Indulge me for a moment while a play devil's advocate. Here is a (very) short list of reasons I can think of for changing a filecode with my comments on each one. I am sure there are many more. 1 - Allow access to the file without PRIV mode programs/programming. (Editor? Fcopy?) Generally speaking files have a PRIV file code for to prevent the type of access discussed here. Most PRIV files are binary files that require either a tool that understands the makeup of the file to manipulate it or must be edited in DEBUG. If a system manager is sophisticated enough to edit a file with DEBUG then that same user can figure out/already knows how to change a filecode with DEBUG. Would changing a filecode be supported by HP? I can envision a scenario where a file code is changed and a dataset corrupted. Would this leave the user "on their own" support-wise? The implication of an MPE command that allows the filecode to be change says that it is supported. Allowing the user to change the filecode of an Image dataset just may be giving that user the gun, the ammunition, and just enough direction on how to pull the trigger while the gun is still firmly planted in the holster aimed directly at the foot. 2 - Allow MPE commands (rename, purge, copy, etc) to function on the file. Wouldn't it make just as much sense to allow SM users to use standard MPE commands on a file, specifying the filecode as part of the command similar to DSCOPY and DEBUG. This is a lot cleaner than destroying the file code. :copy ROOT1,ROOT2;filecode=-400 is a lot easier than: :altfile ROOT1;filecode=0 :copy root1,root2 :altfile root1;filecode=-400 :altfile root2;filecode=-400 I am sure that the amount of resources required by HP to change a large number of MPE commands is greater than just changing ALTFILE, but you never know. Maybe it is a simple patch to FOPEN to bypass PRIV file checking the same as bypassing security for an SM user. Well, its food for thought anyway. Doug. Doug Werth Beechglen Development Inc. [log in to unmask] Cincinnati, Ohio The opinions expressed do not necessarily represent the views or opinions of Beechglen Development. They might, but not necessarily. They represent solely the opinions of the author. >At 3/30/99 12:52 AM , Jeff Vance wrote: >Hi all, > >We *may* enhance the ALTFILE CI command so that a user can modify a >file's file code. If we do this here are my thoughts on the >restrictions on ALTFILE: > > 1. SM can alter any file's file code to any value (even negative) > > 2. Non-SM can alter any file he/she has WRITE access to, to a file > code whose numeric value is >= 0. > > 3. Non-SM cannot alter a file with a negative (PRIV) file code to > any file code value. > >Thanks in advance for your thoughts. > >Jeff Vance, CSY >