With the TRKCALC intercept in place, I now
have all the technology I need for a MVS/380 2.0
that I am happy with. The required source code
is all in CVS, so if you're impatient, or I'm dead,
just mosey on down to http://mvs380.sourceforge.net
and grab the random bits of code you need,
like mvs380ss.jcl and svc120b.jcl and iewfetch.asm
and iefactrt.asm and various others.

I'm not going to build it immediately because
I'm waiting to see how REVIEW pans out, and
also Gerhard is still busy making enhancements
to MVSSUPA, so I will wait until he stops.

But I never want to retreat from the position
we are in right now.

First of all, let me tell you who is going to
win Miss America - it's the first person to
produce an ANY/ANY module. Even
experts who have worked on MVS for
decades have never even heard of this,
and even the Loch Ness Monster is
more believable. Even when I point them
to the IBM documentation (see below),
they just assume that someone must
have bumped IBM when they were
writing the manual.

When I was at school, someone came
in with a sick note "from their mother"
which said "John was not at school
today because I was sick", and when
the teacher challenged him as to why
his mother would say "I" instead of "he",
he countered with "someone must have
bumped her arm when she was writing it".
If that isn't worth 10 points for effort, I
don't know what is.

Anyway, from memory, back in the 1980s
with the IBM C/370 compiler, I believe I
first saw modules marked ANY/ANY
instead of 31/ANY, and I wasn't really
sure what the difference was. I started
on mainframes with MVS/XA so I have
always had AM31 available until I started
porting GCC to MVS 3.8j.

Then one day while working on PDOS/390
I was shocked when I accidentally ran an
AM24/RM24 module on PDOS/390 (which
always assumes modules are AM31/RMANY)
and it actually worked instead of abending.

I had in fact for many years resisted adding
system dependencies in my code, ie
checking CVTxxx and doing one thing for
MVS/XA and above and something else
for below. Or a separate module for I/O
routines which would be dynamically
loaded BTL so that the rest of the app
could be ATL. I wanted to keep the design
simple and I'd rather produce a MVS 3.8j
module and a z/OS module and an
MVS/380 module.

I was fairly content with producing AM24
modules and relying on upward compatibility
to ensure that module still worked on z/OS.
So yes, I had one module to cover all, but
it was certainly sad seeing "24" for modules
destined for z/OS. Not that utilities like
copyfile and hexdump require more than
16 MiB of memory, but still, it was sad.

But when my AM24 module was successfully
running as AM31 (ie the exact same module),
I realized that I had in my hands *at least*
an AMODE ANY, RMODE 24 application.
Which is pretty bloody fantastic already.
All my due diligence of keeping the code
simple for as long as possible had paid off.
The S/370 build, which, obviously, did no
BSMs, was also capable of running AM31
on z/OS, since as of late MVS/ESA, all the
I/O routines were bimodal.

But given that I had previously ensured
that I also had an S/390 build, which
produced a 31/ANY load module for z/OS,
I wondered whether I was now in a
position to use the S/390 target (which
also does no BSMs, obviously) and have
it run on MVS 3.8j. And I was elated to
see that I could indeed do that. That
means I only need a single physical
load module to cover *both* MVS 3.8j
and z/OS *perfectly* (ignoring AM64,
anyway). With zero kludging whatsoever.
I don't need to test the CVT or have
dynamic loading.

If you inspect the actual assembler code
that goes into one of my modules, it is
very very simple (well, if you ignore the
massive features added by Gerhard).
It is plain old S/370 code. Just doing
OPENs and stuff like that. No dynamic
testing for 24 vs 31. Just plain old
OPEN that you would see in any old
MVS 3.8j program. Even getting memory
it uses a plain old GETMAIN RU which
defaults to LOC=RES, just like you would
see on any old MVS 3.8j program. The
module becomes 31/ATL capable just
because of the fortuitous fact that LOC=RES
actually gets ATL memory if your module
is marked RMODE ANY. ie it looks like luck.
ie if an MVS 3.8j programmer had simply
written code a certain way in 1980, before
OS/390 existed, and then woke up one
day during the OS/390 era and decided to
mark the module 31/ANY, saying "I wonder
what will happen?", it would have magically
worked.

