Mainframe hacking

87 views
Skip to first unread message

P S

unread,
Jul 19, 2009, 5:49:59 PM7/19/09
to
Does anyone here recall any published news articles or incidents
involving mainframe hacking (any flavor of VM, VSE or MVS)?� Do you
personally know of any incidents?

Or have any such been kept on the QT?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

John P. Baker

unread,
Jul 19, 2009, 5:52:41 PM7/19/09
to
John P. Baker

P S

unread,
Jul 19, 2009, 5:53:14 PM7/19/09
to
You don't say? :-)

John P. Baker

unread,
Jul 19, 2009, 5:53:54 PM7/19/09
to
To my knowledge, there has never been a documented case of an external user
compromising a mainframe system "without inside assistance".

John P. Baker

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of P S
Sent: Sunday, July 19, 2009 5:47 PM
To: IBM-...@bama.ua.edu
Subject: Mainframe hacking

John P. Baker

unread,
Jul 19, 2009, 5:55:09 PM7/19/09
to
Key bounce... Must have been a gremlin... <VBG>

John P. Baker

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of P S
Sent: Sunday, July 19, 2009 5:53 PM
To: IBM-...@bama.ua.edu
Subject: Re: Mainframe hacking

You don't say? :-)

----------------------------------------------------------------------

Mary Anne Matyaz

unread,
Jul 19, 2009, 10:08:39 PM7/19/09
to
I had one once, circa 1992-1993. It was at a university, which at the time
were notoriously open, at least as far as TCPIP and a firewall. Someone got
the uss screen, was able to get into the production CICS, and the CECI
command was not protected, so they were able to shut the CICS down. The hack
came from Brazil somewhere. Bank of Brazil maybe?

Mary Anne

Gainsford, Allen

unread,
Jul 19, 2009, 10:53:10 PM7/19/09
to
> Does anyone here recall any published news articles or incidents
> involving mainframe hacking (any flavor of VM, VSE or MVS)?� Do you
> personally know of any incidents?
>
> Or have any such been kept on the QT?

Anyone who's read "The Adolescence of P-1" by Thomas Ryan will know
exactly how to do it. :)

P S

unread,
Jul 19, 2009, 11:16:23 PM7/19/09
to
On Sun, Jul 19, 2009 at 10:51 PM, Gainsford,
Allen<allen.g...@eds.com> wrote:
> Anyone who's read "The Adolescence of P-1" by Thomas Ryan will know
> exactly how to do it. �:)

Ouch. Besides the technical inaccuracies, that book was irritating
because for no apparent reason it misplaced University of Waterloo,
putting it near the wrong highway. "When Harlie Was One" is a better
example of the sub-genre, along with "The Moon Is A Harsh Mistress",
of course.

Howard Rifkind

unread,
Jul 20, 2009, 8:36:52 AM7/20/09
to
Interesting, I didn't think that back in '93 MVS 4.3 had a USS piece.

Or was it OS390 R1 or something like that.

--- On Sun, 7/19/09, Mary Anne Matyaz <maryan...@GMAIL.COM> wrote:

Horne, Jim - James S

unread,
Jul 20, 2009, 8:39:52 AM7/20/09
to
I don't think MVS 4.3 did but v5 did = MVS/OpenEdition I think it was called. I remember an IBMer friend of mine telling me that, yes, there was Unix in that release, but it wouldn't last. Oh well...

Jim Horne
Systems Programmer
Large Systems Engineering & Messaging NC4IT
Lowe's Companies, Inc.
1000 Lowe's Boulevard
Mooresville, NC
704-758-5354
Jim....@Lowes.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Howard Rifkind
Sent: Monday, July 20, 2009 8:36 AM
To: IBM-...@bama.ua.edu
Subject: Re: Mainframe hacking

NOTICE:
All information in and attached to the e-mail(s) below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone
(704-758-1000) or by e-mail and destroy all copies of this message (electronic, paper, or otherwise). Thank you.

Bruno Sugliani

unread,
Jul 20, 2009, 8:53:12 AM7/20/09
to
On Mon, 20 Jul 2009 08:39:22 -0400, Horne, Jim - James S
<Jim.S...@LOWES.COM> wrote:

>I don't think MVS 4.3 did but v5 did = MVS/OpenEdition I think it was
called. I remember an IBMer friend of mine telling me that, yes, there was
Unix in that release, but it wouldn't last. Oh well...

No it is correct the first version of OE was in 4.30
But sockets came in 5.10
It was my first time in Poughkeepsie :D

Bruno Sugliani
zxnetconsult(at)free(dot)fr
http://zxnetconsult.free.fr

Ivan Warren

unread,
Jul 20, 2009, 9:00:37 AM7/20/09
to
Howard Rifkind wrote:
> Interesting, I didn't think that back in '93 MVS 4.3 had a USS piece.
>
>
Possibly also, this person wasn't talking about USS, but rather about
the SSCP-LU session which spews out messages coded in the USSTAB
according to what's coded in the LU macro. That makes more sense to me
as far as then being able to establish a session to a CICS instance.

--Ivan

Binyamin Dissen

unread,
Jul 20, 2009, 9:01:25 AM7/20/09
to
On Mon, 20 Jul 2009 05:36:28 -0700 Howard Rifkind <ibm_...@YAHOO.COM> wrote:

:>Interesting, I didn't think that back in '93 MVS 4.3 had a USS piece.

Same acronym, different meaning.

Unformatted System Service (or something like that).

:>Or was it OS390 R1 or something like that.


:>
:>--- On Sun, 7/19/09, Mary Anne Matyaz <maryan...@GMAIL.COM> wrote:
:>
:>> From: Mary Anne Matyaz <maryan...@GMAIL.COM>
:>> Subject: Re: Mainframe hacking
:>> To: IBM-...@bama.ua.edu
:>> Date: Sunday, July 19, 2009, 10:07 PM
:>> I had one once, circa 1992-1993. It
:>> was at a university, which at the time
:>> were notoriously open, at least as far as TCPIP and a
:>> firewall. Someone got
:>> the uss screen, was able to get into the production CICS,
:>> and the CECI
:>> command was not protected, so they were able to shut the
:>> CICS down. The hack
:>> came from Brazil somewhere. Bank of Brazil maybe?
:>>
:>> Mary Anne
:>>
:>> On Sun, Jul 19, 2009 at 5:47 PM, P S <zos...@gmail.com>
:>> wrote:
:>>
:>> > Does anyone here recall any published news articles or
:>> incidents
:>> > involving mainframe hacking (any flavor of VM, VSE or
:>> MVS)?� Do you
:>> > personally know of any incidents?
:>> >
:>> > Or have any such been kept on the QT?

