On Apr 24,  9:42am, Mark Bixby wrote:
> Subject: Re: Extending Posix filenames (brief comment)
> 1) The POSIX shell, utilities, and API should all support the new Unix-style
> file names.
>
> 2) HPFOPEN should support Unix-style names.
>
> 3) There doesn't have to be *any* other support on the MPE side except for
> :FILE equates.  If you want to use Unix-style names from MPE, then you must
> :FILE first and then backreference the :FILE.
>
> All legacy applications could then use the Unix-style names (assuming they
      ^^^^^^
> allow file equates), and no legacy applications would break because FOPEN and
> friends would still expect the current MPE/POSIX syntax.

[Side bar comment: some CSY'ers were talking about what it will be like
when most major apps are written in java (like the next generation SAP or
SGA apps), namely will these apps ever be considered LEGACY?  They presumeably
will easily move to the latest hardware, new I/O devices, etc. ]

About Mark's simple scheme for extended filenames...

It appears that we have to make a CHOICE between full compatibility or
building up the wall between MPE and POSIX.  Obviously, forwards
compatibility is extremely important to us, but also the basic design of
POSIX in MPE was not to have a wall between MPE and POSIX.  Do we have
to trade one for the other?

What if we can preserve LEGACY MPE applications, tools, scripts, JCL, etc.
and still allow the CI to reach all possible filenames on the system?
This may be possible as follows:

- MPE filenames passed to FOPEN, FRENAME, FLABELINFO, etc are still
terminated by today's rules (IOWs any char except a ".", "/", "$", "*", ":"
is a valid name terminator).

- MPE-escaped filenames passed to FOPEN, etc. must be delimited by a null.
(The debate is on regarding space as a terminator!).  This means that we are
willing to break apps/tools that use MPE-escaped syntax with FOPEN, etc
and any terminator other than a null.

-  the CI supports an escape char (like "\"), but this is a CI meta
character only and is not known to the APIs.  Also the CI's escape char
is only meaningful in the MPE-escaped syntax.

- we make sure that all of the POSIX APIs delimit filenames with a null
(same true for the CI, which sometimes uses space or cr as a terminator).

- it is concievable that certain CI IO redirections will work differently
when the target file is in MPE-escape syntax.  Eg.
   :echo abc >./foo$bar
will work differently with extgended chars than it does today.  One can
argue that you should put the redirection filename at the end of the line,
but this is not required by the CI.

- our centralized name parser needs to be taught these new chars.  It may or
may not need to know about the escape char, depending on how we solve
the wildcard pattern matching issue.

I think that covers the major work.  Now this is a LOT more effort than
Mark's approach.  Is it worth it to keep the POSIX/MPE wall as low as
possible at the expense of (probably a few) existing apps/tools that
use MPE-escape syntax, call FOPEN, etc and don't use a null terminator?

Jeff Vance, CSY




--