Well, almost, anyway. In 1980 he would have
also had to say "I like to see clean registers
in all my dumps" and have changed the
various IBM macros (READ/NOTE/etc) so
that they used ICM '0111' instead of "L"
when loading a 24-bit address.

That's magic. If that doesn't win Miss
America, nothing will.

This magical ability to use "PDS" and just
magically convert a module from 24/24
to 31/ANY is what is actually an ANY/ANY
module. For 34 years, IBM has been
documenting *in their z/OS manuals* how
a program can still run on MVS/370. That's
right. Even though MVS/370 stopped being
supported decades ago, IBM has still been
documenting how to get your modules to
run cleanly on MVS 3.8j and z/OS at the
same time. In the hope that one day,
someone would actually produce an
ANY/ANY module. Presumably some time
after someone captured and slaughtered
the Loch Ness Monster once and for all.

While something trivial like IEFBR14
could have been marked ANY/ANY at
any point since MVS/XA was released,
any remotely normal utility that opens
a file could not be marked this way,
because the IBM routines were only
made bimodal in late MVS/ESA. Before
then programmers were expected to
compensate for this shortcoming
themselves, by doing their own BSM
before doing a READ. I don't know why
IBM couldn't have just put the BSM
into their own routines instead of
expecting every programmer to do
that themselves, but nevermind, by
late MVS/ESA they were finally doing
it sensibly. I don't know when the macros
were cleaned up, perhaps earlier than
the I/O routines themselves. And of
course, by that time, MVS 3.8j was no
longer being used, nor did it even run
on the same hardware that MVS/XA
and above ran on.

Let me quote from the z/OS manual
referenced below, as you won't believe
me unless you see it for yourself:

"Execute entirely in 24-bit addressing mode on an MVS/370 system"

That's right. Even in z/OS manuals, IBM
is *still* documenting what an ultimate
load module actually looks like.

Theoretically people may be accidentally
creating ANY/ANY load modules on z/OS
to this day. If for whatever reason they
have been using "GETMAIN R" instead
of LOC=BELOW, they are in fact meeting
MVS 3.8j specifications to get BTL memory.
And if they have been using
GETMAIN RU with no LOC= parameter
to get their ATL memory, on the assumption
that they will be marking the load module
RMODE ANY so it will work out fine, then
once again they are not exceeding the
MVS 3.8j documentation, and have every
right to expect their load module to work
on MVS 3.8j - *officially*. It is true that
MVS 3.8j fortuitously allows and ignores
extra undocumented options, but anyone
working from the documentation without
access to the old hardware that could
have run MVS 3.8j wouldn't know that,
and it's breaking the rules even if it does
happen to allow it.

There is one more practical exception.
For a module to work ATL on z/OS,
it is still necessary for the EOF routine
to reside and be executed in AM24
BTL. But rather than having a dynamically
loaded module to do this, it is far
neater, in my opinion, to simply
allocate some BTL storage and copy
the EOF code from ATL to BTL.

And an extension of that, the DCB
OPEN exit also needs to able to
handle being invoked as AM24,
and thus that needs to be copied
BTL, or more practically it needs to
have a stub copied BTL which does
a BSM to switch into AM31 so that
it can then run your ATL code. BUT
this complication only needs to be
executed if you find (e.g. by inspecting
R15 or doing a LA) that your module
resides ATL. So although the BSM
needs to *assemble* and exist *in
your load module*, it will never
actually be executed on MVS 3.8j.

And thus a practical ANY/ANY was born.

I have been able to build ANY/ANY modules
for a year or two now, but I haven't yet
released a new version of GCCMVS/PDPCLIB
that will do this, because I was holding out
for a bit more technology.

Even though ANY/ANY modules are beautiful
enough to win Miss America, they won't
actually run as AM31 on either MVS/XA or
MVS/380 1.x, because in both cases the
OS I/O routines are not bimodal. To me, the
solution to that problem is to simply mark
modules 24/24 and let them run as AM24
on both MVS/XA and MVS/380 1.x, and if
you don't like that, upgrade to either OS/390
or above or MVS/380 2.0 or above.