--
Binyamin Dissen <bdi...@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.

Neal Eckhardt

unread,
Jul 20, 2009, 10:19:35 AM7/20/09
to
On 19 Jul 2009 20:16:23 -0700, zos...@GMAIL.COM (P S) wrote:

>with "The Moon Is A Harsh Mistress",
>of course.

I missed that book. I assume it is an old one too?

--
Neal

Elected officials should wear uniforms like
NASCAR drivers. That way it would be easier
to identify their corporate sponsors.

Ted MacNEIL

unread,
Jul 20, 2009, 10:20:32 AM7/20/09
to
>Interesting, I didn't think that back in '93 MVS 4.3 had a USS piece.

>Or was it OS390 R1 or something like that.

I thought it came out with 5, or 5.22.
-
Too busy driving to stop for gas!

howard...@cusys.edu

unread,
Jul 20, 2009, 11:37:16 AM7/20/09
to
On Mon, 20 Jul 2009 10:19:35 -0400, Neal Eckhardt
<neck...@penntraffic.nospam.com> wrote:

>>with "The Moon Is A Harsh Mistress",
>>of course.
>
> I missed that book. I assume it is an old one too?

Nah, I just read it in "Worlds of If:, the other day.. decade -
1965-1956. No way I would consider that old.

Rick Fochtman

unread,
Jul 20, 2009, 11:51:38 AM7/20/09
to
P S wrote:

My shop was never accessed by unauthorized persons, but a DOS attack
slowed us down once. The attacker was traced and successfully prosecuted.

Tony B.

unread,
Jul 20, 2009, 12:03:36 PM7/20/09
to
Do you recall the details of the DOS ?

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf
Of Rick Fochtman
Sent: Monday, July 20, 2009 10:47 AM
To: IBM-...@bama.ua.edu
Subject: Re: Mainframe hacking

P S wrote:

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.392 / Virus Database: 270.13.20/2248 - Release Date: 07/20/09
06:16:00

David Cole

unread,
Jul 20, 2009, 1:45:21 PM7/20/09
to
>>Does anyone here recall any published news articles or incidents
>>involving mainframe hacking (any flavor of VM, VSE or MVS)? Do you
>>personally know of any incidents?
>>
>>Or have any such been kept on the QT?


A couple of years ago, there was a thread called "Back doors". I
posted something there about the vulnerability of z/OS to hacking.
Here's the link:

http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&X=2F4EDA1D0DDA5823A7-&Y=dbcole%40colesoft.com

(The resulting silence was deafening.)

Dave Cole REPLY TO: dbc...@colesoft.com
ColeSoft Partners WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: 540-456-6658

Steve Comstock

unread,
Jul 20, 2009, 2:05:22 PM7/20/09
to
David Cole wrote:
>>> Does anyone here recall any published news articles or incidents
>>> involving mainframe hacking (any flavor of VM, VSE or MVS)? Do you
>>> personally know of any incidents?
>>>
>>> Or have any such been kept on the QT?
>
>
> A couple of years ago, there was a thread called "Back doors". I posted
> something there about the vulnerability of z/OS to hacking. Here's the
> link:
>
> http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&X=2F4EDA1D0DDA5823A7-&Y=dbcole%40colesoft.com
>
>
> (The resulting silence was deafening.)
>
>
>
> Dave Cole REPLY TO: dbc...@colesoft.com
> ColeSoft Partners WEB PAGE: http://www.colesoft.com
> 736 Fox Hollow Road VOICE: 540-456-8536
> Afton, VA 22920 FAX: 540-456-6658

Dave,

It sounds really interesting. But the link takes me to a page
where it is asking me to login and it has pre-filled in your
email address. Just a heads up.

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques

==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==

Farley, Peter x23353

unread,
Jul 20, 2009, 2:35:10 PM7/20/09
to
Steve,

That's the standard IBM-MAIN Archives login page, just substitute your
own email address and password instead of Dave's. That's how I got to
it.

HTH

Peter

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
> Behalf Of Steve Comstock
> Sent: Monday, July 20, 2009 2:04 PM
> To: IBM-...@bama.ua.edu

> Subject: Re: Mainframe hacking (getting back on topic)
>
> David Cole wrote:
<Snipped>


> Dave,
>
> It sounds really interesting. But the link takes me to a page
> where it is asking me to login and it has pre-filled in your
> email address. Just a heads up.
>
> Kind regards,
>
> -Steve Comstock

This message and any attachments are intended only for the use of the addressee and
may contain information that is privileged and confidential. If the reader of the
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.

Steve Comstock

unread,
Jul 20, 2009, 2:43:34 PM7/20/09
to
Farley, Peter x23353 wrote:
> Steve,
>
> That's the standard IBM-MAIN Archives login page, just substitute your
> own email address and password instead of Dave's. That's how I got to
> it.
>
> HTH
>
> Peter

Yeah, I got there. Turns out my password had expired so
I had to request a new one. All's fine now.

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques

==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==

----------------------------------------------------------------------

David Cole

unread,
Jul 20, 2009, 2:45:14 PM7/20/09
to
Steve,

Yeah, that link goes to IBM-MAIN's archives, and you need a your
email address (which IBM-MAIN already has) and a password to access
that post and the thread in which it lives.

I've made a copy of my post at my own website. Here's that link:
http://www.dbcole.com/misc/rebackdoors.html

Dave Cole

