With MSG it is possible to set up a record with type C and include code and command in the message text in order to run a program when the message is called.

I would like to do something similar with fsmsg, but at first glance it doesn't seem to be possible. I will shell FSMSG if that is my only option (and if it works). On the other hand, if there is a more graceful option, I'd rather do that.

At issue is some processing overnight that has not yet been identified that is messing with our batch processes. We're not getting FS109 regularly overnight, and I suspect interference with backups or some such thing.

My idea is to intercept the FS109 call and suspend all activity for X minutes, after which, processing will resume.

As is, a message is displayed to screen requiring user input. That means processing halts until an operator can press the Enter key, at which point processing invariably resumes normally.

Alternatively, I might define an indexing process to simulate pressing the Enter key.

Thoughts/suggestions?

Victor,

I shelled FSMSG to provide logging of error messages and, as you note, to avoid response messages when executing in batch mode. This is a very good approach.

FS109 says, invalid volume or directory. This would imply that a data volume cannot be attached (because it is read-only?) during processing. Suspending the batch process would not solve the problem, as the attach has already failed when the error message is encountered. If this is occurring during backup, you should look into rescheduling the nightly backup procedures to avoid interference.

Gerald

"FS109 says, invalid volume or directory. This would imply that a data volume cannot be attached (because it is read-only?) during processing. Suspending the batch process would not solve the problem, as the attach has already failed when the error message is encountered. If this is occurring during backup, you should look into rescheduling the nightly backup procedures to avoid interference."

The batch process I referred to runs 24 hours a day, 7 days a week. Rescheduling backup won't work. However, I can delay processing when there is a problem, such as this. However, I cannot predict when backups occur. I agree that it is probably backups causing the problem.

It doesn't matter if the volume is already not attached. The entire cycle repeats, and it will be picked up the next time an attach succeeds. Suspending operation for a while gives the backup process now detected time to complete before the next attempt. Besides, the volume is probably already attached anyway (in which case a different error will be reported, which can also be dealt with).

Victor

If the batch process is running cyclically from the indexing hook, there should be an easy way to deal with this. First, shell FSMSG and check for a batch indicator to decide if the message would display. Then, put a postprocessor on the indexing hook to halt execution of your batch process during backups.

But how do you "halt execution during backups?" At the OS level, execute the backup through a .BAT or .CMD file which starts by writing a BACKUP.LCK file to the AREV directory, and finishes by deleting BACKUP.LCK. Then have your indexing postprocessor check for the BACKUP.LCK file before kicking off. This will minimize the delay in batch processing to just the time required for the backup.

"If the batch process is running cyclically from the indexing hook,"

It is not. There are 9 dedicated PCs that run cyclically, period. The data they process are received in files of about 350 megabytes each. These files are parsed into work tables located on a local hard drive, where HTML documents are generated (10,000 cases with anywhere from 1 to a dozen or so documents each) per 350 megabyte file. Each document is gzipped, and the lot zipped and ftp'd to a unix server, where the zip file is disassembled and the gz files placed in their appropriate locations.

Meanwhile, status information is logged in Arev files at various points in the process. None of this is time critical. If a document does not get converted, then a completion flag is not set, and it is resent for reconversion.

Anyway, as you can see, the bulk of the processing is not on the server. So processing normally can proceed even during backups. There is plenty of error detection built in so that if a step is skipped it will be picked up later.

So all I really want to do is to intercept the message, log it, and proceed.

"check for a batch indicator to decide if the message would display."

I don't follow you here.

"Then, put a postprocessor on the indexing hook to halt execution of your batch process during backups."

Currently, there is no indexing. I'm considering to enable indexing so that I have a hook to check in the case the PC becomes idle, indicating there is an error message. If this condition is detected, then the error can be logged and processing proceed.

Since we have redundant PCs, currently what happens is that the PCs check on each other. If one of them detects that another one has not been processing for over an hour, it sends an email to the operators that the PC is not running. Then the operator can take appropriate action.

