Changes common to VPARS and VTAPE
VSSI Version 4 includes the following features and enhancements:
Starting with Version 4, VSSI now uses CP accessed parameter disk(s) to store the configuration files.
The VSSI parameter disk may, but does not have to, be the same parameter disk as the one (usually CF1) used by the IPL process.
As part of the installation process, the VSSI CONFIG file is edited and the location of the VSSI parameter disk is specified as follows:
VSI_DISK userid vdev
Note: The VSSI parm disk MUST be CP accessed before VPARS and/or VTAPE can access the files.
During the installation process, the following files are moved to the selected (usually CF1) IBM parameter disk:
With this version, the VSSI code no longer modifies the IBM provided HCPMDLAT macro. VSSI is now using private MDLAT's based on the following component ID's, which have been allocated to VSSI:
Note: There are two side effects to this implementation:
Starting with Version 4 of VSSI software, the configuration files used by the VSSI products do not require an assemble step and are no longer placed on the system spool. These files are now standard fixed length 80 character records, and are stored on the VSSI parm disk(s). The IBM CP parser is used to decode the configuration statements for VPARS and VTAPE.
The VTSYSTEM DEFAULTS file MUST be stored on the VSSI primary parm disk, which is defined by the VSI_Disk initialization statement in the VSSI CONFIG file.
Although VTSYSTEM is the default name of the VTAPE initialization file, it can be changed to any valid CMS filename by coding the following statement in the VSSI CONFIG file.
VTAPE_CONfig fname
Note: The filetype is DEFAULTS and CANNOT be changed.
Version 4 of VTAPE introduces the following new features:
The VPSYSTEM DEFAULTS file MUST be stored on the VSSI primary parm disk, which is defined by the VSI_Disk initialization statement in the VSSI CONFIG file.
If required, VPARS configuration files can be segregated by CP classes and/or userid, and stored on different parm disks. This is accomplished by coding the following keywords in the VPSYSTEM file:
PARM_USER userid diskowner vdev PARM_CLASS cpclass diskowner vdev
Note: The additional parm disks must be CP accessed before VPARS can use the files. The previous statements define the parm disk, they DO NOT access them.
Note: If a userid is assigned a special parm disk, all the files required by VPARS must be on this disk. VPARS will not search the primary parm disk if a file is not found on the alternate parm disk.
The CMS utility VPUTIL has been updated to allow a VPARS concatenation to be searched (List or Print function). Prior to Version 4, only a single configuration could be searched. The following two keywords have been added:
The VPBXREST command, used in the creation of NOBASE system, has been enhanced to correctly support 3390 dasd. When the restore of a capture tape is started, the device type of the receiving dasd (which must match the type of the initial TPF dasd) is determined and the information used to correctly restore pool records.
This is the replacement for VPBXPLTB in a TPF 4.1 environment.
In order to support TPF 4.1 in a NOBASE environment, the module
VPBXPLTB (which creates the POOL SECTION DIRECTORY TABLE) had to be
modified. The file VPBXPLTB assemble delivered on the tape only
supports TPF 3.1. In a TPF 4.1 environment, the
file VPBXPL41 must be renamed to VPBXPLTB before being assembled. As
part of the rewrite, the new module also supports partial track.
Prior to version 4, VPBXBMAP utility was limited to reading only one tape when copying the pool directory records to disk (to be used by VPBXREST). Now, any number of tapes can be read in one run.