1. TSO *doesn't* get "quarantined like a contagious pit-bull"; rather, TSO
imposes a firewall between authorized and unauthorized code. The same
firewall, implemented differently, exists for PGM=foo.
2. If PGM=ABC does not require APF authorization then you can run ABC
under TSO without "extra hurdles".
3. I found out that it took less of my time to keypunch my program than to
correct the errors made by the keypunch operators.
4. "Who knew what you were doing or to what end?"
Were your keypunch operators qualified to do a code review? Your
operators? If your management believed that they had more control
over what you did in batch, they were deluding themselves.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of
Jesse 1 Robinson <[email protected]>
Sent: Monday, November 18, 2019 7:09 PM
To: [email protected]
Subject: Re: AUTHPGM in IKJTSOxx
I share the curiosity about why TSO gets quarantined like a contagious
pit-bull. If I can run PGM=ABC in a batch job with no more authorization that
SAF READ to the load library, then why are there extra hurdles to run the exact
same program under TSO? I don't mean technically why; I mean architecturally
why.
This is speculation tempered by anecdotal history. Despite being an old fart, I
got into this biz pretty late, 1978. By that time my first employer--ancestor
of Experian--was just rolling out TSO to the unwashed masses. It rapidly
replaced a nearly universal industry protocol of writing out a program, JCL,
etc. on coding sheets; submitting them to the keypunch department; then waiting
a day (or more) for a computer turnaround. After the results came back, you
either did a rinse-and-repeat or progressed to whatever you perceived the next
step to be. That was development.
'Foreground execution' presented a huge boon to productivity, but also a cause
for anxiety among the powers that be. Background execution required a village.
Foreground execution required only some taps on a keyboard in private. Who knew
what you were doing or to what end? The cows that had been properly confined to
the stockyard were suddenly allowed to run roughshod over an unfenced range.
This anarchy could not be tolerated.
So TSO was saddled with an additional layer of control not required for batch.
The same program that could run unfettered in batch needed additional
dispensation to run under TSO. It's not that you could do mischief under TSO
that you could not do in batch. It's that you could do it unaided and
unobserved.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
[email protected]
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Seymour J Metz
Sent: Monday, November 18, 2019 11:59 AM
To: [email protected]
Subject: (External):Re: AUTHPGM in IKJTSOxx
TSO normally runs authorized and attaches commands as unauthorized. It's true
that the TMP was originally unauthorized, but that was long ago in a galaxy far
away.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of
Steve Smith <[email protected]>
Sent: Friday, November 15, 2019 6:05 PM
To: [email protected]
Subject: Re: AUTHPGM in IKJTSOxx
Well, it's been two hours, and no expert has come forth, so I'll take a shot.
As TSO normally runs non-authorized, attempting to execute an authorized
program would normally fail. TSO can run authorized commands & programs, but
it has to do considerable setup for them, to maintain integrity, and actually
invoke them in an APF-authorized environment. So the parms are how it knows
what it needs to do that for.
There's also the mixed environment of TSO, and authorized programs might need
to take extra care to avoid integrity issues that don't apply when running in
its own address space. So the AUTH* parms control what programs are
(hopefully) known to be safe there.
Side note: for this purpose, and most, by TSO I mean the IBM-supplied TMP.
You can logon with any proc that executes anything (subject to different
controls). In that case none of this applies.
As implied above, I am not an expert on this, so it may not be complete or
completely accurate.
sas
On Fri, Nov 15, 2019 at 2:48 PM Paul Gilmartin <
[email protected]> wrote:
> On Wed, 13 Nov 2019 08:55:39 -0600, Jeffrey Holst wrote:
>
> >Does AUTHPGM require that the specified program have a non-zero AC or
> that it be in an APF authorized library?
> >
> >I ask because it appears that a very clever user may have written a
> program whose name matches a program in the AUTHPGM list. The program
> executes a macro instruction that requires APF authorization. It
> appears that he was able to successfully call it from TSO.
> >
> What does AUTHPGM protect, or rather what security hazard does the
> absence of a program from the AUTHPGM list specifically prevent? Can
> an expert outline a scenario?
>
> -- gil
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to [email protected] with the message: INFO IBM-MAIN
>
--
sas
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
