Re: Israel

[Phil Smith III]

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

(Hmm, with two "l"s in "signalling", at least in the title; two is typically 
British, one is American. But the article isn't even consistent, uses both. Now 
let's discuss that...)

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

Re: Question on HLASM - B to a DROP statement!?!

[Phil Smith III]

Gary Weinhold wrote:
>I can imagine a junior assembler programmer thinking that they should
>branch to the DROP to ensure it was executed before entering the
>following code. I think it takes a while for new programmers to
>understand what USING and DROP statements actually do other than the
>necessity of having a USING at the beginning of a program (often
>hidden in a macro).

Indeed! Addressability is a tricky thing to really grok. I have a fond memory 
of (gulp) over 40 years ago being asked to add some stuff to EXEC 2 on VM/370 
R6. It immediately blew addressability, and my then-manager said "Ehhh, maybe 
let's not". I said, "Let me do it and I'll come out of it understanding 
addressability". And he did, and I did! (Well, at least somewhat--I'll not 
claim to Know All, that would be obnoxious.)

For me, the operative question on this is, "Is there a use case where this 
would make sense to do?" and I do not believe that there is one. What's the 
saying about "Just because you can doesn't mean you should"?

Plus I've never accepted any RC other than 0 as acceptable from an assembler 
job. Have you??

...phsiii

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

Re: Iin Defense of FTP. FUD rules

[Phil Smith III]

Radoslaw wrote, in part:
> sftp implementation on z/OS lacks some features.

Can you elaborate? If via AT-TLS I'd be surprised. Unless there's some 
additional login majicks (2FA?) that you're referring to?

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

Re: Mainframe FTP status

[Phil Smith III]

There was a version of the PCOMM (or whatever it was called at the time) manual 
that described how IND$FILE worked in some detail. Not as much as that IUO doc 
that Tom Brennan posted, but enough that I remember the Relay/Gold folks using 
it as a reference.

It's always bothered me that something that gets used this heavily was all but 
unsupported--undocumented puts in that category for me.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, September 25, 2024 5:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe FTP status

The data stream manual is available online.

-- 
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר




From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Wednesday, September 25, 2024 5:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe FTP status

It's not! Basically *nothing* about IND$FILE is documented.

IIRC that the 3270 datastream manual, which is out of print, describes the 
basics of 3270 structured fields. The only way to know the details of how 
IND$FILE uses them is by hacking.

CM

On Wed, 25 Sep 2024 17:12:29 -0400, David Spiegel  
wrote:

>Hi Charles,
>Where is this design change documented?

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


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

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

Re: Mainframe FTP status

[Phil Smith III]

Nah, the AT-TLS issues we've had aren't AT-TLS's fault, so I'm not gonna 
disagree with you!

I'm not sure it's worthy of more accolades than stunnel, though, which goes 
back at least to 2000. Sure, it's suited to z/OS, but is it fundamentally 
different? This is a philosophical point, not a real argument!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Wednesday, September 25, 2024 4:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe FTP status

I don't but perhaps there is a Redbook or similar.

AT-TLS is one of the coolest d@mn pieces of software ever written, IMHO. It 
sits at 50,000 feet and can "TLS-ify" any TCP program. Let's say someone at 
your shop wrote some utility for your shop years ago that does some chore -- 
sends the widget status out to the factory machines or something. Now the 
auditors come along and say "you need to protect those sessions with TLS." 
Someone would have to dig into that ancient code and figure out how to make a 
bunch of complex TLS calls -- and get them perfect, or you introduce a security 
exposure waiting to happen.

But you don't have to do that. AT-TLS can impose TLS on this program without 
your having to touch a line of code!

Or look at it from IBM's point of view. How many TCP-utilizing programs do they 
have on z/OS? Every one would have to be looked at every time there was a 
significant update to TLS. But not any more. They have only one TLS-utilizing 
program to maintain, and that is AT-TLS.

Now my friend @Phil is going to chime in here and say "all is not a bed of 
roses in AT-TLS-land" and he would be right, but what I have written above is 
valid for about 90-95% of the cases.

Charles

On Wed, 25 Sep 2024 15:00:17 -0500, Don Johnson  
wrote:

>Thanks, Charles, that does make a lot of sense. I have tried to search for 
>AT-TLS, and find a lot of details, but I am not quite ready for that yet.
>
>Do you know of a primer that starts at 20,000 feet and brings me into the 
>process easily?

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

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

Re: Mainframe FTP status

[Phil Smith III]

Welll...it's doing a 3270 write, is the point. You have up to one 3270 
screen at a time: it's not going to be something that can run as a background 
process without a pretty big architectural change, one that will break it for 
every emulator until they catch up. So where's the win there? "Just use FTP." 
In fact, if I were still an emulator vendor and this change did happen, I would 
probably look into supporting FTP before I'd change my IND$FILE support.

Anyone remember where the IND$FILE protocol was documented? I do...

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Wednesday, September 25, 2024 4:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe FTP status

That was true once upon a time but has not been true since about 1995. IND$FILE 
uses a 3270 sub-protocol called "structured fields" and can transfer up to 32K 
of binary data in a block.

It's still single-task and half-duplex, and layered into TSO, all of which 
makes it a lot slower than FTP, but it is NOT 3270 screen oriented.

Charles

On Wed, 25 Sep 2024 15:30:50 -0400, David Spiegel  
wrote:

>Hi Gil,
>If IND$FILE replaces FTP, it would be slow beyond belief.
>The way that IND$FILE works is that it reads a screenfull (24*80=1920
>Bytes) at a time and deals with the this buffer.
>I cannot imagine the time it would take to Upload/Download a large TRS 
>Dataset.

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

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

Re: Mainframe FTP status

[Phil Smith III]

Feh. IND$FILE is single-threaded and requires a terminal session. And can you 
do the equivalent of mget or mput?

For all its warts, ftp for the right use case is the best answer.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
roscoe5
Sent: Wednesday, September 25, 2024 3:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe FTP status

An enhanced IND$FILE, how many of us would love that‽ That might even swing my 
choice of TN3270 emulator if it was faster and easier.

Sent from [Proton Mail](https://proton.me/mail/home) for iOS

On Wed, Sep 25, 2024 at 3:04 PM, Paul Gilmartin 
<[042bfe9c879d-dmarc-requ...@listserv.ua.edu](mailto:On Wed, Sep 25, 2024 
at 3:04 PM, Paul Gilmartin < wrote:

> On Wed, 25 Sep 2024 12:26:54 -0500, Charles Mills wrote:
>
>>I find it vanishingly unlikely that FTP would go away or have its 
>>functionality significantly reduced.
>> .
> Replace it with an enhanced IND$FILE?
>
> --
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: Is z/OS FTP encrypted?

[Phil Smith III]

Hmm. Yeah, our code uses GSK directly, so I don't think the ioctl stuff 
applies. Sounds like you're suggesting a separate tester app that *would* use 
the ioctl stuff and that it could thus detect AT-TLS. Part of the problem with 
that (besides it being more work than I think I want to invest) is that a 
customer might be fine and then get a wild hare/hair* and enable it. So "Your 
product stopped working", not "We're doing an install and it's not working". In 
the latter case, "Run this diagnostic program" would be more likely to occur to 
us.

Ah, here's a thought: since one of the first things we do via https is just a 
GET, a telnet to port 443 would actually appear to connect if AT-TLS is in 
place, yes? Now, that requires the customer to have telnet available on z/OS, 
but that's not a crazy requirement. And it's "free". I already have folks using 
telnet to test for basic connectivity--"Can we even get to the server?" If you 
telnet to 443, let it time out, and look at the messages; and then telnet to 
442 and do the same, the messages will differ IFF you're actually getting to 
the server. The analogy is the difference between calling someone, them 
answering, and you never responding (the connection happens but since you're 
using telnet, you never do a TLS handshake) and calling someone and it never 
getting answered. This is surprisingly useful for the many sites who don't have 
a good handle on their z/OS-to-other-boxes connectivity. 

Of course as I've said, we've seen this exactly twice, and would hopefully be 
quicker to recognize it, were it to happen a third time. So maybe this isn't 
worth worrying about a whole lot; I was kinda hoping that the simple addition 
of a "Hey AT-TLS, it's me, Margaret" might let us give an error saying "Don't 
do that!"

Appreciate the info, and will definitely keep it in case it does seem worth 
pursuing!

...phsiii

*There seems to be disagreement about which of these the idiom really intends.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Timothy Sipples
Sent: Thursday, September 19, 2024 12:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Is z/OS FTP encrypted?

Phil Smith III wrote:
>If I?m "Paul"* then can you point me at something that would describe 
>how to become AT-TLS aware in a GSK application? Thanks!
>...phsiii
>*This happens to me *constantly*, like at least once a month. My dad
>(PHS2) said it never happened to him! Four letters, one syllable, 
>begins with a P and ends with an L but otherwise...?!?

Sorry, Phil. Paul commented in this thread, and I thought he had experienced 
the support issue.

It?s hard to be too precise about implementation details since I?m not familiar 
with your application. z/OS AT-TLS aware applications use the SIOCTTLSCTL ioctl 
interfaces. Here?s the general entry point into the relevant z/OS 3.1 
documentation (link subject to change):

https://www.ibm.com/docs/en/zos/3.1.0?topic=tls-using-siocttlsctl-ioctl

I?m speculating, but maybe you could include an embedded or separate 
?IVP-style? initial program step that tests/?pings? a connection that?s 
otherwise identical to your GSK-based connection (same IP address, port, etc.) 
If the test reveals that AT-TLS is configured by policy for the connection then 
that?d be useful information to report. Ideally when you detect AT-TLS in use 
(meeting certain baseline capabilities perhaps) you?d issue a message/log and 
proceed with the non-TLS connection logic in your application ? assuming you 
have that logic. (?XYZ1234: Connection secured with z/OS AT-TLS. TLS settings 
in MYPROD.PARM ignored.?) But I suppose in a ?Phase 0? initial implementation 
you could issue a message/log and stop.

?
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity IBM Z/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

Re: Is z/OS FTP encrypted?

[Phil Smith III]

If I’m "Paul"* then can you point me at something that would describe how to 
become AT-TLS aware in a GSK application? Thanks!

...phsiii

*This happens to me *constantly*, like at least once a month. My dad (PHS2) 
said it never happened to him! Four letters, one syllable, begins with a P and 
ends with an L but otherwise...?!?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Timothy Sipples
Sent: Wednesday, September 18, 2024 1:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is z/OS FTP encrypted?

Paul Gilmartin wrote:
>Is it evident in the client terminal window that the connection is 
>not/is encrypted?  (I'm envisioning something like the lock favicon in 
>a browser window.)  Alas, if the mechanism is fully transparent the 
>encryption condition might not be dectable by that client.

John S. Giltner, Jr. wrote:
>It is detectable on the non-z/OS side as the non-z/OS side still need 
>to do SSL/TLS. It's only transparent on the z/OS side and for FTP (client
>or server) it is only "semi-transparent."   For FTP the z/OS server/client
>knows that that SSL/TSL is being used, it is just not using SystemSSL directly.
>AT-TLS is making all of the SystemSSL calls and z/OS server/client code 
>see plain text.

Applications on z/OS that use AT-TLS can be divided into three categories: 
basic, aware, and controlling.

“Basic” means the application has absolutely no idea AT-TLS is “in the loop.” 
Such applications are TLS “naïve.”

“Aware” means the application senses that AT-TLS is (or is not) “in the loop,” 
and it may use its awareness for certain purposes such as displaying messages 
(example: “XYZ1234: Connection is secured via z/OS AT-TLS”), logging, warning, 
and/or halting if some baseline security strength is not met. The awareness can 
be simple or detailed, for example awareness of what cipher suite z/OS AT-TLS 
negotiates.

“Controlling” means the application explicitly directs z/OS AT-TLS’s behaviors 
in certain ways. z/OS Communications Server must be informed ahead of time that 
an application is controlling via the “ApplicationControlled” setting in the 
AT-TLS policy.

The second and third categories require the application to use certain APIs to 
interact with z/OS AT-TLS.

AFAIK the FTP server and client on z/OS are AT-TLS aware applications. For 
example, you can set the SECURE_FTP REQUIRED configuration statement in the FTP 
client to require TLS (and SECURE_DATACONN PRIVATE).

Paul, if you’ve had support issues when your customers turn on z/OS AT-TLS with 
your application then presumably you could make your application AT-TLS aware. 
You could display a message and/or write something to your log when you detect 
AT-TLS in use for your application. You cannot stop (nor should stop) a 
customer from configuring AT-TLS. There are excellent reasons customers do that 
(read on), but at least you can know when it happens. You may not even get a 
support phone call when they “double TLS” your application connections because 
your customers should be able to check your message/log themselves based on the 
troubleshooting documentation you provide.

Alan Altmark wrote:
>Windows native FTP doesn't support FTPS (FTP with RFC 4217 - aka 
>negotiated or explicit TLS). Filezilla does (and has z/OS support). The 
>FTP client that comes with PCOMM does (I'm not talking about 3270 file 
>transfer). There are others.
>Don't mess with AT-TLS for this. z/VM and z/OS added the support for 
>RFC 4217 so that there's no question about what is and isn't encrypted.

z/VM is different in certain respects. On z/OS it’s *imperative* you “mess” 
with AT-TLS.

With z/OS 2.5 or higher you *must* configure z/OS AT-TLS if you want the z/OS 
FTP server to operate with TLS (FTPS). (z/OS 2.4 reaches End of Support mere 
days from now: September 30, 2024. A support extension for z/OS 2.4 is 
available for up to 3 years for an additional charge.)

Although the z/OS FTP client still offers “built-in” TLS support IBM recommends 
that you use z/OS AT-TLS with the FTP client, too. The documentation I linked 
to in my previous message mentions that recommendation.

In fact, IBM generally recommends you use z/OS AT-TLS instead of “built-in” 
TLS. There are several reasons, but the basic reason is that consolidating 
TLS-related configuration (including certificates) in one logical “place” in 
the operating system helps make network security management and enforcement 
much easier and helps promote “crypto agility.” If you must run around to 58+ 
different application configuration files to look for cipher suites, TLS 
versions, certificates, etc., etc. it’s a lot more work (and a lot more 
security risk) than just checking z/OS AT-TLS for everything. The only 
remaining application supplied with z/OS Communications Server that can use its 
own "built-in” TLS support is the FTP client. I’d take the hint, and for all 
applications. Unless there’s a “darn good reason” otherwise, and I’m curious 
what that D

Re: Is z/OS FTP encrypted?

[Phil Smith III]

Because since Windows FTP doesn't "do" SFTP, it won't work. You can't throw a 
TLS handshake at a port that isn't going to recognize it and react 
appropriately. That's what I keep harping about: AT-TLS is *great*, I'm not 
dissing it at all; but it's not magic, you can't just add it at random and say 
"Now  is encrypted so it's all good". It has to work, too, and 
won't if that connection isn't expecting a TLS handshake.

