Re: IFS file create exit point. was: Monitoring IFS directory for file creation

[johnking@xxxxxxx]

Rob,

Thanks for the tip. The functions monitored by the exit point
(QIBM_QPWFS_FILE_SERV Format PWFS0100 functions shown below) seem ideally
suited for virus-checking, but I don't seen anything that looks like a
'file   close' function to indicate when it is safe for me to play with
the file contents. Perhaps some value on the 'Change file attribute
request' would work, or maybe I could loop until all file locks were
released...

     * X'0000' - Change file attributes request
     * X'0001' - Create stream file or directory request
     * X'0002' - Delete file or delete directory request
     * X'0003' - List file attributes request
     * X'0004' - Move request
     * X'0005' - Open stream file request
     * X'0006' - Rename request
     * X'0007' - Allocate conversation request

 John King
>> -----Original Message-----
>> From: midrange-l-bounces@xxxxxxxxxxxx
>> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
>> Sent: Friday, January 21, 2005 4:03 PM
>> To: Midrange Systems Technical Discussion
>> Subject: Re: Monitoring IFS directory for file creation
>>
>> I believe there is an exit point for IFS with V5R3.  Byteware is using
>> this
>> for automated virus scanning.
>> Is this it?
>> http://publib.boulder.ibm.com/infocenter/iseries/v5r3/ic2924/info/rzaii/rzai
>> imstexfile.htm
>>
>> Rob Berendt
>>
>> <snip>
>>
>>
>> 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
>
>