Message Waits in Subsystem

[devinst]

When a user gets an error on a web page they close that page and bring the program back up. This, however, does not end the job in the subsystem qhttpsvr. That job remains at a message wait status. This becomes and issue when the job has any record locks. Since the user has closed the page and moved on the program errors do not always get reported. Sometimes it is not until other jobs have a problem retrieving the locked record before it is brought to the attention of IT. Is there any option to have the jobs end after a certain amount of time in the config file? If not, can anyone share how they are handling the issue? I know I can write a program to check the subsystem for message waits but was hoping to have it handled with an option. Thanks.!!!

[Scott Klement]

My approach has always been to have a global monitor that catches all errors. This way your program never goes to MSGW, instead it catches all of it's errors. I usually dump the job log when this happens, and send a message to whomever is in charge of supporting the program. That way, whomever is in charge will always know when an error occurs, and can look at the job log for details. Hopefully they can fix the error so it won't keep happening.

This approach is extremely easy to implement.

[devinst]

I like that idea Scott. That way we retain what caused the error and still allow the system to move on. My only question is you mentioned a global monitor. Is this something you put into each program as a standard coding practice?

[Scott Klement]

Correct, I put this in each program as part of my standard way of coding.

[devinst]

Great.!! Would it be possible to get a sample of the code?

[Scott Klement]

There's really not a lot to the code... You know how an RPG program has "main calcs"? (the C-specs or /FREE specs that are called when the program is called...) I just put all of those into a subroutine called 'DoMain', and then call that subroutine from within a MONITOR group. Something like this:

Code: Select all

     D ErrHandle       PR                  ExtPgm('ERRHANDLE')
      /free
        monitor;
          exsr DoMain;
        on-error;
          ErrHandle();
        endmon;
        *inlr = *on;

So not really a lot to it... because everything is inside the DoMain subroutine (or something that DoMain calls) it will handle all errors that occur in the program. When an error occurs, I'm calling a separate program named ERRHANDLE that will dump the job log and send me a message. If you have e-mail set up on the IBM i, you could even e-mail the job log to whomever is in charge of supporting these programs by doing something like this:

Code: Select all

PGM

    MONMSG MSGID(CPF0000 MCH0000) EXEC(GOTO IGNORE)


   /* DUMP THE JOB LOG TO A PDF FILE */

    OVRPRTF FILE(QPJOBLOG) +
            WSCST(*PDF) +
            DEVTYPE(*AFPDS) +
            TOSTMF('/QDLS/TEMP/JOBLOG.PDF') +
            OVRSCOPE(*JOB)
    DSPJOBLOG OUTPUT(*PRINT)
    DLTOVR FILE(QPJOBLOG) LVL(*JOB)


   /* E-MAIL IT TO SCOTT */

    SNDDST TYPE(*DOC) DOC(JOBLOG.PDF) FLR(TEMP) +
           DSTD('Error Report') +
           TOINTNET((sklement@xxxxxxxxxx.com *PRI))


   /* DELETE THE PDF FROM THE IFS */

    RMVLNK OBJLNK('/QDLS/TEMP/JOBLOG.PDF')

IGNORE:
ENDPGM 

That''s not the best example, because I personally don't like to use SNDDST -- I would prefer to use a better e-mail client. But, since I'm not familiar with your setup, I'm just using SNDDST because it comes with the OS. In shops where you can't e-mail, you could just do a SNDMSG to send the responsible user/person a message instead of using e-mail, and just leave the job log in the spool. Lots of different possibilities.

I also know people who like to use DUMP(A) in the RPG code to create a dump of the program as well. Personally, I don't use/like dumps -- but maybe you do.

So there's lots of possibilities -- but hopefully this will get you started.

Also, I should point out that this isn't really a Profound UI issue. This could happen with any RPG program (or CL, or Cobol, etc...) on IBM i... it doesn't have anything directly to do with our displays. In fact, I primarily used this before I worked at Profound... it was used in green-screen programs, batch jobs, CGIDEV2 programs, etc. So it will work fine with Profound UI, but it's really a general solution to RPG error handling.

[devinst]

If there is one thing I have learned from my 25 years of RPG coding, it is that some of the best solutions are the simple ones!!
I love this idea. Most of my code is broken out into sub routines already but I never thought about using a monitor statement around an exsr. If fact, if I had, I probably would have thought it wouldn't work. I could see around calling an sub procedure since it is a call but not an exsr. I have definitely learned something new today and will use it often.

There rest of your explanation, including the 'main clacs' makes perfect sense also. And I do agree with you on the SNDDST too.

Once again, thanks for all your help Scott. What I have learned from using some of your shared code has been priceless.!!