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

[Dr Syd Nicholson <sydnic@xxxxxxxxxx>]

Thanks Evan,

A count of the members will let me know if there are any to process.

The system wil be in place for 1-2 years until AS/400s are replaced. The
company is centralising its IT and moving to Unix/Oracle. It will be
operational 24 hrs/day until then. This is indeed a data pump, moving
data from one platform to another and a quick solution is required.
However, it still needs to be efficient, performance of the AS/400 is
important.

After each member is processed it will be deleted. There should never be
an excessive number of members in the file.

Regards
Syd Nicholson


Evan Harris wrote:

> 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.
>
>
>
> _______________________________________________
> 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.
>