View previous topic :: View next topic
|
Author |
Message |
Lewish
New User
Joined: 23 Aug 2005 Posts: 2
|
|
|
|
Program normally runs about 15 minutes. When a customer sends a bad input file, the program gets stuck in a loop. The program will run for over an hour, sometimes 2 hours, before someone in operations notices it's been running too long and cancels the job.
I want to be able to display the last customer that the program is processing when it gets stuck in a loop and than cause the program to abend fairly quickly, rather than 1 or 2 hours later.
The only way I know how to do this is to put a TIME limit in the JCL and then code a DISPLAY in the program to display every customer. Then when the time limit is reached, the program will abend and I will know what the last customer was.
However, by that time, I could have a HUGE amount of displays.
Is there a way to set the time limit inside the program so that when the time limit is reached, do one DISPLAY and then ABEND.
Thanks! |
|
Back to top |
|
|
priyesh.agrawal
Senior Member
Joined: 28 Mar 2005 Posts: 1448 Location: Chicago, IL
|
|
|
|
Isn't it a better idea to put some validation checks for the data before processing, rather than running the job with bad data & waiting for TIME Abend.
Regards,
Priyesh. |
|
Back to top |
|
|
Lewish
New User
Joined: 23 Aug 2005 Posts: 2
|
|
|
|
Ideally, yes, coding edits would be the thing to do. However, this is a program written years ago and was originally only designed to handle one customer. Now it handles over 15 customers, each of which would have to have their own individual edits coded. To do this would require writing an new program. Because of limited resources, right now I have to work around the problem. |
|
Back to top |
|
|
mmwife
Super Moderator
Joined: 30 May 2003 Posts: 1592
|
|
|
|
Since I don't know the details of the problem I'll throw out a few ideas:
1) JES has instream cmds that will abend the job when the stated SPOOL limit is exceeded.
2) I'd code a conditional DISPLAY checking for a recurrence of the key of the I/P recs read. Or some suspect field or other.
3) I would try wring the rec just read to an O/P file. After the job is stopped, look at the O/P file. That will tell you (maybe) what rec caused the prob and take it from there. I'd make a file of that rec and DISPLAY until I get dizzy. |
|
Back to top |
|
|
|