I prefer the idea that someone had a while back... (I've expanded the idea
slightly)...
Add a new JCL keyword PARMX= and save the data in a SWB control block along
with "// OUTPUT ADDRESS=" and other JCL keywords.
Then provide a service to return a pointer and length of this field
(RDPARMX - ala RDJFCB or even update EXTRACT).
I don't know what Cobol or other languages would do but I'm sure they can be
updated as well.
New code can start to use this new technique whereas old code would still
use PARM=.
Of course, program DOCUMENTATION should dictate which JCL keyword to use.
It could even be smart enough to check for EITHER PARM= or PARMX=.
I believe that coding BOTH should cause a JCL error.
This way, old code will not break and new (or updated) code can reap the
rewards.
DanD
----- Original Message -----
From: "Vernooij, CP - SPLXM" <kees.vern...@klm.com>
Newsgroups: bit.listserv.ibm-main
Sent: Wednesday, October 28, 2009 11:49 AM
Subject: Re: A modest PARM proposal
How can new programs determine if they received the new or the old format,
i.o.w. if they can/should process the data after byte 100 or not?
Kees.
"Thomas Berg" <thomas.b...@swedbank.se> wrote in message
news:<e46b4df55a5e8746855078ae31f1b180336f71d...@fspas01ev010.fspa.myntet.se>...
Although ignorant in this field, I'm wondering why this
approach wouldn't work (as noone is suggesting it):
Today: lengthfield + parm (max 100 bytes)
Tomorrow: lengthfield + parm (max 100 bytes) + padding to 102 bytes +
newlengthfield + newparm (max 4GiB ? :) )
This of course has the limitation means that the receiving part has to
add 102 to get the long parm.
But it will only affect new programs that need to handle more that 100
bytes parms, I think ?
Regards,
Thomas Berg
__________________________________________
Thomas Berg Specialist IT-U SWEDBANK
> -----Ursprungligt meddelande-----
> Från: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] För Shmuel Metz (Seymour J.)
> Skickat: den 28 oktober 2009 12:16
> Till: IBM-MAIN@bama.ua.edu
> Ämne: A modest PARM proposal
>
> Over the past decade there have been several discussions of
> issues relating to the size limit for PARM. The basic problems are:
>
> 1. The field in the SCT is only 100 characters.
>
> 2. While the OS/360 documentation said from day one that any main
> program could be used as a subroutine, some programmers assumed
> that their parameter lists came from the Initiator and were
> limited to a single parameter point to a HW+string that had
> at most 100 characters.
>
> 3. Some programmers used an EX of an MVC with length-1 into a 100
> byte field without checking whether the length exceeded 100 bytes.
>
> While I would argue that the programs mentioned in 2 and 3
> are broken, correcting all of them would be a lot more work
> then simply identifying them. Accordingly, I would like to
> throw a suggestion open for discussion that I believe will
> address the various issues that have been raised.
>
> 1. Provide something in the SWA that allows the C/I to pass a large
> PARM string to the Initiator.
>
> 2. Include a table in the C/I containing PARM size limits indexed by
> program name.
>
> 3. Provide for installation extensions and 3rd party extensions to
> the table, preferably driven by PARMLIB.
>
> 4. Provide a default of 32 KiB - 1or 64 KiB - 1for programs not in
> the table, with a facility for the installation to provide a
> smaller default limit.
>
> --
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access
> instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
**********************************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286
**********************************************************************
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
