- This topic has 11 replies, 6 voices, and was last updated 13 years, 6 months ago by .
I’m hoping one of the brilliant minds here can sort out what has become a most perplexing problem.
We have a number of batch billing jobs using fileset-ftp, which have been running for years without manual intervention. As we’ve needed a new one, we’ve simply copied the threads, process, tclprocs, translators, etc and made any necessary window-dressing changes for the system/department involved and life has continued pretty smoothly…until now. The latest one has been in production for two weeks and has required manual intervention every day.
What appears to be happening is that that advanced scheduling does not work with the ftp for this process. Sometimes it looks like it just doesn’t trigger at all and sometimes it looks like it tried to open a connection and the thread goes into “opening status” and never comes out. However, that’s just what we see on the surface. Once I turned on sane_eo, things looked even more perplexing to me. It actually looks to me as if the process connects to the ftp site when I start it up, even through that is unnecessary, and then tries to hold onto that connection until the scheduled time. I suspect the connection is being lost but the process never recognizes that officially and that is what is causing the actual fetching of the data when the time comes to fail.
Here are our basics: Cloverleaf 5.4 (AIX v.5 r.2)
Under the Fileset Options tab in the inbound thread:
Directory Parse: tps_ftp_impact_dft
(we are using this currently only because of the inconsistant behavior of the process) Scheduling
Read Interval: 5
Max Messages: 500
Use Advance Sheduling: checked [The shedule is currently set to 19:10:00, but we have been moving it daily (often during working hours) due to having to watch it; we would like it to be 19:30:00 M-F]
On the FTP options tab:
The login and password are filled in correctly. I can use these to ftp into the site using an ftp tool and inconsistantly through the process.
Dir List Command: nlst
Read Time: 5
Pulse Time: 500
Close Connection After Write: checked
Delay Connection Until Needed (I don’t think this works as I think it should)
Data Type: ASCII
FTP Host Information
Host: [not the ip address but the host name of the computer]
I’m including the tclproc for the directory parse. I had a flag in there to not read the directory on start up but since it won’t work reliably on a timer, I now have to manually start and stop it when asked, so you’ll see the flag commented out. Maybe someone will see something in there that is buggy. Also maybe someone can suggest how I can keep it from connecting at startup, which it was doing with or without the flag.
I’m also including two sane_eo logs I saved. They were run back to back and prove that the process on a timer is unpredictable. All I did between stopping and starting it was change the time in the schedule and one time it worked and one time it didn’t. The time it didn’t work, you can see where it had and unexpected read and failed — that time, the thread just stayed green and then when the scheduled time occured, it went into “openning” and stayed that way. No disernable error was generated, nothing that would have generated an alert.
There’s only one more thing I want to add that is different about this connection from the others; it’s something I have no control over and know nothing about. Aparently our “network guys” set this ftp folder up through a “virtual conduit” so it’s not on the actual server that’s generating the billing files. I’m told that it should make no difference and that we “see” exactly the same as we would if it was an ftp folder on the actual server. Has anyone else had experience with this?
I sure hope someone can provide some wisdom and advice. I’ve been banging my head on this one for two weeks and I’ve tried every piece of advice I thought I could gleam from this forum.
Thanks in advance,
Systems Interface Specialist
Maine Medical Center
- The forum ‘Cloverleaf’ is closed to new topics and replies.