Reminder - Next meeting of the GSE UK Security Working Group

[Mark Wilson]

Ladies and Gentlemen,

A gentle reminder that the next meeting of the GSE UK Security Working Group, 
will take place on Thursday 6th June 2019 at the new offices of RSM Partners in 
Bromsgrove, UK (a 40 minute drive from Birmingham Airport).  If you cannot 
attend in person, you are welcome to join via webex.

Please note that registration is open, which you can access via our Events page 
> http://www.racf.gse.org.uk/content/content_events.php. When you register, 
please specify how you will attend (in person or via webex) – you will receive 
joining instructions a few days prior to the meeting.

Highlights from the agenda includes:


  *   Using thin-client terminal emulation to secure 3270 access
  *   Think like an Auditor to secure your system
  *   How to improve your testing of RACF changes
  *   Secure Engineering: How to develop authorised code without compromising 
z/OS system integrity
  *   Network Security – and don’t forget VTAM/SNA
  *   The journey of two Mainframe Security Trainees
  *   Identity Management: Using the right tooling

The full agenda is available to download from our Events page.

If you have a certification or you are studying, you can earn up to 7 CPE hours 
for attending this event.

We hope that you will be able to join us either in person or virtually!

Regards

Mark Wilson and Jamie Pease

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

Re: ind$file - omvs copy equivalent

[Paul Gilmartin]

On Wed, 8 May 2019 20:40:12 +, Seymour J Metz wrote:

>Yes, but you can FTP to an MVS file, which you can allocate with attributes. 
>
"MVS file"?  Do you mean a data set, or as TSO overloads the term, a DDNAME?
But the OP seemed to be interested in a UNIX file.

Mike didn't say where this was coming from or going.  A UNIX file seems to
be a roundabout way, but allocating a DDNAME and RECEIVE INDD() is
straightforward and avoids the need for YA temporary storage.

>>
>>From: Mike Stramba
>>Sent: Wednesday, May 8, 2019 3:59 PM
>>Is there is an OMVS "copy-to-mvs-fb80" equivalent to an "ind$file" upload ?
>>
>>Scenario :
>>
>>1) While in OMVS :   ftp (receive) an XMI file to the z/os system.  (z/os  
>>2.3)
>>  ...

-- gil

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

Re: MODGEN vs AMODGEN

[Mark Zelden]

So running an SMP/E CLEANUP against the target zone should delete that (I assume
the function sysmod is accepted).  I guess IBM should do that on whatever zone 
is 
used to merge OGL/370 (or whatever their process is) into the z/OS SMP/E zones
delivered with a z/OS ServerPac also. 

As far as your hesitation to drop it, I feel your pain. :-)  Still so many of 
these
printing related program products lying around my clients'  environments 
(OGL/370,
various fonts etc.) that everyone is afraid to drop and I think they way they 
are 
used doesn't lend software like TADz to track their usage.  

Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/



On Wed, 8 May 2019 21:28:20 +, Jesse 1 Robinson  
wrote:

>There's a sysmod entry for UQ13184 in the target that shows SUP'D by FMID 
>HVRL100. It doesn't make sense but without this nonsense, SMPMTS would be 
>empty. It's one of those products we keep ordering because no one still here 
>is confident in dropping it.  
>
>.
>.
>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
>robin...@sce.com
>
>-Original Message-
>From: IBM Mainframe Discussion List  On Behalf Of 
>Mark Zelden
>Sent: Wednesday, May 8, 2019 1:09 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: MODGEN vs AMODGEN
>
>OGL/370 is not a base z/OS component it is an old program product. I think my
>client dropped it finally at z/OS 2.1.   
>
>But being that it is ancient (25 yrs old?), why wouldn't all the maintenance 
>come accepted with a ServerPac order?  
>
>Best Regards,
>
>Mark
>--
>Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 
>Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
>http://www.mzelden.com/mvsutil.html
>Systems Programming expert at http://search390.techtarget.com/ateExperts/
>
>
>
>On Wed, 8 May 2019 19:06:51 +, sesse 1 Robinson  
>wrote:
>
>>Our SMPMTS (for 2.3) contains two macros for
>>
>>HVRL1 0   
>>OVERLAY GENERATION LANGUAGE, BASE
>>
>>They look really old, but we start each release with a fresh SMPE 
>>environment, so no carryover is possible.   
>>
>>.
>>.
>>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
>>robin...@sce.com
>>
>>-Original Message-
>>From: IBM Mainframe Discussion List  On 
>>Behalf Of Mark Zelden
>>Sent: Wednesday, May 8, 2019 11:42 AM
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>Subject: (External):Re: MODGEN vs AMODGEN
>>
>>On Wed, 8 May 2019 17:50:20 +, Seymour J Metz  wrote:
>>
 To my understanding they are just a target lib and distribution library.
>>>
>>>Yes, which is why they are not 9nterchangable. If you want macros from the 
>>>running system, use MODGEN  and MTS; if you want only the accepted service, 
>>>use AMODGEN.
>>>
>>
>>SMPMTS seems a thing of the ptst for z/OS.  Are there any base z/OS 
>>components that don't have a target library now?  Any optional ones?  My 
>>SMPMTS is empty for both
>>z/OS 2.2 and z/OS 2.3.   I accept maintenance one year behind apply and I'm 
>>at RSU1812
>>for both z/OS 2.2 (which a few systems are at) and z/OS 2.3. 
>>
>>
>>Best Regards,
>>
>>Mark
>>--
>>Mark Zelden - Zelden Consuiting Services - z/OS, OS/390 and MVS ITIL v3 
>>Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
>>http://www.mzelden.com/mvsutil.html
>>Systems Programming expert at 
>>http://search390.techtarget.com/ateExperts/
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Multiprise 3000 internal DASD hardware issues

[A Sysad]

FAQ:  For Multiprise 3000 (7060-H30) Internal Disk Subsystem - acquiring disks 
of unknown or questionable origin that you intend to re-use

There is a very little or obscurely documented feature that should be more 
widely known by owners.

The feature is called InitSurf (Surface Initialization).

Q:  What does it do?
A:  Writes zeroes from beginning to end on a disk as well as generating good 
block LRC (Longitudinal Redundancy Checking - similar to CRC or checksum).  
Effectively this wipes the drive clean making appear to the Internal Disk 
Subsystem Configuration application as a "brand new" disk.

Q:  What will likely happen if I don't use InitSurf on a previously used disk 
from another system?
A:  Most likely the Internal Disk Susbsystem Configuration application will 
throw errors like "I/O failure occurred when trying to create an array - LSS 
configuration data could not be built or upgraded" - after that the Disks for 
that array will appear with red backgrounds in the HDD Enclosures area

