COPYING PDS AND PDSE

[esmie moo]

Gentle Readers,
Are there special parms that I need to use in the copy PDS & PDSE'S?
For example if I want to copy a PDSE to another PDSE (some maybe LOADLIBS) 
would the following be okay?/*                                             
//COPYJCL1  EXEC PGM=IEBCOPY                   //SYSPRINT DD SYSOUT=*           
              //SYSUT3   DD UNIT=SYSDA,SPACE=(CYL,(50,50))   //SYSUT4   DD 
UNIT=SYSDA,SPACE=(CYL,(50,50))   //INDD     DD DISP=OLD,DSN=MYDSN.CLIP.SHR      
//OUTDD    DD DISP=OLD,DSN=MYDSN.CLIP.SHR.NEW  //SYSIN    DD *                  
                COPY INDD=INDD,OUTDD=OUTDD                   /*                 
                            //                                             
Is the COPY command sufficient?
Thanks in advance

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

Re: COPYING PDS AND PDSE

[Steve Smith]

It's sufficient if it does what you want, no?

sas

On Tue, May 7, 2019 at 7:44 AM esmie moo <
012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote:

> Gentle Readers,
> Are there special parms that I need to use in the copy PDS & PDSE'S?
> For example if I want to copy a PDSE to another PDSE (some maybe LOADLIBS)
> would the following be okay?/*
>  //COPYJCL1  EXEC PGM=IEBCOPY   //SYSPRINT DD SYSOUT=*
>//SYSUT3   DD UNIT=SYSDA,SPACE=(CYL,(50,50))   //SYSUT4
>  DD UNIT=SYSDA,SPACE=(CYL,(50,50))   //INDD DD
> DISP=OLD,DSN=MYDSN.CLIP.SHR  //OUTDDDD
> DISP=OLD,DSN=MYDSN.CLIP.SHR.NEW  //SYSINDD *
>   COPY INDD=INDD,OUTDD=OUTDD   /*
>//
> Is the COPY command sufficient?
> Thanks in advance
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
sas

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

Re: COPYING PDS AND PDSE

[Elardus Engelbrecht]

esmie moo wrote:

>Are there special parms that I need to use in the copy PDS & PDSE'S?

It depends. Do you want to copy all or specific members?


>For example if I want to copy a PDSE to another PDSE (some maybe LOADLIBS) 
>would the following be okay?

PS: I have doctored your JCL sample for better readability! ;-)

//COPYJCL1  EXEC PGM=IEBCOPY   
//SYSPRINT DD SYSOUT=* 
//SYSUT3   DD UNIT=SYSDA,SPACE=(CYL,(50,50))   
//SYSUT4   DD UNIT=SYSDA,SPACE=(CYL,(50,50))   
//INDD DD DISP=OLD,DSN=MYDSN.CLIP.SHR  
//OUTDDDD DISP=OLD,DSN=MYDSN.CLIP.SHR.NEW  
//SYSINDD *
  COPY INDD=INDD,OUTDD=OUTDD   
/* 
// 


>Is the COPY command sufficient?

It should be, a$$uming you want to copy ALL members without any reblocking with 
COPYMOD and that both datasets RECFM, LRECL, BLKSIZE, etc. are the same. 

Perhaps you can drop SYSUT3 and SYSUT4 and add this one:

//SYSOUT   DD SYSOUT=*

Are you getting any error message(s)?

Groete / Greetings
Elardus Engelbrecht

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

Can backup mechanisms be used to steal RACF database? was Re: mainframe hacking "success stories"?

[Clark Morris]

[Default] On 6 May 2019 20:10:27 -0700, in bit.listserv.ibm-main
0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote:

>In most shops only 2 people have the required access to the RACF database. 
>
Could someone use DF/DSS, DF/HSM, FDR or FDR/ABR to copy the database
and then download the dump of the database?

Clark Morris
>
>Sent from Yahoo Mail for iPhone
>
>
>On Monday, May 6, 2019, 11:06 PM, Bob Bridges  wrote:
>
>"Once they’d downloaded the RACF database, they subjected it to a 
>password-cracking tool.  John the Ripper is one such tool, widely available on 
>the internet.  On Feb 28, about the same time the RACF database was 
>downloaded, some questions appeared on the mailing list PaulDotCom about 
>hashing methods for RACF; by March 3rd, apparently in response, John the 
>Ripper had been enhanced to include the capability of working on RACF 
>passwords, in collaboration with another tool call CRACF.
>
>"In the Zauf article is this description:  'Creating a password hash algorithm 
>works like this:  After entering the password, it is padded with spaces, if 
>necessary, to a length of 8 bytes.  Each character is then XORed with x‘55’ 
>and shifted left one bit.  Then the user ID is DES-encrypted, using the 
>modified password as the DES key.  Developers took a few days to determine the 
>algorithm and modify John the Ripper.  Now the utility excels at hashing the 
>RACF database.'  It also mentioned a source-code module named racf2john.c, 'a 
>tool that converts database file exported in the input data, read for JTR' 
>[Google’s translation from Polish].
>
>"By way of testing, investigators attempted to use these tools themselves to 
>crack RACF passwords.  They found that a great many passwords could be 
>extracted, that they were easy to discover by dictionary attack, that they 
>were not very complex and in many cases that they’d been unchanged from the 
>default when the ID was created.  Using a standalone PC they cracked about 30 
>000 passwords (out of 120 000 on Applicat’s database) in  'a couple of days'."
>
>---
>Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
>/* If the Earth were flat, cats would have pushed everything off it by now. */
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Charles Mills
>Sent: Monday, May 6, 2019 13:14
>
>I *believe* that was done by investigators after the fact, attempting to 
>determine how the attack might have been done. I don't recall that there is 
>compelling evidence that Svartholm actually did that.
>
>It *is* trivially easy to do, assuming (a.) read access to the DB and (b.) 
>old-style password storage.
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of David Spiegel
>Sent: Sunday, May 5, 2019 8:02 AM
>
>One of the tricks he pulled was to offload the RACF Database to a PC and 
>Dictionary Attack it.
>
>--
>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: COPYING PDS AND PDSE

[Chris Hoelscher]

Well ... at times when dealing with PDSE I had problems with copy or even 
copymod (I don’t remember what the problems were) - as lonh as the source or 
target was a PDSE, I found COPYGRP the best option

(te problem may have had to do with copying ALIAS , but I am niot 100% sure)

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
Humana Inc.
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 476-2538 or 407-7266


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Elardus Engelbrecht
Sent: Tuesday, May 7, 2019 8:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] COPYING PDS AND PDSE

esmie moo wrote:

>Are there special parms that I need to use in the copy PDS & PDSE'S?

It depends. Do you want to copy all or specific members?


>For example if I want to copy a PDSE to another PDSE (some maybe LOADLIBS) 
>would the following be okay?

PS: I have doctored your JCL sample for better readability! ;-)

//COPYJCL1  EXEC PGM=IEBCOPY   
//SYSPRINT DD SYSOUT=* 
//SYSUT3   DD UNIT=SYSDA,SPACE=(CYL,(50,50))   
//SYSUT4   DD UNIT=SYSDA,SPACE=(CYL,(50,50))   
//INDD DD DISP=OLD,DSN=MYDSN.CLIP.SHR  
//OUTDDDD DISP=OLD,DSN=MYDSN.CLIP.SHR.NEW  
//SYSINDD *
  COPY INDD=INDD,OUTDD=OUTDD   
