Re: TSO temp dataset
Elardus, Thanks for the correction. I had read your reply, but the thread at that stage sounded to me like zSECURE built the JCL, and then the OP manually submitted it. I see that was incorrect, and we're just rehashing your original advice. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Thursday, February 15, 2018 10:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] TSO temp dataset Ron Hawkins wrote: >We're talking about the temp dataset that ISPF==>EDIT==>SUB command creates >before copying to INTRDR. Correct, but actually, in this specific thread, it is about how the allocation is done by zSecure and how to fix it. zSecure has its own version of Submit running REXX programs to do the allocations which I have described earlier in this thread. The OP has asked on RACF-L how to delete 200 000 ids (yes, one fifth of 1 million) and now asking space related question on IBM-MAIN. That is a lot of ids and he got the advice to split that job in parts. Perhaps this is why he has trouble submitting his extrememly large jobs. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Parmlib members change control?
Thanks to all who have responded - it looks like we are going to at least try the Git solution. In all my past placements as a sysprog, 'change control' or something like it has been part of the job, along with the associated 'royal pain' as Seymour rightly describes it. In this particular instance, I'm a 'team of one' looking after 2 mainframe-based z/OS's, and 3 more and a z/Linux running under z/VM on a z-PDT rig. Because I'm on my own, the idea of a formal, external change control system has never come up before, but the powers that be are beginning to look over their collective shoulder and recognising the fact that I am rapidly approaching retirement age. Strangely enough, having to start using a change control system again after all this time almost has a sense of 'coming home' associated with it. Sean On 16 February 2018 at 01:06, Steve Horein wrote: > Years ago, I had the opportunity to work with NewEra's ImageFocus. Neat > stuff to perform "virtual IPLs" (my description, not theirs), running the > gauntlet based on loadparm and load address, checking syntax of members, > verifying existence of data sets, etc.Like I say, neat stuff. Anyway, they > were developing a new offering: Control Editor. If I recall from some of > the presentations, it had the capability to enforce recording of change > justification, and retain backup copies of members. I never personally used > that offering - the company I worked for at the time stopped using the z > platform as their system of record, and I had to find a new place to work. > I had full intention of making use of it, had I the opportunity. That may > be something to look into. > http://www.newera-info.com/index.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
small MPF exit question concerning 'sticky' console messages
The programmers have a Cobol program that uses: DISPLAY OPR-MSG UPON CONSOLE. DISPLAY 'OPERATOR ACTION: IGNORE, RETRY, CANCEL' UPON CONSOLE. MOVE SPACES TO OPR-RPL. ACCEPT OPR-RPL FROM CONSOLE. This shows up on the console as: +OPERATOR ACTION: IGNORE, RETRY, CANCEL @15 IGZI AWAITING REPLY Currently, we trap the "AWAITING REPLY" in the MPF list using: IGZI,RETAIN(YES),SUP(NO),USEREXIT(MPFTREXX) The exit causes an email to be sent. (And that works) The outstanding issue is that the highlighted message rolls off the console. They would like for it to be sticky and not roll off. (It has always rolled off, even before we used the MPF exit.) Can this be done in the MPF exit? Somewhere else? z/OS 1.13 Thanks, -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: small MPF exit question concerning 'sticky' console messages
I think your problem is not the message but the console. I suppose this is a WTOR and that is sticky. It only remains on the console if the console is in MODE=RD, not in MODE=R. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Tony Thigpen > Sent: 16 February, 2018 14:37 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: small MPF exit question concerning 'sticky' console messages > > The programmers have a Cobol program that uses: >DISPLAY OPR-MSG UPON CONSOLE. >DISPLAY 'OPERATOR ACTION: IGNORE, RETRY, CANCEL' >UPON CONSOLE. >MOVE SPACES TO OPR-RPL. >ACCEPT OPR-RPL FROM CONSOLE. > > This shows up on the console as: >+OPERATOR ACTION: IGNORE, RETRY, CANCEL > @15 IGZI AWAITING REPLY > > Currently, we trap the "AWAITING REPLY" in the MPF list using: > IGZI,RETAIN(YES),SUP(NO),USEREXIT(MPFTREXX) > The exit causes an email to be sent. (And that works) > > The outstanding issue is that the highlighted message rolls off the > console. They would like for it to be sticky and not roll off. (It has > always rolled off, even before we used the MPF exit.) > > Can this be done in the MPF exit? Somewhere else? > > z/OS 1.13 > > Thanks, > > -- > Tony Thigpen > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Question: Users of Pacific Systems Group -- Vendor
I'm looking for users of Pacific Systems Group software, in particular z-Writer and its "front-ends" for other products, specifically ZWQUIK and ZWEASY. I'd like to know how well these work for you and how Pacific Systems Group is as a vendor. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question: Users of Pacific Systems Group -- Vendor
We trialed their other product SMF Writer. I liked the product. Unfortunately, upper management didn't want to spend the money to acquire the product. In comparison to what we recently spent on hardware upgrades, that cost was insignificant. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Thompson Sent: Friday, February 16, 2018 8:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Question: Users of Pacific Systems Group -- Vendor [External Email] I'm looking for users of Pacific Systems Group software, in particular z-Writer and its "front-ends" for other products, specifically ZWQUIK and ZWEASY. I'd like to know how well these work for you and how Pacific Systems Group is as a vendor. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: small MPF exit question concerning 'sticky' console messages
You are correct. Thanks. Tony Thigpen Vernooij, Kees (ITOPT1) - KLM wrote on 02/16/2018 08:42 AM: I think your problem is not the message but the console. I suppose this is a WTOR and that is sticky. It only remains on the console if the console is in MODE=RD, not in MODE=R. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: 16 February, 2018 14:37 To: IBM-MAIN@LISTSERV.UA.EDU Subject: small MPF exit question concerning 'sticky' console messages The programmers have a Cobol program that uses: DISPLAY OPR-MSG UPON CONSOLE. DISPLAY 'OPERATOR ACTION: IGNORE, RETRY, CANCEL' UPON CONSOLE. MOVE SPACES TO OPR-RPL. ACCEPT OPR-RPL FROM CONSOLE. This shows up on the console as: +OPERATOR ACTION: IGNORE, RETRY, CANCEL @15 IGZI AWAITING REPLY Currently, we trap the "AWAITING REPLY" in the MPF list using: IGZI,RETAIN(YES),SUP(NO),USEREXIT(MPFTREXX) The exit causes an email to be sent. (And that works) The outstanding issue is that the highlighted message rolls off the console. They would like for it to be sticky and not roll off. (It has always rolled off, even before we used the MPF exit.) Can this be done in the MPF exit? Somewhere else? z/OS 1.13 Thanks, -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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: J line command was: TSO temp dataset
Thanks, Kolusu! That was it. I haven't thought about PACK for so long that it never crossed my mind. I thought I had PACK OFF in everything because I've seen it cause issues in the past. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sri h Kolusu Sent: Thursday, February 15, 2018 5:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: J line command was: TSO temp dataset Pommier Rex, Check if you have PACK ON in your Profile. I can replicate your JCL error if the member has PACK ON and I get a JCL error. TYPE PACK OFF while editing the member and save it then try the J command Thanks, Kolusu IBM Mainframe Discussion List wrote on 02/15/2018 03:39:41 PM: > From: "Pommier, Rex" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 02/15/2018 03:40 PM > Subject: J line command was: TSO temp dataset > Sent by: IBM Mainframe Discussion List > > Subject change due to topic drift. > > I don't know what I'm doing wrong. z/OS 2.2. My PDS member looks like this: > > > EDIT RRP.JCL(I) - 01.04 Columns > Command ===> Scro > ** * Top of Data * > 01 //RRPB JOB (040423,495),RRP,CLASS=T,MSGCLASS=X,MSGLEVEL=(1,1), > 02 // NOTIFY=&SYSUID > 03 //STEP001 EXEC PGM=IEFBR14 > > Backing out to the member list: > > DSLISTRRP.JCL > Command ===> >Name Prompt Size Created > j I 3 2018/02/15 > > > when I hit enter, I get this: > > IKJ56700A ENTER JOBNAME CHARACTER(S) - > > > And I put in a random character (like Z) and get this: > > IKJ56250I JOB RRPZ(JOB02979) SUBMITTED > 16.35.54 JOB02979 $HASP165 RRPZ ENDED AT MVSJES2 - JCL ERROR CN > (INTERNAL) > > And my output looks like this: > > J E S 2 J O B L O G -- S Y S T E M Z O S 1 > -- N O D E M V S J E S 2 > > 16.35.54 JOB02979 THURSDAY, 15 FEB 2018 > 16.35.54 JOB02979 IRR010I USERID RRP IS ASSIGNED TO THIS JOB. > 16.35.54 JOB02979 IEFC452I RRPZ - JOB NOT RUN - JCL ERROR 478 > -- JES2 JOB STATISTICS -- > 6 CARDS READ >20 SYSOUT PRINT RECORDS > 0 SYSOUT PUNCH RECORDS > 1 SYSOUT SPOOL KBYTES > 0.00 MINUTES EXECUTION TIME > FILE>RRP.RRPZ.JOB02979.D003.JESJCL,2018.046,16: > 36:03:211 //RRPZ JOB 3331, > JOB02979 > // RRP, **JOB STATEMENT GENERATED BY > SUBMIT** > // NOTIFY=RRP, > // MSGLEVEL=(1,1) > 2 //SYSIN DD * GENERATED STATEMENT > FILE> RRP.RRPZ.JOB02979.D004.JESYSMSG,2018.046,16: > 36:03:21STMT NO. MESSAGE > 2 IEFC019I MISPLACED DD STATEMENT > 2 IEFC607I JOB HAS NO STEPS > > > I have no idea what it's submitting besides nothing, but it > definitely isn't what I put a "J" in front of. Ideas? > > Rex > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU > ] On Behalf Of Sri h Kolusu > Sent: Thursday, February 15, 2018 3:36 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: TSO temp dataset > > >>Am I looking in the wrong place? > > Gil, > > You need to look in ISPF User's guide Vol 1 under the section "Library and > data set list utility line commands" > > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/ > com.ibm.zos.v2r1.f54ug00/bdpr.htm > > > Thanks, > Kolusu > > > > The information contained in this message is confidential, protected > from disclosure and may be legally privileged. If the reader of > this message is not the intended recipient or an employee or agent > responsible for delivering this message to the intended recipient, > you are hereby notified that any disclosure, distribution, copying, > or any action taken or action omitted in reliance on it, is strictly > prohibited and may be unlawful. If you have received this > communication in error, please notify us immediately by replying to > this message and destroy the material in its entirety, whether in > electronic or hard copy format. Thank you. > > -- > 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 The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any act
Re: Question: Users of Pacific Systems Group -- Vendor
Our Systems Development tested the ZWESASY Product as a “front-end” to CA-Easytrieve (we migrated away from CA Products). They were satisfied and we have been using it in Production for about three months. My only issue with it is it does not use Easytrieve Macros. Thank You, Len Sasso System Administrator Out-Of-The-Office: TEAM: Together Everyone Achieves More RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400 t: +1.518.257.4209 | m: +1.518.894.0879 len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn CSRA Think Next. Now. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of PINION, RICHARD W. Sent: Friday, February 16, 2018 8:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Question: Users of Pacific Systems Group -- Vendor We trialed their other product SMF Writer. I liked the product. Unfortunately, upper management didn't want to spend the money to acquire the product. In comparison to what we recently spent on hardware upgrades, that cost was insignificant. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Thompson Sent: Friday, February 16, 2018 8:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Question: Users of Pacific Systems Group -- Vendor [External Email] I'm looking for users of Pacific Systems Group software, in particular z-Writer and its "front-ends" for other products, specifically ZWQUIK and ZWEASY. I'd like to know how well these work for you and how Pacific Systems Group is as a vendor. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This electronic message transmission contains information from CSRA that may be attorney-client privileged, proprietary or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe you have received this message in error, please contact me immediately and be aware that any use, disclosure, copying or distribution of the contents of this message is strictly prohibited. NOTE: Regardless of content, this email shall not operate to bind CSRA to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of email for such purpose. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Parmlib members change control?
Good lord no. I'm reminded that somehow ("magically I guess"), we all managed to survive the 60s, 70s, 80s, and even the early 90s without this formal change control nonsense. If you must track, then the product from action software works. Otherwise no, just no, easy solution below. current parm/proclib member - current name backout parm/proclib member - with a $ suffix at the end (if you want one more backlevel, then use a # as the suffix) Implementation and backout plans work wonders and have been way before formal change management was ever devised. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
PR/SM LPAR Controls Change Running System
Hi List, I have a question about what we recently experienced when dealing with Defined Capacity changes. Say I have a production LPAR with a defined capacity of 100 and a tech-only LPAR with 10. Management decides that we can afford an extra 2 MSU, temporarily. So I enter Change LPAR Controls and change the production LPAR's Defined Capacity to 102 and a tech-only LPAR to 8. At this point, I click the Change Running System button to apply the change. A few days later, the tech-only LPAR was re-IPL'd using a custom group with a load profile. The IPL was performed by selecting Activate. We notice at this point that the tech-only LPAR's Defined Capacity was set to 10. We promptly changed it back to 8. Then, to test this situation again, I started with a baseline of production=100 and tech-only=5. I entered Change LPAR Controls again and changed the tech-only to 8 and again clicked on Change Running System. This time, when the IPL was performed via an activate, the LPAR came up with a defined capacity of 8. I've found some conflicting documentation on the Google: http://www-01.ibm.com/support/docview.wss?uid=tss1wp102437&aid=1 This page says that Change Running System changes are lost after a POR http://www-01.ibm.com/support/docview.wss?uid=isg209611e17c3b8d419852573f700645d4d&aid=1 This page says that it's lost after a reactivation of a partition It seems that PR/SM selects the highest Defined Capacity between the Running System and what's saved in the Activation profile for the LPAR. Can anyone shed some light as to how PR/SM actually works? Andrew Arentsen Senior Mainframe Systems Engineer Phone: 800.242.7666 x1349 ** This e-mail is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this e-mail in error, please tell us immediately by return e-mail and delete the document. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM Debug tool issue
>When using Debug Tool under CICS, every time a CALL statement is encountere= >d the debugger steps into the called program. >Is there a way to just have the called program called and not show its inte= >rnal workings. > >We are using Debug Tool v14.1, z/OS v2.2, COBOL v6 and CICS TS v5.4. I think what you want is STEP OVER, not STEP INTO in Debug Tool Cheers, TomR >> COBOL is the Language of the Future! << -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
>FWIW, I am guessing "255" was simply a brain-glitch for 100, and had no >basis in any actual technology. Charles, you nailed my brain fart exactly! In response to other posts and Frank, I agree that we should answer the RFE for a change to our SYSOPTF support as: "AVAILABLE: Use PARMDD" Cheers, TomR >> COBOL is the Language of the Future! << -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question for COBOL users
On Fri, 16 Feb 2018 11:13:05 -0800, Tom Ross wrote: > >In response to other posts and Frank, I agree that we should answer the >RFE for a change to our SYSOPTF support as: "AVAILABLE: Use PARMDD" > Yaaay! Now you may have to deal with, "But that's not the way we planned to do it." If PARMDD refers to a SYSIN it supports symbol substitution (almost) like EXEC PARM=. There are a few annoying differences. Of course, PARMDD may be a concatenation of library option members (like SYSOPTF). And someone suggested using DDNAME= for more flexibility (again, like SYSOPTF). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PR/SM LPAR Controls Change Running System
In my understanding both pages are correct, you lose the changes after a POR, you also lose the changes if you activate the partition. When you IPL by Activate you use the activation profile settings. You can IPL with the Load command to not re-activate the LPAR and use the previous defined capacity. Regards, Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Andrew Arentsen Sent: Friday, February 16, 2018 12:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: PR/SM LPAR Controls Change Running System Hi List, I have a question about what we recently experienced when dealing with Defined Capacity changes. Say I have a production LPAR with a defined capacity of 100 and a tech-only LPAR with 10. Management decides that we can afford an extra 2 MSU, temporarily. So I enter Change LPAR Controls and change the production LPAR's Defined Capacity to 102 and a tech-only LPAR to 8. At this point, I click the Change Running System button to apply the change. A few days later, the tech-only LPAR was re-IPL'd using a custom group with a load profile. The IPL was performed by selecting Activate. We notice at this point that the tech-only LPAR's Defined Capacity was set to 10. We promptly changed it back to 8. Then, to test this situation again, I started with a baseline of production=100 and tech-only=5. I entered Change LPAR Controls again and changed the tech-only to 8 and again clicked on Change Running System. This time, when the IPL was performed via an activate, the LPAR came up with a defined capacity of 8. I've found some conflicting documentation on the Google: http://www-01.ibm.com/support/docview.wss?uid=tss1wp102437&aid=1 This page says that Change Running System changes are lost after a POR http://www-01.ibm.com/support/docview.wss?uid=isg209611e17c3b8d419852573f700645d4d&aid=1 This page says that it's lost after a reactivation of a partition It seems that PR/SM selects the highest Defined Capacity between the Running System and what's saved in the Activation profile for the LPAR. Can anyone shed some light as to how PR/SM actually works? Andrew Arentsen Senior Mainframe Systems Engineer Phone: 800.242.7666 x1349 ** This e-mail is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this e-mail in error, please tell us immediately by return e-mail and delete the document. -- 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: PR/SM LPAR Controls Change Running System
In many/most?/all? of the HMC LPAR controls, you have three options: only change running system, only save changes to activation profile, or do both. The LPAR (Image) profile comes into play any time the LPAR is activated, which includes POR. Unless the profile has been updated one way or another, dynamic 'running system' changes will be lost on the next activation. IPL itself with or without the LOAD profile does not cause LPAR activation unless the LPAR has been previously deactivated. That is, IPLing a 'not activated' LPAR entails first activation by Image profile followed by IPL with or without use of the LOAD profile. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Leonardo Vaz Sent: Friday, February 16, 2018 1:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: PR/SM LPAR Controls Change Running System In my understanding both pages are correct, you lose the changes after a POR, you also lose the changes if you activate the partition. When you IPL by Activate you use the activation profile settings. You can IPL with the Load command to not re-activate the LPAR and use the previous defined capacity. Regards, Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Andrew Arentsen Sent: Friday, February 16, 2018 12:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: PR/SM LPAR Controls Change Running System Hi List, I have a question about what we recently experienced when dealing with Defined Capacity changes. Say I have a production LPAR with a defined capacity of 100 and a tech-only LPAR with 10. Management decides that we can afford an extra 2 MSU, temporarily. So I enter Change LPAR Controls and change the production LPAR's Defined Capacity to 102 and a tech-only LPAR to 8. At this point, I click the Change Running System button to apply the change. A few days later, the tech-only LPAR was re-IPL'd using a custom group with a load profile. The IPL was performed by selecting Activate. We notice at this point that the tech-only LPAR's Defined Capacity was set to 10. We promptly changed it back to 8. Then, to test this situation again, I started with a baseline of production=100 and tech-only=5. I entered Change LPAR Controls again and changed the tech-only to 8 and again clicked on Change Running System. This time, when the IPL was performed via an activate, the LPAR came up with a defined capacity of 8. I've found some conflicting documentation on the Google: http://www-01.ibm.com/support/docview.wss?uid=tss1wp102437&aid=1 This page says that Change Running System changes are lost after a POR http://www-01.ibm.com/support/docview.wss?uid=isg209611e17c3b8d419852573f700645d4d&aid=1 This page says that it's lost after a reactivation of a partition It seems that PR/SM selects the highest Defined Capacity between the Running System and what's saved in the Activation profile for the LPAR. Can anyone shed some light as to how PR/SM actually works? Andrew Arentsen Senior Mainframe Systems Engineer Phone: 800.242.7666 x1349 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMS dataset oddity with COM-Plete
Hi, One of our customers is running an old(er) version of Software AG's Com-Plete (version 6.4.1) along with testing version 6.8.1, and we have found that when a dataset (any sequential or PDS) is moved from a regular 3390-3 to a 3390-3 that is part of a storage group (same raid box, and close to the same address (in this case the non-SMS volume is on x'0309', and the SMS pool starts at x'0310'), they get an S0C1 when they try to edit or browse that dataset from within Com-Plete, but when we move it back to any non-SMS 3390-3 (or even a 3390-9 or 3390-27) it can be accessed with no problems at all. The problem doesn't happen with com-plete 6.8.1, and Software AG is telling us simultaneously that a) there should be no difference in the edit component between the two releases, and b) they no longer support 6.4.1 so they can't look into it, and even if they did, they would not be able provide a "fix" any more for that level. The client is okay with not moving the datasets to SMS until after the new version of Com-Plete is in production (currently not planned until January 2019), but it bothers me that this is happening and I have no explanation for it. It's also throwing a wrench into my SMS conversion for them. I have a "feeling" that it has something to do with the control blocks that are built in a different place for SMS datasets and non-SMS datasets, but since SMS has been around since Com-Plete 6.1.1 (8 years before 6.4.1), there appears to be no logical reason why it should fail just because the dataset is on an SMS volume. Does anyone have any ideas on how to address this? Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN