Re: Sysplex

[Vernooij, Kees (ITOP NM) - KLM]

I am curious to learn what he meant with the question. Either he has no idea 
what he is talking about or he means something completely different.

Kees.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of scott Ford
Sent: 27 November 2019 18:04
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sysplex

We use one of the system subpool SP 231 for holding messages we build from 
various ESMs. The customer asked if we could share SP231 across LPARs.
My take was no because I understood sp231 was unique until each LPAR .

Scott

On Wed, Nov 27, 2019 at 11:56 AM Allan Staller 
wrote:

> Each LPAR has their own.
>
> SYSPLEX does not share (virtual or real) storage.
> Selected information is shared by XCF using CTC or Coupling Facility.
>
> HTH,
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of scott Ford
> Sent: Wednesday, November 27, 2019 10:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Sysplex
>
> I have a question related to storage subpool. If you running a sysplex 
> do you share one set of subpool, I.e., sp 1 ,,etc. or does each LPAR 
> have its own ?
> I assumed the later.
>
>
> Scott
> --
> 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
> ::DISCLAIMER::
> 
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only. E-mail transmission is not 
> guaranteed to be secure or error-free as information could be 
> intercepted, corrupted, lost, destroyed, arrive late or incomplete, or 
> may contain viruses in transmission. The e mail and its contents (with 
> or without referred errors) shall therefore not attach any liability 
> on the originator or HCL or its affiliates. Views or opinions, if any, 
> presented in this email are solely those of the author and may not 
> necessarily reflect the views or opinions of HCL or its affiliates. 
> Any form of reproduction, dissemination, copying, disclosure, 
> modification, distribution and / or publication of this message 
> without the prior written consent of authorized representative of HCL 
> is strictly prohibited. If you have received this email in error 
> please delete it and notify the sender immediately. Before opening any 
> email and/or attachments, please check them for viruses and other defects.
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
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

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

[Jon Perryman]

 On Wednesday, November 27, 2019, 08:20:47 AM PST, scott Ford 
 wrote:
 
 
> My big issue I was at the mercy of CA code. Not blaming them,
> but it’s a CA product and I wished their doc was better.


If you are talking about the security exit samples, then they accomplished the 
desired results by discouraging it's use. This is not an exit to learn about 
coding exits. For high risk exits, never expect anything more than the basics 
(control blocks, return codes and something trivial that does nothing). They 
gave you the gun but don't expect them to load it for you. 
  Creating a sample that covers everything you need to know is impossible. SAF 
calls can occur in almost any type of environment. You can cripple your system 
if you don't have recovery correct. You can cripple your system if you use a 
macro that is not valid for every environment. Have you implemented diagnostic 
tools that don't make the problem worse.   

Jon.   

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

Re: OOCoD experiences?

[Martin Packer]

Make sure you adjust your LPAR setup when you add capacity. Weights,
Logicalis, etc. You can probably automate that.

Cheers, Martin (bitten by a few experiences in this area)

Sent from my iPad

> On 27 Nov 2019, at 21:17, Laurence Chiu  wrote:
>
> Just asking the list has anybody had experience using OOCod to double
their
> MIPS on their mainframes?
>
> Looking at out of region (country) backup solution so cannot use CBU
> records. So the idea is to buy half of what the MIPS might need to be and
> then provision the other half capacity using capacity on demand for a
> maximum of a week for testing or live to save the purchase price of the
> box.
>
> Thanks
>
> --
> 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: WTO

[Jon Perryman]

 On Wednesday, November 27, 2019, 04:39:07 AM PST, John McKown 
 wrote:
 
 
> Total agreement that it is bad form in today's world. For subsystems, there

> is the SSCT to anchor things. And, as I do for my re-entrant code: a

> Name/Token pair (primary address space level) to hold a 64-bit pointer

> (even in 24 or 31 bit mode, I make sure the pointer is 64-bit clean)..

