Hi all,

Here are some email exchanges I've had with Paul Taffel which I thought
might be stimulating to the larger group.

Jeff Vance, CSY
_____________________________ Reply Separator _________________________________

Hi Paul,

Your ideas has occurred to a few other 3000-l folks, do you mind if
I make a public reply?

On May 6,  4:16pm, Paul Taffel wrote:
> One thought occurred to me while reading the recent discussions about Posix
> filename syntax extensions, that I've not seen mentioned by any posters.
>
> Instead of introducing escape characters into the CI side, had you considered
> requiring 'extended syntax' filenames to be quoted?
>
> For example:         :PURGE "a new filename"
>          or:         :BUILD "file;name;"
>
> I know that (some?) NM commands already accept quoted filenames, but I don't
> believe there should be cases today where a user would be quoting filenames,
> AND
> relying on embedded spaces or delimiters within the quotes (thereby creating
> backwards-compatibility problems).

Quoting is a form of "escaping" the name and it has most of the same
issues that a new escape character has. The fact that a name was quoted vs.
unquoted would need to be known by fopen et. al.,. by our pattern matcher
and by filename parsing code.  So the API layer still needs to know
about "escaping".

All NM commands accept quoted tokens.  This implies that PRINT "myfile"
is perfectly legal today (and has been since 1.0).  It also means that
LISTFILE "./a@" is also perfectly legal today.  So if we decide that now
quotes are significant (note: quotes ARE significant in some CI commands
like the entry point for the RUN command, the XL=list, the NAME= parm
of LISTFILE, and maybe a few other areas) then we may be breaking
some apps, scripts, JCL.  For example, after extended chars are supported,
does LISTFILE "./a@" mean find files beginning with "a" or does it
mean find the file named "a@"?  I assume you want it to mean the latter,
and this is why our pattern matcher would need to know that "@" is not a
wildcard character but instead a real filename character.

Your BUILD example above does not work today since BUILD is still in CM and
uses MYCOMMAND to do its parsing.  In this case, MYCOMMAND is treating
the quotes as part of the filename.  When I execute your above BUILD
command on our experimental system I get:
  :build "./file;name;"  <- I want extended chars to apply only to POSIX names
  Invalid character in MPE file name. (CIERR 583)

  :build ./"file;name;"
  Unknown keyword for BUILD command. (CIERR 299)
    this is because MYCOMMAND doesn't care about quotes and sees the ";" as
    a token delimiter. "name" is a known keyword for the BUILD command,
    and it assumed the filename is <quote>./"file<quote>

  :build ./"file@name"  creates the file named <quote>"file@name"<quote>

> Of course, this doesn't solve all of your problems (embedded '!'s being
> dereferenced, and embedded quote characters), but it would take care of
> embedded spaces and traditional delimiter characters, which isn't bad.

Today, all NM commands accept quoted tokens and the command parser
strips the quotes from the token.  Were you figuring that FOPEN would be
passed a filename surrounded by quotes, like:
  fname := '"./my;name"'+chr(0);  fopen(fname,...);

> I share Craig's concerns about introducing filesystem extensions that
> couldn't be managed 'from the MPE side', and maybe this would allow easy
> access to them from the CI.

I agree that this is a crucial area to resolve.

thanks for you thoughts!

Jeff

----------------------------------
Date: Wed, 07 May 97 14:51:27 PDT
From: "Paul Taffel" <[log in to unmask]>
To: "Jeff Vance" <[log in to unmask]>
Subject: Re[2]: Extending Posix filenames

  Hi Jeff,

  No problem with you 'going public' with this.

  Your answers make perfect sense to me now, but I still really like the idea
  of 'reserving' quoted filenames for Posix-extended syntax.  One question:
  does ANYONE make use of quoted filenames today?  I didn't even realize that
  it was supported by NM commands, until I did some tests prior to my last
  email.  If, as I suspect, this is an unknown feature, we might be able to
  hijack it for Posix-extended syntax, sacrificing backwards compatibility
  without upsetting anyone.

  The one aspect of using quotes as the escape, that I particularly like, is
  that as they must appear at the start of the filename, there's no chance that
  someone could be inadvertently using it now as a terminator, and be caught
  out when we extend the filename syntax.  Any other embedded escape character
  will suffer from this problem.

  I started off assuming that FOPEN would have to be modified to handle the new
  quoted filenames (exactly as you surmised), but now I believe that our
  primary target should be ease of use from the CI.  Anyone who needs to
  manipulate such filenames programmatically should use HPFOPEN, specifying a
  new value for the Name Syntax option (item 41).

  You'll also be able to take the opportunity to finally retire the CM command
  executors, which have inhibited you for far too long from modifying some
  commands!

  Thanks for your (customary) comprehensive reply,

  Paul Taffel
  Quest Software        [log in to unmask]

---End of forwarded mail from "Paul Taffel" <[log in to unmask]>

--