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
