Re: z/OS version of Netcat

[Attila Fogarasi]

https://github.com/mainframed/NC110-OMVS

On Sat, Oct 9, 2021 at 8:14 AM Jerry Whitteridge <
jerry.whitteri...@albertsons.com> wrote:

> Is anyone aware of a version of Netcat that works with Unix Systems
> Services ? Was there something in the Tools and Toys page
>
> Jerry Whitteridge
> jerry.whitteri...@albertsons.com
> Manager Mainframe Systems & HP Non-Stop
> Albertsons Companies
>
> 
> Warning: All e-mail sent to this address will be received by the corporate
> e-mail system, and is subject to archival and review by someone other than
> the recipient. This e-mail may contain proprietary information and is
> intended only for the use of the intended recipient(s). If the reader of
> this message is not the intended recipient(s), you are notified that you
> have received this message in error and that any review, dissemination,
> distribution or copying of this message is strictly prohibited. If you have
> received this message in error, please notify the sender immediately.
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: COBOL 6.2 - use of identical data name in a nested COMMON subprogram generates a IGYPS0037-S compiler error

[Wayne Bickerdike]

Oops, yes it is in the code snippet.

On Sat, Oct 9, 2021 at 2:22 PM Wayne Bickerdike  wrote:

> It's not obvious from the code snippet. I agree with Mike Schwab, qualify
> the name. The duplicate could be in a COPY statement.
>
> On Sat, Oct 9, 2021 at 11:24 AM Mike Schwab 
> wrote:
>
>> >  01 RECORD-NAME.
>> >   05  SUBSECTION-NAME.
>>
>> >  MOVE SUBSECTION-NAME TO WS-SUBSECTION-NAME.
>>
>> > 25779  IGYPS0037-S   "SUBSECTION-NAME" was not a uniquely defined
>> name.  The definition to be used could not be determined from the
>> >   context.  The reference to the name was discarded.
>>
>> You have multiple SUBSECTION-NAME variables.  You need to qualify by
>> coding
>> MOVE SUBSECTION-NAME OF RECORD-NAME TO WS-SUBSECTION-NAME.
>>
>> Applies to all versions of COBOL.
>>
>> On Sat, Oct 9, 2021 at 1:02 AM Farley, Peter x23353
>> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>> >
>> > This is an Enterprise COBOL V6.2 question.  I am not sure if this is a
>> compiler issue or a programmer misunderstanding issue.
>> >
>> > I have a COBOL subroutine which has multiple nested programs within
>> it.  The general structure is as follows (it's actually far more
>> complicated with COPY members and such, but this shows the basic issue).
>> Note carefully that the INSIDE1 subroutine is declared COMMON because other
>> nested subroutines (not shown here) may also CALL it besides the CALL from
>> the top-level program:
>> >
>> > ID DIVISION.
>> > PROGRAM-ID.  SUBMAIN.
>> > . . . . .
>> > WORKING-STORAGE SECTION.
>> >  01 RECORD-NAME.
>> >   05  SUBSECTION-NAME.
>> > 10  SUBSECTION-VAR PIC X.
>> > PROCEDURE DIVISION.
>> > . . . . .
>> >CALL "INSIDE1" USING RECORD-NAME.
>> > . . . . .
>> >
>> > ID DIVISION.
>> > PROGRAM-ID. INSIDE1 COMMON.
>> > . . . . .
>> > WORKING-STORAGE SECTION.
>> >  01  WS-AREA.
>> >05 WS-SUBSECTION-NAME PIC X.
>> > LINKAGE SECTION.
>> >  01 RECORD-NAME.
>> >   05  SUBSECTION-NAME.
>> >10  SUBSECTION-VAR PIC X.
>> > . . . . .
>> > PROCEDURE DIVISION USING RECORD-NAME.
>> > . . . . .
>> >  MOVE SUBSECTION-NAME TO WS-SUBSECTION-NAME.
>> > . . . . .
>> >  EXIT PROGRAM.
>> > END-PROGRAM INSIDE1.
>> >
>> > END-PROGRAM SUBMAIN.
>> >
>> > The MOVE statement in the nested subroutine INSIDE1 gets this COBOL
>> error:
>> >
>> > 25779  IGYPS0037-S   "SUBSECTION-NAME" was not a uniquely defined
>> name.  The definition to be used could not be determined from the
>> >   context.  The reference to the name was discarded.
>> >
>> > The V6.2 Language Reference Manual on page 60 says this about using
>> identical names in nested programs:
>> >
>> > "Identical names
>> > When programs are directly or indirectly contained within other
>> programs, each program can use identical
>> > user-defined words to name resources.
>> > A program references the resources that program describes rather than
>> the same-named resources
>> > described in another program, even if the names are different types of
>> user-defined words."
>> >
>> > Is that language in the manual telling me that I may have a compiler
>> bug here, or am I misunderstanding the language in the manual and have to
>> code the names used in the nested subroutine differently (e.g., by using a
>> unique prefix for all the common data names or at least for the top-level
>> name)?
>> >
>> > TIA for any assistance you can provide.
>> >
>> > 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, 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
>>
>>
>>
>> --
>> 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
>>
>
>
> --
> Wayne V. Bickerdike
>
>

-- 
Wayne V. Bickerdike

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

Re: COBOL 6.2 - use of identical data name in a nested COMMON subprogram generates a IGYPS0037-S compiler error

[Wayne Bickerdike]

It's not obvious from the code snippet. I agree with Mike Schwab, qualify
the name. The duplicate could be in a COPY statement.

On Sat, Oct 9, 2021 at 11:24 AM Mike Schwab  wrote:

> >  01 RECORD-NAME.
> >   05  SUBSECTION-NAME.
>
> >  MOVE SUBSECTION-NAME TO WS-SUBSECTION-NAME.
>
> > 25779  IGYPS0037-S   "SUBSECTION-NAME" was not a uniquely defined name.
> The definition to be used could not be determined from the
> >   context.  The reference to the name was discarded.
>
> You have multiple SUBSECTION-NAME variables.  You need to qualify by coding
> MOVE SUBSECTION-NAME OF RECORD-NAME TO WS-SUBSECTION-NAME.
>
> Applies to all versions of COBOL.
>
> On Sat, Oct 9, 2021 at 1:02 AM Farley, Peter x23353
> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > This is an Enterprise COBOL V6.2 question.  I am not sure if this is a
> compiler issue or a programmer misunderstanding issue.
> >
> > I have a COBOL subroutine which has multiple nested programs within it.
> The general structure is as follows (it's actually far more complicated
> with COPY members and such, but this shows the basic issue).  Note
> carefully that the INSIDE1 subroutine is declared COMMON because other
> nested subroutines (not shown here) may also CALL it besides the CALL from
> the top-level program:
> >
> > ID DIVISION.
> > PROGRAM-ID.  SUBMAIN.
> > . . . . .
> > WORKING-STORAGE SECTION.
> >  01 RECORD-NAME.
> >   05  SUBSECTION-NAME.
> > 10  SUBSECTION-VAR PIC X.
> > PROCEDURE DIVISION.
> > . . . . .
> >CALL "INSIDE1" USING RECORD-NAME.
> > . . . . .
> >
> > ID DIVISION.
> > PROGRAM-ID. INSIDE1 COMMON.
> > . . . . .
> > WORKING-STORAGE SECTION.
> >  01  WS-AREA.
> >05 WS-SUBSECTION-NAME PIC X.
> > LINKAGE SECTION.
> >  01 RECORD-NAME.
> >   05  SUBSECTION-NAME.
> >10  SUBSECTION-VAR PIC X.
> > . . . . .
> > PROCEDURE DIVISION USING RECORD-NAME.
> > . . . . .
> >  MOVE SUBSECTION-NAME TO WS-SUBSECTION-NAME.
> > . . . . .
> >  EXIT PROGRAM.
> > END-PROGRAM INSIDE1.
> >
> > END-PROGRAM SUBMAIN.
> >
> > The MOVE statement in the nested subroutine INSIDE1 gets this COBOL
> error:
> >
> > 25779  IGYPS0037-S   "SUBSECTION-NAME" was not a uniquely defined name.
> The definition to be used could not be determined from the
> >   context.  The reference to the name was discarded.
> >
> > The V6.2 Language Reference Manual on page 60 says this about using
> identical names in nested programs:
> >
> > "Identical names
> > When programs are directly or indirectly contained within other
> programs, each program can use identical
> > user-defined words to name resources.
> > A program references the resources that program describes rather than
> the same-named resources
> > described in another program, even if the names are different types of
> user-defined words."
> >
> > Is that language in the manual telling me that I may have a compiler bug
> here, or am I misunderstanding the language in the manual and have to code
> the names used in the nested subroutine differently (e.g., by using a
> unique prefix for all the common data names or at least for the top-level
> name)?
> >
> > TIA for any assistance you can provide.
> >
> > 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, 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
>
>
>
> --
> 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
>


-- 
Wayne V. Bickerdike

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

Re: Passing user/pw in to BPXBATCH SFTP

[David Crayford]

That's a really bad idea! Just use "ssh-keygen" to create an SSH key. 
You can use "ssh-copy-id" to copy your SSH key to the target system you 
want to connect to.


On 9/10/2021 4:19 am, Billy Ashton wrote:
Hi all! I see we have been talking some about FTPS, so now I want to 
spin the letters around for SFTP with an easy question-I hope!


Does anyone have a batch job/JCL that they use for SFTP that hides a 
user/password? I have looked for some hours at Google, and everything 
I see has the user and password in clear text. I am looking for 
something like the NETRC file, or some other method you folks use for 
running SFTP in BPXBATCH.


Also, I could be running up against the line limit for a single line 
SFTP command with my different options (I am specifying particular 
ciphers), and wonder if there is a way to make SFTP a multi-line command.


Thanks for all your help!
Billy

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

[David Crayford]

On 8/10/2021 7:50 am, Tom Brennan wrote:
I'll repeat what I always say about this.  If I was hacking a 
mainframe I wouldn't start with the mainframe, I'd start with the 
sysprog or security admin's PC or Mac or email or phone or whatever.  
In that case it doesn't matter one bit how well the mainframe is 
protected internally.


Exactly! Even the sophisticated malware such as stuxnet infected their 
targets using USB thumb drives. It's not some magical network hacking 
like we see in those ridiculous movies with the 3D graphics and barking 
animated guard dogs.


One of my colleagues was working in the IBM OMVS development team when 
the Logica breach occurred. The bottom line is the attacker used a 
zero-day attack. Anyone that believes the mainframe is impervious to 
zero-day attacks is dangerously naive. The source code is
on github https://github.com/mainframed/logica. The zero-day exploit was 
a REXX exec. There are also shell-injection exploits and all sorts of 
ingenious hacks.


It's also unfair to frame z/OS UNIX as the weak link just because of the 
Logica breach. I'm lucky enough to work with some very smart and highly 
experienced people and have heard very disconcerting stories about 
security exposures in vendor code. The magic SVCs have already
been mentioned but I've even heard anecdotes about stealing passwords 
from VTAM buffers.





And please stop with the political remarks.  This seems to be the one 
place on earth I can go without reading about politics.  A place where 
I can enjoy a 50+ post back-and-forth between Seymour and Gil, for 
example, without hearing one word about US politics.


On 10/7/2021 3:21 PM, Bill Johnson wrote:
You’d have to be a poorly run shop to permit any of those to occur. 
Maybe that’s why mainframe hacks have actually never 
happened.Biden successfully extracted 124,000 from Afghanistan in 
a few weeks. Amazing.



Sent from Yahoo Mail for iPhone


On Thursday, October 7, 2021, 2:12 PM, Charles Mills 
 wrote:


And assuming you never make a mistake. Never leave an APF data set 
unprotected. Never give the wrong person console authority. Fully 
understand APF on UNIX. Never have a Rexx PDS used by privileged 
users that is modifiable by others. Have no magic SVCs. Have no 
flawed APF code, no APF "tools" available inappropriately.


Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
On Behalf Of Radoslaw Skorupka

Sent: Wednesday, October 6, 2021 2:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe ransomware solution

W dniu 05.10.2021 o 15:24, Tommy Tsui pisze:

Hi
   Any shop implement mainframe ransomware solution can share? IBM 
seems has

cyber vault to handle this. Is there any other solution available ?
Thanks for sharing



Yes, we have such solution.
This is combination of the following products:
1. z/OS
2. RACF
3. Professional staff


Other means:
RACF
backup
Safeguarded copy and other vendors' solutions
audit
procedures

Note: all of the "solutions" marketed nowadays give you some cure *after
breach happened*. However that means some problems. It is unlikely to
restore with RPO=0. If you want RPO=0 then you should pay much more
attention at prevention, which means ...no, NOT ANOTHER PRODUCT.
Definitely first: professional staff, procedures, audit. And then maybe
some tools.
IBM Cyber Resiliency tools: Guardium, zSecure Suite, QRadar SIEM,
Safeguarded Copy...

--
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: Passing user/pw in to BPXBATCH SFTP

[Michael Oujesky]

Must be quite a set of parameters to bust 32K,

At 05:15 PM 10/8/2021, Paul Gilmartin wrote:


On Fri, 8 Oct 2021 16:19:56 -0500, Michael Oujesky wrote:

>If I recollect correctly, we had both the userid and password in an
>encrypted file that duirng the file transfer job was decrypted to a
>VIO dataset that was used as the input to the data transfer facility.
>
How did you keep the key to decrypt?  I supose ICSF would do.
Is it in storage momentarily in the clear?

>What Line limit are you dealing with?  72 or larger?
>
With BPXBATCH STDPARM, the limit is not 72, nor 100, but 32767.

-- 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: COBOL 6.2 - use of identical data name in a nested COMMON subprogram generates a IGYPS0037-S compiler error

[Mike Schwab]

>  01 RECORD-NAME.
>   05  SUBSECTION-NAME.

>  MOVE SUBSECTION-NAME TO WS-SUBSECTION-NAME.

> 25779  IGYPS0037-S   "SUBSECTION-NAME" was not a uniquely defined name.  The 
> definition to be used could not be determined from the
>   context.  The reference to the name was discarded.

You have multiple SUBSECTION-NAME variables.  You need to qualify by coding
MOVE SUBSECTION-NAME OF RECORD-NAME TO WS-SUBSECTION-NAME.

Applies to all versions of COBOL.

On Sat, Oct 9, 2021 at 1:02 AM Farley, Peter x23353
<031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>
> This is an Enterprise COBOL V6.2 question.  I am not sure if this is a 
> compiler issue or a programmer misunderstanding issue.
>
> I have a COBOL subroutine which has multiple nested programs within it.  The 
> general structure is as follows (it's actually far more complicated with COPY 
> members and such, but this shows the basic issue).  Note carefully that the 
> INSIDE1 subroutine is declared COMMON because other nested subroutines (not 
> shown here) may also CALL it besides the CALL from the top-level program:
>
> ID DIVISION.
> PROGRAM-ID.  SUBMAIN.
> . . . . .
> WORKING-STORAGE SECTION.
>  01 RECORD-NAME.
>   05  SUBSECTION-NAME.
> 10  SUBSECTION-VAR PIC X.
> PROCEDURE DIVISION.
> . . . . .
>CALL "INSIDE1" USING RECORD-NAME.
> . . . . .
>
> ID DIVISION.
> PROGRAM-ID. INSIDE1 COMMON.
> . . . . .
> WORKING-STORAGE SECTION.
>  01  WS-AREA.
>05 WS-SUBSECTION-NAME PIC X.
> LINKAGE SECTION.
>  01 RECORD-NAME.
>   05  SUBSECTION-NAME.
>10  SUBSECTION-VAR PIC X.
> . . . . .
> PROCEDURE DIVISION USING RECORD-NAME.
> . . . . .
>  MOVE SUBSECTION-NAME TO WS-SUBSECTION-NAME.
> . . . . .
>  EXIT PROGRAM.
> END-PROGRAM INSIDE1.
>
> END-PROGRAM SUBMAIN.
>
> The MOVE statement in the nested subroutine INSIDE1 gets this COBOL error:
>
> 25779  IGYPS0037-S   "SUBSECTION-NAME" was not a uniquely defined name.  The 
> definition to be used could not be determined from the
>   context.  The reference to the name was discarded.
>
> The V6.2 Language Reference Manual on page 60 says this about using identical 
> names in nested programs:
>
> "Identical names
> When programs are directly or indirectly contained within other programs, 
> each program can use identical
> user-defined words to name resources.
> A program references the resources that program describes rather than the 
> same-named resources
> described in another program, even if the names are different types of 
> user-defined words."
>
> Is that language in the manual telling me that I may have a compiler bug 
> here, or am I misunderstanding the language in the manual and have to code 
> the names used in the nested subroutine differently (e.g., by using a unique 
> prefix for all the common data names or at least for the top-level name)?
>
> TIA for any assistance you can provide.
>
> 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, 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



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

COBOL 6.2 - use of identical data name in a nested COMMON subprogram generates a IGYPS0037-S compiler error

[Farley, Peter x23353]

This is an Enterprise COBOL V6.2 question.  I am not sure if this is a compiler 
issue or a programmer misunderstanding issue.

I have a COBOL subroutine which has multiple nested programs within it.  The 
general structure is as follows (it's actually far more complicated with COPY 
members and such, but this shows the basic issue).  Note carefully that the 
INSIDE1 subroutine is declared COMMON because other nested subroutines (not 
shown here) may also CALL it besides the CALL from the top-level program:

ID DIVISION.
PROGRAM-ID.  SUBMAIN.
. . . . . 
WORKING-STORAGE SECTION.
 01 RECORD-NAME.
  05  SUBSECTION-NAME.
10  SUBSECTION-VAR PIC X.
PROCEDURE DIVISION.
. . . . . 
   CALL "INSIDE1" USING RECORD-NAME.
. . . . . 

ID DIVISION.
PROGRAM-ID. INSIDE1 COMMON.
. . . . .
WORKING-STORAGE SECTION.
 01  WS-AREA.
   05 WS-SUBSECTION-NAME PIC X.
LINKAGE SECTION.
 01 RECORD-NAME.
  05  SUBSECTION-NAME.
   10  SUBSECTION-VAR PIC X.
. . . . . 
PROCEDURE DIVISION USING RECORD-NAME.
. . . . . 
 MOVE SUBSECTION-NAME TO WS-SUBSECTION-NAME.
. . . . . 
 EXIT PROGRAM.
END-PROGRAM INSIDE1.

END-PROGRAM SUBMAIN.

The MOVE statement in the nested subroutine INSIDE1 gets this COBOL error:

25779  IGYPS0037-S   "SUBSECTION-NAME" was not a uniquely defined name.  The 
definition to be used could not be determined from the
  context.  The reference to the name was discarded.

The V6.2 Language Reference Manual on page 60 says this about using identical 
names in nested programs: 

"Identical names
When programs are directly or indirectly contained within other programs, each 
program can use identical
user-defined words to name resources.
A program references the resources that program describes rather than the 
same-named resources
described in another program, even if the names are different types of 
user-defined words."

Is that language in the manual telling me that I may have a compiler bug here, 
or am I misunderstanding the language in the manual and have to code the names 
used in the nested subroutine differently (e.g., by using a unique prefix for 
all the common data names or at least for the top-level name)?

TIA for any assistance you can provide.

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, 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: Passing user/pw in to BPXBATCH SFTP

[Paul Gilmartin]

On Fri, 8 Oct 2021 16:19:56 -0500, Michael Oujesky wrote:

>If I recollect correctly, we had both the userid and password in an
>encrypted file that duirng the file transfer job was decrypted to a
>VIO dataset that was used as the input to the data transfer facility.
> 
How did you keep the key to decrypt?  I supose ICSF would do.
Is it in storage momentarily in the clear?

>What Line limit are you dealing with?  72 or larger?
> 
With BPXBATCH STDPARM, the limit is not 72, nor 100, but 32767.

-- gil

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

Re: Passing user/pw in to BPXBATCH SFTP

[Allan Staller]

Classification: Confidential

There are a number of hacks that obscure the password in SFTP batch.
The easiest and best method I have come across are public/private keypairs

The keypairs may be stored in your ESM, or in the Unix File System.
I heartily recommend CoZ:SFTP Toolkit (WWW.DOVETAIL.COM) . Free to use, $$$ for 
support.

The major enhancement over IBM "vanilla" SFTP is support for z/OS datasets. 
"Vanilla SFTP" from IBM does not do this.

There is far more to be discussed, if you decide t o go down this road,

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Billy Ashton
Sent: Friday, October 8, 2021 3:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Passing user/pw in to BPXBATCH SFTP

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hi all! I see we have been talking some about FTPS, so now I want to spin the 
letters around for SFTP with an easy question-I hope!

Does anyone have a batch job/JCL that they use for SFTP that hides a 
user/password? I have looked for some hours at Google, and everything I see has 
the user and password in clear text. I am looking for something like the NETRC 
file, or some other method you folks use for running SFTP in BPXBATCH.

Also, I could be running up against the line limit for a single line SFTP 
command with my different options (I am specifying particular ciphers), and 
wonder if there is a way to make SFTP a multi-line command.

Thanks for all your help!
Billy

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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


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

Re: Linkling an object from VSE to be used in z/OS

[Tony Thigpen]

All I know is that the first MVS (or was it OS/390?) shop I worked with, 
back in 1983, called them phases. After that shop, I was in VSE shops 
until 10 years ago. Only upon returning to VSE did I first hear "load 
module" and "objects". I just figured that when they moved to using 
"Binder", they stopped using the old term.


Tony Thigpen

Seymour J Metz wrote on 10/8/21 5:15 PM:

z/OS has program objects and load modules. Within legacy load modules there 
might be segments or overlays. But a/OS does not have phases.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Thigpen [t...@vse2pdf.com]
Sent: Friday, October 8, 2021 11:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Linkling an object from VSE to be used in z/OS

A phase in z/VSE is the same as a phase in z/OS, But, the CSECT info is
not as complete as in z/OS. While z/OS has the information for the
original different CSECTs used to build the phase, z/VSE only saves the
main CSECT identification information. Restated, all the subroutines
that may have been hard-linked to the phase are in the phase, but there
is not enough information to remove or replace one of the csects.

So, when you punch the phase from z/VSE, you will see only one CSECT for
the total program.

In this discussion, the problem is that even if the COBOLII program was
linked with LE 'parts' in z/VSE, those LE 'parts' may try to use z/VSE
only pointers to branch into LE.

So, I don't think it's going to work.

Tony Thigpen

Seymour J Metz wrote on 10/8/21 10:12 AM:

What do you consider to be the MVS equivalent of a phase, and what utility are 
you using to convert a load module to an object module?

Certainly you can relink (rebind) and delete extraneous csects but that's 
somewhat of a manual process and still doesn't give you card images.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Thigpen [t...@vse2pdf.com]
Sent: Thursday, October 7, 2021 8:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Linkling an object from VSE to be used in z/OS

Don't expect it to work. When VSE punches a phase, the link deck created
includes any called modules without any way to get them out. This is in
contrast to z/OS which produces all the individual modules.

Tony Thigpen

Gadi Ben-Avi wrote on 10/7/21 3:22 AM:

Hi,
I was asked to attempt to link a object deck from VSE in z/OS.
The program is a COBOL2 program, but the source has been lost.

The first few lines of the object deck are:
W PHASE JKHIVX52,S+X'00'
W MODE AMODE(31),RMODE(ANY)
W.ESD  ..  ..JKHIVX52.§.©..÷0

After that there are many (A little over 12,000) lines that start with W.TXT
Next there are lines that start with W.RLD and a final like that starts with 
W.END.

The JCL I used was
//LKED EXEC  PGM=IEWL,
// PARM='LIST,XREF,NOLET,MAP',
// REGION=2M
//SYSLIN   DD DSN=N623.PMKA.KPMAT.JKHIVX52,DISP=SHR
//SYSLMOD  DD  DSNAME=V110GAD.LOAD(JKHIVX52),DISP=SHR
//SYSUT1   DD  UNIT=3390,SPACE=(CYL,(1,1))
//SYSPRINT DD  SYSOUT=*
//SYSINDD  *
  INCLUDE SYSLIN(JKHIVX52)
  NAME JKHIVX52(R)

I am doing something wrong?
Can this deck be linked into a usable z/OS load module?

Thanks

Gadi



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



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

Re: Passing user/pw in to BPXBATCH SFTP

[Michael Oujesky]

If I recollect correctly, we had both the userid and password in an 
encrypted file that duirng the file transfer job was decrypted to a 
VIO dataset that was used as the input to the data transfer facility.


What Line limit are you dealing with?  72 or larger?

At 03:19 PM 10/8/2021, Billy Ashton wrote:

Content-Transfer-Encoding: 7bit

Hi all! I see we have been talking some about FTPS, so now I want to 
spin the letters around for SFTP with an easy question-I hope!


Does anyone have a batch job/JCL that they use for SFTP that hides a 
user/password? I have looked for some hours at Google, and 
everything I see has the user and password in clear text. I am 
looking for something like the NETRC file, or some other method you 
folks use for running SFTP in BPXBATCH.


Also, I could be running up against the line limit for a single line 
SFTP command with my different options (I am specifying particular 
ciphers), and wonder if there is a way to make SFTP a multi-line command.


Thanks for all your help!
Billy

--
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: Linkling an object from VSE to be used in z/OS

[Seymour J Metz]

z/OS has program objects and load modules. Within legacy load modules there 
might be segments or overlays. But a/OS does not have phases.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Thigpen [t...@vse2pdf.com]
Sent: Friday, October 8, 2021 11:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Linkling an object from VSE to be used in z/OS

A phase in z/VSE is the same as a phase in z/OS, But, the CSECT info is
not as complete as in z/OS. While z/OS has the information for the
original different CSECTs used to build the phase, z/VSE only saves the
main CSECT identification information. Restated, all the subroutines
that may have been hard-linked to the phase are in the phase, but there
is not enough information to remove or replace one of the csects.

So, when you punch the phase from z/VSE, you will see only one CSECT for
the total program.

In this discussion, the problem is that even if the COBOLII program was
linked with LE 'parts' in z/VSE, those LE 'parts' may try to use z/VSE
only pointers to branch into LE.

So, I don't think it's going to work.

Tony Thigpen

Seymour J Metz wrote on 10/8/21 10:12 AM:
> What do you consider to be the MVS equivalent of a phase, and what utility 
> are you using to convert a load module to an object module?
>
> Certainly you can relink (rebind) and delete extraneous csects but that's 
> somewhat of a manual process and still doesn't give you card images.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Tony Thigpen [t...@vse2pdf.com]
> Sent: Thursday, October 7, 2021 8:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Linkling an object from VSE to be used in z/OS
>
> Don't expect it to work. When VSE punches a phase, the link deck created
> includes any called modules without any way to get them out. This is in
> contrast to z/OS which produces all the individual modules.
>
> Tony Thigpen
>
> Gadi Ben-Avi wrote on 10/7/21 3:22 AM:
>> Hi,
>> I was asked to attempt to link a object deck from VSE in z/OS.
>> The program is a COBOL2 program, but the source has been lost.
>>
>> The first few lines of the object deck are:
>> W PHASE JKHIVX52,S+X'00'
>> W MODE AMODE(31),RMODE(ANY)
>> W.ESD  ..  ..JKHIVX52.§.©..÷0
>>
>> After that there are many (A little over 12,000) lines that start with W.TXT
>> Next there are lines that start with W.RLD and a final like that starts with 
>> W.END.
>>
>> The JCL I used was
>> //LKED EXEC  PGM=IEWL,
>> // PARM='LIST,XREF,NOLET,MAP',
>> // REGION=2M
>> //SYSLIN   DD DSN=N623.PMKA.KPMAT.JKHIVX52,DISP=SHR
>> //SYSLMOD  DD  DSNAME=V110GAD.LOAD(JKHIVX52),DISP=SHR
>> //SYSUT1   DD  UNIT=3390,SPACE=(CYL,(1,1))
>> //SYSPRINT DD  SYSOUT=*
>> //SYSINDD  *
>>  INCLUDE SYSLIN(JKHIVX52)
>>  NAME JKHIVX52(R)
>>
>> I am doing something wrong?
>> Can this deck be linked into a usable z/OS load module?
>>
>> Thanks
>>
>> Gadi
>>
>>
>>
>> --
>> 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

z/OS version of Netcat

[Jerry Whitteridge]

Is anyone aware of a version of Netcat that works with Unix Systems Services ? 
Was there something in the Tools and Toys page

Jerry Whitteridge
jerry.whitteri...@albertsons.com
Manager Mainframe Systems & HP Non-Stop
Albertsons Companies


Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


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

Re: IBM JCL Expert preview in today's announcement letter

[Seymour J Metz]

It's easy to write a REXX function in assembler to return the output of a 
DESERV in compound variables.

Isn't there a stage for listing directories?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Friday, October 8, 2021 2:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM JCL Expert preview in today's announcement letter

On Fri, 8 Oct 2021 14:42:57 +, Seymour J Metz wrote:

>DCB=(LRECL=256,BLKSIZE=256) works well. I've' also used KEYLEN=8, However, is 
>there any reason not to use DESERV for new code?
>
Rexx?

Pipelines?

-- 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: Passing user/pw in to BPXBATCH SFTP

[Paul Gilmartin]

On Fri, 8 Oct 2021 16:19:29 -0400, Billy Ashton wrote:
>
>Does anyone have a batch job/JCL that they use for SFTP that hides a
>user/password? I have looked for some hours at Google, and everything I
>see has the user and password in clear text. I am looking for something
>like the NETRC file, or some other method you folks use for running SFTP
>in BPXBATCH.
> 


>Also, I could be running up against the line limit for a single line
>SFTP  ...

What's the "line limit"?

-- gil

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

Re: IEARBUP/IEARBUPM

[Ed Jaffe]

On 10/8/2021 12:07 PM, Carmen Vitullo wrote:
I should have review the doc also, I see now what you are saying, and 
if I was a betting man I'd think it was inadvertently documented in 
IEARBUP



Apparently, it got renamed late in the development cycle and no one 
updated the IEARBUP macro prologue to match the new name:


IHARBUP

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Passing user/pw in to BPXBATCH SFTP

[Billy Ashton]

Hi all! I see we have been talking some about FTPS, so now I want to 
spin the letters around for SFTP with an easy question-I hope!


Does anyone have a batch job/JCL that they use for SFTP that hides a 
user/password? I have looked for some hours at Google, and everything I 
see has the user and password in clear text. I am looking for something 
like the NETRC file, or some other method you folks use for running SFTP 
in BPXBATCH.


Also, I could be running up against the line limit for a single line 
SFTP command with my different options (I am specifying particular 
ciphers), and wonder if there is a way to make SFTP a multi-line command.


Thanks for all your help!
Billy

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

Re: Mainframe ransomware solution

[Bob Bridges]

Yes, that's the one.  I can read a number of languages, but Polish isn't among 
them; I fed that article to Google Translate, and with a few bobbles it did a 
fair job.  I remember a reference in the translation to the "FTP hotel", which 
I guessed means the FTP server, but for the most part the meaning was pretty 
obvious.

The actual Logica report was written in Swinglish -- but it was good Swinglish, 
and anyway I worked 14 years at a Volvo company so it wasn't strange :).

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

/* There are two possible outcomes.  If the result confirms the hypothesis, 
then you've made a measurement.  If the result is contrary to the hypothesis, 
then you've made a discovery.  -Enrico Fermi */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Friday, October 8, 2021 14:15

Yes, I remember this article. I also read that in Polish. :-) And at the time 
whole police report was leaked. 200+ pages.
It was definitely impossible without intercepted password and many 
configuration mistakes.
HTTP vulnerability was also there, but it was not the way to hack in.

https://zaufanatrzeciastrona.pl/historia-pewnego-wlamania/   (still in Polish, 
inside links to several articles)

--- W dniu 08.10.2021 o 16:54, Bob Bridges pisze:
> The way I read in the long Polish article about the Logica hack, when I 
> researched it back in 2013, is that there was speculation about USS and about 
> an HTTP flaw, but the forensics folks in the end thought they probably got 
> hold of a password in the good old-fashioned way and went from there.  They 
> did indeed find and exploit USS configuration goofs.  And the HTTP flaw is 
> real (https://nvd.nist.gov/vuln/detail/CVE-2012-5955), but Logica's post-hack 
> report doesn't mention it; so they, at least, didn't think it figured into 
> the original break-in or in the culprits' activities afterward.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Charles Mills
> Sent: Thursday, October 7, 2021 18:49
>
> Assuming you don't count Logica. ("Oh, that wasn't a real mainframe hack, 
> they came in through USS.")
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Bill Johnson
> Sent: Thursday, October 7, 2021 3:21 PM
>
> You’d have to be a poorly run shop to permit any of those to occur. Maybe 
> that’s why mainframe hacks have actually never happened

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

Re: Linkling an object from VSE to be used in z/OS

[Wayne Bickerdike]

Phase is equivalent of load module.

On Sat, Oct 9, 2021, 05:37 Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 8 Oct 2021 11:30:44 -0400, Tony Thigpen wrote:
>
> >A phase in z/VSE is the same as a phase in z/OS, But, the CSECT info is
> >not as complete as in z/OS.
> >
> What's a "phase in z/OS"?
>
> I need a vocabulary lesson. or a citation to a manual.
>
> -- 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: IEARBUP/IEARBUPM

[Carmen Vitullo]

I should have review the doc also, I see now what you are saying, and if 
I was a betting man I'd think it was inadvertently documented in IEARBUP


Carmen

On 10/8/2021 2:00 PM, Carmen Vitullo wrote:

I found on my 2.4 target sysres

SYS1.MACLIB(IEARBUP), the text your referred to is in this maco

Carmen

On 10/8/2021 1:47 PM, Paul Schuster wrote:

Hi:

In the z/os 2.4 MVS Programming: Authorized
Assembler Services Reference, Volume 2
(EDT-IXG) in the IEARBUP section, there is this sentence:

"Macro IEARBUPM provides equate symbols for the return and reason 
codes."


However, IEARBUPM doesn't seem to be in MACLIB or MODGEN.

So 1) was it inadvertently not shipped in MACLIB or MODGEN, or 2) was 
it inadvertently documented in IEARBUP?


