IBM Support

Connecting to z/OS data sources

White Papers


Abstract

The DVM server has built-in intelligence to leverage direct access paths to underlying data residing on the mainframe environment, such as mainframe Database systems, File Management systems, or system files. The DVM server's built-in evaluation and query processing optimize the access, which in some cases, depending on the data source, can avoid management subsystems for I/O. The benefits are faster access and execution time, plus the ability to more readily offload general processing to zIIP specialty engines, if available

Content

Connecting to z/OS data sources
The DVM server has built-in intelligence to leverage direct access paths to underlying data residing on the mainframe environment, such as mainframe Database systems, File Management systems, or system files. The DVM server's built-in evaluation and query processing optimize the access, which in some cases, depending on the data source, can avoid management subsystems for I/O. The benefits are faster access and execution time, plus the ability to more readily offload general processing to zIIP specialty engines, if available.
           Security Endpoints
Clients access the DVM server through ODBC/JDBC, HTTP/HTTPS, DRDA, including RRSAF and CAF for Db2 z/OS.
Getting started
Within the DVM configuration member, specify the DRDA RDBMSs settings through a definition statement and provide local environment values for all the parameters. The DVM Started Task needs be recycled after setting the Define Database specifications.
The following example shows the section in the configuration member to enable:
"DEFINE DATABASE TYPE(type_selection)", 
"NAME(name)" , 
"LOCATION(location)" , 
"DDFSTATUS(ENABLE)" , 
"DOMAIN(your.domain.name)" , 
"PORT(port)" , 
"IPADDR(1.1.1.1)" , 
"CCSID(37)" , 
"APPLNAME(DSN1LU)" , 
"IDLETIME(110)"
IBM Documentation provides more information on installing and configuring the DVM server.
Direct access to z/OS databases
Adabas
Adabas is designed to support thousands of users in parallel with sub-second response times. Access to Adabas can be from Natural, Software AG’s 4RL dev IDE, ODBC/JDBC, and embedded SQL. Adabas supports up to 65,535 DBs with each supporting up to 5,000 files, where each file can contain up to 4 trillion records, each with up to 926 fields. DVM for z/OS supports Adabas 8.x or later and the DVM server supports long names for fields, Multi-file joins optimized connection modes, Natural subsystem security, and dynamic switching between TCB and SRB mode for improved parallelism and zIIP-eligibility as shown in Figure 2. The DVM Server supports ET/BT transaction-based commands, MU and PE file structures, and Natural DATE and TIME formats.
Benefits of using DVM for z/OS to access Adabas
 
  • Software AG's Adabas SQL requires an off-host server (CONNX) with limits for scale, performance, and failover that can be addressed with DVM server technology
  • The DVM server can service both Adabas and Natural programs and serve as a substitute for Software AG's EntireX solution
  • DVM for z/OS is an integral component for IBM's IDAA Loader component for loading Adabas data to IBM's Data Analytics Accelerator (IDAA)
  • DVM for z/OS DSclient supports both DRDA and the JDBC Gateway server. This offers a replacement option to Software AG's Natural SQL Gateway
  • Organizations with Db2 for z/OS can drive transaction activity through their Db2 subsystem using the Integrated DRDA Facility (IDF) using Db2 as a Data Hub. This option works to isolate workloads to a single system.
  • DVM for z/OS integrates with AT-TLS and improves configuring secure access to Adabas data
  • DVM for z/OS helps to offload SORT, JOIN, and data translation operations
Adabas can execute a single Adabas command that retrieves multiple rows (multi-fetch).  When a SELECT statement executes within the DVM server, the request can be split into multiple and separate READ requests when MapReduce is dynamically activated and returns a list of record IDs (ISN).
Screen Shot 2021-06-01 at 2.45.00 PM
Figure 2 - DVM server architecture for Adabas
Virtualizing Adabas 
Legacy data sources for virtualizing DVM for z/OS for use with a physical file as well as a Natural DDM to map the metadata into a relational set of DVM server catalog tables. Adabas data can be virtualized using JCL batch jobs or by using the DVM Studio.
Creating virtual tables with JCL
DVM for z/OS is packaged with Batch JCL, where the administrator selects one file number at a time. Batch JCL parameters include; Subsystem, SSID, DBID, and File Number. Running the Batch JCL generates metadata in XML and then parsed by the DVM parser to create DVM server metadata as shown in Figure 3.
Screen Shot 2021-06-01 at 2.54.23 PM
Figure 3 - Virtualizing Adabas with Batch JCL
Working with Adabas
Adabas has basic fields, special fields, and multi-value fields. These fields need to be translated by the DVM server and transformed collectively into a relational format for client tools to more easily access and query the underlying data. The DVM catalog stores the metadata for virtual tables shown in Table 1 and Table 2.
Field format Length SQL Data Type
Binary 126 bytes Binary
Fixed 2 bytes Small integer
Fixed 4 bytes Integer
Fixed 8 bytes Big Integer
Float 4 bytes Real Float
Float 8 bytes Double
Packed 29 bytes Decimal
Unpacked 29 bytes Decimal or Numeric
Alpha 253 bytes Varchar
Table 1 - Basic field format conversions for Adabas.
Field Format Length SQL Data Type
ISN RECORD_ID Big Integer
Natural/Predict (D) date 4 bytes Date
Natural/Predict (T) time 7 bytes Timestamp
Table 2 - Special field format conversions for Adabas
The DVM server also works with Multi-value (MU) fields in an Adabas record and periodic groups (PE), which are repeating groups in an Adabas record. Both multi-value field and periodic groups currently have a limit of 191 occurrences and a maximum fetch of 64K occurrences. If Adabas applications execute a delete, the Adabas dataset collapses the array of data by removing the deleted record and reassigning the next record in its place.
When a virtual table is flattened, each multi-value occurrence becomes a column. When the table is not flattened, then each multi-value field is written its own subtable with an index, parent key, and base key, as shown in Figure 4.
    
    Screen Shot 2021-06-01 at 2.46.53 PM
Figure 4 - Multi-value fields in a flattened virtual table.
When working with periodic groups, one level of multi-value (MU) fields can be inside of a periodic group (PE), in order to make a 3-D array. Deleting an occurrence does NOT collapse the array. When the virtual table is flattened, each field in the periodic group (PE) is a column. When the virtual table is not flattened, the periodic group (PE) is a subtable with a group of columns with an index and parent key.
Best Practices for Field naming
 
  • Adabas by design has field names that are two characters in length and it's recommended to use longer field names
  • Adabas DBAs can generate Natural DDM views
  • When flattening ME/PU arrays limit the length of the field name to 26 bytes to account for additional bytes used during data mapping