We've been running this way for about 3 years now, and only within the past month have we been getting the FS messages.

"At the OS level, execute the backup through a .BAT or .CMD file which starts by writing a BACKUP.LCK file to the AREV directory, and finishes by deleting BACKUP.LCK. Then have your indexing postprocessor check for the BACKUP.LCK file before kicking off. This will minimize the delay in batch processing to just the time required for the backup."

Unfortunately, I have no control over the backup process. That is the domain of a different group. Now that you mention it, though, I believe they set a flag when the backup is in progress. I will look into checking for that flag. Then I'll only have a problem when my process takes longer than the time it take between the start of the backup to the time it gets to my files. I can work around that, too.

Not sure how far back this goes, but tested in 3.12

COPYROW SYSMESSAGES FS109 TO:MESSAGES

Now, when FSMSG called FS109, it will execute the one in MESSAGES, so you can modify the structure as required.

Code & Command are @VM delimited in field 11 of the record.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

For anyone paying attention, that should have been

COPYROW SYSMESSAGES FS109 TO:(MESSAGES

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

I tried that scenario already. The problem is that the volume name is passed in %1%. I tried making field 1 of the message C and field 11 the code and command, with %1% as the argument of the command, but this didn't work. Is there another way to pass parameters when calling a subroutine this way?

Of course for this specific scenario, I know what volume it is, but I'd like to make the "message" generic.

A very interesting discussion, Victor, showing a rather specialized approach to batch processing. I had said,

"check for a batch indicator to decide if the message would display."

If your AREV programs were partly interactive, partly batch, then a labeled common or other variable (@USER?) could be set to indicate that the running program is batch. From your explanation, essentially all your processing is batch.

If a process is set on the indexing hook, and a message displays, the indexing process would be executed. This would be a very good way to detect idle processors. Set the idle start time to the interval to wait for a backup to finish.

I'm not totally sure if recursion will effect getting rid of the message, but here's the next idea. You could try a macro or captured playback, as these features may allow you to kill the message. If I remember my AREV, you would set @PLAYBACK={ESC}{ESC} and maybe something else, and then AREV would take it from there. Presto, your system halts with Fsmsg(), waits a specified interval, then plays back the to kill the message and restarts. This is practically cheating, there is so little coding required.

Actually, what is required is a {CR} not {ESC}, but that's essentially the approach I was going to take. And if the backup wasn't finished yet, then the process simply iterates. No big deal.

Good call, Sprezz. Setting Code/Command replaces the message display with an execution. I have used this technique to cure a problem with network drivers not loading. From SYSPROG, the standard message about "No network driver…" displays and the user may press to continue. My application has a separate MESSAGES file, where I use Code/Command to display the FSMSG, then perform an OFF. This prevents any possibility of ignoring the messages and therefore bypassing record locking. The trick is a separate MESSAGES file in the application.

Then Victor could just set the message to type 'N' to avoid the display and ignore the error.

I can answer one question but not the other. My application message FS175 says type "C", and everything else blank except the message text, which is two lines:

C

CALL CATALYST( "HL","@SYSMESSAGES@FS175" ) & PERFORM "OFF"

With the "C" type code, multiple statements may be executed separated by &. The question left is whether the %1% parameter passing can be used for the catalyst HL call. A real AREV head would have to answer that, but you could try adding ",%1%" to the end of the error number. If you have error logging, possibly the error could be logged directly and then the program could be reentered through the PERFORM.

"Then Victor could just set the message to type 'N' to avoid the display and ignore the error."

I'm pretty sure I want to log the error.

I suppose I could use code X and then RUN table program_name %1% and then parse @sentence. Using ,%1% did not work appended to the program name when S was used as the code. I did not try C. It didn't dawn on me. Besides, it is known to have memory problems.

@ANS does not contain the information you need?

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

I think that will work.

View this thread on the forum...