Wouldn't it be easier to make a global statement about R14 being altered
rather than that the top half (alone) is preserved when AMODE=24/31?
It would be easier, but it would be dangerous.
The case that is being protected against is this
- a program is using the high half of reg 14 for
(Binyamin posted this on IBM-Main in response to my incorrectly-targeted
post. It seemed more appropriate to respond here)
Pretty much any macro that generates a PC that is 64 sensitive will use
LLGT
R14 somewhere in the path which will wipe the top half.
That is somewhat incorrect. They
Subject: Re: Subroutines, save areas and 64bit
Not intending to hijack but there was an assertion about z/OS and services
known not to save/restore registers...
Was there a thread here or on IBM-MAIN that discussed R2-R13 being 'corrupted'
following storage/getmain/freemain calls? I don't recall
Steve Comstock wrote:
On 1/17/2011 2:44 PM, Don Poitras wrote:
AMODE 64 in VSE? I didn't think that was supported yet. If you're
talking about z/OS, then you need to worry about more than save areas.
You'd most likely be called from LE in which case you would be called
from an XPLINK
Chris,
I saw read flags as wellI did google - all I found with substance
(on IBM-MAIN) was the fact that R1 is now set to an address valid in
any mode (regardless of callers mode). IOW high order word is is cleared
even if invoking pgm is unaware of that word.
I would hardly call this a
In XPLINK, R1 is just the first function parameter. It can be an
address (above the bar or below) or some number or garbage.
Martin =?UTF-8?B?VHLDvGJuZXI=?= wrote:
Chris,
I saw read flags as wellI did google - all I found with substance
(on IBM-MAIN) was the fact that R1 is now set to
On 1/18/2011 7:30 AM, Tom Marchant wrote:
This is a good reference, but if you are going to use it, please
use the one from z/OS 1.12. It was extensively modified for
release 1.12 to clarify the meaning and if you use older versions
of the manual, you could misunderstand it. Ed posted a link
I am looking for any pointers from those that been down this road before.
Tony Thigpen
Take a look at the z/OS MVS Assembler Services Guide, Chapter 2: it has a
lot of information about the kinds of areas you're exploring.
On 1/17/2011 3:12 PM, Tony Thigpen wrote:
It looks like we have to not only handle AMODE 64, but also multiple
save area formats, AMODE 24, 31, and 64.
I am looking for any pointers from those that been down this road before.
Under zOS, I handle that by using BAKR to save everything, which
BAKR/PR is available in z/VSE, but has the restriction that it can't be
used in an OCEXIT is in place. Since I am a low-level program, I can't
take the chance and use BAKR/PR.
Also, I failed to mention that my routines work for both batch and under
CICS.
Tony Thigpen
-Original Message
BAKR/PR need operating support, and I don't know
whether that's available in VSE.
BAKR can be used - The op-sys does prepare a linkage-stack in
CR15.
It is crippled, if you compare it to the functionality that comes in
z/OS- but you get 96 levels and you get 24 for recovery in a
Tony,
...OCEXIT
you are preparing stuff from a vendor point - right?
Why do you not use the stuff ported from z/OS to VSE to support CICS/TS
and some other subsystem?
I am 100% sure that ESTAE and ESPIE can be used- they might even be
available without OS390 on the EXEC-card.
--
Martin
On 1/17/2011 2:44 PM, Don Poitras wrote:
AMODE 64 in VSE? I didn't think that was supported yet. If you're
talking about z/OS, then you need to worry about more than save areas.
You'd most likely be called from LE in which case you would be called
from an XPLINK program.
Wait! LE does not
13 matches
Mail list logo
