On Mon, 29 Aug 2016 07:51:19 -0700, Charles Mills <charl...@mcn.org> wrote:
>Hmmm. To me, that strategy seems appropriate for a report program ("this
>field is not relevant to this type of transaction so print blanks or
>asterisks") but not for a dump program. Isn't a dump -- consider the name --
>supposed to be "here it all is, as it all is, you figure out what is
>relevant"?
In XPLINK, a program does not necessarily save all of the registers, so the
contents of the location in the save area that is designated for that register
doesn't necessarily have any meaning. In any case, registers 0-3 are not saved,
so it would have no meaning to display contents for those registers in the
XPLINK (downstack) save area.
Indeed, if a given XPLINK program were to save only registers 6-10, the
contents
of registers 4, 5, and 11-15 are meaningless. The unused parts of the save
areas
are not zeroed, and the residual data does not have any value. In particular,
you
cannot assume that the doubleword that is allocated for R11 contained an R11
value from a previous call because of the way the stack frames are allocated.
The reference for this information is the LE Vendor Interfaces manual.
Yes, it is XPLINK-64. The only linkage that LE supports in AMODE 64 is
XPLINK-64.
And XPLINK is not anything like standard linkage. It is possible for an
XPLINK-64
program to call a non-XPLINK program that is not LE enabled, but AFAIK it can
only call an AMODE 64 non-XPLINK program because the save area that is passed
is a 144-byte save area within the XPLINK stack, and is above the bar. An
assembler program would typically use F4SA format to save its caller's
registers.
For XPLINK-64 to call XPLINK may be possible, but it would require that a new
enclave be established. Here I am at (or beyond) the limits of my knowledge.
XPLINK and XPLINK-64 are not compatible. Part of the reason is that the
Common Anchor Area (CAA) is a different format and the mappings for the two
formats are not compatible. Just as one example, in in a 24/31-bit CAA the
field
CEECAAPCB is a 4-byte field at offset X'2F4'. In an XPLINK-64 CAA, CEECAAPCB
is at offset X'390'. At offset X'390' in a 24/31-bit CAA is CEECAASIGNGPTR.
One
would have thought that they would have at least used different names, and
locations that are unused in the older CAA. They didn't.
And so, when Cobol and PL/I support AMODE 64, it will be only XPLINK-64, and
you will only be able to use it if you don't need to mix AMODE 64 and AMODE 31
Cobol and/or PL/I programs.
And, by the way, the main reason for XPLINK is to save a few instructions on
program linkage. But making a call to a non-XPLINK program requires rather more
instructions than just using standard linkage. And one of the things that Cobol
and PL/I programs typically do a lot of is I/O. Those I/O calls are standard
linkage
calls to, for example, GET and PUT. So the benefits of XPLINK evaporate.
</soapbox>
--
Tom Marchant
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
