Operating System - OpenVMS
1753970 Members
7345 Online
108811 Solutions
New Discussion юеВ

Re: Controlling file name parsing in EVE and TPU

 
SOLVED
Go to solution
Galen Tackett
Valued Contributor

Controlling file name parsing in EVE and TPU

Assume that my default directory is on an ODS-5 volume and that I have set my process /CASE=BLIND and /PARSE=TRADITIONAL.

In EVE I give a command like:

WRITE ab^#C^.d.e

and EVE responds:

n lines written to file dev:[dir]ab^#C^.D.e;1

At the DCL prompt a DIR command shows me that, sure enough, a file with this name has been created.

1) Is there a way within TPU to determine the process's case and parse settings? If not with straight TPU, I know you could do it via TPU's CALL_USER and a user written routine in C or whatever, but I'd like to stick to vanilla TPU as much as possible here.

2) Likewise, is there a way to alter these settings from within TPU (vanilla flavor again)?

I've tried searching the online documentation for TPU but haven't turned up anything yet.
11 REPLIES 11
Steven Schweda
Honored Contributor

Re: Controlling file name parsing in EVE and TPU

What would you like EVE to do when you say
WRITE ab^#C^.d.e
?

If you want an ODS2-compatible file name, why
not specify one?

SET

PROCESS

/PARSE_STYLE

/PARSE_STYLE=(keyword)

Allows a user to indicate how commands are to be parsed.

Setting a particular parse style tells DCL how it should handle
command syntax. [...]

Note: "commands" and "DCL".

[...] User programs can also examine the state of this
setting if they need to use different parse rules.

Note: "can".

Is there some actual problem which you are
trying to solve?
Galen Tackett
Valued Contributor

Re: Controlling file name parsing in EVE and TPU

Steve, there's no significant problem here. It's more of a minor annoyance for the most part.

By now you should expect a lot of not-very-important questions from me, shouldn't you? I wish I could say that this is because I figure out all the important ones myself. :-)

A more realistic example would have used a filename something like My^.file which could potentially result from a couple of typo's. This winds up creating a file with the name "My^.file" and some default file type, rather than the intended name "my" and file type "file".

I already knew the bit of DCL documentation you cited.

(I used to be quite a good touch typist, but I guess age must be beginning to take a toll or something. :-)

B
Steven Schweda
Honored Contributor

Re: Controlling file name parsing in EVE and TPU

I'll admit that EVE can create a file with
the name which you specify, rather than with
the name which you desire, but it's not clear
how EVE is supposed to divine your intention
more reliably than it does now.

> What would you like EVE to do [...]?

That question's still pending.

> [...] I guess age must be beginning to take
> a toll or something. [...]

If my experience is any guide, eventually,
you won't even notice. (And you meet new
people every day.)
Galen Tackett
Valued Contributor

Re: Controlling file name parsing in EVE and TPU

> What would you like EVE to do [...]?

You mean EVE can't figure this out on its own?
:-D

Not that I expect this to ever happen, but how about EVE commands (and underlying TPU calls) to allow something similar to DCL's SET PROCESS /CASE and /PARSE?

That would allow a stumble-fingers like me to avoid "invisible" files like TEST^.C.TXT. (That 6/^ key seems to always be getting closer to other commonly typed ones like T, Y, 5/%, and 7/&.)

Or just as bad, not noticing that I hit the caps lock key and winding up with both a test.c and a TEST.C.

John Gillings
Honored Contributor

Re: Controlling file name parsing in EVE and TPU

Galen,

So what you're really saying is TPU will honour ODS-5 specifications even if your process is set BLIND TRADITIONAL? That seems very odd to me, especially the case sensitivity part (sorry, no ODS-5 volume to test on right now). If it's as you say, I can see why you're concerned.

It may be worth writing a CALL_USER routine to check the settings for JPI$_CASE_LOOKUP_PERM, CASE_LOOKUP_IMAGE,
PARSE_STYLE_PERM and PARSE_STYLE_IMAGE.

Do any of the C logical names for fiddling these settings have an effect? (I suspect not, as I think TPU is BLISS code, rather than C).

I would expect (hope!) that TPU leaves all file name processing to RMS, so it should inherit the process defined processing settings.
A crucible of informative mistakes
Karl Rohwedder
Honored Contributor
Solution

Re: Controlling file name parsing in EVE and TPU

John,

Galen seems to be right. Setting my process to /PARS=TRAD, EVE lets me create a file a^b.txt.
It also preserves case.
During the tests I noticed also, that buffernames are always upcase, so when loading files a.txt and A.TXT, you need to specify a new buffername.

regards Kalle
Karl Rohwedder
Honored Contributor

Re: Controlling file name parsing in EVE and TPU

Btw, LSEDIT seems to honour the settings.

regards Kalle
Willem Grooters
Honored Contributor

Re: Controlling file name parsing in EVE and TPU

One of those annoying remains of the past, when case didn't matter, I think. It happens in more places: MMS and PCSI being known examples where case diffence can cause problems but I've seen more side-effects.

What name is actually used on disk?
You specified "ab^#C^.d.e" and the reply is "ab^#C.D.e" - only D uppercased. Weird.

Your problem may well reside inside TPU (where the name you entered is stored, 'as-is', in the RMS structures (if these are used!). It could be just a matter of displaying data.
Willem Grooters
OpenVMS Developer & System Manager
Galen Tackett
Valued Contributor

Re: Controlling file name parsing in EVE and TPU

John,

Karl's got it right.

EVE doesn't seem to be honoring the DCL settings, while DECset V12.8ECO1/LSEDIT V5.1-01 does.

When I reported this issue a few days ago I was running DECset V12.7/LSEDIT V5.0. So the new version appears to work better in this area.

The release notes for DECset 12.8 ECO 1 and its component products, mention improvements in compatibility with ODS-5 extended file naming conventions.

Since I don't think it would be too hard I may try tinkering with some CALL_USER routines in C.