fileset-local in run mode at process start

[Greg Eriksen]

I’m setting up a fileset-local thread to pick up a file that an will be  ftp’d to a directory on the cloverleaf (AIX) server once a day.  Since I don’t need to continually poll the directory, I set up advanced scheduling to a specific time each day.  What I find is that whenever I bounce the process that this inbound thread belongs to, it immediately executes the directory parse tps proc in “run” mode, which then tries to find a file(s) to process.

This doesn’t seem like correct behavior to me.  At most, maybe the proc should be executed in “start” mode when the process is bounced.

Does anyone have an explanation for why it should be working this way?  Or is there anything in the arguements passed to the proc that would let the tcl code distinguish between a “run” mode that is due to a processs start vs. the advance scheduling?

Topic

[Greg Eriksen]

I found a solution to what I was trying to accomplish and thought I’d post it here in case I missed something obvious or better.  What I had wanted to do is have the directory parse tps proc check the local directory for a file the billing department was supposed to put there, and if it didn’t find it then raise an unholy stink about it and send out accusatory emails.  But if the proc was going to be executed in ‘run’ mode whenever the thread or process happened to be bounced, then it would falsely trigger the alerts at times the file was not supposed to be there.

After my original post on this topic, I echoed some keylist commands to confirm that the proc arguments didn’t contain anything I could use to identify that the thread had just started.  I also put echo statements in each of the possible modes and learned that at startup the proc gets executed in BOTH ‘start’ mode and then ‘run’ mode.

I thought about using an Alert to check for the file’s existence rather than the dirParse proc of the inbound fileset-local thread, but ‘file change’ just fills the log with errors that it can’t status a file that doesn’t exist, which doesn’t trigger the associated alert action proc.

So, my solution was to global a variable called something like, “(proc_name)_startup”, and in the ‘start’ mode I set it to a value of “1”.  In the ‘run’ mode I have an if statement that when the variable is set on, it just sets it back to “0”, else it executes all the rest of the code I want to occur in the normal ‘run’ mode.  That way the first ‘run’ that occurs after a startup just sets the startup flag off.  And the subsequent ‘run’ that is triggered by the advanced scheduling performs the actions I only want to happen at that time.  This seems to work so far in testing, but that’s never quite the same as real life.

[Michael Hertel]

I would put a safety feature in the run area of your proc to check for the time and compare it against a range.

If $now is outside the time range, go quiet or send nice emails instead 😀 .

[Richard Hart]

Greg.

It is possible to write some code to replace the default Cloverleaf action – TPS Directory parse.

You have more control over which file, or no files are processed. You can choose to return files to process or not.

As an example, we have code that ‘reads’ zipped SMAT files and sends them on.

When a SMAT file is first in the list, we split this into files that contain the messages, returning ‘no file’.  The second iteration will return the first of the message files from the SMAT file.

The code also checks queues and only returns message files to process if record build-ups are below a threshold value.

[Greg Eriksen]

Thank you both for the responses.

Michael,

I had thought about making the code in the ‘run’ mode conditional on being around the time of the advanced scheduling, but in times past I have run into problems with using a time window like that.  What happens when you have scheduled/unscheduled down time which precludes the normal processing, and now you can’t force a run outside the time window without modifying the code.  But this will probably be my plan “B” if there’s some unresolvable problem with the current solution.

And, “nice emails”?, I’m not sure I understand the concept.

Richard,

Unless I’m misunderstanding you, I think we are talking about the same thing.  The proc I’ve been coding is used in the Inbound / TPS / Directory Parse (fileset_ibdirparse) to replace the default action.   And yes, if the file exists and I don’t have to send out any nasty emails, then I modify the content of the proc’s continued message to only contain the name of the file I want to be processed.  Otherwise, I’d have problems with the names of some hidden files (start with a dot “.”) and a subdirectory that are also in that inbound directory.

All,

The main problem I can see with my solution is that it is really just a fix for what I consider to be a bug with the ‘run’ mode getting executed at startup even though advanced scheduling is enabled.  If Cloverleaf ever comes to agree with this viewpoint and changes the startup behavior, then my code will stop working until I remove the fix.

[Author]

Replies