Bug in DIRECTORY cmd on 8.2?

[Lachnitt_1]

Hi,

I'm wondering about the DIR cmd in 8.2 for his behaviour with the /EXCLUDE Parameter:

VMS7.3-2:
$ dir/wid=file=70 patches:.pcsi* /excl=*.PCSI-DCX_AXPEXE

DEC-AXPVMS-DNVOSIECO02-V0703-2-4.PCSI;1
....

All is fine !!!

But on VMS 8.2:

$ dir/wid=file=70 patches:.pcsi* /excl=*.PCSI-DCX_AXPEXE

%CLI-F-INVQUAVAL, value '*.PCSI-DCX_AXPEXE' invalid for /EXCLUDE qualifier

Any ideas!

Bye Kuddel

[Karl Rohwedder]

Hi Frank,

in a V8.2 system with all rating 1 patches installed:
$ dir/wid=file=70 patches:.pcsi* /excl=*.PCSI*
%DIRECT-W-NOFILES, no files found

Is DIR a foreign command?

regards Kalle

[Kris Clippeleyr]

Hi,

All seems well to me.
On OpenVMS Alpha V8.2:

$ directory/wid=file=70 *.txt*

Directory SID$COMMON:[WORK]

EPC_ERROR.TXT;1
PRODHIST.TXT;1
QJPI.TXT;1
SHOWPROCALL.TXT;2
TEST.TXT_TEST;1

Total of 5 files.

$ directory/wid=file=70 *.txt*/excl=*.txt_test

Directory SID$COMMON:[WORK]

EPC_ERROR.TXT;1
PRODHIST.TXT;1
QJPI.TXT;1
SHOWPROCALL.TXT;2

Total of 4 files.

System has latest patches.

Regards,
Kris (aka Qkcl)

[Lachnitt_1]

Thx at all.
But now all seems to be ok.
Don't know why this was gone wrong!
Bye Kuddel

[Volker Halle]

An additional detail has been left off in the problem description:

The logical name PATCHES included a remote node and device specification:

SYSTEM> sh log patches
"PATCHES" = "node"SYSTEM"::disk:[patches.v82]" (LNM$SYSTEM_TABLE)

Also a SET DEF PATCHES command preceeded the DIR command.

It is invalid to specify a device name in the /EXCLUDE file specification (see $ HELP DIR/EXCL) and the expanded EXCLUDE file spec is therefore invalid, although the %CLI-F-INVQUAVAL error message only shows the un-expanded file name string.

Another 'mystery' solved ;-)

Volker.

[Robert_Boyd]

Volker,

I understand your message, and at the same time I contend that this is in fact incorrect behavior on the part of the DIRECTORY utility. The user provided valid input according to the documentation. If it is invalid to use the /EXCLUDE qualifier when the current default directory is set to a DECnet remote directory, then an appropriate error should be generated, spelling out this fact, and the documentation corrected. Otherwise, I believe that the DIRECTORY utility should handle this case without any complaint.

Robert

[John Gillings]

Robert,

>If it is invalid to use the /EXCLUDE
>qualifier when the current default
>directory is set to a DECnet remote
>directory, then an appropriate error
>should be generated, spelling out this
>fact, and the documentation corrected.

Just because SET DEFAULT accepts a node specification, doesn't mean it's supported (it isn't) and doesn't mean it will always work as you expect (it won''t). The syntax for SET DEFAULT is documented as:

"SET DEFAULT [device-name[:]][directory-spec] "

There is no node name allowed.

Normally OpenVMS documentation only states what IS supported, but in this case there's an exception. see "SET DEFAULT" in the DCL Dictionary (boldface highlighted box)

"Note
The SET DEFAULT command will accept a node name with the device name (that is, nodename::devicename). However, the results of operations using a default with a node name are unpredictable. Some utilities and applications do not allow a node name to be specified in a file specification and will fail if the default file specification contains a node name."

Since utilities are "entitled" to assume only supported environments, the DIRECTORY command need not diagnose this specific circumstance. Although it would be nice if all OpenVMS utilities could report even more accurate and concise error messages, there are far too many potential unsupported configurations to detect and report them all. It's the economics of engineering. [at least in this case the CLI calls out /EXCLUDE as being the problem, what would some other OSes say in similar circumstances? ;-]

It would perhaps be better to have SET HOST reject node specifications, but OpenVMS engineering's fanatical adherance to upwards compatibility excludes that change, even though the usage is unsupported.

Bottom line is, if you SET DEFAULT to another node, and it does what you want, that's great, but if it doesn't, please don't complain!