In order to access the data in the VTS-TSR, the application program contains typical tableBASE calls. It is through parameters or library lists that tableBASE knows VTS should be invoked. The TBLBASE API supports access to the tableBASE VTS-TSR under MVS batch, TSO, IMS, CICS and DB2 SPAS.
The tableBASE options for applications using TBCALLV or TBASEV may have changed. In Version 5 the options were obtained from the VTS setting in CV113450 (linked into CVROOTV). Starting with Version 6 the options are obtained from the region in which the application runs (DK1T1134 for batch, DK1T2734 for CICS).
In Version 5, the VTS product had its own settings for SWITCHES. Starting with Version 6 the VTS product does not have its own SWITCHES settings; it inherits the settings from the interface corresponding to the application being run— Batch, IMS, CICS, DB2 SPAS, etc.
The default settings for the SWITCHES in Version 5 VTS was NNNNN, while the default settings for the Batch, IMS, CICS and DB2 SPAS interfaces differ from these values (refer to the chapters in the tableBASE Installation Guide applicable to the interface). Therefore an application from Version 5 that may have not abended when the VTS-TSR was down (due to a 1072 error) may now abend in the later version, unless the SWITCHES setting is changed from the default value to N.
Other differing settings may cause other behavioral differences unless changed from their Version 5 default values. The difference in settings can normally be resolved by adding a TBOPT override to the application JCL (see tableBASE run-time options).
With Version 7, if the generation number of a VTS changes while it is being accessed, that VTS can no longer be accessed unless the START-TBUOW field in the command area is set to S after the generation number has changed. For more information on how to access a new generation of a VTS-TSR, please refer to 16. START-TBUOW (1 byte).
Accessing a VTS with VTS Gate options
If a VTS-TSR has been started up with one or more of the security options provided with VTS Gate, access to the VTS may be affected. VTS Gate options allow a VTS to be protected using an SAF interface security tool (like ACF2, RACF or Top Secret), be hardware key protected or be started up in read-only mode.
The security implementations for a VTS-TSR can restrict the type of access allowed by a user on the VTS. With these restrictions, each tableBASE command is verified for sufficient authorization before being allowed on the VTS. For the purpose of implementing VTS Gate security, tableBASE commands have been classified into three groups: (a) those that read from a TSR, (b) those that write to a TSR and (c) those that do not access a TSR. More information on these categories can be found here: tableBASE command categories by TSR access.
Read-only VTS-TSR
If a VTS has been started up as read-only with no other security features, tableBASE commands that read from the VTS (group a) and those that do not access the VTS (group c) are allowed. tableBASE update commands (group b) on a read-only VTS-TSR will return error 13-06.
In order for tableBASE update commands, including those for loading the VTS-TSR, to execute successfully, the VTS-TSR must first be switched to read-write mode. More information on how to switch a read-only VTS to read-write mode can be found in the tableBASE Administration Guide.
A read-only VTS can also be SAF interface and/or hardware key protected. More information on accessing these VTS-TSRs is provided below.
SAF interface protected VTS-TSR
If a VTS is SAF protected, each tableBASE command performed on the VTS is authorized based on the access level granted to a userid on the VTS. The userid that is used to submit a batch job or to start up a region (CICS, IMS or DB2 SPAS) is the one that is verified for sufficient authorization. For CICS, IMS and DB2 SPAS regions, any userid permitted to access the region, and while executing in the region, inherits the same access levels to the VTS as the user that started up the region. For more information on access levels and permissions, refer to thetableBASE Administration Guide.
A user that has no authorization to access a VTS-TSR can still operate on the commands that do not access the VTS (group c). A user with only READ access to a VTS can operate on commands that read from and commands that do not access the VTS (groups a and c). A user with ALTER, CONTROL or UPDATE/WRITE access to a VTS can operate on all tableBASE commands (groups a, b and c).
Any attempts to read from a SAF protected VTS without the necessary permission will result in error 1072-3 and 1072-4 respectively. For every failed attempt to access the VTS, an SAF interface error message of the following form will be displayed in the JESMSGLG for the job or region:
ICH408I USER(userid) GROUP(groupname ) NAME(username) DK1.VTS.lparname.vtsname
CL(FACILITY) INSUFFICIENT ACCESS AUTHORITY [FROM resource profile (G)] ACCESS
INTENT(access-intent) ACCESS ALLOWED(access-allowed)Note that if a VTS-TSR is being accessed as a linked VTS, the VTS automatically becomes a read-only VTS. In this case, although a user may be permitted to write to the VTS, any update commands will fail with an error indicating that the VTS-TSR is in read-only mode. The same holds true if the VTS-TSR has been started up in read-only mode as discussed under Read-only VTS-TSR.
Hardware key protected VTS-TSR
Since a hardware key protected VTS-TSR normally runs in read-only mode, user applications (in batch, CICS, IMS or DB2 SPAS) can only perform tableBASE commands that read from such a VTS or do not access the VTS (groups a and c). tableBASE update commands (group b) on a read-only VTS-TSR will return error 13-06.
As discussed under Read-only VTS-TSR, these VTS-TSRs must be switched to read-write mode before they can be loaded with tables.
A hardware key protected VTS can also be SAF interface protected. Refer to SAF interface protected VTS-TSR for more information on how to access these VTS-TSRs.