At 7/20/2009 02:03 PM, Steve Comstock wrote:
>Dave,
>
>It sounds really interesting. But the link takes me to a page where
>it is asking me to login and it has pre-filled in your email
>address. Just a heads up.
>
>Kind regards,
>
>-Steve Comstock
>The Trainer's Friend, Inc.
>
>
>
>David Cole wrote:
>>>Does anyone here recall any published news articles or incidents
>>>involving mainframe hacking (any flavor of VM, VSE or MVS)? Do
>>>you personally know of any incidents?
>>>
>>>Or have any such been kept on the QT?
>>
>>A couple of years ago, there was a thread called "Back doors". I
>>posted something there about the vulnerability of z/OS to hacking.
>>Here's the link:
>>http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-MAIN&P=R63457&X=2F4EDA1D0DDA5823A7-&Y=dbcole%40colesoft.com
>>
>>
>>(The resulting silence was deafening.)
>
>Dave Cole REPLY TO: dbc...@colesoft.com
>ColeSoft Partners WEB PAGE: http://www.colesoft.com
>736 Fox Hollow Road VOICE: 540-456-8536
>Afton, VA 22920 FAX: 540-456-6658

----------------------------------------------------------------------

Patrick O'Keefe

unread,
Jul 20, 2009, 4:49:37 PM7/20/09
to
On Mon, 20 Jul 2009 14:43:32 -0400, David Cole
<dbc...@COLESOFT.COM> wrote:

>...


>>>A couple of years ago, there was a thread called "Back doors". I
>>>posted something there about the vulnerability of z/OS to hacking.
>>>Here's the link:
>>>http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0608&L=IBM-
MAIN&P=R63457&X=2F4EDA1D0DDA5823A7-&Y=dbcole%
40colesoft.com
>>>
>>>
>>>(The resulting silence was deafening.)

>>...

Maybe the result was silence that time but the general topic has
been discussed a number of time in a number of venues. I think
you were saying that you have the keys to the realm if you are an
authorized program and IBM requires authorization for far too
many services, so it is far too easy to stick back-door code in a
program that "needs" to be authorized.

That certainly is a hole in mainframe security, but I don't think of
that as a "hacking" issue. (I'm going to assume the "hacking"
in the original posting was meant to imply a breaching of MVS
security by outsiders where "outsiders" could be either outside
the company or outside the group of legitimate users - a meaning
real hackers would find very offensive.)

Writing a back door is "an inside job". It could be an interesting
hack, but I don't think that's what the OP meant.

MVS security (when used) does a good job of keeping outsiders out,
but no system on any operating system is safe from those that are
given the authority to bypass the security.

Pat O'Keefe

I think "hacking" around or through MVS security is very rare.

Charles T. Lester

unread,
Jul 20, 2009, 11:43:41 PM7/20/09
to
Classic Robert A. Heinlein, an Annapolis graduate

> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Howard Brazee
> Sent: Monday, July 20, 2009 11:37 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: Mainframe hacking
>

Sebastian Welton

unread,
Jul 21, 2009, 3:57:39 AM7/21/09
to
There is an article on the 2600 archives (and replicated elsewhere) on how
to break into VM/370 systems but really requires you to know the maint
password. I have (bows head in shame) 'hacked' into a system. This was open
to the internet and was running an ADCD system and they had not changed the
default passwords, including ibmuser. All I did was take a look around and
then log out but, for me, that was a very large hole in their security (was
not a commercial company but still....)

Seb

Mary Anne Matyaz

unread,
Jul 21, 2009, 5:25:31 AM7/21/09
to
Sorry, yes, I meant the VTAM screen. I refer to it as the USS screen, from
USSTAB.
MA

David Cole

unread,
Jul 21, 2009, 7:18:10 AM7/21/09
to
At 7/20/2009 04:49 PM, Patrick O'Keefe wrote:
>I think you were saying that you have the keys to the realm if you
>are an authorized program and IBM requires authorization for far too
>many services, so it is far too easy to stick back-door code in a
>program that "needs" to be authorized.

Basically, yes.


>That certainly is a hole in mainframe security, but I don't think of
>that as a "hacking" issue. (I'm going to assume the "hacking" in
>the original posting was meant to imply a breaching of MVS security
>by outsiders where "outsiders" could be either outside the company
>or outside the group of legitimate users - a meaning real hackers
>would find very offensive.)

My issue is mainframe security and what seems to me to be a rather
complacent and unfounded attitude that MVS security is bulletproof.
It is not bulletproof for the reasons that I discussed in my prior post.

To divide the issue by the distinction of "insider" vs. "outsider"
obscures the threat.

First of all, WRT an inside threat, I grant that a person posing such
a threat would first have to get past many (well, hopefully many)
other security barriers before being able to exploit the authorized
libraries vulnerability. But I don't think that therefore one should
be unconcerned about the vulnerability.

WRT an "outside" threat, I am willing to accept (and I acknowledged
this in my prior post) that the z/OS's defense against non-APF
authorized threats is "bulletproof". But then to just leave the issue
there is, I think, complacent.

The presumption seems to be that no "outsider" would have the ability
to put a program into APF authorized libraries. Well, what about 3rd
party vendors? We certainly provide the motivation to induce
"insiders" to place our programs into authorized libraries. But what
are we? "Insiders"? "Outsiders"?

(As mentioned in my prior post, one technical way to partially
address this exposure would be for IBM to reduce the number of
reasons requiring a program to run authorized.)


>That certainly is a hole in mainframe security, but I don't think of
>that as a "hacking" issue.

I dunno. Wouldn't "Trojan Horse" fall into the category of "hacking"?


>I think "hacking" around or through MVS security is very rare.

I certainly hope so... But by no means would I consider myself
qualified to make that assertion.


FWIW, this sort of vulnerability is by no means limited to
mainframes. The PC world is plagued by this problem. In other words,
the model is out there. If "Western Civilization Runs on the
Mainframe", then it's only a matter of time before someone will find
that it's worth the effort to write a "gotta have" Trojan Horse.

Dave Cole REPLY TO: dbc...@colesoft.com
ColeSoft Partners WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: 540-456-6658

At 7/20/2009 04:49 PM, Patrick O'Keefe wrote:

>Maybe the result was silence that time but the general topic has
>been discussed a number of time in a number of venues. I think you
>were saying that you have the keys to the realm if you are an
>authorized program and IBM requires authorization for far too many
>services, so it is far too easy to stick back-door code in a program
>that "needs" to be authorized.
>
>That certainly is a hole in mainframe security, but I don't think of
>that as a "hacking" issue. (I'm going to assume the "hacking" in
>the original posting was meant to imply a breaching of MVS security
>by outsiders where "outsiders" could be either outside the company
>or outside the group of legitimate users - a meaning real hackers
>would find very offensive.)
>
>Writing a back door is "an inside job". It could be an interesting
>hack, but I don't think that's what the OP meant.
>
>MVS security (when used) does a good job of keeping outsiders out,
>but no system on any operating system is safe from those that are
>given the authority to bypass the security.
>
>Pat O'Keefe
>
>I think "hacking" around or through MVS security is very rare.

