REVIEW/RFE Release 47.0

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

REVIEW/RFE Release 47.0

Hercules390 - Mvs mailing list
Greetings,


Just an FYI re REVIEW/RFE Release 47.0 - now available from

http://www.prycroft6.com.au/REVIEW/



Also caught up on the backlog of release notes entries at

http://www.prycroft6.com.au/REVIEW/revnotes.html


Cheers,
Greg

Reply | Threaded
Open this post in threaded view
|

Re: REVIEW/RFE Release 47.0

Hercules390 - Mvs mailing list
Hi Greg
 

 Thanks a lot for the new release!
 

 Good that I'm (as usual) late with TK4- Update 09: So RFE/REVIEW Release 47.0 will make it straight into this update .
 

 Cheers
 Jürgen

 

---In [hidden email], <greg.price@...> wrote :

 Greetings,
 
 
 Just an FYI re REVIEW/RFE Release 47.0 - now available from
 
 http://www.prycroft6.com.au/REVIEW/ http://www.prycroft6.com.au/REVIEW/
 
 
 
 Also caught up on the backlog of release notes entries at
 
 http://www.prycroft6.com.au/REVIEW/revnotes.html http://www.prycroft6.com.au/REVIEW/revnotes.html
 
 
 Cheers,
 Greg

Reply | Threaded
Open this post in threaded view
|

Re: REVIEW/RFE Release 47.0

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
---In [hidden email], <greg.price@...> wrote :

> Also caught up on the backlog of release notes entries at

> http://www.prycroft6.com.au/REVIEW/revnotes.html 

[from there}

•The MVS/370 load module is marked as AMODE31 to allow it to run on z/OS where it would otherwise abend with an S0C4. It will place various areas above the line, including data being held for edit. Note that not all functions of the compiled-for-MVS/370 REVIEW/RFE package function currectly under z/OS. Commands which look at system control blocks are liable to abend, but at least the basic data set processing and 3270 functionality works as expected.

[/end from]


Thanks a lot for testing that out to make
sure it works! Now we have a very
serious challenge to see if we can make
that AM31 load module work on the
next release of MVS/380.

BFN. Paul.
Reply | Threaded
Open this post in threaded view
|

Re: REVIEW/RFE Release 47.0

Hercules390 - Mvs mailing list
On 2017-02-28 5:36 PM, [hidden email] [H390-MVS] wrote:
> Thanks a lot for testing that out to make
> sure it works! Now we have a very
> serious challenge to see if we can make
> that AM31 load module work on the
> next release of MVS/380.

It seemed to work on z/OS but then I thought of the I/O buffers for BSAM
and BPAM which I allocate ATL.

This would cause a problem on MVS/XA because DFP Version 2 did not
support AM31 I/O (except for the VSAM and ASM I/O drivers).  So I have
had a stab at making it ready for MVS/XA - without having an MVS/XA to
test it on, but it still worked as well on z/OS.

But, be warned, if I missed something that relies on ATL support
introduced later on by IBM, it might still not work in the 380 realm.

Also, the things I said might abend when the MVS/370 REVIEW load module
is run on z/OS should not abend when run on MVS/380.

Cheers,
Greg



Reply | Threaded
Open this post in threaded view
|

Re: REVIEW/RFE Release 47.0

Hercules390 - Mvs mailing list
---In [hidden email], <greg.price@...> wrote :

> This would cause a problem on MVS/XA because DFP Version 2 did not
> support AM31 I/O (except for the VSAM and ASM I/O drivers). So I have
> had a stab at making it ready for MVS/XA - without having an MVS/XA to
> test it on, but it still worked as well on z/OS.

Those MVS/XA limitations are not
relevant to MVS/380. MVS/380 will
handle I/O being called AM31. At
least for the ones I know about/use.

I would hope that when the module
is running on MVS/380 it should
work the same as z/OS, no MVS/XA
kludges.

Given that MVS/XA has disappeared
off the face of the earth, can you wait
until someone actually requests
MVS/XA support before adding
AMODE switching pollution to the
code? AMODE switching in application
code is not relevant to MVS 3.8j,
MVS/380 or z/OS, which is all that
actually exists at the moment
(maybe OS/390 also exists, and
is also not relevant).

Alternatively, perhaps you could
change the load module so that if
it is marked AM24, and thus starts
in AM24, it remains at AM24 and
only requests BTL memory. So
that it will run AM24 on z/OS too.
That could actually be tested.
MVS/XA can't be. Note that I don't
need this code to be added for
MVS/380 support. MVS/380 will
actually rely on the AM31 setting
(and RM ANY) of the load module,
otherwise ATL memory won't be
allocated (because I am relying on
LOC=RES to get ATL memory,
but it will only do so if the caller
is AM31).

