Re: What not to do on a z/OS system...

[Ed Jaffe]

On 1/18/2022 4:41 PM, Robert Prins wrote:

OK, it's not the silly season, but have you ever used your employers
equipment to do something silly? And are not afraid to admit it?


I caught one of our developers developing software for another company 
using our equipment.


I asked him how many compiles he had run today for this 100% 
unauthorized "side work" and he responded, "Maybe a dozen or so?"


He seemed genuinely surprised to learn he had run 112 such compiles that 
day alone. His response to that was, "Well, that does seem a bit excessive."


Not only were his extracurricular activities a clear violation of 
company policy, his assigned work project was weeks late and full of 
bugs. He had no time to waste.


Needless to say, this individual no longer works for PSI...


--
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: More of LOG4J

[David Crayford]

On 19/1/22 12:41 am, Kirk Wolf wrote:

Since I would guess that a majority of ibm-mainers would agree that open source 
is confusing and dangerous, here's a question:

Let's say that an organization wanted to prohibit open source.  How would you 
go about it?


Good question. First off, you won't be able to run Java. The OpenJ9 JVM 
and OMR JIT projects are open source and hosted on Github. Then you 
would have to get rid of WebSphere which is built using open source 
libraries.

I could go on and on and on.




Kirk Wolf
Dovetailed Technologies
http://dovetail.com

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


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

Re: What not to do on a z/OS system...

[David Purdy]

In the mid-70's, two programmers discovered TSO SEND, and they were madly 
exchanging explicit love notes.  Neither the operators or sysprogs let them 
know the notes were showing up on the console.
Must have worked - they eventually happily married...


-Original Message-
From: Bob Bridges 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tue, Jan 18, 2022 8:31 pm
Subject: Re: What not to do on a z/OS system...

Not the same thing, but it reminds me that I once caused a panic inadvertently 
in my office.  Users would occasionally ask the owner of a process or dataset 
for permission to access it, get the ok from the owner, and forward it to me 
saying "please set this up; as you see, he said it was ok".  I, naturally, 
would insist that the owner email me directly.  (In case it isn't obvious why, 
it's easy to construct an email in which "he" says it's ok; but if it comes 
directly from the owner, I can trust it.  Not that I think anyone's lying, but 
someday it'll happen and I want to get all my customers used to doing it right.

My boss didn't thoroughly understand my objection to accepting second-hand 
permissions.  So one night it occurred to me that a demonstration might be 
educational.  Before I went home I sent him an email bringing up the subject 
again, explained my position, and said "...as you can see by the below email".  
Below I fadged up an email ostensibly from my boss to HIS boss, saying 
something uncomplimentary.

When I got in the next morning, the department was in an uproar.  Apparently my 
boss had completely missed the point of my email; all he could see was that 
someone had hacked his account, and he was on the verge of going to his boss to 
deny that he'd sent any such email.  I talked him down and explained again what 
I'd done.  But I don't think I'll try any such realistic demonstration again in 
future, not at least without more emphatic disclaimers surrounding it.

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

/* Being famous has its benefits, but fame isn't one of them.  -Larry Wall */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Roger Bolan
Sent: Tuesday, January 18, 2022 19:43

Well, mine was just silly and did not involve games or using unauthorized CPU 
time.
I was just doing my normal code development job and running PL/I compiles, 
links, and tests.
The systems I normally used restricted the jobnames to userid + a character.  
Then one of the systems I was working on allowed the jobname to
be whatever I wanted.  So I took one of my ordinary jobs that didn't use
any more time or resources than normal, and "just for fun" I gave it a jobname 
of "COREHOGG".

OMG!!  When I submitted that my phone immediately blew up with people
yelling at me about what did I think I was doing?  Not the operators.
They could see what it was.  But other users who just reacted to the name 
COREHOGG without knowing anything else about the job.

So I learned not to give jobnames "just for fun". :)

--- On Tue, Jan 18, 2022 at 3:41 PM Robert Prins  
wrote:
> OK, it's not the silly season, but have you ever used your employers 
> equipment to do something silly? And are not afraid to admit it?
>
> Well, I have in the early 1990'ies, and I actually got away with it, 
> without losing my job.
>
> And talking about jobs, if anyone of you know of any companies looking 
> for someone with 36+ years of PL/I, and a bit less Db2 and CICS, feel 
> free to drop me a line.
>
> So what did I do? Let's go back a few years…
> https://prino.neocities.org/blog/2022-01-19-setting-the-record-straight.html

--
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: What not to do on a z/OS system...

[Bob Bridges]

Not the same thing, but it reminds me that I once caused a panic inadvertently 
in my office.  Users would occasionally ask the owner of a process or dataset 
for permission to access it, get the ok from the owner, and forward it to me 
saying "please set this up; as you see, he said it was ok".  I, naturally, 
would insist that the owner email me directly.  (In case it isn't obvious why, 
it's easy to construct an email in which "he" says it's ok; but if it comes 
directly from the owner, I can trust it.  Not that I think anyone's lying, but 
someday it'll happen and I want to get all my customers used to doing it right.

My boss didn't thoroughly understand my objection to accepting second-hand 
permissions.  So one night it occurred to me that a demonstration might be 
educational.  Before I went home I sent him an email bringing up the subject 
again, explained my position, and said "...as you can see by the below email".  
Below I fadged up an email ostensibly from my boss to HIS boss, saying 
something uncomplimentary.

When I got in the next morning, the department was in an uproar.  Apparently my 
boss had completely missed the point of my email; all he could see was that 
someone had hacked his account, and he was on the verge of going to his boss to 
deny that he'd sent any such email.  I talked him down and explained again what 
I'd done.  But I don't think I'll try any such realistic demonstration again in 
future, not at least without more emphatic disclaimers surrounding it.

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

/* Being famous has its benefits, but fame isn't one of them.  -Larry Wall */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Roger Bolan
Sent: Tuesday, January 18, 2022 19:43

Well, mine was just silly and did not involve games or using unauthorized CPU 
time.
I was just doing my normal code development job and running PL/I compiles, 
links, and tests.
The systems I normally used restricted the jobnames to userid + a character.  
Then one of the systems I was working on allowed the jobname to
be whatever I wanted.   So I took one of my ordinary jobs that didn't use
any more time or resources than normal, and "just for fun" I gave it a jobname 
of "COREHOGG".

OMG!!   When I submitted that my phone immediately blew up with people
yelling at me about what did I think I was doing?   Not the operators.
They could see what it was.  But other users who just reacted to the name 
COREHOGG without knowing anything else about the job.

So I learned not to give jobnames "just for fun". :)

--- On Tue, Jan 18, 2022 at 3:41 PM Robert Prins  
wrote:
> OK, it's not the silly season, but have you ever used your employers 
> equipment to do something silly? And are not afraid to admit it?
>
> Well, I have in the early 1990'ies, and I actually got away with it, 
> without losing my job.
>
> And talking about jobs, if anyone of you know of any companies looking 
> for someone with 36+ years of PL/I, and a bit less Db2 and CICS, feel 
> free to drop me a line.
>
> So what did I do? Let's go back a few years…
> https://prino.neocities.org/blog/2022-01-19-setting-the-record-straight.html

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

Re: What not to do on a z/OS system...

[PINION, RICHARD W.]

Late night operations staff pushing each other across the raised floor on 
wheeled office chairs. 
Until one night, someone ran into the side of the IBM mainframe.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Roger Bolan
Sent: Tuesday, January 18, 2022 7:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What not to do on a z/OS system...

[External Email. Exercise caution when clicking links or opening attachments.]

Well, mine was just silly and did not involve games or using unauthorized CPU 
time.
I was just doing my normal code development job and running PL/I compiles, 
links, and tests.
The systems I normally used restricted the jobnames to userid + a character.  
Then one of the systems I was working on allowed the jobname to
be whatever I wanted.   So I took one of my ordinary jobs that didn't use
any more time or resources than normal, and "just for fun" I gave it a jobname 
of "COREHOGG".

OMG!!   When I submitted that my phone immediately blew up with people
yelling at me about what did I think I was doing?   Not the operators.
They could see what it was.  But other users who just reacted to the name 
COREHOGG without knowing anything else about the job.

So I learned not to give jobnames "just for fun". :)

--Roger

On Tue, Jan 18, 2022 at 3:41 PM Robert Prins 
wrote:

> OK, it's not the silly season, but have you ever used your employers 
> equipment to do something silly? And are not afraid to admit it?
>
> Well, I have in the early 1990'ies, and I actually got away with it, 
> without losing my job.
>
> And talking about jobs, if anyone of you know of any companies looking 
> for someone with 36+ years of PL/I, and a bit less Db2 and CICS, feel 
> free to drop me a line.
>
> So what did I do? Let's go back a few years…
>
> 
> Setting the record straight
> <
> https://urldefense.com/v3/__https://prino.neocities.org/blog/2022-01-1
> 9-setting-the-record-straight.html__;!!HnnddUIWDII9UQ!GB_iEXBvQwSXDTro
> 4bZX9Go8DZD4Zjg4SP5e13VDJEbdiXSLecGW46mMYasUSTU7-rk$
> >
>
> Robert
> --
> Robert AH Prins
> robert(a)prino(d)org
> The hitchhiking grandfather 
>  !!HnnddUIWDII9UQ!GB_iEXBvQwSXDTro4bZX9Go8DZD4Zjg4SP5e13VDJEbdiXSLecGW4
> 6mMYasUxQrZmmg$ > Some REXX code for use on z/OS 
>  .html__;!!HnnddUIWDII9UQ!GB_iEXBvQwSXDTro4bZX9Go8DZD4Zjg4SP5e13VDJEbdi
> XSLecGW46mMYasU9Ueigeo$ >
>
> --
> 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
Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

Re: What not to do on a z/OS system...

[Roger Bolan]

Well, mine was just silly and did not involve games or using unauthorized
CPU time.
I was just doing my normal code development job and running PL/I compiles,
links, and tests.
The systems I normally used restricted the jobnames to userid + a
character.  Then one of the systems I was working on allowed the jobname to
be whatever I wanted.   So I took one of my ordinary jobs that didn't use
any more time or resources than normal, and "just for fun" I gave it a
jobname of "COREHOGG".

