Run a TACL Maco as a named process

[rip uno]

I have a set of interacting tacl macros that run, querying the spooler for specific jobs and when found, list them out to an edit file, perform some editing functions on them and then ftp them down to the network so they can be emailed out to customers. I have this set up in Netbatch to start up and stop on a set timetable. The process logs to a physical file - not to the spooler as it has a lot of overhead crap and the spooler job tends to fill up too fast.

What I want to do is run the process NAMED but can't see to figure a way to do this when the output is to a physical file and not to the spooler. Any ideas? Netbatch IN file is $DATA06.PRODOPR.MAILPIKO which has the contents RUN $DATA06.PRODOPR.MAILPICK. MAILPICK is a MACRO which scans the spooler for specific jobs. When it finds them, it passes them off to two other macros to perform maintenance functions and FTP the results down to the network.

I want to be able to set up a process to watch for the named process to ensure it is running and not have to keep looking myself but can't figure a way to get this to "RUN NAMED."

[Doug Miller]

rip uno <rip...@gmail.com> wrote in news:2f4876a7-78d5-41eb-a2a6-5d8efdaa2f36
@googlegroups.com:

A TACL macro cannot run as a named process, no matter what you do, because it isn't a
process.

However, the first TACL can start a second TACL as a named process, and feed it the
command RUN $DATA06.PRODOPR.MAILPICK.

[Keith Dick]

I'm not sure why the kind of output file affects the problem. Is there something missing from the description of the situation?

I believe what Doug says is right. You probably have to create another Edit file, say $DATA06.PRODOPR.MAILPIKP, which contains the line:

TACL/NAME <whatever>,IN $DATA06.PRODOPR.MAILPIKO,OUT <whatever>/

Use MAILPIKP as the IN file for the Netbatch job. I think you must not use NOWAIT with that TACL command because I seem to recall that when a Netbatch job finishes, any processes it started are killed at that time, so you want the Netbatch job that starts the named TACL not to terminate.

There might be another way. You might be able to configure a TACL that runs your macros as a persistent process managed by Guardian. Guardian will start the process automatically and will restart it if it ever goes away. Look at the description of "generic process" in "SCF Reference Manual for the Kernel Subsystem" to see how this might be done. There might be some reason that a generic process is not right for this situation, but I think it is worth considering. Then you would not have to do any monitoring of the process yourself.

[Doug Miller]

Keith Dick <kd...@acm.org> wrote in
news:qYednWaZI7Va0H_S...@giganews.com:

> Doug Miller wrote:
>> A TACL macro cannot run as a named process, no matter what you
>> do, because it isn't a process.
>>
>> However, the first TACL can start a second TACL as a named
>> process, and feed it the command RUN $DATA06.PRODOPR.MAILPICK.
>>
> I'm not sure why the kind of output file affects the problem.
> Is there something missing from the description of the
> situation?
>
> I believe what Doug says is right. You probably have to create
> another Edit file, say $DATA06.PRODOPR.MAILPIKP, which contains
> the line:
>
> TACL/NAME <whatever>,IN $DATA06.PRODOPR.MAILPIKO,OUT
> <whatever>/

Not at all what I had in mind, Keith, and probably not quite what
the OP wants, either.

More like:

#PUSH commands
TACL /NAME <whatever>, INV commands DYNAMIC, OUT <whatever>/
#APPEND commands RUN $DATA06.PRODOPR.MAILPICK

> Use MAILPIKP as the IN file for the Netbatch job. I think you
> must not use NOWAIT with that TACL command because I seem to
> recall that when a Netbatch job finishes, any processes it
> started are killed at that time, so you want the Netbatch job
> that starts the named TACL not to terminate.

Specify (IIRC) the "JOBID 0" parameter in the configuration of the
Netbatch job, and processes spawned by that job continue to run
after the job terminates.

[Keith Dick]