/* 
// 


>Is the COPY command sufficient?

It should be, a$$uming you want to copy ALL members without any reblocking with 
COPYMOD and that both datasets RECFM, LRECL, BLKSIZE, etc. are the same. 

Perhaps you can drop SYSUT3 and SYSUT4 and add this one:

//SYSOUT   DD SYSOUT=*

Are you getting any error message(s)?

Groete / Greetings
Elardus Engelbrecht

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

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil rights 
laws and
do not discriminate on the basis of race, color, national origin, age, 
disability, sex,
sexual orientation, gender identity, or religion. Humana Inc. and its 
subsidiaries do not
exclude people or treat them differently because of race, color, national 
origin, age,
disability, sex, sexual orientation, gender identity, or religion.

English: ATTENTION: If you do not speak English, language assistance services, 
free
of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios
gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711).

繁體中文(Chinese)：注意：如果您使用繁體中文，您可以免費獲得語言援助
服務。請致電 1‐877‐320‐1235 (TTY: 711)。

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis 
èd
pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711).

Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej
pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711).

한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로
이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.


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

[Carmen Vitullo]

I'll also add, in spite of being flamed, SNA networks we're pretty secure, it 
wasn't till TCP/IP and OPENMVS that we started having to rethink security I 
know SNA was not 100% secure but that's why VTAM messages were scrutinized by 
operators, sysprogs , automation and security, you don't see that level of 
logging in an open environment. I can view my PC's logging, but it's usually 
after the fact it is viewed. 
and to Tom's point there not fixing stupid, I worked for an outsourcer that 
also sanitized and collected bank and credit reporting agencies data and sold 
this data to anyone in the need, a salesman had all Credit bureau data on his 
laptop, he left that laptop in an unsecure conference room, that laptop was 
stolen and all customer data was stolen, that led to this company encrypting 
all company laptop hard drives, and a nice lawsuit to boot 




Carmen Vitullo 

- Original Message -

From: "Tom Brennan"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, May 7, 2019 12:09:37 AM 
Subject: Re: mainframe hacking "success stories"? 

For the mainframe, one of the words I like to use is "Integrity". The 
hardware designers and programmers did not want to let any error, no 
matter how small, go unnoticed. A quick example: On a real 3278 
terminal if you tried to type on top of a protected field, the box made 
a clicky noise and locked the keyboard from further input until you 
pressed Reset. This is Integrity, protecting the data entry clerk from 
missing even a single character on that COBOL coding form. 

Same with the OS of course - with all the logging and SMF and error 
recovery and message manuals a mile long. You don't see anything close 
to this in Windows and Linux/Unix. In fact, on those platforms it's 
sometimes the opposite... Call a subroutine, forget to check the return 
code, and the program continues on as if nothing happened - good luck. 
On the mainframe, if I call an SVC and it fails I get an abend by 
default with a decent message. That's just one small part of the 
built-in integrity the mainframe has over the other platforms. 

One of my old jokes working with Unix/Linux was: If you got an error 
that makes no sense, check to see if the disk ran out of space. I was 
surprised how often this turned out to be true. 

Over the years one of the bigger Windows/Unix hacks has been buffer 
overflows, I believe based on string copies with no supplied length (you 
keep copying bytes until you hit a zero). But variable fields on the 
mainframe typically had a length byte or halfword - so we avoided one of 
the bigger hacking issues. Well, until USS came along and C started 
being used for mainframe coding. 

But this all makes no difference when you find passwords.txt on a 
sysprog's laptop because the security folks decided the password needs 
to be changed each month to something impossible to remember. That's 
more the point I'm trying to make. 

On 5/6/2019 6:52 PM, Bill Johnson wrote: 
> A plethora of reasons. 
> Lack of emphasis on security by MSFT. More interest in selling the next 
> release than securing each release. 
> Buggy code. Went to a security seminar once where it was stated that MSFT 
> code had one bug for every 25 lines of code. IBM was around one bug every 250 
> lines and NASA was one bug every 10,000 lines. Called KLOC. 
> MSFT is also more available. There are millions of possible targets. That’s 
> why Safari was less exposed to hack than IE. IE had a much larger install 
> base so was more targeted. 
> Many other reasons. 
> Hackers tend to target the easier platform. 
> 
> 
> Sent from Yahoo Mail for iPhone 
> 
> 
> On Monday, May 6, 2019, 9:27 PM, Tom Brennan  
> wrote: 
> 
> Ok, but why is Windows easier to hack than the mainframe? 
> 
> Personally, I'd find a mainframe far easier to hack because I know a 
> little bit about control blocks, APF auth, SVC's, subsystems, address 
> spaces, RACF, etc., and I know far less about the equivalents on 
> Windows. But of course the first step is to get any kind of userid, and 
> that's done by pretty-much the same methods - regardless of platform. 
> 
> On 5/6/2019 1:18 PM, Bill Johnson wrote: 
>> It’s why banks stay on the mainframe. Security. 
>> 
>> 
>> Sent from Yahoo Mail for iPhone 
>> 
>> 
>> On Monday, May 6, 2019, 4:09 PM, Bigendian Smalls 
>>  wrote: 
>> 
>> Bill, would you care to back that sweeping generalization up with some 
>> detail? 
>> 
>>> On May 6, 2019, at 22:06, Bill Johnson 
>>> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: 
>>> 
>>> Completely different. Hacking Microsoft is way easier. 
>>> 
>>> 
>>> Sent from Yahoo Mail for iPhone 
>>> 
>>> 
>>> On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls 
>>>  wrote: 
>>> 
>>> Which is how 80% of all the hacks today start. Find purchase and advance 
>>> your position. This is how the game is played. It was as classic of a hack 
>>> as anything today. 
>>> 
 On May 6, 2019, at 21:43, Bill Johnson 
 <0047540adefe-dmarc-requ...

LU name and RACF ID is SMF records

[Jorge Garcia]

Hi all,

 We want to obtain LU name and RACF ID associated from SMF records or anyother 
source. We don't have available SMF record type 33. This LU name is available 
in TELNET profile 

LUGROUP LUMAJ 
T900D001..T900D030

We don't know if there is some SMF records with the information of LU name, 
RACF ID and IP. We've executed test with SMF record 118 and 119 but we haven't 
obtain sucess. 

Please, could you give us some advice to obtain this information?

Jorge Garcia Juanino
Coordinador sistemas z/OS
ACTP – DIAC – Operación y Soporte EMEA
MAPFRE 
Avenida del Talgo 100-103 – 3ª Planta
CP 28023 Madrid
Tel. 91 581 27 34, Movil 618333559 
jgarc...@mapfre.com

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

[ITschak Mugzach]

Funny credit card story. Here in Israel, a company had all cc on an
encrypted hd. The person used the desktop took the hd home, booted from the
hd and copied all data. Then, from Thailand, he tried to blackmail his
employee.

What value encryption offers in this vase?

בתאריך יום ג׳, 7 במאי 2019, 15:49, מאת Carmen Vitullo ‏:

> I'll also add, in spite of being flamed, SNA networks we're pretty secure,
> it wasn't till TCP/IP and OPENMVS that we started having to rethink
> security I know SNA was not 100% secure but that's why VTAM messages were
> scrutinized by operators, sysprogs , automation and security, you don't see
> that level of logging in an open environment. I can view my PC's logging,
> but it's usually after the fact it is viewed.
> and to Tom's point there not fixing stupid, I worked for an outsourcer
> that also sanitized and collected bank and credit reporting agencies data
> and sold this data to anyone in the need, a salesman had all Credit bureau
> data on his laptop, he left that laptop in an unsecure conference room,
> that laptop was stolen and all customer data was stolen, that led to this
> company encrypting all company laptop hard drives, and a nice lawsuit to
> boot
>
>
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Tom Brennan" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Tuesday, May 7, 2019 12:09:37 AM
> Subject: Re: mainframe hacking "success stories"?
>
> For the mainframe, one of the words I like to use is "Integrity". The
> hardware designers and programmers did not want to let any error, no
> matter how small, go unnoticed. A quick example: On a real 3278
> terminal if you tried to type on top of a protected field, the box made
> a clicky noise and locked the keyboard from further input until you
> pressed Reset. This is Integrity, protecting the data entry clerk from
> missing even a single character on that COBOL coding form.
>
> Same with the OS of course - with all the logging and SMF and error
> recovery and message manuals a mile long. You don't see anything close
> to this in Windows and Linux/Unix. In fact, on those platforms it's
> sometimes the opposite... Call a subroutine, forget to check the return
> code, and the program continues on as if nothing happened - good luck.
> On the mainframe, if I call an SVC and it fails I get an abend by
> default with a decent message. That's just one small part of the
> built-in integrity the mainframe has over the other platforms.
>
> One of my old jokes working with Unix/Linux was: If you got an error
> that makes no sense, check to see if the disk ran out of space. I was
> surprised how often this turned out to be true.
>
> Over the years one of the bigger Windows/Unix hacks has been buffer
> overflows, I believe based on string copies with no supplied length (you
> keep copying bytes until you hit a zero). But variable fields on the
> mainframe typically had a length byte or halfword - so we avoided one of
> the bigger hacking issues. Well, until USS came along and C started
> being used for mainframe coding.
>
> But this all makes no difference when you find passwords.txt on a
> sysprog's laptop because the security folks decided the password needs
> to be changed each month to something impossible to remember. That's
> more the point I'm trying to make.
>
> On 5/6/2019 6:52 PM, Bill Johnson wrote:
> > A plethora of reasons.
> > Lack of emphasis on security by MSFT. More interest in selling the next
> release than securing each release.
> > Buggy code. Went to a security seminar once where it was stated that
> MSFT code had one bug for every 25 lines of code. IBM was around one bug
> every 250 lines and NASA was one bug every 10,000 lines. Called KLOC.
> > MSFT is also more available. There are millions of possible targets.
> That’s why Safari was less exposed to hack than IE. IE had a much larger
> install base so was more targeted.
> > Many other reasons.
> > Hackers tend to target the easier platform.
> >
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Monday, May 6, 2019, 9:27 PM, Tom Brennan 
> wrote:
> >
> > Ok, but why is Windows easier to hack than the mainframe?
> >
> > Personally, I'd find a mainframe far easier to hack because I know a
> > little bit about control blocks, APF auth, SVC's, subsystems, address
> > spaces, RACF, etc., and I know far less about the equivalents on
> > Windows. But of course the first step is to get any kind of userid, and
> > that's done by pretty-much the same methods - regardless of platform.
> >
> > On 5/6/2019 1:18 PM, Bill Johnson wrote:
> >> It’s why banks stay on the mainframe. Security.
> >>
> >>
> >> Sent from Yahoo Mail for iPhone
> >>
> >>
> >> On Monday, May 6, 2019, 4:09 PM, Bigendian Smalls <
> mainfr...@bigendiansmalls.com> wrote:
> >>
> >> Bill, would you care to back that sweeping generalization up with some
> detail?
> >>
> >>> On May 6, 2019, at 22:06, Bill Johnson <
> 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
> >>>
> >>> Complete

Re: COPYING PDS AND PDSE

[esmie moo]

 I want to copy the PDSE to another.  I was told that COPYMOD was the 
preferable parm when copying LOADLIBS.  Is it okay just to use COPY?
On Tuesday, May 7, 2019, 8:09:09 a.m. EDT, Elardus Engelbrecht 
 wrote:  
 
 esmie moo wrote:

>Are there special parms that I need to use in the copy PDS & PDSE'S?

It depends. Do you want to copy all or specific members?


>For example if I want to copy a PDSE to another PDSE (some maybe LOADLIBS) 
>would the following be okay?

PS: I have doctored your JCL sample for better readability! ;-)

//COPYJCL1  EXEC PGM=IEBCOPY                  
//SYSPRINT DD SYSOUT=*                        
//SYSUT3  DD UNIT=SYSDA,SPACE=(CYL,(50,50))  
//SYSUT4  DD UNIT=SYSDA,SPACE=(CYL,(50,50))  
//INDD    DD DISP=OLD,DSN=MYDSN.CLIP.SHR      
//OUTDD    DD DISP=OLD,DSN=MYDSN.CLIP.SHR.NEW  
//SYSIN    DD *                                
  COPY INDD=INDD,OUTDD=OUTDD                  
/*                                            
//        


>Is the COPY command sufficient?

It should be, a$$uming you want to copy ALL members without any reblocking with 
COPYMOD and that both datasets RECFM, LRECL, BLKSIZE, etc. are the same. 

Perhaps you can drop SYSUT3 and SYSUT4 and add this one:

//SYSOUT  DD SYSOUT=*

Are you getting any error message(s)?

Groete / Greetings
Elardus Engelbrecht

--
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: COPYING PDS AND PDSE

[esmie moo]

 Yes.  I want to perform a PDSE to PDSE copy.
On Tuesday, May 7, 2019, 7:59:47 a.m. EDT, Steve Smith  
wrote:  
 
 It's sufficient if it does what you want, no?

sas

On Tue, May 7, 2019 at 7:44 AM esmie moo <
012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote:

> Gentle Readers,
> Are there special parms that I need to use in the copy PDS & PDSE'S?
> For example if I want to copy a PDSE to another PDSE (some maybe LOADLIBS)
> would the following be okay?/*
>  //COPYJCL1  EXEC PGM=IEBCOPY                  //SYSPRINT DD SYSOUT=*
>                    //SYSUT3  DD UNIT=SYSDA,SPACE=(CYL,(50,50))  //SYSUT4
>  DD UNIT=SYSDA,SPACE=(CYL,(50,50))  //INDD    DD
> DISP=OLD,DSN=MYDSN.CLIP.SHR      //OUTDD    DD
> DISP=OLD,DSN=MYDSN.CLIP.SHR.NEW  //SYSIN    DD *
>      COPY INDD=INDD,OUTDD=OUTDD                  /*
>                        //
> Is the COPY command sufficient?
> Thanks in advance
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
sas

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

[Phil Smith III]

ITschak Mugzach wrote:

>Funny credit card story. Here in Israel, a company had all cc on an

>encrypted hd. The person used the desktop took the hd home, booted from the

>hd and copied all data. Then, from Thailand, he tried to blackmail his

>employee.

 

>What value encryption offers in this vase?

 

Indeed. This is why whole-disk (and, in most cases, whole-file and 
whole-database) encryption offers very little actual protection. 
Application-level encryption is much more secure…

 

…phsiii


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

[Carmen Vitullo]

agree, somewhat, in this case the PC/laptop needed to contact the company key 
encryption server @ boot up to validate, this was a little more than encrypting 
the drive, if the server was not contacted periodically or @ boot up, the 
laptop would not boot. I don't know what would happen if you removed the drive, 
I'm sure the drive, in this case would be worthless. 
when 'my position was eliminated' I had my laptop at home, it would not boot 
because I was not able to contact the companies network and encryption server. 




Carmen Vitullo 

- Original Message -

From: "Phil Smith III"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, May 7, 2019 8:21:24 AM 
Subject: Re: mainframe hacking "success stories"? 

ITschak Mugzach wrote: 

>Funny credit card story. Here in Israel, a company had all cc on an 

>encrypted hd. The person used the desktop took the hd home, booted from the 

>hd and copied all data. Then, from Thailand, he tried to blackmail his 

>employee. 



>What value encryption offers in this vase? 



Indeed. This is why whole-disk (and, in most cases, whole-file and 
whole-database) encryption offers very little actual protection. 
Application-level encryption is much more secure… 



…phsiii 


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

[Mohammad Khan]

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

Metal-C exits

[scott Ford]

All:

Has anyone seen or can point me to where IBM provides some guidelines for
doing exit work in Metal-C ?  I saw an article on Developerworks and was
wondering if i could address some of our exits issues easier on Metal C.



-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

mainframe hacking "success stories"?

[Nightwatch RenBand]

Publishing "success stories" is a two edged sword.  Don't and other
installations cannot protect against the attach. Do and you spread the idea
among the bad guys.
It would seem that the best solution is:
1) Only discuss with people who have clearances and a "need to know",
2) Come up with a fix immediately
3) Put the fix in required maintenance and require that installations stay
current.  Never mention what is in the fix.
Of course this great power to the vendor comes with great responsibility.
(thanks, Stan Lee)

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

On the flip side, I bet there are many folks who were prompted to check 
their systems when they saw Phil Young's "Soldier of Fortran" web pages.


On 5/7/2019 7:49 AM, Nightwatch RenBand wrote:

Publishing "success stories" is a two edged sword.  Don't and other
installations cannot protect against the attach. Do and you spread the idea
among the bad guys.
It would seem that the best solution is:
1) Only discuss with people who have clearances and a "need to know",
2) Come up with a fix immediately
3) Put the fix in required maintenance and require that installations stay
current.  Never mention what is in the fix.
Of course this great power to the vendor comes with great responsibility.
(thanks, Stan Lee)

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

[Jousma, David]

That is *exactly* how IBM handles it for z/OS.  I am one of two people at my 
location with access to the ResourceLink security portal.   You ever wonder why 
you go looking for the APAR info for a PTF, and you get a "document not found" 
type of error?   When we are actively applying maintenance, I pull down the 
SECINT SMPE ++ASSIGN data, so that I can select and apply PTF's that have 
security vulnerability implications.

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Nightwatch RenBand
Sent: Tuesday, May 7, 2019 10:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: mainframe hacking "success stories"?

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Publishing "success stories" is a two edged sword.  Don't and other 
installations cannot protect against the attach. Do and you spread the idea 
among the bad guys.
It would seem that the best solution is:
1) Only discuss with people who have clearances and a "need to know",
2) Come up with a fix immediately
3) Put the fix in required maintenance and require that installations stay 
current.  Never mention what is in the fix.
Of course this great power to the vendor comes with great responsibility.
(thanks, Stan Lee)

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Re: BLKSIZE=0 (was: Crazy ...)

[Tom Marchant]

On Mon, 6 May 2019 21:10:04 -0400, Steve Thompson wrote:

>What about BUFL=? As I recall, I used to use this to keep from
>having problems with concatenations...

Yes, until about 25 years ago, when the requirement that the first 
data set of a partitioned data set concatenation have the largest 
BLKSIZE was removed.

-- 
Tom Marchant

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

Re: BLKSIZE=0 (was: Crazy ...)

[Tom Marchant]

On Mon, 6 May 2019 18:52:51 -0400, Steve Smith wrote:

>BLKSIZE=0 requests "System-Determined Block size".  It is indeed the best
>option.  Presumably the "system" has all the relevant facts and knowledge
>at its disposal.  Which is likely at least as much as you know.

When a new data set is created without specifying BLKSIZE, and written to 
by the binder, the data set ends up with BLKSIZE=32760. I just ran a test 
on z/OS 2.3, and there was no DATACLAS involved.

I don't know whether it was set by DFSMA or by the Binder.

-- 
Tom Marchant

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

[Grant Taylor]

On 5/7/19 6:49 AM, Carmen Vitullo wrote:

SNA networks we're pretty secure


I question how much of that ""security was the (largely) closed 
ecosystem.  As in it required different hardware, most of which wasn't 
easily available or inexpensive.


I think Bigendian Smalls and / or Soldier of Fortran have done multiple 
presentations on how insecure SNA was.  Particularly how easy it is to 
subvert the protected fields by ignoring ~> altering the protection 
status when returning the screen to the mainframe.


IMHO any time you rely on the client to behave properly for anything 
security related, you've got a security problem.


I have likened this to an HTML FORM that has a field set to disabled.

I guess there is room for doing this on purpose as a trap to see if 
someone is monkeying with things.  Sort of a litmus test to see if 
anything protected is modified.  But that's contrary to the 
presentations that I've heard.


it wasn't till TCP/IP and OPENMVS that we started having to rethink 
security


Was TCP/IP itself the problem?  Or was it the fact that TCP/IP provided 
a way for different systems, not directly associated with the mainframe 
to connect and / or the introduction of a new subsystem, OpenMVS, and an 
entirely new ecosystem of methodologies & unknowns that turned into 
vulnerabilities?


Is it possible that X.25 network connections to channel attached SNA 
controllers / concentrators could have also introduced the first of the 
two problems above?


Was OSI Networking ever a thing on the mainframe?  Would it have also 
allowed other remote connections?


By "other remote connections" is providing a communications path to the 
mainframe from devices that would be outside of the (inverted tree) with 
everything subservient to the mainframe.  As in something that wasn't 
directly related to the mainframe now had a communications path to the 
mainframe.




--
Grant. . . .
unix || die

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

Re: BLKSIZE=0 (was: Crazy ...)

[Seymour J Metz]

Well, removed except when it wasn't; there were caveats.

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


From: IBM Mainframe Discussion List  on behalf of Tom 
Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, May 7, 2019 11:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BLKSIZE=0 (was: Crazy ...)

On Mon, 6 May 2019 21:10:04 -0400, Steve Thompson wrote:

>What about BUFL=? As I recall, I used to use this to keep from
>having problems with concatenations...

Yes, until about 25 years ago, when the requirement that the first
data set of a partitioned data set concatenation have the largest
BLKSIZE was removed.

--
Tom Marchant

--
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: COPYING PDS AND PDSE

[Seymour J Metz]

COPYMOD is for load module reblocking. There are no load modules in a PDSE. Off 
the top of my head I don't even recall whether it is valid for program objects. 
The COPY statement should work fine for PDSE.


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


From: IBM Mainframe Discussion List  on behalf of 
esmie moo <012780d99c7b-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, May 7, 2019 9:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COPYING PDS AND PDSE

 I want to copy the PDSE to another.  I was told that COPYMOD was the 
preferable parm when copying LOADLIBS.  Is it okay just to use COPY?
On Tuesday, May 7, 2019, 8:09:09 a.m. EDT, Elardus Engelbrecht 
 wrote:

 esmie moo wrote:

>Are there special parms that I need to use in the copy PDS & PDSE'S?

It depends. Do you want to copy all or specific members?


>For example if I want to copy a PDSE to another PDSE (some maybe LOADLIBS) 
>would the following be okay?

PS: I have doctored your JCL sample for better readability! ;-)

//COPYJCL1  EXEC PGM=IEBCOPY
//SYSPRINT DD SYSOUT=*
//SYSUT3  DD UNIT=SYSDA,SPACE=(CYL,(50,50))
//SYSUT4  DD UNIT=SYSDA,SPACE=(CYL,(50,50))
//INDDDD DISP=OLD,DSN=MYDSN.CLIP.SHR
//OUTDDDD DISP=OLD,DSN=MYDSN.CLIP.SHR.NEW
//SYSINDD *
  COPY INDD=INDD,OUTDD=OUTDD
/*
//


>Is the COPY command sufficient?

It should be, a$$uming you want to copy ALL members without any reblocking with 
COPYMOD and that both datasets RECFM, LRECL, BLKSIZE, etc. are the same.

Perhaps you can drop SYSUT3 and SYSUT4 and add this one:

//SYSOUT  DD SYSOUT=*

Are you getting any error message(s)?

Groete / Greetings
Elardus Engelbrecht

--
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: [EXTERNAL MESSAGE] Re: COPYING PDS AND PDSE

[Blake, Daniel J [CTR]]

Shmuel,

I'm not sure what you mean by your statement > There are no load modules in a 
PDSE. <

 Data Set Information
Command ===>

Data Set Name  . . . : TCPIP.SEZALOAD

General DataCurrent Allocation
 Management class . . : **None**Allocated tracks  . :   2,963
 Storage class  . . . : **None**Allocated extents . :   1
  Volume serial . . . : xx  Maximum dir. blocks :   NOLIMIT
  Device type . . . . : 3390
 Data class . . . . . : **None**
  Organization  . . . : PO  Current Utilization
  Record format . . . : U   Used pages  . . . . :   29,397
  Record length . . . : 0   % Utilized  . . . . :   82
  Block size  . . . . : 32760   Number of members . : 306
  1st extent tracks . : 2963
  Secondary tracks  . : 270
  Data set name type  : LIBRARY Dates
  Data set version  . : 1   Creation date . . . :   
2018/01/31
Referenced date . . :   
2019/05/07
Expiration date . . :   
***None***


;-D an 



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Tuesday, May 07, 2019 11:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL MESSAGE] Re: COPYING PDS AND PDSE

COPYMOD is for load module reblocking. There are no load modules in a PDSE. Off 
the top of my head I don't even recall whether it is valid for program objects. 
The COPY statement should work fine for PDSE.


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


From: IBM Mainframe Discussion List  on behalf of 
esmie moo <012780d99c7b-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, May 7, 2019 9:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COPYING PDS AND PDSE

 I want to copy the PDSE to another.  I was told that COPYMOD was the 
preferable parm when copying LOADLIBS.  Is it okay just to use COPY?
On Tuesday, May 7, 2019, 8:09:09 a.m. EDT, Elardus Engelbrecht 
 wrote:

 esmie moo wrote:

>Are there special parms that I need to use in the copy PDS & PDSE'S?

It depends. Do you want to copy all or specific members?


>For example if I want to copy a PDSE to another PDSE (some maybe LOADLIBS) 
>would the following be okay?

PS: I have doctored your JCL sample for better readability! ;-)

//COPYJCL1  EXEC PGM=IEBCOPY
//SYSPRINT DD SYSOUT=*
//SYSUT3  DD UNIT=SYSDA,SPACE=(CYL,(50,50))
//SYSUT4  DD UNIT=SYSDA,SPACE=(CYL,(50,50))
//INDDDD DISP=OLD,DSN=MYDSN.CLIP.SHR
//OUTDDDD DISP=OLD,DSN=MYDSN.CLIP.SHR.NEW
//SYSINDD *
  COPY INDD=INDD,OUTDD=OUTDD
/*
//


>Is the COPY command sufficient?

It should be, a$$uming you want to copy ALL members without any reblocking with 
COPYMOD and that both datasets RECFM, LRECL, BLKSIZE, etc. are the same.

Perhaps you can drop SYSUT3 and SYSUT4 and add this one:

//SYSOUT  DD SYSOUT=*

Are you getting any error message(s)?

Groete / Greetings
Elardus Engelbrecht

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

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

Re: [EXTERNAL MESSAGE] Re: COPYING PDS AND PDSE

[Mark Jacobs]

They're called program objects in a PDS/e

Mark Jacobs


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Tuesday, May 7, 2019 11:50 AM, Blake, Daniel J [CTR] 
<00f1be92566d-dmarc-requ...@listserv.ua.edu> wrote:

> Shmuel,
>
> I'm not sure what you mean by your statement > There are no load modules in a 
> PDSE. <
>
> Data Set Information
> Command ===>
>
> Data Set Name . . . : TCPIP.SEZALOAD
>
> General Data Current Allocation
> Management class . . : None Allocated tracks . : 2,963
> Storage class . . . : None Allocated extents . : 1
> Volume serial . . . : xx Maximum dir. blocks : NOLIMIT
> Device type . . . . : 3390
> Data class . . . . . : None
> Organization . . . : PO Current Utilization
> Record format . . . : U Used pages . . . . : 29,397
> Record length . . . : 0 % Utilized . . . . : 82
> Block size . . . . : 32760 Number of members . : 306
> 1st extent tracks . : 2963
> Secondary tracks . : 270
> Data set name type : LIBRARY Dates
> Data set version . : 1 Creation date . . . : 2018/01/31
> Referenced date . . : 2019/05/07
> Expiration date . . : None
>
> ;-D an
>
> -Original Message-
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of 
> Seymour J Metz
>
> Sent: Tuesday, May 07, 2019 11:40 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL MESSAGE] Re: COPYING PDS AND PDSE
>
> COPYMOD is for load module reblocking. There are no load modules in a PDSE. 
> Off the top of my head I don't even recall whether it is valid for program 
> objects. The COPY statement should work fine for PDSE.
>
>
> ---
>
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of 
> esmie moo 012780d99c7b-dmarc-requ...@listserv.ua.edu
> Sent: Tuesday, May 7, 2019 9:15 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COPYING PDS AND PDSE
>
> I want to copy the PDSE to another. I was told that COPYMOD was the 
> preferable parm when copying LOADLIBS. Is it okay just to use COPY?
> On Tuesday, May 7, 2019, 8:09:09 a.m. EDT, Elardus Engelbrecht 
> elardus.engelbre...@sita.co.za wrote:
>
> esmie moo wrote:
>
> > Are there special parms that I need to use in the copy PDS & PDSE'S?
>
> It depends. Do you want to copy all or specific members?
>
> > For example if I want to copy a PDSE to another PDSE (some maybe LOADLIBS) 
> > would the following be okay?
>
> PS: I have doctored your JCL sample for better readability! ;-)
>
> //COPYJCL1 EXEC PGM=IEBCOPY
> //SYSPRINT DD SYSOUT=*
> //SYSUT3 DD UNIT=SYSDA,SPACE=(CYL,(50,50))
> //SYSUT4 DD UNIT=SYSDA,SPACE=(CYL,(50,50))
> //INDD DD DISP=OLD,DSN=MYDSN.CLIP.SHR
> //OUTDD DD DISP=OLD,DSN=MYDSN.CLIP.SHR.NEW
> //SYSIN DD *
> COPY INDD=INDD,OUTDD=OUTDD
> /*
> //
>
> > Is the COPY command sufficient?
>
> It should be, a$$uming you want to copy ALL members without any reblocking 
> with COPYMOD and that both datasets RECFM, LRECL, BLKSIZE, etc. are the same.
>
> Perhaps you can drop SYSUT3 and SYSUT4 and add this one:
>
> //SYSOUT DD SYSOUT=*
>
> Are you getting any error message(s)?
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
>
> 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
>
> ---
>
> 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 / arc

Re: BLKSIZE=0 (was: Crazy ...)

[Paul Gilmartin]

On Tue, 7 May 2019 15:33:39 +, Seymour J Metz wrote:

>Well, removed except when it wasn't; there were caveats.
>
  ???
>
>From: Tom Marchant 
>Sent: Tuesday, May 7, 2019 11:02 AM
>
>>What about BUFL=? As I recall, I used to use this to keep from
>>having problems with concatenations...
>
>Yes, until about 25 years ago, when the requirement that the first
>data set of a partitioned data set concatenation have the largest
>BLKSIZE was removed.
>
Silly (naive?) me.  I just coded an overriding BLKSIZE on the first
catenand. Or supplied a leading empty temp DSN with suitable attributes.
Would that satisfy the "caveats"?

Same for LRECL.

-- gil

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

Re: [EXTERNAL MESSAGE] Re: COPYING PDS AND PDSE

[Paul Gilmartin]

On Tue, 7 May 2019 15:50:51 +, Blake, Daniel J [CTR] wrote:

>Shmuel,
>
>I'm not sure what you mean by your statement > There are no load modules in a 
>PDSE. <
>
Those 306 members are not load modules.

> Data Set Information
>Command ===>
>
>Data Set Name  . . . : TCPIP.SEZALOAD
>
>General Data   Current Allocation
> Management class . . :**None**Allocated tracks  . :   2,963
> Storage class  . . . :**None**Allocated extents . :   1
>  Volume serial . . . :xx  Maximum dir. blocks :   NOLIMIT
>  Device type . . . . :3390
> Data class . . . . . :**None**
>  Organization  . . . :PO  Current Utilization
>  Record format . . . :U   Used pages  . . . . :   29,397
>  Record length . . . :0   % Utilized  . . . . :   82
>  Block size  . . . . :32760   Number of members . : 306
>  1st extent tracks . :2963
>  Secondary tracks  . :270
>  Data set name type  :LIBRARY Dates
>  Data set version  . : 1  Creation date . . . :   
> 2018/01/31
>   Referenced date 
> . . :   2019/05/07
>   Expiration date 
> . . :   ***None***

-- gil

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

Re: [EXTERNAL MESSAGE] Re: COPYING PDS AND PDSE

[Mark Zelden]

On Tue, 7 May 2019 15:54:19 +, Mark Jacobs  
wrote:

>They're called program objects in a PDS/e
 ^
  PDSE

Pedants unite! ;-) 


>
>Mark Jacobs
>
>
>Sent from ProtonMail, Swiss-based encrypted email.
>
>GPG Public Key - 
>https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com
>
>‐‐‐ Original Message ‐‐‐
>On Tuesday, May 7, 2019 11:50 AM, Blake, Daniel J [CTR] 
><00f1be92566d-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Shmuel,
>>
>> I'm not sure what you mean by your statement > There are no load modules in 
>> a PDSE. <
>>
>> Data Set Information
>> Command ===>
>>
>> Data Set Name . . . : TCPIP.SEZALOAD
>>
>> General Data Current Allocation
>> Management class . . : None Allocated tracks . : 2,963
>> Storage class . . . : None Allocated extents . : 1
>> Volume serial . . . : xx Maximum dir. blocks : NOLIMIT
>> Device type . . . . : 3390
>> Data class . . . . . : None
>> Organization . . . : PO Current Utilization
>> Record format . . . : U Used pages . . . . : 29,397
>> Record length . . . : 0 % Utilized . . . . : 82
>> Block size . . . . : 32760 Number of members . : 306
>> 1st extent tracks . : 2963
>> Secondary tracks . : 270
>> Data set name type : LIBRARY Dates
>> Data set version . : 1 Creation date . . . : 2018/01/31
>> Referenced date . . : 2019/05/07
>> Expiration date . . : None
>>
>> ;-D an
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of 
>> Seymour J Metz
>>
>> Sent: Tuesday, May 07, 2019 11:40 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: [EXTERNAL MESSAGE] Re: COPYING PDS AND PDSE
>>
>> COPYMOD is for load module reblocking. There are no load modules in a PDSE. 
>> Off the top of my head I don't even recall whether it is valid for program 
>> objects. The COPY statement should work fine for PDSE.
>>
>>
>> ---
>>
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of 
>> esmie moo 012780d99c7b-dmarc-requ...@listserv.ua.edu
>> Sent: Tuesday, May 7, 2019 9:15 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: COPYING PDS AND PDSE
>>
>> I want to copy the PDSE to another. I was told that COPYMOD was the 
>> preferable parm when copying LOADLIBS. Is it okay just to use COPY?
>> On Tuesday, May 7, 2019, 8:09:09 a.m. EDT, Elardus Engelbrecht 
>> elardus.engelbre...@sita.co.za wrote:
>>
>> esmie moo wrote:
>>
>> > Are there special parms that I need to use in the copy PDS & PDSE'S?
>>
>> It depends. Do you want to copy all or specific members?
>>
>> > For example if I want to copy a PDSE to another PDSE (some maybe LOADLIBS) 
>> > would the following be okay?
>>
>> PS: I have doctored your JCL sample for better readability! ;-)
>>
>> //COPYJCL1 EXEC PGM=IEBCOPY
>> //SYSPRINT DD SYSOUT=*
>> //SYSUT3 DD UNIT=SYSDA,SPACE=(CYL,(50,50))
>> //SYSUT4 DD UNIT=SYSDA,SPACE=(CYL,(50,50))
>> //INDD DD DISP=OLD,DSN=MYDSN.CLIP.SHR
>> //OUTDD DD DISP=OLD,DSN=MYDSN.CLIP.SHR.NEW
>> //SYSIN DD *
>> COPY INDD=INDD,OUTDD=OUTDD
>> /*
>> //
>>
>> > Is the COPY command sufficient?
>>
>> It should be, a$$uming you want to copy ALL members without any reblocking 
>> with COPYMOD and that both datasets RECFM, LRECL, BLKSIZE, etc. are the same.
>>
>> Perhaps you can drop SYSUT3 and SYSUT4 and add this one:
>>
>> //SYSOUT DD SYSOUT=*
>>
>> Are you getting any error message(s)?
>>
>> Groete / Greetings
>> Elardus Engelbrecht
>>
>> --
>>
>> 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: [EXTERNAL MESSAGE] Re: COPYING PDS AND PDSE

[Paul Gilmartin]

On Tue, 7 May 2019 11:19:47 -0500, Mark Zelden wrote:

>On Tue, 7 May 2019 15:54:19 +, Mark Jacobs wrote:
>
>>They're called program objects in a PDS/e
> ^
>  PDSE
>Pedants unite! ;-) 
> 
Perhaps.  I suspect there are documents detailing the structure of a
"load module" and it was easier to use a new name than to update
all such documents.

OTOH, the organization of a PDSE is radically different from that of
a PDS, yet they kept DSORG=PO because many programming
interfaces depend on that.

-- gil

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

Re: [EXTERNAL MESSAGE] Re: COPYING PDS AND PDSE

[Blake, Daniel J [CTR]]

Thanks.

Dan






-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Tuesday, May 07, 2019 11:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL MESSAGE] Re: COPYING PDS AND PDSE

They're called program objects in a PDS/e

Mark Jacobs


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Tuesday, May 7, 2019 11:50 AM, Blake, Daniel J [CTR] 
<00f1be92566d-dmarc-requ...@listserv.ua.edu> wrote:

> Shmuel,
>
> I'm not sure what you mean by your statement > There are no load 
> modules in a PDSE. <
>
> Data Set Information
> Command ===>
>
> Data Set Name . . . : TCPIP.SEZALOAD
>
> General Data Current Allocation
> Management class . . : None Allocated tracks . : 2,963 Storage class . 
> . . : None Allocated extents . : 1 Volume serial . . . : xx 
> Maximum dir. blocks : NOLIMIT Device type . . . . : 3390 Data class . 
> . . . . : None Organization . . . : PO Current Utilization Record 
> format . . . : U Used pages . . . . : 29,397 Record length . . . : 0 % 
> Utilized . . . . : 82 Block size . . . . : 32760 Number of members . : 
> 306 1st extent tracks . : 2963 Secondary tracks . : 270 Data set name 
> type : LIBRARY Dates Data set version . : 1 Creation date . . . : 
> 2018/01/31 Referenced date . . : 2019/05/07 Expiration date . . : None
>
> ;-D an
>
> -Original Message-
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf 
> Of Seymour J Metz
>
> Sent: Tuesday, May 07, 2019 11:40 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL MESSAGE] Re: COPYING PDS AND PDSE
>
> COPYMOD is for load module reblocking. There are no load modules in a PDSE. 
> Off the top of my head I don't even recall whether it is valid for program 
> objects. The COPY statement should work fine for PDSE.
>
>
> --
> --
> --
> --
> ---
>
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf 
> of esmie moo 012780d99c7b-dmarc-requ...@listserv.ua.edu
> Sent: Tuesday, May 7, 2019 9:15 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COPYING PDS AND PDSE
>
> I want to copy the PDSE to another. I was told that COPYMOD was the 
> preferable parm when copying LOADLIBS. Is it okay just to use COPY?
> On Tuesday, May 7, 2019, 8:09:09 a.m. EDT, Elardus Engelbrecht 
> elardus.engelbre...@sita.co.za wrote:
>
> esmie moo wrote:
>
> > Are there special parms that I need to use in the copy PDS & PDSE'S?
>
> It depends. Do you want to copy all or specific members?
>
> > For example if I want to copy a PDSE to another PDSE (some maybe LOADLIBS) 
> > would the following be okay?
>
> PS: I have doctored your JCL sample for better readability! ;-)
>
> //COPYJCL1 EXEC PGM=IEBCOPY
> //SYSPRINT DD SYSOUT=*
> //SYSUT3 DD UNIT=SYSDA,SPACE=(CYL,(50,50))
> //SYSUT4 DD UNIT=SYSDA,SPACE=(CYL,(50,50)) //INDD DD 
> DISP=OLD,DSN=MYDSN.CLIP.SHR //OUTDD DD DISP=OLD,DSN=MYDSN.CLIP.SHR.NEW 
> //SYSIN DD * COPY INDD=INDD,OUTDD=OUTDD
> /*
> //
>
> > Is the COPY command sufficient?
>
> It should be, a$$uming you want to copy ALL members without any reblocking 
> with COPYMOD and that both datasets RECFM, LRECL, BLKSIZE, etc. are the same.
>
> Perhaps you can drop SYSUT3 and SYSUT4 and add this one:
>
> //SYSOUT DD SYSOUT=*
>
> Are you getting any error message(s)?
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> --
> --
> --
> --
>
> 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: mainframe hacking "success stories"?

[Jesse 1 Robinson]

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, were ushered 
on to the big-boy stage, and shareability was suddenly de rigueur. So began 
still-developing Rube Goldberg mechanisms to keep multiple users out of each 
other's shorts. After decades of flailing around, the only 'security tool' 
trusted by weenie-ware folks with something important to protect is server 
isolation. Let's be clear. The major reason for the mind-boggling proliferation 
of midrange servers is not the need for more MIPS and gigabytes. It's the 
fundamental distrust common to all non-mainframe users that anyone else allowed 
onto MY hardware is a potential mugger. One app, one server. You got a problem 
with that? The boss will buy you your own server. 

.
.
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 Tom 
Brennan
Sent: Tuesday, May 7, 2019 7:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: mainframe hacking "success stories"?

On the flip side, I bet there are many folks who were prompted to check their 
systems when they saw Phil Young's "Soldier of Fortran" web pages.

On 5/7/2019 7:49 AM, Nightwatch RenBand wrote:
> Publishing "success stories" is a two edged sword.  Don't and other 
> installations cannot protect against the attach. Do and you spread the 
> idea among the bad guys.
> It would seem that the best solution is:
> 1) Only discuss with people who have clearances and a "need to know",
> 2) Come up with a fix immediately
> 3) Put the fix in required maintenance and require that installations 
> stay current.  Never mention what is in the fix.
> Of course this great power to the vendor comes with great responsibility.
> (thanks, Stan Lee)


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

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.


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


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

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, were ushered 
on to the big-boy stage, and shareability was suddenly de rigueur. So began 
still-developing Rube Goldberg mechanisms to keep multiple users out of each 
other's shorts. After decades of flailing around, the only 'security tool' 
trusted by weenie-ware folks with something important to protect is server 
isolation. Let's be clear. The major reason for the mind-boggling proliferation 
of midrange servers is not the need for more MIPS and gigabytes. It's the 
fundamental distrust common to all non-mainframe users that anyone else allowed 
onto MY hardware is a potential mugger. One app, one server. You got a problem 
with that? The boss will buy you your own server.

.
.
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 Tom 
Brennan
Sent: Tuesday, May 7, 2019 7:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: mainframe hacking "success stories"?

On the flip side, I bet there are many folks who were prompted to check their 
systems when they saw Phil Young's "Soldier of Fortran" web pages.

On 5/7/2019 7:49 AM, Nightwatch RenBand wrote:
> Publishing "success stories" is a two edged sword.  Don't and other
> installations cannot protect against the attach. Do and you spread the
> idea among the bad guys.
> It would seem that the best solution is:
> 1) Only discuss with people who have clearances and a "need to know",
> 2) Come up with a fix immediately
> 3) Put the fix in required maintenance and require that installations
> stay current.  Never mention what is in the fix.
> Of course this great power to the vendor comes with great responsibility.
> (thanks, Stan Lee)


--
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: BLKSIZE=0 (was: Crazy ...)

[Seymour J Metz]

There were documented cases where you still needed an explicit block size for 
the for the concatenation. Based on the OP, it would appear that there still 
are.


--
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: Tuesday, May 7, 2019 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BLKSIZE=0 (was: Crazy ...)

On Tue, 7 May 2019 15:33:39 +, Seymour J Metz wrote:

>Well, removed except when it wasn't; there were caveats.
>
  ???
>
>From: Tom Marchant
>Sent: Tuesday, May 7, 2019 11:02 AM
>
>>What about BUFL=? As I recall, I used to use this to keep from
>>having problems with concatenations...
>
>Yes, until about 25 years ago, when the requirement that the first
>data set of a partitioned data set concatenation have the largest
>BLKSIZE was removed.
>
Silly (naive?) me.  I just coded an overriding BLKSIZE on the first
catenand. Or supplied a leading empty temp DSN with suitable attributes.
Would that satisfy the "caveats"?

Same for LRECL.

-- 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: [EXTERNAL MESSAGE] Re: COPYING PDS AND PDSE

[Seymour J Metz]

> I'm not sure what you mean by your statement > There are no load modules in a 
> PDSE. <

I meant that there were no load modules in a PDSE. The format of a load module 
is nothing remotely like the format of a program object.

Of course, you could allocate a PDSE that was not a library and copy members 
from a load library, but Fetch would not be able to load them.


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


From: IBM Mainframe Discussion List  on behalf of 
Blake, Daniel J [CTR] <00f1be92566d-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, May 7, 2019 11:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL MESSAGE] Re: COPYING PDS AND PDSE

Shmuel,

I'm not sure what you mean by your statement > There are no load modules in a 
PDSE. <

 Data Set Information
Command ===>

Data Set Name  . . . : TCPIP.SEZALOAD

General DataCurrent Allocation
 Management class . . : **None**Allocated tracks  . :   2,963
 Storage class  . . . : **None**Allocated extents . :   1
  Volume serial . . . : xx  Maximum dir. blocks :   NOLIMIT
  Device type . . . . : 3390
 Data class . . . . . : **None**
  Organization  . . . : PO  Current Utilization
  Record format . . . : U   Used pages  . . . . :   29,397
  Record length . . . : 0   % Utilized  . . . . :   82
  Block size  . . . . : 32760   Number of members . : 306
  1st extent tracks . : 2963
  Secondary tracks  . : 270
  Data set name type  : LIBRARY Dates
  Data set version  . : 1   Creation date . . . :   
2018/01/31
Referenced date . . :   
2019/05/07
Expiration date . . :   
***None***


;-D an



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Tuesday, May 07, 2019 11:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL MESSAGE] Re: COPYING PDS AND PDSE

COPYMOD is for load module reblocking. There are no load modules in a PDSE. Off 
the top of my head I don't even recall whether it is valid for program objects. 
The COPY statement should work fine for PDSE.


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


From: IBM Mainframe Discussion List  on behalf of 
esmie moo <012780d99c7b-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, May 7, 2019 9:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COPYING PDS AND PDSE

 I want to copy the PDSE to another.  I was told that COPYMOD was the 
preferable parm when copying LOADLIBS.  Is it okay just to use COPY?
On Tuesday, May 7, 2019, 8:09:09 a.m. EDT, Elardus Engelbrecht 
 wrote:

 esmie moo wrote:

>Are there special parms that I need to use in the copy PDS & PDSE'S?

It depends. Do you want to copy all or specific members?


>For example if I want to copy a PDSE to another PDSE (some maybe LOADLIBS) 
>would the following be okay?

PS: I have doctored your JCL sample for better readability! ;-)

//COPYJCL1  EXEC PGM=IEBCOPY
//SYSPRINT DD SYSOUT=*
//SYSUT3  DD UNIT=SYSDA,SPACE=(CYL,(50,50))
//SYSUT4  DD UNIT=SYSDA,SPACE=(CYL,(50,50))
//INDDDD DISP=OLD,DSN=MYDSN.CLIP.SHR
//OUTDDDD DISP=OLD,DSN=MYDSN.CLIP.SHR.NEW
//SYSINDD *
  COPY INDD=INDD,OUTDD=OUTDD
/*
//


>Is the COPY command sufficient?

It should be, a$$uming you want to copy ALL members without any reblocking with 
COPYMOD and that both datasets RECFM, LRECL, BLKSIZE, etc. are the same.

Perhaps you can drop SYSUT3 and SYSUT4 and add this one:

//SYSOUT  DD SYSOUT=*

Are you getting any error message(s)?

Groete / Greetings
Elardus Engelbrecht

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

--
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: COPYING PDS AND PDSE

[esmie moo]

 Thanks Seymour and thanks to all who responded to my post. 
On Tuesday, May 7, 2019, 11:39:43 a.m. EDT, Seymour J Metz  
wrote:  
 
 COPYMOD is for load module reblocking. There are no load modules in a PDSE. 
Off the top of my head I don't even recall whether it is valid for program 
objects. The COPY statement should work fine for PDSE.


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


From: IBM Mainframe Discussion List  on behalf of 
esmie moo <012780d99c7b-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, May 7, 2019 9:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COPYING PDS AND PDSE

 I want to copy the PDSE to another.  I was told that COPYMOD was the 
preferable parm when copying LOADLIBS.  Is it okay just to use COPY?
    On Tuesday, May 7, 2019, 8:09:09 a.m. EDT, Elardus Engelbrecht 
 wrote:

 esmie moo wrote:

>Are there special parms that I need to use in the copy PDS & PDSE'S?

It depends. Do you want to copy all or specific members?


>For example if I want to copy a PDSE to another PDSE (some maybe LOADLIBS) 
>would the following be okay?

PS: I have doctored your JCL sample for better readability! ;-)

//COPYJCL1  EXEC PGM=IEBCOPY
//SYSPRINT DD SYSOUT=*
//SYSUT3  DD UNIT=SYSDA,SPACE=(CYL,(50,50))
//SYSUT4  DD UNIT=SYSDA,SPACE=(CYL,(50,50))
//INDD    DD DISP=OLD,DSN=MYDSN.CLIP.SHR
//OUTDD    DD DISP=OLD,DSN=MYDSN.CLIP.SHR.NEW
//SYSIN    DD *
  COPY INDD=INDD,OUTDD=OUTDD
/*
//


>Is the COPY command sufficient?

It should be, a$$uming you want to copy ALL members without any reblocking with 
COPYMOD and that both datasets RECFM, LRECL, BLKSIZE, etc. are the same.

Perhaps you can drop SYSUT3 and SYSUT4 and add this one:

//SYSOUT  DD SYSOUT=*

Are you getting any error message(s)?

Groete / Greetings
Elardus Engelbrecht

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

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

Well, I knew hw to crack SVS 40 years ago, and I reported a security issue much 
more recently that allowed an operator to delete   or overwrite data sets that 
he didn't have access to.


--
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: Monday, May 6, 2019 10:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

How do you get a userid for a mainframe hack attempt? How do you insure it’s 
one with decent security access? Knowing very few have APF access.
I’ve never actually seen a mainframe hacked in 40 years and 15 different shops. 
Also never heard of one at shops in the Ohio, Pennsylvania area that I didn’t 
work. I’ve heard of potential holes but never seen it happen.


Sent from Yahoo Mail for iPhone


On Monday, May 6, 2019, 9:27 PM, Tom Brennan  
wrote:

Ok, but why is Windows easier to hack than the mainframe?

Personally, I'd find a mainframe far easier to hack because I know a
little bit about control blocks, APF auth, SVC's, subsystems, address
spaces, RACF, etc., and I know far less about the equivalents on
Windows.  But of course the first step is to get any kind of userid, and
that's done by pretty-much the same methods - regardless of platform.

On 5/6/2019 1:18 PM, Bill Johnson wrote:
> It’s why banks stay on the mainframe. Security.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Monday, May 6, 2019, 4:09 PM, Bigendian Smalls 
>  wrote:
>
> Bill, would you care to back that sweeping generalization up with some detail?
>
>> On May 6, 2019, at 22:06, Bill Johnson 
>> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
>>
>> Completely different. Hacking Microsoft is way easier.
>>
>>
>> Sent from Yahoo Mail for iPhone
>>
>>
>> On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls 
>>  wrote:
>>
>> Which is how 80% of all the hacks today start.  Find purchase and advance 
>> your position. This is how the game is played. It was as classic of a hack 
>> as anything today.
>>
>>> On May 6, 2019, at 21:43, Bill Johnson 
>>> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
>>>
>>> Still never would have occurred without a valid userid.
>>>
>>>
>>> Sent from Yahoo Mail for iPhone
>>>
>>>
>>> On Monday, May 6, 2019, 3:18 PM, Charles Mills  wrote:
>>>
>>> No.
>>>
>>>  From the link you cite:
>>>
>>> "According to various sources, the hackers succeeded in finding (and 
>>> exploiting) at least 2 previously unknown errors enabling them to raise 
>>> their authorisations in the system. One of them was an error in an IBM HTTP 
>>> server and the other one was an error in the CNMEUNIX file, which in the 
>>> default configuration has SUID 0 authorisations (which means that by 
>>> leveraging on the errors it contains, one is able to execute commands with 
>>> the system administrator’s authorisations)."
>>>
>>> His "user" access to InfoTorg was not a problem for the mainframe. (It was 
>>> a problem for the MPAA lawyer whose account he accessed, but not for the 
>>> mainframe in general.) The above mainframe security vulnerability was.
>>>
>>> Charles
>>>
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>>> Behalf Of Bill Johnson
>>> Sent: Monday, May 6, 2019 11:17 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: mainframe hacking "success stories"?
>>>
>>> The Pirate Bay hack acquired a valid mainframe userid and password off of a 
>>> Microsoft laptop. In effect, not really a mainframe hack. He just logged 
>>> on. 
>>> https://secure-web.cisco.com/1PuV7hwSYcTtXgFxBotxSLjV04bUbgc0D3-k6bonzJuLZyzAgwXxZqkx6sPqF2Uqd5EXgphJmHx9xXg-Q5pyKseze3Yl4UB03fLbjPGHAFehxdnb96GQ7QtMCuINo4LaJjbbnmNOkIzzhad9cYOr3zAgInlkz4N1gXBgoIwEL4gW6wprkQORk9XRleaU9R0SF4afXSC_5_x56DexwB0An5NcTWcqqxBwF1n0jjPmORIumvljPEkj909hatjeM-IH6g0by81yJ9ETS5sTKnD2nZrjKrVCE5Pfyhx_2A366yMPNAGx-nFtzxrkpp7dfFOkOZIcG3RMR0-BbCZkHnD9gv5_8tc7XaMSNiK3LvnLeTHdtMxBRVw96c7pPrZfLxNcqjN-uV4lyhwVjPbTG3HfftTNY9Giui5W1LzcniBszVDtv830M0rUrYf4qH_2rgNMM/https%3A%2F%2Fbadcyber.com%2Fa-history-of-a-hacking%2F
>>>
>>> Sent from Yahoo Mail for iPhone
>>>
>>>
>>> On Monday, May 6, 2019, 1:21 PM, 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?

Re: mainframe hacking "success stories"?

[Seymour J Metz]

How will knowledge of control blocks, SVCs, etc., allow you to escalate your 
privileges beyond those assigned to your userid and groupid?


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


From: IBM Mainframe Discussion List  on behalf of Tom 
Brennan 
Sent: Monday, May 6, 2019 9:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

Ok, but why is Windows easier to hack than the mainframe?

Personally, I'd find a mainframe far easier to hack because I know a
little bit about control blocks, APF auth, SVC's, subsystems, address
spaces, RACF, etc., and I know far less about the equivalents on
Windows.  But of course the first step is to get any kind of userid, and
that's done by pretty-much the same methods - regardless of platform.

On 5/6/2019 1:18 PM, Bill Johnson wrote:
> It’s why banks stay on the mainframe. Security.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Monday, May 6, 2019, 4:09 PM, Bigendian Smalls 
>  wrote:
>
> Bill, would you care to back that sweeping generalization up with some detail?
>
>> On May 6, 2019, at 22:06, Bill Johnson 
>> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
>>
>> Completely different. Hacking Microsoft is way easier.
>>
>>
>> Sent from Yahoo Mail for iPhone
>>
>>
>> On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls 
>>  wrote:
>>
>> Which is how 80% of all the hacks today start.  Find purchase and advance 
>> your position. This is how the game is played. It was as classic of a hack 
>> as anything today.
>>
>>> On May 6, 2019, at 21:43, Bill Johnson 
>>> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
>>>
>>> Still never would have occurred without a valid userid.
>>>
>>>
>>> Sent from Yahoo Mail for iPhone
>>>
>>>
>>> On Monday, May 6, 2019, 3:18 PM, Charles Mills  wrote:
>>>
>>> No.
>>>
>>>  From the link you cite:
>>>
>>> "According to various sources, the hackers succeeded in finding (and 
>>> exploiting) at least 2 previously unknown errors enabling them to raise 
>>> their authorisations in the system. One of them was an error in an IBM HTTP 
>>> server and the other one was an error in the CNMEUNIX file, which in the 
>>> default configuration has SUID 0 authorisations (which means that by 
>>> leveraging on the errors it contains, one is able to execute commands with 
>>> the system administrator’s authorisations)."
>>>
>>> His "user" access to InfoTorg was not a problem for the mainframe. (It was 
>>> a problem for the MPAA lawyer whose account he accessed, but not for the 
>>> mainframe in general.) The above mainframe security vulnerability was.
>>>
>>> Charles
>>>
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>>> Behalf Of Bill Johnson
>>> Sent: Monday, May 6, 2019 11:17 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: mainframe hacking "success stories"?
>>>
>>> The Pirate Bay hack acquired a valid mainframe userid and password off of a 
>>> Microsoft laptop. In effect, not really a mainframe hack. He just logged 
>>> on. 
>>> https://secure-web.cisco.com/1EiUBe8kWIGocAoCHZ8duxx_X3_ii_2_msH4KXaCbsI05OQ4V0kZ0pcTIXpwXTnEXNJkg9GeqVs-R7IzdSX9GnIfcJrObS1D825ZM8nJeSoB6vNzJa2xDGqRXXNZvwK78Iko8hdQw6zS2R6griNgSM3snpLMvdrvHola_yv9zPXwr3f6_IlZ7zMV0PzBZ-SGsvsDr51V7r3Nf9n5gmq2VbONzowLmg5ZZIqqVK1uZXvW9mgP95d8wKnt8qt0yiAh5CB5la2Ub6ctm1NEEnN28D9JkOoehxhmkVmnssVIWwcAmZcPc3YZR4CHcmwQYA0gTScHJJs4dlOuGr6oKCL6mLSnp3kcELzP0FYC6m1v535CyCj7Fno_rt5ZWPmdLK8io3_XlgKB1xTTcjg9LhBDjwf7zqa9Iwg0Fse4BZ-eBCmUliiBCBkA7FPCEcbalillZW5RyF3YVzqmqEU4hm_I0Ig/https%3A%2F%2Fbadcyber.com%2Fa-history-of-a-hacking%2F
>>>
>>> Sent from Yahoo Mail for iPhone
>>>
>>>
>>> On Monday, May 6, 2019, 1:21 PM, 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
>>>
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>>> Behalf Of Bill Johnson
>>> Sent: Sunday, May 5, 2019 10:00 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: mainframe hacking "success stori

Re: mainframe hacking "success stories"?

[Seymour J Metz]

1964? What is the 7090, chopped liver?


--
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: Monday, May 6, 2019 8:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

Read up.
https://secure-web.cisco.com/1Ek9Ay2eea5LMyHGSr_VI0lyNAf1W-23MmrrCjkI3sDnySsBU6IfTzOti5Ei3oq3bKwmnrM1BjsWwe2CFkEGM5mcVxDN9VlsXVTyK-vvRwSNT1crAxZ-qd4W23tb7AAaj1olsa1Z_CJikpLITtzS5j5Uc6FHGAWXJMgRqJfj98g4uo01j3uxWurqq_TpAqZtGgJf6AJkLsKF4bn4zEWkLU7M0OA9Yap0M9BM416WaZIyen9fc5JAhYA3_G_DhpgtS946GQlj8ZiZzE4dcG3hKoy8thlu0pTA2BHzUkbyFMX1uyCOHLJZikq_AtDbQNUp4g6Z0iqxTu3hWF3gs2NkeH8jQ2OicLiLJv7KgjVKb0XXsH-y74Z9uk5uAM108uMXqlbsyl8aoYSLJIherjwr_qrDGmBJwVylXy7b6tfb727hXlqCtNFJRuFV6Ei7g1ue8/https%3A%2F%2Fwww.allerin.com%2Fblog%2Fwhy-do-banks-still-use-mainframes


Sent from Yahoo Mail for iPhone


On Monday, May 6, 2019, 4:23 PM, ITschak Mugzach  wrote:

No. It has nothing to do with security. It is a lagend. Penetrated all my
clients. The reason is convertion complexity, tco and simplicity. Security,
in a nut shell is what your sysprog does. Only few security guys left to
guide them.



בתאריך יום ב׳, 6 במאי 2019, 23:18, מאת Bill Johnson ‏<
0047540adefe-dmarc-requ...@listserv.ua.edu>:

> It’s why banks stay on the mainframe. Security.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Monday, May 6, 2019, 4:09 PM, Bigendian Smalls <
> mainfr...@bigendiansmalls.com> wrote:
>
> Bill, would you care to back that sweeping generalization up with some
> detail?
>
> > On May 6, 2019, at 22:06, Bill Johnson <
> 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > Completely different. Hacking Microsoft is way easier.
> >
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls <
> mainfr...@bigendiansmalls.com> wrote:
> >
> > Which is how 80% of all the hacks today start.  Find purchase and
> advance your position. This is how the game is played. It was as classic of
> a hack as anything today.
> >
> >> On May 6, 2019, at 21:43, Bill Johnson <
> 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
> >>
> >> Still never would have occurred without a valid userid.
> >>
> >>
> >> Sent from Yahoo Mail for iPhone
> >>
> >>
> >> On Monday, May 6, 2019, 3:18 PM, Charles Mills 
> wrote:
> >>
> >> No.
> >>
> >> From the link you cite:
> >>
> >> "According to various sources, the hackers succeeded in finding (and
> exploiting) at least 2 previously unknown errors enabling them to raise
> their authorisations in the system. One of them was an error in an IBM HTTP
> server and the other one was an error in the CNMEUNIX file, which in the
> default configuration has SUID 0 authorisations (which means that by
> leveraging on the errors it contains, one is able to execute commands with
> the system administrator’s authorisations)."
> >>
> >> His "user" access to InfoTorg was not a problem for the mainframe. (It
> was a problem for the MPAA lawyer whose account he accessed, but not for
> the mainframe in general.) The above mainframe security vulnerability was.
> >>
> >> Charles
> >>
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Bill Johnson
> >> Sent: Monday, May 6, 2019 11:17 AM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: mainframe hacking "success stories"?
> >>
> >> The Pirate Bay hack acquired a valid mainframe userid and password off
> of a Microsoft laptop. In effect, not really a mainframe hack. He just
> logged on. 
> https://secure-web.cisco.com/1dtkcrw3UvHDAtHJYgwJLS8NUA5haI3DOoWEHAzRQftl-uSTNSVRZ3xNHIrc5jRBOC5iDUNVz7uX3xQ-PwPmENDdlnSuTzgOMOISGCvKvXM2At3PZhxdNO_PDabkKbWBha9KqL4l89YHhfsaeUk1dUmHOI2aZYHdjbH_PCw0vv6YLKYtoIMk8iOYMAcQVmprdSagagmxYOUmWzjMxXMj4OfXk9QpJWh5PJyPhAlQI_1tB5oinEdbZBzzLVtgGYqGdLe02Ccp3ig2DbwWUWKIDv_2R3raHkIJRZ9ZsmzAFgqdFvOnMuH5_LfBzegcfKxIpNq_Rg-0KzkF18-0ajn2LhKTIsdRO_n9m1GFYbOVFZ8zbxT6wBxlCv9ZWEf9OxIOgTx2svjfkNyCPyDejRjD_K8AqBEwPKotd2V0dmmbHFwy3RVCrxlngG8oZ4aIASFU6/https%3A%2F%2Fbadcyber.com%2Fa-history-of-a-hacking%2F
> >>
> >> Sent from Yahoo Mail for iPhone
> >>
> >>
> >> On Monday, May 6, 2019, 1:21 PM, 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 you

Re: COPYING PDS AND PDSE

[Lizette Koehler]

Remember, that IEBCOPY has lots of examples and details on IBM.COM

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.idau100/iebcopy.htm


Unless specified, the examples will tell you exactly how to copy from a LibA to 
a LibB

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> esmie moo
> Sent: Tuesday, May 07, 2019 10:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COPYING PDS AND PDSE
> 
>  Thanks Seymour and thanks to all who responded to my post.
> On Tuesday, May 7, 2019, 11:39:43 a.m. EDT, Seymour J Metz
>  wrote:
> 
>  COPYMOD is for load module reblocking. There are no load modules in a PDSE.
> Off the top of my head I don't even recall whether it is valid for program
> objects. The COPY statement should work fine for PDSE.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List  on behalf of
> esmie moo <012780d99c7b-dmarc-requ...@listserv.ua.edu>
> Sent: Tuesday, May 7, 2019 9:15 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COPYING PDS AND PDSE
> 
>  I want to copy the PDSE to another.  I was told that COPYMOD was the
> preferable parm when copying LOADLIBS.  Is it okay just to use COPY?
> On Tuesday, May 7, 2019, 8:09:09 a.m. EDT, Elardus Engelbrecht
>  wrote:
> 
>  esmie moo wrote:
> 
> >Are there special parms that I need to use in the copy PDS & PDSE'S?
> 
> It depends. Do you want to copy all or specific members?
> 
> 
> >For example if I want to copy a PDSE to another PDSE (some maybe LOADLIBS)
> would the following be okay?
> 
> PS: I have doctored your JCL sample for better readability! ;-)
> 
> //COPYJCL1  EXEC PGM=IEBCOPY
> //SYSPRINT DD SYSOUT=*
> //SYSUT3  DD UNIT=SYSDA,SPACE=(CYL,(50,50))
> //SYSUT4  DD UNIT=SYSDA,SPACE=(CYL,(50,50)) //INDDDD
> DISP=OLD,DSN=MYDSN.CLIP.SHR //OUTDDDD DISP=OLD,DSN=MYDSN.CLIP.SHR.NEW
> //SYSINDD *
>   COPY INDD=INDD,OUTDD=OUTDD
> /*
> //
> 
> 
> >Is the COPY command sufficient?
> 
> It should be, a$$uming you want to copy ALL members without any reblocking
> with COPYMOD and that both datasets RECFM, LRECL, BLKSIZE, etc. are the same.
> 
> Perhaps you can drop SYSUT3 and SYSUT4 and add this one:
> 
> //SYSOUT  DD SYSOUT=*
> 
> Are you getting any error message(s)?
> 
> Groete / Greetings
> Elardus Engelbrecht
> 

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

Yes  you will find it in smf119 and you have to activate your Telnet records in 
tcpip



Bin unterwegs hab nur iPhone zur Verfügung.😎

> Am 07.05.2019 um 15:04 schrieb Jorge Garcia :
> 
> Hi all,
> 
> We want to obtain LU name and RACF ID associated from SMF records or anyother 
> source. We don't have available SMF record type 33. This LU name is available 
> in TELNET profile 
> 
> LUGROUP LUMAJ 
>T900D001..T900D030
> 
> We don't know if there is some SMF records with the information of LU name, 
> RACF ID and IP. We've executed test with SMF record 118 and 119 but we 
> haven't obtain sucess. 
> 
> Please, could you give us some advice to obtain this information?
> 
> Jorge Garcia Juanino
> Coordinador sistemas z/OS
> ACTP – DIAC – Operación y Soporte EMEA
> MAPFRE 
> Avenida del Talgo 100-103 – 3ª Planta
> CP 28023 Madrid
> Tel. 91 581 27 34, Movil 618333559 
> jgarc...@mapfre.com
> 
> --
> 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

Reusable JCL Content Restored

[Geoff Smith]

FYI - The Reusable JCL Collection has been restored to z/OS Basic Skills 
(https://www.ibm.com/support/knowledgecenter/en/zosbasics/com.ibm.zos.zjcl/zjclc_intro2reusablejclcoll.htm)
 

This collection is designed to help new users quickly become productive in the 
z/OS environment, while teaching JCL keywords and syntax within the context of 
realistic samples. The samples in the collection are based on tasks that 
existing z/OS customers have identified as most likely to be given to new z/OS 
professionals as part of their on-the-job training.

The samples in the reusable JCL collection are as complete as possible, and 
include line-by-line instructions and descriptions. Correctly modifying the 
samples for use, however, requires some basic knowledge of JCL techniques and 
of your own work environment. This collection includes a company checklist and 
other educational materials that can help you use the samples, and eventually 
code your own JCL.

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

TPX with IBM fault analyser

[Peter]

Hi

Cross posted

I am working on a tpx upgrade. When I start the address space for some
reason it reads the fault analyser dataset.

I have checked throughout the proc to see if by chance I have added that in
DD but there isn't any.

Not sure from where the TPX is pointing the Fault analyser parm.

Does anyone have a similar set up and have any clue ?

Peter

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

Re: TPX with IBM fault analyser

[Jousma, David]

You probably want to add this statement to your TPX proc.

//IDIOFF   DD DUMMY  * Disable Fault Analyzer for z/OS *

-or-

Look in sys1.parmlib(idicnf00)

There is probably a 

INCLUDE(TYPE(STC) type statement.   We only allow FA to get involved with batch 
jobs, so we exclude STC and TSU
_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter
Sent: Tuesday, May 7, 2019 2:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TPX with IBM fault analyser

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Hi

Cross posted

I am working on a tpx upgrade. When I start the address space for some reason 
it reads the fault analyser dataset.

I have checked throughout the proc to see if by chance I have added that in DD 
but there isn't any.

Not sure from where the TPX is pointing the Fault analyser parm.

Does anyone have a similar set up and have any clue ?

Peter

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

RFE to expand Unix path length for DYNALLOC beyond 255 characters

[Jerry Callen]

I recently discovered that the maximum path length for dynamic
allocation key 8017 (Unix PATH name) is 255 characters, in spite of
the fact that the text unit length field is 16 bits. While most "human
generated" path lengths will not be that long, software generated paths
can easily exceed that. Anyone who has used npm on Windows knows
exactly what I'm talking about, and npm is now being used on z/OS
(with node.js).

I have opened an RFE to expand this length; please consider voting for it.

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=132716

Thanks!

-- Jerry

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

On Tue, 7 May 2019 17:12:48 +, Jesse 1 Robinson wrote:

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

The earliest microprocessors had nothing equivalent to supervisor state, 
privileged instructions , or storage protect keys. PC operating systems, 
including several releases of Windows, were written without the benefit of any 
of these. Every program had full access to everything that the processor could 
do. 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.

-- 
Tom Marchant

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

I was really talking about things I'd do once I got APF/RACF authority. 
On Windows even if I got admin auth on a server, I wouldn't know what to 
do with it.


On 5/7/2019 10:46 AM, Seymour J Metz wrote:

How will knowledge of control blocks, SVCs, etc., allow you to escalate your 
privileges beyond those assigned to your userid and groupid?


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


From: IBM Mainframe Discussion List  on behalf of Tom 
Brennan 
Sent: Monday, May 6, 2019 9:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

Ok, but why is Windows easier to hack than the mainframe?

Personally, I'd find a mainframe far easier to hack because I know a
little bit about control blocks, APF auth, SVC's, subsystems, address
spaces, RACF, etc., and I know far less about the equivalents on
Windows.  But of course the first step is to get any kind of userid, and
that's done by pretty-much the same methods - regardless of platform.

On 5/6/2019 1:18 PM, Bill Johnson wrote:

It’s why banks stay on the mainframe. Security.


Sent from Yahoo Mail for iPhone


On Monday, May 6, 2019, 4:09 PM, Bigendian Smalls 
 wrote:

Bill, would you care to back that sweeping generalization up with some detail?


On May 6, 2019, at 22:06, Bill Johnson 
<0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

Completely different. Hacking Microsoft is way easier.


Sent from Yahoo Mail for iPhone


On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls 
 wrote:

Which is how 80% of all the hacks today start.  Find purchase and advance your 
position. This is how the game is played. It was as classic of a hack as 
anything today.


On May 6, 2019, at 21:43, Bill Johnson 
<0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

Still never would have occurred without a valid userid.


Sent from Yahoo Mail for iPhone


On Monday, May 6, 2019, 3:18 PM, Charles Mills  wrote:

No.

  From the link you cite:

"According to various sources, the hackers succeeded in finding (and exploiting) at 
least 2 previously unknown errors enabling them to raise their authorisations in the 
system. One of them was an error in an IBM HTTP server and the other one was an error in 
the CNMEUNIX file, which in the default configuration has SUID 0 authorisations (which 
means that by leveraging on the errors it contains, one is able to execute commands with 
the system administrator’s authorisations)."

His "user" access to InfoTorg was not a problem for the mainframe. (It was a 
problem for the MPAA lawyer whose account he accessed, but not for the mainframe in 
general.) The above mainframe security vulnerability was.

Charles


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

The Pirate Bay hack acquired a valid mainframe userid and password off of a 
Microsoft laptop. In effect, not really a mainframe hack. He just logged on. 
https://secure-web.cisco.com/1EiUBe8kWIGocAoCHZ8duxx_X3_ii_2_msH4KXaCbsI05OQ4V0kZ0pcTIXpwXTnEXNJkg9GeqVs-R7IzdSX9GnIfcJrObS1D825ZM8nJeSoB6vNzJa2xDGqRXXNZvwK78Iko8hdQw6zS2R6griNgSM3snpLMvdrvHola_yv9zPXwr3f6_IlZ7zMV0PzBZ-SGsvsDr51V7r3Nf9n5gmq2VbONzowLmg5ZZIqqVK1uZXvW9mgP95d8wKnt8qt0yiAh5CB5la2Ub6ctm1NEEnN28D9JkOoehxhmkVmnssVIWwcAmZcPc3YZR4CHcmwQYA0gTScHJJs4dlOuGr6oKCL6mLSnp3kcELzP0FYC6m1v535CyCj7Fno_rt5ZWPmdLK8io3_XlgKB1xTTcjg9LhBDjwf7zqa9Iwg0Fse4BZ-eBCmUliiBCBkA7FPCEcbalillZW5RyF3YVzqmqEU4hm_I0Ig/https%3A%2F%2Fbadcyber.com%2Fa-history-of-a-hacking%2F

Sent from Yahoo Mail for iPhone


On Monday, May 6, 2019, 1:21 PM, 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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Johnson
Sent: Sunday, May 5, 2019 10:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

Wasn’t really a mainframe hack. It was a laptop hack that acquired legitimate 
mainframe credentials.

--

Re: RFE to expand Unix path length for DYNALLOC beyond 255 characters

[Paul Gilmartin]

On Tue, 7 May 2019 13:37:55 -0500, Jerry Callen wrote:

>I recently discovered that the maximum path length for dynamic
>allocation key 8017 (Unix PATH name) is 255 characters, in spite of
>the fact that the text unit length field is 16 bits. While most "human
>generated" path lengths will not be that long, software generated paths
>can easily exceed that. Anyone who has used npm on Windows knows
>exactly what I'm talking about, and npm is now being used on z/OS
>(with node.js).
>
>I have opened an RFE to expand this length; please consider voting for it.
>
>http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=132716
> 
+1

At least support, for consistency:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxa400/pathname.htm
... A path name can be up to 1023 characters long, including all directory 
names, file names,
and separating slashes. ...

The enhancement should apply to JCL allocation as well as DYNALLOC.

Does any SVC 99 TU exceed 256 characters?  Is this a relic of the MVC 
instruction?

I'll suggest here, but it might belong in a separate RFE:
o Relative (to current directory) paths.  In batch that would be HOME/.
o Tilde expansion: ~/... and ~username/...  I've done this easily in Rexx.

-- gil

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

[Bob Bridges]

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.

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

/* A fanatic is someone who does what he knows God would do if God knew the 
facts of the case.  -found at http://www.algonet.se/~parlei/quotes.html */


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of 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.

From: IBM Mainframe Discussion List  on behalf of 
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, were ushered 
on to the big-boy stage, and shareability was suddenly de rigueur. So began 
still-developing Rube Goldberg mechanisms to keep multiple users out of each 
other's shorts. After decades of flailing around, the only 'security tool' 
trusted by weenie-ware folks with something important to protect is server 
isolation. Let's be clear. The major reason for the mind-boggling proliferation 
of midrange servers is not the need for more MIPS and gigabytes. It's the 
fundamental distrust common to all non-mainframe users that anyone else allowed 
onto MY hardware is a potential mugger. One app, one server. You got a problem 
with that? The boss will buy you your own server.

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

[ITschak Mugzach]

There are ways to collect IDs that might be used to penetrate the
mainframe:

   - users defined to UADS but not to RACF.
   - IBMUSER is active and password wasn't changed.
   - Users assigned to products. until x/os 2.2, if no password assigned,
   the password was the default group (TX ibm for fixing that). userid's can
   be guessed.
   - old os versions used to have some TSOxx userid's.
   - without naming a product, -( the uss directories and logs of some
   password sync and governance solutions are not protected.

and some other techniques that can't be described here. In short, there are
ways. the idea is to collect the data without creating violations. trickey,
but works well.

ITschak


On Tue, May 7, 2019 at 10:17 PM Tom Brennan 
wrote:

> I was really talking about things I'd do once I got APF/RACF authority.
> On Windows even if I got admin auth on a server, I wouldn't know what to
> do with it.
>
> On 5/7/2019 10:46 AM, Seymour J Metz wrote:
> > How will knowledge of control blocks, SVCs, etc., allow you to escalate
> your privileges beyond those assigned to your userid and groupid?
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List  on
> behalf of Tom Brennan 
> > Sent: Monday, May 6, 2019 9:27 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: mainframe hacking "success stories"?
> >
> > Ok, but why is Windows easier to hack than the mainframe?
> >
> > Personally, I'd find a mainframe far easier to hack because I know a
> > little bit about control blocks, APF auth, SVC's, subsystems, address
> > spaces, RACF, etc., and I know far less about the equivalents on
> > Windows.  But of course the first step is to get any kind of userid, and
> > that's done by pretty-much the same methods - regardless of platform.
> >
> > On 5/6/2019 1:18 PM, Bill Johnson wrote:
> >> It’s why banks stay on the mainframe. Security.
> >>
> >>
> >> Sent from Yahoo Mail for iPhone
> >>
> >>
> >> On Monday, May 6, 2019, 4:09 PM, Bigendian Smalls <
> mainfr...@bigendiansmalls.com> wrote:
> >>
> >> Bill, would you care to back that sweeping generalization up with some
> detail?
> >>
> >>> On May 6, 2019, at 22:06, Bill Johnson <
> 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
> >>>
> >>> Completely different. Hacking Microsoft is way easier.
> >>>
> >>>
> >>> Sent from Yahoo Mail for iPhone
> >>>
> >>>
> >>> On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls <
> mainfr...@bigendiansmalls.com> wrote:
> >>>
> >>> Which is how 80% of all the hacks today start.  Find purchase and
> advance your position. This is how the game is played. It was as classic of
> a hack as anything today.
> >>>
>  On May 6, 2019, at 21:43, Bill Johnson <
> 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
> 
>  Still never would have occurred without a valid userid.
> 
> 
>  Sent from Yahoo Mail for iPhone
> 
> 
>  On Monday, May 6, 2019, 3:18 PM, Charles Mills 
> wrote:
> 
>  No.
> 
>    From the link you cite:
> 
>  "According to various sources, the hackers succeeded in finding (and
> exploiting) at least 2 previously unknown errors enabling them to raise
> their authorisations in the system. One of them was an error in an IBM HTTP
> server and the other one was an error in the CNMEUNIX file, which in the
> default configuration has SUID 0 authorisations (which means that by
> leveraging on the errors it contains, one is able to execute commands with
> the system administrator’s authorisations)."
> 
>  His "user" access to InfoTorg was not a problem for the mainframe.
> (It was a problem for the MPAA lawyer whose account he accessed, but not
> for the mainframe in general.) The above mainframe security vulnerability
> was.
> 
>  Charles
> 
> 
>  -Original Message-
>  From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Bill Johnson
>  Sent: Monday, May 6, 2019 11:17 AM
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Subject: Re: mainframe hacking "success stories"?
> 
>  The Pirate Bay hack acquired a valid mainframe userid and password
> off of a Microsoft laptop. In effect, not really a mainframe hack. He just
> logged on.
> https://secure-web.cisco.com/1EiUBe8kWIGocAoCHZ8duxx_X3_ii_2_msH4KXaCbsI05OQ4V0kZ0pcTIXpwXTnEXNJkg9GeqVs-R7IzdSX9GnIfcJrObS1D825ZM8nJeSoB6vNzJa2xDGqRXXNZvwK78Iko8hdQw6zS2R6griNgSM3snpLMvdrvHola_yv9zPXwr3f6_IlZ7zMV0PzBZ-SGsvsDr51V7r3Nf9n5gmq2VbONzowLmg5ZZIqqVK1uZXvW9mgP95d8wKnt8qt0yiAh5CB5la2Ub6ctm1NEEnN28D9JkOoehxhmkVmnssVIWwcAmZcPc3YZR4CHcmwQYA0gTScHJJs4dlOuGr6oKCL6mLSnp3kcELzP0FYC6m1v535CyCj7Fno_rt5ZWPmdLK8io3_XlgKB1xTTcjg9LhBDjwf7zqa9Iwg0Fse4BZ-eBCmUliiBCBkA7FPCEcbalillZW5RyF3YVzqmqEU4hm_I0Ig/https%3A%2F%2Fbadcyber.com%2Fa-history-of-a-hacking%2F
> 
>  Sent from Yahoo Mail for iPhone
> 
> 
>  On Monday, May 6, 2019, 1:21 PM, Charles

Re: RFE to expand Unix path length for DYNALLOC beyond 255 characters

[Jerry Callen]

On Tue, 7 May 2019 14:24:26 -0500, Paul Gilmartin wrote:

> At least support, for consistency:
>
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxa400/pathname.htm
>
> ... A path name can be up to 1023 characters long, including
> all directory names, file names, and separating slashes. ...

Yes, although I can tell you that this is the limit imposed by Windows
(I think), and for npm, even that has proven to be a problem. Deeply
nested Java class paths also bump into this.

I don't really understand why there should need for any limit at all.
Hasn't anyone heard of malloc? :-)

> The enhancement should apply to JCL allocation as well as DYNALLOC.

Hmm, yet another code path. Though it might well be that fixing it in
DYNALLOC would fix it for JCL as well.

> Does any SVC 99 TU exceed 256 characters?  Is this a relic of the
> MVC instruction?

Dollars to donuts that's the reason.

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

[Bob Bridges]

Last century there were frequent panics going around about viri conveyed by 
email:  "If you get an email whose subject line is 'yada yada', DON'T OPEN 
IT!!!  It'll delete your hard drive, give you boils and trigger an 
earthquake!".  I spent quite a bit of time reässuring my friends and relatives 
that you can't get a virus just by opening an email, that for a program to do 
anything you have to give it control (by double-clicking on an attachment, for 
example).

Then Microsoft made it possible for the hoax to become a reality, through their 
handy-dandy auto-run event processing.  I was not an inveterate MS-basher, but 
I nearly became one for a while.  Then they finally began to see the light - 
~very~ late, in my opinion, but better late than never.

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

/* I don't want the cheese, I just want out of the trap.  -Spanish proverb */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, May 7, 2019 14:47

The earliest microprocessors had nothing equivalent to supervisor state, 
privileged instructions , or storage protect keys. PC operating systems, 
including several releases of Windows, were written without the benefit of any 
of these. Every program had full access to everything that the processor could 
do. 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.

--- On Tue, 7 May 2019 17:12:48 +, Jesse 1 Robinson wrote:
>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. 

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

[Bob Bridges]

I think I side with Cliff Stoll on this:  You're not doing any favors by 
obscuring the vulnerabilities, because the bad guys already know.  Go ahead and 
talk about them.  Be explicit.  Get that knowledge into the hands of the good 
guys too.

Or put it this way:  ~Some~ of the bad guys know about the holes - the default 
passwords that never get changed, for example.  The solution isn't to minimize 
the number of bad guys who know, because as soon as one knows the exploits will 
begin.  The solution, once that's out, is to maximize the number of good guys 
who know too, so as to maximize the number of systems that are secured.

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

