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
>