Re: IBM key management products

[Rick Troth]

Not discounting Luke's excellent response: key management is hard.
Look for utilities with reliable import/export capability. Be prepared 
to OWN your keys.
I say this again as a CISSP, own your keys. This is your bread and 
butter, so to speak, the family jewels.
So take care when using these products to ensure that they do what you 
want them to do and that you know what they're doing.


One shop where I recently worked had a great slogan, "crypto is easy; 
key management is hard".
It's not that the crypto was easy but that it's done already, 
implemented, coded, packaged. But the keys *must* be managed by you and 
your team, not the kind of thing which can be outsourced.
Keys and certs cannot be installed and forgotten. And sadly, some of the 
expirations we are given are too short to be practical. (Various 
government issued IDs and licenses commonly last FIVE years. Why do PKI 
certs last only two? ... or ONE?)

But I'm getting off topic. Sorry.

The point is, keys are fundamentally different than any other software 
or data that we have to manage.
And it's a good idea to limit keys to individuals when you can. (Like 
the combination to the bank vault.)

It's all about trust.


-- R; <><


On 4/11/24 05:39, Radoslaw Skorupka wrote:

Sometimes we see some key management products like SKLM or EKMF.
...or TKLM, ISKLM, Guardium KLM, etc.

Is there any explanation of the products scopes, comparisons, 
features, etc. ?




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

Re: Not getting IBM-MAIN Email

[Rick Troth]

Hi David --

Others have had trouble too lately.

IBM-MAIN is hosted by the University of Alabama, so I wonder if "US" 
versus "UA" is a typo?


Some of us have speculated that the university, or one of their service 
providers, recently tightened-up email requirements.
Across the industry, blacklisting and other spam-preventions, have 
tipped the scale and now are blocking a significant portion of 
legitimate email.
Personally, I don't have a solution, but am trying to gather critical 
mass to address it, so I'll contact you off-list. Everyone's situation 
is different, and in this case the note is coming from a Google 
property. But I cannot send (to most recipients) from my home address, 
even with SPF and DKIM in place.


-- R; <><



On 4/8/24 14:25, David Mingee wrote:

Hello All, I stopped getting IBM-MAIN emails on 3/20/2024.  I tried subscribing 
with:
SUBSCRIBE IBM-MAIN David Mingee  sent to LISTSERV.US.EDU
And
INFO IBM-MAIN   to LISTSERV.US.EDU

No success.  Any help would be greatly appreciated.




--
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: Posting issues?

[Rick Troth]

- Getting digests is a RECEIVE function. You can receive email.

- Not being able to post is a SEND problem. Email outbound from your 
personal domain is evidently being blocked.


- What's particularly unnerving in this case is that you don't see a 
bounce message. (Sometimes I don't. Sometimes I do.) That would be the 
"no errors" thing.


Moving your mailboxes to your domain provider might help because your 
domain provider *does* have the chops to force other parties to play along.
As a security professional, I will tell you that's the WRONG way to do 
it. Receivers should NOT trust a party because of their size or because 
of their connections ... any more than because of how many lawyers they 
have on the payroll.
The sending IP address being on the SPF record is clear. Even without 
DNSSEC, faking the SPF record is complex enough that the bad guys would 
have difficulty fudging SPF at the scale they need.
The message to be signed using DKIM is *strong* cryptographic assurance 
that the message is authentic. Fudged DKIM signature is more of a DOS 
problem than a spam allowance.


Does this make sense?

-- R; <><



On 4/5/24 15:36, Phil Smith III wrote:


Yeah, I have SPF records. I may move my mailboxes to my domain provider, who 
might should be able to do better.

But explain:
- getting Digests
- not able to post
- no errors?!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Rick Troth
Sent: Friday, April 5, 2024 3:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Posting issues?

Let's see if this gets through.
I THINK my posts are making it (seems like one did earlier this week), and this 
being a GMail identity, that would make sense.

Phil, you're trying to use a custom address. That is to say, you're using a 
personal domain.
I observe that such are increasingly challenged. I don't have a solution, but 
I'm chasing a couple of remedies. Maybe we can connect.
Maybe we can achieve critical mass?

It's all about trust.
The major email providers don't "trust" akphs.com.
I find that one of my personal domains cannot send to my wife's mailbox at 
Yahoo!. This is a real problem for us and gonna get worse.
All email which is outsourced to Googoo gets through. (sometimes to the spam 
folder)  But Yahoo! slams the door *hard* and won't accept email sent from a 
residential IP address.
Googoo is reasonable about *accepting* traffic too. (again, sometimes to
quarantine) I have not tried (e.g.) AOL or Hotmail. I did try a former 
employer's email service and got rejected.

Two things I have in place which supposedly would help: SPF record and DKIM 
key. These are both in the DNS.
The home IP address being in the SPF record should be enough for Yahoo!
to accept it. Doesn't work.
The DKIM key and the signature on the traffic should confirm that any given 
message is authentic. Doesn't help.
Then too, some are starting to use "DNS SEC". (And some are not, even many 
luminaries. DNSSEC is a pain in all cases and impractical for most.) But I don't know if 
Yahoo! is flagging things based on DNSSEC or lack of.

Anyone else having troubles, let's circle-up off-list and see what we can 
figure out.

-- R; <><


On 4/5/24 14:34, Phil Smith III wrote:

Starting about a week ago, I noticed that posts sent from my lists@akphs address weren't 
showing up in the archives. Email to mailto:lists...@listserv.ua.edu with QUERY IBM-MAIN 
got no response; same from my work address got the expected "not subscribed" 
message. Yet my daily digest to that address has continued.

I tried repeatedly, and finally asked Darren, who kindly looked but didn't see 
anything amiss.

Today when I tried to respond to Radislav's question about FTP, same thing: no 
post. So I subscribed this address as well. That worked, and I've been able to 
post (obviously). But I also noticed a couple of folks asking where the list 
had gone lately, which could just be chance (and isn't quite what I'm seeing, 
either, obviously). I looked at the archives and traffic seems to maybe be down 
over the last 8 days or so, though it wasn't so active before that I can be 
sure (see bottom of this note).

I suddenly realized that if others were having similar issues, that might not 
be obvious beyond the reduced traffic--it's not like they'll be able to post to 
ask, eh?

So: If you're having troubles similar to mine, send a note to 
ibm-m...@akphs.com and let me know. I'm asking you to use that address because 
it will make it easier for me to filter/collate responses.

...phsiii

---
Traffic since March 1 in posts/day:
Fri 1  Mar: 32
Sat 2  Mar: 9
Sun 3  Mar: 7
Mon 4  Mar: 42
Tue 5  Mar: 16
Wed 6  Mar: 25
Thu 7  Mar: 35
Fri 8  Mar: 14
Sat 9  Mar: 7
Sun 10 Mar: 3
Mon 11 Mar: 2
Tue 12 Mar: 11
Wed 13 Mar: 18
Thu 14 Mar: 46
Fri 15 Mar: 31
Sat 16 Mar: 20
Sun 17 Mar: 30
Mon 18 Mar: 17
Tue 19 Mar: 26
Wed 20 Mar: 34
Thu 21 Mar: 6
Fri 22 Mar: 10
Sat 23 Mar: 6
Sun 24 Mar: 12
Mon 25 

Re: Posting issues?

[Rick Troth]

Let's see if this gets through.
I THINK my posts are making it (seems like one did earlier this week), 
and this being a GMail identity, that would make sense.


Phil, you're trying to use a custom address. That is to say, you're 
using a personal domain.
I observe that such are increasingly challenged. I don't have a 
solution, but I'm chasing a couple of remedies. Maybe we can connect. 
Maybe we can achieve critical mass?


It's all about trust.
The major email providers don't "trust" akphs.com.
I find that one of my personal domains cannot send to my wife's mailbox 
at Yahoo!. This is a real problem for us and gonna get worse.
All email which is outsourced to Googoo gets through. (sometimes to the 
spam folder)  But Yahoo! slams the door *hard* and won't accept email 
sent from a residential IP address.
Googoo is reasonable about *accepting* traffic too. (again, sometimes to 
quarantine) I have not tried (e.g.) AOL or Hotmail. I did try a former 
employer's email service and got rejected.


Two things I have in place which supposedly would help: SPF record and 
DKIM key. These are both in the DNS.
The home IP address being in the SPF record should be enough for Yahoo! 
to accept it. Doesn't work.
The DKIM key and the signature on the traffic should confirm that any 
given message is authentic. Doesn't help.
Then too, some are starting to use "DNS SEC". (And some are not, even 
many luminaries. DNSSEC is a pain in all cases and impractical for most.)

But I don't know if Yahoo! is flagging things based on DNSSEC or lack of.

Anyone else having troubles, let's circle-up off-list and see what we 
can figure out.


-- R; <><


On 4/5/24 14:34, Phil Smith III wrote:

Starting about a week ago, I noticed that posts sent from my lists@akphs address weren't 
showing up in the archives. Email to mailto:lists...@listserv.ua.edu with QUERY IBM-MAIN 
got no response; same from my work address got the expected "not subscribed" 
message. Yet my daily digest to that address has continued.

I tried repeatedly, and finally asked Darren, who kindly looked but didn't see 
anything amiss.

Today when I tried to respond to Radislav's question about FTP, same thing: no 
post. So I subscribed this address as well. That worked, and I've been able to 
post (obviously). But I also noticed a couple of folks asking where the list 
had gone lately, which could just be chance (and isn't quite what I'm seeing, 
either, obviously). I looked at the archives and traffic seems to maybe be down 
over the last 8 days or so, though it wasn't so active before that I can be 
sure (see bottom of this note).

I suddenly realized that if others were having similar issues, that might not 
be obvious beyond the reduced traffic--it's not like they'll be able to post to 
ask, eh?

So: If you're having troubles similar to mine, send a note to 
ibm-m...@akphs.com and let me know. I'm asking you to use that address because 
it will make it easier for me to filter/collate responses.

...phsiii

---
Traffic since March 1 in posts/day:
Fri 1  Mar: 32
Sat 2  Mar: 9
Sun 3  Mar: 7
Mon 4  Mar: 42
Tue 5  Mar: 16
Wed 6  Mar: 25
Thu 7  Mar: 35
Fri 8  Mar: 14
Sat 9  Mar: 7
Sun 10 Mar: 3
Mon 11 Mar: 2
Tue 12 Mar: 11
Wed 13 Mar: 18
Thu 14 Mar: 46
Fri 15 Mar: 31
Sat 16 Mar: 20
Sun 17 Mar: 30
Mon 18 Mar: 17
Tue 19 Mar: 26
Wed 20 Mar: 34
Thu 21 Mar: 6
Fri 22 Mar: 10
Sat 23 Mar: 6
Sun 24 Mar: 12
Mon 25 Mar: 11
Tue 26 Mar: 28
Wed 27 Mar: 7
Thu 28 Mar: 36
Fri 29 Mar: 4
Sat 30 Mar: 3
Sun 31 Mar: 7
Mon 1  Apr: 6
Tue 2  Apr: 6
Wed 3  Apr: 17
Thu 4  Apr: 7
Fri 5  Apr: 6

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

in search of AIX/ESA

[Rick Troth]

Is anyone running AIX/ESA or do you happen to have installation media 
for AIX/ESA?
I could ask the same about AIX/370 (which could run in either /370 and 
/XA mode).


thanks


-- R; <><

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

security and privacy for the 21st century

[Rick Troth]

Techies will understand.
And maybe it's coddling the non-techies that drives service companies to 
provide dumbed-down remedies.
They're still obligated to comply with new and wonderful regulations. 
They (the good ones) genuinely try and they (the lazy ones) at least 
want to *look* like they're protecting us.


So I got another of these "you have received a secure message" messages, 
the kind which come through one channel (objectively *not* secure) 
telling me to go to another channel (secured, at some level, but 
invariably hard to use).
If the first channel is insecure, how do they know that I'm even getting 
the message to go read the message?


I want this crap to go away!
And it's not like it can't go away.
It's just that simple solutions seem to have baggage. "It's too easy, so 
it can't possibly be really effective." Why don't we teach the kids 
basic LOGIC in school??


The rant is here:

https://github.com/trothr/blog/blob/master/sir.santa/2024/20240223-you-have-received.md

And some will disagree.
That's okay, because you're allowed to be wrong.
But we can talk about it. (The alternatives are debatable.)
I expect the biggest disagreement to come from PKI aficionados. PKI is 
great, but it doesn't work well for person-to-person. Long story.



-- R; <><





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

Re: GNU COBOL

[Rick Troth]

Forgive me.
I really don't mean to be whining about this.
Up to now, the only USS that I've had access to has been that of an 
employer, so to use such for building things that I share publicly would 
be kinda stealing from them.


Chicory needs really just one thing, and then I could pull-in the 
"parent" makefiles and let-er-rip.
It needs a 'chmod 1777' directory named /usr/opt. My usual habit is to 
let that physically be /var/opt (and then /usr/opt is a sym-link to it).


For USS, any given FLOSS package might also need the patches which Igor 
and the gang on the "z/OS Open Tools" GitHub project have provided.
That will take time, but should eventually fall to automation. They've 
got almost 200 packages, including RSYNC (THANK YOU!!), but I have not 
found Gnu COBOL. Maybe Gnu COBOL "just works".


-- R; <><



On 3/19/24 08:38, Rick Troth wrote:
I'd be happy to run Gnu COBOL through it's paces on USS (as well as 
any other FLOSS packages in the Chicory collection).
I just need a USS environment from which artifacts can be shared 
publicly. (That is, not an employer's USS nor some other similarly 
restricted USS.)


Got shell access where I can throw my SSH keys? Lemme know! Thanks.

-- R; <><



On 3/18/24 16:59, W Mainframe wrote:

Hi,A port to USS OMVS sounds perfect... :)
Dan


Sent from Yahoo Mail for iPhone


On Monday, March 18, 2024, 5:57 PM, Rick Troth 
<058ff5c2d0a7-dmarc-requ...@listserv.ua.edu> wrote:


I try to maintain working copies of Gnu COBOL in the Chicory collection.
Presently we have Gnu COBOL 3.2 for FreeBSD (64 bit), AMD/Intel Linux
(64-bit and 32-bit), and Z or S390 Linux (64-bit and 31-bit).

rsync://chic.casita.net/opt/gnucobol-3.2/

-- R; <><


On 3/16/24 15:36, Mark Jacobs wrote:
GnuCOBOL "has reached an industrial maturity and can compete with 
proprietary offers in all environments," boasted contributor Fabrice 
Le Fessant, in a FOSDEM talk.


https://thenewstack.io/20-years-in-the-making-gnucobol-is-ready-for-industry/ 



Sent from [ProtonMail](https://protonmail.com), Swiss-based 
encrypted email.


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


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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email 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: GNU COBOL

[Rick Troth]

I'd be happy to run Gnu COBOL through it's paces on USS (as well as any 
other FLOSS packages in the Chicory collection).
I just need a USS environment from which artifacts can be shared 
publicly. (That is, not an employer's USS nor some other similarly 
restricted USS.)


Got shell access where I can throw my SSH keys? Lemme know! Thanks.

-- R; <><



On 3/18/24 16:59, W Mainframe wrote:

Hi,A port to USS OMVS sounds perfect... :)
Dan


Sent from Yahoo Mail for iPhone


On Monday, March 18, 2024, 5:57 PM, Rick Troth 
<058ff5c2d0a7-dmarc-requ...@listserv.ua.edu> wrote:

I try to maintain working copies of Gnu COBOL in the Chicory collection.
Presently we have Gnu COBOL 3.2 for FreeBSD (64 bit), AMD/Intel Linux
(64-bit and 32-bit), and Z or S390 Linux (64-bit and 31-bit).

rsync://chic.casita.net/opt/gnucobol-3.2/

-- R; <><


On 3/16/24 15:36, Mark Jacobs wrote:

GnuCOBOL "has reached an industrial maturity and can compete with proprietary offers 
in all environments," boasted contributor Fabrice Le Fessant, in a FOSDEM talk.

https://thenewstack.io/20-years-in-the-making-gnucobol-is-ready-for-industry/

Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.

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

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email 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: GNU COBOL

[Rick Troth]

I try to maintain working copies of Gnu COBOL in the Chicory collection.
Presently we have Gnu COBOL 3.2 for FreeBSD (64 bit), AMD/Intel Linux 
(64-bit and 32-bit), and Z or S390 Linux (64-bit and 31-bit).


rsync://chic.casita.net/opt/gnucobol-3.2/

-- R; <><


On 3/16/24 15:36, Mark Jacobs wrote:

GnuCOBOL "has reached an industrial maturity and can compete with proprietary offers 
in all environments," boasted contributor Fabrice Le Fessant, in a FOSDEM talk.

https://thenewstack.io/20-years-in-the-making-gnucobol-is-ready-for-industry/

Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.

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

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


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

Re: Mainframer Lunch

[Rick Troth]

Do Ohioans count?
I'm outside of Dayton and surprisingly close to the state line.

-- R; <><


On 3/12/24 22:41,   wrote:


Hey,
I would like to have a LUNCH get together with any mainframer's in the 
Indianapolis Indiana area.
Maybe once a month?  If interested, let me know  ming...@prodigy.net
David Mingee
317 903-9455
Thanks

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


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

Re: IBM Announces the z/OS Container Platform

[Rick Troth]

For clarity, start with "chroot" or "change root".
Unix has had thechroot() function and the 'chroot' command since before 
my time, thus POSIX and Linux have it too.
Within a changed root environment, the process or program can only "see" 
files from the new root directory on down.
The hardware architecture and the operating system (ABI or application 
binary interface) remain the same.


The downside to this (or maybe the upside, depending on what you need) 
is that programs running under 'chroot' "see" the same network stack and 
devices. They also "see" other processes (and can signal them).
I used to say that 'chroot' was the closest thing Unix had to a virtual 
machine. It's fantastic for development, and often useful for security.

But then came containers.

Containers are like "chroot on steroids". Processes running in a 
container have the "root" indicated, but also have their own unique 
_network address_ and a private _process space_. The advantage is 
sharing of the kernel (or nucleus); no need to intercept I/O or 
virtualize devices.
The hardware architecture and the operating system (ABI or application 
binary interface) remain the same.


