IBM MAINFRAME: how to avoid a "data set not found"
how to avoid a "data set not found"
Posted: Fri Dec 18, 2009 5:36 pm Post subject: how to avoid a "data set not found"
I have a cobol program that reads a data-set that sometimes hasn't yet been created when the program runs.
the data-set is not that important.
in this case, the program should simply go on with no damage for the application.
when a steps starts and it references a data-set that doesn't exist, the job abends promptly.
the data-set doens't have to be effectiveley used by the program. the job abends before the data-set is opened by the program.
is it possible to cause Z/OS only to check the data-set existence when my program issues an OPEN command, please?
Does it issue an ABEND or does it fail with a JCL error.
Basically, IMHO, what this comes down to is just plain poor planning and implementation. Is it really that difficult to write JCL that you know will work for at least 99% of the time because the files that are required are actually available.
this is a very particular case.
is there a jcl parameter - like free=close, defer and so on - that would make ZOS only check the data-set existence when I open the file?
expecting him to know the definition and proper user of two terms: ABEND and JCL error?
you must think santa clause is just around the corner.
IEF212I J948JT61 EVTPTST6 ARQA - DATA SET NOT FOUND.
the job is critical and can't be postponed.
i'd like to dynamically check if the file exists.
if it doesn't, i wouldn't use (open, read, close) the file and this way the abend would be avoided.
my problem is: even if I don't open the file, ZOS checks it's existence and abends the job.
what I need is to say to ZOS "don't check the file existence until I open the file".
jctgf: you could dynamically allocate the file using BPXWDYN in your COBOL program so there would not be a DD statement for the file. How to do so has been extensively covered in other topics so if you search this forum for BPXWDYN you can find everything you need to use it.
From an operational point of view that suggestion is way out of line. Us support jockeys like to know what file gets used where, and let's face it allowing developers to go around using dynamic allocation uncontrolled is a bit like letting the loonies run the asylum.
The support people need to know exactly what is going on to resolve abends etc. etc.
If some idiot changes the files used in a program at least with the correct DD statements in place we stand half a chance of knowing what is going on when things go belly up.
That is the whole theory behind a well planned and implemented application, so that critical jobs do not get delayed because of stupid problems.
I suppose that you could always have an IEFBR14 as the first step of the job with a DD statement for every file that needs to exist, and if it does it ignores it and if it doesn't it creates it.
Certainly a workaround, but definitely no substitution for correct implementation.
if it is so critical, why does it reference a dataset, that apparently does not have to exist?
Probably you could add a JCL step to determine if the dataset exists and based upon the return code, you can execute the COBOL step with the "created" file or a similar dummy file.
You may have to allocate a new dummy file though.
This may not fix the breaks, it sure can make the horn louder.
"You don'ta fool me - there'sa no sucha thing as a sanity clause! - Chico"
I believe that the thread starter must be support personnel, and he is experiencing the perils of a bad developer,Apparently many prod. support guys get to be in this position, I don't think its fair to use the F word to this guy.
Sorry Expat, I did not read your reply completely before posting the LISTCAT approach.
That is the reason why I insist on a correct and thorough operational acceptance procedure whenever I have set up a support area. Things are tested and tested and tested and various scenarios are catered for before anything new or changed is ever put anywhere near a production environment.
It is usually the support jockeys that are responsible for operational acceptance and if they do not do their job properly they have no one else to blame.
So we have no idea whats going in. OPS testing cant be offshored cos it incurrs cost.
The system has a primary goal and also provides a secondary functionality: to detect and discard duplicate records sent to be processed.
Discarding duplicate records isn't the system main goal.
This functionality was implemented a few years ago and sort of "caught on". A few problems have been avoided because of this service.
The problem is that this functionality is very expensive and, sometimes, may cause serious delays in the processing.
Recently we had a major delay because the file that makes possible for the system to detect duplicate records wasn't available. The job that maintains this Vsam file abended and a lot of time was taken to have the problem solved.
Meanwhile, other jobs remained in the "waiting schedule" status. Everything came to a complete stop.
It’s a set of complex jobs that run at every 2 hours. Given that the Vsam file was out of service, a huge "traffic jam" was formed.
Every day we have a deadline - or a "dead-hour" - to process a lot of jobs. The entire thing almost failed to be processed in time because – again - the Vsam dataset was unavailable.
The night staff was forced to suppress its use by using asterisks (*) in the main program. The thing then proceeded without having the Vsam file operational.
If they had failed to make the train move forward, a few heads would have rolled for sure.
Taking into account that detecting and discarding duplicate records aren't the primary function of the system, but that it should be done whenever it's possible, we'd like to find a way to make job B, C, D, etc proceed even when job A (the job that maintain the Vsam file) hasn't ended OK.
Job B (C, D, etc) must run uninterruptedly even when the Vsam file doesn't exist. That’s why I'm looking for a way to deal with the "data set no found" ABEND.
What we're doing now is precisely what was suggested in one of the previous replies: we are creating the Vsam file if it doesn't exist at the moment of its use by job B.
It works fine, but it's not an elegant solution. Also, it makes possible for a lot of "experts" to say that we’re lousy workers with lousy solutions.
If I can’t dodge the “data set not found” abend, I would like to read the Vsam file dynamically but I don't know how. I know how to read Sam files dynamically, but don't know how to do the same with Vsam files.
What about putting back thd previous contents if the current attempt to create fails?
Might this be better than not having the data at all?
If it is ok to run without the file and the previous content would not be good, what about defining the file and adding one dummy record so that processing would continue?
So far, i do not see a reason for the file to be "missing".
Possibly i've not understood something. . .
Posted: Mon Dec 21, 2009 5:14 am Post subject: Reply to: how to avoid a "data set not found"
To add on. . .
Suggest that the primary focus be that this is a real production process and not focus on "Discarding duplicate records isn't the system main goal.". . .
IMHO, there is no good reason that this does not run correctly/completely every time.