On Wed, 14 Oct 2015 08:22:49 -0400 Peter Relson <[email protected]> wrote:
:>>Then the doc for SVCs 68, 138 should be fixed. :>If by "the doc" you mean the information in the diagnosis reference, the :>information for SVC 138 is probably wrong but that book does not document :>requirements. :>The documentation for PGSER, for example, correctly documents that there :>is no reg 13 requirement (at least for SVC-entry). :>If you're referring to other doc, please clarify. :>Apparently for SVC 68 SYNADAF R13 must point to a "save area" but it is :>not used to save/restore the SVC issuer's registers. The real requirement :>appears to be that the word at offset 8 in the area pointed to by R13 be :>updateable (since the service does, in effect, save area chaining to/from :>the new area that is gotten). No need for this. It should be changed. :>>>I quite strongly disagree. :>>Why? :>For exactly the reasons I described. Further, it is clearer and simpler, :>if you truly need to change AMODEs, just to do so, rather than to branch :>somewhere (BASSM) to accomplish that. Prior to the existence of SAMxx, the :>BSM instruction was the normal way to change AMODE. Some prefer to use the old ways until they can get comfortable with the new. -- Binyamin Dissen <[email protected]> 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 [email protected] with the message: INFO IBM-MAIN
