Re: mainframe hacking "success stories"?

2019-06-17 Thread Bill Johnson
Multiply that by at least 100 in 1980.


Sent from Yahoo Mail for iPhone


On Monday, June 17, 2019, 11:39 PM, Mike Schwab  wrote:

A patent about 2003 stated 21,000 sites had at least one mainframe.

On Tue, Jun 18, 2019 at 3:06 AM Charles Mills  wrote:
>
> Were there once 4 million mainframes?
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Bill Johnson
> Sent: Monday, June 17, 2019 2:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: mainframe hacking "success stories"?
>
> IBM z was more secure even when there were 1000 times more of them and a 
> million times less MSFT platforms. Target was down again over the weekend. 
> How many fools will blame the mainframe again? When it was their point of 
> sale system again.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

2019-06-17 Thread Bill Johnson
I don’t know the exact number but when I started, my employer had 2 mainframes. 
One box was a NAS9000, for production, and the other was a smaller NAS (7750 
comes to mind) for development. Just about every employer had a mainframe. Back 
then, there were more mainframes than PC’s. Green screen terminals were the 
only connection.


Sent from Yahoo Mail for iPhone


On Monday, June 17, 2019, 11:07 PM, Charles Mills  wrote:

Were there once 4 million mainframes?

Charles


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

IBM z was more secure even when there were 1000 times more of them and a 
million times less MSFT platforms. Target was down again over the weekend. How 
many fools will blame the mainframe again? When it was their point of sale 
system again.

--
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: Is there any way to convert RECFM=U to RECFM=V with a utility or script?

2019-06-17 Thread Farley, Peter x23353
Very interesting.  Collapsing the two steps and eliminating the intermediate 
Unix file also works, but I do have explicit DCB information in the JCL for 
both SYSUT1 and SYSUT2, so maybe that's what makes the IEBGENER process work 
here.

I had been told by the coworker who solicited my help that they had already 
tried IEBGENER to copy the file and that it failed, but I should have asked to 
see the job.  I'll remember that.

Thanks for the suggestion.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Monday, June 17, 2019 9:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any way to convert RECFM=U to RECFM=V with a utility or 
script?

On Tue, 18 Jun 2019 00:31:31 +, Farley, Peter x23353 wrote:

>Finally got my mount issue straightened out and got to try your suggestion. 
>IDCAMS REPRO gave errors trying to copy to the Unix output file, but IEBGENER 
>worked just fine.
>
>This did not work:
>
>//STEP0100 EXEC PGM=IDCAMS
>//SYSPRINT DD SYSOUT=*
>//INP  DD DISP=SHR,DSN=weird.recfmu.file,  
>//RECFM=U,LRECL=222,BLKSIZE=222   
>//OUT  DD PATH='/tmp/TMPFILE',   
>//FILEDATA=TEXT,PATHDISP=(KEEP,DELETE),   
>//PATHOPTS=(OWRONLY,OCREAT)   
>//SYSINDD *   
>  REPRO INFILE(INP) OUTFILE(OUT) REUSE
>//   
My experience is that IDCAMS requires DCB information on both INP and OUT.
It will not copy as IEBGENER does.  However, it will convert the format if the
information is available.

>IEBGENER with similar JCL works though:
>
>//STEP0100 EXEC PGM=IEBGENER
>//SYSPRINT DD SYSOUT=*  
>//SYSUT1   DD DISP=SHR,DSN= weird.recfmu.file,
>//RECFM=U,LRECL=222,BLKSIZE=222 
>//SYSUT2   DD PATH='/tmp/TMPFILE', 
>//FILEDATA=TEXT,PATHDISP=(KEEP,DELETE), 
>//PATHOPTS=(OWRONLY,OCREAT) 
>//SYSINDD DUMMY 
>//* 
>//STEP0200 EXEC PGM=IEBGENER
>//SYSPRINT DD SYSOUT=*  
>//SYSUT1   DD PATH='/tmp/TMPFILE', 
>//FILEDATA=TEXT,PATHDISP=(DELETE,KEEP), 
>//PATHOPTS=(ORDONLY),   
>//RECFM=V,BLKSIZE=254   
>//SYSUT2   DD  DISP=(NEW,CATLG,CATLG),
>// DSN=not.weird.vb.copy,
>// UNIT=SYSDA,SPACE=(CYL,(20,20),RLSE),  
>// DSORG=PS,RECFM=VB,LRECL=254,BLKSIZE=0
>//SYSINDD DUMMY 
>//*
What happens if you coalesce the steps and omit the UNIX temp file?