----------------------------------------------------------------------

Paul Gilmartin

unread,
Jul 21, 2009, 9:41:00 AM7/21/09
to
On Tue, 21 Jul 2009 07:14:13 -0400, David Cole wrote:
>
>The presumption seems to be that no "outsider" would have the ability
>to put a program into APF authorized libraries. Well, what about 3rd
>party vendors? We certainly provide the motivation to induce
>"insiders" to place our programs into authorized libraries. But what
>are we? "Insiders"? "Outsiders"?
>
>(As mentioned in my prior post, one technical way to partially
>address this exposure would be for IBM to reduce the number of
>reasons requiring a program to run authorized.)
>
What are the principal offenders? From an applications viewpoint,
I see (the facilities provided by) IEBCOPY, IDCAMS, TRANSMIT/RECEIVE.
(Others?) I find it bizarre that in a non-APF authorized state I
can't manipulate data or rename data sets for which I have all
otherwise necessary RACF authority.

What relief would be possible?

o Could IEBCOPY be enhanced to operate without APF authorization?
What performance degradation would this involve?

o BPX1EXM appeared tantalizing when it first appeared. But it
suffers the defect of not supporting useful DDNAME allocation.
Would an APF-authorized wrapper invoked via BPX1EXM, allocating
data sets specified by the TSOALLOC environment variable as
used by the US^H^H OMVS command, then calling a target
authorized utility be secure and useful?

o The new-fangled (z/OS 1.4) Unix Rexx "address TSO" subcommand
environment is a great help in some cases: it runs the TMP in
a separate, presumably secure, address space. Alas, it's available
only when Rexx is spawned from a shell. Would it be possible to
access this environment with a suitable API call to the Rexx
interpreter?

-- gil

Walt Farrell

unread,
Jul 21, 2009, 9:46:12 AM7/21/09
to
On Tue, 21 Jul 2009 07:14:13 -0400, David Cole <dbc...@COLESOFT.COM> wrote:
>(As mentioned in my prior post, one technical way to partially
>address this exposure would be for IBM to reduce the number of
>reasons requiring a program to run authorized.)

And if there we had a simple way of doing that, we would. Unfortunately,
our analysis to date shows that
(a) no simple method of accomplishing it exists, especially one that covers
enough functions to allow vendors to eliminate their need for full APF in
most of the vendor code; and

(b) that the complex methods are complex both for z/OS to implement, and for
the IBM and vendor products to exploit; and

(c) that the complex methods are also very complex for the customer to
administer.

The functions that require APF do so because, simply, they allow someone to
take over the system. Directly, for some of the functions, and indirectly
for many others if you're clever enough.

Re-architecting the system functions to eliminate the possibility of taking
over the system, or allowing granular control in a way that does not involve
massive rewriting of both the system and the vendor applications, and that
does not involve massive administrative efforts for our customers, would be
a big job.

--
Walt Farrell, CISSP
IBM STSM, z/OS Security Design

John Eells

unread,
Jul 21, 2009, 9:57:19 AM7/21/09
to
David Cole wrote:

> My issue is mainframe security and what seems to me to be a rather
> complacent and unfounded attitude that MVS security is bulletproof. It
> is not bulletproof for the reasons that I discussed in my prior post.

<snip>

