ISPF TBGET returned valued

[Joseph Reichman]

Hi

I am submitting a number of jobs and monitoring their status with Rexx/SDSF

If a job is on execution queue from ISFEXEC ST I look at he phasename variable/stem

I save the values in a ISPF table

After I do an ISFEXEC ST I do a 2 checks
1) if they are in the table
2) if their original status was awaiting execution and now it’s executing I would like to change that corresponding variable from that row to executing
So when I get a RC 0 from TBSCAN the numeric rowid is returned

I then do a TBGET with that rowid and have SAVENAME point to a variable
SAVENAME(therow)

The doc says Dialog manager will return to me a list of variables enclosed my parenthesis having the value of that row

I so say ‘ therow = ‘ therow before and after the tbget and there is nothing in therow

Thanks

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

[ITschak Mugzach]

SAVENAME will return previously saved variables by TBADD/TBMOD. The save4d
variables are extra to the standard table defined by KEYS() and NAMES()
that defined the table "columns".

TBGET will return the variable names defined to the table with the need of
SAVENAME.

HTH
ITschak

ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon *




On Thu, Jun 24, 2021 at 5:42 PM Joseph Reichman <reich...@gmail.com>
wrote:

[Joseph Reichman]

Thank

So let me re-phrase if on the successful tbadd I had SAVE(namelist)

Where namelist == ‘var1 var2 var3 var4 var5’
On the the tbget if I wanted to get var5
I would code therow = var5

And have SAVENAME(therow) ?



> On Jun 24, 2021, at 10:52 AM, ITschak Mugzach <imug...@gmail.com> wrote:
>
> SAVENAME will return previously saved variables by TBADD/TBMOD. The save4d

[ITschak Mugzach]

True.

בתאריך יום ה׳, 24 ביוני 2021 ב-18:09 מאת Joseph Reichman <
reich...@gmail.com>:

--

ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon *

[ITschak Mugzach]

Wrong... Sorry. TBGET with savename will return the NAMEs of the variables
previously saved. The variables themselves will be stored, but with
savename, you will know which variables they are.

ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon *

On Thu, Jun 24, 2021 at 6:09 PM Joseph Reichman <reich...@gmail.com>

[Jeremy Nicoll]

On Thu, 24 Jun 2021, at 15:42, Joseph Reichman wrote:

> I save the values in a ISPF table

How have you defined the table - I mean what variables?

> After I do an ISFEXEC ST I do a 2 checks
> 1) if they are in the table
> 2) if their original status was awaiting execution and now it’s
> executing I would like to change that corresponding variable from that
> row to executing
> So when I get a RC 0 from TBSCAN the numeric rowid is returned


> I then do a TBGET with that rowid and have SAVENAME point to a variable
> SAVENAME(therow)

You shouldn't need to use these extended variables. If you defined the
table with an appropriate set of fields in each row, as soon as you TBGET
the row you want, all the corresponding variables in your rexx (or clist
or assembler program or whatever) will be set from the vars in that row
of the table.

You'd then change them as required and write the revised row back
into the table.


Extended vars are only useful if you have a table where only a
small number of rows need to store a non-standard set of extra
fields. IIRC ispf profiles also work that way - they are tables with
a single row consisting only of extended variables.

--
Jeremy Nicoll - my opinions are my own.

[Frank Clarke]

https://rexxpertise.blogspot.com/2011/11/ispf-tables-extension-variables.html

...and there are other articles as well.  Search for 'extension'.

[Frank Clarke]

True, but sometimes (as with bill-of-materials processing) the bulk of the real data may be found primarily in extension variables.
I often have one row of a table with a key of '3F'x (less than a blank, '40'x) and store there, as extension variables, certain table-specific data such as date-last-updated or somesuch.  Then my TBDISPL specifies "ROWS(SCAN)" and I set the TBSCAN to exclude from display anything less than a blank.
On startup, I read the '3F'x row to populate any variables on that row.



On Thursday, June 24, 2021, 11:42:00 AM EDT, Jeremy Nicoll <jn.ls....@letterboxes.org> wrote:
...

Extended vars are only useful if you have a table where only a
small number of rows need to store a non-standard set of extra
fields.  IIRC ispf profiles also work that way - they are tables with
a single row consisting only of extended variables.