(Tiring of people arguing in circles and getting nowhere)
Let's take a poll. Suppose for the sake of argument that I had in my posession
a set of system modifications which allowed specification of EXTPARM, which
let you specify program parms of up to 32767 characters in length, and that
you
On Wed, 4 Nov 2009 08:30:01 -0600, Martin Kline wrote:
Let's take a poll. Suppose for the sake of argument that I had in my posession
a set of system modifications which allowed specification of EXTPARM, which
let you specify program parms of up to 32767 characters in length, and that
you could
Several JCL improvements have been discussed. From my reading of
these threads, I would guess that a plurality of folks might agree on
these:
1) new PARMX= keyword on EXEC PGM=
- does the same thing as PARM=, but allows 100 characters
- can't have both PARM and PARMX
- a new
On 3 Nov 2009 20:51:59 -0800, in bit.listserv.ibm-main you wrote:
On Tue, Nov 3, 2009 at 5:44 PM, Paul Gilmartin paulgboul...@aim.com wrote:
snip
You're inconsistent in your assumptions. You appear to believe that:
o Some JCL programmers won't take responsibility ... but
o All Assembler,
believe the
benefits far outweigh the risks.
Don Williams
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Chris Craddock
Sent: Tuesday, November 03, 2009 5:46 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: An Alternative Modest PARM Proposal
On Tue
On 4 Nov 2009 09:02:35 -0800, cfmpub...@ns.sympatico.ca (Clark Morris)
wrote:
The danger of a PARMX in JCL that passes parms greater than 100 bytes
is two fold.
1. A specific JCL will have an EXEC statement that invokes the program
with PARMX= without someone having tested the program to verify
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Howard Brazee
Sent: Wednesday, November 04, 2009 12:11 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: An Alternative Modest PARM Proposal
On 4 Nov 2009 09:02:35 -0800, cfmpub...@ns.sympatico.ca
We can't protect all idiots from themselves.
We should.
That attitude is what makes M$ suck!
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
To me, the PARMX approach strikes the right balance:
- You have to explicitly change existing JCL to have a program see 100.
- Existing programs that already support 100 work with only a JCL change
As far as the argument that PARMX is dangerous because someone could
code PARMX with a program
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] För Chris Craddock
Skickat: den 3 november 2009 07:39
Till: IBM-MAIN@bama.ua.edu
Ämne: Re: An Alternative Modest PARM Proposal
You and I have diametrically opposed perspectives
On Tue, Nov 3, 2009 at 9:28 AM, Thomas Berg thomas.b...@swedbank.se wrote:
Tsk, tsk. I think You should leave this matter to more persons with
more knowledge. You see, this is a complicated matter, which You
will maybe grasp when You have got some experience.
And just how does this poorly
On 3 Nov 2009 06:37:12 -0800,
thomas.b...@swedbank.se (Thomas Berg) wrote:
Från: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] För Chris Craddock
Skickat: den 3 november 2009 07:39
Till: IBM-MAIN@bama.ua.edu
Ämne: Re: An Alternative Modest PARM Proposal
THAT my friends
On Mon, 2 Nov 2009 17:12:51 -0600 Paul Gilmartin paulgboul...@aim.com wrote:
:On Mon, 2 Nov 2009 23:50:17 +0200, Binyamin Dissen wrote:
::The suffix does not violate compatibility. A CVT bit could indicate the
::support for the suffix.
::So that a program that works with a long parm today, such
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] För P S
Skickat: den 3 november 2009 15:56
Till: IBM-MAIN@bama.ua.edu
Ämne: Re: SV: An Alternative Modest PARM Proposal
On Tue, Nov 3, 2009 at 9:28 AM, Thomas Berg
thomas.b
On 2 Nov 2009 14:55:21 -0800, paulgboul...@aim.com (Paul Gilmartin)
wrote:
First, as Shmuel notes, most programs don't differentiate between
being CALLED and JCL LAUNCHED. They're oblivious, and it's pretty
hard to tell; parameters is parameters. If a second parameter is
present, it shall be
I still say dump the request for a change to PARM length max for JCL and/or the
PARMX=. For __NEW__ functionality, implement POSIX environment variables into
the JCL. Perhaps using the current SET syntax! Then __NEW__ programs can do an
getenv() type call to grab the environment variable(s)
This does not have to be a 'all-or-none', or 'my-way-or-the-highway' issue.
Assume the some programs can accept JCL-format parms of more than 100
bytes. Also assume that some programs cannot accept such parms. Also
assume you don't want to force program changes.
So what's the issue? In some
On Tue, 3 Nov 2009 09:33:01 -0600, McKown, John wrote:
I still say dump the request for a change to PARM length max for JCL and/or
the PARMX=. For __NEW__ functionality, implement POSIX environment variables
into the JCL. Perhaps using the current SET syntax! Then __NEW__ programs can
do an
I like John's idea. I think that this idea was discussed before with
the suggestion that JCL PROC/SET variables be stored in a special
ASASYMBM table.
Re: Use of symbols in the operand of SET is not supported. - really?
This works fine:
// SET PRFX=SYS1
// SET MACLIB=PRFX..MACLIB
// SET
On Tue, 3 Nov 2009 17:06:23 +0200, Binyamin Dissen wrote:
The API is defined as 100 byte maximum and programs are coded for that. Any
change must respect the existing programs. New programs wishing to use a
larger plist can be coded to use a new way to get to the data.
The JCL manual does say,
On 3 Nov 2009 08:29:39 -0800, m42tom-ibmm...@yahoo.com (Tom Marchant)
wrote:
To prevent possible errors, always use the count as a
length attribute in acquiring the information in the PARM field.
/quote
It does not mention the 100 byte limit.
No. But it does a CYA by telling us to program
On Tue, 3 Nov 2009 00:39:03 -0600, Chris Craddock wrote:
The PARM interface is older than dirt and even though we can all agree with
hindsight that it was a momentously stupid design, it is nevertheless a
formal, documented interface and literally thousands of badly written
programs work
On Tue, 3 Nov 2009 11:56:19 -0600, Rick Fochtman wrote:
-snip
Wow! Do you have ANY idea of who you just challenged??? I see blood and
the streets, and it won't be Chris'.
---unsnip---
On 11/3/2009 at 9:04 AM, in message
listserv%200911031004341010.0...@bama.ua.edu, Paul Gilmartin
paulgboul...@aim.com wrote:
On Tue, 3 Nov 2009 09:33:01 -0600, McKown, John wrote:
I still say dump the request for a change to PARM length max for JCL and/or
the PARMX=. For __NEW__
On Tue, 03 Nov 2009 13:14:53 -0500, des...@verizon.net wrote:
I find the whole issue of compatibility bogus.
Existing programs are compatible with existing parms.
Increasing the max is irrelevant to compatibility.
Longer parms are a total waste of time though.
They're too hard to code.
Real
In ts3ue5lagh91i16hlub6vm6poq4oc65...@4ax.com, on 11/02/2009
at 06:59 PM, Binyamin Dissen bdis...@dissensoftware.com said:
Huh?
Paul is referring to the documented[1] OS/360 convention that a main
program is just another subroutine.
The suffix does not violate compatibility.
It breaks
I still don't see why there would be a problem with just PARM= behaving
just as it does now.
and having a new PARMX= (or whatever) that sets up exactly the same
thing except that the string can be up to whatever that two-byte length
field allows (I don't remember if it's supposed to be signed or
In 6fh0f55c4lt4scbntma0r9udums736r...@4ax.com, on 11/03/2009
at 05:06 PM, Binyamin Dissen bdis...@dissensoftware.com said:
The API is defined as 100 byte maximum
There is no such formal API. The limitations of the R/I and C/I were just
that, limitations. They were never a contract to the
On 2 Nov 2009 13:22:56 -0800, in bit.listserv.ibm-main you wrote:
On Mon, 2 Nov 2009 21:16:42 +0100, Thomas Berg wrote:
If we really go the new syntax road, I liked the suggestion,
by someone I don't remember for the moment, that we introduce
a new JCL operand:
// PARM '...'
I like that
On 3 Nov 2009 09:58:50 -0800, rfocht...@ync.net (Rick Fochtman) wrote:
Yes, compatability must be maintained, as ugly as it may be. Making a
major change now, after 45+ years, could cause major chaos and
discontent in MANY shops.
Maybe in this case, the benefit wouldn't be worth the cost in
In d173ec266418d84395b4b89759d861d403cf9...@usmdlmdowx025.dow.com, on
11/02/2009
at 05:21 PM, van der Grijn, Bart (B) bvandergr...@dow.com said:
As far as I'm concerned everyone has the right to use whatever reply
prefix they want
There is an Internet convention to use re: in replies,
On Tue, 3 Nov 2009 10:25:51 -0600, Kirk Wolf wrote:
Re: Use of symbols in the operand of SET is not supported. - really?
This works fine:
// SET PRFX=SYS1
// SET MACLIB=PRFX..MACLIB
// SET AMACLIB=PRFX..AMACLIB
// SET LINKLIB=PRFX..LINKLIB
Ah! Found it! (They hid it well):
Linkname:
In 4aef4550.4040...@ync.net, on 11/02/2009
at 02:47 PM, Rick Fochtman rfocht...@ync.net said:
IIRC, the IBM compilers will also accept a *PROCESS statement that can
be as long as necessary.
The options on *PROCESS can't be specified in JCL; the options in PARM
can.
--
Shmuel
In 75pte5d4gbjq6ivuct5cia1svu0khlb...@4ax.com, on 11/02/2009
at 03:55 PM, Binyamin Dissen bdis...@dissensoftware.com said:
Not at all.
There's a compatibility problem with programs that currently use HW +
characters as the first parameter and don't rquire the length to be less
than 101.
--
On Tue, Nov 3, 2009 at 11:48 AM, Paul Gilmartin paulgboul...@aim.comwrote:
On Tue, 3 Nov 2009 00:39:03 -0600, Chris Craddock wrote:
The PARM interface is older than dirt and even though we can all agree
with
hindsight that it was a momentously stupid design, it is nevertheless a
formal,
On Tue, 3 Nov 2009 17:36:05 -0500, Tony Harminc wrote:
The argument would be that if such a program fails only because it
copies parmlength bytes to a 100-byte buffer without checking that
the length does not exceed 100, it does not compromise MVS System
Integrity, since the Integrity statement
On Tue, 3 Nov 2009 17:01:12 -0600, Chris Craddock wrote:
When you call a batch job step program through another interface than EXEC
PGM= you are taking responsibility for ensuring that the program's
interface requirements are met. And you're right there are many such
programs that can safely and
On Tue, 3 Nov 2009 14:20:36 -0500, Don Williams wrote:
I have wanted to be able to pass long parms from JCL since the early 80's.
I've have to use inventive ways to get around that restriction. I've
listened to many people complain that 100 characters was too small.
Something like PARMX has be
SNIPPAGE
This reminds me of PL/1. Designed and implemented by committee.
How about writing it up, and if you are a SHARE member, submitting it
for a vote. Let IBM decide how they are going to deal with it (they will
any way, given my experience with JES2 development).
But, this is just one
On Tue, Nov 3, 2009 at 1:36 PM, Shmuel Metz (Seymour J.)
shmuel+ibm-m...@patriot.net shmuel%2bibm-m...@patriot.net wrote:
In 6fh0f55c4lt4scbntma0r9udums736r...@4ax.com, on 11/03/2009
at 05:06 PM, Binyamin Dissen bdis...@dissensoftware.com said:
The API is defined as 100 byte maximum
In 3ukue5d024hvsqq36tesv225fu3lr0c...@4ax.com, on 11/02/2009
at 11:50 PM, Binyamin Dissen bdis...@dissensoftware.com said:
Compatibility has its costs. This solution does not change the number of
parameters and is completely compatible.
No; it breaks compatibility with existing code that
In listserv%200911031148532643.0...@bama.ua.edu, on 11/03/2009
at 11:48 AM, Paul Gilmartin paulgboul...@aim.com said:
BTW, I wonder, which is older, Assembler CALL or JCL PARM?
Neither; they were contemporaneous. Both were in the original OS/360
announcement, as was the principle that a main
Maybe the only thing that is broken is the manual :-)
On Tue, Nov 3, 2009 at 4:40 PM, Paul Gilmartin paulgboul...@aim.com wrote:
On Tue, 3 Nov 2009 10:25:51 -0600, Kirk Wolf wrote:
Re: Use of symbols in the operand of SET is not supported. - really?
This works fine:
// SET PRFX=SYS1
// SET
On Tue, 3 Nov 2009 10:25:51 -0600, Kirk Wolf wrote:
Re: Use of symbols in the operand of SET is not supported. - really?
This works fine:
// SET PRFX=SYS1
// SET MACLIB=PRFX..MACLIB
// SET AMACLIB=PRFX..AMACLIB
// SET LINKLIB=PRFX..LINKLIB
Outdated information? I clearly remember a warning in
Tom Marchant wrote:
exceed 100 characters, but I wouldn't call that an API. The Assembler
Services Guide describes the API. It reads,
quote
snipped?
/quote
It does not mention the 100 byte limit.
It also does not mention that you could receive a four word list
if called as a CP, or a
-MAIN@bama.ua.edu
Subject: Re: An Alternative Modest PARM Proposal
-snip
Wow! Do you have ANY idea of who you just challenged??? I see blood and
the streets, and it won't be Chris'.
---unsnip
-snip
Wow! Do you have ANY idea of who you just challenged??? I see blood and
the streets, and it won't be Chris'.
---unsnip---
While I agree that Chris needs a better understanding
In p06240805c71505a12...@[192.168.1.11], on 11/02/2009
at 04:58 PM, Robert A. Rosenberg hal9...@panix.com said:
When CALLED as opposed to JCL LAUNCHED, do these IBM Compilers accept a
longer than 100 character PARM Entry (while also accepting DDNAME
Overrides in Parms 2+)?
Yes. They're not
On Tue, 3 Nov 2009 16:46:26 -0600, Chris Craddock wrote:
Au contraire. The 100 character limit has been documented since the
beginning of time. An unknowably large number of programmers wrote an
unknowably large number of (arguably incorrect) batch job step programs that
functioned correctly ONLY
Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Tuesday, November 03, 2009 4:49 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: An Alternative Modest PARM Proposal
But take care to address Jim Mulder's serious concern that invoking
certain APF-authorized programs
In b0c6f15b0911022239s3a22a2a2gf6404101562bb...@mail.gmail.com, on
11/03/2009
at 12:39 AM, Chris Craddock crashlu...@gmail.com said:
The PARM interface is older than dirt and even though we can all agree
with hindsight that it was a momentously stupid design, it is
nevertheless a formal,
On Tue, Nov 3, 2009 at 9:08 AM, Thomas Berg thomas.b...@swedbank.se wrote:
On Tue, Nov 3, 2009 at 9:28 AM, Thomas Berg
thomas.b...@swedbank.se wrote:
Tsk, tsk. I think You should leave this matter to more
persons with
more knowledge. You see, this is a complicated matter,
which
2009/11/3 John P. Baker jbaker...@comporium.net:
If a program is APF-authorized and can be invoked from JCL and does not
properly validate any parameter(s) provided to it by its invoker, then I
would argue that the program is defective and that the lack of parameter
validation is APAR'able.
In listserv%200911021027099979.0...@bama.ua.edu, on 11/02/2009
at 10:27 AM, Tom Marchant m42tom-ibmm...@yahoo.com said:
No. As I recall, Shmuel's original proposal was to provide a list
somewhere, preferably in PARMLIB, of programs that could not handle the
long parm.
More precisely, a list
On Tue, Nov 3, 2009 at 5:44 PM, Paul Gilmartin paulgboul...@aim.com wrote:
snip
You're inconsistent in your assumptions. You appear to believe that:
o Some JCL programmers won't take responsibility ... but
o All Assembler, Rexx, FORTRAN, COBOL, C, PL/I, ... can be
presumed to take
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] För Shmuel Metz (Seymour J.)
Skickat: den 1 november 2009 18:56
Till: IBM-MAIN@bama.ua.edu
Ämne: Re: An Alternative Modest PARM Proposal
In p0624080ac7110bd5f...@[192.168.1.11], on 10/30
On Mon, 2 Nov 2009 13:40:44 +0100 Thomas Berg thomas.b...@swedbank.se wrote:
:If the current JCL PARM format change from HW + 0-100 bytes
:to HW + 100 bytes + FW for the new long parm + 0-??? bytes long parm,
:are there any backward compatibility problems ?
Not at all.
Would require a CVT bit
On Sat, 31 Oct 2009 00:33:10 -0400, Robert A. Rosenberg wrote:
At 17:40 -0500 on 10/30/2009, Paul Gilmartin wrote about Re: An
Alternative Modest PARM Proposal:
Therefore, you should understand very well why this won't work.
Such utilities will misinterpret the Long Parm as a DDN override
list
On Mon, 2 Nov 2009 13:40:44 +0100, Thomas Berg wrote:
If the current JCL PARM format change from HW + 0-100 bytes
to HW + 100 bytes + FW for the new long parm + 0-??? bytes long parm,
are there any backward compatibility problems ?
There would be a lateral compatibility problem, in that the
parm
On Mon, 2 Nov 2009 10:50:06 -0600 Paul Gilmartin paulgboul...@aim.com wrote:
:On Mon, 2 Nov 2009 13:40:44 +0100, Thomas Berg wrote:
:If the current JCL PARM format change from HW + 0-100 bytes
:to HW + 100 bytes + FW for the new long parm + 0-??? bytes long parm,
:are there any backward
-
Från: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] För Paul Gilmartin
Skickat: den 2 november 2009 17:50
Till: IBM-MAIN@bama.ua.edu
Ämne: Re: SV: An Alternative Modest PARM Proposal
On Mon, 2 Nov 2009 13:40:44 +0100, Thomas Berg wrote:
If the current JCL PARM format
On 2 Nov 2009 09:19:45 -0800, thomas.b...@swedbank.se (Thomas Berg)
wrote:
As the problem is (old?) programs that cannot cope with
longer parms than 100 bytes, among them IBM module apparently,
that's the problem that needs to be solved.
So we cannot avoid a somewhat ugly change of the JCL
On Mon, 2 Nov 2009 18:59:19 +0200, Binyamin Dissen wrote:
On Mon, 2 Nov 2009 10:50:06 -0600 Paul Gilmartin paulgboul...@aim.com wrote:
:On Mon, 2 Nov 2009 13:40:44 +0100, Thomas Berg wrote:
:If the current JCL PARM format change from HW + 0-100 bytes
:to HW + 100 bytes + FW for the new long
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Thomas Berg
Sent: Monday, November 02, 2009 11:15 AM
To: IBM-MAIN@bama.ua.edu
Subject: SV: SV: An Alternative Modest PARM Proposal
But obviously not a *backward* compatibility
On Mon, 2 Nov 2009 18:14:38 +0100, Thomas Berg wrote:
But obviously not a *backward* compatibility problem ?
And the main problem here, as I have understood the
discussion, is the limit of 100 bytes through JCL PARM.
And that is sort of another format as I see it.
As the problem is (old?)
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] För Tom Marchant
Skickat: den 2 november 2009 18:42
Till: IBM-MAIN@bama.ua.edu
Ämne: Re: SV: SV: An Alternative Modest PARM Proposal
On Mon, 2 Nov 2009 18:14:38 +0100, Thomas Berg wrote
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] För McKown, John
Skickat: den 2 november 2009 18:38
Till: IBM-MAIN@bama.ua.edu
Ämne: Re: SV: An Alternative Modest PARM Proposal
-Original Message-
From: IBM Mainframe
On Mon, 2 Nov 2009 11:38:25 -0600, McKown, John wrote:
How about just agreeing that the HW pointed to my R1 can range in value from 0
to +32,767.
In fact, at least one IBM program (I just tested it) works quite well with
a PARM string length of 65,635 in the HW.
And, in the new JCL PARMX
On Mon, 2 Nov 2009 18:57:49 +0100, Thomas Berg wrote:
Don't we then have a usage problem here ? I'm thinking of thousands
of sites with many more programmers and operators etc. that have
to deal with - now - two forms of parms. I'm thinking of some sort of caos...
And don't we still have the
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] För Paul Gilmartin
Skickat: den 2 november 2009 19:23
Till: IBM-MAIN@bama.ua.edu
Ämne: Re: An Alternative Modest PARM Proposal
On Mon, 2 Nov 2009 18:57:49 +0100, Thomas Berg wrote
On Mon, 2 Nov 2009 19:45:43 +0100, Thomas Berg wrote:
Well, the caos is not primarily feared based on API format. I was thinking
of Job JCLs that production planners, those who restart and corrects jobs,
application programmers/designers etc; all those who deals with parms that
have application
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin
Sent: Monday, November 02, 2009 1:56 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SV: An Alternative Modest PARM Proposal
snip
I might even advocate a new JCL command
On 2 Nov 2009 10:23:59 -0800, in bit.listserv.ibm-main you wrote:
On Mon, 2 Nov 2009 18:57:49 +0100, Thomas Berg wrote:
Don't we then have a usage problem here ? I'm thinking of thousands
of sites with many more programmers and operators etc. that have
to deal with - now - two forms of parms.
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] För Paul Gilmartin
Skickat: den 2 november 2009 20:56
Till: IBM-MAIN@bama.ua.edu
Ämne: Re: SV: An Alternative Modest PARM Proposal
On Mon, 2 Nov 2009 19:45:43 +0100, Thomas Berg wrote
On Mon, 2 Nov 2009 14:02:26 -0600, McKown, John wrote:
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin
I might even advocate a new JCL command, //L EXECU PGM=...,
where EXECU invokes the program in the unauthorized
snip
There is NO REASON to send a Long Parm to these IBM utilities
Of course there is. It ignores, e.g., IBM compilers.
--unsnip---
IIRC, the IBM compilers will also accept a *PROCESS
On Mon, 2 Nov 2009 21:16:42 +0100, Thomas Berg wrote:
*BUT*, we still we have the problem of backward incompatibility
regardless of the input format...
Not if the PARM is stored in memory the same way it is today: A fullword
parameter address with the high order bit set to 1. That word points
JCL.EXEC.PARMX.program-name.
Don Williams
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Monday, November 02, 2009 1:23 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: An Alternative Modest PARM Proposal
On Mon, 2 Nov 2009
On Mon, 2 Nov 2009 21:16:42 +0100, Thomas Berg wrote:
If we really go the new syntax road, I liked the suggestion,
by someone I don't remember for the moment, that we introduce
a new JCL operand:
// PARM '...'
I like that partly beacuse of possibility to have a concatenate
function like:
//
On Mon, 2 Nov 2009 14:47:12 -0600, Rick Fochtman wrote:
snip
There is NO REASON to send a Long Parm to these IBM utilities
Of course there is. It ignores, e.g., IBM compilers.
--unsnip---
IIRC, the
On Mon, 2 Nov 2009 11:32:34 -0600 Tom Marchant m42tom-ibmm...@yahoo.com
wrote:
:On Mon, 2 Nov 2009 18:59:19 +0200, Binyamin Dissen wrote:
:On Mon, 2 Nov 2009 10:50:06 -0600 Paul Gilmartin paulgboul...@aim.com
wrote:
::On Mon, 2 Nov 2009 13:40:44 +0100, Thomas Berg wrote:
::If the current JCL
| Of course there is. It ignores, e.g., IBM compilers.
|
| --unsnip---
|
| IIRC, the IBM compilers will also accept a *PROCESS
| statement that can be as long as necessary.
You don't remember correctly. Some process statements are limiteds to a proper
At 18:14 +0100 on 11/02/2009, Thomas Berg wrote about SV: SV: An
Alternative Modest PARM Proposal:
As the problem is (old?) programs that cannot cope with
longer parms than 100 bytes, among them IBM module apparently,
that's the problem that needs to be solved.
Not exactly on the IBM
At 11:26 -0600 on 11/01/2009, Rick Fochtman wrote about Re: An
Alternative Modest PARM Proposal:
-snip-
There is NO REASON to send a Long Parm to these IBM utilities so
this potential glitch can easily be handled by a new PARMLIB
At 12:58 -0500 on 11/01/2009, Shmuel Metz (Seymour J.) wrote about
Re: An Alternative Modest PARM Proposal:
There is NO REASON to send a Long Parm to these IBM utilities
Of course there is. It ignores, e.g., IBM compilers.
When CALLED as opposed to JCL LAUNCHED, do these IBM Compilers
My apologies if this has been discussed in the past, but as someone that
groups his IBM-Main inbox by Subject I want to point out the following:
http://www.trilithium.com/johan/2005/06/re-outlook/
As far as I'm concerned everyone has the right to use whatever reply
prefix they want and I don't
On Mon, 2 Nov 2009 16:58:37 -0500, Robert A. Rosenberg wrote:
At 12:58 -0500 on 11/01/2009, Shmuel Metz (Seymour J.) wrote about
Re: An Alternative Modest PARM Proposal:
There is NO REASON to send a Long Parm to these IBM utilities
Of course there is. It ignores, e.g., IBM compilers.
When
On Mon, 2 Nov 2009 23:50:17 +0200, Binyamin Dissen wrote:
:The suffix does not violate compatibility. A CVT bit could indicate the
:support for the suffix.
:So that a program that works with a long parm today, such as the Assembler,
:would have to be modified to test the CVT and look in a new
You and I have diametrically opposed perspectives of compatibility.
To me, compatibility means the facility to call a program from JCL
with a long PARM presenting exactly the same interface as today when
it's called from other languages (such as Rexx), and requiring
modification neither
-snip-
There is NO REASON to send a Long Parm to these IBM utilities so this
potential glitch can easily be handled by a new PARMLIB member with a
list of programs that are NOT to be passed an extended parm (IBM knows
who they are
Accept the fact that some days you're the pigeon, other days you're the statue.
Also, accept the fact that as long as you only discuss it on IBM-Main, nothing
will happen.
-
Too busy driving to stop for gas!
--
For IBM-MAIN
In p06240806c7116c639...@[192.168.1.11], on 10/31/2009
at 12:33 AM, Robert A. Rosenberg hal9...@panix.com said:
There is NO REASON to send a Long Parm to these IBM utilities
Of course there is. It ignores, e.g., IBM compilers.
Does this help?
No. It ignores problems with the 100 character
In p0624080ac7110bd5f...@[192.168.1.11], on 10/30/2009
at 05:42 PM, Robert A. Rosenberg hal9...@panix.com said:
OK. The current standard is a single FW (with the high bit set) pointing
at a HW with length followed by 0-100 bytes of data (the FW being
pointed to by R1).
No, the current
On Sat, 31 Oct 2009 00:33:10 -0400, Robert A. Rosenberg wrote:
At 17:40 -0500 on 10/30/2009, Paul Gilmartin wrote about Re: An
Alternative Modest PARM Proposal:
Therefore, you should understand very well why this won't work.
Such utilities will misinterpret the Long Parm as a DDN override
list
On Sat, 31 Oct 2009 00:33:10 -0400, Robert A. Rosenberg wrote:
At 17:40 -0500 on 10/30/2009, Paul Gilmartin wrote about Re: An
Alternative Modest PARM Proposal:
Therefore, you should understand very well why this won't work.
Such utilities will misinterpret the Long Parm as a DDN override
list
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of John P. Baker
Sent: Thursday, October 29, 2009 4:29 PM
To: IBM-MAIN@bama.ua.edu
Subject: An Alternative Modest PARM Proposal
All,
The proposal previously set forth is interesting
In listserv%200910291643073774.0...@bama.ua.edu, on 10/29/2009
at 04:43 PM, Paul Gilmartin paulgboul...@aim.com said:
Aren't we going overboard here? While 100 characters in JCL is painfully
constraining, and 255 might be an uncomfortable limit, any programmer who
feels the need for 65535 in
In 00fa01ca58de$cbaac1b0$630045...@net, on 10/29/2009
at 05:28 PM, John P. Baker jbaker...@comporium.net said:
The proposal previously set forth is interesting, but I would like to put
forward an alternative proposal.
Actually, it's a proposal for an alternative goal. My goal was to preserve
At 07:29 -0500 on 10/30/2009, McKown, John wrote about Re: An
Alternative Modest PARM Proposal:
Same problem with this as with all others. You have changed the
interface expected by OLD code. Suppose your old code is coded for
the current standard. If someone used a long PARM, then your old
On Fri, 30 Oct 2009 17:42:09 -0400, Robert A. Rosenberg wrote:
At 07:29 -0500 on 10/30/2009, McKown, John wrote about Re: An
Alternative Modest PARM Proposal:
Same problem with this as with all others. You have changed the
interface expected by OLD code. Suppose your old code is coded
1 - 100 of 105 matches
Mail list logo
