×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Sorry, Murali, I don't have any specific posts in mind. I just have a vague
recollection of some discussion. I'd have to do the same thing you would -
go to www.midrange.com and put in some search words, like "wait for file to
arrive" or "how to know when a file has arrived". One of those may find you
something. I just don't have the time to do it.
Some other sites to search on are www.ignite400.com or www.search400.com or
www.iseriesnetwork.com (probably need to register) or www.mcpressonline.com
Are you saying that FTP is the way the files are being sent? Are the files
always of the same name? Do you have knowledge and/or control of the
program(s) that are sending the data to your iSeries?
Seems you need some way for your program (or progrrams) to know when a file
has arrived. If the files all have the same name, they could use different
members, not just the "*FIRST" member.
You COULD lock exclusively the file in JIMPORT. But this would make an FTP
transfer fail, not wait. And you'd have no way to know how long it'll take
to finish.
I think an FTP exit program could redirect the transfer to a different
member. Others probably know, or you could look up exit points for FTP in
the API section of InfoCenter, I think, or some kind of TCP/IP manual
there. And the same exit program could put an entry on a data queue that
your program would wait for. The entry would have the name of the new
member. Then your program would override to that member when it receives
the next data queue entry.
This way, all the data gets there without having to wait. Your program gets
notification of new arrivals. And your program can process each until it
finishes, then go to the next.
Hope you don't get flooded beyond the capacity to handle things. If you do,
you could start another job with the same program that'd watch the same
data queue.
Just an idea without thinking too much about consequences. And if the fiels
are coming in over NetServer, it might not be possible. Again, it might.
HTH
Vern
At 08:17 PM 6/6/2004, you wrote:
Thank you Vern! Sorry if I have nt written properly. I mean to say that
next incoming file has to wait automatically, while first incoming file
in process of receiving ? Would be really greatful if you can tell me the
previous discussion topics on this! I can go to archives and pick up the
mails...It is keep checking file in the library or FTP..
Thanks,
Murali.
Vern Hamberg <vhamberg@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hi Murali
Need more information, please. What has to wait? At any rate, I'm not aware
of any automatic way to know that a file is done. You could check for locks
on it. A process that is writing to a physical file will hold a lock on
it, perhaps exclusive, perhaps share-no update.
How do you detect that the file has arrived? I would think of an exit
program for FTP, perhaps, that could tell you it is coming. Otherwise, you
can keep checking the library for a new file. Or something else. I think
there've been discussions here on how to do this.
There is save while active on the various save commands. Check out the help
on that parameter, then go to the backup & recovery manual to get more
details. You'll need to know the implications.
HTH
Vern
At 01:56 AM 6/5/2004, you wrote:
>murali dhar wrote:
>We usually receive incoming files (from other systems) into JIMPORT
>library in our AS400system. Is there a way to automatic wait when there is
>one incoming file in process of receiving ?
>Or save while active ?
>
>
>Rgds,
>Murli.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.