Re: Specifhing the ENVBLOCK (was: Just PDSE)

[Seymour J Metz]

The point is that while lookup only involves a chain, nothing in the 
documentation even hints that validation only involves the chain for the 
current TCB.


From: IBM Mainframe Discussion List  on behalf of 
Attila Fogarasi 
Sent: Wednesday, April 12, 2023 7:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Specifhing the ENVBLOCK (was: Just PDSE)

Separate chains per TCB, so linear chain within TCB but no correlation
between TCBs.  Programs that use conflicting or incompatible environments
across multiple TCBs are on their own :)

On Mon, Apr 10, 2023 at 10:54 PM Seymour J Metz  wrote:

> "However, separate chains within a single address space are independent."
> doesn't sound like a single chain.
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
> Sent: Sunday, April 9, 2023 5:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Specifhing the ENVBLOCK (was: Just PDSE)
>
> On Sun, 9 Apr 2023 20:41:33 +, Seymour J Metz wrote:
>
> >Curse you, OCO!
> >
> >I suspect that validating a potential ENVB address requires running a
> tree rather than just a list.
> >
> <
> https://www.ibm.com/docs/en/zos/2.5.0?topic=environments-chains-how-are-located
> >
> shows only linear chains.  So there can't be other kids of trees.
>
> --
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: Specifhing the ENVBLOCK (was: Just PDSE)

[Attila Fogarasi]

Separate chains per TCB, so linear chain within TCB but no correlation
between TCBs.  Programs that use conflicting or incompatible environments
across multiple TCBs are on their own :)

On Mon, Apr 10, 2023 at 10:54 PM Seymour J Metz  wrote:

> "However, separate chains within a single address space are independent."
> doesn't sound like a single chain.
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
> Sent: Sunday, April 9, 2023 5:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Specifhing the ENVBLOCK (was: Just PDSE)
>
> On Sun, 9 Apr 2023 20:41:33 +, Seymour J Metz wrote:
>
> >Curse you, OCO!
> >
> >I suspect that validating a potential ENVB address requires running a
> tree rather than just a list.
> >
> <
> https://www.ibm.com/docs/en/zos/2.5.0?topic=environments-chains-how-are-located
> >
> shows only linear chains.  So there can't be other kids of trees.
>
> --
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Specifhing the ENVBLOCK (was: Just PDSE)

[Seymour J Metz]

"However, separate chains within a single address space are independent." 
doesn't sound like a single chain.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, April 9, 2023 5:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Specifhing the ENVBLOCK (was: Just PDSE)

On Sun, 9 Apr 2023 20:41:33 +, Seymour J Metz wrote:

>Curse you, OCO!
>
>I suspect that validating a potential ENVB address requires running a tree 
>rather than just a list.
>
<https://www.ibm.com/docs/en/zos/2.5.0?topic=environments-chains-how-are-located>
shows only linear chains.  So there can't be other kids of trees.

--
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: Just PDSE

[Andrew Rowley]

On 8/04/2023 2:23 pm, Brian Westerman wrote:

Just so you know, it's not SYSPLEX that you need, it's GRS and you have have 
that with just a couple FICON ports.


Are you sure about that? Regular PDS needs GRS to safely share between 
multiple systems, if that was all that was required no-one would have 
additional issues with PDSE.


Just because it hasn't happened doesn't mean you are not vulnerable to 
data corruption with the right set of circumstances.


--
Andrew Rowley
Black Hill Software

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

Re: Specifhing the ENVBLOCK (was: Just PDSE)

[Paul Gilmartin]

On Sun, 9 Apr 2023 20:41:33 +, Seymour J Metz wrote:

>Curse you, OCO!
>
>I suspect that validating a potential ENVB address requires running a tree 
>rather than just a list.
>

shows only linear chains.  So there can't be other kids of trees.

-- 
gil

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

Re: Specifhing the ENVBLOCK (was: Just PDSE)

[Seymour J Metz]

Curse you, OCO!

I suspect that validating a potential ENVB address requires running a tree 
rather than just a list.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, April 9, 2023 3:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Specifhing the ENVBLOCK (was: Just PDSE)