Best practices for Load testing
Each DVM ODBC/JDBC client connection performs an (OP)en for an Adabas User Queue Element (UQE), these UQEs share a pool of Adabas Nucleus Threads (NT) that run on the General Processors. The DVM server takes advantage of Adabas v8 multi-buffers and Adabas 64-bit storage through multiple fetches of records for better performance and reduced CPU. Depending on the type of transaction, the size of the format buffer, the size of the result-set (record buffer), Adabas will manage the workload based on the ADARUN parameter settings shown in Table 3.
Parameter Definition Recommendation
V64BIT YES
A setting of YES activates 64-bit storage.
NU
maximum # of user queue elements
Consider increasing this parameter for a larger number of application connections (for example, 800 for a total of 800 user connection pool).
LU
All user buffers (format, record, search, value, ISN).
Recommended value of 1024000
LU represents all buffers that may be required for any Adabas command.
- increase this value to improve performance and ability to handle large PE groups
- minimum value of 64K
- recommend 1024K
NAB The number of attached buffers to be used.
Recommended value of 10000
Increase this value with corresponding increases in LU.
LWP
The size of the Adabas work pool.
Recommended value of 3,500,000
Increase this value with corresponding increases in LU.
NISNHQ The maximum number of records that can be placed in HOLD status at the same time by one user
Typically 1/4 of the NH HOLD queue size.
Important for large updates, for example, up to and exceeding 12000.
NH HOLD queue element (HQE)
his is required for each record (ISN) placed in HOLD status.
This value is important for large updates, for example, up to and exceeding 50000.
LBP The maximum size of the Adabas buffer pool.
Monitor Adabas shutdown stats to size this value for performance.
For example, 1,200,000,000.
NT The number of user threads used during the Adabas session Typically, corresponds to the number of General Processors + 1
Table 3 - ADARUN parameters
Generating code for Adabas
DVM for z/OS provides natural code generation, which can be used to access Adabas. The DVM server supports Software AG Natural version 4 and later. The DVM Studio provides an option for compiling the generated natural program outside of the mainframe. Once virtual tables are defined for an Adabas dataset, Right-clicking on the Virtual Tables section and selecting Generate Query with * allows the administrator to quickly generate code that can be used by a client application to access the dataset, as shown in Figure 7.
DVM Studio:
Server Tab > SQL > Data > SSID > Virtual Tables > Generate Query with *
Screen Shot 2021-06-01 at 2.50.18 PM
Figure 7 - Adabas code generator
The IBM Documentation provides detailed information on this configuration process, in the section Configuring Access to Data in Adabas.
Db2 for z/OS
Db2 provides the ability to federate data from other non-Db2 data sources, leverage User Defined Table Function (UDTF) capability in Db2 for z/OS, and also provide a means to access DVM server's Integrated Data Facility (IDF). User-defined table functions or UDTFs are a program that has the ability to reaches outside of Db2 for z/OS to the operating system or file system to retrieve data and return it in a relational format. DVM for z/OS can create Db2 for z/OS UDTFs that point to Virtual Tables provisioned on the DVM server.
IDF adds a DRDA server interface to the DVM subsystem, such that Db2 for z/OS can pull any virtualized data from any registered DVM server instance in SYSIBM.LOCATIONS and SYSIBM.IPNAMES.
Db2 for z/OS Access Options
Db2 for z/OS can be accessed by the DVM server through either the Distributed Relational Database Architecture (DRDA) access method or the Resource Recovery Services attachment facility (RRSAF) access method. DRDA allows a higher percentage of the Db2 workload to run in Service Request Block (SRB) mode and offloaded to a zIIP specialty engine. Running workloads in SRB mode lowers the total cost of ownership when compared to RRSAF by reducing the dependency on z/OS General Purpose processor use (MIPS). If the z/OS environment uses a zIIP specialty engine, configure the DVM Server to access Db2 for z/OS with the DRDA access method. Before Db2 requests are issued, you must bind DRDA, RRSAF, or both into packages within each Db2 subsystem. Binding both access methods are recommended.
Two different Db2 for z/OS data access constructs are available by the Data Virtualization Manager server; traditional and Db2 Direct.
Traditional Db2 APIs allow for reading and writing of the data, as well as transactional integrity.
Db2 Direct reads the underlying Db2 VSAM linear datasets directly, without issuing an SQL statement against Db2 for z/OS. This access method allows read-only access to the data and provides high performance and bulk data access. This method can be used when you create virtual tables against Db2 database objects with the DVM Studio. In a controlled environment, the Db2 Direct access was used on a large z14 configuration to virtualize and facilitate large data pulls that resulted in greater than 5 times improvement in elapsed time when compared to traditional DRDA access. The work, in this case, is 100% zIIP eligible compared to 60% eligible where Db2 uses DRDA requesters. This access method is that it doesn't use any Db2 resources, as shown in Figure 8.
Screen Shot 2021-06-01 at 2.55.58 PM
Figure 8 - Db2 Direct provides direct access to underlying data without Db2 resources
The IBM Documentation also provides detailed information on configuring access to Db2 for z/OS.
IBM ESA/IMS database
IBM IMS database support is provided through three access methods that use simple SQL-based queries.
IMS database control
Database Control (DBCTL) is an IMS™ facility that provides an IMS Database Manager (IMS DM) subsystem that can be attached to CICS® but runs in its own address spaces. DBCTL access supports SELECT INSERT UPDATE and DELETE.
Note: ODBA and DBCTL are mutually exclusive. Enable one of these two methods to access IMS.
IMS Direct
The DVM server directly accesses underlying native datasets and bypasses the IMS management software for savings on general CPU usage. This access method eliminates the need to traverse the IMS Subsystem with no locking involved when accessing the data. Direct access in this fashion does not fully secure data integrity if the application is performing updates and deletes of data. Security is managed on the IMS native dataset itself when IMS Direct is used. The user ID of the client connection must have the necessary security permissions for reading the IMS database dataset(s), shown in Figure 9.
Screen Shot 2021-06-01 at 2.56.52 PM
Figure 9 - IMS Direct is fully zIIP-eligible and faster for direct access to IMS data
When IMS Direct is not available, the DVM server uses the DBCTL access method. Statistics about the IMS database are collected and stored within a metadata repository from which the SQL engine optimizes the MapReduce process and dynamically determines which is the most performant method for access based on the SQL query. IMS Direct supports all IMS database types, except SHISAM and HISAM.
  • Hierarchical direct access method (HDAM) - VSAM and OSAM
  • Hierarchical indexed direct access method (HIDAM) - VSAM and OSAM
  • Partitioned HDAM (PHDAM) - VSAM and OSAM
  • Partitioned HIDAM (PHIDAM) - VSAM and OSAM
  • Fast Path data entry database (DEDB)
