Order Number: SWRK-UG-35
This manual describes and provides general information on what SysWorks does and how to use it.
Revision/Update Information: This manual supercedes the SysWorkstm V3.4-1 User Guide
Operation System and Version:
OpenVMS VAX V7.2 or higher;
OpenVMS Alpha V7.2 or higher;
DECwindows/Motif V1.2-3 or higher
Software Version: SysWorkstm V3.5
Printed in Australia
The following are trademarks of Compaq Computer Corporation: ACMS, ALL-IN-1, AXP, BASIC, Bookreader, CDA, CI, DATATRIEVE, DBMS, DDIF, DEC, DEC ACCESSWORKS, DEC Ada, DEC C, DEC Fortran, DEC Pascal, DECdecision, DECdesign, DECdirect, DECdns, DECdocument, DECdtm, DECforms, DECimage, DECintact, DECmigrate, DECnet, DECnet/OSI, DECset, DECsupport, DECtp, DECwindows, Digital, DTIF, EDT, HSC, MASSBUS, MicroVAX, MicroVAX II, MSCP, OpenVMS, OpenVMS Cluster, RA, StorageWorks, TA, TMSCP, TURBOchannel, ULTRIX, VAX, VAX C, VAX MACRO, VAX-11/780, VAXcluster, VAXELN, VAXft, VAXstation, VIDA, VMS, VMScluster, VT100, and the DIGITAL logo.
PostScript is a registered trademark of Adobe Systems Inc.
Motif is a registered trademark of Open Software Foundation, Inc.
Oracle is a registered trademark, and Oracle CDD/Repository, Oracle CODASYL DBMS, Oracle Expert, Oracle Rally, Oracle Rdb, Oracle Trace and Rdb7 are trademarks of Oracle Corporation.
OSI is a registered trademark of CA Management, Inc
All other trademarks and registered trademarks are the property of their respective holders.
This document was prepared using DECdocument V3.3.
| Contents | Index |
We welcome your comments on this manual or any SysWorks manual. If you have suggestions for improvements or find any errors, please indicate the chapter, section and page number (if available). Your input is valuable in improving future releases of our documentation.
You can send comments to us in the following ways:
SysWorks Corpita Pty Ltd 15 Bedford Street Collingwood VIC 3066 Australia |
This manual describes and provides general information on what SysWorkstm does and how to use it.
This manual is intended for SysWorkstm users who have a working knowledge of the underlying Digital products.
The following conventions are used in this document:
| Conventions | Description |
|---|---|
| [Ctrl/X] | A sequence such as [Ctrl/X] indicates that you must hold down the key labeled [Ctrl] while you press another key or a pointing device button. |
| [] |
In format descriptions, brackets indicate that whatever is enclosed is
optional; you can select none, one or all of the choices.
In system prompts indicates the default value which will be assumed if the Return key is pressed without first entering a value. |
| {} | In format descriptions, braces surround a required choice of options; you must choose one of the options listed. |
| | | In format descriptions, vertical bars separate the options. If the options are enclosed in brackets (i.e. []) you can select none, one or all of the choices. If the options are enclosed in braces (i.e. {}) you must choose one of the options listed. |
| () | In system prompts, parenthesis indicate the list of values one of which may be entered. The values are separated by a forward slash "/" |
| ... | An elipsis indicates that a value within a range may be chosen or a syntax repeated. A range may be indicated by a pair of end values, or an end value and an end keyword. For example Disk quota (0..unlimited) indicates that the keyword unlimited may be used to represent the highest possible disk quota. |
| italic text | Italicized words and letters indicate that you should substitute a word or value of your choice. |
| UPPERCASE TEXT | Uppercase letters indicate the name of a command or routine. |
| monospace text | Normal monospace text indicates system prompts and output. |
| bold monospace text | Bold monospace text indicates user responses to system prompts. |
| bold monospace italic text | Bold monospace italic text indicates user responses to system prompts which need approriate value substitution. |
| mouse | The term mouse is used to refer to any pointing device such as a mouse, a puck or a stylus. |
| MB1, MB2, MB3 | MB1 indicates the left mouse button, MB2 indicates the middle mouse button, and MB3 indicates the right mouse button. (The buttons can be redefined by the user.) |
Unless otherwise noted, all numeric values are represented in decimal notation.
This chapter gives an introduction to the main concepts in the
SysWorkstm product set.
1.1 Overview of SysWorkstm
The SysWorkstm product set is designed to manage all sizes of OpenVMS networks. This is achieved by providing a layer of software above the traditional Digital and other third party OpenVMS system management utilities. The core of SysWorkstm registers users, applications, terminals etc. in a database. These users, applications, terminals etc. are referred to as meta objects. Each of the management procedures are referred to as tasks, and these can be accessed from DCL, menus and windows. After management, SysWorkstm performs the associated OpenVMS actions to manage them.
Features of the SysWorkstm product set include:
In large sites it allows central and decentralized control of the network and consistency of system management.
In small sites it reduces the need for system managers to be involved in day to day activities such as registering users.
For application developers, it provides an application architecture, and removes the need to develop application code to make an OpenVMS system turnkey.
The product provides a large set of management tasks which operate on a
set of meta objects that exist within the network.
1.2 Meta objects
The entities managed by SysWorkstm are called meta objects.
Each meta object has a set of attributes and associations to other meta
objects. Some meta objects represent physical things or data while
others represent actions or code. See SysWorkstm Object
Model Glossary for a detailed description of all meta objects.
1.3 License Level
SysWorkstm is provided at four license levels. These are:
This product is designed to assist in the development of well built applications. I
This product is designed to assist in the development of well built applications. It provides a set of tools and enhancements to Digital products which help achieve this aim. See the SysWorkstm Developer Software Product Description (SPD) for more details. If the SysWorkstm Administrator product is not also installed, site specific procedures are required to bind developers to SysWorkstm Developer.
This product is designed to assist system and network administrators and managers perform their OpenVMS activities. See the SysWorkstm Administrator Software Product Description (SPD) for more details.
This product is designed to provide a turnkey OpenVMS system base. It
provides a model from which users, developers, and system and network
administrators and managers may perform their activities with minimal
direct OpenVMS interaction. See the SysWorkstm Turnkey
Software Product Description (SPD) for more details.
1.4 Installation Level
SysWorkstm supports four installation levels. These are:
The SysWorkstm software is installed in a nominated root. There is no startup procedure. A site specific interface procedure is required to execute the SysWorkstm SYLOGIN.COM procedure from within developers LOGIN.COM procedures. From version 2.5 of SysWorkstm, private installations are no longer supported.
The SysWorkstm software is installed in the system common area. The SWRK_STARTUP.COM procedure is placed in the SYS$STARTUP area, and should be invoked in the system startup procedures. System wide logicals are defined, and images are installed as shareable. The only image installed with privileges is the SWRK_LNT_INTERFACE.EXE image so that user logical name tables may be created when required at login time. Each developer still needs to execute the SysWorkstm SYLOGIN.COM procedure in their LOGIN.COM procedures. A site login or startup procedure is also required to supply logical names such as disk roots which would be supplied by SysWorkstm if it was installed as a higher level.
The SysWorkstm software is installed as for the public level. Additionally, a privileged OpenVMS username is registered to act as a network server. The SWRK_STARTUP.COM procedure installs more images with privileges in order to assist the network server. This is the minimum installation level at which the SysWorkstm Administrator license will function. Each user still needs to execute the SysWorkstm SYLOGIN.COM in their LOGIN.COM procedure. Alternatively, the system wide SYLOGIN.COM procedure in the SYS$MANAGER area may invoke the SysWorkstm procedure.
The SysWorkstm software is installed as for the system
level. Additionally the various system startup procedures in the
SYS$MANAGER area such as SYCONFIG.COM, SYLOGIN.COM etc are replaced.
This is the minimum installation level required for the
SysWorkstm Turnkey license. Esentially SysWorkstm
Turnkey will take over management of the OpenVMS system.
1.5 Components
This section describes the various components available with the SysWorkstm product set. After each heading is the minimum license level required to use that component.
The optional change control sub-system provides facilities to manage the extended definitions of application software versions and their installation into application environments. The sub-system manages the migration of software through the various development and testing environments and on into production. This sub-system uses the DECset products CMS, DTM, MMS and SCA when they are available. It replaces the basic change control facilities provided with the development tools.
The development tools provide a layer above the various OpenVMS layered products such as CMS, LSE, MMS etc. It also provides basic change control facilities such as migrating from development to test to production when the change control sub-system is not present.
The information core provides a set of management tasks used to manage the majority of meta objects such as users, applications, disks etc. The facilities provided form a layer above the Digital supplied system management tools such as AUTHORIZE, and remove the need for a privileged user to use these command driven utilities for day-to-day standard tasks such as registering a user.
A basic menu system is provided at all license levels. However, some sites may wish to use a more advanced, flexible, user or developer maintained menu system. The optional extended menu sub-system provides extensive and sophisticated menuing for DCL command procedures, images, and ACMS applications.
Supplied with the information core, but not necessarily turned on is the security sub-system. This consists of a set of jobs which checks specific security areas. These jobs are automatically run at intervals betwen one minute to one month. Most can also be requested manually.
Supplied with the information core, but not necessarily turned on is the startup sub-system. This enhances the basic information core task by adding tasks to manage the startup of nodes. Again, this is achieved by providing a layer above the Digital supplied tools, in this case SYSMAN and LICENSE.
The optional storage sub-system provides facilities to manage the offline storage of meta objects. A full cross-reference is maintained so that data may be retrieved by whichever path is appropriate to the user.
This section describes the six layer network model used by at and abone the SysWorkstm Administrator license level. This model consits of a hierarchy of six levels which are:
Meta objects that need to be recognised network wide such as security domains, clusters, tuning domains and nodes are registered at the Network level.
Most meta objects such as users and applications are defined at the
Security Domain level and then created at the Cluster level. This
ensures consistency of such things as OpenVMS usernames, UIC's and
identifiers.
2.1 Network
At the network level, only a few meta objects are defined. The network
has a network master node on which the network meta object definitions
are stored. The network master node may send information to the
security domains. The security domains may request meta object
information from the network master. A network master node is normally
the security domain master node of the security domain to which it
belongs.
2.2 Security Domain
At the security domain level, most meta objects are defined. Each
security domain has a security domain master node on which the security
domains meta object definitions are stored. The security domain master
node may force actions on its sub-ordinate sites, and these sites may
request meta object information downloads from the security domain
master. A security domain master node is normally the site master node
of the site to which it belongs.
2.3 Site
At the site level, meta objects such printers and time zones are
defined. Each site has a site master node on which the sites meta
object definitions are stored. The site master node may force actiolns
on its sub-ordinate clusters, and these clusters may request meta
object information downloads form the site master. A site master node
is normally a cluster alias respondant within the cluster to which it
belongs.
2.4 Cluster
At the cluster level, the meta object takes on static physical
attributes such as a UAF entry, MAIL profile, identifiers, disk
directories etc. Boots nodes within the cluster are normally cluster
alias respondants. Satellite nodes do not normally respond to the
cluster alias. Note that a single node cluster does not have a cluster
alias, and the cluster name and node name registered on the network
level are the same.
2.5 Tuning Domain
A tuning domain is a set of nodes within a cluster which require
similar tuning or security modeling. For example, all the workstations
in a cluster may be in one tuning domain, and all the servers in
another. At the tuning domain level, a system object may receive
additional cluster level attributes. This is used to allow non
homogenous clusters to be correctly tuned for performance and security.
2.6 Node
At the node level, the meta objects take on dynamic attributes such as logical name tables, process etc. All nodes within a cluster that respond to the cluster alias may be used to control nodes within the cluster or maintain the cluster definitions of system objects. Such nodes may request information from the security domain master node.
| Next | Contents | Index |