December 20, 2018 at 1:32 pm
jcelko212 32090 - Wednesday, December 19, 2018 1:50 PMpatrickmcginnis59 10839 - Wednesday, December 19, 2018 12:53 PMLet's bring 1960s COBOL back and Make Procedures Great Again!!!You might want to look at the numbers. COBOL never left and represents tens of billions of lines of code in daily use. Several years ago, a younger friend of mine was making fun of me for not learning whatever the language du jour was. So I ask him what he was writing it work. It was an app for cell phones at a bank to look up account information. But when I pushed him on it, it had to go to a backend to get the COBOL data out of an ISAM file. I wonder we shouldn't replace the term "legacy code" with the term "family curse" code. 🙂
Too funny. Have run into similar more than once. Like the cracker company said back in the '70s... "You can change the box but it's still the same ol' Ritz". Some things just don't need to change.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 20, 2018 at 1:51 pm
Jeff Moden - Thursday, December 20, 2018 1:32 PMjcelko212 32090 - Wednesday, December 19, 2018 1:50 PMpatrickmcginnis59 10839 - Wednesday, December 19, 2018 12:53 PMLet's bring 1960s COBOL back and Make Procedures Great Again!!!You might want to look at the numbers. COBOL never left and represents tens of billions of lines of code in daily use. Several years ago, a younger friend of mine was making fun of me for not learning whatever the language du jour was. So I ask him what he was writing it work. It was an app for cell phones at a bank to look up account information. But when I pushed him on it, it had to go to a backend to get the COBOL data out of an ISAM file. I wonder we shouldn't replace the term "legacy code" with the term "family curse" code. 🙂
Too funny. Have run into similar more than once. Like the cracker company said back in the '70s... "You can change the box but it's still the same ol' Ritz". Some things just don't need to change.
I worked on an ERP for an education system, in its early incantations it was a telnet driven app running a pick style database app on the server.
Obviously you can't keep selling a telnet app in today's world, so the current version (at the time I left the job) had a full fledged gui. It now looks pretty good, but the interesting tidbit is they essentially use a telnet screen scraper behind the scenes.
https://www.rocketsoftware.com/products/rocket-unidata-0/rocket-wintegrate
December 20, 2018 at 1:59 pm
jcelko212 32090 - Wednesday, December 19, 2018 1:50 PMpatrickmcginnis59 10839 - Wednesday, December 19, 2018 12:53 PMAnd it isn't "COBOL data." It is data data stored in an ISAM database (file if you want).
ISAM (indexed sequential access method) is not a database, but in access method. We🙂
I would call it COBOL data. It's stored as text in ASCII or EBCDIC depending on the hardware and the age of the bank's systems. . COBOL would've defined the datatypes and precision used. The data division in the host programs would have used very COBOL features such as FILLER, OCCURS, PICTURE, etc. to determine the structure of the records. We would have no concept of a key,
It sure as heck will not be a CSV file, 🙂
Theres stuff like "USAGE COMP" you put on your pic clause line in the data division or something like that, this allows some access to more native data types, at least on the system I did COBOL on (VMS), you could even open Berkley style sockets in COBOL but really VMS was the sort of system that had DEC write their compilers and they really were a family of compilers that shared many data types and access to the system api, and of course having ISAM in RMS made for a pretty good pre-DBMS set of features. Heck, RDB on VMS was awesome although I didn't do much with it.
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply