[hercules-os380] MVS/380 fundamentals

[[e-mail] [hercules-os380]]

I have now consolidated my hopes for MVS/380
at the moment, and Peppe, I need a guinea pig.
PDPCLIB has moved into a position that I am
not happy with, and I'd like to work with you to
bed in a paradigm that I am happy with. And
the best thing for that would be to work with
that assembler program you were writing to
read an IEBCOPY unload file that had been
FTPed so you need to reconstruct the records.

Basically what I would like is for you to pretend
that BTL memory is tight so you are trying to
allocate 130 KB of memory in AT2B (RM32)
space to alleviate pressure on the RM31
space. The 130 KB is for two complete tape
records in case a V record spans two
blocks, and tape blocks are potentially 64 KB
in size.

I know you can use a simpler algorithm, but if
you use this slightly more complex algorithm,
it gives an actual program where we can
demonstrate how to write assembler programs
properly. Also the act of doing this means that
my writing needs to make enough sense that
a Unix programmer can understand it.

I can provide the code that does the AM32
handling if you can test it out. If it's all too
much work, that's fine, just forget it. And
non-Peppe people are free to comment on
the below proposals too.

Thanks. Paul.


Proposed future MVS/380 design and guidelines for
programming in all of MVS/380, MVS 3.8j, MVS/XA,
OS/390 and z/OS - 24-bit, 31-bit, 32-bit and 64-bit.


On the mainframe, just like modern (2018) Windows
and Unix, both 32-bit and 64-bit registers are
available for use, both for data registers and
address registers. The mainframe has traditionally
had an additional complication of address masking
which can restrict the amount of memory to 24 bits
or 31 bits. Unfortunately much code has been
written that makes an assumption that this masking
will occur, and the programs happily run with crud
in the top 8 or top 1 bit of 32-bit address
registers. In addition to that, some 32-bit programs
have assumed address truncation at 32 bits (by
using x'FFFFFFFF' as negative 1 in an address index),
so fail if an attempt is made to run them in AM64.
Those programs require an implied AM32.

But so long as programs are coded in accordance with
this document, there is nothing architecturally
preventing normal 32-bit programming or normal
64-bit programming, or even a combination of the two.
E.g. you could have 32-bit code pointers, 64-bit
data pointers, and 32-bit longs. It is totally up
to your C compiler and the options it provides and
you enable, or however you choose to write your
assembler code.

This document explains how to write your application
code in a flexible manner, but you have no control
over the operating system. Unfortunately much of
both MVS/XA and MVS/380 require execution in AM24,
and z/OS requires execution in AM31. As such, it is
necessary for your application to be able to switch
to the AMODE that the operating system requires,
noting that different operating systems can handle
different AMODEs. Your application should always be
more advanced or equal to the operating system (ie
you know in advance about all existing operating
systems before you write your program), as such,
your application is only ever expected to step *down*
to match the operating system, never *up*.

For a step-down to ever be possible, it requires that
the code that is being executed be located lower in
memory than the application data that is being addressed.
It also requires that any parameters that are given
to the operating system be located in lower memory
than the other application data. As a result of this,
there are distinct AMODEs and RMODEs:

RMODE: 24, 31, 32, 64
AMODE: 24, 31, 32, 64

Any combination of these can exist, provided that
the AMODE is always greater than or equal to the
RMODE.

So the RMODE is what this particular operating system
can handle, while the AMODE is what your application
has been written to allow. If you have written an
application that doesn't use "VL" or anything else that
may interfere with the top bit of a 32-bit application,
you may use AMODE 32. But all existing operating systems
require an AMODE of 24 or 31, so they will never load
your program into RMODE 32 or 64 space. But because
the operating system may allow 24 or 31, your program
will be marked differently depending on where it is
running. The software installer will typically need to
be informed whether the RMODE needs to be dropped from
RM31 to RM24 when installed on an MVS/380 system.
Because MVS/380 generally requires to be executed in
AM24, while z/OS can usually be executed in AM31.

At startup, your application can do a non-destructive
(works on any hardware) test to see what AMODE and
RMODE it has been invoked in, and it can adjust
appropriately.

The specific test for AMODE is to load a register with
x'FFFFFFFF' and then do a LA. If the top 8 bits have
been cleared, it is AM24. If no bits have been cleared,
it is AM32 or 64. If only the top bit is cleared, it
is AM31.

The specific test for RMODE is to load the address of
any routine. If the address is greater than or equal
to x'80000000', it is RM32. Else if the address is
greater than or equal to x'01000000', it is RM31.
Else the load module is RM24.

Testing 64-bit is different. At compile time you know
whether your program is using 32-bit or 64-bit data
pointers, and if you are building an AM64 program
you can just hardcode or assume the AMODE is 64. The
RMODE can be determined by doing the same test as
before, except using 64-bit registers and seeing if
any of the high 32-bits are non-zero, and if so, it
is RM64, not even RM32.

In the situation where the AMODE and RMODE are the
same, it means that the application and operating
system will execute in the same AMODE, so it is
not necessary to (and nor should you) switch AMODEs
prior to calling an operating system routine. By
sticking to this rule, your application will still
work on MVS 3.8j running on standard S/370 hardware,
because no BSM is executed. You are advised to limit
the rest of your application (or compiler) to
instructions that exist on S/370 too, and only use
MVCLE and CLCLE when you know you are dealing with
a buffer of 16 MiB or more in size.

Basically every operating system macro like READ
needs to be bracketed with some sort of macro like
GAMOS (go to the OS's amode) prior to execution,
and GAMAPP (go to the application's amode) after
execution. You also need to ensure that you build
your application on a system like MVS/380 where
the OS macros are 31-bit or 32-bit clean in order
for your application to be marked as something
above RMODE 24.

In some ways z/OS is better than MVS/380 and in
some ways it is the reverse. You are advised
to code for the lowest common denominator, and
MVS/380 is the best place to do that.

Let's first clarify where MVS/380 is superior.
z/OS does not provide any convenient way to
allocate AT4B (above the 4 GiB bar that 32-bit
addressing has as a limit) memory. It has an
IARV64 macro but the details of that are not
open source so it cannot be reproduced. Also
it is a dog to call (complex and space is
allocated as a minimum of 1 MiB). MVS/380 instead
provides LOC=64 as a parameter to conveniently
get RM64 (AT4B) memory.

Also z/OS does not provide a way for 32-bit
programs to obtain AT2B (above the 2 GiB bar
that 31-bit addressing has as a limit) memory.
Not even IARV64 will get around this problem.
The 2 GiB to 4 GiB range of memory is completely
out of bounds, which is something IBM has
copped flak for in the past. MVS/380 instead
provides a LOC=32 parameter to get RM32 (AT2B)
memory.

The RM64 deficiency of z/OS could be overcome
by having a 3rd party intercept for SVC 120
that would issue an IARV64 call. But the RM32
deficiency requires z/OS to be updated.

The good news is that you can code LOC=32, and
it switches on the high bit of the option byte,
while using the LOC=31 flags for the other 7
bits, meaning that you can write and run a
program on MVS/380 that uses the full 4 GiB
address space, and the program will still run
on z/OS, just in degraded mode, only being
able to allocate a maximum of 2 GiB of memory.

The LOC=64 parameter also switches on the top
bit of the option byte, while leaving the
other bits at the default LOC=RES setting,
meaning it will probably obtain BTL (below
the 16 MiB line, aka RM24) memory unless you
have an SVC 120 intercept in place.

z/OS is superior to MVS/380 mainly in the fact
that the OS routines can handle being executed
in AM31, so a module marked RM24 on MVS/380
can probably be marked as RM31 on z/OS, freeing
up the BTL memory that would otherwise be
occupied by your load module. Since load modules
are normally not very big, and the big space
filler is data, not code, this is of marginal
benefit. It does mean that GAMOS will not need
to execute a BSM, but that is also of marginal
benefit. There are other things too, like the
assembler handles a LG Rx,=LD(XXX), but this
is also of marginal benefit because the code
generator simply needs to generate a SLGR Rx,Rx
and L Rx,=L(XXX) to achieve the same thing, ie
load a 64-bit data pointer. And note that if
you are declaring a 64-bit pointer you would
typically have a YYY DS D.

Note that when doing a GETMAIN, if the current
AMODE is 24, then the LOC= will be ignored and
you will get RM24 memory. Ditto if the current
AMODE is 31, then a LOC=32 or LOC=64 GETMAIN
request will only obtain RM31 memory. In addition,
if the current AMODE is 32/64, then all GETMAIN
requests (ie even for LOC=24) will set all 64 bits
of R15 to provide a clean 64-bit programming
environment. On z/OS all 64 bits may be set even
if you are AM24/31. GETMAIN cannot distinguish
between AM32 and AM64 so a LOC=64 request will
obtain AT4B memory even if your 32-bit program
cannot handle it. A LOC=64 request will also
use 64-bit registers for the amount of data
being requested.

Another thing to note is that MVS 3.8j will
ignore the extra flags in the GETMAIN option
byte that it doesn't know about, so the
recommended practice for your programs that
are using 32-bit data pointers is to use
LOC=32 and mark your load modules AM32=64.
Your programs will still work fine on MVS 3.8j.

If you fail to specify a LOC= to your GETMAIN,
it will default to LOC=RES, ie the location of
the memory will depend on whether your module
has been loaded BTL or ATL. In general this is
not a good option, and should be avoided. You
should instead specify an explicit LOC=24 for
any data that any of MVS/380, MVS/XA or z/OS
require to be kept BTL, or an explicit LOC=31
or LOC=32 for any data that can be stored ATL.
This avoids both wasteful use of resources and
abends.

Don't use the MODE=31 option for OPEN as it
doesn't work on MVS/380.

Don't assume that R15 points to the program
entry point. On MVS/380 the bottom bit may
actually be 1.

When you write a 64-bit application in any
form, ie 64-bit longs and/or 64-bit data
pointers, you should establish a F5SA save
area on program entry and from then on use F4SA.

To cater to AM32 programs that rely on address
truncation at 32 bits, the entire 4 GiB to
8 GiB virtual address space is left vacant on
z/380 so that any virtual memory address in this
range is truncated. In addition, MVS/380 GETMAIN
will not return memory located in the last 2
4 KiB pages before 4 GiB nor the first 4 KiB
pages after 8 GiB. Nor will the operating system
use that space for anything else in case a
32-bit program does a STD 4095(1,2) where
registers 1 and 2 are set to x'FFFFFFFF'. Also
note that there may be an implementation where
there is a different PSW bit to distinguish
between AM32 and AM64, but for now they are
the same thing, and there is no flag in the
module to distinguish this anyway. There could
theoretically be a different way of identifying
AM32 programs in the future, such as maintaining
a list of them, but so far this has been deemed
unnecessary, and the main emphasis is that
AM64 programs should be treated as AM-infinity
and not expect truncation in the first place.

Unrelated to application programming, if you
can do a BSM to x'01' and it works, that is
a sign you are running on a minimal S/380
machine or above. You should do a SAM64 to
see if you are running on a z/380 or above.

There is a technical restriction on MVS/380
that ATL (RM31) memory is only cleared between
steps of a batch job, not between TSO commands.
It is expected that mvs380mn will be renamed
to mvs380, written in C (calling assembler
routines), and have a "clearatl" parameter
to clear the ATL memory until someone constructs
a zap to TSO processing. MVS380MN and GETMAIN are
also expected to use DIAGs at some point so that
each address space can get exclusive use of its
own ATL memory. This is called the "separate
memory" proposal. This would only happen when
NUMPART=1.

It is hoped that one day a large stack buffer
will be added to Hercules/380 main() which
will be later used when an EXEC PGM=XXX is
executed, and XXX will actually be an 80386
module operating in EBCDIC which returns
control to Hercules (and then MVS/380), after
manipulating the stack, whenever something like
an OPEN macro needs to be called. This will
allow people using MVS/380 to operate it using
their PC with next to no performance penalty.
It will become another PC operating system.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

On Mon, 12 Mar 2018, ***@yahoo.com.au [hercules-os380] wrote:

> I have now consolidated my hopes for MVS/380
at the moment, and Peppe, I need a guinea pig.
PDPCLIB has moved into a position that I am
not happy with, and I'd like to work with you to
bed in a paradigm that I am happy with. And
the best thing for that would be to work with
that assembler program you were writing to
read an IEBCOPY unload file that had been
FTPed so you need to reconstruct the records.

---

Well, my assembler sources, at this moment,
are just nothing more than exercises of
a student, Paul ;-) I'm just exercising
to write, read and test very simple
pieces of assembler 370 code, beside
trying to read and understand what others
wrote.

I may help to some extent in C language,
but writing low level I/O MVS routines,
at this moment, is definitely not in
my event horizon.

Peppe.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@vitillaro.org> wrote :

> Well, my assembler sources, at this moment,
> are just nothing more than exercises of
> a student, Paul ;-) I'm just exercising
> to write, read and test very simple
> pieces of assembler 370 code, beside
> trying to read and understand what others
> wrote.

But a simple example program is the ideal
place to demonstrate a technique that will
then hopefully be adopted by other
assembler programs, especially PDPCLIB.

> I may help to some extent in C language,
> but writing low level I/O MVS routines,
> at this moment, is definitely not in
> my event horizon.

No, you don't need to write low-level MVS
routines. All you need is a 128 KB (or
even 64 KB if you prefer) work buffer. Can
you conceive of an algorithm that would
make use of that buffer, but *not* pass that
buffer to MVS for either read or write? Or
alternatively, do you allocate any buffers
already that READ and WRITE (or GET
and PUT) never get to see? Or even just
variables, not buffers. Anything that could
conceivably be allocated above 2 GiB.

I can provide the code that does the BSMs
so that your application can switch between
AM24 and AM32. But before we start I want
to explain to you how that works. I've already
written a document that explains it (ie at the
bottom of the previous message). Do you
have time to read it and ask me anything you
don't understand or agree with? Explaining
how it works is half the challenge. This is a
deviance from anything written in any existing
assembler book, or any existing assembler
program, so people are free to call bullshit
on the new technique. We'll see.

Can you show me the current code?

Thanks. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> deviance

deviation or divergence, take your pick :-)

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> variables, not buffers. Anything that could
> conceivably be allocated above 2 GiB.

And actually, even if you can't find a single
variable that can go above 2 GiB, most of
the code required is to simply execute in
AM32. Currently if you mark your module
as AM64 using "PDS" or the new IEWL,
and that AM64 bit is honored with the new
MVS380MN/MVS380FT, your program will
start running in AM32/64 and then crash
on the READ/WRITE/PUT/GET.

It is at that point that the new code is
required (which I will provide), even if you
don't actually do any legitimate LOC=32
GETMAIN. Hell, you can actually code
the LOC=32 GETMAIN and simply not
use that buffer other than checking what
address it returns.

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> your program will start running in AM32/64

Actually, ideally your program will be running
AM64=infinity, not relying on address truncation
at 32-bits. Basically the same as you would
expect programs running on Unix/Windows
to do. But the GETMAIN would still be LOC=32,
because that is all that you can really address.
32-bit programs running on Unix simply
imply LOC=32 when obtaining memory.

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> bottom of the previous message). Do you
> have time to read it and ask me anything you
> don't understand or agree with? Explaining
> how it works is half the challenge.

Also note that I need to see whether you
believe my aspect on things if others choose
to debate with me on how things should
ideally work.

> This is a deviance

Turns out that this is a valid word after all.
Apologies for the noise on that!

BTW, do you like the idea of your programs
operating in AM64/infinity instead of AM24?

BTW, I wonder if AMD 64 allows people
to address memory above 4 GiB when
running 32-bit applications, e.g. applications
that set an address of x'FFFFFFFF' and then
doing a "mov" or whatever.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

On Mon, 12 Mar 2018, ***@yahoo.com.au [hercules-os380] wrote:

> ---In hercules-***@yahoogroups.com, <***@vitillaro.org> wrote :

> Well, my assembler sources, at this moment,
> are just nothing more than exercises of
> a student, Paul ;-) I'm just exercising
> to write, read and test very simple
> pieces of assembler 370 code, beside
> trying to read and understand what others
> wrote.

But a simple example program is the ideal
place to demonstrate a technique that will
then hopefully be adopted by other
assembler programs, especially PDPCLIB.

> I may help to some extent in C language,
> but writing low level I/O MVS routines,
> at this moment, is definitely not in
> my event horizon.

No, you don't need to write low-level MVS
routines. All you need is a 128 KB (or
even 64 KB if you prefer) work buffer. Can
you conceive of an algorithm that would
make use of that buffer, but *not* pass that
buffer to MVS for either read or write? Or
alternatively, do you allocate any buffers
already that READ and WRITE (or GET
and PUT) never get to see? Or even just
variables, not buffers. Anything that could
conceivably be allocated above 2 GiB.

I can provide the code that does the BSMs
so that your application can switch between
AM24 and AM32. But before we start I want
to explain to you how that works. I've already
written a document that explains it (ie at the
bottom of the previous message). Do you
have time to read it and ask me anything you
don't understand or agree with? Explaining
how it works is half the challenge. This is a
deviance from anything written in any existing
assembler book, or any existing assembler
program, so people are free to call bullshit
on the new technique. We'll see.

Can you show me the current code?

Thanks. Paul.

---

Paul, I didn't write any code at this
moment, beside small assembler test
programs, which do almost nothing
beside reading and writing, using the
standard MVS OPEN/GET/PUT/CLOSE, "cards"
from a RECFM=F dataset.

As I wrote, at the level of student
exercises like this:

* PRINT NOGEN
****************************************************************
* FILENAME: TEACH1A.MLC
* REMARKS : A card-image list of teacher records.
****************************************************************
START 0
YREGS
BEGIN SUBENTRY
OPEN (TEACHERS,INPUT)
LOOP GET TEACHERS,IREC
* XDUMP IREC,27
WTA IDATA
B LOOP
ATEND CLOSE TEACHERS
SUBEXIT
TEACHERS DCB LRECL=27,RECFM=FT,MACRF=GM,EODAD=ATEND,DDNAME=TEACHERS
IREC DS 0CL27
IDATA DS CL27
END BEGIN

Peppe.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@vitillaro.org> wrote :

> BEGIN SUBENTRY
> OPEN (TEACHERS,INPUT)
> LOOP GET TEACHERS,IREC

Hi Peppe.

If you are going to use this program as the
basis of your future programs, then how about
we start making these fundamental changes
that allow your program to run as AM64?

That "GET" above will probably abend if you
mark your module as AM64.

To circumvent the abend, you need to surround
that "GET" with GAMOS and GAMAPP. I can
provide the code for that if you can test it out
and if you agree with the reasons for doing so.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

On Mon, 12 Mar 2018, ***@yahoo.com.au [hercules-os380] wrote:

> ---In hercules-***@yahoogroups.com, <***@vitillaro.org> wrote :

> BEGIN SUBENTRY
> OPEN (TEACHERS,INPUT)
> LOOP GET TEACHERS,IREC

Hi Peppe.

If you are going to use this program as the
basis of your future programs, then how about
we start making these fundamental changes
that allow your program to run as AM64?

That "GET" above will probably abend if you
mark your module as AM64.

To circumvent the abend, you need to surround
that "GET" with GAMOS and GAMAPP. I can
provide the code for that if you can test it out
and if you agree with the reasons for doing so.

BFN. Paul.

---

I think now I understand what you wish from me,
Paul.

Well, I may try to test your environment
from simple assembler programs, like the
one I posted.

If you provide me with detailed information
about what I need to download and install on
my newborn SYS2, time allowing, I'll provide
a feedback.

I guess I'll need at minimum to setup your
new 31 bit support (I'm still using the old
dear SVC120I by now on my SYS2, which happens
to run under your patched hercules 3.07 emulator)
and test it.

I should have around all the updates Gerhard
sent me and I remember I've assembled them on my SYS2,
but I didn't test them. An upgrade is any way on my
schedule, so, we may try to update what I've
in my hands to your last environment,
Paul. From there I may try some simple assembler
tests, following your instructions.

But, better you are not in hurry, Paul.

Remember MVS is an hobby for me, I can't
dedicate much time by now to MVS, beside
some work I'm still doing to test and grow
up the new born SYS2-Volker-Moseley to the
level I may move my old SYS1-Moseley environment.

Now I'm playing with Thomas new MVS38 SORT,
the one published on December 2016 (see how
much I'm late on my tests Paul?).

I'm getting really nice ABEND U0053 about
"IER053A Out of Sequence Error" on datasets
containing few records, while it works on
larger test dataset (the one Thomas and Moseley
provide).

Damn, this is an error that should arise only
from a "merge phase" and I'm not doing any "merge",
as the SORT program report "IER049I Skip Merge Phase".
The same test works nicely with the original OS-360
Moseley MVTSORT, all done over the old dear
2314 sort dasds at this moment.

Guess I should write to Thomas, but it is really
a shame for me, I'm just two years late on these tests ;-)

Another pending project for me, is a basic C library,
I'm currently writing under Linux (in a GCCMVS portable
fashion, I hope) to be able to write a "mini370 assembler",
rewriting the z390 code in C. I've already done the PCRE
routines (which will make me able to reuse the z390
regular expressions of the z390 lexical analyzer) and
I'm writing a simple and small hash table library
(using the uthash C macro only package) for handling
opcode and symbol tables. I should be able to "import"
the z390 opcode table in a couple of weeks and from
there I'll be able to parse simple assembler sources
in other few weeks, under Linux.

If this setup will show to be able to parse a small
subset of the 370 assembler syntax in working machine
code, I'll try to recompile all the "pack" under MVS,
with GCCMVS.

It is just a funny game by now, but, beside my main
job as an HPC sysadm, it keep me really busy, Paul.

Apologies for this long answer, but I wish you understand
why I can't exactly fulfill your "pinea pig" request
at this moment, Paul.

Peppe.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@vitillaro.org> wrote :

> If you provide me with detailed information
> about what I need to download and install on
> my newborn SYS2, time allowing, I'll provide
> a feedback.

> I guess I'll need at minimum to setup your
> new 31 bit support (I'm still using the old
> dear SVC120I by now on my SYS2, which happens
> to run under your patched hercules 3.07 emulator)
> and test it.

To start with we don't even need that, because
you're not doing ATL GETMAINs.

All you need is the BSM instruction and the
ability to mark your load module AM64.

> I should have around all the updates Gerhard
> sent me and I remember I've assembled them on my SYS2,
> but I didn't test them.

Even when you reach a situation that you
wish to do a 31-bit or 32-bit GETMAIN, you
don't need anything from Gerhard. I provide
what is required in mvs380-beta5.zip.

> But, better you are not in hurry, Paul.

It is enough that the experts here see what I
am asking you to do and I can defend my
actions.

Anyway, whenever you get a chance, can
you mark your "teachers" load module as AM64
using "PDS" or some other utility and see if
it abends?

If you don't have "PDS" you can instead use
the iewl.exe in mvs380-beta5 to do the link.
You just need to add "AMODE=32" to the
parameter string. I will probably change that
to "AMODE=64" in a future release now that
I am comfortable with handling AM32 programs.

If you can confirm that AM24 works but AM64
abends, I will then give you some code in an
attempt to make your application trimodal
(24/31/infinity). Your application will not be
dependent on address truncation at either
32-bits or 64-bits, hence it will be infinity,
not AM32 or AM64.

While waiting for you to zap your module
AM64 I will get the code change ready and
see who jumps on me.

Thanks. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"f you don't have "PDS" you can instead use
the iewl.exe in mvs380-beta5 to do the link.
You just need to add "AMODE=32" to the
parameter string. I will probably change that
to "AMODE=64" in a future release now that
I am comfortable with handling AM32 programs."

Why dont you just modify IEWL to handle an AMODE card?

Joe

On Mon, Mar 12, 2018 at 7:14 AM, ***@yahoo.com.au [hercules-os380] <
hercules-***@yahoogroups.com> wrote:

>
>
> ---In hercules-***@yahoogroups.com, <***@vitillaro.org> wrote :
>
> > If you provide me with detailed information
> > about what I need to download and install on
> > my newborn SYS2, time allowing, I'll provide
> > a feedback.
>
> > I guess I'll need at minimum to setup your
> > new 31 bit support (I'm still using the old
> > dear SVC120I by now on my SYS2, which happens
> > to run under your patched hercules 3.07 emulator)
> > and test it.
>
> To start with we don't even need that, because
> you're not doing ATL GETMAINs.
>
> All you need is the BSM instruction and the
> ability to mark your load module AM64.
>
> > I should have around all the updates Gerhard
> > sent me and I remember I've assembled them on my SYS2,
> > but I didn't test them.
>
> Even when you reach a situation that you
> wish to do a 31-bit or 32-bit GETMAIN, you
> don't need anything from Gerhard. I provide
> what is required in mvs380-beta5.zip.
>
> > But, better you are not in hurry, Paul.
>
> It is enough that the experts here see what I
> am asking you to do and I can defend my
> actions.
>
> Anyway, whenever you get a chance, can
> you mark your "teachers" load module as AM64
> using "PDS" or some other utility and see if
> it abends?
>
> If you don't have "PDS" you can instead use
> the iewl.exe in mvs380-beta5 to do the link.
> You just need to add "AMODE=32" to the
> parameter string. I will probably change that
> to "AMODE=64" in a future release now that
> I am comfortable with handling AM32 programs.
>
> If you can confirm that AM24 works but AM64
> abends, I will then give you some code in an
> attempt to make your application trimodal
> (24/31/infinity). Your application will not be
> dependent on address truncation at either
> 32-bits or 64-bits, hence it will be infinity,
> not AM32 or AM64.
>
> While waiting for you to zap your module
> AM64 I will get the code change ready and
> see who jumps on me.
>
> Thanks. Paul.
>
>

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :

>> If you don't have "PDS" you can instead use
>> the iewl.exe in mvs380-beta5 to do the link.
>> You just need to add "AMODE=32" to the
>> parameter string. I will probably change that
>> to "AMODE=64" in a future release now that
>> I am comfortable with handling AM32 programs.

> Why dont you just modify IEWL to handle an AMODE card?

Won't that require the assembler to change to
support that as well? Currently I am building
IEWL from source but not IFOX. The current
solution seems to be the neatest?

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> While waiting for you to zap your module
> AM64 I will get the code change ready and
> see who jumps on me.

Attached and below is my opening bid. It
won't actually assemble as-is, as I need
to look at Gerhard's code to see if I can
figure out macro syntax, but it is complete
enough that it can be understood and
critiqued so that I can potentially update
it with improvements.

BFN. Paul.



ENTRY @@SETUP
@@SETUP DS 0H
SAVE (14,12),,@@SETUP
LR R12,R15
USING @@SETUP,R12
*
* If we are running in a pure 24-bit environment, where
* the AMODE and RMODE are the same, there is no need to
* ever do AMODE switching, so none of this AMODE
* switching code is required at all
*
L R2,=X'FF000000'
LA R2,0(,R2)
CLM R2,B'1000',=X'00'
* If we are currently in AM24, there is nothing
* to ever do, as we will stay in that mode forever
BE RETURNSU
*
* Now see if we are running AM31
CLM R2,B'1000',=X'7F'
BZ IS32
* We are running AM31. If we are also located in
* RM31 space we do not need to do BSM switching
LR R2,R12
N R2,=X'7F000000'
LTR R2,R2
BNZ RETURNSU No amode switching possible
* The app is AM31 but the OS is AM24
* An OS of AM24 is default, so just go and set the
* application AMODE now
B COMM3164
IS32 DS 0H
*
* At this stage we know we are running in AM64
* aka AM32 aka AM-infinity (we don't know which one)
* First we need to know if we are running in RM32,
* highly unlikely.
*
LR R2,R12
N R2,=X'80000000'
LTR R2,R2
BNZ RETURNSU No amode switching possible
* Now see if we are running in RM31 space
LR R2,R12
N R2,=X'7F000000'
LTR R2,R2
BZ COMM3164 RM24 so just set the app amode bits
* We are indeed running in RM31 so we need the high bit
* set whenever we switch to OS mode
OI NEEDBOO,X'80'
COMM3164 DS 0H
* We have dealt with the appropriate bits to set
* the OS mode, now we need to set the return to
* application mode. That is easy, it is the current
* amode, either AM64 or AM31
LA R2,0
BSM R2,0
ST R2,NEEDBOA this will be suitable for ORing
OI NEEDBF,NEEDBANY set flag to say we need BSM switching
B RETURNSU
*
RETURNSU DS 0H
LA R15,0
RETURN (14,12),RC=(15)
LTORG ,
NEEDBF DC X'00' flag bits for whether BSM needed
NEEDBANY EQU X'01' need any amode switching at all?
NEEDBOA DC A(0) amode bits to be ORed in to return APP to
* original amode
NEEDBOO DC A(0) amode bits to be ORed in to set OS amode



*
*
*
MACRO ,
&NM GAMOS
.*
.* GAMOS sets addressing mode to 24 or 31 or
.* potentially bypasses the BSM
.*
TM NEEDBF,NEEDBANY Need AM switching?
BZ .NOSWANY
LA R14,.CONTB1
O R14,NEEDBOO whatever mode OS requires
BSM 0,R14
.CONTB1
.NOSWANY
.MEND MEND ,



*
*
*
MACRO ,
&NM GAMAPP
.*
.* GAMAPP sets addressing mode to 31 or 64 or
.* potentially bypasses the BSM
.*
&NM TM NEEDBF,NEEDBANY Did we previously need a switch?
BZ .FINSW No, no switching required
.* We don't know whether we need to switch to 31 or 64
LA R14,.FINSW
O R14,NEEDBOA This decides 31/64
BSM R0,R14
.FINSW ANOP
.MEND MEND ,
*
*
*

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> abends, I will then give you some code in an
> attempt to make your application trimodal
> (24/31/infinity). Your application will not be
> dependent on address truncation at either
> 32-bits or 64-bits, hence it will be infinity,
> not AM32 or AM64.

Perhaps not. There is a distinction between
whether the application is using the full
64 bits of the register or just the low 32 bits.
A 32-bit program is not expected to pass
around 64-bit pointers to ensure the high
32 bits are 0.

I'll need to rethink this yet again. It's not
enough to just vacate the 4 GiB to 8 GiB
region. Unless the operating system can
guarantee that the high 32 bits will be
zero on entry.

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> I'll need to rethink this yet again. It's not
> enough to just vacate the 4 GiB to 8 GiB
> region. Unless the operating system can
> guarantee that the high 32 bits will be
> zero on entry.

Let's abstract the problem by considering a
128-bit load module calling a 64-bit load
module. The 64-bit program cannot know
about the new 128-bit instructions that would
cause the upper 64 bits to be cleared.

The responsibility instead needs to be put onto
the 128-bit program to pass the 64-bit program
clean upper 64 bits. It either needs to do this
itself or it needs the intermediate LINK etc to
do that. If LINK does it, then LINK needs to
save the 128-bit registers itself, as well as
clearing the upper 64 bits. And if the target
program is actually a 32-bit program, the
caller, or LINK, will need to save and clear
96 bits.

That assumes that we are trying to mark the
called 64-bit program as AM-infinity rather
than having a special bit in the load module
and PSW that restricts the address to
64 bits. If we have a special bit, then we
don't need to clear the upper 64 bits, but
it does mean that return codes like R15
will have junk in the top 64 bits potentially.

No matter what, R13 will need to be in RM64
space. In order for a terminating BR R14 to
work, the 128-bit program will need to be in
RM64 space if either it is to be invoked in
AM64 or if the upper 64 bits of R14 are cleared.

These issues should all have occurred when
a 64-bit program called a 32-bit program (any
AMODE), and probably also when an AM31
program called an AM24 program.

How did IBM solve these problems for all of
LINK/LOAD/etc?

And Windows and Unix should have had the
same problem for 64-bit programs calling
32-bit programs. How did they solve this
problem?

Thanks. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"And Windows and Unix should have had the
same problem for 64-bit programs calling
32-bit programs. How did they solve this
problem?"

Windows and Unix use separate emulation layers when running 32 bit apps on
a 64bit system. On Linux/Unix you have to install the i386 libraries.
Windows provides a subsystem SYSWOW64 that allows the running of 32bit apps..

Joe

On Mon, Mar 12, 2018 at 7:33 PM, ***@yahoo.com.au [hercules-os380] <
hercules-***@yahoogroups.com> wrote:

>
>
> ---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :
>
> > I'll need to rethink this yet again. It's not
> > enough to just vacate the 4 GiB to 8 GiB
> > region. Unless the operating system can
> > guarantee that the high 32 bits will be
> > zero on entry.
>
> Let's abstract the problem by considering a
> 128-bit load module calling a 64-bit load
> module. The 64-bit program cannot know
> about the new 128-bit instructions that would
> cause the upper 64 bits to be cleared.
>
> The responsibility instead needs to be put onto
> the 128-bit program to pass the 64-bit program
> clean upper 64 bits. It either needs to do this
> itself or it needs the intermediate LINK etc to
> do that. If LINK does it, then LINK needs to
> save the 128-bit registers itself, as well as
> clearing the upper 64 bits. And if the target
> program is actually a 32-bit program, the
> caller, or LINK, will need to save and clear
> 96 bits.
>
> That assumes that we are trying to mark the
> called 64-bit program as AM-infinity rather
> than having a special bit in the load module
> and PSW that restricts the address to
> 64 bits. If we have a special bit, then we
> don't need to clear the upper 64 bits, but
> it does mean that return codes like R15
> will have junk in the top 64 bits potentially.
>
> No matter what, R13 will need to be in RM64
> space. In order for a terminating BR R14 to
> work, the 128-bit program will need to be in
> RM64 space if either it is to be invoked in
> AM64 or if the upper 64 bits of R14 are cleared.
>
> These issues should all have occurred when
> a 64-bit program called a 32-bit program (any
> AMODE), and probably also when an AM31
> program called an AM24 program.
>
> How did IBM solve these problems for all of
> LINK/LOAD/etc?
>
> And Windows and Unix should have had the
> same problem for 64-bit programs calling
> 32-bit programs. How did they solve this
> problem?
>
> Thanks. Paul.
>
>

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :

>> And Windows and Unix should have had the
>> same problem for 64-bit programs calling
>> 32-bit programs. How did they solve this
>> problem?"

> Windows and Unix use separate emulation layers
> when running 32 bit apps on a 64bit system. On
> Linux/Unix you have to install the i386 libraries.
> Windows provides a subsystem SYSWOW64 that
> allows the running of 32bit apps.

Thanks. But how are registers preserved?

I'm guessing that Windows/Unix doesn't have the
same expectation of a LOAD EP= being able to
do a fast BALR.

If everything is channeled through a LINK EP=
and LINK takes care of preserving registers,
we would presumably be the same as Windows/Unix.

But LINK EP= cannot be used by an AM64 caller.
We can overcome that problem by keeping the
load module RM31 and switching to AM31 before
calling the new program. But even in AM31 there
is the question of who is going to preserve the
upper 32 bits of registers if the new program is
AM64. I'm wondering if the program needs to set
up a F5SA save area after all, so that AM32/64
are supported. Actually, even so that AM24 can
be supported if the program uses 64-bit registers
for something other than addressing.

BFN. Paul.

[[e-mail] [hercules-os380]]

I have a simpler question.

If PROGA and PROGB are AM24 programs, and
PROGA does a LINK or ATTACH to PROGB, and
PROGB is not well-behaved and doesn't save
and restore the registers properly, does PROGA
get affected, or does the LINK/ATTACH take care
of saving PROGA's registers properly?

Or do the save areas link PROGA directly to
PROGB?

Thanks. Paul.

[Gerhard Postpischil [e-mail] [hercules-os380]]

On 3/12/2018 11:13 PM, ***@yahoo.com.au [hercules-os380] wrote:
> If PROGA and PROGB are AM24 programs, and
> PROGA does a LINK or ATTACH to PROGB, and
> PROGB is not well-behaved and doesn't save
> and restore the registers properly, does PROGA
> get affected, or does the LINK/ATTACH take care
> of saving PROGA's registers properly?

LINK and ATTACH create a new PRB, and return via R14 pointing to CVTEXIT
(SVC 3). Except for the R14 return address, nothing done to the
registers by PROGB affects PROGA.

> Or do the save areas link PROGA directly to
> PROGB?

Which save areas? TCB save, PRB save, SVRB save, or ?
Registers belonging to PROGA are saved in its PRB, and restored before
returning, something you should have noticed while working on IEWFETCH.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@charter.net> wrote :

> LINK and ATTACH create a new PRB, and return via R14 pointing to CVTEXIT
> (SVC 3). Except for the R14 return address, nothing done to the
> registers by PROGB affects PROGA.

Ok, so I would guess that LINK has been updated
to save the full 64-bit registers. However, I'm also
guessing that it doesn't zero out the top 32-bits
of registers prior to calling PROGB.

Therefore we should have a convention that PROGA
is responsible for both saving the high 32-bits and
setting them to 0.

Also, on MVS/380 I just realized that the top 32 bits
of registers can be cleared at FETCH time rather
than in the stub, which should make programming
easier.

>> Or do the save areas link PROGA directly to
>> PROGB?

> Which save areas? TCB save, PRB save, SVRB save, or ?

I had assumed that the normal save areas in
PROGB chained all the way up to PROGA's
save areas, but it seems that assumption
is incorrect.

> Registers belonging to PROGA are saved in its PRB, and restored before
> returning, something you should have noticed while working on IEWFETCH.

IEWFETCH was an SVC 120 which I don't know
the internal details of, other than what registers
are documented to be returned. LINK and ATTACH
I also don't know the internal details of.

BFN. Paul.

[Gerhard Postpischil [e-mail] [hercules-os380]]

On 3/13/2018 2:31 AM, ***@yahoo.com.au [hercules-os380] wrote:
> Ok, so I would guess that LINK has been updated
> to save the full 64-bit registers. However, I'm also
> guessing that it doesn't zero out the top 32-bits
> of registers prior to calling PROGB.

You might do better to consult the relevant documentation instead of
guessing. I have no idea what LINK does in a 64-bit environment, or
whether LINKX is required.

BTW - on Peppe's program, why use RECFM=F rather than FB. Also why do
you waste cycles and storage with an LTR after an N? Elsewhere on a
mainframe related list I saw an estimate that it takes about ten years
to become a proficient mainframe programmer; you really should be able
to do better.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@charter.net> wrote :

>> Ok, so I would guess that LINK has been updated
>> to save the full 64-bit registers. However, I'm also
>> guessing that it doesn't zero out the top 32-bits
>> of registers prior to calling PROGB.

> You might do better to consult the relevant documentation instead of
> guessing. I have no idea what LINK does in a 64-bit environment, or
> whether LINKX is required.

I did take a look at it already. Here is the link:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieaa900/iea3a9_Description4.htm

It at least implies that the high 32 bits are not cleared:

2-13
Unchanged

> BTW - on Peppe's program, why use RECFM=F rather than FB.

It used to be FT, but when I was experiencing a
failure I started changing random things, so FT
ended up as F. I'm not worried too much about
Peppe's portion of the code, just my addition.

The other thing I noticed was that I needed to
make SETUP an ENTRY, otherwise the CALL
didn't work (it tried to find it in SYSLIB instead).
Ideally I wouldn't expose that internal function.
Do I need a BAL R14,SETUP instead?

> Also why do
> you waste cycles and storage with an LTR after an N?

Ok, I'll try changing that.

> Elsewhere on a
> mainframe related list I saw an estimate that it takes about ten years
> to become a proficient mainframe programmer; you really should be able
> to do better.

If I have a utility to write on MVS, like hexdump,
I bet I can write it from scratch in C faster than
you can write it in assembler. So I am a
proficient mainframe programmer, just in a
different language than the one you use and
that I don't claim to be proficient in. And my
version will work both in batch and as a TSO
CP and many many other cool features.

BFN. Paul.

[Gerhard Postpischil [e-mail] [hercules-os380]]

On 3/13/2018 3:18 AM, ***@yahoo.com.au [hercules-os380] wrote:
> It used to be FT, but when I was experiencing a
> failure I started changing random things, so FT
> ended up as F. I'm not worried too much about
> Peppe's portion of the code, just my addition.

FT is strictly for disks with track overflow, to allow writing blocks
longer than the track capacity. As written, the TEACHER file only has
three cards, but in serious use it would be a tape or disk file, so
having F rather than FB is like setting a booby-trap.

> The other thing I noticed was that I needed to
> make SETUP an ENTRY, otherwise the CALL
> didn't work (it tried to find it in SYSLIB instead).
> Ideally I wouldn't expose that internal function.
> Do I need a BAL R14,SETUP instead?

There are at least three ways to do this:

L R15,=A(SETUP)
BALR R14,R15

BAL R14,SETUP

WXTRN SETUP
CALL SETUP

Each has different implications. As SETUP is written, the BAL version
would fail (R15 not set).

> If I have a utility to write on MVS, like hexdump,
> I bet I can write it from scratch in C faster than
> you can write it in assembler. So I am a
> proficient mainframe programmer, just in a
> different language than the one you use and
> that I don't claim to be proficient in. And my
> version will work both in batch and as a TSO
> CP and many many other cool features.
MVS proficiency is unrelated to the language you use. Even on the 7094
you needed three control cards (JOB, ForTran/MAP compiler spec, and
EOJ), and you needed to know how many channels and tapes were available,
and memory limitations. On the mainframe, you need to known JCL, how to
edit under TSO (unless you use card decks), how I/O gear is configured,
what DASD you may use, what the device generics are, how much memory is
available, what printer classes are supported, what forms you need for
printing, etc. Most importantly, you need to know the actual and allowed
physical limits - how many tapes can you request for one DD, how many
data set may be concatenated. It also helps if you know what utility and
support programs IBM provides, so you don't waste time reinventing the
wheel.

You keep mentioning hexdump as though it were some great achievement.
Most MVS programmers would just use IDCAMS rather than writing a new
program, and not worry about irrelevant portability. When you have
written a program that handles thousands of transaction per second, with
fallback capability, you might consider than noteworthy.

As to hexdump, I have macros and service subroutines that would allow
that to be written quickly (some dating back to the sixties). I also
have a hex formatting subroutine that has options whether to display
relative or absolute addresses, whether to display text equivalent
(ECBDIC or ASCII), and instruction mnemonics.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

On Tue, 13 Mar 2018, Gerhard Postpischil ***@charter.net [hercules-os380] wrote:

> On 3/13/2018 2:31 AM, ***@yahoo.com.au [hercules-os380] wrote:
>> Ok, so I would guess that LINK has been updated
>> to save the full 64-bit registers. However, I'm also
>> guessing that it doesn't zero out the top 32-bits
>> of registers prior to calling PROGB.
>
> You might do better to consult the relevant documentation instead of
> guessing. I have no idea what LINK does in a 64-bit environment, or
> whether LINKX is required.
>
> BTW - on Peppe's program, why use RECFM=F rather than FB. Also why do
> you waste cycles and storage with an LTR after an N? Elsewhere on a
> mainframe related list I saw an estimate that it takes about ten years
> to become a proficient mainframe programmer; you really should be able
> to do better.
>

Well Gerhard, the assembler exercise I posted was in the
Z390 shape, these are the MVS3.8j versions of TEACH1A and
a simple "MINICOPY" fragment I got from a forum I've elaborated
over a little bit, thought as a starting point for a program
that may manage RECFM=VS/F conversions (guess GET/PUT macro
are not enough for that a job, isn't?).

http://www.vitillaro.org/curr/teach1A.asm
http://www.vitillaro.org/curr/minicopy.asm

Just simple as is possible to think a "copy records" program
under MVS, I guess.

Forgive my naivness Gerhard, I'm just learning, as you know,
and I'm still far from ten years of mainframe programming
skills ;-)

Peppe.

[pricgren [e-mail] [hercules-os380]]

On 2018-03-13 2:13 PM, ***@yahoo.com.au [hercules-os380] wrote:
>
> I have a simpler question.
>
> If PROGA and PROGB are AM24 programs, and
> PROGA does a LINK or ATTACH to PROGB, and
> PROGB is not well-behaved and doesn't save
> and restore the registers properly, does PROGA
> get affected, or does the LINK/ATTACH take care
> of saving PROGA's registers properly?
>
ATTACH sets up an independent unit of work with its own set of register
values, generally initialized by the system.

LINK transmits the caller's register values to the called routine, which
transmits its register values back to the called program. Exceptions are
that the called program receives GPR14 and GPR15 values set by the system.

Cheers,
Greg

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com> wrote :

>> If PROGA and PROGB are AM24 programs, and
>> PROGA does a LINK or ATTACH to PROGB, and
>> PROGB is not well-behaved and doesn't save
>> and restore the registers properly, does PROGA
>> get affected, or does the LINK/ATTACH take care
>> of saving PROGA's registers properly?

> LINK ... transmits its register values back to the
> called program.

Unless I'm misunderstanding you or Gerhard, Gerhard
said the opposite of that:

Ge> LINK and ATTACH create a new PRB, and return
Ge> via R14 pointing to CVTEXIT
Ge> (SVC 3). Except for the R14 return address,
Ge> nothing done to the
Ge> registers by PROGB affects PROGA.


ie PROGA's registers are not messed with.

BFN. Paul.

[pricgren [e-mail] [hercules-os380]]

On 2018-03-13 9:03 PM, ***@yahoo.com.au [hercules-os380] wrote:
> > LINK ... transmits its register values back to the
> > called program.
>
> Unless I'm misunderstanding you or Gerhard, Gerhard
> said the opposite of that

Well, Gerhard probably always restores the registers properly, but I
didn't once and the calling program fell over.
:)

You included a URL of an IBM KC page.  On that page it says:
"Upon return to the caller, the GPRs contain whatever values the called
program placed there."

In general, the GPRs of a TCB are saved in the TCB, and they are not
restored back to the GPR values saved in the caller's PRB when the
called PRB terminates.

This is in contrast to the case where an SVRB terminates (for example) -
in this case the GPRs (apart from the SVC communication GPRS of 15, 0
and 1) are restored from the SVRB to the TCB, the values in the SVRB
being set from the values current when the SVC was issued.

Cheers,
Greg

[Gerhard Postpischil [e-mail] [hercules-os380]]

On 3/13/2018 6:03 AM, ***@yahoo.com.au [hercules-os380] wrote:
> Unless I'm misunderstanding you or Gerhard, Gerhard
> said the opposite of that:
>
> Ge> LINK and ATTACH create a new PRB, and return
> Ge> via R14 pointing to CVTEXIT
> Ge> (SVC 3). Except for the R14 return address,
> Ge> nothing done to the
> Ge> registers by PROGB affects PROGA.
I'll be a monkey's uncle - rather than relying on documentation, I ran a
quick test.

PROGA loads 0-8 into R0-R8, then calls PROGB. PROGB saves and restores
registers, and PROGA keeps R0-R8 as before the LINK.

Then I wrote PROGC to load R0-R8 with 8-0, and that was what was
returned to PROGA.

So despite PROGB/C's having their own PRB with a save area, LINK
processing returns to CVTEXIT, and that returns the altered registers!

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

[Joe Monk [e-mail] [hercules-os380]]

"LINK transmits the caller's register values to the called routine, which
transmits its register values back to the called program. Exceptions are
that the called program receives GPR14 and GPR15 values set by the system."

The LINK doc says:

"The convention regarding registers 2-12 still applies; the control program
does not change the contents of these registers, and the called load module
should restore them before control is returned."

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa600/iea3a6_Using_the_LINK_or_LINKX_macro.htm

Joe

On Tue, Mar 13, 2018 at 4:43 AM, pricgren ***@yahoo.com
[hercules-os380] <hercules-***@yahoogroups.com> wrote:

>
>
> On 2018-03-13 2:13 PM, ***@yahoo.com.au [hercules-os380] wrote:
>
>
>
> I have a simpler question.
>
> If PROGA and PROGB are AM24 programs, and
> PROGA does a LINK or ATTACH to PROGB, and
> PROGB is not well-behaved and doesn't save
> and restore the registers properly, does PROGA
> get affected, or does the LINK/ATTACH take care
> of saving PROGA's registers properly?
>
> ATTACH sets up an independent unit of work with its own set of register
> values, generally initialized by the system.
>
> LINK transmits the caller's register values to the called routine, which
> transmits its register values back to the called program. Exceptions are
> that the called program receives GPR14 and GPR15 values set by the system..
>
> Cheers,
> Greg
>
>
>

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> I'm wondering if the program needs to set
> up a F5SA save area after all, so that AM32/64
> are supported.

I think Peppe's example program, when AM64
is detected, needs to set up an F5SA and then
do a LMH to clear the high 32 bits. I don't think
it can rely on those high bits being clear.

That means that even a 32-bit program needs
to have a dependency on the 64-bit registers
and instructions being available. If that is done,
it is the death of S/380, and z/380 becomes
the minimum. :-(

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> That means that even a 32-bit program needs
> to have a dependency on the 64-bit registers
> and instructions being available. If that is done,
> it is the death of S/380, and z/380 becomes
> the minimum. :-(

On the assumption that LINK does not preserve
the top 32 bits of registers, I can think of another
solution.

On MVS/380, LINK can be modified to clear the
top 32 bits of registers, so Peppe's AM32 program
will remain simple. This is not a problem on
z/OS where AM32 is not supported, so the 32-bit
module will be marked AM31 instead.

64-bit programs are expected to save the upper
32 bits themselves with STMH prior to dropping
to AM31 and calling LINK.

The modification to LINK/ATTACH will instead be
done using the existing stub. The stub will do a
LMH of zeroes.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

LINK EP= doesn't work in AM64..

LINKX is for that.

Joe

On Mon, Mar 12, 2018 at 9:35 PM, ***@yahoo.com.au [hercules-os380] <
hercules-***@yahoogroups.com> wrote:

>
>
> ---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :
>
> >> And Windows and Unix should have had the
> >> same problem for 64-bit programs calling
> >> 32-bit programs. How did they solve this
> >> problem?"
>
> > Windows and Unix use separate emulation layers
> > when running 32 bit apps on a 64bit system. On
> > Linux/Unix you have to install the i386 libraries.
> > Windows provides a subsystem SYSWOW64 that
> > allows the running of 32bit apps.
>
> Thanks. But how are registers preserved?
>
> I'm guessing that Windows/Unix doesn't have the
> same expectation of a LOAD EP= being able to
> do a fast BALR.
>
> If everything is channeled through a LINK EP=
> and LINK takes care of preserving registers,
> we would presumably be the same as Windows/Unix.
>
> But LINK EP= cannot be used by an AM64 caller.
> We can overcome that problem by keeping the
> load module RM31 and switching to AM31 before
> calling the new program. But even in AM31 there
> is the question of who is going to preserve the
> upper 32 bits of registers if the new program is
> AM64. I'm wondering if the program needs to set
> up a F5SA save area after all, so that AM32/64
> are supported. Actually, even so that AM24 can
> be supported if the program uses 64-bit registers
> for something other than addressing.
>
> BFN. Paul.
>
>

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :

> LINK EP= doesn't work in AM64..

Yes, but we can simply make our 64-bit AM64
program switch to AM31 prior to doing a
LINK EP=, and it will work fine on both z/OS
and MVS/380.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

I'm confused.

When you use link or links, the linking program does not determine the
addresses for R14 and R15.... the OS does that...

"When you use the LINK or LINKX macro, it is the control program that
establishes the values in registers 14 and 15... After the control program
determines the entry point address, it places the address in register 15 if
the target routine is to run in 24-bit or 31-bit addressing mode. If the
target routine is to run in 64-bit addressing mode, that routine is
expected to use relative branching, and register 15 contains a value that
can be used to determine the addressing mode of the issuer of the LINK or
LINKX macro as follows:

- Issuer AMODE 24: X'FFFFF000'
- Issuer AMODE 31: X'FFFFF002'
- Issuer AMODE 64: X'FFFFF004'


https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa600/iea3a6_Using_the_LINK_or_LINKX_macro.htm

Joe


On Tue, Mar 13, 2018 at 4:22 AM, ***@yahoo.com.au [hercules-os380] <
hercules-***@yahoogroups.com> wrote:

>
>
> ---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :
>
> > LINK EP= doesn't work in AM64..
>
> Yes, but we can simply make our 64-bit AM64
> program switch to AM31 prior to doing a
> LINK EP=, and it will work fine on both z/OS
> and MVS/380.
>
> BFN. Paul.
>
>

[Joe Monk [e-mail] [hercules-os380]]

Oh and one other little tidbit...

"The control program saves the address of the location in your program in
its own save area, and places in register 14 the address of a routine
within the control program that will receive control. Because control was
passed using the control program, return must also be made using the
control program. The control program also handles all switching of
addressing mode when processing the LINK or LINKX macro."

Joe

On Tue, Mar 13, 2018 at 4:42 AM, Joe Monk <***@gmail.com> wrote:

> I'm confused.
>
> When you use link or links, the linking program does not determine the
> addresses for R14 and R15.... the OS does that...
>
> "When you use the LINK or LINKX macro, it is the control program that
> establishes the values in registers 14 and 15... After the control
> program determines the entry point address, it places the address in
> register 15 if the target routine is to run in 24-bit or 31-bit addressing
> mode. If the target routine is to run in 64-bit addressing mode, that
> routine is expected to use relative branching, and register 15 contains a
> value that can be used to determine the addressing mode of the issuer of
> the LINK or LINKX macro as follows:
>
> - Issuer AMODE 24: X'FFFFF000'
> - Issuer AMODE 31: X'FFFFF002'
> - Issuer AMODE 64: X'FFFFF004'
>
>
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.
> 0/com.ibm.zos.v2r1.ieaa600/iea3a6_Using_the_LINK_or_LINKX_macro.htm
>
> Joe
>
>
> On Tue, Mar 13, 2018 at 4:22 AM, ***@yahoo.com.au [hercules-os380]
> <hercules-***@yahoogroups.com> wrote:
>
>>
>>
>> ---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :
>>
>> > LINK EP= doesn't work in AM64..
>>
>> Yes, but we can simply make our 64-bit AM64
>> program switch to AM31 prior to doing a
>> LINK EP=, and it will work fine on both z/OS
>> and MVS/380.
>>
>> BFN. Paul.
>>
>>
>
>

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :

>>> LINK EP= doesn't work in AM64..

>> Yes, but we can simply make our 64-bit AM64
>> program switch to AM31 prior to doing a
>> LINK EP=, and it will work fine on both z/OS
>> and MVS/380.

> I'm confused.

Now I am too. :-) I'm not sure what your argument is.

> When you use link or links,

I assume you meant "linkx" not "links".

> the linking program
> does not determine the addresses for R14 and
> R15.... the OS does that...

The problem that I am addressing is not just
R14 and R15. All registers can have crap in
the top 32 bits and a 32 bit program which I
have marked AM32/64/infinity has no
knowledge of these top 32 bits, or even top
96 bits if AM128 ever becomes a reality.

Someone needs to have knowledge of and
clear those high bits. The fact that LINK
doesn't do that automatically, even for say
an AM31 program that happens to be using
64-bit registers for data, means that the
called 32 bit program is in trouble because
all the 32-bit addresses that it loads into
32-bit registers will be treated as 64-bit
addresses with the crud in the top 32 bits
wreaking havoc.

> When you use the LINK or LINKX macro, it is
> the control program that establishes the
> values in registers 14 and 15...

"control program" being z/OS sets R14 and R15,
probably as full 64-bit values, that's fine.

> The control program saves the address of the
> location in your program in its own save area,
> and places in register 14 the address of a
> routine within the control program that will
> receive control. Because control was passed
> using the control program, return must also
> be made using the control program. The control
> program also handles all switching of addressing
> mode when processing the LINK or LINKX macro.

I think I understand that, but I don't think that is
in disagreement with anything I have said.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

Now I'm really confused :)

The registers are stored in the save area, yes?

So, if I link with "clean" registers stored in the save area, how will the
registers become "dirty" upon return, since the save area is restored upon
return?

In other words, if I link to an AM31 program, and only execute AM31 or 24
instructions, what is going to pollute the top 32 bits of the registers
stored in the caller's save area, since the AM31 or 24 instructions of the
called program only use the bottom half of a 64bit register, and the
caller's clean save area is restored upon return?

Joe

On Tue, Mar 13, 2018 at 4:58 AM, ***@yahoo.com.au [hercules-os380] <
hercules-***@yahoogroups.com> wrote:

>
>
> ---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :
>
> >>> LINK EP= doesn't work in AM64..
>
> >> Yes, but we can simply make our 64-bit AM64
> >> program switch to AM31 prior to doing a
> >> LINK EP=, and it will work fine on both z/OS
> >> and MVS/380.
>
> > I'm confused.
>
> Now I am too. :-) I'm not sure what your argument is.
>
> > When you use link or links,
>
> I assume you meant "linkx" not "links".
>
> > the linking program
> > does not determine the addresses for R14 and
> > R15.... the OS does that...
>
> The problem that I am addressing is not just
> R14 and R15. All registers can have crap in
> the top 32 bits and a 32 bit program which I
> have marked AM32/64/infinity has no
> knowledge of these top 32 bits, or even top
> 96 bits if AM128 ever becomes a reality.
>
> Someone needs to have knowledge of and
> clear those high bits. The fact that LINK
> doesn't do that automatically, even for say
> an AM31 program that happens to be using
> 64-bit registers for data, means that the
> called 32 bit program is in trouble because
> all the 32-bit addresses that it loads into
> 32-bit registers will be treated as 64-bit
> addresses with the crud in the top 32 bits
> wreaking havoc.
>
> > When you use the LINK or LINKX macro, it is
> > the control program that establishes the
> > values in registers 14 and 15...
>
> "control program" being z/OS sets R14 and R15,
> probably as full 64-bit values, that's fine.
>
> > The control program saves the address of the
> > location in your program in its own save area,
> > and places in register 14 the address of a
> > routine within the control program that will
> > receive control. Because control was passed
> > using the control program, return must also
> > be made using the control program. The control
> > program also handles all switching of addressing
> > mode when processing the LINK or LINKX macro.
>
> I think I understand that, but I don't think that is
> in disagreement with anything I have said.
>
> BFN. Paul.
>
>

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :

> Now I'm really confused :)

> The registers are stored in the save area, yes?

> So, if I link with "clean" registers stored in the
> save area, how will the registers become "dirty"
> upon return, since the save area is restored
> upon return?

No, I'm not expecting dirty registers on return.
The problem is the called program, not the
calling program.

> In other words, if I link to an AM31 program,
> and only execute AM31 or 24 instructions,
> what is going to pollute the top 32 bits of the
> registers stored in the caller's save area,
> since the AM31 or 24 instructions of the
> called program only use the bottom half of
> a 64bit register, and the caller's clean save
> area is restored upon return?

No, there's no problem there. The problem
only occurs if a program (any amode) uses
64-bit registers, putting (valid) data into the
top 32 bits, and then it calls an AM32
program, and the AM32 program knows
nothing about the high 32 bits, so it doesn't
clear them, so it loads a simple 32-bit
address, goes to use it, and *kapow*, that
crap in the top 32 bits just got used in an
address.

And this is all a problem because I am trying
to use the AM64 bit in the load module to
mean "AM-infinity".

This wouldn't be a problem on a normal
Unix/Windows system, because there is only
one type of 32-bit program and only one
type of 64-bit program, and you can do
something the equivalent of putting
SAM32 at the beginning of your 32-bit
programs and a SAM64 at the beginning
of your 64-bit programs, and everything
is fine.

A SAM32 instruction would in fact solve
the problem, which the AM32 program
can issue when it detects that it has been
started in AM64. But absent that instruction
I need to solve the problem a different way.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"A SAM32 instruction would in fact solve
the problem, which the AM32 program
can issue when it detects that it has been
started in AM64. But absent that instruction
I need to solve the problem a different way."

Which is where you missed this part:

"The control program also handles all switching of addressing mode when
processing the LINK or LINKX macro."

Joe

On Tue, Mar 13, 2018 at 5:39 AM, ***@yahoo.com.au [hercules-os380] <
hercules-***@yahoogroups.com> wrote:

>
>
> ---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :
>
> > Now I'm really confused :)
>
> > The registers are stored in the save area, yes?
>
> > So, if I link with "clean" registers stored in the
> > save area, how will the registers become "dirty"
> > upon return, since the save area is restored
> > upon return?
>
> No, I'm not expecting dirty registers on return.
> The problem is the called program, not the
> calling program.
>
> > In other words, if I link to an AM31 program,
> > and only execute AM31 or 24 instructions,
> > what is going to pollute the top 32 bits of the
> > registers stored in the caller's save area,
> > since the AM31 or 24 instructions of the
> > called program only use the bottom half of
> > a 64bit register, and the caller's clean save
> > area is restored upon return?
>
> No, there's no problem there. The problem
> only occurs if a program (any amode) uses
> 64-bit registers, putting (valid) data into the
> top 32 bits, and then it calls an AM32
> program, and the AM32 program knows
> nothing about the high 32 bits, so it doesn't
> clear them, so it loads a simple 32-bit
> address, goes to use it, and *kapow*, that
> crap in the top 32 bits just got used in an
> address.
>
> And this is all a problem because I am trying
> to use the AM64 bit in the load module to
> mean "AM-infinity".
>
> This wouldn't be a problem on a normal
> Unix/Windows system, because there is only
> one type of 32-bit program and only one
> type of 64-bit program, and you can do
> something the equivalent of putting
> SAM32 at the beginning of your 32-bit
> programs and a SAM64 at the beginning
> of your 64-bit programs, and everything
> is fine.
>
> A SAM32 instruction would in fact solve
> the problem, which the AM32 program
> can issue when it detects that it has been
> started in AM64. But absent that instruction
> I need to solve the problem a different way.
>
> BFN. Paul.
>
>

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :

>> A SAM32 instruction would in fact solve
>> the problem, which the AM32 program
>> can issue when it detects that it has been
>> started in AM64. But absent that instruction
>> I need to solve the problem a different way."

> Which is where you missed this part:

> The control program also handles all switching of
> addressing mode when processing the LINK
> or LINKX macro.

I think we're talking about different things. Let
me put it a different way.

Let's say we have AM32, AM64, AM128 and AM256
programs. Forget AM24 and AM31. Forget they
ever existed.

I think ideally we would have 4 separate PSW
bits for that, and the beginning of each application
program would have a SAM32/64/128/256
depending on what the author has coded. The
program author always knows whether he has
used 64/128/256 addresses in his application.

Unfortunately we don't have a SAM32 instruction.
Let's say that IBM had also omitted SAM64 and
SAM128 and gone straight to SAM256 because
new hardware became available, so we went
straight from 32-bit to 256 bit processing.

But now in an effort to combat global warming,
we have decided to dumb down 256-bit
registers to 128 or 64 or 32. What happens
when all these get mixed up, and we're lacking
the facilities for the programmer to restrict an
app to just 128 bit pointers?

I can see two solutions:

1. The LINK service saves the full 256 bits of
a register, and then zeroes out the top
256-32 bits, so any parameters passed between
applications must be done in RM32 space.

2. If the calling program happens to be 128
bits, it takes responsibility to save the top
128-32 bits of the address, then sets those
bits to 0, calls PROGB which will still operate
in AM256, but will have clean registers, so
that if it is say only a 64-bit program, only
the bottom 32 bits of registers will have
non-zero data in them. The top 128 bits will
not be cleared by PROGA but instead either
by the operating system or some program
above PROGA. PROGA only uses the
bottom 128 bits so is only responsible for
clearing 128-32 bits. That's all it has the
instructions for. The 256-bit instructions are
beyond the scope of PROGA. If our site
doesn't use any 256 bit programs we can
actually run on cheaper 128-bit hardware.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"But now in an effort to combat global warming,
we have decided to dumb down 256-bit
registers to 128 or 64 or 32. What happens
when all these get mixed up, and we're lacking
the facilities for the programmer to restrict an
app to just 128 bit pointers?"

You're conflating two topics. Addresses and registers. They are
independent.

You can have 128 bit registers on a machine that only supports 32 bit
memory addressing. Likewise, you can have 64 bit registers on a machine
that only supports 16 bit memory addresses.

Just because the VALUE that is pointed to by a pointer is 64 bits, doesn't
mean that the ADDRESS of that VALUE must also be 64 bits.

Joe

