On Tue, 22 Sep 2009 08:15:59 +0300, Binyamin Dissen wrote: >On Mon, 21 Sep 2009 19:58:13 -0400 "Robert A. Rosenberg" wrote: > >:>At 14:54 -0500 on 09/21/2009, Paul Gilmartin wrote about Re: Reading >:>DD card information: > >:>>I'd be quite satisfied with this _provided_ it was compatible >:>>with the existing CALL, LINK, ATTACH, etc. argument lists. >:>>I.e. on program entry R1 points to a fullword which points >:>>to a halfword containing the length of the PARMX followed >:>>by the PARMX string. > >:>>(And that symbol substitution would work within PARMX.) > >:>>But how would this facilitate implementation? > >:>This would need one extra detail. That is the existence of a PARMX >:>overrides the existence of a PARM. This means that if I supply both a >:>PARM and a PARMX on the EXEC card, that the PARM (and its contents) >:>are ignored and the R1 only points at the PARMX supplied string. This
My inclination would be to make them mutually exclusive. But Bob Schramm proposed a scheme where a distinguished value of PARM would indicate that PARMX should be used instead. I chose not to dispute that then, but I will now. If PARMX is provided, PARM should be ignored, or even prohibited. BTW, I'd be agreeable to a specification that PARMX may reside above the 16MiB line. >:>keeps the interface compatible with the current PARM (except that the >:>halfword can now contain a value over 100). > As much as 32767, or perhaps 65535. Yah, I know that the s/360 hardware has no support for unsigned halfword arithmetic, but it can be done in software -- that's what ICM is for. >:>To support passing both PARM and PARMX at the same time would need >:>some way of signaling that R1 points at 2 Full Words not one. Since >:>the current interface does not turn on the high bit (end of parms >:>flag) in the R1 indicated FW there is no way to indicate that >:>information. It MIGHT be possible to use the R1 with the low bit on >:>(ie: Pass an odd address like is done to indicate 64-bit addresses) >:>to signal a two FW parm list but that has other compatibility >:>problems with old code. > 31-bit has fewer compatibility problems than 64-bit. >Actually the current interface does set the high order bit of the word >pointing to the parm to x'80'. All (almost all?) IBM utilities support a three >word plist, where the second word points to a list of overriding DDNAMEs and >the third word points to a starting page number. > How about saying "many"? --gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
