LONGPARM

Post by Charles Mills
- A valid EXEC PARM= operand may never be longer than 100 bytes, no matter
what. (Neglecting nit-picking about doubled quotes, etc.)
- The V2R1 LONGPARM feature (APF-authorized programs only) is only relevant
to the EXEC PARMDD= situation.

You can pass long (>100 byte) parameter strings to both authorized and
unauthorized programs. However, the system will fail the load if you
attempt to pass a long (>100 byte) parm string to an authorized program
that does not have the LONGPARM binder attribute set. That prevents an
authorized program from being "fooled" into overlaying something important.
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Charles Mills

2017-12-01 00:31:01 UTC

This post might be inappropriate. Click to display it.

Ed Jaffe

2017-12-01 02:38:49 UTC

Post by Charles Mills
Thanks.
Got it. In order for a program to be passed > 100 bytes from // EXEC it must be either not authorized or linked with LONGPARM (or both).
Am I right on bullet one? Parms greater than 100 bytes are a PARMDD thing only, never a PARM= thing?

You can *never* pass more than 100 bytes via PARM=. If you want a longer
parameter, you *must* use PARMDD.

The interface as seen by the program is the same in both cases: halfword
length followed by data.
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Paul Gilmartin

2017-12-01 03:25:21 UTC

What about the ATTACH, XCTL, LINK, and LOAD/CALL macros. Prior to
the innovation of the LONGPARM attribute it was the responsibility of
either the parent or child task (not clearly documented which?) to
verify PARM length. Do these nowadays respect the NOLONGPARM
setting?

A defensively coded subroutine should *always* validate its arguments.
It seems OS/360 developers were unaware of this.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Ed Jaffe

2017-12-01 04:42:08 UTC

Post by Paul Gilmartin
What about the ATTACH, XCTL, LINK, and LOAD/CALL macros.

PARM= and PARMDD are JCL constructs only.

LONGPARM isn't used other than during initial establishment of an APF
authorized job step.
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Charles Mills

2017-12-01 16:26:46 UTC

@Gil, there are two issues:

There is no *integrity* exposure (at least in theory) from long parms and CALL, XCTL, etc. Either both programs are loaded from an APF-authorized library (in which case we are forced to assume honesty and competence on the part of the authors*) or else the called program is certainly not running authorized, so while a longer than expected PARM might cause a S0Cx, it cannot affect the integrity of the system as a whole. In other words, it can overlay program storage but not system storage.

*Laugh if you want, but if you don't make that assumption then all of MVS integrity goes down the drain.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Thursday, November 30, 2017 7:27 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: LONGPARM

You can *never* pass more than 100 bytes via PARM=. If you want a
longer parameter, you *must* use PARMDD.
halfword length followed by data.

What about the ATTACH, XCTL, LINK, and LOAD/CALL macros. Prior to the innovation of the LONGPARM attribute it was the responsibility of either the parent or child task (not clearly documented which?) to verify PARM length. Do these nowadays respect the NOLONGPARM setting?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Tony Harminc

2017-12-01 20:05:21 UTC

On 30 November 2017 at 22:26, Paul Gilmartin <

Post by Ed Jaffe
You can *never* pass more than 100 bytes via PARM=. If you want a longer
parameter, you *must* use PARMDD.
The interface as seen by the program is the same in both cases: halfword
length followed by data.

There is nothing in the nature of ATTACH, XCTL, LINK or LOAD/CALL that
suggests the argument(s) must be of the form halfword length followed by
data. And indeed it's very often the case that internal routines have R1
pointing at some quite different data structure. For that matter R1 doesn't
have to be a valid pointer at all. Any checking/rejection at the system
level that assumed this kind of argument would cause huge breakage all over
the place.

Post by Paul Gilmartin
Do these nowadays respect the NOLONGPARM setting?

Clearly not. They have no way of knowing what kind of data the called
program is expecting.

A defensively coded subroutine should *always* validate its arguments.
No argument. (Yeah, I know...)

Post by Paul Gilmartin
It seems OS/360 developers were unaware of this.

I don't know why you say that. I think we've been through this a zillion
times on this list. Many programs depended on the documented restriction
that JCL-supplied parms could not exceed 100 bytes. While this may not be
*the* greatest design, it was common. There was no integrity exposure until
facilities to pass in long parms to a job step program became available,
and the "in the wild" exposure wasn't very long (it was fixed between the
time I noticed it and when I got a demo exploit ready to send to IBM...)
GIven that there's still at least one OS/390 user out there, I won't
publish the exploit for another few years. In any case, finding your own is
close to trivial.

Tony H.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Charles Mills

2017-12-01 20:46:52 UTC

Many programs depended on the documented restriction that JCL-supplied parms could
not exceed 100 bytes. While this may not be *the* greatest design, it was common.

And in fairness, we were constrained in those days by limited memory, 4K base register issues and relatively slow instruction times. Why waste bytes, addressability and cycles just to make sure OS/360 was behaving as advertised?

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Tony Harminc
Sent: Friday, December 1, 2017 12:07 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: LONGPARM

Post by Ed Jaffe
You can *never* pass more than 100 bytes via PARM=. If you want a
longer parameter, you *must* use PARMDD.
halfword length followed by data.

There is nothing in the nature of ATTACH, XCTL, LINK or LOAD/CALL that suggests the argument(s) must be of the form halfword length followed by data. And indeed it's very often the case that internal routines have R1 pointing at some quite different data structure. For that matter R1 doesn't have to be a valid pointer at all. Any checking/rejection at the system level that assumed this kind of argument would cause huge breakage all over the place.

Do these nowadays respect the NOLONGPARM setting?

Clearly not. They have no way of knowing what kind of data the called program is expecting.

A defensively coded subroutine should *always* validate its arguments.
No argument. (Yeah, I know...)

It seems OS/360 developers were unaware of this.

Seymour J Metz

2017-12-01 20:55:33 UTC

What was advertised was that a main program was just another subroutine. OS/360 did not advertise that the caller of a subroutine would always pass correct parameters.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Charles Mills <***@MCN.ORG>
Sent: Friday, December 1, 2017 3:48 PM
To: IBM-***@listserv.ua.edu
Subject: Re: LONGPARM

Many programs depended on the documented restriction that JCL-supplied parms could
not exceed 100 bytes. While this may not be *the* greatest design, it was common.

Post by Ed Jaffe
You can *never* pass more than 100 bytes via PARM=. If you want a
longer parameter, you *must* use PARMDD.
halfword length followed by data.

There is nothing in the nature of ATTACH, XCTL, LINK or LOAD/CALL that suggests the argument(s) must be of the form halfword length followed by data. And indeed it's very often the case that internal routines have R1 pointing at some quite different data structure. For that matter R1 doesn't have to be a valid pointer at all. Any checking/rejection at the system level that assumed this kind of argument would cause huge breakage all over the place.

Do these nowadays respect the NOLONGPARM setting?

Clearly not. They have no way of knowing what kind of data the called program is expecting.

A defensively coded subroutine should *always* validate its arguments.
No argument. (Yeah, I know...)

It seems OS/360 developers were unaware of this.

I don't know why you say that. I think we've been through this a zillion times on this list. Many programs depended on the documented restriction that JCL-supplied parms could not exceed 100 bytes. While this may not be
*the* greatest design, it was common. There was no integrity exposure until facilities to pass in long parms to a job step program became

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Paul Gilmartin

2017-12-01 05:09:33 UTC

Post by Paul Gilmartin
What about the ATTACH, XCTL, LINK, and LOAD/CALL macros.

PARM= and PARMDD are JCL constructs only.
LONGPARM isn't used other than during initial establishment of an APF
authorized job step.

"LONGPARM isn't used ..." has confusing semantics. That would seem to imply
that in other contexts the 100-character limit is enforced. Or in those other cases,
is LONGPARM presumed?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Peter Hunkeler

2017-12-01 12:57:40 UTC

"LONGPARM isn't used ..." has confusing semantics. That would seem to imply that in other contexts the 100-character limit is enforced. Or in those other cases, is LONGPARM presumed?

You made me curious, so I went to RTFM. I will submit an RCF, because the documentation couldn't be more fuzzy and confusing, IMHO. Before submitting, I would like to get your opinion on my comments below.

o The Binder manual talks about: "The system checks ... and the program is APF authorized."
A program is not APF authorized, the job step TCB is or is not.

o The JCL Reference manual talks about: "If the program to be invoked is from an APF authorized library *or* has been bound with the AC(1) attribute..."
The *or* is confusing.

LONPARM is not mentioned with the LINK or ATTACH service. This makes sense and indicates to me that it is the *initiator* doing this verification when it prepares to attach the program.
So the binder and JCL manuals should say that "The system will check at job step initiation when the job step will be set APF authorized....

--
Peter Hunkeler

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Ed Jaffe

2017-12-01 15:26:45 UTC

Post by Ed Jaffe
LONGPARM isn't used other than during initial establishment of an APF
authorized job step.

"LONGPARM isn't used ..." has confusing semantics. That would seem to imply
that in other contexts the 100-character limit is enforced. Or in those other cases,
is LONGPARM presumed?

LONGPARM allows parms > 100 bytes to be passed to authorized programs
invoked via JCL // EXEC statement. Nothing confusing about that.

Stated another way: if your program is bound with AC(1) and loaded from
an APF authorized concatenation, you will need LONGPARM if you wish to
receive parms > 100 bytes. Without LONGPARM, your program will only be
allowed to receive parms <= 100 bytes.

Programs invoked through other means (ATTACH, etc) and unauthorized
programs invoked via JCL // EXEC statement can receive long parms as well.

It's just that simple...
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Maxim Bochagov

2017-12-01 15:58:44 UTC

Hello All,

What about to check the existence of a PARM DD-name before the fetch
of inline params?
Like, if you want to pass a long parlist and it is more than 100
bytes, then just specify a //PARM DD * card before this mind flow.
Anycase, this way is a LOCAL FIX for this problem, IMHO..

=Maxim

Post by Ed Jaffe
LONGPARM isn't used other than during initial establishment of an APF
authorized job step.

"LONGPARM isn't used ..." has confusing semantics. That would seem to imply
that in other contexts the 100-character limit is enforced. Or in those other cases,
is LONGPARM presumed?

LONGPARM allows parms > 100 bytes to be passed to authorized programs
invoked via JCL // EXEC statement. Nothing confusing about that.
Stated another way: if your program is bound with AC(1) and loaded from an
APF authorized concatenation, you will need LONGPARM if you wish to receive
parms > 100 bytes. Without LONGPARM, your program will only be allowed to
receive parms <= 100 bytes.
Programs invoked through other means (ATTACH, etc) and unauthorized programs
invoked via JCL // EXEC statement can receive long parms as well.
It's just that simple...
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

--
Regards,
=Maxim Bochagov

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

Tom Marchant

2017-12-01 13:14:34 UTC