LOADING An AMODE64 Program

[ess...@juno.com]

I want to load a program that has AMODE 64 from a Program with AMODE 31.
.
.
I looked at David Bonds Share Session 8158 - August. 2003
64-Bit z/OS Assembler Coding.
.
It was very informative.
.
.
So I issue a Load for PROG64 which has AMODE 64, from a program with AMODE 31.
*
LARL R2,PROG64$
LOAD EPLOC=(R2) ISSUE LOAD
STM R15,R1,SVLOADZ SAVE REGISTERS FROM LOAD ST R0,PROD64@ STOR MODULE ADDRESS
.
.
At a Latter Time,I want to invoke this module passing a structure whose address is in Register 1, using the following instructions.
*
LARL R1,STRUCT31 31 Bit Structure
L R15,PROG64@ Get Target Routine Address from Load
LLGTR R15,R15 Ensure R15 Has a Good Address
BASSM R14,R15 Call PROG64 in AMODE 64
.
*
*31 Bit Storage
DS 0D
PROG64$ DC CL8'PROG64 '
PROG64@ DC A(0)
*
STRUCT31 DS CL256
.
.
Are the above sequence of instructions correct ?
Do I need to issue LLGTR ?
What am I mis understanding to accomplish this ?
.
.
Thanks
Paul D'Angelo
-----------------------------------------------------------------

[Bob Rutledge]

In order to have BASSM switch to 64-bit addressing, R15 (in your example) must
be (arithmetically) odd; bit 63 must be 1.

Bob

[ess...@juno.com]

Bob Rutledge wrote

>In order to have BASSM switch to 64-bit addressing, R15 (in >your example) must be (arithmetically) odd; bit 63 must be 1.

Can I replace LLGTR R15,R15 with OILL R15,X'0001'
.
.
Thanks

[Bob Rutledge]

Since LLGTR supplies 33 zero-bits at the high-order end and that OILL supplies a
one-bit at the low-order end, I'd say no. Add, not replace.

Bob

[ess...@juno.com]

Thanks Again
SO the sequenec of Instructions should look like this.

LARL R1,STRUCT31 31 Bit Structure
L R15,PROG64@ Get Target Routine Address from Load
LLGTR R15,R15 Ensure R15 Has a Good Address

OILL R15,X'0001' Ensure bit 63 is 1

BASSM R14,R15 Call PROG64 in AMODE 64

*
*31 Bit Storage
DS 0D
PROG64$ DC CL8'PROG64 '
PROG64@ DC A(0)
*
STRUCT31 DS CL256
.

[Bob Rutledge]

Yes, but note: If the loaded program is _marked_ AMODE 64, the LOAD service
will do all that stuff for you and return the 64-bit address in R0.

Bob

[Andreas F. Geissbuehler]

Bob Rutledge wrote:
> Yes, but note: If the loaded program is _marked_ AMODE 64, the LOAD service
> will do all that stuff for you and return the 64-bit address in R0.
>

> On 8/8/2015 5:53 PM, Paul wrote:
>> Thanks Again
>> SO the sequenec of Instructions should look like this.
>>
>> LARL R1,STRUCT31 31 Bit Structure
>> L R15,PROG64@ Get Target Routine Address from Load
>> LLGTR R15,R15 Ensure R15 Has a Good Address
>> OILL R15,X'0001' Ensure bit 63 is 1
>> BASSM R14,R15 Call PROG64 in AMODE 64
>>
>> *
>> *31 Bit Storage
>> DS 0D
>> PROG64$ DC CL8'PROG64 '
>> PROG64@ DC A(0)
>> *
>> STRUCT31 DS CL256

Paul, just in case you or someone decides to add AMODE 64 I'd change
PROG64@ DC A(0) --> 2A(0)

Andreas Geissbuehler

[ess...@juno.com]

Andreas and Bob
Thank You

Let me see if I understand this
After the load I would issue the following
Rx - GeneralPurpose Registers
Gx - 64Bit Registers

After the Load
ST R0,FWD
LLGTR G15,R0
STG G15,PROG64@
.
.
PROG64@ DC 2A(0)
FWD DC A(0)
.
.
* To Invoke the 64Amode Module

LARL R1,STRUCT31 31 Bit Structure

LG R15,PROG64@ Ensure R15 Has a Good Address

OILL R15,X'0001' Ensure bit 63 is 1
BASSM R14,R15 Call PROG64 in AMODE 64
*

So if the above sequence of instructions is corect Do I still Need the OILL instruction ?

Paul D'Angelo
*************

---------- Original Message ----------
From: "Andreas F. Geissbuehler" <afg...@VIDEOTRON.CA>
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: LOADING An AMODE64 Program

[Walt Farrell]

On Sat, 8 Aug 2015 21:58:53 -0400, Andreas F. Geissbuehler <afg...@VIDEOTRON.CA> wrote:

>Bob Rutledge wrote:
>> Yes, but note: If the loaded program is _marked_ AMODE 64, the LOAD service
>> will do all that stuff for you and return the 64-bit address in R0.
>>
>> On 8/8/2015 5:53 PM, Paul wrote:
>>> Thanks Again
>>> SO the sequenec of Instructions should look like this.
>>>
>>> LARL R1,STRUCT31 31 Bit Structure
>>> L R15,PROG64@ Get Target Routine Address from Load
>>> LLGTR R15,R15 Ensure R15 Has a Good Address
>>> OILL R15,X'0001' Ensure bit 63 is 1
>>> BASSM R14,R15 Call PROG64 in AMODE 64
>>>
>>> *
>>> *31 Bit Storage
>>> DS 0D
>>> PROG64$ DC CL8'PROG64 '
>>> PROG64@ DC A(0)
>>> *
>>> STRUCT31 DS CL256
>
>Paul, just in case you or someone decides to add AMODE 64 I'd change
>PROG64@ DC A(0) --> 2A(0)

Did you perhaps mean "decides to add RMODE 64"?

--
Walt

[Andreas F. Geissbuehler]

Yes indeed, that's what I meant, thx!

Even if it currently fits into a word, I prefer consistency, use doublewords,
the Grand's and as Bob suggested (below), let LOAD return a 64-bit address.

Andreas

[Peter Relson]

The original post made no mention of what problem (if any was
encountered).

There is no need to LLGTR or OILL. The value returned from LOAD is
suitable for use by BASSM. Thus it has the low bit on when the module is
AMODE 64.

But the right thing to do after the load is to save the 64-bit GR0 not the
32-bit GR0. The LLGTR will be OK as long as the module is below 2G (it
does not clear bit 63), but someday the module might be above 2G. You
don't want to be clearing 33 bits of a 64-bit address.

When you want to call, assuming that you want to place the entry point
address in register 15, set 64-bit GR15 and issue BASSM 14,15.

But of course you'd better make sure that any data that that target
routine will rely on has also been set up properly (such as the high
halves of parameter list address and save area address). Thus (adding the
LLGTR for R1, and changing PROG64@ to be a doubleword and using LG)

LARL R1,STRUCT31 31 Bit Structure

LLGTR R1,R1 Clear high bit in case it's an AMODE 64 target
LG R15,PROG64@ Get 64-bit Target Routine Address from Load
BASSM R14,R15 Call PROG64 in whatever AMODE it is defined to be

Where PROG64@ is not "A" or even "2A" but "AD". It should be double-word
aligned for best processing.

Peter Relson
z/OS Core Technology Design

[rkue...@tsys.com]

I remember a mapping macro used to address the fields in the RPL. I have
found macros in SYS1.MACLIB that reference RPLRTNCD but can't find the old
macro. One of its names may have been IFGRPL which is also referenced but
which also does not exist. Is it gone?

----------------------------------------- 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

[John McKown]

SYS1.MODGEN(IFGRPL) exists in both z/OS 1.12 and z/OS 2.1.

--

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

[rkue...@tsys.com]

thanks

Efforts and courage are not enough without purpose and direction. - John
F. Kennedy
Fasten your seat belts, it's going to be a bumpy ride. - Bette Davis (as
character Margo Channing) _All About Eve_1950
Furious activity is no substitute for understanding. - H. H. Williams
Our greatest danger in life is in permitting the urgent things to crowd
out the important. - Charles E. Hummel
Quidquid latine dictum sit, altum videtur.

[Robert Ngan]

For the general case (i.e. modules that could be any AMODE), use:

LLGF R15,PROG@64
BASSM R14,R15

Robert Ngan
CSC Financial Services Group

IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
2015/08/09 09:22:39:

> From: "ess...@juno.com" <ess...@JUNO.COM>
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Date: 2015/08/09 09:25
> Subject: Re: LOADING An AMODE64 Program

> Sent by: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU>
>

[Bob Rutledge]

If PROG@64 us a 64-bit address field; branching to its high-order word will
currently head for location 0.

If PROG@64 is a 32-bit address field LLGF will leave bit 33 on and head for
never-never land.

Bob

[Robert Ngan]

z/OS doesn't support RMODE=64 modules at present. Since LLGF loads a 32-bit
address into a 64-bit register, it'll work for all valid 32-bit entry point
address values. For 64-bit address fields, use LG.

Robert Ngan
CSC Financial Services Group

IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

2015/08/10 18:00:04:

> From: Bob Rutledge <deer...@IX.NETCOM.COM>
> To: ASSEMBL...@LISTSERV.UGA.EDU

[Paul Gilmartin]

On 2015-08-10 17:47, Robert Ngan wrote:
> z/OS doesn't support RMODE=64 modules at present. Since LLGF loads a 32-bit
> address into a 64-bit register, it'll work for all valid 32-bit entry point
> address values. For 64-bit address fields, use LG.
>

This feels wrong to me. If a program in AMODE 64 LOADs a module, won't
LOAD return a 64-bit address?

Isn't RMODE 64 now supported for data-only modules?

If a data-only module is marked RMODE 64, AMODE 64, it should be
the programmer's responsibility to clear bit 63.

-- gil

[David de Jongh]

I generally code a small assembler program with a DSECT for each mapping
macro I'm interested in, with GEN, or whatever parameter(s) will force an
expanded print. That way, I don't have to count displacements when I'm
looking in a dump.
David de Jongh

[Peter Relson]

It is clearly wrong to capture the 4-byte result of LOAD and then use LLGF
if the module can be AMODE 64.
And, yes, the 8-byte GR0 can be used in all cases (the high half not being
relevant unless AMODE 64).

As I had mentioned, the result of LOAD is suitable for use with BASSM and
thus for AMODE 64 has the low bit on.
If that is then used with LLGF this will be a branch to an odd address and
a specification exception will result.

[Tom Marchant]

On Tue, 11 Aug 2015 08:46:39 -0400, Peter Relson wrote:

>If that is then used with LLGF this will be a branch to an odd address and
>a specification exception will result.

You lost me with that one Peter. Given all of these conditions:
1. A program stores the low half of R0 as returned from LOAD
2. The high half of R0 returned from LOAD is 0
3. R15 is loaded from the saved R0 with LLGF
4. The program issued BASSM R14,R15

Everything will work correctly. Of course, if the program uses BASR
rather than BASSM, a specification exception will result.

I would say that the correct sequence should be:

LOAD modulename
STG R0,moduleaddreess
LG R15,moduleaddress
BASSM R14,R15

where
moduleaddress DS FD
or
moduleaddress DS AD

Of course, if you don't need to keep the module address around because
you will only call it once, the STG/LG can be replaced with
LGR R15,R0

--
Tom Marchant

[Paul Gilmartin]

On 2015-08-11, at 07:50, Tom Marchant wrote:

> On Tue, 11 Aug 2015 08:46:39 -0400, Peter Relson wrote:
>
>> If that is then used with LLGF this will be a branch to an odd address and
>> a specification exception will result.
>
> You lost me with that one Peter. Given all of these conditions:
> 1. A program stores the low half of R0 as returned from LOAD
> 2. The high half of R0 returned from LOAD is 0
>

If it's a data-only module with RMODE(64) the high half may be nonzero.

> 3. R15 is loaded from the saved R0 with LLGF
> 4. The program issued BASSM R14,R15
>

But if it's data-only:
o you wouldn't want to branch to it.
o you need to clear bit 63 before accessing it.

(Might one declare a data-only module as RMODE(64) AMODE(24) so
it may be loaded above the bar, but so LOAD returns an unbiased
address?)

(Might the programmer declare an odd address as an ENTRY for the
purpose of accessing data at that address? This becomes
ambiguous with AMODE(64).)