So yes, it can talk to Linux; it can connect to any thing that's expecting TLS. 
If you had a text-based browser, you could do a GET to http://www.google.com/ 
and it would work, and the Google end would think you were using https (because 
you would be). Your process wouldn't know that, would think it was using http.

Alan says Filezilla supports FTPS, so no need for AT-TLS with Filezilla. 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Billy Ashton
Sent: Tuesday, September 17, 2024 4:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is z/OS FTP encrypted?

I am curious about AT-TLS and why not consider it?

Is AT-TLS only for use when two mainframes are communicating, or would it work 
if the server is a Linux or other OS machine? Then, is it only a mainframe 
client that can use the AT-TLS connection, or could Filezilla use it when 
connecting to a mainframe or other server?

Thank you and best regards,
Billy Ashton


-- Original Message --
>From "Alan Altmark"  To IBM-MAIN@listserv.ua.edu Date 
>9/17/2024 2:19:59 PM Subject Re: Is z/OS FTP encrypted?

>Windows native FTP doesn't support FTPS  (FTP with RFC 4217 - aka negotiated 
>or explicit TLS).Filezilla does (and has z/OS support).  The FTP client 
>that comes with PCOMM does (I'm not talking about 3270 file transfer).   There 
>are others.
>
>Don't mess with AT-TLS for this.   z/VM and z/OS added the support for RFC 
>4217 so that there's no question about what is and isn't encrypted.
>
>Alan Altmark
>IBM
>
>--
>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: Is z/OS FTP encrypted?

[Phil Smith III]

John S. Giltner, Jr. wrote, in part:
>The remote side still has to support SSL/TLS so it know.

This is of course correct, and is where the danger comes from folks thinking 
"Oh, adding TLS will be good, it's adding security!" Whichever side is seeing 
the encrypted traffic has to be ready to deal with it. I suspect, for example, 
that you can't just add AT-TLS to an SMTP connection because the SMTP server 
you're connecting to is going to expect a STARTTLS keyword to say "Yo, we be 
gonna encrypt now, let's do the handshake".

If you think I'm harping on this, I agree with you. But given the time and 
effort we spent trying to figure it out when a customer (or rather, their 
outsourcer) randomly added AT-TLS as a second layer of encryption, I'm'a gonna 
harp. Understand that from the server (non-z/OS) side in that case, we could 
see the handshake succeeding--it's just that it was the AT-TLS handshake, and 
the payload inside that was another handshake.

New feature: InfiniteTLS, where the handshake process looks for and handles 
multiple layers of TLS. YES, I'm joking...I hope.

John also wrote:
>Unless of course the other side is also z/OS running AT-TLS.

Or stunnel (https://www.stunnel.org/) or equivalent. This transparent wrapping 
is not actually unique to z/OS; what's unique (I think) is that it's at the OS 
level. I use stunnel to enable a non-TLS-aware Bayesian spam proxy that I've 
been using for ~20 years, for example. Works great.

...phsiii

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

Re: Is z/OS FTP encrypted?

[Phil Smith III]

Timothy Sipples wrote, in part:
>z/OS AT-TLS supports both inbound and outbound connections.

Cool! Now I'm wondering if we should have gone that route in 2008, instead of 
using GSK ourselves. O well, sure not gonna change now!

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

Re: Is z/OS FTP encrypted?

[Phil Smith III]

I saw Hayim's note that FTP on z/OS supports encryption, and uses 
AT-TLS/PAGENT, so I'm not asking about FTP itself here.

Rather, I'm wondering about the earlier suggestion to add AT-TLS. In the cases 
I've seen, AT-TLS only works for outbound. Can you also tell it "This incoming 
connection will be encrypted, please take the data out of the tunnel and 
present it to the application unencrypted"?

I expect y'all are gonna say "Of course", in which case today will be a good 
day -- I will have learned something!


And if it is "Of course", the reason I've not seen it is surely because the 
only times I've encountered AT-TLS is when people added it *on top* of the TLS 
our product already uses via GSK. As I've written before, this is a Very Bad 
Idea, because the outbound connection from z/OS, encrypted via AT-TLS, 
completes the handshake with the external server--which then gets the "inside" 
encrypted payload (the one WE encrypted via GSK), says "What the  is 
THAT?!" and hangs up.

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

Re: [Upgrading z/OS vs. z/VM

[Phil Smith III]

Thanks to all who responded. Interesting and I learned a lot.

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

Re: Happy 20th Birthday to zAAP

[Phil Smith III]

Wow, that's hard to believe--it seems like it was just yesterday! The perils of 
aging, I  guess...

But is it really "Hapy Birthday" if it's been subsumed? A theological question.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Timothy Sipples
Sent: Sunday, September 1, 2024 10:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Happy 20th Birthday to zAAP

As previously reported back in 2004, the first customer production use of zAAP 
(the System z Application Assist Processor) went live on September 1, 2004. 
Which was impressively speedy because it occurred more than 3 weeks before the 
earliest release of z/OS to support zAAP (z/OS Version 1.6) became Generally 
Available - and barely 2 months after zAAP (the hardware feature) was 
introduced. IBM discontinued zAAPs several years ago because their functions 
were fully incorporated into zIIPs.

Happy 20th Birthday, zAAP!

-
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity IBM Z/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

Re: [EXTERNAL] Upgrading z/OS vs. z/VM

[Phil Smith III]

Ok, that's interesting. Maybe we're more constrained because it's an ADCD image?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Tuesday, September 3, 2024 11:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Upgrading z/OS vs. z/VM

Phil,

I'm going to give you a qualified "nope" here.  Granted I work at a small site 
- 2 production LPARs and a sandbox, no shared anything, no sysplex yadda yadda 
yadda.  We currently have 3.1 sitting on a mod27 volume (with its unix 
filesystem datasets that shipped with it ready to go).  Had to put new catalog 
entries into the master for the new USS datasets and new libraries on the RES 
pack - using indirect cataloging for it.  IPLed 3.1 and ran for a few hours 
before we hit a snag that forced us to back out to 2.4.  Backout was simply 
shutting down, pointing the hardware to the 2.4 SYSRES and IPLing.   No messing 
with spool or anything else.  Just need to make sure fallback maintenance is in 
place.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Tuesday, September 3, 2024 10:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Upgrading z/OS vs. z/VM

I'm NOT trying to start a war here, just trying to grok whether I'm confused or 
not. I will make assertions below, any/all of which may be wrong, but that 
seems better than qualifying each with "I think..." etc.

Upgrading z/VM versions has been pretty trivial for quite a while: point to a 
new CP module, reIPL. 

Upgrading z/OS is a lot harder. There's no way to just swap the OS itself, 
which means you need to clone the LPAR and then connect the user data volumes, 
with required catalog tinkering. And SPOOL needs to be backed up and restored 
(or contents lost). 

Is this really still true in 2024?

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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.

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

Upgrading z/OS vs. z/VM

[Phil Smith III]

I'm NOT trying to start a war here, just trying to grok whether I'm confused or 
not. I will make assertions below, any/all of which may be wrong, but that 
seems better than qualifying each with "I think..." etc.

Upgrading z/VM versions has been pretty trivial for quite a while: point to a 
new CP module, reIPL. 

Upgrading z/OS is a lot harder. There's no way to just swap the OS itself, 
which means you need to clone the LPAR and then connect the user data volumes, 
with required catalog tinkering. And SPOOL needs to be backed up and restored 
(or contents lost). 

Is this really still true in 2024?

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

MP3000 parts available

[Phil Smith III]

(Resending to IBM-MAIN because it rejected the HTML-formatted original; 
cross-posted to IBM-MAIN, IBMVM, LINUX-390, and the Herucles list)

Someone in Oakland, CA (near Lake Merritt) has most of an MP3000 they're trying 
to give away. No HMC, but the chassis, disks, etc.; FOB Oakland.

If you're interested, email me directly at mp3...@akphs.com and I'll connect 
you.

The above is all I know (besides their email address, which I'm obviously not 
posting publicly) so please don't ask me questions!

.phsiii

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

Re: Relative Instructions not generated by some IBM macros, e.g. STORAGE and ATTACHX

[Phil Smith III]

Gil wrote, in part:
>"Enhanced" might be a better word than "fixed."

Sure--hence my scare quotes. OP made it sound like they considered this a bug, 
more or less.

Hey, let's write a SHARE requirement to convert all macros and source to use 
Jump instructions! IBM will want to get right on that... /s

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

Re: Relative Instructions not generated by some IBM macros, e.g. STORAGE and ATTACHX

[Phil Smith III]

I hadn't ever viewed the relative instructions as completely replacing 
addressability. Interesting.

I do suspect that this is never going to be "fixed": it's a lot of work, and it 
essentially ain't broken, so...

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Monday, August 26, 2024 2:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Relative Instructions not generated by some IBM macros, e.g. 
STORAGE and ATTACHX

ASMMREL?

ARCHLVL=2? How old are the boxen you support?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Richard Zierdt 
Sent: Monday, August 26, 2024 11:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Relative Instructions not generated by some IBM macros, e.g. STORAGE 
and ATTACHX

Writing code using relative addressing, as much as reasonably possible.
Problem:  some IBM macros, e.g., ATTACH(X) and STORAGE, generate L and LA(E) 
instructions instead of, e.g., LRL and LA(E)Y.

STORAGE  OBTAIN,
  Length=(0),
  Loc=(31,31)
generates this instruction
  L  15,=AL1(B'',(0*16),(0),B'01110110')
requiring a base register
instead of, e.g.,
  LRL   15,=AL1(B'',(0*16),(0),B'01110110')
(Load Relative Long) which does not.

ATTACHX EP=SUBTASK
generates
  LAE   15,IHB0098 SET UP LIST ADDRESS
instead of
 LAEY  15,IHB0098 SET UP LIST ADDRESS

Temporary base-displacement addressing can be established prior to issuing 
these macros, but that defeats the purpose of relative addressing.

These macros are included:
 SYSSTATE ARCHLVL=2Support for relative addressing
 IEABRCX DEFINE
 IEABRCX ENABLEChange base-displacement to relative
but apply to branch instructions, not load.

Any perspectives would be helpful, either with an alternative solution, or 
that, like taxes, you live with it.
Thanks –
Richard Zierdt

Confidentiality Warning/Avertissement de confidentialité:

This message is intended only for the named recipients. This message may 
contain information that is privileged or confidential. If you are not the 
named recipient, its employee or its agent, please notify us immediately and 
permanently destroy this message and any copies you may have. Ce message est 
destiné uniquement aux destinataires dûment nommés. Il peut contenir de 
l'information privilégiée ou confidentielle. Si vous n'êtes pas le destinataire 
dûment nommé, son employé ou son mandataire, veuillez nous aviser sans tarder 
et supprimer ce message ainsi que toute copie qui peut en avoir été faite.

--
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: 3270 programming

[Phil Smith III]

Might be useful to know what OP wants to do. There are things like the IND$FILE 
protocol that aren't documented, or barely; IIRC, the best doc on that one is 
hiding in the PC3270 book. But it was 30+ years ago, from the Relay/Gold days, 
and I could be misremembering. *Something* to do with 3270s was barely 
documented and hiding in some other book!

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

Re: How to "touch" mainframe files

[Phil Smith III]

A. We don't have enough data to migrate so that hadn't occurred to me. Of 
course!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, August 5, 2024 4:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to "touch" mainframe files

Yes it does – recalling large migrated files may not have enough free DASD to 
get recalled, especially when there are lots of them (as OP also said I 
believe).

Hence the OP request to change last access time WITHOUT a recall (i.e. without 
OPEN).  Plus recalling really large datasets from ML2 can take quite a lot of 
elapsed time.

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Monday, August 5, 2024 4:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to "touch" mainframe files


Well there you go:



//MASK EXEC PGM=IEFBR14

//STEPLIB   DD DISP=SHR,DSN=some.dataset.name



Looked before, DOLR was 8/1; repeated to be sure looking at DOLR didn't change 
DOLR (which would be Bad, but); ran job; now DOLR is 8/5.



Now, OP had something about "the files are large" but if anyone explained why 
that mattered for this, I missed it. Does it?



-Original Message-

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Seymour J Metz

Sent: Monday, August 5, 2024 3:46 PM

To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>

Subject: Re: How to "touch" mainframe files



An authorized application can directly update the VTOC, but an unauthorized 
application needs the allocation and OPEN. Neither the C/I nor the Initiator 
will open the dataset unless it is, e.g., STEPLIB.



--











From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of 
Itschak Mugzach 
<0305158ad67d-dmarc-requ...@listserv.ua.edu<mailto:0305158ad67d-dmarc-requ...@listserv.ua.edu>>

Sent: Monday, August 5, 2024 2:54 PM

To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>

Subject: Re: How to "touch" mainframe files



I thought the op requires no allocation, no IO. VTOC alteration is the only 
way, I assume.



ITschak



*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere

Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and 
IBM I **|  *



*|* *Email**: i_mugz...@securiteam.co.il<mailto:i_mugz...@securiteam.co.il> 
**|* *Mob**: +972 522 986404 **|*

*Skype**: ItschakMugzach **|* *Web**: 
https://urldefense.com/v3/__http://www.securiteam.co.il/__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!LaR1PZcX103EbarclO_HONndsbbmg0ZktTuwseGM5BQRX4jaldPz9UItnQKbTisVDR9dOAWIf-tnTWsbu4E$<https://urldefense.com/v3/__http:/www.securiteam.co.il/__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!LaR1PZcX103EbarclO_HONndsbbmg0ZktTuwseGM5BQRX4jaldPz9UItnQKbTisVDR9dOAWIf-tnTWsbu4E$>
  **|*



On Mon, Aug 5, 2024 at 9:02 PM Seymour J Metz 
mailto:sme...@gmu.edu>> wrote:



> No, you need an OPEN.

>

> --

> Shmuel (Seymour J.) Metz

>

>

>

> 

> From: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU>> on

> behalf of Toby Seguin 
> <028ef8c142dd-dmarc-requ...@listserv.ua.edu<mailto:028ef8c142d
> d-dmarc-requ...@listserv.ua.edu>>

> Sent: Monday, August 5, 2024 1:53 PM

> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>

> Subject: Re: How to "touch" mainframe files

>

> I used to run IEFBR14 with a disp of shr,keep,keep to touch a dataset.

> It keeps it from going to archive without opening it. Not sure if it

> updates the last used date or not. I'd assume it would.

>

> Andrew Huntington

> Project Coordinator

> SECURITY ARCHITECTURE

--

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

Re: How to "touch" mainframe files

[Phil Smith III]

Well there you go:

//MASK EXEC PGM=IEFBR14 
//STEPLIB   DD DISP=SHR,DSN=some.dataset.name

Looked before, DOLR was 8/1; repeated to be sure looking at DOLR didn't change 
DOLR (which would be Bad, but); ran job; now DOLR is 8/5.

Now, OP had something about "the files are large" but if anyone explained why 
that mattered for this, I missed it. Does it?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Monday, August 5, 2024 3:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to "touch" mainframe files

An authorized application can directly update the VTOC, but an unauthorized 
application needs the allocation and OPEN. Neither the C/I nor the Initiator 
will open the dataset unless it is, e.g., STEPLIB.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר




From: IBM Mainframe Discussion List  on behalf of 
Itschak Mugzach <0305158ad67d-dmarc-requ...@listserv.ua.edu>
Sent: Monday, August 5, 2024 2:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to "touch" mainframe files

I thought the op requires no allocation, no IO. VTOC alteration is the only 
way, I assume.

ITschak

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

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





On Mon, Aug 5, 2024 at 9:02 PM Seymour J Metz  wrote:

> No, you need an OPEN.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
>
>
> 
> From: IBM Mainframe Discussion List  on 
> behalf of Toby Seguin <028ef8c142dd-dmarc-requ...@listserv.ua.edu>
> Sent: Monday, August 5, 2024 1:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How to "touch" mainframe files
>
> I used to run IEFBR14 with a disp of shr,keep,keep to touch a dataset. 
> It keeps it from going to archive without opening it. Not sure if it 
> updates the last used date or not. I'd assume it would.
>
> Andrew Huntington
> Project Coordinator
> SECURITY ARCHITECTURE
>
> --
> 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: How to "touch" mainframe files

[Phil Smith III]

Radoslaw Skorupka wrote:
>IMHO "last reference date" is updated wherever ISPF user type I (info) line 
>command in >P.3.4 menu.

So there you go: a HLLAPI script that drives a TSO session... /s

(OK, it might work, but several MUCH simpler approaches have been mooted here!)

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

Re: How to "touch" mainframe files

[Phil Smith III]

Well this is interesting, in that it sounds like I'm not the only one who's not 
100% clear on what the rules are for "touch". Doc doesn't say much either 
(typical *ix doc).

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bernd Oppolzer
Sent: Friday, August 2, 2024 6:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to "touch" mainframe files

Phil asked:

This makes me realize that I don't know what "touch" actually does. I mean, I 
know the effect, but what does it have to do to make that happen?

IMO:

The arcane Unix systems probably had only one timestamp per file, no difference 
for read/write, and files are simply chains of bytes, so I believe that what 
touch does is open the file for append, then append nothing and then close the 
file.
This way the date (of last write) should be set to the current date (or 
timestamp).

A simple open for read should IMO not change the date of a file.

But that's some speculation on my part ...

HTH, kind regards

Bernd


Am 02.08.2024 um 22:30 schrieb Phil Smith III:
> Billy Ashton asked how to do the equivalent of a USS "touch" on a z/OS data 
> set.
>
> I'm wondering if there's something like the C "DD:ddname" filename 
> specification hack that could be used. I know this would seem odd: run a 
> batch job that uses BPXwhatever to run USS "touch", but if it's possible...?
>
> This makes me realize that I don't know what "touch" actually does. I mean, I 
> know the effect, but what does it have to do to make that happen? If it's 
> some filesystem function, a minimal C program might be able to use the 
> "DD:ddname" hack and that function. Googling suggests that it just opens the 
> file and that that's sufficient to update it, but there has to be more, since 
> it can optionally update just the last access time, without updating the last 
> changed time.
>
> In fact, the more I think about this, I now wonder what "last referenced" 
> even means; I assume it's time of last access, not change?
>
> Billy wrote, in part:
>> We don't want to do things like allocate, open, and print one record, 
>> as some of these files are huge (25-50GB).
> Would you need to print a record to update "last referenced"? Shouldn't 
> reading a record suffice? Do you even need to do that? Why does the size of 
> the file matter here?
>
> I'm sure these are dumb questions but my in-depth filesystem knowledge is for 
> other OSes, so I'm just knowledgeable enough to be curious...
>
> --
> 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: How to "touch" mainframe files

[Phil Smith III]

Billy Ashton asked how to do the equivalent of a USS "touch" on a z/OS data set.

I'm wondering if there's something like the C "DD:ddname" filename 
specification hack that could be used. I know this would seem odd: run a batch 
job that uses BPXwhatever to run USS "touch", but if it's possible...?

This makes me realize that I don't know what "touch" actually does. I mean, I 
know the effect, but what does it have to do to make that happen? If it's some 
filesystem function, a minimal C program might be able to use the "DD:ddname" 
hack and that function. Googling suggests that it just opens the file and that 
that's sufficient to update it, but there has to be more, since it can 
optionally update just the last access time, without updating the last changed 
time.

In fact, the more I think about this, I now wonder what "last referenced" even 
means; I assume it's time of last access, not change?

Billy wrote, in part:
> We don't want to do things like allocate, open, and print one record, 
> as some of these files are huge (25-50GB).

Would you need to print a record to update "last referenced"? Shouldn't reading 
a record suffice? Do you even need to do that? Why does the size of the file 
matter here?

I'm sure these are dumb questions but my in-depth filesystem knowledge is for 
other OSes, so I'm just knowledgeable enough to be curious...

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

Re: Breaking Event Address, BEAR

[Phil Smith III]

Too early, too many acronyms/initialisms--I spent several seconds trying to 
figure out what 'IBM' stood for. Sheesh. ("If BEAR..." "I Barely Mean...")

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Monday, July 29, 2024 7:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Breaking Event Address, BEAR

BEAR is not the address of the last branch, it's the address of the last 
breaking event. If you brnch to an OPEN and get am S213, I don't believe that 
there is any way to recover the branch.

What is the specific scenario you're concerned with.

IBM: is the BEAR at the time of a program check available to recovery exits?

-- 
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר




From: IBM Mainframe Discussion List  on behalf of 
Steve Austin 
Sent: Monday, July 29, 2024 6:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Breaking Event Address, BEAR

I lied I don’t want the Breaking Event address  I’d like the source of the
Breaking Event address. And I’m assuming the source of the BEA is the same
as the source of the branch entries in the trace table. I’d like my running
program to retrieve the address of the last branch without breaking
anything. Is this possible? Thanks

--
This e-mail message has been scanned and cleared by Google Message Security
and the UNICOM Global security systems. This message is for the named
person's use only. If you receive this message in error, please delete it
and notify the sender.

--
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: Does MVCDK move 'per byte' like MVC?

[Phil Smith III]

On z/VM, using PER, you can see that MVCL is interruptible: issuing one for a 
big area (typically MB), you may see the same instruction traced multiple 
times. Kinda fun. At least that was true at some point; been a while since I've 
used PER in anger.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Attila Fogarasi
Sent: Friday, July 26, 2024 5:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Does MVCDK move 'per byte' like MVC?

To answer "how can you tell", another TCB will see a partial move for MVCL 
while only the complete move is seen for MVC.  Rather important for some 
multi-tasking code.  On some older machines such as CMOS the partial move was 
on a cache line boundary, so by block but not predictable.  Don't know for 
current hardware, where cache management is much more sophisticated.
Made for some interesting bugs for pre-z.

On Sat, Jul 27, 2024 at 7:35 AM Paul Gilmartin < 
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 26 Jul 2024 16:03:40 -0500, Mike Schwab wrote:
>
> >MVC has another exemption.  The entire 256 bytes appear to move at 
> >once.
> >
>  How can you tell?  How might this "appear" different from moving 
> sequentially?  Was that true even on the earliest s/360?  Is that to 
> say that the move appears "block concurrent"?
>
> >   ... Vs MVCL appears to move 1 byte at a time with register updates.
>
> --
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: World’s largest computer outage!

[Phil Smith III]

Andrew Rowley wrote, in part:
>You can't really blame Windows in this case.
>If you had a linklisted, APF authorized product that hooked into
>system functions and was remotely updateable by the vendor without a
>system restart, they could equally bring down all z/OS systems
>simultaneously.

Exactly. This is a process problem on two levels:
1) ClownStrike (I can't seem to stop typing their name that way*) screwed up
2) The Windows ecosystem made it hard to undo that change

#2 is on Windows, but Windows didn't cause the breakage. We've discussed the 
architecture that requires this level of security intrusiveness, and can whine 
about the company policies that mandate them. But if there were 1.4 billion 
z/OS systems in the world, many of them run by people who essentially know 
nothing about computers and have them connected to the Internet, I'm not 
convinced z/OS wouldn't have an equally nasty security problem. (And no, I 
can't quite imagine Aunt Maisie submitting jobs, but you get my point!)

Yes, there are aspects that make z/OS probably inherently more secure; yes, the 
z/OS ethos is such that mainframe vendors think about this stuff more. But, 
again, with 1.4B such machines, the equation would change a lot. The general 
attitude at most vendors seems to be that you buy software engineers by the 
pound. That's one way you get things like this incident.

And to people saying "This stuff never happened before we had Windows" -- sure 
it did. There were DOS viruses. What there weren't were over a billion clueless 
end-users connected to the Internet, essentially saying "Please infect me!" and 
necessitating a multi-$B industry of software that doesn't do anything except 
keep other things from happening. Nice work if you can get it, BTW.


Finally, a comment re WordPerfect: I remember when Novell bought it for $1.8B, 
and then sold it a bit over a year later to Corel for $180M. I commented to my 
boss at the time, "Two more owners and we can afford it!"


*And yes, "There but for the grace of &deity go any of us vendors..."

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

Re: World’s largest computer outage!

[Phil Smith III]

Gil wrote:
>But these things happen. I heard of a product that crashed
>reproducibly at customer sites having 8 or more tape drives.

>Who does that in a test lab!>

Exactly. The real problem here isn't that *gasp* there was a software problem: 
it's that nobody thought about how things could fail and how to back it out 
gracefully.

My recommendation: SMP/E for Windows! /s

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

Re: World’s largest computer outage!

[Phil Smith III]

Denis wrote, in part:
>It would be so easy to keep the last good known boot images (including
>drivers) and switch back automatically, if booting does not succeed
>for e.g. 3 times.

Indeed. That might even be more elegant than the solution I proposed yesterday 
where it would ask "Does ye wanna be revertin' here?" after any BSOD.

I would suggest that any boot-after-failure should tell them "Try this again a 
few times", lest people get one BSOD, reboot, fail, and then call the helpdesk 
immediately. You'd want them to get it back up and running and *then* report 
the problem, rather than swamping support with zillions of identical tickets to 
which the response is "Reboot twice more"!

As I've been saying for 30++ years:
Applications people worry about how it's going to work.
Systems people worry about how it's going to fail.
Neither Microsoft nor ClownStrike seem to have enough systems folks.

...phsiii

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

Re: [EXTERNAL] Re: [IBM-MAIN] Connect:Direct

[Phil Smith III]

Sterling sold a lot more than storage management. They were, like CA, a huge 
company that most folks had never heard of.

Humorously, there's a Sterling, Virginia about five miles from what was the 
Sterling Software office in Reston. Occasionally while working for Sterling 
someone would ask me where I worked, and I'd say "Sterling Software". 
Invariably that would lead to a discussion where I'd realize that they were 
picturing some tiny outfit up in Sterling. I'd explain that no, this was a 
multi-billion dollar company selling enterprise software for a variety of 
operating systems.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Rich Tabor
Sent: Saturday, July 20, 2024 11:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: [IBM-MAIN] Connect:Direct

it is now IBM Sterling Connect:Direct

Get Outlook for iOS 
From: IBM Mainframe Discussion List  on behalf of 
Dean Kent <06a91de5360b-dmarc-requ...@listserv.ua.edu>
Sent: Friday, July 19, 2024 6:47:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: [IBM-MAIN] [EXTERNAL] Re: [IBM-MAIN] Connect:Direct

My recollection:

NDM was owned by Sterling Commerce, which sold network products, while
Sterling Software sold storage management solutions.   In 1993 Sterling
'bought' (actually merged with) Systems Center and renamed the product
Direct:Connect.In 2000, CA aquired Sterling Software while Sterling
Commerce was bought by SBC Communications.   Where it went after that, I
didn't track (I was in the storage management group of CA until 2010).

On 7/18/2024 11:00 AM, Dave Beagle wrote:
> Sterling owned NDM. (Network Data Mover) It was one of the 15 or so products 
> I was responsible for from 2003-2017, it became Connect Direct in 93 & IBM 
> acquired it in 2010. I talked with a number of Sterling people over those 
> years. AFAIK, IBM still owns it but it might be supported by a third party. 
> When IBM bought it, our cost skyrocketed to 100k/year from 20k a year and we 
> decided to drop support and ran it unsupported for years. I wasn’t happy but 
> management always was cost driven.
>
>
>
> Dave B.
>
> إسرائيل قتلت 40 ألف فلسطيني بريء
>
>
> On Thursday, July 18, 2024, 12:30 PM, Radoslaw Skorupka 
> <0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:
>
> To clarify: Nobody said it is no longer IBM-branded product.
> SDSF is part of z/OS, but it is developed by Rocket Software.
> Many other products are also "off-shored" out of IBM to HCL, 21CS, 
> Rocket and maybe other companies. (*)
>
> Regarding Connect:Direct - I don't know it's status.
> IMHO it is somehow internal competitor to MQ MFT, so I don't know 
> whether IBM is willing to enhance it or rather keep it moribound.
>
>
> (*) Side note: JES3 and z/VSE are notable exceptions - those product 
> were somehow "sold" to the companies (Phoenix and 21CS) and now both 
> are marketed and supported be those companies.
> However TWS, SDSF, PCOMM, Fault Analyzer, Omegamon - all of them are 
> marketed and supported by IBM. Including APARs, PTFs, etc.
>

--
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: World’s largest computer outage!

[Phil Smith III]

It seems to be a driver in those PCs that talks to something in some cloud 
somewhere somehow.

The House is now taking bets on how long it takes to get a coherent story on 
what happened.

(Which is reasonable--fix it, THEN talk about it!)

This one seems slightly more self-inflicted (in that the victim companies chose 
CrowdStrike or Heimdall or whatever other choice) than the Rogers outage last 
year, which was much more pervasive but of course across a smaller market. 
Similar in terms of perfectly innocent folks stopped cold by something they had 
nothing to do with.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Friday, July 19, 2024 11:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: World’s largest computer outage!

The impact is larger than just Microsoft's cloud. The cloudstrike update is 
causing crashes in Windows PCs and servers. For some it causes the PC to be 
unbootable.

(It crashed my PC but it was able to restart)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Dave Beagle
Sent: Friday, July 19, 2024 10:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: World’s largest computer outing!

lol spell check but thanks for correcting a 2nd grade word.



Dave B.

إسرائيل قتلت 40 ألف فلسطيني بريء


On Friday, July 19, 2024, 10:32 AM, Phil Smith III  wrote:

*outage not *outing

The real question is how many (OK, how FEW) CxOs are going to look at this and 
say "Gee, SPOF, eggs in one basket, *not under our control*, is this cloudy 
thingy really such a great idea?"

-Original Message-
> On 7/19/24 at 9:38 AM, Dave Beagle wrote:
>
>> Microsoft via a Crowdstrike security update is experiencing the largest 
>> outage in world history. Long live the mainframe.

--
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: [EXTERNAL] Re: [IBM-MAIN] Connect:Direct

[Phil Smith III]

Yes. See https://en.wikipedia.org/wiki/Connect:Direct for a pretty accurate 
timeline.

I was in Sterling VMD 1997-2000 (through the CA acquisition), which was in the 
same building as NMD (the NDM/Connect:Direct folks), despite being nominally 
separate companies by then. I never dug into the dichotomy at all, but do 
remember calling my wife on Valentine's Day 2000 to tell her we'd just been 
bought by CA. Her response: "It's Valentine's Day, not April Fools". Alas, it 
was both.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Dean Kent
Sent: Friday, July 19, 2024 9:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: [IBM-MAIN] Connect:Direct

My recollection:

NDM was owned by Sterling Commerce, which sold network products, while Sterling 
Software sold storage management solutions.   In 1993 Sterling 'bought' 
(actually merged with) Systems Center and renamed the product Direct:Connect.   
 In 2000, CA aquired Sterling Software while Sterling Commerce was bought by 
SBC Communications.   Where it went after that, I didn't track (I was in the 
storage management group of CA until 2010).

On 7/18/2024 11:00 AM, Dave Beagle wrote:
> Sterling owned NDM. (Network Data Mover) It was one of the 15 or so products 
> I was responsible for from 2003-2017, it became Connect Direct in 93 & IBM 
> acquired it in 2010. I talked with a number of Sterling people over those 
> years. AFAIK, IBM still owns it but it might be supported by a third party. 
> When IBM bought it, our cost skyrocketed to 100k/year from 20k a year and we 
> decided to drop support and ran it unsupported for years. I wasn’t happy but 
> management always was cost driven.
>
>
>
> Dave B.
>
> إسرائيل قتلت 40 ألف فلسطيني بريء
>
>
> On Thursday, July 18, 2024, 12:30 PM, Radoslaw Skorupka 
> <0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:
>
> To clarify: Nobody said it is no longer IBM-branded product.
> SDSF is part of z/OS, but it is developed by Rocket Software.
> Many other products are also "off-shored" out of IBM to HCL, 21CS, 
> Rocket and maybe other companies. (*)
>
> Regarding Connect:Direct - I don't know it's status.
> IMHO it is somehow internal competitor to MQ MFT, so I don't know 
> whether IBM is willing to enhance it or rather keep it moribound.
>
>
> (*) Side note: JES3 and z/VSE are notable exceptions - those product 
> were somehow "sold" to the companies (Phoenix and 21CS) and now both 
> are marketed and supported be those companies.
> However TWS, SDSF, PCOMM, Fault Analyzer, Omegamon - all of them are 
> marketed and supported by IBM. Including APARs, PTFs, etc.
>

--
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: World’s largest computer outing!

[Phil Smith III]

*outage not *outing

The real question is how many (OK, how FEW) CxOs are going to look at this and 
say "Gee, SPOF, eggs in one basket, *not under our control*, is this cloudy 
thingy really such a great idea?"

-Original Message-
> On 7/19/24 at 9:38 AM, Dave Beagle wrote:
>
>> Microsoft via a Crowdstrike security update is experiencing the largest 
>> outage in world history. Long live the mainframe.

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

Dumb SDSF question

[Phil Smith III]

Poking around in SDSF today, I scrolled all the way to the right and found:

SysLevel 
z/OS 02.04.00 HBB77C0
z/OS 02.04.00 HBB77C0
z/OS 02.04.00 HBB77C0
(etc.)

Why is this listed for each running task? Wild guess: in a SYSPLEX/JESPLEX (and 
no, I don’t understand the difference between those) the levels could vary. Is 
that it? Googling didn’t help me, alas:
sdsf "sysplex"
gets a total of 20 hits. Though one of those:
https://bit.listserv.ibm-main.narkive.com/viUMTwqk/why-does-sdsf-st-only-show-current-jesplex-jobs
certainly suggests that it’s seeing the whole SYSPLEX, which led to my 
conjecture.

TIA

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

Re: Mainframe history - 12 inch floppies?

[Phil Smith III]

Since we're drifting: My dad had many friends in Prague, because he studied 
there in 1947 (and was there when the Communists took over, though he was 
across town). He visited there as often as he could, and at one point in the 
80s got a tour of a data centre. Technology there included paper tape machines, 
only they couldn't get paper tape--so they were using used movie film from the 
Russian movie industry. Pretty weird!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Monday, July 15, 2024 12:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe history - 12 inch floppies?

W dniu 15.07.2024 o 14:35, Paul Gilmartin pisze:
> On Mon, 15 Jul 2024 05:19:52 +, Timothy Sipples wrote:
>> ...
>> Drifting even further afield, ...

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

Re: Connect:Direct

[Phil Smith III]

Mike Schwab wrote:
>https://en.wikipedia.org/wiki/Connect:Direct
>Mid 1980s The Systems Center created by UCC employees.  Determined
>need for high speed data transfer between mainframe OSes, added
>midrange then PCs.
>Merged with VM Systems to form Systems Center Inc.
>Bought by Sterling 1993.
>Sterling Commerce sold to SBC (AT&T) 2001.
>Sold to IBM 2010.

Close. VM Software, Inc., not VM Systems Group, merged with The Systems Center 
to form System Center (singular, no article). And
SterComm went to SBC in 2000, not 2001. CA bought Sterling on Valentine's Day 
2000 (I called my wife, whose response was, "It's
Valentine's Day, not April Fool's"), and SBC bought SterComm at the same time.

VMSI and VMSG were the two main VM vendors, conveniently located about 20 miles 
from each other. I was at VMSG 1986-1997, when they
sold their mainframe products and me to Sterling VMD (the former VMSI). VMSG 
was called Relay Technology by then.

As mainframe folks, you'll appreciate this: when VMSG said they were renaming 
themselves to Relay Technology, we all said "WTF, why
is 'Technology' singular?" Then we went to update screens etc. and realized 
that "Relay Technology" and "VM Systems Group" are the
SAME NUMBER OF CHARACTERS, fit nicely in existing fields, so we stopped 
bitching. And no, management had not thought of that!

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

Re: Mainframe history - 12 inch floppies?

[Phil Smith III]

Radoslaw Skorupka wrote, in part:
>BTW: Privately I am floppy disk entomologist.

So...you deBUG floppies? /s

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

Re: another z/OSMF rant. -- Catch-22 is killing me

[Phil Smith III]

Those are excellent examples of how it MIGHT be just some weaknesses in 
specific sub-implementations for z/OSMF (not sure what to call those; 
"sub-implementations" seems at least workable: "when thing X gets z/OSMF-ized").

The AT-TLS thing isn't z/OSMF's fault per se, but it sure would color one's 
perception of z/OSMF, especially if you hit it early on. And if there are lots 
of those, then it becomes z/OSMF's fault, because "z/OSMF is hard to use". That 
statement would be correct in that case, even if, again, it's not z/OSMF's 
fault per se.

And &deity knows that there were lots of terrible early Windows products (Adobe 
has never corrected theirs)!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Colin Paice
Sent: Friday, July 12, 2024 1:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: another z/OSMF rant. -- Catch-22 is killing me

Going back about 20 years...
I thought ISPF dialog manager and customising was great.
Someone used it to produce a terrible tool.   You had to enter a lot of
data (which it could have queried for).  Having used it once, you could not 
change the configuration.  The end user comments were like "ISPF customising is 
rubbish" meaning the stuff behind ISPF was rubbish.
I've also seen some excellent ISPF tools for customising which were really 
slick.
Used properly z/OSMF could be very useful.
If you use z/OSMF to create AT-TLS definitions - it does not query what you 
already have - you have to enter it all from scratch!  This is not z/OSMF's 
fault.
Colin

On Fri, 12 Jul 2024 at 17:34, Phil Smith III  wrote:

> Well, like a busted clock, Bill isn't wrong *every* time. The thinking 
> is that since Kids Today expect GUIs, having one will make z/OS more 
> attractive/usable for them. That's probably not wrong: y'all use ISPF, 
> right? That's a GUI, such as they were circa 1980. Why do you use it?
> Because it's more productive: it makes stuff easier for you. Same 
> argument will apply to that PFSK who takes over after you and I stroke 
> out in front of our 3270 emulators.
>
> I believe the questions are, as I implied in my earlier post:
>
> 1) Is z/OSMF usable as a GUI--that is, is it sufficiently functional 
> to solve the problem? It *seems* like the answer may be "no". But I 
> admit I have not touched it (I don’t need to--yet).
>
> 2) Is z/OS even GUI-able without major structural changes? DOS really 
> wasn't. As we know, it went from "Here's a shell on top of DOS" to 
> "Here's Windows, with a DOS "command prompt" emulator available". 
> That's a fundamental difference. Does z/OS need that level of change? 
> I suspect so, especially since so much is non-standard 
> nowadays--there's no "All the parmlib stuff is always in SYS1.PARMLIB" 
> the say "All .ini files are in C:\Windows". Heck, that's so ingrained 
> that any of you who ever had a Windows machine with Windows on some 
> drive other than C will recall various products that absolutely would 
> not work...and that's *with* that standardization!
>
> I'd like z/OSMF to be The Answer. I'm just not convinced that the 
> folks driving it understand the challenge or have the resources/vision 
> to meet it. I hope I'm wrong.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Tom Longfellow
> Sent: Friday, July 12, 2024 9:05 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: another z/OSMF rant. -- Catch-22 is killing me
>
> In what way does z/OSMF make zOS more viable?   The new crowd of fresh
> young bucks will have to learn 'something' in order to work with zOS.  
> Why does it have to be an 'abstraction' layer isolating them from the 
> down and dirty details to get a working system.
> Right now, their "viability" tool has me dead in the water.  Unable to do
> my JOB.   Sooner or later someone will notice and it will be another nail
> in the casket of zOS and IBM.
>
> Oh sure, GUIs are cool looking and sexy.  We are finishing up year 25+ of
> a 5 year plan to get off the mainframe.   It was sold to the money men with
> a few prototype panels of how the GUI might work.The only techincal
> detail they were concerned with was "When can we have it". I contend
> that the total costs of the grand networks of interelated servers costs way
> more than the costs on our mainframe.   But, sturdy work horse don't look
> the same as thoroughbreds.  Pretty pictures win the day.
>
> I guess I am not buying into current thinking.   like "If you CAN encrypt,
> you MUST encrypt" , "If it CAN look like Windows, it MUST look li

