You can define database manager components in saved segments. This can be done after you have installed the product. Saved segments allow code to be shared among users. Code that is not in saved segments runs in the user free storage area of the user machine and database machine.
Code can be loaded into the following saved segments:
The resource adapter saved segment may contain the code for the following components:
The DRRM and CONV components are only applicable if the DRDA code is installed.
The resource adapter segment can be saved above 16M.
The DBSS saved segment contains the code for the following components:
The DBSS segment must be saved below 16M.
The RDS saved segment may contain the code for the following components:
The DRRM and WUM components are only applicable if the DRDA code is installed.
The RDS Segment can be saved above 16M. This includes the WUM, DRRM and CONV components. If RDS is saved above 16M, the "AMODE(24)" initialization parameter CANNOT be used. If "AMODE(24)" is specified with the RDS Segment defined above 16M (or if RDS is loaded into free storage above 16M), message ARI0021I is issued and start up fails. If you must use the "AMODE(24)" parameter, you must create an alternative bootstrap package which specifies an RDS segment that is saved below 16M. If RDS is not used in a saved segment, and "AMODE(24)" is required, you must define the virtual machine storage to 16M or less, to prevent RDS from being loaded above 16M.
The ISQL saved segment contains the ISQL code. It must be saved below 16M.
This saved segment contains the code for the message repository. It must be saved below 16M.
Notes:
Use the VMFSGMAP EXEC, which uses the VM/ESA CP DEFSEG command, to define each component in a saved segment. After defining the saved segments you must load them (using the VMFBLD EXEC, which uses the ARISAVES EXEC), and create a bootstrap package to use them (using the SQLGENLD EXEC). If you choose to have ARISAVES create the default (SQLDBA) bootstrap package, it is not necessary to run SQLGENLD.
In any bootstrap package there can be three bootstrap modules that correspond to the following components:
The bootstraps identify where the components reside. Only one bootstrap module is needed for the DBSS and RDS components. Because the DBSS and RDS components must both reside in saved segments or both reside in user free storage, only one module is needed to indicate the location of the code. (The DBSS and RDS code is often referred to as the DB2 Server for VM system code.) For a service machine, only the bootstrap modules for the resource adapter and ISQL need to be generated.
Each set of saved segments defined for the database manager usually has three bootstrap modules. (Typically, only one set of saved segments is defined for the code at an installation.) The bootstrap modules identify the corresponding saved segments. The database manager requires bootstrap modules for every saved segment except national language message repositories. National language message repository saved segments are identified in the ARISNLSC MACRO.
The bootstrap modules allow the database manager to use the code residing in the saved segments. The SQLBOOTS EXEC generates the appropriate bootstrap modules (the SQLDBA bootstrap package) for default saved segments. If you respond YES when the ARISAVES EXEC prompts you to use the saved segments you are loading as defaults, ARISAVES calls SQLBOOTS to create the SQLDBA bootstrap package. This bootstrap package specifies whether the database manager code runs as a default in saved segments or not. If not, the code runs in the user free storage area. ISQL and the resource adapter run in the user free storage area of the user machines, and the system code runs in the user free storage area of the database machines. Also, the resource adapter runs in the user free area of the database machine when in single user mode. To create other bootstrap packages, you use the SQLGENLD EXEC. You name the bootstrap package when you use SQLGENLD to create it. For more information on the SQLGENLD EXEC and the SQLBOOTS EXEC, see Defining Saved Segments.
Even though you have defined one or more saved segments for the database manager, they are used only in the following situations:
If you omit the DCSSID parameter after defining additional bootstrap packages, the default rules are more complex. They are even more complex when you do not define all bootstrap modules in a bootstrap package. (Consider doing this if, for example, you want the system code to run in special saved segments, but want ISQL and the resource adapter to run in default saved segments.) The following sections describe the default rules.
If you want to keep things simple, define only one set of saved segments and generate three bootstrap modules. This is what is done for default saved segments. If you choose to have default saved segments, you define them, and the database manager creates a bootstrap package for them. If you have default saved segments, they are used when your users run EXECs without specifying the DCSSID parameter. This way, you always easily know where the database manager code is running. For an example of defining saved segments and generating bootstraps, see Defining Saved Segments.
Even if you have default saved segments, you should still define saved segments for national language messages that you expect to use. A default saved segment is not generated for national language messages. For more information, see Defining Message Repositories as Saved Segments.
You may want to define multiple saved segments for the database manager code. (For example, you want to run the code at different locations.) The above guideline still applies: if possible, generate all three bootstraps, and provide the users with specific instructions for DCSSID parameters.
For a service machine, you only need to generate the bootstrap modules for RA and ISQL. The DBSS and RDS code cannot run from a service machine.
If you need more details on the way bootstraps work, continue reading. If not, skip the rest of this section.
The bootstrap module identifies the name of the saved segment to be loaded into storage at run time. In addition, the bootstrap module for the resource adapter also contains the name of the database machine. This name is required to establish the communication link in multiple user mode. In a VM/ESA operating system, you do not need to specify the name of the database machine because APPC/VM is used for communication: only the RESID (resource) is needed. After installation, there is one bootstrap package made up of the following CMS files:
SQLDBA SQLDBBT Q -- corresponds to the DB2 Server for VM system code
(not generated for a service machine)
SQLDBA SQLISBT Q -- corresponds to the ISQL code
SQLDBA SQLRMBT Q -- corresponds to the resource adapter code
The files are created at installation time and reside on the production minidisk. Collectively, they form the SQLDBA bootstrap package.
When you run the SQLGENLD EXEC to create a bootstrap package, you are prompted for the name to be specified in the DCSSID parameter and the name (or names) of the saved segment (or saved segments). The name to be specified in the DCSSID parameter is used to identify the bootstrap package. For example, if you generate a bootstrap package with the name MYBOOT for the system code, ISQL, and the resource adapter, these files are created on the production minidisk:
MYBOOT SQLDBBT -- DB2 Server for VM system code bootstrap module MYBOOT SQLISBT -- ISQL bootstrap module MYBOOT SQLRMBT -- resource adapter bootstrap module
When you run the SQLSTART EXEC, the bootstrap for the system code and resource adapter are copied to the A-disk of the database machine. (Because you can run the database manager in single user mode, and it cannot determine the mode you will use, the resource adapter bootstrap is always copied.) Assume that you issue the following command, and DBNAME and RESID are the same:
SQLSTART DBNAME(TEST1) DCSSID(MYBOOT) ...
The file TEST1 SQLDBN is either created or updated at this time, with the following information:
DBMACHID = name of the database machine DCSSID = MYBOOT DBNAME = TEST1
When you run the SQLINIT EXEC for the user machine, the bootstraps for ISQL and the resource adapter are copied to the A-disk of the user machine. Assume that you issue the following command:
SQLINIT DBNAME(TEST1) DCSSID(MYBOOT)
During processing, the resource adapter bootstrap is recreated with the name of the database machine. The TEST1 SQLDBN file is read to obtain the name of the database machine. This means you must have used the SQLSTART EXEC (or the SQLDBINS EXEC) to create the SQLDBN file for the database machine.
The resid SQLDBN file, containing the default DCSSID, cannot always be accessed; therefore, the default DCSSID in this file cannot be used. A user machine cannot access the resid SQLDBN file on a database machine in either of the following situations:
You must create a new file (SQLDCSID DEFAULT) on the production (Q) disk that is linked by these user machines to provide a default DCSSID for them. This file is created when the SQLGENLD EXEC is run. The SQLGENLD EXEC generates the bootstrap package for a particular saved segment. The EXEC prompts you to specify whether the DCSSID is to be the default for user machines that have a link to this Q-disk.
The following examples outline the above discussion. The examples assume that you have default saved segments identified in the SQLDBA bootstrap package.
Assume that you have created four saved segments (one for each of the following): the DBSS code, the RDS code, the ISQL code, and for the resource adapter code. (Also assume that you used the names SQLSQLDS for the DBSS/DSC, SQLXRDS for the RDS, SQLISQL for ISQL, and SQLRMGR for the resource adapter as the names of the saved segments.) You then used SQLGENLD to create the three bootstrap modules and identified this bootstrap package with the name MYBOOT. Assume that the name of the database machine is SQLMACH1 and that both DBNAME and RESID are TEST1. Until you specify the DCSSID parameter on the SQLSTART EXEC (or unless you provided it when you generated the database using the SQLDBINS EXEC), the code is loaded as specified by the SQLDBA bootstrap modules. The SQLDBN file has the following information:
DBMACHID = SQLMACH1 DCSSID = SQLDBA DBNAME = TEST1
If a user machine that is linked to the database machine Q-disk containing the TEST1 SQLDBN file runs the SQLINIT EXEC, that EXEC is called to use the SQLDBA bootstrap modules. Assume that you run the SQLINIT EXEC as follows:
SQLINIT DBNAME(TEST1) DCSSID(MYBOOT)
During processing, the bootstraps for ISQL and the resource adapter use the saved segments SQLISQL and SQLRMGR. These saved segments are used even though the database manager is using the default bootstrap modules.
When the SQLSTART EXEC (or SQLDBINS EXEC) has been run with the DCSSID parameter DCSSID(MYBOOT), the database manager uses the saved segments SQLSQLDS and SQLXRDS. The user only has to specify the DBNAME parameter on the SQLINIT EXEC, for example, SQLINIT DBNAME(TEST1), to use the SQLISQL and SQLRMGR code.
Assume you have created a second resource adapter saved segment named SQLRMGR2 using the bootstrap name RMBOOT2, and the environment has already been established to use MYBOOT as shown in Example 1. Also assume that DBNAME and RESID are the same, and that you start the application server as follows:
SQLSTART DBNAME(TEST1)
Notice that the DCSSID is not specified. The SQLSTART EXEC reads the TEST1 SQLDBN file and uses the MYBOOT bootstrap module to load the SQLSQLDS and SQLXRDS code into saved segments. In this situation, MYBOOT (rather than SQLDBA) has become the established default bootstrap package for server-name TEST1. When you run the SQLINIT EXEC specifying DCSSID (RMBOOT2) in a user machine that has a link to the Q-disk containing the TEST1 SQLDBN file, the bootstrap package exists for the resource adapter, but not for ISQL. For this example, run the SQLINIT EXEC as follows:
SQLINIT DBNAME(TEST1) DCSSID(RMBOOT2)
During processing, the SQLINIT EXEC regenerates a resource adapter bootstrap to load the saved segment named SQLRMGR2. Because it does not find a bootstrap identified by RMBOOT2 for ISQL, it reads the TEST1 SQLDBN file, finds the DCSSID=MYBOOT entry, and uses the bootstrap identified by MYBOOT for ISQL.
Assume that you have a second database (TEST2) that is owned by the SQLMACH2 database machine, and that the database has a bootstrap package (SQLBOOT2) for the DB2 Server for VM system code only. Also assume that DBNAME and RESID are the same.
The TEST2 SQLDBN file has the following entries:
DBMACHID = SQLMACH2 DCSSID = SQLBOOT2 DBNAME = TEST2
Suppose that you run the SQLINIT EXEC using the DCSSID of RMBOOT2, as shown in Example 2:
SQLINIT DBNAME(TEST2) DCSSID(RMBOOT2)
During processing the bootstrap package for the resource adapter exists and is created on the user's A-disk to communicate with the SQLMACH2 machine and server-name TEST2. If the SQLINIT EXEC does not find a bootstrap identified by RMBOOT2 for ISQL, or one identified by SQLBOOT2 (from TEST2 SQLDBN), or if the ARISISBT module is not found, it defaults to the SQLDBA ISQL bootstrap module.
| Note: | This example only applies to systems with multiple databases in which default saved segments are not used. |
Suppose you have users on a processor that does not have a database machine, and a service machine is defined as the owner of the Q-disk. You want the resource adapter and ISQL code to run in saved segments. When creating the bootstrap package (BOOTS), using the SQLGENLD EXEC, answer YES to the following prompt:
Do you want BOOTS to be the default DCSSID for user machines?
When you answer YES, a new file, SQLDCSID DEFAULT, is created on the production (Q) disk with the following entry:
DCSSID=BOOTS
If DBNAME and RESID are the same, and the users run the SQLINIT EXEC without specifying the DCSSID parameter, the DCSSID in the SQLDCSID DEFAULT file is used as the default. Assume that a user enters the following command:
SQLINIT DBNAME (TEST2)
During processing, the bootstrap package BOOTS (for the resource adapter and ISQL) is copied to the user's A-disk.
When a user runs the SQLINIT EXEC without specifying DCSSID (BOOTS), and you have not specified that BOOTS is to be the default DCSSID for user machines, the SQLDBA bootstrap package is used.
You should specify that the bootstrap package for the resource adapter and ISQL (BOOTS in this example) is the default DCSSID when you create the bootstrap package (BOOTS) with the SQLGENLD EXEC. Doing this ensures that user machines not having a link to the Q-disk that contains the SQLDBN file for the database machine that they are accessing will have a default DCSSID. These user machines then do not have to specify the DCSSID parameter.
Table 14 shows the saved segment usage by virtual machine.
Table 14. Saved Segment Usage by Virtual Machine
| Saved Segment | User Machine | Database Manager in Multiple User Mode | Database Manager in Single User Mode |
|---|---|---|---|
| ISQL | X | ||
| DBSS | X | X | |
| RDS | X | X | |
| RA | X | X | |
| DB2 Server for VM message repository | X | ||
| CMS DB2 Server for VM message repository | X | X | X |
It is possible to overlap saved segments that will not be used in the same machine. For example, in multiple user mode, the DBSS and RDS components are used only by the database machine, and ISQL and the resource adapter are used only by the user machine. Therefore, in multiple user mode, it is possible to overlay DBSS (or RDS) with ISQL (or the resource adapter).
| Note: | In single user mode, the resource adapter is used by the database machine, and must run in the same machine as DBSS and RDS, and therefore cannot overlap either RDS or DBSS. |
Table 15 shows the components that can overlap when they are being
run in multiple user mode only.
Table 15. Shared Segment Relationships in Multiple User Mode
| Component Name | Used By | Default SYSNAME | Segments This Component Can Overlap |
|---|---|---|---|
| Resource adapter | End users | SQLRMGR |
SQLXRDS SQLSQLDS |
| ISQL | End users | SQLISQL |
SQLXRDS SQLSQLDS |
| DBSS | Database manager | SQLSQLDS |
SQLRMGR SQLISQL LANGS001 |
| RDS | Database manager | SQLXRDS |
SQLRMGR SQLISQL LANGS001 |
| DB2 Server for VM Message Repository |
End users Database manager | LANGS001 |
SQLXRDS SQLSQLDS |
This section outlines the steps you must follow to put database manager code into saved segments. It is only a supplement to the information about defining saved segments in the manuals below. It assumes that you are familiar with saved segments and the procedures that must be followed to define them. For more information about saved segments, refer to the the VM/ESA: Planning and Administration manual.
To use saved segments for database manager component load modules, you must do the following:
This step does not need to be performed if you are creating or modifying default saved segments (that is the saved segments used by the SQLDBA bootstrap package). When you run ARISAVES for default saved segments, the database manager automatically creates a bootstrap package (SQLDBA) for you. If you are defining other saved segments, after you run ARISAVES, you must run SQLGENLD.
The following is an example of the process used to define saved segments for the components. With the VM/ESA operating system, you must define the segments with VMSES/E VMFSGMAP EXEC, which calls the DEFSEG command.
Before building and loading a DB2 Server for VM segment, you must obtain the following information:
Table 16. Sizes for Saved Segments (Base Code)
| segname | Segment Size in Kilobytes | DEFSEG Number of Pages (Segment Size / 4 Kilobytes) |
|---|---|---|
|
SQLRMGR LANGS001 SQLISQL SQLSQLDS SQLXRDS |
320 320 384 1536 2112 |
80 80 96 384 528 |
Table 17. Sizes for Saved Segments (DRDA)
| segname | Segment Size in Kilobytes | DEFSEG Number of Pages (Segment Size / 4 Kilobytes) |
|---|---|---|
|
SQLRMGR LANGS001 SQLISQL SQLSQLDS SQLXRDS |
2304 320 384 1536 3968 |
576 80 96 384 992 |
The address where a segment can be defined on your system is dependent on the locations of the other saved segments on your system. See your system programmer for assistance in determining origin values for the saved segments.
If you are going to save a segment in an address space where an old saved segment is located, you must first purge the old saved segment. See the VM/ESA: Planning and Administration manual for more information on defining and deleting segments with VMSES/E.
Log on to the installation user ID, 5697F42S.
To link and access the VMSES/E code and Software Inventory minidisks, enter the following commands. (You need R/W access to the Software Inventory minidisks.)
access 5e5 b link maint 51d 51d mr access 51d d
+----------------------Do these steps for each segment-----------------------+
Enter the following command to display the Segment Map panel, which displays information about the segments defined on your system:
vmfsgmap segbld esasegs segblist
Figure 64. Segment Map Panel Example
+--------------------------------------------------------------------------------+ | VMFSGMAP - Segment Map More: + | | Lines 1 to nn of nn | | | | 000-MB 001-MB 002-MB 003-MB | | Name Typ 0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF | |M CMS SYS W-W-------------1...............2...............3............... | |M GCS SYS W---------------1...............2...............3............... | | | | 004-MB 005-MB 006-MB 007-MB | | Name Typ 0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF | | CMSPIPES DCS 4...............5...............6...............RRRR------------ | |M GCS SYS RRRRRRNNNNNNNNNNNNNNNNNNNNNNNNNN6...............7............... | |M HLASM DCS 4...............5...............RRRRRRRRRRRRRRRR7............... | | | | 008-MB 009-MB 00A-MB 00B-MB | | Name Typ 0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF | | DOSBAM SPA 8...............9...............A...............====------------ | | CMSBAM MEM 8...............9...............A...............BRRR............ | | CMSDOS MEM 8...............9...............A...............R............... | | CMSVMLIB DCS RRRRRRRRRRRRRRRR9...............A...............B............... | | DOSINST DCS 8...............R---------------A...............B............... | | | | 00C-MB 00D-MB 00E-MB 00F-MB | | Name Typ 0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF | | HELPINST DCS RRRRRRRRRRRRRRRRD...............E...............F............... | |M CMS SYS C...............D...............RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR> | | | |================================= 16-MB Line ================================== | | | | 010-MB 011-MB 012-MB 013-MB | | F1=Help F2=Chk Obj F3=Exit F4=Chg Obj F5=File F6=Save | | F7=Bkwd F8=Fwd F9=Retrieve F10=Add Obj F11=Del Obj F12=Cancel | |====> _ | +--------------------------------------------------------------------------------+
To add segment definitions, press PF10 to display the Add Segment Definition panel. To change segment definitions, press PF4 to display the Change Segment Definition panel.
The following shows an example of the Add Segment Definition panel.
Figure 65. Add Segment Definition Panel Example
+--------------------------------------------------------------------------------+ | Add Segment Definition | | Lines 1 to nn of nn | | | | OBJNAME....: segname | | DEFPARMS...: | | SPACE......: | | TYPE.......: SEG | | OBJDESC....: | | OBJINFO....: | | GT_16MB....: NO | | DISKS......: | | SEGREQ.....: | | PRODID.....: 5697F42S compname | | BLDPARMS...: UNKNOWN | | | | | | | | | | | | | | | | F1=Help F2=Get Obj F3=Exit F4=Add Line F5=Map F6=Chk MEM | | F7=Bkwd F8=Fwd F9=Retrieve F10=Seginfo F11=Adj MEM F12=Cancel | |====> | +--------------------------------------------------------------------------------+
To obtain the DB2 Server for VM segment definitions, you must fill in the appropriate fields on the Add Segment Definition panel.
If you are building the NLS message repository segments, use the base prodid 5697F42S.
compname is DB2VM or DB2VMSFS. Use DB2VM for building segments from a minidisk. Use DB2VMSFS for building segments from SFS directories.
Press PF10 to obtain DB2 Server for VM segment information.
Notes:
VMFSMD2044W Segment name segname already defined. Current segment definition will be replaced.
You can change the name of the segment in the next step if you do not want to replace the current definition.
Fill in or update the Add Segment Definition panel.
Figure 66. Add Segment Definition Panel Showing the New Segment Information
+--------------------------------------------------------------------------------+ | Add Segment Definition More: + | | Lines 1 to nn of nn | | | | | | | | | | OBJNAME....: segname | | DEFPARMS...: ????-???? SR | | SPACE......: | | TYPE.......: SEG | | OBJDESC....: object_description | | OBJINFO....: object_information | | GT_16MB....: NO|YES | | DISKS......: | | SEGREQ.....: | | PRODID.....: 5697F42S compname | | BLDPARMS...: PPF(5697F42S compnameSEG bldlist_name) | | | | | | | | | | | |VMFSMD2760I SEGINFO processing completed SUCCESSFULLY | | | | F1=Help F2=Get Obj F3=Exit F4=Add Line F5=Map F6=Chk MEM | | F7=Bkwd F8=Fwd F9=Retrieve F10=Seginfo F11=Adj MEM F12=Cancel | |====> | +--------------------------------------------------------------------------------+
You can define and use the Resource Adapter and RDS saved segments above 16MB. To define the component above 16MB, specify the starting and ending pages above 16MB on the DEFPARMS field. If you define the component both above and below 16MB, give them different names.
| Note: | If you define the RDS segment above 16M, you CANNOT start the server with the "AMODE(24)" initialization parameter. |
Notice that the component name used in this field is DB2VMSEG or DB2VMSFSSEG. If you have a PPF override to the DB2VM or DB2VMSFS component name, you will also need to add an override to your PPF for DB2VMSEG or DB2VMSFSSEG before you build the segment in Step 14. Build the DB2 Server for VM Segments.
| Note: | The bldlist_name refers to the buildlist for each component of DB2 Server for VM that can be placed in a shared segment. A list of each component and its associated bldlist_name follows: |
Table 18. Component and associated bldlist_name
| Component | bldlist_name |
|---|---|
| Upper Case American English NLS | ARIBLASG |
| French NLS | ARIBLBSG |
| Japanese NLS | ARIBLFSG |
| German NLS | ARIBLHSG |
| Chinese (Hanzi) NLS | ARIBLJSG |
| Mixed Case American English | ARIBLLNG |
| DBSS component | ARIBLDBS |
| ISQL component | ARIBLISQ |
| Resource Adapter component | ARIBLMGR |
| RDS component | ARIBLRDS |
Press F5 to display the refreshed Segment Map panel.
Figure 67. Segment Map Panel with Added Segments Example
+--------------------------------------------------------------------------------+ | VMFSGMAP - Segment Map More: - | | Lines nn to nn of nn| | | | | | 000-MB 001-MB 002-MB 003-MB | | Name Typ 0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF | |M CMS SYS W-W-------------1...............2...............3............... | |M GCS SYS W---------------1...............2...............3............... | | | | 004-MB 005-MB 006-MB 007-MB | | Name Typ 0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF | | CMSPIPES DCS 4...............5...............6...............RRRRRR---------- | |M GCS SYS RRRRRRNNNNNNNNNNNNNNNNNNNNNNNNNN6...............7............... | | | | 008-MB 009-MB 00A-MB 00B-MB | | Name Typ 0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF | | DOSBAM SPA 8...............9...............------------==================== | | CMSBAM MEM 8...............9...............A...............RRRR............ | | CMSDOS MEM 8...............9...............A...............R............... | | SQLISQL MEM RRRRRR..........9...............A...............B............... | | CMSVMLIB DCS RRRRRRRRRRRRRRRR9...............A..............WB........RRRRRRR | | F1=Help F2=Chk Obj F3=Exit F4=Chg Obj F5=File F6=Save | | F7=Bkwd F8=Fwd F9=Retrieve F10=Add Obj F11=Del Obj F12=Cancel | |====> | +--------------------------------------------------------------------------------+
Press F5 to save the changed information and exit from the panel.
+-------------------End of Do these steps for each segment-------------------+
To load the saved segment, the machine must have enough virtual storage to contain the saved segment, loader tables, and CMS control block tables at the end of virtual storage.
Before building the new DB2 Server for VM segment, following these steps:
ipl cms parm clear nosprof instseg no
| Note: | ** DO NOT press ENTER at the VM READ!** |
access (noprof
access 5e5 b
link MAINT 51d 51d mr access 51d d
access vdev k
vdev is the address the database machine production minidisk is linked as by the installation user ID, or vdev is the name of the database machine production SFS directory. You need write access to this minidisk or directory.
set language ameng (add ari user
ARISAVES is called by the VMFBLD command, in Step 14. Build the DB2 Server for VM Segments.
Before you run the ARISAVES EXEC for each component to be defined in a saved segment, verify that the ARISSEGC macro contains the proper SYSNAME entry, origin, and saved segment choice for the component. Use XEDIT to change the ARISSEGC macro on the database machine, SQLMACH, production minidisk or SFS directory. (You should not use the VMSES/E local modification procedure.)
If the saved segment you defined is to become the new default, the SYSNAME value in the ARISSEGC macro should match the name you used to define the saved segment for the component. If not, edit the ARISSEGC macro and change the SYSNAME accordingly. The message ARI0365W will be issued if the SYSNAMEs do not match.
The ARISSEGC MACRO has a record length of 80, and its record format is fixed. The values in each record must be separated by one or more blanks and are interpreted in the order shown in the following list:
ARISAVES EXEC only processes the first occurrence of the value of each compid. Other records are ignored. You could use them to store other information on saved segments.
Unless you have changed some values in it, the ARISSEGC MACRO contains the following information:
Release the database machine, SQLMACH, production minidisk or SFS directory by entering the following command:
release k
For each segment that is to be built, enter the following command:
vmfbld ppf segbld esasegs segblist segname (serviced
You will be prompted asking you if you want the saved segments to be the new default saved segments. If you reply YES, ARISAVES updates the origin values in the ARISSEGC MACRO and generates bootstrap modules by calling the SQLBOOTS EXEC.
If you reply NO, you must create a bootstrap package yourself by using the SQLGENLD EXEC shown in Step 15. Create a Bootstrap Package.
If you responded YES when prompted by the ARISAVES EXEC to use the saved segments you that loaded as defaults, you do not have to do this step, as ARISAVES would have generated a default bootstrap package (SQLDBA) for you.
If you answered NO to the prompt, you must run the SQLGENLD EXEC to create a bootstrap package for the saved segments you loaded. To run SQLGENLD EXEC, you must log off of the installation user ID and log on to the database machine (SQLMACH).
Because SQLGENLD prompts you for certain information about the new bootstrap, you should determine the contents of the bootstrap package before you run the SQLGENLD EXEC. For more information, see Contents of a Bootstrap Package.
A bootstrap package contains modules created by the SQLGENLD EXEC. SQLGENLD places the modules on the production minidisk (Q-disk). Note that, even though the DBSS and RDS components are loaded in different saved segments, there is only one bootstrap module for them. All of those components are needed to run the DB2 Server for VM system code in a database machine. Thus, one bootstrap identifies the location of the DBSS and RDS components.
Not all modules are needed because the database manager uses defaults when a module of a bootstrap is missing. For more information on the defaults, see Using SQLGENLD.
Figure 69 summarizes the different bootstrap modules that you can have.
Figure 69. Bootstrap Package Contents
fn ft fm
Resource adapter --> dcssid SQLRMBT Q
DBSS/RDS ....------> dcssid SQLDBBT Q
ISQL --------------> dcssid SQLISBT Q
|
The dcssid (saved segment ID) is the name you give to the bootstrap package with SQLGENLD. It is the dcssid that you use in the DCSSID parameter of various IBM-supplied execs (such as, SQLSTART or SQLINIT). When dcssid is specified in a DCSSID parameter, the bootstrap package production disk entries are copied to the execution machine's A-disk as shown in Figure 70.
Figure 70. Bootstraps Copied to the Execution Machine A-disk
The resource adapter bootstrap is incomplete when it is copied to the A-disk of the user machine. It is completed when the user runs the SQLINIT EXEC, which supplies the missing server name to be accessed.
Use SQLGENLD to generate bootstrap packages for running the database manager in saved segments. You cannot use this EXEC to generate a bootstrap package for running the database manager in a default mode. The SQLDBA bootstrap package identifies the default mode, which can be default saved segments (if you have defined them) or user free storage.
When you identify the bootstraps to be contained in the package you are creating and the location where you want them to load the code, you can use the SQLGENLD EXEC. To use SQLGENLD, obtain read access to the service minidisk by entering the following command:
access 193 v
You can run SQLGENLD only from the database machine:
sqlgenld
When it runs, the SQLGENLD EXEC obtains both read and write access to the production minidisk. Both kinds of access are available to a defined database machine. You should ensure that no other machine has write access to the production minidisk when you run SQLGENLD.
If you are running SQLGENLD from a database machine that does not own the production minidisk, SQLGENLD prompts you for the write password.
The SQLGENLD EXEC prompts you for dcssid. This is the name of the new bootstrap package. If a bootstrap package with this name already exists, SQLGENLD replaces the existing bootstraps. The EXEC does not let you replace the initial SQLDBA bootstrap package. The SQLDBA bootstrap package is used as a default by many IBM-supplied execs. Do not modify or erase the SQLDBA bootstrap package.
When you supply dcssid, SQLGENLD prompts if you want to create a resource adapter bootstrap, a DBSS/RDS bootstrap, and an ISQL bootstrap. For each bootstrap that you choose to create, you are prompted for the saved segment name (or, in the case of DBSS/RDS, names). The name is the name you used in the OBJNAME field of the Add Segment Definition panel.
The database manager prompts if you want this bootstrap package to be the default DCSSID for user machines that have a link to this production (Q) disk. Specify this as the default if you have users linking to this Q-disk who will be accessing a database machine that does not own this production (Q) disk, and if you do not have saved segments identified by the SQLDBA bootstrap package. Because the database manager provides a default DCSSID, these users are not required to specify the DCSSID parameter when they run the SQLINIT EXEC.
| Note: | The SQLDCSID DEFAULT file cannot be used by a user if the file resid SQLDBN exists on the production (Q) disk they are linked to. This is because the default bootstrap package for a database is identified in the resid SQLDBN file. The SQLDCSID DEFAULT file is used by users that are accessing an application server other than the one that owns the Q-disk to which they are linked. |
If you say that you want this bootstrap to be the default for users with a link to this production (Q) disk, a new file SQLDCSID DEFAULT will be created on the production (Q) disk to contain the default DCSSID. When the bootstraps are created, SQLGENLD places them on the production minidisk. They are then erased from the database machine A-disk.
To run the database machine, you must ensure that its virtual storage is smaller than the load address of any of the saved segments that you loaded, or that the SEGMENT RESERVE command has been issued on the database machine for all segments that reside within the database machine virtual storage. The SEGMENT RESERVE commands should normally be placed in the Server's PROFILE EXEC.
If you are using default saved segments and you want to run a component in user free storage, follow these steps:
If you have secondary production disks, you must manually copy the ARISSEGC MACRO to them. Then, you must run the SQLBOOTS EXEC for each production disk. For information on the SQLBOOTS EXEC, see SQLBOOTS EXEC.
The ARISNLSC MACRO indicates the repository used for DB2 Server for VM messages. It has a record length of 80, and a fixed record format. The MACRO is shown in Figure 71.
|
For more information, see National Language Support for Messages and HELP Text.