On Tue, Mar 13, 2018 at 6:32 AM, ***@yahoo.com.au [hercules-os380] <
hercules-***@yahoogroups.com> wrote:

>
>
> ---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :
>
> >> A SAM32 instruction would in fact solve
> >> the problem, which the AM32 program
> >> can issue when it detects that it has been
> >> started in AM64. But absent that instruction
> >> I need to solve the problem a different way."
>
> > Which is where you missed this part:
>
> > The control program also handles all switching of
> > addressing mode when processing the LINK
> > or LINKX macro.
>
> I think we're talking about different things. Let
> me put it a different way.
>
> Let's say we have AM32, AM64, AM128 and AM256
> programs. Forget AM24 and AM31. Forget they
> ever existed.
>
> I think ideally we would have 4 separate PSW
> bits for that, and the beginning of each application
> program would have a SAM32/64/128/256
> depending on what the author has coded. The
> program author always knows whether he has
> used 64/128/256 addresses in his application.
>
> Unfortunately we don't have a SAM32 instruction.
> Let's say that IBM had also omitted SAM64 and
> SAM128 and gone straight to SAM256 because
> new hardware became available, so we went
> straight from 32-bit to 256 bit processing.
>
> But now in an effort to combat global warming,
> we have decided to dumb down 256-bit
> registers to 128 or 64 or 32. What happens
> when all these get mixed up, and we're lacking
> the facilities for the programmer to restrict an
> app to just 128 bit pointers?
>
> I can see two solutions:
>
> 1. The LINK service saves the full 256 bits of
> a register, and then zeroes out the top
> 256-32 bits, so any parameters passed between
> applications must be done in RM32 space.
>
> 2. If the calling program happens to be 128
> bits, it takes responsibility to save the top
> 128-32 bits of the address, then sets those
> bits to 0, calls PROGB which will still operate
> in AM256, but will have clean registers, so
> that if it is say only a 64-bit program, only
> the bottom 32 bits of registers will have
> non-zero data in them. The top 128 bits will
> not be cleared by PROGA but instead either
> by the operating system or some program
> above PROGA. PROGA only uses the
> bottom 128 bits so is only responsible for
> clearing 128-32 bits. That's all it has the
> instructions for. The 256-bit instructions are
> beyond the scope of PROGA. If our site
> doesn't use any 256 bit programs we can
> actually run on cheaper 128-bit hardware.
>
> BFN. Paul.
>
>

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :

>> But now in an effort to combat global warming,
>> we have decided to dumb down 256-bit
>> registers to 128 or 64 or 32. What happens
>> when all these get mixed up, and we're lacking
>> the facilities for the programmer to restrict an
>> app to just 128 bit pointers?

> You're conflating two topics. Addresses and registers.
> They are independent.

Registers can be used as address registers, so
they're intertwined. And a 128-bit register that
was previously used for a value may subsequently
be used as a 64-bit address, so the high 64
bits need to be zeroed.

> You can have 128 bit registers on a machine
> that only supports 32 bit memory addressing.
> Likewise, you can have 64 bit registers on a
> machine that only supports 16 bit memory
> addresses.

And the reverse too - 64 bit address registers
but only 16-bit data registers. Theoretically,
anyway.

> Just because the VALUE that is pointed to by
> a pointer is 64 bits, doesn't mean that the
> ADDRESS of that VALUE must also be 64 bits.

Sure, but on the machines I posited, ie 256-bit
registers, 128-bit registers etc, a register can
be used for either data or an address, so if
PROGA has polluted high bits, they need to
be cleared by the time PROGB starts doing
*addressing*.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"Registers can be used as address registers, so
they're intertwined. And a 128-bit register that
was previously used for a value may subsequently
be used as a 64-bit address, so the high 64
bits need to be zeroed."

No.

If a 128-bit register contains a 32-bit address, only the rightmost 32 bits
will be used, the left 96 will be ignored. Likewise, if a 128-bit register
that previously held a value now contains a 64-bit address and the top 64
bits are dirty, still only the rightmost 64 bits will be looked at, under
the limitations of address arithmetic. The rest will be ignored.

This happens all the time in the mainframe, where the registers are 64bit
and addresses are 31/24 bit.

Joe

On Tue, Mar 13, 2018 at 7:22 AM, ***@yahoo.com.au [hercules-os380] <
hercules-***@yahoogroups.com> wrote:

>
>
> ---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :
>
> >> But now in an effort to combat global warming,
> >> we have decided to dumb down 256-bit
> >> registers to 128 or 64 or 32. What happens
> >> when all these get mixed up, and we're lacking
> >> the facilities for the programmer to restrict an
> >> app to just 128 bit pointers?
>
> > You're conflating two topics. Addresses and registers.
> > They are independent.
>
> Registers can be used as address registers, so
> they're intertwined. And a 128-bit register that
> was previously used for a value may subsequently
> be used as a 64-bit address, so the high 64
> bits need to be zeroed.
>
> > You can have 128 bit registers on a machine
> > that only supports 32 bit memory addressing.
> > Likewise, you can have 64 bit registers on a
> > machine that only supports 16 bit memory
> > addresses.
>
> And the reverse too - 64 bit address registers
> but only 16-bit data registers. Theoretically,
> anyway.
>
> > Just because the VALUE that is pointed to by
> > a pointer is 64 bits, doesn't mean that the
> > ADDRESS of that VALUE must also be 64 bits.
>
> Sure, but on the machines I posited, ie 256-bit
> registers, 128-bit registers etc, a register can
> be used for either data or an address, so if
> PROGA has polluted high bits, they need to
> be cleared by the time PROGB starts doing
> *addressing*.
>
> BFN. Paul.
>
>

[Joe Monk [e-mail] [hercules-os380]]

"so the high 64 bits need to be zeroed."

Can you imagine how many cycles would be wasted if CICS had to zero the
registers before every use? Nobody would use the system because it would be
dog slow.

That's why the first thing any CICS programmer learns is to move low-values
(hex 00) to the EIB before doing things like receive map, etc. Because
there WILL be "core trash" in there.

Joe

On Tue, Mar 13, 2018 at 7:29 AM, Joe Monk <***@gmail.com> wrote:

> "Registers can be used as address registers, so
> they're intertwined. And a 128-bit register that
> was previously used for a value may subsequently
> be used as a 64-bit address, so the high 64
> bits need to be zeroed."
>
> No.
>
> If a 128-bit register contains a 32-bit address, only the rightmost 32
> bits will be used, the left 96 will be ignored. Likewise, if a 128-bit
> register that previously held a value now contains a 64-bit address and the
> top 64 bits are dirty, still only the rightmost 64 bits will be looked at,
> under the limitations of address arithmetic. The rest will be ignored.
>
> This happens all the time in the mainframe, where the registers are 64bit
> and addresses are 31/24 bit.
>
> Joe
>
> On Tue, Mar 13, 2018 at 7:22 AM, ***@yahoo.com.au [hercules-os380]
> <hercules-***@yahoogroups.com> wrote:
>
>>
>>
>> ---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :
>>
>> >> But now in an effort to combat global warming,
>> >> we have decided to dumb down 256-bit
>> >> registers to 128 or 64 or 32. What happens
>> >> when all these get mixed up, and we're lacking
>> >> the facilities for the programmer to restrict an
>> >> app to just 128 bit pointers?
>>
>> > You're conflating two topics. Addresses and registers.
>> > They are independent.
>>
>> Registers can be used as address registers, so
>> they're intertwined. And a 128-bit register that
>> was previously used for a value may subsequently
>> be used as a 64-bit address, so the high 64
>> bits need to be zeroed.
>>
>> > You can have 128 bit registers on a machine
>> > that only supports 32 bit memory addressing.
>> > Likewise, you can have 64 bit registers on a
>> > machine that only supports 16 bit memory
>> > addresses.
>>
>> And the reverse too - 64 bit address registers
>> but only 16-bit data registers. Theoretically,
>> anyway.
>>
>> > Just because the VALUE that is pointed to by
>> > a pointer is 64 bits, doesn't mean that the
>> > ADDRESS of that VALUE must also be 64 bits.
>>
>> Sure, but on the machines I posited, ie 256-bit
>> registers, 128-bit registers etc, a register can
>> be used for either data or an address, so if
>> PROGA has polluted high bits, they need to
>> be cleared by the time PROGB starts doing
>> *addressing*.
>>
>> BFN. Paul.
>>
>>
>
>

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :

>> so the high 64 bits need to be zeroed.

> Can you imagine how many cycles would be
> wasted if CICS had to zero the registers
> before every use?

It only needs to be zeroed when EXEC PGM=CICS
is executed (under the proposed model for a
machine without appropriate SAM instructions).

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :

>> Registers can be used as address registers, so
>> they're intertwined. And a 128-bit register that
>> was previously used for a value may subsequently
>> be used as a 64-bit address, so the high 64
>> bits need to be zeroed.

> No.

> If a 128-bit register contains a 32-bit address, only
> the rightmost 32 bits will be used, the left 96 will be
> ignored.

That is only the case if you have a SAM32 instruction.
What if you are missing SAM64 and SAM128 and
SAM32 instructions?

> This happens all the time in the mainframe, where
> the registers are 64bit and addresses are 31/24 bit.

People who write AM24 and AM31 programs are
lucky that they have a way of doing the equivalent
of SAM24 and SAM31. People writing AM32
programs don't have a SAM32 instruction, so
some other solution is required.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"That is only the case if you have a SAM32 instruction.
What if you are missing SAM64 and SAM128 and
SAM32 instructions?"

Thats simple. You run in whatever address size the PSW says, all the time,
and you write your code accordingly.

Jeez, where have I seen that before? Oh yeah, just about every IBM 360 and
370 machine made...

Joe

On Tue, Mar 13, 2018 at 7:34 AM, ***@yahoo.com.au [hercules-os380] <
hercules-***@yahoogroups.com> wrote:

>
>
> ---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :
>
> >> Registers can be used as address registers, so
> >> they're intertwined. And a 128-bit register that
> >> was previously used for a value may subsequently
> >> be used as a 64-bit address, so the high 64
> >> bits need to be zeroed.
>
> > No.
>
> > If a 128-bit register contains a 32-bit address, only
> > the rightmost 32 bits will be used, the left 96 will be
> > ignored.
>
> That is only the case if you have a SAM32 instruction.
> What if you are missing SAM64 and SAM128 and
> SAM32 instructions?
>
> > This happens all the time in the mainframe, where
> > the registers are 64bit and addresses are 31/24 bit.
>
> People who write AM24 and AM31 programs are
> lucky that they have a way of doing the equivalent
> of SAM24 and SAM31. People writing AM32
> programs don't have a SAM32 instruction, so
> some other solution is required.
>
> BFN. Paul.
>
>

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :

>> That is only the case if you have a SAM32 instruction.
>> What if you are missing SAM64 and SAM128 and
>> SAM32 instructions?"

> Thats simple. You run in whatever address size the
> PSW says, all the time, and you write your code
> accordingly.

How does an application do a BSM to set an
address size of:

1. 32
2. 64
3. 128
4. 256

There was only one bit available, and we are very
lucky that someone at IBM found it at all. It was
very clever of them to use the bottom bit.

But that 1 bit necessarily means "infinity", aka 256
if you're on a 256-bit machine.

BFN. Paul.

[[e-mail] [hercules-os380]]

I'm trying to understand why we have this
situation on the mainframe but not on
Windows and Unix as far as I know.

MSDOS had DOS-extenders, and I don't
see any barrier to having both 32-bit and
64-bit DOS extenders.

But the key is that application and extended
operating system are always in synch. ie if
you wish to write a 64-bit program you will
need a 64-bit DOS extender. There is no
concept of needing to step down the
application because the application is more
advanced than the OS itself.

Having to surround a call to READ with a
GAMOS/GAMAPP wrapper is very odd.
They could have done exactly that instead
the READ code themselves.

But I'm still uncertain about this. I haven't
yet reconciled the difference between the
mainframe and Unix/Windows.

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> But I'm still uncertain about this. I haven't
> yet reconciled the difference between the
> mainframe and Unix/Windows.

What would the situation be if the first IBM
mainframe was AM32 and then a couple of
decades later 64-bit support was added?
But 64-bit applications were not written
until *after* (radical!) the OS had been
updated to fully support 64-bit.

I'm guessing that there would have been a
separate SYS1.MACLIB64 to pick up the
new READ etc macros that generated
64-bit instructions? Or would that be
governed by an assembler option MODE64
that the READ etc macros recognized?

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"I haven't
> yet reconciled the difference between the
> mainframe and Unix/Windows."

Really? it is called the PSW...

PC's dont have a PSW, mainframes do. Thus it is possible to do things on
the mainframe by manipulating the PSW that can't be done on the PC.

Joe

On Tue, Mar 13, 2018 at 8:32 AM, ***@yahoo.com.au [hercules-os380] <
hercules-***@yahoogroups.com> wrote:

>
>
> ---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :
>
> > But I'm still uncertain about this. I haven't
> > yet reconciled the difference between the
> > mainframe and Unix/Windows.
>
> What would the situation be if the first IBM
> mainframe was AM32 and then a couple of
> decades later 64-bit support was added?
> But 64-bit applications were not written
> until *after* (radical!) the OS had been
> updated to fully support 64-bit.
>
> I'm guessing that there would have been a
> separate SYS1.MACLIB64 to pick up the
> new READ etc macros that generated
> 64-bit instructions? Or would that be
> governed by an assembler option MODE64
> that the READ etc macros recognized?
>
> BFN. Paul.
>
>

['Dave Wade' [e-mail] [hercules-os380]]

Joe,



I think you are over simplifying things. IMHO the main difference between mainframe and PC is that Mainframe I/O is conceptualised, externalised, and formalized.



As for why does code work differently, well on Z 32 and 64 bit programs can still use the same interfaces. Any program can issue an SVC and it will behave in the same way.

On the PC platform this doesn’t happen. New interfaces which are only callable in the new address mode were defined.



Dave





From: hercules-***@yahoogroups.com <hercules-***@yahoogroups.com>
Sent: 13 March 2018 14:48
To: hercules-***@yahoogroups.com
Subject: Re: [hercules-os380] MVS/380 fundamentals








"I haven't
> yet reconciled the difference between the
> mainframe and Unix/Windows."



Really? it is called the PSW...



PC's dont have a PSW, mainframes do. Thus it is possible to do things on the mainframe by manipulating the PSW that can't be done on the PC.



Joe



On Tue, Mar 13, 2018 at 8:32 AM, ***@yahoo.com.au <mailto:***@yahoo.com.au> [hercules-os380] <hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> > wrote:



---In hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> , <***@yahoo.com.au <mailto:***@yahoo.com.au> > wrote :

> But I'm still uncertain about this. I haven't
> yet reconciled the difference between the
> mainframe and Unix/Windows.

What would the situation be if the first IBM
mainframe was AM32 and then a couple of
decades later 64-bit support was added?
But 64-bit applications were not written
until *after* (radical!) the OS had been
updated to fully support 64-bit.

I'm guessing that there would have been a
separate SYS1.MACLIB64 to pick up the
new READ etc macros that generated
64-bit instructions? Or would that be
governed by an assembler option MODE64
that the READ etc macros recognized?

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"On the PC platform this doesn’t happen. New interfaces which are only
callable in the new address mode were defined."

Not totally true. Interfaces can be thunked to operate in different modes :)

Only computers that are meant for multitasking have a concept like a PSW.

Windows is meant for 1 user at a time. MVS is meant for 1000's of users at
a time.

Joe

On Tue, Mar 13, 2018 at 1:25 PM, 'Dave Wade' ***@gmail.com
[hercules-os380] <hercules-***@yahoogroups.com> wrote:

>
>
> Joe,
>
>
>
> I think you are over simplifying things. IMHO the main difference between
> mainframe and PC is that Mainframe I/O is conceptualised, externalised, and
> formalized.
>
>
>
> As for why does code work differently, well on Z 32 and 64 bit programs
> can still use the same interfaces. Any program can issue an SVC and it will
> behave in the same way.
>
> On the PC platform this doesn’t happen. New interfaces which are only
> callable in the new address mode were defined.
>
>
>
> Dave
>
>
>
>
>
> *From:* hercules-***@yahoogroups.com <hercules-***@yahoogroups.com>
> *Sent:* 13 March 2018 14:48
> *To:* hercules-***@yahoogroups.com
> *Subject:* Re: [hercules-os380] MVS/380 fundamentals
>
>
>
>
>
>
> "I haven't
> > yet reconciled the difference between the
> > mainframe and Unix/Windows."
>
>
>
> Really? it is called the PSW...
>
>
>
> PC's dont have a PSW, mainframes do. Thus it is possible to do things on
> the mainframe by manipulating the PSW that can't be done on the PC.
>
>
>
> Joe
>
>
>
> On Tue, Mar 13, 2018 at 8:32 AM, ***@yahoo.com.au [hercules-os380]
> <hercules-***@yahoogroups.com> wrote:
>
>
>
> ---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :
>
> > But I'm still uncertain about this. I haven't
> > yet reconciled the difference between the
> > mainframe and Unix/Windows.
>
> What would the situation be if the first IBM
> mainframe was AM32 and then a couple of
> decades later 64-bit support was added?
> But 64-bit applications were not written
> until *after* (radical!) the OS had been
> updated to fully support 64-bit.
>
> I'm guessing that there would have been a
> separate SYS1.MACLIB64 to pick up the
> new READ etc macros that generated
> 64-bit instructions? Or would that be
> governed by an assembler option MODE64
> that the READ etc macros recognized?
>
> BFN. Paul.
>
>
>
>
>
>
>
>

['Dave Wade' [e-mail] [hercules-os380]]

Joe



Windows/NT, from which Windows/XP, Windows/7 and Windows/2000 is directly descended was largely designed by Dave Cutler who was one of the designers of DECs VMS. Microsoft poached him from Digital. So in many senses it can be said to be descended from VMS. Whilst on the end user versions there is only one console its as “multi-user” under the covers as MVS, perhaps more so. Its not exposed to the typical user but at the simplest level the RUNAS command can be used to start several commands prompts each with different credentials. There has been a simple telnet server in the server versions since NT4. The current Windows/2000 Pro has an SSH server. Both are multi-user. Server versions of windows do allow multiple sessions via “remote desktop protocol.” The number of sessions is limited unless you by a “terminal server licence”. Just as IBM limit the code you can run on its specialist servers. Microsoft generally hide this from the user, possibly to sell more licences but it did introduce “Fast User Switching” at Windows/7. It only actually switches the display, the background users programs continue to run.



Thunking across the 64/32/16 bit boundary isn’t available to applications, you are basically stuck in one mode and the protection levels won’t let you change. No such thing as switching mode like you can do on MVS which also means you don’t need to worry about save area sizes, it just works




... and whilst there isn’t a PSW there are equivalent control registers



Dave





From: hercules-***@yahoogroups.com <hercules-***@yahoogroups.com>
Sent: 13 March 2018 23:39
To: hercules-***@yahoogroups.com
Subject: Re: [hercules-os380] MVS/380 fundamentals








"On the PC platform this doesn’t happen. New interfaces which are only callable in the new address mode were defined."



Not totally true. Interfaces can be thunked to operate in different modes :)



Only computers that are meant for multitasking have a concept like a PSW.



Windows is meant for 1 user at a time. MVS is meant for 1000's of users at a time.



Joe



On Tue, Mar 13, 2018 at 1:25 PM, 'Dave Wade' ***@gmail.com <mailto:***@gmail.com> [hercules-os380] <hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> > wrote:



Joe,



I think you are over simplifying things. IMHO the main difference between mainframe and PC is that Mainframe I/O is conceptualised, externalised, and formalized.



As for why does code work differently, well on Z 32 and 64 bit programs can still use the same interfaces. Any program can issue an SVC and it will behave in the same way.

On the PC platform this doesn’t happen. New interfaces which are only callable in the new address mode were defined.



Dave





From: hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> <hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> >
Sent: 13 March 2018 14:48
To: hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com>
Subject: Re: [hercules-os380] MVS/380 fundamentals







"I haven't
> yet reconciled the difference between the
> mainframe and Unix/Windows."



Really? it is called the PSW...



PC's dont have a PSW, mainframes do. Thus it is possible to do things on the mainframe by manipulating the PSW that can't be done on the PC.



Joe



On Tue, Mar 13, 2018 at 8:32 AM, ***@yahoo.com.au <mailto:***@yahoo.com.au> [hercules-os380] <hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> > wrote:



---In hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> , <***@yahoo.com.au <mailto:***@yahoo.com.au> > wrote :

> But I'm still uncertain about this. I haven't
> yet reconciled the difference between the
> mainframe and Unix/Windows.

What would the situation be if the first IBM
mainframe was AM32 and then a couple of
decades later 64-bit support was added?
But 64-bit applications were not written
until *after* (radical!) the OS had been
updated to fully support 64-bit.

I'm guessing that there would have been a
separate SYS1.MACLIB64 to pick up the
new READ etc macros that generated
64-bit instructions? Or would that be
governed by an assembler option MODE64
that the READ etc macros recognized?

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :

> As for why does code work differently, well on
> Z 32 and 64 bit programs can still use the same
> interfaces. Any program can issue an SVC and
> it will behave in the same way.
> On the PC platform this doesn’t happen. New
> interfaces which are only callable in the new
> address mode were defined.

What is the underlying reason that the PC defined
new 64-bit interfaces instead of using the old
32-bit interfaces?

Is it because registers are pushed on the stack
and thus occupy a well-defined amount of space,
rather than doing what MSDOS did which was
to use registers, and there would have been
nothing preventing a 32-bit or 64-bit version of
MSDOS being created if they had continued
using this interface?

Is there any other way the interfaces could have
distinguished between a 32-bit and 64-bit caller?

Actually, I'm not sure it's true to say that z/OS
supports the same interface for 32-bit and 64-bit
callers. They really haven't supported 64-bit
callers at all. When it comes time to call READ
you must drop down to one of the 32-bit modes
yourself, because only a 32-bit interface exists.

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> Is it because registers are pushed on the stack
> and thus occupy a well-defined amount of space,
> rather than doing what MSDOS did which was
> to use registers, and there would have been
> nothing preventing a 32-bit or 64-bit version of
> MSDOS being created if they had continued
> using this interface?

I just realized that PDOS/386 only works because
I require all applications to be 32-bit as well.

Even if we forget about 16-bit programming, if I
create a PDOS/x64, then I am not sure what I
should do if I want to support both 32-bit and
64-bit applications.

Normally I would just tell everyone to build
64-bit versions of all their applications, but if
I theoretically wanted to support a 32-bit
API using registers like eax, as opposed to
the 64-bit API of the same interrupt using
extended registers - I don't know what they
are called - qax maybe? fax? - what do I
need to do? When loading the executable
I can presumably detect whether it has been
marked as 32-bit or 64-bit and then whenever
I get an API call I know whether to truncate
the register or not.

The other thing I could do is whenever a
64-bit program does a system() to a 32-bit
program, the system() process clears the
top 32 bits, so that 32-bit programs are in
fact able to use the 64-bit interface.

ie the exact same consideration as z/OS.

If system() doesn't clear the registers, then
the onus is on the 64-bit application to clear
the high 32 bits before calling system(). We
could actually say that both things should
always be done, ie a 64-bit program should
not rely on system() clearing the high 32 bits,
and also system() is actually designed to
clear the high 32 bits.

Actually the system() call is INT 21H 4BH,
called "exec".

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> Even if we forget about 16-bit programming, if I
> create a PDOS/x64,

Actually, how about - we can still support 16-bit
programming, so long as it is a genuine 16-bit
application, ie code, data and stack must fit
into 64k. ie the tiny model I believe that is, and
most utilities can probably fit into that.

While we are rewriting history, at the point that
people were writing single programs that
exceeded the 16-bit limit of 64k, they should
have switched to a 32-bit processor and OS.

With the benefit of hindsight, people should
have been warned to only write tiny mode
MSDOS programs, with an "MZ" signature
in the first 2 bytes, and the 4 bytes at offset
0x80 should be set to 0, so that a "PE"
signature is not accidentally set there.

I think a tiny mode MSDOS program will
happily run on a 64-bit machine and the
machine will not even know the difference.

If we can bed down that technology, that
would be great, as I'd love to be able to
run 16-bit programs instead of being
forced to 32 when programs like hexdump
don't need 32-bit integers.

Actually, can I also run 16-bit MVS load
modules? ie can GCC theoretically emit
instructions that assume int = 16 bit so
that I can have smaller modules? I think so!
Can I also have 16-bit addresses? I think
GCC can generate that too! And can I
force the issue by making a BSM to x'01'
set an AMODE of 16 instead of 64 if so
configured, so that my 16-bit MVS load
modules don't need to keep clearing the
top 16 bits of the register after it has had
crap put in it by use of "long" variables?

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> GCC can generate that too! And can I
> force the issue by making a BSM to x'01'
> set an AMODE of 16 instead of 64 if so
> configured, so that my 16-bit MVS load
> modules don't need to keep clearing the
> top 16 bits of the register after it has had
> crap put in it by use of "long" variables?

If I start doing that, then I think I need to change
Peppe's test program to check that the 24-bit
test is done by ensuring the high bit in a
24-bit address is actually 1. If it isn't, then
we're in 16-bit mode and BSMs are still
required to switch in and out of 24-bit vs
16-bit. And GETMAIN will need to check if a
request for memory is actually AM24 or AM16
and only return 16-bit memory if we're actually
running AM16. The same way that it will only
return RM31 memory for a LOC=31 request if
the program is actually running AM31.

BFN. Paul.

[[e-mail] [hercules-os380]]

Any time a module with AM64=infinity is loaded,
if the size is less than 64k it should be loaded
into the first 64k of virtual memory.

That way a more efficient 16-bit hexdump can
be located there.

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> Any time a module with AM64=infinity is loaded,

It's not infinity, it is "user-defined". The user may
define it as meaning 16 or they may define it to
mean infinity. Programs should adapt by testing
to see what bits are being cleared when you do
a BSM to x'01'.

Here is a revised test for Peppe's program, which
emphasizes the bits that are being tested:

* If we are running in a pure 24-bit environment, where
* the AMODE and RMODE are the same, there is no need to
* ever do AMODE switching, so none of this AMODE
* switching code is required at all
*
L R2,=X'C1800000'
LA R2,0(,R2)
CLM R2,B'1100',=X'0080'
* If we are currently in AM24, there is nothing
* to ever do, as we will stay in that mode forever
BE RETURNSU
*
* Now see if we are running AM31
CLM R2,B'1000',=X'41'
BNE IS32


Note that the "IS32" is a misnomer, so I have
updated the comments here:

* Note that we say "32" here, but it is actually
* any value other than 24 or 31.
IS32 DS 0H


BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> It's not infinity, it is "user-defined". The user may
> define it as meaning 16 or they may define it to
> mean infinity.

And to reduce global warming, we should spend
the rest of eternity converting C programs to 16-bit
8086 assembler. But keep the C version handy
in case an enhancement is needed to hexdump etc.
Actually, the code generation is probably good
enough already that we just need to strip the
runtime library down or use an intelligent linker.
Every time an assembler programmer spots a
code improvement, we could actually modify
the compiler every time.

BFN. Paul.

[[e-mail] [hercules-os380]]

The tiny memory model is described here:

https://en.wikipedia.org/wiki/Intel_Memory_Model

with CS=SS=DS=ES

which is the same as modern 32-bit and 64-bit
Windows, or so I have been told.

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> And to reduce global warming, we should spend
> the rest of eternity converting C programs to 16-bit
> 8086 assembler.

The 16-bit 8086 C/assembler programs will all be
running under 24-bit MVS/380 of course. And
31-bit programming will still be supported too,
for programs that have a genuine need.

I'm guessing we should demand that 16-bit programs
stop relying on the top 16 bits of registers being
ignored in addressing, so that we can set the
AM64 bit to mean infinity instead of 16.

ie when addresses are loaded into registers,
people need to so a SLR Rx,Rx, ICM B'0011'
rather than doing a lazy LH which will propagate
the top bit so that the top 16 bits potentially
become b'1'. I guess if people are willing to
restrict their programs to 32K of data+code+
stack they can use LH when doing S/380
programming.

Back to 8086, I'm not sure why we need the
tiny memory model. I don't see why all 4
segment registers can't have their own
values, all 64k apart so that you end up with
a module that uses 256KB. That trick wouldn't
work for S/370 though, unless there were
hardware changes.

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> And to reduce global warming, we should spend
> the rest of eternity converting C programs to 16-bit
> 8086 assembler.

Or perhaps simply compiling with every 16-bit
compiler available (Open Watcom, Turbo C,
Microsoft C, SDCC) to find which one produces
the tightest code. Note that it is not necessary
for the compiler itself to be a 16-bit animal, it
is only necessary that it produces such code.

And from the mainframe side, I guess I can
find out how to produce 16-bit modules at the
same time as I figure out how to produce
64-bit modules. And the different 64-bitness
and 16-bitness should be variable, e.g.
mixing 16-bit addresses with 64-bit longs.

BFN. Paul.

[[e-mail] [hercules-os380]]

Could a 16-bit S/370 module have any genuine
expectation that if invoked with:

EXEC PGM=XXX

that the top 16-bits of each register are zero
at entry, so that it doesn't need to be aware
of 32-bit registers at all? Even the "long"
variable could be implemented as a reference
to storage rather than ever using more than
the bottom 16 bits of any register, even when
running on hardware with 64 bit registers.

BFN. Paul.

[[e-mail] [hercules-os380]]

Let me try a different question.

Given that Windows will call an application with
CS=DS=SS=ES, how can I write a 16-bit
application to run under Windows?

And is it possible for me to run that 16-bit
application under MSDOS, or if not MSDOS,
then at least PDOS/86?

I have been inspecting the 16-bit modules that
I create with PDPCLIB and they are all large
model and manipulate ds.

I am looking to create a universal 16-bit
executable. Determining how to do this on
x86 may help in determining best practices
for S/3x0.

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> I am looking to create a universal 16-bit
> executable. Determining how to do this on
> x86 may help in determining best practices
> for S/3x0.

I have looked at PDOS/86 code to see how
MSDOS executables work.

It looks like there is a 256-byte "PSP" allocated
just before the program code begins. So if your
entry point is the first bit of code, it will be at
address 0x100.

cs, ds and es all seem to point to that PSP, and
it looks like ss can be configured (in the
executable) to point to that too.

So it looks to me like these tiny mode applications
should be loadable by Windows, and even if
Microsoft refuses to do that, I should be able to
make PDOS/386 and even PDOS/x64 do that.

But there might be a problem if PROGA calls
PROGB when PROGA is 32-bit and PROGB
is 16-bit. The read etc routines will need to know
when to use a full 32-bit ecx like this:

regsin.d.ecx = (unsigned int)bytes;

and when to use a 16-bit cx like this:

regsin.x.cx = (unsigned int)bytes;

for the length of a read. The application clearly
knows this because it is coded one way or the
other, but without using a different API call
(in this case I am using INT 21H AH=3FH),
the operating system may get confused.

Given the fact that it needs to be coded
differently for 16-bit vs 32-bit, it may make
more sense to use a different API, e.g.
keep the AH the same but use INT 22H
instead of INT 21H.

The equivalent of this on S/370 is that the
READ macro should probably be generating
LGR instead of LR. The fact that IBM is not
doing this (as far as I know) is preventing load
modules from being properly 64-bit in the first
place. They're really still a hybrid 32/64 using
32-bit registers in places that it would make
more sense to use 64-bit registers. Maybe
IBM needs a READX macro or something
to be a separate API just like the PC is
rumored to be.

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> So it looks to me like these tiny mode applications
> should be loadable by Windows, and even if
> Microsoft refuses to do that, I should be able to
> make PDOS/386 and even PDOS/x64 do that.

Or more importantly, I should be able to make
Hercules/380 and MVS/380 do that.

BFN. Paul.

[[e-mail] [hercules-os380]]

With regard to the question of moving from
16-bit registers to 32-bit registers rather than
using segmentation, in the year 2000 I was
working at a company using Z80 processors
because they were extremely cheap, but
they had more than 64 KB of memory so
had some sort of banking mechanism. I
can't remember the details, but it was
something like the operating system
occupied 16 KB and the lower 48 KB was
for applications to reside and the data
pointed to different memory locations so
you needed to choose what you wanted.

