[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]

General Programming Concepts: Writing and Debugging Programs


SMIT Screen Types

There are three main screen types available for the System Management Interface Tool (SMIT). The screens occur in a hierarchy consisting of menu screens, selector screens, and dialog screens. When performing a task, a user typically traverses one or more menus, then zero or more selectors, and finally one dialog.

The following table shows SMIT screen types, what the user sees on each screen, and what SMIT does internally with each screen:

SMIT Screens
Screen Type What the User Sees on the Screen What SMIT Does Internally with Each Screen
Menu A list of choices Uses the choice to select the next screen to display.
Selector Either a list of choices or an entry field Obtains a data value for subsequent screens. Optionally selects alternative dialogs or selectors.
Dialog A sequence of entry fields. Uses data from the entry fields to construct and run the target task command string.

Menus present a list of alternative subtasks; a selection can then lead to another menu screen or to a selector or dialog screen. A selector is generally used to obtain one item of information that is needed by a subsequent screen and which can also be used to select which of several selector or dialog screens to use next. A dialog screen is where any remaining input is requested from the user and where the chosen task is actually run.

A menu is the basic entry point into SMIT and can be followed by another menu, a selector, or a dialog. A selector can be followed by a dialog. A dialog is the final entry panel in a SMIT sequence.

Menu Screens

A SMIT menu is a list of user-selectable items. Menu items are typically tasks or classes of tasks that can be performed from SMIT. A user starting with the main SMIT menu selects an item defining a broad range of system tasks. A selection from the next and subsequent menus progressively focuses the user's choice, until finally a dialog is typically displayed to collect information for performance of a particular task.

Design menus to help a user of SMIT narrow the scope of choice to a particular task. Your design can be as simple as a new menu and dialog attached to an existing branch of SMIT, or as complex as an entire new hierarchy of menus, selectors, and dialogs starting at the SMIT applications menu.

At run time, SMIT retrieves all menu objects with a given ID (id descriptor value) from the specified object repository. To add an item to a particular SMIT menu, add a menu object having an ID value equal to the value of the id descriptor of other non-title objects in the same menu.

Build menus by defining them in a stanza file and then processing the file with the odmadd command. A menu definition is compiled into a group of menu objects. Any number of menus, selectors, and dialogs can be defined in one or more files.

odmadd Adds the menu definitions to the specified object repository.
/usr/lib/objrepos Default object repository for system information and can be used to store your compiled objects.

At SMIT run time, the objects are automatically retrieved from a SMIT database.

Note: You should always back up the /usr/lib/objrepos directory before deleting or adding any objects or object classes. Unanticipated damage to objects or classes needed for system operations can cause system problems.

Selector Screens

A SMIT selector prompts a user to specify a particular item, typically a system object (such as a printer) or attribute of an object (such as a serial or parallel printer mode). This information is then generally used by SMIT in the next dialog.

For instance, a selector can prompt a user to enter the name of a logical volume for which to change logical volume characteristics. This could then be used as a parameter in the sm_cmd_hdr.cmd_to_discover_postfix field of the next dialog for entry field initialization. Likewise, the selector value could also be used as the value for a subsequent sm_cmd_opt.cmd_to_list_postfix field. It can also be used directly as a subsequent initial entry field value. In each case, logical consistency requires that this item either be selected prior to the dialog or be held constant while in the dialog.

Design a selector to request a single piece of information from the user. A selector, when used, falls between menus and dialogs. Selectors can be strung together in a series to gather several pieces of information before a dialog is displayed.

Selectors should usually contain a prompt displayed in user-oriented language and either a response area for user input or a pop-up list from which to select a value; that is, one question field and one answer. Typically the question field is displayed and the SMIT user enters a value in the response area by typing the value or by selecting a value from a list or an option ring.

To give the user a run-time list of choices, the selector object can have an associated command (defined in the sm_cmd_opt.cmd_to_list field) that lists the valid choices. The list is not hard-coded, but developed by the command in conjunction with standard output. The user gets this list by selecting the F4=List function of the SMIT interface.

In a ghost selector (sm_cmd_hdr.ghost="y"), the command defined in the sm_cmd_opt.cmd_to_list field, if present, is automatically run. The selector screen is not displayed at this time and the user sees only the pop-up list.

The application of a super-ghost selector permits branching following menu selection, where the branch to be taken depends on the system state and not user input. In this case, the cmd_to_classify descriptor in the super-ghost selector can be used to get the required information and select the correct screen to present next.

Build selectors by defining them in a stanza file and then processing the file with the odmadd command. Several menus, selectors, and dialogs can be defined in a single file. The odmadd command adds each selector to the specified object repository. The /usr/lib/objrepos directory is the default object repository for system information and is used to store your compiled objects. At SMIT run time, the objects are automatically retrieved from a SMIT database.

Note: Always back up the /usr/lib/objrepos directory before deleting or adding any objects or object classes. Unanticipated damage to objects or classes needed for system operations can cause system problems.

Dialog Screens

A dialog in SMIT is the interface to a command or task a user performs. Each dialog executes one or more commands, shell functions, and so on. A command can be run from any number of dialogs.

To design a dialog, you need to know the command string you want to build and the command options and operands for which you want user-specified values. In the dialog display, each of these command options and operands is represented by a prompt displayed in user-oriented language and a response area for user input. Each option and operand is represented by a dialog command option object in the Object Data Manager (ODM) database. The entire dialog is held together by the dialog header object.

The SMIT user enters a value in the response area by typing the value, or by selecting a value from a list or an option ring. To give the user a run-time list of choices, each dialog object can have an associated command (defined in the sm_cmd_opt.cmd_to_list field) that lists the valid choices. The user gets this list by invoking the F4=List function of the SMIT interface. This causes SMIT to run the command defined in the associated cmd_to_list field and to use its standard output and stderr file for developing the list.

In a ghost dialog, the dialog screen is not displayed. The dialog runs as if the user had immediately pressed the dialog screen Enter key to run the dialog.

Build dialogs by defining them in a stanza file and then processing the file with the odmadd command. Several menus, selectors, and dialogs can be defined in a single file. The odmadd command adds each dialog definition to the specified object repository. The /usr/lib/objrepos directory is the default object repository for system information and can be used to store your compiled objects. At SMIT run time, the objects are automatically retrieved from a SMIT database.

Note: Always back up the /usr/lib/objrepos directory before deleting or adding any objects or object classes. Unanticipated damage to objects or classes needed for system operations can cause system problems.

Related Information

Chapter 25, System Management Interface Tool (SMIT)

SMIT Object Classes , SMIT Aliases and Fast Paths , SMIT Information Command Descriptors , SMIT Command Generation and Execution

Adding Tasks to the SMIT Database , Debugging SMIT Database Extensions , Creating SMIT Help Information for a New Task

Chapter 17, Object Data Manager (ODM)

odmadd command, smit command


[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]