> But, be warned, if I missed something that relies on ATL support
> introduced later on by IBM, it might still not work in the 380 realm.

Sure. That's what we need to find out.

> Also, the things I said might abend when the MVS/370 REVIEW load module
> is run on z/OS should not abend when run on MVS/380.

Yes, that will be way cool! :-)

BFN. Paul.
Reply | Threaded
Open this post in threaded view
|

Re: REVIEW/RFE Release 47.0

Hercules390 - Mvs mailing list
---In [hidden email], <kerravon86@...> wrote :

> Alternatively, perhaps you could
> change the load module so that if
> it is marked AM24, and thus starts
> in AM24, it remains at AM24 and
> only requests BTL memory.

Perhaps the best way to do this
would be, for the MVS/370 module,
to translate LOC=ABOVE to LOC=RES
(in the build process).

Ideally it would be possible for the
module to actually run ATL so that
it gets ATL memory on z/OS.

I think adding in at least an option
to *run* ATL would be better than
polluting the code with MVS/XA-specific
kludges that are untested and unused.

BFN. Paul.
Reply | Threaded
Open this post in threaded view
|

Re: REVIEW/RFE Release 47.0

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
On 2017-03-01 11:40 AM, [hidden email] [H390-MVS] wrote:
> Those MVS/XA limitations are not
> relevant to MVS/380. MVS/380 will
> handle I/O being called AM31. At
> least for the ones I know about/use.
No, it is not an AMODE issue - it is about where the I/O buffers reside.

The change to which I allude is that a small number of GETMAINs with
LOC=(31,64) for z/OS have the LOC operand dropped in the compile for
pre-ESA systems.

No-one has stated that the EXCP I/O driver (which is used by
QSAM/BSAM/BPAM) supports I/O buffer addresses above the line.  Do SAM's
channel programs use IDAWs?  I don't know, but until someone tells me
they do, then the small retreat from full z/OS VSCR exploitation is a
small price to pay.

Even IBM resorted to inventing the DCBE to implement QSAM buffers ATL.

If VSAM and ASM were the only I/O drivers ready for ATL I/O when MVS/XA
came out, I doubt that MVS 3.8J is in much better shape.

And then there is the CATALOG SVC 26 interface - another data area I
thought prudent to move BTL.

If GET/PUT/READ/WRITE/CHECK etc issue SVC 0 (EXCP) under the covers then
we recall that the AMODE of SVC routines depends on theor SVC table
entries and not upon the AMODE of the PRBs that issued the SVC.

Have these SVC routines gone through conversion to AM31?
I think not.  Please enlighten me if I'm wrong.

These areas can be moved back to ATL very easily once functionality has
been verified.

But if given control with AM31, REVIEW/RFE stays with AM31, and that is
not affected by the qualifying point I am making here.

Cheers,
Greg

Reply | Threaded
Open this post in threaded view
|

Re: REVIEW/RFE Release 47.0

Hercules390 - Mvs mailing list
On 3/1/2017 3:37 AM, Greg Price [hidden email] [H390-MVS] wrote:
> No-one has stated that the EXCP I/O driver (which is used by
> QSAM/BSAM/BPAM) supports I/O buffer addresses above the line.  Do SAM's
> channel programs use IDAWs?  I don't know, but until someone tells me
> they do, then the small retreat from full z/OS VSCR exploitation is a
> small price to pay.
I haven't looked at the code lately, but how difficult would it be to
use another approach?  Both IBM (ASM XF) and U. of Waterloo (SCRIPTW)
isolate all system dependent code in a single module, and test on
startup which support module to load (MVS or CMS).


Gerhard Postpischil
Bradford, VT

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

Reply | Threaded
Open this post in threaded view
|

Re: REVIEW/RFE Release 47.0

Hercules390 - Mvs mailing list
On 2017-03-01 11:49 PM, Gerhard Postpischil [hidden email]
[H390-MVS] wrote:
> I haven't looked at the code lately, but how difficult would it be to
> use another approach?
Well, I suppose anything is possible...

