Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Curious Directory Command Behavior

 
SOLVED
Go to solution
jjinva
Advisor

Curious Directory Command Behavior

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?









12 REPLIES 12
Richard Brodie_1
Honored Contributor

Re: Curious Directory Command Behavior

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
Honored Contributor

Re: Curious Directory Command Behavior

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
Honored Contributor

Re: Curious Directory Command Behavior

>> 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.
Honored Contributor

Re: Curious Directory Command Behavior

Hein - max version is 32767
____________________
Purely Personal Opinion
Ian Miller.
Honored Contributor

Re: Curious Directory Command Behavior

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


____________________
Purely Personal Opinion
Peter Weaver_1
Frequent Advisor
Solution

Re: Curious Directory Command Behavior

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

that should get you what you were after.
jjinva
Advisor

Re: Curious Directory Command Behavior

>>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
Honored Contributor

Re: Curious Directory Command Behavior

>>>>>$ 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
Advisor

Re: Curious Directory Command Behavior

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
Honored Contributor

Re: Curious Directory Command Behavior

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

Cheers,
Hein
Hoff
Honored Contributor

Re: Curious Directory Command Behavior

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
Honored Contributor

Re: Curious Directory Command Behavior

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