If you really need speed, check if IBM has any user vector table entries 
specifically assigned for customer use. 4 load instructions instead of 
searching thru a chain. IBM assigns each entry (e.g. product vendor request). I 
vaguely recall it being called CSRCTABL but I could be wrong.

Jon.  

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

Re: OOCoD experiences?

[Laurence Chiu]

Thanks for that. I think there might be a software deal in the mix also
based on Tailor Fit Pricing but it's good to know all the ramifications.

CBU won't work because the site is out of country.

On Thu, Nov 28, 2019, 10:24 AM Jerry Whitteridge 
wrote:

> Be aware of using OOCoD that there is a difference in the billing records
> for Hardware and Software. We looked at this before I moved to IBM and had
> to rule it out as the Hardware side only bills you for the Capacity by the
> day activated (e.g. Use OOCoD for 7 days and get charged for the 7 days at
> higher capacity) BUT software is billed by the month so you get the full
> month at the higher capacity even if you only turned on OOCoD for an hour.
> CBU also provides test activations without financial impact where as OOCoD
> will not.
>
> Jerry Whitteridge
> Delivery Manager / Mainframe Architect
> GTS - Safeway Account
> 602 527 4871 Mobile
> jerry.whitteri...@ibm.com
>
> IBM Services
>
> IBM Mainframe Discussion List  wrote on
> 11/27/2019 02:16:44 PM:
>
> > From: Laurence Chiu 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 11/27/2019 02:17 PM
> > Subject: [EXTERNAL] OOCoD experiences?
> > Sent by: IBM Mainframe Discussion List 
> >
> > Just asking the list has anybody had experience using OOCod to double
> their
> > MIPS on their mainframes?
> >
> > Looking at out of region (country) backup solution so cannot use CBU
> > records. So the idea is to buy half of what the MIPS might need to be and
> > then provision the other half capacity using capacity on demand for a
> > maximum of a week for testing or live to save the purchase price of the
> > box.
> >
> > Thanks
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: OOCoD experiences?

[Jerry Whitteridge]

Be aware of using OOCoD that there is a difference in the billing records
for Hardware and Software. We looked at this before I moved to IBM and had
to rule it out as the Hardware side only bills you for the Capacity by the
day activated (e.g. Use OOCoD for 7 days and get charged for the 7 days at
higher capacity) BUT software is billed by the month so you get the full
month at the higher capacity even if you only turned on OOCoD for an hour.
CBU also provides test activations without financial impact where as OOCoD
will not.

Jerry Whitteridge
Delivery Manager / Mainframe Architect
GTS - Safeway Account
602 527 4871 Mobile
jerry.whitteri...@ibm.com

IBM Services

IBM Mainframe Discussion List  wrote on
11/27/2019 02:16:44 PM:

> From: Laurence Chiu 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 11/27/2019 02:17 PM
> Subject: [EXTERNAL] OOCoD experiences?
> Sent by: IBM Mainframe Discussion List 
>
> Just asking the list has anybody had experience using OOCod to double
their
> MIPS on their mainframes?
>
> Looking at out of region (country) backup solution so cannot use CBU
> records. So the idea is to buy half of what the MIPS might need to be and
> then provision the other half capacity using capacity on demand for a
> maximum of a week for testing or live to save the purchase price of the
> box.
>
> Thanks
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Paging Jay Maynard

[Joe Monk]

try jay.k...@gmail.com

Joe

On Wed, Nov 27, 2019 at 11:59 AM Mike Schwab 
wrote:

> https://twitter.com/tronguy
>
> Pretty much ignores anything Hercules related, won't assign a replacement
> owner.
>
> On Wed, Nov 27, 2019 at 11:28 AM Seymour J Metz  wrote:
> >
> > Does anybody have a valid e-mail address for Jay Maynard? The two I have
> bounce.
> >
> >
> > --
> > 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
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

OOCoD experiences?

[Laurence Chiu]

Just asking the list has anybody had experience using OOCod to double their
MIPS on their mainframes?

