Re: Running with SQA/ESQA 100% CHECK
Kees, About your answer above: why do you check a single PGDS utilization? I think it hardly hirts when one PGDS is over some limit if the total configuration is within limit? ... Besides that, the question is what we can do about it, as Barbara already mentioned. thanks for basically asking the same questions I have asked in the ETR I had opened. I was given to understand (not as clearly, of course) that I have no idea what I am talking about. And why do I even question IBMs best practises? As this has happened for *every* HC ETR I have ever opened (and also for quite a few emails that I had exchanged in hopes of improving the product) I have resolved to not bother anymore. If I cannot make a check fit, I just delete it. We have a line in every checklist that says 'get HC to shut up'. And we installed the downloadable version before we migrated to 1.6, so we've been putting up with HC for a long time. The only reason we still start the STC is that *very few* checks actually do make sense, the RACF_sensitive_resources being among them. Another is the RSM MAXCADS check, as this is the only way to actually see how many CADS are in use short of taking a dump. (It may be that showmvs also reports on this.) To me it appears that IBM is promoting the health checker as a way to prevent customers from using the variety of options that z/OS supports (just to make life for the support groups easier). To that effect, every component gets beaten to write a 'health check'. Hence some duplicate checks, some extremely poor documentation, some checks that I consider plain stupid, and a lot that appear to be written hastily (we call that unloved in German-lieblos) and not thought out. If you don't distort your installation to follow those so-called 'best practises', IBM will basically tell you that you're on your own, and if you don't do it, it's your own fault if you have problems. I still consider the *idea* of looking at best practises very valid and very good, but not how HC implements it, and not what I consider IBMs closedmindedness about the product and its checks. My 2 cents, and I'll stop now. Regards, Barbara -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
Mike Feeley [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... I'm thinking of changing PLPA to the minimum size of 1 cylinder and letting it overflow into the COMMON page dataset. Is there any issues with allocating a huge COMMON page dataset? For example, if my LPAR only requires a combined PLPA and COMMON size of 800 cylinders, can I used an entire 3390- 3 for the new PLPA (1 cylinder) and COMMON (the rest of the volume, around 3337 cylinders)? Any issues with the large number of page slots, memory usage, etc. This is for z/OS 1.8 on a z9 box. Nothing else will use this volume. It will either be 100% utilized with PAGE datasets or 100% utulized with PAGE datasets plus a placeholder (filler) dataset. I don't know why I can't just create a huge COMMON page dataset and be done with it versus creating a 700 cylinder COMMON this year and maybe then a 800 cylinder COMMON in 2 more years, etc. Just create the one huge COMMON page dataset and I will be set well into retirement. What are the downfalls from doing something like this? Mike, There are a couple of things to consider: The ancient advantage of a 1 cyl PLPA and a large COMMON, the Seldom Ending Channelprogram, has been retired a couple of z/OS releases ago, so that one has gone. However, a new feature has come into play: PAV. ASM will request 2 alias UCBs for every pagedataset on a volume, so a fullsize PLPA and a fullsized COMMON will give you 3 paths to each of them. But, if your system, like most modern systems, does not do much paging anymore and especially not on PLPA and COMMON, this advantage has little weight. So, yes, if you want to design a PLPA/COMMON configuration that is to last till your retirement, a 1 cyl PLPA and a huge COMMON will probably be the best. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
BTS-problem w COOL:gen et al.
I have a problem with BTS (Batch Terminal Simulator) and the product COOL:gen. (I have asked at the IMS-L list and got answers but no solution.) Prolog: I'm running BTS in batch mode (DLI) under TSO. (Using IBM:s Debug Tool I have two VTAM-windows open through PCOM.) I'm essentially trying to get a working (in production) transaction/program to run under BTS. The program in question is a COOL:gen(tm) generated program and the code is rather convoluted with the IMS calls hidden in COOL's (static) runtime modules. Problem: The problem is that it dies after initial screen/MFS display, probably as BTS thinks it has finished directly after the initial GU IOPCB although the program *still runs* ! A working example that I am running in the same test setup (and same TSO session etc.): BTS0007I BTS V3R1 SIMULATION STARTED. TIME=15:42:49, DATE=2007.253, IMS=V9R1. ./D LTERM=IOPCB TYPE=3270-A02 SIZE=(24,80) FORMBUF=16000 TPBUF=16000 ./E SSID=DB2T ./O DB=Y TSODB=Y MSG=Y TSOMSG=P SQL=Y TSOSQL=Y X SQLHX=Y TSOSQLHX=Y MQI=A TSOMQI=Y IFI=Y TSOIFI=Y ./T TC=XXX300 MBR=XXXG300 PSB=XXXG300 PLC=99 X LANG=CBL TYPE=MSG PLAN=UUU ./T TC=YYYTTX1 MBR=YYYGTX1 PSB=YYYGTX1 PLC=99 X LANG=CBL TYPE=MSG PLAN=UUU ENTER BTS COMMAND OR /FORMAT OR /* YYYTTX1 BTS0100I ATTACHING DFSRRC00, PARM=DLI,BTSPC000,YYYGTX1 ,12,01Y BTS0006I TRANSACTION STARTED: YYYTTX1 . MBR=YYYGTX1 PSB=YYYGTX1 EDIT= YYY=0 PLC=99LANG=CBL TYPE=MSG MSG CALL- FUNC=GU , PCB=IOPCB , STATUS= , MESSAGE NUMBER=01 LENGTH=75, PCBN=001 -MSG-GU ENTER COMMAND : 'L CALL', 'L IOAR', 'END' OR NULL LINE - === NOTE no ENTER BTS COMMAND OR /FORMAT OR /* etc.! ** DB CALL- FUNC=GU , PCB=YYYFABC , STATUS= , LEVEL=02, SEGMENT=YYYCTRX IOLENGTH=000765, PCBN=003-DB-GU ** DB CALL- FUNC=GHU , PCB=YYYFABC , STATUS= , LEVEL=02, SEGMENT=YYYCTRX IOLENGTH=000765, PCBN=003-DB-GHU ** DB CALL- FUNC=REPL, PCB=YYYFABC , STATUS= , LEVEL=02, SEGMENT=YYYCTRX IOLENGTH=000765, PCBN=003-DB-REPL BTS0031I MODNAME: OYYYJTX1 MSG CALL- FUNC=ISRT, PCB=IOPCB , STATUS= , MESSAGE NUMBER=01 LENGTH=000231, PCBN=001 -MSG-ISRT ENTER COMMAND : 'L CALL', 'L IOAR', 'END' OR NULL LINE - BTS0101A ENTER NULL LINE TO OBTAIN IMS-SCREEN FOR PCB(IOPCB ) === === Here the MFS is displayed OK, after that the transaction continues as it should (GU etc.) === The problem transaction: BTS0007I BTS V3R1 SIMULATION STARTED. TIME=15:45:25, DATE=2007.253, IMS=V9R1. ./D LTERM=IOPCB TYPE=3270-A02 SIZE=(24,80) FORMBUF=16000 TPBUF=16000 ./E SSID=DB2T ./O DB=Y TSODB=Y MSG=Y TSOMSG=P SQL=Y TSOSQL=Y X SQLHX=Y TSOSQLHX=Y MQI=A TSOMQI=Y IFI=Y TSOIFI=Y ./T TC=XXX300 MBR=XXXG300 PSB=XXXG300 PLC=99 X LANG=CBL TYPE=MSG PLAN=UUU ./T TC=YYYTTX1 MBR=YYYGTX1 PSB=YYYGTX1 PLC=99 X LANG=CBL TYPE=MSG PLAN=UUU ENTER BTS COMMAND OR /FORMAT OR /* XXX300 BTS0100I ATTACHING DFSRRC00, PARM=DLI,BTSPC000,XXXG300 ,12,01Y BTS0006I TRANSACTION STARTED: XXX300 . MBR=XXXG300 PSB=XXXG300 EDIT= YYY=0 PLC=99LANG=CBL TYPE=MSG IGZ0014W IGZEOPT is no longer supported. Its content was ignored. MSG CALL- FUNC=GU , PCB=IOPCB , STATUS= , MESSAGE NUMBER=01 LENGTH=75, PCBN=001 -MSG-GU ENTER COMMAND : 'L CALL', 'L IOAR', 'END' OR NULL LINE - ENTER BTS COMMAND OR /FORMAT OR /* === NOTE! /* BTS0008I END OF INPUT DATA SET ENCOUNTERED. MSG CALL- FUNC=GN , PCB=IOPCB , STATUS=QD, MESSAGE NUMBER=01 PCBN=001 -MSG-GN QD ENTER COMMAND : 'L CALL', 'L IOAR', 'END' OR NULL LINE - SQL CALL- TYPE=DELETE, PROGRAM=TIRPROFD, PLAN=UUU , STATEMENT=0768, SECTION=0006 -SQL-RC= BTS0031I MODNAME: OXXXJ300 MSG CALL- FUNC=ISRT, PCB=IOPCB , STATUS= , MESSAGE NUMBER=01 LENGTH=000347, PCBN=001 -MSG-ISRT ENTER COMMAND : 'L CALL', 'L IOAR', 'END' OR NULL LINE - SQL CALL- TYPE=INSERT, PROGRAM=TIRPROFD, PLAN=UUU , STATEMENT=0714, SECTION=0004 -SQL-RC= MSG CALL- FUNC=GU , PCB=IOPCB , STATUS=QC, MESSAGE NUMBER=01 PCBN=001 -MSG-GU QC ENTER COMMAND : 'L CALL', 'L IOAR', 'END' OR NULL LINE - BTS0020I STATISTICS REPORT FOR TRANSACTION:XXX300 . PCBNAMEGU GN GNP GHU GHN GHNP ISRT PURG REPL DLET DEQ CHKP LOG STAT XRST CHNG ROLB OPEN CLSE OTHR IOPCB 211 BTS0096I DB2=V8R1, SQL CALLS = 2 OPEN CLOSE SELECT FETCH INSERT DELETE UPDATE PREPARE DESCRIBE EXECUTE EXECUTE-IMMEDIATE OTHER
Re: Wikiscanner
[...] snip Thats why I never go to Wikipedia to look something up. If anyone can change it, how can you trust any of it? /snip How can you trust other encyclopedias ? Are there more reliable ? Possibly yes, epecially in some hot areas, but who cares about others reliability - who measured it before using ? I vaguely remain some funny bugs in polish encyclopedias. Reading commercial encyclopedia I have never know whether given entry is the only false one. g BTW: false content in wikipedia is very quickly removed. Every insert or update is checked by some guys. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.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.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
The ancient advantage of a 1 cyl PLPA and a large COMMON, the Seldom Ending Channelprogram, has been retired a couple of z/OS releases ago Not to dispute; where is that documented? The last time I discussed this with IBM it was still recommended. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Wikiscanner
BTW: false content in wikipedia is very quickly removed. Every insert or update is checked by some guys. Boy, are you optimistic! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
Mike Feeley wrote: I'm thinking of changing PLPA to the minimum size of 1 cylinder and letting it overflow into the COMMON page dataset. Is there any issues with allocating a huge COMMON page dataset? I would ask WHY ? Why do you want PLPA to overflow into COMMON page ? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.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.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Running with SQA/ESQA 100% CHECK
Barbara Nitz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Kees, About your answer above: why do you check a single PGDS utilization? I think it hardly hirts when one PGDS is over some limit if the total configuration is within limit? ... Besides that, the question is what we can do about it, as Barbara already mentioned. thanks for basically asking the same questions I have asked in the ETR I had opened. I was given to understand (not as clearly, of course) that I have no idea what I am talking about. And why do I even question IBMs best practises? spontaneous, non suppressable mindflash Gee Barbara, this sounds familiar, is HC also being developped in Boeblingen? /spontaneous, non suppressable mindflash As this has happened for *every* HC ETR I have ever opened (and also for quite a few emails that I had exchanged in hopes of improving the product) I have resolved to not bother anymore. If I cannot make a check fit, I just delete it. We have a line in every checklist that says 'get HC to shut up'. And we installed the downloadable version before we migrated to 1.6, so we've been putting up with HC for a long time. The only reason we still start the STC is that *very few* checks actually do make sense, the RACF_sensitive_resources being among them. Another is the RSM MAXCADS check, as this is the only way to actually see how many CADS are in use short of taking a dump. (It may be that showmvs also reports on this.) To me it appears that IBM is promoting the health checker as a way to prevent customers from using the variety of options that z/OS supports (just to make life for the support groups easier). Maybe it was driven by the aging of hardware system programmers and the coming lack of them. It seems it is going to be solved by making the systems intelligent, self-checking and self-healing as we have been promised for 10 or 20 years, but if this HC is the result, they still have a long way to go. To that effect, every component gets beaten to write a 'health check'. Hence some duplicate checks, some extremely poor documentation, some checks that I consider plain stupid, and a lot that appear to be written hastily (we call that unloved in German-lieblos) and not thought out. If you don't distort your installation to follow those so-called 'best practises', IBM will basically tell you that you're on your own, and if you don't do it, it's your own fault if you have problems. I still consider the *idea* of looking at best practises very valid and very good, but not how HC implements it, and not what I consider IBMs closedmindedness about the product and its checks. My 2 cents, and I'll stop now. We are installing 1.8 now and I will have a look at HC, but with reserve. Regards, Kees. Regards, Barbara -- ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
Ted MacNEIL [EMAIL PROTECTED] wrote in message news:1482040871-1189580775-cardhu_decombobulator_blackberry.rim.net-179 [EMAIL PROTECTED]... The ancient advantage of a 1 cyl PLPA and a large COMMON, the Seldom Ending Channelprogram, has been retired a couple of z/OS releases ago Not to dispute; where is that documented? The last time I discussed this with IBM it was still recommended. - OA14248, closed 2006-02-07. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Performance degradation
Is it possible defrag process (using ADRDSSU) in a volume at the same time with delete define file in the volume ? Yesterday I have a problem in production machine, the problem was performance degradation, I have check CPU Utilization low and there were many job was running including defrag process. Performance back to normal after cancel defrag process. Thanks --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Performance degradation
Nofri, Apa kabar? Did you check for enqueue contention on the VTOC? Your Delete/Define was probably stuck behind that. Check the RMF Enqueue report. It's unlikely that DEFRAG by itself will generate enough IO to degrade a single volume's performance unless the volume is already very busy before the defrag starts. Selamat Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Nofri Sent: Wednesday, September 12, 2007 12:30 AM To: IBM-MAIN@BAMA.UA.EDU Subject: [IBM-MAIN] Performance degradation Is it possible defrag process (using ADRDSSU) in a volume at the same time with delete define file in the volume ? Yesterday I have a problem in production machine, the problem was performance degradation, I have check CPU Utilization low and there were many job was running including defrag process. Performance back to normal after cancel defrag process. Thanks --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: The future of IBM Mainframes [just thinking]
What he said PLUS there are several contributors either between jobs or retired who don't have a company ID. Bill From: Ted MacNEIL [EMAIL PROTECTED] Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To: IBM-MAIN@BAMA.UA.EDU Subject: Re: The future of IBM Mainframes [just thinking] Date: Wed, 12 Sep 2007 02:36:11 + What he said! Please remember that a lot of us work for companies who forbid our use of company email addresses to post on public forums. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html _ More photos; more messages; more whatever. Windows Live Hotmail - NOW with 5GB storage. http://imagine-windowslive.com/hotmail/?locale=en-usocid=TXT_TAGHM_migration_HM_mini_5G_0907 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: The future of IBM Mainframes [just thinking]
What he said PLUS there are several contributors either between jobs I resemble that remark! Just because you don't use a corporate account, doesn't mean you should not contribute. There is only ONE List-Serve that I know of which requires you to use a corporate e-mail to contribute. And, that is ISV-Costs (run by John Anderson of IBM Canada). So, I never joined because my former company forbade us from using our e-mail to contribute. And, now I cannot join because I am back out on the job market. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: The future of IBM Mainframes [just thinking]
In a message dated 9/12/2007 6:22:29 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: There is only ONE List-Serve that I know of which requires you to use a corporate e-mail to contribute. And, that is ISV-Costs (run by John Anderson of IBM Canada). So, I never joined because my former company forbade us from using our e-mail to contribute. And, now I cannot join because I am back out on the job market. So create a new corporation named, perhaps, Eamacneil Enterprises. A corporate e-mail should be an easy second step. Show me a law, and I will show you a loophole. [First rule of lawyers] Bill Fairchild Plainfield, IL ** See what's new at http://www.aol.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
HTTP Server Abend
In the dark of night our HTTP server starting having problems on our zOS1.7 sand box. Well it was really probably during the day and we have not noticed it. Anyway, it has been working fine for a long time. The last known changes were to separate Telnet services outside TCPIP and change the Gateway statement to the Beginroutes statement. We backed the changes out and still got the same abend. Has anyone run across this or any suggestions as to what might be causing this abend? Thanks The return and reason codes suggest this is caused by mounting the HFS as R/W on another system that is not in the same GRS ring. No changes have been made there either and it appears the proper HFS files are mounted. $HASP373 IMWEBSRV STARTED IEF403I IMWEBSRV - STARTED - TIME=15.14.55 IMW3534I PID: 33555289 SERVER STARTING IEA995I SYMPTOM DUMP OUTPUT 191 USER COMPLETION CODE=4039 REASON CODE= TIME=15.14.55 SEQ=00468 CPU= ASID=0057 PSW AT TIME OF ERROR 078D1400 84A5BA8E ILC 2 INTC 0D NO ACTIVE MODULE FOUND NAME=UNKNOWN DATA AT PSW 04A5BA88 - 00181610 0A0D58D0 D00498EC * TOP OF DATA ** This is IBM HTTP Server V5R3M0 Built on Jan 12 2007 at 13:00:21. Started at Tue Sep 11 11:14:55 2007 Running as WEBSRV, UID:0, GID:5. Using _CEE_ENVFILE /etc/httpd.envvars. CEE3512S An HFS load of module GSKCMS31 failed. The system return code was 157; the reason code was 5B4B000D. entry offset +03D8 at address 10C029D0. From entry point __dllstaticinit at compile unit offset +03D8 at e 1CEE3DMP V1 R7.0: Condition processing resulted in the unhandled condition. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Wikiscanner
On Sep 12, 2007, at 1:55 AM, R.S. wrote: [...] snip Thats why I never go to Wikipedia to look something up. If anyone can change it, how can you trust any of it? /snip How can you trust other encyclopedias ? Are there more reliable ? Possibly yes, epecially in some hot areas, but who cares about others reliability - who measured it before using ? I vaguely remain some funny bugs in polish encyclopedias. Reading commercial encyclopedia I have never know whether given entry is the only false one. g BTW: false content in wikipedia is very quickly removed. Every insert or update is checked by some guys. Did you read that the CIA (or was it the the FBI) changes it to its political whim. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
On Sep 12, 2007, at 2:10 AM, R.S. wrote: Mike Feeley wrote: I'm thinking of changing PLPA to the minimum size of 1 cylinder and letting it overflow into the COMMON page dataset. Is there any issues with allocating a huge COMMON page dataset? I would ask WHY ? Why do you want PLPA to overflow into COMMON page ? It was recommended years ago by a guru and no one dares to question the guru. Ed -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.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.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
I'm thinking of changing PLPA to the minimum size of 1 cylinder and letting it overflow into the COMMON page dataset. Is there any issues with allocating a huge COMMON page dataset? I would ask WHY ? Why do you want PLPA to overflow into COMMON page ? It was recommended years ago by a guru and no one dares to question the guru. We do this so that we don't have to worry about sizing the PLPA page dataset. We just define a large common page dataset and let PLPAQ overflow into it. There is no performance degradation. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
Ed Gould wrote: Mike Feeley wrote: I'm thinking of changing PLPA to the minimum size of 1 cylinder and letting it overflow into the COMMON page dataset. Is there any issues with allocating a huge COMMON page dataset? I would ask WHY ? Why do you want PLPA to overflow into COMMON page ? It was recommended years ago by a guru and no one dares to question the guru. Ed I believe that recommendation is no longer valid (not sure as of which z/OS release), but it had to do with the way I/O was handled to load LPA. Allowing it to overflow for some reason was more efficient. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Wikiscanner
Ed Gould wrote: On Sep 12, 2007, at 1:55 AM, R.S. wrote: [...] snip Thats why I never go to Wikipedia to look something up. If anyone can change it, how can you trust any of it? /snip How can you trust other encyclopedias ? Are there more reliable ? Possibly yes, epecially in some hot areas, but who cares about others reliability - who measured it before using ? I vaguely remain some funny bugs in polish encyclopedias. Reading commercial encyclopedia I have never know whether given entry is the only false one. g BTW: false content in wikipedia is very quickly removed. Every insert or update is checked by some guys. Did you read that the CIA (or was it the the FBI) changes it to its political whim. As many other people. However only hot topics are subject of such change. Vast majority is politically neutral and therefore more reliable. Of course even neutral topics can be falsed i.e. by authors ignorance, however - as I said the same could apply to commercial encyclopedias, at smaller degree, but it still could. In other words, I use Wikipedia when I want to learn about something. I don't trust it's content in mission critical situations ...as well as other encyclopedias. In mission critical cases I look for specialist sources. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.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.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
Ed Gould wrote: On Sep 12, 2007, at 2:10 AM, R.S. wrote: Mike Feeley wrote: I'm thinking of changing PLPA to the minimum size of 1 cylinder and letting it overflow into the COMMON page dataset. Is there any issues with allocating a huge COMMON page dataset? I would ask WHY ? Why do you want PLPA to overflow into COMMON page ? It was recommended years ago by a guru and no one dares to question the guru. I know it WAS. My question was rather rhetorical. Many rules of thumb went obsoleted over the years. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.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.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
Ed Gould [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... On Sep 12, 2007, at 2:10 AM, R.S. wrote: Mike Feeley wrote: I'm thinking of changing PLPA to the minimum size of 1 cylinder and letting it overflow into the COMMON page dataset. Is there any issues with allocating a huge COMMON page dataset? I would ask WHY ? Why do you want PLPA to overflow into COMMON page ? It was recommended years ago by a guru and no one dares to question the guru. Ed Ok, I already tried to send an answer but Outlook crashed, so I'll try again: One guru told me years ago: question everything and I took that to include the guru. Until recently, the good reason was ASM's usage of Seldom Ending Channel Programs, but that is not valid anymore. If you want to know more about it, let me know. Now, like Mike's proposal, it can help you make life a little easier. PLPA can spill over to COMMON, but not vica versa. So if you want to manage space for both easily, you can do this by creating a small PLPA and a large COMMON, which has free space for both. With both a large PLPA and a COMMON, you must manage growth and free space for both. Not a very big issue, but just a little thing to make life somewhat easier. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
R.S. wrote: Ed Gould wrote: On Sep 12, 2007, at 2:10 AM, R.S. wrote: Mike Feeley wrote: I'm thinking of changing PLPA to the minimum size of 1 cylinder and letting it overflow into the COMMON page dataset. Is there any issues with allocating a huge COMMON page dataset? I would ask WHY ? Why do you want PLPA to overflow into COMMON page ? It was recommended years ago by a guru and no one dares to question the guru. I know it WAS. My question was rather rhetorical. Many rules of thumb went obsoleted over the years. I setup all my environments that way. Even if it no longer has any performance benefits it won't hurt anything and doing it that way is one less thing to worry about. -- Mark Jacobs Time Customer Service Tampa, FL -- Pound pastrami, can kraut, six bagels -- bring home for Emma. Isaac Edward Leibowitz (Saint Leibowitz) A Canticle for Leibowitz -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HTTP Server Abend
Matt, are you sharing your HFS in r/w with other systems (probably outside the plex...)??? Or, perhaps, are you sharing HFS (in r/w) between different OS levels??? _ Paolo Cacciari Business Continuity and Resiliency Services, IBM Global Services - South Region, EMEA Via Darwin 85, 20019 Settimo Milanese(MI) – Italy - MISET001 The goal is to be prepared for a disaster not to continually plan for a successful test * [EMAIL PROTECTED] ( + 39 051 41.36799 Mobile: + 39 335 6287584 7 + 39 02 596.23288 Fax BO: + 39 051 406052 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
My theory on this is much like Bob Shannon's. Keep it easier, if you are worried about the performance impact of page-ins from PLPA, you are so real storage constrained that your system will be in bad shape anyway. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Vernooy, C.P. - SPLXM Sent: Wednesday, September 12, 2007 2:19 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PLPA and COMMON PAGESPACE Size Ted MacNEIL [EMAIL PROTECTED] wrote in message news:1482040871-1189580775-cardhu_decombobulator_blackberry.rim.net-179 [EMAIL PROTECTED]... The ancient advantage of a 1 cyl PLPA and a large COMMON, the Seldom Ending Channelprogram, has been retired a couple of z/OS releases ago Not to dispute; where is that documented? The last time I discussed this with IBM it was still recommended. - OA14248, closed 2006-02-07. Kees. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: BTS-problem w COOL:gen et al.
Thomas, When you say the BTS run ends, were there any BTS messages? I would have expected the ENTER to generate some sort of message. What should be generated by the MFS when you hit enter? (specifically, the first part of the message showing the transaction code.) Mark Hammond Applications Consultant -Original Message- From: Thomas Berg [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 12, 2007 2:04 AM To: IBM-MAIN@BAMA.UA.EDU Subject: BTS-problem w COOL:gen et al. === === Here the MFS is displayed, but after that (e g ENTER) the transaction dies and the BTS run ends - as: === BTS0005I END OF BTS RUN. *** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Global mirror for z/OS
We are building a disaster recovery datacenter about 4 hrs. from our primary site. Does anyone have any information on XRC Global mirroring for z/OS and are there any good redbooks/manuals? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
We do this so that we don't have to worry about sizing the PLPA page dataset. We just define a large common page dataset and let PLPAQ overflow into it. There is no performance degradation. I've been doing since at least XA, if not before. And, that was before expanded storage, so paging rates were high. Until we start paging again, I don't think it's a bad practice. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ServerPac Installs and dataset allocations
On Tue, 11 Sep 2007 17:23:49 -0400, Bob Shannon [EMAIL PROTECTED] wrote: I can't justify a mod-27 since about 60% of it would be empty - multiplied by all our sysres sets: 2 for maintenance (one for each company), 6 for one company environment, 3 or 4 sets for 3 other environments and a few more sets for sandbox environments. So at least 20 or so mod-27s in all that would not even be half full. As I've said before, we define Mod-15s for the sysres. They're about 15Gb. It's a good size for us. The entire sysres fits on 1 volume. That's a good idea if you don't have disaster recovery implications. We don't any more, but we used to. The reason I don't want custom sizes is that occasionally we run out of available cloning sets and need to create a new one. That doesn't ever happen except during version migrations when some of the sets are used for one release and some for another. But when it does, we can easily get another set of 3390-9 volumes to use. If we had a large pool of say mod-15s in use for other workloads then that wouldn't be an issue. We don't have many mod-27 volumes in use at this point, but we are starting to use them more. One of our sysres volumes contains ISV products (MVS products only). I could see using a mod-27 if we put the ISV and IBM OS on the same volume, but I'm not sure I want to do that (but I haven't ruled it out for the future either). Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Global mirror for z/OS
Sharon, you can start with this manual: http://publibz.boulder.ibm.com/epubs/pdf/antgr131.pdf This could be an useful web page: http://www-1.ibm.com/support/docview.wss?rs=580uid=ssg1S7000860 For any questions, try to contact me offlist. Hope this hepls. Regards. _ Paolo Cacciari Business Continuity and Resiliency Services, IBM Global Services - South Region, EMEA Via Darwin 85, 20019 Settimo Milanese(MI) – Italy - MISET001 The goal is to be prepared for a disaster not to continually plan for a successful test * [EMAIL PROTECTED] ( + 39 051 41.36799 Mobile: + 39 335 6287584 7 + 39 02 596.23288 Fax BO: + 39 051 406052 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
I believe that recommendation is no longer valid (not sure as of which z/OS release), but it had to do with the way I/O was handled to load LPA. If you're not paging, it doesn't matter. Allowing it to overflow for some reason was more efficient. The efficiency had to do with (then) expensive DASD (dollars/mb, rather than today's pennies/gb). The practice was: Define a 1-CYL PLPA and put it and the COMMON on the same pack. It saved you a pack. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: The future of IBM Mainframes [just thinking]
Bill there are several contributors ... between jobs ... In some professions it's called resting. Chris Mason - Original Message - From: Bill Wilkie [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Wednesday, September 12, 2007 12:52 PM Subject: Re: The future of IBM Mainframes [just thinking] ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
Mike Feeley wrote: I'm thinking of changing PLPA to the minimum size of 1 cylinder and letting it overflow into the COMMON page dataset. Is there any issues with allocating a huge COMMON page dataset? For example, if my LPAR only requires a combined PLPA and COMMON size of 800 cylinders, can I used an entire 3390- 3 for the new PLPA (1 cylinder) and COMMON (the rest of the volume, around 3337 cylinders)? Any issues with the large number of page slots, memory usage, etc. This is for z/OS 1.8 on a z9 box. Nothing else will use this volume. It will either be 100% utilized with PAGE datasets or 100% utulized with PAGE datasets plus a placeholder (filler) dataset. I don't know why I can't just create a huge COMMON page dataset and be done with it versus creating a 700 cylinder COMMON this year and maybe then a 800 cylinder COMMON in 2 more years, etc. Just create the one huge COMMON page dataset and I will be set well into retirement. What are the downfalls from doing something like this? snip There is no point in making the COMMON data set any larger than 2GB. COMMON cannot possibly grow to 2GB, since that would be _all_ the space below the bar. I'd allocate a 1-cylinder PLPA followed by a 2GB COMMON and then forget about it for (probably) the rest of my life. -- John Eells z/OS Technical Marketing IBM Poughkeepsie [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
On Wed, 12 Sep 2007 07:07:19 +, Ted MacNEIL [EMAIL PROTECTED] wrote: The ancient advantage of a 1 cyl PLPA and a large COMMON, the Seldom Ending Channelprogram, has been retired a couple of z/OS releases ago Not to dispute; where is that documented? The last time I discussed this with IBM it was still recommended. APAR Identifier .. OA14248 Last Changed 06/10/10 NEW FUNCTION Symptom .. NF PERFM Status ... CLOSED UR1 Severity ... 3 Date Closed . 06/02/07 Component .. 5752SC1CW Duplicate of Reported Release . 708 Fixed Release 999 Component Name 5752 AUX STOR M Special Notice ATTENTION Current Target Date .. Flags SCP ...NEW FUNCTION Platform PERVASIVE Status Detail: SHIPMENT - Packaged solution is available for shipment. PE PTF List: PTF List: Release 707 : UA24291 available 06/02/22 (F602 ) Release 708 : UA24292 available 06/02/22 (F602 ) Release 709 : UA24293 available 06/02/22 (F602 ) Release 717 : UA24295 available 06/02/22 (F602 ) Release 720 : UA24294 available 06/02/22 (F602 ) Parent APAR: Child APAR list: ERROR DESCRIPTION: New function APAR As processors, control units, dasd have increased in speed the benefits of suspend/resume have decreased to the point where it has been determined the difference between suspend/ resume and start subchannel are not longer relevant. Therefore it has been decided to no longer use suspend/resume. LOCAL FIX: PROBLEM SUMMARY: * USERS AFFECTED: All users of HBB7707, HBB7708, HBB7709, * * JBB7717, and HBB7720.* * PROBLEM DESCRIPTION: ASM uses suspendable channel programs. * * When an ASM channel program completes, * * it goes into a suspended state. Later, * * when ASM wants to initiate another * * I/O request, it modifies and then * * resumes the suspended channel * * program.* * RECOMMENDATION: The use of suspend/resume channel programs * * in ASM is deleted. * The use of suspend/resume channel programs in ASM is deleted. -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SV: BTS-problem w COOL:gen et al.
Mark, Firstly: when BTS run ends there is only the BTS0005I END OF BTS RUN. message. Secondly: I have got it working by having an end-of-message indicator when issuing the transcode, XXX300 $ ! (Also - before trying that - I got it to a working state by doing a /FORMAT modname after the first ENTER BTS COMMAND OR /FORMAT OR /*.) Unfortunately it doesn't work when I include the XXX300 $ in the BTSIN input. I have to enter it on the screen during the run. So the problem is solved. _ Thomas Berg Specialist IT Utveckling Swedbank AB (Publ) -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] För Mark Hammond Skickat: den 12 september 2007 15:07 Till: IBM-MAIN@BAMA.UA.EDU Ämne: Re: BTS-problem w COOL:gen et al. Thomas, When you say the BTS run ends, were there any BTS messages? I would have expected the ENTER to generate some sort of message. What should be generated by the MFS when you hit enter? (specifically, the first part of the message showing the transaction code.) Mark Hammond Applications Consultant -Original Message- From: Thomas Berg [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 12, 2007 2:04 AM To: IBM-MAIN@BAMA.UA.EDU Subject: BTS-problem w COOL:gen et al. === === Here the MFS is displayed, but after that (e g ENTER) the transaction dies and the BTS run ends - as: === BTS0005I END OF BTS RUN. *** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John Eells Sent: Wednesday, September 12, 2007 8:38 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PLPA and COMMON PAGESPACE Size snip There is no point in making the COMMON data set any larger than 2GB. COMMON cannot possibly grow to 2GB, since that would be _all_ the space below the bar. I'd allocate a 1-cylinder PLPA followed by a 2GB COMMON and then forget about it for (probably) the rest of my life. -- John Eells I'm confused by this. Isn't ECSA and the like paged to COMMON? Or is it paged to normal paging datasets? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
McKown, John [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED].. .. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John Eells Sent: Wednesday, September 12, 2007 8:38 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PLPA and COMMON PAGESPACE Size snip There is no point in making the COMMON data set any larger than 2GB. COMMON cannot possibly grow to 2GB, since that would be _all_ the space below the bar. I'd allocate a 1-cylinder PLPA followed by a 2GB COMMON and then forget about it for (probably) the rest of my life. -- John Eells I'm confused by this. Isn't ECSA and the like paged to COMMON? Or is it paged to normal paging datasets? It is confusing these days, with lines and bars, but ECSA is still under the 2GB line. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
On Wed, 12 Sep 2007 15:56:20 +0200, Vernooy, C.P. - SPLXM [EMAIL PROTECTED] wrote: There is no point in making the COMMON data set any larger than 2GB. COMMON cannot possibly grow to 2GB, since that would be _all_ the space below the bar. I'd allocate a 1-cylinder PLPA followed by a 2GB COMMON and then forget about it for (probably) the rest of my life. -- John Eells I'm confused by this. Isn't ECSA and the like paged to COMMON? Or is it paged to normal paging datasets? It is confusing these days, with lines and bars, but ECSA is still under the 2GB line. Right, and as John said... that would be all the space below the bar which would mean no EPVT (31-bit private). Try IPLing a sandbox with CSA=(n,1800M) (leaving some room for EPLPA/EMLPA/EFLPA/ESQA/ENUC) and see how far you get. ;-) Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
John, CSA and ECSA are paged to the COMMON page dataset, PLPA is paged to PLPA and (if overflow) to COMMMON. Since the combined size of PLPA+COMMON has to be less than 2GB, (at least until RMODE 64 programs are available, which may never happen), a 2GB COMMON page dataset will be more than large enough. Where is the confusion? Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Wednesday, September 12, 2007 8:47 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PLPA and COMMON PAGESPACE Size -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John Eells Sent: Wednesday, September 12, 2007 8:38 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PLPA and COMMON PAGESPACE Size snip There is no point in making the COMMON data set any larger than 2GB. COMMON cannot possibly grow to 2GB, since that would be _all_ the space below the bar. I'd allocate a 1-cylinder PLPA followed by a 2GB COMMON and then forget about it for (probably) the rest of my life. -- John Eells I'm confused by this. Isn't ECSA and the like paged to COMMON? Or is it paged to normal paging datasets? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ServerPac Installs and dataset allocations
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John Eells Sent: Tuesday, September 11, 2007 7:35 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: ServerPac Installs and dataset allocations SNIP Oddly enough I'd looked already. I wrote the SMS support spec for ServerPac and I'd have been acutely aware of defects related to the design or its execution. Even now, as you see, I retain some degree of professional interest. In any event, searching for ServerPac, volser, and SMS return one hit in RETAIN, OW54994, which has nothing to do with primary or secondary space allocation specification. ServerPac and SMS return 21 hits (most are even for ServerPac ;-), none of which have to do with space allocation specification either. Dialog defects, incorrectly built JCL and such, sure, but I found nothing that says the code that processes the space allocation amounts is broken. SNIP I think I see the problem. I have not been talking about the allocation from the viewpoint of amount of space but VOLSER specific issues. ServerPac logic was, shall we say, declaring volumes to be SMS volumes, based on the first two digits of the VOLSER. This then made volumes in-eligible for the datasets that were specifically set to go to those volumes. Example: CMSRES, CMSCAT, CMSnnn as you can see start with CM. But when telling the install what the volume was for SMS control, it saw the CM and decided from that point forward that any volume starting with CM was an SMS controlled volume. Regards, Steve Thompson -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
On Wed, 12 Sep 2007 09:37:36 -0400, John Eells wrote: There is no point in making the COMMON data set any larger than 2GB. Until (and unless) we start having common above the bar. Even then 2GB will likely last a while. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
APAR Identifier .. OA14248 Thanks, Mark. That APAR only mentions suspend/resume. Nothing regarding the one cylinder PLPA. (Which was in use long before suspend/resume, and was used to save a pack -- not for performance). - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bob Shannon Sent: Wednesday, September 12, 2007 7:34 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PLPA and COMMON PAGESPACE Size SNIP We do this so that we don't have to worry about sizing the PLPA page dataset. We just define a large common page dataset and let PLPAQ overflow into it. There is no performance degradation. SNIP In most shops where I did the system work, I made the LPA page data set 30% (min) larger than what it used at the time it was going to be rolled into production. The Common was made the max size (today, basically a volume on 3390-3). We did not do CLPA except for when we KNEW we were putting on maint that required the LPA to be refreshed. IPLs ran rather quickly (although today the difference between CLPA and non-CLPA is hardly noticeable). And we didn't have surprises of maint getting on before we were ready. Development shops may want the overflow to always force a CLPA. Regards, Steve Thompson --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
I'm confused by this. Isn't ECSA and the like paged to COMMON? Or is it paged to normal paging datasets? But, extended COMMON and below the line COMMON are still below the 2GB bar. So, they could never add up to more than 2GB. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
Kees wrote: Now, like Mike's proposal, it can help you make life a little easier. PLPA can spill over to COMMON, but not vica versa. So if you want to manage space for both easily, you can do this by creating a small PLPA and a large COMMON, which has free space for both. With both a large PLPA and a COMMON, you must manage growth and free space for both. Not a very big issue, but just a little thing to make life somewhat easier. What prevented me from ever doing the small PLPA thing was the last part of the description of the IRL005E message... ILR005E PLPA PAGE DATA SET FULL, OVERFLOWING TO COMMON DATA SET Explanation: The PLPA page data set has become full. All subsequent writes for the PLPA will be sent to the COMMON page data set. System Action: The system continues to build the link pack area by writing pages for the remaining LPA modules to the common page data set. If the common page data set is unavailable or becomes full, the system will be terminated with a wait state code X'03C' reason 3. The way I always figured it was belts braces... if either one of them became unavailable, the other one was still there, which is why I also have them on separate volumes. Could never see the point of gambling with the possibility of downtime on a Prod system... Herbie Elavon Financial Services Limited Registered in Ireland: Number 418442 Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Elavon Financial Services Limited, trading as Elavon, is regulated by the Financial Regulator -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Wednesday, September 12, 2007 9:26 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PLPA and COMMON PAGESPACE Size I'm confused by this. Isn't ECSA and the like paged to COMMON? Or is it paged to normal paging datasets? But, extended COMMON and below the line COMMON are still below the 2GB bar. So, they could never add up to more than 2GB. - Yea. I desperately need more sleep. And less Oracle (don't ask, won't tell, mea culpa!). -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Running with SQA/ESQA 100% CHECK
Barbara Nitz wrote: [snip] thanks for basically asking the same questions I have asked in the ETR I had opened. I was given to understand (not as clearly, of course) that I have no idea what I am talking about. And why do I even question IBMs best practises? As this has happened for *every* HC ETR I have ever opened (and also for quite a few emails that I had exchanged in hopes of improving the product) I have resolved to not bother anymore. If I cannot make a check fit, I just delete it. We have a line in every checklist that says 'get HC to shut up'. And we installed the downloadable version before we migrated to 1.6, so we've been putting up with HC for a long time. 1) I hope someone at IBM is paying attention to this. The only reason we still start the STC is that *very few* checks actually do make sense, the RACF_sensitive_resources being among them. Another is the RSM MAXCADS check, as this is the only way to actually see how many CADS are in use short of taking a dump. (It may be that showmvs also reports on this.) I've found these to be extremely useful checks as well. One thing helping to keep our platform down is sysprogs that fail to enable new function year after year. Another good reason for checks is to get those Luddites to enable missing functionality on their systems. A message that must be explained ... well ... must be explained. To me it appears that IBM is promoting the health checker as a way to prevent customers from using the variety of options that z/OS supports (just to make life for the support groups easier). To that effect, every component gets beaten to write a 'health check'. Hence some duplicate checks, some extremely poor documentation, some checks that I consider plain stupid, and a lot that appear to be written hastily (we call that unloved in German-lieblos) and not thought out. If you don't distort your installation to follow those so-called 'best practises', IBM will basically tell you that you're on your own, and if you don't do it, it's your own fault if you have problems. My sense is that various z/OS components have been told they *must* write checks. That might not have been the best approach. I still consider the *idea* of looking at best practises very valid and very good, but not how HC implements it, and not what I consider IBMs closedmindedness about the product and its checks. 2) I hope someone at IBM is paying attention to this. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ServerPac Installs and dataset allocations
Thompson, Steve wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of John Eells Sent: Tuesday, September 11, 2007 7:35 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: ServerPac Installs and dataset allocations SNIP Oddly enough I'd looked already. I wrote the SMS support spec for ServerPac and I'd have been acutely aware of defects related to the design or its execution. Even now, as you see, I retain some degree of professional interest. In any event, searching for ServerPac, volser, and SMS return one hit in RETAIN, OW54994, which has nothing to do with primary or secondary space allocation specification. ServerPac and SMS return 21 hits (most are even for ServerPac ;-), none of which have to do with space allocation specification either. Dialog defects, incorrectly built JCL and such, sure, but I found nothing that says the code that processes the space allocation amounts is broken. SNIP I think I see the problem. I have not been talking about the allocation from the viewpoint of amount of space but VOLSER specific issues. ServerPac logic was, shall we say, declaring volumes to be SMS volumes, based on the first two digits of the VOLSER. This then made volumes in-eligible for the datasets that were specifically set to go to those volumes. Example: CMSRES, CMSCAT, CMSnnn as you can see start with CM. But when telling the install what the volume was for SMS control, it saw the CM and decided from that point forward that any volume starting with CM was an SMS controlled volume. snip I can't find an APAR that describes that problem and I don't recall it, either, but that doesn't absolutely mean it never happened. (Memory is the second thing to go, right? ;-) But it's the *logical* volume (LVOL) serial starting with SM that identifies a group of SMS-managed data sets. There is no *physical* volume serial displayed for an SMS-managed data set in the dialog, because we can't know where the data set will wind up in advance; that's up to your SMS configuration and ACS routines. Instead, the dialog displays a STORCLAS for SMS-managed data sets. The CHANGE command can switch back and forth at the group level (either by LVOL, originally, or by View and Change attribute, the latter being much easier) and you can use the panels to switch back and forth at the data set level. (In either case, the SMS-eligible and SMS-required attributes control whether you can make the change.) There are additional restrictions, such as the requirement to change the LVOL of a data set to change its SMS-managed status unless you change the status of the entire LVOL's worth of data sets at the same time (if you change from SMS to non-SMS, the dialog will rename the LVOL so it no longer starts with SM). It would not be terribly hard to get lost here and think that a data set was stuck in an SMS-managed state. The SMS support was, admittedly, somewhat complex and confusing before we introduced the View and Change option in a later release. This is largely the consequence of very old design decisions that created LVOLs and how they were processed to begin with. I would like to think that nobody is messing with them any more now that View and Change can shield everyone from having to worry about them. -- John Eells z/OS Technical Marketing IBM Poughkeepsie [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: The future of IBM Mainframes [just thinking]
Sincere apologies... I was probably wrong to create an absolute rule... Thanks for pointing out the other side of the coin to me... it was definitely in the shade, otherwise I would have noticed it, surely... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bill Wilkie Sent: 12 September 2007 11:52 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: The future of IBM Mainframes [just thinking] What he said PLUS there are several contributors either between jobs or retired who don't have a company ID. Bill From: Ted MacNEIL [EMAIL PROTECTED] Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To: IBM-MAIN@BAMA.UA.EDU Subject: Re: The future of IBM Mainframes [just thinking] Date: Wed, 12 Sep 2007 02:36:11 + What he said! Please remember that a lot of us work for companies who forbid our use of company email addresses to post on public forums. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html _ More photos; more messages; more whatever. Windows Live Hotmail - NOW with 5GB storage. http://imagine-windowslive.com/hotmail/?locale=en-usocid=TXT_TAGHM_migr ation_HM_mini_5G_0907 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Elavon Financial Services Limited Registered in Ireland: Number 418442 Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Elavon Financial Services Limited, trading as Elavon, is regulated by the Financial Regulator -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
Ted MacNEIL [EMAIL PROTECTED] wrote in message news:1253452742-1189606952-cardhu_decombobulator_blackberry.rim.net-192 [EMAIL PROTECTED]... APAR Identifier .. OA14248 Thanks, Mark. That APAR only mentions suspend/resume. Nothing regarding the one cylinder PLPA. (Which was in use long before suspend/resume, and was used to save a pack -- not for performance). - Ted, did you not get my reply with the APAR number? The 1 cylinder PLPA is a result of suspend/resume and the high cost of diskspace these days. With suspend/resume you should have only 1 pagedataset on a volume and by shifing all data to the Common and thus eliminating PLPA dataset I/O, you could get both the paging performance and the volume efficiency. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Running with SQA/ESQA 100% CHECK
Barbara Based upon past posts, I've gotten (and still have) huge respect for your knowlege and expertise on this platform. My only guess is that your (negative) experience with Health Checker support may have something to do with how IBM support works outside of the US. In my experience, IBM support has been responsive to specific problems and issues I have brought to their attention. I have certainly heard of differences described by those in AP and EMEA with regards to how IBM support works. I can only say that my experience with IBM US support is usually very good. Another vehicle we all also have is the outstanding relationship that exists today between many IBM z/OS development organizations and the US SHARE User Group. I believe you care about this platform. Please, don't give up. Please help us all improve z/OS for the future. Try to attend SHARE. Or, if it is simply not feasable to attend SHARE in the US, please participate with us in some fashion via electronic means. How about this idea? Can we start new threads to discuss specific checks which are not helpful or are incomplete or deficient in some way? One check per discussion thread? For example, lets say you (or anyone else) has something to say about check USS_AUTOMOUNT_DELAY, just to pick one as an example. We could use a discussion thread convention like this: Subject: Health Check USS_AUTOMOUNT_DELAY problems And then, explain the concern with the check, and let others observe and comment. Then, those of us who have occasion to directly discuss with IBM Health Check issues can have specific suggestions for improvement to pass along. Someone might be inspired to collapse/codify the suggestion into a Requirement. IBM might even monitor this discussion directly, but we certainly don't use IBM-MAIN as an official channel to IBM. Again, please help us make Health Checker better. I think it is in all our interests that z/OS be successful in all installations, and that Health Checker can be an important vehicle to help installations keep their z/OS healthy. Brian On Wed, 12 Sep 2007 08:42:51 +0200, Barbara Nitz wrote: Kees, About your answer above: why do you check a single PGDS utilization? I think it hardly hirts when one PGDS is over some limit if the total configuration is within limit? ... Besides that, the question is what we can do about it, as Barbara already mentioned. thanks for basically asking the same questions I have asked in the ETR I had opened. I was given to understand (not as clearly, of course) that I have no idea what I am talking about. And why do I even question IBMs best practises? As this has happened for *every* HC ETR I have ever opened (and also for quite a few emails that I had exchanged in hopes of improving the product) I have resolved to not bother anymore. If I cannot make a check fit, I just delete it. We have a line in every checklist that says 'get HC to shut up'. And we installed the downloadable version before we migrated to 1.6, so we've been putting up with HC for a long time. The only reason we still start the STC is that *very few* checks actually do make sense, the RACF_sensitive_resources being among them. Another is the RSM MAXCADS check, as this is the only way to actually see how many CADS are in use short of taking a dump. (It may be that showmvs also reports on this.) To me it appears that IBM is promoting the health checker as a way to prevent customers from using the variety of options that z/OS supports (just to make life for the support groups easier). To that effect, every component gets beaten to write a 'health check'. Hence some duplicate checks, some extremely poor documentation, some checks that I consider plain stupid, and a lot that appear to be written hastily (we call that unloved in German- lieblos) and not thought out. If you don't distort your installation to follow those so-called 'best practises', IBM will basically tell you that you're on your own, and if you don't do it, it's your own fault if you have problems. I still consider the *idea* of looking at best practises very valid and very good, but not how HC implements it, and not what I consider IBMs closedmindedness about the product and its checks. My 2 cents, and I'll stop now. Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
Tom Marchant wrote: On Wed, 12 Sep 2007 09:37:36 -0400, John Eells wrote: There is no point in making the COMMON data set any larger than 2GB. Until (and unless) we start having common above the bar. Even then 2GB will likely last a while. Paging for common storage above 2G will likely not be directed toward the existing common paging data set. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
Ted, did you not get my reply with the APAR number? No. I missed it. The 1 cylinder PLPA is a result of suspend/resume and the high cost of diskspace these days. I was doing it before suspend/resume came out (MVS/SP1.3.0?) The first performance course I ever took had it as a 'trick of the trade'. January 1982. (The course was actually given by Amdahl) - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
And to reduce having to seek over empty cylinders because you would allocate more space to the PLPA for growth. Regards, Gene --Original Message-- From: Ted MacNEIL Sender: IBM Mainframe Discussion List To: IBM-MAIN@BAMA.UA.EDU ReplyTo: IBM Mainframe Discussion List Sent: Sep 12, 2007 10:23 AM Subject: Re: PLPA and COMMON PAGESPACE Size APAR Identifier .. OA14248 Thanks, Mark. That APAR only mentions suspend/resume. Nothing regarding the one cylinder PLPA. (Which was in use long before suspend/resume, and was used to save a pack -- not for performance). - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Sent via BlackBerry by ATT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
On Wed, 12 Sep 2007 16:29:15 +0200, Vernooy, C.P. - SPLXM [EMAIL PROTECTED] wrote: The 1 cylinder PLPA is a result of suspend/resume and the high cost of diskspace these days. With suspend/resume you should have only 1 pagedataset on a volume and by shifing all data to the Common and thus eliminating PLPA dataset I/O, you could get both the paging performance and the volume efficiency. Now it doesn't matter if you have more than one pageds per volume if you have dynamic pav (regardless of suspend/resume). I think the decision to remove suspend/resume was based on issues that kept cropping up with pav and paging. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: The future of IBM Mainframes [just thinking]
Not to mention us unwashed unemployed Ted MacNEIL wrote: What he said! Please remember that a lot of us work for companies who forbid our use of company email addresses to post on public forums. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
snip--- It was recommended years ago by a guru and no one dares to question the guru. unsnip-- HORSEFEATHERS!! No guru is beyond challenging, expecially when experience indicates different from what the so-called GURU advocates. We tried it both ways at Clearing and ended up separating PAGE and COMMON page spaces and NOT using the overflow method. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
Thanks for that Ted. I thought it was me. ? On Wed Sep 12 14:23 , Ted MacNEIL [EMAIL PROTECTED] sent: APAR Identifier .. OA14248 Thanks, Mark. That APAR only mentions suspend/resume. Nothing regarding the one cylinder PLPA. (Which was in use long before suspend/resume, and was used to save a pack -- not for performance). - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
Mark Zelden wrote: ... I think the decision to remove suspend/resume was based on issues that kept cropping up with pav and paging. Must have been a fairly serious issue of some sort. Why else would they change the behavior via APAR and not on a release boundary? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Global mirror for z/OS
-snip We are building a disaster recovery datacenter about 4 hrs. from our primary site. Does anyone have any information on XRC Global mirroring for z/OS and are there any good redbooks/manuals? ---unsnip--- Much depends on the config; contact me off-list and we can talk. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concurrent Upgrade Puzzlement.
Physically not possible, but virtually possible? :-) The CP display shows CP's 0, 2, and 4 online. The 'change LPAR controls' shows 4 'non dedicated CPs'. The activation profile shows 3 non shared. (Most likely it was 4 before the change.) Three of the four LPAR D M=CPU displays seem to be correct. The odd LPAR happens to be our z/os.e with our most loved workloads. Interesting, yes? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Tuesday, September 11, 2007 9:45 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Concurrent Upgrade Puzzlement. If you have 4 CPs there, it dispatches four logical CPs on three physical CPs. Not a good idea. Also, not possible. Unlike VM, PRSM/LPAR does not virtualise CP's. If the physical CEC has 'n' CP's, no LPAR can have more than 'n' LP's. - Too busy driving to stop for gas! NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
I think that the straw which finally prompted the elimination of suspend/resume channel programs for paging was a problem exposed by products which DDR swap DASD volumes dynamically. I suspect the thinking went something like this: Since the problem exposed by DDR swap of page volumes was very severe, the complexity of correctly fixing this problem very high, and the actual performance value of suspend/resume in this day and age now extremely low, why not simply delete suspend/resume complexity from ASM? See OA09675 for more background on this. Brian On Wed, 12 Sep 2007 09:46:24 -0700, Edward Jaffe wrote: Mark Zelden wrote: ... I think the decision to remove suspend/resume was based on issues that kept cropping up with pav and paging. Must have been a fairly serious issue of some sort. Why else would they change the behavior via APAR and not on a release boundary? -- Edward E Jaffe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Running with SQA/ESQA 100% CHECK
Barbara SHOWMVS and SHOWzOS report the MAXCAD and current usage since several years. Require APF. Dataspace/Hiperspace . . . Total MAXCAD=25 Total used CADS=12 Roland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concurrent Upgrade Puzzlement.
Interesting, yes. I would have expected CPs 0,1 and 2 online. Did you pose the question to IBM HW support? I'd be interested to hear the answer if/when you get one. Steve -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Hal Merritt Sent: Wednesday, September 12, 2007 1:00 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Concurrent Upgrade Puzzlement. Physically not possible, but virtually possible? :-) The CP display shows CP's 0, 2, and 4 online. The 'change LPAR controls' shows 4 'non dedicated CPs'. The activation profile shows 3 non shared. (Most likely it was 4 before the change.) Three of the four LPAR D M=CPU displays seem to be correct. The odd LPAR happens to be our z/os.e with our most loved workloads. Interesting, yes? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Tuesday, September 11, 2007 9:45 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Concurrent Upgrade Puzzlement. If you have 4 CPs there, it dispatches four logical CPs on three physical CPs. Not a good idea. Also, not possible. Unlike VM, PRSM/LPAR does not virtualise CP's. If the physical CEC has 'n' CP's, no LPAR can have more than 'n' LP's. - Too busy driving to stop for gas! NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
FICON tape drive?
Anybody ever seen a stand alone FICON attached 3490 capable tape drive? Yes, I know it sounds crazy. I'm fairly certain they don't exist, but I need to know. Thanks. Jeffrey Deaver, Engineer Systems Engineering [EMAIL PROTECTED] 651-665-4231(v) 651-610-7670(p) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concurrent Upgrade Puzzlement.
Ted, The statement snip Unlike VM, PRSM/LPAR does not virtualise CP's. /snip begs the question: If I have a CEC with 4 GP CPUs and 2 LPARS, LPAR1 has 4 non-dedicated initial CPs and LPAR2 has 2 non-dedicated initial CPs, is not PRSM/LPAR virtualizing CPs, since there 6 logical CPs, but only 4 physical CPs? Curiosity of course, since I don't use VM. Steve -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Tuesday, September 11, 2007 10:45 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Concurrent Upgrade Puzzlement. If you have 4 CPs there, it dispatches four logical CPs on three physical CPs. Not a good idea. Also, not possible. Unlike VM, PRSM/LPAR does not virtualise CP's. If the physical CEC has 'n' CP's, no LPAR can have more than 'n' LP's. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concurrent Upgrade Puzzlement.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bielskie, Stephen Sent: Wednesday, September 12, 2007 12:42 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Concurrent Upgrade Puzzlement. Ted, The statement snip Unlike VM, PRSM/LPAR does not virtualise CP's. /snip begs the question: If I have a CEC with 4 GP CPUs and 2 LPARS, LPAR1 has 4 non-dedicated initial CPs and LPAR2 has 2 non-dedicated initial CPs, is not PRSM/LPAR virtualizing CPs, since there 6 logical CPs, but only 4 physical CPs? Curiosity of course, since I don't use VM. Steve From what I understand, PRSM calls these things logical CPs and assigns each LPAR a number of logical CPs. It then dispatches the logical CP on a physical CP. I don't know when PRSM assigns a logical CP to a physical CP. It may be at LPAR activation, or may be dynamic. But within a single LPAR one physical CP will map to at most one logical CP. Therefore the number of logical CPs which may be assigned to an LPAR cannot exceed the number of physical CPs. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FICON tape drive?
You might be better off looking for an ESCON attached 3490 and adding a Ficon to ESCON converter. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey Deaver Sent: Wednesday, September 12, 2007 1:40 PM To: IBM-MAIN@BAMA.UA.EDU Subject: FICON tape drive? Anybody ever seen a stand alone FICON attached 3490 capable tape drive? Yes, I know it sounds crazy. I'm fairly certain they don't exist, but I need to know. Thanks. Jeffrey Deaver, Engineer Systems Engineering [EMAIL PROTECTED] 651-665-4231(v) 651-610-7670(p) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FICON tape drive?
We recently acquired a refurbished Sun/STK 9490 Timberline (3490 clone). The purchase/shipping documents indicate the ESCON interface is a separate component. Looking at the guts confirms the interface is physically separate from the drive. All of which implies there are other interfaces that could be used. I don't know if a FICON interface is one of the options but this might lead you in the right direction. -Original Message- From: Jeffrey Deaver [mailto:snip] Sent: Wednesday, September 12, 2007 10:40 AM To: IBM-MAIN@BAMA.UA.EDU Subject: FICON tape drive? Anybody ever seen a stand alone FICON attached 3490 capable tape drive? Yes, I know it sounds crazy. I'm fairly certain they don't exist, but I need to know. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concurrent Upgrade Puzzlement.
Bielskie, Stephen wrote: If I have a CEC with 4 GP CPUs and 2 LPARS, LPAR1 has 4 non-dedicated initial CPs and LPAR2 has 2 non-dedicated initial CPs, is not PRSM/LPAR virtualizing CPs, since there 6 logical CPs, but only 4 physical CPs? Curiosity of course, since I don't use VM. The difference is that z/VM will dispatch more virtual CPs _for one guest_ than are available to z/VM or even on the box. For example, you could have two CPs available to z/VM and define a guest with four virtual CPs. z/VM will dispatch all four of the guest's virtual CPs using only the two CPs available to it. You can't do that with PR/SM. (Probably don't want to anyway.) -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FICON tape drive?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey Deaver Sent: Wednesday, September 12, 2007 12:40 PM To: IBM-MAIN@BAMA.UA.EDU Subject: FICON tape drive? Anybody ever seen a stand alone FICON attached 3490 capable tape drive? Yes, I know it sounds crazy. I'm fairly certain they don't exist, but I need to know. Thanks. SNIP I think we have 4 of them (I assume you mean, not inside an ATL when you say stand alone, but discreet 3490 heads w/ w/o autoloader and otherwise manually controlled by an operator -- Me.). Regards, Steve Thompson -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA to IBM TCP Conversion
Chris,
Thanks for the information and document. I already had some of your
recommendations in place and I am still reviewing everything. There is one
thing that I would like to ask you about.
You quoted the IP Guide and said:
quote
Common INET physical file system (CINET PFS)
If you wish to run multiple z/OS Communications Server TCP/IP stacks
concurrently, you must use the Common INET (CINET) configuration. In this
configuration, up to a maximum of eight TCP/IP stacks can be active at any
time.
/quote
You may be sure that IBM means just the IBM-supplied software for creating
the appearance of an IP node and absolutely not software from any other
Tom, Dick or Harry!
Why don't you think I need a CINET environment if one of the stacks is
Interlink? It's true that the guide says z/OS CS but since I have used
Interlink for so long I tend to ignore when manuals say IBM TCP/IP - an IP
stack is an IP stack, right? (I know all stacks aren't exactly created equal,
but...) I have made several products work with Interlink when the doc only
mentioned IBM TCP/IP.
The OMVS proc has a steplib for Interlink and the BPX parm entry looks like:
SUBFILESYSTYPE NAME(TCPIPCA) /* Name of file system */
TYPE(CINET) /* Type matching Cinet's TYPE */
ENTRYPOINT(T010PFSA)/* Entry point of load module */
PARM('SYSID(ACSS)') /* SSID of CA TCPAccess stack */
When OMVS comes up, these msgs are displayed:
T01OE101I TCP/IP PFS Name:TCPIPCA Initialization Started
T01OE104I TCP/IP PFS Name:TCPIPCA Subtask:00AE76F8 Started
IEF196I T01OE104I TCP/IP PFS Name:TCPIPCA Subtask:00AE76F8 Started
T01OE102I TCP/IP PFS Name:TCPIPCA Using TCPaccess Subsystem Name:ACSS
T01OE115I TCP/IP PFS Name:TCPIPCA FILESYSTYPE PARM:
T01OE116I SYSID(ACSS)
T01OE103I TCP/IP PFS Name:TCPIPCA Initialization Complete
This may be a moot point anyway if everything checks out ok with IBM and I
can just drop CA. Whenever I get a chance I will try taking out the CA stuff
and see what happens to it with no OMVS. For now I am trying to not run the
CA stack at all. Also, you are correct in one of your posts that I am not
doing anything real complicated - everything is in 1 LPAR, no plex, etc.
Thanks for the help...
Robert
Confidentiality Notice: This e-mail message, including any attachments, is for
the sole use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concurrent Upgrade Puzzlement.
If I have a CEC with 4 GP CPUs and 2 LPARS, LPAR1 has 4 non-dedicated initial CPs and LPAR2 has 2 non-dedicated initial CPs, is not PRSM/LPAR virtualizing CPs, since there 6 logical CPs, but only 4 physical CPs? Curiosity of course, since I don't use VM. Terminology error on my part. What I meant was: Unlike VM, no single LPAR can have more logical CPs than there are physical CP's on the CEC. So, if you have 4 GP's, no LPAR can have more than 4 CP's defined to it. (You can, however, have RSVD CP's defined, so that you can add more LP's, if you dynamically add more GP's, without a POR or an IPL) It's been awhile, but VM used to allow a guest more 'active' CP's than were physically installed. This is what I meant by virtualisation of CP's. The terminology definitions have drifted in meaning over the last 20 years. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concurrent Upgrade Puzzlement.
On Wed, 12 Sep 2007 12:48:31 -0500, McKown, John wrote: From what I understand, PRSM calls these things logical CPs and assigns each LPAR a number of logical CPs. It then dispatches the logical CP on a physical CP. I don't know when PRSM assigns a logical CP to a physical CP. It may be at LPAR activation, or may be dynamic. A logical processor is not assigned to a physical processor. It is dispatched on a physical processor, and not necessarily the same one as it was dispatched on the last time. However, PR/SM does try to dispatch a logical processor on the same physical processor to improve the probability that there will still be useful L1 cache data. But within a single LPAR one physical CP will map to at most one logical CP. Therefore the number of logical CPs which may be assigned to an LPAR cannot exceed the number of physical CPs. Sounds logical, but since there is no real mapping of logical to physical processors, I'm pretty sure it's not correct. Someone please correct me if I am wrong, but as I understand it, processors are dispatched individually, not in groups. I see no reason why PR/SM can't support more logical processors for a partition than there are physical processors, though it would not be desirable to do so. It sounds to me as if this is actually what was happening in this case. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concurrent Upgrade Puzzlement.
I see no reason why PR/SM can't support more logical processors for a partition than there are physical processors It was a design decision, from the get go. MDF was designed the same way. I was a beta-tester of MDF in the mid-1980's, and participated in many NDA meetings for that. Also, attended many NDA's for PR/SM. The company, where I worked at the time, was an early adopter of PRSM. Both IBM and Amdahl were quick to point out the design decision, and stated that if you wanted to go the other way (more logical/image than physically install), use VM. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concurrent Upgrade Puzzlement.
From the PR/SM manual: LPs can be defined to have as many CPs as are present on the underlying MCM. Copyright IBM So Hal indeed has an anomaly (unless z/OS.e is more VM like than I thought.) He shows 3 CPs enabled from the service element. I will be interested to see if it will be fixed with an IPL, deactivate/activate of the LPAR, or other solution. I wonder if work is actually being dispatched on the fourth logical CP. Speaking of terminology changes over the years, LPs = Logical Partitions in the PR/SM manual, not Logical Processors. What ever happened to LPAR? Good grief! I must not be part of the trendy mainframe crowd anymore. ; ) Steve -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Wednesday, September 12, 2007 2:50 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Concurrent Upgrade Puzzlement. If I have a CEC with 4 GP CPUs and 2 LPARS, LPAR1 has 4 non-dedicated initial CPs and LPAR2 has 2 non-dedicated initial CPs, is not PRSM/LPAR virtualizing CPs, since there 6 logical CPs, but only 4 physical CPs? Curiosity of course, since I don't use VM. Terminology error on my part. What I meant was: Unlike VM, no single LPAR can have more logical CPs than there are physical CP's on the CEC. So, if you have 4 GP's, no LPAR can have more than 4 CP's defined to it. (You can, however, have RSVD CP's defined, so that you can add more LP's, if you dynamically add more GP's, without a POR or an IPL) It's been awhile, but VM used to allow a guest more 'active' CP's than were physically installed. This is what I meant by virtualisation of CP's. The terminology definitions have drifted in meaning over the last 20 years. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concurrent Upgrade Puzzlement.
On Wed, 12 Sep 2007 19:05:19 +, Ted MacNEIL wrote: I see no reason why PR/SM can't support more logical processors for a partition than there are physical processors It was a design decision, from the get go. MDF was designed the same way. I was a beta-tester of MDF in the mid-1980's, and participated in many NDA meetings for that. Ok, and I was a cross-trained Amdahl SE Specialist at the time. I was deeply involved it the 580, macrocode and MDF Also, attended many NDA's for PR/SM. The company, where I worked at the time, was an early adopter of PRSM. Both IBM and Amdahl were quick to point out the design decision, and stated that if you wanted to go the other way (more logical/image than physically install), use VM. True. That doesn't mean it can't be done. You can't define a partition with more active logical processors than there are on the box. Neither can you configure another one online when you already have as many as there are physical processors. That begs the question, though. How do you explain the facts as reported by Mr. Merritt? My suspicion is that PR/SM doesn't really care that much that he is left with four logical processors while funning on a box with only three CPs. I don't think I'd want to keep it running that way, but what else is PR/SM going to do? Stop dispatching on of the logical processors? And if so, what happens to the task that was running on it at the time? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concurrent Upgrade Puzzlement.
LPs can be defined to have as many CPs as are present on the underlying MCM. Even that is not precise. Especially these days, when each board is fully populated. You need to activate the PU's through micro-code. And, only those activated can be used, and set the limit per LPAR. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HTTP Server Abend
Matt, I would track open APAR OA22110 to get a better diagnostic IGW020I msg even I believe the SYSLOG should provide more info for this kind of LOAD failure. Regards Roland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FICON tape drive?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Thompson, Steve Sent: Wednesday, September 12, 2007 1:24 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FICON tape drive? SNIP Well, I got the wrong info. Something bothered me about what I was told and so I went and verified it, our 3490 units are through a converter box. So they aren't FICON or ESCON (to the purist) attached. Now, if all ya all will excuse me, I have to go to the laundry room to deposit the egg soaked clothing... Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FICON tape drive?
In a message dated 9/12/2007 4:07:33 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
Now, if all ya all will excuse me, I have to go to the laundry room to
deposit the egg soaked clothing...
I dunno, I google'd {FICON attached 3490} and came with several hits to
include Luminex and Bustech VTS and IBM 3590 running 3490 mode. Probably have
to
get an ISV to verify prices and specs.
** See what's new at http://www.aol.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concurrent Upgrade Puzzlement.
Stop dispatching on of the logical processors? And if so, what happens to the task that was running on it at the time? I always thought you had to configure the processor offline before you could remove it from the profile. In all the discussion, I missed whether that was done. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concurrent Upgrade Puzzlement.
No manual configuration or profile changes were made. Only the hardware microcode. I kind of hesitate to issue reconfiguration commands right now. This is our most loved LPAR. I have a PMR open with IBM. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Wednesday, September 12, 2007 4:33 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Concurrent Upgrade Puzzlement. Stop dispatching on of the logical processors? And if so, what happens to the task that was running on it at the time? I always thought you had to configure the processor offline before you could remove it from the profile. In all the discussion, I missed whether that was done. - Too busy driving to stop for gas! NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concurrent Upgrade Puzzlement.
No manual configuration or profile changes were made. Only the hardware microcode. Then, I really don't understand what kind of state you're in. I kind of hesitate to issue reconfiguration commands right now. This is our most loved LPAR. When we were GDPS testing, a few years ago, IBM was supplying the service support for the implementation. We are also using CUOD. The process was documented as: Start Up: 1. Perform the on-demand upgrade. 2. CONFIG the processors online on the required LPARs. 3. Start the appropriate start-up automation. Shut down: 1. Start the appropriate shut-down automation. 2. CONFIG the processors offline on the appropriate LPARs. 3. Downgrade the CUOD processors. These procedures came right out of IBM documentation, and are pretty straight forward. I have never taken the processors away from an image before CONFIGing them offline, first. I have no idea what state the LPAR would be in, in that case. I would hope that PRSM z/OS, together, would not allow it. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Call for Sessions for SHARE in Orlando
Fellow IBM-Main Members- Now that SHARE in San Diego is a fond memory, it is time to start planning for the upcoming winter SHARE conference. It will be held at the Coronado Springs Resort in Orlando, FL, on February 24th through 29th, 2007. The Enterprise Wide Capacity and Performance Project is now soliciting for Sessions. We are actively looking for Abstracts pertaining to Performance, Capacity Planning, Benchmarking, User Experiences, and zIIP zAAP Experiences. We may also schedule Sunday Sessions to offer Introductory and Basics Sessions for the zNextGen project. The themes for this Conference will be Virtualization, and The SOA Journey. Any appropriate sessions on these themes will also be considered. SHARE is an organization that is supported by volunteers. If you'd like the opportunity to share your experience at our next conference, please send your abstract for consideration to Tom Halinski ( mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]) or Norman Hollander ( mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]) by September 28, 2007. The actually scheduling process will take place in October, so please consider volunteering now. Norman Hollander, Project Manager EWCP Enterprise-Wide Capacity and Performance Project Office: +1 323-46-zNorm (323-469-6676) Cell: +1 323-351-3174 eMail: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] This eMail message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply eMail and destroy all copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concurrent Upgrade Puzzlement.
On Wed, 12 Sep 2007 22:46:30 +, Ted MacNEIL wrote: No manual configuration or profile changes were made. Only the hardware microcode. Then, I really don't understand what kind of state you're in. I kind of hesitate to issue reconfiguration commands right now. This is our most loved LPAR. snip! I have never taken the processors away from an image before CONFIGing them offline, first. I have no idea what state the LPAR would be in, in that case. I would hope that PRSM z/OS, together, would not allow it. CUOD is a completely different situation. Hal was doing a concurrent UPGRADE. The upgrade consisted of reducing the number of processors from four to three and increasing their speed. If the concurrent upgrade had required that the LPAR with four logical processors had required that one processor be CONFIGed offline first, that would hardly have been non-disruptive, would it? I'm not surprised that it worked as it did. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Call for Sessions for SHARE in Orlando
On Wed, 12 Sep 2007 16:11:53 -0700, Norman Hollander on h-WiZ.biz wrote: February 24th through 29th, 2007. The Enterprise Wide Capacity and Oops! Missed it. Sorry. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concurrent Upgrade Puzzlement.
If the concurrent upgrade had required that the LPAR with four logical processors had required that one processor be CONFIGed offline first, that would hardly have been non-disruptive, would it? CONFIG a processor offline is non-disruptive, except for a possible performance impact. But, I'm assuming you didn't do it during prime time. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PLPA and COMMON PAGESPACE Size
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 09/12/2007 12:46:24 PM: Mark Zelden wrote: ... I think the decision to remove suspend/resume was based on issues that kept cropping up with pav and paging. Must have been a fairly serious issue of some sort. Why else would they change the behavior via APAR and not on a release boundary? There is some prior discussion in the archives: http://bama.ua.edu/cgi-bin/wa?A2=ind0602L=ibm-mainP=R27468I=1X=- We had already been planning to remove ASM use of suspend/resume via the HyperPAV support APARs, since HyperPAV didn't mesh well with suspend resume. Then another problem cropped up with dynamic PAV and suspend/resume, and we did not have an elegant solution. Since we we going to be removing suspend/resume anyway, we simply removed it a little earlier. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Running with SQA/ESQA 100% CHECK
On Wed, 2007-09-12 at 08:42 +0200, Barbara Nitz wrote: And we installed the downloadable version before we migrated to 1.6, so we've been putting up with HC for a long time. This may have been my mistake as well. Left a very bitter taste. The shipped product is significantly better, but still has warts. I had a look at a default 1.7 install after my prior post. Still complains about the system console having; - routcde 11 - not enough routcde's (it's defined as routcde=ALL; customers choice) Various XCF complaints - in this case a base sysplex. Personally I don't think I should have to go in and tell component(s) this is *not* a parallel sysplex. It (H/C) should check the running system, not rely on a pile of parms to the checker itself. IMHO the over-rides should be for handling anomalies, not to (re-)define the system. For example GRS ought to be able to figure it out for itself that STAR really *isn't* the best option in a non-parallel sysplex. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
