I have been remiss in following up. Other pressing concerns, etc., etc.
I have this working in a test EXEC. I can
- Set a particular PF key to a new command
- Invoke View and it sees the new PF definition correctly
- On exit from VIEW, restore the previous key values
There is no effect on other userids using VIEW, but a VIEW session for the same
userid in a split screen gets the overridden PF definition.
Here is the essential part of the Rexx code. (Call_ISP issues the passed
command and checks for errors.) To make this "production" you would want to
remove all of the SAYs. I think it would be possible to do this in several
fewer instructions but I beat my head against the wall getting this debugged
and now figure it is good enough.
ProfileTableName = "ISRPROF"
KeylistName = "ISRSPEC"
/* New approach based on looping through profile */
/* No need to open ISRPROF -- should already be open */
/* But do need to make sure to position to top */
Call Addr_ISP "TBTOP" ProfileTableName
/* Loop reading records until find one for Keylist ISRSPEC */
KEYLISTN = "" /* Initialize so not undefined */
Do Forever /* At least until success or failure! */
/* On to the next row */
Call Addr_ISP "TBSKIP" ProfileTableName
/* Will get an 8 above if not found */
/* Read the row */
Call Addr_ISP "TBGET" ProfileTableName "SAVENAME(THEVARS) POSITION(THEROW)"
Say "THEROW =" THEROW
Say "TheVars =" THEVARS
Say "KEYLISTN =" KEYLISTN
/* See if we found our keylist */
If KEYLISTN = KeylistName Then Do
Say "KEY4DEF, KEY4LAB, KEY4ATR =" KEY4DEF"," KEY4LAB"," KEY4ATR
/* Save them */
HoldKEY4DEF = KEY4DEF
HoldKEY4LAB = KEY4LAB
HoldKEY4ATR = KEY4ATR
/* Set our values */
KEY4DEF = "MYPFKEY"
KEY4LAB = "My Label"
KEY4ATR = "LONG"
/* Write it back */
Call Addr_ISP "TBPUT" ProfileTableName "SAVE"THEVARS /* Includes the parens
*/
Leave /* Our work here is done */
End /* Found keylist name */
End /* Forever */
/* Start up a VIEW session with the new PF key */
Call Addr_ISP "VIEW DATASET(some.data.set.name)"
/* Restore the former values */
Call Addr_ISP "TBTOP" ProfileTableName /* Get back to the top */
Call Addr_ISP "TBSKIP" ProfileTableName "NUMBER("0+THEROW")"
KEY4DEF = HoldKEY4DEF
KEY4LAB = HoldKEY4LAB
KEY4ATR = HoldKEY4ATR
Say "KEY4DEF, KEY4LAB, KEY4ATR =" KEY4DEF"," KEY4LAB"," KEY4ATR
Call Addr_ISP "TBPUT" ProfileTableName "SAVE"THEVARS /* Includes the parens */
Thanks all, and especially @Michael, for your invaluable assistance.
Charles
On Fri, 3 Oct 2025 16:04:36 +0000, Schmitt, Michael <[email protected]>
wrote:
>As previously mentioned, the source for the keylist is the KEYS table, but the
>values are copied and used from the application's profile.
>
>ISPF is using the first row for the profile variables, and then rows 2 and up
>are one row per keylist. Each row is still just extension variables. Variable
>KEYLISTN is the keylist name, and the rest are the keylist data.
>
>So what you do is:
>1. TBSKIP starting with row 2 until you find one where KEYLISTN is the desired
>keylist. You should capture the extension variable names.
>2. When you find what you want, change the KEYnDEF, KEYnLAB, KEYnATR value.
>3. TBPUT profile SAVE(extvars)
>
>
>To prove this is correct, here's code that displays all the keylist variables
>for the VIEW keylist:
>
>address ISPEXEC
> "CONTROL ERRORS RETURN"
> keylist = 'ISRSPEC'
> table = 'ISRPROF'
>
> keylistn = ''
> "TBTOP &TABLE"
> "TBSKIP &TABLE NUMBER(2) SAVENAME(EXTVARS)"
> do while rc = 0
> if keylistn = keylist then do
> call display_keylist
> leave
> end
> keylistn = ''
> "TBSKIP &TABLE SAVENAME(EXTVARS)"
> end
>
> exit
>
>display_keylist:
> parse var extvars '(' extvars ')'
> do i = 1 to words(extvars)
> extvar = word(extvars, i)
> say extvar '=' value(extvar)
> end
> return
>
>
>-----Original Message-----
>From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
>Charles Mills
>Sent: Thursday, October 2, 2025 4:05 PM
>To: [email protected]
>Subject: Re: Programmatic API to ISPF PF keys?
>
>Okay, I had time to get back onto this. I have learned a little, but I have
>not solved my problem. What is the problem? I would like to be able, in a REXX
>EXEC executed from ISPF, to be able to read the setting of a given PF key,
>alter that setting, invoke VIEW and have the setting be in effect, and then
>restore the setting to its previous value -- either explicitly -- or
>implicitly by not "saving" the change.
>
>I have totally solved reading and writing the key tables.
>
>TBOPEN ISRKEYS NOWRITE SHARE
>KEYLISTN = "ISRSPEC"
>"TBGET ISRKEYS"
>Say "KEY4DEF =" KEY4DEF
>KEY4DEF = "MYNEWKEY"
>TBPUT ISRKEYS SAVE(KEY4DEF)
>
>Does pretty much what it would seem like it should do. I can go into 3.16 and
>see my change to ISRKEYS.
>
>But it has zero effect on the working PF key definitions for VIEW.
>
>I have learned with some success how to manipulate the profile. (I have also
>succeeded in clobbering it a couple of times and putting myself back into "new
>TSO userid" mode <g>.)
>
>I learned you don't want to TBOPEN ISRPROF -- it's already open. I have not
>figured out what row I want to read and update -- what key to specify for
>TBGET. I can read rows by number specified in TBSKIP, but setting PF values at
>least in rows 1 or 2 does not seem to affect VIEW. I don't want to hack at row
>numbers -- I want to know the correct key. KEYLISTN = "ISRSPEC" is not the
>answer -- the TBGET fails with an RC 8. It looks like it should be. If I set a
>PF key in VIEW to some eyecatcher value I can see it browsing ISRPROF.
>(Regular ISPF BROWSE -- 3.16 fails due to in-use.) The eyecatcher is preceded
>in the data by KEYLISTN..ISRSPEC.KEY1DEF etc. but KEYLISTN = "ISRSPEC" does
>not seem to make TBGET succeed.
>
>Any thoughts?
>Charles
>
>On Sat, 27 Sep 2025 04:38:35 +0000, Schmitt, Michael <[email protected]>
>wrote:
>
>>I bet the keylists are stored in the profile table, but not as profile
>>variables at all. Instead they’re additional rows in the table, one row per
>>keylist. The keylist name may be a key. So when a panel is displayed, it
>>reads the keylist row, and now it has the key values.
>>
>>I do think that the key variables are still extension variables in the row,
>>though. Otherwise the variable names wouldn’t be repeated in the member.
>>
>>If that theory is correct, you could manipulate the values using standard
>>ISPF table commands, even force the profile to save. You wouldn’t run into
>>the extension variable limit because there’s not that many key variables in
>>one keylist.
>>
>>I’d be careful though not to change the current row number (CRP) in the table.
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to [email protected] with the message: INFO IBM-MAIN
>
>
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