(Subject: changed: this has drifted far from"PDSE")

On Sun, 9 Apr 2023 09:50:44 +, Seymour J Metz wrote:

>Chapter 12. TSO/E REXX programming services
>
Thanks.  Eek!  TMI.  Where I see:
Entry specifications
For the IRXEXCOM routine, the contents of the registers on entry are:
Register 0  Address of an environment block (optional)

It should clarify that with "see Parameter 5 (below)"
Where it says:
... However, IRXEXCOM does not check whether the address is valid.
Ouch!
And the concern raised earlier that many languages don't allow control
of R0 is serious.  REXX should provide standard CALL interfaces.

The Services book mentions IKJCT441 as an alternative.  However:
IKJCT441 uses the REXX direct interface (rather than the symbolic
interface).  Why this serious restriction?  Compatibility with CLIST
limitations?

Is there a callable service that returns a *valid* EXECBLOCK address?

>"f you do not specify an address in the environment block address parameter, 
>the TSO/E REXX routine
>checks register 0 for the address of an environment block. If register 0 
>contains the address of a
>valid environment block, the routine runs in the environment represented by 
>that environment block.
>If the address is not valid, the routine locates the current non-reentrant 
>environment and runs in that
>
There is much mention of environment chains.  How are those chains rooted?
It may not matter if it has no supported user interface.

How does it check for validity?  Merely verifying the identifier "ENVBLOCK"?
Or does it verify that block exists in a chain.

>environment. If register 0 contains a 0, the routine immediately searches for 
>the last non-reentrant
>environment created, thereby eliminating the processing required to check 
>whether register 0 contains a
>valid environment block address."

So it's quicker to search a list than validate a passed address!?

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

Specifhing the ENVBLOCK (was: Just PDSE)

[Paul Gilmartin]

(Subject: changed: this has drifted far from"PDSE")

On Sun, 9 Apr 2023 09:50:44 +, Seymour J Metz wrote:

>Chapter 12. TSO/E REXX programming services
>
Thanks.  Eek!  TMI.  Where I see:
Entry specifications
For the IRXEXCOM routine, the contents of the registers on entry are:
Register 0  Address of an environment block (optional)

It should clarify that with "see Parameter 5 (below)"
Where it says:
... However, IRXEXCOM does not check whether the address is valid. 
Ouch!
And the concern raised earlier that many languages don't allow control
of R0 is serious.  REXX should provide standard CALL interfaces.

The Services book mentions IKJCT441 as an alternative.  However:
IKJCT441 uses the REXX direct interface (rather than the symbolic
interface).  Why this serious restriction?  Compatibility with CLIST
limitations?

Is there a callable service that returns a *valid* EXECBLOCK address?

>"f you do not specify an address in the environment block address parameter, 
>the TSO/E REXX routine
>checks register 0 for the address of an environment block. If register 0 
>contains the address of a
>valid environment block, the routine runs in the environment represented by 
>that environment block.
>If the address is not valid, the routine locates the current non-reentrant 
>environment and runs in that
>
There is much mention of environment chains.  How are those chains rooted?
It may not matter if it has no supported user interface.

How does it check for validity?  Merely verifying the identifier "ENVBLOCK"?
Or does it verify that block exists in a chain.

>environment. If register 0 contains a 0, the routine immediately searches for 
>the last non-reentrant
>environment created, thereby eliminating the processing required to check 
>whether register 0 contains a
>valid environment block address."

So it's quicker to search a list than validate a passed address!?

-- 
gil

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

Re: Just PDSE

[Seymour J Metz]

Chapter 12. TSO/E REXX programming services

"f you do not specify an address in the environment block address parameter, 
the TSO/E REXX routine
checks register 0 for the address of an environment block. If register 0 
contains the address of a
valid environment block, the routine runs in the environment represented by 
that environment block.
If the address is not valid, the routine locates the current non-reentrant 
environment and runs in that
environment. If register 0 contains a 0, the routine immediately searches for 
the last non-reentrant
environment created, thereby eliminating the processing required to check 
whether register 0 contains a
valid environment block address."


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
Sent: Saturday, April 8, 2023 9:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Just PDSE

