> -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould > Sent: Wednesday, January 23, 2008 3:22 PM > To: [email protected] > Subject: Parm Length restriction was Re: Using an InfoPrint > 6500 with PSF > > > We have discussed on IBM-MAIN plenty of times about the restriction > of 100 characters in the parm field. The PSF proc is an example what > IBM had to go through in order to get around the 100 > character max. I > am *NOT* complaining but just showing those who have complained how > IBM got around its own 100 character max length restriction. > This is > the interesting as it shows how far IBM had to go to get around the > restriction. They basically had to add fields and change the > convertor/interpreter to allow for the "options". I'll bet a beer > that this cost IBM a fair amount of change in order to implement > these "new" JCL fields. While I am not saying increasing the length > would *NOT* have necessitated the changes (its probably a tossup) it > would have made implementation, IMO a LOT easier. Yes I know it was > re-written (and probably is for the best) but in any case it would > have been less costly. > > As a side issue are these new JCL parameters supported in dynamic > allocation? If not has anyone tried putting in a Share requirement > and if so what was the outcome? > > > Ed
And you just came up with a bit of a methodology that could be used (with some difficulty) in our own application programs. In a step which wants a PARM value > 100 characters, use something like: // PARM='abcd ' where "abcd" is the label of an // OUTPUT statement available to the application. You can then use many of the parameters on the OUTPUT statement for passing parameter information. For example, ADDRESS= can contain up to 4 subparameters, each of which can be up to 60 bytes. That is 240 characters. BUILDING gives another 60 characters (300 so far). DEPT gives yet another 60 (now 360 bytes). MAILBCC can be up to 32 addresses of 60 characters each, or 1920 bytes (now at 2280 bytes). MAILCC gives the same as MAILBCC (now up to 4200 bytes). MAILFILE gives another 60 bytes (4260 total). MAILFROM another 60 (4320 bytes). MAILTO another 32 by 60 characters (1920 more for 6240 bytes). NAME= for 60 more (6300 types). PRTATTRS for 127 characters (6427 bytes). PRTOPTNS for 16 characters (6443 bytes). PRTQUEUE for 127 bytes (6570 bytes). REPLYTO for 60 bytes (6630 bytes total, so far). ROOM gives another 60 bytes (6690 bytes). TITLE, another 60 bytes (6750 bytes). USERDATA gives 16 times 60 or 960 bytes (7710 bytes). USERPATH for 8 times 254 bytes or 2032 bytes (9742 bytes). WRITER give a final 8 bytes for a grand total of 9750 bytes, assuming I haven't misadded anywhere. Retrieving this data is left as an exercise for the user. But it would likely be done in an assembler subroutine. Oh, and that 9750 bytes is per OUTPUT statement. Now, going even crazier, you could architect your main program to only accept OUTPUT statement names in the PARM=. A PARM is 100 bytes. Assuming that you'd need a space as a separator, what is the maximum number of possible labels which could be given to the main routine? The first characters must be alphabetic or national. That's 29 values. The second through 6th can also be numeric. That's 39 values. So, there are 29 single character labels, taking 2 characters (trailing blank). That's 58 characters, leaving 42. In that, you can put 14 more 2 character labels. That's a total of 43 possible labels of OUTPUT statements, each possibly having 9750 bytes of "parameter" information, for a super grand total of 419,250 bytes of "parameter" information. WOW! I exceeded the magic 64K! -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. ---------------------------------------------------------------------- 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
