Re: cURL and security

[Luke Wilby]

We are using Rocket's cURL. Fully supported and everything.

The primary use case at the moment:

Stop and Start z/OS Connect APIs using the z/OS Connect REST interface, from a 
batch job with no password on the user account.

Eventually, we'll want to do similar stuff for other targets and using other 
clients not on z/OS (off the top of my head...Jenkins to zOSMF, python on Linux 
to DB2 REST, etc).



> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of kekronbekron
> Sent: Friday, July 24, 2020 15:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: cURL and security
> 
> Oh ok ... guess I didn't realize that WET is being provided primarily for
> 'backward compatibility'.
> Thanks for the clarification on the other bits.
> 
> > Using cURL or libcurl is not inherently dangerous. Any code that goes
> > into production should be peer reviewed. You can write bad code in any
> > language using any tool.
> 
> Again ... you've over-generalized a very specific scenario I said folks should
> be wary of.
> I didn't say curl or any other tool is dangerous, piping source-unknown 
> scripts
> to bash is!
> 
> - KB
> 
> ‐‐‐ Original Message ‐‐‐
> On Friday, July 24, 2020 10:15 AM, David Crayford 
> wrote:
> 
> > On 2020-07-24 12:02 PM, kekronbekron wrote:
> >
> > > > I wouldn't. I would recommend using a sophisticated networking
> > > > library like Java or whatever your favorite language is on the JVM.
> > > > Can't figure out if you're kidding...
> >
> > No, I'm not kidding! IMO, unless you have a critical requirement to
> > web enable legacy languages then I would avoid WET at all costs. A
> > quick browse of the samples is enough to conclude that while it may
> > work it is hideously complicated compared to similar function in
> > modern languages. So, why not just use a better language? I almost
> > died laughing when I saw how complicated it is to parse JSON in REXX
> > using the WET.
> >
> > > > Who told you that? My employer offers a cURL port for z/OS and
> > > > it's well maintained with support for production environment.
> > > > Ok, Rocket's curl?
> > > > What's the percentage of clients that want a separate product for
> something that also comes with (or at least used to?) the OS (Ported Tools).
> >
> > FYI, IBM sold ported tools to Rocket years ago. There is no cURL that
> > comes with z/OS.
> >
> > > Yes, everything I'm saying is subjective...
> > > Adoption would be much higher if Ported Tools' curl were actively
> developed.
> >
> > It is! And you can download it for free if you just want to write
> > in-house tooling. If you want to use cURL in production then you will
> > have to buy support.
> >
> > > Eh ... I didn't say curl-ing a script is dangerous and CWET isn't.
> > > I meant piping any source-unknown script direct for execution is not a
> great idea.
> >
> > Using cURL or libcurl is not inherently dangerous. Any code that goes
> > into production should be peer reviewed. You can write bad code in any
> > language using any tool.
> >
> > > -   KB
> > >
> > > ‐‐‐ Original Message ‐‐‐
> > > On Friday, July 24, 2020 8:53 AM, David Crayford dcrayf...@gmail.com
> wrote:
> > >
> > > > On 2020-07-24 11:12 AM, kekronbekron wrote:
> > > >
> > > > > Just mentioned ASM / COB CWET for options really.
> > > > > They're a a lot more involved than the Python client (when that's
> available).
> > > > > curl is ok as a user, but when you want to productionize something, I
> would think the recommendation would be to use CWET.
> > > > > I wouldn't. I would recommend using a sophisticated networking
> > > > > library like Java or whatever your favorite language is on the JVM.
> > > >
> > > > > Not saying curl is a bad tool, it is handy & does what it does.
> > > > > Ease of use does not mean it's the solution of choice in many
> controlled environments.
> > > > > By loved I mean does it get upgrades/improvements?
> > > > > Who told you that? My employer offers a cURL port for z/OS and
> > > > > it's well maintained with support for production environment.
> > > >
> > > > > I don't know I'm just asking..
> > > > > curl-ing a shell script directly is bit ... dangerous.
> > > > > That's purely subjective. I don't see why cURL would be any more
> > > > > dangerous than writing a Python script or using CWET.
> > > >
> > > > Lots of people are using Git for DevOps on z/OS and that uses cURL
> > > > for ssh and https transport.
> > > >
> > > > > Not in this case as the script is available to inspect.
> > > > > --
> > > >
> > > > 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: INF

Re: cURL and security

[Luke Wilby]

Thanks David.

Sadly, for us, it uses basic auth and the base64 encoded token is as good as a 
password. Our auditors would make life difficult.


> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of David Crayford
> Sent: Friday, July 24, 2020 13:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: cURL and security
> 
> Use tokens
> https://developer.atlassian.com/cloud/jira/platform/basic-auth-for-rest-
> apis/
> 
> On 2020-07-24 11:21 AM, Luke Wilby wrote:
> > Hey David
> >
> > Do you authenticate to Jira when using cURL? How?
> >
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> >> Behalf Of David Crayford
> >> Sent: Friday, July 24, 2020 12:29 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: cURL and security
> >>
> >> On 2020-07-23 2:17 PM, kekronbekron wrote:
> >>> It would be best to consider switching to the z/OS Client Web
> >>> Enablement
> >> Toolkit.
> >>> There are sample programs for REXX / ASM / COB .. and I'm positive
> >>> there'll
> >> be a Python client pretty soon (IBM Open Enterprise Python for z/OS).
> >>
> >> To me the idea of writing a web client in assembler is preposterous.
> >> COBOL is almost as bad and I would opt to use bpxwunix() with curl
> >> over the Web Enabelment Toolkit any day.
> >> I can create a Jira ticket with a couple of lines of curl. I would
> >> suggest writing a REXX script using the WET would be considerably more
> effort.
> >>
> >>> Don't think cURL is loved that much on Z.
> >> Are you speaking from experience? Not loved by who? Anybody who
> knows
> >> how to use z/OS UNIX shells knows how to use curl. I used curl only
> >> yesterday to install a shell utility from github with a simple one-liner.
> >>
> >> sh -c "$(curl -fsSL
> >> https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
> >>
> >>
> >>> Hmm .. unless client auth is required at the cURL target, you don't
> >>> need to
> >> worry about client certs, right?
> >>> Just plop on the target server's CA cert (interim & root CA) public
> >>> keys in a
> >> user keyring, and point CWET to the user keyring.
> >>> Server auth will work just fine.
> >>>
> >>> - KB
> >>>
> >>> ‐‐‐ Original Message ‐‐‐
> >>> On Thursday, July 23, 2020 10:20 AM, Filip Palian
> >>> 
> >> wrote:
>  Hey,
> 
>  You can read login credentials from within a script at run time
>  from a separate file containing password. This file should have an
>  adequate permissions and ownership set of course.
> 
>  Alternatively, if you control the target, perhaps you can whitelist
>  your curl/client.
> 
>  I hope that helps.
> 
>  Cheers,
>  F
> 
>  W dniu czwartek, 23 lipca 2020 Luke akal...@hotmail.com napisał(a):
> 
> > Hi All
> > I'm wondering if anyone is using cURL on z/OS in a production setting?
> > I'm interested how to utilise cURL when the target URL requires
> > authentication.
> > We can't use Basic Auth because we are not able to store usernames
> >> and
> > password in scripts or batch jobs.
> > We can't easily use certificates because our users on z/OS do not
> > have certificates and our Windows based corporate certificate
> > management
> >> doesn't
> > allow users access to the private keys of their Windows certificates.
> > Anyone else using cURL for DevOps on z/OS and how are you securing
> >> it?
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-
> >> MAIN
>  --
> 
>  For IBM-MAIN subscribe / signoff / archive access instructions,
>  send email to lists...@listserv.ua.edu with the message: INFO
>  IBM-MAIN
> >>> 
> >>> -- For IBM-MAIN subscribe / signoff / archive access instructions,
> >>> send email to lists...@listserv.ua.edu with the message: INFO
> >>> IBM-MAIN
> >> -
> >> - 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: cURL and security

[kekronbekron]

Oh ok ... guess I didn't realize that WET is being provided primarily for 
'backward compatibility'.
Thanks for the clarification on the other bits.

> Using cURL or libcurl is not inherently dangerous. Any code that goes
> into production should be peer reviewed. You can write bad code in any
> language using any tool.

Again ... you've over-generalized a very specific scenario I said folks should 
be wary of.
I didn't say curl or any other tool is dangerous, piping source-unknown scripts 
to bash is!

- KB

‐‐‐ Original Message ‐‐‐
On Friday, July 24, 2020 10:15 AM, David Crayford  wrote:

> On 2020-07-24 12:02 PM, kekronbekron wrote:
>
> > > I wouldn't. I would recommend using a sophisticated networking library
> > > like Java or whatever your favorite language is on the JVM.
> > > Can't figure out if you're kidding...
>
> No, I'm not kidding! IMO, unless you have a critical requirement to web
> enable legacy languages then I would avoid WET at all costs. A quick
> browse of the samples is enough to conclude that
> while it may work it is hideously complicated compared to similar
> function in modern languages. So, why not just use a better language? I
> almost died laughing when I saw how complicated it
> is to parse JSON in REXX using the WET.
>
> > > Who told you that? My employer offers a cURL port for z/OS and it's well
> > > maintained with support for production environment.
> > > Ok, Rocket's curl?
> > > What's the percentage of clients that want a separate product for 
> > > something that also comes with (or at least used to?) the OS (Ported 
> > > Tools).
>
> FYI, IBM sold ported tools to Rocket years ago. There is no cURL that
> comes with z/OS.
>
> > Yes, everything I'm saying is subjective...
> > Adoption would be much higher if Ported Tools' curl were actively developed.
>
> It is! And you can download it for free if you just want to write
> in-house tooling. If you want to use cURL in production then you will
> have to buy support.
>
> > Eh ... I didn't say curl-ing a script is dangerous and CWET isn't.
> > I meant piping any source-unknown script direct for execution is not a 
> > great idea.
>
> Using cURL or libcurl is not inherently dangerous. Any code that goes
> into production should be peer reviewed. You can write bad code in any
> language using any tool.
>
> > -   KB
> >
> > ‐‐‐ Original Message ‐‐‐
> > On Friday, July 24, 2020 8:53 AM, David Crayford dcrayf...@gmail.com wrote:
> >
> > > On 2020-07-24 11:12 AM, kekronbekron wrote:
> > >
> > > > Just mentioned ASM / COB CWET for options really.
> > > > They're a a lot more involved than the Python client (when that's 
> > > > available).
> > > > curl is ok as a user, but when you want to productionize something, I 
> > > > would think the recommendation would be to use CWET.
> > > > I wouldn't. I would recommend using a sophisticated networking library
> > > > like Java or whatever your favorite language is on the JVM.
> > >
> > > > Not saying curl is a bad tool, it is handy & does what it does.
> > > > Ease of use does not mean it's the solution of choice in many 
> > > > controlled environments.
> > > > By loved I mean does it get upgrades/improvements?
> > > > Who told you that? My employer offers a cURL port for z/OS and it's well
> > > > maintained with support for production environment.
> > >
> > > > I don't know I'm just asking..
> > > > curl-ing a shell script directly is bit ... dangerous.
> > > > That's purely subjective. I don't see why cURL would be any more
> > > > dangerous than writing a Python script or using CWET.
> > >
> > > Lots of people are using Git for DevOps on z/OS and that uses cURL for
> > > ssh and https transport.
> > >
> > > > Not in this case as the script is available to inspect.
> > > > --
> > >
> > > 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: cURL and security

[kekronbekron]

Ah sorry.. just realising that ID certs (& client auth) require private key lol.

I'm sure others will correct me if I'm wrong... afraid you've to use GENCERT, 
GENREQ and then get it signed by your off-mainframe PKI.
That way, private keys for ID certificates exist on mainframe... which isn't an 
unusual way of doing things.

Alternatively, I think PCOMM, HoD, etc. will have some support for working with 
external keystore for client auth.
https://www.ibm.com/support/knowledgecenter/SSEQ5Y_14.0.0/com.ibm.pcomm.doc/books/html/admin_guide11.htm#cfgssl
Check point #12 here.
"Send Personal Certificate Trusted by Server"
or
"Select or Prompt for Personal Client Certificate" may work.

For option 2,
PCOMM lists Personal certificates from the following location:
[certmgr.msc] ->[Current User->Personal -> Certificates]



- KB

‐‐‐ Original Message ‐‐‐
On Friday, July 24, 2020 8:49 AM, Luke Wilby  wrote:

> cURL requires the client's private key for mutual auth.
>
> I'm not familiar with CWET but I imagine the security considerations are the 
> same.
>
> My clients need to authenticate to the server. The server then needs to 
> perform authorization checks.
>
> It's the authentication part that we need to sort out.
>
> Our company's internal certificate management is done on Windows. Our Windows 
> clients have personal certificates, installed by our Windows team. They don't 
> have access to the private keys.
>
> Our z/OS clients don't have certificates and even if they did, they would 
> come from the Windows team and our clients wouldn't have access to the 
> private keys to issue the cURL call.
>
> > Just mentioned ASM / COB CWET for options really.
> > They're a a lot more involved than the Python client (when that's 
> > available).
> > curl is ok as a user, but when you want to productionize something, I would
> > think the recommendation would be to use CWET.
> > Not saying curl is a bad tool, it is handy & does what it does.
> > Ease of use does not mean it's the solution of choice in many controlled
> > environments.
> > By loved I mean does it get upgrades/improvements?
> > I don't know I'm just asking..
> > curl-ing a shell script directly is bit ... dangerous.
> > Not in this case as the script is available to inspect.
> >
> > -   KB
> >
> > ‐‐‐ Original Message ‐‐‐
> > On Friday, July 24, 2020 7:59 AM, David Crayford dcrayf...@gmail.com
> > wrote:
> >
> > > On 2020-07-23 2:17 PM, kekronbekron wrote:
> > >
> > > > It would be best to consider switching to the z/OS Client Web
> > > > Enablement Toolkit.
> > >
> > > > There are sample programs for REXX / ASM / COB .. and I'm positive
> > > > there'll be a Python client pretty soon (IBM Open Enterprise Python for
> > > > z/OS).
> > >
> > > To me the idea of writing a web client in assembler is preposterous.
> > > COBOL is almost as bad and I would opt to use bpxwunix() with curl
> > > over the Web Enabelment Toolkit any day.
> > > I can create a Jira ticket with a couple of lines of curl. I would
> > > suggest writing a REXX script using the WET would be considerably more
> > > effort.
> > >
> > > > Don't think cURL is loved that much on Z.
> > >
> > > Are you speaking from experience? Not loved by who? Anybody who
> > > knows
> > > how to use z/OS UNIX shells knows how to use curl. I used curl only
> > > yesterday to install a shell utility from github with a simple one-liner.
> > > sh -c "$(curl -fsSL
> > > https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
> > >
> > > > Hmm .. unless client auth is required at the cURL target, you don't need
> > > > to worry about client certs, right?
> > >
> > > > Just plop on the target server's CA cert (interim & root CA) public 
> > > > keys in a
> > > > user keyring, and point CWET to the user keyring.
> > >
> > > > Server auth will work just fine.
> > > >
> > > > -   KB
> > > >
> > > > ‐‐‐ Original Message ‐‐‐
> > > > On Thursday, July 23, 2020 10:20 AM, Filip Palian s3...@pjwstk.edu.pl
> > > > wrote:
> > >
> > > > > Hey,
> > > > > You can read login credentials from within a script at run time
> > > > > from a separate file containing password. This file should have an
> > > > > adequate permissions and ownership set of course.
> > > > > Alternatively, if you control the target, perhaps you can
> > > > > whitelist your curl/client.
> > > > > I hope that helps.
> > > > > Cheers,
> > > > > F
> > > > > W dniu czwartek, 23 lipca 2020 Luke akal...@hotmail.com napisał(a):
> > > > >
> > > > > > Hi All
> > > > > > I'm wondering if anyone is using cURL on z/OS in a production 
> > > > > > setting?
> > > > > > I'm interested how to utilise cURL when the target URL requires
> > > > > > authentication.
> > > > > > We can't use Basic Auth because we are not able to store
> > > > > > usernames and password in scripts or batch jobs.
> > > > > > We can't easily use certificates because our users on z/OS do
> > > > > > not have certificates and our Windows based corporate
> > > > > > certi

Re: cURL and security

[David Crayford]

On 2020-07-24 12:02 PM, kekronbekron wrote:

I wouldn't. I would recommend using a sophisticated networking library
like Java or whatever your favorite language is on the JVM.

Can't figure out if you're kidding...


No, I'm not kidding! IMO, unless you have a critical requirement to web 
enable legacy languages then I would avoid WET at all costs. A quick 
browse of the samples is enough to conclude that
while it may work it is hideously complicated compared to similar 
function in modern languages. So, why not just use a better language? I 
almost died laughing when I saw how complicated it

is to parse JSON in REXX using the WET.




Who told you that? My employer offers a cURL port for z/OS and it's well
maintained with support for production environment.

Ok, Rocket's curl?
What's the percentage of clients that want a separate product for something 
that also comes with (or at least used to?) the OS (Ported Tools).


FYI, IBM sold ported tools to Rocket years ago. There is no cURL that 
comes with z/OS.




Yes, everything I'm saying is subjective...
Adoption would be much higher if Ported Tools' curl were actively developed.


It is! And you can download it for free if you just want to write 
in-house tooling. If you want to use cURL in production then you will 
have to buy support.




Eh ... I didn't say curl-ing a script is dangerous and CWET isn't.
I meant piping any source-unknown script direct for execution is not a great 
idea.


Using cURL or libcurl is not inherently dangerous. Any code that goes 
into production should be peer reviewed. You can write bad code in any 
language using any tool.





- KB

‐‐‐ Original Message ‐‐‐
On Friday, July 24, 2020 8:53 AM, David Crayford  wrote:


On 2020-07-24 11:12 AM, kekronbekron wrote:


Just mentioned ASM / COB CWET for options really.
They're a a lot more involved than the Python client (when that's available).
curl is ok as a user, but when you want to productionize something, I would 
think the recommendation would be to use CWET.

I wouldn't. I would recommend using a sophisticated networking library
like Java or whatever your favorite language is on the JVM.


Not saying curl is a bad tool, it is handy & does what it does.
Ease of use does not mean it's the solution of choice in many controlled 
environments.
By loved I mean does it get upgrades/improvements?

Who told you that? My employer offers a cURL port for z/OS and it's well
maintained with support for production environment.


I don't know I'm just asking..
curl-ing a shell script directly is bit ... dangerous.

That's purely subjective. I don't see why cURL would be any more
dangerous than writing a Python script or using CWET.

Lots of people are using Git for DevOps on z/OS and that uses cURL for
ssh and https transport.


Not in this case as the script is available to inspect.

--

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: [OT] OOBOL and English was Re: Still COBOL After All These Years?

[Tom Brennan]

Worth watching, thanks!  Usually I'd rather read than listen, but this 
guy really moves along.  That's about half an hour of info packed into 
12 minutes.


On 7/23/2020 6:17 PM, Tony Thigpen wrote:
I know this has just about run it's course, but I came across this 
interesting youtube video about "why the US did not adopt the metric 
system" by a legitimate historian.


https://youtu.be/yseldOMcT4Q

Tony Thigpen



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

Re: cURL and security

[kekronbekron]

> I wouldn't. I would recommend using a sophisticated networking library
> like Java or whatever your favorite language is on the JVM.

