Another AMODE/RMODE question 
Author Message
 Another AMODE/RMODE question

There are plenty of problems here.

First, LOAD tells you the AMODE.

97.1.5 Output Register Information

If the LOAD is successful, the GPRs contain the following when control returns to the caller:

Register Contents
0
     Entry point address of the requested load module. Load services
     setsthe high-order bit of the entry point address to the load
     module's AMODE. If the module's AMODE is ANY, it sets the
     indicator to the caller's AMODE.
1
     The high-order byte contains the load module's APF authorization code.

     | The three low-order bytes contain a length value for the
     | module. When the module is a program object, bound with
     | FETCHOPT=NOPACK option, the length value returned is in full
     | pages (this is the full size of the area obtained with
     | GETMAIN to hold the program object). If the program object is
     | bound with FETCHOPT=PACK, the length value returned is the
     | virtual storage size indicated in the directory entry. See
     | DFSMS/MVS Program Management for further information.

Second, OPEN, CLOSE and the access method modules, at least un current
MVS systems, do not have a problem with AMODE.  BUT, the OPEN parm list,
and DCB, must be below the line.  Move mode PUT and GET also may require
the buffer to be below the line.

Third, if there is a problem with

           LOAD  EP=xxxx
           LR    15,0
           BASSM 14,15

the problem is on the return, if the AMODE must change.  The BASSM
will set the AMODE, but a BR 14 will not set it back.  You have to
use a BSM 0,14 instruction to return, and restore the AMODE.  This
is why you have to be real careful about glue modules, and placing
the glue module code below the line.

-- Steve Myers

The E-mail addresses in this message are private property.  Any use of them
to  send  unsolicited  E-mail  messages  of  a  commerical  nature  will be
considered trespassing,  and the originator of the message will be  sued in
small claims court in Camden County,  New Jersey,  for the  maximum penalty
allowed by law.



Tue, 01 Feb 2000 03:00:00 GMT  
 Another AMODE/RMODE question

Tim,

I'm not sure what you described can actually be working.  Doing a
BASSM with the unmodified address supplied by LOAD will cause the
called program to start executing in AMODE 24.  Unless that program
dynamically switches to AMODE 31, a S0C4 will occur when the registers
are stored back during entry logic.  (assuming R13, as setup by the
'C' program is pointing to a Savearea that is above the line).
Additionally, if the called program is running amode 31, then, unless
modified for amode 31 processing, the OPEN and CLOSE should fail.
These macros use the LA instruction, which sets 31 bits in amode 31
and 24 bits in amode 24.  I believe that this can cause a problem with
the SVC.

To ensure that the correct amode is restored to the calling program,
without modifing the called program, you must use an intermidiate
'glue' module.  The glue module saves the return address and
addressing mode of the calling program.  It then calles the called
program using BASSM.  When the called program returns to the glue
module, the glue modules use the previously save return address and
addressing mode and does a BSM back to the original calling program.

Naturally, the glue module is defined amode any, rmode 24.  This
ensures that an old subprogram can correctly branch back.

Sam

Send private email if you want to discuss this in more detail.

Quote:

>Funny that someone else should have asked about AMODE/RMODE, just at the same time I had a question ...
>We have a C/ASM module, linked with AMODE(31)/RMODE(ANY).  The ASM part of the module issues an OS
> LOAD based on parms passed in from the C program, and then BASSMs to the address returned from the LOAD.  
>The LOAD'd module was linked AMODE(24)/RMODE(24) because it issues an OS GET, which must execute in
>that environment.

>The LOAD'd program saves registers, and seems to execute w/o a problem ... until it tries to return.  It appears
>( stress APPREARS ) that the LOAD'd module causes an 0C4 when it tries to *restore* the savearea address
>and original registers, even though it didn't have a problem saving registers in the prologue.

>We temporarily corrected the "problem" by forcing the LOAD'd module into AMODE(31) just before that step
>in the epilogue, but we can't be absolutely sure that all the programs that load that module will be AMODE(31).

>If I've used BASSM to get to the LOAD'd module, how can I be absolutely certain that the module returns in the
>same mode in which it was called?
>    TIA,
>            Tim Schubach



Tue, 01 Feb 2000 03:00:00 GMT  
 Another AMODE/RMODE question


says...

Quote:
> There are plenty of problems here.

> First, LOAD tells you the AMODE.

> 97.1.5 Output Register Information

> If the LOAD is successful, the GPRs contain the following when control returns to the caller:

> Register Contents
> 0
>      Entry point address of the requested load module. Load services
>      setsthe high-order bit of the entry point address to the load
>      module's AMODE. If the module's AMODE is ANY, it sets the
>      indicator to the caller's AMODE.
> 1
>      The high-order byte contains the load module's APF authorization code.

>      | The three low-order bytes contain a length value for the
>      | module. When the module is a program object, bound with
>      | FETCHOPT=NOPACK option, the length value returned is in full
>      | pages (this is the full size of the area obtained with
>      | GETMAIN to hold the program object). If the program object is
>      | bound with FETCHOPT=PACK, the length value returned is the
>      | virtual storage size indicated in the directory entry. See
>      | DFSMS/MVS Program Management for further information.

