Re: JES2, meaning of parameter value codes

[Frank Swarbrick]

But what is the 'j' in 'jccc'?  Why not just ''?

From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Monday, February 28, 2022 6:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: JES2, meaning of parameter value codes

What is unclear? nn is any two digit number. jccc is any character string 
that is a valid ddname. PROCnn or Jccc names a concatenation that can be 
selected as the procedure library concatenation for a job, as specified by 
JOBCLASS(v), JOBCLASS(STC), JOBCLASS(TSU) or  /*JOBPARM PROCLIB=ddname. You 
need to look at the JES2 JCL, any PROCLIB(foo) statement in the initialization 
member and any subsequent commands, e.g., $ADD PROCLIB, to see what is in each 
concatenation.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Monday, February 28, 2022 7:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2, meaning of parameter value codes

https://www.ibm.com/docs/en/zos/2.5.0?topic=class-parameter-description-jobclassclassstctsu

PROCLIB=nn|j|00
Specifies the default 2-8 character procedure library name (jccc) or 
procedure library number (0-99) which is to be used for this job class. It 
allows you to specify procedure libraries for different job classes. In the 
JES2 procedure, one DD statement must be named PROC00. If you specify 
additional procedure libraries (jccc or 01-99), then you might associate 
these libraries to a job class by replacing the jccc or nn of this 
parameter with the appropriate procedure library name or number. All cataloged 
procedure libraries to be used by jobs, time-sharing users, or system tasks 
must be defined in the JES2 procedure.

z/OS 2.5


From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Monday, February 28, 2022 5:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: JES2, meaning of parameter value codes

Please post example and release level.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Monday, February 28, 2022 6:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES2, meaning of parameter value codes

I am looking at the JES2 Initialization and Tuning Reference.  There are 
examples job parameters with codes such as "jxxx" and "jccc".  I can't 
seem to find a table of their meanings.  Can someone point me in the right 
direction?
Thanks,
Frank

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

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

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

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

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

Re: Solutions Not Problems - Dilbert Comic Strip on 2022-02-25 | Dilbert by Scott Adams

[Tony Harminc]

On Mon, 28 Feb 2022 at 15:25, Leonard D Woren 
wrote:

> When a certain horrible 2-letter company acquired acf2, they did a
> global change in the manuals from 'product' to 'solution'.
> Occasionally made for some interesting sentences.
>

Solutionion?

Tony H.

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

Re: Certificates ,extKeyUsage and Criticality flag

[Charles Mills]

Okay. Well, good luck.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Michael Babcock
Sent: Monday, February 28, 2022 4:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Certificates ,extKeyUsage and Criticality flag

CICS is the client, ZCEE is the server.  I got a new CICS SITE certificate
that includes clientAuth and serverAuth.   I’ve gotten further but run into
another issue.  I’ve opened a case with IBM.  Thanks for the assistance.

On Mon, Feb 28, 2022 at 5:21 PM Charles Mills  wrote:

> Trying to follow this.
>
> Who connects to who? (I'm not knowledgeable about ZCEE.) Is ZCEE the
> client (initiator of the connection) and CICS the server? If so, then CICS
> needs a *server* certificate and the lack of clientAuth is not the problem
> -- not with that certificate anyway.
>
> If CICS is configured for client certificate authentication -- that's
> always a *server* option, not a configuration option at the client end --
> then ZCEE has to present a certificate that proves its identity, and CICS
> would need access to a local trusted chain that signs that certificate.
> THAT certificate would need or potentially need clientAuth. And presumably
> CICS would check that identity against some list of permitted clients.
>
> > IF the app recognizes the extension AND the flag
> > is FALSE, is it REQUIRED to honor restrictions
>
> Well, for your purposes, it doesn't really matter what it is required to
> do, does it? Certainly it is at least permitted to do so -- otherwise what
> the heck would be the purpose or function of the extension? And at least
> apparently from your description, that is what it is doing. (And FWIW, I
> *think* yes, it is required to honor an extension that it understands, even
> if not critical.)
>
> Although I *suspect* perhaps there is some sort of confusion here over
> what certificate is in error, and in what way.
>
> As I tried to say earlier, the function of "critical" is to say "if you do
> NOT understand this extension then you are required to reject the
> certificate."
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Michael Babcock
> Sent: Monday, February 28, 2022 11:32 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Certificates ,extKeyUsage and Criticality flag
>
> I know which cert has the problem.  It's the CICS SITE certificate which
> has serverAuth only in the extKeyUsage extension.
>
> What I'm trying to understand is IF the criticality flag is false AND
> the app recognizes the extension is it REQUIRED to honor the
> restrictions of said extension (if indeed there are restrictions).
>
>  From what I've read, IF the app DOES NOT recognize the extension and IF
> the flag is TRUE, then the app MUST reject the cert.  Further, IF the
> app DOES NOT recognize the extension AND the flag is FALSE, then the app
> can IGNORE the extension.  However, I cannot determine (or comprehend
> what I'm reading) that IF the app recognizes the extension AND the flag
> is FALSE, is it REQUIRED to honor restrictions (or is it simply up to
> the app to make a decision - honor or not).
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Michael Babcock
OneMain Financial
z/OS Systems Programmer, Lead

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

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

Re: JES2, meaning of parameter value codes

[Seymour J Metz]

What is unclear? nn is any two digit number. jccc is any character string 
that is a valid ddname. PROCnn or Jccc names a concatenation that can be 
selected as the procedure library concatenation for a job, as specified by 
JOBCLASS(v), JOBCLASS(STC), JOBCLASS(TSU) or  /*JOBPARM PROCLIB=ddname. You 
need to look at the JES2 JCL, any PROCLIB(foo) statement in the initialization 
member and any subsequent commands, e.g., $ADD PROCLIB, to see what is in each 
concatenation.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Monday, February 28, 2022 7:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JES2, meaning of parameter value codes

https://www.ibm.com/docs/en/zos/2.5.0?topic=class-parameter-description-jobclassclassstctsu

PROCLIB=nn|j|00
Specifies the default 2-8 character procedure library name (jccc) or 
procedure library number (0-99) which is to be used for this job class. It 
allows you to specify procedure libraries for different job classes. In the 
JES2 procedure, one DD statement must be named PROC00. If you specify 
additional procedure libraries (jccc or 01-99), then you might associate 
these libraries to a job class by replacing the jccc or nn of this 
parameter with the appropriate procedure library name or number. All cataloged 
procedure libraries to be used by jobs, time-sharing users, or system tasks 
must be defined in the JES2 procedure.

z/OS 2.5


From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Monday, February 28, 2022 5:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: JES2, meaning of parameter value codes

Please post example and release level.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Monday, February 28, 2022 6:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES2, meaning of parameter value codes

I am looking at the JES2 Initialization and Tuning Reference.  There are 
examples job parameters with codes such as "jxxx" and "jccc".  I can't 
seem to find a table of their meanings.  Can someone point me in the right 
direction?
Thanks,
Frank

--
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: Certificates ,extKeyUsage and Criticality flag

[Michael Babcock]

CICS is the client, ZCEE is the server.  I got a new CICS SITE certificate
that includes clientAuth and serverAuth.   I’ve gotten further but run into
another issue.  I’ve opened a case with IBM.  Thanks for the assistance.

On Mon, Feb 28, 2022 at 5:21 PM Charles Mills  wrote:

> Trying to follow this.
>
> Who connects to who? (I'm not knowledgeable about ZCEE.) Is ZCEE the
> client (initiator of the connection) and CICS the server? If so, then CICS
> needs a *server* certificate and the lack of clientAuth is not the problem
> -- not with that certificate anyway.
>
> If CICS is configured for client certificate authentication -- that's
> always a *server* option, not a configuration option at the client end --
> then ZCEE has to present a certificate that proves its identity, and CICS
> would need access to a local trusted chain that signs that certificate.
> THAT certificate would need or potentially need clientAuth. And presumably
> CICS would check that identity against some list of permitted clients.
>
> > IF the app recognizes the extension AND the flag
> > is FALSE, is it REQUIRED to honor restrictions
>
> Well, for your purposes, it doesn't really matter what it is required to
> do, does it? Certainly it is at least permitted to do so -- otherwise what
> the heck would be the purpose or function of the extension? And at least
> apparently from your description, that is what it is doing. (And FWIW, I
> *think* yes, it is required to honor an extension that it understands, even
> if not critical.)
>
> Although I *suspect* perhaps there is some sort of confusion here over
> what certificate is in error, and in what way.
>
> As I tried to say earlier, the function of "critical" is to say "if you do
> NOT understand this extension then you are required to reject the
> certificate."
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Michael Babcock
> Sent: Monday, February 28, 2022 11:32 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Certificates ,extKeyUsage and Criticality flag
>
> I know which cert has the problem.  It's the CICS SITE certificate which
> has serverAuth only in the extKeyUsage extension.
>
> What I'm trying to understand is IF the criticality flag is false AND
> the app recognizes the extension is it REQUIRED to honor the
> restrictions of said extension (if indeed there are restrictions).
>
>  From what I've read, IF the app DOES NOT recognize the extension and IF
> the flag is TRUE, then the app MUST reject the cert.  Further, IF the
> app DOES NOT recognize the extension AND the flag is FALSE, then the app
> can IGNORE the extension.  However, I cannot determine (or comprehend
> what I'm reading) that IF the app recognizes the extension AND the flag
> is FALSE, is it REQUIRED to honor restrictions (or is it simply up to
> the app to make a decision - honor or not).
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Michael Babcock
OneMain Financial
z/OS Systems Programmer, Lead

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

Re: JES2, meaning of parameter value codes

[Frank Swarbrick]

https://www.ibm.com/docs/en/zos/2.5.0?topic=class-parameter-description-jobclassclassstctsu

PROCLIB=nn|j|00
Specifies the default 2-8 character procedure library name (jccc) or 
procedure library number (0-99) which is to be used for this job class. It 
allows you to specify procedure libraries for different job classes. In the 
JES2 procedure, one DD statement must be named PROC00. If you specify 
additional procedure libraries (jccc or 01-99), then you might associate 
these libraries to a job class by replacing the jccc or nn of this 
parameter with the appropriate procedure library name or number. All cataloged 
procedure libraries to be used by jobs, time-sharing users, or system tasks 
must be defined in the JES2 procedure.

z/OS 2.5


From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Monday, February 28, 2022 5:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: JES2, meaning of parameter value codes

Please post example and release level.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Monday, February 28, 2022 6:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES2, meaning of parameter value codes

I am looking at the JES2 Initialization and Tuning Reference.  There are 
examples job parameters with codes such as "jxxx" and "jccc".  I can't 
seem to find a table of their meanings.  Can someone point me in the right 
direction?
Thanks,
Frank

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

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

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

Re: JES2, meaning of parameter value codes

[Seymour J Metz]

Please post example and release level.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Frank Swarbrick [frank.swarbr...@outlook.com]
Sent: Monday, February 28, 2022 6:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES2, meaning of parameter value codes

I am looking at the JES2 Initialization and Tuning Reference.  There are 
examples job parameters with codes such as "jxxx" and "jccc".  I can't 
seem to find a table of their meanings.  Can someone point me in the right 
direction?
Thanks,
Frank

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

JES2, meaning of parameter value codes

[Frank Swarbrick]

I am looking at the JES2 Initialization and Tuning Reference.  There are 
examples job parameters with codes such as "jxxx" and "jccc".  I can't 
seem to find a table of their meanings.  Can someone point me in the right 
direction?
Thanks,
Frank

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

Re: Certificates ,extKeyUsage and Criticality flag

[Charles Mills]

Trying to follow this.

Who connects to who? (I'm not knowledgeable about ZCEE.) Is ZCEE the client 
(initiator of the connection) and CICS the server? If so, then CICS needs a 
*server* certificate and the lack of clientAuth is not the problem -- not with 
that certificate anyway.

If CICS is configured for client certificate authentication -- that's always a 
*server* option, not a configuration option at the client end -- then ZCEE has 
to present a certificate that proves its identity, and CICS would need access 
to a local trusted chain that signs that certificate. THAT certificate would 
need or potentially need clientAuth. And presumably CICS would check that 
identity against some list of permitted clients.

> IF the app recognizes the extension AND the flag 
> is FALSE, is it REQUIRED to honor restrictions

Well, for your purposes, it doesn't really matter what it is required to do, 
does it? Certainly it is at least permitted to do so -- otherwise what the heck 
would be the purpose or function of the extension? And at least apparently from 
your description, that is what it is doing. (And FWIW, I *think* yes, it is 
required to honor an extension that it understands, even if not critical.)

Although I *suspect* perhaps there is some sort of confusion here over what 
certificate is in error, and in what way.

As I tried to say earlier, the function of "critical" is to say "if you do NOT 
understand this extension then you are required to reject the certificate."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Michael Babcock
Sent: Monday, February 28, 2022 11:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Certificates ,extKeyUsage and Criticality flag

I know which cert has the problem.  It's the CICS SITE certificate which 
has serverAuth only in the extKeyUsage extension.

What I'm trying to understand is IF the criticality flag is false AND 
the app recognizes the extension is it REQUIRED to honor the 
restrictions of said extension (if indeed there are restrictions).

 From what I've read, IF the app DOES NOT recognize the extension and IF 
the flag is TRUE, then the app MUST reject the cert.  Further, IF the 
app DOES NOT recognize the extension AND the flag is FALSE, then the app 
can IGNORE the extension.  However, I cannot determine (or comprehend 
what I'm reading) that IF the app recognizes the extension AND the flag 
is FALSE, is it REQUIRED to honor restrictions (or is it simply up to 
the app to make a decision - honor or not).

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

Re: Solutions Not Problems - Dilbert Comic Strip on 2022-02-25 | Dilbert by Scott Adams

[Leonard D Woren]

When a certain horrible 2-letter company acquired acf2, they did a 
global change in the manuals from 'product' to 'solution'.  
Occasionally made for some interesting sentences.


/Leonard

Art Gutowski wrote on 2/26/2022 8:04 PM:

On Fri, 25 Feb 2022 16:19:21 -0500, Mark Regan  wrote:


https://dilbert.com/strip/2022-02-25

Priceless.  I once knew a manager who insisted on calling bugs "opportunities".  To wit, 
a colleague responded, "Sure, a bug is an opportunity...if you're a frog."

Cheers,
Art Gutowski

--
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: Certificates ,extKeyUsage and Criticality flag

[Michael Babcock]

I know which cert has the problem.  It's the CICS SITE certificate which 
has serverAuth only in the extKeyUsage extension.


What I'm trying to understand is IF the criticality flag is false AND 
the app recognizes the extension is it REQUIRED to honor the 
restrictions of said extension (if indeed there are restrictions).


From what I've read, IF the app DOES NOT recognize the extension and IF 
the flag is TRUE, then the app MUST reject the cert.  Further, IF the 
app DOES NOT recognize the extension AND the flag is FALSE, then the app 
can IGNORE the extension.  However, I cannot determine (or comprehend 
what I'm reading) that IF the app recognizes the extension AND the flag 
is FALSE, is it REQUIRED to honor restrictions (or is it simply up to 
the app to make a decision - honor or not).


On 2/28/2022 9:51 AM, Colin Paice wrote:

My reading of this is, the certificate sent *from the client *(not sent
down from the server) does not have Client set in the EKU.
I blogged

on TLS, and said

The Extended Key Usage (EKU) indicates the purpose, or what the certificate
public key can be used for.

- A client certificate needs extendedKeyUsage = clientAuth
- A server certificate needs extendedKeyUsage = serverAuth.

Check which certificate has the problem,
Colin

On Mon, 28 Feb 2022 at 14:55, Michael Babcock  wrote:


To all you certificate experts out there:

We have z/OS Connect EE (ZCEE) installed and are running into an issue
with our CICS SITE certificate.  We are getting the following during a
handshake from CICS to ZCEE:

"Extended key usage does not permit use for TLS client authentication"

The CICS certificate is a SITE cert and has the extKeyUsage extension
defined with serverAuth and the criticality flag set to false.  What the
message is indicating is that we need to have
clientAuth as well as serverAuth in the extKeyusage field.  I understand
that part.

My question is "since the criticality flag is set to false" should ZCEE
honor that extension and enforce the restriction?"  Or is it up to the
application to honor that particular extension and enforce
the restrictions even though the criticality flag is false?   I
understand that if the flag is true the application MUST honor/enforce
the restrictions.

Can someone enlighten me?

--
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: XEDIT assembler continuation lines

[Seymour J Metz]

Maybe compatibility with EDIT. XEDIT came out with VM/SP R2, and by then 3270s 
were ubiquitous.

Maybe an RFE is in order for a mode in which the TRUNC column applies to 
editing commands bu not to input from the keyboard.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Alan Altmark [alan_altm...@us.ibm.com]
Sent: Monday, February 28, 2022 12:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XEDIT assembler continuation lines

On Wed, 23 Feb 2022 17:47:31 +, Seymour J Metz  wrote:
>Bummer. Maybe someone from IBM can shed light on the issue.

I speculate that this was to prevent INSERT and CHANGE from overlaying column 
72 by accident when editing in line mode.  When you're ready to put in 
continuation characters, do  TRUNC 72 # CL :72 # COVERLAY X # REPEAT n # TRUNC 
71.

Naturally we all updated our profiles once 3270s showed up, so it turned into a 
non-issue.

Alan Altmark
IBM

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

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

Re: XEDIT assembler continuation lines

[Tony Thigpen]

FYI,

Prior to converting from a System-3 to a 4331 running DOS/VS, IBM 
dropped a line-mode remote terminal into our shop. This would be about 
1981. We edited programs and JCL using it for about 4 months before we 
finally got our 4331.


Until this discussion, I had kinda forgotten this experience. Alan's 
comments paged those memories back into main storage. Having used a 
remote line-mode terminal, I now understand the history of TRUNC 71.


Tony Thigpen

Paul Gilmartin wrote on 2/28/22 10:04:

On Sun, 27 Feb 2022 23:27:51 -0600, Alan Altmark wrote:


On Wed, 23 Feb 2022 17:47:31 +, Seymour J Metz wrote:

Bummer. Maybe someone from IBM can shed light on the issue.


I speculate that this was to prevent INSERT and CHANGE from overlaying column 
72 by accident when editing in line mode.  When you're ready to put in 
continuation characters, do  TRUNC 72 # CL :72 # COVERLAY X # REPEAT n # TRUNC 
71.


AYFK‽  I'll assume that was a macro, perhaps a PF key.

Wouldn't it be useful if after marking the continuation it inserted a following
blank line to contain the rest of the statement?


Naturally we all updated our profiles once 3270s showed up, so it turned into a 
non-issue.


What had you used previously?  A command line editor?

Will the tyranny of the 026 and 701 ever be overthrown?  Has anyone submitted
an RFE to incorporate FLOWASM into HLASM; even make it the default?

--
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: 2.5 Heads Up

[Tony Harminc]

On Mon, 28 Feb 2022 at 10:50, Ed Jaffe  wrote:

> On 2/28/2022 5:21 AM, Allan Staller wrote:
>
> > Peter,
> > Can you post the trap?
>
>
> https://www.ibm.com/docs/en/zos/2.5.0?topic=traps-slip-zero-address-detection-zad
>

"ZAD is not supported on z/OS under z/VM. ":-(

Is there any SOD or RFE or the like for this?

Tony H.

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

Re: AUXLIST (was XEDIT equivalent to ISPF C - OO/OO (copy overlay))

[Phil Smith III]

Shmuel wrote:

>Your guess is worth what I paid for it. I started on the 3277 back when the
competition was the 2260 and am at home with 3270 data streams.

 

>What you wrote was "this will mean a new application *cannot* use existing
hardware,", which isn't even close to saying that you need dual paths, and
is false.

 

One more time: I've clarified what I meant. You're stuck on that. I'm done
here.


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

Re: 2.5 Heads Up

[Allan Staller]

Classification: Confidential

Thanks Ed


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: Monday, February 28, 2022 9:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

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

On 2/28/2022 5:21 AM, Allan Staller wrote:
> Classification: Confidential
>
> Peter,
> Can you post the trap?

https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzos%2F2.5.0%3Ftopic%3Dtraps-slip-zero-address-detection-zad&data=04%7C01%7Callan.staller%40HCL.COM%7Cd60027a37a5b4957dd5f08d9fad20ec3%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637816602673605564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=GoPgZ8w1Ynntt8rWiiG%2BztOg3rgfM4Xm4PzE4i4Jklo%3D&reserved=0


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.phoenixsoftware.com%2F&data=04%7C01%7Callan.staller%40HCL.COM%7Cd60027a37a5b4957dd5f08d9fad20ec3%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637816602673605564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=CTOJkEDHyvY52vfujY%2FDa4P4IaohF7Vdarnj8I%2BS3r4%3D&reserved=0



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

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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


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

Re: Certificates ,extKeyUsage and Criticality flag

[Colin Paice]

My reading of this is, the certificate sent *from the client *(not sent
down from the server) does not have Client set in the EKU.
I blogged

on TLS, and said

The Extended Key Usage (EKU) indicates the purpose, or what the certificate
public key can be used for.

   - A client certificate needs extendedKeyUsage = clientAuth
   - A server certificate needs extendedKeyUsage = serverAuth.

Check which certificate has the problem,
Colin

On Mon, 28 Feb 2022 at 14:55, Michael Babcock  wrote:

> To all you certificate experts out there:
>
> We have z/OS Connect EE (ZCEE) installed and are running into an issue
> with our CICS SITE certificate.  We are getting the following during a
> handshake from CICS to ZCEE:
>
> "Extended key usage does not permit use for TLS client authentication"
>
> The CICS certificate is a SITE cert and has the extKeyUsage extension
> defined with serverAuth and the criticality flag set to false.  What the
> message is indicating is that we need to have
> clientAuth as well as serverAuth in the extKeyusage field.  I understand
> that part.
>
> My question is "since the criticality flag is set to false" should ZCEE
> honor that extension and enforce the restriction?"  Or is it up to the
> application to honor that particular extension and enforce
> the restrictions even though the criticality flag is false?   I
> understand that if the flag is true the application MUST honor/enforce
> the restrictions.
>
> Can someone enlighten me?
>
> --
> 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: 2.5 Heads Up

[Ed Jaffe]

On 2/28/2022 5:21 AM, Allan Staller wrote:

Classification: Confidential

Peter,
Can you post the trap?


https://www.ibm.com/docs/en/zos/2.5.0?topic=traps-slip-zero-address-detection-zad


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



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

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

Re: XEDIT assembler continuation lines

[Paul Gilmartin]

On Sun, 27 Feb 2022 23:27:51 -0600, Alan Altmark wrote:

>On Wed, 23 Feb 2022 17:47:31 +, Seymour J Metz wrote:
>>Bummer. Maybe someone from IBM can shed light on the issue.
>
>I speculate that this was to prevent INSERT and CHANGE from overlaying column 
>72 by accident when editing in line mode.  When you're ready to put in 
>continuation characters, do  TRUNC 72 # CL :72 # COVERLAY X # REPEAT n # TRUNC 
>71.  
> 
AYFK‽  I'll assume that was a macro, perhaps a PF key.

Wouldn't it be useful if after marking the continuation it inserted a following
blank line to contain the rest of the statement?

>Naturally we all updated our profiles once 3270s showed up, so it turned into 
>a non-issue.
>
What had you used previously?  A command line editor?

Will the tyranny of the 026 and 701 ever be overthrown?  Has anyone submitted
an RFE to incorporate FLOWASM into HLASM; even make it the default?

-- 
gil

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

Re: Certificates ,extKeyUsage and Criticality flag

[Charles Mills]

The criticality flag means "if you are too back-level to recognize this new 
extension then you must reject the certificate."

A TLS implementation that recognizes the extension should always honor it.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Michael Babcock
Sent: Monday, February 28, 2022 6:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Certificates ,extKeyUsage and Criticality flag

To all you certificate experts out there:

We have z/OS Connect EE (ZCEE) installed and are running into an issue 
with our CICS SITE certificate.  We are getting the following during a 
handshake from CICS to ZCEE:

"Extended key usage does not permit use for TLS client authentication"

The CICS certificate is a SITE cert and has the extKeyUsage extension 
defined with serverAuth and the criticality flag set to false.  What the 
message is indicating is that we need to have
clientAuth as well as serverAuth in the extKeyusage field.  I understand 
that part.

My question is "since the criticality flag is set to false" should ZCEE 
honor that extension and enforce the restriction?"  Or is it up to the 
application to honor that particular extension and enforce
the restrictions even though the criticality flag is false?   I 
understand that if the flag is true the application MUST honor/enforce 
the restrictions.

Can someone enlighten me?

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

Certificates ,extKeyUsage and Criticality flag

[Michael Babcock]

To all you certificate experts out there:

We have z/OS Connect EE (ZCEE) installed and are running into an issue 
with our CICS SITE certificate.  We are getting the following during a 
handshake from CICS to ZCEE:


"Extended key usage does not permit use for TLS client authentication"

The CICS certificate is a SITE cert and has the extKeyUsage extension 
defined with serverAuth and the criticality flag set to false.  What the 
message is indicating is that we need to have
clientAuth as well as serverAuth in the extKeyusage field.  I understand 
that part.


My question is "since the criticality flag is set to false" should ZCEE 
honor that extension and enforce the restriction?"  Or is it up to the 
application to honor that particular extension and enforce
the restrictions even though the criticality flag is false?   I 
understand that if the flag is true the application MUST honor/enforce 
the restrictions.


Can someone enlighten me?

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

Re: 2.5 Heads Up

[Allan Staller]

Classification: Confidential

Peter,
Can you post the trap?

Thanks in advance,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter Relson
Sent: Saturday, February 26, 2022 7:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

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

You apparently also do not run with Zero Address Detection activated (a SLIP 
ZAD trap).
You should strongly consider doing so.

As to "the cat's out of the bag": a bag of IBM+ISV's is a pretty big bag.
You use undocumented things at your own risk.

Peter Relson
z/OS Core Technology Design


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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


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