Re: IEAMSCHD and SRB entry questions

[Peter Relson]

>I accept what the current state of the documentation says. However, when
>z/OS is touted as 64-bit capable, shouldn't a continous effort be driven 
whereby
>all invoked system system services eventually are AMODE(64) capable ??
>(disregard the restricted location of certain control blocks for now  
I'm
>merely referring to invoking a service whilst running in AMODE(64))

It would be nice to be able to answer "yes". Everything we do, and likely 
everything you do, is based on a business decision. Would you prefer we 
spend time working on that versus providing function that you can't 
accomplish on your own?

>I was kind of disappointed when IBM initially gave the list of services 
that
>could be called from AMODE 64.(as long as the parameters were below the 
bar).
>I mentioned that the hardware does all the work for a PC from a 64 bit 
caller,
>so stating "support" really didn't require any code changes. All my PC
>routines equally supported 64bit callers.

We have tried, largely unsuccessfully, to get from ISVs a list of services 
most important to them in this regard, so that a prioritized list could 
guide any implementation effort. I presume you are talking about entry in 
AMODE 64 but not data above 2G. The cost of having many services 
(especially older ones) support data above 2G is generally deemed to be 
too high for the value.

>The main "gotchas" are macro expansions that have not yet been updated to 

>use grande instructions when SYSSTATE AMODE64=YES is in effect.

Anything that takes the approach of accepting an AMODE 64 caller while 
assuming that data is below 2G cannot then compatibly be expanded to 
accept AMODE 64 with data above 2G. It could do so only by the user 
indicating some new option and possibly going to a new entry point.  For 
example, suppose the existing service uses only the low half of register 1 
to address the parameter list. Then suppose the service accepts an AMODE 
64 caller only by changing the macro's instructions that chain through a 
control structure to locate the SVC number or PC number. It is now 
possible that the service is entered with register 1 high half containing 
garbage. That is OK until the target routine might want to code "if caller 
is AMODE 64 then use 64-bit register 1". It can't do so compatibly. The 
caller would need to indicate "you may use 64-bit address" and we would 
probably do something similar to what some DFSMS services did, in setting 
register 1 to some value that could not logically be a parameter list 
address, and putting the parameter list address into some other register. 
The target routine would check if register 1 is the special value to 
determine where to get the parameter list address.

Thus we tend to be quite conservative about this sort of change, to avoid 
locking ourselves into an implementation. If we have left the service "not 
AMODE 64" then it would be compatible to implement "if AMODE 64, then the 
parameterlist and/or data can be above 2G".

Are we all that likely to enhance our older services to support data above 
the bar? Not in most cases. But it's hard to know for sure.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IEAMSCHD and SRB entry questions

[Binyamin Dissen]

I was kind of disappointed when IBM initially gave the list of services that
could be called from AMODE 64.(as long as the parameters were below the bar).
I mentioned that the hardware does all the work for a PC from a 64 bit caller,
so stating "support" really didn't require any code changes. All my PC
routines equally supported 64bit callers.

On Mon, 13 Jun 2016 10:48:54 -0700 Ed Jaffe 
wrote:

