Re: SSL Error
#define EIO 122 /* Input/output error */ Found in CEE.SCEEH.H(ERRNO). It doesn't really help, though! Robin -Original Message- From: IBM Mainframe Discussion List On Behalf Of Roberto Halais Sent: Wednesday, November 29, 2023 8:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SSL Error Hi: I am doing an FTPS from z/OS 2.4 to a server and am getting the following GSK error: SP01 MESSAGE 0004 08:47:20.122796 SSL_ERROR Job TCPIP Process 037C Thread 0002 gsk_read_v3_record Errno 007A (122) Socket read failed from 192.168.99.25.21 I have not been able to find the ERRNO 007A (122) Any help would be appreciated. Thank you, Roberto Halais -- 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: Building AMODE 31 Assembler DLL
FWIW, the EXPORT parameter causes a ENTNAME XATTR LINKAGE(XPLINK),SCOPE(EXPORT) statement to get generated, so you could include one yourself, with whatever macro you are using. Robin -Original Message- From: IBM Mainframe Discussion List On Behalf Of Eric Erickson Sent: Sunday, September 24, 2023 9:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Building AMODE 31 Assembler DLL Thanks for the that pointer. I had not gotten to that manual as yet. But for a follow on question. As these are routines called from C, I've been using EDCPRLG as the entry code. Can I switch those out for CEEENTRY, as EDCPRLG does not have the EXPORT keyword. Taking a quick look at the CEEENTRY macro, it looks like I will need to code MAIN=NO, as these are not main routines. Again, thanks for the pointer. The XL C manuals only reference EDCPRLG for assembler routine. I can see that the manual you referenced will become one of my goto references for the near term future. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OSMF and Zowe
Thanks, Brian and Matt. Perhaps the fact that you can get Zowe directly from IBM will help mitigate the prejudice against open source! Robin -Original Message- From: IBM Mainframe Discussion List On Behalf Of Brian Westerman Sent: Wednesday, September 20, 2023 12:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OSMF and Zowe I believe you can still order CBIPO, but z/OSMF does (unfortunately) seem to be the way IBM wants everyone to go. I personally disagree with z/OSMF for many reasons (most of them due to overhead and capability restrictions), but mine seems to be a waste of breath. :) Any way ZOWE is open source, and many shops won't allow that. It's actually a pretty good idea, but still some shops see open source as inherently evil. Brian -- 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
z/OSMF and Zowe
Would it be correct to say that every shop has z/OSMF installed because that is the only method of updating your system that IBM now supports? Ordering CBPDOs (or whatever they were called) is no longer an option? OTOH, Zowe is an open-source project that the average shop will not be using? So if you want to ship a product that uses it, the customer will have to install it? TIA Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XLC - Weak symbols
You are, of course, right but using LET just means you should pay attention to your binder listings! -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Harminc Sent: Friday, May 5, 2023 5:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XLC - Weak symbols On Fri, 5 May 2023 at 10:54, Robin Atwood wrote: > You don't need to do anything in the C code but the Binder will give a > missing external reference (IEW2456E) message. You can specify LET in > the Binder options to treat RC=8 as non-fatal. > This, imho, is a Very Bad Idea. Once you start with telling the Binder OK: RC 8 is fine, then at some point you'll get a real RC 8 for something else, and it'll get into your build unnoticed. BTDT with SMP/E too many times... Tony H. -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Neale Ferguson > Sent: Friday, May 5, 2023 2:53 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: XLC - Weak symbols > > Is it possible to declare a “weak” symbol with XLC? i.e. Using GNU C I > can either > > #pragma weak > extern void * ; > extern void * __attribute__((weak)); > > But neither of these forms are accepted by XLC and I can’t see > anything in the language reference. > > I want to define a symbol that may or may not be present at link time > such that it is NULL if not found but don’t want the linker flagging > it as an error (a warning is fine). > > Neale > -- 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: XLC - Weak symbols
You don't need to do anything in the C code but the Binder will give a missing external reference (IEW2456E) message. You can specify LET in the Binder options to treat RC=8 as non-fatal. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Neale Ferguson Sent: Friday, May 5, 2023 2:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: XLC - Weak symbols Is it possible to declare a “weak” symbol with XLC? i.e. Using GNU C I can either #pragma weak extern void * ; extern void * __attribute__((weak)); But neither of these forms are accepted by XLC and I can’t see anything in the language reference. I want to define a symbol that may or may not be present at link time such that it is NULL if not found but don’t want the linker flagging it as an error (a warning is fine). Neale -- 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: Inexplicable 0C4!
The interruptible instructions (usually) only get interrupted if the string is longer than 256 bytes, which is not usually the case. We just need a simple function for operating on short strings, very often. Some of the suggestions to allocate lots of extra pages were somewhat missing the point! -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Crayford Sent: Friday, April 28, 2023 7:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Inexplicable 0C4! On 28/4/23 19:57, Robin Atwood wrote: > I need to know the length of the string, preferably without needing a > new parameter and altering a lot of code. At which point I remembered > that the XL/C compiler generates inline code for the strlen(s) function. For > those who are interested, this is: Why don't you just use TRT like the C/C++ compiler does for it's inline string handling optimizations? In our experience those interruptible instructions may seem like syntactic sugar but they don't perform better. The only noticeable difference was the introduction of the SIMD instructions. > > LRR4,R2 copy string ptr > XRR0,R0 search for zero byte > SRST R0,R4 search > BO*-4 resume search > SLR R0,R2 get length > > I assume some magic causes the SRST not to "recognize an access > exception" because normally the first register > (R0 here) contains an address limiting the search. Well, that was an > interesting exercise! > > Thanks > > On Fri, Apr 28, 2023 at 6:33 PM Robin Atwood wrote: > >> Thanks, Michael, that is the problem. The next page is available, but >> the one after that isn't. Obviously, I had read the entry for TRE in >> the PoOps but didn't take in the significance of the Access >> Exceptions clause. (In fact, I still don't understand it: >> "may or may not"!) >> >> The problem is I maintain legacy C code originally developed with >> SAS/C, which had a strupr(s) function. There is no length parameter, >> so I was at a loss what to set R1+1 to for the TRE instruction. >> I could search for the zero bytes using SRST but presumably that >> would hit the same problem going off the end of a page. >> Although, the SRST will wrap at top of storage - what does that imply? >> I could invent the strnupr(s,n) function but that will involve many >> code changes. ☹ >> >> @Ed Jaffe: thanks for the tip about the TEA, but where do you find it? >> IPCS STATUS FAILDATA displays it but, in my dumps, PSA+90 and PDS+A8 >> both have zero in the address part. >> >> Thanks to all who replied. >> >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Michael Stein >> Sent: Thursday, April 27, 2023 10:20 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Inexplicable 0C4! >> >> On Thu, Apr 27, 2023 at 07:58:23PM +0700, Robin Atwood wrote: >>> I have had two of these during the course of two months, so it's >>> getting serious! >>> >>> The abend happens in my implementation of a C strupr() function when >>> the TRE instruction is executed: >>> >>> TST TRE R2,R1 fold string >>> >>> R0 R1 R2 R3PSW >>> >>> 0009C5EC 1AA748F8 7FFF 078D04008009BD14 >> from principles of operation TRE: >> >>Access exceptions for the portion of the first operand to the right of >>the last byte processed may or may not be recognized. For an operand >>longer than 4K bytes, access exceptions are not recognized for locations >>more than 4K bytes beyond the last byte processed. >> >>Access exceptions for all 256 bytes of the second operand may be >>recognized, even if not all bytes are used. >> >> The first operand is > 4K bytes, R2 is 1AA748F8, what's the status of >> the next page? >> >> R1 looks ok as the 2nd operand only needs to clear 256 bytes. >> > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Inexplicable 0C4!
I was thinking along those lines but then had a better idea. See my other post. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Michael Stein Sent: Friday, April 28, 2023 6:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Inexplicable 0C4! On Fri, Apr 28, 2023 at 03:32:59PM +0700, Robin Atwood wrote: > Thanks, Michael, that is the problem. The next page is available, but > the one after that isn't. > The problem is I maintain legacy C code originally developed with > SAS/C, which had a strupr(s) function. There is no length parameter, > so I was at a loss what to set R1+1 to for the TRE instruction. You could look at the TRE instrucion as an optimization and not expect it to do all the work. How about setting the length to include just to the end of the current page. Then as the first operand doesn't cross a page boundary it should avoid the 0C4 since the original address was to a valid storage location and it won't go outside that 4K page. After the TRE the CC is set: For CC 3 the TRE hasn't found the end and there still are bytes to process in the first operand so you loop back to the TRE. For CC 1 the TRE has found the end character so you are done. For CC 0 the TRE has landed on the start of the next page without finding the end character so you give it 4K more (set the length to 4K) branch back to the TRE. -- 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: Inexplicable 0C4!
I need to know the length of the string, preferably without needing a new parameter and altering a lot of code. At which point I remembered that the XL/C compiler generates inline code for the strlen(s) function. For those who are interested, this is: LRR4,R2 copy string ptr XRR0,R0 search for zero byte SRST R0,R4 search BO*-4 resume search SLR R0,R2 get length I assume some magic causes the SRST not to "recognize an access exception" because normally the first register (R0 here) contains an address limiting the search. Well, that was an interesting exercise! Thanks On Fri, Apr 28, 2023 at 6:33 PM Robin Atwood wrote: > Thanks, Michael, that is the problem. The next page is available, but > the one after that isn't. Obviously, I had read the entry for TRE in > the PoOps but didn't take in the significance of the Access Exceptions > clause. (In fact, I still don't understand it: > "may or may not"!) > > The problem is I maintain legacy C code originally developed with > SAS/C, which had a strupr(s) function. There is no length parameter, > so I was at a loss what to set R1+1 to for the TRE instruction. > I could search for the zero bytes using SRST but presumably that would > hit the same problem going off the end of a page. > Although, the SRST will wrap at top of storage - what does that imply? > I could invent the strnupr(s,n) function but that will involve many > code changes. ☹ > > @Ed Jaffe: thanks for the tip about the TEA, but where do you find it? > IPCS STATUS FAILDATA displays it but, in my dumps, PSA+90 and PDS+A8 > both have zero in the address part. > > Thanks to all who replied. > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Michael Stein > Sent: Thursday, April 27, 2023 10:20 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Inexplicable 0C4! > > On Thu, Apr 27, 2023 at 07:58:23PM +0700, Robin Atwood wrote: > > I have had two of these during the course of two months, so it's > > getting serious! > > > > The abend happens in my implementation of a C strupr() function when > > the TRE instruction is executed: > > > > TST TRE R2,R1 fold string > > > > R0 R1 R2 R3PSW > > > > 0009C5EC 1AA748F8 7FFF 078D04008009BD14 > > from principles of operation TRE: > > Access exceptions for the portion of the first operand to the right of > the last byte processed may or may not be recognized. For an operand > longer than 4K bytes, access exceptions are not recognized for locations > more than 4K bytes beyond the last byte processed. > > Access exceptions for all 256 bytes of the second operand may be > recognized, even if not all bytes are used. > > The first operand is > 4K bytes, R2 is 1AA748F8, what's the status of > the next page? > > R1 looks ok as the 2nd operand only needs to clear 256 bytes. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Inexplicable 0C4!
Thanks, Michael, that is the problem. The next page is available, but the one after that isn't. Obviously, I had read the entry for TRE in the PoOps but didn't take in the significance of the Access Exceptions clause. (In fact, I still don't understand it: "may or may not"!) The problem is I maintain legacy C code originally developed with SAS/C, which had a strupr(s) function. There is no length parameter, so I was at a loss what to set R1+1 to for the TRE instruction. I could search for the zero bytes using SRST but presumably that would hit the same problem going off the end of a page. Although, the SRST will wrap at top of storage - what does that imply? I could invent the strnupr(s,n) function but that will involve many code changes. ☹ @Ed Jaffe: thanks for the tip about the TEA, but where do you find it? IPCS STATUS FAILDATA displays it but, in my dumps, PSA+90 and PDS+A8 both have zero in the address part. Thanks to all who replied. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Michael Stein Sent: Thursday, April 27, 2023 10:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Inexplicable 0C4! On Thu, Apr 27, 2023 at 07:58:23PM +0700, Robin Atwood wrote: > I have had two of these during the course of two months, so it's > getting serious! > > The abend happens in my implementation of a C strupr() function when > the TRE instruction is executed: > > TST TRE R2,R1 fold string > > R0 R1 R2 R3PSW > > 0009C5EC 1AA748F8 7FFF 078D04008009BD14 from principles of operation TRE: Access exceptions for the portion of the first operand to the right of the last byte processed may or may not be recognized. For an operand longer than 4K bytes, access exceptions are not recognized for locations more than 4K bytes beyond the last byte processed. Access exceptions for all 256 bytes of the second operand may be recognized, even if not all bytes are used. The first operand is > 4K bytes, R2 is 1AA748F8, what's the status of the next page? R1 looks ok as the 2nd operand only needs to clear 256 bytes. -- 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
Inexplicable 0C4!
I have had two of these during the course of two months, so it's getting serious! The abend happens in my implementation of a C strupr() function when the TRE instruction is executed: L R3,=X'7FFF'string maximum length XRR0,R0 zero terminator byte LA R1,UPRXtranslate table TST TRE R2,R1 fold string BC 1,TSTresume translation R0 R1 R2 R3 PSW 0009C5EC 1AA748F8 7FFF 078D04008009BD14 The memory pointed to by R1 and R2 is addressable and in Sp0, key 8, so bog standard. I know R3 looks dodgy, but that is because the string to be upper-cased must be zero byte terminated. R2 points at X'D4C6C9E3E2E3404000', so the format is correct. Given all this, why has the instruction caused an abend? The code lives in a server that is running all day, every day. I wondered if the target data had been released by another task, but VSMDATA showed a DQE for the data's page and no FQE for the data itself, so the data should still be available (as I understand it). Notice R3 hasn't changed, so the abend happened on the very first byte. Any suggestions gratefully received! Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: USS zlib issues
Thanks, Mark, that's very helpful. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Zelden Sent: Friday, March 17, 2023 10:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: USS zlib issues I meant to add that the sourceid is PUT2208, RSU2209. I'm at RSU2212. Best Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html On Fri, 17 Mar 2023 10:09:50 -0500, Mark Zelden wrote: >It's good on my system. This is the PTF that last updated it all. >it's security / integrity so you won't find out much about it. > > >++ PTF (UJ09020)/* >//UJ09020 JOB 5695-09020,SCPX7,MSGLEVEL=(1,1),CLASS=A */ . >++VER(Z038) FMID(HOT77C0) > SUP(AA60361,AA63294,CA57154,CA57870,CA58433,CA63294,UA99527,UJ00876, > UJ01516,UJ08514) > /* > PROBLEM DESCRIPTION(S): >OA63294 - > INTEGRITY PROBLEM -- 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: [EXTERNAL] Re: USS zlib issues
Thanks, Ann, that's very useful to know. I will pass on the info to our sysprogs. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ann Kelley Sent: Friday, March 17, 2023 7:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: USS zlib issues I checked my z/OS 2.4 system. At RSU2008, the zlibs were truncated. At RUS2212, the files were restored to what appears to be proper length --- UJ09020 is the latest PTF for this part, at RSU2212. -- 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: USS zlib issues
Thanks, Barbara, I will forward your post to the sysprog! I don't know if our z/OS 2.5 has had any maintenance yet. Robin -Original Message- From: IBM Mainframe Discussion List On Behalf Of Barbara Nitz Sent: Thursday, March 16, 2023 4:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: USS zlib issues Hi Robin, >drwxr-xr-x 2 BPXROOT RSEGROUP8192 Apr 19 2021 IBM >-rwxr-xr-x 2 BPXROOT RSEGROUP 1012800 Apr 19 2021 libzz.a >-rwxr-xr-x 2 BPXROOT RSEGROUP 405520 Apr 19 2021 libzz.so >-rwxr-xr-x 2 BPXROOT RSEGROUP 252 Apr 19 2021 libzz.x >-rwxr-xr-x 2 BPXROOT RSEGROUP 417840 Apr 19 2021 libzz64.so >-rwxr-xr-x 2 BPXROOT RSEGROUP 252 Apr 19 2021 libzz64.x >-rwxr-xr-x 2 BPXROOT RSEGROUP 413760 Apr 19 2021 libzzX.so >-rwxr-xr-x 2 BPXROOT RSEGROUP 252 Apr 19 2021 libzzX.x your *.x files are definitely truncated. They all have al length of 252 which is extremely unlikely. This is what it looks like on my system (only the *x files): libzz.x fff--- --s- BPXROOT SYS1 6723 libzzX.xfff--- --s- BPXROOT SYS1 6723 libzz64.x fff--- --s- BPXROOT SYS1 7209 The last change date on mine is 2023/01/06, which is the time I last put maintenance in. No idea what that was, but I guess that's your only chance of fixing the truncated stuff. The date you show is when this stuff was first installed by IBM. I am guessing for the ServerPac. Regards, Barbara -- 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
USS zlib issues
We have discovered something odd with the zlib that comes with z/OS 2.5. AFAWCT (our principle sysprog recently retired), zlib is just delivered as part of USS and is used with zEDC, we didn't do anything special to order it. The libraries live under /usr/lpp/hzc and we see: $ ll /usr/lpp/hzc/lib total 4560 drwxr-xr-x 2 BPXROOT RSEGROUP8192 Apr 19 2021 IBM -rwxr-xr-x 2 BPXROOT RSEGROUP 1012800 Apr 19 2021 libzz.a -rwxr-xr-x 2 BPXROOT RSEGROUP 405520 Apr 19 2021 libzz.so -rwxr-xr-x 2 BPXROOT RSEGROUP 252 Apr 19 2021 libzz.x -rwxr-xr-x 2 BPXROOT RSEGROUP 417840 Apr 19 2021 libzz64.so -rwxr-xr-x 2 BPXROOT RSEGROUP 252 Apr 19 2021 libzz64.x -rwxr-xr-x 2 BPXROOT RSEGROUP 413760 Apr 19 2021 libzzX.so -rwxr-xr-x 2 BPXROOT RSEGROUP 252 Apr 19 2021 libzzX.x The problem is with the *.x files (which contain import statements); they are truncated. If you try and include them in a Binder step you get: IEW2797S UNIX FILE ASSOCIATED WITH ddname HAS INVALID RECORD FORMAT. with an explanation that USS program objects should be multiples of 4096 long. We had a look at another LPAR and that was the same. There is an easy workaround which is to code your own IMPORT statements, but I find it a bit odd that we have a corrupt install. Can someone take a quick look and see if they have the same thing? If so, we will open a problem with IBM. TIA Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Amode 64 JSON library?
@David I take your point but I fear my management won't see it that way, reinventing the wheel and all that. I shall spend today experimenting with rebuilding parameter lists, which is likely to be a useful technique in this whole exercise. -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Crayford Sent: Monday, March 13, 2023 10:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Amode 64 JSON library? My advice is to abandon the horrible Web Enablement services and build a good C JSON parser like json-c. Even better if you can ditch C and use C++ because then you have some very nice options. https://github.com/json-c/json-c https://github.com/nlohmann/json On 13/3/23 18:07, Robin Atwood wrote: > Yes, we are linking in HWTJCSS. It only contains 18 entry points for the 31 > bit routines, AFAICT. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Colin Paice > Sent: Monday, March 13, 2023 4:16 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Amode 64 JSON library? > > Are you using > Linkage stub method > <https://www.ibm.com/docs/en/zos/2.5.0?topic=parser-syntax-linkage-programming-considerations>(Recommended) > Use the linkable stub routine HWTJCSS from SYS1.CSSLIB to link edit > yourobject code. > <https://www.ibm.com/docs/en/zos/2.5.0?topic=parser-syntax-linkage-programming-considerations> > Colin > > On Mon, 13 Mar 2023 at 08:55, Robin Atwood wrote: > >> I am investigating the implications of converting a large body of C >> code to >> 64 bit. Compiling with LP64 seems >> straightforward, the problems are at the binder step. I am currently >> getting IEW2469E Reason 3: >> >> "Either the reference or the target is in amode 64 and the amodes do >> not match." >> >> This I was expecting; what I wasn't expecting is an apparent lack of >> 64 bit entry points for the JSON routines. The IBM doc >> >> https://www.ibm.com/docs/en/zos/2.5.0?topic=parser-syntax-linkage-prog >> rammin >> g-considerations >> <https://www.ibm.com/docs/en/zos/2.5.0?topic=parser-syntax-linkage-pro >> gramming-considerations> makes no mention of 64 bit calls. I have >> searched, examined header files, looked at samples, but have found no >> clue. >> Am I missing something incredibly obvious or do I have to code stub >> routines myself to convert the parameter lists? >> Has anyone else encountered this? >> >> TIA >> Robin >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, send >> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Amode 64 JSON library?
Yes, we are linking in HWTJCSS. It only contains 18 entry points for the 31 bit routines, AFAICT. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Colin Paice Sent: Monday, March 13, 2023 4:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Amode 64 JSON library? Are you using Linkage stub method <https://www.ibm.com/docs/en/zos/2.5.0?topic=parser-syntax-linkage-programming-considerations>(Recommended) Use the linkable stub routine HWTJCSS from SYS1.CSSLIB to link edit yourobject code. <https://www.ibm.com/docs/en/zos/2.5.0?topic=parser-syntax-linkage-programming-considerations> Colin On Mon, 13 Mar 2023 at 08:55, Robin Atwood wrote: > I am investigating the implications of converting a large body of C > code to > 64 bit. Compiling with LP64 seems > straightforward, the problems are at the binder step. I am currently > getting IEW2469E Reason 3: > > "Either the reference or the target is in amode 64 and the amodes do > not match." > > This I was expecting; what I wasn't expecting is an apparent lack of > 64 bit entry points for the JSON routines. The IBM doc > > https://www.ibm.com/docs/en/zos/2.5.0?topic=parser-syntax-linkage-prog > rammin > g-considerations > <https://www.ibm.com/docs/en/zos/2.5.0?topic=parser-syntax-linkage-pro > gramming-considerations> makes no mention of 64 bit calls. I have > searched, examined header files, looked at samples, but have found no > clue. > Am I missing something incredibly obvious or do I have to code stub > routines myself to convert the parameter lists? > Has anyone else encountered this? > > TIA > Robin > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Amode 64 JSON library?
I am investigating the implications of converting a large body of C code to 64 bit. Compiling with LP64 seems straightforward, the problems are at the binder step. I am currently getting IEW2469E Reason 3: "Either the reference or the target is in amode 64 and the amodes do not match." This I was expecting; what I wasn't expecting is an apparent lack of 64 bit entry points for the JSON routines. The IBM doc https://www.ibm.com/docs/en/zos/2.5.0?topic=parser-syntax-linkage-programmin g-considerations makes no mention of 64 bit calls. I have searched, examined header files, looked at samples, but have found no clue. Am I missing something incredibly obvious or do I have to code stub routines myself to convert the parameter lists? Has anyone else encountered this? TIA Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automation of the TSO RECEIVE command
If you are using Rexx call the "queue" function to stack the response before
you issue RECEIVE. Also make sure you have called "prompt('ON')".
HTH
Robin
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Lennie Dymoke-Bradshaw
Sent: 31 August 2022 17:12
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Automation of the TSO RECEIVE command
The TSO commands TRANSMIT and RECEIVE are very useful for moving data
around, particularly as TRANSMIT produces an 80-byte LRECL which works
easily with in-stream JCL.
But has anyone worked out a reliable mechanism to automate the use of the
RECEIVE command?
It always issues queries to the user. How can the responses to these queries
be simply handled?
I feel sure someone has worked this out.
Lennie Dymoke-Bradshaw
https://rsclweb.com
Re: FTP Software for Mainframe to PC
Err, FTP, in both directions. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler Sent: 10 June 2022 19:49 To: IBM-MAIN@LISTSERV.UA.EDU Subject: FTP Software for Mainframe to PC Just looking to create a list of software that does FTP from the mainframe to the PC I know IND$FILE FILEZILLA Are there any others? Cost or no cost is okay. Lizette -- 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: SLIP IF not working
Yes, I did try PVTMOD=(MOD1) but it didn't help. Jim Mulder responded to me online and his comments crystalised for me what the problem was: we are running many test servers at different service levels in different ASIDs and I assume the wrong one was getting monitored. MODE=HOME resolved this but I would have though specifying JOBNAME would be enough to avoid the situation? Robin -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: 09 June 2022 20:57 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SLIP IF not working > SLIP SET,IF,J=SRV1,PVTMOD=(MOD1,001234),ID=SLP1,END > I did issue D SLIP=SLP1 and the SLIP was enabled/active. You could take a console dump at the time that the SLIP trap is enabled/active. It should include the address space of SRV1. Look at control regs 9,10,11. They will show PER-IF active, and the address range. Do those look correct? I would guess that MOD1 is not running in the environment you think it is (specifically, when the jobname, as in the home address space's CSCB/ASSB, is 'SRV1'), or that there is another copy of the module that grabbed the SLIP trap but is not the one that you are executing. Could this be running as the target of a space-switch PC? An earlier post probably mentioned (I don't remember), but did you try this without the offset specified just to see if anything in the module was matching the SLIP trap? Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SLIP IF not working
As several people have suggested, adding MODE=HOME does the trick. I thought it was not necessary since I had specified JOBNAME, but apparently not. John Welke sent me this illuminating private message: "I saw your question on IBM-MAIN about SLIP IF not working and as I only subscribe to the digest I thought it easier if I reply directly to you. I encountered a very similar problem many years ago and the trick was to include “MODE=HOME” on the SLIP trap. This is alluded to in the reply from Harris Morgenstern from IBM (shown below). Date:Wed, 8 Jun 2022 13:51:49 + From:Harris Morgenstern hmor...@us.ibm.com Subject: SLIP IF not working MVS System Commands discusses this: PVTMOD/PVTEP without JOBNAME/ASID and MODE=HOME: This consideration pertains to the PVTMOD and PVTEP parameters when specified in an IF or SBT PER trap for a module that was not loaded with GLOBAL=YES. PVTMOD and PVTEP are used for monitoring execution in modules that reside in private storage. Whenever possible, specify JOBNAME or ASID, and MODE=HOME, when you use PVTMOD or PVTEP in order to avoid performance impact due to PER interrupts occurring within the range of the specified private load module but in another address space. Using this parameter combination communicates the following information: - JOBNAME or ASID tells SLIP to match only when the PER interrupt occurs under the indicated job. - MODE=HOME tells SLIP to match only when the PER interrupt occurs while executing in the home (dispatched) address space. - JOBNAME or ASID in combination with MODE=HOME tells SLIP to set the PER range only when the private module is loaded into storage in the specified address space. If this parameter combination is not specified, SLIP sets the PER range the first time the private module is loaded into storage, regardless of which address space performs the load." So now we know! I am not sure the above extract is in the current version of System Commands; I couldn't find it in the description of the MODE parameter. Thanks to all. Robin -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ed Jaffe Sent: 09 June 2022 11:34 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SLIP IF not working On 6/8/2022 12:03 AM, Robin Atwood wrote: > I strongly suspect the problem is caused by the PVTMOD parameter. > Normally I just specify a RANGE but this SLIP must be sent to a customer, so > that will not work. In addition to PVTMOD=, try also specifying MODE=HOME. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SLIP IF not working
Unfortunately, this is not the case; we use a normal LOAD without the ADDR parameter. > It is not necessary for SLIP IF with PVTMOD that the module be in storage I had noticed the ENABLED/INACTIVE status and was wondering what it implied. Anyway, the module is loaded normally and is in storage, so I am none the wiser as to why the trap was never triggered. Robin -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: 08 June 2022 19:25 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SLIP IF not working SLIP PVTMOD (whether for IF or an error trap) works only for modules for which the system maintains a CDE to manage the module. That does not occur for "directed load" (LOAD with ADDR= or LOAD with ADDR64=). Perhaps the module in question is loaded by directed load. For such a case, you will need to get the address of the module and use the exact address range that you need. Whether the loader of the application (CICS?) provides you a way to do that, I have no idea. It is not necessary for SLIP IF with PVTMOD that the module be in storage at the time of the trap's setting. Such a SLIP trap will show as INACTIVE if there is not a module currently being monitored. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SLIP IF not working
With a normal LOAD EPLOC=... macro; no ADDR parameter. I calculated the absolute offset of the target instruction and substituted RANGE for PVTMOD and, of course, everything worked perfectly. There is definitely something SLIP doesn't like about our modules. One good outcome of this exercise is I have read the SLIP doco thoroughly and discovered the ACTION=RECOVERY parameter. This causes an abend 06F-080 to be issued when the trap is triggered; that causes our recovery routines to run which schedule an SVC dump. Then you can use your normal abend analysis and recover the registers at the time of the trap. Neat! Robin -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: 08 June 2022 17:28 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SLIP IF not working How did you load it? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Robin Atwood [abend...@gmail.com] Sent: Wednesday, June 8, 2022 3:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SLIP IF not working Thanks to everyone who responded. I will answer all the questions here: 1. The module was definitely loaded. We dynamically load all our modules so I checked with XDC that it was there. 2. It is not an LPA module, it's loaded into private memory. 3. I did issue D SLIP=SLP1 and the SLIP was enabled/active. 4. It is not a CICS module. The task is a file server so I kicked off a transfer from the PC. 5. A=SVCD is the default for most types of trap. I even tried A=SYNCSVCD, which overrides DAE. I strongly suspect the problem is caused by the PVTMOD parameter. Normally I just specify a RANGE but this SLIP must be sent to a customer, so that will not work. Robin -Original Message- From: IBM Mainframe Discussion List On Behalf Of allan winston Sent: 07 June 2022 23:35 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SLIP IF not working Robin, Since you said " I made a transaction that drove MOD1", this brings up the question of whether or not this is a CICS region. I ran into this problem around 20 years ago. Because CICS uses a customized loader in order to maintain multithreading, PVTMOD did not work. I forced the module into a fixed location in memory using the "CORE=LOAD" function of INTERTEST, located the starting address, added the desired offset, and then used the RANGE parameter instead of the PVTMOD parameter. Allan On Tue, Jun 7, 2022 at 9:19 AM Robin Atwood wrote: > I wanted to get a dump of my server when the instruction at 001234 in > module > MOD1 gets executed, so I entered: > > > > SLIP SET,IF,J=SRV1,PVTMOD=(MOD1,001234),ID=SLP1,END > > > > I made a transaction that drove MOD1 but no dump was taken. So, OK, > the offset maybe incorrect (there are lots of csects in MOD1) and I > adjusted the offset, but to no avail. So just to see if the trap > worked at all, I > entered: > > > > SLIP SET,IF,J=SRV1,PVTMOD=(MOD1),ID=SLP1,END > > > > but still no dump. So I must be missing something basic; I was > recently doing a lot of SLIP SA traps and didn't have this > > trouble. MOD1 is definitely in memory at the time the SLIP command is > issued. Any advice much appreciated. > > > > Thanks > > Robin > > > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SLIP IF not working
Thanks to everyone who responded. I will answer all the questions here: 1. The module was definitely loaded. We dynamically load all our modules so I checked with XDC that it was there. 2. It is not an LPA module, it's loaded into private memory. 3. I did issue D SLIP=SLP1 and the SLIP was enabled/active. 4. It is not a CICS module. The task is a file server so I kicked off a transfer from the PC. 5. A=SVCD is the default for most types of trap. I even tried A=SYNCSVCD, which overrides DAE. I strongly suspect the problem is caused by the PVTMOD parameter. Normally I just specify a RANGE but this SLIP must be sent to a customer, so that will not work. Robin -Original Message- From: IBM Mainframe Discussion List On Behalf Of allan winston Sent: 07 June 2022 23:35 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SLIP IF not working Robin, Since you said " I made a transaction that drove MOD1", this brings up the question of whether or not this is a CICS region. I ran into this problem around 20 years ago. Because CICS uses a customized loader in order to maintain multithreading, PVTMOD did not work. I forced the module into a fixed location in memory using the "CORE=LOAD" function of INTERTEST, located the starting address, added the desired offset, and then used the RANGE parameter instead of the PVTMOD parameter. Allan On Tue, Jun 7, 2022 at 9:19 AM Robin Atwood wrote: > I wanted to get a dump of my server when the instruction at 001234 in > module > MOD1 gets executed, so I entered: > > > > SLIP SET,IF,J=SRV1,PVTMOD=(MOD1,001234),ID=SLP1,END > > > > I made a transaction that drove MOD1 but no dump was taken. So, OK, > the offset maybe incorrect (there are lots of csects in MOD1) and I > adjusted the offset, but to no avail. So just to see if the trap > worked at all, I > entered: > > > > SLIP SET,IF,J=SRV1,PVTMOD=(MOD1),ID=SLP1,END > > > > but still no dump. So I must be missing something basic; I was > recently doing a lot of SLIP SA traps and didn't have this > > trouble. MOD1 is definitely in memory at the time the SLIP command is > issued. Any advice much appreciated. > > > > Thanks > > Robin > > > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SLIP IF not working
I wanted to get a dump of my server when the instruction at 001234 in module MOD1 gets executed, so I entered: SLIP SET,IF,J=SRV1,PVTMOD=(MOD1,001234),ID=SLP1,END I made a transaction that drove MOD1 but no dump was taken. So, OK, the offset maybe incorrect (there are lots of csects in MOD1) and I adjusted the offset, but to no avail. So just to see if the trap worked at all, I entered: SLIP SET,IF,J=SRV1,PVTMOD=(MOD1),ID=SLP1,END but still no dump. So I must be missing something basic; I was recently doing a lot of SLIP SA traps and didn't have this trouble. MOD1 is definitely in memory at the time the SLIP command is issued. Any advice much appreciated. Thanks Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPCS - Dump timing
IPCS STATUS. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jake Anderson Sent: 08 February 2022 11:06 To: IBM-MAIN@LISTSERV.UA.EDU Subject: IPCS - Dump timing Hello We have some dumps taken on 6th February but is it possible to know at what time the dump was captured using IPCS and can we see the timestamp anywhere in DUMP using IPCS ? Jake -- 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: Available ASIDs low and dropping
The usual trick is to recycle the ASID restarting the non-reusable ASIDs, IIRC. -Original Message- From: IBM Mainframe Discussion List On Behalf Of John Blythe Reid Sent: 10 January 2022 18:12 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Available ASIDs low and dropping Thanks Rob, Robin, It was the IEA_ASIDS healthcheck that triggered the alert. In this case it's due to recycling ADABAS regions. They do it weekly and each region terminates with this message: IEF352I ADDRESS SPACE UNAVAILABLE MXI currently shows this, so you can see that there's not long to go: Address Space Definitions Maximum Defined 500 Reserved Non-Reusable500 Reserved Start Commands5 Address Space TypeNumber Percentage Available For Use 29 2 Marked Not-Reusable 816 81 Started Tasks Active 111 11 Batch Jobs Active7 0 TSO Users Active 2 0 Initiators Active 39 3 I notice this suggestion in the IBM documentation: An address space that becomes nonreusable when it terminates (that is, message IEF352I ADDRESS SPACE UNAVAILABLE is issued when the address space terminates) should be considered for using a reusable ASIDs. Specify REUSASID=YES on the START command for the address spaces or specify ATTR=(REUSASID) on the ASCRE. Investigate and remediate any 0D3 abends that result from the use of a reusable ASID. I don't like the look of those 0D3 abends though. Any thoughts on this ? Regards, John. -- 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: Available ASIDs low and dropping
They might get: IEA061E REPLACEMENT ASID SHORTAGE HAS BEEN DETECTED This is often associated with DB2. If you can identify the job creating the ASIDs, recycling it will help alleviate the shortage. There is a lot on this subject in the list archives. HTH Robin -Original Message- From: IBM Mainframe Discussion List On Behalf Of John Blythe Reid Sent: 10 January 2022 16:44 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Available ASIDs low and dropping I have a customer with an LPAR running out of ASIDs. I estimate that they will run out in about three weeks time. This is a fairly big deal as they haven't IPL'd this LPAR for two years. Clearly an IPL is needed very soon. In fact one should have been done long before now. The question I have is what error message would be issued when a new address space could not be created due to no ASIDs being available ? If anyone can help thanks in advance. Regards, John. -- 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: PSA 0
We have already discovered this the hard way! We have a C-callable assembler routine to load modules using SVC 8. Its parameter is a C string which is copied into an 8 byte, space-filled area. The loop was terminated by a fragment: CLI 0(R5),0correct BEENDLOOP CLC 0(R5),C' ' wrong!! BEENDLOOP We had been getting away with the typo in the second compare instruction for about the last 25 years; it is actually comparing 5 bytes at address 0 with those at +X'40' and the compare had been failing because the area at +X'40' is all zeros. Come z/OS 2.5 address 0 - 4 is now all zeros, the compare succeeds, the loop terminates immediately and SVC 8 fails with abend S806! I have spent quite a bit of time preparing zaps for product versions going back some years. ☹ Robin -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jim Mulder Sent: 25 November 2021 08:15 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PSA 0 0 was the address of the restart new PSW in ESA/390. When we implemented zArchitecture 20 years ago, we set the obsolete ESA/390 interrupt new PSWs such that if someone tried to simulate an interrupt by doing a LPSW for one of them, the result would be a 0E1 wait state with a unique reason code. We figured that after 20 years of that, we had already gotten whatever value that there might have been from that, and it might now be better not to have things like 000A and 000130E1 hanging around down there where some program that has a null pointer bug might pick them up and end up trying to use them as addresses and get into even more weird results or storage overlays (since those are often valid GETMAINed addresses). So in z/OS 2.5, we changed those back to being reserved fields that are initialized to zeroes. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 11/24/2021 05:58:15 PM: > From: "Hank Oerlemans" > <03c4d8bf55f3-dmarc-requ...@listserv.ua.edu> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 11/24/2021 07:57 PM > Subject: PSA 0 > Sent by: "IBM Mainframe Discussion List" > > A random neuron thinks there was an announcement but if anyone can > shed some light I'm curious about Address 0. > > I am used to seeing X'000A' then X'000130E1' in the first 8-bytes. > This is no longer so. All zeros. A good thing ! > > SA22-7832-12 of Pops doesn't mention anything in CH. 3. > > So was there any kind of announcement for z/OS 2.5 ? -- 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: C signal() and abends not being signaled
You will also want TRAP(OFF) in your LE options otherwise LE will always
intercept any abend.
Robin
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
David Crayford
Sent: 22 October 2021 07:23
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C signal() and abends not being signaled
You're using the wrong signal. SIGABND catches abends such as x37. If you want
to catch machine checks use SIGSEGV (0C4), SIGILL (0C1) etc.
On 19/10/2021 11:03 pm, Jantje. wrote:
> Esteemed listers,
>
> I have the situation that in the vast majority of cases the C program just
> works fine, but in an infinitesimal small number of cases, it gets a S0C4
> abend. I could perhaps, through intricate testing and comparing of lots of
> things -- and burning huge amounts of CPU in doing so -- prevent the abend
> from happening, but I would rather avoid the cost of that testing and instead
> privilege the normal case.
>
> So, I thought to use the signal() function to take control in those very few
> cases where the abend occurs.
>
> However...
>
> signal or no signal, LE takes that CEEDUMP and the program stops, no matter
> what.
>
> What am I missing?
>
> I reduced my program to bare minimum to prove the point. Here is the code:
>
> #include
> #include
> #include
> #ifdef __cplusplus
>extern "C" void StrAbn(int);
> #else
>void StrAbn(int);
> #endif
> int main(int argc, char *argvݨ) {
>printf("Setting abend handler\n");
>if (signal(SIGABND, StrAbn) == SIG_ERR) {
> perror("Could not signal user signal");
> abort();
>} else {
> printf("Abend handler set\n");
>}
>printf("This must cause an abend\n");
>strcpy(0,"Coucou");
>printf("Continuing after abend\n");
>return(0);
> }
> void StrAbn(int SIG_TYPE) {
>printf("Trapped a vicious abend\n");
>signal(SIG_TYPE, SIG_IGN);
>printf("Exiting after the abend\n");
>exit(0);
> }
>
> The output says:
>
> Setting abend handler
> Abend handler set
> This must cause an abend
>
> and it does cause an abend. But control does not come to my signal handling
> routine. The "Trapped a vicious abend" never appears.
> I have been reading up on LE condition handling and on the use of the
> signal() function, and I have searched the archives of this very list. All to
> no avail.
>
> For what it is worth: I do see the following LE options:
>
> ABPERC(NONE)
> ABTERMENC(ABEND)
> DEBUG
> POSIX(OFF)
> NOTEST(ALL,"*","PROMPT","INSPPREF")
> TRAP(ON,SPIE)
>
> So, what do I need to do to actually trap that abend and get control back in
> my program when it happens?
>
> Any and all suggestions are welcome.
>
> Thanks and very best regards,
>
> Jantje.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Error running RCNVTCAT
The "outtrap" function is a TSO/E extension. You should execute the exec under
the TMP (IKJEFT01).
Robin
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Mark Jacobs
Sent: 05 October 2021 19:29
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Error running RCNVTCAT
It's my first time executing RCNVTCAT which I obtained from file 542 on the
CBTTAPE. Getting this error; IRX0043I Error running RCNVTCAT, line 1016:
Routine not found
In SYSTSPRT there are these two lines
1016 +++ xx=outtrap('junk.','*') /* I don't care */
209 +++ If (DsExist("'"cat.1"'") > 4)
Is this a stupid-user-error, or something else? It's being executed using a
modified copy of the JCL in the PDS.
//RCNVTCAT EXEC PGM=IRXJCL,COND=EVEN,
// PARM='RCNVTCAT CATALOG.Z22Z.MASTER'
//SYSEXEC DD DISP=SHR,DSN=SY010A.V501.FILE542.PDS
Mark Jacobs
Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.
GPG Public Key -
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Edit: Introduce New SUBMIT Module
So write an edit macro to copy the all the lines onto a Rexx stack and use
"SUBMIT * END(//)" (or similar) to submit it! You can then use OUTTRAP() to
capture the message from SUBMIT and stop the screen breaking up.
Robin
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
David Spiegel
Sent: 24 June 2021 17:09
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPF Edit: Introduce New SUBMIT Module
Hi Brian,
I am familiar with the Command Table. I want to set up a command to do an ISPF
Edit SUBMIT, not a TSO SUBMIT. That also means no for DSNAME.
That is, SUBMIT what is being EDITd/BROWSEd/VIEWd.
Thanks and regards,
David
On 2021-06-24 02:36, Brian Westerman wrote:
> You can call you program anything you want and create a command table entry
> for it. That way you can leave IBM's submit where it was/is is SYS1.CMDLIB.
>
>
> i.e. (look in option 3.9 of ISPF) and add
>
> YourCMD SELECT PGM(yourPGM PRM('')) NEWAPPL(anything)
>
>
> Then when the user types "yourCMD" it will invoke "yourPGM"
>
> The PRM part is to pass a parm to yopur program, (in case they type "SUBMIT
> 'somedataset(member)'".
>
> However, if you call your program SUBMIT then it will work outside of ISPF as
> well, although it will work if you called it yourPGM just as well. The
> command table just keeps them from having to type "TSO yourPGM" instead of
> just yourPGM or yourCMD.
>
>
> In any case, you don't want to replace IBM's submit, you just want to make
> sure that yours is located before IBM's in either a steplib or in a linklist
> dataset that occurs BEFORE sys1.cmdlib.
>
> I think using the name SUBMIT is a really really bad idea, unless you are
> going to create a alias for IBM's submit (maybe call it IBMSUB), so that if
> need be you can use it in case yours fails.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN .
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ASCRE termination exits: how many?
@Peter: thanks for clarifying that, obviously I had mangled something (although I am not sure how!). Anyway, I have now coded an exit that will work with either type of process so the problem is now hopefully moot. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: 23 April 2021 19:21 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ASCRE termination exits: how many? Two ASCRE's were issued. Each created address space has the termination exit you specified when you issued the ASCRE to create it. If you are finding that only one routine gets control for the termination of both of those address spaces then you specified that routine on both ASCRE invocations, whether intentionally or not. It says the termination routine is run under the creating TCB, it doesn't say what happens if another ASCRE has been issued with a different exit. Nor should it. Each ASCRE is totally unrelated to the other. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ASCRE termination exits: how many?
The exits are not in common, they don't need to be. I have a dump which shows that the right TCB is running, the parameters supplied to the exit are correct, it's just the wrong exit has been called. I have not opened a problem with IBM, I was hoping to get some feedback from IBMers here first. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: 23 April 2021 18:12 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ASCRE termination exits: how many? Is the exit loaded in common? Have you dumped the parameter lists and verified that they contain the expected value? Opened an ETR (or whatever they're calling it these days)? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Rob Scott [rsc...@rocketsoftware.com] Sent: Thursday, April 22, 2021 11:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ASCRE termination exits: how many? The address of the TRMEXIT is stored in the ASCRE parameter list prior to the PC routine that invokes the ASCRE service. If the newborn ASID-1 runs TRMEXIT-2, I would imagine that either the parmlist for ASCRE-1 is the same as the one for ASCRE-2 or the TRMEXIT-1 address is in fact TRMEXIT-2. To debug, I would consider the following : (o) : Are you using the same storage area for the MF=L form for both invocations of ASCRE? If so, what happens when you use different ones? (o) : What are the contents of the ODA after both ASCREs have been issued and what are the RC+RSN codes for both services? (o) : The creating TCB could wait on an ECB that will be POSTed by the newborn ASID-1 jobstep code when it starts and then only perform ASCRE-2 for ASID-2 afterwards. (o) : Is the storage containing TRMEXIT-1 and TRMEXIT-2 as expected and not released or re-used when ASID-2 terminates. It is unlikely that there is a problem with ASCRE. Rob Scott Rocket Software From: IBM Mainframe Discussion List On Behalf Of Robin Atwood Sent: 22 April 2021 14:15 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ASCRE termination exits: how many? EXTERNAL EMAIL I disagree. It says the termination routine is run under the creating TCB, it doesn't say what happens if another ASCRE has been issued with a different exit. I have a dump of an abend in one of the exits which has the right parameter list and TCB but the code is the wrong exit. -Original Message- From: IBM Mainframe Discussion List mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Binyamin Dissen Sent: 22 April 2021 19:40 To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: ASCRE termination exits: how many? The manual documents otherwise: "Specifies the address of the termination routine that gets control when the new address space terminates. The routine receives control in 31-bit addressing mode as an asynchronous exit in the creator's address space under the creator's TCB." I would suggest that you display your parameter lists and verify that you are requesting what you expect. And validate which TCB is running the exit. On Thu, 22 Apr 2021 18:26:38 +0700 Robin Atwood mailto:abend...@gmail.com>> wrote: :>I issue an ASCRE macro with TRMEXIT specified and a new AS is started. Then :>from another TCB I issue an ASCRE with TRMEXIT :> :>specifying a different exit routine and a second AS is started. When the :>first created AS terminates which TRMEXIT gets driven? I :> :>had assumed that the TRMEXIT would be associated with the TCB that owned the :>new AS and you could have different exit :> :>routines for different TCBs, but testing seems to show that the last :>specified TRMEXIT gets called. So is it correct to say that you :> :>can only have one TRMEXIT routine per address space? :> :> :> :>Thanks :> :>Robin :> :> :> :> :> :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the message: INFO IBM-MAIN -- Binyamin Dissen mailto:bdis...@dissensoftware.com>> http://secure-web.cisco.com/1dSxr-cMuk_Q1U8R30QvTHQkDN78jhsK_HGIS4084azCE4_p itQOn3OysRdHqvT6zrrvM5VGaLyiAYpWmNhp7UAp8xbCdPcuiC3CNZbHcJqKQSYZJyVk67MKHRQy V_knlvWjjcwuIMrAaq_j4ZfbGTG1BiLHTPIEBqo1GWfCKsnfhvIGniPrWICH_k-KRODZ6e6xhbAm bJfzZRxBtHUZUgfgWHHP0FEuDpKipwCRWYgAALAWBuBx7aw1IjbKgXH6dH_M15vD8cdHOgVSeSvZ ZcNLdvdvSnty5JlTcIXlqibTreNJuBkIOnpebBooIUEbnySA9-d87di9a5UEA1hTJeRN2qYztacU y9tI9Vn52G8hkDFnhsmKHZ89HOKJTPPNXPHIjLiku_Yc6E-XebXSqbsuBIBe7fX1mfOAleIZ2YMr 5TGbKSoJuDpptDN-aRfoh/http%3A%2F%2Fwww.dissensoftware.com<http://secure-web. cisco.com/1dSxr-cMuk_Q1U8R30QvTHQkDN78jhsK_HGIS4084azCE4_pitQOn3OysRdHqvT6zr rvM5VGaLyiAYpWmNhp7UAp8xbCdPcuiC3CNZbHcJqKQSYZJyVk67MKHRQyV_knlvWjjcwuIMrAaq _j4ZfbGTG1BiLHTPIEBqo1GWfC
Re: ASCRE termination exits: how many?
@Seymour: The two TCBs have different functions and I got a dump which shows when the AS created by TCB1 terminates, the exit from TCB2 got driven, leading to an 0C4 because the input requirements are different. @Rob: Thanks for the detailed reply, I will reply to each of your points: (o): Each ASCRE is issued from a different TCB that have their own work storage obtained. (o): The ODAs are as expected, I use the returned ECBs to coordinate with an AS initialisation module. The RC is zero. (o): See above about ECBs. I started up a transaction with TCB1 which completes after creating a new AS. I then do a transaction with TCB2 and it creates a new AS. I then do another transaction with TCB1 and when its AS terminates I get an abend 0C4 in the exit in the code running under TCB2. This gives the impression that TCB1's exit has been replaced by TCB2's. (o): The code containing the two exits is all still in memory. I too doubt there is a problem with ASCRE but was wondering if there is a system limitation that one AS can only have one ASCRE termination exit active at one time. Where does the TRMEXIT address get saved? At TCB or ASCB level? Anyway, though an interesting problem, I need this to work and the obvious solution is to code one independent exit that will work with both types of transaction. Thanks to all who replied. Robin -Original Message- From: IBM Mainframe Discussion List On Behalf Of Rob Scott Sent: 22 April 2021 22:59 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ASCRE termination exits: how many? The address of the TRMEXIT is stored in the ASCRE parameter list prior to the PC routine that invokes the ASCRE service. If the newborn ASID-1 runs TRMEXIT-2, I would imagine that either the parmlist for ASCRE-1 is the same as the one for ASCRE-2 or the TRMEXIT-1 address is in fact TRMEXIT-2. To debug, I would consider the following : (o) : Are you using the same storage area for the MF=L form for both invocations of ASCRE? If so, what happens when you use different ones? (o) : What are the contents of the ODA after both ASCREs have been issued and what are the RC+RSN codes for both services? (o) : The creating TCB could wait on an ECB that will be POSTed by the newborn ASID-1 jobstep code when it starts and then only perform ASCRE-2 for ASID-2 afterwards. (o) : Is the storage containing TRMEXIT-1 and TRMEXIT-2 as expected and not released or re-used when ASID-2 terminates. It is unlikely that there is a problem with ASCRE. Rob Scott Rocket Software From: IBM Mainframe Discussion List On Behalf Of Robin Atwood Sent: 22 April 2021 14:15 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ASCRE termination exits: how many? EXTERNAL EMAIL I disagree. It says the termination routine is run under the creating TCB, it doesn't say what happens if another ASCRE has been issued with a different exit. I have a dump of an abend in one of the exits which has the right parameter list and TCB but the code is the wrong exit. -Original Message- From: IBM Mainframe Discussion List mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Binyamin Dissen Sent: 22 April 2021 19:40 To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: ASCRE termination exits: how many? The manual documents otherwise: "Specifies the address of the termination routine that gets control when the new address space terminates. The routine receives control in 31-bit addressing mode as an asynchronous exit in the creator's address space under the creator's TCB." I would suggest that you display your parameter lists and verify that you are requesting what you expect. And validate which TCB is running the exit. On Thu, 22 Apr 2021 18:26:38 +0700 Robin Atwood mailto:abend...@gmail.com>> wrote: :>I issue an ASCRE macro with TRMEXIT specified and a new AS is started. Then :>from another TCB I issue an ASCRE with TRMEXIT :> :>specifying a different exit routine and a second AS is started. When the :>first created AS terminates which TRMEXIT gets driven? I :> :>had assumed that the TRMEXIT would be associated with the TCB that owned the :>new AS and you could have different exit :> :>routines for different TCBs, but testing seems to show that the last :>specified TRMEXIT gets called. So is it correct to say that you :> :>can only have one TRMEXIT routine per address space? :> :> :> :>Thanks :> :>Robin :> :> :> :> :> :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the message: INFO IBM-MAIN -- Binyamin Dissen mailto:bdis...@dissensoftware.com>> http://www.dissensoftware.com<http://www.dissensoftware.com> Director, Dissen Software, Bar & Grill - Israel -
Re: ASCRE termination exits: how many?
I disagree. It says the termination routine is run under the creating TCB, it doesn't say what happens if another ASCRE has been issued with a different exit. I have a dump of an abend in one of the exits which has the right parameter list and TCB but the code is the wrong exit. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Binyamin Dissen Sent: 22 April 2021 19:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ASCRE termination exits: how many? The manual documents otherwise: "Specifies the address of the termination routine that gets control when the new address space terminates. The routine receives control in 31-bit addressing mode as an asynchronous exit in the creator's address space under the creator's TCB." I would suggest that you display your parameter lists and verify that you are requesting what you expect. And validate which TCB is running the exit. On Thu, 22 Apr 2021 18:26:38 +0700 Robin Atwood wrote: :>I issue an ASCRE macro with TRMEXIT specified and a new AS is started. Then :>from another TCB I issue an ASCRE with TRMEXIT :> :>specifying a different exit routine and a second AS is started. When the :>first created AS terminates which TRMEXIT gets driven? I :> :>had assumed that the TRMEXIT would be associated with the TCB that owned the :>new AS and you could have different exit :> :>routines for different TCBs, but testing seems to show that the last :>specified TRMEXIT gets called. So is it correct to say that you :> :>can only have one TRMEXIT routine per address space? :> :> :> :>Thanks :> :>Robin :> :> :> :> :> :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- 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
ASCRE termination exits: how many?
I issue an ASCRE macro with TRMEXIT specified and a new AS is started. Then from another TCB I issue an ASCRE with TRMEXIT specifying a different exit routine and a second AS is started. When the first created AS terminates which TRMEXIT gets driven? I had assumed that the TRMEXIT would be associated with the TCB that owned the new AS and you could have different exit routines for different TCBs, but testing seems to show that the last specified TRMEXIT gets called. So is it correct to say that you can only have one TRMEXIT routine per address space? Thanks Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SAS/C++ help
SAS/C went out of support in about 2004! Good luck getting support. Robin > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gadi Ben-Avi > Sent: 21 January 2021 17:07 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SAS/C++ help > > How about asking SAS. > Start at support.sas.com or send a message to supp...@sas.com > > Gadi > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of David Crayford > Sent: Thursday, January 21, 2021 12:04 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: SAS/C++ help > > I'm working on a project that uses SAS/C++ and I'm having problems getting > the sasCC370 compiler in z/OS UNIX configured to include the Rogue Wave > STL library. In the sascc.cfg file I specified CXXLIBPREFIX=VENDOR.C750.RW > but then it failed because the LIBCXX data set was not found. I tried to > concatanate libraries using CXXLIBPREFIX=VENDOR.C750:VENDOR:C750.RW > but that didn't work. > > Is there a forum where I can ask SAS/C++ questions? > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > Email secured by Check Point > > -- > 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: Which JES2 control block contains the SDSF DSDATE/JOBCRDATE fields?
You want either the IAZSSST or IAZSSS2 dsects depending if you are going the extended status (STAT) or SAPI (SSS2) route. It's not for the faint-hearted but the dsects contain much embedded doc. HTH Robin > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Al Loeffler > Sent: 10 November 2020 05:39 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Which JES2 control block contains the SDSF DSDATE/JOBCRDATE > fields? > > The SDSF H and O panels display a creation date and time for each output > DDNAME in a job when a '?" is typed in the NP column. The SDSF User's > Guide gives the column name as DSDATE with a width of 10 and says that the > installation can change the CRDATE column to 19, so that the date and time is > included. There is also a column called JOBCRDATE that has a width of 19. > > The $PDDB contains a creation time (PDBCRTME), but no creation date > (according to the JES2 Data Areas manual). I've searched SYS1.SHASMAC and > the JES2 Data Areas manual for any date fields, but haven't found any. > > Does anyone know which JES2 control block contains this information? > > Regards, > > Al Loeffler > > -- > 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: ALERSERV delete from stimerm exit
I am guessing you need a job step TTOKEN if you delete the ALET not under the owning TCB. Robin > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Joseph Reichman > Sent: 09 October 2020 09:37 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: ALERSERV delete from stimerm exit > > Hi > > > > Would any one know if there is any restriction on deleting an ALET entry > (ALESERV DELETE) from a STIMERM exit I am getting a RC X'14' in R15 > > > > I ran the program under test and it's the same ALET I ALERSERV ADD > AL=WORKUNIT > > > > thanks > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Restrict users to Purge Jobs in TSO
You need to investigate the RACF JESSPOOL class. It's in z/OS SDSF Operation and Customization. HTH Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gilson Cesar de Oliveira Sent: 18 February 2020 19:56 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Restrict users to Purge Jobs in TSO Hello: Does anyone know how to restrict the option to purge sysouts in JES2 Spool through TSO (SDSF) but only the jobs which the user is the owner? We have profiles in OPERCMDS class like JES2.CANCEL.BAT and we would like to restrict the purge option only for sysouts generated by userA. UserB should not have the permission to purge jobs from UserA. Thanks in advance for any help. Regards, Gilson Cesar -- 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: PDSE V2 data set info
I had a look at that but SMDE is all about directory entries, no data set info. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pierre Fichaud Sent: 29 January 2020 23:55 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDSE V2 data set info How about the DESERV macro and the IGWSMDE mapping ? Regards, Pierre. -- 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: PDSE V2 data set info
I voted! LISTDSI does indded return SYSDSVERSION and SYSMAXGENS but it doesn't help in my situation (an assembler module). ISITMGD doesn't really cut it for my requirement, you have to allocate and open a data set and it only tells you if the PDSE supports generations. Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Conley Sent: 29 January 2020 13:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDSE V2 data set info On 1/28/2020 5:48 AM, Robin Atwood wrote: > I have a requirement in my queue to include the PDSE Version and the MAXGEN > limit in the DSINFO report our server sends > > to workstation clients. I checked the F1 DSCB, IGGCSI00 output fields, SMDEs > and found nothing. Searching only produced Lionel Dyck's > > PGSEGEN utility but that works in an ISPF environment and can obtain the > values from ISPF variables (ZDSDSNV, ZDSNGEN). I resorted to a brute force > search of SYS1.MACLIB and SYS1.MODGEN using "MAXG" but that only found the > DFA and some allocation support. Is > > this information actually publically available and, if so, can someone tell > me where? > Robin, Vote for RFE 107052 and 107053. Been asking IBM for YEARS to support the basics for PDSE's, still no dice. LISTDSI supposably will return the PDSE version. Don't get me started. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE V2 data set info
Thanks to everyone who replied, you have confirmed what I had suspected. The ISITMGD macro seems to do some of what I want, I will take that route. Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: 29 January 2020 10:56 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDSE V2 data set info DCOLLECT? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Robin Atwood Sent: Tuesday, January 28, 2020 4:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: PDSE V2 data set info [CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.] I have a requirement in my queue to include the PDSE Version and the MAXGEN limit in the DSINFO report our server sends to workstation clients. I checked the F1 DSCB, IGGCSI00 output fields, SMDEs and found nothing. Searching only produced Lionel Dyck's PGSEGEN utility but that works in an ISPF environment and can obtain the values from ISPF variables (ZDSDSNV, ZDSNGEN). I resorted to a brute force search of SYS1.MACLIB and SYS1.MODGEN using "MAXG" but that only found the DFA and some allocation support. Is this information actually publically available and, if so, can someone tell me where? Thanks Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
PDSE V2 data set info
I have a requirement in my queue to include the PDSE Version and the MAXGEN limit in the DSINFO report our server sends to workstation clients. I checked the F1 DSCB, IGGCSI00 output fields, SMDEs and found nothing. Searching only produced Lionel Dyck's PGSEGEN utility but that works in an ISPF environment and can obtain the values from ISPF variables (ZDSDSNV, ZDSNGEN). I resorted to a brute force search of SYS1.MACLIB and SYS1.MODGEN using "MAXG" but that only found the DFA and some allocation support. Is this information actually publically available and, if so, can someone tell me where? Thanks Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STC gets gets DAIR error 0218/0000
I finally solved this, the code had the S99NOMNT flag set in the SVC 99 request block, coded in such an obscure way that I didn't notice for a long time. S99NOMNT overrides S99MOUNT so my previous attempt at a fix failed. The perpetrator is long gone, of course. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: 10 July 2019 08:22 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: STC gets gets DAIR error 0218/ On Tue, 9 Jul 2019 at 03:18, Robin Atwood wrote: > We have a customer trying to allocate a data set on some kind of virtual > tape device and the dynamic allocation is failing with 0218/: "user > does not have volume mounting authorization". Using > the same user id he is able to allocate the same data set from a TSO > session. We suggested he give the user id of the file > server the same permissions his TSO user id had, in particular the MOUNT > profile in the TSOAUTH class. This made no > difference. AFAIK, the TSO "authorities" are indicated in the PSCBATR1 > flags in the PSCB but are only present when a TSO environment has been > created; the file server is running as a normal started task, no TSO. To > make sure I had the customer sends us a dump of the server and, indeed, > there is no PSCB. > > So what is getting checked and what might we tell the customer to enable > so the file server can mount the tape? > Robin, you asked a perhaps related question back on 8 Nov 2016, under the subject "DAIR error 0470 allocating internal reader". That involved, among other things, APAR OA50565. While that was about the JCL flag in the PSCB, the MOUNT flag is in the same place, and may be subject to much the same problem. At that time Jim Mulder said (what I interpret as) IDCAMS has a private interface to the TSO environment service that turns on the JCL bit. Back then I commented that this (OA50565) seemed to have removed some traditional options from batch jobs, which, in the absence of a TSO environment, did not restrict anything controlled by the JCL or MOUNT flags in the TSO segment. Ah - OA50565 also refers to OA45876, which *is* about MOUNT. But these are all old, so maybe something recent has further changed the behaviour here. And yes, I realize that you don't seem to have a PSCB, but still... Tony H. -- 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: STC gets gets DAIR error 0218/0000
Tony- Yes, I remember the issue with the PSCBJCL flag well, and initially thought the solution to this current problem would be similar: force the PSCBVMNT flag on as well. But the server doesn't have a PSCB in these circumstances so that idea was moot. But thanks for reminding me of OA45876, I read it again and my attention was drawn to the S99MOUNT flag in the S99RB. I didn't know that this existed but turning it on would seem to be a good idea! I will see what happens. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: 10 July 2019 08:22 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: STC gets gets DAIR error 0218/ On Tue, 9 Jul 2019 at 03:18, Robin Atwood wrote: > We have a customer trying to allocate a data set on some kind of virtual > tape device and the dynamic allocation is failing with 0218/: "user > does not have volume mounting authorization". Using > the same user id he is able to allocate the same data set from a TSO > session. We suggested he give the user id of the file > server the same permissions his TSO user id had, in particular the MOUNT > profile in the TSOAUTH class. This made no > difference. AFAIK, the TSO "authorities" are indicated in the PSCBATR1 > flags in the PSCB but are only present when a TSO environment has been > created; the file server is running as a normal started task, no TSO. To > make sure I had the customer sends us a dump of the server and, indeed, > there is no PSCB. > > So what is getting checked and what might we tell the customer to enable > so the file server can mount the tape? > Robin, you asked a perhaps related question back on 8 Nov 2016, under the subject "DAIR error 0470 allocating internal reader". That involved, among other things, APAR OA50565. While that was about the JCL flag in the PSCB, the MOUNT flag is in the same place, and may be subject to much the same problem. At that time Jim Mulder said (what I interpret as) IDCAMS has a private interface to the TSO environment service that turns on the JCL bit. Back then I commented that this (OA50565) seemed to have removed some traditional options from batch jobs, which, in the absence of a TSO environment, did not restrict anything controlled by the JCL or MOUNT flags in the TSO segment. Ah - OA50565 also refers to OA45876, which *is* about MOUNT. But these are all old, so maybe something recent has further changed the behaviour here. And yes, I realize that you don't seem to have a PSCB, but still... Tony H. -- 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: STC gets gets DAIR error 0218/0000
Joe- Apologies for the confusion, we are trying to read the data set. The customer has not been clear about the hardware involved but the job output they sent us did not have to specify a volser on the DD statement. IIRC, on our own system we used to have catalogued data sets residing on tape which could be allocated without a volser as long as the tape was mounted. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joe Monk Sent: 09 July 2019 17:44 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: STC gets gets DAIR error 0218/ Robin, I took your comments to mean your file server was having problems allocating an output file. Thats why I gave the requirements for an output file for dynamic allocation ... If its a VTL (i.e. disk pool), and the DSN is specified, there are two requirements: a. the VOLSER must be specified and b. the VOLSER must be mounted for STORAGE use. Joe On Tue, Jul 9, 2019 at 3:42 AM Robin Atwood wrote: > Joe, thanks for the prompt reply. I think your suggestions don't apply > here because the customer sent us the output of a batch job which analysed > the tape. The interesting part was the allocation messages, the DD > statement was: > > //TAPEIN DD DSN=RC.MD.SQDS.NPDC.PKLHIST.H2000,DISP=OLD > > IEF285I RC.MD.SQDS.NPDC.PKLHIST.H2000KEPT > IEF285I VOL SER NOS= R02195. > > So I think we can assume the volume info is all in the catalog. Our server > does a dynamic allocation with DSN and DISP specified, so it's basically > the same as the above JCL. > > Thanks > Robin > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Joe Monk > Sent: 09 July 2019 15:03 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: STC gets gets DAIR error 0218/ > > Some possible reasons for this error are: > >- The dynamic allocation tried to use a VIO-eligible unit, but the data >set name was not a temporary dsname (DSN=&). >- The dynamic allocation tried to put a data set with a non-temporary >dsname (DSN=dsname) onto a real DASD volume but > - No volume serial number was supplied, and > - No volumes on the system were mounted with a USE attribute of > STORAGE. > > Joe > > On Tue, Jul 9, 2019 at 2:18 AM Robin Atwood wrote: > > > We have a customer trying to allocate a data set on some kind of virtual > > tape device and the dynamic allocation is failing > > > > with 0218/: "user does not have volume mounting authorization". Using > > the same user id he is able to allocate the same > > > > data set from a TSO session. We suggested he give the user id of the file > > server the same permissions his TSO user id had, > > > > in particular the MOUNT profile in the TSOAUTH class. This made no > > difference. AFAIK, the TSO "authorities" are indicated in > > > > the PSCBATR1 flags in the PSCB but are only present when a TSO > environment > > has been created; the file server is running > > > > as a normal started task, no TSO. To make sure I had the customer sends > us > > a > > dump of the server and, indeed, there is no > > > > PSCB. > > > > > > > > So what is getting checked and what might we tell the customer to enable > so > > the file server can mount the tape? > > > > > > > > Thanks > > > > Robin > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STC gets gets DAIR error 0218/0000
Joe, thanks for the prompt reply. I think your suggestions don't apply here because the customer sent us the output of a batch job which analysed the tape. The interesting part was the allocation messages, the DD statement was: //TAPEIN DD DSN=RC.MD.SQDS.NPDC.PKLHIST.H2000,DISP=OLD IEF285I RC.MD.SQDS.NPDC.PKLHIST.H2000KEPT IEF285I VOL SER NOS= R02195. So I think we can assume the volume info is all in the catalog. Our server does a dynamic allocation with DSN and DISP specified, so it's basically the same as the above JCL. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joe Monk Sent: 09 July 2019 15:03 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: STC gets gets DAIR error 0218/ Some possible reasons for this error are: - The dynamic allocation tried to use a VIO-eligible unit, but the data set name was not a temporary dsname (DSN=&). - The dynamic allocation tried to put a data set with a non-temporary dsname (DSN=dsname) onto a real DASD volume but - No volume serial number was supplied, and - No volumes on the system were mounted with a USE attribute of STORAGE. Joe On Tue, Jul 9, 2019 at 2:18 AM Robin Atwood wrote: > We have a customer trying to allocate a data set on some kind of virtual > tape device and the dynamic allocation is failing > > with 0218/: "user does not have volume mounting authorization". Using > the same user id he is able to allocate the same > > data set from a TSO session. We suggested he give the user id of the file > server the same permissions his TSO user id had, > > in particular the MOUNT profile in the TSOAUTH class. This made no > difference. AFAIK, the TSO "authorities" are indicated in > > the PSCBATR1 flags in the PSCB but are only present when a TSO environment > has been created; the file server is running > > as a normal started task, no TSO. To make sure I had the customer sends us > a > dump of the server and, indeed, there is no > > PSCB. > > > > So what is getting checked and what might we tell the customer to enable so > the file server can mount the tape? > > > > Thanks > > Robin > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
STC gets gets DAIR error 0218/0000
We have a customer trying to allocate a data set on some kind of virtual tape device and the dynamic allocation is failing with 0218/: "user does not have volume mounting authorization". Using the same user id he is able to allocate the same data set from a TSO session. We suggested he give the user id of the file server the same permissions his TSO user id had, in particular the MOUNT profile in the TSOAUTH class. This made no difference. AFAIK, the TSO "authorities" are indicated in the PSCBATR1 flags in the PSCB but are only present when a TSO environment has been created; the file server is running as a normal started task, no TSO. To make sure I had the customer sends us a dump of the server and, indeed, there is no PSCB. So what is getting checked and what might we tell the customer to enable so the file server can mount the tape? Thanks Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TCPIP IP address for current LPAR
The name of the stack is the first parameter to EZBNMIFR! Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, Kees (ITOP NM) - KLM Sent: 29 April 2019 20:08 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TCPIP IP address for current LPAR "it will tell you pretty much everything about *the* TCP/IP stack": What if you have more than 1 TCP/IP stack in your system? Which one does the application intend to use and how does the NMI address that stack? Kees > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Robin Atwood > Sent: 29 April, 2019 14:35 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: TCPIP IP address for current LPAR > > The EZBNMIFR Network Management Interface will probably be of help here, > it will tell you pretty much everything about the TCP/IP stack. > > Robin > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Stan Weyman > Sent: 29 April 2019 19:00 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: TCPIP IP address for current LPAR > >Is there an accessible control block that holds the IP address (or > addresses) for the current LPAR I'm running on? I have need to pass back > this address to another remote application and would prefer to interrogate > a control block rather than issue commands to obtain same a la D > TCPIP,,NETSTAT,HOME (although this would be my alternative). A sample > snippet of code would be great but the location should let me get there. > >Is there any other option that getting the @ from a control block or > using D TCPIP,,NETSTAT,HOME? > >Thanks ahead of time > > Regards > Stan > > > > > -- > 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 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
Re: TCPIP IP address for current LPAR
The EZBNMIFR Network Management Interface will probably be of help here, it will tell you pretty much everything about the TCP/IP stack. Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Stan Weyman Sent: 29 April 2019 19:00 To: IBM-MAIN@LISTSERV.UA.EDU Subject: TCPIP IP address for current LPAR Is there an accessible control block that holds the IP address (or addresses) for the current LPAR I'm running on? I have need to pass back this address to another remote application and would prefer to interrogate a control block rather than issue commands to obtain same a la D TCPIP,,NETSTAT,HOME (although this would be my alternative). A sample snippet of code would be great but the location should let me get there. Is there any other option that getting the @ from a control block or using D TCPIP,,NETSTAT,HOME? Thanks ahead of time Regards Stan -- 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: ASCRE init module
I have to create an ACEE in the init module because the jobstep runs in user mode. That work fine currently. I will find a better sub-pool to use. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: 15 January 2019 00:50 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ASCRE init module I am thinking storage in a user sub-pool and saving the address in the ACEE since we create that. An ASCRE Initialization routine must not obtain storage in user-region subpools because after the initialization routine runs, the user region is (re-)initialized. Maybe you shouldn't be creating an ACEE (at least not until the jobstep program begins)? Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ASCRE init module (again)
>> Don't even think of using fields like CVTUSER and TCBUSER Agreed! I am thinking storage in a user sub-pool and saving the address in the ACEE since we create that. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of scott Ford Sent: 10 January 2019 08:39 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ASCRE init module (again) Like N/T and some storage for CBS in a subpool. .? On Wed, Jan 9, 2019 at 3:13 PM Seymour J Metz wrote: > Don't even think of using fields like CVTUSER and TCBUSER unless there is > some way to be sure that nobody else is or ever will be using them. > BTDT,GTS. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of Robin Atwood > Sent: Wednesday, January 9, 2019 6:37 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: ASCRE init module (again) > > In my init module I now want to obtain storage and set up a control block > and pass the address to the main program. Where is a good place to stash > this? I suppose I could create an N/T pair but this seems a bit cumbersome > just to pass a single address within an address space. There is the TCBUSER > field in the top-level TCB (IEAVAR00) but that's a bit scary. I create an > ACEE and that has a field ACEEAPTR which is reserved for the application, > so > that is a possibility. What do other people do? Am I missing something > blindingly obvious?! > > Thanks > Robin > > -- > 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 > -- Scott Ford IDMWORKS z/OS Development -- 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
ASCRE init module (again)
In my init module I now want to obtain storage and set up a control block and pass the address to the main program. Where is a good place to stash this? I suppose I could create an N/T pair but this seems a bit cumbersome just to pass a single address within an address space. There is the TCBUSER field in the top-level TCB (IEAVAR00) but that's a bit scary. I create an ACEE and that has a field ACEEAPTR which is reserved for the application, so that is a possibility. What do other people do? Am I missing something blindingly obvious?! Thanks Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ASCRE and ACEE inheritance
> It is certainly possible that various things are governed by the STC task > and other things are governed by the jobstep program task. OK, I understand. Well, we have a circumvention, dynamically allocate needed data sets rather than use JCL. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: 19 September 2018 18:41 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ASCRE and ACEE inheritance >In the exit I issue a RACROUTE VERIFY for a user's id and >stash the resulting ACEE in ASXBSENV. I don't think of the ASCRE INITRTN as an exit in the normal usage of the term. It runs too early to do much of anything. For example, dynamic allocation is not available until after the INITRTN returns. FWIW, normal processing is to do a free-region after the end of the INITRTN and before the start of the jobstep program task. It is certainly possible that various things are governed by the STC task and other things are governed by the jobstep program task. I think that that would be true whether the space was created by ASCRE or a simple start command. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ASCRE and ACEE inheritance
Peter, thanks for the response. My concern is that in the exit I issue a RACROUTE VERIFY for a user's id and stash the resulting ACEE in ASXBSENV. When the allocations do eventually get done the temporary data sets (at least) seem to be governed by the original STC's ACEE and the dynamically allocated data sets by the new ACEE. Why does this happen and is it possible to avoid it? Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: 18 September 2018 18:44 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ASCRE and ACEE inheritance - Is the INIT routine run under the region control task, or under the started task control task (I suspect the latter)? Why do you care under which task the routine runs? You should probably not be doing anything that cares. FWIW, it does not run under the RCT task. And it does not run under the dump task either. It certainly runs under a task that is older than the jobstep program task (which has not yet been identified since the proc has not yet been read). Why does more need to be stated? - Have any allocations asked for via DD statement in the procedure already been done? Your observation seems to indicate: yes, they have. No they have not. "Before" is "before". Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ASCRE and ACEE inheritance
The hook produced an 0C4 but that served the purpose. The TCB chain is IEEVAR00->IEAVTSDT->IEEPRWI2. The last module is, unsurprisingly, involved in STC initialisation and links to the exit. Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ASCRE and ACEE inheritance
I will have to put an XDC hook in the initialisation exit and poke around. It looks like the temporary data sets at least have been allocated. We don't get this problem with systems where TEMPDSN is not active in RACF. An RCF will perhaps clarify the situation but I don't think it will solve my problem! Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: 17 September 2018 15:56 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ASCRE and ACEE inheritance >Apologies for the delay in replying but your response got flagged as spam somewhere and I did not see it. I finally found it in the archives! My bad. The flag had been set by GMX, and I badly missed to remove it from the subject when replying. I recognized after sending, and for a quick moment thought to correct and resend, but then decided otherwise. Ag... I'm sorry. >I am not sure where the original ACEE of the child STC is coming from since both it and the parent STC have similar JCL procedure names that match to the same RACF rule. So the ACEE could be coming from the RACF rule or it could be inherited (like with forked address spaces or jobs submitted via internal reader). My problem is that there seem to be two sets of rules in play: the data sets allocated by JCL get the original STC's ACEE and the dynamically allocated ones get the new ACEE I set in the address space initialisation exit (in ASXBSENV). The doc states that the initialisation exit runs before the JCL procedure but perhaps some JCL processing happens at the same time. I'm surely not authoritative to write "this is how it works", but the statement "It executes in the new address space before the procedure identified by SYS1.PROCLIB." Is foggy. A procedure is not executed, programs are. Your problem makes clear that this part of the documentation should be enhanced: - Is the INIT routine run under the region control task, or under the stated task control task (I suspect the latter)? - Have any allocations asked for via DD statement in the procedure already been done? Your observation seems to indicate: yes, they have. Would an RCF be sufficient? -- Peter Hunkeler -- Peter Hunkeler -- 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: ASCRE and ACEE inheritance
Peter- Apologies for the delay in replying but your response got flagged as spam somewhere and I did not see it. I finally found it in the archives! I am not sure where the original ACEE of the child STC is coming from since both it and the parent STC have similar JCL procedure names that match to the same RACF rule. So the ACEE could be coming from the RACF rule or it could be inherited (like with forked address spaces or jobs submitted via internal reader). My problem is that there seem to be two sets of rules in play: the data sets allocated by JCL get the original STC's ACEE and the dynamically allocated ones get the new ACEE I set in the address space initialisation exit (in ASXBSENV). The doc states that the initialisation exit runs before the JCL procedure but perhaps some JCL processing happens at the same time. Thanks Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Are there C prototypes and/or headers available for the BPX1xxxxx USS callable services?
We call BPX1xxx routines from C and assembler all the time without problems. It is just the standard linkage. Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: 11 September 2018 01:38 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Are there C prototypes and/or headers available for the BPX1x USS callable services? Or documentation for calling BPX1 functions from C/C++? Seems to me I have seen this information somewhere but I am not finding it. Or are there more C-appropriate services that I should be using instead - instead of BPX1PCT (pfsctl) specifically? I am looking at vfs_pfsctl but it looks more difficult than BPX1PCT rather than less. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ASCRE and ACEE inheritance
Has anyone had any luck starting a new address-space with ASCRE but specifying a non-default ACEE? I tried our usual technique of inserting the desired ACEE address into TCBSENV and ASXBSENV but it was ignored. The obvious solution would be to set the ACEE in the address-space initialisation exit and that is what I did and it seemed to work. The new STC is still owned by the mother task's ACEE but data set accesses are governed by the new ACEE. The trouble began when I tried this on a system with TEMPDSN turned on in RACF. The temporary data sets seem to be owned by the original ACEE so the mainline code cannot access them. We solved this by doing dynamic allocation of the temporary data sets but there must be a better way! How can I specify the ACEE I want when I do the ASCRE? Thanks Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UserKEY CSA/Dataspace scope=common Remdiation
Jim- Thanks for the clarification. Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: 16 May 2018 22:41 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: UserKEY CSA/Dataspace scope=common Remdiation Post z/OS 2.3, only programs in system keys (0-7) will be able to store into common dataspaces (and CSA). Non-fetch protected system key SCOPE=COMMON data spaces (and non-fetch protected system key CSA) continue to be supported. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 05/16/2018 07:56:02 AM: > From: Robin Atwood <abend...@gmail.com> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 05/16/2018 11:28 AM > Subject: Re: UserKEY CSA/Dataspace scope=common Remdiation > Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > > So post z/OS 2.3 only programs in system keys (0-7) will be able to access > common dataspaces? What happens if you specify FPROT=NO on DSPSERV? > > Thanks > Robin > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Jousma, David > > Sent: 15 May, 2018 19:57 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: UserKEY CSA/Dataspace scope=common Remdiation > > > > One more time All *user-key SCOPE=COMMON dataspaces. > > > > Jim Mulder > > > > Apr 5 > > > > Re: [EXTERNAL] Re: UA94606 > > VSM ALLOWUSERKEYCSA(NO) > > > > only prevents obtaining user key CSA. > > It does not prevent creating a user key CADS, or using CHANGKEY > > to change the key of subpool 247 or 248 (DREF SQA) storage to > > user key. > > > > The health check and the new SMF 30 field report all three of those > > types of security issues, and all three will be disallowed in the next > > release after z/OS 2.3. -- 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: UserKEY CSA/Dataspace scope=common Remdiation
So post z/OS 2.3 only programs in system keys (0-7) will be able to access common dataspaces? What happens if you specify FPROT=NO on DSPSERV? Thanks Robin > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jousma, David > Sent: 15 May, 2018 19:57 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: UserKEY CSA/Dataspace scope=common Remdiation > > One more time All *user-key SCOPE=COMMON dataspaces. > > Jim Mulder > > Apr 5 > > Re: [EXTERNAL] Re: UA94606 > VSM ALLOWUSERKEYCSA(NO) > > only prevents obtaining user key CSA. > It does not prevent creating a user key CADS, or using CHANGKEY > to change the key of subpool 247 or 248 (DREF SQA) storage to > user key. > > The health check and the new SMF 30 field report all three of those > types of security issues, and all three will be disallowed in the next > release after z/OS 2.3. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Managing JESYSMSG size
For PDS members I already do that and, yes, it is very fast! However, in the current situation the customer is retrieving Endevor members and, for various reasons, they need to be saved in a short-lived catalogued data set. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen Sent: 07 March 2018 01:41 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Managing JESYSMSG size As this is your code, it may be worth it to use BPAM rather than do a separate allocation for each member. Will also save lots of CPU. On Mon, 5 Mar 2018 13:51:48 +0700 Robin Atwood <abend...@gmail.com> wrote: :>Greg- :>The SVC 99s are under my control and that is very useful to know! :> :>Thanks :>Robin :> :>-Original Message- :>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Price :>Sent: 03 March 2018 10:10 :>To: IBM-MAIN@LISTSERV.UA.EDU :>Subject: Re: Managing JESYSMSG size :> :>On 2018-03-02 9:53 PM, Robin Atwood wrote: :>> Is there anyway via :>> JES2 or SMS to suppress these messages? Preferably on a per-job basis :>> rather than globally :> :>Would MSGLEVEL=(n,0) do the trick? :> :>If the DYNALLOCs are under your control, you can request this in the relevant SVC 99 text unit. :> :>Cheers, :>Greg :> :>-- :>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 -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Managing JESYSMSG size
Yes, after a fruitless search through the text units I found the flag in the RB. I will implement a configuration option so customers can turn off the allocation messages when doing initial check-outs or other operations involving large numbers of members. Thanks for the tip! Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Price Sent: 05 March 2018 19:39 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Managing JESYSMSG size On 2018-03-05 5:50 PM, Robin Atwood wrote: > Greg- > The SVC 99s are under my control and that is very useful to know! > > Thanks > Robin Robin, Great! :) But I was slightly inaccurate. :( It is not in a text unit, it is in the RB proper - bit S99MSGL0 in byte S99FLG11. In a batch program (HSIPINQ) which allocates lots of DDs, I use the flag in both the allocation and deallocation requests to reduce spooled output size, as well as the number of pages one has to scroll down to get to the start of the SYSPRINT report. (Sometimes this is being viewed outside SDSF where N 3 works well.) The main purpose I like all those allocation and data set disposition messages in the general case is so that I can quickly see which data sets are allocated at the time of an abend, and can usually figure out which DDs are allocated to which data sets. Naturally, the data sets disposed of after the abend are the ones which were allocated at the time of the abend. Of course, sometimes customer flower boxes from their IEFACTRT routine can be helpful in this area too. Anyway, in the SYSPRINT report line which reports the data sets as they are processed I now also display the DD name just in case it's needed. IIRC, I went looking for this flag one day when trying to figure out how BPXWDYN can do allocations and deallocations without generating such messages. Given its component prefix, perhaps it was written with a view to operating in spawned address spaces which usually leave no spooled relic of their existence. Cheers, Greg -- 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: Managing JESYSMSG size
Greg- The SVC 99s are under my control and that is very useful to know! Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Price Sent: 03 March 2018 10:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Managing JESYSMSG size On 2018-03-02 9:53 PM, Robin Atwood wrote: > Is there anyway via > JES2 or SMS to suppress these messages? Preferably on a per-job basis > rather than globally Would MSGLEVEL=(n,0) do the trick? If the DYNALLOCs are under your control, you can request this in the relevant SVC 99 text unit. Cheers, Greg -- 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: Managing JESYSMSG size
Elardus- Dan has the solution, use the JESLOG parameter. I don't think management would respond well to me suggesting we replace our server with ftp! Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: 02 March 2018 18:20 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Managing JESYSMSG size Robin Atwood wrote: >We have a customer using our file server to synchronise 200,000 odd members >with a PC-based source manager. Each download requires a data set allocation >which generates IGD10xI messages in the server's JESYSMSG file, about five >lines per member. That is a PITA. I can't remember how you can suppress it in the first place, but I believe it should be possible, via SPIN or something else?. >So they are getting millions of messages filling up the spool resulting in >their ops shutting down the server. Is there anyway via JES2 or SMS to >suppress these messages? Preferably on a per-job basis rather than globally, >although since this is only a problem on the initial sync globally might be >acceptable for a short while. These are not syslog messages so the usual >techniques using MPF, NetView, etc will not work. Rather try use FTP (SFTP or FTPS if you can) with mget or mput depending where you start your transfer. No worries about gazillion messages. Of course if you let your FTP messages sitting somewhere, say in a OMVS file, just check the space that you dont run out of space. Or just do your transfers in stages, say 50 000 members. Repeat a few times with next members. 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
Managing JESYSMSG size
We have a customer using our file server to synchronise 200,000 odd members with a PC-based source manager. Each download requires a data set allocation which generates IGD10xI messages in the server's JESYSMSG file, about five lines per member. So they are getting millions of messages filling up the spool resulting in their ops shutting down the server. Is there anyway via JES2 or SMS to suppress these messages? Preferably on a per-job basis rather than globally, although since this is only a problem on the initial sync globally might be acceptable for a short while. These are not syslog messages so the usual techniques using MPF, NetView, etc will not work. Thanks Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LE strikes again
Thanks for the pointer. But I suppose I should build at ARCH(5) which is the lowest common denominator to deal with any other customers who refuse to upgrade! Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Timothy Sipples Sent: 16 July 2017 12:14 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LE strikes again Robin Atwood wrote: >I had sent the customer a version of the product compiled with XL/C at >ARCH(7) but that was not low enough! It looks like ARCH(5) is necessary. Not quite. On a z890 (or z990) machine ARCH(6) or lower is necessary. ARCH (5) or lower is necessary on z800 and z900 machines. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LE strikes again
TRAP(OFF) in the PARM parameter did the trick, the 0C1 is caused by a CLFI instruction which is obviously not supported by a z850. I had sent the customer a version of the product compiled with XL/C at ARCH(7) but that was not low enough! It looks like ARCH(5) is necessary. Thanks to everyone who helped. Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: 12 July 2017 01:32 To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: Re: LE strikes again >>SLIP SET,C=0C1,J=jobname,ML=1,END >> >>Then have them load the dump into IPCS, select option 2.2 and send you the results. > > >I don't think you can SLIP trap an 001 program check as long as LE is running with TRAP(ON,SPIE). LE's ESPIE exit will gain control before SLIP; and LE will do error handling and at the end isseue SVC 0D (ABEND) with abend code S0C1. > > >This is why the failing instruction in the symptom dump points to 0A0D, and not the original failing instruction address. It occurred to be that my statement above was not accurate. A SLIP for S0C1 will of course also match when TRAP(ON,SPIE) is in effect, but only for the ABEND LE issues at the end of its error handling. Thus you will see the SVC D instruction as the failing instruction. When run with TRAP(OFF), the SLIP will match on the original S0C1 that RTM issues (lack of any ESPIE) for the 001 program check. And this dump will show PSW and registers at time of the original 001 program check. -- Peter Hunkeler -- 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: LE strikes again
There is already a SYSUDUMP statement but the customer has suppressed most dumps. Hence the SLIP trap. -- Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: 11 July 2017 19:01 To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: Re: LE strikes again >I never knew that! I will ask the customer to update the JCL to use the PARM field. ... and ask them to add a //SYSABEND DD SYSOUT=h DD-Statemebt, where "h" is a HOLD class, so that you can have a look or get information from the dump. -- Peter Hunkeler -- 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: LE strikes again
I never knew that! I will ask the customer to update the JCL to use the PARM field. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: 11 July 2017 18:18 To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: Re: LE strikes again >SLIP SET,C=0C1,J=jobname,ML=1,END > >Then have them load the dump into IPCS, select option 2.2 and send you the results. I don't think you can SLIP trap an 001 program check as long as LE is running with TRAP(ON,SPIE). LE's ESPIE exit will gain control before SLIP; and LE will do error handling and at the end isseue SVC 0D /ABEND) with abend code S0C1. This is why the failing instruction in the symptom dump points to 0A0D, and not the original failing instruction address. -- Peter Hunkeler -- 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: LE strikes again
Yes, ignore my other post, PARM='TRAP(OFF)/' should work. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: 10 July 2017 21:54 To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: Re: LE strikes again >The CEEOPTS-DD-statement was new in z/OS 1.7 Ooops..., I forgot about this fact. Too long ago. Can you try the TRAP(OFF) via EXEC PARM? For C, I believe LE PARMs come before program options in the PARM and have to end with a slash / -- Peter Hunkeler -- 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: LE strikes again
So PARM='/TRAP(OFF)' must be used? -- Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: 11 July 2017 02:33 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LE strikes again >You can also use a JCL statement to override (if available) LE Parms. > > https://www.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.ce ea500/ceedd.htm No, he can't because he's on z/OS 1.4. I already proposed CEEOPTS DD, and Norbert Friemel remembered me it's not yet supported at that release. -- Peter Hunkeler -- Peter Hunkeler -- 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: LE strikes again
We tried that and it didn't make any difference. Using the IPCS LEDATA exit with CEEDUMP tells us there there is no LE environment, which is strange since the main module is XL/C. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: 10 July 2017 19:49 To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: LE strikes again > logs at job end, so the only way I could get any kind of dump was to ask them to set a SLIP trap. So why don't I get a dump of the original 0C1? Looking at the system trace produces: Have the customer add a DD statement for CEEOPTS and add TRAP(OFF) as sysin data to that.This will turn off LE's ESTAE and ESPIE routines, so you should get a dump of the original problem. -- Peter Hunkeler -- 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: LE strikes again
Don- Thanks for that, will do. Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Don Poitras Sent: 10 July 2017 18:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LE strikes again IPCS needs to be run with a MIGLIB from z/OS 1.4. IBM seems to be reluctant to just provide these, so if you haven't saved one, you need to have the customer run systrace and send you the output. In article <00c401d2f96e$84910120$8db30360$@gmail.com> you wrote: > A customer has installed one of our products and gets an immediate 0C1 > when it is started. The customer is running z/OS 1.4 on a z850 so when > I received the dump I confidently expected the PSW to be pointing at > an unsupported instruction; what I saw was 0A0D with R1=040C1000 in > module CEEBTERM. So it looks like LE trapped an 0C1 and then reissued > it (TRAP(OFF) in CEEOPTS make no difference). The customer suppresses > all dumps, purges all STC logs at job end, so the only way I could get > any kind of dump was to ask them to set a SLIP trap. So why don't I > get a dump of the original 0C1? Looking at the system trace produces: > > INVALID CONTROL BLOCK TOB /03 AT 0181B640 = E3D6C240/01. > Invalid control block TTCH/05 at 7F6DF000 = /00. > System Trace processing is terminated. > > so that is also suppressed. Anyone any idea how I can help these people? > > Thanks > Robin -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- 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
LE strikes again
A customer has installed one of our products and gets an immediate 0C1 when it is started. The customer is running z/OS 1.4 on a z850 so when I received the dump I confidently expected the PSW to be pointing at an unsupported instruction; what I saw was 0A0D with R1=040C1000 in module CEEBTERM. So it looks like LE trapped an 0C1 and then reissued it (TRAP(OFF) in CEEOPTS make no difference). The customer suppresses all dumps, purges all STC logs at job end, so the only way I could get any kind of dump was to ask them to set a SLIP trap. So why don't I get a dump of the original 0C1? Looking at the system trace produces: INVALID CONTROL BLOCK TOB /03 AT 0181B640 = E3D6C240/01. Invalid control block TTCH/05 at 7F6DF000 = /00. System Trace processing is terminated. so that is also suppressed. Anyone any idea how I can help these people? Thanks Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACH with RSAPF=YES
Thanks, John. I have constructed a bare-bones testbed in HLASM and called BPX1FRK and it "Just Worked". :) The cool thing is the child process is created in a BPXAS address space that is just lying around and doesn't need to be created. And, according to the doc, in the real case where the STC is multi-TCB only the TCB issuing the fork gets cloned in the new ASID, exactly what I want. -- Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: 23 May 2017 19:41 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ATTACH with RSAPF=YES On Tue, May 23, 2017 at 2:43 AM, Robin Atwood <abend...@gmail.com> wrote: > Yes, the point was taken. I am now investigating using fork() to > spin-off another address space. > From my vague monitoring of this thread, I think that is a wonderful idea. I don't know how much you're "in to" what can be done, but there are some nice(!) facilities that fork() can leverage. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxb200/bpxenv.htm You can use the C language setenv() to set a number of UNIX environment variables with can affect the results of fork() if you have the right RACF authorities set up. _BPX_JOB NAME can set the name of the fork'd address space (such as to the user's name) _B PX_USERID can set the RACF owner for the fork'd address space. The address space doing the fork() needs some "heavy" RACF authorities for this. > > Thanks > Robin > > -- Windows. A funny name for a operating system that doesn't let you see anything. 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: ATTACH with RSAPF=YES
Yes, the point was taken. I am now investigating using fork() to spin-off another address space. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: 23 May 2017 00:24 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ATTACH with RSAPF=YES As best I can tell (unless I missed it), the OP has not answered the question of whether they understand that after doing something to remove authorization from the space, they are OK with leaving the space unauthorized. If that is not the case, we might as well end the discussion because there is no way to do that while maintaining system integrity, and it is unlikely anyone would accept such a "solution". Walt Farrell has pointed out approaches that are conceivably OK. ATTACH with RSAPF=YES should be off the table. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACH with RSAPF=YES
Thanks. Potentially there will be a lot of transactions so I will look into this, although starting the TMP after a fork() seems a bit fraught! -- Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: 19 May 2017 22:43 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ATTACH with RSAPF=YES On Fri, 19 May 2017 08:37:00 -0500, Walt Farrell wrote: >On Fri, 19 May 2017 20:05:43 +0700, Robin Atwood wrote: > >>(2) is interesting. Actually my first thought was to use ASCRE to >>spawn a new ASID to execute the command but I have heard that address space >>creation/destruction is a major overhead and so focused on ATTACH. > >My first question would be whether you're processing enough requests, >frequently enough, to worry about the overhead. If you're not used that >frequently, maybe the overhead won't matter? > And, an address space created by fork()/BPXAS lingers after the process terminates (I've observed in system log for 30 minutes) so another fork() within that interval needn't start a new address space. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACH with RSAPF=YES
(2) is interesting. Actually my first thought was to use ASCRE to spawn a new ASID to execute the command but I have heard that address space creation/destruction is a major overhead and so focused on ATTACH. Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Walt Farrell Sent: 19 May 2017 19:34 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ATTACH with RSAPF=YES On Fri, 19 May 2017 14:32:27 +0700, Robin Atwood <abend...@gmail.com> wrote: >The situation would be that the client routes a command to the server >on the host which routes it to a dependent ASID. The DA gets the ACEE >of the user and executes the command via IJKEFTSR. The command is one of a >suite of Rexx execs in a library allocated to the DA which executes ISPF >services (eg, to copy some members). Without wilful collaboration of a sysprog >I am struggling to see how this could be subverted by a malicious user. >However, if you can see something >please let me know! It all comes down to the fine (and unknown to us) details of how your dependent ASID initializes, what storage key the initiator ATTACHes it in, what storage keys it uses, and how you plan to remove authorization (JSCBAUTH) before invoking IKJEFTSR. (And that you never restore authorization (JSCBAUTH) once you've removed it.) Ideally you would not run the dependent ASID authorized at all. There are at least two ways you could do that, I believe: (1) z/OS provides services via WLM that (if I remember correctly) allow an authorized server to route requests to an unauthorized servant, with z/OS managing the identity that is used for each request. (2) Using UNIX functions you could fork() a new address space to handle the request, switch the identity while still running authorized, and then execmvs() a new unauthorized program to run the request, return the results, and terminate. This does have the dependent ASID running authorized briefly, but the execmvs() takes care of cleaning things up so unauthorized code can then run safely. In any case, if you have not been running REXX execs and TSO or ISPF functions before in your dependent address spaces, you will probably have some major redesign to do in order to run them safely. And if you're going to do some major redesign you should start afresh with something that is architecturally safer, such as (1) or (2) above. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACH with RSAPF=YES
The situation would be that the client routes a command to the server on the host which routes it to a dependent ASID. The DA gets the ACEE of the user and executes the command via IJKEFTSR. The command is one of a suite of Rexx execs in a library allocated to the DA which executes ISPF services (eg, to copy some members). Without wilful collaboration of a sysprog I am struggling to see how this could be subverted by a malicious user. However, if you can see something please let me know! Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: 19 May 2017 01:47 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ATTACH with RSAPF=YES On Thu, 18 May 2017 08:09:03 -0700, Charles Mills wrote: >I hope you are getting the idea how risky this entire approach is. You >are playing "you bet your mainframe." You might get it right today And if you don't get it right, you might discover that, or you might not. It is very difficult to demonstrate that you have not created an integrity exposure. -- Tom Marchant -- 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: ATTACH with RSAPF=YES
I thought this must be the case but wanted to check. This is indeed how the product I am working on is set up: the top-level job step module is AC=1, the rest not. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: 18 May 2017 23:23 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ATTACH with RSAPF=YES On 18 May 2017 at 08:56, Robin Atwood <abend...@gmail.com> wrote: > What is the situation of a module that is loaded from an authorised > library but was linked with AC=0? Is it authorised? Can it get authorised? > Modules are not authorized. Job steps are authorized. If you are able to get your job step from an unauthorized to an authorized state using IBM supplied facilities, IBM promises to fix it so you can't. And probably pretty quickly. I don't mean to sound pedantic about this. There is indeed an important distinction between modules marked AC(1) and those not, when they live in an authorized library. Nothing prevents an AC(0) module from being loaded from such a library by an authorized job step, and given control in an authorized state. This is the normal situation. The only modules that should be marked AC(1) are those that are intended to be invoked as the initial program of a job step, which typically means EXEC PGM= in JCL, or CALL in TSO. (TSO has additional requirements to make CALL invoke a program in an authorized state.) Such modules must be prepared to deal safely with their environment, parms, and input data and not compromise system integrity, because any user can invoke them with any parms and input. Modules that are intended to run authorized, but to be invoked only by other code running authorized, may not need such general protection against malicious invokers. Tony H. -- 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: ATTACH with RSAPF=YES
What is the situation of a module that is loaded from an authorised library but was linked with AC=0? Is it authorised? Can it get authorised? Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: 16 May 2017 20:58 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ATTACH with RSAPF=YES We have a requirement to attach user modules from an unauthorised library and execute them from an STC which runs APF authorised. You need to reject that requirement. It cannot be accomplished while maintaining system integrity. Use of something like "fork" can perhaps accomplish the goal without meeting the letter of the requirement. Well, if you want to run unauthorized stuff you would first need to set your job as non-APF by resetting the bit. And if you do that, you must *never* turn the bit back on. Turning of JSCBAUTH is a fairly common approach, once the "authorized stuff" has been done. But you must then leave it off in order to maintain system integrity. In all likelihood you should NEVER use RSAPF=YES. It is provided so that the initiator can attach the jobstep program task. I have no idea why it was documented. Way back when, even internal things were documented. Maybe when internal-only things were being removed from the books, no one realized how internal this one was. The only z/OS-supported mechanism for authority-decreasing is SYNCH(X). And I do intentionally exclude authority-decreasing PC's (e.g., a PC that gets control in problem state when the invoker was supervisor state) from what is supported by z/OS. You can't be stopped from doing so, but things likely won't behave the way you need if there was a (E)SPIE present. There might be cases other than (E)SPIE that similarly would cause anomalous behavior. I have no idea if this is documented explicitly. It's just something I remember being told long long ago. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACH with RSAPF=YES
Peter- Thanks for this, I shall ponder. Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: 16 May 2017 20:58 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ATTACH with RSAPF=YES We have a requirement to attach user modules from an unauthorised library and execute them from an STC which runs APF authorised. You need to reject that requirement. It cannot be accomplished while maintaining system integrity. Use of something like "fork" can perhaps accomplish the goal without meeting the letter of the requirement. Well, if you want to run unauthorized stuff you would first need to set your job as non-APF by resetting the bit. And if you do that, you must *never* turn the bit back on. Turning of JSCBAUTH is a fairly common approach, once the "authorized stuff" has been done. But you must then leave it off in order to maintain system integrity. In all likelihood you should NEVER use RSAPF=YES. It is provided so that the initiator can attach the jobstep program task. I have no idea why it was documented. Way back when, even internal things were documented. Maybe when internal-only things were being removed from the books, no one realized how internal this one was. The only z/OS-supported mechanism for authority-decreasing is SYNCH(X). And I do intentionally exclude authority-decreasing PC's (e.g., a PC that gets control in problem state when the invoker was supervisor state) from what is supported by z/OS. You can't be stopped from doing so, but things likely won't behave the way you need if there was a (E)SPIE present. There might be cases other than (E)SPIE that similarly would cause anomalous behavior. I have no idea if this is documented explicitly. It's just something I remember being told long long ago. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACH with RSAPF=YES
We set the ASXBSENV to the ACEE of the user. The requests are run single-threaded, we will have a pool of STCs available. Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Walt Farrell Sent: 16 May 2017 22:33 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ATTACH with RSAPF=YES On Tue, 16 May 2017 20:42:42 +0700, Robin Atwood <abend...@gmail.com> wrote: >>However, as you're running work on behalf of various end-users, I hope you're >>authenticating those users and >running the work under the proper end-user >>identity in each case. And that would probably require authorization >of the >>STC. > >Yes, we run under the ACEE of the user. However, unless your STC runs single-threaded (handling requests for only 1 user at a time) it's not possible for you to run REXX execs invokiing ISPF services with proper security. It would require ensuring that none of the execs, or the services they invoke, perform any ATTACH requests., The new subtask created by ATTACH would not inherit the ACEE of the user on whose behalf you're running the request. (There is one exception to that, but it's used rarely enough that it probably won't apply to you. You would have to be using WLM services, and operating as a WLM servant to manage the requests that you're processing. Then, and only then as far as I know, would the user's ACEE propagate down to a new subtask.) -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACH with RSAPF=YES
>However, as you're running work on behalf of various end-users, I hope you're >authenticating those users and >running the work under the proper end-user >identity in each case. And that would probably require authorization >of the >STC. Yes, we run under the ACEE of the user. Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTACH with RSAPF=YES
Thanks to everyone for replying, I would never realised you had to flip JSCBAUTH from the macro documentation. The actual business requirement is that we run Rexx execs that call ISPF services on behalf of workstation users running an IDE. The STC doing this must run authorised because it communicates with a comms task via cross-memory services. So we will have control over what gets executed. This is still very much an experiment, I am not sure it will actually work. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen Sent: 15 May 2017 20:56 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ATTACH with RSAPF=YES Well, if you want to run unauthorized stuff you would first need to set your job as non-APF by resetting the bit. Of course, your authorized key8 storage will be subject to change by the unauthorized task, thus your authorized code must not use Key8 storage. (1) and (2) are not exclusive, as your authorized task would need to remain in supervisor state after resetting APF (assuming you still need APF services). If you no longer need APF services, simply reset APF do MODESET PROB and the garden variety ATTACH(X) Why do you want to run unauthorized code from this STC? What is the business case? On Mon, 15 May 2017 15:18:38 +0700 Robin Atwood <abend...@gmail.com> wrote: :>We have a requirement to attach user modules from an unauthorised library :>and execute them from an STC which :> :>runs APF authorised. Calling ATTACH with RSAPF=YES seems to do exactly what :>I want but every time I try it :> :>I get abend S306-0C, "authorised program attaching module from an :>unauthorized library". The ATTACH macro :> :>description states: :> :> :> :>RSAPF=YES when these conditions are met: :> :>. The caller is running in supervisor state, system key (0-7), :>or both :> :>. The caller is running non-APF authorized :> :>. The subtask is attached in the problem program state and with :>a nonsystem key. :> :> :> :>Conditions 1 and 2 seem mutually exclusive. I tried coding MODESET MODE=SUP :>and adding SM=PROB,KEY=PROP :> :>to the ATTACH but it made no difference. I seem to be missing something :>fairly massive here! Can anyone shed :> :>some light on this? :> :> :> :>Thanks :> :>Robin :> :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ATTACH with RSAPF=YES
We have a requirement to attach user modules from an unauthorised library and execute them from an STC which runs APF authorised. Calling ATTACH with RSAPF=YES seems to do exactly what I want but every time I try it I get abend S306-0C, "authorised program attaching module from an unauthorized library". The ATTACH macro description states: RSAPF=YES when these conditions are met: . The caller is running in supervisor state, system key (0-7), or both . The caller is running non-APF authorized . The subtask is attached in the problem program state and with a nonsystem key. Conditions 1 and 2 seem mutually exclusive. I tried coding MODESET MODE=SUP and adding SM=PROB,KEY=PROP to the ATTACH but it made no difference. I seem to be missing something fairly massive here! Can anyone shed some light on this? Thanks Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fujitsu Mainframe Vs IBM mainframe
Back when I too worked on Amdahls in the 80s, the SEs told me the Fujitsus had 31 bit I/O architecture! Don't know the truth of that, though. Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Cairns Sent: 23 February 2017 17:08 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Fujitsu Mainframe Vs IBM mainframe The first ten years of my mainframe career I never saw a true IBM installation. First I worked with a Fujistu and MSP, then I moved to a shop that had Amdahl kit, and after that a shop that was Hitachi. At least for the Amdahl and Hitachi the OS was really MVS, OS/390 etc. The Fujitsu environment worked almost exactly the same as the MVS system from the perspective of an applications programmer. The sysprogs probably knew more about the differences than I did at the time. We ran Adabas/Natural, lots of PL/1, SAS, and probably many more besides that I didn't know about (this was my first shop, I was quite young and completely inexperienced of course). Interesting things I remember about the Fujitsu OS: MVS was called MSP - Multiple Systems Product if I recall correctly. But apparently you could see the IBM copyright in the load modules in some places... TSO was called TSS - Time Sharing System RACF was still called RACF - and worked exactly the same Though JCL was the same, we had something called JOL - Job Oriented Language. This was a set of ISPF panels that walked you through creation of each jobstep and built (awful) dynamically allocated JCL. ISPF was called SPF - Systems Productivity Facility We had something called GEM - I forget the acronym, this was a source/version control system if I recall correctly. Used to have to use the TSO SUBMIT and OUTPUT commands a lot - but I guess this was no different from MVSes of the same era (early 80's). We didn't have SDSF. Mike -- 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: IEC141I 013-A8: how to read VS data sets?
Elardus- The macro used is very similar to the one you have posted below. I have finally worked out how the code that "works" avoids the abend: it opens the data set as RECFM=F and reads the max LRECL. Needless to say, the output received is not useful. I am changing the code to check for RECFM=VS and send an "unsupported format" error message. Thanks to all who contributed to this thread. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: 06 January 2017 16:38 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEC141I 013-A8: how to read VS data sets? Robin Atwood wrote: >But my curiosity was piqued when I found that another of our products *could* >read the data set; I just cannot work out how! If you can find out, could you post your macro used for that VS dataset? I'm just curious if you don't mind, please. Something like this example I'm using for reading VBS (not VS) datasets (SMF in this case): INVOERDCB DSORG=PS,MACRF=(GM),DDNAME=INVOER,EODAD=EINDE (I admit that above macro is not perfect or optimal or ideal, but it is *working* and fast+furious for both tape/disk) Robin (and others too!), thanks for your posts in this thread. It was very educational to me. Thanks again! 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: IEC141I 013-A8: how to read VS data sets?
This is a vendor product and I am the developer. I got a bug report from some customer who tried to download a VS data set from the spool and the server got the abend. I have reproduced this by using IEBCOPY to unload a PDS and pointing SYSUT2 at SYSOUT. If I use the SDSF JOB DATA SET display and scroll to the right, I can see the data set is RECFM=VS, LRECL=23212. Since the message manual quite clearly states you cannot read a VS data set from SYSOUT using QSAM, I should close the bug as a permanent restriction. But my curiosity was piqued when I found that another of our products *could* read the data set; I just cannot work out how! Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: 06 January 2017 01:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEC141I 013-A8: how to read VS data sets? Like Walt, I'm skeptical of the assertion that a spool data set is VS, where 'S' means 'spanned'. Spanned records are extremely rare in MVS. The only use for them I've ever come across is MANx SMF, which I believe predates dirt. Most standard utilities fail when opened to V(B)S records. Only IFASMFDP can read SMF data, and the output from that is ordinary VB. SAPI should be able to handle any spool data set. OTOH I've never coded anything for SAPI; we use VPS (Levi, Ray, Shoup) to extract spool data and ship it to network printers. Likewise, SDSF or equivalent ISV product can handle spool data sets whether created as V or F. SDSF now has a Rexx interface that makes it very usable for processing spool files. FWIW it was once possible to utilize JES2 interfaces to read spool data sets directly. That ability evaporated a long, long time ago. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEC141I 013-A8: how to read VS data sets?
The JCL is not relevant, both applications are servers that use dynamic allocation. They are using SAPI to read the JES spool. The message is IEC141I 013-A8,IGG0199G,TAURISP3,TAURISP3,SYS2 The spool data set is allocated to SYS2. I am really interested in advice about reading VS data sets, what access method to use, etc. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: 05 January 2017 19:47 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IEC141I 013-A8: how to read VS data sets? Robin, Please delete any part of the email you did a REPLY to that does not pertain to your question. It tends to confuse the issue. Next, I am not clear on Reading a VS on JES2 Spool. JES2 Spool has its own unique process for creating SYSOUT. So if you could explain further that could help. If you are asking about a job that abended when trying to Read a VS dataset and got an S013-A8, then that is a different question. When I look up your abend code An incorrect record format was requested for a SYSIN, SYSOUT, or subsystem data set with BSAM or QSAM or for a z/OS UNIX directory with BPAM. One of the following conditions was detected: RECFM=D was specified. Variable spanned records (VS or VBS) were requested for input. Both ANSI and machine control characters were specified. Please show the JCL from the job that runs good and the job that fails. You can change the dataset name and I think we only need the JCL to see the way it is coded. Again, you would read SYSOUT On JES2 not a VS dataset on JES2. Unless your application is trying to run a JES2 SSI function to read SYSOUT. Please provide further details. And if you could post the complete IEC141 I message, that would also be helpful. Again just change the dataset name. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Robin Atwood > Sent: Thursday, January 05, 2017 5:31 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: IEC141I 013-A8: how to read VS data sets? > > One of our apps abends if trying to read a VS data set on the JES2 > spool. The message manual tells me this is because it is not allowed > to read VS SYSOUT using QSAM. Yet we have another application which does > exactly that. > Furthermore, after one day of staring at the code I cannot see any > functional difference between the two routines: > both use identical DCB/DCBEs. SDSF can read the data set of course, > but I expect it has some internal interface. So I searched on what is > the correct way to read VS data sets and found virtually nothing. > Anybody got any experience of this? > > Thanks > Robin > -- 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
IEC141I 013-A8: how to read VS data sets?
One of our apps abends if trying to read a VS data set on the JES2 spool. The message manual tells me this is because it is not allowed to read VS SYSOUT using QSAM. Yet we have another application which does exactly that. Furthermore, after one day of staring at the code I cannot see any functional difference between the two routines: both use identical DCB/DCBEs. SDSF can read the data set of course, but I expect it has some internal interface. So I searched on what is the correct way to read VS data sets and found virtually nothing. Anybody got any experience of this? Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: 05 January 2017 17:59 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Delete NVR entries where ENQ shows from LLA/XCFAS Lucas Rosalen wrote: >You could do the right way, which means removing these datasets from LLA and >LNKLST. Agreed! >Or you could recklessly use BYPASSNQ program, which can be found in CBT >file #749 Hehehe, 'recklessly'? That AC(1) program is a frontend to screen SVCs and then misuse "SYSNOENQ" before calling deletion programs like IEHPROGM or IDCAMS. My storage admins will not like that program at all. So, I can't try that out to see if a certain special RACF profile will block this program or not. 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: How to Identify modules as C/C++ or Cobol, or ASM from dump (SYSMDUMP)
Peter- Try in IPCS VERBX LEDATA 'TCB(00xx) CEEDUMP' where the TCB is the one that abended and you should get the LE trace-back, similar to what you would get in SYSOUT CEEDUMP. HTH Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: 29 November 2016 17:00 To: IBM-MAIN@LISTSERV.UA.EDU Subject: How to Identify modules as C/C++ or Cobol, or ASM from dump (SYSMDUMP) I've got a dump (SYSMDUMP) from a Cobol program that has called some 500+ other modules (don't ask) when it finally abends with an S0CA. The modules are Cobol, C/C++ and Assembler modules. The S0CA is caused by the fact that C/C++ sets the "decimal overflow mask" in the PSW, but does not reset it to the previous state. Cobol expects decmial overflows not to cause an exception (000A). My problem is to find which of the 500+ are C/C++ modules. So far I could not find a way to determine this from the dump. LE remembers which runtime environments (Cobol, C/C++) are active because some such code has been active in the enclacve. So I'm hoping that LE keeps some kind of list of modules loaded by "type", i.e. the various languages it supports. I'm thinking of something like the LLE (load list entries) but by language type. Does anyone happen to know anything that might help me? -- Peter Hunkeler -- Peter Hunkeler -- 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: DAIR error 0470 allocating internal reader
Jim-
Thanks, so we need to apply the PTF. I will changes my code to check for
PSCBJCL and only force it on if necessary.
Cheers
Robin
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: 09 November 2016 10:05
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DAIR error 0470 allocating internal reader
The OA50565 fix changed the TSO/E environment service to turn on PSCBJCL
when running in an APF authorized jobstep (i.e. when JCSBAUTH is on).
IDCAMS is linked in SYS1.LINKLIB with AC(1), so an EXEC PGM=IDCAMS jobstep
is APF authorized.
Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
> A venerable STC started getting 0470 ("user unauthorized for
> subsystem") when trying to allocate an INTRDR after we added a lot of
> new function in a separate subtask. Disabling the new subtask allowed
> the allocation to work as before.
> Searching I found OA50565 which describes the same thing happening to
> IDCAMS. The problem was the new subtask was calling IKJTSOEV and that
> causes the PSCBJCL flag to be turned off so the task cannot submit
> jobs. The apar states that IDCAMS now establishes a TSF with the
> PSCBJCL on without saying how. I tried forcing the PSCBJCL flag on
> after the call to IKJTSOEV but that resulted in an LE exception when I
> tried the allocation in the other task. Toggling the flag in the task
> that does the allocation seems to work OK so far: I set the flag on,
> allocate the INTRDR, turn it off and nobody seems to notice.
>
> I am not too happy with this arrangement! Does someone know how to
> establish the TSF with the PSCBJCL flag on as in IDCAMS, or equally
> good, how to cancel the TSF once it is established. I could find no
> function call that does that.
--
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: DAIR error 0470 allocating internal reader
Thanks for the suggestion but the point of the exercise was to reduce the
number of ASIDs that must be managed!
Otherwise a very sensible idea.
Robin
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steve Smith
Sent: 08 November 2016 19:13
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DAIR error 0470 allocating internal reader
I don't know the answer to your question, but I appreciate the problem. It
sounds like you might be headed into a Catch-22 rabbit-hole (to mix some
metaphors). Have you considered putting some function in an auxiliary address
space? I think it's the ASCRE macro that lets you do this easily, at the cost
of having to do some AR-mode (or other means) to share information.
sas
On Tue, Nov 8, 2016 at 5:56 AM, Robin Atwood <abend...@gmail.com> wrote:
> A venerable STC started getting 0470 ("user unauthorized for
> subsystem") when trying to allocate an INTRDR after we added a lot of
> new function in a separate subtask. Disabling the new subtask allowed
> the allocation to work as before.
> Searching I found OA50565 which describes the same thing happening to
> IDCAMS. The problem was the new subtask was calling IKJTSOEV and that
> causes the PSCBJCL flag to be turned off so the task cannot submit
> jobs. The apar states that IDCAMS now establishes a TSF with the
> PSCBJCL on without saying how. I tried forcing the PSCBJCL flag on
> after the call to IKJTSOEV but that resulted in an LE exception when I
> tried the allocation in the other task. Toggling the flag in the task
> that does the allocation seems to work OK so far: I set the flag on,
> allocate the INTRDR, turn it off and nobody seems to notice.
>
> I am not too happy with this arrangement! Does someone know how to
> establish the TSF with the PSCBJCL flag on as in IDCAMS, or equally
> good, how to cancel the TSF once it is established. I could find no
> function call that does that.
>
> Thanks
> Robin
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
sas
--
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
DAIR error 0470 allocating internal reader
A venerable STC started getting 0470 ("user unauthorized for subsystem") when
trying to allocate an INTRDR after we
added a lot of new function in a separate subtask. Disabling the new subtask
allowed the allocation to work as before.
Searching I found OA50565 which describes the same thing happening to IDCAMS.
The problem was the new
subtask was calling IKJTSOEV and that causes the PSCBJCL flag to be turned off
so the task cannot submit jobs. The apar
states that IDCAMS now establishes a TSF with the PSCBJCL on without saying
how. I tried forcing the PSCBJCL flag on after
the call to IKJTSOEV but that resulted in an LE exception when I tried the
allocation in the other task. Toggling the flag in the
task that does the allocation seems to work OK so far: I set the flag on,
allocate the INTRDR, turn it off and nobody seems to
notice.
I am not too happy with this arrangement! Does someone know how to establish
the TSF with the PSCBJCL flag on as in IDCAMS, or equally good, how to cancel
the TSF once it is established. I could find no function call that does that.
Thanks
Robin
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
