Home > Archive > ASM370 > May 2004 > Assembler XCTL instruction -- please help
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Assembler XCTL instruction -- please help
|
|
| who me 2004-05-03, 3:31 pm |
|
Hello All
I'm an experienced *cough* COBOL programmer with some assembler background,
but i need some help with an assembler instruction Ive never used before.
Im wrinting an assembler program that will be used to intercept a call from a
driver to a subroutine. The purpose of the "interceptor" is to create an
audit trail of the application driver and all the subroutines that it calls.
but thats beside the point at the moment.
I need this batch (this is all batch by the way) assembler interceptor routine
to transfer control (XCTL seems to be my only choice) to the "real"
subroutine.
Heres the scenario:
PgmA calls PgmB
PgmB transfers control (via XCTL) to PgmC
When PgmC ends, control should be returned to PgmA
PgmA is COBOL
PgmB is Assembler
PgmC is COBOL
I have the process working up to PgmC. Upon leaving program C, I get a
S0C1 abend.
Here is the assembler program that does the XCTL: (this is PgmB)
STM R14,R12,12(R13)
BASR R12,R0
USING *,R12
ST R13,SAVEAREA+4 SAVE CALLERS SAVEAREA ADDRESS
LA R13,SAVEAREA POINT TO OUR SAVE AREA
*
CALL INTLOG,(PGMID) WRITE TO THE INTERCEPTION LOG
DISPLAY 'RETURN FROM INTLOG'
*
L R13,SAVEAREA+4 RELOAD CALLERS SAVE AREA ADDR
L R14,12(R13) RESTORE CALLERS R14
L R15,16(R13) RESTORE CALLERS R15
L R0,20(R13) RESTORE CALLERS R0
L R1,24(R13) RESTORE CALLERS R1
XCTL (2,12),EP=SCAISUBA TRANSFER CONTROL
*
SAVEAREA DS 18F
PGMID DC CL8'SCANSUBA'
LTORG
END
I have also tried this variation, and get the same result.
STM R14,R12,12(R13)
BASR R12,R0
USING *,R12
ST R13,SAVEAREA+4 SAVE CALLERS SAVEAREA ADDRESS
LA R13,SAVEAREA POINT TO OUR SAVE AREA
*
CALL INTLOG,(PGMID) WRITE TO THE INTERCEPTION LOG
DISPLAY 'RETURN FROM INTLOG'
MVC MODNAME,=C'SCAISUBA'
*
L R13,SAVEAREA+4 RELOAD CALLERS SAVE AREA ADDR
L R14,12(R13) RESTORE CALLERS R14
L R15,16(R13) RESTORE CALLERS R15
L R0,20(R13) RESTORE CALLERS R0
L R1,24(R13) RESTORE CALLERS R1
XCTL (2,12),EPLOC=MODNAME TRANSFER CONTROL
*
SAVEAREA DS 18F
PGMID DC CL8'SCANSUBA'
MODNAME DS CL8
LTORG
END
I have tried commenting out the CALL to INTLOG and the DISPLAY. These
statements don't appear to have any affect on whether the XCTL the code. They
are there to create the audit trail when I get this working.
The documentation on XCTL says that the caller's registers must be restored
prior to issuing the XCTL. I think I have that logic in ok. But the doc
also mentions that the PSW and PICA must be restored. I have no idea how
to do that. Could that be the cause of the S0C1?
Is there another (or better) solution here than using XCTL?
About the environment: This is a mainframe shop running Z/OS 390. Compiles
are AMODE31, RMODE ANY, if that helps. COBOL routines are compiled in OS390
COBOL Not sure what else I can provide, but ask anything I left out.
I appreciate any help or advice anyone can give.
Thanks!
Allen
aoe.web(at)earthlink(dot)net
| |
| Barry Schwarz 2004-05-03, 3:32 pm |
| On Sat, 01 May 2004 05:14:26 GMT, not@gonna.tell.com (who me) wrote:
>
>
>Hello All
>
>I'm an experienced *cough* COBOL programmer with some assembler background,
>but i need some help with an assembler instruction Ive never used before.
>
>Im wrinting an assembler program that will be used to intercept a call from a
>driver to a subroutine. The purpose of the "interceptor" is to create an
>audit trail of the application driver and all the subroutines that it calls.
>but thats beside the point at the moment.
>
>I need this batch (this is all batch by the way) assembler interceptor routine
>to transfer control (XCTL seems to be my only choice) to the "real"
>subroutine.
Since you use the terms "call" and "subroutine" specifically, is it
correct to assume that before you embarked on this course the driver
and the subroutine were in the same load module (had been link edited
together? If so, then XCTL is not what you want because
1 - It transfers control to a different load module.
2 - The called module returns (via R14), control returns to the OS
which treats it as the end of the task.
>
>Heres the scenario:
>
> PgmA calls PgmB
> PgmB transfers control (via XCTL) to PgmC
> When PgmC ends, control should be returned to PgmA
>
>PgmA is COBOL
>PgmB is Assembler
>PgmC is COBOL
>
The simplest solution appears to be for PgmB to:
1 - Save the environment from PgmA (registers, AMODE, etc).
2 - Perform whatever (auditing) you have in mind.
3 - Restore the PgmA environment except adjust R15 to point to
PgmC
4 - Branch to PgmC. When PgmC returns, it will be to PgmA as you
want (since R14 will still be, or be again, the return address in
PgmA).
<<Remove the del for email>>
| |
| Turtle44 2004-05-03, 3:32 pm |
| Try this
STM R14,R12,12(R13)
BASR R12,R0
USING *,R12
ST R13,SAVEAREA+4 SAVE CALLERS SAVEAREA
ADDRESS
LA R13,SAVEAREA POINT TO OUR SAVE AREA
*
CALL INTLOG,(PGMID) WRITE TO THE INTERCEPTION
LOG
DISPLAY 'RETURN FROM INTLOG'
*
L R13,SAVEAREA+4 RELOAD CALLERS SAVE AREA
ADDR
LM R14,R12,12(R13) RESTORE CALLERS REG
L R15,=V(SCAISUBA) ADDRESS OF SCAISUBA
BR R15
*
SAVEAREA DS 18F
PGMID DC CL8'SCANSUBA'
LTORG
END
HTH
remove the obvious to email me.
On Sat, 01 May 2004 05:14:26 GMT, not@gonna.tell.com (who me) wrote:
>
>
>Hello All
>
>I'm an experienced *cough* COBOL programmer with some assembler background,
>but i need some help with an assembler instruction Ive never used before.
>
>Im wrinting an assembler program that will be used to intercept a call from a
>driver to a subroutine. The purpose of the "interceptor" is to create an
>audit trail of the application driver and all the subroutines that it calls.
>but thats beside the point at the moment.
>
>I need this batch (this is all batch by the way) assembler interceptor routine
>to transfer control (XCTL seems to be my only choice) to the "real"
>subroutine.
>
>Heres the scenario:
>
> PgmA calls PgmB
> PgmB transfers control (via XCTL) to PgmC
> When PgmC ends, control should be returned to PgmA
>
>PgmA is COBOL
>PgmB is Assembler
>PgmC is COBOL
>
>
>I have the process working up to PgmC. Upon leaving program C, I get a
>S0C1 abend.
>
>Here is the assembler program that does the XCTL: (this is PgmB)
>
>
> STM R14,R12,12(R13)
> BASR R12,R0
> USING *,R12
> ST R13,SAVEAREA+4 SAVE CALLERS SAVEAREA ADDRESS
> LA R13,SAVEAREA POINT TO OUR SAVE AREA
> *
> CALL INTLOG,(PGMID) WRITE TO THE INTERCEPTION LOG
> DISPLAY 'RETURN FROM INTLOG'
> *
> L R13,SAVEAREA+4 RELOAD CALLERS SAVE AREA ADDR
> L R14,12(R13) RESTORE CALLERS R14
> L R15,16(R13) RESTORE CALLERS R15
> L R0,20(R13) RESTORE CALLERS R0
> L R1,24(R13) RESTORE CALLERS R1
> XCTL (2,12),EP=SCAISUBA TRANSFER CONTROL
> *
> SAVEAREA DS 18F
> PGMID DC CL8'SCANSUBA'
> LTORG
> END
>
>
>I have also tried this variation, and get the same result.
>
>
>
> STM R14,R12,12(R13)
> BASR R12,R0
> USING *,R12
> ST R13,SAVEAREA+4 SAVE CALLERS SAVEAREA ADDRESS
> LA R13,SAVEAREA POINT TO OUR SAVE AREA
> *
> CALL INTLOG,(PGMID) WRITE TO THE INTERCEPTION LOG
> DISPLAY 'RETURN FROM INTLOG'
> MVC MODNAME,=C'SCAISUBA'
> *
> L R13,SAVEAREA+4 RELOAD CALLERS SAVE AREA ADDR
> L R14,12(R13) RESTORE CALLERS R14
> L R15,16(R13) RESTORE CALLERS R15
> L R0,20(R13) RESTORE CALLERS R0
> L R1,24(R13) RESTORE CALLERS R1
> XCTL (2,12),EPLOC=MODNAME TRANSFER CONTROL
> *
> SAVEAREA DS 18F
> PGMID DC CL8'SCANSUBA'
> MODNAME DS CL8
> LTORG
> END
>
>
>
>I have tried commenting out the CALL to INTLOG and the DISPLAY. These
>statements don't appear to have any affect on whether the XCTL the code. They
>are there to create the audit trail when I get this working.
>
>The documentation on XCTL says that the caller's registers must be restored
>prior to issuing the XCTL. I think I have that logic in ok. But the doc
>also mentions that the PSW and PICA must be restored. I have no idea how
>to do that. Could that be the cause of the S0C1?
>
>Is there another (or better) solution here than using XCTL?
>
>About the environment: This is a mainframe shop running Z/OS 390. Compiles
>are AMODE31, RMODE ANY, if that helps. COBOL routines are compiled in OS390
>COBOL Not sure what else I can provide, but ask anything I left out.
>
>I appreciate any help or advice anyone can give.
>
>Thanks!
>
>Allen
>aoe.web(at)earthlink(dot)net
>
>
>
| |
| Binyamin Dissen 2004-05-03, 3:32 pm |
| On Sat, 01 May 2004 05:14:26 GMT not@gonna.tell.com (who me) wrote:
:>I'm an experienced *cough* COBOL programmer with some assembler background,
:>but i need some help with an assembler instruction Ive never used before.
:>Im wrinting an assembler program that will be used to intercept a call from a
:>driver to a subroutine. The purpose of the "interceptor" is to create an
:>audit trail of the application driver and all the subroutines that it calls.
:>but thats beside the point at the moment.
:>I need this batch (this is all batch by the way) assembler interceptor routine
:>to transfer control (XCTL seems to be my only choice) to the "real"
:>subroutine.
:>Heres the scenario:
:> PgmA calls PgmB
:> PgmB transfers control (via XCTL) to PgmC
:> When PgmC ends, control should be returned to PgmA
:>PgmA is COBOL
:>PgmB is Assembler
:>PgmC is COBOL
:>I have the process working up to PgmC. Upon leaving program C, I get a
:>S0C1 abend.
My guess is that COBOL is using a BALR 14,15 to invoke the routine, rather
than a LINK.
XCTL would be appropriate if a LINK was done.
If BALR 14,15 was done, you should change your assembler routine to do a LOAD
and BR 15 to the routine in place of the XCTL. And if the routine is called
many times, you will need to add a JPA search to avoid LOADing the module too
many times.
--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
| |
| Turtle44 2004-05-03, 3:32 pm |
| On Sat, 01 May 2004 23:41:39 +1200, Turtle44
<Rogers_lists@hotmail.removethis.com> wrote:
Correction
Oops - silly me - seeing R12 is your base register, it would need to
be done this way.
SCAISUBA must be linked in the same module
Try this
STM R14,R12,12(R13)
BASR R12,R0
USING *,R12
ST R13,SAVEAREA+4 SAVE CALLERS SAVEAREA
LA R13,SAVEAREA POINT TO OUR SAVE AREA
*
CALL INTLOG,(PGMID) WRITE TO THE INTERCEPTION
DISPLAY 'RETURN FROM INTLOG'
*
L R13,SAVEAREA+4 RELOAD CALLERS SAVE AREA
L R14,12(R13) RSTR CALLERS RTN ADDR
L R15,=V(SCAISUBA) ADDRESS OF SCAISUBA
LM R0,R12,20(R13) RESTORE CALLERS REG
BR R15
*
SAVEAREA DS 18F
PGMID DC CL8'SCANSUBA'
LTORG
END
HTH
Regards... Roger Sawtell
remove the obvious to email me.
| |
| Peter H. 2004-05-03, 3:33 pm |
|
The SOC1 which resulted when the XCTL'd module supposedly "returns" to the
address in R14 is caused by the address in R14 not being valid.
XCTL was originally intended for use in certain system routines, namely
OPEN/CLOSE/END-OF-VOLUME, not user routines, although nothing prevents user use
of SVC 7.
| |
| Peter H. 2004-05-03, 3:33 pm |
| [color=darkred]
My guess is that COBOL is using a BALR 14,15 to invoke the routine, rather than
a LINK.
XCTL would be appropriate if a LINK was done.[color=darkred]
Correct, and in this event, R14 would always be invalid.
In an XCTL-based subsystem, the exit from an XCTLed-to routine must be either
another XCTL (as in OPEN/CLOSE/EOV and in certain ERPs) or an SVC 3 (the EXIT
SVC), never a BR14.
| |
| Neil W Rickert 2004-05-03, 3:33 pm |
| peterh5322@aol.comminch (Peter H.) writes:
>My guess is that COBOL is using a BALR 14,15 to invoke the routine, rather than
>a LINK.
>XCTL would be appropriate if a LINK was done.
[color=darkred]
>Correct, and in this event, R14 would always be invalid.
That's not necessarily correct. It is up to the program that does
the XCTL, to make sure that R14 is valid, and will continue to be
valid after the XCTL. That is, it must not point into the module
that XCTL will delete.
>In an XCTL-based subsystem, the exit from an XCTLed-to routine must be either
>another XCTL (as in OPEN/CLOSE/EOV and in certain ERPs) or an SVC 3 (the EXIT
>SVC), never a BR14.
I don't agree. In many cases R14 will point to an SVC 3.
| |
| Binyamin Dissen 2004-05-03, 3:33 pm |
| On 01 May 2004 23:02:16 GMT peterh5322@aol.comminch (Peter H.) wrote:
:>My guess is that COBOL is using a BALR 14,15 to invoke the routine, rather than
:>a LINK.
:>XCTL would be appropriate if a LINK was done.
:>Correct, and in this event, R14 would always be invalid.
No.
:>In an XCTL-based subsystem, the exit from an XCTLed-to routine must be either
:>another XCTL (as in OPEN/CLOSE/EOV and in certain ERPs) or an SVC 3 (the EXIT
:>SVC), never a BR14.
The MVS control program set R14 to point to the SVC 3 instruction in the CVT
when it gives control via LINK or ATTACH. If this value is properly passed to
the XCTL-invoked subroutine it will be OK.
Of course, if a program "knows" that it will only be called via supervisor
assisted linkage it can exit via SVC 3 in place of BR 14 - but that limits its
use to those situations.
--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
| |
| Peter H. 2004-05-03, 3:33 pm |
| [color=darkred]
.... If this value is properly passed to the XCTL-invoked subroutine it will be
OK.[color=darkred]
That's the big if, and is consistent with my immediately previous post, which
says that it is not OK in *every* case.
[color=darkred]
Of course, if a program "knows" that it will only be called via supervisor
assisted linkage it can exit via SVC 3 in place of BR 14 - but that limits its
use to those situations.[color=darkred]
Only in the first instantiation is R14 pointed to the SVC 3 instruction in the
CVT.
In all other cases, an inline SVC 3 (or SVC 13, ABEND) is the proper exit.
In a pathological case, namely a Type 1 SVC, the only exits permissible are: 1)
a (return) branch to the task dispatcher, and 3) the execution of an ABEND SVC
(SVC 13).
There was a special case (perhaps there still is ... it's been a few, perhaps
three, decades since I reviewed the IGC003 source code) within SVC 3 itself
which allowed it, a Type 1 SVC, to issue other SVCs, including, but not
necessarily limited to CLOSE (SVC 20) and ABEND (SVC 13).
| |
| who me 2004-05-03, 3:33 pm |
|
Guys,
I appreciate all the responses. Im looking forward to trying your
suggestions. Please keep any ideas out there coming.
Thanks to everyone...
Allen
aoe.web(at)earthlink(dot)net
| |
| Greg Price 2004-05-03, 3:33 pm |
| Posting the registers and PSW at abend time is always
a great help for program check-type abends.
Or would it spoil the sport? :)
GP
who me wrote:
> Guys,
>
> I appreciate all the responses. Im looking forward to trying your
> suggestions. Please keep any ideas out there coming.
>
> Thanks to everyone...
>
> Allen
> aoe.web(at)earthlink(dot)net
| |
| Binyamin Dissen 2004-05-03, 3:33 pm |
| On 02 May 2004 01:05:46 GMT peterh5322@aol.comminch (Peter H.) wrote:
:>... If this value is properly passed to the XCTL-invoked subroutine it will be
:>OK.
:>That's the big if, and is consistent with my immediately previous post, which
:>says that it is not OK in *every* case.
If done properly.
Using non-system assisted linkage to invoke a routine that will do an XCTL is
a dangerous practice - especially if the calling chain is not aware that an
XCTL will be issued.
:>Of course, if a program "knows" that it will only be called via supervisor
:>assisted linkage it can exit via SVC 3 in place of BR 14 - but that limits its
:>use to those situations.
:>>>
:>Only in the first instantiation is R14 pointed to the SVC 3 instruction in the
:>CVT.
No - every case of LINK sets R14 to point to the SVC 3.
XCTL does not, as it is not a CALL type linkage.
:>In all other cases, an inline SVC 3 (or SVC 13, ABEND) is the proper exit.
:>In a pathological case, namely a Type 1 SVC, the only exits permissible are: 1)
:>a (return) branch to the task dispatcher, and 3) the execution of an ABEND SVC
:>(SVC 13).
:>There was a special case (perhaps there still is ... it's been a few, perhaps
:>three, decades since I reviewed the IGC003 source code) within SVC 3 itself
:>which allowed it, a Type 1 SVC, to issue other SVCs, including, but not
:>necessarily limited to CLOSE (SVC 20) and ABEND (SVC 13).
SVC 3 is the magic SVC that figures out why it was called. I once wanted to
write code to hook it but after research decided that there would be a better
way to get the function I desired.
--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
| |
| Peter H. 2004-05-03, 3:33 pm |
| [color=darkred]
SVC 3 is the magic SVC that figures out why it was called. I once wanted to
write code to hook it but after research decided that there would be a better
way to get the function I desired.[color=darkred]
SVC 3 is like God ... if it didn't exist, man would have to invent it.
There HAD to be a means of terminating a task other than abnormal termination.
SVC 13 could have performed this function ... examining the reason for the
ABEND, and then terminating the task normally if there was no actual abnormal
ending ... however, there was PCP and it had only one task, and that task
couldn't be terminated ... ever.
Therefore, a normal termination SVC was required, and SVC 3 was "it".
R14 is set to the address of the CVT's SVC 3 instruction for every instance of
LINK or ATTACH. Consequently, a program need not know whether it was invoked by
SVC 6 or SVC 42, and it can, therefore, always assume it was invoked by BALR
R14,R15.
IOW, the OS architecture for tasks assumes every module is called as an
ordinary "closed subroutine".
If actually invoked by a BALR R14,R15, then the BR R14 returns the the calling
subroutine.
If actually invoked by an SVC 6 or SVC 42, then the BR R14 actually invokes SVC
3, and that task is terminated (SVC 42 case) or that PRB is removed from the RB
queue (SVC 6 case).
XCTL is mucking with the RB queue in a well-defined way ... just not the same
way as with SVC 6 or SVC 42.
BTW ... for SVC 42 (ATTACH), the SVRB under which IGC042 runs actually becomes
the PRB for the load module which is ATTACHed as the new task.
Anther BTW ... SVC 42's final action is to invoke SVC 6 (LINK) to load the
module, setup the return linkage to SVC 3, and, finally, to branch to that
module's EP, which it places in R15, before such branch.
| |
| Sven Pran 2004-05-03, 3:33 pm |
| As far as I knew OS every "program" or "subprogram" should
assume when entered that general register:
13 contains the address of a savearea to hold 18 fullwords
14 contains the return address for exit from the (sub-)program
15 contains the entry point address to the (sub-)program
and 1 the address of a parameter address block.
I know that the savearea requirement was modified with the
introduction of BASR (instead of BALR) but I haven't heard
or seen any change for the linkage conventions related to
registers 14, 15 and 1? No program should ever need to
worry about SVC 3 for return.
Sven
"Peter H." <peterh5322@aol.comminch> wrote in message
news:20040502154830.19969.00000685@mb-m10.aol.com...
>
> SVC 3 is the magic SVC that figures out why it was called. I once wanted
to
> write code to hook it but after research decided that there would be a
better
> way to get the function I desired.
>
> SVC 3 is like God ... if it didn't exist, man would have to invent it.
>
> There HAD to be a means of terminating a task other than abnormal
termination.
>
> SVC 13 could have performed this function ... examining the reason for the
> ABEND, and then terminating the task normally if there was no actual
abnormal
> ending ... however, there was PCP and it had only one task, and that task
> couldn't be terminated ... ever.
>
> Therefore, a normal termination SVC was required, and SVC 3 was "it".
>
> R14 is set to the address of the CVT's SVC 3 instruction for every
instance of
> LINK or ATTACH. Consequently, a program need not know whether it was
invoked by
> SVC 6 or SVC 42, and it can, therefore, always assume it was invoked by
BALR
> R14,R15.
>
> IOW, the OS architecture for tasks assumes every module is called as an
> ordinary "closed subroutine".
>
> If actually invoked by a BALR R14,R15, then the BR R14 returns the the
calling
> subroutine.
>
> If actually invoked by an SVC 6 or SVC 42, then the BR R14 actually
invokes SVC
> 3, and that task is terminated (SVC 42 case) or that PRB is removed from
the RB
> queue (SVC 6 case).
>
> XCTL is mucking with the RB queue in a well-defined way ... just not the
same
> way as with SVC 6 or SVC 42.
>
> BTW ... for SVC 42 (ATTACH), the SVRB under which IGC042 runs actually
becomes
> the PRB for the load module which is ATTACHed as the new task.
>
> Anther BTW ... SVC 42's final action is to invoke SVC 6 (LINK) to load the
> module, setup the return linkage to SVC 3, and, finally, to branch to that
> module's EP, which it places in R15, before such branch.
>
>
| |
| Peter H. 2004-05-03, 3:33 pm |
| [color=darkred]
No program should ever need to
worry about SVC 3 for return.[color=darkred]
There's that qualifier, "NO", again.
Know your linkage requirements and then follow them.
Religiously.
And never use the "NO" word again.
There are always exceptions.
| |
| Sven Pran 2004-05-03, 3:33 pm |
|
"Peter H." <peterh5322@aol.comminch> wrote in message
news:20040502210241.17518.00000561@mb-m03.aol.com...
>
> No program should ever need to
> worry about SVC 3 for return.
>
> There's that qualifier, "NO", again.
>
> Know your linkage requirements and then follow them.
>
> Religiously.
>
> And never use the "NO" word again.
>
> There are always exceptions.
>
I have no intention of starting a lengthy (and valueless)
discussion on this item, but I am very interested if you
have an example where a module (except possibly SVC
transient routines which really are part of the operating
system and not available for "users" to write) can go
wrong by using the standard linkage conventions and
assuming that general registers 13, 14, 15 and 1 have
been initialized with (respectively) the savearea address,
the return address, the entry point address and the
parameter address block address?
regards Sven
| |
| Binyamin Dissen 2004-05-03, 3:34 pm |
| On Mon, 3 May 2004 10:24:43 +0200 "Sven Pran" <no.direct@mail.please> wrote:
:>I have no intention of starting a lengthy (and valueless)
:>discussion on this item, but I am very interested if you
:>have an example where a module (except possibly SVC
:>transient routines which really are part of the operating
:>system and not available for "users" to write) can go
:>wrong by using the standard linkage conventions and
:>assuming that general registers 13, 14, 15 and 1 have
:>been initialized with (respectively) the savearea address,
:>the return address, the entry point address and the
:>parameter address block address?
RPL exits, for one. They are non-privileged code and are invoked without a
save area.
Also DCB exits. IBM supplies the SYNADAF/SYSANRLS macros to get a save area
for a SYNAD exit.
--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
| |
| Peter H. 2004-05-03, 3:34 pm |
| [color=darkred]
I have no intention of starting a lengthy (and valueless)
discussion on this item ...[color=darkred]
Fair enough. Case closed.
| |
| Peter H. 2004-05-03, 3:34 pm |
| [color=darkred]
RPL exits, for one. They are non-privileged code and are invoked without a save
area.
Also DCB exits. IBM supplies the SYNADAF/SYSANRLS macros to get a save area for
a SYNAD exit.[color=darkred]
Excellent examples, and certainly saves a "valueless" discussion. Thank you.
|
|
|
|
|