On Sun, 9 Apr 2023 00:14:46 +, Seymour J Metz wrote:

>Presumably R0  should be zero if not pointing to an ENVB.
>
Cite the source, please.

--
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: Just PDSE

[Paul Gilmartin]

On Sun, 9 Apr 2023 00:14:46 +, Seymour J Metz wrote:

>Presumably R0  should be zero if not pointing to an ENVB.
>
Cite the source, please.

-- 
gil

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

Re: Just PDSE

[Seymour J Metz]

Presumably R0  should be zero if not pointing to an ENVB.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, April 8, 2023 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Just PDSE

On Fri, 7 Apr 2023 21:47:54 -0400, Tony Harminc wrote:
>
>While looking at the help for CALL, I see - shades of another recent
>discussion - that there is now a NOENVB | PASSENVB option:
>
>NOENVB   The NOENVB operand indicates that the REXX environment
> block (ENVBLOCK) address is not to be passed to the called
> program in register 0.  This is the default.
>
>Yeah, but *what* ENVB does it pass if you override the default? The
>help doesn't say.
>
That faithfully paraphrases the omission in:
<https://www.ibm.com/docs/en/zos/2.5.0?topic=irxexcom-entry-specifications>:
Entry specifications
...
Register 0
Address of an environment block (optional)

I can cause R0 to contain the Address of an environment block with
L R0,=A(ENVBLOCK)
but since it's documented as "optional", I should simply be able to
omit that instruction and R0 will contain residual data.  Is that OK?
It doesn't say.

--
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: Just PDSE

[Paul Gilmartin]

On Fri, 7 Apr 2023 21:47:54 -0400, Tony Harminc wrote:
>
>While looking at the help for CALL, I see - shades of another recent
>discussion - that there is now a NOENVB | PASSENVB option:
>
>NOENVB   The NOENVB operand indicates that the REXX environment
> block (ENVBLOCK) address is not to be passed to the called
> program in register 0.  This is the default.
>
>Yeah, but *what* ENVB does it pass if you override the default? The
>help doesn't say.
>
That faithfully paraphrases the omission in:
:
Entry specifications
...
Register 0
Address of an environment block (optional)

I can cause R0 to contain the Address of an environment block with
L R0,=A(ENVBLOCK)
but since it's documented as "optional", I should simply be able to
omit that instruction and R0 will contain residual data.  Is that OK?
It doesn't say.

-- 
gil

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

Re: Just PDSE

[Brian Westerman]

Just so you know, it's not SYSPLEX that you need, it's GRS and you have have 
that with just a couple FICON ports.

