We have a situation where automated process run overnight. Sometimes, an overnight process severs the Netware connection to known workstations. I think this was designed so that backups could take place successfully. It is possible that we can isolate the configuration that does this and disable it for our processes, but so far, attempts to disable this have not been successful.

So, I'm posting this message to see if there is something that can be done from within Arev to gracefully handle this situation. The netware client is configured so that any lost connections are reestablished if severed. However, this does not seem to work with Arev. I assume that a handle of some sort is obtained upon first connection to the network, and Arev continues to use this same handle, which becomes invalid when the network connection is severed and subsequently re-established.

Logging off and back on always resolves the problem, but I'm hoping there is an automated process that can be used instead. Perhaps all we'd need to do is to reattach the appropriate volume (perhaps after first detaching it), but then the question is how we'd know when we need to reattach the volume. By the time we know a volume needs to be reattached (or whatever the appropriate action is), we have a fatal error.

Right now all I can think of to do is reactive, like, for example, writing an MFS to intercept failed IO and do an attach (or whatever) before a retry.

Any other suggestions? I'm still pushing for ensuring that our connections are not cleared by whatever automated process is clearing them, but I'm not holding my breath.

Victor,

I guess I'd be using a "DOS terminate process" verb to kill the AREV session and a batch file to loop back into AREV again and resume.

Another way might be to split your job across several machines so it doesn't run as long. Depends on how the big job can be carved up into smaller tasks, and whether resumption is possible.

This sounds mighty weird, Victor - the implication is that AREV is at fault, when it really sounds like a networking infrastructure problem, or a faulty device somewhere.

Another option might be to use a single OI32 for the process - it is much faster as a rule. By shortening the time window your interruptions may be avoided.

Steve

The Sprezzatura Group

World Leaders in all things RevSoft

] I guess I'd be using a "DOS terminate process" verb to kill the AREV session and a batch file to loop back into AREV again and resume.

We've explored something along these lines, and the problem is that the custom logon process is very interactive. It would take a significant amount of development to get around this – more than, say, monitoring the process to clear errors manually on a daily basis and manually relog on.

] Another way might be to split your job across several machines so it doesn't run as long. Depends on how the big job can be carved up into smaller tasks, and whether resumption is possible.

We currently are using 10 machines. Even so, the estimates are for the process to run for several months before completing. Actually, in this case, the limiting factor is not Arev but the mainframe. It must continue regular day to day operations in addition to creating the daily conversion files for us.

] This sounds mighty weird, Victor - the implication is that AREV is at fault, when it really sounds like a networking infrastructure problem, or a faulty device somewhere.

It's an infrastructure process – not a device problem. Bear in mind, most of the processes involved were designed in the 80s using RevG.

] Another option might be to use a single OI32 for the process - it is much faster as a rule. By shortening the time window your interruptions may be avoided.

Unfortunately, this is not an option. It has been explored and eliminated as a viable option. I was not involved in the analysis, so I don't know all the details for why this is the case, but knowing that the system is really a REVG application ported to Arev may offer a bit of a clue. I think this is another case of "it's possible but would be more trouble than it is worth".

I think I have a solution that will work in our situation. The process uses DOS-level operations to wait for a file to become available from the mainframe to process. I've just added code to reattach the Arev volume on the network when a file is found for processing. All workstations this morning has message FS456 displayed. If I went to TCL and attached the volume, then returned and continued, the process continued without a problem. However, if I just tried to continue without reattaching, the PC hung up. Since our process was easy to modify to include the attach before processing to Arev files, this works well.

I don't know if this is relevant, but we are using the REVELATION user with the NLM.

View this thread on the forum...