31-bit addressing in MVS CICS 
Author Message
 31-bit addressing in MVS CICS

I have inherited some old MVS CICS assembly language programs that need to
be updated to work above the 16MB line. I've never read anything that said
exactly what one needs to do, but here's what I've done so far:

- Changed BAL and BALR to BAS and BASR
- Recoded self-modifying code

What else do I need to do? Must I recode EXecuted MVC and CLC instructions?
Are there articles I can download that talk about this?

All help appreciated!

Glynn Brooks
Systems Programmer
MAGEC Software



Sun, 03 May 1998 03:00:00 GMT  
 31-bit addressing in MVS CICS

Quote:

>I have inherited some old MVS CICS assembly language programs that need to
>be updated to work above the 16MB line. I've never read anything that said
>exactly what one needs to do, but here's what I've done so far:
>- Changed BAL and BALR to BAS and BASR
>- Recoded self-modifying code
>What else do I need to do? Must I recode EXecuted MVC and CLC instructions?
>Are there articles I can download that talk about this?

The addressing and residency mode of an assembler program can be set
either at assembly time or at linkage time.
The assembler intructions are AMODE and RMODE for addressing mode and
residency mode respectively. AMODE 31 and RMODE ANY will  allow the
module to be loaded above the line.
The same values may be specified at the linkage step to 'override' the
modes set at assembly time.
The EX, MVC and CLC instructions are not sensitive to addressing mode.
In addition to BAL and BALR, the LA and LRA instructions are sensitive
to addressing mode. In the case of LA, problems may arise if flags are
saved in the high order byte of the register - if not, then there is
no problem.
Addressing mode can also be changed dynamically during execution, but
that is probably not relevant here.

For an extensive discussion on 24/31 addressing see 'Advanced
Assembler Language and MVS Interfaces' by Carmine Cannatello.

Hope this proves useful,
--
 Richard.

 Hucknall,  England.



Mon, 04 May 1998 03:00:00 GMT  
 31-bit addressing in MVS CICS
: I have inherited some old MVS CICS assembly language programs that need to
: be updated to work above the 16MB line. I've never read anything that said
: exactly what one needs to do, but here's what I've done so far:

: - Changed BAL and BALR to BAS and BASR
: - Recoded self-modifying code

: What else do I need to do? Must I recode EXecuted MVC and CLC instructions?
: Are there articles I can download that talk about this?

: All help appreciated!

: Glynn Brooks
: Systems Programmer
: MAGEC Software

Glynn, not sure what all has to be changed, but, what the hell are
self-modifying instructions doing in a CICS program????
I will research your question tomorrow and reply to this thread.

Don Eakin
--
From the keyboard of Don Eakin --- Conversion Associates



Mon, 04 May 1998 03:00:00 GMT  
 31-bit addressing in MVS CICS
Most all of the instructions are insensitive to addressing mode, other than
the fact that the high-order byte of addresses is *ignored* in 24-bit mode,
whereas they are significant in 31-bit mode.  So, the main thing that you
have to look out for are places where the programmer couldn't resist using
the high-order byte of a pointer for some other purpose (e.g., flag bits):
we've all done it at some time in our past...

BAL/BALR, for instance, work just fine in 31-bit mode -- that is, unless you
are using them for their side-effect (in 24-bit mode) of putting the ILC and
condition code bits into the high-order byte of the linkage register (this
tends to be rare).  Also, I don't understand the previous comment about LA
being sensitive to the mode: this instruction gives identical results in
both modes (e.g., the high-order byte is always cleared when in 24-bit
mode).

If you have to work with bi-modal code, then you have to be a bit careful,
and make use of BASSM/BSM for linkage (or the MVS LINK macro).  However, for
a simple wholesale switch into 31-bit mode, all you really have to do is be
careful that you keep your high-order bytes "clean", and you'll be fine.


      IBM Research, Yorktown Heights



Tue, 05 May 1998 03:00:00 GMT  
 31-bit addressing in MVS CICS



Quote:
>I have inherited some old MVS CICS assembly language programs that
need to
>be updated to work above the 16MB line. I've never read anything
that said
>exactly what one needs to do, but here's what I've done so far:

>- Changed BAL and BALR to BAS and BASR
>- Recoded self-modifying code

I find that using a BASSM in place of BALR if you are transfering
control over to another program especially if you are not sure what
AMODE the program you passing control to.

Quote:

>What else do I need to do? Must I recode EXecuted MVC and CLC

instructions?

No, your main body of the program should be OK.  I found I only had
to mess with changing the linkage between called programs, and
ensuring that the Mode in the PSW gets set correctly as it passes
from one program to the next (especially if those programs are not
of the same mode).

Quote:
>Are there articles I can download that talk about this?

I had to do this myself mostly by trial and error, wish I had some
resources that would have saved some time.  
Quote:

>All help appreciated!

>Glynn Brooks
>Systems Programmer
>MAGEC Software



Tue, 05 May 1998 03:00:00 GMT  
 31-bit addressing in MVS CICS

  Also, I don't understand the previous comment about LA