Can't figure out if you're kidding...

> Who told you that? My employer offers a cURL port for z/OS and it's well
> maintained with support for production environment.

Ok, Rocket's curl?
What's the percentage of clients that want a separate product for something 
that also comes with (or at least used to?) the OS (Ported Tools).
Yes, everything I'm saying is subjective...
Adoption would be much higher if Ported Tools' curl were actively developed.

Eh ... I didn't say curl-ing a script is dangerous and CWET isn't.
I meant piping any source-unknown script direct for execution is not a great 
idea.

- KB

‐‐‐ Original Message ‐‐‐
On Friday, July 24, 2020 8:53 AM, David Crayford  wrote:

> On 2020-07-24 11:12 AM, kekronbekron wrote:
>
> > Just mentioned ASM / COB CWET for options really.
> > They're a a lot more involved than the Python client (when that's 
> > available).
> > curl is ok as a user, but when you want to productionize something, I would 
> > think the recommendation would be to use CWET.
>
> I wouldn't. I would recommend using a sophisticated networking library
> like Java or whatever your favorite language is on the JVM.
>
> > Not saying curl is a bad tool, it is handy & does what it does.
> > Ease of use does not mean it's the solution of choice in many controlled 
> > environments.
> > By loved I mean does it get upgrades/improvements?
>
> Who told you that? My employer offers a cURL port for z/OS and it's well
> maintained with support for production environment.
>
> > I don't know I'm just asking..
> > curl-ing a shell script directly is bit ... dangerous.
>
> That's purely subjective. I don't see why cURL would be any more
> dangerous than writing a Python script or using CWET.
>
> Lots of people are using Git for DevOps on z/OS and that uses cURL for
> ssh and https transport.
>
> > Not in this case as the script is available to inspect.
>
> --
>
> 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: cURL and security

[David Crayford]

Use tokens 
https://developer.atlassian.com/cloud/jira/platform/basic-auth-for-rest-apis/


On 2020-07-24 11:21 AM, Luke Wilby wrote:

Hey David

Do you authenticate to Jira when using cURL? How?


-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of David Crayford
Sent: Friday, July 24, 2020 12:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: cURL and security

On 2020-07-23 2:17 PM, kekronbekron wrote:

It would be best to consider switching to the z/OS Client Web Enablement

Toolkit.

There are sample programs for REXX / ASM / COB .. and I'm positive there'll

be a Python client pretty soon (IBM Open Enterprise Python for z/OS).

To me the idea of writing a web client in assembler is preposterous.
COBOL is almost as bad and I would opt to use bpxwunix() with curl over the
Web Enabelment Toolkit any day.
I can create a Jira ticket with a couple of lines of curl. I would suggest 
writing a
REXX script using the WET would be considerably more effort.


Don't think cURL is loved that much on Z.

Are you speaking from experience? Not loved by who? Anybody who knows
how to use z/OS UNIX shells knows how to use curl. I used curl only
yesterday to install a shell utility from github with a simple one-liner.

sh -c "$(curl -fsSL
https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"



Hmm .. unless client auth is required at the cURL target, you don't need to

worry about client certs, right?

Just plop on the target server's CA cert (interim & root CA) public keys in a

user keyring, and point CWET to the user keyring.

Server auth will work just fine.

- KB

‐‐‐ Original Message ‐‐‐
On Thursday, July 23, 2020 10:20 AM, Filip Palian 

wrote:

Hey,

You can read login credentials from within a script at run time from a
separate file containing password. This file should have an adequate
permissions and ownership set of course.

Alternatively, if you control the target, perhaps you can whitelist your
curl/client.

I hope that helps.

Cheers,
F

W dniu czwartek, 23 lipca 2020 Luke akal...@hotmail.com napisał(a):


Hi All
I'm wondering if anyone is using cURL on z/OS in a production setting?
I'm interested how to utilise cURL when the target URL requires
authentication.
We can't use Basic Auth because we are not able to store usernames

and

password in scripts or batch jobs.
We can't easily use certificates because our users on z/OS do not have
certificates and our Windows based corporate certificate management

doesn't

allow users access to the private keys of their Windows certificates.
Anyone else using cURL for DevOps on z/OS and how are you securing

it?

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

MAIN

--

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

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

--
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: cURL and security

[David Crayford]

On 2020-07-24 11:12 AM, kekronbekron wrote:

Just mentioned ASM / COB CWET for options really.
They're a a lot more involved than the Python client (when that's available).

curl is ok as a user, but when you want to productionize something, I would 
think the recommendation would be to use CWET.


I wouldn't. I would recommend using a sophisticated networking library 
like Java or whatever your favorite language is on the JVM.





Not saying curl is a bad tool, it is handy & does what it does.
Ease of use does not mean it's the solution of choice in many controlled 
environments.
By loved I mean does it get upgrades/improvements?


Who told you that? My employer offers a cURL port for z/OS and it's well 
maintained with support for production environment.




I don't know I'm just asking..

curl-ing a shell script directly is bit ... dangerous.


That's purely subjective. I don't see why cURL would be any more 
dangerous than writing a Python script or using CWET.


Lots of people are using Git for DevOps on z/OS and that uses cURL for 
ssh and https transport.




Not in this case as the script is available to inspect.


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

Re: cURL and security

[Luke Wilby]

Hey David

Do you authenticate to Jira when using cURL? How?

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of David Crayford
> Sent: Friday, July 24, 2020 12:29 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: cURL and security
> 
> On 2020-07-23 2:17 PM, kekronbekron wrote:
> > It would be best to consider switching to the z/OS Client Web Enablement
> Toolkit.
> > There are sample programs for REXX / ASM / COB .. and I'm positive there'll
> be a Python client pretty soon (IBM Open Enterprise Python for z/OS).
> 
> To me the idea of writing a web client in assembler is preposterous.
> COBOL is almost as bad and I would opt to use bpxwunix() with curl over the
> Web Enabelment Toolkit any day.
> I can create a Jira ticket with a couple of lines of curl. I would suggest 
> writing a
> REXX script using the WET would be considerably more effort.
> 
> > Don't think cURL is loved that much on Z.
> 
> Are you speaking from experience? Not loved by who? Anybody who knows
> how to use z/OS UNIX shells knows how to use curl. I used curl only
> yesterday to install a shell utility from github with a simple one-liner.
> 
> sh -c "$(curl -fsSL
> https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
> 
> 
> >
> > Hmm .. unless client auth is required at the cURL target, you don't need to
> worry about client certs, right?
> > Just plop on the target server's CA cert (interim & root CA) public keys in 
> > a
> user keyring, and point CWET to the user keyring.
> > Server auth will work just fine.
> >
> > - KB
> >
> > ‐‐‐ Original Message ‐‐‐
> > On Thursday, July 23, 2020 10:20 AM, Filip Palian 
> wrote:
> >
> >> Hey,
> >>
> >> You can read login credentials from within a script at run time from a
> >> separate file containing password. This file should have an adequate
> >> permissions and ownership set of course.
> >>
> >> Alternatively, if you control the target, perhaps you can whitelist your
> >> curl/client.
> >>
> >> I hope that helps.
> >>
> >> Cheers,
> >> F
> >>
> >> W dniu czwartek, 23 lipca 2020 Luke akal...@hotmail.com napisał(a):
> >>
> >>> Hi All
> >>> I'm wondering if anyone is using cURL on z/OS in a production setting?
> >>> I'm interested how to utilise cURL when the target URL requires
> >>> authentication.
> >>> We can't use Basic Auth because we are not able to store usernames
> and
> >>> password in scripts or batch jobs.
> >>> We can't easily use certificates because our users on z/OS do not have
> >>> certificates and our Windows based corporate certificate management
> doesn't
> >>> allow users access to the private keys of their Windows certificates.
> >>> Anyone else using cURL for DevOps on z/OS and how are you securing
> it?
> >>>
> >>> For IBM-MAIN subscribe / signoff / archive access instructions,
> >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-
> MAIN
> >> --
> >>
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> 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: cURL and security

[Luke Wilby]

cURL requires the client's private key for mutual auth.

I'm not familiar with CWET but I imagine the security considerations are the 
same.

My clients need to authenticate to the server. The server then needs to perform 
authorization checks.

It's the authentication part that we need to sort out.

Our company's internal certificate management is done on Windows. Our Windows 
clients have personal certificates, installed by our Windows team. They don't 
have access to the private keys.

Our z/OS clients don't have certificates and even if they did, they would come 
from the Windows team and our clients wouldn't have access to the private keys 
to issue the cURL call.