Re: Mainframe history - 12 inch floppies?

[Phil Smith III]

Some Googling suggests that there really were no 12" floppies. I suspect if you 
grew up with late "hard" floppies, 8" look enormous, are easily mistaken for 
12"!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: Friday, July 12, 2024 8:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe history - 12 inch floppies?

On 7/11/2024 9:00 AM, Radoslaw Skorupka wrote:
> I just found information in some book that IBM mainframes used 12 inch 
> floppy diskettes. Late 70's.
>
> Anybody heard about such diskettes?


When I first set foot in an IBM-mainframe computer room, the CPU and 
peripherals used 8"floppy diskettes for loading the internal code.

I never saw a 12" floppy diskette used.


-- 

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

Re: another z/OSMF rant. -- Catch-22 is killing me

[Phil Smith III]

Well, like a busted clock, Bill isn't wrong *every* time. The thinking is that 
since Kids Today expect GUIs, having one will make z/OS more attractive/usable 
for them. That's probably not wrong: y'all use ISPF, right? That's a GUI, such 
as they were circa 1980. Why do you use it? Because it's more productive: it 
makes stuff easier for you. Same argument will apply to that PFSK who takes 
over after you and I stroke out in front of our 3270 emulators.

I believe the questions are, as I implied in my earlier post:

