MVSFORUMS.com

[THRIVIKRAM]

Hi All,

I have a batch job that executes 24/6. It writes out into error GDG file for those records discarded. Problem is, since this job runs continuously the error file is filled up on the second day (approximately) and the job is getting down. Is there a way to avoid this and write to the next generation as soon as the current GDG version is filled up. I already tried increasing the space in job but it did not work as more space is needed. Since this is a new project, we are not sure of the approximate errors that the job creates daily.

Thanks!!

[taltyman]

Do you need the error file for later processing or just to see what errors are occuring? Maybe just send it to sysout instead of a dataset.

[THRIVIKRAM]

I need the Error file for later analysing what went wrong. I can try writing into Sysout, but that would be huge too...

[Bill Dennis]

The program would need to be intelligent enough to CLOSE and reOPEN the file to create a new generation.

A better solution would be to write the GDG file to tape where size is not a problem. Be sure to specify a volume count in the JCL if the file will be over 5 volumes.

[jyoung]

What if you determined the maximum number of records that the file can hold then keep a record count of the records written and when the get close to the maximum close the file and reopen a new one.

[dbzTHEdinosauer]

[expat]

[jyoung]

Ok here is another silly idea...
Define the output file as a sequential file with a disp of old. When the job is done kick off another job to offload the data to somewhere - anywhere(FTP?). When you start up the next time it will over write it, but you will have the data from the previous time stored somewhere else.

[dbzTHEdinosauer]

iyoung,

that was a silly idea.

OP never did say what the allocation and dcb parms are. he could be writing a 10,000 byte error record and allocating 1 cylinder.
_________________
Dick Brenholtz
American living in Varel, Germany

[THRIVIKRAM]

[Bill Dennis]

thrivikram,

what about going to tape? can you have a tape drive tied up 24/6?
_________________
Regards,
Bill Dennis

Disclaimer: My comments on this foorum are my own and do not represent the opinions or suggestions of any other person or business entity.

[jsharon1248]

What is the average record size? Please don't guess. Run a HISTOGRM to determine the average. How many records? Seems to me that the space is available whether or not it was requested. If you keep running the job, the records are being written somewhere. Also, post the actual z/OS error messages.

If you can manage to update the programs generating the messages, put a threshold on each message type. Write the individual messages until you hit the threshold. After you hit the threshold, bypass the write, and only generate a message the next time you hit the threshold stating that x number of messages of that type were bypassed.

One other idea. Modify this output file to a rolling log similar to a DBMS. Create an RRDS VSAM file with x number of records. When you get to x, reset the counter to 1 and write over the file from the beginning. Not a perfect solution, but it might buy you some time.

However, by addressing the space issue, you're avoiding the root cause. Why is this process generating so many error messages? Solve that, and you don't need to worry about space.

[Terry_Heinze]

[jgr]

Is this still an issue, THRIVIKRAM? If so, it might be resolvable via a data management exit and SVC 99, but I'd need more information...

[Dibakar]