Thanks for getting back 1) I am still debugging my code what I mean to say
by that is that my errors were incurred running under TESTAUTH (which really
shouldn't matter its just that I am sharing my findings under TEST) 2) I
have 2 load modules that I would like to be accessed by other address spaces
in the system (I realize I could have put the load library in the linklist)
however I choose to put them in LPA or to be more specific Dynamic LPA 3) my
first step is I open the load library were my load modules are located This
is my DCB STEPLB DCB DDNAME=&DDNAME, RECFM=U, DSORG=PO, MACRF=R The reason I
have DDNAME equal a variable is because running TEST in a clist I cannot
allocate STEPLIB I obtain 24 bit storage for the DCB * * Get Storage for
STEPLIB DCB * STORAGE OBTAIN,LENGTH=MYDCBLEN,ADDR=(R9),LOC=(24,64),SP=0 I
then open it * * Open STEPLIB DCB * OPEN ((R8),INPUT),MF=(E,OPENLS),MODE=31
I then issue a BLDL for purposes of getting the length of the load module
since I would like to load these modules in CSA. I realize I could of done a
LOAD and obtained the length from R1 but I found this value to be erroneous
meaning not the same value I observed by browsing the datasets in ISPF BLDL
(R8),LISTADDR I then get CSA storage using the length value from BLDL
STORAGE OBTAIN, LENGTH=(R6), ADDR=(R8), SP=228 I then load the modules into
the CSA address using the aforementioned DCB LOAD EPLOC=(R9), DCB=(R7),
ADDR=(R8), ERRET=LOADERR, SF=(E,LOADLS) After doing so two of load modules
GETMACIN and OPENFILE I try to put into LPA LA R8,DBGRWTLN(,R8) Add Wait
List Modules
*-------------------------------------------------------------------* * Add
OPENFILE and GETMACIN to LPA * * *
*-------------------------------------------------------------------* LA
R8,LPAREA USING LPMEA,R8 MVC LPMEANAME,=CL8'GETMACIN' MVC
LPMEAENTRYPOINTADDR,GETMACAD OI LPMEAENTRYPOINTADDR,LPMEAENTRYPOINTADDRBIT0
MVC LPMEALOADPOINTADDR,GETMACAD NI LPMEALOADPOINTADDR,X'7F' MVC
LPMEAMODLEN,PGMSLEN+32 LA R8,LPMEA_LEN(,R8) * MVC LPMEANAME,=CL8'OPENFILE'
MVC LPMEAENTRYPOINTADDR,OPENADDR OI
LPMEAENTRYPOINTADDR,LPMEAENTRYPOINTADDRBIT0 MVC LPMEALOADPOINTADDR,OPENADDR
NI LPMEALOADPOINTADDR,X'7F' MVC LPMEAMODLEN,PGMSLEN+28 CSVDYLPA REQUEST=ADD,
MODINFOTYPE=MEMBERLIST, NUMMOD=TWOMEM, BYADDR=YES, REQUESTOR=DBGRSERVER,
RETCODE=RETCODY, RSNCODE=ERRNX, MODINFO=LPAREA,MF=(E,DYNLPA) +* MACDATE
-02/04/19- +M00M0042 DS 0H CSVDYLPA-1 + PUSH PRINT This is the output
CSVDYLPA IKJ57024I AT +48E 15R 00000000 TESTAUTH 13r?+4cc l(200) xc
1FA9C57C. C7C5E3D4 C1C3C9D5 00008000 000008A5 *GETMACIN.......v* 00000000
000002C9 9DF4E938 1DF4E938 000003E8 *...I.4Z..4Z....Y* 1FA9C59C. 00000000
00000000 D6D7C5D5 C6C9D3C5 *........OPENFILE* 00008000 000008A6 00000341
9DF4B418 *.......w.....4..* 1FA9C5BC. 1DF4B418 00003520 00000000 00000000
*.4..............* Register 15 is 0 and the high order bit +LPMEASUCCESS EQU
X'80' Successfully processed is on it is offset A from both the GETMACIN
literal And OPENFILE literal Now here is the problem starts later in my code
I try linking to OPENFILE LINK EP=OPENFILE,
PARAM=(ALETD,=CL8'SYSADATA',EXD_PTR), MF=(E,PARAMOP),SF=(E,LINK_LIST) Then
this happens CSV005I BLDL FAILED FOR MODULE OPENFILE, DCB NOT OPEN CSV028I
ABEND806-0C JOBNAME=JOER STEPNAME=ISPFLITE IKJ56641I DBGRSERV ENDED DUE TO
ERROR IKJ56640I SYSTEM ABEND CODE 0C1 REASON CODE 00000001 TESTAUTH Don't
understand If I have it in LPA isn't that part of the system search Path ?
Thanks -----Original Message----- From: IBM Mainframe Assembler List On
Behalf Of Peter Relson Sent: Sunday, October 31, 2021 9:11 AM To:
[email protected] Subject: Re: A question about an Authorizing
PC Service Routine IBM-Main would have been a better home for the post. I
discovered this program Curious: did you discover this program's loadmod
installed on your system, or did you just discover the source for the
program? If the former, you should alert your support staff (and likely
upper management) immediately. To be completely fair, without seeing the
ETDEF for this PC it is probably not knowable if this is or is not a "magic
PC". If the PC were defined to give control in problem state, this might not
be an exposure, depending on the PKM that was established. If entered in
problem state, the SPKA would blow up unless the key of the SPKA was
represented within the PKM. And if that PKM represented the caller's PKM,
the caller already had the authority to do that SPKA. Now, the odds of that
being why someone created this are close to 0.... Once this PC routine
Branches back to the users code (BSM 0,1), the user code is running in
supervisor state and would issue a PR instruction to remove the entry from
the linkage stack. I find this code very messy. How would the user code
return to an instruction following the BSM so the PC Service Routine would
issue the PR instruction ? We should not care that it's messy; it is
unacceptable code regardless. As mentioned above, it is not true that the
user code is necessarily running in supervisor state (although likely). The
user code's PR would do what PR does when it corresponds to a PC - removing
the entry from the linkage stack and giving control to the instruction after
the PC, in the PC issuer's state and key (assuming that the key 0 routine
did not change the linkage stack entry itself). Peter Relson z/OS Core
Technology Design Scanned by McAfee and confirmed virus-free. Find out more
here: https://bit.ly/2zCJMrO
