Re: z/OS V2R5 Will be the Last Release to Include JES3
Like Y2K, this might open up a whole new career opportunity for someone with an itch to move around. HAVE GUN WILL TRAVEL WIRE JAFFE LOS ANGELES . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Tuesday, February 26, 2019 2:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: z/OS V2R5 Will be the Last Release to Include JES3 On 2/26/2019 10:35 AM, Elardus Engelbrecht wrote: > >> There is still much more to do to bring JES2 up to JES3 standard, but >> apparently IBM believes they can get it all done by September 2021... > Hahaha, LOL, I don't believe in such predictions that something will happens > at time X/Y/Z. Usually I take such 'predictions' with a very small pinch of > tasteless salt, but I will remember it and wait at the predicted date/time. Haha! Me too! I've won almost every bet I've ever made on such timelines being overly-optimistic. LOL :-D > Oh, wait, big blue forgot about backward compatibility... In a BIG way! :-\ > I however see, there will be a lot of vendors trying to assisting conversion > to JES2 from JES3. You're right! Among others, I suspect IBM Global Services will try to pretend they actually know how to perform the conversion and charge tremendous sums of money to try to do so! =-O There's plenty of time to get it right. By my calculation, today's announcement gives JES3 only another 10 1/2 years of life before it becomes fully unsupported software. I might be retired by then... ;-) -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS V2R5 Will be the Last Release to Include JES3
On 2/26/2019 10:35 AM, Elardus Engelbrecht wrote: There is still much more to do to bring JES2 up to JES3 standard, but apparently IBM believes they can get it all done by September 2021... Hahaha, LOL, I don't believe in such predictions that something will happens at time X/Y/Z. Usually I take such 'predictions' with a very small pinch of tasteless salt, but I will remember it and wait at the predicted date/time. Haha! Me too! I've won almost every bet I've ever made on such timelines being overly-optimistic. LOL :-D Oh, wait, big blue forgot about backward compatibility... In a BIG way! :-\ I however see, there will be a lot of vendors trying to assisting conversion to JES2 from JES3. You're right! Among others, I suspect IBM Global Services will try to pretend they actually know how to perform the conversion and charge tremendous sums of money to try to do so! =-O There's plenty of time to get it right. By my calculation, today's announcement gives JES3 only another 10 1/2 years of life before it becomes fully unsupported software. I might be retired by then... ;-) -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXF105E
One of the thing that usually bites me is the fact that you have to have the access to ALL of the directories to the path to the directory/file you're trying to get to. On Tue, Feb 26, 2019 at 4:52 PM Lizette Koehler wrote: > Did you check SYSLOG to see if there were any additional messages, for > instance > ICH408I > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List On > Behalf Of > > esst...@juno.com > > Sent: Tuesday, February 26, 2019 2:30 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: BPXF105E > > > > Hi,.I need some help understanding BPXF105EBPXF105E RETURN CODE 007B, > > REASON CODE 05620064 JRDirWriteRequestThe service tried to open a > directory > > for write access.Action: The open service request cannot be processed. > > Correct the name or the open flags and retry the operation . > > Normally I use a standard SMP Receive From Network job. > > At this time we are experiencing some network issues, so receive from > network > > is not possible. > > . > > I was able to download some PTFs (SMPHOLD and SMPPTFIN) to my Windows > work > > station. > > And then FTP those files to a sequential file on z/os. > > . > > I'm trying to use OCOPY to copy these pax files from a sequential file > to my > > personnel omvs home directory. > > What I receive is: > > BPXF105E RETURN CODE 007B, REASON CODE 05620064 . > > . > > //COPYSTEP EXEC PGM=IKJEFT01 > > //OUTDIR DD PATH='/u/pauld01/SMPHOLD/', > > //PATHDISP=(KEEP), > > //PATHOPTS=(OWRONLY) > > //INMVSDD DSN=VENDGHI.SMPHOLD,DISP=OLD > > //SYSTSPRT DD SYSOUT=* > > //SYSTSIN DD * > > OCOPY INDD(INMVS) OUTDD(OUTDIR) BINARY > > . > > . > > An Ideas why I'm failing ? > > . > > Paul > > . > > . > > > > -- > > 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 > -- John Kelly -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXF105E
Did you check SYSLOG to see if there were any additional messages, for instance ICH408I Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > esst...@juno.com > Sent: Tuesday, February 26, 2019 2:30 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: BPXF105E > > Hi,.I need some help understanding BPXF105EBPXF105E RETURN CODE 007B, > REASON CODE 05620064 JRDirWriteRequestThe service tried to open a directory > for write access.Action: The open service request cannot be processed. > Correct the name or the open flags and retry the operation . > Normally I use a standard SMP Receive From Network job. > At this time we are experiencing some network issues, so receive from network > is not possible. > . > I was able to download some PTFs (SMPHOLD and SMPPTFIN) to my Windows work > station. > And then FTP those files to a sequential file on z/os. > . > I'm trying to use OCOPY to copy these pax files from a sequential file to my > personnel omvs home directory. > What I receive is: > BPXF105E RETURN CODE 007B, REASON CODE 05620064 . > . > //COPYSTEP EXEC PGM=IKJEFT01 > //OUTDIR DD PATH='/u/pauld01/SMPHOLD/', > //PATHDISP=(KEEP), > //PATHOPTS=(OWRONLY) > //INMVSDD DSN=VENDGHI.SMPHOLD,DISP=OLD > //SYSTSPRT DD SYSOUT=* > //SYSTSIN DD * > OCOPY INDD(INMVS) OUTDD(OUTDIR) BINARY > . > . > An Ideas why I'm failing ? > . > Paul > . > . > > -- > 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: Source of green zebra paper
As a work/study undergraduate I was in charge of the remote sites around campus. We got a palate of nice green-bar only it was orange from GSA in Anniston for about 15 cents a carton. It was nice paper about 20% linen and could be used in pen-fed plotters. Only problem was it had TOP SECRETpre-printed in the tractor margins. We used it a couple days and then we got a call to bring it all back to the center. The argument was that we could turn it over and print on the clear side. Nope-'send it back or burn it' was the final ruling.In a message dated 2/26/2019 3:11:52 PM Central Standard Time, rob...@prino.org writes: I'll have a look at those URLs, and just to be sure I remeasured them again as 8.5 x 15". And the source? This paper, or what's left of it, which is not much, was collected over the years by my father, working at the IBM Lab in Uithoorn. Looking back now, I can't stand my little sister scribbling hundreds of pages full with her felt-pens... :( -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Source of green zebra paper
Robert, This may be what you're looking for: https://www.labeloutfitters.com/3500-Sheets-14-78-x-8-12-Continuous-Form-Paper-12-Green-Bar-NO-Marginal-Perfs-15-Standard-Weight_p_1936.html --- Jim Stefanik Dallas Vintage Computing Center From: Robert Prins Sent: Tuesday, 26 February 2019 16:11 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Source of green zebra paper On 2019-02-25 02:53, Timothy Sipples wrote: > You could check directly with the paper manufacturers if you haven't already. > Q-Connect, headquartered in Belgium, seems to be one of the biggest OEM > suppliers of "listing paper" in the United Kingdom. Here's their main Web > site: > > https://www.q-connect.com > > and the Web site provides their head office contact details. Challenge and 5 > Star Office are other brands. 5 Star Office might be this one: > > https://www.5stareasyofficesupplies.co.uk > > Challenge I'm having trouble finding. > > You could also ask whether a custom order is possible. That looks like an > unusual size. I don't remember ever seeing 8.5x15, but anything is possible. > 11x15 (11x14 with teardown) I could believe. There's also an 8.5x14 "U.S. > Legal" size paper that might have been a teardown size in continuous > feed/fanfold/listing paper form. Some car rental contract paper seems to be > that size, still. Paper manufacturers can still do pretty much anything, > though, if you navigate back far enough in the supply chain. I'll have a look at those URLs, and just to be sure I remeasured them again as 8.5 x 15". And the source? This paper, or what's left of it, which is not much, was collected over the years by my father, working at the IBM Lab in Uithoorn. Looking back now, I can't stand my little sister scribbling hundreds of pages full with her felt-pens... :( Robert -- Robert AH Prins robert(a)prino(d)org -- 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
BPXF105E
Hi,.I need some help understanding BPXF105EBPXF105E RETURN CODE 007B, REASON CODE 05620064 JRDirWriteRequestThe service tried to open a directory for write access.Action: The open service request cannot be processed. Correct the name or the open flags and retry the operation . Normally I use a standard SMP Receive From Network job. At this time we are experiencing some network issues, so receive from network is not possible. . I was able to download some PTFs (SMPHOLD and SMPPTFIN) to my Windows work station. And then FTP those files to a sequential file on z/os. . I'm trying to use OCOPY to copy these pax files from a sequential file to my personnel omvs home directory. What I receive is: BPXF105E RETURN CODE 007B, REASON CODE 05620064 . . //COPYSTEP EXEC PGM=IKJEFT01 //OUTDIR DD PATH='/u/pauld01/SMPHOLD/', //PATHDISP=(KEEP), //PATHOPTS=(OWRONLY) //INMVSDD DSN=VENDGHI.SMPHOLD,DISP=OLD //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * OCOPY INDD(INMVS) OUTDD(OUTDIR) BINARY . . An Ideas why I'm failing ? . Paul . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Source of green zebra paper
On 2019-02-25 02:53, Timothy Sipples wrote: You could check directly with the paper manufacturers if you haven't already. Q-Connect, headquartered in Belgium, seems to be one of the biggest OEM suppliers of "listing paper" in the United Kingdom. Here's their main Web site: https://www.q-connect.com and the Web site provides their head office contact details. Challenge and 5 Star Office are other brands. 5 Star Office might be this one: https://www.5stareasyofficesupplies.co.uk Challenge I'm having trouble finding. You could also ask whether a custom order is possible. That looks like an unusual size. I don't remember ever seeing 8.5x15, but anything is possible. 11x15 (11x14 with teardown) I could believe. There's also an 8.5x14 "U.S. Legal" size paper that might have been a teardown size in continuous feed/fanfold/listing paper form. Some car rental contract paper seems to be that size, still. Paper manufacturers can still do pretty much anything, though, if you navigate back far enough in the supply chain. I'll have a look at those URLs, and just to be sure I remeasured them again as 8.5 x 15". And the source? This paper, or what's left of it, which is not much, was collected over the years by my father, working at the IBM Lab in Uithoorn. Looking back now, I can't stand my little sister scribbling hundreds of pages full with her felt-pens... :( Robert -- Robert AH Prins robert(a)prino(d)org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS V2R5 Will be the Last Release to Include JES3
Ed Jaffe wrote: >z/OS V2R5 (or whatever it will be called) will be the last release to include >the JES3 feature. IBM justifies that decision in this way: I am feeling for you, you who are really who is one of the serious top-gun JES3 gurus. I remember the ten thousand millions (and still counting) threads in IBM-MAIN about JES3 and comparision and "unification" of JES2 and JES3. >There is still much more to do to bring JES2 up to JES3 standard, but >apparently IBM believes they can get it all done by September 2021... Hahaha, LOL, I don't believe in such predictions that something will happens at time X/Y/Z. Usually I take such 'predictions' with a very small pinch of tasteless salt, but I will remember it and wait at the predicted date/time. Oh, wait, big blue forgot about backward compatibility... I however see, there will be a lot of vendors trying to assisting conversion to JES2 from JES3. Disclaimer: I never ever see or worked with JES3 at all. If I say something about JES3 innards, feel free to disregard it with your great pleasure. ;-) 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 and zIIP
great info, thanks for the link Brian Carmen Vitullo - Original Message - From: "Brian Chapman" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, February 26, 2019 10:14:08 AM Subject: Re: CPU time and zIIP Thanks Peter. Here is the IBM document that I based my assumptions of the SDSF fields. *CPU-Time* Accumulated CPU time consumed by and on behalf of the address space, for the current job step, in seconds. SDSF obtains this value from RMF, as follows: ASCBEJST + ASCBSRBT + ASSBASST (source field R791TCPU) where *ASCBEJST* is elapsed job step time *ASCBSRBT* is accumulated SRB time *ASSBASST* is the CPU time consumed by preemptible class SRBs running on behalf of this address space, in milliseconds *ECPU-Time* Total CPU time consumed by and within the address space, for the current job step, in seconds. SDSF obtains this value from RMF, as follows: ASCBEJST + ASCBSRBT + ASSBPHTM (source field R791TCPC) where *ASCBEJST* is elapsed job step time *ASCBSRBT* is accumulated SRB time *ASSBPHTM* is the CPU time consumed by preemptible class SRBs running in this address space, in milliseconds (threads plus enclaves) https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zosmfsdsf.jobresources.help.doc/izusfhpJobActiveSystemUse.html I assumed since SDSF compartmentalized the zIIP, zAAP, and zICP times that they must not be included in the CPU-Time field. Like Carmen noted, when I add the GCP-Time, zIIP-Time, zAAP-Time, and zICP-Time it does not calculate out to be the same as the CPU-Time or ECPU-Time amount. Thank you, Brian Chapman On Tue, Feb 26, 2019 at 9:21 AM Peter Relson wrote: > If the comment is correct that the SDSF display is using ASCBEJST, then > the statement > "ZIIP is not reported as part of CPU." > is not correct with respect to that display. > > ASCBEJST includes all time, whether standard CP or zIIP. > There are additional fields, such as ASSB_TIME_ON_CP, that do not include > zIIP. > > Fields in SMF records do use ASSB_TIME_ON_CP rather than ASCBEJST. For > those fields, the statement is correct. > > I wasn't sure in what way the OP concluded that zIIP was or was not > included when he wrote "must not be true" and "I'm thinking it is not". > > Peter Relson > z/OS Core Technology Design > > > -- > 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: z/OS V2R5 Will be the Last Release to Include JES3
On 2/26/2019 10:05 AM, Ed Jaffe wrote: There is still much more to do to bring JES2 up to JES3 standard, but apparently IBM believes they can get it all done by September 2021... Correction: by 2023. They could continue to enhance JES2 via continuous delivery right up until the expected delivery of z/OS V2R6 (or whatever it will be called). -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS V2R5 Will be the Last Release to Include JES3
z/OS V2R5 (or whatever it will be called) will be the last release to include the JES3 feature. IBM justifies that decision in this way: "JES2 has added functionality, including dependent job control, deadline scheduling, 8-character job classes, and interpreting JES3 JECL control statements. For z/OS V2.4, additional function to aid in migrations is planned, including Disk Reader capability and enhanced JES3 JECL support in JES2 (ROUTE XEQ). Today, as a result of our strategic investment and ongoing commitment to JES2, as well as continuing to enhance JES3 to JES2 migration aids, IBM is announcing that the release following z/OS V2.4 is planned to be the last release of z/OS that will include JES3 as a feature." There is still much more to do to bring JES2 up to JES3 standard, but apparently IBM believes they can get it all done by September 2021... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.4 Announcement Letter (Preview)
Paul Gilmartin wrote: >RACF<->LDAP bridge? Sorry, but I think you are missing something. There is already such an interface. In fact, one of my clients is using a selfhelp web-portal for many years using a SSL LDAP server in one of my LPARs using RACF as a LDAP Backend. Using a LDAP client, you can download a RACF LDAP schema from LDAP's own OMVS folders supplied by IBM. Of course, I disabled DB2 as a LDAP backend to satisfy my cruel auditors. 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: z/OS 2.4 Announcement Letter (Preview)
On Tue, 26 Feb 2019 11:31:17 -0600, John McKown wrote: >On Tue, Feb 26, 2019 at 11:13 AM Ramiro Camposagrado wrote: > https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=AN=CA=899/ENUSLP19-0013=USN >> >Yummy! Deploy z/Linux Docker containers on z/OS to run on the z/OS image >itself. > KVM? To me, with plenty Linux on other platforms, the chief (practically only) benefit of OMVS has been its close coupling with Classic z/OS (address LINKMVS and address TSO) and accessibility of Classic data sets (//DSN). Some will say ISPF support of z/FS. Will containerized Linux have similar facilities? And access to z/FS? ASCII<->EBCDIC bridge? RACF<->LDAP bridge? Hmmm... Linux, of course, is free. Is the container separately priced? It would be useful if the "continuous delivery" links included summary titles in addition to announcement numbers. >I don't know what the NoSQL VSAMDB is, but that sounds interesting too. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.4 Announcement Letter (Preview)
On Tue, Feb 26, 2019 at 11:13 AM Ramiro Camposagrado < 0218a26c8a45-dmarc-requ...@listserv.ua.edu> wrote: > > https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=AN=CA=899/ENUSLP19-0013=USN > > Yummy! Deploy z/Linux Docker containers on z/OS to run on the z/OS image itself. I don't know what the NoSQL VSAMDB is, but that sounds interesting too. -- I just burned 2000 calories! That's the last time I'll nap with brownies in the oven. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS 2.4 Announcement Letter (Preview)
https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=AN=CA=899/ENUSLP19-0013=USN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.3 Memory Requirements on z14
My response about memory sizes was purely to correct/inform the misinformed folks who were quoting all sorts of numbers for the different Systems and stating what IBM or its marketing folks did/did not do :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time and zIIP
Thanks Peter. Here is the IBM document that I based my assumptions of the SDSF fields. *CPU-Time* Accumulated CPU time consumed by and on behalf of the address space, for the current job step, in seconds. SDSF obtains this value from RMF, as follows: ASCBEJST + ASCBSRBT + ASSBASST (source field R791TCPU) where *ASCBEJST* is elapsed job step time *ASCBSRBT* is accumulated SRB time *ASSBASST* is the CPU time consumed by preemptible class SRBs running on behalf of this address space, in milliseconds *ECPU-Time* Total CPU time consumed by and within the address space, for the current job step, in seconds. SDSF obtains this value from RMF, as follows: ASCBEJST + ASCBSRBT + ASSBPHTM (source field R791TCPC) where *ASCBEJST* is elapsed job step time *ASCBSRBT* is accumulated SRB time *ASSBPHTM* is the CPU time consumed by preemptible class SRBs running in this address space, in milliseconds (threads plus enclaves) https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zosmfsdsf.jobresources.help.doc/izusfhpJobActiveSystemUse.html I assumed since SDSF compartmentalized the zIIP, zAAP, and zICP times that they must not be included in the CPU-Time field. Like Carmen noted, when I add the GCP-Time, zIIP-Time, zAAP-Time, and zICP-Time it does not calculate out to be the same as the CPU-Time or ECPU-Time amount. Thank you, Brian Chapman On Tue, Feb 26, 2019 at 9:21 AM Peter Relson wrote: > If the comment is correct that the SDSF display is using ASCBEJST, then > the statement > "ZIIP is not reported as part of CPU." > is not correct with respect to that display. > > ASCBEJST includes all time, whether standard CP or zIIP. > There are additional fields, such as ASSB_TIME_ON_CP, that do not include > zIIP. > > Fields in SMF records do use ASSB_TIME_ON_CP rather than ASCBEJST. For > those fields, the statement is correct. > > I wasn't sure in what way the OP concluded that zIIP was or was not > included when he wrote "must not be true" and "I'm thinking it is not". > > Peter Relson > z/OS Core Technology Design > > > -- > 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 and zIIP
SDSF uses ERBSMFI for address space CPU-related information and processes the R791ELEM records mapped by ERBSMF79 in SYS1.MACLIB. The ECPU column in SDSF DA is populated from field R791TCPC. The comments in R791TCPC state the formula : ascbejst+ascbsrbt+(assbphtm-assbphtm_base) Rob Scott Rocket Software -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: Tuesday, February 26, 2019 2:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CPU time and zIIP If the comment is correct that the SDSF display is using ASCBEJST, then the statement "ZIIP is not reported as part of CPU." is not correct with respect to that display. ASCBEJST includes all time, whether standard CP or zIIP. There are additional fields, such as ASSB_TIME_ON_CP, that do not include zIIP. Fields in SMF records do use ASSB_TIME_ON_CP rather than ASCBEJST. For those fields, the statement is correct. I wasn't sure in what way the OP concluded that zIIP was or was not included when he wrote "must not be true" and "I'm thinking it is not". Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time and zIIP
I think the OP and prolly most of us non developers make a bad assumption based on what SDSF's help and user guide provides, which is very little. checking the alternate display on SDSF for one of my DB2 subsystems I see CPUtime as 4093.12, GCPUtime is 2187.06 and Ziiptime is 2.17, that's not adding up since all other times, other than accumulated time is zero Carmen Vitullo - Original Message - From: "Peter Relson" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, February 26, 2019 8:20:00 AM Subject: CPU time and zIIP If the comment is correct that the SDSF display is using ASCBEJST, then the statement "ZIIP is not reported as part of CPU." is not correct with respect to that display. ASCBEJST includes all time, whether standard CP or zIIP. There are additional fields, such as ASSB_TIME_ON_CP, that do not include zIIP. Fields in SMF records do use ASSB_TIME_ON_CP rather than ASCBEJST. For those fields, the statement is correct. I wasn't sure in what way the OP concluded that zIIP was or was not included when he wrote "must not be true" and "I'm thinking it is not". Peter Relson z/OS Core Technology Design -- 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 and zIIP
If the comment is correct that the SDSF display is using ASCBEJST, then the statement "ZIIP is not reported as part of CPU." is not correct with respect to that display. ASCBEJST includes all time, whether standard CP or zIIP. There are additional fields, such as ASSB_TIME_ON_CP, that do not include zIIP. Fields in SMF records do use ASSB_TIME_ON_CP rather than ASCBEJST. For those fields, the statement is correct. I wasn't sure in what way the OP concluded that zIIP was or was not included when he wrote "must not be true" and "I'm thinking it is not". Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Identifying and eliminating uncataloged datasets
You would see this on my systems also, because I use indirect catalog for SYSRES datasets, I manage multiple SYSRES's for the PLEX, one active and one for my SMPE env and one I copy maint to, be careful just relying on the vtoc list to delete any SYSx datasets one example and check ieasym for SYSR2 symbolic - when one of my clients software was so large it spilled to a secondary SYSRES I used indirect cataloging that pointed to the secondary SYSRES SYS1.LINKLIB is on my current SYSRES my SMP and a maint volume (sysres) catalog entry is ENCRYPTIONDATA DATA SET ENCRYPTION-(NO) VOLUMES VOLSER** DEVTYPE--X'' FSEQN-- ASSOCIATIONS(NULL) ATTRIBUTES Carmen Vitullo - Original Message - From: "Tony Thigpen" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, February 25, 2019 6:27:49 PM Subject: Identifying and eliminating uncataloged datasets I have inherited a system where nobody bothered to clean-up after themselves. If I do a DITTO VTOC of all the volumes, I can sometimes find 5 or 6 copies of the same dataset, some of which are SYSx.*. I would like to first rename all the uncataloged versions so I can eventually delete them. Does anybody know of a free tool that would help with this process? -- Tony Thigpen -- 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
FW: z/OS 2.3 Memory Requirements on z14
Forgot to add, this is a "soft" requirement implemented in z/OS 2.3. i.e. z/OS will run in < 8GB, but if the LPAR is too small, strange things my happen. -Original Message- From: Allan Staller Sent: Tuesday, February 26, 2019 7:54 AM To: 'IBM Mainframe Discussion List' Subject: RE: z/OS 2.3 Memory Requirements on z14 The storage for the HSA is separate from the "orderable" storage. This has been true for several hardware generations. AFAIK, this memory size if fixed and cannot be changed. This has nothing to do with the OP's question. The OP wanted to know if there was any impact beyond replying to the warning WTOR @ IPL time if the storage allocated to the LPAR was < 8GB. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Parwez Hamid Sent: Monday, February 25, 2019 5:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.3 Memory Requirements on z14 All Z systems have a certain amount of minimum memory for customer use in the base system configuration. In addition to this 'customer' memory there is memory for the HSA - again included in the base configuration. If required, customers can purchase extra memory up to the maximum limit for the System. z14 M/T 3906, Minimum = 256 GB, Standard HSA = 192 GB z14 M/T 3907, Minimum = 64 GB, Standard HSA = 64 GB z13 M/T 2964, Minimum = 64 GB, Standard HSA = 96 GB z13s M/T 2965, Minimum = 64 GB, Standard HSA = 40 GB For other systems, refer to announcement letters or Redbooks. -- 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: Identifying and eliminating uncataloged datasets
IEHIBALL! -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Thigpen Sent: Monday, February 25, 2019 6:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Identifying and eliminating uncataloged datasets I have inherited a system where nobody bothered to clean-up after themselves. If I do a DITTO VTOC of all the volumes, I can sometimes find 5 or 6 copies of the same dataset, some of which are SYSx.*. I would like to first rename all the uncataloged versions so I can eventually delete them. Does anybody know of a free tool that would help with this process? -- Tony Thigpen -- 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: z/OS 2.3 Memory Requirements on z14
The storage for the HSA is separate from the "orderable" storage. This has been true for several hardware generations. AFAIK, this memory size if fixed and cannot be changed. This has nothing to do with the OP's question. The OP wanted to know if there was any impact beyond replying to the warning WTOR @ IPL time if the storage allocated to the LPAR was < 8GB. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Parwez Hamid Sent: Monday, February 25, 2019 5:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.3 Memory Requirements on z14 All Z systems have a certain amount of minimum memory for customer use in the base system configuration. In addition to this 'customer' memory there is memory for the HSA - again included in the base configuration. If required, customers can purchase extra memory up to the maximum limit for the System. z14 M/T 3906, Minimum = 256 GB, Standard HSA = 192 GB z14 M/T 3907, Minimum = 64 GB, Standard HSA = 64 GB z13 M/T 2964, Minimum = 64 GB, Standard HSA = 96 GB z13s M/T 2965, Minimum = 64 GB, Standard HSA = 40 GB For other systems, refer to announcement letters or Redbooks. -- 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: z/OS 2.3 Memory Requirements on z14
Which is interesting when you consider that most (Windows) PCs are single-user machines. Macs, BTW, tend to do well in the 8-16GB of memory range. So, an 8GB (strongly urged) minimum for a massively multi-user machine such as z14 isn't really a lot. And, yes, I know memory usage patterns vary wildly between operating environments. Cheers, Martin Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2 Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: "R.S." To: IBM-MAIN@LISTSERV.UA.EDU Date: 26/02/2019 09:33 Subject:Re: z/OS 2.3 Memory Requirements on z14 Sent by:IBM Mainframe Discussion List W dniu 2019-02-26 o 00:16, Mike Smith pisze: > Not quite. The minimum amount of memory on a z14 ZR1 is 64GB (256GB on the larger z14). > > At first, 64GB sounds like "plenty." But if you are supporting a number of LPARs with small memory allocations, you can use of the 64GB pretty quickly. > Any amount of memory can be divided into "many enough" LPARs just to have memory shortage. IMHO it's simply unreasonable to purchase such expensive machine lika z14 with lack of such inexpensvie resource like memory. 64GB is rich configuration for desktop PC nowadays (mine has 32GB, cause it's standard). -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.3 Memory Requirements on z14
W dniu 2019-02-26 o 00:16, Mike Smith pisze: Not quite. The minimum amount of memory on a z14 ZR1 is 64GB (256GB on the larger z14). At first, 64GB sounds like "plenty." But if you are supporting a number of LPARs with small memory allocations, you can use of the 64GB pretty quickly. Any amount of memory can be divided into "many enough" LPARs just to have memory shortage. IMHO it's simply unreasonable to purchase such expensive machine lika z14 with lack of such inexpensvie resource like memory. 64GB is rich configuration for desktop PC nowadays (mine has 32GB, cause it's standard). -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: z/OS 2.4
Et voila http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/2/877/ENUSZP19-0012/index.html=en_locale=en v2r4 preview - Vignesh Mainframe Infrastructure -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: 21 February 2019 16:13 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: z/OS 2.4 No such plans. CICS/IMS have the same issue as z/OS. Multiple SMPE environments to support for each "product" (4 separate environments for 4 IMS & related products). CICS/IMS will remain separate from z/OS and related products. z/OS and related products will be consolidated from multiple SMPE environments to 1 SMPE environment, based on serverpac orderables. (Compilers, Netview, AO, JAVA,.) -Original Message- From: IBM Mainframe Discussion List On Behalf Of Nims,Alva John (Al) Sent: Thursday, February 21, 2019 10:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.4 My $0.02: Global zone can have it all, but my opinion would be, to use separate Target/DLib zones. Use ZONEINDEX to tie it all together. Al Nims Systems Admin/Programmer III UF Information Technology 720 Bld. 3rd Floor, #9 P.O. Box 112050 Gainesville, FL. 32611 (e) ajn...@ufl.edu (p) (352) 273-1298 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Thursday, February 21, 2019 10:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.4 > Not SREL ? How are you going to put, e.g., MVS and CICS, in the same zone? -- Shmuel (Seymour J.) Metz https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__mason.gmu.edu_-7Esmetz3%26d%3DDwIFAw%26c%3DpZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM%26r%3D0Ef64GJS77DVfhr5GGKZeQ%26m%3D6VJ6cc2xu21HxYeZTub9NOcE8qzldFP27TYi-G7jZog%26s%3DZQsTRv4wJQlXgaaihhBkmAGwP8VFNQKeCcvxEQflJZI%26edata=02%7C01%7Callan.staller%40HCL.COM%7C33a4b19ae72f4b52f8a408d698163165%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636863618452808640sdata=LZ2LSG8WigFdBfpM4pUyRw%2FSGLbWw2ZZF65bHUQF1z0%3Dreserved=0= From: IBM Mainframe Discussion List on behalf of Allan Staller Sent: Thursday, February 21, 2019 10:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.4 Not SREL. Various compenents were installed in their own SMP environments (SMPE/Target/Dlib). -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Thursday, February 21, 2019 9:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.4 How are you going to consolidate zones with different SREL? -- Shmuel (Seymour J.) Metz https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__apac01.safelinks.protection.outlook.com_-3Furl-3Dhttp-3A-252F-252Fmason.gmu.edu-252F-7Esmetz3-26amp-3Bdata-3D02-257C01-257Callan.staller-2540HCL.COM-257C0a1812564531490e2df908d6980dea8e-257C189de737c93a4f5a8b686f4ca9941912-257C0-257C0-257C636863582904219132-26amp-3Bsdata-3DsfZksnSHBPlVKs7fB-252FNH2AsCLdagXgVM5eldmTeD6vk-253D-26amp-3Breserved-3D0%26d%3DDwIFAw%26c%3DpZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM%26r%3D0Ef64GJS77DVfhr5GGKZeQ%26m%3D6VJ6cc2xu21HxYeZTub9NOcE8qzldFP27TYi-G7jZog%26s%3D2e8IuS_K7UgQ9tNuB66-LeIn8gbS0M4U0VvXpa2s1X8%26edata=02%7C01%7Callan.staller%40HCL.COM%7C33a4b19ae72f4b52f8a408d698163165%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636863618452808640sdata=5X7pr%2Fcuka6i5eIHBc0l3drsgSFPQbQIiJxd5q1ryXk%3Dreserved=0= From: IBM Mainframe Discussion List on behalf of Allan Staller Sent: Thursday, February 21, 2019 9:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.4 For historical reasons, I have several SMP/E zones associated w/zOS and other ServerPac available items. I am going to consolidate all of the separate zones associated into a single zone to simplify the maintenance process. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Timothy Sipples Sent: Thursday, February 21, 2019 1:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.4 Allan Staller wrote: >If so, I need to get my 2.3 order in before I can no longer do so. Why not order it now? I can't think of any downside as long as you're already licensed. Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER::
