COBOL Output write problem

sijayapal · New User Joined: 23 Dec 2008 Posts: 69 Location: India

Hi,

I have a cobol code which creates 13 output generations from a single input file based on certain conditions. When i ran the code, i got the data in first file and last file but the other versions are empty. Then i tried to trace the code line by line... and found that the records are getting processed properly and being writen to the output but the data is not present in the output file. I am confused.. Any guess>??????

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

How are you coding the dataset names in the JCL? Are they separate DDs? Are the generations hardcoded?

dbzTHEdinosauer · Posted: Wed Aug 10, 2011 8:33 pm

yeah, line 87 of your code invalidates the 3rd dd statement in your jcl.

sijayapal · New User Joined: 23 Dec 2008 Posts: 69 Location: India

yes... they are seperate DD statements

The generations will be like +1, +2, +3 etc.. until +13

sijayapal · New User Joined: 23 Dec 2008 Posts: 69 Location: India

Craq Giegerich · Posted: Wed Aug 10, 2011 8:49 pm

dick scherrer · Posted: Thu Aug 11, 2011 1:30 am

Hello,

If you are unwilling to post the requested info, we should delete this topic.

All you have done is waste everyone's time so far.

You have been part of the forum long enough to know how questions/problems should be posted. . .

Bill Woodger · Posted: Thu Aug 11, 2011 5:32 am

Sija,

Why do you want to use a GDG for 13 output files from the same program? Sounds like a nightmare to manage or understand. Once each generation is created (if it works) how are you going to know which selection of data is on which specific dataset? And how are you going to know after 20 days of production runs? How are you going to know which group of 13 datasets are in a "set" to be processed together. I hope you are not going to just code -1, -2, -3 etc and just hope that it all matches up. You are going to "use up" your GDG 13 times faster than "normal". What benefit do you see this approach giving you? I can't think of one yet.

If you believe your program is working then you must assume the GDG approach you are using is messing up somehow. Why don't you try to run the program with 13 uniquely-named output files and see what results you get?

If you are then still confused by the output, we need to see JCL and program code, nicely formatted (use the Code button to preserve formatting in a post, use Preview to check it looks OK).

dick scherrer · Posted: Thu Aug 11, 2011 9:47 am

Hello,

How is the gdg defined?

Why has the jcl not yet been posted?

Who approved of creating al of these generatons in a single job or step

I asked a few of the folks i currently and called a few i previously worked with and they all said such would never be allowed to run in Production.

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

Without commenting on why you want to do this, strictly as a COBOL/JCL puzzle to be figured out...

Check to make sure that each FD is being opened only once, and closed only once. Reopening the FD will basically erase the file.

Check to make sure the each file is actually being cataloged/(rolled in) after the step runs. You might be seeing the results of 'not cataloged' errors.

Check each file to make sure it's allocation is not 0/0. That might point to a JCL typo. If you have an open statement on a non-existent DD, some shops will allocate a temporary dataset to it. (I think it's Stop X-37 that does that here). After the step runs, the file you think you wrote to is empty, because it got cataloged, but the temp dataset is gone.