/* Unspecified error; smash forehead on keyboard to continue. */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nightwatch RenBand
Sent: Tuesday, May 7, 2019 10:50

Publishing "success stories" is a two edged sword.  Don't and other
installations cannot protect against the attach. Do and you spread the idea
among the bad guys.
It would seem that the best solution is:
1) Only discuss with people who have clearances and a "need to know",
2) Come up with a fix immediately
3) Put the fix in required maintenance and require that installations stay
current.  Never mention what is in the fix.
Of course this great power to the vendor comes with great responsibility.
(thanks, Stan Lee)

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

Passing along a job opportunity

[Phil Smith III]

I got a ping for a z/OS sysprog job in Costa Mesa, CA, figured I'd point folks 
on this list at it. If that's not OK let me know and I won't do it again.

 

To be clear: THIS IS NOT A JOB I'M HIRING FOR. DO NOT ASK ME ABOUT IT BECAUSE I 
WON'T KNOW.

Ask this guy:

Gar Thompson, Safeguard Healthcare

gthomp...@safeguard-healthcare.com  

P: 714 372-2256

C: 714 747-6337

 

Good luck. This message will self-dest


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

. why MVS users nowadays need special authority to create a program dump.

?


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


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

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.

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

/* A fanatic is someone who does what he knows God would do if God knew the 
facts of the case.  -found at 
http://secure-web.cisco.com/1SRoNi6sO9ZJ2yVRdFSymY4R9_0Uk8Xjf3DDO4saNi36LiC7IIYA4Sf-mnlaquaS_pHzYiFw4j4pWWsGGactebIisSF268q0X_DDyS0dgpuj94D3fHgU5g1S_OUHjrOrhQJX2LaMOeZpJmjmWK_f7xgy-zEbG8FshS-YX5LaidM64JArWLGWWd-Ywqqg9yiDwsB2fL48pq-m1YxadcfjXD4ZhRcTW2rx28yiCe664ynLnheLCN6ZdkOcyfEJRXGWplWar_CzAPvn7Wh-zImqfkNhdE8KjpSBNBcPVyHYRf4_itZrp9SBYiCOceKorhJpJSFBxPpKlhEv0-LvMyiRC6iszK6LCwxBE6T0JzXomNn1gXFxDl6EcQz7gAlmgDC7qGYyz1VCxO9c_lbgbC-9oFZqSDzsnQBFYSQWk23tm5ziuFsBB0ijnL4bsuPu9zTQU/http%3A%2F%2Fwww.algonet.se%2F%7Eparlei%2Fquotes.html
 */


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of 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.

From: IBM Mainframe Discussion List  on behalf of 
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, were ushered 
on to the big-boy stage, and shareability was suddenly de rigueur. So began 
still-developing Rube Goldberg mechanisms to keep multiple users out of each 
other's shorts. After decades of flailing around, the only 'security tool' 
trusted by weenie-ware folks with something important to protect is server 
isolation. Let's be clear. The major reason for the mind-boggling proliferation 
of midrange servers is not the need for more MIPS and gigabytes. It's the 
fundamental distrust common to all non-mainframe users that anyone else allowed 
onto MY hardware is a potential mugger. One app, one server. You got a problem 
with that? The boss will buy you your own server.

--
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: BLKSIZE=0 (was: Crazy ...)

[Jesse 1 Robinson]

With the thread having been rechristened, I'm not sure who gets the OP title. I 
was the OOP. Turns out there was actually no BLKSIZE error. The problem was 
Fault Analyzer's rush to judgment after an SQL data choke. OTOH I'm pretty sure 
that BLKSIZE=0 would help only to set the max value  of 32760.   

.
.
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 
Seymour J Metz
Sent: Tuesday, May 7, 2019 10:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: BLKSIZE=0 (was: Crazy ...)

There were documented cases where you still needed an explicit block size for 
the for the concatenation. Based on the OP, it would appear that there still 
are.


--
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: Tuesday, May 7, 2019 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BLKSIZE=0 (was: Crazy ...)

On Tue, 7 May 2019 15:33:39 +, Seymour J Metz wrote:

>Well, removed except when it wasn't; there were caveats.
>
  ???
>
>From: Tom Marchant
>Sent: Tuesday, May 7, 2019 11:02 AM
>
>>What about BUFL=? As I recall, I used to use this to keep from having 
>>problems with concatenations...
>
>Yes, until about 25 years ago, when the requirement that the first data 
>set of a partitioned data set concatenation have the largest BLKSIZE 
>was removed.
>
Silly (naive?) me.  I just coded an overriding BLKSIZE on the first catenand. 
Or supplied a leading empty temp DSN with suitable attributes.
Would that satisfy the "caveats"?

Same for LRECL.

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

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

If you already have update access to APF libraries then it's no longer an issue 
of OS security, but one of personnel security. Getting equivalent privileges in 
windoze makes taking the machine over a no brainer.  The issue is how easy it 
to illicitly gain privileges in each OS.


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


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

I was really talking about things I'd do once I got APF/RACF authority.
On Windows even if I got admin auth on a server, I wouldn't know what to
do with it.

On 5/7/2019 10:46 AM, Seymour J Metz wrote:
> How will knowledge of control blocks, SVCs, etc., allow you to escalate your 
> privileges beyond those assigned to your userid and groupid?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Tom Brennan 
> Sent: Monday, May 6, 2019 9:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: mainframe hacking "success stories"?
>
> Ok, but why is Windows easier to hack than the mainframe?
>
> Personally, I'd find a mainframe far easier to hack because I know a
> little bit about control blocks, APF auth, SVC's, subsystems, address
> spaces, RACF, etc., and I know far less about the equivalents on
> Windows.  But of course the first step is to get any kind of userid, and
> that's done by pretty-much the same methods - regardless of platform.
>
> On 5/6/2019 1:18 PM, Bill Johnson wrote:
>> It’s why banks stay on the mainframe. Security.
>>
>>
>> Sent from Yahoo Mail for iPhone
>>
>>
>> On Monday, May 6, 2019, 4:09 PM, Bigendian Smalls 
>>  wrote:
>>
>> Bill, would you care to back that sweeping generalization up with some 
>> detail?
>>
>>> On May 6, 2019, at 22:06, Bill Johnson 
>>> <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
>>>
>>> Completely different. Hacking Microsoft is way easier.
>>>
>>>
>>> Sent from Yahoo Mail for iPhone
>>>
>>>
>>> On Monday, May 6, 2019, 3:53 PM, Bigendian Smalls 
>>>  wrote:
>>>
>>> Which is how 80% of all the hacks today start.  Find purchase and advance 
>>> your position. This is how the game is played. It was as classic of a hack 
>>> as anything today.
>>>
 On May 6, 2019, at 21:43, Bill Johnson 
 <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

 Still never would have occurred without a valid userid.


 Sent from Yahoo Mail for iPhone


 On Monday, May 6, 2019, 3:18 PM, Charles Mills  wrote:

 No.

   From the link you cite:

 "According to various sources, the hackers succeeded in finding (and 
 exploiting) at least 2 previously unknown errors enabling them to raise 
 their authorisations in the system. One of them was an error in an IBM 
 HTTP server and the other one was an error in the CNMEUNIX file, which in 
 the default configuration has SUID 0 authorisations (which means that by 
 leveraging on the errors it contains, one is able to execute commands with 
 the system administrator’s authorisations)."

 His "user" access to InfoTorg was not a problem for the mainframe. (It was 
 a problem for the MPAA lawyer whose account he accessed, but not for the 
 mainframe in general.) The above mainframe security vulnerability was.

 Charles


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

 The Pirate Bay hack acquired a valid mainframe userid and password off of 
 a Microsoft laptop. In effect, not really a mainframe hack. He just logged 
 on. 
 https://secure-web.cisco.com/1EiUBe8kWIGocAoCHZ8duxx_X3_ii_2_msH4KXaCbsI05OQ4V0kZ0pcTIXpwXTnEXNJkg9GeqVs-R7IzdSX9GnIfcJrObS1D825ZM8nJeSoB6vNzJa2xDGqRXXNZvwK78Iko8hdQw6zS2R6griNgSM3snpLMvdrvHola_yv9zPXwr3f6_IlZ7zMV0PzBZ-SGsvsDr51V7r3Nf9n5gmq2VbONzowLmg5ZZIqqVK1uZXvW9mgP95d8wKnt8qt0yiAh5CB5la2Ub6ctm1NEEnN28D9JkOoehxhmkVmnssVIWwcAmZcPc3YZR4CHcmwQYA0gTScHJJs4dlOuGr6oKCL6mLSnp3kcELzP0FYC6m1v535CyCj7Fno_rt5ZWPmdLK8io3_XlgKB1xTTcjg9LhBDjwf7zqa9Iwg0Fse4BZ-eBCmUliiBCBkA7FPCEcbalillZW5RyF3YVzqmqEU4hm_I0Ig/https%3A%2F%2Fbadcyber.com%2Fa-history-of-a-hacking%2F

 Sent from Yahoo Mail for iPhone


 On Monday, May 6, 2019, 1:21 PM, 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 g