1) Is z/OSMF usable as a GUI--that is, is it sufficiently functional to solve 
the problem? It *seems* like the answer may be "no". But I admit I have not 
touched it (I don’t need to--yet).

2) Is z/OS even GUI-able without major structural changes? DOS really wasn't. 
As we know, it went from "Here's a shell on top of DOS" to "Here's Windows, 
with a DOS "command prompt" emulator available". That's a fundamental 
difference. Does z/OS need that level of change? I suspect so, especially since 
so much is non-standard nowadays--there's no "All the parmlib stuff is always 
in SYS1.PARMLIB" the say "All .ini files are in C:\Windows". Heck, that's so 
ingrained that any of you who ever had a Windows machine with Windows on some 
drive other than C will recall various products that absolutely would not 
work...and that's *with* that standardization!

I'd like z/OSMF to be The Answer. I'm just not convinced that the folks driving 
it understand the challenge or have the resources/vision to meet it. I hope I'm 
wrong.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Longfellow
Sent: Friday, July 12, 2024 9:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: another z/OSMF rant. -- Catch-22 is killing me

In what way does z/OSMF make zOS more viable?   The new crowd of fresh young 
bucks will have to learn 'something' in order to work with zOS.  Why does it 
have to be an 'abstraction' layer isolating them from the down and dirty 
details to get a working system.
Right now, their "viability" tool has me dead in the water.  Unable to do my 
JOB.   Sooner or later someone will notice and it will be another nail in the 
casket of zOS and IBM.

Oh sure, GUIs are cool looking and sexy.  We are finishing up year 25+ of a 5 
year plan to get off the mainframe.   It was sold to the money men with a few 
prototype panels of how the GUI might work.The only techincal detail they 
were concerned with was "When can we have it". I contend that the total 
costs of the grand networks of interelated servers costs way more than the 
costs on our mainframe.   But, sturdy work horse don't look the same as 
thoroughbreds.  Pretty pictures win the day.

I guess I am not buying into current thinking.   like "If you CAN encrypt, you 
MUST encrypt" , "If it CAN look like Windows, it MUST look like Windows"

--
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: another z/OSMF rant. -- Catch-22 is killing me

[Phil Smith III]

Things I Wish I'd Said dept:
"A GUI is like a joke: If you have to explain it, it isn't very good."

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

Re: Off topic discussions

[Phil Smith III]

Well, I lose: it didn't strip my sig and looking at current LISTSERV doc, I 
don't see an option to do so. O well.

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

Re: Off topic discussions

[Phil Smith III]

I'd be surprised if a current version of LISTSERV didn't remove them 
automatically, or at least have an option to do so--when properly formatted. 
OTOH, how many folks here besides him and me knew about that convention? I fear 
it's one that's sorta died since Usenet died. Which is a shame.

Wait, convention isn't CRLF SP, it's HYPHEN HYPHEN SPACE

Shmuel, I see the two hyphens but not the space in yours. Did it get stripped 
by your client? Or LISTSERV? Might make sure it's really still there...
-- 
...phsiii

