View previous topic :: View next topic
|
Author |
Message |
jctgf Currently Banned Active User
Joined: 04 Nov 2006 Posts: 109
|
|
|
|
Hi,
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.
my problem is:
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?
Thanks. |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8796 Location: Welsh Wales
|
|
|
|
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. |
|
Back to top |
|
|
Escapa
Senior Member
Joined: 16 Feb 2007 Posts: 1399 Location: IL, USA
|
|
|
|
Quote: |
is it possible to cause Z/OS only to check the data-set existence when my program issues an OPEN command, please?
|
Not always what we want is possible... |
|
Back to top |
|
|
jctgf Currently Banned Active User
Joined: 04 Nov 2006 Posts: 109
|
|
|
|
this is a very particular case.
what I mean is:
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?
thanks a lot. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
expat wrote: |
Does it issue an ABEND or does it fail with a JCL error.
|
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. |
|
Back to top |
|
|
jctgf Currently Banned Active User
Joined: 04 Nov 2006 Posts: 109
|
|
|
|
the job abends with:
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".
is it possible, please?
thanks. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
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. |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8796 Location: Welsh Wales
|
|
|
|
Robert Sample wrote: |
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. |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8796 Location: Welsh Wales
|
|
|
|
jctgf wrote: |
the job is critical and can't be postponed. |
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. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
Quote: |
the job is critical and can't be postponed |
if it is so critical, why does it reference a dataset, that apparently does not have to exist?
this FU! |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8796 Location: Welsh Wales
|
|
|
|
dbzTHEdinosauer wrote: |
you must think santa clause is just around the corner.
if it is so critical, why does it reference a dataset, that apparently does not have to exist?
|
Maybe he'll bring a few extra datasets on Christmas day |
|
Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007 Posts: 1744 Location: Tirupur, India
|
|
|
|
Hi,
As a temporary fix,
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.
Code: |
//LSTSDENT EXEC PGM=IDCAMS,COND=(4,LT)
//SYSPRINT DD SYSOUT=A
//SYSIN DD *
LISTCAT ENT('THE CREATED FILE')
/*
// IF LSTSDENT.RC NE 0 THEN
//***************USE A DUMMY INPUT FILE****************
//EXCI EXEC PGM=THE COBOL CODE
//STEPLIB DD DSN=ZX.PROD.COB2LOAD,DISP=SHR
//DCFILE DD DSN=DUMMY FILE,DISP=SHR,
// AMP=('ACCBIAS=SYSTEM')
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
.
.
.
// ENDIF
// IF LSTSDENT.RC = 0 THEN
//***************USE THE ORIGINAL INPUT FILE************
//EXCI EXEC PGM=THE COBOL CODE
//STEPLIB DD DSN=ZX.PROD.COB2LOAD,DISP=SHR
//DCFILE DD DSN=LIVE FILE,DISP=SHR,
// AMP=('ACCBIAS=SYSTEM')
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
.
.
.
// ENDIF |
This may not fix the breaks, it sure can make the horn louder.
Good luck.! |
|
Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006 Posts: 1205 Location: Dublin, Ireland
|
|
|
|
Quote: |
you must think santa clause is just around the corner |
It would seem that, in this case, there's a contract somewhere similar to the one discussed by Groucho & Chico -
Quote: |
"You don'ta fool me - there'sa no sucha thing as a sanity clause! - Chico"
Garry. |
|
|
Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007 Posts: 1744 Location: Tirupur, India
|
|
|
|
Quote: |
if it is so critical, why does it reference a dataset, that apparently does not have to exist?
this FU!
|
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.
Regards, |
|
Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007 Posts: 1744 Location: Tirupur, India
|
|
|
|
Quote: |
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.
|
Sorry Expat, I did not read your reply completely before posting the LISTCAT approach. |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8796 Location: Welsh Wales
|
|
|
|
vasanthz wrote: |
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, |
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. |
|
Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007 Posts: 1744 Location: Tirupur, India
|
|
|
|
Quote: |
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. |
I agree.
But sometimes the operational acceptance testing is performed by a separate team(in our shop its the OPS testing team located onshore, since they require tonnes of equipment for testing). And we (Support jockeys at offshore) get to monitor the "virgin execution" of the job ;) blank
So we have no idea whats going in. OPS testing cant be offshored cos it incurrs cost.
Regards, |
|
Back to top |
|
|
jctgf Currently Banned Active User
Joined: 04 Nov 2006 Posts: 109
|
|
|
|
Hi,
Thanks for the interest.
The situation is the following:
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.
Thanks. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Hello,
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. . . |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
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.
fwiw,
d |
|
Back to top |
|
|
karisurya
New User
Joined: 02 Aug 2007 Posts: 64 Location: Bangalore
|
|
|
|
Hi,
Some time back we have a similar situation where the Dataset may/maynot exist and program should read onlf if the dataset is present and process.
We used the following syntax
Code: |
SELECT OPTIONAL IN-FILE
ASSIGN TO DT.
|
This will ensure the job wont create any problem even if the file is not present.
Hope it helps.
Regards,
Surya |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
|
|
Quote: |
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. |
horse manure
if Yo do not like it, just stop the payments!
You have a lousy/faulty design, You are deep in Mississippi mud(1) , we(2) spend time provide You a solution
and You complain that the solution is not elegant by your taste...
it has already beed ascertained that...
the current design is ... lousy
the current solution is ... lousy
because it has been designed/implemented by lousy workers
so what in Gehenna do You want from the people on the forum ??
(1) aka known as that ain't chocolate puddin'!
(2) not me personally but other people have |
|
Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6248 Location: Mumbai, India
|
|
|
|
expat wrote: |
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. |
We've been doing this but if the dasd is sms-managed there will be a valid eof. If the dasd is not sms-managed, the results are unpredictable - someimes a dcb mis-match abend occurs, sometimes incorrect data is read depending on what was on the dasd prior to the new file being allocated, sometmes an eof is processed - and we ended up using an in-house utility. |
|
Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007 Posts: 1744 Location: Tirupur, India
|
|
|
|
Quote: |
We've been doing this but if the dasd is sms-managed there will be a valid eof |
Hi,
why not use IDCAMS LISTCAT to test the existence. I guess it wont fail. |
|
Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6248 Location: Mumbai, India
|
|
|
|
Well, I just don't know what their process is doing - so won't be able to predict much and actually, would like to "quote" what Enrico has said.
in your (Vasanth) assumption you've assumed, entire process ends the moment program-in-question(P1) is executed or not. What if there are some "dowstream-programs" waiting for the output from P1...add one more IDCAMS step? and then one more...and few more...? |
|
Back to top |
|
|
|