In bcclb59aeniuip0fg518qmrtqp4ndfg...@4ax.com, on 09/23/2009
at 08:40 PM, Clark Morris cfmpub...@ns.sympatico.ca said:
I recall that the limit was 144 bytes and I always tested for either that
or the maximum size that my program would accept.
The size was never 144 and you were never
[rant]
This whole thread really irks me. Simply the idea that a program might move a
variable length string without first checking for limits is just appalling. I
would be pretty ashamed if I found I had done that in any of my personal
programs, let alone any code I wrote when I was working
OK - I was regretting my post somewhat, but perhaps this will reduce the pain:
APF authorized programs can be called from JCL, from a TSO TMP and from
Unix System Services. For TSO and -perhaps?- USS (note context) the
specific programs that can be called is restricted. The programs that can
On Thu, Sep 24, 2009 at 9:31 AM, Scott Rowe scott.r...@joann.com wrote:
[rant]
This whole thread really irks me. Simply the idea that a program might move
a variable length string without first checking for limits is just appalling.
I would be pretty ashamed if I found I had done that in
The problem is that in many companies the pressure is to make the schedule
rather than to write robust code. Additionally, the knowledge base of
competent z/OS programmers grows smaller each year. I have encountered
numerous cases of this and other 'appalling' coding practices during
On 24 Sep 2009 06:33:24 -0700, scott.r...@joann.com (Scott Rowe)
wrote:
[rant]
This whole thread really irks me. Simply the idea that a program might move a
variable length string without first checking for limits is just appalling. I
would be pretty ashamed if I found I had done that in any
Following this thread a while now and although some missing
competence (me) it seems to me that Binyamin Dissen had the
most practical suggestion.
My only input is: keep it simple, keep it general.
Regards,
Thomas Berg
__
Thomas Berg Specialist
On Wed, 23 Sep 2009 10:04:42 +0100, Terry Sambrooks wrote:
2) With my bias set aside, I acknowledge that the existing two byte prefix
associated with EXEC PARM data is capable of holding a length up to 65535
(X'') although this may appear negative depending upon field definition.
As an
On Thu, Sep 24, 2009 at 10:36 AM, Paul Gilmartin paulgboul...@aim.com wrote:
As an experiment, I tried calling BPXBATCH from Rexx with a 65535-byte
parm (x'' in the length field). It executed without error, and
correctly processed the entire PARM string.
VERY interesting. So a poorly
.
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
P S
Sent: Thursday, September 24, 2009 10:09 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Long parms ... again (was: Reading DD card information)
On Thu, Sep 24, 2009 at 10:36 AM, Paul Gilmartin
On Thu, Sep 24, 2009 at 11:29 AM, Hal Merritt hmerr...@jackhenry.com wrote:
CERT alert?
Bugs in authorized programs cause problems all the time. IBM even has a 'red
alert' newsletter to quickly inform the community when a bug in their code
poses a serious threat.
This is a key reason why
I doesn't have to be an end user interface, and you don't need update
access. Almost everyone has read access and can invoke authorized code in
authorized libraries.
Lou
Artificial Intelligence is no match for Natural Stupidity
Sent from Gurnee, IL, United States
On Thu, Sep 24, 2009 at 11:23
I understand the concerns, but this sounds like a good reason for all ISVs to
review their code. Consider the case of user key common storage: that took a
while to get code clean, but it was a good thing, and worth the effort.
My point is that there is no 100 byte limit on the interface,
On Thu, 24 Sep 2009 13:06:01 -0400, Scott Rowe
scott.r...@joann.com wrote:
I understand the concerns, but this sounds like a good reason for
all ISVs to review their code. ...
Not just ISV; shops should review their own code, too.
My point is that there is no 100 byte limit on the
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Patrick O'Keefe
Sent: Thursday, September 24, 2009 2:26 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Long parms ... again (was: Reading DD card information)
On Thu, 24 Sep 2009 13:06:01
At 14:08 +1200 on 09/23/2009, Gainsford, Allen wrote about Re: Long
parms ... again (was: Reading DD card information):
Any programmers who abide by these statements are not producing
defective code. They are following IBM's rules. Increasing the
PARM length will break perfectly valid
At 19:50 -0500 on 09/22/2009, Paul Gilmartin wrote about Re: Long
parms ... again (was: Reading DD card information):
For a good example of how your primary mode programs
can pass parameters, consider the way the system uses
a register to pass information in the PARM field of an
EXEC
On Thu, 24 Sep 2009 16:11:34 -0400, Robert A. Rosenberg wrote:
This provides a way to support PARMX while staying compatible with
PARM (and programs that use it). If PARMX is not supplied in the JCL,
act as now. If there is a PARMX pass a 2 FW list in R1 (with the
second FW flagged as
On Wed, 23 Sep 2009 01:23:26 -0400, Jim Mulder d10j...@us.ibm.com
wrote:
. . .
There is an extensive discussion of the long PARM
topic in the archives starting on May 12,2005, under
the subjects PARM= and Re: PARM= .
While this was being investigated, Karl Schmitz decided
to look at
What happens if the length of this thread exceeds 100 posts? Will
listserv 0C4? :-)
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at
On Thu, 24 Sep 2009 16:11:34 -0400 Robert A. Rosenberg hal9...@panix.com
wrote:
:At 19:50 -0500 on 09/22/2009, Paul Gilmartin wrote about Re: Long
:parms ... again (was: Reading DD card information):
:For a good example of how your primary mode programs
:can pass parameters, consider
I think its long past 100 posts. It only 0C4's after 256 posts!
Eric Bielefeld
Sr. Systems Programmer
Milwaukee, Wisconsin
414-475-7434
- Original Message -
From: Mark Zelden mark.zel...@zurichna.com
Subject: Re: Long parms ... again (was: Reading DD card information)
What
On Thu, Sep 24, 2009 at 6:45 PM, Eric Bielefeld eric-ibmm...@wi.rr.com wrote:
I think its long past 100 posts. It only 0C4's after 256 posts!
Nope, we're only in the 60s.
--
For IBM-MAIN subscribe / signoff / archive access
Jim Mulder wrote:
Karl Schmitz decided to look at some of IBM's APF authorized
programs in SYS1.LINKLIB to see if he could find one which assumed
that the parm length did not exceed 100. My recollection is that
the first one he looked at (selected from a component in which
he had
Hi,
Re-the appended text in quotes below:
1) I am not an advocate of long parm as I hold a personal opinion that it
would be clumsy in JCL, if the full length capability of a 2-byte field were
to be exploited.
2) With my bias set aside, I acknowledge that the existing two byte prefix
associated
On Tue, 22 Sep 2009 16:30:18 -0500 Paul Gilmartin paulgboul...@aim.com
wrote:
:On Tue, 22 Sep 2009 23:52:06 +0300, Binyamin Dissen wrote:
::I believe I stated pretty clearly above that I'd expect PARMX
::to replace the first PARM, not be added as a second.
:That violates compatibility.
:No, it
On Tue, 22 Sep 2009 21:41:52 + Ted MacNEIL eamacn...@yahoo.ca wrote:
:Thee is an obvious need for lifting the 100-byte limit on parms, but
:it needs to be done in a way that allows old programs to continue
:to work.
:100 bytes is only a limit for programmes called through JCL.
:If a
How about a new //SYSPARM DD instead?
If this were combined with a 'SYMBOLS=YES' option on the DD statement, as
Gil recommended earlier in this thread (I hope I got that attribution correct),
it
would not break existing programs, which would simply ignore the DD, not
expecting it.
Of course,
In a message dated 9/23/2009 7:28:19 A.M. Central Daylight Time,
bsqu...@umich.edu writes:
Having said that, I don't believe it is a large risk. Something like
PARMX, which
can be explicitly stated to ONLY work for programs that support it (I'm
talking
about documentation, not code)
On Wed, 23 Sep 2009 07:27:56 -0500 Robert Birdsall bsqu...@umich.edu wrote:
:Having said that, I don't believe it is a large risk. Something like PARMX,
which
:can be explicitly stated to ONLY work for programs that support it (I'm
talking
:about documentation, not code) puts the
On Wed, Sep 23, 2009 at 10:27 AM, Binyamin Dissen
bdis...@dissensoftware.com wrote:
On Wed, 23 Sep 2009 07:27:56 -0500 Robert Birdsall bsqu...@umich.edu wrote:
:Having said that, I don't believe it is a large risk. Something like
PARMX, which
:can be explicitly stated to ONLY work for
On Wed, 23 Sep 2009 10:40:33 -0400 P S zosw...@gmail.com wrote:
:On Wed, Sep 23, 2009 at 10:27 AM, Binyamin Dissen
:bdis...@dissensoftware.com wrote:
: On Wed, 23 Sep 2009 07:27:56 -0500 Robert Birdsall bsqu...@umich.edu
wrote:
: :Having said that, I don't believe it is a large risk. Something
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Binyamin Dissen
Sent: Wednesday, September 23, 2009 10:07 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Long parms ... again (was: Reading DD card information)
SNIP
You are missing the point
: Long parms ... again (was: Reading DD card information)
:You are missing the point.
:The APF program was written to the spec that the parameter will never be
:more
:than 100 characters, and it was enforced by JCL.
:SNIP
:What about the principle that you do not use KEY0 or SUPSTATE when
On Wed, Sep 23, 2009 at 11:06 AM, Binyamin Dissen
bdis...@dissensoftware.com wrote:
You are missing the point.
The APF program was written to the spec that the parameter will never be more
than 100 characters, and it was enforced by JCL.
You are changing the rules allowing an end user to
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Binyamin Dissen
Sent: Wednesday, September 23, 2009 10:36 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Long parms ... again (was: Reading DD card information)
On Wed, 23 Sep 2009 11:28:05 -0400
On Wed, 23 Sep 2009 11:59:26 -0400 Thompson, Steve
steve_thomp...@stercomm.com wrote:
:Might I suggest that you are being a bit myopic? Or perhaps suffering
:from tunnel vision?
Not at all. Concerned about compatibility.
:APF programs are to be written to a higher standard.
Granted.
But what
Sorry if this was already suggested, but how about a Language Environment
option that would enable/allow 100 parm values in JCL?
Then, you could have an installation default, and override it on a
particular job step, or link specific programs with LE options.
If you did this, then perhaps you
On Wed, Sep 23, 2009 at 10:59 AM, Thompson, Steve
steve_thomp...@stercomm.com wrote:
Might I suggest that you are being a bit myopic? Or perhaps suffering
from tunnel vision?
APF programs are to be written to a higher standard.
From what you have written, you believe that if someone
Sorry if this was already suggested, but how about a Language Environment
option that would enable/allow 100 parm values in JCL?
Considering the limit is enforced by JES, the SWA, the convertor, and the
interpreter, LE wouldn't stand a chance.
The limit is there before LE sees it.
-
Too busy
Of
Chris Craddock
Sent: Wednesday, September 23, 2009 12:30 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Long parms ... again (was: Reading DD card information)
On Wed, Sep 23, 2009 at 10:59 AM, Thompson, Steve
steve_thomp...@stercomm.com wrote:
Might I suggest that you are being a bit myopic
On Wed, 23 Sep 2009 12:57:46 -0400, Barkow, Eileen wrote:
The argument that an existing program cannot handle a longer parm area if it
was available is nonsense - just don't pass it the longer area and there will
not be a problem.
A perfect example on why a longer parm area over 100 bytes is
in order to fit every thing in.
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]
On Behalf Of Chris Craddock
Sent: Wednesday, September 23, 2009 12:30 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Long parms ... again (was: Reading DD card information)
On Wed
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Chris Craddock
Sent: Wednesday, September 23, 2009 11:30 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Long parms ... again (was: Reading DD card information)
On Wed, Sep 23, 2009 at 10:59 AM
Sorry if I wasn't clear. I meant that an LE option could be used to
control whether a user batch program would see 100 character parms.
I'm suggesting that z/OS itself be extended to support 100 character PARMS
(somehow), but that an LE option would control whether a user program would
ever
On Wed, Sep 23, 2009 at 2:30 PM, Kirk Wolf k...@dovetail.com wrote:
Sorry if I wasn't clear. I meant that an LE option could be used to
control whether a user batch program would see 100 character parms.
I'm suggesting that z/OS itself be extended to support 100 character PARMS
(somehow),
Sorry if I wasn't clear. I meant that an LE option could be used to
control whether a user batch program would see 100 character parms.
I'm suggesting that z/OS itself be extended to support 100 character
PARMS
(somehow), but that an LE option would control whether a user program
would
Allen,
I respectfully disagree:
1) how are two options cleaner? The usage would be ugly... the JCL coder
would have to think - let me see, should I use PARM with 100 or PARMX with
more? and what if both are coded?
2) a separate program api would require modifications to any program that
can
On Wed, 23 Sep 2009 16:53:03 -0500, Kirk Wolf
k...@dovetail.com wrote:
...
I respectfully disagree:
1) how are two options cleaner? The usage would be ugly...
the JCL coder would have to think - let me see, should I use PARM
with 100 or PARMX with more? and what if both are coded?
I see
On 23 Sep 2009 09:31:06 -0700, in bit.listserv.ibm-main you wrote:
On Wed, Sep 23, 2009 at 10:59 AM, Thompson, Steve
steve_thomp...@stercomm.com wrote:
Might I suggest that you are being a bit myopic? Or perhaps suffering
from tunnel vision?
APF programs are to be written to a higher
On Thu, 24 Sep 2009 09:24:25 +1200, Gainsford, Allen wrote:
Seems to me that it would be cleaner, and probably make more sense, if JCL
supported a PARMX parameter which was *not* passed to programs in the normal
way. Instead, provide a way for programs to *ask* for the PARMX: a macro
for
On Wed, 23 Sep 2009 20:40:43 -0300, Clark Morris wrote:
I recall that the limit was 144 bytes and I always tested for either
that or the maximum size that my program would accept.
That's octal.
-- gil
--
For IBM-MAIN subscribe
On Wed, 23 Sep 2009 10:09:50 +0200, Gilbert Saint-Flour wrote:
Jim Mulder wrote:
Karl Schmitz decided to look at some of IBM's APF authorized
programs in SYS1.LINKLIB to see if he could find one which assumed
that the parm length did not exceed 100. My recollection is that
the first
On Tue, 22 Sep 2009 08:15:59 +0300, Binyamin Dissen
bdis...@dissensoftware.com wrote:
...
:I'd be quite satisfied with this _provided_ it was compatible
:with the existing CALL, LINK, ATTACH, etc. argument lists.
:I.e. on program entry R1 points to a fullword which points
:to a halfword
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Patrick O'Keefe
Sent: Tuesday, September 22, 2009 2:36 PM
To: IBM-MAIN@bama.ua.edu
Subject: Long parms ... again (was: Reading DD card information)
SNIPPAGE
Whatever technique used to pass
On 22 Sep 2009 12:59:30 -0700, steve_thomp...@stercomm.com (Thompson,
Steve) wrote:
Whatever technique used to pass a long parm is not going to be
safely handled byt the old, standard parm passing scheme because
a long parm passed that way will break old, standard programs.
Some new technique
On Tue, 22 Sep 2009 14:35:40 -0500, Patrick O'Keefe wrote:
...
:I'd be quite satisfied with this _provided_ it was compatible
:with the existing CALL, LINK, ATTACH, etc. argument lists.
:I.e. on program entry R1 points to a fullword which points
:to a halfword containing the length of the PARMX
On Tue, 22 Sep 2009 14:35:40 -0500 Patrick O'Keefe patrick.oke...@wamu.net
wrote:
:On Tue, 22 Sep 2009 08:15:59 +0300, Binyamin Dissen
:bdis...@dissensoftware.com wrote:
::I'd be quite satisfied with this _provided_ it was compatible
::with the existing CALL, LINK, ATTACH, etc. argument lists.
On Tue, 22 Sep 2009 15:12:25 -0500 Paul Gilmartin paulgboul...@aim.com
wrote:
:On Tue, 22 Sep 2009 14:35:40 -0500, Patrick O'Keefe wrote:
::I'd be quite satisfied with this _provided_ it was compatible
::with the existing CALL, LINK, ATTACH, etc. argument lists.
::I.e. on program entry R1 points
On Tue, 22 Sep 2009 23:52:06 +0300, Binyamin Dissen wrote:
:I believe I stated pretty clearly above that I'd expect PARMX
:to replace the first PARM, not be added as a second.
That violates compatibility.
No, it preserves and extends compatibility. There are numerous
programs extant that now
Thee is an obvious need for lifting the 100-byte limit on parms, but
it needs to be done in a way that allows old programs to continue
to work.
100 bytes is only a limit for programmes called through JCL.
If a programme calls another, with standard linkage, the length can be a lot
longer.
I
On Tue, 22 Sep 2009 21:41:52 +, Ted MacNEIL wrote:
Thee is an obvious need for lifting the 100-byte limit on parms, but
it needs to be done in a way that allows old programs to continue
to work.
100 bytes is only a limit for programmes called through JCL.
If a programme calls another, with
That depends on the format of the PARM (or the expectation
of the called program).
There are standards.
If they have the half-word in front and follow the strandard, there is nothing
to reach for.
I think you are reaching,
You can call programmes with 'long, parms.
Only PGM= has the limit!
-
On Tue, 22 Sep 2009 23:25:35 +, Ted MacNEIL wrote:
There are standards.
If they have the half-word in front and follow the strandard, there is nothing
to reach for.
I think you are reaching,
Yes, but:
#2.8.1 z/OS V1R10.0 MVS Assembler Services Guide
You know the rest. It says example and convention, not
standard. Regardless, I'd like to see the two-byte length
followed by the PARM field preserved in any extension of a
PARM-like operand to a 65536 (it says two-byte, not halfword,
avoiding the implication that it's signed), or even just
But I consider this highly phobic: no one has yet evinced
an existing program, not intentionally written as a
refutation, that behaves in a dangerous or mysterious
fashion simply because it was invoked with a long PARM.
There is an extensive discussion of the long PARM
topic in the archives
66 matches
Mail list logo
