COBOL CALLing ALC ...

[Steve Thompson]

I am trying to determine how I am supposed to know if a COBOL
program is AMODE=31/ANY when they call an ALC subroutine.

The routine getting control has just been through an upgrade from
1979 style of NOREUS and data mixed in with instructions.

Also, this routine is not LE conforming. It has never been.

I'm used to doing a BSM to return as a subroutine to have
addressing modes match. I had assumed that the caller did BSSM
not just BASR or BALR

So when the program ends and returns to the caller via BSM R14,
wow, you would not believe all the ESTAEs that get driven
(including this programs ESTAEX). LE throws a fit and thankfully,
having set up SYSMDUMP with DISP=MOD, I get the dump I need and
IPCS ignores the second dump. ;-)

So, R14 does not have the hi-order bit on when I am called.

COBOL being used is Enterprise COBOL 4.2 (which is currently
supported).

The environment, just so we are all on the same page is JES2,
z/OS 2.2, z13EC.

Regards,
Steve Thompson

PS. I have been scanning various manuals (including the LE one)
and nothing is said about this. And I don't have any MVS/XA or
MVS/ESA manuals around anymore.

[Sam Siegel]

Look at the Test Addressing Mode (TAM) instruction,

[John McKown]

​I did this long ago for a COBOL program. Excerpts below.

... save ...
MAINLINE DS 0H
L R15,=A(DO31BIT+X'80000000') JM0803
BASSM R14,R15 FORCE 31 BIT MODE JM0803
* JM0803
* THE PREVIOUS TWO INSTRUCTIONS FORCE THE CPU INTO 31 BIT MODE
* WHILE BRANCHING TO THE LABEL 'DO31BIT'.
* JM0803
DO31BIT DS 0H JM0803
ST R14,MODE SAVE CURRENT MODE JM0803
NC MODE,=X'80000000' CLEAR BITS JM0803
* JM0803
* THE BASSM INSTRUCTION PLACED THE CURRENT PSW ADDRESS INTO R14.
* THIS INCLUDES THE THEN-CURRENT ADDRESSING MODE. IF THE HIGH BIT
* OF REG 14 IS 1, THEN THE CPU WAS ALREADY IN 31 BIT MODE. IF IT
* WAS ZERO, THEN THE CPU WAS IN 24 BIT MODE. IN EITHER CASE, THE
* CPU WILL BE IN 31-BIT MODE AFTER THE BASSM.
* WE SAVE THE HIGH-BIT OF R14 SO THAT WE CAN RETURN TO THE
* ORIGINAL CALLER IN HIS ORIGINAL ADDRESSING MODE.
* JM0803
...
... code
...
... return
* LET'S GO BACK TO THE CALLER. SINCE WE MAY NEED TO CHANGE BACK
* TO 24 BIT MODE, WE CAN'T USE THE RETURN MACRO. SO LET'S JUST
* ISSUE THE INSTRUCTIONS OURSELVES. THE MAIN DIFFERENCE BELOW
* IS THE USE OF THE BSM INSTRUCTION INSTEAD OF THE BR INSTRUCTION.
* THE BSM INSTRUCTION WILL CHANGE THE MODE AS APPROPRIATE.
* JM0803
LR R1,R13 SAVE REGISTER 13 JM0803
L R13,4(,R13) GET CALLER'S R13 JM0803
L R14,12(,R13) GET RETURN ADDRESS JM0803
O R14,MODE SET ORIGINAL JM0803
* ADDRESSING MODE JM0803
LM R0,R12,20(R13) RELOAD REGISTERS JM0803
SLR R15,R15 ZERO COND CODE JM0803
OI 15(R13),X'01' SET FLAG JM0803
BSM R0,R14 RETURN TO CALLER JM0803
* WHILE SETTING THE JM0803
* ADDRESS MODE JM0803
​


​That is directly from my code.



--
"Pessimism is a admirable quality in an engineer. Pessimistic people check
their work three times, because they're sure that something won't be right.
Optimistic people check once, trust in Solis-de to keep the ship safe, then
blow everyone up."
"I think you're mistaking the word optimistic for inept."
"They've got a similar ring to my ear."

From "Star Nomad" by Lindsay Buroker:

Maranatha! <><
John McKown

[Scott Ford]

Steve,

Also very the called Assembler subroutine isn't doing I/O below the line and
verify your LE parms are ALL31(ON) , which is one of many to be careful of
with LE.

Scott

[John McKown]

On Mon, Jul 11, 2016 at 3:09 PM, Steve Thompson <ste...@copper.net> wrote:

> I am trying to determine how I am supposed to know if a COBOL program is
> AMODE=31/ANY when they call an ALC subroutine.
>

​Look at the TAM instruction.​

TEST ADDRESSING MODE
TAM [E]
'010B'