OMG!!   When I submitted that my phone immediately blew up with people
yelling at me about what did I think I was doing?   Not the operators.
They could see what it was.  But other users who just reacted to the name
COREHOGG without knowing anything else about the job.

So I learned not to give jobnames "just for fun". :)

--Roger

On Tue, Jan 18, 2022 at 3:41 PM Robert Prins 
wrote:

> OK, it's not the silly season, but have you ever used your employers
> equipment to do something silly? And are not afraid to admit it?
>
> Well, I have in the early 1990'ies, and I actually got away with it,
> without losing my job.
>
> And talking about jobs, if anyone of you know of any companies looking for
> someone with 36+ years of PL/I, and a bit less Db2 and CICS, feel free to
> drop me a line.
>
> So what did I do? Let's go back a few years…
>
> 
> Setting the record straight
> <
> https://prino.neocities.org/blog/2022-01-19-setting-the-record-straight.html
> >
>
> Robert
> --
> Robert AH Prins
> robert(a)prino(d)org
> The hitchhiking grandfather 
> Some REXX code for use on z/OS
> 
>
> --
> 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: TSO RECEIVE prompt for output temporary dataset

[Seymour J Metz]

Why misrepresent what I wrote? Why misrepresent what Kolosu wrote? He quoted 
"The OP wants to RECEIVE to a temp DSN and PASS that data set to a subsequent 
job step.", so what he CLEARLY INTENDED was subsequent job step.

Please try to remain civil and drop the straw dummies.


--
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: Tuesday, January 18, 2022 7:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO RECEIVE prompt for output temporary dataset

On Tue, 18 Jan 2022 23:49:41 +, Seymour J Metz  wrote:

>No. In the context of a separate jobstep, "same REXX" only makes sense if 
>interpreted as "new invocation of same REXX".
>
Is it past  your nap time?  You're getting grouchy.

Why assert something opposite to what Kolusu clearly intended
then endeavor to rebut it?

>... Without the restriction to separate jobsteps, it's trivial to use the 
> temporary twice in the same invocation.

>
>From:  Sri h Kolusu
>Sent: Tuesday, January 18, 2022 6:02 PM
>
>> What does he code in the JCL of the next step in order to allocate the
>temporary dataset that he created in the REXX?
>
>I guess you overlooked this sentence from my message "OP then needs to
>finish the next step processing also in the same rexx."

-- 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: TSO RECEIVE prompt for output temporary dataset

[Paul Gilmartin]

On Tue, 18 Jan 2022 23:49:41 +, Seymour J Metz  wrote:

>No. In the context of a separate jobstep, "same REXX" only makes sense if 
>interpreted as "new invocation of same REXX". 
>
Is it past  your nap time?  You're getting grouchy.

Why assert something opposite to what Kolusu clearly intended
then endeavor to rebut it?

>... Without the restriction to separate jobsteps, it's trivial to use the 
> temporary twice in the same invocation.

>
>From:  Sri h Kolusu
>Sent: Tuesday, January 18, 2022 6:02 PM
>
>> What does he code in the JCL of the next step in order to allocate the
>temporary dataset that he created in the REXX?
>
>I guess you overlooked this sentence from my message "OP then needs to
>finish the next step processing also in the same rexx."

-- gil

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

Re: What not to do on a z/OS system...

[Seymour J Metz]

Well, I was once a systems programmer at an SVS shop and was entitled to the 
use of Gerhard Postpischil's (ז״ל) EXHIBIT. I disabled the games, and the 
operations manager insisted that I re-enable them. 

Another shop used the proceeds from recycled paper to pay for a monthly beer 
bash.

What is allowed, or even encouraged, depends very much on local management.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robert Prins [robert.ah.pr...@gmail.com]
Sent: Tuesday, January 18, 2022 7:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: What not to do on a z/OS system...

OK, it's not the silly season, but have you ever used your employers
equipment to do something silly? And are not afraid to admit it?

Well, I have in the early 1990'ies, and I actually got away with it,
without losing my job.

And talking about jobs, if anyone of you know of any companies looking for
someone with 36+ years of PL/I, and a bit less Db2 and CICS, feel free to
drop me a line.

So what did I do? Let's go back a few years…


Setting the record straight


Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 

Some REXX code for use on z/OS


--
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: TSO RECEIVE prompt for output temporary dataset

[Seymour J Metz]

No. In the context of a separate jobstep, "same REXX" only makes sense if 
interpreted as "new invocation of same REXX". Without the restriction to 
separate jobsteps, it's trivial to use the temporary twice in the same 
invocation.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Sri 
h Kolusu [skol...@us.ibm.com]
Sent: Tuesday, January 18, 2022 6:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO RECEIVE prompt for output temporary dataset

> What does he code in the JCL of the next step in order to allocate the
temporary dataset that he created in the REXX?


I guess you overlooked this sentence from my message "OP then needs to
finish the next step processing also in the same rexx."


Thanks,
Kolusu

--
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: What not to do on a z/OS system...

[Tom Brennan]

Does the Xerox machine count?

On 1/18/2022 4:41 PM, Robert Prins wrote:

OK, it's not the silly season, but have you ever used your employers
equipment to do something silly? And are not afraid to admit it?



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

Re: TSO RECEIVE prompt for output temporary dataset

[Seymour J Metz]

That doesn't answer the question. I know of no way to do it as written. 
Allocating the temporary in the JCL rather than in the REXX is a change of 
specifications.

Even if IBM added a PASS disposition to SVC 99 TU types 0005 and 0006, there 
would be no way to identify the passed dataset in the JCL without additional 
DYNALLOC changes.


--
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: Tuesday, January 18, 2022 6:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO RECEIVE prompt for output temporary dataset

On Tue, 18 Jan 2022 22:48:19 +, Seymour J Metz  wrote:

>What does he code in the JCL of the next step in order to allocate the 
>temporary dataset that he created in the REXX?
>
He said and you quoted below: "OP then needs to
finish the next step processing also in the same rexx."

Or, allocate with JCL DD and PASS; snag DSN and VOL
in Rexx for RECEIVE reply.

I could imagine passing DSN and VOL in a file.  Butt does
the temp data set survive the job step boundary?


>
>From:  Sri h Kolusu
>Sent: Tuesday, January 18, 2022 2:35 PM
>
>> The OP wants to RECEIVE to a temp DSN and PASS that data set to a
>> subsequent job step.
>
>Well if  REXX is an option then he can allocate a temp dataset and get the
>name using LISTDSI and then issue the RECEIVE  command. OP then needs to
>finish the next step processing also in the same rexx.
>
>/* REXX */
>"ALLOC DD(MYRCVD) NEW REU UNIT(SYSDA) RECFM(F B) LRECL(80),
> SPACE(75,30) TRACKS DIR(30) DSORG(PO)"
>DDINFO = LISTDSI("MYRCVD" "FILE")
>SAY "TEMP DATASET NAME: "SYSDSNAME
>X=PROMPT('ON')
>X=MSG('ON')
>RECEIVER='Userid'
>RCVPARMS=''
>OUTDSN=SYSDSNAME
>QUEUE "DATASET('"OUTDSN"') "RCVPARMS
>QUEUE "END"
>"RECEIVE USER("RECEIVER")"
>
>
>next step process here

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

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

Re: TSO RECEIVE prompt for output temporary dataset

[Seymour J Metz]

VOL=, yes, but not an explicit VOL=SER=.


--
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: Tuesday, January 18, 2022 11:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO RECEIVE prompt for output temporary dataset

On Tue, 18 Jan 2022 13:59:13 +, Seymour J Metz wrote:

>In JCL, you can refer multiple times to the same temporary DSN;
>
Mostly true, but when I refer multiple times in the same job step
I haveee needed to specify VOL.

>... allowing  in PARSE, DAIR and DYNALLOC would allow doing the 
> same thing dynamically. As it stands, you have to extract the DSN and volume 
> from the first allocation and use them in the remaining allocations.

-- 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: More of LOG4J

[Seymour J Metz]

> Since I would guess that a majority of ibm-mainers would agree that 
> open source is confusing and dangerous, here's a question: 

Why? Have there been polls? Is that based on feedback from your customers?

> Let's say that an organization wanted to prohibit open source.  How would you 
> go about it?

I'm not sure that it is possible on z; certainly not on z/OS.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Kirk Wolf [k...@dovetail.com]
Sent: Tuesday, January 18, 2022 11:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: More of LOG4J

Since I would guess that a majority of ibm-mainers would agree that open source 
is confusing and dangerous, here's a question:

Let's say that an organization wanted to prohibit open source.  How would you 
go about it?

Kirk Wolf
Dovetailed Technologies
http://secure-web.cisco.com/18Y18C1GjfUVpT_GNSsVukfmHVcqlHciPs9HKvLRsyUaKHPDtCnbiuO4rlCj7f2uFrCktsyQPqDGPU_HGZgF6AG1G5FlyKceDb9CoRQWJqPYFPj7GuqomGMzX0Bsuyvj-nfaXSeUpCtrzZ-5WrEVS3osnkp5IMjdFjQElWfHmjEVxt5ehnIrPHqEdBwcrHJXTL1gXOOaylnWF7JRjdOi-aOK7_Ek_JmjIZQjKoIxnKRqkGKvpWayLJmXIQjqJgDluPP0BHmAnX4QAZRSQ2XHiuS6EE34-sqVQArB4StaWkf_TEseRm698gk6i5IXXk9v1MiWUZ-Aocu_BfSdKUxVQoQ9mwgo5Qs-u5HRumaWxzsHT4bkeAM5ZRDxmicZZMI3adeyEbC1b_AGpnCp0m0TBCMOk6kBq4mQ50Q0m8u8EU0z9NfJzFnXZgatkgthli65e/http%3A%2F%2Fdovetail.com

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

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

Re: More of LOG4J

[Seymour J Metz]

Definitely not open source; some material on the CBT tape was object code only, 
although the bulk of it was always open source.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
PINION, RICHARD W. [rpin...@firsthorizon.com]
Sent: Tuesday, January 18, 2022 12:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: More of LOG4J

