topic Re: DCL F$PARSE Bug? in Operating System - OpenVMS

DCL F$PARSE Bug?

Robert Atkinson — Tue, 07 Mar 2006 05:51:01 GMT

I always assumed if you run F$PARSE and ask it to return a field, if the field doesn't exist it returns blank.

In this example, for DEVICE and DIRECTORY, it keeps returning the environment default which I'm sure is wrong.

For filename, it correctly returns blank!

ALPHA_ROB$$ @ROB.TMP
$ SH DEF
SY:[LIVE.DAT]
$ WS F$PARSE("SY2:[LIVE.XXX]",,,"DIRECTORY")
[LIVE.XXX]
$ WS F$PARSE("SY2:",,,"DIRECTORY")
[LIVE.DAT]
$ WS F$PARSE("SY2:[LIVE.XXX]",,,"NAME")

ALPHA_ROB$$

Re: DCL F$PARSE Bug?

Robert Gezelter — Tue, 07 Mar 2006 06:03:28 GMT

Robert,

For that matter, a similar comment applies to the DEVICE option. Both DEVICE and DIRECTORY operate as you describe, with and without the SYNTAX_ONLY option.

Operationally, you can describe the operation as a "silent" third default string, that of the current default device string.

In any event, it is not a recent change. I checked it on 6.2.

- Bob Gezelter, http://www.rlgsc.com

Re: DCL F$PARSE Bug?

Robert Atkinson — Tue, 07 Mar 2006 06:10:32 GMT

That's worrying. If it's been like that for so long, it must be by design.

I can't think why you'd have 2 different outputs for the same method of call though!

Rob.

Re: DCL F$PARSE Bug?

David Jones_21 — Tue, 07 Mar 2006 06:26:13 GMT

F$PARSE inherits it's behaviour from the SYS$PARSE RMS call, which has always behaved that way. A process has a default disk and directory that can be returned when not supplied otherwise, but there is no default filename. If there was an f$file_scan function, it would probably do what you want.

Supply a bogus DECnet node for the second argument and it will suppress using the process default directory, e.g. f$parse("SYS2:","XXX::",,"DIRECTORY)

Re: DCL F$PARSE Bug?

Robert Atkinson — Tue, 07 Mar 2006 06:39:40 GMT

Surely if run from a command file, then a default NAME and TYPE does exist, but $PARSE doesn't use them.

The behaviour changes dependent on the return field, which I found very worrying.

However, this is documented in the DCL Dictionary :-

"If you omit the device and directory names in the filespec argument, the F$PARSE function supplies defaults, first from the default-spec argument and second from the related-spec argument. If names are not provided by these arguments, the F$PARSE function uses your current default disk and directory. "

But, I don't agree with this.

F$PARSE by it's very name should return a parsed string of the information yuo give it. By this example, there is no way to explicitly return the DEVICE or DIRECTORY as blank.

In fact you have to do something like this, which is pants! :-

$ IF F$PARSE("ABC.COM","[XXXX]",,"DIRECTORY") .EQS. "[XXXX]" THEN ......

Robert.

Re: DCL F$PARSE Bug?

Steven Schweda — Tue, 07 Mar 2006 08:14:51 GMT

I guess that the whole OS (which uses $PARSE)
is wrong, too.

alp $ show default
ALP$DKA0:[SMS]

alp $ dire ALP$DKA100:
%DIRECT-W-NOFILES, no files found

(There exists an empty "ALP$DKA100:[SMS]".)

alp $ dire ALP$DKB300:
%DIRECT-E-OPENIN, error opening ALP$DKB300:[SMS]*.*;* as input
-RMS-E-DNF, directory not found
-SYSTEM-W-NOSUCHFILE, no such file

This is the way it works. I'd bet against it
ever being changed.

What should be used for the directory if you
specify only the device? Or for the device
if you specify only the directory? Perhaps
some sort of "default" device and directory?

Sometimes life is hard.

Re: DCL F$PARSE Bug?

Robert Atkinson — Tue, 07 Mar 2006 08:24:51 GMT

No....$PARSE should be $PARSE, not $SEARCH.

If you want to start using defaults, then you should have to explicitly supply them, i.e. :-

$ WS "FILE = " + F$PARSE("","CHANGED.TMP",,"NAME")
FILE = CHANGED
$ WS "FILE = " + F$PARSE("",,,"NAME")
FILE =

If I want dynamic defaulting, I just need to do F$PARSE("FILE.COM",F$ENV("DEFAULT"),,"NAME")

I restate....there is no way to return "" for F$PARSE("",,,"DIRECTORY").

Rob.

Re: DCL F$PARSE Bug?

Steven Schweda — Tue, 07 Mar 2006 08:34:08 GMT

Yup. As Mr. Jones said, you want an
f$file_scan function.

Writing your own was easier before ODS5
extended file names, too. Looking for "["
and "]" is not what it once was.

Everything's complicated.

Re: DCL F$PARSE Bug?

Hein van den Heuvel — Tue, 07 Mar 2006 08:45:52 GMT

I agree with most prior sentiments.

First: This is the way it is, and even if it might be wrong it can not be changed for the default case or it would break too much. I suppose one could design an alternative to "SYNTAX_ONLY", perhaps "FILESCAN", but that does not seem worth it to me. Still, Guy might like it and it would simply map onto the existing system service SYS$FILESCAN.

Second: Ido not think it to be wrong, albeit maybe lsightly confusion to some.
Think of it this way: F$PARSE does what 'the system would do' and gives you string handles to play with.
If you were to tell the system to $CREATE TMP
That is: no extention and it will not add an extention and thus parse does not return one.
Now issue $CREATE .TMP
There is no file name, only an extention, and the system will not add a filename and consistently F$PARSE does not return one.
In both cases however the file is created in the default directory and consistently F$PARSE returns that string.

For a slightly more elegant workaround I would recommend a brute-force string subtraction. It avoids the conditional:

$ test_dir = f$parse ("test:","",,"DIRECTORY","SYNTAX_ONLY")
$ show symb test_dir
TEST_DIR = ""
$ test_dir = test_dir - ""
$ show symb test_dir
TEST_DIR = ""

(I threw in the case difference for fun :-).

Hope this helps some,
Regards,
Hein.

Re: DCL F$PARSE Bug?

Hein van den Heuvel — Tue, 07 Mar 2006 08:53:51 GMT

oh my, lots of replies while I was slowly making mine.
And I was not even really done. The warmign on the lower case was only half of it. There is also a warning on the pointy brackets vs square brackets:

$test_dir = f$parse ("test:[abc]","",,"DIRECTORY")
$ show symb test_dir
TEST_DIR = ""

>> No....$PARSE should be $PARSE, not $SEARCH.

That is exactly what "SYNTAX_ONLY" accomplishes: no search.
It stops the actual search (which is the only way to return a dynamic file version string, but parse still tells you where it would have looked

Hein.

Re: DCL F$PARSE Bug?

Robert Atkinson — Tue, 07 Mar 2006 08:59:08 GMT

Interesting to read peoples points of view on this - wobbly bottom lip to know I'm in the minority on this one :(

I've logged an issue on the HP Advocacy site to see if they can add a "PARSE_ONLY" qualifier, which should make me and everyone else happy again :)

Rob.

P.S. Still disagree about the functionality of something that 'parses', so please feel free to leave you comments on how wrong I am ;)

Re: DCL F$PARSE Bug?

Ian Miller. — Wed, 08 Mar 2006 05:48:18 GMT

http://www.hpuseradvocacy.org/node/1994