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.