All I am saying is that in an effort to provide a functional MVS/370
REVIEW which stands the most chance of running without a problem as a
pure AM31 app on MVS/380, I have made some small adjustments in memory
management (think RMODE) in a couple of places because I think that
without those adjustments it would abend.  I think it would be more
informative if it did not abend.  If it works and everyone thinks that
MVS/380 suddenly has the same RMODE freedoms that z/OS has, then it can
be recompiled accordingly to settle the issue.  I am making this
distinction because I don't want anyone to think that suddenly all
(non-UNIX?) z/OS software will run successfully on MVS/380 just because
an editor can buffer data ATL on it.  Though I have heard chat about I/O
macros and GETMAIN being enhanced, I have not heard much scuttlebutt
about the upgrading of MVS SVC routines to support 31-bit addresses in
general - the point being that many system services are accessed by
application by issuing SVCs.

Cheers,
Greg

Reply | Threaded
Open this post in threaded view
|

Re: REVIEW/RFE Release 47.0

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
On 1 March 2017 at 03:37, Greg Price [hidden email] wrote:
> No-one has stated that the EXCP I/O driver (which is used by
> QSAM/BSAM/BPAM) supports I/O buffer addresses above the line.  Do SAM's
> channel programs use IDAWs?  I don't know, but until someone tells me
> they do, then the small retreat from full z/OS VSCR exploitation is a
> small price to pay.

I don't imagine SAM's channel programs use IDAWs, but surely the EXCP
processor must create them. How otherwise could a real CCW chain be
set up when SAM wants to, say, read 8 kB into an 8kB virtual storage
block that is mapped to two discontiguous frames? Surely none of this
processing involves moving pages to adjacent frames; I'm pretty sure
no such service exists within even modern systems.

But I think you're asking if SAM *always* generates channel programs
with IDAWs, and I guess the answer to be no. But I suppose if the code
is general enough, it might. But then even that's not going to work if
LRA produces a bogus result for ATL input (virtual) addresses. I have
no idea what it does in "S/380". To say nothing of the required
PAGEFIXes, etc. etc.

Tony H.
Reply | Threaded
Open this post in threaded view
|

Re: REVIEW/RFE Release 47.0

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
---In [hidden email], <greg.price@...> wrote :

> No, it is not an AMODE issue - it is about
> where the I/O buffers reside.

I see. Yes, I don't believe that it is possible
for MVS/380 to accept ATL I/O buffers,
and certainly I have never attempted to
test that.

> But if given control with AM31, REVIEW/RFE
> stays with AM31, and that is
> not affected by the qualifying point
> I am making here.

Great. That's what I want.

Please don't restructure REVIEW as
suggested by Gerhard. I'd like to wait
for REVIEW to be tested as-is before
making any AMODE enhancements.

It might take a year before it can be
tested. I'm waiting for Gerhard to
enhance SVC120I to allow multiple
small ATL memory requests. I
believe the rest of the technology
is already in place (in dev).

BFN. Paul.
Reply | Threaded
Open this post in threaded view
|

Re: REVIEW/RFE Release 47.0

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
On 3/1/2017 2:37 PM, Tony Harminc [hidden email] [H390-MVS] wrote:
> I don't imagine SAM's channel programs use IDAWs, but surely the EXCP
> processor must create them. How otherwise could a real CCW chain be
> set up when SAM wants to, say, read 8 kB into an 8kB virtual storage
> block that is mapped to two discontiguous frames? Surely none of this
> processing involves moving pages to adjacent frames; I'm pretty sure
> no such service exists within even modern systems.
Basically most EXCPs were changed to EXCPIO, which is responsible for
either page fixing virtual pages, or (on 32/64MiB machines) relocating
ATL pages to 24-bit storage. CCWs were restructured to use 2K per. Not
sure if or when IDAW support was added (SP ?).

Gerhard Postpischil
Bradford, VT

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

Reply | Threaded
Open this post in threaded view
|

Re: REVIEW/RFE Release 47.0

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
---In [hidden email], <greg.price@...> wrote :

> And then there is the CATALOG SVC 26
> interface - another data area I
> thought prudent to move BTL.

On further thought, I would suggest that
it is *only* the data being edited that
should reside ATL. And I would expect
that MVS never sees the data being
edited, ie the ATL addresses are never
passed to any MVS call.

That should simplify the code, so that
there is hopefully just one place where
you need to mark it as "this can go
ATL on the MVS 3.8j build".

Another (less-preferred) possibility is
that you could modify the GETMAIN
macro used for the MVS 3.8j build
so that it is only if the subpool is 0
that the LOC= parameter is used.
I believe you changed the data
being edited such that it goes into
subpool 0.

BFN. Paul.
Reply | Threaded
Open this post in threaded view
|

