Looking for less complex DSM interfaces

5250 session
We have recently developed a business application using external definitions stored in a database file - such as fields definitions, data structures, validity checks, and so on. One of the uses of this external data has been to generate a DDS source that is then compiled into a DSPF. I would like to replace this generate-DDS/compile-DSPF solution and generate runtime on-the-fly 5250 screens instead. I understand that DSM could be the solution, but it seems a bit complex. I would like to know if there are any other solutions you are aware of, or if there are any friendly DSM interfaces that neutralize some of the complexity. The DDS we generate utilizes the standard DDS attributes such as indicators, PR, UL and so on, for both subfile and detail formats.

Answer Wiki

Thanks. We'll let you know when a new response is added.

The DSM option is the only way to go, and so far AFAIK no one has provided any tools to use it.

You can use RPG to manipulate a full 1920 byte screen field, inserting hex 20’s as end of field terminators and so on, but frankly, you’ve got the best solution for the present.

I’d hate to try and use DSM to handle subfile output, when I have a higer level language that could do it


There are four general directions to take for green-screen I/O:

    • DDS display files
    • UIM displays
    • USRDFN record I/O within DDS
    • DSM I/O

Both DDS and UIM display files are compiled and effectively “fixed format”. USRDFN I/O is done within a DDS display file, but the content of USRDFN record formats is completely determined at run-time. DSM requires no display file object at all.

USRDFN I/O is done by placing the low-level 5250 data stream commands directly into a record buffer and writing the record. It requires very detailed knowledge of the 5250 data stream.

DSM is much easier than USRDFN I/O because it is based more on functions rather than the specific bytes of the data stream. After a little practice to learn what some of the elements are for, most of the APIs become clear. You can then reduce the API calls to procedure calls that you design how ever you choose.

Here are a couple collections of trivial examples that I put together to show how even ILE CL can make use of DSM. First, the DSM Commands Directory has some examples of a few simple *CMDs built over DSM APIs and a CL program that outputs a list of records from the QCUSTCDT file in the standard QIWS library. Then, the Dynamic Screen Manager Directory lists most of the DSM APIs as code samples in ILE CL. (The CL is all written for pre-V5R3.)

The example program in the first set shows that some fairly complex screen output can be done with CL. Obviously, ILE RPG or even V5R4 ILE CL could do far more.


Discuss This Question:  

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: