DIMS8 is a generalized display/screen/form/terminal management system providing enhanced online system functionality for both current and future transaction system implementations. DIMS8 comprises a set of software tools and techniques which is easily applied to current development and maintenance methods. DIMS8 provides substantial benefits both in cost and flexibility, and encompasses any old, current and future terminals selected through a uniform network interface.
DIMS8 is an implementation method and a software package, which can be applied to the standard TP8 environment. It has been designed based on collected ideas and experiences from a number of TP8 projects. It provides:
Enhanced online system functionality
Generalized implementation techniques
Flexible network interface
DIMS8 combines a number of software features with a set of implementation standards.
Terminal independent displays
Generalized network and application interface
Generalized validation and editing
Generalized end-user communication
Logical display and application relation
Generalized utility functions
The implementation standards are skeletons to be customized by the site.
A transaction is composed of three different definitions and the actual application program. These components are dynamically related to each other by the DIMS8 software during execution of a transaction.
The display definition defines the application end-user view through a logical definition of its components ( text, fields, rules, etc. ).
The transaction definition defines the application communication needs in the form of interface fields and the linkage from the first display into the application program.
The terminal definition defines the physical attributes of the terminal type from which the transaction is executed.
The application program (tpr) defines the application process.
Terminal Definition
All network interface is handled through a number of logical functions. The terminal definition contains the physical attributes required to operate a specific terminal type. Each physical attribute is automatically replaced by the logical function during network communication.
The terminal definition will also contain a Site-standard definition, which applies to all displays communicated to this terminal type. Site standards define:
Reserved Areas: Date, time, message-id, logical-id, Status-, diagnostic-, broadcast-messages, etc.
Field Presentation: Text, output, input field appearance, diagnostic field appearance, etc.
Visual Attributes: Blink, blank, inverse video, etc.
Special Function Keys: Terminate transaction, refresh display, etc.
There is one terminal definition for each terminal type being used at the site, ex. VIP7700, VIP7800, QUESTAR/DKU, IBM 3270.
Different site standards may be set up for the same terminal type for use by different application systems.
Transaction Definition
The transaction definition contains a description of all the application fields to be communicated through the network. This description is used when defining displays and programming the application tpr.
This definition also links the initiated transaction from the initial input display to the first application tpr.
Display Definition
The display definition describes the application display in terms of:
Fields: Fixed text and variable field definition
Rules: Field validation and editing
Options: Visual attributes and fill requirements
Interface: Application fields where data is delivered or retrieved
The display is linked to the application tpr(s) via the application interface fields in the communication area. The display layout can be defined and redefined without any form of change requirement for the application tpr(s).
Application program (tpr)
The application process is implemented using standard COBOL-74 or COBOL-85. The network interface is established via the application interface fields and a few simple DIMS8 function calls.
The application tpr(s) tends to be small, since only the actual application process logic remains in the coding. All field validation and editing, plus all forms of network communication is handled by the related definitions.
Network Interface
The terminal definition concept will allow the same transaction to be executed on virtually any terminal type, using the same displays and totally independent from the application tpr(s). A site standard, which is applied to all displays, will define the general appearance of the display and the information that is to be automatically presented on each screen. This concept will make any transaction, no matter what application or function it performs, look familiar to the terminal operator.
Error Correction
This interface has been standardized and all error corrections operate through a uniform error correction procedure. This applies both to DIMS8 automatic validation and to any form of error correction initiated by the application.
Abort Handling
Abort handling has been enhanced and further standardized. This is to ensure proper guidance information for the terminal operator in any abort situation, as well as adequate debug information for the application programmer.
Development Tools
The transaction and display definition can be defined through a powerful online painting utility or via a definition language. Testing can be performed online independent from the application module development. New transactions can be tested without TP8 Workstation change requirements.
The application module testing has been enhanced to facilitate use of standard COBOL-74 debug features like TRACE and DISPLAY. A standard abort display describes debug information like TPR-name, abort-message/trace-message, IDS-II exception, last DML statement, last 30 trace events, .ABORT statement, etc. Furthermore, standard TPR DISPLAY-statements can be collected and browsed online. Actual TPR-dumps are seldom required.
Security Facility
A logon/logoff security system can be established on the basis of the standard user-group and authority concept of TP8. User identification is either logical-id, initials or both. The facility includes service transactions for logon, logoff and maintenance of identifications.
Broadcast Facility
A number of broadcast messages may be used for communication via the reserved area on any display. Central operation broadcast (urgent or normal), network broadcast for a single user or a group of users and system broadcast for application dependent displays are available.
Notepad Facility
This facility enables the user to maintain personal notes online. The notepad can be invoked as a separate transaction or at any point during operation of any other transaction via a special function key. After completing the notepad maintenance, the point of invocation is re-established, transparent to the application logic.
Mail Facility
This facility enables the user to create, post, receive and reply to letters online. As with notepad, mail can be invoked as a separate transaction or during operation of any other transaction. A special mail indicator in the reserved area of any display, displays the status of the personal mailbox (empty, mail or urgent mail). A range of electronic mail options are available, including possibilities for restricting mail utilization.
News Facility
This facility enables the user to consult news type documents online. In contrast to mail, these documents are of a more static nature and maintenance can be limited to certain users.
Menu Facility
A structure of menu displays - company, system, sub-system - can be built on top or as a shell for TP8 transactions. Use of the menus is optional and intended for the inexperienced user only. By using the send/transmit and selection codes the user can be navigated from physical logon to the system into any transaction. After completion the user can return to the current menu level directly from the transaction or via the send/transmit.
Help Facility
This facility enables the user to consult system documentation online. Help can be invoked as a separate transaction, or from within any point in any transaction. The user may choose between basic operational instructions or system documentation through a document hierarchy. Documents may be maintained to support help on a transaction level, interaction level (specific transaction state) or even on a field level.
Help is invoked via a special function key or by entering a special help indicator - i.e., ? - instead of an actual field value. After completing the help request the point of invocation is re-established, transparent to the application. Help on the field level may also be used to invoke special application logic, like customer selection from a list, when help is requested in the customer number field.
Paging Facility
The paging facility supports inquiry type transactions, where the application presents information via several displays of the same or different nature. Very often this is combined with a selection choice, thus providing levels of information presentation. Using the paging facility, the user will receive a uniform presentation of paging and/or selection possibilities. Paging operation is extended to support backward functionality, which normally requires very complex application coding. Selection operation is extended to support level navigation, where the user can return to previous levels of selection or paging-selection and choose a new path.
This very user-friendly and sophisticated functionality is transparent to the application logic, which simply operates on a present-next-page basis.