John:
My first reaction when I began following this thread when I heard someone say
they only moved 100 bytes regardless of length, was TOO BAD. I ALWAYS used the
supplied length, then I realized that knowing it would never exceed 100 bytes,
I picked up the length, did a BCTR on the length and executed a move to save
the parm...... OOPS. That would not be good either if they made the length
greater than 256. So granted changing it may catch a lot of code.
Perhaps a new parameter like NEWPARM=" " that way they could add support for a
larger list without affecting old code. When you need it, just code the new
name in the JCL and check the program.
Bill
> Date: Fri, 4 Jan 2008 13:45:42 -0600> From: [EMAIL PROTECTED]> Subject: Re:
> JCL parms> To: [email protected]> > > -----Original Message-----> > From:
> IBM Mainframe Discussion List > > [mailto:[EMAIL PROTECTED] On Behalf Of
> Howard Brazee> > Sent: Friday, January 04, 2008 1:38 PM> > To:
> [email protected]> > Subject: Re: JCL parms> > > > > > On 4 Jan 2008
> 10:28:37 -0800, in bit.listserv.ibm-main you wrote:> > > > >I'd be overjoyed
> if IBM would admit to the possibility of a > > parm string > > >up to 32,767
> bytes, and design parm-driven software with > > that in mind. > > >And allow
> JCL to accept a parm of that length. Changes to > > code would be > >
> >minimal, since it already uses a halfword length. Changes to JCL > >
> >processing might be rather major, so I don't expect this to be done > >
> >overnight, as long as it's kep in mind.> > > > Why should this be a problem
> in JCL processing? Do you expect there> > will be jobs that depend upon the
> current limitations?> > Yes. I know of some programs which move the PARM into
> their own,> predefined, storage. Said storage is DC CL100. And they don't
> check that> the input is <=100 characters. Poor planning, but none-the-less.>
> > I also like my "environment variable" idea because I'm lazy. I can fetch>
> the contents of an environment variable by name and not need to parse> the
> PARM looking for it.> > --> 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
----------------------------------------------------------------------
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
