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

Syd

Rather than actually list the members you might want to just retrieve the
count of members in the file using the file description API (name escapes
me at the moment and I'm at home). This would probably be marginally
quicker (which could be important if there are lots of members being
transmitted) and less resource hungry although admittedly it could be
considered another layer of logic depending on how obvious you like the
things you are doing to be in code.

If this is a one off exercise to pump data from one platform to another and
there will be a lot of data there is a limit on the number of members that
can exist in a file at one time (32,767 I believe). If you exceed this it
is a rather horrible experience as it will damage the file beyond repair.

Also be aware that the number of members can impact user profile internals
in terms of how many objects a user can own - there are limits here that
are rather nasty although only applicable if you are talking many many
thousands of file members.

Apologies if you already have a handle on these factors.

Regards
Evan Harris

>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
>
>_______________________________________________
>This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
>To post a message email: MIDRANGE-L@midrange.com
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
>or email: MIDRANGE-L-request@midrange.com
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/midrange-l.