Variable Pool

[Paul Gilmartin]

In: z/OS 2.5 ISPF Edit and Edit Macros
IBM SC19-3621-50

I find seven uses of the term, "variable pool". None of these appears to be
a defining occurrence. The term does not appear in the Index. Is it defined
elsewhere? If so, there should be a cross-reference/hyperlink. There is no
"Related Publications" list as is typical of IBM publications.

It seems to mean a list of names which are enclosed in parentheses. I've used
:(name)" to access REXX variables in Edit macros. Are there variable pools
other than the set of REXX symbols? If so, what is the search order?

It feels as if an RCF is needed.

--
Thanks,
gil

[Dave Salt]

My understanding is there are 3 variable pools; function, shared, and profile. Using REXX as an example, the function pool is created when a REXX procedure begins execution, and deleted when the REXX procedure ends. Any variables set by the REXX procedure are available only while that procedure is executing, and aren't available to any other REXX procedures (unless they're specifically passed as arguments). For example, if REXXA sets COLOR to GREEN, that value is only available to REXXA and only exists until REXXA stops executing.

The shared pool is created whenever something is called using NEWAPPL, and deleted when the application ends. For example, the SimpList vendor product is called using NEWAPPL(SLST). The SHARED pool exists for SLST until the user exits SimpList. If another SimpList session is opened while the first SimpList session is in use (e.g. in split screen), a separate SHARED pool is created for the second SimpList session (and so on). Throughout each SimpList session, VPUT and VGET can be used to store variables and retrieve them from the SHARED pool for that particular SimpList session. For example, REXXA sets COLOR to BLUE, VPUTs COLOR in the SHARED pool, and exits. Later, during that same SimpList session, REXXB VGETs COLOR from the SHARED pool, and the value of COLOR in the REXXB function pool is now BLUE. Meanwhile, in a separate SimpList session, COLOR might have been set to RED or some other value.

The profile pool is created the very first time something is called using NEWAPPL, and is never deleted (unless someone takes a specific action to delete it). For example, the very first time a user enters a SimpList session, a member called SLSTPROF is created in their PROFILE data set. Anything VPUT to SLSTPROF will be there forever; next day, next week, next year (unless VERASE is used to erase a variable). There is only one SLSTPROF member, so it's shared across ALL SimpList sessions. Therefore, if REXXA sets COLOR to PINK and VPUTS it in the PROFILE, and REXXB is executing in a different split screen session and VGETS COLOR, the value of COLOR in the REXXB function pool will also be PINK.

It's late and I'm rushing to write this before I get to bed, but hopefully it provides a decent understanding of how the variable pools work.

Dave Salt

SimpList™ - try it; you'll get it!

https://www.mackinney.com/products/program-development/simplist.html 

---

From: 'Paul Gilmartin' via ISPF discussion list <ispf-...@nd.edu>
Sent: February 8, 2023 10:24 PM
To: ISPF-List <ispf-...@nd.edu>
Subject: [ISPF-L] Variable Pool

 

--
You received this message because you are subscribed to the Google Groups "ISPF discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ispf-l-list...@nd.edu.
To view this discussion on the web visit https://groups.google.com/a/nd.edu/d/msgid/ispf-l-list/5e4a6a52-35f6-4871-2b5d-2a27b2a615c6%40AIM.com.

[Binyamin Dissen]

Look at the ISPF Users Guide.

The variables pools are ISPF, not EDIT. EDIT uses ISPF services.

On Wed, 8 Feb 2023 20:24:51 -0700 "'Paul Gilmartin' via ISPF discussion list"
<ispf-...@nd.edu> wrote:

:>In: z/OS 2.5 ISPF Edit and Edit Macros

--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

[Frank Clarke]

Thank you, Dave.   That was very clear.

To view this discussion on the web visit https://groups.google.com/a/nd.edu/d/msgid/ispf-l-list/IA1PR12MB74964ECD276EB65C8D34D8C0A1D99%40IA1PR12MB7496.namprd12.prod.outlook.com.

[Pedro Vera]

The variable pool is discussed in Dialog Developer's Guide and Reference, chapter 3 under "Using the variable services".

[Paul Gilmartin]

On 2/10/23 13:27:08, Pedro Vera wrote:
> The variable pool is discussed in Dialog Developer's Guide and Reference,
> chapter 3 under "Using the variable services".

