0

I have an existing MF COBOL 4.0 program with years of data in a ISAM file but I need to add a new field to the existing file. The record currently has 1208 chars and I need to add another 10 to it.

If I simply put the extra PIC X(10) field in my copybook, it gives me an error.

Cloves Almeida
  • 83
  • 1
  • 6
  • What kind of error do you get? – Peter Lang Feb 17 '10 at 19:50
  • Is it a compile time error or a run time error? And as Peter asks, give us a bit more detail. The specific message number/text would be very usefull. – NealB Feb 17 '10 at 20:44
  • It gives me an ERROR 39. – Cloves Almeida Feb 18 '10 at 17:24
  • You didn't indicate, but I am guessing you are getting "ERROR 39" at runtime. File Status 39 indicates a conflict between the actual file structure and how you have defined it in your program. This error occured on your OPEN statement. If this is the case, the answer provided by *avisser* below is the correct one, you need to restructure your file to match the revised record definition in your program. Right now you are trying to read an "apple" record with a program that only knows about "oranges" (maybe a bad analogy - but I'm not feeling very creative at the moment). – NealB Feb 18 '10 at 20:14

4 Answers4

2

You need to modify the underlying data file to match your file definition in COBOL. One way to do so would be to define a line of output exactly like what lines of your data look like now, but with an extra Pic x(10) on the end of it. You would then read in your data line by line, and output it to a new location with 10 extra spaces on the end of it. That way your data is 10 characters longer, and you can go back and add that extra Pic x(10) to your main program. It should work after that.

Micah
  • 514
  • 3
  • 11
0

For file errors, you will want to keep a list handy. I recommend starting with a list you find online, and any time you get an error you cannot figure out in 5 seconds, add a detailed explanation of the resolution so you will have it in your notes the next time it happens. Here are a couple decent lists to start with

In my list, file status 39 is:

  • OPEN-CONFLICT-FILE-ATR - The 'open' statement was unsuccessful because a conflict was detected between the fixed file attributes specified for that file in the program. These attibutes include the organization of the file (sequential, relative, or indexed), the prime record key, the alternate record keys, the code set, the maximum record size, and the record type (fixed or variable).

And this is from the personalized note: Check the file that you have assigned to your ddname in your JCL. Especially the length allocation. In your case, you know that the length does not match, since you just changed the program.

There are utilities to reformat datasets, particularly SYNCSORT. Or of course you can write your own.

Abacus
  • 2,041
  • 1
  • 18
  • 23
0

With changing the copybook, you're only changing the representation of the data used in your program. Shouldn't you be restructuring the data source (i.e. the ISAM file) as well?

Albert Visser
  • 1,124
  • 6
  • 5
0

Late answer, but I thought you might be interested.

I've been working on our Cobol system for over 20 years and we've come across this issue many times.

Changes to the structure of our index files are what we consider a "Major Release". These require specific Conversion programs which:

  1. Rename the physical file, moving it aside to an 'old' file
  2. Open the 'old' version of the file (using a version of the copybook before the change)
  3. Open (create) the 'new' version of the file
  4. Move the contents of each of the 'old' records to a 'new' record and WRITEs it

Of course these conversions require the system to be 'down', hence the reason why they are considered major releases.

If you have files which are likely to have fields added to them in the future, you can add extra FILLER to the end of index file to let you cope with new fields being added. We tend to add a FILLER of 50 or 100. Of course this doesn't help you if you change one of the existing fields, or even the structure of any of the keys.

DuncanKinnear
  • 4,563
  • 2
  • 34
  • 65