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.
The following figure shows possible relationships among SMIT menus, selectors, and dialogs. 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.
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.
You 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.
You build menus by defining them in a stanza file and then processing the file with the odmadd command. Any number of menus, selectors, and dialogs can be defined in one or more files. The odmadd command adds the menu definitions 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. A menu definition is compiled into a group of menu objects. At SMIT run time, the objects are automatically retrieved from a SMIT database.
Attention: 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.
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.
You 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.
You 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.
Attention: 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.
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.
You 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.
Attention: 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.
System Management Interface Tool (SMIT) Overview for Programmers.
For more information about programming SMIT, see Understanding SMIT Object Classes, Understanding SMIT Aliases and FastPaths, Understanding SMIT Information Command Descriptors, and Understanding SMIT Command Generation and Execution.
Adding Tasks to the SMIT Database, Debugging SMIT Database Extensions, Creating SMIT Help Information for a NewTask.
For information about programming with ODM, see Object Data Manager (ODM) Overview for Programmers.
The odmadd command, smit command.
