× 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 thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.