Transmit metadata from DBDEF Tables to other hosts

TPFUG_Req_Number: DF00176
Contact Originator Id: claudio.jorge@eds.com
Abstract: TPFDF should provide the capability to replicate or transmit a structured and formatted copy of the Database Definitions (DBDEF) table data to other host systems connected to TPF. The other systems could be UNIX or UNIX Clones, OS/390, Windows or generally any system that supports a network API like TCP/IP.
Description: A Data Dictionary or some form of Meta Data Repository is critically required to manage and administer a complex database environment such as TPF typically supports. Since the requirement for a data dictionary has previously been submitted and rejected, an alternative is needed. One possibility is to provide a mechanism or means to transport or send the data to an offline environment. Once there it can be imported into one of many commercially available Data repositories or users can develop their own simplified versions to allow better management of TPF databases. Since TPFDF allows for non-TPF data files to be defined in the DBDEF, a fairly complete snapshot of the TPF can be maintained.

The replication could be for the entire DBDEF, selected files (e.g. based on wildcarding) or specific files. The data could be organized according to the current DBDEF structure or some intermediate format more suitable for porting to a relational database. The transmission could occur during cycle to NORM or on request via a "Z" entry. The data could be structured to mirror the DBDEF or could be massaged into some intermediate format more suited to a relational database or perhaps in a form suited to XML.
Critical Success Factors: The solution should be generic enough to fit the needs to a diverse customer base with many different types of connectivity options. It should be flexible enough to allow or support either incremental (e.g. after a DBDEF load) or full dumps. At the same time, it should not interfere with online operations or add additional complexity to the TPF environment.
Alternative Solutions: An obvious alternative is to provide full data dictionary capabilities within the TPF environment. This is difficult to cost justify or tailor to satisfy every need.

Another alternative is for each user to develop their own solutions. The building blocks are available in TPF. However, these roll your own solutions would require too much customization on the TPF side and would lack consistency and standardization.

Another typical solution would be to do a DBDEF display and scrape the screen or use terminal API's (but that is to 80's)
Solution Considerations: There are several critical solution considerations. One is the connectivity option. There are various TPF tools and connectivity options available that could be used to support this facility. TPFAR (as with continuous data collection) is an obvious choice, as are MQ Series, TCP/IP and even FTP. Each of these share a common element, in that the DBDEF has to be scanned first and converted into an intermediate or structured data stream before it can be transmitted. That is the second consideration. How should the DBDEF be read (either core copy or the file copy)? What will be the intermediate format of the data? For example a TPF segment could read the DBDEF and build a file in the TPF File System which could then be transmitted via FTP. That leads to the questions of who initiates the connection, controls the transmission and the timing of the transmission, e.g. every IPL, on demand through ZUDFM or DBDEF INIT entries.