Re: An Alternative Modest PARM Proposal

2009-11-04 Thread Martin Kline
(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 could obtain this modification for a small fee. Who would be interested in 
using it? Who would refuse to use it? 

What if you could specify in your parmlib the list of programs which could be 
invoked with this parameter? Would you use it then? After all, aren't we really 
talking about a limited number of potential uses at any given site?

Take it a step further. Suppose IBM supplied this capability with the next z/OS 
release. Also suppose that you could enable or disable the functionality via a 
parmlib value as well as specify the programs that were eligible for use. Would 
you be interested then?

--
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


Re: An Alternative Modest PARM Proposal

2009-11-04 Thread Paul Gilmartin
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 obtain this modification for a small fee. Who would be interested in
using it? Who would refuse to use it?

Depends on the value of small.
I'd say 65535 rather than 32767.  But either is larger than practically
useful.  That would be about 5000.

What if you could specify in your parmlib the list of programs which could be
invoked with this parameter? Would you use it then? After all, aren't we really
talking about a limited number of potential uses at any given site?

It would certainly be useful to have one more syntactic extension in
the PARMLIB member:

AC=0 /* Unauthorized programs are relatively harmless.  */
NAME=FRED
NAME=JOE
...

Take it a step further. Suppose IBM supplied this capability with the next z/OS
release. Also suppose that you could enable or disable the functionality via a
parmlib value as well as specify the programs that were eligible for use. Would
you be interested then?

We'd need to take a poll at our site; I can't make that decision alone.
But I'd vote yes.  But there are tradeoffs.  If resources forced a
choice between long PARM and symbol substitution in SYSIN, I'd take
the latter.

-- gil

--
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


Re: An Alternative Modest PARM Proposal

2009-11-04 Thread Kirk Wolf
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 keyword means that the JCL coder has to intentionally use
it (and be responsible to test programs for  100 character
compatability)
- programs that already work  100 don't need to be modified

2) Keep JCL and PROC variables around and use them to populate an
ASASYMBM table (separate from the system table)
Maybe have an LE option that automatically imports these as
environment variables,
but non-LE assembler programs could use ASASYMBM to access them.

3) Symbol substition in SYSIN; something like:
//FOO DD DATA,SUB=YES
  INPUT OPT=JCLVAR
