Modify the value of a extensionvariable in an ISPF-Table

UmeySan · Posted: Wed Nov 14, 2018 11:48 pm

Hi Experts,

I'm trying to modify the value of a extensionvariable of a ISPF table.
The table has no key-fields, only these extensionvariables.
The table has only one row.

After a TBGET i loop through all variable-names. For a specific variable i modify the value. At end i try to update the row with TBPUT .

TBGET EQQAPROF SAVENAME(UV) ...
VARNAMES = TRANSLATE(UV," ","()")
VARCOUNT = WORDS(VARNAMES)

DO VARINDX = 1 TO VARCOUNT
VAR = WORD(VARNAMES,VARINDX)
IF VAR = 'blablabla'
VAR = ZZSTRG ...new Value is in ZZSTRG
SAY LEFT(VAR,16,".")"--"VALUE(VAR) ...just to be sure
END

TBPUT EQQAPROF SAVE("VARNAMES") ORDER

So everything seams right, only the TBPUT gets an Error ISPS110
Saying that there are more than 254 variables in the variable-list.

OK, thats right, cause i have 697 extensionvariables in that [swear word deleted] table.

Doing a TBPUT directly after the modification of the specific variable with only the name of the variable destroys the table. Meaning it leaves the table with only the variable used in TBPUT, All others vanished.

So question is: How will i be able to update this table with all his 697
extensionvariables.

I tryed TBMOD, didn't work either. A TBMOD, in the lopp, directly after the check of the variable-name, with or without modifying the value, updates all extensionvariables but also adds some more rows to the table.

So hopefully someone can put me in the right direction to solve that problem.

Willy Jensen · Posted: Thu Nov 15, 2018 4:07 am

Well, if the limit is 254 then that is it, no amount of cursing will change it.
Time for a rethink i.e. having just one variable with a separator between the values? Remember that you in REXX you can parse with a non-displayable separation character.

UmeySan · Posted: Fri Nov 16, 2018 7:28 pm

Thank's a lot Will Jensen.

But is there a way to update only a specific variable of that row with it's 697 extension variables.

Doing a TBPUT with only one variable seams to destroy the table.

It's been a while that i'm doing some Rexx, so perhaps i'm missing something.

Jjeg ønsker Dem en god weekend

Willy Jensen · Posted: Fri Nov 16, 2018 7:45 pm

No, that is what I am saying, you have a a maximum of 254 extension variables. If you need more than that you have to do it differently.
TBPUT with one variable does not technically destroy the table, it just rewrites the row with that one variable. Do you really need 697 variables in one row? You could transpose the table to 697 rows with one variable in each. Or as I suggested initially, use a delimiter and REXX PARSE with one variable in the row. i.e.:

Pedro · Posted: Mon Nov 19, 2018 4:09 am

Can you provide a trace?

My theory is that your list of variable names includes unexpected text.

I doubt that you could have created a table with so many extension variables if you cannot update it with the same number of variables.

PeterHolland · Posted: Mon Nov 19, 2018 11:55 am

Table EQQAPROF is not created by the user as far as i remember.

To look at the specifics of the table use ISPF Dialog Test (option 7)

UmeySan · Posted: Mon Nov 19, 2018 3:55 pm

Morning gents !

As Peter Holland suspects, this is not my own table. EQQAPROF is a Profile table from OPC. Among many other things, the Job-Name variable is stored there.

My Intension was to pick up a jobname from a member, open in edit mode, via Rexx (Cursor Position - Point & shoot), open a new Screen and branch direclty into the OPC Panel where you could specify the Job you want to browse.

PeterHolland · Posted: Mon Nov 19, 2018 4:28 pm

Among many other things, the Job-Name variable is stored there.

How do you know? Subsystem name, yes, but jobname ? Which jobname?

My Intension was to pick up a jobname from a member, open in edit mode, via Rexx (Cursor Position - Point & shoot), open a new Screen and branch direclty into the OPC Panel where you could specify the Job you want to browse.

I don't understand this.

Willy Jensen · Posted: Mon Nov 19, 2018 7:03 pm

I did not note the table name in the original entry, sorry. Now I see that it belongs to TWS (OPC). This probably means that the table is created and updated from a program using the CALL with namelist interface. The documentation (zos 2.1) states a limit of 254 extension variable names also for a namelist, though I seem to remember that the limit was greater at some point in time. TWS, being an IBM product, might have access to an alternate interface, or the documentation could be wrong. In any case I think that you are stuck with the limit of 254 names when using REXX. You could try to write a program to test the CALL namelist interface.
By the way, good to see a description of what you are attempting.

Pedro · Posted: Mon Nov 19, 2018 11:15 pm

Pedro · Posted: Mon Nov 19, 2018 11:21 pm

UmeySan · Posted: Tue Nov 20, 2018 5:23 pm

@Peter: You could use 3.16 to view/edit the EQQAPROF table.
The variable where the jobname is stored is "oajob", used by EQQASELP Panel.

@Willy: Yes, seams that i'm stuck with the limit of 254 names.
I'm also thinking about a little Assembler Programm.

@Pedro: I retired four yeares ago. reactivated for a project since summer this year.

Thank's a lot

UmeySan · Posted: Tue Nov 20, 2018 5:35 pm

@Peter

Just think of a normal Member in a PO Dataset.

If you open this member in edit mode, you coud see lines where names of OPC applications with their associated Jobs are listed.

... APPL A#Appl01 XA001 XA002 XA003 XA004
... APPL B#Appl02 XB001 XB002 XB003 XB004

You Position the Cursor at the Job you would browse an press a defined pf key. Point-and-shoot. The rexx started via pf key extracts the jobname at curser Position and branches to OPC displaying Panel EQQASELP.

Hope i could make myself clear.

Fijne dag !

Nic Clouston · Posted: Tue Nov 20, 2018 5:51 pm

If you are only using the table to point and shoot why is there a need to update it?

PeterHolland · Posted: Tue Nov 20, 2018 6:05 pm

Panel EQQASELP (Application List Criteria) as the name implies is used to select applications. Probably a jobname (generic?) can be used and probably that jobname is saved in the profile table.

It would be nice you show a screen print of that part of the profile table.

Somewhere in the back of my memory i seem to remember that some table data consisting of multiple records form in reality 1 long strong with variables.

UmeySan · Posted: Tue Nov 20, 2018 8:23 pm

As Peter describes, the TWS (OPC) application is reading this table to get all the needed variables. So only storing a variable with VPUT into the Profile pool doesn't work.

@Peter: Sorry, i didn't realy understand the last sentence, what's the meaning.

Willy Jensen · Posted: Tue Nov 20, 2018 8:49 pm

Interesting, using profile vput allows me to add 800 extension variables to a profile, so Pedro's suggestion should help you achieve your goal.
My sampe pgm shows 1435 extension variables in the zzzz profile:

Pedro · Posted: Tue Nov 20, 2018 10:09 pm

PeterHolland · Posted: Wed Nov 21, 2018 8:41 am

@UmeySan

The meaning of the last sentence :

concatenating the table records to 1 long string

UmeySan · Posted: Wed Nov 21, 2018 3:44 pm

Thank's a lot gent's, i appreciate your help.

Perhaps my Alzheimer's symptoms are getting worse, so i can't follow up your hints in every step. Or i schall reduce the bottels of red wine at dinner to a limit of one.

And as beeing a programmer, normaly using Assembler, Cobol, db2 cics, ims, i'm no Guru of Rexx language.

@Willy: I can't really see where you're updating a specific table without using TBPUT or TBMOD or TBADD. And what does this &ZZ proc does?

@Pedro:
>> It probably 'reads the table' through the use of VPUT and VGET services

Would you be so Kind to explain that in Detail.

I would be delighted to here form you, so you could enligthen my lack of knowledge here.

Willy Jensen · Posted: Wed Nov 21, 2018 7:46 pm

Sorry, should have mentioned that the REXX is called ZZ, it calls itself to have the correct applid.
Using applid 'ZZZZ' implies profile table ZZZZPROF. I do not use table access commands, as Pedro and others have said elsewhere in this topic you use 'VGET name PROFILE' and 'VPUT name PROFILE' to access profile variables. So in your case, make sure that you have applid EQQA, then you can access the variables that you need.
I strongly suggest that you read up on ISPF variables and application ids in the 'ISPF Dialog Developer's Guide and Reference' manual.

UmeySan · Posted: Wed Nov 21, 2018 10:22 pm

Hi Willy,

thanks, that was pointing me in the right direction.

From my "Point-&-Shoot" Rexx, i'm picking up the jobname. Then i execute another Rex via:

ADDRESS ISPEXEC "SELECT PGM(ISPSTRT) PARM(CMD(XX6))"

This one (XX6) looks like your example and is executing OPC.
So far so good.

After getting the EQQA applid in XX6 i can VGET the jobname, modify it with another value and VPUT it in the Profile. Later on in OPC i can see the modified jobname.

So my Problem now is, how to get my jobname-value from the starting rexx, wich uses another applid.

I remember there a three different pools. Shared-Pool, Profile-Pool and another one. And there was a way to transfer a variable from one applid to another. Or that there is a variable pool that could be acessed by different applids.

Hope i could make my jumbled thoughts a Little bit clear.

Hjertelige hilsener & mange tak

UmeySan

Willy Jensen · Posted: Thu Nov 22, 2018 3:16 am

you can use ISPEXEC SELECT CMD('command(parms)') NEWAPPL('applid') NEWPOOL to start your 2nd REXX with a parameter and the desired appplid.
I appreciate your danish regards

Willy Jensen · Posted: Thu Nov 22, 2018 3:06 pm

I really had a bad day yesterday, the correct syntax for starting a command with parameters is:
SELECT CMD(%cmdname the-parm-string) NEWPOOL NEWAPPL(applid)
Check the 'ISPF Services Guide' manual for details.

UmeySan · Posted: Thu Nov 22, 2018 4:08 pm

Hi Willy,

D'ont worry, i have bad weeks, bad month's, ...
As i say every morning: "your only good day was yesterday"

Yeah, i could remember the differenc between PGM and CMD Format.

So I did a instructed but i loose the content of the variable ZZSTRG by the re-entry in the rexx. That's really the last straw that breaks the camel's back. That really drive me nuts.

Perhaps you have the time to look at that [expletive deleted] little rexx of mine and could help me to break the vicious circle.

bij voorbaat dank !!!

This is rexx STROPC

ADDRESS ISPEXEC "VGET ZAPPLID"

IF ZAPPLID <> 'EQQA' THEN DO
ADDRESS ISPEXEC "VGET (ZZSTRG) PROFILE"
ADDRESS ISPEXEC "SELECT CMD(%STROPC ZZSTRG) NEW..."
EXIT 0
END

OAJOB = ZZSTRG ...Content lost
ADDRESS ISPEXEC "VPUT OAJOB PROFILE"

ADDRESS ISPEXEC "SELECT CMD(%OPC) NEWAPPL(EQQA) PASSLIB SCRNAME(UMOPC)"

EXIT