>> -----Original Message-----
>> From: IBM Mainframe Discussion List On Behalf Of Capomaestro
>>
>> Had the recent opportunity to code some dual-mode (CICS & batch) assembler.
>> After searching the LISTSERVs the DFHAFCD macro (<hlq>.SDFHMACS) revealed
itself. The code did not contained
>> CICS EXEC statements and therefore did not require preprocessing. Upon
entry under CICS the registers point into
>> La-la Land (what's a sock for?). What to do?
>> Add this to the ASM source -
>>
>> punch ' INCLUDE SDFHLOAD(DFHEAI)'
>> punch ' ORDER DFHEAI /* fake for CICS CI :P */'
>> ...or hardcode into the LKED step SYSIN
>If your dual-mode routine does not issue any EXEC CICS commands, you not
only don't need but should
>NOT include the CICS stub in the load module.
>> ...and code the DFHAFCD macro -
>> lr r2,r1 hold that thought...
>> dfhafcd type=LOCATE,cb=AFCB
>> ltr r15,r15 is this CICS?
>> jz not_under_CICS no.
>> la r1,4(,r2) yes. bump over EIBPTR
>> l r1,0(,r1) pointer to DFHCommarea
>> st r1,0(,r2) store into EIBPTR
>It's not clear from this snippet why you believe R1 points to EIBPTR before
you determine whether you're
>running in CICS. How is this program normally entered? ("Main" program or
subroutine?)
On Tue, 16 Aug 2005 09:56:42 -0500, Chase, John <[EMAIL PROTECTED]> wrote:
>> -----Original Message-----
>> From: IBM Mainframe Discussion List On Behalf Of Capomaestro
>>
>> Au contraire, the DFHEAI stub is *required* to be the first CSECT in the
module. CICS 'interrogates' modules
>>for it's I-catcher to determine if it is command level or not.
>Sorry; I thought you said that this program, being usable in both batch and
CICS environs, did not contain any
>EXEC CICS commands. If that's true, it does not need, and you should not
specify, any CICS stub at all. (BTW,
>the "requirement" for the CICS stub to be the first CSECT applied to OS/VS
COBOL and the DFHECI stub.)
>> Use the linkage editor NAME statement to point to your favourite entry
point (omitted, admittedly
>>but we're all adults here).
>
>> As for R1? Standard linkage conventions says it points to the address of
the parameter list and the code
>>snippet, once detecting CICS dummys-up the EIBPTR with the address of the
EIBCAPTR (DFHCOMMAREA being a
>>list of addresses).
>
>OK, now it appears this program is a CALLed sub-program rather than a
"main" program. Since you snipped out
>all of your original post, please remind me where and when the program
suffers the "foot warmer".
>
> -jc-
>
If CICS (KCP, which would make the assembler code "main", right?) detects
that a module is not command level then R1 does not point at a parameter
list (DFHCOMMAREA) neither does R13 point to a savearea (ASRA/S0C4, you say
potato and I say potato). Therefore the stub is *required* under CICS and
harmless in batch.
YMMV (but I am sceptical).
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