I wonder where it gets LRECL for STEP0200 SYSUT1?

-- 

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


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

2019-06-17 Thread Paul Gilmartin
On Mon, 17 Jun 2019 20:06:23 -0700, Charles Mills wrote:

>Were there once 4 million mainframes?
>
And  were they z's?

>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Bill Johnson
>Sent: Monday, June 17, 2019 2:08 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: mainframe hacking "success stories"?
>
>IBM z was more secure even when there were 1000 times more of them and a 
>million times less MSFT platforms. Target was down again over the weekend. How 
>many fools will blame the mainframe again? When it was their point of sale 
>system again.

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

2019-06-17 Thread Mike Schwab
A patent about 2003 stated 21,000 sites had at least one mainframe.

On Tue, Jun 18, 2019 at 3:06 AM Charles Mills  wrote:
>
> Were there once 4 million mainframes?
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Bill Johnson
> Sent: Monday, June 17, 2019 2:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: mainframe hacking "success stories"?
>
> IBM z was more secure even when there were 1000 times more of them and a 
> million times less MSFT platforms. Target was down again over the weekend. 
> How many fools will blame the mainframe again? When it was their point of 
> sale system again.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

2019-06-17 Thread Charles Mills
Because you don't come to SHARE? Specifically, Chad Rikansrud's security 
keynote in March of 2017.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Monday, June 17, 2019 1:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: mainframe hacking "success stories"?

Did they use z/OS?
Or maybe Linux on PC?
Not?
Windows?
What a surprise!

BTW: I have heard many times about filese encrypted by ransomware. Why 
it's always Windows? Why the only file encryption on z/OS I ever heard 
is the encryption directed by administrator?
Why?

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

2019-06-17 Thread Charles Mills
Were there once 4 million mainframes?

Charles


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

IBM z was more secure even when there were 1000 times more of them and a 
million times less MSFT platforms. Target was down again over the weekend. How 
many fools will blame the mainframe again? When it was their point of sale 
system again.

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


Re: Is there any way to convert RECFM=U to RECFM=V with a utility or script?

2019-06-17 Thread Paul Gilmartin
On Tue, 18 Jun 2019 00:31:31 +, Farley, Peter x23353 wrote:

>Finally got my mount issue straightened out and got to try your suggestion. 
>IDCAMS REPRO gave errors trying to copy to the Unix output file, but IEBGENER 
>worked just fine.
>
>This did not work:
>
>//STEP0100 EXEC PGM=IDCAMS
>//SYSPRINT DD SYSOUT=*
>//INP  DD DISP=SHR,DSN=weird.recfmu.file,  
>//RECFM=U,LRECL=222,BLKSIZE=222   
>//OUT  DD PATH='/tmp/TMPFILE',   
>//FILEDATA=TEXT,PATHDISP=(KEEP,DELETE),   
>//PATHOPTS=(OWRONLY,OCREAT)   
>//SYSINDD *   
>  REPRO INFILE(INP) OUTFILE(OUT) REUSE
>//   
My experience is that IDCAMS requires DCB information on both INP and OUT.
It will not copy as IEBGENER does.  However, it will convert the format if the
information is available.

>IEBGENER with similar JCL works though:
>
>//STEP0100 EXEC PGM=IEBGENER
>//SYSPRINT DD SYSOUT=*  
>//SYSUT1   DD DISP=SHR,DSN= weird.recfmu.file,
>//RECFM=U,LRECL=222,BLKSIZE=222 
>//SYSUT2   DD PATH='/tmp/TMPFILE', 
>//FILEDATA=TEXT,PATHDISP=(KEEP,DELETE), 
>//PATHOPTS=(OWRONLY,OCREAT) 
>//SYSINDD DUMMY 
>//* 
>//STEP0200 EXEC PGM=IEBGENER
>//SYSPRINT DD SYSOUT=*  
>//SYSUT1   DD PATH='/tmp/TMPFILE', 
>//FILEDATA=TEXT,PATHDISP=(DELETE,KEEP), 
>//PATHOPTS=(ORDONLY),   
>//RECFM=V,BLKSIZE=254   
>//SYSUT2   DD  DISP=(NEW,CATLG,CATLG),
>// DSN=not.weird.vb.copy,
>// UNIT=SYSDA,SPACE=(CYL,(20,20),RLSE),  
>// DSORG=PS,RECFM=VB,LRECL=254,BLKSIZE=0
>//SYSINDD DUMMY 
>//*
What happens if you coalesce the steps and omit the UNIX temp file?

I wonder where it gets LRECL for STEP0200 SYSUT1?

-- gil

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


Re: Is there any way to convert RECFM=U to RECFM=V with a utility or script?

2019-06-17 Thread Farley, Peter x23353
Finally got my mount issue straightened out and got to try your suggestion. 
IDCAMS REPRO gave errors trying to copy to the Unix output file, but IEBGENER 
worked just fine.

This did not work:

//STEP0100 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//INP  DD DISP=SHR,DSN=weird.recfmu.file,  
//RECFM=U,LRECL=222,BLKSIZE=222   
//OUT  DD PATH='/tmp/TMPFILE',   
//FILEDATA=TEXT,PATHDISP=(KEEP,DELETE),   
//PATHOPTS=(OWRONLY,OCREAT)   
//SYSINDD *   
  REPRO INFILE(INP) OUTFILE(OUT) REUSE
//

Results in this message in JESMSGLG:

IEC141I 013-34,IGG0199G,TSOUSER9,STEP0100,OUT

And these messages in SYSPRINT:

  REPRO INFILE(INP) OUTFILE(OUT) REUSE
IDC3300I  ERROR OPENING ...PATH=.SPECIFIED... 
IDC3321I ** OPEN/CLOSE/EOV ABEND EXIT TAKEN   
IDC0005I NUMBER OF RECORDS PROCESSED WAS 0
IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12

IEBGENER with similar JCL works though:

//STEP0100 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*  
//SYSUT1   DD DISP=SHR,DSN= weird.recfmu.file,
//RECFM=U,LRECL=222,BLKSIZE=222 
//SYSUT2   DD PATH='/tmp/TMPFILE', 
//FILEDATA=TEXT,PATHDISP=(KEEP,DELETE), 
//PATHOPTS=(OWRONLY,OCREAT) 
//SYSINDD DUMMY 
//* 
//STEP0200 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*  
//SYSUT1   DD PATH='/tmp/TMPFILE', 
//FILEDATA=TEXT,PATHDISP=(DELETE,KEEP), 
//PATHOPTS=(ORDONLY),   
//RECFM=V,BLKSIZE=254   
//SYSUT2   DD  DISP=(NEW,CATLG,CATLG),
// DSN=not.weird.vb.copy,
// UNIT=SYSDA,SPACE=(CYL,(20,20),RLSE),  
// DSORG=PS,RECFM=VB,LRECL=254,BLKSIZE=0
//SYSINDD DUMMY 
//* 

The "not.weird.vb.copy" file comes out as a normal VB file with all the right 
BDW/RDW prefixes and no LF or NL or other line delimiters at the end.

Thank you!

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter x23353
Sent: Wednesday, June 12, 2019 7:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any way to convert RECFM=U to RECFM=V with a utility or 
script?

