Re: File lock problem -- MIDRANGE-L

Jim,

This comes from memory snippets from about 10 years ago and some scraps of
old code.

There is a table on the system that contains an association between the name
of an incoming RJE file and a program to be executed when the file has been
received. I think it also associates the RJE file with an AS/400 file.
Unfortunately I do not have RJE on my current system, so cannot check. In
your program you can also call the IBM program QMRSWTR with a 30 byte parm.
This parm will come back with the lib, file and member of the file just
received (not sure of the exact format). For some reason, I remember the
table name containing the string "WT",

----- Original Message -----
From: "Jim Langston" <jimlangston@conexfreight.com>
To: <MIDRANGE-L@midrange.com>
Sent: Tuesday, January 02, 2001 4:48 PM
Subject: File lock problem


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

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