I would recommend the second option you mentioned, namely a “driver” program (with the main menu), and separate subprograms for the various options.
Depending on the number of options, in the main menu, the GDA you mention in your first approach could become quite large. Also, maintenance of the GDA variables would be more annoying than would be the case with individual PDAs for each subprogram.
A robust menu/navigation subsystem will support PF keys for drill-down and transfer of control, and will allow or disallow access to functions for individual users or groups. Building this logic can be quite complex. If you build all functions as programs, then Natural Command Processor can be used to handle much of the navigational control. Also, it may be simpler to test and invoke programs “stand-alone”, as in batch.
Yes, that is true, but I prefer to have the “Security”-Layer and “Navigation” in the natural-programs. I think it is more flexible and you have the controll in one hand. Another point is, that I don’t have to handles with GDAs.
They are diffcault to you and in a error-case hard th handle.
If you are using only one mainprogram it is easy to restart after a hard error. You start at the beginning. All varablies are correctly set.
In my case, it is easier to test subprograms than programs.
I can test the subprograms with our Test-Framework NatUnit http://sourceforge.net/projects/natunit/?source=directory very easily and retest them every day.
Next point is, that a subprogram give me the chance to make the subprogram “SOA”-enabled. With a program I can’t to this.
For a batchmode I musst write a wrapper programm, thats ok.
A subprogram gives me the oppertunity to use it in another workflow.
If I want to use it with programs, I found sometimes this ugly code:
IF MAINPRG EQ 'WRKFLW1' OR EQ 'WRKFLW2'
But I have no experiance with this desgin and I wanted to know where are the contranits.
If you wish, you could have a common program serve up all main menu and sub-menu screens if the layout is the same and just the content is different. Typically the functionality on all main and sub-menus would be close to identical.
I once worked on a complex application in which a specific scenario resulted in a subprogram being executed at level 40. Very difficult to debug.
But even fairly simple applications can get you beyond level 99. You have to support typical PF3 logic - “take me back to where I was.” Combine this with 5 or 6 PF keys (on every screen) that “drill down” or take the user to related functions. Most users will repeatedly use those navigation keys and rarely use PF3. Whether you use FETCH RETURN or CALLNAT to drive the menu/navigation system, each transfer of control is another level deeper, and you will eventually exceed the maximum of 512.
If you build an application with programs instead of subprograms, you can set your own maximum and tell the user when he reaches or exceeds it.
I believe you are on the right track using FETCH instead of FETCH RETURN or CALLNAT. An object that just fetches itself passing parameters stays at level 1 and has no issue finding its way around. We designed ours to use navigation codes (4 3-character codes, 1 for each submenu level), so based on the selection or function key, it FETCHes itself with the new set of codes which can be either selected or entered on a command line so people who know the codes can jump right to where they want to go. We display only the codes the user has access to and do not permit entry of a code that is also not on that user’s navigation profile.