Tried that too, but apparently my HFS file is having some trouble being mounted 
and I have to get the storage guys involved to fix it.  Bureaucratic nightmare.

When that's fixed I will definitely try it, thanks for the suggestion.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John McKown
Sent: Wednesday, June 12, 2019 4:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any way to convert RECFM=U to RECFM=V with a utility or 
script?

EXTERNAL EMAIL

Copy it to a UNIX file with FILEDATA=TEXT using IENGENER or other. Then copy it 
back to a PS dataset with appreciate LRECL and RECFM. The first step will copy 
each physical record to UNIX, and put a LF at the end to be a regular UNIX text 
file. The second step will copy the UNIX file back to FB or VB. If FB, it will 
pad with space. If VB, it will put the right LLBB at the front.

On Wed, Jun 12, 2019, 14:06 Farley, Peter x23353 < peter.far...@broadridge.com> 
wrote:

> We have a vendor-generated file that comes in with
> DCB=(RECFM=U,LRECL=200,BLKSIZE=27998) (don't ask why please, this DCB 
> setting is out of our hands).
>
> The records are actually variable length data, up to 200 bytes of 
> actual data with no length prefix (no RDW/BDW).  No binary data, only 
> text characters.  I suspect a *ix text-format file as the vendor 
> source but have no proof of that.
>
> We have tried every utility we could think of (IEBGENER, IDCAMS REPRO, 
> SORT INREC BUILD=(1,200)) to copy this data to a more usable z/OS 
> record format but so far nothing we tried works.
>
> Am I correct that only a Rexx or awk script could do this conversion 
> (given the update to Rexx to support RECFM=U files and awk's native
> capabilities) or an HLL program coded to handle U-format input can do 
> this conversion?
>
> Any other ideas you have to help us perform the conversion without 
> writing an HLL program would be much appreciated.
>
> Peter
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, 

Re: mainframe hacking "success stories"?

2019-06-17 Thread Bill Johnson
IBM z was more secure even when there were 1000 times more of them and a 
million times less MSFT platforms. Target was down again over the weekend. How 
many fools will blame the mainframe again? When it was their point of sale 
system again.


Sent from Yahoo Mail for iPhone


On Monday, June 17, 2019, 4:48 PM, R.S.  wrote:

W dniu 2019-05-13 o 02:42, Phil Smith III pisze:
> Bill Johnson posted a couple more links to mainframe blog posts from a 
> mainframe vendor-more asking the barber if you need a shave; but even 
> ignoring that, you don't appear to have actually read the articles, Bill.
>
>  
>
> The first one 
> 
>   says IBM Z is more secure because it's less common. That's not inherent 
> security; that's like saying your car is less vulnerable because you park it 
> far from the madding crowd. It may be *attacked* less, but that doesn't make 
> it inherently more *secure*.




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

2019-06-17 Thread R.S.

Did they use z/OS?
Or maybe Linux on PC?
Not?
Windows?
What a surprise!

BTW: I have heard many times about filese encrypted by ransomware. Why 
it's always Windows? Why the only file encryption on z/OS I ever heard 
is the encryption directed by administrator?

Why?

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2019-05-15 o 22:12, Edward Finnell pisze:

Dang those pesky servers

https://www.usnews.com/news/national-news/articles/2019-05-07/baltimore-targeted-by-ransomware-attack-city-shuts-down-most-of-its-servers
In a message dated 5/15/2019 12:14:19 PM Central Standard Time, 
0047540adefe-dmarc-requ...@listserv.ua.edu writes:
Microsoft (MSFT) is warning users about a monster computer bug.

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



==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2018 r. wynosi 169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169,248,488 as at 1 January 2018.

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

2019-06-17 Thread R.S.

W dniu 2019-05-13 o 02:42, Phil Smith III pisze:

Bill Johnson posted a couple more links to mainframe blog posts from a 
mainframe vendor-more asking the barber if you need a shave; but even ignoring 
that, you don't appear to have actually read the articles, Bill.

  


