Re: CPU time cost of dynamic allocation
In z/OS 1.12, the original CPITCBTM and CPISRBTM "Initiator" TOTAL CPU times were (finally!) separated into the Init-to-Load "INIT" CPU times (CPITCITM/CPISRITM) for the CPU times prior to LOADTIME, and into "TERM" CPU times (CPITCTTM/CPISRTTM) from the end of your program execution until the last SMF record is written (steps with MANY DD's write MANY SMF 30 subtype 4 records for a single step, and more records at job termination for the last step). This schematic maps the where the CP Engine CPU times in SMF 30-4 Step Termination Records are recorded: FIRST SMFLAST SMF INITTIME ALOCTIME LOADTIME TERMTIME TERMTIME 1->2--34www5 | | | | | |<-DSENQ-->|<-ALOCTM->|<EXECTM>| | | | || | | | || | |I||TTT| | CPITCITM |CPUTCBTM| CPITCTTM | | CPISRITMCPUSRBTM| CPISRTTM | CPUHPTTM CPUIIPTM CPURCTTM Barry -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Tuesday, August 6, 2019 2:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Can you please clarify? Your first sentence seems to say that SVC 99 (or do you mean Initiator) CPU time is in the SMF 30? Can you be more specific? Your last sentence seems to say the opposite? Or ... ? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 12:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation This allocation time can be calculated from SMF type 30. I am sure time is tracked. I am not sure the associated CPU is tracked. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Tuesday, August 6, 2019 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? -- 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
Re: CPU time cost of dynamic allocation
The site is IBM Dallas; neither is installed. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Friday, August 9, 2019 12:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation The last time that I looked, the price for MXG was ridiculously low; if you're already paying for SAS then, imho, getting MXG is a nobrainer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
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 > > IGD106I SYS19221.T152903.RA000.TESTALLO.R0475053 PASSED, > DDNAME=TEMPFILE > ... > IGD103I SMS ALLOCATED TO DDNAME SYSUT1 > > IEF142I TESTALLO PRINT - STEP WAS EXECUTED - COND CODE > > IGD105I SYS19221.T152903.RA000.TESTALLO.R0475053 DELETED, DDNAME=SYSUT1 > > > +--- > | --TIMINGS (MINS.)-- > > | JOBNAME STEPNAME PROCSTEPRC EXCP CONNTCBSRB CLOCK SERV > PG > | TESTALLO PRINT00 23 10.00.00 .0135 > 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=* > //SYSINDD 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 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 on behalf of > CM Poncelet > 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=, > '// DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS), > '// SPACE=(CYL,(,2000)),VOL=(,,,20) > > The VOL=(,,,20) would give you 320 extents. The SPACE=(CYL,) would > hopefully be unable to allocate the primary 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 &qu
Re: CPU time cost of dynamic allocation
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 IGD106I SYS19221.T152903.RA000.TESTALLO.R0475053 PASSED,DDNAME=TEMPFILE ... IGD103I SMS ALLOCATED TO DDNAME SYSUT1 IEF142I TESTALLO PRINT - STEP WAS EXECUTED - COND CODE IGD105I SYS19221.T152903.RA000.TESTALLO.R0475053 DELETED, DDNAME=SYSUT1 +--- | --TIMINGS (MINS.)-- | JOBNAME STEPNAME PROCSTEPRC EXCP CONNTCBSRB CLOCK SERV PG | TESTALLO PRINT00 23 10.00.00 .0135 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=* //SYSINDD 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 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 on behalf of CM Poncelet 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=, '// DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS), '// SPACE=(CYL,(,2000)),VOL=(,,,20) The VOL=(,,,20) would give you 320 extents. The SPACE=(CYL,) would hopefully be unable to allocate the primary 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 &g
Re: CPU time cost of dynamic allocation
The last time that I looked, the price for MXG was ridiculously low; if you're already paying for SAS then, imho, getting MXG is a nobrainer. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Ron Hawkins Sent: Thursday, August 8, 2019 3:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Charles et al. Using the TCB time reported in IEF032 to measure and analyse the net CPU cost of program execution is a bit like a detective investigating a crime without leaving the office. As others have said, there is more than one bucket used to measure the CPU time of a job or step. If you use MXG, then you know that Barry totals all those buckets into the CPUTM variable. Watch a job sit in privileged dispatch status while going through space recovery at allocation for an idea of why TCB time in IEF032 is inadequate. If you don't have MXG (why) or equivalent software, then I suggest you enhance IEFACTRT to provide the information or dig around CBT for an up to date SMF type 30 report program. RON HAWKINS Director, Ipsicsopt Pty Ltd (ACN: 627 705 971) m+61 400029610| t: +1 4085625415 | f: +1 4087912585 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Wednesday, 7 August 2019 02:25 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] CPU time cost of dynamic allocation I have a batch program that does several SVC 99 allocations. They are fairly vanilla temporary dataset allocations, or at least that is how I think of them. I am seeing a CPU time of about .0025 CPU seconds per allocation on a z196. Is this what others would expect, or does it seem high? OTOH I have an IEFBR14 batch job on the same machine that allocates 15 temporary datasets in JCL. The entire job lock, stock and barrel uses (according to IEF032I) .00 CPU seconds. Can anyone explain why JCL allocation is apparently much more CPU efficient than SVC 99 allocation? Charles -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 on behalf of CM Poncelet 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=, '// DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS), '// SPACE=(CYL,(,2000)),VOL=(,,,20) The VOL=(,,,20) would give you 320 extents. The SPACE=(CYL,) would hopefully be unable to allocate the primary 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
> My argument was that datasets allocated via IEFBR14 are not *physically* > allocated on DASD What is I/O to the VTOC and VTOCIX, chopped liver? That's as physical as it gets. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of CM Poncelet Sent: Thursday, August 8, 2019 9:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation I mentioned "temp datasets" because Charles' post referred to them as such: 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 Meanwhile, yes, they (as temp datasets) are not actually catalogued - but are "PASSED" via the JFCB or JFCBX, or whatever similar else, to subsequent JCL steps. My argument was that datasets allocated via IEFBR14 are not *physically* allocated on DASD - and that this could be checked as per the example JCL and then cross-checked (after the IEFBR14) via ISPF "3.2" and "3.4". Yes, I did suggestDSORG=PS in my example JCL "// DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS)" OPENing such a dataset for READ (rather than WRITE) would probably hit an abend as well as, if not before, hitting the EODAD. HTH Cheers, Chris Poncelet (retired sysprog) On 09/08/2019 00:30, Paul Gilmartin wrote: > On Thu, 8 Aug 2019 23:52:25 +0100, CM Poncelet wrote: > >> 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), >> '//... > I don't believe temp data sets can be catalogued. > > I'd consider the proof to be whether the data set can be OPENed in a > later step. I'd expect a READ to enter EODAD instantly. > > Specifying DSORG=PS might make a difference. > > -- gil > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
AFAIK the writing of an EOF in allocation is still a parmlib option and only occurs for SMS managed data sets. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Jesse 1 Robinson Sent: Friday, August 9, 2019 12:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Once upon a memorable time, a data set allocated in (say) an IEFRB14 step got a DSCB created complete with whatever DCB attributes were specified in JCL. However, the 'data' on disk had no actual format, so opening the data set would get some kind of I/O error. Unless, perhaps, the data on the track had previously been written by a real program, in which case the data would be 'readable' even though it was leftover garbage. So it was customary for an application to create a new empty data set with something like IEBGENER using dummy input just so that a later read operation on the empty file would get immediate EOF without error. Then MVS was changed to simulate an OPEN/CLOSE on a new allocation so that a later read would get immediate EOF. We don't even think about it today, but applications are simpler and less error prone without having to worry about the format of a newly allocated data set. . . 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 On Behalf Of CM Poncelet Sent: Thursday, August 8, 2019 6:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: CPU time cost of dynamic allocation I mentioned "temp datasets" because Charles' post referred to them as such: 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 Meanwhile, yes, they (as temp datasets) are not actually catalogued - but are "PASSED" via the JFCB or JFCBX, or whatever similar else, to subsequent JCL steps. My argument was that datasets allocated via IEFBR14 are not *physically* allocated on DASD - and that this could be checked as per the example JCL and then cross-checked (after the IEFBR14) via ISPF "3.2" and "3.4". Yes, I did suggestDSORG=PS in my example JCL "// DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS)" OPENing such a dataset for READ (rather than WRITE) would probably hit an abend as well as, if not before, hitting the EODAD. HTH Cheers, Chris Poncelet (retired sysprog) On 09/08/2019 00:30, Paul Gilmartin wrote: > On Thu, 8 Aug 2019 23:52:25 +0100, CM Poncelet wrote: > >> 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), >> '//... > I don't believe temp data sets can be catalogued. > > I'd consider the proof to be whether the data set can be OPENed in a > later step. I'd expect a READ to enter EODAD instantly. > > Specifying DSORG=PS might make a difference. > > -- gil -- 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
Re: CPU time cost of dynamic allocation
On 2019-08-09 2:08 PM, Jesse 1 Robinson wrote: Then MVS was changed to simulate an OPEN/CLOSE on a new allocation so that a later read would get immediate EOF. My flakey memory says that is only for SMS-managed data sets - or at least that was the case when it was originally brought in. Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
Once upon a memorable time, a data set allocated in (say) an IEFRB14 step got a DSCB created complete with whatever DCB attributes were specified in JCL. However, the 'data' on disk had no actual format, so opening the data set would get some kind of I/O error. Unless, perhaps, the data on the track had previously been written by a real program, in which case the data would be 'readable' even though it was leftover garbage. So it was customary for an application to create a new empty data set with something like IEBGENER using dummy input just so that a later read operation on the empty file would get immediate EOF without error. Then MVS was changed to simulate an OPEN/CLOSE on a new allocation so that a later read would get immediate EOF. We don't even think about it today, but applications are simpler and less error prone without having to worry about the format of a newly allocated data set. . . 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 On Behalf Of CM Poncelet Sent: Thursday, August 8, 2019 6:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: CPU time cost of dynamic allocation I mentioned "temp datasets" because Charles' post referred to them as such: 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 Meanwhile, yes, they (as temp datasets) are not actually catalogued - but are "PASSED" via the JFCB or JFCBX, or whatever similar else, to subsequent JCL steps. My argument was that datasets allocated via IEFBR14 are not *physically* allocated on DASD - and that this could be checked as per the example JCL and then cross-checked (after the IEFBR14) via ISPF "3.2" and "3.4". Yes, I did suggestDSORG=PS in my example JCL "// DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS)" OPENing such a dataset for READ (rather than WRITE) would probably hit an abend as well as, if not before, hitting the EODAD. HTH Cheers, Chris Poncelet (retired sysprog) On 09/08/2019 00:30, Paul Gilmartin wrote: > On Thu, 8 Aug 2019 23:52:25 +0100, CM Poncelet wrote: > >> 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), >> '//... > I don't believe temp data sets can be catalogued. > > I'd consider the proof to be whether the data set can be OPENed in a > later step. I'd expect a READ to enter EODAD instantly. > > Specifying DSORG=PS might make a difference. > > -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
I mentioned "temp datasets" because Charles' post referred to them as such: 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 Meanwhile, yes, they (as temp datasets) are not actually catalogued - but are "PASSED" via the JFCB or JFCBX, or whatever similar else, to subsequent JCL steps. My argument was that datasets allocated via IEFBR14 are not *physically* allocated on DASD - and that this could be checked as per the example JCL and then cross-checked (after the IEFBR14) via ISPF "3.2" and "3.4". Yes, I did suggestDSORG=PS in my example JCL "// DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS)" OPENing such a dataset for READ (rather than WRITE) would probably hit an abend as well as, if not before, hitting the EODAD. HTH Cheers, Chris Poncelet (retired sysprog) On 09/08/2019 00:30, Paul Gilmartin wrote: > On Thu, 8 Aug 2019 23:52:25 +0100, CM Poncelet wrote: > >> 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), >> '//... > I don't believe temp data sets can be catalogued. > > I'd consider the proof to be whether the data set can be OPENed in a > later step. I'd expect a READ to enter EODAD instantly. > > Specifying DSORG=PS might make a difference. > > -- gil > > -- > 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
Re: CPU time cost of dynamic allocation
On Thu, 8 Aug 2019 23:52:25 +0100, CM Poncelet wrote: >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), >'//... I don't believe temp data sets can be catalogued. I'd consider the proof to be whether the data set can be OPENed in a later step. I'd expect a READ to enter EODAD instantly. Specifying DSORG=PS might make a difference. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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=, '// DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS), '// SPACE=(CYL,(,2000)),VOL=(,,,20) The VOL=(,,,20) would give you 320 extents. The SPACE=(CYL,) would hopefully be unable to allocate the primary 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
Re: CPU time cost of dynamic allocation
Charles et al. Using the TCB time reported in IEF032 to measure and analyse the net CPU cost of program execution is a bit like a detective investigating a crime without leaving the office. As others have said, there is more than one bucket used to measure the CPU time of a job or step. If you use MXG, then you know that Barry totals all those buckets into the CPUTM variable. Watch a job sit in privileged dispatch status while going through space recovery at allocation for an idea of why TCB time in IEF032 is inadequate. If you don't have MXG (why) or equivalent software, then I suggest you enhance IEFACTRT to provide the information or dig around CBT for an up to date SMF type 30 report program. RON HAWKINS Director, Ipsicsopt Pty Ltd (ACN: 627 705 971) m+61 400029610| t: +1 4085625415 | f: +1 4087912585 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Wednesday, 7 August 2019 02:25 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] CPU time cost of dynamic allocation I have a batch program that does several SVC 99 allocations. They are fairly vanilla temporary dataset allocations, or at least that is how I think of them. I am seeing a CPU time of about .0025 CPU seconds per allocation on a z196. Is this what others would expect, or does it seem high? OTOH I have an IEFBR14 batch job on the same machine that allocates 15 temporary datasets in JCL. The entire job lock, stock and barrel uses (according to IEF032I) .00 CPU seconds. Can anyone explain why JCL allocation is apparently much more CPU efficient than SVC 99 allocation? Charles -- 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
Re: CPU time cost of dynamic allocation
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
Re: CPU time cost of dynamic allocation
Usually[*], but that doesn't involve checking for a DSCB. [*] If you refer to a migrated non-SMS dataset by UNIT and VOL=SER, then it doesn't test for migrated. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, August 7, 2019 4:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation On Wed, 7 Aug 2019 16:25:52 +, Seymour J Metz wrote: >The Initiator does not check that the data set exists; ... > ... and yet it checks for whether it's migrated. -- gil -- 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
Re: CPU time cost of dynamic allocation
Yes, it doesn't check whether there is a DSCB but it does checked whether the migrated copy exists. Of course, retrieving the migrated copy will create a DSCB. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw Sent: Wednesday, August 7, 2019 5:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Which simply means that if UNIT and VOLUME are not supplied then it looks in the catalog, where it detects a MIGRAT value if the data set is migrated. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: http://secure-web.cisco.com/1yEedku2uCM418Zp79jkIHNVonJF0hEhnXa1-T0E5FZHuleD61gn8PtC9EZBFie8M1IiHtLX8tt_pc2NnbJjoLJcW8o2Nc3tiTjM4rr6URHj5NFiauhnhXJ1cLmwMW-QSpogSVvYytTsuMHb4CLzHEZSHU_ehZUPr90reYS0rIK1ITyCxNPxTeB_JCGseMcVp5rafLzSVytulX3ck2EeLcD9Ilt3I2m9FBhpouzH32XwnQgFO0TzFFSE4iTQLJEm4c3uMF_IOYngLejlvaYNap00ZbunoFjJi3GHPSftTVW_7opK4hiu9089vDyq1nnR8iXN-9nXIt8VuXzJI3E0n_N0Rn5wxel3qedePEjzg9yDOcpND8fzVGy2K-Y36A4Y5pejf99gcR31xSyAQdvSkesM4OLmGdHqGxgQRZkFr1R90yH6OEiL4RgtfBtN28NRG/http%3A%2F%2Fwww.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: 07 August 2019 21:15 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] CPU time cost of dynamic allocation On Wed, 7 Aug 2019 16:25:52 +, Seymour J Metz wrote: >The Initiator does not check that the data set exists; ... > ... and yet it checks for whether it's migrated. -- gil -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
FWIW, my usage involves no check for existence. I am allocating new, temporary, non-passed datasets. I'm going to check my SVC 99 to make sure there are no unnecessary text units specified. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lennie Dymoke-Bradshaw Sent: Wednesday, August 7, 2019 5:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Which simply means that if UNIT and VOLUME are not supplied then it looks in the catalog, where it detects a MIGRAT value if the data set is migrated. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: 07 August 2019 21:15 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] CPU time cost of dynamic allocation On Wed, 7 Aug 2019 16:25:52 +, Seymour J Metz wrote: >The Initiator does not check that the data set exists; ... > ... and yet it checks for whether it's migrated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
Which simply means that if UNIT and VOLUME are not supplied then it looks in the catalog, where it detects a MIGRAT value if the data set is migrated. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: 07 August 2019 21:15 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] CPU time cost of dynamic allocation On Wed, 7 Aug 2019 16:25:52 +, Seymour J Metz wrote: >The Initiator does not check that the data set exists; ... > ... and yet it checks for whether it's migrated. -- gil -- 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
Re: CPU time cost of dynamic allocation
On Wed, 7 Aug 2019 16:25:52 +, Seymour J Metz wrote: >The Initiator does not check that the data set exists; ... > ... and yet it checks for whether it's migrated. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
Data sets on tape are created by OPEN. For that matter, allocation does no I/O for card punches, paper tape punches or printers; if you have the first two that is TMI. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of David Spiegel Sent: Wednesday, August 7, 2019 1:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation That's true for DASD, but, not for Tape, IIRC. On 2019-08-07 12:53, Seymour J Metz wrote: > They say that the memory is the second thing to go (I don't remember the > first.) IEFBR14 with DDDISP=(,PASS) or DISP=(,CATLG) does allocate a new data > set. there would be much wailing and gnashing of teeth if it stopped doing > that. > > > -- > Shmuel (Seymour J.) Metz > https://nam02.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3&data=02%7C01%7C%7Cbf913ac8c88544d06ac908d71b57cd5c%7C84df9e7fe9f640afb435%7C1%7C0%7C637007936258345512&sdata=VvGKdsg2Spkk4Kq0WeVM3amVpcusMCi8yL%2BZEPkXYNw%3D&reserved=0 > > > From: IBM Mainframe Discussion List 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? > > Chris Poncelet (retired sysprog) > > > > On 06/08/2019 20:38, Charles Mills wrote: >> FWIW I tried adding DISP=(,PASS) to all of the DDs and adding another (BR14 >> also) step. No difference in the step CPU time -- still 0.00 seconds. >> >> Of course, one could play guessing games all day. Is the Initiator smart >> enough to know the whole job is one big no-op? I would guess not, but who >> knows. >> >> Charles >> >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Paul Gilmartin >> Sent: Tuesday, August 6, 2019 12:45 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: CPU time cost of dynamic allocation >> >> On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: >>> OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >>> temporary datasets in JCL. The entire job lock, stock and barrel uses >>> (according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >>> allocation is apparently much more CPU efficient than SVC 99 allocation? >>> >> Nowadays, z/OS performs some special optimization for IEFBR14 (it knows >> it's not going to use those data sets anyway.) Might that come into play >> here? >> >> -- >> 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 > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
That's true for DASD, but, not for Tape, IIRC. On 2019-08-07 12:53, Seymour J Metz wrote: > They say that the memory is the second thing to go (I don't remember the > first.) IEFBR14 with DDDISP=(,PASS) or DISP=(,CATLG) does allocate a new data > set. there would be much wailing and gnashing of teeth if it stopped doing > that. > > > -- > Shmuel (Seymour J.) Metz > https://nam02.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3&data=02%7C01%7C%7Cbf913ac8c88544d06ac908d71b57cd5c%7C84df9e7fe9f640afb435%7C1%7C0%7C637007936258345512&sdata=VvGKdsg2Spkk4Kq0WeVM3amVpcusMCi8yL%2BZEPkXYNw%3D&reserved=0 > > > From: IBM Mainframe Discussion List 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? > > Chris Poncelet (retired sysprog) > > > > On 06/08/2019 20:38, Charles Mills wrote: >> FWIW I tried adding DISP=(,PASS) to all of the DDs and adding another (BR14 >> also) step. No difference in the step CPU time -- still 0.00 seconds. >> >> Of course, one could play guessing games all day. Is the Initiator smart >> enough to know the whole job is one big no-op? I would guess not, but who >> knows. >> >> Charles >> >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Paul Gilmartin >> Sent: Tuesday, August 6, 2019 12:45 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: CPU time cost of dynamic allocation >> >> On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: >>> OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >>> temporary datasets in JCL. The entire job lock, stock and barrel uses >>> (according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >>> allocation is apparently much more CPU efficient than SVC 99 allocation? >>> >> Nowadays, z/OS performs some special optimization for IEFBR14 (it knows >> it's not going to use those data sets anyway.) Might that come into play >> here? >> >> -- >> 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 > > -- > 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
Re: CPU time cost of dynamic allocation
They say that the memory is the second thing to go (I don't remember the first.) IEFBR14 with DDDISP=(,PASS) or DISP=(,CATLG) does allocate a new data set. there would be much wailing and gnashing of teeth if it stopped doing that. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List 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? Chris Poncelet (retired sysprog) On 06/08/2019 20:38, Charles Mills wrote: > FWIW I tried adding DISP=(,PASS) to all of the DDs and adding another (BR14 > also) step. No difference in the step CPU time -- still 0.00 seconds. > > Of course, one could play guessing games all day. Is the Initiator smart > enough to know the whole job is one big no-op? I would guess not, but who > knows. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Tuesday, August 6, 2019 12:45 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: CPU time cost of dynamic allocation > > On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: >> OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >> temporary datasets in JCL. The entire job lock, stock and barrel uses >> (according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >> allocation is apparently much more CPU efficient than SVC 99 allocation? >> > Nowadays, z/OS performs some special optimization for IEFBR14 (it knows > it's not going to use those data sets anyway.) Might that come into play > here? > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
On 2019-08-07 6:36 PM, Lennie Dymoke-Bradshaw wrote: However, I think standard TSO ALLOCATE does perform that check Yes, I was probably basing my opinion on my observations of the behaviour of the ALLOCATE command. Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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? Chris Poncelet (retired sysprog) On 06/08/2019 20:38, Charles Mills wrote: > FWIW I tried adding DISP=(,PASS) to all of the DDs and adding another (BR14 > also) step. No difference in the step CPU time -- still 0.00 seconds. > > Of course, one could play guessing games all day. Is the Initiator smart > enough to know the whole job is one big no-op? I would guess not, but who > knows. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Tuesday, August 6, 2019 12:45 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: CPU time cost of dynamic allocation > > On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: >> OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >> temporary datasets in JCL. The entire job lock, stock and barrel uses >> (according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >> allocation is apparently much more CPU efficient than SVC 99 allocation? >> > Nowadays, z/OS performs some special optimization for IEFBR14 (it knows > it's not going to use those data sets anyway.) Might that come into play > here? > > -- > 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
Re: CPU time cost of dynamic allocation
The Initiator does not check that the data set exists; if it did, the documented JCL for various utilities and service aids would not work. As you note, "some of the text units used in dynamic allocation have no equivalent in the DD statement." -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw Sent: Wednesday, August 7, 2019 4:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Greg, I think you'll find that whether SVC 99 checks that a data set exists on disk or not depends on the text units used. If I want the 'does data set exist' check made I usually include the text unit to return data set organisation (DALRTORG). This ensures that the DSCB for the data set is read, thus generating an error if it does not exist. However, if I leave this text unit off the dynamic allocation then I can allocate the equivalent of the DD statement you quoted, and subsequently generate a 213-04 abend at OPEN time. However, I think standard TSO ALLOCATE does perform that check, so perhaps it too uses that same text unit. In my understanding step allocation performs the same checks, based on the DD statement keywords you specify. However, some of the text units used in dynamic allocation have no equivalent in the DD statement. See Table 87 on page 692 in MVS Programming: Authorized Assembler Services Guide - SA23-1371-30 for the z/OS 2.3 version. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: http://secure-web.cisco.com/1i_vkpUB53TjjsdUxdu2Gwz3v0DXmssvECR89JmxSRUaXq-98XQWsx9nTMw3TmF5aC3UyhsWMculDvVK9VLe0U-mO8N6WYdjdylnqJcliTyEGGUx0ztU2hKlB0OOxcTvb7DtQlqigqGnV04fU58YSCrUGiXlb2FQ3seOaKau0zASdREliZF1KxDucvA8Fn7Tpxkt0S_qn5uOZekFbUXl4qWHbhx92UV8qaQojvIhbwTiR2Z4JEJpoZyCvxV-qJUp4KKsP55BqZdmhI1JBMmH7rX1fr2EHC8L7FfyBP3wcGJdL8vUjx5-m-fkP5WQC8UFQ9lsW-8wis1yz2vpmblUqIKTR6OqgKV_i3maORUvruxpbOMGeC_5OQ0AbYUVWLaEzZNoIzquJ-VtJlF6IimnKnH7FPz-A_bLmArJk_BjVBpqQ3zO9OP9dMB_ZdqFn5F9t/http%3A%2F%2Fwww.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Greg Price Sent: 07 August 2019 03:00 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] CPU time cost of dynamic allocation On 2019-08-07 5:08 AM, Carmen Vitullo wrote: > I suspect dynamic allocation may be doing more that the IEFBR14 possibly? Well, DYNALLOC is certainly doing more that the job step initiation when it comes to allocation. Device allocation at step-start time is a largely CPU-bound affair with the only I/O usually being for catalog look-ups. That is why something like //MY DD DD DSN=FRED,DISP=OLD,UNIT=3390,VOL=SER=MYVOL1 will get a S213-04 at OPEN time when FRED does not exist. DYNALLOC will check that FRED exists on the volume - yes! it does "lots" of I/O to the data set's volume which batch device allocation does not perform. Data set name enqueue is done before device allocation, and most of it is done at job start time for data sets mentioned in JCL. DYNALLOC has to do the ENQ when it is called before looking at devices. Cheers, Greg -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
Greg, I think you'll find that whether SVC 99 checks that a data set exists on disk or not depends on the text units used. If I want the 'does data set exist' check made I usually include the text unit to return data set organisation (DALRTORG). This ensures that the DSCB for the data set is read, thus generating an error if it does not exist. However, if I leave this text unit off the dynamic allocation then I can allocate the equivalent of the DD statement you quoted, and subsequently generate a 213-04 abend at OPEN time. However, I think standard TSO ALLOCATE does perform that check, so perhaps it too uses that same text unit. In my understanding step allocation performs the same checks, based on the DD statement keywords you specify. However, some of the text units used in dynamic allocation have no equivalent in the DD statement. See Table 87 on page 692 in MVS Programming: Authorized Assembler Services Guide - SA23-1371-30 for the z/OS 2.3 version. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Greg Price Sent: 07 August 2019 03:00 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] CPU time cost of dynamic allocation On 2019-08-07 5:08 AM, Carmen Vitullo wrote: > I suspect dynamic allocation may be doing more that the IEFBR14 possibly? Well, DYNALLOC is certainly doing more that the job step initiation when it comes to allocation. Device allocation at step-start time is a largely CPU-bound affair with the only I/O usually being for catalog look-ups. That is why something like //MY DD DD DSN=FRED,DISP=OLD,UNIT=3390,VOL=SER=MYVOL1 will get a S213-04 at OPEN time when FRED does not exist. DYNALLOC will check that FRED exists on the volume - yes! it does "lots" of I/O to the data set's volume which batch device allocation does not perform. Data set name enqueue is done before device allocation, and most of it is done at job start time for data sets mentioned in JCL. DYNALLOC has to do the ENQ when it is called before looking at devices. Cheers, Greg -- 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
Re: CPU time cost of dynamic allocation
On 2019-08-07 5:08 AM, Carmen Vitullo wrote: I suspect dynamic allocation may be doing more that the IEFBR14 possibly? Well, DYNALLOC is certainly doing more that the job step initiation when it comes to allocation. Device allocation at step-start time is a largely CPU-bound affair with the only I/O usually being for catalog look-ups. That is why something like //MY DD DD DSN=FRED,DISP=OLD,UNIT=3390,VOL=SER=MYVOL1 will get a S213-04 at OPEN time when FRED does not exist. DYNALLOC will check that FRED exists on the volume - yes! it does "lots" of I/O to the data set's volume which batch device allocation does not perform. Data set name enqueue is done before device allocation, and most of it is done at job start time for data sets mentioned in JCL. DYNALLOC has to do the ENQ when it is called before looking at devices. Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
For the SVC 99, the time as reported by the C library function clock(), documented as Approximates the processor time used by the program, since the beginning of an implementation-defined time period that is related to the program invocation. In other words, it is the CPU time used so far by the program. I suspect it calls TIMEUSED under the covers. For IEF032I IEF032I STEP/BR14/STOP 2019218.1435 CPU: 0 HR 00 MIN 00.00 SECSRB: 0 HR 00 MIN 00.00 SEC VIRT: 4K SYS: 252K EXT:0K SYS:10576K ATB- REAL:20K SLOTS: 0K VIRT- ALLOC: 10M SHRD: 0M Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Tuesday, August 6, 2019 4:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Charles Mills wrote: >I am seeing a CPU time of about .0025 CPU seconds per allocation on a z196. >The entire job lock, stock and barrel uses (according to IEF032I) .00 CPU >seconds. What type of CPU time? SMF30CPT - TCB? SMF30CPS - SRB? SMF30ISB – SRB CPU time for initiator work? SMF30RCT – Region control task CPU time? SMF30ICU_STEP_INIT – Initiator TCB time? ... etc ... Please clarify your observation. Groete / Greetings Elardus Engelbrecht -- 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
Re: CPU time cost of dynamic allocation
Charles Mills wrote: >I am seeing a CPU time of about .0025 CPU seconds per allocation on a z196. >The entire job lock, stock and barrel uses (according to IEF032I) .00 CPU >seconds. What type of CPU time? SMF30CPT - TCB? SMF30CPS - SRB? SMF30ISB – SRB CPU time for initiator work? SMF30RCT – Region control task CPU time? SMF30ICU_STEP_INIT – Initiator TCB time? ... etc ... Please clarify your observation. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
SMF type 30 has a lot more granularity than the message. If you submit an RFE, I advise that you not ask to have all of those data in the message. OTOH, a ew more fileds wouldn't hurt. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Tuesday, August 6, 2019 3:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Thanks. I don't have MXG but I am super familiar with SMF concepts, reading the SMF documentation, "decoding" SMF triplets and so forth. I see the following: 12 C SMF30ICU 4 binary Initiator CPU time under the task control block (TCB), in hundredths of a second. This field is set at step termination. SMF30ICU = SMF30ICU_STEP_INIT (for this step) + SMF30ICU_STEP_TERM (from the previous step) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 3:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation SMF type 30's contain the start and end time of the allocation process for the initiator. I cannot specifically recall whether the CPU time for this process is broken out into a specific bucket, or can be calculated. I you have MXG, Barry Merrill has a lot of doc in this area. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Tuesday, August 6, 2019 2:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Can you please clarify? Your first sentence seems to say that SVC 99 (or do you mean Initiator) CPU time is in the SMF 30? Can you be more specific? Your last sentence seems to say the opposite? Or ... ? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 12:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation This allocation time can be calculated from SMF type 30. I am sure time is tracked. I am not sure the associated CPU is tracked. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Tuesday, August 6, 2019 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- 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...@listser
Re: CPU time cost of dynamic allocation
Got it. Thanks, Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, August 6, 2019 3:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Yes, allocations in your JCL are done in the Initiator. The IEF032I message n your job has CPU time for your jobstep. There may also be an IEF032I for the Initiator, but the CPU time would be for all of the jobs that the Initiator had handled before shutting down. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
FWIW I tried adding DISP=(,PASS) to all of the DDs and adding another (BR14 also) step. No difference in the step CPU time -- still 0.00 seconds. Of course, one could play guessing games all day. Is the Initiator smart enough to know the whole job is one big no-op? I would guess not, but who knows. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, August 6, 2019 12:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? > Nowadays, z/OS performs some special optimization for IEFBR14 (it knows it's not going to use those data sets anyway.) Might that come into play here? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
Yes, allocations in your JCL are done in the Initiator. The IEF032I message n your job has CPU time for your jobstep. There may also be an IEF032I for the Initiator, but the CPU time would be for all of the jobs that the Initiator had handled before shutting down. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Tuesday, August 6, 2019 3:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Are you saying -- I am trying to clarify; I don't doubt you -- that the JCL allocations are done by the Initiator, and that time is not included in IEF032I? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, August 6, 2019 12:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation The key word is "apparently". Unless you can track the CPU time used by the Initiator, you have no way to know which is more efficient. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Tuesday, August 6, 2019 12:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CPU time cost of dynamic allocation I have a batch program that does several SVC 99 allocations. They are fairly vanilla temporary dataset allocations, or at least that is how I think of them. I am seeing a CPU time of about .0025 CPU seconds per allocation on a z196. Is this what others would expect, or does it seem high? OTOH I have an IEFBR14 batch job on the same machine that allocates 15 temporary datasets in JCL. The entire job lock, stock and barrel uses (according to IEF032I) .00 CPU seconds. Can anyone explain why JCL allocation is apparently much more CPU efficient than SVC 99 allocation? -- 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
Re: CPU time cost of dynamic allocation
I would have to dig before I can provide a detailed answer. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Tuesday, August 6, 2019 2:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Thanks. I don't have MXG but I am super familiar with SMF concepts, reading the SMF documentation, "decoding" SMF triplets and so forth. I see the following: 12 C SMF30ICU 4 binary Initiator CPU time under the task control block (TCB), in hundredths of a second. This field is set at step termination. SMF30ICU = SMF30ICU_STEP_INIT (for this step) + SMF30ICU_STEP_TERM (from the previous step) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 3:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation SMF type 30's contain the start and end time of the allocation process for the initiator. I cannot specifically recall whether the CPU time for this process is broken out into a specific bucket, or can be calculated. I you have MXG, Barry Merrill has a lot of doc in this area. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Tuesday, August 6, 2019 2:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Can you please clarify? Your first sentence seems to say that SVC 99 (or do you mean Initiator) CPU time is in the SMF 30? Can you be more specific? Your last sentence seems to say the opposite? Or ... ? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 12:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation This allocation time can be calculated from SMF type 30. I am sure time is tracked. I am not sure the associated CPU is tracked. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Tuesday, August 6, 2019 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listser
Re: CPU time cost of dynamic allocation
Thanks. I don't have MXG but I am super familiar with SMF concepts, reading the SMF documentation, "decoding" SMF triplets and so forth. I see the following: 12 C SMF30ICU 4 binary Initiator CPU time under the task control block (TCB), in hundredths of a second. This field is set at step termination. SMF30ICU = SMF30ICU_STEP_INIT (for this step) + SMF30ICU_STEP_TERM (from the previous step) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 3:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation SMF type 30's contain the start and end time of the allocation process for the initiator. I cannot specifically recall whether the CPU time for this process is broken out into a specific bucket, or can be calculated. I you have MXG, Barry Merrill has a lot of doc in this area. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Tuesday, August 6, 2019 2:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Can you please clarify? Your first sentence seems to say that SVC 99 (or do you mean Initiator) CPU time is in the SMF 30? Can you be more specific? Your last sentence seems to say the opposite? Or ... ? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 12:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation This allocation time can be calculated from SMF type 30. I am sure time is tracked. I am not sure the associated CPU is tracked. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Tuesday, August 6, 2019 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- 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
Re: CPU time cost of dynamic allocation
SMF type 30's contain the start and end time of the allocation process for the initiator. I cannot specifically recall whether the CPU time for this process is broken out into a specific bucket, or can be calculated. I you have MXG, Barry Merrill has a lot of doc in this area. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Tuesday, August 6, 2019 2:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Can you please clarify? Your first sentence seems to say that SVC 99 (or do you mean Initiator) CPU time is in the SMF 30? Can you be more specific? Your last sentence seems to say the opposite? Or ... ? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 12:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation This allocation time can be calculated from SMF type 30. I am sure time is tracked. I am not sure the associated CPU is tracked. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Tuesday, August 6, 2019 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
all of those timings, from the jeslog or syslog you see are from the SMF type 30 subtype 4 the IEF032I is prolly, without checking from the IEFACTRT SMF exit, which uses the same SMF record and sub type. I suspect dynamic allocation may be doing more that the IEFBR14 possibly? Carmen Vitullo - Original Message - From: "Charles Mills" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, August 6, 2019 2:02:25 PM Subject: Re: CPU time cost of dynamic allocation Can you please clarify? Your first sentence seems to say that SVC 99 (or do you mean Initiator) CPU time is in the SMF 30? Can you be more specific? Your last sentence seems to say the opposite? Or ... ? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 12:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation This allocation time can be calculated from SMF type 30. I am sure time is tracked. I am not sure the associated CPU is tracked. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Tuesday, August 6, 2019 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? -- 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
Re: CPU time cost of dynamic allocation
Can you please clarify? Your first sentence seems to say that SVC 99 (or do you mean Initiator) CPU time is in the SMF 30? Can you be more specific? Your last sentence seems to say the opposite? Or ... ? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 12:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation This allocation time can be calculated from SMF type 30. I am sure time is tracked. I am not sure the associated CPU is tracked. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Tuesday, August 6, 2019 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
Are you saying -- I am trying to clarify; I don't doubt you -- that the JCL allocations are done by the Initiator, and that time is not included in IEF032I? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, August 6, 2019 12:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation The key word is "apparently". Unless you can track the CPU time used by the Initiator, you have no way to know which is more efficient. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Tuesday, August 6, 2019 12:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CPU time cost of dynamic allocation I have a batch program that does several SVC 99 allocations. They are fairly vanilla temporary dataset allocations, or at least that is how I think of them. I am seeing a CPU time of about .0025 CPU seconds per allocation on a z196. Is this what others would expect, or does it seem high? OTOH I have an IEFBR14 batch job on the same machine that allocates 15 temporary datasets in JCL. The entire job lock, stock and barrel uses (according to IEF032I) .00 CPU seconds. Can anyone explain why JCL allocation is apparently much more CPU efficient than SVC 99 allocation? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
This allocation time can be calculated from SMF type 30. I am sure time is tracked. I am not sure the associated CPU is tracked. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Tuesday, August 6, 2019 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? > Nowadays, z/OS performs some special optimization for IEFBR14 (it knows it's not going to use those data sets anyway.) Might that come into play here? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
Except when it is: //DD1 DD DSN=&FOO,...,DISP=(,PASS) -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, August 6, 2019 12:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? > Nowadays, z/OS performs some special optimization for IEFBR14 (it knows it's not going to use those data sets anyway.) Might that come into play here? -- gil -- 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
Re: CPU time cost of dynamic allocation
On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? > Nowadays, z/OS performs some special optimization for IEFBR14 (it knows it's not going to use those data sets anyway.) Might that come into play here? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
The key word is "apparently". Unless you can track the CPU time used by the Initiator, you have no way to know which is more efficient. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Tuesday, August 6, 2019 12:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CPU time cost of dynamic allocation I have a batch program that does several SVC 99 allocations. They are fairly vanilla temporary dataset allocations, or at least that is how I think of them. I am seeing a CPU time of about .0025 CPU seconds per allocation on a z196. Is this what others would expect, or does it seem high? OTOH I have an IEFBR14 batch job on the same machine that allocates 15 temporary datasets in JCL. The entire job lock, stock and barrel uses (according to IEF032I) .00 CPU seconds. Can anyone explain why JCL allocation is apparently much more CPU efficient than SVC 99 allocation? Charles -- 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
CPU time cost of dynamic allocation
I have a batch program that does several SVC 99 allocations. They are fairly vanilla temporary dataset allocations, or at least that is how I think of them. I am seeing a CPU time of about .0025 CPU seconds per allocation on a z196. Is this what others would expect, or does it seem high? OTOH I have an IEFBR14 batch job on the same machine that allocates 15 temporary datasets in JCL. The entire job lock, stock and barrel uses (according to IEF032I) .00 CPU seconds. Can anyone explain why JCL allocation is apparently much more CPU efficient than SVC 99 allocation? Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
