360/20 (vintage 1970) didn't have BAL/BALR instructions, it had BAS/BASR. Tom Puddicombe Mainframe Performance & Capacity Planning CSC
71 Deerfield Rd, Meriden, CT 06450 ITIS | (860) 428-3252 | tpudd...@csc.com | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. Gilbert Saint-Flour <usenet5...@yahoo.com> Sent by: IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> 02/10/2009 09:49 AM Please respond to IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> To IBM-MAIN@bama.ua.edu cc Subject Re: Assembler Question - AMODE=24 LINKINST was added to the CALL macro in 1997 (OS/390 R2). Frankly, I don't remember ever noticing it, let alone using it. What I remember is what I went through when I started to work in XA in 1988/1989 and ESA in 1991. I started to modify programs which were all AMODE=24 to switch to AMODE=31, like I saw the SDSF code do in ISFSRC. A few months later, I realised that it would be better to write AMODE=ANY code which CALLs AMODE=ANY sub-routines which switch to AMODE=24 when they have to (mostly GET/PUT, READ/WRITE), and made appropriate changes in sub-routines for them to work in MVS/370, MVS/XA and MVS/ESA. So, for the last 20 years, I used this type of approach in most of my assembler code and don't care about what's available to switch AMODE in MVS, VM and VSE. In 2003, I realised that it was unlikely that my programs would ever have to work in a system older than DFSMS/MVS, so I removed all the AMODE=24 code from GET/PUT, READ/WRITE sub-routines. I don't think I ever used SYSSTATE or made much difference between BASR and BALR and can't imagine why someone would worry about this in 2009. The only thing I remember is the problem about 24-bit address constants in various control-blocks (DCB, RB, SWA, ...) which many of my programs and sub-routines have to deal with. And, almost always, I code BAL/BALR and rarely BAS/BASR. I started coding assembler on a 360/20 in 1972, so call that an old habit. -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ On Tuesday 10 February 2009 14:53, Farley, Peter x23353 wrote: >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On >> Behalf Of Edward Jaffe >> Sent: Monday, February 09, 2009 6:50 PM >> To: IBM-MAIN@bama.ua.edu >> Subject: Re: Assembler Question > <Snipped> >> I haven't coded a BALR for program linkage in decades. Up until a few >> years ago, I still used it on occasion to "sense" the current AMODE. > > Indeed, and do you then always use the LINKINST=BASR keyword on the CALL > macro to force the macro not to use BALR? What do you do about the WTO > macro which always generates a BAL around the message text? Etc., etc., > pick your system macro and observe the BAL/R's and other ancient > instructions all over the place. > > <smallrant> > I am occasionally somewhat peeved at IBM for failing to provide different, > non-24-bit macro expansions when the programmer goes to the trouble of > coding SYSSTATE ARCHLVL=2 (or any other mechanism they might care > to invent). > > Even GET/PUT could use BASR, AFAIK, unless they too are using the BALR > to detect AMODE. Which ought to be documented, if true. > </smallrant> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