Would one consider the CBT Tape to be open source?  I've used CBT programs in 
many places I've worked at.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter x23353
Sent: Tuesday, January 18, 2022 12:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: More of LOG4J

[External Email. Exercise caution when clicking links or opening attachments.]

Your guess is not universal.  I for one embrace open source as the future for 
the z ecosystem.

How to successfully manage that "new" environment for potentially dangerous 
dependencies is certainly an issue, but not an unsolvable one.  Certainly I 
think IBM itself needs to assist to help solve such issues to maintain the z 
RAS level.

My guess is that one cannot prohibit open source, it is far too prevalent and 
necessary for many if not most organizations actively using z/OS to run their 
business (e.g.,  the Apache / Tomcat web server software delivered as part of 
z/OS is also open source - Would you prohibit that too?).

IMHO it is foolish to attempt to prohibit what you don't like or understand.  
Seek first to understand it and then how to manage the risks.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Kirk Wolf
Sent: Tuesday, January 18, 2022 11:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: More of LOG4J

Since I would guess that a majority of ibm-mainers would agree that open source 
is confusing and dangerous, here's a question:

Let's say that an organization wanted to prohibit open source.  How would you 
go about it?

Kirk Wolf
Dovetailed Technologies
--

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

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

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

Re: More of LOG4J

[Seymour J Metz]