(note sig in above as a test to see whether a properly formatted one DOES get 
stripped)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pew, Curtis G
Sent: Wednesday, July 10, 2024 12:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Off topic discussions

On Jul 10, 2024, at 11:43 AM, Seymour J Metz  wrote:

Is an automatically added signature, preceded by the standard CRLF SP sig 
delimiter, considered part of the discussion.

I would say “no”. I’m happy to ignore potentially offensive text in a signature.


I really miss my old e-mail software, where I could define different automatic 
signatures for different recipients.

Since very few email clients support this, I think it would be creating an 
unnecessary burden to expect people to alter their signatures just to post here.

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





--
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: another z/OSMF rant. -- Catch-22 is killing me

[Phil Smith III]

This is exactly the problem Windows had in the early days: it's all well and 
good until you fall off the edge, out of the GUI envelope, and then all is 
lost. That doesn't make it necessarily a bad idea--I hear Windows has a *few* 
users--but it does mean that you need to be very, Very, VERY serious about 
developing the GUI *and* forcing applications to do the same. Good luck with 
the latter on z/OS.


ObAnecdote: Back in the mid-90s, the Relay/Gold terminal emulation product had 
a Windows version that was built on the core of the DOS version. It worked 
great, was Windows-ized--except for one error screen that came up when some 
sort of SDLC thing failed: it fell into DOS-land, and the only solution was to 
hit ENTER to continue. Since this was being used to automate a process for an 
insurance company, it was A Big Problem. Fixing it in the code was non-trivial; 
best solution I could come up with was a phone-enabled powerstrip* such that 
when it failed, someone could make a call and power-cycle the rack. They didn't 
much like that solution (neither did I, but it was better than nothing). Oddly, 
I forget how it was finally solved, given how long it went on and the number of 
site visits I made trying to deal with it. Maybe they changed to not use SDLC.

*My "drinking bird that hits Enter every few seconds" was also vetoed as 
impractical

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Longfellow
Sent: Monday, July 8, 2024 11:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: another z/OSMF rant. -- Catch-22 is killing me

The store is much longer than this post could cover.  I will keep it as brief 
as possible in an attempt to keep my blood pressure under control.

1.  Product install is STRONGLY recommending using z/OSMF Softtware Management 
to install.
2. I obey and get everything downloaded and start the installation workflow,.
3.  It's time to submit the jobs that actually do the work of building the SMP 
and product runlibes   
4.  z/OSMF fails to submit any jobs with a complaint about SSL...
5.  IBM support says the problem is a flaw in the JAVA that I installed last 
September (using z/OSMF of all things) 
6.  "old fashined" batch JCL was used to download that fix and all of his 
associated follow on maintenance (RSU2406).
7.  RSU2406 applied and system IPLed to get a fresh new start.
=  Now the Catch-22  == 
+ z/OSFMF will not respond to its designated IP HTTPS port.   It is not even 
listening on that port.
+ Therefore I cannot even login to use the Diagnostic Assistant or even attempt 
to complete my insall.

CATCH-22:   You NEED z/OSMF to DEBUG z/OSMF.
===
Latest from IBM --- we think the z/OSMF error is related to this WLM error we 
see in the log.
Now the problem expands to another support team.
In the meantime I am out here hanging - unable to perform my job.


I have always said that GUIs are OK when they help.   But SOMEONE still has to 
know what to do to fix it when it's broke WITHOUT using the thing that just 
broke.
I contend that z/OSMF now needlessly surpasses the complexity and obscurity of 
the z/OS 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

Re: What's at a comma?

[Phil Smith III]

Ah, ok, thanks. Makes sense. So in previous versions, what was there? Doesn't 
matter, just curious. Looked kinda like a PSW, not necessarily.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter Relson
Sent: Thursday, July 4, 2024 8:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What's at a comma?

Phil S wrote:

IPL PSW: The first eight bytes read during a CCW-type initial-program-loading 
(IPL) initial read operation are stored at locations 0-7.
...
That's what I was talking about re the IPL PSW.


That is, of course, true. My point was that that information is not in the 
"PSA" that is available to programs.
It was at absolute locations 0-7 (not subject to prefixing because that is not 
active at the IPL itself).
The IPL root program ends up after that in the same page (and what follows).

But that is gone by the time the IPL proceeds much further.

Prior to z-Architecture, locations 0-7 were the restart old PSW, generally 0's 
until a restart had been done (if ever).

Peter Relson
z/OS Core Technology Design


--
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: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News

[Phil Smith III]

Without starting/escalating a war here, may I ask about this:
>ooRexx would be a terrible language for automation because automation
>loses control of storage management. Those oop features come at a
>cost. If your product isn't essential then ooRexx is fine but can be a
>huge problem for system critical products.

I don't understand "because automation loses control of storage management". 
Can you elaborate?

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

Re: What's at a comma?

[Phil Smith III]

Peter Relson wrote:
>The code is checking 7 bytes at location x'6B' through x'71'.
>As of z/OS 2.5 that area is all zeroes.

>Prior to z/OS 2.5 for any z/Architecture IPL it is not. The same is
>true for location 0 and others.

>Since none of them are programming interfaces (such that changing the
>value is not something we would feel a need to disclose), I doubt that
>anyone at IBM would try to list them for you. But if you have access
>to both a release before 2.5 and a release 2.5 or later, you could
>probably figure it out with not much difficulty.

>Someone asked about "IPL PSW". These 7 bytes have nothing to do with
>any IPL PSW. And the PSW's used for IPL are not preserved in low
>storage for later viewing.

That was me, Peter. And I know you grok this far better than I do, so I'm not 
arguing, just trying to understand. I see this in the PofOp:

Assigned Storage Locations in the z/Architecture Architectural Mode

0-7 . . . . . . . . . . . . . . . . . . . . . . . . Absolute Address

IPL PSW: The first eight bytes read during a CCW-type initial-program-loading 
(IPL) initial read operation are stored at locations 0-7.


That's what I was talking about re the IPL PSW.

Thanks,
...phsiii

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

Re: What's at a comma?

[Phil Smith III]

Ah, thanks. That solves this mystery!

But I'd ask: Why zeroes? That seems to be asking for problems like this. I'd 
have chosen DEADBEEF or  or 12345678: more likely to be useful if 
something is misbehaving.

Not too late to change that, actually...

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: Wednesday, July 3, 2024 9:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What's at a comma?

On 7/2/2024 3:20 PM, Phil Smith III wrote:
> It would indeed. But I'm astonished that the IPL PSW is zeroes?! Perhaps some 
> IBMer can explain that. And maybe someone else on 2.5 can run the snippet?

I covered this in a "Bit Bucket" at SHARE right after z/OS V2R5 first came out 
4+ years ago.

Since they are no longer used, all of the old ESA/390 8-byte PSWs in the PSA 
were set to zeros starting in z/OS V2R5.

General cleanup...

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

Re: What's at a comma?

[Phil Smith III]

Schmitt, Michael wrote:
>The REXX code displays:

>
>

>Which would explain why it isn't branching.

>We were on z/OS 2.4 before.

It would indeed. But I'm astonished that the IPL PSW is zeroes?! Perhaps some 
IBMer can explain that. And maybe someone else on 2.5 can run the snippet?

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

Re: What's at a comma?

[Phil Smith III]

I don't think "breaks this code" is fair. More like "This code is now equally 
broken but no longer randomly 'works' quite as often".

In any case, x'6B' is in the middle of:
FLCER018 DSCL104 FLCE 18x: reserved
...which starts at location x'18'.

On my 2.4 system, that's all zeroes. Location 0 sure isn't all zeroes; it is, 
of course, the IPL PSW.

/* REXX */say c2x(storage(x2d(00), 8)); say c2x(storage(x2d(6b), 8))
displays both. I'd be astonished if those were ever the same. Unless there's 
some prefixing majick getting in here. What do you see when you run that Rexx 
snippet?

And what z/OS version did you come from?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Tuesday, July 2, 2024 5:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: What's at a comma?

Today I learned that z/OS 2.5 upgrade breaks this code:

 CLC   0(R7),ECOMMAIS THIS A COMMA
 BNE   PD07240 IF NOT, BRANCH
  :
ECOMMA   EQU   X'6B'   COMMA (,)

Which has worked since 1985.

Yes, I know that this is incorrect code. It worked because the input never has 
a comma there. The "correct" result is to branch. Now it doesn't.