Re: mainframe hacking "success stories"?

[Seymour J Metz]

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


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


From: IBM Mainframe Discussion List  on behalf of Tom 
Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, May 7, 2019 2:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

On Tue, 7 May 2019 17:12:48 +, Jesse 1 Robinson wrote:

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

The earliest microprocessors had nothing equivalent to supervisor state, 
privileged instructions , or storage protect keys. PC operating systems, 
including several releases of Windows, were written without the benefit of any 
of these. Every program had full access to everything that the processor could 
do. 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.

--
Tom Marchant

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

[Jesse 1 Robinson]

(Resurrecting an old thread) We're being 'urged' to demonstrate that we can 
fail over to our internal DR site, run for a while, then fail back. As I 
indicated previously, we've done countless short tests but never allowed 
production to run in DR; hence no need to fail back. My question here is not 
technical. Our DR site (self-owned and managed) runs normally with a single CP 
supported by enough CBU to run production. We have purchased several full power 
tests to enable up to 10 days of testing per outing. If you have a similar 
setup, 

1. Have you performed an extended full-power test?

2. Does the 10-day testing limit come into play?

3. From our perspective, we are only testing, but we would be dealing with real 
production data in and out. Will this lead to a contractual conundrum?



.
.
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 van 
der Grijn, Bart (B)
Sent: Monday, June 5, 2017 5:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: DR Failover

The people doing the MF recovery vary by test. It's typically someone on the 
operational side of the house, with the folks that maintain the procedures 
riding shotgun. 
Our sysprog team is geographically dispersed (US/NL/PRC) so chances are there's 
someone left that wasn't swallowed by the giant crater. 

Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, June 01, 2017 6:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DR Failover

Never got traction on two of my questions, which are independent of technology.

-- During a failover (test I would presume), who actually performs the DR 
procedure whatever it is? Sysprogs, operators, production control folks, or 
someone else? Has anyone dared to bring in a non-technical person like a 
manager? This question is crucial to business resiliency because, depending the 
reason for failover, your top technical folks may be indisposed for an extended 
duration.

-- If you stayed in the DR environment long enough to have captured/updated 
live customer data, how did you eventually return to the production 
environment? This question is crucial to business resiliency because at some 
point down the line, you have to return or, as the poem goes, settle in for a 
long winter's nap.  


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

RACF database unprotected? That's not a properly secured system, any more than 
one with default passwords is.


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


From: IBM Mainframe Discussion List  on behalf of 
Knutson, Samuel 
Sent: Monday, May 6, 2019 3:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

The attacker created zero day exploits against z/OS in the wild allowing 
escalation of privilege and proved difficult to dislodge even once discovered.
Information available to the public supports this.  Phil Young has done a good 
job of dissecting the hack.

Philip Young - Smashing the Mainframe for Fun and Prison Time 
https://secure-web.cisco.com/1WHZO7R_IzgaHmdSwc5fSpAsKhWqVG-Hc8oqhS1AazIb1z9MntaVwwZo5ffUYnhUSo1yf8zD5sr1au8SYtE-JcwOypzxfKX_kJMguP7cUGE7LrhWfUr0e_Z--o2sXZAhUD-ZgjqMrnZaae6eqL_cxNZgbZKqKbcc20i5UU51GSxTvvrYXSsEPMZySnINGr52STdXBoH8zY2CDpzo1qrc6K8eRA_MAb9G1KhY8l0Yt6yOj7VyYgNzCxlzZjKt71yrZ8YuGRS5Df2Z_DSIJtAp2KL0R_uzcHshox7vsvk3y5PGoZRl9M24EStow5L5rzczUpBcLFd1K5IYn5xSrqKXEhYome2AfmDfwaQt5mRdy3IHX3gjKpmMGHI1vduL9foUdWRYO5pplujaSlpEzZ3GQ6heQcgXBymhLBVQqAR_N33qWnLANE_IdF6FIDBwgIzvA/https%3A%2F%2Fyoutu.be%2FSjtyifWTqmc

And

How Hackers Breached a Government (and a Bank)
https://secure-web.cisco.com/1c-YbwF54FIR_OVKsBQbi_FSQ_Buj6SAGBnZFwi8hiRIbp9GtVg_GYvf1iyySH4aPQFGUiDHmRBocoAihCpRRpUh8Cw1k3aE-dp9f_d-NWYWtq1CNeOb7qMYbzaMRGEp03yU38Eu6RLBq6fEQUvHQv4EqGKA6V-BAIYm2U2zNq-URUcl4jhaa7rxKZDLOr2uXmh64_vgh1tDlm_q8zfe3DMSIv96ZgKylj_T6Dz2pnh1tYh7uoKRdb_LX6CJkokmqk2sWGQlRtTJieL7JvQOIH_Y-G5AzxE_Tnk2-igiY2AF0D47kcSLMbSEhxRgdIpeTzQoPqXu0bvj63rfoPjgkbEWPY_NzU_M_R3Dl0mKJpRF7iu3T63VWhwkNkWcIa1rAqLB6o1Y05Aq_fczPj6FrliYbLY7ShGQrmB2pTBJkzt8ILHbZwKUvY8B6V5tWvUaM/https%3A%2F%2Fshare.confex.com%2Fshare%2F124%2Fwebprogram%2FHandout%2FSession16982%2FHow%2520Hackers%2520Breached%2520a%2520Government%2520%2528and%2520a%2520Bank%2529.pdf

z/OS on IBMz hardware is the most securable environment in the world but as 
public evidence supports it was compromised.
It would seem fair to say the mainframe was hacked.

Best Regards,
Sam Knutson

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Johnson
Sent: Monday, May 6, 2019 2:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

Exactly.


Sent from Yahoo Mail for iPhone


On Monday, May 6, 2019, 2:43 PM, ITschak Mugzach  wrote:

Yes. Just logged on... And had access to all databases. This us how they was 
caught. Too much queries per second.

בתאריך יום ב׳, 6 במאי 2019, 21:17, מאת Bill Johnson ‏<
0047540adefe-dmarc-requ...@listserv.ua.edu>:

> The Pirate Bay hack acquired a valid mainframe userid and password off
> of a Microsoft laptop. In effect, not really a mainframe hack. He just
> logged on. 
> https://secure-web.cisco.com/1FHcvIN9JU6P3HDRd5Nm3kzXT9GShrhJ2swTQh93tmIsKYH_nTMhNb1Xy4Z1wExjMZmlhtneijXsWajoTs4dODCTJK0Gns1Lhn0TGX7NFQoMPaf45QoXHxV_3P5HRmQE1oWL65CRqRiAMbCLvrwemiSSt-2PQTF4uIXWTyPa6nl1H2VSpk24KRUCzUgm39kP3MLQa5vs2JEi9jzzNSppCPXdMJm6WQnjr25jidrU3UVzHlYU6FFz_69qs5Ug0rQfdJoX6XoByi0aKn01E4nDG26HFvHKw2JuJd_U-niP5mCtABsFcVBovCc-btiFde1lim8BnwZqcXJtTyK2TwtSfdpJmsf8_L0sIEJtfEYxh5yJbUptiD-xxRNkHUi8Sm1ifykfSwyWKnAPdl0Xj7BgvnmUVI_Zk_5R1h5I5YkwNkknZZl2zQZmwAMcWbAI4DpQ9/https%3A%2F%2Fbadcyber.com%2Fa-history-of-a-hacking%2F
>
> Sent from Yahoo Mail for iPhone
>
>
> On Monday, May 6, 2019, 1:21 PM, 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
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Bill Johnson
> Sent: Sunday, May 5, 2019 10:00 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: mainframe hacking "success stories"?
>
> Wasn’t really a mainframe hack. It was a laptop hack that acquired
> legitimate mainframe credentials.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> -

Re: BLKSIZE=0 (was: Crazy ...)

[Seymour J Metz]

The post quoted a message citing the block size. The obvious fix is 
BLKSIZE=32760, not BLKSIZE=0.


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


From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Tuesday, May 7, 2019 4:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BLKSIZE=0 (was: Crazy ...)

With the thread having been rechristened, I'm not sure who gets the OP title. I 
was the OOP. Turns out there was actually no BLKSIZE error. The problem was 
Fault Analyzer's rush to judgment after an SQL data choke. OTOH I'm pretty sure 
that BLKSIZE=0 would help only to set the max value  of 32760.

.
.
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 
Seymour J Metz
Sent: Tuesday, May 7, 2019 10:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: BLKSIZE=0 (was: Crazy ...)

There were documented cases where you still needed an explicit block size for 
the for the concatenation. Based on the OP, it would appear that there still 
are.


--
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: Tuesday, May 7, 2019 11:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BLKSIZE=0 (was: Crazy ...)

On Tue, 7 May 2019 15:33:39 +, Seymour J Metz wrote:

>Well, removed except when it wasn't; there were caveats.
>
  ???
>
>From: Tom Marchant
>Sent: Tuesday, May 7, 2019 11:02 AM
>
>>What about BUFL=? As I recall, I used to use this to keep from having
>>problems with concatenations...
>
>Yes, until about 25 years ago, when the requirement that the first data
>set of a partitioned data set concatenation have the largest BLKSIZE
>was removed.
>
Silly (naive?) me.  I just coded an overriding BLKSIZE on the first catenand. 
Or supplied a leading empty temp DSN with suitable attributes.
Would that satisfy the "caveats"?

Same for LRECL.

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

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

[Bob Bridges]

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.

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

/* If the Earth were flat, cats would have pushed everything off it by now.
*/


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

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

-Original Message-
From: IBM Mainframe Discussion List  on behalf of
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: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of 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: IBM Mainframe Discussion List  on behalf of
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, were
ushered on to the big-boy stage, and shareability was suddenly de rigueur.
So began still-developing Rube Goldberg mechanisms to keep multiple users
out of each other's shorts. After decades of flailing around, the only
'security tool' trusted by weenie-ware folks with something important to
protect is server isolation. Let's be clear. The major reason for the
mind-boggling proliferation of midrange servers is not the need for more
MIPS and gigabytes. It's the fundamental distrust common to all
non-mainframe users that anyone else allowed onto MY hardware is a potential
mugger. One app, one server. You got a problem with that? The boss will buy
you your own server.

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

Re: mainframe hacking "success stories"?

[Grant Taylor]

On 5/7/19 2:28 PM, Seymour J Metz wrote:

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


My opinion is that:

   A program (core) dump is tantamount to (obfuscated) source code.

In short, the algorithm is out.  I hope your security wasn't based only 
on the secrecy of the algorithm.




--
Grant. . . .
unix || die

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

Re: [EXTERNAL MESSAGE] Passing along a job opportunity

[Blake, Daniel J [CTR]]

It's a very wide net being casted.  I've gotten three email and one voice mail. 
 The voicemail dude is out of NJ and he has called my cell four times.  If 
you're not in my contact list I don't answer.

;-D an


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Tuesday, May 07, 2019 4:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL MESSAGE] Passing along a job opportunity

I got a ping for a z/OS sysprog job in Costa Mesa, CA, figured I'd point folks 
on this list at it. If that's not OK let me know and I won't do it again.

 

To be clear: THIS IS NOT A JOB I'M HIRING FOR. DO NOT ASK ME ABOUT IT BECAUSE I 
WON'T KNOW.

Ask this guy:

Gar Thompson, Safeguard Healthcare

gthomp...@safeguard-healthcare.com  

P: 714 372-2256

C: 714 747-6337

 

Good luck. This message will self-dest


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

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


--
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:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

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.

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

/* If the Earth were flat, cats would have pushed everything off it by now.
*/


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

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

-Original Message-
From: IBM Mainframe Discussion List  on behalf of
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: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of 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: IBM Mainframe Discussion List  on behalf of
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, were
ushered on to the big-boy stage, and shareability was suddenly de rigueur.
So began still-developing Rube Goldberg mechanisms to keep multiple users
out of each other's shorts. After decades of flailing around, the only
'security tool' trusted by weenie-ware folks with something important to
protect is server isolation. Let's be clear. The major reason for the
mind-boggling proliferation of midrange servers is not the need for more
MIPS and gigabytes. It's the fundamental distrust common to all
non-mainframe users that anyone else allowed onto MY hardware is a potential
mugger. One app, one server. You

Re: BLKSIZE=0 (was: Crazy ...)

[Tom Marchant]

On Tue, 7 May 2019 21:00:45 +, Seymour J Metz wrote:

>The post quoted a message citing the block size. The obvious fix is 
>BLKSIZE=32760, not BLKSIZE=0.

I agree. I'm pretty sure that coding BLKSIZE=0 for an existing data set 
will have no effect because it is indistinguishable at OPEN time from not 
coding BLKSIZE on the DD statement. The only time BLKSIZE=0 will help 
is when the data sets are created.

-- 
Tom Marchant

>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List  on behalf of 
>Jesse 1 Robinson 
>Sent: Tuesday, May 7, 2019 4:38 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: BLKSIZE=0 (was: Crazy ...)
>
>With the thre d having been rechristened, I'm not sure who gets the OP title. 
>I was the OOP. Turns out there was actually no BLKSIZE error. The problem was 
>Fault Analyzer's rush to judgment after an SQL data choke. OTOH I'm pretty 
>sure that BLKSIZE=0 would help only to set the max value  of 32760.

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

Re: BLKSIZE=0 (was: Crazy ...)

[Seymour J Metz]

BLKSIZE is intended for writing new datasets. If you're reading an existing 
dataset then SDB isn't applicable.


--
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: Monday, May 6, 2019 2:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: BLKSIZE=0 (was: Crazy ...)

On Mon, 6 May 2019 16:44:47 +, Seymour J Metz wrote:

>Not that I know of, other then the SMF records for the input and output.
>
>From: Paul Gilmartin
>Sent: Friday, May 3, 2019 1:42 PM
>
>When IEBCOPY reblocks a module, does it leave any audit trail?  That
>might be of interest in case of the OP's problem.
>
Amidst the nattering about 32760 vs. half-track vs. 4KiB vs. ...
I suggested coding BLKSIZE=0.  That received neither support nor
opposition.  So, I wonder:

Does coding BLKSIZE=0 ever lead to complete failure of a utility or product?
I encountered one many years ago.  It was promptly fixed by APAR.

Does BLKSIZE=0 ever lead to suboptimum performance?

There might be trivial exceptions for unlabelled tapes with DISP=MOD
or for IEBGENER where SYSUT1 is already adversely blocked.

-- 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: mainframe hacking "success stories"?

[Bob Bridges]

It may be a more common exposure than I would have predicted.  I've run into
clients who have general read access to a high-level qualifier, let's say
SYS2.**, which sounds reasonable because SYS2 has lots of CLIST, load and
proc libs that all users need.  But then they drop a lot of other things in
there too; maybe SYS2.CA.ACF.** has the ACF2 database, or there's a SYS2
library where they store certificate keys.  No one stopped to think,
apparently, about what could go wrong with this.

No one needs read access to the security database.  In Top Secret, for
example, if I issue a command to list a user or permit access to a dataset,
the TSS started task looks at my authority to take that action and then does
it on its own authority.  During an installation or migration I can create
temporary access for the guy who's doing the work, set to expire
automatically after an agreed period of time (a fortnight, a month,
whatever), but that's it.  You could make an exception for the storage
manager if you really want to, but the security products even have their own
backup facilities so there just isn't much need for anyone to have read
access to the security database.

In the Swedish hack, the original stolen ID had read access to the RACF
database.  The hackers downloaded the database, then applied a dictionary
attack to it at their leisure, thus getting thousands of passwords not only
in that LPAR but in another one visited by the same users.

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

/* Ye knowe ek that in forme of speche is chaunge
Withinne a thousand yere, and wordes tho
That hadden pris, now wonder nyce and straunge
Us thinketh hem, and yit they spake hem so.
  -Geoffrey Chaucer, Troilus and Criseyde, Book 2, 22-25 */


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Tuesday, May 7, 2019 16:54
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

RACF database unprotected? That's not a properly secured system, any more
than one with default passwords is.


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


From: IBM Mainframe Discussion List  on behalf of
Knutson, Samuel 
Sent: Monday, May 6, 2019 3:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

The attacker created zero day exploits against z/OS in the wild allowing
escalation of privilege and proved difficult to dislodge even once
discovered.
Information available to the public supports this.  Phil Young has done a
good job of dissecting the hack.

Philip Young - Smashing the Mainframe for Fun and Prison Time
https://secure-web.cisco.com/1WHZO7R_IzgaHmdSwc5fSpAsKhWqVG-Hc8oqhS1AazIb1z9
MntaVwwZo5ffUYnhUSo1yf8zD5sr1au8SYtE-JcwOypzxfKX_kJMguP7cUGE7LrhWfUr0e_Z--o2
sXZAhUD-ZgjqMrnZaae6eqL_cxNZgbZKqKbcc20i5UU51GSxTvvrYXSsEPMZySnINGr52STdXBoH
8zY2CDpzo1qrc6K8eRA_MAb9G1KhY8l0Yt6yOj7VyYgNzCxlzZjKt71yrZ8YuGRS5Df2Z_DSIJtA
p2KL0R_uzcHshox7vsvk3y5PGoZRl9M24EStow5L5rzczUpBcLFd1K5IYn5xSrqKXEhYome2AfmD
fwaQt5mRdy3IHX3gjKpmMGHI1vduL9foUdWRYO5pplujaSlpEzZ3GQ6heQcgXBymhLBVQqAR_N33
qWnLANE_IdF6FIDBwgIzvA/https%3A%2F%2Fyoutu.be%2FSjtyifWTqmc

And

How Hackers Breached a Government (and a Bank)
https://secure-web.cisco.com/1c-YbwF54FIR_OVKsBQbi_FSQ_Buj6SAGBnZFwi8hiRIbp9
GtVg_GYvf1iyySH4aPQFGUiDHmRBocoAihCpRRpUh8Cw1k3aE-dp9f_d-NWYWtq1CNeOb7qMYbza
MRGEp03yU38Eu6RLBq6fEQUvHQv4EqGKA6V-BAIYm2U2zNq-URUcl4jhaa7rxKZDLOr2uXmh64_v
gh1tDlm_q8zfe3DMSIv96ZgKylj_T6Dz2pnh1tYh7uoKRdb_LX6CJkokmqk2sWGQlRtTJieL7JvQ
OIH_Y-G5AzxE_Tnk2-igiY2AF0D47kcSLMbSEhxRgdIpeTzQoPqXu0bvj63rfoPjgkbEWPY_NzU_
M_R3Dl0mKJpRF7iu3T63VWhwkNkWcIa1rAqLB6o1Y05Aq_fczPj6FrliYbLY7ShGQrmB2pTBJkzt
8ILHbZwKUvY8B6V5tWvUaM/https%3A%2F%2Fshare.confex.com%2Fshare%2F124%2Fwebpro
gram%2FHandout%2FSession16982%2FHow%2520Hackers%2520Breached%2520a%2520Gover
nment%2520%2528and%2520a%2520Bank%2529.pdf

z/OS on IBMz hardware is the most securable environment in the world but as
public evidence supports it was compromised.
It would seem fair to say the mainframe was hacked.

Best Regards,
Sam Knutson

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Bill Johnson
Sent: Monday, May 6, 2019 2:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

Exactly.


Sent from Yahoo Mail for iPhone


On Monday, May 6, 2019, 2:43 PM, ITschak Mugzach  wrote:

Yes. Just logged on... And had access to all databases. This us how they was
caught. Too much queries per second.

בתאריך יום ב׳, 6 במאי 2019, 21:17, מאת Bill Johnson ‏<
0047540adefe-dmarc-requ...@listserv.ua.edu>:

> The Pirate Bay hack acquired a valid mainframe userid and password off
> of a Microsoft laptop. In effect, not really a mainframe hack. He just
> logged on.
https://secure-web.cisco.com/1FHcvIN9JU6P3HDRd5Nm3kzXT9GShrhJ2swTQh93tmIsKYH
_nTMhNb1Xy4Z1wExjMZmlhtneijXsWajoTs4dODCTJK0Gns1Lhn0TGX7NFQoMPaf45QoXHxV_3P5
HRmQE1o

Re: mainframe hacking "success stories"?

[Grant Taylor]

On 5/7/19 2:54 PM, Seymour J Metz wrote:
RACF database unprotected? That's not a properly secured system, 
any more than one with default passwords is.


That can be said about MANY things, not just mainframes or open systems.

The robber got into a house through a window that was closed but not 
locked?  "That's not a properly secured system."


IMHO /how/ access is acquired less important than the fact unauthorized 
access /was/ acquired.




--
Grant. . . .
unix || die

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

Remember that half of all security administrators are below average. Even when 
they are competent, there may be management directives that prevent them from 
properly securing the system. BTDT,GTS (no tee shirt, just the scars.)


--
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:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

It may be a more common exposure than I would have predicted.  I've run into
clients who have general read access to a high-level qualifier, let's say
SYS2.**, which sounds reasonable because SYS2 has lots of CLIST, load and
proc libs that all users need.  But then they drop a lot of other things in
there too; maybe SYS2.CA.ACF.** has the ACF2 database, or there's a SYS2
library where they store certificate keys.  No one stopped to think,
apparently, about what could go wrong with this.

No one needs read access to the security database.  In Top Secret, for
example, if I issue a command to list a user or permit access to a dataset,
the TSS started task looks at my authority to take that action and then does
it on its own authority.  During an installation or migration I can create
temporary access for the guy who's doing the work, set to expire
automatically after an agreed period of time (a fortnight, a month,
whatever), but that's it.  You could make an exception for the storage
manager if you really want to, but the security products even have their own
backup facilities so there just isn't much need for anyone to have read
access to the security database.

In the Swedish hack, the original stolen ID had read access to the RACF
database.  The hackers downloaded the database, then applied a dictionary
attack to it at their leisure, thus getting thousands of passwords not only
in that LPAR but in another one visited by the same users.

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

/* Ye knowe ek that in forme of speche is chaunge
Withinne a thousand yere, and wordes tho
That hadden pris, now wonder nyce and straunge
Us thinketh hem, and yit they spake hem so.
  -Geoffrey Chaucer, Troilus and Criseyde, Book 2, 22-25 */


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Tuesday, May 7, 2019 16:54
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

RACF database unprotected? That's not a properly secured system, any more
than one with default passwords is.


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


From: IBM Mainframe Discussion List  on behalf of
Knutson, Samuel 
Sent: Monday, May 6, 2019 3:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

The attacker created zero day exploits against z/OS in the wild allowing
escalation of privilege and proved difficult to dislodge even once
discovered.
Information available to the public supports this.  Phil Young has done a
good job of dissecting the hack.

Philip Young - Smashing the Mainframe for Fun and Prison Time
https://secure-web.cisco.com/1WHZO7R_IzgaHmdSwc5fSpAsKhWqVG-Hc8oqhS1AazIb1z9
MntaVwwZo5ffUYnhUSo1yf8zD5sr1au8SYtE-JcwOypzxfKX_kJMguP7cUGE7LrhWfUr0e_Z--o2
sXZAhUD-ZgjqMrnZaae6eqL_cxNZgbZKqKbcc20i5UU51GSxTvvrYXSsEPMZySnINGr52STdXBoH
8zY2CDpzo1qrc6K8eRA_MAb9G1KhY8l0Yt6yOj7VyYgNzCxlzZjKt71yrZ8YuGRS5Df2Z_DSIJtA
p2KL0R_uzcHshox7vsvk3y5PGoZRl9M24EStow5L5rzczUpBcLFd1K5IYn5xSrqKXEhYome2AfmD
fwaQt5mRdy3IHX3gjKpmMGHI1vduL9foUdWRYO5pplujaSlpEzZ3GQ6heQcgXBymhLBVQqAR_N33
qWnLANE_IdF6FIDBwgIzvA/https%3A%2F%2Fyoutu.be%2FSjtyifWTqmc

And

How Hackers Breached a Government (and a Bank)
https://secure-web.cisco.com/1c-YbwF54FIR_OVKsBQbi_FSQ_Buj6SAGBnZFwi8hiRIbp9
GtVg_GYvf1iyySH4aPQFGUiDHmRBocoAihCpRRpUh8Cw1k3aE-dp9f_d-NWYWtq1CNeOb7qMYbza
MRGEp03yU38Eu6RLBq6fEQUvHQv4EqGKA6V-BAIYm2U2zNq-URUcl4jhaa7rxKZDLOr2uXmh64_v
gh1tDlm_q8zfe3DMSIv96ZgKylj_T6Dz2pnh1tYh7uoKRdb_LX6CJkokmqk2sWGQlRtTJieL7JvQ
OIH_Y-G5AzxE_Tnk2-igiY2AF0D47kcSLMbSEhxRgdIpeTzQoPqXu0bvj63rfoPjgkbEWPY_NzU_
M_R3Dl0mKJpRF7iu3T63VWhwkNkWcIa1rAqLB6o1Y05Aq_fczPj6FrliYbLY7ShGQrmB2pTBJkzt
8ILHbZwKUvY8B6V5tWvUaM/https%3A%2F%2Fshare.confex.com%2Fshare%2F124%2Fwebpro
gram%2FHandout%2FSession16982%2FHow%2520Hackers%2520Breached%2520a%2520Gover
nment%2520%2528and%2520a%2520Bank%2529.pdf

z/OS on IBMz hardware is the most securable environment in the world but as
public evidence supports it was compromised.
It would seem fair to say the mainframe was hacked.

Best Regards,
Sam Knutson

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Bill Johnson
Sent: Monday, May 6, 2019 2:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

Exactly.


Sent from Yahoo Mail for iPhone


On Monday, May 6, 2019, 2:43 PM, ITschak Mugzach  wrote:

Yes. Just logged on... And had

Re: mainframe hacking "success stories"?

[Seymour J Metz]

If you're talking about security, then there is a big difference between what 
controls are available and what you deploy. 

> The robber got into a house through a window that was closed but not
> locked? 

That's a defective resident, not a defective window.

> IMHO /how/ access is acquired less important than the fact unauthorized
> access /was/ acquired.

If you're assessing the software then it's important to know whether the 
security breach was a software problem. If you're assessing the organization 
then it's important to know how unauthorized access was obtained in order to 
prevent it from happening again. If you're a judge or juror then it's important 
to know how access was obtained in order to decide how to assess liability. The 
only context in which how isn't paramount is for the people doing spin control.


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


From: IBM Mainframe Discussion List  on behalf of 
Grant Taylor <023065957af1-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, May 7, 2019 5:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

On 5/7/19 2:54 PM, Seymour J Metz wrote:
> RACF database unprotected? That's not a properly secured system,
> any more than one with default passwords is.

That can be said about MANY things, not just mainframes or open systems.

The robber got into a house through a window that was closed but not
locked?  "That's not a properly secured system."

IMHO /how/ access is acquired less important than the fact unauthorized
access /was/ acquired.



--
Grant. . . .
unix || die

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

[Bob Bridges]

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, were
ushered on to the big-boy stage, and shareability was suddenly de rigueur.
So began still-developing Rube Goldberg mechanisms to keep multiple users
out of each other's shorts. After decades of flailing around, the only
'security tool' trusted by weenie-ware folks with something important to
protect is server isolation. Let's be clear. The major reason for the
mind-boggling proliferation of midrange servers is not the need for more
MIPS and gigabytes. It's the fundamental distrust common to all
non-mainframe users that anyone else allowed onto MY hardware is a potential

Job Postings - z/OS assembler programmers

[Kevin Loesch]

 Broadcom currently has two openings for senior level z/OS mainframe
software engineers in the Pittsburgh,PA area.

https://broadcom.wd1.myworkdayjobs.com/External_Career/job/USA-PA-Pittsburgh-Holiday-Drive/R-D-Software-Engineer-5_R006107


https://broadcom.wd1.myworkdayjobs.com/External_Career/job/USA-PA-Pittsburgh-Holiday-Drive/R-D-Software-Engineer-4_R006109


 Please contact me offline if you have any questions.

Regards,
Kevin Loesch
Broadcom Inc
kevin.loe...@broadcom.com   | broadcom.com

(My apologies if this appears as a duplicate post. I posted earlier via
Google Groups but that is not visible to the main list server).

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

Re: DR Failover

[Jackson, Rob]

Yes, we have run extended tests.  Yes, the CBU-test ten-day limit comes into 
play.  We have burned more than one CBU for a given DR test to accommodate our 
current DR folks' requirements.  (Interestingly, if you CBU your specialty 
engines, they can't automatically downgrade you if you have an active LPAR 
based solely on them . . . and I won't say anything else about that; they 
definitely downgrade you automatically otherwise.  Though they will call you 
about the expired entitlement when the code prevents the downgrade.)

On 3, we don't have any issues, as far as I know; we haven't switched actual 
prod to the DR infrastructure.  I don't think any of our contracts would 
prohibit it, and I don't think any of our vendors would frown on it.  Perhaps 
it's wishful thinking, but I think most mainframe ISVs are pretty mature about 
it and know their customers largely are not cheating.  We've paid extra for 
CUoD for special events to be fair and honest to our vendors; no one should 
have to pay for a legitimate DR test, in my very humble opinion.  If something 
goes very wrong, and you get stuck at DR for a while, I suppose that would be 
different . . . .

First Tennessee Bank
Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jesse 1 Robinson
Sent: Tuesday, May 07, 2019 4:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DR Failover

[External Email]

(Resurrecting an old thread) We're being 'urged' to demonstrate that we can 
fail over to our internal DR site, run for a while, then fail back. As I 
indicated previously, we've done countless short tests but never allowed 
production to run in DR; hence no need to fail back. My question here is not 
technical. Our DR site (self-owned and managed) runs normally with a single CP 
supported by enough CBU to run production. We have purchased several full power 
tests to enable up to 10 days of testing per outing. If you have a similar 
setup,

1. Have you performed an extended full-power test?

2. Does the 10-day testing limit come into play?

3. From our perspective, we are only testing, but we would be dealing with real 
production data in and out. Will this lead to a contractual conundrum?



.
.
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 van 
der Grijn, Bart (B)
Sent: Monday, June 5, 2017 5:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: DR Failover

The people doing the MF recovery vary by test. It's typically someone on the 
operational side of the house, with the folks that maintain the procedures 
riding shotgun.
Our sysprog team is geographically dispersed (US/NL/PRC) so chances are there's 
someone left that wasn't swallowed by the giant crater.

Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, June 01, 2017 6:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DR Failover

Never got traction on two of my questions, which are independent of technology.

-- During a failover (test I would presume), who actually performs the DR 
procedure whatever it is? Sysprogs, operators, production control folks, or 
someone else? Has anyone dared to bring in a non-technical person like a 
manager? This question is crucial to business resiliency because, depending the 
reason for failover, your top technical folks may be indisposed for an extended 
duration.

-- If you stayed in the DR environment long enough to have captured/updated 
live customer data, how did you eventually return to the production 
environment? This question is crucial to business resiliency because at some 
point down the line, you have to return or, as the poem goes, settle in for a 
long winter's nap.


--
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: mainframe hacking "success stories"?

[Charles Mills]

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

Re: Passing along a job opportunity

[Phil Smith III]

Daniel HJ Blake wrote:

>It's a very wide net being casted.  I've gotten three email and 

>one voice mail.  The voicemail dude is out of NJ and he has 

>called my cell four times.  If you're not in my contact list I don't

>answer.

 

You mean for this job? Wow. Maybe they're desperate; someone might could take 
advantage of that.


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

[Phil Smith III]

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

Re: mainframe hacking "success stories"?

[Gabe Goldberg]

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://www.linkedin.com/in/gabegoldTwitter: GabeG0

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

[Jack J. Woehr]

On 5/7/2019 9:03 PM, Phil Smith III wrote:

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


Such constitutes the ONLY legitimate business case for introducing 
Outlook into the enterprise!


--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

MODGEN vs AMODGEN

[Peter]

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

Re: mainframe hacking "success stories"?

[Gabe Goldberg]

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://www.linkedin.com/in/gabegoldTwitter: GabeG0

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