Some of our choices don't matter as much anymore. It is easy to see
the advantage of a date in the format of MMDD if all we're doing
is comparing to see which date is older.
But if we are doing anything more complicated - just send the date to
a function library to do the processing. When
Paul Gilmartin asked:
So I wonder why the scheme chosen was not the last 4
digits of +8900. It would have matched the chosen
scheme for the 20th and 21st centuries, and provided for
smooth extension to the 19th and earlier.
Nobody was expecting to run into any SMF records with
dates
On Fri, 25 Sep 2009 16:52:04 -0500, William H. Blair
wmhbl...@comcast.net wrote:
. . .
The short version: Yes, essentially, it has been like that forever,
or indeed at least long enough that his intended point was valid.
The long version:
I don't know about that field specifically, since I'm
Andy Wood wonders:
Maybe they were just optimists and figured that by the
time they really needed it, the operating system would
have been updated to provide it.
As I said, I don't know where Poughkeepsie got the idea.
Maybe they thought of it all by themselves. We did not
care at the time.
Paul Gilmartin wrote:
Not really. Rexx, supplied by IBM, supports at least 3 different linkage
conventions:
Thanks for your kind reply. Does interpreted Rexx and compiled Rexx support
these 3 different linkage conventions?
Just curious...
Groete / Greetings
Elardus Engelbrecht
On Sun, 27 Sep 2009 05:41:24 -0500, Elardus Engelbrecht wrote:
Not really. Rexx, supplied by IBM, supports at least 3 different linkage
conventions:
Thanks for your kind reply. Does interpreted Rexx and compiled Rexx support
these 3 different linkage conventions?
I haven't a Rexx compiler to
On Sun, 27 Sep 2009 05:32:31 -0500, William H. Blair wrote:
There was some question which representation would be
best to represent dates1999: dddF or 0cyydddF. The
several IBMers with whom folks like us at GUIDE on some
of the futures task forces discussed the issue eventually
decided that
wmhbl...@comcast.net (William H. Blair) writes:
Of course, to some people it wasn't common knowledge.
But folks were no more interested in hearing about the
two-digit year problem in 1981 than they were in 1995.
Nobody (but some banks and a lot of software vendors)
cared. It would not hit the
William H. Blair's discussion of some of the proto-history of what came to be
called the Y2K problem is of great interest. In particular,
| There was some question which representation would be
| best to represent dates1999: dddF or 0cyydddF...
is of interest because, like almost all
Frank Swarbrick wrote:
In Cobol the length parameter for linkage from a JCL PARM is a two-byte
field. Is this not the case in assembler?
If a primary program (compiled in any language) receives a parm via JCL, there
is a standard as imposed by IBM.
As documented: There is NO limit in
On Sat, 26 Sep 2009 12:00:02 -0500, Elardus Engelbrecht wrote:
Linkage convention is that the address of the parameter is in GPR 1. The
length field is on a 2 byte boundary on that address.
This convention is independent of the language used to compile and link-edit
your program(s).
Not really.
Paul Gilmartin's point is an important one.
In assembly language the z/OS MVS 'R1 points to' convention can be exploited in
several different ways; and in REXX at least two different PARM-accessing
schemes are made available; but in, say. current PL/I the single scheme
embodied in
john gilmore wrote:
snippage
but in, say. current PL/I the single scheme embodied in
example: procedure(parm) options(main) ;
. . .
declare parm character(*) varying2 parameter
nonassignable ;
. . .
end example ;
is the only one supported,
snip
I believe other
, Grand Rapids, MI 49546 MD RSCB1G
p 616.653.8429
f 616.653.8497
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of john gilmore
Sent: Thursday, September 24, 2009 4:15 PM
To: IBM-MAIN@bama.ua.edu
Subject: Long parms...again
Jousma, David
On Fri, Sep 25, 2009 at 4:54 AM, Jousma, David david.jou...@53.com wrote:
That wasn't the word I was referring to.
It was the fact you referred to Chris Craddock as Christ that got the
chuckle out of me.
_
Believe me I've
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
John Chase reminded us:
EIBDATE is, and has been long enough to be forever, a four
byte packed-decimal field. From SDFHMAC:
EIBDATE DSPL4 DATE IN 0CYYDDD+ FORMAT,
* where C is the century
*
[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
Christ Craddock's point is ineluctable.
Well before the Y2K problem had been recognized by hoi polloi IBM guaranteed
that the CICS Command-Level EIB (Execution Interface Block) would not be
altered in a way that would break old CICS APs, in effect that old
DSECTs/templates would continue to
.
-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,
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of john gilmore
Christ Craddock's point is ineluctable.
Well before the Y2K problem had been recognized by hoi polloi IBM
guaranteed that the CICS Command-
Level EIB (Execution Interface Block) would not be
.com
1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G
p 616.653.8429
f 616.653.8497
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of john gilmore
Sent: Thursday, September 24, 2009 11:12 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Long parms
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
snip---
I would hope that I would never do that, either. However, for code that
uses an interface that has been unchanged for 45 years with a 100-byte
limit, I'm not sure I'd be quite that hard on someone whose code copied
the
On Thu, 24 Sep 2009 13:01:01 -0500, Chase, John jch...@ussco.com
wrote:
. . .
EIBDATE is, and has been long enough to be forever, a four byte
packed-decimal field. From SDFHMAC:
EIBDATE DSPL4 DATE IN 0CYYDDD+ FORMAT,
* where C is the
Jousma, David (david.jou...@53.com) writes of my use of ineluctable that it
is 'funny from a guy who takes great pains to use the English language
correctly'.
Mr. Jousma may well have his own view of what this word means, but in standard
English it means impossible to avoid.
John Gilmore
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 Thu, 24 Sep 2009 14:43:31 -0500 Rick Fochtman rfocht...@ync.net wrote:
:snip---
:I would hope that I would never do that, either. However, for code that
:uses an interface that has been unchanged for 45 years with a 100-byte
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
-Original Message-
snip
:There's no excuse for knowing what you're doing and
PLANNING AHEAD. I've
:always coded my programs with the assumption that the parm
field might
:be as long as 255 bytes, the max that can be described in a
single byte.
Is this tongue in cheek? The
Read it again John:
' Christ Craddock's point is ineluctable.
Funny coming from a guy who takes great pains to use the English
language correctly.must be the second coming...'
It had nothing to do with the use of ineluctable, it was the big job
promotion you gave to Chris(t) Craddock!
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
snip---
:Granted that guns have safeties (most of them, anyway). But if you have
:to worry about whether it's on or off, you're already doing something
:very wrong.
:There's no excuse for knowing what you're doing and
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
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of john gilmore
Jousma, David (david.jou...@53.com) writes of my use of
ineluctable that it is 'funny from a guy
who takes great pains to use the English language correctly'.
Mr. Jousma may well have his own view
snip
Rick propably felt that 255 was sufficient for his purposes. And it is
the max number in a single byte, for loading with an IC instruction. And
it is the max number which can be MVC'ed using an EX instruction to a
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
On 9/24/2009 at 1:43 PM, in message 4abbcbe3.2030...@ync.net, Rick
Fochtman
rfocht...@ync.net wrote:
snip---
I would hope that I would never do that, either. However, for code that
uses an interface that has been unchanged
On Thu, 24 Sep 2009 17:27:13 -0500, Chase, John jch...@ussco.com wrote:
...
I thought he was pointing out your misspelling of Chris Craddock's first
name as Christ.
...
You didn't hear about Chris's promotion?
Pat O'Keefe
--
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
96 matches
Mail list logo