IMS Direct support SELECT Only, for bulk data access and low general processor usage. Multiple IMS subsystems can be accessed with this method.
IMS Open Database Access (ODBA)
Open Database Access (ODBA) provides a callable interface that enables any z/OS® recoverable, resource-managed z/OS address space, including the DVM server to issue DL/I database calls to an IMS DB subsystem. The interface provides access to full-function DL/I databases and data entry databases (DEDBs). ODBA supports SELECT INSERT UPDATE and DELETE, and two-phase commit. Multiple IMS subsystems can be accessed with this method. When configuring multiple IMS subsystems, enable either (DBCTL and IMS Direct) or (ODBA and IMS Direct).
Note: ODBA and DBCTL are mutually exclusive. Only one of these two methods to access IMS for a single DVM server.
Configuration
As with other data sources, there are two datasets supplied by DVM for z/OS that need to be edited for configuring IMS. To configure access, the DVM server started task JCL and configuration member hlq.xVZy.SAVZEXEC.(xVZyIN00) needs to be modified. More configuration changes are necessary to the IMS system.
Creating Virtual Tables
The Program Specification Block (PSB) and Database Definition (DBD) source members and the copybooks for each IMS segment must exist in the virtual source libraries defined to the server. For details, see see “Creating virtual source libraries” in the IBM documentation for DVM for z/OS.
Enabling IMS Direct
Enable the IMSDIRECTENABLED parameter configuration member. When an IMS SQL query is run, the SQL Engine determines if the request is best executed with IMS Direct (native file support) or if IMS APIs are required. The determination is based o the database and file types supported, as well as the size of the database. The Program Specification Block (PSB) and Database Definition (DBD) source members and the copybooks for each IMS segment must exist in the virtual source libraries defined to the server. For details, see “Creating virtual source libraries” in the IBM documentation for DVM for z/OS.
In the IN00 configuration member search for the following sections, to enable access methods.
DoThis = 1 
DontDoThis = 0 
... 

/* Enable IMS CCTL/DBCTL support */ 
if DontDoThis 
then 
do MODIFY PARM NAME(DBCTL) VALUE(YES)" 
... 
Accessing mainframe files like VSAM
Much of critical business data on the mainframe exists in file formats and datasets that are not managed by any specific database management system. VSAM files are opened, written to, and simply exist, waiting for applications to access them for create, retrieve, update, and delete (CRUD) operations.
While these files lack the DBMS to ensure data integrity, the DVM server can access the files through its Data Mapping Facility (DMF) and transform them into a normalized relational view for SQL access.
  • Virtual Storage Access Method (VSAM) is an IBM DASD file storage access method, used to store mission-critical data and managed by a file management system. The problem is that modern applications are looking to access this data more readily, but VSAM is not a database, therefore lacks many of the standard characteristics for data integrity, structure, access, and data protection.
  • Sequential files have records in the file in the order they are written and can only be read back in the same order. They are a simple form of a COBOL file. Every record in a relative file can be accessed directly without having to read through the other records. Once virtualized, the DVM server allows this sequential data to be retrieved in any group order, along with query predicates.
  • Delimited files are typically not found in a mainframe environment, but can be in any file storage system and have column delimiters for a stream of records that consist of fields that are ordered by column. Each record contains fields for one row, with individual fields separated by column delimiters. The DVM server requires the use of Rules, to virtualize delimited files.
  • System Management Facility (SMF) offers a way of keeping track of what is happening on your mainframe. There are 255 SMF records available to help deliver information about all functions and products running on the z/OS environment from the machine level to application-specific activity related to processing, I/O, allocated memory, and so on.
  • System level files (Log stream, Syslog, Operlog, and so on.)
    • Syslog is a standard for computer message logging and can be used for computer system management, security auditing, analysis, and debugging messages.
    • Log stream is an application-specific collection of data that oftentimes organizations use to optimize their environment and routinely store in the form of SMF records. Log stream datasets are VSAM linear datasets.
    • Operations log (OPERLOG) is a sysplex-wide log of system messages residing in a system logger log stream, similar to Syslog.
Virtual storage access method (VSAM)
Virtual Storage Access Method (VSAM) is an IBM DASD file storage access method, used to store mission-critical data and managed by a file management system. The problem is that modern applications are looking to access this data more readily, but VSAM is not a database, therefore lacks many of the standard characteristics for data integrity, structure, access, and data protection.
DVM for z/OS provides seamless access to native VSAM data without configuration for SQL access, other than creating a virtual source library that maps DVM server metadata to the native data residing on disk that describes the record structure in copybooks to properly read the data. The DVM server supports COBOL, PL/I, and DCSCECT formatted copybooks.
This section divides this process into steps to help simplify this process into building blocks required to virtualize VSAM data with the DVM Studio.
  • VSAM cluster representing the VSAM dataset, including one or both of data or index data records. The DVM server requires the name of a valid VSAM cluster as part of the source library for mapping purposes. There are no more configuration steps required for the DVM Server to set up the SQL interface to native VSAM files.
  • The dataset Member name contained in the virtual source library that maps to the copybook (record layout) for the underlying data structure residing on disk
The process involves the one-time creation of a virtual source library containing metadata needed to properly access and read VSAM data, followed by the creation of a virtual table, which allows for SQL access by any number of client applications.
Creating a virtual source library
The DVM Studio is instrumental in creating the building blocks for the DVM server to use in virtualized data. All data sources require a virtual source library to be configured to virtualize underlying data. The library structure ensures a valid description and mapping for the DVM server for locating, accessing, and processing SQL statements.
The DVM Studio allows a user to create a virtual source library under the Admin folder of the Server Tab for Source Libraries, as shown in Figure 10.
DVM Studio:
Server Tab > Admin > Source Libraries > Create Virtual Source Library
Screen Shot 2021-06-01 at 2.57.45 PM
Figure 10 - Creating a Virtual Source Library
The Virtual Source Library wizard requires a name, description, and selected host library name containing the VSAM record layout from a drop-down list of available source libraries. The underlying data structure can be virtualized into a Virtual Table for clients to access and query.
Creating a virtual table
The DVM Studio allows a user to create a virtual table under the SQL folder of the Server Tab for Virtual Tables. This step requires knowledge of the name of the DVM subsystem (SSID) containing the metadata and virtual source library for the desired dataset.
DVM Studio:
Server Tab > SQL > Data > SSID > Virtual Tables
Right-clicking on the Virtual Tables label opens a Virtual Tables wizard to help define criteria for access, fields to include in the virtual table and allows for the ability to validate the virtual table definition. In this particular example, it ensures that the VSAM cluster name and VSAM cluster type match and display the appropriate success or failure.
The Virtual Tables wizard prompts to select the data type, then advances to the New VSAM Virtual Table dialog screen for further definition and requires that the data mapping library defined during the configuration of the DVM server as part of the started task JCL be selected. The accessing USER and SERVER should have READ/WRITE permissions to the target dataset, shown in Figure 11.
Screen Shot 2021-06-01 at 2.58.43 PM
Figure 11 - Creating a Virtual Table with the DVM Studio Wizard 
The Virtual Tables wizard then requests the administrator to select the previously defined virtual source library that contains copybooks for available data. Once the proper Source Library is downloaded and selected, a list of copybook members appears for selection. Selecting the appropriate copybook member associated with the VSAM dataset allows the administrator to advance through the wizard and define the table layout when querying the data, shown in Figure 12.
Screen Shot 2021-06-01 at 3.02.54 PM
Figure 12 - Associating Source Copybook to Virtual Table
If the last field from the source file's copybook is required, that field should be flagged for the Enable End Field Selection checkbox, shown in Figure 13.
Screen Shot 2021-06-01 at 3.02.21 PM
Figure 13 - Virtual Table Layout
The virtual table definition must be validated before creation. In this example, the VSAM cluster name matches the type for the underlying file (KSDS) as shown in Figure 14.
Screen Shot 2021-06-01 at 3.03.43 PM
Figure 14 - Associating VSAM Cluster name to Virtual Table
The DVM server checks the VSAM cluster name provided and returns a positive message with the type of VSAM Cluster, as shown in Figure 15.
Screen Shot 2021-06-01 at 3.04.04 PM
Figure 15 - Successful validation of VSAM Cluster
Querying the new virtual table
With the new virtual table created, Right-clicking on the Virtual Tables label again and selecting Generate Query with * allows the administrator to quickly verify that data can be retrieved without error and ready for the next step in provisioning the new object for test, development, or production-ready applications to use, shown in Figure 16.
DVM Studio:
Server Tab > SQL > Data > SSID > Virtual Tables > Generate Query with *
-- Description: Retrieve the result set for OPERLOG_SYSLOG (up to 1000 rows)
-- Tree Location: 10.3.58.61/1200/SQL/Data/AVZS/Virtual Tables/OPERLOG_SYSLOG
-- Remarks: Logstream - SYSPLEX.OPERLOG
SELECT * FROM OPERLOG_SYSLOG WHERE SYSLOG_JOBID = 'AVZS';
-- Description: Retrieve the result set for VSAM_TABLE (up to 1000 rows)
-- Tree Location: 10.3.58.61/1200/SQL/Data/AVZS/Virtual Tables/VSAM_TABLE
-- Remarks: VSAM - FBOR.STAFF.VSAM
SELECT * FROM VSAM)_TABLE LIMIT 1000;
Screen Shot 2021-06-01 at 3.31.05 PM
Figure 16 - Result of SQL Query on VSAM Virtual Table VSAM_TABLE
System and operations logging
Mainframes generate an incredible amount of logs every second. Transactions, cache, Db2, and so on, without a straightforward way to summarize the data. Some organizations analyze SYSLOG and OPERLOG by forwarding the data to Splunk for analytics. In this case, DVM for z/OS can be used to virtualize selective logs for local analysis or forward those logs to Splunk, where the DVM server can virtualize that data and blend it with other local data. Many choose to use IBM Common Data Provider for z Systems (CDPz).
That stated, while there are options, some are costly from a licensing perspective and require more capital outlay from an infrastructure standpoint regarding CPU, storage, and memory, staging environments, and so on. This is why DVM for z/OS becomes an option with no data movement and in-place access to the system and operational data. The DVM server supports over 35+ non-relational data sources, including SMF, SYSLOG, OPERLOG, JOBLOG, and so on, and can serve in a multi-purpose manner for various use cases.
OPERLOG is a merged, Sysplex-wide system message log provided by a log stream of data. SYSLOG contains a partition (LPAR) message log and is an SYSOUT dataset produced by JES2 or JES3.
DVM for z/OS provides 5 pre-defined virtual tables to display OPERLOG and SYSLOG:
  1. OPERLOG_SYSLOG accesses the SYSPLEX logstream and is defined in the global variable GLOBAL2.SYSLOG.DEFAULT after the  AVZSYSLG rule is enabled
  2. OPERLOG_MDB
  3. OPERLOG_MDB_MDB_CONTROL_OBJECT
  4. OPERLOG_MDB_MDB_TEXT_OBJECT
  5. SYSLOG
Configuring access for SYSLOG
To configure access to system log (SYSLOG) files, the use of both the DVM server configuration member AVZSIN00 and built-in VTB rules are required. VTB rules are provided to define the SYSLOG dataset name. Each of the rules for SYSLOG processing requires that table names for use by SQL begin with SYSLOG. The following rules are provided:
  • AVZSYSLG uses a global variable to specify the name of the dataset to use for the SYSLOG data.
  • AVZSYSL2 supports the use of generation data group (GDG) dataset names. One of the following formats is expected and the general use of global variables allows for maximum flexibility in the overall configuration.
  • SYSLOG_GDG_nnnn, where nnnn is a relative GDG number (0 - 9999) that is appended to the GDG base name value that is obtained from the GLOBAL2.SYSLOG.GDGBASE variable.
  • For example, if the table name as specified in the SQL statement is SYSLOG_GDG_1, then the dataset name returned by this rule is HLQ.SYSLOG(-1), depending on the value in GLOBAL2.SYSLOG.GDGBASE.
  • SYSLOG_DSN_suffix, where suffix is used as the last part of a global variable of the form GLOBAL2.SYSLOG.suffix to look up the name of the dataset to be used. If this variable does not exist, the dataset name is specified in GLOBAL2.SYSLOG.DEFAULT is used to read the SYSLOG records.
  • Global variable examples possible for use with this rule:

    GDGBASE       hlq.SYSLOG
    DEFAULT         hlq.SYSLOG(0)
    TODAY             hlq.SYSLOG(0)
    YESTERDAY   hlq.SYSLOG(-1)
Customizing rules for SYSLOG
Once enabled, the VTB rules for SYSLOG persist for every occurrence of an SQL statement where the use of SYSLOG as a prefix for table names in SQL statements. To enable VTB events for SYSLOG, the DVM server configuration member needs to be customized by configuring the SEFVTBEVENTS parameter in the AVZSIN00 member from the DVM server ISPF PANEL.

"MODIFY PARM NAME(SEFVTBEVENTS) VALUE(YES)"
When configuring AVZSYSL2 for SYSLOG, no customization of the VTR is required. However, when configuring for AVZSYSLG, specify 'S' next to the AVZSYSLG in the ISPF PANEL and change the dataset name to SYSLOG.
Enabling rules for SYSLOG
Enable AVZSYSLG and AVZSYSL2 rules by specifying 'E' next to the member in the ISPF PANEL. To auto-enable these rules after each DVM server restart, instead, specify ‘A’ next to the member name. If the event global variables are needed. The administrator needs to configure the SYSLOG global variable, shown in Figure 17.
Screen Shot 2021-06-01 at 3.05.31 PM
Figure 17 - Auto-Enabling AVZSYSLG and AVZSYSL2 VTB rules
The DVM Studio can now be used similarly to running sample queries on VSAM by selecting SYSLOG in the Virtual Tables section of the Server Tab. Figure 18 displays both the generated SQL statement and the results.
DVM Studio:
Server Tab > SQL > Data > SSID > Virtual Tables > SYSLOG > Generate Query with *
-- Description: Retrieve the result set for SYSLOG (up to 1000 rows)
-- Tree Location: 10.3.58.61/1200/SQL/Data/AVZS/Virtual Tables/SYSLOG
-- Remarks: HTTP://10.3.58.61:1201
SELECT * FROM SYSLOG LIMIT 1000;
 Screen Shot 2021-06-01 at 3.07.11 PM
