Re: z/OS 2.1 to 2.4 [EXTERNAL]

[Brian Westerman]

Yes, you need to have current maintenance on your old 2.1 system, but your 
ability to fall back based on what you have stated in your response makes it so 
that your fallback (if necessary) will not be an issue for you.  Depending on 
your product mix, I think that SAG might have a simple work around for you for 
allowusekeycsa(yes), and so long as you are using the Version 8 SVC (which 
still supports version 7 Adabas products like cluster services and parallel 
services) you will be okay for all but a small number of products.  There are 
some products that you will have to update but they are likely minor in your 
case (older EntireX Brokers), at least they should be because very little 
depends on the actual release of the broker.  There are some special PPT 
entries you have to perform as well that depend on your products, but there is 
an SAG page that tell you all of them.

The only problem you will hit is with Natural, which needs to be at 4.2.4 to 
not need the allowuserkeycsa(yes), this will require SAG's ASM to do this, but 
I think it's free.  

I have performed several upgrades to old levels of Adabas (back to version 7.1) 
for just the Natural component, and they are truly dead simple, and if done 
correctly won't require you to recatalog everything in the natural libraries 
either (at least not manually depending on how far back you are).  Plus, again 
with proper planning, you have a fallback that you can implement within a few 
minutes.  Remember if you upgrade Natural, you still have to install ASM.  The 
suggested solution SAG is to install ASM Authorized Services Manager with all 
versions of Natural that use the older buffer pools and want to convert to 
allowuserkeycsa(no).

Brian

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

Re: Assembler :- PC Instruction

[Jon Perryman]

 > What you describe as being able to run code in any 

> address space sounds more like scheduling an SRB.


SRB is one method to execute authorized code in any address space but surely 
you must be familiar with others such as SVC, PC and IEFSSREQ. Or are you 
suggesting that getmain and storage macro's somehow use an SRB to execute 
authorized code in any address space?

Jon. 

On Friday, August 30, 2019, 08:08:32 AM PDT, Tom Marchant 
<000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:  
 
 On Thu, 29 Aug 2019 20:59:02 +, Jon Perryman wrote:

>As for "executing authorized code in other address spaces", I actually meant 
>any address space.

What do you mean by that? A PC instruction can pass control to code 
in a specific address space, as defined when the PC routine was 
established. What you describe as being able to run code in any 
address space sounds more like scheduling an SRB.

  

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

Global Foundary sues TSMC for patent infringement

[Edward Finnell]

https://uk.reuters.com/article/uk-globalfoundries-tsmc-lawsuit/globalfoundries-sues-tsmc-wants-u-s-import-ban-on-some-products-idUKKCN1VH0WE

tinyfied:https://tinyurl.com/y55sr58n

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

Re: Case TS002648607 (PMR 76523,082,000) - Compiler abend

[Charles Mills]

And then your successor can modify and debug it!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Friday, August 30, 2019 3:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Case TS002648607 (PMR 76523,082,000) - Compiler abend

