Re: system event trigger whenever a source file member is updated

Tom,

The file will always exist. The FTP process from the other machine will not
create the file.

I don't know how often new members will arrive.

I think I have two approaches. Your approach, where a program periodically polls
the file and lists new members. I agree that this won't be too resource hungry,
or, use the FTP exit point to trigger the event, add a small delay of a few
seconds, and then list/process any members.

6 and two 3s I think, regarding the above choices. I think I prefer your
approach - I was just hoping that OS/400 may have some way of "listening" for
this event allowing me to make the process more efficient.

Thanks to all who helped with this question.

Syd Nicholson



Quoting thomas@inorbit.com:

> Syd:
>
> Seems unusual that the sending site controls the names, but there always
> seems to be restrictions whatever we do. (In the extreme, what if they
> chose library QSYS and file name QADBIFLD? :-) )
>
> Okay, does the file have to exist ahead of time? I mean, I realize that
> a pre-existing file can have advantages in terms of field definitions,
> etc.; but you'll have better luck with the audit journal if you trigger
> on the file create than if you try to trigger on member. As soon as you
> can lock the file *EXCL after creation, you could rename it. That lets
> you work with the data while making the reserved file name available
> once again.
>
> But I'm not sure any kind of audit journal monitor is going to be
> appreciably faster or more efficient than a basic NEP that periodically
> (every 10 seconds? 60 secs? 300?) wakes up and lists the members in the
> target file and hands them off for processing. If all it needs is to
> check the list of members, it won't be much of a resource user... until
> there's actually a new member to process of course.
>
> Tom Liotta