> Just mentioned ASM / COB CWET for options really.
> They're a a lot more involved than the Python client (when that's available).
> 
> curl is ok as a user, but when you want to productionize something, I would
> think the recommendation would be to use CWET.
> 
> Not saying curl is a bad tool, it is handy & does what it does.
> Ease of use does not mean it's the solution of choice in many controlled
> environments.
> By loved I mean does it get upgrades/improvements?
> I don't know I'm just asking..
> 
> curl-ing a shell script directly is bit ... dangerous.
> Not in this case as the script is available to inspect.
> 
>  - KB
> 
> ‐‐‐ Original Message ‐‐‐
> On Friday, July 24, 2020 7:59 AM, David Crayford 
> wrote:
> 
> > On 2020-07-23 2:17 PM, kekronbekron wrote:
> >
> > > It would be best to consider switching to the z/OS Client Web
> Enablement Toolkit.
> > > There are sample programs for REXX / ASM / COB .. and I'm positive
> there'll be a Python client pretty soon (IBM Open Enterprise Python for
> z/OS).
> >
> > To me the idea of writing a web client in assembler is preposterous.
> > COBOL is almost as bad and I would opt to use bpxwunix() with curl
> > over the Web Enabelment Toolkit any day.
> > I can create a Jira ticket with a couple of lines of curl. I would
> > suggest writing a REXX script using the WET would be considerably more
> > effort.
> >
> > > Don't think cURL is loved that much on Z.
> >
> > Are you speaking from experience? Not loved by who? Anybody who
> knows
> > how to use z/OS UNIX shells knows how to use curl. I used curl only
> > yesterday to install a shell utility from github with a simple one-liner.
> >
> > sh -c "$(curl -fsSL
> > https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
> >
> > > Hmm .. unless client auth is required at the cURL target, you don't need
> to worry about client certs, right?
> > > Just plop on the target server's CA cert (interim & root CA) public keys 
> > > in a
> user keyring, and point CWET to the user keyring.
> > > Server auth will work just fine.
> > >
> > > -   KB
> > >
> > > ‐‐‐ Original Message ‐‐‐
> > > On Thursday, July 23, 2020 10:20 AM, Filip Palian s3...@pjwstk.edu.pl
> wrote:
> > >
> > > > Hey,
> > > > You can read login credentials from within a script at run time
> > > > from a separate file containing password. This file should have an
> > > > adequate permissions and ownership set of course.
> > > > Alternatively, if you control the target, perhaps you can
> > > > whitelist your curl/client.
> > > > I hope that helps.
> > > > Cheers,
> > > > F
> > > > W dniu czwartek, 23 lipca 2020 Luke akal...@hotmail.com napisał(a):
> > > >
> > > > > Hi All
> > > > > I'm wondering if anyone is using cURL on z/OS in a production setting?
> > > > > I'm interested how to utilise cURL when the target URL requires
> > > > > authentication.
> > > > > We can't use Basic Auth because we are not able to store
> > > > > usernames and password in scripts or batch jobs.
> > > > > We can't easily use certificates because our users on z/OS do
> > > > > not have certificates and our Windows based corporate
> > > > > certificate management doesn't allow users access to the private keys
> of their Windows certificates.
> > > > > Anyone else using cURL for DevOps on z/OS and how are you securing
> it?
> > > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > > send email to lists...@listserv.ua.edu with the message: INFO
> > > > > IBM-MAIN
> > > > > --
> > > >
> > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > send email to lists...@listserv.ua.edu with the message: INFO
> > > > IBM-MAIN
> > >
> > > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> >
> > 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 / ar

Re: cURL and security

[kekronbekron]

Just mentioned ASM / COB CWET for options really.
They're a a lot more involved than the Python client (when that's available).

curl is ok as a user, but when you want to productionize something, I would 
think the recommendation would be to use CWET.

Not saying curl is a bad tool, it is handy & does what it does.
Ease of use does not mean it's the solution of choice in many controlled 
environments.
By loved I mean does it get upgrades/improvements?
I don't know I'm just asking..

curl-ing a shell script directly is bit ... dangerous.
Not in this case as the script is available to inspect.

 - KB

‐‐‐ Original Message ‐‐‐
On Friday, July 24, 2020 7:59 AM, David Crayford  wrote:

> On 2020-07-23 2:17 PM, kekronbekron wrote:
>
> > It would be best to consider switching to the z/OS Client Web Enablement 
> > Toolkit.
> > There are sample programs for REXX / ASM / COB .. and I'm positive there'll 
> > be a Python client pretty soon (IBM Open Enterprise Python for z/OS).
>
> To me the idea of writing a web client in assembler is preposterous.
> COBOL is almost as bad and I would opt to use bpxwunix() with curl over
> the Web Enabelment Toolkit any day.
> I can create a Jira ticket with a couple of lines of curl. I would
> suggest writing a REXX script using the WET would be considerably more
> effort.
>
> > Don't think cURL is loved that much on Z.
>
> Are you speaking from experience? Not loved by who? Anybody who knows
> how to use z/OS UNIX shells knows how to use curl. I used curl only
> yesterday to install a shell utility from github with a simple one-liner.
>
> sh -c "$(curl -fsSL
> https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
>
> > Hmm .. unless client auth is required at the cURL target, you don't need to 
> > worry about client certs, right?
> > Just plop on the target server's CA cert (interim & root CA) public keys in 
> > a user keyring, and point CWET to the user keyring.
> > Server auth will work just fine.
> >
> > -   KB
> >
> > ‐‐‐ Original Message ‐‐‐
> > On Thursday, July 23, 2020 10:20 AM, Filip Palian s3...@pjwstk.edu.pl wrote:
> >
> > > Hey,
> > > You can read login credentials from within a script at run time from a
> > > separate file containing password. This file should have an adequate
> > > permissions and ownership set of course.
> > > Alternatively, if you control the target, perhaps you can whitelist your
> > > curl/client.
> > > I hope that helps.
> > > Cheers,
> > > F
> > > W dniu czwartek, 23 lipca 2020 Luke akal...@hotmail.com napisał(a):
> > >
> > > > Hi All
> > > > I'm wondering if anyone is using cURL on z/OS in a production setting?
> > > > I'm interested how to utilise cURL when the target URL requires
> > > > authentication.
> > > > We can't use Basic Auth because we are not able to store usernames and
> > > > password in scripts or batch jobs.
> > > > We can't easily use certificates because our users on z/OS do not have
> > > > certificates and our Windows based corporate certificate management 
> > > > doesn't
> > > > allow users access to the private keys of their Windows certificates.
> > > > Anyone else using cURL for DevOps on z/OS and how are you securing it?
> > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > > > --
> > >
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
>
> 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: cURL and security

[kekronbekron]

Hmm ... for client auth, isn't it just the public key of the client that has to 
be sent to the server?
And the server checks that against the client cert's CAs?
In which case, you only need a copy of the client pub key from Windows, and add 
it to a user keyring ... not the private key?

- KB

‐‐‐ Original Message ‐‐‐
On Friday, July 24, 2020 4:31 AM, Luke Wilby  wrote:

> I'm not sure use CWET will make any difference.
>
> The cURL targets require client authentication.
>
> The cURL targets live on z/OS (z/OS Connect, zOSMF, DB2, etc)
>
> The clients may be TSO users, batch jobs, Windows, Mac or Linux clients. The 
> batch jobs may run under userids that do not have passwords.
>
> We cannot store passwords anywhere. No scripts, no files.
>
> Our z/OS users generally don't have certificates or keyrings. Our servers do 
> (DB2, z/OS Connect, zOSMF, etc).
>
> Thanks
> Luke
>
> > It would be best to consider switching to the z/OS Client Web Enablement
> > Toolkit.
> > There are sample programs for REXX / ASM / COB .. and I'm positive there'll
> > be a Python client pretty soon (IBM Open Enterprise Python for z/OS).
> > Don't think cURL is loved that much on Z.
> > Hmm .. unless client auth is required at the cURL target, you don't need to
> > worry about client certs, right?
> > Just plop on the target server's CA cert (interim & root CA) public keys in 
> > a
> > user keyring, and point CWET to the user keyring.
> > Server auth will work just fine.
> >
> > -   KB
> >
> > ‐‐‐ Original Message ‐‐‐
> > On Thursday, July 23, 2020 10:20 AM, Filip Palian s3...@pjwstk.edu.pl
> > wrote:
> >
> > > Hey,
> > > You can read login credentials from within a script at run time from a
> > > separate file containing password. This file should have an adequate
> > > permissions and ownership set of course.
> > > Alternatively, if you control the target, perhaps you can whitelist
> > > your curl/client.
> > > I hope that helps.
> > > Cheers,
> > > F
> > > W dniu czwartek, 23 lipca 2020 Luke akal...@hotmail.com napisał(a):
> > >
> > > > Hi All
> > > > I'm wondering if anyone is using cURL on z/OS in a production setting?
> > > > I'm interested how to utilise cURL when the target URL requires
> > > > authentication.
> > > > We can't use Basic Auth because we are not able to store usernames
> > > > and password in scripts or batch jobs.
> > > > We can't easily use certificates because our users on z/OS do not
> > > > have certificates and our Windows based corporate certificate
> > > > management doesn't allow users access to the private keys of their
> > > > Windows certificates.
> > >
> > > > Anyone else using cURL for DevOps on z/OS and how are you securing it?
> > > > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions, send email 
> > to
> > lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
>
> 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: cURL and security

[David Crayford]

On 2020-07-23 2:17 PM, kekronbekron wrote:

It would be best to consider switching to the z/OS Client Web Enablement 
Toolkit.
There are sample programs for REXX / ASM / COB .. and I'm positive there'll be 
a Python client pretty soon (IBM Open Enterprise Python for z/OS).


To me the idea of writing a web client in assembler is preposterous. 
COBOL is almost as bad and I would opt to use bpxwunix() with curl over 
the Web Enabelment Toolkit any day.
I can create a Jira ticket with a couple of lines of curl. I would 
suggest writing a REXX script using the WET would be considerably more 
effort.



Don't think cURL is loved that much on Z.


Are you speaking from experience? Not loved by who? Anybody who knows 
how to use z/OS UNIX shells knows how to use curl. I used curl only 
yesterday to install a shell utility from github with a simple one-liner.


sh -c "$(curl -fsSL 
https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"





Hmm .. unless client auth is required at the cURL target, you don't need to 
worry about client certs, right?
Just plop on the target server's CA cert (interim & root CA) public keys in a 
user keyring, and point CWET to the user keyring.
Server auth will work just fine.

- KB

‐‐‐ Original Message ‐‐‐
On Thursday, July 23, 2020 10:20 AM, Filip Palian  wrote:


Hey,

You can read login credentials from within a script at run time from a
separate file containing password. This file should have an adequate
permissions and ownership set of course.

Alternatively, if you control the target, perhaps you can whitelist your
curl/client.

I hope that helps.

Cheers,
F

W dniu czwartek, 23 lipca 2020 Luke akal...@hotmail.com napisał(a):


Hi All
I'm wondering if anyone is using cURL on z/OS in a production setting?
I'm interested how to utilise cURL when the target URL requires
authentication.
We can't use Basic Auth because we are not able to store usernames and
password in scripts or batch jobs.
We can't easily use certificates because our users on z/OS do not have
certificates and our Windows based corporate certificate management doesn't
allow users access to the private keys of their Windows certificates.
Anyone else using cURL for DevOps on z/OS and how are you securing it?

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

--

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

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


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

Re: [OT] OOBOL and English was Re: Still COBOL After All These Years?

[Tony Thigpen]

I know this has just about run it's course, but I came across this 
interesting youtube video about "why the US did not adopt the metric 
system" by a legitimate historian.


https://youtu.be/yseldOMcT4Q

Tony Thigpen

Bob Bridges wrote on 7/23/20 10:13 AM:

I would be willing to follow such a convention, if there's a consensus for it, 
or possibly even if it's requested by only a few.  Personally I enjoy such 
discussions - obviously - but I can see not everyone would.

But what constitutes OT?  These things have recently started with a discussion 
of COBOL and mainframes, neither of which I would judge to be OT.  It's hard to 
be certain precisely where the thread crosses the line.  Opinions will differ, 
at least.

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

/* Why did the string bass player get angry at the timpanist?  A: Because the 
timpanist turned a peg and wouldn't tell him which one.  -from a collection of 
musician jokes */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of kekronbekron
Sent: Thursday, July 23, 2020 02:19

Quick poll for the list:

Can we all follow a 'rule' that says [OT] must be added in all off-topic 
discussions, so we can filter them out if required?

--
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: Encrypting z/OS SNMP traps to Windows SNMP server

[Attila Fogarasi]

CA Common Services supports SNMPv3 with DES encryption and SHA-5 and MD5
authentication, hopefully that works with your Solar Winds Orion server.
You define the use of encryption in the SNMPCNFG member for your ENFSNMPM
procedure (sample with good comments is in  CAW0OPTV dataset).  That would
be an easy change (not affecting OPS/MVS).

On Tue, Jul 21, 2020 at 2:28 AM John McKown 
wrote:

> This is a new requirement from the higher ups in our new owning company. We
> are still on z/OS 1.12, so I don't have any new fancy stuff. We use
> CA-OPS/MVS to trap "abend" messages from the CA-7 Browse log. We send these
> messages to an Solar Winds "Orion" SNMP server so that it can interface
> with CA Service Desk to automatically open Service Desk tickets. This is
> all on internal (Data Center) LAN. But it is "server to server" by the
> standards of our new masters and so it MUST be encrypted or we must stop
> doing it.
>
> I have been trying to read up on AT/TLS, but it is totally over my head. I
> don't really know anything about IP encryption. Or Windows people are also
> ignorant of IP encryption on z/OS (of course).
>
> --
> People in sleeping bags are the soft tacos of the bear world.
> Maranatha! <><
> John McKown
>
> --
> 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

Implementation of COBOL non-standard rounding

[Clark Morris]