Basically the moral of the story is that you
can't necessarily go directly from 16-bit
registers to 32-bit registers because of
the price of CPUs.

But given that the applications had to fit
into 64k anyway, I don't think there is
any issue. 64k is 16-bit programming and
that is something that should be able to be
supported, even if large memory model
segmented memory is not.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

The Z80 used bank switching ... could support up to 8 banks of 64K IIRC.
There were 3 address select lines on the processor which could be used to
select a bank of 64K to be switched in.

BTW, Z80 is 8-bit ... Z8000 was its 16-bit big brother.

Joe

On Wed, Mar 14, 2018 at 6:48 AM, ***@yahoo.com.au [hercules-os380] <
hercules-***@yahoogroups.com> wrote:

>
>
> With regard to the question of moving from
> 16-bit registers to 32-bit registers rather than
> using segmentation, in the year 2000 I was
> working at a company using Z80 processors
> because they were extremely cheap, but
> they had more than 64 KB of memory so
> had some sort of banking mechanism. I
> can't remember the details, but it was
> something like the operating system
> occupied 16 KB and the lower 48 KB was
> for applications to reside and the data
> pointed to different memory locations so
> you needed to choose what you wanted.
>
> Basically the moral of the story is that you
> can't necessarily go directly from 16-bit
> registers to 32-bit registers because of
> the price of CPUs.
>
> But given that the applications had to fit
> into 64k anyway, I don't think there is
> any issue. 64k is 16-bit programming and
> that is something that should be able to be
> supported, even if large memory model
> segmented memory is not.
>
> BFN. Paul.
>
>

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :

> The Z80 used bank switching ... could support
> up to 8 banks of 64K IIRC. There were 3 address
> select lines on the processor which could be used
> to select a bank of 64K to be switched in.

I see. So able to access 512K. And the Commodore 128
extended the Commodore 64 to 128 KB, presumably
the same way. I think the Commodore 64 used a 6510
processor which was supposed to be near-identical
to the 6502.

I'm guessing that at the place using Z80 they had
the operating system residing in every 64k bank.
Or maybe it was on ROM, overriding the memory.

> BTW, Z80 is 8-bit ... Z8000 was its 16-bit big brother.

Ok, I'm pretty sure it was Z80 that was being used.
I can remember asking why we couldn't have a flat
address space and I was told that we were buying
Z80s incredibly cheaply, like $1 each.

Anyway, I guess when we defined a "short" in our
C code that the value was being stored in memory
rather than in a register.

BFN. Paul.

[[e-mail] [hercules-os380]]

Where does the 68000 fit into things:

https://en.wikipedia.org/wiki/Motorola_68000

The wiki says that it has a 16-bit ALU and a
16-bit data bus.

But as a programmer I don't think I care about
that. So long as it uses 32-bit instructions and
a flat address space, I don't need to stuff
around with anything.

Basically I would have been happy if people had
gone from 16-bit 8086 writing only tiny memory
model programs to 32/16-bit 80386SX instead
of jumping to a too-expensive 80386.

I've also taken a look at the

https://en.wikipedia.org/wiki/Commodore_128

It uses an 8502 and banks two 64k banks.
And again the 64k banks means that we
have a simple programming model that
could potentially exist on a S/370 too,
and as an 8086-style module running
under MVS/380.

BFN. Paul.

[Mike Schwab [e-mail] [hercules-os380]]

The ESA/390 access register would give your 2GiB per access register in use.

On Wed, Mar 14, 2018 at 8:07 AM, ***@yahoo.com.au
[hercules-os380] <hercules-***@yahoogroups.com> wrote:
> Where does the 68000 fit into things:
>
> https://en.wikipedia.org/wiki/Motorola_68000
>
> The wiki says that it has a 16-bit ALU and a
> 16-bit data bus.
>
> But as a programmer I don't think I care about
> that. So long as it uses 32-bit instructions and
> a flat address space, I don't need to stuff
> around with anything.
>
> Basically I would have been happy if people had
> gone from 16-bit 8086 writing only tiny memory
> model programs to 32/16-bit 80386SX instead
> of jumping to a too-expensive 80386.
>
> I've also taken a look at the
>
> https://en.wikipedia.org/wiki/Commodore_128
>
> It uses an 8502 and banks two 64k banks.
> And again the 64k banks means that we
> have a simple programming model that
> could potentially exist on a S/370 too,
> and as an 8086-style module running
> under MVS/380.
>
> BFN. Paul.
>
>
> ------------------------------------
> Posted by: ***@yahoo.com.au
> ------------------------------------
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

['Bill Turner, WB4ALM' [e-mail] [hercules-os380]]

Be carefull when reading just the CPU HARDWARE specs. They do not tell
the full story.

I have programmed motorola 6809 systems that had "many" banks of memory,
by using a "write only" memory technique to control
bank selection.

1. Many of the Motorola 68 hundred and 68 thousand CPU's did their IO by
reading and writing to device specific single memory addresses  (not an
"I/O port" address as defined in the Intel chips).

2. Several vendors made use of an extended bus structure that had extra
address select lines running in parallel to the normal 16 bit address
bus that was controlled directly by CPU controlled. This extended set of
address lines had their binary states established from the output of set
of 16 4-bit hardware registers.  Since by cpu design a system ROM had to
exist in high memory (FFFF and down...) the memory address space
occupied by the read-only ROM was also used to control some of these
unique "write only" registers.

In the system I worked on, we had "20-bit addresses" being controlled by
a 16-bit address CPU.  Obviously the extra 4-bits were primarily used to
control which bank of 64K memory was currently being addressed.  One of
the banks was reserved for the operating system, and was therefore
protected from application read or write activity.  Since these bank
switching registers were only accessible when you were using the
"operating system banked memory", unauthorized changes were virtually
impossible to create.

I have seen a similar technique used in other hardware systems to
greatly expand the amount of physical memory that could be accessed from
a relatively "small" address bus.  Some of these same systems used
memory bus overlap and Direct Memory Access techniques to "swap"
memory.    Gee, I wonder if this is was an early form of Hardware DAT
translation and Virtual memory?


/s/ Bill Turner, wb4alm




On 03/14/2018 09:07 AM, ***@yahoo.com.au [hercules-os380] wrote:
>
> Where does the 68000 fit into things:
>
> https://en.wikipedia.org/wiki/Motorola_68000
>
> The wiki says that it has a 16-bit ALU and a
> 16-bit data bus.
>
> But as a programmer I don't think I care about
> that. So long as it uses 32-bit instructions and
> a flat address space, I don't need to stuff
> around with anything.
>
> Basically I would have been happy if people had
> gone from 16-bit 8086 writing only tiny memory
> model programs to 32/16-bit 80386SX instead
> of jumping to a too-expensive 80386.
>
> I've also taken a look at the
>
> https://en.wikipedia.org/wiki/Commodore_128
>
> It uses an 8502 and banks two 64k banks.
> And again the 64k banks means that we
> have a simple programming model that
> could potentially exist on a S/370 too,
> and as an 8086-style module running
> under MVS/380.
>
> BFN. Paul.
>
>

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

>> So it looks to me like these tiny mode applications
>> should be loadable by Windows, and even if
>> Microsoft refuses to do that, I should be able to
>> make PDOS/386 and even PDOS/x64 do that.

> Or more importantly, I should be able to make
> Hercules/380 and MVS/380 do that.

Although Hercules/380 loading a 16-bit 8086
executable will be very different from PDOS/x64
loading a 16-bit 8086 executable. The Hercules
one will be running in EBCDIC and returning
control to Hercules and MVS to do I/O. It will
not be an executable that can run under any
normal x86 system.

Although maybe I could change PDOS/x86
to start running those special MVS 8086
executables.

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

>> So it looks to me like these tiny mode applications
>> should be loadable by Windows, and even if
>> Microsoft refuses to do that, I should be able to
>> make PDOS/386 and even PDOS/x64 do that.

> Or more importantly, I should be able to make
> Hercules/380 and MVS/380 do that.

No, it won't work on Hercules/380. It is a 32-bit
Windows application, and my intention is to
make EBCDIC executables an extension of
that Hercules executable. That means they
will be loaded by MVS/380 into Hercules
memory, and they will need to live with
whatever segment registers Hercules is using.

So the addresses that the EBCDIC executables
will be executing at will be much bigger than
64k, thus beyond the range of 16-bit addressing.

That can be a selling point of PDOS/386 though.
It can handle 16-bit EBCDIC 8086 executables as
well as 32-bit EBCDIC 80386 executables.

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

>> That can be a selling point of PDOS/386 though.
>> It can handle 16-bit EBCDIC 8086 executables as
>> well as 32-bit EBCDIC 80386 executables.

> Actually, I should be able to write a Windows
> DLL that provides an MVS-style I/O paradigm
> such that these special 80386 EBCDIC
> executables can operate under normal Windows,
> MVS/380 and PDOS/386.

Is it technically possible to put a 16-bit program
inside a Windows PE executable? Or some
other sort of executable that Windows 10 is
willing to load?

What about Linux - does it allow the concept of
loading and executing a 16-bit executable?

If there is some accepted form of 16-bit
executables, I could make PDOS/86 recognize
that as well as MSDOS-style.

And I'd still like to know if MVS can load and
execute some sort of 16-bit load module.

BFN. Paul.

[[e-mail] [hercules-os380]]

Does it make sense to take PDOS/x86 all the
way back to the Intel 8080 with 8-bit registers
which was a predecessor to the 8086? I just
read about that here:

https://en.wikipedia.org/wiki/Intel_8080

I would have thought it was impossible for
me to do anything sensible with PDOS when
the whole computer can only address 64K.

Was the mainframe ever in this situation of
8 bit registers and 64K total addressability?

BFN. Paul.

[Gerhard Postpischil [e-mail] [hercules-os380]]

On 3/14/2018 11:57 AM, ***@yahoo.com.au [hercules-os380] wrote:
> Was the mainframe ever in this situation of
> 8 bit registers and 64K total addressability?
Not quite. IBM started with 36 bit registers (IBM 701) and 2K words (CRT
memory), later 4K word core storage, and had a 6-bit byte.

But unlike Intel with its 4-bit shift for additional memory addressing
(!), IBM allowed 15 addressing bits even though their early machines
didn't use all of them.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

[Gerhard Postpischil [e-mail] [hercules-os380]]

On 3/14/2018 3:29 AM, ***@yahoo.com.au [hercules-os380] wrote:
> Could a 16-bit S/370 module have any genuine
> expectation that if invoked with:
>
> EXEC PGM=XXX
>
> that the top 16-bits of each register are zero
> at entry, so that it doesn't need to be aware
> of 32-bit registers at all? Even the "long"
> variable could be implemented as a reference
> to storage rather than ever using more than
> the bottom 16 bits of any register, even when
> running on hardware with 64 bit registers.
When a program is invoked, you are guaranteed only the contents of
register 1 (PARM), 13 (TCB-linked save area), 14 (return address), and
15 (entry address). Other registers contain initiator (PGM=) or other
program data (LINK, ATTACH, XCTL, etc.)


Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@charter.net> wrote :

> When a program is invoked, you are guaranteed only the contents of
> register 1 (PARM), 13 (TCB-linked save area), 14 (return address), and
> 15 (entry address). Other registers contain initiator (PGM=) or other
> program data (LINK, ATTACH, XCTL, etc.)

Thanks. Well, in the general case, it is unreasonable
for an AM64 program to be expected to know about
256-bit registers and clear them itself. It doesn't know
the instruction to do so. So it really needs AM64 to be
treated as AM64 to allow truncation. Which means
we also need bits in the load module for AM32 and
AM128, unless the specifications for program
invocation are changed, at least in MVS/380.

Back in the S/360 days when there was an AM32
(PSW bit 4), how was that signified in the load module?

Thanks. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"Having to surround a call to READ with a
GAMOS/GAMAPP wrapper is very odd.
They could have done exactly that instead
the READ code themselves."

No.

One of IBM's biggest selling points is "forward compatibility". That means
you take ALC code from an IBM 360 and run it unmodified on a z/Arch box.

Try doing that on a PC. All of that support for DOS stuff has been dropped
(command prompt for powershell, etc).

Joe

On Tue, Mar 13, 2018 at 8:19 AM, ***@yahoo.com.au [hercules-os380] <
hercules-***@yahoogroups.com> wrote:

>
>
> I'm trying to understand why we have this
> situation on the mainframe but not on
> Windows and Unix as far as I know.
>
> MSDOS had DOS-extenders, and I don't
> see any barrier to having both 32-bit and
> 64-bit DOS extenders.
>
> But the key is that application and extended
> operating system are always in synch. ie if
> you wish to write a 64-bit program you will
> need a 64-bit DOS extender. There is no
> concept of needing to step down the
> application because the application is more
> advanced than the OS itself.
>
> Having to surround a call to READ with a
> GAMOS/GAMAPP wrapper is very odd.
> They could have done exactly that instead
> the READ code themselves.
>
> But I'm still uncertain about this. I haven't
> yet reconciled the difference between the
> mainframe and Unix/Windows.
>
> BFN. Paul.
>
>

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :

>> Having to surround a call to READ with a
>> GAMOS/GAMAPP wrapper is very odd.
>> They could have done exactly that instead
>> the READ code themselves.

> No.

> One of IBM's biggest selling points is "forward
> compatibility". That means you take ALC code
> from an IBM 360 and run it unmodified on a z/Arch box.

I have no idea why you think IBM couldn't have
put a BSM inside the READ code (ie the OS
code, not the macro) instead of requiring an
application programmer to code that instead.

It would not have broken forward compatibility.

BFN. Paul.

[Gerhard Postpischil [e-mail] [hercules-os380]]

On 3/13/2018 9:28 PM, ***@yahoo.com.au [hercules-os380] wrote:
> I have no idea why you think IBM couldn't have
> put a BSM inside the READ code (ie the OS
> code, not the macro) instead of requiring an
> application programmer to code that instead.
>
> It would not have broken forward compatibility.
BSM is suboptimal, as it requires saving the old mode, setting a flag,
and restoring on return. BASSM in the READ/WRITE macros would have been
simpler. But in the long run neither would allow for easy support of
AM31 buffers.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@charter.net> wrote :

>> I have no idea why you think IBM couldn't have
>> put a BSM inside the READ code (ie the OS
>> code, not the macro) instead of requiring an
>> application programmer to code that instead.

>> It would not have broken forward compatibility.

> BSM is suboptimal, as it requires saving the old mode, setting a flag,
> and restoring on return. BASSM in the READ/WRITE macros would have been
> simpler.

I don't think having the BASSM instruction contained
in a load module is a good idea, as it prevents running
on S/370.

> But in the long run neither would allow for easy support of
> AM31 buffers.

I am happy to live with a restriction for some time of
requiring I/O buffers BTL. I just want BSM switching
to move out of my application load module and into
the operating system. They could have done this
for both 32-bit and 64-bit programs.

But yes, it would have been good if MVS/XA
had also supported ATL I/O buffers. Once MVS/XA
failed to do that, a universal executable was
required to allocate BTL unless you start putting
in checks for specific operating systems which
is something I dislike. If they had created an
API to test "ATL buffers OK" that would be fine,
but absent such a test I prefer to just unconditionally
allocate buffers BTL.

BFN. Paul.

[Gerhard Postpischil [e-mail] [hercules-os380]]

On 3/13/2018 10:08 PM, ***@yahoo.com.au [hercules-os380] wrote:
> I don't think having the BASSM instruction contained
> in a load module is a good idea, as it prevents running
> on S/370.

IBM provided, whenever possible, forward compatibility, but never said
anything about going backwards. And a recompile would fix the problem.

> I am happy to live with a restriction for some time of
> requiring I/O buffers BTL. I just want BSM switching
> to move out of my application load module and into
> the operating system. They could have done this
> for both 32-bit and 64-bit programs.

If you're talking about ATL buffers for standard access methods, then
you're correct. But ATL I/O was possible - we used it on our 4341 and
4381; but I don't recall which version of MVS/SP that came in with, if
not earlier. I would guess that you could finagle it under MVS/380 using
EXCP/EXCPVR/STARTIO with IDAWs.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@charter.net> wrote :

