At present, all my HLASM code checks for the high order bit to be '1'b. Even for fixed length parameter lists. Why? Because I don't trust the programmers using my code to call it correctly. Therefore, I do as many validations as I can before performing any operations. I got into this habit due to a really messy HLASM subroutine that I had to rewrite. It had a tendency to not validate anything. And did some amazing memory overlays in CICS, some of which crashed CICS itself.
If a validation error occurs, I either return a return code which is architected as meaning "either the wrong number of parameters or an invalid parameter value has been detected.", or I force an ABEND. I only ABEND when I update an existing program which was not designed to return a return code, because I know the calling code will not check it. In the past, I caused an S0C3 via an EX of itself. I have changed this to an S0C1 by doing a BRC to *+2 (Jcond *+2) because I have changed my assembly technique to use relative addressing as well as being LE enabled (in most cases). I actually prefer LE enabled assembler in most cases. Mainly because: (1) it interoperates better with HLLs like COBOL, PL/I, FORTRAN, and C/C++, both as caller and as callee; (2) I can use subroutines written in those languages easily; and (3) if I abend in my assembler code, I get a CEEDUMP. This latter is very nice when I am writing a UNIX shell command because it puts the CEEDUMP in a uniquely named file in the current directory. It's difficult to get a SYSUDUMP type abend dump from a UNIX shell command. And the CEEDUMP is usually sufficient for my debugging. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Bernd Oppolzer > Sent: Tuesday, April 10, 2012 5:49 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: PL/I with variable PLISTs (was: LE C calling HLASM) > > I would not blame PL/1 for this. > It is not OK IMHO to request the caller to set the > high order bit on the last parameter, when the number of the > parameters > is fixed > (see also my GDDM example on the other post). This is not required by > any OS convention, > at least that's my understanding. > > Kind regards > > Bernd > > > > Am 11.04.2012 00:19, schrieb Frank Swarbrick: > > I don't know if this is relevant, but I was looking at the > PL/I DL/I (IMS) interface (PLITDLI) and noticed that they > actually have to pass, as the first parameter, a fullword > containing the remaining number of items! Crazy! > > > > For example, in COBOL you say: > > > > call 'CBLTDLI' using ghnp, pcb-mask, i-o-area, ssa-1 ssa-2. > > > > In PL/I it looks like you'd do something like this: > > call PLITDLI (five, ghnp, pcb-mask, i-o-area, ssa-1 ssa-2); > > > > See here for more details: > > > http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.j > sp?topic=%2Fcom.ibm.ims11.doc.apg%2Fims_imsdbpliapp.htm > > > > I was pretty happy about what I learned about PL/I until I > saw this. Yuck! > > > > Frank > > > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
