Introduced in version 7.1 of the Sirius Mods, Screen objects are designed to make writing and maintaining User Language full-screen applications easier. They also let you take advantage of dynamic 3270 screen sizes in your applications.
Most modern 3270 emulators allow flexible definitions of 3270 screen sizes beyond the standard Models 2, 3, 4, and 5. Traditional User Language screen definitions define a fixed layout for a screen and so must be designed to be display correctly on even the smallest screen. This is usually the 3278 Model 2, which contains a none-too-generous 24 rows by 80 columns. Though a screen designed for a 24x80 layout will usually display correctly on other models, screens designed for other models may display misaligned data on a smaller screen, often rendering the application unusable on these screen types. This leaves the application programmer little choice but to design for the lowest common denominator — Model 2 — wasting precious screen space on larger screens.
With Screen objects, screen definition takes place during User Language request evaluation instead of during compilation, freeing the programmer to detect and take advantage of the current screen size and to make more efficient use of available screen space. It is therefore possible for a single application to support many different screen sizes without changing User Language code or resorting to special $functions to manipulate a traditional screen layout.
Screens and ScreenFields
The Screen class provides an object-oriented equivalent of the Model 204 full-screen feature. An instance of a Screen object is equivalent to a screen you might define with the User Language full-screen feature. The Screen methods specify layout and certain visual attributes of each screen: where screen items are to appear on the video display, and how they are to be highlighted or colored.
Screen objects are composed of screen fields and not screenlines as in the full-screen feature, and multiple screen fields may form the equivalent of a single screenline (or row). These screen fields are themselves objects: instances of the Screenfield class. In this document, ScreenField objects are sometimes referred to as “fields” and sometimes as “screenfields.”
System space for Screen objects
Traditional User Language full-screen applications use FSCB (Full SCreen Buffer) space to hold 3270 screen definitions. Since screen objects are part of Janus SOAP, the design must fit within this existing object-oriented architecture, which cannot utilize FSCB space. As a result, screen objects use STBL space for dynamic screen definitions.
Because the entire screen image must be in contiguous storage, any instance of a screen object must allocate the maximum allowable STBL space, even if some of this space may not be used by a particular application. You use the SCRNSTBL user parameter, which specifies the maximum size per screen, to prevent unnecessary waste of STBL space and to limit an application to a reasonable amount of space to prevent STBL exhaustion.
A good starting value for SCRNSTBL is 6144 (this is the default as of Sirius Mods 7.3 and maintenance to earlier versions). Scrolling applications and applications designed for large screens with many fields may require two or more times this storage. An application that exceeds its screen STBL allocation is canceled.
- The Janus SOAP manual in PDF format: http://sirius-software.com/maint/download/jansoapr.pdf
- The Category:Screenfield methods page on the Sirius Wiki.
- Documentation conventions and terminology used in Sirius Software technical documentation.