Have you ever wanted to do something with a display file but you couldn't seem to get DDS to do it? The last thing you wanted to do was start coding 5250 data streams in a user-defined record format. In that case, Dynamic Screen Manager (DSM) is just what you have been looking for.
DSM is implemented as a sub-set of the standard iSeries API set. It allows you to build screens and windows dynamically from any ILE-language program, even CL! You can even mix DSM with standard DDS display files.
Here are just a few examples of how you might use DSM:
- Create a window the user can move and re-size. The window position is specified at runtime.
- Sound the workstation alarm without writing a display file record (using the QsnBeep API).
- Replace many things you do now with a more intuitive approach. For example, to determine the display mode (i.e., 24x80 or 27x132) before writing to the display, the Retrieve Screen Dimensions (QsnRtvScrDim) API can be used instead of executing a POST to a display file's record format and then querying the display file's file information data structure.
DSM offers three "functional groups" of services, depending on how much control you wish to have over the screen.
- Low-level services provide a direct link to the standard 5250 command set. Most of the more common 5250 commands (e.g., Sound workstation alarm) are mapped directly to APIs; those that are not can be executed similarly to the user-defined record method in DDS (i.e., by writing the hexadecimal command to a buffer and writing the buffer).
- Window services provide a way to dynamically build windows of any size at any location. Once a window is built, the user can move and resize it. Windows and OS/2 programmers will feel somewhat at home using these APIs.
- Session services provide a scrollable interface conceptually similar to subfiles. A session is a specialized form of a window; it can be moved and resized. Because DSM handles more of the details with sessions, you are more limited as to what you can do.
There are two different ways to use the DSM APIs, directly or indirectly. When an API is called in direct mode, the underlying screen command(s) is executed immediately. To call an API in indirect mode, you specify a command buffer as one of the parameters and the underlying screen command(s) is written to the command buffer instead. You can add multiple commands to a command buffer and then later call the Put Buffer API to have DSM execute all the commands at once. This can be much more efficient, especially as the number of commands increase.
Despite its new technical jargon and low-level appearance, DSM can be quite easy to use and has some real application. It is worth looking at when you are through beating your head against the wall over DDS.
Note: The DSM APIs are in the QSNAPI service program. You must bind your programs to this service program to use them.
-----------------------------------
About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years' experience programming for and managing AS/400-iSeries systems.
