Paul, I'm taking up Charles's challenge to spawn a new thread concerning DISP=MOD but your contribution is closer to the point on which I wanted to comment.
I used to use DISP=(MOD,DELETE) with PGM=IEFBR14 in typically the first job step in order to dispose of a previous instance of a data set which may or may not exist. I then allocated the data set in the following step with DISP=OLD. I used to do this for data sets which may or may not be used in that job step and so the allocation was a small primary, say, 1 track, and a large secondary, say 50 tracks with RLSE added for tidiness. There is an apparent problem with this technique in that it might convert a started task procedure with one step into one with multiple steps. This brings us to SYST. Back in February, I asked about the consequences of removing SYST from a SCHEDxx entry which might have been mandated by a product install. Would removing it create a situation incompatible with running in production? I had been doing it for years on test systems without evident ill effect. Naturally TIME=1440 needs to be added to the EXEC statement but was that really all? After a number of responses that did indeed seem to be the case. Thus, if you want to use a DISP=MOD "trick" and that creates the need to add a job step to a started task procedure, you can always remove SYST in the SCHEDxx member if present for your program while at the same time ensuring that TIME=1440 to the EXEC statement. Going back to whether or not the data set exists, it may be that, if a dump is taken, it is printed off and that job deletes the data set as something just using precious space that is no longer needed. There may be other reasons why such essentially temporary data sets may or may not be left lying around. I have some lecture notes where I describe this for a VTAM/NET started task procedure so I may as well provide them as an example of what I was talking about above: //NET PROC //* //IEFBR14 EXEC PGM=IEFBR14 //NCPDUMP DD DSN=USER.NCPDUMP,DISP=(MOD,DELETE), // VOL=REF=SYS1.PARMLIB,SPACE=(TRK,1) //* //NET EXEC PGM=ISTINM01,TIME=1440 //STEPLIB DD DSN=SYS1.SSPLIB,DISP=SHR //VTAMLST DD DSN=USER.VTAMLST,DISP=SHR //VTAMLIB DD DSN=USER.VTAMLIB,DISP=SHR // DD DSN=SYS1.VTAMLIB,DISP=SHR //NCPLOAD DD DSN=USER.NCPLOAD,DISP=SHR //NCPDUMP DD DSN=USER.NCPDUMP,DISP=(NEW,KEEP), // VOL=REF=SYS1.PARMLIB,SPACE=(TRK,(1,50),RLSE), // DCB=(RECFM=F,LRECL=512,BLKSIZE=512) I see this is very old since I seem not to have updated it for a possibly larger NCP dump record size - just in case anyone wanted to mention that point. Another point about my example is that it is oriented to a started task procedure which is started in the morning and closed down sometime in the evening - which, certainly for VTAM, aligns it with rather outdated concepts for running systems - again just in case that thought was bothering anyone reading this. Chris Mason ----- Original Message ----- From: "Paul Gilmartin" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <IBM-MAIN@BAMA.UA.EDU> Sent: Thursday, 06 July, 2006 8:39 PM Subject: Re: avgrec/avgblk history ? <snip> > > That said, my most frequent uses of MOD are for its collateral effects: > > o Conditionally create a data set in an IEFBR14 step with DISP=(MOD,CATLG), > then write it in a subsequent step with DISP=OLD. > > o Conditionally delete a data set with DISP=(MOD,DELETE). > <snip> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
