Re: Cross Memory Services with AXSET and SSAR.
On Mon, 16 Mar 2015 18:30:19 +, Cannaerts, Jan jan.cannae...@socmut.be wrote: As for my problem; I have made a small test program that holds a piece of storage paged in memory, it spits out the virtual address to that piece of memory on sysprint so that I can easily retrieve it. Calling the assembler routine to peek inside that address space from REXX on our test LPAR, works flawlessly. I plug in the ASID, the virtual address and the length (main part of my customization efforts), and it spits the contents back out to REXX. I'm very happy with this. I'm very surprised that would work at all, as code within REXX execs does not run authorized, and you need to be authorized to do the MODESET and the other instructions you've mentioned. How are you invoking that routine from your REXX exec? Where does the REXX exec run (TSO session, batch job under IKJEFT01, or ?) -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized ...))
All, See this thread ...Charles this is the one I spoke about... https://groups.google.com/forum/#!msg/bit.listserv.ibm-main/tR7c3Pi9pFI/tnp_CEFOh-IJ Regards, Scott On Tue, Mar 17, 2015 at 10:52 AM, John McKown john.archie.mck...@gmail.com wrote: On Tue, Mar 17, 2015 at 9:43 AM, Binyamin Dissen bdis...@dissensoftware.com wrote: Of course, after this snippet the authorized section cannot trust the contents of any key8 storage. Yes, I can see how that can be true. Of course, I don't know of a _good_ method to ensure memory protection from a rogue program which runs in the same address space as a trusted program. That's why z/OS UNIX has the concept of a dirty address space and you can get some nasty return codes. That could be considered a plus for doing things like this using UNIX facilities to fork() a child address space to run the untrusted program, and only sharing specific memory pages using UNIX share memory facilities or IAZVSERV. But that then goes back to the problem of the child needing to access DD statements in the parent address space. There are always trade offs. Unless you are willing to go whole hog and only use UNIX facilities, including UNIX files instead of DDs. -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- 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: SMS ACS and TEMP DSN Parsing
Well, the temp-dsn pattern will probably only change with z/OS releases, so it will (only) be another item on that checklist. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, March 17, 2015 3:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS ACS and TEMP DSN Parsing Yes, that I understand. However, I have always been reluctant to set any TEMP DSN different than other TEMP DSNs. But this is a unique case and I am hoping this will resolve the issue. The other issue is the consistency for the temp DSN pattern. If anything changes, this code will no longer work. (Sigh) Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Shirey Sent: Tuesday, March 17, 2015 7:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS ACS and TEMP DSN Parsing I don't think there's anything wrong with the logic, but you know that most attributes of a DATACLAS can be overridden. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, March 16, 2015 7:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMS ACS and TEMP DSN Parsing I am trying to create a process in the Dataclas that will change some of the dataset attributes of on specific Temp DSN. The DSN comes in with DSTYPE = TEMP Does anyone know if this will work? The DSN will look like this: SYS15070.T105514.RA000.MYDSN1.R0226931 If (DSTYPE = Temp and DSN(4) = 'MYDSN1') Then Do Set Dataclas = X Write DSN set to X Dataclas Exit End -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tech Skills Heading the Way of the Dinosaur - 2015 Edition
Lizette and Elardus , The article I skimmed and will read more later. I agree. Sometimes one learns bad habits or techniques because of exposure and rush to get things done . I suffer from this horrible illness and have been trying to correct it through questions and research. Regards, Scott On Tue, Mar 17, 2015 at 10:23 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: Lizette Koehler wrote: Interesting article that covers both midrange and mainframe platforms Indeed. Some of my old skills should be staying in prehistoric times like programming in Clarion and Clipper. You've gotta move on, just what that article suggests. I had to drop them because of platform development. Oh, one thing I think that author forgot was the evolving of viruses, Trojans, worms, etc. I remember how easy it was to get rid of that bouncing ball virus, today you get that stealthy rootkit havoc wreaker which are sometimes impossible to get rid of... You probably remember those bulliten boards on those home computers like Commodore 64 and such? Good days if you can say using those slow unreliable modems are 'good'. Natural Adabas was the rage some years ago in online jobhunting pages, now they're replaced by 1001 other skills in demand... One of these times I will tell my grand-grand-children there was something like 'Ancient Art of Computing.' (Sorry, Sun Tzu to misquote you...) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized ...))
On Tue, 17 Mar 2015 09:14:56 -0500, John McKown john.archie.mck...@gmail.com wrote: I just had a thought (and it's lonely). You start off APF authorized, key 8 as a normal APF program. You want to run program B from the STEPLIB, but without APF authorization. Perhaps the simplest way is to use SYNCHX something like: LOAD EP=B ST R0,EPA_B MODESET KEY=ZERO USING PSA,0 L R3,PSATOLD MY TCB USING TCB,R3 L R3,TCBJSCB GET JSCB ADDRESS DROP R3 ICM R3,B'1000',=X'00' CLEAR HIGH BYTE USING IEZJSCB,R3 NI JSCBOPTS,255-JSCBAUTH NOT APF L R15,EPA_B SYNCHX (15) INVOKES PROGRAM B IN TCB KEY OI JSCBOPTS,JSCBAUTH RESTORE APF AUTHORIZATION MODESET KEY=NZERO The SYNCHX is the magic which allows your code to stay key 0 while invoking the other program in line in key 8. When the program returns, your code is still key 0. At which point you restore APF authorization and continue on. At which point you have a _major_ system integrity flaw. What about all that key 8 storage your APF-authorized program has been using? The program you SYNCHX'd to is free to overwrite it. You cannot trust any of it, including the initial save area that MVS passed to your program, and where you presumably stored the registers on entry (including the return address). When you go to return to the system it's quite possible that you'll go to an address selected by the rogue routine, and it will be running with APF authority at that point. This can only be fully safe if you never have any key 8 storage, or if you copy all your key 8 data to a system key area before you invoke the unauthorized program, and never use the old key 8 storage again. That would be made a bit easier for you if your program was added to the PPT as running in a system key. Then your initial save area and everything you GETMAIN would be in that system key by default. But if you start out in key 8, you have more work to do. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPYO (was: APF-authorized ...)
In 1169475919541461.wa.paulgboulderaim@listserv.ua.edu, on 03/16/2015 at 04:52 PM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu said: I don't think so; if I were to relink IEBCOPY with AC(1) into an authorized library, it would work equally well when called from an unauthorized program. What did you mean by changing IEBCOPY from AC(1) to AC(0); I took it to mean not only relinking but changing the code so that it would work. If you were only talking about changing the AC after the code was already changed, then the answer is still obvious: the principle of least privilege. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPYO (was: APF-authorized ...)
On Tue, 17 Mar 2015 08:40:51 -0500, John McKown john.archie.mck...@gmail.com wrote: On Tue, Mar 17, 2015 at 8:18 AM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 5c91d5e7-95b6-439d-87a7-111003a2f...@comcast.net, on 03/16/2015 at 10:52 PM, Ed Gould edgould1...@comcast.net said: Legally no but it can be done . You can, legally, turn APF off and later turn it off. It should be done the way porcupines make love: very carefully. IMO, it would be easier to just use ATTACHX with the JSCB= pointing to a copy of the current task's JSCB with the APF bit flipped off. Of course, the copy really needs to be in subpool 253 (key 0, below the line). The OP might even want a TASKLIB= if he wants to do a DYNALLOC to specify the DSNs to be searched, perhaps given in a configuration file of some sort. OK, likely overkill in this case. Another interesting parameter might be SZERO=NO to not share subpool zero to avoid memory leaks if, as I have seen, the ATTACH'd program doesn't bother to clean up all its memory because the system will do that automatically. I've especially noticed this in the past because CLOSE didn't always free the I/O buffers when a DCB was closed. That still doesn't protect that APF-authorized program's key 8 storage from tampering by the non-authorized program. In other words, all that effort still leaves a major integrity hole open. Sharing your APF-authorized environment with untrusted code is _not_ simple, and even a complex implementation may not make it truly safe. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized ...))
On Tue, 17 Mar 2015 11:19:56 -0400, Tony Harminc t...@harminc.net wrote: On 17 March 2015 at 10:52, John McKown john.archie.mck...@gmail.com wrote: Of course, after this snippet the authorized section cannot trust the contents of any key8 storage. Yes, I can see how that can be true. Of course, I don't know of a _good_ method to ensure memory protection from a rogue program which runs in the same address space as a trusted program. Well there is the key9 scheme (officially Storage-Protection-Override) that CICS uses. Whether it's hardened enough to protect against a malicious -- as opposed to possibly erroneous as the POO puts it -- problem program, I don't know. It's not. It is intended only to protect from incorrectly coded programs, not malicious ones. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized ...))
On Tue, Mar 17, 2015 at 10:18 AM, Walt Farrell walt.farr...@gmail.com wrote: On Tue, 17 Mar 2015 09:14:56 -0500, John McKown john.archie.mck...@gmail.com wrote: I just had a thought (and it's lonely). You start off APF authorized, key 8 as a normal APF program. You want to run program B from the STEPLIB, but without APF authorization. Perhaps the simplest way is to use SYNCHX something like: LOAD EP=B ST R0,EPA_B MODESET KEY=ZERO USING PSA,0 L R3,PSATOLD MY TCB USING TCB,R3 L R3,TCBJSCB GET JSCB ADDRESS DROP R3 ICM R3,B'1000',=X'00' CLEAR HIGH BYTE USING IEZJSCB,R3 NI JSCBOPTS,255-JSCBAUTH NOT APF L R15,EPA_B SYNCHX (15) INVOKES PROGRAM B IN TCB KEY OI JSCBOPTS,JSCBAUTH RESTORE APF AUTHORIZATION MODESET KEY=NZERO The SYNCHX is the magic which allows your code to stay key 0 while invoking the other program in line in key 8. When the program returns, your code is still key 0. At which point you restore APF authorization and continue on. At which point you have a _major_ system integrity flaw. What about all that key 8 storage your APF-authorized program has been using? The program you SYNCHX'd to is free to overwrite it. You cannot trust any of it, including the initial save area that MVS passed to your program, and where you presumably stored the registers on entry (including the return address). When you go to return to the system it's quite possible that you'll go to an address selected by the rogue routine, and it will be running with APF authority at that point. This can only be fully safe if you never have any key 8 storage, or if you copy all your key 8 data to a system key area before you invoke the unauthorized program, and never use the old key 8 storage again. That would be made a bit easier for you if your program was added to the PPT as running in a system key. Then your initial save area and everything you GETMAIN would be in that system key by default. But if you start out in key 8, you have more work to do. All of the above is very true. But as I understand the original problem, it is how to run untrusted code in the same address space as APF authorized code. IMO, this, in and of itself, is a possible? integrity exposure in z/OS. The only real solution would be to only run code which you have written or vetted to be safe (assuming you trust yourself). In the original post, it was running an IBM utility. But Charles didn't want to trust it enough to simply LINK to it and allow it to do its thing. What he wanted is what I gave: a way to temporarily turn off APF authorization, run the other code, then turn it back on. I, personally, would not do this. Being a paranoid heretic, I would go the UNIX route and figure out a way to run the untrusted code in a child process in another address space by using fork() and, likely, attach_execmvs(). And I again acknowledge the problems associated with DD statements in this environment. Too bad that z/OS does not have a easy way, in a UNIX child process, to have the child process do I/O to DDs allocated in the parent's address space. Perhaps by scheduling IRBs to a specialized TCBs in the parent which is set up to do this. Of course, this would be a massive new facility in DFSMSdfp. I can imagine a DCB or ACB option which would say the DD for this is in my parent. That would cause DFP to set things up in the child, and parent, so that the when the child did I/O to the DCB/ACB, DFP would schedule a routine to run in the parent to do the actual function (OPEN, CLOSE, READ, WRITE, ???) and pass the associated data back and forth (or use DAS or AR mode somehow). This would probably be very difficult. Which means expensive and time consuming. And for little actual need. -- Walt -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: using bpxwunix with tsocmd to run XMIT
In d3571c7d425590479eb3adb197bfc47b03932...@m4ukex02.intranet.macro4.com, on 03/17/2015 at 09:45 AM, Steve Austin steve.aus...@macro4.com said: any quotes I put around the dsn are ignored Presumably the command operand of bpxwunix is subject to shell parsing, for which quotes and apostrophes have special semantics. I suspect that you need to escape the apostrophes. Neither have I been able to set NOPREFIX Can you issue two TSO commands separated by semicolon? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPYO (was: APF-authorized ...)
On Mon, 16 Mar 2015 15:05:37 -0500, Paul Gilmartin paulgboul...@aim.com wrote: When I whined about the (how?) in connection with SMP/E a few years ago, before I knew even what little I now suspect about the nature of the weakness, Walt replied with words similar to reasonable caution. I take that to mean that whatever flaw, it's (perhaps) susceptible to malicious exploitation, but highly unlikely to be triggered inadvertently. Exactly. It is not specifically that the programs may misbehave, but that the users may misbehave. If you trust the users not to misbehave, then you can safely let them run the program. If you don't trust them, then you should not let them run it. I do wish that IBM would describe the exact nature of the possible user misbehavior. Then folks like Charles would know more about the kind of program behavior they need to consider when deciding whether it's safe to invoke a program while running APF-authorized. Of course, if the possible user misbehavior were described in detail, then the malicious users would also know more about how to look for such potentially exploitable situations. That makes it difficult to convince everyone to improve that documentation. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized ...))
On 17 March 2015 at 10:52, John McKown john.archie.mck...@gmail.com wrote: Of course, after this snippet the authorized section cannot trust the contents of any key8 storage. Yes, I can see how that can be true. Of course, I don't know of a _good_ method to ensure memory protection from a rogue program which runs in the same address space as a trusted program. Well there is the key9 scheme (officially Storage-Protection-Override) that CICS uses. Whether it's hardened enough to protect against a malicious -- as opposed to possibly erroneous as the POO puts it -- problem program, I don't know. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPYO (was: APF-authorized ...)
In 9542953551899120.wa.m42tomibmmainyahoo@listserv.ua.edu, on 03/16/2015 at 02:25 PM, Tom Marchant 000a2a8c2020-dmarc-requ...@listserv.ua.edu said: Furthermore, if it were not designed to be invoked in an authorized environment, it should not be included in an APF authorized load library. Lot's of luck convincing IBM of that. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPYO (was: APF-authorized ...)
On Tue, 17 Mar 2015 23:30:33 -0400, Shmuel Metz (Seymour J.) wrote: SMP/E has a head start: the DDDEF list could be passed to the child process, And those allocations that are in the JCL? Are any necessary? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 abend after upgrading to z/OS 1.13
In b08549f0b5dc9644a4b897a29c64751a6640e...@monexch01.na.lzb.hq, on 03/17/2015 at 04:12 PM, Jerry Criste jerry.cri...@la-z-boy.com said: KBMS, has been unsupported since 2000, and is critical to the business. Why didn't you replace it while you had time? Here's some detail pulled from Fault Analyzer: It prints an ABEND code without a reason code? That makes the summary far less usefull. Thanks in advance for any insight that is provided. Look at the instructions in AICKBMSE.@MEMALOC and AICKBMSE.@MEMZER0. My guess is that it's looking at a system control block whose format has changed. R15 (R12 at entry) seems to be some sort of PLIST and the first word is bad or at least bytes 5-8[1] of what it points to are bad. At this point diagnosis is probably the easy part. Once you know the problem, fixing it without the source will be expensive, and you don't have time to find an alternative. [1] Please excuse me while I retch. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 abend after upgrading to z/OS 1.13
In 8873067969180921.wa.m42tomibmmainyahoo@listserv.ua.edu, on 03/17/2015 at 12:09 PM, Tom Marchant 000a2a8c2020-dmarc-requ...@listserv.ua.edu said: If that is the case, it is loaded into key zero storage that is not retch protected. If that is the case, you will S0C1 when you store into it. No; that would be S0C4-04, not S0C1. In this case he's getting S0C4-10 on a load. My guess is a control block change, although I wouldn't rule out Johm's CSVCLOC suggestion. If the problem is CSCBLOC, it's easy to put a bandage on it. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPYO (was: APF-authorized ...)
In 0281165305245017.wa.paulgboulderaim@listserv.ua.edu, on 03/17/2015 at 12:10 PM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu said: SMP/E has a head start: the DDDEF list could be passed to the child process, And those allocations that are in the JCL? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPYO (was: APF-authorized ...)
In caajsdjhnouonkoeeao9-eccqp5obuypxwnhdo5c+v8vzbgd...@mail.gmail.com, on 03/17/2015 at 01:01 PM, John McKown john.archie.mck...@gmail.com said: SVC 3 (EXIT) does not return to R15 in the RSA, Of course not but (I think, likely more) And documented. Now that I think on it, one could mess up the rogue programs attempts to modify an RSA Don't go there. Run in a system key and be done. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IDC31378I GDG BASE EXTENSION RECORD COUNT IS ZERO, BUT GDG EXTENSION
Has anybody figure out a way to actively do run some process to identify the IDC31378I GDG BASE EXTENSION RECORD COUNT IS ZERO, BUT GDG EXTENSION condition in catalog? with gdg base name I see with diagnose we do see this message however there's definately a name which is needed for the GDG Base which has this problem I see IBM has APAR opened however wondering meanwhile if we could have CSI used to identify the situation -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IDC31378I GDG BASE EXTENSION RECORD COUNT IS ZERO, BUT GDG EXTENSION
This will depend on your z/OS Level I found two APARs that might be of interest OA44642: IDC31379I DOES NOT LIST THE GDG WITH THE EXTENSION CELL COUNT MISMATCH DFSMS V21 users affect. MSGIDC31378I and MSGIDC31379I do not display the GDG BASE name in error, users could not determine which GDG had error, if the catalog contained more than one GDG's. OA44886: NOT ALL EXTENSION RECORDS FOR A GDG BASE ARE DELETED IF THE EXTENSION CELL COUNT IN THE BASE IS WRONG All users of z/OS 2.1.0 and higher getting message IDC31378I or IDC31379I. Code is changed to delete all extension records when DELETE GDG FORCE is issued. Do either of these help? Could you post the entire IDC31378I message? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ravi Gaur Sent: Tuesday, March 17, 2015 9:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IDC31378I GDG BASE EXTENSION RECORD COUNT IS ZERO, BUT GDG EXTENSION Has anybody figure out a way to actively do run some process to identify the IDC31378I GDG BASE EXTENSION RECORD COUNT IS ZERO, BUT GDG EXTENSION condition in catalog? with gdg base name I see with diagnose we do see this message however there's definately a name which is needed for the GDG Base which has this problem I see IBM has APAR opened however wondering meanwhile if we could have CSI used to identify the situation -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS ACS and TEMP DSN Parsing
You can test it with the test-mode of ISMF option 7.4. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: 17 March, 2015 1:02 To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMS ACS and TEMP DSN Parsing I am trying to create a process in the Dataclas that will change some of the dataset attributes of on specific Temp DSN. The DSN comes in with DSTYPE = TEMP Does anyone know if this will work? The DSN will look like this: SYS15070.T105514.RA000.MYDSN1.R0226931 If (DSTYPE = Temp and DSN(4) = 'MYDSN1') Then Do Set Dataclas = X Write DSN set to X Dataclas Exit End Thanks Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HMC Integrated console and JAVA
Thanks to those who suggested checking for pop-ups etc. None of that worked. After seeing the post about an open PMR where IBM acknowledged problems with JAVA 8 I uninstalled it and went back to JAVA7_21. Now my integrated console and operating system messages are available again. Alan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 abend after upgrading to z/OS 1.13
The listing indicates the @MEMALOC csect is AMODE 31. The calling program is listed as AMODE 24. Assuming the LINK in the first program is to @MEMALOC, it seems the contents of R2 at the time of the abend is part of some sort of save area passed by the AMODE 24 program, but now interpreted as a 31-bit address. The first program has a link-edit date of 1994 where the load module containing @MEMALOC has a link-edit date of yesterday. Are you sure the new copy of this program has the correct attributes? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bernd Oppolzer Sent: Tuesday, March 17, 2015 1:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S0C4 abend after upgrading to z/OS 1.13 The PSW which is contained in the Fault Analyser Reports shows that the AMODE at the time of error is 31 (see 99... at the leftmost part of the instruction address), so the address in R2 is in fact treated as a 31 bit address. But the main task seems to be at RMODE 24 and was probably AMODE 24. Could it be that the problem is that some intermediate component switched the AMODE to 31 and didn't switch it back to 24 on return? Kind regards Bernd Am 17.03.2015 um 18:01 schrieb John McKown: The problem is R2: R2: 4F1D6048 (Storage invalid) If you have a dump that you can actually look at, see if there is something reasonable at 001D6048. Otherwise, you'll need to try to backtrack where this value came from. If the data at address 001D6048 looks reasonable, then you need to figure out how the high order byte got set ot x'4F'. Well, I know nada about that package. The fact that the CSECT names all start with @MEM is suspicious. One question would be what release of z/OS did it last run on successfully? And I have two entries you could try with _might_ help. But, then again, they might not. In the DIAGnn member of PARMLIB, try putting in two lines like: VSM USEZOSV1R9RULES(YES) CBLOC VIRTUAL24(IHALCCA,IHAPCCA) http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2E2B0/31.6 and, less likely, in IEASYSnn you might try CSCBLOC=BELOW I've had really old programs blow up when the CSCB is above the line. But this can have a negative impart on the use of common memory below the line. Please read up on this. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2e2b0/54.8.14 The first two can be dynamically adjusted by putting them in a DIAGnn member of PARMLIB and the issuing the command: T DIAG=nn The latter requires an IPL to change. On Tue, Mar 17, 2015 at 11:12 AM, Jerry Criste jerry.cri...@la-z-boy.com wrote: Hello, We are experiencing an S0C4 abend after upgrading to z/OS 1.13. The application is known as KBMS, has been unsupported since 2000, and is critical to the business. We are working on a replacement, but full implementation is still several months away. We have experienced problems with the application in previous upgrades, but were able to address it by re-linking some of the programs (we do not have the source). Unfortunately that approach is not working this time, so I'm hoping someone can explain what might be happening and possible solutions. Thanks in advance for any insight that is provided. snip Instructions around point of failure: Offset HexInstruction -- -- - -10 90C8 C01C STM R12,R8,28(R12) -C 18FC LR R15,R12 -A 41C0 C050 LA R12,80(,R12) -6 18EB LR R14,R11 -4 5820 F000 L R2,0(,R15) * 5870 2005 L R7,5(,R2) +4 D203 F014 7001 MVC 20(4,R15),1(R7) +A 5860 F004 L R6,4(,R15) +E 1876 LR R7,R6 +10 4170 0007 LA R7,7 +14 1476 NR R7,R6 +16 1277 LTR R7,R7 Program Status Word (PSW) . : 078D2000 9970FB58 General Purpose Registers: R0: 0003 (651264 bytes of storage addressable) R1: 1970FCD8 (Module AICKBMSE CSECT @MEMFREE + X'0') R2: 4F1D6048 (Storage invalid) R3: 199DE000 (1069056 bytes of storage addressable) R4: (2048 bytes of storage addressable) R5: 0001 (2047 bytes of storage addressable) R6: (2048 bytes of storage addressable) R7: 0001 (2047 bytes of storage addressable) R8: 0008 (2040 bytes of storage addressable) R9: 104D6000 (Storage invalid) R10: 199C6008 (1167352 bytes of storage addressable) R11: 1970FB48 (Module AICKBMSE CSECT @MEMALOC + X'0') R12: 199C86D8 (1157416 bytes of storage addressable) R13: 9970FE80 (Module AICKBMSE CSECT @MEMZER0 + X'20') R14: 1970FB48 (Module AICKBMSE CSECT @MEMALOC + X'0') R15: 199C8688 (1157496 bytes of storage addressable) Virtual Storage Map AREA
Re: SMS ACS and TEMP DSN Parsing
Would checking the DDNAME and/or PROGRAM help? On 17 March 2015 at 15:10, Vernooij, CP (ITOPT1) - KLM kees.verno...@klm.com wrote: Well, the temp-dsn pattern will probably only change with z/OS releases, so it will (only) be another item on that checklist. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, March 17, 2015 3:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS ACS and TEMP DSN Parsing Yes, that I understand. However, I have always been reluctant to set any TEMP DSN different than other TEMP DSNs. But this is a unique case and I am hoping this will resolve the issue. The other issue is the consistency for the temp DSN pattern. If anything changes, this code will no longer work. (Sigh) Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Shirey Sent: Tuesday, March 17, 2015 7:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS ACS and TEMP DSN Parsing I don't think there's anything wrong with the logic, but you know that most attributes of a DATACLAS can be overridden. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, March 16, 2015 7:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMS ACS and TEMP DSN Parsing I am trying to create a process in the Dataclas that will change some of the dataset attributes of on specific Temp DSN. The DSN comes in with DSTYPE = TEMP Does anyone know if this will work? The DSN will look like this: SYS15070.T105514.RA000.MYDSN1.R0226931 If (DSTYPE = Temp and DSN(4) = 'MYDSN1') Then Do Set Dataclas = X Write DSN set to X Dataclas Exit End -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Looking for Miklos Szigetvari
Listers please forgive me for using the list for this purpose but I am looking to contact Miklos Szigetvari and his email address is now rejected. Miklos, if you are still monitoring the list would you please email me. Or, if anyone else knows a new email address for him that you could share, please send it to me in a private email. ch...@arneycomputer.com Chuck Arney Arney Computer Systems Web: http://zosdebug.com Facebook: http://www.facebook.com/arneycomputer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized ...))
On Tue, 17 Mar 2015 10:43:14 -0500, John McKown john.archie.mck...@gmail.com wrote: All of the above is very true. But as I understand the original problem, it is how to run untrusted code in the same address space as APF authorized code. IMO, this, in and of itself, is a possible? integrity exposure in z/OS. The only real solution would be to only run code which you have written or vetted to be safe (assuming you trust yourself). In the original post, it was running an IBM utility. But Charles didn't want to trust it enough to simply LINK to it and allow it to do its thing. What he wanted is what I gave: a way to temporarily turn off APF authorization, run the other code, then turn it back on. I, personally, would not do this. That may be what he asked for, but it's not safe as you suggested it. The existence of that SMP/E integrity APAR that we've mentioned demonstrates that if you want to run authorized, and invoke programs that you didn't write, then there is a level of knowledge you need to have about those routines in order to be sure it's safe to run them. The alternative is that you design your program so it will be safe to run them. One method is using fork() and execmvs() as you suggest below (snipped) to make the program run someplace else, where it won't have your authority and can't interfere with you. Another is to change the way your authorized program runs. We've mentioned one possibility in that area: put the authorized processing in a PC routine, establish that PC while you're running authorized, then turn off authorization. When you need to perform the authorized function later on, let the PC routine do it. Another design change might be to set your program up so the system invokes it in a system key, rather than invoking it in key 8. Then make sure any storage you allocate for your own use is also in that system key, and you should be safe from any tampering the other program might want to perform. You can then turn off JSCBAUTH before invoking the other program, and use SYNCHX to invoke it in problem state and a user key, and it won't run with any kind of authorization. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized ...))
On Tue, 17 Mar 2015 13:28:29 -0500, John McKown john.archie.mck...@gmail.com wrote: On Tue, Mar 17, 2015 at 10:43 AM, John McKown john.archie.mck...@gmail.com wrote: Being a paranoid heretic, I would go the UNIX route and figure out a way to run the untrusted code in a child process in another address space by using fork() and, likely, attach_execmvs(). And I again acknowledge the problems associated with DD statements in this environment. Talking to myself again. But I had another take on the above, for shop which despise UNIX. Use ASCRE to create the new address space. One problem is that this uses an INIT routine to initialize the address space. The documentation for ASCRE does not say anything about propagating the STEPLIB/JOBLIB, I assume this INIT routine needs to be in LPA, or dynamically added to LPA. The INIT routine would be passed the DSNs which make up the STEPLIB/JOBLIB for the task, do DYNALLOC on them, OPEN the DD, and use the TASKLIB= option of ATTACHX. It would also receive the equivalent of the PARM= from a batch job, which it might need to reformat and pass to the user program. If some data needs to be shared, put all of it in a single, large, page boundary GETMAIN'd area and use IAZVSERV to map that between the two address spaces. Sure, go ahead and reinvent fork(). Then try to figure out what parts of it you got wrong. Or, guess what: it's a lot easier to simply use fork(), which after all is a native z/OS service. You don't _have_ to think of it as being UNIX. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPYO (was: APF-authorized ...)
On Tue, 17 Mar 2015 13:01:42 -0500, John McKown wrote: SVC 3 (EXIT) does not return to R15 in the RSA, but (I think, likely more) ... OK. I had it backwards. Dredging my memory, I believe the subtask is entered with R14 pointing to an SVC 3. And some rogue vendors, I have heard, modify that R14 in order to front-end SVC 3. Ugh. Did I say R15? I probably should have said R14. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized ...))
On Tue, 17 Mar 2015 17:58:16 +0100, Thomas Berg thomas.b...@swedbank.se wrote: May an ignorant peek in here... :) Just as a concept and theoretically; wouldn't a way to secure that the key 8 storage is untouched is to save a hash of the content in system key area (with a random salt) ? Then just compare the hashes before reusing the key 8 data. Of course, this is only feasible if performance is not a problem. That does not secure the storage; it merely lets you tell if it has been corrupted. And you might have a lot of storage, with complex structure, that you need to handle that way. Still, that approach might be a start, but since it doesn't really solve the issue. And there are other issues that it doesn't being to address, so I would look for a different approach that actually prevents the unauthorized program from interfering with you. I've seen too many cases of people designing solutions that they think will allow safe intermingling of trusted authorized code with unauthorized code, and it often devolves into a game of whack-a-mole. You think of an issue, and defend against it. The attacker comes up with an issue you didn't consider, so you patch your program to get around that. Then the attacker comes up with another attack for you to patch against, and another, and ... It's best not to play that game. You need a design that fully isolates you in the first place. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: accounting packages
CA-Masterpiece is a full blown z/OS accounting package. Dun Bradstreet also had the Millennium software. Not sure if still available. SAP also cover off financials. Mincom (now Ventyx) also have an offering (Ellipse). On Tue, Mar 17, 2015 at 4:08 PM, Timothy Sipples sipp...@sg.ibm.com wrote: CA MICS does not address corporate/organizational accounting and financial reporting, though. The word accounting is important to clarify. My assumption is that the question relates to corporate accounting and financial reporting -- the stuff a company would report to its shareholders, among other things -- and not strictly or even primarily to IT-related accounting. That's a reasonable default assumption when confronted with the word accounting. My assumption means sales, revenue, profit, expenses, accounts receivable, accounts payable, cashflows, asset valuations, taxes, etc. within particular departments and across the entire organization. If I'm mistaken, if the latter, there are also several solutions on z/OS and/or z/VSE that cover IT-related accounting. IBM Tivoli Decision Support for z/OS (and Tivoli Usage and Accounting Manager) would be another example in the latter category. I hope the original poster will clarify. Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
using bpxwunix with tsocmd to run XMIT
I'm using bpxwunix with tsocmd to run an XMIT (see below). This works, but I've been unable to prevent the TSO PREFIX, being added to dataset name; any quotes I put around the dsn are ignored. Neither have I been able to set NOPREFIX. Is there a way to prevent the suffix being added? Thanks Steve lines.0 = 0 env.0 = 0 cmd=/bin/tsocmd XMIT target 'DS(dsn)' xrc = bpxwunix(cmd,lines.,out.,var.,env.) This e-mail message has been scanned and cleared by Postini / Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: using bpxwunix with tsocmd to run XMIT
Steve Austin wrote:
I'm using bpxwunix with tsocmd to run an XMIT (see below). This works, but
I've been unable to prevent the TSO PREFIX, being added to dataset name; any
quotes I put around the dsn are ignored. Neither have I been able to set
NOPREFIX. Is there a way to prevent the suffix being added?
Old trap for anyone trying string parsing... I sometimes fall in that trap too.
;-)
And you can't do a TRACE to see how lines are parsed and resolved... ouch...
cmd=/bin/tsocmd XMIT target 'DS(dsn)'
Try this (adding a single quote character to the right of ( and to the left of
) ):
cmd=/bin/tsocmd XMIT target 'DS('dsn')'
Note: This is DS, then (, then single quote character, then double quote
character, then variablename dsn, then double quote, single quote and then ).
This is so that the datasetname have single quote chars to the left and right,
all inside the parenthesis.
Something like this after parsing and resolving var names: cmd=/bin/tsocmd
XMIT xyz 'DS('hlq.mlq.lq')'
(Double quote outside string and only single quote inside the string.)
A$$uming of course, as you write, the characters from D to ) are both inside
double and single quote characters.
Geez, I hope I got it right... ;-)
HTH!
Groete / Greetings
Elardus Engelbrecht
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Turning JSCBAUTH off and back on again using Standard ATTACH (Was: IEBCOPYO (was: APF-authorized ...))
For decades, the IBM standard initiator has used a special form of ATTACH to allow Authorized programs to execute via JCL. The replacement JCL and Clist language I invented (Jol - see www.Oscar-Jol.com) and a more recent set of programs I wrote to allow Long Parms (3,000 characters) and Symbolic Parameters to be used in Control Cards (CBT Tape number 839) used the same ATTACH as the IBM Initiator uses. Thus properly Authorized can execute Authorized, and non-Aithorized can't do Authorized things. Jol was used by Amoco (USA) for decades, as well as Shell Oil, Air New Zealand and many other companies without a problem using this special form of ATTACH. You might find it would save time to look at the Source Code and duplicate it, or use one of my programs as is to execute Authorised Programs with Long Parmeters, or with control cards created via standard Symbolic Parameters. Or use Jol itself. See CBT Tape number 839. http://www.cbttape.org/ftp/cbt/CBT839.zip Clement Clarke Scott Ford wrote: John, I agree , I understand from a system integrity point of view why going from ac(0) to ac(1) is dangerous and understand why the customers ask the questions, boy do I... On Monday, March 16, 2015, John McKown wrote: Why stay in key 0? You could use another key in1..7 and most system services will work. But you will need to be careful in updating storage. You could use something like MVCDK to move bytes from location to location. But use of register to storage is going to be a problem. I'm not really suggesting that you do either. But I don't have a _simple_ solution for you either. On Mar 16, 2015 5:31 PM, Charles Mills wrote: I don't really know but my logic goes like this: You can only turn JCSBAUTH back on if you are key 0, otherwise you will S0C4. So you could set key 0, and then turn JSCBAUTH off, do stuff, and then turn it back on again -- but if you are going to run for any length of time doing stuff in key 0 you might just as well leave JSCBAUTH on, and if on the other hand you are going to go to user key, you are stuck there once you turn JSCBAUTH off. Does that make sense? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU ] On Behalf Of Scott Ford Sent: Monday, March 16, 2015 3:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEBCOPYO (was: APF-authorized ...) I have a related question to this very informative thread. Inside a long running task, i.e.; stc can you turn off APF authorization and turn back on ? Btw I have customers asked about this. -- 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 listserv@listserv.uaedu 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: IEBCOPYO (was: APF-authorized ...)
On Tue, Mar 17, 2015 at 12:10 PM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: snip Sigh. Cf. UNIX, which certainly doesn't let exit() branch to a user-modifiable address. A better designed END SVC would branch, not to the R15 in a key 8 RSA, but to a caller's address kept in protected storage. SVC 3 (EXIT) does not return to R15 in the RSA, but (I think, likely more) (1) makes the previous RB the current RB, (2) releases the exiting RB's storage, and (3) restores the PSW and registers from the contents of the now current RB (what was the previous RB at the time that the SVC 3 was issued). Now that I think on it, one could mess up the rogue programs attempts to modify an RSA by deliberately messing up the savearea chain pointers in the save area pointed to by TCBFSA to defeat forward save area chaining (perhaps copying the values in that area somewhere else and setting all 72 bytes to x'00'), setting R13 to some page boundary GETMAIN'd storage (get 8K and page protect the second 4K using PGSER), doing the SYNCHX setup previously mentioned, and restoring the save area chain pointers and restoring the FSA values after the SYNCHX returns. Of course, this does not stop a rogue from modifying key 8 storage. It just makes it more difficult to find something interesting to modify. In fact, if there are critical areas which are key 8, GETMAIN them on page boundaries in page multiples and use PGSER to mark them read-only before the SYNCHX and then read-write afterwards. Again, this is not impossible to get around. But it adds another level of coding to the rogue program. -- gil -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPYO (was: APF-authorized ...)
On Tue, 17 Mar 2015 13:01:42 -0500, John McKown john.archie.mck...@gmail.com wrote: On Tue, Mar 17, 2015 at 12:10 PM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: snip Sigh. Cf. UNIX, which certainly doesn't let exit() branch to a user-modifiable address. A better designed END SVC would branch, not to the R15 in a key 8 RSA, but to a caller's address kept in protected storage. PR. With BAKR 14,0 on entry SVC 3 (EXIT) does not return to R15 in the RSA, but No, it doesn't; it's the other way around. When the system passes control to your program, such as by ATTACH(X), LINK(X) or SYNCH(X), register 14 contains the address of CVTEXIT. CVTEXIT is an SVC 3 instruction. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 abend after upgrading to z/OS 1.13
it is loaded into key zero storage that is not retch protected. If that is the case, you will S0C1 when you store into it. Which will definitely make it retch. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Tuesday, March 17, 2015 10:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S0C4 abend after upgrading to z/OS 1.13 On Tue, 17 Mar 2015 16:12:53 +, Jerry Criste wrote: Hello, We are experiencing an S0C4 abend after upgrading to z/OS 1.13. I can't read your Fault Analyzer report because of the formatting. You didn't say what release of z/OS you were coming from, but one possibility is that your code is marked reentrant, but is not really, and is coming from an APF authorized library. If that is the case, it is loaded into key zero storage that is not retch protected. If that is the case, you will S0C1 when you store into it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 abend after upgrading to z/OS 1.13
On Tue, 17 Mar 2015 10:14:33 -0700, Charles Mills wrote: it is loaded into key zero storage that is not retch protected. If that is the case, you will S0C1 when you store into it. Oops. I meant to write S0C4 -- Tom Marchant Which will definitely make it retch. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Tuesday, March 17, 2015 10:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S0C4 abend after upgrading to z/OS 1.13 On Tue, 17 Mar 2015 16:12:53 +, Jerry Criste wrote: Hello, We are experiencing an S0C4 abend after upgrading to z/OS 1.13. I can't read your Fault Analyzer report because of the formatting. You didn't say what release of z/OS you were coming from, but one possibility is that your code is marked reentrant, but is not really, and is coming from an APF authorized library. If that is the case, it is loaded into key zero storage that is not retch protected. If that is the case, you will S0C1 when you store into it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 abend after upgrading to z/OS 1.13
The PSW which is contained in the Fault Analyser Reports shows that the AMODE at the time of error is 31 (see 99... at the leftmost part of the instruction address), so the address in R2 is in fact treated as a 31 bit address. But the main task seems to be at RMODE 24 and was probably AMODE 24. Could it be that the problem is that some intermediate component switched the AMODE to 31 and didn't switch it back to 24 on return? Kind regards Bernd Am 17.03.2015 um 18:01 schrieb John McKown: The problem is R2: R2: 4F1D6048 (Storage invalid) If you have a dump that you can actually look at, see if there is something reasonable at 001D6048. Otherwise, you'll need to try to backtrack where this value came from. If the data at address 001D6048 looks reasonable, then you need to figure out how the high order byte got set ot x'4F'. Well, I know nada about that package. The fact that the CSECT names all start with @MEM is suspicious. One question would be what release of z/OS did it last run on successfully? And I have two entries you could try with _might_ help. But, then again, they might not. In the DIAGnn member of PARMLIB, try putting in two lines like: VSM USEZOSV1R9RULES(YES) CBLOC VIRTUAL24(IHALCCA,IHAPCCA) http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2E2B0/31.6 and, less likely, in IEASYSnn you might try CSCBLOC=BELOW I've had really old programs blow up when the CSCB is above the line. But this can have a negative impart on the use of common memory below the line. Please read up on this. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2e2b0/54.8.14 The first two can be dynamically adjusted by putting them in a DIAGnn member of PARMLIB and the issuing the command: T DIAG=nn The latter requires an IPL to change. On Tue, Mar 17, 2015 at 11:12 AM, Jerry Criste jerry.cri...@la-z-boy.com wrote: Hello, We are experiencing an S0C4 abend after upgrading to z/OS 1.13. The application is known as KBMS, has been unsupported since 2000, and is critical to the business. We are working on a replacement, but full implementation is still several months away. We have experienced problems with the application in previous upgrades, but were able to address it by re-linking some of the programs (we do not have the source). Unfortunately that approach is not working this time, so I'm hoping someone can explain what might be happening and possible solutions. Thanks in advance for any insight that is provided. snip Instructions around point of failure: Offset HexInstruction -- -- - -10 90C8 C01C STM R12,R8,28(R12) -C 18FC LR R15,R12 -A 41C0 C050 LA R12,80(,R12) -6 18EB LR R14,R11 -4 5820 F000 L R2,0(,R15) * 5870 2005 L R7,5(,R2) +4 D203 F014 7001 MVC 20(4,R15),1(R7) +A 5860 F004 L R6,4(,R15) +E 1876 LR R7,R6 +10 4170 0007 LA R7,7 +14 1476 NR R7,R6 +16 1277 LTR R7,R7 Program Status Word (PSW) . : 078D2000 9970FB58 General Purpose Registers: R0: 0003 (651264 bytes of storage addressable) R1: 1970FCD8 (Module AICKBMSE CSECT @MEMFREE + X'0') R2: 4F1D6048 (Storage invalid) R3: 199DE000 (1069056 bytes of storage addressable) R4: (2048 bytes of storage addressable) R5: 0001 (2047 bytes of storage addressable) R6: (2048 bytes of storage addressable) R7: 0001 (2047 bytes of storage addressable) R8: 0008 (2040 bytes of storage addressable) R9: 104D6000 (Storage invalid) R10: 199C6008 (1167352 bytes of storage addressable) R11: 1970FB48 (Module AICKBMSE CSECT @MEMALOC + X'0') R12: 199C86D8 (1157416 bytes of storage addressable) R13: 9970FE80 (Module AICKBMSE CSECT @MEMZER0 + X'20') R14: 1970FB48 (Module AICKBMSE CSECT @MEMALOC + X'0') R15: 199C8688 (1157496 bytes of storage addressable) Virtual Storage Map AREA ADDRESS SIZE 64-BIT HIGH PRIVATE AREA 0002 8191P 64-BIT SHARED AREA 0200 510T 64-BIT COMMON AREA 01EF8000 67583.9M 64-BIT LOW PRIVATE AREA 00088000 1948.00G 64-BIT JAVA AREA8000 30720.0M --- 2 GIG BOUNDARY --- EXTENDED PRIVATE AREA1970 1641M EXTENDED COMMON SERVICE AREA (ECSA)09C28000 256864K EXT MODIFIED LINK PACK AREA (MLPA)09C27000 4K EXT FIXED LINK PACK AREA (FLPA) 09C24000
Re: zSeries HMC forcible disconnect issue - anybody seen this one before?
I opened a PMR and found that IBM is working on a Java 8 issue. They do not have an ETA for a fix. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ambros, Thomas Sent: Monday, March 09, 2015 2:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: zSeries HMC forcible disconnect issue - anybody seen this one before? Java issue. Downgrading to version 6 as on old hosts worked around it. SR time... Thomas Ambros zEnterprise Operating Systems zEnterprise Systems Management 518-436-6433 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Monday, March 09, 2015 12:48 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: zSeries HMC forcible disconnect issue - anybody seen this one before? Call MS. Ed On Mar 9, 2015, at 10:45 AM, Ambros, Thomas wrote: Remote access to our HMCs is controlled through a 'jump host' we access through Citrix in normal circumstances. I'm experiencing this problem when I use Windows Remote Desktop access to that jump host, bypassing Citrix, so I believe it is something to do with the Windows machine that is the jump host. This is a new issue after our Windows guys upgraded the jump host to Windows Server 2008 R2 Datacenter 6.1.7601, Java Version 8 update 31 and we're using Internet Explorer version 8. I'm pretty sure IE is unchanged. The zSeries HMCs are at 2.12.0 and are unchanged, obviously. The problem is a fairly consistent forcible session disconnect after 45 seconds. The HMC log simply reports that it was forcibly disconnected with no further details, and I haven't found anything in any of Window's logs to indicate what or why it was done. It's not an inactivity timeout, active use of the HMC gets cut off just as a session that is not being used. It appears to be restricted to the zSeries HMC, for example our Storage Admin team reports no problems with their TPC-R browser sessions through the same jump host. My next move is to find the Java configuration file options and see if there's some mindless default in there. I haven't opened an SR yet, I was throwing it out here in case somebody's seen this sort of symptom themselves. Already raised the issue of backing out to our Windows team, if they can't assist in diagnostics, but I'd prefer to fix it not really having the time to go through the annoyance of reinstall. Thanks... Thomas Ambros zEnterprise Operating Systems zEnterprise Systems Management 518-436-6433 This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose such information for any purpose other than to provide the services for which you are receiving the information. 127 Public Square, Cleveland, OH 44114 If you prefer not to receive future e-mail offers for products or services from Key send an e-mail to mailto:dnereque...@key.com with 'No Promotional E- mails' in the SUBJECT line. -- 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 This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose such information for any purpose other than to provide the services for which you are receiving the information. 127 Public Square, Cleveland, OH 44114 If you prefer not to receive future e-mail offers for products or services from Key send an e-mail to mailto:dnereque...@key.com with 'No Promotional E- mails' in the
Re: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized ...))
On Tue, Mar 17, 2015 at 10:43 AM, John McKown john.archie.mck...@gmail.com wrote: Being a paranoid heretic, I would go the UNIX route and figure out a way to run the untrusted code in a child process in another address space by using fork() and, likely, attach_execmvs(). And I again acknowledge the problems associated with DD statements in this environment. Talking to myself again. But I had another take on the above, for shop which despise UNIX. Use ASCRE to create the new address space. One problem is that this uses an INIT routine to initialize the address space. The documentation for ASCRE does not say anything about propagating the STEPLIB/JOBLIB, I assume this INIT routine needs to be in LPA, or dynamically added to LPA. The INIT routine would be passed the DSNs which make up the STEPLIB/JOBLIB for the task, do DYNALLOC on them, OPEN the DD, and use the TASKLIB= option of ATTACHX. It would also receive the equivalent of the PARM= from a batch job, which it might need to reformat and pass to the user program. If some data needs to be shared, put all of it in a single, large, page boundary GETMAIN'd area and use IAZVSERV to map that between the two address spaces. The DDs remain a problem. -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPYO (was: APF-authorized ...)
On Tue, 17 Mar 2015 13:01:42 -0500, John McKown john.archie.mck...@gmail.com wrote: Now that I think on it, one could mess up the rogue programs attempts to modify an RSA by deliberately messing up the savearea chain pointers in the save area pointed to by TCBFSA to defeat forward save area chaining (perhaps copying the values in that area somewhere else and setting all 72 bytes to x'00'), setting R13 to some page boundary GETMAIN'd storage (get 8K and page protect the second 4K using PGSER), doing the SYNCHX setup previously mentioned, and restoring the save area chain pointers and restoring the FSA values after the SYNCHX returns. Of course, this does not stop a rogue from modifying key 8 storage. It just makes it more difficult to find something interesting to modify. In fact, if there are critical areas which are key 8, GETMAIN them on page boundaries in page multiples and use PGSER to mark them read-only before the SYNCHX and then read-write afterwards. Again, this is not impossible to get around. But it adds another level of coding to the rogue program. But TCBFSA points to one of the more interesting areas for the rogue program to modify :) Yes, you can build in a little more protection by having the main program simply issue SVC 3 rather than restoring registers and branching to R14. But there are probably lots of other key 8 areas you'd still need to worry about. So it's really not a bullet-proof solution. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HMC Integrated console and JAVA
On 3/17/2015 12:17 PM, Alan Field wrote: After seeing the post about an open PMR where IBM acknowledged problems with JAVA 8 I uninstalled it and went back to JAVA7_21. Now my integrated console and operating system messages are available again. I had the same issue just yesterday. I tried to open a hardware PMH via SR, but that didn't work much better. Like you, backing off to Java 7 solved my issue. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://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: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized ...))
In caajsdjgyexftzmrwu-geynan_9wbojog1jk35qbebr8mfp3...@mail.gmail.com, on 03/17/2015 at 09:14 AM, John McKown john.archie.mck...@gmail.com said: I just had a thought (and it's lonely). It's not my dog. Violating system integrity is easy. Safely doing what Charlesv wanted is much more difficult. SYNCHX (15) INVOKES PROGRAM B IN TCB KEY Still able to walk all over your user key storage and yor subpool 0. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized ...))
In caajsdjijjgpxfxevytorprbl-qzj7tqphpswo9bw3g_gjje...@mail.gmail.com, on 03/17/2015 at 08:53 AM, John McKown john.archie.mck...@gmail.com said: I think the original design was to allow an type 3 or 4 SVC to invoke some used supplied code, and do so in TCB key / problem state. And then still be in key 0 / supervisor state when the user code returns. Back in the day access methods were the obvious users and there weren't all those options we have today. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Remaining Mainframes
I am looking to find any remaining Mainframe systems in the Department of Energy? If you are running one, please let me know who you are. /Thomas Kern /On Contract to DOE Headquarters /301-903-2211 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPYO (was: APF-authorized ...)
On Tue, Mar 17, 2015 at 2:04 PM, Walt Farrell walt.farr...@gmail.com wrote: But TCBFSA points to one of the more interesting areas for the rogue program to modify :) That is why you copy the 72 bytes pointed to by it to another area and zero those 72 bytes while other perhap rogue is running. Yes, you can build in a little more protection by having the main program simply issue SVC 3 rather than restoring registers and branching to R14. But there are probably lots of other key 8 areas you'd still need to worry about. So it's really not a bullet-proof solution. Nope, not bullet-proof. But more bullet-resistant against a person with poor aim, or something like that. But if the main worry is not memory corruption, but improper use of APF authorized functions, then it is pretty good. And now I'm back to hawking my UNIX (or ASCRE) solution. Best is just to not require the possibly rogue program. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized ...))
On Tue, 17 Mar 2015 17:58:16 +0100 Thomas Berg thomas.b...@swedbank.se wrote: : -Original Message- : From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of : Walt Farrell : Sent: Tuesday, March 17, 2015 4:18 PM : To: IBM-MAIN@LISTSERV.UA.EDU : Subject: Re: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized : ...)) : On Tue, 17 Mar 2015 09:14:56 -0500, John McKown john.archie.mck...@gmail.com : wrote: : : The SYNCHX is the magic which allows your code to stay key 0 while : invoking the other program in line in key 8. When the program : returns, your code is still key 0. At which point you restore APF : authorization and continue on. : : At which point you have a _major_ system integrity flaw. What about all that key 8 storage your : APF-authorized program has been using? The program you SYNCHX'd to is free to overwrite it. : You cannot trust any of it, including the initial save area that MVS passed to your program, and : where you presumably stored the registers on entry (including the return address). : : When you go to return to the system it's quite possible that you'll go to an address selected by : the rogue routine, and it will be running with APF authority at that point. : : This can only be fully safe if you never have any key 8 storage, or if you copy all your key 8 data : to a system key area before you invoke the unauthorized program, and never use the old key 8 : storage again. That would be made a bit easier for you if your program was added to the PPT as : running in a system key. Then your initial save area and everything you GETMAIN would be in : that system key by default. But if you start out in key 8, you have more work to do. : :May an ignorant peek in here... :) : :Just as a concept and theoretically; wouldn't a way to secure that the key 8 storage is untouched is to save a hash of the content in system key area (with a random salt) ? Then just compare the hashes before reusing the key 8 data. :Of course, this is only feasible if performance is not a problem. :(Not that I'm a knowledgeable person in any of these areas...) You would have to also make sure no STIMERM's are around (or anything else that could run as an ASYNC exit. Of course the AC=1 routine does not need the FSA - it can discard it and getmain a system key work area. -- 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: SMS ACS and TEMP DSN Parsing
At our site we use DATACLAS=special to direct a dataset to a specific storage group. On Tue, Mar 17, 2015 at 2:37 PM, Graham Harris harris...@gmail.com wrote: Would checking the DDNAME and/or PROGRAM help? On 17 March 2015 at 15:10, Vernooij, CP (ITOPT1) - KLM kees.verno...@klm.com wrote: Well, the temp-dsn pattern will probably only change with z/OS releases, so it will (only) be another item on that checklist. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, March 17, 2015 3:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS ACS and TEMP DSN Parsing Yes, that I understand. However, I have always been reluctant to set any TEMP DSN different than other TEMP DSNs. But this is a unique case and I am hoping this will resolve the issue. The other issue is the consistency for the temp DSN pattern. If anything changes, this code will no longer work. (Sigh) Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Shirey Sent: Tuesday, March 17, 2015 7:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS ACS and TEMP DSN Parsing I don't think there's anything wrong with the logic, but you know that most attributes of a DATACLAS can be overridden. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, March 16, 2015 7:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMS ACS and TEMP DSN Parsing I am trying to create a process in the Dataclas that will change some of the dataset attributes of on specific Temp DSN. The DSN comes in with DSTYPE = TEMP Does anyone know if this will work? The DSN will look like this: SYS15070.T105514.RA000.MYDSN1.R0226931 If (DSTYPE = Temp and DSN(4) = 'MYDSN1') Then Do Set Dataclas = X Write DSN set to X Dataclas Exit End -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPYO (was: APF-authorized ...)
In CAAJSdjgEqM=ny94cfmkafhue_fbtvv7tueaphy8284_2m5u...@mail.gmail.com, on 03/17/2015 at 08:40 AM, John McKown john.archie.mck...@gmail.com said: IMO, it would be easier to just use ATTACHX with the JSCB= pointing to a copy of the current task's JSCB with the APF bit flipped off. Why? You still have the same considerations for, e.g., user key storage. Another interesting parameter might be SZERO=NO C/interesting/mandatory/ -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: using bpxwunix with tsocmd to run XMIT
On Tue, Mar 17, 2015 at 7:06 AM, Steve Austin steve.aus...@macro4.com wrote:
Thanks Elardus, but however many quotes I insert they are appear to be
ignored. I've tried the command from OMVS and get the same result (see below).
Steve
Example output from an actual UNIX command line prompt (not BPXWUNIX)
LIH1:TSH009:/home/tsh009$
tsocmd xmit lih1.tsh009 ds('sys1.ppoption')
xmit lih1.tsh009 ds('sys1.ppoption')
INMX000I 0 message and 8 data records sent as 113 records to LIH1.TSH009
INMX001I Transmission occurred on 03/17/2015 at 07:43:04.
LIH1:TSH009:/home/tsh009$
Example REXX code, run from a UNIX prompt, which uses tsocmd to run XMIT
LIH1:TSH009:/home/tsh009$
cat ~/bin/do_xmit.rexx
/* REXX */
command=/bin/tsocmd xmit lih1.tsh009 ds('sys1.ppoption')
say command
call bpxwunix command
LIH1:TSH009:/home/tsh009$
The running of the above
LIH1:TSH009:/home/tsh009$
do_xmit.rexx
/bin/tsocmd xmit lih1.tsh009 ds('sys1.ppoption')
xmit lih1.tsh009 ds('sys1.ppoption')
INMX000I 0 message and 8 data records sent as 113 records to LIH1.TSH009
INMX001I Transmission occurred on 03/17/2015 at 07:54:23.
LIH1:TSH009:/home/tsh009$
--
If you sent twitter messages while exploring, are you on a textpedition?
He's about as useful as a wax frying pan.
10 to the 12th power microphones = 1 Megaphone
Maranatha!
John McKown
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: using bpxwunix with tsocmd to run XMIT
Thanks Elardus, but however many quotes I insert they are appear to be ignored.
I've tried the command from OMVS and get the same result (see below).
Steve
/bin/tsocmd XMIT ZOS113.SA 'DS('SA2.DMXPORT.F5')
£ /bin/tsocmd XMIT ZOS113.SA 'DS('SA2.DMXPORT.F5')'
XMIT ZOS113.SA DS(SA2.DMXPORT.F5)
INMX060I TRANSMIT command terminated. Input dataset unusable +
INMX061I Allocation failed for dataset 'SA2.SA2.DMXPORT.F5' +
IKJ56228I DATA SET SA2.SA2.DMXPORT.F5 NOT IN CATALOG OR CATALOG CAN NOT BE ACCES
SED
£
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Elardus Engelbrecht
Sent: 17 March 2015 10:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: using bpxwunix with tsocmd to run XMIT
Steve Austin wrote:
I'm using bpxwunix with tsocmd to run an XMIT (see below). This works, but
I've been unable to prevent the TSO PREFIX, being added to dataset name; any
quotes I put around the dsn are ignored. Neither have I been able to set
NOPREFIX. Is there a way to prevent the suffix being added?
Old trap for anyone trying string parsing... I sometimes fall in that trap too.
;-)
And you can't do a TRACE to see how lines are parsed and resolved... ouch...
cmd=/bin/tsocmd XMIT target 'DS(dsn)'
Try this (adding a single quote character to the right of ( and to the left of
) ):
cmd=/bin/tsocmd XMIT target 'DS('dsn')'
Note: This is DS, then (, then single quote character, then double quote
character, then variablename dsn, then double quote, single quote and then ).
This is so that the datasetname have single quote chars to the left and right,
all inside the parenthesis.
Something like this after parsing and resolving var names: cmd=/bin/tsocmd
XMIT xyz 'DS('hlq.mlq.lq')'
(Double quote outside string and only single quote inside the string.)
A$$uming of course, as you write, the characters from D to ) are both inside
double and single quote characters.
Geez, I hope I got it right... ;-)
HTH!
Groete / Greetings
Elardus Engelbrecht
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
This e-mail message has been scanned and cleared by Postini / Google Message
Security and the UNICOM Global security systems. This message is for the named
person's use only. If you receive this message in error, please delete it and
notify the sender.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: using bpxwunix with tsocmd to run XMIT
On Tue, 17 Mar 2015 05:39:49 -0500, Elardus Engelbrecht wrote:
Old trap for anyone trying string parsing... I sometimes fall in that trap
too. ;-)
I did, several times, trying to find a solution.
And you can't do a TRACE to see how lines are parsed and resolved... ouch...
trace R helps for Rexx, but not entirely'
set -x works for shell.
cmd=/bin/tsocmd XMIT target 'DS(dsn)'
Try this (adding a single quote character to the right of ( and to the left of
) ):
cmd=/bin/tsocmd XMIT target 'DS('dsn')'
It's even worse. I got it to work with:
trace R
lines.0 = 0
cmd = set -x; /bin/tsocmd XMIT target DS('dsn')
xrc = bpxwunix(cmd, 'lines.', /* out. */, /* err. */, /* env., login,
batch, */ )
(I defaulted most of the arguments in order to see the trace immediately.)
The hard one is RECEIVE -- one needs to QUEUE the reply to the prompt.
That's not always possible.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: using bpxwunix with tsocmd to run XMIT
Steve Austin wrote:
Thanks Elardus, but however many quotes I insert they are appear to be
ignored. I've tried the command from OMVS and get the same result (see below).
So I see after that IKJ message. I assume you do it interactively.
Replace /bin/tsocmd XMIT ZOS113.SA 'DS('SA2.DMXPORT.F5')' with
/bin/tsocmd XMIT ZOS113.SA DS('SA2.DMXPORT.F5')
so, no quotes on DS and its keyword (only quote around datasetname)?
Alternatively: What if you try DDNAME instead of DSNAME?
If no one can help you on IBM-MAIN, I believe you may encountered a rare
parsing problem.
Groete / Greetings
Elardus Engelbrecht
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: using bpxwunix with tsocmd to run XMIT
Paul Gilmartin wrote:
And you can't do a TRACE to see how lines are parsed and resolved... ouch...
trace R helps for Rexx, but not entirely'
set -x works for shell.
Thanks. So I found out the hard way...
It's even worse. I got it to work with:
cmd = set -x; /bin/tsocmd XMIT target DS('dsn')
xrc = bpxwunix(cmd, 'lines.', /* out. */, /* err. */, /* env., login,
batch, */ )
More, but different types of quotes. Ok, next time I will quote you! ;-)
I believe Steve will use your example successfully.
Thanks Paul for kindly helping out. Much appreciated! You can of course quote
me on this.
The hard one is RECEIVE -- one needs to QUEUE the reply to the prompt.
That's not always possible.
Of course.
Groete / Greetings
Elardus Engelbrecht
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: using bpxwunix with tsocmd to run XMIT
/bin/tsocmd XMIT ZOS113.SA DS('SA2.DMXPORT.F5')
Gives;
£ /bin/tsocmd XMIT ZOS113.SA DS('SA2.DMXPORT.F5')
FSUM7332 syntax error: got (, expecting Newline
£
DDNAME is not an option, as ultimately I want this to work using bpwxunix and
the dataset will not be allocated in the address spaces in which xmit runs.
Regards
Steve
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Elardus Engelbrecht
Sent: 17 March 2015 12:26
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: using bpxwunix with tsocmd to run XMIT
Steve Austin wrote:
Thanks Elardus, but however many quotes I insert they are appear to be
ignored. I've tried the command from OMVS and get the same result (see below).
So I see after that IKJ message. I assume you do it interactively.
Replace /bin/tsocmd XMIT ZOS113.SA 'DS('SA2.DMXPORT.F5')' with
/bin/tsocmd XMIT ZOS113.SA DS('SA2.DMXPORT.F5')
so, no quotes on DS and its keyword (only quote around datasetname)?
Alternatively: What if you try DDNAME instead of DSNAME?
If no one can help you on IBM-MAIN, I believe you may encountered a rare
parsing problem.
Groete / Greetings
Elardus Engelbrecht
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
This e-mail message has been scanned and cleared by Postini / Google Message
Security and the UNICOM Global security systems. This message is for the named
person's use only. If you receive this message in error, please delete it and
notify the sender.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: using bpxwunix with tsocmd to run XMIT
Don't quote me, but I now have it working as described.
Thanks for your help!
Steve
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Elardus Engelbrecht
Sent: 17 March 2015 12:37
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: using bpxwunix with tsocmd to run XMIT
Paul Gilmartin wrote:
And you can't do a TRACE to see how lines are parsed and resolved... ouch...
trace R helps for Rexx, but not entirely'
set -x works for shell.
Thanks. So I found out the hard way...
It's even worse. I got it to work with:
cmd = set -x; /bin/tsocmd XMIT target DS('dsn')
xrc = bpxwunix(cmd, 'lines.', /* out. */, /* err. */, /* env.,
login, batch, */ )
More, but different types of quotes. Ok, next time I will quote you! ;-)
I believe Steve will use your example successfully.
Thanks Paul for kindly helping out. Much appreciated! You can of course quote
me on this.
The hard one is RECEIVE -- one needs to QUEUE the reply to the prompt.
That's not always possible.
Of course.
Groete / Greetings
Elardus Engelbrecht
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
This e-mail message has been scanned and cleared by Postini / Google Message
Security and the UNICOM Global security systems. This message is for the named
person's use only. If you receive this message in error, please delete it and
notify the sender.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: using bpxwunix with tsocmd to run XMIT
Steve Austin wrote: Don't quote me, but I now have it working as described. Thanks for your help! You're most welcome, but I believe Paul should get the credits for helping out. About quotes, it reminds me of this old school joke: Teacher: 'Hey, Pete, why are all your answers in quotes?' Pete: 'Sir, they're not mine, they're coming from my pal next to me.' Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPYO (was: APF-authorized ...)
In 5c91d5e7-95b6-439d-87a7-111003a2f...@comcast.net, on 03/16/2015 at 10:52 PM, Ed Gould edgould1...@comcast.net said: Legally no but it can be done . You can, legally, turn APF off and later turn it off. It should be done the way porcupines make love: very carefully. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPYO (was: APF-authorized ...)
On Tue, Mar 17, 2015 at 8:18 AM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 5c91d5e7-95b6-439d-87a7-111003a2f...@comcast.net, on 03/16/2015 at 10:52 PM, Ed Gould edgould1...@comcast.net said: Legally no but it can be done . You can, legally, turn APF off and later turn it off. It should be done the way porcupines make love: very carefully. IMO, it would be easier to just use ATTACHX with the JSCB= pointing to a copy of the current task's JSCB with the APF bit flipped off. Of course, the copy really needs to be in subpool 253 (key 0, below the line). The OP might even want a TASKLIB= if he wants to do a DYNALLOC to specify the DSNs to be searched, perhaps given in a configuration file of some sort. OK, likely overkill in this case. Another interesting parameter might be SZERO=NO to not share subpool zero to avoid memory leaks if, as I have seen, the ATTACH'd program doesn't bother to clean up all its memory because the system will do that automatically. I've especially noticed this in the past because CLOSE didn't always free the I/O buffers when a DCB was closed. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPYO (was: APF-authorized ...)
Shmuel Metz (Seymour J.) wrote: Legally no but it can be done . You can, legally, turn APF off and later turn it off. Turn it off and then again off? Or is there a typo in what you wrote? It should be done the way porcupines make love: very carefully. Or if you're male and in a wrong specie, then only ONCE! I rather feign death to stay out of trouble... ;-) http://en.wikipedia.org/wiki/Sexual_cannibalism Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Tech Skills Heading the Way of the Dinosaur - 2015 Edition
Interesting article that covers both midrange and mainframe platforms http://www.globalknowledge.com/training/generic.asp?pageid=3750 http://www.globalknowledge.com/training/generic.asp?pageid=3750country=Uni ted+Statesutm_medium=emailutm_source=email country=United+Statesutm_medium=emailutm_source=email When we learn a concept for the first time, the newness of it tends to become embedded with the learning process. We remember the new idea's significance and forever after remember it as new. The initial impact of a discovery can prevent the concept from aging. At the same time, we realize how quickly technology advances. Is it time to evolve your expertise? If any of the following reminiscences ring true to you, have you moved beyond them? If not, it might be time to make some new discoveries. To paraphrase the comedian Jeff Foxworthy, You might be a tech dinosaur if ... . Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized ...))
In ca+qm759umgfno+gbxqsgyni1r5uej7dkcdkdzdbnkai...@mail.gmail.com, on 03/16/2015 at 07:10 PM, Scott Ford idfzos...@gmail.com said: I did a quick google on JSCBAUTH and long thread in 2010...very interesting several people mentioned to SYNC and LINK to perform authorized calls unless I misunderstood the thread. The Devil is in the details. SYNC is useful when a dispatching element is in a privileged state; it has nothing to do with whether the address space is in a privileged state. Can you quote anything in that thread to suggest otherwise? If so, it's wrong. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPYO (was: APF-authorized ...)
In CA+qM75_YCpXgMjXrqx=hcbif-qhjktvhz7eunmkcej56pxj...@mail.gmail.com, on 03/16/2015 at 06:20 PM, Scott Ford idfzos...@gmail.com said: can you turn off APF authorization and turn back on ? Easily? Yes. Safely? Only with great care. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized ...))
On Mon, Mar 16, 2015 at 8:15 PM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In ca+qm759umgfno+gbxqsgyni1r5uej7dkcdkdzdbnkai...@mail.gmail.com, on 03/16/2015 at 07:10 PM, Scott Ford idfzos...@gmail.com said: I did a quick google on JSCBAUTH and long thread in 2010...very interesting several people mentioned to SYNC and LINK to perform authorized calls unless I misunderstood the thread. The Devil is in the details. SYNC is useful when a dispatching element is in a privileged state; it has nothing to do with whether the address space is in a privileged state. Can you quote anything in that thread to suggest otherwise? If so, it's wrong. Right. SYNCH and SYNCHX don't say anything about APF authorization. There are parameters which can be used by an APF authorized program which can do things such as changing the PKM (adding new keys in addition to the TCB key), the PSW key, and PSW problem / supervisor state. I've only use SYNCH to run a memory-resident piece of code under a new PRB, not any of the fancy stuff. I think the original design was to allow an type 3 or 4 SVC to invoke some used supplied code, and do so in TCB key / problem state. And then still be in key 0 / supervisor state when the user code returns. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: using bpxwunix with tsocmd to run XMIT
In 2128103613061808.wa.paulgboulderaim@listserv.ua.edu, on
03/17/2015
at 07:19 AM, Paul Gilmartin
000433f07816-dmarc-requ...@listserv.ua.edu said:
cmd = set -x; /bin/tsocmd XMIT target DS('dsn')
I see it now; your original code had the apostrophes around DS(foo)
instead of just around the dsn.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see http://patriot.net/~shmuel/resume/brief.html
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS ACS and TEMP DSN Parsing
I don't think there's anything wrong with the logic, but you know that most attributes of a DATACLAS can be overridden. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, March 16, 2015 7:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMS ACS and TEMP DSN Parsing I am trying to create a process in the Dataclas that will change some of the dataset attributes of on specific Temp DSN. The DSN comes in with DSTYPE = TEMP Does anyone know if this will work? The DSN will look like this: SYS15070.T105514.RA000.MYDSN1.R0226931 If (DSTYPE = Temp and DSN(4) = 'MYDSN1') Then Do Set Dataclas = X Write DSN set to X Dataclas Exit End -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS ACS and TEMP DSN Parsing
Lizette Koehler wrote: However, I have always been reluctant to set any TEMP DSN different than other TEMP DSNs. I will also be reluctant. The other issue is the consistency for the temp DSN pattern. If anything changes, this code will no longer work. (Sigh) Can you force them to be not Temp and force them to use an unique HLQ with its own RACF profile and Dataclass? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized ...))
On Mon, Mar 16, 2015 at 5:31 PM, Charles Mills charl...@mcn.org wrote: I don't really know but my logic goes like this: You can only turn JCSBAUTH back on if you are key 0, otherwise you will S0C4. So you could set key 0, and then turn JSCBAUTH off, do stuff, and then turn it back on again -- but if you are going to run for any length of time doing stuff in key 0 you might just as well leave JSCBAUTH on, and if on the other hand you are going to go to user key, you are stuck there once you turn JSCBAUTH off. Does that make sense? Charles Charles, I just had a thought (and it's lonely). You start off APF authorized, key 8 as a normal APF program. You want to run program B from the STEPLIB, but without APF authorization. Perhaps the simplest way is to use SYNCHX something like: LOAD EP=B ST R0,EPA_B MODESET KEY=ZERO USING PSA,0 L R3,PSATOLD MY TCB USING TCB,R3 L R3,TCBJSCB GET JSCB ADDRESS DROP R3 ICM R3,B'1000',=X'00' CLEAR HIGH BYTE USING IEZJSCB,R3 NI JSCBOPTS,255-JSCBAUTH NOT APF L R15,EPA_B SYNCHX (15) INVOKES PROGRAM B IN TCB KEY OI JSCBOPTS,JSCBAUTH RESTORE APF AUTHORIZATION MODESET KEY=NZERO The SYNCHX is the magic which allows your code to stay key 0 while invoking the other program in line in key 8. When the program returns, your code is still key 0. At which point you restore APF authorization and continue on. -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized ...))
Of course, after this snippet the authorized section cannot trust the contents of any key8 storage. On Tue, 17 Mar 2015 09:14:56 -0500 John McKown john.archie.mck...@gmail.com wrote: :On Mon, Mar 16, 2015 at 5:31 PM, Charles Mills charl...@mcn.org wrote: : I don't really know but my logic goes like this: : : You can only turn JCSBAUTH back on if you are key 0, otherwise you will S0C4. So you could set key 0, and then turn JSCBAUTH off, do stuff, and then turn it back on again -- but if you are going to run for any length of time doing stuff in key 0 you might just as well leave JSCBAUTH on, and if on the other hand you are going to go to user key, you are stuck there once you turn JSCBAUTH off. : : Does that make sense? : : Charles : :Charles, : :I just had a thought (and it's lonely). You start off APF authorized, :key 8 as a normal APF program. You want to run program B from the :STEPLIB, but without APF authorization. Perhaps the simplest way is to :use SYNCHX something like: : : LOAD EP=B : ST R0,EPA_B : MODESET KEY=ZERO : USING PSA,0 : L R3,PSATOLD MY TCB : USING TCB,R3 : L R3,TCBJSCB GET JSCB ADDRESS : DROP R3 : ICM R3,B'1000',=X'00' CLEAR HIGH BYTE : USING IEZJSCB,R3 : NI JSCBOPTS,255-JSCBAUTH NOT APF : L R15,EPA_B : SYNCHX (15) INVOKES PROGRAM B IN TCB KEY : OI JSCBOPTS,JSCBAUTH RESTORE APF AUTHORIZATION : MODESET KEY=NZERO : :The SYNCHX is the magic which allows your code to stay key 0 while :invoking the other program in line in key 8. When the program :returns, your code is still key 0. At which point you restore APF :authorization and continue on. -- 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: using bpxwunix with tsocmd to run XMIT
On Tue, 17 Mar 2015 09:27:53 -0400, Shmuel Metz (Seymour J.) wrote:
on 03/17/2015 at 07:19 AM, Paul Gilmartin said:
cmd = set -x; /bin/tsocmd XMIT target DS('dsn')
I see it now; your original code had the apostrophes around DS(foo)
instead of just around the dsn.
And the parentheses need to be protected from the shell, and if dsn mentions
a PDS member more parentheses need to be protected.
I sometimes post Rexx examples untested (with apologia). This one I tested.
One might wonder, Why was OP doing it this (Byzantine) way?
One plausible answer: This is the simplest (only?) form that works in all of:
o TSO TMP
o shell
o IRXJCL
I keep a UNIX directory in my SYSEXEC. Unsupported; IBM told me so when
I submitted an ETR. But it mostly works except for a few program checks,
always when a command successfully completes, and never more than once
per ISPF session. I endure those, rather than replicate EXECs in PDS and
UNIX directories. Substance for a SER here, perhaps.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS ACS and TEMP DSN Parsing
Yes, that I understand. However, I have always been reluctant to set any TEMP DSN different than other TEMP DSNs. But this is a unique case and I am hoping this will resolve the issue. The other issue is the consistency for the temp DSN pattern. If anything changes, this code will no longer work. (Sigh) Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Shirey Sent: Tuesday, March 17, 2015 7:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS ACS and TEMP DSN Parsing I don't think there's anything wrong with the logic, but you know that most attributes of a DATACLAS can be overridden. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, March 16, 2015 7:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMS ACS and TEMP DSN Parsing I am trying to create a process in the Dataclas that will change some of the dataset attributes of on specific Temp DSN. The DSN comes in with DSTYPE = TEMP Does anyone know if this will work? The DSN will look like this: SYS15070.T105514.RA000.MYDSN1.R0226931 If (DSTYPE = Temp and DSN(4) = 'MYDSN1') Then Do Set Dataclas = X Write DSN set to X Dataclas Exit End -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tech Skills Heading the Way of the Dinosaur - 2015 Edition
Lizette Koehler wrote: Interesting article that covers both midrange and mainframe platforms Indeed. Some of my old skills should be staying in prehistoric times like programming in Clarion and Clipper. You've gotta move on, just what that article suggests. I had to drop them because of platform development. Oh, one thing I think that author forgot was the evolving of viruses, Trojans, worms, etc. I remember how easy it was to get rid of that bouncing ball virus, today you get that stealthy rootkit havoc wreaker which are sometimes impossible to get rid of... You probably remember those bulliten boards on those home computers like Commodore 64 and such? Good days if you can say using those slow unreliable modems are 'good'. Natural Adabas was the rage some years ago in online jobhunting pages, now they're replaced by 1001 other skills in demand... One of these times I will tell my grand-grand-children there was something like 'Ancient Art of Computing.' (Sorry, Sun Tzu to misquote you...) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized ...))
Thanks. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Tuesday, March 17, 2015 7:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized ...)) On Mon, Mar 16, 2015 at 5:31 PM, Charles Mills charl...@mcn.org wrote: I don't really know but my logic goes like this: You can only turn JCSBAUTH back on if you are key 0, otherwise you will S0C4. So you could set key 0, and then turn JSCBAUTH off, do stuff, and then turn it back on again -- but if you are going to run for any length of time doing stuff in key 0 you might just as well leave JSCBAUTH on, and if on the other hand you are going to go to user key, you are stuck there once you turn JSCBAUTH off. Does that make sense? Charles Charles, I just had a thought (and it's lonely). You start off APF authorized, key 8 as a normal APF program. You want to run program B from the STEPLIB, but without APF authorization. Perhaps the simplest way is to use SYNCHX something like: LOAD EP=B ST R0,EPA_B MODESET KEY=ZERO USING PSA,0 L R3,PSATOLD MY TCB USING TCB,R3 L R3,TCBJSCB GET JSCB ADDRESS DROP R3 ICM R3,B'1000',=X'00' CLEAR HIGH BYTE USING IEZJSCB,R3 NI JSCBOPTS,255-JSCBAUTH NOT APF L R15,EPA_B SYNCHX (15) INVOKES PROGRAM B IN TCB KEY OI JSCBOPTS,JSCBAUTH RESTORE APF AUTHORIZATION MODESET KEY=NZERO The SYNCHX is the magic which allows your code to stay key 0 while invoking the other program in line in key 8. When the program returns, your code is still key 0. At which point you restore APF authorization and continue on. -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- 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: SMS ACS and TEMP DSN Parsing
Overriding DC space can be prevented by the 'override space' attribute (yes/no). Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Shirey Sent: Tuesday, March 17, 2015 3:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS ACS and TEMP DSN Parsing I don't think there's anything wrong with the logic, but you know that most attributes of a DATACLAS can be overridden. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, March 16, 2015 7:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMS ACS and TEMP DSN Parsing I am trying to create a process in the Dataclas that will change some of the dataset attributes of on specific Temp DSN. The DSN comes in with DSTYPE = TEMP Does anyone know if this will work? The DSN will look like this: SYS15070.T105514.RA000.MYDSN1.R0226931 If (DSTYPE = Temp and DSN(4) = 'MYDSN1') Then Do Set Dataclas = X Write DSN set to X Dataclas Exit End -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized ...))
On Tue, Mar 17, 2015 at 9:43 AM, Binyamin Dissen bdis...@dissensoftware.com wrote: Of course, after this snippet the authorized section cannot trust the contents of any key8 storage. Yes, I can see how that can be true. Of course, I don't know of a _good_ method to ensure memory protection from a rogue program which runs in the same address space as a trusted program. That's why z/OS UNIX has the concept of a dirty address space and you can get some nasty return codes. That could be considered a plus for doing things like this using UNIX facilities to fork() a child address space to run the untrusted program, and only sharing specific memory pages using UNIX share memory facilities or IAZVSERV. But that then goes back to the problem of the child needing to access DD statements in the parent address space. There are always trade offs. Unless you are willing to go whole hog and only use UNIX facilities, including UNIX files instead of DDs. -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
S0C4 abend after upgrading to z/OS 1.13
Hello, We are experiencing an S0C4 abend after upgrading to z/OS 1.13. The application is known as KBMS, has been unsupported since 2000, and is critical to the business. We are working on a replacement, but full implementation is still several months away. We have experienced problems with the application in previous upgrades, but were able to address it by re-linking some of the programs (we do not have the source). Unfortunately that approach is not working this time, so I'm hoping someone can explain what might be happening and possible solutions. Thanks in advance for any insight that is provided. Here's some detail pulled from Fault Analyzer: (note, only copied events 1-9, 10-128 are recurrences of 6-9) Event Fail Module Program EP # Type Point Name Name Name Event Location (*) Description -- -- -- - -- 1 Link AICVTASK AICVTASK ICVTASK E+20C From SYSTEMS.KBSSKBMS.LOAD.ZOS113 2 Abend S0C4 * AICKBMSE @MEMALOC n/a P+10 From SYSTEMS.KBSSKBMS.LOAD.ZOS113 3 SVC 12 IGC0101C n/a n/a M+844E From LPA 4 Link KBESTAE KBESTAE n/a P+220 From SYSTEMS.KBSSKBMS.LOAD.ZOS113 5 Call KBESTAEM KBESTAEM BESTAEM E+102A From SYSTEMS.KBSSKBMS.LOAD.ZOS113 6 Abend S0C4 AICVMISC AICVMISC n/a P+C36 From SYSTEMS.KBSSKBMS.LOAD.ZOS113 7 SVC 12 IGC0101C n/a n/a M+844E From LPA 8 Call AICKBMS3 AICKBMS3 n/a P+276 From SYSTEMS.KBSSKBMS.LOAD.ZOS113 9 Call KBESTAEM KBESTAEM BESTAEM E+102A From SYSTEMS.KBSSKBMS.LOAD.ZOS113 (*) One or more of the following abbreviations might appear in the Event Location column: F#n Source file number (refer to detailed event information for file identification) L#n Source file line number S#n Listing file statement number (refer to detailed event information for file identification) M+x Offset from start of load module P+x Offset from start of program E+x Offset from start of entry point - H1 I B M F A U L T A N A L Y Z E R E V E N T D E T A I L S - H2 EVENT 1 OF 128: LINK (DSA ADDRESS 00083558) NOTE: Source code information for CSECT AICVTASK could not be presented because no compiler listing or side-file data sets were provided. Load Module Name. . . . . . : SYSTEMS.KBSSKBMS.LOAD.ZOS113(AICVTASK) At Address. . . . . . . . : 00054DF0 Load Module Length. . . . : X'1210' Link-Edit Date and Time . : 1994/12/14 00:00:00 CSECT Name. . . . . . . . . : AICVTASK At Address. . . . . . . . : 00054DF0 (Module AICVTASK offset X'0') CSECT Length. . . . . . . : X'120C' CSECT Language. . . . . . : Assembler (Compiled using Assembler H V2 R1 M0 on 1992/01/21) Entry Point Name. . . . . : ICVTASK At Address. . . . . . . : 00054DF0 (CSECT AICVTASK offset X'0') Machine Instruction . . . . : 0A06 SVC 6 (LINK LINKX) At Address. . . . . . . . : 00054FFC (CSECT AICVTASK offset X'20C') AMODE . . . . . . . . . . : 24 Additional instructions around event offset: Offset HexInstruction -- -- -- -30 47E0 C3A6 BC 14,934(,R12) -2C 5810 70DC L R1,220(,R7) -28 5010 8000 ST R1,0(,R8) -24 4110 8000 LA R1,0(,R8) -20 9680 1000 OI 0(R1),128 -1C 47F0 C1F4 BC 15,500(,R12) -18 D20B 8074 9154 MVC 116(12,R8),340(R9) -12 900C D014 STM R0,R12,20(R13) -E 1811 LR R1,R1 -C 41F0 8074 LA R15,116(,R8) -8 4100 5020 LA R0,32(,R5) -4 5000 F000 ST R0,0(,R15) * 0A06 SVC 6(LINK LINKX) +2 58D0 021C L R13,540 +6 58DD 0070 L R13,112(R13) +A 58DD 0008 L R13,8(R13) +E 980C D014 LM R0,R12,20(R13) +12 12FF LTR R15,R15 +14 4770 C22C BC 7,556(,R12) +18 5810 021C L R1,540 Program Status Word (PSW) . : 078D3000 00054FFE General Purpose Registers: R0: 00067F20 (422112 bytes of storage addressable) R1: 000815E0 (317984 bytes of storage addressable) R2: 00055A88 (Module AICVTASK CSECT AICVTASK + X'C98') R3: 000815E0 (317984 bytes of storage addressable) R4: 00067F00 (422144 bytes of storage addressable) R5: 00067F00 (422144 bytes of storage addressable) R6: 000817A8 (317528 bytes of storage addressable) R7: 000815E0 (317984 bytes of storage addressable) R8: 000835A8 (309848 bytes of storage addressable) R9: 00055DF0 (Module AICVTASK CSECT AICVTASK + X'1000') R10: 00013000 (20480 bytes of storage addressable) R11: 00083728 (309464 bytes of storage addressable) R12: 00054DF0 (Module AICVTASK CSECT AICVTASK + X'0') R13: 00083558 (309928 bytes of storage
Re: S0C4 abend after upgrading to z/OS 1.13
The problem is R2: R2: 4F1D6048 (Storage invalid) If you have a dump that you can actually look at, see if there is something reasonable at 001D6048. Otherwise, you'll need to try to backtrack where this value came from. If the data at address 001D6048 looks reasonable, then you need to figure out how the high order byte got set ot x'4F'. Well, I know nada about that package. The fact that the CSECT names all start with @MEM is suspicious. One question would be what release of z/OS did it last run on successfully? And I have two entries you could try with _might_ help. But, then again, they might not. In the DIAGnn member of PARMLIB, try putting in two lines like: VSM USEZOSV1R9RULES(YES) CBLOC VIRTUAL24(IHALCCA,IHAPCCA) http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2E2B0/31.6 and, less likely, in IEASYSnn you might try CSCBLOC=BELOW I've had really old programs blow up when the CSCB is above the line. But this can have a negative impart on the use of common memory below the line. Please read up on this. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2e2b0/54.8.14 The first two can be dynamically adjusted by putting them in a DIAGnn member of PARMLIB and the issuing the command: T DIAG=nn The latter requires an IPL to change. On Tue, Mar 17, 2015 at 11:12 AM, Jerry Criste jerry.cri...@la-z-boy.com wrote: Hello, We are experiencing an S0C4 abend after upgrading to z/OS 1.13. The application is known as KBMS, has been unsupported since 2000, and is critical to the business. We are working on a replacement, but full implementation is still several months away. We have experienced problems with the application in previous upgrades, but were able to address it by re-linking some of the programs (we do not have the source). Unfortunately that approach is not working this time, so I'm hoping someone can explain what might be happening and possible solutions. Thanks in advance for any insight that is provided. snip Instructions around point of failure: Offset HexInstruction -- -- - -10 90C8 C01C STM R12,R8,28(R12) -C 18FC LR R15,R12 -A 41C0 C050 LA R12,80(,R12) -6 18EB LR R14,R11 -4 5820 F000 L R2,0(,R15) * 5870 2005 L R7,5(,R2) +4 D203 F014 7001 MVC 20(4,R15),1(R7) +A 5860 F004 L R6,4(,R15) +E 1876 LR R7,R6 +10 4170 0007 LA R7,7 +14 1476 NR R7,R6 +16 1277 LTR R7,R7 Program Status Word (PSW) . : 078D2000 9970FB58 General Purpose Registers: R0: 0003 (651264 bytes of storage addressable) R1: 1970FCD8 (Module AICKBMSE CSECT @MEMFREE + X'0') R2: 4F1D6048 (Storage invalid) R3: 199DE000 (1069056 bytes of storage addressable) R4: (2048 bytes of storage addressable) R5: 0001 (2047 bytes of storage addressable) R6: (2048 bytes of storage addressable) R7: 0001 (2047 bytes of storage addressable) R8: 0008 (2040 bytes of storage addressable) R9: 104D6000 (Storage invalid) R10: 199C6008 (1167352 bytes of storage addressable) R11: 1970FB48 (Module AICKBMSE CSECT @MEMALOC + X'0') R12: 199C86D8 (1157416 bytes of storage addressable) R13: 9970FE80 (Module AICKBMSE CSECT @MEMZER0 + X'20') R14: 1970FB48 (Module AICKBMSE CSECT @MEMALOC + X'0') R15: 199C8688 (1157496 bytes of storage addressable) Virtual Storage Map AREA ADDRESS SIZE 64-BIT HIGH PRIVATE AREA 0002 8191P 64-BIT SHARED AREA 0200 510T 64-BIT COMMON AREA 01EF8000 67583.9M 64-BIT LOW PRIVATE AREA 00088000 1948.00G 64-BIT JAVA AREA8000 30720.0M --- 2 GIG BOUNDARY --- EXTENDED PRIVATE AREA1970 1641M EXTENDED COMMON SERVICE AREA (ECSA)09C28000 256864K EXT MODIFIED LINK PACK AREA (MLPA)09C27000 4K EXT FIXED LINK PACK AREA (FLPA) 09C24000 12K EXT PAGEABLE LINK PACK AREA (PLPA) 05848000 69488K EXTENDED SYSTEM QUEUE AREA (ESQA) 01B1 62688K EXTENDED NUCLEUS 0100 11328K -- 16 MEG BOUNDARY --- NUCLEUS 00FD3000 180K SYSTEM QUEUE AREA (SQA)
Re: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized ...))
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Walt Farrell Sent: Tuesday, March 17, 2015 4:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Turning JSCBAUTH off and back on again (Was: IEBCOPYO (was: APF-authorized ...)) On Tue, 17 Mar 2015 09:14:56 -0500, John McKown john.archie.mck...@gmail.com wrote: The SYNCHX is the magic which allows your code to stay key 0 while invoking the other program in line in key 8. When the program returns, your code is still key 0. At which point you restore APF authorization and continue on. At which point you have a _major_ system integrity flaw. What about all that key 8 storage your APF-authorized program has been using? The program you SYNCHX'd to is free to overwrite it. You cannot trust any of it, including the initial save area that MVS passed to your program, and where you presumably stored the registers on entry (including the return address). When you go to return to the system it's quite possible that you'll go to an address selected by the rogue routine, and it will be running with APF authority at that point. This can only be fully safe if you never have any key 8 storage, or if you copy all your key 8 data to a system key area before you invoke the unauthorized program, and never use the old key 8 storage again. That would be made a bit easier for you if your program was added to the PPT as running in a system key. Then your initial save area and everything you GETMAIN would be in that system key by default. But if you start out in key 8, you have more work to do. May an ignorant peek in here... :) Just as a concept and theoretically; wouldn't a way to secure that the key 8 storage is untouched is to save a hash of the content in system key area (with a random salt) ? Then just compare the hashes before reusing the key 8 data. Of course, this is only feasible if performance is not a problem. (Not that I'm a knowledgeable person in any of these areas...) Best Regards, Thomas Berg ___ Thomas Berg Specialist zOS/RQM/IT Delivery Swedbank AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 abend after upgrading to z/OS 1.13
On Tue, 17 Mar 2015 16:12:53 +, Jerry Criste wrote: Hello, We are experiencing an S0C4 abend after upgrading to z/OS 1.13. I can't read your Fault Analyzer report because of the formatting. You didn't say what release of z/OS you were coming from, but one possibility is that your code is marked reentrant, but is not really, and is coming from an APF authorized library. If that is the case, it is loaded into key zero storage that is not retch protected. If that is the case, you will S0C1 when you store into it. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPYO (was: APF-authorized ...)
On Tue, 17 Mar 2015 10:07:37 -0500, Walt Farrell walt.farr...@gmail.com wrote: It is not specifically that the programs may misbehave, but that the users may misbehave. If you trust the users not to misbehave, then you can safely let them run the program. If you don't trust them, then you should not let them run it. Clarification: ... should not let them run it *in*a*privileged*state*. I like John M's idea of running subtasks in separate address spaces, fork() or BPX1EXM. He mentioned the complications. SMP/E has a head start: the DDDEF list could be passed to the child process, and it could perform the allocations. (Not so)SMOP. I do wish that IBM would describe the exact nature of the possible user misbehavior. Then folks like Charles would know more about the kind of program behavior they need to consider when deciding whether it's safe to invoke a program while running APF-authorized. Of course, if the possible user misbehavior were described in detail, then the malicious users would also know more about how to look for such potentially exploitable situations. That makes it difficult to convince everyone to improve that documentation. Nowadays, if I specify NOWAIT on all my DDDEFs, I believe (not rigorously tested) I can run SMP/E unauthorized. It would be a favor to me if SMP/E, when it runs unauthorized, did not enforce the RACF checks. I suspect this would not be widely beneficial. And other programmers might need the utilities to run authorized anyway. On Tue, 17 Mar 2015 10:18:26 -0500, Walt Farrell walt.farr...@gmail.com wrote: ... When you go to return to the system it's quite possible that you'll go to an address selected by the rogue routine, and it will be running with APF authority at that point. Sigh. Cf. UNIX, which certainly doesn't let exit() branch to a user-modifiable address. A better designed END SVC would branch, not to the R15 in a key 8 RSA, but to a caller's address kept in protected storage. This can only be fully safe if you never have any key 8 storage, or if you copy all your key 8 data to a system key area before you invoke the unauthorized program, and never use the old key 8 storage again. That would be made a bit easier for you if your program was added to the PPT as running in a system key. Then your initial save area and everything you GETMAIN would be in that system key by default. But if you start out in key 8, you have more work to do. For a modest start, I can naively wonder why, by default, authorized programs don't start in a system key? Oops! would the STM on entry S0C4? Than could be fixed by copying the RSA to that system key and addressing that with R13. I suppose all the conventions were established before there was any such thing as a nonzero system key. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
