Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

macOS Anyone familiar with COBOL?

Aperture

Aperture

macrumors 68000
Original poster
Mar 19, 2006
1,876
0
PA
Hey Everyone. This isn't really related to Mac programming, so I apologize, but I'm seeking your help. I was asked to help extract some data from an old piece of custom business software written in COBOL for Windows. The software was published in 1996, so it is quite old.

Could anyone point me to any docs regarding data storage in older COBOL apps? If possible to know with such little info, how is it likely storing information? Is it likely self inclosed, storing in a database, or storing in an external file somewhere (is there a common file extension?).

Also, are there any good data manipulation apps out there that would help me convert this data into a newer format?

This is a big question, but I'll really appreciate any help I can get! :)
 
This page seems to suggest that COBOL does indeed have some sort of file access mechanism. Perhaps even this little bit will help you get the feel for reading the code.

I remember reading a book on COBOL in the 70s, when my programming consisted of BASIC on the school system mainframe. It kinda scared me.
 
This would be my approach:
Learn enough COBOL to recognize I/O. Find the output statements (or input statements) and work to decipher what the format of a record is, what field and record separators are, etc.
Hopefully you have access to a UNIX-like environment available, like Linux or OS X. If not, get cygwin installed on a windows machine. Then use a tool like od to take a look at the binary files that are generated by this software, to try to confirm your ideas about how the data is laid out.
Document the layout(s), with descriptions of the fields. Document the relationship of the files to one another. Document the field offsets within each record, the widths in bytes, the datatype if this varies, etc. This will form your foundation for extracting this data.
Decide what you want the destination format to be. I would choose a relational database, get the data loaded, then get a schema and data dump. This should give you an easy way to move the data again in the future.
Once you have all this done, then you can start writing code. I would not try to fix this problem with more COBOL. I would pick a language that you know well already. If you don't know any languages, this project will go much slower because you will have more to learn.
You'll need to basically write a data translator at this point. It will read up the records and stick them in the new datastore.

This will be a difficult task. It can be simplified if you can clear all data in a test environment and start building records, observing the way the files change.

Good luck. I don't envy you.

-Lee
 
Haha, thanks guys. You were both a big help!

PS: Lee, I don't blame you!
 
I did a load of COBOL stuff in the mid-late eighties. Can't remember much of it though. I do remember it being one of the most verbose languages ever but the way it dealt with data entry forms was pretty neat.
 
RM/COBOL from MicroFocus is a popular compiler and their web site can provide some information on how to get your data. Try looking for an ODBC driver to make it easier.
 
The structure of data used by a COBOL program should be mapped out in declarations that use PICTURE ("PIC") patterns, e.g.,
Code: 
DATA DIVISION.
FILE SECTION.
FD CountryFile.
01 CountryRec            PIC X(28).
   88 EndOfCountryFile   VALUE HIGH-VALUES.

FD GraduateInfoFile.
01 GradInfoRecGF.
   88 EndOfGradFile      VALUE HIGH-VALUES.
   02 StudentNameGF      PIC X(25).
   02 GradYearGF         PIC 9(4).
   02 CourseCodeGF       PIC 9.
      88 CSISGraduate    VALUE 1 THRU 5.
   02 EmailAddrGF        PIC X(28).
   02 EmailDomainGF      PIC X(20).
   02 CountryCodeGF      PIC XX.
Do you see a section this this in the code? Chances are this is data with fixed-length fields within each record (chunk of a disk file). Each PIC value tells you the length of the field and its format. Here is an explanation of the letters used in PIC declarations and here are additional options for formatted output.
 
ow, ow, ow, it hurts, it hurts. I can smell the cabinets full of untouched paper files in hanging folders, the shelves of books bound with burgundy and gold leaf cardboard covers that someone last looked at when MLK was still marching. The tile wainscoting, the 5-wheeled mahogany-stained chairs with the iron screw to set the height.

I can see someone in a white lab coat carefully pulling a moth from a relay in the array. Please, make it stop.
 
Aperture said:
Hey Everyone. This isn't really related to Mac programming, so I apologize, but I'm seeking your help. I was asked to help extract some data from an old piece of custom business software written in COBOL for Windows. The software was published in 1996, so it is quite old.

Could anyone point me to any docs regarding data storage in older COBOL apps? If possible to know with such little info, how is it likely storing information? Is it likely self inclosed, storing in a database, or storing in an external file somewhere (is there a common file extension?).

Also, are there any good data manipulation apps out there that would help me convert this data into a newer format?

This is a big question, but I'll really appreciate any help I can get! :)
Click to expand...

I've written quite a lot of COBOL but none in the last 30 years.
It likley is storing data in fixed field binary files. But COBOL is also designed to work very closly with SQL (and other older) databases and has some abilty to make querries from ithin the language.

But just read the code. The I/O section will very clearly define all the file formats with "Picture" statements. Unlike C, Cobol seporates the format of the data from the statem,ents that do the I/O. The relation betwen the fields and the names (variables) are efined up at the top. I/O stamants operat on the names.

Also notice the the files structur is hiarical kind of like an outline using level numbers.


The laters version of COBOL like you have (the 90's were very, very late for Cobol) has some extentions to the language for use with CRTs and interactive users.

You should just read up a little on the language. It is not hard. very simple. Most of it is "declarative" and says what is to happen, not how.

Don't expect comma delimited files. Fixed fields was the style. But COBOL also does have built-in ISAM files (ISAM is like a single table DBMS)
 
I'm a mainframe COBOL programmer. Feel free to ask me whatever, I will try to help you. Being able to see the source code would be a help as well, the file layout structures may be inline in the program or stand alone files (called "copybooks") - so if you see an FD statement that is followed by a COPY xxxxxx type statement, your program is using a copybook and you need to find a file with the xxxxxx name. Best of luck.

Scott
 
CodeRaven said:
I'm a mainframe COBOL programmer. Feel free to ask me whatever, I will try to help you. Being able to see the source code would be a help as well, the file layout structures may be inline in the program or stand alone files (called "copybooks") - so if you see an FD statement that is followed by a COPY xxxxxx type statement, your program is using a copybook and you need to find a file with the xxxxxx name. Best of luck.
Click to expand...
Sweet. :)

Can you elaborate what type of applications you maintain/create?

The last I used COBOL was a little over 30 years ago. A bit rusty. At the time, one program I developed for the DoD was a COBOL program that analyzed other COBOL source programs for complexity based upon McCabe's complexity criteria.

I think I still have that program around the home somewhere.
 
I mainly do batch programs, but have worked a little on some CICS programs. I work for a world-wide mutual fund company.
 
Open a copy of the file in a simple text editor to see how the data is stored. Also knowing the data store, ala Dr Q helps.

If it is something simple, and a flat database file.

Using something simple like Filemaker, or even Excel can input the file into an easy to use file format.

I've used both for file import, usually Excel, since it was usually the quickest to import using fixed field length or a delineated file structures. And it is rather easy to export.

Though a programmer might find out the file structure, how the new database handles data and write a simple program to do it.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back