Sending messages (even those that require a response) to a message queue from an RPG/400 program is simple with the DSPLY operation. Information messages, field values, and reply messages can be sent to the message queue with this operation.
For example: A batch job extracts certain records from a file based on a selection criteria. If a certain number of records is not extracted, the job is aborted. By using the DSPLY operation, one simple statement can notify the user through his/her message queue that the job has been aborted.
Here is the basic format of the statement (the compile time array ARM is used to accomplish easy message text set-up):
C ARM,1 DSPLYUSERMQ ** Extract Job Aborted
Factor 1 contains the field name, literal, table name, or array element whose value is to be displayed.
Factor 2 contains the name of the message queue to which the message will be sent. If the job is batch and factor 2 is not specified, QSYSOPR becomes the default queue. If the job is interactive and factor 2 is not specified, *EXT becomes the default queue.
Result field contains the field that is to accept the response (shown in a later example).
You can display messages from a message file. This statement will display user message USR0001 from message file QUSERMSG:
C *MUSR0001 DSPLY
The message identifier must be preceded by *M to indicate that this is a message.
The most powerful way in which to use the operation is to display a message and request a response. For example, you may want to give the operator the option to continue a batch job. The following statement will send the question, "Do you want to continue? (Y/N)" to the QSYSOPR message queue and the program will wait until a response is given.
C ARM,1 DSPLY RESP **
Do you want to continue? (Y N)
There are some restrictions:
You can DSPLY to any message queue except a program message queue.
The maximum length of information that can be displayed is 52.
For more information about the DSPLY operation refer to the RPG/400 Reference manual (SC09-1089).
Midrange Computing
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online