A Better Way to Display Quick 5250 Messages in RPG

Note: The code accompanying this article is available for download here.

Here are a couple of code snippets containing a call to the QUILNGTX API that does a much better job than the DSPLY opcode. This API has been around for a long time (before/free), and we wrapped it into a service program procedure to make it easier to use.

As you can see from the included code sample, it only takes a character work variable to contain the text to display, and a call to the ShowText subprocedure to display a message. It shows a pop-up box with text wrapping that is displayed on screen. There are no input capable fields, and no control over window positioning; but for a quick and dirty display to the user it works fairly well.

We are not using the full functionality of this API, as you could also integrate message files into the popup, but due to the positioning limitations we only use it for temporary or debugging messages.

Finally, there is no error handling in this procedure, but using the fields in the ERRCODE data structure you could implement some if you wished.

–Dave

Dave, well knock me down and call me “shorty.” The QUILNGTX API has been around since V3R6, and I hadn’t heard of it or used it. When wrapped in an easily accessible subprocedure like the one you provided, it sure does beat using the DSPLY opcode. (I must admit, over the years I’ve left a DSPLY or two in production RPG programs when project deadlines were looming.)

I took Dave’s code, modified it using /FREE form syntax, and created a small sample program. You can download it here. The revised subprocedure accepts three parameters:

1. Message text to display to the user. This is a varying-length field, so make sure you use %TRIMR if the source of the message is a fixed-length field.
2. Message ID. Optional.
3. Qualified Message File Optional. When the message ID and message file are passed, the message text from the specified message ID is placed by the API in the window’s title line. I would have preferred IBM just let the user specify a title as a separate parameter. If a title isn’t required (or you don’t want to bother defining a title in a message file), then these last two parameters can just be left blank.

Shown below is a picture of the output window for 80 column output. The Window position (row 5 col 2), height (12 lines total) and exit key (F12) are fixed.

Here is the RPG code that invoked the procedure:

/Free
    ShowText('This is an API test.  The amount of text that can +
    be displayed is nothing short of incredible.  The quick +
    brown fox jumped over the lazy dog.  With an API like this +
    available, we shouldn''t need to use the DSPLY opcode any +
    longer.  It reduces the need for coding DDS WINDOW formats +
    and will make life a bed of roses.  It even does an +
    automatic word wrap.  What will they think of next?  123456+
    789012345678901234567890123456789012345678901234597890':
    'SQL0101':'QSQLMSG');
    *InLR=*On;
/End-Free

Just to demonstrate the title feature, I passed message ID SQL0101 (SQL Statement too long or complex) from message file QSQLMSG. If a title isn’t required, just leave these two parameters blank.

As Dave points out, when showing quick and dirty messages to the user or when debugging, this is a great way to show a classy message without any extra DDS hassle. Further, it doesn’t suffer the 52-character message limitation imposed by DSPLY. However, the one thing that the DSPLY opcode can still do is retrieve a response from the user.

–Mike

Michael Sansoterra is a DBA for Broadway Systems in Grand Rapids, Michigan. Send your questions or comments for Mike via the IT Jungle Contact page.

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot