When I first began logging on and using ISPF I soon noticed my profile values weren't being kept; I had to repeatedly respecify my PFK definitions, scroll defaults, edit profiles, etc. I have recently discovered the likely cause: the system is maintaining two sets of profile tables because it is using two ISPF application IDs.
The normal application ID for the PDF component of ISPF is ISR. However, when the system puts me in ISPF on logon, even though it is displaying the PDF primary options menu it does so with the default generic ISPF application id of ISP. When I subsequently exit this initial PDF invocation but then reenter PDF the PDF primary option menu shows the normal PDF application ID of ISR.
I suspect that whatever procedure is being used for logon processing puts users in PDF without using a normal "PDF" command which would open PDF with its usual ISR id. I believe it may be using an "ISPSTART" command specifying "ISR@PRIM" as initial panel, which makes it look and act like PDF but with the ISP application id that ISPSTART normally assigns by default.
Since the application id determines which profile tables an ISPF application uses, the initial and subsequent invocations of PDF use different tables (basic profile, edit profile/recovery, command): one set for ISP and another for ISR. But this is confusing to a user who sees the same PDF primary option menu and therefore believes it's the same function. It also forces users to specify all their PDF-oriented profile values--function keys, edit profiles, scroll defaults, etc.--twice. I recommend that logon processing be modified to initially directly call PDF so that the initial display of the PDF primary option menu will be under application id ISR; then the same profile tables will be used for any PDF invocation including the initial one at logon.
Thanks!
jk zup