Q:  How do I use/access InitSurf?
A:  Only through the 'SSA Hard Drive Service Aids' icon in the Support Element 
Workplace application when logged in as 'SERVICE'.
- Click CPC icon over to the SSA Hard Drive Service Aids icon in 
the Service pane.
- this starts a special version of the ISSACFG utility in a window
- select the SSA Adapter - Bus 1 Slot 1 (12) to access the Internal 
Disk Subsystem (not the OS/2 ones which is 11)
- Select 'Disk Aids' and you should see all the drives (use F9/F10 to 
toggle flashing the lights on each drive so you're sure which is which)
- F6 is the magic key to start the InitSurf  (if you select the drive 
you are doing the InitSurf on it will show % complete)

General Internal Disk Subsystem Topics:

Q:  When building arrays in a 7060-H30, after cabling the blue SSA cables 
properly, where do the jumpers go?
A1: for a single array0 (six disks, two jumpers, Adapter card 0, two long blue 
SSA cables)
disks: SD10,SD11,SD20,SD21,SD40,SD41 (SD21 should end up being the 
hotspare for the entire system)
jumpers:  SD30,SD31
A2: for a two array system (array0 and array1)  (11 disks, 5 jumpers, Adapter 
Cards 0 and 1, two long blue SSA cables, one 6" blue SSA cable)
disks: SD10,SD11,SD20,SD21,SD40,SD41,SD12,SD13,SD22,SD33,SD42 (SD21 
should end up being the hotspare for the entire system)
jumpers:  SD30,SD31,SD32,SD23,SD43
A3: for a three array system (array0, array1, array2) (16 disks, 0 jumpers, 
Adapter Cards 0 and 1, two long blue SSA cables, one 6" blue SSA cable)
disks:  all 16 slots populated with disks (SD21 should end up being the 
hotspare for the entire system)
jumpers:  none

Q:  How do I cable the blue SSA cables in the adapter cards above the disks for 
the different quantities of arrays?
A:  The left-most cable always remains in place.  When needing to go to add 
array1 (and array2), you will need to get a short 6" blue SSA cable, attach it 
to the right-hand port on the Adapter Card 0 (Hard Drive Group 0 - leftmost) 
and attach the other end to the left-hand port on the Adapter Card 1 (Hard 
Drive Group 1 - middle) adapter card.  The remaining long blue SSA cable that 
runs back to the back of the machine should be attached to the right-hand port 
on Adapter Card 1 (Hard Drive Group 1 - middle) adapter card.  Conceptually, 
each pair of columns of disks is a loop on the midplane.  What you're doing for 
the array1&2 is essentially connecting those two loops to make one big 
continuous loop.

Q:  Where is/are the database file(s) that the Internal Disk Subsystem 
Configuration application uses?
A:  This also does not seem to be documented, but they appear to be...
D:\sp_rw\bbr2ccfg.dat
D:\sp_rw\bbr2scfg.dat
D:\sp_rw\bbrucfg.dat
D:\sp_rw\bbrucfg2.dat
If you really want to start from scratch and wipe out everything this 
application knows, you can rename/move them and the application will create new 
ones


References:
Service Guide Supplement - SY24-6162-00   Chapter 7
Internal Disk Subsystem: Users Guide - SA22-1026-00    Chapter 3
Service Guide - SY24-6155-03   pages 4-44 through 4-72  (this is really 
more for the OS/2 array)
Parts Catalog - S123-7471-00   pages 8-11,16

Part Numbers:
12K0474 - 18.2GB SSA HDD
21L3856 - HDD Jumper Assembly/Passthru
05N5370 - SSA Extender Card
31L7986 - SSA 1.4 meter cable
31L7985 - SSA .2 meter cable

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

Chinese hackers steal NSA malware ZDNET

[Edward Finnell]

https://www.zdnet.com/article/chinese-hackers-were-using-nsa-malware-a-year-before-shadow-brokers-leak/

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

Re: mainframe hacking "success stories"?

[Schuffenhauer, Mark]

There is a lot of security out there, if you're permitted to use it.  TCPIP did 
not make the mainframe less safe, other things using TCPIP did, especially when 
we moved most authentication off the mainframe.

"Let the servers do anything they want!"   "A, no."

The pen tester found stupid pointless stuff, and left.  The one time they were 
successful, they found a list of privileged accounts off mainframe, and guessed 
at the four obvious per 90 day passwords based on a partial password of one of 
those ids, where the signon was not secure.

Things are only as secure as the weakest link.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, May 08, 2019 2:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

It's similar to an authorized program in that there are complex rules for its 
use. You can associate access rules with controlled programs, but you need to 
dot all the Is and cross all the Ts.

An example might be giving a specific user to a payroll file only if he is 
running a specific program.

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


From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Tuesday, May 7, 2019 5:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

Yeah, about that:  What ~is~ a "controled program"?  I noticed that 
qualification, but my background is apps development and I'm woefully ignorant 
in spots.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Expecting the world to treat you fairly because you are a good person is a 
little like expecting the bull not to attack you because you are a vegetarian.  
-Dennis Wholey */


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Tuesday, May 7, 2019 17:05

The quoted text refers to controlled programs, which are not what users 
normally run.


From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Tuesday, May 7, 2019 5:02 PM

Well, more correctly, an installation ~can~ control users' ability to create 
dumps.  Here's a bit from the RACF manual:

"Your installation can control the dumping (with SYSUDUMP, SYSABEND, and 
SYSMDUMP statements) of address spaces that contain controlled programs by 
defining a profile to protect a resource called IEAABD.DMPAUTH in the FACILITY 
general resource class. / To control the dumping (with SYSABEND, SYSMDUMP, and 
SYSUDUMP statements) of address spaces that have tasks running in a task 
control block (TCB) key of less than 8, a profile protecting a resource called 
IEAABD.DMPAKEY must be defined in the FACILITY general resource class."

>From the way this is worded, I gather that if you don't define that rule in 
>RACF then dumps aren't restricted.  ACF2 and Top Secret may have the 
>restriction turned on by default, I'm not sure.  My current three clients seem 
>all to have this feature turned on, that is, they're controling access to 
>dumps.

-Original Message-
From: Seymour J Metz
Sent: Tuesday, May 7, 2019 16:29

"MVS users nowadays need special authority to create a program dump"?

-Original Message-
From: Bob Bridges 
Sent: Tuesday, May 7, 2019 3:33 PM

And thus what I said last night:  MVS has been around longer, so it's had more 
opportunity to find and plug holes.  Give it another two decades and we may 
find that even Windows is much more secure.

Not perfect, of course, even then.  Iron sharpens iron, so the Good Guys and 
the Bad Guys continue to get smarter together.

In 1978 and '79 I worked for a university that had a DECsystem-10.  I learned a 
~ton~ back then about...well, I didn't think of it as hacking, but I could 
start a program, then  it and inspect the machine code at my leisure.  
I made substantial progress toward figuring out Colossal Cave's "magic mode" 
before I left there for another job.  It's primarily by remembering those days 
that I came to understand why MVS users nowadays need special authority to 
create a program dump.

-Original Message-
From: Seymour J Metz
Sent: Tuesday, May 7, 2019 13:21

While the old mainframes were too expensive for individual users, that changed 
by the 1960s and moreso by the 1970s. Reme4mber the Honeywell Kitchen Computer? 
The DEC PDP-5 and PDP-8?

As for mainframe security I don't believe that such operating systems as 
IBSYS/IBJOB cleared storage between jobs.

-Original Message-
From: Jesse 1 Robinson 
Sent: Tuesday, May 7, 2019 1:12 PM

When I explain mainframe security to the unwashed but curious, I cite history 
above all. The mainframe emerged from the primordial bit bucket soup at a time 
and in a form that utterly precluded individual users from possessing their own 
computers. The notion of one-computer-one-user was monstrously unthinkable. 

Re: MODGEN vs AMODGEN

[Jesse 1 Robinson]

There's a sysmod entry for UQ13184 in the target that shows SUP'D by FMID 
HVRL100. It doesn't make sense but without this nonsense, SMPMTS would be 
empty. It's one of those products we keep ordering because no one still here is 
confident in dropping it.  

.
.
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
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Zelden
Sent: Wednesday, May 8, 2019 1:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: MODGEN vs AMODGEN

OGL/370 is not a base z/OS component it is an old program product. I think my
client dropped it finally at z/OS 2.1.   

But being that it is ancient (25 yrs old?), why wouldn't all the maintenance 
come accepted with a ServerPac order?  

Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 
Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/



On Wed, 8 May 2019 19:06:51 +, Jesse 1 Robinson  
wrote:

>Our SMPMTS (for 2.3) contains two macros for
>
>HVRL1 0   
>OVERLAY GENERATION LANGUAGE, BASE
>
>They look really old, but we start each release with a fresh SMPE environment, 
>so no carryover is possible.   
>
>.
>.
>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
>robin...@sce.com
>
>-Original Message-
>From: IBM Mainframe Discussion List  On 
>Behalf Of Mark Zelden
>Sent: Wednesday, May 8, 2019 11:42 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: MODGEN vs AMODGEN
>
>On Wed, 8 May 2019 17:50:20 +, Seymour J Metz  wrote:
>
>>> To my understanding they are just a target lib and distribution library.
>>
>>Yes, which is why they are not 9nterchangable. If you want macros from the 
>>running system, use MODGEN  and MTS; if you want only the accepted service, 
>>use AMODGEN.
>>
>
>SMPMTS seems a thing of the ptst for z/OS.  Are there any base z/OS components 
>that don't have a target library now?  Any optional ones?  My SMPMTS is empty 
>for both
>z/OS 2.2 and z/OS 2.3.   I accept maintenance one year behind apply and I'm at 
>RSU1812
>for both z/OS 2.2 (which a few systems are at) and z/OS 2.3. 
>
>
>Best Regards,
>
>Mark
>--
>Mark Zelden - Zelden Consuiting Services - z/OS, OS/390 and MVS ITIL v3 
>Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
>http://www.mzelden.com/mvsutil.html
>Systems Programming expert at 
>http://search390.techtarget.com/ateExperts/


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

Re: ind$file - omvs copy equivalent

[Jackson, Rob]

You can also specify -W and seqparms= on the cp command to specify DCB and 
space--and not have to pre-allocate the dataset.

First Tennessee Bank
Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, May 08, 2019 4:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ind$file - omvs copy equivalent

[External Email]

Yes, but you can FTP to an MVS file, which you can allocate with attributes.


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, May 8, 2019 4:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ind$file - omvs copy equivalent

On Wed, 8 May 2019 20:09:29 +, Seymour J Metz wrote:

>What happens if you pre-allocate the file as FB 80 and do a binary FTP?
>
You can't pre-allocate a UNIX file with attributes.

>
>From: Mike Stramba
>Sent: Wednesday, May 8, 2019 3:59 PM
>Is there is an OMVS "copy-to-mvs-fb80" equivalent to an "ind$file" upload ?
>
>Scenario :
>
>1) While in OMVS :   ftp (receive) an XMI file to the z/os system.  (z/os  2.3)
>
>2) Now copy (cp ?) to a FB80  file.
>
>I've tried  "cp  test.XMI   '//user.FB80',   but am getting an empty
>user.FB80 file.
>
>3) then issue RECEIVE against the FB80 file.
>
>If I do an IND$FILE  transfer  directly to the   FB80 dataset,  then
>RECEIVE  INDA(FB80) ..   is working.

-- gil

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

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

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

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

Re: ind$file - omvs copy equivalent

[Seymour J Metz]

Yes, but you can FTP to an MVS file, which you can allocate with attributes. 


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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, May 8, 2019 4:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ind$file - omvs copy equivalent

On Wed, 8 May 2019 20:09:29 +, Seymour J Metz wrote:

>What happens if you pre-allocate the file as FB 80 and do a binary FTP?
>
You can't pre-allocate a UNIX file with attributes.

>
>From: Mike Stramba
>Sent: Wednesday, May 8, 2019 3:59 PM
>Is there is an OMVS "copy-to-mvs-fb80" equivalent to an "ind$file" upload ?
>
>Scenario :
>
>1) While in OMVS :   ftp (receive) an XMI file to the z/os system.  (z/os  2.3)
>
>2) Now copy (cp ?) to a FB80  file.
>
>I've tried  "cp  test.XMI   '//user.FB80',   but am getting an empty
>user.FB80 file.
>
>3) then issue RECEIVE against the FB80 file.
>
>If I do an IND$FILE  transfer  directly to the   FB80 dataset,  then
>RECEIVE  INDA(FB80) ..   is working.

-- gil

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

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

Re: ind$file - omvs copy equivalent

[Mike Stramba]

On 5/8/19, Seymour J Metz  wrote:
> What happens if you pre-allocate the file as FB 80 and do a binary FTP?

Ahh !

Didn't think of that !

get  the.xmi  '//me.ind'   did the trick !

Thanks.

Mike

>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf of
> Mike Stramba 
> Sent: Wednesday, May 8, 2019 3:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: ind$file - omvs copy equivalent
>
> Is there is an OMVS "copy-to-mvs-fb80" equivalent to an "ind$file" upload ?
>
> Scenario :
>
> 1) While in OMVS :   ftp (receive) an XMI file to the z/os system.  (z/os
> 2.3)
>
> 2) Now copy (cp ?) to a FB80  file.
>
> I've tried  "cp  test.XMI   '//user.FB80',   but am getting an empty
> user.FB80 file.
>
> 3) then issue RECEIVE against the FB80 file.
>
> If I do an IND$FILE  transfer  directly to the   FB80 dataset,  then
> RECEIVE  INDA(FB80) ..   is working.
>
> Mike
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: ind$file - omvs copy equivalent

[ITschak Mugzach]

As Seymour suggested, we use filezilla to transfer files and pre-allocate
them.

ITschak

בתאריך יום ד׳, 8 במאי 2019, 23:09, מאת Seymour J Metz ‏:

> What happens if you pre-allocate the file as FB 80 and do a binary FTP?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Mike Stramba 
> Sent: Wednesday, May 8, 2019 3:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: ind$file - omvs copy equivalent
>
> Is there is an OMVS "copy-to-mvs-fb80" equivalent to an "ind$file" upload ?
>
> Scenario :
>
> 1) While in OMVS :   ftp (receive) an XMI file to the z/os system.  (z/os
> 2.3)
>
> 2) Now copy (cp ?) to a FB80  file.
>
> I've tried  "cp  test.XMI   '//user.FB80',   but am getting an empty
> user.FB80 file.
>
> 3) then issue RECEIVE against the FB80 file.
>
> If I do an IND$FILE  transfer  directly to the   FB80 dataset,  then
> RECEIVE  INDA(FB80) ..   is working.
>
> Mike
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: ind$file - omvs copy equivalent

[Paul Gilmartin]

On Wed, 8 May 2019 20:09:29 +, Seymour J Metz wrote:

>What happens if you pre-allocate the file as FB 80 and do a binary FTP?
> 
You can't pre-allocate a UNIX file with attributes.

>
>From: Mike Stramba
>Sent: Wednesday, May 8, 2019 3:59 PM
>Is there is an OMVS "copy-to-mvs-fb80" equivalent to an "ind$file" upload ?
>
>Scenario :
>
>1) While in OMVS :   ftp (receive) an XMI file to the z/os system.  (z/os  2.3)
>
>2) Now copy (cp ?) to a FB80  file.
>
>I've tried  "cp  test.XMI   '//user.FB80',   but am getting an empty
>user.FB80 file.
>
>3) then issue RECEIVE against the FB80 file.
>
>If I do an IND$FILE  transfer  directly to the   FB80 dataset,  then
>RECEIVE  INDA(FB80) ..   is working.

-- gil

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

