VB File attribute mismatch

Learncoholic · New User Joined: 20 Sep 2007 Posts: 97 Location: India

Hi,

My Cobol program has the following file definition for an input dataset -

Bill Woodger · Posted: Wed Nov 14, 2012 1:49 pm

Why is the record in the FD defined like that if your maximum/only length is 1635 of data?

Learncoholic · New User Joined: 20 Sep 2007 Posts: 97 Location: India

Hi Bill,

The VB file may contain records more than 1635 of length & hence FD is defined such as to let COBOL run as is even for increase in length.

Thanks

Robert Sample · Posted: Wed Nov 14, 2012 5:15 pm

Learncoholic, the error message is EXTREMELY explicit about what your problem is. The error message states that your program has defined the file as having records with LRECL 32756 yet the physical file has LRECL 1639. What do you not understand about that error message?

The system is telling you that your belief the file has record length 32752 is wrong -- believe the system and change your program. And, by the way, the VB file may NOT contain records more than 1635 bytes long -- your system indicates that the file is not spanned, and the LRECL is 1639 so the longest any record will EVER be is 1635 bytes.

Learncoholic · New User Joined: 20 Sep 2007 Posts: 97 Location: India

Thanks Robert.

The problem to me is more than intended in the error message.
When the COBOL is executed in production, the INPUT file is opened successfully & the module is executing as it is.

But when the same program is run in Test, it's abending with the error message.

So I am un-ceratin about how the same program is executing fine in production but throwing the error in test.

Is there a problem with compilation parms?

Thanks

Bill Woodger · Posted: Wed Nov 14, 2012 5:48 pm

If it is working in Production, check the characteristics of the dataset in Production and let us know.

Robert Sample · Posted: Wed Nov 14, 2012 5:52 pm

Obviously, the program running in production and the program running in test are not the same program if the same input file (and you ARE using the same input file -- not a copy, right?) in the two programs generated different results. Why the difference? It may be how the program was compiled, it may be test and production files are not the same, it may be pretty much anything. Your job, as a programmer, is to figure out what the difference is.

But you STILL need to understand that your belief that the file will contain any records longer than 1635 bytes is not rational and definitely not supported by what the system is telling you. Unless your application creates records by combining data in multiple input records from the file, there simply is no way for you to ever have a record longer than 1635 bytes -- PERIOD.

Anuj Dhawan · Posted: Wed Nov 14, 2012 7:32 pm

Jose Mateo · Posted: Wed Nov 14, 2012 7:57 pm

Good morning to all!

If you are saying that the program and the file attributes in the PRODUCTION system are the same as in the TEST system then I don't know how it's running in the production system. In your FD you are not including the four bytes for the record length for every record on the file,
S/B RECORD 1639 TO 32756. Plus you need to add a 01 for the smallest record on the file, in this case it be 1639.
S/B 01 DUMMY-SM-RECORD.
05 FILLER PIC X(1639).

01 DUMMY-RECORD.
05 FILLER PIC X(32756).

Bill Woodger · Posted: Wed Nov 14, 2012 10:13 pm

Jose,

I've never had to define the RDW in a Cobol FD.

Robert Sample · Posted: Wed Nov 14, 2012 11:01 pm

Jose, the Enterprise COBOL Programming Guide manual specifically states in 1.9.1.1.3 that what you posted is not right (emphasis added):

Bill O'Boyle · Posted: Thu Nov 15, 2012 1:08 am

The following previous post might be beneficial -

www.ibmmainframes.com/viewtopic.php?p=293539&highlight=#293539

Learncoholic · New User Joined: 20 Sep 2007 Posts: 97 Location: India

Thanks to all.

I resolved the situation to find that the problem was not in COBOL at all.

Actually the I/P file I was referring to was a version of GDG.
Now, 2 different programs creates 2 different versions of the same GDG.
Each of the programs uses different LRECL for their respective versions.

The Program that I referred to as abending uses the latest version of the GDG. This version has LRECL of 1639.

After this program was executed in production, another program created a new version of the GDG with different LRECL.

Since the program (that I referred to) uses the latest version of the GDG in production, so in test we executed the module with latest version of GDG. However we were oblivious of the fact that a GDG version was created with diff LRECL after the module was executed.
This resulted in the confusion.

Thanks once again for taking time out to look into my problem.

dick scherrer · Posted: Wed Nov 21, 2012 10:22 pm

Hello,

Learncoholic · New User Joined: 20 Sep 2007 Posts: 97 Location: India

I agree with you Dick.

In case files under same GDG is created, all versions should have the same DCB.

But in actual ground this was not being followed. I am uncertain why it was set up like that.

Thanks

Nic Clouston · Posted: Thu Nov 22, 2012 6:51 pm

I assume that you are NOT talking about versions (where the Vxx bit changes) but generations (where the Gxxxx bit changes)?

dick scherrer · Posted: Fri Nov 23, 2012 8:54 am

Hello,

I'm more than 99% sure that these are Generations NOT Versions.

Poor design is why/how this was set up this way. I'd encourage doing the research and determine how to hace one set of dcb info.