monitor, on-error and service program woes

[soup_dog]

Hi everyone! It's been a while since I had a question to post, but I just ran into something interesting.

I have a service program that I use to run CL commands from within RPG.

In this case, I am using the service program to set up a work file.

MONITOR;
runCommand('CLRPFM WORKFILE');
ON-ERROR;
runCommand('CRTPF WORKFILE');
ENDMON;

The error monitor catches when the workfile hasn't been created yet, and creates it. In subsequent calls, the file is cleared.


As time has gone on, sometimes users would get kicked out with an error message saying the system was trying to reference an object that no longer existed. The suggestions I found online were to make the activation group for the service program a NAMED activation group instead of *CALLER.

So I did that. NOW, the error monitor does not work. The first command fails and it falls into the on-error routine like normal. As soon as the second runCOmmand is attempted, though, I get a machine check saying it can't find the runCOmmand routine.

By checking the activation group it appears that the MONITOR/ON-ERROR routine is closing down the activation group. I am looking for confirmation on that theory. Does the MONITOR command reclaim resources when it goes into the error portion?

Thanks in advance!

Jim

[tomliotta]

Re: monitor, on-error and service program woes

As time has gone on, sometimes users would get kicked out with an error message saying the system was trying to reference an object that no longer existed. ...

... So I did that. NOW, the error monitor does not work. The first command fails and it falls into the on-error routine like normal. As soon as the second runCOmmand is attempted, though, I get a machine check saying it can't find the runCOmmand routine.

Are you saying that it's now showing essentially the same behavior as it was before the change? There are some differences in how you describe the before and after, but the actual error message IDs aren't shown; so it's not clear exactly what was and is happening.

By changing the activation group, those error descriptions might indicate pretty much the same things. Hard to make good sense without seeing the actual errors for guides.

[B.Hauser]

Re: monitor, on-error and service program woes

Is there a RCLRSC or RCLACTGRP performed somewhere?

Birgitta

[soup_dog]

Re: monitor, on-error and service program woes

Nope, no RCLRSC. the runcommand procedure literally just calls QCMDEXEC.

When the service program uses the *CALLER activation group the following code works fine.

MONITOR;
runCommand('CLRPFM WORKFILE');
ON-ERROR;
runCommand('CRTPF WORKFILE');
ENDMON;

When the activation group is named, like CMDTOOLS, the code fails on the second runCommand. If you debug the job, when the first RunCommand is executing, you can see the activation group CMDTOOLS. As soon as it gets into the error trap, the activation group CMDTOOLS disappears. That why I was wondering if the AS400 system is doing a RCLRSC or something upon entering the error handler.

[Rocky]

Re: monitor, on-error and service program woes

Hi everyone! It's been a while since I had a question to post, but I just ran into something interesting.

I have a service program that I use to run CL commands from within RPG.

In this case, I am using the service program to set up a work file.

MONITOR;
runCommand('CLRPFM WORKFILE');
ON-ERROR;
runCommand('CRTPF WORKFILE');
ENDMON;

The error monitor catches when the workfile hasn't been created yet, and creates it. In subsequent calls, the file is cleared.


As time has gone on, sometimes users would get kicked out with an error message saying the system was trying to reference an object that no longer existed. The suggestions I found online were to make the activation group for the service program a NAMED activation group instead of *CALLER.

So I did that. NOW, the error monitor does not work. The first command fails and it falls into the on-error routine like normal. As soon as the second runCOmmand is attempted, though, I get a machine check saying it can't find the runCOmmand routine.

By checking the activation group it appears that the MONITOR/ON-ERROR routine is closing down the activation group. I am looking for confirmation on that theory. Does the MONITOR command reclaim resources when it goes into the error portion?

Thanks in advance!

Jim

I'm no expert in activation group - but in this scenario I would recommend *CALLER - the calling program in a named activation group but not the routines it calls - scoping causes all sorts of problems - which this is what the issue is.

[soup_dog]

Re: monitor, on-error and service program woes

I agree with you there. because of a completely seperate issue I was forced to change the *CALLER activation group to a named activation group. (pointer issues and deleted objects.)

[Scott Klement]

Re: monitor, on-error and service program woes

It kinda sounds like you aren't accounting for control boundaries, to me. But to be sure, I need you to answer the following questions.

Is the MONITOR group in the service program? Or is the MONITOR group in the caller, and the runCommand() routine is in the service program?

How are the exceptions percolated? Does runCommand() receive the error from QCMDEXC, and re-send it? Or does it just blow up and hope that the caller is monitoring for it?

[soup_dog]

Re: monitor, on-error and service program woes

It kinda sounds like you aren't accounting for control boundaries, to me. But to be sure, I need you to answer the following questions.

Is the MONITOR group in the service program? Or is the MONITOR group in the caller, and the runCommand() routine is in the service program?

How are the exceptions percolated? Does runCommand() receive the error from QCMDEXC, and re-send it? Or does it just blow up and hope that the caller is monitoring for it?

The monitor group is in the CALLING program. The service program contains just call to qcmdexec.

In the service program the call to QCMDEXEC just blows up and expects the calling routine to monitor for it. (Crap, I know. In my defense it was one of the first service programs I have ever written. LOL.)

[Scott Klement]

Re: monitor, on-error and service program woes

Yep, so the error makes perfect sense.

In ILE, when an exception message is sent, it will automatically look for an exception handler by checking up the program stack until it finds a control boundary. When it hits a control boundary, it will stop checking -- and if it hasn't found an exception handler, the exception will be sent as an unhandled exception.

A control boundary occurs in the first procedure/pgm in the call stack after the activation group changes.

So if your runCommand() procedure is in a service program that's in a different activation group from the caller -- using MONITOR in the caller won't work.

If you want more detail on this, see the "ILE Concepts" manual.

You can fix that by having runCommand() catch it's own errors, and then re-send them to the caller. This is very easy to do if you've ever done it before... I generally just copy the code from the last place I did this sort of thing. But, it can be difficult if you've never done it before... if you post the code for your runCommand() procedure, I'll see if I can demonstrate how to add that support.