Currently in IBM Enterprise COBOL the only rounding is round half away
from zero (5.5 becomes 6, -5.5 becomes -6).  I understand than various
organizations use different rounding rules based on policy and/or
legal requirements in some or all computations involving rounding.
These would include round half to nearest even (5.5 becomes 6, 4.5
becomes 4. How do organizations handle the non-standard rounding in
current COBOL programs? in-line code with each computation? PERFORM of
a common subroutine copied into the program? CALL to a separate COBOL
subroutine? CALL to a routine in another language?  If the 2014 COBOL
Standard additional rounding options included the ones your
organization uses, would your organization modify code over time to
take advantage of the software and hardware support for them, assuming
that they would deliver identical results? 

Clark Morris  

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

Re: cURL and security

[Luke Wilby]

I'm not sure use CWET will make any difference.

The cURL targets require client authentication.

The cURL targets live on z/OS (z/OS Connect, zOSMF, DB2, etc)

The clients may be TSO users, batch jobs, Windows, Mac or Linux clients. The 
batch jobs may run under userids that do not have passwords.

We cannot store passwords anywhere. No scripts, no files.

Our z/OS users generally don't have certificates or keyrings. Our servers do 
(DB2, z/OS Connect, zOSMF, etc).
 
Thanks
Luke








> It would be best to consider switching to the z/OS Client Web Enablement
> Toolkit.
> There are sample programs for REXX / ASM / COB .. and I'm positive there'll
> be a Python client pretty soon (IBM Open Enterprise Python for z/OS).
> Don't think cURL is loved that much on Z.
> 
> Hmm .. unless client auth is required at the cURL target, you don't need to
> worry about client certs, right?
> Just plop on the target server's CA cert (interim & root CA) public keys in a
> user keyring, and point CWET to the user keyring.
> Server auth will work just fine.
> 
> - KB
> 
> ‐‐‐ Original Message ‐‐‐
> On Thursday, July 23, 2020 10:20 AM, Filip Palian 
> wrote:
> 
> > Hey,
> >
> > You can read login credentials from within a script at run time from a
> > separate file containing password. This file should have an adequate
> > permissions and ownership set of course.
> >
> > Alternatively, if you control the target, perhaps you can whitelist
> > your curl/client.
> >
> > I hope that helps.
> >
> > Cheers,
> > F
> >
> > W dniu czwartek, 23 lipca 2020 Luke akal...@hotmail.com napisał(a):
> >
> > > Hi All
> > > I'm wondering if anyone is using cURL on z/OS in a production setting?
> > > I'm interested how to utilise cURL when the target URL requires
> > > authentication.
> > > We can't use Basic Auth because we are not able to store usernames
> > > and password in scripts or batch jobs.
> > > We can't easily use certificates because our users on z/OS do not
> > > have certificates and our Windows based corporate certificate
> > > management doesn't allow users access to the private keys of their
> Windows certificates.
> > > Anyone else using cURL for DevOps on z/OS and how are you securing it?
> > >
> > > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Sending email from the Mainframe

[Seymour J Metz]

> Given the prior comments about wanting to not smart host / off-load to a
> different local SMTP server, yes, I'm assuming direct-to-MX with my
> comments / questions.

That's a bad idea for several reasons.

> Sorry, that's somewhat nebulous.  Are you asking about the z/OS SYSPROGs
> or the company management that said SYSPROGs report to?

I'm talking whoever has authority over both the z/OS system and the network 
infrastructure, including firewalls, mail servers, routers and connection to an 
ISP or backbone.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Grant Taylor [023065957af1-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, July 23, 2020 4:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

On 7/23/20 2:27 PM, Seymour J Metz wrote:
> Are you assuming direct-to-MX?

Given the prior comments about wanting to not smart host / off-load to a
different local SMTP server, yes, I'm assuming direct-to-MX with my
comments / questions.

> Are you assuming using a mail server not under the control of the z/OS
> system's management.

Sorry, that's somewhat nebulous.  Are you asking about the z/OS SYSPROGs
or the company management that said SYSPROGs report to?

> If not, then I've already addressed the issue.

I agree that having z/OS smart-host to a different SMTP server that does
the to-MX sending would address my comments / questions.  I assume that
said smart-host is under the same company management hierarchy (or
subcontracted there from), even if it's not actually the z/OS SYSPROGs.

I believe that enforcing TLS with CSSMTP being used as direct-to-MX is
going to be problematic.  At least for a general outbound email.
Business-to-business might be considerably less problematic.



--
Grant. . . .
unix || die

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

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

Re: Sending email from the Mainframe

[Grant Taylor]

On 7/23/20 2:27 PM, Seymour J Metz wrote:

Are you assuming direct-to-MX?


Given the prior comments about wanting to not smart host / off-load to a 
different local SMTP server, yes, I'm assuming direct-to-MX with my 
comments / questions.


Are you assuming using a mail server not under the control of the z/OS 
system's management.


Sorry, that's somewhat nebulous.  Are you asking about the z/OS SYSPROGs 
or the company management that said SYSPROGs report to?



If not, then I've already addressed the issue.


I agree that having z/OS smart-host to a different SMTP server that does 
the to-MX sending would address my comments / questions.  I assume that 
said smart-host is under the same company management hierarchy (or 
subcontracted there from), even if it's not actually the z/OS SYSPROGs.


I believe that enforcing TLS with CSSMTP being used as direct-to-MX is 
going to be problematic.  At least for a general outbound email. 
Business-to-business might be considerably less problematic.




--
Grant. . . .
unix || die

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

Re: Sending email from the Mainframe

[Seymour J Metz]

> What happens to email if CSSMTP (AT-TLS) is configured to *require*
> encryption and the receiving system doesn't support encryption?

Are you assuming direct-to-MX? Are you assuming using a mail server not under 
the control of the z/OS system's management. If not, then I've already 
addressed the issue.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Grant Taylor [023065957af1-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, July 23, 2020 11:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

On 7/23/20 1:24 AM, Seymour J Metz wrote:
> But what, someone may ask, if the realy connects to a box that doesn't
> support TLS 1.2? The same thing as if the traffic from CSSMTP were
> unencrypted, and not the concern of the z/OS staff unless the relay
> is also running on z/OS.

What happens to email if CSSMTP (AT-TLS) is configured to *require*
encryption and the receiving system doesn't support encryption?

I presume that CSSMTP will fail to send the email b/c of the lack of
encryption.

What happens to these unsent emails?

Does an error get sent back to the sending application?

Do the unsent messages pile up in a spool somewhere?

Even at ~90% support for encryption, that's one in ten emails that can't
be sent via encrypted channels.  What happens to that 10% that can't be
sent with encryption?  Also, I don't believe the ~90% figure.  I believe
it to be somewhere between 60% and 70% and that there is a geographic
influence to the number.

I agree that requiring encryption is perfectly reasonable.  I think that
requiring TLS 1.2 is a laudable goal.

But I also think it would be negligent to fail to have a plan for email
that can't be sent via encrypted channels.

What happens to the email that CSSMTP (AT-TLS) wants to send if the
receiving system has an expired certificate and thus fails validation?
This is a fairly common short lived oops.

Also, I was not questioning the merit of TLS.  I was simply inquiring if
the requirement was for encryption, which can be accomplished multiple
ways, or if it was for TLS specifically.



--
Grant. . . .
unix || die

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

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

Re: SFTP and z/OS Migration

[Paul Gilmartin]

On Thu, 23 Jul 2020 17:57:20 +, Seymour J Metz wrote:

>Neither LCD nor LPWD is part of RFC 959. ...
>
Agreed.  Generally the RFCs impose only weak requirements on
client UIs, easily satisfied by both linemode and GUI clients.
Stronger requirements on both client and server network
interfaces.

>In an ideal world the MVS-OE developers would have looked at what Eunix 
>programmers in the wild actually used and not just what was needed to get 
>certification, but that has not always been what they did.
> 
Yes, remembering all the while that both MVS client and server
antedate OMVS and their subsequent extension to HFS was an
ad-hoc overlay.

-- gil

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

Re: SFTP and z/OS Migration

[Seymour J Metz]

Neither LCD nor LPWD is part of RFC 959. In an ideal world the MVS-OE 
developers would have looked at what Eunix programmers in the wild actually 
used and not just what was needed to get certification, but that has not always 
been what they did.


--
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: Thursday, July 23, 2020 1:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SFTP and z/OS Migration

On Wed, 22 Jul 2020 16:07:54 -0500, Kirk Wolf wrote:
>...
>WinSCP has unique problems: it starts one SFTP connection for directory
>displays, and one or more for file transfers.   This is a little silly
>since you can do multiple things at a time on one connection.   This means
>that you can't change a /+ setting in the GUI and have it apply to file
>transfers.
>
This is reminiscent of an oddity in MVS plain old linemode ftp.  Like:

cd /here
ftp localhost
LPWD
/here
LCD /there
LPWD
/there
! pwd
/here

... apparently the MVS FTP client process does not issue a chdir(); as
I'm accustomed to on other systems.

-- 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: Sending email from the Mainframe

[Seymour J Metz]

There's a difference between questioning the accuracy of the stated reqirement 
and suggesting that he not comply with it. Why not simply ask the OP for the 
exact requirement imposed by management?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Grant Taylor [023065957af1-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, July 23, 2020 12:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

On 7/23/20 12:17 AM, Timothy Sipples wrote:
> I don't know why you're questioning Len's expressed*requirement*.

Experience.  Specifically experience that has included being down stream
of multiple telephone games.  Person A tells person B that they require
/encryption/.  Then person B tells person C that /TLS/ is required.  —
Person B innocently substituted "TLS" in place of "encryption" thinking
that it was the only way to meet the requirement.  —  So person C's
working understanding is that /TLS/ specifically is required when that
is not the case.  Person A might be perfectly satisfied with an IPsec VPN.

So experience has taught me to /politely/ inquire if the strict
requirement is for /TLS/ -or- /encryption/.

It may seem like a subtle difference.  But the difference has technical
ramifications.



--
Grant. . . .
unix || die

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

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

Re: SFTP and z/OS Migration

[Paul Gilmartin]

On Wed, 22 Jul 2020 16:07:54 -0500, Kirk Wolf wrote:
>...
>WinSCP has unique problems: it starts one SFTP connection for directory
>displays, and one or more for file transfers.   This is a little silly
>since you can do multiple things at a time on one connection.   This means
>that you can't change a /+ setting in the GUI and have it apply to file
>transfers.
>
This is reminiscent of an oddity in MVS plain old linemode ftp.  Like:

cd /here
ftp localhost
LPWD
/here
LCD /there
LPWD
/there
! pwd
/here

... apparently the MVS FTP client process does not issue a chdir(); as
I'm accustomed to on other systems.

-- gil

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

Re: SFTP and z/OS Migration

[Lionel B Dyck]

I just tried Bitvise and have deleted WinSCP and FileZilla - Thank you Kirk...


Lionel B. Dyck <
Website: https://www.lbdsoftware.com

"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 
Kirk Wolf
Sent: Thursday, July 23, 2020 11:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SFTP and z/OS Migration

On Wed, Jul 22, 2020 at 4:07 PM Kirk Wolf  wrote:

>
> You *can* change settings interactively from most SFTP GUIs like 
> FileZilla
> -
> -  change directories to the "/+" directory (you will see your current
> settings)
> -  rename  the ".newoption" pretend file in that directory to the 
> option that you want to set
>
> WinSCP has unique problems: it starts one SFTP connection for directory
> displays, and one or more for file transfers.   This is a little silly
> since you can do multiple things at a time on one connection.   This means
> that you can't change a /+ setting in the GUI and have it apply to 
> file transfers.
>
> I don't use Windows much, but my favorite SFTP GUI is "BitVise", which 
> includes an SSH emulator and SFTP client.
>
>
>
Note:  I just tried the latest version of FileZilla, and it also now starts a 
new SFTP connection for transfers, separate from the one used for the UI
display.So changing settings interactively won't work there either.
 Try BitVise, which is better anyway IMO.

Kirk Wolf

--
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: Sending email from the Mainframe

[Grant Taylor]

On 7/23/20 12:17 AM, Timothy Sipples wrote:

I don't know why you're questioning Len's expressed*requirement*.


Experience.  Specifically experience that has included being down stream 
of multiple telephone games.  Person A tells person B that they require 
/encryption/.  Then person B tells person C that /TLS/ is required.  — 
Person B innocently substituted "TLS" in place of "encryption" thinking 
that it was the only way to meet the requirement.  —  So person C's 
working understanding is that /TLS/ specifically is required when that 
is not the case.  Person A might be perfectly satisfied with an IPsec VPN.


So experience has taught me to /politely/ inquire if the strict 
requirement is for /TLS/ -or- /encryption/.


It may seem like a subtle difference.  But the difference has technical 
ramifications.




--
Grant. . . .
unix || die

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

Re: SFTP and z/OS Migration

[Kirk Wolf]

On Wed, Jul 22, 2020 at 4:07 PM Kirk Wolf  wrote:

>
> You *can* change settings interactively from most SFTP GUIs like FileZilla
> -
> -  change directories to the "/+" directory (you will see your current
> settings)
> -  rename  the ".newoption" pretend file in that directory to the option
> that you want to set
>
> WinSCP has unique problems: it starts one SFTP connection for directory
> displays, and one or more for file transfers.   This is a little silly
> since you can do multiple things at a time on one connection.   This means
> that you can't change a /+ setting in the GUI and have it apply to file
> transfers.
>
> I don't use Windows much, but my favorite SFTP GUI is "BitVise", which
> includes an SSH emulator and SFTP client.
>
>
>
Note:  I just tried the latest version of FileZilla, and it also now starts
a new SFTP connection for transfers, separate from the one used for the UI
display.So changing settings interactively won't work there either.
 Try BitVise, which is better anyway IMO.

Kirk Wolf

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

Re: Sending email from the Mainframe

[Grant Taylor]

On 7/23/20 1:24 AM, Seymour J Metz wrote:
But what, someone may ask, if the realy connects to a box that doesn't 
support TLS 1.2? The same thing as if the traffic from CSSMTP were 
unencrypted, and not the concern of the z/OS staff unless the relay 
is also running on z/OS.


What happens to email if CSSMTP (AT-TLS) is configured to *require* 
encryption and the receiving system doesn't support encryption?


I presume that CSSMTP will fail to send the email b/c of the lack of 
encryption.


What happens to these unsent emails?

Does an error get sent back to the sending application?

Do the unsent messages pile up in a spool somewhere?

Even at ~90% support for encryption, that's one in ten emails that can't 
be sent via encrypted channels.  What happens to that 10% that can't be 
sent with encryption?  Also, I don't believe the ~90% figure.  I believe 
it to be somewhere between 60% and 70% and that there is a geographic 
influence to the number.


I agree that requiring encryption is perfectly reasonable.  I think that 
requiring TLS 1.2 is a laudable goal.


But I also think it would be negligent to fail to have a plan for email 
that can't be sent via encrypted channels.


What happens to the email that CSSMTP (AT-TLS) wants to send if the 
receiving system has an expired certificate and thus fails validation? 
This is a fairly common short lived oops.


Also, I was not questioning the merit of TLS.  I was simply inquiring if 
the requirement was for encryption, which can be accomplished multiple 
ways, or if it was for TLS specifically.




--
Grant. . . .
unix || die

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

Re: DFSORT task (I hope)

[Sri h Kolusu]

>>I see it is candidate for REXX script, but DFSORT job seems to be more
elegant.

Radoslaw Skorupka,

As Max already shown DFSORT does have an elegant file matching capability
using JOINKEYS.  Please check the  smart DFSORT trick "Create files with
matching and non-matching records"  which is available at

https://www.ibm.com/support/pages/node/665475

>>If you want to do it DFSORT, I think you'll have to use ICETOOL with the
SPLICE option.

Joe,

SPLICE is an older technique and has limitations(many to many match),
using Joinkeys is the ideal solution for this case

>>You can use JOIN function of DFSORT:

Max,

Excellent !! Thank you.


Thanks,
Kolusu
DFSORT Development
IBM Corporation

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

Re: [OT] OOBOL and English was Re: Still COBOL After All These Years?

[Bob Bridges]

I would be willing to follow such a convention, if there's a consensus for it, 
or possibly even if it's requested by only a few.  Personally I enjoy such 
discussions - obviously - but I can see not everyone would.

But what constitutes OT?  These things have recently started with a discussion 
of COBOL and mainframes, neither of which I would judge to be OT.  It's hard to 
be certain precisely where the thread crosses the line.  Opinions will differ, 
at least.

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

/* Why did the string bass player get angry at the timpanist?  A: Because the 
timpanist turned a peg and wouldn't tell him which one.  -from a collection of 
musician jokes */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of kekronbekron
Sent: Thursday, July 23, 2020 02:19

Quick poll for the list:

Can we all follow a 'rule' that says [OT] must be added in all off-topic 
discussions, so we can filter them out if required?

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

Re: DFSORT task (I hope)

[Massimo Biancucci]

You can use JOIN function of DFSORT:

//ST100EXEC  PGM=SORT
//SYSOUT  DD SYSOUT=*
//FILE1   DD *
DSNAME01
DSNAME09
DSNAME02
DSNAME27
DSNAME04
/*
//FILE2   DD *
DSNAME09
DSNAME04
/*
//SORTOUT  DD SYSOUT=*
//SYSIN   DD *
 JOINKEYS F1=FILE1,FIELDS=(1,44,A)
 JOINKEYS F2=FILE2,FIELDS=(1,44,A)
 JOIN UNPAIRED,F1,ONLY
 REFORMAT FIELDS=(F1:1,80)
 SORT FIELDS=COPY
/*

Output is:

DSNAME01
DSNAME02
DSNAME27

I assumed dsnames are at 1,44 and lrecl is 80.

JOINKEYS UNPAIRED,F1,ONLY means output only unpaired keys records from
FILE1.

Best regards.
Max


Mail
priva di virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Il giorno gio 23 lug 2020 alle ore 10:11 R.S. <
r.skoru...@bremultibank.com.pl> ha scritto:

> I have the following case:
>
> Large (thousands) list containing filenames,
> filea10002
> fileb10041
> filec20043
> filed39093
> longfileabc
> anotherfile
> ...
>
> and small (dozens) list of filename "exlusions"
> longfileabc
> fileb10041
> ...
>
> Short list is subset of long list. All files has fixed lentgh name, no
> other fields exist in the record.
> The goal is to exclude from large list all the entries which are present
> in the short list.
> Lists are unsorted, but I think it doesn't matter. I see it is candidate
> for REXX script, but DFSORT job seems to be more elegant.
> Any clue?
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2020 r. wynosi 169.401.468 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital
> amounting to PLN 169.401.468 as at 1 January 2020.
>
> --
> 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: OOBOL and English was Re: Still COBOL After All These Years?

[Joe Monk]

"Lb Foot is not a measure of pressure" ... correct. It is a measure of
torque.

A pound-foot (lbf⋅*ft*) is a unit of torque (a pseudovector). One
pound-foot is the torque created by one pound of force acting at a
perpendicular distance of one foot from a pivot point. Conversely one
pound-foot is the moment about an axis that applies one pound-force at a
radius of one foot.

Joe

On Wed, Jul 22, 2020 at 10:08 PM Wayne Bickerdike  wrote:

> Time for us to go back to school.
>
> Lb Foot is not a measure of pressure, it needs to act on area to be a
> measure of pressure. Lbs / square foot/ PSI etc. are common measurements of
> pressure (tires etc.).
>
> In the 60's we were taught poundals as a measure of force, ie the force
> required to accelerate  a mass of one pound at a rate of one foot per
> second per second.
>
> Thankfully SI came to the rescue by the time I went to college.
> Isaac Newton, quintessentially English gets an SI unit, as does Faraday,
> Tesla, Curie. Very multicultural...
>
>
> On Thu, Jul 23, 2020 at 12:44 PM Mike Schwab 
> wrote:
>
> > And the metric equivalent is Newton Meters.  You can get torque
> > wrenches in either measurement, I would think some have both.  Some
> > bolts will fail if too loose or too tight.
> >
> > On Wed, Jul 22, 2020 at 7:31 PM Gibney, Dave  wrote:
> > >
> > > Foot pounds is a measure of pressure
> > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List  On
> > > > Behalf Of Seymour J Metz
> > > > Sent: Wednesday, July 22, 2020 5:29 PM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: OOBOL and English was Re: Still COBOL After All These
> > Years?
> > > >
> > > > Yes, and whyat is lbf?
> > > >
> > > >
> > > > --
> > > > Shmuel (Seymour J.) Metz
> > > > https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg
> > > > BY0HMszNaDT!78SA9VzAdbjMTRYvnKQIT6jc0VOHrKWRan9aUIqsjvsI210oVzT
> > > > j6BY-5Ot12g$
> > > >
> > > >
> > > > 
> > > > From: IBM Mainframe Discussion List  on
> > > > behalf of Gibney, Dave 
> > > > Sent: Wednesday, July 22, 2020 8:26 PM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: OOBOL and English was Re: Still COBOL After All These
> > Years?
> > > >
> > > > Actually, the pound is a unit of force in English units. I believe
> > weight is
> > > > measured in stones.
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: IBM Mainframe Discussion List  On
> > > > > Behalf Of Seymour J Metz
> > > > > Sent: Wednesday, July 22, 2020 4:23 PM
> > > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > > Subject: Re: OOBOL and English was Re: Still COBOL After All These
> > Years?
> > > > >
> > > > > You have the same mass versus weight issue with pound.
> > > > >
> > > > >
> > > > > --
> > > > > Shmuel (Seymour J.) Metz
> > > > >
> > > > https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg
> > > > >
> > > > BY0HMszNaDT!6qfIOAdssnfWNb9bnHdVr6MfJemAcckz1N2FLwezCZtDcak8bJ
> > > > > a3JHuDBIGmlQ$
> > > > >
> > > > > 
> > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> > > > > behalf of Tony Thigpen [t...@vse2pdf.com]
> > > > > Sent: Wednesday, July 22, 2020 6:05 PM
> > > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > > Subject: Re: OOBOL and English was Re: Still COBOL After All These
> > Years?
> > > > >
> > > > > See! SI is a "FANTASTIC" improvement over old stuff. It's all
> > > > > standardized and everyone talks in the same way. (NOT!)
> > > > >
> > > > > Thank you France.
> > > > >
> > > > > Vive la pound, and inch, and mile...
> > > > >
> > > > > (This post was posted with sarcastic mode set to "on".)
> > > > >
> > > > > Tony Thigpen
> > > > >
> > > > > Paul Gilmartin wrote on 7/22/20 5:58 PM:
> > > > > > On Wed, 22 Jul 2020 17:05:29 +, Seymour J Metz wrote:
> > > > > >
> > > > > >> I took me a while before I realized that, of course, kg is a
> unit
> > of mass,
> > > > not
> > > > > of weight; you weigh tings in kilogram-force (kgf or kgF).
> > > > > >>
> > > > > > Which of the following would you envision and welcome as an
> > idiomatic
> > > > > > alternative?:
> > > > > > o ... how many kg I mass?
> > > > > > o ... how many kgF I weigh?
> > > > > > o Other (specify)?
> > > > > >
> > > > > > Should an outfitter sell climbing ropes rated in Newtons?
> > > > > >
> > > > > > (BTW, what's the SI unit of Specific Impulse?  And the formula
> for
> > ∆v?
> > > > > Ugh!)
> > > > > >
> > > > > >> 
> > > > > >> From: Jackson, Rob
> > > > > >> Sent: Wednesday, July 22, 2020 12:21 PM
> > > > > >>
> > > > > >> -Original Message-
> > > > > >> From: Bob Bridges
> > > > > >> Sent: Wednesday, July 22, 2020 12:16 PM
> > > > > >>
> > > > > >> [External Email. Exercise caution when clicking links or opening
> > > > > attachments.]
> > > > > >>
> > > > > >> ... I'd have to calculate to tell you how many kg I weigh.
> > > > > >
> > > > > > -- gi

Re: DFSORT task (I hope)

[Joe Monk]

If you want to do it DFSORT, I think you'll have to use ICETOOL with the
SPLICE option.

Joe

On Thu, Jul 23, 2020 at 3:11 AM R.S.  wrote:

> I have the following case:
>
> Large (thousands) list containing filenames,
> filea10002
> fileb10041
> filec20043
> filed39093
> longfileabc
> anotherfile
> ...
>
> and small (dozens) list of filename "exlusions"
> longfileabc
> fileb10041
> ...
>
> Short list is subset of long list. All files has fixed lentgh name, no
> other fields exist in the record.
> The goal is to exclude from large list all the entries which are present
> in the short list.
> Lists are unsorted, but I think it doesn't matter. I see it is candidate
> for REXX script, but DFSORT job seems to be more elegant.
> Any clue?
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2020 r. wynosi 169.401.468 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital
> amounting to PLN 169.401.468 as at 1 January 2020.
>
> --
> 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

Solution to missing OVIEW option

[Lionel B Dyck]

Just published this technique to provide an OVIEW option

 

https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/lionel-dyck
1/2020/07/23/adding-oview-to-the-current-obrowse-and-oedit-comm?CommunityKey
=87042487-940e-49cc-ae6d-5a5b76c5ea7e
 &Tab=

 

 

Lionel B. Dyck <
Website:   https://www.lbdsoftware.com

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

 


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

Re: Sending email from the Mainframe

[Sasso, Len]

Tim:

Thank you, I thought it was a reasonable requirement.


Please Be Safe!

Thank You!

Len Sasso
Systems Administrator Senior
CSRA, A General Dynamics Information Technology Company
327 Columbia TPKE
Rensselaer, NY 12144

Office Hours: M-F  7 AM - 3:45 PM
Out-Of-Office:
Phone: (518) 257-4209
Cell: (518) 894-0879
Fax: (518) 257-4300
len.sa...@gdit.com
URL: www.gdit.com





From: IBM Mainframe Discussion List  on behalf of 
Timothy Sipples 
Sent: Thursday, July 23, 2020 2:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Sending email from the Mainframe



 [External: Use caution with links & attachments]

Grant Taylor wrote:
>That means that z/OS's CSSMTP will be near or on par with other SMTP
>servers and related problems securing SMTP traffic.  Most of which have
>to do with the capabilities of the receiving SMTP server, which is
>outside of CSSMTP's control.

First of all, here's what Len Sasso wrote:
>All our messages must implement TLS 1.2 or higher for
>transport level encryption.

I don't know why you're questioning Len's expressed *requirement*. And
(don't worry, Len!) it's a very, very reasonable requirement in the year
2020 and beyond. For that matter it was a reasonable requirement 20+ years
ago, too.

Then there's this fact, which Lionel Dyck kindly pointed out:
>CSSMTP is a send only SMTP service - it does not receive anything.

Exactly. This is about getting TLS 1.2+ encryption enabled from z/OS at
least as far as the next hop. CSSMTP alone doesn't provide a return
mailbox.

According to Google's latest Transparency Report, available here:

https://urldefense.com/v3/__https://transparencyreport.google.com/safer-email/overview?hl=en__;!!JRQnnSFuzw7wjAKq6ti6!jQEpQBYYYTpvQzuolvNNqmVerCNjKRCLDoprizRvzc2Qp-ZFVX3swid6aX90zw$

93% of outgoing e-mail from Google and 94% of incoming e-mail to Google
rode over TLS between April 24, 2020, and July 23, 2020. Google's e-mail
services are heavily consumer-oriented ("How is piano practice going?"),
and well over 90% of it is encrypted in flight. Len Sasso is dealing with
an enterprise system, presumably. Maybe my cousin's medical insurance
claim acknowledgment is being e-mailed, or maybe your loan application
update is being e-mailed out to you. Does anyone seriously want to
question Len's requirement? Or would it be at least as appropriate to
question why you haven't enabled encryption for your SMTP and other
network traffic, if you haven't?

It's very frustrating to me when even basic security precautions and
practices are questioned like this. Get it turned on, please! It's quick,
easy, and no additional charge. And have a look at the z/OS Encryption
Readiness Tool ("zERT"), included with z/OS at no additional charge, to
get visibility on where you still have gaps.

>If you configure z/OS's CSSMTP to /require/ encryption, TLS 1.2 or
>otherwise, and the receiving SMTP system doesn't offer it, the email
>will be stuck on z/OS.

That's an available configuration choice, that's correct, and that's
exactly what *should* happen in myriad real world scenarios to avoid a
potential or actual security breach.

>Do you really want to have someone perform regular postmaster duties on
>z/OS?

As Lionel patiently explained, this is about whether Len Sasso's
requirement is satisfied, to encrypt e-mail traffic to the next hop. There
are no postperson duties here, not with CSSMTP. These are basic network
security duties, prudently practiced and respected for decades now.

But (hypothetically, off on your tangent) why not? It's an IMAP
mailbox the postperson(s) monitor, presumably. The postperson probably
isn't either configuring and administering a Kubernetes cluster or
navigating ISPF screens. If the mailbox were hosted on z/OS (yes, it can
be, with other software), what's the problem?

I'm a little confused here. Isn't this IBM-MAIN? Is there something you
wouldn't or don't like about providing more and more useful user services
from z/OS?

>It might be better to send the email to another exissting corporate
>SMTP server where someone is already handling the postmaster duties.

Yes, there's something else besides CSSMTP. OK, backing off that
tangent

>Simply enabling TLS on z/OS's CSSMTP is probably not sufficient to
>guarantee that the email transmission path to the next SMTP server will
>be encrypted.

It is if you configure AT-TLS to require it, which is par for the course
really.

>Both the sending end (CSSMTP) and the receiving end (remote SMTP server)
>need to support encryption.

Yes, and as you can see from Google's Transparency Report TLS isn't a rare
or exotic thing. (What year is this?)

>Most MTAs can be an encrypted client without their own TLS certificate.
>—  Though a /client/ TLS certificate can be entertaining to use in place
>of username and password for authenticating the sending system to a
relay.
>}:-)

Not merely "entertaining." It's one perfectly reasonable, prudent security
measure 

Re: OOBOL and English was Re: Still COBOL After All These Years?

[Jeremy Nicoll]

On Wed, 22 Jul 2020, at 22:58, Paul Gilmartin wrote:

> Should an outfitter sell climbing ropes rated in Newtons?

I have a feeling that things like safety harnesses (for people working at
height), fall-arrest systems etc are rated in Newtons etc.

It's probably because it's not just the static load of someone dangling
on the end of a rope that matters, but the strain they put on it if they've
fallen however far before the system tries to arrest their fall.


Adverts might not say this though; they might instead say that an item 
meets such-and-such a use standard.  That in turn might dictate that 
a wearer shouldn't be more than (say) 120 kg nor be falling more than 
20m.

-- 
Jeremy Nicoll - my opinions are my own.

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

DFSORT task (I hope)

[R.S.]

I have the following case:

Large (thousands) list containing filenames,
filea10002
fileb10041
filec20043
filed39093
longfileabc
anotherfile
...

and small (dozens) list of filename "exlusions"
longfileabc
fileb10041
...

Short list is subset of long list. All files has fixed lentgh name, no 
other fields exist in the record.
The goal is to exclude from large list all the entries which are present 
in the short list.
Lists are unsorted, but I think it doesn't matter. I see it is candidate 
for REXX script, but DFSORT job seems to be more elegant.

Any clue?


--
Radoslaw Skorupka
Lodz, Poland





==

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

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

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

If you are not the addressee of this message:

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

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

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

Re: Sending email from the Mainframe

[Seymour J Metz]

Indeed.

CSSMTP is an SMTP client. It needs to connect to an SMTP server, and in most if 
not all installations there is an SMTP server dedicated to the purpose, which 
serves as a relay to the outside world. If management has decreed that all SMTP 
traffic be encrypted, then barring a configuration error the relay will accept 
encrypted traffic. If the relay doesn't support TLS 1.2 then create a trouble 
ticket.

Even if the data don't have privacy issues, I don't see how encryption for 
CSSMTP imposes an administrative burden beyond what the installation would need 
without the SMTP traffic. 

But what, someone may ask, if the realy connects to a box that doesn't support 
TLS 1.2? The same thing as if the traffic from CSSMTP were unencrypted, and not 
the concern of the z/OS staff unless the relay is also running 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 
Timothy Sipples [sipp...@sg.ibm.com]
Sent: Thursday, July 23, 2020 2:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

Grant Taylor wrote:
>That means that z/OS's CSSMTP will be near or on par with other SMTP
>servers and related problems securing SMTP traffic.  Most of which have
>to do with the capabilities of the receiving SMTP server, which is
>outside of CSSMTP's control.

First of all, here's what Len Sasso wrote:
>All our messages must implement TLS 1.2 or higher for
>transport level encryption.

I don't know why you're questioning Len's expressed *requirement*. And
(don't worry, Len!) it's a very, very reasonable requirement in the year
2020 and beyond. For that matter it was a reasonable requirement 20+ years
ago, too.

Then there's this fact, which Lionel Dyck kindly pointed out:
>CSSMTP is a send only SMTP service - it does not receive anything.

Exactly. This is about getting TLS 1.2+ encryption enabled from z/OS at
least as far as the next hop. CSSMTP alone doesn't provide a return
mailbox.

According to Google's latest Transparency Report, available here:

https://transparencyreport.google.com/safer-email/overview?hl=en

93% of outgoing e-mail from Google and 94% of incoming e-mail to Google
rode over TLS between April 24, 2020, and July 23, 2020. Google's e-mail
services are heavily consumer-oriented ("How is piano practice going?"),
and well over 90% of it is encrypted in flight. Len Sasso is dealing with
an enterprise system, presumably. Maybe my cousin's medical insurance
claim acknowledgment is being e-mailed, or maybe your loan application
update is being e-mailed out to you. Does anyone seriously want to
question Len's requirement? Or would it be at least as appropriate to
question why you haven't enabled encryption for your SMTP and other
network traffic, if you haven't?

It's very frustrating to me when even basic security precautions and
practices are questioned like this. Get it turned on, please! It's quick,
easy, and no additional charge. And have a look at the z/OS Encryption
Readiness Tool ("zERT"), included with z/OS at no additional charge, to
get visibility on where you still have gaps.

>If you configure z/OS's CSSMTP to /require/ encryption, TLS 1.2 or
>otherwise, and the receiving SMTP system doesn't offer it, the email
>will be stuck on z/OS.

That's an available configuration choice, that's correct, and that's
exactly what *should* happen in myriad real world scenarios to avoid a
potential or actual security breach.

>Do you really want to have someone perform regular postmaster duties on
>z/OS?

As Lionel patiently explained, this is about whether Len Sasso's
requirement is satisfied, to encrypt e-mail traffic to the next hop. There
are no postperson duties here, not with CSSMTP. These are basic network
security duties, prudently practiced and respected for decades now.

But (hypothetically, off on your tangent) why not? It's an IMAP
mailbox the postperson(s) monitor, presumably. The postperson probably
isn't either configuring and administering a Kubernetes cluster or
navigating ISPF screens. If the mailbox were hosted on z/OS (yes, it can
be, with other software), what's the problem?

I'm a little confused here. Isn't this IBM-MAIN? Is there something you
wouldn't or don't like about providing more and more useful user services
from z/OS?

>It might be better to send the email to another exissting corporate
>SMTP server where someone is already handling the postmaster duties.

Yes, there's something else besides CSSMTP. OK, backing off that
tangent

>Simply enabling TLS on z/OS's CSSMTP is probably not sufficient to
>guarantee that the email transmission path to the next SMTP server will
>be encrypted.

It is if you configure AT-TLS to require it, which is par for the course
really.

>Both the sending end (CSSMTP) and the receiving end (remote SMTP server)
>need to support encryption.

Yes, and as you can see from Google's Transparen