Re: Isn't DISP=MOD wonnderful? (was avgrec/avgblk history ?)
Paul, The function where the behavior Ed is referring to is similar to what you might be familiar with in SDSF when you issue PRINT ODSN. On Thu, 6 Jul 2006 15:57:08 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: Paul Gilmartin wrote: Why would anyone welcome a change that merely diminishes function? (Of course I'm free to make a private assessment of your customers' cognitive capacities that you could never utter publicly.) Paul, I accidentally sent an e-mail to the list that was intended to go directly (off-list) to Tom Marchant. I don't really have time right now to provide all of the background you would need to understand how this is used and in what context. Suffice to say that the customers that requested (and gladly received) this enhancement were in no way suffering from diminished cognitive capacity. They knew what they were asking for, we agreed it was a valuable enhancement, and it resulted in no loss of function whatsoever. It has nothing to do with how the DISP= keyword is treated in JCL. -- 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
Re: Isn't DISP=MOD wonnderful? (was avgrec/avgblk history ?)
On Thu, 6 Jul 2006 15:48:50 -0600, Paul Gilmartin [EMAIL PROTECTED] wrote: I deliberately [over]simplified my example. When I wish either to create a new data set, or re-use the existing one, I often use the following to avoid adding a job step: //STEP EXEC PGM=IEBGENER //ALLOC DD DISP=(MOD,CATLG),UNIT=DASD,DSN=...,SPACE=... //SYSUT2DD DISP=OLD,DSN=*.ALLOC,VOL=REF=*.ALLOC,UNIT=DASD Specifying VOL (with a referback) and UNIT permits accessing DSN before it is catalogued. Would similar work for deleting and creating in a single job step: //STEP EXEC PGM=IEBGENER //ALLOC DD DISP=(MOD,DELETE),UNIT=DASD,DSN=...,SPACE=... //SYSUT2DD DISP=OLD,DSN=*.ALLOC,UNIT=DASD ...? I believe the ALLOC data set is uncatalogued before SYSUT2 is catalogued (order of DD statements?). Of course this requires an elegible storage volume in addition to the one used by the ALLOC DD. If responses are vague or contradictory I'll try a test. I don't think so. In an SMS environment I believe the data set is cataloged when it is created. Even if not, you run the risk of trying to allocate it on the same volume. Tom Marchant -- 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
Re: Isn't DISP=MOD wonnderful? (was avgrec/avgblk history ?)
In a recent note, Tom Marchant said: Date: Fri, 7 Jul 2006 08:08:29 -0500 //STEP EXEC PGM=IEBGENER //ALLOC DD DISP=(MOD,DELETE),UNIT=DASD,DSN=...,SPACE=... //SYSUT2DD DISP=OLD,DSN=*.ALLOC,UNIT=DASD ...? I believe the ALLOC data set is uncatalogued before SYSUT2 is catalogued (order of DD statements?). Of course this requires an elegible storage volume in addition to the one used by the ALLOC DD. I don't think so. In an SMS environment I believe the data set is cataloged when it is created. Even if not, you run the risk of trying to allocate it on the same volume. Experiment shows you're correct. It fails except for a non-SMS managed HLQ. I hadn't realized SMS introduced such a restriction. I'm not much concerned about having only a single eligible storage volume. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Isn't DISP=MOD wonnderful? (was avgrec/avgblk history ?)
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
Re: Isn't DISP=MOD wonnderful? (was avgrec/avgblk history ?)
In a recent note, Chris Mason said: Date: Thu, 6 Jul 2006 22:55:44 +0200 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. I deliberately [over]simplified my example. When I wish either to create a new data set, or re-use the existing one, I often use the following to avoid adding a job step: //STEP EXEC PGM=IEBGENER //ALLOC DD DISP=(MOD,CATLG),UNIT=DASD,DSN=...,SPACE=... //SYSUT2DD DISP=OLD,DSN=*.ALLOC,VOL=REF=*.ALLOC,UNIT=DASD Specifying VOL (with a referback) and UNIT permits accessing DSN before it is catalogued. Would similar work for deleting and creating in a single job step: //STEP EXEC PGM=IEBGENER //ALLOC DD DISP=(MOD,DELETE),UNIT=DASD,DSN=...,SPACE=... //SYSUT2DD DISP=OLD,DSN=*.ALLOC,UNIT=DASD ...? I believe the ALLOC data set is uncatalogued before SYSUT2 is catalogued (order of DD statements?). Of course this requires an elegible storage volume in addition to the one used by the ALLOC DD. If responses are vague or contradictory I'll try a test. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: Isn't DISP=MOD wonnderful? (was avgrec/avgblk history ?)
Paul Gilmartin wrote: This change is unwelcome; Not according to our customers! :-) -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Isn't DISP=MOD wonnderful? (was avgrec/avgblk history ?)
In a recent note, Edward Jaffe said: Date: Thu, 6 Jul 2006 15:15:35 -0700 This change is unwelcome; Not according to our customers! :-) Why would anyone welcome a change that merely diminishes function? (Of course I'm free to make a private assessment of your customers' cognitive capacities that you could never utter publicly.) I checked your website; (E)JES is your product; I had been unaware of that (or had forgotten). I'm accustomed to getting a JCL error when I specify DISP=NEW and the data set preexists. Do you avoid this by making Type 1 changes to allocation, or is the DISP=NEW an operand of an (E)JES subcommand rather than a JCL DD statement operand? And does there remain a construct for specifying that the programmer requires a new library, not merely a new member of an existing library? -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: Isn't DISP=MOD wonnderful? (was avgrec/avgblk history ?)
In a recent note, Eric N. Bielefeld said: Date: Thu, 6 Jul 2006 17:28:00 -0500 I think the newer tape drives probably fail a lot less on DISP=MOD. I noticed that when we went from 3420 to 3480 tapes, and again when we converted to 3490s. I'm sure the 3590s are even better. Was the cause ever analyzed? It would have to be something like false detection of a file trailer label, implausible as that seems to me. Hard problem to re-create. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: Isn't DISP=MOD wonnderful? (was avgrec/avgblk history ?)
Paul Gilmartin wrote: Why would anyone welcome a change that merely diminishes function? (Of course I'm free to make a private assessment of your customers' cognitive capacities that you could never utter publicly.) Paul, I accidentally sent an e-mail to the list that was intended to go directly (off-list) to Tom Marchant. I don't really have time right now to provide all of the background you would need to understand how this is used and in what context. Suffice to say that the customers that requested (and gladly received) this enhancement were in no way suffering from diminished cognitive capacity. They knew what they were asking for, we agreed it was a valuable enhancement, and it resulted in no loss of function whatsoever. It has nothing to do with how the DISP= keyword is treated in JCL. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
