This chapter describes the problema software package. The following topics are covered:
An overview of the problema system and its interfaces in “The problema Request Management System.”
Instructions on installing and configuring problema are provided in “Installing and Configuring problema.”
A description of the actions and processes that problema users and administrators are likely to use in “Using problema.”
A specific description of the user-level facilities of problema is provided in “General Operations.”
The problema system administration request tracking service is based on the successful CASEVision/Tracker™ application, and brings the power and ease-of-use of that software to the system administrator. The configurability of Tracker has been maintained in problema, while custom-tailoring the application to the system administrator's needs. The Tracker product must be installed in order to use problema successfully.
Much of the in-depth documentation provided with Tracker is also accurate for problema, and should therefore be considered a valuable resource for understanding this product.
The problema request tracking software uses the same database software technology used in Tracker and in the rest of the IRIXpro suite of system administration tools. However, the problema application uses the dml language, as opposed to sgitcl in the rest of IRIXpro. Sample dml scripts are provided in the /usr/IRIXpro/sample/problema directory that are designed to be run as root and irixpro cron(1) jobs. The script problemaDBclean removes the requests marked as DELETED from the database. The problemaDBdue script lists the requests that are not closed and past their expected due date.
The problema application has been designed to offer a convenient way for users to request system administration services and to offer administrators a convenient way to track those requests. A clear record is kept of each request, and the administrator is free to prioritize and assign each request in the most efficient way. With this system, the best interests of the user and the administrator are served by clarifying a process that is often handled informally.
The problema request tracking system includes a database to hold system administration requests and graphical interfaces to that database. Online help is available at all times through the graphical interface windows, providing detailed instructions on the request filing, tracking, resolution and querying processes.
The problema application consists primarily of a database and three very similar interfaces to the information in the database. The difference between the interfaces is primarily in the level of detail and number of fields offered. The first interface is the one most users see regularly, called miproblema. This interface provides only the most basic fields necessary to submit a request to the administrators. The second interface is problema, which is also designed for users, but which provides a more complete interface to the database. The third interface is reserved for the system administrators or managers who make decisions and take action on the requests submitted by the users. This administrator's interface is called suproblema. The suproblema window contains some fields and options not available on the problema user-level version. All these interfaces are described and shown in the section titled “Using problema”.
In the course of this chapter, except where otherwise stated, all information is true for all problema interfaces. The suproblema interface is a superset of the problema interface, and the problema interface is a superset of the miproblema interface. The term problema is used in general to describe the database and its interfaces, rather than strictly the user's interface.
In addition to the functions available through the miproblema and problema interfaces, the suproblema interface to the problema database allows the administrator or manager to track a request that has been forwarded to a known vendor, and to add a technical description of the user's problem. It offers more action options than are available through the user's interfaces.
Typically, the suproblema interface is installed only on the host where the system administrators maintain the problema database and have regular access. Hosts that serve users generally have the miproblema and problema interfaces. However, you are free to install suproblema wherever you like and allow whomever you choose to use it, as best suits your needs.
This section describes the problema process in terms of the life cycle of a request in the system. The data flow diagram in Figure 5-1 illustrates the request tracking process.
A request can go through many different states during its life cycle. The request tracking process has four major stages:
A user submits a request into the problema database. At this point the request is in the AWAITING_RESPONSE state.
The request is assigned to an owner to perform the work. If no action is required (for example, if the request is already resolved, must be deferred, or is a duplicate), the request is tagged appropriately and then returned to the database in the CLOSED or AWAITING_RESPONSE state for later action.
Assigned requests are then executed by their owners. The owner may also elect to defer, resolve, or tag the request as a duplicate, or the request may be forwarded to an outside vendor for attention.
Finally, the request is resolved when the work is done and the request is moved to the CLOSED state. If the work was not done correctly, the original requesting user can reopen the request, if need be, or submit a new request.
The problema application is ready to run when you install IRIXpro on your system. All basic files necessary for standard usage are installed and configured for you. To use problema as it is distributed, you must have a CaseVision/Tracker user's license installed as well.
The problema application can be configured to match your needs and methods of administration. All necessary files for customization are installed with the application. To customize problema or create your own custom application, you must have a CaseVision/Tracker designer's license installed.
You can configure problema to accept the selected priorities, categories, and individuals who are authorized to execute problema operations. But first, you must install problema on each client system and the server, and run the application generation tools.
Follow these steps to install problema on your server:
Log in to your server as root.
Use the inst(1) program to install the Tracker 2.0 product and the appropriate licenses on your server.
Execute the command /usr/IRIXpro/problema/problemainstall. This command puts the problema commands in /usr/local/bin and the problema app-defaults file in /usr/lib/X11/app-defaults, and initializes your database. This process also adds problema online help to your sgihelp system. When this is done, problema is installed on your server.
Put /usr/local/bin in your PATH environment variable, if it is not already there.
Execute the suproblema command.
Follow these steps to install problema on your client systems:
Log in to your client as root.
Use the inst(1) program to install the Tracker 2.0 product and the appropriate licenses on your client.
Using either inst, NFS, propel, rcp, or media-based transfer, install the following parts of your problema software distribution on your client:
/usr/IRIXpro/problema/problema.pdl
/usr/IRIXpro/problema/tools
/usr/IRIXpro/problema/problemainstall
Make sure your system has the /usr/local/bin directory, or create it if needed.
Execute the command /usr/IRIXpro/problema/problemainstall. This command puts the problema commands in /usr/local/bin, the problema app-defaults file in /usr/lib/X11/app-defaults, and determines the locations of the server database. This process also adds problema online help to your sgihelp system. When this is done, problema is installed on your client.
Put /usr/local/bin in your PATH environment variable, if it is not already there. If you do not wish to use the /usr/local/bin location, the problema application can be started from the icon in the IRIXpro directory view, as can all IRIXpro applications.
Execute the miproblema or problema command.
You must create a user called irixpro on your system if you wish to delete request records from your problema database when they have been closed, or if you wish to access Silicon Graphics Electronic Services.
Create the user irixpro according to the instructions in Chapter 5 of the Personal System Administration Guide or according to the instructions in Chapter 3 of your IRIX Advanced Site and Server Administration Guide. You may use any available UID for this account.
The configurable parameters of problema are stored in the following files. Each file is described below:
/usr/IRIXpro/problema/miproblema.pdl
/usr/IRIXpro/problema/problema.pdl
/usr/IRIXpro/problema/suproblema.pdl
/usr/IRIXpro/problema/problemagen
/usr/IRIXpro/problema/categories.h
/usr/IRIXpro/problema/vendor_categories.h
/usr/IRIXpro/problema/vendor_names.h
/usr/IRIXpro/problema/vendor_priorities.h
/usr/IRIXpro/problema/vendor_status.h
/usr/IRIXpro/problema/tools/lib/problema_notify
/usr/lib/X11/app-defaults/Miproblema
/usr/lib/X11/app-defaults/Problema
/usr/lib/X11/app-defaults/Suproblema
This is the configuration file for the miproblema view of the application. This is a plain text file, editable with any text editor. You must be logged in as root to edit this file. The file is extensively commented and you can alter it to change miproblema as you see fit. There is extensive documentation on modifying PDL files in Chapter 2 of the CASEVision/Tracker Design Guide, titled `'Using the Process Description Language.''
This is the configuration file for the problema view of the application. This is a plain text file, editable with any text editor. You must be logged in as root to edit this file. The file is extensively commented and you can alter it to change problema as you see fit. There is extensive documentation on modifying PDL files in Chapter 2 of the CASEVision/Tracker Design Guide, titled `'Using the Process Description Language.''
This is the primary configuration file for all of problema. This file specifically defines the suproblema application as it is distributed. This is a plain text file, editable with any text editor. You must be logged in as root to edit this file. The file is extensively commented to help you make your configuration choices. There is also extensive documentation on modifying PDL files in Chapter 2 of the CASEVision/Tracker Design Guide, titled `'Using the Process Description Language.'' This file is where you set the allowable categories of requests, the allowable priorities, and the acceptable entries for each field.
This script takes the changes made to the suproblema.pdl file and effects the changes in the problema database. If you use problema to create a custom application with its own database, use this file to specify the location of the database and the PDL file for the new application.
The categories.h file controls the available categories for requests through problema. You may customize this file as you see fit, and you can select a default owner for each category of requests if you so choose. The format is:
Category // Owner Misc, // jschmoe |
Each category and owner pair are separated by two slash characters. On all but the final line, a comma (,) must follow the category name. Instructions are provided in the text of this file. This is a plain text file, editable with any text editor. You must be logged in as root to edit this file.
This file controls the available vendor categories for request forwarding. Each category should correspond to an appropriate outside vendor.
This file names the available outside vendors for request forwarding. Each line in the file names a vendor.
This file names the available vendor priorities for request forwarding. Each line in the file names a possible priority.
This file controls the various options for the vendor's status on a request. The default values should cover most scenarios, but this file is configurable.
This file controls the e-mail process whereby users and other parties are notified of request transitions. This file is configurable.
The primary means of configuring the problema functionality is by editing the suproblema.pdl file, the miproblema.pdl file, and the problema.pdl file. These files are extensively commented, and written in the Process Description Language, which is described in detail in Chapter 2 of the CASEVision/Tracker Design Guide. Specific information regarding PDL syntax can be found in that guide.
The problema software is completely configurable for your site and organizational needs. The Process Description Language allows you to work within a basic framework of data structures and concepts to define:
your request states
the transitions between those states
the fields that will make up each request record
the allowable values for those fields
The Process Description Language also allows you to set up rules regarding the use of the data structures you have defined and to define new applications or new views of the problema database. Finally, you can use the PDL files to have problema execute IRIX shell commands of your choice as part of transitions, make field values available to your users as shell environment variables, and generally tailor the interaction between problema and other system utilities or applications.
The following list offers suggestions and ideas about custom uses for problema and the Process Description Language. The example used for customizing is a system administration group with special needs for quick response:
| Request States | Given the definition of the problema application as a database product, you can define your own states for requests. For example, if your organization submits results back to the requesting party for final approval, you can create a state defined as AWAITING_APPROVAL. | |
| Request Transitions |
| |
| New Fields | Different organizations have different information they wish to track in the life cycle of a request. The problema application allows you to create and define request description fields as you see fit. | |
| New Field Values |
| |
| New Rules | You can define rules about who in your organization may make transitions (each transition can have its own customized rules) and about which fields must be filled in for transitions to take place. For example, there can be transition commands restricted to certain users, or the vendor forwarding transitions can cause e-mail to be sent directly to the outside vendor. | |
| New Applications |
| |
| New Views | You can create, in the same manner as with a new application, a custom view of the database. For example, you may wish to create a view of the database that allows only request submission. To do this, begin with a copy of the problema.pdl file and modify it to suit your needs. Information that is confidential or irrelevant may be screened from the view provided to different users. | |
| IRIX Command Execution |
| |
| Environment Sharing |
| |
| Application Interface |
|
The Process Description Language imposes very few rules on the application developer. The language works within the paradigm of the database, and actions are defined in terms of field values, request states, and transitions, and in terms of views of the database records beyond these limitations (which can more correctly be termed specializations), you are free to define the services problema renders to you and your users.
The following sections describe the form and use of suproblema, miproblema, and problema. First, there is a description of each part of the interface window and information on using the features in the window. Then information is provided on using other features of problema. Finally, specific sections detailing operations on the server and client systems are provided.
The suproblema main window is shown in Figure 5-2.
The problema main window is shown in Figure 5-3:
The miproblema window is shown in Figure 5-4:
All the problema main windows have four parts:
| menu bar | Lets you access the window menus. | |
| control bar | Lets you display a list of requests and perform operations on individual requests. | |
| query results area |
| |
| request form area |
|
Each part of the problema main windows is described in detail in the sections below.
The menu bar in each problema main window is shown in Figure 5-5.
The menu bar offers you four menus. The menus are:
| File menu | Lets you print a file or exit the window. | |
| Edit menu | Provides editing commands that you can apply to all fields as a group:
| |
| Query menu | Lets you reuse query selection criteria by making the following settings:
| |
| Help menu | Lets you get product version information, summary information for the window, context information for components of the window, and an index of help topics for the system. |
The control bar of each problema window is shown here in Figure 5-6, with the Query mode selected from the Modes menu
The Modes menu on the left displays the actions that you can perform on requests in the database. At any given time, some actions may be disabled if they are not available for the request being acted upon. For example, if you are examining a closed request, the “resolve” action is not available.
The actions available from the miproblema Modes menu are:
QUERY
DISPLAY
SUBMIT_REQUEST
The actions available from the problema Modes menu are:
QUERY
DISPLAY
SUBMIT_REQUEST
RESOLVE
NOTIFYME
EDIT
REOPEN
The actions available from the suproblema Modes menu are:
QUERY
DISPLAY
SUBMIT_REQUEST
RESOLVE
NOTIFYME
EDIT
REOPEN
FORWARD_TO_VENDOR
UPDATE_FROM_VENDOR
ASSIGN
DEFER
DUPLICATE
DELETE
When you select a command from the Modes menu, the information displayed in the rest of the window changes, as does the read/write permission on the fields below in the request form area. To the right of the Modes menu, the apply command button changes to reflect the command you selected from the Modes menu.
Commands have two categories: inspection commands that review requests and transition commands that can change the state of a request. The inspection commands, Query and Display, let you look up requests, either in a list of summaries or individually in detail. The transition commands change either the status of the request or the fields in the report. Any field required for a specific transition is highlighted, indicating that an entry is necessary. If no entry is made, then the command cannot be applied.
The list control buttons on the right of the control bar are:
First
Next
Previous
Last
These buttons let you choose a request from the query results area list for display in the request form area.
The problema query results area is shown below in Figure 5-7. It is shown empty, as it is when the interface is first brought up.
The number of requests in the current query is displayed at the top of the list area. When a query is made, the requests selected are listed in the grey area. If you use any of the list controls (buttons or menu items) to display a request in the request form area, the list in the grey area will scroll to the displayed request.
Two small icons that may appear to the left of a list entry in the grey area also help to track the status of a request:
A small rectangle indicates that the request has been displayed in the form area at least once since its submission.
A check mark indicates that the request has been edited at least once.
The query results area is divided into six columns, each with a title. The text in each column lines up under the title. Next to each title is a radio button. When you click one of these buttons, the button is highlighted and the list of requests is sorted accordingly. For example, if you click the ID# button, the list is sorted in ascending order according to the request identification number. You can sort only one characteristic at a time.
The request form area contains fields for entering and displaying data. A blank miproblema request form area is shown here in Figure 5-8:
A blank problema request form area is shown in Figure 5-9:
The request form area for suproblema has certain extra fields dealing with outside vendor forwarding and technical description, as shown here in Figure 5-10:
In all of the problema interfaces, fields change colors and take on highlighting according to your current operation. If a field has a red border, it is required to be completed before the operation can be applied. Fields may also have a red border if they are incorrectly entered. In either case, a highlighted field blocks the operation. If a field is the same color as the window background color, then it is writable, but optional. If the field turns black, it is not writable during this operation.
To display a popup menu containing options for any field, hold down the right mouse button while the cursor is over the field. At minimum, the menu contains the items Reuse (for using the last value displayed in this field), Revert (for returning to the saved value), and Clear (for blanking out the field). If predefined values are available for the field, they are displayed on the cascading menu attached to the Values item. The cascading menu features a tear-off perforation at the top. If you click the perforation, the menu is displayed in its own window.
The menu for fields that accept long text descriptions such as the Description and Resolution fields have an option called Edit... that lets you enter the text through your editor of choice. The editor default depends on your environment variable setting and defaults to vi(1) if no variables are set. See “Setting the Default Field Editor” for more information.
The History of Changes field is automatically updated by problema each time an action is taken on a request.
The problema software provides a wide variety of date input formats. Dates can be supplied with as little information as the year or month, or specified to the nearest second.
Special formats allow dates to be supplied as a base time point plus or minus a time interval, and also as relative to the current year, month, day, hour or second. Date field values specify a point in time to the nearest second. You cannot, however, represent a time interval such as `'in six seconds'' or `'in two days.''
Date values are ordered from a starting point (the lowest value) and increasing toward later dates. Therefore, a date that occurs after a specified date will have a higher value. This enables you to use comparison operators such as < (before) and > (after).
When you use dates in transitions, you always enter a specific point in time. When you are using dates in queries, you can enter a range or condition as well as a specific time.
Setting a date and time in problema is handled in the same manner as CASEVision/Tracker, and Chapter 3 of the CASEVision/Tracker User's Guide offers a complete explanation of all date and time functions.
To query the problema database, perform the following steps:
Select Query from the Modes menu if it is not already selected. All fields in the window become writable.
Enter the desired selection criteria in the appropriate fields.
Click the apply command button to perform your query. All appropriate requests appear in summary form in the query results area.
Leaving all fields blank brings all requests in the database into the list, with the first few displayed in the query results portion of the window. Entering one or more fields displays those requests with matching fields. Entering multiple fields has the effect of selecting only those requests that match all listed criteria. You can also use the operators in Table 5-1 to refine your queries. When you use these operators, you should enclose all values inside quotation marks (““).
Operator
Description
=range entry
equal to
<>
not equal to
<
less than
<=
less than or equal to
>
greater than
>=
greater than or equal to
=match
regular expression match
contains
contains specified value (list fields only)
contains any
contains any of the specified values (list fields only)
contains only
contains only the specified values (list fields only)
= null
unset or non-existent test
<> null
set or existing test
[startrange:endrange]
range entry
The less-than (<) and greater-than (>) operators can be used with dates to mean before and after, respectively. For example, >June 25 means after June 25.
To display the detailed information for any request in the query results area, you can double-click the request directly, or you can click one of the list control buttons: First, Next, Prev, and Last.
When you display a request, a small rectangular icon appears to the left of the request line in the query results area. If you modify the request, a check mark will appear next to the request as well. If you make a subsequent query, the icons will be cleared.
All user operations can be performed from miproblema or problema, and all information in the database can be viewed from problema.
For most problema operations, follow these steps:
Enter the command
problema
to invoke the application. The problema window is displayed.
Select the desired command from the Modes menu in the control bar. The problema window immediately enters the selected mode for performing the command. Note that the command is not executed until you click the apply command button, which is to the right of the Cancel button in the control bar. Depending on the command selected, the window makes these changes:
Fields become writable or read-only.
The command name now appears on the Modes menu button and on the apply command button.
All fields required for the command are highlighted in red.
Fill in the request form fields with the appropriate information. Remember that holding down the right mouse button displays a menu with some or all of these items:
Values Lets you select any valid predefined value.
Clear Clears the field.
Reuse Inserts the value from the previous request (if any).
Revert Restores the original value of the field for that request.
As the required fields are entered, the highlight disappears. If a field is entered incorrectly, according to the rules for that field, it remains highlighted and must be corrected for the transition to take place. If you don't know the field's requirements, check online help.
Click the apply command button to perform the operation.
Note that the apply command button is sensitive only when all required fields are filled in. Clicking the button performs the operation and changes the window and database (if affected) accordingly. Any default fields are filled in automatically. The command mode may change as well; for example, after a query, the window switches to display mode.
In addition, e-mail notifications are made to the owner, project manager, submitter, and any other parties indicated in the Notify field. The general format for a “SUBMIT_REQUEST” notification is:
Field czar set to: root. Field category set to: Backup. Field ENTITY_ID set to: 8. Field STATE set to: AWAITING_RESPONSE. Field summary set to: I'd like to schedule regular backups of my /work file system.. Field bboard set to: root. Field last_update set to: Thu Jul 7 16:24:53 PDT 1994. Field due_date set to: Tue Jul 12 16:24:45 PDT 1994. Field submit_date set to: Thu Jul 7 16:24:45 PDT 1994. Field submitter set to: grant. Field notify_list set to: (root, grant). New value of history: ========== Date: Mon Jul 04 16:24:53 1994 User: grant@vicksburg ========== SUBMIT_REQUEST New value of description: I'd like to schedule regular backups of my /work file system. TRANSITION = SUBMIT_REQUEST EXECUTING /bin/true
From problema, select SUBMIT_REQUEST from the Modes menu on the control bar.
The window makes these changes:
The Report # and Status fields turn read-only, since these are set automatically by the system.
The Description field is highlighted in red, indicating that it is required.
The apply command button changes to read SUBMIT_REQUEST, although the button is not yet enabled.
Fill in the Description field, which is required, and any other fields needed to provide as much request information as possible.
After you make an entry in the Description field and move the cursor out of it, the highlighting is removed. At this point, the apply command and Cancel buttons are enabled, since you have fulfilled the Description requirement. Click the apply command button to submit your request.
Use one of the following methods to set your default editor for fields in any problema interface:
The environment variable $WINEDITOR (for editors like jot(1) that bring up their own windows).
The environment variable $EDITOR (for editors like vi(1) that do not supply their own windows).
The editorCommand setting in your home directory's .Xdefaults file.
If none of these are set, the editor defaults to vi(1).
Each new request should be reviewed using suproblema on the problema server, and resolved, deferred, or assigned to an owner. When the assigned requests have been fulfilled by their owners, they are closed (with the RESOLVE command) on the server.
The following options are available only from the suproblema Modes menu:
FORWARD_TO_VENDOR
ASSIGN
DEFER
DUPLICATE
DELETE
Only authorized users can screen requests. The authorized users are specified in the “suproblema.pdl” file. You begin screening by querying and displaying requests, and you can then apply different transitions after the selected request displays.
Screening requests follows all the steps mentioned in the section “Procedure for Performing General Operations”. The difference is that you deal only with requests in the AWAITING_RESPONSE state.
The screener has three transition commands for turning down requests:
| DEFER | If work on the request is to be performed at a later date. This requires an entry in the Reopen Date field. When this command is used, problema automatically reopens the request on the specified date, switching its status from CLOSED to AWAITING_RESPONSE. | |
| DUPLICATE | A request on the same topic has been previously submitted. | |
| RESOLVE | The request has already been performed or is moot. |
The ASSIGN command lets the screener specify the owner who will be executing the request. The ASSIGN command requires that the Owner field be changed.
The FORWARD_TO_VENDOR command indicates that the problem has been forwarded to an outside vendor of hardware or software for further action.
To automatically forward requests to Silicon Graphics, you must be an authorized Silicon Graphics Support Advantage customer, and you must have the electronic services package installed on your problema server. If these services are installed, problema uses the /usr/IRIXpro/lib/problematoes script to contact Silicon Graphics when the FORWARD_TO_VENDOR action is taken and Silicon Graphics is the specified vendor.
When forwarding and updating requests, the user performing the actions is expected to be irixpro. See “The User irixpro” for more information. This operation is synchronous, which means that suproblema waits on the request until it returns from Silicon Graphics or until the request action fails.
When forwarding requests, the key field is the Technical Description field. All pertinent information must be listed in this field.
After a request has been assigned, it is turned over to the owner for implementation. (If the owner performed the assignment, there is no turnover.) In addition to new requests, the owner may receive rejected resolutions (REOPEN requests). The owner then performs the requested work and when finished, closes the request by making a RESOLVE transition.
To resolve an existing request, you first have to bring it up with a query, as discussed in “Query Operations”.
When the request is displayed, perform these steps:
Select RESOLVE from the Modes menu. The Resolution field is highlighted.
Enter the explanation of the fix in the Resolution field.
Click the apply command button, which now reads RESOLVE. The status changes from AWAITING_RESPONSE to CLOSED.
If your database is growing too large for convenient use, you can use the DELETE command to mark closed requests for deletion. The deletion itself can be carried out any time at the administrator's convenience through the use of the script: /usr/IRIXpro/sample/problema/problemaDBclean. This script is designed to be run as a job in a non-peak use time through the cron(1) utility. It is suggested, however, that you make an archive copy of your database before deleting any closed requests. You can also use the delete operation to mark duplicate requests or mistaken requests that have been closed. The DELETE transition works only on requests with a CLOSED status.
You must be logged in as the user irixpro to perform DELETE transitions. See the section in this chapter titled “The User irixpro” for complete information on creating the user irixpro. Note that you cannot simply use the command:
su irixpro |
to log yourself in momentarily as irixpro to perform this transition. You must use one of the following commands:
su - irixpro |
or
login irixpro |
Each request submitted with any problema interface receives an automatic due date by which it is expected to be closed. The script /usr/IRIXpro/sample/problemaDBdue generates a list of these overdue requests. This script is designed to be run as a job in a non-peak use time through the cron(1) utility. You must be logged in as the user irixpro to use this script. See the instructions in the section titled “Deleting Requests” for more information on logging in as irixpro and the section titled “The User irixpro” for more information on creating the irixpro user account.