Re: SYSPLEX JES2 SYSLOG processing
On Thu, 4 Jan 2024 12:31:36 -0600, Paul Gorlinsky wrote: >On a z/OS 2.5 system using z System Automation V4.3, > >The event needs to issue a 'W L' then locate the SYSLOG output for that >specific LPAR, There are many ways to solve this problem and various considerations. >Where STC08984 is the result of parsing a JES2 $DS'SYSLOG' command > >LPR1 2024002 02:01:00:45 STC08984 $HASP890 JOB(SYSLOG) > > $HASP890 JOB(SYSLOG) > STATUS=(EXECUTING/LPR1),CLASS=STC, > $HASP890 > PRIORITY=15,SYSAFF=(LPR1),HOLD=(NONE) >LPR1 2024002 02:01:00:45 STC09720 $HASP890 JOB(SYSLOG) > > $HASP890 JOB(SYSLOG) > STATUS=(EXECUTING/LPR2),CLASS=STC, > $HASP890 > PRIORITY=15,SYSAFF=(LPR2),HOLD=(NONE) > >I have tried using a PIPE command without success... You never show the PIPE command nor how or why it failed. I can only guess as to why it failed. Possibility 1: Notice the indentation of the $DS output. This shows $DS writes multiple MLWTO's. Does PIPE only return the first MLWTO? Personally, I would issue D A,SYSLOG to get the jobid and forget using $DS. Possibility 2: You issue "W L" before the $DS. Maybe SYSLOG is one of the products that changes it's JOBID to free JES resources. The $DS picks up the wrong JOBID. Solution would be to issue $DS first. Possibility 3: "W L" does not complete before XWTR is started. > start an XWTR with job selection for class and JOBID... > >For example, >'S XWTR.XWTR,END=IEF176I' >'F XWTR.XWTR,CLASS=L,JOBID=STC08984' I suspect that "W L" command issues messages. XWTR should not be started before it completes. Is the JOBID available from those messages? You might consider TRAP & WAIT. Maybe an MPF exit for the messages. Maybe you could use a different class for each system and omit the jobid. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSPLEX JES2 SYSLOG processing
Hey Paul - Do you get any interesting results from the NetView command line (you may need to enter INPUT 2 to get more room) if you issue: WINDOW PIPE CC 5 $DS'SYSLOG'|TOS LAST "$HASP890"|SEP|EDIT "CB" COLOR 1.*|CONS ONLY If you do, hope is not lost. On Thu, Jan 4, 2024 at 12:31 PM Paul Gorlinsky wrote: > On a z/OS 2.5 system using z System Automation V4.3, I am trying to set a > daily event that runs on each LPAR of the SYSPLEX. > > The event needs to issue a 'W L' then locate the SYSLOG output for that > specific LPAR, start an XWTR with job selection for class and JOBID... > > For example, > 'S XWTR.XWTR,END=IEF176I' > 'F XWTR.XWTR,CLASS=L,JOBID=STC08984' > > Where STC08984 is the result of parsing a JES2 $DS'SYSLOG' command > > LPR1 2024002 02:01:00:45 STC08984 $HASP890 JOB(SYSLOG) > >$HASP890 JOB(SYSLOG) > STATUS=(EXECUTING/LPR1),CLASS=STC, >$HASP890 > PRIORITY=15,SYSAFF=(LPR1),HOLD=(NONE) > LPR1 2024002 02:01:00:45 STC09720 $HASP890 JOB(SYSLOG) > >$HASP890 JOB(SYSLOG) > STATUS=(EXECUTING/LPR2),CLASS=STC, >$HASP890 > PRIORITY=15,SYSAFF=(LPR2),HOLD=(NONE) > LPR1 2024002 02:01:00:45 STC06274 $HASP890 JOB(SYSLOG) > >$HASP890 JOB(SYSLOG) > STATUS=(EXECUTING/LPR3),CLASS=STC, >$HASP890 > PRIORITY=15,SYSAFF=(LPR3),HOLD=(NONE) > LPR1 2024002 02:01:00:45 STC09125 $HASP890 JOB(SYSLOG) > >$HASP890 JOB(SYSLOG) > STATUS=(EXECUTING/LPR4),CLASS=STC, >$HASP890 > PRIORITY=15,SYSAFF=(LPR4),HOLD=(NONE) > LPR1 2024002 02:01:00:45 STC03207 $HASP890 JOB(SYSLOG) > >$HASP890 JOB(SYSLOG) > STATUS=(EXECUTING/LPR5),CLASS=STC, >$HASP890 > PRIORITY=15,SYSAFF=(LPR5),HOLD=(NONE) > > I have tried using a PIPE command without success... > > Any ideas? > > Thanks > 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
SYSPLEX JES2 SYSLOG processing
On a z/OS 2.5 system using z System Automation V4.3, I am trying to set a daily event that runs on each LPAR of the SYSPLEX. The event needs to issue a 'W L' then locate the SYSLOG output for that specific LPAR, start an XWTR with job selection for class and JOBID... For example, 'S XWTR.XWTR,END=IEF176I' 'F XWTR.XWTR,CLASS=L,JOBID=STC08984' Where STC08984 is the result of parsing a JES2 $DS'SYSLOG' command LPR1 2024002 02:01:00:45 STC08984 $HASP890 JOB(SYSLOG) $HASP890 JOB(SYSLOG) STATUS=(EXECUTING/LPR1),CLASS=STC, $HASP890 PRIORITY=15,SYSAFF=(LPR1),HOLD=(NONE) LPR1 2024002 02:01:00:45 STC09720 $HASP890 JOB(SYSLOG) $HASP890 JOB(SYSLOG) STATUS=(EXECUTING/LPR2),CLASS=STC, $HASP890 PRIORITY=15,SYSAFF=(LPR2),HOLD=(NONE) LPR1 2024002 02:01:00:45 STC06274 $HASP890 JOB(SYSLOG) $HASP890 JOB(SYSLOG) STATUS=(EXECUTING/LPR3),CLASS=STC, $HASP890 PRIORITY=15,SYSAFF=(LPR3),HOLD=(NONE) LPR1 2024002 02:01:00:45 STC09125 $HASP890 JOB(SYSLOG) $HASP890 JOB(SYSLOG) STATUS=(EXECUTING/LPR4),CLASS=STC, $HASP890 PRIORITY=15,SYSAFF=(LPR4),HOLD=(NONE) LPR1 2024002 02:01:00:45 STC03207 $HASP890 JOB(SYSLOG) $HASP890 JOB(SYSLOG) STATUS=(EXECUTING/LPR5),CLASS=STC, $HASP890 PRIORITY=15,SYSAFF=(LPR5),HOLD=(NONE) I have tried using a PIPE command without success... Any ideas? Thanks Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Starting up a LPAR for the first time joining a parallel sysplex
Classification: Confidential Nothing major on the 1st 2 points. LPAR1 cannot join the sysplex until GRS= in IEASYS00 is updated to (at least) TRYJOIN. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Laurence Chiu Sent: Tuesday, December 5, 2023 2:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Starting up a LPAR for the first time joining a parallel sysplex [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] We are building a parallel sysplex. LPAR1 is still in a monoplex with GRS=NONE. It will be shutdown. Then we want to bring up LPAR2 with GRS=STAR and join the sysplex. A couple of questions cropped up. 1. Can LPAR2 be brought up, trying to access the share catalog, RACF database etc when the other LPAR is not up. What are the gotchas to be looking for 2. This will be the first time the LPAR is IPL'd with GRS=STAR and trying to join the sysplex. Would that extend the time for the IPL and what would you be looking for during the IPL? Would it take 2-3 hours to be confident it was working - e.g. CDS are okay, an all other parallel sysplex configurations? 3. What happens when LPAR1 comes up and then joins the parallel sysplex? Thanks -- 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
Starting up a LPAR for the first time joining a parallel sysplex
We are building a parallel sysplex. LPAR1 is still in a monoplex with GRS=NONE. It will be shutdown. Then we want to bring up LPAR2 with GRS=STAR and join the sysplex. A couple of questions cropped up. 1. Can LPAR2 be brought up, trying to access the share catalog, RACF database etc when the other LPAR is not up. What are the gotchas to be looking for 2. This will be the first time the LPAR is IPL'd with GRS=STAR and trying to join the sysplex. Would that extend the time for the IPL and what would you be looking for during the IPL? Would it take 2-3 hours to be confident it was working - e.g. CDS are okay, an all other parallel sysplex configurations? 3. What happens when LPAR1 comes up and then joins the parallel sysplex? Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What happens if you IPL a LPAR defined as being in a parallel sysplex but the CF LPAR is not there
Thanks to all. We do have an emergency single pack LPAR we can use but I would rather be prepared and either have a IEASYSnn setup or have operator instructions ready for people to know what to do when in a DR situation when the pressure is on On Fri, Nov 17, 2023 at 4:04 AM Burrell, Todd < 0316e668f7df-dmarc-requ...@listserv.ua.edu> wrote: > I seem to remember that you can override the system parameters at IPL time > and specify PLEXCFG=MONOPLEX. This should bring you up in a single system > plex. Or you can specify PLEXCFG=XCFLOCAL and not be in a plex at all. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Laurence Chiu > Sent: Thursday, November 16, 2023 1:54 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: What happens if you IPL a LPAR defined as being in a parallel > sysplex but the CF LPAR is not there > > It was gold for me and will help me settle a dispute with some local > sysprogs who said there would be no problem. My question is, it says if you > don't have a CF then change GRS=TRYJOIN or =NONE. Problem is, when the > problem occurs, how do you get online to change it? I could not find an > operator command to change it and since the system is able to IPL, you > can't logon to change it. > > On Thu, Nov 16, 2023 at 4:18 PM kekronbekron < > 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > > > Awesome, how do we even find such gems with TechDocs being what it is... > > Luckily for this one, I seem to have it bookmarked. > > > > > > On Thursday, November 16th, 2023 at 05:14, Attila Fogarasi < > > fogar...@gmail.com> wrote: > > > > > > > Answered a decade ago including how to continue the IPL and get > > > running (either single system or sysplex without CF) > > > > > https://www.ibm.com/support/pages/system/files/inline-files/Where_is_M > > y_Coupling_Facility.pdf > > > "The paper is being written to provide clear and concise > > > instructions on how to address the sysplex support team’s most > > > common callout. Where is > > My > > > Coupling Facility?" > > > > > > On Thu, Nov 16, 2023 at 10:42 AM Mark Jacobs < > > > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > > > > > > > GRS will attempt to connect to ISGLOCK, fail and z/OS will go into > > > > a X'0A3' wait state. > > > > > > > > Mark Jacobs > > > > > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > > > > > GPG Public Key - > > > > > > [URL Removed for your safety] > > > > > > > > On Wednesday, November 15th, 2023 at 5:49 PM, Laurence Chiu < > > > > lch...@gmail.com> wrote: > > > > > > > > > Thinking about a LPAR defined as being in a parallel sysplex > > > > > with GRS=STAR. > > > > > > > > > > What happens if you IPL that LPAR and the CF is not active? Will > > > > > it start, issue a WTOR or just fail? We are wondering what would > > > > > happen if our > > LPAR > > > > > was started at the DR site (off a replicated set of volumes) but > > > > > the > > DR > > > > > CEC > > > > > did not have a CF defined. Thanks > > > > > > > > > > > > -- > > > > > 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 w
Re: What happens if you IPL a LPAR defined as being in a parallel sysplex but the CF LPAR is not there
I seem to remember that you can override the system parameters at IPL time and specify PLEXCFG=MONOPLEX. This should bring you up in a single system plex. Or you can specify PLEXCFG=XCFLOCAL and not be in a plex at all. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Laurence Chiu Sent: Thursday, November 16, 2023 1:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What happens if you IPL a LPAR defined as being in a parallel sysplex but the CF LPAR is not there It was gold for me and will help me settle a dispute with some local sysprogs who said there would be no problem. My question is, it says if you don't have a CF then change GRS=TRYJOIN or =NONE. Problem is, when the problem occurs, how do you get online to change it? I could not find an operator command to change it and since the system is able to IPL, you can't logon to change it. On Thu, Nov 16, 2023 at 4:18 PM kekronbekron < 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > Awesome, how do we even find such gems with TechDocs being what it is... > Luckily for this one, I seem to have it bookmarked. > > > On Thursday, November 16th, 2023 at 05:14, Attila Fogarasi < > fogar...@gmail.com> wrote: > > > > Answered a decade ago including how to continue the IPL and get > > running (either single system or sysplex without CF) > > > https://www.ibm.com/support/pages/system/files/inline-files/Where_is_M > y_Coupling_Facility.pdf > > "The paper is being written to provide clear and concise > > instructions on how to address the sysplex support team’s most > > common callout. Where is > My > > Coupling Facility?" > > > > On Thu, Nov 16, 2023 at 10:42 AM Mark Jacobs < > > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > > > > > GRS will attempt to connect to ISGLOCK, fail and z/OS will go into > > > a X'0A3' wait state. > > > > > > Mark Jacobs > > > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > > > GPG Public Key - > > > > [URL Removed for your safety] > > > > > > On Wednesday, November 15th, 2023 at 5:49 PM, Laurence Chiu < > > > lch...@gmail.com> wrote: > > > > > > > Thinking about a LPAR defined as being in a parallel sysplex > > > > with GRS=STAR. > > > > > > > > What happens if you IPL that LPAR and the CF is not active? Will > > > > it start, issue a WTOR or just fail? We are wondering what would > > > > happen if our > LPAR > > > > was started at the DR site (off a replicated set of volumes) but > > > > the > DR > > > > CEC > > > > did not have a CF defined. Thanks > > > > > > > > > -- > > > > 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 We comply with applicable Federal civil rights laws and do not discriminate. Visit floridablue.com/ndnotice <https://floridablue.com/ndnotice> to view our Non-Discrimination policy and find information on our free language assistance services. Florida Blue is a trade name of Blue Cross and Blue Shield of Florida, Inc. Blue Cross and Blue Shield of Florida, Inc., and its subsidiary and affiliate companies are not responsible for errors or omissions in this e-mail message. Any personal comments made in this e-mail do not reflect the views of Blue Cross and Blue Shield of Florida, Inc. The information contained in this document may be confidential and intended solely for the use of the individual or entity to whom it is addressed. This do
Re: What happens if you IPL a LPAR defined as being in a parallel sysplex but the CF LPAR is not there
Can you specify it at IPL time by replying to the IEA101A SPECIFY SYSTEM PARAMETERS message? You would need an IEASYSxx that has the necessary parameter to issue the prompt in it set up beforehand. On Thu, Nov 16, 2023 at 12:54 AM Laurence Chiu wrote: > It was gold for me and will help me settle a dispute with some local > sysprogs who said there would be no problem. My question is, it says if you > don't have a CF then change GRS=TRYJOIN or =NONE. Problem is, when the > problem occurs, how do you get online to change it? I could not find an > operator command to change it and since the system is able to IPL, > you can't logon to change it. > > On Thu, Nov 16, 2023 at 4:18 PM kekronbekron < > 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > > > Awesome, how do we even find such gems with TechDocs being what it is... > > Luckily for this one, I seem to have it bookmarked. > > > > > > On Thursday, November 16th, 2023 at 05:14, Attila Fogarasi < > > fogar...@gmail.com> wrote: > > > > > > > Answered a decade ago including how to continue the IPL and get running > > > (either single system or sysplex without CF) > > > > > > https://www.ibm.com/support/pages/system/files/inline-files/Where_is_My_Coupling_Facility.pdf > > > "The paper is being written to provide clear and concise instructions > on > > > how to address the sysplex support team’s most common callout. Where is > > My > > > Coupling Facility?" > > > > > > On Thu, Nov 16, 2023 at 10:42 AM Mark Jacobs < > > > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > > > > > > > GRS will attempt to connect to ISGLOCK, fail and z/OS will go into a > > > > X'0A3' wait state. > > > > > > > > Mark Jacobs > > > > > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > > > > > GPG Public Key - > > > > > > > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > > > > > > > On Wednesday, November 15th, 2023 at 5:49 PM, Laurence Chiu < > > > > lch...@gmail.com> wrote: > > > > > > > > > Thinking about a LPAR defined as being in a parallel sysplex with > > > > > GRS=STAR. > > > > > > > > > > What happens if you IPL that LPAR and the CF is not active? Will it > > > > > start, > > > > > issue a WTOR or just fail? We are wondering what would happen if > our > > LPAR > > > > > was started at the DR site (off a replicated set of volumes) but > the > > DR > > > > > CEC > > > > > did not have a CF defined. Thanks > > > > > > > > > > > > -- > > > > > 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 > -- Jay Maynard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What happens if you IPL a LPAR defined as being in a parallel sysplex but the CF LPAR is not there
You can change the Load Parameter in the activation profile to have z/OS Prompt for System Parameters Response and then specify GRS=NONE/TRYJOIN there. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com On Thursday, November 16th, 2023 at 1:53 AM, Laurence Chiu wrote: > It was gold for me and will help me settle a dispute with some local > sysprogs who said there would be no problem. My question is, it says if you > don't have a CF then change GRS=TRYJOIN or =NONE. Problem is, when the > problem occurs, how do you get online to change it? I could not find an > operator command to change it and since the system is able to IPL, > you can't logon to change it. > > On Thu, Nov 16, 2023 at 4:18 PM kekronbekron < > 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > > > Awesome, how do we even find such gems with TechDocs being what it is... > > Luckily for this one, I seem to have it bookmarked. > > > > On Thursday, November 16th, 2023 at 05:14, Attila Fogarasi < > > fogar...@gmail.com> wrote: > > > > > Answered a decade ago including how to continue the IPL and get running > > > (either single system or sysplex without CF) > > > > https://www.ibm.com/support/pages/system/files/inline-files/Where_is_My_Coupling_Facility.pdf > > > > > "The paper is being written to provide clear and concise instructions on > > > how to address the sysplex support team’s most common callout. Where is > > > My > > > Coupling Facility?" > > > > > > On Thu, Nov 16, 2023 at 10:42 AM Mark Jacobs < > > > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > > > > > > > GRS will attempt to connect to ISGLOCK, fail and z/OS will go into a > > > > X'0A3' wait state. > > > > > > > > Mark Jacobs > > > > > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > > > > > GPG Public Key - > > > > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > > > > > On Wednesday, November 15th, 2023 at 5:49 PM, Laurence Chiu < > > > > lch...@gmail.com> wrote: > > > > > > > > > Thinking about a LPAR defined as being in a parallel sysplex with > > > > > GRS=STAR. > > > > > > > > > > What happens if you IPL that LPAR and the CF is not active? Will it > > > > > start, > > > > > issue a WTOR or just fail? We are wondering what would happen if our > > > > > LPAR > > > > > was started at the DR site (off a replicated set of volumes) but the > > > > > DR > > > > > CEC > > > > > did not have a CF defined. Thanks > > > > -- > > > > > > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What happens if you IPL a LPAR defined as being in a parallel sysplex but the CF LPAR is not there
Bring up a one pack rescue system that can get to the same PARMLIB and change it. On Thu, Nov 16, 2023 at 12:54 AM Laurence Chiu wrote: > It was gold for me and will help me settle a dispute with some local > sysprogs who said there would be no problem. My question is, it says if you > don't have a CF then change GRS=TRYJOIN or =NONE. Problem is, when the > problem occurs, how do you get online to change it? I could not find an > operator command to change it and since the system is able to IPL, > you can't logon to change it. > > On Thu, Nov 16, 2023 at 4:18 PM kekronbekron < > 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > > > Awesome, how do we even find such gems with TechDocs being what it is... > > Luckily for this one, I seem to have it bookmarked. > > > > > > On Thursday, November 16th, 2023 at 05:14, Attila Fogarasi < > > fogar...@gmail.com> wrote: > > > > > > > Answered a decade ago including how to continue the IPL and get running > > > (either single system or sysplex without CF) > > > > > > https://www.ibm.com/support/pages/system/files/inline-files/Where_is_My_Coupling_Facility.pdf > > > "The paper is being written to provide clear and concise instructions > on > > > how to address the sysplex support team’s most common callout. Where is > > My > > > Coupling Facility?" > > > > > > On Thu, Nov 16, 2023 at 10:42 AM Mark Jacobs < > > > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > > > > > > > GRS will attempt to connect to ISGLOCK, fail and z/OS will go into a > > > > X'0A3' wait state. > > > > > > > > Mark Jacobs > > > > > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > > > > > GPG Public Key - > > > > > > > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > > > > > > > On Wednesday, November 15th, 2023 at 5:49 PM, Laurence Chiu < > > > > lch...@gmail.com> wrote: > > > > > > > > > Thinking about a LPAR defined as being in a parallel sysplex with > > > > > GRS=STAR. > > > > > > > > > > What happens if you IPL that LPAR and the CF is not active? Will it > > > > > start, > > > > > issue a WTOR or just fail? We are wondering what would happen if > our > > LPAR > > > > > was started at the DR site (off a replicated set of volumes) but > the > > DR > > > > > CEC > > > > > did not have a CF defined. Thanks > > > > > > > > > > > > -- > > > > > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What happens if you IPL a LPAR defined as being in a parallel sysplex but the CF LPAR is not there
It was gold for me and will help me settle a dispute with some local sysprogs who said there would be no problem. My question is, it says if you don't have a CF then change GRS=TRYJOIN or =NONE. Problem is, when the problem occurs, how do you get online to change it? I could not find an operator command to change it and since the system is able to IPL, you can't logon to change it. On Thu, Nov 16, 2023 at 4:18 PM kekronbekron < 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > Awesome, how do we even find such gems with TechDocs being what it is... > Luckily for this one, I seem to have it bookmarked. > > > On Thursday, November 16th, 2023 at 05:14, Attila Fogarasi < > fogar...@gmail.com> wrote: > > > > Answered a decade ago including how to continue the IPL and get running > > (either single system or sysplex without CF) > > > https://www.ibm.com/support/pages/system/files/inline-files/Where_is_My_Coupling_Facility.pdf > > "The paper is being written to provide clear and concise instructions on > > how to address the sysplex support team’s most common callout. Where is > My > > Coupling Facility?" > > > > On Thu, Nov 16, 2023 at 10:42 AM Mark Jacobs < > > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > > > > > GRS will attempt to connect to ISGLOCK, fail and z/OS will go into a > > > X'0A3' wait state. > > > > > > Mark Jacobs > > > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > > > GPG Public Key - > > > > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > > > > > On Wednesday, November 15th, 2023 at 5:49 PM, Laurence Chiu < > > > lch...@gmail.com> wrote: > > > > > > > Thinking about a LPAR defined as being in a parallel sysplex with > > > > GRS=STAR. > > > > > > > > What happens if you IPL that LPAR and the CF is not active? Will it > > > > start, > > > > issue a WTOR or just fail? We are wondering what would happen if our > LPAR > > > > was started at the DR site (off a replicated set of volumes) but the > DR > > > > CEC > > > > did not have a CF defined. Thanks > > > > > > > > > -- > > > > 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: What happens if you IPL a LPAR defined as being in a parallel sysplex but the CF LPAR is not there
Awesome, how do we even find such gems with TechDocs being what it is... Luckily for this one, I seem to have it bookmarked. On Thursday, November 16th, 2023 at 05:14, Attila Fogarasi wrote: > Answered a decade ago including how to continue the IPL and get running > (either single system or sysplex without CF) > https://www.ibm.com/support/pages/system/files/inline-files/Where_is_My_Coupling_Facility.pdf > "The paper is being written to provide clear and concise instructions on > how to address the sysplex support team’s most common callout. Where is My > Coupling Facility?" > > On Thu, Nov 16, 2023 at 10:42 AM Mark Jacobs < > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > > > GRS will attempt to connect to ISGLOCK, fail and z/OS will go into a > > X'0A3' wait state. > > > > Mark Jacobs > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > GPG Public Key - > > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > > > On Wednesday, November 15th, 2023 at 5:49 PM, Laurence Chiu < > > lch...@gmail.com> wrote: > > > > > Thinking about a LPAR defined as being in a parallel sysplex with > > > GRS=STAR. > > > > > > What happens if you IPL that LPAR and the CF is not active? Will it > > > start, > > > issue a WTOR or just fail? We are wondering what would happen if our LPAR > > > was started at the DR site (off a replicated set of volumes) but the DR > > > CEC > > > did not have a CF defined. Thanks > > > > > > -- > > > 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: What happens if you IPL a LPAR defined as being in a parallel sysplex but the CF LPAR is not there
That is perfect, thanks. Looks like there is some work to do at the DR site to make sure this does not happen. On Thu, Nov 16, 2023 at 12:44 PM Attila Fogarasi wrote: > Answered a decade ago including how to continue the IPL and get running > (either single system or sysplex without CF) > > https://www.ibm.com/support/pages/system/files/inline-files/Where_is_My_Coupling_Facility.pdf > "The paper is being written to provide clear and concise instructions on > how to address the sysplex support team’s most common callout. Where is My > Coupling Facility?" > > On Thu, Nov 16, 2023 at 10:42 AM Mark Jacobs < > 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > > > GRS will attempt to connect to ISGLOCK, fail and z/OS will go into a > > X'0A3' wait state. > > > > Mark Jacobs > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > GPG Public Key - > > > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > > > > > On Wednesday, November 15th, 2023 at 5:49 PM, Laurence Chiu < > > lch...@gmail.com> wrote: > > > > > > > Thinking about a LPAR defined as being in a parallel sysplex with > > GRS=STAR. > > > > > > What happens if you IPL that LPAR and the CF is not active? Will it > > start, > > > issue a WTOR or just fail? We are wondering what would happen if our > LPAR > > > was started at the DR site (off a replicated set of volumes) but the DR > > CEC > > > did not have a CF defined. Thanks > > > > > > -- > > > 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: What happens if you IPL a LPAR defined as being in a parallel sysplex but the CF LPAR is not there
Answered a decade ago including how to continue the IPL and get running (either single system or sysplex without CF) https://www.ibm.com/support/pages/system/files/inline-files/Where_is_My_Coupling_Facility.pdf "The paper is being written to provide clear and concise instructions on how to address the sysplex support team’s most common callout. Where is My Coupling Facility?" On Thu, Nov 16, 2023 at 10:42 AM Mark Jacobs < 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > GRS will attempt to connect to ISGLOCK, fail and z/OS will go into a > X'0A3' wait state. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > > On Wednesday, November 15th, 2023 at 5:49 PM, Laurence Chiu < > lch...@gmail.com> wrote: > > > > Thinking about a LPAR defined as being in a parallel sysplex with > GRS=STAR. > > > > What happens if you IPL that LPAR and the CF is not active? Will it > start, > > issue a WTOR or just fail? We are wondering what would happen if our LPAR > > was started at the DR site (off a replicated set of volumes) but the DR > CEC > > did not have a CF defined. Thanks > > > > -- > > 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: What happens if you IPL a LPAR defined as being in a parallel sysplex but the CF LPAR is not there
GRS will attempt to connect to ISGLOCK, fail and z/OS will go into a X'0A3' wait state. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com On Wednesday, November 15th, 2023 at 5:49 PM, Laurence Chiu wrote: > Thinking about a LPAR defined as being in a parallel sysplex with GRS=STAR. > > What happens if you IPL that LPAR and the CF is not active? Will it start, > issue a WTOR or just fail? We are wondering what would happen if our LPAR > was started at the DR site (off a replicated set of volumes) but the DR CEC > did not have a CF defined. Thanks > > -- > 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
What happens if you IPL a LPAR defined as being in a parallel sysplex but the CF LPAR is not there
Thinking about a LPAR defined as being in a parallel sysplex with GRS=STAR. What happens if you IPL that LPAR and the CF is not active? Will it start, issue a WTOR or just fail? We are wondering what would happen if our LPAR was started at the DR site (off a replicated set of volumes) but the DR CEC did not have a CF defined. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Better support for multiple master catalogs in a sysplex
Lennie, I can appreciate your RFE, we used to maintain multiple mastercat’s in our prod sysplex, but do not anymore.Mostly due to the extra efforts and issues you note in your RFE. Our OMVS and CSF datasets are in usercats.We do take catalog backups 4 times a day, and our master catalog is pretty stable, as in the contents of it doesn’t change much. As for your highlights of certain products that are or could be VSAM, we do isolate some of those items into their own USERCAT so that we can have stricter access rules for those catalogs (general public doesn’t have update access). We also happened to be a GDPS customer, so we have isolated K systems connected to the sysplex where we could do the necessary repairs if it ever came to that. While not all shops are GDPS, the idea remains similar in that you could have another disconnected lpar with access to the DASD (but offline), to do any kind of necessary recovery. Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> Date: Monday, November 6, 2023 at 8:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Better support for multiple master catalogs in a sysplex I have just raised an RFE regarding support for better sharing of VSAM system datasets (such as RACF, ICSF key stores and ZFS file systems) when used in a sysplex with multiple master catalogs. Please would you examine it and support of relevant I have just raised an RFE regarding support for better sharing of VSAM system datasets (such as RACF, ICSF key stores and ZFS file systems) when used in a sysplex with multiple master catalogs. Please would you examine it and support of relevant for you. https://urldefense.com/v3/__https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3890__;!!MwwqYLOC6b6whF7V!gDErcwuVzIRgwvRCcZtGPvKZe2wgGAOI3fK9vJWOm4eIrdxXqqQAsa01MoMDrNecT1BKVhVLI0_KyZu2WrJ83n211Cr90JjJM28$<https://urldefense.com/v3/__https:/ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3890__;!!MwwqYLOC6b6whF7V!gDErcwuVzIRgwvRCcZtGPvKZe2wgGAOI3fK9vJWOm4eIrdxXqqQAsa01MoMDrNecT1BKVhVLI0_KyZu2WrJ83n211Cr90JjJM28$> Thanks Lennie Dymoke-Bradshaw https://urldefense.com/v3/__https://rsclweb.com__;!!MwwqYLOC6b6whF7V!gDErcwuVzIRgwvRCcZtGPvKZe2wgGAOI3fK9vJWOm4eIrdxXqqQAsa01MoMDrNecT1BKVhVLI0_KyZu2WrJ83n211Cr9tuyN6c4$<https://urldefense.com/v3/__https:/rsclweb.com__;!!MwwqYLOC6b6whF7V!gDErcwuVzIRgwvRCcZtGPvKZe2wgGAOI3fK9vJWOm4eIrdxXqqQAsa01MoMDrNecT1BKVhVLI0_KyZu2WrJ83n211Cr9tuyN6c4$> <https://urldefense.com/v3/__https://rsclweb.com/__;!!MwwqYLOC6b6whF7V!gDErcwuVzIRgwvRCcZtGPvKZe2wgGAOI3fK9vJWOm4eIrdxXqqQAsa01MoMDrNecT1BKVhVLI0_KyZu2WrJ83n211Cr9GwIOX3Q$<https://urldefense.com/v3/__https:/rsclweb.com/__;!!MwwqYLOC6b6whF7V!gDErcwuVzIRgwvRCcZtGPvKZe2wgGAOI3fK9vJWOm4eIrdxXqqQAsa01MoMDrNecT1BKVhVLI0_KyZu2WrJ83n211Cr9GwIOX3Q$>> 'Dance like no one is watching. Encrypt like everyone is.' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Better support for multiple master catalogs in a sysplex
I have just raised an RFE regarding support for better sharing of VSAM system datasets (such as RACF, ICSF key stores and ZFS file systems) when used in a sysplex with multiple master catalogs. Please would you examine it and support of relevant for you. https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3890 Thanks Lennie Dymoke-Bradshaw https://rsclweb.com <https://rsclweb.com/> 'Dance like no one is watching. Encrypt like everyone is.' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Better support for multiple master catalogs in a sysplex
I have just raised an RFE regarding support for better sharing of VSAM system datasets (such as RACF, ICSF key stores and ZFS file systems) when used in a sysplex with multiple master catalogs. Please would you examine it and support of relevant for you. Thanks Lennie Dymoke-Bradshaw https://rsclweb.com <https://rsclweb.com/> 'Dance like no one is watching. Encrypt like everyone is.' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Auto: Re: GRS setup for MONOPLEX to SYSPLEX
Je suis absent le 26 juin 2023. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GRS setup for MONOPLEX to SYSPLEX
While my advice is not to do it at all, that doesn't meant hat it isn't possible without a plex, just that it's really (really) not a good idea. I have been at sites that were okay with the exposure, and if you are really, really careful;, you will still occasionally have issues, but for the most part, unless you are really careless, you will likely be okay. But it's so darn cheap to grab a couple ficon cards (even on ebay) and do it right. If the OP is correct that you can use the built-in IFB ports or some other internal connection, then that's worth giving it a try. I am very interested to hear how it goes for them without using FICON, it could be very interesting. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GRS setup for MONOPLEX to SYSPLEX
Amen to that. I used to share PDSE, but it was "last resort" and for single action. IMHO the only way to safely share PDSE data is to IEBCOPY it to PDSU (PS file) and IEBCOPY to PDSE. (context is cross-sysplex) -- Radoslaw Skorupka Lodz, Poland W dniu 20.06.2023 o 14:24, Allan Staller pisze: Classification: Confidential Not my dog, but I would not do that, except under extreme duress. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gibney, Dave Sent: Monday, June 19, 2023 4:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GRS setup for MONOPLEX to SYSPLEX [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Even PDSE can be safely shared. If updates only occur from one LPAR and read-only everywhere else. And, said updates may not be reflected immediately (or until next IPL) in the other read-only LPARs -Original Message- From: IBM Mainframe Discussion List On Behalf Of Radoslaw Skorupka Sent: Monday, June 19, 2023 1:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GRS setup for MONOPLEX to SYSPLEX Yes, PDSE do require SYSPLEX. Not GRS-plex, not CA-MIM (or MII), but SYSPLEX. Reason: PDSE use sysplex communication, not GRS facilities. Regarding to the topic: in order to share datasets you need ...nothing. No parallel sysplex No base sysplex Not even GRSplex No SMSplex Simply nothing except DASD available from several systems. Of course, the more mentioned facilities you have the better sharing is. And yes, in order to share PDSEs (properly) you still have sysplex. However you can share ICF BCSes (catalogs), VSAM, PS, PDS, etc. Note: there are various flavours of sharing. Shared DASD as a data transport method, shared PDSes with jobs, REXX tools, etc. - it can be shared easily, because it is not heavily used. Batch datasets - assuming proper batch windows it is also can be shared easily. For frequent sharing it is good to think about ICF ECS or RLS, etc. -- Radoslaw Skorupka Lodz, Poland W dniu 19.06.2023 o 17:03, Michael Babcock pisze: Beware of PDSEs. I’m not 100% sure but I think the sandbox needs to be in the plex to share them. Updating a PDSE outside of the plex can cause corruption. We have our sandbox in the plex just to avoid issues. On Mon, Jun 19, 2023 at 9:25 AM Paul Gorlinsky wrote: We have a sandbox system that references TSO user and ISV catalogs and datasets. The sandbox has a unique master catalog but shares virtually everything else. It does have access to the couple facility that the Sysplex is using ... But it is not a member of the Sysplex. Is it possible for a monoplex z/OS system to share DASD, user cats, etc., with a SYSPLEX via GRS management and coupling facility? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GRS setup for MONOPLEX to SYSPLEX
Some folks have mentioned 'backplane' etc. There is no such thing as 'backplane' connectivity. One solution for a FICON CTC within a SINGLE CEC/CPC is to use a 'jumper cable' between 2 FICON ports - either on the same FICON card or 2 different ones. More about using and spec of the jumper cable in Planning Fiber Links manual - GA23-1409. Regards Parwez Hamid From: IBM Mainframe Discussion List on behalf of Dana Mitchell Sent: 22 June 2023 13:22 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GRS setup for MONOPLEX to SYSPLEX Where are you seeing this or what is it called? The only shortcut I of know is: https://www-40.ibm.com/servers/resourcelink/lib03010.nsf/0/D78D2E0FE578329485258194006D1387/$file/SB10-7174-00.pdf With FICON partition-to-partition communication technology, communication between logical partitions of a single physical system can be achieved utilizing only a single physical FICON channel attached to a FICON Director switch. On Thu, 22 Jun 2023 00:19:21 -0500, Brian Westerman wrote: >According to the manual, you can configure them to be connected apparently >without wires. I believe it does the route internally, but I can't really >tell from the manual. There is probably a better manual because I seem to be >seeing just the overview, bur it does appear to not need any cabling. > >Brian -- 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: GRS setup for MONOPLEX to SYSPLEX
what else would you expect to see in the FICON CTC reference guide :) You need to look at the technical guide for the specific hardware box that you want to implement on. I think that starting with the z13 that they allowed. There may have been some other methods previous to the z13, but this was the first that I came aware of something other than CF's and FC-CTCs. PSIFB - Parallel Sysplex InfiniBand ICA - Integrated Coupling Adapter IC - Internal Coupling link and then also FC-CTC which we already discussed. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GRS setup for MONOPLEX to SYSPLEX
Where are you seeing this or what is it called? The only shortcut I of know is: https://www-40.ibm.com/servers/resourcelink/lib03010.nsf/0/D78D2E0FE578329485258194006D1387/$file/SB10-7174-00.pdf With FICON partition-to-partition communication technology, communication between logical partitions of a single physical system can be achieved utilizing only a single physical FICON channel attached to a FICON Director switch. On Thu, 22 Jun 2023 00:19:21 -0500, Brian Westerman wrote: >According to the manual, you can configure them to be connected apparently >without wires. I believe it does the route internally, but I can't really >tell from the manual. There is probably a better manual because I seem to be >seeing just the overview, bur it does appear to not need any cabling. > >Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GRS setup for MONOPLEX to SYSPLEX
According to the manual, you can configure them to be connected apparently without wires. I believe it does the route internally, but I can't really tell from the manual. There is probably a better manual because I seem to be seeing just the overview, bur it does appear to not need any cabling. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GRS setup for MONOPLEX to SYSPLEX
Presumably a FICON wrap-around cable. From: IBM Mainframe Discussion List on behalf of Dana Mitchell Sent: Wednesday, June 21, 2023 3:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GRS setup for MONOPLEX to SYSPLEX On Wed, 21 Jun 2023 09:10:05 -0500, Paul Gorlinsky wrote: >Thanks everyone ... I will try the Backplane method and post results > Sorry, what exactly do you mean by 'Backplane method'? -- 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: GRS setup for MONOPLEX to SYSPLEX
On Wed, 21 Jun 2023 09:10:05 -0500, Paul Gorlinsky wrote: >Thanks everyone ... I will try the Backplane method and post results > Sorry, what exactly do you mean by 'Backplane method'? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GRS setup for MONOPLEX to SYSPLEX
Thanks everyone ... I will try the Backplane method and post results -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GRS setup for MONOPLEX to SYSPLEX
Classification: Confidential I would tak a couple of FICON cables and string them between ports. Not sure about the z/14 hardware design. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gorlinsky Sent: Tuesday, June 20, 2023 8:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GRS setup for MONOPLEX to SYSPLEX [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Can we use the back plain of the z/14 to do the CTC thing? -- 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: GRS setup for MONOPLEX to SYSPLEX
Yes, from the z13 up you are supposed to be able to create the connections. I have not tried it, but it seems to be outlined int he manuals. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GRS setup for MONOPLEX to SYSPLEX
Can we use the back plain of the z/14 to do the CTC thing? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GRS setup for MONOPLEX to SYSPLEX
Classification: Confidential Not my dog, but I would not do that, except under extreme duress. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gibney, Dave Sent: Monday, June 19, 2023 4:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GRS setup for MONOPLEX to SYSPLEX [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Even PDSE can be safely shared. If updates only occur from one LPAR and read-only everywhere else. And, said updates may not be reflected immediately (or until next IPL) in the other read-only LPARs -Original Message- From: IBM Mainframe Discussion List On Behalf Of Radoslaw Skorupka Sent: Monday, June 19, 2023 1:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GRS setup for MONOPLEX to SYSPLEX Yes, PDSE do require SYSPLEX. Not GRS-plex, not CA-MIM (or MII), but SYSPLEX. Reason: PDSE use sysplex communication, not GRS facilities. Regarding to the topic: in order to share datasets you need ...nothing. No parallel sysplex No base sysplex Not even GRSplex No SMSplex Simply nothing except DASD available from several systems. Of course, the more mentioned facilities you have the better sharing is. And yes, in order to share PDSEs (properly) you still have sysplex. However you can share ICF BCSes (catalogs), VSAM, PS, PDS, etc. Note: there are various flavours of sharing. Shared DASD as a data transport method, shared PDSes with jobs, REXX tools, etc. - it can be shared easily, because it is not heavily used. Batch datasets - assuming proper batch windows it is also can be shared easily. For frequent sharing it is good to think about ICF ECS or RLS, etc. -- Radoslaw Skorupka Lodz, Poland W dniu 19.06.2023 o 17:03, Michael Babcock pisze: > Beware of PDSEs. I’m not 100% sure but I think the sandbox needs to > be in the plex to share them. Updating a PDSE outside of the plex can > cause corruption. > > We have our sandbox in the plex just to avoid issues. > > On Mon, Jun 19, 2023 at 9:25 AM Paul Gorlinsky wrote: > >> We have a sandbox system that references TSO user and ISV catalogs >> and datasets. The sandbox has a unique master catalog but shares >> virtually everything else. >> >> It does have access to the couple facility that the Sysplex is using ... >> But it is not a member of the Sysplex. >> >> Is it possible for a monoplex z/OS system to share DASD, user cats, >> etc., with a SYSPLEX via GRS management and coupling facility? -- 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 ::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: GRS setup for MONOPLEX to SYSPLEX
There really is no "safe" way to share DASD without some sort of PLEX, either a full sysplex (with the CF's) or a baisc (baby) sysplex with Ficon adapters as CTC's. Otherwise, Catalog sharing is problematic and PDS/e sharing is not possible, and actually neither is standard PDS sharing of members because multiple people can end up overlaying each other. The reserves alone that will happen in a Sandbox are probably already affecting your other LPARs and you might not even realize it. HSM backups are a good example of something that issues reserves that can slow things down for the systems that aren't doing the backups, but are using those volumes. There are many more issues, too many to list. Can you get away without some sort of Plex? The answer is, if you are careful and don't mind the ENQ's, yes, until you do something that you should not have, in which case you can have a really bad day. The best you can hope for in that situation is that you lock out the other system(s), the worst is that you end up with wrong or corrupt data. It's far too easy (and cheap) to at least set up a basic plex (with ficon ports) than to expose yourself to problems. Honestly, you can use extra Ficon ports or buy a (or a couple) ficon cards on ebay or from some third party hardware (re)seller and have them installed. Connecting things up is extremely easy and quick, plus (since GRS is free) you end up with not only safety, but the ability to route commands from any system to any other system and several other niceties. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SYSPLEX
Google and the document setting a SYSPLEX will walk you through how to set a PLEX up Regards, Steve Beaver -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GRS setup for MONOPLEX to SYSPLEX
Even PDSE can be safely shared. If updates only occur from one LPAR and read-only everywhere else. And, said updates may not be reflected immediately (or until next IPL) in the other read-only LPARs -Original Message- From: IBM Mainframe Discussion List On Behalf Of Radoslaw Skorupka Sent: Monday, June 19, 2023 1:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GRS setup for MONOPLEX to SYSPLEX Yes, PDSE do require SYSPLEX. Not GRS-plex, not CA-MIM (or MII), but SYSPLEX. Reason: PDSE use sysplex communication, not GRS facilities. Regarding to the topic: in order to share datasets you need ...nothing. No parallel sysplex No base sysplex Not even GRSplex No SMSplex Simply nothing except DASD available from several systems. Of course, the more mentioned facilities you have the better sharing is. And yes, in order to share PDSEs (properly) you still have sysplex. However you can share ICF BCSes (catalogs), VSAM, PS, PDS, etc. Note: there are various flavours of sharing. Shared DASD as a data transport method, shared PDSes with jobs, REXX tools, etc. - it can be shared easily, because it is not heavily used. Batch datasets - assuming proper batch windows it is also can be shared easily. For frequent sharing it is good to think about ICF ECS or RLS, etc. -- Radoslaw Skorupka Lodz, Poland W dniu 19.06.2023 o 17:03, Michael Babcock pisze: > Beware of PDSEs. I’m not 100% sure but I think the sandbox needs to > be in the plex to share them. Updating a PDSE outside of the plex can > cause corruption. > > We have our sandbox in the plex just to avoid issues. > > On Mon, Jun 19, 2023 at 9:25 AM Paul Gorlinsky wrote: > >> We have a sandbox system that references TSO user and ISV catalogs >> and datasets. The sandbox has a unique master catalog but shares >> virtually everything else. >> >> It does have access to the couple facility that the Sysplex is using ... >> But it is not a member of the Sysplex. >> >> Is it possible for a monoplex z/OS system to share DASD, user cats, >> etc., with a SYSPLEX via GRS management and coupling facility? -- 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: GRS setup for MONOPLEX to SYSPLEX
It's possible to share some things, but others can only be safely shared within a sysplex. From: IBM Mainframe Discussion List on behalf of Paul Gorlinsky Sent: Monday, June 19, 2023 10:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: GRS setup for MONOPLEX to SYSPLEX We have a sandbox system that references TSO user and ISV catalogs and datasets. The sandbox has a unique master catalog but shares virtually everything else. It does have access to the couple facility that the Sysplex is using ... But it is not a member of the Sysplex. Is it possible for a monoplex z/OS system to share DASD, user cats, etc., with a SYSPLEX via GRS management and coupling facility? Thanks -- 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: GRS setup for MONOPLEX to SYSPLEX
Yes, PDSE do require SYSPLEX. Not GRS-plex, not CA-MIM (or MII), but SYSPLEX. Reason: PDSE use sysplex communication, not GRS facilities. Regarding to the topic: in order to share datasets you need ...nothing. No parallel sysplex No base sysplex Not even GRSplex No SMSplex Simply nothing except DASD available from several systems. Of course, the more mentioned facilities you have the better sharing is. And yes, in order to share PDSEs (properly) you still have sysplex. However you can share ICF BCSes (catalogs), VSAM, PS, PDS, etc. Note: there are various flavours of sharing. Shared DASD as a data transport method, shared PDSes with jobs, REXX tools, etc. - it can be shared easily, because it is not heavily used. Batch datasets - assuming proper batch windows it is also can be shared easily. For frequent sharing it is good to think about ICF ECS or RLS, etc. -- Radoslaw Skorupka Lodz, Poland W dniu 19.06.2023 o 17:03, Michael Babcock pisze: Beware of PDSEs. I’m not 100% sure but I think the sandbox needs to be in the plex to share them. Updating a PDSE outside of the plex can cause corruption. We have our sandbox in the plex just to avoid issues. On Mon, Jun 19, 2023 at 9:25 AM Paul Gorlinsky wrote: We have a sandbox system that references TSO user and ISV catalogs and datasets. The sandbox has a unique master catalog but shares virtually everything else. It does have access to the couple facility that the Sysplex is using ... But it is not a member of the Sysplex. Is it possible for a monoplex z/OS system to share DASD, user cats, etc., with a SYSPLEX via GRS management and coupling facility? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GRS setup for MONOPLEX to SYSPLEX
That’s exactly what we do. We share the SMS config though. On Mon, Jun 19, 2023 at 11:04 AM Paul Gorlinsky wrote: > I think I will do the same ... put in it the PLEX but run with a different > master catalog, spool, etc. > > Thanks > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GRS setup for MONOPLEX to SYSPLEX
I think I will do the same ... put in it the PLEX but run with a different master catalog, spool, etc. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GRS setup for MONOPLEX to SYSPLEX
Beware of PDSEs. I’m not 100% sure but I think the sandbox needs to be in the plex to share them. Updating a PDSE outside of the plex can cause corruption. We have our sandbox in the plex just to avoid issues. On Mon, Jun 19, 2023 at 9:25 AM Paul Gorlinsky wrote: > We have a sandbox system that references TSO user and ISV catalogs and > datasets. The sandbox has a unique master catalog but shares virtually > everything else. > > It does have access to the couple facility that the Sysplex is using ... > But it is not a member of the Sysplex. > > Is it possible for a monoplex z/OS system to share DASD, user cats, etc., > with a SYSPLEX via GRS management and coupling facility? > > Thanks > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GRS setup for MONOPLEX to SYSPLEX
Yes but the monoplex needs to communicate over CTCs to the SYSPLEX. Sent from my iPhone > On Jun 19, 2023, at 10:25 AM, Paul Gorlinsky wrote: > > We have a sandbox system that references TSO user and ISV catalogs and > datasets. The sandbox has a unique master catalog but shares virtually > everything else. > > It does have access to the couple facility that the Sysplex is using ... But > it is not a member of the Sysplex. > > Is it possible for a monoplex z/OS system to share DASD, user cats, etc., > with a SYSPLEX via GRS management and coupling facility? > > Thanks > > -- > 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
GRS setup for MONOPLEX to SYSPLEX
We have a sandbox system that references TSO user and ISV catalogs and datasets. The sandbox has a unique master catalog but shares virtually everything else. It does have access to the couple facility that the Sysplex is using ... But it is not a member of the Sysplex. Is it possible for a monoplex z/OS system to share DASD, user cats, etc., with a SYSPLEX via GRS management and coupling facility? Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
This is a vendor package. Upon asking they said they only support RLS for sharing. So there are no other options. On Wed, Mar 8, 2023, 2:58 PM Dale R. Smith > > IBM has a product called "CICS VSAM Transparency for z/OS" that claims you > can migrate VSAM Files to Db2 Tables without having to change any program > code. > https://www.ibm.com/support/pages/ibm-cics-vsam-transparency-zos > > From the web page: > > IBM CICS VSAM Transparency for z/OS > > Helps you migrate valuable data from VSAM files to Db2 tables in a manner > that can evolve as business needs change > > IBM® CICS® VSAM Transparency helps you move valuable data from VSAM files > to Db2® tables. This migration can evolve as your business requirements > dictate, without having to modify your CICS® and batch VSAM application > programs. You can access the Db2® data 24x7, as well as integrate your data > with new and existing Db2® applications, preserving your core investments > and avoiding costly application rewrites. > > I'm sure it's not cheap, but it would allow you to share the data and it > may be cheaper than what you would need to do to share a VSAM file. > > I have no experience with the product so I don't know if it works as > advertised. > > -- > Dale R. Smith > > -- > 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: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
Hadn't considered that. Based on what the outsourcer has advised us I doubt this has even crossed their mind. On Thu, Mar 9, 2023, 6:19 PM Timothy Sipples wrote: > The only other thing I can think of is that some operators (some > outsourcers for example) might not have — or know how to perform — capacity > measurement, planning, chargeback accounting (ugh!), or contractual > arrangements when running the CFCC on general purpose processors (CPs). > Those are not a technical limitations. You/they can do all of that for CF > workloads straightforwardly. But those "technobusiness" factors might > explain some reticence if you're observing any. > > — — — — — > Timothy Sipples > Senior Architect > Digital Assets, Industry Solutions, and Cybersecurity > IBM zSystems/LinuxONE, Asia-Pacific > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
The only other thing I can think of is that some operators (some outsourcers for example) might not have — or know how to perform — capacity measurement, planning, chargeback accounting (ugh!), or contractual arrangements when running the CFCC on general purpose processors (CPs). Those are not a technical limitations. You/they can do all of that for CF workloads straightforwardly. But those "technobusiness" factors might explain some reticence if you're observing any. — — — — — Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM zSystems/LinuxONE, Asia-Pacific 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
Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
That is my view. The application team won't care if the application is performing slowly since this is just a functional test. It means a path to HA on the production server. And in my view it doesn't matter if the engine is an ICF of GP - the load is going to be low on it. On Thu, Mar 9, 2023 at 3:49 AM Martin Packer wrote: > You don’t need a dedicated engine to test CF – unless your test is a > Performance test. And then possibly a single one wouldn’t be helpful. > Function test should be fine with any old engine. > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
You don’t need a dedicated engine to test CF – unless your test is a Performance test. And then possibly a single one wouldn’t be helpful. Function test should be fine with any old engine. From: IBM Mainframe Discussion List on behalf of Laurence Chiu Date: Sunday, 5 March 2023 at 14:05 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's? The debate I am having with the outsourcer is whether or not it's feasible or even practical to run a test CF on a general purpose engine. They say it requires a dedicated engine and I think that is nonsense! If I can get that over the line (and that is the challenge) then I can suggest what you recommended below. And since I don't need one CF, I might need even fewer resources. On Sun, Mar 5, 2023 at 5:39 PM Mike Schwab wrote: > To avoid impacting other systems, I would drop your LPAR weights by a > total of 6%, trim your LPAR memory to reuse for the ICFs, then create > your two ICF partitions with 3% of 1 CPU and the reclaimed memory.. > > On Sat, Mar 4, 2023 at 2:55 PM Laurence Chiu wrote: > > > > Thanks for the input. > > > > > > On Sun, Mar 5, 2023 at 7:41 AM Mike Schwab > wrote: > > > > > > > > > https://www.researchgate.net/publication/342570694_Coupling_Facility_Configuration_Options_-_Updated_2020 > > > > > > > I am familiar with that document and even provided a copy to our > outsourcer > > to read but clearly they hadn't > > > > This is a direct link to IBM for that document. > > > > https://www.ibm.com/downloads/cas/JZB2E38Q > > > > > > > > > CF is not counted on SCRT, shown on RMF reports. > > > Won't cost you on z/OS, may on some vendors. > > > > > > > I don't care so much as this CF is only System B and for development so > > using a general purpose engine is not an issue for us. The MSU charges > are > > going to be low and we are prepared to pay those if it gets us our > parallel > > sysplex > > > > > > > > > Thin CFs go to enabled wait when work is completed, restart when > > > interrupt says there is work. > > > > > > Estimate is 3% light sharing to 13% heaving sharing (of z/OS workload). > > > > > > Thin CF would use internal links so no I/O overhead to another CPU. > > > > > > For the testing CF on the same system as the test Sysplex that is fine. > > But they say there are no spare links from System B to System A if I > wanted > > to run a test Sysplex on System B and access a CF on System A. > > > > This is their response I had to manage > > > > > > To give an idea of what I am facing, this is their response to my > proposals. > > > > Using a General Purpose CP (GCP) as a coupling facility on System B(z13 > at > > WithDrawn From Marketing Licensed Internal Code) > > • There are no spare unallocated GCP on System B i.e no “parked” GCP. > > • All GCP’s, on System B, are allocated as shared, across all LPARS. i.e. > > no dedicated GCP’s. > > • Sharing GCP’s to use for z/OS and as a coupling facility is strongly > not > > recommended FYI coupling facility engines run CFCC (coupling facility > > control code) rather than z/OS. > > • This possibly I believe is now exhausted. > > > > I think all these points are contestable, specially after reading the IBM > > document from a specialist in this area > > > > I just need to get some authoritative voice onto the case, ideally the > > author of the document but that might not be easy. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > -- > 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 Unless otherwise stated above: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
CICS/VSAM transparency may not solve this problem. You would need to implement DB2 data sharing and that's not simple if you don't already use data sharing. ISI Pty in Melbourne also market a VSAM transparency product. I supported this product for many years and it is still in use at one large Australian bank. The ISI version works better than the IBM product which was a bought-in product from a 3rd party vendor. For less complex VSAM applications, I considered trying to transform VSAM read/writes to CF equivalents because the code path overhead is large for high volume VSAM I/O. The magic is in the intercepts for batch and CICS. On Wed, Mar 8, 2023 at 12:57 PM Dale R. Smith wrote: > On Wed, 8 Mar 2023 11:35:09 +1300, Laurence Chiu wrote: > > >Just to explain why we need two LPARs. The application uses a VSAM dataset > >which is updated for all incoming transactions. If we want to run two > >instances of that application on two different LPARs to provide > >availability even if one of the LPARs goes offline for any reason, then > the > >VSAM dataset needs to be shared across the two instances when both are > >running to support concurrent access. > > > >The only other option for the two LPARs on the same CEC is possibly VSAM > >ShareOptions but given this is a package from a vendor, it might not be > >coded to support the right queueing and de-queueing of access to that > >dataset. > > IBM has a product called "CICS VSAM Transparency for z/OS" that claims you > can migrate VSAM Files to Db2 Tables without having to change any program > code. > https://www.ibm.com/support/pages/ibm-cics-vsam-transparency-zos > > From the web page: > > IBM CICS VSAM Transparency for z/OS > > Helps you migrate valuable data from VSAM files to Db2 tables in a manner > that can evolve as business needs change > > IBM® CICS® VSAM Transparency helps you move valuable data from VSAM files > to Db2® tables. This migration can evolve as your business requirements > dictate, without having to modify your CICS® and batch VSAM application > programs. You can access the Db2® data 24x7, as well as integrate your data > with new and existing Db2® applications, preserving your core investments > and avoiding costly application rewrites. > > I'm sure it's not cheap, but it would allow you to share the data and it > may be cheaper than what you would need to do to share a VSAM file. > > I have no experience with the product so I don't know if it works as > advertised. > > -- > Dale R. Smith > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
On Wed, 8 Mar 2023 11:35:09 +1300, Laurence Chiu wrote: >Just to explain why we need two LPARs. The application uses a VSAM dataset >which is updated for all incoming transactions. If we want to run two >instances of that application on two different LPARs to provide >availability even if one of the LPARs goes offline for any reason, then the >VSAM dataset needs to be shared across the two instances when both are >running to support concurrent access. > >The only other option for the two LPARs on the same CEC is possibly VSAM >ShareOptions but given this is a package from a vendor, it might not be >coded to support the right queueing and de-queueing of access to that >dataset. IBM has a product called "CICS VSAM Transparency for z/OS" that claims you can migrate VSAM Files to Db2 Tables without having to change any program code. https://www.ibm.com/support/pages/ibm-cics-vsam-transparency-zos From the web page: IBM CICS VSAM Transparency for z/OS Helps you migrate valuable data from VSAM files to Db2 tables in a manner that can evolve as business needs change IBM® CICS® VSAM Transparency helps you move valuable data from VSAM files to Db2® tables. This migration can evolve as your business requirements dictate, without having to modify your CICS® and batch VSAM application programs. You can access the Db2® data 24x7, as well as integrate your data with new and existing Db2® applications, preserving your core investments and avoiding costly application rewrites. I'm sure it's not cheap, but it would allow you to share the data and it may be cheaper than what you would need to do to share a VSAM file. I have no experience with the product so I don't know if it works as advertised. -- Dale R. Smith -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
Just to explain why we need two LPARs. The application uses a VSAM dataset which is updated for all incoming transactions. If we want to run two instances of that application on two different LPARs to provide availability even if one of the LPARs goes offline for any reason, then the VSAM dataset needs to be shared across the two instances when both are running to support concurrent access. The only other option for the two LPARs on the same CEC is possibly VSAM ShareOptions but given this is a package from a vendor, it might not be coded to support the right queueing and de-queueing of access to that dataset. > .. > > 2. Just in case there's any confusion VSAM RLS (and Transactional > VSAM, i.e. z/OS DFSMStvs) do(es) not require two or more z/OS instances. A > single z/OS instance with a single CF is the minimum configuration for > those VSAM features. > > 3. If you do run two or more z/OS instances (a "Parallel Sysplex in a > box") that can be a lovely configuration, but just bear in mind if the site > or machine go offline (planned or unplanned) then you lose the whole > Sysplex. Nonetheless a "Parallel Sysplex in a box" provides a great deal of > value in terms of protecting against various software-related issues that > would affect service availability if you only had one z/OS instance. > Hypothetically a single CF could topple over and/or require a planned > outage even without anything else going offline, but even with one CF the > "Parallel Sysplex in a box" is rather good. > > 4. Check for and apply all relevant firmware, z/OS, and middleware updates > (of course). > > — — — — — > Timothy Sipples > Senior Architect > Digital Assets, Industry Solutions, and Cybersecurity > IBM zSystems/LinuxONE, Asia-Pacific > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
This is very helpful, thanks. Plus I have the document which is an IBM official document. On Tue, Mar 7, 2023 at 10:07 AM Attila Fogarasi wrote: > Perhaps your outsourcer will accept recommendations by IBM in an official > apar, see https://www.ibm.com/support/pages/apar/II09294 > This says in part "If you can accept slower response times or occasional > slower > > response times and the load is not too great, CFs in shared > LPs may be a viable alternative to running CFs with DEDICATED > CP resources." > > > On Tue, Mar 7, 2023 at 12:04 AM Allan Staller < > 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > > > Classification: Confidential > > > > The "spare" ICF engine on the "A" box could be shared between *your* > > test/production sysplexes. > > > > HTH > > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf > > Of Laurence Chiu > > Sent: Friday, March 3, 2023 9:34 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Running a Coupling Facility using a CP for a test Parallel > > Sysplex 0 anyh gotcha's? > > > > [CAUTION: This Email is from outside the Organization. Unless you trust > > the sender, Don't click links or open attachments as it may be a Phishing > > email, which can steal your Information and compromise your Computer.] > > > > The situation. > > > > We share a couple of Z13's with another (larger client). Z13 B is where > we > > run our development LPARs and Z13 A is production. > > > > For critical business reasons an online application on our production > LPAR > > needs to be highly available and that means in a parallel sysplex. But > our > > outsourcer has told us it cannot be done for the following reasons > because > > there are no spare ICF engines on the host B - all are being used by > other > > CF instances, either to support production Sysplexes or development ones > > (not ours). > > > > Host A does potentially have a spare ICF engine we could use to support a > > production parallel Sysplex but good practice does recommend you create a > > test one first of course. > > > > I then asked the question, if host A has a spare ICF engine, can't it be > > used to support a CF to be used by the test Sysplex on B. I was advised > > this was not possible since there are no spare connections between host A > > and Host B (Infiniband possibly) so the Sysplex on B could not actually > > communicate with the CF on A. > > > > Our requirement for the Sysplex is primarily to be able to share a VSAM > > dataset which is hit every time a transaction comes in with a peak of > about > > 99tps. So we would need VSAM RLS to share the dataset records between the > > two application instances. There is no DB2, CICS or IMS so I think the > only > > structures in the CF are those to support VSAM RLS, maybe some XCF > > structures and core systems. > > > > Knowing that we would only bring up the test sysplex to make sure > > transactions routed correctly across the two LPARs and most of the time > we > > would have one member of the Sysplex off, I suggested that the test CF > > could be built using a CP. To this suggestion I received the following > > (anti) advice > > - there would be MSU costs (we don't care since we think the MIPS load on > > the CF would be low). Plus we would ask that the CF be defined with > Dynamic > > Coupling Facility Dispatch and set DYNDISP=THIN. Since that CF is going > to > > be idling most of the time, MSU consumption is not going to be a major > cost. > > - it's strongly recommended not to do this by IBM. Yet when I read this > > document > > > > > > > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdownloads%2Fcas%2FJZB2E38Q=05%7C01%7Callan.staller%40HCL.COM%7C1962ff1c13d7410924a708db1c617020%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C638134977066659942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=78DxD9grmMmrALQNItds2OaQ6Eyuv43mGVh5%2BoeqQnk%3D=0 > > the option is discussed in great detail and the only negatives are the > > incurring of MSU costs and some performance degradation if both a z/OS > and > > CF LPAR are trying to use the same CP at the same time. But this can be > > managed. > > > > - that a CF running on a CP would need a dedicated CP engine and there > are > > no spare engines in host B. That totally flies against the information I > > have read from IBM docs. > > > > Of cours
Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
That is what I suggested and I was told there were no spare "connections" between the two hosts but they didn't elaborate. I have been asked if those connections are ICA-SR or IFB and reading the manual linked in this thread, I think they are IFB since that is what is supported on the Z13's. If that is the case then it seems they can be shared but I have no way of knowing what the actual connections are. On Tue, Mar 7, 2023 at 2:04 AM Allan Staller < 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > Classification: Confidential > > The "spare" ICF engine on the "A" box could be shared between *your* > test/production sysplexes. > > HTH > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Laurence Chiu > Sent: Friday, March 3, 2023 9:34 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Running a Coupling Facility using a CP for a test Parallel > Sysplex 0 anyh gotcha's? > > [CAUTION: This Email is from outside the Organization. Unless you trust > the sender, Don't click links or open attachments as it may be a Phishing > email, which can steal your Information and compromise your Computer.] > > The situation. > > We share a couple of Z13's with another (larger client). Z13 B is where we > run our development LPARs and Z13 A is production. > > For critical business reasons an online application on our production LPAR > needs to be highly available and that means in a parallel sysplex. But our > outsourcer has told us it cannot be done for the following reasons because > there are no spare ICF engines on the host B - all are being used by other > CF instances, either to support production Sysplexes or development ones > (not ours). > > Host A does potentially have a spare ICF engine we could use to support a > production parallel Sysplex but good practice does recommend you create a > test one first of course. > > I then asked the question, if host A has a spare ICF engine, can't it be > used to support a CF to be used by the test Sysplex on B. I was advised > this was not possible since there are no spare connections between host A > and Host B (Infiniband possibly) so the Sysplex on B could not actually > communicate with the CF on A. > > Our requirement for the Sysplex is primarily to be able to share a VSAM > dataset which is hit every time a transaction comes in with a peak of about > 99tps. So we would need VSAM RLS to share the dataset records between the > two application instances. There is no DB2, CICS or IMS so I think the only > structures in the CF are those to support VSAM RLS, maybe some XCF > structures and core systems. > > Knowing that we would only bring up the test sysplex to make sure > transactions routed correctly across the two LPARs and most of the time we > would have one member of the Sysplex off, I suggested that the test CF > could be built using a CP. To this suggestion I received the following > (anti) advice > - there would be MSU costs (we don't care since we think the MIPS load on > the CF would be low). Plus we would ask that the CF be defined with Dynamic > Coupling Facility Dispatch and set DYNDISP=THIN. Since that CF is going to > be idling most of the time, MSU consumption is not going to be a major cost. > - it's strongly recommended not to do this by IBM. Yet when I read this > document > > > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdownloads%2Fcas%2FJZB2E38Q=05%7C01%7Callan.staller%40HCL.COM%7C1962ff1c13d7410924a708db1c617020%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C638134977066659942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=78DxD9grmMmrALQNItds2OaQ6Eyuv43mGVh5%2BoeqQnk%3D=0 > the option is discussed in great detail and the only negatives are the > incurring of MSU costs and some performance degradation if both a z/OS and > CF LPAR are trying to use the same CP at the same time. But this can be > managed. > > - that a CF running on a CP would need a dedicated CP engine and there are > no spare engines in host B. That totally flies against the information I > have read from IBM docs. > > Of course for production the CF on host A would be configured to use an > ICF engine (or share one) > > Finally, while I accepted the argument at the time there were no > connections between Host A and Host B, further reading suggests that you do > not need to dedicate channels for communications but use XCF or by using > Infiniband sub channels or sharing the same physical link with more than > one Sysplex. Then the issue of running the CF on a CP goes away since I can > ask for two CF's to be defined on ho
Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
ICF Thin interrupts introduced at level 19 for z12+ https://www.ibm.com/downloads/cas/JZB2E38Q On Mon, Mar 6, 2023 at 3:36 PM Gibney, Dave <03b5261cfd78-dmarc-requ...@listserv.ua.edu> wrote: > > Does an OOS z13 support ICF thin provisioning with nterrupts? > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Mike Schwab > > Sent: Monday, March 6, 2023 1:12 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Running a Coupling Facility using a CP for a test Parallel > > Sysplex 0 > > anyh gotcha's? > > > > And this was long before Thin ICF provisioning on a CP with interrupts. > > > > On Mon, Mar 6, 2023 at 3:07 PM Attila Fogarasi wrote: > > > > > > Perhaps your outsourcer will accept recommendations by IBM in an official > > > apar, see > > https://urldefense.com/v3/__https://www.ibm.com/support/pages/apar/II > > 09294__;!!JmPEgBY0HMszNaDT!pc-N5jQe_vQoNsN9-04ykQN3SVPA3-- > > zfrRMvdLg48EaghVAdve13YxtLv7URiG7JmKVX-gL1XSkd75g6Li7Hg$ > > > This says in part "If you can accept slower response times or occasional > > > slower > > > > > > response times and the load is not too great, CFs in shared > > > LPs may be a viable alternative to running CFs with DEDICATED > > > CP resources." > > > > > > > > > On Tue, Mar 7, 2023 at 12:04 AM Allan Staller < > > > 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > > > > > > > Classification: Confidential > > > > > > > > The "spare" ICF engine on the "A" box could be shared between *your* > > > > test/production sysplexes. > > > > > > > > HTH > > > > > > > > -Original Message- > > > > From: IBM Mainframe Discussion List > > On Behalf > > > > Of Laurence Chiu > > > > Sent: Friday, March 3, 2023 9:34 PM > > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > > Subject: Running a Coupling Facility using a CP for a test Parallel > > > > Sysplex 0 anyh gotcha's? > > > > > > > > [CAUTION: This Email is from outside the Organization. Unless you trust > > > > the sender, Don't click links or open attachments as it may be a > > > > Phishing > > > > email, which can steal your Information and compromise your > > Computer.] > > > > > > > > The situation. > > > > > > > > We share a couple of Z13's with another (larger client). Z13 B is where > > > > we > > > > run our development LPARs and Z13 A is production. > > > > > > > > For critical business reasons an online application on our production > > > > LPAR > > > > needs to be highly available and that means in a parallel sysplex. But > > > > our > > > > outsourcer has told us it cannot be done for the following reasons > > because > > > > there are no spare ICF engines on the host B - all are being used by > > > > other > > > > CF instances, either to support production Sysplexes or development > > ones > > > > (not ours). > > > > > > > > Host A does potentially have a spare ICF engine we could use to support > > > > a > > > > production parallel Sysplex but good practice does recommend you > > create a > > > > test one first of course. > > > > > > > > I then asked the question, if host A has a spare ICF engine, can't it be > > > > used to support a CF to be used by the test Sysplex on B. I was advised > > > > this was not possible since there are no spare connections between host > > A > > > > and Host B (Infiniband possibly) so the Sysplex on B could not actually > > > > communicate with the CF on A. > > > > > > > > Our requirement for the Sysplex is primarily to be able to share a VSAM > > > > dataset which is hit every time a transaction comes in with a peak of > > about > > > > 99tps. So we would need VSAM RLS to share the dataset records > > between the > > > > two application instances. There is no DB2, CICS or IMS so I think the > > > > only > > > > structures in the CF are those to support VSAM RLS, maybe some XCF > > > > structures and core systems. > > > > > > > > Knowing that we would only bring up the test sysplex to make sure > > > > transactions routed correctly across the
Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
Does an OOS z13 support ICF thin provisioning with nterrupts? > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Mike Schwab > Sent: Monday, March 6, 2023 1:12 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Running a Coupling Facility using a CP for a test Parallel > Sysplex 0 > anyh gotcha's? > > And this was long before Thin ICF provisioning on a CP with interrupts. > > On Mon, Mar 6, 2023 at 3:07 PM Attila Fogarasi wrote: > > > > Perhaps your outsourcer will accept recommendations by IBM in an official > > apar, see > https://urldefense.com/v3/__https://www.ibm.com/support/pages/apar/II > 09294__;!!JmPEgBY0HMszNaDT!pc-N5jQe_vQoNsN9-04ykQN3SVPA3-- > zfrRMvdLg48EaghVAdve13YxtLv7URiG7JmKVX-gL1XSkd75g6Li7Hg$ > > This says in part "If you can accept slower response times or occasional > > slower > > > > response times and the load is not too great, CFs in shared > > LPs may be a viable alternative to running CFs with DEDICATED > > CP resources." > > > > > > On Tue, Mar 7, 2023 at 12:04 AM Allan Staller < > > 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > > > > > Classification: Confidential > > > > > > The "spare" ICF engine on the "A" box could be shared between *your* > > > test/production sysplexes. > > > > > > HTH > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List > On Behalf > > > Of Laurence Chiu > > > Sent: Friday, March 3, 2023 9:34 PM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Running a Coupling Facility using a CP for a test Parallel > > > Sysplex 0 anyh gotcha's? > > > > > > [CAUTION: This Email is from outside the Organization. Unless you trust > > > the sender, Don't click links or open attachments as it may be a Phishing > > > email, which can steal your Information and compromise your > Computer.] > > > > > > The situation. > > > > > > We share a couple of Z13's with another (larger client). Z13 B is where we > > > run our development LPARs and Z13 A is production. > > > > > > For critical business reasons an online application on our production LPAR > > > needs to be highly available and that means in a parallel sysplex. But > > > our > > > outsourcer has told us it cannot be done for the following reasons > because > > > there are no spare ICF engines on the host B - all are being used by other > > > CF instances, either to support production Sysplexes or development > ones > > > (not ours). > > > > > > Host A does potentially have a spare ICF engine we could use to support a > > > production parallel Sysplex but good practice does recommend you > create a > > > test one first of course. > > > > > > I then asked the question, if host A has a spare ICF engine, can't it be > > > used to support a CF to be used by the test Sysplex on B. I was advised > > > this was not possible since there are no spare connections between host > A > > > and Host B (Infiniband possibly) so the Sysplex on B could not actually > > > communicate with the CF on A. > > > > > > Our requirement for the Sysplex is primarily to be able to share a VSAM > > > dataset which is hit every time a transaction comes in with a peak of > about > > > 99tps. So we would need VSAM RLS to share the dataset records > between the > > > two application instances. There is no DB2, CICS or IMS so I think the > > > only > > > structures in the CF are those to support VSAM RLS, maybe some XCF > > > structures and core systems. > > > > > > Knowing that we would only bring up the test sysplex to make sure > > > transactions routed correctly across the two LPARs and most of the time > we > > > would have one member of the Sysplex off, I suggested that the test CF > > > could be built using a CP. To this suggestion I received the following > > > (anti) advice > > > - there would be MSU costs (we don't care since we think the MIPS load > on > > > the CF would be low). Plus we would ask that the CF be defined with > Dynamic > > > Coupling Facility Dispatch and set DYNDISP=THIN. Since that CF is going to > > > be idling most of the time, MSU consumption is not going to be a major > cost. > > > - it's strongly recommended not to do this by IBM. Yet when I read this > > > document > > > > > > >
Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
And this was long before Thin ICF provisioning on a CP with interrupts. On Mon, Mar 6, 2023 at 3:07 PM Attila Fogarasi wrote: > > Perhaps your outsourcer will accept recommendations by IBM in an official > apar, see https://www.ibm.com/support/pages/apar/II09294 > This says in part "If you can accept slower response times or occasional > slower > > response times and the load is not too great, CFs in shared > LPs may be a viable alternative to running CFs with DEDICATED > CP resources." > > > On Tue, Mar 7, 2023 at 12:04 AM Allan Staller < > 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > > > Classification: Confidential > > > > The "spare" ICF engine on the "A" box could be shared between *your* > > test/production sysplexes. > > > > HTH > > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf > > Of Laurence Chiu > > Sent: Friday, March 3, 2023 9:34 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Running a Coupling Facility using a CP for a test Parallel > > Sysplex 0 anyh gotcha's? > > > > [CAUTION: This Email is from outside the Organization. Unless you trust > > the sender, Don't click links or open attachments as it may be a Phishing > > email, which can steal your Information and compromise your Computer.] > > > > The situation. > > > > We share a couple of Z13's with another (larger client). Z13 B is where we > > run our development LPARs and Z13 A is production. > > > > For critical business reasons an online application on our production LPAR > > needs to be highly available and that means in a parallel sysplex. But our > > outsourcer has told us it cannot be done for the following reasons because > > there are no spare ICF engines on the host B - all are being used by other > > CF instances, either to support production Sysplexes or development ones > > (not ours). > > > > Host A does potentially have a spare ICF engine we could use to support a > > production parallel Sysplex but good practice does recommend you create a > > test one first of course. > > > > I then asked the question, if host A has a spare ICF engine, can't it be > > used to support a CF to be used by the test Sysplex on B. I was advised > > this was not possible since there are no spare connections between host A > > and Host B (Infiniband possibly) so the Sysplex on B could not actually > > communicate with the CF on A. > > > > Our requirement for the Sysplex is primarily to be able to share a VSAM > > dataset which is hit every time a transaction comes in with a peak of about > > 99tps. So we would need VSAM RLS to share the dataset records between the > > two application instances. There is no DB2, CICS or IMS so I think the only > > structures in the CF are those to support VSAM RLS, maybe some XCF > > structures and core systems. > > > > Knowing that we would only bring up the test sysplex to make sure > > transactions routed correctly across the two LPARs and most of the time we > > would have one member of the Sysplex off, I suggested that the test CF > > could be built using a CP. To this suggestion I received the following > > (anti) advice > > - there would be MSU costs (we don't care since we think the MIPS load on > > the CF would be low). Plus we would ask that the CF be defined with Dynamic > > Coupling Facility Dispatch and set DYNDISP=THIN. Since that CF is going to > > be idling most of the time, MSU consumption is not going to be a major cost. > > - it's strongly recommended not to do this by IBM. Yet when I read this > > document > > > > > > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdownloads%2Fcas%2FJZB2E38Q=05%7C01%7Callan.staller%40HCL.COM%7C1962ff1c13d7410924a708db1c617020%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C638134977066659942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=78DxD9grmMmrALQNItds2OaQ6Eyuv43mGVh5%2BoeqQnk%3D=0 > > the option is discussed in great detail and the only negatives are the > > incurring of MSU costs and some performance degradation if both a z/OS and > > CF LPAR are trying to use the same CP at the same time. But this can be > > managed. > > > > - that a CF running on a CP would need a dedicated CP engine and there are > > no spare engines in host B. That totally flies against the information I > > have read from IBM docs. > > > > Of course for production the CF on host A would be configured to use an > >
Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
Perhaps your outsourcer will accept recommendations by IBM in an official apar, see https://www.ibm.com/support/pages/apar/II09294 This says in part "If you can accept slower response times or occasional slower response times and the load is not too great, CFs in shared LPs may be a viable alternative to running CFs with DEDICATED CP resources." On Tue, Mar 7, 2023 at 12:04 AM Allan Staller < 0387911dea17-dmarc-requ...@listserv.ua.edu> wrote: > Classification: Confidential > > The "spare" ICF engine on the "A" box could be shared between *your* > test/production sysplexes. > > HTH > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Laurence Chiu > Sent: Friday, March 3, 2023 9:34 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Running a Coupling Facility using a CP for a test Parallel > Sysplex 0 anyh gotcha's? > > [CAUTION: This Email is from outside the Organization. Unless you trust > the sender, Don't click links or open attachments as it may be a Phishing > email, which can steal your Information and compromise your Computer.] > > The situation. > > We share a couple of Z13's with another (larger client). Z13 B is where we > run our development LPARs and Z13 A is production. > > For critical business reasons an online application on our production LPAR > needs to be highly available and that means in a parallel sysplex. But our > outsourcer has told us it cannot be done for the following reasons because > there are no spare ICF engines on the host B - all are being used by other > CF instances, either to support production Sysplexes or development ones > (not ours). > > Host A does potentially have a spare ICF engine we could use to support a > production parallel Sysplex but good practice does recommend you create a > test one first of course. > > I then asked the question, if host A has a spare ICF engine, can't it be > used to support a CF to be used by the test Sysplex on B. I was advised > this was not possible since there are no spare connections between host A > and Host B (Infiniband possibly) so the Sysplex on B could not actually > communicate with the CF on A. > > Our requirement for the Sysplex is primarily to be able to share a VSAM > dataset which is hit every time a transaction comes in with a peak of about > 99tps. So we would need VSAM RLS to share the dataset records between the > two application instances. There is no DB2, CICS or IMS so I think the only > structures in the CF are those to support VSAM RLS, maybe some XCF > structures and core systems. > > Knowing that we would only bring up the test sysplex to make sure > transactions routed correctly across the two LPARs and most of the time we > would have one member of the Sysplex off, I suggested that the test CF > could be built using a CP. To this suggestion I received the following > (anti) advice > - there would be MSU costs (we don't care since we think the MIPS load on > the CF would be low). Plus we would ask that the CF be defined with Dynamic > Coupling Facility Dispatch and set DYNDISP=THIN. Since that CF is going to > be idling most of the time, MSU consumption is not going to be a major cost. > - it's strongly recommended not to do this by IBM. Yet when I read this > document > > > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdownloads%2Fcas%2FJZB2E38Q=05%7C01%7Callan.staller%40HCL.COM%7C1962ff1c13d7410924a708db1c617020%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C638134977066659942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=78DxD9grmMmrALQNItds2OaQ6Eyuv43mGVh5%2BoeqQnk%3D=0 > the option is discussed in great detail and the only negatives are the > incurring of MSU costs and some performance degradation if both a z/OS and > CF LPAR are trying to use the same CP at the same time. But this can be > managed. > > - that a CF running on a CP would need a dedicated CP engine and there are > no spare engines in host B. That totally flies against the information I > have read from IBM docs. > > Of course for production the CF on host A would be configured to use an > ICF engine (or share one) > > Finally, while I accepted the argument at the time there were no > connections between Host A and Host B, further reading suggests that you do > not need to dedicate channels for communications but use XCF or by using > Infiniband sub channels or sharing the same physical link with more than > one Sysplex. Then the issue of running the CF on a CP goes away since I can > ask for two CF's to be defined on host A, one for production and one for > test and DCFC ensures that that production CF is not impacted by the
Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
Classification: Confidential The "spare" ICF engine on the "A" box could be shared between *your* test/production sysplexes. HTH -Original Message- From: IBM Mainframe Discussion List On Behalf Of Laurence Chiu Sent: Friday, March 3, 2023 9:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's? [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don't click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] The situation. We share a couple of Z13's with another (larger client). Z13 B is where we run our development LPARs and Z13 A is production. For critical business reasons an online application on our production LPAR needs to be highly available and that means in a parallel sysplex. But our outsourcer has told us it cannot be done for the following reasons because there are no spare ICF engines on the host B - all are being used by other CF instances, either to support production Sysplexes or development ones (not ours). Host A does potentially have a spare ICF engine we could use to support a production parallel Sysplex but good practice does recommend you create a test one first of course. I then asked the question, if host A has a spare ICF engine, can't it be used to support a CF to be used by the test Sysplex on B. I was advised this was not possible since there are no spare connections between host A and Host B (Infiniband possibly) so the Sysplex on B could not actually communicate with the CF on A. Our requirement for the Sysplex is primarily to be able to share a VSAM dataset which is hit every time a transaction comes in with a peak of about 99tps. So we would need VSAM RLS to share the dataset records between the two application instances. There is no DB2, CICS or IMS so I think the only structures in the CF are those to support VSAM RLS, maybe some XCF structures and core systems. Knowing that we would only bring up the test sysplex to make sure transactions routed correctly across the two LPARs and most of the time we would have one member of the Sysplex off, I suggested that the test CF could be built using a CP. To this suggestion I received the following (anti) advice - there would be MSU costs (we don't care since we think the MIPS load on the CF would be low). Plus we would ask that the CF be defined with Dynamic Coupling Facility Dispatch and set DYNDISP=THIN. Since that CF is going to be idling most of the time, MSU consumption is not going to be a major cost. - it's strongly recommended not to do this by IBM. Yet when I read this document https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdownloads%2Fcas%2FJZB2E38Q=05%7C01%7Callan.staller%40HCL.COM%7C1962ff1c13d7410924a708db1c617020%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C638134977066659942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=78DxD9grmMmrALQNItds2OaQ6Eyuv43mGVh5%2BoeqQnk%3D=0 the option is discussed in great detail and the only negatives are the incurring of MSU costs and some performance degradation if both a z/OS and CF LPAR are trying to use the same CP at the same time. But this can be managed. - that a CF running on a CP would need a dedicated CP engine and there are no spare engines in host B. That totally flies against the information I have read from IBM docs. Of course for production the CF on host A would be configured to use an ICF engine (or share one) Finally, while I accepted the argument at the time there were no connections between Host A and Host B, further reading suggests that you do not need to dedicate channels for communications but use XCF or by using Infiniband sub channels or sharing the same physical link with more than one Sysplex. Then the issue of running the CF on a CP goes away since I can ask for two CF's to be defined on host A, one for production and one for test and DCFC ensures that that production CF is not impacted by the development one. A lot to digest here but I really want to have some authoritative data in order to refute most of the comments being our outsourcer. Thanks -- 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 liabili
Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
I think you've covered most of the bases. A few points from me: 1. If you can afford to dedicate a whole engine to the production Coupling Facility — at least for the intervals when you're using the production CF "nontrivially" — then that'd be ideal. But if you cannot afford a whole engine (general purpose processor in this case) then see how your testing goes. The basic point is you really don't want production z/OS to stall, waiting for CF services. 2. Just in case there's any confusion VSAM RLS (and Transactional VSAM, i.e. z/OS DFSMStvs) do(es) not require two or more z/OS instances. A single z/OS instance with a single CF is the minimum configuration for those VSAM features. 3. If you do run two or more z/OS instances (a "Parallel Sysplex in a box") that can be a lovely configuration, but just bear in mind if the site or machine go offline (planned or unplanned) then you lose the whole Sysplex. Nonetheless a "Parallel Sysplex in a box" provides a great deal of value in terms of protecting against various software-related issues that would affect service availability if you only had one z/OS instance. Hypothetically a single CF could topple over and/or require a planned outage even without anything else going offline, but even with one CF the "Parallel Sysplex in a box" is rather good. 4. Check for and apply all relevant firmware, z/OS, and middleware updates (of course). — — — — — Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM zSystems/LinuxONE, Asia-Pacific 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
Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
Since you will be the only user, no one else will be impacted. On Sun, Mar 5, 2023 at 3:49 PM Laurence Chiu wrote: > > That's the debate I'm having. The CF is only to support VSAM RLS and most > of the time only one member of the sysplex will be up so the load on the CF > is not going to be high. > > I just can't persuade the outsourcer we don't need a dedicated engine for > the CF. > > On Mon, Mar 6, 2023, 9:49 AM Seymour J Metz wrote: > > > The issue is performance. Depending on what you are doing, the degraded > > performance may be acceptable. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > > of Laurence Chiu [lch...@gmail.com] > > Sent: Sunday, March 5, 2023 2:05 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Running a Coupling Facility using a CP for a test Parallel > > Sysplex 0 anyh gotcha's? > > > > The debate I am having with the outsourcer is whether or not it's feasible > > or even practical to run a test CF on a general purpose engine. They say it > > requires a dedicated engine and I think that is nonsense! > > > > If I can get that over the line (and that is the challenge) then I can > > suggest what you recommended below. And since I don't need one CF, I might > > need even fewer resources. > > > > > > On Sun, Mar 5, 2023 at 5:39 PM Mike Schwab > > wrote: > > > > > To avoid impacting other systems, I would drop your LPAR weights by a > > > total of 6%, trim your LPAR memory to reuse for the ICFs, then create > > > your two ICF partitions with 3% of 1 CPU and the reclaimed memory.. > > > > > > On Sat, Mar 4, 2023 at 2:55 PM Laurence Chiu wrote: > > > > > > > > Thanks for the input. > > > > > > > > > > > > On Sun, Mar 5, 2023 at 7:41 AM Mike Schwab > > > wrote: > > > > > > > > > > > > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.researchgate.net%2Fpublication%2F342570694_Coupling_Facility_Configuration_Options_-_Updated_2020=05%7C01%7Csmetz3%40gmu.edu%7C436800a18ba54430093908db1daca96d%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638136399655620282%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=HYoo%2FosMEZw5JHKVlB0T%2F2llYz5vokvdUSyxKpIB3Do%3D=0 > > > > > > > > > > > > > I am familiar with that document and even provided a copy to our > > > outsourcer > > > > to read but clearly they hadn't > > > > > > > > This is a direct link to IBM for that document. > > > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdownloads%2Fcas%2FJZB2E38Q=05%7C01%7Csmetz3%40gmu.edu%7C436800a18ba54430093908db1daca96d%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638136399655776514%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=tnP0qr0DTsTupn4v2ayadx5%2FmP%2BKlg8RXncytv1PUiA%3D=0 > > > > > > > > > > > > > > > > > CF is not counted on SCRT, shown on RMF reports. > > > > > Won't cost you on z/OS, may on some vendors. > > > > > > > > > > > > > I don't care so much as this CF is only System B and for development so > > > > using a general purpose engine is not an issue for us. The MSU charges > > > are > > > > going to be low and we are prepared to pay those if it gets us our > > > parallel > > > > sysplex > > > > > > > > > > > > > > > > > Thin CFs go to enabled wait when work is completed, restart when > > > > > interrupt says there is work. > > > > > > > > > > Estimate is 3% light sharing to 13% heaving sharing (of z/OS > > workload). > > > > > > > > > > Thin CF would use internal links so no I/O overhead to another CPU. > > > > > > > > > > For the testing CF on the same system as the test Sysplex that is > > fine. > > > > But they say there are no spare links from System B to System A if I > > > wanted > > > > to run a test Sysplex on System B and access a CF on System A. > > > > > > > > This is their response I had to manage > > > > > > > > > > > > To gi
Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
That's the debate I'm having. The CF is only to support VSAM RLS and most of the time only one member of the sysplex will be up so the load on the CF is not going to be high. I just can't persuade the outsourcer we don't need a dedicated engine for the CF. On Mon, Mar 6, 2023, 9:49 AM Seymour J Metz wrote: > The issue is performance. Depending on what you are doing, the degraded > performance may be acceptable. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Laurence Chiu [lch...@gmail.com] > Sent: Sunday, March 5, 2023 2:05 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Running a Coupling Facility using a CP for a test Parallel > Sysplex 0 anyh gotcha's? > > The debate I am having with the outsourcer is whether or not it's feasible > or even practical to run a test CF on a general purpose engine. They say it > requires a dedicated engine and I think that is nonsense! > > If I can get that over the line (and that is the challenge) then I can > suggest what you recommended below. And since I don't need one CF, I might > need even fewer resources. > > > On Sun, Mar 5, 2023 at 5:39 PM Mike Schwab > wrote: > > > To avoid impacting other systems, I would drop your LPAR weights by a > > total of 6%, trim your LPAR memory to reuse for the ICFs, then create > > your two ICF partitions with 3% of 1 CPU and the reclaimed memory.. > > > > On Sat, Mar 4, 2023 at 2:55 PM Laurence Chiu wrote: > > > > > > Thanks for the input. > > > > > > > > > On Sun, Mar 5, 2023 at 7:41 AM Mike Schwab > > wrote: > > > > > > > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.researchgate.net%2Fpublication%2F342570694_Coupling_Facility_Configuration_Options_-_Updated_2020=05%7C01%7Csmetz3%40gmu.edu%7C436800a18ba54430093908db1daca96d%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638136399655620282%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=HYoo%2FosMEZw5JHKVlB0T%2F2llYz5vokvdUSyxKpIB3Do%3D=0 > > > > > > > > > > I am familiar with that document and even provided a copy to our > > outsourcer > > > to read but clearly they hadn't > > > > > > This is a direct link to IBM for that document. > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdownloads%2Fcas%2FJZB2E38Q=05%7C01%7Csmetz3%40gmu.edu%7C436800a18ba54430093908db1daca96d%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638136399655776514%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=tnP0qr0DTsTupn4v2ayadx5%2FmP%2BKlg8RXncytv1PUiA%3D=0 > > > > > > > > > > > > > CF is not counted on SCRT, shown on RMF reports. > > > > Won't cost you on z/OS, may on some vendors. > > > > > > > > > > I don't care so much as this CF is only System B and for development so > > > using a general purpose engine is not an issue for us. The MSU charges > > are > > > going to be low and we are prepared to pay those if it gets us our > > parallel > > > sysplex > > > > > > > > > > > > > Thin CFs go to enabled wait when work is completed, restart when > > > > interrupt says there is work. > > > > > > > > Estimate is 3% light sharing to 13% heaving sharing (of z/OS > workload). > > > > > > > > Thin CF would use internal links so no I/O overhead to another CPU. > > > > > > > > For the testing CF on the same system as the test Sysplex that is > fine. > > > But they say there are no spare links from System B to System A if I > > wanted > > > to run a test Sysplex on System B and access a CF on System A. > > > > > > This is their response I had to manage > > > > > > > > > To give an idea of what I am facing, this is their response to my > > proposals. > > > > > > Using a General Purpose CP (GCP) as a coupling facility on System > B(z13 > > at > > > WithDrawn From Marketing Licensed Internal Code) > > > • There are no spare unallocated GCP on System B i.e no “parked” GCP. > > > • All GCP’s, on System B, are allocated as shared, across all LPARS. > i.e. > > > no dedicated GCP’s. > > > • Sharing GCP’s to use for z/OS and as a coupling facility is strongly > > not > > > recommended F
Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
AFAIK, the only issues for connecting two LPARS with a CF running on a CP of the same CEC are cost and performance. For cross-CEC connections, a CTCA link is enough for XCF, but anything more, e.g., GRS star, requires a CF link. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Laurence Chiu [lch...@gmail.com] Sent: Friday, March 3, 2023 10:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's? The situation. We share a couple of Z13's with another (larger client). Z13 B is where we run our development LPARs and Z13 A is production. For critical business reasons an online application on our production LPAR needs to be highly available and that means in a parallel sysplex. But our outsourcer has told us it cannot be done for the following reasons because there are no spare ICF engines on the host B - all are being used by other CF instances, either to support production Sysplexes or development ones (not ours). Host A does potentially have a spare ICF engine we could use to support a production parallel Sysplex but good practice does recommend you create a test one first of course. I then asked the question, if host A has a spare ICF engine, can't it be used to support a CF to be used by the test Sysplex on B. I was advised this was not possible since there are no spare connections between host A and Host B (Infiniband possibly) so the Sysplex on B could not actually communicate with the CF on A. Our requirement for the Sysplex is primarily to be able to share a VSAM dataset which is hit every time a transaction comes in with a peak of about 99tps. So we would need VSAM RLS to share the dataset records between the two application instances. There is no DB2, CICS or IMS so I think the only structures in the CF are those to support VSAM RLS, maybe some XCF structures and core systems. Knowing that we would only bring up the test sysplex to make sure transactions routed correctly across the two LPARs and most of the time we would have one member of the Sysplex off, I suggested that the test CF could be built using a CP. To this suggestion I received the following (anti) advice - there would be MSU costs (we don't care since we think the MIPS load on the CF would be low). Plus we would ask that the CF be defined with Dynamic Coupling Facility Dispatch and set DYNDISP=THIN. Since that CF is going to be idling most of the time, MSU consumption is not going to be a major cost. - it's strongly recommended not to do this by IBM. Yet when I read this document https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdownloads%2Fcas%2FJZB2E38Q=05%7C01%7Csmetz3%40gmu.edu%7Cdf1956e16dcf4821e3cf08db1c616edf%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638134977044989164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lSiwgmIAvYohgwejbgEGTNu94ELAAPA%2Fq0lFp7g%2FJ2Y%3D=0 the option is discussed in great detail and the only negatives are the incurring of MSU costs and some performance degradation if both a z/OS and CF LPAR are trying to use the same CP at the same time. But this can be managed. - that a CF running on a CP would need a dedicated CP engine and there are no spare engines in host B. That totally flies against the information I have read from IBM docs. Of course for production the CF on host A would be configured to use an ICF engine (or share one) Finally, while I accepted the argument at the time there were no connections between Host A and Host B, further reading suggests that you do not need to dedicate channels for communications but use XCF or by using Infiniband sub channels or sharing the same physical link with more than one Sysplex. Then the issue of running the CF on a CP goes away since I can ask for two CF's to be defined on host A, one for production and one for test and DCFC ensures that that production CF is not impacted by the development one. A lot to digest here but I really want to have some authoritative data in order to refute most of the comments being our outsourcer. Thanks -- 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: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
The issue is performance. Depending on what you are doing, the degraded performance may be acceptable. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Laurence Chiu [lch...@gmail.com] Sent: Sunday, March 5, 2023 2:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's? The debate I am having with the outsourcer is whether or not it's feasible or even practical to run a test CF on a general purpose engine. They say it requires a dedicated engine and I think that is nonsense! If I can get that over the line (and that is the challenge) then I can suggest what you recommended below. And since I don't need one CF, I might need even fewer resources. On Sun, Mar 5, 2023 at 5:39 PM Mike Schwab wrote: > To avoid impacting other systems, I would drop your LPAR weights by a > total of 6%, trim your LPAR memory to reuse for the ICFs, then create > your two ICF partitions with 3% of 1 CPU and the reclaimed memory.. > > On Sat, Mar 4, 2023 at 2:55 PM Laurence Chiu wrote: > > > > Thanks for the input. > > > > > > On Sun, Mar 5, 2023 at 7:41 AM Mike Schwab > wrote: > > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.researchgate.net%2Fpublication%2F342570694_Coupling_Facility_Configuration_Options_-_Updated_2020=05%7C01%7Csmetz3%40gmu.edu%7C436800a18ba54430093908db1daca96d%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638136399655620282%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=HYoo%2FosMEZw5JHKVlB0T%2F2llYz5vokvdUSyxKpIB3Do%3D=0 > > > > > > > I am familiar with that document and even provided a copy to our > outsourcer > > to read but clearly they hadn't > > > > This is a direct link to IBM for that document. > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdownloads%2Fcas%2FJZB2E38Q=05%7C01%7Csmetz3%40gmu.edu%7C436800a18ba54430093908db1daca96d%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638136399655776514%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=tnP0qr0DTsTupn4v2ayadx5%2FmP%2BKlg8RXncytv1PUiA%3D=0 > > > > > > > > > CF is not counted on SCRT, shown on RMF reports. > > > Won't cost you on z/OS, may on some vendors. > > > > > > > I don't care so much as this CF is only System B and for development so > > using a general purpose engine is not an issue for us. The MSU charges > are > > going to be low and we are prepared to pay those if it gets us our > parallel > > sysplex > > > > > > > > > Thin CFs go to enabled wait when work is completed, restart when > > > interrupt says there is work. > > > > > > Estimate is 3% light sharing to 13% heaving sharing (of z/OS workload). > > > > > > Thin CF would use internal links so no I/O overhead to another CPU. > > > > > > For the testing CF on the same system as the test Sysplex that is fine. > > But they say there are no spare links from System B to System A if I > wanted > > to run a test Sysplex on System B and access a CF on System A. > > > > This is their response I had to manage > > > > > > To give an idea of what I am facing, this is their response to my > proposals. > > > > Using a General Purpose CP (GCP) as a coupling facility on System B(z13 > at > > WithDrawn From Marketing Licensed Internal Code) > > • There are no spare unallocated GCP on System B i.e no “parked” GCP. > > • All GCP’s, on System B, are allocated as shared, across all LPARS. i.e. > > no dedicated GCP’s. > > • Sharing GCP’s to use for z/OS and as a coupling facility is strongly > not > > recommended FYI coupling facility engines run CFCC (coupling facility > > control code) rather than z/OS. > > • This possibly I believe is now exhausted. > > > > I think all these points are contestable, specially after reading the IBM > > document from a specialist in this area > > > > I just need to get some authoritative voice onto the case, ideally the > > author of the document but that might not be easy. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > Mike A Schwab, Spring
Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
The debate I am having with the outsourcer is whether or not it's feasible or even practical to run a test CF on a general purpose engine. They say it requires a dedicated engine and I think that is nonsense! If I can get that over the line (and that is the challenge) then I can suggest what you recommended below. And since I don't need one CF, I might need even fewer resources. On Sun, Mar 5, 2023 at 5:39 PM Mike Schwab wrote: > To avoid impacting other systems, I would drop your LPAR weights by a > total of 6%, trim your LPAR memory to reuse for the ICFs, then create > your two ICF partitions with 3% of 1 CPU and the reclaimed memory.. > > On Sat, Mar 4, 2023 at 2:55 PM Laurence Chiu wrote: > > > > Thanks for the input. > > > > > > On Sun, Mar 5, 2023 at 7:41 AM Mike Schwab > wrote: > > > > > > > > > https://www.researchgate.net/publication/342570694_Coupling_Facility_Configuration_Options_-_Updated_2020 > > > > > > > I am familiar with that document and even provided a copy to our > outsourcer > > to read but clearly they hadn't > > > > This is a direct link to IBM for that document. > > > > https://www.ibm.com/downloads/cas/JZB2E38Q > > > > > > > > > CF is not counted on SCRT, shown on RMF reports. > > > Won't cost you on z/OS, may on some vendors. > > > > > > > I don't care so much as this CF is only System B and for development so > > using a general purpose engine is not an issue for us. The MSU charges > are > > going to be low and we are prepared to pay those if it gets us our > parallel > > sysplex > > > > > > > > > Thin CFs go to enabled wait when work is completed, restart when > > > interrupt says there is work. > > > > > > Estimate is 3% light sharing to 13% heaving sharing (of z/OS workload). > > > > > > Thin CF would use internal links so no I/O overhead to another CPU. > > > > > > For the testing CF on the same system as the test Sysplex that is fine. > > But they say there are no spare links from System B to System A if I > wanted > > to run a test Sysplex on System B and access a CF on System A. > > > > This is their response I had to manage > > > > > > To give an idea of what I am facing, this is their response to my > proposals. > > > > Using a General Purpose CP (GCP) as a coupling facility on System B(z13 > at > > WithDrawn From Marketing Licensed Internal Code) > > • There are no spare unallocated GCP on System B i.e no “parked” GCP. > > • All GCP’s, on System B, are allocated as shared, across all LPARS. i.e. > > no dedicated GCP’s. > > • Sharing GCP’s to use for z/OS and as a coupling facility is strongly > not > > recommended FYI coupling facility engines run CFCC (coupling facility > > control code) rather than z/OS. > > • This possibly I believe is now exhausted. > > > > I think all these points are contestable, specially after reading the IBM > > document from a specialist in this area > > > > I just need to get some authoritative voice onto the case, ideally the > > author of the document but that might not be easy. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > -- > 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: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
To avoid impacting other systems, I would drop your LPAR weights by a total of 6%, trim your LPAR memory to reuse for the ICFs, then create your two ICF partitions with 3% of 1 CPU and the reclaimed memory.. On Sat, Mar 4, 2023 at 2:55 PM Laurence Chiu wrote: > > Thanks for the input. > > > On Sun, Mar 5, 2023 at 7:41 AM Mike Schwab wrote: > > > > > https://www.researchgate.net/publication/342570694_Coupling_Facility_Configuration_Options_-_Updated_2020 > > > > I am familiar with that document and even provided a copy to our outsourcer > to read but clearly they hadn't > > This is a direct link to IBM for that document. > > https://www.ibm.com/downloads/cas/JZB2E38Q > > > > > CF is not counted on SCRT, shown on RMF reports. > > Won't cost you on z/OS, may on some vendors. > > > > I don't care so much as this CF is only System B and for development so > using a general purpose engine is not an issue for us. The MSU charges are > going to be low and we are prepared to pay those if it gets us our parallel > sysplex > > > > > Thin CFs go to enabled wait when work is completed, restart when > > interrupt says there is work. > > > > Estimate is 3% light sharing to 13% heaving sharing (of z/OS workload). > > > > Thin CF would use internal links so no I/O overhead to another CPU. > > > > For the testing CF on the same system as the test Sysplex that is fine. > But they say there are no spare links from System B to System A if I wanted > to run a test Sysplex on System B and access a CF on System A. > > This is their response I had to manage > > > To give an idea of what I am facing, this is their response to my proposals. > > Using a General Purpose CP (GCP) as a coupling facility on System B(z13 at > WithDrawn From Marketing Licensed Internal Code) > • There are no spare unallocated GCP on System B i.e no “parked” GCP. > • All GCP’s, on System B, are allocated as shared, across all LPARS. i.e. > no dedicated GCP’s. > • Sharing GCP’s to use for z/OS and as a coupling facility is strongly not > recommended FYI coupling facility engines run CFCC (coupling facility > control code) rather than z/OS. > • This possibly I believe is now exhausted. > > I think all these points are contestable, specially after reading the IBM > document from a specialist in this area > > I just need to get some authoritative voice onto the case, ideally the > author of the document but that might not be easy. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
Thanks for the input. On Sun, Mar 5, 2023 at 7:41 AM Mike Schwab wrote: > > https://www.researchgate.net/publication/342570694_Coupling_Facility_Configuration_Options_-_Updated_2020 > I am familiar with that document and even provided a copy to our outsourcer to read but clearly they hadn't This is a direct link to IBM for that document. https://www.ibm.com/downloads/cas/JZB2E38Q > CF is not counted on SCRT, shown on RMF reports. > Won't cost you on z/OS, may on some vendors. > I don't care so much as this CF is only System B and for development so using a general purpose engine is not an issue for us. The MSU charges are going to be low and we are prepared to pay those if it gets us our parallel sysplex > Thin CFs go to enabled wait when work is completed, restart when > interrupt says there is work. > > Estimate is 3% light sharing to 13% heaving sharing (of z/OS workload). > > Thin CF would use internal links so no I/O overhead to another CPU. > > For the testing CF on the same system as the test Sysplex that is fine. But they say there are no spare links from System B to System A if I wanted to run a test Sysplex on System B and access a CF on System A. This is their response I had to manage To give an idea of what I am facing, this is their response to my proposals. Using a General Purpose CP (GCP) as a coupling facility on System B(z13 at WithDrawn From Marketing Licensed Internal Code) • There are no spare unallocated GCP on System B i.e no “parked” GCP. • All GCP’s, on System B, are allocated as shared, across all LPARS. i.e. no dedicated GCP’s. • Sharing GCP’s to use for z/OS and as a coupling facility is strongly not recommended FYI coupling facility engines run CFCC (coupling facility control code) rather than z/OS. • This possibly I believe is now exhausted. I think all these points are contestable, specially after reading the IBM document from a specialist in this area I just need to get some authoritative voice onto the case, ideally the author of the document but that might not be easy. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
https://www.researchgate.net/publication/342570694_Coupling_Facility_Configuration_Options_-_Updated_2020 CF is not counted on SCRT, shown on RMF reports. Won't cost you on z/OS, may on some vendors. Thin CFs go to enabled wait when work is completed, restart when interrupt says there is work. Estimate is 3% light sharing to 13% heaving sharing (of z/OS workload). Thin CF would use internal links so no I/O overhead to another CPU. On Fri, Mar 3, 2023 at 9:35 PM Laurence Chiu wrote: > > The situation. > > We share a couple of Z13's with another (larger client). Z13 B is where we > run our development LPARs and Z13 A is production. > > For critical business reasons an online application on our production LPAR > needs to be highly available and that means in a parallel sysplex. But our > outsourcer has told us it cannot be done for the following reasons because > there are no spare ICF engines on the host B - all are being used by other > CF instances, either to support production Sysplexes or development ones > (not ours). > > Host A does potentially have a spare ICF engine we could use to support a > production parallel Sysplex but good practice does recommend you create a > test one first of course. > > I then asked the question, if host A has a spare ICF engine, can't it be > used to support a CF to be used by the test Sysplex on B. I was advised > this was not possible since there are no spare connections between host A > and Host B (Infiniband possibly) so the Sysplex on B could not actually > communicate with the CF on A. > > Our requirement for the Sysplex is primarily to be able to share a VSAM > dataset which is hit every time a transaction comes in with a peak of about > 99tps. So we would need VSAM RLS to share the dataset records between the > two application instances. There is no DB2, CICS or IMS so I think the only > structures in the CF are those to support VSAM RLS, maybe some XCF > structures and core systems. > > Knowing that we would only bring up the test sysplex to make sure > transactions routed correctly across the two LPARs and most of the time we > would have one member of the Sysplex off, I suggested that the test CF > could be built using a CP. To this suggestion I received the following > (anti) advice > - there would be MSU costs (we don't care since we think the MIPS load on > the CF would be low). Plus we would ask that the CF be defined with Dynamic > Coupling Facility Dispatch and set DYNDISP=THIN. Since that CF is going to > be idling most of the time, MSU consumption is not going to be a major cost. > - it's strongly recommended not to do this by IBM. Yet when I read this > document > > https://www.ibm.com/downloads/cas/JZB2E38Q > the option is discussed in great detail and the only negatives are the > incurring of MSU costs and some performance degradation if both a z/OS and > CF LPAR are trying to use the same CP at the same time. But this can be > managed. > > - that a CF running on a CP would need a dedicated CP engine and there are > no spare engines in host B. That totally flies against the information I > have read from IBM docs. > > Of course for production the CF on host A would be configured to use an ICF > engine (or share one) > > Finally, while I accepted the argument at the time there were no > connections between Host A and Host B, further reading suggests that you do > not need to dedicate channels for communications but use XCF or by using > Infiniband sub channels or sharing the same physical link with more than > one Sysplex. Then the issue of running the CF on a CP goes away since I can > ask for two CF's to be defined on host A, one for production and one for > test and DCFC ensures that that production CF is not impacted by the > development one. > > A lot to digest here but I really want to have some authoritative data in > order to refute most of the comments being our outsourcer. > > Thanks > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Running a Coupling Facility using a CP for a test Parallel Sysplex 0 anyh gotcha's?
The situation. We share a couple of Z13's with another (larger client). Z13 B is where we run our development LPARs and Z13 A is production. For critical business reasons an online application on our production LPAR needs to be highly available and that means in a parallel sysplex. But our outsourcer has told us it cannot be done for the following reasons because there are no spare ICF engines on the host B - all are being used by other CF instances, either to support production Sysplexes or development ones (not ours). Host A does potentially have a spare ICF engine we could use to support a production parallel Sysplex but good practice does recommend you create a test one first of course. I then asked the question, if host A has a spare ICF engine, can't it be used to support a CF to be used by the test Sysplex on B. I was advised this was not possible since there are no spare connections between host A and Host B (Infiniband possibly) so the Sysplex on B could not actually communicate with the CF on A. Our requirement for the Sysplex is primarily to be able to share a VSAM dataset which is hit every time a transaction comes in with a peak of about 99tps. So we would need VSAM RLS to share the dataset records between the two application instances. There is no DB2, CICS or IMS so I think the only structures in the CF are those to support VSAM RLS, maybe some XCF structures and core systems. Knowing that we would only bring up the test sysplex to make sure transactions routed correctly across the two LPARs and most of the time we would have one member of the Sysplex off, I suggested that the test CF could be built using a CP. To this suggestion I received the following (anti) advice - there would be MSU costs (we don't care since we think the MIPS load on the CF would be low). Plus we would ask that the CF be defined with Dynamic Coupling Facility Dispatch and set DYNDISP=THIN. Since that CF is going to be idling most of the time, MSU consumption is not going to be a major cost. - it's strongly recommended not to do this by IBM. Yet when I read this document https://www.ibm.com/downloads/cas/JZB2E38Q the option is discussed in great detail and the only negatives are the incurring of MSU costs and some performance degradation if both a z/OS and CF LPAR are trying to use the same CP at the same time. But this can be managed. - that a CF running on a CP would need a dedicated CP engine and there are no spare engines in host B. That totally flies against the information I have read from IBM docs. Of course for production the CF on host A would be configured to use an ICF engine (or share one) Finally, while I accepted the argument at the time there were no connections between Host A and Host B, further reading suggests that you do not need to dedicate channels for communications but use XCF or by using Infiniband sub channels or sharing the same physical link with more than one Sysplex. Then the issue of running the CF on a CP goes away since I can ask for two CF's to be defined on host A, one for production and one for test and DCFC ensures that that production CF is not impacted by the development one. A lot to digest here but I really want to have some authoritative data in order to refute most of the comments being our outsourcer. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex environment perform DEFRAG
Run defrag. Files open will not be touched. On Mon, Dec 12, 2022 at 9:44 PM Tommy Tsui wrote: > > Hi all, > > Anyone can share how to perform disk DEFRAG at the parallel sysplex > environment? Anything need to aware ? > Thanks for sharing > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Sysplex environment perform DEFRAG
Hi all, Anyone can share how to perform disk DEFRAG at the parallel sysplex environment? Anything need to aware ? Thanks for sharing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSPLEX / SYSNAME / SMFID stability
I do ... I spend most of my day mentoring new sysprogs for Kyndryl ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSPLEX / SYSNAME / SMFID stability
I'm glad to hear that; pay it forward. I miss him. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gorlinsky [p...@atsmigrations.com] Sent: Friday, September 30, 2022 11:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSPLEX / SYSNAME / SMFID stability BTW you and GP were my best mentors of that time Thanks -- 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: SYSPLEX / SYSNAME / SMFID stability
BTW you and GP were my best mentors of that time Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSPLEX / SYSNAME / SMFID stability
Every time my boss asked me if we were bringing too many FDRSAR tapes, I told him that he will never hear me say that there are too many, only that there are not enough. The ta he pulled were generally actual backup tapes. If our procedures for recovering from logs weren't documented well enough to use them during D/R, then we wanted to know before the balloon went up. Yes, I'm still in Annandale. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gorlinsky [p...@atsmigrations.com] Sent: Friday, September 30, 2022 10:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSPLEX / SYSNAME / SMFID stability You can not believe how many "TAPES" critical to the success of a DR test have been lost or forgotten. The major one, the standalone IPL utility tape. BTW the business that I am in today is DR/BC and Virtual Tape Appliance. My z/Appliance device emulates FICON attached 3480, 3490 and 3590 tapes drives and has an integrate mirroring facility for up to 8 locations. Why eight? One in-house, cloud like dropbox, AWS, Azure, etc., duplicate company owned data center, or hosted services ( more than one if needed ). Check out https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.atsmigrations.com%2Fdata=05%7C01%7Csmetz3%40gmu.edu%7C76d91da3083248e0513b08daa2ee91ea%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638001442777804317%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=yOM0NVRBqjmYA%2FupHPEae4qRnLb1itLetvxmDfAidxI%3Dreserved=0 for more information. Are you still in the DC area? Take care, 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: SYSPLEX / SYSNAME / SMFID stability
You can not believe how many "TAPES" critical to the success of a DR test have been lost or forgotten. The major one, the standalone IPL utility tape. BTW the business that I am in today is DR/BC and Virtual Tape Appliance. My z/Appliance device emulates FICON attached 3480, 3490 and 3590 tapes drives and has an integrate mirroring facility for up to 8 locations. Why eight? One in-house, cloud like dropbox, AWS, Azure, etc., duplicate company owned data center, or hosted services ( more than one if needed ). Check out https://www.atsmigrations.com for more information. Are you still in the DC area? Take care, Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSPLEX / SYSNAME / SMFID stability
That would have been a decision way above my pay grade.. My manager and his government counterpart were there at the time, and my responsibilities were on the technical side. I asked SG to configure a virtual machine with our home CPUID and continued the test. We certainly let the vendor know that it was unacceptable; if the government took legal action I was not informed (I would have celebrated.) BTW, that was less effort than the tapes that our boss decreed lost and the personnel that our boss decreed dead, which I considered not only a fair part of the test but absolutely essential. In a real disaster, all bets are off, and if your recovery plan doesn't cover contingencies then you're SOL. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gorlinsky [p...@atsmigrations.com] Sent: Friday, September 30, 2022 9:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSPLEX / SYSNAME / SMFID stability Hello Seymour, The best thing to do is to turn this over to the lawyers. It is a breach of contract and the vendor needs to be held accountable. I have done two DR tests in the past thirty days and several of the vendors DONT require and immediately Key change. However, one vendor does and the customer has several products from them. Ask the real question... what would have happened in a LIVE situation? This is why the lawyers need to be aware of the potential damage they can do to your business. A DR test is also a test of the VENDORS ability to provide their contractual obligations. -- 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: SYSPLEX / SYSNAME / SMFID stability
Hello Seymour, The best thing to do is to turn this over to the lawyers. It is a breach of contract and the vendor needs to be held accountable. I have done two DR tests in the past thirty days and several of the vendors DONT require and immediately Key change. However, one vendor does and the customer has several products from them. Ask the real question... what would have happened in a LIVE situation? This is why the lawyers need to be aware of the potential damage they can do to your business. A DR test is also a test of the VENDORS ability to provide their contractual obligations. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSPLEX / SYSNAME / SMFID stability
What do you do when the key a software vendor gave you for a D/R test doesn't work and they don't give you a correct key within the contracted window? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Martin Packer [martin_pac...@uk.ibm.com] Sent: Friday, September 30, 2022 4:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSPLEX / SYSNAME / SMFID stability “Customers do the darnedest things…” From: IBM Mainframe Discussion List on behalf of Ed Jaffe Date: Thursday, 29 September 2022 at 22:57 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: SYSPLEX / SYSNAME / SMFID stability On 9/29/2022 5:19 AM, Mark A. Brooks wrote: > Right, I'm not aware of a UUID for a z/OS system. > Every system in a given sysplex must have a unique name. In that sense > SysplexName.SystemName might do the trick. But ... > Sysplex names are not necessarily unique -- test sysplex or DR site could be > using the same name. In our case, the D/R sysplex *and* system names are all the same. The only way we can tell them apart is by CPC Type/Serial. We have a REXX call WHEREAMI that inspects CPC Type/Serial in the PCCA and let's you know where you are. Of course, serial numbers can faked under z/VM, but we don't do that... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.phoenixsoftware.com%2Fdata=05%7C01%7Csmetz3%40gmu.edu%7C74d183aacdb44615760308daa2bd633a%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638001231574073756%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=gYHsfajw%2BfhpEQ9Z6LbPDdmiJtkHEGJmNMU6asGH3y4%3Dreserved=0 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 Unless otherwise stated above: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU -- 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: SYSPLEX / SYSNAME / SMFID stability
FYI, XCF does provide a "sysplex ID" that can be used to uniquely identify a sysplex for the life of the sysplex. That could be used to distinguish between two different sysplexes with the same name. A new sysplex ID is generated each time the sysplex starts fresh. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSPLEX / SYSNAME / SMFID stability
“Customers do the darnedest things…” From: IBM Mainframe Discussion List on behalf of Ed Jaffe Date: Thursday, 29 September 2022 at 22:57 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: SYSPLEX / SYSNAME / SMFID stability On 9/29/2022 5:19 AM, Mark A. Brooks wrote: > Right, I'm not aware of a UUID for a z/OS system. > Every system in a given sysplex must have a unique name. In that sense > SysplexName.SystemName might do the trick. But ... > Sysplex names are not necessarily unique -- test sysplex or DR site could be > using the same name. In our case, the D/R sysplex *and* system names are all the same. The only way we can tell them apart is by CPC Type/Serial. We have a REXX call WHEREAMI that inspects CPC Type/Serial in the PCCA and let's you know where you are. Of course, serial numbers can faked under z/VM, but we don't do that... -- 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 Unless otherwise stated above: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSPLEX / SYSNAME / SMFID stability
On 9/29/2022 5:19 AM, Mark A. Brooks wrote: Right, I'm not aware of a UUID for a z/OS system. Every system in a given sysplex must have a unique name. In that sense SysplexName.SystemName might do the trick. But ... Sysplex names are not necessarily unique -- test sysplex or DR site could be using the same name. In our case, the D/R sysplex *and* system names are all the same. The only way we can tell them apart is by CPC Type/Serial. We have a REXX call WHEREAMI that inspects CPC Type/Serial in the PCCA and let's you know where you are. Of course, serial numbers can faked under z/VM, but we don't do that... -- 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: SYSPLEX / SYSNAME / SMFID stability
> On Sep 29, 2022, at 8:19 AM, Mark A. Brooks wrote: > > Right, I'm not aware of a UUID for a z/OS system. > Every system in a given sysplex must have a unique name. In that sense > SysplexName.SystemName might do the trick. But ... > Sysplex names are not necessarily unique -- test sysplex or DR site could be > using the same name. I wasn’t too worried about DR but that is a good point. I think the best bet is to document the requirement for unique SYSPLEX names and let that be the high level qualifier as it were. I figured for service providers they would have some tenant ID for their customer but that’s just meta-data. Thanks for the input. Matt Hogstrom “It may be cognitive, but, it ain’t intuitive." — Hogstrom -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSPLEX / SYSNAME / SMFID stability
Right, I'm not aware of a UUID for a z/OS system. Every system in a given sysplex must have a unique name. In that sense SysplexName.SystemName might do the trick. But ... Sysplex names are not necessarily unique -- test sysplex or DR site could be using the same name. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSPLEX / SYSNAME / SMFID stability
IMHO duplicate names are undesirable; you can avoid them by implementing appropriate naming conventions. Ideally the names should be constructed from a combination of the IPL volume serial and the LPAR name. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Matt Hogstrom [m...@hogstrom.org] Sent: Wednesday, September 28, 2022 8:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SYSPLEX / SYSNAME / SMFID stability We had an internal debate about the stability of SYSNAME and smfID in a sysplex. The discussion was that smfID is not stable and can be changed and that there can be more than one system in a sysplex with the same sysname / smfid. I haven’t had a chance to try it out but the argument seems to be counterintuitive that anyone would use the same SYSNAME / SMFID in a SYSPLEX. The IBM documents to not specifically say that it is not allowed but I’m curious if anyone has seen such a configuration / can think of a reason why you would do that. The problem I’m trying to get a handle on is to uniquely identify a z/OS instance over time and the SYSPLEX.SYSNAME seemed like a good combination (I still think that they will be stable over time) but I thought I’d pose the question to the brain trust here. Another proposal was to use the hostname / domain name as unique but it seems that you can have multiple instances of those depending on how many TCPIP stacks you are running in a z/OS instance. Thoughts? Matt Hogstrom m...@hogstrom.org “It may be cognitive, but, it ain’t intuitive." — Hogstrom -- 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: SYSPLEX / SYSNAME / SMFID stability
That’s a good question … I hope I used the term z/OS instance and not LPAR in my question. A z/OS instance could be run on different CECs and LPARs at different times. There is no canonical UUID for an instance but I think there is likely an industry best practice that could be relied upon. Matt Hogstrom “It may be cognitive, but, it ain’t intuitive." — Hogstrom > On Sep 28, 2022, at 9:14 AM, Martin Packer wrote: > > If it moves to another machine is it still the same LPAR? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSPLEX / SYSNAME / SMFID stability
If it moves to another machine is it still the same LPAR? From: IBM Mainframe Discussion List on behalf of Matt Hogstrom Date: Wednesday, 28 September 2022 at 13:59 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] SYSPLEX / SYSNAME / SMFID stability We had an internal debate about the stability of SYSNAME and smfID in a sysplex. The discussion was that smfID is not stable and can be changed and that there can be more than one system in a sysplex with the same sysname / smfid. I haven’t had a chance to try it out but the argument seems to be counterintuitive that anyone would use the same SYSNAME / SMFID in a SYSPLEX. The IBM documents to not specifically say that it is not allowed but I’m curious if anyone has seen such a configuration / can think of a reason why you would do that. The problem I’m trying to get a handle on is to uniquely identify a z/OS instance over time and the SYSPLEX.SYSNAME seemed like a good combination (I still think that they will be stable over time) but I thought I’d pose the question to the brain trust here. Another proposal was to use the hostname / domain name as unique but it seems that you can have multiple instances of those depending on how many TCPIP stacks you are running in a z/OS instance. Thoughts? Matt Hogstrom m...@hogstrom.org “It may be cognitive, but, it ain’t intuitive." — Hogstrom -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless otherwise stated above: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SYSPLEX / SYSNAME / SMFID stability
We had an internal debate about the stability of SYSNAME and smfID in a sysplex. The discussion was that smfID is not stable and can be changed and that there can be more than one system in a sysplex with the same sysname / smfid. I haven’t had a chance to try it out but the argument seems to be counterintuitive that anyone would use the same SYSNAME / SMFID in a SYSPLEX. The IBM documents to not specifically say that it is not allowed but I’m curious if anyone has seen such a configuration / can think of a reason why you would do that. The problem I’m trying to get a handle on is to uniquely identify a z/OS instance over time and the SYSPLEX.SYSNAME seemed like a good combination (I still think that they will be stable over time) but I thought I’d pose the question to the brain trust here. Another proposal was to use the hostname / domain name as unique but it seems that you can have multiple instances of those depending on how many TCPIP stacks you are running in a z/OS instance. Thoughts? Matt Hogstrom m...@hogstrom.org “It may be cognitive, but, it ain’t intuitive." — Hogstrom -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF JS command cross-sysplex [EXTERNAL]
KB Much appreciated, I will let the team know. You will be pleased to know i have a long backlog of enhancement ideas. Rob Sent from a field in Hampshire From: IBM Mainframe Discussion List on behalf of kekronbekron <02dee3fcae33-dmarc-requ...@listserv.ua.edu> Sent: Friday, August 12, 2022 3:06:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SDSF JS command cross-sysplex [EXTERNAL] EXTERNAL EMAIL Rob, Just want to say, I think this is a great addition to SDSF. You folks at Rocket are really doing SDSF development right. Seamlessly adding in new functionality, without a freakshow layer. - KB --- Original Message --- On Thursday, August 11th, 2022 at 9:58 PM, Rob Scott wrote: > The SDSF "JS" action does not get sent to remote systems in the sysplex. It > reads data from a special JES2 dataset for the job locally. > > A possible reason for no data being shown is that the job on the remote > system is not in the same MAS. > > Rob Scott > Rocket Software > > Sent from Samsung Mobile on O2 > Get Outlook for Androidhttps://aka.ms/AAb9ysghttps://aka.ms/AAb9ysg> > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of > Feller, Paul 02fc94e14c43-dmarc-requ...@listserv.ua.edu > > Sent: Thursday, August 11, 2022 4:12:37 PM > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: SDSF JS command cross-sysplex [EXTERNAL] > > EXTERNAL EMAIL > > > > > > Keith, I'm assuming you are talking about looking at job on a different lpar > in the same sysplex, also part of the same JES MAS. > > This is a display of a job running on a different lpars then the one I was > logged on to. This is a z/OS 2.4 environment. > > SDSF JOB STEP DISPLAY - JOB DTSTM01D (JOB24586) SMF LINE 1-19 (19) > COMMAND INPUT ===> SCROLL ===> CSR > > PREFIX=* DEST=(ALL) OWNER=* SYSNAME= > NP STEPNAME ProcStep Pgm-Name Step-CC AbendRsn StepNum Elapsed CPU-Time > SRB-Time > STEP000 TMSCOPY TMSCOPY CC 1 0:00:17.79 0:00:02.73 0:00:00.46 > STEP005 STEP001 TMSDATA CC 2 0:00:12.71 0:00:00.71 0:00:00.23 > STEP005 STEP002 IDCAMS CC 3 0:00:02.08 0:00:00.41 0:00:00.01 > STEP003 SAS SAS CC 4 0:01:14.04 0:00:29.98 0:00:00.58 > STEP005 STEP004 IKJEFT01 CC 5 0:00:00.06 0:00:00.02 0:00:00.00 > STEP005 STEP04A TMSUPDTE CC 6 0:00:01.08 0:00:00.14 0:00:00.01 > STEP005 STEP005 IKJEFT01 CC 7 0:00:00.05 0:00:00.02 0:00:00.00 > STEP005 STEP05A TMSUDSNB CC 8 0:00:01.22 0:00:00.17 0:00:00.02 > STEP005 STEP006 IKJEFT01 CC 0001 9 0:00:00.05 0:00:00.02 0:00:00.00 > STEP005 STEP06A TMSUPDTE FLUSH 10 > STEP005 STEP007 IKJEFT01 CC 0001 11 0:00:00.05 0:00:00.02 0:00:00.00 > STEP005 STEP07A TMSUDSNB FLUSH 12 > STEP010 TMSEXPDT TMSEXPDT CC 13 0:12:12.33 0:02:45.00 0:00:09.36 > STEP010 EARL EARL CC 14 0:00:00.55 0:00:00.04 0:00:00.00 > STEP020 TMSCTLG TMSCTLG CC 15 0:20:46.39 0:01:27.02 0:00:03.23 > STEP020 EARL EARL CC 16 0:00:00.93 0:00:00.34 0:00:00.01 > STEP030 TMSCYCLE TMSCYCLE CC 17 0:00:06.49 0:00:00.49 0:00:00.07 > STEP030 EARL EARL CC 18 0:00:00.58 0:00:00.04 0:00:00.00 > STEP040 TMSCLEAN TMSCLEAN ACTIVE 19 > > > F SDSF,D JES > ISF304I Modify DISPLAY command accepted. > ISF351I SDSF JES Subsystems > Sysname JES Version Status > CM01 JES2 z/OS 2.4 ACTIVE > PR05 JES2 z/OS 2.4 ACTIVE > CM02 JES2 z/OS 2.4 ACTIVE > PR03 JES2 z/OS 2.4 ACTIVE > PR02 JES2 z/OS 2.4 ACTIVE > PR01 JES2 z/OS 2.4 ACTIVE > > > Paul Feller > GTS Mainframe Technical Support > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Keith Gooding > > Sent: Thursday, August 11, 2022 9:34 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: SDSF JS command cross-sysplex [EXTERNAL] > > I found that the SDSF ‘JS’ (job steps) command issued from the SDSF panels or > via the REXX API produces no output if the target job is running on a > different system in the sysplex. This is with z/os 2.5. On a 2.3 system the > same happens except that the heading says ‘no job steps found’ (or similar > message). > > Is anyone able to use JS cross-system or is this working as designed?. I am > able to use others commands such as JT (Job Tasks) so I know that the SDSF > address spaces are talking to each other. > > Keith Gooding > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > Please no
Re: SDSF JS command cross-sysplex [EXTERNAL]
Rob, Just want to say, I think this is a great addition to SDSF. You folks at Rocket are really doing SDSF development right. Seamlessly adding in new functionality, without a freakshow layer. - KB --- Original Message --- On Thursday, August 11th, 2022 at 9:58 PM, Rob Scott wrote: > The SDSF "JS" action does not get sent to remote systems in the sysplex. It > reads data from a special JES2 dataset for the job locally. > > A possible reason for no data being shown is that the job on the remote > system is not in the same MAS. > > Rob Scott > Rocket Software > > Sent from Samsung Mobile on O2 > Get Outlook for Androidhttps://aka.ms/AAb9ysg > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of > Feller, Paul 02fc94e14c43-dmarc-requ...@listserv.ua.edu > > Sent: Thursday, August 11, 2022 4:12:37 PM > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: SDSF JS command cross-sysplex [EXTERNAL] > > EXTERNAL EMAIL > > > > > > Keith, I'm assuming you are talking about looking at job on a different lpar > in the same sysplex, also part of the same JES MAS. > > This is a display of a job running on a different lpars then the one I was > logged on to. This is a z/OS 2.4 environment. > > SDSF JOB STEP DISPLAY - JOB DTSTM01D (JOB24586) SMF LINE 1-19 (19) > COMMAND INPUT ===> SCROLL ===> CSR > > PREFIX=* DEST=(ALL) OWNER=* SYSNAME= > NP STEPNAME ProcStep Pgm-Name Step-CC AbendRsn StepNum Elapsed CPU-Time > SRB-Time > STEP000 TMSCOPY TMSCOPY CC 1 0:00:17.79 0:00:02.73 0:00:00.46 > STEP005 STEP001 TMSDATA CC 2 0:00:12.71 0:00:00.71 0:00:00.23 > STEP005 STEP002 IDCAMS CC 3 0:00:02.08 0:00:00.41 0:00:00.01 > STEP003 SAS SAS CC 4 0:01:14.04 0:00:29.98 0:00:00.58 > STEP005 STEP004 IKJEFT01 CC 5 0:00:00.06 0:00:00.02 0:00:00.00 > STEP005 STEP04A TMSUPDTE CC 6 0:00:01.08 0:00:00.14 0:00:00.01 > STEP005 STEP005 IKJEFT01 CC 7 0:00:00.05 0:00:00.02 0:00:00.00 > STEP005 STEP05A TMSUDSNB CC 8 0:00:01.22 0:00:00.17 0:00:00.02 > STEP005 STEP006 IKJEFT01 CC 0001 9 0:00:00.05 0:00:00.02 0:00:00.00 > STEP005 STEP06A TMSUPDTE FLUSH 10 > STEP005 STEP007 IKJEFT01 CC 0001 11 0:00:00.05 0:00:00.02 0:00:00.00 > STEP005 STEP07A TMSUDSNB FLUSH 12 > STEP010 TMSEXPDT TMSEXPDT CC 13 0:12:12.33 0:02:45.00 0:00:09.36 > STEP010 EARL EARL CC 14 0:00:00.55 0:00:00.04 0:00:00.00 > STEP020 TMSCTLG TMSCTLG CC 15 0:20:46.39 0:01:27.02 0:00:03.23 > STEP020 EARL EARL CC 16 0:00:00.93 0:00:00.34 0:00:00.01 > STEP030 TMSCYCLE TMSCYCLE CC 17 0:00:06.49 0:00:00.49 0:00:00.07 > STEP030 EARL EARL CC 18 0:00:00.58 0:00:00.04 0:00:00.00 > STEP040 TMSCLEAN TMSCLEAN ACTIVE 19 > > > F SDSF,D JES > ISF304I Modify DISPLAY command accepted. > ISF351I SDSF JES Subsystems > Sysname JES Version Status > CM01 JES2 z/OS 2.4 ACTIVE > PR05 JES2 z/OS 2.4 ACTIVE > CM02 JES2 z/OS 2.4 ACTIVE > PR03 JES2 z/OS 2.4 ACTIVE > PR02 JES2 z/OS 2.4 ACTIVE > PR01 JES2 z/OS 2.4 ACTIVE > > > Paul Feller > GTS Mainframe Technical Support > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Keith Gooding > > Sent: Thursday, August 11, 2022 9:34 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: SDSF JS command cross-sysplex [EXTERNAL] > > I found that the SDSF ‘JS’ (job steps) command issued from the SDSF panels or > via the REXX API produces no output if the target job is running on a > different system in the sysplex. This is with z/os 2.5. On a 2.3 system the > same happens except that the heading says ‘no job steps found’ (or similar > message). > > Is anyone able to use JS cross-system or is this working as designed?. I am > able to use others commands such as JT (Job Tasks) so I know that the SDSF > address spaces are talking to each other. > > Keith Gooding > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > Please note: This message originated outside your organization. Please use > caution when opening links or attachments. > > -- > 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
Re: SDSF JS command cross-sysplex
Mark. Sorry for the confusing terminology. I meant cross-system within the same sysplex. As I have already posted, the problem seems to be the lack of a journal dataset for STCs - it is working OK for journaled job classes. A conversion to SDSF RACF security was involved in the migration but I am fairly sure that security is not related to the problem. Keith > On 11 Aug 2022, at 19:37, Mark Zelden wrote: > > On Thu, 11 Aug 2022 13:32:46 -0500, Mark Zelden wrote: > >>> On Thu, 11 Aug 2022 15:34:20 +0100, Keith Gooding wrote: >>> >>> I found that the SDSF ‘JS’ (job steps) command issued from the SDSF panels >>> or via the REXX API produces no output if the target job is running on a >>> different system in the sysplex. This is with z/os 2.5. On a 2.3 system the >>> same happens except that the heading says ‘no job steps found’ (or similar >>> message). >>> >>> Is anyone able to use JS cross-system or is this working as designed?. I >>> am able to use others commands such as JT (Job Tasks) so I know that the >>> SDSF address spaces are talking to each other. >>> >>> Keith Gooding >> >> Unfortunately I am getting a really late start on 2.5 and can't test this >> yet. Not only that, this >> migration will be a pain because I have 9 sysplexes using ISFPARMs still. >> Which brings me to >> my point... Was a migration from ISFPARMs involved with upgrading to 2.5 >> and could >> this just be a security related problem? I assume both LPARs are in the >> same JESplex. >> Works fine under z/OS 2.4. >> >> >> Best Regards, >> >> Mark >> -- >> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS >> ITIL v3 Foundation Certified >> mailto:m...@mzelden.com >> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html >> > > I just noticed (and caught up with messages) - your subject says > "cross-sysplex". But > your descriptions says "different system in the sysplex". Which is it? I > don't know how > this could ever work cross-sysplex which implies JES2 is not shared. As I > wrote, it > works fine under z/OS 2.4. > > Best Regards, > > Mark > -- > Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS > ITIL v3 Foundation Certified > mailto:m...@mzelden.com > Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html > > -- > 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: SDSF JS command cross-sysplex
On Thu, 11 Aug 2022 13:32:46 -0500, Mark Zelden wrote: >On Thu, 11 Aug 2022 15:34:20 +0100, Keith Gooding wrote: > >>I found that the SDSF ‘JS’ (job steps) command issued from the SDSF panels or >>via the REXX API produces no output if the target job is running on a >>different system in the sysplex. This is with z/os 2.5. On a 2.3 system the >>same happens except that the heading says ‘no job steps found’ (or similar >>message). >> >>Is anyone able to use JS cross-system or is this working as designed?. I am >>able to use others commands such as JT (Job Tasks) so I know that the SDSF >>address spaces are talking to each other. >> >>Keith Gooding > >Unfortunately I am getting a really late start on 2.5 and can't test this yet. > Not only that, this >migration will be a pain because I have 9 sysplexes using ISFPARMs still. >Which brings me to >my point... Was a migration from ISFPARMs involved with upgrading to 2.5 and >could >this just be a security related problem? I assume both LPARs are in the >same JESplex. >Works fine under z/OS 2.4. > > >Best Regards, > >Mark >-- >Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS >ITIL v3 Foundation Certified >mailto:m...@mzelden.com >Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html > I just noticed (and caught up with messages) - your subject says "cross-sysplex". But your descriptions says "different system in the sysplex". Which is it? I don't know how this could ever work cross-sysplex which implies JES2 is not shared. As I wrote, it works fine under z/OS 2.4. Best Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF JS command cross-sysplex [EXTERNAL]
Got it. The ‘special dataset’ is presumably $JOURNAL. I found that I had only tested with STCs. It works ok for JOBs where the jobclass has JOURNAL=Yes. It does not seem possible to set JOURNSL=YES for STCs. Back to the drawing board. Keith > On 11 Aug 2022, at 19:06, Keith Gooding wrote: > > Thank you Rob and Paul. At least I know that it should work. In fact I think > it *did* once work in the same sysplex at z/os 2.4 but I cannot be 100% sure. > > The systems are in the same MAS (2 systems sharing a JES2 spool and > checkpoint). Are there any instructions in the SDSF configuration that I may > have missed ? . Should I open a case with IBM ? > > Keith > >> On 11 Aug 2022, at 17:28, Rob Scott wrote: >> >> The SDSF "JS" action does not get sent to remote systems in the sysplex. It >> reads data from a special JES2 dataset for the job locally. >> >> A possible reason for no data being shown is that the job on the remote >> system is not in the same MAS. >> >> Rob Scott >> Rocket Software >> >> Sent from Samsung Mobile on O2 >> Get Outlook for Android<https://aka.ms/AAb9ysg> >> >> From: IBM Mainframe Discussion List on behalf of >> Feller, Paul <02fc94e14c43-dmarc-requ...@listserv.ua.edu> >> Sent: Thursday, August 11, 2022 4:12:37 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: SDSF JS command cross-sysplex [EXTERNAL] >> >> EXTERNAL EMAIL >> >> >> >> >> >> Keith, I'm assuming you are talking about looking at job on a different lpar >> in the same sysplex, also part of the same JES MAS. >> >> This is a display of a job running on a different lpars then the one I was >> logged on to. This is a z/OS 2.4 environment. >> >> SDSF JOB STEP DISPLAY - JOB DTSTM01D (JOB24586) SMFLINE 1-19 (19) >> COMMAND INPUT ===>SCROLL ===> CSR >> PREFIX=* DEST=(ALL) OWNER=* SYSNAME= >> NP STEPNAME ProcStep Pgm-Name Step-CCAbendRsn StepNum Elapsed >> CPU-TimeSRB-Time >>STEP000 TMSCOPY TMSCOPY CC 1 0:00:17.79 >> 0:00:02.73 0:00:00.46 >>STEP005 STEP001 TMSDATA CC 2 0:00:12.71 >> 0:00:00.71 0:00:00.23 >>STEP005 STEP002 IDCAMS CC 3 0:00:02.08 >> 0:00:00.41 0:00:00.01 >>STEP003 SAS SAS CC 4 0:01:14.04 >> 0:00:29.98 0:00:00.58 >>STEP005 STEP004 IKJEFT01 CC 5 0:00:00.06 >> 0:00:00.02 0:00:00.00 >>STEP005 STEP04A TMSUPDTE CC 6 0:00:01.08 >> 0:00:00.14 0:00:00.01 >>STEP005 STEP005 IKJEFT01 CC 7 0:00:00.05 >> 0:00:00.02 0:00:00.00 >>STEP005 STEP05A TMSUDSNB CC 8 0:00:01.22 >> 0:00:00.17 0:00:00.02 >>STEP005 STEP006 IKJEFT01 CC 0001 9 0:00:00.05 >> 0:00:00.02 0:00:00.00 >>STEP005 STEP06A TMSUPDTE FLUSH10 >>STEP005 STEP007 IKJEFT01 CC 0001 11 0:00:00.05 >> 0:00:00.02 0:00:00.00 >>STEP005 STEP07A TMSUDSNB FLUSH12 >>STEP010 TMSEXPDT TMSEXPDT CC 13 0:12:12.33 >> 0:02:45.00 0:00:09.36 >>STEP010 EARL EARL CC 14 0:00:00.55 >> 0:00:00.04 0:00:00.00 >>STEP020 TMSCTLG TMSCTLG CC 15 0:20:46.39 >> 0:01:27.02 0:00:03.23 >>STEP020 EARL EARL CC 16 0:00:00.93 >> 0:00:00.34 0:00:00.01 >>STEP030 TMSCYCLE TMSCYCLE CC 17 0:00:06.49 >> 0:00:00.49 0:00:00.07 >>STEP030 EARL EARL CC 18 0:00:00.58 >> 0:00:00.04 0:00:00.00 >>STEP040 TMSCLEAN TMSCLEAN ACTIVE 19 >> >> >> F SDSF,D JES >> ISF304I Modify DISPLAY command accepted. >> ISF351I SDSF JES Subsystems >> Sysname JES Version Status >> CM01 JES2 z/OS 2.4 ACTIVE >> PR05 JES2 z/OS 2.4 ACTIVE >> CM02 JES2 z/OS 2.4 ACTIVE >> PR03 JES2 z/OS 2.4 ACTIVE >> PR02 JES2 z/OS 2.4 ACTIVE >> PR01 JES2 z/OS 2.4 ACTIVE >> >> >> Paul Feller >> GTS Mainframe Technical Support >> >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of >> Keith Gooding >> Sent: Thursday, August 11, 2022 9:34 AM
Re: SDSF JS command cross-sysplex
On Thu, 11 Aug 2022 15:34:20 +0100, Keith Gooding wrote: >I found that the SDSF ‘JS’ (job steps) command issued from the SDSF panels or >via the REXX API produces no output if the target job is running on a >different system in the sysplex. This is with z/os 2.5. On a 2.3 system the >same happens except that the heading says ‘no job steps found’ (or similar >message). > >Is anyone able to use JS cross-system or is this working as designed?. I am >able to use others commands such as JT (Job Tasks) so I know that the SDSF >address spaces are talking to each other. > >Keith Gooding Unfortunately I am getting a really late start on 2.5 and can't test this yet. Not only that, this migration will be a pain because I have 9 sysplexes using ISFPARMs still. Which brings me to my point... Was a migration from ISFPARMs involved with upgrading to 2.5 and could this just be a security related problem? I assume both LPARs are in the same JESplex. Works fine under z/OS 2.4. Best Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF JS command cross-sysplex [EXTERNAL]
Thank you Rob and Paul. At least I know that it should work. In fact I think it *did* once work in the same sysplex at z/os 2.4 but I cannot be 100% sure. The systems are in the same MAS (2 systems sharing a JES2 spool and checkpoint). Are there any instructions in the SDSF configuration that I may have missed ? . Should I open a case with IBM ? Keith > On 11 Aug 2022, at 17:28, Rob Scott wrote: > > The SDSF "JS" action does not get sent to remote systems in the sysplex. It > reads data from a special JES2 dataset for the job locally. > > A possible reason for no data being shown is that the job on the remote > system is not in the same MAS. > > Rob Scott > Rocket Software > > Sent from Samsung Mobile on O2 > Get Outlook for Android<https://aka.ms/AAb9ysg> > > From: IBM Mainframe Discussion List on behalf of > Feller, Paul <02fc94e14c43-dmarc-requ...@listserv.ua.edu> > Sent: Thursday, August 11, 2022 4:12:37 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SDSF JS command cross-sysplex [EXTERNAL] > > EXTERNAL EMAIL > > > > > > Keith, I'm assuming you are talking about looking at job on a different lpar > in the same sysplex, also part of the same JES MAS. > > This is a display of a job running on a different lpars then the one I was > logged on to. This is a z/OS 2.4 environment. > > SDSF JOB STEP DISPLAY - JOB DTSTM01D (JOB24586) SMFLINE 1-19 (19) > COMMAND INPUT ===>SCROLL ===> CSR > PREFIX=* DEST=(ALL) OWNER=* SYSNAME= > NP STEPNAME ProcStep Pgm-Name Step-CCAbendRsn StepNum Elapsed > CPU-TimeSRB-Time > STEP000 TMSCOPY TMSCOPY CC 1 0:00:17.79 > 0:00:02.73 0:00:00.46 > STEP005 STEP001 TMSDATA CC 2 0:00:12.71 > 0:00:00.71 0:00:00.23 > STEP005 STEP002 IDCAMS CC 3 0:00:02.08 > 0:00:00.41 0:00:00.01 > STEP003 SAS SAS CC 4 0:01:14.04 > 0:00:29.98 0:00:00.58 > STEP005 STEP004 IKJEFT01 CC 5 0:00:00.06 > 0:00:00.02 0:00:00.00 > STEP005 STEP04A TMSUPDTE CC 6 0:00:01.08 > 0:00:00.14 0:00:00.01 > STEP005 STEP005 IKJEFT01 CC 7 0:00:00.05 > 0:00:00.02 0:00:00.00 > STEP005 STEP05A TMSUDSNB CC 8 0:00:01.22 > 0:00:00.17 0:00:00.02 > STEP005 STEP006 IKJEFT01 CC 0001 9 0:00:00.05 > 0:00:00.02 0:00:00.00 > STEP005 STEP06A TMSUPDTE FLUSH10 > STEP005 STEP007 IKJEFT01 CC 0001 11 0:00:00.05 > 0:00:00.02 0:00:00.00 > STEP005 STEP07A TMSUDSNB FLUSH12 > STEP010 TMSEXPDT TMSEXPDT CC 13 0:12:12.33 > 0:02:45.00 0:00:09.36 > STEP010 EARL EARL CC 14 0:00:00.55 > 0:00:00.04 0:00:00.00 > STEP020 TMSCTLG TMSCTLG CC 15 0:20:46.39 > 0:01:27.02 0:00:03.23 > STEP020 EARL EARL CC 16 0:00:00.93 > 0:00:00.34 0:00:00.01 > STEP030 TMSCYCLE TMSCYCLE CC 17 0:00:06.49 > 0:00:00.49 0:00:00.07 > STEP030 EARL EARL CC 18 0:00:00.58 > 0:00:00.04 0:00:00.00 > STEP040 TMSCLEAN TMSCLEAN ACTIVE 19 > > > F SDSF,D JES > ISF304I Modify DISPLAY command accepted. > ISF351I SDSF JES Subsystems > Sysname JES Version Status > CM01 JES2 z/OS 2.4 ACTIVE > PR05 JES2 z/OS 2.4 ACTIVE > CM02 JES2 z/OS 2.4 ACTIVE > PR03 JES2 z/OS 2.4 ACTIVE > PR02 JES2 z/OS 2.4 ACTIVE > PR01 JES2 z/OS 2.4 ACTIVE > > > Paul Feller > GTS Mainframe Technical Support > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Keith Gooding > Sent: Thursday, August 11, 2022 9:34 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: SDSF JS command cross-sysplex [EXTERNAL] > > I found that the SDSF ‘JS’ (job steps) command issued from the SDSF panels or > via the REXX API produces no output if the target job is running on a > different system in the sysplex. This is with z/os 2.5. On a 2.3 system the > same happens except that the heading says ‘no job steps found’ (or similar > message). > > Is anyone able to use JS cross-system or is this working as designed?. I am > able to use others commands such as JT (Job Tasks) so I know that the SDSF > address spaces are talking to each other. > > Keith Gooding > ---
Re: SDSF JS command cross-sysplex [EXTERNAL]
The SDSF "JS" action does not get sent to remote systems in the sysplex. It reads data from a special JES2 dataset for the job locally. A possible reason for no data being shown is that the job on the remote system is not in the same MAS. Rob Scott Rocket Software Sent from Samsung Mobile on O2 Get Outlook for Android<https://aka.ms/AAb9ysg> From: IBM Mainframe Discussion List on behalf of Feller, Paul <02fc94e14c43-dmarc-requ...@listserv.ua.edu> Sent: Thursday, August 11, 2022 4:12:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SDSF JS command cross-sysplex [EXTERNAL] EXTERNAL EMAIL Keith, I'm assuming you are talking about looking at job on a different lpar in the same sysplex, also part of the same JES MAS. This is a display of a job running on a different lpars then the one I was logged on to. This is a z/OS 2.4 environment. SDSF JOB STEP DISPLAY - JOB DTSTM01D (JOB24586) SMFLINE 1-19 (19) COMMAND INPUT ===>SCROLL ===> CSR PREFIX=* DEST=(ALL) OWNER=* SYSNAME= NP STEPNAME ProcStep Pgm-Name Step-CCAbendRsn StepNum Elapsed CPU-TimeSRB-Time STEP000 TMSCOPY TMSCOPY CC 1 0:00:17.79 0:00:02.73 0:00:00.46 STEP005 STEP001 TMSDATA CC 2 0:00:12.71 0:00:00.71 0:00:00.23 STEP005 STEP002 IDCAMS CC 3 0:00:02.08 0:00:00.41 0:00:00.01 STEP003 SAS SAS CC 4 0:01:14.04 0:00:29.98 0:00:00.58 STEP005 STEP004 IKJEFT01 CC 5 0:00:00.06 0:00:00.02 0:00:00.00 STEP005 STEP04A TMSUPDTE CC 6 0:00:01.08 0:00:00.14 0:00:00.01 STEP005 STEP005 IKJEFT01 CC 7 0:00:00.05 0:00:00.02 0:00:00.00 STEP005 STEP05A TMSUDSNB CC 8 0:00:01.22 0:00:00.17 0:00:00.02 STEP005 STEP006 IKJEFT01 CC 0001 9 0:00:00.05 0:00:00.02 0:00:00.00 STEP005 STEP06A TMSUPDTE FLUSH10 STEP005 STEP007 IKJEFT01 CC 0001 11 0:00:00.05 0:00:00.02 0:00:00.00 STEP005 STEP07A TMSUDSNB FLUSH12 STEP010 TMSEXPDT TMSEXPDT CC 13 0:12:12.33 0:02:45.00 0:00:09.36 STEP010 EARL EARL CC 14 0:00:00.55 0:00:00.04 0:00:00.00 STEP020 TMSCTLG TMSCTLG CC 15 0:20:46.39 0:01:27.02 0:00:03.23 STEP020 EARL EARL CC 16 0:00:00.93 0:00:00.34 0:00:00.01 STEP030 TMSCYCLE TMSCYCLE CC 17 0:00:06.49 0:00:00.49 0:00:00.07 STEP030 EARL EARL CC 18 0:00:00.58 0:00:00.04 0:00:00.00 STEP040 TMSCLEAN TMSCLEAN ACTIVE 19 F SDSF,D JES ISF304I Modify DISPLAY command accepted. ISF351I SDSF JES Subsystems Sysname JES Version Status CM01 JES2 z/OS 2.4 ACTIVE PR05 JES2 z/OS 2.4 ACTIVE CM02 JES2 z/OS 2.4 ACTIVE PR03 JES2 z/OS 2.4 ACTIVE PR02 JES2 z/OS 2.4 ACTIVE PR01 JES2 z/OS 2.4 ACTIVE Paul Feller GTS Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Keith Gooding Sent: Thursday, August 11, 2022 9:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SDSF JS command cross-sysplex [EXTERNAL] I found that the SDSF ‘JS’ (job steps) command issued from the SDSF panels or via the REXX API produces no output if the target job is running on a different system in the sysplex. This is with z/os 2.5. On a 2.3 system the same happens except that the heading says ‘no job steps found’ (or similar message). Is anyone able to use JS cross-system or is this working as designed?. I am able to use others commands such as JT (Job Tasks) so I know that the SDSF address spaces are talking to each other. Keith Gooding -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Please note: This message originated outside your organization. Please use caution when opening links or attachments. -- 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.rocketso
Re: SDSF JS command cross-sysplex [EXTERNAL]
Keith, I'm assuming you are talking about looking at job on a different lpar in the same sysplex, also part of the same JES MAS. This is a display of a job running on a different lpars then the one I was logged on to. This is a z/OS 2.4 environment. SDSF JOB STEP DISPLAY - JOB DTSTM01D (JOB24586) SMFLINE 1-19 (19) COMMAND INPUT ===>SCROLL ===> CSR PREFIX=* DEST=(ALL) OWNER=* SYSNAME= NP STEPNAME ProcStep Pgm-Name Step-CCAbendRsn StepNum Elapsed CPU-TimeSRB-Time STEP000 TMSCOPY TMSCOPY CC 1 0:00:17.79 0:00:02.73 0:00:00.46 STEP005 STEP001 TMSDATA CC 2 0:00:12.71 0:00:00.71 0:00:00.23 STEP005 STEP002 IDCAMS CC 3 0:00:02.08 0:00:00.41 0:00:00.01 STEP003 SAS SAS CC 4 0:01:14.04 0:00:29.98 0:00:00.58 STEP005 STEP004 IKJEFT01 CC 5 0:00:00.06 0:00:00.02 0:00:00.00 STEP005 STEP04A TMSUPDTE CC 6 0:00:01.08 0:00:00.14 0:00:00.01 STEP005 STEP005 IKJEFT01 CC 7 0:00:00.05 0:00:00.02 0:00:00.00 STEP005 STEP05A TMSUDSNB CC 8 0:00:01.22 0:00:00.17 0:00:00.02 STEP005 STEP006 IKJEFT01 CC 0001 9 0:00:00.05 0:00:00.02 0:00:00.00 STEP005 STEP06A TMSUPDTE FLUSH10 STEP005 STEP007 IKJEFT01 CC 0001 11 0:00:00.05 0:00:00.02 0:00:00.00 STEP005 STEP07A TMSUDSNB FLUSH12 STEP010 TMSEXPDT TMSEXPDT CC 13 0:12:12.33 0:02:45.00 0:00:09.36 STEP010 EARL EARL CC 14 0:00:00.55 0:00:00.04 0:00:00.00 STEP020 TMSCTLG TMSCTLG CC 15 0:20:46.39 0:01:27.02 0:00:03.23 STEP020 EARL EARL CC 16 0:00:00.93 0:00:00.34 0:00:00.01 STEP030 TMSCYCLE TMSCYCLE CC 17 0:00:06.49 0:00:00.49 0:00:00.07 STEP030 EARL EARL CC 18 0:00:00.58 0:00:00.04 0:00:00.00 STEP040 TMSCLEAN TMSCLEAN ACTIVE 19 F SDSF,D JES ISF304I Modify DISPLAY command accepted. ISF351I SDSF JES Subsystems Sysname JES Version Status CM01 JES2 z/OS 2.4 ACTIVE PR05 JES2 z/OS 2.4 ACTIVE CM02 JES2 z/OS 2.4 ACTIVE PR03 JES2 z/OS 2.4 ACTIVE PR02 JES2 z/OS 2.4 ACTIVE PR01 JES2 z/OS 2.4 ACTIVE Paul Feller GTS Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Keith Gooding Sent: Thursday, August 11, 2022 9:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SDSF JS command cross-sysplex [EXTERNAL] I found that the SDSF ‘JS’ (job steps) command issued from the SDSF panels or via the REXX API produces no output if the target job is running on a different system in the sysplex. This is with z/os 2.5. On a 2.3 system the same happens except that the heading says ‘no job steps found’ (or similar message). Is anyone able to use JS cross-system or is this working as designed?. I am able to use others commands such as JT (Job Tasks) so I know that the SDSF address spaces are talking to each other. Keith Gooding -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Please note: This message originated outside your organization. Please use caution when opening links or attachments. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SDSF JS command cross-sysplex
I found that the SDSF ‘JS’ (job steps) command issued from the SDSF panels or via the REXX API produces no output if the target job is running on a different system in the sysplex. This is with z/os 2.5. On a 2.3 system the same happens except that the heading says ‘no job steps found’ (or similar message). Is anyone able to use JS cross-system or is this working as designed?. I am able to use others commands such as JT (Job Tasks) so I know that the SDSF address spaces are talking to each other. Keith Gooding -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SG24-2557 'System/390 MVS Parallel Sysplex Batch Performance' .pdf?
Glad there's still interest in that one. I'm rather proud of it. :-) Seriously, much of what we wrote is still valid. There are just a few places where more modern techniques exist. Cheers, Martin Sent from my iPad > On 1 Jul 2022, at 02:25, Sri h Kolusu wrote: > > >> >>> Does anyone have a .pdf of an old IBM redbook called 'System/390 MVS >>> Parallel Sysplex Batch Performance' (SG24-2557) that they'd be willing to >>> share? > > Michael, > > Does book manager format help? > > https://www.ibm.com/resources/publications/OutputPubsDetails?PubID=SG24255700 > > > If you need the PDF copy I can send it tomorrow offline > > > Thanks, > Kolusu > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless otherwise stated above: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SG24-2557 'System/390 MVS Parallel Sysplex Batch Performance' .pdf?
>> Does anyone have a .pdf of an old IBM redbook called 'System/390 MVS >> Parallel Sysplex Batch Performance' (SG24-2557) that they'd be willing to >> share? Michael, Does book manager format help? https://www.ibm.com/resources/publications/OutputPubsDetails?PubID=SG24255700 If you need the PDF copy I can send it tomorrow offline Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SG24-2557 'System/390 MVS Parallel Sysplex Batch Performance' .pdf?
Michael, Fortunately, I downloaded that redbook years ago, before it was withdrawn from the redbook website. At one point, I supplied my copy to one of the authors! It was my bible for tuning LSR buffer pools. I would be happy to send you a copy. Allan On Thu, Jun 30, 2022 at 8:44 PM Michael Watkins < 032966e74d0f-dmarc-requ...@listserv.ua.edu> wrote: > Does anyone have a .pdf of an old IBM redbook called 'System/390 MVS > Parallel Sysplex Batch Performance' (SG24-2557) that they'd be willing to > share? > > -- > 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