(spoilers ahead if you want to figure out what's wrong for yourself...)


So what's wrong is they meant to code CLI. But they didn't, so this assembles 
as if it were:

 CLC   0(7,0),107(0)

But 0 isn't a base register, so it is comparing the 7 bytes at address x'0' to 
what's at address x'6B'. Right?

My question is: what is at those two addresses? Whatever it is, it must have 
never been the same before, but now it is always the same.

(Unless there's some z/OS 2.5 thing where storage reads at low core behave 
differently)




--
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: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News

[Phil Smith III]

"roooRexx" -- ruh roh, Scooby Dooo!

(sorry, couldn't resist)
-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Tuesday, July 2, 2024 1:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you! 
(Re: z/OS 3.1 Enhancements & Support News

On Tue, 2 Jul 2024 17:14:45 +, Seymour J Metz  wrote:

>> Conscientious documentation of Rexx avoid the word "default" in this 
>> context for two reasons:
>> `1. The expression is assigned to the stem with every
>>possible tail, not to only those not previously given
>>a value.
>
>Not so; ooRexx is not SAA rex. The ooRexx documentation uses the word default 
>because it *is* appropriate in the context of ooRexx.
>
In what sense is it appropriate to SSA Rexx but nor roooRexx?

>> 2. If an individual member of the compound is DRO ped,
>>its value returns to the standard UPPER(stem.tail), not
>>   the value assigned earlier to the stem.
>
>That's because DROP does not set a compound variable to the default value of 
>the stem.
>
>The test below is from OREXX rather than ooRexx, but the results should be the 
>same.
>
>  Go on - try a few... Enter 'exit' to end.
>foo.=bar
>
In SAA Rexx that assigns BAR to compound variables with stem FOO. and every 
possible tail; no default is affected.
How is it different in ooRexx?

>   REXXTRY.CMD on OS/2 
>drop foo.baz
>   REXXTRY.CMD on OS/2 
>say foo.baz FOO.BAZ
>
That is the default value in SAA Rexx.

>   REXXTRY.CMD on OS/2 
>say foo.foo BAR
>
That is not a default value.  It was explicitly assigned by "foo.=bar".  Is it 
different in ooRexx?

--
gil

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

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

Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News

[Phil Smith III]

ler numbers of targets than if all were in a single
   pool.
   - EXECIO 1 is a dog.
   - Algorithm efficiency matters, more so in REXX than in other
   languages.  A recursive Fibonacci function of 100 might take hours or days
   depending on the platform.  If you save intermediate results in a global
   stem, Fib(100) takes seconds or less, only slightly longer than the loop
   method.
   - Typing and sizing are non-issues in REXX.  How often has a compiled
   language program needed to be updated because a field length changed or a
   table overflowed?  Whatever you do in any other procedural language can be
   done more easily and with less down the line maintenance in REXX.

I could go on.

OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands with 
more than a dozen filters, while Pipelines specifications are commonly over 
100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Mon, Jul 1, 2024 at 1:58 PM Seymour J Metz  wrote:

> probably means here files; inline with the source code.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
> 
> From: IBM Mainframe Discussion List  on 
> behalf of Phil Smith III 
> Sent: Monday, July 1, 2024 2:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Rexx is quite cool, flexible, powerful, feature-rich, 
> thank you! (Re: z/OS 3.1 Enhancements & Support News
>
> Paul Gilmartin wrote:
> >Lack of closure: I don't believe a function package, much less a 
> >command environment can be coded in REXX. those must be coded in 
> >another language, therefore less portable.
>
> Well, that's a good point. OORexx makes that somewhat better, but not 
> like P/P. But I could imagine writing an interface to enable this. The 
> tricky part with Classic Rexx would be variable passing, but Pipes 
> demonstrates that it's quite doable. I think it'd be easier with OORexx, no?
>
> >I've written some utility packages which I concatenate with SYSIN, 
> >REPRO to a temporary member, and execute that.
> >Ugh!
>
> You mean so you have your program + "standard" functions, glue 'em 
> together, and thus the standard functions are local and can access 
> variables easily? Cool. Can't quite imagine doing that on CMS!
>
> >Lack of support for instream data.
>
> Not sure what you mean here--is it that it's not native/trivial to 
> read from a DD * in Rexx?
>
> >Lack of elementary functions, made a challenge by the desire to 
> >support arbitrary precision.  (Can a function package, in whatever 
> >language determine the caller's NUMERIC settings at the instant of 
> >call?)
>
> No, though I've never wanted that. Not saying it's not a valid
> requirement: had the Rexx ecosystem developed more, stuff like this 
> would have become necessary and presumably been enabled.
>
> This is a fun discussion.
>
> --
> 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: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News

[Phil Smith III]

Paul Gilmartin wrote:
>Lack of closure: I don't believe a function package, much less a
>command environment can be coded in REXX. those must be coded in
>another language, therefore less portable.

Well, that's a good point. OORexx makes that somewhat better, but not like P/P. 
But I could imagine writing an interface to enable this. The tricky part with 
Classic Rexx would be variable passing, but Pipes demonstrates that it's quite 
doable. I think it'd be easier with OORexx, no?

>I've written some utility packages which I concatenate with
>SYSIN, REPRO to a temporary member, and execute that.
>Ugh!

You mean so you have your program + "standard" functions, glue 'em together, 
and thus the standard functions are local and can access variables easily? 
Cool. Can't quite imagine doing that on CMS!

>Lack of support for instream data.

Not sure what you mean here--is it that it's not native/trivial to read from a 
DD * in Rexx?

>Lack of elementary functions, made a challenge by the
>desire to support arbitrary precision.  (Can a function
>package, in whatever language determine the caller's
>NUMERIC settings at the instant of call?)

No, though I've never wanted that. Not saying it's not a valid requirement: had 
the Rexx ecosystem developed more, stuff like this would have become necessary 
and presumably been enabled.

This is a fun discussion.

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

Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News

[Phil Smith III]

I've long maintained that Rexx's (arguable) failure (I'm a huge fan, so I 
resist that term, but the popularity of first Perl and now Python kind of make 
it true) is due to two things:

1) It's IBM and too many folks therefore concluded it must be bad.
2) There were few decent/public examples of how to write function packages for 
it. I did so on CMS a few times, and it wasn't as easy as one might like; and 
they seem rare to nonexistent on z/OS (yes, yes, I know y'all are about to cite 
a bunch of examples, but relatively speaking, they seem rare). RXIUCV, 
RXSOCKETS, RXLDEV on CMS were popular, but CPAN and whatever the Python 
equivalent are beat Rexx by orders of magnitude.

Revisionist history is always easy, but: if IBM had at least made it easier 
and/or just provided some simple examples of function packages, maybe we'd be 
having a different conversation now...though I still doubt it, since IBM never 
tried to make it open source or even promoted it on non-IBM platforms. I guess 
that last might should be in the list above as #3.

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

Re: As a long-time Rexx programmer

[Phil Smith III]

Ok, I guess that makes sense. Though I might argue that whoever wrote the Rexx 
support should understand Rexx, to get it right...

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Monday, July 1, 2024 10:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: As a long-time Rexx programmer

On Thu, 13 Jun 2024 14:40:05 -0400, Phil Smith III  wrote:

>...am I the only one who SMH at the documentation for things like 
>ISFEXEC  
>(https://www.ibm.com/docs/en/zos/2.4.0?topic=language-issuing-commands-isfexec 
>)?
> It reads like it was written by someone who doesn't quite understand how 
> variables/literals work in Rexx:

Why would anyone expect SDSF support & dev to know REXX when it's not part of 
their job? REXX documentation belongs with REXX and in the case of quoting, 
it's only mentioned because SDSF support received multiple calls caused by 
special characters. Since most people go directly to the examples, it doesn't 
surprise me this has never been corrected.

--
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 Enhancements & Support News

[Phil Smith III]

*you're. I'm tired.

-Original Message-----
From: Phil Smith III 
Sent: Saturday, June 29, 2024 10:48 PM
To: 'IBM Mainframe Discussion List' 
Subject: RE: z/OS 3.1 Enhancements & Support News

Ed,
I'm honestly unsure what point your making here. That sounds pissy and I don't 
mean it to be--just honestly confused?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
EDWARD GOULD
Sent: Saturday, June 29, 2024 7:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 3.1 Enhancements & Support News

I distinctly remember (I think I was on the TSO committee at Share) When Rexx 
was announced. We were looking at ordering tSO/E at the 
time and I asked the boss to put the breaks on ordering TSO/e until GA and then 
wait 2 months. IIRC it was the early 80's. I also 
remember there were quite a few big prereqs as there were a lot of bugs early 
in REXX. My memory is not 100 percent here but it isn't 
far off.

--
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 Enhancements & Support News

[Phil Smith III]

Ed,
I'm honestly unsure what point your making here. That sounds pissy and I don't 
mean it to be--just honestly confused?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
EDWARD GOULD
Sent: Saturday, June 29, 2024 7:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 3.1 Enhancements & Support News

I distinctly remember (I think I was on the TSO committee at Share) When Rexx 
was announced. We were looking at ordering tSO/E at the 
time and I asked the boss to put the breaks on ordering TSO/e until GA and then 
wait 2 months. IIRC it was the early 80's. I also 
remember there were quite a few big prereqs as there were a lot of bugs early 
in REXX. My memory is not 100 percent here but it isn't 
far off.

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

Re: Using environment variables in JCL and USS

[Phil Smith III]

SWAG but have you tried a trailing semicolon? Or quotes around the value? I 
found an example on the web for another product:
ENVAR C='X Y'
...which sorta suggests that the quotes might work. Might try both flavors of 
quote, too.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Colin Paice
Sent: Tuesday, June 25, 2024 1:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Using environment variables in JCL and USS

I am writing a program using system SSL (GSK*).
If I define the environment variables in USS everything works.
If I specified the environment variables in JCL
//START1   EXEC PGM=GSKMAIN,REGION=0M,
// PARM=('ENVAR("_CEE_ENVFILE=DD:STDENV")/4000')
//STDENV  DD *
GSK_TRACE_FILE=/tmp/zzztrace.file
GSK_TRACE=0xff
GSK_KEYRING_FILE=START1/TN3270
/*
environment variables like GSK_KEYRING_FILE are padded on the right with
blanks.  it cannot find the keyring TN3270__   and gives me a trace
file with blanks on the end!

I guess this is a GSK bug - it should strip trailing blanks, but I wondered if 
there was a JCL solution for this?

Colin

--
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: gsk and ICSF

[Phil Smith III]

Atila Fogarasi wrote:
>Perhaps the cause is the obvious: RACDCERT has some options which
>require ICSF. For example a certificate that is migrated from one RACF
>system to another will have PKDS. So fairly easy to wind up using ICSF
>unexpectedly.

You nailed it. Once I used a RACF certificate instead of a gskkyman database, I 
got the failure as well, exactly the same as the customer's. Interesting that 
it doesn't say anything about being unable to get the certificate. But I did 
find this in the output:

zSSLdoHTTP line:2179 stat:   1 rc: 455 tag: GSK_SECURE_SOCKET_INIT
SSL specific error:  ICSF services are not available
zSSLdoHTTP line: 874 stat:   1 rc:   1 tag: connectToServer
zSSLdoHTTP line:1050 stat: 572 rc:  -1 tag: done

I hadn't seen this before because for some reason that output (which *is* from 
our product!) is going to a different data set, and I was looking at the main 
one. My bad. But customer sent the entire thing from SPOOL and now that I know 
what to look for, I see it in hers. And I'll figure out why this output is 
separate and fix that.

-Original Message-
From: Phil Smith III  
Sent: Friday, June 21, 2024 6:12 PM
To: 'ibmtc...@vm.marist.edu' ; 'IBM Mainframe 
Discussion List' 
Subject: gsk and ICSF

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

Had an odd one this morning: a customer who was doing some testing could not 
connect to our server (on premises at their site) from z/OS (server is an x86 
Linux machine). I saw the email when I woke up and thought "OK, gsktrace to the 
rescue!"

But by the time I got to my desk, I had more email saying "Nevermind, ICSF 
wasn't running--once we started it, all is fine". And now that's working, they 
can't break it again to run with gsktrace.

Meanwhile, I can connect just fine without ICSF running. Of course, that's to 
one of OUR versions of the same server, using one of OUR certificates. Wild 
guess is that the customer's cert is using some certificate feature that 
requires ICSF interpretation, but I had them send me both the root and the 
leaf, and various online cert analyzers don't show anything obvious.

Anyone know of any certificate features that absolutely require ICSF 
intervention? Our product uses GSK directly -- no AT-TLS or anything like that.

I realize this is vague but hoping someone (maybe at IBM?) has a guess...

Thanks,
...phsiii

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

gsk and ICSF

[Phil Smith III]

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

Had an odd one this morning: a customer who was doing some testing could not 
connect to our server (on premises at their site) from z/OS (server is an x86 
Linux machine). I saw the email when I woke up and thought "OK, gsktrace to the 
rescue!"

But by the time I got to my desk, I had more email saying "Nevermind, ICSF 
wasn't running--once we started it, all is fine". And now that's working, they 
can't break it again to run with gsktrace.

Meanwhile, I can connect just fine without ICSF running. Of course, that's to 
one of OUR versions of the same server, using one of OUR certificates. Wild 
guess is that the customer's cert is using some certificate feature that 
requires ICSF interpretation, but I had them send me both the root and the 
leaf, and various online cert analyzers don't show anything obvious.

Anyone know of any certificate features that absolutely require ICSF 
intervention? Our product uses GSK directly -- no AT-TLS or anything like that.

I realize this is vague but hoping someone (maybe at IBM?) has a guess...

Thanks,
...phsiii

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

Re: As a long-time Rexx programmer

[Phil Smith III]

"If the command contains special characters or blanks, enclose it in single 
quotation marks."

Might not be the best example, but it's clear from the doc that whoever wrote 
it doesn't understand that unassigned Rexx variables return their literal 
values.

Point is, if this is an SDSF special thing, then that isn't clear. If it's 
referring to "Hey, if you want to pass something like
xyz;abc
then you need to either have that in a variable and specify the variable OR put 
it in quotes because that's how Rexx works", then that's different. (And is 
what is pretty clear from some other places in the doc, though perhaps not this 
specific case.)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Friday, June 14, 2024 4:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: As a long-time Rexx programmer

Ok I will bite.

Please point out what parts of that extract are "grim" and "embarrassing".

Rob Scott
Rocket Software

Get Outlook for Android<https://aka.ms/AAb9ysg> 
From: IBM Mainframe Discussion List  on behalf of 
Lionel B. Dyck <057b0ee5a853-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, June 13, 2024 8:43:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: As a long-time Rexx programmer

EXTERNAL EMAIL




Just be glad we do have a REXX API to invoke SDSF 😊


Lionel B. Dyck <><
Github: https://github.com/lbdyck<https://github.com/lbdyck>
System Z Enthusiasts Discord: https://discord.gg/sze<https://discord.gg/sze>

“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 
Phil Smith III
Sent: Thursday, June 13, 2024 1:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: As a long-time Rexx programmer

...am I the only one who SMH at the documentation for things like ISFEXEC 
(https://www.ibm.com/docs/en/zos/2.4.0?topic=language-issuing-commands-isfexec<https://www.ibm.com/docs/en/zos/2.4.0?topic=language-issuing-commands-isfexec>)?
 It reads like it was written by someone who doesn't quite understand how 
variables/literals work in Rexx:
--
You issue commands with the ISFEXEC host command as follows:
Address SDSF
"ISFEXEC sdsf-command (options)"
sdsf-command
is a supported SDSF command, including any parameters. If the command contains 
special characters or blanks, enclose it in single quotation marks.
--
The rest of the doc seems to be similar. If only IBM had some Rexx 
experience.oh, wait.

Yes, I'm being snide, but this is just grim. And embarrassing. I realize 
unlikely to be fixed at this late date, of course.

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

As a long-time Rexx programmer

[Phil Smith III]

...am I the only one who SMH at the documentation for things like ISFEXEC 
(https://www.ibm.com/docs/en/zos/2.4.0?topic=language-issuing-commands-isfexec)?
 It reads like it was written by someone who doesn't quite understand how 
variables/literals work in Rexx:
--
You issue commands with the ISFEXEC host command as follows:
Address SDSF
"ISFEXEC sdsf-command (options)"
sdsf-command
is a supported SDSF command, including any parameters. If the command contains 
special characters or blanks, enclose it in single quotation marks.
--
The rest of the doc seems to be similar. If only IBM had some Rexx 
experience.oh, wait.

Yes, I'm being snide, but this is just grim. And embarrassing. I realize 
unlikely to be fixed at this late date, of course.

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

Re: A new way to look at load modules

[Phil Smith III]

Nice. Sounds like CMS MODMAP, kinda.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Sam 
Golob
Sent: Wednesday, June 5, 2024 8:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: A new way to look at load modules

Dear Folks,

 We have a new TSO command called LISTMOD, which allows you to see what is 
in a load module very clearly, INCLUDING ALL DISPLACEMENTS.  I don't believe 
that this kind of tool existed before, or at least (if it did), it wasn't in 
wide circulation.  The tool is on the CBT Tape File 994, (improved version on 
the Updates Page) and it is free.

 This LISTMOD command allows you to display PDSE load modules as well, and 
see the code and displacements.

 This LISTMOD command can be found on File 994 of the Updates page of 
www.cbttape.org .  Use the version of LISTMOD on the UPDATES PAGE only, which 
was greatly improved.

 Invoke LISTMOD by simply saying:   LISTMOD modnamewhere modname is a 
load module name.  If the load module is in LPA, LISTMOD will say so.

 To direct LISTMOD to a particular library (PDS or PDSE) containing the 
load module, allocate that library to the DDNAME of TASKLIB.

 Output of LISTMOD can be very long, so it should be captured by s 
SYSOUTTRAP tool (such tools are included in File 994).

 Some sample output follows:

Loaded Program Name:  DSLIST
-
Module has been LOADED. CDE Address: 008B5128 Length of loaded module Hex:  
00012818Decimal: 75800 Length after entry address :  00012818Decimal: 
75800 Displacement of entry point:  Decimal: 0
-

  00  DSLIST 04/22/24 17.51 Copyright (C) 2021-2022 J. Stephen My

4FF43CEDCEE4FF6FF6FF4FF4FF4C99A9888A44C5464D44EA898894DA
7004E423923004122124017B5103678997830D3D020210202201B02357855048
0---+---+---+---1---+---+---+---2---+---+---+---3---+---+---+---

ers   }   x 8Y   }  &}0 &0} } } 8 } } |0040
89A09ED01CAB0004FE5BB01F4DB05DF05FD052104190D0D0B8D0F7D4D141
59200C0C8F7504008880008D1008000480001002AB010CE57B0C83F0
0---+---+---+---1---+---+---+---2---+---+---+---3---+---+---+---

}   )  } \ %+\} 3  g} o0   \x   )\ M  x0xd xM   0080 
D41050CD4E161F1140004ED4F3B8D49FB81EA7005ECD1EA7001FA800400311AD
00B0D0D0107C8E801003E000377700607A40740AD0D42E740C407409100B9074
0---+---+---+---1---+---+---+---2---+---+---+---3---+---+---+---

   .  6K  c0 + } 3   } o0 a \ 0   00C0
0041101E4EC31F1E1F41CF4FC0D0B8F041D4F1B8D49FB8412040204EB74F02B1
041001BE31C38EAEAEBEB61FCD227300E0003770006071800010021050100CF8
0---+---+---+---1---+---+---+---2---+---+---+---3---+---+---+---

  (many lines follow)

  Best of everything to all of you.

Sincerely, Sam

--
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: Upgrade by cutting a wire?

[Phil Smith III]

I believe ya, but am hoping for a cite.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Friday, May 31, 2024 1:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Upgrade by cutting a wire?

That sort of thing was done in the 1950s.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Rick Troth <058ff5c2d0a7-dmarc-requ...@listserv.ua.edu>
Sent: Friday, May 31, 2024 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Upgrade by cutting a wire?

This kind of thing is so common. Maybe it was majic in the 1980s. But now, 
everything is digital and pre-programmed at the factory.

I have a shiny new Icom IC-7300 transceiver. (That's ham radio talk.) It has a 
general coverage receiver, all modes from like 0 to somewhere past 54MHz. But 
it will only *transmit* on frequencies legal to US radio amateurs ... at the 
time of manufacture.
I'VE BEEN TOLD that there is a diode I can clip or remove that will negate the 
transmit lockout.

Legally, I'm not supposed to transmit on (e.g.) 870KHz broadcast AM, and I'm 
not interested in setting up a pirate station. But hams are into disaster 
preparedness. In a crisis, I might *need* to transmit on radio frequencies that 
I'm not normally authorized for. (Not to mention that I hate the whole nanny 
thing.) So ... yeah ... I might "upgrade by cutting a wire" soonish.

Not mainframe, but kinda related. And your fault for making me think of it. 
*:-)*


-- R; <><


On 5/31/24 9:49 AM, Phil Smith III wrote:
> I remember hearing that some Amdahl 370 clone was upgradable by cutting a 
> wire. Anyone else ever hear this? Can't find a cite on the web.
>
> Just curiosity, no real point to this...! (But it is Friday.)
>
> --
> 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: Upgrade by cutting a wire?

[Phil Smith III]

Heh. In a similar vein, in June 1996 I spent a fun-filled week onsite at a New 
York insurance company overseeing testing of a custom program written by some 
Israeli contractors.

The project used five rented PCs. I get there and start setting up: one of the 
PCs won't connect to the network. It's a 3COM card, so I call 3COM, get their 
support. They have me pull the card, then take a pencil and draw a line between 
two marked points on the card. On reinsertion, it worked!

"Great!" I said. "What did I just do?"
"Changed it from an ISA card to an EISA card."

That was pretty impressive.

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

Upgrade by cutting a wire?

[Phil Smith III]

I remember hearing that some Amdahl 370 clone was upgradable by cutting a wire. 
Anyone else ever hear this? Can't find a cite on the web.

Just curiosity, no real point to this...! (But it is Friday.)

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

Re: EBCDIC/ASCII - FTP

[Phil Smith III]

And just to make you laugh/groan/cry, from a book I read last night (fiction), 
someone commenting on an encoded transmission:
"I'm pretty sure it's eight-bit ASCII, also known as UTF-8"

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Harminc
Sent: Tuesday, May 28, 2024 11:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EBCDIC/ASCII - FTP

On Tue, 28 May 2024 at 09:44, Paul Gilmartin < 
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> [...]
> Should I Imagine that originally EBCDIC had no btackets and two 
> customer cultures improvised, independently?
>

I'm not sure to what extent it was customer cultures vs the infamous multiple 
ways of doing things within IBM. I'd say the two sets of roots are the TN print 
train (for the 1403), and the 3270 character set with its early limitations on 
available character generator memory. Different kinds of customers had 
different requirements for characters even within the  US market, and of course 
Europe had a whole 'nother requirement for accented characters. And we mustn't 
forget that this is all the Data Processing Division (DPD), and in parallel 
there was the Office Products Division doing its own thing.

Increasing the number of characters on a print train slows it down, while the 
3270 has an architected and large set of control characters that eat into the 
available display character space even if there is enough memory in the 
terminal. Solutions to these two issues developed in different and incompatible 
directions.

Tony H.

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

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

Re: VTOCs vs. catalogs

[Phil Smith III]

Well, thanks. This has been interesting, with at least the typical amount of 
thread drift!

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

VTOCs vs. catalogs

[Phil Smith III]

I'm curious whether any of you old-timers can explain why we have both VTOCs 
and catalogs. I'm guessing it comes down to (a) VTOCs
came first and catalogs were added to solve some problem (what?) and/or (b) 
catalogs were added to save some I/O and/or memory, back
when a bit of those mattered. But I'd like to understand. Anyone?


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

Re: [EXTERNAL] Re: JOB card format

[Phil Smith III]

Thanks for the clarification!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Harminc
Sent: Saturday, May 11, 2024 9:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: JOB card format

On Thu, 9 May 2024 at 15:01, Phil Smith III  wrote:

> [...]
>
Since classic timer units are close to microseconds
>
[...]
>

Ah, no. We've been through this one before - the last time here in 2018 as far 
as I can see. A (classic) Timer Unit is about 26 μs, which is the notional tick 
rate of bit 30 of the old S/360 Interval Timer. But this kind of Timer Unit 
continues to be available in some interfaces on z/OS, though the Interval Timer 
is long gone.

Bit 31 of the TOD clock ticks close enough to a one second rate that the high 
half of the clock can be used to count seconds for many human interface 
purposes. Bit 51 of the TOD clock ticks at (exactly) the 1 μs rate, and hence 
bit 63 at 2**-12 μs. According to the PofO this last is called a "clock unit".

Tony H.

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

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

Re: AT-TLS Redbook

[Phil Smith III]

I've said this here before, but it bears repeating: although I'd be the first 
to agree that this sounds stupid/basic, make sure they know NOT to turn it on 
Just Because. We've had two customers who decided it would increase security, 
so they enabled it--for a connection that was already using https. (To be 
precise, it wasn't the customer per se--it was their outsourcer.) The server 
(non-z/OS side) was not amused by the double TLS handshake. Fortunately by the 
second one, I recognized it quickly...

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gorlinsky
Sent: Thursday, May 9, 2024 6:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AT-TLS Redbook

I have a client that in the early stages of planning an AT-TLS installation for 
TLS 1. Is there a Redbook that focuses on AT-TLS?

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

Re: [EXTERNAL] Re: JOB card format

[Phil Smith III]

GMTA!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Thursday, May 9, 2024 2:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: JOB card format

357912 so 5x the 64k limit.
* 60 = 2,1474,720  seconds.
About 1/1000 of a 2GB limit if .001 second units.

On Thu, May 9, 2024 at 12:48 PM Pommier, Rex  wrote:
>
> Subject: [EXTERNAL] Re: JOB card format
>
> On Thu, 9 May 2024 10:44:10 -0500, Steve Beaver  wrote:
>
> >TIME=1440 turns off the timing  -- This depends on whether there is 
> >an exit controlling the use of 1440
> >
> I wonder why the designers didn't choose , the  largest possible 
> 4-digit value, to mean "forever"?  (OTHH, I get cognitive dissonance 
> with products that use
> 0 to mean "unlimited".)
>
> --
> gil
>
> --
>
> Gil et al,
>
> So how did they come up with this one?  From the JCL reference manual:
>
> minutes
> Specifies the maximum number of minutes the step can use the 
> processor. Minutes must be a number from 0 through 357912 (248.55 days).
>
> 357912 minutes?  My brain isn't coming up with a logical explanation for that 
> number.
>
> Rex
>
> --
> The information contained in this message is confidential, protected from 
> disclosure and may be legally privileged. If the reader of this message is 
> not the intended recipient or an employee or agent responsible for delivering 
> this message to the intended recipient, you are hereby notified that any 
> disclosure, distribution, copying, or any action taken or action omitted in 
> reliance on it, is strictly prohibited and may be unlawful. If you have 
> received this communication in error, please notify us immediately by 
> replying to this message and destroy the material in its entirety, whether in 
> electronic or hard copy format. Thank you.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

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

Re: [EXTERNAL] Re: JOB card format

[Phil Smith III]

Rex Pommier wrote, in part:
>So how did they come up with this one?  From the JCL reference manual:

>minutes
>Specifies the maximum number of minutes the step can use the processor. 
>Minutes must be a >number from 0 through 357912 (248.55 days).

>357912 minutes?  My brain isn't coming up with a logical explanation for that 
>number.

Well, obviously in binary it's 0101011101111000 and...ok, not that. BUT I 
did multiply it by 60 and got 21,474,720--which is suspiciously close in digits 
(if not in scale) to 2**31, 2,147,483,648. Since classic timer units are close 
to microseconds, this seems likely to be the source of the limit, no?

...phsiii (feeling slightly smug about having found that, though not 100% 
convinced it's the answer!)

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

Re: JOB card format

[Phil Smith III]

Except that TIME=1440 or TIME=NOLIMIT unintuitively overrides that /*JOBPARM 
value, right? 

Not that I think IBM has the infodev resources to spend, but the amount of 
discussion this generated suggests to me that the doc is insufficient.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, May 9, 2024 1:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JOB card format

לא דובים ולא יער

TIME= on the JOB and EXEC is, was and always will be CPU time. It's the TIME= 
on the /*JOBPARM that is wall clock time.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Hayim Sokolsky <062497e865c9-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, May 9, 2024 11:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JOB card format

In truth, TIME= is “wall time” and not CPU time. How many real-world minutes is 
your job allowed to run before it gets cancelled if it runs over.

As there are 1,440 minutes in a 24 hour day, TIME=1440 turns off the timing.


Hayim


Hayim Sokolsky (he/him/his)
Director, Software Engineering
Rocket Software, USA
E: hsokol...@rocketsoftware.com<mailto:hsokol...@rocketsoftware.com>
W:RocketSoftware.com<https://www.rocketsoftware.com/>

The views I have expressed in this email are my own personal views, and are not 
endorsed or supported by, and do not necessarily express or reflect, the views, 
positions or strategies of my employer.

From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Wednesday, May 8, 2024 20:59
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JOB card format

EXTERNAL EMAIL


Thanks. I knew it would be something like that!

What I wanted to grok in fullness was the TIME= parameter. Page 394 of that PDF 
talks about it, but is vague about what the time value means. I always thought 
it was CPU time, and the doc says things like "number of minutes the step can 
use the processor", though that's an odd way to say "CPU time" IMHO. And then 
it talks about "continuous wait state", which tends not to use much CPU (!). 
Nowhere does it seem to define things in detail. Or maybe the wait state thing 
is just saying (clumsily) that when CPU time is unlimited (via TIME=1440 or 
TIME=NOLIMIT), the other, usually unrelated maximum wait time is also 
overridden to be unlimited?

What led me to this was an STC we have that's generating
$HASP308  ESTIMATED TIME EXCEEDED BY 345 MINUTES yet total CPU used is 
0.02. Some Googling found this APAR:
https://www.ibm.com/support/pages/apar/OA54766<https://www.ibm.com/support/pages/apar/OA54766>
which says "These values represent Wall-Clock time". That totally confuses me, 
and is perhaps just wrong.

This thread: 
https://bit.listserv.ibm-main.narkive.com/IAGR45k7/hasp308-message<https://bit.listserv.ibm-main.narkive.com/IAGR45k7/hasp308-message>
 talks about trying to limit based on wall-clock time and folks aren't saying 
"Sure, that's what TIME= means".

So...which is it? Seems like wall-clock (with or without the Random Capitals) 
makes little sense?!

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Mark 
Jacobs
Sent: Wednesday, May 8, 2024 7:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: JOB card format

Google JCL reference manual. You'll find the documentation there. Or just use 
this link, 
https://www.ibm.com/docs/en/SSLTBW_3.1.0/pdf/ieab600_v3r1.pdf<https://www.ibm.com/docs/en/SSLTBW_3.1.0/pdf/ieab600_v3r1.pdf>

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

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


On Wednesday, May 8th, 2024 at 7:38 PM, Phil Smith III 
mailto:li...@akphs.com>> wrote:

> I just spent far longer Googling than I think I should have NOT finding 
> documentation on the format of a JOB card. Surely this exists.?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu<mailto: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<mailto: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<mailto:lists...@

Re: JOB card format

[Phil Smith III]

Hah, "your shop". We're a dev shop, three people, ADCD. Can't even spell 
"accounting field for JES2", since we don't go near anything where that would 
matter.

Thanks for the info, Shmuel et al. And yes, Gil, they're still card images, 
right?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, May 9, 2024 8:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JOB card format

The generic format is in JCL Reference, but your installation may have imposed 
restrictions on the accounting and programmer name fields. 

Is your shop using the accounting field for JES2? If so, that's also in the JCL 
reference.  Or has IBM dropped that option?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Wednesday, May 8, 2024 7:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JOB card format

I just spent far longer Googling than I think I should have NOT finding 
documentation on the format of a JOB card. Surely this exists.?

--
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: JOB card format

[Phil Smith III]

Thanks. I knew it would be something like that!

What I wanted to grok in fullness was the TIME= parameter. Page 394 of that PDF 
talks about it, but is vague about what the time value means. I always thought 
it was CPU time, and the doc says things like "number of minutes the step can 
use the processor", though that's an odd way to say "CPU time" IMHO. And then 
it talks about "continuous wait state", which tends not to use much CPU (!). 
Nowhere does it seem to define things in detail. Or maybe the wait state thing 
is just saying (clumsily) that when CPU time is unlimited (via TIME=1440 or 
TIME=NOLIMIT), the other, usually unrelated maximum wait time is also 
overridden to be unlimited?

What led me to this was an STC we have that's generating 
$HASP308  ESTIMATED TIME EXCEEDED BY 345 MINUTES
yet total CPU used is 0.02. Some Googling found this APAR:
https://www.ibm.com/support/pages/apar/OA54766
which says "These values represent Wall-Clock time". That totally confuses me, 
and is perhaps just wrong.

This thread: https://bit.listserv.ibm-main.narkive.com/IAGR45k7/hasp308-message 
talks about trying to limit based on wall-clock time and folks aren't saying 
"Sure, that's what TIME= means".

So...which is it? Seems like wall-clock (with or without the Random Capitals) 
makes little sense?!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Wednesday, May 8, 2024 7:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JOB card format

Google JCL reference manual. You'll find the documentation there. Or just use 
this link, https://www.ibm.com/docs/en/SSLTBW_3.1.0/pdf/ieab600_v3r1.pdf

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

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


On Wednesday, May 8th, 2024 at 7:38 PM, Phil Smith III  wrote:

> I just spent far longer Googling than I think I should have NOT finding 
> documentation on the format of a JOB card. Surely this exists.?
> 
> --
> 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

JOB card format

[Phil Smith III]

I just spent far longer Googling than I think I should have NOT finding 
documentation on the format of a JOB card. Surely this exists.?

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

Re: EBCDIC/ASCII - FTP

[Phil Smith III]

Sorry, now I'm confused again--the Bemer page was wrong, and you wanted to 
instead quote some random TSO page that doesn't mention ASCII or EBCDIC?

Not trying to take you to task, I'm honestly lost!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Wednesday, May 8, 2024 2:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EBCDIC/ASCII - FTP

On Wed, 8 May 2024 12:05:26 -0400, Phil Smith III wrote:

>"I have seen this before"--what is "this"?
>
I believe he's referring to my citation of the classic rant:
<https://web.archive.org/web/20180513204153/http://www.bobbemer.com/P-BIT.HTM>

I copied the wrong UR.
<https://www.ibm.com/docs/en/zos/3.1.0?topic=processing-tso-command-environment>

--
gil

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

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

Re: EBCDIC/ASCII - FTP

[Phil Smith III]

Thanks. That wasn't obvious to me because I did not get from that Bemer page 
that IBM had erred in not making the 360 ASCII only--just that had the software 
actually supported ASCII, things would have been different. Better? Maybe; it's 
certainly been that case that a ton of resources have been spent on 
ASCII-EBCDIC issues over the years.

Almost as many as have been spent on linends, or null terminated strings (two 
other items on my time-machine list!)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Wednesday, May 8, 2024 12:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EBCDIC/ASCII - FTP

"This" is the link that Gil provided in the email that I replied to, at the 
bottom of the post. The assertion was that IBM erred in not making the 
System/360 ASCII only.

The availability of multiple EBCDIC code pages seems to me to make Beemer's 
assertion that there is a 1 to 1 correspondence between ASCII and EBCDIC even 
more dubious.

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

Re: EBCDIC/ASCII - FTP

[Phil Smith III]

"I have seen this before"--what is "this"?

I'm curious about your assertion that ASCII/EBCDIC cannot translate cleanly. 
With the right EBCDIC code page, we do this every day. The basic etoa() and 
atoe() work fine, have not caused problems--and we care a lot about specific 
characters, as we support "encrypt in EBCDIC, decrypt in ASCII" and vice versa 
with Format-Preserving Encryption.

It seems clear that if IBM had inflicted (no scare quotes needed) ASCII as the 
native encoding for S/360, there would have been more resistance. OTOH it's not 
clear what realistic choice those customers would have had. There is always the 
"If I have to do a conversion, I will at least look at alternatives", and with 
IBM's fate hanging on the success of S/360, maybe that would have been the 
proverbial straw; we'll never know.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Wednesday, May 8, 2024 11:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EBCDIC/ASCII - FTP

I have seen this before, and I am not persuaded. I find it interesting that all 
of the references provided were written by Mr. Beemer himself, some of them 
with another author.

Perhaps, in hindsight it would have been better if IBM had made the
System/360 an ASCII only machine. But at the time, ASCII was new and relatively 
unknown. As it was, the market had generally rejected ASCII on System/360, so 
the USASCII bit was removed with the introduction of
System/370 in 1970.

Both ASCII and EBCDIC are limited. ASCII, even more so because it is a
7 bit code, though there are proprietary 8 bit extensions. No one knew in 1964 
that Unicode would later be designed based upon ASCII.

The claim that "A 1-to-1 translation between the two [ASCII and EBCDIC] exists" 
is false.Each includes characters that are not defined in the other. This has 
always been the case.

If IBM had "inflicted" ASCII on its customers in 1964, would the
System/360 have had the wide acceptance that it did? We will never know.

According to "Architecture of System/360" 
https://cpb-us-w2.wpmucdn.com/sites.gatech.edu/dist/8/175/files/2015/08/IBM-360.pdf


The reasons against such exclusive adoption was the widespread use of the BCD 
code derived from and easily translated to the IBM card code. To facilitate use 
of both codes, the central processing units are designed with a high degree of 
code independence, with generalized code translation facilities, and with 
program-selectable BCD or ASCII modes for code-dependent instructions. 
Neverthe- less, a choice had to be made for the code-sensitive I/O devices and 
for the programming support, and the solution was to offer both codes, fully 
supported, as a user option.
Systems with either option will, of course, easily read or write I/O media with 
the other code.


Aside from that, it wasn't the "P-bit", but the A bit.

--
Tom Marchant

On Wed, 1 May 2024 11:31:56 -0500, Paul Gilmartin  wrote:

>Seriously!?  After IBM inflicted the burden of EBCDIC on users:
>IT.HTM> it chooses to torment them with the need to learn different 
>conventions for various products?  Consistency would be a boon here.

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

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

Assembler/compiler fun

[Phil Smith III]

See code produced by different compilers. (Search for "s390x" in the "choose 
compiler" box to find the Z compilers)
https://godbolt.org/

What strange hobbies some people have! (I'm including myself there)

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

Re: EBCDIC/ASCII - FTP

[Phil Smith III]

BM wrote, in part:
>On zOS, its EBCDIC file, is there any solution first convert to ASCII then 
>Terse send?

Google is your friend:
"z/os" "convert to ascii"
immediately found lots of discussion, including 
https://bit.listserv.ibm-main.narkive.com/kIFvk8fr/data-conversion-ebcdic-to-ascii
which suggests OCOPY, among other things.

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

Re: Hex error code interpreter?

[Phil Smith III]

Interesting, thanks. In this case, a gsktrace showed that it was failing GCM 
AES in the handshake. A reminder by Charles Mills led me to look at the top of 
the trace, and they had FIPS enabled. GCM and FIPS don't get along.

So while the answers were correct, they actually wouldn't have led me to the 
solution; Charles, however, did!

What we really need is BPXMILLS, I guess...

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Ramsey Hallman
Sent: Sunday, April 28, 2024 5:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Hex error code interpreter?

Colin, MVS/Quickref definitely has the IBM z/OS Cryptographic Services System 
SSL messages. If you have access to Quickref, simply leave the "0x"
off of the message (as the codes are presented within the IBM
documentation) and search for an item of 03353084:

 - V=IBM P=Z/OS CRYPTO SSL MSGS
R=V3R1 I=03353084
 * Text Below Copyright (c) 2024, IBM
*
03353084 ICSF callable service returned an error.



Explanation

Ensure that ICSF is operating correctly and if access to the ICSF callable

services are protected with CSFSERV class profiles that the user ID of the

application has READ access to the profiles protecting the ICSF callable

services. See Table 5 on page 15or Table 6 on page 16 for information about

the required resource profile access. If the problem persists, collect a

System SSL trace and contact your service representative.



User response

Ensure that ICSF is operating correctly and that the user ID of the

application has appropriate access to the CSFSERV class RACF resource

profiles. See Table 5 on page 15 or Table 6 on page 16 for information about 
required resource profile access. Collect a System SSL trace and verify the

ICSF return code and reason code relating to the error. See z/OS Cryptographic 
Services ICSF Application Programmer's Guide for more information about ICSF 
return and reason codes. If the problem persists contact your service

representative.


Ramsey Hallman
MVS/Quickref Support Group

On Sat, Apr 27, 2024 at 7:09 AM Colin Paice < 
059d4daca697-dmarc-requ...@listserv.ua.edu> wrote:

> See gsk_strerror()
> <https://www.ibm.com/docs/en/zos/2.4.0?topic=reference-gsk-strerror>
>
> On Fri, 26 Apr 2024 at 23:16, Phil Smith III  wrote:
>
> > Did I dream it, or is there some utility that can take an error such 
> > as
> > gsk_encrypt_tls13_record(): AES GCM Encryption failed: Error 
> > 0x03353084 and interpret the 0x03353084? I swear I remember seeing 
> > this but can't find it now. Getting old sucks*.
> >
> > *But consider the alternatives.
> >
> > 
> > -- 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: Netview

[Phil Smith III]

Radoslaw Skorupka wrote:
>"vel" is not Polish. We don't have letter "v". It is latin, so I
>supposed it is wide known.
>And yes, it is "aka".
>BTW: WTF is aka??? :-)

Interesting. I believe ya (not gonna argue with someone about their native 
language!) but the usage seems to be Polish, per:
https://en.wiktionary.org/wiki/vel#Polish

For anyone wondering: AKA is a TLA for Also Known As, i.e., vel :-)

("Wait, haven't we done this?" "Oh, yes, sorry!" - Monty Python, though I'm 
damned if I can remember anything else from the sketch
and probably don't have it 100% right)


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

Re: Hex error code interpreter?

[Phil Smith III]

Thanks to all; BPXMTEXT is what I was looking for, though it didn't help in 
this case.

-Original Message-
From: Phil Smith III  
Sent: Friday, April 26, 2024 6:16 PM
To: 'IBM Mainframe Discussion List' ; 
'mvs...@vm.marist.edu' 
Subject: Hex error code interpreter?

Did I dream it, or is there some utility that can take an error such as
gsk_encrypt_tls13_record(): AES GCM Encryption failed: Error 0x03353084 and 
interpret the 0x03353084? I swear I remember seeing this but can't find it now. 
Getting old sucks*.

*But consider the alternatives.

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

Hex error code interpreter?

[Phil Smith III]

Did I dream it, or is there some utility that can take an error such as
gsk_encrypt_tls13_record(): AES GCM Encryption failed: Error 0x03353084
and interpret the 0x03353084? I swear I remember seeing this but can't find it 
now. Getting old sucks*.

*But consider the alternatives.

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

Re: Netview

[Phil Smith III]

For those who are curious like me, "vel" is Polish for "AKA". That was my 
guess, confirmed via Tha Goog.

Not throwing shade at Radoslaw, whose English is better than that of a lot of 
folks on the list who are native speakers!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Friday, April 26, 2024 7:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Netview

It is not so easy.
Do you know IWS vel TWS vel Workload Scheduler?
It is still being sold by IBM, but development is out of IBM.
The same for SDSF (Rocket), PCOMM (HCL), Omegamon, etc. The list is longer.
And it is nothing new IMHO, as far as I remember ESCON Director was also third 
party product under IBM logo.

Note, JES3 and z/VSE are different - in both cases products are supported and 
marketed by their current producers - that means PSI and 21CS.

--
Radoslaw Skorupka
Lodz, Poland



W dniu 26.04.2024 o 07:38, Bruce Hewson pisze:
> Hello Steve,
>
> FUD
>
> "IBM Netview for Z/OS" is still being sold and supported by IBM, and is a 
> pre-req for IBM System Automation and GDPS.  No evidence that this product 
> has been sold.
>
> On Wed, 24 Apr 2024 16:19:17 -0500, Steve Beaver  
> wrote:
>
>> My understanding is that IBM sold off Netview.
>>
>> Who did they sell it to?
>>
>>
>> Sent from my iPhone
>>
>> No one said I could type with one thumb
>>
>
> Regards
> Bruce Hewson
>
> --
> 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: Netview

[Phil Smith III]

Also lots of stuff went to UNICOM, like the Optim products (and more).

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

[Phil Smith III]

More: One of the folks who was having problems writes:
>I gave up on using my pacbell.net email...I switched my Assembler list
>and IBM MAIN list to my .gmail email address and all is well.

I looked, and pacbell.net has no SPF record. Remember, mine started flowing 
once I had enabled SPF, so...maybe? OTOH maybe it's just that whatever 
anti-spam service UA is using doesn't like big ISPs, which always have SOME 
spammers. Gmail is the exception because they do so much with SPF/DKIM/DMARC.

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

Re: grep ascii files...

[Phil Smith III]

Gil asked:
> How do regular expessions play with R-to-L text?

https://stackoverflow.com/questions/50570322/regex-pattern-matching-in-right-to-left-languages

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

[Phil Smith III]

I'm'a try to post this from my lists@ address, because I suspect it will work. 
Longish but (if you're reading it at all) it suggests some progress on the list 
email issue.

To recap, as of a couple of weeks ago:
- I was suddenly not able to post from lists@
- I was still getting the daily digest to lists@
- requests to lists...@listserv.ua.edu from lists@ got no response

This past Friday, my ISP (Cox) moved email to Yahoo. Still used the same 
addresses @cox.net, but with new server names etc., and requiring a 
quasi-enrollment process. That process went OK but I was unable to get Outlook 
to POP mail; webmail worked fine. Cox's typically useless "support" spent 25 
minutes playing 20 questions (name/account number/PIN/etc.) then had forgotten 
the problem. Eventually we got to "You have to contact Yahoo support". Only 
Yahoo has no support except if you pay.

That was the final straw. My mailboxes were at Cox but almost all email (except 
my wife's personal email) was being forwarded to an @akphs.com address anyway. 
I'd been dithering but now it was time, so I moved my mailboxes to my domain 
provider (EasyDNS, btw--good folks). That was a certain amount of hassle, but 
it's done and now email arrives faster, since it's not having to fight its way 
through Cox's outsourced anti-spam, never mind whatever Yahoo does. AND I now 
have DKIM/DMARC set up for the domain: EasyDNS did that for me automatically 
once I moved the mailboxes.

And best of all, requests to lists...@listserv.ua.edu from lists@ are now 
working!

If this post appears, I submit that it strongly supports the previous theory 
that something in the ua.edu infrastructure got pickier about DKIM and that's 
what's been causing the hassles; my added DKIM-ness thus fixed it for me.

Now...what does this mean for others who are having trouble? Well, it would 
mean that your email provider is falling below the threshold of acceptability 
for whatever the heightened DKIM awareness requires. Not sure what you can do 
about that. You might tinker, sending notes to yourself at some other address 
and looking at the headers (also feel free to email me here and I can do the 
same), see if there's anything in the DKIM-added headers that looks 
interesting, but I'm not sure what that would be. I have not grokked DKIM/DMARC 
in detail because I haven't had to (and perhaps now I also don't, heh).

...phsiii

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

Re: IBM key management products

[Phil Smith III]

Charles wrote:
>When I was doing security presentations as part of my job one of the
>"controversies" I ran into was that the supposed percentage of insider
>attacks is all over the place. I used to see 85% in one set of
>statistics and nearly zero in others. I have no independent knowledge.

My point is that most insider attacks are not going to also exploit some 
cross-LPAR weakness: they're going to exploit some access. And if you have 
access, then data set encryption doesn't add any security.

Again, Swiss cheese--it's not zero added value, just IMHO relatively minor. The 
insider attack is both better and worse than the external attack: better 
because they're presumably more quick and opportunistic--insiders would be less 
likely to hammer away at something for months trying to find a way in, I 
expect; worse because they're likely more targeted--the insider has a higher 
probability of knowing where the crown jewels are.

Data set encryption has its place and adds some value. What I resist is the 
all-too-common "We encrypted some data sets, so now we're safe". No, what 
you've done is added a SMALL amount of additional protection. All that data is 
in the clear whenever it's used, and that represents significant risk. If you 
can work with it in its protected state, that risk is dramatically reduced.

>I see it as a real possibility:
>"It's only a sandbox system, so we pretty much give developers
>whatever access they say they need."

Ibid.

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

Re: IBM key management products

[Phil Smith III]

Tony Harminc wrote:
>Yes, storage administrators are a small population, but their
>credentials can be compromised as much as anyone else's, and then
>you're not dealing with rogue storage admins but with criminal (or
>goverment or whatever) actors. And storage admins (or their
>credentials) may well make a better target than those of application
>users because the admins have much broader access to data.

More Swiss cheese. Yes, there's benefit. It's relatively small compared to 
things like format-preserving data protection, however, which let the data be 
in its protected state by default, with only the few use cases that absolutely 
require cleartext access having those permissions.

It's all about outrunning the bear!

...phsiii

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

Re: IBM key management products

[Phil Smith III]

Well that's a good point, Charles. A relatively minor risk, compared to 
external attackers, but I suppose they could come in via the sandbox/test 
system, too.

Definitely a "Swiss cheese attack"!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Friday, April 12, 2024 4:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM key management products

Dataset encryption also guards against the situation in which a sandbox or test 
LPAR (1) has very permissive RACF definitions and (2) inadvertently has shared 
access to production DASD.

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

[Phil Smith III]

Digest showing up is of course a positive step, but not the answer. I've always 
gotten the digests on my lists@akphs address, just (starting recently) couldn't 
post. Now you seem to be able to do both, but can't get a QUERY IBM-MAIN 
response.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Schuster
Sent: Wednesday, April 10, 2024 12:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Not getting IBM-MAIN Email

My digest also automagically showed up today.  Hopefully issue is resolved.

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

[Phil Smith III]

Indeed. I'm thinking that either UA.edu or their provider stepped up their 
filtering. But that's why I'm asking: to see if other folks are in the same 
boat, so at least I'd *know*. So far nothing definitive.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Walt Farrell
Sent: Saturday, April 6, 2024 9:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Posting issues?

On Fri, 5 Apr 2024 15:36:21 -0400, Phil Smith III  wrote:

>Yeah, I have SPF records. 

But, increasingly, it seems to be necessary to have DMARC and DKIM properly 
setup, too. I don't know if that would explain your problem with this mailing 
list, though.

--
Walt

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

[Phil Smith III]

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

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

Posting issues?

[Phil Smith III]

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