Swift is even smarter.  It seems like even a newline doesn't absolutely
indicate the end of a statement, as long as the compiler can infer that a
statement absolutely has not completed.  You can (but I don't recommend it)
even do something like this:

let
a
=
1
print (
a
)

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

Re: Case TS002648607 (PMR 76523,082,000) - Compiler abend

[Frank Swarbrick]

Swift is even smarter.  It seems like even a newline doesn't absolutely 
indicate the end of a statement, as long as the compiler can infer that a 
statement absolutely has not completed.  You can (but I don't recommend it) 
even do something like this:

let
a
=
1
print (
a
)



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Friday, August 30, 2019 4:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Case TS002648607 (PMR 76523,082,000) - Compiler abend

On Fri, 30 Aug 2019 17:33:56 +, Seymour J Metz wrote:

>Be careful what you ask for - you might get it. It's one of the things that I 
>don't like about REXX.
>
>ObHamlet "And make us rather bear those semicolons we have, then fly to 
>continuation conventions that we know not of"
>
( C 'then' 'than')

Why?  I find Rexx pleasantly consistent there:
An instruction is terminated by:
o A newline not preceded by a comma
o Or a semicolon
Spaces are irrelevant
Newline and semicolon are highly interchangeable.

Compare POSIX shell conventions.  Are they even documented?  For example:
542 $ for I in 1 2
> do
> echo $I
> done
OK, but:
544 $ for I in 1 2; do; echo $I; done
-sh: syntax error near unexpected token `;'

-- 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: Case TS002648607 (PMR 76523,082,000) - Compiler abend

[scott Ford]

Gil,

I agree with you on Rexx, writing it since it first came out on VM.
Some of the other languages are a bit funky.

Scott

On Fri, Aug 30, 2019 at 6:04 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 30 Aug 2019 17:33:56 +, Seymour J Metz wrote:
>
> >Be careful what you ask for - you might get it. It's one of the things
> that I don't like about REXX.
> >
> >ObHamlet "And make us rather bear those semicolons we have, then fly to
> continuation conventions that we know not of"
> >
> ( C 'then' 'than')
>
> Why?  I find Rexx pleasantly consistent there:
> An instruction is terminated by:
> o A newline not preceded by a comma
> o Or a semicolon
> Spaces are irrelevant
> Newline and semicolon are highly interchangeable.
>
> Compare POSIX shell conventions.  Are they even documented?  For example:
> 542 $ for I in 1 2
> > do
> > echo $I
> > done
> OK, but:
> 544 $ for I in 1 2; do; echo $I; done
> -sh: syntax error near unexpected token `;'
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: Case TS002648607 (PMR 76523,082,000) - Compiler abend

[Paul Gilmartin]

On Fri, 30 Aug 2019 17:33:56 +, Seymour J Metz wrote:

>Be careful what you ask for - you might get it. It's one of the things that I 
>don't like about REXX.
>
>ObHamlet "And make us rather bear those semicolons we have, then fly to 
>continuation conventions that we know not of"
>
( C 'then' 'than')

Why?  I find Rexx pleasantly consistent there:
An instruction is terminated by:
o A newline not preceded by a comma
o Or a semicolon
Spaces are irrelevant
Newline and semicolon are highly interchangeable.

Compare POSIX shell conventions.  Are they even documented?  For example:
542 $ for I in 1 2
> do
> echo $I
> done
OK, but:
544 $ for I in 1 2; do; echo $I; done
-sh: syntax error near unexpected token `;'

-- gil

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

Re: Migrate MQ from 7.0.1 to 9.1

[Andy Cooper]

Thank you, David.

Very good information for Dana.  And "NEWFUNC" was the parm I couldn't recall 
off the top of my head.  :-)


Andy

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

Re: vendor distributes their private key

[Christian Svensson]

Fwiw,

For client authentication we ask our clients to send us a Certificate
Signing Request for the keypair they want to use, and we sign them using
our internal Client Authentication CA. We set the CN and other options to
what we want for our systems to authorize them correctly, and then send the
client the resulting certificate back.

We never see their private key, and we have full control of validity of
their certificate (revocation and expiration).

On Fri, Aug 30, 2019, 10:15 Charles Mills  wrote:

> Andrew, that's a good thought. I'm not knowledgeable enough to tell
> whether it is perfect from a cryptographic point of view or not.
>
> FWIW though, that is not how X.509 standard client authentication works.
> It works the way I described, in accordance with RFC 5246 7.4.6.
>
> Passwords work, and are obviously THE most common form of client
> authentication. I think a primary usage of client certificate
> authentication is with unattended processes. (Think z/OS jobs!) There is no
> one available to key in a password, and passwords stored in files make the
> auditors very cranky.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Andrew Rowley
> Sent: Thursday, August 29, 2019 6:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: vendor distributes their private key
>
> On 29/08/2019 9:18 am, Charles Mills wrote:
>
> > But for certificate-based client authentication, the server admin must
> send the client admin a client certificate AND its private key. Why?
> Philosophically, because a client certificate signed by a trusted CA does
> not prove the authenticity of the client. A man-in-the-middle might have
> previously intercepted the certificate and now be sending it out from HIS
> client as its own.
>
> This doesn't sound right somehow. I suspect it is often implemented that
> way, but it sounds worse than password authentication with a good password.
>
> --
> 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: Clarification on DASD mod conversion of SYSRES

[Gibney, Dave]

Many of our tailored members are apply to all four of my LPARs and reside in 
SYS1.WSU.PARMLIB
LPAR specific members are in SYS1.lparname.PARMLIB
Changes are first IPL'd in SYS1.lparname.PARMLIB.OVERRIDE

Which is where I was before the migration to FNTS, so
Changed, common members where in SYS1.FNTS.PARMLIB
And changed LPAR members in SYS!.FNTS.lparname.PARMLIB. 

I should (and have many) moved the migration members further down. On the other 
hand, I've only IPL'd production twice since my migration IPL in December 2017.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Jousma, David
> Sent: Friday, August 30, 2019 10:54 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Clarification on DASD mod conversion of SYSRES
> 
> Holy parmlibs batman!!!   Why on earth so many?
> 
> __
> ___
> Dave Jousma
> AVP | Manager, Systems Engineering
> 
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, 
> MI
> 49546
> 616.653.8429  |  fax: 616.653.2717
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Gibney, Dave
> Sent: Friday, August 30, 2019 1:48 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Clarification on DASD mod conversion of SYSRES
> 
> **CAUTION EXTERNAL EMAIL**
> 
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
> 
> I learned this from Skip, I think at my first SHARE. IMHO, SYS1.PARMLIB
> should be on SYSRES and EMPTY. SYS1.IBM.PARMLIB, on SYSRES and SMP/E
> maintained.
> My current production parmlib concatenation is:
> 
> PARMLIB  SYS1.FNTS.WSUMVS1.PARMLIBWSUFNT
> PARMLIB  SYS1.FNTS.PARMLIB WSUFNT
> PARMLIB  SYS1.WSUMVS1.PARMLIB.OVERRIDEPARM01
> PARMLIB  SYS1.WSUMVS1.PARMLIB PARM01
> PARMLIB  SYS1.WSU.PARMLIB   IODF00
> PARMLIB  SYS1.IBM.PARMLIB  **
> PARMLIB  SYS1.PARMLIB **
> 
> When I migrated from local to MFaaS at FNTS, I only changed a couple
> members.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Jesse 1 Robinson
> > Sent: Friday, August 30, 2019 9:28 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Clarification on DASD mod conversion of SYSRES
> >
> > I'd like to address a question implied in this thread: where should I
> > put the installation 'business' PARMLIB, that is, the data set that
> > typically contains
> > 90+% of all required members, which are often tailored and do not
> > 90+change at
> > all from release to release. I would argue strongly in favor of
> > putting this PARMLIB on some sysprog-owned volume *away* from the
> ServerPac set.
> > Some reasons and a war story.
> >
> > -- This user-created and managed PARMLIB will not be unexpectedly
> > updated by PTF.
> >
> > -- This PARMLIB can contain IBM-, ISV-, and installation-owned members.
> >
> > -- This PARMLIB requires little in the way of updates, any one of
> > which could possibly finger-check into failure on the next IPL.
> >
> > The story. In a previous life, we kept the business PARMLIB on sysres.
> > The VTAM guy made a critical change on a remote system shortly before
> IPL.
> > Then we switched sysres to a PARMLIB that did not have this change.
> > VTAM would not come up. The data center was 400 miles away. It was
> > before TCP/IP. Fixing the problem would be trivial if only we could
> > log on. The only staff on site were operators. We were facing a long
> > drive up the California coast just to submit a simple job. We were
> > finally able to talk an operator through editing up a job (local
> > non-SNA 3270) and submitting it, which corrected the problem.
> >
> > Of course we should have had better 'procedures'. Good luck with that.
> >
> > .
> > .
> > J.O.Skip Robinson
> > Southern California Edison Company
> > Electric Dragon Team Paddler
> > SHARE MVS Program Co-Manager
> > 323-715-0595 Mobile
> > 626-543-6132 Office ⇐=== NEW
> > robin...@sce.com
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Brian Westerman
> > Sent: Friday, August 30, 2019 12:13 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: (External):Re: Clarification on DASD mod conversion of SYSRES
> >
> > You can't IPL with the IPL datasets cataloged to , it fails if
> > you try to set
> >  to something in IEASYMxx.  The same is true if you try to use a
> > symbolic for the catalog volume(s) (assuming it's separate from the
> > res volume(s)), but I think that issue is the ICF catalogs themselves.
> > You can however catalog normal non-vsam datasets to any symbol you
> > want so long as you identify it in the IEASYMxx member.  I ALWAYS
> > catalog ALL my DLIB and some VENDOR volumes that way, it makes life
> > (and 

Re: Clarification on DASD mod conversion of SYSRES

[Jousma, David]

Holy parmlibs batman!!!   Why on earth so many?

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gibney, Dave
Sent: Friday, August 30, 2019 1:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Clarification on DASD mod conversion of SYSRES

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I learned this from Skip, I think at my first SHARE. IMHO, SYS1.PARMLIB should 
be on SYSRES and EMPTY. SYS1.IBM.PARMLIB, on SYSRES and SMP/E maintained.  
My current production parmlib concatenation is:  

PARMLIB  SYS1.FNTS.WSUMVS1.PARMLIBWSUFNT  
PARMLIB  SYS1.FNTS.PARMLIB   WSUFNT  
PARMLIB  SYS1.WSUMVS1.PARMLIB.OVERRIDEPARM01  
PARMLIB  SYS1.WSUMVS1.PARMLIB PARM01  
PARMLIB  SYS1.WSU.PARMLIB IODF00  
PARMLIB  SYS1.IBM.PARMLIB**  
PARMLIB  SYS1.PARMLIB   **   

When I migrated from local to MFaaS at FNTS, I only changed a couple members. 

> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Jesse 1 Robinson
> Sent: Friday, August 30, 2019 9:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Clarification on DASD mod conversion of SYSRES
> 
> I'd like to address a question implied in this thread: where should I 
> put the installation 'business' PARMLIB, that is, the data set that 
> typically contains
> 90+% of all required members, which are often tailored and do not 
> 90+change at
> all from release to release. I would argue strongly in favor of 
> putting this PARMLIB on some sysprog-owned volume *away* from the ServerPac 
> set.
> Some reasons and a war story.
> 
> -- This user-created and managed PARMLIB will not be unexpectedly 
> updated by PTF.
> 
> -- This PARMLIB can contain IBM-, ISV-, and installation-owned members.
> 
> -- This PARMLIB requires little in the way of updates, any one of 
> which could possibly finger-check into failure on the next IPL.
> 
> The story. In a previous life, we kept the business PARMLIB on sysres. 
> The VTAM guy made a critical change on a remote system shortly before IPL.
> Then we switched sysres to a PARMLIB that did not have this change. 
> VTAM would not come up. The data center was 400 miles away. It was 
> before TCP/IP. Fixing the problem would be trivial if only we could 
> log on. The only staff on site were operators. We were facing a long 
> drive up the California coast just to submit a simple job. We were 
> finally able to talk an operator through editing up a job (local 
> non-SNA 3270) and submitting it, which corrected the problem.
> 
> Of course we should have had better 'procedures'. Good luck with that.
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Brian Westerman
> Sent: Friday, August 30, 2019 12:13 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Clarification on DASD mod conversion of SYSRES
> 
> You can't IPL with the IPL datasets cataloged to , it fails if 
> you try to set
>  to something in IEASYMxx.  The same is true if you try to use a 
> symbolic for the catalog volume(s) (assuming it's separate from the 
> res volume(s)), but I think that issue is the ICF catalogs themselves.  
> You can however catalog normal non-vsam datasets to any symbol you 
> want so long as you identify it in the IEASYMxx member.  I ALWAYS 
> catalog ALL my DLIB and some VENDOR volumes that way, it makes life 
> (and maintenance) a lot easier to be able to change the volsers.
> 
> (i.e. one of the sites I manage has their current IPL vols as is 
> C23RS1 (which has every cataloged as **) , C23RS2 ( which has 
> everything cataloged to
> ) and C23DL1 (which has everything cataloged to ) , 
> C23DL2 (same format but )  and C23DL3 (same format but 
> ), and the next one will be D23RS1, and D23RS2, D23DL1, D23DL2 
> and D23DL3.  There is no re cataloging of datasets necessary, I just 
> change the IEASYMxx member and everything is where it needs to be.  My 
> Backup SYSRES's are C23RSA and C23RSB and again, I just point the IPL 
> to C23RSA and IEASYMxx is changed to point  to C23RSB and everything is 
> set yo IPL and go.
> 
> The names of the volumes themselves can be whatever I want to make 
> them easy to remember in an emergency, they could be 11 and 22 
> and the process would be the same.
> 
> It's very 

Re: Clarification on DASD mod conversion of SYSRES

[Gibney, Dave]

I learned this from Skip, I think at my first SHARE. IMHO, SYS1.PARMLIB should 
be on SYSRES and EMPTY. SYS1.IBM.PARMLIB, on SYSRES and SMP/E maintained.  
My current production parmlib concatenation is:  

PARMLIB  SYS1.FNTS.WSUMVS1.PARMLIBWSUFNT  
PARMLIB  SYS1.FNTS.PARMLIB   WSUFNT  
PARMLIB  SYS1.WSUMVS1.PARMLIB.OVERRIDEPARM01  
PARMLIB  SYS1.WSUMVS1.PARMLIB PARM01  
PARMLIB  SYS1.WSU.PARMLIB IODF00  
PARMLIB  SYS1.IBM.PARMLIB**  
PARMLIB  SYS1.PARMLIB   **   

When I migrated from local to MFaaS at FNTS, I only changed a couple members. 

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Jesse 1 Robinson
> Sent: Friday, August 30, 2019 9:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Clarification on DASD mod conversion of SYSRES
> 
> I'd like to address a question implied in this thread: where should I put the
> installation 'business' PARMLIB, that is, the data set that typically contains
> 90+% of all required members, which are often tailored and do not change at
> all from release to release. I would argue strongly in favor of putting this
> PARMLIB on some sysprog-owned volume *away* from the ServerPac set.
> Some reasons and a war story.
> 
> -- This user-created and managed PARMLIB will not be unexpectedly
> updated by PTF.
> 
> -- This PARMLIB can contain IBM-, ISV-, and installation-owned members.
> 
> -- This PARMLIB requires little in the way of updates, any one of which could
> possibly finger-check into failure on the next IPL.
> 
> The story. In a previous life, we kept the business PARMLIB on sysres. The
> VTAM guy made a critical change on a remote system shortly before IPL.
> Then we switched sysres to a PARMLIB that did not have this change. VTAM
> would not come up. The data center was 400 miles away. It was before
> TCP/IP. Fixing the problem would be trivial if only we could log on. The only
> staff on site were operators. We were facing a long drive up the California
> coast just to submit a simple job. We were finally able to talk an operator
> through editing up a job (local non-SNA 3270) and submitting it, which
> corrected the problem.
> 
> Of course we should have had better 'procedures'. Good luck with that.
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Brian Westerman
> Sent: Friday, August 30, 2019 12:13 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Clarification on DASD mod conversion of SYSRES
> 
> You can't IPL with the IPL datasets cataloged to , it fails if you try 
> to set
>  to something in IEASYMxx.  The same is true if you try to use a
> symbolic for the catalog volume(s) (assuming it's separate from the res
> volume(s)), but I think that issue is the ICF catalogs themselves.  You can
> however catalog normal non-vsam datasets to any symbol you want so long
> as you identify it in the IEASYMxx member.  I ALWAYS catalog ALL my DLIB
> and some VENDOR volumes that way, it makes life (and maintenance) a lot
> easier to be able to change the volsers.
> 
> (i.e. one of the sites I manage has their current IPL vols as is C23RS1 (which
> has every cataloged as **) , C23RS2 ( which has everything cataloged to
> ) and C23DL1 (which has everything cataloged to ) , C23DL2
> (same format but )  and C23DL3 (same format but ), and the
> next one will be D23RS1, and D23RS2, D23DL1, D23DL2 and D23DL3.  There is
> no re cataloging of datasets necessary, I just change the IEASYMxx member
> and everything is where it needs to be.  My Backup SYSRES's are C23RSA and
> C23RSB and again, I just point the IPL to C23RSA and IEASYMxx is changed to
> point  to C23RSB and everything is set yo IPL and go.
> 
> The names of the volumes themselves can be whatever I want to make
> them easy to remember in an emergency, they could be 11 and 22
> and the process would be the same.
> 
> It's very easy to do maintenance this way.
> 
> Brian
> 
> 
> --
> 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: Case TS002648607 (PMR 76523,082,000) - Compiler abend

[Seymour J Metz]

Be careful what you ask for - you might get it. It's one of the things that I 
don't like about REXX.

ObHamlet "And make us rather bear those semicolons we have, then fly to 
continuation conventions that we know not of"


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



From: IBM Mainframe Discussion List  on behalf of 
Frank Swarbrick 
Sent: Thursday, August 29, 2019 5:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Case TS002648607 (PMR 76523,082,000) - Compiler abend

One reason to love Swift.  No semicolons required!!!


From: IBM Mainframe Discussion List  on behalf of 
Matt Hogstrom 
Sent: Thursday, August 29, 2019 12:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Case TS002648607 (PMR 76523,082,000) - Compiler abend

I always knew semi-colons were dangerous.  Most people butcher their usage in 
grammar and now abends … who knows what mischief they will stir up next.

Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook 

  LinkedIn 

  Twitter 


“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

> On Aug 29, 2019, at 1:37 PM, Charles Mills  wrote:
>
> Amazing!
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Joseph Reichman
> Sent: Thursday, August 29, 2019 10:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Fwd: Case TS002648607 (PMR 76523,082,000) - Compiler abend
>
> Begin forwarded message:
>
>> From: "Basil Kanneth" 
>> Date: August 29, 2019 at 11:01:57 AM EDT
>> To: "Joseph Reichman" 
>> Subject: RE: Case TS002648607 (PMR 76523,082,000) - Compiler abend
>>
>> Hi Joseph,
>>
>> It turns out the system protection exception occurred because of a missing 
>> semicolon after the following line in the code:
>> typedef int (DLL_FN)(char *)
>>
>> So it should be:
>> typedef int (DLL_FN)(char *);
>>
>> If you make the above changes, your test case should compile fine.
>>
>> We agree the compiler should not abend in this situation and we are 
>> investigating a potential fix.
>>
>> I will provide you with another update by Thursday, September 5th, 2019.
>>
>> Regards,
>> 
>> Basil Kanneth, PMP®
>> IBM XL C,C++, Fortran & COBOL Compilers Service Team
>> IBM Software Group - Toronto Lab

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

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


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

Re: z/OS 2.1 to 2.4 [EXTERNAL]

[Gibney, Dave]

I will have all available (and RSU,IBM or Hiper) maintenance on. And, yes 
fallback is one of my larger concerns. 
One  of my least favorite memories from the early 90s is standalone restore of 
catalog and SMS control dataset volumes between failed IPLs without proper 
fallback PTFs on. I think we were making a large jump to MVS/ESA 2.5, but I 
won't swear to that.
Actual SLED and the 3090 took 40 minutes to IPL after and before each failure. 
It was quite the learning experience and I've tried to do things "right" ever 
since.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Pommier, Rex
> Sent: Friday, August 30, 2019 8:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL]
> 
> Tom,
> 
> The idea is to apply 2.1 maintenance that would make 2.1 compatible with
> 2.3.  Since IBM won't release 2.4 compatibility maintenance for 2.1, if 
> there's
> some that would make 2.1 co-exist with 2.3, that might make it easier for the
> OP to make the jump from 2.1 to 2.4.
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Tom Marchant
> Sent: Friday, August 30, 2019 10:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL]
> 
> On Fri, 30 Aug 2019 10:48:03 +, Feller, Paul wrote:
> 
> Would it be a good thing to at least try to get any z/OS 2.3 compatibility
> maintenance applied?
> 
> What does that mean to someone who is running z/OS 2.1?
> You can't apply a z/OS 2.3 PTF to a z/OS 2.1 system.
> 
> --
> Tom Marchant
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> The information contained in this message is confidential, protected from
> disclosure and may be legally privileged.  If the reader of this message is 
> not
> the intended recipient or an employee or agent responsible for delivering
> this message to the intended recipient, you are hereby notified that any
> disclosure, distribution, copying, or any action taken or action omitted in
> reliance on it, is strictly prohibited and may be unlawful.  If you have 
> received
> this communication in error, please notify us immediately by replying to this
> message and destroy the material in its entirety, whether in electronic or
> hard copy format.  Thank you.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue

[Farley, Peter x23353]

Problem resolved.  Programmer error or ECC memory check in the programmer's 
brain (take your pick).

The "global application library" is actually TWO libraries, one PDSE (current 
application target library) and one PDS (modules not recently recompiled).  The 
E15 / E35 exit programs are located in the PDSE library.  Adding that library 
second in the STEPLIB using MODS with no DD name allows the alternate version 
in the first STEPLIB library allows the alternate version to be loaded.

Apologies for wasted bandwidth and no disrespect to the vendor.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter x23353
Sent: Friday, August 30, 2019 11:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue

Thanks Peter.  In this case both exit programs are resident in LINKLIST and the 
global application library in LINKLIST is (AFAIK) also LLA/VLF managed.

The precise sequence is a little more complicated than I first thought.  Here 
is the sequence:

JCL Invokes SYNCSORT
SYNCSORT invokes COBOL EXIT program from LINKLIST library
COBOL EXIT program dynamically calls assembler subroutine (also in LINKLIST 
global application library)
Assembler subroutine LOAD's a "data" load module containing a small amount of 
application-specific data and displays that data via WTO.

The "data" load modules are the ones that are incorrectly coming from LINKLIST 
instead of from MODLIB/STEPLIB/JOBLIB where I provide an alternate version of 
the "data".  The LINKLIST version of the "data" module is always loaded.

I will open an issue with the vendor on this.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter Relson
Sent: Friday, August 30, 2019 8:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue

I know nothing about SYNCSORT, but it is possible (and if so they should
document) that the way they ask the system to fetch the module specifically 
indicates not to use tasklib/steplib/joblib. When the system does that it is 
typically to be using its copy of the named module rather than someone else's 
(since you'd have to out of your way, for example, to get your copy into LPA or 
ahead of the system's copy in the LNKLST. Since in your case it is "your 
module", such program logic would seem kind of strange.

Peter Relson
z/OS Core Technology Design
--

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

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

Re: Assembler :- PC Instruction

[Seymour J Metz]

Their meaning was vague in the 1950s. Try using MIPS to compare the performance 
of a 704 and 704 without knowing the workload.


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



From: IBM Mainframe Discussion List  on behalf of 
Vernooij, Kees (ITOP NM) - KLM 
Sent: Friday, August 30, 2019 3:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler :- PC Instruction

A little less I think.
I remember their meaning became vague when comparing performance and MIPS of 
Amdahl and IBM machines gave unexplainable differences during the 80's.
And when IBM started putting more functionality into an instruction, if was 
definitely renamed to Meaningless Indicator of Processor Speed.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Seymour J Metz
> Sent: 29 August, 2019 19:04
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Assembler :- PC Instruction
>
> SVC itself performs a simple function. SVC together with  its interrupt
> handlers is not so simple. What with the serialization for the GETMAIN or
> whatever it uses these days, I'd expect it to be at least as expensive as
> PC. If you need to operate in another address space, add in the overhead
> of acquiring, scheduling and freeing SRBs.
>
> > The times that machine performance could be expressed in Million
> Instructions Per Second are long gone.
>
>
> They've been gone for half a century, if they ever existed.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Vernooij, Kees (ITOP NM) - KLM 
> Sent: Thursday, August 29, 2019 8:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Assembler :- PC Instruction
>
> "against SVC plus the SVC interrupt handler".
> Possibly also: Plus SVC code?
> The SVC instruction performs a function, the PC instruction does too.
>
> From what I understood of the PC instruction: with 1 instruction you can
> now execute a 'function' that might have taken pages of assembler
> instructions before.
>
> The times that machine performance could be expressed in Million
> Instructions Per Second are long gone.
>
> Kees.
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Peter Relson
> > Sent: 29 August, 2019 13:45
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Assembler :- PC Instruction
> >
> > 
> > You can do a BASR and STORAGE OBTAIN, STORAGE RELEASE and BR in less
> time
> > than a BAKR.
> > 
> >
> > No you can't.
> >
> > 
> > How does its performance stack up against SVC?
> > 
> >
> > That's not a useful comparison. What is useful is "how does its
> > performance stack up against SVC plus the SVC interrupt handler".
> >
> > Peter Relson
> > z/OS Core Technology Design
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://secure-web.cisco.com/1SDiyZznrzneuHMlVlorXfTN4MTOpKavy-U7CQXEF7Om1cw7VKvBjMioACkhSTdJ1UnT0iDSIquIbZapsrpfepa_vxpOjTUhLmTFVYyX8-WUvuITkLgcyQSfx70Z0S1L32cpQemqODSaxoEapfhZJJFgHMr4DIg0lLch-REK7PAtQBFbQeMqmiNaONF0Q9oouQ66ESvhUuR7h4qumKtr8gqNkU55CHeadMTwQaTFxq8o2o4E1w1Sity7ZnmLgUss1CZ4CSDC5BA6oVAezdvnolPJdO3B2Q8IuilFkIrrrOeygikyBnH2nbnpkNCyzAIX0HK379LjyMP_MlC4IW_p_xt80CSihKm2wQeeqdQ9FySf76x4sM9Yo17aeOy3Cm-hd9UR_GRjyAv49alg08lumuRTxlZxx76WGjT12MdnIrVQ/http%3A%2F%2Fsecure-
> web.cisco.com/1yFCMng_oi34MeuWoGQVFSplOg6fpaFLyxdbGdQb9STPypzNLAxj2z3H1yPe
> 4hmcGsoQrveXhGIGpIQn4y5avwq7BULLqLr7LDIdVd3uZfyPSdpqKPZLOf85a9_UOdAfEEkGjP
> nXcTp7oZjO72UlCrOrkWCx9XGTouvxIvkrdhdxx7mbiJCUcsSNwdIhGoKmSm_S4VqyCCu_-
> 5BvvEZ79ciMla-Ce6L9JM5Ftywxolu5eN46Eq6qEk2Cf-
> Zcs5T9IkVQzK7gnyAmr3_tZBL1XW1EDny_9mYCBo58WeWGmKDzZaHMjFOWAKa7le7wuJMXxvxG
> huhm_EyVpP7hsmqb89fuquitBk3uYlWjLHQFCW51CPwAUMtM3_g4RZTozHtzb/http%3A%2F%2
> Fhttp://secure-web.cisco.com/1AQKdY4EiF6WcU0D3keYzjZkkvl1a6EzqmnBNLIn4X5Fpyr6naYn2j3cK2vDIyJsRpJ8dy0XFV07AUcRzyOm9vfesfF5N18Nyxc6Fb2ihZ4V9dzLkGZvO_e8LJX2zmAzPdyMciW-NYkwSFEMrbhRuigmI1OLsiM3Lk9SK_MFWdRRUw8QzWdl7Da15Uos1aiQ5iAZecQ2V5eykSp_OvNAOOWoJMiNhW1U__9eVmVGlmRtNGiJi2mmiovMjYSppmRFCqA9sPEmpSPY-E5q8hSnkHWF2W6QNid1IxGFsWnhvsf1f2dzjLYL3zqOWMDpI51nN_BxkZ9BiGcw7jOmaVk9zwwhbrQb2_0BqZWIl2nX7kcb482OaSCWurfQYBbKrp0IyXE6RdP1MNHo1k8VCms7kH9LNPSd32LhpxKPIvDc-XbX9ptaIm63pSt1F-43plwSm/http%3A%2F%2Fwww.klm.com.
>  This e-mail and any attachment may contain confidential and
> privileged material intended for the addressee only. If you are not the
> addressee, you are notified that no part of the e-mail or any attachment
> may be disclosed, copied or distributed, and that any other action related
> to this e-mail or attachment is 

Re: Assembler :- PC Instruction

[Seymour J Metz]

I interpreted "might have taken pages of assembler instructions" as referring 
to GETMAIN, FREEMAIN and linkage needed in conjunction with the BALR. With 
PC/PR the registers are saved and restored with no additional user code.


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



From: IBM Mainframe Discussion List  on behalf of 
Peter Relson 
Sent: Friday, August 30, 2019 8:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler :- PC Instruction


>From what I understood of the PC instruction: with 1 instruction you can
now execute a 'function' that might have taken pages of assembler
instructions before.


I'm not sure where this thought comes from. The PC instruction is not
magic. It does not execute a "function" beyond the function of the
instruction itself.
It passes control somewhere, may change state, may create an entry on the
linkage stack.

Peter Relson
z/OS Core Technology Design


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

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

Re: z/OS 2.1 to 2.4 [EXTERNAL]

[David Spiegel]

Hi Paul,
The buzzword you are hinting at is called "Toleration Maintenance".

Regards,
David

On 2019-08-30 12:39, Feller, Paul wrote:
> Sorry if my wording was off a little.  But yes the idea is to apply any z/OS 
> 2.1 fixes needed related to support of z/OS 2.3.  That would get you nearer 
> to a system that might allow for fall back from z/OS 2.4.  I'm sure IBM would 
> suggest a two step approach.  Install z/OS 2.3 as soon as possible and then 
> go to z/OS 2.4 later.
>
> Thanks..
>
> Paul Feller
> AGT Mainframe Technical Support
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Pommier, Rex
> Sent: Friday, August 30, 2019 10:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL]
>
> Tom,
>
> The idea is to apply 2.1 maintenance that would make 2.1 compatible with 2.3. 
>  Since IBM won't release 2.4 compatibility maintenance for 2.1, if there's 
> some that would make 2.1 co-exist with 2.3, that might make it easier for the 
> OP to make the jump from 2.1 to 2.4.
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Tom Marchant
> Sent: Friday, August 30, 2019 10:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL]
>
> On Fri, 30 Aug 2019 10:48:03 +, Feller, Paul wrote:
>
> Would it be a good thing to at least try to get any z/OS 2.3 compatibility 
> maintenance applied?
>
> What does that mean to someone who is running z/OS 2.1?
> You can't apply a z/OS 2.3 PTF to a z/OS 2.1 system.
>
> --
> Tom Marchant
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> The information contained in this message is confidential, protected from 
> disclosure and may be legally privileged.  If the reader of this message is 
> not the intended recipient or an employee or agent responsible for delivering 
> this message to the intended recipient, you are hereby notified that any 
> disclosure, distribution, copying, or any action taken or action omitted in 
> reliance on it, is strictly prohibited and may be unlawful.  If you have 
> received this communication in error, please notify us immediately by 
> replying to this message and destroy the material in its entirety, whether in 
> electronic or hard copy format.  Thank you.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


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

Re: vendor distributes their private key

[Charles Mills]

Andrew, that's a good thought. I'm not knowledgeable enough to tell whether it 
is perfect from a cryptographic point of view or not.

FWIW though, that is not how X.509 standard client authentication works. It 
works the way I described, in accordance with RFC 5246 7.4.6.

Passwords work, and are obviously THE most common form of client 
authentication. I think a primary usage of client certificate authentication is 
with unattended processes. (Think z/OS jobs!) There is no one available to key 
in a password, and passwords stored in files make the auditors very cranky.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Andrew Rowley
Sent: Thursday, August 29, 2019 6:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: vendor distributes their private key

On 29/08/2019 9:18 am, Charles Mills wrote:

> But for certificate-based client authentication, the server admin must send 
> the client admin a client certificate AND its private key. Why? 
> Philosophically, because a client certificate signed by a trusted CA does not 
> prove the authenticity of the client. A man-in-the-middle might have 
> previously intercepted the certificate and now be sending it out from HIS 
> client as its own.

This doesn't sound right somehow. I suspect it is often implemented that 
way, but it sounds worse than password authentication with a good password.

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

Re: An acronym that doesn't start with the word Mother

[Charles Mills]

Third party vendors also offer pure mainframe-based MFA. I am slightly familiar 
with an offering from Vanguard, for example.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jim Mooney
Sent: Friday, August 30, 2019 7:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: MFA: An acronym that doesn't start with the word Mother

We've been asked to implement MFA on the zOS Mainframe. I've read some threads 
on here, and it seems some have implemented IBM's MFA solution on zOS, and some 
have implemented MFA on 'winders.'

The zOS solution is pricey so we are looking at alternatives. My question is: 
Does a windows implementation (tied to AD) meet audit requirements requiring 
MFA on the mainframe? IOW, can the requirement be met with MFA running on 
another platform?

We currently use RSA Secure server for VPN access and could possibly leverage 
that for all MF access.

Our security people are doing a POC on something called PAM (Privilege Access 
Mgmt/windows) to secure the mainframe, and I would like to make sure they are 
not taking a wrong turn. So any input from those ahead of us on this path would 
be very helpful. Thanks for looking. 

-Jim

--
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: Assembler :- PC Instruction

[Charles Mills]

"A PC can execute what might have taken many instructions before" is true in
the same sense that it is true for BAL: one instruction that you code goes
off and does a bunch of stuff elsewhere, saving you having to code all those
instructions.

It is also true in the sense that a PC can do in one instruction what would
have taken a whole series of instructions before: switching AMODE, switching
problem state, and branching.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Friday, August 30, 2019 5:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler :- PC Instruction


>From what I understood of the PC instruction: with 1 instruction you can 
now execute a 'function' that might have taken pages of assembler 
instructions before. 


I'm not sure where this thought comes from. The PC instruction is not 
magic. It does not execute a "function" beyond the function of the 
instruction itself.
It passes control somewhere, may change state, may create an entry on the 
linkage stack.

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

Re: Clarification on DASD mod conversion of SYSRES

[Seymour J Metz]

I would put it outside of the target zone but would keep a close tab on IBM 
changes that you potentially might want to mirror.


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

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

Re: Clarification on DASD mod conversion of SYSRES

[Jousma, David]

Agreed!   Our parmlib concatenation consist of the business parmlib that 
resides on MCAT pack, followed by the serverpack provided sys1.ibm.parmlib.
The sys1.parmlib from serverpack never gets used in our shop, except to take a 
peek at what IBM thinks we should do on something.

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jesse 1 Robinson
Sent: Friday, August 30, 2019 12:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Clarification on DASD mod conversion of SYSRES

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I'd like to address a question implied in this thread: where should I put the 
installation 'business' PARMLIB, that is, the data set that typically contains 
90+% of all required members, which are often tailored and do not change at all 
from release to release. I would argue strongly in favor of putting this 
PARMLIB on some sysprog-owned volume *away* from the ServerPac set. Some 
reasons and a war story.

-- This user-created and managed PARMLIB will not be unexpectedly updated by 
PTF. 

-- This PARMLIB can contain IBM-, ISV-, and installation-owned members. 

-- This PARMLIB requires little in the way of updates, any one of which could 
possibly finger-check into failure on the next IPL. 

The story. In a previous life, we kept the business PARMLIB on sysres. The VTAM 
guy made a critical change on a remote system shortly before IPL. Then we 
switched sysres to a PARMLIB that did not have this change. VTAM would not come 
up. The data center was 400 miles away. It was before TCP/IP. Fixing the 
problem would be trivial if only we could log on. The only staff on site were 
operators. We were facing a long drive up the California coast just to submit a 
simple job. We were finally able to talk an operator through editing up a job 
(local non-SNA 3270) and submitting it, which corrected the problem. 

Of course we should have had better 'procedures'. Good luck with that. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian Westerman
Sent: Friday, August 30, 2019 12:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Clarification on DASD mod conversion of SYSRES

You can't IPL with the IPL datasets cataloged to , it fails if you try to 
set  to something in IEASYMxx.  The same is true if you try to use a 
symbolic for the catalog volume(s) (assuming it's separate from the res 
volume(s)), but I think that issue is the ICF catalogs themselves.  You can 
however catalog normal non-vsam datasets to any symbol you want so long as you 
identify it in the IEASYMxx member.  I ALWAYS catalog ALL my DLIB and some 
VENDOR volumes that way, it makes life (and maintenance) a lot easier to be 
able to change the volsers.  

(i.e. one of the sites I manage has their current IPL vols as is C23RS1 (which 
has every cataloged as **) , C23RS2 ( which has everything cataloged to 
) and C23DL1 (which has everything cataloged to ) , C23DL2 (same 
format but )  and C23DL3 (same format but ), and the next one 
will be D23RS1, and D23RS2, D23DL1, D23DL2 and D23DL3.  There is no re 
cataloging of datasets necessary, I just change the IEASYMxx member and 
everything is where it needs to be.  My Backup SYSRES's are C23RSA and C23RSB 
and again, I just point the IPL to C23RSA and IEASYMxx is changed to point 
 to C23RSB and everything is set yo IPL and go.

The names of the volumes themselves can be whatever I want to make them easy to 
remember in an emergency, they could be 11 and 22 and the process would 
be the same.

It's very easy to do maintenance this way.

Brian


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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

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

Re: z/OS 2.1 to 2.4 [EXTERNAL]

[Feller, Paul]

Sorry if my wording was off a little.  But yes the idea is to apply any z/OS 
2.1 fixes needed related to support of z/OS 2.3.  That would get you nearer to 
a system that might allow for fall back from z/OS 2.4.  I'm sure IBM would 
suggest a two step approach.  Install z/OS 2.3 as soon as possible and then go 
to z/OS 2.4 later.

Thanks..

Paul Feller
AGT Mainframe Technical Support


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pommier, Rex
Sent: Friday, August 30, 2019 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL]

Tom,

The idea is to apply 2.1 maintenance that would make 2.1 compatible with 2.3.  
Since IBM won't release 2.4 compatibility maintenance for 2.1, if there's some 
that would make 2.1 co-exist with 2.3, that might make it easier for the OP to 
make the jump from 2.1 to 2.4.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Friday, August 30, 2019 10:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL]

On Fri, 30 Aug 2019 10:48:03 +, Feller, Paul wrote:

Would it be a good thing to at least try to get any z/OS 2.3 compatibility 
maintenance applied?

What does that mean to someone who is running z/OS 2.1?
You can't apply a z/OS 2.3 PTF to a z/OS 2.1 system.

--
Tom Marchant

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


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


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

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

Re: Clarification on DASD mod conversion of SYSRES

[Jesse 1 Robinson]

I'd like to address a question implied in this thread: where should I put the 
installation 'business' PARMLIB, that is, the data set that typically contains 
90+% of all required members, which are often tailored and do not change at all 
from release to release. I would argue strongly in favor of putting this 
PARMLIB on some sysprog-owned volume *away* from the ServerPac set. Some 
reasons and a war story.

-- This user-created and managed PARMLIB will not be unexpectedly updated by 
PTF. 

-- This PARMLIB can contain IBM-, ISV-, and installation-owned members. 

-- This PARMLIB requires little in the way of updates, any one of which could 
possibly finger-check into failure on the next IPL. 

The story. In a previous life, we kept the business PARMLIB on sysres. The VTAM 
guy made a critical change on a remote system shortly before IPL. Then we 
switched sysres to a PARMLIB that did not have this change. VTAM would not come 
up. The data center was 400 miles away. It was before TCP/IP. Fixing the 
problem would be trivial if only we could log on. The only staff on site were 
operators. We were facing a long drive up the California coast just to submit a 
simple job. We were finally able to talk an operator through editing up a job 
(local non-SNA 3270) and submitting it, which corrected the problem. 

Of course we should have had better 'procedures'. Good luck with that. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian Westerman
Sent: Friday, August 30, 2019 12:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Clarification on DASD mod conversion of SYSRES

You can't IPL with the IPL datasets cataloged to , it fails if you try to 
set  to something in IEASYMxx.  The same is true if you try to use a 
symbolic for the catalog volume(s) (assuming it's separate from the res 
volume(s)), but I think that issue is the ICF catalogs themselves.  You can 
however catalog normal non-vsam datasets to any symbol you want so long as you 
identify it in the IEASYMxx member.  I ALWAYS catalog ALL my DLIB and some 
VENDOR volumes that way, it makes life (and maintenance) a lot easier to be 
able to change the volsers.  

(i.e. one of the sites I manage has their current IPL vols as is C23RS1 (which 
has every cataloged as **) , C23RS2 ( which has everything cataloged to 
) and C23DL1 (which has everything cataloged to ) , C23DL2 (same 
format but )  and C23DL3 (same format but ), and the next one 
will be D23RS1, and D23RS2, D23DL1, D23DL2 and D23DL3.  There is no re 
cataloging of datasets necessary, I just change the IEASYMxx member and 
everything is where it needs to be.  My Backup SYSRES's are C23RSA and C23RSB 
and again, I just point the IPL to C23RSA and IEASYMxx is changed to point 
 to C23RSB and everything is set yo IPL and go.

The names of the volumes themselves can be whatever I want to make them easy to 
remember in an emergency, they could be 11 and 22 and the process would 
be the same.

It's very easy to do maintenance this way.

Brian


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

Re: z/OS 2.1 to 2.4

[Martin Packer]

The analogy is with iOS apps. The ones you'd ideally want to use are those 
where the vendor is beta'ing iOS 13 (actually 13.1.)

Cheers, Martin

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   "Jousma, David" <01a0403c5dc1-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   30/08/2019 16:19
Subject:Re: z/OS 2.1 to 2.4
Sent by:IBM Mainframe Discussion List 



Yea  That vendor until recently was still developing on z/OS 1.13 
until this summer when they made the jump to 2.2 or maybe 2.3.   We are 
already at V2.3, and really don’t want to skip a release or delay, 
although that is an option I guess.   It's just a bit short sighted on the 
vendors part to think they can hold their customers hostage like this. 

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
Rapids, MI 49546
616.653.8429  |  fax: 616.653.2717



-Original Message-
From: IBM Mainframe Discussion List  On Behalf 
Of Mike Schwab
Sent: Friday, August 30, 2019 10:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.1 to 2.4

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or 
unexpected emails**

On Fri, Aug 30, 2019 at 6:49 AM Elardus Engelbrecht 
 wrote:
>
> Jousma, David wrote:
>
> >Elardus, yea, I took quite a bit of vacation this summer
>
[deleted]
> Good luck. (While I'm also waiting for z/OS v2.4 to be made 
> available... ;-D )
>
> Groete / Greetings
> Elardus Engelbrecht
>
Well, the quick fix is to Order now and Upgrade soon to z/OS 2.3, then 
upgrade to 2.4 or 2.5 later on.  And advise the application company to 
suggest this to their other customers.

--
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 **CAUTION 
EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or 
unexpected emails**

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


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



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: z/OS 2.1 to 2.4 [EXTERNAL]

[Pommier, Rex]

Tom,

The idea is to apply 2.1 maintenance that would make 2.1 compatible with 2.3.  
Since IBM won't release 2.4 compatibility maintenance for 2.1, if there's some 
that would make 2.1 co-exist with 2.3, that might make it easier for the OP to 
make the jump from 2.1 to 2.4.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Friday, August 30, 2019 10:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL]

On Fri, 30 Aug 2019 10:48:03 +, Feller, Paul wrote:

Would it be a good thing to at least try to get any z/OS 2.3 compatibility 
maintenance applied?

What does that mean to someone who is running z/OS 2.1?
You can't apply a z/OS 2.3 PTF to a z/OS 2.1 system.

--
Tom Marchant

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


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


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

Re: z/OS 2.1 to 2.4 [EXTERNAL]

[Tom Marchant]

On Fri, 30 Aug 2019 10:48:03 +, Feller, Paul wrote:

Would it be a good thing to at least try to get any z/OS 2.3 compatibility 
maintenance applied?

What does that mean to someone who is running z/OS 2.1?
You can't apply a z/OS 2.3 PTF to a z/OS 2.1 system.

-- 
Tom Marchant

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

Re: z/OS 2.1 to 2.4

[Jousma, David]

Yea  That vendor until recently was still developing on z/OS 1.13 until 
this summer when they made the jump to 2.2 or maybe 2.3.   We are already at 
V2.3, and really don’t want to skip a release or delay, although that is an 
option I guess.   It's just a bit short sighted on the vendors part to think 
they can hold their customers hostage like this.   

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Friday, August 30, 2019 10:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.1 to 2.4

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

On Fri, Aug 30, 2019 at 6:49 AM Elardus Engelbrecht 
 wrote:
>
> Jousma, David wrote:
>
> >Elardus, yea, I took quite a bit of vacation this summer
>
[deleted]
> Good luck. (While I'm also waiting for z/OS v2.4 to be made 
> available... ;-D )
>
> Groete / Greetings
> Elardus Engelbrecht
>
Well, the quick fix is to Order now and Upgrade soon to z/OS 2.3, then upgrade 
to 2.4 or 2.5 later on.  And advise the application company to suggest this to 
their other customers.

--
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 **CAUTION EXTERNAL 
EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

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


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

Re: SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue

[Farley, Peter x23353]

Thanks Massimo, I did try that and got the same results - only the LINKLIST 
version gets loaded even when the MODS statement uses a specific DD name.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Massimo Biancucci
Sent: Friday, August 30, 2019 4:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue

Peter,

I've tried the same on a customer site running Syncsort 2.1.5.0R on zOS 2.3 and 
it seems everything works fine.

You can try (only a try) to code the DDNAME on E15/E35, add the DD with LOADLIB 
and see if anything changes.

MODS E15=(EXITE15M,2048000,MYDDN,C),E35=(EXITE35M,2048000,MYDDN,C)

Double check if PDS are in LLA/VLF and finally open an issue to Syncsort.

Good luck.
Max
--

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


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

Re: SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue

[Farley, Peter x23353]

Thanks Peter.  In this case both exit programs are resident in LINKLIST and the 
global application library in LINKLIST is (AFAIK) also LLA/VLF managed.

The precise sequence is a little more complicated than I first thought.  Here 
is the sequence:

JCL Invokes SYNCSORT
SYNCSORT invokes COBOL EXIT program from LINKLIST library
COBOL EXIT program dynamically calls assembler subroutine (also in LINKLIST 
global application library)
Assembler subroutine LOAD's a "data" load module containing a small amount of 
application-specific data and displays that data via WTO.

The "data" load modules are the ones that are incorrectly coming from LINKLIST 
instead of from MODLIB/STEPLIB/JOBLIB where I provide an alternate version of 
the "data".  The LINKLIST version of the "data" module is always loaded.

I will open an issue with the vendor on this.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter Relson
Sent: Friday, August 30, 2019 8:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue

I know nothing about SYNCSORT, but it is possible (and if so they should
document) that the way they ask the system to fetch the module specifically 
indicates not to use tasklib/steplib/joblib. When the system does that it is 
typically to be using its copy of the named module rather than someone else's 
(since you'd have to out of your way, for example, to get your copy into LPA or 
ahead of the system's copy in the LNKLST. Since in your case it is "your 
module", such program logic would seem kind of strange.

Peter Relson
z/OS Core Technology Design
--

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

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

Re: Assembler :- PC Instruction

[Tom Marchant]

On Thu, 29 Aug 2019 20:59:02 +, Jon Perryman wrote:

>As for "executing authorized code in other address spaces", I actually meant 
>any address space.

What do you mean by that? A PC instruction can pass control to code 
in a specific address space, as defined when the PC routine was 
established. What you describe as being able to run code in any 
address space sounds more like scheduling an SRB.

-- 
Tom Marchant

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

Re: Assembler :- PC Instruction

[Martin Packer]

Maybe he's talking about the more limited Primary and Secondary address 
spaces.

Cheers, Martin

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   30/08/2019 16:00
Subject:Re: Assembler :- PC Instruction
Sent by:IBM Mainframe Discussion List 



On Thu, 29 Aug 2019 19:56:57 -1000, Anne & Lynn Wheeler wrote:

>in the wake of the FS faulure (FS was going to be completely different
>than 370, and 370 efforts were being shutdown during FS period, also
>lack of 370 offerings during FS period is credited with giving clone
>mainframe vendors market foothold), there was mad rush to get stuff back
>into 370 product pipeline ... 303x and 3081 Q efforts were kicked off
>in parallel. 3081 included 370/xa, 31bit addressing and "access
>registers" (subsystems had their own virtual address space, but could
>use "access registers" to access "parameter" storage in application
>address space). All this was known informally as "811" for the Nov1978
>publication date of the architecture specification documents.

I don't know about IBM internal plans or discussions, but Access Registers 

and AR mode were not publicly announced as part of 370/XA. They were 
first documented in the Enterprise System Architecture/370 Principles of 
Operation, SA22-7200-0, which can be found at 
https://urldefense.proofpoint.com/v2/url?u=http-3A__bitsavers.trailing-2Dedge.com_pdf_ibm_370_princOps_SA22-2D7200-2D0-5F370-2DESA-5FPrinciples-5Fof-5FOperation-5FAug88.pdf=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=GjItMeo-vHych-AkF0VZDvBsdcmOPmD-rPThhcKZDsg=EnehEvQA2zc3fw8_iaVQ7p0AUMyW3J4EULsynDXB2cc=
 


Appendix D of that manual describes differences between 370-XA and 
ESA/370. On page D-1 it has this:


New Facilities in ESA/370
The following facilities are new in ESA/370 and are
not provided in 370-XA. Access registers, home
address space, linkage stack, and load and store
using real address are provided by all ESA/370
models. Move with source or destination key and
private space are provided by some ESA/370 models.


>
>In part because of the increasing threat of CSA increasing to 8mbytes
>for larger 3033 customers, a subset of "access registers" was
>retrofitted to 3033 as "dual-address space" mode ... subsystems could
>have their own address space, but also a 2nd address space to access
>calling application parameters directly ... w/o needing CSA space.
>
>In 370 (3033) dual-address space mode ... there still wasn't program
>call, but a supervisor call which in software would move the application
>space address space to secondary and then load the subsystem address
>space and enter the called subsystem. In 370/xa and "access register"
>program call had a system defined table with all the necessary
>information to do that function directly as part of the program call
>instruction (whether implemented in hardware, microcode, picocode and/or
>some combination)

To clarify a bit, there was no Linkage Stack until ESA/370, and hence no 
stacking PC.

-- 
Tom Marchant

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




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: Assembler :- PC Instruction

[Tom Marchant]

On Thu, 29 Aug 2019 19:56:57 -1000, Anne & Lynn Wheeler wrote:

>in the wake of the FS faulure (FS was going to be completely different
>than 370, and 370 efforts were being shutdown during FS period, also
>lack of 370 offerings during FS period is credited with giving clone
>mainframe vendors market foothold), there was mad rush to get stuff back
>into 370 product pipeline ... 303x and 3081 Q efforts were kicked off
>in parallel. 3081 included 370/xa, 31bit addressing and "access
>registers" (subsystems had their own virtual address space, but could
>use "access registers" to access "parameter" storage in application
>address space). All this was known informally as "811" for the Nov1978
>publication date of the architecture specification documents.

I don't know about IBM internal plans or discussions, but Access Registers 
and AR mode were not publicly announced as part of 370/XA. They were 
first documented in the Enterprise System Architecture/370 Principles of 
Operation, SA22-7200-0, which can be found at 
http://bitsavers.trailing-edge.com/pdf/ibm/370/princOps/SA22-7200-0_370-ESA_Principles_of_Operation_Aug88.pdf

Appendix D of that manual describes differences between 370-XA and ESA/370. On 
page D-1 it has this:


New Facilities in ESA/370
The following facilities are new in ESA/370 and are
not provided in 370-XA. Access registers, home
address space, linkage stack, and load and store
using real address are provided by all ESA/370
models. Move with source or destination key and
private space are provided by some ESA/370 models.


>
>In part because of the increasing threat of CSA increasing to 8mbytes
>for larger 3033 customers, a subset of "access registers" was
>retrofitted to 3033 as "dual-address space" mode ... subsystems could
>have their own address space, but also a 2nd address space to access
>calling application parameters directly ... w/o needing CSA space.
>
>In 370 (3033) dual-address space mode ... there still wasn't program
>call, but a supervisor call which in software would move the application
>space address space to secondary and then load the subsystem address
>space and enter the called subsystem. In 370/xa and "access register"
>program call had a system defined table with all the necessary
>information to do that function directly as part of the program call
>instruction (whether implemented in hardware, microcode, picocode and/or
>some combination)

To clarify a bit, there was no Linkage Stack until ESA/370, and hence no 
stacking PC.

-- 
Tom Marchant

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

Re: SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue

[Mike Schwab]

Exit loadlib should be listed in the MODLIB DD statement.

Page 380 / 4.27 in https://mysupport.syncsort.com/largefiles/mfx14pg.pdf

On Fri, Aug 30, 2019 at 7:19 AM Peter Relson  wrote:
>
> I know nothing about SYNCSORT, but it is possible (and if so they should
> document) that the way they ask the system to fetch the module
> specifically indicates not to use tasklib/steplib/joblib. When the system
> does that it is typically to be using its copy of the named module rather
> than someone else's (since you'd have to out of your way, for example, to
> get your copy into LPA or ahead of the system's copy in the LNKLST. Since
> in your case it is "your module", such program logic would seem kind of
> strange.
>
> 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



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

Re: z/OS 2.1 to 2.4

[Mike Schwab]

On Fri, Aug 30, 2019 at 6:49 AM Elardus Engelbrecht
 wrote:
>
> Jousma, David wrote:
>
> >Elardus, yea, I took quite a bit of vacation this summer
>
[deleted]
> Good luck. (While I'm also waiting for z/OS v2.4 to be made available... ;-D )
>
> Groete / Greetings
> Elardus Engelbrecht
>
Well, the quick fix is to Order now and Upgrade soon to z/OS 2.3, then
upgrade to 2.4 or 2.5 later on.  And advise the application company to
suggest this to their other customers.

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

Re: [External] Re: Clarification on DASD mod conversion of SYSRES

[Pommier, Rex]

Brian,

What datasets do you mean by "IPL datasets cataloged to "?  Everything on 
my SYSRES is cataloged to  except SYS1.PARMLIB and we IPL just fine.  
According to the 2.2 INIT & TUNING manual, changing  is not allowed in 
IEASYMxx at all.  The further documented restriction is that SYS1.PARMLIB 
cannot use  nor can any dataset defined in the LOADxx member being used 
unless the LOADxx member also has the vol-ser defined therein so the system can 
find it.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian Westerman
Sent: Friday, August 30, 2019 2:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Clarification on DASD mod conversion of SYSRES

You can't IPL with the IPL datasets cataloged to , it fails if you try to 
set  to something in IEASYMxx.  The same is true if you try to use a 
symbolic for the catalog volume(s) (assuming it's separate from the res 
volume(s)), but I think that issue is the ICF catalogs themselves.  You can 
however catalog normal non-vsam datasets to any symbol you want so long as you 
identify it in the IEASYMxx member.  I ALWAYS catalog ALL my DLIB and some 
VENDOR volumes that way, it makes life (and maintenance) a lot easier to be 
able to change the volsers.  

(i.e. one of the sites I manage has their current IPL vols as is C23RS1 (which 
has every cataloged as **) , C23RS2 ( which has everything cataloged to 
) and C23DL1 (which has everything cataloged to ) , C23DL2 (same 
format but )  and C23DL3 (same format but ), and the next one 
will be D23RS1, and D23RS2, D23DL1, D23DL2 and D23DL3.  There is no re 
cataloging of datasets necessary, I just change the IEASYMxx member and 
everything is where it needs to be.  My Backup SYSRES's are C23RSA and C23RSB 
and again, I just point the IPL to C23RSA and IEASYMxx is changed to point 
 to C23RSB and everything is set yo IPL and go.

The names of the volumes themselves can be whatever I want to make them easy to 
remember in an emergency, they could be 11 and 22 and the process would 
be the same.

It's very easy to do maintenance this way.

Brian

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


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


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

MFA: An acronym that doesn't start with the word Mother

[Jim Mooney]

We've been asked to implement MFA on the zOS Mainframe. I've read some threads 
on here, and it seems some have implemented IBM's MFA solution on zOS, and some 
have implemented MFA on 'winders.'

The zOS solution is pricey so we are looking at alternatives. My question is: 
Does a windows implementation (tied to AD) meet audit requirements requiring 
MFA on the mainframe? IOW, can the requirement be met with MFA running on 
another platform?

We currently use RSA Secure server for VPN access and could possibly leverage 
that for all MF access.

Our security people are doing a POC on something called PAM (Privilege Access 
Mgmt/windows) to secure the mainframe, and I would like to make sure they are 
not taking a wrong turn. So any input from those ahead of us on this path would 
be very helpful. Thanks for looking. 

-Jim

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

Re: Assembler :- PC Instruction

[Vernooij, Kees (ITOP NM) - KLM]

Peter,
Ok, than I misunderstood what was or could be put into the PC microcode.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Relson
> Sent: 30 August, 2019 14:25
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Assembler :- PC Instruction
> 
> 
> From what I understood of the PC instruction: with 1 instruction you can
> now execute a 'function' that might have taken pages of assembler
> instructions before.
> 
> 
> I'm not sure where this thought comes from. The PC instruction is not
> magic. It does not execute a "function" beyond the function of the
> instruction itself.
> It passes control somewhere, may change state, may create an entry on the
> linkage stack.
> 
> Peter Relson
> z/OS Core Technology Design
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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

Re: Assembler :- PC Instruction

[Peter Relson]

>From what I understood of the PC instruction: with 1 instruction you can 
now execute a 'function' that might have taken pages of assembler 
instructions before. 


I'm not sure where this thought comes from. The PC instruction is not 
magic. It does not execute a "function" beyond the function of the 
instruction itself.
It passes control somewhere, may change state, may create an entry on the 
linkage stack.

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

Re: SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue

[Peter Relson]

I know nothing about SYNCSORT, but it is possible (and if so they should 
document) that the way they ask the system to fetch the module 
specifically indicates not to use tasklib/steplib/joblib. When the system 
does that it is typically to be using its copy of the named module rather 
than someone else's (since you'd have to out of your way, for example, to 
get your copy into LPA or ahead of the system's copy in the LNKLST. Since 
in your case it is "your module", such program logic would seem kind of 
strange.

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

Re: z/OS 2.1 to 2.4

[Jousma, David]

Kees,

I fully agree!!!   I suspect there are quite a few banks that run this 
application.   When I had a meeting with these folks, I got the impression that 
there was may the "one guy left" that could delve into the assembler code that 
supports this.   

We are escalating the vendor now through our application team that owns the 
relationship with the vendor.

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Vernooij, Kees (ITOP NM) - KLM
Sent: Friday, August 30, 2019 7:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.1 to 2.4

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Yes, then it is the end for this application. 
But from your description I understand that there must be more customers who 
will have the 2.4 problem. Is this still no reason for the company to start 
converting to the current standards?

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Jousma, David
> Sent: 30 August, 2019 13:18
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> Well, my excitement was short-lived.In the text of OA56180 I read:
> 
> Note: This APAR only applies to user key CSA storage.  Both
>   user key (8-15) SCOPE=COMMON data spaces and the usage of
>   the CHANGKEY service to change the storage key of common
>   storage to a key of 8-15 are not affected by this APAR,
>   and will no longer be supported after z/OS V2R3.
> 
> 
> Sadly, this application is creating UserKey Common data space and 
> using it as a high-perf "data base" within the application for their batch 
> jobs.
> I've known about it since IBM enabled reporting via SMF30 records.
> 
> __
> 
> ___
> Dave Jousma
> AVP | Manager, Systems Engineering
> 
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
> Rapids, MI 49546
> 616.653.8429  |  fax: 616.653.2717
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Vernooij, Kees (ITOP NM) - KLM
> Sent: Friday, August 30, 2019 7:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> **CAUTION EXTERNAL EMAIL**
> 
> **DO NOT open attachments or click on links from unknown senders or 
> unexpected emails**
> 
> It does, because 2.4 does not support userkeycsa(yes) anymore. It is 
> also discussed in the 2.4 migration guide.
> 
> It seems to me the feature will stay, because IBM has fulfilled its 
> goal to block CSA from being used by unauthorized users with full 
> read/write access. Now you must selectively permit userkey csa to 
> users and it is now your responsibility.
> 
> Kees.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David
> > Sent: 30 August, 2019 12:47
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS 2.1 to 2.4
> >
> > Yea...  Funny thing it is a pretty major/well known Financial
> Application
> > vendor.   Every 4-6 months for the last two years I've been pinging them
> > on their status.   I just don’t think they understand the gravity of the
> > situation they are creating here.
> >
> > Also, I did open a PMR on this PTF.   It's not clear to me that the
> > support it discusses continues into V2.4?
> >
> > 
> > __
> > 
> > ___
> > Dave Jousma
> > AVP | Manager, Systems Engineering
> >
> > Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
> > Rapids, MI 49546
> > 616.653.8429  |  fax: 616.653.2717
> >
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On 
> > Behalf Of Mike Schwab
> > Sent: Friday, August 30, 2019 6:34 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS 2.1 to 2.4
> >
> > **CAUTION EXTERNAL EMAIL**
> >
> > **DO NOT open attachments or click on links from unknown senders or 
> > unexpected emails**
> >
> > I would ask they cover your cost for this as part of their product, 
> > since they are the only product you use that needs it.
> >
> > On Fri, Aug 30, 2019 at 5:20 AM Jousma, David 
> > <01a0403c5dc1-dmarc- requ...@listserv.ua.edu> wrote:
> > >
> > > This is the first I have seen this!   That is good news.  We have one
> > particular Financial Business application, written/distributed by 
> > outside vendor that I have been bugging now since I put V2.3 in 
> > almost 2
> years ago
> > to remediate.   They still have not yet remediated there code, and I was
> > thinking this was going 

Re: z/OS 2.1 to 2.4

[Elardus Engelbrecht]

Jousma, David wrote:

>Elardus, yea, I took quite a bit of vacation this summer  

Grrr, I'm so jealous! ;-)

But, I have been in a lot of projects and am now just lurking sniffing out the 
IBM-MAIN and other listserv posts on their websites... 


>I always suspend delivery of IBM-MAIL mail during that time, otherwise my 
>outlook email box would probably fill up.   :)

Due to quantity of daily posts of IBM-MAIN, I have turned of e-mails from 
IBM-MAIN. We at our work have a limit of 2GB on the Outlook Server to encourage 
people to properly manage their mails.

(We once have years ago GroupWise (called 'GroupStupid' tongue in cheek) and 
later Zimbra (called 'Zebra'))

Ok, back to this thread - I really hope you can sort out the problem with your 
vendor. If you have any good news, please be kind to share it.

Good luck. (While I'm also waiting for z/OS v2.4 to be made available... ;-D )

Groete / Greetings
Elardus Engelbrecht

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

Re: z/OS 2.1 to 2.4

[Vernooij, Kees (ITOP NM) - KLM]

Yes, then it is the end for this application. 
But from your description I understand that there must be more customers who 
will have the 2.4 problem. Is this still no reason for the company to start 
converting to the current standards?

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jousma, David
> Sent: 30 August, 2019 13:18
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> Well, my excitement was short-lived.In the text of OA56180 I read:
> 
> Note: This APAR only applies to user key CSA storage.  Both
>   user key (8-15) SCOPE=COMMON data spaces and the usage of
>   the CHANGKEY service to change the storage key of common
>   storage to a key of 8-15 are not affected by this APAR,
>   and will no longer be supported after z/OS V2R3.
> 
> 
> Sadly, this application is creating UserKey Common data space and using it
> as a high-perf "data base" within the application for their batch jobs.
> I've known about it since IBM enabled reporting via SMF30 records.
> 
> __
> ___
> Dave Jousma
> AVP | Manager, Systems Engineering
> 
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> Rapids, MI 49546
> 616.653.8429  |  fax: 616.653.2717
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Vernooij, Kees (ITOP NM) - KLM
> Sent: Friday, August 30, 2019 7:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> **CAUTION EXTERNAL EMAIL**
> 
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
> 
> It does, because 2.4 does not support userkeycsa(yes) anymore. It is also
> discussed in the 2.4 migration guide.
> 
> It seems to me the feature will stay, because IBM has fulfilled its goal
> to block CSA from being used by unauthorized users with full read/write
> access. Now you must selectively permit userkey csa to users and it is now
> your responsibility.
> 
> Kees.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Jousma, David
> > Sent: 30 August, 2019 12:47
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS 2.1 to 2.4
> >
> > Yea...  Funny thing it is a pretty major/well known Financial
> Application
> > vendor.   Every 4-6 months for the last two years I've been pinging them
> > on their status.   I just don’t think they understand the gravity of the
> > situation they are creating here.
> >
> > Also, I did open a PMR on this PTF.   It's not clear to me that the
> > support it discusses continues into V2.4?
> >
> > __
> > 
> > ___
> > Dave Jousma
> > AVP | Manager, Systems Engineering
> >
> > Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> > Rapids, MI 49546
> > 616.653.8429  |  fax: 616.653.2717
> >
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Mike Schwab
> > Sent: Friday, August 30, 2019 6:34 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS 2.1 to 2.4
> >
> > **CAUTION EXTERNAL EMAIL**
> >
> > **DO NOT open attachments or click on links from unknown senders or
> > unexpected emails**
> >
> > I would ask they cover your cost for this as part of their product,
> > since they are the only product you use that needs it.
> >
> > On Fri, Aug 30, 2019 at 5:20 AM Jousma, David <01a0403c5dc1-dmarc-
> > requ...@listserv.ua.edu> wrote:
> > >
> > > This is the first I have seen this!   That is good news.  We have one
> > particular Financial Business application, written/distributed by
> > outside vendor that I have been bugging now since I put V2.3 in almost 2
> years ago
> > to remediate.   They still have not yet remediated there code, and I was
> > thinking this was going to hold up my implementation.
> > >
> > > 
> > > __
> > > ___
> > > Dave Jousma
> > > AVP | Manager, Systems Engineering
> > >
> > > Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> > > Rapids, MI 49546
> > > 616.653.8429  |  fax: 616.653.2717
> > >
> > >
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> > > Behalf Of Vernooij, Kees (ITOP NM) - KLM
> > > Sent: Friday, August 30, 2019 4:20 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: z/OS 2.1 to 2.4
> > >
> > > **CAUTION EXTERNAL EMAIL**
> > >
> > > **DO NOT open attachments or click on links from unknown senders or
> > > unexpected emails**
> > >
> > > IBM has a payed feature called Restricted Use CSA, that allows you
> > > to
> > keep your applics with userkeycsa running in 2.4.
> > > Check OA56180.
> > >
> > > Kees.
> > >
> > >
> > > > -Original Message-
> > > > 

Re: z/OS 2.1 to 2.4

[Jousma, David]

Well, my excitement was short-lived.In the text of OA56180 I read:

Note: This APAR only applies to user key CSA storage.  Both
  user key (8-15) SCOPE=COMMON data spaces and the usage of
  the CHANGKEY service to change the storage key of common
  storage to a key of 8-15 are not affected by this APAR,
  and will no longer be supported after z/OS V2R3.


Sadly, this application is creating UserKey Common data space and using it as a 
high-perf "data base" within the application for their batch jobs.  I've known 
about it since IBM enabled reporting via SMF30 records.

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Vernooij, Kees (ITOP NM) - KLM
Sent: Friday, August 30, 2019 7:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.1 to 2.4

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

It does, because 2.4 does not support userkeycsa(yes) anymore. It is also 
discussed in the 2.4 migration guide.

It seems to me the feature will stay, because IBM has fulfilled its goal to 
block CSA from being used by unauthorized users with full read/write access. 
Now you must selectively permit userkey csa to users and it is now your 
responsibility.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Jousma, David
> Sent: 30 August, 2019 12:47
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> Yea...  Funny thing it is a pretty major/well known Financial Application
> vendor.   Every 4-6 months for the last two years I've been pinging them
> on their status.   I just don’t think they understand the gravity of the
> situation they are creating here.
> 
> Also, I did open a PMR on this PTF.   It's not clear to me that the
> support it discusses continues into V2.4?
> 
> __
> 
> ___
> Dave Jousma
> AVP | Manager, Systems Engineering
> 
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
> Rapids, MI 49546
> 616.653.8429  |  fax: 616.653.2717
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Mike Schwab
> Sent: Friday, August 30, 2019 6:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> **CAUTION EXTERNAL EMAIL**
> 
> **DO NOT open attachments or click on links from unknown senders or 
> unexpected emails**
> 
> I would ask they cover your cost for this as part of their product, 
> since they are the only product you use that needs it.
> 
> On Fri, Aug 30, 2019 at 5:20 AM Jousma, David <01a0403c5dc1-dmarc- 
> requ...@listserv.ua.edu> wrote:
> >
> > This is the first I have seen this!   That is good news.  We have one
> particular Financial Business application, written/distributed by 
> outside vendor that I have been bugging now since I put V2.3 in almost 2 
> years ago
> to remediate.   They still have not yet remediated there code, and I was
> thinking this was going to hold up my implementation.
> >
> > 
> > __
> > ___
> > Dave Jousma
> > AVP | Manager, Systems Engineering
> >
> > Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
> > Rapids, MI 49546
> > 616.653.8429  |  fax: 616.653.2717
> >
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On 
> > Behalf Of Vernooij, Kees (ITOP NM) - KLM
> > Sent: Friday, August 30, 2019 4:20 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS 2.1 to 2.4
> >
> > **CAUTION EXTERNAL EMAIL**
> >
> > **DO NOT open attachments or click on links from unknown senders or 
> > unexpected emails**
> >
> > IBM has a payed feature called Restricted Use CSA, that allows you 
> > to
> keep your applics with userkeycsa running in 2.4.
> > Check OA56180.
> >
> > Kees.
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List 
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave
> > > Sent: 30 August, 2019 10:06
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: z/OS 2.1 to 2.4
> > >
> > > Just monoplexes. Some limited sharing of DASD. Not even GRS.
> > > But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting.
> > > Our Natural Global Buffer Pool is one such use.
> > > We are quite back level with both Natural and Adabas.
> > >
> > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List  
> > > > On Behalf Of Brian Westerman
> > > > Sent: Thursday, August 29, 2019 11:53 PM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: 

Re: z/OS 2.1 to 2.4

[Vernooij, Kees (ITOP NM) - KLM]

It does, because 2.4 does not support userkeycsa(yes) anymore. It is also 
discussed in the 2.4 migration guide.

It seems to me the feature will stay, because IBM has fulfilled its goal to 
block CSA from being used by unauthorized users with full read/write access. 
Now you must selectively permit userkey csa to users and it is now your 
responsibility.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jousma, David
> Sent: 30 August, 2019 12:47
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> Yea...  Funny thing it is a pretty major/well known Financial Application
> vendor.   Every 4-6 months for the last two years I've been pinging them
> on their status.   I just don’t think they understand the gravity of the
> situation they are creating here.
> 
> Also, I did open a PMR on this PTF.   It's not clear to me that the
> support it discusses continues into V2.4?
> 
> __
> ___
> Dave Jousma
> AVP | Manager, Systems Engineering
> 
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> Rapids, MI 49546
> 616.653.8429  |  fax: 616.653.2717
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Mike Schwab
> Sent: Friday, August 30, 2019 6:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> **CAUTION EXTERNAL EMAIL**
> 
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
> 
> I would ask they cover your cost for this as part of their product, since
> they are the only product you use that needs it.
> 
> On Fri, Aug 30, 2019 at 5:20 AM Jousma, David <01a0403c5dc1-dmarc-
> requ...@listserv.ua.edu> wrote:
> >
> > This is the first I have seen this!   That is good news.  We have one
> particular Financial Business application, written/distributed by outside
> vendor that I have been bugging now since I put V2.3 in almost 2 years ago
> to remediate.   They still have not yet remediated there code, and I was
> thinking this was going to hold up my implementation.
> >
> > __
> > ___
> > Dave Jousma
> > AVP | Manager, Systems Engineering
> >
> > Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> > Rapids, MI 49546
> > 616.653.8429  |  fax: 616.653.2717
> >
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Vernooij, Kees (ITOP NM) - KLM
> > Sent: Friday, August 30, 2019 4:20 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS 2.1 to 2.4
> >
> > **CAUTION EXTERNAL EMAIL**
> >
> > **DO NOT open attachments or click on links from unknown senders or
> > unexpected emails**
> >
> > IBM has a payed feature called Restricted Use CSA, that allows you to
> keep your applics with userkeycsa running in 2.4.
> > Check OA56180.
> >
> > Kees.
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave
> > > Sent: 30 August, 2019 10:06
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: z/OS 2.1 to 2.4
> > >
> > > Just monoplexes. Some limited sharing of DASD. Not even GRS.
> > > But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting.
> > > Our Natural Global Buffer Pool is one such use.
> > > We are quite back level with both Natural and Adabas.
> > >
> > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List  On
> > > > Behalf Of Brian Westerman
> > > > Sent: Thursday, August 29, 2019 11:53 PM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: z/OS 2.1 to 2.4
> > > >
> > > > IS your a Parallel sysplex or just LPAR environment?  If not
> > > > parallel
> > > sysplex,
> > > > then you have nothing to worry about, except for the fact that the
> > > > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't
> > > > using
> > > it
> > > > now), everything else is fairly minor.  If your running a sysplex,
> > > > then
> > > you
> > > > probably are okay, but it will depend on a lot of factors which I
> > > > don't
> > > have
> > > > enough information to tell you about.
> > > >
> > > > You can contact me offline if you want and we can discuss it, but
> > > > I
> > > suspect
> > > > that so long as you are not running some pretty old vendor
> > > > software or
> > > some
> > > > really crappy home grown code that you will have very few (if any)
> > > issues.
> > > >
> > > > Brian
> > > >
> > > > --
> > > > --
> > > > -- For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > send
> > > email to
> > > > lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> > > 
> > > 

Re: z/OS 2.1 to 2.4

[Jousma, David]

Elardus, yea, I took quite a bit of vacation this summer  I always suspend 
delivery of IBM-MAIL mail during that time, otherwise my outlook email box 
would probably fill up.   :)

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Elardus Engelbrecht
Sent: Friday, August 30, 2019 6:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.1 to 2.4

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Jousma, David wrote:

>This is the first I have seen this!   That is good news. 

That is indeed good news. APAR OA53355 and APAR OA56180 were discussed several 
times on IBM-MAIN. Perhaps you have missed that?

Groete / Greetings
Elardus Engelbrecht

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

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


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

Re: z/OS 2.1 to 2.4 [EXTERNAL]

[Feller, Paul]

Would there be any concerns with internal changes to system dataset structures? 
 As an example like catalogs or things like HSM CDS datasets?  Going from z/OS 
2.1 to z/OS 2.4 is technically not support for fallback.  Would it be a good 
thing to at least try to get any z/OS 2.3 compatibility maintenance applied?  
That might get you nearer to a level that could help if you had to fallback.

From the z/OS Planning for Installation manual for z/OS 2.4
z/OS V2R4 is supported for coexistence, fallback, and upgrade with the 
following z/OS® releases: z/OS V2R4, V2R3, and V2R2.

This means that:
•Coexistence of a z/OS V2R4 system with a V2R3 and V2R2 system is supported.
•Fallback from a z/OS V2R4 system to a V2R3 or V2R2 system is supported.
•Upgrade to a z/OS V2R4 system from a V2R3 or V2R2 system is supported.


Thanks..

Paul Feller
AGT Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Friday, August 30, 2019 5:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL]

I would ask they cover your cost for this as part of their product, since they 
are the only product you use that needs it.

On Fri, Aug 30, 2019 at 5:20 AM Jousma, David 
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
>
> This is the first I have seen this!   That is good news.  We have one 
> particular Financial Business application, written/distributed by outside 
> vendor that I have been bugging now since I put V2.3 in almost 2 years ago to 
> remediate.   They still have not yet remediated there code, and I was 
> thinking this was going to hold up my implementation.
>
> __
> ___
> Dave Jousma
> AVP | Manager, Systems Engineering
>
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
> Rapids, MI 49546
> 616.653.8429  |  fax: 616.653.2717
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Vernooij, Kees (ITOP NM) - KLM
> Sent: Friday, August 30, 2019 4:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or 
> unexpected emails**
>
> IBM has a payed feature called Restricted Use CSA, that allows you to keep 
> your applics with userkeycsa running in 2.4.
> Check OA56180.
>
> Kees.
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave
> > Sent: 30 August, 2019 10:06
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS 2.1 to 2.4
> >
> > Just monoplexes. Some limited sharing of DASD. Not even GRS.
> > But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting.
> > Our Natural Global Buffer Pool is one such use.
> > We are quite back level with both Natural and Adabas.
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On 
> > > Behalf Of Brian Westerman
> > > Sent: Thursday, August 29, 2019 11:53 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: z/OS 2.1 to 2.4
> > >
> > > IS your a Parallel sysplex or just LPAR environment?  If not 
> > > parallel
> > sysplex,
> > > then you have nothing to worry about, except for the fact that the
> > > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't 
> > > using
> > it
> > > now), everything else is fairly minor.  If your running a sysplex, 
> > > then
> > you
> > > probably are okay, but it will depend on a lot of factors which I 
> > > don't
> > have
> > > enough information to tell you about.
> > >
> > > You can contact me offline if you want and we can discuss it, but 
> > > I
> > suspect
> > > that so long as you are not running some pretty old vendor 
> > > software or
> > some
> > > really crappy home grown code that you will have very few (if any)
> > issues.
> > >
> > > Brian
> > >
> > > --
> > > --
> > > -- 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 information, services and offers, please visit our web site: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.klm.com=DwIFaQ=9g4MJkl2VjLjS6R4ei18BA=eUhu3PeeWy6RTndlJVKembFjFsvwCa8eeU_gm45NyOc=CIWXYEyO7PjdkaZtkx3QORHQNtp6NWBpvuBE36kVx8E=7Nz0_hw5NPQWkLKTsODu3Hpo9EOyPNVzAYH0ZNr43LU=
>  . This e-mail and any attachment may contain confidential and privileged 
> material intended for the addressee only. If you are not the addressee, 

Re: zOS GENCERT

[Jantje.]

On Wed, 28 Aug 2019 11:31:33 -0500, Joel M Ivey  wrote:

>In zOS, is it possible to extract a private key, making it viewable by a 
>human, generated by the RACF RACDCERT GENCERT command?

RACDCERT EXPORT perhaps?

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.icha400/le-export.htm

Cheers,

Jantje.

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

Re: z/OS 2.1 to 2.4

[Jousma, David]

Yea...  Funny thing it is a pretty major/well known Financial Application 
vendor.   Every 4-6 months for the last two years I've been pinging them on 
their status.   I just don’t think they understand the gravity of the situation 
they are creating here.

Also, I did open a PMR on this PTF.   It's not clear to me that the support it 
discusses continues into V2.4?

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Friday, August 30, 2019 6:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.1 to 2.4

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I would ask they cover your cost for this as part of their product, since they 
are the only product you use that needs it.

On Fri, Aug 30, 2019 at 5:20 AM Jousma, David 
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
>
> This is the first I have seen this!   That is good news.  We have one 
> particular Financial Business application, written/distributed by outside 
> vendor that I have been bugging now since I put V2.3 in almost 2 years ago to 
> remediate.   They still have not yet remediated there code, and I was 
> thinking this was going to hold up my implementation.
>
> __
> ___
> Dave Jousma
> AVP | Manager, Systems Engineering
>
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
> Rapids, MI 49546
> 616.653.8429  |  fax: 616.653.2717
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Vernooij, Kees (ITOP NM) - KLM
> Sent: Friday, August 30, 2019 4:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or 
> unexpected emails**
>
> IBM has a payed feature called Restricted Use CSA, that allows you to keep 
> your applics with userkeycsa running in 2.4.
> Check OA56180.
>
> Kees.
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave
> > Sent: 30 August, 2019 10:06
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS 2.1 to 2.4
> >
> > Just monoplexes. Some limited sharing of DASD. Not even GRS.
> > But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting.
> > Our Natural Global Buffer Pool is one such use.
> > We are quite back level with both Natural and Adabas.
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On 
> > > Behalf Of Brian Westerman
> > > Sent: Thursday, August 29, 2019 11:53 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: z/OS 2.1 to 2.4
> > >
> > > IS your a Parallel sysplex or just LPAR environment?  If not 
> > > parallel
> > sysplex,
> > > then you have nothing to worry about, except for the fact that the
> > > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't 
> > > using
> > it
> > > now), everything else is fairly minor.  If your running a sysplex, 
> > > then
> > you
> > > probably are okay, but it will depend on a lot of factors which I 
> > > don't
> > have
> > > enough information to tell you about.
> > >
> > > You can contact me offline if you want and we can discuss it, but 
> > > I
> > suspect
> > > that so long as you are not running some pretty old vendor 
> > > software or
> > some
> > > really crappy home grown code that you will have very few (if any)
> > issues.
> > >
> > > Brian
> > >
> > > --
> > > --
> > > -- 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 information, services and offers, please visit our web site: 
> http://www.klm.com. This e-mail and any attachment may contain confidential 
> and privileged material intended for the addressee only. If you are not the 
> addressee, you are notified that no part of the e-mail or any attachment may 
> be disclosed, copied or distributed, and that any other action related to 
> this e-mail or attachment is strictly prohibited, and may be unlawful. If you 
> have received this e-mail by error, please notify the sender immediately by 
> return e-mail, and delete this message.
>
> Koninklijke 

Re: z/OS 2.1 to 2.4

[Vernooij, Kees (ITOP NM) - KLM]

We discovered it in Cheryl's newsletter 2019 no.1.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jousma, David
> Sent: 30 August, 2019 12:20
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> This is the first I have seen this!   That is good news.  We have one
> particular Financial Business application, written/distributed by outside
> vendor that I have been bugging now since I put V2.3 in almost 2 years ago
> to remediate.   They still have not yet remediated there code, and I was
> thinking this was going to hold up my implementation.
> 
> __
> ___
> Dave Jousma
> AVP | Manager, Systems Engineering
> 
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> Rapids, MI 49546
> 616.653.8429  |  fax: 616.653.2717
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Vernooij, Kees (ITOP NM) - KLM
> Sent: Friday, August 30, 2019 4:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> **CAUTION EXTERNAL EMAIL**
> 
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
> 
> IBM has a payed feature called Restricted Use CSA, that allows you to keep
> your applics with userkeycsa running in 2.4.
> Check OA56180.
> 
> Kees.
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Gibney, Dave
> > Sent: 30 August, 2019 10:06
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS 2.1 to 2.4
> >
> > Just monoplexes. Some limited sharing of DASD. Not even GRS.
> > But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting.
> > Our Natural Global Buffer Pool is one such use.
> > We are quite back level with both Natural and Adabas.
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> > > Behalf Of Brian Westerman
> > > Sent: Thursday, August 29, 2019 11:53 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: z/OS 2.1 to 2.4
> > >
> > > IS your a Parallel sysplex or just LPAR environment?  If not
> > > parallel
> > sysplex,
> > > then you have nothing to worry about, except for the fact that the
> > > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't
> > > using
> > it
> > > now), everything else is fairly minor.  If your running a sysplex,
> > > then
> > you
> > > probably are okay, but it will depend on a lot of factors which I
> > > don't
> > have
> > > enough information to tell you about.
> > >
> > > You can contact me offline if you want and we can discuss it, but I
> > suspect
> > > that so long as you are not running some pretty old vendor software
> > > or
> > some
> > > really crappy home grown code that you will have very few (if any)
> > issues.
> > >
> > > Brian
> > >
> > > 
> > > -- 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 information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and
> may be unlawful. If you have received this e-mail by error, please notify
> the sender immediately by return e-mail, and delete this message.
> 
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in
> receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION
> EXTERNAL EMAIL**
> 
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
> 
> This e-mail transmission contains information that is confidential and may
> be privileged.   It is intended only for the addressee(s) named 

Re: z/OS 2.1 to 2.4

[Mike Schwab]

I would ask they cover your cost for this as part of their product,
since they are the only product you use that needs it.

On Fri, Aug 30, 2019 at 5:20 AM Jousma, David
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
>
> This is the first I have seen this!   That is good news.  We have one 
> particular Financial Business application, written/distributed by outside 
> vendor that I have been bugging now since I put V2.3 in almost 2 years ago to 
> remediate.   They still have not yet remediated there code, and I was 
> thinking this was going to hold up my implementation.
>
> _
> Dave Jousma
> AVP | Manager, Systems Engineering
>
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, 
> MI 49546
> 616.653.8429  |  fax: 616.653.2717
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Vernooij, Kees (ITOP NM) - KLM
> Sent: Friday, August 30, 2019 4:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or 
> unexpected emails**
>
> IBM has a payed feature called Restricted Use CSA, that allows you to keep 
> your applics with userkeycsa running in 2.4.
> Check OA56180.
>
> Kees.
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Gibney, Dave
> > Sent: 30 August, 2019 10:06
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS 2.1 to 2.4
> >
> > Just monoplexes. Some limited sharing of DASD. Not even GRS.
> > But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting.
> > Our Natural Global Buffer Pool is one such use.
> > We are quite back level with both Natural and Adabas.
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> > > Behalf Of Brian Westerman
> > > Sent: Thursday, August 29, 2019 11:53 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: z/OS 2.1 to 2.4
> > >
> > > IS your a Parallel sysplex or just LPAR environment?  If not
> > > parallel
> > sysplex,
> > > then you have nothing to worry about, except for the fact that the
> > > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't
> > > using
> > it
> > > now), everything else is fairly minor.  If your running a sysplex,
> > > then
> > you
> > > probably are okay, but it will depend on a lot of factors which I
> > > don't
> > have
> > > enough information to tell you about.
> > >
> > > You can contact me offline if you want and we can discuss it, but I
> > suspect
> > > that so long as you are not running some pretty old vendor software
> > > or
> > some
> > > really crappy home grown code that you will have very few (if any)
> > issues.
> > >
> > > Brian
> > >
> > > 
> > > -- 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 information, services and offers, please visit our web site: 
> http://www.klm.com. This e-mail and any attachment may contain confidential 
> and privileged material intended for the addressee only. If you are not the 
> addressee, you are notified that no part of the e-mail or any attachment may 
> be disclosed, copied or distributed, and that any other action related to 
> this e-mail or attachment is strictly prohibited, and may be unlawful. If you 
> have received this e-mail by error, please notify the sender immediately by 
> return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
> employees shall not be liable for the incorrect or incomplete transmission of 
> this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
> Airlines) is registered in Amstelveen, The Netherlands, with registered 
> number 33014286
> 
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL 
> EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or 
> unexpected emails**
>
> This e-mail transmission contains information that is confidential and may be 
> privileged.   It is intended only for the addressee(s) named above. If you 
> receive this e-mail in error, please 

Re: z/OS 2.1 to 2.4

[Elardus Engelbrecht]

Jousma, David wrote:

>This is the first I have seen this!   That is good news. 

That is indeed good news. APAR OA53355 and APAR OA56180 were discussed several 
times on IBM-MAIN. Perhaps you have missed that?

Groete / Greetings
Elardus Engelbrecht

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

Re: z/OS 2.1 to 2.4

[Jousma, David]

This is the first I have seen this!   That is good news.  We have one 
particular Financial Business application, written/distributed by outside 
vendor that I have been bugging now since I put V2.3 in almost 2 years ago to 
remediate.   They still have not yet remediated there code, and I was thinking 
this was going to hold up my implementation.

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Vernooij, Kees (ITOP NM) - KLM
Sent: Friday, August 30, 2019 4:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS 2.1 to 2.4

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

IBM has a payed feature called Restricted Use CSA, that allows you to keep your 
applics with userkeycsa running in 2.4.
Check OA56180.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Gibney, Dave
> Sent: 30 August, 2019 10:06
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> Just monoplexes. Some limited sharing of DASD. Not even GRS.
> But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting.
> Our Natural Global Buffer Pool is one such use.
> We are quite back level with both Natural and Adabas.
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List  On 
> > Behalf Of Brian Westerman
> > Sent: Thursday, August 29, 2019 11:53 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS 2.1 to 2.4
> >
> > IS your a Parallel sysplex or just LPAR environment?  If not 
> > parallel
> sysplex,
> > then you have nothing to worry about, except for the fact that the
> > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't 
> > using
> it
> > now), everything else is fairly minor.  If your running a sysplex, 
> > then
> you
> > probably are okay, but it will depend on a lot of factors which I 
> > don't
> have
> > enough information to tell you about.
> >
> > You can contact me offline if you want and we can discuss it, but I
> suspect
> > that so long as you are not running some pretty old vendor software 
> > or
> some
> > really crappy home grown code that you will have very few (if any)
> issues.
> >
> > Brian
> >
> > 
> > -- 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 information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

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

Re: z/OS 2.1 to 2.4

[Jousma, David]

As long as you don't have any USERKEYCSA or USERKEYCAD applications to 
remediate, you will probably be ok.  As IBM has removed support for that in 
2.4.  What is the official IBM stance?  N-2 or N-3?  I don't recall.   

I'll be ordering 2.4 this fall as well.

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gibney, Dave
Sent: Thursday, August 29, 2019 4:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OS 2.1 to 2.4

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

  I am considering what upgrade path (if any) I might take from my current z/OS 
2.1 RSU 1903 system. I thought that I wouldn't go to 2.3 because I was using 
SMTP and not CSSMTP. The configuring and implementation of CSSMTP has proven 
remarkably uneventful. I am not aware of any other gotchas between 2.1 and 2.3 
or above.
  I run four monoplex LPARs. I really don't "coexist" in the sysplex sense. I 
am considering getting s 2.4 Serverpac when available and making the jump.
  I do need to be concerned with fallback. I know it's mostly speculation at 
this point, but does anyone know of z/OS 2.4 fallback maintenance that won't be 
available for 2.1?
  Or gotchas I haven't noticed.

Dave Gibney
Information Technology Services
Washington State University


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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


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

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

Re: z/OS 2.1 to 2.4

[Vernooij, Kees (ITOP NM) - KLM]

RUCSA is available for z/OS 2.1, so you can implement on you current systems 
and move it out of the migration path.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Martin Packer
> Sent: 30 August, 2019 10:37
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> Note: With RUCSA there are still migration actions - because of the new
> way of allowing an address space to use it.
> 
> Cheers, Martin
> 
> Martin Packer
> 
> zChampion, Systems Investigator & Performance Troubleshooter, IBM
> 
> +44-7802-245-584
> 
> email: martin_pac...@uk.ibm.com
> 
> Twitter / Facebook IDs: MartinPacker
> 
> Blog:
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
> 
> Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or
> 
> https://itunes.apple.com/gb/podcast/mainframe-performance-
> topics/id1127943573?mt=2
> 
> 
> Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
> 
> 
> 
> From:   "Vernooij, Kees (ITOP NM) - KLM" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   30/08/2019 09:21
> Subject:Re: z/OS 2.1 to 2.4
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> IBM has a payed feature called Restricted Use CSA, that allows you to keep
> your applics with userkeycsa running in 2.4.
> Check OA56180.
> 
> Kees.
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Gibney, Dave
> > Sent: 30 August, 2019 10:06
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS 2.1 to 2.4
> >
> > Just monoplexes. Some limited sharing of DASD. Not even GRS.
> > But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting.
> > Our Natural Global Buffer Pool is one such use.
> > We are quite back level with both Natural and Adabas.
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> > > Behalf Of Brian Westerman
> > > Sent: Thursday, August 29, 2019 11:53 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: z/OS 2.1 to 2.4
> > >
> > > IS your a Parallel sysplex or just LPAR environment?  If not parallel
> > sysplex,
> > > then you have nothing to worry about, except for the fact that the
> > > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't
> using
> > it
> > > now), everything else is fairly minor.  If your running a sysplex,
> then
> > you
> > > probably are okay, but it will depend on a lot of factors which I
> don't
> > have
> > > enough information to tell you about.
> > >
> > > You can contact me offline if you want and we can discuss it, but I
> > suspect
> > > that so long as you are not running some pretty old vendor software or
> > some
> > > really crappy home grown code that you will have very few (if any)
> > issues.
> > >
> > > Brian
> > >
> > > --
> > > 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 information, services and offers, please visit our web site:
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.klm.com=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-
> WOWZjlZ0NwmcFSpQCLphNznBSDQ=gpOagelfUQirHhAYLM5OLW3X-fZoRpaYVr-
> LlHpuVHg=SH5PyIj6HoznFA_qBtRu5lZhtUhNauWGIZeJ5AXpEjU=
> . This e-mail and any attachment may contain confidential and privileged
> material intended for the addressee only. If you are not the addressee,
> you are notified that no part of the e-mail or any attachment may be
> disclosed, copied or distributed, and that any other action related to
> this e-mail or attachment is strictly prohibited, and may be unlawful. If
> you have received this e-mail by error, please notify the sender
> immediately by return e-mail, and delete this message.
> 
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in
> receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> 

Re: SYNCSORT and STEPLIB/JOBLIB/LINKLIB issue

[Massimo Biancucci]

Peter,

I've tried the same on a customer site running Syncsort 2.1.5.0R on zOS 2.3
and it seems everything works fine.

You can try (only a try) to code the DDNAME on E15/E35, add the DD with
LOADLIB and see if anything changes.

MODS E15=(EXITE15M,2048000,MYDDN,C),E35=(EXITE35M,2048000,MYDDN,C)

Double check if PDS are in LLA/VLF and finally open an issue to Syncsort.

Good luck.
Max

Il giorno gio 29 ago 2019 alle ore 23:53 Farley, Peter x23353 <
peter.far...@broadridge.com> ha scritto:

> I have a confusing issue with using COBOL E15/E35 exit programs where the
> exit programs dynamically call application-specific subroutines in a JCL
> SYNCSORT.  The issue is from which library the exit programs are actually
> loading the dynamically called subroutines.  It seems that the dynamic
> subroutines always load from LINKLIB, and not from STEPLIB or JOBLIB.  What
> I EXPECTED to happen was that the version of the dynamically called
> application-specific subroutines in the STEPLIB or JOBLIB would be used,
> not the version in LINKLIB.
>
> The JCL sort in question has a STEPLIB pointing to a small PDS with
> application-specific versions of certain dynamically called subroutines.
> The MODS statement is coded like this:
>
> MODS E15=(EXITE15M,2048000,,C),E35=(EXITE35M,2048000,,C)
>
> When each of the exits (both are compiled with Enterprise COBOL V5.2)
> EXITE15M or EXITE35M is called by SYNCSORT, the only version of those exit
> programs available is in the LINKLIST in a global application library.
> Both exits dynamically call one of the application-specific subroutines as
> one of the first things that they do.
>
> The application-specific subroutine performs a WTO as part of its normal
> operation (ROUTCDE=11,DESC=7) to allow identification of which version of
> the subroutine was actually loaded and executed.
>
> Even with a STEPLIB (and I also tried a JOBLIB) pointing to a library with
> DIFFERENT VERSIONS of the application-specific subroutine than are in the
> global application library in the LINKLIST, only the GLOBAL VERSION in the
> LINKLIST application library is ever used, as evidenced by the WTO message
> generated.
>
> Is this a misunderstanding on my part of how dynamic calls from a MODS
> exit program should work, or is this a potential issue for a call to
> SYNCSORT support?
>
> SYNCSORT level is 2.1.6.0N, z/OS V2.2.
>
> TIA for any assistance or advice you can provide.
>
> Peter
>
>
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> e-mail and delete the message and any attachments from your system.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: z/OS 2.1 to 2.4

[Martin Packer]

Note: With RUCSA there are still migration actions - because of the new 
way of allowing an address space to use it.

Cheers, Martin

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   "Vernooij, Kees (ITOP NM) - KLM" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   30/08/2019 09:21
Subject:Re: z/OS 2.1 to 2.4
Sent by:IBM Mainframe Discussion List 



IBM has a payed feature called Restricted Use CSA, that allows you to keep 
your applics with userkeycsa running in 2.4.
Check OA56180.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Gibney, Dave
> Sent: 30 August, 2019 10:06
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> Just monoplexes. Some limited sharing of DASD. Not even GRS.
> But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting.
> Our Natural Global Buffer Pool is one such use.
> We are quite back level with both Natural and Adabas.
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Brian Westerman
> > Sent: Thursday, August 29, 2019 11:53 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS 2.1 to 2.4
> >
> > IS your a Parallel sysplex or just LPAR environment?  If not parallel
> sysplex,
> > then you have nothing to worry about, except for the fact that the
> > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't 
using
> it
> > now), everything else is fairly minor.  If your running a sysplex, 
then
> you
> > probably are okay, but it will depend on a lot of factors which I 
don't
> have
> > enough information to tell you about.
> >
> > You can contact me offline if you want and we can discuss it, but I
> suspect
> > that so long as you are not running some pretty old vendor software or
> some
> > really crappy home grown code that you will have very few (if any)
> issues.
> >
> > Brian
> >
> > --
> > 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 information, services and offers, please visit our web site: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.klm.com=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=gpOagelfUQirHhAYLM5OLW3X-fZoRpaYVr-LlHpuVHg=SH5PyIj6HoznFA_qBtRu5lZhtUhNauWGIZeJ5AXpEjU=
 
. This e-mail and any attachment may contain confidential and privileged 
material intended for the addressee only. If you are not the addressee, 
you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to 
this e-mail or attachment is strictly prohibited, and may be unlawful. If 
you have received this e-mail by error, please notify the sender 
immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission 
of this e-mail or any attachments, nor responsible for any delay in 
receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered 
number 33014286



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




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: z/OS 2.1 to 2.4

[Vernooij, Kees (ITOP NM) - KLM]

IBM has a payed feature called Restricted Use CSA, that allows you to keep your 
applics with userkeycsa running in 2.4.
Check OA56180.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Gibney, Dave
> Sent: 30 August, 2019 10:06
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> Just monoplexes. Some limited sharing of DASD. Not even GRS.
> But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting.
> Our Natural Global Buffer Pool is one such use.
> We are quite back level with both Natural and Adabas.
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Brian Westerman
> > Sent: Thursday, August 29, 2019 11:53 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS 2.1 to 2.4
> >
> > IS your a Parallel sysplex or just LPAR environment?  If not parallel
> sysplex,
> > then you have nothing to worry about, except for the fact that the
> > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't using
> it
> > now), everything else is fairly minor.  If your running a sysplex, then
> you
> > probably are okay, but it will depend on a lot of factors which I don't
> have
> > enough information to tell you about.
> >
> > You can contact me offline if you want and we can discuss it, but I
> suspect
> > that so long as you are not running some pretty old vendor software or
> some
> > really crappy home grown code that you will have very few (if any)
> issues.
> >
> > Brian
> >
> > --
> > 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 information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: z/OS 2.1 to 2.4

[Gibney, Dave]

Just monoplexes. Some limited sharing of DASD. Not even GRS.
But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting. 
Our Natural Global Buffer Pool is one such use. 
We are quite back level with both Natural and Adabas.


> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Brian Westerman
> Sent: Thursday, August 29, 2019 11:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> IS your a Parallel sysplex or just LPAR environment?  If not parallel sysplex,
> then you have nothing to worry about, except for the fact that the
> ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't using it
> now), everything else is fairly minor.  If your running a sysplex, then you
> probably are okay, but it will depend on a lot of factors which I don't have
> enough information to tell you about.
> 
> You can contact me offline if you want and we can discuss it, but I suspect
> that so long as you are not running some pretty old vendor software or some
> really crappy home grown code that you will have very few (if any) issues.
> 
> Brian
> 
> --
> 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: DWW1VS00 impact to DFSMS ?

[Brian Westerman]

This is actually answered by IBM here 
https://www-01.ibm.com/support/docview.wss?uid=swg21192432

The CICS module goes first because it's needed to provide support for the CICS 
VR addresspace.  The CICS version of the module is MUCH bigger than the 
delivered one from SMS and contains all of the logic from the SMS copy (which 
does almost nothing as it's only about 458 bytes long) and adds to it the code 
necessary to support the CICS VR address space.

Actually you would have found out very quickly that it won't work correctly the 
other way around. :)

Brian

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

Re: Clarification on DASD mod conversion of SYSRES

[Brian Westerman]

You can't IPL with the IPL datasets cataloged to , it fails if you try to 
set  to something in IEASYMxx.  The same is true if you try to use a 
symbolic for the catalog volume(s) (assuming it's separate from the res 
volume(s)), but I think that issue is the ICF catalogs themselves.  You can 
however catalog normal non-vsam datasets to any symbol you want so long as you 
identify it in the IEASYMxx member.  I ALWAYS catalog ALL my DLIB and some 
VENDOR volumes that way, it makes life (and maintenance) a lot easier to be 
able to change the volsers.  

(i.e. one of the sites I manage has their current IPL vols as is C23RS1 (which 
has every cataloged as **) , C23RS2 ( which has everything cataloged to 
) and C23DL1 (which has everything cataloged to ) , C23DL2 (same 
format but )  and C23DL3 (same format but ), and the next one 
will be D23RS1, and D23RS2, D23DL1, D23DL2 and D23DL3.  There is no re 
cataloging of datasets necessary, I just change the IEASYMxx member and 
everything is where it needs to be.  My Backup SYSRES's are C23RSA and C23RSB 
and again, I just point the IPL to C23RSA and IEASYMxx is changed to point 
 to C23RSB and everything is set yo IPL and go.

The names of the volumes themselves can be whatever I want to make them easy to 
remember in an emergency, they could be 11 and 22 and the process would 
be the same.

It's very easy to do maintenance this way.

Brian

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

Re: Assembler :- PC Instruction

[Vernooij, Kees (ITOP NM) - KLM]

A little less I think.
I remember their meaning became vague when comparing performance and MIPS of 
Amdahl and IBM machines gave unexplainable differences during the 80's.
And when IBM started putting more functionality into an instruction, if was 
definitely renamed to Meaningless Indicator of Processor Speed.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Seymour J Metz
> Sent: 29 August, 2019 19:04
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Assembler :- PC Instruction
> 
> SVC itself performs a simple function. SVC together with  its interrupt
> handlers is not so simple. What with the serialization for the GETMAIN or
> whatever it uses these days, I'd expect it to be at least as expensive as
> PC. If you need to operate in another address space, add in the overhead
> of acquiring, scheduling and freeing SRBs.
> 
> > The times that machine performance could be expressed in Million
> Instructions Per Second are long gone.
> 
> 
> They've been gone for half a century, if they ever existed.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> 
> From: IBM Mainframe Discussion List  on behalf
> of Vernooij, Kees (ITOP NM) - KLM 
> Sent: Thursday, August 29, 2019 8:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Assembler :- PC Instruction
> 
> "against SVC plus the SVC interrupt handler".
> Possibly also: Plus SVC code?
> The SVC instruction performs a function, the PC instruction does too.
> 
> From what I understood of the PC instruction: with 1 instruction you can
> now execute a 'function' that might have taken pages of assembler
> instructions before.
> 
> The times that machine performance could be expressed in Million
> Instructions Per Second are long gone.
> 
> Kees.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Peter Relson
> > Sent: 29 August, 2019 13:45
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Assembler :- PC Instruction
> >
> > 
> > You can do a BASR and STORAGE OBTAIN, STORAGE RELEASE and BR in less
> time
> > than a BAKR.
> > 
> >
> > No you can't.
> >
> > 
> > How does its performance stack up against SVC?
> > 
> >
> > That's not a useful comparison. What is useful is "how does its
> > performance stack up against SVC plus the SVC interrupt handler".
> >
> > Peter Relson
> > z/OS Core Technology Design
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://secure-
> web.cisco.com/1yFCMng_oi34MeuWoGQVFSplOg6fpaFLyxdbGdQb9STPypzNLAxj2z3H1yPe
> 4hmcGsoQrveXhGIGpIQn4y5avwq7BULLqLr7LDIdVd3uZfyPSdpqKPZLOf85a9_UOdAfEEkGjP
> nXcTp7oZjO72UlCrOrkWCx9XGTouvxIvkrdhdxx7mbiJCUcsSNwdIhGoKmSm_S4VqyCCu_-
> 5BvvEZ79ciMla-Ce6L9JM5Ftywxolu5eN46Eq6qEk2Cf-
> Zcs5T9IkVQzK7gnyAmr3_tZBL1XW1EDny_9mYCBo58WeWGmKDzZaHMjFOWAKa7le7wuJMXxvxG
> huhm_EyVpP7hsmqb89fuquitBk3uYlWjLHQFCW51CPwAUMtM3_g4RZTozHtzb/http%3A%2F%2
> Fwww.klm.com. This e-mail and any attachment may contain confidential and
> privileged material intended for the addressee only. If you are not the
> addressee, you are notified that no part of the e-mail or any attachment
> may be disclosed, copied or distributed, and that any other action related
> to this e-mail or attachment is strictly prohibited, and may be unlawful.
> If you have received this e-mail by error, please notify the sender
> immediately by return e-mail, and delete this message.
> 
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in
> receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> h the
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are 

Re: z/OS 2.1 to 2.4

[Brian Westerman]

IS your a Parallel sysplex or just LPAR environment?  If not parallel sysplex, 
then you have nothing to worry about, except for the fact that the 
ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't using it 
now), everything else is fairly minor.  If your running a sysplex, then you 
probably are okay, but it will depend on a lot of factors which I don't have 
enough information to tell you about.

You can contact me offline if you want and we can discuss it, but I suspect 
that so long as you are not running some pretty old vendor software or some 
really crappy home grown code that you will have very few (if any) issues.

Brian

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

Re: Clarification on DASD mod conversion of SYSRES

[Barbara Nitz]

>I just checked my master cat and EVERY entry has , 2, or 3 except
>SYS1.PARMLIB on the SYSRES It has **. and  both are set
>to  since we use mod 27s.   We are at z/OS 2.3.

All, thanks for checking. 

So my conclusion way back when must have been wrong. I had left SYS1.PARMLIB 
(that came with ADCD) on the sysres. There was no SYS1.IBM.PARMLIB, and 
SYS1.PARMLIB was the one that was SMP/E-maintained. All other parmlibs were on 
the volume I had established called ZOSCAT. (One more thing that wasn't right 
with the ADCD systems).
Given that at 1.13 there was no rescue system and I had to IPL the old, 
functioning system every time I needed to make a change, I must have overlooked 
that only SYS1.PARMLIB needs to be catalogued on volume **. At least it 
didn't do any harm having everything else on sysres catalogued on ** 
instead of 

Still, the wordings in the books could do with some clarification, preferably 
in one central place. The day I did that migration (away from the ADCD res vols 
to my own) I must have IPL'd 20 times or so until I got things right. It was a 
long day.

Barbara

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