Looking at out of region (country) backup solution so cannot use CBU
records. So the idea is to buy half of what the MIPS might need to be and
then provision the other half capacity using capacity on demand for a
maximum of a week for testing or live to save the purchase price of the
box.

Thanks

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

Re: Sysplex

[Mark Jacobs]

If you have a requirement to share messages across members of a sysplex, and 
the customer has a coupling facility, using notepad services might be something 
to look at.

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieai600/oa3845078.htm


Sent from ProtonMail, Swiss-based encrypted email.

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

‐‐‐ Original Message ‐‐‐
On Wednesday, November 27, 2019 12:03 PM, scott Ford  wrote:

> We use one of the system subpool SP 231 for holding messages we build from
> various ESMs. The customer asked if we could share SP231 across LPARs.
> My take was no because I understood sp231 was unique until each LPAR .
>
> Scott
>
> On Wed, Nov 27, 2019 at 11:56 AM Allan Staller allan.stal...@hcl.com
> wrote:
>
> > Each LPAR has their own.
> > SYSPLEX does not share (virtual or real) storage.
> > Selected information is shared by XCF using CTC or Coupling Facility.
> > HTH,
> > -Original Message-
> > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf
> > Of scott Ford
> > Sent: Wednesday, November 27, 2019 10:33 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Sysplex
> > I have a question related to storage subpool. If you running a sysplex do
> > you share one set of subpool, I.e., sp 1 ,,etc. or does each LPAR have its
> > own ?
> > I assumed the later.
> >
> > Scott
> >
> > --
> >
> > 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
> > ::DISCLAIMER::
> >
> > The contents of this e-mail and any attachment(s) are confidential and
> > intended for the named recipient(s) only. E-mail transmission is not
> > guaranteed to be secure or error-free as information could be intercepted,
> > corrupted, lost, destroyed, arrive late or incomplete, or may contain
> > viruses in transmission. The e mail and its contents (with or without
> > referred errors) shall therefore not attach any liability on the originator
> > or HCL or its affiliates. Views or opinions, if any, presented in this
> > email are solely those of the author and may not necessarily reflect the
> > views or opinions of HCL or its affiliates. Any form of reproduction,
> > dissemination, copying, disclosure, modification, distribution and / or
> > publication of this message without the prior written consent of authorized
> > representative of HCL is strictly prohibited. If you have received this
> > email in error please delete it and notify the sender immediately. Before
> > opening any email and/or attachments, please check them for viruses and
> > other defects.
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> 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

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

Re: Sysplex

[Laurence Chiu]

Without knowing the specific requirements sounds like the CF would be the
ideal place to store this information.

https://www.ibm.com/downloads/cas/JZB2E38Q



On Thu, Nov 28, 2019, 6:32 AM Seymour J Metz  wrote:

> The same applies to virtual machines in an LPAR; each has its own memory.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Charles Mills 
> Sent: Wednesday, November 27, 2019 12:29 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Sysplex
>
> Each LPAR is from the OS's point of view another box on the other side of
> the computer room. (Yes, you can quibble with that but it is a good way of
> thinking about it for most practical purposes.) z/OS on LPAR A has almost
> no knowledge of or visibility into LPAR B. LPAR B, after all, might not be
> running z/OS: it might be running Linux, or VSE, or VM, or a standalone
> dump, or some new OS that I am writing in my spare time.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of R.S.
> Sent: Wednesday, November 27, 2019 12:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Sysplex
>
> SP231 is a part of address space. It is virtual memory. LPAR is
> "hardware", so LPAR memory is real memory with no concepts like subpool,
> Common Area, PVT, etc. More: LPAR can host any operating system,
> including zLinux, which has no address spaces, SP231, LPA, etc.
> To repeat: NO z/OS MEMORY MAPPED TO PHYSICAL LPAR MEMORY CAN BE SHARED
> IN SYSPLEX.
>
> --
> 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: Paging Jay Maynard

[Mike Schwab]

https://twitter.com/tronguy