But of course, that means I need to produce
an MVS/380 2.0 that is capable of running
an unkludged 31-bit z/OS load module.
Note that if a z/OS programmer inspects
the internal technical details of one of my
ANY/ANY modules, I want him to come
away agreeing that it is totally clean and
a definite candidate for Miss America.
What that means is I don't want the *load
module* to be kludged. I don't mind if
the load module has some severe
limitations (or doesn't run at all in fact)
on MVS/380, so long as z/OS and
MVS 3.8j are totally clean from a
technical inspection point of view.

If anyone has any complaints about
the module's performance on MVS/380
(any version) I expect them to just
mark the module 24/24 and they are
no worse off than they were with
MVS 3.8j.

But if you have some *select
applications* that are currently
ANY/ANY load modules, and you
can't afford z/OS, and you are willing
to put up with a bit of foul odor, then
let's talk.

I am one of those people and my
application is GCC.

It is true that I have the ability to
build a S/380 version of GCC that will
work on both MVS/XA and all versions
of MVS/380, but I'd prefer to just ship
a single GCC module, and work around
any restrictions that may appear.

One such restriction is that the I/O
routines in beta MVS/380 2.0 have
not been updated to support tapes,
so if you wish to run GCC as 31-bit
on MVS/380 2.0 you must give GCC
a disk file, not a tape file. Again, if
you don't like that, feel free to mark
GCC as AM24 and it will happily
read your tape file, but your tape
file must contain a small program,
because a large program will run
out of memory when run AM24.

That's fine. I can live with that. My
important compiles all compile from
disk datasets, so I will copy any programs
on tape onto disk before trying to compile
them. No problem. And of course, people
using bootleg z/OS have no problem with
this either. So a single load module is
all I need. And although I intend to *build*
copyfile and hexdump etc etc as ANY/ANY
modules so that they look totally beautiful
on both MVS 3.8j and z/OS, I may well
choose to mark them all as 24/24 on
MVS/380 2.0, so that e.g. copyfile can
operate on a tape, which is something
that I actually want.

Of course, in the future, e.g. MVS/380 2.1,
someone may contribute code to allow
the tape routines to be bimodal. Ideally
they would achieve this by taking the
available assembler code and then
doing disassemblies to update the
source code, prior to adding a BSM at
entry and exit. But if people (like me
sometimes) are too lazy to do
disassemblies and would like to just
chance their arm at using the old source
code we have available, and hope that
it is good enough, that's fine too. Let's
talk. Send me the new code, and if it
doesn't stop me from rebuilding GCC,
then that's probably fine for MVS/380 2.1.

Anyway, for an ANY/ANY module like
GCC to actually work on MVS/380 2.0
in any fashion at all, it needed a couple
of things that were available in MVS/XA,
but not in MVS/380 1.x.

1. The OS to respect the AMODE 31 bit
in the load module.

2. Don't attempt to allocate a huge amount
of memory as a heap, only allocate what
you actually need. ie multiple ATL GETMAINs.

Number 1 was achieved a year ago or
something, but it has been done in an
extremely crude manner which I hope
someone will fix in due course.

Number 2 was done in the last couple
of weeks by Gerhard.

For practical use, there was also one
other thing I wanted - ATL memory to
be cleaned up automatically when a
step ends, in case of either an abend
or a memory leak. I would really hate
it if I run a program once and it finishes
successfully, but run it again and it
complains about "out of memory error".
I expect the OS to clean this up
automatically, and if we don't have that
technology, then I prefer an alternative
solution which is to use a huge heap
(60 MB) and a crude SVC 120 that
just returns a fixed address all the time,
that gives the illusion that the OS is
cleaning up memory automatically. I
have been running with that illusion
for about a decade, but also in the
last couple of weeks Gerhard provided
the automatic cleanup solution I needed,
ie an update to IEFACTRT.

So now beta MVS/380 2.0 has everything
I need. I am happy to throw MVS/380 1.x
in the dustbin of history, along with MVS/XA,
and stick with running beautiful ANY/ANY
modules. I don't mind if MVS/380 2.0 is
not beautiful, but I do very much are about
my load modules.

Note that because all of my C programs
are built with PDPCLIB, in particular
MVSSUPA, which is the only place
that there is an interface to the operating
system, they are all basically identical.
Either everything works, or everything
fails. Since I'm only after ANY/ANY to
work, I have everything I need already.

Next we can begin negotiations for
*other* programs, like REVED, which
are more "icing on the cake" to me at
this point. REVED needs to run as
RMODE 24. In order to support that,
I actually need a new API in SVC120B
that allows me to say "this address
space has started running RM24
programs as AM31, which means all
future requests for LOC=RES memory
should come from BTL storage, and
if any app wants ATL storage they need
an explicit LOC=ANY on their GETMAIN
request". I would then need to call that
API from IEWFETCH. We don't have
that technology yet, but I can live
without it.

SVC120B is the name of the new SVC 120
intercept btw, but it also has the TRKCALC
intercept in it. BTW, with the working
TRKCALC, I have now recovered from
all the MVSSUPA changes that were
made in response to Peppe's change
requests.

Anyway, many of you are probably
totally confused about this RM24/ANY
issue. This is because of the crude
implementation. Because we do not
yet have the technology to load a
module ATL, and nor does the current
beta MVS/380 2.0 even have the
ability to dump ATL memory, so you
are half running blind if your AM31
app abends (yet another restriction
you must live with for now), I expect
to get ATL memory for LOC=RES
requests even for modules that are
physically BTL. This does not break
any rules. The GCC module is marked
RMODE ANY, and indeed, it does
LOC=RES requests and indeed it
gets ATL memory returned. Everything
is working perfectly fine from the
perspective of the programmer/user.

Note that this implementation differs
from z/OS, because z/OS has the
ability to actually physically load
modules ATL, and thus they can
simply look at the current PSW and
if the PSW shows an ATL address,
then only then will LOC=RES give an
ATL address. But this difference in
implementation is something internal
to both operating systems and no-one
else's business.

However, that means that I have to
document that AM31/RM24 programs
like REVED are not supported.

BUT, they might work anyway! Because
the problem only arises when you do a
LOC=RES memory request expecting
to get BTL memory. But if you do an
explicit LOC=BELOW, you will in fact
get BTL memory. I was under the
impression that REVED and REVIEW
never do LOC=RES calls, so it should
still run fine. But for some reason
REVED (but not REVIEW) is abending
when LOC=RES returns ATL memory.

To switch off this LOC=RES gets ATL
memory behavior, you just need to
reverse out this change:

http://mvs380.cvs.sourceforge.net/viewvc/mvs380/mvs380/source/misc/svc120b.jcl?r1=1.31&r2=1.32

That way REVED (with my zap), will
start working again.

GCC will still work too, so long as you
only compile small programs.

So with current technology, this is the
choice you need to make. You either
run GCC with ATL memory or you run
REVED with ATL memory.

Note that even with LOC=RES getting
BTL storage, REVED works, but after
successfully saving the data, it abends.
I haven't produced a dump for that yet,
as it may be fixed by the macro changes.

So that's where we stand today. From
my point of view, it's Nirvana. Because
the actual work I wish to do is to both
build and run GCC using ATL memory
to produce beautiful ANY/ANY modules,
of which GCC is one such module. Yes,
I could do exactly that on a bootleg z/OS
too, but I prefer to do it on the non-bootleg
MVS/380 2.0,

Other people may wish to edit large
files (more than 16 MiB) using reved.
That is now possible too, if they don't
mind ignoring the abend on exit. And
MVS/380 2.0 isn't finalized yet, so at
this point it is not clear how many of
those restrictions mentioned above
can be lifted before the new release.

BFN. Paul.




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

3.
The attributes AMODE ANY/RMODE ANY take on a special meaning when used together. (This meaning might seem to disagree with the meaning of either taken alone.) A module with the AMODE ANY/RMODE ANY attributes will execute on either an MVS/370 or a system that uses 31-bit addressing if the module is designed to:
Use no facilities that are unique.
Execute entirely in 31-bit addressing mode on a system that uses 31-bit addressing and return control to its caller in 31-bit addressing mode. (The AMODE could be different from invocation to invocation.)
Execute entirely in 24-bit addressing mode on an MVS/370 system.
The linkage editor and loader accept this combination from the object module or load module but not from the PARM field of the linkage editor EXEC statement or the linkage editor MODE control statement. The linkage editor converts AMODE ANY/RMODE ANY to AMODE 31/RMODE ANY.