Re: REVIEW/RFE Release 47.0

Hercules390 - Mvs mailing list
---In [hidden email], <kerravon86@...> wrote :

> you need to mark it as "this can go
> ATL on the MVS 3.8j build".

E.g. I believe you have your own
macro which in turn calls GETMAIN.

So on your own macro you could
add a parameter MVS38PASS
which, if set to YES, will pass
through the LOC= parameter to
the unmodified GETMAIN.

But in all other places where
LOC=31 is specified, on the
MVS/370 build you strip off the
LOC before passing to GETMAIN,
thus forcing it to be LOC=RES,
ie BTL in the case of REVIEW.

So there is hopefully literally just
one place in the code where
MVS38PASS needs to be added.

That is minimalist (yet provides
basically full benefits to the user)
and most likely to actually work
on the next MVS/380.

BFN. Paul.
Reply | Threaded
Open this post in threaded view
|

Re: REVIEW/RFE Release 47.0

Hercules390 - Mvs mailing list
---In [hidden email], <kerravon86@...> wrote :

> So on your own macro you could
> add a parameter MVS38PASS
> which, if set to YES, will pass
> through the LOC= parameter to
> the unmodified GETMAIN.

Actually, a nice touch for that
hopefully one line of code would
be to test if it is 24 or 31, using
either TEST31 or GETAM which
can be found here:

http://pdos.cvs.sourceforge.net/viewvc/pdos/pdos/pdpclib/mvssupa.asm?view=markup

and only if AM=31 do the LOC=31
on the GETMAIN.

That way your module will be AMODE ANY
instead of only AMODE 31 working on
z/OS.

BFN. Paul.
Reply | Threaded
Open this post in threaded view
|

Re: REVIEW/RFE Release 47.0

Hercules390 - Mvs mailing list
---In [hidden email], <kerravon86@...> wrote :

> That way your module will be AMODE ANY

Also noting that even MVS/XA users,
should they ever arise from the dead,
will be able to mark the module AM24
and still be able to run it. AM31 won't
work because MVS/XA I/O routines
are not 31-bit capable. I don't care if
MVS/XA can't run a module AM31,
but it would be good for them to at
least be no worse off than they were
when they were running MVS 3.8j.

BFN. Paul.
Reply | Threaded
Open this post in threaded view
|

Re: REVIEW/RFE Release 47.0

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
---In [hidden email], <greg.price@...> wrote :

> And then there is the CATALOG SVC 26
> interface - another data area I
> thought prudent to move BTL.

Just to clarify - MVS/380, like MVS 3.8j, is
not expecting to operate on any ATL
addresses. The ATL addresses to store
the data being edited should not be
given to any MVS routine as a parameter.
They need to be copied into BTL storage
before doing that.

It is true that the I/O routines in MVS/380
can handle being executed in AM31, but
that doesn't mean you can give them
ATL addresses.

In actual fact, the only reason those
I/O routines can handle being called
in AM31 is because I do an
unconditional BSM to AM24 at the
beginning of those routines (ie
*outside* the application). And then
an unconditional BSM back to the
original AMODE. So it is imperative
that the routines only receive BTL
addresses.

So, it's a kludge. But the kludge is
good enough to be able to run a
subset of z/OS 31-bit programs.
Specifically z/OS programs that
don't pass ATL addresses to any
MVS routine.

BFN. Paul.
Reply | Threaded
Open this post in threaded view
|

Re: REVIEW/RFE Release 47.0

Hercules390 - Mvs mailing list
On 3/3/2017 2:30 AM, [hidden email] [H390-MVS] wrote:

> It is true that the I/O routines in MVS/380
> can handle being executed in AM31, but
> that doesn't mean you can give them
> ATL addresses.
>
> In actual fact, the only reason those
> I/O routines can handle being called
> in AM31 is because I do an
> unconditional BSM to AM24 at the
> beginning of those routines (ie
> *outside* the application). And then
> an unconditional BSM back to the
> original AMODE. So it is imperative
> that the routines only receive BTL
> addresses.
The I/O routines expect that you either supply data in the provided BTL
buffer, or for the record mode interface, will copy your record into the
BTL buffer. I don't have a working 380 system right now, so I can't test
it, but if it doesn't work with ATL data, it needs to be fixed.

Gerhard Postpischil
Bradford, VT

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

Reply | Threaded
Open this post in threaded view
|

Re: REVIEW/RFE Release 47.0

Hercules390 - Mvs mailing list
---In [hidden email], <gerhardp@...> wrote :

