Directory Change Notification - ODS-2/ODS-5

[Ishan Oshadi Jayawarden]

I knew I should've checked "help open"...

[Ishan Oshadi Jayawarden]

On first glance this seems to be capable of doing what I want... though polling, it'll be sleeping most of the time anyway...

$ open/read/share f logfile
$loop:
$ read/nolock/end=reboot f ln
$! write sys$output ln
$! process line
$ goto loop
$reboot:
$ wait 0:0:2
$ goto loop

[Richard W Hunt]

The thing that bothers me about this is that you are working from the wrong end of the data flow path. Looking at the destination for a change is not going to really help because the thing doing the listening with that OPEN/APPEND action might actively block the report producer from working.

Usually, as a matter of good programming practice, it is better when possible to have the acting program (producer) send the notification to the reacting program. This allows the reacting program to be passive and not affect system performance. It also allows the reacting program to respond very quickly when the right signal is given.

If the two programs are on the same cluster, you might even consider THIS mechanism... let the reacting program suspend itself and have the action program send a RESUME. You can do that cross-cluster with DCL SET PROCESS/RESUME /ID=xxxx or something similar to that. If it gets "hung" you can do a manual resume with the same command.

[Antoniov.]

Hi Oshadi,
I'm not sure get your real intention.
I guess writer process do something like this:
$ open/write/share=read f logfile
$loop:
$ write f
$ ...
In this case your example can work as you expected.

Antonio Vigliotti

[Ishan Oshadi Jayawarden]

Hi Antoniov... what I'm doing here is reading a central logfile; all report generating apps record their output filenames in this logfile; so if I can read this log file line by line, in close-to real-time, I'll be all set. The bit of script I posted lets me do that...

So in effect, I'm down to polling a single file, and only for the last line only, (can I call it non-blocking IO in DCL? :) instead of polling a big directory.

It's not the most elegant solution, but one major advantage is that I don't need to modify any writers... this is a good thing for me because this script should (in theory, at least) work without any changes through application upgrades, or even on different sites...

[Antoniov.]

Oshadi,
it's not elegant but works!
Don't forget, writer application has to open with /SHARE=READ qualifier.

Antonio Vigliotti

[Wim Van den Wyngaert]

About the locking ...

It is better to create the file with extention .NEW and when it is completely created to rename it to the .LIS or whatever extention. This way you won't see files being created during f$search.

About signaling ...

What if the signal didn't arrive (e.g. cluster transition and tcp timeout when tcp is used for signaling) ? Make sure that at startup, you start processing the files before you get the signal.

Wim

[Wim Van den Wyngaert]

And FYI
http://forums2.itrc.hp.com/service/forums/questionanswer.do?threadId=602985

Wim

[Wim Van den Wyngaert]

And hope you don't use high water marking mixed with big file creations.
http://forums2.itrc.hp.com/service/forums/questionanswer.do?threadId=603651

Wim

[Ishan Oshadi Jayawarden]

brrr... yes, we have HWM; big file creations are infrequent, though...