DDS for regular display formats, but switched to UIM for help displays years ago. And for *CMD help.

Looked at samples of UIM applications. I think there were some panels and code in TAATOOLS, but never had a customer willing to make that switch. I can see the attraction, though. Most of the user interface stuff is taken care of by the UIM. Handles display, edit, lists (no more subfiles!), and I think even printing. You don't have to deal with screen handling, just react to events, if I remember correctly. 

Never really did anything with DSM. Looked at it once, 3 or 4 years ago. Don't even remember what I was trying to do (maybe a movable window?). In the end I stuck with DDS for that, too.

Dale,

I've been using UIM Helptest for my Cozzi Tools commands for a couple of years, but that's the extent of it. I'm going to build a UIM Menu maker to get some experience with it. Hate those DDS-based Menus. 

Too bad they don't also send UIM streams to the Web or even better, support XML in place of UIM tags.

I remember making panel groups with help text for a new collection of programs our department wrote way back in 1993.  It worked well but was still kinda tedious.  I've also made help text in Word, PDF, etc. and launched those from within the green screen.  Not sure what DSM is, so now I'll have to look that up...

Ooh - forgot about that. Yes, UIM for menus. They're reasonably easy to create, can do short, long, or no command line, and (the best part of all) they support scrolling.

Dale,

Menus, yes. And they are all pretty consistent in their structure. So I'm going to generate a Message File just like the DDS-based Menus, and then in my "Build Menu" routine, I'll extract the menu option text, command and helptext from the msgid. Looks relatively easy. But I've gotta get away from this SDA/DDS-based menus on one of my clients. They're painful.

One of my cutomers had a package that used *PGM menus. They were actually pretty slick. All menus used the exact same PGM(). The *PGM figured out the *MENU's object name, and then built the menu dynamically by interrogating a table with the menu name as the primary key. Unfortunately I don't have a copy of it anywhere.

I do remember that the menu item table had a few features you might want to consider:

I kind of remember it allowing you to specify comment text, blank lines, a command to execute, a menu to show, or a program to call. The *PGM would figure out what to do based on the line type.

MENUI's ACTION values would allow for CALL, CMD, or MENU. Comment text was just extra text that was displayed; the closest I think you'd get in UIM would be to use MENUGRP.

Don't remember a way to do blank lines or free form text. I think MENUGRP would allow for both, though not quite as freely. The MNUGRP has a name, which is the free form text, and I think there's an automatic blank line between MENUGRPs. P(aragraph) would make blank lines and free form text easy, but you're not allowed to use P inside of a MENU.

Allow for short or long command line, or option number only. UIM CMDLINE and OPTLINE tags.

It also allowed for resequencing. The menu editor allowed you to move lines before and after, like SEU, insert new lines, and delete lines. Each line had an Id that was independent of its sequence. Then there were next and previous sequence numbers in each item, maintained as a doubly linked list. The first item had previous = 0, and the last line had next = 99999. At run time, the menu's *PGM looked for previous = 0 to find the first item to display, then followed the links until it hit 99999.

I only have vague recollection of how it managed security. I kind of think it did check up front, and items you weren't autohrized to were not displayed in the run time menu. UIM would do that with COND and CHKOBJ. CONDs are separate from the MENUIs (or MENUGRPs) that use them, so that would be a little trickier to generate, but not impossible.

Don't know if any of this is worth incorporating into your "Build Menu", but it was a reasonably good system.

I've been using UIM for help for quite some time and at my current location they hadnt been using so it was a nice development to put together.  As of late, I created my own package to use the IFS for storing help text and linking it to DDS with the F1 or HELP key and displaying the help.  And, while the help is displayed the user can use SEU to modify the help text.  This lets users make and maintain their own help and with special characters they can highlight and underline text.   Neat little way to go.