>> It is true that the I/O routines in MVS/380
>> can handle being executed in AM31, but
>> that doesn't mean you can give them
>> ATL addresses.
>>
>> In actual fact, the only reason those
>> I/O routines can handle being called
>> in AM31 is because I do an
>> unconditional BSM to AM24 at the
>> beginning of those routines (ie
>> *outside* the application). And then
>> an unconditional BSM back to the
>> original AMODE. So it is imperative
>> that the routines only receive BTL
>> addresses.

> The I/O routines expect that you either supply data in the provided BTL
> buffer, or for the record mode interface, will copy your record into the
> BTL buffer. I don't have a working 380 system right now, so I can't test
> it, but if it doesn't work with ATL data, it needs to be fixed.

I am having difficulty understanding
what you are talking about, but
regardless, nothing needs to be
fixed, it's all working as expected.

My best guess is that we are talking
cross-purposes about the term
"I/O routine". I think you are talking
about mvssupa. There is no BSM
switch (anymore, anyway) in that
code.

When I talk about "I/O routine doing
a BSM" I am referring to IBM routines
igg019ba and igg019dk (both shown
below).

This allows the application to run
without any AMODE switching at
all (quibbling aside), which means
that on z/OS the exact same module
can reside ATL - something that
wouldn't be possible if there were
any switches to AM24.

BFN. Paul.





C:\devel\mvssrc\osmods\igg019ba>cvs diff -r 1.1 igg019ba.asm
Index: igg019ba.asm
===================================================================
RCS file: /cvsroot/mvs380/mvssrc/osmods/igg019ba/igg019ba.asm,v
retrieving revision 1.1
retrieving revision 1.2
diff -r1.1 -r1.2
136a137,148

> * 31-bit mods
>          LA    RETR,0(RETR)   Clear the high byte or bit
>          LA    ENTRYR,MOD31A  We will branch to MOD31A
>          BSM   RETR,ENTRYR    R15 will have high byte clear,
> *                             and the top bit clear means it will
> *                             start executing in AMODE 24.
> *                             The R14 meanwhile will receive the
> *                             current AMODE.
> MOD31A   DS    0H
>          ST    RETR,20(SAVR)  R14 now contains AMODE in high bit
>          LR    ENTRYR,BASR    Put R15 back to previous state,
> *                             just in case
158c170,172
<          BR    RETR                    RETURN TO USER             10665
---
> * 31-bit mods
>          BSM   RZERO,RETR
> *        BR    RETR                    RETURN TO USER             10665
256c270,272
<          BR    RETR                    RETURN TO USER
---
> * 31-bit mods
>          BSM   RZERO,RETR
> *        BR    RETR                    RETURN TO USER

C:\devel\mvssrc\osmods\igg019ba>



C:\devel\mvssrc\osmods\igg019dk>cvs diff -r 1.1 igg019dk.asm
Index: igg019dk.asm
===================================================================
RCS file: /cvsroot/mvs380/mvssrc/osmods/igg019dk/igg019dk.asm,v
retrieving revision 1.1
retrieving revision 1.3
diff -r1.1 -r1.3
104a105,116

> * 31-bit mods
>          LA    R14,0(R14)     Clear the high byte or bit
>          LA    R15,MOD31A     We will branch to MOD31A
>          BSM   R14,R15        R15 will have high byte clear,
> *                             and the top bit clear means it will
> *                             start executing in AMODE 24.
> *                             The R14 meanwhile will receive the
> *                             current AMODE.
> MOD31A   DS    0H
>          ST    R14,12(R13)    R14 now contains AMODE in high bit
>          L     R15,16(R13)    Put R15 back to previous state,
> *                             just in case
1019c1031,1037
<          RETURN (14,12)                 RESTORE USER REGS
---
> *        RETURN (14,12)                 RESTORE USER REGS
> * 31-bit mods
>          LM    14,12,12(13)   When we restore all registers,
> *                             R14 will have the high bit set
> *                             if we were called in AMODE 31.
>          BSM   R0,R14         Now we return to the caller,
> *                             setting the AMODE on the way

C:\devel\mvssrc\osmods\igg019dk>


Reply | Threaded
Open this post in threaded view
|

Re: REVIEW/RFE Release 47.0

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
---In [hidden email], <kerravon86@...> wrote :

> Just to clarify - MVS/380, like MVS 3.8j, is
> not expecting to operate on any ATL
> addresses.

The sole exception is that FREEMAIN
can accept an ATL address on MVS/380
only.

BFN. Paul.
12