I'll keep the context, but look at the bottom for a possible solution: On Sun, 5 Oct 2025 at 02:06, Jon Perryman <[email protected]> wrote:
> On Fri, 3 Oct 2025 14:53:30 -0500, Charles Mills <[email protected]> wrote: > > >It occurred to me after I posted that I could make an "MVS" copy of > ISRPROF to > >another member and then display that member with 3.16, without any ISPF > ENQ conflicts. > > Doing this from memory. > > 1. xxxPROF is open for write (because VPUT PROFILE). TBSAVE ISRPROF > DDNAME() should save a copy to another DD name. Maybe the member name can > be overridden. > > 2. xxxKEYS is the table that contains keylists as defined for the applid > xxx. You can read from this table but not save it. > > 3. The first line of xxxPROF is the list of VPUT PROFILE variables. > Subsequent lines are user modified keys. > > 4. Keys are shared. Your change will affect all open VIEW. You will also > lose the user modified keys. > > 5. Maybe a new key entry in the keylist will solve your problem. > > 6. PANELID command turns on/off the display of the panel name. > > 7. View the panel and somewhere near the top will be the keylist name (in > your case, ISRSPEC), the applid (in your case, ISR) and whether it is > shared or private. > > 8. ISRPROF and ISRKEYS should always be open because you of ISR@PRIM. > Other applid's may or may not be open depending upon the APPLID's that are > active. > > 9. The applid only applies to the xxxPROF and xxxKEYS member (e.g. > ISRPROF). Originally, the xxxPROF table contained the VPUT xxx PROFILE > variables. It now includes user modified keys. > > 10. KEYLIST ON/OFF allows you to switch between keylists and zpfxx > variables. If this is only for you, then maybe you can live with the > limitations. > > Since VIEW is out of your control, tllhere is no perfect solution to your > problem especially considering you want to do this for a specific VIEW > where multiple VIEWs may be active and should not be affected. > > If you are doing this for multiple people, then making a copy of the > affected panel and giving it a unique key name is probably the best you can > provide. You might want to apply a usermod to make sure you don't lose the > functionality when maintenance is applied. > First of all, you can invoke your code to set a new applid, like what I do in some of my execs: arg idsn parse source source parse value source with . . moi . signal on syntax "ispexec vget (zapplid)" if zapplid \= 'RAP' then do "ispexec select cmd(%"moi idsn") newappl(RAP)" exit end and disable KEYLISTs for that applid, no clue how to do that programmatically. Or, but that's a rather a bit more complicated, modify the VIEW panel on-the-fly, which is what I do in my EDITCLIP exec that allows me to *edit* ISPF Edit clipboard from within edit macros, and even from outside ISPF Edit (provided you add an "ECLIP SELECT CMD(%EDITCLIP &ZPARM) NEWAPPL(ISR) SCRNAME(EDITCLIP) Edit any clipboard" command to one of your (user-)command tables. Here's the EDITCLIP macro < https://prino.neocities.org/zOS/editclip.exec.html> You can optionally create a prepared panel and store it in a XMIT'ed or AMATERSE'd dataset (the latter is cleaner) and expand and LIBDEF that on the fly. My EPANQ <https://prino.neocities.org/zOS/epanq.exec.html> can store and extract anything embedded in a REXX exec, and an example storing a loadlib (still as XMIT) and panel to use Doug Nadel's ISPFHTML utility, < https://prino.neocities.org/zOS/qh.exec.html>. Enjoy, and share whatever you're building! Robert -- Robert AH Prins robert(a)prino(d)org The hitchhiking grandfather <https://prino.neocities.org/index.html> Some REXX code for use on z/OS <https://prino.neocities.org/zOS/zOS-Tools.html> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