>> I don't think having the BASSM instruction contained
>> in a load module is a good idea, as it prevents running
>> on S/370.

> IBM provided, whenever possible, forward compatibility, but never said
> anything about going backwards. And a recompile would fix the problem.

If it is possible, and I know for a fact that it is,
I would like a single 32-bit executable that works
optimally in all of MVS 3.8j, MVS/380, PDOS/370,
PDOS/380, PDOS/390, OS/390, z/OS.

At a later date I will have a separate 64-bit
executable which I only expect to work on
MVS/380, z/OS and z/PDOS.

Way off into the future I may have a 128-bit
load module and a 256-bit load module.

That is how I expect programming to work
universally, and the current challenge I am
discussing is to mark a 32-bit module as
AM64 and still have it execute properly
when called from a 64-bit module via
LINK, even on a machine with 256-bit
address registers.

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> At a later date I will have a separate 64-bit
> executable which I only expect to work on
> MVS/380, z/OS and z/PDOS.

Actually I should be able to support 64-bit
programming on PDOS/380. When I detect
that I am on z/380 hardware I can switch
to AM64 and all software will be run in
AM64 mode, regardless of whether they
are 32-bit or 64-bit programs.

I can make GETMAIN LOC=32 and LOC=64
work too, even though most of the OS code will
be 32-bit C code.

So maybe PDOS/380 will be the first
environment to support a 3 MiB malloc()
for a 32-bit program.

I will probably make the first GETMAIN LOC=64
just return a fixed pointer to the 8 GiB + 4096*2
location. I would prefer to use memmgr, but I
don't have a 64-bit GCC to compile that with
and don't really want to code in assembler.
Especially when I don't actually have any 64-bit
programs that use more than 4 GiB of memory.
Actually I will only provide that 8 GiB location
when the LOC=64 memory request is for more
than 4 GiB of memory. Note that the GETMAIN
macro is currently not smart enough to use a
LGR when the parameter is LOC=64.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

How did IBM code run before there was such a thing as BSM?

You run the same way. 1 address mode, all the time.

Joe

On Tue, Mar 13, 2018 at 8:03 AM, ***@yahoo.com.au [hercules-os380] <
hercules-***@yahoogroups.com> wrote:

>
>
> ---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :
>
> >> That is only the case if you have a SAM32 instruction.
> >> What if you are missing SAM64 and SAM128 and
> >> SAM32 instructions?"
>
> > Thats simple. You run in whatever address size the
> > PSW says, all the time, and you write your code
> > accordingly.
>
> How does an application do a BSM to set an
> address size of:
>
> 1. 32
> 2. 64
> 3. 128
> 4. 256
>
> There was only one bit available, and we are very
> lucky that someone at IBM found it at all. It was
> very clever of them to use the bottom bit.
>
> But that 1 bit necessarily means "infinity", aka 256
> if you're on a 256-bit machine.
>
> BFN. Paul.
>
>

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :

> How did IBM code run before there was such a thing as BSM?

> You run the same way. 1 address mode, all the time.

That's effectively what we have today. When you
do a BSM to x'01' and set bits 31+32 of the PSW
to b'11', you are effectively saying "there is no
address masking, you run in 1 address mode
all the time in your main application and you
only need to dumb things down when calling
the operating system, ie dumbing down to either
AM24 or AM31".

Now, within that single application address mode,
how do you handle 32-bit applications, 64-bit
applications, 128-bit applications and 256-bit
applications?

I've already given my proposal which is that either
LINK or the caller of LINK needs to zero everything
other than the bottom 32 bits before calling a
program of unknown number of bits (32 to 256).

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> That is only the case if you have a SAM32 instruction.

And even if you do have a SAM32 instruction,
you're still screwed, because you need a way
of distinguishing on the mainframe because
of the switching to AM24. If you execute a
routine that can be executed in any AMODE
which then switches to AM24, it doesn't know
whether to return to AM32 or AM64 or
AM128 or AM256. They all use b'1' in the
bottom bit of the register to indicate "some
number greater than 31".

BFN. Paul.

[pricgren [e-mail] [hercules-os380]]

On 2018-03-13 10:32 PM, ***@yahoo.com.au [hercules-os380] wrote:
> The LINK service saves the full 256 bits of
> a register, and then zeroes out the top
> 256-32 bits, so any parameters passed between
> applications must be done in RM32 space.

Or you could do what IBM did/does, and have the OS zero the maximum
widths of all of the registers which do not have set values like entry
points, return points, and initial save area addresses for new units of
work, and proceed from there.

Applications which use a subset of the native register width use
instructions which do not alter bits that the application does not know
exist.  If such a restricted bit-width program returns control to a
program that uses a greater bit width, those register values are
returned unaltered because the called program did not know how to change
them.

The called program cannot even perceive if the high order bits are zero
or not - but no matter because the value of those unseen bits does not
affect how that program executes, and those unseen bits will be returned
unaltered to the caller.

And everybody's happy.

Of course, the OS has to know how to save and restore the entire status
for each and all units of work as they get dispatched, suspended, and
dispatched again.

Cheers,
Greg

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com> wrote :

> Applications which use a subset of the native register width use
> instructions which do not alter bits that the application does not know
> exist.

The problem is that those unknown bits get used
as an address regardless, if a 128-bit program is
executing and it was called by a program using
256-bit registers. And if there is no SAM128
instruction to save the day.

BFN. Paul.




256-bit program


> The called program cannot even perceive if the high order bits are zero
> or not - but no matter because the value of those unseen bits does not
> affect how that program executes,

It DOES affect how the program executes.
The unwanted and nominally inaccessible
bits will be used in an address register.

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> These issues should all have occurred when
> a 64-bit program called a 32-bit program (any
> AMODE),

For closure, it's not an issue when calling an
AM31 or AM24 program because they are
protected from the upper 33 or 42 bits due to
their AMODE setting. It is only AM32 that is
unusual in that it won't get any mask
protection when running in z/OS because
we're sharing the AM64 setting to mean
"infinity".

> and probably also when an AM31
> program called an AM24 program.

And this is not an issue by virtue of the fact
that when the AM24 program returns it
doesn't return directly to the caller, there is
a PRB protecting the caller.

So the only problem is that IBM doesn't clear
the top 32 bits of registers, so the onus is on
the caller to not just step down to AM31 but
also do a STMH/LMH prior to invoking LINK,
and do a LMH on return. That's when the
caller is a genuine 64-bit program that has
disturbed the high 32 bits of any register.

Following these rules, things will work on both
MVS/380 and z/OS. No need to add a LINKX
to MVS/380 or MVS 3.8j.

Note that MVS/380 behaves a bit differently in
that it will (one day hopefully) acknowledge the
LOC=32 on GETMAIN, and also it will clear the
high 32 bits of registers prior to calling the
AM32 application. This is needed even for an
EXEC PGM=XXX.

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@vitillaro.org> wrote :

> * FILENAME: TEACH1A.MLC

Hi Peppe.

I have modified your program so that it can be
marked as AM24/31/32 and will work fine on
the current Hercules/380 which only supports
AM32, not AM64.

Please let me know if you understand the
changes and are happy with them.

Attached and below.

BFN. Paul.



//PDPMVS JOB CLASS=C,REGION=0K
//*
//CREATE EXEC PGM=IEFBR14
//DD1 DD DSN=&&LOADLIB,DISP=(,PASS),
// DCB=(RECFM=U,LRECL=0,BLKSIZE=6144),
// SPACE=(CYL,(10,10,20)),UNIT=SYSALLDA
//*
//ASM EXEC PGM=ASMA90,
// PARM='DECK,LIST,TERM'
//SYSLIB DD DSN=SYS1.MACLIB,DISP=SHR,DCB=BLKSIZE=32720
// DD DSN=SYS1.MODGEN,DISP=SHR
//SYSUT1 DD UNIT=SYSALLDA,SPACE=(CYL,(20,10))
//SYSUT2 DD UNIT=SYSALLDA,SPACE=(CYL,(20,10))
//SYSUT3 DD UNIT=SYSALLDA,SPACE=(CYL,(20,10))
//SYSTERM DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSLIN DD DUMMY
//SYSGO DD DUMMY
//SYSPUNCH DD DSN=&&OBJSET,UNIT=SYSALLDA,SPACE=(80,(9000,9000)),
// DISP=(,PASS)
//SYSIN DD *
* PRINT NOGEN
****************************************************************
* FILENAME: TEACH1A.MLC
* REMARKS : A card-image list of teacher records.
****************************************************************
*
*
*
MACRO ,
&NM GAMOS
.*
.* GAMOS sets addressing mode to 24 or 31 or
.* potentially bypasses the BSM
.*
TM NEEDBF,NEEDBANY Need AM switching?
BZ ZZ&SYSNDX.X
LA R14,ZZ&SYSNDX.X
O R14,NEEDBOO whatever mode OS requires
BSM 0,R14
ZZ&SYSNDX.X DS 0H
.MEND MEND ,
*
*
*
MACRO ,
&NM GAMAPP
.*
.* GAMAPP sets addressing mode to 31 or 64 or
.* potentially bypasses the BSM
.*
&NM TM NEEDBF,NEEDBANY Did we previously need a switch?
BZ ZZ&SYSNDX.X No, no switching required
.* We don't know whether we need to switch to 31 or 64
LA R14,ZZ&SYSNDX.X
O R14,NEEDBOA This decides 31/64
BSM R0,R14
ZZ&SYSNDX.X DS 0H
.MEND MEND ,
*
*
*
START 0
YREGS
BEGIN DS 0H
SAVE (14,12)
BALR R12,0
USING *,R12
LA R11,SAVEAREA
ST R11,8(,R13)
ST R13,4(,R11)
LR R13,R11
USING SAVEAREA,R13
*
CALL SETUP
OPEN (TEACHERS,INPUT)
LOOP DS 0H
GAMOS
GET TEACHERS,IREC
GAMAPP
* XDUMP IREC,80
* WTA IDATA
B LOOP
ATEND DS 0H
GAMAPP
CLOSE TEACHERS
LA R15,0
L R13,SAVEAREA+4
RETURN (14,12),RC=(15)
TEACHERS DCB LRECL=80,RECFM=F,MACRF=GM,EODAD=ATEND,DDNAME=TEACHERS, X
DSORG=PS
IREC DS 0CL80
IDATA DS CL80
SAVEAREA DS 18F
*
*
*
ENTRY SETUP
SETUP DS 0H
SAVE (14,12),,SETUP
LR R12,R15
USING SETUP,R12
*
* If we are running in a pure 24-bit environment, where
* the AMODE and RMODE are the same, there is no need to
* ever do AMODE switching, so none of this AMODE
* switching code is required at all
*
L R2,=X'FF000000'
LA R2,0(,R2)
CLM R2,B'1000',=X'00'
* If we are currently in AM24, there is nothing
* to ever do, as we will stay in that mode forever
BE RETURNSU
*
* Now see if we are running AM31
CLM R2,B'1000',=X'7F'
BZ IS32
* We are running AM31. If we are also located in
* RM31 space we do not need to do BSM switching
LR R2,R12
N R2,=X'7F000000'
LTR R2,R2
BNZ RETURNSU No amode switching possible
* The app is AM31 but the OS is AM24
* An OS of AM24 is default, so just go and set the
* application AMODE now
B COMM3164
IS32 DS 0H
*
* At this stage we know we are running in AM64
* aka AM32 aka AM-infinity (we don't know which one)
* First we need to know if we are running in RM32,
* highly unlikely.
*
LR R2,R12
N R2,=X'80000000'
LTR R2,R2
BNZ RETURNSU No amode switching possible
* Now see if we are running in RM31 space
LR R2,R12
N R2,=X'7F000000'
LTR R2,R2
BZ COMM3164 RM24 so just set the app amode bits
* We are indeed running in RM31 so we need the high bit
* set whenever we switch to OS mode
OI NEEDBOO,X'80'
COMM3164 DS 0H
* We have dealt with the appropriate bits to set
* the OS mode, now we need to set the return to
* application mode. That is easy, it is the current
* amode, either AM64 or AM31
LA R2,0
BSM R2,0
ST R2,NEEDBOA this will be suitable for ORing
OI NEEDBF,NEEDBANY set flag to say we need BSM switching
B RETURNSU
*
RETURNSU DS 0H
LA R15,0
RETURN (14,12),RC=(15)
LTORG ,
NEEDBF DC X'00' flag bits for whether BSM needed
NEEDBANY EQU X'01' need any amode switching at all?
NEEDBOA DC A(0) amode bits to be ORed in to return APP to
* original amode
NEEDBOO DC A(0) amode bits to be ORed in to set OS amode
*
END BEGIN
/*
//*
//LKED EXEC PGM=IEWL,PARM='AMODE=32,RMODE=24',
// COND=(0,LT,ASM)
//SYSLIN DD DSN=&&OBJSET,DISP=(OLD,DELETE)
//SYSLMOD DD DSN=&&LOADLIB(TEACH),DISP=(OLD,PASS)
//SYSUT1 DD UNIT=SYSALLDA,SPACE=(CYL,(2,1))
//SYSPRINT DD SYSOUT=*
//*
//TEACH EXEC PGM=TEACH,PARM='',
// COND=(0,LT,LKED)
//STEPLIB DD DSN=&&LOADLIB,DISP=(OLD,PASS)
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSIN DD DUMMY
//TEACHERS DD *
teacher 1
teacher 2
teacher 3
/*
//*
//

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> I have modified your program so that it can be
> marked as AM24/31/32 and will work fine on
> the current Hercules/380 which only supports
> AM32, not AM64.

On z/OS you will need to mark the module a
maximum of AM31 unless they update the LINK
processing to clear the upper 32 bits of registers
or else an AM64 caller of your AM32 takes
responsibility for clearing the upper 32 bits as
well as saving the upper 32 bits itself, if there
is any chance that it has set the upper 32 bits
to something other than 0. I think this is
probably a reasonable approach.

BFN. Paul.

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com.au> wrote :

> On z/OS you will need to mark the module a
> maximum of AM31 unless they update the LINK
> processing to clear the upper 32 bits of registers

I am happy to live with restrictions on z/OS,
especially if we do things in a way that IBM
can actually update z/OS if they want to.

There is little point marking a 32-bit module
AM32=64 on z/OS unless IBM also updates
GETMAIN to provide a LOC=32 parameter.

And so long as MVS/380 automatically clears
the top 32 bits of registers when it fetches a
module, and so long as 64-bit programs
don't rely on being passed 64-bit addresses
or values, there should be no problem with
32-bit and 64-bit programs marked as
AM32=64 co-existing on MVS/380 either.

Can anyone spot a problem with this approach?

BFN. Paul.

[pricgren [e-mail] [hercules-os380]]

On 2018-03-12 7:44 PM, ***@yahoo.com.au [hercules-os380] wrote:
> z/OS does not provide any convenient way to
> allocate AT4B (above the 4 GiB bar that 32-bit
> addressing has as a limit) memory. It has an
> IARV64 macro but the details of that are not
> open source so it cannot be reproduced. Also
> it is a dog to call (complex and space is
> allocated as a minimum of 1 MiB).

Well, it is widely documented how the macro should be coded by the
programmer, so if you wanted to, there is no technical barrier to you
coding and shipping your own IARV64 macro which reduced to a GETMAIN
LOC=64 thereby making z/OS ATB requests function pretty much as expected
under MVS/380 without source code change.

But you knew that....

Cheers,
Greg

[[e-mail] [hercules-os380]]

---In hercules-***@yahoogroups.com, <***@yahoo.com> wrote :

>> z/OS does not provide any convenient way to
>> allocate AT4B (above the 4 GiB bar that 32-bit
>> addressing has as a limit) memory. It has an
>> IARV64 macro but the details of that are not
>> open source so it cannot be reproduced. Also
>> it is a dog to call (complex and space is
>> allocated as a minimum of 1 MiB).

> Well, it is widely documented how the macro should be coded by the
> programmer, so if you wanted to, there is no technical barrier to you
> coding and shipping your own IARV64 macro which reduced to a GETMAIN
> LOC=64 thereby making z/OS ATB requests function pretty much as expected
> under MVS/380 without source code change.

> But you knew that....

No, I didn't know that. Thanks for the suggestion,
I'll add that to the document.

BFN. Paul.