Re: ind$file - omvs copy equivalent

[Paul Gilmartin]

On Wed, 8 May 2019 15:59:08 -0400, Mike Stramba  wrote:

>Is there is an OMVS "copy-to-mvs-fb80" equivalent to an "ind$file" upload ?
>
>Scenario :
>
>1) While in OMVS :   ftp (receive) an XMI file to the z/os system.  (z/os  2.3)
>
>2) Now copy (cp ?) to a FB80  file.
>
>I've tried  "cp  test.XMI   '//user.FB80',   but am getting an empty
>user.FB80 file.
>
>3) then issue RECEIVE against the FB80 file.
>
>If I do an IND$FILE  transfer  directly to the   FB80 dataset,  then
>RECEIVE  INDA(FB80) ..   is working.
> 
I believe you can:
X = BPXWDYN( 'alloc dd(INFILE) recfm(F,B) lrecl(80) 
path(''/u/mike/test.XMI'') msg(WTP)' )
RECEIVE INDDNAME(INDD)

(Be prepared to answer the prompt)

-- gil

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

Re: ind$file - omvs copy equivalent

[Jackson, Rob]

Pre Co:Z I had to do a bunch of shenanigans with scripts to copy files 
"automatically" from OMVS.  You need to check out the -v and -W arguments of 
cp.  Or just use Co:Z.

First Tennessee Bank
Mainframe Technical Support


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Stramba
Sent: Wednesday, May 08, 2019 3:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ind$file - omvs copy equivalent

[External Email]

Is there is an OMVS "copy-to-mvs-fb80" equivalent to an "ind$file" upload ?

Scenario :

1) While in OMVS :   ftp (receive) an XMI file to the z/os system.  (z/os  2.3)

2) Now copy (cp ?) to a FB80  file.

I've tried  "cp  test.XMI   '//user.FB80',   but am getting an empty
user.FB80 file.

3) then issue RECEIVE against the FB80 file.

If I do an IND$FILE  transfer  directly to the   FB80 dataset,  then
RECEIVE  INDA(FB80) ..   is working.

Mike

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

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

Re: MODGEN vs AMODGEN

[Mark Zelden]

OGL/370 is not a base z/OS component it is an old program product. I think my
client dropped it finally at z/OS 2.1.   

But being that it is ancient (25 yrs old?), why wouldn't all the maintenance 
come
accepted with a ServerPac order?  

Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/



On Wed, 8 May 2019 19:06:51 +, Jesse 1 Robinson  
wrote:

>Our SMPMTS (for 2.3) contains two macros for 
>
>HVRL1 0   
>OVERLAY GENERATION LANGUAGE, BASE
>
>They look really old, but we start each release with a fresh SMPE environment, 
>so no carryover is possible.   
>
>.
>.
>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
>robin...@sce.com
>
>-Original Message-
>From: IBM Mainframe Discussion List  On Behalf Of 
>Mark Zelden
>Sent: Wednesday, May 8, 2019 11:42 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: MODGEN vs AMODGEN
>
>On Wed, 8 May 2019 17:50:20 +, Seymour J Metz  wrote:
>
>>> To my understanding they are just a target lib and distribution library.
>>
>>Yes, which is why they are not 9nterchangable. If you want macros from the 
>>running system, use MODGEN  and MTS; if you want only the accepted service, 
>>use AMODGEN.
>>
>
>SMPMTS seems a thing of the ptst for z/OS.  Are there any base z/OS components 
>that don't have a target library now?  Any optional ones?  My SMPMTS is empty 
>for both
>z/OS 2.2 and z/OS 2.3.   I accept maintenance one year behind apply and I'm at 
>RSU1812
>for both z/OS 2.2 (which a few systems are at) and z/OS 2.3. 
>
>
>Best Regards,
>
>Mark
>--
>Mark Zelden - Zelden Consuiting Services - z/OS, OS/390 and MVS ITIL v3 
>Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
>http://www.mzelden.com/mvsutil.html
>Systems Programming expert at http://search390.techtarget.com/ateExperts/
>
>
---
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: ind$file - omvs copy equivalent

[Pew, Curtis G]

On May 8, 2019, at 2:59 PM, Mike Stramba 
mailto:mikestra...@gmail.com>> wrote:

1) While in OMVS :   ftp (receive) an XMI file to the z/os system.  (z/os  2.3)

2) Now copy (cp ?) to a FB80  file.

I've tried  "cp  test.XMI   '//user.FB80',   but am getting an empty
user.FB80 file.

3) then issue RECEIVE against the FB80 file.


I’ve done exactly that on several occasions without issues.

Did you use binary mode when you did the FTP?

If you issue “od -x -N 80 test.XMI” does it look like the first record of an 
XMIT dataset?


--
Pew, Curtis G
curtis@austin.utexas.edu






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

Re: ind$file - omvs copy equivalent

[Seymour J Metz]

What happens if you pre-allocate the file as FB 80 and do a binary FTP?


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


From: IBM Mainframe Discussion List  on behalf of 
Mike Stramba 
Sent: Wednesday, May 8, 2019 3:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ind$file - omvs copy equivalent

Is there is an OMVS "copy-to-mvs-fb80" equivalent to an "ind$file" upload ?

Scenario :

1) While in OMVS :   ftp (receive) an XMI file to the z/os system.  (z/os  2.3)

2) Now copy (cp ?) to a FB80  file.

I've tried  "cp  test.XMI   '//user.FB80',   but am getting an empty
user.FB80 file.

3) then issue RECEIVE against the FB80 file.

If I do an IND$FILE  transfer  directly to the   FB80 dataset,  then
RECEIVE  INDA(FB80) ..   is working.

Mike

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

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

ind$file - omvs copy equivalent

[Mike Stramba]

Is there is an OMVS "copy-to-mvs-fb80" equivalent to an "ind$file" upload ?

Scenario :

1) While in OMVS :   ftp (receive) an XMI file to the z/os system.  (z/os  2.3)

2) Now copy (cp ?) to a FB80  file.

I've tried  "cp  test.XMI   '//user.FB80',   but am getting an empty
user.FB80 file.

3) then issue RECEIVE against the FB80 file.

If I do an IND$FILE  transfer  directly to the   FB80 dataset,  then
RECEIVE  INDA(FB80) ..   is working.

Mike

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

Re: mainframe hacking "success stories"?

[Seymour J Metz]

It's similar to an authorized program in that there are complex rules for its 
use. You can associate access rules with controlled programs, but you need to 
dot all the Is and cross all the Ts.

An example might be giving a specific user to a payroll file only if he is 
running a specific program.

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


From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Tuesday, May 7, 2019 5:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

Yeah, about that:  What ~is~ a "controled program"?  I noticed that
qualification, but my background is apps development and I'm woefully
ignorant in spots.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Expecting the world to treat you fairly because you are a good person is
a little like expecting the bull not to attack you because you are a
vegetarian.  -Dennis Wholey */


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Tuesday, May 7, 2019 17:05

The quoted text refers to controlled programs, which are not what users
normally run.


From: IBM Mainframe Discussion List  on behalf of
Bob Bridges 
Sent: Tuesday, May 7, 2019 5:02 PM

Well, more correctly, an installation ~can~ control users' ability to create
dumps.  Here's a bit from the RACF manual:

"Your installation can control the dumping (with SYSUDUMP, SYSABEND, and
SYSMDUMP statements) of address spaces that contain controlled programs by
defining a profile to protect a resource called IEAABD.DMPAUTH in the
FACILITY general resource class. / To control the dumping (with SYSABEND,
SYSMDUMP,
and SYSUDUMP statements) of address spaces that have tasks running in a task
control block (TCB) key of less than 8, a profile protecting a resource
called IEAABD.DMPAKEY must be defined in the FACILITY general resource
class."

>From the way this is worded, I gather that if you don't define that rule in
RACF then dumps aren't restricted.  ACF2 and Top Secret may have the
restriction turned on by default, I'm not sure.  My current three clients
seem all to have this feature turned on, that is, they're controling access
to dumps.

-Original Message-
From: Seymour J Metz
Sent: Tuesday, May 7, 2019 16:29

"MVS users nowadays need special authority to create a program dump"?

-Original Message-
From: Bob Bridges 
Sent: Tuesday, May 7, 2019 3:33 PM

And thus what I said last night:  MVS has been around longer, so it's had
more opportunity to find and plug holes.  Give it another two decades and we
may find that even Windows is much more secure.

Not perfect, of course, even then.  Iron sharpens iron, so the Good Guys and
the Bad Guys continue to get smarter together.

In 1978 and '79 I worked for a university that had a DECsystem-10.  I
learned a ~ton~ back then about...well, I didn't think of it as hacking, but
I could start a program, then  it and inspect the machine code at my
leisure.  I made substantial progress toward figuring out Colossal Cave's
"magic mode" before I left there for another job.  It's primarily by
remembering those days that I came to understand why MVS users nowadays need
special authority to create a program dump.

-Original Message-
From: Seymour J Metz
Sent: Tuesday, May 7, 2019 13:21

While the old mainframes were too expensive for individual users, that
changed by the 1960s and moreso by the 1970s. Reme4mber the Honeywell
Kitchen Computer? The DEC PDP-5 and PDP-8?

As for mainframe security I don't believe that such operating systems as
IBSYS/IBJOB cleared storage between jobs.

-Original Message-
From: Jesse 1 Robinson 
Sent: Tuesday, May 7, 2019 1:12 PM

When I explain mainframe security to the unwashed but curious, I cite
history above all. The mainframe emerged from the primordial bit bucket soup
at a time and in a form that utterly precluded individual users from
possessing their own computers. The notion of one-computer-one-user was
monstrously unthinkable. Mainframe was of necessity a shared environment in
which utter strangers were obligated to breathe the same digital air and
excrete into the same pools. Preventing cross contamination was the first
commandment. This overriding concern guided and often dictated decades of
evolution. There was never a moment in the mainframe's lineage where
security or integrity could be architecturally compromised for *any* other
goal.

Contrast that with any sort of Pee-Cee, where Pee stood originally for 'be
sure to close the dorm room door when you toddle down the hall for a cold
one'. Likewise for the U of xNIX. Each machine had one devoted owner whose
needs were paramount. Unfortunately the computer could not discern its
master by nose, a simple trick any dog could perform instinctively.

Then the throwable machines, by virtue of price and availability, 

Re: [EXTERNAL] Re: mainframe hacking "success stories"?

[Seymour J Metz]

"That is not new, it has already been, for there is nothing new under the Sun."

There have been extensive discussions here over the decades about bad auditors. 
OTOH, if you're lucky enough to have competent auditors, they can really help.


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


From: IBM Mainframe Discussion List  on behalf of 
Bill Johnson <0047540adefe-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, May 8, 2019 1:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: mainframe hacking "success stories"?

The problem in my recent shops is management and security people whose 
mainframe knowledge would struggle to fill a thimble. They find security 
“holes” that are not really holes because they have no idea how the mainframe 
or its security apparatus works.


Sent from Yahoo Mail for iPhone


On Wednesday, May 8, 2019, 1:28 PM, Seymour J Metz  wrote:

Sometimes management won't let  you correct a security problem until an auditor 
finds it. A package or service that locates *real* threats can be very useful 
leverage for tightening things up.

