CL Escape Messages handling not using Genie

[SDeanD]

Our application is extremely heavy in SNDRCVF for prompts and Escape messages that require a reply.

We are shooting for an RPPG OA conversion that does not run any screen scrapping (genie) .

we have developed a Generic .NET framework for Menu and execution. Works well. Atrium was not a good fit.

I have a solution for the SNDRECV. Create small RPG OA programs with PARMS. IN/OUT

Do you have a suggestion for handling the escape messages? we get a PUI window now. Can I customize this and return back to the application?

thoughts?

thanks, Dean

[Scott Klement]

I've not heard of *ESCAPE messages that require a reply. Do you mean *INQ messages?

As far as *ESCAPE messages go, these are used to indicate that a routine ended abnormally (i.e., "crashed"). They are sent up the call stack, level-by-level looking for a routine that monitors for them... if nothing monitors them, or if they hit a control boundary, the operating system takes over and sends a function check to the operator. In a 5250 program, this function check is displayed interactively for them to work with, but in a batch program (which is, technically, what your PUI rich display files are when they are outside of Genie) the OS sends this function check to QSYSOPR.

It does not, to the best of my knowledge, ever prompt the user for a response to an *ESCAPE message. (Though, the function check error will do so.)

If you wanted to handle *ESCAPE messages yourself, this would be pretty easy to do. Just write an RPG program that calls your converted program (or all programs?) in a MONITOR block. When an error is received, catch the error and display info on the screen, etc. Should be a relatively simple program.

However, if you want to let the user reply, then you aren't really dealing with *ESCAPE messages, but rather things like *INQ messages. In that case, your program to handle all of this would be somewhat more complicated...

Ultimately, the best solution is to have your programs catch and handle all errors so you don't need to ever rely on what the OS does when it crashes!

[SDeanD]

Scott,

Sorry for misclassifying the message type. See Code Below:

Code: Select all

/* Day Close Checks prior to Execution.              */                         
/*  1- Make sure order file is not in use.           */                         
/*  If in use, user can retry or cancel the request. */                         
                                                                                
 CHKORH:     ALCOBJ     OBJ((ORORHD *FILE *EXCL)) WAIT(0)                       
             MONMSG     MSGID(CPF1002) EXEC(DO)                                 
             RMVMSG     PGMQ(*EXT) CLEAR(*ALL)                                  
             SNDUSRMSG  MSGID(USR8004) MSGF(AFSMSG) MSGDTA(ORDER) +             
                          VALUES(C R) DFT(R) MSGRPY(&REPLY)                     
             IF         COND(&REPLY *EQ 'R') THEN(GOTO CMDLBL(CHKORH))          
             GOTO       CMDLBL(@EXIT@)                                          
             ENDDO                                                              

This Type of message bombs the PUI session. I guess I could write an RPG to replace SNDUSRMSG with the 2 parms and pass back the &reply

[Scott Klement]

True, the way PUI works right now is that it looks for any job at MSGW status, and when it finds that, it ends the session and shows the user the error about it ending. The SNDUSRMSG command sends *INQ messages, which will indeed cause the MSGW condition, and bomb the session.

Probably the best thing to do is (as you said) create an RPG program that accepts parameters like SNDUSRMSG does and have it bring up the message on a rich display file and show the message to the user and get the reply, etc.

It it were me, I'd write a new command, maybe named SNDPUIMSG. And I'd have it take all of the same parameters as SNDUSRMSG (or at least all of the ones that your organization uses from SNDUSRMSG). This command would run the RPG progam that brings up the rich display. That way, you could simply search/replace your existing SNDUSRMSG commands, changing them to SNDPUIMSG as a quick way to update your code.

Would that work for you?

[SDeanD]

Scott,

I did wrap my execution in a monitor, But it is executing via qcmdexec. ??

Code: Select all

/     monitor ;                                        
     WSCMD = %trim(pcmd) ;                          
     WsCmdlen = %len(%trimr(wscmd));                
     callP(e)  QCMDEXC(Wscmd : WsCmdLen);           
   on-error *all  ;                                 
   //  Error Check # 5 Invalid Program Call          
     wserrmsg = aq_get_brief('FMS' : 0005) ;        
     Eval wserrmsg = 'FMS0005 ' + wserrmsg ;        
//TODO:  add error call handler                    
   endmon ;                                             

I still get this:

Error image

Capture.PNG (112.77 KiB) Viewed 819 times

[Scott Klement]

The MONITOR thing was based on the concept that these are *ESCAPE messages -- so please disregard my first response. Your more recent message points out that you are using SNDUSRMSG (which is not capable of sending *ESCAPE messages) so MONITOR will not help you here.

Instead, I suggest creating a new command (maybe called SNDPUIMSG) to replace your SNDUSRMSG. This command would not use MONITOR, it'd just accept parameters for the message to display, the valid replies, etc, just like SNDUSRMSG does, but instad of using operating system messages, it'd just display a rich display screen to prompt the user. This is what I was describing in my most recent response.

Hope that helps clarify

[SDeanD]

Thanks. I am on Board with that. SNDPUIMSG Command. I kind of was starting to heading that way. thanks for the guidance.

back to the MSGW and trigger the Response from PUI. can I trap that instead? I already have a monitor block around my command. but it does not capture it.

Thanks for your thoughts. trying to stop the program from bombing when it is a record lock or something. I know I can recode for it. But, we have hundreds of programs.

You may be familiar with our software, FMS Software by Accutech. we acquired them 8 years ago and are supporting the clients and software. it is specific to the Food Distribution Industry.

thanks,
Dean