The first one 

  says IBM Z is more secure because it's less common. That's not inherent security; 
that's like saying your car is less vulnerable because you park it far from the 
madding crowd. It may be *attacked* less, but that doesn't make it inherently more 
*secure*.


No. Assuming no system is 100% secure we can assume every system has 
*some* holes. The hole can be discovered by someone, however the less 
people try the less likely it would happen.

Remember Navajo Indians Code Talkers?

Another example could be Linux on aunt's workstation. Aunt (uncle, 
grandpa...) is not educated in computer security, however changing 
Windows to Linux makes 99% of attacks impossible.


That's real life, and that kind of "obscurity" really provides security 
advantage.



--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2018 r. wynosi 169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169,248,488 as at 1 January 2018.

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


Re: Volume compare utility

2019-06-17 Thread Jesse 1 Robinson
We have been devoted fans and customers of TDMF since long before IBM acquired 
it. I stand in awe of its magical properties. But it is a bit clumsy when 
copying/moving thousands of volumes shared by many LPARs. The method we used 
this time was far more suited to our purpose. 

.
.
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 
Jerry Whitteridge
Sent: Monday, June 17, 2019 8:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Volume compare utility

"What" should have been "way" !

Jerry Whitteridge
Delivery Manager / Mainframe Architect
GTS - Safeway Account
602 527 4871 Mobile
jerry.whitteri...@ibm.com

IBM Services

IBM Mainframe Discussion List  wrote on
06/17/2019 08:29:34 AM:

> From: Jerry Whitteridge 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/17/2019 08:30 AM
> Subject: [EXTERNAL] Re: Volume compare utility Sent by: IBM Mainframe 
> Discussion List 
>
> In the (distant) past we've been able to get a temporary license from 
> the vendor of the target disk for TDMF as part of the deal - might be 
> one
what
> of you getting a portion of your bridge.
>
> Jerry Whitteridge
> Delivery Manager / Mainframe Architect GTS - Safeway Account
> 602 527 4871 Mobile
> jerry.whitteri...@ibm.com
>
> IBM Services
>
> IBM Mainframe Discussion List  wrote on
> 06/16/2019 01:16:35 PM:
>
> > From: Jesse 1 Robinson 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 06/16/2019 01:16 PM
> > Subject: [EXTERNAL] Re: Volume compare utility Sent by: IBM 
> > Mainframe Discussion List 
> >
> > Maybe if I could throw in the Brooklyn Bridge...
> >
> > .
> > .
> > 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

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


Re: Need for a z/OS "master index" (Was RE: LOAD/LINK exit) [SEC=UNOFFICIAL]

2019-06-17 Thread Seymour J Metz
Why not IDCAMS?


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


From: IBM Mainframe Discussion List  on behalf of 
Jones, Phil <02379a6d81f2-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, June 16, 2019 7:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Need for a z/OS "master index" (Was RE: LOAD/LINK exit) 
[SEC=UNOFFICIAL]

Ah yes... The good old days, when the question may have been as you wrote: "if 
you were new to this platform, how would you ever guess that the tool to copy a 
file (oops, dataset) was named IEBGENER and was documented in a manual named 
"DFSMSdfp Utilities"? Wouldn't it be great if a newbie could just go "Watson! 
How do I copy a file?""

The answer would have been IEBGENER if the dataset happened to be SEQUENTIAL, 
but not if it was PARTITIONED. And certainly not if it was VSAM.

Written (half) in jest...   :-)

Regards; Phil

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Monday, 17 June 2019 4:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Need for a z/OS "master index" (Was RE: LOAD/LINK exit)

Exactly! You hit on one of the other problems: when you find an answer, how do 
you know it is THE answer?

OGET. OPUT. ISPF 3.3. Etc.

In fact the original question here is a matter of finding AN answer
(CSVLLIX1 -- but no good, it only does LLA) and then it turning out there was 
ANOTHER answer that did indeed fill the bill.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Friday, June 14, 2019 12:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Need for a z/OS "master index" (Was RE: LOAD/LINK exit)

I thought that the program to copy a dataset was IDCAMS. IEHMOVE? IEBCOPY?
The COPY command from COPY, FORMAT, LIST and MERGE (sic)?


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


From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Friday, June 14, 2019 12:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Need for a z/OS "master index" (Was RE: LOAD/LINK exit)

Yes! I remembered this exit being added to z/OS. I looked and looked and looked 
at Installation Exits and when I could not find it, figured I must have read 
more into CSVLLIXn than really existed.

z/OS desperately needs some sort of "master index." IBM has the AI to be able 
to put up a site that could answer questions like "how do I monitor every FETCH 
or LOAD?" (or, for that matter, "how do I convert RECFM=U into RECFM=V?"). The 
platform really needs it. How often do we see questions here where the answer 
is "it's right in the manual! RTFM you dummy!" The problem is "how would I know 
to look in that manual?"

My favorite example: if you were new to this platform, how would you ever guess 
that the tool to copy a file (oops, dataset) was named IEBGENER and was 
documented in a manual named "DFSMSdfp Utilities"? Wouldn't it be great if a 
newbie could just go "Watson! How do I copy a file?"

Just as an experiment, I just keyed "how copy a z/OS file" into KC and got lots 
of hits, but not one of them was for IEBGENER. Changing file to dataset at 
least gets me close: the fourth hit is for pervasive encryption and IEBGENER.

Maybe we just need to learn to use KC more. You know what? I keyed the original 
question, "how monitor every fetch and load" into KC and the very first hit was 
for CSVFETCH.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
** 
IMPORTANT: This e-mail is for the use of the intended recipient only and may 
contain information that is confidential, commercially valuable and/or subject 
to legal or parliamentary privilege. If you are not the intended recipient you 
are notified that any review, re-transmission, disclosure, dissemination or 
other use of, or taking of any action in reliance upon, this information is 
prohibited and may result in severe penalties. If you have received this e-mail 
in error please notify the sender immediately and delete all electronic and 
hard copies of this transmission together with any attachments. Please consider 
the environment before printing this e-mail 
**

--
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: VTOC reading

2019-06-17 Thread Seymour J Metz
> The relevant subroutine - XVTCREAD - uses a CCW chain to read an entire 
> track in a single EXCP,

Wow! It must be really old. Ever since the 3350 we had Read Multiple Count Key 
Data.


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


From: IBM Mainframe Discussion List  on behalf of 
Greg Price 
Sent: Monday, June 17, 2019 10:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VTOC reading

On 2019-06-14 7:58 AM, Mike Shaw wrote:
> CVAF is much slower than BSAM, alphabetical order or not. EXCP with
> chained CCWs is much faster, then just sort the DSNs yourself.

In the "LOAD/LINK exit" thread, Graeme mentioned the products named
Dorana and SoftAudit.

