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=markjac...@protonmail.com<https://api.protonmail.ch/pks/lookup?op=get=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...@listserv.ua.edu> with the message: 
INFO IBM-M

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

Re: FTP translate table defaults

[Phil Smith III]

Good questions. SITE CHTAG doesn't work. This is an enduring mystery to me.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Friday, April 5, 2024 2:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP translate table defaults

On Fri, 5 Apr 2024 13:32:46 -0400, Phil Smith IIIwrote:
>...
>I don't have a solid answer other than that file tagging seems to matter, so 
>chtag is your friend.
> .
Does the FTP server have such as a SITE CHTAG command?

Will FTP automatically tag a file to the value in SBDATACONN?

--
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: FTP translate table defaults

[Phil Smith III]

Radoslaw asked about default translate tables for FTP. My earlier thread titled 
"FTP problem", here and MVS-OE, seems related.

I don't have a solid answer other than that file tagging seems to matter, so 
chtag is your friend.

Or I've misunderstood the question, of course.

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

Re: FTP problem

[Phil Smith III]

Colin Paice wrote:
>It may be interaction with _BPXK_AUTOCVT environment variable, and
>possibly the FILETAG

Hmm. _BPXK_AUTOCVT is ON; setting it to OFF means that a text file tagged as 
ISO8859-1 now displays as garbage, which makes sense. IBM-1047 and untagged 
files display OK. (It also breaks OS-generated text in my shell prompt, which 
is interesting-but not literals in that same prompt.) But it doesn't seem to 
affect FTP, which makes sense-how would I set it for an FTP session? Or are you 
suggesting setting it for the FTP server? It's not set there unless it's 
defaulting.

FILETAG appears to apply only to C/C++. If you meant the tag on the file, 
that's what my chtag was tinkering with.

I feel like I'm arguing with you, and I don't mean to-I appreciate the thoughts!


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

Re: FTP problem

[Phil Smith III]

Cross-posting this to MVS-OE as a fup to earlier note. TL;DR is that FTPing a 
text file back to Windows was getting binary (unreadable) no matter what I'd 
tried.

 

Sorta figured this out, mostly:

> echo woof > txt

> chtag -p txt

t ISO8859-1   T=on  txt

 

That file transfers fine as *binary*, which  makes sense, since it's apparently 
8859-1 on disk. I have other files:

> chtag -p logs/build.log

- untaggedT=off logs/build.log

.that have to be transferred as ASCII, so apparently they're "native" (EBCDIC, 
presumably 1047) on disk.

 

The remaining mystery is what's making a random file created via echo (or 
various other things) be ISO8859-1 instead of native EBCDIC?!

 

From: Phil Smith III  
Sent: Monday, October 30, 2023 6:13 PM
To: 'ibm-m...@bama.ua.edu' 
Subject: RE: FTP problem

 

Off-list reply pointed out that I meant "z/OS FTP server", not "Windows". 
Braincheck. I fire up Windows FTP client, do GETs. And yes, I was specifying 
ASCII. That's what was so weird: it sometimes said 
125-Tagged ASCII file translated with current data connection translation table
.which is what got me tinkering with chtag. But sometimes it didn't say 
'translated', and the resulting file was STILL borked!

Annotated:
* FTPed file, it was borked. Let's tinker with chtag.
> chtag -p gskinterop.txt
t ISO8859-1   T=on  gskinterop.txt

* Hmm, 8859-1, that's weird. OK, let's untag it
> chtag -r gskinterop.txt

> chtag -p gskinterop.txt
- untaggedT=off gskinterop.txt

* FTPed it again, still borked. Even with explicit ASCII.

* Let's tag it explicitly
> chtag -t -c ibm-1047 gskinterop.txt

> chtag -p gskinterop.txt
t IBM-1047T=on  gskinterop.txt

* Still borked.

I started to think something was going on on the Windows side, so I replaced 
the file contents with a * before retrying the above. No change: the borked 
version was full-size, just not translated, apparently. Yes, when I look at it 
on z/OS it looks fine.

Yes I could use scp but that's not how I normally do this.


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

Re: Rexx numeric digits and scientific notation question

[Phil Smith III]

For me, this prompts discussion over "Is using SIGNAL worse than not 
modularizing the initialization?":

/**/
stuff
signal DoInit
DoneInit:
.

DoInit:
numeric digits 40
.
signal DoneInit

---

Discuss :)


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

Re: BASE64 Decode / EPOCH Conversion Code Samples

[Phil Smith III]

There seems to be confusion about what Base64 (jeez, I keep typing "54" or 
"65"!) encoding is. It's just what it sounds like: an
encoding of characters using a 64-character* alphabet, i.e., six bits at a 
time. Hex '01020304' Base64-encodes to the same set of
8-bit characters whether ASCII or EBCDIC. "abcd" encodes to different 
characters depending on whether the input is EBCDIC or ASCII
because the bytes (and thus the chunks of six bits0 are different.

That means that if you Base64-encode an ASCII string, you can decode it on an 
EBCDIC platform (after translating the characters from
ASCII to EBCDIC) and you get the original string-in ASCII. If you want 
translation, you need to translate before encoding or after
decoding.

So "Is there a bilingual [ASCII/EBCDIC] version of Base64" really doesn't make 
sense.

*Although there are some slight variations. See 
https://en.wikipedia.org/wiki/Base64#Variants_summary_table if you're really 
bored.

For the character geeks out there, there's a Unicode Base32K that's 
normalization safe. That'll really make your head hurt.


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

Re: Question

[Phil Smith III]

Yes, the Serena stuff is part of the divestiture to Rocket.

Request: more extensive Subject: lines than "Question". Makes the list much 
more useful.


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

Re: Program Alias Names

[Phil Smith III]

Quite possibly a stupid/useless suggestion, but: what about SIDEFILE entries? 
It's been 15 years since I remember looking at those. We had a ton of long 
entry point names in ported code, and used SIDEFILE for a while.

We later got around needing SIDEFILE in a super-hackish way: we create a 
"decks" file that contains the object decks all copied together, include that 
member, and it works-finds the long entry point names. I doubt that will help 
you, but it does explain why I'm not using SIDEFILEs any more!

.phsiii


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

Re: DMARC failure in messages from this listserv

[Phil Smith III]

Michael Schmitt wrote, in part:
>Microsoft Exchange has started quarantining too many messages from

>this listserv as "phishing". It is several per day; one day there was 16.

 

My understanding of DMARC is incomplete, but here are some observations.

 

First, one of your examples had a header.from value of COX.NET; the other was 
LISTSERV.UA.EDU. Those are, like, different, and that field identifies the 
DMARC policy domain. Now, why one was COX.NET is a mystery to me. If you have 
the original note, it would be interesting to see the complete headers.

 

My first hypothesis was that because the domains were different, the one note 
failed because it was subject to different policy: when the COX.NET note came 
in, your mail system fetched the Cox DMARC policy and failed the note based on 
that, while it passed based on the UA.EDU (OK, LISTSERV.UA.EDU) policy.  
However, neither of those domains seems to have any DMARC published!  

 

Moving on, I see compauth=fail on the failed note. That field is the "composite 
authentication" result, and is presumably why it really failed. From 
https://www.itpromentor.com/anti-spoof-atp/:

"Composite authentication" or CompAuth for short, is essentially a confidence 
score or rating, which is applied to incoming messages. It takes into account 
the presence of explicit authentication records such as SPF, DKIM and DMARC, 
however, if no such records exist (or if not all of them exist), Microsoft will 
also apply some other intelligence, such as sender reputation, sender/recipient 
history, behavioral analysis, and other advanced techniques which add or 
subtract from the confidence in whether a message has been spoofed or not. 
Therefore, it is a "composite" of both explicit and implicit authentication, 
which determines whether a message is marked as spoofed, ultimately.

 

The way I think about DMARC (and compauth, as part of DMARC) is that it's kinda 
sniffing the note: "Hey, does the alleged sending domain have SPF info? DKIM? 
Do the headers all match?" - it's sort of like Bayesian spam filtering, only 
based on a combination of headers and external information. So it's like you 
judge your daughter's boyfriend based not on what he says (Bayesian content 
filtering) but on how he looks AND what others say about him. When you ask 
around and nobody's heard of him, you have no information-but that's a sort of 
information in and of itself. OK, I've tortured that metaphor enough!

 

I'm surmising that listserv.ua.edu does not have a bad reputation, but cox.net 
does (or at least, a worse one). Which makes sense: while ua.edu has students, 
and we know what THEY'RE like, they're unlikely to be spoofing/sending from 
listserv.ua.edu. But Cox has lots of customers, some of whom are going to be 
spammers. Any ISP has an intermittent reputation problem in terms of spam. And 
ISPs are going to find it hard to turn on DKIM, since they has no control over 
the sending clients (which must put the DKIM signature in the outgoing notes).

 

You also wrote:

>On the other hand, messages I send to the server have mixture of pass

>and fail, and they aren't getting quarantined.

 

"to the server"-to the list? To some other server? Not clear.

 

https://dmarc.org/overview/ is the canonical reference; 
https://datatracker.ietf.org/doc/html/rfc7489 is the primary RFC; and 
https://www.valimail.com/blog/understanding-email-authentication-headers/ seems 
pretty good, too.

 

I think the real key here is understanding where that COX.NET note came from, 
since that's the problem child. Headers from other failures would be 
interesting, too.

 

Are others seeing this problem? I'm not, but my mailboxes are hosted at Cox.


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

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

[Phil Smith III]

Shmuel wrote:
>I was thinking of zCX as hosting containers

>The process for deploying virtual machines in z/VM is different
>although it also eliminates manual setup that used to be necessary.

>i was trying to illustrated that the automation of deployment was not
>limited to the cloud.

Ah! Gotcha. Sure, containers is containers is containers. But given the expense 
of IBM zSystems MIPS, it's hard to envision overprovisioning for possible usage 
spikes the way x86 clusters do.  Yes, there's CoD, which is sort of the 
forerunner to this elastic capacity, but not nearly as automated.

To be clear: I'm unconvinced that cloud elasticity is a particularly useful 
capacity in most serious business use cases. Black Friday (heck, the whole 
holiday season) maybe, but that's moderately predictable, and CoD or just plain 
ol' capacity planning can deal with that.

Similarly, I'm unconvinced that zCX is meaningful other than as a "See, we can 
do stuff like this too". I don't see folks embracing it significantly 
[yet--still relatively early days, obviously). What I've seen is people going 
"Neat!" but then.what?

I do think that the management-by-magazine folks are all aTwitter (or is that 
aX now?) about cloud capabilities because they think they will eliminate the 
need for capacity management and thus save them money. My bet is maybe on the 
first, no on the second. But I have nothing to support that other than my gut 
based on experience. (And I had Thai food for lunch, so gut may be even less 
reliable than usual!)


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

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

[Phil Smith III]

Shmuel asked:
>How do containers in the cloud differ from containers on the
>mainframe? How difficult is it to provision a new z/VM virtual machine
>with contemporary software? ow much is just different coverage in the
>in-flight magazines versus substantive benefits of the cloud?

Just checking: are you considering a z/VM VM (z/VM??) a container? I wouldn't 
argue with that, just checking.

Anyway, it's.different. While z/VM has the "pool" concept, it's not quite the 
same as "just fire up another container". But at not-too-high an altitude, I'd 
say they were very much the same.

Acourse the IBM zSystems MIPS are still more expensive.


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

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

[Phil Smith III]

Dave Beagle wrote:
>Large amounts of data, including AI, will require processing power
>(and security) unlike anything DP has seen. Perfect for the mainframe.
>And, there ARE new mainframe shops.

"processing power"-the mainframe lost that battle long ago.
"security"-there's nothing inherently more secure about IBM zSystems than other 
platforms these days either, alas.

New mainframe shops? As the saying goes, "Pics or it didn't happen". I'd be 
thrilled to learn that these exist!




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

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

[Phil Smith III]

Bob Bridges wrote:
>"...where mainframes' resilience meets the agility of cloud computing."  
>What is the "agility" of the cloud, exactly?

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

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

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

For software vendors, the attraction is that they don't have to build/manage as 
much of the platform as they do when they provide a fully functional server. 
All that really does is move that requirement from the vendor (once) to each 
customer, so it's a win for the vendor and a loss for the customer. That is, 
the customer has to do all the vulnerability scanning, patching, etc., instead 
of having the vendor do the heavy lifting (the wise customer does the scanning 
anyway, but then expects the vendor to provide the updates.) I keep waiting for 
the customer world to figure this out; hasn't happened yet AFAICT. Weird.


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

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

[Phil Smith III]

roscoe5 asked:

>how do you see the future for mainframes?

>Increasing, steady, declining, .

 

[Editorializing ahead!]

As usual, "It depends". There are fewer mainframe shops than there were, but 
more usage. 

 

A simple example: consider payment processors, many (not all) of whom have at 
least some IBM zSystems. Recent consolidation there (multi-billion-dollar 
deals): FIS bought Worldpay; Fiserv bought First Data; Global Payments bought 
Heartland and TSYS. Seven companies are now three. So there's your "fewer 
customers". Meanwhile, of course, transaction volumes at these and other 
committed companies are still growing. So there's your "more usage".

 

What I assume will happen over time is that along with continued consolidation, 
some shops will move off because some bright young spark is convinced it will 
be better. Doesn't mean they're right, but that doesn't mean it won't happen. 
Even when that doesn't happen, various other evolution will chip away at some 
usage when it becomes (or, again, SEEMS to become) wiser to move some 
processing off. And essentially nobody is moving new processing TO the 
mainframe, because reasons.

 

At the same time, while the smarter companies get it and see no reason to move, 
there aren't a significant number of new mainframe shops. A few LinuxONEs, but 
zero new z/OS or z/VM or z/VSE or z/TPF shops. I don't see any way this trend 
will reverse, though by the same token I don't see the mainframe going away 
anytime soon. It will just become more and more of a niche market of large 
systems-sort of strange, "big niche"! The aging of the mainframe community 
isn't help, of course.

 