> Everything will work correctly. Of course, if the program uses BASR
> rather than BASSM, a specification exception will result.
>
> I would say that the correct sequence should be:
>
> LOAD modulename
> STG R0,moduleaddreess
> LG R15,moduleaddress
> BASSM R14,R15
>
> where
> moduleaddress DS FD
> or
> moduleaddress DS AD
>
> Of course, if you don't need to keep the module address around because
> you will only call it once, the STG/LG can be replaced with
> LGR R15,R0

-- gil

[Peter Relson]

My bad.

Obviously Tom M is correct.

Only if you were then to use "BASR" (or "BALR") would there be a problem
of PIC 6 if LLGF were used.

[Steve Smith]

Well, this is the best and most accurate advice. However, the comments
on the LLGTR are misleading. It is there to clear the high-order 33
bits, but only the high 32 are in question. LARL, like all LA*
instructions clears bit 32 when in AMODE 31.

If this code was running AMODE 64 (and it's not magic, difficult, or
dangerous), then the LLGTR would be entirely superfluous.

sas

[Binyamin Dissen]

On Tue, 11 Aug 2015 10:02:58 -0600 Paul Gilmartin
<00000014e0e4a59...@LISTSERV.UGA.EDU> wrote:

:>(Might one declare a data-only module as RMODE(64) AMODE(24) so

:>it may be loaded above the bar, but so LOAD returns an unbiased
:>address?)

AMODE refers to how the supervisor will pass control to the module. The binder
will not allow a attributes that are illogical such as entered in AMODE24
while residing above the bar.

:>(Might the programmer declare an odd address as an ENTRY for the

:>purpose of accessing data at that address? This becomes
:>ambiguous with AMODE(64).)

That is an interesting question. I wonder how IBM handled the case.

--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

[Paul Gilmartin]

On 2015-08-18, at 03:25, Binyamin Dissen wrote:

> On Tue, 11 Aug 2015 10:02:58 -0600 Paul Gilmartin
> <00000014e0e4a59...@LISTSERV.UGA.EDU> wrote:
>
> :>(Might one declare a data-only module as RMODE(64) AMODE(24) so
> :>it may be loaded above the bar, but so LOAD returns an unbiased
> :>address?)
>
> AMODE refers to how the supervisor will pass control to the module. The binder
> will not allow a attributes that are illogical such as entered in AMODE24
> while residing above the bar.
>

It's not illogical if the module is pure data and the programmer uses AMODE24
(or AMODE31) solely to prevent setting of bit 63 by LOAD. Might be worth
RC=4 from Binder.

> :>(Might the programmer declare an odd address as an ENTRY for the
> :>purpose of accessing data at that address? This becomes
> :>ambiguous with AMODE(64).)
>
> That is an interesting question. I wonder how IBM handled the case.

-- gil

[ess...@juno.com]

Im in the process of issuing two commands from the same program.
I have a 31 Bit AMODE program that will LINK to the AMODE64 Bit module and then upon return I will LOAD the AMODE64 Bit Module and BSSM to it.
Ill post the results later this week.

Paul

---------- Original Message ----------
From: Paul Gilmartin <00000014e0e4a59...@LISTSERV.UGA.EDU>
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: LOADING An AMODE64 Program

[Peter Relson]

>I have a 31 Bit AMODE program that will LINK to the AMODE64 Bit module

This will be rejected unless you use LINKX with AMODE64OK=YES.

Might the programmer declare an odd address as an ENTRY for the
purpose of accessing data at that address?

This becomes smbiguous with AMODE(64).

That is an interesting question. I wonder how IBM handled the case.

Yes they might. We chose not to "handle" it. In a word (well, 3 words),
"don't do that".

[Steve Smith]

Speaking of RMODE 64, I see that HLASM supports it, but the Binder doesn't
on z/OS. So it's unclear if LOAD supports RMODE 64 yet. Assuming support
is added someday, I presume LINK will not.

However, assuming the Binder is consistent and requires AMODE 64 on an
RMODE 64 module, LOAD will always return an odd address, although you can't
directly use it for anything! (Based on the assumption that above-the-bar
execution is still not supported).

sas

--
sas

[Chuck Arney]