Doug Miller wrote:
> Keith Dick <kd...@acm.org> wrote in
> news:qYednWaZI7Va0H_S...@giganews.com:
>
>
>>Doug Miller wrote:
>>
>>>A TACL macro cannot run as a named process, no matter what you
>>>do, because it isn't a process.
>>>
>>>However, the first TACL can start a second TACL as a named
>>>process, and feed it the command RUN $DATA06.PRODOPR.MAILPICK.
>>>
>>
>>I'm not sure why the kind of output file affects the problem.
>>Is there something missing from the description of the
>>situation?
>>
>>I believe what Doug says is right. You probably have to create
>>another Edit file, say $DATA06.PRODOPR.MAILPIKP, which contains
>>the line:
>>
>> TACL/NAME <whatever>,IN $DATA06.PRODOPR.MAILPIKO,OUT
>> <whatever>/
>
>
> Not at all what I had in mind, Keith, and probably not quite what
> the OP wants, either.
>
> More like:
>
> #PUSH commands
> TACL /NAME <whatever>, INV commands DYNAMIC, OUT <whatever>/
> #APPEND commands RUN $DATA06.PRODOPR.MAILPICK
>

Yes, I thought you had something like that in mind. That might work, but I have a very dim recollection that there is something that does not work right about trying to use INV to send commands to a TACL process. Maybe that recollection is wrong, maybe it was a bug I ran into that has been fixed. Except for the extra Edit file in what I suggested, I think that if they both work, they are equivalent. They both use one additional TACL process.

>
>
>>Use MAILPIKP as the IN file for the Netbatch job. I think you
>>must not use NOWAIT with that TACL command because I seem to
>>recall that when a Netbatch job finishes, any processes it
>>started are killed at that time, so you want the Netbatch job
>>that starts the named TACL not to terminate.
>
>
> Specify (IIRC) the "JOBID 0" parameter in the configuration of the
> Netbatch job, and processes spawned by that job continue to run
> after the job terminates.

That sounds familiar, but seems a lot easier to be forgotten than making sure the command file for the job runs the second TACL waited. Either probably works fine.

[wbreidbach]

As far as I understood this is a batchjob running "forever". If this is true you should create a persistent process instead. Configured correctly the persistence manager would take care of that process and if it dies, it would be restarted automatically.

[rip uno]

I tried this method using the "OUT $NULL and then OUT $S.#TEST.PRNT" and it ran for about a minute and died showing it was having problems with all the TACL commands in the MAILPICK macro. I seemed like it didn't want me to have any TACL inside the TACL Macro I was running.

As for the persistent process, That wouldn't work as this is set up to run during the day then shut down at night for cleanup. We save off the log file, move the days emails over into a saved folder and clear out the normal location so it is fresh for the next day, clear out the log file and then restart the process again an hour later so it will run for the next day.

I hope I am not clouding this issues more than necessary.

[rip uno]

Using this scenario, would this be an intermediate file between my MAILPIKO which is called from NETBATCH (my understanding is I can only call OBEY file or executables)? MAILPIKO would then RUN this macro and if I wanted to use netbatch scheduler to stop the process at a given time I would have an obey file to STOP PROCESS_NAME instead of STOP JOB. I could then set up another process to monitor for the PROCESS-NAME and notify me if it is not running.

[Keith Dick]

It probably would help to know what error messages you got that indicate to you it was having problems with all the TACL commands. The kind of problems it was complaining about might be a useful clue.

I can think of two things to check.

One is that maybe your MAILPICK macro depends on some local macros that normally get loaded automatically at logon and this is not happening with the second TACL process. If that is the problem, change the commands sent to the second TACL process to load those macros before running MAILPICK.

The other thing to check is whether the problems with all of the TACL commands have something in common, and how does that something differ from the usual environment when running the usual way in Netbatch. Here, seeing the error messages, and the commands they refer to, would help us understand the problem if you don't figure it out yourself. I think I remember that there is something unusual about the normal Netbatch environment, but I don't remember what. Might be a false memory of mine.

[Keith Dick]

I don't completely understand your question, especially the first part.

I think you have the second part right: If you get this working, you could monitor the process name you are using to know whether your macro is still running. If you use JOBID 0, stopping the Netbatch job will not stop processes started from within that Netbatch job, so you would have to stop that second TACL explicitly when you wanted to get rid of it.