In some ways it looks (at the right distance) like a return to the early days 
of computing, where big iron shops were few but serious. Of course then it was 
big iron vs. nothing; now it's big iron vs. racks, cloud, etc.

 

Maybe AI will reverse this trend, though I personally don't see it. Like many 
current Internet services, AI usage looks like it will largely comprise two 
things: building the LLM (which is expensive but not real-time and can retry on 
failure, so might as well use cheap MIPS) and then querying/using the LLM 
(which is real-time but not critical, so might as well use cheap MIPS). Plus 
there's been a whole shift from "computers should work" to "computers should 
*mostly* work". When your Google search fails or your Instagram page doesn't 
load, you shrug and try again. When your credit card transaction doesn't go 
through, neither you nor the merchant just shrug. But you're starting to-when 
it's a website and the transaction fails, you scowl but try it again, and if it 
works that time, you forget about it. We're being conditioned to accept 
mediocrity, and AI in its current incarnation doesn't appear to be ready to 
reverse that. It's depressing.

 

Meanwhile, a colleague happened to send me this:
https://www.itpro.com/cloud/cloud-computing/cloud-computing-or-mainframe-why-the-pendulum-might-be-swinging-back-in-the-age-of-hybrid-strategies-and-generative-ai
which is a bit more cheerful, albeit more "the leak is slowing" than "things 
are improving".


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

Re: Where are Unix reason codes over 7371 documented

[Phil Smith III]

Thanks. I got BPXMTEXT working, added to SYSPROC. But first I invoked it the 
hard way, via:
TSO EXEC 'SYS1.SBPXEXEC(BPXMTEXT)' '7663730C'

I was confused: never having seen the output, and not knowing what caused 
7663730C, the output:
TCPIP
JRNetAccessDenied: The user is not permitted to communicate with the specified 
network.

Action: If access to the specified network is required, the user must be 
permitted to the appropriate SAF resource

...made me think I'd invoked the wrong thing. No, stupid, that's what error 
7663730C means!!! Must be a Monday.


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

Re: Where are Unix reason codes over 7371 documented

[Phil Smith III]

Colin Paice wrote:
>tso command bpxmtext  7663730c

I get:
COMMAND BPXMTEXT NOT FOUND
?


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

Re: Encryption and decryption - processor or TCPIP

[Phil Smith III]

Peter wrote:
>Still I am trying to understand encryption and decryption load goes to
>general CP Incase if you don't have CPACF or ICSF ?

Even with CPACF and ICSF, some/most of the encryption load is on the CPU. They 
aren't magic. CPACF is faster, but it's still fundamentally executing Z 
instructions in the millicode.


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

Re: Encryption and decryption - processor or TCPIP

[Phil Smith III]

Peter wrote:
>After implementing ATTLS there is some delay in our CICS transaction but I
>was suspecting if sn absence of crypto processor can overload the general
>processor to cause this delay ?

Define "some delay". Adding AT-TLS means that a TLS handshake is being added to 
the communication. That isn't instantaneous, and means some additional network 
back-and-forth. I'd strongly suspect that it's more just network latency added 
by that than the cost of the encryption itself.

As for CPACF, this tiny Rexx program will tell you if it's enabled. It does 
require that CSF (ICSF) be running/have run since IPL. It tests a bit CSF sets 
after *it* verifies the existence of CPACF by trying the instructions.

/* REXX */
   if bitand(storage(d2x(x2d(c2x(storage(d2x(x2d(c2x(,
 storage(d2x(x2d(c2x(storage(10,4)))+x2d(C8)),4)))+,
 x2d(B8)), 4)))+x2d(11A)), 1), '08'x) <> '00'x then
   say 'CPACF is enabled'
   else say 'CPACF is not enabled'
/*
tests CCVT_KMC_AES256 (x'08', "KMC AES 256 key enabled")
on flag CCVT_KMC_EXPORT3 (offset 11A)
in CSFCCVT, pointed to by CVTABEND (offset x'B8')
into CVT (X'10' in page 0)
*/


If by some chance CPACF is NOT enabled, it's a free feature on all current IBM 
hardware, so get it turned on!

Do make sure that anything you enable AT-TLS for both can handle TLS at the 
other end AND is not already doing TLS. We've had several incidents where 
people turned on AT-TLS "because it's good" and our product was already doing 
TLS. The double encryption does not work out well--specifically, it results in 
strange connection failures because "inner" level of negotiation works, but 
then instead of seeing a request, it sees another TLS negotiation start, which 
it doesn't understand since it's not looking for one. It doesn't sound like 
this is your issue--if it were, you'd be having failures, not delays!--but it's 
important to understand and I'll keep repeating it because it seems to be a 
common error.


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

Re: Encryption and decryption - processor or TCPIP

[Phil Smith III]

Peter wrote:
>I have a general question here. When you don't have crypto processor, So
>when a ATTLS traffic is enabled does the encryption and decryption handled
>by Started task TCPIP or the general processor?

The TCPIP started task is just code and runs on the general processor, so your 
question doesn't make much sense. AT-TLS is managed
by the Policy Agent started task, and it appears that the actual encryption 
takes place in the TCPIP started task, but that's a
conclusion-I've never wondered.

Why do you ask? What problem are you trying to solve? We'd like to know more!


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

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

[Phil Smith III]

Itschak Mugzach wrote:
>The STIG does not allow a uss keystore.

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


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

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

[Phil Smith III]

Radoslaw Skorupka wrote, in part:
>"security by obscurity" means just the key under the mat.

I'd agree that it perhaps SHOULD mean that, but that isn't how people use the 
term. And even then, I'd submit that that's just another trivial case of "if 
you have enough": you have to know/think to look under the mat.

ObAnecdote: 35+ years ago, at a tiny vendor, we took a power hit and the room 
didn't come back up. Eventually I convinced myself the room still didn't have 
power, so I called the power company. By this point it's 2AM. Power guy comes, 
is cheerful, needs to get into room with main breaker. Door is locked. I ask if 
he has a sledgehammer; he says sure, but HE'S not about to smash the doorknob. 
No, I say, I'll do it. Building isn't supposed to have us locked out, we have a 
company to run, a $10 doorknob is a perfectly reasonable price to pay. So I 
bash the knob and he fixes the problem (a half-tripped breaker).

Next day I go down to tell the building guy what happened. He listens, 
laughs-and reaches up to the top of the doorframe, pulls down a key.

So we had security by obscurity AND the XKCD both more or less exemplified in 
one incident! (OK, we were smashing a door with a hammer, not hitting a guy 
with a wrench, but close enough.)


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

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

[Phil Smith III]

If you mean certificates for TLS, the USS gskkyman utility is great for 
testing/verification. Nothing wrong with it for production, but most sites in 
my experience are happier with the certs in SAF (RACF/ACF2/TSS) for production. 
The beauty of gskkyman is that it's isolated AND discrete. With SAF you can 
screw other folks up and/or think you have it working correctly when you don't. 
With gskkyman you can create a database containing just the certificate(s) you 
think you need and verify that they work, then move them to SAF.

 