It is not unclear that LOAD does support RMODE64, but only in a limited sense. You can do directed LOADs into above the bar storage using one of two special 64-bit parameters. But of course that precludes the creation of CDEs for the modules so you have to manage them yourself. IBM does not "support" execution above the bar because support is not available across the board in z/OS facilities and services. The most important probably is ABEND reporting and handling.

You can read more about writing RMODE64 programs in my blog at http://zosdebug.com/blog

Chuck Arney
Arney Computer Systems
Web: http://zosdebug.com
Facebook: http://www.facebook.com/arneycomputer

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Steve Smith
Sent: Wednesday, August 19, 2015 9:43 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: LOADING An AMODE64 Program

[Paul Gilmartin]

On 2015-08-19, at 08:42, Steve Smith wrote:

> Speaking of RMODE 64, I see that HLASM supports it, but the Binder doesn't
> on z/OS. So it's unclear if LOAD supports RMODE 64 yet. Assuming support
> is added someday, I presume LINK will not.
>

Does this mean that one can't create a data module to be loaded above-the-bar?
One must obtain STORAGE and copy into it? Can one IDENTIFY an address above-
the-bar?

> However, assuming the Binder is consistent and requires AMODE 64 on an
> RMODE 64 module, LOAD will always return an odd address, although you can't
> directly use it for anything! (Based on the assumption that above-the-bar
> execution is still not supported).
>

That matter seems moot if the Binder (or anything else) can't create
an RMODE 64 object. If it did, it could still be used for data.

A while back I heard in these fora that one could branch to code above-
the-bar provided interrupts were disabled; interrupts above-the-bar
were lethal. More recently that interrupts are supported, but no
(few?) system services can be invoked from above-the-bar.

> On Wed, Aug 19, 2015 at 7:47 AM, Peter Relson <rel...@us.ibm.com> wrote:
>>
>> Might the programmer declare an odd address as an ENTRY for the
>> purpose of accessing data at that address?
>> This becomes smbiguous with AMODE(64).
>> That is an interesting question. I wonder how IBM handled the case.
>>
>> Yes they might. We chose not to "handle" it. In a word (well, 3 words),
>> "don't do that".
>>

Again, for data, what about RMODE(64) AMODE(24) to avoid overlaying
bit 32 (as by AMODE 31) or bit 63 (as by AMODE 64)?

The corresponding problem doesn't occur for RMODE(31) because bit 0
of a fullword address is not used for addressing (except to select
addressing mode in some branch instuctions.)

-- gil

[Chuck Arney]

A data-only module has the same restrictions as a code module. You can put
it above the bar with either move or directed load. However, you must
manage the module/storage yourself. Since there is no CDE any other code
that uses the module will have to be provided it's address because the
address cannot be obtained by issuing a LOAD for it. No IDENTIFY support.

The interrupts disabled thing was true prior to z/OS 1.13. In 1.13 and
above the interrupt handlers/dispatcher save the state properly so this is
no longer true.

A discussion of AMODE for a data-only module has no value.

Chuck Arney
Arney Computer Systems
Web: http://zosdebug.com
Facebook: http://www.facebook.com/arneycomputer


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Wednesday, August 19, 2015 11:30 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: LOADING An AMODE64 Program

[Peter Relson]

>So it's unclear if LOAD supports RMODE 64 yet.

As Chuck Arney responded, only to the extent that you can provide
an area above 2G (LOAD with ADDR64).

>Assuming support
>is added someday, I presume LINK will not.

Well, I'd expect that LINK will not but LINKX would.

>IBM does not "support" execution above the bar

As of z/OS 1.13, z/OS supports execution above the bar as long as you
don't call anything outside of your own application.
That might be a very limited set of cases, but it is what it is.

>Does this mean that one can't create a data module to be loaded
above-the-bar?
>One must obtain STORAGE and copy into it? Can one IDENTIFY an address
above-
>the-bar?

No to all three.
You can create a data module to be loaded above the bar. You can use LOAD
with ADDR64 to get the system to load into the area that you provide.

>LOAD will always return an odd address, although you can't
> directly use it for anything! (Based on the assumption that
above-the-bar
> execution is still not supported).

The assumption is incorrect.

>Again, for data, what about RMODE(64) AMODE(24) to avoid overlaying bit
32
>(as by AMODE 31) or bit 63 (as by AMODE 64)?