Thanks. In: z/OS 2.5 ISPF Dialog Developer's Guide and Reference
IBM SC19-3619-50
Chapter 3,
I see no mention of accessing variables in macros with "(name)".

Where is the lexical syntax of ISPF variables specified?

>> On Wednesday, February 8, 2023 at 11:53:00 PM EST, Dave Salt wrote:
>>
>> My understanding is there are 3 variable pools; function, shared, and
>> profile.

Thanks. A more complete description than I've found elsewhere. It's
unsettling that you begin with "My understanding is ..." It appears as if
there is no readily accessible description, but you have gleaned it over
time, even somewhat by trial and error.

Using REXX as an example, the function pool is created when a REXX
>> procedure begins execution, and deleted when the REXX procedure ends. Any
>> variables set by the REXX procedure are available

By unpleasant experience, not "Any variables", but apparently only those
whose lexical syntax conforms to that of ISPF variables (wherever that's
described.) I learned that to my dismay when I tried to use
"(compound.symbol)" in an ISREDIT command in a macro. This restriction needs
to be stated clearly for those (like me) more familiar with REXX than with
ISPF.

The Macro book needs a citation of the description of the constructs to access
macro (e.g. REXX) variables.

RCF sorely needed.

--
gil

[Jeffrey Ranney]

Excellent reply, Dave!! 

To view this discussion on the web visit https://groups.google.com/a/nd.edu/d/msgid/ispf-l-list/IA1PR12MB74964ECD276EB65C8D34D8C0A1D99%40IA1PR12MB7496.namprd12.prod.outlook.com.

[Marvin Knight]

As Pedro stated, variable pools are described in Chapter 3 of the ISPF Dialog Reference Guide. Chapter 1 also has the naming convention. Services may reference a variable in different ways as described by the service. In the case of Edit Macros Chapter 6 of the Edit Macros manual describes how variables are used under the "Using commands in edit macros" section.

Marvin Knight

-----Original Message-----
From: 'Paul Gilmartin' via ISPF discussion list <ispf-...@nd.edu>

--
You received this message because you are subscribed to the Google Groups "ISPF discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ispf-l-list...@nd.edu.

To view this discussion on the web visit https://groups.google.com/a/nd.edu/d/msgid/ispf-l-list/72fc4033-5d6f-be81-299a-1ce37e8234d3%40AIM.com .

[Paul Gilmartin]

On 2/10/23 15:53:32, Marvin Knight wrote:

> As Pedro stated, variable pools are described in Chapter 3 of the ISPF Dialog Reference Guide. Chapter 1 also has the naming convention. Services may reference a variable in different ways as described by the service. In the case of Edit Macros Chapter 6 of the Edit Macros manual describes how variables are used under the "Using commands in edit macros" section.

Thanks. There, I read:
Variables
Variables function in edit macros in the same way as in CLISTs and REXX EXECs.
The only exceptions are dialog variables—variables that communicate with ISPF
and the PDF component—which can only have names from 1 to 8 characters in
length.