OTOH, an auditor, product or service that claims bogus security issues, 
sometimes missing real issues at the same time, is worse than useless.


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


From: IBM Mainframe Discussion List  on behalf of 
Sankaranarayanan, Vignesh 
Sent: Wednesday, May 8, 2019 10:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: mainframe hacking "success stories"?

I guess the point of contention really is "vULnErAbiliTIeS"...
Words have meaning, a vulnerability is not equal to a loosely 
configured/hardened system.
Of course, I could be wrong but I take the word to mean zero-days or something 
that breaks a module/function, and the way it breaks is exploited for further 
foothold, etc.
An open wound is vulnerable, but not wearing your seatbelt is NOT  a 
vulnerability, it's a risk!
Yes, when the CEO has to issue a public statement it doesn't matter whose turf 
the hole is in, but that doesn't mean common sense goes out the window, and 
suddenly 2 random and unrelated things are equal.

Way too many times, a normal, but potentially dangerous config miss/omission is 
labelled as VULNERABILITY VULNERABILITY VULNERABILITY VULNERABILITY YOUR 
MAINFRAME IS DOOMED, YOUR RACF TEAM IS AN ABSOLUTE ZERO, YOU ARE DONE FOR. 
unless you hire us and we can sort it all out for you.
Everyone's gotta pay bills, sure, but I'm not particularly fond of the kind of 
salesman that creates the demand --just to push their product--... like the 
pen-selling example in the Wolf of Wall Street.
Products are cool, but what's cooler is what people can achieve with vanilla 
stuff.
A beautifully setup piece of REXX/ASM/bunch of scripts on various platforms can 
easily outperform Next Gen security greatness.
Not being completely dismissive of course, but many times, it's easier to stick 
in a product than doing the hard thing, which is to learn to be efficient and 
effective with what you've got.

- Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: 08 May 2019 02:26
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: mainframe hacking "success stories"?

I was travelling and I have kind of lost track of where this thread has gone. 
Let me throw three thoughts out there.

1. Our job is to make our platform -- and if you are at a customer, your site 
-- as secure as reasonably possible. Not "more secure than Windows." It is NOT 
like the joke about the two hunters being chased by a bear, one of whom says "I 
don't have to run faster than the bear; just faster than you."
You have to run faster than ALL the bears.

2. "Oh, but they got a userid and password from somewhere else." A userid and 
password is nothing. You know who has a userid and password? All of your users. 
Another name for your users is "insider threats."

3. You think your mainframe in darned near invulnerable? Put it to the test.
Hire one of the pen testing firms like RSM or Vanguard. Report back here if 
they find no vulnerabilities. Tell me I'm wrong.

Charles

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

MARKSANDSPENCER.COM

 Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

Re: mainframe hacking "success stories"?

[ITschak Mugzach]

Once in while assessment value nothing. your systems are probably changing
every day. Consider continuous monitoring solution...
ITschak

On Wed, May 8, 2019 at 10:28 PM Tom Brennan 
wrote:

> We're you told what prevented them from getting into the mainframe, or
> any details about the attempt?
>
> On 5/8/2019 5:02 AM, Bill Johnson wrote:
> > We did hire a firm to come in and test. They were able to get into the
> building by piggy backing on someone else’s badge. Were able to get into
> various servers, but did not get into the MF.
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

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

Re: mainframe hacking "success stories"?

[Tom Brennan]

"Were"... typing while eating is my excuse.  Sorry for the crumbs.

On 5/8/2019 12:27 PM, Tom Brennan wrote:
We're you told what prevented them from getting into the mainframe, or 
any details about the attempt?


On 5/8/2019 5:02 AM, Bill Johnson wrote:
We did hire a firm to come in and test. They were able to get into the 
building by piggy backing on someone else’s badge. Were able to get 
into various servers, but did not get into the MF.




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




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

Re: mainframe hacking "success stories"?

[Tom Brennan]

We're you told what prevented them from getting into the mainframe, or 
any details about the attempt?


On 5/8/2019 5:02 AM, Bill Johnson wrote:

We did hire a firm to come in and test. They were able to get into the building 
by piggy backing on someone else’s badge. Were able to get into various 
servers, but did not get into the MF.



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

Re: MODGEN vs AMODGEN

[Jesse 1 Robinson]

Our SMPMTS (for 2.3) contains two macros for 

HVRL100   
OVERLAY GENERATION LANGUAGE, BASE

They look really old, but we start each release with a fresh SMPE environment, 
so no carryover is possible.   

.
.
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
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Zelden
Sent: Wednesday, May 8, 2019 11:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: MODGEN vs AMODGEN

On Wed, 8 May 2019 17:50:20 +, Seymour J Metz  wrote:

>> To my understanding they are just a target lib and distribution library.
>
>Yes, which is why they are not 9nterchangable. If you want macros from the 
>running system, use MODGEN  and MTS; if you want only the accepted service, 
>use AMODGEN.
>

SMPMTS seems a thing of the past for z/OS.  Are there any base z/OS components 
that don't have a target library now?  Any optional ones?  My SMPMTS is empty 
for both
z/OS 2.2 and z/OS 2.3.   I accept maintenance one year behind apply and I'm at 
RSU1812
for both z/OS 2.2 (which a few systems are at) and z/OS 2.3. 


Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 
Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/


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

Re: MODGEN vs AMODGEN

[Mark Zelden]

On Wed, 8 May 2019 17:50:20 +, Seymour J Metz  wrote:

>> To my understanding they are just a target lib and distribution library.
>
>Yes, which is why they are not 9nterchangable. If you want macros from the 
>running system, use MODGEN  and MTS; if you want only the accepted service, 
>use AMODGEN.
>

SMPMTS seems a thing of the past for z/OS.  Are there any base z/OS components 
that
don't have a target library now?  Any optional ones?  My SMPMTS is empty for 
both
z/OS 2.2 and z/OS 2.3.   I accept maintenance one year behind apply and I'm at 
RSU1812
for both z/OS 2.2 (which a few systems are at) and z/OS 2.3. 


Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: mainframe hacking "success stories"?

[Seymour J Metz]

 4. Get management buy in to fix the problems they find, if any.

 5. Even if they find nothing, repeat the pen test periodically.


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


From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Tuesday, May 7, 2019 9:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

I was travelling and I have kind of lost track of where this thread has
gone. Let me throw three thoughts out there.

1. Our job is to make our platform -- and if you are at a customer, your
site -- as secure as reasonably possible. Not "more secure than Windows." It
is NOT like the joke about the two hunters being chased by a bear, one of
whom says "I don't have to run faster than the bear; just faster than you."
You have to run faster than ALL the bears.

2. "Oh, but they got a userid and password from somewhere else." A userid
and password is nothing. You know who has a userid and password? All of your
users. Another name for your users is "insider threats."

3. You think your mainframe in darned near invulnerable? Put it to the test.
Hire one of the pen testing firms like RSM or Vanguard. Report back here if
they find no vulnerabilities. Tell me I'm wrong.

Charles

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

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

Re: [EXTERNAL] Re: mainframe hacking "success stories"?

[Bill Johnson]

The problem in my recent shops is management and security people whose 
mainframe knowledge would struggle to fill a thimble. They find security 
“holes” that are not really holes because they have no idea how the mainframe 
or its security apparatus works.


Sent from Yahoo Mail for iPhone


On Wednesday, May 8, 2019, 1:28 PM, Seymour J Metz  wrote:

Sometimes management won't let  you correct a security problem until an auditor 
finds it. A package or service that locates *real* threats can be very useful 
leverage for tightening things up.

OTOH, an auditor, product or service that claims bogus security issues, 
sometimes missing real issues at the same time, is worse than useless.


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


From: IBM Mainframe Discussion List  on behalf of 
Sankaranarayanan, Vignesh 
Sent: Wednesday, May 8, 2019 10:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: mainframe hacking "success stories"?

I guess the point of contention really is "vULnErAbiliTIeS"...
Words have meaning, a vulnerability is not equal to a loosely 
configured/hardened system.
Of course, I could be wrong but I take the word to mean zero-days or something 
that breaks a module/function, and the way it breaks is exploited for further 
foothold, etc.
An open wound is vulnerable, but not wearing your seatbelt is NOT  a 
vulnerability, it's a risk!
Yes, when the CEO has to issue a public statement it doesn't matter whose turf 
the hole is in, but that doesn't mean common sense goes out the window, and 
suddenly 2 random and unrelated things are equal.

Way too many times, a normal, but potentially dangerous config miss/omission is 
labelled as VULNERABILITY VULNERABILITY VULNERABILITY VULNERABILITY YOUR 
MAINFRAME IS DOOMED, YOUR RACF TEAM IS AN ABSOLUTE ZERO, YOU ARE DONE FOR. 
unless you hire us and we can sort it all out for you.
Everyone's gotta pay bills, sure, but I'm not particularly fond of the kind of 
salesman that creates the demand --just to push their product--... like the 
pen-selling example in the Wolf of Wall Street.
Products are cool, but what's cooler is what people can achieve with vanilla 
stuff.
A beautifully setup piece of REXX/ASM/bunch of scripts on various platforms can 
easily outperform Next Gen security greatness.
Not being completely dismissive of course, but many times, it's easier to stick 
in a product than doing the hard thing, which is to learn to be efficient and 
effective with what you've got.

- Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: 08 May 2019 02:26
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: mainframe hacking "success stories"?

I was travelling and I have kind of lost track of where this thread has gone. 
Let me throw three thoughts out there.

1. Our job is to make our platform -- and if you are at a customer, your site 
-- as secure as reasonably possible. Not "more secure than Windows." It is NOT 
like the joke about the two hunters being chased by a bear, one of whom says "I 
don't have to run faster than the bear; just faster than you."
You have to run faster than ALL the bears.

2. "Oh, but they got a userid and password from somewhere else." A userid and 
password is nothing. You know who has a userid and password? All of your users. 
Another name for your users is "insider threats."

3. You think your mainframe in darned near invulnerable? Put it to the test.
Hire one of the pen testing firms like RSM or Vanguard. Report back here if 
they find no vulnerabilities. Tell me I'm wrong.

Charles

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

MARKSANDSPENCER.COM

 Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

http://secure-web.cisco.com/1tXrycjZt65r8itxPWtiSpcSBSbgYEO9yEsp-Ju8yXoB2KksloCg6AIzvtjjOC3z6-677n_k-7qjNQnbFVPP3018gggmboywthXztkaL5CShfp5sy2mR9p8qTIffDVc1oysRfrYUi9FIPJYjxSdExj64aVLabgJgai3RXXa_RwOQ0ze8bBRMTO3E7qmIyUDO-2TvtvMJkJckxd5H1VorFY57YAeJgBBKDjlHMhTvZICo1Ke4aepBxXFEAFm5MTYTHwJdEfE9R3lt1Ubn5x6CAFWD-A9wRVbKzrhRduLKz0XtMEzgdrZGhgLrcBRDIJ1QmFrbRXD-1LgoxzGWKy5sChQjempZidX9-AZeQ2n9j-VvYw0NyOxe5ZQsI4HKUmMBFDxJI7jao-nipAzob-BkaN02FIpkscL4F12RJrwiM3mGPR9yq684U3UsPVQAHsFpD/http%3A%2F%2Fwww.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful.

