Re: Serverpac installs January 2022 and beyond - Requests
And therein begins a new line where some company offers services to move small machine workloads to zPDT. Or whatever... - KB ‐‐‐ Original Message ‐‐‐ On Saturday, July 24th, 2021 at 9:51 AM, Brian Westerman wrote: > Did you think to have even ONE of those early sites be one with a small > processor (single CPU) like a low end single CPU z/13, z14 or z15? Most > likely you didn't and that's very sad. A good percentage of "new" clients > that IBM has added over the past 5 to 8 years are in that boat and IBM has > decided to set sail without them. > > I have no doubt that the early customers represented vast swaths of > geographies and industries, but how low did you guys dip to test with a > "small" site. The ones IBM called strategic so that they would not go to Open > Systems and instead go with a small box and z/OS? > > It's very disappointing. Not all of the people IBM is ignoring have access to > large and small boxes like I do, if you have a small box and want to upgrade > after January to 2.5 from say 2.3, they will not be able to do it without > beefing up their machine or coming to someone like us to do it for them. I'm > not complaining about the business that IBM is pushing my way, but I think > it's sad that IBM appears to care very little about the damage (via > frustration) they are about to do. Some will buy an upgraded box, but many > will simply drop their mainframe path in favor of some other direction (away > from z/OS). > > Brian > > On Fri, 23 Jul 2021 15:24:10 -0500, Marna WALLE mwa...@us.ibm.com wrote: > > > Brian, > > > > > > Some of the problem here is that you are telling me what "will" be > > > > there, but I don't have anything that actually shows that or even > > > > implies it for z/OSMF for z/OS. I don't even have the workflows to > > > > verify anything. > > > > For the z/OS Workflows that you haven't seen yet, they are Workflow steps > > that are submitting the same JCL jobs that you used to submit through the > > ISPF interface and should be familiar with today. Meaning, instead of using > > an ISPF panel to submit the job, you will now submit those same jobs from > > the z/OSMF Workflow interface. That is the difference. The jobs remain the > > same, in probably 99.99% of the cases. They are being converted from ISPF > > JCL skeletons (SCPPSENU) to z/OSMF Workflow JCL templates (XML). So yes, > > you haven't seen them in their XML format, but you certainly have seen them > > when they were JCL skeletons. And remember, every single Workflow step JCL > > that is submitted is able to be edited from z/OSMF, just like it was with > > the CustomPac dialog. > > > > Might there be a conversion error to XML? Yes, of course that is possible. > > But that is why we have my second comment below... > > > > > > People won't have much time between Late September and January to > > > > discover and correct all of the bugs. > > > > For each z/OS new release, and V2.5 more than ever, there are early > > customer programs. The release level early program for z/OS V2.5 has its > > main focus on the installation of and upgrade to z/OS V2.5. We understood > > that the installation process would be different and wanted as much > > exposure, testing, and validation in customer environments before it GAs. > > We have early customers that represent many different industries and > > geographies. Each of these customers has installed with a z/OS V2.5 z/OSMF > > ServerPac. Not a single one of them used the old ISPF ServerPac. > > > > -Marna WALLE > > > > z/OS System Install and Upgrade > > > > IBM Poughkeepsie > > > > 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: Serverpac installs January 2022 and beyond - Requests
Did you think to have even ONE of those early sites be one with a small processor (single CPU) like a low end single CPU z/13, z14 or z15? Most likely you didn't and that's very sad. A good percentage of "new" clients that IBM has added over the past 5 to 8 years are in that boat and IBM has decided to set sail without them. I have no doubt that the early customers represented vast swaths of geographies and industries, but how low did you guys dip to test with a "small" site. The ones IBM called strategic so that they would not go to Open Systems and instead go with a small box and z/OS? It's very disappointing. Not all of the people IBM is ignoring have access to large and small boxes like I do, if you have a small box and want to upgrade after January to 2.5 from say 2.3, they will not be able to do it without beefing up their machine or coming to someone like us to do it for them. I'm not complaining about the business that IBM is pushing my way, but I think it's sad that IBM appears to care very little about the damage (via frustration) they are about to do. Some will buy an upgraded box, but many will simply drop their mainframe path in favor of some other direction (away from z/OS). Brian On Fri, 23 Jul 2021 15:24:10 -0500, Marna WALLE wrote: >Brian, >>> Some of the problem here is that you are telling me what "will" be there, >>> but I don't have anything that actually shows that or even implies it for >>> z/OSMF for z/OS. I don't even have the workflows to verify anything. > >For the z/OS Workflows that you haven't seen yet, they are Workflow steps that >are submitting the same JCL jobs that you used to submit through the ISPF >interface and should be familiar with today. Meaning, instead of using an >ISPF panel to submit the job, you will now submit those same jobs from the >z/OSMF Workflow interface. That is the difference. The jobs remain the same, >in probably 99.99% of the cases. They are being converted from ISPF JCL >skeletons (SCPPSENU) to z/OSMF Workflow JCL templates (XML). So yes, you >haven't seen them in their XML format, but you certainly have seen them when >they were JCL skeletons. And remember, every single Workflow step JCL that is >submitted is able to be edited from z/OSMF, just like it was with the >CustomPac dialog. > >Might there be a conversion error to XML? Yes, of course that is possible. >But that is why we have my second comment below... > > >>> People won't have much time between Late September and January to discover >>> and correct all of the bugs. > >For each z/OS new release, and V2.5 more than ever, there are early customer >programs. The release level early program for z/OS V2.5 has its main focus on >the installation of and upgrade to z/OS V2.5. We understood that the >installation process would be different and wanted as much exposure, testing, >and validation in customer environments before it GAs. We have early >customers that represent many different industries and geographies. Each of >these customers has installed with a z/OS V2.5 z/OSMF ServerPac. Not a single >one of them used the old ISPF ServerPac. > >-Marna WALLE >z/OS System Install and Upgrade >IBM Poughkeepsie > >-- >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 processor primer version 3 released
Thank you, thank you, thank you. Please do keep sharing gems like this, and make them easy to find. - KB ‐‐‐ Original Message ‐‐‐ On Saturday, July 24th, 2021 at 3:50 AM, Jim Mulder wrote: > https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/c-kevin-shum/2021/07/23/z-primer-version-3-release > > Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. > > Poughkeepsie NY > > > -- > > 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 processor primer version 3 released
Dr. Shum is the man! If you really want a definitive answer to "what is the fastest way to clear a register?" and everything beyond that, check out his presentation. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Friday, July 23, 2021 3:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z processor primer version 3 released https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/c-kevin-shu m/2021/07/23/z-primer-version-3-release Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -- 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 processor primer version 3 released
This might save some hunting for the document link: https://community.ibm.com/HigherLogic/System/DownloadDocumentFile.ashx?DocumentFileKey=1275a261-ab21-4f8a-b060-5c71880a71fa On 7/23/2021 3:20 PM, Jim Mulder wrote: https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/c-kevin-shum/2021/07/23/z-primer-version-3-release Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -- 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
z processor primer version 3 released
https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/c-kevin-shum/2021/07/23/z-primer-version-3-release Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Serverpac installs January 2022 and beyond - Requests
Brian, >> Some of the problem here is that you are telling me what "will" be there, >> but I don't have anything that actually shows that or even implies it for >> z/OSMF for z/OS. I don't even have the workflows to verify anything. For the z/OS Workflows that you haven't seen yet, they are Workflow steps that are submitting the same JCL jobs that you used to submit through the ISPF interface and should be familiar with today. Meaning, instead of using an ISPF panel to submit the job, you will now submit those same jobs from the z/OSMF Workflow interface. That is the difference. The jobs remain the same, in probably 99.99% of the cases. They are being converted from ISPF JCL skeletons (SCPPSENU) to z/OSMF Workflow JCL templates (XML). So yes, you haven't seen them in their XML format, but you certainly have seen them when they were JCL skeletons. And remember, every single Workflow step JCL that is submitted is able to be edited from z/OSMF, just like it was with the CustomPac dialog. Might there be a conversion error to XML? Yes, of course that is possible. But that is why we have my second comment below... >> People won't have much time between Late September and January to discover >> and correct all of the bugs. For each z/OS new release, and V2.5 more than ever, there are early customer programs. The release level early program for z/OS V2.5 has its main focus on the installation of and upgrade to z/OS V2.5. We understood that the installation process would be different and wanted as much exposure, testing, and validation in customer environments before it GAs. We have early customers that represent many different industries and geographies. Each of these customers has installed with a z/OS V2.5 z/OSMF ServerPac. Not a single one of them used the old ISPF ServerPac. -Marna WALLE z/OS System Install and Upgrade IBM Poughkeepsie -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Serverpac installs January 2022 and beyond - Requests
A USERMOD is overkill. SMP/E parmlib is specified in the JCL, so just create your own and use it. That's what I do. But if you really want to have a usermod, I don't mind. sas On Fri, Jul 23, 2021 at 8:26 AM Richards, Robert B. (CTR) < 01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote: > For SMPWRKx datasets, see SYS1.SAMPLIB(GIMDDALC). Turn it into a usermod: > > ++USERMOD(SMP1K1) REWORK(2021204). > ++VER(Z038) FMID(HMP1K00) . > ++SAMP(GIMDDALC) DISTLIB(ASAMPLIB) . > Contents of GIMDDALC pasted here with your changes. > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GDPS Manuals Link
On Thu, 22 Jul 2021 20:46:46 +, fred glenlake wrote: >I am unsuccessfully trying to locate the hiding spot of the GDPS Manuals for >V4R1 so I can download a few. If anyone can share > the link of where I could download them please. I don't think the GDPS manuals aren't online since they're part of a service offering, not a product, per se. I would open a Case with GDPS to request them. Alan Altmark IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Concatenated datasets
On 7/19/2021 3:43 AM, Mario Bezzi wrote: Greg that's very interesting.. Could you please point me at the doc which explains how to get there? I have been reading the description of the CSVQUERY services, but while I see an OUTPATHNAM option, I can't find anything about the source loadlib for a regular load module. That precise facility is not documented as such... (AFAIK) I'd recommend you get HCL Z Asset Optimizer (aka ZAO) where its Usage Monitor component has done all that work for you. If your site runs IBM Z Software Asset Management then that will also do it. Basically, the plan is to ascertain the DD, and then chase the relevant control blocks to determine the data set name. CSVQUERY OUTPDATA often contains a DD name for load modules, and a pointer of interest for program objects. I don't know what an FMD is, but I imagine it is a Fetched Module Descriptor. Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Serverpac installs January 2022 and beyond - Requests
Nice! thanks Bob Carmen Vitullo -Original Message- From: Robert <01c91f408b9e-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN Date: Friday, 23 July 2021 7:26 AM CDT Subject: Re: Serverpac installs January 2022 and beyond - Requests For SMPWRKx datasets, see SYS1.SAMPLIB(GIMDDALC). Turn it into a usermod: ++USERMOD(SMP1K1) REWORK(2021204). ++VER(Z038) FMID(HMP1K00) . ++SAMP(GIMDDALC) DISTLIB(ASAMPLIB) . Contents of GIMDDALC pasted here with your changes. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Friday, July 23, 2021 8:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Serverpac installs January 2022 and beyond - Requests Barb, how did you get my apply and accept sysouts :) joking aside, these datasets are the same datasets I've always had space issues with or I needed to up the directory size, go thru the pain of allocating a .NEW datasets larger, or with more directories or both, copy the failed library to the new one, rename, delete.rerun only to get a D37 on another dataset :( other issues I've had was the SMPWRKx datasets are ALWAYS under allocated Carmen On 7/23/2021 3:27 AM, Barbara Nitz wrote: >> Its interesting, because I don’t have any products that give me extra >> extents except what SMS does for me space wise, and I have never increased >> my dataset size allocations. > Just as a preparation for increasing allocations, here is what failed x37 in > the past 8 refreshes (all on the *installation* target volume, never IPL'd > from). I apply maintenance twice a year, too, and it is always upwards of > 1000ptfs. SMPE was dealing with a few of those x37 doing in-flight > compresses, but I had only the last refresh without having to increase sizes. > #1 > IEC031I D37-04,IFG0554P,,APPLY,LINKLIB,SYS1.LINKLIB > IEC031I D37-04,IFG0554P,,APPLY,NUCLEUS,SYS1.NUCLEUS > IEC031I D37-04,IFG0554P,,APPLY,SASMMOD1,ASM.SASMMOD1 > IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0 > IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0 > IEC031I D37-04,IFG0554P,,APPLY,SGIMLMD0,GIM.SGIMLMD0 > IEC031I D37-04,IFG0554P,,APPLY,SGIMLMD0,GIM.SGIMLMD0 > IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0 > IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0 > IEC031I D37-04,IFG0554P,,APPLY,SGIMLMD0,GIM.SGIMLMD0 > IEC031I D37-04,IFG0554P,,APPLY,SCEERUN,CEE.SCEERUN > #2 > IEC032I E37-04,IFG0554P,,APPLY,SGIMTENU,GIM.SGIMTENU > IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG > IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG > IEC031I D37-04,IFG0554P,,APPLY,SISFLOAD,ISF.SISFLOAD > IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG > IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG > IOEZ00312I Dynamic growth of aggregate x.SIZUUSRD in progress > #3 > Made an error during increase of data sets, ended up restoring > everything and increasing (joblogs from before restore not saved) > SCBDMENU SMPSTS 16->50 trks, sec 5 > SASMMOD1 50->80 trks > #4 > Accept of previous maintenance: > IEC032I E37-04,IFG0554P,,ACCEPT,ABBLLIB,BBL.ABBLLIB > Apply new: > IEC031I D37-04,IFG0554P,,APPLY,LINKLIB,SYS1.LINKLIB > IEC031I D37-04,IFG0554P,,APPLY,SICELINK,SYS1.SICELINK > #5 > Accept of previous maintenance: > IEC032I E37-04,IFG0554P,,ACCEPT,AGIMTENU,GIM.AGIMTENU > IEC032I E37-04,IFG0554P,,ACCEPT,AERBPWSV,SYS1.AERBPWSV > IEC032I E37-04,IFG0554P,,ACCEPT,AHAPINC3,HAP.AHAPINC3 > IEC032I E37-04,IFG0554P,,ACCEPT,AGIMTENU,GIM.AGIMTENU > Apply new: > IEC032I E37-04,IFG0554P,,APPLY,SERBPWSV,SYS1.SERBPWSV > IEC032I E37-04,IFG0554P,,APPLY,SEEQINST,SYS1.SEEQINST > IEC031I D37-04,IFG0554P,,APPLY,MIGLIB,SYS1.MIGLIB > IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0 > IEC031I D37-04,IFG0554P,,APPLY,SISFLOAD,ISF.SISFLOAD > IEC031I D37-04,IFG0554P,,APPLY,SCEERUN,CEE.SCEERUN > #6 > IEC031I D37-04,IFG0554P,,APPLY,SERBLINK,SYS1.SERBLINK > IEC031I D37-04,IFG0554P,,APPLY,CMDLIB,SYS1.CMDLIB > IEC031I D37-04,IFG0554P,,APPLY,LINKLIB,SYS1.LINKLIB > IEC031I D37-04,IFG0554P,,APPLY,NUCLEUS,SYS1.NUCLEUS > IEC031I D37-04,IFG0554P,,APPLY,SASMMOD1,ASM.SASMMOD1 > #7 > IEC032I E37-04,IFG0554P,,APPLY,SISFTLIB,ISF.SISFTLIB > IEC032I E37-04,IFG0554P,,APPLY,SERBPWSV,SYS1.SERBPWSV > IOEZ00312I Dynamic growth of aggregate x.SAZFAMOD in progress > IEC031I D37-04,IFG0554P,,APPLY,SERBLINK,SYS1.SERBLINK > IEC031I D37-04,IFG0554P,,APPLY,SISFLOAD,ISF.SISFLOAD > IEC032I E37-04,IFG0554P,,APPLY,SCEELPA,CEE.SCEELPA > #8 > Accept of previous maintenance: > IEC032I E37-04,IFG0554P,1,ACCEPT,AGIMTENU,GIM.AGIMTENU > IEC032I E37-04,IFG0554P,1,ACCEPT,AISFTLIB,ISF.AISFTLIB > IEC032I E37-04,IFG0554P,1,ACCEPT,AAZFAMOD,AZF.AAZFAMOD > IEC032I E37-04,IFG0554P,1,ACCEPT,AHAPINC3,HAP.AHAPINC3 > Apply new: > IEC031I D37-04,IFG0554P,,APPLY,DGTLLIB,SYS1.DGTLLIB > > With z/OS 2.5, I'll probably triple allocations for those data sets during > allocation. > >> That being said, my cloning process copies my
Re: Serverpac installs January 2022 and beyond - Requests
For SMPWRKx datasets, see SYS1.SAMPLIB(GIMDDALC). Turn it into a usermod: ++USERMOD(SMP1K1) REWORK(2021204). ++VER(Z038) FMID(HMP1K00) . ++SAMP(GIMDDALC) DISTLIB(ASAMPLIB) . Contents of GIMDDALC pasted here with your changes. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Friday, July 23, 2021 8:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Serverpac installs January 2022 and beyond - Requests Barb, how did you get my apply and accept sysouts :) joking aside, these datasets are the same datasets I've always had space issues with or I needed to up the directory size, go thru the pain of allocating a .NEW datasets larger, or with more directories or both, copy the failed library to the new one, rename, delete.rerun only to get a D37 on another dataset :( other issues I've had was the SMPWRKx datasets are ALWAYS under allocated Carmen On 7/23/2021 3:27 AM, Barbara Nitz wrote: >> Its interesting, because I don’t have any products that give me extra >> extents except what SMS does for me space wise, and I have never increased >> my dataset size allocations. > Just as a preparation for increasing allocations, here is what failed x37 in > the past 8 refreshes (all on the *installation* target volume, never IPL'd > from). I apply maintenance twice a year, too, and it is always upwards of > 1000ptfs. SMPE was dealing with a few of those x37 doing in-flight > compresses, but I had only the last refresh without having to increase sizes. > #1 > IEC031I D37-04,IFG0554P,,APPLY,LINKLIB,SYS1.LINKLIB > IEC031I D37-04,IFG0554P,,APPLY,NUCLEUS,SYS1.NUCLEUS > IEC031I D37-04,IFG0554P,,APPLY,SASMMOD1,ASM.SASMMOD1 > IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0 > IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0 > IEC031I D37-04,IFG0554P,,APPLY,SGIMLMD0,GIM.SGIMLMD0 > IEC031I D37-04,IFG0554P,,APPLY,SGIMLMD0,GIM.SGIMLMD0 > IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0 > IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0 > IEC031I D37-04,IFG0554P,,APPLY,SGIMLMD0,GIM.SGIMLMD0 > IEC031I D37-04,IFG0554P,,APPLY,SCEERUN,CEE.SCEERUN > #2 > IEC032I E37-04,IFG0554P,,APPLY,SGIMTENU,GIM.SGIMTENU > IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG > IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG > IEC031I D37-04,IFG0554P,,APPLY,SISFLOAD,ISF.SISFLOAD > IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG > IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG > IOEZ00312I Dynamic growth of aggregate x.SIZUUSRD in progress > #3 > Made an error during increase of data sets, ended up restoring > everything and increasing (joblogs from before restore not saved) > SCBDMENU SMPSTS 16->50 trks, sec 5 > SASMMOD1 50->80 trks > #4 > Accept of previous maintenance: > IEC032I E37-04,IFG0554P,,ACCEPT,ABBLLIB,BBL.ABBLLIB > Apply new: > IEC031I D37-04,IFG0554P,,APPLY,LINKLIB,SYS1.LINKLIB > IEC031I D37-04,IFG0554P,,APPLY,SICELINK,SYS1.SICELINK > #5 > Accept of previous maintenance: > IEC032I E37-04,IFG0554P,,ACCEPT,AGIMTENU,GIM.AGIMTENU > IEC032I E37-04,IFG0554P,,ACCEPT,AERBPWSV,SYS1.AERBPWSV > IEC032I E37-04,IFG0554P,,ACCEPT,AHAPINC3,HAP.AHAPINC3 > IEC032I E37-04,IFG0554P,,ACCEPT,AGIMTENU,GIM.AGIMTENU > Apply new: > IEC032I E37-04,IFG0554P,,APPLY,SERBPWSV,SYS1.SERBPWSV > IEC032I E37-04,IFG0554P,,APPLY,SEEQINST,SYS1.SEEQINST > IEC031I D37-04,IFG0554P,,APPLY,MIGLIB,SYS1.MIGLIB > IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0 > IEC031I D37-04,IFG0554P,,APPLY,SISFLOAD,ISF.SISFLOAD > IEC031I D37-04,IFG0554P,,APPLY,SCEERUN,CEE.SCEERUN > #6 > IEC031I D37-04,IFG0554P,,APPLY,SERBLINK,SYS1.SERBLINK > IEC031I D37-04,IFG0554P,,APPLY,CMDLIB,SYS1.CMDLIB > IEC031I D37-04,IFG0554P,,APPLY,LINKLIB,SYS1.LINKLIB > IEC031I D37-04,IFG0554P,,APPLY,NUCLEUS,SYS1.NUCLEUS > IEC031I D37-04,IFG0554P,,APPLY,SASMMOD1,ASM.SASMMOD1 > #7 > IEC032I E37-04,IFG0554P,,APPLY,SISFTLIB,ISF.SISFTLIB > IEC032I E37-04,IFG0554P,,APPLY,SERBPWSV,SYS1.SERBPWSV > IOEZ00312I Dynamic growth of aggregate x.SAZFAMOD in progress > IEC031I D37-04,IFG0554P,,APPLY,SERBLINK,SYS1.SERBLINK > IEC031I D37-04,IFG0554P,,APPLY,SISFLOAD,ISF.SISFLOAD > IEC032I E37-04,IFG0554P,,APPLY,SCEELPA,CEE.SCEELPA > #8 > Accept of previous maintenance: > IEC032I E37-04,IFG0554P,1,ACCEPT,AGIMTENU,GIM.AGIMTENU > IEC032I E37-04,IFG0554P,1,ACCEPT,AISFTLIB,ISF.AISFTLIB > IEC032I E37-04,IFG0554P,1,ACCEPT,AAZFAMOD,AZF.AAZFAMOD > IEC032I E37-04,IFG0554P,1,ACCEPT,AHAPINC3,HAP.AHAPINC3 > Apply new: > IEC031I D37-04,IFG0554P,,APPLY,DGTLLIB,SYS1.DGTLLIB > > With z/OS 2.5, I'll probably triple allocations for those data sets during > allocation. > >> That being said, my cloning process copies my res volume and ZFS datasets to >> new volumes and resets extents to current used, which is why I never used >> the software deployment and NEVER will in z/OSMF. > Right now the plan is for my successor to install z/OSMF once we're on 2.5. > *I* will certainly NEVER use z/OSMF to do the rollout to all the other >
Re: Serverpac installs January 2022 and beyond - Requests
Barb, how did you get my apply and accept sysouts :) joking aside, these datasets are the same datasets I've always had space issues with or I needed to up the directory size, go thru the pain of allocating a .NEW datasets larger, or with more directories or both, copy the failed library to the new one, rename, delete.rerun only to get a D37 on another dataset :( other issues I've had was the SMPWRKx datasets are ALWAYS under allocated Carmen On 7/23/2021 3:27 AM, Barbara Nitz wrote: Its interesting, because I don’t have any products that give me extra extents except what SMS does for me space wise, and I have never increased my dataset size allocations. Just as a preparation for increasing allocations, here is what failed x37 in the past 8 refreshes (all on the *installation* target volume, never IPL'd from). I apply maintenance twice a year, too, and it is always upwards of 1000ptfs. SMPE was dealing with a few of those x37 doing in-flight compresses, but I had only the last refresh without having to increase sizes. #1 IEC031I D37-04,IFG0554P,,APPLY,LINKLIB,SYS1.LINKLIB IEC031I D37-04,IFG0554P,,APPLY,NUCLEUS,SYS1.NUCLEUS IEC031I D37-04,IFG0554P,,APPLY,SASMMOD1,ASM.SASMMOD1 IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0 IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0 IEC031I D37-04,IFG0554P,,APPLY,SGIMLMD0,GIM.SGIMLMD0 IEC031I D37-04,IFG0554P,,APPLY,SGIMLMD0,GIM.SGIMLMD0 IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0 IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0 IEC031I D37-04,IFG0554P,,APPLY,SGIMLMD0,GIM.SGIMLMD0 IEC031I D37-04,IFG0554P,,APPLY,SCEERUN,CEE.SCEERUN #2 IEC032I E37-04,IFG0554P,,APPLY,SGIMTENU,GIM.SGIMTENU IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG IEC031I D37-04,IFG0554P,,APPLY,SISFLOAD,ISF.SISFLOAD IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG IOEZ00312I Dynamic growth of aggregate x.SIZUUSRD in progress #3 Made an error during increase of data sets, ended up restoring everything and increasing (joblogs from before restore not saved) SCBDMENU SMPSTS 16->50 trks, sec 5 SASMMOD1 50->80 trks #4 Accept of previous maintenance: IEC032I E37-04,IFG0554P,,ACCEPT,ABBLLIB,BBL.ABBLLIB Apply new: IEC031I D37-04,IFG0554P,,APPLY,LINKLIB,SYS1.LINKLIB IEC031I D37-04,IFG0554P,,APPLY,SICELINK,SYS1.SICELINK #5 Accept of previous maintenance: IEC032I E37-04,IFG0554P,,ACCEPT,AGIMTENU,GIM.AGIMTENU IEC032I E37-04,IFG0554P,,ACCEPT,AERBPWSV,SYS1.AERBPWSV IEC032I E37-04,IFG0554P,,ACCEPT,AHAPINC3,HAP.AHAPINC3 IEC032I E37-04,IFG0554P,,ACCEPT,AGIMTENU,GIM.AGIMTENU Apply new: IEC032I E37-04,IFG0554P,,APPLY,SERBPWSV,SYS1.SERBPWSV IEC032I E37-04,IFG0554P,,APPLY,SEEQINST,SYS1.SEEQINST IEC031I D37-04,IFG0554P,,APPLY,MIGLIB,SYS1.MIGLIB IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0 IEC031I D37-04,IFG0554P,,APPLY,SISFLOAD,ISF.SISFLOAD IEC031I D37-04,IFG0554P,,APPLY,SCEERUN,CEE.SCEERUN #6 IEC031I D37-04,IFG0554P,,APPLY,SERBLINK,SYS1.SERBLINK IEC031I D37-04,IFG0554P,,APPLY,CMDLIB,SYS1.CMDLIB IEC031I D37-04,IFG0554P,,APPLY,LINKLIB,SYS1.LINKLIB IEC031I D37-04,IFG0554P,,APPLY,NUCLEUS,SYS1.NUCLEUS IEC031I D37-04,IFG0554P,,APPLY,SASMMOD1,ASM.SASMMOD1 #7 IEC032I E37-04,IFG0554P,,APPLY,SISFTLIB,ISF.SISFTLIB IEC032I E37-04,IFG0554P,,APPLY,SERBPWSV,SYS1.SERBPWSV IOEZ00312I Dynamic growth of aggregate x.SAZFAMOD in progress IEC031I D37-04,IFG0554P,,APPLY,SERBLINK,SYS1.SERBLINK IEC031I D37-04,IFG0554P,,APPLY,SISFLOAD,ISF.SISFLOAD IEC032I E37-04,IFG0554P,,APPLY,SCEELPA,CEE.SCEELPA #8 Accept of previous maintenance: IEC032I E37-04,IFG0554P,1,ACCEPT,AGIMTENU,GIM.AGIMTENU IEC032I E37-04,IFG0554P,1,ACCEPT,AISFTLIB,ISF.AISFTLIB IEC032I E37-04,IFG0554P,1,ACCEPT,AAZFAMOD,AZF.AAZFAMOD IEC032I E37-04,IFG0554P,1,ACCEPT,AHAPINC3,HAP.AHAPINC3 Apply new: IEC031I D37-04,IFG0554P,,APPLY,DGTLLIB,SYS1.DGTLLIB With z/OS 2.5, I'll probably triple allocations for those data sets during allocation. That being said, my cloning process copies my res volume and ZFS datasets to new volumes and resets extents to current used, which is why I never used the software deployment and NEVER will in z/OSMF. Right now the plan is for my successor to install z/OSMF once we're on 2.5. *I* will certainly NEVER use z/OSMF to do the rollout to all the other sysplexes. Cloning is done in 4 jobs and they work and are easily controlled. Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- /I am not bound to win, but I am bound to be true. I am not bound to succeed, but I am bound to live by the light that I have. I must stand with anybody that stands right, and stand with him while he is right, and part with him when he goes wrong. *Abraham Lincoln*/
Re: Serverpac installs January 2022 and beyond - Requests
>Its interesting, because I don’t have any products that give me extra extents >except what SMS does for me space wise, and I have never increased my dataset >size allocations. Just as a preparation for increasing allocations, here is what failed x37 in the past 8 refreshes (all on the *installation* target volume, never IPL'd from). I apply maintenance twice a year, too, and it is always upwards of 1000ptfs. SMPE was dealing with a few of those x37 doing in-flight compresses, but I had only the last refresh without having to increase sizes. #1 IEC031I D37-04,IFG0554P,,APPLY,LINKLIB,SYS1.LINKLIB IEC031I D37-04,IFG0554P,,APPLY,NUCLEUS,SYS1.NUCLEUS IEC031I D37-04,IFG0554P,,APPLY,SASMMOD1,ASM.SASMMOD1 IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0 IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0 IEC031I D37-04,IFG0554P,,APPLY,SGIMLMD0,GIM.SGIMLMD0 IEC031I D37-04,IFG0554P,,APPLY,SGIMLMD0,GIM.SGIMLMD0 IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0 IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0 IEC031I D37-04,IFG0554P,,APPLY,SGIMLMD0,GIM.SGIMLMD0 IEC031I D37-04,IFG0554P,,APPLY,SCEERUN,CEE.SCEERUN #2 IEC032I E37-04,IFG0554P,,APPLY,SGIMTENU,GIM.SGIMTENU IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG IEC031I D37-04,IFG0554P,,APPLY,SISFLOAD,ISF.SISFLOAD IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG IOEZ00312I Dynamic growth of aggregate x.SIZUUSRD in progress #3 Made an error during increase of data sets, ended up restoring everything and increasing (joblogs from before restore not saved) SCBDMENU SMPSTS 16->50 trks, sec 5 SASMMOD1 50->80 trks #4 Accept of previous maintenance: IEC032I E37-04,IFG0554P,,ACCEPT,ABBLLIB,BBL.ABBLLIB Apply new: IEC031I D37-04,IFG0554P,,APPLY,LINKLIB,SYS1.LINKLIB IEC031I D37-04,IFG0554P,,APPLY,SICELINK,SYS1.SICELINK #5 Accept of previous maintenance: IEC032I E37-04,IFG0554P,,ACCEPT,AGIMTENU,GIM.AGIMTENU IEC032I E37-04,IFG0554P,,ACCEPT,AERBPWSV,SYS1.AERBPWSV IEC032I E37-04,IFG0554P,,ACCEPT,AHAPINC3,HAP.AHAPINC3 IEC032I E37-04,IFG0554P,,ACCEPT,AGIMTENU,GIM.AGIMTENU Apply new: IEC032I E37-04,IFG0554P,,APPLY,SERBPWSV,SYS1.SERBPWSV IEC032I E37-04,IFG0554P,,APPLY,SEEQINST,SYS1.SEEQINST IEC031I D37-04,IFG0554P,,APPLY,MIGLIB,SYS1.MIGLIB IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0 IEC031I D37-04,IFG0554P,,APPLY,SISFLOAD,ISF.SISFLOAD IEC031I D37-04,IFG0554P,,APPLY,SCEERUN,CEE.SCEERUN #6 IEC031I D37-04,IFG0554P,,APPLY,SERBLINK,SYS1.SERBLINK IEC031I D37-04,IFG0554P,,APPLY,CMDLIB,SYS1.CMDLIB IEC031I D37-04,IFG0554P,,APPLY,LINKLIB,SYS1.LINKLIB IEC031I D37-04,IFG0554P,,APPLY,NUCLEUS,SYS1.NUCLEUS IEC031I D37-04,IFG0554P,,APPLY,SASMMOD1,ASM.SASMMOD1 #7 IEC032I E37-04,IFG0554P,,APPLY,SISFTLIB,ISF.SISFTLIB IEC032I E37-04,IFG0554P,,APPLY,SERBPWSV,SYS1.SERBPWSV IOEZ00312I Dynamic growth of aggregate x.SAZFAMOD in progress IEC031I D37-04,IFG0554P,,APPLY,SERBLINK,SYS1.SERBLINK IEC031I D37-04,IFG0554P,,APPLY,SISFLOAD,ISF.SISFLOAD IEC032I E37-04,IFG0554P,,APPLY,SCEELPA,CEE.SCEELPA #8 Accept of previous maintenance: IEC032I E37-04,IFG0554P,1,ACCEPT,AGIMTENU,GIM.AGIMTENU IEC032I E37-04,IFG0554P,1,ACCEPT,AISFTLIB,ISF.AISFTLIB IEC032I
Re: How should I send file to another sysplex securely.
On 7/22/21 6:21 PM, Charles Mills wrote: Agreed. By "roll your own" I was referring to 1) Create an asymmetric public + private key pair on the destination system. 2) Transfer the destination system's public key to the source system. 3) Create a symmetric key on the source system. Etc. If that's "roll your own" cryptography, then how do you use Pervasive Encryption without "rolling your own" cryptography? You must have keying material, and I'd be flabbergasted if IBM shipped said keying material with the system. You have to transfer that keying material between systems you want to communicate. How do you avoid "rolling your own" cryptography when you make the investment and create the aforementioned SFTP server? -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How should I send file to another sysplex securely.
On 7/22/21 6:17 PM, Mike Schwab wrote: Since a lot of chips a manufactured in China, a device could be sending ... your data, Theoretically yes. I'm not going to speculate on the probability that such is happening. Though Hanlon's Razor comes to mind. But for it to be sending your data it would have to ... actually send the data. And in doing so would present symptoms of sending data. These symptoms can be detected. As such it's quite possible to detect if this is happening. I say possible, because not everybody is looking for such data. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How should I send file to another sysplex securely.
On 7/22/21 6:09 PM, Charles Mills wrote: Guys, this is the problem with inventing your own solution. You didn't elucidate what the (or a) problem is. Public keys are, well, public. Yes, that's the very nature of a /public/ key. The new fashion in fact is to NOT trust internal networks. You really don't know how far an intruder may have intruded, so you should assume every communication channel is insecure. *HEAVYsigh* Yes. Zero Trust *is* /a/ thing. But I think it's *MUCH* /more/ of a buzz word trying to sell snake oil than it is a real problem. As Bruce Schneier is famous for saying "Trust the Math". If I compare (a cryptographic hash of) the public key on SYS1 and SYS2 and they are the same, combined with the fact that SYS1's corresponding key can decrypt what SYS2 encrypts with it's copy of SYS1's public key, then I think the math dictates that SYS1 and SYS2 are actually talking to each other, no matter how (in)secure the intervening network(s) are. And if a malicious actor can intercept data flowing across a HyperSocket between two LPARs and perform a full in the middle attack, ... you've got MUCH bigger problems. In the new era of cloud and partners and bring your own device, exactly what is an internal and what is an external network? The two CECs sitting next to each other in the same room with cables running directly between them seems to definitely qualify as "internal" to me. You can "what if" yourself to death. Or you can "trust the math". Verify (a hash of) the public key on the source and destination system. If the key is the same, you are quite likely safe to move data across the wire. If someone can spoof the output from the commands to display (the hash of) the public key and your terminal as an active in the middle attack ... you have bigger problems. I'm not even sure that IBM can help you. This new paradigm is called "Zero Trust." https://csrc.nist.gov/publications/detail/sp/800-207/final. I have a presentation on Zero Trust coming up courtesy of New Era, but we don't have a date yet. A good month or so out. I'm intrigued. But obviously I'm a tad bit skeptical. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Serverpac installs January 2022 and beyond - Requests
Except for C:\Windows and the Program files directory, I don't think I keep anything where Microsoft wants me to. I like to keep everything that isn't the vanilla MS system on other drives and I create links to them so that I can reinstall when I want and just redo the links. But then I also update the registry manually as well, so maybe I'm a bad example. Brian On Thu, 22 Jul 2021 07:38:02 -0700, Tom Brennan wrote: >"seems everyone has a better way" > >I think you hit on the root of the problem. With Windows and Linux >installs, everyone (generally) does things the same exact way, including >filenames and directory locations. They don't have the problems we have >with mainframe installs. > >On 7/22/2021 7:19 AM, Carmen Vitullo wrote: >> I think I IPL'd the CPAC system that was built from the ServerPac once >> in my career, it was the company/dept's standard and we had a small LPAR >> built just for that reason. Documentation was provided, IPLing the CPAC >> system was only done to proceed with the ServerPac install. >> >> moving on from that company I moved to a different process, seems >> everyone has a better way, for me building the target sysres and zfs >> file systems, running some IVP tests and build my new master catalog, >> and IPL that system on my sandbox system. >> >> I have a documented process to copy/migrate the new version or maint to >> production that works well even for someone who's not a z/os sysprog. >> >> Carmen >> >> >> On 7/21/2021 1:19 PM, Tom Brennan wrote: >>> Same with me when I ran ServerPac installs - I never IPL'd using the >>> datasets provided by the installer such as catalogs, RACF, spool, SMF, >>> page, etc. I never understood IBM's reason for doing that, and also >>> never understood the reason for running the system validation jobs on >>> the vanilla system. What was much more important for us was IPLing >>> the new res pack on a sandbox system with our own system datasets, >>> parms, and usermods - and then solve any issues that may come up. >>> >>> So those IBM-supplied system datasets were never used, and although I >>> could not delete them using the CPP dialog, I would always set them to >>> 1 track or 1 cylinder before running the alloc job - just to save space. >>> >>> It just made little sense to me to prove the vanilla system from IBM >>> works correctly. Of course it does, otherwise why would they send it >>> to me? >>> >>> On 7/20/2021 10:23 PM, Gibney, Dave wrote: I don't know how it would work with zOSMF, but I don't worry about the dataset sizes of my SMPE target datasets. Because I never IPL using them. I copy to new SYSRES, FDR and ADRDSSU dataset copies to single extents. Of course, I rarely (maybe 5 to 5 times in 30 years) put maintenance into a running system >>> >>> -- >>> 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