A container hosted by Linux is a Linux environment. A container hosted 
by Slolaris is a Slolaris environment. A container (called a "jail") 
hosted by FreeBSD* is a FreeBSD environment.
_Presumably a container hosted by z/OS (USS) is a z/OS (USS) 
environment,_ but the sales pitches are perhaps vague. (It's also 
possible that I'm just dense! I concede.)


So ... Timothy ... please speak it plainly for slowpokes like me.
*What exactly are these various offerings? *

Thanks!

*FreeBSD (or possibly one of the other BSDs) was first with this, by the 
way. They call it a "jail".


-- R; <><




On 3/6/24 08:04, Matt Hogstrom wrote:

At Broadcom we announced support for K8s deployments of what I call the 
surround z/OS software deployment.   Internally we’ve tested deployments on 
x86, zLinux and zCX with the latter two using OCP.

Its called WatchTower and leverages public REST APIs across the on z/OS and off 
z/OS products.   K8s makes deployment,management and upgrades so much easier.

We started with x86 as most Z shops are not ready on zLinux or zCX   Cant wait 
for that though.

Matt Hogstrom
PGP key 0F143BC1


On Mar 6, 2024, at 07:48, Jousma, 
David<01a0403c5dc1-dmarc-requ...@listserv.ua.edu>  wrote:

Timothy,

I’ll wait to see more information as it becomes available.   So zCX is Ubuntu 
Linux on z/OS, IBM has labelled Redhat Openshift as zCX-OCP, and now we have 
zOSCP.   I like the container Ideas, but this literally sounds like z/OS Unix 
inside a container?   I guess that surprises me, as I don’t hear about people 
actively coding in z/OS Unix.   Or is this something else?

BTW, I am a big proponent of ZCX, and would like to see IBM move its ancillary 
mainframe support software into a docker container.   I know TWS DWC, Omegamon 
TEPS, and others are moving that way.   Just waiting for more to come. We 
are also running Rocker Terminal Emulator Webedition in ZCX to replace all of 
our desktop out-of-date Bluezone implementations.

Dave Jousma
Vice President | Director, Technology Engineering


From: IBM Mainframe Discussion List  on behalf of Timothy 
Sipples
Date: Tuesday, March 5, 2024 at 8:46 PM
To:IBM-MAIN@LISTSERV.UA.EDU  
Subject: IBM Announces the z/OS Container Platform
I’d like to draw your attention to this IBM announcement: https: //urldefense. 
com/v3/__https: //www. ibm. 
com/docs/en/announcements/zos-container-platform-delivers-industry-standard-cloud-technologies-build-run-zos-unix-applications-as-containers-natively-zos__;!!MwwqYLOC6b6whF7V!g9jgcYA166VI9yCFuvhNkTfHy8dDjgaHN__msC1njoKwcSod3-qptPTbiM-TB68jc0uSWrpixIKdSvtHkw$


I’d like to draw your attention to this IBM announcement:

Re: UFT and NJE

[Rick Troth]

I forgot the link to the project ...

*https://github.com/trothr/uft/*

-- R; <><




On 2/28/24 18:01, Rick Troth wrote:


A friend and I were recently talking about NJE over IP (specifically 
FUNet NJE) and I mentioned UFT.
He had not known about UFT and seemed very interested. It has been 
around for years, and sometimes gets interest again. So I thought I 
should mention it here.


UFT is "unsolicited file transfer". In context, "unsolicited" means 
that you didn't go out and get or fetch the file. It came to you. 
(Trying to avoid things which conjure images of spam. It does *not* 
mean "unwanted".)
It's functionally equivalent to NJE except that it doesn't use 
proprietary protocols and (significantly) it does not require another 
topology. It rides on the public internet. The protocol is easy.


Another acronym is SIFT for "sender-initiated file transfer", but I've 
always used SIFT to mean an email variant (where the spool space 
attributes are in X- headers, which we see from time to time).
But UFT itself was created to *avoid* having to attach files to email. 
It's like FedEx or UPS or DHL compared to postal/correspondence.


I have a guest CMS account and recently backed-up my 191 using CMS Tar 
and UFT. Handy! I was also tinkering with 'sf' (sendfile) on Linux for 
my friend.
The following is 'rls' output (sorta like 'rdrlist' but command line, 
not TUI, so more like 'q rdr') with files from a mixture of sources,
just to show how the files look on a Unix/Linux/POSIX system. (On z/VM 
they're just spool files, nuthin new there.)



*$ rls*
*A-   1 -    rijndael    48552 Jan 25 10:02 0001 
uft-1.10.1.tar.gz*
*I-   1 -    rijndael    48354 Jan 25 10:03 0002 
uft-1.10.1.tar.gz*

*I-   1 -    c-73-121    11406 Jan 25 11:26 0003*
*A-   1 -    c-73-121    11419 Jan 25 11:32 0004*
*A-   1 -    c-73-121    11372 Jan 25 14:29 0005*
*A-   1 -    localhos  780 Jan 25 14:30 0006*
*I-   1 -    rijndael   529780 Feb 06 17:33 0007 sf*
*A-   1 -    freebsd1    11459 Feb 07 10:41 0008 makefile*
*N-   1 -    148-100-    11817 Feb 28 16:15 0009 TCPIP.DATA*
*A-   1 -    148-100-    11539 Feb 28 16:16 0010 TCPIP.DATA*
*I-   1 -    148-100-  1887232 Feb 28 16:26 0011*
*N-   1 -    148-100-  575 Feb 28 17:06 0012 TROTHR.NAMES*

The above list is supposed to be sorta like 'ls' output, but the left 
end is A for text files, I for binary (image), and N for netdata.

Notice that files always have a spool ID, but they might not have a name.

I'd really like to do more with NJE over IP, but I'd also like to see 
more UFT action.
There's a GitHub project for it. If anyone is interested, check it 
out. If you find bugs, let me know (and/or open an "issue").



-- R; <><







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

UFT and NJE

[Rick Troth]

A friend and I were recently talking about NJE over IP (specifically 
FUNet NJE) and I mentioned UFT.
He had not known about UFT and seemed very interested. It has been 
around for years, and sometimes gets interest again. So I thought I 
should mention it here.


UFT is "unsolicited file transfer". In context, "unsolicited" means that 
you didn't go out and get or fetch the file. It came to you. (Trying to 
avoid things which conjure images of spam. It does *not* mean "unwanted".)
It's functionally equivalent to NJE except that it doesn't use 
proprietary protocols and (significantly) it does not require another 
topology. It rides on the public internet. The protocol is easy.


Another acronym is SIFT for "sender-initiated file transfer", but I've 
always used SIFT to mean an email variant (where the spool space 
attributes are in X- headers, which we see from time to time).
But UFT itself was created to *avoid* having to attach files to email. 
It's like FedEx or UPS or DHL compared to postal/correspondence.


I have a guest CMS account and recently backed-up my 191 using CMS Tar 
and UFT. Handy! I was also tinkering with 'sf' (sendfile) on Linux for 
my friend.
The following is 'rls' output (sorta like 'rdrlist' but command line, 
not TUI, so more like 'q rdr') with files from a mixture of sources,
just to show how the files look on a Unix/Linux/POSIX system. (On z/VM 
they're just spool files, nuthin new there.)



*$ rls*
*A-   1 -    rijndael    48552 Jan 25 10:02 0001 
uft-1.10.1.tar.gz*
*I-   1 -    rijndael    48354 Jan 25 10:03 0002 
uft-1.10.1.tar.gz*

*I-   1 -    c-73-121    11406 Jan 25 11:26 0003*
*A-   1 -    c-73-121    11419 Jan 25 11:32 0004*
*A-   1 -    c-73-121    11372 Jan 25 14:29 0005*
*A-   1 -    localhos  780 Jan 25 14:30 0006*
*I-   1 -    rijndael   529780 Feb 06 17:33 0007 sf*
*A-   1 -    freebsd1    11459 Feb 07 10:41 0008 makefile*
*N-   1 -    148-100-    11817 Feb 28 16:15 0009 TCPIP.DATA*
*A-   1 -    148-100-    11539 Feb 28 16:16 0010 TCPIP.DATA*
*I-   1 -    148-100-  1887232 Feb 28 16:26 0011*
*N-   1 -    148-100-  575 Feb 28 17:06 0012 TROTHR.NAMES*

The above list is supposed to be sorta like 'ls' output, but the left 
end is A for text files, I for binary (image), and N for netdata.

Notice that files always have a spool ID, but they might not have a name.

I'd really like to do more with NJE over IP, but I'd also like to see 
more UFT action.
There's a GitHub project for it. If anyone is interested, check it out. 
If you find bugs, let me know (and/or open an "issue").



-- R; <><





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

Re: zsh for z/OS

[Rick Troth]

For scripting, most recommend Bourne-compatible, which includes BASH, 
ZSH, DASH, and [PD]KSH.
In my experience, when you stick with a certain subset of what these all 
do you'll be "safe" and your scripts will not break if/when you carry 
them around.
I have tried to distill some of the lessons learned in recent years into 
a "best practice" doc.


https://github.com/trothr/best/blob/main/Shell.md

We talked briefly here about profiling. Easiest way to have consistent 
profiling is to *not* use the shell-specific variants.
(For example, if your login shell is BASH, then use ~/.profile and avoid 
~/.bash_profile.)

I really need to add this info to that page.

Some people like CSH for interactive work, for which there is TCSH in 
open source land. But CSH variants are *not* recommended for scripting.


Coming to closure, I have recently built the following for the Chicory 
project:


 * bash-5.2.21
 * zsh-5.9
 * dash-0.5.12
 * pdksh-5.2.14
 * tcsh-6.24.10


I don't have access to a USS environment which I'm free to use for 
public things, so I don't have any of these built for MVS.
The platforms I *do* have include: Linux-i386, Linux-x86_64, Linux-s390, 
Linux-s390x, Linux-arm, FreeBSD-amd64, SunOS-i386, SunOS-x86_64.
You can find most of them under rsync://chic.casita.net/opt. (If they're 
not there now, they should be in the next 24 hours.)


I hope this helps.

-- R; <><


On 2/19/24 14:31, Pew, Curtis G wrote:

On Feb 17, 2024, at 11:00 AM, Paul 
Gilmartin<042bfe9c879d-dmarc-requ...@listserv.ua.edu>  wrote:

What are the benefits of zsh?  Are there incompatibilities?

I largely stay with POSIX shell for portability of scripts and skills.

Apple switched to zsh because newer versions of bash are covered by the GPLv3 
license, which is less corporate-friendly than the older GPLv2. I would assume 
that IBM has similar motivation.

If you’re still seeing bash on a Mac that probably means you started using it 
before the switch. It’s been a while, but when they switched the default I had 
to do something (probably in Terminal) to get it to switch for me. (It used to 
prompt you to switch if you opened with a bash shell.) There’s still bash 
available on MacOS, but it’s a rather old version, 3.2.57 while the current 
stable release is 5.2.21.


--
Curtis Pew
ITS Campus Solutions
curtis@austin.utexas.edu




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



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

Re: Banks migrate from mainframes to AI-driven cloud tech

[Rick Troth]

On 2/10/24 19:54, Phil Smith III wrote:

Bob Bridges wrote:

"...where mainframes' resilience meets the agility of cloud computing."
What is the "agility" of the cloud, exactly?

The ability to spin up more instances [of applications that are built that way, 
obviously] on demand/automatically. For certain very peaky workloads this is a 
huge win. Not that I'm in any way arguing that these are important applications 
in the real world, but things like Pinterest and Instagram at least started 
this way in AWS or GCP, still use the model (albeit presumably on their own 
cloud now): when something big happens and usage blows up, instead of just 
getting dog-slow or crashing, more instances get spun up and things hum along.

Yes, there are a ton of assumptions involved there-capacity/competence/security/etc. of 
the cloud provider. I'm very chary of public cloud for "real work" for this 
reason. But if you look at it at the right angle (perhaps squinting a lot!), you can see 
that-again, for the right workloads-it gets you out of the business of 
provisioning/capacity management/etc. Of course it also encourages inefficient code, but 
?maybe? that's OK (again, in the right use cases).

One of the biggest problems, of course, is that folks don't understand the 
caveats, go in with both feet first, and get burned. All of the CSPs, for 
example, offer some sort of cryptographic service. None of them are BYOK (Bring 
Your Own Key)-in other words, you're trusting the service itself not to attack 
you or to get compromised and allow an attack. WCGW?

For software vendors, the attraction is that they don't have to build/manage as 
much of the platform as they do when they provide a fully functional server. 
All that really does is move that requirement from the vendor (once) to each 
customer, ...



kick the can



  ... so it's a win for the vendor and a loss for the customer. That is, the 
customer has to do all the vulnerability scanning, patching, etc., instead of 
having the vendor do the heavy lifting (the wise customer does the scanning 
anyway, but then expects the vendor to provide the updates.) I keep waiting for 
the customer world to figure this out; hasn't happened yet AFAICT. Weird.


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



This BYOK thing ... what a concept!


-- R; <><

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

Re: DMARC failure in messages from this listserv

[Rick Troth]

> Last, but not least: for regular mailing I use Thunderbird. But for 
"un-spamming" I have to use web browser interface.


Same here:
This is a GMail account, and TBird works well, but the logic to tell 
GMail "this is not spam" is only via their web interface.


The problem is not (or is not entirely) a fault of LISTSERV nor of UA 
email.
The university provides this forum as a free service to the mainframe 
community.
But the point I want to make in this paragraph is: it's an arms race. 
Worse, it's getting more and more difficult for anything outside the 
space of what Google and Hotmail and Yahoo understand (and control) to 
engage in email. This is a driving factor in the migration of some of us 
(Lionel raised his hand weeks ago) to platforms such as Discord.


For my part, I'm interested in peering with sites which don't have an 
allergy to LISTSERV and things like it.
One thing I would ask the list manager(s): allow attachments. I could 
sign every message with PGP if only LISTSERV would not reject such posts.


-- R; <><


On 2/15/24 07:53, Radoslaw Skorupka wrote:
I am using Microsoft mail account (hotmail) and I observe similar 
problem. Many messages are sent to "unwanted" folder.
I don't know how to add IBM-MAIN to safe senders. The only thing I can 
do is manually add each address, message by message.
However it is not effective - a lot of manual work. I doubt MS service 
honour my requests.
Last, but not least: for regular mailing I use Thunderbird. But for 
"un-spamming" I have to use web browser interface.


BTW: I use this mail account almost only for IBM-MAIN and RACF-L.



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

Re: zsh for z/OS

[Rick Troth]

On 2/19/24 15:09, Paul Gilmartin wrote:

On Mon, 19 Feb 2024 19:31:11 +, Pew, Curtis G wrote:

If you’re still seeing bash on a Mac that probably means you started using it 
before the switch. It’s been a while, but when they switched the default I had 
to do something (probably in Terminal) to get it to switch for me. (It used to 
prompt you to switch if you opened with a bash shell.) There’s still bash 
available on MacOS, but it’s a rather old version, 3.2.57 while the current 
stable release is 5.2.21.


1377 $ bash --version
GNU bash, version 5.2.26(1)-release (x86_64-apple-darwin21.6.0)


 ...


I'd like to know where the source code is for BASH 5.2.26. Best I could 
find today was/is 5.2.21, which is dated November so is kinda current.


Talk to me, Gil. Where'd you get that? Brew? Who's behind that 
particular build? (I mean, did they put their names on it? Did they 
provide contact info?)

Thanks.


-- R; <><




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

BASH bug w/r/t external links

[Rick Troth]

On 2/16/24 15:32, Frank Swarbrick wrote:

In bash, only 'onetstat' works.  I think that bash under z/OS is unable
to follow executables with the 'e' file type (external link).



Turns out that someone has addressed this.

https://github.com/ZOSOpenTools/bashport/blob/main/stable-patches/findcmd.c.patch

It's likely that whatever source was used for building the BASH Frank 
has (others too) simply does not have this patch.


I'm not sure how to utilize the "ports" other than to manually apply 
each patch individually. I have not been able to get email addresses for 
the contributors to the "ZOSOpenTools" project. (And wanted to for other 
reasons.) Maybe that's exactly how they do it, each patch one at a time.



-- R; <><




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

Re: zsh for z/OS

[Rick Troth]

EXCELLENT work, Frank, and THANKS for sharing your findings.

I say you've found a BASH bug.
I can IMAGINE how/why BASH is failing on external links, but it doesn't 
matter. The point is: IT FAILS and it should not.

Great catch!

I'd be happy to help chase down a resolution, if we can simply get BASH 
developers (and/or those porting it to z/OS) to join in.


More in a follow-up note.

-- R; <><


On 2/19/24 14:50, Frank Swarbrick wrote:

If you are referring to the setting of $PATH during logon, or just invoking a 
shell, my PATH includes the directory in which both netstat and onetstat reside 
(/bin).  See the following tests:


(base) [bash] DVFJS@ZOSD ~ $ printenv PATH

/u/dvfjs/golang/bin:/u/dvfjs/miniconda/bin:/u/dvfjs/miniconda/condabin:/u/dvfjs/bin:/bin:/usr/sbin:/usr/lpp/java/J8.0_64/bin:/_PRDS/PYTHON/SCYPH311/pyz/bin:.

(base) [bash] DVFJS@ZOSD ~ $ printenv SHELL

/u/dvfjs/miniconda/bin/bash

(base) [bash] DVFJS@ZOSD ~ $ onetstat -P 1234

MVS TCP/IP NETSTAT CS V2R5   TCPIP Name: TCPIP   12:21:49

User Id  Conn Local Socket   Foreign Socket State

---      -- -

CICSDEVD 0016A155 0.0.0.0..1234  0.0.0.0..0 Listen

(base) [bash] DVFJS@ZOSD ~ $ which onetstat

/bin/onetstat

(base) [bash] DVFJS@ZOSD ~ $ netstat -P 1234

bash: netstat: command not found

(base) [bash] DVFJS@ZOSD ~ $ which netstat

which: no netstat in 
(/u/dvfjs/golang/bin:/u/dvfjs/miniconda/bin:/u/dvfjs/miniconda/condabin:/u/dvfjs/bin:/bin:/usr/sbin:/usr/lpp/java/J8.0_64/bin:/_PRDS/PYTHON/SCYPH311/pyz/bin:.)


[Note that the ls -F option "Puts a / after each directory name, a * after every 
executable file, a | after every FIFO file, a @ after every symbolic link, and a = after 
every socket. It also puts an & character after an external link name."]

(base) [bash] DVFJS@ZOSD ~ $ ls -Fl /bin/netstat /bin/onetstat

erwxrwxrwx   1 BPXROOT  OMVSGRP8 Jun  1  2021 /bin/netstat& -> ONETSTAT

lrwxrwxrwx   1 BPXROOT  OMVSGRP   29 Jun  1  2021 /bin/onetstat@ -> 
../usr/lpp/tcpip/bin/onetstat

(base) [bash] DVFJS@ZOSD ~ $ ls -Fl /bin/ | grep '&'

erwxrwxrwx   1 BPXROOT  OMVSGRP8 Jun  1  2021 ezbzcmcs& -> EZBZCMCS

erwxrwxrwx   1 BPXROOT  OMVSGRP8 Jun  1  2021 makedepend& -> CCNEMDEP

erwxrwxrwx   1 BPXROOT  OMVSGRP8 Jun  1  2021 netstat& -> ONETSTAT

erwxrwxrwx   1 BPXROOT  OMVSGRP5 Jun  1  2021 ping& -> OPING

erwxrwxrwx   1 BPXROOT  OMVSGRP8 Jun  1  2021 portmap& -> OPORTMAP

erwxrwxrwx   1 BPXROOT  OMVSGRP6 Jun  1  2021 rexec& -> OREXEC

erwxrwxrwx   1 BPXROOT  OMVSGRP7 Jun  1  2021 rpcgen& -> ORPCGEN

erwxrwxrwx   1 BPXROOT  OMVSGRP8 Jun  1  2021 rpcinfo& -> ORPCINFO

erwxrwxrwx   1 BPXROOT  OMVSGRP4 Jun  1  2021 rsh& -> ORSH

erwxrwxrwx   1 BPXROOT  OMVSGRP5 Jun  1  2021 snmp& -> OSNMP

erwxrwxrwx   1 BPXROOT  OMVSGRP6 Jun  1  2021 sosinfo& -> CDASOS

erwxrwxrwx   1 BPXROOT  OMVSGRP8 Jun  1  2021 traceroute& -> OTRACERT

(base) [bash] DVFJS@ZOSD ~ $ ping

bash: ping: command not found

(base) [bash] DVFJS@ZOSD ~ $ rpcinfo

bash: rpcinfo: command not found

(base) [bash] DVFJS@ZOSD ~ $ sosinfo

bash: sosinfo: command not found

(base) [bash] DVFJS@ZOSD ~ $ traceroute

bash: traceroute: command not found

(base) [bash] DVFJS@ZOSD ~ $ /bin/netstat -P 1234

MVS TCP/IP NETSTAT CS V2R5   TCPIP Name: TCPIP   12:47:43

User Id  Conn Local Socket   Foreign Socket State

---      -- -

CICSDEVD 0016A155 0.0.0.0..1234  0.0.0.0..0 Listen


Thus my "guess" that in bash (but not in sh or tcsh) the file names that are 
external links are not found (unless the directory is explicitly specified.

Try it yourself (if you have bash available).


From: IBM Mainframe Discussion List  on behalf of Rick 
Troth <058ff5c2d0a7-dmarc-requ...@listserv.ua.edu>
Sent: Monday, February 19, 2024 6:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: zsh for z/OS

Check your PATH environment variable.
If the directory where 'netstat' resides is not in your PATH, then
you'll get "command not found".
There's nothing about BASH or ZSH which would preclude 'netstat' or
'onetstat' from working.

One of the [un]fortunate things about the myriad command shells
available is that most have their own unique way of profiling. (Though
most *can* follow the original rules.)
That is, if you have $HOME/.bash_profile, and BASH is your login shell,
it will get sourced when you log-on rather than $HOME/.profile.
You very possibly have different profiling for BASH, ZSH, and stock
/bin/sh.
As a rule, I either remove $HOME/.bash_profile or make it a sym-link to
$HOME/.profile.

I do use ZSH,

Re: zsh for z/OS

[Rick Troth]

On 2/16/24 14:48, Ed Jaffe wrote:

On 2/16/2024 11:33 AM, Frank Swarbrick wrote:
z/OS 3.1 added the Z Shell, zsh.  Is anyone using it?  How do you 
like it.  What interesting features does it have over bash?


I'm only at 2.5, so can't use it.


I am using it. After all, what self-respecting z/OS advocate doesn't 
want to use a shell called Z?



indeed! : - )




I'm not a power user. Not doing anything I couldn't also do in bash...



I use BASH almost exclusively for interactive work, mostly because of 
the nifty command retrieval feature. But ZSH has the same thing. Cool!
After Martin mentioned Mac, I logged into my nearest Mac and found my 
logon shell set to BASH. But ZSH is there. (As long as my retrieve key 
works, I don't notice which shell I get by default.)


WARNING: recommend that you *not* use particular shells when scripting. 
That is, start your scripts with #!/bin/sh (rather than #!/bin/zsh or 
#!/bin/bash).
If you need features of a particular shell, there is a better way to 
indicate that.


For more info about ZSH, see the Wikipedia page.

https://en.wikipedia.org/wiki/Z_shell

The "Z" is arbitrary and (sadly) has nothing to do with our systems. 
(Unless IBM snuck something in.)


I maintain pre-compiled copies of ZSH, BASH, [PD]KSH, and DASH for 
several platforms as part of the Chicory collection. (But have not been 
able to brew much Chicory on z/OS lately. Wanna help?)


Another popular shell is TCSH (also in Chicory), but it's a C-shell 
variant. The others are all Bourne compatible, which many consider a 
requirement (at least for scripting).


I have cluttered this thread enough already. I'll say more about 
profiling and shell selection in another note.



-- R; <><

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

Re: zsh for z/OS

[Rick Troth]

The function of external links is a feature of the system.
Whether or not external links are executable really SHOULD NOT depend on 
which shell you run.


That would be like .lnk files on Windoze. They only work when you're in 
a file browser, not when you're in a command window. Bad bad bad bad bad.


Personally, I've seen and used "external links" for more than 20 years 
and never encountered shell dependency.


-- R; <><


On 2/16/24 16:35, Frank Swarbrick wrote:

Interesting.  So it looks like (just guessing!) bash isn't able to find 
external links when following the PATH.  Or something.

Frank

From: IBM Mainframe Discussion List  on behalf of Michael 
Babcock <05ad4e2d7232-dmarc-requ...@listserv.ua.edu>
Sent: Friday, February 16, 2024 1:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: zsh for z/OS

I can also cd into the bin directory and issue ./netstat and it works.

On Fri, Feb 16, 2024 at 2:33 PM Frank Swarbrick 
wrote:


Here's a bit of an off the wall question/request.

Do both 'netstat' and 'onetstat' work in zsh?

In bash, only 'onetstat' works.  I think that bash under z/OS is unable to
follow executables with the 'e' file type (external link).


ls -FalTHp /bin/netstat /bin/onetstat

 erwxrwxrwx 1 BPXROOT  OMVSGRP8 Jun  1
2021 /bin/netstat -> ONETSTAT

 lrwxrwxrwx 1 BPXROOT  OMVSGRP   29 Jun  1
2021 /bin/onetstat -> ../usr/lpp/tcpip/bin/onetstat

Frank


From: IBM Mainframe Discussion List  on behalf
of Ed Jaffe <05acc3c79bf7-dmarc-requ...@listserv.ua.edu>
Sent: Friday, February 16, 2024 12:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: zsh for z/OS

On 2/16/2024 11:33 AM, Frank Swarbrick wrote:

z/OS 3.1 added the Z Shell, zsh.  Is anyone using it?  How do you like

it.  What interesting features does it have over bash?

I'm only at 2.5, so can't use it.

I am using it. After all, what self-respecting z/OS advocate doesn't
want to use a shell called Z?

I'm not a power user. Not doing anything I couldn't also do in bash...

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




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

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

--
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: zsh for z/OS

[Rick Troth]

On 2/16/24 15:51, Ed Jaffe wrote:

On 2/16/2024 12:32 PM, Frank Swarbrick wrote:

Here's a bit of an off the wall question/request.

Do both 'netstat' and 'onetstat' work in zsh?

In bash, only 'onetstat' works.  I think that bash under z/OS is 
unable to follow executables with the 'e' file type (external link).


Just tried. Both work in Zsh.



It's not the shell.
It's the profiling.


-- R; <><

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

Re: zsh for z/OS

[Rick Troth]

Check your PATH environment variable.
If the directory where 'netstat' resides is not in your PATH, then 
you'll get "command not found".
There's nothing about BASH or ZSH which would preclude 'netstat' or 
'onetstat' from working.


One of the [un]fortunate things about the myriad command shells 
available is that most have their own unique way of profiling. (Though 
most *can* follow the original rules.)
That is, if you have $HOME/.bash_profile, and BASH is your login shell, 
it will get sourced when you log-on rather than $HOME/.profile.
You very possibly have different profiling for BASH, ZSH, and stock 
/bin/sh.
As a rule, I either remove $HOME/.bash_profile or make it a sym-link to 
$HOME/.profile.


I do use ZSH, but less often, so am less familiar with how it works on 
this point.


ORIGINALLY, /etc/profile gets sourced when you log-on. If you then also 
have $HOME/.profile, it gets sourced afterward (so you can override 
system profiling with your own customizations).


A related thing is "RC files", like $HOME/.bashrc. The "RC files" get 
sourced *every* time a shell is spawned, not just when you log-on.
Many newcomers to Unix/Linux/POSIX don't know the difference between the 
profiles and the RC files, so they throw all of the profiling into 
(e.g.) $HOME/.bashrc. It's kinda counter-productive. The RC files are 
for settings which cannot be "inherited" for one reason or another.


It gets worse with graphical logon. (But need not! Just that nobody 
bothered to set things right for the graphical logon logic.)


Keep it simple and stick with the standards. Avoid shiny things and 
feechers which cause konfoozhun.


-- R; <><


On 2/16/24 15:48, Michael Babcock wrote:

According to the man page for netstat, it’s a synonym for onetstat.
Issuing netstat in bash 5.2 says command not found.   It may be a moot
point if it’s truly a synonym.

On Fri, Feb 16, 2024 at 2:33 PM Frank Swarbrick 
wrote:


Here's a bit of an off the wall question/request.

Do both 'netstat' and 'onetstat' work in zsh?

In bash, only 'onetstat' works.  I think that bash under z/OS is unable to
follow executables with the 'e' file type (external link).


ls -FalTHp /bin/netstat /bin/onetstat

 erwxrwxrwx 1 BPXROOT  OMVSGRP8 Jun  1
2021 /bin/netstat -> ONETSTAT

 lrwxrwxrwx 1 BPXROOT  OMVSGRP   29 Jun  1
2021 /bin/onetstat -> ../usr/lpp/tcpip/bin/onetstat

Frank


From: IBM Mainframe Discussion List  on behalf
of Ed Jaffe <05acc3c79bf7-dmarc-requ...@listserv.ua.edu>
Sent: Friday, February 16, 2024 12:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: zsh for z/OS

On 2/16/2024 11:33 AM, Frank Swarbrick wrote:

z/OS 3.1 added the Z Shell, zsh.  Is anyone using it?  How do you like

it.  What interesting features does it have over bash?

I'm only at 2.5, so can't use it.

I am using it. After all, what self-respecting z/OS advocate doesn't
want to use a shell called Z?

I'm not a power user. Not doing anything I couldn't also do in bash...

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




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

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

--
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: Query - do you have access to GitHub from your z/OS system? And do you have git on your z/OS system?

[Rick Troth]

I previously used CVS and then Subversion. About ten years ago I was 
introduced to Git and have come to prefer it.


Q:    1. Do you have access to GitHub from your z/OS system?

A: yes*

In two recent roles, my team used an internal GitHub server.
Personally I use GitHub.com (heavily) and GItLab.com (somewhat less).
I coulda/woulda/shoulda argued for access to the external servers, but 
see below about security.


Q:    2. Do you have git installed on your z/OS system?

A: no

(And this is the asterisk on "yes" above.)
In both roles where I have used GitHub internally, we did not have Git 
installed on z/OS.
That could change, but there remains some resistance to using free/libre 
open source software directly.
We may or may not have had IP connectivity to the outside servers. (We 
*did* have IP connectivity to the inside servers.)


The primary source of resistance is FUD. (And as a security 
professional, I will again say, we protect the wrong things.) But there 
is also legitimate concern over the supply chain. (The Chicory project 
is one of many means to have a solid FLOSS supply chain.)


Aside: we see the increasing use of code signing.
I recommend simple PGP signing of downloadable archives (e.g., TAR files 
or PAX files or similar).
This is not to say that we cannot also use PKI based code signing, but 
PKI requires third parties and introduces A LOT more moving parts. BT/DT
So I recommend PGP signatures for starters. With an appropriate 
web-of-trust PGP is more than sufficient. PKI is not cryptographically 
any stronger and has more third party risk.
(This can lead to heated discussion. Apologies for drifting away from 
Lionel's question. But it becomes important sooner than later.)


But there are other means of incorporating Git into the z/OS development 
cycle.
In both of the roles that I mention, we *did* have SSH, and that 
included SCP/SFTP, so we had a secure way of copying files between z/OS 
and development workstations.
So there's no reason to *not* use Git with z/OS even if you cannot 
install 'git' directly.


I hope this helps.


-- R; <><


On 2/14/24 09:20, Lionel B. Dyck wrote:

As part of the z/OS Open Tools project I'm asking if your z/OS system has
access to GitHub. The reason for this question is that IBM, ISVs, and
open-source developers are increasingly using GitHub.

Questions:

1. Do you have access to GitHub from your z/OS system?
2. Do you have git installed on your z/OS system?

Thank you


Lionel B. Dyck <><
Github:https://github.com/lbdyck
System Z Enthusiasts Discord:
https://discord.gg/system-z-enthusiasts-880322471608344597

“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 tolists...@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

TPF job lead for those interested

[Rick Troth]

friends --

If any of you are looking for work and are comfortable with z/TPF and 
related systems, drop me a note off-list, either to this address or to 
r...@casita.net.


-- Rick; <><





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

Re: Question

[Rick Troth]

The closest standard is Python's "ctypes".
Now ... some of the guides I have read say that CTYPES only works with 
C, but I've found that (within limits) LE calling convention works well 
with other languages, not just C.


In a previous life, I was able to call C from Python (the point being 
"to call /native/") without any special rigging other than CTYPES 
(included w Python).


-- R; <><


On 2/7/24 12:32, Lionel B. Dyck wrote:

Add to that question how does the z/OS Open Tools port of python compare to
Rockets and to the IBM Open Enterprise SDK?


Lionel B. Dyck <><
Github:https://github.com/lbdyck
System Z Enthusiasts Discord:
https://discord.gg/system-z-enthusiasts-880322471608344597

“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
Frank Swarbrick
Sent: Wednesday, February 7, 2024 11:30 AM
To:IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question

So here's a curious question.  Are IBM Open Enterprise SDK for Python and
the Python from Rocket Software basically the same, or no?

Frank

From: IBM Mainframe Discussion List  on behalf of
Peter Sylvester
Sent: Tuesday, February 6, 2024 11:15 PM
To:IBM-MAIN@LISTSERV.UA.EDU  
Subject: Re: Question

Yes,  from the IBM pax installation. And a bit of pipifax. :-)

Python 3.12.0 (heads/pyz_dev-3.12:ef647e3673, Oct 31 2023, 19:02:59) [Clang
14.0.0 (build 1465bdb)] on zos On 06/02/2024 19:47, Ed Jaffe wrote:

Yes.

: >python
Python 3.11.4 (heads/pyz_dev-3.11.ziip:39640ccf4b, Jul 15 2023,
05:46:13) [Clang 14.0.0 ] on zos Type "help", "copyright", "credits"
or "license" for more information
On 2/6/2024 10:15 AM, Steve Beaver wrote:

Does anyone have Python installed in your shop?


Steve



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

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

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



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

Re: Encryption and decryption - processor or TCPIP

[Rick Troth]

Nicely put.

> Symmetric or "secret key" encryption is probably what you think of 
when you think of encryption.
> You encrypt and decrypt with the same secret key, just like when you 
passed coded notes in grade school.
> It is a part of almost everything where encryption is involved. It is 
slow as things go, but it is relatively fast compared to ...


You nailed the description, but I recommend *not* calling it "secret 
key" encryption because in asymmetric there is a /secret/ key. (Call it 
the /private/ key. But some still call it the secret key.)
A better term might be "/single/ key encryption" because there is only 
one key. It's like a house key: it both locks and unlocks. (Or like 
coded notes in grade school, yep.)
Symmetric is more accurate, but not a term lay people use. (But we could 
... uhh ... school them.) *:-)*


Also ... spot on about key distribution problems.
Some of us in VM land have started tinkering with a trust anchor.

Absolutely right about that "random secret key".
Better term there is /session/ key. All our current crypto combines 
asymmetric (for trust) with symmetric (for speed): TLS/SSL (call it 
PKI), SSH, PGP/GPG.


-- R; <><


On 1/25/24 16:28, Charles Mills wrote:

I'm trying to put this in my own words. I'm not an expert on Z crypto 
architecture, but I am sure someone will correct me if I am wrong.

The CPACF instructions are like the TRT instruction. You *could* do what TRT 
does with a loop using IC and compare and so forth, but the TRT instruction is 
much faster. It's a relatively slow instruction as instructions go, while still 
much faster than a loop. But it's a machine instruction. The CPU is busy and 
running up CPU time for the task the whole time that TRT takes. The same for 
CPACF instructions: faster than a loop, but still machine instructions that 
consume CPU time.

The crypto cards are a little like a DASD drive. The control program can say "go do this" 
and then suspend the task in question and go do other things or go into a wait state. The task 
accrues no CPU time while the crypto card is doing its thing, much the way it accrues no CPU time 
while the DASD does its thing. Like DASD, when the crypto card completes its operation, it comes 
back to the control program and says "I'm done, here is your result." The task resumes 
executing, presumably using the results of the crypto operation. The function is overall faster 
than a loop, and way more economical in terms of CPU time.

A little encryption background:

Symmetric or "secret key" encryption is probably what you think of when you 
think of encryption. You encrypt and decrypt with the same secret key, just like when you 
passed coded notes in grade school. It is a part of almost everything where encryption is 
involved. It is slow as things go, but it is relatively fast compared to

Asymmetric or "public key" encryption. The big problem with symmetric encryption is "how do you deliver 
that secret key to the other end of the line?" For DASD encryption, that is not an issue, because both "ends 
of the line" are right there on your machine. But for communication situations, where the other end is far away 
and there is no secure path (until you have the encryption set up) and thus no way to deliver that secret key to the 
other end, other than a guy on a plane with a briefcase padlocked to his wrist. Asymmetric encryption is like magic! 
You use one key for encryption and a different key for decryption. (The two keys have a complex mathematical 
relationship to each other, and even computing that relationship takes a lot of time.) So you can encode something with 
the other end's completely public public key, and only that other end, that has the corresponding private key, can 
decrypt it! Magic! Problem solved. Except that asymmetric encryption is really, really, really slow. Specialized 
hardware makes it faster, but it is still really, really slow. So how is it usable then in the real world? The answer 
is that you never encrypt "real data" with asymmetric encryption. You make up a random secret key, deliver it 
to the other end using public key (rather than a guy with a briefcase) and then use that random secret key for 
symmetric encryption of the real data.

So symmetric encryption is used for everything, and asymmetric encryption is 
used in addition for things where the other end is remote. (That combo is often 
something called SSL or TLS, and they also make extensive use of our other old 
friends, digital certificates.)

CM

On Thu, 25 Jan 2024 13:01:17 -0600, Alan Altmark  
wrote:


On Wed, 24 Jan 2024 20:15:18 +0400, Peter  wrote:

Still I am trying to understand encryption and decryption load goes to
general CP In case if you don't have CPACF or ICSF ?

There's no such thing as "don't have CPACF".   All machines have it.  It's 
on-chip and part of the instruction set.

