Thanks for that. Je suis maintenant convaincu, because of the "UNIT 741F' and "EXCP 1" from SYSUT1 in step PRINT. Cheers, CP
On 09/08/2019 23:44, Jesse 1 Robinson wrote: > I had to do some testing. I cooked up the below JCL to create a temporary > data set with no I/O and pass it to another step for input. I inserted store > class NOVIO because otherwise the data set was created on VIO, which clouded > the issue. Job messages indicate that the data set did get created on DASD > and passed to the second step. > > The important point is that it does not get an I/O error trying to read > garbage. It gets immediate EOF, same as with a cataloged data set: > > IGD101I SMS ALLOCATED TO DDNAME (TEMPFILE) > > DSN (SYS19221.T152903.RA000.TESTALLO.R0475053 ) > > STORCLAS (NOVIO) MGMTCLAS ( ) DATACLAS (STAND1) > > VOL SER NOS= ATMP05 > > IEF142I TESTALLO ALLOC - STEP WAS EXECUTED - COND CODE 0000 > > IGD106I SYS19221.T152903.RA000.TESTALLO.R0475053 PASSED, > DDNAME=TEMPFILE > ... > IGD103I SMS ALLOCATED TO DDNAME SYSUT1 > > IEF142I TESTALLO PRINT - STEP WAS EXECUTED - COND CODE 0000 > > IGD105I SYS19221.T152903.RA000.TESTALLO.R0475053 DELETED, DDNAME=SYSUT1 > > > +------------------------------------------------------------------------------- > | --TIMINGS (MINS.)-- > > | JOBNAME STEPNAME PROCSTEP RC EXCP CONN TCB SRB CLOCK SERV > PG > | TESTALLO PRINT 00 23 10 .00 .00 .0 135 > 0 > | > > | DDNAME UNIT TYPE BLKSIZ EXCP (ONLY NON-ZERO COUNTS LISTED) > > | > > | SYSUT1 741F 3390 18400 1 > > +------------------------------------------------------------------------------- > > > //ALLOC EXEC PGM=IEFBR14 > //TEMPFILE DD SPACE=(CYL,1),DCB=SYS1.PROCLIB,DISP=(,PASS), > // STORCLAS=NOVIO > //* > //* > //PRINT EXEC PGM=IEBGENER > //SYSPRINT DD SYSOUT=* > //SYSIN DD DUMMY > //SYSUT2 DD DUMMY > //SYSUT1 DD DSN=*.ALLOC.TEMPFILE > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of > Seymour J Metz > Sent: Friday, August 9, 2019 8:45 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: CPU time cost of dynamic allocation > > Believe what you want, but the fact is that DISP=NEW for DASD physically > creates a dataset. whether it also writes an EOF depends on how you're > configured. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > ________________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of > CM Poncelet <ponce...@bcs.org.uk> > Sent: Thursday, August 8, 2019 6:52 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: CPU time cost of dynamic allocation > > FWIW I hesitate to believe that PASSED/DELETED implies that the temp datasets > were ever physically created on DASD - unless they were OPENed for OUTPUT > in-between. I think the *physical* alloc happens only on an OPEN DCB with > MACRF=(PM/L). > > Have you tried something like the following with IEFBR14? > > '//WHATEVER DD DISP=(,CATLG), > '// DSN=<whatever>, > '// DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS), > '// SPACE=(CYL,(9999,2000)),VOL=(,,,20) > > The VOL=(,,,20) would give you 320 extents. The SPACE=(CYL,9999) would > hopefully be unable to allocate the primary 9999 CYLs on the first 16 > extents, so would have to allocate the remaining CYLs on second/third/etc. > DASD volumes. An ISPF "3.2" would show on which VOLSERs the dataset had been > allocated. An ISPF "3.4" with "V" (if memory serves), and specifying the > first VOLSER from the "3.2", would then show how much free space and how many > extents were still available on it. If no free space or extents are left on > it, do a "3.4" but now specifying the fully qualified DSN *and* the second > VOLSER from "3.2". > If some of the dataset has been physically allocated on this second DASD > VOLSER, the "3.4" should display it; else, it has not been physically > allocated on this DASD. > > Just my ha'penny. > > > > > On 08/08/2019 20:17, Charles Mills wrote: >> I see >> >> IEF285I SYS19218.T143507.RA000.xxx00114.R0105346 PASSED >> IEF285I SYS19218.T143507.RA000.xxx00114.R0105347 PASSED >> IEF285I SYS19218.T143507.RA000.xxx00114.R0105348 PASSED >> ... >> >> And >> >> IEF285I SYS19218.T143507.RA000.xxx00114.R0105346 DELETED >> IEF285I SYS19218.T143507.RA000.xxx00114.R0105347 DELETED >> IEF285I SYS19218.T143507.RA000.xxx00114.R0105348 DELETED >> ... >> >> So it looks to me like DSCBs were actually created. >> >> Charles >> >> >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of CM Poncelet >> Sent: Wednesday, August 7, 2019 12:34 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: CPU time cost of dynamic allocation >> >> >From years ago, I *think* an IEFBR14 step with DISP=(,CATLG) [or >> (,PASS)] does not physically allocate a dataset on a VOLSER but only >> registers it in the usercat. Have you checked whether it is in the VTOC? > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