Re: [EXTERNAL] Re: mainframe hacking "success stories"?

[Bill Johnson]

Have experienced the second paragraph many times.


Sent from Yahoo Mail for iPhone


On Wednesday, May 8, 2019, 1:28 PM, Seymour J Metz  wrote:

Sometimes management won't let  you correct a security problem until an auditor 
finds it. A package or service that locates *real* threats can be very useful 
leverage for tightening things up.

OTOH, an auditor, product or service that claims bogus security issues, 
sometimes missing real issues at the same time, is worse than useless.


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


From: IBM Mainframe Discussion List  on behalf of 
Sankaranarayanan, Vignesh 
Sent: Wednesday, May 8, 2019 10:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: mainframe hacking "success stories"?

I guess the point of contention really is "vULnErAbiliTIeS"...
Words have meaning, a vulnerability is not equal to a loosely 
configured/hardened system.
Of course, I could be wrong but I take the word to mean zero-days or something 
that breaks a module/function, and the way it breaks is exploited for further 
foothold, etc.
An open wound is vulnerable, but not wearing your seatbelt is NOT  a 
vulnerability, it's a risk!
Yes, when the CEO has to issue a public statement it doesn't matter whose turf 
the hole is in, but that doesn't mean common sense goes out the window, and 
suddenly 2 random and unrelated things are equal.

Way too many times, a normal, but potentially dangerous config miss/omission is 
labelled as VULNERABILITY VULNERABILITY VULNERABILITY VULNERABILITY YOUR 
MAINFRAME IS DOOMED, YOUR RACF TEAM IS AN ABSOLUTE ZERO, YOU ARE DONE FOR. 
unless you hire us and we can sort it all out for you.
Everyone's gotta pay bills, sure, but I'm not particularly fond of the kind of 
salesman that creates the demand --just to push their product--... like the 
pen-selling example in the Wolf of Wall Street.
Products are cool, but what's cooler is what people can achieve with vanilla 
stuff.
A beautifully setup piece of REXX/ASM/bunch of scripts on various platforms can 
easily outperform Next Gen security greatness.
Not being completely dismissive of course, but many times, it's easier to stick 
in a product than doing the hard thing, which is to learn to be efficient and 
effective with what you've got.

- Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: 08 May 2019 02:26
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: mainframe hacking "success stories"?

I was travelling and I have kind of lost track of where this thread has gone. 
Let me throw three thoughts out there.

1. Our job is to make our platform -- and if you are at a customer, your site 
-- as secure as reasonably possible. Not "more secure than Windows." It is NOT 
like the joke about the two hunters being chased by a bear, one of whom says "I 
don't have to run faster than the bear; just faster than you."
You have to run faster than ALL the bears.

2. "Oh, but they got a userid and password from somewhere else." A userid and 
password is nothing. You know who has a userid and password? All of your users. 
Another name for your users is "insider threats."

3. You think your mainframe in darned near invulnerable? Put it to the test.
Hire one of the pen testing firms like RSM or Vanguard. Report back here if 
they find no vulnerabilities. Tell me I'm wrong.

Charles

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

MARKSANDSPENCER.COM

 Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

http://secure-web.cisco.com/1tXrycjZt65r8itxPWtiSpcSBSbgYEO9yEsp-Ju8yXoB2KksloCg6AIzvtjjOC3z6-677n_k-7qjNQnbFVPP3018gggmboywthXztkaL5CShfp5sy2mR9p8qTIffDVc1oysRfrYUi9FIPJYjxSdExj64aVLabgJgai3RXXa_RwOQ0ze8bBRMTO3E7qmIyUDO-2TvtvMJkJckxd5H1VorFY57YAeJgBBKDjlHMhTvZICo1Ke4aepBxXFEAFm5MTYTHwJdEfE9R3lt1Ubn5x6CAFWD-A9wRVbKzrhRduLKz0XtMEzgdrZGhgLrcBRDIJ1QmFrbRXD-1LgoxzGWKy5sChQjempZidX9-AZeQ2n9j-VvYw0NyOxe5ZQsI4HKUmMBFDxJI7jao-nipAzob-BkaN02FIpkscL4F12RJrwiM3mGPR9yq684U3UsPVQAHsFpD/http%3A%2F%2Fwww.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful.

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

Re: mainframe hacking "success stories"?

[Seymour J Metz]

Of course, some documents would no longer work, so you need management buyin to 
secure things.


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


From: IBM Mainframe Discussion List  on behalf of 
Gabe Goldberg 
Sent: Wednesday, May 8, 2019 12:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

I had a Sev 1 APAR against PROFS (or when it became OfficeVision) by
pointing out that (at least on VM) sending a document with embedded .sy
control word could, say, quietly format recipient's A disk (for those
who've never touched VM, that's a VM user's personal storage). Tricky
fix was making NOSY (or whatever option disabled processing .sy) the
default. Presumably the problem and fix applied wherever OV appeared.

Seymour J Metz  said correctly:

 > And when some "genius" at Microsoft thought it would be a good idea to
 > be able to embed arbitrary code in a document, it meant that someone
could
 > do anything they wanted to do to your computer just by sending you a
document.

To be fair, that issue existed in Script way back when.

--
Gabriel Goldberg, Computers and Publishing, Inc.   g...@gabegold.com
3401 Silver Maple Place, Falls Church, VA 22042   (703) 204-0433
LinkedIn: 
http://secure-web.cisco.com/1z9nm_XUec9A2JjLl71eUbjF0oFeWmu7IzCPbSOxENPcGsVFBMma3nJvrClTZExGxhCCwvmLFd3IcgQ3rrYxrYrTYL7UvhFf63hukjct4ELUv8PRCUIwtx7FXTZbp8vLhy8fZRZgbRpLh_L31Da0FpC2aP1AuXXN_BoSyw9DTbfCVMBaMR9vz4dgqzRPKEGKF4s7eLhsT4UkgmALh2tUxtOl8DPQoYbFVjzrjdlzFkrus0ptxLh0pKQE8AMAZohlkIsoaS4c9bADyRo6BJty6E_JIqctds_bLYFDMCtRuAwojkY0nX1C9g5lb2UJLE93QnDqn_glpNqOu-IcHPYabb2op0Kn-qyZ02b6KbmLuTdNyHk3p0bNyv-TjS1Wx9FjOU5AmlTAbUaPTzKAn1XHaNG2g9-i1ssWnSn0V6irnGQYNmA8A_VJ-n395LqMTGHZ1/http%3A%2F%2Fwww.linkedin.com%2Fin%2Fgabegold
Twitter: GabeG0

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

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

Re: mainframe hacking "success stories"?

[Seymour J Metz]

There are two very different questions.

 1. Is it safe to run multilevel security on this platform?

 2. Is it safe to run multilevel security at this site?

If the answer to the second question is no, then the answer to the first is 
irrelevant. 


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


From: IBM Mainframe Discussion List  on behalf of 
Gabe Goldberg 
Sent: Wednesday, May 8, 2019 12:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

Long ago I was asked for advice on proving that it was unsafe running
multiple levels of classified material on VM, in a data center where the
manager had -- of course -- insisted that it was.

Whether or not that was true (and whether or not it could be proven), I
suggested first experimenting with issues such as Tim mentions. Such as
starting at the system S and Y disks (where IBM and installation system
software, utilities, and tools lived), examining Execs for Link
commands, and following them where they led. A few days later, the
tester placed a printout of the -- unencrypted, with passwords -- system
directory on the manager's desk.

I don't know what followed but wonder if they were still allowed to run
any classified work.

Timothy Sipples  said:

That said, I'm quite concerned (paranoid, even) because these wonderful
security features so frequently either aren't implemented at all or are
implemented badly, inconsistently. Also, unfortunately, there are far too
many organizations running unsupported technologies with known security
vulnerabilities, and there are even more that do not have reasonable,
timely preventive maintenance programs that they execute consistently and
well.

--
Gabriel Goldberg, Computers and Publishing, Inc.   g...@gabegold.com
3401 Silver Maple Place, Falls Church, VA 22042   (703) 204-0433
LinkedIn: 
http://secure-web.cisco.com/1nFG-F-LQeWf6Rjs_reP7vF8EPayKPR5DDz_cI7aCm7XzBKPavGdna_aPEB_qBXEWBAn0sA8lpu99iyBHpwSOUphAgj-cxbHdJQRt6lGDW_hh6nfq4PxzTuFC1sG9HOspjLCQE58qZPyRseIgJwQmHFsxvm0rTCkRW5uaGJGQq7bEep1qdUy62yvHf_O9LZe2tY3777p26cNp8LiJhkgiqu3xoMAaIAOy2uZpoxelbII3hKySBXdqhu1LW4DRfsUp--a2M239xvh9R3JK6-keXvkIefD4KZPnq3K_v0SMfctXfL5kLu7RTsFDjOGnzgfDrouqxgsVmBfkjqJeTypazohjI3x0Qvn1kVQ63tk_pdY4gQSi5bToFc2COU4RUXyK/http%3A%2F%2Fwww.linkedin.com%2Fin%2Fgabegold
Twitter: GabeG0

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

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

Re: mainframe hacking "success stories"?

[Seymour J Metz]

PROFS uses Script; AFAIK it doesn't format documents itself.


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


From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Tuesday, May 7, 2019 11:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

Seymour J Metz wrote, re:

>> And when some "genius" at Microsoft thought it would be a good idea to

>> be able to embed arbitrary code in a document, it meant that someone could

>> do anything they wanted to do to your computer just by sending you a 
>> document.



>To be fair, that issue existed in Script way back when.



And in PROFS. And elsewhere.



Of course autorun was evil, but it did have some fun moments. At one point in 
the Outlook 97 days, our network manager sent me a
note which, when opened, played VERY LOUDLY a .wav file that screamed "HEY 
EVERYBODY! I'M LOOKIN' AT PORN OVER HERE!"


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

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

Re: MODGEN vs AMODGEN

[Seymour J Metz]

> To my understanding they are just a target lib and distribution library.

Yes, which is why they are not 9nterchangable. If you want macros from the 
running system, use MODGEN  and MTS; if you want only the accepted service, use 
AMODGEN.


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


From: IBM Mainframe Discussion List  on behalf of 
Peter 
Sent: Wednesday, May 8, 2019 12:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: MODGEN vs AMODGEN

Hi

This is just for my knowledge sake.

While assembling a assembler source code I have seen few JCL using MODGEN
and AMODGEN sometimes.

Does it really makes any difference between the two ?

To my understanding they are just a target lib and distribution library.

Peter

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

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

Re: mainframe hacking "success stories"?

[Anne & Lynn Wheeler]

one of the biggest problems doing the (non-SNA) internal network around
the world was when (encrypted) links crossed national boundaries
... lots of push back from numerous countries around the world (even tho
all these links were between purely corporate locations).

other trivia: at big cutover to internetworking protocol on 1Jan1983,
they had approx 100 network nodes and 255 hosts ... when the internal
network was rapidly approach 1000 systems (which it passes a few months
later). old post with corporate locations around the world that added
one or more network nodes during 1983:
http://www.garlic.com/~lynn/2006k.html#8

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: Take cover, it's a student programmer! | Computerworld Shark Tank

[Steve Smith]

I started out long ago and far away with an 026 BCD keypunch (it probably
had tubes in its electronics); had to learn a few "substitutions" for some
rare characters like + & -.  It was wonderful to graduate to a "modern" 029
later.  I even learned how to make one of those control cards you wrapped
around a little drum... being able to tab on a keypunch was huge.

Later on, as an operator, I did learn it was fairly easy, not necessarily
requiring intent, to convert a 2501 card reader into a card sprayer.  And
it was spectacular.

sas

On Wed, May 8, 2019 at 1:05 PM Schuffenhauer, Mark 
wrote:

> You have not punched cards, until you've punched them in the original
> Klingon.

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

Re: [EXTERNAL] Re: mainframe hacking "success stories"?

[Seymour J Metz]

Sometimes management won't let  you correct a security problem until an auditor 
finds it. A package or service that locates *real* threats can be very useful 
leverage for tightening things up.

OTOH, an auditor, product or service that claims bogus security issues, 
sometimes missing real issues at the same time, is worse than useless.


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


From: IBM Mainframe Discussion List  on behalf of 
Sankaranarayanan, Vignesh 
Sent: Wednesday, May 8, 2019 10:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: mainframe hacking "success stories"?

I guess the point of contention really is "vULnErAbiliTIeS"...
Words have meaning, a vulnerability is not equal to a loosely 
configured/hardened system.
Of course, I could be wrong but I take the word to mean zero-days or something 
that breaks a module/function, and the way it breaks is exploited for further 
foothold, etc.
An open wound is vulnerable, but not wearing your seatbelt is NOT  a 
vulnerability, it's a risk!
Yes, when the CEO has to issue a public statement it doesn't matter whose turf 
the hole is in, but that doesn't mean common sense goes out the window, and 
suddenly 2 random and unrelated things are equal.

Way too many times, a normal, but potentially dangerous config miss/omission is 
labelled as VULNERABILITY VULNERABILITY VULNERABILITY VULNERABILITY YOUR 
MAINFRAME IS DOOMED, YOUR RACF TEAM IS AN ABSOLUTE ZERO, YOU ARE DONE FOR. 
unless you hire us and we can sort it all out for you.
Everyone's gotta pay bills, sure, but I'm not particularly fond of the kind of 
salesman that creates the demand --just to push their product--... like the 
pen-selling example in the Wolf of Wall Street.
Products are cool, but what's cooler is what people can achieve with vanilla 
stuff.
A beautifully setup piece of REXX/ASM/bunch of scripts on various platforms can 
easily outperform Next Gen security greatness.
Not being completely dismissive of course, but many times, it's easier to stick 
in a product than doing the hard thing, which is to learn to be efficient and 
effective with what you've got.

- Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: 08 May 2019 02:26
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: mainframe hacking "success stories"?

I was travelling and I have kind of lost track of where this thread has gone. 
Let me throw three thoughts out there.

1. Our job is to make our platform -- and if you are at a customer, your site 
-- as secure as reasonably possible. Not "more secure than Windows." It is NOT 
like the joke about the two hunters being chased by a bear, one of whom says "I 
don't have to run faster than the bear; just faster than you."
You have to run faster than ALL the bears.

2. "Oh, but they got a userid and password from somewhere else." A userid and 
password is nothing. You know who has a userid and password? All of your users. 
Another name for your users is "insider threats."

3. You think your mainframe in darned near invulnerable? Put it to the test.
Hire one of the pen testing firms like RSM or Vanguard. Report back here if 
they find no vulnerabilities. Tell me I'm wrong.

Charles

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

MARKSANDSPENCER.COM

 Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

http://secure-web.cisco.com/1tXrycjZt65r8itxPWtiSpcSBSbgYEO9yEsp-Ju8yXoB2KksloCg6AIzvtjjOC3z6-677n_k-7qjNQnbFVPP3018gggmboywthXztkaL5CShfp5sy2mR9p8qTIffDVc1oysRfrYUi9FIPJYjxSdExj64aVLabgJgai3RXXa_RwOQ0ze8bBRMTO3E7qmIyUDO-2TvtvMJkJckxd5H1VorFY57YAeJgBBKDjlHMhTvZICo1Ke4aepBxXFEAFm5MTYTHwJdEfE9R3lt1Ubn5x6CAFWD-A9wRVbKzrhRduLKz0XtMEzgdrZGhgLrcBRDIJ1QmFrbRXD-1LgoxzGWKy5sChQjempZidX9-AZeQ2n9j-VvYw0NyOxe5ZQsI4HKUmMBFDxJI7jao-nipAzob-BkaN02FIpkscL4F12RJrwiM3mGPR9yq684U3UsPVQAHsFpD/http%3A%2F%2Fwww.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful.

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to 

Re: mainframe hacking "success stories"?

[Anne & Lynn Wheeler]

sipp...@sg.ibm.com (Timothy Sipples) writes:
> Together we sketched a picture of all this on a whiteboard so I could
> understand what they had done. After we drew the picture, I asked this
> simple question: "Is this secure?" After a very little bit of side
> discussion, very quickly, they did two things: (1) they changed their
> "security" policy, and (2) they went immediately to work to change
> everything I just described.

early 80s, I had HSDT project doing T1 (1.5mbits/sec) and faster speed
full-duplex links. IBM internal network was larger than arpanet/internet
from just about the beginning to sometime mid-80s ... and the same
technology was used for the IBM sponsored university BITNET (also larger
than arpanet/internet for a time). It wasn't SNA ... until late 80s when
the communication group was claiming that the internal network would
stop working if not converted to SNA/VTAM ... which occured about the
same time that BITNET converted to TCP/IP.

Corporate also required that all links leaving IBM physical locations
had to be encrypted ... which were external hardware link encryptors
(mid-80s, major hardware link encryptor company claimed that IBM had
over half of all the link encryptors in the world).

On of my problems was I really hated what I had to pay for T1 link
encrptors (a few thousand) and it was really hard to find faster link
encryptors (less of problem for links supported by standard IBM
controllers which were limited to 56kbit links).

I eventually got involved in doing hardware link encryptor that would
cost less than $100 to build and support at least 3mbyte/sec ... with
some other tweaks. Initially the corporate crypto product group said
that it significantly weakened the DES standard. It took me 3months to
figure out how to explain what was happening (it was significantly
stronger than standard DES, & not TDES) ... but it turned out to be a
hollow victory. I was told that I could make as many as I wanted ... but
there was only organization in the world that could use such crypto; i
could make as many as I wanted to, but they all had to be shipped to an
address in Maryland. It was when I realized that there was 3kinds of
crypto in the world: 1) the kind they don't care about, 2) the kind you
can't do and 3) the kind you can only do for them.

Other trivia: doing mainframe DES in the early 80s for a full-duplex T1
required both processors of a dedicated 3081K doing nothing else but
executing standard DES. There was also work on doing public key for
email (PGP-like public key).

Last product we did at IBM was RS/6000 HA/CMP (it originally started out
as HA/6000, but I quickly changed name to HA/CMP when started working
with national labs (technical/scientific) and RDBMS vendors (commercial)
on cluster scaleup. Old reference on Jan1992 meeting in Ellison's
conference room on 128-way cluster scaleup:
http://www.garlic.com/~lynn/95.html#13
within a few weeks of the meeting, cluster scaleup is transferred,
announced as supercomputer (for technical/scientific *ONLY*), and we are
told that we can't work on anything with more than four processors. A
few months later we leave.

Later two of the Oracle people in the Ellison meeting have left and are
at a small client/server startup responsible for something called
"commerce server" and we are brought in as consultants because they want
to do payment transactions on the server, the startup had also invented
this technology they call "SSL" they want to use, the result is now
fequently called "electronic commerce".

I have absolute authority over everything from servers to payment
networks ... and make several tweaks to the HTTPS implementation to
improve integrity and availability ... but can only make recommendations
on the browser/server side ...  some of which are almost immediately
violated ... contributing to problems, some that continue to this day.

Second half 90s, I'm giving presentations on "Why Internet Isn't
Business Critical Dataprocessing" at various internet meetings. Problems
aren't TCP/IP design ... but various glitches in deployments by various
organizations.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: Take cover, it's a student programmer! | Computerworld Shark Tank

[Schuffenhauer, Mark]

You have not punched cards, until you've punched them in the original Klingon.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Wednesday, May 08, 2019 11:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Take cover, it's a student programmer! | Computerworld Shark Tank

On Wed, 8 May 2019 15:39:49 +, Seymour J Metz wrote:

>I don't know where to begin, but it reads like buzzword bingo. How many of the 
>errors can you spot?
>
(link de-cisco-ized):

https://www.computerworld.com/article/3393220/take-cover-it-s-a-student-programmer.html
... Those header cards are punched for four-way symmetry so they can run in 
any direction,
whether backwards or upside down. But they have so many punches that 
they’re almost
lacy in appearance. ...

Ummm ... 2-way symmetry (1<=>80) is easy; punch just 40 columns starting at 
each end.
(12<=>9) harder in EBCDIC -- need to decode binary images (in an exit entered 
for each card).  And if decoding binary, why punch the card symetrically -- let 
software do it.

I once used a site where the job separator cards were brown stock with no 
corner cut; easily spotted by the operator.  No symmetry; needed to be 
correctly oriented with the vendor's EOF code in column 1.

Visual inspection by the operator may have had an adverse consequence.  I once 
got punched output with *one* card punched in wrong orientation.  Best 
explanation:
That card was backward in the hopper and so punched.  Operator separating jobs 
noticed the wrong corner cut and "fixed" it.  I fixed it further by duplicating 
it in correct orientation on a keypunch.

I once made an 81-column card by making minuscule adjustments at the punch 
station.  Reader read 80 columns (FSVO) correctly and ignored the 81st with no 
error indication.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DISCLAIMER: This email and any attachments may contain confidential information 
that is intended solely for use by the intended recipient(s). If you are not 
the intended recipient, you are strictly prohibited from disclosing, copying, 
distributing or using any of the information contained in the communication. If 
you received this email in error, please contact the sender by reply email and 
immediately delete the communication.

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

Re: MODGEN vs AMODGEN

[Mark Zelden]

I would think it is because at one time there was no MODGEN library and JCL all 
pointed to AMODGEN.   Then once MODGEN came into existence people just
added MODGEN and didn't delete AMODGEN to some samples.  Sometimes I still 
see samples pointing only to AMODGEN, so it is actually one of only two DLIB
libraries I have indirectly cataloged with a symbolic that I change at each OS 
upgrade.
I also indirectly catalog SYS1.AMACLIB because some samples have it.

Since MODGEN represents the running system, I don't know why anyone would
want to use AMODGEN instead of MODGEN.  


Best Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/


On Wed, 8 May 2019 06:58:07 +, Vernooij, Kees (ITOP NM) - KLM 
 wrote:

>That is exactly the, intended, difference: APPLIED fixes are on the Tlib, 
>ACCEPTED fixes are also on the Dlib.
>This way you can decide which level of maintenance you will use in your 
>assembly.
>
>Kees.
>
>
>> -Origin l Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Peter
>> Sent: 08 May, 2019 6:40
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: MODGEN vs AMODGEN
>> 
>> Hi
>> 
>> This is just for my knowledge sake.
>> 
>> While assembling a assembler source code I have seen few JCL using MODGEN
>> and AMODGEN sometimes.
>> 
>> Does it really makes any difference between the two ?
>> 
>> To my understanding they are just a target lib and distribution library.
>> 
>> Peter
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>For information, services and offers, please visit our web site: 
>http://www.klm.com. This e-mail and any attachment may contain confidential 
>and privileged material intended for the addressee only. If you are not the 
>addressee, you are notified that no part of the e-mail or any attachment may 
>be disclosed, copied or distributed, and that any other action related to this 
>e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
>received this e-mail by error, please notify the sender immediately by return 
>e-mail, and delete this message.
>
>Koninklijke Luhhtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
>employees shall not be liable for the incorrect or incomplete transmission of 
>this e-mail or any attachments, nor responsible for any delay in receipt.
>Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
>Airlines) is registered in Amstelveen, The Netherlands, with registered number 
>33014286
>
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Take cover, it's a student programmer! | Computerworld Shark Tank