The only variable is whether or not the no-charge hardware cryptographic 
feature 3863 is enabled (in countries 

Re: New SSH vulnerability

[Rick Troth]

Allan speaks truth.

Looks like the OpenSSH team addressed the Terrapin attack hot on the 
heels of the CVE ...


https://www.openssh.com/releasenotes.html

(9.6 is discussed at the top of the release notes)

OpenSSH 9.6p1 is in the Chicory collection.
(Was troublesome because of forced upgrades presumably not related to 
CVE-2023-48795, but did eventually build.)
I've got it built for Linux and FreeBSD with more to come. There's a 
z/OS build here ...


https://github.com/ZOSOpenTools/opensshport/releases/download/STABLE_opensshport_1953/openssh-9.6p1.20240109_105141.zos.pax.Z

For more info about the vulnerability, see here ...

https://nvd.nist.gov/vuln/detail/CVE-2023-48795

-- R; <><


On 1/25/24 09:20, Allan Staller wrote:

Classification: Confidential

It does take some time for the fixes to be developed, tested and distributed.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Thursday, January 25, 2024 8:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: New SSH vulnerability

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

Looks like a fairly new SSH vulnerability has surfaced...Anyone figure out a 
local remediation for this yet?   As per usual, IBM is mum.   There is no 
fixing PTF yet based on what I see in ResourceLink.


QID

38913

Severity

HIGH

Definition

SSH Prefix Truncation Vulnerability (Terrapin)

Description

The Terrapin attack exploits weaknesses in the SSH transport layer protocol in 
combination with newer cryptographic algorithms and encryption modes introduced 
by OpenSSH over 10 years ago. Since then, these have been adopted by a wide 
range of SSH implementations, therefore affecting a majority of current 
implementations.





QID Detection Logic (Unauthenticated):



This detection attempts to start the SSH key exchange process and examines 
whether either of the vulnerable ChaCha20-Poly1305 Algorithm or CBC-EtM 
Algorithm is active. It subsequently verifies whether Strict Key Exchange is 
enabled. If a target is identified as vulnerable, it indicates that the target 
supports either of the vulnerable algorithms and lacks support for Strict Key 
Exchange.

Solution

Customers are advised to refer to the individual vendor advisory for their 
operating system and install the patch released by the vendor. For more 
information regarding the vulnerability, please refer to Terrapin Vulnerability



Patch:



Following are links for downloading patches to fix the vulnerabilities:

OpenWall Security Advisory

Impact

Successful exploitation of the vulnerability may allow an attacker to downgrade 
the security of an SSH connection when using SSH extension negotiation. The 
impact in practice heavily depends on the supported extensions. Most commonly, 
this will impact the security of client authentication when using an RSA public 
key.

CVEs

CVE-2023-48795

Results

SSH Prefix Truncation Vulnerability (Terrapin) detected on port: 22

ChaCha20-Poly1305 Algorithm Support: True

CBC-EtM Algorithm Support: False

Strict Key Exchange algorithm enabled: False

EVM Report

Yes

EVM Risk Score

4.9

Host Details

Host

192.168.30.2

IP Address

192.168.30.2

Operating System

IBM OS/390

Tier

T3

FQDN



Port

22

Protocol

tcp




Dave Jousma
Vice President | Director, Technology Engineering





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

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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of 

software updates and supply chain [was: Another Getting away from the mainframe tale]

[Rick Troth]

Off-topic, so I changed the subject line.
And while what follows is not TSO nor batch, it *does* fit in USS space, 
so hopefully I won't get plonked. *:-)*


I've been collecting software in source form for several years. It 
started as a hobby, but lately looks like a supply chain gap-fill.
It's a decent sized body of code. If one is up for running a Linux 
kernel, you can get a fully self-hosting system with a build 
environment, including several important server programs (such as the 
Apache and Nginx web servers).

But a sizable portion compiles and runs just fine on USS.

I would appreciate help finding patches which facilitate the USS build. 
Most packages need minor tweaks for USS, but otherwise fly smoothly. The 
list is here ...


https://github.com/trothr/chicory/blob/master/doc/packages.md

It really chaps when some app stops working, "you must upgrade", not 
exclusive to software-as-a-service.
Sometimes a similar thing happens in open source land: the latest 
OpenSSH required a certain level of OpenSSL that I had trouble with. 
(The authors can expand dependency hell, and sadly sometimes do.)
Mandatory upgrades are usually forced on us in the name of security, but 
I find that the actual risks are not clearly enumerated and some are 
insignificant (and I hold a CISSP cert).


This project naturally tends toward open source.
I want to software, in source form, in my own hot little hands.
Download the source code, KEEP YOUR OWN COPY, be ready to fall-back to 
an older release if needed.


-- R; <><


On 1/22/24 09:19, Bob Bridges wrote:

Getting off-topic, here, but I've never felt the lure of the 365 subscription.  
Maybe it's just because I'm an old fart, but I dislike the idea of using 
software that they can change when THEY want to.  MS Office is the one app I 
shell out real money for whenever I buy a new PC; the rest of the time I'm 
happy using shareware, open software and the like.  But I want the software in 
my own hot little hands, not theirs.

For the same reason I'd still be using POP3 instead of IMAP, if I could.

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

/* The harder I practice, the luckier I get.  -Gary Player */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Thompson
Sent: Monday, January 22, 2024 08:55

Along those lines, if you get an office 365 subscription, bundled into this is 
one-drive. So unless you specifically save documents to a file server or on/in 
your computer (you do not use a one-drive path) you are using M/$ cloud.

And what I have found is, if you turn off one-drive, Word, XL, and others have problems 
with saving, restoring data. But not if you have them using a file server. ?!? And this 
means as soon as you create a new spreadsheet/document/powerpoint/etc. you have to do a 
"save as" to the file server.

Now, enterprise users of windows & Office, whole nuther thing.

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



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

Re: I hate to be a pain (Cross-Posted)

[Rick Troth]

> Files in Unix are pretty unsecure.   ...

That's the popular wisdom.
I could argue that the evidence is circumstantial, even coincidental. 
(Bad rap because of bad practice by OTHER PEOPLE.)


But I'll back down.
What Itschak said about USS/Unix being unfamiliar to mainframe security 
teams is reality.
Unix and USS matter when you're in a multi-platform environment (where I 
live). If you stay in MVS then you're better off with SAF and ICSF.


-- R; <><


On 1/18/24 10:32, Colin Paice wrote:

My H'penth

Files in Unix are pretty unsecure.  I feel that any keystore in Unix is an
exposure.

With ICSF you can define a public/private key pair, and protect them with a
SAF profile such as

RDEFINE CSFKEYS label...

You then give people access to the label, and hence to the key(s).

I think it is harder to get access to these RACF resources than access to
Unix files, so the recommendation is use ICSF and SAF.

I tend to use certificates etc in RACF and not ICSF  (for ease of use) but
I think ICSF is more secure.

Colin





On Thu, 18 Jan 2024 at 13:53, Rick Troth  wrote:


On 1/18/24 02:53, ITschak Mugzach wrote:

see below the relevant STIG (V8r11)- TSS0-ES-000100:

IBM z/OS for PKI-based authentication must use ICSF or the ESM to store
keys.


Why?
(And I realize that YOU are not making this up, so don't take any
challenge personally.)



Any keys or Certificates must be managed in ICSF or the external security
manager and not in UNIX files.


Here too, why?

I found the following, but with no rationale or justification for the
above mandates.

https://www.stigviewer.com/stig/ibm_zos_tss/2021-03-30/finding/V-223883

"If the private key is discovered, an attacker can use the key to
authenticate as an authorized user and gain access to the network
infrastructure. The cornerstone of the PKI is the private key used to
encrypt or digitally sign information. If the private key is stolen,
this will lead to the compromise of the authentication and
non-repudiation gained through PKI because the attacker can use the
private key to digitally sign documents and pretend to be the authorized
user. Both the holders of a digital certificate and the issuing
authority must protect the computers, storage devices, or whatever they
use to keep the private keys."

I was going to breaking that down in this note for sake of
understanding, but that would be tedious.
Instead I'll cut to the chase: _none of the above identifies a problem
with keys residing in USS_. The statement correctly indicates the need
to protect the private key, but stops short of evaluating means of
protection.

What is the risk? discovery of the private key.