It very much depends on what software you are talking about. There was software 
from IBM with ghastly support. There was chargeable software from CA with 
appalling packaging. There was free software with excellent support. Even 
within a single developer it can vary widely from program to program.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Clark Morris [03b2c618bdfc-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, January 18, 2022 12:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: More of LOG4J

On Tuesday 18/01/2022 at 12:42 pm, Kirk Wolf  wrote:
> Since I would guess that a majority of ibm-mainers would agree that
> open source is confusing and dangerous, here's a question:
As someone who installed and modified JES2 exits from the CBT tape,
modified HASP with British Rail and other contributions  from the
Michigan mods tapes and used another mods tape for an IEBCOPY
replacement as well as being someone who contributed back to the
Michigan Mods 1979 tape, the JES3 tape and the CBTTAPE, I would not
call open source confusing and dangerous. Anything that is put on a
system has to be maintained either in house or by some trusted party
be it a vendor or an open source project.  The user has to understand
the supplier's notification and update process and be able to use it
in their environment.  There have been both open source fiascos and
vendor related fiascos.


Clark Morris
>
>
>
> Let's say that an organization wanted to prohibit open source.  How
> would you go about it?
>
> Kirk Wolf
> Dovetailed Technologies
> http://secure-web.cisco.com/1NqXtEGbELDj8GTt1o7CjZSi9c6HQpwwh3HDzNgz4ccaqyvMVE7GOxk0HV52bhVq-zmiaO67GGcctOV63GXkfa0cV7lmMYb4l8gJiVt4SdJnL2Q0M8nzomnJ1Us9ybORF4tmaegym4PQ5uQ2TlykRITm7_1mljjrwyJIv6Fz7vlSAXTC5idmBUe6T5BySSQ2Lyq8SP1H1GH4j4BSsRzZSEuEQuAvDVO_I7qh9JzlnRgX3yYvgXdvON7AKrzTfumSq_fG0Gl-Q1WI2scr9foQOa8xKL21MJqPRBL2Zcpn5HgvAQoXfpqkEBaN1TBQ4rvrHkJS0iinyPjzE6Bh03oPTnnuTiKlTvy5Enta0sQokuL0hFJvoUIzOoV7T9l84fEiZdxGgeKrtMD3ocyZ1_1eIyh0uhLigxVSAQbuKP8QwaTED7l0ZgghO_1MALPOirKyg/http%3A%2F%2Fdovetail.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


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

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

Re: What not to do on a z/OS system...

[Bob Bridges]

Dunno whether this counts, but I got very far (but not quite all the way) to 
hacking Colossal Cave's "magic mode".  That wasn't on an IBM mainframe; it was 
a DecSystem-10.  On that machine you could stop program execution with a 
Ctrl-C, then inspect the machine code at your leisure.  And I was writing a lot 
of stuff in that machine's assembler, so I could interpret it fairly easily.

But it was at a university, where my boss apparently had the university 
attitude:  He didn't mind if I learned new machine skills, attended an Arabic 
class, whatever as long as I met his needs.  Still, it was on my employer's 
equipment.

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

/* Being famous has its benefits, but fame isn't one of them.  -Larry Wall */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Robert Prins
Sent: Tuesday, January 18, 2022 19:41

OK, it's not the silly season, but have you ever used your employers equipment 
to do something silly? And are not afraid to admit it?

Well, I have in the early 1990'ies, and I actually got away with it, without 
losing my job.

And talking about jobs, if anyone of you know of any companies looking for 
someone with 36+ years of PL/I, and a bit less Db2 and CICS, feel free to drop 
me a line.

So what did I do? Let's go back a few years…

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

Re: TSO RECEIVE prompt for output temporary dataset

[Paul Gilmartin]

On Tue, 18 Jan 2022 22:48:19 +, Seymour J Metz  wrote:

>What does he code in the JCL of the next step in order to allocate the 
>temporary dataset that he created in the REXX?
> 
He said and you quoted below: "OP then needs to
finish the next step processing also in the same rexx."

Or, allocate with JCL DD and PASS; snag DSN and VOL
in Rexx for RECEIVE reply.

I could imagine passing DSN and VOL in a file.  Butt does
the temp data set survive the job step boundary?


>
>From:  Sri h Kolusu
>Sent: Tuesday, January 18, 2022 2:35 PM
>
>> The OP wants to RECEIVE to a temp DSN and PASS that data set to a
>> subsequent job step.
>
>Well if  REXX is an option then he can allocate a temp dataset and get the
>name using LISTDSI and then issue the RECEIVE  command. OP then needs to
>finish the next step processing also in the same rexx.
>
>/* REXX */
>"ALLOC DD(MYRCVD) NEW REU UNIT(SYSDA) RECFM(F B) LRECL(80),
> SPACE(75,30) TRACKS DIR(30) DSORG(PO)"
>DDINFO = LISTDSI("MYRCVD" "FILE")
>SAY "TEMP DATASET NAME: "SYSDSNAME
>X=PROMPT('ON')
>X=MSG('ON')
>RECEIVER='Userid'
>RCVPARMS=''
>OUTDSN=SYSDSNAME
>QUEUE "DATASET('"OUTDSN"') "RCVPARMS
>QUEUE "END"
>"RECEIVE USER("RECEIVER")"
>
>
>next step process here

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

Re: TSO RECEIVE prompt for output temporary dataset

[Seymour J Metz]

Yes, IBM would need o add a new value to TU keys 0005 and 0006.

I would say to allow a directory or a link to a directory, but not a special 
file, which would exclude a pipe.


--
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: Tuesday, January 18, 2022 1:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO RECEIVE prompt for output temporary dataset

On Mon, 17 Jan 2022 16:57:29 +, Seymour J Metz wrote:

>That should work. I still think that there should be an OUTDD parameter on 
>RECEIVE.
>
The OP wants to RECEIVE to a temp DSN and PASS that data set to a subsequent 
job step.

PASS requires a DD statement in JCL.  Allocating that data set requires
a priori knowledge of attributes such as DSORG and SPACE which are
known only after seeing the prompt:
Enter restore parameters or 'DELETE' or 'END' +
The input file attributes are: DSORG=PARTITIONED, RECFM=FB,BLKSIZE=27920, 
LRECL...
You may enter DSNAME, SPACE, UNIT, VOL, OLD/NEW, or RESTORE/COPY/DELETE/END

OUTDD might solve some problems; not thisi one.  Should the prompt supply 
needed optiions
and allow escape to command line to ALLOCATE?

Should OUTDD be allowed to indicate a UNIX PATH?  A pipe to uudecode?  A pipe 
to AMATERSE?

-- 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: TSO RECEIVE prompt for output temporary dataset

[Sri h Kolusu]

> What does he code in the JCL of the next step in order to allocate the
temporary dataset that he created in the REXX?


I guess you overlooked this sentence from my message "OP then needs to
finish the next step processing also in the same rexx."


Thanks,
Kolusu

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

Re: TSO RECEIVE prompt for output temporary dataset

[Seymour J Metz]

What does he code in the JCL of the next step in order to allocate the 
temporary dataset that he created in the REXX?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Sri 
h Kolusu [skol...@us.ibm.com]
Sent: Tuesday, January 18, 2022 2:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO RECEIVE prompt for output temporary dataset

> The OP wants to RECEIVE to a temp DSN and PASS that data set to a
> subsequent job step.

Well if  REXX is an option then he can allocate a temp dataset and get the
name using LISTDSI and then issue the RECEIVE  command. OP then needs to
finish the next step processing also in the same rexx.

/* REXX */
"ALLOC DD(MYRCVD) NEW REU UNIT(SYSDA) RECFM(F B) LRECL(80),
 SPACE(75,30) TRACKS DIR(30) DSORG(PO)"
DDINFO = LISTDSI("MYRCVD" "FILE")
SAY "TEMP DATASET NAME: "SYSDSNAME
X=PROMPT('ON')
X=MSG('ON')
RECEIVER='Userid'
RCVPARMS=''
OUTDSN=SYSDSNAME
QUEUE "DATASET('"OUTDSN"') "RCVPARMS
QUEUE "END"
"RECEIVE USER("RECEIVER")"


next step process here


Thanks,
Kolusu

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

What not to do on a z/OS system...

[Robert Prins]

OK, it's not the silly season, but have you ever used your employers
equipment to do something silly? And are not afraid to admit it?

Well, I have in the early 1990'ies, and I actually got away with it,
without losing my job.

And talking about jobs, if anyone of you know of any companies looking for
someone with 36+ years of PL/I, and a bit less Db2 and CICS, feel free to
drop me a line.

So what did I do? Let's go back a few years…


Setting the record straight


Robert
-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


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

Re: LISTDSI (was: TSO RECEIVE prompt for output temporary dataset)

[Sri h Kolusu]

> What was your LISTDSI?  Did you use the FILE option?

Yes. I did use the FILE option

DDINFO = LISTDSI("MYRCVD" "FILE")

Thanks,
Kolusu

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

LISTDSI (was: TSO RECEIVE prompt for output temporary dataset)

[Paul Gilmartin]

On Tue, 18 Jan 2022 13:02:39 -0700, Sri h Kolusu wrote:

>> Some of those attributes are available only from RECEIVE's prompt.
>
>True. But if OP is aware of the attributes then he can allocate temp files.
>
Perhaps only by a trial RECEIVE and cancelling.

>> Does this require either that DSN be catalogued or VOL be suppled?
>
What was your LISTDSI?  Did you use the FILE option?

LISTDSI is poorly documented, IMO.  I once allocated a data set with
overriding attributes and issued LISTDSI FILE, assuming it would return
the attributes of the FILE (TSO jargon).  Nope, to my dismay it returned
the attributes from the DSCB.

The Ref. says, " LISTDSI does not support hierarchical file system
(HFS) data sets."  I just submitted a (disingenuous?) RCF asking
whether it supports zFS.  I neglected to ask about NFS.

>Nope. Running with TRACE this is what I got
>
>INMR901I Dataset SYS1.PARMLIB from USERID on SNJMAS3
>INMR902I Members: ADYSET00
>INMR906A Enter restore parameters or 'DELETE' or 'END' +
>INMR001I Restore successful to dataset
>'SYS22018.T125746.RA000.USERID.R0399354'
>INMR144I Sender notified of receipt

-- gil

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

Re: RFE for FTP server security documentation

[Lennie Dymoke-Bradshaw]

I have just received an email from IBM saying the RFE has now been made PUBLIC. 
Apologies, I was unaware that it needed to go through that stage.

Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lennie Dymoke-Bradshaw
Sent: 18 January 2022 16:21
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RFE for FTP server security documentation

Maybe it is too new ☹.
Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B. Dyck
Sent: 18 January 2022 16:11
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RFE for FTP server security documentation

Tried to vote but was not authorized - even after logging in ☹


Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck

“Worry more about your character than your reputation. Character is what you 
are, reputation merely what others think you are.”   - - - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lennie Dymoke-Bradshaw
Sent: Tuesday, January 18, 2022 10:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RFE for FTP server security documentation

The URL has been mangled somewhere along the way. The REF number is 153764.
I think you will need an IBM Id to vote.
Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lennie Dymoke-Bradshaw
Sent: 18 January 2022 16:00
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RFE for FTP server security documentation

Greetings all,

 

I have raised an RFE requesting IBM clarify the situation regarding the use of 
UID(0) for the z/OS FTP server.

I ask if you would please vote for it.

 

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe
 _ID=153764

 



Lennie Dymoke-Bradshaw

https://rsclweb.com   


'Dance like no one is watching. Encrypt like everyone is.'

 


--
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: TSO RECEIVE prompt for output temporary dataset

[Sri h Kolusu]

> Some of those attributes are available only from RECEIVE's prompt.

True. But if OP is aware of the attributes then he can allocate temp files.

> Does this require either that DSN be catalogued or VOL be suppled?

Nope. Running with TRACE this is what I got

INMR901I Dataset SYS1.PARMLIB from USERID on SNJMAS3
INMR902I Members: ADYSET00
INMR906A Enter restore parameters or 'DELETE' or 'END' +
INMR001I Restore successful to dataset
'SYS22018.T125746.RA000.USERID.R0399354'
INMR144I Sender notified of receipt


Thanks,
 Kolusu

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

Re: TSO RECEIVE prompt for output temporary dataset

[Paul Gilmartin]

On Tue, 18 Jan 2022 12:35:57 -0700, Sri h Kolusu wrote:

>> The OP wants to RECEIVE to a temp DSN and PASS that data set to a
>> subsequent job step.
>
>Well if  REXX is an option then he can allocate a temp dataset and get the
>name using LISTDSI
>... and then issue the RECEIVE  command. OP then needs to
>finish the next step processing also in the same rexx.
>
OP's mention of a subsequent job step may have been overspecification.

>/* REXX */
>"ALLOC DD(MYRCVD) NEW REU UNIT(SYSDA) RECFM(F B) LRECL(80),
> SPACE(75,30) TRACKS DIR(30) DSORG(PO)"
>
Some of those attributes are available only from RECEIVE's prompt.

>DDINFO = LISTDSI("MYRCVD" "FILE")
>SAY "TEMP DATASET NAME: "SYSDSNAME
>X=PROMPT('ON')
>X=MSG('ON')
>RECEIVER='Userid'
>RCVPARMS=''
>OUTDSN=SYSDSNAME
>QUEUE "DATASET('"OUTDSN"') "RCVPARMS
>
Does this require either that DSN be catalogued or VOL be suppled?

>QUEUE "END"
>"RECEIVE USER("RECEIVER")"
>
>next step process here

-- gil

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

Re: TSO RECEIVE prompt for output temporary dataset

[Sri h Kolusu]

> The OP wants to RECEIVE to a temp DSN and PASS that data set to a
> subsequent job step.

Well if  REXX is an option then he can allocate a temp dataset and get the
name using LISTDSI and then issue the RECEIVE  command. OP then needs to
finish the next step processing also in the same rexx.

/* REXX */
"ALLOC DD(MYRCVD) NEW REU UNIT(SYSDA) RECFM(F B) LRECL(80),
 SPACE(75,30) TRACKS DIR(30) DSORG(PO)"
DDINFO = LISTDSI("MYRCVD" "FILE")
SAY "TEMP DATASET NAME: "SYSDSNAME
X=PROMPT('ON')
X=MSG('ON')
RECEIVER='Userid'
RCVPARMS=''
OUTDSN=SYSDSNAME
QUEUE "DATASET('"OUTDSN"') "RCVPARMS
QUEUE "END"
"RECEIVE USER("RECEIVER")"


next step process here


Thanks,
Kolusu

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

Re: TSO RECEIVE prompt for output temporary dataset

[Tony Harminc]

On Tue, 18 Jan 2022 at 09:02, Seymour J Metz  wrote:
>
> Did the fix only hit PARSE, or was the syntax also supported in DAIR and 
> DYNALLOC? I don't see much utility in being able to parse a temporary DSN if 
> I can't use it for a dynamic allocation.

I don't remember the details, other than that it was entirely evident
to anyone who's used IKJPARS and DAIR or DYNALLOC that there was a
*lot* more work to be done. I imagine it was seen as a simple fix by
the change team, and then at some point someone with more
understanding had it withdrawn.

Which is why it would be great if one of our IBM friends would try to
find it and perhaps comment.

Tony H.
_
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Tony Harminc [t...@harminc.net]
> Sent: Monday, January 17, 2022 7:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TSO RECEIVE prompt for output temporary dataset
>
> On Mon, 17 Jan 2022 at 11:08, Seymour J Metz  wrote:
> >
> > The ampersand for temporary dataset names is a JCL convention, not a TSO 
> > convention.
>
> Back in the late 1970s or maybe early 1980s there was a short-lived
> APAR "fix" that added support for using the ampersand to specify
> temporary datasets in IKJPARS. It was quickly withdrawn - I speculate
> because someone with the necessary design sense could see that there
> would be a near endless series of followon fixes to make everything
> work.
>
> Maybe one of our IBMers here could dig up that APAR or even comment on
> what happened.
>
> Tony H.

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

Re: COBOL V6 question

[Tom Ross]

>The compile time costs should be tolerable given benefits of runtime execut=
>ion.  Has IBM been able to provide, or have other people seen demonstrable =
>benefits?

We have seen results all over the map!  One customer recompiled an application
and found it to run 70% faster!  Seventy percent!  Others get 5% - 40%
improvement.  With very small programs the benefit it minimal, some CICS
customers do not see much improvement.  One CICS customer in Chicago told us
they got over 50% improvmenet in throughput with COBOL V6, they could change
their business processes to handle more claims!

In general, customers compile a program once or three times, then put it into
production and run it thousands or millions of times, so the payback is
definitely there in overal CPU savings!

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: More of LOG4J

[Dave Jousma]

On Tue, 18 Jan 2022 10:41:41 -0600, Kirk Wolf  wrote:

>Since I would guess that a majority of ibm-mainers would agree that open 
>source is confusing and dangerous, here's a question:
>
>Let's say that an organization wanted to prohibit open source.  How would you 
>go about it?
>
>Kirk Wolf
>Dovetailed Technologies
>http://dovetail.com
>

We have all kinds of open source, including all the ports IBM has made 
available.   It all depends on "who supports, when broken".   We have nothing 
in Prod environment that isn't supported by someone (a vendor).   Rocket Git 
client we pay for support through IBM, so that we can continue opening tickets 
through IBM portal.  Other stuff like PDS, TASID, we have but we dont make 
available to general public.  We have Dovetail's Wiki/Tomcat port for our own 
technical information repository, but even that is not used in any production 
business application capacity.

A general user could download "stuff" i guess, but in the end, if my team didnt 
install it, then they are on their own, including answering to all the various 
review groups (audit, risk, infosec, etc).

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

Re: TSO RECEIVE prompt for output temporary dataset

[Paul Gilmartin]

On Mon, 17 Jan 2022 16:57:29 +, Seymour J Metz wrote:

>That should work. I still think that there should be an OUTDD parameter on 
>RECEIVE.
>
The OP wants to RECEIVE to a temp DSN and PASS that data set to a subsequent 
job step.

PASS requires a DD statement in JCL.  Allocating that data set requires
a priori knowledge of attributes such as DSORG and SPACE which are
known only after seeing the prompt:
Enter restore parameters or 'DELETE' or 'END' + 

The input file attributes are: DSORG=PARTITIONED, RECFM=FB,BLKSIZE=27920, 
LRECL...
You may enter DSNAME, SPACE, UNIT, VOL, OLD/NEW, or RESTORE/COPY/DELETE/END 
 

OUTDD might solve some problems; not thisi one.  Should the prompt supply 
needed optiions
and allow escape to command line to ALLOCATE?

Should OUTDD be allowed to indicate a UNIX PATH?  A pipe to uudecode?  A pipe 
to AMATERSE?

-- gil

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

Re: More of LOG4J

[Itschak Mugzach]

Kirk, No way! This is under the title of mainframe modernisation. There are
so many services that are based on open source as well as many vendor
products. Open source is part of our life. Now we have to deal (and live)
with it.

What I am saying is that there are thousands of java jar files in USS and
you don't know your risks. Just for the record, on my 2.3 system there are
about 14,000 different jar files. We were able to analyze all of them and
propagate it with NVD. Will run tomorrow on 2.4. I expect to see the same
issues.

ITschak

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Tue, Jan 18, 2022 at 6:42 PM Kirk Wolf  wrote:

> Since I would guess that a majority of ibm-mainers would agree that open
> source is confusing and dangerous, here's a question:
>
> Let's say that an organization wanted to prohibit open source.  How would
> you go about it?
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: More of LOG4J

[Colin Paice]

A lot of the discussion comes down to management of risk.

   1. If we have a problem will we be able to get it fixed.
   1. Check the forums and see how the product is treated
  2. Are there people in the community who help out with questions
   2. If we find we cannot use this product at any time
   1. do we have a fall back plan?
  2. What would be the cost of alternatives
   3. With our existing  "in house" software
  1. What happens if one or more people who support it ( who know and
  love it), if they leave
  2. Do we need to train up other people in this software.
  3. Should we allocate some resource to help support the "open source"
  software we want to use eg 1person day a week.

Most customers have different levels of risk, isolation of data, areas of
responsibility and  access.


"Open source" is just one more factor.

Colin

On Tue, 18 Jan 2022 at 17:21, Clark Morris <
03b2c618bdfc-dmarc-requ...@listserv.ua.edu> wrote:

> On Tuesday 18/01/2022 at 12:42 pm, Kirk Wolf  wrote:
> > Since I would guess that a majority of ibm-mainers would agree that
> > open source is confusing and dangerous, here's a question:
> As someone who installed and modified JES2 exits from the CBT tape,
> modified HASP with British Rail and other contributions  from the
> Michigan mods tapes and used another mods tape for an IEBCOPY
> replacement as well as being someone who contributed back to the
> Michigan Mods 1979 tape, the JES3 tape and the CBTTAPE, I would not
> call open source confusing and dangerous. Anything that is put on a
> system has to be maintained either in house or by some trusted party
> be it a vendor or an open source project.  The user has to understand
> the supplier's notification and update process and be able to use it
> in their environment.  There have been both open source fiascos and
> vendor related fiascos.
>
>
> Clark Morris
> >
> >
> >
> > Let's say that an organization wanted to prohibit open source.  How
> > would you go about it?
> >
> > Kirk Wolf
> > Dovetailed Technologies
> > http://dovetail.com
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: More of LOG4J

[Tom Brennan]

I'm not in that majority, but if getting rid of all things open-source 
became a mandate, I'd communicate to management what Stuart Holland used 
to tell me:  First shut down things like SSH, anything that uses 
OpenSSL, USS programs, etc.  It would be a mess.


And like someone else here mentioned, there are CBT programs that many 
people have become to rely on, whether they realize it or not.


On 1/18/2022 8:41 AM, Kirk Wolf wrote:

Since I would guess that a majority of ibm-mainers would agree that open source 
is confusing and dangerous, here's a question:

Let's say that an organization wanted to prohibit open source.  How would you 
go about it?

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

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



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

Re: co Z Batch

[Mark Jacobs]

Go to the vendor website, download and install the latest version. Depending on 
what level you're running now, there might be migration actions needed.

https://dovetail.com/downloads/coz/index.html

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

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

‐‐‐ Original Message ‐‐‐

On Tuesday, January 18th, 2022 at 12:07 PM, esst...@juno.com  
wrote:

> 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: More of LOG4J

[Clark Morris]

On Tuesday 18/01/2022 at 12:42 pm, Kirk Wolf  wrote:
Since I would guess that a majority of ibm-mainers would agree that 
open source is confusing and dangerous, here's a question:
As someone who installed and modified JES2 exits from the CBT tape, 
modified HASP with British Rail and other contributions  from the 
Michigan mods tapes and used another mods tape for an IEBCOPY 
replacement as well as being someone who contributed back to the 
Michigan Mods 1979 tape, the JES3 tape and the CBTTAPE, I would not 
call open source confusing and dangerous. Anything that is put on a 
system has to be maintained either in house or by some trusted party 
be it a vendor or an open source project.  The user has to understand 
the supplier's notification and update process and be able to use it 
in their environment.  There have been both open source fiascos and 
vendor related fiascos.



Clark Morris




Let's say that an organization wanted to prohibit open source.  How 
would you go about it?


Kirk Wolf
Dovetailed Technologies
http://dovetail.com

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



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

Re: More of LOG4J

[PINION, RICHARD W.]

Would one consider the CBT Tape to be open source?  I've used CBT programs in 
many places I've worked at.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter x23353
Sent: Tuesday, January 18, 2022 12:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: More of LOG4J

[External Email. Exercise caution when clicking links or opening attachments.]

Your guess is not universal.  I for one embrace open source as the future for 
the z ecosystem.

How to successfully manage that "new" environment for potentially dangerous 
dependencies is certainly an issue, but not an unsolvable one.  Certainly I 
think IBM itself needs to assist to help solve such issues to maintain the z 
RAS level.

My guess is that one cannot prohibit open source, it is far too prevalent and 
necessary for many if not most organizations actively using z/OS to run their 
business (e.g.,  the Apache / Tomcat web server software delivered as part of 
z/OS is also open source - Would you prohibit that too?).

IMHO it is foolish to attempt to prohibit what you don't like or understand.  
Seek first to understand it and then how to manage the risks.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Kirk Wolf
Sent: Tuesday, January 18, 2022 11:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: More of LOG4J

Since I would guess that a majority of ibm-mainers would agree that open source 
is confusing and dangerous, here's a question:

Let's say that an organization wanted to prohibit open source.  How would you 
go about it?

Kirk Wolf
Dovetailed Technologies
--

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

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

co Z Batch

[esst...@juno.com]

Hello.
.
We are running a free software product called co Z Batch on z/OS 2.3.
.
Does anyone run coZ Batch with z/OS 2.5 ?
Are there any Maintenance for coZ Batch required for z/OS 2.5 ?
.
Thanks
Paul D'Angelo

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

Re: More of LOG4J

[Farley, Peter x23353]

Your guess is not universal.  I for one embrace open source as the future for 
the z ecosystem.

How to successfully manage that "new" environment for potentially dangerous 
dependencies is certainly an issue, but not an unsolvable one.  Certainly I 
think IBM itself needs to assist to help solve such issues to maintain the z 
RAS level.

My guess is that one cannot prohibit open source, it is far too prevalent and 
necessary for many if not most organizations actively using z/OS to run their 
business (e.g.,  the Apache / Tomcat web server software delivered as part of 
z/OS is also open source - Would you prohibit that too?).

IMHO it is foolish to attempt to prohibit what you don't like or understand.  
Seek first to understand it and then how to manage the risks.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Kirk Wolf
Sent: Tuesday, January 18, 2022 11:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: More of LOG4J

Since I would guess that a majority of ibm-mainers would agree that open source 
is confusing and dangerous, here's a question:  

Let's say that an organization wanted to prohibit open source.  How would you 
go about it?   

Kirk Wolf
Dovetailed Technologies
--

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: JES2 mail notification

[Carmen Vitullo]

We use other JES2 batch to EMAIL products, JES2MAIL IIRC, J2JOE, but if 
you want to use the;



//NFT NOTIFY EMAIL='myem...@mydomain.com'

JES2 statement I think you need JES2EDS ?

correct me if I am mistaken

Carmen

On 1/18/2022 10:40 AM, Mark Regan wrote:

You should look at using Lionel Dyck's XMITIP REXX program. You can get it
directly from his site, athttps://www.lbdsoftware.com, or at CBT Tape, at
https://www.cbttape.org, file 314.

Regards,

Mark Regan, K8MTR General, EN80tg
CTO1 USNR-Retired (1969-1991)
Nationwide Insurance, Retired, 1986-2017
z/OS Network Software Consultant (z NetView, z/OS Communications Server)
Contractor, Checks & Balances, Inc.
Email:marktre...@gmail.com
LinkedIn:https://www.linkedin.com/in/mark-t-regan




On Sun, Jan 16, 2022 at 8:18 AM Mike Shorkend
wrote:


Hi,
I am trying to set up email notification for job termination but have run
into a problem that the JES2EDS started task  can't connect to z/OSMF. This
is the joblog(I have had to obfuscate the URI  and NODE)


   J E S 2  J O B  L O G  --  S Y S T E M  S Y S D  --  N O
D E  N O D E 1


1.25.31 S0452379  SUNDAY,16 JAN 2022 

1.25.31 S0452379  IEF196I IGD103I SMS ALLOCATED TO DDNAME SYS1

1.25.31 S0452379  IEF196I IGD104I SYS3.TCPIP.TCPPARMS
RETAINED,
1.25.31 S0452379  IEF196I DDNAME=SYS1

1.25.31 S0452379  IEF196I IGD103I SMS ALLOCATED TO DDNAME SYS5

1.25.31 S0452379  IEF196I IGD104I SYS3.TCPIP.TCPPARMS
RETAINED,
1.25.31 S0452379  IEF196I DDNAME=SYS5

1.25.31 S0452379  IEF196I IGD103I SMS ALLOCATED TO DDNAME SYS7

1.25.31 S0452379  IEF196I IGD104I SYS3.PLX2.TCPIP.STANDARD.TCPXLBIN
RETAINED,
1.25.31 S0452379  IEF196I DDNAME=SYS7

1.25.31 S0452379  IEF196I IGD103I SMS UNIX FILE ALLOCATED TO DDNAME
SYS00011
1.25.31 S0452379  IEF196I IGD104I UNIX FILE WAS RETAINED, DDNAME IS
(SYS00011)
1.25.31 S0452379  IEF196I FILENAME IS (/etc/hosts)

1.25.32 S0452379  $HASP1529 106 0420 Socket closed by remote partner

1.25.32 S0452379  $HASP1534 z/OSMF server URI
https://host.domain.co.il:1443/zosmf
1.25.32 S0452379  $HASP1535 Current message is in email queue $EDSQ004 at
offset 
   918   in EMQT 0288FF01

1.25.32 S0452379 *$HASP1523 Unable to connect to z/OSMF server.



If I plugin the URI to a browser, I connect to z/OMSF without a problem.


$HASP1529   sends you to the HTTP toolkit where a 106 return code is:

Meaning: A communication error has been detected. One or
more of the following problems has occurred:
• A failure in the communication with the web server
• An error in an underlying sockets or SSL/TLS service call
• An error in obtaining the necessary system resources to
process the connect.
Action: Check the diagArea for further diagnostic information.
The toolkit uses many internal services, including sockets, SSL,
and other calls when processing an HTTP API service call. If one
of these internal services fails because of an error in
communications with the targeted server or because of an
internal environmental condition, the error is reported in the
diagnostic area. This information can be useful to the
application programmer but, in many cases, it is for the use of
IBM Support. If one of these errors occurs, clean up the
environment, check for possible communication configuration
problems, and reissue the request

Before opening a case with IBM, has anyone else run into this (and
hopefully solved it)?
z/OS 2.4  and I think that I have followed all the prereq tasks.

Thanks

Mike

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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: More of LOG4J

[Kirk Wolf]

Since I would guess that a majority of ibm-mainers would agree that open source 
is confusing and dangerous, here's a question:  

Let's say that an organization wanted to prohibit open source.  How would you 
go about it?   

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

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

Re: JES2 mail notification

[Mark Regan]

You should look at using Lionel Dyck's XMITIP REXX program. You can get it
directly from his site, at https://www.lbdsoftware.com, or at CBT Tape, at
https://www.cbttape.org, file 314.

Regards,

Mark Regan, K8MTR General, EN80tg
CTO1 USNR-Retired (1969-1991)
Nationwide Insurance, Retired, 1986-2017
z/OS Network Software Consultant (z NetView, z/OS Communications Server)
Contractor, Checks & Balances, Inc.
Email: marktre...@gmail.com
LinkedIn:  https://www.linkedin.com/in/mark-t-regan




On Sun, Jan 16, 2022 at 8:18 AM Mike Shorkend 
wrote:

> Hi,
> I am trying to set up email notification for job termination but have run
> into a problem that the JES2EDS started task  can't connect to z/OSMF. This
> is the joblog(I have had to obfuscate the URI  and NODE)
>
>
>   J E S 2  J O B  L O G  --  S Y S T E M  S Y S D  --  N O
> D E  N O D E 1
>
>
> 1.25.31 S0452379  SUNDAY,16 JAN 2022 
>
> 1.25.31 S0452379  IEF196I IGD103I SMS ALLOCATED TO DDNAME SYS1
>
> 1.25.31 S0452379  IEF196I IGD104I SYS3.TCPIP.TCPPARMS
>RETAINED,
> 1.25.31 S0452379  IEF196I DDNAME=SYS1
>
> 1.25.31 S0452379  IEF196I IGD103I SMS ALLOCATED TO DDNAME SYS5
>
> 1.25.31 S0452379  IEF196I IGD104I SYS3.TCPIP.TCPPARMS
>RETAINED,
> 1.25.31 S0452379  IEF196I DDNAME=SYS5
>
> 1.25.31 S0452379  IEF196I IGD103I SMS ALLOCATED TO DDNAME SYS7
>
> 1.25.31 S0452379  IEF196I IGD104I SYS3.PLX2.TCPIP.STANDARD.TCPXLBIN
>RETAINED,
> 1.25.31 S0452379  IEF196I DDNAME=SYS7
>
> 1.25.31 S0452379  IEF196I IGD103I SMS UNIX FILE ALLOCATED TO DDNAME
> SYS00011
> 1.25.31 S0452379  IEF196I IGD104I UNIX FILE WAS RETAINED, DDNAME IS
> (SYS00011)
> 1.25.31 S0452379  IEF196I FILENAME IS (/etc/hosts)
>
> 1.25.32 S0452379  $HASP1529 106 0420 Socket closed by remote partner
>
> 1.25.32 S0452379  $HASP1534 z/OSMF server URI
> https://host.domain.co.il:1443/zosmf
> 1.25.32 S0452379  $HASP1535 Current message is in email queue $EDSQ004 at
> offset 
>   918   in EMQT 0288FF01
>
> 1.25.32 S0452379 *$HASP1523 Unable to connect to z/OSMF server.
>
>
>
> If I plugin the URI to a browser, I connect to z/OMSF without a problem.
>
>
> $HASP1529   sends you to the HTTP toolkit where a 106 return code is:
>
> Meaning: A communication error has been detected. One or
> more of the following problems has occurred:
> • A failure in the communication with the web server
> • An error in an underlying sockets or SSL/TLS service call
> • An error in obtaining the necessary system resources to
> process the connect.
> Action: Check the diagArea for further diagnostic information.
> The toolkit uses many internal services, including sockets, SSL,
> and other calls when processing an HTTP API service call. If one
> of these internal services fails because of an error in
> communications with the targeted server or because of an
> internal environmental condition, the error is reported in the
> diagnostic area. This information can be useful to the
> application programmer but, in many cases, it is for the use of
> IBM Support. If one of these errors occurs, clean up the
> environment, check for possible communication configuration
> problems, and reissue the request
>
> Before opening a case with IBM, has anyone else run into this (and
> hopefully solved it)?
> z/OS 2.4  and I think that I have followed all the prereq tasks.
>
> Thanks
>
> Mike
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: TSO RECEIVE prompt for output temporary dataset

[Paul Gilmartin]

On Tue, 18 Jan 2022 13:59:13 +, Seymour J Metz wrote:

>In JCL, you can refer multiple times to the same temporary DSN; 
>
Mostly true, but when I refer multiple times in the same job step
I haveee needed to specify VOL.

>... allowing  in PARSE, DAIR and DYNALLOC would allow doing the 
> same thing dynamically. As it stands, you have to extract the DSN and volume 
> from the first allocation and use them in the remaining allocations.

-- gil

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

Re: TSO RECEIVE prompt for output temporary dataset

[Paul Gilmartin]

On Mon, 17 Jan 2022 10:42:00 -0600, Support, DUNNIT SYSTEMS LTD.  wrote:

>Thanks, Paul.
> 
You're welcome.  Did you find a solution?
I believe that if a temp data set is to be passed to another job step,
it must be allocated with JCL DD.

-- gil

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

Re: RFE for FTP server security documentation

[Lennie Dymoke-Bradshaw]

Maybe it is too new ☹.
Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B. Dyck
Sent: 18 January 2022 16:11
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RFE for FTP server security documentation

Tried to vote but was not authorized - even after logging in ☹


Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck

“Worry more about your character than your reputation. Character is what you 
are, reputation merely what others think you are.”   - - - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lennie Dymoke-Bradshaw
Sent: Tuesday, January 18, 2022 10:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RFE for FTP server security documentation

The URL has been mangled somewhere along the way. The REF number is 153764.
I think you will need an IBM Id to vote.
Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lennie Dymoke-Bradshaw
Sent: 18 January 2022 16:00
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RFE for FTP server security documentation

Greetings all,

 

I have raised an RFE requesting IBM clarify the situation regarding the use of 
UID(0) for the z/OS FTP server.

I ask if you would please vote for it.

 

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe
 _ID=153764

 



Lennie Dymoke-Bradshaw

https://rsclweb.com   


'Dance like no one is watching. Encrypt like everyone is.'

 


--
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: RFE for FTP server security documentation

[Farley, Peter x23353]

I get "Unauthorized access - You cannot access this page because you do not 
have the proper authority." even when I reconstitute the URL with that RFE 
number.

This is the URL I reconstituted:

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=153764

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lennie Dymoke-Bradshaw
Sent: Tuesday, January 18, 2022 11:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RFE for FTP server security documentation

The URL has been mangled somewhere along the way. The REF number is 153764.
I think you will need an IBM Id to vote.
Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lennie Dymoke-Bradshaw
Sent: 18 January 2022 16:00
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RFE for FTP server security documentation

Greetings all,

I have raised an RFE requesting IBM clarify the situation regarding the use of 
UID(0) for the z/OS FTP server.

I ask if you would please vote for it.

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=153764

Lennie Dymoke-Bradshaw
--

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: RFE for FTP server security documentation

[Lionel B. Dyck]

Tried to vote but was not authorized - even after logging in ☹


Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck

“Worry more about your character than your reputation. Character is what you 
are, reputation merely what others think you are.”   - - - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lennie Dymoke-Bradshaw
Sent: Tuesday, January 18, 2022 10:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RFE for FTP server security documentation

The URL has been mangled somewhere along the way. The REF number is 153764.
I think you will need an IBM Id to vote.
Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lennie Dymoke-Bradshaw
Sent: 18 January 2022 16:00
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RFE for FTP server security documentation

Greetings all,

 

I have raised an RFE requesting IBM clarify the situation regarding the use of 
UID(0) for the z/OS FTP server.

I ask if you would please vote for it.

 

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe
 _ID=153764

 



Lennie Dymoke-Bradshaw

https://rsclweb.com   


'Dance like no one is watching. Encrypt like everyone is.'

 


--
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: RFE for FTP server security documentation

[Lennie Dymoke-Bradshaw]

The URL has been mangled somewhere along the way. The REF number is 153764.
I think you will need an IBM Id to vote.
Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Lennie Dymoke-Bradshaw
Sent: 18 January 2022 16:00
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RFE for FTP server security documentation

Greetings all,

 

I have raised an RFE requesting IBM clarify the situation regarding the use
of UID(0) for the z/OS FTP server.

I ask if you would please vote for it.

 

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe
 _ID=153764

 



Lennie Dymoke-Bradshaw

https://rsclweb.com   


'Dance like no one is watching. Encrypt like everyone is.'

 


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

RFE for FTP server security documentation

[Lennie Dymoke-Bradshaw]

Greetings all,

 

I have raised an RFE requesting IBM clarify the situation regarding the use
of UID(0) for the z/OS FTP server.

I ask if you would please vote for it.

 

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe
 _ID=153764 

 



Lennie Dymoke-Bradshaw

https://rsclweb.com   


'Dance like no one is watching. Encrypt like everyone is.'

 


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

Re: More of LOG4J

[Itschak Mugzach]

True, but David claims it is...

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Tue, Jan 18, 2022 at 3:52 PM Seymour J Metz  wrote:

> > all RSU levels are the same
>
> No. The HOLDDATA change multiple times between levels.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Itschak Mugzach [0305158ad67d-dmarc-requ...@listserv.ua.edu]
> Sent: Tuesday, January 18, 2022 2:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: More of LOG4J
>
> Thanks David,
>
>
>1. Even if you are right about the version numbers, we still have 5
>different versions here.
>2. Your claim about the sub-version is interesting. So Z/OS 2.4, just
>fir example, all RSU levels are the same. I don't think so, and so do
> the
>NVD administrators. Read the range of the affected versions. it includes
>all three levels.
>3. I am sure your company does a great job with versioning.
>4. The major issue with open source is that there is no formal life
>cycle. Usually it is a vendor product that you need to completely
> upgrade
>instead of installing a PTF. See your offering such as BASH. It is
>downloaded and installed. no service exists. Do you expect the user to
>check every day if there is a new version?
>
> ITschak
>
> *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
> Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
> and IBM I **|  *
>
> *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
> *Skype**: ItschakMugzach **|* *Web**:
> http://secure-web.cisco.com/18jw22Iixgzti-EBXxg6vWn0F3OY5r5Gp8oO1oKVHF5_kUxYP1KB7fHFTQdXVgRIeqX1IuucbHKPxPh8qqPDIldAePAQO89Ts1FThaNo1aodm8nKlD6m8R4wK0QI6pUXAo4hOsFR815-StTt-LTTZ735ZXz_RuNKLZtfxB8QQkfnB-8g344vQzERl9qrJDSQsY90UFWKSPDnUa226Pjj1nnz32kG9-AvqTg5hQItx21pE7AUvWL1XppaTzIHS9tR0O6BXhjnPGf1R1fEJPuF7Zn1dSfoGN-qoYaUD4DCjy5bsttJT1aN9gLyUg-EhqewCDPIxtOMDjzIUmfVNpBNZjQPOCKAd5d6y42XB8tpi8FC9MAnBdaY_t315WjDsQtj7B_IBDRX60triI3xvhNq1cPstw0g1DWw2pgFBvmqIx0Or1TEUc7xrwv9zv-x0dPXR/http%3A%2F%2Fwww.Securiteam.co.il
> **|*
>
>
>
>
>
> On Tue, Jan 18, 2022 at 4:52 AM David Crayford 
> wrote:
>
> > On 17/1/22 10:34 pm, ITschak Mugzach wrote:
> > > Hi,
> > >
> > > We took the time to dive into the wider issue of open source and z/os.
> > USS
> > > is a scary jungle!
> >
> > Only to the ignorant.
> >
> >
> > >
> > > Without many details on the how, we discovered that on our z/os 2.3
> there
> > > are 19 (!) different versions of Apache Ant: 1.5.3, 1.6.2, 1.6.5,
> 1.7.0,
> > > 1.7.1, 1.8.0, 1.8.1, 1.8.2, 1.8.2, 1.8.2, 1.8.3 ,1.8.4, 1.9.0, 1.9.2,
> > 1.9.3
> > > ,1.9.4, 1.9.6 ,1.9.7, 1.9.8 used by 1000 plus jar files and sharing 4
> > CVEs.
> >
> > I take it you don't understand the concept of semantic versioning. Those
> > are not all different versions, the last digit is the patch. We do this
> > in our (mainframe) products too.
> > In fact, we go further and add the Git commit hash to the version
> > message so we can track the version the customer is running down to a
> > line of code.
> >
> > Apache Ant is a build system and not part of a runtime. I don't share
> > your concerns.
> >
> >
> > >
> > > Nice divers... and as others may say "What you don't know doesn't hurt
> > you".
> > >
> > > ITschak
> > >
> > > 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
> >
> > --
> > 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: JES2 mail notification

[Carmen Vitullo]

I totally agree, I never ever recall having an open ticket with IBM on 
an issue and working with support for over a year on the setup and 
configuration, even providing all the log and trace data, and still over 
a year working an issue.


messaging is foreign, to me anyway, multiple places to look for errors.

my site only uses z/OSMF currently to setup the policy agent for TCPIP, 
and JES2 Email Delivery, I am thankful I SHOULD be retired before I have 
to think about 2.5


Carmen

On 1/18/2022 8:19 AM, Mike Shaw wrote:

All of the REST APIs and external security controls z/OSMF
supports/requires and the need to (eventually) make z/OSMF "easy to use by
an early tenure systems programmer"  have made the beast ponderous. It may
be easy to use at some point in the future but it's sure NOT easy to
install or configure now...

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.


On Tue, Jan 18, 2022 at 12:22 AM Brian Westerman <
brian_wester...@syzygyinc.com> wrote:


I hate for this to sound like a marketing email, but the difficulty of
using Jesmail via z/OSMF and several other Jes to email products is (one of
the) reason(s) we developed SyzMail/z.  There is zero changes needed to the
system and the install is complete in 5 minutes.  No changes to any JCL or
exits are necessary.

I have noticed that lately a lot of extra work is being generated by
trying to do something very simple with extremely sophisticated software.

Brian

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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: JES2 mail notification

[Mike Shaw]

All of the REST APIs and external security controls z/OSMF
supports/requires and the need to (eventually) make z/OSMF "easy to use by
an early tenure systems programmer"  have made the beast ponderous. It may
be easy to use at some point in the future but it's sure NOT easy to
install or configure now...

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.


On Tue, Jan 18, 2022 at 12:22 AM Brian Westerman <
brian_wester...@syzygyinc.com> wrote:

> I hate for this to sound like a marketing email, but the difficulty of
> using Jesmail via z/OSMF and several other Jes to email products is (one of
> the) reason(s) we developed SyzMail/z.  There is zero changes needed to the
> system and the install is complete in 5 minutes.  No changes to any JCL or
> exits are necessary.
>
> I have noticed that lately a lot of extra work is being generated by
> trying to do something very simple with extremely sophisticated software.
>
> Brian
>
> --
> 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: TSO RECEIVE prompt for output temporary dataset

[Seymour J Metz]

Did the fix only hit PARSE, or was the syntax also supported in DAIR and 
DYNALLOC? I don't see much utility in being able to parse a temporary DSN if I 
can't use it for a dynamic allocation.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Harminc [t...@harminc.net]
Sent: Monday, January 17, 2022 7:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO RECEIVE prompt for output temporary dataset

On Mon, 17 Jan 2022 at 11:08, Seymour J Metz  wrote:
>
> The ampersand for temporary dataset names is a JCL convention, not a TSO 
> convention.

Back in the late 1970s or maybe early 1980s there was a short-lived
APAR "fix" that added support for using the ampersand to specify
temporary datasets in IKJPARS. It was quickly withdrawn - I speculate
because someone with the necessary design sense could see that there
would be a near endless series of followon fixes to make everything
work.

Maybe one of our IBMers here could dig up that APAR or even comment on
what happened.

Tony H.

--
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: TSO RECEIVE prompt for output temporary dataset

[Seymour J Metz]

In JCL, you can refer multiple times to the same temporary DSN; allowing 
 in PARSE, DAIR and DYNALLOC would allow doing the same thing 
dynamically. As it stands, you have to extract the DSN and volume from the 
first allocation and use them in the remaining allocations.


--
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: Monday, January 17, 2022 8:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO RECEIVE prompt for output temporary dataset

On Mon, 17 Jan 2022 19:41:34 -0500, Tony Harminc wrote:

>On Mon, 17 Jan 2022 at 11:08, Seymour J Metz wrote:
>>
>> The ampersand for temporary dataset names is a JCL convention, not a TSO 
>> convention.
>
>Back in the late 1970s or maybe early 1980s there was a short-lived
>APAR "fix" that added support for using the ampersand to specify
>temporary datasets in IKJPARS.
>
There's no need  for that.  One can create a temp data set simply by
omitting specification of DSNAME.

>... It was quickly withdrawn - I speculate
>because someone with the necessary design sense could see that there
>would be a near endless series of followon fixes to make everything
>work.
>
The challenge lies in creating dynamically the control blocks that the
converter would have creating statically; PASS; referback; ENQ; ...
What were they thinking?!  Maybe in JES 5.

But I want a way to rename/alias a DDNAME, scope within a step.

>Maybe one of our IBMers here could dig up that APAR or even comment on
>what happened.

-- 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: More of LOG4J

[Seymour J Metz]

> all RSU levels are the same

No. The HOLDDATA change multiple times between levels.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Itschak Mugzach [0305158ad67d-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, January 18, 2022 2:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: More of LOG4J

Thanks David,


   1. Even if you are right about the version numbers, we still have 5
   different versions here.
   2. Your claim about the sub-version is interesting. So Z/OS 2.4, just
   fir example, all RSU levels are the same. I don't think so, and so do the
   NVD administrators. Read the range of the affected versions. it includes
   all three levels.
   3. I am sure your company does a great job with versioning.
   4. The major issue with open source is that there is no formal life
   cycle. Usually it is a vendor product that you need to completely upgrade
   instead of installing a PTF. See your offering such as BASH. It is
   downloaded and installed. no service exists. Do you expect the user to
   check every day if there is a new version?

ITschak

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: 
http://secure-web.cisco.com/18jw22Iixgzti-EBXxg6vWn0F3OY5r5Gp8oO1oKVHF5_kUxYP1KB7fHFTQdXVgRIeqX1IuucbHKPxPh8qqPDIldAePAQO89Ts1FThaNo1aodm8nKlD6m8R4wK0QI6pUXAo4hOsFR815-StTt-LTTZ735ZXz_RuNKLZtfxB8QQkfnB-8g344vQzERl9qrJDSQsY90UFWKSPDnUa226Pjj1nnz32kG9-AvqTg5hQItx21pE7AUvWL1XppaTzIHS9tR0O6BXhjnPGf1R1fEJPuF7Zn1dSfoGN-qoYaUD4DCjy5bsttJT1aN9gLyUg-EhqewCDPIxtOMDjzIUmfVNpBNZjQPOCKAd5d6y42XB8tpi8FC9MAnBdaY_t315WjDsQtj7B_IBDRX60triI3xvhNq1cPstw0g1DWw2pgFBvmqIx0Or1TEUc7xrwv9zv-x0dPXR/http%3A%2F%2Fwww.Securiteam.co.il
  **|*





On Tue, Jan 18, 2022 at 4:52 AM David Crayford  wrote:

> On 17/1/22 10:34 pm, ITschak Mugzach wrote:
> > Hi,
> >
> > We took the time to dive into the wider issue of open source and z/os.
> USS
> > is a scary jungle!
>
> Only to the ignorant.
>
>
> >
> > Without many details on the how, we discovered that on our z/os 2.3 there
> > are 19 (!) different versions of Apache Ant: 1.5.3, 1.6.2, 1.6.5, 1.7.0,
> > 1.7.1, 1.8.0, 1.8.1, 1.8.2, 1.8.2, 1.8.2, 1.8.3 ,1.8.4, 1.9.0, 1.9.2,
> 1.9.3
> > ,1.9.4, 1.9.6 ,1.9.7, 1.9.8 used by 1000 plus jar files and sharing 4
> CVEs.
>
> I take it you don't understand the concept of semantic versioning. Those
> are not all different versions, the last digit is the patch. We do this
> in our (mainframe) products too.
> In fact, we go further and add the Git commit hash to the version
> message so we can track the version the customer is running down to a
> line of code.
>
> Apache Ant is a build system and not part of a runtime. I don't share
> your concerns.
>
>
> >
> > Nice divers... and as others may say "What you don't know doesn't hurt
> you".
> >
> > ITschak
> >
> > 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
>
> --
> 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: JES2 mail notification

[Carmen Vitullo]

SMTP :) not SNMP

Carmen

On 1/18/2022 7:17 AM, Carmen Vitullo wrote:
our biggest problem was getting the CERTs in place, and translating 
RACF to Top-Secret, I spent almost a year working with support and our 
security team running tracesetc, here to find out the setup on 
z/OSMF to connect to a mail server by default was looking to 
authenticate the snmp mail user in the setup, out smtp server did not 
require a password so a special jar file was created to bypass auth 
checking, another issue I had was the CERT was connected to USER JES2, 
but for some reason, JESEDS was assigned a user of JES2EDS, that 
needed to be fixed, I'm nto sure why the ID was being changed, and 
still to this day I know if JES2 email is not working I need to stop 
and restart JES2EDS :(


Carmen

On 1/17/2022 5:50 AM, Roger Lowe wrote:
On Sun, 16 Jan 2022 15:17:40 +0200, Mike 
Shorkend  wrote:



Hi,
I am trying to set up email notification for job termination but 
have run
into a problem that the JES2EDS started task  can't connect to 
z/OSMF. This

is the joblog(I have had to obfuscate the URI  and NODE)


Mike,
 Here are a few things to check out:
1. Has zOSMF been setup to be "autostart"?
2. Have you seen Chapter 8 of the JES2 Init and Tuning Guide - "JES2 
Email Delivery Services"?

3. Certificates in your relevant ESM been setup?
4. Has the userid you assigned for JES2EDS address space been added 
to zOSMF as a valid user?
5. Has the userid assigned to JES2EDS address space been given the 
necessary security access to to use z/OSMF email (notification) 
services?

6. Have you defined the SMTP Server to the zOSMF configuration?

A lot of this is discussed in details in the Chapter 8 of the JES2 
Init and Tuning Guide.


Hope the above helps

Roger

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: JES2 mail notification

[Carmen Vitullo]

our biggest problem was getting the CERTs in place, and translating RACF 
to Top-Secret, I spent almost a year working with support and our 
security team running tracesetc, here to find out the setup on 
z/OSMF to connect to a mail server by default was looking to 
authenticate the snmp mail user in the setup, out smtp server did not 
require a password so a special jar file was created to bypass auth 
checking, another issue I had was the CERT was connected to USER JES2, 
but for some reason, JESEDS was assigned a user of JES2EDS, that needed 
to be fixed, I'm nto sure why the ID was being changed, and still to 
this day I know if JES2 email is not working I need to stop and restart 
JES2EDS :(


Carmen

On 1/17/2022 5:50 AM, Roger Lowe wrote:

On Sun, 16 Jan 2022 15:17:40 +0200, Mike Shorkend  
wrote:


Hi,
I am trying to set up email notification for job termination but have run
into a problem that the JES2EDS started task  can't connect to z/OSMF. This
is the joblog(I have had to obfuscate the URI  and NODE)


Mike,
 Here are a few things to check out:
1. Has zOSMF been setup to be "autostart"?
2. Have you seen Chapter 8 of the JES2 Init and Tuning Guide - "JES2 Email Delivery 
Services"?
3. Certificates in your relevant ESM been setup?
4. Has the userid you assigned for JES2EDS address space been added to zOSMF as 
a valid user?
5. Has the userid assigned to JES2EDS address space been given the necessary 
security access to to use z/OSMF email (notification) services?
6. Have you defined the SMTP Server to the zOSMF configuration?

A lot of this is discussed in details in the Chapter 8 of the JES2 Init and 
Tuning Guide.

Hope the above helps

Roger

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: JES2 mail notification

[Steve Smith]

When I looked at setting up JES2 email notifications, I couldn't believe
the enormous complexity, and wonder why on earth z/OSMF needs to be
involved.  Seems to me they could have just dropped these off to CSMTP.

Anyway, great that someone saw the opportunity, and took it!

sas


On Tue, Jan 18, 2022 at 12:23 AM Brian Westerman <
brian_wester...@syzygyinc.com> wrote:

> I hate for this to sound like a marketing email, but the difficulty of
> using Jesmail via z/OSMF and several other Jes to email products is (one of
> the) reason(s) we developed SyzMail/z.  There is zero changes needed to the
> system and the install is complete in 5 minutes.  No changes to any JCL or
> exits are necessary.
>
> I have noticed that lately a lot of extra work is being generated by
> trying to do something very simple with extremely sophisticated software.
>
> Brian
>
>

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

Re: Sysplex Command Routing

[Carmen Vitullo]

HI Ray, I'm not sure, and late to the game here, rather than limit this 
with a sysplex scope at another site we limit what users can issue 
commands on what systems, I do not know the details, I was not involved 
in the management of the profiles, but this was done with RACF, so a 
user can route *ALL, but the command would only be issued or valid on 
the systems he/she had authority.



Carmen

On 1/17/2022 10:19 AM, Ray Kilgore wrote:

Does anyone know of how you can limit the scope of where an operator can route 
commands to within a sysplex. Lets say I only want a users TSO logon to only be 
able to route commands to 3 out of 6 systems within a sysplex. Operator JOHNDOE 
can only route z/OS commands to SYS1, SYS2 and SYS3.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: More of LOG4J

[Itschak Mugzach]

Blessed are the innocent

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Tue, Jan 18, 2022 at 2:25 PM Raphaël Jacquot  wrote:

> Le 18/01/2022 à 09:09, Itschak Mugzach a écrit :
> > Raphael,
> >
> > That's exactly my point. How do you maintain the life cycle of open
> source?
>
> each project publishes updates, according to either
> * fixed calendar
> * feature based calendar
> * vulnerability fixes
>
> > How can you explain that so many vendor products include old open source
> > versions?
>
> You have multiple ways of handling things:
>
> * Those that use a set version of each library they use, includes
>
>* Publishing software as a docker image
>
>  this is possibly the less evil way of doing things, as long as
>  the vendor actually updates the docker image regularly, whenever
>  a vulnerability is found
>
>* Fork a local copy of each library they use
>
>  those need extra work when vulnerability fixes are announced.
>
>  this way of doing things leads to having a number of versions of
>  the libraries in the system (gets confusing)
>  this also leads to old (vulnerable) versions being included.
>  said vendors should be bashed for doing things the wrong way.
>
> * those that use the libraries that are present in the system, whose
>code properly adapts to what is available on the machine at the time
>
>those allow for proper system upgrades, providing proper automatic
>systemwide vulnerability fixes.
>
> --
> 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: More of LOG4J

[Raphaël Jacquot]

Le 18/01/2022 à 09:09, Itschak Mugzach a écrit :

Raphael,

That's exactly my point. How do you maintain the life cycle of open source?


each project publishes updates, according to either
* fixed calendar
* feature based calendar
* vulnerability fixes


How can you explain that so many vendor products include old open source
versions?


You have multiple ways of handling things:

* Those that use a set version of each library they use, includes

  * Publishing software as a docker image

this is possibly the less evil way of doing things, as long as
the vendor actually updates the docker image regularly, whenever
a vulnerability is found

  * Fork a local copy of each library they use

those need extra work when vulnerability fixes are announced.

this way of doing things leads to having a number of versions of
the libraries in the system (gets confusing)
this also leads to old (vulnerable) versions being included.
said vendors should be bashed for doing things the wrong way.

* those that use the libraries that are present in the system, whose
  code properly adapts to what is available on the machine at the time

  those allow for proper system upgrades, providing proper automatic
  systemwide vulnerability fixes.

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

Re: More of LOG4J

[Itschak Mugzach]

Raphael,

That's exactly my point. How do you maintain the life cycle of open source?
How can you explain that so many vendor products include old open source
versions?

ITschak

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Tue, Jan 18, 2022 at 10:05 AM Raphaël Jacquot  wrote:

> Le 18/01/2022 à 08:28, Itschak Mugzach a écrit :
> > See your offering such as BASH. It is
> > downloaded and installed. no service exists. Do you expect the user
> to
> > check every day if there is a new version?
>
> no, that would be the job of the site administrator
>
> --
> 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: More of LOG4J

[Raphaël Jacquot]

Le 18/01/2022 à 08:28, Itschak Mugzach a écrit :

See your offering such as BASH. It is
downloaded and installed. no service exists. Do you expect the user to
check every day if there is a new version?


no, that would be the job of the site administrator

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