Cobol Database Migration

Hi experts,

i must develop a system to a professional, and he she has an old cobol software. I found a tool that gives to me the next information:

Min Records=121
Max Records=331
Data Compression on
Space code = 32
Number code=48
Key compression on
Key number code = 32
Block Size = 512
Block Increment = 512
Block Contains = 0
Allocation increment = 0
Index block = 1768
No records = 5713
Integrity flag=0
Primary Key Offset = 0
Primary Key Lenght = 4
Empty block = 3

 Now i need to know how to process this information ( what is useful and what doesnt ) in java or .net


Who is Participating?
moorhouselondonConnect With a Mentor Commented:
Here are my thoughts on what some of those values represent:-

Max Records=331
I have messed around software in the past which had a ceiling for the maximum number of records - if you want to expand the size of the table you had to do it using a special procedure.  Not applicable these days.

Space code = 32
The ASCII code for a Space character is 32

Number code=48
The ASCII code for a '0' character is 48, '1' is 49, etc.

Key number code = 32
The smallest ASCII code on your keyboard (apart from control characters) is the space bar (ASCII code 32)

Block Size = 512
When reading/writing to hard drive a record is defined as 512 bytes
These are Constant values that COBOL needed to help define its environment.  Newer languages don't need you to define these things - they are handled automatically.  In fact, it is best to start off with a clean slate - making your software mimic COBOL's data structures could well be counter-productive.
SunBowConnect With a Mentor Commented:
Close enough, not that I know much better. You usually have more records than blocks, they are not same, the former being the data, the latter more the physical space. Think: sector(s).

> Max Records=331
> No records = 5713

This kind of thing befuddles imagination as much as MS-Speak. Among reasons I disliked Cobol. CD& could probably whip through it if you chose a better TA.

I probably agree with moorhouselondon

You should try to get data to flat file, first, ignore all of the above except that at your destination is a Cobol Professional. Show them the data and then ask what is needed/required. Can it import CSV file, or is it to be fixed column? Generally those are the more common forms, after dBase.

So learn to adapt you output accordingly, such as for ouputting text only, and for having all items of a field being equal in length, a language can be very finicky about that, getting columns to line up. You might be able to practice with MS-Office if you have it, try moving it to Access, for example.

If your friend is instead giving you the data, do the reverse, have them get it to you in an agreed format for a flat file that either has fixed length fields or can be delimited by commas if their language permits. It may depend on how old their language is. Some are running OOP
>  Newer languages don't need you to define these things - they are handled automatically

It isn't cobol so much as how the back end is defined, and how that has improved over time. A language should not be so dependent on a specific format for an HD for example, other parts of system such as controllers and operating systems can do that well enough. But sometimes it pays also to first ensure there is sufficient disk space, before attempting to write to the file a character at a time, only to hav it all blow up on you in the middle of a run.
MarianoSBAuthor Commented:
It wont be necessary, i forgot to close the commentary and to assign the points.  Thanks for warning.  Regards,    Mariano
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.