gskkyman operates via a series of prompts, so it's pretty easy to use:

*   Get the certificate in a USS file, preferably as a Base64-encoded file 
(doesn't have to be, just easier to say "Yep, that looks like a certificate")
*   Go into gskkyman and import it
*   Point the application truststore at the gskkyman database and test

 

Obviously I'm making a bunch of assumptions about what you're doing in the 
above, so none of it may apply.

 

...phsiii


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

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

[Phil Smith III]

Paul Gilmartin wrote:
>I believe otherwise. I know of a case where a vendor allowed a product
>to escape to the field containing a tester's back door, and another
>related to II14489. Either could be exploited with no brute force,
>merely knowledge of the existence and nature of the defect. In the
>case of the latter, the vendor chose to obscure the details very long
>term to protect customers who might not have installed the fix.
>"That's security by obscurity."

But that's still the same thing, just smaller: IF they knew about it, then they 
could exploit it. It's just a matter of degree. Similarly, OCO makes it harder 
to find the way around, say, a CPUID or license key. 

>But protecting passwords is a valid use of "That's security by
>obscurity." A password is not a pervasive defect as those other cases
>are.

"protecting passwords" in what context? I'm sure your point is valid but it's 
escaping me!


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

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

[Phil Smith III]

Leonard D Woren wrote, in part:
>Software can be hacked.

Um. And? What's your point? Anything can be hacked:
https://xkcd.com/538/

The phrase "security by obscurity" has bothered me for years. It's *ALL* 
security by obscurity. If you have enough "stuff"-time, money, guns 
(wrenches)-you can get in. The trick is to make it hard enough that you outrun 
the bear.

For example, 256-bit AES can be broken by brute force-if you have until the end 
of time. (And if you'll know it when you see it, another issue.) But that 
"until the end of time" means you can use it to outrun the bear.

When people say "That's security by obscurity", they really mean "That's weak 
security because the barriers aren't high enough". That's all. It's not a big 
revelation.

.phsiii


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

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

[Phil Smith III]

Steve Estle wrote, in part:
>but we'd like to encrypt as much as possible in our environment

Why? What problem are you trying to solve? Remember that DSE provides 
protection against exactly two attacks:

1) Someone getting at the wire between the array and the CEC

2) Rogue storage admin



Those are the risks for which it was designed and implemented, and it does a 
fine job of those. Otherwise, it's no different from
RACF/ACF2/TSS protecting stuff in the first place. (I'm assuming you have 
encrypting DASD already.)



If the rational is "Encryption is good because encryption", that's dangerous, 
because you're not really protecting very much. I
realize that this may be management's delusion, but it's not good. There's way 
too much of that out there-"We protected something,
yay, now we're safe(r)". Not necessarily.


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

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

[Phil Smith III]

Interesting discussion. Some thoughts.

 

First, it's not "Pervasive Encryption" you're talking about. It's IBM z/OS data 
set encryption (DSE). PE is the IBM encryption strategy. When data set 
encryption came along, IBM kept calling it PE, but it's just part of PE (the 
rest of which hasn't really been that well defined, IMHO).

 

Paul Gilmartin asked:

>What about Format preserving encryption?

 

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

 

In fact, that leads me to wonder: what mode of AES *is* DSE using? It's AES, we 
know that, but it's unclear which mode. Since many modes increase the size of 
the data, I'm assuming it's a mode that does not increase the data size. Ah, 
this link (PDF):
https://public.dhe.ibm.com/eserver/zseries/zos/DFSMS/ENCRYPTION/OA56622/OA56622.pdf
suggests-though doesn't state explicitly-that it is indeed XTS, with the 
ability to switch to some other mode in the future if necessary (good design).

 

Grant Taylor wrote, in part:
>Conversely encryption is a kind of data authentication / verification.

 

Um.not unless it's using specific AES modes, like GCM. If it's not expanding 
the data, there's nowhere to "fit" any kind of authentication. And per the 
above, I'm pretty sure it's (currently) XTS.

 

He also noted:

>Viruses (for PCs) have been self-decrypting for a long time.

 

Sure, but there's some code getting invoked to do that. It's not magic. Still 
doesn't make it clear why DSE cannot do program objects.

 

Attila Fogarasi suggests that the reason is simply because DSE requires 
extended-format data sets, which libraries aren't. That seems compelling. I 
assume the implicit rest of the story is, "IBM put the DSE code only in the 
extended-format data set processing code, because reasons".


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

Re: allowed characters in member name

[Phil Smith III]

Paul Gilmartin wrote:
>STOW 'Abc Xyz!'probably works.
>STOW 8X'FF'   probably doesn't or produces unexpected results.

Ah.this is in reference to the original question, sorta, not to my "Why?" 
question. Thanks.


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

Re: allowed characters in member name

[Phil Smith III]

Radoslaw Skorupka wrote:
>The "8 characters rule" is widely used in z/OS and mainframe world.
>Why?

Presumably because a doubleword is a nice, discrete size of data-big enough to 
be useful, small enough to manipulate with things like two (now one) register?

And Steve Beaver added:
>The simplest path on this discussion is to try it in batch or ispf. The only 
>other way is in HLASM with the STOW macro

Try what? Unclear what you're suggesting?


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

Re: allowed characters in member name

[Phil Smith III]

Paul Gilmartin wrote, in part, in answer to "Why can't a data set name element 
start with a digit":
>Left-to-right lexical analyzer that treats anything beginning with a digit
>as a number.

I'm willing to believe this, but am unclear on why whatever is parsing a DSN 
would care whether it's a number or not. E.g.:
//SYSINDD   DISP=SHR,DSN=1.2.3

Why would it care that it's a digit? The start of a non-initial DSN element is 
the thing after a period, so it doesn't matter there.

 

My guess is something planned/considered that never happened, or just a mistake 
late on a Sunday afternoon in 1962.


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

Re: allowed characters in member name

[Phil Smith III]

Has anyone ever understood why data set/member names cannot start with 
numerics? Just curious, as it seems like an odd restriction.


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

Re: TCPPING for z/OS

[Phil Smith III]

Am I the only one who keeps reading this thread subject as "TIPPING for z/OS" 
and thinks, ", this tipping thing is REALLY getting out of hand!!!" ?


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

Re: Assembler programmer wanted

[Phil Smith III]

Dean Kent wrote:

>In that case, I think that California law would not apply.   I have the

>impression (perhaps mistaken) that the labor laws apply to residents,

>not remote workers.

 

This is correct. I know this because when HP bought Voltage Security, we were 
no longer able to roll over any PTO, as mandated by California. Voltage was a 
California company too, but had one policy; HP/HPE/Micro Focus/OpenText aren't 
so generous.


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

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

[Phil Smith III]

Now that we've gotten to clarify on the Basic Constraints thing (TL;DR: the 
RFCs require it; System SSL does not, prior to TLSv1.3; for LE at least, an 
ENVAR can override it), I have a follow-on question:

 

Can I set an environment variable outside of LE and have it apply to the LE 
enclave? Our STC starts with an assembler program that handles the PC, XMS, 
etc., and then eventually calls the LE program to do the actual work for the 
client. While it doesn't matter here, since the ENVAR is needed only for the LE 
part, I wondered whether we could have also set the environment variable for 
the entire PROC and have it work. Figured someone would know offhand; a bit of 
searching was inconclusive, and I can't trivially test it because the broken 
certificate was corrected and making someone put it back AGAIN the week before 
Christmas when half the office is already gone would be difficult. Plus it 
might save someone else hassle later to get it hashed out here, in the archives.

 

TIA


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

Re: SMP/E question of the day

[Phil Smith III]

Kurt Quackenbush wrote, re:

>> NAME ABCDITSK ABCPROC#C C_CODE

 

>I believe SMP/E supports a maximum of 8 characters for the LMOD,

>CSECT, and CLASS names specified on the IMASPZAP NAME statement. CSECT

>name ABCPROC#C is 9 characters.

 

Right, but that's the generated name-the module is ABCPROC, written in C. How 
does one get around this? As Gil suggests, this seems like an SMP/E bug/failing.


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

Re: SMP/E question of the day

[Phil Smith III]

Binyamin wrote:
>Unless you are sending this via teletype or FAX, I question why you
>would provide a zap rather than a module replacement.

Well, we've been discussing that already. But we'd like to understand it at 
least.

Meanwhile, Tom Marchant's suggestion sounded helpful, except it's C code. So 
what should:
NAME ABCDITSK ABCPROC#C C_CODE
become? It complains about the ABCPROC#C.


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

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

[Phil Smith III]

Oh. It does say:
"If TLS V1.3 is negotiated for a secure connection, certificate validation is 
done according to RFC 5280 unless explicitly specified."
but also still says "The default value is ANY."

That seems a tad bit unclear, should be more like:
" The default value is ANY, unless TLS V1.3 is negotiated for a secure 
connection, in which case certificate validation is done according to RFC 5280 
unless explicitly specified."

In the meantime, I've verified that adding the environment variable fixes it, 
so I'm good!

Thanks again to all. This all harkens back to two long-departed cow-orkers, who 
said:

Hansen's Law: It's always a certificate problem.
Weald's Corollary: Even when it's not a certificate problem, it's a certificate 
problem.

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

SMP/E question of the day

[Phil Smith III]

>From a coworker, who tried to post but it seems to have vanished-not even a 
>bounce?! If it just got stuck somewhere, this might be a duplicate, sorry.

 

 

I am having problems trying to convert a normal ZOS AMASPZAP to a SMPE ++ZAP.

 

When I run the zap through a standalone AMASPZAP process everything works fine:

 

IGWSPZAP  INSPECTS, MODIFIES, AND DUMPS CSECTS OR SPECIFIC DATA RECORDS ON 
DIRECT ACCESS STORAGE.

AMA168I SYSIN PROCESSING STARTED

NAME ABCDITSK ABCPROC#C C_CODE

VER 067A EC0A008C,A077

VER 0680 5800926C

VER 0684 A7011000

VER 0792 58F0301E

VER 0796 E54CD0E0,

VER 07AA E300D13B,0094

VER 07B0 EC060018,007E

REP 067A EC0A0102,A077

AMA122I OLD DATA WAS EC0A008CA077

CHECKSUM C08C1494

AMA132I CHECKSUM WAS CORRECT, IS NOW 0.

AMA163I PREVIOUS GROUP ENDED, ASSOCIATED MESSAGES FOLLOW:

AMA125I IDR COUNT = 1 FOR SECTION = ABCPROC#C

AMA164I END OF MESSAGES FOR PREVIOUS GROUP

AMA168I SYSIN PROCESSING COMPLETED

AMA100I IGWSPZAP   PROCESSING COMPLETED

 

However when I try to apply:

 

++VER(Z038) FMID(VABC840) .

++ZAP(ABCDITSK) .

NAME ABCDITSK ABCPROC#C C_CODE

VER 067A EC0A008C,A077

VER 0680 5800926C

VER 0684 A7011000

VER 0792 58F0301E

VER 0796 E54CD0E0,

VER 07AA E300D13B,0094

VER 07B0 EC060018,007E

REP 067A EC0A0102,A077

 

SMPE has issues

 

  SET BOUNDARY(TARGET) .

GIM20501ISET PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 00.

 

 

  APPLY S(ABC8401) .

 

--NAME ABCDITSK ABCPROC#C C_CODE

GIM23101E ** THERE IS A SYNTAX ERROR IN A ZAP CONTROL STATEMENT FOR MODULE

 ABCDITSK IN SYSMOD ABC8401.

GIM30216IAPPLY PROCESSING FAILED FOR SYSMOD ABC8401. SYSTEM UTILITY

 PROCESSING FAILED FOR AN ELEMENT IN ABC8401.

GIM20501IAPPLY PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 08.


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

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

[Phil Smith III]

Chris Meyer wrote:
>I checked with the System SSL folks on this.  

>It sounds like what you're observing is a difference in default System
>SSL certificate validation mode settings Between TLSv1.2 and TLSv1.3.
>See the description of the System SSL GSK_CERT_VALIDATION_MODE
>parameter in this table:
>https://www.ibm.com/docs/en/zos/3.1.0?topic=programming-environment-variables.
>Note that the default for TLSv1.2 (and earlier) is ANY, which initally
>validates against RFC 2459 which has the relaxed requirements
>regarding the critical bit. For TLSv1.3, however, System SSL defaults
>to RFC 5280 checking which requires the critical bit to be set.

>Based on what you've said in this thread, I'm assuming that you have
>not specified a value for GSK_CERT_VALIDATION_MODE, as that would
>result in the behavior you described.

Ah HAH -- this has to be it! An no, we are not specifying a 
GSK_CERT_VALIDATION_MODE.

All the doc says ANY is and remains the default. Are you saying that the 
default silently changes when it's TLSv1.3? If so, is that a code bug or a doc 
bug?

It looks like an environment variable can change that setting, too. I'm going 
to see if I can get someone to replace the certificate with the "bad" one and 
try that. If that'll get us around it, we'll be good--if some customer hits it, 
we can say "Add this" and they'll be good to go. As I think I wrote before, I'm 
not all that worried about that happening, since any real modern root cert 
SHOULD have BC set correctly, but it would be good to know.

Thanks!

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

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

[Phil Smith III]

Charles wrote:
>The critical bit is there to provide upward compatibility for
>certificates, which are a standard that is implemented in everything
>from z/OS to Nest Thermostats to Balckberrys that have not been
>updated in ten years.

>The critical bit says "this extension really matters. If you don't
>know what this extension is all about, if you don't recognize it, if
>it is a newer standard than your implementation, then you must reject
>this certificate."

>So it seems to me to be really fussy pedantry for a TLS implementation
>(yes, GSK) to say "I recognize that extension, but you were SUPPOSED
>to set the critical bit, so nanner, nanner, I am rejecting it."

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

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

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

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

