Curious Directory Command Behavior

[jjinva]

VMS8.2 On an ES47: Attachment shows the commands and results I ran.

Trying to find *.log files created today before 03:00 with the following command:

$ dir *.log /since /before=03:00:00/date

Returns all the log files within the specified time.

Now I want to get only the last version of the log so I use this command that adds a semicolon after *.log.

$ dir *.log; /since /before=03:00:00/date

I was expecting the last version of all the logs but only get the log that had a single entry.

Is this the expected behavior from this command sequence?

[Richard Brodie_1]

It might be, there is insufficient data to tell.

That is what you would see if the latest version of the other TESTx.LOGs is dated after 3am. You would need the output of:

dir *.log; /date

to tell that. ; means specifically "the latest version", not "the latest version that matches these other criteria".

[Hoff]

If the goal here is to process a list of log files under application control, then this task is usually a series of lexical functions (including f$search() and f$file_attributes() and f$cvtime() (with the COMPARISON format) and a DCL loop to process each file. Not with the /OUTPUT of the DIRECTORY command, as I suspect this design might be headed.

[Hein van den Heuvel]

>> dir *.log; /since /before=03:00:00/date
>>... get the log that had a single entry.
>> Is this the expected behavior from this command sequence?

Yes. That command tell directory to look for the latest version of all the files with type 'LOG' and prune that result set, leaving only those created today, before 03:00.

You'll need to parse directory output, or like Hoff indicates run your own lookup loop and check the articulates with DCL ( F$FILE "RDT" or "CDT" ).
Or perhaps with PERL and the STATS array, or perl functions acting on the stats array ( notably -M or -C ).


btw... I'm sure you know that those version numbers are dangerously close to failing right? (32766 being the max).

hth,
Hein.

[Ian Miller.]

Hein - max version is 32767

[Ian Miller.]

the key thing is the order of the tests.
1. Find files of that name and the specified version (; means version 0 i.e the highest version)
2. matching the dates

[Peter Weaver_1 · Accepted solution]

Try
$ dir *.log /since /before=03:00:00/date /version=1

that should get you what you were after.

[jjinva]

>>Try
>>$ dir *.log /since /before=03:00:00/date /version=1

Thank you. That does give the intended result, but the question is still "why didn't adding the semi-colon to the dir command produce this result."

If I remove the "/before=03:00" from the command it works as expected, it gives me the latest version but it's after 03:00.

Is there a problem with mixing "/since and /before" or "/after for that matter.

For clarification purposes: We had a problem between midnight and 3am this morning and I was looking for what might have caused the problem. Not going to do any processing, just look at logs.

[Hein van den Heuvel]

>>>>>$ dir *.log /since /before=03:00:00/date /version=1

Thank you. That does give the intended result, but the question is still "why didn't adding the semi-colon to the dir command produce this result."

As I replied before.

Think about it...

How does directory know which files to look at?
It goes into the directory (that's why it is called 'directory and not DFU) to find files to match the basic file name desired.
Then it checks whether attributes (other than FID) were requested and whether any filters were specified. If so, it accesses those potential candidates found and looks to see whether those filters apply

The requested match is for: *.LOG;
That means in OpenVMS speak "the highest version numbered file for each .LOG file.
Using the output you provided that is for some file with a version higher than 24896.

So it accesses that file, and only that version of that files, and finds it does not
fit the date filter.

Regards,
Hein

[jjinva]

Thanks to Peter for the solution to what I was looking to do and to Hein for his patient explanation that took a little while to sink in. I should have assigned 10 points for both but I had assigned points before I figured out that I had an answer. I owe you both points and will catch up next time. Thanks again!

[Hein van den Heuvel]

Most welcome. I have plenty of points. No worries there.
I do appreciate the acknowledgement.

Cheers,
Hein

[Hoff]

Um, I might be confused then.

Out of curiosity, why do I get the expected matches for the highest version of each of the files that matches an analogous command on a test system, rather than (as shown in the OP's example) just one match for just one file, even though there are other files that seem to match the selection criteria?

Here, I'm seeing what the OP was expecting to see. Read down the OP's list of files. There are other files that should have matched that selection. Specifically, these files:

TEST2.LOG;8472 24-MAR-2010 02:59:47.78

TEST3.LOG;6627 24-MAR-2010 02:17:13.18

TEST4.LOG;104 24-MAR-2010 02:16:53.49

TEST5.LOG;15964 24-MAR-2010 02:17:12.01

TEST6.LOG;1760 24-MAR-2010 00:19:50.02

[H.Becker]

From the original post it wasn't obvious that there were newer versions of some of the log files.