Quote:
>being sensitive to the mode: this instruction gives identical results in
>both modes (e.g., the high-order byte is always cleared when in 24-bit
>mode).


>      IBM Research, Yorktown Heights

The LA should only clear the high-order BIT in 31 bit mode.
Mike Giaquinto...


Thu, 07 May 1998 03:00:00 GMT  
 31-bit addressing in MVS CICS

Besides the POPS, MVS/ESA System Programming Library:Application
Development Guide GC28-1852 and MVS/ESA Application Development Guide
GC28-1821 has decent discussions on AMODE and RMODE.


Thu, 07 May 1998 03:00:00 GMT  
 31-bit addressing in MVS CICS
Talking of the abuse of the high order byte in 24-bit mode, one
common thing to watch out for is the use of

        MVI     X'80',end-of-parms-list

where it should use

        OI      X'80',end-of-parms-list

Otherwise 'clean' programs often fail in this respect (I don't know why).

--



Sat, 16 May 1998 03:00:00 GMT  
 31-bit addressing in MVS CICS

Quote:
>Talking of the abuse of the high order byte in 24-bit mode, one
>common thing to watch out for is the use of

>        MVI     X'80',end-of-parms-list

>where it should use

>        OI      X'80',end-of-parms-list

>Otherwise 'clean' programs often fail in this respect (I don't know why).

I had a question about this - A 'call using' from Cobol would set the H.0. bit
of the last parm address passed to assembler. With Cobol2 now running in 24
and/or 31 bit addresses how does it now tell assmebler the end of the parm
list on a 'call using' if all addresses are at 31 bit??

thanks
steve
--

3M Health Information Systems                          --------  __o
Wallingford, Connecticut        " GO UCONN HUSKIES "  -------  _`\<,_
Give me your dirty love -- Frank Zappa               -------  (*)/ (*)



Mon, 18 May 1998 03:00:00 GMT  
 31-bit addressing in MVS CICS

Quote:

>of the last parm address passed to assembler. With Cobol2 now running in 24
>and/or 31 bit addresses how does it now tell assmebler the end of the parm
>list on a 'call using' if all addresses are at 31 bit??

Simple.  If (for instance) you have 5 parms, parms 0 through 3
will be high-order bit zero, and 31 bits of addres, and parm 4 will
be high order bit one, and 31 bits of address...

                                Valdis Kletnieks
                                Computer Systems Engineer
                                {*filter*}ia Tech



Tue, 19 May 1998 03:00:00 GMT  
 31-bit addressing in MVS CICS
|> >Talking of the abuse of the high order byte in 24-bit mode, one
|> >common thing to watch out for is the use of
|> >
|> >        MVI     X'80',end-of-parms-list
|> >
|> >where it should use
|> >
|> >        OI      X'80',end-of-parms-list
|> >
|> >Otherwise 'clean' programs often fail in this respect (I don't know why).
|>
|>
|> I had a question about this - A 'call using' from Cobol would set the H.0. bit
|> of the last parm address passed to assembler. With Cobol2 now running in 24
|> and/or 31 bit addresses how does it now tell assmebler the end of the parm
|> list on a 'call using' if all addresses are at 31 bit??

No problem, 31 bits still leaves the high order bit (MSB) for this use. The OI
above would still work while the MVI will not.

--



Fri, 22 May 1998 03:00:00 GMT  
 31-bit addressing in MVS CICS

Quote:

>I had a question about this - A 'call using' from Cobol would set the H.0. bit
>of the last parm address passed to assembler. With Cobol2 now running in 24
>and/or 31 bit addresses how does it now tell assmebler the end of the parm
>list on a 'call using' if all addresses are at 31 bit??

The end-of-plist flag is not related to 31-bit addressing.


Tue, 26 May 1998 03:00:00 GMT  
 31-bit addressing in MVS CICS

Quote:


>>I had a question about this - A 'call using' from Cobol would set the H.0. bit
>>of the last parm address passed to assembler. With Cobol2 now running in 24
>>and/or 31 bit addresses how does it now tell assmebler the end of the parm
>>list on a 'call using' if all addresses are at 31 bit??

Notice that it's the high order bit that indicates the end of the parmlist.
Therefore it does not figure into a 31-bit address and can still be used
since this is the 32-bit in a fullword (or the first of 32-bits if you
prefer).


Sun, 31 May 1998 03:00:00 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. 31-bit Addressing Problem

2. 31 Bit Addressing

3. Use of ARCHRCAL in 31 bit address spece ?

4. 31 bit vs 24 bit - two easy questions

5. 31-bit Programming Question

6. Bit instructions with offset more than 31

7. New Release Info/24 vs. 31 bit

8. Performance (non)optimization: 31-bit ints in pointers

9. longint on ALPHA: more efficient 31 bit digits?

10. US - FL - S.E. ****MVS/CICS PROGRAMMERS (UNIX,MVS/TSO,ISPF,COBOL)****CONTRACT

11. DATA(31) and AMODE=31

12. Errors: cannot use 16-bit register with a 32-bit address

 

 
Powered by phpBB® Forum Software