Pretty much ignores anything Hercules related, won't assign a replacement owner.

On Wed, Nov 27, 2019 at 11:28 AM Seymour J Metz  wrote:
>
> Does anybody have a valid e-mail address for Jay Maynard? The two I have 
> bounce.
>
>
> --
> 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



-- 
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: AUTHPGM in IKJTSOxx

[Seymour J Metz]

Well, IBM ha documented a lot of the rules for authorized code.


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



From: IBM Mainframe Discussion List  on behalf of 
Michael Stein 
Sent: Wednesday, November 27, 2019 12:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AUTHPGM in IKJTSOxx

On Tue, Nov 26, 2019 at 07:13:47PM +, Seymour J Metz wrote:
> If you have update access to APF authorized libraries then you could
> certainly write such a program, although a competent auditor would read
> you the riot act if he found out. Exploiting a program that follows the
> rules is harder.

Figuring out the "rules" is hard.  Following them is harder.

It's very easy to get an authorized function to usually work.  Writing the
code so that it works and fails correctly and is secure is much harder..

For security it's usually best to let the hardware provide the security
boundaries whereever possible (address space and protect keys).

Write access to an APF library on a personal test system is really useful
for education, development, and trying out system services.

A non-shared test system doesn't have system stability or security issues
to be concerned about.  But be very careful NEVER to run that type of
code on shared systems.

I once traced instruction counts for a path of "hit enter once" type
action.  This involved turning on instruction fetch PER and disabled
DAT off code to update a counter for each asid/instruction address.

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

[Seymour J Metz]

The same applies to virtual machines in an LPAR; each has its own memory.


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



From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Wednesday, November 27, 2019 12:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sysplex

Each LPAR is from the OS's point of view another box on the other side of the 
computer room. (Yes, you can quibble with that but it is a good way of thinking 
about it for most practical purposes.) z/OS on LPAR A has almost no knowledge 
of or visibility into LPAR B. LPAR B, after all, might not be running z/OS: it 
might be running Linux, or VSE, or VM, or a standalone dump, or some new OS 
that I am writing in my spare time.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Wednesday, November 27, 2019 12:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sysplex

SP231 is a part of address space. It is virtual memory. LPAR is
"hardware", so LPAR memory is real memory with no concepts like subpool,
Common Area, PVT, etc. More: LPAR can host any operating system,
including zLinux, which has no address spaces, SP231, LPA, etc.
To repeat: NO z/OS MEMORY MAPPED TO PHYSICAL LPAR MEMORY CAN BE SHARED
IN SYSPLEX.

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

[Charles Mills]

Each LPAR is from the OS's point of view another box on the other side of the 
computer room. (Yes, you can quibble with that but it is a good way of thinking 
about it for most practical purposes.) z/OS on LPAR A has almost no knowledge 
of or visibility into LPAR B. LPAR B, after all, might not be running z/OS: it 
might be running Linux, or VSE, or VM, or a standalone dump, or some new OS 
that I am writing in my spare time.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Wednesday, November 27, 2019 12:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sysplex

SP231 is a part of address space. It is virtual memory. LPAR is 
"hardware", so LPAR memory is real memory with no concepts like subpool, 
Common Area, PVT, etc. More: LPAR can host any operating system, 
including zLinux, which has no address spaces, SP231, LPA, etc.
To repeat: NO z/OS MEMORY MAPPED TO PHYSICAL LPAR MEMORY CAN BE SHARED 
IN SYSPLEX.

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

Paging Jay Maynard

[Seymour J Metz]

Does anybody have a valid e-mail address for Jay Maynard? The two I have bounce.


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

[scott Ford]

Hey R.S.,

Got it, a big thx that helps me a lot. I have worked SysPlexes but never
had to set them up.

Scott

On Wed, Nov 27, 2019 at 12:20 PM R.S. 
wrote:

> SP231 is a part of address space. It is virtual memory. LPAR is
> "hardware", so LPAR memory is real memory with no concepts like subpool,
> Common Area, PVT, etc. More: LPAR can host any operating system,
> including zLinux, which has no address spaces, SP231, LPA, etc.
> To repeat: NO z/OS MEMORY MAPPED TO PHYSICAL LPAR MEMORY CAN BE SHARED
> IN SYSPLEX.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> W dniu 2019-11-27 o 18:03, scott Ford pisze:
> > We use one of the system subpool SP 231 for holding messages we build
> from
> > various ESMs. The customer asked if we could share SP231 across LPARs.
> > My take was no because I understood sp231 was unique until each LPAR .
> >
> > Scott
> >
> > On Wed, Nov 27, 2019 at 11:56 AM Allan Staller 
> > wrote:
> >
> >> Each LPAR has their own.
> >>
> >> SYSPLEX does not share (virtual or real) storage.
> >> Selected information is shared by XCF using CTC or Coupling Facility.
> >>
> >> HTH,
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> Behalf
> >> Of scott Ford
> >> Sent: Wednesday, November 27, 2019 10:33 AM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Sysplex
> >>
> >> I have a question related to storage subpool. If you running a sysplex
> do
> >> you share one set of subpool, I.e., sp 1 ,,etc. or does each LPAR have
> its
> >> own ?
> >> I assumed the later.
> >>
> >>
> >> Scott
> >> --
> >> Scott Ford
> >> IDMWORKS
> >> z/OS Development
> >>
> >>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlega
> ć
> karze.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2019 r. wynosi 169.347.928 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital
> amounting to PLN 169.347.928 as at 1 January 2019.
>
> --
> 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: Sysplex

[R.S.]

SP231 is a part of address space. It is virtual memory. LPAR is 
"hardware", so LPAR memory is real memory with no concepts like subpool, 
Common Area, PVT, etc. More: LPAR can host any operating system, 
including zLinux, which has no address spaces, SP231, LPA, etc.
To repeat: NO z/OS MEMORY MAPPED TO PHYSICAL LPAR MEMORY CAN BE SHARED 
IN SYSPLEX.


--
Radoslaw Skorupka
Lodz, Poland






W dniu 2019-11-27 o 18:03, scott Ford pisze:

We use one of the system subpool SP 231 for holding messages we build from
various ESMs. The customer asked if we could share SP231 across LPARs.
My take was no because I understood sp231 was unique until each LPAR .

Scott

On Wed, Nov 27, 2019 at 11:56 AM Allan Staller 
wrote:


Each LPAR has their own.

SYSPLEX does not share (virtual or real) storage.
Selected information is shared by XCF using CTC or Coupling Facility.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf
Of scott Ford
Sent: Wednesday, November 27, 2019 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Sysplex

I have a question related to storage subpool. If you running a sysplex do
you share one set of subpool, I.e., sp 1 ,,etc. or does each LPAR have its
own ?
I assumed the later.


Scott
--
Scott Ford
IDMWORKS
z/OS Development





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2019 r. wynosi 169.347.928 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.347.928 as at 1 January 2019.

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

Re: Sysplex

[scott Ford]

David,

Yes sir, we building provisioning software for RACF, ACF2 and Top-Secret

Scott

On Wed, Nov 27, 2019 at 12:11 PM David Spiegel 
wrote:

> Hi Scott,
> "... various ESMs ..."
> Does this mean: various External Security Managers?
>
> Regards,
> David
>
> On 2019-11-27 12:03, scott Ford wrote:
> > We use one of the system subpool SP 231 for holding messages we build
> from
> > various ESMs. The customer asked if we could share SP231 across LPARs.
> > My take was no because I understood sp231 was unique until each LPAR .
> >
> > Scott
> >
> > On Wed, Nov 27, 2019 at 11:56 AM Allan Staller 
> > wrote:
> >
> >> Each LPAR has their own.
> >>
> >> SYSPLEX does not share (virtual or real) storage.
> >> Selected information is shared by XCF using CTC or Coupling Facility.
> >>
> >> HTH,
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> Behalf
> >> Of scott Ford
> >> Sent: Wednesday, November 27, 2019 10:33 AM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Sysplex
> >>
> >> I have a question related to storage subpool. If you running a sysplex
> do
> >> you share one set of subpool, I.e., sp 1 ,,etc. or does each LPAR have
> its
> >> own ?
> >> I assumed the later.
> >>
> >>
> >> Scott
> >> --
> >> 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
> >> ::DISCLAIMER::
> >> 
> >> The contents of this e-mail and any attachment(s) are confidential and
> >> intended for the named recipient(s) only. E-mail transmission is not
> >> guaranteed to be secure or error-free as information could be
> intercepted,
> >> corrupted, lost, destroyed, arrive late or incomplete, or may contain
> >> viruses in transmission. The e mail and its contents (with or without
> >> referred errors) shall therefore not attach any liability on the
> originator
> >> or HCL or its affiliates. Views or opinions, if any, presented in this
> >> email are solely those of the author and may not necessarily reflect the
> >> views or opinions of HCL or its affiliates. Any form of reproduction,
> >> dissemination, copying, disclosure, modification, distribution and / or
> >> publication of this message without the prior written consent of
> authorized
> >> representative of HCL is strictly prohibited. If you have received this
> >> email in error please delete it and notify the sender immediately.
> Before
> >> opening any email and/or attachments, please check them for viruses and
> >> other defects.
> >> 
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
>
>
> --
> 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: Sysplex

[David Spiegel]

Hi Scott,
"... various ESMs ..."
Does this mean: various External Security Managers?

Regards,
David

On 2019-11-27 12:03, scott Ford wrote:
> We use one of the system subpool SP 231 for holding messages we build from
> various ESMs. The customer asked if we could share SP231 across LPARs.
> My take was no because I understood sp231 was unique until each LPAR .
>
> Scott
>
> On Wed, Nov 27, 2019 at 11:56 AM Allan Staller 
> wrote:
>
>> Each LPAR has their own.
>>
>> SYSPLEX does not share (virtual or real) storage.
>> Selected information is shared by XCF using CTC or Coupling Facility.
>>
>> HTH,
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf
>> Of scott Ford
>> Sent: Wednesday, November 27, 2019 10:33 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Sysplex
>>
>> I have a question related to storage subpool. If you running a sysplex do
>> you share one set of subpool, I.e., sp 1 ,,etc. or does each LPAR have its
>> own ?
>> I assumed the later.
>>
>>
>> Scott
>> --
>> 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
>> ::DISCLAIMER::
>> 
>> The contents of this e-mail and any attachment(s) are confidential and
>> intended for the named recipient(s) only. E-mail transmission is not
>> guaranteed to be secure or error-free as information could be intercepted,
>> corrupted, lost, destroyed, arrive late or incomplete, or may contain
>> viruses in transmission. The e mail and its contents (with or without
>> referred errors) shall therefore not attach any liability on the originator
>> or HCL or its affiliates. Views or opinions, if any, presented in this
>> email are solely those of the author and may not necessarily reflect the
>> views or opinions of HCL or its affiliates. Any form of reproduction,
>> dissemination, copying, disclosure, modification, distribution and / or
>> publication of this message without the prior written consent of authorized
>> representative of HCL is strictly prohibited. If you have received this
>> email in error please delete it and notify the sender immediately. Before
>> opening any email and/or attachments, please check them for viruses and
>> other defects.
>> 
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>


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

Re: Sysplex

[scott Ford]

We use one of the system subpool SP 231 for holding messages we build from
various ESMs. The customer asked if we could share SP231 across LPARs.
My take was no because I understood sp231 was unique until each LPAR .

Scott

On Wed, Nov 27, 2019 at 11:56 AM Allan Staller 
wrote:

> Each LPAR has their own.
>
> SYSPLEX does not share (virtual or real) storage.
> Selected information is shared by XCF using CTC or Coupling Facility.
>
> HTH,
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of scott Ford
> Sent: Wednesday, November 27, 2019 10:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Sysplex
>
> I have a question related to storage subpool. If you running a sysplex do
> you share one set of subpool, I.e., sp 1 ,,etc. or does each LPAR have its
> own ?
> I assumed the later.
>
>
> Scott
> --
> 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
> ::DISCLAIMER::
> 
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only. E-mail transmission is not
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or may contain
> viruses in transmission. The e mail and its contents (with or without
> referred errors) shall therefore not attach any liability on the originator
> or HCL or its affiliates. Views or opinions, if any, presented in this
> email are solely those of the author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification, distribution and / or
> publication of this message without the prior written consent of authorized
> representative of HCL is strictly prohibited. If you have received this
> email in error please delete it and notify the sender immediately. Before
> opening any email and/or attachments, please check them for viruses and
> other defects.
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
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: Question - UUID Approach for Mainframes in Japan

[Cameron Conacher]

Thanks everyone
This is great.

Sent from my iPhone

> On Nov 26, 2019, at 5:23 PM, Charles Mills  wrote:
> 
> Yeah, sorry, I fully admit I have zero real-world experience with UUIDs on Z 
> -- Japanese or otherwise. And relatively little elsewhere: I have used them 
> for version signing on Visual Studio -- that's it.
> 
> I would certainly think (hope!) that any reasonable code would be using the 
> underlying 128-bit binary value, and whether you used abc, ABC or some 
> mixture would be irrelevant.
> 
> I think the standard is pretty clear: the 128-bit binary value *is* the UUI, 
> the character string is just a representation thereof, and upper-case hex 
> values are acceptable.
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Cameron Conacher
> Sent: Tuesday, November 26, 2019 9:00 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Question - UUID Approach for Mainframes in Japan
> 
> Thanks Charles,
> I was hoping someone with a Japan background would weigh in to say
> something along the lines of "have the Consumers upper case the UUID BEFORE
> they send it to you" or, "we use DATAPOWER to force upper case on all UUIDs
> BEFORE the strings arrive in the mainframe". or something else.
> 
> If a Consumer were to send me a UUID in Lower Case and I return a reply
> with the UUID Upper Cased, does this cause some inconsistency on the
> Consumer's side of the fence?
> I mean, functionally, the UUIDs are the same, but the actual string values
> are different.
> Does this create issues?
> 
> 
>> On Mon, Nov 25, 2019 at 4:30 PM Charles Mills  wrote:
>> 
>> UUID letters as generated are all lower case, so you could translate them
>> to upper case without losing any information.
>> 
>> Anything that accepts UUIDs must be prepared to accept upper case, so you
>> would be good to go.
>> 
>> -- https://tools.ietf.org/html/rfc4122#section-3
>> 
>> Charles
>> 
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Cameron Conacher
>> Sent: Monday, November 25, 2019 3:43 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Question - UUID Approach for Mainframes in Japan
>> 
>> Hello folks,
>> I am here with another question today.
>> We are a large international company with a market presence in Japan.
>> We store our mainframe EBCDIC data for these markets in EBCDIC CodePage
>> 930.
>> This CodePage has no support for lower case English letters.
>> 
>> If I were a distributed platform and I generated a UTF-8 encoded UUID
>> value, and sent this value to the mainframe, it would be then transformed
>> into EBCDIC CodePage 930.
>> If the UUID were to be generated with any lower case English values ("a",
>> "b", "c", "d", "e", or "f") I would expect to encounter some issue at
>> conversion/transformation time, since the underlying EBCDIC CodePage cannot
>> support the value.
>> However, if upper case values were sent instead ("A", "B", "C", "D", "E",
>> or "F"), everything would flow and transform politely.
>> 
>> So, my question is whether in the Japan world, mainframe application expect
>> Consumers to send only upper cased values, or if an intermediate step prior
>> to message transformation occurs close to the mainframe side of things to
>> force upper casing of the UUID.
>> Or some other technique?
>> Similarly, if a UUID were to be sent from the mainframe to the middle tier
>> somewhere, should I expect that the mainframe would only pas along upper
>> cased values in the UUID area?
>> 
>> I believe I can handle things on the mainframe side by transforming the
>> entire message to UTF-16BE, and then upper casing the UUID, and then
>> transforming this updated UTF-16BE message area to EBCDIC CodePage 930.
>> Not sure if this is a "good" way, but it would work.
>> 
>> Any thoughts?
>> 
>> Thanks
>> 
>> ...Cameron
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Sysplex