It occurs to me that it might be easier to leave your job the way it is and set up something to watch that the job continues to run in Netbatch. You can give jobs some sort of stable ID, can't you? If so, it probably would not be much more difficult to write some code to use the Netbatch commands to check whether that job is still running than it would be to check that a particular process name is still running. (A little harder but probably not much harder.) Just another approach to consider if this approach becomes too complicated or reaches a dead end.

[wbreidbach]

I still think the persistent process is a pretty good option, you define the process with "startmode manual" as let's say $ZZKRN.#MYPROCESS. at the end of the day youissue a command SCF ABORT PROCESS $ZZKRN.#MYPROCESS and in the morning the start-command. The input-file for that TACL should be the obey-file, not the macro.
In my eyes using NetBatch is not a real good solution as NetBatch is intended for batchjobs which are ending normally and not for processes like this which are running as long as they are not stopped. I guess that the status of the NetBatch job would not be "ok" afterwards.
We are using another procedure for processes like this one:
We monitor the existence of configured processes and if one of those processes does not run we do an automatic restart if this is configured and not disabled.
We have a similar case:
in the morning: enable restart for process $ABC -> process is started if it does not exist
in the evening: disable restart for process $ABC, stop process $ABC -> the missing process will be found with a message "restart disabled".

[Doug Miller]

rip uno <rip...@gmail.com> wrote in

news:4ef6c67b-15e2-4438...@googlegroups.com:

I thought you were launching a TACL process from Netbatch. Sorry if I misunderstood.

> (my understanding is I
> can only call OBEY file or executables)?

You can launch *only* an executable from Netbatch. When you're invoking an OBEY file,
you launch TACL as the executable, with the OBEY file as its input.

> MAILPIKO would then
> RUN this macro and if I wanted to use netbatch scheduler to stop
> the process at a given time I would have an obey file to STOP
> PROCESS_NAME instead of STOP JOB. I could then set up another
> process to monitor for the PROCESS-NAME and notify me if it is
> not running.

Right.

[Doug Miller]

rip uno <rip...@gmail.com> wrote in

news:f7031548-deae-45ca...@googlegroups.com:

> I tried this method using the "OUT $NULL and then OUT
> $S.#TEST.PRNT" and it ran for about a minute and died showing it
> was having problems with all the TACL commands in the MAILPICK
> macro. I seemed like it didn't want me to have any TACL inside
> the TACL Macro I was running.

Using a TACL macro as an INfile doesn't work very well. You need to RUN it.

[rip uno]

This sounds like it would solve the issue, but SCF is real close to a black hole to me. I will read the SCF manual for Kernel processing and see if I can figure this out enough to give this a shot. I agree that using batchcom in the manner I am doing is probably not the correct path we should take.

[wbreidbach]

It is pretty easy to define a persistent process, your program is TACL and so there is no need for ASSIGNS, PARAMS or DEFINES which would make it somewhat complicated. Here a very simple example:

ADD PROCESS $ZZKRN.mypocess , &
AUTORESTART 1 , &
CPU FIRST , &
DEFAULTVOL <subvol> , &
HIGHPIN ON , &
INFILE <name of obey-file> , &
OUTFILE <name of output-file> , &
NAME <process-name> , &
PRIORITY $mypro , &
PROGRAM $SYSTEM.SYSTEM.TACL , &
STARTMODE MANUAL

you can stop it with abort process $zzkrn.myprocess and start again with start process $zzkrn.myprocess
The big advantage: If the process stops unexpectedly or is stopped errobneously the persistence manager will notice and restart the process.

[rip uno]

> , &
> PRIORITY $mypro , &
> PROGRAM $SYSTEM.SYSTEM.TACL , &
> STARTMODE MANUAL
>
> you can stop it with abort process $zzkrn.myprocess and start again with start process $zzkrn.myprocess
> The big advantage: If the process stops unexpectedly or is stopped errobneously the persistence manager will notice and restart the process.

Thanks - I have been trying a few variations of the other recommendations with varying results. I will also give this a shot and see which option gives the best results. This sounds like it will do what I am looking for without me having to write another process to monitor my email application.

[rip uno]

The persistent process seems to be working the cleanest and easiest to monitor, start and stop so I think I am going to incorporate this into our situation and run with it for a while.

Thanks to all for your knowledge and assistance.