COBOL features for @Heater. and others.
msrobots
Posts: 3,704
OK. This has not yet any relation to Parallax products, but I really hope that the P2 will make this doable for me.
But @Heater asked me for features I miss in other languages in the PBASIC thread. I have to try to shine some light on this.
GnuCOBOL transpiles COBOL to C/C++.
By now PropGCC does not support dynamic loading (yet) so we need to static link all needed stuff. And my beloved GnuCOBOL does not support static linking (yet).
So I am stuck and have to wait until I can run COBOL on a Propeller.
I know I am a nutcase even to think about COBOL, a Language usually running on Main Frames, to run on a Micro Controller. But I simply love this dinosaur of a language.
And sometimes I think it even matches nicely.
COBOL is different from all other languages I had to use in my life. But is has features I do often miss when programming in Basic, C/C++, C#, SPIN, Modula or all the other languages I had to learn (and forget later on).
For example there is no printf(...) in it. If you want formatted output, you put that formatting information into the definition of your data. So in my code I can just write "display customer-total-price" without needing to think about formatting, this is done in the declaration of the data item/variable. SO:
01 customer-total-price pic 9(10) would give me ten digits without sign but
01 customer-total-price pic s9,999,999.99 would give me a formatted output for the same variable. (in this case leading sign commas and decimal point and leading zeroes)
like with printf() there are several variations (leading/trailing sign or spaces or zeroes or even masking with "*" )
But the main point is you do not need to define it every time you need to output it, you do it once at the definition.
Them level indicators are another nice feature. Somehow like a structure in C/C++ but again different.
is easily done in other languages also, but
is a nice way to define meaningful words to values of your data. Each 88 item can be used in Boolean expressions/case ...
so you could write
if FCLOSED ...
instead of
if (DASDSTAT=="42") or whatever the other language has as syntax. Even if using "if (DASDSTAT==FCLOSED)" COBOL looks nicer to me. And more readable.
Like constants in SPIN but bound to the definition of your data items. Easy to find/adjust.
COBOL is a very, very verbose language.
a simple for next loop may read like
perform myroutine varying customer-id from 1 to 100
or a add statement
add 1 to customer-count
NOT : customer-count++;
But this verbosity is also the (normal missing) comment. Usually COBOL programs read almost like English language, especially for non-programmers.
for example:
and the perform will call jumps, otherCode, anotherProcedure and flaming-hoops in that order and repeat until hell-freezes-over so actually one time since hell get set to 1 in flaming-hoops.
I know you are all yawning now, so I might need to fetch some more and better examples.
The next thing fitting perfectly to a MC is the SCREEN SECTION of COBOL programs. Build in TUI support.
Displaying and accepting whole screens with two lines of code.
A screen is basically a data definition as shown above, but with line and row numbers attached per item if needed and located in the SCREEN SECTION of a COBOL program.
Then we have the unique(?) basic file handling of COBOL. Sure you can use SQL and tons of databases with COBOL, but it has some nice build in basic file handling. Sure its old stuff. ISAM. So comparable to Dbase3 if someone remembers. Data files and index files. But in opposite to Dbase quite unlimited in Data size.
I will give a example in the next post. I need to look for some free one.
And then there is the REPORT SECTION.
Another set of data definitions just to produce nice reports, build for printing not to throw on the screen like screen definitions.
And supporting all the goodies you really need like group changes and group and total sums, or whatever you desire.
All of it build in to the language. Almost seamless.
not sure if anybody here is interested in COBOL, a major hurdle to get more public presence is that anybody thinks COBOL is dead.
But it isn't.
I barely scratched the language in this post, so if there is some interest I can happily supply more information.
Coming back to the original post of @Heater. it is not so that languages like C/C++ or JavaScript el. al. can't do this. GnuCobol compiles COBOL source to C(or C++). So I am absolutely sure that C/C++ can handle all of this. Because they actually do.
I just think that COBOL is way more readable as a lot of other languages. And I will not mention FORTH here at all.
Enjoy!
Mike
But @Heater asked me for features I miss in other languages in the PBASIC thread. I have to try to shine some light on this.
GnuCOBOL transpiles COBOL to C/C++.
By now PropGCC does not support dynamic loading (yet) so we need to static link all needed stuff. And my beloved GnuCOBOL does not support static linking (yet).
So I am stuck and have to wait until I can run COBOL on a Propeller.
I know I am a nutcase even to think about COBOL, a Language usually running on Main Frames, to run on a Micro Controller. But I simply love this dinosaur of a language.
And sometimes I think it even matches nicely.
COBOL is different from all other languages I had to use in my life. But is has features I do often miss when programming in Basic, C/C++, C#, SPIN, Modula or all the other languages I had to learn (and forget later on).
For example there is no printf(...) in it. If you want formatted output, you put that formatting information into the definition of your data. So in my code I can just write "display customer-total-price" without needing to think about formatting, this is done in the declaration of the data item/variable. SO:
01 customer-total-price pic 9(10) would give me ten digits without sign but
01 customer-total-price pic s9,999,999.99 would give me a formatted output for the same variable. (in this case leading sign commas and decimal point and leading zeroes)
like with printf() there are several variations (leading/trailing sign or spaces or zeroes or even masking with "*" )
But the main point is you do not need to define it every time you need to output it, you do it once at the definition.
Them level indicators are another nice feature. Somehow like a structure in C/C++ but again different.
01 full-name 05 first-name pic X(30) 05 fast name pic X(30)
is easily done in other languages also, but
*
01 ISAMFILE-NAME PIC X(080) VALUE "ISAMFILE".
01 ISAMFILE-OCFG PIC X(001) VALUE "C".
88 ISAMFILE-NOTOPEN VALUE "C".
88 ISAMFILE-IS-OPEN VALUE "I", "O", "U".
*
* These values may vary between compilers.
* RM-Cobol values
01 DASDSTAT PIC X(002).
88 GOODIO VALUE "00".
88 DUPAKEY VALUE "02".
88 NO-FILE VALUE "05", "35".
88 DUPRECD VALUE "22".
88 NO-RECD VALUE "23".
88 FCLOSED VALUE "42".
88 LOSTPOSN VALUE "46".
88 KEYERROR VALUE "98".
88 BUSYIO VALUE "99".
*
is a nice way to define meaningful words to values of your data. Each 88 item can be used in Boolean expressions/case ...
so you could write
if FCLOSED ...
instead of
if (DASDSTAT=="42") or whatever the other language has as syntax. Even if using "if (DASDSTAT==FCLOSED)" COBOL looks nicer to me. And more readable.
Like constants in SPIN but bound to the definition of your data items. Easy to find/adjust.
COBOL is a very, very verbose language.
a simple for next loop may read like
perform myroutine varying customer-id from 1 to 100
or a add statement
add 1 to customer-count
NOT : customer-count++;
But this verbosity is also the (normal missing) comment. Usually COBOL programs read almost like English language, especially for non-programmers.
for example:
identification division. program-id. freeze. data division. working-storage section. 01 hell pic 9 value 0. 88 hell-freezes-over value 1. procedure division. perform jumps thru flaming-hoops until hell-freezes-over. stop run. jumps. ... otherCode. ... anotherProcedure. ... flaming-hoops. ... move 1 to hell
and the perform will call jumps, otherCode, anotherProcedure and flaming-hoops in that order and repeat until hell-freezes-over so actually one time since hell get set to 1 in flaming-hoops.
I know you are all yawning now, so I might need to fetch some more and better examples.
The next thing fitting perfectly to a MC is the SCREEN SECTION of COBOL programs. Build in TUI support.
Displaying and accepting whole screens with two lines of code.
A screen is basically a data definition as shown above, but with line and row numbers attached per item if needed and located in the SCREEN SECTION of a COBOL program.
Then we have the unique(?) basic file handling of COBOL. Sure you can use SQL and tons of databases with COBOL, but it has some nice build in basic file handling. Sure its old stuff. ISAM. So comparable to Dbase3 if someone remembers. Data files and index files. But in opposite to Dbase quite unlimited in Data size.
I will give a example in the next post. I need to look for some free one.
And then there is the REPORT SECTION.
Another set of data definitions just to produce nice reports, build for printing not to throw on the screen like screen definitions.
And supporting all the goodies you really need like group changes and group and total sums, or whatever you desire.
All of it build in to the language. Almost seamless.
not sure if anybody here is interested in COBOL, a major hurdle to get more public presence is that anybody thinks COBOL is dead.
But it isn't.
I barely scratched the language in this post, so if there is some interest I can happily supply more information.
Coming back to the original post of @Heater. it is not so that languages like C/C++ or JavaScript el. al. can't do this. GnuCobol compiles COBOL source to C(or C++). So I am absolutely sure that C/C++ can handle all of this. Because they actually do.
I just think that COBOL is way more readable as a lot of other languages. And I will not mention FORTH here at all.
Enjoy!
Mike
Comments
Very readable. Only problem is that it seems to hide any notion of an algorithm you may have as best it can!
I was idly speculating, whilst waiting for a bus the other day:
If msrobots ever gets COBOL to run on a Prop or other MCU and wiggle an I/O pin with it, that will be a world first! With that Earth shattering break through millions of COBOL programmers will crawl out of their bank vaults and start programming micro-controllers. Flashing LEDS. Building IoT devices. All of a sudden stackoverflow will be full of COBOLers asking questions about how do do real world things with COBOL on MCU's. Github and Bitbucket will suddenly be full of COBOL repositories.
Then the bus came, and I woke up.
Next time waiting for the bus you'll dream how to add a way to access DIRA/OUTA from COBOL... ;-)
Problem is it's closed source so hacking it to wiggle an I/O is not attractive.
I think that bringing the Propeller, micro-controllers and IoT to the sad and dark world of COBOL programmers is such an important mission that it deserves a long term supported proper solution. We have to set them free.
Technically, you could. My 1130 emulator will run 1130 COBOL. Unfortunately, those that have the actual COBOL compiler won't release it because of potential legal issues. The compiler was licensed by IBM rather than provided with the machine (like FORTRAN and RPG I). I doubt that IBM would bother to enforce 50-year-old license agreements for an obsolete machine.
I have a few COBOL programs that I'd really like to run again. Maybe someday?
The COBOL didn't support a screen section, and may have supported the report section (that was an IBM enhancement).
Walter
You might be surprised how many large companies still depend on COBOL (banking, health insurance, etc).
COBOL with IBM's DB2 relational database or Oracle and various interfaces to PC/network based applications are still a powerful combination.
Rewriting huge COBOL systems would be to costly and time consuming for many companies so they just keep them running...
Install GnuCOBOL.
Then perhaps your old COBOL programs will live again!
I was idly speculating, whilst waiting for another bus...
What the heck. GNUCobol won't run on a Prop. But I'm sure it runs on a Raspberry Pi.
All we need to do is figure out how to use some C code from Cobol and link that together. The C code could do the GPIO reading and writing. Connecting to SPI/I2C devices and so on.
BINGO, we bring the sad old Cobol guys into the light of the modern IoT world. Not exactly a micro-controller but think of the possibilities!
Then the bus arrived and I woke up....
This is a job for msrobots. I have enough unfinished projects around here.
Heater -
I'm sure that would work... but that's the easy way out. I want to run them - unmodified - in their original environment (or a reasonable facsimile).
There is a MIT thesis detailing a COBOL compiler for the 1130 (from 1970 or so). I'm seriously thinking about obtaining a copy and implementing it. And I have no idea if it actually worked or not. Sadly, the author passed away last year.
Easy? No. But I learn best from doing.
I have no idea of course but as far as I understand the Cobol language has not changed in decades. What changes have come with recent standards are backward compatible. They don't break old code.
So, I imagine your old code can be run under GNUCobol, unmodified.
Assuming you have the source code of course.
If not, you are into emulator land.
Or is there a point I am missing?
Oh yeah. I'm familiar with the hard way to do things. Having got CP/M and programs written for it to run on the Propeller.
Still, someone should make it possible for the Cobol guys to interface with the real world. They need it
Well, there is Object Oriented COBOL
Regarding breaking old code... IBM did, back in the 90's, on the mainframe. They introduced a common framework (Language Environment, I believe) that removed support for the report section, removed ALTER GOTO support, and also caused issues with some programs that used overlapping card input formats. The latter was fairly easy to fix, ALTER GOTO was a bad idea from the start (but it was used) and the report section removal caused many programs to have to be rewritten from scratch.
I do have the source code.
You're not missing a point, I'm not being clear about my goals. What I want to do is run programs that I wrote (in high school) on an IBM 1130... on an IBM 1130. Specifically, my 1130 emulator. Not for any practical purpose. I do enough software development for the real world at work (or at least I like to think I do). This is play, nothing more.
Walter
Software archaeology. Or should we say "preservation".
That was the drive behind getting CP/M working on the Prop.
Sadly I don't have the source to the Algol I wrote in uni back in 1976. No idea what happened to those punch cards....
yes. The guys on the GnuCOBOL project doing a tremendous job to archive that.
Interfacing C and GnuCOBOL is very easy and GnuCOBOL already runs on RasPi's.
It's just I never really liked C/C++ and have very limited knowledge of Linux systems. This might change with my next computer since Win10 now includes something like "bash on Ubuntu on windows" and is able to run elf binaries.
It is some sort of a Linux Subsystem for windows.
here a more complete example of the use of declaratives.
... ... INPUT-OUTPUT SECTION. FILE-CONTROL. SELECT ISAMFILE ASSIGN TO DISK ISAMFILE-NAME ORGANIZATION IS INDEXED ACCESS MODE IS DYNAMIC RECORD KEY IS ISAMFILE-KEYP FILE STATUS DASDSTAT. ... ... DATA DIVISION. FILE SECTION. FD ISAMFILE LABEL RECORDS ARE STANDARD. 01 ISAMFILE-RECD. 03 ISAMFILE-KEYP. 05 ISAMFILE-BANK-NMBR PIC 9(004). 05 ISAMFILE-BRCH-NMBR PIC 9(004). 03 ISAMFILE-DATA PIC X(992). ... ... / WORKING-STORAGE SECTION. * 01 ISAMFILE-NAME PIC X(080) VALUE "ISAMFILE". 01 ISAMFILE-OCFG PIC X(001) VALUE "C". 88 ISAMFILE-NOTOPEN VALUE "C". 88 ISAMFILE-IS-OPEN VALUE "I", "O", "U". * * These values may vary between compilers. * RM-Cobol values 01 DASDSTAT PIC X(002). 88 GOODIO VALUE "00". 88 DUPAKEY VALUE "02". 88 NO-FILE VALUE "05", "35". 88 DUPRECD VALUE "22". 88 NO-RECD VALUE "23". 88 FCLOSED VALUE "42". 88 LOSTPOSN VALUE "46". 88 KEYERROR VALUE "98". 88 BUSYIO VALUE "99". * 01 PROGRAM-EXIT-STATUS PIC 9(003) VALUE ZEROES. ... ... / PROCEDURE DIVISION. DECLARATIVES. ISAMFILE-STATUS SECTION. USE AFTER STANDARD EXCEPTION PROCEDURE ON ISAMFILE. ISAMFILE-STATUS-EXECUTE. IF NOT BUSYIO MOVE DASDSTAT TO LOG-FILE-STAT MOVE ISAMFILE-NAME TO LOG-FILE-NAME PERFORM LOG-A-FILE-ERROR END-IF. END DECLARATIVES. * * * MAIN-CODE SECTION. MAIN-CODE-0000. OPEN INPUT ISAMFILE. IF NOT GOODIO MOVE 86 TO PROGRAM-EXIT-STATUS GO TO MAIN-CODE-EXIT END-IF. MOVE 'I' TO ISAMFILE-OCFG. * MAIN-CODE-1000. READ ISAMFILE NEXT RECORD WITH NO LOCK AT END GO TO MAIN-CODE-EXIT END-READ. IF BUSYIO PERFORM BUSY-CODE END-IF. IF LOSTPOSN PERFORM LOST-CODE END-IF. * Insert additional status checks as needed ... ... ... * Do 'NOT AT END' stuff here ... ... ... GO TO MAIN-CODE-1000. MAIN-CODE-EXIT. IF ISAMFILE-IS-OPEN CLOSE ISAMFILE END-IF. MOVE 'C' TO ISAMFILE-OCFG MOVE PROGRAM-EXIT-STATUS TO RETURN-CODE. STOP RUN.The idea is to connect Cobol to hardware. GPIO, I2C, SPI, UART, etc as directly as possible.
If GNU Cobol can interface to C/C++ easily then we are nearly there.
Windows does not help. Ubuntu on Windows does not help. Many layers of abstraction too far away from those GPIO pins.
By the way, I have used BASH on Windows for a decade or more now. Using cygwin. On the rare occasions I have had to use a Windows machine that is the first thing that gets installed. It's what makes this Win 10 machine I am typing into now tolerable.
I don't know what they are doing running Ubuntu elf binaries on Windows but it does not sound good. Why do that?
sudo apt-get install gcc make flex bison autoconf automake libtool libgmp libgmp-dev libdb5.3 libdb-dev gettext help2man texlive-binaries subversion gdb
just guessing.
Mike
Bit like putting lipstick on a pig.
All the other programmers laughed at Bob. They were doing sexy graphics work on cutting edge games, making databases handle gigabytes of data, and tapping into this new internet thing in ways nobody ever thought possible, while Bob wrote stodgy software for banks and insurance companies. Boring old Bob.
But then Y2K was looming and suddenly Bob was a popular guy. He was getting offers left and right, jet-setting across the country and having lunch with the CEO's of Fortune 100 companies. Turns out COBOL might be boring but lots of important people use it.
So many in fact, and so much work, that Bob lost it. Burned out. Crashed. He found a company that said it could put him in suspended animation for the duration of the crisis, and wake him up when Y2K was all over and done. Bob sighed and signed up. They gave him a tour of the facility, it was all state of the art with high tech medical hardware and state of the art computers. Bob signed the form and they put him under, with the timer programmed to wake him up on January 1, 2000.
So Bob goes under, and when he wakes up he's surrounded by folks in scrubs and surgical masks. There are gasps of amazement and a couple of claps of applause. "He made it! He's alive!" someone squeals. They sit him up and give him some water and all in all he feels OK.
"What's the big deal?" he asks when he feels strong enough. "You guys didn't seem to think it would be any big deal when you put me under."
"Well, we have some good news and some bad news," the team leader tells him. "The bad news is that the timer that was supposed to wake you up wasn't Y2K compliant, and you've been out for eight thousand years, so everyone you knew is dead. The good news is that we've solved the problems of poverty, war, crime, and unemployment."
"That's...swell," Bob says, trying to wrap his head around it. "But tell me something, if I've been in this can for 8,000 years, why did you finally decide to try and wake me up?"
"Well," the team leader says, "It says in your file that you know COBOL, and the year 10,000 is coming up."
I'll be here all night, folks.
If the film takes place in a devolved future, where do they find people to design the advanced computer and medical devices portrayed in the film? People like Bob then.
Pretty funny!! Luckily, I had moved on to developing Windows programs a few years before Y2K.
A lot people thought COBOL couldn't handle four digit years. That was not the problem of course - the problem was short sighted analysts that tried to save file space or figured the system would obsolete before 1/1/2000. Disk space was expensive. In fact, the first mainframes I worked on in 1973 at G.E. had no disk drives. Each one had 12 tape drives...
I disagree. The issue goes back to the days of punched cards. Many early systems used punched card decks as a database. Most of these cards had only 80 columns. Space was at an extreme premium. As an example, overpunched digits were used to save a column for signed numbers.
As far as "short sighted/obsolete"... Imagine it's 1965 and you're an analyst. You want to make the year field 4 digits because it will cause issues 35 years from now. Due to the amount of data required, this will mean 2 cards per transaction, not 1, doubling the cost of cards and doubling the time it takes to process those cards. Do you think management would have said yes? Or would you be out of a job?
Walter
8000 years?!
They are going to have to wake up Bob and thousands of Windows, Unix/Linux, Java and other programmers in 2037 to fix the impending doom of the 32 bit epoch roll over in 2038 !
Despite the 2038 issue, that the Unix creators decided on a counter as a time base instead of year/month/day/hour/minute/seconds was pure genius (and of course extremely obvious after the fact, but not before, as with most such ideas). I don't know if Kernighan and Thompson came up with that themselves or took it from Multics or somewhere else.
A while ago I noticed that my minicomputer emulator started to show the time of files as being in the fifties.. and of course that was because the file system designer, back in the early seventies, had decided on a 32-bit field for the time (so far so good), but divided that into separate fields for year/month/day etc., which only allows for 6 bits used as an unsigned integer for years. As it's unsigned, the designer settled for 1950 as epoch year. But 6 bits only gives you 63 years.. so it rolled over in 2013. Even if that looked 'good enough' in the seventies (though the last system was sold in 2001), it still looks like an incredibly bad idea to have a time stamp made up of year/month and so on, when it's so much simpler to just use a linear seconds counter. And the latter is so much easier to do date arithmetic on as well. But of course, somebody had to come up with that idea in the first place before it became obvious.. MS-DOS has the same problem as my mini. But they tried to make things better by reducing the space needed for seconds by one bit, so the resolution is 2 seconds. Just use a seconds time stamp, guys! Well, they didn't, and so didn't many others, so it was clearly not obvious.
It's the user space stuff where the problems will be.
This bit me already a couple of years back when trying to create certificates and keys with openssl on a 32 bit Debian machine. They did not work. Then I realized I was asking for a very long expiry time, past 2038. openssl was creating pre-expired certs and keys because it's date calculations had rolled over! Worked fine on a 64 bit Debian installation.
That openssl problem has been fixed since then. But who knows where similar problems exist in application code? Especially in all those embedded systems that have been built on Linux by now.
Punch cards were phased out in plenty of time for systems to be modifed to handle 4 digit years.
https://en.wikipedia.org/wiki/Year_2000_problem
Of course programmers squeezed what they could into the space available. Including skimping on date formats.
Technology advanced exponentially since then. Which makes that all that look really stupid.
How were they to know that would happen?
Even if they knew that would happen they would have to skimp on date and other formats since they had make do with what was available at the time.
I had to look it up ;-)
https://en.wikipedia.org/wiki/Signed_overpunch
Bottom line: don't let anyone tell you that Unix timestamps are a count of seconds since the epoch. They aren't.
I'm not sure I understood all that.
Of course I naturally assumed the Unix timestamps were the number of seconds since the epoch. Never mind any leap seconds and such.
This is disturbing news to me.
I don't get the point about differentiating between "23:59:60 of one day and 00:00:00 of the next". Surely if you are counting hours minutes and seconds there is no 23:59:60. Minutes and seconds are in base 60 so you can only count to 23:59:59. The next tick is 00:00:00.