Keep Your Users Informed

April 28, 2004 Hey, Ted

Although we run an ERP package, we have plenty of homegrown programs that fill holes in the package. Most of them produce reports that the package doesn’t offer us. Sometimes a user keys runtime information into a prompt screen and presses a function key to submit a request to batch. However, if the results don’t come off the printer PDQ, the user may submit another request, thinking the first one was not accepted. How can we inform the user that the request was received?

–George

Your problem reminds me of something I’ve noticed: that homegrown software often does a poor job of keeping the user informed. I have received calls from users whose terminals had apparently “locked up.” The problem often turned out to be a long-running interactive program. The screen was blank, and there were no messages to tell the user what was going on.

Fortunately, yours is a very easy problem to fix, George.

Whenever you code a Submit Job (SBMJOB) command in a prompting program, make it a habit to follow SBMJOB with the Send Program Message (SNDPGMMSG) command, which informs the user that the job has been submitted to batch. The easiest way to accomplish this is to send a generic-type completion message.

SNDPGMMSG  MSG('Job was submitted for processing.') +
             MSGTYPE(*COMP)

That should be easy enough. You might enhance the message by including values that the user just keyed into the prompt screen.

SNDPGMMSG  MSG('Report for customer' *BCAT &CUSNO *BCAT + 
              'was submitted for processing.') +           
              MSGTYPE(*COMP)

Including keyed values helps the user who is submitting multiple requests, perhaps taken from a list on paper.

Another approach is to trap the message that OS/400 sends to the submitting program and send it to the caller.

DCL        VAR(&MSGID) TYPE(*CHAR) LEN(7)                
DCL        VAR(&MSGDTA) TYPE(*CHAR) LEN(80)              

SBMJOB     CMD(DSPLIBL) JOB(TED)                         
RCVMSG     MSGTYPE(*COMP) MSGDTA(&MSGDTA) MSGID(&MSGID)  
IF         COND(&MSGID *EQ CPC1221) THEN(DO)             
SNDPGMMSG  MSGID(CPC1221) MSGF(QCPFMSG) MSGDTA(&MSGDTA) +
             MSGTYPE(*COMP)                              
ENDDO

The user will see a message like the following one at the bottom of his menu.

Job 024488/AUSER/AJOB submitted to job queue QBATCH1 in library QGPL.

Before you implement any of these ideas, first take a look at the ERP package. Packaged software, unlike much of the homegrown stuff I’ve seen, is usually built upon a strong architecture. That is, there are certain ways that things are done. How does your ERP package inform the user that a job has been submitted to batch? I suggest you use the same approach, if possible. I like consistency, mainly because I (as well as users) hate inconsistency. Even if you don’t like the way the ERP package does something, it would help the users to make your homegrown stuff work the way the ERP package does.

–Ted