On Apr 23, 11:18am, Doug Werth wrote:
...
> RENAME .GROUP.ACCOUNT,.GROUP.ACCOUNT
>
> Under 4.0 this would come back with a CIERR 630, First character of
> filename is not alphabetic.
>
> Since the "." is a valid character in posix files the programs now get a
> CIERROR 372 with an FSERR 52 (Nonexistent permanent file) instead.

It is true that as of release 4.5, if a filename begins with a dot or a
slash the name is considered to be a POSIX name.  This is called MPE-escaped
syntax, and is the default syntax for the CI and all intrinsics.

Forwards compatibility is very important to us, but we generally define
this as making sure that things that used to work continue to work the
same way.  "Used to work" usually refers to non-error conditions.  We sometimes
changed the behavior of commands that used to *fail*, to either fail in
a different way or to actually "work".
Anytime we add a new command, a new CI variable, a new intrinsic we can
break something that used to work.  In the above RENAME example it still
fails, but with a different error than in 4.0.  Note that RENAME could
also work if you had a file named "./.GROUP.ACCOUNT"

I appreciate Doug mentioning this example because it illustrates how
important compatibility is to our customers, and that has been one of
the evolutionary strengths of MPE.  Compatibility is a big issue in the
subject heading of this thread.  Extending the legal characters in a filename
can break existing scripts, JCL, UDCs, programs calling COMMAND, etc.
I have plenty of examples that probably appear "odd" (but not any odder than
the above RENAME example :)  One reasons that I suggested having traditional
MPE interfaces not support the extended characters is precisely to ensure
compatibility for existing MPE apps -- even at the expense of making the
MPE/POSIX wall a little higher (which is not desireable, IMO).

> As the programming effort to change the number of programs that this
> routine was compiled into was too great we wrote them a routine to
> intercept and parse the command intrinsic. If it is RENAME and the file
> name is blank it emulates the pre-posix behavior otherwise it passes the
> command on to the real intrinsic.

Could you have, instead, written a COMMAND() stub in your XL and had the
XL COMMAND simply call HPCICOMMAND.  Then define a system level UDC named
RENAME that handles this case?  I don't know if this would be easier or not.

> So while the discussion about posix and MPE integration continues, my
> customer wants to know "How can I turn it off?"

You cannot "turn off" POSIX.  We had many long debates about designing a
POSIX "switch", and even started some work in that area.  We decided that
POSIX needed to be in FOS and always "on" in order to make MPE a
viable platform for unix ports.

You can:
- write UDCs to trap new commands (eg. NEWDIR, CHDIR, etc),
- purge @.hpbin.sys,
- write UDCs to trap old enhanced commands (RENAME, PURGE, BUILD, etc.),
- write AIF procedure exits to trap COMMAND and HPCICOMMAND
- remove your compilers

and pretty much disable POSIX.  BE AWARE that more and more of FOS MPE
is relying on POSIX names and features.  See STAGEMAN for example.

Jeff Vance, CSY

--