I have been doing it at several sites now that really don't need CF's (and some 
who can't afford them) and it works very well, no problems at all.

Brian

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

Re: Just PDSE

[Tony Harminc]

On Fri, 7 Apr 2023 at 20:44, Paul Gilmartin
<042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
[...]
> Heck, you can't even:
> //RUN  EXEC PGM='MYNAME.LINKLIB(MYFILE)',PARM='Wonbat'
>
> Even though TSO lets you:
> CALL 'MYNAME.LINKLIB(MYFILE)'  'Wonbat'
>
> And why does TSO force the parm to uppercase while JCL accepts it asis?

There's an ASIS option on CALL. My guess is that the upcasing was put
in in the early days of TSO, when although JCL would accept lower case
PARM= strings, nobody was really using them. But most early TSO
terminals such as the 2741 and later 3270 did have lower (mixed) case,
and so I guess it was seen as a measure of compatibility. ASIS was
added much later (1990s?).

While looking at the help for CALL, I see - shades of another recent
discussion - that there is now a NOENVB | PASSENVB option:

NOENVB   The NOENVB operand indicates that the REXX environment
 block (ENVBLOCK) address is not to be passed to the called
 program in register 0.  This is the default.

Yeah, but *what* ENVB does it pass if you override the default? The
help doesn't say.

Tony H.

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

Re: Just PDSE

[Paul Gilmartin]

On Fri, 7 Apr 2023 22:10:15 +, Frank Swarbrick wrote:

>z/OS for UNIX files holds program objects, just like PDSE as far as I know.
>Now all we need is
>//RUN  EXEC PGM='/u/myname/myexefile'
>
Heck, you can't even:
//RUN  EXEC PGM='MYNAME.LINKLIB(MYFILE)',PARM='Wonbat'

Even though TSO lets you:
CALL 'MYNAME.LINKLIB(MYFILE)'  'Wonbat'

And why does TSO force the parm to uppercase while JCL accepts it asis?

>And, of course, allowing UNIX files in JOBLIB/STEPLIB.
>
Yup.  But resolving any of those inconsistencies would require violating
Conway's Law, which seems to be a guiding principle of IBM design.

-- 
gil

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

Re: Just PDSE

[Frank Swarbrick]

z/OS for UNIX files holds program objects, just like PDSE as far as I know.
Now all we need is
//RUN  EXEC PGM='/u/myname/myexefile'

And, of course, allowing UNIX files in JOBLIB/STEPLIB.

From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Friday, April 7, 2023 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Just PDSE

On Fri, 7 Apr 2023 16:17:04 +, Gibney, Dave wrote:

>The issue with this has always been and still is the fact that you cannot 
>safely share PDES without SYSPLEX (perhaps not full SYSPLEX) ...
>
Do program objects in a z/FS directory satisfy (some) requirements for PDSE?

--
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: Just PDSE

[Paul Gilmartin]

On Fri, 7 Apr 2023 17:18:52 +, Gibney, Dave wrote:
>
>> -Original Message-
>> From:  Paul Gilmartin
>> >
>> Do program objects in a z/FS directory satisfy (some) requirements for PDSE?
>
>Maybe, but you still cant share without SYSPLEX
>
In the old, old days, before *HFS* sharing existed we began using NFS.
+ No sysplex requirement.  In our test lab we had a larger number of
  systems at a greater spread of releases than sysplex supports.
+ It supported sharing to our Solaris desktops.  We had a problem with
  MVS NFS server and Solaris client.  We didn't bother to chase it. we
  relied on Solaris server and MVS client. 
+ Program objects on the Solaris server ran fine on the MVS clients.

- Extended attributes weren't supported.  We lived without them.

Still, I wonder about COBOL.  Is Enterprise COBOL fully supported
by zFS; no PDSE requirement?

-- 
gil

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

Re: Just PDSE

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Paul Gilmartin
> Sent: Friday, April 7, 2023 9:47 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Just PDSE
> 
> On Fri, 7 Apr 2023 16:17:04 +, Gibney, Dave wrote:
> 
> >The issue with this has always been and still is the fact that you cannot
> safely share PDES without SYSPLEX (perhaps not full SYSPLEX) ...
> >
> Do program objects in a z/FS directory satisfy (some) requirements for PDSE?


Maybe, but you still cant share without SYSPLEX

> 
> --
> 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: Just PDSE

[Paul Gilmartin]

On Fri, 7 Apr 2023 16:17:04 +, Gibney, Dave wrote:

>The issue with this has always been and still is the fact that you cannot 
>safely share PDES without SYSPLEX (perhaps not full SYSPLEX) ...
>
Do program objects in a z/FS directory satisfy (some) requirements for PDSE?

-- 
gil

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

Just PDSE

[Gibney, Dave]

The issue with this has always been and still is the fact that you cannot 
safely share PDES without SYSPLEX (perhaps not full SYSPLEX) but still more 
than our small couple LPAR shop needed, And since our development to production 
path was from Development LPAR to Production LPAR via libraries on a shared 
disk, somewhat of a non-starter.

We got burnt a long time ago with an ISV that distributed their parmlib in a 
PDSE, which we unknowingly at the time shared.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Seymour J Metz
> Sent: Friday, April 7, 2023 5:52 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: LE runtime

> I would be tempted to just switch to PDSE and be done with it. Of course,
> that doesn't help with the C++ issue, but it's still one less thing to worry
> about.
> 

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