But, then, why did I get an error when I tried such as (adapting a later
example:
'ISREDIT (FOO.BAR) = LINE 1'
"FOO.BAR" is a valid REXX variable name,7 characters in length, which is
between 1 and 8.
"Ain't no rule sayin' a dog cain't play basketball."

It violates "the exception that proves the rule." "can only have names from
1 to 8 characters in length" leads readers to believe that this is the only
exception and that names not violating it are acceptable.

Generally, the document badly conflates REXX and ISREDIT syntax, leading
ultimately to programmer confusion. The examples seem correct; they shulld
work, but they do not instill understanding. for example:
'ISREDIT (LINEDATA) = LINE 1'
could be written:
ADDRESS ISREDIT '(LINEDATA) = LINE 1'
or even:
EDCMD = '(LINEDATA) = LINE 1'
ADDRESS ISREDIT
EDCMD /* No apostrophes needed here. */

The text concerning substitution is horribly garbled. It conflates substitution
by the REXX processor with substitution by ISREDIT, confusing rather than
enlightening the reader.

--
Thanks,
gil

[Pedro Vera]

re: " "FOO.BAR" is a valid REXX variable name,7 characters in length, which is
between 1 and 8"

 

I think the rexx manual refers to that as a compound variable, to differentiate that from a simple variable name.

[robhb...@gmail.com]

Paul, I don't think I've ever had to do this but I'm sure this is just a matter of paying attention to who is interpreting each part of the string. I'm sure this'll work if you reärrange the quotes:

address ISREDIT '('foo.bar') = LINE 1'

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* If "compassionate conservative" is an oxymoron, then so is "liberal values". -John Aul (ja...@symon.com), quoted in A Word A Day */

-----Original Message-----
From: 'Paul Gilmartin' via ISPF discussion list <ispf-...@nd.edu>

Sent: Friday, February 10, 2023 18:51

....why did I get an error when I tried such as (adapting a later example:

[Pedro Vera]

re: " I'm sure this'll work if you reärrange the quotes"

 

It will not work.  The intent of the original statement was to get a line of data from the editor and put that value into variable foo.bar.  If you rearrange the quotes, it will resolve the foo.bar variable first and then use that as the variable name.  The first time through it will likely fail if foo.bar was not initialized.  For it to work, foo.bar needs to first be assigned the value of a 1-8 character name.  And even then, the line from the editor will not be put into foo.bar as was originally intended.

 

I suggest this simple workaround:
   address ISREDIT '(tempvar) = LINE 1'

   foo.bar = tempvar 

 

Yeah, the extra movement of data adds additional work for the processor, but the statement syntax limits what you can do.  You have to program around its shortcomings.

[Paul Gilmartin]

On 2/11/23 12:54:57, Pedro Vera wrote:
> re: " I'm sure this'll work if you reärrange the quotes"
>
> It will not work. The intent of the original statement was to get a line
> of data from the editor and put that value into variable foo.bar. If you
> rearrange the quotes, it will resolve the foo.bar variable first and then
> use that as the variable name. The first time through it will likely fail

This illustrates the folly of attempting to document REXX, which is documented
elsewhere, in an ISPF manual. It's simply misleading.

> if foo.bar was not initialized. For it to work, foo.bar needs to first be
> assigned the value of a 1-8 character name. And even then, the line from

foo.bar *is* a 1-8 character name, the only restriction stated in the topic.

> the editor will not be put into foo.bar as was originally intended.
>
> I suggest this simple workaround:
> address ISREDIT '(tempvar) = LINE 1'
> foo.bar = tempvar
>
> Yeah, the extra movement of data adds additional work for the processor,
> but the statement syntax limits what you can do. You have to program
> around its shortcomings.

The ISPF designers did extra work performing needless (and undocumented)
syntax checking requiring the user to code an extra statement. The
"work for the processor" is probably inconsequential, but brevity
improves clarity.

--
gil

[Pedro Vera]

re: " foo.bar *is* a 1-8 character name"

 

I should have said:

For it to work, foo.bar needs to first be assigned the value of a 1-8 character ISPF variable name.

[robhb...@gmail.com]

Oh, duh! Sorry, I wasn't paying attention - thought we were talking about a VPUT. Yeah, I know, there's nothing that implies that, I just jumped ahead without thinking. Sorry, my bad.

The only thing I still think I said right there, then, is the part about who's interpreting each part of the command. "(X) = LINE 1" isn't a REXX statement, it's an ISREDIT statement; and foo.bar isn't an ISREDIT variable name, it's a REXX variable name. Now that you've put me straight, I don't see a way to combine them (the way I was attempting had it been a VPUT).

It's all your fault for not trying to use VPUT, that's what it is.

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* For Sale: Parachute. Only used once, never opened, small stain. */

-----Original Message-----
From: 'Paul Gilmartin' via ISPF discussion list <ispf-...@nd.edu>

Sent: Saturday, February 11, 2023 15:10

> It will not work. The intent of the original statement was to get a
> line of data from the editor and put that value into variable foo.bar.
> If you rearrange the quotes, it will resolve the foo.bar variable
> first and then use that as the variable name. The first time through
> it will likely fail

[Pedro Vera]

Perhaps some historical perspective would be helpful.  (some of this happened before I joined IBM):

1. CLIST language came first (maybe early 1970's)

2. ISPF came somewhere in late 1970's.  It seemed to integrate nicely with clists, using similar variable name syntax.

 

3. Rexx came in the mid 1980's.  It has a more powerful variable name capability.  Rexx integrates well with ISPF if it only uses ISPF  variable naming conventions.  (a guess...) IBM wants to keep downward compatibility for everything, so never updated ISPF to allow rexx compound variables.  

 

And here we are 40 years later still confused about it!  

[Paul Gilmartin]

On 2/12/23 00:03:30, Pedro Vera wrote:

> ...

> 3. Rexx came in the mid 1980's. It has a more powerful variable name
> capability. Rexx integrates well with ISPF if it only uses ISPF variable
> naming conventions. (a guess...) IBM wants to keep downward compatibility
> for everything, so never updated ISPF to allow rexx compound variables.
>
> And here we are 40 years later still confused about it!

The second-most confused group is the tech writers. The most confused is
the readers.

Downward compatibility should not be a concern. REXX can only benefit from
relaxation of the syntax. Program interfaces from FORTRAN, PL/I, COBOL, ...
can remain unchanged with their restrictions. COBOL has always supported
long variable names, but coders of Edit macros in COBOL don't seem to be
complaining.

For REXX, strings between parentheses and delimited by '(', ')' ',', and ' '
should simply be passed as-is, full length to IRXEXCOM, which should be
the sole arbiter of syntax.

I was mistaken when I said "variable pool" is not REXX jargon. The term
occurs eleven times in SO/E REXX Reference SA32-0972-50, All late in the
book in sections I'd consider advanced topics, beginning with
Chapter 12. TSO/E REXX programming services...239. I haven't read that part
since long ago, under CMS.

I don't find the term adequately explained; I've submitted an RCF.

ISPF Edit and Edit Macros should state whether or not this is the same
"variable pool" it mentions, with citation/hyperlink to the Rexx document.

Intriguing is:
Return code
-1 • Another task is accessing the variable pool

Does multitasking affect ISPF?

In the ISPF Macros book:
...
2. In the REXX environment, the REXX variable pool and the dialog function
variable pool are also merged. Therefore, quoted variable names in
parentheses are the same as unquoted variable names, except that the editor
does the symbolic substitution rather than the REXX processor.

This needs clarification, at least that "names" must be syntactically legal
to both REXX and ISPF, with citatations/hyperlinks to each. ISPF should
not replicate either specification. Such repetition is treacherous.

"quoted"-"unquoted" needs clarification. Bob Bridges got it exactly backward.
Examples elsewhere in the chapter should be cited.

"merged" is frightening. Are variables copied from the REXX variable pool
to the dialog function variable pool or the reverse? In case of identcal
names, which dominates? Does merging make dialog variables available to
REXX? Is the merging performed once, perhaps at ISREDIT MACRO, or befpre
executing each ISREDIT command. Is this affected by PROCEDURE EXPOSE/
or is the "merge" imaginary; simply by concatenating the REXX and function
variable pools (but which dominates?)

The "length 1-8" mentioned elsewhere misleads REXX programmers to believe
(hope) that is the only limitation, and compound symbols are permitted.
It should be replaced by a citation/hyperlink to the point where the syntax
of ISPF variables is specified.

--
Thanks,
gil

[Marvin Knight]

The ISPF Dialog variables syntax is described in the "z/OS ISPF Dialog Developer's Guide and Reference" around page 6 or 7 depending on the z/OS version you reference:
https://www.ibm.com/docs/en/zos/2.5.0?topic=ispf-dialog-variables

"Dialog variables are referred to symbolically. The name is composed of 1 to 8 characters (6 for FORTRAN). Alphanumeric characters A-Z, 0-9, #, $, or @ can be used in the name, but the first character cannot be numeric. APL variable names cannot contain #, $, or @."

In this section we also state:

"The use of STEM or COMPOUND variables within a REXX procedure is not supported by ISPF."
--------------
As Pedro stated SPF was developed around 1975 and then ISPF around 1980. Edit is a dialog that runs under ISPF Dialog Manager. When an Edit macro runs it actually generates a SELECT CMD/PGM to invoke it. So for REXX or a CLIST the function pool will interface with TSO. ISPF calls IKJCT441 to update/retrieve variables. A VGET would use the SHARE/PROFILE pool and update the function pool (call to IKJCT441).

Marvin Knight

-----Original Message-----
From: 'Paul Gilmartin' via ISPF discussion list <ispf-...@nd.edu>

Sent: Sunday, February 12, 2023 11:51 AM
To: ispf-...@nd.edu
Subject: [EXTERNAL] Re: [ISPF-L] Variable Pool

--
You received this message because you are subscribed to the Google Groups "ISPF discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ispf-l-list...@nd.edu.

To view this discussion on the web visit https://groups.google.com/a/nd.edu/d/msgid/ispf-l-list/0ea4de94-188e-4246-77ed-16f379e40018%40AIM.com .