Other examples (Scripting)

This section provides script editing examples.

Modify APPC script data – scenario 1

The following script uses the recommended method for modifying APPC script data — using the <REPLACE> tag inside the <OUTBOUND> section to replace <CMSEND> <CONTENT> data. <REPLACE> uses an offset method to indicate where to start replacing.

Script for Modifying Script Data Using the <REPLACE> Tag

Modify APPC script data – scenario 2

This is an alternative method of modifying APPC script data.

Alternative Method for Modifying APPC Script Data

To explain the code, we will look at individual pieces.

1. Retrieve the user data from the associated DETAIL member:
   parse source op_sys how_called scr_name rest
   address HSCMDS “ALLOC F(DETAILS) DA(USR2503.TSTEAM.DETAIL(“scr_name”)”,
   “SHR REUS”
   “EXECIO * DISKR DETAILS (STEM data_in.FINIS”
   address HSCMDS “FREE F(DETAILS)”
2. Determine which user <CONTENT> data record to modify using the attached LABEL and extract record type information:
   parse var data_in.2 len_type “00000002” rest
3. Retrieve new data from the MESSAGE file and use the replay PORT number (provided by Performance Test) to select the replacement record for this user:
   “EXECIO * DISKR MESSAGES (STEM msg_in.FINIS”
   out_data = msg_in.port
4. Build the replacement user <CONTENT> data record:
   data_in.2 = ‘OO’X||D2C(length(out_data)+12)||substr(len_type,3,2)||,
   “00000002”||out_data
5. Build member name for replacement DETAIL member that contains the replacement user <CONTENT> record, again using the PORT number for uniqueness:
   new_mem=”H3C1NW”||RIGHT(port,2,’0’)
6. Create new DETAIL member:
   address HSCMDS “ALLOC(F(“new_mem”) DA(USR2503.TSTEAM.DETAIL(“new_mem”)) OLD
   REUS”
   “EXECIO” data_in.0. “DISKW” new_mem “(STEM data_in. FINIS”
   address HSCMDS “FREE F(“new_mem”)”
7. Modify <DETAIL COMBINED=...> tag to point to the replacement DETAIL member:

Modify an MQ script to test the requester

This section provides an example that shows how to modify an MQ script to test the requesting application. In this example, the application flow is as follows:

1. The Customer Inquiry Program PUTs an inquiry to the request queue (PUT A).
2. The Customer Information Processing Program GETs the request (GET A) and processes the inquiry.
3. The processing program PUTs the response on the response queue (PUT B).
4. The inquiry programs GETs the response from the response queue (GET B) and presents it to the user.

MQ Script Application Flow

The inquiry program assigns a unique correlation ID to the request message (PUT A). The correlation ID remains intact all of the way through processing. When the inquiry program retrieves the response (GET B), it uses the correlation ID to match the response with the request.

In this example, the user interface for the inquiry program must be tested to ensure that it is displaying information correctly, yet the processing program is unavailable.

To test the inquiry program, the player must act as the processing program. That is, it must execute GET A and PUT B. To do this, the request queue must contain a request that the player can GET (GET A). Input inquiries after playback starts to populate the queue. However, the correlation ID from the new requests will not match the correlation ID that was initially recorded. To make this scenario work, the player must replace the recorded correlation ID with the new correlation ID.

Further, thorough testing requires displaying several customer records. Achieve this by replacing the customer information in the recorded response (PUT B) with information from an external file. Each time you submit an inquiry, playback GETs the request and returns a response generated from the records in the external file. Add logic that terminates playback if the GET is unsuccessful or after all of the records have been used.

Start with a script that contains the processing program’s activity, GET A and PUT B (see the below figures). Then add REXX logic to:

• Initialize a Count Variable
• Read Data from an External File
• Loop Until an Unsuccessful GET or Last Record is Encountered
• Process the MQ_PUT Message

Each of these sections explains the REXX logic required to achieve the example and indicates where in the script to add the logic. Each section presents the relevant portion of the script along with the additional logic in bold text. If you have trouble with context, compare the section with  the below figures. They show the script as it was recorded.

Page 1 of Script containing GET A and PUT B as Recorded

Page 2 of Script Containing GET A and PUT B as Recorded

Initialize a Count Variable

The looping logic in this example requires a count variable. At the beginning of the script, after the <VERSION> tag, initialize the variable.

Read Data from an External File

Reading data from the external file is the next required step. After variable initialization, before the connection is established, insert an EXECIO statement to read the records into a REXX stem variable, ‘reply_message’. This results in a series of reply_message.n variables, where n indicates the record number. Include a FINIS parameter to close the file after all of the records have been read.

Loop Until an unsuccessful GET or last record is encountered

Because the script contains only a single transaction, looping logic must be added to the script to execute the GET and process the response message the correct number of times. If the GET is unsuccessful or there are no more records to process, the loop must terminate. To do this:

1. Before the MQ_GET tag that retrieves the request, insert a DO statement to execute the MQ_GET until all records have been processed (DO i=1 TO replay_message.0). ‘reply_message.0’ represents the total number of records.
2. Add a WAIT parameter to the MQGMO_OPTIONS to avoid executing multiple MQ_GETS on an empty queue.
3. After the MQ_GET tag, insert an IF statement that checks the reason code to ensure that the GET is successful. Use the Performance Test for WebSphere MQ REXX variable ACTUAL_REASON to return the reason code. If the reason code equals zero, increment the count and set the length value (new_len) used for processing the response message to the length of the current record (reply_message.i).
4. After the MQ_PUT that delivers the response, insert an END statement that ends the current loop and returns to the beginning of the DO loop, providing the IF statement condition is met. That is, the MQ_GET is successful.
5. After the END statement, insert an ELSE statement that terminates the loop if the MQ_GET is unsuccessful. To terminate the loop, set the value of i to ‘reply_message.0’.
6. After the ELSE statement, insert another END statement to terminate the DO loop when all records from the external file have been processed.

Process the MQ_PUT message

The correlation ID that was recorded must be replaced with the correlation IDs from the live requests that are in the request queue. Additionally, the recorded response message must be replaced with the records from the external file.

1. Before the MQ_PUT tag that delivers the response and after the IF statement added in the last step, initialize a variable with the value of the current request’s correlation ID. Use the Performance Test REXX variable ACTUAL_CORRELID to return the actual correlation ID from the preceding MQ_GET. The correlation ID must be enclosed in single quotes and followed by the letter X to signify hexadecimal format. Therefore, the opening single quote, and the closing single quote and letter X, must be enclosed in double quotation marks.
2. Inside the MQ_PUT tag, replace the value of the MQMD_CORRELID parameter with the NEW_CORRELID variable.
3. Above the CONTENT tag associated with the MQ_PUT, insert the REPLACE tag to replace the recorded customer information with the current record from the external file (reply_message.i). The REPLACE tag requires a FIELD parameter that defines the offset and replacement value. It also supports an optional LENGTH parameter. Set the offset to 0 to begin replacing data with the first byte, set the replacement value to reply_message.i, which is the current record, and set the length value to new_len, which is the length of the current record.