[Paul Gilmartin]

On Wed, 8 May 2019 15:39:49 +, Seymour J Metz wrote:

>I don't know where to begin, but it reads like buzzword bingo. How many of the 
>errors can you spot?
> 
(link de-cisco-ized):

https://www.computerworld.com/article/3393220/take-cover-it-s-a-student-programmer.html
... Those header cards are punched for four-way symmetry so they can run in 
any direction,
whether backwards or upside down. But they have so many punches that 
they’re almost
lacy in appearance. ...

Ummm ... 2-way symmetry (1<=>80) is easy; punch just 40 columns starting at 
each end.
(12<=>9) harder in EBCDIC -- need to decode binary images (in an exit entered 
for each
card).  And if decoding binary, why punch the card symetrically -- let software 
do it.

I once used a site where the job separator cards were brown stock with no 
corner cut;
easily spotted by the operator.  No symmetry; needed to be correctly oriented 
with the
vendor's EOF code in column 1.

Visual inspection by the operator may have had an adverse consequence.  I once 
got
punched output with *one* card punched in wrong orientation.  Best explanation:
That card was backward in the hopper and so punched.  Operator separating jobs
noticed the wrong corner cut and "fixed" it.  I fixed it further by duplicating 
it in
correct orientation on a keypunch.

I once made an 81-column card by making minuscule adjustments at the punch
station.  Reader read 80 columns (FSVO) correctly and ignored the 81st with no
error indication.

-- gil

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

Re: Take cover, it's a student programmer! | Computerworld Shark Tank

[Seymour J Metz]

I don't know where to begin, but it reads like buzzword bingo. How many of the 
errors can you spot?


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


From: IBM Mainframe Discussion List  on behalf of 
Mark Regan 
Sent: Wednesday, May 8, 2019 11:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Fwd: Take cover, it's a student programmer! | Computerworld Shark Tank

It's 1970 and pilot fish is a college junior taking courses in computer
programming. And technology is progressing, as technology does. The school has
just upgraded from an IBM 360/40 mainframe to a much more powerful IBM 360/65.
It orders it with an entire megabyte of magnetic core memory, which adds about
$1 million to its cost, and several disk drives in addition to the usual tape
drives.
.continued at
https://secure-web.cisco.com/15zK_cbp0LUzx4MP97pDnsEPi7NusY71fI6UdF3fM8lZehI4km7ynABssUYVBrnNksLbZIGbj-PNyeuWiToUNn5kf9egb-nAiCRi9RR1i6ThnNfai8zQ3oUz4DlKb2I_Yp4RwATAJULacRWXm-AdzoKK79nJ9rDqZU4KtQxRSC8_YznNKhFsmtpKliSJCuxc8UZomtkGHe4j3lIjJkGrDxs69mWcleXrXLd9EVs3V-ODayXuH0Cahrmsjd6Z1Je4kDiYYFnr2yqQjS_LI55TkDLWE16E59IL43REWVvncgvP0f08AO1vBqHxHWOauVM69ANbLtvF4pZ2SLSKm-W41i51OPVqKNALNYPNHw34M_e1BfdcpVpqA3-SsUpp37P9ooSkvD02c2pxwrncE6JIiYw/https%3A%2F%2Fwww.computerworld.com%2Farticle%2F3393220%2Ftake-cover-it-s-a-student-programm
er.html

Regards,

Mark T. Regan, K8MTR
CTO1 USNR-Retired, 1969-1991
Nationwide Insurance, Retired, 1986-2017




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

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

Re: DR Failover

[Jim IBMMain]

We had worked out "In Theory" how we would do it.  

About 18 months after we opened our second data center, Our Main Data Center 
needed to shutdown over a long weekend, for 100% shutdown power maintenance. 

After the Online's were shutdown Friday Night, We waited for all the DASD & 
Tape to sync to the "other" site, and shut down the site. (100% Powerdown).  We 
then did our "Plan" (Mostly the DR "real" Plan) and brought Powered Down Center 
up in the  sister site, and ran the normal Batch Production workload.  Saturday 
Morning the Online's came up (2hr later then normal), we ran until Monday 
afternoon, when we then shut down the Online's (early, Was a holiday and was 
not a work day but there is limited activity even on S/S/H. Then Ran the Monday 
Night Batch back in the original DataCenter. 

We were prepared to keep production running in one location, if there was a 
issue with the power upgrades until the next weekend (or they fixed it). 

Our Active - Active Servers switched over without any issues, as they were 
suppose to.  (Except the Voip-PBX)

The only issue we noted is the VOIP Did not transfer the active calls to its 
"sister" VOIP/PBX it hung up on the few calls that were in progress, but all 
were able to redial the calls and connect thru its Sister/PBX. 

Few months later we tested the sister site fail over (Test/Dev) to the main 
site and ran for the weekend, "Just for the Fun of it" 

In 2012 Hurricane Sandy took out the Powerlines to the Main DataCenter, The DC 
was running on the Generators but facilities management was not able to get 
more fuel, and we were in danger of running out of fuel, and having to move the 
work load to the sister site, We started to make plans for "When" to do the 
switch,  But we were able to get fuel and did not have to do the movement of 
the workload.

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

Fwd: Take cover, it's a student programmer! | Computerworld Shark Tank

[Mark Regan]

It's 1970 and pilot fish is a college junior taking courses in computer
programming. And technology is progressing, as technology does. The school has
just upgraded from an IBM 360/40 mainframe to a much more powerful IBM 360/65.
It orders it with an entire megabyte of magnetic core memory, which adds about
$1 million to its cost, and several disk drives in addition to the usual tape
drives.
.continued at 
https://www.computerworld.com/article/3393220/take-cover-it-s-a-student-programm
er.html 
 
Regards,
 
Mark T. Regan, K8MTR
CTO1 USNR-Retired, 1969-1991
Nationwide Insurance, Retired, 1986-2017
 
 
 

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

Re: mainframe hacking "success stories"?

[Timothy Sipples]

Carmen Vitullo wrote:
>I'll also add, in spite of being flamed, SNA networks
>we're pretty secure

I'm going to push back on this one a bit, and not in a flaming way I hope.

"Classic" SNA can encrypt connections using DES or TDES, assuming your past
self/selves implemented it (not a given, certainly). That was advanced
stuff for its day and even a little beyond, but the world was/is racing
ahead, properly so. Fortunately, with Enterprise Extender, you can take
advantage of current encryption standards and exploit Crypto Express, too.
(Please do that.)

Several years ago I met a bank's CIO and senior IT leaders. Their view at
the time (and prior) was that SNA was secure, and that newfangled TCP/IP
stuff wasn't. (The Internet was/is scary, after all.) So they adopted a
security policy that "thou shall never implement TCP/IP on the mainframe."
And they didn't; they obeyed their policy faithfully. Of course, business
still needed to get done. Therefore, the bank installed and ran about
20-odd Microsoft Windows servers with Microsoft SNA Server -- remember
that? The SNA Servers did two things: (1) they handled all SNA to/from
TCP/IP traffic, and (2) they handled all authorizations. Yes, that's right,
the bank had effectively disabled RACF entirely because they created 20=odd
RACF IDs for each one of the SNA Servers, and then the SNA Servers
(Windows) had carte blanche to do anything they wanted to do with their
system of record, with core banking data, card data, etc. They delegated
all mainframe authorization decisions to Microsoft Windows.

Together we sketched a picture of all this on a whiteboard so I could
understand what they had done. After we drew the picture, I asked this
simple question: "Is this secure?" After a very little bit of side
discussion, very quickly, they did two things: (1) they changed their
"security" policy, and (2) they went immediately to work to change
everything I just described.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE


E-Mail: sipp...@sg.ibm.com

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

Re: [EXTERNAL] Re: mainframe hacking "success stories"?

[Sankaranarayanan, Vignesh]

I guess the point of contention really is "vULnErAbiliTIeS"...
Words have meaning, a vulnerability is not equal to a loosely 
configured/hardened system.
Of course, I could be wrong but I take the word to mean zero-days or something 
that breaks a module/function, and the way it breaks is exploited for further 
foothold, etc.
An open wound is vulnerable, but not wearing your seatbelt is NOT  a 
vulnerability, it's a risk!
Yes, when the CEO has to issue a public statement it doesn't matter whose turf 
the hole is in, but that doesn't mean common sense goes out the window, and 
suddenly 2 random and unrelated things are equal.

Way too many times, a normal, but potentially dangerous config miss/omission is 
labelled as VULNERABILITY VULNERABILITY VULNERABILITY VULNERABILITY YOUR 
MAINFRAME IS DOOMED, YOUR RACF TEAM IS AN ABSOLUTE ZERO, YOU ARE DONE FOR. 
unless you hire us and we can sort it all out for you.
Everyone's gotta pay bills, sure, but I'm not particularly fond of the kind of 
salesman that creates the demand --just to push their product--... like the 
pen-selling example in the Wolf of Wall Street.
Products are cool, but what's cooler is what people can achieve with vanilla 
stuff.
A beautifully setup piece of REXX/ASM/bunch of scripts on various platforms can 
easily outperform Next Gen security greatness.
Not being completely dismissive of course, but many times, it's easier to stick 
in a product than doing the hard thing, which is to learn to be efficient and 
effective with what you've got.

- Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: 08 May 2019 02:26
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: mainframe hacking "success stories"?

I was travelling and I have kind of lost track of where this thread has gone. 
Let me throw three thoughts out there.

1. Our job is to make our platform -- and if you are at a customer, your site 
-- as secure as reasonably possible. Not "more secure than Windows." It is NOT 
like the joke about the two hunters being chased by a bear, one of whom says "I 
don't have to run faster than the bear; just faster than you."
You have to run faster than ALL the bears.

2. "Oh, but they got a userid and password from somewhere else." A userid and 
password is nothing. You know who has a userid and password? All of your users. 
Another name for your users is "insider threats."

3. You think your mainframe in darned near invulnerable? Put it to the test.
Hire one of the pen testing firms like RSM or Vanguard. Report back here if 
they find no vulnerabilities. Tell me I'm wrong.

Charles

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