> Second, OPEN, CLOSE and the access method modules, at least un current
> MVS systems, do not have a problem with AMODE.  BUT, the OPEN parm list,
> and DCB, must be below the line.  Move mode PUT and GET also may require
> the buffer to be below the line.

> Third, if there is a problem with

>            LOAD  EP=xxxx
>            LR    15,0
>            BASSM 14,15

> the problem is on the return, if the AMODE must change.  The BASSM
> will set the AMODE, but a BR 14 will not set it back.  You have to
> use a BSM 0,14 instruction to return, and restore the AMODE.  This
> is why you have to be real careful about glue modules, and placing
> the glue module code below the line.

> -- Steve Myers

> The E-mail addresses in this message are private property.  Any use of them
> to  send  unsolicited  E-mail  messages  of  a  commerical  nature  will be

Actually, the ONLY thing required to be below 16M is the DCB, all my OPEN
and CLOSE calls use LOC=ANY storage for the parameter list (you must
generate the list with the MODE=31 operand).

--
Robert Ngan
CSC Financial Services Group

To reply, remove the ".spamoff" from my address



Fri, 04 Feb 2000 03:00:00 GMT  
 Another AMODE/RMODE question

Well, yes, but I find 5 byte "addresses" (which I think is what MODE=31
generates) to be more of a nuisance than a benefit.

Quote:
>Actually, the ONLY thing required to be below 16M is the DCB, all my OPEN
>and CLOSE calls use LOC=ANY storage for the parameter list (you must
>generate the list with the MODE=31 operand).

>--
>Robert Ngan
>CSC Financial Services Group

-- Steve Myers

The E-mail addresses in this message are private property.  Any use of them
to  send  unsolicited  E-mail  messages  of  a  commerical  nature  will be
considered trespassing,  and the originator of the message will be  sued in
small claims court in Camden County,  New Jersey,  for the  maximum penalty
allowed by law.



Sat, 05 Feb 2000 03:00:00 GMT  
 Another AMODE/RMODE question


says...

Quote:
> Well, yes, but I find 5 byte "addresses" (which I think is what MODE=31
> generates) to be more of a nuisance than a benefit.

> >Actually, the ONLY thing required to be below 16M is the DCB, all my OPEN
> >and CLOSE calls use LOC=ANY storage for the parameter list (you must
> >generate the list with the MODE=31 operand).

> >--
> >Robert Ngan
> >CSC Financial Services Group

> -- Steve Myers

> The E-mail addresses in this message are private property.  Any use of them
> to  send  unsolicited  E-mail  messages  of  a  commerical  nature  will be
> considered trespassing,  and the originator of the message will be  sued in
> small claims court in Camden County,  New Jersey,  for the  maximum penalty
> allowed by law.

I just looked at the generated code and it actually uses 8 bytes, 1 for
the options byte, a 3 byte filler and then the actually address of the
DCB.

--
Robert Ngan
CSC Financial Services Group

To reply, remove the ".spamoff" from my address



Sat, 05 Feb 2000 03:00:00 GMT  
 Another AMODE/RMODE question

The original post seems to be gone from my server, so I'm replying
to Sam Siegel's reply:

Going back to Tim Schubach's original remarks, he said:

"The LOAD'd program saves registers, and seems to execute w/o a
problem ... until it tries to return.  It appears (stress APPREARS)
that the LOAD'd module causes an 0C4 when it tries to *restore* the
savearea address and original registers, even though it didn't have
a problem saving registers in the prologue."

My guess here, is that the low-order three bytes of the caller's
31-bit savearea address mapped to some valid, below-16MB address
when the callee's prologue was executed, but was no longer valid at
epilog time.  (Something got stepped on.)

What's more important, though, is Tim's statement:

"We temporarily corrected the "problem" by forcing the LOAD'd
module into AMODE(31) just before that step in the epilogue, but we
can't be absolutely sure that all the programs that load that
module will be AMODE(31)."

I take this to mean that the addressing modes of all of the callees
handled by the LOAD and BASSM are unknown (i.e. other AMODE24
modules may exist).  Rather than writing a glue module, I suggest
you consider replacing the LOAD+BASSM with a LINK.  If it's an
"infrequent" call, there should be no noticable performance
penalty, and the system will handle the "gluing" for you.  The only
problem might come from a parameter list that is passed from the
caller that is above 16MB.  If one exists, you *might* need to go
back to the glue module approach and copy the parameter list (and
any above-16MB parameters it may point to) to below-16MB storage.
On the other hand, you *might* get away with re-linking your caller
to force RMODE24.  If the parameter list (and all its parameters)
are not in program-obtained storage (i.e. non-reentrant code and
they move to below-16MB with the load module) then the LINK
approach should still work.

==============  ,,   ========================================


                 -'#  IBMMAIL(USRWNZEN) --> MVS (work)
==============  ###  ========================================  
"People who write subsystems use a lot of four-letter words."



Tue, 15 Feb 2000 03:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. AMODE/RMODE question

2. Another AMODE/RMODE question

3. AMODE/RMODE question

4. OPEN & RMODE(ANY)

5. LIDT in Rmode

6. Interrupt topmode from rmode

7. LIDT in Rmode

8. AMODE 64 problem

9. amode conflict

10. Switcing amode 24 / 31 dynamically?

11. DATA(31) and AMODE=31

12. COBOL -> ASM & AMODE problem

 

 
Powered by phpBB® Forum Software