The extended-addressing-mode bit and basic-
addressing-mode bit, bits 31 and 32 of the current
PSW, respectively, are tested, and the result is indi-
cated in the condition code.
Resulting Condition Code:
0 PSW bits 31 and 32 zeros (indicating 24-bit addressing mode)
1 PSW bit 31 zero and bit 32 one (indicating 31-bit addressing mode)
2 --
3 PSW bits 31 and 32 ones (indicating 64-bit addressing mode)
Program Exceptions:
•
Transaction constraint
Programming Note: The case when PSW bit 31 is one and bit 32 is zero causes
an early PSW specification exception to be recognized.

>
> Regards,
> Steve Thompson
>
> PS. I have been scanning various manuals (including the LE one) and
> nothing is said about this. And I don't have any MVS/XA or MVS/ESA manuals
> around anymore.
>

[Peter Relson]

>I'm used to doing a BSM to return as a subroutine to have
>addressing modes match. I had assumed that the caller did
>BSSM not just BASR or BALR

Whether BASSM, BASR, or BALR bit 32 of the 64-bit GR will be on if the
caller was AMODE 31.
But if the call was done via
LA 14,return_address
B 0(15)

Then you're out of luck.

I trust that "BSM R14" was a typo and you meant "BSM 0(R14)"

If you know that you're not called by BASSM, then BSM 14,0 upon entry will
make sure that you can return via BSM.
But if you are (or can be) called by BASSM, that does not work. That's why
the TAM instruction upon entry is not helpful for such a case - it only
tells you the current AMODE which might not match the caller's AMODE.


Peter Relson
z/OS Core Technology Design

[Richard Kuebbing]

We are a very large mainframe shop and use Cobol extensively. We have both main program assembler and Asm subroutines.

We find that if you call a AMODE 24 subroutine dynamically, Cobol complains.

I recommend that before STM 14,12 in subroutine, use the following so that you always return to the caller in the mode they called you

BSM R14,0 *Save mode bit to use when exit

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Steve Thompson
Sent: Monday, July 11, 2016 4:10 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: COBOL CALLing ALC ...

I am trying to determine how I am supposed to know if a COBOL program is AMODE=31/ANY when they call an ALC subroutine.

The routine getting control has just been through an upgrade from
1979 style of NOREUS and data mixed in with instructions.

Also, this routine is not LE conforming. It has never been.

I'm used to doing a BSM to return as a subroutine to have addressing modes match. I had assumed that the caller did BSSM not just BASR or BALR

So when the program ends and returns to the caller via BSM R14, wow, you would not believe all the ESTAEs that get driven (including this programs ESTAEX). LE throws a fit and thankfully, having set up SYSMDUMP with DISP=MOD, I get the dump I need and IPCS ignores the second dump. ;-)

So, R14 does not have the hi-order bit on when I am called.

COBOL being used is Enterprise COBOL 4.2 (which is currently supported).

The environment, just so we are all on the same page is JES2, z/OS 2.2, z13EC.

Regards,
Steve Thompson

PS. I have been scanning various manuals (including the LE one) and nothing is said about this. And I don't have any MVS/XA or MVS/ESA manuals around anymore.

----------------------------------------- The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you

[Gary Weinhold]

As the responses have indicated this is not a trivial task and it could
be impossible in the general case. Although the TAM or BSM instructions
can determine the addressing mode at entry in most cases, you do not
know for sure whether the R1, R13 and R14 addresses are "clean" for the
addressing mode you determined. This may not be as messy for your case,
where it sounds like the caller is always some version of COBOL. But if
the caller could be an assembler program or subroutine written long ago,
there may be flags in the first byte of the registers, amode switches in
the program, or other non-standard techniques.

Since you are called by a known level of COBOL, either directly or
through an LE service, you might check if there is a missing PTF. Our
records indicate that IBM fixed CEEXCRTH for APAR PM52681, but dropped
the fix when creating z/OS 2.1 (PI29344). The problem was a AMODE-31 R14
without the high-order bit on, which IBM accepted as an error in LE.

Regards, Gary

__________

[Tom Marchant]

On Mon, 11 Jul 2016 16:09:43 -0400, Steve Thompson wrote:

>I'm used to doing a BSM to return as a subroutine to have
>addressing modes match. I had assumed that the caller did BSSM
>not just BASR or BALR
>
>So when the program ends and returns to the caller via BSM R14,
>wow, you would not believe all the ESTAEs that get driven
>(including this programs ESTAEX). LE throws a fit and thankfully,
>having set up SYSMDUMP with DISP=MOD, I get the dump I need and
>IPCS ignores the second dump. ;-)
>
>So, R14 does not have the hi-order bit on when I am called.

As Peter said, bit 32 of R14 is set according to AMODE by BALR and
BASR when running in 24-bit or 31-bit mode.

You can verify that by looking at your caller's save area in the dump.
I think that the error is not what you think it is.

--
Tom Marchant