Re: SYSTEM KEY Programming Was: IVSK and SPKA
IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 07/12/2015 09:40:25 PM: From: Walt Farrell walt.farr...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 07/12/2015 11:08 PM Subject: Re: SYSTEM KEY Programming Was: IVSK and SPKA Sent by: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Sun, 12 Jul 2015 17:34:41 -0400, Scott Ford idfzos...@gmail.com wrote: No sir, its subpool=231, linkage=system, thus supervisor state required From Authorized Assembler Services description of the STORAGE macro: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a4b1/ 11.1.1?SHELF=all13be9DT=20120813104512CASE= or http://preview.tinyurl.com/o3ca8au quote Environment: The requirements for the caller are: ... For LINKAGE=SYSTEM or LINKAGE=SVC: for all other subpools [Walt: that is, for subpools except 0-127, 131, or 132], one or more of the following: ° Supervisor state ° PSW key 0-7 ° APF-authorization. /quote -- Walt APF-authorization checking was added for STORAGE with LINKAGE=SYSTEM in z/OS 1.10. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSTEM KEY Programming Was: IVSK and SPKA
On Sun, 12 Jul 2015 20:42:19 +0300, Binyamin Dissen bdis...@dissensoftware.com wrote: On Sun, 12 Jul 2015 12:54:02 -0400 Scott Ford idfzos...@gmail.com wrote: :I have question then :I inherited some code..it's called passed a value for a storage obtain... :Before the obtain, they go into mode=sup, storage :obtain,length(value),sp=231,loc=any, then back into mode=prog. Is this the :old way of setting key zero or a piece of storage ? CSA allocations via the STORAGE macro requires supervisor state. If I've read the book correctly, PSW key 0-7 or APF authorization should also work. And if Scott's code doesn't already have one of those wouldn't the MODESET to supervisor state fail? -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSTEM KEY Programming Was: IVSK and SPKA
No sir, its subpool=231, linkage=system, thus supervisor state required Scott On Sun, Jul 12, 2015 at 5:19 PM, Walt Farrell walt.farr...@gmail.com wrote: On Sun, 12 Jul 2015 20:42:19 +0300, Binyamin Dissen bdis...@dissensoftware.com wrote: On Sun, 12 Jul 2015 12:54:02 -0400 Scott Ford idfzos...@gmail.com wrote: :I have question then :I inherited some code..it's called passed a value for a storage obtain... :Before the obtain, they go into mode=sup, storage :obtain,length(value),sp=231,loc=any, then back into mode=prog. Is this the :old way of setting key zero or a piece of storage ? CSA allocations via the STORAGE macro requires supervisor state. If I've read the book correctly, PSW key 0-7 or APF authorization should also work. And if Scott's code doesn't already have one of those wouldn't the MODESET to supervisor state fail? -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSTEM KEY Programming Was: IVSK and SPKA
Two threads in a couple of weeks re the inability of people to learn MVS principles properly these days. Terrible indictment of the OCO decision years ago that public lists like this are now the proxy mentor that some of us were fortunate enough to have had when we needed one. Enough from me - hooroo. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSTEM KEY Programming Was: IVSK and SPKA
On Sun, 12 Jul 2015 17:34:41 -0400, Scott Ford idfzos...@gmail.com wrote: No sir, its subpool=231, linkage=system, thus supervisor state required From Authorized Assembler Services description of the STORAGE macro: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a4b1/11.1.1?SHELF=all13be9DT=20120813104512CASE= or http://preview.tinyurl.com/o3ca8au quote Environment: The requirements for the caller are: ... For LINKAGE=SYSTEM or LINKAGE=SVC: for all other subpools [Walt: that is, for subpools except 0-127, 131, or 132], one or more of the following: ° Supervisor state ° PSW key 0-7 ° APF-authorization. /quote -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PAGE DS SLOTS TYPE75
Thanks Barry. for the archive: print PAGETYPE PAGEDSN to see that figures are for LOCAL/PLPA/COMMON the repeated lower #s were for PLPA COMMON. Cheers. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XCF HELP!
It may really be 'broke'. I'd open a sevcrit to get the CE's dispatched. In a message dated 7/12/2015 1:29:45 P.M. Central Daylight Time, pinnc...@rochester.rr.com writes: If that doesn't work, try CONFIG CHP OFF and ON (assuming that there are no other devices you need on that CHPID). I'm thinking either one or both of the varies may be required to clear the intervention. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSTEM KEY Programming Was: IVSK and SPKA
Rob. LOL !! ... My apologies and yes, IMS does indeed (and DB2) use key7. I don't have the specific posts at hand but, I'll try to find one or two that speaks of key2 usage by IMS and, if / when I do, I'll send it over.. Key9 is also used by CICS in certain circumstances (as an example, BSG type code and IIRC, debuggers). Kind Regards, Jim Thomas 617-233-4130 (mobile) 636-327-7333 (res / wrk) j...@thethomasresidence.us (pvt email) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Scott Sent: Saturday, July 11, 2015 5:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSTEM KEY Programming Was: IVSK and SPKA Jim, Yeah - perhaps I should have said well known IBM products. ISVs can and do use both key2 and key4 (myself included). I thought IMS was key7 along with MQ and DB2 For the archives, here is the current key usage of IBM software that I am aware of : 0Supervisor 1Job scheduler 3Availability manager 5Data management 6Communications (VTAM, TCP/IP) 7DB2, IMS and MQ 8,9V=V problem programs 10-15V=R problem programs -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Sent: Saturday, July 11, 2015 6:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSTEM KEY Programming Was: IVSK and SPKA Rob, Forgive me, I strongly agree and advocate what you've stated but Strobe runs (for the most part) in key 2. Further, key 2 used to be used by VSCR (in the good ol' days) but, IIRC, IMS is (or has) ramping up with key 2 usage. Worthless bit of trivia perhaps but .. just thought I'd put it out there. Kind Regards, Jim Thomas 617-233-4130 (mobile) 636-327-7333 (res / wrk) j...@thethomasresidence.us (pvt email) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Scott Sent: Saturday, July 11, 2015 4:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSTEM KEY Programming Was: IVSK and SPKA I spend quite a lot of time writing code for software products that have to do things beyond the scope of normal problem state. The problem with going to key0 is pretty much always not what you intended to do - but what happens when your code goes wrong (and everyone's code goes wrong) or when your caller passes you something bad by error or by design. This is why I avoid key0 as much as I possibly can - and the way to do that if you are writing system software is take advantage of a SCHEDxx PARMLIB setting and declare your server jobstep program as running in *another* system key. Of the remaining seven keys, two of them (key2 and key4) seem to not be used by any well-known current software products. Once your server jobstep program is running non-key0 system key, most of the authorized services can be called without having to switch to key0 - and this can only be good news for your code and your customers systems. Client code, of course, should always run in problem state and use a well-defined and secure method to communicate to your server (for example a space-switch PC). Anyone writing authorized code should read and understand the system integrity issues and there are some very good presentations given by Karl Schmitz out there on the internet. I think that what is lacking in the Authorized Programming manuals is a really well written example of how to implement a client server application. While the descriptions of the services and their parameters are well documented, a decent working example would really help the community understand the issues and prevent the proliferation of public domain code with (how shall I put it?) non-optimal designs. Rob Scott Principal Software Engineer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Blaicher, Christopher Y. Sent: Saturday, July 11, 2015 5:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSTEM KEY Programming Was: IVSK and SPKA Interesting question that I haven't really thought too much about because when I have to do something special, generally it is key 0. With that said, in a previous life I wrote utilities for DB2. For those we got into key 7 as the default because that is what DB2 runs in. There are ways to attach a task in a key other than 8, but that is another topic. In the processing of the utilities we still had to get to key 0 and get back, so it was no different, except that the base key was different. In the Diagnosis Manual, in the Storage section, there is a brief list of the storage
Re: SYSTEM KEY Programming Was: IVSK and SPKA
If it still exists, IBM Prolog for 370, the MVS version (as opposed to the original which ran under VM/CMS) uses keys beyond 9. In fact, we were in the middle of Beta tests when I had to go back and change code from using KEY9 because of what CICS had just done (circa 1991). Apparently someone doing testing of Prolog with CICS found that our code was causing CICS a migraine. And hasn't support for DAT OFF (V=R) been dropped? Only the DAT OFF nucleus actually runs DAT OFF now? Regards, Steve Thompson On 07/11/2015 06:47 PM, Rob Scott wrote: Jim, Yeah - perhaps I should have said well known IBM products. ISVs can and do use both key2 and key4 (myself included). I thought IMS was key7 along with MQ and DB2 For the archives, here is the current key usage of IBM software that I am aware of : 0Supervisor 1Job scheduler 3Availability manager 5Data management 6Communications (VTAM, TCP/IP) 7DB2, IMS and MQ 8,9V=V problem programs 10-15V=R problem programs SNIPPAGE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
XCF HELP!
For the first time ever, when shutting down an LPAR in a sysplex, I forgot to issue the V XCF,lparname,OFF! Now, I can't get that LPAR to join the sysplex. Luckily, the important LPAR is up. The second LPAR is supposed to be in a sysplex and I am the only one using it. It currently has z/os 2.1 running on it. I keep getting error: IXC409D SIGNAL PATHS BETWEEN sysname1 AND sysname2 ARE LOST. REPLY RETRY OR SYSNAME=SYSNAME OF THE SYSTEM TO BE REMOVED. I've tried to RETRY and to give it SYSNAME that's down, but nothing helps! I'm sure there's some SETXCF command I need to do, but I've never done this before so I'm unsure. I put a question in to IBM but won't hear back till tomorrow. It would be nice if someone is out there and can help me!! Anne D. Crabtree System Programmer WV Office of Technology Data Center 1900 Kanawha Blvd East Bldg 6, Room B-110 Charleston, WV 25305 (304)957-8292 (304)558-1441 fax -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSTEM KEY Programming Was: IVSK and SPKA
In one word - carefully. Treat every instruction that you execute in key0 as being a candidate to cause the next unscheduled IPL. I would advise to straddle the code that *actually* requires key0 with a save current key, go to key0 and then a restore saved key sequence - I typically put this in a macro. Make sure that your recovery routines are aware that this code can key-switch and let them restore the environment cleanly. Always be aware of the key of your caller and use it to read and write data owned by them - MVCDK and MVCSK are your friends (also good candidates for macro encapsulation). SAF protect any services that you provide to problem state callers. Never return to your caller with any changes to their execution authority. Test your code (on a test system) with the dirty regs and dirty getmain/freemain diagnostic traps. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Sunday, July 12, 2015 11:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSTEM KEY Programming Was: IVSK and SPKA With all the discussion, what's the safest way to use key=0 , if it is required ? Scott On Sunday, July 12, 2015, Tom Marchant 000a2a8c2020-dmarc-requ...@listserv.ua.edu wrote: On Sun, 12 Jul 2015 11:29:01 -0400, Steve Thompson wrote: And hasn't support for DAT OFF (V=R) been dropped? Only the DAT OFF nucleus actually runs DAT OFF now? V=R doesn't mean DAT off. Just that virtual addresses map to the same real addresses. I've never seen anything that ran V=R, but ADDRSPC=REAL is still documented. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu javascript:; with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321 Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSTEM KEY Programming Was: IVSK and SPKA
As little as possible. g Don't leave yourself in key 0 because you're going to need it again in 20 instructions. Get in and get out. Five years from now some other programmer may introduce a branch out in the middle of your 20 instructions, with potentially unhappy results. Comment the code to help reduce the above possibility: *** Entering key 0 * *** Exiting key 0 ** Desk check, desk check, desk check. Don't use key 0 simply because it is easier or simpler to code than using some particular non-8 key. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Sunday, July 12, 2015 8:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSTEM KEY Programming Was: IVSK and SPKA With all the discussion, what's the safest way to use key=0 , if it is required ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSTEM KEY Programming Was: IVSK and SPKA
Binyamin, I thought that might be the case. Todah habah Regards, Scott On Sunday, July 12, 2015, Binyamin Dissen bdis...@dissensoftware.com wrote: On Sun, 12 Jul 2015 12:54:02 -0400 Scott Ford idfzos...@gmail.com javascript:; wrote: :I have question then :I inherited some code..it's called passed a value for a storage obtain... :Before the obtain, they go into mode=sup, storage :obtain,length(value),sp=231,loc=any, then back into mode=prog. Is this the :old way of setting key zero or a piece of storage ? CSA allocations via the STORAGE macro requires supervisor state. -- Binyamin Dissen bdis...@dissensoftware.com javascript:; http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu javascript:; with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSTEM KEY Programming Was: IVSK and SPKA
On Sun, 12 Jul 2015 11:29:01 -0400, Steve Thompson wrote: And hasn't support for DAT OFF (V=R) been dropped? Only the DAT OFF nucleus actually runs DAT OFF now? V=R doesn't mean DAT off. Just that virtual addresses map to the same real addresses. I've never seen anything that ran V=R, but ADDRSPC=REAL is still documented. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSTEM KEY Programming Was: IVSK and SPKA
I have question then I inherited some code..it's called passed a value for a storage obtain... Before the obtain, they go into mode=sup, storage obtain,length(value),sp=231,loc=any, then back into mode=prog. Is this the old way of setting key zero or a piece of storage ? Scott On Sunday, July 12, 2015, Rob Scott rsc...@rocketsoftware.com wrote: In one word - carefully. Treat every instruction that you execute in key0 as being a candidate to cause the next unscheduled IPL. I would advise to straddle the code that *actually* requires key0 with a save current key, go to key0 and then a restore saved key sequence - I typically put this in a macro. Make sure that your recovery routines are aware that this code can key-switch and let them restore the environment cleanly. Always be aware of the key of your caller and use it to read and write data owned by them - MVCDK and MVCSK are your friends (also good candidates for macro encapsulation). SAF protect any services that you provide to problem state callers. Never return to your caller with any changes to their execution authority. Test your code (on a test system) with the dirty regs and dirty getmain/freemain diagnostic traps. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU javascript:;] On Behalf Of Scott Ford Sent: Sunday, July 12, 2015 11:57 AM To: IBM-MAIN@LISTSERV.UA.EDU javascript:; Subject: Re: SYSTEM KEY Programming Was: IVSK and SPKA With all the discussion, what's the safest way to use key=0 , if it is required ? Scott On Sunday, July 12, 2015, Tom Marchant 000a2a8c2020-dmarc-requ...@listserv.ua.edu javascript:; wrote: On Sun, 12 Jul 2015 11:29:01 -0400, Steve Thompson wrote: And hasn't support for DAT OFF (V=R) been dropped? Only the DAT OFF nucleus actually runs DAT OFF now? V=R doesn't mean DAT off. Just that virtual addresses map to the same real addresses. I've never seen anything that ran V=R, but ADDRSPC=REAL is still documented. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu javascript:; javascript:; with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu javascript:; with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321 Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com javascript:; Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu javascript:; with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XCF HELP!
Doesn't help to system reset, then respond DOWN... I still crash when trying to activate. Anne D. Crabtree System Programmer WV Office of Technology Data Center 1900 Kanawha Blvd East Bldg 6, Room B-110 Charleston, WV 25305 (304)957-8292 (304)558-1441 fax -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Bishop (TEMA TPC) Sent: Sunday, July 12, 2015 12:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XCF HELP! Quickref says that you can reply SYSNAME=sysname,DOWN AFTER you have put the down'ed LPAR through a system reset. Thanks Bill Bishop Specialist Mainframe Support Group Server Development Support Toyota Motor Engineering Manufacturing North America, Inc. bill.bis...@tema.toyota.com (502) 570-6143 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Crabtree, Anne D Sent: Sunday, July 12, 2015 12:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: XCF HELP! For the first time ever, when shutting down an LPAR in a sysplex, I forgot to issue the V XCF,lparname,OFF! Now, I can't get that LPAR to join the sysplex. Luckily, the important LPAR is up. The second LPAR is supposed to be in a sysplex and I am the only one using it. It currently has z/os 2.1 running on it. I keep getting error: IXC409D SIGNAL PATHS BETWEEN sysname1 AND sysname2 ARE LOST. REPLY RETRY OR SYSNAME=SYSNAME OF THE SYSTEM TO BE REMOVED. I've tried to RETRY and to give it SYSNAME that's down, but nothing helps! I'm sure there's some SETXCF command I need to do, but I've never done this before so I'm unsure. I put a question in to IBM but won't hear back till tomorrow. It would be nice if someone is out there and can help me!! Anne D. Crabtree System Programmer WV Office of Technology Data Center 1900 Kanawha Blvd East Bldg 6, Room B-110 Charleston, WV 25305 (304)957-8292 (304)558-1441 fax -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XCF HELP!
IXC466I INBOUND SIGNAL CONNECTIVITY ESTABLISHED WITH SYSTEM IPO2 245 VIA DEVICE 0342 WHICH IS CONNECTED TO DEVICE 0412 IXC466I OUTBOUND SIGNAL CONNECTIVITY ESTABLISHED WITH SYSTEM IPO2 246 VIA DEVICE 0343 WHICH IS CONNECTED TO DEVICE 0413 IXC466I INBOUND SIGNAL CONNECTIVITY ESTABLISHED WITH SYSTEM IPO2 247 VIA DEVICE 0340 WHICH IS CONNECTED TO DEVICE 0410 IXC466I OUTBOUND SIGNAL CONNECTIVITY ESTABLISHED WITH SYSTEM IPO2 248 VIA DEVICE 0341 WHICH IS CONNECTED TO DEVICE 0411 PXM4704 XMANAGER PLEXGRPX GRP= MEM= PXM4704 XMANAGER PLEXGRPX GRP= MEM= PXM4705 XMANAGER PLEXGRPX NEW=00 OLD=00 TYPE=0B PXM4705 XMANAGER PLEXGRPX NEW=00 OLD=00 TYPE=0B PXM4704 XMANAGER PLEXGRPX GRP= MEM= PXM4705 XMANAGER PLEXGRPX NEW=00 OLD=00 TYPE=0B ISG011I SYSTEM IPO2 - JOINING GRS COMPLEX IXC467I RESTARTING PATHIN DEVICE 0340 256 USED TO COMMUNICATE WITH SYSTEM IPO2 RSN: INTERVENTION REQUIRED IXC467I RESTARTING PATHIN DEVICE 0342 257 USED TO COMMUNICATE WITH SYSTEM IPO2 RSN: INTERVENTION REQUIRED IXC467I RESTARTING PATHOUT DEVICE 0341 258 USED TO COMMUNICATE WITH SYSTEM IPO2 RSN: INTERVENTION REQUIRED IXC467I RESTARTING PATHOUT DEVICE 0343 260 USED TO COMMUNICATE WITH SYSTEM IPO2 RSN: INTERVENTION REQUIRED *18 IXC409D SIGNAL PATHS BETWEEN IPO2 AND IPO1 ARE LOST. REPLY RETRY OR SYSNAME=SYSNAME OF THE SYSTEM TO BE REMOVED. CTM916W PROGRAM CTMCKP WAITING FOR CTM.CKPT 10 SEC CTM916W PROGRAM CTMCKP WAITING FOR CTM.CKPT 70 SEC R 18,SYSNAME=IPO2,DOWN IEE600I REPLY TO 18 IS;SYSNAME=IPO2,DOWN *19 IXC417D CONFIRM REQUEST TO REMOVE IPO2 FROM THE SYSPLEX. REPLY SYSNAME=IPO2 TO REMOVE IPO2 OR C TO CANCEL. R 19,SYSNAME=IPO2 IEE600I REPLY TO 19 IS;SYSNAME=IPO2 IXC101I SYSPLEX PARTITIONING IN PROGRESS FOR IPO2 REQUESTED BY 270 XCFAS. REASON: SYSTEM ENTERED WAIT STATE *ISG178E GLOBAL RESOURCE SERIALIZATION HAS BEEN DISRUPTED. GLOBAL RESOURCE REQUESTORS WILL BE SUSPENDED. IXC808I ELEMENTS FROM TERMINATED SYSTEM IPO2 WERE NOT PROCESSED BY 272 THIS SYSTEM. ARM COUPLE DATA SET IS NOT AVAILABLE TO THIS SYSTEM. IXC105I SYSPLEX PARTITIONING HAS COMPLETED FOR IPO2 273 - PRIMARY REASON: SYSTEM ENTERED WAIT STATE - REASON FLAGS: 22 ISG179I SYSTEM IPO1 INITIATED AUTO RESTART PROCESSING. ISG175I SYSTEM IPO1 RESTARTED GLOBAL RESOURCE SERIALIZATION. ISG011I SYSTEM IPO2 - BEING PURGED FROM GRS COMPLEX ISG013I SYSTEM IPO2 - PURGED FROM GRS COMPLEX But if I try to activate IPO2 after this, I get same IXC409I message. Anne D. Crabtree System Programmer WV Office of Technology Data Center 1900 Kanawha Blvd East Bldg 6, Room B-110 Charleston, WV 25305 (304)957-8292 (304)558-1441 fax -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Sunday, July 12, 2015 12:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XCF HELP! A question or two. Did you wait long enough when the IXC409D was produced? The system continues and will process the response when entered. Cross-system coupling facility (XCF) tries to restart the signaling path. If XCF restores connectivity, the message will be deleted before it is answered. If XCF cannot fully restore connectivity between the two systems, the system issues message IXC409D again. Did you see any other IXC message? IXC402D or IXC102A, XCF signaling connectivity to the removed system is no longer relevant and the system deletes the message. Could you post the RSP to the IXC409D you entered? And any additional messages that occurred after that? Not sure what is going on at this point. So, the worst case scenario would be
Re: SYSTEM KEY Programming Was: IVSK and SPKA
With all the discussion, what's the safest way to use key=0 , if it is required ? Scott On Sunday, July 12, 2015, Tom Marchant 000a2a8c2020-dmarc-requ...@listserv.ua.edu wrote: On Sun, 12 Jul 2015 11:29:01 -0400, Steve Thompson wrote: And hasn't support for DAT OFF (V=R) been dropped? Only the DAT OFF nucleus actually runs DAT OFF now? V=R doesn't mean DAT off. Just that virtual addresses map to the same real addresses. I've never seen anything that ran V=R, but ADDRSPC=REAL is still documented. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu javascript:; with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XCF HELP!
A question or two. Did you wait long enough when the IXC409D was produced? The system continues and will process the response when entered. Cross-system coupling facility (XCF) tries to restart the signaling path. If XCF restores connectivity, the message will be deleted before it is answered. If XCF cannot fully restore connectivity between the two systems, the system issues message IXC409D again. Did you see any other IXC message? IXC402D or IXC102A, XCF signaling connectivity to the removed system is no longer relevant and the system deletes the message. Could you post the RSP to the IXC409D you entered? And any additional messages that occurred after that? Not sure what is going on at this point. So, the worst case scenario would be a sysplex wide COLD start. All LPARs down, then one up with INITIAL, the rest JOIN. But that is not necessarily what is needed, just what might be the very worst thing that might need to be done. Nice webpage with XCF Commands summary http://www.oocities.org/smtwango/MAINFRAME/MFCOMMANDS/sysplexcmd.html Thanks Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Crabtree, Anne D Sent: Sunday, July 12, 2015 9:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: XCF HELP! For the first time ever, when shutting down an LPAR in a sysplex, I forgot to issue the V XCF,lparname,OFF! Now, I can't get that LPAR to join the sysplex. Luckily, the important LPAR is up. The second LPAR is supposed to be in a sysplex and I am the only one using it. It currently has z/os 2.1 running on it. I keep getting error: IXC409D SIGNAL PATHS BETWEEN sysname1 AND sysname2 ARE LOST. REPLY RETRY OR SYSNAME=SYSNAME OF THE SYSTEM TO BE REMOVED. I've tried to RETRY and to give it SYSNAME that's down, but nothing helps! I'm sure there's some SETXCF command I need to do, but I've never done this before so I'm unsure. I put a question in to IBM but won't hear back till tomorrow. It would be nice if someone is out there and can help me!! Anne D. Crabtree System Programmer WV Office of Technology Data Center 1900 Kanawha Blvd East Bldg 6, Room B-110 Charleston, WV 25305 (304)957-8292 (304)558-1441 fax -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XCF HELP!
On 7/12/2015 12:51 PM, Crabtree, Anne D wrote: IXC466I INBOUND SIGNAL CONNECTIVITY ESTABLISHED WITH SYSTEM IPO2 245 VIA DEVICE 0342 WHICH IS CONNECTED TO DEVICE 0412 IXC466I OUTBOUND SIGNAL CONNECTIVITY ESTABLISHED WITH SYSTEM IPO2 246 VIA DEVICE 0343 WHICH IS CONNECTED TO DEVICE 0413 IXC466I INBOUND SIGNAL CONNECTIVITY ESTABLISHED WITH SYSTEM IPO2 247 VIA DEVICE 0340 WHICH IS CONNECTED TO DEVICE 0410 IXC466I OUTBOUND SIGNAL CONNECTIVITY ESTABLISHED WITH SYSTEM IPO2 248 VIA DEVICE 0341 WHICH IS CONNECTED TO DEVICE 0411 PXM4704 XMANAGER PLEXGRPX GRP= MEM= PXM4704 XMANAGER PLEXGRPX GRP= MEM= PXM4705 XMANAGER PLEXGRPX NEW=00 OLD=00 TYPE=0B PXM4705 XMANAGER PLEXGRPX NEW=00 OLD=00 TYPE=0B PXM4704 XMANAGER PLEXGRPX GRP= MEM= PXM4705 XMANAGER PLEXGRPX NEW=00 OLD=00 TYPE=0B ISG011I SYSTEM IPO2 - JOINING GRS COMPLEX IXC467I RESTARTING PATHIN DEVICE 0340 256 USED TO COMMUNICATE WITH SYSTEM IPO2 RSN: INTERVENTION REQUIRED IXC467I RESTARTING PATHIN DEVICE 0342 257 USED TO COMMUNICATE WITH SYSTEM IPO2 RSN: INTERVENTION REQUIRED IXC467I RESTARTING PATHOUT DEVICE 0341 258 USED TO COMMUNICATE WITH SYSTEM IPO2 RSN: INTERVENTION REQUIRED IXC467I RESTARTING PATHOUT DEVICE 0343 260 USED TO COMMUNICATE WITH SYSTEM IPO2 RSN: INTERVENTION REQUIRED *18 IXC409D SIGNAL PATHS BETWEEN IPO2 AND IPO1 ARE LOST. REPLY RETRY OR SYSNAME=SYSNAME OF THE SYSTEM TO BE REMOVED. CTM916W PROGRAM CTMCKP WAITING FOR CTM.CKPT 10 SEC CTM916W PROGRAM CTMCKP WAITING FOR CTM.CKPT 70 SEC R 18,SYSNAME=IPO2,DOWN IEE600I REPLY TO 18 IS;SYSNAME=IPO2,DOWN *19 IXC417D CONFIRM REQUEST TO REMOVE IPO2 FROM THE SYSPLEX. REPLY SYSNAME=IPO2 TO REMOVE IPO2 OR C TO CANCEL. R 19,SYSNAME=IPO2 IEE600I REPLY TO 19 IS;SYSNAME=IPO2 IXC101I SYSPLEX PARTITIONING IN PROGRESS FOR IPO2 REQUESTED BY 270 XCFAS. REASON: SYSTEM ENTERED WAIT STATE *ISG178E GLOBAL RESOURCE SERIALIZATION HAS BEEN DISRUPTED. GLOBAL RESOURCE REQUESTORS WILL BE SUSPENDED. IXC808I ELEMENTS FROM TERMINATED SYSTEM IPO2 WERE NOT PROCESSED BY 272 THIS SYSTEM. ARM COUPLE DATA SET IS NOT AVAILABLE TO THIS SYSTEM. IXC105I SYSPLEX PARTITIONING HAS COMPLETED FOR IPO2 273 - PRIMARY REASON: SYSTEM ENTERED WAIT STATE - REASON FLAGS: 22 ISG179I SYSTEM IPO1 INITIATED AUTO RESTART PROCESSING. ISG175I SYSTEM IPO1 RESTARTED GLOBAL RESOURCE SERIALIZATION. ISG011I SYSTEM IPO2 - BEING PURGED FROM GRS COMPLEX ISG013I SYSTEM IPO2 - PURGED FROM GRS COMPLEX Anne, I would try to VARY 0340-0343,OFFLINE to both systems, then VARY ONLINE. If that doesn't work, try CONFIG CHP OFF and ON (assuming that there are no other devices you need on that CHPID). I'm thinking either one or both of the varies may be required to clear the intervention. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HMIGRATE vs. ENQ
On Sat, 11 Jul 2015 21:26:56 -0400, Robert A. Rosenberg wrote: My suggestion was to the question of how to insure the dataset was still ENQ'ed until job end not how to do an early DEQ while the job was still running. Your suggestion does not address the problem with I opened the thread; it could only aggravate it. Others had hijacked the thread and you were answering them, not me. In fact, I submitted a batch job: //STEP1 IEFBR14 DISP=OLD //STEP2 IKJEFT01 HMIGRATE STEP1 waited for several hours for all the Browsers to log off. At that point, by good fortune, there were no remaining ENQs and HMIGRATE succeeded. If there had been further ENQs (I can't control this) HMIGRATE would have failed. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSTEM KEY Programming Was: IVSK and SPKA
On Sun, 12 Jul 2015 01:26:44 -0500, Shane Ginnane wrote: Two threads in a couple of weeks re the inability of people to learn MVS principles properly these days. Terrible indictment of the OCO decision years ago that public lists like this are now the proxy mentor that some of us were fortunate enough to have had when we needed one. Enough from me - hooroo. That edge can cut in both directions. Conversely, any programmer able to read the source code is likely to feel entitled and competent to modify it. I am not an advocate of OCO; I prefer other controls. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XCF HELP!
Tried that. Still get message. Will try again. Anne D. Crabtree System Programmer WV Office of Technology Data Center 1900 Kanawha Blvd East Bldg 6, Room B-110 Charleston, WV 25305 (304)957-8292 (304)558-1441 fax -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Bishop (TEMA TPC) Sent: Sunday, July 12, 2015 12:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XCF HELP! Quickref says that you can reply SYSNAME=sysname,DOWN AFTER you have put the down'ed LPAR through a system reset. Thanks Bill Bishop Specialist Mainframe Support Group Server Development Support Toyota Motor Engineering Manufacturing North America, Inc. bill.bis...@tema.toyota.com (502) 570-6143 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Crabtree, Anne D Sent: Sunday, July 12, 2015 12:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: XCF HELP! For the first time ever, when shutting down an LPAR in a sysplex, I forgot to issue the V XCF,lparname,OFF! Now, I can't get that LPAR to join the sysplex. Luckily, the important LPAR is up. The second LPAR is supposed to be in a sysplex and I am the only one using it. It currently has z/os 2.1 running on it. I keep getting error: IXC409D SIGNAL PATHS BETWEEN sysname1 AND sysname2 ARE LOST. REPLY RETRY OR SYSNAME=SYSNAME OF THE SYSTEM TO BE REMOVED. I've tried to RETRY and to give it SYSNAME that's down, but nothing helps! I'm sure there's some SETXCF command I need to do, but I've never done this before so I'm unsure. I put a question in to IBM but won't hear back till tomorrow. It would be nice if someone is out there and can help me!! Anne D. Crabtree System Programmer WV Office of Technology Data Center 1900 Kanawha Blvd East Bldg 6, Room B-110 Charleston, WV 25305 (304)957-8292 (304)558-1441 fax -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XCF HELP!
Quickref says that you can reply SYSNAME=sysname,DOWN AFTER you have put the down'ed LPAR through a system reset. Thanks Bill Bishop Specialist Mainframe Support Group Server Development Support Toyota Motor Engineering Manufacturing North America, Inc. bill.bis...@tema.toyota.com (502) 570-6143 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Crabtree, Anne D Sent: Sunday, July 12, 2015 12:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: XCF HELP! For the first time ever, when shutting down an LPAR in a sysplex, I forgot to issue the V XCF,lparname,OFF! Now, I can't get that LPAR to join the sysplex. Luckily, the important LPAR is up. The second LPAR is supposed to be in a sysplex and I am the only one using it. It currently has z/os 2.1 running on it. I keep getting error: IXC409D SIGNAL PATHS BETWEEN sysname1 AND sysname2 ARE LOST. REPLY RETRY OR SYSNAME=SYSNAME OF THE SYSTEM TO BE REMOVED. I've tried to RETRY and to give it SYSNAME that's down, but nothing helps! I'm sure there's some SETXCF command I need to do, but I've never done this before so I'm unsure. I put a question in to IBM but won't hear back till tomorrow. It would be nice if someone is out there and can help me!! Anne D. Crabtree System Programmer WV Office of Technology Data Center 1900 Kanawha Blvd East Bldg 6, Room B-110 Charleston, WV 25305 (304)957-8292 (304)558-1441 fax -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSTEM KEY Programming Was: IVSK and SPKA
On Sun, 12 Jul 2015 12:54:02 -0400 Scott Ford idfzos...@gmail.com wrote: :I have question then :I inherited some code..it's called passed a value for a storage obtain... :Before the obtain, they go into mode=sup, storage :obtain,length(value),sp=231,loc=any, then back into mode=prog. Is this the :old way of setting key zero or a piece of storage ? CSA allocations via the STORAGE macro requires supervisor state. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XCF HELP!
Ma'am, I believe that XCF / GRS are having problems with your CDS's and or, perhaps even alternate CDS's. I suggest checking XCF and GRS on all systems while this is in progress, with commands such as D XCF,S,ALL and D GRS to find their status. Please check for INACTIVE and or QUIESCE'd paths .. if this is the case .. you might have to issue PATHIN / OUT to recover. XCF has to be has to be able to signal other images. If you find problematic paths... please give GRS enough time (I usually ask that you give it at least ten to fifteen minutes ... just to be on the safe side) to try and recover. If you still see GRS INACTIVE or QUIESCE'd status thereafter, try to QUIESCE the 'dead' system (IPO2 in this instance I think). If the above is unsuccessful, try to SETXCF STOP / START POLICY. Kind Regards, Jim Thomas 617-233-4130 (mobile) 636-327-7333 (res / wrk) j...@thethomasresidence.us (pvt email) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Crabtree, Anne D Sent: Sunday, July 12, 2015 11:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XCF HELP! IXC466I INBOUND SIGNAL CONNECTIVITY ESTABLISHED WITH SYSTEM IPO2 245 VIA DEVICE 0342 WHICH IS CONNECTED TO DEVICE 0412 IXC466I OUTBOUND SIGNAL CONNECTIVITY ESTABLISHED WITH SYSTEM IPO2 246 VIA DEVICE 0343 WHICH IS CONNECTED TO DEVICE 0413 IXC466I INBOUND SIGNAL CONNECTIVITY ESTABLISHED WITH SYSTEM IPO2 247 VIA DEVICE 0340 WHICH IS CONNECTED TO DEVICE 0410 IXC466I OUTBOUND SIGNAL CONNECTIVITY ESTABLISHED WITH SYSTEM IPO2 248 VIA DEVICE 0341 WHICH IS CONNECTED TO DEVICE 0411 PXM4704 XMANAGER PLEXGRPX GRP= MEM= PXM4704 XMANAGER PLEXGRPX GRP= MEM= PXM4705 XMANAGER PLEXGRPX NEW=00 OLD=00 TYPE=0B PXM4705 XMANAGER PLEXGRPX NEW=00 OLD=00 TYPE=0B PXM4704 XMANAGER PLEXGRPX GRP= MEM= PXM4705 XMANAGER PLEXGRPX NEW=00 OLD=00 TYPE=0B ISG011I SYSTEM IPO2 - JOINING GRS COMPLEX IXC467I RESTARTING PATHIN DEVICE 0340 256 USED TO COMMUNICATE WITH SYSTEM IPO2 RSN: INTERVENTION REQUIRED IXC467I RESTARTING PATHIN DEVICE 0342 257 USED TO COMMUNICATE WITH SYSTEM IPO2 RSN: INTERVENTION REQUIRED IXC467I RESTARTING PATHOUT DEVICE 0341 258 USED TO COMMUNICATE WITH SYSTEM IPO2 RSN: INTERVENTION REQUIRED IXC467I RESTARTING PATHOUT DEVICE 0343 260 USED TO COMMUNICATE WITH SYSTEM IPO2 RSN: INTERVENTION REQUIRED *18 IXC409D SIGNAL PATHS BETWEEN IPO2 AND IPO1 ARE LOST. REPLY RETRY OR SYSNAME=SYSNAME OF THE SYSTEM TO BE REMOVED. CTM916W PROGRAM CTMCKP WAITING FOR CTM.CKPT 10 SEC CTM916W PROGRAM CTMCKP WAITING FOR CTM.CKPT 70 SEC R 18,SYSNAME=IPO2,DOWN IEE600I REPLY TO 18 IS;SYSNAME=IPO2,DOWN *19 IXC417D CONFIRM REQUEST TO REMOVE IPO2 FROM THE SYSPLEX. REPLY SYSNAME=IPO2 TO REMOVE IPO2 OR C TO CANCEL. R 19,SYSNAME=IPO2 IEE600I REPLY TO 19 IS;SYSNAME=IPO2 IXC101I SYSPLEX PARTITIONING IN PROGRESS FOR IPO2 REQUESTED BY 270 XCFAS. REASON: SYSTEM ENTERED WAIT STATE *ISG178E GLOBAL RESOURCE SERIALIZATION HAS BEEN DISRUPTED. GLOBAL RESOURCE REQUESTORS WILL BE SUSPENDED. IXC808I ELEMENTS FROM TERMINATED SYSTEM IPO2 WERE NOT PROCESSED BY 272 THIS SYSTEM. ARM COUPLE DATA SET IS NOT AVAILABLE TO THIS SYSTEM. IXC105I SYSPLEX PARTITIONING HAS COMPLETED FOR IPO2 273 - PRIMARY REASON: SYSTEM ENTERED WAIT STATE - REASON FLAGS: 22 ISG179I SYSTEM IPO1 INITIATED AUTO RESTART PROCESSING. ISG175I SYSTEM IPO1 RESTARTED GLOBAL RESOURCE SERIALIZATION. ISG011I SYSTEM IPO2 - BEING PURGED FROM GRS COMPLEX ISG013I SYSTEM IPO2 - PURGED FROM GRS COMPLEX
