Re: File lock problem

On Tue, 2 Jan 2001, Jim Langston wrote:

> Okay, this is my scenario:
> 
> I have a file being sent to me automatically every day through RJE.
> This file is being sent from one of our customers, and I don't want
> to have to get my customer involved in this.  
> 
> What I am wanting to do is as soon as I receive this file I want to
> send it to another one of our AS/400s.  This file will be processed
> on both AS/400s, different information.
> 
> I know I can create a never ending job that will check the last member
> of the file and compare it against a data queue, and if the file member
> is different than the last one received (which would probably be *blanks)
> I would then try to allocate the file until I could, once I could allocate
> it I would send it to my other AS/400 then do some cleanup (copy it to 
> another file name maybe, or just update the data area with the last member
> received).
> 
> I really don't want to do this, however, as this never ending job is going
> to be eating up CPU cycles checking for the presence of a new member.  And
> yes, I understand it won't be that much CPU, but I would rather it was nothing
> until such time as the file was actually received.  Which is where my idea
> of a *insert trigger came from, but then how do I know when the file is 
>finished
> being written and is safe to send?
> 

So why not combine your two ideas:

1) Have an insert trigger that does nothing more than throw an entry onto
          data queue.
2) Have a never ending program that waits for entries on the data queue,
          not consuming any CPU until it gets an entry.
3) When the NEP gets a new data queue entry, it does an ALCOBJ, waiting
          for the member to become available, then copies it.

You'd need some extra code to look for duplicate records on the data queue
(for example, when a new member is added with more than one record, the
insert trigger will fire for every record) but this shouldn't be too hard
to surmount...  especially if the never ending program can have a database
that keeps track of what it has and hasn't already sent...  you could even
use an API to get the date/time that the member was added to the PF if the
member name isn't unique...

You get the idea....


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---