SoftAudit was from Isogon (who also produced SPIFFY and probably other
products I can't recall). Isogon was acquired by IBM, around the 2005
time frame.

Dorana was started by Ubiquity because they could not get a good
distribution deal for SoftAudit in Australia. I wrote the first program
for it in 1996, which was the DASD scanner.

SoftAudit could not make a new sale outside the US pretty much so IBM
acquired the Dorana product in 2006 with a view to kill the competition,
at least as we thought. (Dorana could not be sold in the US because of a
lack of funds to bust a patent which Isogon did not actually use, but
for which it was assumed they would claim infringement. It was thought
that if the funds were available then the patent could almost certainly
be busted, but that, of course, remains conjecture. That particular
patent has now expired.)

In 2007 I was hired (in Australia) by IBM New York because, it turns
out, they thought I was someone else. (I think that's funny.)
Unfortunately for them, I was not the C++ coder who wrote the one bit of
Dorana they were interested in - a component called the Match Engine -
but merely an assembler guy, and they already had lots of assembler
talent. (I also do a bit of PL/I. The current IBM product still ships a
couple of PL/I programs - probably a rarity these days.)

But a contract is a contract, and so I was still on the books when IBM
grew dissatisfied with the ex-Isogon team to the extent that they gave
the whole project to IBM ADL.

The ADL team preferred Dorana over SoftAudit (perhaps they thought DB2
was superior to ISPF tables as a scalable DBMS), and were happy enough
to retain the services of an original developer.

IBM had renamed SoftAudit to Tivoli License Compliance Manager for z/OS,
or TLCMz for short. Dorana was renamed to Tivoli Asset Discovery for
z/OS which I was told had no official abbreviation but the unofficial
one of TADz soon became its de facto handle.

(Actually, the original IBM name for it was Hardware and Software
Identification for z/OS or HSIz for the limited release of 7.1, but by
7.2 it was TADz. It still uses the component prefix of HSI.)


And now I finally get to the thread relevance - reading VTOCs. When I
wrote the "Inquisitor" as I called it, it used a routine sourced from an
Amdahl SE-supplied program called SUPERLST, which was really just a
version of XVTCLIST as found on the CBT tape.

The relevant subroutine - XVTCREAD - uses a CCW chain to read an entire
track in a single EXCP, so this seemed like a good routine to use - even
better because it was in the public domain, put there by a couple of
very large US corporations who had separately donated the code to the
CBT tape in the 1980s.

As TLCMz level 3 from 2008 until it went EOS in 2010, I was interested
to see that they had used the same routine in their DASD scanner - the
"Surveyor".

So, XVTCREAD - the VTOC reading routine originally written around
1966/1967 - has given and is still giving grand service today in 2019,
over 50 years later.  Now that's compatibility!


Cheers,
Greg


Disclaimer: The recollections, views and opinions stated above are my
own and do not represent any official statement. No guarantees as to
their accuracy are given.

--
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: Volume compare utility

2019-06-17 Thread Jerry Whitteridge
"What" should have been "way" !

Jerry Whitteridge
Delivery Manager / Mainframe Architect
GTS - Safeway Account
602 527 4871 Mobile
jerry.whitteri...@ibm.com

IBM Services

IBM Mainframe Discussion List  wrote on
06/17/2019 08:29:34 AM:

> From: Jerry Whitteridge 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/17/2019 08:30 AM
> Subject: [EXTERNAL] Re: Volume compare utility
> Sent by: IBM Mainframe Discussion List 
>
> In the (distant) past we've been able to get a temporary license from the
> vendor of the target disk for TDMF as part of the deal - might be one
what
> of you getting a portion of your bridge.
>
> Jerry Whitteridge
> Delivery Manager / Mainframe Architect
> GTS - Safeway Account
> 602 527 4871 Mobile
> jerry.whitteri...@ibm.com
>
> IBM Services
>
> IBM Mainframe Discussion List  wrote on
> 06/16/2019 01:16:35 PM:
>
> > From: Jesse 1 Robinson 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 06/16/2019 01:16 PM
> > Subject: [EXTERNAL] Re: Volume compare utility
> > Sent by: IBM Mainframe Discussion List 
> >
> > Maybe if I could throw in the Brooklyn Bridge...
> >
> > .
> > .
> > 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
> >
>
> --
> 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: Volume compare utility

2019-06-17 Thread Jerry Whitteridge
In the (distant) past we've been able to get a temporary license from the
vendor of the target disk for TDMF as part of the deal - might be one what
of you getting a portion of your bridge.

Jerry Whitteridge
Delivery Manager / Mainframe Architect
GTS - Safeway Account
602 527 4871 Mobile
jerry.whitteri...@ibm.com

IBM Services

IBM Mainframe Discussion List  wrote on
06/16/2019 01:16:35 PM:

> From: Jesse 1 Robinson 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/16/2019 01:16 PM
> Subject: [EXTERNAL] Re: Volume compare utility
> Sent by: IBM Mainframe Discussion List 
>
> Maybe if I could throw in the Brooklyn Bridge...
>
> .
> .
> 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
>

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


Re: VTOC reading

2019-06-17 Thread Greg Price

On 2019-06-14 7:58 AM, Mike Shaw wrote:
CVAF is much slower than BSAM, alphabetical order or not. EXCP with 
chained CCWs is much faster, then just sort the DSNs yourself.


In the "LOAD/LINK exit" thread, Graeme mentioned the products named 
Dorana and SoftAudit.


SoftAudit was from Isogon (who also produced SPIFFY and probably other 
products I can't recall). Isogon was acquired by IBM, around the 2005 
time frame.


Dorana was started by Ubiquity because they could not get a good 
distribution deal for SoftAudit in Australia. I wrote the first program 
for it in 1996, which was the DASD scanner.


SoftAudit could not make a new sale outside the US pretty much so IBM 
acquired the Dorana product in 2006 with a view to kill the competition, 
at least as we thought. (Dorana could not be sold in the US because of a 
lack of funds to bust a patent which Isogon did not actually use, but 
for which it was assumed they would claim infringement. It was thought 
that if the funds were available then the patent could almost certainly 
be busted, but that, of course, remains conjecture. That particular 
patent has now expired.)


In 2007 I was hired (in Australia) by IBM New York because, it turns 
out, they thought I was someone else. (I think that's funny.) 
Unfortunately for them, I was not the C++ coder who wrote the one bit of 
Dorana they were interested in - a component called the Match Engine - 
but merely an assembler guy, and they already had lots of assembler 
talent. (I also do a bit of PL/I. The current IBM product still ships a 
couple of PL/I programs - probably a rarity these days.)


But a contract is a contract, and so I was still on the books when IBM 
grew dissatisfied with the ex-Isogon team to the extent that they gave 
the whole project to IBM ADL.


The ADL team preferred Dorana over SoftAudit (perhaps they thought DB2 
was superior to ISPF tables as a scalable DBMS), and were happy enough 
to retain the services of an original developer.


IBM had renamed SoftAudit to Tivoli License Compliance Manager for z/OS, 
or TLCMz for short. Dorana was renamed to Tivoli Asset Discovery for 
z/OS which I was told had no official abbreviation but the unofficial 
one of TADz soon became its de facto handle.


(Actually, the original IBM name for it was Hardware and Software 
Identification for z/OS or HSIz for the limited release of 7.1, but by 
7.2 it was TADz. It still uses the component prefix of HSI.)



And now I finally get to the thread relevance - reading VTOCs. When I 
wrote the "Inquisitor" as I called it, it used a routine sourced from an 
Amdahl SE-supplied program called SUPERLST, which was really just a 
version of XVTCLIST as found on the CBT tape.


The relevant subroutine - XVTCREAD - uses a CCW chain to read an entire 
track in a single EXCP, so this seemed like a good routine to use - even 
better because it was in the public domain, put there by a couple of 
very large US corporations who had separately donated the code to the 
CBT tape in the 1980s.


As TLCMz level 3 from 2008 until it went EOS in 2010, I was interested 
to see that they had used the same routine in their DASD scanner - the 
"Surveyor".


So, XVTCREAD - the VTOC reading routine originally written around 
1966/1967 - has given and is still giving grand service today in 2019, 
over 50 years later.  Now that's compatibility!



Cheers,
Greg


Disclaimer: The recollections, views and opinions stated above are my 
own and do not represent any official statement. No guarantees as to 
their accuracy are given.


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


Re: honorpriority=no in WLM

2019-06-17 Thread Horst Sinram
Duncan,

why do you believe that HonorPriority=No could help? You will only be confining 
work to the already potentially overloaded zIIPs by disallowing help from the 
CPs. So, HonorPriority=No can only make things worse.
I assume that you don't want to go so far and configure all zIIPs offline to 
that partition; the way to go is really having sufficient zIIP capacity for 
your workload peaks.

Horst Sinram - IBM z/OS Workload and Capacity Management

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