Nobody would implement an option that was clearly supporting incorrect
information whose sole intent is to avoid some processing you don't think
you want.
Now if you had mentioned some new option asking for a non-AMODE-identified
return value that could be different.

If you don't need bit 63 because you're not doing a BASSM then clear it
(whether because it's data or because you're doing a BASR or whatever).
And simply put: don't place AMODE 64 data that is to be externally located
on an odd address unless you know that it will be on an odd address (so
that the user would know to avoid clearing bit 63).

[John McKown]

On Thu, Aug 20, 2015 at 6:39 AM, Peter Relson <rel...@us.ibm.com> wrote:

> >So it's unclear if LOAD supports RMODE 64 yet.
>
> As Chuck Arney responded, only to the extent that you can provide
> an area above 2G (LOAD with ADDR64).
>

What happens if someone, mistakenly, loads a module with 4 byte ADCONs into
above the bar storage? Yes, this is an error. I don't see anything in the
documentation about this.

[Binyamin Dissen]

On Thu, 20 Aug 2015 08:14:36 -0500 John McKown <john.arch...@GMAIL.COM>
wrote:

:>On Thu, Aug 20, 2015 at 6:39 AM, Peter Relson <rel...@us.ibm.com> wrote:

:>> >So it's unclear if LOAD supports RMODE 64 yet.

:>> As Chuck Arney responded, only to the extent that you can provide
:>> an area above 2G (LOAD with ADDR64).

:>What happens if someone, mistakenly, loads a module with 4 byte ADCONs into
:>above the bar storage? Yes, this is an error. I don't see anything in the
:>documentation about this.

Probably the same thing that happens when a module with 3 byte adcons is
loaded above the line.

[Robert Ngan]

I'd suggest using LOADPT= to get an address not contaminated with
addressing mode bits, but this doesn't support returning 64-bit values yet.

Robert Ngan
CSC Financial Services Group

IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
2015/08/19 11:29:31:

> From: Paul Gilmartin <00000014e0e4a59...@LISTSERV.UGA.EDU>
> To: ASSEMBL...@LISTSERV.UGA.EDU

> Date: 2015/08/19 11:31
> Subject: Re: LOADING An AMODE64 Program

> Sent by: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU>
>

[Chuck Arney]

> What happens if someone, mistakenly, loads a module with 4 byte ADCONs into above the bar
> storage? Yes, this is an error. I don't see anything in the documentation about this.

The ADCONs simply do not get relocated. There is no system abend or anything so it's up to your program what it will do with them.

[Paul Gilmartin]

On 2015-08-20, at 05:39, Peter Relson wrote:
>
>> Does this mean that one can't create a data module to be loaded
> above-the-bar?
>> One must obtain STORAGE and copy into it? Can one IDENTIFY an address
> above-
>> the-bar?
>
> No to all three.
> You can create a data module to be loaded above the bar. You can use LOAD
> with ADDR64 to get the system to load into the area that you provide.
>

A disappointing restriction. I hope full Content Supervision support
extends above the bar someday. (Is it constrained by existing Data
Areas definitions?)

> Nobody would implement an option that was clearly supporting incorrect
> information whose sole intent is to avoid some processing you don't think
> you want.
>

Technically, one might argue that any AMODE value is "incorrect" for a
pure data object. The programmer ought to be allowed to choose the
most useful value.

> Now if you had mentioned some new option asking for a non-AMODE-identified
> return value that could be different.
>

Such an option might be useful if a given ENTRY point could be used
alike for branch and non-branch operations

> If you don't need bit 63 because you're not doing a BASSM then clear it
> (whether because it's data or because you're doing a BASR or whatever).
> And simply put: don't place AMODE 64 data that is to be externally located
> on an odd address unless you know that it will be on an odd address (so
> that the user would know to avoid clearing bit 63).
>

"know" requires the programmer to make undesired assumptions about the
address of an object.

How are bit 32 and bit 63 handled in 64-bit V-CONs? (Do 64-bit V-CONs
exist?)

-- gil

[Peter Relson]

>What happens if someone, mistakenly, loads a module with 4 byte ADCONs
into
>above the bar storage? Yes, this is an error. I don't see anything in the
>documentation about this.

We don't often document what the behavior is when you make a mistake. When
you make a mistake and something bad happens (such as an abend) you look
up the "something bad" and one hopes that

With LOAD with ADDR64, the error is yours to deal with. That LOAD approach
does not care what the RMODE of the module is, it expects you to get it
right. This is also the case with LOAD with ADDR and an RMODE 24 module
that is to be loaded above 16M.

I believe that the binder will complain about a 4-byte adcon in an RMODE
64 module. I don't know if it complains about a 3-byte adcon in an RMODE
31 module.

>The programmer ought to be allowed to choose the
>most useful value.

You know that I disagree. What you really want is a way to indicate that
the AMODE is irrelevant and thus you would need a way to identify that the
thing being loaded is data, not code. The system would not attempt to
guess. The system does not currently keep the un-AMODEd entry point
address.

>(Do 64-bit V-CONs exist?)

I don't think so, but 64-bit AD-cons with EXTRN do.

>I'd suggest using LOADPT= to get an address not contaminated with
>addressing mode bits,

LOADPT does not necessarily equal entry point. So your use of that depends
on what you need.

[Mar...@pi-sysprog.de]

>> (Do 64-bit V-CONs exist?)

Copied from IBM-Main (John Ehrmann)

try a VD-type adcon. (See the HLASM Language Reference.)

--
Martin

Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de

[ess...@juno.com]

Im posting he results of my sampe program for loading a 64BIT Amode program and invoking it via BSSM.
.
The Driving program is AMODE31 RMODE ANY
The program that is loaded was Linked Edit as AMODE 64 and RMODE ANY.
.
I wanted to accomplish two methods of invoking the same 64BIT AMODE program. The function of 64BIT AMODE Program (PROG64) is simplistic;(1) established the save areas, (2) acquire a Memory Segment, (3) DETACHE the memory Segment, and (4)restores the callers environment and return.
.
.
The Driver Routine issues a LINK to PROG64
And Upond Return LOADs PROG64 and then BASSM to it.
.
.
I had to use a LINKX macro as LINK incurred an ABEND of 0C6.
Then the BASSM failed because PROG64 returned witha BR14.
I then modified the PROG64 program to issue a BSM 0,14 as the return instruction.
This succeded for both LINKX and LOAD/BASSM, I am still fine tuning this logic.
.
.
The Driveing routine is posted below:

GOCHECK CNOP 2,4 ALIGNMENT BAKR R14,0 SAVE CALLERS ENVIRONMENT
LARL R12,DRIV64A ESTABLISH BASE REGISTER
LARL R13,SAVE64 REGISTER SAVE Area
* *
WTO '&CSECT - LINK Routine'
SYSSTATE ASCENV=P,AMODE64=YES,ARCHLVL=2
LARL R2,PROG64$
LINKX EPLOC=(R2),AMODE64OK=YES ISSUE LINKX
SYSSTATE AMODE64=NO
*
WTO '&CSECT - LOAD Routine'
LARL R2,PROG64$
LOAD EPLOC=(R2) ISSUE LOAD
STM R15,R1,LOADREGS REGS AFTER LOAD
STG R0,MOD@ 64Bit Module
LGR R15,R0 64Bit Address
BASSM R14,R15 Invoke 64Bit Module
*
WTO '&CSECT - Return'
*
DS 0D
DC CL8'SAVEAREA'
SAVE64 DS 34A
DS 0D
DC CL8'LOADREGS'
LOADREGS DC 4A(0) REGISTERS AFTER LOAD
DS 0AD
MOD@ DC AD(0)
SAVEG15 DC AD(0)
DC AD(0)
DC AD(0)
DC AD(0)
*
*****************************************************************

Paul D'Angelo
*************

[Scott Ford]

There was a TriModal handout from Share that showed how to call and switch
address modes, it was excellent . It was by IBMer John Ehrman ....that says
it all to me.


Scott

[David Staudacher]

> "There was a TriModal handout from Share that showed

> how to call and switch address modes... "

Must be this one from SHARE 118 in Atlanta (March 2012): "A Tutorial on Trimodal Programming on z/OS"
http://share.confex.com/share/118/webprogram/Handout/Session10409/Trimodal%20Handout.pdf