/*


IMO, *all* three of these solve important (and independent) usability
problems with JCL.
A poll on IBM-MAIN is not enough - requirements need to be submitted
to IBM via support center, SHARE, zBLC, etc.

It would be nice if there were some consensus here; but that's too
much to hope for :-)

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

--
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


Re: An Alternative Modest PARM Proposal

2009-11-04 Thread Clark Morris
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, Rexx, FORTRAN, COBOL, C, PL/I, ... can be
  presumed to take responsibility for ensuring that the
  interface requirements of any program they may call are met.

 I strongly doubt the second of those statements.  Therefore,
 to avoid breaking programs in unpredictable ways, the OS must
 be reinforced to avoid ever passing a PARM 100 characters.
 This must be done at the SVC level in order to preclude the
 programmer's loading registers and issuing the LINK or ATTACH
 SVC with an oversize PARM.  In fact, there's no way to prevent
 the programmer's coding LOAD followed by BALR.  Give me a
 program with AC=0 that doesn't check its PARM length and I'll
 break it.  (Wanna see me make ASMA90 S0C4?  I needed to use
 ATTCHPGM; couldn't break it with ATTCHMVS.  I have a tester's
 temperament; you can't assume I'll always for be responsible
 for ensuring that a program's interface requirements, documented
 or otherwise are met.)
 http://bama.ua.edu/archives/ibm-main.html


No I am not inconsistent in my assumptions, but I've obviously failed to
communicate them to you. Let me try one last time.

The fact that you can find programs that are well behaved in the
circumstances you're talking about is not at all in dispute. But neither is
it in the slightest bit relevant. Whether you choose to accept it or not,
the initiator's documented interface existed long before  the other
interfaces you're citing (with the exception of plain old CALL) were even
a developer's wet dream. Lots of horses fled the barn in the mean time.

And I agree that I can't assume you will be responsible for ensuring your
called program's interface requirements are met. In fact, I'm sure I can't.
That's the whole point. Your tester's temperament is at odds with the
stability needs of a production batch environment and I'll take a healthy
sized bet that those production batch environments were there before you
were, so whether you like it or not, they get grandfathered in, even if they
don't play well by the rules you imagine they must.

(Sorry if my architect's temperament is showing)

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 that
it can handle that PARM length.  This is sloppy programming and the
installation deserves what it gets.

2. An installation will either change all JCL to use PARMX instead of
PARM or require it for new JCL without verifying that the programs can
handle it.  Again this might be considered poor management because a
mass change is made to an interface without testing.

Both cases require specific action to break something existing, i.e.
the JCL change.  A change to existing JCL to create a PARM greater
than 100 bytes in length on an EXEC statement with PARM= would still
cause job failure.  In one sense a more basic question is what do we
see the future of the z series as being.  People on other platforms
look at many of the restrictions in JCL as being archaic (8 byte
program names, 44 byte data set names, upper case only, and so forth).
Even those coming from VSE (formerly Dumb Operating System) look
askance at some of the restrictions (like not being able to handle
FBA).   

--
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


Re: An Alternative Modest PARM Proposal

2009-11-04 Thread Don Williams
Authorized programs should be written to a higher standard.  Above and
beyond normal error checking, they should be written to prevent intentional
abuse.  That is the standard IBM uses when they accept APARs on their
authorized programs.  A malicious user can be expected to attempt to use any
and all unintended means to invoke an authorized program.  JCL is not the
only way to invoke an authorized program.  There are other means to invoke
an authorized program which pass more than 100 characters.  Authorized
programs should already be protecting themselves from any problems which
could be caused by long parameters.  PARMX passing more than 100 characters
would not be a new risk, although arguably easier than other methods.
Regardless, if an authorized program is discovered to behave in a
destructive manner when passed more than 100 characters, then you are
already at risk and it should be corrected.  That is what IBM does.  That is
what everybody should do.  If you feel that PARMX would be increase the
risks in your environment, then it could be controlled with the SAF (RACF,
etc.) protection addendum. 

1. Is there a significant number of frequently used authorized programs
known to have highly undesirable consequences?  I don't think so. 
2. Is it likely that the PARMX proposal would have undesirable dire
consequences?  I don't think so. 
3. Does simply making it easier to pass more than 100 characters to an
authorized program, justify canning the PARMX proposal?  I 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, 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

 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 programmer.


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 because they were guaranteed never to get more
than 100 bytes of parameter data from the initiator. You can play verbal
semantic games all you want, but THAT *IS* A CONTRACT to the programmer. We
can all agree it was a bad idea and that wiser programmers might have
properly dealt with the interface even then, but so what? All of those bad
programs will, for better or worse, continue to run safely because the
behavior of the initiator is not going to change.



 New programs wishing to use a
 larger plist can be coded to use a new way to get to the data.

 If it were only a case of new programs then I would agree that the
 existing format is obsolete. However, existing programs, including those
 from IBM, support the existing interface for parms longer than 100.
  http://bama.ua.edu/archives/ibm-main.html


No Shmuel, that's where you have it precisely backwards. SOME existing
programs can/do correctly interpret the existing interface when called with
a longer parm string by a program other than the initiator. An unknowably
large number don't behave that way and giving a JCL programmer a means (even
accidentally) to pass longer parameter data to those existing programs
through the existing interface is just begging for trouble, which is why it
won't happen.

Dressing the proposal up with a cheat-sheet approach where the initiator can
consult a secret decoder ring to decide whether the long parameter string is
allowed or not is (frankly) kinda nutty. It presents loads more mechanism
and complexity for the OS and creates a maintenance problem with no
guarantees of avoiding a 3AM collision with an otherwise valid program whose
interface needs have not yet been documented.

-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

--
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


Re: An Alternative Modest PARM Proposal

2009-11-04 Thread Howard Brazee
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 that
it can handle that PARM length.  This is sloppy programming and the
installation deserves what it gets.

2. An installation will either change all JCL to use PARMX instead of
PARM or require it for new JCL without verifying that the programs can
handle it.  Again this might be considered poor management because a
mass change is made to an interface without testing.

We can't protect all idiots from themselves.

--
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


Re: An Alternative Modest PARM Proposal

2009-11-04 Thread Thompson, Steve
-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 (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 that
it can handle that PARM length.  This is sloppy programming and the
installation deserves what it gets.

2. An installation will either change all JCL to use PARMX instead of
PARM or require it for new JCL without verifying that the programs can
handle it.  Again this might be considered poor management because a
mass change is made to an interface without testing.

We can't protect all idiots from themselves.

snip

It is impossible to make anything foolproof, because fools are so
ingenious. -- Robert Heinlein

--
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


Re: An Alternative Modest PARM Proposal

2009-11-04 Thread Ted MacNEIL
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: An Alternative Modest PARM Proposal

2009-11-04 Thread Kirk Wolf
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 that didn't support  100:
This seems selectively cautious to me... any program could fail if you
change its input to something it doesn't support.  You don't need a
new JCL keyword.

As far as starting a debate between the three suggested JCL
enhancements (PARMX, JCL variables available at runtime, and SYSIN
substitution) - why?  IMO, its better to lump everything into a single
requirement bundle that has wide rather than fractured demand.   IBM
will choose what and how to implement anyway (if at all).   Maybe we
should just be thankful that we have 100 and not 80 :-)



On Wed, Nov 4, 2009 at 11:01 AM, Clark Morris cfmpub...@ns.sympatico.ca wrote:
 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, Rexx, FORTRAN, COBOL, C, PL/I, ... can be
  presumed to take responsibility for ensuring that the
  interface requirements of any program they may call are met.

 I strongly doubt the second of those statements.  Therefore,
 to avoid breaking programs in unpredictable ways, the OS must
 be reinforced to avoid ever passing a PARM 100 characters.
 This must be done at the SVC level in order to preclude the
 programmer's loading registers and issuing the LINK or ATTACH
 SVC with an oversize PARM.  In fact, there's no way to prevent
 the programmer's coding LOAD followed by BALR.  Give me a
 program with AC=0 that doesn't check its PARM length and I'll
 break it.  (Wanna see me make ASMA90 S0C4?  I needed to use
 ATTCHPGM; couldn't break it with ATTCHMVS.  I have a tester's
 temperament; you can't assume I'll always for be responsible
 for ensuring that a program's interface requirements, documented
 or otherwise are met.)
 http://bama.ua.edu/archives/ibm-main.html


No I am not inconsistent in my assumptions, but I've obviously failed to
communicate them to you. Let me try one last time.

The fact that you can find programs that are well behaved in the
circumstances you're talking about is not at all in dispute. But neither is
it in the slightest bit relevant. Whether you choose to accept it or not,
the initiator's documented interface existed long before  the other
interfaces you're citing (with the exception of plain old CALL) were even
a developer's wet dream. Lots of horses fled the barn in the mean time.

And I agree that I can't assume you will be responsible for ensuring your
called program's interface requirements are met. In fact, I'm sure I can't.
That's the whole point. Your tester's temperament is at odds with the
stability needs of a production batch environment and I'll take a healthy
sized bet that those production batch environments were there before you
were, so whether you like it or not, they get grandfathered in, even if they
don't play well by the rules you imagine they must.

(Sorry if my architect's temperament is showing)

 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 that
 it can handle that PARM length.  This is sloppy programming and the
 installation deserves what it gets.

 2. An installation will either change all JCL to use PARMX instead of
 PARM or require it for new JCL without verifying that the programs can
 handle it.  Again this might be considered poor management because a
 mass change is made to an interface without testing.

 Both cases require specific action to break something existing, i.e.
 the JCL change.  A change to existing JCL to create a PARM greater
 than 100 bytes in length on an EXEC statement with PARM= would still
 cause job failure.  In one sense a more basic question is what do we
 see the future of the z series as being.  People on other platforms
 look at many of the restrictions in JCL as being archaic (8 byte
 program names, 44 byte data set names, upper case only, and so forth).
 Even those coming from VSE (formerly Dumb Operating System) look
 askance at some of the restrictions (like not being able to handle
 FBA).

 --
 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 

Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Eric Chevalier
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 is compatibility. Not elegant, not pretty, 
 but guaranteed compatible. Now can we all just get over this nonsense?


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.

Wow! Do you have ANY idea of who you just challenged??? I see blood
and the streets, and it won't be Chris'.

Eric

--
Eric Chevalier  E-mail: et...@tulsagrammer.com
   Web: www.tulsagrammer.com
Is that call really worth your child's life?  HANG UP AND DRIVE!

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Binyamin Dissen
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 as the Assembler,
::would have to be modified to test the CVT and look in a new place for the
::long parm.  A poor solution, IMO.

:Compatibility has its costs. This solution does not change the number of
:parameters and is completely compatible.

: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 of the target program nor of the calling language
:(i.e. Rexx).  You seem to advocate that the interface when called
:from JCL should differ from the interface when called from Rexx, etc.
:I can't view that as compatible.

You have an unusual understanding of compatibility.

Compatibility means that an existing program runs as is without needing to
make any changes with the APIs remaining the same. New programs requiring new
features use new APIs.

:Yes, some programs would break if they could be called from JCL
:with long parms, identically as they'd break if called from Rexx,
:etc. with the same parms.  Even that identical behavior in breakage
:is a form of compatibility.

Or if called as a CP or if called with a random parameter list.

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.

--
Binyamin Dissen bdis...@dissensoftware.com
http://www.dissensoftware.com

Director, Dissen Software, Bar  Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Howard Brazee
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 taken as a ddnamelist.

I don't know of any reason why this shouldn't be the case.   

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread McKown, John
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) they are interested in. 
The plus of this is that others, in other threads, have wanted to be able to 
get the contents of SET variables in their programs. Again, this would allow 
that. But it would take a change to the converter/intepreter as well as the 
initiator. Another plus is that you could use this instead of parsing the PARM 
field. 

For example, instead of:

// EXEC PGM=MYPROG,
// PARM='VAR1=VAL1,VAR2=VAL2,VAR7=VAL7,VAR3=VAL3'

You could have:

// SET VAR1=VAL1
// SET VAR2=VAL2
// SET VAR7=VAL7
// SET VAR3=VAL3
// EXEC PGM=MYPROG

and MYPROG would simply do a getenv(VAR1) to get the value of VAR1 and so on. 
No parsing of the PARM= needed.

It would also simplify using UNIX programs because the environment variables 
could be set in JCL (and as symbolic parameters passed into a PROC) instead of 
somehow getting them in via the //STDENV statement (which doesn't do symbolic 
substitution).

Just my from-left-field idea, yet again.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Martin Kline
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 cases, you want to be able to pass more than 
100 characters as a JCL parm to a program that is capable of handling it.

I believe it's been discussed already, but why not just request an additional 
JCL parameter, such as PARMX or EXTPARM, or whatever, that has the 
following restrictions: Cannot be specified along with PARM, and a maximum 
length of 32767 characters, with the same formatting requirements as the 
PARM parameter. Document the restriction that passing more than 100 
characters to a program should only be done when the program supports it. 
The resulting data as presented to the called program would be the same: 
pointer to HW length followed by data of that length. So, coding PARM='RENT' 
or PARMX='RENT' results in the same data. 

I have no requirement for passing more than 100 characters in the parm for 
the linkage editor or HLASM. So, I could code PARM or PARMX. It makes no 
difference. I don't even care if these two programs ever support more than 
100 characters. 

However, I may need to pass more than 100 characters to some program, 
such as the COBOL compiler. First, I have to know that the compiler supports 
it. Second, I need the JCL support. Today, assuming the called program 
supports the parm, if I want to create a simulated parm, I could front-end the 
compiler with REXX or assembler, building the long parm list as needed. With a 
new JCL option, I could bypass the front end process.

Finally, what about users who pass more than 100 character parms to 
programs that are not coded to handle them? That's why you document Don't 
do that, or you get unexpected results. What happens now if I pass an 
invalid parm to a program?

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Paul Gilmartin
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 getenv() type call to grab the environment variable(s) they are 
interested in. The plus of this is that others, in other threads, have wanted 
to be able to get the contents of SET variables in their programs. Again, this 
would allow that. But it would take a change to the converter/intepreter as 
well as the initiator. Another plus is that you could use this instead of 
parsing the PARM field.

For example, instead of:

// EXEC PGM=MYPROG,
// PARM='VAR1=VAL1,VAR2=VAL2,VAR7=VAL7,VAR3=VAL3'

You could have:

// SET VAR1=VAL1
// SET VAR2=VAL2
// SET VAR7=VAL7
// SET VAR3=VAL3
// EXEC PGM=MYPROG

and MYPROG would simply do a getenv(VAR1) to get the value of VAR1 and so 
on. No parsing of the PARM= needed.

I'd almost support that.  And a simple wrapper program to concatenate
variables of a distinguished format could assemble a PARM of enormous
length and issue a CALL.  If the wrapper is not itself AC=1, there's
no hazard of invoking authorized programs with oversized PARM.

My reservation?  Use of symbols in the operand of SET is not supported.
Damn!

-- gil

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Kirk Wolf
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 AMACLIB=PRFX..AMACLIB
// SET LINKLIB=PRFX..LINKLIB


Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Tue, Nov 3, 2009 at 10:04 AM, 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__ 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) they are 
interested in. The plus of this is that others, in other threads, have wanted 
to be able to get the contents of SET variables in their programs. Again, 
this would allow that. But it would take a change to the converter/intepreter 
as well as the initiator. Another plus is that you could use this instead of 
parsing the PARM field.

For example, instead of:

// EXEC PGM=MYPROG,
// PARM='VAR1=VAL1,VAR2=VAL2,VAR7=VAL7,VAR3=VAL3'

You could have:

// SET VAR1=VAL1
// SET VAR2=VAL2
// SET VAR7=VAL7
// SET VAR3=VAL3
// EXEC PGM=MYPROG

and MYPROG would simply do a getenv(VAR1) to get the value of VAR1 and so 
on. No parsing of the PARM= needed.

 I'd almost support that.  And a simple wrapper program to concatenate
 variables of a distinguished format could assemble a PARM of enormous
 length and issue a CALL.  If the wrapper is not itself AC=1, there's
 no hazard of invoking authorized programs with oversized PARM.

 My reservation?  Use of symbols in the operand of SET is not supported.
 Damn!

 -- gil

 --
 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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Tom Marchant
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, The length of the subparameters passed must not
exceed 100 characters, but I wouldn't call that an API.  The Assembler
Services Guide describes the API.  It reads, 

quote
When your program receives control from the system, register 1 contains the
address of a fullword on a fullword boundary in your program's address space
(see Figure 2-4). The high-order bit (bit 0) of this word is set to 1. The
system uses this convention to indicate the last word in a variable-length
parameter list. Bits 1-31 of the fullword contain the address of a two-byte
length field on a halfword boundary. The length field contains a binary
count of the number of bytes in the PARM field, which immediately follows
the length field. If the PARM field was omitted in the EXEC statement, the
count is set to zero. 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.

-- 
Tom Marchant

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Howard Brazee
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 correctly.

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Paul Gilmartin
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 correctly ONLY because the initiator is never going to give
them a parameter string of more that 100 characters. That's the one and only
interface contract. The assertion that you can find programs that behave
well when called directly with longer parameter strings is also true, but
completely uninteresting.

Changing the behavior of PARM is fraught with incompatibilities. So much so
that wiser heads elected not to pull the trigger on it. There are lots of
ways of enabling (much longer) parameter strings but they all necessarily
involve defining some brand new and non- overlapping interface
definition. New programs written to the putative new parameter interface
spec will work correctly and completely oblivious of the old spec. And since
the existing PARM interface will remain unchanged, all old programs will
continue work as they do now, completely oblivious of any new interface.

THAT my friends is compatibility. Not elegant, not pretty, but guaranteed
compatible. Now can we all just get over this nonsense?

The Assembler CALL interface (likewise older than dirt) plus Rexx ATTCHMVS
and many other language calling interfaces (mostly newer than dirt) have
long supported parameters longer than 100.  Are you suggesting that these
facilities are fraught with incompatibilites?  Perhaps so risky that
the facilities should be curtailed?  The existence of these other
interfaces, at least to AC=0 programs, makes the JCL PARM limit a
barrier that surrounds and protects little.  If the JCL PARM limit were
relaxed, all old programs would continue to work exactly as they do now,
when passed the PARMs they are now being passed, completely oblivious
of any new capability.

BTW, I wonder, which is older, Assembler CALL or JCL PARM?  Historians
might answer.  If Assembler is older, JCL is the interloper with a
novel restriction.

And I have seen no horror stories of programs being called outside JCL
with oversize PARMs (although this musing might evince some).  I suspect
that when it happens, the programmer merely shrugs, Oops.  I won't
do that any more.

As an experiment, I called ASMA90 with a PARM length of 32767.  Worked
fine, however pointless.  With a PARM length of 32768, SOC4.  But that
behavior does not mandate a proscription of the facility (Rexx ATTCHPGM)
that I used to call ASMA90 that way, nor any blot on compatibility.
It's just a Don't do that!, even as if the JCL PARM limit were relaxed
to allow me to EXEC PGM=ASMA90,PARMX=some 32768 characters and cause
it to ABEND, it would not be an incompatibility, just a behavior for the
programmer to avoid.  not be an incompatibility,

-- gil

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Paul Gilmartin
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---
While I agree that Chris needs a better understanding of all the issues
involved, I must admit that I agree with the sentiments expressed.

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.

And you, also, need a better understanding.  No one is proposing any
change that will cause existing dusty programs with existing dusty
JCL to fail.  (Well, disregarding the possibility that someone is
deliberately coding an oversize PARM with the intent of causing a
JCL error.  Is anyone actually doing that?)  Even so, each innovation
to JCL, such as the OUTPUT statement, the SET statement, the IF
statement, allowing nested PROC calls, etc. has caused some constructs
that previously would have received JCL errors now to execute, even
in some cases with unintended results.  Do you call those new
behaviors incompatibilities?  Did you object to them as such when
they appeared?  And this is not even considering the impact of
those innovations on JCL syntax checkers.  None of those raises
a valid objection, nor should a longer PARM (or PARMX).

--gil

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Frank Swarbrick
 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__ 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) they are 
 interested in. The plus of this is that others, in other threads, have wanted 
 to be able to get the contents of SET variables in their programs. Again, 
 this would allow that. But it would take a change to the converter/intepreter 
 as well as the initiator. Another plus is that you could use this instead of 
 parsing the PARM field.

For example, instead of:

// EXEC PGM=MYPROG,
// PARM='VAR1=VAL1,VAR2=VAL2,VAR7=VAL7,VAR3=VAL3'

You could have:

// SET VAR1=VAL1
// SET VAR2=VAL2
// SET VAR7=VAL7
// SET VAR3=VAL3
// EXEC PGM=MYPROG

and MYPROG would simply do a getenv(VAR1) to get the value of VAR1 and so 
 on. No parsing of the PARM= needed.

 I'd almost support that.  And a simple wrapper program to concatenate
 variables of a distinguished format could assemble a PARM of enormous
 length and issue a CALL.  If the wrapper is not itself AC=1, there's
 no hazard of invoking authorized programs with oversized PARM.
 
 My reservation?  Use of symbols in the operand of SET is not supported.
 Damn!

I think someone in a prior posting suggested a PARM JCL statement.  I'm not 
sure if this is what he meant, but how about this?

// SET MYVAL=VAL1
// PARM VAR1=MYVAL
// PARM VAR2=VAL2
// PARM VAR7=VAL7
// PARM VAR3=VAL3
// EXEC PGM=MYPROG

SET would still function at it always has.  PARM would be a new type of 
statement that would set an environment variable, and would support the use 
of symbolics.

Could we go further and allow these environment variables in some sort of 
conditional checking, such as:
// IFPARM VAR1='SOMETHING' THEN
//MYDD DD DISP=SHR,DSN=MY.FILE
// ENDIF

I have no idea of the internals of how JCL is supported, so this may be way off 
the beam.

Frank


-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Howard Brazee
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 environment variables is a much better way to go.

For me, the bigger issue is having a system where the JCL calls
programs just as programs call programs.

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Shmuel Metz (Seymour J.)
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 compatibility for existing code that already supports more than
100 characters. Don Ault has already stated that IBM will not do that.

[1] From the beginning.
 
-- 
 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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Stephen Y Odo
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 unsigned
... I would guess that it's signed)?

you can use PARM= OR PARMX= on an EXEC statement but not both ...

if you leave your JCL alone for old stuff, they should still work and
not have to worry about these long PARMs.

if you change your JCL to use PARMX= then you should make sure your
program does handle a long parm string.  if YOU choose to switch to
PARMX= and it results in a problem, then it's YOUR fault.

--Stephen

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Shmuel Metz (Seymour J.)
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 programmer.

New programs wishing to use a
larger plist can be coded to use a new way to get to the data.

If it were only a case of new programs then I would agree that the
existing format is obsolete. However, existing programs, including those
from IBM, support the existing interface for parms longer than 100.
 
-- 
 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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Clark Morris
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 partly beacuse of possibility to have a concatenate
function like:
// PARM 'part 1 .'
// PARM 'part 2 .'
// PARM 'part 3 .'
etc.
An easy way to input a long parm (in JCL).

That would be of considerable value even given the 100-character
limit.  PARM continuation is a PITA, particularly when the JCL
is being generated by a program.  OTOH, JCL symbols provide
fast symptomatic relief:  PARM='PART1PART2PART3'

*BUT*, we still we have the problem of backward incompatibility
regardless of the input format...

As long as authorized programs are excluded, no new incompatibility
is introduced.  Any programmer can today call any unauthorized
program with Rexx with a 65,535 character PARM.

Actually if you use PARMX to pass exactly the same parm with the
exception that the PARM can be over 100 bytes in length, fallout
should be minimal.  The only time PARMX would be used is to pass such
a parm and I would hope that someone would test said use before it
goes into production.  Existing JCL would not be affected and backward
compatibility shouldn't be a problem.  Since an explicit action would
have to be taken to pass a 101 - 65K parm, it should NOT unexpectedly
affect existing programs.  Of course if some makes mass PARM= to
PARMX= changes to JCL all bets are off. 
...
PARM = d2c( 65535 )left( 'WOMBAT', 65535 )
address ATTCHPGM 'MYPROGM PARM'
...

But that's not a solution because it's cumbersome and
doesn't support the use of JCL symbols.

Regarding John M's suggestion of using STEPLIB to suppress
execution in authorized state:

o I'm uneasy with such reliance on a side effect; it lacks
  referential transparency (not that that's ever been much
  a concern in the design of JCL).

o It leaves too great a hazard of inadvertently executing
  a program in authorized state with a long PARM, either
  - because the programmer doesn't supply a STEPLIB and
symbol substitution unexpectedly creates a long PARM
  - or because the data set the programmer supplies is
later marked authorized without consideration of the
indirect consequence.
  Tom M. has supplied an example.

Regarding Clark M's assertion:

Any authorized program that didn't verify that the parm length was
acceptable was poorly coded.  I know that my programs checked for
maximum value and also minimum values so that I knew that the program
didn't pick up garbage.

Kudos.  But even representatives of the most reputable organizations
can slip up:

   Linkname: Re: Long parms ... again (was: Reading DD card information)
URL: http://bama.ua.edu/cgi-bin/wa?A2=ind0909L=ibm-mainamp;P=153276

(My apologies for misattributing this to John EElls; it was
Jim Mulder, citing a survey by Karl Schmitz.)

-- gil

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Howard Brazee
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 shops
that had poor programming.

But in general, backwards compatibility is over-valued and the costs
of backwards compatibility are under-valued.

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Shmuel Metz (Seymour J.)
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 (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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Shmuel Metz (Seymour J.)
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.
 
-- 
 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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Chris Craddock
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, documented interface and literally thousands of badly written
 programs work correctly ONLY because the initiator is never going to give
 them a parameter string of more that 100 characters.snip
 
 The Assembler CALL interface (likewise older than dirt) plus Rexx ATTCHMVS
 and many other language calling interfaces (mostly newer than dirt) have
 long supported parameters longer than 100.  Are you suggesting that these
 facilities are fraught with incompatibilites?  Perhaps so risky that
 the facilities should be curtailed?  The existence of these other
 interfaces, at least to AC=0 programs, makes the JCL PARM limit a
 barrier that surrounds and protects little.  If the JCL PARM limit were
 relaxed, all old programs would continue to work exactly as they do now,
 when passed the PARMs they are now being passed, completely oblivious
 of any new capability.


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 easily be called exactly as you describe.
That's completely and utterly not the point.

There exists an unknowably large pool of programs that were written as batch
job step programs with no expectation or intention of ever being invoked
through any other interface. If you tried to call one of those via an
assembler CALL interface, or ATTACHMVS, or any other permutation you can
cook up and pass it more than 100 bytes of PARM data, you would break that
program in an unpredictable way. Your prescription of well don't do that
is fine in a world where everyone knows what they are doing and pays
attention to the rules. That doesn't resemble the world we live in though.

-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Paul Gilmartin
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 talks about Installation
Control, and clearly the installation has the ability to disallow the
invocation of such programs via TSO/E CALL, TESTAUTH, authorized REXX,
and so on.

However this could be tested, I believe, by using the EXECMVS
(BPX1EXM) service. This can pass a parm string of length up to 4096
(yet another arbitrary number) to any program in linklist (or possibly
a private STEPLIB), and will invoke AC(1) programs in an authorized
state, with, as far as I know, no method of installation control other
than denying UNIX access entirely. An attack based on this would take
some effort, even assuming a buffer overflow and subsequent code
execution can be accomplished, not least because the overlaying code
would have to come from global storage. But PC malware authors have
done the same under more difficult conditions.

So if someone can find an AC(1) IBM module in linklist that does
something Really Bad with a long parm string, this'd be the way.

BPX1EXM invokes its target program as a new jobstep with no
DD statements in effect.  So someone would need to find an AC(1)
IBM module in linklist that does something Really Bad with a long
parm string and no DD statements.  Quite a challenge.

-- gil

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Paul Gilmartin
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 easily be called exactly as you describe.
That's completely and utterly not the point.

There exists an unknowably large pool of programs that were written as batch
job step programs with no expectation or intention of ever being invoked
through any other interface. If you tried to call one of those via an
assembler CALL interface, or ATTACHMVS, or any other permutation you can
cook up and pass it more than 100 bytes of PARM data, you would break that
program in an unpredictable way. Your prescription of well don't do that
is fine in a world where everyone knows what they are doing and pays
attention to the rules. That doesn't resemble the world we live in though.

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 responsibility for ensuring that the
  interface requirements of any program they may call are met.

I strongly doubt the second of those statements.  Therefore,
to avoid breaking programs in unpredictable ways, the OS must
be reinforced to avoid ever passing a PARM 100 characters.
This must be done at the SVC level in order to preclude the
programmer's loading registers and issuing the LINK or ATTACH
SVC with an oversize PARM.  In fact, there's no way to prevent
the programmer's coding LOAD followed by BALR.  Give me a
program with AC=0 that doesn't check its PARM length and I'll
break it.  (Wanna see me make ASMA90 S0C4?  I needed to use
ATTCHPGM; couldn't break it with ATTCHMVS.  I have a tester's
temperament; you can't assume I'll always for be responsible
for ensuring that a program's interface requirements, documented
or otherwise are met.)

-- gil

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Paul Gilmartin
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 desired for a very long time by many people. A
solution is long over due.

The PARMX suggestion would not require any existing programs to be changed,
would not require existing JCL to be changed. Existing JCL and programs
would continue to work without any changes. You don't have to use it, if you
don't like it. PARMX would allow JCL to pass long parms more like other
existing languages.

You could create new JCL or update old JCL to invoke an existing program
using PARMX; that program may or may not be able to gracefully handle parms
greater that 100 characters. If it can, then you have a easy way to pass
that program more than 100 character parm. If it can't, don't use PARMX with
that program.

SAF could be used to control usage of PARMX for those would don't like it.

Implementing PARMS would not prevent other features like environment
 (PARMX, I assume.)
variables, etc. from being implemented as well. That is about as compatible
as you can get. It seems like we are making a mountain out of mole hill, so
I'm going to submit a PARMX requirement to IBM. So IBM will decide.

Amen.

But take care to address Jim Mulder's serious concern that invoking
certain APF-authorized programs with long parms can be highly
destructive.  This could be prevented simply by invoking all
programs in the unauthorized state when PARMX is specified.

But I'd prefer something more transparent, such as a new keyword,
AUTH={ YES | NO | SAF }, where:

o YES (the default) maintains the current behavior: PARM100
  causes a JCL error.  If PARM=100, the PGM is invoked according
  to its AC attribute.

o NO allows PARM100, but any PGM is invoked unauthorized.

o SAF causes a SAF call to determine whether PGM is allowed a
  to be invoked authorized with PARM100.

-- gil

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Thompson, Steve
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 person's opinion.

Regards,
Steve Thompson

-- STD disclaimer, opinions expressed by me, may not be those of my
employer --

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Chris Craddock
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

 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 programmer.


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 because they were guaranteed never to get more
than 100 bytes of parameter data from the initiator. You can play verbal
semantic games all you want, but THAT *IS* A CONTRACT to the programmer. We
can all agree it was a bad idea and that wiser programmers might have
properly dealt with the interface even then, but so what? All of those bad
programs will, for better or worse, continue to run safely because the
behavior of the initiator is not going to change.



 New programs wishing to use a
 larger plist can be coded to use a new way to get to the data.

 If it were only a case of new programs then I would agree that the
 existing format is obsolete. However, existing programs, including those
 from IBM, support the existing interface for parms longer than 100.
  http://bama.ua.edu/archives/ibm-main.html


No Shmuel, that's where you have it precisely backwards. SOME existing
programs can/do correctly interpret the existing interface when called with
a longer parm string by a program other than the initiator. An unknowably
large number don't behave that way and giving a JCL programmer a means (even
accidentally) to pass longer parameter data to those existing programs
through the existing interface is just begging for trouble, which is why it
won't happen.

Dressing the proposal up with a cheat-sheet approach where the initiator can
consult a secret decoder ring to decide whether the long parameter string is
allowed or not is (frankly) kinda nutty. It presents loads more mechanism
and complexity for the OS and creates a maintenance problem with no
guarantees of avoiding a 3AM collision with an otherwise valid program whose
interface needs have not yet been documented.

-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Shmuel Metz (Seymour J.)
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 supports more than 100
characters. It also leads to users believing that they have specified a
parameter when the program actually never sees it.
 
-- 
 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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Shmuel Metz (Seymour J.)
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 program is just another
subroutine.
 
-- 
 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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Paul Gilmartin
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 the JCL RM
that symbols were not to be used in the arguments of SET, but I can
no longer find it.  Can anyone help me here?.  It always worked,
but IBM maintains a fine distinction between supported and
happens to work.

For example from elsewhere in the JCL RM:

   17.1.4.5 z/OS V1R11.0 MVS JCL Reference
 
__
17.1.4.5 Relational-Expression Keywords

   The following keywords are the only keywords supported by IBM and 
recommended for use
   in relational-expressions. Any other keywords, even if accepted by the 
system, are not
   intended or supported keywords.

And the fact that symbols are not substituted between apostrophes in the
argument of SET is a PITA, even though it can be worked around, painstakingly.

-- gil

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Gerhard Postpischil

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 two word list with DD names, etc. I take 
it to provide the minimum you need to know to handle a PARM, 
with no deeper significance.


Gerhard Postpischil
Bradford, VT

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Don Williams
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 desired for a very long time by many people. A
solution is long over due.

The PARMX suggestion would not require any existing programs to be changed,
would not require existing JCL to be changed. Existing JCL and programs
would continue to work without any changes. You don't have to use it, if you
don't like it. PARMX would allow JCL to pass long parms more like other
existing languages.

You could create new JCL or update old JCL to invoke an existing program
using PARMX; that program may or may not be able to gracefully handle parms
greater that 100 characters. If it can, then you have a easy way to pass
that program more than 100 character parm. If it can't, don't use PARMX with
that program. 

SAF could be used to control usage of PARMX for those would don't like it.

Implementing PARMS would not prevent other features like environment
variables, etc. from being implemented as well. That is about as compatible
as you can get. It seems like we are making a mountain out of mole hill, so
I'm going to submit a PARMX requirement to IBM. So IBM will decide.

Don Williams

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Rick Fochtman
Sent: Tuesday, November 03, 2009 12:56 PM
To: IBM-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---
While I agree that Chris needs a better understanding of all the issues 
involved, I must admit that I agree with the sentiments expressed.

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.

Rick

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Rick Fochtman

-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 of all the issues 
involved, I must admit that I agree with the sentiments expressed.


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.


Rick

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Shmuel Metz (Seymour J.)
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 coded to test for jobstep; in fact, there's no incentive
for them to test. If they have code for a first parameter of, e.g., up to
255 then it works just fine for 100 or less.

If so THEN you have a conflict with using a PARMX.

Which was why I proposed an alternative to PARMX.
 
-- 
 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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Paul Gilmartin
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 because they were guaranteed never to get more
than 100 bytes of parameter data from the initiator. You can play verbal
semantic games all you want, but THAT *IS* A CONTRACT to the programmer. We
can all agree it was a bad idea and that wiser programmers might have
properly dealt with the interface even then, but so what? All of those bad
programs will, for better or worse, continue to run safely because the
behavior of the initiator is not going to change.

from the initiator is a major hedge.  Any of those bad programs
(at least with AC=0) can readily be invoked with a long parm by
other means.  If this *IS* A CONTRACT it has so many loopholes
that I'd deem it fraudulent.

 If it were only a case of new programs then I would agree that the
 existing format is obsolete. However, existing programs, including those
 from IBM, support the existing interface for parms longer than 100.
  http://bama.ua.edu/archives/ibm-main.html

No Shmuel, that's where you have it precisely backwards. SOME existing
programs can/do correctly interpret the existing interface when called with
a longer parm string by a program other than the initiator. An unknowably
large number don't behave that way and giving a JCL programmer a means (even
accidentally) to pass longer parameter data to those existing programs
through the existing interface is just begging for trouble, which is why it
won't happen.

Can't we assume that Shumel implied the SOME?  And existing interfaces
(not the interface; stop trying to pretend there's only one) allow
(at least some: those with AC=0) existing programs to be passed longer
parameter data.  For those programs, the putative hazard has existed
as long as the assembler CALL interface.  The universe hasn't ended
as a consequence.  If system integrity or data security is a concern,
then all means of calling any program with a long parm must be
proscribed.

Dressing the proposal up with a cheat-sheet approach where the initiator can
consult a secret decoder ring to decide whether the long parameter string is
allowed or not is (frankly) kinda nutty. It presents loads more mechanism
and complexity for the OS and creates a maintenance problem with no
guarantees of avoiding a 3AM collision with an otherwise valid program whose
interface needs have not yet been documented.

Agreed.  But much simpler:

o AC=0: long parm allowed, as it is now via those pesky alternate
interfaces.

o AC=1: long parm prohibited, even as now.

-- gil

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread John P. Baker
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.

John P. Baker

-Original Message-
From: IBM 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 with long parms can be highly
destructive.  This could be prevented simply by invoking all
programs in the unauthorized state when PARMX is specified.

But I'd prefer something more transparent, such as a new keyword,
AUTH={ YES | NO | SAF }, where:

o YES (the default) maintains the current behavior: PARM100
  causes a JCL error.  If PARM=100, the PGM is invoked according
  to its AC attribute.

o NO allows PARM100, but any PGM is invoked unauthorized.

o SAF causes a SAF call to determine whether PGM is allowed a
  to be invoked authorized with PARM100.

-- gil

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Shmuel Metz (Seymour J.)
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, documented interface

No; it is documented that the C/I (originally the R/I) will never pass
more than 100 characters. It was also documented that there might be other
callers than the Initiator.

Changing the behavior of PARM is fraught with incompatibilities. So much
so that wiser heads elected not to pull the trigger on it.

Changing the behavior is exactly what you propose, and IBM has already
decided that they won't do that. The wiser heads at IBM decided that long
PARM support will continue to use a HW length followed by the characters,
with the main issue left open whether the limit[1] would be 32 KiB - 1 or
64 KiB - 1.

There are lots of ways of enabling (much longer) parameter strings 
but they all necessarily involve defining some brand new and 
non- overlapping interface definition. 

Not unless you need a PARM longer than 64 KiB - 1. Otherwise the existing
HW length will work just fine.

THAT my friends is compatibility. Not elegant, not pretty, but
guaranteed compatible. 

Compatibility means one thing to you and something quite different to me.

Now can we all just get over this nonsense?

Well, per Don Ault we already have; there will be no arbitrary new
interface when the existing interface can handle the job. Of course, we
disagree on what is nonesense.

[1] Yes, a FW would allow for a much higher limit, but per Don Ault
that's not going to happen, and I have never run into a situation
where 1 32 KiB - 1 limit would be inadequate.

-- 
 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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Tony Harminc
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.

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 talks about Installation
Control, and clearly the installation has the ability to disallow the
invocation of such programs via TSO/E CALL, TESTAUTH, authorized REXX,
and so on.

However this could be tested, I believe, by using the EXECMVS
(BPX1EXM) service. This can pass a parm string of length up to 4096
(yet another arbitrary number) to any program in linklist (or possibly
a private STEPLIB), and will invoke AC(1) programs in an authorized
state, with, as far as I know, no method of installation control other
than denying UNIX access entirely. An attack based on this would take
some effort, even assuming a buffer overflow and subsequent code
execution can be accomplished, not least because the overlaying code
would have to come from global storage. But PC malware authors have
done the same under more difficult conditions.

So if someone can find an AC(1) IBM module in linklist that does
something Really Bad with a long parm string, this'd be the way.

Tony H.

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf 
 Of Paul Gilmartin

 But take care to address Jim Mulder's serious concern that invoking
 certain APF-authorized programs with long parms can be highly
 destructive.  This could be prevented simply by invoking all
 programs in the unauthorized state when PARMX is specified.

 But I'd prefer something more transparent, such as a new keyword,
 AUTH={ YES | NO | SAF }, where:

 o YES (the default) maintains the current behavior: PARM100
  causes a JCL error.  If PARM=100, the PGM is invoked according
  to its AC attribute.

 o NO allows PARM100, but any PGM is invoked unauthorized.

 o SAF causes a SAF call to determine whether PGM is allowed a
  to be invoked authorized with PARM100.

 -- gil

--
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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Shmuel Metz (Seymour J.)
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 of maximum parm lengths, using wildcardsw to
provide defaults. I suspect that for IEB* and IEH* that a maximum of 256
would be safe. From a 1995 message that I had forgotten, IBM is more
likely to do the checking in the Interpreter than in the C/I.
 
-- 
 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


Re: An Alternative Modest PARM Proposal

2009-11-03 Thread Chris Craddock
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 responsibility for ensuring that the
  interface requirements of any program they may call are met.

 I strongly doubt the second of those statements.  Therefore,
 to avoid breaking programs in unpredictable ways, the OS must
 be reinforced to avoid ever passing a PARM 100 characters.
 This must be done at the SVC level in order to preclude the
 programmer's loading registers and issuing the LINK or ATTACH
 SVC with an oversize PARM.  In fact, there's no way to prevent
 the programmer's coding LOAD followed by BALR.  Give me a
 program with AC=0 that doesn't check its PARM length and I'll
 break it.  (Wanna see me make ASMA90 S0C4?  I needed to use
 ATTCHPGM; couldn't break it with ATTCHMVS.  I have a tester's
 temperament; you can't assume I'll always for be responsible
 for ensuring that a program's interface requirements, documented
 or otherwise are met.)
 http://bama.ua.edu/archives/ibm-main.html


No I am not inconsistent in my assumptions, but I've obviously failed to
communicate them to you. Let me try one last time.

The fact that you can find programs that are well behaved in the
circumstances you're talking about is not at all in dispute. But neither is
it in the slightest bit relevant. Whether you choose to accept it or not,
the initiator's documented interface existed long before  the other
interfaces you're citing (with the exception of plain old CALL) were even
a developer's wet dream. Lots of horses fled the barn in the mean time.

And I agree that I can't assume you will be responsible for ensuring your
called program's interface requirements are met. In fact, I'm sure I can't.
That's the whole point. Your tester's temperament is at odds with the
stability needs of a production batch environment and I'll take a healthy
sized bet that those production batch environments were there before you
were, so whether you like it or not, they get grandfathered in, even if they
don't play well by the rules you imagine they must.

(Sorry if my architect's temperament is showing)

-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

--
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


Re: An Alternative Modest PARM Proposal

2009-11-02 Thread Binyamin Dissen
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 to indicate the new support.

--
Binyamin Dissen bdis...@dissensoftware.com
http://www.dissensoftware.com

Director, Dissen Software, Bar  Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
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


Re: An Alternative Modest PARM Proposal

2009-11-02 Thread Tom Marchant
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.

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 and the NOXPARM00 member can be supplied with the
PTF or FUNCTION that adds PARMX Support). For ISV (and Home Grown
RYO) utilities that accept mult-parm parmlibs, have the vendor/author
supply the needed members to be placed into PARMLIB.

Does this help?

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.  You have added essentially the same list to is incompatible and
excessively complicated alternative.

-- 
Tom Marchant

--
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


Re: An Alternative Modest PARM Proposal

2009-11-02 Thread Binyamin Dissen
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 compatibility problems ?

:There would be a lateral compatibility problem, in that the
:parm passed from JCL would have a format different from the
:parm passed by other languages, thereby violating one of
:the oldest conventions of OS/360.

Huh?

:Put the length of the parm, whatever length, in the HW.  It's
:how all languages that support long parms now do it.

The suffix does not violate compatibility. A CVT bit could indicate the
support for the suffix.

--
Binyamin Dissen bdis...@dissensoftware.com
http://www.dissensoftware.com

Director, Dissen Software, Bar  Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
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


Re: An Alternative Modest PARM Proposal

2009-11-02 Thread Tom Marchant
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 parm + 0-??? bytes long parm,
:are there any backward compatibility problems ?

:There would be a lateral compatibility problem, in that the
:parm passed from JCL would have a format different from the
:parm passed by other languages, thereby violating one of
:the oldest conventions of OS/360.

Huh?

:Put the length of the parm, whatever length, in the HW.  It's
:how all languages that support long parms now do it.

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 place for the
long parm.  A poor solution, IMO.

-- 
Tom Marchant

--
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


Re: An Alternative Modest PARM Proposal

2009-11-02 Thread Paul Gilmartin
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 problem of powerful system modules that
(although somewhat wrongly) depends on JCL parm never having more
that 100 bytes ?   ...

Today, any programmer can invoke such powerful system modules from
Assembler, Rexx, or several other languages with a long PARM (or
a short PARM.  Simply, they will execute unauthorized (unless the
caller was authorized).  If the rule were that specifying PARMX
caused the PGM always to be run unauthorized, the hazard would be
removed.

  ...  (Will PARMX appear as an ordinarie parm to the
receiving program ?)

I would hope so, to avoid the chaos you fear.  (Operators shouldn't
be concerned with PARM.  Perhaps production supervisors.)

-- gil

--
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


Re: An Alternative Modest PARM Proposal

2009-11-02 Thread Clark Morris
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.  I'm thinking of some sort of caos...
And don't we still have the problem of powerful system modules that
(although somewhat wrongly) depends on JCL parm never having more
that 100 bytes ?   ...

Today, any programmer can invoke such powerful system modules from
Assembler, Rexx, or several other languages with a long PARM (or
a short PARM.  Simply, they will execute unauthorized (unless the
caller was authorized).  If the rule were that specifying PARMX
caused the PGM always to be run unauthorized, the hazard would be
removed.

  ...  (Will PARMX appear as an ordinarie parm to the
receiving program ?)

I would hope so, to avoid the chaos you fear.  (Operators shouldn't
be concerned with PARM.  Perhaps production supervisors.)

Any authorized program that didn't verify that the parm length was 
acceptable was poorly coded.  I know that my programs checked for
maximum value and also minimum values so that I knew that the program
didn't pick up garbage.  

-- gil


--
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


Re: An Alternative Modest PARM Proposal

2009-11-02 Thread Rick Fochtman

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 statement that can 
be as long as necessary.


Rick

--
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


Re: An Alternative Modest PARM Proposal

2009-11-02 Thread Don Williams
I would prefer to be able to pass a long parm to authorized programs.

Authorized programs should be well written to check everything it receives,
otherwise it is a security risk. In other words, an authorized program
should always be written to prevent any detrimental activity, malicious or
otherwise. If it doesn't, I would consider it broken and in need of repair. 

However, I understand that there could be situations where it might not be
feasible to fix them. I would prefer an option to use a security
class/profile control the use of PARMX. Perhaps something like class
FACILITY profile 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 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 problem of powerful system modules that
(although somewhat wrongly) depends on JCL parm never having more
that 100 bytes ?   ...

Today, any programmer can invoke such powerful system modules from
Assembler, Rexx, or several other languages with a long PARM (or
a short PARM.  Simply, they will execute unauthorized (unless the
caller was authorized).  If the rule were that specifying PARMX
caused the PGM always to be run unauthorized, the hazard would be
removed.

  ...  (Will PARMX appear as an ordinarie parm to the
receiving program ?)

I would hope so, to avoid the chaos you fear.  (Operators shouldn't
be concerned with PARM.  Perhaps production supervisors.)

-- gil

--
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


Re: An Alternative Modest PARM Proposal

2009-11-02 Thread Paul Gilmartin
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:
// PARM 'part 1 .'
// PARM 'part 2 .'
// PARM 'part 3 .'
etc.
An easy way to input a long parm (in JCL).

That would be of considerable value even given the 100-character
limit.  PARM continuation is a PITA, particularly when the JCL
is being generated by a program.  OTOH, JCL symbols provide
fast symptomatic relief:  PARM='PART1PART2PART3'

*BUT*, we still we have the problem of backward incompatibility
regardless of the input format...

As long as authorized programs are excluded, no new incompatibility
is introduced.  Any programmer can today call any unauthorized
program with Rexx with a 65,535 character PARM.

...
PARM = d2c( 65535 )left( 'WOMBAT', 65535 )
address ATTCHPGM 'MYPROGM PARM'
...

But that's not a solution because it's cumbersome and
doesn't support the use of JCL symbols.

Regarding John M's suggestion of using STEPLIB to suppress
execution in authorized state:

o I'm uneasy with such reliance on a side effect; it lacks
  referential transparency (not that that's ever been much
  a concern in the design of JCL).

o It leaves too great a hazard of inadvertently executing
  a program in authorized state with a long PARM, either
  - because the programmer doesn't supply a STEPLIB and
symbol substitution unexpectedly creates a long PARM
  - or because the data set the programmer supplies is
later marked authorized without consideration of the
indirect consequence.
  Tom M. has supplied an example.

Regarding Clark M's assertion:

Any authorized program that didn't verify that the parm length was
acceptable was poorly coded.  I know that my programs checked for
maximum value and also minimum values so that I knew that the program
didn't pick up garbage.

Kudos.  But even representatives of the most reputable organizations
can slip up:

   Linkname: Re: Long parms ... again (was: Reading DD card information)
URL: http://bama.ua.edu/cgi-bin/wa?A2=ind0909L=ibm-mainamp;P=153276

(My apologies for misattributing this to John EElls; it was
Jim Mulder, citing a survey by Karl Schmitz.)

-- gil

--
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


Re: An Alternative Modest PARM Proposal

2009-11-02 Thread Paul Gilmartin
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 IBM compilers will also accept a *PROCESS statement that can
be as long as necessary.

o Have you checked _all_ the compilers?  What about HLASM?

o What about ISV programs and even user programs?

o Does this support JCL symbol substitution in the body of
  the *PROCESS statement?  (I suspect not.)

Admitted, I've been able to pass long parms to programs from
Rexx.  And even to manufacture those parms using JCL symbols
passed in the parm to Rexx.  The Modest Proposal under
discussion here is to make the operation simpler.

-- gil

--
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


Re: An Alternative Modest PARM Proposal

2009-11-02 Thread Binyamin Dissen
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 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 passed from JCL would have a format different from the
::parm passed by other languages, thereby violating one of
::the oldest conventions of OS/360.

:Huh?

::Put the length of the parm, whatever length, in the HW.  It's
::how all languages that support long parms now do it.

: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 place for the
:long parm.  A poor solution, IMO.

Compatibility has its costs. This solution does not change the number of
parameters and is completely compatible.

--
Binyamin Dissen bdis...@dissensoftware.com
http://www.dissensoftware.com

Director, Dissen Software, Bar  Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
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


Re: an alternative modest PARM proposal

2009-11-02 Thread john gilmore
| 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 
substring of a card image.  Multiple process statements are, however, often 
supported.  Le bon Dieu est dans le détail.


John Gilmore Ashland, MA 01721-1817 USA


  
_
Hotmail: Trusted email with Microsoft's powerful SPAM protection.
http://clk.atdmt.com/GBL/go/177141664/direct/01/
http://clk.atdmt.com/GBL/go/177141664/direct/01/

--
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


Re: An Alternative Modest PARM Proposal

2009-11-02 Thread Robert A. Rosenberg
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 member 
with a list of programs that are NOT to be passed an extended parm 
(IBM knows who they are and the NOXPRM00 member can be supplied with 
the PTF or FUNCTION that adds PARMX Support). For ISV (and Home 
Grown RYO) utilities that accept mult-parm parmlibs, have the 
vendor/author supply the needed members to be placed into PARMLIB.

unsnip--
Do you intend to include in that list the potentially thousands of 
application programs that might accept a parm string in any business 
shop? And parse that list at IPL time? Or at program initiation 
time? What about existing apps that nobody can even remember the 
details inside?


Why not? For ISV code they just supply the needed PARMLIB member as 
they currently do. As for RYO code, the program is BAD (Broken As 
Designed) if it accepts additional parms when called as opposed to 
JCL Launched and does not validate them. Note that my comment is NOT 
about passing a longer than 100 byte parm as the ONLY entry in the 
passed Parm List but passing a 2 entry parm with the 2nd entry as the 
extended parm. The only case where there would be a conflict (and 
thus a need to suppress the passing of the PARMX) is for those 
programs ALREADY able to be passed a mult-parm parm list WHEN CALLED. 
All other programs would need to be written to look for a 2nd parm 
with an PARMX longer string.


If you have multi-parm accepting programs you are unaware of, WHY are 
you attempting to pass them a PARMX via JCL in the first place? 
Remember that you need to add the support in the first place and thus 
it is an error to just code a PARMX for a program that will not 
accept it (independent of the CALLED PARMLIST issue). You also have 
the sanity check issue I mentioned above where the PARMX attempt 
should cause the program to reject the PARMX or malfunction and this 
signal the need to fix the JCL to remove the erroneous PARMX.


--
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


Re: An Alternative Modest PARM Proposal

2009-11-02 Thread Robert A. Rosenberg
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 accept 
a longer than 100 character PARM Entry (while also accepting DDNAME 
Overrides in Parms 2+)? If so THEN you have a conflict with using a 
PARMX. If the passed PARM is still only 100 bytes even when called, 
there is no issue.


--
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


Re: An Alternative Modest PARM Proposal

2009-11-02 Thread Paul Gilmartin
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 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+)? If so THEN you have a conflict with using a
PARMX. If the passed PARM is still only 100 bytes even when called,
there is no issue.

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 taken as a ddnamelist.

Then, as I cited yesterday (but I also often fail to read the
preceding plies in threads):

   Linkname: Invoking the assembler dynamically
URL: 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ASMP1020/7.5

Clearly mentions that ddnamelist is supported, but omits mention
of a limit of length of optionlist.  RCF submitted.

-- gil

--
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


Re: An Alternative Modest PARM Proposal

2009-11-02 Thread Paul Gilmartin
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 place for the
:long parm.  A poor solution, IMO.

Compatibility has its costs. This solution does not change the number of
parameters and is completely compatible.

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 of the target program nor of the calling language
(i.e. Rexx).  You seem to advocate that the interface when called
from JCL should differ from the interface when called from Rexx, etc.
I can't view that as compatible.

Yes, some programs would break if they could be called from JCL
with long parms, identically as they'd break if called from Rexx,
etc. with the same parms.  Even that identical behavior in breakage
is a form of compatibility.

-- gil

--
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


Re: An Alternative Modest PARM Proposal

2009-11-02 Thread Chris Craddock


 
 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 of the target program nor of the calling language
 (i.e. Rexx).  You seem to advocate that the interface when called
 from JCL should differ from the interface when called from Rexx, etc.
 I can't view that as compatible.

 Yes, some programs would break if they could be called from JCL
 with long parms, identically as they'd break if called from Rexx,
 etc. with the same parms.  Even that identical behavior in breakage
 is a form of compatibility.



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 correctly ONLY because the initiator is never going to give
them a parameter string of more that 100 characters. That's the one and only
interface contract. The assertion that you can find programs that behave
well when called directly with longer parameter strings is also true, but
completely uninteresting.

Changing the behavior of PARM is fraught with incompatibilities. So much so
that wiser heads elected not to pull the trigger on it. There are lots of
ways of enabling (much longer) parameter strings but they all necessarily
involve defining some brand new and non- overlapping interface
definition. New programs written to the putative new parameter interface
spec will work correctly and completely oblivious of the old spec. And since
the existing PARM interface will remain unchanged, all old programs will
continue work as they do now, completely oblivious of any new interface.

THAT my friends is compatibility. Not elegant, not pretty, but guaranteed
compatible. Now can we all just get over this nonsense?

-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

--
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


Re: An Alternative Modest PARM Proposal

2009-11-01 Thread Rick Fochtman

-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 and the NOXPARM00 member can be supplied with the PTF or 
FUNCTION that adds PARMX Support). For ISV (and Home Grown RYO) 
utilities that accept mult-parm parmlibs, have the vendor/author supply 
the needed members to be placed into PARMLIB.

unsnip--
Do you intend to include in that list the potentially thousands of 
application programs that might accept a parm string in any business 
shop? And parse that list at IPL time? Or at program initiation time? 
What about existing apps that nobody can even remember the details inside?


Rick
---
Accept the fact that some days you're the pigeon, other days you're the 
statue.


--
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


Re: An Alternative Modest PARM Proposal

2009-11-01 Thread Ted MacNEIL
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 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


Re: An Alternative Modest PARM Proposal

2009-11-01 Thread Shmuel Metz (Seymour J.)
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 limit going back to the
1960's.

-- 
 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


Re: An Alternative Modest PARM Proposal

2009-11-01 Thread Shmuel Metz (Seymour J.)
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 standard is that bit 0 indicates the end of the list and
that the first word points to a halfword length followed by characters.
The 100 character limit is strictly a C/I limited, and various IBM
utilities accept longer parms.

Make the new method a 2 FW Parm list with FW 1 pointing at the old  100
character PARM and FW 2 (which is End of Parmlist flagged)  pointing at
the new Long Parm.

That would break compatibility badly.

BTW: There are a number of IBM utilities that ALREADY check the  length
of their Parmlist since they support being launched by JCL  with a PARM
and being CALLED with a real muli-parm parmlist (the 2nd  and subsequent
parms often being DDN overrides).

Which is one of the reasons why your suggestion won't fly.

BTW, I had forgotten about an old (1995) post from Don Ault in which he
said that IBM will not implement long parms in a fashion incompatible with
the existing interface. He left it open as to whether the length field
would be signed or unsigned.

-- 
 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


Re: An Alternative Modest PARM Proposal

2009-11-01 Thread Paul Gilmartin
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.

There is NO REASON to send a Long Parm to these IBM utilities so this

Very wrong!  RTFM.  Namely:

   Linkname: Invoking the assembler dynamically, 7.5
URL: 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/asmp1020/7.5

Harsh langage?  Perhaps, but:

o You're the one who started shouting (NO REASON).

o I'm weary of writers spreading disinformation on this topic
  with the goal of inciting FUD.

Not a utility, precisely, but a supported and widely used IBM program.
And I personally have usefully called HLASM (from Rexx) with a PARM
exceeding 100 characters.  I recognized this to my frustration when I
attempted to replace the Rexx with JCL.

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 and the NOXPARM00 member can be supplied with the
PTF or FUNCTION that adds PARMX Support). For ISV (and Home Grown
RYO) utilities that accept mult-parm parmlibs, have the vendor/author
supply the needed members to be placed into PARMLIB.

Does this help?

No.  Far too much an administrative burden.  It'll never fly.

I have a better idea.  Indicate to the program that it's being passed
a long PARM by calling it with R1 pointing to a fullword (with the
sign bit set) addressing a halfword containing a value greater than
or equal to 101, followe by the parameter string.  Indicate to the
program that it's being passed an old-fashioned PARM by calling it
with R1 addressing a fullword (with the sign bit set) addressing a
halfword containing a value less than or equal to 100, followed by
the parameter string.

Fully compatible with the current behavior of HLASM and many other
programs, and no added administrative duties.

-- gil

--
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


Re: An Alternative Modest PARM Proposal

2009-11-01 Thread Paul Gilmartin
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.

There is NO REASON to send a Long Parm to these IBM utilities so this

Very wrong.  RTFM.  Namely:

   Linkname: Invoking the assembler dynamically
URL: 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ASMP1020/7.5

Harsh language?  Perhaps.  However:

o You're the one who started shouting (NO REASON).

o I'm weary of writers spreading disinformation on this topic
  with the goal of inciting FUD.

Not precisely a utility, but a very standard and widely used IBM
program which accepts both an alternate DDNAME list and to which
I have long been usefuly passing a long PARM (from Rexx), as I
realized with dismay when I attempted to convert the Rexx to JCL.

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 and the NOXPARM00 member can be supplied with the
PTF or FUNCTION that adds PARMX Support). For ISV (and Home Grown
RYO) utilities that accept mult-parm parmlibs, have the vendor/author
supply the needed members to be placed into PARMLIB.

Does this help?

No.  It's an unacceptable burden to administrators, and even to
maintainers of IBM utilities themselves.

I have a better idea.  Indicate to a program that it's being invoked
with a long parm by placing in R1 the address of a fullword (with the
sign bit set) addressing a halfword containing a value greater than
or equal to 101, followed by the parameter string.  Indicate to a
program that it's being passed an old-fashioned PARM by placing in R1
the address of a fullword (with the sign bit set) addressing a
halfword containing a value less than or equal to 101, followed
by the parameter string.  This is fully compatible with the existing
design of HLASM and many other IBM and ISV programs, and places no
new duties on adminstrators.

-- gil

--
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


Re: An Alternative Modest PARM Proposal

2009-10-30 Thread McKown, John
 -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, but I would 
 like to put
 forward an alternative proposal.
 
 For a short PARM= value (compatibility mode), R1 - fullword 
 address of
 PARM= info, consisting of a 2-byte length prefix (value 
 0..100) followed by
 a string buffer not exceeding 100 bytes.
 
 For a long PARM= value, R1 - fullword address of PARM= info, 
 consisting of
 a 4-byte length prefix (negated (high-order bit = B'1'), value
 101..installation-defined-maximum), followed by a fullword 
 address of a
 string buffer not exceeding installation-defined-maximum 
 bytes, followed by
 a fullword ALET identifying the dataspace wherein the string buffer is
 located.
 
 FWIW, z/VSE currently allows a maximum PARM= length of 300 
 bytes, coded in
 up to three (3) PARM=value specifications on an EXEC 
 statement, with the
 values being concatenated by the JCL processor.
 
 John P. Baker

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 code will fail. Any changes to this 
must keep the current interface as it currently is. I still like using POSIX 
environment variables and being able to set them at the job level via JCL. 
Then just use the getenv() type call to get the value for any particular 
variable you're expecting.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
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


Re: An Alternative Modest PARM Proposal

2009-10-30 Thread Shmuel Metz (Seymour J.)
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 JCL,
even mechanically generated JCL, should probably choose a
different language.

Personally, I could live with 32 KiB - 1.
 
-- 
 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


Re: An Alternative Modest PARM Proposal

2009-10-30 Thread Shmuel Metz (Seymour J.)
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
compatibility with existing code.

For a long PARM= value, R1 - fullword address of PARM= info, consisting
of a 4-byte length prefix (negated (high-order bit = B'1'), value
101..installation-defined-maximum), followed by a fullword address of a
string buffer not exceeding installation-defined-maximum bytes, followed
by a fullword ALET identifying the dataspace wherein the string buffer
is located.

That might be a good design for a new system with no compatibility
constraints, but it destroys compatibility with existing code.

-- 
 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


Re: An Alternative Modest PARM Proposal

2009-10-30 Thread Robert A. Rosenberg
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 
code will fail. Any changes to this must keep the current interface 
as it currently is.


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).


Make the new method a 2 FW Parm list with FW 1 pointing at the old 
100 character PARM and FW 2 (which is End of Parmlist flagged) 
pointing at the new Long Parm. The only GOTHCHA with an old style 
program is if it gets paranoid and actually checked the 
end-of-parmlist flag on the single FW it expects to be passed to it.


BTW: There are a number of IBM utilities that ALREADY check the 
length of their Parmlist since they support being launched by JCL 
with a PARM and being CALLED with a real muli-parm parmlist (the 2nd 
and subsequent parms often being DDN overrides).


--
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


Re: An Alternative Modest PARM Proposal

2009-10-30 Thread Paul Gilmartin
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 for
the current standard. If someone used a long PARM, then your old
code will fail. Any changes to this must keep the current interface
as it currently is.

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).

Make the new method a 2 FW Parm list with FW 1 pointing at the old
100 character PARM and FW 2 (which is End of Parmlist flagged)
pointing at the new Long Parm. The only GOTHCHA with an old style
program is if it gets paranoid and actually checked the
end-of-parmlist flag on the single FW it expects to be passed to it.

BTW: There are a number of IBM utilities that ALREADY check the
length of their Parmlist since they support being launched by JCL
with a PARM and being CALLED with a real muli-parm parmlist (the 2nd
and subsequent parms often being DDN overrides).

Therefore, you should understand very well why this won't work.
Such utilities will misinterpret the Long Parm as a DDN override
list.

-- gil

--
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


Re: An Alternative Modest PARM Proposal

2009-10-30 Thread Rick Fochtman

--snip
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).


Make the new method a 2 FW Parm list with FW 1 pointing at the old 100 
character PARM and FW 2 (which is End of Parmlist flagged) pointing at 
the new Long Parm. The only GOTHCHA with an old style program is if it 
gets paranoid and actually checked the end-of-parmlist flag on the 
single FW it expects to be passed to it.


BTW: There are a number of IBM utilities that ALREADY check the length 
of their Parmlist since they support being launched by JCL with a PARM 
and being CALLED with a real muli-parm parmlist (the 2nd and subsequent 
parms often being DDN overrides).

---unsnip
What's to stop older programs from interpreting the second FW as a 
pointer to a DDNAME list?


Rick

--
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


Re: An Alternative Modest PARM Proposal

2009-10-30 Thread Robert A. Rosenberg
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.


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 and the NOXPARM00 member can be supplied with the 
PTF or FUNCTION that adds PARMX Support). For ISV (and Home Grown 
RYO) utilities that accept mult-parm parmlibs, have the vendor/author 
supply the needed members to be placed into PARMLIB.


Does this help?

--
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


Re: An Alternative Modest PARM Proposal

2009-10-29 Thread Paul Gilmartin
On Thu, 29 Oct 2009 17:28:44 -0400, John P. Baker wrote:

For a short PARM= value (compatibility mode), R1 - fullword address of
PARM= info, consisting of a 2-byte length prefix (value 0..100) followed by
a string buffer not exceeding 100 bytes.

For a long PARM= value, R1 - fullword address of PARM= info, consisting of

Again, NO!  Provide in JCL the facility now provided by Rexx
address ATTCHMVS, in a completely compatible fashion.

a 4-byte length prefix (negated (high-order bit = B'1'), value
101..installation-defined-maximum), followed by a fullword address of a
string buffer not exceeding installation-defined-maximum bytes, followed by
a fullword ALET identifying the dataspace wherein the string buffer is
located.

An interesting alternative.  But why not just use 64-bit addressing?
dataspaces are _so_ 20th century.

How does the JCL programmer specify the dataspace?  Or does the
Interpreter select one by colonic extraction?

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 JCL,
even mechanically generated JCL, should probably choose a
different language.

-- gil

--
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


Re: An Alternative Modest PARM Proposal

2009-10-29 Thread Don Williams
I think that would break many programs. Many standard utilities,
compilers, etc. expect to invoked from either JCL where there is only one
parm or dynamically called with one or more parms. Off the top of my head I
can't remember for format of the second parm other than it is used to
dynamically change the standard DDNAMEs to user specified. This mean that if
you accidently executed one of those programs with PARMX='' it would get
all confused. 

I still vote for a simple PARMX='long-string' where the GPR1 - fullword (w/
high bit set to 1) - 2-byte-length followed by a long string.
I originally said that the max length could be 32k-1 or 64k-1, but only
because that's was a convenient max for a 2 byte length field. However, a
max size even as small as 1024 to 4096 would very likely satisfy well over
99% of anyone's true need to pass a long parm. I find it difficult to
envision JCL with a parm string that was many thousands of characters long
(that's a lot of continuations). Besides there are very likely other limits
in the converter/interpreter, text units, JES, etc. that would make
massively long parms difficult to implement. If even longer parms are
needed, the various current methods to pass longer parms by dynamically
calling the program could still be used. 

I think that my proposal seems to be the simplest (KISS), seems likely to
break fewer things, and the very important to IBM, cheaper to design,
implement, and test while satisfying many customer's long standing desire to
have a much long parm field.

Don Williams

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of John P. Baker
Sent: Thursday, October 29, 2009 5:29 PM
To: IBM-MAIN@bama.ua.edu
Subject: An Alternative Modest PARM Proposal

All,

 

The proposal previously set forth is interesting, but I would like to put
forward an alternative proposal.

 

For a short PARM= value (compatibility mode), R1 - fullword address of
PARM= info, consisting of a 2-byte length prefix (value 0..100) followed by
a string buffer not exceeding 100 bytes.

 

For a long PARM= value, R1 - fullword address of PARM= info, consisting of
a 4-byte length prefix (negated (high-order bit = B'1'), value
101..installation-defined-maximum), followed by a fullword address of a
string buffer not exceeding installation-defined-maximum bytes, followed by
a fullword ALET identifying the dataspace wherein the string buffer is
located.

 

FWIW, z/VSE currently allows a maximum PARM= length of 300 bytes, coded in
up to three (3) PARM=value specifications on an EXEC statement, with the
values being concatenated by the JCL processor.

 

John P. Baker


--
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