Can that happen with USS? yes (that's an area I am very familiar with)

Can that happen with ICSF? you tell me (but I'll wager yes)

Can that happen with an ESM? you tell me (same)

Because of my familiarity with USS and things like it, combined with the
common techniques used there and in other systems, it appeals to me.
That's both subjective (personal) and objective (common techniques and
methods, win/win).

Observation:
EVERY DAY I find doors closing on existing security methods in favor of
obscure alternatives.
The reasoning seems to be that attackers know the familiar routes and
therefore the familiar routes must be avoided.
That reasoning does not scale, and Wirth's law comes into play:
"software is getting slower more rapidly than hardware becomes faster".

Someone should expound on why ICSF or ESM is actually better or I'm
calling BS on this.

-- R; <><



ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon  *




On Wed, Jan 17, 2024 at 11:22 PM Phil Smith III  wrote:


Itschak Mugzach wrote:

The STIG does not allow a uss keystore.

Ummmkay? I see no mention of a STIG here. But as I said, I'm even

SWAGging

what he really wants/needs.


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


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


--
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: I hate to be a pain (Cross-Posted)

[Rick Troth]

On 1/18/24 02:53, ITschak Mugzach wrote:

see below the relevant STIG (V8r11)- TSS0-ES-000100:

IBM z/OS for PKI-based authentication must use ICSF or the ESM to store
keys.



Why?
(And I realize that YOU are not making this up, so don't take any 
challenge personally.)




Any keys or Certificates must be managed in ICSF or the external security
manager and not in UNIX files.



Here too, why?

I found the following, but with no rationale or justification for the 
above mandates.


https://www.stigviewer.com/stig/ibm_zos_tss/2021-03-30/finding/V-223883

"If the private key is discovered, an attacker can use the key to 
authenticate as an authorized user and gain access to the network 
infrastructure. The cornerstone of the PKI is the private key used to 
encrypt or digitally sign information. If the private key is stolen, 
this will lead to the compromise of the authentication and 
non-repudiation gained through PKI because the attacker can use the 
private key to digitally sign documents and pretend to be the authorized 
user. Both the holders of a digital certificate and the issuing 
authority must protect the computers, storage devices, or whatever they 
use to keep the private keys."


I was going to breaking that down in this note for sake of 
understanding, but that would be tedious.
Instead I'll cut to the chase: _none of the above identifies a problem 
with keys residing in USS_. The statement correctly indicates the need 
to protect the private key, but stops short of evaluating means of 
protection.


What is the risk? discovery of the private key.

Can that happen with USS? yes (that's an area I am very familiar with)

Can that happen with ICSF? you tell me (but I'll wager yes)

Can that happen with an ESM? you tell me (same)

Because of my familiarity with USS and things like it, combined with the 
common techniques used there and in other systems, it appeals to me. 
That's both subjective (personal) and objective (common techniques and 
methods, win/win).


Observation:
EVERY DAY I find doors closing on existing security methods in favor of 
obscure alternatives.
The reasoning seems to be that attackers know the familiar routes and 
therefore the familiar routes must be avoided.
That reasoning does not scale, and Wirth's law comes into play: 
"software is getting slower more rapidly than hardware becomes faster".


Someone should expound on why ICSF or ESM is actually better or I'm 
calling BS on this.


-- R; <><



ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon  *




On Wed, Jan 17, 2024 at 11:22 PM Phil Smith III  wrote:


Itschak Mugzach wrote:

The STIG does not allow a uss keystore.

Ummmkay? I see no mention of a STIG here. But as I said, I'm even SWAGging
what he really wants/needs.


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


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



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

Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?

[Rick Troth]

On 1/14/24 01:07, Phil Smith III wrote:

aul Gilmartin asked:


What about Format preserving encryption?
  


Format-Preserving Encryption is for structured data, i.e., specific fields. You 
would not use it on a binary blob; at that point, you'd use XTS or one of the 
other AES modes whose output is the same length as the input.



FPE is brilliant. But like everything else, it's not a be-all and 
end-all. Phil nails it: not so great for binary blobs.


I *strongly* recommend FPE for the most sensitive information when it's 
in a structured form. (Such as credit card numbers coming from the 
reader to the POS terminal.) The value of FPE is that you can actually 
*use* the info WHILE IT IS ENCRYPTED. This is available *now* and is 
significantly easier than homomorphic encryption.


More vendors should offer FPE. The best we get from most vendors is 
tokenization, but that doesn't scale well.



-- R; <><




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

Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?

[Rick Troth]

On 1/13/24 11:28, Steve Estle wrote:

I know this seems innocuous, but we'd like to encrypt as much as possible in 
our environment ...



Forgive my tone, Steve. And please don't take this as directed at you, 
but at the broader industry, especially at "seatback magazine management".


Many people use encryption like it was fairy dust: just sprinkle it 
liberally and everything is safer. That's not true, and the reasons are 
not immediately obvious. But the problem starts with the requirement to 
/decrypt/ before data can actually be used. And if *everything* is 
encrypted then there are more cases where things are getting decrypted. 
I've been using encryption, both professionally and personally, for more 
than three decades, and I find that I'm getting increasingly selective 
day by day.


I feel your pain about certain data sets being difficult.
And don't get me started about seed keys needed for whole disk situations.


-- R; <><





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

Re: SSH tunneling for unattended process.

[Rick Troth]

bottom posting ... refreshing ... sincerely


On 1/11/24 14:08, Jon Perryman wrote:

On Thu, 11 Jan 2024 09:47:45 -0600, Kirk Wolf  wrote:


Did I say anything about using passwords for ssh?
Again, this has nothing to do with your assertion that
using tn3270 over a ssh tunnel would expose the userid and password.

This thread is specifically about using ssh tunnel to provide SSL for non-SSL 
TCP apps. TN3270 (without enabling SSL) is being used for context that everyone 
in this group understands.

You ask how I would get your TSO userid / password when you run TN3270 thru an ssh 
tunnel. Very simply, the userid & password would likely be the same for both. 
Assuming you automated ssh with userid & password exposed, I just look at your 
script.



I don't understand the strife.
It's true that we normally go username/password for 3270 sign-on.
It's also true that we *can* sign-on using username/password with SSH. 
But the latter is not recommended when you have SSH keys. And the 
subject is "unattended" where keys would be *very* desirable.



-- R; <><

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

Re: OpenSSH CVE-2023-48795 vulnerability

[Rick Troth]

Thanks for the heads-up.
I have added OpenSSH 9.6p1 to the Chicory collection.
Sadly, I don't have a z/OS build system for that collection. (And if 
anyone can offer such, please pardon my sound-byte responses up to now.)


Had to bump-up the minimum level of OpenSSL from 1.0.2 to 1.1.1.
It builds and links against OpenSSL 1.1.1t and LibreSSL 3.8.1. Not sure 
their rejection of 1.0.2 is justified, but it's the current religion.


-- R; <><


On 1/5/24 07:50, rpinion865 wrote:

Does anyone know if the z/OS implementation of ssh is vulnerable to 
CVE-2023048795? I tried searching
for z/OS and OpenSSH (CVE-2023-48795). But, I did not get any hits specific to 
z/OS. Thanks in advance.

Cross posting to IBMTCP-L and IBM Main

Sent with [Proton Mail](https://proton.me/) secure email.

--
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: SSH tunneling for unattended process.

[Rick Troth]

Sorry for the delay. Holidays and family and friends and such. Ahhh...

It's been a minute, but I used SSH to carry PPP traffic back in the day.
The client side PPPD ran 'ssh' as a child process, arranging stdin and 
stdout, as if it was a dial-up modem.
The server side ran the counterpart 'pppd' as its command. (People don't 
always think about this, but you can run specific commands via SSH 
rather than always getting a shell prompt.)
Once upon a time, I was told "it'll never work", but I used it regularly 
before I learnt OpenVPN and never had problems.


So you wound up with two PPP processes talking to each other over SSH. 
This is what I meant by "directly". It did not use-L or-R options for 
TCP via the SSH tunnel. This is how RSYNC uses SSH even now.


Regarding your "ssh -L ...", non-standard ports are easier. (And -L 
means something else. See below.)


   ssh user@host:/port /


And-L means "local TCP listener" (traffic to be forwarded to the other 
end), while-R means "remote TCP listener" (remote connections conveyed 
back to the client end).


Clarification on -L and -R ...

   -L 1234:192.168.1.1:4321


in English means "listen locally on TCP port 1234 and send that traffic 
to 192.168.1.1 on the remote end at port 4321.


   -R 2345:192.168.3.3:5432


in English means "listen on the remote end at TCP port 2345 and send 
that traffic to 192.168.3.3 on this end at port 5432.


-- R; <><


On 12/29/23 21:47, kekronbekron wrote:

Thanks Rick.
This is the part I don't follow... "You can use SSH directly (with client invoking 
SSH to launch a service program on the target)".

Is it possible to make a simple example?
User A at Machine A wants to connect via port 4321 to machine B port 22, and 
it's just good old SSH connectivity.

I don't understand the "encrypt a connection" part.
Meaning, SSH-ing into machines is well known and there's encryption etc.

Correct me if I'm wrong but I think "ssh -L ..." is just to get to SSH on a 
target machine via a non-standard port?



On Friday, December 29th, 2023 at 20:35, Rick Troth  wrote:



I can't speak for Frank, but he started his inquiry with this:


We're looking at using an SSH tunnel (or reverse tunnel)to encrypt a

connection


where the application on the other end does not support TLS.


SSH is an excellent choice for this kind of job.
You can use SSH directly (with client invoking SSH to launch a service
program on the target)
or you can establish one or more TCP listeners (either direction) over
an SSH session, or any combination.
ALL of the traffic handled by way of the SSH session would be encrypted.

So I might not have understood exactly what Frank needs, but I'm a firm
believer in SSH.

Authentication of the remote SSH host is done using the SSH host key(s)
on the target system. That's standard.

Authentication of the client can be done using an SSH client key (as is
my practice) or using PKI certificates (as Colin describes in his blog).
Frank indicated that what he needs is unattended/automatic, easily
supported using either method.

Does that help?

-- R; <><



On 12/29/23 09:20, kekronbekron wrote:


Hi Rick/Frank,

If you have time, could you explain more about this setup.
I don't get what's desired..

On Friday, December 29th, 2023 at 19:04, Rick trothtro...@gmail.com  wrote:


Hi Frank --

BT/DT and it works great.

I took the usual means of capturing the host key of the target: signed
on as the service account and ran 'ssh' interactively. Ever after, the
client would not be prompted, but it would fail if the key changed. (And
that's the point.)

The client signed on using an SSH client key. Of course, I had to break
a rule here and magically obviate the need for a pass phrase. (Dark
magic. Not something we speak about in public.)

In this particular case, I ran it from/etc/inittab on a traditional Unix
(Linux) system. That way when the session would die it would be restarted.

This hack used either -L or -R, I forget which, but established a TCP
listener. All traffic was limited to local (which is the default), so no
risk of someone off-box sending or seeing cleartext.

-- R; <><

On 12/29/23 04:53, Colin Paice wrote:


Frank,
What do you have on the z/OS end? If the back end supports it, it can map
from a certificate to a userid.
See Using certificates to logon to z/OS
https://colinpaice.blog/2023/03/28/using-certificates-to-logon-to-z-os/
andWhat’s the difference between RACDCERT MAP and RACMAP?
https://colinpaice.blog/2020/07/28/whats-the-difference-between-racdcert-map-and-racmap/
Colin

On Fri, 29 Dec 2023 at 06:27, frankswarbrickfrank.swarbr...@outlook.com
wrote:


We're looking at using an SSH tunnel (or reverse tunnel) to encrypt a
connection where the application on the other end does not support TLS.
The POC looks to be working. I am now pondering on the steps required to
make setting up the t

Re: OpenSSH CVE-2023-48795 vulnerability

[Rick Troth]

Thanks!

I don't see the artifacts for the 9.6p1 build. Do the project 
maintainers need to cut a release?


-- R; <><


On 1/5/24 20:04, kekronbekron wrote:

You could grab the latest (unsupported) release from this repo, once it's 
published.
Here's a link to the pull request, which introduces the latest version.
The build has succeeded.

https://github.com/ZOSOpenTools/opensshport/pull/6



On Saturday, January 6th, 2024 at 05:26, Filip Palian  
wrote:



For this type of verification SBOMs seems to be the way moving forward:
https://cyclonedx.org/use-cases/#known-vulnerabilities

Cheers,
FP

W dniu piątek, 5 stycznia 2024 rpinion865 <
042a019916dd-dmarc-requ...@listserv.ua.edu> napisał(a):


Does anyone know if the z/OS implementation of ssh is vulnerable to
CVE-2023048795? I tried searching
for z/OS and OpenSSH (CVE-2023-48795). But, I did not get any hits
specific to z/OS. Thanks in advance.

Cross posting to IBMTCP-L and IBM Main

Sent with Proton Mail secure email.

--
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: SSH tunneling for unattended process.

[Rick Troth]

I can't speak for Frank, but he started his inquiry with this:

> We're looking at using an SSH tunnel (or reverse tunnel)to encrypt a 
connection

> where the application on the other end does not support TLS.

SSH is an excellent choice for this kind of job.
You can use SSH directly (with client invoking SSH to launch a service 
program on the target)
*or* you can establish one or more TCP listeners (either direction) over 
an SSH session, or any combination.

ALL of the traffic handled by way of the SSH session would be encrypted.

So I might not have understood exactly what Frank needs, but I'm a firm 
believer in SSH.


Authentication of the remote SSH host is done using the SSH host key(s) 
on the target system. That's standard.


Authentication of the client can be done using an SSH client key (as is 
my practice) or using PKI certificates (as Colin describes in his blog).
Frank indicated that what he needs is unattended/automatic, easily 
supported using either method.


Does that help?

-- R; <><


On 12/29/23 09:20, kekronbekron wrote:

Hi Rick/Frank,

If you have time, could you explain more about this setup.
I don't get what's desired..


On Friday, December 29th, 2023 at 19:04, Rick Troth  wrote:



Hi Frank --

BT/DT and it works great.

I took the usual means of capturing the host key of the target: signed
on as the service account and ran 'ssh' interactively. Ever after, the
client would not be prompted, but it would fail if the key changed. (And
that's the point.)

The client signed on using an SSH client key. Of course, I had to break
a rule here and magically obviate the need for a pass phrase. (Dark
magic. Not something we speak about in public.)

In this particular case, I ran it from/etc/inittab on a traditional Unix
(Linux) system. That way when the session would die it would be restarted.

This hack used either -L or -R, I forget which, but established a TCP
listener. All traffic was limited to local (which is the default), so no
risk of someone off-box sending or seeing cleartext.

-- R; <><





On 12/29/23 04:53, Colin Paice wrote:


Frank,
What do you have on the z/OS end? If the back end supports it, it can map
from a certificate to a userid.
See Using certificates to logon to z/OS
https://colinpaice.blog/2023/03/28/using-certificates-to-logon-to-z-os/
andWhat’s the difference between RACDCERT MAP and RACMAP?
https://colinpaice.blog/2020/07/28/whats-the-difference-between-racdcert-map-and-racmap/
Colin

On Fri, 29 Dec 2023 at 06:27, Frank swarbrickfrank.swarbr...@outlook.com
wrote:


We're looking at using an SSH tunnel (or reverse tunnel) to encrypt a
connection where the application on the other end does not support TLS.
The POC looks to be working. I am now pondering on the steps required to
make setting up the tunnel an automated process. It seems to me that we'd
want the z/OS user to be a "protected" user
(NOPASSWORD/NOPHRASE/NOOIDCARD). Would this require that we use SSH host
based authentication? I imagine that the user would require an OMVS
segment. I wonder if it would need a shell or home directory. Any other
thoughts?

Thanks,
Frank

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

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



--
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: SSH tunneling for unattended process.

[Rick Troth]

Hi Frank --

BT/DT and it works great.

I took the usual means of capturing the host key of the target: signed 
on as the service account and ran 'ssh' interactively. Ever after, the 
client would not be prompted, but it would fail if the key changed. (And 
that's the point.)


The client signed on using an SSH client key. Of course, I had to break 
a rule here and magically obviate the need for a pass phrase. (Dark 
magic. Not something we speak about in public.)


In this particular case, I ran it from/etc/inittab on a traditional Unix 
(Linux) system. That way when the session would die it would be restarted.


This hack used either -L or -R, I forget which, but established a TCP 
listener. All traffic was limited to local (which is the default), so no 
risk of someone off-box sending or seeing cleartext.


-- R; <><




On 12/29/23 04:53, Colin Paice wrote:

Frank,
What do you have on the z/OS end?   If the back end supports it, it can map
from a certificate to a userid.
See Using certificates to logon to z/OS

andWhat’s the difference between RACDCERT MAP and RACMAP?

Colin

On Fri, 29 Dec 2023 at 06:27, Frank Swarbrick
wrote:


We're looking at using an SSH tunnel (or reverse tunnel) to encrypt a
connection where the application on the other end does not support TLS.
The POC looks to be working.  I am now pondering on the steps required to
make setting up the tunnel an automated process.  It seems to me that we'd
want the z/OS user to be a "protected" user
(NOPASSWORD/NOPHRASE/NOOIDCARD).  Would this require that we use SSH host
based authentication?  I imagine that the user would require an OMVS
segment.  I wonder if it would need a shell or home directory.  Any other
thoughts?

Thanks,
Frank


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


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



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

Re: RFC3280 (and 5280), "Basic Constraints" set to Critical

[Rick Troth]

On 12/11/23 10:13, Phil Smith III wrote:

Charles wrote:

The critical bit is there to provide upward compatibility for
certificates, which are a standard that is implemented in everything

>from z/OS to Nest Thermostats to Balckberrys that have not been

updated in ten years.
The critical bit says "this extension really matters. If you don't
know what this extension is all about, if you don't recognize it, if
it is a newer standard than your implementation, then you must reject
this certificate."
So it seems to me to be really fussy pedantry for a TLS implementation
(yes, GSK) to say "I recognize that extension, but you were SUPPOSED
to set the critical bit, so nanner, nanner, I am rejecting it."

OK, I agree, but I still don't know whether that makes it a bug or what.



If it's WRONG (*and* if no one has functional dependency on that "wrong" 
behavior, which we hope they don't) then it's a bug.




Alan's comment:

While I wouldn't be surprised to find certificate validation fixes in
the same release that has TLS 1.3 (it tightened up various security
aspects), I would be surprised to find those fixes not applying to
older protocols.

...also seems trenchant: even if it IS considered correct behavior, why just 
for TLSv1.3?



And that too.
Consistency across protocol levels would be a Good Thing.

IBM needs to either make GSK consistent here or splain to you why it's 
not consistent.




Hoping someone from gsk-land in IBM can chime in here. I don't have the ability 
to open a PMR these days.

...phsiii

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



-- R; <><

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

Re: RFC3280 (and 5280), "Basic Constraints" set to Critical

[Rick Troth]

(replying via IBM-MAIN; where'd my IBMTCP-L subscription go?)

Apologies that I don't have a *solution*. But hopefully this observation 
is more than just bitch-n-moan.


> The fix was to update the root certificate used by the server to add 
the required Critical value for Basic Constraints (henceforth "BC" as a 
shorthand).


That would seem to throw the burden on the CAs. Not your problem anymore?

As an industry, we have a problem with planned obsolescence. We think 
it's healthy. (And "we" used to think smoking tobacco was healthy. Go 
figure.)
Some changes as the protocols evolve (and code evolves) carry 
intentional breakage, trying to force you to get away from old stuff. 
(Doesn't matter if the risk from the "old stuff" is acceptable, you're a 
heretic for staying back-level. We're gonna make it hurt.)


Linus Torvalds has a reputation for being hard to work with. It's been 
said that he regularly berates other kernel developers ... publicly ... 
with invective.
But to his credit, it's also been said that he comes down harder on 
developers who break the non-kernel experience. In one example, if 
people depend on a bug in your ABI, it's no longer a bug but a feature.
Carry this to TCP land: So then we're all happily up-to-date with TLS 
1.2 and along comes TLS 1.3 and ... bzzzttt!!!


IBM gets an extra hour in detention over this.
They're known to follow the rules ... to a fault. I confess that I 
haven't read "the rules" (e.g., RFC 5280, et al), but there have been 
significant cases where other systems worked fine but the IBM system did 
not. (I'm thinking of an certain problem with the AIX TCP stack versus 
F5 load balancers which Phil might remember.)
Other vendors deliver wares which behave more as expected, rightly or 
wrongly.


In trying to help, the question which comes to mind is: where do you see 
the error? Is it on z/OS or on the other end?
And does it really help to fix the root cert? Have you uncovered a bug 
in TLS 1.3? (And do the TLS 1.3 lords consider it a bug or a feature?)


-- R; <><


On 12/8/23 11:36, Phil Smith III wrote:

(Cross-posted to IBM-MAIN and IBMTCP-L)

Our z/OS product acts as a client to our non-z/OS server. As such, it makes TLS 
connections to fetch Policy and keys.

As I've written previously, we had a problem when we added TLSv1.3 support to 
the z/OS product, getting errors:
ERROR check_cert_extensions_3280_and_later(): Basic Constraints extension must 
be critical for CA Certificate

The fix was to update the root certificate used by the server to add the required 
Critical value for Basic Constraints (henceforth "BC" as a shorthand).

This happened again here this week when a certificate was updated (someone used 
the wrong internal CA, which was old). Once we got it straightened out, I 
started wondering why this only happened once we added TLSv1.3 support. Some 
reading of RFC5280 (which obsoleted 3280) suggests that a PKIX-compliant 
certificate should ALWAYS be rejected if not BC. But this doesn't seem to be 
true until we add the TLSv1.3 support.

I say "seems to" because I don't have an easy way to test all combinations. The 
older version of our z/OS product didn't support TLSv1.3. The changes to implement 1.3 
support added three calls to the stack:

*   One that says "Yeah, we do 1.3":
gsk_attribute_set_enum(pSSI->hEnviron, GSK_PROTOCOL_TLSV1_3, 
GSK_PROTOCOL_TLSV1_3_ON);
*   One to add the 1.3 key shares:
gsk_attribute_set_buffer(pSSI->hEnviron, GSK_CLIENT_TLS_KEY_SHARES, 
"00230024002500290030", 0);
*   One to add the 1.3 ciphers (I think?):
sslStatus = vsgsk_attribute_set_buffer(pSSI->hSocket, GSK_V3_CIPHER_SPECS_EXPANDED, 
"C030C02FC028C027C014130113021303003500380039002F00320033", 0);

There was another change that added SNI support, but that was backported to the 
old version, so I don't think it nets out as a difference between what I had 
available to test. And of course the cert is fixed now, so I couldn't easily 
test more if I wanted to.

Anyone (Wai? Charles?) have any domain knowledge here? Should gsk be 
categorically rejecting a root certificate that claims to be PKIX-compliant, or 
only if TLSv1.3 is supported?

I'm less interested in getting it fixed if it's wrong, since there's obvious significant 
risk of breaking a lot of existing, working connections-plus as folks move to TLSv1.3 
they'll fix it anyway-than I am in feeling that we can confidently tell customers who hit 
this "Yes, that's a requirement of [TLSv1.3? TLS in general, but IBM only enforces 
it for 1.3? something else?]", and not that it's a peculiarity of our 
implementation. Put another way, the surprise (after reading the RFC and thinking I 
understand it!) is that it breaks when it does-that a non-BC certificate ever works. 
Should it?


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

Re: External Functions in C on z/OS

[Rick Troth]

Thanks.
This is all ... overwhelming ... and amazing. Very nice.

I build packages from source, so I'm keen on following that where 
possible. But it's gonna take some time.


-- R; <><


On 11/22/23 12:37, Rony G. Flatscher wrote:

Hi Rick,

On 22.11.2023 16:09, Rick Troth wrote:

Are you saying that you can call Java from ooRexx?

Yes.
How does that happen? 
There is a DLL/shared object that can be linked by both, ooRexx and 
Java. It allows for going either direction: call Java from ooRexx, but 
also call ooRexx from Java or from any JVM language (you mentioned 
Scala, Clojure, Groovy and friends, also the very first JVM language 
NetRexx).
Do you spin-up a JVM running in standby mode? 


ooRexx allows for libraries of Rexx/ooRexx code (named "packages"). If 
that library gets called by any Rexx/ooRexx program it will check 
whether a JVM is already running or not, if not, it will use the 
DLL/shared object to demand load the JVM.



Do you run ooRexx in a JVM?

Yes, that is possible too.
I can call native code from Java, but always have to transit the JNI. 
JNI gets used behind the curtain, but the Rexx or Java programmer will 
never get to see JNI.

Never been able to go the other direction.

The ooRexx-Java bridge works in both directions.
The JVM is the single most difficult (for me, but I have lots to 
learn) barrier to inter-language operation with Java (other than 
Scala, Clojure, Groovy and friends which already run "in" the JVM).


The way to go from Java is via the Java scripting framework in the 
Java package named javax.script (while the JSR-223 group developed 
that framework I served as one of the experts). Here a Java example of 
how to run a Rexx or ooRexx script, supplying arguments to Rexx and 
fetching and showing the return Rexx result:


   import javax.script.*;

   public class TestCallRexx
   {
    public static void main (String args[])
    {
    ScriptEngineManager manager = new ScriptEngineManager();
    ScriptEngine se = 
manager.getEngineByName("rexx");
    String rexxCode = "say '(Rexx) argument from Java:' 
arg(1) \n" +
  "do i=1 to arg()    /* iterate over 
arguments */ \n" +
  "   say '(Rexx) arg #' i':' 
arg(i)   \n" +

"end \n" +
  "parse version v  /* Rexx 
version */ \n" +
  "say '(Rexx) parse version:' 
v   \n" +
  "parse source s   /* Rexx 
version */ \n" +
  "say '(Rexx) parse source:' 
s    \n" +
  "/* get the operating system and version 
via Rexx\n" +
  "   and return it within the following 
string */ \n" +
  "return 'from ooRexx:' 
sysVersion()   \n";

    try
    {
    ScriptContext sc=se.getContext();  // get the default 
ScriptContext

    // add the fileName to the ENGINE_SCOPE bindings
    sc.setAttribute(ScriptEngine.FILENAME, "TestCallRexx", 
ScriptContext.ENGINE_SCOPE);
    // add arguments for the script to the 
ENGINE_SCOPE bindings
    Object args4script[]=new Object[] {"one", "zwei", 
"tre", "quatre"};
    sc.setAttribute(ScriptEngine.ARGV, args4script, 
ScriptContext.ENGINE_SCOPE);
    // the RexxScriptEngine always compiles the last 
script and makes it available with the getCurrentScript() method
    Object o=se.eval(rexxCode,sc); // now let us 
re-execute the Rexx script

    System.out.println("(Java) received from Rexx: "+o);
    }
    catch (Exception exc)
    {
    System.err.println(exc);
    System.exit(-1);
    }
    System.exit(0);
    }
   }

Here the output running the above Java program:

   G:\test\java\jsr223>java TestCallRexx
   REXXout>(Rexx) argument from Java: one
   REXXout>(Rexx) arg # 1: one
   REXXout>(Rexx) arg # 2: zwei
   REXXout>(Rexx) arg # 3: tre
   REXXout>(Rexx) arg # 4: quatre
   REXXout>(Rexx) arg # 5: a Slot.Argument
   REXXout>(Rexx) parse version: REXX-ooRexx_5.1.0(MT)_64-bit 6.05 22 
Oct 2023

   REXXout>(Rexx) parse source: WindowsNT SUBROUTINE TestCallRexx
   (Java) received from Rexx: from ooRexx: Windows 10.0.19045

Not sure whether the formatting is distorted (used preview style).

You can supply any type of argument to Rexx and fetch any type of 
return value from Rexx.


As you can see it is very easy to use from Java.

---

Here a s

Re: External Functions in C on z/OS

[Rick Troth]

Are you saying that you can call Java from ooRexx?
How does that happen? Do you spin-up a JVM running in standby mode? Do 
you run ooRexx in a JVM?
I can call native code from Java, but always have to transit the JNI. 
Never been able to go the other direction.


The JVM is the single most difficult (for me, but I have lots to learn) 
barrier to inter-language operation with Java (other than Scala, 
Clojure, Groovy and friends which already run "in" the JVM).


-- R; <><


On 11/17/23 10:00, Rony G. Flatscher wrote:

On 16.11.2023 22:54, David Crayford wrote:

I don't find ooRexx useful on the PC as it's basically on life support
where Python has millions of contributors. Take data validation as an
example. There is a first class library 
https://docs.pydantic.dev/latest/.


Python isn't my favorite language by a large margin. But it is useful 
so it
wins. Same same with Java. Personal preference is secondary to a 
pragmatic

choice.


The combination of ooRexx [1] with Java [2] - on all platforms - 
allows one to exploit all of Java (the Java runtime environment) as a 
huge external class library for ooRexx. Unlike with Python there would 
be no need to locate, choose and import specific modules with the 
needed functionality, rather one can use the Rexx skills to 
immediately exploit all of the Java functionality on all platforms.


It is hard to realize/assess the potential of this combination without 
a little bit of curiosity and the will to learn new tricks.


---rony

[1] ooRexx download site: 

[2] ooRexx-Java bridge (BSF4ooRexx850) download site: 





On Fri, Nov 17, 2023 at 5:32 AM Seymour J Metz  wrote:


I find REXX extremely useful on PCs, but TSO/E REXX is a backwater
compared to ooRexx, and I would be tempted to use Java or Python for
complicated TSO scripts. But on z/Linux ooRexx with BSF4REXX is a 
viable

option.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי




From: IBM Mainframe Discussion List  on 
behalf

of David Crayford 
Sent: Thursday, November 16, 2023 4:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: External Functions in C on z/OS

I choose a language on capabilities rather than personal preference. 
I’ve
been accused on this forum by my ex-colleague and pal Wayne 
Bickerdyke of
having a pathological dislike of REXX. That’s not true, but I do 
find it
less useful than other languages. Python has a useful library called 
ctypes
which includes classes for mapping data structures with Python 
classes. We

use BigEndianStructure for mapping control blocks
https://docs.python.org/3/library/ctypes.html#ctypes.BigEndianStructure. 


It would be cool if the tooling that we worked on with Peter Relson to
create C header files could be reused to generate Python mappings. 
With the

recent zIIP offloading Python is strategic.


On 17 Nov 2023, at 12:38 am, Charles Mills  wrote:

  Different strokes for different folks.

1. I was not aware of that pointer. This is the classic documentation
problem. The answer is right there in the manual, clear as day -- 
provided
you know where to look. A lot of these answers are easy to find, 
assuming

you already know the answer.

2. My code is running a complex Rexx environment that frankly I do not
fully understand. (I didn't write it and it isn't "mine.") I wanted 
to be

sure I had THE right environment block, not SOME environment block. An
11-instruction assembler module seemed like a great solution. I still
believe that it was.

  Charles

On Thu, 16 Nov 2023 11:31:20 +0800, David Crayford 


wrote:
There's a TSO/E vector table that has the address of the REXX 
routines.


// get the address of the TSO/e vector table
CVT  * cvt  = *(( CVT ** ) CVTPTR);
TSVT * tsvt = cvt->cvttvt;


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


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

Re: External Functions in C on z/OS

[Rick Troth]

Agreed!
The set-up/tear-down of LE is a pain.

In a previous life, I brought up LE to have it available for C (or any 
other LE languages) sort of on demand. Calling linkage to/from the other 
languages worked fine. It was that LE establishment that would lead to 
ABENDs if not done (or if not done right).


And yeah ... C structs. No biggie.

-- R; <><


On 11/15/23 20:12, David Crayford wrote:

There isn’t an R0 issue. IRXINIT(‘FINDENVB’) will fetch the environment block. 
All of the REXX mapping macros have been converted to C structures and can be 
found in /usr/include/zos (there is a PDS/E but I can’t remember what it's 
called). FWIW, writing external functions in C/C++ is a bad idea unless it’s 
main routine. The overhead of standing up and ripping down an LE environment is 
huge. Metal/C is an option. It’s one of the reasons why I don’t like REXX, it’s 
difficult to extend with languages other than assembler which makes it useless 
for what I want for a glue language.


On 16 Nov 2023, at 2:06 am, Charles Mills  wrote:

@Peter, I went around on the R0 question here a couple of years ago.

- No, I don't think there is a reliable way to get the entry R13 from within 
the C/C++ code. Obviously, if you could, then any other register is trivial.

- Yes, people suggested inline assembler. I rejected that approach -- it may be 
completely viable but I rejected it -- because

a. I am just not a fan of inline assembler. Call it personal preference. I think the 
syntax seems kludgey. I prefer an external module written in "real" assembler. 
I fully accept that this is just my personal opinion and others who think otherwise are 
just as valid.
b. IIRC the logic was a little bit unsupported. XLC is stable now, so it would 
probably be safe, but for me that was another nail in the coffin of the in-line 
assembler approach.

The code is exactly 11 executable instructions, four of them because I set up 
an eyecatcher that is not really necessary.

I do it without a save area. I branch to the C code with the assumption that 
the C code will ultimately return to *my caller* and not to me.

FWIW, I pass R0 in the EVALBLOCK data area, a totally "safe" spot that does not 
require a GETMAIN.

Charles

On Wed, 15 Nov 2023 17:54:44 +, Farley, Peter  
wrote:


Isn’t there is some C library function (maybe unique to XLC/C++) that lets you 
get the value of R13 (current DSA pointer)?  With that pointer value in hand, 
couldn’t one chain up the DSA stack to get to the saved registers at entry, or 
is that not possible?

At worst, an inline ASM routine to copy the value of the current R13 to a C 
pointer variable, then chain up the DSA stack?

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Wednesday, November 15, 2023 12:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: External Functions in C on z/OS


I see, in my C++ projects, EFPL, ENVB, EVALB and SHVB structs that appear to me 
to have been produced from IBM macros by the EDCDSECT tool.



Have you looked for the IRX macros in SYS1.MACLIB?



Are you familiar with EDCDSECT?



Slightly changing the subject, to interface with ehe Rexx environment from a 
called function you will need the entry R0, I found no great way to get that. I 
had to write a tiny front end in assembler that passes R0 to a C/C++ main().



Charles



On Wed, 15 Nov 20 3 10:57:14 -0600, Eric Erickson  wrote:




I've written quite a few callable external funitions for Rexx over the years. On 
z/OS I've always used assembler as we needed to access system services for a 
variety of tasks. I've written them in C for other platforms (OS/2 & Windows) 
over the years. I need to write some on z/OS, but I want to use C, but can not seem 
to find any examples or header files for the Rexx Control Blocks. I can't believe 
nobody has done this over the years? Is it even supported?



--

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


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

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

Re: External Functions in C on z/OS

[Rick Troth]

I remember the DSECT2C command, but might have been from an ISV (maybe 
Dignus?).
But converting a DSECT to a struct is kinda easy. So if you have the 
Rexx and TSO control blocks in assembler, you should be able to cook-up 
C structs for equivalent representation.

If you need help with that, just holler. BT/DT

-- R; <><


On 11/15/23 16:26, Farley, Peter wrote:

OK, I sort of understand the “personal preference” about not using inline 
assembler (it is kludgey, I agree) and somewhat understand the concern about 
the “unsupported” aspect of retrieving register contents at entry, but if that 
is the case why not use MetalC where you have much more control of the entry 
and exit logic, and could easily provide your own version of the prolog that 
guaranteed access to the contents of R0?  Is there some C library routine that 
is not provided by MetalC that you would need in your Rexx external function?

Also you are correct that IBM does not supply C versions of the Rexx or TSO 
control blocks.  Like Colin, I cobbled together my own collection of them from 
the assembler macro library source using the EDCDSECT utility and some 
semi-automated post-processing.

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Wednesday, November 15, 2023 1:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: External Functions in C on z/OS


@Peter, I went around on the R0 question here a couple of years ago.



- No, I don't think there is a reliable way to get the entry R13 from within 
the C/C++ code. Obviously, if you could, then any other register is trivial.



- Yes, people suggested inline assembler. I rejected that approach -- it may be 
completely viable but I rejected it -- because



a. I am just not a fan of inline assembler. Call it personal preference. I think the 
syntax seems kludgey. I prefer an external module written in "real" assembler. 
I fully accept that this is just my personal opinion and others who think otherwise are 
just as valid.

b. IIRC the logic was a little bit unsupported. XLC is stable now, so it would 
probably be safe, but for me that was another nail in the coffin of the in-line 
assembler approach.



The code is exactly 11 executable instructions, four of them because I set up 
an eyecatcher that is not really necessary.



I do it without a save area. I branch to the C code with the assumption that 
the C code will ultimately return to *my caller* and not to me.



FWIW, I pass R0 in the EVALBLOCK data area, a totally "safe" spot that does not 
require a GETMAIN.



Charles



On Wed, 15 Nov 2023 17:54:44 +, Farley, Peter  
wrote:




Isn’t there is some C library function (maybe unique to XLC/C++) that lets you 
get the value of R13 (current DSA pointer)?  With that pointer value in hand, 
couldn’t one chain up the DSA stack to get to the saved registers at entry, or 
is that not possible?
At worst, an inline ASM routine to copy the value of the current R13 to a C 
pointer variable, then chain up the DSA stack?
Peter
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Wednesday, November 15, 2023 12:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: External Functions in C on z/OS
I see, in my C++ projects, EFPL, ENVB, EVALB and SHVB structs that appear to me 
to have been produced from IBM macros by the EDCDSECT tool.
Have you looked for the IRX macros in SYS1.MACLIB?
Are you familiar with EDCDSECT?
Slightly changing the subject, to interface with ehe Rexx environment from a 
called function you will need the entry R0, I found no great way to get that. I 
had to write a tiny front end in assembler that passes R0 to a C/C++ main().
Charles
On Wed, 15 Nov 20 3 10:57:14 -0600, Eric Erickson  wrote:

I've written quite a few callable external funitions for Rexx over the years. On 
z/OS I've always used assembler as we needed to access system services for a 
variety of tasks. I've written them in C for other platforms (OS/2 & Windows) 
over the years. I need to write some on z/OS, but I want to use C, but can not seem 
to find any examples or header files for the Rexx Control Blocks. I can't believe 
nobody has done this over the years? Is it even supported?

--

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


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


--

Re: Kinda fun

[Rick Troth]

One great thing about punched cards (and printed paper, and even such 
things as paper tape)
is that they don't suffer degaussing or other such high-tech ailments. 
(They have their own /different/ problems.)

Cards and printed paper are even human readable. Wow.

Let's hear it for low tech and old tech!

-- R; <><


On 11/8/23 09:10, Phil Smith III wrote:

Bob Bridges wrote about his history with keypunches.

Mine started in 1965, when I was four. My dad was working on his first concordance, of Beowulf, and 
my mom was going to do the data entry of the text. (They'd met in the 50s when he was working for a 
CIA front doing translation and his typist quit. He told them, "I need a new typist, but don't 
give me anyone interesting", and when they brought her in, he thought, "Dammit, nobody 
listens to me around here!" Nine months later they were married.)

So I got to play with a keypunch at a very young age, and then again starting in 1975 when I sat in 
on my dad's PL/C class at the University. I have fond memories of playing outside with a bag of 
chad (please, not "chads"-it was a mass noun for 50 years; the 2000 election instantly 
made it a count noun, but we old-timers don't have to put up with that). (Jeez, even Office thinks 
it should be "chads". Kids today.)

Bob, your musing about communications parameters sounds like full/half duplex.

As for the cost of cards-I bought a few boxes on eBay about a decade ago. Even 
then folks were often selling individual cards for several dollars. I still 
have a bunch. My dad always had them in his breast pocket for note cards. He'd 
also always heard that they were the same size as old U.S. bills, but in the 
pre-Internet era had no easy way to verify that. Until one day in the late 80s, 
walking in lower Manhattan, he passed a numismatic store that had an old $1 
bill taped to the inside of the window. He instantly whipped out a card and 
held it up, and sure 'nuff, it was the same size, modulo the clipped corner, of 
course!

Keypunches persisted at University of Waterloo until the early 80s, not because the U was 
backward, but because ONE prof (not my dad!) insisted on using them. IIRC the I/O 
operators (remember them?) tried various stunts, like "accidentally" dropping 
his box of cards (only it wasn't really) in front of him and then stepping on them as 
they went to pick them up. They finally managed to get approval to tell him HE would have 
to pay for the maintenance. That cured it.

Don't misshttps://www.masswerk.at/keypunch/  !


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



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

Re: FTP problem

[Rick Troth]

Been so many years I forget the syntax but you might be able to force 
the other end to behave appropriately. TYPE E and MODE B for binary 
stuff, yes. But look into "QUOTE" and "SITE" commands in the FTP client 
for sending "TYPE I" or "TYPE A" and the like over to the server.


I hope this helps.
But honestly, I really dislike FTP these days. Have for a long time.
Where I have sign-on, I use 'scp' instead. Where I don't, I use 
HTTP/HTTPS. (And you can throw data sets over the wall to/from USS.)


-- R; <><


On 10/30/23 15:13, Phil Smith III wrote:

I was doing a gsktrace and FTPing the resulting text file (after processing the 
trace file) to Windows. I was getting gibberish. Tinkered with chtag, didn't 
get anywhere. Then I deleted the file and did the gsktrace again, FTPed that, 
it was fine. Next iteration (new trace file) I could not get it to work at all.

  


It looks like Windows FTP server is convinced the file is "mixed" (even when I 
chtag -r it) and thus not doing translation.

  


I realize this is confused, but that's because I'm confused; I'm used to FTP 
and Ascii and Image and MODE B TYPE E and like that, and think I've tried all 
options. The fact that it worked once is almost worse.

  


Ideas?


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



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

Re: System Z Enthusiasts discord (yes - Z folks do use discord)

[Rick Troth]

On 10/11/23 12:55, Lionel B. Dyck wrote:

There is an online community for all System Z Enthusiasts on discord that is
growing. There are discussions ranging from the z/OS Open Tools to Hercules
to CBTape tools to Stack Overflow questions on Z to nearly anything and
everything related to Z.

Check it out at:  https://discord.gg/3PKgUayuSV



Second this.

If you wish, you can think of it as a VMSHARE work-alike. It's an 
"online conference".


Thanks Lionel for inviting us. Thanks Steven for setting it up.




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

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



I should also qualify this endorsement. There are two concerns, and 
maybe they can be addressed in the near future.
First is supporting the forum. When you look at massively popular 
platforms like Twitter and Facebook, you see their demise. How is 
Discord funded? We should keep in mind that we likely will have to 
step-up to some sort of support down the road.
LISTSERV gets by on the generosity of academic institutions (in this 
case the University of Alabama, "Roll Tide!"). But even these sometimes 
have to trim their budgets.


Secondly, and this is personal, I much prefer interaction via email. 
Would love to see platforms like Discord support that mode of 
communication. Two very important "circles" in my own life use FB 
Messenger, which is horribly captive. (But the others don't get it, not 
being techie; they don't see the entrapment.) If someone happens to know 
of a plug-in or a mod (in this case, to Discord) enabling email please 
do share. The problems with email are historical (the original design) 
and a tragedy of the commons (the unpoliced shared space will be marred 
by the nere do wells).



-- R; <><




--
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: TN3270, EBCDIC and ASCII

[Rick Troth]

On 10/10/23 22:22, Grant Taylor wrote:

On 10/10/23 3:15 PM, Rick Troth wrote:
The copy-n-paste point makes me wonder if the fonts are actually 
mapped to ASCII values.


I was wondering the same thing.

I'm watching the thread to learn more.



*blush*

Gotta be prepared to say "I was wrong".




I don't know graphical environments well enough to analyze it. But it 
would mean that, yes, there *is* A/E translation happening even in 
the graphical 3270 emulators. (In hopes of not steering Juan wrong 
with what I said before.)


I would have naively assumed that the A/E translation is happening 
between the TN3270* protocol and the in memory screen buffer.


This would mean that the buffer can be displayed with any font the 
user chooses /and/ it would more cleanly support copy / paste.


*I actually assume that similar would happen with communications using 
more traditional SNA on the LAN; e.g. DLC.  --  If memory even 
remotely serves after a long day.




A/E translation is a challenge on several fronts.
One is that DBCS and Unicode don't relate at all (as encoded).

When I first sank into this swamp, circa early 1990s, there was a 
valiant effort, prominently visible at SHARE in those days, to resolve 
mappings of the myriad 8-bit code pages.
Most terminals in my shop were CP37. The best table we could come up 
with mapped "CP37v2" to ISO-8859-1. (This, of course, did not serve the 
CP500 fans nor the ISO-8859-other for 2, 3, and so on.) I still 
reference that table.
Tom Brennan might remember some of this saga. *:-)* Translate tables 
abound! VM TCP/IP has more than I could keep straight in my head.


CP37v2 was a customer invention that fixed the square brackets problem 
in CP37. As far as IBM was concerned, there was no CP37v2 ... *but* ... 
IBM came out with CP1047 which edged closer to CP37v2. CP1047 is the 
official code page (I was told) for USS. CP1047 is the official code 
page of a certain ISV product I was involved with in recent years, one 
where character sets are crucial.


Over on the ASCII side, ISO-8859-1 was the norm for all Unix systems 
that I encountered, including Linux. But then Unicode landed on our 
planet. Linux embraced it, using UTF-8, so did other platforms. That's 
all fine and good until we want to talk to an EBCDIC system, either by 
way of 3270 emulation or via SSH.


The web burst onto the scene. Thankfully HTTP and HTML have tagging 
capabilities, so for most consumers ... well ... they have no idea the 
work the techies have gone thru.



-- R; <><




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

Re: TN3270, EBCDIC and ASCII

[Rick Troth]

Not late at all.

The copy-n-paste point makes me wonder if the fonts are actually mapped 
to ASCII values.
I don't know graphical environments well enough to analyze it. But it 
would mean that, yes, there *is* A/E translation happening even in the 
graphical 3270 emulators. (In hopes of not steering Juan wrong with what 
I said before.)


-- R; <><


On 10/10/23 14:19, Steve Thompson wrote:

I am replying a bit late to this.

However, when you do a copy/paste from the TN3270 screen to Notepad 
(as an example), it then becomes "ASCII". Same for copy to Word.


Now, if you copy from your workstation and paste into the TN3270 
emulator, it gets converted/translated to "EBCDIC" and watch out for 
the ] [, and others becoming goofy.


Just thought you might need that bit of info.  I've used QWS3270, 
EXTRA, VISTA, HOD (Host On Demand), and one or two others.


Steve Thompson

On 10/10/2023 12:18 PM, jgmauta...@yahoo.com.ar wrote:

Hi!
I want to understand how TN3270 emulation works regarding convertion 
of characters (between EBCDIC and ASCII, and viceversa).
This is how I think it works (more or less), but I am not sure at 
all. So please let me know about any mistakes.
Let suppose that you use a TN3270 emulator program to access the ISPF 
browser to display a dataset. Let also assume, to simplify, that it 
contains just a single character, an "A".In DASD, what is indeed 
stored is X'C1' or, to be more accurate, BINARY'1100 0001'. When you 
BROWSE the dataset, then the Mainframe sends to the TN3270 PC client 
exactly X'C1' (BIN'1100 0001'). No convertion is done at the 
Mainframe side. Then, when the TN3270 client receives X'C1', because 
it knows that this is a TN3270 session and that its configured 
CODEPAGE is say 500, it realizes that X'C1' corresponds to an "A" 
displayable character. And, before sending the instruction to display 
it on the PC screen, it converts X'C1' to X'41'.

Is this more or less how this works?
Thanks in advnace for your help,

Juan Mautalen

--
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: TN3270, EBCDIC and ASCII

[Rick Troth]

Hi Juan --

TN3270 is an EBCDIC protocol.
When a TN3270 client program connects to a z/OS or z/VM or z/VSE or 
z/TPF host (typically on TCP port 23) and negotiates for TN3270, 
everything is EBCDIC after that. (Well ... everything except the 
signalling, of course. But the textual content is all EBCDIC.)


When you use a 3270 emulator, what happens depends on the emulator. Best 
I can tell, most graphical 3270 emulators use an EBCDIC font, so the 
characters don't have to be translated.
Even so, yes, there are code pages. You can tell your emulator which 
code page to use (e.g., CP500). I confess, I don't know with certainty 
that the EBCDIC fonts do not require A/E mapping, but it's obviously 
silly if they do.

Ideally there's no translation for a graphical 3270 emulator.

C3270 is a text mode 3270 emulator for Unix and Linux. It talks to an 
ASCII (or ASCII-like) pseudo terminal (which in turn usually involves 
emulation).
C3270 must convert the EBCDIC 0xC1 to ASCII 0x41, and same for the rest 
of the printable characters.

There must be A/E translation for textual 3270 emulators like C3270.

Over the years, the most common translations developed around CP500 and 
CP37. Sadly, these are not completely compatible. Most characters map 
nicely, but square brackets and one or two other characters are a 
continual pain.
The ASCII side is ISO-8859-1 in most cases, so for emulators like C3270, 
there must be a mapping between CP1047 (for example) and ISO-8859-1. 
Many people lost many hours grasping for the ideal translation table.
BUT NOW the world has gone Unicode. Most of your "ASCII" systems 
actually speak UTF-8. That definitely belongs in a separate reply.


Does this help?

-- R; <><


On 10/10/23 12:18, jgmauta...@yahoo.com.ar wrote:

Hi!
I want to understand how TN3270 emulation works regarding convertion of 
characters (between EBCDIC and ASCII, and viceversa).
This is how I think it works (more or less), but I am not sure at all. So 
please let me know about any mistakes.
Let suppose that you use a TN3270 emulator program to access the ISPF browser to display a dataset. 
Let also assume, to simplify, that it contains just a single character, an "A".In DASD, 
what is indeed stored is X'C1' or, to be more accurate, BINARY'1100 0001'. When you BROWSE the 
dataset, then the Mainframe sends to the TN3270 PC client exactly X'C1' (BIN'1100 0001'). No 
convertion is done at the Mainframe side. Then, when the TN3270 client receives X'C1', because it 
knows that this is a TN3270 session and that its configured CODEPAGE is say 500, it realizes that 
X'C1' corresponds to an "A" displayable character. And, before sending the instruction to 
display it on the PC screen, it converts X'C1' to X'41'.
Is this more or less how this works?
Thanks in advnace for your help,

Juan Mautalen

--
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: Error messages (a rant and an idea)

[Rick Troth]

A confluence of several things.
First, z/VM has a facility (been there for decades) that facilitates 
(sorta) what you're talking about.
MVS people, please don't shrink back. We can easily have the same 
service on z/OS.


When I was in a previous gig, someone had used the VM message handler to 
mix Messages and Codes with interactive messaging.
In another gig, I followed that and added mnemonics (because in that job 
we had several hundred unique condititions with English-looking 
symbols). Another colleague had cobbled-up a handler for z/OS.

The result was ...

 * the message (to be displayed at runtime),
 * what it means (in case it was not already clear),
 * what to do about it (call it "user action"),

 ... and the mnemonic if relevant. Then we had a tool, shared with 
customers, which would pull out the second (details) and third (action) 
bullet.


I think I mentioned the VM message content handler here before: I wrote 
a work-alike for POSIX systems, which the Wizard compiled on USS.
It needs a bit more work before it can do the multi-bullet thing 
discussed above, but that's in the plan.


I feel your pain, Lionel. I would argue that error messages from any 
subsystem (or application) should be concise (usually a one-liner), but 
*not* end with just return code and reason code. Then further details 
should be readily available, web at least or a quick command, because 
"concise" is just not enough for some customers. (Everybody's different.)


-- R; <><


On 9/18/23 08:06, Lionel B. Dyck wrote:

I submitted this IBM Idea and would appreciate your support if you’re able
to vote:

https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3827

The text is:

Title:
All error messages for shell tools should be complete and NOT require
referencing a Messages and Codes manual

Text:
Receiving a message like this (example from DSFS dsadm command): IDFS00329E
Could not set creation parameters, return code 126 reason code ED07621A. Is
confusing and meaningless to the average OMVS shell user. They are not used
to finding a messages and codes manual (which is so last millennium) and
using Google/Bing/... is useless in finding this, and similar, messages.

All shell commands that run under OMVS should provide clear, and complete,
messages without requiring the user to find a messages and codes manual. The
days of the 1960's and 1970's to


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

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

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



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

Re: With regrets, after many years I will no longer be following IBM-MAIN

[Rick Troth]

Back in the days of NetNews, there was .
See #3 of the verb.

https://en.wiktionary.org/wiki/plonk

In the case of your personal news reader (or for us, your particular 
email client) this is effective.
For LISTSERV (sans the feature Gabe suggests), it rests upon the list 
admin to remove the plonkee.


Gotta love the onomatopoeic meanings and origins of the word!

-- R; <><


On 8/31/23 15:03, Gabe Goldberg wrote:

For decades, I've wished for a list setting:

Set bozo  on

...which would allow the subject person to post and see posts 
reflected back, but not inflict them on anyone else. Talking into a 
bottomless well would get boring.


Ed Jaffe

On 8/30/2023 7:12 AM, Kirk Wolf wrote:


Dear ibm-mainers,

It is with regrets that after many years I will no longer be actively 
following IBM-MAIN.


The list has become intolerable because of trolling, off-topic thread 
hijacking, and personal attacks. The signal-to-noise ratio is 
approaching "1".   My assessment is that without some form of 
community governance and real moderation, IBM-MAIN will soon be 
completely useless except for the archives.


This is not the first time this forum has been hijacked. Everyone knows
who the troublemaker(s) is(are).

What I do is set up email filters to send those posts directly to my
Trash folder. I never see them.

Doing so is a lot easier than pressing the  key over and over...

--
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: With regrets, after many years I will no longer be following IBM-MAIN

[Rick Troth]

Thanks for the invite, Lionel. I have accepted it. Maybe see some of you 
there!


Never the less, I will have to remain connected with the LISTSERV list.
We might should have a conversation (here? on Discord? both?) about the 
implications of the different services. It's not a mainframe topic, but 
kinda important. (And I mean beyond comfort zone and religion and 
politics.)


A couple others have already mentioned the value of the traffic.
Also, Phil suggested using alternative client programs and mixing modes. 
Like Phil, I use a dedicated client program, but also use the web 
interface.
It helps to be able to sort and filter, selectively deleting subjects or 
submissions which are "noise" or even those which I just can't use.


I use Thunderbird. It has OpenPGP built-in since circa 2020. Phil uses 
Outlook. I've used that too, and really like it. (But not as happy with 
its PGP/GPG integration.)
Speaking of PGP, I do wish that the list accepted attachments so I could 
sign my posts. (That's one thing you get from most Discord-like 
services, a bit more assurance of the identity of the submitter.)


-- R; <><


On 8/30/23 10:21, Lionel B. Dyck wrote:

There is now an option - the System Z Enthusiasts discord server.

Join here https://discord.gg/dvPuM5dg2Y

Please do so with the goal of sharing in the system z community with your
knowledge and expertise, or to ask questions that further your skills and
the profession.


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

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Lance D. Jackson
Sent: Wednesday, August 30, 2023 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: With regrets, after many years I will no longer be following
IBM-MAIN

I completely agree with your assessment Kirk.  With all of the other social
media options for venting ideological viewpoints, I would hope that IBM-MAIN
can return to it's techie roots and be a place where professionals can share
their experiences and wisdom.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Kirk Wolf
Sent: Wednesday, August 30, 2023 10:12
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: With regrets, after many years I will no longer be following
IBM-MAIN

Dear ibm-mainers,

It is with regrets that after many years I will no longer be actively
following IBM-MAIN.

The list has become intolerable because of trolling, off-topic thread
hijacking, and personal attacks. The signal-to-noise ratio is approaching
"1".   My assessment is that without some form of community governance and
real moderation, IBM-MAIN will soon be completely useless except for the
archives.

I want to sincerely thank all of the extremely knowledgeable and kind
contributors from whom I have learned so much.   You are more than welcome
to contact me directly for questions in my area of expertise.

Kirk Wolf
Dovetailed Technologies
http:// coztoolkit.com

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

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

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


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

Re: On-Prem to Cloud Mainframe Migration Experiences

[Rick Troth]

The Cloud is sexy. It's the current shiny thing. It's the popular trend.
Reality is that cloud tech is simply a resurrection of service bureaus 
from years back. That's not a judgement pro or con. But if your business 
opted to move AWAY from the service bureau then why do you want to 
RETURN by way of the Cloud?


Cloud is nothing more or less than outsourcing.
Outsourcing makes a lot of sense for a whole lotta reasons. And 
sometimes it doesn't.
I recommend a hybrid approach in all cases: think carefully about what 
you will and will-not outsource.
I was with Voltage Security for 7 years. Their centerpiece is 
format-preserving-encryption. Many of our customers wanted to migrate 
selected workloads to the cloud. It's a great use case for FPE, and in 
those situations I advised that they go ahead and move processing to the 
cloud while keeping the keys on-prem.


When considering a cloud migration, be diligent to peel-back the emotion 
(discomfort) of moving certain computing work off-site and consider the 
factual risks. If the risks are low, then go! If the risks outweigh, 
then stay.


I really appreciate the experience Steve recounts. So many of these 
projects have failed to account for hidden costs and other such factors.

I've personally encountered some and witnessed too many from a distance.
Here are some points:

 * break it down into smaller chunks (move a few applications or 
services at a time, not all at once)
 * avoid re-write (if you've got working COBOL, don't convert it to 
Java, for example)
 * consider architectural needs (if you're on Z, should you continue on 
Z?)
 * be open to re-compile (if you're using Linux on Intel, you might do 
fine with Linux on ARM from your cloud service, maybe)
 * beware beneficiaries (if someone is getting a hefty bonus on the 
deal, they might not be objective, or "follow the money")
 * own what matters most (retain control of your actual business, maybe 
keep crypto keys on-prem, just one example)
 * get it in writing (ensure that all parties recognize and "sign" the 
requirements, deliverables, and margins), and speaking of margin

 * build-in some margin (there WILL BE overruns, prepare for a percentage)
 * get objective help (a consultant or several or even a contracted 
partner)


Regarding architecture, Z is initially about that awesome hardware. But 
you might need z/OS itself, for which you can get a range of supporting 
hardware and/or emulation.
Lance mentions DB2, and we know that "DB2" on AIX is not the same as DB2 
on MVS.


Regarding re-write, there's no code more reliable than that which has 
been vetted over years (decades) of use. New code always has bugs. A 
re-write will therefore introduce bugs.
This must of course be considered in context: if you're changing the 
system then you might uncover old bugs never seen before.


I'm surely missing something important. But this is a forum, so someone 
else might see what I missed and chime in. :-)


-- R; <><


On 8/30/23 10:17, Steve Thompson wrote:
I do not have any experience with "cloud" mainframe per se. I do have 
experience with CaaS (Compiling as a Service). Contact me off line if 
you want into on that.


I do have experience with outsourced mainframes having worked for ACS 
when they were in the biz.


Per that experience, I predict that the initial costs will be 
wonderful and about 5 years out the costs will be above what was 
expected with a consideration of migrating back to in house (prem).  
Just based on how things went with ACS and some of its competitors 
where we had entities come in and go out.


Steve Thompson

On 8/21/2023 2:22 PM, Lance D. Jackson wrote:

List,

Has anyone had experience (good or bad) with migrating their 
mainframe Db2 workload from on-prem to the cloud?


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

securing the trust store [was: Firefox and HMC self-signed cert]

[Rick Troth]

I changed the subject.
Also, while this fork is not specifically a mainframe topic, it's really 
important, and most of us will have it thrown in our face, even as 
mainframers.



On 8/29/23 15:29, Grant Taylor wrote:

On 8/29/23 10:46 AM, Charles Mills wrote:
Don't want to get into one of the peeing contests that have become 
all too common here.


Neither do I.

I do want to have a polite and professional discussion about what 
things are capable of.


Hopefully I'll learn things from you -- I usually do.  :-D  Maybe, if 
I'm very lucky, I'll teach you something.  :-)



Same here.
And I confess to being contrarian.
I relish butting heads with Alan Altmark over things like MAC vs DAC. 
(It's not for the head butt, which hurts, but for sake of digging down 
to the foundation.)





Let me just say that never mind any enterprise PKI CA constraints, I 
think Tom was talking about OpenSSL on a PC.


Why elide what is a very germane safety component?  That being 
restricting what a given CA is allowed to sign?


OpenSSL stores private keys -- private keys -- in a pretty accessible 
format.



The *format* really doesn't bother me, other than w/r/t processability.

It's true that complicated access methods will slow down an attacker. 
Problem is they also slow down legitimate work, and that effect is 
multiplied. (Attacker only needs to succeed once; the good guy must 
succeed time after time after time.)





OpenSSL /can/ store the private key in a file.

OpenSSL /can/ /also/ depend something like a YubiKey to store the 
private key.


If I can get into Tom's PC -- perhaps while he is at lunch, or with a 
clever phish -- and get that private key, then I can generate server 
certificates for any site in the world and Tom's associates will 
trust those certificates.


Maybe, maybe not.  It will depend if the private key is password 
protected or not.  If there is a password, it won't be a walk up and 
sign without knowing the password.


Not criticizing Tom or his processes here. Just pointing out to 
readers that there are some significant risks in general to the 
approach of "oh, I will just create an ad hoc CA and have my users 
trust it."



I agree it's not effective for everyone to run their own CA. But for 
purpose of education, a "live" in-house CA comes in handy.





I agree that there are risks.

It's a question of which is more risky long term:

1)  training users to click past certificate warnings
2)  the potential for someone to abuse Tom's CA which is constrained 
to the enterprise domain name and has a hardware token (YubiKey)?


It's all about the lesser of the evils.



YES

And making it harder (more expensive) for the attacker (relative to his 
ROI).





Trusting a CA is implicitly trusting everything that anyone does with 
its root private key.


That's where a constrained CA / root key comes into play.

Trusting the key to sign *. is very bad.

Trusting the key to sign *.example.com, not so much so. Especially if 
example.com is a private internal domain not possible to use in the 
real world.


Yes, it is no different in some ways than trusting DigiCert. The 
difference is that DigiCert has very rigorous protocols for 
protecting its root private keys. OpenSSL does not.


It's possible for Tom, et al., to make reasonable approximations of 
what DigiCert, et al., are doing.  If Tom's company wanted to, they 
can purchase a more professional Hardware Security Module (HSM) that 
can get quite close to what more professional entities do if they so 
choose.


But using something like a YubiKey to hold the root key of for an 
enterprise CA constrained to the internal domain is probably 
reasonably safe.  Especially if said YubiKey is used to sign an 
intermediate certificatte -- like the big kids do -- and storing said 
YubiKey disconnected, in a safe in between uses once a quarter.  
Especially if the system that does the signing is disconnected from 
the network.



I've been simmering a blog post about MFA since GitHub pressed the issue 
recently.
YubiKey is part of that because it can become a new single point of 
failure.
In all of this, one of the biggest overlooked thingies is new points of 
failure. We forget that locking out bad guys kinda sucks for US when WE 
suddenly look like one of the bad guys. (Machines cannot tell the 
difference.)


This is not a slam on YubiKey.
It's an observation that our systems need failover factors and most 
developers still don't think about that.





I think it's well within reason for individuals, and especially 
businesses to fairly safely have an (Enterprise) CA that is 
constrained to their organization.




Grant. . . .

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



-- R; <><

--
For IBM-MAIN subscribe / signoff / 

it's all about trust [was: Firefox and HMC self-signed cert]

[Rick Troth]

On 8/29/23 11:24, Grant Taylor wrote:

On 8/29/23 10:07 AM, Tom Brennan wrote:

And you can specify an expiration far in the future.


Remember, some web browsers are capping the limit on the lifetime of 
certificates they will work with.



The browser producers have the advantage over the rest of us because 
they affect such a large percentage of consumer clients.
When they say "certificates shall only last a year", there's little we 
can do about it, whether they're right or wrong.


They're wrong. They're at least "imperfect" in a conversation where 
perfection is the goal. So ... they're wrong.
Shortening the viability lifetime brings hidden costs that the browser 
makers either don't see or don't care about. (Covering their own arse. 
They have no incentive to cover yours.)
By contrast, physical indicia (credit cards, driver licenses, and other 
IDs that some of us cannot speak about) have lifetimes/expirations five 
years out.
Shorter lifetimes for web site certs generate business for CAs and make 
work for web site admins. The latter is increasingly error prone. But 
higher frequency replacement is considered "more secure". It's like 
killing the dogs and cats during the plague, when they were the natural 
enemies of the true carriers of the disease.


We protect the wrong things. (And we kill the wrong critters.) We also 
sprinkle such ideas as faster cert replacement and technology like 
cryptography as if it's fairy dust magically making things better. 
Crypto alone doesn't make your systems secure. Faster refresh does not 
improve your posture all by itself.


Charles suggested snagging the private key from the CA. That's exactly 
the kind of attack a smart adversary would take. It's way less expensive 
and more likely to result in exfiltration of cleartext.
If the CA is breached, then the issued certs are just as invalid on day 
one as they are on day 398. In that case, what has the shortened 
lifetime bought us?


This is not to say that fast cycle advocates are idiots. Most of them 
are prolly way smarter than I am. It's just that they stopped short of 
solving the real problem. (And some of them are opportunists: if they 
can get you to buy their wares in a panic, then they've made a pretty 
penny and can retire sooner.)


I almost regret this note because I haven't really offered a solution. 
Some say "security is a process". I hate that slogan, but it's kinda 
true. I DO say that we're foolish to try and shrink-wrap security into 
store-shelf remedies. There's no alternative to educating the staff.



-- R; <><

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

Re: GAO recommends upgrades at IRS, Dept Defense Logistics

[Rick Troth]

"Nor is the watchdog happy about the tax agency’s continued use of 
COBOL, which they note,
could lead to 'difficulty finding employees with such knowledge,' adding 
that this
'shortage of expert personnel available to maintain a critical system 
creates significant risk to an agency’s mission.'"


I'm not a COBOLer, but this is ignorance on part of the GAO as they 
listen to popular marketeering from a number of voices in our industry.


COBOL is *not* a dead language. Dr. Cameron Seay has been teaching COBOL 
to his students in Tennessee and Carolina for years, rewarding their 
academic efforts with high paying jobs and a fair amount of renown.


To confirm the viability of COBOL, I ran a quick compile, link, and 
execute this morning. This was on PC hardware running Linux and was done 
via shell script rather than JCL. COBOL is not only alive and well but 
works great on non-mainframe systems.


The most reliable code is code which you don't have to modify. Salesmen 
calling for replacement of COBOL simply because of its age are trying to 
sell you something. Beware their snake oil. Working COBOL is far better 
than untested (even as yet unwritten) Java, or even C or Python. 
Ditching COBOL because of its age as a language is illogical. It's 
another gubmint mandate likely to ramp-up costs on the overburdened US 
taxpayers but fail to deliver on promises.


A smarter direction is to ensure currency of supporting systems and then 
integrate with the newfangled shiny things. Hopefully the IBM contract 
will help the GAO see the light.


-- R; <><


On 8/28/23 18:48, Mike Schwab wrote:

https://planetmainframe.com/2023/08/mandates-and-talent-shortages-are-driving-big-spending-on-modernization/

IBM is one contractor.



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

Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]

[Rick Troth]

The list of OS and HW pairs ...

    AIX-powerpc (or "ppc")
    AIX-powerpc64 (or "ppc64")
    CYGWIN-i386
    CYGWIN-x86_64
    Darwin-i386
    Darwin-x86_64
    Darwin-arm64
    FreeBSD-i386
    FreeBSD-amd64
    HPUX-parisc
    HPUX-ia64
    Linux-i386 (or i486, i586, i686)
    Linux-x86_64
    Linux-s390
    Linux-s390x
    Linux-alpha
    Linux-arm
    Linux-arm64 (Linux-aarch64)
    Linux-m68k
    Linux-mips
    Linux-mips64
    Linux-ppc
    Linux-ppc64
    Linux-ppc64le
    Linux-sparc
    Linux-sparc64
    Minix-i386
    NetBSD-i386
    NetBSD-amd64
    OpenBSD-i386
    OpenBSD-amd64
    OS390-s390
    OS390-s390x
    SunOS-i386 (Solaris-i386)
    SunOS-x86_64 (Solaris-x86_64 or Solaris-amd64)
    SunOS-sparc (Solaris-sparc)
    SunOS-sparc64 (Solaris-sparc64)
    Windows-x86 (Windows-i386)
    Windows-amd64

This is not an exhaustive list, just the pairs I've worked with. And 
some are old: I haven't touched Linux-alpha in a lllooonnnggg time. I 
also really only use one of the BSDs.


Some of the systems are bi-modal: AIX, Linux-s390x, and OS390 are all 
64-bit systems these days, but usually still support 32-bit "user space" 
programs.


The names, both left and right, are taken from 'uname' output. I 
regularly butt heads with a good friend over names like "powerpc", but 
that's what the systems say about themselves.


-- R; <><


On 8/24/23 15:23, Rick Troth wrote:

This topic has gotten fun.

RPM has an advantage over some installer methods that it includes the 
architecture (e.g., "x86_64" or "s390x").
Sadly, it does *not* include the operating system (e.g., "Linux" or 
"OS/390").

But, yeah, effective and widely used.

Tools like YUM (for RedHat) and ZYPPER (for SUSE) sit on top of RPM. 
(YAST is another layer up from ZYPPER and is SUSE's equivalent to 
AIX's SMIT, but less painful.)
In my experience, they're well done. (YAST is excellent.) You can 
still install packages directly with 'rpm' and either YUM or 
ZYPPER/YAST will figure things out, not break nor crash.


We're skipping the tools used in AIX, Slolaris, HP-UX, and others. 
It's not rocket surgery.


Dependencies are always a problem when you stray outside the 
distributor/vendor collection.
Many times 'rpm' has complained about dependencies/pre-reqs/co-reqs. 
When I force the install, it usually works. Not always. Sometimes I 
have to manually sym-link a shared lib with an older name.


For many years, I've used a point-n-shoot scheme, lately called 
Chicory. (Didn't originally have a name.)
I use this for packages that I build from source. Once a package is 
built for a slightly older (e.g.) RedHat Linux, said packages work 
just fine on a slightly newer SUSE Linux or Debian Linux (of the same 
HW architecture). Not always, but I've learned to isolate 
co-reqs/pre-reqs/dependencies. Static linkage helps. In Chicory space, 
the OS (e.g., "Linux" or "OS/390") and the HW (e.g., "x86_64" or 
"s390x") are always indicated. This developed over more years than I 
should admit. I'll enumerate in a separate note.
But I can't promote Chicory here: it's painfully close to TAR and ZIP 
for delivery. (Then again, those *do* work, and are stilled used today 
by vendors that I've worked for, so mebbe.)
Right now it only handles RSYNC or NFS or removable media. Doesn't 
actually do TAR as such. (Acorse, if someone wants to contribute ...)


-- R; <><


On 8/24/23 14:57, Steve Thompson wrote:
With Linux distros there are a few maint systems. The one I am most 
familiar with is RPM.


To me YAST (the Linux equivalent of SMP/E) handles upgrades and user 
changes (if you know how to do them, I don't because I'm a SU in 
Linux -- Stupid User).


Each product/component has its own main entry and then dependencies. 
You can override them if you dare. If you are a developer you would 
probably know if the override is a good idea.


So you decide to download an ISO. If you have a fat pipe and the 
time, you download a NETWork install ISO.


You fill in all the stuff (Upgrade install or "NEW" INSTALL are the 
primary options). The system loads and boots and if this is a "NEW" 
install, formats and load partitions etc. etc.


Then it gets into all the stuff you said you want installed so it 
pulls down all the related/needed repositories and packages and goes 
to work.


At a certain point it reboots to the system it has built and then 
continues with the applications level stuff.


From time to time you get notified, or you just check it yourself, 
and see if there is maint to be added. Yast handles it.


I thought it was a fairly good replacement for SMP/E for the Linux 
side of things. I can see how it could be used to do z/OS and 

Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]

[Rick Troth]

This topic has gotten fun.

RPM has an advantage over some installer methods that it includes the 
architecture (e.g., "x86_64" or "s390x").
Sadly, it does *not* include the operating system (e.g., "Linux" or 
"OS/390").

But, yeah, effective and widely used.

Tools like YUM (for RedHat) and ZYPPER (for SUSE) sit on top of RPM. 
(YAST is another layer up from ZYPPER and is SUSE's equivalent to AIX's 
SMIT, but less painful.)
In my experience, they're well done. (YAST is excellent.) You can still 
install packages directly with 'rpm' and either YUM or ZYPPER/YAST will 
figure things out, not break nor crash.


We're skipping the tools used in AIX, Slolaris, HP-UX, and others. It's 
not rocket surgery.


Dependencies are always a problem when you stray outside the 
distributor/vendor collection.
Many times 'rpm' has complained about dependencies/pre-reqs/co-reqs. 
When I force the install, it usually works. Not always. Sometimes I have 
to manually sym-link a shared lib with an older name.


For many years, I've used a point-n-shoot scheme, lately called Chicory. 
(Didn't originally have a name.)
I use this for packages that I build from source. Once a package is 
built for a slightly older (e.g.) RedHat Linux, said packages work just 
fine on a slightly newer SUSE Linux or Debian Linux (of the same HW 
architecture). Not always, but I've learned to isolate 
co-reqs/pre-reqs/dependencies. Static linkage helps. In Chicory space, 
the OS (e.g., "Linux" or "OS/390") and the HW (e.g., "x86_64" or 
"s390x") are always indicated. This developed over more years than I 
should admit. I'll enumerate in a separate note.
But I can't promote Chicory here: it's painfully close to TAR and ZIP 
for delivery. (Then again, those *do* work, and are stilled used today 
by vendors that I've worked for, so mebbe.)
Right now it only handles RSYNC or NFS or removable media. Doesn't 
actually do TAR as such. (Acorse, if someone wants to contribute ...)


-- R; <><


On 8/24/23 14:57, Steve Thompson wrote:
With Linux distros there are a few maint systems. The one I am most 
familiar with is RPM.


To me YAST (the Linux equivalent of SMP/E) handles upgrades and user 
changes (if you know how to do them, I don't because I'm a SU in Linux 
-- Stupid User).


Each product/component has its own main entry and then dependencies. 
You can override them if you dare. If you are a developer you would 
probably know if the override is a good idea.


So you decide to download an ISO. If you have a fat pipe and the time, 
you download a NETWork install ISO.


You fill in all the stuff (Upgrade install or "NEW" INSTALL are the 
primary options). The system loads and boots and if this is a "NEW" 
install, formats and load partitions etc. etc.


Then it gets into all the stuff you said you want installed so it 
pulls down all the related/needed repositories and packages and goes 
to work.


At a certain point it reboots to the system it has built and then 
continues with the applications level stuff.


From time to time you get notified, or you just check it yourself, and 
see if there is maint to be added. Yast handles it.


I thought it was a fairly good replacement for SMP/E for the Linux 
side of things. I can see how it could be used to do z/OS and 
related.


Thoughts, and comments?

Oh, and I still only do programming on IBM type Mainframes.

Steve Thompson

On 8/24/2023 2:34 PM, Jon Perryman wrote:
  > On Thursday, August 24, 2023 at 11:06:43 AM PDT, Colin Paice 
 wrote:

But this fix management would be done by IBM (or product owner).


I'm guessing that IBM is still on a 2 year release cycle and they 
still have a custom-built offering so you're not dealing with a lot 
of tapes and files. With as many products that IBM deals with, 
packaging would be a nightmare. IBM's RHEL and other Linux distros 
exists solely to simplify the process and they don't deal with 
anywhere near the number of IBM z/OS products. SMP/e is a good 
compromise that guarantees everything was performed correctly for 
your needs. OEM vendors can easily provide choices because they don't 
deal with the magnitude of IBM.




 On Thursday, August 24, 2023 at 11:06:43 AM PDT, Colin Paice 
 wrote:

    ITSchak,
But this fix management would be done by IBM (or product owner).  We 
should

be able to download the image which has been tested by IBM Consolidated
Service Test in POK.
Only if you need >additional< fixes before the next download - do you 
need

to do any SMP/E work. It would still be there if you need it.
Colin

On Thu, 24 Aug 2023 at 17:08, ITschak Mugzach  
wrote:



Kurt,

I think the power of SMP/E is not the initial install, but the fix
management (ptf chain management). Actually many deliveries from IBM 
have
SMP/E already populated and technically this is a kind of DSS dump 
(or can

be).

ITschak


ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous 
Monitoring

for z/OS, x/Linux & IBM I **| z/VM coming soon  *

Re: Strange results for the PS1 prompt with z/OS Unix

[Rick Troth]

> I want to agree, but I can't.
>  I've seen too many differences across too many platforms and too 
many Unix (like) OSs.
>  Getting consistent behavior can become very tricky and you quickly 
end up away from the purity that -- I think -- that you are talking about.


You understand what I am talking about.

I didn't mean to imply that all vendors ("distributors" in the Linux 
case) get this stuff right.
EXPECT IT, where "expect" means "to require" not "to presume upon". Hold 
their feet to the fire when the break shit.

It's not difficult, but it does count for "eternal vigilance".

Speaking of breaking shit, I've been more pleased than disappointed by 
one particular distributor.
SUSE have worked hard to make stuff work, even in the fact of contrary 
popular trends. (I won't enumerate now for sake of brevity.)


Then:
(talking about login versus child shells and "profile" versus "resource 
config")


> The water starts to get murky when you start using the same shell
> for both interactive (ostensibly with a TTY) and non-interactive
> (ostensibly without a TTY) use.  E.g. the former is your login shell
> and the latter is a script using the same shell.  Sometimes you want
> different configurations of that shell based on it's use case.

(other stuff cut for brevity)

Yes, murky indeed.

Stephen Bourne recognized the overlap between interactive commands and 
scripted commands and *intentionally* made his shell a language 
interpreter.
Bill Joy criticized it as unfriendly for interactive work, and Bourne 
conceeded. If one must use a different shell for keyboard input than for 
scripting, there is the C shell.
But BASH has absorbed many of the conveniences of C shell. I expect KSH 
has too (but I don't know it as well as you do). With KSH and BASH, who 
needs CSH?


The problem is, when people use the C shell (Joy's brainchild) and then 
think to script a sequence of commands they had entered interactively 
... train wreck.
While C shell may be better for interactive work (than olde Bourne), it 
is widely criticized as poor on the scripting front. And people use what 
they know.
I've chosen to "know" and teach Bourne-ish shells in both modes. When I 
cobble-up a nifty sequence, I can immediately copy-n-paste that into a 
file for re-use later. This is good practice.


> #needMoreCoffee

mee too!

Meanwhile, ALL Bourne-compatible shells are supposed to source 
/etc/profile when invoked in "login" mode. I know that BASH, ZSH, PDKSH, 
and DASH all do. It's when the per-shell custom variant exists that 
/etc/profile gets skipped.


-- R; <><


On 8/18/23 10:27, Grant Taylor wrote:

On 8/18/23 8:33 AM, Rick Troth wrote:
About profiling, I regularly setPS1='\$ ' which for BASH renders a 
prompt as "$" for normal users but as "#" for superuser. It's 
convenient.

ZSH shows that as "\$" and does not change it when I change UID.


Zsh has similar behavior.

Zsh uses different escape sequences for the prompt PS1 et al. than 
Bash does.


Check out the PROMPT EXPANSION of the zshmis (or zshall) manual pages.

Look into %# in the Zsh prompt as it will give you # for root and % 
for non-root.



This is *not* a slam on ZSH, just an observation.


There are many differences between Zsh and Bash.  Prompt (PS1 et al.) 
is just one that surprises a lot of people.


In search of better profiling, /etc/zprofile should source 
/etc/profile and then override as needed. (PS1 being a prime example, 
eh?)

Or ~.zprofile sourcing ~.profile, same logic and rationale.


I want to agree, but I can't.  I've seen too many differences across 
too many platforms and too many Unix (like) OSs.  Getting consistent 
behavior can become very tricky and you quickly end up away from the 
purity that -- I think -- that you are talking about.


There are two levels: profiling which should happen when you sign on 
(once) and "resource config" which gets invoked every time a program 
starts.


Eh

The water starts to get murky when you start using the same shell for 
both interactive (ostensibly with a TTY) and non-interactive 
(ostensibly without a TTY) use.  E.g. the former is your login shell 
and the latter is a script using the same shell.  Sometimes you want 
different configurations of that shell based on it's use case.


Then you get into even more esoteric things like is your interactive 
shell a login shell or a non-login shell (possibly started from inside 
your login shell).


Aside:  Some people start additional interactive non-login shells from 
their interactive login shell as a way to divide command history or 
have different features for a task at hand.  E.g. in the long process 
of working on something that takes many hours and need a shell briefly 
to fix something / unclog a printer, then start an interactive 
non-login shell, do the maintenance work therein

Re: zsh (was: Strange results for the PS1 prompt ...)

[Rick Troth]

On 8/18/23 11:42, Paul Gilmartin wrote:

On Fri, 18 Aug 2023 15:16:13 +, Seymour J Metz wrote:


As long as they included something that looked like the Bourne shell, adding 
other shells as options wouldn't have affected POSIX and X.OPEN compliance.


Bourne shell falls considerable short of POSIX and X.OPEN compliance.
I once told an antiquarian of a SunOS 4 /bin.sh deficiency (tilde expansion,
IIRC.)  He quickly remarked, "Oh, that's Bourne shell."  I believe Bourne
also lacks "$( ... )" command substitution.Perhaps obsessed with
portability, I test some scripts with dash.



DASH is an excellent test shell for shaking out compatibility problems.


Acorse, the best option would be to run scripts against *several* shells 
(and DASH, BASH, ZSH, and PDKSH are all easy to come by).



We're not after Bourne as such, just the common superset. (Where we see 
that both ZSH and BASH vary.)
We're also (here) not talking about interactive shell, but we've drifted 
into scripting.







Preferences in e.g., desktop managers, languages, operating systems, are highly 
subjective; if it works for you, that's what matters.

Now, if you're working on a large project hen some standardization is needed; 
again, if the choices made on the project work for the project, that's what 
matters.


Requirements are stricter for ISVs targeting multiple platforms and FOSS 
developers.



Indeed!
But I always press my teammates (sometimes ISV, but not for the current 
gig) to make their shells portable. It's not difficult and prevents 
"oooppss" when someone else takes their script in a different direction.



https://github.com/trothr/best/blob/main/Shell.md



-- R; <><




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

Re: Strange results for the PS1 prompt with z/OS Unix

[Rick Troth]

ZSH is a powerful shell and serves as an example of the need for clean 
and generic profiling.
I don't use ZSH heavily, but I maintain it in the Chicory collection. 
(see below)


About profiling, I regularly setPS1='\$ ' which for BASH renders a 
prompt as "$" for normal users but as "#" for superuser. It's convenient.

ZSH shows that as "\$" and does not change it when I change UID.

This is *not* a slam on ZSH, just an observation.
In search of better profiling, /etc/zprofile should source /etc/profile 
and then override as needed. (PS1 being a prime example, eh?)

Or ~.zprofile sourcing ~.profile, same logic and rationale.

There are two levels: profiling which should happen when you sign on 
(once) and "resource config" which gets invoked every time a program 
starts.
RC scripts for shells should look for a sacred "I have been profiled" 
environment variable and source appropriate profiles if it is not set.
But RC scripts should not completely re-profile because they (the RC 
scripts) get sourced every time a shell starts.
RC scripts of interest in this context would be ~.zshrc and ~.bashrc (or 
/etc/zshrc and /etc/bashrc if you're the sysadmin).

Does this make sense?

I started the Chicory collection when I worked in academia because I 
didn't want to be on [name your platform] and not have various tools. 
BASH was one. (I didn't know about ZSH in those days.)
It has grown and gotten honed. Most open source packages build really 
easily. (Not as easy on USS, but that's a whole nutha story.) The 
collection includes *five* shells, currently  ...


 * bash-5.2.15
 * zsh-5.9
 * pdksh-5.2.14
 * dash-0.5.12
 * tcsh-6.24.10


So that's BASH, ZSH, KSH, DASH, and a C-shell variant. (Long story about 
C-shell. Let's just say, you don't wanna.)



-- R; <><


On 8/18/23 05:38, David Crayford wrote:
What version of bash are you using? Rocket software's port or IBM z/OS 
Open Tools?


Irrespective, bash is an enhanced ASCII application so make sure you 
have the following environment variables set in your profile login 
scripts by entering "env | sort" from the shell command line.


_BPXK_AUTOCVT=ON
_CEE_RUNOPTS=FILETAG(AUTOCVT,AUTOTAG) TERMTHDACT(UADUMP) ABTERMENC(ABEND)
_TAG_REDIR_ERR=txt
_TAG_REDIR_IN=txt
_TAG_REDIR_OUT=txt

Incidentally, I noticed that IBM are shipping zsh as part of z/OS 3.1 
so bye, bye bash.


I've being using zsh for years and it turbo charges the shell. For 
example, there are open source themes such as oh-my-zsh and 
powerline10k. The powerline customizes PS1 with fancy glyphs. The 
current Git branch, commits and other information is shown. It's next 
level to the dull one your using :). Also, there is 
zsh-autosuggestions which recalls previous commands for auto 
completion. oh-my-zsh also provides a plugin for git command 
completion and other super cool command completions that make using 
the shell as easy as an IDE.


https://github.com/ohmyzsh/ohmyzsh/tree/master
https://github.com/romkatv/powerlevel10k
https://github.com/zsh-users/zsh-autosuggestions

To enable the cool glyphs you will need to install Nerd fonts and 
configure your terminal emulator. If you're a Windows user and using 
PuTTY I recommend switching to Windows Terminial (preferably with 
WSL2) which has tabs, tiled windows and is just miles better. If 
you're on a Mac like me it's easy to configure Termimal, iTerm2 or 
whatever emulator you use. Same with Linux desktops. On z/OS "export 
TERM=xterm-256color"


In the meantime, there is a port of powerline-go as part of the Z/OS 
Open Tools project. If you have downloaded the installer you can 
install it simply by running "zopen install powerlinegoport".


https://github.com/justjanne/powerline-go   # instructions how to 
configure it with bash


*Z Shell (Zsh) on z/OS*

The Z Shell (Zsh), specifically Zsh 5.8.1, has been ported and made 
available on z/OS 3.1. Zsh is a UNIX command interpreter that is used 
as an interactive login shell and as a shell script command processor. 
It has command-line editing, built-in spelling correction, 
programmable command completion, shell functions (with autoloading), a 
history mechanism, and a host of other features. With the 
extensibility, rich customization, and advanced features, Zsh provides 
a modern and powerful shell on z/OS. It is designed to accelerate 
users' daily work and have consistent behavior with other open platforms.


On 17/8/2023 11:31 pm, Tom Longfellow wrote:
I am confused and am throwing out a Hail Mary for help.   Here is the 
situation.

Two cloned LPARs.  (same sysres and unix root file systems)

On system 1 - the /etc/profile   has a PS1 of
 export PS1="[\\u@\\H \\W \\@]\\$ "

On system 2 - the /etc/profile  has a PS1 of
    export PS1="[\\u@\\H \\W \\@]\\$ "

Why YES they do look the same... at least they do to me.
-=-=-=
The results however are very different.

On system one the displayed PS1 is
    [TECH905@jismvs_test ~ 11:26 AM]$

On system two the displayed PS1 is
   [\u@\H \W \@]$

Re: Strange results for the PS1 prompt with z/OS Unix

[Rick Troth]

On 8/17/23 12:42, Tom Longfellow wrote:

The value of TERM is xterm.(I have no idea why)



"xterm" has become generic for ANSI X3.64 capable terminals and terminal 
emulators.
Once upon a time "vt100" filled that role, but "xterm" implies more 
capability.


https://en.wikipedia.org/wiki/ANSI_escape_code


-- R; <><

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

Re: Strange results for the PS1 prompt with z/OS Unix

[Rick Troth]

On 8/17/23 11:31, Tom Longfellow wrote:

I am confused and am throwing out a Hail Mary for help.   Here is the situation.
Two cloned LPARs.  (same sysres and unix root file systems)

On system 1 - the /etc/profile   has a PS1 of
 export PS1="[\\u@\\H \\W \\@]\\$ "

On system 2 - the /etc/profile  has a PS1 of
export PS1="[\\u@\\H \\W \\@]\\$ "

Why YES they do look the same... at least they do to me.
-=-=-=
The results however are very different.

On system one the displayed PS1 is
[TECH905@jismvs_test ~ 11:26 AM]$

On system two the displayed PS1 is
   [\u@\H \W \@]$
-=-=-=-=
I am using the same SHELL program in my environment.  (/usr/bin/bash)

Anybody have any ideas why the two different LPARs are reading the same string 
but interpreting it in two different ways?
My suspect is some dark secret settings in the Unix file system.   Total Guess



Good comments in other responses, in particular: code page concerns 
(square brackets, back-tick, stuff like that).


I've struggled to get things to play right with the Unix standard. 
/etc/profile should be sourced at login, but is not always. Also, people 
lately have turned to "RC scripts" (like ~.bashrc). Avoid these for 
PROFILING. Long story.


Some suggestions, things to check:

 * confirm that both systems are giving you BASH (because the PS1
   you're showing is an extension from original Bourne)
 * confirm that BASH is at the same level
 * confirm that /etc/profile is getting sourced *and* that something
   else is not changing things after the fact
 * look for ~.profile (which is supposed to take effect *after*
   /etc/profile, giving you final control)
 * avoid ~.bashrc and other RC scripts (in the near term, until you've
   fixed this)
 * check your code pages, including file tagging


I hope this helps.


-- R; <><




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



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

Re: IBM C/C++ for Open Enterprise Languages

[Rick Troth]

> ... the IBM Open XL C/C++ compiler is not compatible with XL C/C++
> or xlclang compilers. This incompatibility may pose challenges.
> Python 3.11 is developed using IBM Open XL C/C++, while Python
> 3.10 uses xlclang. As a result, binary packages created for
> Python 3.10 won't work with the IBM Open XL C/C++ compiler.

Come again?
Are you saying that object code for this platform produced by one compiler
is incompatible with object code for this platform produced by the other 
compiler?


The broken compiler "can only be used for open source", but open source 
aficionados would surely use the alternative when compiling their wares.

Free as in speech, not just free as in beer.

Perhaps the broken compiler should come with a surgeon general's warning.
(A meaningful reference in the US where cigarette packaging has, now for 
decades, been required to state "this product is bad for you".)


We continue further down the rabbit hole of software being used for 
controlling people rather than software being used for controlling 
machines.


-- R; <><


On 8/9/23 02:58, David Crayford wrote:

As if we didn’t already have enough z/OS C/C++ compilers :)

I've recently been working on Python bindings for z/OS products and wanted to 
share some useful notes. IBM recently released the IBM C/C++ for Open 
Enterprise Languages on z/OS compiler [1], a free version of IBM Open XL C/C++, 
which is a port of LLVM/clang. This compiler can only be used for open source. 
For example, to build Python, Node, go packages that require a build phase when 
installed or contributing to z/OS open source projects. It's important to note 
that the IBM Open XL C/C++ compiler is not compatible with XL C/C++ or xlclang 
compilers. This incompatibility may pose challenges. Python 3.11 is developed 
using IBM Open XL C/C++, while Python 3.10 uses xlclang. As a result, binary 
packages created for Python 3.10 won't work with the IBM Open XL C/C++ compiler.
To overcome this issue, the recommended solution is to build Python distributions that include 
the source C/C++ code. During the installation process using pip, this code can be built. There 
are a few issues with the new compiler. Firstly, there is no support for "OS" 
linkage, meaning no #pragma linkage(module,OS) or extern 'OS' {}. Custom thunk routines need to 
be written to address this.  Additionally, the compiler supports inline assembly, but the 
-qasmlib= option is not available, making macros unusable. A workaround I 
found is to assemble some HLASM code and copy-paste from the listing.
Moreover, the runtime library is not entirely compatible with XL C/C++. I 
discovered that the __amrc structure is missing, which breaks my pzfile package 
and makes accessing VSAM files nearly impossible. I plan to open a case with 
IBM to address this issue.
Another limitation is that the compiler does not produce source/assembly 
listings. Furthermore, thread level storage is not supported, which complicates 
the process of porting certain libraries.

On a positive note, IBM has open-sourced their zoslib library [2], which 
assists in porting applications to z/OS. There is a lot of useful function in 
this library. It supports dynamically loading and calling modules using thunk 
routines. Unfortunately, there is a comment in the code which states it only 
works with xlclang. The library is Apache 2.0 licensed but it has IBM 
copyright. I'm not a lawyer so I'm unsure of the legalities of using this 
library for product code.

[1] 
https://www.ibm.com/docs/en/cloud-paks/z-modernization-stack/2023.2?topic=languages-cc-open-enterprise-zos
[2] https://github.com/ibmruntimes/zoslib


--
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: Automount (was USS Features)

[Rick Troth]

> However it is not reality show or beauty contest, rather I'd like to 
see some real advantages of automount.


Last week I learned of a peculiar use of automount in z/OS which is 
different from my experience and which a storage admin might truly 
dislike: auto-create a (possibly large, in any case yet another to 
manage) USS filespace for each user.

Yuck.
So I get it that some find automount counter productive.

My experience has always been quite different, whether with z/OS or 
elsewhere.
The mounted objects are often sub-directories of a shared space 
(advantage: NOT creating countless additional spaces to manage).
The mounted objects are called for on-demand (advantage: NOT requiring a 
large table of filesystems to mount when the system starts).


I was blown away the first time I ran 'df' on USS. So many things mounted!
And many of them were program products. As a long time Unix person and 
sometime Unix admin, I do find program products to be excellent 
candidates for their own mount point (whether also their own physical 
space or shared).
Automounter could dramatically reduce the number of things needing mount 
at boot time.


My first experience with automounter was for user home directories (in 
that case, always residing in shared spaces on the back end).
But that was the time of shared workstations: a users home dir was not 
mounted until she signed on.


Summary: YES, automount has some advantages, though no, it's not always 
implemented elegantly.


-- R; <><


On 8/5/23 09:08, Radoslaw Skorupka wrote:

W dniu 04.08.2023 o 22:04, Jon Perryman pisze:
  > On Monday, July 31, 2023 at 08:29:07 AM PDT, Radoslaw Skorupka 
wrote:



Regarding automount feature: IMHO it is less than useless.
While there is truth to what you say about automount, there are uses 
where people find it useful because it provides features that some 
customers need. Most notably, everything in a filesystem is randomly 
placed within that filesystem without any controls. Ask a z/OS 
storage admin if he could tolerate the same situation where all z/OS 
datasets are placed randomly (no SMS nor disk esoterics).


I asked storage admin (myself) and heard NO. Automount changes nothing 
to what you described (and what is IMHO disputable, but this is 
different thread).
Oh, BTW: I met many other storage admins in my career. No one liked 
automount feature, usually they didn't express any opinion, but 
sometimes they complain on that.
However it is not reality show or beauty contest, rather I'd like to 
see some real advantages of automount.




 On Monday, July 31, 2023 at 08:29:07 AM PDT, Radoslaw Skorupka 
<0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:

    Regarding automount feature: IMHO it is less than useless.
- It require some effort to establish and manage (including storage 
adm.)

- It wastes space, because even smallest empty home directory occupies
first extent of the ZFS/HFS.
- Space (extents) taken by some large files and then deleted is still
occupied by the user.
- Tools like find may omit currently unmounted directories, sometimes
making the search ineffective.
- I vaguely remember the z/OS Unix does not like excessive filesystems
being mounted.
- Automount/demount consume some resources.
- Last, but not least: I observed the are more active TSO users than USS
users. The same apply to CICS, etc. Sometimes one may enter TSO OMVS
just out of curiosity. In case of automount yet another filesystem is
created.


  From the other hand one can create common filesystems for all home
directories.
When needed it can be divided among multiple filesystems.
Users with large needs may have dedicated filesystems.
Empty user directory does not consume resources. Even "touched".


My €0.02




Regards



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

Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives

[Rick Troth]

On 8/1/23 22:42, Grant Taylor wrote:

On 8/1/23 7:20 PM, David Crayford wrote:
What’s the difference between between channelized I/O and a rack of 
x86 servers connected to a SAN using fibre channel driven by high 
speed HBAs?


I don't know.

My understanding is that Fibre Channel is an evolution of SCSI which 
is supposedly a somewhat intelligent controller wherein the OS asks 
said controller to fetch / store some data for it.  As I understand 
it, the OS & main CPU aren't involved in the transfer beyond asking 
the controller to do the transfer on it's behalf.



SCSI originally had much more limited scale ... by design. The acronym 
expands to "small computer system interface".


I haven't read-up on the details of FCP, but I do suspect it follows 
SCSI yet with dramatically relaxed limits. Operationally, FCP appears to 
be a lot like FICON, and that's channelz.





I'd have to reference documentation to see if / how much Direct Memory 
Access comes into play vs the CPU's involvement in the transfer to / 
from the controller.



DMA is significant.
True: PCs have had DMA in corner cases for a long time.
DMA is part of the equation.




But between the controller and the back end drive, as I understand it, 
the CPU ins't involved.



Right.
A channel processor for an IBM-class "mainframe" operates independently 
of the CPU(s) other than being triggered when a CPU says "go run this 
channel program" and effectively "don't bother me until you're done".





So I can't say that "a rack of x86 servers connected to a SAN using 
fibre channel" isn't using channelized I/O.  I think in many ways they 
are.


This is a place where minutia matters.



If the CPUs are truly free to continue their own work until SAN fibre 
channel independently completes its work, that sounds like a mainframe 
class channel.





Grnat. . . .

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



These things can be hard to pin down. Labeling is sometimes 
counter-productive.


In the automotive industry, is the vehicle a sedan or a van or a 
mini-van or an SUV or a truck?

So in the auto industry, we hear "cross over". [sigh]

I think Jon Perryman first asked us to define mainframe. And I bit!
[voice of Leonard Bones McCoy] "Dammit Jon! I'm a software developer, 
not a field service engineer!"
But it really started with Andrew Hudson at Ars Technica getting a 
number of facts wrong.




-- R; <><

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

Re: Mainframe Makers.... WAS: Ars Technica: The IBM mainframe: How it runs and why it survives

[Rick Troth]

On 8/1/23 15:44, Phil Smith III wrote:

Jon Perryman wrote:

The last Fujitsu mainframe is scheduled for 2030 and dropping all
support by 2035. Honeywell Bull GCOS and Unisys OS 2200 and MCP are
now x86 based. Are these mainframes or are they PCs?

PCframes? mainCs? It is hard to define rigorously, but as someone else quoted SCOTUS, 
"I know it when I see it".

In common use, I'd argue (not very vociferously, I admit) that only IBM 
machines-and maybe Fujitsus-are really mainframes: The others are just very 
large computers. But this may be due entirely by the fact that I have to 
explain to sales reps on a regular basis that our z/OS support means IBM 
machines, not Unisys or whatever!



Fujitsu machines following S/370 architecture are mainframes. Amdahl 
machines were definitely mainframes.
Look for channelized I/O, then other physical attributes (not just size, 
not just the instruction set). It's not difficult, and it's not merely 
cultural.


On balance, I encountered a Unisys machine, with the instruction set of 
a much older system (which might have been a mainframe in its time) 
which was definitely *not* a mainframe (because the contemporary box 
just did not fit the class).

So Unisis machines not so much.


-- R; <><

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

XMITMSGX release 2.1.5 for C, Regina Rexx, ooRexx, Java

[Rick Troth]

Thanks to help from Sir Dave the Generous,
we confirmed that the XMITMSGX Rexx support built with Regina works just 
fine with ooRexx. Yay!
I had been trying to build against ooRexx expecting some linkage 
differences, but *someone* in ooRexx land made things compatible between 
ooRexx and Regina.


I did not cut a new release (on GitHub) but did spin two new RPMS 
(Linux-s390x and Linux-x86_64).

They're here ...

http://www.casita.net/pub/xmitmsgx/xmitmsgx-2.1.5-0.s390x.rpm

http://www.casita.net/pub/xmitmsgx/xmitmsgx-2.1.5-1.x86_64.rpm

and the source tarball ...

http://www.casita.net/pub/xmitmsgx/xmitmsgx-2.1.5.tar.gz

The only change was to the shell script wrapper demonstrating the 
message handler from Rexx.
As of now, if it doesn't find Regina then it falls back to 'rexx' 
(presuming ooRexx).

No change to the sample Rexx script nor to the interface library.

Enjoy!

-- R; <><









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

Re: bitmapped displays [was: Definition of mainframe?]

[Rick Troth]

wish I knew your email address



On 7/31/23 15:32, Grant Taylor wrote:

On 7/31/23 11:28 AM, Paul Gilmartin wrote:

I trust that you know alternatives.  Will you describe one?


As for how I'm using X11,

I'm currently typing this reply in Thunderbird (X11 client 
application) running on a different Linux system than the one that I'm 
using as the (X11 display) server.


I have Firefox and Lotus Notes do similar.


Though I suspect that these aren't the type of applications that would 
be commonly executed in USS / OMVS.


As for the environments,

I routinely configure an interactive shell the way that I want it and 
then spawn many different things from it, be it different window, or 
foreground / background / suspended processes, or even things like 
terminal multiplexers that allow me to completely {dis,re}connect from 
things that are running.



Another thing I find useful is to pipe stdout from a command into
"less" running in a fresh xterm window, leaving my parent session
available for interactive commands.  I have a script for this.


That is an interesting use case.  I like it.

Though I suspect that while the new XTerm is open, the first XTerm is 
busy running the command generating the output and less.


But *nix makes this easy to background things to release the terminal 
for interactive use while the new terminal is showing data.




Grant. . . .

--
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: bitmapped displays [was: Definition of mainframe?]

[Rick Troth]

On 7/31/23 10:54, Paul Gilmartin wrote:

On Mon, 31 Jul 2023 10:08:34 -0400, Rick Troth wrote:

...
On MVS (USS), I remember using 'xterm', which is the X11 app I use most.
Lately, I'm more likely to run 'xterm' on some other platform and then
SSH-in to USS. Works.


A benefit of xterm on MVS (any system, in fact) is the ability to launch a
child job with the same environment tediously built by the parent.



BINGO


-- R; <><

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

Re: Definition of mainframe? Was: Ars Technica

[Rick Troth]

On 7/31/23 09:09, Dave Jones wrote:

Opps.I was wrong. According to this site 
(https://en.wikipedia.org/wiki/CERN_httpd), the first web server at CERN was 
indeed written and hosted on a NeXT Computer running NeXTSTEP.
I must have dreamed the part about VM, then.



Thanks for clarifying.

I also recall CERN running a web server on VM at that time.
I know that they had a major VM installation. (And mainframes counted as 
supercomputers in those days, which would have been very relevant to CERN.)




DJ

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



-- R; <><

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

Re: Definition of mainframe? Was: Ars Technica

[Rick Troth]

On 7/30/23 18:50, Andrew Rowley wrote:

On 30/07/2023 2:28 am, Jon Perryman wrote:
ASK YOURSELF: Name the z/OS Unix feature that sort of fixes the 
fundamental design flaw with Unix filesystems just described?


I suspect most people won't think about each user having a unique 
filesystem using automount to make their filesystem available. 
Typical Unix uses one file system with all users having directories 
in the /user directory.


An automounted filesystem per user has always been a terrible idea. I 
think it was given as an example of how you could use automount and 
somehow morphed into a recommendation. (Other OSes can e.g. use 
automount to mount a remote user filesystem via NFS).



I responded to this in a thread fork.
The points Andrew makes are sound, but there's context where per-user 
automount is a GOOD idea.





Reasons it's a bad idea:

1) Freespace in the filesystem is not shared between users. This means 
that you need much more space than if there was one pool of freespace 
shared between all.



(repeating)
if the thing mounted is a sub-dir of a shared space, this argument is void.




2) It makes simple questions like e.g. "Which users have a 
.ssh/authorized_keys file?" much harder to answer.



Certainly.
But it also means that ~.ssh/authorized_keys follows the user, which is 
beneficial.





A filesystem per user is basically equivalent to a SMS storage group 
and catalog per user. You get isolation between users, but at the 
expense of much more difficult management.




But, again, an automount per user does not necessarily mean a filesystem 
per user.



-- R; <><

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

Re: bitmapped displays [was: Definition of mainframe?]

[Rick Troth]

On 7/31/23 00:33, Grant Taylor wrote:

On 7/29/23 5:47 PM, Rick Troth wrote:
Xwindows is used by Linux because it had been developed widely and 
was common on Unix when Linux came into popular view.  Xwindows 
itself is an excellent development. Sadly, Xwindows is way to 
"chatty" and has other issues.


I'm curious to know what you're thinking if you'd be willing to 
elaborate.



The whole Athena project at MIT "back in the day" was rigorously planned 
out with cross-platform requirements in mind.
It's old, but if we're going to diss things because they're old then 
we'll devolve into a flame war about COBOL.
Kerberos was born there too. (Less of a fan, but it has its place, and 
notice that Microsoft has fully bought in there.)


X11 not only ran on VMS workstations but could even use DECNET for 
transport as an alternative to TCP. (I'd be surprised to encounter 
DECNET support in contemporary X11.)
Stuff like that indicates that the X11 developers took pains to build a 
generalized API which in turn allowed it to run on more systems.





(But the reactions against it from the security community are WAY out 
of line, MUCH to aggressive. Xwindows is not and evil back door for 
the hackers. But I digress.)


X11 is not good.  I don't know how /bad/ it is.

I think the biggest thing is that most people don't think about it at 
all.  As such it has a way of biting many people.



I hear a great number of people complaining. But in my experience X is 
#1 complicated (likely because of the Stone Age when it was developed) 
and #2 "heavy" or as I like to say "chatty".


Saying "X11 is not good" out of hand is a weak argument (but is sadly 
effective in public forums like this one).


If most people don't think about it, that's a GOOD thing. "It's just 
there", so make use of it.





X11 has a couple of authentication methods, per IP and MIT Magic 
Cookie.  Per IP is problematic when you have multiple users on either 
IP.  MIT Magic Cookie tends to help this and make t hings more per 
user.  But I don't think as many people use MIT Magic Cookie as 
should.  Almost all of the tutorials I've seen online still do things 
per IP or simply open up X11 to the any IP that can connect to it.


Despite the authentication issue, X11 makes it too easy for a client 
that can access the X11 display server to copy the screen to a file, 
manipulate the clipboard, capture keys, read / mess with the mouse, 
and various other surprising things.



Wearing my CISSP hat: then don't let untrustworthy clients access the 
X11 display.
There is value in minimal rules. Ultimately *all* controls boil down to 
binary go/no-go. Always. But too many "what ifs" often make it harder 
for legitimate people (and programs) to do what they need to do.


Now if Wayland can address the all-or-nothing access, great!
But I'm seriously worried that Wayland will throw out some babies with 
the nasty old dirty bath water. (And that water really is gross, I agree.)
But *something* must have access/control over the whole raster. The 
design of X11 leaves much of it open to all comers.
I see this, I recognize the risks, but I don't damn it outright. (And I 
admit to being contrarian in the security world.)

We protect the wrong things.

One great thing about X11 is the ability to launch a single application 
*without* a window manager or session manager.
You can, for example, bring up Xvnc as the one and only client. The 
local screen/display then appears to be the remote canvas.
I did this regularly using VMware back when I ran VMware on my Linux PC. 
Worked a charm.


I use X11 heavily and I *only* use it over trusted channels and with 
trusted clients.


Forgive me for ignorance about the details of the built-in 
authentication methods: I don't use them. I do my best to tie-off the 
ends and then tell X auth to get out of the way. He doesn't always 
listen. Oh well.





You're right: z/OS already does Xwindows. Mac doesn't use Xwindows, 
but its fore-runner NeXT did X just fine.  (personal experience)


macOS doesn't use X11 /by/ /default/.  But my understanding is that 
there are many ways to add X11 on top of -- what I think is called - 
Coco (?) -- thereby making it behave similar to Linux (et al.) and 
Windows with an X11 display server.



Yes. There are may ways to add X11 on top of MacOS, also on top of MS 
Windows.


I use CYGWIN/X on MS Windows. That's a basic requirement in my MO. 
(Though it's true, that exposes me to untrustworthy clients by nature of 
MS Windows itself. Let's not get started.)





MS Windows doesn't do X, but there are numerous utilities bridging 
the gap. (Personally I go for CYGWIN/X when corp IT doesn't get in 
the way.  Works great!)  I rarely use X based apps on MVS, but I've 
used them occasionally for more than two decades. (Even used X from 
CMS. Tell the ARS Technica guy *that*, will ya?)


I'm curious what X11 based applications you ran

Re: USS Features

[Rick Troth]

per-user automount does not necessarily waste space

The thing which is mounted might be a sub-directory of a shared space.

Also, automount is not exclusively for user home directories. It's great 
for selected program products.


-- R; <><


On 7/30/23 23:46, Grant Taylor wrote:

On 7/30/23 10:23 PM, Andrew Rowley wrote:
A low end laptop has 250GB available. How much space should a z/OS 
user be able to use (to do their job) before they have to make a 
special request to the storage management group? 10GB? 100GB?


Please forgive the ignorant question, but does z/OS support quota in 
any way other than a hard file system limit?


Some of my testing runs to (temporarily) 100GB+ for input and output 
files. I run it on the PC because the space isn't available on the 
mainframe, but It would be nice to be able to run it on z/OS. If you 
get a few users with usage spikes to 100GB the space might not be so 
trivial.


I've seen a few quota systems capable of allowing users to go above a 
soft limit for an amount of time while still being bounded by an 
absolute hard limit.


This soft limit allows users to burst for temporary things, usually 
for single digit number of hours or days.  Once the user exceeds the 
time, their soft quota kicks in and behaves as if it's the hard limit.




Grant. . . .

--
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: Definition of mainframe? Was: Ars Technica

[Rick Troth]

On 7/30/23 12:42, Paul Gilmartin wrote:

On Sun, 30 Jul 2023 10:56:08 -0500, Dave Jones wrote:


Pretty sure it was CMS.


Do you know the chronology?

When was the CMS(?) based HTTPD created?

Was SFS available at that date?  MDFS is a poor fit for HTTP paths.




There were several web servers available for VM early on.
One I was fond of was based on Pipelines and did hierarchical content 
even on flat CMS minidisks.
If you had SFS, you could go that route and have a storage-based 
hierarchy. The server figgered it out. Flexible.



-- R; <><

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

Re: Definition of mainframe? Was: Ars Technica

[Rick Troth]

On 7/30/23 11:49, Paul Gilmartin wrote:

On Sun, 30 Jul 2023 10:38:59 -0500, Dave Jones  wrote:

3) The original web browse was written of a Next, but the web server that 
served out the pages ran on IBM's VM/ESA.


What guest OS?


CMS, which technically is a "guest OS".


-- R; <><

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

of COBOL and other languages [was: Definition of mainframe?]

[Rick Troth]

We had an ... interesting ... conversation over on the assembler list a 
couple weeks ago.
I knee-jerked against something PHSiii said. I sorta started some 
flaming. Not intentional.


Yeah ... the author got me ticked off too.
I'm actually not a COBOL fan, but I truly wish more of us knew it (and 
used it).
It annoys me to the max when people reject things due to age or 
perceived obsolescence.

FORTRAN is older but catches less crap than COBOL.

As an industry, we need less allergies to languages outside our normal 
space.
It's frustrating the Java has become such a requirement. Java itself is 
a great language, but nobody compiles it to native; they leave it as 
byte code requiring a JVM. That makes it difficult to work with other 
languages. (Java can call out to C, assembler, even COBOL, using the 
JNI, but those languages cannot call back "in" to Java inside the JVM.)


COBOL does not require a mainframe and mainframes do not require COBOL.

Jon, you should drop a note to the chief editor at ARS Technica. Tell 
him (or her) how far off the mark they were!


-- R; <><


On 7/29/23 12:28, Jon Perryman wrote:

Can anyone provide the definition of MAINFRAME? The ARS Technica article is 
complete nonsense because the mainframe is a state of mind and nothing to do 
with reality. Can anyone prove me wrong? 
https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/.

The IBM z16 is just 4 motherboards containing 16 CPU and many PCIe slots. Linux 
will run on an IBM z16. Is a PC also mainframe? Forget zPDT because I suspect 
it still uses a PCIe zCPU card. I can't say with any certainty, but I suspect 
that z/OS will run on a PC by using Hercules. What is the definition of 
MAINFRAME?

1. CPU does not make a mainframe: The smallest IBM z16 (39 user cores of the 64 
cores) is the same as an AMD Ryzen 4.2Ghz CPU (64 user cores of 64 cores). The 
largest IBM z16 (200 user cores of the 256 cores) is the same as 4 AMD Ryzen 
CPU on 1 motherboard (256 user cores of the 256 cores). Both are CISC CPU (AMD 
uses X86 instructions versus IBM z instructions). IBM Telum (5.2Ghz) has a 
slightly faster clock than AMD Ryzen (4.2Ghz) but is offset by the 25% extra 
user cores. IBM z16 has 4 motherboards for 16 CPU and the same AMD Ryzen would 
need 1 motherboard for 4 CPU.

2. Hardware does not make a mainframe. IBM z16 has PCIe and ram which are also 
on every modern motherboard. IBM z16 chooses not to include other hardware 
(e.g. SATA, IDE, WIFI and more). Motherboards choose not to have 1,600 PCIe 
slots. IBM could allow PCIe graphics cards, mice, keyboards and more. 
Essentially, IBM z16 and AMD Ryzen can implement the same hardware if there was 
enough customer demand.

3. OS does not make a mainframe. Linux running on z16 doesn't make it mainframe 
Linux. There's nothing stopping Linux from taking advantage of every z16 
hardware feature (e.g. 1,600 PCIe slots) but no one is willing to build the 
Linux software. IBM hasn't duplicated z/OS software features in Linux.

4. Software does not make a mainframe. IBM sells DB2 for Linux and DB2 for 
z/OS. DB2 for Linux runs on all hardware including z16. With Linux, you can 
still run DB2 on z16 but large customers choose DB2 for z/OS.

ASK YOURSELF: Other than design philosophy, name 1 fundamental difference 
between IBM z16, AMD Ryzen and the software.

ASK YOURSELF: Since design philosophy is the only difference, name the 
philosophy that makes a mainframe.

Despite the story's false claims for z/OS relevance, it is ignorance in the 
Linux community that makes IBM z/OS relevant. Specifically, it's the lack of 
design in Linux. Consider DB2 for Linux and DB2 for z/OS which are the same 
product both from IBM and available on an IBM z16. Linux people tell you they 
provide the same results, but they ignore the intrinsic capabilities of z/OS 
design. DB2 for Linux supports high availability and large databases but it 
requires knowledge of big data solutions, Linux clustering solutions and more. 
Add a computer to the cluster and you must replicate the master disk. Take a 
computer offline from the cluster, then it must re-sync or replicate the master 
disk. DB2 on z/OS does not experience these problems because of z/OS shared 
dasd and dasd mirroring.

ASK YOURSELF: Name 1 brilliant feature design that originated directly from 
Linux or Unix. Please don't use features that originated from IBM (e.g. 
databases, SQL, HTML, Cloud and more).

Brilliant feature design exposes very little. For instance, does anyone know 
the problems solved by z/OS shared dasd and dasd mirroring. Linux people on the 
other hand can easily name those problems solved if you mention clustering 
solutions and big data solutions. I've personally seen one sysplex split 
between 2 sites 40 KM apart using line of site satellite dishes for 
communication, yet z/OS app programmers were informed. In other words, IBM 
designs for the 21st century.

ASK 

bitmapped displays [was: Definition of mainframe?]

[Rick Troth]

Xwindows is used by Linux because it had been developed widely and was 
common on Unix when Linux came into popular view.
Xwindows itself is an excellent development. Sadly, Xwindows is way to 
"chatty" and has other issues. (But the reactions against it from the 
security community are WAY out of line, MUCH to aggressive. Xwindows is 
not and evil back door for the hackers. But I digress.)


Bitmapped displays have been a mandate since Xerox Alto. It was actually 
before that, but the Alto is what wowwed Steve Jobs, leading to the 
Macintosh.
I'm happy with text mode, though I do require full-screen. But I'm 
content to use bitmapped screens and apps when appropriate.


You're right: z/OS already does Xwindows.
Mac doesn't use Xwindows, but its fore-runner NeXT did X just fine. 
(personal experience)
MS Windows doesn't do X, but there are numerous utilities bridging the 
gap. (Personally I go for CYGWIN/X when corp IT doesn't get in the way. 
Works great!)
I rarely use X based apps on MVS, but I've used them occasionally for 
more than two decades. (Even used X from CMS. Tell the ARS Technica guy 
*that*, will ya?)


The nice thing about Xwindows is that it's the same from one platform to 
the next.


Most of the original hand-helds did Xwindows, though today's hand-helds 
are mostly Android or iPhone, of which neither do X, that's true.


Most companies which still sell their own Unix variant (IBM for one) 
support Xwindows. Nothing there to do with Linux.


But about Linux and X ...
Mike Martin and I were at BMC in 1999 when Linux for S/390 was about to 
be released. (And I'm skipping Bigfoot by Linas Vepstas which could go 
even further back to S/370 hardware.)
To my knowledge, we were the first to run Linux/390 native outside of 
IBM. We got time on the weekend, took down all production on the 600, 
but it into basic mode, and IPLed. It crashed.
Jan Ott was our resident machine code genius. He looked at the dump. 
"There's that Intel instruction." (New at the time relative op codes, 
the biggest reason why Bigfoot got stomped.)
We had blown out the device table. Re-gen the IOCDS and tried again the 
next weekend. Success!


Geek that I am, I started recompiling the compiler. (Gotta have the 
latest compiler for everything else. Besides, Linux is "open source", 
right?)
Mike was more sporty. He brought up DOOM. We had to borrow a nearby Sun 
workstation (I forget which model). There was no BITMAPPED DISPLAY on 
the mainframe.
But the beauty of this story is that DOOM was essentially the first 
application to run on Linux/390 native (outside of IBM).


-- R; <><


On 7/29/23 12:28, Jon Perryman wrote:

Can anyone provide the definition of MAINFRAME? The ARS Technica article is 
complete nonsense because the mainframe is a state of mind and nothing to do 
with reality. Can anyone prove me wrong? 
https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/.

The IBM z16 is just 4 motherboards containing 16 CPU and many PCIe slots. Linux 
will run on an IBM z16. Is a PC also mainframe? Forget zPDT because I suspect 
it still uses a PCIe zCPU card. I can't say with any certainty, but I suspect 
that z/OS will run on a PC by using Hercules. What is the definition of 
MAINFRAME?

1. CPU does not make a mainframe: The smallest IBM z16 (39 user cores of the 64 
cores) is the same as an AMD Ryzen 4.2Ghz CPU (64 user cores of 64 cores). The 
largest IBM z16 (200 user cores of the 256 cores) is the same as 4 AMD Ryzen 
CPU on 1 motherboard (256 user cores of the 256 cores). Both are CISC CPU (AMD 
uses X86 instructions versus IBM z instructions). IBM Telum (5.2Ghz) has a 
slightly faster clock than AMD Ryzen (4.2Ghz) but is offset by the 25% extra 
user cores. IBM z16 has 4 motherboards for 16 CPU and the same AMD Ryzen would 
need 1 motherboard for 4 CPU.

2. Hardware does not make a mainframe. IBM z16 has PCIe and ram which are also 
on every modern motherboard. IBM z16 chooses not to include other hardware 
(e.g. SATA, IDE, WIFI and more). Motherboards choose not to have 1,600 PCIe 
slots. IBM could allow PCIe graphics cards, mice, keyboards and more. 
Essentially, IBM z16 and AMD Ryzen can implement the same hardware if there was 
enough customer demand.

3. OS does not make a mainframe. Linux running on z16 doesn't make it mainframe 
Linux. There's nothing stopping Linux from taking advantage of every z16 
hardware feature (e.g. 1,600 PCIe slots) but no one is willing to build the 
Linux software. IBM hasn't duplicated z/OS software features in Linux.

4. Software does not make a mainframe. IBM sells DB2 for Linux and DB2 for 
z/OS. DB2 for Linux runs on all hardware including z16. With Linux, you can 
still run DB2 on z16 but large customers choose DB2 for z/OS.

ASK YOURSELF: Other than design philosophy, name 1 fundamental difference 
between IBM z16, AMD Ryzen and the software.

ASK YOURSELF: Since design philosophy is the only difference, name the 

speaking of filesystems [was: Definition of mainframe?]

[Rick Troth]

I don't follow your comparison of PDS/e and Unix filesystems.
If I saw correlation of Linux filesystems with PDS, I glossed over it as 
stoopid. (Here again, I feel your pain.)


My understanding is that PDS is (historically) a means of segmenting one 
data set into related chunks. They're "related" because they're all 
members of the same data set.
The real "filesystem" for MVS is the catalog, and the "files" are the 
data sets, whether partitioned or not. Hopefully the VTOC and the 
catalog match-up. That's not always required.


PDS are also flat, unless something has changed recently.
PDS is more like the partition table on a PC disk. (Though the latter 
doesn't use names, per se, and tends to have less "members".)


You're absolutely right: a Unix filesystem is a file containing files. 
There the similarity to PDS ends.
Unix filesystems have two important features: inodes and directories. 
The inodes are usually invisible. The directories connect inodes with 
names, which is what people see.
A hard link is where two files (by name) refer to the same inode. A 
symbolic link is a special kind of Unix file that names another file. 
Here's a neat trick: you can make a hard link to a sym-link.

There are only a handful of actual file *types*:

 * plain file
 * directory
 * character special (like a terminal)
 * block special (like a disk drive or partition thereof)
 * symbolic link
 * and a couple others added by OMVS ... really


As I recall, other Unix vendors added their own special types. But I've 
slept since then and memory is fuzzy (or maybe I dreamed it).


Not all "filesystems" mountable on a Linux system properly implement 
inodes and directories. They therefore lack some functionality in 
practice; it can be significant.


Some features of Unix (and Linux) filesystems are a step up from 
historical MVS data sets. It is sadly still possible to have a data set 
with no time stamp.
So you can count that as one thing Unix did that MVS has learned 
afterward. (Not a slam on z/OS. Just keeping things in perspective.)


-- R; <><


On 7/29/23 12:28, Jon Perryman wrote:

Can anyone provide the definition of MAINFRAME? The ARS Technica article is 
complete nonsense because the mainframe is a state of mind and nothing to do 
with reality. Can anyone prove me 
wrong?https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/.

The IBM z16 is just 4 motherboards containing 16 CPU and many PCIe slots. Linux 
will run on an IBM z16. Is a PC also mainframe? Forget zPDT because I suspect 
it still uses a PCIe zCPU card. I can't say with any certainty, but I suspect 
that z/OS will run on a PC by using Hercules. What is the definition of 
MAINFRAME?

1. CPU does not make a mainframe: The smallest IBM z16 (39 user cores of the 64 
cores) is the same as an AMD Ryzen 4.2Ghz CPU (64 user cores of 64 cores). The 
largest IBM z16 (200 user cores of the 256 cores) is the same as 4 AMD Ryzen 
CPU on 1 motherboard (256 user cores of the 256 cores). Both are CISC CPU (AMD 
uses X86 instructions versus IBM z instructions). IBM Telum (5.2Ghz) has a 
slightly faster clock than AMD Ryzen (4.2Ghz) but is offset by the 25% extra 
user cores. IBM z16 has 4 motherboards for 16 CPU and the same AMD Ryzen would 
need 1 motherboard for 4 CPU.

2. Hardware does not make a mainframe. IBM z16 has PCIe and ram which are also 
on every modern motherboard. IBM z16 chooses not to include other hardware 
(e.g. SATA, IDE, WIFI and more). Motherboards choose not to have 1,600 PCIe 
slots. IBM could allow PCIe graphics cards, mice, keyboards and more. 
Essentially, IBM z16 and AMD Ryzen can implement the same hardware if there was 
enough customer demand.

3. OS does not make a mainframe. Linux running on z16 doesn't make it mainframe 
Linux. There's nothing stopping Linux from taking advantage of every z16 
hardware feature (e.g. 1,600 PCIe slots) but no one is willing to build the 
Linux software. IBM hasn't duplicated z/OS software features in Linux.

4. Software does not make a mainframe. IBM sells DB2 for Linux and DB2 for 
z/OS. DB2 for Linux runs on all hardware including z16. With Linux, you can 
still run DB2 on z16 but large customers choose DB2 for z/OS.

ASK YOURSELF: Other than design philosophy, name 1 fundamental difference 
between IBM z16, AMD Ryzen and the software.

ASK YOURSELF: Since design philosophy is the only difference, name the 
philosophy that makes a mainframe.

Despite the story's false claims for z/OS relevance, it is ignorance in the 
Linux community that makes IBM z/OS relevant. Specifically, it's the lack of 
design in Linux. Consider DB2 for Linux and DB2 for z/OS which are the same 
product both from IBM and available on an IBM z16. Linux people tell you they 
provide the same results, but they ignore the intrinsic capabilities of z/OS 
design. DB2 for Linux supports high availability and large databases but it 
requires knowledge of big data solutions, Linux 

Linux and z/OS and stuff [was: Definition of mainframe?]

[Rick Troth]

This is the IBM-MAIN discussion list, so let me tread lightly on my z/OS 
friends.
It's correct that the O/S does not define "the mainframe". I can't count 
the number of times I've cringed at things like "Linux for z/OS" 
(instead of "Linux for Z").


I share your frustration over the wrong implications in the article.

I've been a fan of Unix for many years.
My first Unix was on a mainframe. Remember Amdahl? They picked up an 
academic project to port Unix to the S/370. Wow ... such elegant design: 
fully Unix and yet fully mainframe. Yeah, it talked ASCII but it had no 
allergy to EBCDIC devices (printers and terminals).


There were other Unix developments for the mainframe. Some were 
miserable. Some were excellent. AIX/ESA (not to be confused with AIX/370 
XA) made excellent use of data spaces, then the latest technology in 
mainframe development. AIX/ESA was not the half-hearted effort as some 
other Unix-for-mainframe.

And then came Linux.

I've been a fan of Linux since it was release 0.x, using it as a 
development platform from its earliest days. Linux is my primary 
workstation in all cases.


The best thing about Linux is that it follows Unix.
Unix in turn does have several brilliant design ideas, one being 
"everything is a file". While admittedly imperfect (you can surely site 
exceptions), this has largely held true.
Unix sprung from MULTICS. A number of Unix inventors later developed 
Plan 9, which some will argue is better than Unix. I won't enumerate; I 
do agree, the author doesn't "get it". But Unix is an excellent "lab", 
just different from z/OS.
In recent years, Linux has varied from traditional Unix designs. I'm not 
keen on that trend, but it's beyond scope of this conversation.


MVS is, of course, the diesel locomotive where I want the heavy lifting. 
(You mentioned DB2 and contrasted the two flavors. I concur.)
The fact that MVS also now has a Unix face is just added gravy, icing on 
the cake. EBCDIC is a problem, even if ideally it should not be.
But I can bring in a high percentage of "open source" and "just make". 
Ahhh...


Excellent as MVS is, I would not want it for desktop or laptop use, even 
if it was ported to those instruction sets.
But Linux is fine in that context. And Linux can scale in ways that 
other op sys cannot. (MacOS sure, but Windows, nah. And MVS can scale 
yet further, duh.)


-- R; <><


On 7/29/23 12:28, Jon Perryman wrote:

Can anyone provide the definition of MAINFRAME? The ARS Technica article is 
complete nonsense because the mainframe is a state of mind and nothing to do 
with reality. Can anyone prove me wrong? 
https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/.

The IBM z16 is just 4 motherboards containing 16 CPU and many PCIe slots. Linux 
will run on an IBM z16. Is a PC also mainframe? Forget zPDT because I suspect 
it still uses a PCIe zCPU card. I can't say with any certainty, but I suspect 
that z/OS will run on a PC by using Hercules. What is the definition of 
MAINFRAME?

1. CPU does not make a mainframe: The smallest IBM z16 (39 user cores of the 64 
cores) is the same as an AMD Ryzen 4.2Ghz CPU (64 user cores of 64 cores). The 
largest IBM z16 (200 user cores of the 256 cores) is the same as 4 AMD Ryzen 
CPU on 1 motherboard (256 user cores of the 256 cores). Both are CISC CPU (AMD 
uses X86 instructions versus IBM z instructions). IBM Telum (5.2Ghz) has a 
slightly faster clock than AMD Ryzen (4.2Ghz) but is offset by the 25% extra 
user cores. IBM z16 has 4 motherboards for 16 CPU and the same AMD Ryzen would 
need 1 motherboard for 4 CPU.

2. Hardware does not make a mainframe. IBM z16 has PCIe and ram which are also 
on every modern motherboard. IBM z16 chooses not to include other hardware 
(e.g. SATA, IDE, WIFI and more). Motherboards choose not to have 1,600 PCIe 
slots. IBM could allow PCIe graphics cards, mice, keyboards and more. 
Essentially, IBM z16 and AMD Ryzen can implement the same hardware if there was 
enough customer demand.

3. OS does not make a mainframe. Linux running on z16 doesn't make it mainframe 
Linux. There's nothing stopping Linux from taking advantage of every z16 
hardware feature (e.g. 1,600 PCIe slots) but no one is willing to build the 
Linux software. IBM hasn't duplicated z/OS software features in Linux.

4. Software does not make a mainframe. IBM sells DB2 for Linux and DB2 for 
z/OS. DB2 for Linux runs on all hardware including z16. With Linux, you can 
still run DB2 on z16 but large customers choose DB2 for z/OS.

ASK YOURSELF: Other than design philosophy, name 1 fundamental difference 
between IBM z16, AMD Ryzen and the software.

ASK YOURSELF: Since design philosophy is the only difference, name the 
philosophy that makes a mainframe.

Despite the story's false claims for z/OS relevance, it is ignorance in the 
Linux community that makes IBM z/OS relevant. Specifically, it's the lack of 
design in Linux. Consider DB2 for Linux and DB2 

Re: Definition of mainframe? Was: Ars Technica

[Rick Troth]

Your inquiry is (understandably) somewhat of a reaction against 
unfortunate trends in public thinking.
I will respond to them separately. First is triggered by the subject 
line: definition of a mainframe.


Your #2 is a miss.
Hardware *does* make a mainframe: channelized I/O
Let me explain.

Remember the VAX?
DEC wanted to market their box as a "mainframe".
In those days, I was quite fond of the VAX, and of its most common O/S, 
VMS.
(Later, I went back to VMS and ... oy vey ... trying to forget it.) So 
foreign to me after being away.
But VAX hardware was redeemed (I say, not meaning to slam VMS) by Unix 
and Linux being ported to it.


SATA is great, but doesn't count. It doesn't scale to the same extent.
FCP counts, but few machines talking FCP go to the same scaling as IBM Z 
"clients".
So not all machines doing SATA or FCP or SCSI qualify as mainframes if 
only because they don't go all-in with such I/O models.


Why was the VAX not a mainframe, as DEC wanted customers to believe?
It lacked channelized I/O. Not that it didn't have good input/output 
facilities, but that it didn't have the same concepts, systems, 
services, and sub-processors as machines from IBM (and others).


IBM is not the only company to produce large systems with channelized I/O.
Some vendors, in fact, used plug-compatible devices. Sweet! (Though they 
might have called their machines "supercomputers". Okay, fine. And some 
IBM mainframes were called "supercomputers" at one time. But that's a 
whole nutha story.)


So the single significant feature of "a mainframe" in my glossary is 
channelized I/O.


-- R; <><


On 7/29/23 12:28, Jon Perryman wrote:

Can anyone provide the definition of MAINFRAME? The ARS Technica article is 
complete nonsense because the mainframe is a state of mind and nothing to do 
with reality. Can anyone prove me wrong? 
https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/.

The IBM z16 is just 4 motherboards containing 16 CPU and many PCIe slots. Linux 
will run on an IBM z16. Is a PC also mainframe? Forget zPDT because I suspect 
it still uses a PCIe zCPU card. I can't say with any certainty, but I suspect 
that z/OS will run on a PC by using Hercules. What is the definition of 
MAINFRAME?

1. CPU does not make a mainframe: The smallest IBM z16 (39 user cores of the 64 
cores) is the same as an AMD Ryzen 4.2Ghz CPU (64 user cores of 64 cores). The 
largest IBM z16 (200 user cores of the 256 cores) is the same as 4 AMD Ryzen 
CPU on 1 motherboard (256 user cores of the 256 cores). Both are CISC CPU (AMD 
uses X86 instructions versus IBM z instructions). IBM Telum (5.2Ghz) has a 
slightly faster clock than AMD Ryzen (4.2Ghz) but is offset by the 25% extra 
user cores. IBM z16 has 4 motherboards for 16 CPU and the same AMD Ryzen would 
need 1 motherboard for 4 CPU.

2. Hardware does not make a mainframe. IBM z16 has PCIe and ram which are also 
on every modern motherboard. IBM z16 chooses not to include other hardware 
(e.g. SATA, IDE, WIFI and more). Motherboards choose not to have 1,600 PCIe 
slots. IBM could allow PCIe graphics cards, mice, keyboards and more. 
Essentially, IBM z16 and AMD Ryzen can implement the same hardware if there was 
enough customer demand.

3. OS does not make a mainframe. Linux running on z16 doesn't make it mainframe 
Linux. There's nothing stopping Linux from taking advantage of every z16 
hardware feature (e.g. 1,600 PCIe slots) but no one is willing to build the 
Linux software. IBM hasn't duplicated z/OS software features in Linux.

4. Software does not make a mainframe. IBM sells DB2 for Linux and DB2 for 
z/OS. DB2 for Linux runs on all hardware including z16. With Linux, you can 
still run DB2 on z16 but large customers choose DB2 for z/OS.

ASK YOURSELF: Other than design philosophy, name 1 fundamental difference 
between IBM z16, AMD Ryzen and the software.

ASK YOURSELF: Since design philosophy is the only difference, name the 
philosophy that makes a mainframe.

Despite the story's false claims for z/OS relevance, it is ignorance in the 
Linux community that makes IBM z/OS relevant. Specifically, it's the lack of 
design in Linux. Consider DB2 for Linux and DB2 for z/OS which are the same 
product both from IBM and available on an IBM z16. Linux people tell you they 
provide the same results, but they ignore the intrinsic capabilities of z/OS 
design. DB2 for Linux supports high availability and large databases but it 
requires knowledge of big data solutions, Linux clustering solutions and more. 
Add a computer to the cluster and you must replicate the master disk. Take a 
computer offline from the cluster, then it must re-sync or replicate the master 
disk. DB2 on z/OS does not experience these problems because of z/OS shared 
dasd and dasd mirroring.

ASK YOURSELF: Name 1 brilliant feature design that originated directly from 
Linux or Unix. Please don't use features that originated from IBM (e.g. 

looking for RSYNC for OMVS [was: Preferred FTP Client for Windows]

[Rick Troth]

And for my next question: what about RSYNC?
I don't see it mentioned on the Co:Z web site. Didn't find it on 
Rocket's web site either.
I thought I heard a rumor about someone porting it, but I also don't see 
it under the z/OS Open Tools GitHub repository.


RSYNC is the tool of choice for bulk file transfer on Linux, most Unix, 
MacOS, even Windoze (via CYGWIN, maybe WSL1).
Stealing verbiage from Lionel, it would be impossible to speak too 
highly about RSYNC as a general tool for maintaining file hierarchies.
The gotcha for z/OS would be ASCII/EBCDIC mixing, similar problem for 
those who use NFS between USS and other systems.


-- R; <><


On 7/28/23 11:38, Tom Brennan wrote:
Sounds great!  I've never used Co:Z, but I always assumed it was a mod 
to the open source SSH code, with a new listening STC.  Interesting to 
see John's note about it using IBM's SSH processing.  I'm not sure I 
would have thought of that simple idea myself.


Conversations in the past went like this:
User: Does the mainframe support sftp?
Tom: Sure!
User: Ok, so I can sftp PROD.PAYROLL to our Linux app.
Tom: Sure!  But... um...

On 7/28/2023 8:01 AM, Lionel B. Dyck wrote:
It would be impossible to speak to highly about Co:Z - and not just 
about their sftp server enhancement but also their other tools. They 
have provided what IBM should have.


Check the license - it's free with some restrictions. And they offer 
a full support contract as well (which I would encourage you to 
consider if you're going to use it in production if only to support 
this great company).



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

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


-Original Message-
From: IBM Mainframe Discussion List  On 
Behalf Of John S. Giltner, Jr.

Sent: Friday, July 28, 2023 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Preferred FTP Client for Windows

Co:Z SFTP only talks SSH/SFTP.  It sits "on top" of IBM's ported 
OpenSSH.  So you need IBM's OpenSSH installed.


To get/put z/OS files you do need to use some special command such as 
to put  a text file with LRECL=80 and fixed block  to z/OS


ls /+mode=text,lrecl=80,recmf=fb,blksize=0,space=trk.1.1
put //!ZOS.FILE.NAME

To get a z/OS file that is text:

ls /+mode=text
get //ZOS.FILE.NAME

To do binary it would be ls /+mode=binary.

For OMVS files the get/put are just like any other *nix host. If the 
files are in EBCDIC you need the ls /+mode=text.  If they are binary 
or in ASCII you use /+mode=binary/


Co:Z does have a config file where you can set defaults for mode, 
lrecl, blksize and everything else so you don't have to specify the 
parameters every time if you know what you going to be using most of 
the time.


You can also use Co:Z as a client on z/OS to send/get files from 
other SFTP servers.


On Fri, 28 Jul 2023 10:25:34 -0400, Rick Troth  wrote:


This is great to hear, John. Thanks.

For people like me, who need excruciating clarity, you're saying that
the SERVER in the Co:Z product groks traditional datasets as well as
USS files. Correct? Fantastic!
That means one can use a variety of clients, specifically several which
go via SSH. Is that also correct?

You mention SFTP which is FTP-like behavior using SSH under the covers.
Contrast with FTPS which is traditional FTP but with SSL/TLS added.
I'm keen on the former because it uses a single channel. Though I much
prefer a one-shot command in any case, and 'scp' does that (and runs
via SSH like 'sftp').

Does the Co:Z server speak both SSH (for SFTP) and traditional FTP?

-- R; <><


On 7/28/23 07:34, John S. Giltner, Jr. wrote:
I use sftp  with Co:Z SFTP installed on the z/OS side.  It allows 
access to z/OS files as well as OMVS files.  Where as OpenSSH on 
z/OS only allows access to OMVS files.


Under Windows you can use WSL, Putty, Cygwin, or any other CLI sftp 
product.  I use Cygwin most of the time.



On Wed, 26 Jul 2023 16:06:52 -0500, Steve Estle  
wrote:



Hello All,

I work in a secure government environment and moving files up and 
down from the mainframe (especially traditional ZOS datasets) is a 
'' pita with Winscp and everything I read (including IBMMAIN 
archives) is that tool is just plain dumb when it comes to 
datasets with standard ZOS HLQ's.  I'm trying to do a 
non-scientific poll - what is the preferred FTP client to run on 
Windows platform out there everyone is using that you are happy 
with and can easily navigate to either traditional ZOS HLQ dataset 
or Unix System Services files.  Of course freeware is preferred if 
user friendly.


I know there is Filezilla but not sure it is much better than Winscp?

Thanks for everyone's thoughts and input.

Steve Estle
steven.es...@peraton.com


-- For IBM-MAIN subscribe / 

Re: Preferred FTP Client for Windows

[Rick Troth]

This is great to hear, John. Thanks.

For people like me, who need excruciating clarity, you're saying that 
the SERVER in the Co:Z product groks traditional datasets as well as USS 
files. Correct? Fantastic!
That means one can use a variety of clients, specifically several which 
go via SSH. Is that also correct?


You mention SFTP which is FTP-like behavior using SSH under the covers.
Contrast with FTPS which is traditional FTP but with SSL/TLS added.
I'm keen on the former because it uses a single channel. Though I much 
prefer a one-shot command in any case, and 'scp' does that (and runs via 
SSH like 'sftp').


Does the Co:Z server speak both SSH (for SFTP) and traditional FTP?

-- R; <><


On 7/28/23 07:34, John S. Giltner, Jr. wrote:

I use sftp  with Co:Z SFTP installed on the z/OS side.  It allows access to 
z/OS files as well as OMVS files.  Where as OpenSSH on z/OS only allows access 
to OMVS files.

Under Windows you can use WSL, Putty, Cygwin, or any other CLI sftp product.  I 
use Cygwin most of the time.


On Wed, 26 Jul 2023 16:06:52 -0500, Steve Estle  wrote:


Hello All,

I work in a secure government environment and moving files up and down from the 
mainframe (especially traditional ZOS datasets) is a '' pita with Winscp 
and everything I read (including IBMMAIN archives) is that tool is just plain 
dumb when it comes to datasets with standard ZOS HLQ's.  I'm trying to do a 
non-scientific poll - what is the preferred FTP client to run on Windows 
platform out there everyone is using that you are happy with and can easily 
navigate to either traditional ZOS HLQ dataset or Unix System Services files.  
Of course freeware is preferred if user friendly.

I know there is Filezilla but not sure it is much better than Winscp?

Thanks for everyone's thoughts and input.

Steve Estle
steven.es...@peraton.com

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

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


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

Re: SYSLOGD config question.

[Rick Troth]

No sweat, Tom. And no laughing.

Not sure how to *exclude* things, but I use two catchall statements.
(And I avoid fancy extensions to the original specification: keep it 
simple.)

So my /etc/syslog.conf looks mostly like ...

    *.info /var/log/messages
    *.info @loghost

The first statement routes all event types (the asterisk) with a 
priority of "info" or more to the common file.
The second statement routes the same traffic to a remote SYSLOG 
listener. (I like using UDP for a lot of reasons, and you didn't ask, so 
skipping for now.)

But I think you already know this part. Moving on then.

Is your catchall working?

So you want to exclude certain traffic? Would it be acceptable to 
replace the catchall(s) with a number of specific statements?


The way SYSLOG routes traffic is by the facility name. (I used an 
asterisk in the example, but you can code any of the ten or so 
pre-defined facilities, and/or make up your own as "local1" or "local5" 
or whatever.)

So maybe ...

    auth.info /var/log/messages
    cron.info /var/log/messages
    daemon.info /var/log/messages
    kern.info   /var/log/messages
    security.info /var/log/messages
    user.info /var/log/messages
 ... so on ...
local2.info /var/log/otherfile
local7.info /var/log/thirdfile

Does this help?

-- R; <><


On 7/24/23 14:42, Tom Longfellow wrote:

I apologize to all who have seen this before.   BUT since I cannot find my 
original post here, I am going to try again.

I am sure that all of Unix Gurus will laugh at my ignorance, but I still cannot 
break through this wall.   The syntax of syslogd.conf is a complete mystery of 
arcane directives that I have been unable to juggle..

I currently have a set up that send all messages from TASKA to LOGA... All 
messages from TASKB to LOGB.
There is also a 'catchall' that sends all the messages to a common log file.

What I would 'like' to do is replace the 'catchall' with a selection screen 
that exclude TASKA and TASKB messages but still collects the rest of the syslog 
traffic.

=-=-=--=-=-

--
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: Ars Technica: The IBM mainframe: How it runs and why it survives

[Rick Troth]

yeah ... saw that and cringed

It's decidedly NOT TRUE.
And for comparison, other platforms require more staff.

-- R; <><


On 7/24/23 13:51, Lionel B. Dyck wrote:

Wow - talk about scary - requires hundreds to thousands of support staff - 
something the author harps on several times.


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

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Monday, July 24, 2023 11:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Ars Technica: The IBM mainframe: How it runs and why it survives

Ars Technica published a deep-dive explainer of modern IBM mainframes:

https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/


I’d quibble with the application server topic that talks about CICS with no 
mention of IMS/TM. CICS is to IMS as Windows 3.1 is to Windows 10.  



--
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: Ars Technica: The IBM mainframe: How it runs and why it survives

[Rick Troth]

Good article.
As often happens, the author didn't mention Linux for Z ... nor z/VM, 
VSE, TPF.

Common public misconception is that Z is exclusively z/OS.

Don't misunderstand: this is no slam on z/OS. I'm a fan! That's the one 
place I'd put my heavy-lifting database and similar "system of record" 
workloads.
But Z is hardware and the other op sys make excellent use of that 
superior hardware. I'm a fan of Linux and run it on several kinds of 
hardware. The best Linux performance, and the most reliable operation, 
is consistently on Z.


The article speaks much about COBOL. Sadly, I only know >one< university 
professor teaching COBOL. (And his students are landing high-dollar jobs 
out of the gate.)
COBOL benefits from inter-language workings. Similarly, z/OS benefits 
from inter-opsys workings. And often those other op sys are on the same 
class of hardware.
Calling COBOL to/from languages like PL/I, C, even Python or Rexx, makes 
fabulous long-term use of all that lovely COBOL code "out there".
Where the Ars Technica article telling *that* story? (Credit where 
credit due: this piece *did* discuss XML and JSON. Good.)


Sincere thanks Michael for sharing the article.

-- R; <><


On 7/24/23 13:33, Bill Johnson wrote:

Say it isn’t so! lol

It’s estimated that there are 10,000 mainframes in use today. They’re used 
almost exclusively by the largest companies in the world, including two-thirds 
of Fortune 500 companies, 45 of the world’s top 50 banks, eight of the top 10 
insurers, seven of the top 10 global retailers, and eight of the top 10 
telecommunications companies. And most of those mainframes come from IBM.


Sent from Yahoo Mail for iPhone


On Monday, July 24, 2023, 1:21 PM, Bob Bridges  wrote:

Hey, that's fun!  Kind of an answer to "the mainframe is old and decrepit and can't 
survive much longer in the face of newer and [therefore] far better technologies".

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

/* As a father, I have a vested interest in seeing my children do well in 
school.  If they don't, they won't graduate, and will probably wind up living 
in my house until they are thirty years old.  This will interfere with my plan 
to reach retirement age without killing another human being.  -W Bruce Cameron, 
_Study Habits_ (2001) */


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Monday, July 24, 2023 12:43

Ars Technica published a deep-dive explainer of modern IBM mainframes:

https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/

I’d quibble with the application server topic that talks about CICS with no 
mention of IMS/TM. CICS is to IMS as Windows 3.1 is to Windows 10.  

--
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: XMITMSGX release 2.1.4 (CMS-like 'xmitmsg' for Linux/Unix/POSIX)

[Rick Troth]

forgot the link

https://github.com/trothr/xmitmsgx/releases/tag/2.1.4/





On 7/23/23 22:17, Rick Troth wrote:

I was able to cut release 2.1.4 of this XMITMSG work-alike.
It includes support for Rexx (Regina) and now also Java.
Also included are shell scripts to demonstrate calling the utility 
from C, Rexx, and Java.


Two RPMs are up on GitHub: 64-bit PC Linux (AMD/Intel) and 64-bit Z 
Linux.


I did turn the crank with Linux on ARM, FreeBSD (on AMD/Intel), and 
Solaris (on AMD/Intel). Those are not up on GitHub but if anyone is 
interested I can provide them (but you can build them yourself).


The samples are in the "src" directory.
When packages are under /opt/vendor/package that makes sense, but the 
prefix for the RPM install is "/usr". That means the samples are in 
/usr/src, which seems ... unclean. Never the less, an 'rpm -e' nicely 
removes them, so I'm not stressed about it.


Feedback is always welcome!

I've gotten a lot of positive responses about supporting ooRexx.
Dunno if it's my own denseness or if ooRexx really is harder, but I 
have not yet been able to crack the nut of the ooRexx SAA interface.
If someone really wants to call this baby from ooRexx, do please lend 
a hand. danku


-- R; <><







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

XMITMSGX release 2.1.4 (CMS-like 'xmitmsg' for Linux/Unix/POSIX)

[Rick Troth]

I was able to cut release 2.1.4 of this XMITMSG work-alike.
It includes support for Rexx (Regina) and now also Java.
Also included are shell scripts to demonstrate calling the utility from 
C, Rexx, and Java.


Two RPMs are up on GitHub: 64-bit PC Linux (AMD/Intel) and 64-bit Z Linux.

I did turn the crank with Linux on ARM, FreeBSD (on AMD/Intel), and 
Solaris (on AMD/Intel). Those are not up on GitHub but if anyone is 
interested I can provide them (but you can build them yourself).


The samples are in the "src" directory.
When packages are under /opt/vendor/package that makes sense, but the 
prefix for the RPM install is "/usr". That means the samples are in 
/usr/src, which seems ... unclean. Never the less, an 'rpm -e' nicely 
removes them, so I'm not stressed about it.


Feedback is always welcome!

I've gotten a lot of positive responses about supporting ooRexx.
Dunno if it's my own denseness or if ooRexx really is harder, but I have 
not yet been able to crack the nut of the ooRexx SAA interface.
If someone really wants to call this baby from ooRexx, do please lend a 
hand. danku


-- R; <><

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

Re: Ignorant z/OS question

[Rick Troth]

On 7/20/23 14:57, Phil Smith III wrote:

Shmuel wrote:

Define a 3270 address that you can DIAL into; don't forget to use
RESET rather than DETACH when you're done.

Yeah, that's not the answer, alas-if I wanted a 3270 session, I would just log onto the guest. What I've 
seen before is that the SECUSER sees all the z/OS SYSLOG traffic, and can reply via CP SEND. I'm sure I'm 
not describing it well-someone will (I hope!) say "You need a virtual device at " or "You need the XYZZY configuration in a PARMLIB member".



NOTE: there's also the CP VDELETE command. Reading that help, there is a 
limit on the number of messages the guest opsys can queue out.
But this is getting beyond my knowledge and experience. I mention only 
for sake of trying to not steer you wrong: what I'm remembering could be 
unique to VM on VM. (Surely hope not, though!)





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



-- R; <><

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

Re: Ignorant z/OS question

[Rick Troth]

On 7/20/23 14:57, Phil Smith III wrote:

Shmuel wrote:

Define a 3270 address that you can DIAL into; don't forget to use
RESET rather than DETACH when you're done.

Yeah, that's not the answer, alas-if I wanted a 3270 session, I would just log onto the guest. What I've 
seen before is that the SECUSER sees all the z/OS SYSLOG traffic, and can reply via CP SEND. I'm sure I'm 
not describing it well-someone will (I hope!) say "You need a virtual device at " or "You need the XYZZY configuration in a PARMLIB member".



I think what you want to do is somehow get z/OS to *not* use a "device" 
as the console.


There is, architecturally, a "system console", which z/VM (CP) presents 
to the guest as part of service processor hardware simulation. Some of 
this verbiage I'm taking directly from the help screen for CP VINPUT. 
(Do a 'help cp vinput' on your nearest CMS account.) The CP VINPUT 
command is for input, duh, but there's a counterpart output function.


Last I knew, in absence of a console device, guest operating systems 
(z/VM for sure, and I'd expect z/OS too, maybe the rest) would use the 
so-called system console to write the usual console traffic. This then 
is handled by VM in the traditional way, e.g., 'cp spool console start', 
and it's all linemode, no 3270 problems or quirks.


The HMC (here too, been a while!) can pop open a window for 
line-at-a-time input which the OS in the corresponding LPAR will receive 
... and respond to. We're not talking 3270 and we're surely not talking 
3215.


As I write this, some memory freshens and I recall that I was using VM 
on VM where it worked like a charm. So I'm only guessing at how z/OS MVS 
would behave.





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



-- R; <><

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

Re: Ignorant z/OS question

[Rick Troth]

Have you tried configuring z/OS to use the linemode console?
Been so long that I'm forgetting what it's called. (Something Alan 
Altmark would know!)
It's the thing which talks to the VINPUT (VMSG/PVMSG) interface. I think 
it's functionally similar to SYSASCII (but EBCDIC, duh).


We're NOT talking 3215, which was the handy thing in the olden dayz. (I 
could gripe at whoever in Pookie removed that capability. Turkeys!)


-- R; <><


On 7/20/23 12:08, Phil Smith III wrote:

When I start our z/OS system (under VM), my startup EXEC issues
'CP TERMINAL CONMODE 3270' '15'X 'CP IPL' sysres 'LOADPARM' 
loadaddr||loadparm
.which works fine, z/OS IPLs. But I have to log on to see what's going on-the 
console traffic doesn't come across a SECUSER connection. What do I need to do 
to make that work? Some Googling didn't find it, but I'm sure it's just me!

Thanks.




--
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: unix commands in batch and su

[Rick Troth]

As others have said, you need to feed the list-o-commands into the 
interpreting shell.


Another tool that should be recommended is 'sudo'. But I'll defer 
commentary on that just now for sake of brevity.


Don't fear "scripting".
The input to 'sh' or to 'su' can be from a USS file, but it can 
alternatively be a traditional sequential data set or a member of a PDS. 
The only lack when using data sets is they can't be marked as executable 
and turn "run" or "executed". But they can be fed to the shell, no 
problem! and that's a script, nothing more to it. Yeah, you can also 
embed it in the job, sure!


You attempted stacking commands. That doesn't always work because of 
context. You need for the interpreting shell to "see" the whole stack or 
queue, and it often only gets one at a time.
(And I confess to not knowing the full nature of 'oshell'. Maybe that 
syntax is supposed to work?)


Variable length is much better than fixed length for feeding into the 
shell. But if all of the commands are shorter than your LRECL then you 
can often get away with fixed length.


-- R; <><


On 6/13/23 15:07, Radoslaw Skorupka wrote:

I need to issue several commands in batch, that means JCL job.
I know some ways to do it, but... but before I have to issue su 
command to get root authorities.

I put 'su' command before others, but it doesn't work.
Example:
//K EXEC PGM=IKJEFT01
//SYSTSIN DD *
 oshell su;mkdir a;mkdir b;other commands...

The stream works OK, but second and remaining commands failed due to 
lack of root authority.


Any clue how to use su and the commands?
I would like to avoid putting all the commands to the shell script, as 
that require puting the script into filesystem. Less portable.

Or maybe there is a method to run the script embedded in the jobstream?



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

Re: USS automount facility and search/browse

[Rick Troth]

On 6/12/23 09:03, Radoslaw Skorupka wrote:
I need to review some user home directories. However they have 
auto-mounted filesystems.

How to search it without asking folks to logon?



I have not tried this on USS, but with other automounters, simply 'cd 
~user' will force a mount of that user's home directory.

Try it.

Often, I'll get an error from 'cd ~user' if the target user's home 
directory is not available to me. (Sometimes even when doing the 'cd' as 
root/admin.) But the system cannot know the settings until the directory 
gets mounted, so forcing the mount would seem to be a requirement ahead 
of knowing if the 'cd' would work. But then, if you're needing to 
"review some user home directories", read rights are implied.


The tilde hack is a shell feature, but I'm not aware of any contemporary 
shells where it doesn't work. If tilde doesn't work, then fully 
qualified path to the user's home directory works.




Note: it is not related to any hacking or unauthorized access. I can 
have any authority I would need, including some tricks to logon using 
their userid, etc. Looking for simple method to run automount by a 
command, etc.



-- R; <><



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

Re: Updated UNIX certification WAS: z/OS 3.1: Now UNIX® Certified

[Rick Troth]

This "file tagging" is completely new for me. Please pardon my ignorance.

The behavior you describe (some utils honor the tag, others don't) 
sounds perfectly typical, totally expected.
There *must* be a default, and that would predate the availability of a 
"tag", so for apps to not "honor" a tag, even if painful, makes sense.

We're talking default: default behavior, default charset, etc.

When I first encountered USS, and experienced, "sure, it's Unix, but 
it's not ASCII", there was a really really helpful indicator: newline.
There are two newline characters, and thankfully they're both in 
unprintable space (no graphemes). So when a textual utility reads a text 
line and hits 0x15, it can safely assume EBCDIC. The default codepage 
for USS was said to be 1047. Others are fine, as long as we know they're 
EBCDIC. If that same textual utility reads a text line and hits 0x0A, it 
can safely assume ASCII (or superset like UTF-8). It would likely need 
to take action, translate the line A to E, or ... something. (The 
options are numerous.)
This, of course, has to be done within the application or utility. The 
logic has been within our reach for thirty years, maybe more. I've 
written applications which use it.

This doesn't help "text" without embedded newlines.

Of the mixed utilities you mention, some are exhibiting a default behavior.
If we want universal new behavior (to honor this newfangled "tagging" 
feecher) then what's needed is an OS-level implementation.
Otherwise we have to re-code, in the source, thousands of utilities, not 
to mention FLOSS, third party products, and end-user programs.
In other words, if file tagging is to have a consistent effect on ALL 
applications, the operating system has to do the "honoring".


How did we get here?

-- R; <><


On 6/8/23 05:58, David Frenzel wrote:

Since the current email thread has evolved away from this announcement I felt 
it would make sense to open a separate one.

I can see that z/OS 2.1 received the same certification back in 2013 
(https://www.opengroup.org/openbrand/register/brand3601.htm).
Timothy, are you stating that z/OS 3.1 now has the same certification that 2.1 
has or is this certification for 3.1 implying any changes as to how USS works 
and whether anything has been improved from 2.x?

I just spent hours on an issue where it turned out that some utilities honor the file tag 
for code pages while others simply ignore it and use some hard-coded value. I stopped 
counting the endless hours of time wasted because some weird code page issue appeared in 
USS. Hopefully, nobody is going to scream "POSIX compliance" at me now..

Cheers - David

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Timothy Sipples
Sent: Freitag, 26. Mai 2023 14:03
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OS 3.1: Now UNIX® Certified

z/OS 3.1 has already earned its UNIX® certification...

https://www.opengroup.org/openbrand/register/brand3693.htm

—
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity IBM zSystems/LinuxONE, 
Asia-Pacific sipp...@sg.ibm.com


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

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


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

Re: z/OS 3.1: Now UNIXR Certified

[Rick Troth]

On 6/5/23 23:19, kekronbekron wrote:

Porting applications to Linux-s390x has never been particularly difficult.

It starts getting hairy when attempts are made for vectorized apps, or other 
acceleration frameworks that are available for x86 Intel or AMD.
Can't port all of them but maybe need to re-create them, to have the same 
capabilities on Z.



Thanks for clarifying.
I view those as non-kernel optimizations. Services provided by the 
kernel/system are very very consistent.
Not saying they aren't important, but that well-written apps can at 
least function in their absence. Such sources "drop right in" to Linux 
of any flavor.


I've personally re-compiled a large number of FLOSS apps for Linux on 
more than a half dozen processor architectures.
This kind of problem (optimization) has become secondary in my 
experience. (Again, NOT saying it doesn't matter.)


Contrast "Linux to Linux" with "Linux to USS" and the question of what 
the system provides, and *how* it provides that, becomes dramatically 
more significant.

And we're *still* saddled with platform optimizations.




- KB

--- Original Message ---
On Tuesday, June 6th, 2023 at 2:25 AM, Rick Troth  wrote:



Porting applications to Linux-s390x has never been particularly difficult.
The biggest challenge has always been such things as endianness.
Linux-s390x presents the same kernel interface to userland as Linux-i386.

Porting to USS has (at least) two significant hurdles: EBCDIC and a
different system interface. Being Unix certified doesn't really help the
porting process.
Even so, I wish that more packages would be ported to USS. It's better
FOR ANY GIVEN PACKAGE that it be ported to USS (and/or to other Unix,
such as Slolaris or AIX). The more broadly a package ports, the better
the health of its heart/core.
But I'm not being altrustic: I wish that they were available on USS. I
miss them!

-- R; <><



On 6/5/23 11:01, kekronbekron wrote:


True, however, I expect it to at least be less difficult than it was in the 
past.
Less difficult that it was with linux/s390x.
Some of the key things IBM has done (and is doing) are
LinuxONE community cloud,
Wazi as a Service (on IBM cloud),
and upstreaming LLVM and Golang bits.

Icing on the cake will be zDT Learner's Edition, if it ever sees the light of 
day again.

Are there any other noteworthy ports that haven't been upstreamed to because of 
this?

- KB

--- Original Message ---
On Monday, June 5th, 2023 at 5:31 PM, David Crayford dcrayf...@gmail.com wrote:


On 5/6/2023 7:42 pm, kekronbekron wrote:


porting RocksDB
Is zOS support upstreamed too, by any chance?

The likelihood of the Meta maintainers accepting a z/OS patch PR is
extremely low. Due to z/OS being a niche platform, maintainers tend to
be hesitant in accepting patches unless they are supported by
organizations such as IBM (in the case of Node.js) with a commitment to
support the port. A notable example is the Perl community, which faced
significant challenges when removing EBCDIC support after the original
porters (IBM) lost interest. As a result, it is more commonplace to
maintain a separate patch file for z/OS-specific modifications.


- KB
--- Original Message ---
On Monday, June 5th, 2023 at 4:35 PM, David Crayford dcrayf...@gmail.com wrote:


One compelling reason to embrace zFS is its potential for modernization
and facilitating the development of contemporary tools. While
acknowledging the significance of QSAM, VSAM KSDS, and other older
technologies, it is crucial to recognize the advancements made in data
structure formats for disk files since the days of VSAM. In the present
era, LSM-trees have gained popularity for their application in NoSQL
key-value stores, blazing-fast TSDBs, and highly optimized logging systems.

Attempting to implement an LSM-tree using VSAM would be an arduous
endeavor, bordering on a nightmare. Even with the assistance of Media
Manager, it remains a Herculean task to reconcile these two disparate
technologies.

I dedicated a couple of hours to porting RocksDB, and the results have
been nothing short of exceptional. It operates seamlessly on z/OS,
demonstrating its prowess and resilience. Another noteworthy aspect of
LSM-trees is their inherent ability to merge and compact while in
operation, eliminating the need for reorgs.
https://github.com/facebook/rocksdb

https://www.youtube.com/watch?v=I6jB0nM9SKU

On 5/6/2023 5:55 pm, David Crayford wrote:


On 2/6/2023 11:31 pm, René Jansen wrote:


What I remember of it is that he was convinced it was a lot slower.
He was mistaken! I've tested it out, and QSAM is no match for zFS. You
can find the details in this gist:
https://gist.github.com/daveyc/14b45d6d70d8dd9af1848e539d78881f.
Adding an fsync() call after writing each record barely incurs any
overhead. zFS, operating with highly optimized Media Manager APIs,
handles it efficiently. Additionally, zFS functions as a caching file
s

Re: z/OS 3.1: Now UNIX® Certified

[Rick Troth]

On 6/5/23 18:55, Paul Gilmartin wrote:

On Mon, 5 Jun 2023 16:55:45 -0400, Rick Troth wrote:

Porting applications to Linux-s390x has never been particularly difficult.
The biggest challenge has always been such things as endianness.


How serious is that?  It has caused me problems only with careless
type-punning.



I would not be surprised if you're a more disciplined programmer than 
many FLOSS volunteers.





...
Porting to USS has (at least) two significant hurdles: EBCDIC


How much is that mitigated by Enhanced ASCII?  What residual
problems remain?  Unsupported library functions?



Linguistics, including graphemes, have been a problem since the Tower of 
Babel.

Sometimes that's a GOOD thing, but it *is* a thing.




... and a
different system interface. Being Unix certified doesn't really help the
*porting* process.


Aren't the C and system() interfaces the same?  What problems remain?



Short answer: no.

Have you never re-compiled flawless C source from one Unix (e.g. AIX) on 
another Unix (e.g. HP-UX)?


Now you've done and got me started!
So much time and effort went into the Gnu autoconf/automake tools, but 
that wasn't good enough so KitWare re-invented *that* wheel, stomping on 
the logic others have tried to provide.


If you're trying to say "it's not really that difficult", then I agree.
But we're up against an innumerable horde of developers content with 
"good enough", under management focused on "good enough", and funded by 
investors who just want "good enough", though "good enough" really isn't 
... if your goal is multi-platform efficacy.
Multi-platform costs. It only costs discipline, but it does cost. With 
USS, you need even more discipline. (And that's *not* a slam on USS.)



-- R; <><

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

Re: z/OS 3.1: Now UNIXR Certified

[Rick Troth]

Porting applications to Linux-s390x has never been particularly difficult.
The biggest challenge has always been such things as endianness. 
Linux-s390x presents the same kernel interface to userland as Linux-i386.


Porting to USS has (at least) two significant hurdles: EBCDIC and a 
different system interface. Being Unix certified doesn't really help the 
*porting* process.
Even so, I wish that more packages would be ported to USS. It's better 
FOR ANY GIVEN PACKAGE that it be ported to USS (and/or to other Unix, 
such as Slolaris or AIX). The more broadly a package ports, the better 
the health of its heart/core.
But I'm not being altrustic: I wish that they were available on USS. I 
miss them!


-- R; <><


On 6/5/23 11:01, kekronbekron wrote:

True, however, I expect it to at least be less difficult than it was in the 
past.
Less difficult that it was with linux/s390x.
Some of the key things IBM has done (and is doing) are
LinuxONE community cloud,
Wazi as a Service (on IBM cloud),
and upstreaming LLVM and Golang bits.

Icing on the cake will be zDT Learner's Edition, if it ever sees the light of 
day again.

Are there any other noteworthy ports that haven't been upstreamed to because of 
this?

- KB

--- Original Message ---
On Monday, June 5th, 2023 at 5:31 PM, David Crayford  
wrote:



On 5/6/2023 7:42 pm, kekronbekron wrote:


porting RocksDB
Is zOS support upstreamed too, by any chance?


The likelihood of the Meta maintainers accepting a z/OS patch PR is
extremely low. Due to z/OS being a niche platform, maintainers tend to
be hesitant in accepting patches unless they are supported by
organizations such as IBM (in the case of Node.js) with a commitment to
support the port. A notable example is the Perl community, which faced
significant challenges when removing EBCDIC support after the original
porters (IBM) lost interest. As a result, it is more commonplace to
maintain a separate patch file for z/OS-specific modifications.


- KB
--- Original Message ---
On Monday, June 5th, 2023 at 4:35 PM, David Crayford dcrayf...@gmail.com wrote:


One compelling reason to embrace zFS is its potential for modernization
and facilitating the development of contemporary tools. While
acknowledging the significance of QSAM, VSAM KSDS, and other older
technologies, it is crucial to recognize the advancements made in data
structure formats for disk files since the days of VSAM. In the present
era, LSM-trees have gained popularity for their application in NoSQL
key-value stores, blazing-fast TSDBs, and highly optimized logging systems.

Attempting to implement an LSM-tree using VSAM would be an arduous
endeavor, bordering on a nightmare. Even with the assistance of Media
Manager, it remains a Herculean task to reconcile these two disparate
technologies.

I dedicated a couple of hours to porting RocksDB, and the results have
been nothing short of exceptional. It operates seamlessly on z/OS,
demonstrating its prowess and resilience. Another noteworthy aspect of
LSM-trees is their inherent ability to merge and compact while in
operation, eliminating the need for reorgs.
https://github.com/facebook/rocksdb

https://www.youtube.com/watch?v=I6jB0nM9SKU

On 5/6/2023 5:55 pm, David Crayford wrote:


On 2/6/2023 11:31 pm, René Jansen wrote:


What I remember of it is that he was convinced it was a lot slower.
He was mistaken! I've tested it out, and QSAM is no match for zFS. You
can find the details in this gist:
https://gist.github.com/daveyc/14b45d6d70d8dd9af1848e539d78881f.
Adding an fsync() call after writing each record barely incurs any
overhead. zFS, operating with highly optimized Media Manager APIs,
handles it efficiently. Additionally, zFS functions as a caching file
system.

I have observed a certain degree of snobbery among many
traditionalists when it comes to USS. I can recall an incident from
approximately 15 years ago when I advocated for the use of sqlite in
one of our products. My boss dismissed the idea, expressing concerns
that customers might be deterred by using the UNIX file system.
Consequently, we opted for a VSAM KSDS, despite its inherent
limitations. Interestingly, it is worth noting that there are now
numerous IBM z/OS products that embrace sqlite, with some even
integrating it with HLASM.


So I told him that nobody forced him not to use QSAM for datasets just because 
it ran in USS. And it think that is a great asset of it. Just because Unix 
forces you to have a hierarchical directory system does not mean, in USS, that 
you need to use it for all I/O.

René.


On 2 Jun 2023, at 17:03, Seymour J metzsme...@gmu.edu wrote:

Dubbing is part of the setup overhead for a task, and only occurs once, so 
except for very short tasks it is just noise in measuring performance.

As for the general overhead of Unix System Services, the Devil is in the 
details. For a comparison to be reasonable, the two programs have to be using 
the services in a comparable fashion. Was your COBOL 

Re: z/OS 3.1: Now UNIXR Certified

[Rick Troth]

On 6/1/23 09:36, David Crayford wrote:
   ... OMVS is a real UNIX subsystem running on z/OS. It's not a shim 
or abstraction layer on top of native services. 



agreed! no argument here


-- R; <><

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