Hardware requirements include real storage, DASD space, tape, and display terminals.
The database manager itself does not require any real storage. However, if more real storage is available, there is less paging, thus improving performance.
The VSE guest sharing facility requires 40 kilobytes of real storage for each database communication link.
The DASD space requirements for the virtual machines are discussed below.
You no longer install and service DB2 Server for VM strictly using the MAINT user ID. You should use the user ID, 5697F42S. You can change this user ID, however, by creating a PPF override. See the DB2 Server for VM Program Directory for more information.
See the DB2 Server for VM Program Directory for the recommended DASD sizes for the installation user ID machine and initial installation, migration, and service instructions.
A database machine requires two kinds of minidisks: system minidisks and database minidisks.
A database machine must have read/write access to its own work minidisk (A-disk). In addition, it must be able to access the DB2 Server for VM production and service minidisks. Collectively, these three minidisks are referred to as the system minidisks. The system minidisks can be optionally installed in shared file system (SFS) directories with default names of VMSYS:SQLMACH, VMSYS:SQLMACH.SQL.PRODUCTION and VMSYS:SQLMACH.SQL.SERVICE. From now on, any reference to the service or production minidisk can be replaced by these directories.
The work minidisk is required because the database manager does various operations that require space temporarily.
The production minidisk contains IBM-supplied EXECs and programs that are required for day-to-day use of the database manager. The production minidisk defines an entire DB2 Server for VM environment, and contains all the CMS files that enable database machines to access databases. It also contains CMS files that allow users to access a database with a given database machine. The CMS files determine the default application server and thus the database a user can access. Users can access other database machines and thus other databases by database switching.
The DB2 Server for VM LOADLIB resides on the production minidisk. Every virtual machine must have read access to the production minidisk in order to access the database manager.
The service minidisk also contains IBM-supplied EXECs and programs, but it needs to be accessed only during installation, database generation, migration, maintenance or system administration activities.
Usually, all database machines use the same production and service minidisks. Thus, they can be defined once for the entire installation. You can define more than one production minidisk as your installation grows. Multiple production minidisks are convenient when you have many database machines that often perform administrative tasks. If you define a second production minidisk, you create a second DB2 Server for VM environment. This environment has its own users, its own database machines, and its own databases. It is independent of any other DB2 Server for VM environment that is defined by any other production minidisk. More specific information is in Chapter 12, Planning and Implementing Configurations. In planning your initial installation, assume there will be only one production minidisk and one service minidisk.
Initially, there is only one database machine, SQLMACH. Thus, for installation, you need to be concerned only with the size of the work minidisk for that initial database machine. The installation process makes SQLMACH the owner of the production and service minidisks.
See the DB2 Server for VM Program Directory for the recommended database machine DASD sizes for the service minidisks and production minidisks.
A service minidisk must contain only IBM-supplied files: it must not contain any user-created files. The IBM-supplied service minidisk files are documented in the DB2 Server for VM Program Directory.
The production minidisk may contain user files, but it must contain all the IBM-supplied files. The IBM-supplied production minidisk files are documented in the DB2 Server for VM Program Directory. The space allocations shown for the production minidisk reflect the requirements for the IBM-supplied files plus approximately 30% free space.
The service minidisk allocation for non-English versions of the HELP text is described in the program directory supplied with the non-English HELP text distribution tape. The allocations documented in the DB2 Server for VM Program Directory include space for the English version of the HELP text.
The service minidisk is referred to as the SQLMACH 193 minidisk, but can be defined with any valid user ID and virtual address. Similarly, although the production minidisk is referred to as the SQLMACH 195 minidisk, you can use any valid user ID and virtual device address. The same virtual machine must own both the service and production minidisks. When migrating from a previous release of the database manager, another user ID and virtual device address can be used for the production minidisk for testing. If you have not used a previous release of the database manager, you should use the user ID SQLMACH and the 193 and 195 virtual device addresses as described in the DB2 Server for VM Program Directory.
Minidisk requirements for a database machine vary based on the number and size of databases defined on it. Each database has a minimum minidisk storage requirement. A database requires a minimum of three VM minidisks, but a typical database has several more. The minidisk requirements are summarized below:
The directory, log and database extents minidisks cannot be in CMS shared file system directories.
The directory and log minidisks are discussed further in Chapter 2, Planning for Database Generation. Dbextent minidisks are discussed in greater detail in Chapter 7, Managing Database Storage.
The ARISDBG MACRO, which comes with this product, contains IBM-supplied specifications for generating a starter database. This database consists of one directory minidisk, one log minidisk, and one data minidisk. You can later add more dbextents, up to a logical maximum size of about 4.6 gigabytes, using the information in Adding Dbextents to a Storage Pool.
You should generate the starter database at the time of initial installation and experiment with it in order to familiarize yourself with the database manager. You may then keep it as your production database. However, as your needs grow, you may find it necessary to transfer its contents to another database, which can be a major undertaking. Thus, once you are familiar with how it works, it is best to discard the starter database and generate your own database by following the guidelines in Chapter 2, Planning for Database Generation.
The initial physical size of the starter database is predefined and will be about the same on all IBM storage devices. See the DB2 Server for VM Program Directory for the recommended DASD sizes for the starter database.
This starter database must be able to fit in a single dbextent. If you do not have enough DASD, you will not be able to use the IBM-supplied specifications, and will have to generate your own database at the time of installation. If you want to define the equivalent of the starter database on the devices, you must define multiple dbextents on multiple volumes.
If you are migrating from a previous release of the database manager, you already have at least one database, so generating the starter database is optional. The advantage of doing so is that you can use it as a test database to verify your installation, but the disadvantages are the work involved and the necessary DASD allocations. Thus to deal with migration needs, the database manager provides allocations for generating a starter database that is large enough to hold the initial database components (for example, HELP text, catalog tables, and FORTRAN packages), but not much else. The DB2 Server for VM Program Directory also shows the minidisk sizes for a minimum starter database.
The service machine must have read/write access to its own work minidisk (A-disk). In addition, it must be able to access the production and service minidisks. For more information see System Minidisks.
If you only have a service machine on a processor and intend to access a database manager (defined as a global resource) in another processor, the code that is installed on your local processor is known as the service machine. If you install the service machine, you do not need a database machine. See the DB2 Server for VM Program Directory for the recommended DASD sizes for the service machine.
During installation, it is recommended that one virtual machine be defined as a user machine. A user machine also requires a 191 minidisk (A-disk, formatted at the 1024 byte block size with free space equivalent to at least 3 cylinders of an IBM 3380 storage device). The user machine 191 disk can optionally be installed in a CMS shared file system directory. See the DB2 Server for VM Program Directory for the recommended DASD sizes for the user machine. After initial installation, you will probably want to define many user machines.
One tape drive is required for installation. Depending on the DB2 Server for VM facilities you use, you may need tape drives after installation. Tape processing can be used for the following activities:
For all of these facilities except archiving, you can use DASD instead of tape.
Also, with the exception of accounting output, the database manager does not require the continuous use of any tape drive: tape mounts are requested when needed. If you are using tape drives, you should have at least two to cover all your needs.
The database manager supports all tape drives that are supported by the operating system.
A variety of display terminals are supported, including the larger screen sizes offered by some models of the 3278 and 3279 (or equivalent) devices. Since the database manager relies on CP (control program) and CMS to provide terminal support for DB2 Server for VSE online applications, the terminal must be one that is supported by CMS.
You can direct ISQL-printed output to any printer supported by the Remote Spooling Communications Subsystem (RSCS). Use CP SPOOL and TAG commands to change the routing of the print output.
| Note: | To display and print DBCS characters (for example, Japanese HELP text), a DBCS terminal and printer (for example, the IBM 5550 terminal) are required. |