Figure 18 - Generated query and results for SYSLOG with the DVM Studio
Configuring access to OPERLOG
However, no modifications are needed to configure the DVM server to access OPERLOG data, however, OPERLOG must be active in a system logger log stream. Use the IBM mainframe’s System Display and Search Facility (SDSF) to verify whether OPERLOG is active with the ‘/D C,HC’ inputs. OPERLOG is actively configured and enabled if the following displays in the facility.
CNZ4100I 15.19.16 CONSOLE DISPLAY 056
CONSOLES MATCHING COMMAND: D C,HC
MSG:CURR=0 LIM=9000 RPLY:CURR=0 LIM=9999 SYS=P02
PFK=00
HARDCOPY LOG=(SYSLOG,OPERLOG) CMDLEVEL=CMDS
ROUT=(ALL)
LOG BUFFERS IN USE: 0 LOG BUFFER LIMIT: 9999
The DVM Studio can now be used similarly to running sample queries on VSAM by selecting OPERLOG_SYSLOG in the Virtual Tables section of the Server Tab.  Figure 19 displays the first 100 rows.
DVM Studio:
Server Tab > SQL > Data > SSID > Virtual Tables > OPERLOG_SYSLOG > Generate Query with *
We are now going to use an SQL Query in DVM Studio to verify our setup is running successfully for the first 100 rows.
SELECT * FROM OPERLOG_SYSLOG LIMIT 1000;
Screen Shot 2021-06-01 at 3.26.30 PM
Figure 19 - Generating Query on OPERLOG with the DVM Studio
These results are similar to the SYLOG example, however, we have records for a different ZB02 LPAR, as we are now reporting across the Sysplex. Querying only on the ZB01 LPAR allows us to test and validate in an interactive mode in the ISPF PANEL for the DVM server. Following steps used previously, the query is modified and displayed in Figure 20.
SELECT * FROM OPERLOG_SYSLOG
WHERE SYSLOG_JOBID='AVZS';
Screen Shot 2021-06-01 at 3.25.38 PM
Figure 20 - SQL Query result from OPERLOG for AVZS JOBID 
In the DVM server ISPF PANEL in interactive mode, the Address Environment can be updated to ‘AVZ’ to generate a message in the OPERLOG. Run the following command: DISPLAY REMOTE USER(*), shown in Figure 21.
Screen Shot 2021-06-01 at 3.09.38 PM
Figure 21 - Displaying Remote Users
When running the same query again within the DVM Studio, the SYSLOG_DATE_TIME value is incremented, as AVZS generates a new message in our OPERLOG, as presented in Figure 22.
-- Description: Retrieve the result set for OPERLOG_SYSLOG (up to 1000 rows)
-- Tree Location: 10.3.58.61/1200/SQL/Data/AVZS/Virtual Tables/OPERLOG_SYSLOG
-- Remarks: Logstream - SYSPLEX.OPERLOG
SELECT * FROM OPERLOG_SYSLOG WHERE SYSLOG_JOBID = 'AVZS';
Screen Shot 2021-06-01 at 3.24.30 PM
Figure 22 - SQL Query result from OPERLOG with recent messages
Delimited file datasets
The most common form of delimited data is CSV or Microsoft Excel worksheet. When delimited data processing is activated through VTB rules, processing occurs in columnar order. The delimited data must include a value for each column in the map in the correct order to prevent errors.
To enable delimited data processing, the DVM server configuration member (AVZSIN00) needs to be customized by configuring the SEFVTBEVENTS parameter.
"MODIFY PARM NAME(SEFVTBEVENTS) VALUE(YES)"
The DVM server ISPF panel allows you to customize a sample rule named AVZMDDLM from the VT rule management section. Within this panel section column and string delimiter values, as well as control header processing, can be enabled. The 'vtb.optbdlcv' option should be set to '1'.
/*------------------------------------------------------------------*/
/*    Activate delimited data processing for the table              */
/*------------------------------------------------------------------*/
vtb.optbdlcv = 1            /* flag that data is delimited.         */
More options are available to help with the processing of delimited data.
  • vtb.optbdlco sets the column delimiter (default value is the comma ',')
  • vtb.optbdlch sets the delimiter (default is the double quotation mark ")
  • vtb.optbdlhr identifies and removes the header record containing column names. If specified without a header prefix, the system compares the first token in each line to the first column name in the table to recognize and discard the header. The default is no header checking with value 0.
  • vtb.optbdlhp is a global parameter that defines prefix data that identifies the beginning of a header line to be discarded. The specified value can contain a maximum of 32 bytes. This value is compared to the beginning of each delimited line of data before any tokenization is performed.
Defining map definitions for delimited datasets
To read a delimited dataset, data type mappings need to be in place for the delimited file we want to virtualize. Figure 23 represents a sample CSV file currently located in the local zFS file system.
Screen Shot 2021-06-01 at 3.11.55 PM
Figure 23 - DCL definitions for CLIENT_INFO delimited dataset
Map definitions are needed to ensure columns are displayed in the correct order. The process is similar to that performed for VSAM or other input files. Figure 24 represents a copybook definition of the delimited file dataset that declares the field definitions to be created in the DVM server virtual source library.
Screen Shot 2021-06-01 at 3.12.18 PM
Figure 24 - DCL definitions for CLIENT_INFO delimited dataset
The DVM Studio can now be used similarly to running sample queries on VSAM by selecting zFS in the Virtual Tables section of the Server Tab. Figure 25 displays both the generated SQL statement and results. Be certain to add the 'MDDLM_' prefix before the Virtual Table name to format data properly for display. The 'MDDLM_' prefix is required for SQL, to ensure proper formatting.
DVM Studio:
Server Tab > SQL > Data > SSID > Virtual Tables > zFS > Generate Query with *
-- Description: Retrieve the result set for CLIENT_INFO_DELIMITED (up to 10000 rows)
-- Tree Location: 10.3.58.61/1200/SQL/Data/AVZS/Virtual Tables/CLIENT_INFO_DELIMITED
-- Remarks: zFS file - /u/arnould/CLINET_INFO/DELIMITED.csv
SELECT * FROM MDDLM_CLIENT_INFO_DELIMITED LIMIT 10000;
Screen Shot 2021-06-01 at 3.21.47 PM
Figure 25 - Result from SQL Query on Delimited dataset
Data conversion errors occur if the delimited data is not compatible with the host types of the columns. If the conversion fails, diagnostic information related to the error is automatically logged for troubleshooting problems.
System Management Facility (SMF)
IBM z/OS System information can be logged with the IBM System Management Facility (SMF) and the native DVM server logging feature. Logging allows you to collect various systems and operations-related information. The following IBM APARs should be applied on the z/OS SMP/E base system:
  • APAR OA49263 provides real-time SMF support and is a requirement for the configuration of real-time SMF data access.
  • APAR OA48933 is required to address accessing log streams. SMF log stream configuration is required for in-memory resource support. In this section, we are going to cover how to access this information from the DVM server.
There are different methods of access to SMF files:
  • SMF datasets - SMF information is recorded in MANx datasets. When a dataset gets full, the data is processed using IFASMFDP. The output of IFASMFDP is required when using global variables.
  • Log streams - SMF information can be recorded in multiple log streams and determined by the dataset name beginning with IFASMF, which is used by the VTB rule for SMF.
  • In-memory SMF data offers real-time access and can be read directly from the z/OS system buffer.
Upon DVM server initialization, SMF connects to the in-memory resource and continuously reads a buffer of SMF activity using a REXX procedure. The REXX procedure is responsible for reading dataset names from in-memory objects.
From a DVM server perspective, the SMF dataset is driven by the Server Event Facility (SEF) rules. SEF rules are provided with default values in member hlq.AVZS.SAVZXVTB(AVZSMFT1). It is used when a table with the prefix 'SMF_TYPE_' is found in the SQL statement. It is used to specify the base map name and the dataset name for SMF tables in a Global Variable. A dataset name can be specified for a specific table (SMF record type) by creating a global variable for the table name. This allows applications to use other SMF data sources without exposing their names.
This REXX procedure provides the name of Datasets or In-Memory objects that need to be read (a global variable named VTB.OPTBDSNA is going to be completed at execution).
Note:
You must at least define the global variable GLOBAL2.SMFTBL2.DEFAULT to make these rules working. These VTB rules can also be customized according to your needs and naming conventions.
To configure access to System Management Facility (SMF) files, you need to configure the server started task JCL, the server configuration member, and the server virtual table member. To enable reading SMF data in real-time in logstreams, you must have the SMFPRMxx member in the system PARMLIB dataset configured to use both log streams and in-memory resources.
SMF dataset names are dynamic in local environments and require SEF rules enablement and optionally Global Variables set to specific values to provide dataset names to the virtual tables and views from SMF datasets or logstream configurations.
You can choose either GDG dataset name to support or dynamic dataset name support, or both, to quickly access your SMF data. These two options are provided for your convenience to help you start accessing your SMF data. Custom rules likely need to be developed to use your local naming convention to access your SMF files. It is common to use GDG datasets to export SMF Data automatically to disk from a fixed GDG base name.
SMF from GDG datasets
Enable read access of SMF data from GDG datasets, as well as access to SMF data through dynamic dataset names, by enabling Data Virtualization Manager Server Event Facility rule AVZSMFT1.
DVM server:
Rules Mgmt > SEF Rule Management > VTB > Enable > Auto-enable
To configure the access method, use the following method:
In the Global Variables display of the DVM server ISPF panel, update the Global Prefix to GLOBAL2, then configure the SMF data access for the SMFTBL2 dataset. DEFAULT variable should have a corresponding SMF dump dataset name if used. This option is used to specify the source SMF.
GLOBAL2.SMFTBL2.DEFAULT = "YOUR.DATASET.SMF.GDG"
This syntax is going to be useful if we want to read the FULL GDG dataset.
Pro tip:  Be careful to define the dataset name using uppercase. If you specify the correct name, but in lower or mixed cases, the allocation fails.
To be able to filter out or select specific GDG members, we are going to configure other variables. Here are the other variables you could add. For example, to add "TODAY", in the command line of the Global Prefix "GLOBAL2.SMFTBL2", enter S TODAY and exit edit mode by pressing.
GLOBAL2.SMFTBL2.TODAY           = "YOUR.DATASET.SMF.GDG(+0)"  (for today's GDG only)
GLOBAL2.SMFTBL2.YESTERDAY = "YOUR.DATASET.SMF.GDG(-1)"                 (for yesterday's GDG only)
  
Now let's test our definitions are correctly defined in executing a query against our GDG dataset. In Data Studio, which was used earlier to access VSAM files, we are going to edit and run the following query:
SELECT * FROM SMF_07001_YESTERDAY
Let's execute the query, we get the following result as shown in Figure 26.
Screen Shot 2021-06-01 at 3.18.42 PM
Figure 26 - Result from SQL Query on SMF70 records from Yesterday
If we want to change the default GDG Dataset name, we can either change the VTB Global Variable as shown earlier or submit the new GDG Dataset name in the SQL Query. To pass a dynamic dataset name to query an SMF dataset we use the following format for the table name in the SQL statement:
Where:
- TableMapName__DataSetName
- TableMapName is SMF_07001
- DatasetName is prefixed by two underscores (__) and the periods in the dataset name are replaced with single underscores (_).
Edit and run the following SQL from Data Studio to get the results shown in Figure 27. To display SMF records from "Today", run the following Select statement and use parenthesis in the SQL and double quotation mark for the table name:
SELECT * FROM "SMF_07001__SMF_RECORDS_ZB01_SMF_SAVE(+0)"
Screen Shot 2021-06-01 at 3.18.15 PM
 Figure 27 - Result from SQL Query on SMF70 records from a dynamic Dataset name
SMF from Logstream
Another way to read SMF data is to connect to a Logstream to have more real-time SMF Data to read. Enable rule AVZSMFT1 and add the following Global Variable to the existing ones:
GLOBAL2.SMFTBL2.LOG = "LOGSTREAM.dataset.name"
Figure 28 displays the current SMF PARMLIB member associated with the DVM server. The SMFPRMxx member can be modified to make any change to the SMF collection. SMFPRMxx members are located in the z/OS PARMLIB Dataset and can be modified to change the SMF recording interval and SMF types for the collection.
Screen Shot 2021-06-01 at 3.15.21 PM
Figure 28 - Displaying the current SMF PARMLIB member
Figure 29 displays the PARMLIB(SMFPRMxx) member.

Screen Shot 2021-06-01 at 3.15.59 PM

Figure 29 - SMFPRMxx PARMLIB member
The example collects SMF Data every 5 minutes (INTVAL(05)) across all SMF Types, EXCEPT ranges from 16 - 19, 62 to 63, 65 to 69, 99, 100 to 102, 110, 119 to 120. Any changes to this member need to be submitted in the SDSF Log to take into account our changes: /SET SMF=xx
Test that the definitions are correctly defined by executing a query against the LOGSTREAM. Edit and run the following query in the DVM Studio, as shown in Figure 31.
SELECT * FROM "SMF_07001_LOG" LIMIT 1000;
Screen Shot 2021-06-01 at 3.17.43 PM
Figure 31 - Result from SQL Query on SMF70 records with Logstream
In-memory SMF access
Another way to read SMF data is to connect to In-Memory buffers directly. This approach bypasses the SMF Dump to GDG Dataset and SMF LOGSTREAM Intervals. The method is similar to reading GDG or LOGSTREAM datasets.
In addition, we need to modify the DVM configuration member AVZINS00 by adding the following statements after the GLOBAL PRODUCT OPTIONS statement.
IF DoThis 
THEN DO 
"DEFINE SMF NAME(IFASMF.INMEM)", 
"STREAM(IFASMF.ZB01.INMEM)", 
"BUFSIZE(500)", 
"TIME(0)" 
END 
Pro tip:   You must have your SMFPRMxx member in the system PARMLIB dataset configured to use log streams and in-memory resources.
NAME is the name of the INMEMORY resource matching the name of the resource defined to SMF with the INMEM parameter. If this parameter is included, the INMEMORY API is read continuously and a buffer of the most recent records are maintained. Either this parameter or the STREAM parameter, or both, must be specified. This parameter must begin with IFASMF.
Looking at the SMFPRMxx member in z/OS system PARMLIB as presented in Figure 32, the INMEM parameter as an in-memory resource to record SMF records in memory for real-time processing.
Screen Shot 2021-06-01 at 3.33.04 PM
Figure 32 - INMEM parameters in SMFPRMxx PARMLIB member
The syntax for the INMEM parameter in SMFPRMxx is:
INMEM(rname, RESSIZMAX({nnnnM|nG}), {TYPE({aa,bb|aa,bb:zz|aa,bb:zz,…})| NOTYPE({aa,bb|aa,bb:zz|aa,bb:zz,…})}
Subparameters are specified as follows:
  • "rname" is the name of the in-memory resource.
  • RESSIZMAX defines the size of the buffer available for this in-memory resource, in megabytes or gigabytes.
  • TYPE defines the SMF record types that are to be recorded to this in-memory resource.
  • NOTYPE directs SMF is to collect all SMF record types, except record types explicitly specified.
Check the DVM server to ensure that In-Memory Logstreams are updating the internal buffers, as shown in Figure 33.
Screen Shot 2021-06-01 at 3.33.53 PM
Figure 33 - DVM server Management Menu
The internal buffer status for the In-Memory resources defined earlier in SMFPRMxx is shown in Figure 34. The streams are Enabled and Active with available records.
Screen Shot 2021-06-01 at 3.34.11 PM
Figure 34 - Displaying current SMF Real-Time streams.
Use the following command to display SMF recording parameters, and verify In-Memory streams are active, as presented in Figure 35.
Screen Shot 2021-06-01 at 3.34.37 PM
Figure 35 - Displaying SMF recording parameters from LOGSTREAM
Similar to GDG or LOGSTREAM, enable rule AVZSMFT1 in the VTB ruleset in the DVM server. In the Global Variables display, perform the following steps:
  1. Change Global Prefix to GLOBAL2.
  2. Select SMFTBL2, as shown in Figure 36.

    Screen Shot 2021-06-01 at 3.35.34 PM
    Figure 36 - Editing SMFTBL2 VTB rule
  3. Configure the SMF data access option for IN-MEMORY by adding the following Global Variable to the existing ones by typing at the command lines. 

    S IM = "IFASMF.INMEM"
    S IM2 = "IFASMF.INMEM.Db2"
  4. You should see the new Global Variables in the list:

    GLOBAL2.SMFTBL2.IM = "IFASMF.INMEM"
    GLOBAL2.SMFTBL2.IM2 = "IFASMF.INMEM.Db2"


    Pro tip: Be careful when defining the dataset name. You must enter the name in the upper case. If you specify the correct name, but in lower or mixed cases, the allocation fails.
  5. Submit the following SQL Query to display SMF30 records (which are collected), from the IFASMF.INMEM buffer, as shown in Figure 37 displays records that are captured in real-time through in-memory SMF collection. The SQL syntax for Virtual Tables is composed of the Table Mapping (SMF_03000) in conjunction with IM (IFASMF.INMEM) separated by a 'single' underscore "_".
     
    SELECT * FROM SMF_03000_IM LIMIT 10000;
 Screen Shot 2021-06-01 at 3.39.56 PM
Figure 37 - Result from SQL Query on SMF30 In-Memory records
How SMF records are mapped in DVM for z/OS
While Data Studio makes it easy to access fields in SMF records, you still need to understand the underlying data and how it is structured. SMF records are typically variable in length and allow the same record type to contain various amounts of information.
This mechanism is a flexible and effective way to present the maximum amount of information in the smallest amount of space.  Maintain relationships between the rows in the various tables, by adding a field to the table containing the base part of the record and a corresponding field in the tables containing the repeating sections.
The DVM Studio shows nearly every record type that is mapped. There is one called SMF_tttss, and one or more called SMF_tttss_aaaaaa, where ttt is the record type (in decimal), ss is the subtype, and aaaaaa is a string of characters and numbers that indicate the repeating section that resides in that table. For example, the type 70 subtype 1 record is loaded into the following tables:
  • SMF_07001
  • SMF_07001_SMF70AID
  • SMF_07001_SMF70BCT
In DVM terminology, the table that contains the record header is called the base table and the tables that contain the repeating sections are called subtables. The base table contains a generated column called ‘CHILD_KEY’, and the subtables contain a generated field called ‘PARENT_KEY’. All the rows in the base table and the subtables that have the same CHILD_KEY and PARENT_KEY values came from the same SMF record.
If you want to extract fields from the base table and from repeating sections that were in the same record, you execute a JOIN between the PARENT_KEY and CHILD_KEY fields - for example:
SELECT SMF_TIME, SMF_SID, SMF_SEQN, SMF70VPA, SMF70BPS, 
FROM SMF_07001 A0 JOIN SMF_07001_SMF70BPD A9 
ON A0.CHILD_KEY = A9.PARENT_KEY; 
Which SMF record types are supported?
Rocket is constantly developing support for more SMF record types and shipping PTFs to deliver that support to customers. If you are trying to determine if a record type is supported, the easiest way to do that is to scroll through the list of support virtual tables in the DVM Studio.
You can also get a list of the record types and the field names (but not the subtable names) from the ISPF interface. As presented in Figure 38 from the primary DVM server menu.
Screen Shot 2021-06-01 at 3.43.01 PM
Figure 38 - Displaying Maps in the DVM server
There is a row for each record type and subtype as shown in Figure 39.
Screen Shot 2021-06-01 at 3.43.21 PM
Figure 39 - SMF records Mappings
Enter an X next to the base table and a list of all the fields in that base table and all of its subtables is presented in Figure 40.
Screen Shot 2021-06-01 at 3.43.59 PM
Figure 40 - Displaying Map for SMF70 records
By scrolling to the right you can also see the definition of each field (its format, length, offset, and so on) like in Figure 41.
Screen Shot 2021-06-01 at 3.44.27 PM
Figure 41 - Displaying SMF70 records mapping definitions
Db2 unload datasets
To be able to access a Db2 unload dataset directly with an SQL query, you must configure a virtual table rule to define the Db2 unload dataset name to the Db2 virtual table. To configure access to a Db2 unload dataset, you must add the Db2 unload dataset name to the Db2 virtual table in a Data Virtualization Manager Server Event Facility (SEF) virtual table rule. With this access, you can issue SQL queries directly against Db2 unload datasets for existing Db2 virtual tables.
Switching a Db2 virtual table to read an unload dataset is done by assigning a dataset name to the table in a virtual table rule. The VTB global variable vtb.optbdsna is used to redirect access from Db2 to reading the sequential file named in the variable. The named sequential file must contain the unload data created by the Db2 UNLOAD utility. A model VTB rule, AVZMDLDU, is provided to demonstrate redirecting a Db2 virtual table to a Db2 unload dataset.
For the example presented in Figure 42, consider a virtual table named DW01_DSN81210_EMP that maps to the EMP table in the Db2 subsystem DW01.
-- Description:  Retrieve the result set for DW01_DSN81210_EMP (up to 10000 rows)
-- Tree Location: 10.3.58.61/1200/SQL/Data/AVZS?Virtual Tables?DW01_DSN81210_EMP
-- Remarks: DRDA - DSN81210.EMP
SELECT * FROM DW01_DSN81210_EMP_ LIMIT 10000;
Screen Shot 2021-06-01 at 3.48.26 PM
Figure 42 - DW01_DSN81210_EMP Virtual Table
By activating the model rule AVZMDLDU, you can query an unloaded sequential dataset named DSNDW00.UNLD.DSN81210.EMP by issuing the following query, as shown in Figure 43:

SELECT * FROM MDLDU_DW01_DSN81210_EMP__ARNOULD_DW00_UNLD_DSN8D12A_DSN8S12E
-- Description:  Retrieve the result set for DW01_DSN81210_EMP (up to 10000 rows)
-- Tree Location: 10.3.58.61/1200/SQL/Data/AVZS?Virtual Tables?DW01_DSN81210_EMP
-- Remarks: DRDA - DSN81210.EMP
SELECT * FROM MDLDU_DW01_DSN81210_EMP_ARNOULD_DW00_UNLD_DSN8D12A_DSN8S12E;
Screen Shot 2021-06-01 at 3.50.31 PM
Figure 43 - Result from SQL Query access to an UNLOAD Dataset for DW01_DSN81210_EMP
The AVZMDLDU rule performs the following steps:
  1. Extracts the table name DW01_DSN81210_EMP and sets the VTB global variable vtb.optbmtna.
  2. Extracts the dataset name ARNOULD_DW00_UNLD_DSN8D12A_DSN8S12E, converts the underscores to periods, and sets the VTB global variable vtb.optbdsna.
The following restrictions and considerations apply for this feature:

SQL access to Db2 unload files is limited to SQL queries only.
- The columns in the Db2 virtual table definition must exactly match the table unloaded in Db2.
- To use this feature, the corresponding Virtual Table must exist in the DVM server

The sample rule AVZMDLDU can be used as a reference for further customization. When customizing this rule, more logic is likely needed to be added if different unload datasets require different VTB variable settings for CCSID or internal/external format.
  1. Customize the Data Virtualization Manager configuration member (AVZSIN00) to enable virtual table rule events by configuring the SEFVTBEVENTS parameter in the member, as presented in Figure 45 and as follows: "MODIFY PARM NAME(SEFVTBEVENTS) VALUE(YES)"

    Screen Shot 2021-06-01 at 3.52.46 PM
    Figure 45 - Activating SEFVTBEVENTS in AVZSIN00 member
  2. Access the VTB rules, as follows:
    1. In the Data Virtualization Manager server - Primary Option Menu, specify option E, Rules Mgmt.
    2. Specify option 2, SEF Rule Management.
    3. Enter VTB for Display Only the Ruleset Named, like in Figure 46.

      Screen Shot 2021-06-01 at 3.53.21 PM\

      Figure 46 - Displaying VTB Rules only 
  3. Customize the AVZMDLDU rule, as follows:
    1. Specify S next to AVZMDLDU to edit the rule, like in Figure 47
      Screen Shot 2021-06-01 at 3.54.42 PM
      Figure 47. Editing VTB rule AVZMDLDU
    2. Find the vtb.optbdsna variable and specify the name of the Db2 unload dataset to process, as presented in Figure 48.

      Screen Shot 2021-06-01 at 3.55.34 PM
      Figure 48 - vtb.optbdsna variable in AVZMDLDU rule

Pro Tip:  If you update the sample AVZMDLDU rule and then provide a default value for the vtb.optbdsna variable that doesn't require the correct dataset name in the SQL statement for execution can run and return the values from the default UNLOAD dataset, as shown in Figure 49.

 
-- Description:  Retrieve the result set for DW01_DSN81210_EMP (up to 10000 rows)
-- Tree Location: 10.3.58.61/1200/SQL/Data/AVZS?Virtual Tables?DW01_DSN81210_EMP
-- Remarks: DRDA - DSN81210.EMP
SELECT * FROM MDLDU_DW01_DSN81210_EMP_WHATEVER_DATASET;
Screen Shot 2021-06-01 at 3.58.36 PM
Figure 49 - Result from SQL Query specifying UNLOAD Dataset name.

If we don't want to have this behavior, then we don't need to modify the sample rule variable vtb.optbdsna variable. Every SQL needs to specify the correct UNLOAD dataset name to work properly.
  1. Update rule options as needed. Figure 50 describes the VTB rule options that support Db2 unload dataset access.

    Screen Shot 2021-06-01 at 3.59.27 PM
    Figure 50 -  Rule options for AVZMDLDU rule
VTB variable descriptions:
- vtb.optbdlcv - If the data was unloaded with a DELIMITED statement, set vtb.optbdlcv to 1 to declare the data is in delimited format. It might be necessary to declare the delimiters if the default column
   delimiter (,) and character string delimiter (“) were overridden when the data was unloaded.
vtb.optbdsna specifies the name of the sequential unload dataset created by the Db2 UNLOAD utility to access.
vtb.optbduif - By default, the Db2 unload utility writes data in external format. If FORMAT INTERNAL is used when unloading data, vtb.optbduif must be set to 1 to declare that the data was unloaded in
   internal format.
vtb.optbmtna specifies the map name of the Db2 virtual table describing the unload file.
- vtb.optbtbcc - if the table CCSID is not compatible with the CCSID defined for the SQL engine (AVZSIN00 SQLENGDFLTCCSID parameter). 
   vtb.optbtbcc can be used to declare the CCSID of the data. It is important for Unicode tables and tables containing GRAPHIC columns.
4.  Enable the rule by specifying E next to AVZMDLDU and pressing Enter.
 
5.  Set the rule to Auto-enable by specifying A next to AVZMDLDU like in Figure 51 and pressing Enter. Setting a rule to Auto-enable activates the rule automatically when the server is restarted.

    Screen Shot 2021-06-01 at 4.01.34 PM
      Figure 51 - Auto-Enabling AVZMDLDU VTB rule

[{"Type":"SW","Line of Business":{"code":"LOB10","label":"Data and AI"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SS4NKG","label":"IBM Data Virtualization Manager for z\/OS"},"ARM Category":[{"code":"a8m0z000000cxAOAAY","label":"SQL Engine"},{"code":"a8m0z000000cxATAAY","label":"Studio"},{"code":"a8m0z000000cxAZAAY","label":"z\/OS Connect"}],"Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"All Version(s)"}]

Product Synonym

DVM

Document Information

Modified date:
30 June 2021

UID

ibm16455669