[Allan Staller]

Each LPAR has their own.

SYSPLEX does not share (virtual or real) storage.
Selected information is shared by XCF using CTC or Coupling Facility.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
scott Ford
Sent: Wednesday, November 27, 2019 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Sysplex

I have a question related to storage subpool. If you running a sysplex do you 
share one set of subpool, I.e., sp 1 ,,etc. or does each LPAR have its own ?
I assumed the later.


Scott
--
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
::DISCLAIMER::

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


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

Re: Sysplex

[R.S.]

W dniu 2019-11-27 o 17:33, scott Ford pisze:

I have a question related to storage subpool. If you running a sysplex do
you share one set of subpool, I.e., sp 1 ,,etc. or does each LPAR have its
own ?
I assumed the later.


I don't understand.
In Sysplex there is no shared memory. In Parallel Sysplex there is 
shared memory, but it resides Coupling Facility and its structures - 
memory objects.
AFAIK the subpool you described is part of address space, which is 
totally local despite your z/OS is in monoplex or any kind of sysplex. 
It cannot be shared. Maybe some definitions are shared (usually should 
be shared), but this is different story.


--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2019 r. wynosi 169.347.928 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.347.928 as at 1 January 2019.

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

Sysplex

[scott Ford]

I have a question related to storage subpool. If you running a sysplex do
you share one set of subpool, I.e., sp 1 ,,etc. or does each LPAR have its
own ?
I assumed the later.


Scott
-- 
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: WTO

[scott Ford]

John,

Absolutely, my big issue I was at the mercy of CA code. Not blaming them,
but it’s a CA product and I wished their doc was better.

Scott

On Wed, Nov 27, 2019 at 7:39 AM John McKown 
wrote:

> On Tue, Nov 26, 2019 at 2:40 PM Seymour J Metz  wrote:
>
> > Of course it was reentrant, but was it good form? I prefer to protect
> code
> > against wild stores by marking it as r/o.
> >
>
> Total agreement that it is bad form in today's world. For subsystems, there
> is the SSCT to anchor things. And, as I do for my re-entrant code: a
> Name/Token pair (primary address space level) to hold a 64-bit pointer
> (even in 24 or 31 bit mode, I make sure the pointer is 64-bit clean)..
>
>
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> People in sleeping bags are the soft tacos of the bear world.
> Maranatha! <><
> John McKown
>
> --
> 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: SMFPRMFxx SYS SUBSYS and EXITs question

[Peter Relson]

Does the list of exits in the SUBSYS specification overwrite all those in 
SYS, that is, in this case, it reduces the list of exits from the ten in 
the SYS specification to just the two that are explicitly listed? 


For a subsystem identified by SUBSYS (STC in your case), yes. 
For a subsystem not identified by SUBSYS, the SYS specification applies.

SYS is a "default", a "backup" for the cases where you do not provide your 
own override list.

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

[John McKown]

On Tue, Nov 26, 2019 at 2:40 PM Seymour J Metz  wrote:

> Of course it was reentrant, but was it good form? I prefer to protect code
> against wild stores by marking it as r/o.
>

Total agreement that it is bad form in today's world. For subsystems, there
is the SSCT to anchor things. And, as I do for my re-entrant code: a
Name/Token pair (primary address space level) to hold a 64-bit pointer
(even in 24 or 31 bit mode, I make sure the pointer is 64-bit clean)..


>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown

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