Application screen management: an APL2 approach

ABSTRACT

This paper describes a comprehensive full screen management system written in APL2. It provides an application I/O interface that may be adapted to a variety of screen management specific subsystems in both interactive and background environments. Besides the usual character and numeric field support, additional field types and attributes are supported by the system described here. This system differs from past efforts in several respects. It is written in APL2, and takes full advantage of APL2's extended data structures and vector notation for its implementation and application code interfaces. Additionally, it was designed as a generalized application-user I/O interface, and as such, provides a great deal of isolation between the application and the specific screen management subsystem employed by the screen functions. It is also easily extended to support new features, such as additional field types, as well as new screen management subsystem specific facilities as they become available. To date, such extensions have been made without impacting the existing application base. In actual application usage, these functions have been found to be easy to use, and have in most instances resulted in simpler application code than would have been possible otherwise.

REFERENCES

• 1: Terry McKee, Menus with APL, and other full-screen applications, ACM SIGAPL APL Quote Quad, v.9 n.4, p.196-201, June 1979
• 2: David M. Weintraub, A flexible full-screen applications development workspace utilizing APL syntax, ACM SIGAPL APL Quote Quad, v.13 n.3, p.187-193, March 1983
• 3: For example, the Screen Management Functions provided in the workspaces FSC124, FSC126, and FSM distributed with IBM's VS APL (IBM Program Number 5748-APl).
• 4: For an extended discussion of using APL2 with a relational database system, see Brown, James A., and H. Crowder, "APL2: Exploiting DB2 and SQL/D'S," IBM Santa Teresa Technical Report TR 03.267, July 1985, and Brown, James A., "Multi-user SQL Applications in APL2," IBM Santa Teresa Technical Report TR 03.274, September 1985.
• 5: Graphical Data Display Manager (IBM Program Number 5748-XXH); Auxilary Processor 126 is the IBM-supplied interface between their APL Program Products (VS APL and APL2 (IBM Program Number 5668-899)) and the Graphical Data Display Manager Program Product.
• 6: In GDDM, screens are formatted in "pages," which are areas of memory reserved by GDDM. Pages are referenced by page number, and GDDM activity (page formatting, reading, etc.) may only be performed in the "current page". GDDM pages may be created and selected as the "current page" by the SMF functions SCBPAGECREATE and SCRPAGESELECT respectively.
• 7: Details of GDDM concepts and usage, except where necessary for the discussion at hand, will not be presented here. For an excellent introduction to GDDM, see "Graphical Data Display Manager Application Programming Guide," (IBM Corporation, IBM Form No. SC33-0148).
• 8: In lieu of a specific override by the transaction in its call to SCRRETRIEVE, several PF keys are "reserved" for use by SMF. PF 1 is used to display any predefined "Help" text field present in the panel object, PF 2 is used to initiate the automatic screen copy to the predefined printer, and PF 5 is used to "refresh" all the input fields. To informSCRRETRIEVE that it is to recognize usage of a particular PF key (other than the "reserved" keys), that PF key number is passed to SCRRETRIEVE. To disable a "reserved" PF key, the negative of the PF key number is passed to SCRRETRIEVE- To override a "reserved" PF key (i.e., have SCRRETRIEVE return control to the transaction), the number of the PF key is explicitly supplied to SCRRETRIEVE.
• 9: Although one could interpret the 0 result from SCRPFKEYas implying that the "Enter" key was pressed, this approach precludes running transactions which make this assumption on terminals which support other types of key replies (such as PA keys on IBM 327x terminals).
• 10: In retrospect, the use of 126 as the major event code was a mistake, as it "ties" SMF to a specific screen management subsystem (AI? 126 and GDDM) to a greater degree than is desirable for a truly screen management subsystem independent implementation'
• 11: It is possible to avoid having to change any of the SMF functions which call SCRGDMX by having the new SCRGD~ "translate" the GDDM calls passed to it into equivalent calls for the new screen management subsystem.

INDEX TERMS

Classification:
  D. Software
  D.2 SOFTWARE ENGINEERING
      D.2.2 Design Tools and Techniques
          Subjects: User interfaces
  D.3 PROGRAMMING LANGUAGES
      D.3.2 Language Classifications

          Nouns: APL
      D.3.3 Language Constructs and Features
          Subjects: Input/output

General Terms:
Design, Languages, Management