Re: Sending z/OS Events to Windows Server
There are a number of commercial products that will send z/OS operational and security events to Linux or Windows. I am, ahem, the principal author of one: https://correlog.com/mainframe-security-solutions/zdefender-for-zos/ There are a number of competitive products but I'll let you do your own Google searches. The SMF exits could be a starting point but they are not for the feint-hearted. Cross-memory, locks, SRB, Key 0, that sort of thing. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieaa800/condiscon.htm A better starting point if you wanted to roll your own is "SMF log streams." More of a problem state, get-a-record sort of interface. You might also take a look at IBM Common Data Provider. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Roberts Sent: Tuesday, October 9, 2018 3:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Sending z/OS Events to Windows Server I have a need to recognize certain events (creation of a file, completion of a JOB, etc) and send basic information about each event to a Windows process near real-time. The Windows process would be a RESTful web server deployed on the Intranet alongside the z/OS box. I have been out of the SYSPROG loop for quite a while, but I seem to recall that the SMF exits are a good place to detect these events. But I know that the SMF exits can't do anything involving a WAIT, so the only thing the exit could do would be to post the information to another address space cross-memory. That address space (STARTED task?) could then act as a HTTPS client and send the data to the outboard server. I have been reading about the "z/OS Client Web Enablement Toolkit". Would this work for the HTTPS client? Whatever I create I need it to work in a vanilla z/OS environment V2.1 or after (no CICS etc.). Does this sound like I am on track? Or is there a better way? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Sending z/OS Events to Windows Server
I have a need to recognize certain events (creation of a file, completion of a JOB, etc) and send basic information about each event to a Windows process near real-time. The Windows process would be a RESTful web server deployed on the Intranet alongside the z/OS box. I have been out of the SYSPROG loop for quite a while, but I seem to recall that the SMF exits are a good place to detect these events. But I know that the SMF exits can't do anything involving a WAIT, so the only thing the exit could do would be to post the information to another address space cross-memory. That address space (STARTED task?) could then act as a HTTPS client and send the data to the outboard server. I have been reading about the "z/OS Client Web Enablement Toolkit". Would this work for the HTTPS client? Whatever I create I need it to work in a vanilla z/OS environment V2.1 or after (no CICS etc.). Does this sound like I am on track? Or is there a better way? Note: only events for selected files/jobs would be transmitted. Files would need to match a list of patterns, jobs to match a list of USERS. So it would not be a high volume interface. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBMLink down since at least yesterday; Granular APAR search also dead
Honest Abe got shot. I should be happy with mere humiliation. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Tuesday, October 09, 2018 1:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: :Re: IBMLink down since at least yesterday; Granular APAR search also dead On 10/9/2018 11:45 AM, Jesse 1 Robinson wrote: > Same counts here. I didn't even know this URL before today. haha! I put it in the Bit Bucket twice in a row! lol -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: :Re: IBMLink down since at least yesterday; Granular APAR search also dead
On 10/9/2018 11:45 AM, Jesse 1 Robinson wrote: Same counts here. I didn't even know this URL before today. haha! I put it in the Bit Bucket twice in a row! lol -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: ZZSA question
Thanks, I need to see if I can look at the SADMP source code. I know how CCW's work for a 3270 unit at IPL time, but it would be interesting to see if a totally different method is used when CONSOLE=SYSC is coded. And I need to correct myself: I looked at my old SA ICKDSF notes and the console address needs to be coded in the loadparm, such as CNSL - so messages appear immediately with no interrupt needed. On 10/9/2018 11:52 AM, Seymour J Metz wrote: TN3270 is a different animal from HMC, whether line mode or 3270 mode. TN3270 to an ICC looks like a local non-SNA 3270. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tom Brennan Sent: Friday, October 5, 2018 11:52 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: [EXTERNAL] Re: ZZSA question I just tested ZZSA under Hercules and like I thought, when you connect via Hercules TN3270 to simulate a console, after IPL no ZZSA messages appear until you press Enter. That means ZZSA sits waiting for an interrupt from a 3270 device, and uses that device for the rest of the communication. To me, that means it works just like SADUMP, DFDSS, and ICKDSF and there is no console configuration. On 10/5/2018 8:20 AM, Dyck, Lionel B. (RavenTek) wrote: I've tested ZZSA under Hercules - Thanks to Sam Golob's fine work - but I didn't see how to define a console as an HMC integretated console (hmcs) ? -- Lionel B. Dyck (Contractor) < Mainframe Systems Programmer – RavenTek Solution Partners -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Brennan Sent: Friday, October 05, 2018 10:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: ZZSA question Oh... you mean HMC console. New answer: I did not try that, but prior to going to that site I had never user ZZSA before so I tested it under Hercules, and that simulates the HMC console I believe, so I'd bet the answer is yes. On 10/5/2018 8:07 AM, Tom Brennan wrote: I used (well mostly watched) ZZSA work via ICC with no problems. That was a couple of years ago on a new z13s with OSA 5S cards. On 10/5/2018 4:58 AM, Dyck, Lionel B. (RavenTek) wrote: Does anyone know if the ZZSA tool (stand alone utilities) on the CBTTape can use the HMC Integrated Console? - - Lionel B. Dyck (Contractor) < Mainframe Systems Programmer - RavenTek Solution Partners - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISF452E on SDSF using MACRO ISFPARMS only on z/OS V2.3.
Hello, Adding this, you need to connect the sdsfaux on to sdsf proc. And get the required RACF or security access to it. Thanks On Wed, Oct 10, 2018, 1:38 AM Matthew Stitt wrote: > Find the SDSFAUX sample JCL and copy it to your system PROCLIB. Create a > user id and started task profile for it in your security product. > > SDSF will automatically start the new address space when it starts. > > Everything should be happy. > > That's all I remember I had to do when I started playing with z/OS V2R3. > > On Tue, 9 Oct 2018 18:02:39 +, Dunlap, Curtis L > wrote: > > >Thanks, but I've checked with our ACF2 admin and he says SDSF class is > not activated. > > > >Curt > > > > > > > >From: IBM Mainframe Discussion List on behalf > of Matt Hogstrom > >Sent: Tuesday, October 9, 2018 12:41:33 PM > >To: IBM-MAIN@LISTSERV.UA.EDU > >Subject: Re: ISF452E on SDSF using MACRO ISFPARMS only on z/OS V2.3. > > > >If its the same problem I had you have to make the SDSF class Raclistable. > > > > > >Matt Hogstrom > >m...@hogstrom.org > >+1-919-656-0564 > >PGP Key: 0x90ECB270 > > > > >> On Oct 9, 2018, at 5:01 PM, Dunlap, Curtis L wrote: > >> > >> Hi IBM-MAIN Mainframers! Long time listener, first time caller. :-) > >> > >> I'm upgrading from z/OS V2.1 to V2.3 and I'm receiving this message > opening SDSF: > >> ISF452E SDSFAUX communications failed, return code 0x0008, > >> reason code 0x00370801, function "connect". SDSFAUX not available > >> or function not supported > >> I tried to implement SDSF with the ISFPARMS USERMOD table w/o SDSF* > servers to expedite the OS upgrade and am now receiving this message when > SDSF is executed from TSO, ISPF or batch. I've struck out doing searches > on the webernets (and IBM as well) for this particular scenario, but from > what I've read, I should still be able to use SDSF w/o the servers > running. Anybody out there have any good ideas short of converting? > >> > >> Thanks in advance. > >> Curt. > > > > -- > 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: ISF452E on SDSF using MACRO ISFPARMS only on z/OS V2.3.
Find the SDSFAUX sample JCL and copy it to your system PROCLIB. Create a user id and started task profile for it in your security product. SDSF will automatically start the new address space when it starts. Everything should be happy. That's all I remember I had to do when I started playing with z/OS V2R3. On Tue, 9 Oct 2018 18:02:39 +, Dunlap, Curtis L wrote: >Thanks, but I've checked with our ACF2 admin and he says SDSF class is not >activated. > >Curt > > > >From: IBM Mainframe Discussion List on behalf of >Matt Hogstrom >Sent: Tuesday, October 9, 2018 12:41:33 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: ISF452E on SDSF using MACRO ISFPARMS only on z/OS V2.3. > >If its the same problem I had you have to make the SDSF class Raclistable. > > >Matt Hogstrom >m...@hogstrom.org >+1-919-656-0564 >PGP Key: 0x90ECB270 > >> On Oct 9, 2018, at 5:01 PM, Dunlap, Curtis L wrote: >> >> Hi IBM-MAIN Mainframers! Long time listener, first time caller. :-) >> >> I'm upgrading from z/OS V2.1 to V2.3 and I'm receiving this message opening >> SDSF: >> ISF452E SDSFAUX communications failed, return code 0x0008, >> reason code 0x00370801, function "connect". SDSFAUX not available >> or function not supported >> I tried to implement SDSF with the ISFPARMS USERMOD table w/o SDSF* servers >> to expedite the OS upgrade and am now receiving this message when SDSF is >> executed from TSO, ISPF or batch. I've struck out doing searches on the >> webernets (and IBM as well) for this particular scenario, but from what I've >> read, I should still be able to use SDSF w/o the servers running. Anybody >> out there have any good ideas short of converting? >> >> Thanks in advance. >> Curt. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBMLink down since at least yesterday; Granular APAR search also dead
[Default] On 9 Oct 2018 10:42:45 -0700, in bit.listserv.ibm-main edja...@phoenixsoftware.com (Ed Jaffe) wrote: >On 10/9/2018 9:10 AM, Tom Conley wrote: >> >> ... any ideas why Granular APAR search is dead? Any search I do comes >> back with 0 results. > >It's working for me using this URL: > >https://www14.software.ibm.com/support/customercare/psearch/search?domain=gapar Shouldn't someone just be able to go the main site www.ibm.com, click on support, then on the support page click on z/OS and then on the next page get a list of options including SR and IBMLINK? If this isn't the case, why would the lack of such capability not be a blatant instance of terminal incompetence (pun recognized after keying)? Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: ZZSA question
TN3270 is a different animal from HMC, whether line mode or 3270 mode. TN3270 to an ICC looks like a local non-SNA 3270. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tom Brennan Sent: Friday, October 5, 2018 11:52 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: [EXTERNAL] Re: ZZSA question I just tested ZZSA under Hercules and like I thought, when you connect via Hercules TN3270 to simulate a console, after IPL no ZZSA messages appear until you press Enter. That means ZZSA sits waiting for an interrupt from a 3270 device, and uses that device for the rest of the communication. To me, that means it works just like SADUMP, DFDSS, and ICKDSF and there is no console configuration. On 10/5/2018 8:20 AM, Dyck, Lionel B. (RavenTek) wrote: > I've tested ZZSA under Hercules - Thanks to Sam Golob's fine work - but I > didn't see how to define a console as an HMC integretated console (hmcs) ? > > -- > Lionel B. Dyck (Contractor) < > Mainframe Systems Programmer – RavenTek Solution Partners > > > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Tom Brennan > Sent: Friday, October 05, 2018 10:14 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: ZZSA question > > Oh... you mean HMC console. New answer: I did not try that, but prior to > going to that site I had never user ZZSA before so I tested it under > Hercules, and that simulates the HMC console I believe, so I'd bet the answer > is yes. > > On 10/5/2018 8:07 AM, Tom Brennan wrote: >> I used (well mostly watched) ZZSA work via ICC with no problems. That >> was a couple of years ago on a new z13s with OSA 5S cards. >> >> On 10/5/2018 4:58 AM, Dyck, Lionel B. (RavenTek) wrote: >>> Does anyone know if the ZZSA tool (stand alone utilities) on the >>> CBTTape can use the HMC Integrated Console? >>> >>> - >>> - >>> >>> Lionel B. Dyck (Contractor) < >>> Mainframe Systems Programmer - RavenTek Solution Partners >>> >>> >>> >>> - >>> - For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO >>> IBM-MAIN >>> >>> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, send >> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: IBM mainframe containers grow more secure | ZDNet
As usual, ZD gets it wrong. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Mark Regan Sent: Friday, October 5, 2018 11:55 AM To: IBM-MAIN@listserv.ua.edu Subject: Fwd: IBM mainframe containers grow more secure | ZDNet https://secure-web.cisco.com/1bBxNoB4SepXzNmdpkP-n9RAe9fBqgeZczV8xA14tYDTramMGgqdq7sVbWAnPAJ1OUG-ugQyTrOW-NqGa4VRGmMKk2fdXCKiB3yKpiKzz00Wr1aw21Mn7X_qvXdQJm_LCxy6_XjYqv55ExeYsdBE4Mx1LCRCaFOReg-nX1jBNHH1iAKhqt8HJbT-YRfU7MStJReO_PxRD9IRVmRc1shtByZF3cRC42uqnP4tx5ArVkhA4OIkhKPwGagUrYyDor_WZeafoi-a1SEeYWt32BVSN_5htAd54-89ORxXIivl5zJQ51ahuXD6USoTjKB_zj5oArCEXnRV1pKuDcqXJD4zTW_Id4uUTRiNTy79Uf74Ovpx2rVTUuzZOuQ_OqQxPW40UahPAndQg5HCQmRIRWHq8EyPerZD-zJkd5sNFJTs1in3CAMgCnYV-2r41X5zgy0vm/https%3A%2F%2Fwww.zdnet.com%2Farticle%2Fibm-mainframe-containers-grow-more-secure%2F -- 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: ISPF issue - new system
You need to have unit names matching your STC and TSO JCL and you need to define public and storage volumes in VATLSTxx matching your JCL and unit names. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Vinoth M Sent: Friday, October 5, 2018 1:18 PM To: IBM-MAIN@listserv.ua.edu Subject: ISPF issue - new system Hi All, We have build a new system and we are bringing this system without SMS configuration. We got the VTAM, TSO, TCPIP up and we are ready to login TSO, when we login to TSO, the ISPF profiles are not getting allocated, since it’s pointing to SMS dataset but we have disabled SMS. May I know, where to change the SMS stuffs to NON-SMS volume, do I no to change in parmlibs or any other procs, please let me know. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
:Re: IBMLink down since at least yesterday; Granular APAR search also dead
Same counts here. I didn't even know this URL before today. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Tuesday, October 09, 2018 11:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: IBMLink down since at least yesterday; Granular APAR search also dead On 10/9/2018 10:45 AM, Tom Conley wrote: > > I enter IEBCOPY, 0 hits. *1-10*of*279*results -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBMLink down since at least yesterday; Granular APAR search also dead
On 10/9/2018 10:45 AM, Tom Conley wrote: I enter IEBCOPY, 0 hits. *1-10*of*279*results -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISF452E on SDSF using MACRO ISFPARMS only on z/OS V2.3.
Thanks, but I've checked with our ACF2 admin and he says SDSF class is not activated. Curt From: IBM Mainframe Discussion List on behalf of Matt Hogstrom Sent: Tuesday, October 9, 2018 12:41:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISF452E on SDSF using MACRO ISFPARMS only on z/OS V2.3. If its the same problem I had you have to make the SDSF class Raclistable. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.e0zm100%2FRACF_SDSF_RACLIST_V2R3.htmdata=02%7C01%7Ccvd5215%40psu.edu%7Cda65b2162df147bfd81b08d62e061953%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636747001061519191sdata=2quGdN73OfTEDoV19It4aVdP6eLytIl%2BN2UC6WGlH5g%3Dreserved=0 Matt Hogstrom m...@hogstrom.org +1-919-656-0564 PGP Key: 0x90ECB270 I just read a book on Stockholm Syndrome, it was pretty bad at first, but, by the end I kind of liked it. > On Oct 9, 2018, at 5:01 PM, Dunlap, Curtis L wrote: > > Hi IBM-MAIN Mainframers! Long time listener, first time caller. :-) > > I'm upgrading from z/OS V2.1 to V2.3 and I'm receiving this message opening > SDSF: > ISF452E SDSFAUX communications failed, return code 0x0008, > reason code 0x00370801, function "connect". SDSFAUX not available > or function not supported > I tried to implement SDSF with the ISFPARMS USERMOD table w/o SDSF* servers > to expedite the OS upgrade and am now receiving this message when SDSF is > executed from TSO, ISPF or batch. I've struck out doing searches on the > webernets (and IBM as well) for this particular scenario, but from what I've > read, I should still be able to use SDSF w/o the servers running. Anybody > out there have any good ideas short of converting? > > Thanks in advance. > Curt. > > > -- > 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: IBMLink down since at least yesterday; Granular APAR search also dead
On 10/9/2018 1:42 PM, Ed Jaffe wrote: On 10/9/2018 9:10 AM, Tom Conley wrote: ... any ideas why Granular APAR search is dead? Any search I do comes back with 0 results. It's working for me using this URL: https://www14.software.ibm.com/support/customercare/psearch/search?domain=gapar I enter IEBCOPY, 0 hits. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBMLink down since at least yesterday; Granular APAR search also dead
On 10/9/2018 9:10 AM, Tom Conley wrote: ... any ideas why Granular APAR search is dead? Any search I do comes back with 0 results. It's working for me using this URL: https://www14.software.ibm.com/support/customercare/psearch/search?domain=gapar -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISF452E on SDSF using MACRO ISFPARMS only on z/OS V2.3.
If its the same problem I had you have to make the SDSF class Raclistable. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.e0zm100/RACF_SDSF_RACLIST_V2R3.htm Matt Hogstrom m...@hogstrom.org +1-919-656-0564 PGP Key: 0x90ECB270 I just read a book on Stockholm Syndrome, it was pretty bad at first, but, by the end I kind of liked it. > On Oct 9, 2018, at 5:01 PM, Dunlap, Curtis L wrote: > > Hi IBM-MAIN Mainframers! Long time listener, first time caller. :-) > > I'm upgrading from z/OS V2.1 to V2.3 and I'm receiving this message opening > SDSF: > ISF452E SDSFAUX communications failed, return code 0x0008, > reason code 0x00370801, function "connect". SDSFAUX not available > or function not supported > I tried to implement SDSF with the ISFPARMS USERMOD table w/o SDSF* servers > to expedite the OS upgrade and am now receiving this message when SDSF is > executed from TSO, ISPF or batch. I've struck out doing searches on the > webernets (and IBM as well) for this particular scenario, but from what I've > read, I should still be able to use SDSF w/o the servers running. Anybody > out there have any good ideas short of converting? > > Thanks in advance. > Curt. > > > -- > 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: IBMLink down since at least yesterday; Granular APAR search also dead
On 10/9/2018 11:44 AM, Jesse 1 Robinson wrote: Appears to be a temporary transition problem. This news note is dated 8 Oct. "Our redirect from www.ibm.com/ibmlink is not working at this moment until we finish migrating to blueID. "Please use the link below instead: https://www-304.ibm.com/ibmlink " The IBMLink Help Desk did not so inform us. Also, any ideas why Granular APAR search is dead? Any search I do comes back with 0 results. 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: IBMLink down since at least yesterday; Granular APAR search also dead
Appears to be a temporary transition problem. This news note is dated 8 Oct. "Our redirect from www.ibm.com/ibmlink is not working at this moment until we finish migrating to blueID. "Please use the link below instead: https://www-304.ibm.com/ibmlink " . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Chambers, David W. Sent: Tuesday, October 09, 2018 6:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: IBMLink down since at least yesterday; Granular APAR search also dead Just in case someone needs it: https://www-304.ibm.com/ibmlink Save you a call. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.3, SDSFAUX missing message...
We do not use ISFPRMxx. We're still using the assembled mac version. Might be our issue even tho the manual states it's acceptable. On 10/9/2018 11:29 AM, Rob Scott wrote: From the "Summary of changes" section in the SDSF 2.3 manual : As of z/OS V2R3, SDSF requires the SDSF and SDSFAUX address spaces to be active for full functionality. The SDSF address space manages connections, processes ISFPRMxx statements, handles operator commands, and starts and stops SDSFAUX. The SDSFAUX address space is used for data gathering requests. Typically, the SDSF address space is started during IPL using COMMNDxx. During SDSF initialization, the SDSFAUX address space is started. When a user accesses SDSF, the SDSF client program attempts to connect to the SDSF address space. To connect to the SDSF server, the user must have READ access to the ISF.CONNECT.system resource in the SDSF class. If the SDSF address space is not active, SDSF provides limited functionality. The user must have READ access to the SERVER.NOPARM resource in the SDSF class so that ISFPARMS can be used instead of ISFPRMxx. Panels that require the use of the SDSFAUX data gatherers (such as APF, LPA, and LNK) are not available. If the SDSF address is active, but no ISFPRMxx is in effect (such as a syntax error during startup), SDSFAUX is not started. The user requires access to the SERVER.NOPARM resource to fall back to ISFPARMS and requires READ access to the ISF.CONNECT.system resource to continue. Panels that require the use of SDSFAUX are not available. Hope that helps Rob Scott Rocket Software -Original Message- From: IBM Mainframe Discussion List On Behalf Of Brian France Sent: Tuesday, October 9, 2018 4:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.3, SDSFAUX missing message... We're in process of upgrading from z/OS 2.1 to 2.3 On our test lpar when we enter sdsf we see the following message - ISF452E SDSFAUX communications failed, return code 0x0008,, reason code 0x00370801, function "connect". SDSFAUX not available, or function not supported, Indeed we have never run SDSFAUX nor the SDSF server. So any ide'ers as to why this now coming up? Anyone else see it? -- Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/SYSARC Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 b...@psu.edu "To make an apple pie from scratch, you must first invent the universe." Carl Sagan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.rocketsoftware.com%2FRocketCommunity%2FRCEmailSupportdata=02%7C01%7Cbwf2%40psu.edu%7Cfe0f8db547334794f3ba08d62dfc032e%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636746957753832204sdata=DshSQRRIE%2FKV0UM4vZRVSIcjCLGxiLlc13%2BEDLP1M5Q%3Dreserved=0 Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fmanage-your-email-preferencesdata=02%7C01%7Cbwf2%40psu.edu%7Cfe0f8db547334794f3ba08d62dfc032e%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636746957753832204sdata=k5wtawOCiuOTacJ%2BYPRiP5iuigHnKZQ4a7P9mfoKZzE%3Dreserved=0 Privacy Policy - https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policydata=02%7C01%7Cbwf2%40psu.edu%7Cfe0f8db547334794f3ba08d62dfc032e%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636746957753832204sdata=zSeMabeus96Uu7AX4WKdbvepzrPwrii94lP%2Bn0CpMgM%3Dreserved=0 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 -- Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/SYSARC Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 b...@psu.edu "To make an apple pie from scratch, you must first invent the universe." Carl Sagan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.3, SDSFAUX missing message...
Good to know ahead of time, thanks Rob! I'll be moving to 2.3 early next year Carmen Vitullo - Original Message - From: "Rob Scott" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, October 9, 2018 10:29:22 AM Subject: Re: z/OS 2.3, SDSFAUX missing message... >From the "Summary of changes" section in the SDSF 2.3 manual : As of z/OS V2R3, SDSF requires the SDSF and SDSFAUX address spaces to be active for full functionality. The SDSF address space manages connections, processes ISFPRMxx statements, handles operator commands, and starts and stops SDSFAUX. The SDSFAUX address space is used for data gathering requests. Typically, the SDSF address space is started during IPL using COMMNDxx. During SDSF initialization, the SDSFAUX address space is started. When a user accesses SDSF, the SDSF client program attempts to connect to the SDSF address space. To connect to the SDSF server, the user must have READ access to the ISF.CONNECT.system resource in the SDSF class. If the SDSF address space is not active, SDSF provides limited functionality. The user must have READ access to the SERVER.NOPARM resource in the SDSF class so that ISFPARMS can be used instead of ISFPRMxx. Panels that require the use of the SDSFAUX data gatherers (such as APF, LPA, and LNK) are not available. If the SDSF address is active, but no ISFPRMxx is in effect (such as a syntax error during startup), SDSFAUX is not started. The user requires access to the SERVER.NOPARM resource to fall back to ISFPARMS and requires READ access to the ISF.CONNECT.system resource to continue. Panels that require the use of SDSFAUX are not available. Hope that helps Rob Scott Rocket Software -Original Message- From: IBM Mainframe Discussion List On Behalf Of Brian France Sent: Tuesday, October 9, 2018 4:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.3, SDSFAUX missing message... We're in process of upgrading from z/OS 2.1 to 2.3 On our test lpar when we enter sdsf we see the following message - ISF452E SDSFAUX communications failed, return code 0x0008,, reason code 0x00370801, function "connect". SDSFAUX not available, or function not supported, Indeed we have never run SDSFAUX nor the SDSF server. So any ide'ers as to why this now coming up? Anyone else see it? -- Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/SYSARC Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 b...@psu.edu "To make an apple pie from scratch, you must first invent the universe." Carl Sagan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.3, SDSFAUX missing message...
From the "Summary of changes" section in the SDSF 2.3 manual : As of z/OS V2R3, SDSF requires the SDSF and SDSFAUX address spaces to be active for full functionality. The SDSF address space manages connections, processes ISFPRMxx statements, handles operator commands, and starts and stops SDSFAUX. The SDSFAUX address space is used for data gathering requests. Typically, the SDSF address space is started during IPL using COMMNDxx. During SDSF initialization, the SDSFAUX address space is started. When a user accesses SDSF, the SDSF client program attempts to connect to the SDSF address space. To connect to the SDSF server, the user must have READ access to the ISF.CONNECT.system resource in the SDSF class. If the SDSF address space is not active, SDSF provides limited functionality. The user must have READ access to the SERVER.NOPARM resource in the SDSF class so that ISFPARMS can be used instead of ISFPRMxx. Panels that require the use of the SDSFAUX data gatherers (such as APF, LPA, and LNK) are not available. If the SDSF address is active, but no ISFPRMxx is in effect (such as a syntax error during startup), SDSFAUX is not started. The user requires access to the SERVER.NOPARM resource to fall back to ISFPARMS and requires READ access to the ISF.CONNECT.system resource to continue. Panels that require the use of SDSFAUX are not available. Hope that helps Rob Scott Rocket Software -Original Message- From: IBM Mainframe Discussion List On Behalf Of Brian France Sent: Tuesday, October 9, 2018 4:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.3, SDSFAUX missing message... We're in process of upgrading from z/OS 2.1 to 2.3 On our test lpar when we enter sdsf we see the following message - ISF452E SDSFAUX communications failed, return code 0x0008,, reason code 0x00370801, function "connect". SDSFAUX not available, or function not supported, Indeed we have never run SDSFAUX nor the SDSF server. So any ide'ers as to why this now coming up? Anyone else see it? -- Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/SYSARC Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 b...@psu.edu "To make an apple pie from scratch, you must first invent the universe." Carl Sagan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences 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: S106 abends after copying into LINKLIST
The BLDL entry for a load module has included the TTR and length of the first text record since Old Man Noach cornered the market in Gopher Wood. Fetch chained the read of the text record to another read; the following record could never be a text record. There was no need to read the ESD. It seems highly unlikely that this has changed. Of course, none of this applies to program objects. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of John Eells Sent: Monday, October 8, 2018 3:44 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: S106 abends after copying into LINKLIST I do not know whether LLA keeps a pointer to the first text record (though it might), but it would certainly need the preceding associated control and ESD records to be cached as well if the first read done is for a text record. I would expect that, since the ESD and control records encode their own length, they are read with the SLI bit on in the CCW, so that incorrect length does not cause any sort of I/O error, logical or otherwise. The same goes for RLD records, and it might also apply to others. Based on some research I did a long time ago, here is how I believe things work: The control record contains a CCW fragment to be used in constructing the Read CCW for the next text record, unless it's the last. PCI processing is used to chain onto the channel program to get the entire module in one shot unless the system is so busy the PCI can't be serviced in time to add to the chain and the I/O operation terminates. In that case, I believe it's restarted where it left off. The read CCW for the text record should be constructed using the specific length stored in the control record, and I would not expect the SLI bit to be used for that CCW. On that basis, I would agree that if the first "text" record you read does not have the expected length that the unexpected status back from the device would likely result in a "logical I/O error." However, it's possible that SLI is used for the read (I have not read the code), and that would make other reasons (empty track, no record at that location on a track, additional extents, etc.) more likely culprits for ABEND106-F RC40. For performance reasons, though, I would expect that SLI is not set. This code was originally written before control unit cache existed and was designed to be really good at avoiding unecessary disk latency. And, of course, we might change details in the code at any time (though why we would ever want to is a good question!). The text records themselves are of variable length. They have a minimum length of 1024 bytes, and a maximum length of the track length or block size, whichever is smaller. The Binder (and COPYMOD) try to write the minimum possible number based on those limits. They issue TRKBAL to find out how much space is left on the track, and write records on following tracks as needed to finish writing a load module. (This is why 32760 is the best block size for load libraries.) Because the directory pointers to PDS members are TTR pointers, every load module does not generally happen to start on a new track. This means that large block sizes rarely if ever result in uniform text record lengths. They do result in fewer text records if the modules' lengths exceed a lower block size, though. All the above applies to load modules. I have no idea how this works under the covers for program objects, but Program Management Advanced Facilities documents load module records. Just some random additional info to reinforce the "except under narrow circumstances, with sufficient advance reflection, and malice--er, risk acceptance-aforethought, don't update running systems' data sets" others have already expressed. Michael Stein wrote: > > It's been a while but from what I remember about program fetch > here's a guess. > > Looking up S106 RC 0F reason code 40: > > either an uncorrectable I/O error occurred or an error in the > load module caused the channel program to fail. > > Well, lets assume the hardware is work so this isn't a "real" I/O > error caused by some hardware problem. And there are no dataset > extent changes, only the overwriting the dataset to empty it > out and then copying in the new modules. > > Well the EOF pointer for the dataset got moved toward the front after > the directory. This caused the new modules to be written starting at > the new EOF over the old modules. > > And LLA still has the directory entries for the old modules, not the new > ones. These now point into the new modules. LLA's information includes > specific information on the first block of text of each old module: > >- the TTR of the first block of text >- the length of the first block of text >- the linkage editor assigned origin of first block of text > > This allows program fetch to start with reading first text block, > rather than having
Re: z/OS 2.3, SDSFAUX missing message...
I don't think this issue is related to one I had, mine was security related, I did find a match for this issue https://www-01.ibm.com/support/docview.wss?uid=isg1PI54862 Carmen Vitullo - Original Message - From: "Brian France" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, October 9, 2018 10:08:37 AM Subject: z/OS 2.3, SDSFAUX missing message... We're in process of upgrading from z/OS 2.1 to 2.3 On our test lpar when we enter sdsf we see the following message - ISF452E SDSFAUX communications failed, return code 0x0008,, reason code 0x00370801, function "connect". SDSFAUX not available, or function not supported, Indeed we have never run SDSFAUX nor the SDSF server. So any ide'ers as to why this now coming up? Anyone else see it? -- Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/SYSARC Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 b...@psu.edu "To make an apple pie from scratch, you must first invent the universe." Carl Sagan -- 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
ISF452E on SDSF using MACRO ISFPARMS only on z/OS V2.3.
Hi IBM-MAIN Mainframers! Long time listener, first time caller. :-) I'm upgrading from z/OS V2.1 to V2.3 and I'm receiving this message opening SDSF: ISF452E SDSFAUX communications failed, return code 0x0008, reason code 0x00370801, function "connect". SDSFAUX not available or function not supported I tried to implement SDSF with the ISFPARMS USERMOD table w/o SDSF* servers to expedite the OS upgrade and am now receiving this message when SDSF is executed from TSO, ISPF or batch. I've struck out doing searches on the webernets (and IBM as well) for this particular scenario, but from what I've read, I should still be able to use SDSF w/o the servers running. Anybody out there have any good ideas short of converting? Thanks in advance. Curt. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS 2.3, SDSFAUX missing message...
We're in process of upgrading from z/OS 2.1 to 2.3 On our test lpar when we enter sdsf we see the following message - ISF452E SDSFAUX communications failed, return code 0x0008,, reason code 0x00370801, function "connect". SDSFAUX not available, or function not supported, Indeed we have never run SDSFAUX nor the SDSF server. So any ide'ers as to why this now coming up? Anyone else see it? -- Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/SYSARC Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 b...@psu.edu "To make an apple pie from scratch, you must first invent the universe." Carl Sagan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S106 abends after copying into LINKLIST
My $0,02: 1. Use PDSE on LNKLST whenever possible 2. For PDS do not use secondary allocation (and single extent for primary, CONTIG) 3. Keep number of "your own" libraries as small as possible 4. Allow LNKLST additions, not deletions (or just be prepared for IPL) 5. PTFs on LNKLST are good reason to IPL -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Disk i/o problem
You may want to talk to your hardware vendor on this. Some times this could be dependent on your hardware, EMC, IBM, STK, etc They may have some insight for you on this question. Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Tommy Tsui > Sent: Monday, October 08, 2018 8:37 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Disk i/o problem > > hi all， > During online，one our dwdm link suspend 50ms，and the switch port offline > and then online within 1 second，we found os issued IOS080i i/o exceed > timeout value alert，our MIH set IOTDASD=00:07，most our cics trans timeout > and some db2 logcopy hang，how come just 1 second interrupted and casued all > trans timeout？any parameter can turning？any shop hit the same problem ？ > many > thanks > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBMLink down since at least yesterday; Granular APAR search also dead
On 10/9/2018 9:41 AM, Chambers, David W. wrote: Just in case someone needs it: https://www-304.ibm.com/ibmlink Save you a call. So IBM just all of a sudden decided to break www.ibmlink.ibm.com and www.ibm.com/ibmlink. We weren't supposed to have to remember the -3xx after the www, which always seems to change. Classic. WTG, IBM! 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: Question on DISP=MOD and GDGs
> I would imagine their other JCL checker product probably has the same issue I was once acquired by ASG and worked there for about four years, but I have no special knowledge of logic of the JCL check products. That said, the products were acquired from competing companies and had different code bases, so the internal processing might be quite different, and a given bug might be specific to only one of them. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Brian Westerman Sent: Tuesday, October 9, 2018 12:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Question on DISP=MOD and GDGs Hi, Your conclusion is correct, but there is a currently known problem with PRO/JCL (from ASG) that erroneously says that it's not valid. There are actually several PRO/JCL problems that we have open with ASG currently, related to GDG processing with tape and also tape processing with disp=MOD and disk processing with DISP=MOD. I think we have 4 altogether. Of all the problems, the only one they fixed is that the PROCLIB concatenation was not being dynamically located under z/OS 2.3. (the easiest one for us to code around by already defining the libraries explicitly in the parms). I would imagine their other JCL checker product probably has the same issue but I don't know for sure. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.3 and VOLCOUNT
Classification: Public We tripped over something with z/OS 2.1 maintenance and volcounts. These are some notes I have: With z/OS 2.1, an enhancement to DFSMS came in which meant that when a dataset (tape in this case) filled 5 volumes, DFSMS automatically created the additional control blocks to extend by another 5 tapes...and then another and so on Until we applied maintenance to z/OS 2.1, that happened regardless of the VOL,,,x parameter in JCL or in the DATACLAS, After, the system now honours the VOL,,,x parameter or what's in the DATACLAS (and I think the DATACLAS overrides the JCL). A selection of DATACLAS's had VOLCOUNT=1 set (which really means 5 vols), and this caused us some abends. We raised a PMR with IBM, and one part of the dialogue went: There was a RAS enhancement to eliminate ABEND837-08 for tape data sets introduced by APAR= OA46493. This APAR also has a detailed description how the VOLCNT allocation should work. Andy Styles z/Series System Programmer -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Beesley, Paul Sent: 09 October 2018 13:54 To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.3 and VOLCOUNT -- This email has reached the Bank via an external source -- Did something change with VOLCOUNT parameter handling between z/OS 2.1 and 2.3? We have a job that uses 21 tapes to backup an application's datasets, and has this parameter: VOL=(,RETAIN,,20), Following the upgrade to 2.3 at the weekend, this job failed S837-08, indicating it has run out of tape volumes, which is quite correct. However, looking back at the previous runs, they all have used 21 tapes. So they should really have abended as well, but all worked ok. Hence, wondering if something has changed in volume count processing, or whether there was a bug in 2.1 which was fixed in 2.3. Would appreciate any suggestions before I face the Spanish inquisition who are claiming that my upgrade broke their job. Paul Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading names used by the Atos group. The following trading entities are registered in England and Wales: Atos IT Services UK Limited (registered number 01245534), Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud Company Limited (registration number 08011902). The registered office for each is at Second Floor, Mid City Place, 71 High Holborn, London, WC1V 6EA. The VAT No. for each is: GB232327983. This e-mail and the documents attached are confidential and intended solely for the addressee, and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 10399850. Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Halifax is a division of Bank of Scotland plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded.
Re: Cross-memory POST ERRET and return codes
@Jim, thanks. A couple of follow-ups if I may. - What is the proper return from an XMPOST ERRET routine? BR 14? I don't see anything in the docs. - Would an XMPOST LINKAGE=BRANCH ERRET routine get passed the ABEND code? Where? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Monday, October 8, 2018 7:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cross-memory POST ERRET and return codes POSTERR will get control when an abend occurs under the XMPOST SRB in the target address space. Since you specified MEMREL=NO, POSTERR will get control under an SRB running in ASID 1. The return codes 4 and 8 are only for LINKAGE=SYSTEM, so they are not relevant to your LINKAGE=BRANCH request. They are return codes in R15 from POST. They are not passed to the ERRET. For LINKAGE=SYSTEM, return code 8 indicates that the POST is being done asynchronously (under an SRB in the target address space), and that ERRET will not be used if an abend occurs under the SRB. The book doesn't say when you would get return code 8 instead of 4, but I see in the code that 4 is used when the POST is issued in PSW key 0-7, and 8 is used when the POST is issued in PSW key 8-15. So it seems that effectively, ERRET is ignored for LINKAGE=SYSTEM cross-memeory POSTs issue in PSW key 8-15. I don't know why that was done, but it has been that way since the introduction of LINKAGE=SYSTEM in MVS/ESA SP3.1.0. Jim Mulder z/OS Diagnosis, Design, Development, 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: IBMLink down since at least yesterday; Granular APAR search also dead
Just in case someone needs it: https://www-304.ibm.com/ibmlink Save you a call. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS 2.3 and VOLCOUNT
Did something change with VOLCOUNT parameter handling between z/OS 2.1 and 2.3? We have a job that uses 21 tapes to backup an application's datasets, and has this parameter: VOL=(,RETAIN,,20), Following the upgrade to 2.3 at the weekend, this job failed S837-08, indicating it has run out of tape volumes, which is quite correct. However, looking back at the previous runs, they all have used 21 tapes. So they should really have abended as well, but all worked ok. Hence, wondering if something has changed in volume count processing, or whether there was a bug in 2.1 which was fixed in 2.3. Would appreciate any suggestions before I face the Spanish inquisition who are claiming that my upgrade broke their job. Paul Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading names used by the Atos group. The following trading entities are registered in England and Wales: Atos IT Services UK Limited (registered number 01245534), Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud Company Limited (registration number 08011902). The registered office for each is at Second Floor, Mid City Place, 71 High Holborn, London, WC1V 6EA. The VAT No. for each is: GB232327983. This e-mail and the documents attached are confidential and intended solely for the addressee, and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any reason to still use SWA=BELOW?
I would doubt there is any reason to use SWA=BELOW unless someone is chasing the TIOT(?) chain using logic that was invalidated w/MVS/ESA. I once has an application program that choked on this. A relatively small source code change to use RDJFCB, instead of chaseing the chain resolved the issue. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Conley Sent: Monday, October 8, 2018 7:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Any reason to still use SWA=BELOW? Just wondering if there is any reason to still use SWA=BELOW. I'm seeing this in a JES2 parm member and I'm surprised, since I changed to SWA=ABOVE ages ago. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBMLink down since at least yesterday; Granular APAR search also dead
Repeated refrain: The "new tools" are neither as reliable, functional, or available as those they are replacing. C'mon IBM, get your act together.! -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Conley Sent: Monday, October 8, 2018 4:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IBMLink down since at least yesterday; Granular APAR search also dead I wanted to personally thank IBM for their commitment to 24/7 downtime for electronic support. Somehow SR escaped the 24/7 down requirements, so I can still create PMRs. Searching, not so much. Well done, KUDOS!!! Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any reason to still use SWA=BELOW?
On Mon, 8 Oct 2018 20:37:23 -0400, Tom Conley wrote: I assume you see this while browsing the syslog for events that occurred during system startup for STCs launched prior to JES2 start. This is why JES2 definition for STC jobclass is ignored. These STCs get serviced by Master Scheduler, not by JES2. >Just wondering if there is any reason to still use SWA=BELOW. I'm >seeing this in a JES2 parm member and I'm surprised, since I changed to >SWA=ABOVE ages ago. > >Regards, >Tom Conley > >-- >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: Question on DISP=MOD and GDGs
Hi, Your conclusion is correct, but there is a currently known problem with PRO/JCL (from ASG) that erroneously says that it's not valid. There are actually several PRO/JCL problems that we have open with ASG currently, related to GDG processing with tape and also tape processing with disp=MOD and disk processing with DISP=MOD. I think we have 4 altogether. Of all the problems, the only one they fixed is that the PROCLIB concatenation was not being dynamically located under z/OS 2.3. (the easiest one for us to code around by already defining the libraries explicitly in the parms). I would imagine their other JCL checker product probably has the same issue but I don't know for sure. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