...phsiii

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

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

[Phil Smith III]

Charles Mills wrote, in part:
>Confirming:

>The complaint was at the client end. The client is z/OS. The complaint
>was that the CA root had a Basic Constraints extension that was not
>marked as critical?

Yes. And that it only seems to matter to gsk when the client says "I can do 
TLSv1.3".

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

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

[Phil Smith III]

Peter Sylvester wrote, in part:

>There is a difference between what you must set and what you must

>verify. 5280/3280 is clear (IMO) about that.

>when you verify a cert, AND you know about the extension, you just

>verify the extension and don't care about the critical bit

>Since the error message seems to indicate that the extension is known,

>the verifier has no reason to checjk the criticality bit.

 

By "when you verify a cert" you mean gsk, and that it shouldn't care about the 
critical bit?

 

>>The fix was to update the root certificate used by the server to add

>>the required Critical value for Basic Constraints (henceforth "BC" as

>>a shorthand).

 

>The RFC path validation does not usea selfsignedroot certificate. The

>only necessary thing for an implementation is to have an association

>between a subject an a public key.

>A self signed cert is just handy.

 

>>This happened again here this week when a certificate was updated

>>(someone used the wrong internal CA, which was old). Once we got it

>>straightened out, I started wondering why this only happened once we

>>added TLSv1.3 support. Some reading of RFC5280 (which obsoleted 3280)

>>suggests that a PKIX-compliant certificate should ALWAYS be rejected

>>if not BC. But this doesn't seem to be true until we add the TLSv1.3

>>support.

what is suggesting this?

 

If by "this" you mean "what is suggesting 'But this doesn't seem to be true 
until we add the TLSv1.3 support'" then it's that the old version, which 
doesn't do TLSv1.3, didn't get the BC error with the same cert.

 

>SNI is used to identify a server, and in particular, the cert (chain)

>to be presented to the client.

 

Right, I know.I was just noting that this was another change between versions, 
in case there was some interaction.

 

>Does you product work with TLS 1.2?

 

Yes. Has for years. Both old and new versions.

 

So to recap, my perception is that if the client doesn't say "I can do 
TLSv1.3", BC doesn't matter; if it does say so, BC matters.

 

I feel dense, but I'm not sure what to conclude from what you wrote-whether 
you're suggesting that gsk is doing something wrong or not. Or maybe you hadn't 
presented a conclusion yet, pending my answers above!

 

Appreciate the input, hoping for more.

 

.phsiii


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

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

[Phil Smith III]

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

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

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

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

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

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

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

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

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

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


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

Re: CBS's "60 Minutes": Quantum Computing

[Phil Smith III]

All the big-brain mathematicians/cryptographers I know are extremely skeptical 
about quantum computing ever becoming a reality. The problems of stability are 
also exponential, and so getting from a few dozen/hundred qbits to something 
big enough to be reasonable may be essentially impossible. 

 

Of course some breakthrough could happen; so could room-temperature 
superconductors, anti-gravity, or a cure for cancer. Tomorrow-or never.


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

Re: RACF, the FACILITY class, and z/XDC

[Phil Smith III]

Ed Jaffe recommended against creating a SAF class. I'll respectfully suggest 
that it's not that hard.

First, if you do, IBM told us, "Start the class name with a dollar sign-we'll 
never use those". Of course you could collide with
another vendor, but that's unlikely.

We've had customers doing so for 13 years or so. Besides some folks who didn't 
understand how to use their own ESM, we've had no
problems. ACF2 and TSS were easy, too.

Now, I admit that our usage is pretty simple: we have named data protection 
entities called Cryptids, and you can use them to
protect (encrypt/tokenize/hash) or access (decrypt/detokenize) data. So if you 
have a Cryptid named BANANA, a user needs READ or
greater authority to PROTECT.BANANA or ACCESS.BANANA, as appropriate to use 
BANANA to protect or access. 

For something like EJES, with possibly dozens of subtleties, it would surely be 
harder. The complexity of SAF related to
certificates comes to mind, though I suspect some of that is due to some 
historical mistakes. Still, once you've defined a scheme,
it's just PERMITs, right?


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

Re: IBM APAR Names

[Phil Smith III]

Shmuel wrote:
>Whoops! Somehow I missed the last sentence of the paragraph.

Ah hah! Hence the confusion. Glad we straightened that out.


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

Re: Kinda fun

[Phil Smith III]

Stuart Holland wrote, in part:
>Also, the cards only had the punches - no text across the top. 

That was called "interpreting" cards, IIRC. I forget whether there was a 
machine to do this (not that a site with no more punches or readers would have 
had one!), but I bet others here will remember.