Just wondering.

Thank you.

Paul

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


--
/I am not bound to win, but I am bound to be true. I am not bound to 
succeed, but I am bound to live by the light that I have. I must stand 
with anybody that stands right, and stand with him while he is right, 
and part with him when he goes wrong. *Abraham Lincoln*/


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

Re: IEARBUP/IEARBUPM

[Carmen Vitullo]

I found on my 2.4 target sysres

SYS1.MACLIB(IEARBUP), the text your referred to is in this maco

Carmen

On 10/8/2021 1:47 PM, Paul Schuster wrote:

Hi:

In the z/os 2.4 MVS Programming: Authorized
Assembler Services Reference, Volume 2
(EDT-IXG) in the IEARBUP section, there is this sentence:

"Macro IEARBUPM provides equate symbols for the return and reason codes."

However, IEARBUPM doesn't seem to be in MACLIB or MODGEN.

So 1) was it inadvertently not shipped in MACLIB or MODGEN, or 2) was it 
inadvertently documented in IEARBUP?

Just wondering.

Thank you.

Paul

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


--
/I am not bound to win, but I am bound to be true. I am not bound to 
succeed, but I am bound to live by the light that I have. I must stand 
with anybody that stands right, and stand with him while he is right, 
and part with him when he goes wrong. *Abraham Lincoln*/


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

Re: Mainframe ransomware solution

[Skip Robinson]

I'm sort of intrigued by the notion of 'magical SVC'. I know it's a figure
of speech, but I categorically disbelieve in magic. For the whipper
snappers among us, our beloved SDSF started out in the 1980s as an
IUP--installed user program. Written as I understand it by a couple of IBM
customer SEs. It was called Interactive Spool Facility; hence the ubiquity
of the ISF prefix throughout the product.

'SDSF' was marketed by IBM and eventually--after strong customer
demand--elevated to a Class 1 product with full Support Center involvement.
>From the beginning, even as an IUP, SDSF needed to run APF authorized. That
was accomplished by a magical SVC'. Customers were uncomfortable with that
solution for the same reasons discussed in this thread. The solution
attempted was to make some elaborate checks in the SVC to verify that it
was in fact being issued by the IBM product. At some point the whole SVC
strategy was abandoned. Modern SDSF no longer requires any magic SVC. I
have not heard of any customer concern over the current implementation.

On Fri, Oct 8, 2021 at 11:15 AM Radoslaw Skorupka 
wrote:

> Yes, I remember this article. I also read that in Polish. :-)
> And at the time whole police report was leaked. 200+ pages.
> It was definitely impossible without intercepted password and many
> configuration mistakes.
> HTTP vulnerability was also there, but it was not the way to hack in.
>
> https://zaufanatrzeciastrona.pl/historia-pewnego-wlamania/   (still in
> Polish, inside links to several articles)
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
> W dniu 08.10.2021 o 16:54, Bob Bridges pisze:
> > The way I read in the long Polish article about the Logica hack, when I
> researched it back in 2013, is that there was speculation about USS and
> about an HTTP flaw, but the forensics folks in the end thought they
> probably got hold of a password in the good old-fashioned way and went from
> there.  They did indeed find and exploit USS configuration goofs.  And the
> HTTP flaw is real (https://nvd.nist.gov/vuln/detail/CVE-2012-5955), but
> Logica's post-hack report doesn't mention it; so they, at least, didn't
> think it figured into the original break-in or in the culprits' activities
> afterward.
> >
> > ---
> > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >
> > /* I've never hated a man enough to give him his diamonds back.
> -Zsa-Zsa Gabor */
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> Behalf Of Charles Mills
> > Sent: Thursday, October 7, 2021 18:49
> >
> > Assuming you don't count Logica. ("Oh, that wasn't a real mainframe
> hack, they came in through USS.")
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Bill Johnson
> > Sent: Thursday, October 7, 2021 3:21 PM
> >
> > You’d have to be a poorly run shop to permit any of those to occur.
> Maybe that’s why mainframe hacks have actually never happened
>
> --

Skip Robinson
323-715-0595

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

IEARBUP/IEARBUPM

[Paul Schuster]

Hi:

In the z/os 2.4 MVS Programming: Authorized
Assembler Services Reference, Volume 2
(EDT-IXG) in the IEARBUP section, there is this sentence:

"Macro IEARBUPM provides equate symbols for the return and reason codes."

However, IEARBUPM doesn't seem to be in MACLIB or MODGEN.  

So 1) was it inadvertently not shipped in MACLIB or MODGEN, or 2) was it 
inadvertently documented in IEARBUP?

Just wondering.

Thank you.

Paul

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

Re: Linkling an object from VSE to be used in z/OS

[Paul Gilmartin]

On Fri, 8 Oct 2021 11:30:44 -0400, Tony Thigpen wrote:

>A phase in z/VSE is the same as a phase in z/OS, But, the CSECT info is 
>not as complete as in z/OS. 
>
What's a "phase in z/OS"?

I need a vocabulary lesson. or a citation to a manual.

-- gil

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

Re: IBM JCL Expert preview in today's announcement letter

[Paul Gilmartin]

On Fri, 8 Oct 2021 14:42:57 +, Seymour J Metz wrote:

>DCB=(LRECL=256,BLKSIZE=256) works well. I've' also used KEYLEN=8, However, is 
>there any reason not to use DESERV for new code?
>
Rexx?

Pipelines?

-- gil

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

Re: Mainframe ransomware solution

[Radoslaw Skorupka]

Yes, I remember this article. I also read that in Polish. :-)
And at the time whole police report was leaked. 200+ pages.
It was definitely impossible without intercepted password and many 
configuration mistakes.

HTTP vulnerability was also there, but it was not the way to hack in.

https://zaufanatrzeciastrona.pl/historia-pewnego-wlamania/   (still in 
Polish, inside links to several articles)


--
Radoslaw Skorupka
Lodz, Poland




W dniu 08.10.2021 o 16:54, Bob Bridges pisze:

The way I read in the long Polish article about the Logica hack, when I 
researched it back in 2013, is that there was speculation about USS and about 
an HTTP flaw, but the forensics folks in the end thought they probably got hold 
of a password in the good old-fashioned way and went from there.  They did 
indeed find and exploit USS configuration goofs.  And the HTTP flaw is real 
(https://nvd.nist.gov/vuln/detail/CVE-2012-5955), but Logica's post-hack report 
doesn't mention it; so they, at least, didn't think it figured into the 
original break-in or in the culprits' activities afterward.

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

/* I've never hated a man enough to give him his diamonds back.  -Zsa-Zsa Gabor 
*/

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Thursday, October 7, 2021 18:49

Assuming you don't count Logica. ("Oh, that wasn't a real mainframe hack, they came 
in through USS.")

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Johnson
Sent: Thursday, October 7, 2021 3:21 PM

You’d have to be a poorly run shop to permit any of those to occur. Maybe 
that’s why mainframe hacks have actually never happened


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

Linkling an object from VSE to be used in z/OS

[Tom Ross]

>Hi,
>I was asked to attempt to link a object deck from VSE in z/OS.
>The program is a COBOL2 program, but the source has been lost.

I have been recommending The Source Recovery Company for 25 years!
 https://www.source-recovery.com/
You can send them your executable (not the object deck) and they
can re-create the COBOL source!  The data names and paragraph names
will be machine generated, but you could compile with COBOL V6 on z/OS!

Cheers,
TomR  >> COBOL is the Language of the Future! <<

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

Re: Mainframe ransomware solution

[Bob Bridges]

Yes, an ID they got hold of -- my impression was that it was the original ID -- 
had read access to the RACF database.  They downloaded it, and posted questions 
here and there about how RACF passwords are encrypted.  Within a few days a new 
version of John the Ripper appeared, reworked for RACF.  The forensics people 
ran that version on an unexceptional PC afterward, as a test, using a 
dictionary attack of course, and as I recall they said they got ten or twenty 
thousand passwords out of it in the first day or two, which of course gave them 
access to IDs on other LPARs as well.

I'm kind of surprised how often I find that a client thinks the admins need 
update access to the security database in order to do their job.  Sometimes 
they even let me take it away; not always, my dire warnings notwithstanding.

I'm more disturbed at how often a site has a rule giving everyone read access 
to SYS2.**, which often includes the security database along with everything 
else.  I suppose they set it up that way in the beginning, "just to get things 
rolling", and never looked at it again.

About coming in through USS:  When I first wrote up the report on the Logica 
hack for my then-employer, my Conclusions section started out with this 
confession:

  Overall, what I see is that the hackers got on through a stolen password 
(obtained
  no doubt through the usual means).  Then they used OMVS to gain superuser 
access,
  UID(0), and go from there.  My jaundiced notions of Unix security, and my 
prejudice
  in favor of MVS’, are strengthened by this tale rather than weakened.  The 
problem
  with this reaction is that I know nothing of Unix; really I should learn 
something
  about it before I conclude anything.
  
  And after all, since OMVS is a part of MVS, that makes Unix part of my
  responsibility, no?

I know more about OMVS security now, but not nearly enough.

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

/* One of the justifications for democracy is that everyone's interest should 
be represented in government.  Butthe homeowner who locks his door is 
looking out for his own interest just as much as the burglar who picks the 
lock, but not exactly in the same way.  The voter who wants to keep his own 
money isn't seeking the same thing as the voter who wants the state to give him 
someone else's money.  -Joseph Sobran */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Spiegel
Sent: Friday, October 8, 2021 11:18

 From what I recall, the bad guys had "READ" to the RACF Database. (It helps to 
have incompetent SecAdmin staff and auditors.) They downloaded it and then 
dictionary-attacked it easily, because there was no password limitation and 
there was no trivial-password-exclusion list.
Also, NVAS had no security. That is, once in, the hackers could logon to any 
3270 application from the main panel.

--- On 2021-10-08 10:54, Bob Bridges wrote:
> The way I read in the long Polish article about the Logica hack, when I 
> researched it back in 2013, is that there was speculation about USS and about 
> an HTTP flaw, but the forensics folks in the end thought they probably got 
> hold of a password in the good old-fashioned way and went from there.  They 
> did indeed find and exploit USS configuration goofs.  And the HTTP flaw is 
> real...but Logica's post-hack report doesn't mention it; so they, at least, 
> didn't think it figured into the original break-in or in the culprits' 
> activities afterward.
>
> -Original Message-
> From: Charles Mills
> Sent: Thursday, October 7, 2021 18:49
>
> Assuming you don't count Logica. ("Oh, that wasn't a real mainframe 
> hack, they came in through USS.")
>
> -Original Message-
> From: Bill Johnson
> Sent: Thursday, October 7, 2021 3:21 PM
>
> You’d have to be a poorly run shop to permit any of those to occur. Maybe 
> that’s why mainframe hacks have actually never happened

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

Re: Mainframe ransomware solution

[Ed Jaffe]

On 10/8/2021 8:18 AM, David Spiegel wrote:
From what I recall, the bad guys had "READ" to the RACF Database. (It 
helps to have incompetent SecAdmin staff and auditors.)



These days, one would be beyond negligent to ignore the warnings issued 
by the RACF_SENSITIVE_RESOURCES health check. (Was that available in 2013?)


I assume all ESMs produce similar warnings:


|   RACF Dataset Report
|
| S Data Set Name   Vol    UACC Warn ID* User
| - --- --    
|   SYS2.RACF.DBPRIM    MVSSY2 None No   
|   SYS2.RACF.DBBACK    MVSSY1 None No   


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: Linkling an object from VSE to be used in z/OS

[Tony Thigpen]

A phase in z/VSE is the same as a phase in z/OS, But, the CSECT info is 
not as complete as in z/OS. While z/OS has the information for the 
original different CSECTs used to build the phase, z/VSE only saves the 
main CSECT identification information. Restated, all the subroutines 
that may have been hard-linked to the phase are in the phase, but there 
is not enough information to remove or replace one of the csects.


So, when you punch the phase from z/VSE, you will see only one CSECT for 
the total program.


In this discussion, the problem is that even if the COBOLII program was 
linked with LE 'parts' in z/VSE, those LE 'parts' may try to use z/VSE 
only pointers to branch into LE.


So, I don't think it's going to work.

Tony Thigpen

Seymour J Metz wrote on 10/8/21 10:12 AM:

What do you consider to be the MVS equivalent of a phase, and what utility are 
you using to convert a load module to an object module?

Certainly you can relink (rebind) and delete extraneous csects but that's 
somewhat of a manual process and still doesn't give you card images.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Thigpen [t...@vse2pdf.com]
Sent: Thursday, October 7, 2021 8:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Linkling an object from VSE to be used in z/OS

Don't expect it to work. When VSE punches a phase, the link deck created
includes any called modules without any way to get them out. This is in
contrast to z/OS which produces all the individual modules.

Tony Thigpen

Gadi Ben-Avi wrote on 10/7/21 3:22 AM:

Hi,
I was asked to attempt to link a object deck from VSE in z/OS.
The program is a COBOL2 program, but the source has been lost.

The first few lines of the object deck are:
W PHASE JKHIVX52,S+X'00'
W MODE AMODE(31),RMODE(ANY)
W.ESD  ..  ..JKHIVX52.§.©..÷0

After that there are many (A little over 12,000) lines that start with W.TXT
Next there are lines that start with W.RLD and a final like that starts with 
W.END.

The JCL I used was
//LKED EXEC  PGM=IEWL,
// PARM='LIST,XREF,NOLET,MAP',
// REGION=2M
//SYSLIN   DD DSN=N623.PMKA.KPMAT.JKHIVX52,DISP=SHR
//SYSLMOD  DD  DSNAME=V110GAD.LOAD(JKHIVX52),DISP=SHR
//SYSUT1   DD  UNIT=3390,SPACE=(CYL,(1,1))
//SYSPRINT DD  SYSOUT=*
//SYSINDD  *
 INCLUDE SYSLIN(JKHIVX52)
 NAME JKHIVX52(R)

I am doing something wrong?
Can this deck be linked into a usable z/OS load module?

Thanks

Gadi



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

[Bill Johnson]

Exactly right.


Sent from Yahoo Mail for iPhone


On Friday, October 8, 2021, 8:54 AM, Bob Bridges  wrote:

The way I read in the long Polish article about the Logica hack, when I 
researched it back in 2013, is that there was speculation about USS and about 
an HTTP flaw, but the forensics folks in the end thought they probably got hold 
of a password in the good old-fashioned way and went from there.  They did 
indeed find and exploit USS configuration goofs.  And the HTTP flaw is real 
(https://nvd.nist.gov/vuln/detail/CVE-2012-5955), but Logica's post-hack report 
doesn't mention it; so they, at least, didn't think it figured into the 
original break-in or in the culprits' activities afterward.

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

/* I've never hated a man enough to give him his diamonds back.  -Zsa-Zsa Gabor 
*/

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Thursday, October 7, 2021 18:49

Assuming you don't count Logica. ("Oh, that wasn't a real mainframe hack, they 
came in through USS.")

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Johnson
Sent: Thursday, October 7, 2021 3:21 PM

You’d have to be a poorly run shop to permit any of those to occur. Maybe 
that’s why mainframe hacks have actually never happened

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

[Bill Johnson]

Dude, you need to quit being a lemming afraid to challenge the know it alls. Oh 
wait.


Sent from Yahoo Mail for iPhone


On Friday, October 8, 2021, 8:34 AM, zMan  wrote:

And you were. In those exchanges, that makes one of you.

On Thu, Oct 7, 2021 at 9:00 PM Charles Mills  wrote:

> Sincere apologies. I was trying to be constructive.
>

Bill, you need to put the crack pipe down.

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

[David Spiegel]

Hi Bob,
From what I recall, the bad guys had "READ" to the RACF Database. (It 
helps to have incompetent SecAdmin staff and auditors.)
They downloaded it and then dictionary-attacked it easily, because there 
was no password limitation and there was no trivial-password-exclusion list.
Also, NVAS had no security. That is, once in, the hackers could logon to 
any 3270 application from the main panel.


Regards,
David

On 2021-10-08 10:54, Bob Bridges wrote:

The way I read in the long Polish article about the Logica hack, when I researched it back 
in 2013, is that there was speculation about USS and about an HTTP flaw, but the forensics 
folks in the end thought they probably got hold of a password in the good old-fashioned way 
and went from there.  They did indeed find and exploit USS configuration goofs.  And the 
HTTP flaw is real 
(https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnvd.nist.gov%2Fvuln%2Fdetail%2FCVE-2012-5955data=04%7C01%7C%7Ccd9662019d7c471e41b208d98a6b83b3%7C84df9e7fe9f640afb435%7C1%7C0%7C637693016700068298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=URXCTpLeeXlb7WraJx2DMcyoy1AfPLKyhn3Nc1jECxQ%3Dreserved=0),
 but Logica's post-hack report doesn't mention it; so they, at least, didn't think it 
figured into the original break-in or in the culprits' activities afterward.

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

/* I've never hated a man enough to give him his diamonds back.  -Zsa-Zsa Gabor 
*/

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Thursday, October 7, 2021 18:49

Assuming you don't count Logica. ("Oh, that wasn't a real mainframe hack, they came 
in through USS.")

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Johnson
Sent: Thursday, October 7, 2021 3:21 PM

You’d have to be a poorly run shop to permit any of those to occur. Maybe 
that’s why mainframe hacks have actually never happened

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

[Bob Bridges]

The way I read in the long Polish article about the Logica hack, when I 
researched it back in 2013, is that there was speculation about USS and about 
an HTTP flaw, but the forensics folks in the end thought they probably got hold 
of a password in the good old-fashioned way and went from there.  They did 
indeed find and exploit USS configuration goofs.  And the HTTP flaw is real 
(https://nvd.nist.gov/vuln/detail/CVE-2012-5955), but Logica's post-hack report 
doesn't mention it; so they, at least, didn't think it figured into the 
original break-in or in the culprits' activities afterward.

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

/* I've never hated a man enough to give him his diamonds back.  -Zsa-Zsa Gabor 
*/

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Thursday, October 7, 2021 18:49

Assuming you don't count Logica. ("Oh, that wasn't a real mainframe hack, they 
came in through USS.")

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Johnson
Sent: Thursday, October 7, 2021 3:21 PM

You’d have to be a poorly run shop to permit any of those to occur. Maybe 
that’s why mainframe hacks have actually never happened

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

Re: Linkling an object from VSE to be used in z/OS

[Seymour J Metz]

Phases in the CIL used to be non-relocatable, so adcons would certainly have 
been a problem in the old days. I don't know what the status is in z/VSE.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joe 
Monk [joemon...@gmail.com]
Sent: Friday, October 8, 2021 10:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Linkling an object from VSE to be used in z/OS

The real problem he's going to have is ACONs. Usually they are referenced
around a partition, no?

Joe

On Fri, Oct 8, 2021 at 9:13 AM Seymour J Metz  wrote:

> What do you consider to be the MVS equivalent of a phase, and what utility
> are you using to convert a load module to an object module?
>
> Certainly you can relink (rebind) and delete extraneous csects, but that's
> somewhat of a manual process and still doesn't give you card images.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Tony Thigpen [t...@vse2pdf.com]
> Sent: Thursday, October 7, 2021 8:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Linkling an object from VSE to be used in z/OS
>
> Don't expect it to work. When VSE punches a phase, the link deck created
> includes any called modules without any way to get them out. This is in
> contrast to z/OS which produces all the individual modules.
>
> Tony Thigpen
>
> Gadi Ben-Avi wrote on 10/7/21 3:22 AM:
> > Hi,
> > I was asked to attempt to link a object deck from VSE in z/OS.
> > The program is a COBOL2 program, but the source has been lost.
> >
> > The first few lines of the object deck are:
> > W PHASE JKHIVX52,S+X'00'
> > W MODE AMODE(31),RMODE(ANY)
> > W.ESD  ..  ..JKHIVX52.§.©..÷0
> >
> > After that there are many (A little over 12,000) lines that start with
> W.TXT
> > Next there are lines that start with W.RLD and a final like that starts
> with W.END.
> >
> > The JCL I used was
> > //LKED EXEC  PGM=IEWL,
> > // PARM='LIST,XREF,NOLET,MAP',
> > // REGION=2M
> > //SYSLIN   DD DSN=N623.PMKA.KPMAT.JKHIVX52,DISP=SHR
> > //SYSLMOD  DD  DSNAME=V110GAD.LOAD(JKHIVX52),DISP=SHR
> > //SYSUT1   DD  UNIT=3390,SPACE=(CYL,(1,1))
> > //SYSPRINT DD  SYSOUT=*
> > //SYSINDD  *
> > INCLUDE SYSLIN(JKHIVX52)
> > NAME JKHIVX52(R)
> >
> > I am doing something wrong?
> > Can this deck be linked into a usable z/OS load module?
> >
> > Thanks
> >
> > Gadi
> >
> >
> >
> > --
> > 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: Mainframe ransomware solution

[Seymour J Metz]

Still a mainframe, and the demonstration of MVS at SHARE was certainly MVS.

What was security like on TSS/360 and TSS/370?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Spiegel [dspiegel...@hotmail.com]
Sent: Friday, October 8, 2021 10:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe ransomware solution

Hi R'Shmuel; AMV"SH,
"... What about the Christmas Card Worm? ..."

That was AFAIK on a VM system, not, an MVS system.

Regards,
David

On 2021-10-08 10:35, Seymour J Metz wrote:
> Historically, there have been many poorly run shops. Prior to MVS, older 
> systems were wide open and even systems with storage protection were swiss 
> cheeses.
>
>   07F0
>   0A0C
>
> Didn't somebody delete an unsecured system data set during IBM's MVS 
> demonstration at SHARE? What about the Christmas Card Worm?
>
>
> --
> Shmuel (Seymour J.) Metz
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=04%7C01%7C%7Cb18204aadece408d669708d98a68dbc6%7C84df9e7fe9f640afb435%7C1%7C0%7C637693005274413450%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Uk8NcyJRnMxMoFv7faM3sA3HSM1HafQ6QJvHBBzpUiA%3Dreserved=0
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Bill Johnson [0047540adefe-dmarc-requ...@listserv.ua.edu]
> Sent: Thursday, October 7, 2021 6:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Mainframe ransomware solution
>
> You’d have to be a poorly run shop to permit any of those to occur. Maybe 
> that’s why mainframe hacks have actually never happened.Biden 
> successfully extracted 124,000 from Afghanistan in a few weeks. Amazing.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Thursday, October 7, 2021, 2:12 PM, Charles Mills  wrote:
>
> And assuming you never make a mistake. Never leave an APF data set 
> unprotected. Never give the wrong person console authority. Fully understand 
> APF on UNIX. Never have a Rexx PDS used by privileged users that is 
> modifiable by others. Have no magic SVCs. Have no flawed APF code, no APF 
> "tools" available inappropriately.
>
> Charles
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .

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

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

Re: Question on z/OS 2.5 and HFS file systems.

[Seymour J Metz]

It's trivial for mounted file systems. However, as others have noted, the real 
problem is testing migrated file systems.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Mark Jacobs [0224d287a4b1-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, October 6, 2021 11:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on z/OS 2.5 and HFS file systems.

Processing DCOLLECT data should be able to it.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://secure-web.cisco.com/1EEAPV04L1MtJ1qnxNnWW4CUFnjg2WQnSzLAMw46cl5YvU8Zd4FHEhwU7eXw_pPsrfa0fWtg-qEYwvd6ONBjhlczjfj4MV2Yp9TYyZvF1CC4CFmv9kfCpbt5n2RuD76bgRzZz6tGwbf1xbkCcvBcOyHRjLuTmXrdtXom2-jnziTHYGXjs2e7Nde-DxDpoQjfY198LcGdEnPvmR4DrNvaKBpetvkz-s3RQ6fLtkKauQox2zpgJV5KKTpcHuAGlrQwLlxYGoIveLjb1e2glbU8GHh-yXkGzCLU4Yi5VFMsEvUcMLj5-OX335V9hCDaTk8IsnxaOf0UOhM8ZkKFYOSHZQ1WSBCs3C-u3KK7o1yQ49jM7PnrSxQmkrHVquyozo3nSnh4Tu3zbwKnu-4B28H0mA4sj54T1QE8izKCOA4BW0WmULh3WKbxGqiQVRtSMbTnE/https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com

‐‐‐ Original Message ‐‐‐

On Wednesday, October 6th, 2021 at 11:40 AM, Ed Jaffe 
 wrote:

> On 10/6/2021 7:55 AM, James Crudele wrote:
>
> > There is a health check for it.
>
> I just looked at that. It only identifies MOUNTED HFS file systems.
>
> In our shop, we use AUTOMNT to mount user home directories on-demand as
>
> needed. I suspect that's a fairly common setup.
>
> So allow me to re-state my question: if an HFS is not mounted, how can a
>
> customer identify it? Something through ISMF?
>
> -
>
> Phoenix Software International
>
> Edward E. Jaffe
>
> 831 Parkview Drive North
>
> El Segundo, CA 90245
>
> https://secure-web.cisco.com/15FsA_vECfxYL_15WYQ62TCDpfj8VOjQZMqlwf9JgohF4cCwWdN1rUnMBU0jGCLGuqLoTn8801r5NPh0k0RTXgoHQqJxT1mcUUaU1QN4kpFmxO4K2ddjogBqfLlNANP7aa9W4b9wiypOgReuF94VrXuM5899ymbuCXRZY2EtYb7HYGTK3iPWOumSIsPl-LpUWTxyxgeg_oe_k6JiXV5FKOny-A-GpCw4EUr5H-QvOPRT6I-XHBW4DwZ4mqbXCMhgAqlBg2zc96946h4Akguh3aLMYyHacq8OqlZum51uya7h7p0giBu7CwxLEC4OJAaFT3mmUv_TDsYZH7E-r7n7mPXy5Z5sWgdZZHHunDf2a7ErjzXyk4wcq78OLBBRPC_RxJcPpo_6v4BhgM1mOGojM4M2jM-jaq2u3CfPPOBmSvjw9vS0p8bfkUHDnZwO_WOFH/https%3A%2F%2Fwww.phoenixsoftware.com%2F
>
>
> ---
>
> This e-mail message, including any attachments, appended messages and the
>
> information contained therein, is for the sole use of the intended
>
> recipient(s). If you are not an intended recipient or have otherwise
>
> received this email message in error, any use, dissemination, distribution,
>
> review, storage or copying of this e-mail message and the information
>
> contained therein is strictly prohibited. If you are not an intended
>
> recipient, please contact the sender by reply e-mail and destroy all copies
>
> of this email message and do not otherwise utilize or retain this email
>
> message or any or all of the information contained therein. Although this
>
> email message and any attachments or appended messages are believed to be
>
> free of any virus or other defect that might affect any computer system into
>
> which it is received and opened, it is the responsibility of the recipient
>
> to ensure that it is virus free and no responsibility is accepted by the
>
> sender for any loss or damage arising in any way from its opening or use.
>
> -
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to 

Re: Mainframe ransomware solution

[David Spiegel]

Hi R'Shmuel; AMV"SH,
"... What about the Christmas Card Worm? ..."

That was AFAIK on a VM system, not, an MVS system.

Regards,
David

On 2021-10-08 10:35, Seymour J Metz wrote:

Historically, there have been many poorly run shops. Prior to MVS, older 
systems were wide open and even systems with storage protection were swiss 
cheeses.

  07F0
  0A0C

Didn't somebody delete an unsecured system data set during IBM's MVS 
demonstration at SHARE? What about the Christmas Card Worm?


--
Shmuel (Seymour J.) Metz
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=04%7C01%7C%7Cb18204aadece408d669708d98a68dbc6%7C84df9e7fe9f640afb435%7C1%7C0%7C637693005274413450%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Uk8NcyJRnMxMoFv7faM3sA3HSM1HafQ6QJvHBBzpUiA%3Dreserved=0


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Bill Johnson [0047540adefe-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, October 7, 2021 6:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe ransomware solution

You’d have to be a poorly run shop to permit any of those to occur. Maybe 
that’s why mainframe hacks have actually never happened.Biden successfully 
extracted 124,000 from Afghanistan in a few weeks. Amazing.


Sent from Yahoo Mail for iPhone


On Thursday, October 7, 2021, 2:12 PM, Charles Mills  wrote:

And assuming you never make a mistake. Never leave an APF data set unprotected. Never 
give the wrong person console authority. Fully understand APF on UNIX. Never have a Rexx 
PDS used by privileged users that is modifiable by others. Have no magic SVCs. Have no 
flawed APF code, no APF "tools" available inappropriately.

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


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

Re: IBM JCL Expert preview in today's announcement letter

[Seymour J Metz]

DCB=(LRECL=256,BLKSIZE=256) works well. I've' also used KEYLEN=8, However, is 
there any reason not to use DESERV for new code?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Rupert Reynolds [rreyno...@cix.co.uk]
Sent: Wednesday, October 6, 2021 11:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM JCL Expert preview in today's announcement letter

>From memory, I'm pretty sure I've done the same thing (LRECL and BKSIZE
256) in compiled code, allocated both via JCL and via SVC 99.

Out of date, I'm guessing there are handy routines to read PDS directories
for us these days, and PDSE too? (Newer than ISPF LM*, I mean).

Roops

On Wed., Oct. 6, 2021, 16:19 Paul Gilmartin, <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 6 Oct 2021 10:33:14 -0400, David Spiegel wrote:
> >...
> >Besides not needing DCB, DSORG is usually useless as well.
> >
> Perhaps useless in JCL.  In Rexx I've needed to code DSORG(PS) to read a
> PDS directory.
>
> -- 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: Linkling an object from VSE to be used in z/OS

[Joe Monk]

The real problem he's going to have is ACONs. Usually they are referenced
around a partition, no?

Joe

On Fri, Oct 8, 2021 at 9:13 AM Seymour J Metz  wrote:

> What do you consider to be the MVS equivalent of a phase, and what utility
> are you using to convert a load module to an object module?
>
> Certainly you can relink (rebind) and delete extraneous csects, but that's
> somewhat of a manual process and still doesn't give you card images.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Tony Thigpen [t...@vse2pdf.com]
> Sent: Thursday, October 7, 2021 8:39 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Linkling an object from VSE to be used in z/OS
>
> Don't expect it to work. When VSE punches a phase, the link deck created
> includes any called modules without any way to get them out. This is in
> contrast to z/OS which produces all the individual modules.
>
> Tony Thigpen
>
> Gadi Ben-Avi wrote on 10/7/21 3:22 AM:
> > Hi,
> > I was asked to attempt to link a object deck from VSE in z/OS.
> > The program is a COBOL2 program, but the source has been lost.
> >
> > The first few lines of the object deck are:
> > W PHASE JKHIVX52,S+X'00'
> > W MODE AMODE(31),RMODE(ANY)
> > W.ESD  ..  ..JKHIVX52.§.©..÷0
> >
> > After that there are many (A little over 12,000) lines that start with
> W.TXT
> > Next there are lines that start with W.RLD and a final like that starts
> with W.END.
> >
> > The JCL I used was
> > //LKED EXEC  PGM=IEWL,
> > // PARM='LIST,XREF,NOLET,MAP',
> > // REGION=2M
> > //SYSLIN   DD DSN=N623.PMKA.KPMAT.JKHIVX52,DISP=SHR
> > //SYSLMOD  DD  DSNAME=V110GAD.LOAD(JKHIVX52),DISP=SHR
> > //SYSUT1   DD  UNIT=3390,SPACE=(CYL,(1,1))
> > //SYSPRINT DD  SYSOUT=*
> > //SYSINDD  *
> > INCLUDE SYSLIN(JKHIVX52)
> > NAME JKHIVX52(R)
> >
> > I am doing something wrong?
> > Can this deck be linked into a usable z/OS load module?
> >
> > Thanks
> >
> > Gadi
> >
> >
> >
> > --
> > 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 ransomware solution

[Bob Bridges]

IMO you were doing fine, Mr Mills.  The only thing I might suggest is that you 
let unearned obstreporosity drop off into the void unnoticed.  In addition to 
being more fun for lurkers who don't care to read such exchanges, surely that'd 
be more frustrating to anyone hoping for a quarrel (whoever that might be).

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

/* I'd still be slaving away at a desk for another 25 years if people backed up 
[their computer data] and kept a cool head.  -Ross Greenberg, a pioneer in IBM 
PC antivirus software who went into semi-retirement in his mid-30s */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Thursday, October 7, 2021 21:00

Sincere apologies. I was trying to be constructive.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Thursday, October 7, 2021 5:34 PM

I don't know about the others on the list, but I am a tad tired of this and 
other rounds of sniping between Mr. Johnson and Mr. Mills.

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

Re: Mainframe ransomware solution

[Seymour J Metz]

Historically, there have been many poorly run shops. Prior to MVS, older 
systems were wide open and even systems with storage protection were swiss 
cheeses.

 07F0
 0A0C

Didn't somebody delete an unsecured system data set during IBM's MVS 
demonstration at SHARE? What about the Christmas Card Worm?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Bill Johnson [0047540adefe-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, October 7, 2021 6:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe ransomware solution

You’d have to be a poorly run shop to permit any of those to occur. Maybe 
that’s why mainframe hacks have actually never happened.Biden successfully 
extracted 124,000 from Afghanistan in a few weeks. Amazing.


Sent from Yahoo Mail for iPhone


On Thursday, October 7, 2021, 2:12 PM, Charles Mills  wrote:

And assuming you never make a mistake. Never leave an APF data set unprotected. 
Never give the wrong person console authority. Fully understand APF on UNIX. 
Never have a Rexx PDS used by privileged users that is modifiable by others. 
Have no magic SVCs. Have no flawed APF code, no APF "tools" available 
inappropriately.

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

Re: Mainframe ransomware solution

[zMan]

And you were. In those exchanges, that makes one of you.

On Thu, Oct 7, 2021 at 9:00 PM Charles Mills  wrote:

> Sincere apologies. I was trying to be constructive.
>

Bill, you need to put the crack pipe down.

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

Re: Mainframe ransomware solution

[Seymour J Metz]

My understanding is that most security breaches are either inside jobs or 
involve social engineering. Procedural and technological measures are 
absolutely necessary, but they are not enough.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom 
Brennan [t...@tombrennansoftware.com]
Sent: Thursday, October 7, 2021 7:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe ransomware solution

I'll repeat what I always say about this.  If I was hacking a mainframe
I wouldn't start with the mainframe, I'd start with the sysprog or
security admin's PC or Mac or email or phone or whatever.  In that case
it doesn't matter one bit how well the mainframe is protected internally.

And please stop with the political remarks.  This seems to be the one
place on earth I can go without reading about politics.  A place where I
can enjoy a 50+ post back-and-forth between Seymour and Gil, for
example, without hearing one word about US politics.

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

Re: Linkling an object from VSE to be used in z/OS

[Seymour J Metz]

What do you consider to be the MVS equivalent of a phase, and what utility are 
you using to convert a load module to an object module?

Certainly you can relink (rebind) and delete extraneous csects, but that's 
somewhat of a manual process and still doesn't give you card images.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Thigpen [t...@vse2pdf.com]
Sent: Thursday, October 7, 2021 8:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Linkling an object from VSE to be used in z/OS

Don't expect it to work. When VSE punches a phase, the link deck created
includes any called modules without any way to get them out. This is in
contrast to z/OS which produces all the individual modules.

Tony Thigpen

Gadi Ben-Avi wrote on 10/7/21 3:22 AM:
> Hi,
> I was asked to attempt to link a object deck from VSE in z/OS.
> The program is a COBOL2 program, but the source has been lost.
>
> The first few lines of the object deck are:
> W PHASE JKHIVX52,S+X'00'
> W MODE AMODE(31),RMODE(ANY)
> W.ESD  ..  ..JKHIVX52.§.©..÷0
>
> After that there are many (A little over 12,000) lines that start with W.TXT
> Next there are lines that start with W.RLD and a final like that starts with 
> W.END.
>
> The JCL I used was
> //LKED EXEC  PGM=IEWL,
> // PARM='LIST,XREF,NOLET,MAP',
> // REGION=2M
> //SYSLIN   DD DSN=N623.PMKA.KPMAT.JKHIVX52,DISP=SHR
> //SYSLMOD  DD  DSNAME=V110GAD.LOAD(JKHIVX52),DISP=SHR
> //SYSUT1   DD  UNIT=3390,SPACE=(CYL,(1,1))
> //SYSPRINT DD  SYSOUT=*
> //SYSINDD  *
> INCLUDE SYSLIN(JKHIVX52)
> NAME JKHIVX52(R)
>
> I am doing something wrong?
> Can this deck be linked into a usable z/OS load module?
>
> Thanks
>
> Gadi
>
>
>
> --
> 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: VSAM RLS False Contention

[allan winston]

While I never worked with RLS, I found this issue to be an interesting one
to research since I performed
quite a bit of CICS LSR tuning 20 years ago.

>From what I have found in the main z/OS manuals and Redbooks, the lock
structure needs to be enlarged.

Additionally, if the MAXSYSTEM parameter was set higher than it needed to
be, that can cause unnecessary doubling
of the size of the cache entries.  The doubling occurs when you exceed 7
and then when you exceed 23.

Since the lock table is used by all clusters participating in RLS, I would
not expect any SMF record to be attributing the false
contention to a specific cluster - it is just an expected side-effect of
hashing.

Conceivably, if there are bottlenecks in the CICS transactions such that
the locks are being held longer than in the past,
that could be contributing to the false contentions, as the hash table
entry is being released more slowly.

In the rare event that there are any VSAM clusters defined to RLS that are
not ever shared, you could consider changing
those clusters back to LSR and perform manual tuning of their pools,
thereby reducing the stress on the lock table.
However, there are application subtleties in doing so - record-level
locking in the RLS case versus control-interval locking in the LSR case.

Allan


On Tue, Oct 5, 2021 at 5:17 PM Crawford, Robert C. <
01feadb2c2d2-dmarc-requ...@listserv.ua.edu> wrote:

> Off and on we VSAM RLS false contention plateaus going over IBM's
> recommended .5% rate.  We don't see any kind of triggering behavior in CICS
> or the CICS application.
>
> I would like to at least see the datasets causing the false contention but
> all the false contention buckets in the RMF type 42 subtype 16 records are
> zero.  The true contention buckets have values.
>
> It's my understanding the subtype 16 are supposed to have dataset level
> information.  I specified several dataset name levels in RMF VSAMRLS
> options.  I also see the same dataset levels in SMS display MONDS commands.
>
> Is it possible I'm missing something that causes DFSSMS to write dataset
> level false contention data?  Am I looking in the wrong place?
>
> Thanks.
>
> Robert Crawford
> Mainframe Management
> United Services Automobile Association
> (210) 913-3822
>
> "Moy glaz! YA ne dolzhen dobavlyat' v nego puding!"
> - Tolstoy
> Please send requests to mainframe management through our front door at
> go/mfmfrontdoor
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Seymour J Metz
> Sent: Tuesday, October 5, 2021 3:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: EXTERNAL: Re: PL/I vs. JCL
>
> And before that MVS-OE., with MVS before Open.
>
>
> --
> Shmuel (Seymour J.) Metz
>
> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!GryZGb6B1VCs0SfC!TBwvJ8AO8e9VuDJE7lIsISBnAl6KAhctOQOxm3s7DJUmS0PMKUDPz75eQK5LMQqR2TA$
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of David Spiegel 
> Sent: Tuesday, October 5, 2021 1:37 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I vs. JCL
>
> Maybe they should've left it as "Open MVS"? (OS/390)
>
> On 2021-10-05 13:08, Tom Brennan wrote:
> > I always thought IBM's position on that was pretty silly.  If you make
> > up a new three word name, expect it to quickly be turned into an
> > acronym.  If they didn't want us to reuse an existing little-known
> > acronym they should have named it something else.
> >
> > On 10/5/2021 9:56 AM, Seymour J Metz wrote:
> >>>   USS has always meant Unix System Services.
> >>
> >>
> >> Not unless you have a time machine; Unformatted System Services dates
> >> to the 1970s. Further, the last post here from IBM on the issue said
> >> that USS was not an approved abbreviation for Unix System Services.
> >>
> >> --
> >> Shmuel (Seymour J.) Metz
> >> https://urldefense.com/v3/__https://na01.safelinks.protection.outlook
> >> .com/?url=http*3A*2F*2Fmason.gmu.edu*2F*smetz3data=04*7C01*7C*7C
> >> 66d0453903554718720608d98822bd8d*7C84df9e7fe9f640afb435*7
> >> C1*7C0*7C637690505140660718*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> >> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000sdata=Lx
> >> w1EM03nZsemipAC1ktZCbgKrL*2BedD7*2BDDlG*2Fiwn*2B8*3Dreserved=0__
> >> ;JSUlJX4lJSUlJSUlJSUlJSUlJSUl!!GryZGb6B1VCs0SfC!TBwvJ8AO8e9VuDJE7lIsI
> >> SBnAl6KAhctOQOxm3s7DJUmS0PMKUDPz75eQK5LiSU-R24$
> >>
> >>
> >>
> >> 
> >> From: IBM Mainframe Discussion List  on
> >> behalf of Joe Monk 
> >> Sent: Monday, October 4, 2021 9:11 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: PL/I vs. JCL
> >>
> >> USS is a VTAM term for Unformatted System Services.
> >>
> >> USS has always meant Unix System Services.
> >>
> >> Joe
> >>
> >> On Mon, Oct 4, 2021 at 7:30 PM Mike Schwab 
> >> wrote:
> >>
> >>> U.S.S.  Unformated System Services, until Unix System Services tried
> >>> to take it over.
> >>>
> >>> On Tue, Oct 5, 2021 at 1:24 AM Paul 

Re: Mainframe ransomware solution

[Seymour J Metz]

PPTT, unless you consider training to be part of process. Training should 
include periodic training on changes.

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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Filip Palian [s3...@pjwstk.edu.pl]
Sent: Friday, October 8, 2021 12:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe ransomware solution

>From the information security perspective there's a well-known
confidentiality, integrity and availability (CIA) triad.
However, the overall security posture of an organisation is dependent on
the following three key areas: people, process, technology (PPT).

Majority of breaches/risks can be prevented/mitigated by addressing
essentials (e.g. capable staff, awareness trainings, well documented and
communicated processes, technology/security controls etc.).
As always, a multifaceted approach is required to address security
holistically. Relaying solely on technology/products is simply a no go/not
enough.



pt., 8 paź 2021 o 11:59 Charles Mills  napisał(a):

> Sincere apologies. I was trying to be constructive.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Farley, Peter x23353
> Sent: Thursday, October 7, 2021 5:34 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Mainframe ransomware solution
>
> I don't know about the others on the list, but I am a tad tired of this
> and other rounds of sniping between Mr. Johnson and Mr. Mills.
>
> --
> 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: Customized Offering Driver

[Rich Smrcina]

Thank you, Marna. I’ll sent it now.

Rich Smrcina


> On Oct 8, 2021, at 8:54 AM, Marna WALLE  wrote:
> 
> Hi Rich,
> Please open a Case so we can see what is going on.  If you like, please email 
> me the Case number so I can see what it is.  
> 
> This is the statement that we had in the Announcement, which indicates that 
> z/OSMF - at z/OS V2.5 GA on Sept 30, 2021 - should have z/OSMF starting on 
> it.  "With the availability of z/OS V2.5, the Customized Offerings Driver has 
> z/OSMF enabled so it can be used to install a z/OS ServerPac portable 
> software instance."
> 
> If you ordered your COD before Sept 30, 2021 it might be at a level which did 
> not automatically start z/OSMF.  If you ordered it after, z/OSMF should start 
> without the problems you are seeing.  
> 
> -Marna WALLE
> z/OS Installation and Upgrade
> IBM Poughkeepsie
> 
> --
> 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: Customized Offering Driver

[Marna WALLE]

Hi Rich,
Please open a Case so we can see what is going on.  If you like, please email 
me the Case number so I can see what it is.  

This is the statement that we had in the Announcement, which indicates that 
z/OSMF - at z/OS V2.5 GA on Sept 30, 2021 - should have z/OSMF starting on it.  
"With the availability of z/OS V2.5, the Customized Offerings Driver has z/OSMF 
enabled so it can be used to install a z/OS ServerPac portable software 
instance."

If you ordered your COD before Sept 30, 2021 it might be at a level which did 
not automatically start z/OSMF.  If you ordered it after, z/OSMF should start 
without the problems you are seeing.  

-Marna WALLE
z/OS Installation and Upgrade
IBM Poughkeepsie

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

Re: Mainframe ransomware solution

[Seymour J Metz]

I've been at multiple shops that had magic SVCs. At one shop that had two, I 
was allowed to remove one but not another. In one shop where I discovered an 
error in the authentication code, I was ordered to not mention it to the 
auditors. I naively expect such to die with the advent of APF, but they're 
still out the, due to decades of inertia.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Radoslaw Skorupka [r.skoru...@hotmail.com]
Sent: Friday, October 8, 2021 7:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe ransomware solution

First part of my answer was kind of joke. Wasn't it clear?
Second part provided some means, products and opinions.

Regarding magic SVCs - I have *never* found any. Yes, I met and fixed
some other mistakes you mentioned.
And yes, such point should be on auditor checklist.
And yes, people tend to make mistakes. That's why I mentioned audit as
important part of the picture.
And it is good idea to have redundant protections whenever possible.
That's why we have encrypted datasets. Not because RACF sucks.
And at the end we may have Safeguarded Copy or Dell/EMC solution.

--
Radoslaw Skorupka
Lodz, Poland



W dniu 08.10.2021 o 00:47, Charles Mills pisze:
> I don't know, but what the professional Pen Testers tell me is that they 
> never fail to find things like that.
>
> I've never met any group that never made a mistake, never had an "oops," 
> never "missed something."
>
> Magic SVCs were widespread until recently. Has every single one vanished?
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Bill Johnson
> Sent: Thursday, October 7, 2021 3:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Mainframe ransomware solution
>
> You’d have to be a poorly run shop to permit any of those to occur. Maybe 
> that’s why mainframe hacks have actually never happened.Biden 
> successfully extracted 124,000 from Afghanistan in a few weeks. Amazing.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Thursday, October 7, 2021, 2:12 PM, Charles Mills  wrote:
>
> And assuming you never make a mistake. Never leave an APF data set 
> unprotected. Never give the wrong person console authority. Fully understand 
> APF on UNIX. Never have a Rexx PDS used by privileged users that is 
> modifiable by others. Have no magic SVCs. Have no flawed APF code, no APF 
> "tools" available inappropriately.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Radoslaw Skorupka
> Sent: Wednesday, October 6, 2021 2:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Mainframe ransomware solution
>
> W dniu 05.10.2021 o 15:24, Tommy Tsui pisze:
>>> Hi
>>   Any shop implement mainframe ransomware solution can share? IBM seems has
>> cyber vault to handle this. Is there any other solution available ?
>> Thanks for sharing
> 
> Yes, we have such solution.
> This is combination of the following products:
> 1. z/OS
> 2. RACF
> 3. Professional staff
> 
>
> Other means:
> RACF
> backup
> Safeguarded copy and other vendors' solutions
> audit
> procedures
>
> Note: all of the "solutions" marketed nowadays give you some cure *after
> breach happened*. However that means some problems. It is unlikely to
> restore with RPO=0. If you want RPO=0 then you should pay much more
> attention at prevention, which means ...no, NOT ANOTHER PRODUCT.
> Definitely first: professional staff, procedures, audit. And then maybe
> some tools.
> IBM Cyber Resiliency tools: Guardium, zSecure Suite, QRadar SIEM,
> Safeguarded Copy...

--
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: IBM JCL Expert preview in today's announcement letter

[Carmen Vitullo]

I would be interested in participating in a conf call or a private call 
with developers


thank you

Carmen

On 10/8/2021 7:55 AM, Domenico D'Alterio wrote:

Hello List,
I see that the IBM announcement 
https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/3/649/ENUSA21-0533/index.html=en_locale=en
 triggered a lot of questions.
I am the Senior Product Manager in IBM working on this new project, so it will 
be a completely new offering from IBM for a JCL Checker tool.
If you are interested in talking with development during the development phase, 
reach-out me. It would not be a sales call, just an early exposure of what we 
plan to deliver with the possibility to influence the roadmap.

Thank you,
Domenico D'Alterio

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


--
/I am not bound to win, but I am bound to be true. I am not bound to 
succeed, but I am bound to live by the light that I have. I must stand 
with anybody that stands right, and stand with him while he is right, 
and part with him when he goes wrong. *Abraham Lincoln*/


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

Re: IBM JCL Expert preview in today's announcement letter

[Mitch Mccluhan]

Domenic,
Tell me more, please.
Mitch


Sent from the all new AOL app for iOS


On Friday, October 8, 2021, 8:05 AM, Domenico D'Alterio 
 wrote:

Hello List,
I see that the IBM announcement 
https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/3/649/ENUSA21-0533/index.html=en_locale=en
 triggered a lot of questions.
I am the Senior Product Manager in IBM working on this new project, so it will 
be a completely new offering from IBM for a JCL Checker tool.
If you are interested in talking with development during the development phase, 
reach-out me. It would not be a sales call, just an early exposure of what we 
plan to deliver with the possibility to influence the roadmap.

Thank you,
Domenico D'Alterio

--
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: IBM JCL Expert preview in today's announcement letter

[Domenico D'Alterio]

Hello List,
I see that the IBM announcement 
https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/3/649/ENUSA21-0533/index.html=en_locale=en
 triggered a lot of questions.
I am the Senior Product Manager in IBM working on this new project, so it will 
be a completely new offering from IBM for a JCL Checker tool.
If you are interested in talking with development during the development phase, 
reach-out me. It would not be a sales call, just an early exposure of what we 
plan to deliver with the possibility to influence the roadmap.

Thank you,
Domenico D'Alterio

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

Re: Mainframe ransomware solution

[Radoslaw Skorupka]

I'm not IBM expert, but...
1. This is bad or not followed procedure. BTW: I made it impossible in 
my shop, since day 0. It was never ever possible to get new password on 
production without procedure. The procedure was inconvenient, more time 
consuming compared to call, but it wasn't bypassed. And yes, password 
resets were thoroughly audited since day 1. And all shouting managers 
were answered that we will react as quickly as possible, but still 
according to the procedure.


2. MFA would make it impossible. MFA is additional cost, it is 
inconvenient, but it works.


3. There is still possibility to kidnap one's child and force him to do 
bad things. ...but this is not end of story. Separation of duties should 
help here a little. For example sysprog or RACF admin can do anything 
with the z/OS, but usually such person cannot reconfigure corporate 
firewall or allow strangers to enter the data center.



--
Radoslaw Skorupka
Lodz, Poland



W dniu 08.10.2021 o 02:44, Tom Brennan pisze:
(Sorry, another repeat here) I once test-called the company Help Desk 
and with no other information but the fact that I called from a 
sysprog's desk phone (my own), they gave me not only a password reset, 
but also told me my TSO userid because I had "forgotten" it, and then 
helped me log on.  Sure, a hacker would have to be at my desk, but 
that could be accomplished.


IBM Experts: I'm ready for your correction.

On 10/7/2021 5:06 PM, Bill Johnson wrote:
The thing about you list dominators, is you think you know it all and 
should never be challenged. I love when the IBM experts corrects one 
of you.



Sent from Yahoo Mail for iPhone


On Thursday, October 7, 2021, 6:01 PM, Charles Mills 
 wrote:


Exactly, and "that was not a real hack" would not get your data back.

Charles



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

Re: Mainframe ransomware solution

[Radoslaw Skorupka]

W dniu 08.10.2021 o 01:26, Charles Mills pisze:
[...]

It is not an anti-mainframe position to advocate for mainframe security. "Oh, we 
have nothing to worry about" is surely the enemy of security.

Charles

Amen to that!



--
Radoslaw Skorupka
Lodz, Poland

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

Re: Mainframe ransomware solution

[Radoslaw Skorupka]

There is big difference between stolen money from tent on the camping 
and stolen money from bank safe, which was not closed because someone 
did not do his duty.

The safe can be locked, but the tent cannot be effectively secured.

--
Radoslaw Skorupka
Lodz, Poland




W dniu 08.10.2021 o 01:18, Charles Mills pisze:

The one I am privately aware of I did not work on and is four years (?) in the 
past. It was a US government system.

There are varying versions of the Logica story. The one I read in the police 
report and accept as factual involved the exploitation of a flaw in a Web 
browser running on z/OS UNIX. They used that to utterly take over the machine, 
issuing multiple userids and making them SPECIAL and so forth. They installed 
their own login server to make things easier for themselves. I would call that 
a mainframe breach.

I think a focus on "was it a real hack" is a mistake. If your senior systems programmer writes his 
password on the back of his business card and accidentally leaves it in a bar, that is not a "real 
hack" but your data is just as much at risk as if it were. The focus should be on vulnerabilities (in 
that case, lack of MFA and lack of user education) not "was it a real hack?"

If your teenaged son dropped his housekey in your driveway and someone used it to come in 
and steal your TV, would you say "that was not a real burglary"?

At best you can't say mainframe hacks have never happened, you can only say you 
don't know of any. There is a well-known tendency for shops not to discuss. 
(Nor for that matter can one assert unequivocally that they have; only that 
there are none that are well-documented.)

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Johnson
Sent: Thursday, October 7, 2021 3:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe ransomware solution

Logica isn’t actually a hack. And of course the phantom one you’re working on.

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

[Radoslaw Skorupka]

First part of my answer was kind of joke. Wasn't it clear?
Second part provided some means, products and opinions.

Regarding magic SVCs - I have *never* found any. Yes, I met and fixed 
some other mistakes you mentioned.

And yes, such point should be on auditor checklist.
And yes, people tend to make mistakes. That's why I mentioned audit as 
important part of the picture.
And it is good idea to have redundant protections whenever possible. 
That's why we have encrypted datasets. Not because RACF sucks.

And at the end we may have Safeguarded Copy or Dell/EMC solution.

--
Radoslaw Skorupka
Lodz, Poland



W dniu 08.10.2021 o 00:47, Charles Mills pisze:

I don't know, but what the professional Pen Testers tell me is that they never 
fail to find things like that.

I've never met any group that never made a mistake, never had an "oops," never 
"missed something."

Magic SVCs were widespread until recently. Has every single one vanished?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Johnson
Sent: Thursday, October 7, 2021 3:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe ransomware solution

You’d have to be a poorly run shop to permit any of those to occur. Maybe 
that’s why mainframe hacks have actually never happened.Biden successfully 
extracted 124,000 from Afghanistan in a few weeks. Amazing.


Sent from Yahoo Mail for iPhone


On Thursday, October 7, 2021, 2:12 PM, Charles Mills  wrote:

And assuming you never make a mistake. Never leave an APF data set unprotected. Never 
give the wrong person console authority. Fully understand APF on UNIX. Never have a Rexx 
PDS used by privileged users that is modifiable by others. Have no magic SVCs. Have no 
flawed APF code, no APF "tools" available inappropriately.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Radoslaw Skorupka
Sent: Wednesday, October 6, 2021 2:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe ransomware solution

W dniu 05.10.2021 o 15:24, Tommy Tsui pisze:

Hi

  Any shop implement mainframe ransomware solution can share? IBM seems has
cyber vault to handle this. Is there any other solution available ?
Thanks for sharing


Yes, we have such solution.
This is combination of the following products:
1. z/OS
2. RACF
3. Professional staff


Other means:
RACF
backup
Safeguarded copy and other vendors' solutions
audit
procedures

Note: all of the "solutions" marketed nowadays give you some cure *after
breach happened*. However that means some problems. It is unlikely to
restore with RPO=0. If you want RPO=0 then you should pay much more
attention at prevention, which means ...no, NOT ANOTHER PRODUCT.
Definitely first: professional staff, procedures, audit. And then maybe
some tools.
IBM Cyber Resiliency tools: Guardium, zSecure Suite, QRadar SIEM,
Safeguarded Copy...


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

Re: Mainframe ransomware solution

[ITschak Mugzach]

I’ve not seen the first one, but the second one is a joke.

ITschak

בתאריך יום ו׳, 8 באוק׳ 2021 ב-5:17 מאת Nash, Jonathan S. <
01abdcef2f3c-dmarc-requ...@listserv.ua.edu>:

>
> Philip Young
> “Soldier of Fortran”
> Mainframe hacker videos from 6 years ago :-(
>
> https://youtu.be/Xfl4spvM5DI
>
> https://youtu.be/vyHAqxCkf-k
>
> There are other Def con etc mainframe hacker
> videos out there ...
>
> Kinda makes me nervous...
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon  *

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