Peter, I would think that simply extending the length to > 100 would be the best change.
1) The documentation side of the equation would be minimal 2) All old programs would work, unchanged, with their current set of parameters they all know and love, and have worked since the '60s. 3) The existing plist format is light and simple - there really isn't a place to insert a bit flag somewhere that says this is the new, possibly longer format. Any hey - who ever would need more than 32,767 bytes of parms???? :-) (I mean, why stop at 256?) Going to a new JCL keyword, like PARMX= or something like that, would be OK for specification on the human side of the issue. On the JCL side, it would be nice to point to a DD that contained the parms, whether it was a DD * or a seq file. Internally in the plist though, I would lean towards leaving it in the same format. //MYJOB EXEC PGM=IEFBR14,PARMX=MYDATA //MYDATA DD * This is my parm data. It can be VWERY, VWERY long. Elmer. //* Todd ----- Original Message ----- From: "Peter Relson" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Thursday, May 12, 2005 4:36 PM Subject: PARM= > We all know and love (well, at least know) that the limitation > in JCL for PARM= is 100 total characters. We are thinking (again) > about expanding this, and would like to hear your thoughts. > > Some of the possibilities include > - just extending, in JCL processing, so that the target routine > gets what it does today (halfword length followed by string, > only the string would potentially be >100). This is obviously > the nicest from the target routine's perspective if it can handle > the extended length > - a service that the target routine can call to "give me my parameters". > Obviously the target routine would have to change in order to utilize > that service, and likely would have to dual-path for systems that do > not have the service > > One choice that proved not feasible was using a second parameter. > Various utilities already take advantage of the "known" structure > and pass additional data as additional parameters. > > Some of the potential problems an existing target routine might have > with an extended length parameter are > - It provided an area via DS of 100 characters, "knowing" that the > limit was 100, and then did an EX (execute) of an MVC to move the > parameter string, using the length in the halfword. Unfortunately, > if the length is (for example), 256, this would overlay the next 156 bytes > - It did some operation (MVC, TRT, whatever) that is limited to 256 > characters which works fine when the limit is 100, but if the routine > was passed 257 characters of data, it might process that as 257 mod 256 > characters in some ways. ---------------------------------------------------------------------- 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