ObJoke: What, you didn't remember how to just glance at the cards and read the 
punches? (I'm 100% sure that back in the day there were folks who could!)


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

Re: IBM APAR Names

[Phil Smith III]

Shmuel wrote:
>SES is a tools that fills the same nicje in the VM ecology as SMP does
>in the MVS ecology.

Right, I said that. Hence my confusion about what point you were making.




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

Re: Kinda fun

[Phil Smith III]

Bob Bridges wrote about his history with keypunches.

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

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

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

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

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

Don't miss https://www.masswerk.at/keypunch/ !


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

Re: IBM APAR Names

[Phil Smith III]

Shmuel wrote:
>What is VMSES/E, chopped liver. I'd agree if you were talking free VM,
>but by the time z/VM came out SES was old hat.

? Not sure what point you're making, I'm afraid?


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

Kinda fun

[Phil Smith III]

https://blog.computationalcomplexity.org/2023/11/in-bad-old-days-we-had-punchcards-how.html


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

Re: IBM APAR Names

[Phil Smith III]

This has been interesting. As a long-time VMer, I'd note that in VM-land, there 
is of course no SMP/E and things are a bit different. "APAR" and "PTF" kind of 
get used interchangeably, though there is recognition that they're not the 
same. But typically a VMer will say "I need APAR VM20779", not "I need the PTF 
for z/VM 7.3 that came from APAR VM20779", because it's basically same 
difference without SMP/E. The VM maintenance tools (VMSES/E) work fine but 
aren't as.shall we say theological? as SMP/E.

 

(Extra credit for anyone who remembers VM20779, at least 40 years ago!)


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

Re: IBM APAR Names

[Phil Smith III]

An aside re SPEs: back in the early 80s, IBM released an SPE for a CMS utility. 
The original code was on the order of 500 lines; the SPE was something like 
3500. Melinda Varian (whom some of you may recall) posted to VMSHARE-the 
VM-oriented BBS of the era-a review of the change, which had a number of 
significant problems, concluding:
"This is small? This is programming?? This is an enhancement???"

 

I was just starting out, but it solidly cemented the meaning of "SPE" for me!


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

APAR theology (was: IBM APAR Names)

[Phil Smith III]

Without wanting to start a war, I’m interested in how this works. I’ve worked 
with IBM stuff for over four decades, but mostly with VM until the last 15 or 
so years.

 

My understanding is:

*   PMR: represents a customer issue, which may end there.
*   APAR: represents a customer issue that at least seems to indicate a 
code problem. Existence of an APAR does not guarantee a fix will ever be 
created; it’s more a recognition that there’s more to it than just “customer 
needs an existing fix”, “is doing something dumb”, etc. One APAR might thus map 
to multiple PMRs, if multiple customers have the same problem.
*   PTF: An actual fix

 

Now y’all are talking about “APAR fixes”, which I’ve never heard of. And I know 
there’s more to APARs than I wrote, just can’t remember it. Having worked for 
vendors for the last 37 years means I’ve been out of the normal flow of such 
things, too—when I was at UofWaterloo, we had a backlog of a couple of hundred 
things that we’d fixed in IBM code; we had an agreement with our PSR—the sort 
of “level 1 ½” that customers have [had, then, anyway] that we’d only have 5 
open at once. That was always fun: call IBM, “I want to open five problems.” 
“FIVE PROBLEMS???!” “Well, I have a couple of hundred, but I’m only opening 
five today.” “Oh, ok.”

 

ISTR that if a problem appears in multiple supported releases, one APAR might 
result in multiple PTFs, one per release.

 

I’m also interested in a definitive list of APAR closings. I’ve never seen one, 
and the lists I’ve seen have been conflicting and often included different 
interpretations of the same closing.

 

None of this matters a ton, of course, but it *works* when done right, which is 
more than I can say for many customer problem workflows!

 

I don’t see this as particularly sensitive info, but perhaps IBM will disagree, 
in which case I’ll STFU.


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

Capacity control for the win (not)

[Phil Smith III]

Ring/Alexa are a bit overwhelmed tonight-I'm getting alerts 10 minutes after 
the doorbell actually rang. Shoulda used CICS.


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

Re: FTP problem

[Phil Smith III]

Wendell Lovewell wrote:
>fwiw, I wrote a bash script to run gsktrace and ftp it to a Windows
>FTP server. (I connect to z/OS using SSH to run it.)

Thanks.if I had a Windows FTP server (which I don't, despite my original post), 
this would be great. I do a LOT of ftp -i TO this system, some FROM it. This is 
the first time FROM has had a problem. (TO sometimes fails due to random 
network timeouts, but that's another story.)


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

Re: FTP problem

[Phil Smith III]

Off-list reply pointed out that I meant "z/OS FTP server", not "Windows". 
Braincheck. I fire up Windows FTP client, do GETs. And yes, I was specifying 
ASCII. That's what was so weird: it sometimes said 
125-Tagged ASCII file translated with current data connection translation table
.which is what got me tinkering with chtag. But sometimes it didn't say 
'translated', and the resulting file was STILL borked!

Annotated:
* FTPed file, it was borked. Let's tinker with chtag.
> chtag -p gskinterop.txt
t ISO8859-1   T=on  gskinterop.txt

* Hmm, 8859-1, that's weird. OK, let's untag it
> chtag -r gskinterop.txt

> chtag -p gskinterop.txt
- untaggedT=off gskinterop.txt

* FTPed it again, still borked. Even with explicit ASCII.

* Let's tag it explicitly
> chtag -t -c ibm-1047 gskinterop.txt

> chtag -p gskinterop.txt
t IBM-1047T=on  gskinterop.txt

* Still borked.

I started to think something was going on on the Windows side, so I replaced 
the file contents with a * before retrying the above. No change: the borked 
version was full-size, just not translated, apparently. Yes, when I look at it 
on z/OS it looks fine.

Yes I could use scp but that's not how I normally do this.


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

FTP problem

[Phil Smith III]

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

 

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

 

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

 

Ideas?


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

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Phil Smith III]

Peter Relson wrote:

>I on the other hand do have sympathy. A highly significant reason that

>z/OS still exists (and the same could have been said for its

>predecessors OS/390 and MVS) is because of the enormous amount of time

>and effort we have put into maintaining as much compatibility as we

>can. We do not treat incompatibility lightly. We do try to keep down

>the number of upgrade actions needed to move to a new release.

 

+1000. Nobody does compatibility like IBM, and that's A Good Thing that s 
many other vendors should learn from. Microsoft changes UI elements and 
keyboard shortcuts silently with service! And breaks myriad other things, also 
without notice.

 

IBM has been my guiding light in this regard for my 37 (gulp) years at vendors. 
When we break something, we try to do it visibly-e.g., a configuration option 
that fails at startup, rather than doing something unexpected. And it's 
documented, of course, AND in release notes.

 

Of course this is enterprise software, where folks can be expected to read 
release notes; if they don't, my sympathy is low. Consumer stuff, expectations 
are somewhat different.

 

Anyone who's dealt with the Python 2 to Python 3 mess should understand.

 

...phsiii


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

Re: SMP/E and PATH existence

[Phil Smith III]

Jon Perryman wrote:
>Is APPLY CHECK no longer standard practice when installing a PTF or
>product? Quackenbush says checking DDDEF's externally is unnecessary
>and will only take take the time required for APPLY CHECK.

You missed my point-APPLY CHECK happens after doing several steps already, and 
if the user needs to then get help with USS, they're now half-done and will 
either have to start over (because things changed) or at least have to remember 
where they were.

Yes, this should all be easy. Sad to say, it's not, for many customers, where 
the grizzled veterans have retired (or worse).

Failfast is A Good Thing.


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

Re: SMP/E and PATH existence

[Phil Smith III]

Jon Perryman wrote:
>Kurt is saying that APPLY CHECK does exactly what you want. CHECK
>verifies SMP/e has everything expected and will run 100% through. If 3
>DD / DDDEF's are missing, then you should see those 3 errors and any
>other errors that SMP/e detects. APPLY CHECK only validates DD /
>DDDEF's that are needed for the apply and ignores all other DD /
>DDDEF's. I've never experienced missing DD / DDDEF's, so I'm basing
>this on Kurt's recommendation.

Yep, I got that, thanks. But understand that by that point, they're halfway 
through the install. Far better for it to fail first thing, so they can fix 
that and then run through the entire process. Remember how alien many z/OS 
folks think USS is.


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

Re: SMP/E and PATH existence

[Phil Smith III]

Kurt Quackenbush wrote:
>SMP/E APPLY CHECK and similar commands verify existence of directories
>and data sets from DDDEF entries before they are used. There is no
>independent SMP/E command or utility to perform this verification.
>However, there is a capability in z/OSMF Software Management, the
>Software Instance Validation action, which does this kind of checking,
>among others.

Thanks. Since I really, really don't want them to get 3/4 of the way through 
and then have to go hunt down someone with USS access, I'll use 
BPXBATCH/IDCAMS. At least now I know I'm not missing something obvious!


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

Re: PARM='GRAPHICS(CHAIN(SN))'

[Phil Smith III]

For the record, while I was the one who used it, I did NOT know about it-a 
colleague did. I am only an egg when it comes to z/OS stuff. Just in case 
someone was wondering-which I know you weren't, but I didn't want to get credit 
where it wasn't due.


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

Re: SMP/E and PATH existence

[Phil Smith III]

Rob Scott wrote:
>A long time ago, I wrote a program called DDDEFCHK that used the SMP/E
>API to check if normal DDDEF data sets exist - there is also a
>DDDEFPTH companion program to handle paths.

Ah, so that kinda confirms that SMP/E can't do it natively. I think 
BPXBATCH/IDCAMS are a better bet for us, then-nothing to maintain. Thanks.


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

SMP/E and PATH existence

[Phil Smith III]

Is there a way to get SMP/E to validate the existence of a USS path on a DDEF? 
Thanks to y'all's help, I have externalized the USS path we use to a variable. 
However, if the directory doesn't exist, the user can get pretty far (to the 
RECEIVE step) before that's recognized. I've looked at the SMP/E doc but didn't 
find anything.

I realize I can do this with BPXBATCH:
//TESTDIR  EXEC PGM=BPXBATCH,PARM='SH test -d '

Or with IDCAMS:
//TESTDIR  EXEC PGM=IDCAMS,PARM='GRAPHICS(CHAIN(SN))'
//SYSINDD *,SYMBOLS=(JCLONLY,JESJCL)
ALLOCATE   DDNAME(VSHZFS1) PATH('')

But this seems like something SMP/E might reasonably also do "natively". Can it?


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

Re: Bob Shannon

[Phil Smith III]

I didn't know Bob well, but my SHARE interactions with him were always 
encounters with a gentleman. I am sad today.

 

...phsiii


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

Re: JCL symbols used to define other JCL symbols [was: RE: Is SMP/E needed for installs?]

[Phil Smith III]

Farley, Peter wrote:
>I believe that statement in the JCL Reference is in error and needs to
>be deleted or at the very least completely rewritten. My quite
>substantial experience using this technique over the last 10-15 years
>is that using JCL symbols as part of the definition of other JCL
>symbols works flawlessly every time. There is no unpredictability. If
>the symbol used to define one symbol isn't already defined, you get
>the literal "" value that you coded as part of the definition.
>This works for both SET and PROC and EXEC statements, without any
>failures or unpredictability that I have ever seen. The resulting
>VALUE of that symbol may cause errors, but there is no
>unpredictability to the symbol definition process.

>I cannot imagine any circumstance in which the result of defining one
>JCL symbol using another JCL symbol would ever be unpredictable.

>If there is any possible case where the result is unpredictable, IBM
>should be required to specify the circumstances and explain why.

I'd bet large coin that what this really means is "If you do this, you're 
likely to confuse yourself". As indeed you COULD-anyone who's gotten sloppy 
with Rexx stemmed variables (where this kind of usage is more common) has been 
burned that way! Of course in the examples Peter Hannigan provided, you're 
*trying* to play those games, so I think it's as safe as anything.


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

Re: Is SMP/E needed for installs?

[Phil Smith III]

Peter Hannigan wrote:
>If the length of the prefix can be limited to seven characters then
>this can be used:


Wow. It took me 10+ minutes of staring at this to puzzle it out. Too clever by 
half for me (and that's not meant as an insult). 

After much discussion, we've concluded that nobody is going to load our stuff 
to the "root" on a real system, and if they do, then they're going to be an 
SMP/E jock already. So while I love this suggestion and will look at other ways 
to use it, I think I'm just going to put a comment in the common member that 
does the SETs saying "You can't have a null HLQ/RPREFIX". The other places 
where the HLQ gets substituted in would have the same problem (though, yes, I 
could be clever and set them with a trailing do, but that way lies madness).

I really appreciate all the help folks have provided with this. Our 
installation is now MUCH cleaner/simpler because the edits to the actual jobs 
comprise just:

1.  JOB card (doh)
2.  JCLLIB (right below the JOB card, so easy to find)
3.  Possibly SMS changes from UNIT= and VOL=SER=



I vaguely considered changing the last one to use a variation on your approach, 
Peter, but that would have to assume (as the default does) that all the data 
sets use the same values. Again, at that point, hopefully the customer is 
sophisticated enough to deal with it; can only hold their hands so far before 
it becomes ridiculous.

If folks think I'm being silly in any of these conclusions, I'd love to hear it!

...phsiii


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

Re: Error messages (a rant and an idea)

[Phil Smith III]

Steve Beaver wrote:
>I can remember when IDC3009I was just maybe half a page max.

>Now you look at IDC3009I and it pages upon pages of diagnostic codes 
>and what they mean

I've decided this is supporting my thesis-can't quite tell? Or are you saying 
this is one of those cases where breaking it out into several messages would 
have made sense?


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

Re: Error messages (a rant and an idea)

[Phil Smith III]

While I agree that it would be nice if the messages were complete, I'm not sure 
I can see a business case for IBM to implement that. It would cost a lot, 
consume the last two or three remaining docs folks well past their retirement 
age, and.for what? Will it increase z/OS uptake? I doubt it.

 

Me, I'd settle for the hex codes having good and centralized explanations. 
Though I realize that way could lie madness, as it could encourage 
laziness-adding new messages as just another such code rather than thinking 
about it and giving a "real" error message.

 

I and others have observed that when creating good software, error handling can 
be the largest part of the job. In complex environments, there are often many, 
many errors that *should* never appear. Bad software ignores those errors, 
figuring it'll show up somewhere else (as it often does, to the user's complete 
confusion); or falls back on a catch-all, like Microsoft's "That didn't work", 
with no additional info and no idea what to do about it.

 

One school would have every such error try to be complete and distinct, so that 
errors 4832 and 4833 might be similar but are definitely differentiated. But 
then if you're documenting the errors, your manual/database may be 75% such 
errors-for all of which the suggested action is "Contact support", since it's 
basically "We have no idea what you did to even cause this?!"

 

For such errors, I'd argue that a single error *with a distinct subcode* is 
more useful: "Internal error 1234; contact support". That takes one entry in 
the Messages & Codes, and since there is no real additional useful information 
to record, it's no less helpful to the user. I suspect that's where the USS hex 
error codes came from originally, though I sure don't know.

 

When this is the approach, it's probably important to have a goal-and perhaps a 
policy-of paying attention to occurrences of such errors, and making them more 
"real" if appropriate. Maybe that sounds obvious, but it's really self-defense 
as much as anything: if "Internal error 1234" means "You need to enable the 
Florblatz option and try again", you change that case of the error to say just 
that, thus eliminating (some of!) the support calls.


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

Re: Query strings (was: AI expert hot new position.)

[Phil Smith III]

Paul Gilmartin wrote, in part:
>Who puts it there?

The site. Probably depends how you got there. The one on the CNBC link is:
__source=iosappshare%7Ccom.apple.UIKit.activity.CopyToPasteboard

No idea about the stuff after the %7C (ISO8859-1 OR bar), though I can guess, 
but the first part obviously suggests OP is using an Apple product and selected 
a "Share" option from some app.

There are, of course, plenty of cases where removing the query string breaks 
the link. I tend to clean it up if I remember, but always test-in another 
browser-before sending.


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