In a recent note, Jan MOEYERSONS said: > Date: Wed, 3 Jan 2007 02:43:50 -0600 > > >>BTW: I know *existing* OS/390 application using more than 256 bytes in > >>PARM. > I really would like to see a (working!) example of such a gismo... > I do it regularly with HLASM called from Rexx (not from JCL). Or, at least I used to before we mostly converted to Tachyon. Do you really need an example?
> >I was given a whole C library full of functios to recompile. the number of > >parms on EXEC PGM=CCNDRVR exceed the PARM field length limit. Without > >editting indvidual functions what's the best work-around? > You can use PARM='/OPTFILE(DD:COPT)' and then put all the parms in > //COPT DD * > o If this doesn't support symbol substitution, it falls short of many people's needs. o If this can't be used with an instream data set in a library PROC, it falls short of many people's needs. (No, it's not satisfactory to provide the COPT with an overriding DD.) The OPTFILE circumvention is a stopgap with functional restrictions (above), which is implemented haphazardly in some, not all, utilities, likely with inconsistent syntax. If the Convertor/Interpreter/Initiator were to automate the process by: o Automatically reading the OPTFILE DD and converting to the traditional R1 points to halfword length followed by PARM text. o Supporting OPTFILE as an instream data set in library PROCs o Supporting symbol substitution within the OPTFILE instream data ... it would be closer to the requirement. But why not merely relax the 100-character limit on PARM? It makes no sense to retain a limit motivated by storage prices which have since dropped by five(?) orders of magnitude. -- gil -- StorageTek INFORMATION made POWERFUL ---------------------------------------------------------------------- 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
