Everybody likes using the DDS keywords that support the programming of windows. However, if you're running the job across a communications line, you should be aware that windows programming has some drawbacks. Displaying a window requires workstation data management to read the current 5250 screen, to save the state of that screen, and to be prepared to restore the screen at a moment's notice. The more windows you build on the display, the harder the system has to work to manage this emulated desktop. If you have a user on a communications line, the response time can lag.

So how can you minimize the impact?

Use the User Restore Display (USR-RSTDSP) DDS keyword in your display files. This keyword places the function of saving and restoring the display under program control, allowing you to tailor the effects of the windowing without punishing the system. Programming with USRRSTDSP requires a bit more attention on your part, but ultimately provides a windowing screen that is maximized for your real environment.

Here are some other tips.

? Use the Display Size (DSPSIZ) DDS keyword consistently on your screen formats. Every time the system has to reformat the screen size for the remote workstation, the system takes a hit.

? Use the Erase Input (ERASEINP) keyword when the user is doing lots of heads-down keying. The 5250 data-stream actually has an "erase all input fields" control code it can send to the display to zap the fields on the workstation. This is less overhead than sending back a datastream of blanks or zeros to the remote workstation.

? Keep the number of display formats that you overlay onto the workstation to a minimum. When the user presses Enter, each one of them has to tunnel back to the system. Nevertheless, if your application requires you to splatter multiple formats on the screen, here's something else to think about: the 5250 hardware always processes input in a top-to-bottom, left-to-right manner. If you send Format A to the bottom of the screen and follow it by sending Format B to the top of the screen, you've created a knot for the 5250 hardware to unravel. It's best to send the screens out and position them on the display in the same order in which your program expects them back.

? Use the Clear Line Number (CLRL) DDS keyword instead of sending back an entire updated format. The CLRL keyword allows you to zap a particular line on the screen. For instance, if the user presses Enter and the program sends back the same format with a single line of data updated, the CLRL keyword can greatly reduce the turnaround time.

? Check out the real functionality of the override trio of record-level and field-level keywords (PUTOVR, OVRATR, and OVRDTA). If you're repeatedly sending the same format back to the display, these override functions can individually control the fields and their attributes.

? Whenever possible, use DDS keywords for validity checking of input fields. The 5250 hardware has been optimized so that all of these validity checking functions actually occur in the workstation. That means you don't have to send the entire screen down the communications line, chew up a couple of CPU cycles, and spit it back all the way to the remote display just to inform the user he keyed in a bad field.

? Don't use the 5250 Numeric Only field types. The Numeric Only function allows the user to enter decimal points and commas on numeric fields. Unfortunately, workstation data management has to parse through these input fields to perform decimal alignment before it passes the fields to the program. If you have a lot of people using this function, performance can be impacted.

? Break the Write/Read habit of sending and receiving display formats. It takes two line turnarounds using Write/Read when-in the majority of cases-a single EXFMT operation code would suffice. EXFMT will only create a single line turnaround.

? If you're outputting only to a display station, be sure to use the Defer Write-DFRWRT(*YES)-keyword. An RPG WRITE operation forces a line turnaround unless DFRWRT is also issued.

-Thomas M. Stockwell

Thomas M. Stockwell is an independent IT analyst and writer. He is the former Editor in Chief of MC Press Online and Midrange Computing magazine and has over 20 years of experience as a programmer, systems engineer, IT director, industry analyst, author, speaker, consultant, and editor.  

 

Tom works from his home in the Napa Valley in California. He can be reached at ITincendiary.com.