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. - 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. - IBM would investigate all its AC=1 programs to make sure they either handle parms >100 or fail appropriately. Ones that would benefit from supporting parms >100 would have the new attribute set. - Modify TSO commands CALL, TEST and TESTAUTH to support longer parms. Not sure whether this will be 64K. - Possibly modify REXX to support longer parms. Today, I belive the limit is 500 characters. - Possibly modify BPXBATCH to accept more than 500 characters (todays limit). - From an internal perspective, SWAREQ allows you to retrieve the SCT which contains the parm length. This length will reflect the total length of the parm specification. If greater than 100, then the user would call SWAREQ to retrieve a new block(s) which would contain the long parms in segments. The primary inhibitor to getting this implemented will be the cost. If I load it with too many bells and whistles, it won't make it into plan. All comments appreciated. Don Ault ---------------------------------------------------------------------- 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
