Problem defining LU Range
Hi, I defined the following statement in the TCP/IP Profile LUGROUP HAR1LU BIH1001A..BIH1256A ENDLUGROUP When I try to activate it I get the message: EZZ0186I LU_RANGE BIH1001A..BIH1256A INCORRECTLY SPECIFIED This is running on OS/390 v.28 (Groan). I looked at the OS/390 V2.8 IP Configuration manual, and it seems to be ok. What is wrong here? Gadi לשימת לבך, בהתאם לנהלי חברת מלם מערכות בעמ ו/או כל חברת בת ו/או חברה קשורה שלה (להלן : החברה) וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam and/or its subsidiaries (hereinafter : Malam) regulations and signatory rights, no offer, agreement, concession or representation is binding on the Malam, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the Malam seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problem defining LU Range
Hi Gadi, I think you must specify how to determine new LUs. We do it this way. Please have a look at IP Configuration Guide. There you will find: LU range specification: Telnet LU range rules allow for almost any type of LU range needed. Ranges can be alphabetic (A), numeric (N), alphanumeric (B), hexadecimal (X), or a complete wildcard (?), which includes alphanumeric and the three national characters (@,#,$). The range type can be different for each character position. Within the LU range, any character position can be fixed (F). To conform with VTAM LU naming convention, the first character must be alphabetic or a national character. If the first character is a range, only the alphabetic range can be used. An LU range is created by specifying a starting LU name, an ending LU name, and the range rules to be used. For example, the following statement creates a range from TCPM1000 to TCPM1100. TCPM1000..TCPM1100..FNNN etc .. regards Juergen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problem defining LU Range
try this: LUGROUP HAR1LU BIH1001A..BIH1256A..NNNF ENDLUGROUP -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: IKJ56500I COMMAND OPUTX NOT FOUND
Forget all those Irish commands (OGET, OPUT, etc.) and start unsing UNIX commands. Here are two JCL's I'm using to run UNIX commands in batch: // EXPORT SYMLIST=*// SET DIR='newdir'//UNIXCMDS EXEC PGM=BPXBATCH //STDINDD DUMMY //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //SYMRESDD DD SYSOUT=* //STDPARM DD *,SYMBOLS=(JCLONLY) SH cd /some/directory ; ls -l ; mkdir -m 700 DIR./* Note that STDPARM is the BPXBATCH vatiant of PARMDD, and don't confuse them. You start with the usual SH to tell BPXBATCH to run a shell. All the rest of STDPARM is input to that shell, so you need to adhere to shell command line syntax. Chain multiple commands with the ;. Note also that you must not try to insert comment, because the first # will start a comment that goes to the end of STDPARM. Advantage: You can user JCL symbols (and if your jobclass allows it, also system symbols) in the UNIX commands. The second job is solving the problem of running commands via su in batch. Its not perfect, but mostly does the trick for me. First, there is a JCL procedure: //BPXSU PROC SOUT='*',TMP='tmp-command-file-for-BPXSU-job' //INPUT EXEC PGM=IEBGENER //SYSPRINT DD DUMMY //SYSIN DD DUMMY //SYSUT1DD DDNAME=COMMANDS //SYSUT2DD PATH='/tmp/SYSUID-TMP', // PATHDISP=(KEEP,DELETE), // PATHOPTS=(OWRONLY,OCREAT,OEXCL), // PATHMODE=(SIRUSR,SIWUSR) //EXECUSS EXEC PGM=BPXBATCH,PARM='SH su' //STDOUTDD SYSOUT=SOUT. //STDERRDD SYSOUT=SOUT. //STDIN DD PATH='/tmp/SYSUID-TMP', // PATHDISP=(DELETE,DELETE) //STDPARM DD DUMMY Second, here is how to use it: // EXPORT SYMLIST=*// SET FILE='somefile'//UNIXCMDS EXEC BPXSU//COMMANDS DD *,SYMBOLS=(JCLONLY) ls -l ; chown foo:bar FILE./* The rules for COMMANDS are similar to the above. Note that this is STDIN, not STDPARM, so the SH is not need. Also, fi system symbols are allowed, the you can make the temp file name more unique using date, time or other system symbols. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problem defining LU Range
Hi Juergen, Unfortunatly, the third parameter was intorduced sometime after OS/390 v2.8, so I cannot use it. Gadi From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Juergen Keller [keller-ibmm...@web.de] Sent: 17 December 2014 10:42 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Problem defining LU Range try this: LUGROUP HAR1LU BIH1001A..BIH1256A..NNNF ENDLUGROUP -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN לשימת לבך, בהתאם לנהלי חברת מלם מערכות בעמ ו/או כל חברת בת ו/או חברה קשורה שלה (להלן : החברה) וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam and/or its subsidiaries (hereinafter : Malam) regulations and signatory rights, no offer, agreement, concession or representation is binding on the Malam, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the Malam seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problem defining LU Range
WARNING: I'm not working with TCP/IP these days anymore, but ... ;-) Gadi wrote: I defined the following statement in the TCP/IP Profile LUGROUP HAR1LU BIH1001A..BIH1256A ENDLUGROUP When I try to activate it I get the message: EZZ0186I LU_RANGE BIH1001A..BIH1256A INCORRECTLY SPECIFIED All our LU groups are all numeric in the last few (usually 4) characters, in case this could be the reason. Perhaps you could try it out, but yes, I saw Juergen Keller's excellent replies and I cannot find any problem with that. Or ... your group is already defined before that statement. This is running on OS/390 v.28 (Groan). Yeah... What is wrong here? Show us the LUMAP for HAR1LU and IPGROUP too. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problem defining LU Range
Back then the LU names had to consist of the LU base name and the range specification (i.e. at the end). So a definition like BIHA1001..BIHA1256 should work. Regards and good luck, Klaus Stanislawiak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Trouble with IARV64 GETCOMMON
The default setting for IARV64 FPROT is YES meaning that the program accessing the storage must have a PSW key that matches the storage key of the memobj (or PSW key 0). I believe that IPCS storage browse ACTIVE runs in problem state and key8 - therefore you will not see the storage. If you want all address spaces to see your common memobj, try using FPROT=NO on the IARV64 macro. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Donald Likens Sent: 16 December 2014 20:31 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Trouble with IARV64 GETCOMMON I issue the following macro: IARV64 REQUEST=GETCOMMON, COND=YES, SEGMENTS=SBS01, === Value is 1. MOTKNSOURCE=SYSTEM,OUTMOTKN=SBITKN, TYPE=PAGEABLE, OWNERCOM=SYSTEM, ORIGIN=SBILOC, DUMP=LIKECSA, RSNCODE=SBIRSN I display the address obtained. When I look at this address in IPCS looking at the ACTIVE address space, I do not see my storage. When I take a dump of my address space, I see my storage. What am I doing wrong? -- 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 ■ +1 800.966.3270 ■ +1 781.577.4321 Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Problem defining LU Range
Here are the complete definitions: LUGROUP HAR1LU BIH10001..BIH10256 ENDLUGROUP IPGROUP HAR1IP 255.255.255.0:10.100.2.0 255.255.255.0:10.100.12.0 255.255.255.0:10.100.13.0 255.255.255.0:10.100.14.0 255.255.255.0:10.100.15.0 255.255.255.0:10.100.16.0 255.255.255.0:10.100.17.0 255.255.255.0:10.100.18.0 255.255.255.0:10.100.19.0 ENDIPGROUP LUMAP HAR1LU HAR1IP Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Wednesday, December 17, 2014 12:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Problem defining LU Range WARNING: I'm not working with TCP/IP these days anymore, but ... ;-) Gadi wrote: I defined the following statement in the TCP/IP Profile LUGROUP HAR1LU BIH1001A..BIH1256A ENDLUGROUP When I try to activate it I get the message: EZZ0186I LU_RANGE BIH1001A..BIH1256A INCORRECTLY SPECIFIED All our LU groups are all numeric in the last few (usually 4) characters, in case this could be the reason. Perhaps you could try it out, but yes, I saw Juergen Keller's excellent replies and I cannot find any problem with that. Or ... your group is already defined before that statement. This is running on OS/390 v.28 (Groan). Yeah... What is wrong here? Show us the LUMAP for HAR1LU and IPGROUP too. 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 לשימת לבך, בהתאם לנהלי חברת מלם מערכות בעמ ו/או כל חברת בת ו/או חברה קשורה שלה (להלן : החברה) וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam and/or its subsidiaries (hereinafter : Malam) regulations and signatory rights, no offer, agreement, concession or representation is binding on the Malam, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the Malam seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)
W dniu 2014-12-16 o 22:11, J O Skip Robinson pisze: My complaints focus on those HCs that don't really make sense any more. For example, in 1984 it would have been a cogent warning that the Product X master file and its backup/alternate are located behind the same DASD control unit. If you lost the control unit, you'd lose both copies. In 2014 with array technology, there is no longer a physical control unit. You have a big box with hundreds of logical volumes. If you lose the whole box, you're in a world of hurt so egregious that the demise of a master file is just noise. Yet I get constant warnings about a configuration oversight for which there is no feasible remedy. Sure I can turn the HC off, but shouldn't common sense (and a bit of extra coding) turn it off for me? introduction Well, I'm not going to invent some check which can be senseless for me but reasonable for you. Sometimes the check itself can check whether configuration is applicable, in some other cases it is up to administrator to decide. /introduction Now, Health Checker has its own configuration member in parmlib, you can easily (and dynamically of course) disable unneeded checks. Theoretical example: on system ABC I have one library with more1 extent on LNKLST. I'm aware of it, I cannot change it now, the planned outage will be in March, so I don't want to be warned about it verey 4 hours. Regards -- Radoslaw Skorupka Lodz, Poland --- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MIPS, CEC, LPARs, PRISM, WLM
W dniu 2014-12-17 o 13:44, L Hagedorn pisze: Hi IBM-MAIN, We have a situation with multiple LPARS on a CEC, running DB2 asids prod, test, dev. It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and stealing MIPS from the PROD LPAR and affecting production. Others claim this is not possible due to Prism. Will someone provide an overview of how Prism influences or controls MIPS usage (CPU) across LPARs sharing the same CEC, what are the limiting or controlling factors (if any), and how can the behavior be measured or reported upon so I can explain this with supporting doc? Does WLM play a part in sharing CPU across LPARs? Any information or referrals to doc is appreciated. (some simlifications done) First, it's easier to talkt about system A in LPAR A and system B in LPAR B. Nevermind what applications are running under given system. You decide how much percentage of total CPU power is assigned to the LPARs, i.e. 70% for LPAR A and 20% for LPAR B and 10% for LPAR C. However when LPAR A is not busy but LPAR B is busy it can happen LPAR B will consume more than you assigned. It's OK because stealing LPAR will consume only spare CPU cycles. You can prevent it (why? ) by using capping. In fact the weights are in use when all LPARs want do consume more than assigned. HTH -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2014 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.696.052 zote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MIPS, CEC, LPARs, PRISM, WLM
Linda Hagedorn wrote: We have a situation with multiple LPARS on a CEC, running DB2 asids prod, test, dev. What z/OS levels? What levels of DB2 on all those LPARS? It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and stealing MIPS from the PROD LPAR and affecting production. Based on what were those claims made? I would like to see for example, RMF or SMF data/reports or some other tools used to prove that claims. Are you having response time problems? Others claim this is not possible due to Prism. Will someone provide an overview of how Prism influences or controls MIPS usage (CPU) across LPARs sharing the same CEC, what are the limiting or controlling factors (if any), and how can the behavior be measured or reported upon so I can explain this with supporting doc? Does WLM play a part in sharing CPU across LPARs? Are your LPARS hard or soft capped? What are the CPU and MSU allocations to your LPARS? Any information or referrals to doc is appreciated. I'll leave that to the real performance gurus on IBM-MAIN. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ftp rdw
Yes, you can do it yourself. https://www.ibm.com/developerworks/rfe Kirk Wolf Dovetailed Technologies http://dovetail.com On Tue, Dec 16, 2014 at 9:38 PM, Paul Edwards mutazi...@gmail.com wrote: You should submit an RFE for FTP to IBM. Hi Kirk. I am not an IBM customer. Is this something you could do yourself? Or will anyone else volunteer? 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
Re: MIPS, CEC, LPARs, PRISM, WLM
The answer is, it depends. First, there is no priority across LPARS. All LPARS are dispatched equally according to the LPAR weights. For example, if LPARA is weighted are 80 and LPARB is weighted at 20, the following occurs: If LPARA wants 85% and LPARB wants 10% (total 85%) everybody is happy and goes on their merry way. If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20% and LPARA will be squeezed to 80%. If LPARA wants 50% and LPARB wants 40% (total 90%) everybody is happy and goes on their merry way. The LPARA weight represents a guaranteed minimum proportion (note: LPAR weights need not total to 100. The proportion is relative.) All of the above occurs when capping (either hard or soft) is not present. Software capping can occur with resource groups. Hardware capping can occur with group capacity limits. This is a complex subject and much more than can be covered in a short e-mail. If you have not already done so, I suggest you obtain a copy of and read the PR/SM Planning Guide. The most recent version I can find is SB10-7155-01 and is located here: https://www-304.ibm.com/support/docview.wss?uid=isg202e537c11be0929c8525776100663570aid=1 (watch the wrap). RMF Monitor I (batch) has an excellent CPU report. This will also include the PARTITION DATA REPORT. I will refer you to the fine manuals for details/ WLM *may* reach across LPAR Boundaries. If fact, it is designed to do this. However, if the DVLP lpar is not in the same SYSPLEX, WLM cannot be a factor. As others have pointed out, what evidence is there that the runaway task is affecting production (factual, not conjecture!)? HTH, snip We have a situation with multiple LPARS on a CEC, running DB2 asids prod, test, dev. It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and stealing MIPS from the PROD LPAR and affecting production. Others claim this is not possible due to Prism. Will someone provide an overview of how Prism influences or controls MIPS usage (CPU) across LPARs sharing the same CEC, what are the limiting or controlling factors (if any), and how can the behavior be measured or reported upon so I can explain this with supporting doc? Does WLM play a part in sharing CPU across LPARs? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ftp rdw
On Wed, 17 Dec 2014 07:55:03 -0600, Kirk Wolf wrote: Yes, you can do it yourself. https://www.ibm.com/developerworks/rfe Is DeveloperWorks membership required? $$$? Kirk Wolf Dovetailed Technologies http://dovetail.com On Tue, Dec 16, 2014 at 9:38 PM, Paul Edwards wrote: You should submit an RFE for FTP to IBM. Hi Kirk. I am not an IBM customer. Is this something you could do yourself? Or will anyone else volunteer? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: IKJ56500I COMMAND OPUTX NOT FOUND
On Wed, 17 Dec 2014 09:48:45 +0100, Peter Hunkeler wrote: Forget all those Irish commands (OGET, OPUT, etc.) and start unsing UNIX commands. ... Note that STDPARM is the BPXBATCH vatiant of PARMDD, and don't confuse them. You start with the usual SH to tell BPXBATCH to run a shell. All the rest of STDPARM is input to that shell, so you need to adhere to shell command line syntax. Chain multiple commands with the ;. Note also that you must not try to insert comment, because the first # will start a comment that goes to the end of STDPARM. You might bootleg a comment in with such as: : ' - This serves as a comment. I have not tested it on z/OS BPXBATCH. It must contain no apostrophes. - ' Advantage: You can user JCL symbols (and if your jobclass allows it, also system symbols) in the UNIX commands. With z/OS 2.1 and higher. Jobclass? Are system symbols considered secret/sensitive? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IKJ56500I COMMAND OPUTX NOT FOUND
THAT IS AWESOME! Wow! Thanks, Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Wednesday, December 17, 2014 12:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: Re: IKJ56500I COMMAND OPUTX NOT FOUND Forget all those Irish commands (OGET, OPUT, etc.) and start unsing UNIX commands. Here are two JCL's I'm using to run UNIX commands in batch: // EXPORT SYMLIST=*// SET DIR='newdir'//UNIXCMDS EXEC PGM=BPXBATCH //STDINDD DUMMY //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //SYMRESDD DD SYSOUT=* //STDPARM DD *,SYMBOLS=(JCLONLY) SH cd /some/directory ; ls -l ; mkdir -m 700 DIR./* Note that STDPARM is the BPXBATCH vatiant of PARMDD, and don't confuse them. You start with the usual SH to tell BPXBATCH to run a shell. All the rest of STDPARM is input to that shell, so you need to adhere to shell command line syntax. Chain multiple commands with the ;. Note also that you must not try to insert comment, because the first # will start a comment that goes to the end of STDPARM. Advantage: You can user JCL symbols (and if your jobclass allows it, also system symbols) in the UNIX commands. The second job is solving the problem of running commands via su in batch. Its not perfect, but mostly does the trick for me. First, there is a JCL procedure: //BPXSU PROC SOUT='*',TMP='tmp-command-file-for-BPXSU-job' //INPUT EXEC PGM=IEBGENER //SYSPRINT DD DUMMY //SYSIN DD DUMMY //SYSUT1DD DDNAME=COMMANDS //SYSUT2DD PATH='/tmp/SYSUID-TMP', // PATHDISP=(KEEP,DELETE), // PATHOPTS=(OWRONLY,OCREAT,OEXCL), // PATHMODE=(SIRUSR,SIWUSR) //EXECUSS EXEC PGM=BPXBATCH,PARM='SH su' //STDOUTDD SYSOUT=SOUT. //STDERRDD SYSOUT=SOUT. //STDIN DD PATH='/tmp/SYSUID-TMP', // PATHDISP=(DELETE,DELETE) //STDPARM DD DUMMY Second, here is how to use it: // EXPORT SYMLIST=*// SET FILE='somefile'//UNIXCMDS EXEC BPXSU//COMMANDS DD *,SYMBOLS=(JCLONLY) ls -l ; chown foo:bar FILE./* The rules for COMMANDS are similar to the above. Note that this is STDIN, not STDPARM, so the SH is not need. Also, fi system symbols are allowed, the you can make the temp file name more unique using date, time or other system symbols. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: IKJ56500I COMMAND OPUTX NOT FOUND
THAT IS AWESOME! Wow! Thanks, You're welcome. I recognize from seeming my onw post that it has been reformatted in a bad way. A couple of line feeds have been dropped. Hope you can decifer the samples anyway. If not, tell me and I will try reposting them. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: AW: Re: IKJ56500I COMMAND OPUTX NOT FOUND
On Wed, 17 Dec 2014 16:32:33 +0100, Peter Hunkeler wrote: Advantage: You can user JCL symbols (and if your jobclass allows it, also system symbols) in the UNIX commands. With z/OS 2.1 and higher. Jobclass? Are system symbols considered secret/sensitive? I guess, no. I imagine this is more to be able to selectively switch this feature on to protect from side effects in existing JCL. Dammit! As I said before, ab ovo an apparent reference to an undefined symbol such as: //SYSUT2 DD DISP=(,PASS),DSN=SYSUT2 ... should have been treated as a syntax error. (Shmuel has pointed out that the behavior can't be introduced now; it would break vast amounts of existing JCL.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
publibz-infocenter-knowledgecenter
Curse you, Red Baron! My bookmark to publibz/z/OS documentation redirected for a while to a similar infocenter shelf list; later to a knowledgecenter shelflist. Now it redirects to the knowledgecenter storefront. What's a quick link to this week's z/OS v2r1 software shelflist? (was: http://pic.dhe.ibm.com/infocenter/zos/v2r1/index.jsp ) Bring back LOOKAT! Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MIPS, CEC, LPARs, PRISM, WLM
MVS Sysprogs reported the situation saying DB2DIST on LPAR A was affecting LPAR B. I didn't ask them for doc, but will next time. This is a runtime issue, unrelated to reported changes. That being said, I'm aware WLM is changed frequently and without broadcast notification. This appears from time to time. I am new here (couple of months) so cannot determine how long its been happening - could be months, could be years. I need to understand the interworkings of prism, WLM, and the LPARs, and from the postings today, more about soft and hard capping. All input is appreciated. I have a learning curve in this area, so telling me to look for something in RMF is welcome, along with any display commands where I can see the caps. I have Mainview. Sent from my iPhone On Dec 17, 2014, at 8:35 AM, Lizette Koehler stars...@mindspring.com wrote: I would ask first, how do you know it is affecting the Prod LPAR. What evidence, RMF Reports, Performance monitors, etc. ? There should be, I think, so data that could explicitly show that is what is happening. Is it all the time, some of the time? Is it a specific time when the prod LPAR is affected? How long has it been going on? Is there a point in time when this started? If so, what changes occurred at that point? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of L Hagedorn Sent: Wednesday, December 17, 2014 5:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: MIPS, CEC, LPARs, PRISM, WLM Hi IBM-MAIN, We have a situation with multiple LPARS on a CEC, running DB2 asids prod, test, dev. It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and stealing MIPS from the PROD LPAR and affecting production. Others claim this is not possible due to Prism. Will someone provide an overview of how Prism influences or controls MIPS usage (CPU) across LPARs sharing the same CEC, what are the limiting or controlling factors (if any), and how can the behavior be measured or reported upon so I can explain this with supporting doc? Does WLM play a part in sharing CPU across LPARs? Any information or referrals to doc is appreciated. Thanks, Linda -- 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: publibz-infocenter-knowledgecenter
On Wed, 17 Dec 2014 09:56:22 -0600, Paul Gilmartin wrote: Curse you, Red Baron! Seriously. Under the nav frame in http://www-01.ibm.com/support/knowledgecenter/ I find TOC-IBM Operating Systems-System z Operating Systems-z/OS-2.1.0 so buried in Javascript that I don't know what it's trying to do. It 404s. This sort of thing could erode my respect for IBM. (Actually, I just found on the error page a link that seems to work. But, still, ...) Bring back LOOKAT! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MIPS, CEC, LPARs, PRISM, WLM
Thank you for the extensive information and examples. I will be hitting the books. Can you expand on this example: If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20% and LPARA will be squeezed to 80%. It seems counter intuitive to me and I'd like to understand. Lets say LPARA is prod - they should get most of the resources. Why would LPARA be squeezed instead of LPARB? Sent from my iPhone On Dec 17, 2014, at 9:07 AM, Staller, Allan allan.stal...@kbmg.com wrote: The answer is, it depends. First, there is no priority across LPARS. All LPARS are dispatched equally according to the LPAR weights. For example, if LPARA is weighted are 80 and LPARB is weighted at 20, the following occurs: If LPARA wants 85% and LPARB wants 10% (total 85%) everybody is happy and goes on their merry way. If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20% and LPARA will be squeezed to 80%. If LPARA wants 50% and LPARB wants 40% (total 90%) everybody is happy and goes on their merry way. The LPARA weight represents a guaranteed minimum proportion (note: LPAR weights need not total to 100. The proportion is relative.) All of the above occurs when capping (either hard or soft) is not present. Software capping can occur with resource groups. Hardware capping can occur with group capacity limits. This is a complex subject and much more than can be covered in a short e-mail. If you have not already done so, I suggest you obtain a copy of and read the PR/SM Planning Guide. The most recent version I can find is SB10-7155-01 and is located here: https://www-304.ibm.com/support/docview.wss?uid=isg202e537c11be0929c8525776100663570aid=1 (watch the wrap). RMF Monitor I (batch) has an excellent CPU report. This will also include the PARTITION DATA REPORT. I will refer you to the fine manuals for details/ WLM *may* reach across LPAR Boundaries. If fact, it is designed to do this. However, if the DVLP lpar is not in the same SYSPLEX, WLM cannot be a factor. As others have pointed out, what evidence is there that the runaway task is affecting production (factual, not conjecture!)? HTH, snip We have a situation with multiple LPARS on a CEC, running DB2 asids prod, test, dev. It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and stealing MIPS from the PROD LPAR and affecting production. Others claim this is not possible due to Prism. Will someone provide an overview of how Prism influences or controls MIPS usage (CPU) across LPARs sharing the same CEC, what are the limiting or controlling factors (if any), and how can the behavior be measured or reported upon so I can explain this with supporting doc? Does WLM play a part in sharing CPU across LPARs? /snip -- 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: IKJ56500I COMMAND OPUTX NOT FOUND
Yeah but that's only as of z/OS 2.1 ….as a ISV we support backlevel versions also …so one has to come up with two solutions … Regards, Scott From: Charles Mills Sent: Wednesday, December 17, 2014 10:17 AM To: IBM-MAIN@LISTSERV.UA.EDU THAT IS AWESOME! Wow! Thanks, Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Wednesday, December 17, 2014 12:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: Re: IKJ56500I COMMAND OPUTX NOT FOUND Forget all those Irish commands (OGET, OPUT, etc.) and start unsing UNIX commands. Here are two JCL's I'm using to run UNIX commands in batch: // EXPORT SYMLIST=*// SET DIR='newdir'//UNIXCMDS EXEC PGM=BPXBATCH //STDINDD DUMMY //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //SYMRESDD DD SYSOUT=* //STDPARM DD *,SYMBOLS=(JCLONLY) SH cd /some/directory ; ls -l ; mkdir -m 700 DIR./* Note that STDPARM is the BPXBATCH vatiant of PARMDD, and don't confuse them. You start with the usual SH to tell BPXBATCH to run a shell. All the rest of STDPARM is input to that shell, so you need to adhere to shell command line syntax. Chain multiple commands with the ;. Note also that you must not try to insert comment, because the first # will start a comment that goes to the end of STDPARM. Advantage: You can user JCL symbols (and if your jobclass allows it, also system symbols) in the UNIX commands. The second job is solving the problem of running commands via su in batch. Its not perfect, but mostly does the trick for me. First, there is a JCL procedure: //BPXSU PROC SOUT='*',TMP='tmp-command-file-for-BPXSU-job' //INPUT EXEC PGM=IEBGENER //SYSPRINT DD DUMMY //SYSIN DD DUMMY //SYSUT1DD DDNAME=COMMANDS //SYSUT2DD PATH='/tmp/SYSUID-TMP', // PATHDISP=(KEEP,DELETE), // PATHOPTS=(OWRONLY,OCREAT,OEXCL), // PATHMODE=(SIRUSR,SIWUSR) //EXECUSS EXEC PGM=BPXBATCH,PARM='SH su' //STDOUTDD SYSOUT=SOUT. //STDERRDD SYSOUT=SOUT. //STDIN DD PATH='/tmp/SYSUID-TMP', // PATHDISP=(DELETE,DELETE) //STDPARM DD DUMMY Second, here is how to use it: // EXPORT SYMLIST=*// SET FILE='somefile'//UNIXCMDS EXEC BPXSU//COMMANDS DD *,SYMBOLS=(JCLONLY) ls -l ; chown foo:bar FILE./* The rules for COMMANDS are similar to the above. Note that this is STDIN, not STDPARM, so the SH is not need. Also, fi system symbols are allowed, the you can make the temp file name more unique using date, time or other system symbols. -- 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: ftp rdw
On Wed, 17 Dec 2014 07:55:03 -0600, Kirk Wolf wrote: Yes, you can do it yourself. https://www.ibm.com/developerworks/rfe In the description of the FTP SITE subcommand in: z/OS Communications Server: IP User's Guide and Commands SC27-3662-00 http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.halu001/site.htm z/OS V2R1z/OS Communications Serverz/OS Communications Server: IP User's Guide and CommandsFTP subcommandsSIte subcommand-Send site-specific information to a host I find: length Specifies the logical record length of a newly allocated data set. The valid range is 0—32760. A special value of x (LRecl=x) is also supported to indicate that a logical record length can exceed 32760 for variable-length spanned records. So apparently FTP supports transfer of RECFM=VBS,LRECL=X. I'll need to try it. And maybe submit an RCF requesting an example. IBM's implementation of FTP is horrendously complicated. Kinda like z/OS data management. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MIPS, CEC, LPARs, PRISM, WLM
I don't see the DIST ADDRESS SPACE going runaway. What is feasible is DDF work - separately WLM classified as it should be - taking a big chunk of CPU. (And that work runs IN the DIST address space but hopefully not at its dispatching priority.) DIST address space itself going rogue would sound like a bug. Lots of things determine whether this would lead to a separate Production LPAR being impacted, most notably whether Prod LPAR is above its share (as determined by weights). With DDF work this could affect either the GCP pool or the zIIP pool. There ARE interactions between WLM and PR/SM but generally not. Such interactions include if IRD Weight Management is active. And I see you already have several other answers - so it looks like you came to the right place. :-) Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: L Hagedorn linda.haged...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 17/12/2014 12:54 Subject:MIPS, CEC, LPARs, PRISM, WLM Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Hi IBM-MAIN, We have a situation with multiple LPARS on a CEC, running DB2 asids prod, test, dev. It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and stealing MIPS from the PROD LPAR and affecting production. Others claim this is not possible due to Prism. Will someone provide an overview of how Prism influences or controls MIPS usage (CPU) across LPARs sharing the same CEC, what are the limiting or controlling factors (if any), and how can the behavior be measured or reported upon so I can explain this with supporting doc? Does WLM play a part in sharing CPU across LPARs? Any information or referrals to doc is appreciated. Thanks, Linda -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IKJ56500I COMMAND OPUTX NOT FOUND
On 2014-12-17, at 09:31, Scott Ford wrote: Yeah but that's only as of z/OS 2.1 ….as a ISV we support backlevel versions also …so one has to come up with two solutions … No, you need to come up with only the solution for the backlevel version, then rely on upward compatibility. (But it may be suboptimal.) It's a design blunder that STDPARM is mutex with EXEC PARM= rather than being appended. If it had been appended the programmer might assign a few variables in the EXEC PARM= using JCL symbol values, then exploit them in the script in STDPARM. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MIPS, CEC, LPARs, PRISM, WLM
You may ask IBM or your Business Partner to do a CP3000 study. This can uncover issues with WLM. On Wed, Dec 17, 2014 at 11:36 AM, Ted MacNEIL eamacn...@yahoo.ca wrote: PR/SM (LPAR) doesn't know PROD from TEST. It only knows weight. If you have set it up for LPAR to have 80% and LPARB to have 20%, that's what they get in times of contention. No more, no less. 20% is one's allotment so it's okay. 85% is above the allotment so it's scaled back to 80%. This is how it's always worked. - -teD - Original Message From: L Hagedorn Sent: Wednesday, December 17, 2014 11:15 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: MIPS, CEC, LPARs, PRISM, WLM Thank you for the extensive information and examples. I will be hitting the books. Can you expand on this example: If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20% and LPARA will be squeezed to 80%. It seems counter intuitive to me and I'd like to understand. Lets say LPARA is prod - they should get most of the resources. Why would LPARA be squeezed instead of LPARB? Sent from my iPhone On Dec 17, 2014, at 9:07 AM, Staller, Allan allan.stal...@kbmg.com wrote: The answer is, it depends. First, there is no priority across LPARS. All LPARS are dispatched equally according to the LPAR weights. For example, if LPARA is weighted are 80 and LPARB is weighted at 20, the following occurs: If LPARA wants 85% and LPARB wants 10% (total 85%) everybody is happy and goes on their merry way. If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20% and LPARA will be squeezed to 80%. If LPARA wants 50% and LPARB wants 40% (total 90%) everybody is happy and goes on their merry way. The LPARA weight represents a guaranteed minimum proportion (note: LPAR weights need not total to 100. The proportion is relative.) All of the above occurs when capping (either hard or soft) is not present. Software capping can occur with resource groups. Hardware capping can occur with group capacity limits. This is a complex subject and much more than can be covered in a short e-mail. If you have not already done so, I suggest you obtain a copy of and read the PR/SM Planning Guide. The most recent version I can find is SB10-7155-01 and is located here: https://www-304.ibm.com/support/docview.wss?uid=isg202e537c11be0929c8525776100663570aid=1 (watch the wrap). RMF Monitor I (batch) has an excellent CPU report. This will also include the PARTITION DATA REPORT. I will refer you to the fine manuals for details/ WLM *may* reach across LPAR Boundaries. If fact, it is designed to do this. However, if the DVLP lpar is not in the same SYSPLEX, WLM cannot be a factor. As others have pointed out, what evidence is there that the runaway task is affecting production (factual, not conjecture!)? HTH, snip We have a situation with multiple LPARS on a CEC, running DB2 asids prod, test, dev. It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and stealing MIPS from the PROD LPAR and affecting production. Others claim this is not possible due to Prism. Will someone provide an overview of how Prism influences or controls MIPS usage (CPU) across LPARs sharing the same CEC, what are the limiting or controlling factors (if any), and how can the behavior be measured or reported upon so I can explain this with supporting doc? Does WLM play a part in sharing CPU across LPARs? /snip -- 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 -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MIPS, CEC, LPARs, PRISM, WLM
Sounds like you also need to familiarise yourself with how DIST works - meaning enclaves that run the actual DDF SQL. As I say, unlikely DIST itself but rather more likely the DDF is in play. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: L Hagedorn linda.haged...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 17/12/2014 16:08 Subject:Re: MIPS, CEC, LPARs, PRISM, WLM Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU MVS Sysprogs reported the situation saying DB2DIST on LPAR A was affecting LPAR B. I didn't ask them for doc, but will next time. This is a runtime issue, unrelated to reported changes. That being said, I'm aware WLM is changed frequently and without broadcast notification. This appears from time to time. I am new here (couple of months) so cannot determine how long its been happening - could be months, could be years. I need to understand the interworkings of prism, WLM, and the LPARs, and from the postings today, more about soft and hard capping. All input is appreciated. I have a learning curve in this area, so telling me to look for something in RMF is welcome, along with any display commands where I can see the caps. I have Mainview. Sent from my iPhone On Dec 17, 2014, at 8:35 AM, Lizette Koehler stars...@mindspring.com wrote: I would ask first, how do you know it is affecting the Prod LPAR. What evidence, RMF Reports, Performance monitors, etc. ? There should be, I think, so data that could explicitly show that is what is happening. Is it all the time, some of the time? Is it a specific time when the prod LPAR is affected? How long has it been going on? Is there a point in time when this started? If so, what changes occurred at that point? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of L Hagedorn Sent: Wednesday, December 17, 2014 5:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: MIPS, CEC, LPARs, PRISM, WLM Hi IBM-MAIN, We have a situation with multiple LPARS on a CEC, running DB2 asids prod, test, dev. It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and stealing MIPS from the PROD LPAR and affecting production. Others claim this is not possible due to Prism. Will someone provide an overview of how Prism influences or controls MIPS usage (CPU) across LPARs sharing the same CEC, what are the limiting or controlling factors (if any), and how can the behavior be measured or reported upon so I can explain this with supporting doc? Does WLM play a part in sharing CPU across LPARs? Any information or referrals to doc is appreciated. Thanks, Linda -- 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 stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MIPS, CEC, LPARs, PRISM, WLM
Sent from my iPhone On Dec 17, 2014, at 8:26 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: Linda Hagedorn wrote: We have a situation with multiple LPARS on a CEC, running DB2 asids prod, test, dev. What z/OS levels? What levels of DB2 on all those LPARS? Z is 2.1. DB2s are V10 Put1308 It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and stealing MIPS from the PROD LPAR and affecting production. Based on what were those claims made? I would like to see for example, RMF or SMF data/reports or some other tools used to prove that claims. Are you having response time problems? Operations is reporting the situation. I can confirm the presence of bad SQL in the dev system, and the operations say things return to normal after its cancelled. Again, I don't have doc to indicate normal, so I'll ask that also. My questions are to understand how LPARA is causing a problem in LPARB. Operations management says this true, but the sysprog says it can't happen. Doc will be requested next time. Any particular advice on what should be asked is appreciated. I'll ask what they see, screen shots, source, etc. Thank you. Linda Others claim this is not possible due to Prism. Will someone provide an overview of how Prism influences or controls MIPS usage (CPU) across LPARs sharing the same CEC, what are the limiting or controlling factors (if any), and how can the behavior be measured or reported upon so I can explain this with supporting doc? Does WLM play a part in sharing CPU across LPARs? Are your LPARS hard or soft capped? What are the CPU and MSU allocations to your LPARS? I don't know. Is there a display command that would show the status and limits? Any information or referrals to doc is appreciated. I'll leave that to the real performance gurus on IBM-MAIN. 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
Suggestion for the ICETOOL SUBSET operator
Using the ICETTOOL SUBSET operator I missed a position subselection option for the FIRST/LAST/RRN parms. I can of course use other DFSORT operators for this purpose, but felt that this possibility would fit well in the SUBSET function. Example: RRN(3,12,(31:22,71:10))or RRN(3,12,31:22,71:10) Here only the parts from position 31, length 22, and position 71, length 10, is selected for the output record. (The record will contain selected parts concatenated from pos 1, length 32.) Padding spec may also be added. Best Regards, Thomas Berg ___ Thomas Berg Specialist zOS/RQM/IT Delivery Swedbank AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MIPS, CEC, LPARs, PRISM, WLM
I lurk on IBM-Main, and I'm always awed by the knowledge here. You are treasure. Sent from my iPhone On Dec 17, 2014, at 10:02 AM, Martin Packer martin_pac...@uk.ibm.com wrote: I don't see the DIST ADDRESS SPACE going runaway. What is feasible is DDF work - separately WLM classified as it should be - taking a big chunk of CPU. (And that work runs IN the DIST address space but hopefully not at its dispatching priority.) DIST address space itself going rogue would sound like a bug. Lots of things determine whether this would lead to a separate Production LPAR being impacted, most notably whether Prod LPAR is above its share (as determined by weights). With DDF work this could affect either the GCP pool or the zIIP pool. There ARE interactions between WLM and PR/SM but generally not. Such interactions include if IRD Weight Management is active. And I see you already have several other answers - so it looks like you came to the right place. :-) Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: L Hagedorn linda.haged...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 17/12/2014 12:54 Subject:MIPS, CEC, LPARs, PRISM, WLM Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Hi IBM-MAIN, We have a situation with multiple LPARS on a CEC, running DB2 asids prod, test, dev. It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and stealing MIPS from the PROD LPAR and affecting production. Others claim this is not possible due to Prism. Will someone provide an overview of how Prism influences or controls MIPS usage (CPU) across LPARs sharing the same CEC, what are the limiting or controlling factors (if any), and how can the behavior be measured or reported upon so I can explain this with supporting doc? Does WLM play a part in sharing CPU across LPARs? Any information or referrals to doc is appreciated. Thanks, Linda -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MIPS, CEC, LPARs, PRISM, WLM
Thank you. Sent from my iPhone On Dec 17, 2014, at 11:36 AM, Ted MacNEIL eamacn...@yahoo.ca wrote: PR/SM (LPAR) doesn't know PROD from TEST. It only knows weight. If you have set it up for LPAR to have 80% and LPARB to have 20%, that's what they get in times of contention. No more, no less. 20% is one's allotment so it's okay. 85% is above the allotment so it's scaled back to 80%. This is how it's always worked. - -teD - Original Message From: L Hagedorn Sent: Wednesday, December 17, 2014 11:15 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: MIPS, CEC, LPARs, PRISM, WLM Thank you for the extensive information and examples. I will be hitting the books. Can you expand on this example: If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20% and LPARA will be squeezed to 80%. It seems counter intuitive to me and I'd like to understand. Lets say LPARA is prod - they should get most of the resources. Why would LPARA be squeezed instead of LPARB? Sent from my iPhone On Dec 17, 2014, at 9:07 AM, Staller, Allan allan.stal...@kbmg.com wrote: The answer is, it depends. First, there is no priority across LPARS. All LPARS are dispatched equally according to the LPAR weights. For example, if LPARA is weighted are 80 and LPARB is weighted at 20, the following occurs: If LPARA wants 85% and LPARB wants 10% (total 85%) everybody is happy and goes on their merry way. If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20% and LPARA will be squeezed to 80%. If LPARA wants 50% and LPARB wants 40% (total 90%) everybody is happy and goes on their merry way. The LPARA weight represents a guaranteed minimum proportion (note: LPAR weights need not total to 100. The proportion is relative.) All of the above occurs when capping (either hard or soft) is not present. Software capping can occur with resource groups. Hardware capping can occur with group capacity limits. This is a complex subject and much more than can be covered in a short e-mail. If you have not already done so, I suggest you obtain a copy of and read the PR/SM Planning Guide. The most recent version I can find is SB10-7155-01 and is located here: https://www-304.ibm.com/support/docview.wss?uid=isg202e537c11be0929c8525776100663570aid=1 (watch the wrap). RMF Monitor I (batch) has an excellent CPU report. This will also include the PARTITION DATA REPORT. I will refer you to the fine manuals for details/ WLM *may* reach across LPAR Boundaries. If fact, it is designed to do this. However, if the DVLP lpar is not in the same SYSPLEX, WLM cannot be a factor. As others have pointed out, what evidence is there that the runaway task is affecting production (factual, not conjecture!)? HTH, snip We have a situation with multiple LPARS on a CEC, running DB2 asids prod, test, dev. It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and stealing MIPS from the PROD LPAR and affecting production. Others claim this is not possible due to Prism. Will someone provide an overview of how Prism influences or controls MIPS usage (CPU) across LPARs sharing the same CEC, what are the limiting or controlling factors (if any), and how can the behavior be measured or reported upon so I can explain this with supporting doc? Does WLM play a part in sharing CPU across LPARs? /snip -- 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: ftp rdw
On Wed, 17 Dec 2014 10:33:18 -0600, Paul Gilmartin wrote: On Wed, 17 Dec 2014 07:55:03 -0600, Kirk Wolf wrote: z/OS Communications Server: IP User's Guide and Commands SC27-3662-00 http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.halu001/site.htm z/OS V2R1z/OS Communications Serverz/OS Communications Server: IP User's Guide and CommandsFTP subcommandsSIte subcommand-Send site-specific information to a host I find: length Specifies the logical record length of a newly allocated data set. The valid range is 0—32760. A special value of x (LRecl=x) is also supported to indicate that a logical record length can exceed 32760 for variable-length spanned records. So apparently FTP supports transfer of RECFM=VBS,LRECL=X. I'll need to try it. And maybe submit an RCF requesting an example. OK. I tried it: put unloaded unld3 SITE VARrecfm LRECL=6016 RECFM=VS BLKSIZE=6020 200 SITE command was accepted PORT 10,80,63,53,166,91 200 Port request OK. STOR unld3 125 Storing data set User.TEMP.UNLD3 250 Transfer completed successfully. 332072 bytes transferred in 0.040 seconds. Transfer rate 8301.80 Kbytes/sec. Command: get unld3 unld4 PORT 10,80,63,53,166,92 200 Port request OK. RETR unld3 125 Sending data set User.TEMP.UNLD3 250 Transfer completed successfully. 331947 bytes transferred in 0.040 seconds. Transfer rate 8298.67 Kbytes/sec. Data was truncated. Command: PUT works better than get, probably because of SENDSITE. Is there a reverse SENDSITE? Something that would extract the characteristics of a file and issue a LOCSITE? (I could copy and paste into LOCSITE. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MIPS, CEC, LPARs, PRISM, WLM
Any LPAR can exceed their proportion if there is available resource. If there is insufficient resource, LPARS will be forced to their proportion, as defined by the LPAR weights (unless another LPAR is not consuming its share). Remember, PR/SM does not know LPARA is production and should be favored. It just knows LPARA is assigned weight x. For example there is CEC with LPARS(weights) LPARA(60%) LPARB(20%) and LPARC(20%). If all LPARS demand their weight, the CPU will be distributed according to the weights defined (barring soft/hard capping). Now, assume LPARC only wants 5%. LPARA and LPARB can now consume the 15% that LPARC does not want. In the example from my previous post, the total demand is 105%. LPARB has a defined weight of 20% and is guaranteed this value. LPARA is guaranteed its weight of 80%. (total of 100). The additional 5% exceeds the available capacity and will be presented as latent demand. IF LPARB were to drop to only requiring 10%, LPAR would then be allowed to exceed the defined proportion because the total demand is now 90%. There are man7y tricks of the trade to cap the non-production LPARs. The only question is the granularity appropriate. Another good source would be the CMG archives (www.cmg.org) and Cheryl Watsons Tuning Letters. Hopefully, Cheryl will spot this thread and chime in. HTH, snip Can you expand on this example: If LPARA wants 85% and LPARB want 20% (total 105%) LPARB will get 20% and LPARA will be squeezed to 80%. It seems counter intuitive to me and I'd like to understand. Lets say LPARA is prod - they should get most of the resources. Why would LPARA be squeezed instead of LPARB? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MIPS, CEC, LPARs, PRISM, WLM
How is the dasd handled? Is it separate between Prd and other LPARs? Or do you share your dasd. In other words any LPAR can see any dasd for any other LPAR or is it PRD dasd is only on prd and not accessible by the other LPARS? How does Operation identify the issue? Are they looking at an alert? Or a Monitor (Tivoli Omegamon, other?) How is the network during this time? Is connectivity optimal or slowed down? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of L Hagedorn Sent: Wednesday, December 17, 2014 9:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: MIPS, CEC, LPARs, PRISM, WLM MVS Sysprogs reported the situation saying DB2DIST on LPAR A was affecting LPAR B. I didn't ask them for doc, but will next time. This is a runtime issue, unrelated to reported changes. That being said, I'm aware WLM is changed frequently and without broadcast notification. This appears from time to time. I am new here (couple of months) so cannot determine how long its been happening - could be months, could be years. I need to understand the interworkings of prism, WLM, and the LPARs, and from the postings today, more about soft and hard capping. All input is appreciated. I have a learning curve in this area, so telling me to look for something in RMF is welcome, along with any display commands where I can see the caps. I have Mainview. Sent from my iPhone On Dec 17, 2014, at 8:35 AM, Lizette Koehler stars...@mindspring.com wrote: I would ask first, how do you know it is affecting the Prod LPAR. What evidence, RMF Reports, Performance monitors, etc. ? There should be, I think, so data that could explicitly show that is what is happening. Is it all the time, some of the time? Is it a specific time when the prod LPAR is affected? How long has it been going on? Is there a point in time when this started? If so, what changes occurred at that point? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of L Hagedorn Sent: Wednesday, December 17, 2014 5:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: MIPS, CEC, LPARs, PRISM, WLM Hi IBM-MAIN, We have a situation with multiple LPARS on a CEC, running DB2 asids prod, test, dev. It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and stealing MIPS from the PROD LPAR and affecting production. Others claim this is not possible due to Prism. Will someone provide an overview of how Prism influences or controls MIPS usage (CPU) across LPARs sharing the same CEC, what are the limiting or controlling factors (if any), and how can the behavior be measured or reported upon so I can explain this with supporting doc? Does WLM play a part in sharing CPU across LPARs? Any information or referrals to doc is appreciated. Thanks, Linda -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IKJ56500I COMMAND OPUTX NOT FOUND
Gil: That was what I was trying to say and didn't do it very well. Love the new JCL changes is Z/OS 2.1 Scott From: Paul Gilmartin Sent: Wednesday, December 17, 2014 11:43 AM To: IBM-MAIN@LISTSERV.UA.EDU On 2014-12-17, at 09:31, Scott Ford wrote: Yeah but that's only as of z/OS 2.1 ….as a ISV we support backlevel versions also …so one has to come up with two solutions … No, you need to come up with only the solution for the backlevel version, then rely on upward compatibility. (But it may be suboptimal.) It's a design blunder that STDPARM is mutex with EXEC PARM= rather than being appended. If it had been appended the programmer might assign a few variables in the EXEC PARM= using JCL symbol values, then exploit them in the script in STDPARM. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IKJ56500I COMMAND OPUTX NOT FOUND
Fortunately this particular problem is internal use only and so V2R1-only is a minor issue only. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Wednesday, December 17, 2014 8:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IKJ56500I COMMAND OPUTX NOT FOUND Yeah but that's only as of z/OS 2.1 ….as a ISV we support backlevel versions also …so one has to come up with two solutions … ith 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: PROGxx vs LNKLSTxx, and APF FORMAT(DYNAMIC)
we've run into health checks that are not compatible with what we believe are reasonable settings Whenever any HC creator interacts with the HC team it is always suggested to them that they provide a parameter by which the customer can indicate the value to check for, because even though something might be recommended it might not meet the business needs of some customers, and those customers want a way to indicate check for the state I need, to help make sure that no one accidentally changes it even to the state that would normally be recommended. For those sort of cases, we really want customers to tune the check, not deactivate/delete it. For example, the GRS mode check can be tuned to check for STAR or RING. If the checks that you refer to do not have such parameterization, requesting it would be a great first step. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MIPS, CEC, LPARs, PRISM, WLM
Craig Mullin's DB/2 books are really educational in scope and insight(and heavy). Fundamental understanding of the interoperation is key to identifying and tuning problems. He was with Platinum when he first began the series and moved on after the acquisition by CA.(He and other vendors were presenting at our ADUG conference on 9/11/01. Haven't seen him since but still get the updates.) The CA tools are really good at pinpointing problems. Detector and Log Analyzer are key. For SQL there's the SQL analyzer(priced) component. Sometimes if it's third party software there may be a known issues with certain transactions or areas of interactions. For continual knowledge _www.share.org_ (http://www.share.org) is a good source. Developers and installations give current and timely advice on fitting metrics to machines. The proceedings for the last three Events are kept online without signup. The new RMF stuff for EC12 and Flash drives is pretty awesome. In a message dated 12/17/2014 11:00:20 A.M. Central Standard Time, linda.haged...@gmail.com writes: I lurk on IBM-Main, and I'm always awed by the knowledge here. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MIPS, CEC, LPARs, PRISM, WLM
In pretty good with DB2, and Craig is wonderful. It's the intricacies of MVS performance I need to bring in focus. I have a lot of reading and research to do so I can collect appropriate doc the next time one of these hits. Linda Sent from my iPhone On Dec 17, 2014, at 2:34 PM, Ed Finnell 000248cce9f3-dmarc-requ...@listserv.ua.edu wrote: Craig Mullin's DB/2 books are really educational in scope and insight(and heavy). Fundamental understanding of the interoperation is key to identifying and tuning problems. He was with Platinum when he first began the series and moved on after the acquisition by CA.(He and other vendors were presenting at our ADUG conference on 9/11/01. Haven't seen him since but still get the updates.) The CA tools are really good at pinpointing problems. Detector and Log Analyzer are key. For SQL there's the SQL analyzer(priced) component. Sometimes if it's third party software there may be a known issues with certain transactions or areas of interactions. For continual knowledge _www.share.org_ (http://www.share.org) is a good source. Developers and installations give current and timely advice on fitting metrics to machines. The proceedings for the last three Events are kept online without signup. The new RMF stuff for EC12 and Flash drives is pretty awesome. In a message dated 12/17/2014 11:00:20 A.M. Central Standard Time, linda.haged...@gmail.com writes: I lurk on IBM-Main, and I'm always awed by the knowledge here. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MIPS, CEC, LPARs, PRISM, WLM
Sent from my iPhone On Dec 17, 2014, at 12:38 PM, Lizette Koehler stars...@mindspring.com wrote: How is the dasd handled? Is it separate between Prd and other LPARs? Or do you share your dasd. Dasd is shared. In other words any LPAR can see any dasd for any other LPAR or is it PRD dasd is only on prd and not accessible by the other LPARS? Its all shared. How does Operation identify the issue? Are they looking at an alert? Or a Monitor (Tivoli Omegamon, other?) That's one of the outstanding questions. How is the network during this time? Is connectivity optimal or slowed down? Operations is adept at monitoring. They do not identify any network issues. I'll ask them specifically next time. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of L Hagedorn Sent: Wednesday, December 17, 2014 9:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: MIPS, CEC, LPARs, PRISM, WLM MVS Sysprogs reported the situation saying DB2DIST on LPAR A was affecting LPAR B. I didn't ask them for doc, but will next time. This is a runtime issue, unrelated to reported changes. That being said, I'm aware WLM is changed frequently and without broadcast notification. This appears from time to time. I am new here (couple of months) so cannot determine how long its been happening - could be months, could be years. I need to understand the interworkings of prism, WLM, and the LPARs, and from the postings today, more about soft and hard capping. All input is appreciated. I have a learning curve in this area, so telling me to look for something in RMF is welcome, along with any display commands where I can see the caps. I have Mainview. Sent from my iPhone On Dec 17, 2014, at 8:35 AM, Lizette Koehler stars...@mindspring.com wrote: I would ask first, how do you know it is affecting the Prod LPAR. What evidence, RMF Reports, Performance monitors, etc. ? There should be, I think, so data that could explicitly show that is what is happening. Is it all the time, some of the time? Is it a specific time when the prod LPAR is affected? How long has it been going on? Is there a point in time when this started? If so, what changes occurred at that point? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of L Hagedorn Sent: Wednesday, December 17, 2014 5:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: MIPS, CEC, LPARs, PRISM, WLM Hi IBM-MAIN, We have a situation with multiple LPARS on a CEC, running DB2 asids prod, test, dev. It is claimed a runaway DB2 DIST asid on the DVLP LPAR is burning CPU and stealing MIPS from the PROD LPAR and affecting production. Others claim this is not possible due to Prism. Will someone provide an overview of how Prism influences or controls MIPS usage (CPU) across LPARs sharing the same CEC, what are the limiting or controlling factors (if any), and how can the behavior be measured or reported upon so I can explain this with supporting doc? Does WLM play a part in sharing CPU across LPARs? Any information or referrals to doc is appreciated. Thanks, Linda -- 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: Trouble with IARV64 GETCOMMON
The default setting for IARV64 FPROT is YES meaning that the program accessing the storage must have a PSW key that matches the storage key of the memobj (or PSW key 0). I believe that IPCS storage browse ACTIVE runs in problem state and key8 - therefore you will not see the storage. If you want all address spaces to see your common memobj, try using FPROT=NO on the IARV64 macro. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- I issue the following macro: IARV64 REQUEST=GETCOMMON, COND=YES, SEGMENTS=SBS01, === Value is 1. MOTKNSOURCE=SYSTEM,OUTMOTKN=SBITKN, TYPE=PAGEABLE, OWNERCOM=SYSTEM, ORIGIN=SBILOC, DUMP=LIKECSA, RSNCODE=SBIRSN I display the address obtained. When I look at this address in IPCS looking at the ACTIVE address space, I do not see my storage. When I take a dump of my address space, I see my storage. What am I doing wrong? Active Storage Processing z/OS MVS IPCS User's Guide SA23-1384-00 IPCS can process as a dump the central storage for the address space in which IPCS is currently running, private storage, and any common storage accessible by an unauthorized problem state program. Users running z/OS® R2 IPCS on a z/OS R2 system who have been authorized READ access to facility class resource BLSACTV.ADDRSPAC may view storage that is fetch-protected from application code. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
FRR Parameter Area too small
I have a problem in that the FRR Parameter Area (24 bytes) returned in SETFRR A,PARMAD= is too small! I am having to re-work some code to support 64-bit (and prior 31-bit) callers in SRB mode and am curious what others do in this situation. The 24 byte FRR Parameter area used to hold 6 registers but now only 3 for 64-bit support. The thought of getting storage and later freeing it seems expensive, just to have an Extended FRR Parameter Area. FRR STACK size is fairly small, so not sure if getting 2 areas (2 SETFRR requests) and chaining them is likely to run out and lead to disaster. Also probably frowned upon, i.e. it is both ugly and asking for problems, especially if there is recursion (occasionally can happen). Anyone else hit this? And what have you done to get around it? Thanks, John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
JCLLIB in started proc?
I just added a JCLLIB statement to a cataloged procedure that I start with a Start command. I am getting IEFC019I MISPLACED JCLLIB STATEMENT. Should I infer that JCLLIB is not allowed in a started PROC, or should I be looking for a fat-finger coding error? (I want the JCLLIB for INCLUDE, not EXEC PROC=.) I RTFM but don't see anything explicit. It does refer to in a job at several points. Is JCLLIB allowed in a started PROC if the PROC has a JOB statement? I know I can do that but I've never done it. Where is that documented? Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCLLIB in started proc?
I use something like this in the STCJOBS dataset that's allocated in MSTJCL00. //MYSTC JOB // JCLLIB ORDER=(TECHSVC.PROCLIB) //MYSTC EXEC MYSTC Mark Jacobs Charles Mills wrote: I just added a JCLLIB statement to a cataloged procedure that I start with a Start command. I am getting IEFC019I MISPLACED JCLLIB STATEMENT. Should I infer that JCLLIB is not allowed in a started PROC, or should I be looking for a fat-finger coding error? (I want the JCLLIB for INCLUDE, not EXEC PROC=.) I RTFM but don't see anything explicit. It does refer to in a job at several points. Is JCLLIB allowed in a started PROC if the PROC has a JOB statement? I know I can do that but I've never done it. Where is that documented? Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCLLIB in started proc?
Charles, Can we see you job stream ? Scott ford www.identityforge.com from my IPAD On Dec 17, 2014, at 8:05 PM, Charles Mills charl...@mcn.org wrote: I just added a JCLLIB statement to a cataloged procedure that I start with a Start command. I am getting IEFC019I MISPLACED JCLLIB STATEMENT. Should I infer that JCLLIB is not allowed in a started PROC, or should I be looking for a fat-finger coding error? (I want the JCLLIB for INCLUDE, not EXEC PROC=.) I RTFM but don't see anything explicit. It does refer to in a job at several points. Is JCLLIB allowed in a started PROC if the PROC has a JOB statement? I know I can do that but I've never done it. Where is that documented? Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCLLIB in started proc?
I added a JOB statement and now I get an error on that also: IEFC019I MISPLACED JOB STATEMENT The documentation seems to me to be contradictory. In the JCL Reference: A cataloged procedure may consist of these JCL statements: CNTL, command, DD, ENDCNTL, EXEC, IF/THEN/ELSE/ENDIF, INCLUDE, OUTPUT JCL, and SET. Optionally, a cataloged procedure can begin with a PROC statement and end with a PEND statement. If coded, PROC must be the first statement in the procedure. -- No JOB in there. In System Commands under Start: The job name for a given started task can be assigned based on a variety of inputs. ... 2. The job name specified on the JOB JCL statement within the member. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Jacobs Sent: Wednesday, December 17, 2014 5:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCLLIB in started proc? I use something like this in the STCJOBS dataset that's allocated in MSTJCL00. //MYSTC JOB // JCLLIB ORDER=(TECHSVC.PROCLIB) //MYSTC EXEC MYSTC Mark Jacobs Charles Mills wrote: I just added a JCLLIB statement to a cataloged procedure that I start with a Start command. I am getting IEFC019I MISPLACED JCLLIB STATEMENT. Should I infer that JCLLIB is not allowed in a started PROC, or should I be looking for a fat-finger coding error? (I want the JCLLIB for INCLUDE, not EXEC PROC=.) I RTFM but don't see anything explicit. It does refer to in a job at several points. Is JCLLIB allowed in a started PROC if the PROC has a JOB statement? I know I can do that but I've never done it. Where is that documented? Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FRR Parameter Area too small
I have a problem in that the FRR Parameter Area (24 bytes) returned in SETFRR A,PARMAD= is too small! I am having to re-work some code to support 64-bit (and prior 31- bit) callers in SRB mode and am curious what others do in this situation. The 24 byte FRR Parameter area used to hold 6 registers but now only 3 for 64-bit support. The thought of getting storage and later freeing it seems expensive, just to have an Extended FRR Parameter Area. FRR STACK size is fairly small, so not sure if getting 2 areas (2 SETFRR requests) and chaining them is likely to run out and lead to disaster. Also probably frowned upon, i.e. it is both ugly and asking for problems, especially if there is recursion (occasionally can happen). The FRR stack is limited to 32 entries, so unless you are in control of how many entries are on the stack when you are invoked, and how many entries are used by things that you invoke, it may be inadvisable to use SETFRR as a method for acquiring a small amount of storage. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCLLIB in started proc?
Here's the first few lines -- includes all of the error lines. FMID is or would be set if the INCLUDE worked. //USERIDAX JOB ,' Test Job',MSGCLASS=A,NOTIFY=SYSUID,CLASS=A //* //* Pick up correct load libarary //JCLLIB ORDER=USERID.COMPANY.CNTL //INCLUDE MEMBER=SETPACKG //* //MYTEST PROC RUNMODE=,INSTALL=,VERBOSE=,TRACE=, // INSTANCE=1, // LOADLIB=USERID.FMID..LOADPDSE Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Wednesday, December 17, 2014 5:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JCLLIB in started proc? Charles, Can we see you job stream ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Utility to replace occurrences of string in PDS?
PDS or STARTOOL Usage The PDS package (free from CBT file 182) and Serena's STARTOOL product were mentioned earlier. Here's a note about their syntax. The TSO command PDS pdsname REPL : !stringA!stringB! WRITE is all you need. As a TSO command it is easy to put in a batch job. [Use the STARTOOL command instead of PDS if you have the Serena product.] The ! character is a delimiter. It can be any character that is not in either of the strings. People often use / as the delimiter, but avoid / if using it as a line command in ISPF option 3.4 since / of course substitutes to the dataset name in the ISPF 3.4 dataset list. Omit the WRITE keyword to get a simulated replacement run without any actual updates. PDS pdsname FIND : !stringA! is the command to do a FIND across the PDS (useful prior to REPLacement). Interactively you can use the PDS pdsname TSO command to get into PDS (or STARTOOL) and then use the REPL or FIND subcommands from there. From within ISPF you get nice panels showing the member list. From true READY mode you get the TSO line mode experience. The colon character : specifies ALL members. You can instead specify a subset of members such as ABC:DEF (all members beginning with ABC through to those beginning with DEF) or throw some * wildcards into the mix. Edit Macro Across All Members Edit Macros were also mentioned earlier in the thread as an alternative. Consider the ISPF sample edit macro ISRMBRS which is both documented and shipped with ISPF. Mainly for interactive use. If you edit a non-existent member in your PDS, for example TEMPXYZ, and then invoke the edit macro as ISRMBRS MYMACRO then your edit macro MYMACRO will be applied to every member (except the member you are editing from). However, make sure your edit macro has the ISPF 'END' command in it, or you will be pressing PF3 for every member. Hope that helps, dap -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ftp rdw
On Tue, 16 Dec 2014 09:46:30 -0600, John McKown wrote: STRU F / SITE RDW - usable. Each VBS segment read separately and correctly. The code on the PC must reassemble segmented records. Where'd you get a VBS file to test? Did you make one? I'm testing with an IEBCOPY PDSU; RECFM=VS. I'd like to experiment with one that is actually Blocked (multiple segments in a block) and Spanned (multiple segments per logical record). I find that with BINARY; TYPE E; MODE B; I can FTP PUT my VB file intact. The SENDSITE helps a lot. And I can FTP GET it with the same options *provided* I first copy the SENDSITE echoed on the PUT and issue it as a LOCSITE command. I believe (but where's my PoC?) that I could synthesize on a desktop, non-z, non MVS/380 system a binary file that I could PUT and reconstruct a RECFM=VB data set (with either STRU R or TYPE E, MODE B) or RECFM=VBS (only with TYPE E, mode B). But the OP seems more intent on whining about the failure of the technique he's fixated on than switching to an effective technique. It's more complex than he'd like, but things are tough all over. SMoP. And he wants to be able to read the envelope file on a PC, but he hasn't mentioned the EBCDIC--ASCII problem. Perhaps it's considered a given; SMoP again. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ftp rdw
And he wants to be able to read the envelope file on a PC, but he hasn't mentioned the EBCDIC--ASCII problem. Perhaps it's considered a given; SMoP again. That's fine. It's well-defined that the binary file is in EBCDIC, uses big-endian 4-byte integers etc. Thus any EBCDIC text will be run through this code: http://mvs380.cvs.sourceforge.net/viewvc/mvs380/mvssrc/ozpd/c/febc.c?view=markup in order to be portable. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ftp rdw
Thanks for the pointer Kirk. I have submitted it: https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfeCR_ID=63596 BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MIPS, CEC, LPARs, PRISM, WLM
On 17 Dec 2014 14:13:46 -0800, in bit.listserv.ibm-main you wrote: In pretty good with DB2, and Craig is wonderful. It's the intricacies of MVS performance I need to bring in focus. I have a lot of reading and research to do so I can collect appropriate doc the next time one of these hits. After reading most of this thread, two things hit this retired systems programmer. The first is that with all DASD shared, runaway bad SQL may be doing a number on your disk performance due to contention and I would look at I-O on both production and test. DB2 and other experts who are more familiar with current DASD technology and contention can give more help. The other is the role played on both LPARs by the use of zAAP and zIIP processors which run at full speed and reduced cost for selected work loads. The bad SQL may be eligible to run on those processors and taking away the availability from production. This is just a guess based on a dangerous (inadequate) amount of knowledge. Clark Morris Linda Sent from my iPhone On Dec 17, 2014, at 2:34 PM, Ed Finnell 000248cce9f3-dmarc-requ...@listserv.ua.edu wrote: Craig Mullin's DB/2 books are really educational in scope and insight(and heavy). Fundamental understanding of the interoperation is key to identifying and tuning problems. He was with Platinum when he first began the series and moved on after the acquisition by CA.(He and other vendors were presenting at our ADUG conference on 9/11/01. Haven't seen him since but still get the updates.) The CA tools are really good at pinpointing problems. Detector and Log Analyzer are key. For SQL there's the SQL analyzer(priced) component. Sometimes if it's third party software there may be a known issues with certain transactions or areas of interactions. For continual knowledge _www.share.org_ (http://www.share.org) is a good source. Developers and installations give current and timely advice on fitting metrics to machines. The proceedings for the last three Events are kept online without signup. The new RMF stuff for EC12 and Flash drives is pretty awesome. In a message dated 12/17/2014 11:00:20 A.M. Central Standard Time, linda.haged...@gmail.com writes: I lurk on IBM-Main, and I'm always awed by the knowledge here. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Fwd: FC0994 authServer: secure_socket_init failed with rc = 428 (Key entry does not contain a private key)
-- Forwarded message -- From: John Mattson johnmattson...@gmail.com Date: Wed, Dec 17, 2014 at 5:41 PM Subject: FC0994 authServer: secure_socket_init failed with rc = 428 (Key entry does not contain a private key) To: RACF Discussion List rac...@listserv.uga.edu, ibm-m...@listserve.ua.edu Cross post RACF-L and IBM-MAIN Getting the error trying to do TLS FTP from zOS 1.11 to a Unix server. Hoping someone has seen this before. FC0994 authServer: secure_socket_init failed with rc = 428 (Key entry does not contain a private key) I have checked and re-checked that our SelfSigned cert is the private one, and that we have the vendors CERTAUTH and SITE certs in place. I did find an old entry from Hal Merritt back in 2009, but no resolution. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCLLIB in started proc?
I did a quick internet search usingibm stc jcl with jobcard I found this Job Cards for Started Tasks Sometime around MVS/ESA V5.1, IBM introduced job card support for started tasks. To use this feature, the started task JCL must reside in a dataset specified in either the IEFJOBS or IEFPDSI DD statements of the master scheduler JCL (MSTJCLxx PARMLIB member). Refer to MVS Initialization and Tuning Reference for some suggestions on how to set this up. For the purpose of the following examples, I will presume that a separate IEFJOBS dataset has been allocated. Adding Accounting Information A typical member in IEFJOBS could look like this: //JES2 JOB (8022,BX00) JOB CARD SUPPORT //IEFPROC EXEC JES2 The JCL for JES2 will be picked up from the IEFPDSI concatenation. The resulting started task JCL could look something like: //JES2 JOB (8022,BX00), // MSGLEVEL=1 //IEFPROC EXEC JES2 At this point, we have added some accounting information to the started task. Additional Features Now, you are able to add other features to the started task JCL. For instance, say you wished to change the output characteristics for the started task. You could do something like this: //INIT JOB (8024,BX00) JOB CARD SUPPORT //DFLT OUTPUT JESDS=ALL,CLASS=Z //IEFPROC EXEC INIT So this started task can have a different sysout class than others. Another new capability is getting the started task JCL from somewhere else: //TAPEINI JOB (8100,BX01) JOB CARD SUPPORT //STCJCL JCLLIB ORDER=(TAPELIB.STCJCL) //TPINIT EXEC TAPEINI The JCL for TAPEINI will be picked up from TAPELIB.STCJCL. Notes If you specify the PARM option on the MVS START command; for example, S JES2,PARM='WARM,NOREQ' the specified PARM value will not be used if you are using job cards. An alternative method of accomplishing the same result, is to set up a symbolic parameter PRM in the PROC for JES2 which will be substituted into the PARM value of the EXEC statement and use the command S JES2,PRM='WARM,NOREQ' instead. Your JES2 PROC (in IEFPDSI) would look like: //JES2 PROC PRM='WARM,NOREQ' //IEFPROC EXEC PGM=HASJES20,PARM='PRM', . etc If a job card member is not present in the IEFJOBS dataset, then the started task JCL will be built and work as before. I have only scratched the surface on this subject. Refer to the chapter on Started Tasks in MVS JCL Reference for more information. Go to the links page to find OS/390 books on the Web. Check what libraries are in your MSTJCLxx member in SYS1.PARMLIB Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Wednesday, December 17, 2014 6:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JCLLIB in started proc? I just added a JCLLIB statement to a cataloged procedure that I start with a Start command. I am getting IEFC019I MISPLACED JCLLIB STATEMENT. Should I infer that JCLLIB is not allowed in a started PROC, or should I be looking for a fat- finger coding error? (I want the JCLLIB for INCLUDE, not EXEC PROC=.) I RTFM but don't see anything explicit. It does refer to in a job at several points. Is JCLLIB allowed in a started PROC if the PROC has a JOB statement? I know I can do that but I've never done it. Where is that documented? Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MIPS, CEC, LPARs, PRISM, WLM
The bad SQL is usually tablespace scans, and/or Cartesian product. They are relatively easy to identify and cancel. MVS reports the stress in prod, the high CPU use on the dev lpar, and I find the misbehaving thread and cancel it. Mvs reports things then return to normal. The perplexing part is the bad SQL running on LPARA is affecting its own lpar and the major lpar on the CEC. It's own lpar I can understand, but the other one too? The prefetches - dynamic, list, and sequential are ziip eligible in DB2 V10, so the comment about the bad SQL taking the ziips from prod is possible. I'm adding that to my list as something to check. The I/o comment is interesting. I'll add it to my list to watch for also. I'm hitting the books tonight. Thanks for all the ideas and references. Sent from my iPad On Dec 17, 2014, at 9:48 PM, Clark Morris cfmpub...@ns.sympatico.ca wrote: On 17 Dec 2014 14:13:46 -0800, in bit.listserv.ibm-main you wrote: In pretty good with DB2, and Craig is wonderful. It's the intricacies of MVS performance I need to bring in focus. I have a lot of reading and research to do so I can collect appropriate doc the next time one of these hits. After reading most of this thread, two things hit this retired systems programmer. The first is that with all DASD shared, runaway bad SQL may be doing a number on your disk performance due to contention and I would look at I-O on both production and test. DB2 and other experts who are more familiar with current DASD technology and contention can give more help. The other is the role played on both LPARs by the use of zAAP and zIIP processors which run hecat full speed and reduced cost for selected work loads. The bad SQL may be eligible to run on those processors and taking away the availability from production. This is just a guess based on a dangerous (inadequate) amount of knowledge. Clark Morris Linda Sent from my iPhone On Dec 17, 2014, at 2:34 PM, Ed Finnell 000248cce9f3-dmarc-requ...@listserv.ua.edu wrote: Craig Mullin's DB/2 books are really educational in scope and insight(and heavy). Fundamental understanding of the interoperation is key to identifying and tuning problems. He was with Platinum when he first began the series and moved on after the acquisition by CA.(He and other vendors were presenting at our ADUG conference on 9/11/01. Haven't seen him since but still get the updates.) The CA tools are really good at pinpointing problems. Detector and Log Analyzer are key. For SQL there's the SQL analyzer(priced) component. Sometimes if it's third party software there may be a known issues with certain transactions or areas of interactions. For continual knowledge _www.share.org_ (http://www.share.org) is a good source. Developers and installations give current and timely advice on fitting metrics to machines. The proceedings for the last three Events are kept online without signup. The new RMF stuff for EC12 and Flash drives is pretty awesome. In a message dated 12/17/2014 11:00:20 A.M. Central Standard Time, linda.haged...@gmail.com writes: I lurk on IBM-Main, and I'm always awed by the knowledge here. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: IKJ56500I COMMAND OPUTX NOT FOUND
Yeah but that's only as of z/OS 2.1 ?.as a ISV we support backlevel versions also ?so one has to come up with two solutions ? If you need the symbol substitution, then yes, this requires z/OS V2.1. The STDPARM has been there at least in V1.13. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: publibz-infocenter-knowledgecenter
What's a quick link to this week's z/OS v2r1 software shelflist? Bring back LOOKAT! ...and bring back BookMaster and BookServer as well. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FRR Parameter Area too small
On Wed, 17 Dec 2014 17:56:38 -0600 John Sullivan john_sulli...@bmc.com wrote: :I have a problem in that the FRR Parameter Area (24 bytes) returned in SETFRR A,PARMAD= is too small! :I am having to re-work some code to support 64-bit (and prior 31-bit) callers in SRB mode and am curious what others do in this situation. :The 24 byte FRR Parameter area used to hold 6 registers but now only 3 for 64-bit support. :The thought of getting storage and later freeing it seems expensive, just to have an Extended FRR Parameter Area. :FRR STACK size is fairly small, so not sure if getting 2 areas (2 SETFRR requests) and chaining them is likely to run out and lead to disaster. :Also probably frowned upon, i.e. it is both ugly and asking for problems, especially if there is recursion (occasionally can happen). :Anyone else hit this? :And what have you done to get around it? I am sure that most have found even the 24 bytes to be insufficient in most cases and thus save a pointer to the real recovery stuff. I guess you were lucky to only require 24 bytes. You must certainly hate PC-ARRs, where you only have eight bytes of data to save for the recovery routine. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
