On Fri, 20 May 2005 08:47:43 -0400, Don Ault <[EMAIL PROTECTED]> wrote:
>I would like to thank all of you for the posts on PARM=. I had asked >Peter to make the initial posting, since I was not currently connected >to the IBM-MAIN forum. It is my job to come up with an acceptable >solution for long parms. I'm currently leaning towards the following >set of externals: > >- Specification of the long parms will follow the existing syntax, but >simply allow a longer specification. Based on all the comments, I am >now inclined to support the full 64K as opposed to some smaller length. Bad idea. See below. >- No change to the parms passed to the application. Halfword length, >followed by the parm data. Symbolic substitution supported. > >- There will be a system wide option to turn on/off the ability of the >system to process long parms. If the option is off, then a JCL error >will occur with parms > 100. Some of the reasons for this are: >1. Allow customers to maintain compatibility. >2. In a JES3 plex, all systems will need to be uplevel with z/OS and >JES3 in order for long parms to be supported. We might require a >compatibility APAR to detect cases where z/OS or JES3 mismatches on >parm support would create unacceptable behavior. For JES2, a mix of >systems in the plex would force users to set system affintiy in jobs >to make sure it runs on a system that supports long parms. > >- An operator command (or extention of existing >command) to turn the option on or off. Probably DISPLAY support as well. >(cost going up) > >- To address the integrity issue, programs linked with AC=1, coming from >APF authorized libraries, will require a new Binder attribute in order to >get past the converter/interpreter with parms > 100. Non-APF authorized >programs will not require the new attribute in order to process parms >100. >This basically says we accept the risk of passing long parms to >unauthorized >programs. Some may fail and produce undesired consequences, but this seems >better than forcing all unatuhorized application programs to be relinked >with this attribute. I will need to research whether we can get a new >attribute without requiring the program to reside in a PDSE. I don't think >I will be allowed to proceed without some protection for the APF authorized >programs. Another possibility is to only support long parms for >unauthorized >programs. The attribute could come in a followon release. Don, If you limit the long parms to 32K instead of 64K I have little issue, but by raising your limit to unauthorized programs to 64K you create an architectural problem: Old programs loading the "halfword length on a halfword boundary" length value using the LH instruction will receive negative values for such long parameters. They are unlikely to successfully handle such arithmetic values as they would have been very unanticipated when they were written some 30-35 years ago. If a 32K PARM string isn't long enough I hold out little hope that a 64K string is going to always satisfy the user's requirements. -- Tom Schmidt Madison, WI (Yes, old programs will be using LH instead of ICM since they may well have been written using the 360 instruction set. IBM promised not to break old programs with incompatible changes, remember?) ---------------------------------------------------------------------- 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
