Michael Schmitt wrote:
Also the linkage stack is not supported by Language Environment, so you
should not be using it in any code that can be called in an LE run-unit.
The doc is likely "imprecise". It is surely untrue in general. z/OS does
not need any "support" by LE in order for an
Assembler List On Behalf
Of Farley, Peter x23353
Sent: Thursday, January 20, 2022 11:30 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Regsiters (was: Unsigned Binary Formats)
Note in that manual on page 34 of that PDF (page 6 in the book) it says:
When a program
2022 2:37 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Regsiters
On 2022-01-28 15:08 PM, Schmitt, Michael wrote:
> Also the linkage stack is not supported by Language Environment, so you
> should not be using it in any code that can be called in an LE run-unit.
I
-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Regsiters
Dave, if speed is an issue (i.e., your small routine is called many, many
times), BAKR is **SLOW** even on very recent hardware. It is convenient, but
normal save/restore processes beat the pants off BAKR if execution time
ist [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Tom Marchant [00a69b48f3bb-dmarc-requ...@listserv.uga.edu]
Sent: Tuesday, January 25, 2022 10:48 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Regsiters
The second word of a save area does not tell you about the s
Sorry, the forward pointer is at +X'88'. +'80' is the back chain.
--
Tom Marchant
On Tue, 25 Jan 2022 10:48:55 -0500, Tom Marchant
wrote:
>If it is a 144-byte (or larger) save area, there are two possible forward
>pointers. One at +8 and the other at +X'80'. Both can be valid.
If you don't know that your caller provided a 144-byte save area, you have to
assume that they only provided 72 bytes. That's what F5SA is for. The low
halves are stored as they are in a standard save area, and you can save the
forward pointer at offset 8. You store the high halves in your
tserv.uga.edu]
>Sent: Monday, January 24, 2022 2:01 PM
>To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>Subject: Re: Saving Caller's 64-bit Regsiters
>
>Replying to my own post to elaborate a little.
>
>When a program allocates a save area to pass to its callers, there is only
>one wo
.
A fullword in GETMAIN storage is good. AR 0 is good.
QED
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Dave Clark
Sent: Monday, January 24, 2022 11:15 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64
: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Tom Marchant [00a69b48f3bb-dmarc-requ...@listserv.uga.edu]
Sent: Monday, January 24, 2022 2:01 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Regsiters
Replying to my own post to elaborate
Re: Saving Caller's 64-bit Regsiters
For both VSE and zOS, there is REXX documentation (VSE'sis at
https://urldefense.com/v3/__https://www.ibm.com/docs/en/zvse/6.2?topic=packages-interface-writing-external-function-subroutine-code__;!!Ebr-cpPeAnfNniQ8HSAI
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Gary Weinhold [weinh...@dkl.com]
Sent: Monday, January 24, 2022 3:37 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Regsiters
For both VSE and zOS
For both VSE and zOS, there is REXX documentation (VSE'sis at
https://www.ibm.com/docs/en/zvse/6.2?topic=packages-interface-writing-external-function-subroutine-code
that states that on entry to the called routine Register 13 contains the
address of a register save area. What it doesn't say is
"IBM Mainframe Assembler List" wrote on
01/24/2022 02:01:29 PM:
> When I'm following save area chains in a dump, starting with R13, I look
> at the second word. If it is an address, I know that the save area at
that
> address is a standard 72-byte save area. If it is F4SA, F5SA, F7SA, or
Replying to my own post to elaborate a little.
When a program allocates a save area to pass to its callers, there is only
one word, the second word, that it can use in the new save area.
Everything else is reserved for the called program. The oldest documentation
for the standard 72-byte save
When you say that it "makes no sense", I think you mean that you don't
understand it.
The second word of a save area cannot be set by the caller. Or, rather,
if it is, it will be destroyed by the called program.
How does a program know how a caller will use the save area that is
passed to
If your program can be called by a program that you don't control, and that
doesn't document that it provides something more, you have to assume
that you re only provided a 72-byte save area.
There is no code that a program can provide in the first word of a save area
that could describe the
Tony Thigpen wrote "stuff".
The opinions in that post do not reflect the requirements of an interface
provider.
It is irrelevant what your routine is called from. The caller is
responsible for meeting the interface, whether that be save area or
parameter list or other data or environment. And
Mainframe Assembler List On Behalf
Of Tony Thigpen
Sent: Friday, January 21, 2022 6:20 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Regsiters
Dave,
I found the BAKR/PR limitation I was thinking about:
From the VSE Systems Macro Ref, under STXIT:
"The STXIT
Dave,
I found the BAKR/PR limitation I was thinking about:
From the VSE Systems Macro Ref, under STXIT:
"The STXIT macro is only allowed when the linkage stack is empty. If a
STXIT macro is issued in a module called with a PC or BAKR instruction
(that is, the linkage stack is not empty), the
The definitive source is:
Supervisor Diagnosis Reference z/VSE (for your release)
Chapter 2: Design Information
Section: z/Architecture Linkage Stack
The z/VSE 6.1 manual has a better PDF index and the language for this
section has not changed since 4.1.
Off the top of my head, I remember
"IBM Mainframe Assembler List" wrote on
01/21/2022 11:46:44 AM:
> AND the other warning:
>
> No support for the linkage stack in an abend situation for the dumping
> process, if you are in a vanilla VSE system. It is flushed and empty for
> the next, but not shown in dumps
I take
Am 21.01.22 um 17:50 schrieb Dave Clark:
OK, so what you're saying is that I should do the standard updates
to the caller
I never said anything about what you should do.
Martin
anuary 21, 2022 6:32 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Regsiters
"IBM Mainframe Assembler List" wrote on
01/21/2022 09:16:30 AM:
> Dave Clark wrote
>
> is there
> some other means of knowing whether or not to save the high halves in
"IBM Mainframe Assembler List" wrote on
01/21/2022 12:02:06 PM:
> Once upon a time there were only 32-bit registers and 72-byte save
areas.
> Some documentation was written during that time. It would have made no
sense
> for it to say "we provide a 72-byte save area" because the obvious
WY overkill IMHO.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Dave Clark
Sent: Friday, January 21, 2022 8:50 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Regsiters
"IBM Main
:32 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Regsiters
"IBM Mainframe Assembler List" wrote on
01/21/2022 09:16:30 AM:
> Dave Clark wrote
>
> is there
> some other means of knowing whether or not to save the high halves in
the
> call
"IBM Mainframe Assembler List" wrote on
01/21/2022 11:46:44 AM:
> AND the other warning:
>
> No support for the linkage stack in an abend situation for the dumping
> process, if you are in a vanilla VSE system. It is flushed and empty for
> the next, but not shown in dumps
OK, so
>> ... can the BAKR instruction be used in z/VSE? <<
I am not Tony, but I guess my answer is as good.
Yes BAKR can be used in VSE - but not in CICS (or only in very very rare
circumstances- AND to be very exact- not in any task switching
environment (I know that I convinced one very good
"IBM Mainframe Assembler List" wrote on
01/21/2022 09:55:32 AM:
> It's worse than you think. There is a save area format tag literal for
> the save area, but it's not set by the caller. It is set by the callee
> saying how he used the previous save area in the chain. Which makes no
> sense.
"IBM Mainframe Assembler List" wrote on
01/21/2022 09:55:32 AM:
> It's worse than you think. There is a save area format tag literal for
> the save area, but it's not set by the caller. It is set by the callee
> saying how he used the previous save area in the chain. Which makes no
> sense.
2022 9:53 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Regsiters
Peter,
The whole "It's your interface" line is a crock of bull s**t. That may
be true from the operating system's viewpoint, but not from the language
system's viewpoint.
We write stuff th
Dave,
It's worse than you think. There is a save area format tag literal for
the save area, but it's not set by the caller. It is set by the callee
saying how he used the previous save area in the chain. Which makes no
sense.
Tony Thigpen
Dave Clark wrote on 1/21/22 9:32 AM:
"IBM
Peter,
The whole "It's your interface" line is a crock of bull s**t. That may
be true from the operating system's viewpoint, but not from the language
system's viewpoint.
We write stuff that can be called by:
1) the O/S
2) IBM provided language programs (such as Cobol)
3) our own programs.
-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Regsiters
"IBM Mainframe Assembler List" wrote on
01/21/2022 09:16:30 AM:
> Dave Clark wrote
>
> is there
> some other means of knowing whether or not to save the high halves in
the
> caller's save area?
>
&g
"IBM Mainframe Assembler List" wrote on
01/21/2022 09:16:30 AM:
> Dave Clark wrote
>
> is there
> some other means of knowing whether or not to save the high halves in
the
> caller's save area?
>
>
> This has been covered many times. It's your interface. If you documented
> that they
Dave Clark wrote
is there
some other means of knowing whether or not to save the high halves in the
caller's save area?
This has been covered many times. It's your interface. If you documented
that they should provide a save area suitable for saving high halves in
that area then you assume
Mainframe Assembler List On Behalf
Of Seymour J Metz
Sent: Thursday, January 20, 2022 12:18 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Regsiters (was: Unsigned Binary Formats)
Sorry; that should have been #page=33. On most browser that fragment will take
you
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Kerry Liles [kerry.li...@gmail.com]
Sent: Thursday, January 20, 2022 11:45 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Regsiters (was: Unsigned Binary Formats)
Just FYI, that link
"IBM Mainframe Assembler List" wrote on
01/20/2022 11:45:55 AM:
> Just FYI, that link to
>
> MVS Programming: Assembler Services Guide, SA23-1368-50, <
> https://urldefense.com/v3/__https://www.ibm.com/servers/
> resourcelink/svc00100.nsf/pages/zOSV2R5sa231368/$file/
>
Dave Clark [dlcl...@winsupplyinc.com]
> Sent: Wednesday, January 19, 2022 5:20 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Saving Caller's 64-bit Regsiters (was: Unsigned Binary Formats)
>
> "IBM Mainframe Assembler List" wrote on
> 01/19/2022 05:12:36
"IBM Mainframe Assembler List" wrote on
01/19/2022 06:05:12 PM:
> At program entry:
>
> STMH 2,14,your-high-halves-save-area 13 fullwords for 2-14 high halves
>
> At program exit:
>
> LMH 2,14, your-high-halves-save-area
Thanks. I take it that I shouldn't presume the caller has
R-LIST@LISTSERV.UGA.EDU
Subject: Saving Caller's 64-bit Regsiters (was: Unsigned Binary Formats)
"IBM Mainframe Assembler List" wrote on
01/19/2022 05:12:36 PM:
> Is register 2 considered volatile for the 64 bit high half?
>
> If not, then how do you know if the macro user wi
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Saving Caller's 64-bit Regsiters (was: Unsigned Binary Formats)
"IBM Mainframe Assembler List" wrote on
01/19/2022 05:12:36 PM:
> Is register 2 considered volatile for the 64 bit high half?
>
> If not, then how do you know if the macro
-LIST@LISTSERV.UGA.EDU]
On Behalf Of Dave Clark
Sent: Wednesday, January 19, 2022 2:21 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Saving Caller's 64-bit Regsiters (was: Unsigned Binary Formats)
"IBM Mainframe Assembler List" wrote on
01/19/2022 05:12:36 PM:
> Is register
.
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Dave Clark
Sent: Wednesday, January 19, 2022 4:21 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Saving Caller's 64-bit Regsiters (was: Unsigned Binary Formats)
"IBM Mainframe Assembler List" wrote on
01/19/2022 0
"IBM Mainframe Assembler List" wrote on
01/19/2022 05:12:36 PM:
> Is register 2 considered volatile for the 64 bit high half?
>
> If not, then how do you know if the macro user will preserve and
> restore the register?
There is no macro, but I think I get your point. Although
47 matches
Mail list logo
