File lock problem

[Jim Langston <jimlangston@xxxxxxxxxxxxxxxx>]

I figured it out.

The job that is updating the file is the one that is calling 
the trigger which is the one allocating the file so that's legal
and is why the lock is being accepted.

Well, shoot, that's just not going to work then, is it?

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?

Any ideas, comments, suggestions, criticisms?

Regards,

Jim Langston
+---
| 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
+---