Re: Monitoring IFS directory for file creation

Carsten,

 Thanks, I missed that article in "iSeries". I love that magazine (we've
subscribed since it was a stapled-together newsletter for the S34 back in
the early '80s) but trying to locate anything on their website always
raises my bloodpressure <grin>!

 Question about the lack of a journal event: When I enabled journaling on
a test directory and used Explorer to copy a small file into that
directory, a 'CS' journal entry was visible from DSPJRN OUTPUT(*) as
shown below. This record's position in the journal, after the 'CM' and
'EC' and 'CA' events leads me to think this is the record I should
monitor for. Am I missing something?

 Interesting to note that the JOOBJ field created by DSPJRN
OUTPUT(*OUTFILE) results in some hex value - probably some file handle
that needs to be rsolved with yet another API!

Many thanks, John King

Journal  . . . . . . :   IFSMON          Library  . . . . . . :   JONLIB
Sequence . . . . . . :   88
Code . . . . . . . . :   B  - Integrated file system
Type . . . . . . . . :   CS - IFS object closed
Object . . . . . . . :   /home/JOHN/Junk/test.jpg
Flag . . . . . . . . :   0               Ref Constraint . . . :   No
Date . . . . . . . . :   01/24/05        Time . . . . . . . . :   12:21:01
Count/RRN  . . . . . :   0
Job  . . . . . . . . :   003683/QUSER/QPWFSERVSO
Commit cycle ID  . . :   0
User profile . . . . :   JOHN            Program  . . . . . . : QPWFSERVSO
Ignore APY/RMV . . . :   Yes               Library  . . . . . : *OMITTED
Trigger  . . . . . . :   No                ASP device . . . . : *OMITTED

> On Saturday, January 22, 2005 5:13 AM, Carsten replied:
>
> Hello John,
>
> - One of the challenges that you are facing is the absence of a journal
> event associated with the file being closed. In stead you can use the
> QP0LROR (Retrieve object references) to detect when there is no longer
> being
> held a lock against the file.
>
> I wrote an example of such a utility a while ago that can be found here
> (ProVIP membership required):
> http://www.iseriesnetwork.com/resources/clubtech/index.cfm?fuseaction=ShowNe
> wsletterIssue&ID=19712
>
> Let me know if you have any questions.
>
> Best regards,
> Carsten Flensburg
>
> ----- Original Message -----
>
>> Hello all,
>>
>>  We need to automatically execute a job whenever files are created in
>> a particular IFS directory. The process needs to work no matter how
>> the
> files
>> arrive: via FTP, drag-n-drop from Windows Explorer or other processes
>> yet
> to
>> be invented. I could write a sleeper program to monitor the directory
> every
>> 'x' minutes, but would rather take advantage of a system function if
>> possible.
>>
>>  This appears to be do-able by journaling the IFS directory. The
>> archives are full of examples of doing this for DB2 files, but I want
>> to make sure this is viable for IFS directories before committing to
>> management. Or
> maybe
>> there is a simpler way? Would someone be kind enough to critique this
> and/or
>> steer me in the right direction? I think I need to:
>>
>> 1) Create a journal and receiver.
>> 2) Associate the IFS directory with that journal.
>> 3) Submit a QBATCH job that uses RCVJRNE to watch the journal.
>> 4) The QBATCH job wakes when an entry appears in the journal. If it
>> determines that a 'file close' action occurred it will submit a job to
>> process and remove the IFS file.
>> 5) QBATCH program goes back to sleep again.
>>
>>  I've completed steps 1) and 2) and manually added files to the
>> monitored directory. Sure 'nuff, the system creates multitudes of
>> journal
> entries.
> It
>> appears the 'CS - IFS object closed' is the one we want to watch.
>>
>> Questions:
>> 1) Is OpsNav the only way to manage IFS journaling? I don't always
>> have a fully-loaded PC next to me and a green-screen command would be
>> a nice fallback.
>> 2) Using drag-n-drop from WinExp creates 50+ journal entries for each
>> file
>> created: commitment control, attribute changes, stuff I couldn't care
>> less about. That seems wasteful, plus I'm confused about exactly which
>> entry indicates that the file is closed and is safe to process. Can
>> someone enlighten me?
>> 3) Does a program using RCVJRNE behave similarly to 'QRCVDTAQ'? That
>> is, does it wait patiently until an entry appears or does it require
>> something different?
>> 4) What techniques should be used to ensure that the QBATCH program is
>> running and how to restart it without re-processing existing entries?
>> A utility named 'DspAudLog' by Mr. Oguine published by iSeries in June
>> 2000 records the last-used journal sequence number in a data area. Is
>> this
> still
>> the best technique?
>> 5) What else have I missed?
>>
>> Many thanks, JK
>
>
>
>