• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 475
  • Last Modified:

Messages by the application on the screen at botton line.

i m making a small program in RPG n i want to give some messages at the bottom line of the display
can u tell me what are the ways in which i can do this and please give some explanatory example based on each one of that since i m new to this tech.
1 Solution

I'm not sure you've given enough information. There are different ways depending on the environment.

Does the RPG program have a display file that it's doing I/O against? If so, does the display file define a message line? Does it define a message subfile? If no display file, what will be on the screen when the program is called? Will it be a system display or will it be called from another program? If called from another program, what does that program do with display files? Or is everything done with UIM panel groups or DSM APIs? (Or is it an EPM environment?)

When you send the message out, do you want it to show immediately? Do you want it to remain on the screen after the program ends or is it temporary?

Okay, simple start... You can send *STATUS messages to the the *EXT program message queue. This can be done with a SNDPGMMSG CL command or by calling the Send Program Message (QMHSNDPM) API. The SNDPGMMSG command can be in a small CL program that can be called by your RPG program; just pass in the message data you want to send. It'd be better in the long run if you learned the API, but the CL is an easy start.

Maybe that's all you need to know. It generally works for many circumstances.


mayankgangradeAuthor Commented:
i m using a display file with RPG n i have not defined any message lines in the display file since i don't know how to do that. can we do it without calling a  CL program ?

With the record-level keyword RTNCSRLOC(&RCD &FLD &POS), you can get info about the cursor location when the user presses <Enter>. With the record-level keyword CSRLOC(LINNBR POSNBR), you can set the position where the cursor should be on an output operation.

However, when the user presses <Enter>, the cursor might not be in the field that you want to position the cursor in. The user might have typed into FLD1, <Tab> to Fld2, typed in FLD2, then moved back to FLD1 to correct a character. When <Enter> is pressed, the display file will report that the cursor is in FLD1.

You still need to track which fields had data entered into them. Your program logic will need to decide what to do next. The CSRLOC() keyword can be used on output if you don't want to use indicators for DSPATR(PC), but you'll need to keep track of the actual locations of your display fields.


Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

Whoa, my apologies... I typed that previous item into the wrong window... Please ignore it.


Okay, correct window this time (I think).

Even though you haven't specified a message-line, one was automatically assigned. One problem is that different display emulators can handle message-lines in different ways. I suppose most developers prefer to take control by adding a "message subfile" to their display file. It looks something like:

     A          R @MSESFL                   SFL
     A                                      SFLMSGRCD(24)
     A            @MSMKY                    SFLMSGKEY
     A            @MSPGQ                    SFLPGMQ
     A          R @MSESFLC                  SFLCTL(@MSESFL)
     A                                      SFLSIZ(0002)
     A                                      SFLPAG(0001)
     A                                      OVERLAY
     A  88                                  SFLEND
     A  88                                  SFLDSP
     A  88                                  SFLINZ
     A  92                                  SFLDLT
     A            @MSPGQ                    SFLPGMQ

That defines a single-line subfile on line 24 of the display. Because SFLSIZ>SFLPAG, it can hold up to 9999 messages and can be scrolled through.

This is essentially what you see on many system displays.

The @MSPGQ field usually can hold the name of the program that opened the display file; this is the program message queue where messages are taken from for the display. The @MSMKY field can hold a message key, but many programmers leave it alone.

The combination of keywords is often what's important rather than the content of those fields.

By specifying keywords SFLMSGRCD() and SFLINZ and executing an output operation for the subfile with indicator 88 on, the messages on the program's message queue are moved into the message subfile and displayed. So you send any messages you want displayed to the program's message queue and then tell the subfile to display them.

The message subfile gives you some direct control over how messages display in your own DSPFs. Under some circumstances, you have no DSPF or you need a generic solution -- that is the alternative where you'll most likely send a *STATUS message to the *EXT message queue (The 'external' message queue of the job). That message will generally display wherever the current message line is defined.

The best way is Tom's solution using message subfiles - this gives the programm the most flexability and requires only 1 error indicator per field on the screen.
One thing to has not posted is how to get the message onto the screen.
If you are using RPG and not RPGLE the easiest way is via a CL and a message file (CRTMSGF and WRKMSGD to create and manage the message file)
The following CL is one I use to use (it may not be the best)

Pass the mesasge ID and Message file - a blank message removes all messages.

PGM  PARM(&MSGID &MSGF)                                
DCL        VAR(&MSGID) TYPE(*CHAR) LEN(7)              
DCL        VAR(&MSGF) TYPE(*CHAR) LEN(10)              
IF         COND(&MSGID *NE '       ') THEN(DO)          
SNDPGMMSG  MSGID(&MSGID) MSGF(&MSGF)                    
MONMSG CPF0000                                          
ELSE       CMD(DO)                                      
RMVMSG     PGMQ(*PRV) CLEAR(*ALL)                      


An easier way to display a mesage - I do not like this method but it is easy.
*in60, when on, will show msg001 in msgfile MYMSGF and switch off *in60
*IN61, when on, will  show the text and turn off *in61
*in62, when on,  will display the contents of field MTXT and switch off *in62 (MTXT is set in the RPG)

A            ORDNDS    R        B  3 18REFFLD(ORDN)                        
A  60                                  ERRMSGID(MSG0001 MYMSGF  60)      
A  61                                  ERRMSG('Order number outside range' 61)
A  62                                  ERRMSGID(CPF9898 QCPFMSG 62 &MTXT)

A            MTXT          78   P      

another method is the old s/36 way - this is quite flexible but will only show 1 message at a time but has the advantage of not locking the screen and again only requires 1 error indicator per screen field.

A            MSGID          7A  H                                      
A            MSG           78A  O 24  2MSGID(&MSGID MYMSGF)          
A                                      DSPATR(HI)                      

There are probably many more ways.

I wold go via the message subfile way - it may take a bit longer to master but it is well worth the effort (you can also access the second level help as per as/400 messages).

MurpheyApplication ConsultantCommented:
hi mayankgangrade,

Most of the given samples are only working for interactive programs.
If you like to do it also for batch programs, stick to the sample of Dave,
or just send an e-Mail in stead of a Message by the SNDDST command.

Have fun

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now