Re: Mysterious U4088-63 from RPTSTG(ON)
In 0a0e01d0994a$e99c0410$bcd40c30$@mcn.org, on 05/28/2015 at 06:33 AM, Charles Mills charl...@mcn.org said: Well, I moved ISAUTH() unchanged to its own assembler module. No change in the error. I removed the IEABRCX DEFINE and bingo! It works. My guess is that it doesn't recognize the eye catcher unless there's a B in front of it. Personally, I consider IEABRCX DEFINE to be a ticking time bomb and would only use it under duress. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mysterious U4088-63 from RPTSTG(ON)
Lizette, You are absolutely correct. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, May 28, 2015 7:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mysterious U4088-63 from RPTSTG(ON) SDSF I believe is ISF Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Thursday, May 28, 2015 4:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mysterious U4088-63 from RPTSTG(ON) Charles (and others) Has LE obsconded with SDSF's *RESERVED* use of ISA prefix? Ed On May 28, 2015, at 4:58 PM, Charles Mills wrote: Well that would make sense ... In my case the program does not ABEND if some function -- also relative branch -- is called first rather than ISAUTH, which makes no sense at all. I have not tried every possibility, for example - what if I called some other function rather than ISAUTH at the early point in the C++ logic where I call (or comment out the call to) ISAUTH? - what if I called ISAUTH later in the program, after other functions had been called successfully? Seems to me if I were writing a how much heap actually got used tool I would just initialize the whole heap to X'DEADBEEF' or X'8BADF00D' or something and then at EOJ search from the top for the end of the initial value. But what do I know. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Andy Wood Sent: Thursday, May 28, 2015 2:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mysterious U4088-63 from RPTSTG(ON) On Thu, 28 May 2015 07:56:03 -0700, Charles Mills charl...@mcn.org wrote: . . . I would assume C++ gets the stack at startup, not on the first external call. Interesting thought. I have this very vague recollection, that when RPTSTG is ON, things are set up so that the stack is always too small (or gives that appearance), so that routine gets called every time. However, it has been a very long time since I was near anything like that, things may have changed, and perhaps I had the story wrong in the first place. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mysterious U4088-63 from RPTSTG(ON)
Well that would make sense ... In my case the program does not ABEND if some function -- also relative branch -- is called first rather than ISAUTH, which makes no sense at all. I have not tried every possibility, for example - what if I called some other function rather than ISAUTH at the early point in the C++ logic where I call (or comment out the call to) ISAUTH? - what if I called ISAUTH later in the program, after other functions had been called successfully? Seems to me if I were writing a how much heap actually got used tool I would just initialize the whole heap to X'DEADBEEF' or X'8BADF00D' or something and then at EOJ search from the top for the end of the initial value. But what do I know. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Andy Wood Sent: Thursday, May 28, 2015 2:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mysterious U4088-63 from RPTSTG(ON) On Thu, 28 May 2015 07:56:03 -0700, Charles Mills charl...@mcn.org wrote: . . . I would assume C++ gets the stack at startup, not on the first external call. Interesting thought. I have this very vague recollection, that when RPTSTG is ON, things are set up so that the stack is always too small (or gives that appearance), so that routine gets called every time. However, it has been a very long time since I was near anything like that, things may have changed, and perhaps I had the story wrong in the first place. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mysterious U4088-63 from RPTSTG(ON)
On Thu, 28 May 2015 07:56:03 -0700, Charles Mills charl...@mcn.org wrote: . . . I would assume C++ gets the stack at startup, not on the first external call. Interesting thought. I have this very vague recollection, that when RPTSTG is ON, things are set up so that the stack is always too small (or gives that appearance), so that routine gets called every time. However, it has been a very long time since I was near anything like that, things may have changed, and perhaps I had the story wrong in the first place. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mysterious U4088-63 from RPTSTG(ON)
Charles (and others) Has LE obsconded with SDSF's *RESERVED* use of ISA prefix? Ed On May 28, 2015, at 4:58 PM, Charles Mills wrote: Well that would make sense ... In my case the program does not ABEND if some function -- also relative branch -- is called first rather than ISAUTH, which makes no sense at all. I have not tried every possibility, for example - what if I called some other function rather than ISAUTH at the early point in the C++ logic where I call (or comment out the call to) ISAUTH? - what if I called ISAUTH later in the program, after other functions had been called successfully? Seems to me if I were writing a how much heap actually got used tool I would just initialize the whole heap to X'DEADBEEF' or X'8BADF00D' or something and then at EOJ search from the top for the end of the initial value. But what do I know. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Andy Wood Sent: Thursday, May 28, 2015 2:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mysterious U4088-63 from RPTSTG(ON) On Thu, 28 May 2015 07:56:03 -0700, Charles Mills charl...@mcn.org wrote: . . . I would assume C++ gets the stack at startup, not on the first external call. Interesting thought. I have this very vague recollection, that when RPTSTG is ON, things are set up so that the stack is always too small (or gives that appearance), so that routine gets called every time. However, it has been a very long time since I was near anything like that, things may have changed, and perhaps I had the story wrong in the first place. -- 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: Mysterious U4088-63 from RPTSTG(ON)
Entry point names are fair game, right? Only program module names have reserved prefixes -- at least that is what SMPE (which I was just reading) seems to imply. In any event, ISAUTH works in every circumstance I have tried except (IEABRCX RPTSTG(ON)). But who knows. I certainly do not have all the answers. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Thursday, May 28, 2015 4:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mysterious U4088-63 from RPTSTG(ON) Charles (and others) Has LE obsconded with SDSF's *RESERVED* use of ISA prefix? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mysterious U4088-63 from RPTSTG(ON)
SDSF I believe is ISF Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Thursday, May 28, 2015 4:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mysterious U4088-63 from RPTSTG(ON) Charles (and others) Has LE obsconded with SDSF's *RESERVED* use of ISA prefix? Ed On May 28, 2015, at 4:58 PM, Charles Mills wrote: Well that would make sense ... In my case the program does not ABEND if some function -- also relative branch -- is called first rather than ISAUTH, which makes no sense at all. I have not tried every possibility, for example - what if I called some other function rather than ISAUTH at the early point in the C++ logic where I call (or comment out the call to) ISAUTH? - what if I called ISAUTH later in the program, after other functions had been called successfully? Seems to me if I were writing a how much heap actually got used tool I would just initialize the whole heap to X'DEADBEEF' or X'8BADF00D' or something and then at EOJ search from the top for the end of the initial value. But what do I know. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Andy Wood Sent: Thursday, May 28, 2015 2:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mysterious U4088-63 from RPTSTG(ON) On Thu, 28 May 2015 07:56:03 -0700, Charles Mills charl...@mcn.org wrote: . . . I would assume C++ gets the stack at startup, not on the first external call. Interesting thought. I have this very vague recollection, that when RPTSTG is ON, things are set up so that the stack is always too small (or gives that appearance), so that routine gets called every time. However, it has been a very long time since I was near anything like that, things may have changed, and perhaps I had the story wrong in the first place. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mysterious U4088-63 from RPTSTG(ON)
My only guess is: the branch in the Prolog to obtain New storage in the case when the current segment is too small must point to a special routine in the rptstg(on) case. And maybe this routine has a Problem if the branch is a BRC and no BC. But I cannot really imagine what sort of problem -Original Message- Date: Thu, 28 May 2015 15:33:41 +0200 Subject: Re: Mysterious U4088-63 from RPTSTG(ON) From: Charles Mills charl...@mcn.org To: IBM-MAIN@LISTSERV.UA.EDU Well, I moved ISAUTH() unchanged to its own assembler module. No change in the error. I removed the IEABRCX DEFINE and bingo! It works. BTW, the RPTSTG(ON) output shows nothing unusual. I can post it if anyone thinks they would see something there. FWIW, here is the complete assembled code of the new ISAUTH. The addresses are of course different. CDSALEN is also a lot smaller because ISAUTH basically needs none of the work area used by some of the other functions. ***That's not the key difference -- the smaller CDSALEN still fails if IEABRCX DEFINE.*** Other than that, the only difference I can see relative to the old code is the base/displacement branches rather than branch relatives. (The EXTRN CEESTART is generated once per assembly by EDCPRLG. It's earlier in the listing in the big module.) I am *totally* mystified. Even if you posit a (HIGHLY unlikely!) bug in TESTAUTH or LE, I don't see how substituting two BRC's for BC's could expose it. 23 ISAUTH EDCPRLG DSALEN=CDSALEN,BASEREG 24+*** 0 0009825+IHB0002DS DSECT 26+ DSD 27+ DSCL(120+0) 00080 028+ ORG IHB0002DS 29+ DSCL(CDSALEN+8) 00098 0009830+ ORG 31+ DS0D 00090 32+IHB0002LG EQU *-IHB0002DS-8 0001C 000C033+CZAISAUT CSECT 34+*-- 35+ DS0H R:F 0001C 36+ USING *,15 47F0 F0400005C37+ISAUTH B IHB0002B branch ar 38+* PPA1 constant area 1439+ DCAL1(IHB0002N+4-*) offs CE40+ DCX'CE' . CEE A041+ DCX'A0' . CEE 1042+ DCAL1(0+0+16) . memb 0038 43+ DCAL4(IHB0002P) . A( 44+ DCAL4(0) . A( 0090 45+ DCAL4(IHB0002LG)to 0006 46+IHB0002N DCAL2(6) . leng C9E2C1E4E3C8 47+ DCC'ISAUTH' untr 48+*-- 49+ EXTRN CEESTART 50+*-- 51+* PPA2 constant area 52+IHB0002P DS0F forc 0353+ DCX'03' . memb 0054+ DCX'00' . memb 3355+ DCX'33' . plis 0056+ DCX'00' . CEE 57+ DCAL4(CEESTART) 58+ DCAL4(0)A( 0048 59+ DCAL4(IHB0002T) . A( 60+* 61+* Time stamp area 62+IHB0002T DS0F F2F0F1F5 63+ DCCL4'2015' . F0F5F2F8 64+ DCCL4'0528' . mmdd F0F9F1F5F0F0 65+ DCCL6'091500' . hhmm F0F1 66+ DCCL2'01' . vers F0F1F0F0 67+ DCCL4'0100' . rele 68+* 69+IHB0002B DS0H 70
Re: Mysterious U4088-63 from RPTSTG(ON)
Is it time to fire up a PMR?
On 28/05/2015 9:55 PM, Charles Mills wrote:
FWIW, I can duplicate the problem with a call from a trivial C++ program.
Whether or not the program actually is authorized does not seem to make a
difference. Here's the entire program:
#ifdef __MVS__
// Same pragmas!
#pragma runopts(
STACK(64K,16K),ANYHEAP(192K,8K),HEAP(1024K),PLIST(HOST),POSIX(ON),TRAP(ON,NO
SPIE),NOEXECOPS )
#endif
#include stdio.h
#include stdlib.h
extern OS {bool ISAUTH();}
int main(int argc, char* argv[])
{
printf(ISAUTH() test sandbox entered\n);
printf(Headed off to ISAUTH()\n);
bool isauth = ISAUTH();
printf(Back from ISAUTH(), isauth=%d\n, isauth);// make sure call
does not get optimized out
printf(Adios muchachos!\n);
return 0;
}
Output is
ISAUTH() test sandbox entered
Headed off to ISAUTH()
CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4088 TO DATA SET: ...
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Thursday, May 28, 2015 6:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mysterious U4088-63 from RPTSTG(ON)
Well, I moved ISAUTH() unchanged to its own assembler module. No change in
the error. I removed the IEABRCX DEFINE and bingo! It works.
BTW, the RPTSTG(ON) output shows nothing unusual. I can post it if anyone
thinks they would see something there.
FWIW, here is the complete assembled code of the new ISAUTH. The addresses
are of course different. CDSALEN is also a lot smaller because ISAUTH
basically needs none of the work area used by some of the other functions.
***That's not the key difference -- the smaller CDSALEN still fails if
IEABRCX DEFINE.*** Other than that, the only difference I can see relative
to the old code is the base/displacement branches rather than branch
relatives. (The EXTRN CEESTART is generated once per assembly by EDCPRLG.
It's earlier in the listing in the big module.)
I am *totally* mystified. Even if you posit a (HIGHLY unlikely!) bug in
TESTAUTH or LE, I don't see how substituting two BRC's for BC's could expose
it.
--
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: Mysterious U4088-63 from RPTSTG(ON)
bran 58F0 C0740007478+ L 15,116(,12) load 05EF 79+ BALR 14,15 invo 80+* at this point R0 has the new NAB, R2 58F0 D0480004881+ L 15,72(,13) 90F0 20480004882+ STM 15,0,72(2) 9210 2000 0 83+ MVI 0(2),X'10' 50D0 2004484+ ST13,4(,2)back 18D2 85+ LR13,2acti 86+*** 87+ DROP 15 88+*** C0C0 FFBB 089 LARL R12,CZAISAUT R:C 0 90 USING CZAISAUT,R12 91 * 92 * Issue the TESTAUTH 93 TESTAUTH FCTN=1 4110 0001194+ LA1,1(0,0) SPECIFY F 4100 0FFF00FFF95+ LA0,X'FFF' NO AUTH C 8900 00140001496+ SLL 0,20 REG 0 N 0A77 97+ SVC 119 98 * 99 * TESTAUTH returns 0 = yes, 4 = no 100 * We return 1 = yes, 0 = no 88F0 00022 101 SRL R15,2 Conv 13FF 102 LCR R15,R15 Conv A7FA 00011 103 AHI R15,1 Conv 104 * 105 EDCEPIL , 58D0 D0044 106+ L 13,4(,13) addre 58E0 D00CC 107+ L 14,12(,13) resto 982C D01C0001C 108+ LM2,12,28(13)resto 051E 109+ BALR 1,14 retur 001C 110+ DCAL4(ISAUTH) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Wednesday, May 27, 2015 8:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mysterious U4088-63 from RPTSTG(ON) Sure. It's magical mystery code, but sure. 1669 ISAUTH EDCPRLG DSALEN=CDSALEN,BASEREG 1670+*** 0 00618 1671+IHB0092DS DSECT 1672+ DSD 1673+ DSCL(120+0) 00080 0 1674+ ORG IHB0092DS 1675+ DSCL(CDSALEN+8) 00614 00614 1676+ ORG 1677+ DS0D 006101678+IHB0092LG EQU *-IHB0092DS-8 00035 01510 1679+CZAMISC CSECT 1680+*-- 1681+ DS0H R:F 008761682+ USING *,15 A7F4 0021008B8 1685+ISAUTH BRC 15,IHB0092B (BC) 1686+* PPA1 constant area 14 1687+ DCAL1(IHB0092N+4-*) offs CE 1688+ DCX'CE' . CEE A0 1689+ DCX'A0' . CEE 10 1690+ DCAL1(0+0+16) . memb 08941691+ DCAL4(IHB0092P) . A( 1692+ DCAL4(0) . A( 06101693+ DCAL4(IHB0092LG)to 00061694+IHB0092N DCAL2(6) . leng C9E2C1E4E3C81695+ DCC'ISAUTH' untr 1696+*-- 1697+* PPA2 constant area 1698+IHB0092P DS0F forc 03 1699+ DCX'03' . memb 00 1700+ DCX'00' . memb 33 1701+ DCX'33' . plis 00
Re: Mysterious U4088-63 from RPTSTG(ON)
Sigh. Torture. BTW, if anyone wants to play with this I will be happy to send you the two source modules. 24 lines of C++ and 77 lines of assembler. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Thursday, May 28, 2015 7:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mysterious U4088-63 from RPTSTG(ON) Is it time to fire up a PMR? On 28/05/2015 9:55 PM, Charles Mills wrote: FWIW, I can duplicate the problem with a call from a trivial C++ program. Whether or not the program actually is authorized does not seem to make a difference. Here's the entire program: -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mysterious U4088-63 from RPTSTG(ON)
Yeah, I suppose a routine could be looking at R14 minus 10 to see how it got there. Unlikely, and awful coding technique, but possible. But why only this one routine? If I comment out the call in the (large, real) C++ program, a subsequent call to another routine in the same source module works. I would assume C++ gets the stack at startup, not on the first external call. Interesting thought. I could add a call to a dummy do-nothing routine ahead of the ISAUTH call. But frankly, I am about out of patience with this problem. I have a fix now for the real problem, so perhaps I need to get back to my real job. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bernd Oppolzer Sent: Thursday, May 28, 2015 7:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mysterious U4088-63 from RPTSTG(ON) My only guess is: the branch in the Prolog to obtain New storage in the case when the current segment is too small must point to a special routine in the rptstg(on) case. And maybe this routine has a Problem if the branch is a BRC and no BC. But I cannot really imagine what sort of problem -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Mysterious U4088-63 from RPTSTG(ON)
I have a C++ program that I am testing that is working perfectly in all
regards except one. When I run it with
//CEEOPTS DD *
RPTSTG(ON)
/*
it ABENDs with U4088-63 which is documented as save area chain corruption. I
can run it with TERMTHDACT(DUMP) or with HEAPCHK(ON,10,0,10,10,1024,0)
without error.
I have isolated the ABEND to a call to a self-written assembler function
called ISAUTH. I execute a printf() immediately before the call but not a
printf() after. I am posting below the entire code of ISAUTH. CDSALEN has a
value of x'60C'. I think other than that the code snippet is self-contained.
The assembler module contains many similar small functions. I know at least
5 of them get called without error.
It used to work. What changed? I added some functions and the module grew to
have addressability problems, so I added an IEABRCX DEFINE. I have eyeballed
the code generated by EDCPRLG and it appears correct -- now with a BRC 15
instead of a B. It would be inconvenient to get the IEABRCX back out of
there as a test.
The function is declared in C++ as extern OS {bool ISAUTH();}. The other
functions are declared similarly.
AMODE 31/XPLINK(NO)
Does anyone have any clues?
ISAUTH EDCPRLG DSALEN=CDSALEN,BASEREG=NONE
LARL R12,CZAMISC
USING CZAMISC,R12
*
* *** USING CDSASTOR,R13 Use R13 as base for reentrant store
*
* Issue the TESTAUTH
TESTAUTH FCTN=1
*
* TESTAUTH returns 0 = yes, 4 = no
* We return 1 = yes, 0 = no
SRL R15,2 Convert 4 into 1
LCR R15,R15 Convert 1 into -1
AHI R15,1 Convert 1 into 0 and 0 into 1
*
* *** J Ret_R15Return whatever is in R15
EDCEPIL ,
Charles
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mysterious U4088-63 from RPTSTG(ON)
In article 09a301d098e6$0607d120$12177360$@mcn.org you wrote:
(snip)
I have isolated the ABEND to a call to a self-written assembler function
called ISAUTH. I execute a printf() immediately before the call but not a
printf() after. I am posting below the entire code of ISAUTH. CDSALEN has a
value of x'60C'. I think other than that the code snippet is self-contained.
(snip)
It used to work. What changed? I added some functions and the module grew to
have addressability problems, so I added an IEABRCX DEFINE. I have eyeballed
the code generated by EDCPRLG and it appears correct -- now with a BRC 15
instead of a B. It would be inconvenient to get the IEABRCX back out of
there as a test.
Can you post the expansions of EDCPRLG and EDCEPIL?
I presume they do save and restoring of registers, and appropriate
save area linkage, but it would be nice to see the expansion.
The function is declared in C++ as extern OS {bool ISAUTH();}. The other
functions are declared similarly.
AMODE 31/XPLINK(NO)
Does anyone have any clues?
ISAUTH EDCPRLG DSALEN=CDSALEN,BASEREG=NONE
LARL R12,CZAMISC
USING CZAMISC,R12
*
* *** USING CDSASTOR,R13 Use R13 as base for reentrant store
*
* Issue the TESTAUTH
TESTAUTH FCTN=1
*
* TESTAUTH returns 0 = yes, 4 = no
* We return 1 = yes, 0 = no
SRL R15,2 Convert 4 into 1
LCR R15,R15 Convert 1 into -1
AHI R15,1 Convert 1 into 0 and 0 into 1
*
* *** J Ret_R15Return whatever is in R15
EDCEPIL ,
-- glen
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mysterious U4088-63 from RPTSTG(ON)
)resto 051E1760+ BALR 1,14 retur 08761761+ DCAL4(ISAUTH) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of glen herrmannsfeldt Sent: Wednesday, May 27, 2015 8:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mysterious U4088-63 from RPTSTG(ON) In article 09a301d098e6$0607d120$12177360$@mcn.org you wrote: (snip) I have isolated the ABEND to a call to a self-written assembler function called ISAUTH. I execute a printf() immediately before the call but not a printf() after. I am posting below the entire code of ISAUTH. CDSALEN has a value of x'60C'. I think other than that the code snippet is self-contained. (snip) It used to work. What changed? I added some functions and the module grew to have addressability problems, so I added an IEABRCX DEFINE. I have eyeballed the code generated by EDCPRLG and it appears correct -- now with a BRC 15 instead of a B. It would be inconvenient to get the IEABRCX back out of there as a test. Can you post the expansions of EDCPRLG and EDCEPIL? I presume they do save and restoring of registers, and appropriate save area linkage, but it would be nice to see the expansion. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
