"Yes" and "sort of". The DELETEs were preceded by ENROLLs for zero blocks. The return codes from the ENROLLs were irrelevant. Some were expected to fail because the user was already enrolled. That was acceptable, even expected, when there were many users to delete. I suppose I could do the DELETEs in a different stream and look for non-zero codes there. That, or I could code a REXX loop (he said to a resounding roar of Boos and Hisses.) The console stages were supposed to disclose any problems; however, they were useless in this case - there were no messages whatsoever that went down the pipe.
Perhaps it was an omission by chance that DELETE USER only operates on enrolled users. The design of SFS does allow someone to grant permissions to unenrolled users. By doing nothing if one of those users is DELETEd, you leave orphaned permissions lying around waiting for the id to be reissued. This ought to raise the hairs on the back of your neck when you don your Security hat. I tried, unsuccessfully, reporting it back in the late '80s or early '90s. A real improvement would be to allow a list of users to be deleted in a single pass through the catalog. Perhaps this could be included when you close the security hole. :-) Richard (with egg on the face) Schuh -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Saturday, December 16, 2006 2:09 PM To: [email protected] Subject: Re: COMMAND vs. CMS On Friday, 12/15/2006 at 09:48 PST, "Schuh, Richard" <[EMAIL PROTECTED]> wrote: > I stand by my statement that the command was not being executed. The > users in the list who were already enrolled, were not deleted and the > service machine executing the commands is an administrator of the > filepool. So, Richard, as it turns out DELETE *was* being executed, but it was failing because of the open workunit? (Similar to my 'not authorized' example.) I would have expected a non-zero RC from the DELETE. Alan Altmark z/VM Development IBM Endicott