:>On 6/13/2016 10:12 AM, Andre Schoeman wrote:
:>>> Since the documentation for IEAMSCHD says that AMODE 64 is not supported,
:>>> you are taking a risk that your code might at any point stop behaving
:>>> properly. That is your choice, but it is your (and your users') risk. Is
:>>> there any plan to do so in the immediate future? Not that I know of. Would
:>>> any such plan be announced? Probably not.
:>> I accept what the current state of the documentation says. However, when
:>> z/OS is touted as 64-bit capable, shouldn't a continous effort be driven 
whereby
:>> all invoked system system services eventually are AMODE(64) capable ??
:>> (disregard the restricted location of certain control blocks for now   
I'm
:>> merely referring to invoking a service whilst running in AMODE(64))
:>
:>I have stated before (possibly in other forums -- certainly at TDMs) 
:>that our approach is to try to help IBM and the z/OS community identify 
:>existing system services that don't work for AMODE(64) callers. IBM has 
:>only limited manpower to test z/OS services, so we test them for them by 
:>invoking them in real-world AMODE(64) code.
:>
:>That means we completely disregard documentation that states a service 
:>requires 31-bit mode and rely solely on the results our own empirical 
:>testing. (Of course, we limit AMODE(64) invocations to SVC and PC-based 
:>services and never even try to invoke LINKAGE=BRANCH services in 
:>AMODE(64) because we know that won't work.)
:>
:>What we've discovered is that _nearly all_ SVC and PC-based services 
:>work just fine so long as you pass the parameters below the bar. The 
:>main "gotchas" are macro expansions that have not yet been updated to 
:>use grande instructions when SYSSTATE AMODE64=YES is in effect. Usually, 
:>all you must do is clear XGR 14,14 (or another register) before invoking.
:>
:>Is it a risk? Of course! IBM is free to change these interfaces at any 
:>time without warning and we're happily prepared to adapt our code as 
:>necessary in the event the macro expansion changes or they choose to 
:>support AMODE(64) callers in an incompatible way (hopefully on a release 
:>boundary).
:>
:>For us, improved performance, better code readability, and (hopefully) 
:>fewer changes down the road when those services finally do "officially" 
:>support AMODE(64) callers,  are worth that risk. YM-AS-MV (Your Mileage 
:>-- And Sensibilities -- May Vary).

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IEAMSCHD and SRB entry questions

[Ed Jaffe]

On 6/13/2016 10:12 AM, Andre Schoeman wrote:

Since the documentation for IEAMSCHD says that AMODE 64 is not supported,
you are taking a risk that your code might at any point stop behaving
properly. That is your choice, but it is your (and your users') risk. Is
there any plan to do so in the immediate future? Not that I know of. Would
any such plan be announced? Probably not.

I accept what the current state of the documentation says. However, when
z/OS is touted as 64-bit capable, shouldn't a continous effort be driven whereby
all invoked system system services eventually are AMODE(64) capable ??
(disregard the restricted location of certain control blocks for now   I'm
merely referring to invoking a service whilst running in AMODE(64))


I have stated before (possibly in other forums -- certainly at TDMs) 
that our approach is to try to help IBM and the z/OS community identify 
existing system services that don't work for AMODE(64) callers. IBM has 
only limited manpower to test z/OS services, so we test them for them by 
invoking them in real-world AMODE(64) code.


That means we completely disregard documentation that states a service 
requires 31-bit mode and rely solely on the results our own empirical 
testing. (Of course, we limit AMODE(64) invocations to SVC and PC-based 
services and never even try to invoke LINKAGE=BRANCH services in 
AMODE(64) because we know that won't work.)


What we've discovered is that _nearly all_ SVC and PC-based services 
work just fine so long as you pass the parameters below the bar. The 
main "gotchas" are macro expansions that have not yet been updated to 
use grande instructions when SYSSTATE AMODE64=YES is in effect. Usually, 
all you must do is clear XGR 14,14 (or another register) before invoking.


Is it a risk? Of course! IBM is free to change these interfaces at any 
time without warning and we're happily prepared to adapt our code as 
necessary in the event the macro expansion changes or they choose to 
support AMODE(64) callers in an incompatible way (hopefully on a release 
boundary).


For us, improved performance, better code readability, and (hopefully) 
fewer changes down the road when those services finally do "officially" 
support AMODE(64) callers,  are worth that risk. YM-AS-MV (Your Mileage 
-- And Sensibilities -- May Vary).


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IEAMSCHD and SRB entry questions

[Andre Schoeman]

>>Note that all the GPR's in the issuing code are purified to contain "clean" 
>>31-bit addresses
>>before the IEAMSCHD is issued.

>That's not good enough. Your SRB routine, which received control in 31-bit 
>mode cannot make 
>any assumptions about the high halves of the registers.

I mentioned that in relation to the fact that an AMODE(64) module issued the 
IEAMSCHD whilst
the doc states AMODE(31) is required ... didn't have any assumptions about 
the SRB routine
itself.

>>As of late (I suspect since z/OS V2R1), the high halves (bits 0-31) of all 
>>GPRs, and the ARs,
>>contain x'' when the SRB routine is entered (the routine is scheduled 
>>in KEY=0
>>with PASN=SASN=HASN), even if (in the case of the GPRs) bits 32-63 is zero.

>As Ed pointed out, this is a DIAG trap that is intended to help you to find 
>errors in your code 
>where you assume that the high halves are zero when they may not be.

Indeed! I found that out the hard way ...

Thanks to everyone who responded to this  learnt a few lessons here.

Best regards, Andre

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IEAMSCHD and SRB entry questions

[Andre Schoeman]

>Since the documentation for IEAMSCHD says that AMODE 64 is not supported, 
>you are taking a risk that your code might at any point stop behaving 
>properly. That is your choice, but it is your (and your users') risk. Is 
>there any plan to do so in the immediate future? Not that I know of. Would 
>any such plan be announced? Probably not.

I accept what the current state of the documentation says. However, when
z/OS is touted as 64-bit capable, shouldn't a continous effort be driven whereby
all invoked system system services eventually are AMODE(64) capable ??
(disregard the restricted location of certain control blocks for now   I'm
merely referring to invoking a service whilst running in AMODE(64))

>Regardless, the AMODE of the target SRB is not AMODE 64, and the high 
>halves are not part of the interface. You must make no assumption about 
>those values other than what has been documented.
>So aside from observing that they are FF's, why do you care?

The SRB routine was created as a 64-bit routine and immediately switches
to AMODE(64) upon getting control. Since SRB routines receive control in
AMODE(31), I did not expect or depend on any specific values in the high
halves of the GPR's or the AR's. I was merely interested why that condition
existed and Ed's comment about the DIAGxx member explained that.

Best regards, Andre

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IEAMSCHD and SRB entry questions

[Ed Jaffe]

On 6/13/2016 6:52 AM, Tom Marchant wrote:

On Fri, 10 Jun 2016 14:39:35 -0700, Andr é Schoeman wrote:


As of late (I suspect since z/OS V2R1), the high halves (bits 0-31) of all 
GPRs, and the ARs,
contain x'' when the SRB routine is entered (the routine is scheduled 
in KEY=0
with PASN=SASN=HASN), even if (in the case of the GPRs) bits 32-63 is zero.

As Ed pointed out, this is a DIAG trap that is intended to help you to find 
errors in your code
where you assume that the high halves are zero when they may not be.


These traps also "dirty" the access registers. We have found many bugs 
in our code with these traps, and quite a few in IBM's code as well...


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IEAMSCHD and SRB entry questions

[Tom Marchant]

On Fri, 10 Jun 2016 14:39:35 -0700, Andr é Schoeman wrote:

>Note that all the GPR's in the issuing code are purified to contain "clean" 
>31-bit addresses
>before the IEAMSCHD is issued.

That's not good enough. Your SRB routine, which received control in 31-bit mode 
cannot make 
any assumptions about the high halves of the registers.

>As of late (I suspect since z/OS V2R1), the high halves (bits 0-31) of all 
>GPRs, and the ARs,
>contain x'' when the SRB routine is entered (the routine is scheduled 
>in KEY=0
>with PASN=SASN=HASN), even if (in the case of the GPRs) bits 32-63 is zero.

As Ed pointed out, this is a DIAG trap that is intended to help you to find 
errors in your code 
where you assume that the high halves are zero when they may not be.

-- 
Tom Marchant.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IEAMSCHD and SRB entry questions

[Peter Relson]

Since the documentation for IEAMSCHD says that AMODE 64 is not supported, 
you are taking a risk that your code might at any point stop behaving 
properly. That is your choice, but it is your (and your users') risk. Is 
there any plan to do so in the immediate future? Not that I know of. Would 
any such plan be announced? Probably not.

Regardless, the AMODE of the target SRB is not AMODE 64, and the high 
halves are not part of the interface. You must make no assumption about 
those values other than what has been documented.
So aside from observing that they are FF's, why do you care?

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IEAMSCHD and SRB entry questions

[J R]

No. Not quite identical. He spelled his name differently. 

Sent from my iPhone

> On Jun 10, 2016, at 18:36, Ed Jaffe  wrote:
> 
>> On 6/10/2016 2:39 PM, Andr é Schoeman wrote:
>> I've got code that schedules a SRB routine (using IEAMSCHD), since z/OS 
>> V1R13 (successfully).
> 
> Yes. You have two identical posts saying the same thing...
> 
>> Q2: When was the filling of bits 0-31 with x'' in the GPRs and ARs 
>> introduced ???
> 
> I think it was OS/390 V2R6 with the IeaInitRegsTask DIAG TRAP. Check your 
> DIAGxx member.
> 
>> Q3: Is the filling of bits 0-31 with x'' specific to a 
>> PASN=SASN=HASN environment ???
> Not that I recall. The IeaInitArSrb does the same thing for SRBs.
> 
> -- 
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.com/
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IEAMSCHD and SRB entry questions

[Ed Jaffe]

On 6/10/2016 2:39 PM, Andr é Schoeman wrote:

I've got code that schedules a SRB routine (using IEAMSCHD), since z/OS V1R13 
(successfully).


Yes. You have two identical posts saying the same thing...


Q2: When was the filling of bits 0-31 with x'' in the GPRs and ARs 
introduced ???


I think it was OS/390 V2R6 with the IeaInitRegsTask DIAG TRAP. Check 
your DIAGxx member.



Q3: Is the filling of bits 0-31 with x'' specific to a PASN=SASN=HASN 
environment ???

Not that I recall. The IeaInitArSrb does the same thing for SRBs.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

IEAMSCHD and SRB entry questions

[Andr é Schoeman]

I've got code that schedules a SRB routine (using IEAMSCHD), since z/OS V1R13 
(successfully).
Although the manual states that the issuer of IEAMSCHD must be AMODE(31), the 
issuer actually
runs in AMODE(64) and all schedules have been successful, the SRB routine 
receives control (in AMODE31)
and completes successfully.
Note that all the GPR's in the issuing code are purified to contain "clean" 
31-bit addresses
before the IEAMSCHD is issued.

As of late (I suspect since z/OS V2R1), the high halves (bits 0-31) of all 
GPRs, and the ARs,
contain x'' when the SRB routine is entered (the routine is scheduled 
in KEY=0
with PASN=SASN=HASN), even if (in the case of the GPRs) bits 32-63 is zero.


Q1: Is the doc in need of updating to support AMODE(64) callers of IEAMSCHD, or 
am I running the risk of
a failure here (S0C4 comes to mind) ???

Q2: When was the filling of bits 0-31 with x'' in the GPRs and ARs 
introduced ???

Q3: Is the filling of bits 0-31 with x'' specific to a PASN=SASN=HASN 
environment ???

Apologies if my questions have been addressed in previous posts, but I searched 
and couldn't
find any prior info on this.

Best regards, André

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

IEAMSCHD and SRB entry questions

[André Schoeman]

I've got code that schedules a SRB routine (using IEAMSCHD), since z/OS V1R13 
(successfully).
Although the manual states that the issuer of IEAMSCHD must be AMODE(31), the 
issuer actually
runs in AMODE(64) and all schedules have been successful, the SRB routine 
receives control (in AMODE31)
and completes successfully.
Note that all the GPR's in the issueing code are purified to contain "clean" 
31-bit addresses
before the IEAMSCHD is issued.

As of late (I suspect since z/OS V2R1), the high halves (bits 0-31) of all 
GPRs, and the ARs,
contain x'' when the SRB routine is entered (the routine is scheduled 
in KEY=0
with PASN=SASN=HASN), even if (in the case of the GPRs) bits 32-63 is zero.


Q1: Is the doc in need of updating to support AMODE(64) callers of IEAMSCHD, or 
am I running the risk of
a failure here (S0C4 comes to mind) ???

Q2: When was the filling of bits 0-31 with x'' in the GPRs and ARs 
introduced ???

Q3: Is the filling of bits 0-31 with x'' specific to a PASN=SASN=HASN 
environment ???

Apologies if my questions have been addressed in previous posts, but I searched 
and couldn't
find any prior info on this.

Best regards, André

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN