The iSeries does not natively store deleted user profile data. You would need one of the third party Security packages that manage profiles, or you could write your own exit program but for profile management that would be one a bear. <a href="http://www.netiq.com/products/iseriesmgmt/default.asp">NetIQ's password management module</a> gives you that and lets you create profile templates and check password complexity. I'm sure there are others but that is the only one I've worked with. 'one would be a bear' woops =========================================================== There is no "file" involved. However, all actions are stored if auditing is turned on. That causes the information to be stored in the audit journal receivers. Also, the system provides an exit point where profile deletions can trigger a program that you supply that can store the profile information in any format that you choose. This program can be thought of much like a trigger program that fires when a table row is deleted. Almost anyone who can write a trigger program can also write the exit program for this. The audit journal can record changes to profiles. Generally, if you used this technique, you'd be interested in the Change Profile (CP) entries that are generated for CRTUSRPRF and CHGUSRPRF. You could log each historical change as they happened. Also, the Delete Object (DO) entry could be a signal that the profile had been deleted. The accumulated create and change actions would fully describe the profile as it was when deleted. The <a href="http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/apis/XDLTUP.htm">Delete User Profile Exit Program</a> for V5R3 would be an easier technique. In short, you'd write the program to call the <a href="http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/apis/qsyrusri.htm">Retrieve User Information (QSYRUSRI) API</a> for the profile being deleted. The profile name is supplied in the User profile name field of the data structure in the parameter passed in when the system calls your exit program. You could optionally call other APIs to capture ownership, authority or any other info you wanted. You call the QSYRUSRI API and store the data structure that it returns back to you. You could create a table that matches the API structure or define a different table format and extract what you need from the API data structure. Exit programs for this exit point can be registered as 'before' or 'after' deletion. You'd register 'before' in order to be able to retrieve and store the profile info before it's deleted. You might choose to create both exit programs -- the first would retrieve the profile info and store it in the job; the second would apply the info to your log table. Tom

The iSeries does not natively store deleted user profile data. You would need one of the third party Security packages that manage profiles, or you could write your own exit program but for profile management that would be one a bear. <a href="http://www.netiq.com/products/iseriesmgmt/default.asp">NetIQ's password management module</a> gives you that and lets you create profile templates and check password complexity. I'm sure there are others but that is the only one I've worked with. 'one would be a bear' woops =========================================================== There is no "file" involved. However, all actions are stored if auditing is turned on. That causes the information to be stored in the audit journal receivers. Also, the system provides an exit point where profile deletions can trigger a program that you supply that can store the profile information in any format that you choose. This program can be thought of much like a trigger program that fires when a table row is deleted. Almost anyone who can write a trigger program can also write the exit program for this. The audit journal can record changes to profiles. Generally, if you used this technique, you'd be interested in the Change Profile (CP) entries that are generated for CRTUSRPRF and CHGUSRPRF. You could log each historical change as they happened. Also, the Delete Object (DO) entry could be a signal that the profile had been deleted. The accumulated create and change actions would fully describe the profile as it was when deleted. The <a href="http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/apis/XDLTUP.htm">Delete User Profile Exit Program</a> for V5R3 would be an easier technique. In short, you'd write the program to call the <a href="http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/apis/qsyrusri.htm">Retrieve User Information (QSYRUSRI) API</a> for the profile being deleted. The profile name is supplied in the User profile name field of the data structure in the parameter passed in when the system calls your exit program. You could optionally call other APIs to capture ownership, authority or any other info you wanted. You call the QSYRUSRI API and store the data structure that it returns back to you. You could create a table that matches the API structure or define a different table format and extract what you need from the API data structure. Exit programs for this exit point can be registered as 'before' or 'after' deletion. You'd register 'before' in order to be able to retrieve and store the profile info before it's deleted. You might choose to create both exit programs -- the first would retrieve the profile info and store it in the job; the second would apply the info to your log table. Tom