This typically happens (in my experience) when a single ISPPROF dataset is shared across multiple images (last update wins).
A)Code/install ISPF EXIT 16 to change the name of the ISPPROF dataset being used to something image specific. B)Live with it HTH, -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of ITschak Mugzach Sent: Friday, July 5, 2019 9:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Who is changing a user's ISPF profile Lizette, I think ISPF enqueues the profile table even on concatenated dd,so not sure they can share ISRPROF/ISPPROF. ITschak On Fri, Jul 5, 2019 at 5:16 PM Lizette Koehler <stars...@mindspring.com> wrote: > Note the following information from the ISPF Manual > > > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.1.0%2Fcom.ibm.zos. > v2r1.f54ug00%2Faloptab.htm&data=02%7C01%7Callan.staller%40HCL.COM% > 7Ce70a12bbab864cbaae1f08d701543a5e%7C189de737c93a4f5a8b686f4ca9941912% > 7C0%7C0%7C636979333612770566&sdata=A%2B9gYJaqHYvp8kpZYiX4TLYqSgjKf > VA0%2BcWFq7aewsU%3D&reserved=0 > > > The table output library must be a partitioned data set. The ISPTABL > ddname that defines the table output library can specify the same data > set as the table input library, ddname ISPTLIB. The first data set in > the ISPTLIB concatenation should be the same as the data set used for ISPTABL. > This ensures predictable behavior of dialogs that use table services > without specifying the LIBRARY keyword. The output and input data sets > must be the same if the updated version of a table is to be > reprocessed by the same dialog that updated it. > > The behavior can be due to the allocations on ISPTLIB and ISPTABL. > > Make sure the users dataset is at the top of BOTH allocations. > > Lizette > > > -----Original Message----- > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of > > ITschak Mugzach > > Sent: Friday, July 05, 2019 6:12 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Who is changing a user's ISPF profile > > > > And last: an ispf application is invoked without appl so it set > > pfkeys > and > > other profile settings is ISR / ISP instead of its own profile. > > > > ITschak > > > > בתאריך יום ו׳, 5 ביולי 2019, 16:03, מאת Joel C. Ewing > ><jcew...@acm.org > >: > > > > > Various possibilities: > > > (1)The user is attempting to violate installation standards and a > > > default installation initial edit macro is forcing the edit > > > profile values back > > > > > > (2)The user is attempting to modify a locked edit profile, which > > > means any changes he makes are temporary -- locking some default > > > edit profiles is another way installations can encourage what they > > > believe to be best practices for certain dataset types > > > > > > (3) The user may be changing the final qualifier of the dataset > > > name, not realizing that the edit profile is tied to the final > > > qualifier of the dataset name, not to the dataset itself. > > > > > > (4) The user may be editing datasets with so many different final > > > dataset name qualifiers that he is exceeding the maximum number of > > > retained edit profiles as defined by the installation -- which > > > means his version of the least recently used edit profile will be > > > dropped and the next time he edits a dataset corresponding to that > > > edit profile a default profile will be used. > > > > > > I'm sure there are other possibilities. > > > Joel C. Ewing > > > > > > On 7/5/19 1:26 AM, Vernooij, Kees (ITOP NM) - KLM wrote: > > > > If it is e.g. an ISPF Edit Initial Macro, changed by someone, > > > > the user > > > will be the one that modifies the Profile. This will be difficult > > > to > trap. > > > > What has changed in their profile? > > > > > > > > Kees. > > > > > > > >> -----Original Message----- > > > >> From: IBM Mainframe Discussion List > > > >> [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > > On > > > >> Behalf Of Anthony Thompson > > > >> Sent: 05 July, 2019 4:33 > > > >> To: IBM-MAIN@LISTSERV.UA.EDU > > > >> Subject: Re: Who is changing a user's ISPF profile > > > >> > > > >> You probably want SMF record type 15, to tell you who has > > > >> opened a > > > dataset > > > >> for output, and when. > > > >> > > > >> Are you a RACF shop? You can define a RACF profile for the > > > >> user's ISPF profile dataset to ensure that only they have more > > > >> than READ access, and use NOTIFY(userid) to get a TSO message > > > >> whenever some other > > > user/whatever > > > >> fails the RACF check. ACF2 has similar facilities, and I've > > > >> never met > > > TSS. > > > >> > > > >> Ant. > > > >> > > > >> -----Original Message----- > > > >> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > > > >> On > > > Behalf > > > >> Of Gadi Ben-Avi > > > >> Sent: Friday, 5 July 2019 12:21 AM > > > >> To: IBM-MAIN@LISTSERV.UA.EDU > > > >> Subject: Who is changing a user's ISPF profile > > > >> > > > >> Hi, > > > >> > > > >> A user is complaining that 'someone' is changing their ISPF > > > >> profile and setting that they set up are changing. > > > >> > > > >> Can I track this in SMF and see who, if anyone is doing this? > > > >> > > > >> I saw the SMF 42 records are created when members in a PDS or > > > >> PDS/E are changed. > > > >> > > > >> Will they pick up ISPF profile changes? > > > >> We are running z/OS v2.2. > > > >> > > > >> Thanks > > > >> Gadi > > > -- > > > Joel C. Ewing > > > > [>] > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for Legacy **| * ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
