Re: Multiple Displays vs One Display

This is an interesting thread. I've never hard of this "one screen /
one module" recommendation before. I'm having a hard time

understanding why you'd do this...

My comments are simply my preferences and not necessarily what I think others should do, but I prefer designs where one subject is distinguished
from another - both at the UI level as well as the program level. I develop Web applications almost exclusively, but I think the same could apply to 5250 interfaces as well.

In a purchase order application, you're usually dealing with separate files for header data and line item data. So at the UI level, my preference is to provide one tab for entering and maintaining header data (and displaying line item summary data), but provide a separate tab for entering and maintaining line item data.

I generally use three (3) RPG modules for database maintenance. The first is used to create a *PGM object, and performs request dispatching and control functions for the browser. *SRVPGM objects are created from the other two modules which are used for browser I/O and database I/O respectively.

I follow this pattern for both header and line data, so in the case of purchase order maintenance, I'd have at least six (6) modules - one set of 3 for header data and another set of three for line item data. This defines a well balanced design that's easy to understand and maintain.

On the HTML side, I'd have one set of templates for header data and another set of templates for line item data, which would be roughly equivalent to having one 5250 display file for header data, and another for line item data.

There's a performance and work management benefit as well. If a user is simply browsing header data, there's no need to load or activate the code and files required to support line item data. Program initialization is kept to a minimum, and only occurs if requested.

Nathan M. Andelin