We prefer the phrase "bullet resistant." ;-) (Sorry, I couldn't resist.)

Several years ago, I visited a state-run data center in the USA's
tornado belt. They had searched high and low for a building design that
was "tornado proof" but nobody would certify that. They had to settle
for a building that was "missile proof." The "missile" in this case was
a utility pole hitting end-on at 200mph. I have no idea whether a
tornado ever hit that building, but I do know there are few other
buildings I would rather be inside. (Well, Cheyenne Mountain would
probably be OK, if you call that a building. ;-)

What we said in the z/OS R9 GA announcement was:

"Specifically, z/OS "System Integrity" is defined as the inability of
any program not authorized by a mechanism under the installation's
control to circumvent or disable store or fetch protection, access a
resource protected by the z/OS Security Server (RACF�), or obtain
control in an authorized state; that is, in supervisor state, with a
protection key less than 8, or Authorized Program Facility (APF)
authorized. In the event that an IBM System Integrity problem is
reported, IBM will always take action to resolve it."

Tornado proof? Probably not. Good enough? Up to you, but who else
offers more than that? (I do know of some other vendors whose code runs
on z/OS who have made similar statements.)

To me, it seems that this statement does not address authorized code or
authorized users for the same reason the manufacturers' warranties on
new cars do not include the consequences of driver error or abuse.

But, what do I know? I'm not exactly a security expert.

--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

Shane

unread,
Jul 21, 2009, 10:09:27 AM7/21/09
to
On Tue, 2009-07-21 at 09:55 -0400, John Eells wrote:

> "Specifically, z/OS "System Integrity" is defined as the inability of
> any program not authorized by a mechanism under the installation's

> control ...

This is the bit I have trouble with.
Just about every product demands an auth'd library for install. Given
that the product has been purchased and is presumably required, how's
that "under the installation's control" ?.

As Dave says, this blows the whole idea of security to hell (sorry Dave,
my emphasis ... ;-)

Shane ...

Anne & Lynn Wheeler

unread,
Jul 21, 2009, 10:48:42 AM7/21/09
to
seba...@WELTON.DE (Sebastian Welton) writes:
> There is an article on the 2600 archives (and replicated elsewhere) on how
> to break into VM/370 systems but really requires you to know the maint
> password. I have (bows head in shame) 'hacked' into a system. This was open
> to the internet and was running an ADCD system and they had not changed the
> default passwords, including ibmuser. All I did was take a look around and
> then log out but, for me, that was a very large hole in their security (was
> not a commercial company but still....)

recent post mentioning once taking the bait and demonstrating an
exploit/penetration ... they had supposedly added huge amount of
security features to an internal system to protect highly
classified corporate documents ... and then claimed even if
i was in the machine room, i would be able to get access
http://www.garlic.com/~lynn/2009k.html#5

--
40+yrs virtualization experience (since Jan68), online at home since Mar1970

Anne & Lynn Wheeler

unread,
Jul 21, 2009, 10:52:22 AM7/21/09
to
seba...@WELTON.DE (Sebastian Welton) writes:
> There is an article on the 2600 archives (and replicated elsewhere) on how
> to break into VM/370 systems but really requires you to know the maint
> password. I have (bows head in shame) 'hacked' into a system. This was open
> to the internet and was running an ADCD system and they had not changed the
> default passwords, including ibmuser. All I did was take a look around and
> then log out but, for me, that was a very large hole in their security (was
> not a commercial company but still....)

recent post mentioning once taking the bait and demonstrating an


exploit/penetration ... they had supposedly added huge amount of
security features to an internal system to protect highly
classified corporate documents ... and then claimed even if
i was in the machine room, i would be able to get access
http://www.garlic.com/~lynn/2009k.html#5

--
40+yrs virtualization experience (since Jan68), online at home since Mar1970

----------------------------------------------------------------------

Barry Merrill

unread,
Jul 21, 2009, 11:12:56 AM7/21/09
to
At the Chicago SHARE 43 meeting in August, 1974, IBM had invited
attendees to a demonstration of the new MVS operating system on the 145
at the Chicago Ed center. At 8 p.m. Tuesday, three attendees found the
IBM demonstrator on duty was enthralling an attractive lady with his
expertise. Not wanting to be interrupted by three males, he said, "Go
play with the system on that user TSO terminal over there -- you can
find out how good the security of an MVS system is for a typical TSO
user". The challenge was accepted, and in short order, "Tim W." observed
that SYS1.NUCLEUS was not protected, so he scratched it. "Tim W." knew
that once the system is up, the dataset SYS1.NUCLEUS is not read again,
so the SHARE demonstration continued without a flaw. It was later heard
that IBM took the SHARE MVS demonstration down at 11 p.m. to IPL for a
customer benchmark; it took until 3 a.m. for IBM to find a CE who could
correctly decipher the wait state code and explain that the IPLs kept
failing because there was no SYS1.NUCLEUS on the IPL volume.

Barry Merrill

Chris Craddock

unread,
Jul 21, 2009, 11:17:10 AM7/21/09
to
On Tue, Jul 21, 2009 at 9:07 AM, Shane <ibm-...@tpg.com.au> wrote:

> On Tue, 2009-07-21 at 09:55 -0400, John Eells wrote:
>
> > "Specifically, z/OS "System Integrity" is defined as the inability of
> > any program not authorized by a mechanism under the installation's
> > control ...
>
> This is the bit I have trouble with.
> Just about every product demands an auth'd library for install. Given
> that the product has been purchased and is presumably required, how's
> that "under the installation's control" ?.
>
> As Dave says, this blows the whole idea of security to hell (sorry Dave,
> my emphasis ... ;-)


It is under the installation's control because the installation chooses what
resources to secure and how to secure them. Security and integrity depends
on the whole chain of control. Break one link and you lose control
altogether which is why some of us bang on endlessly about software
integrity. What's amazing to me is that as near as I have been able to tell,
barely anyone (neither vendors, nor customers) actually gives a damn about
the software integrity part - which is by far the most important part -
assuming of course that the installation doesn't allow the unwashed masses
to update system datasets or APF libraries.

All of the hand wringing that goes on over vendor use of authorized
libraries is just so much uninformed hot air, PROVIDED that the installation
maintains the security of those libraries. A product having an authorized
library is literally no big deal and with z/OS design as it stands today
there just isn't any other way to get most things done. It has been this way
since the flood and it is highly unlikely it will ever change. There is of
course a presumption that the product itself does not violate integrity
which is unfortunately rarely a valid assumption. But again, nobody actually
seems to give a damn, so we continue to live in glass houses. Kinda funny
really.

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

Bruce Richardson

unread,
Jul 21, 2009, 12:06:20 PM7/21/09
to
Getting back on target ....
Doesn't anyone remember the Christmas Tree viral worm?
As I recall, it was an e-mail with an attachment; the reader
was instructed to save the attachment as a EXEC, and run
it to see the Christmas greeting. While the greeting was displayed,
the EXEC harvested the address book (in PROFS, and/or NAMES file)
and resent the original e-mail to anyone it could find. In short order,
systems were crashing due to full SPOOL, and the networks
ground to a halt, shipping this note back and forth.
I believe the programmer did some hard time.
I don't remember what year it was, but is was when PROFS
was big.

Chris Mason

unread,
Jul 21, 2009, 12:20:17 PM7/21/09
to
Ivan

> Possibly also, this person wasn't talking about USS ...

Quite on the contrary, this person, Mary Anne Matyaz, to give "this person" a
name, was talking very precisely about USS, USS (Unformatted System
Services) being the VTAM function which supplies the session establishment
data mapping and information messages to be used on the ...

> ... but rather about the SSCP-LU session ...

... SSCP-LU session which you correctly identify as being the relevant SNA
architectural element.

> ... which spews out messages ...

However the messages are hardly "spewed" but sent out singly as befits the
intelligibility of the incoming command text with the exception of the initial
message 10, the one certainly referred to as the "USS screen" here, which
appears on activation.

> ... coded in the USSTAB ...

Indeed it is the USSTAB operand which supplies the name of the USS table
which contains the installation's specification for the USS function, replacing
the default USS table which does not include an USS message 10, and valid
wherever the associated SSCPFM operand specifies a value other than FSS
for "formatted system services" which require no installation-specific table.

... according to what's coded in the LU macro.

A couple more corrections are due here. Probably because it inherited a
development culture which included QTAM and TCAM, NCP was one of those
products which required to be generated from assembler macro statements -
also just like operating systems at the time and IMS, CICS and so on. VTAM
was actually a product which did not rely on assembler macro statements -
one of the first? - but, because it wanted to incorporate the NCP source as
one of the VTAMLST members (major nodes) it felt obliged, for the sake of
consistency, to ensure that all other VTAMLST members had the syntax of
assembler macros. Other than in the NCP major node, VTAM statements were
*never* macros.

Then along came the NDF program as a way of generating NCPs and now not
even the NCP statements could correctly be described as macros.

Thus, while it is possible that, prior to the early 80's, an USSTAB operand
could be specified on an "LU macro" as long as it was defined within an NCP, it
has been and is impossible since.

Also it is quite possible that the "USS screen" to which Mary Anne refers could
have been presented on a device which maps somehow to a VTAM LOCAL
statement which also can take the USSTAB operand so it doesn't have to
have been even an LU statement.

> That makes more sense to me as far as then being able to establish a
session to a CICS instance.

The interpretation Howard, Jim and Bruno arrived at is, of course, total
nonsense, caused solely because this persistent misuse of an abbreviation for
UNIX System Services. So much so that USS can even be denied its proper
interpretation!!!

Chris Mason

On Mon, 20 Jul 2009 14:59:44 +0200, Ivan Warren <iv...@VMFACILITY.FR>
wrote:

>Howard Rifkind wrote:
>> Interesting, I didn't think that back in '93 MVS 4.3 had a USS piece.
>>
>>

>Possibly also, this person wasn't talking about USS, but rather about
>the SSCP-LU session which spews out messages coded in the USSTAB
>according to what's coded in the LU macro. That makes more sense to me
>as far as then being able to establish a session to a CICS instance.
>
>--Ivan

Hal Merritt

unread,
Jul 21, 2009, 12:21:02 PM7/21/09
to
Google results show the Christmas Tree viral worm was in 1987 and affected PROFS running on VM/370.

Not clear how this is relevant in a MVS/zos context.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Bruce Richardson
Sent: Tuesday, July 21, 2009 11:06 AM
To: IBM-...@bama.ua.edu
Subject: Re: Mainframe hacking

NOTICE: This electronic mail message and any files transmitted with it are intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.

Chris Mason

unread,
Jul 21, 2009, 12:39:10 PM7/21/09
to
Mary Anne

> Sorry, yes, I meant the VTAM screen. I refer to it as the USS screen, from
USSTAB.

No apology is needed at all. Rather a considerable apology is due from all
those who have so misused USS as so to mislead Howard Rifkind, Jim Horne
and Bruno Sugliani. You and a great many people refer to what you meant
with perfect accuracy as an "USS screen". More specifically the 3270 device
or emulator screen presents the USS message 10 at the time the
corresponding LU is activated. Unformatted System Services (USS) - as
opposed to Formatted System Services (FSS) - has been a feature of VTAM
since before it was a program product, in other words in the mid 70's - long
before UNIX System Services - and the names by which its predecessors were
known - was a twinkle in the eyes of its begetters. Because of Howard's
misunderstanding, we have been reminded that the birth of "UNIX in MVS" was
well over a decade later in the early 90's. If this were subject to some sort of
legal process, the plagiarists would be paying hefty damages by now.

To be completely honest, I have to confess that specifically USS message 10
was *not* one of the suite of original USS messages and I cannot now
remember which release/version/flavour of VTAM introduced USS message 10.
It may have been as late as the early 80's but would still have predated the
pretender by a decade.

I am grateful to you for pointing out however inadvertently what a snare the
misuse of USS is. The widespread wanton use of USS when UNIX System
Services is meant trapped 3 contributors before 2 contributors spotted the
problem - even if one made a gross error in so doing!

I see some joker insists that USS means United States Ship. This is of course
nonsense when the context usually assumed for the IBM-MAIN list is z/OS -
and hoping that another joker will not be jumping in to insist that any zSeries
operating system is appropriate (which was the point of my "usually") - even if
some tangents can take us very far from the original subject!

Chris Mason

On Tue, 21 Jul 2009 05:23:07 -0400, Mary Anne Matyaz
<maryan...@GMAIL.COM> wrote:

>Sorry, yes, I meant the VTAM screen. I refer to it as the USS screen, from
>USSTAB.
>MA
>
>On Mon, Jul 20, 2009 at 8:36 AM, Howard Rifkind <ibm_...@yahoo.com>

wrote:
>
>> Interesting, I didn't think that back in '93 MVS 4.3 had a USS piece.
>>

----------------------------------------------------------------------

Eric Bielefeld

unread,
Jul 21, 2009, 12:53:41 PM7/21/09
to
I'm just curious. Has anyone worked for a company whose datacenter was
struck by a tornado? Was the datacenter damaged or destroyed? Especially,
what if the building was a really tall building? I don't recall ever
hearing that. I know in Milwaukee, we occasionally have tornados. Back in
the 60's, my wife's family farm near Platteville had a lot of damage due to
a tornado. Her dad just watched from the living room. Luckily, it didn't
hit the house but only a barn and silo.

Eric Bielefeld
Sr. Systems Programmer
Milwaukee, Wisconsin
414-475-7434


----- Original Message -----
From: "John Eells" <ee...@US.IBM.COM>
>
> Several years ago, I visited a state-run data center in the USA's tornado
> belt. They had searched high and low for a building design that was
> "tornado proof" but nobody would certify that. They had to settle for a
> building that was "missile proof." The "missile" in this case was a
> utility pole hitting end-on at 200mph. I have no idea whether a tornado
> ever hit that building, but I do know there are few other buildings I
> would rather be inside. (Well, Cheyenne Mountain would probably be OK, if
> you call that a building. ;-)

> > John Eells

Mark Jacobs

unread,
Jul 21, 2009, 1:00:31 PM7/21/09
to

When I worked in NYC my office was right next to the NY Federal Reserve
building. One time when they were doing repairs on the outside wall I
saw that it was about 3-5 feet thick, solid stone.

--
Mark Jacobs
Time Customer Service
Tampa, FL
----

You can have any kind of a home you want. You can even
get stucco. Oh, how you can get stucco.

Groucho Marx - The Cocoanuts (1929)

Mary Anne Matyaz

unread,
Jul 21, 2009, 1:09:18 PM7/21/09
to
The first time I had to deal with it was OS/390 2.5, and it was called
OpenEdition, or OE, at
the time.
Funny, when I read Howards note, Unix System Services never occurred to me.
I was still thinking Unformatted Systems Services...I was puzzled.
When I see something like that, that looks completely and obviously wrong to
me, I usually try to stop and determine if there's another way of looking at
it, or explaining it, or I try to figure out what I missed. This time I
guess I didnt' do that. :)

Lets blame it on IBM and all their name changes, shall we? :)

MA

Hal Merritt

unread,
Jul 21, 2009, 1:30:14 PM7/21/09
to
Well, does a hurricane count? Generally, the category of a hurricane just about matches the F number for a tornado (a category three hurricane is about the same wind speed and destructive force as a F-3 tornado). In addition, tornados often accompany hurricanes, but there is so much going on that they are hard to spot and it is hard to attribute specific damage to a tornado.

The datacenter was on the top floor of a 7 story building. The roof failed and the top floor was flooded. All of the equipment was powered off and wrapped in plastic about an hour before the roof failed. Had the equipment not been wrapped, we would have surely been classified as 'destroyed'. We were down for a couple of weeks as we mucked out the under floor and dried everything out.

This was Hurricane Alicia in 1983 (long before DR was popular). We had plastic handy simply because the roof had a history of leakage.

Hurricane Ike last year did very little structural damage but the power was out for weeks. That challenge was getting deliveries of fuel for the generator. The suppliers had no power to pump fuel or were under water, the drivers that did not evacuate had no fuel to drive to work, etc etc.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Eric Bielefeld
Sent: Tuesday, July 21, 2009 11:52 AM
To: IBM-...@bama.ua.edu

NOTICE: This electronic mail message and any files transmitted with it are intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.

----------------------------------------------------------------------

Tony Harminc

unread,
Jul 21, 2009, 1:54:54 PM7/21/09
to
2009/7/21 Hal Merritt <HMer...@jackhenry.com>:

> Google results show the Christmas Tree viral worm was in 1987 and affected PROFS running on VM/370.

December 10, 1987. PROFS had nothing to do with it except to the
extent that PROFS had turned many new and non-technical people into VM
users.

http://vm.marist.edu/~vmshare/browse?fn=CHRISTMA&ft=PROB

But really, while this was certainly malware, I'm not sure I'd call it
"hacking", even in the bad sense of the word. It relied on
unsophisticated (or in those days, simply unsuspicious) end users to
run a program; there was no advantage taken of any hole in CMS, CP or
PROFS. So maybe social engineering, like today's phishing attacks.

> Not clear how this is relevant in a MVS/zos context.

Why does it have to be related to MVS/zOS? The question was "Does


anyone here recall any published news articles or incidents involving
mainframe hacking (any flavor of VM, VSE or MVS)?"

Tony H.

howard...@cusys.edu

unread,
Jul 21, 2009, 2:05:55 PM7/21/09
to
On 21 Jul 2009 10:30:14 -0700, HMer...@JACKHENRY.COM (Hal Merritt)
wrote:

>Well, does a hurricane count?

Really, the solution isn't to hurricane-proof, tornado-proof,
flood-proof, fire-proof, bomb-proof, airplane-proof a data center.

That money would be better spent in creating a backup data center at
such a distance that the same problem won't bring it down.

Schwarz, Barry A

unread,
Jul 21, 2009, 2:27:08 PM7/21/09
to
Unfortunately, the way some tax laws are written, hardening the facility
could be a write-off while a second data center can be a tax burden.

-----Original Message-----
From: Howard Brazee [mailto:howard...@CUSYS.EDU]
Sent: Tuesday, July 21, 2009 11:06 AM
To: IBM-...@bama.ua.edu
Subject: Re: Bulletproof (was Re: Mainframe hacking (getting back on
topic))

----------------------------------------------------------------------

Thompson, Steve

unread,
Jul 21, 2009, 2:35:20 PM7/21/09
to
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Behalf Of Chris Mason
Sent: Tuesday, July 21, 2009 11:19 AM
To: IBM-...@bama.ua.edu
Subject: Re: Mainframe hacking

<SNIPPAGE>


The interpretation Howard, Jim and Bruno arrived at is, of course, total

nonsense, caused solely because this persistent misuse of an
abbreviation for
UNIX System Services. So much so that USS can even be denied its proper
interpretation!!!

Chris Mason

<SNIPPAGE>

Unix System Services vs. VTAM and USS. Pedantic. Last laugh.
Interesting picture here.

Regards,
Steve Thompson

Mark Post

unread,
Jul 21, 2009, 2:36:11 PM7/21/09
to
>>> On 7/21/2009 at 2:24 PM, "Schwarz, Barry A" <barry.a...@BOEING.COM>
wrote:
> Unfortunately, the way some tax laws are written, hardening the facility
> could be a write-off while a second data center can be a tax burden.

Not to mention that certain types of companies are subject to government regulation that requires such types of hardening _and_ second data centers.


Mark Post

Chase, John

unread,
Jul 21, 2009, 4:11:39 PM7/21/09
to
Depends on the tornado. The one that hit OKC in May, 1999 had enough
power to suck pavement off the road. Generally, whatever was above
ground in its path simply got "blown away".

-jc-

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Behalf Of Eric Bielefeld
> Sent: Tuesday, July 21, 2009 11:52 AM
> To: IBM-...@bama.ua.edu

> Subject: Re: Bulletproof (was Re: Mainframe hacking (getting back on
topic))
>

Rick Fochtman

unread,
Jul 21, 2009, 5:45:44 PM7/21/09
to
--------------------------------<snip>--------------------------------
Do you recall the details of the DOS ?
--------------------------------<unsnip>----------------------------
Random USERID generator trying to logon to our system.

When the FBI confiscated his machine, they found 2 GB of "Kiddie porn",
so they hung him for that as well. He got 30 years.

(Certainly what I'd call "Civic Improvement")

Rick

Rick Fochtman

unread,
Jul 21, 2009, 5:48:10 PM7/21/09
to
-------------------------------<snip>-------------------------------
That's the standard IBM-MAIN Archives login page, just substitute your
own email address and password instead of Dave's. That's how I got to it.
---------------------------------<unsnip>-----------------------------
What password? I don't recall ever setting ANY password for IBM-MAIN.

Anne & Lynn Wheeler

unread,
Jul 21, 2009, 5:58:34 PM7/21/09
to
Bruce.Ri...@ARCELORMITTAL.COM (Bruce Richardson) writes:
> Getting back on target ....
> Doesn't anyone remember the Christmas Tree viral worm?
> As I recall, it was an e-mail with an attachment; the reader
> was instructed to save the attachment as a EXEC, and run
> it to see the Christmas greeting. While the greeting was displayed,
> the EXEC harvested the address book (in PROFS, and/or NAMES file)
> and resent the original e-mail to anyone it could find. In short order,
> systems were crashing due to full SPOOL, and the networks
> ground to a halt, shipping this note back and forth.
> I believe the programmer did some hard time.
> I don't remember what year it was, but is was when PROFS
> was big.

almost exactly a year before the morris worm on the internet

from a a.f.c post
http://www.garlic.com/~lynn/2007u.html#87

vmshare refernce:
http://vm.marist.edu/~vmshare/browse?fn=CHRISTMA&ft=PROB
and risk digest reference
http://catless.ncl.ac.uk/Risks/5.81.html#subj1

by comparison morris worm a year later
http://en.wikipedia.org/wiki/Morris_worm

for other topic drift ... a thread in a.f.c. & ibmconnect
http://www.garlic.com/~lynn/2009j.html#79 Timeline: The evolution of online communities
http://www.garlic.com/~lynn/2009j.html#80 Timeline: The evolution of online communities
http://www.garlic.com/~lynn/2009k.html#0 Timeline: The evolution of online communities
http://www.garlic.com/~lynn/2009k.html#6 Timeline: The evolution of online communities
http://www.garlic.com/~lynn/2009k.html#9 Timeline: The evolution of online communities
http://www.garlic.com/~lynn/2009k.html#12 Timeline: The evolution of online communities
http://www.garlic.com/~lynn/2009k.html#13 Timeline: The evolution of online communities

--
40+yrs virtualization experience (since Jan68), online at home since Mar1970

----------------------------------------------------------------------

Rick Fochtman

unread,
Jul 21, 2009, 6:02:46 PM7/21/09
to
--------------------------------<snip>--------------------------------------

The presumption seems to be that no "outsider" would have the ability to
put a program into APF authorized libraries. Well, what about 3rd party
vendors? We certainly provide the motivation to induce "insiders" to
place our programs into authorized libraries. But what are we?
"Insiders"? "Outsiders"?

(As mentioned in my prior post, one technical way to partially address

this exposure would be for IBM to reduce the number of reasons requiring
a program to run authorized.)

--------------------------------<unsnip>------------------------------------
I've always required that 3rd party vendors include penalty clauses in
their contracts, such that it their software contributes to a security
breach, then they pay penalties that are downright Draconian. Failing
that, I want to review all authorized source code, as well as any
mechanisms that communitcate to unauthorized code. I would be happy to
execute, and abide by, a non-disclosure agreement if that was required.
If the vendor won't agree to one or the other of those terms, we looked
somewhere else. I only had one vendor refuse and they blew a $200,000
deal just that quickly.

(I even got a look at some serious IBM code, but as far as I know, the
NDA is still in effect so I can't go into details.)

"You want to play in my yard, you play by my rules. Period."

Rick

Anne & Lynn Wheeler

unread,
Jul 21, 2009, 6:14:21 PM7/21/09
to
ee...@US.IBM.COM (John Eells) writes:
> We prefer the phrase "bullet resistant." ;-) (Sorry, I couldn't resist.)

misc. past posts mentioning getting to play disk enginneer in bldg.
14 & 15
http://www.garlic.com/~lynn/subtopic.html#disk

we i 1st started playing they had all these "test cells" (engineering
devices under development) ... that they had big switch which
interconnected test cells and some number of mainframes. testing was
"stand alone" with dedicated mainframe machine time scheduled. they had
tried concurrent testing in mvs environment ... but even with a single
connected "test cell", MVS mtbf was 15 minutes (crash or hang requiring
reboot).

so for the heck of it, i undertook to rewrite i/o supervisor to make it
bullet proof and never fail or hang ... allowing significant improvement
in productivity by allowing concurrent, on-demand testing with any
number of "test cells". i happened to mention the mvs 15min mtbf number
in an internal report ... which seemed to bring down the wrath of the
mvs organization on my head.

later when we were doing ha/cmp product ... misc. past posts
http://www.garlic.com/~lynn/subtopic.html#hacmp

i was asked to write a section in the corporate continuous availability
strategy document ... unforunately, both rochester and pok complained
(that they couldn't then match the implementation) and my section
got pulled.

i had also coined the terms "disaster survivable" and "geographic
survivable" (to differentiate from disaster/recovery) when we
were out marketing ... misc. past posts
http://www.garlic.com/~lynn/submain.html#available

--
40+yrs virtualization experience (since Jan68), online at home since Mar1970

----------------------------------------------------------------------

Schwarz, Barry A

unread,
Jul 21, 2009, 6:15:05 PM7/21/09
to
Try to search the archives at http://bama.ua.edu/archives/ibm-main.html
without one.

-----Original Message-----
From: Rick Fochtman
Sent: Tuesday, July 21, 2009 2:46 PM
To: IBM-...@bama.ua.edu
Subject: Re: Mainframe hacking (getting back on topic)

-------------------------------<snip>-------------------------------
That's the standard IBM-MAIN Archives login page, just substitute your
own email address and password instead of Dave's. That's how I got to
it.
---------------------------------<unsnip>-----------------------------
What password? I don't recall ever setting ANY password for IBM-MAIN.

----------------------------------------------------------------------

Rick Fochtman

unread,
Jul 21, 2009, 6:23:35 PM7/21/09
to
------------------------------------<snip>-------------------------------
What are the principal offenders? From an applications viewpoint, I see
(the facilities provided by) IEBCOPY, IDCAMS, TRANSMIT/RECEIVE.
(Others?) I find it bizarre that in a non-APF authorized state I can't
manipulate data or rename data sets for which I have all otherwise
necessary RACF authority.

What relief would be possible?
------------------------------------<unsnip>--------------------------------
APF authorization is intended not only to protect the user from himself,
but also to maintain system integrity. Invoking the wrong service at the
wrong time could be a major disaster for the entire data center. Bear in
mind that APF authorization also allows a programmer to bypass many of
the checks that help maintain integrity, as well as RACF security (or
ACF2 or