MARKSANDSPENCER.COM

 Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful.

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

Re: mainframe hacking "success stories"?

[Rob Scott]

>> Hire one of the pen testing firms like RSM or Vanguard. Report back here if 
>> they find no vulnerabilities. Tell me I'm wrong.

Agree with this 100%.

If you can catch Mark Wilson from RSM in bar, buy him some beers and he can 
tell you redacted stories about pen tests that he has done that will make your 
hair stand on end.

Rob Scott
Rocket Software.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Wednesday, May 8, 2019 2:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

I was travelling and I have kind of lost track of where this thread has gone. 
Let me throw three thoughts out there.

1. Our job is to make our platform -- and if you are at a customer, your site 
-- as secure as reasonably possible. Not "more secure than Windows." It is NOT 
like the joke about the two hunters being chased by a bear, one of whom says "I 
don't have to run faster than the bear; just faster than you."
You have to run faster than ALL the bears.

2. "Oh, but they got a userid and password from somewhere else." A userid and 
password is nothing. You know who has a userid and password? All of your users. 
Another name for your users is "insider threats."

3. You think your mainframe in darned near invulnerable? Put it to the test.
Hire one of the pen testing firms like RSM or Vanguard. Report back here if 
they find no vulnerabilities. Tell me I'm wrong.

Charles

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: [EXTERNAL] Re: mainframe hacking "success stories"?

[Sankaranarayanan, Vignesh]

Another reason for lot of focus on white/black hat focus on USS -- that's what 
most of the non-mainframe world is already familiar with, lower barrier to 
(unauthorized) entry to mainframe.
Don't know if any individual/team has/have  *started* their break-the-mainframe 
journey from core MVS...

– Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mohammad Khan
Sent: 07 May 2019 14:49
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: mainframe hacking "success stories"?

USS is definitely an integral part of z/OS so it's a legitimate mainframe hack. 
However if more of the hacks are occurring via USS it does raise questions 
about its quality from security perspective compared to the "classic" MVS side 
of the mainframe. Buffer overruns are probably the most common exploits in the 
UNIX / C programming environment, did IBM just bring in all its problems as 
well when they implemented OMVS / USS?

MKK

On Mon, 6 May 2019 10:21:25 -0700, Charles Mills  wrote:

>#1: Noo. It was a legitimate mainframe hack (assuming you consider USS a 
>legitimate part of the mainframe, which it has been for 20 years or so). It 
>was an exploit of CGI buffer overrun.
>
>#2: It drives me nuts to hear mainframers explain away mainframe breaches. "It 
>wasn't really a mainframe hack, they got in through USS." "It wasn't really a 
>mainframe hack, they re-used a Windows password." "It wasn't really a 
>mainframe hack ... whatever." If your CEO was standing in front of the press 
>explaining how your company let x million credit card numbers go astray, would 
>it matter HOW they got into your mainframe, or only that they DID?" If your 
>mainframe is vulnerable to a USS hack, or a shared Windows password, or 
>whatever, you need to fix THAT, or risk having to explain to your CEO why he 
>got fired (like Target's) for letting all those credit card numbers go astray.
>
>Charles
>

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

MARKSANDSPENCER.COM

 Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful.

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

Re: MODGEN vs AMODGEN

[Greg Price]

On 2019-05-08 2:39 PM, Peter wrote:

Does it really makes any difference between the two ?


That depends on what maintenance you have applied but not accepted.

I would guess that JCL using AMODGEN in the assembler SYSLIB 
concatenation dates from (or is cloned from JCL that dates from) the 
time when MVS did not have a SYS1.MODGEN data set.


In those days, to be sure to be sure that you were getting the latest 
level of those macros for your system's maintenance level, placing 
SMPMTS ahead of AMODGEN (and AHASPSRC etc. - that is, any macro DLIB 
which did not have a corresponding SYSLIB) was the convention that was 
supposed to be observed, even if it seldom was.


The creation of the relevant macro SYSLIBs such as MODGEN now places 
them on an equal footing with libraries such as MACLIB in that regard.


For practical purposes these days, for assembler SYSLIB DD data sets 
just change all AMODGEN references to MODGEN.


Anyone referenced AGENLIB lately?

:)

Cheers,
Greg

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

Re: MODGEN vs AMODGEN

[Carmen Vitullo]

IIRC like any A library name - they are SMP/E distribution libraries that 
are NOT suppose to be customer modified so you know for a fact AMODGEN is 
'pristine'. 
if you don't modify any source in MODGEN you 'should' be Ok, I'm sure someone 
will correct me if I am wrong. 
thanks 



Carmen Vitullo 

- Original Message -

From: "Peter"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, May 7, 2019 11:39:30 PM 
Subject: MODGEN vs AMODGEN 

Hi 

This is just for my knowledge sake. 

While assembling a assembler source code I have seen few JCL using MODGEN 
and AMODGEN sometimes. 

Does it really makes any difference between the two ? 

To my understanding they are just a target lib and distribution library. 

Peter 

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


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

Re: mainframe hacking "success stories"?

[Bill Johnson]

We did hire a firm to come in and test. They were able to get into the building 
by piggy backing on someone else’s badge. Were able to get into various 
servers, but did not get into the MF.


Sent from Yahoo Mail for iPhone


On Tuesday, May 7, 2019, 9:26 PM, Charles Mills  wrote:

I was travelling and I have kind of lost track of where this thread has
gone. Let me throw three thoughts out there.

1. Our job is to make our platform -- and if you are at a customer, your
site -- as secure as reasonably possible. Not "more secure than Windows." It
is NOT like the joke about the two hunters being chased by a bear, one of
whom says "I don't have to run faster than the bear; just faster than you."
You have to run faster than ALL the bears.

2. "Oh, but they got a userid and password from somewhere else." A userid
and password is nothing. You know who has a userid and password? All of your
users. Another name for your users is "insider threats."

3. You think your mainframe in darned near invulnerable? Put it to the test.
Hire one of the pen testing firms like RSM or Vanguard. Report back here if
they find no vulnerabilities. Tell me I'm wrong.

Charles

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




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

Re: LU name and RACF ID is SMF records

[Wolfgang Fritz]

You should activate the smf119 in tcp/ip
Configure with your necessary subtypes

Bin unterwegs hab nur iPhone zur Verfügung.

> Am 08.05.2019 um 09:26 schrieb Jorge Garcia :
> 
> Hi Wolgfang,
> 
> We don't have SMF records type 119 available in this system
> 
> Thanks
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: COBOL 6.2 and ARCH(12) [EXTERNAL]

[Massimo Biancucci]

Hi,

IMHO I think it's possible but for "pure Application Cobol Coding".

What I mean is that Cobol V6 does produce a load module with instructions
for the requested ARCHLVL you've set.

At runtime, only for called LE routines who accomplish some tasks (eg.
SQUARE ROOT or something like this), it's meaningful and maybe hopeful that
LE "understands" what HW it's running on and uses the best instructions.

Regards.
Max.

Il giorno ven 3 mag 2019 alle ore 23:20 Feller, Paul <
paul.fel...@transamerica.com> ha scritto:

> It is my understanding that if you set the ARCH level to something lower
> than the machine type you are running on it should not use any of the new
> machine instructions.  If what the vendor says is truly what is happening
> then I would think a question to IBM would be in order.
>
> Thanks..
>
> Paul Feller
> AGT Mainframe Technical Support
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Brian Chapman
> Sent: Friday, May 03, 2019 2:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: COBOL 6.2 and ARCH(12) [EXTERNAL]
>
> We have a vendor debugging product that is constantly causing 0C1 and 0C4
> abends since we have upgraded to COBOL 6.2. It also caused these abends
> when we were at COBOL 4,2, but the abend rate has grown considerably after
> the upgrade.
>
> The vendor has produced countless patches, but so far they have not
> resolved the issues. We were notified today that they believe they
> understand the issue. They are stating that even though our COBOL compiler
> is set with ARCH(8) (to support our DRE machine), LE run-time is
> recognizing that the program is COBOL 6.2, running on a z14, and
> automatically switch the ARCH level to ARCH(12). They believe the run-time
> execution is exploiting the new Vector Packed Decimal Facility and
> producing erratic behavior.
>
> I searched through several presentations and IBM manuals for COBOL 6.2,
> and everything I have found states that a recompile with ARCH(12) is
> required to take advantage of the new facility. Is the vendor correct?
>
>
>
> Thank you,
>
> Brian Chapman
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> Please note:  This message originated outside your organization. Please
> use caution when opening links or attachments.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: [EXTERNAL] Re: mainframe hacking "success stories"?

[Sankaranarayanan, Vignesh]

Don't know about shared accounts but I reckon this allows for auditing what 
goes on with privileged AD accounts...

https://blogs.technet.microsoft.com/jepayne/2017/12/08/weffles/

– Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: 07 May 2019 00:07
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: mainframe hacking "success stories"?

> How does one audit for shared Windows passwords, even when they may be 
> encrypted and salted?

Good question.

I guess the answer to this and all similar questions is "MFA". Two factor 
authentication solves a lot of problems, or at least makes them a whole lot 
less likely.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, May 6, 2019 10:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

On Mon, 6 May 2019 10:21:25 -0700, Charles Mills wrote:

>#1: Noo. It was a legitimate mainframe hack (assuming you consider USS a 
>legitimate part of the mainframe, which it has been for 20 years or so). It 
>was an exploit of CGI buffer overrun.
>
Was that Shellshock?  Is only bash susceptible to Shellshock.  That feature is 
so vulnerable that it ought to be withdrawn; reliance on filtering inputs is 
hardly sufficient.

>#2: It drives me nuts to hear mainframers explain away mainframe breaches. "It 
>wasn't really a mainframe hack, they got in through USS." "It wasn't really a 
>mainframe hack, they re-used a Windows password." "It wasn't really a 
>mainframe hack ... whatever." If your CEO was standing in front of the press 
>explaining how your company let x million credit card numbers go astray, would 
>it matter HOW they got into your mainframe, or only that they DID?" If your 
>mainframe is vulnerable to a USS hack, or a shared Windows password, or 
>whatever, you need to fix THAT, or risk having to explain to your CEO why he 
>got fired (like Target's) for letting all those credit card numbers go astray.
>
+1
It doesn't matter.

How does one audit for shared Windows passwords, even when they may be 
encrypted and salted?

-- gil

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

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

MARKSANDSPENCER.COM

 Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful.

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

Re: LU name and RACF ID is SMF records

[Jorge Garcia]

Hi Wolgfang,

 We don't have SMF records type 119 available in this system

Thanks

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

Re: MODGEN vs AMODGEN

[Vernooij, Kees (ITOP NM) - KLM]

That is exactly the, intended, difference: APPLIED fixes are on the Tlib, 
ACCEPTED fixes are also on the Dlib.
This way you can decide which level of maintenance you will use in your 
assembly.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter
> Sent: 08 May, 2019 6:40
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: MODGEN vs AMODGEN
> 
> Hi
> 
> This is just for my knowledge sake.
> 
> While assembling a assembler source code I have seen few JCL using MODGEN
> and AMODGEN sometimes.
> 
> Does it really makes any difference between the two ?
> 
> To my understanding they are just a target lib and distribution library.
> 
> Peter
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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