Last client had a file driven system that used *PGM menus. There was only one menu program. The menu name was keys to two files, a header (title, library list, ...), and details (text, commands, or blank lines, or text with no command which was highlighted, etc.). Because it was file driven, once you created the menu, all you had to do was update the tables for users to see changes.

In house and for other clients, I use *UIM. They have the same look and feel as all OS menus, and help is built in (if you want it to be). Coding of the actual command to execute is manual, but never found that to be much of a hindrance (just use the prompter and copy/paste). You can code a GO command, but there is a menu action that you should use instead. Command line support is automatic, like it is with a *MSGF menu (you'd have to deal with that yourself if you used *PGM menus).

I've always used in-house menu programs.  My first programming project was to create the menu programs for the in-house applications that we later developed.

Initial design included: Menu program (to display options to user - users would only see the options that they were authorised to), Tracking interactive and batch options, Menu maintenance, Jobs on System enquiry, User authority maintenance.

First round of updates expanded the Jobs on System enquiry to allow operations to reset records in the Jobs file where the job had died (or been cancelled from jobq) without clearing it's location, ability to send messages to interactive jobs (like "please sign off so we can do backups").

Later updates allowed duplication of a user authority to another user, fast path menus (so rather than just supporting menu options displayed you could enter menu code + option number).  We also added a "You are about to submit" screen for batch jobs with no submit options.

There was a later major rewrite that provided a more coherent structure to the menu application and the programs that it called - originally we had incorporated code in each program that communicated with the menu files and programs.  This rewrite moved all menu control to a single package of programs, and allowed us to insert 3rd party programs into our menu applications without having to change their code to include the old style handshake routines and files. - well heck like I said it was my first project!!

Since that time all sites that I've worked at have had some form of menu application - including one that was a SYNON generated monstrosity.  I have never worked with IBM style menus for application function.  In fact the only time I ever worked seriously with IBM menus was helping our operations staff (once again at my first job) set up their own menus for standard tasks - backups, power down/up requirements, etc.  And once they understood how the menus were built and operated they did their own thing from then onwards and I wasn't involved.

Hmm... since Neil mentioned it, I should add that *UIM does allow conditions. You can check object authorities, and you can check user class. Condition can be used on menu item or menu group. Not as flexible, I guess, as if you did something in a program, but easy as long as you have object securities setup properly.

Hi guys,

If it is green-screen stuff we use a home grown menu system that has worked nicely for the last 10-or-so years. It was built once upon a time using Synon:2E (CA:2E nowadays) but I wouldn't refer to it in the same manner as the Neilster does.

Regards,

Paulster

I have a menu system that I wrote and sell for $99 to any IBM i shop.  It is all subfile driven and has many useful capabilities.  Complete documentation is available.

Email: redbeetlesystems@bellsouth.net