Database Access Middleware:
Standardization and Enterprise Wide Deployment

A White Paper by StarQuest Software, Inc.

INTRODUCTION 

BENEFITS OF DATA SHARING  

DATA SHARING TRENDS 

DATABASE ACCESS MIDDLEWARE ARCHITECTURE 

EVALUATION CRITERIA  

BENEFITS OF STANDARDIZATION
AND ENTERPRISE DEPLOYMENT
 

CONCLUSION 


Introduction

A recent poll showed that 94% of IT executives agree that direct access to mainframe and minicomputer data is important to operations (Source: IDC). The critical component for achieving this is the connection between desktop systems and the host resident data. StarQuest's StarSQL Enterprise Edition (StarSQL EE) database access middleware has emerged as the leading product for linking Windows desktops with IBM's DB2 relational database. StarSQL EE has achieved this with seamless, standards-based, integration with the Windows desktop environment, support for a wide range of available network infrastructure products and the entire range of DB2 implementations. 

This document discusses the benefits of sharing data directly with applications and the types of solutions commonly used to accomplish this. Within the framework of current and future data sharing trends, the document presents evaluation criteria for clearly understanding how to make the right choice for implementing client server solutions with DB2. Finally, the document explains the benefits of making StarSQL EE part of the enterprise standard Information Technology (IT) framework. 

Excerpts from case studies and information associated with StarQuest's partner relationships with Microsoft, IBM and Cisco are included to illustrate the benefits of standardization and enterprise-wide deployment of StarSQL. 

Benefits of Data Sharing 

"Providing direct access to our DB2 data is an integral part of our IT solution." Henry Slack, Chief Technology Officer, Employer's Reinsurance Corp. 

Sharing data directly has become an integral part of Information Technology strategy. The benefits are considerable, with a guaranteed return on investment. A recent poll shows that 70% agreed that it is best to distribute applications to the desktop while centralizing data on their mainframe systems (Source: IDC). 

The primary impetus for this trend is based on the efficiency of Graphical User Interface (GUI) applications. When compared with traditional host-based screen oriented applications, desktop based GUI applications are faster to navigate and give the users more of the features they need. The result is more efficient tools for accomplishing the requirements of day-to-day operations. The savings in operations from new client server applications are substantial. 

While distributing applications out to the desktops is very effective for users, the data assets of most organizations continue to reside on host systems. The host systems are uniquely qualified for this, having been perfected by years of mission critical operation. When combined, the effectiveness of GUI applications and the dependability of host have generated the requirement for data access middleware. 

"We need to get data to our analyst. They determine what treatments are effective and that in turn, benefits everyone." Julia Chan, Consultant, Kaiser Permanente 

Organizations that provide direct access to data assets can realize immediate returns by reducing standing inventories, speeding effective medical treatments to market or providing outstanding services to customers. Data sharing provides solutions for critical business related requirements that challenge an organization's effectiveness. Reduced development costs, efficient hardware usage and savings on maintenance are additional areas where dramatic cost savings occur. 

"Our development projects required our DB2 data be made readily available to our NT environment where the majority of our developers and users reside." Dave Calenda, Manager of Plant Infrastructure, Nabisco 

The alternatives to direct DB2 access are indirect methods that all have expensive limitations. Screen scraping, file transfer and Advanced Program to Program Communication (APPC) all fail to provide the fundamentally necessary service—seamless, bi-directional flow of record level data from any application and DB2. 

Data Sharing Trends 

There are three predominate methodologies for sharing data that have emerged. They are: 

  • Two-tiered Client Server
  • Three-tiered Client Server
  • Distributed Architecture

Two-tiered Model 

"Our analyst's tools are all on the desktop. They need access to the most recent patient data and that resides within DB2. Using StarSQL, our analysts import data directly into their spreadsheets doing in one step that which once took six steps and a programmer." Julia Chan, Consultant, Kaiser Permanente 

The Two-tiered Client Server model, the so-called "fat" client model, is a solution where applications reside on desktop systems and connect directly to the host resident data. An example of Two-tiered architecture is connecting your spreadsheet directly to your database. The "fat" refers to the many layers of software installed on the client, that provide the user interface and connection services to the data. 

More and more organizations are using Visual Basic, Visual C++ or PowerBuilder to create desktop applications. Prerequisites for adopting a fat client methodology are: 

  • Dependable data access middleware
  • Centralized management of the desktop environments

The control of software distribution to the client systems is generally implemented with a third party management tool. The advantages to the Two-tiered model are its relative simplicity and speed. 
 
Various tiered architectures provide options for organizations to access data directly. 

Three-tiered Model 

"Now our customers can track a shipment right from their web browser. With StarSQL Pro we publish DB2 data directly to the web." Bob Towle, MIS Director, Eagle USA Airfreight 

The Three-tiered Client Server model, the "thin" client model, allows desktops to access data from an intervening system that provides data acquisition services on behalf of the clients. An example of this is a browser client accessing records through a web server that in turn, connects to the host resident data. Here, "thin" reflects that the client can now be a simple system that runs nothing more than a browser? for example, a network computer (NC). The use of intermediate servers alleviates the need for managing software at the client. 

Distributed (N-Tiered) Model 

"Data can come from anywhere in our Network and our applications use it, as is, when it gets there." Dave Calenda, Manager of Plant Infrastructure, Nabisco 

Distributed Architecture is a descendent of Two- and Three-tiered Client Server that has evolved into a whole new class of solution. In the Distributed Model, the source of applications and data are completely abstracted in a network. The Common Object Broker Relational Architecture (CORBA) and Distributed Common Object Module (DCOM) architectures have emerged as the leading trends for solutions of this kind. While solutions of this sort are intricate, their advantage lies in their ability to evolve as computing trends evolve. 

Benefits of Client Server Solutions 

Each type of solution has its merits and is appropriate depending upon the data access requirements of the application. For example Two-tiered solutions are great when implementing update intensive applications or applications that require access to up-to-the-minute data. Three-tier solutions can provide wide access to data assets without client development. StarSQL EE provides the flexibility needed to implement all kinds of solutions and remove licensing restriction that penalize organizations for changing their strategy or mixing the different solution architectures. 

Database Access Middleware Architecture 

The key technology for implementing data sharing solutions is database access middleware. This is the conduit for seamlessly delivering data between the database and application. StarSQL EE is database base access middleware that resides entirely on Windows clients. Understanding the different architectures of the available solutions illustrates why StarQuest's approach is the easiest, simplest and offers the highest performance. 

Host Centric Solutions 

The first generation of database access middleware solutions was implemented by third party applications that resided on the host. Access from the desktop is enabled by an Open DataBase Connectivity (ODBC) interface, a proprietary Application Program Interface (API), or both. The database commands are sent to the host application enclosed in a proprietary data stream where they are interpreted by the host application and executed locally. The results are gathered and returned to the client. The host application acts as a "proxy" process, executing SQL commands for the client application. 

At the time, the proxy offered benefits that were unmatched by DB2. This included access to non-relational data and support for more network connection options. When IBM added service for processing remote data requests as part of DB2, the advantages of third party host-resident solutions rapidly diminished. 

As with any proprietary software, the expense of purchasing and maintaining the component is considerable, especially when the comparable function is offered as a no charge, standard feature of DB2. In addition the host component tends to consume expensive host processing resources and only provides services for specific hardware and operating systems. In all, the host based proxy solutions suffered from enough flaws that other solutions were soon brought forward. 
 
Host-based proxy server configuration. 

Proprietary Gateways 

The next improvement in database access middleware was the proprietary gateway solution. Instead of implementing a host component, this solution used IBM's Distributed Relational Database Architecture (DRDA) to provide direct access to DB2. This had the benefit of reducing host CPU usage and the cost of purchasing and maintaining a host component. Once again, an ODBC interface, a proprietary 

API, or both enable access from the desktop. The gateway is responsible for translating the data stream appropriately for use on the host and the client system. 

While this approach addressed the issue of proprietary host components, it introduced its own set of unique problems. By using the gateway to translate the transactions of every client system a processing bottleneck is created. As more clients were added the more gateways were required. The addition of clients always results in a performance impact. The proprietary gateway approach led to the unfair and inaccurate assessment that DRDA was slow. In reality it was the processing bottleneck that was responsible for the poor performance. 
   
Proprietary gateway causes a processing bottleneck by translating the transactions of every client.  

Client Centric Solution  

The latest implementation of database access middleware is a client-only methodology. The client is responsible for translating ODBC and DRDA standards for its own transactions. In this model bottlenecks are eliminated, host CPU utilization is minimized and the cost of ownership is reduced. The client-only model provides a complete standards-based solutions that is efficient, easy to maintain and scalable.  

The simplicity of the design and appropriate division of processing responsibility make for a fast, dependable and affordable method for taking advantage of client server computing in the DB2 environment.  

Evaluation Criteria 

Once the benefits of data sharing and the role that database access middleware plays are understood, defining the criteria for evaluating the choices becomes simple. The categories used to evaluate the merits of database access middleware are:  

  • Performance
  • Stability
  • Usability
  • Value

The relative importance of any particular category can vary from application or organization, but the categories themselves are requisite. A failure to meet any of the criteria makes a product unusable. Each one of these categories and how to evaluate them follows in this section.   

Performance  

"StarSQL EE is 100% faster than any other product we tested." Dan Garlewicz, Network Manager, Nabisco  

"I am interested when a product can show a 15% to 100% performance increase. In some cases StarSQL was four times faster than our previous middleware component —this translated into big savings." Henry Slack, CTO, Employer's Reinsurance Corp 

Performance means the amount of work done. This translates directly to cost. The number of transactions processed is a function of software design, network infrastructure, hardware and load. StarSQL Pro is engineered to maximize performance in all of these areas. StarSQL Pro leverages low cost desktop CPU rather than creating bottlenecks relying on gateways or the host for processing power.  

"Accessing DB2 data via DRDA saves up to 80% on host CPU usage when compared to using query tools on the host." Curt Cotner, IBM Santa Teresa Labs  

"StarSQL Pro had the least impact on our network resources." Dave Calenda, Manager of Plant Infrastructure, Nabisco  

StarSQL EE eliminates the need for cumbersome proprietary host software and does not require any additional application processing on the host. It minimizes traffic on the network by only transferring the information necessary to complete each transaction. StarSQL EE spreads the processing load throughout the user environment so every user gets consistently high performance all the time.   

Stability  

"Microsoft only uses the best." Vesa Suomalainen, Director of Product Strategy, Microsoft  

Stability means dependability. It is important to consider the dependability of the vendor as well as the product. Every business has a market driven incentive to field products that work and to provide fixes for their products when problems arise. When companies like Microsoft, IBM and Cisco Systems look for a partner, excellence is the only acceptable standard. StarQuest Software's long standing partnership with Microsoft, IBM and Cisco Systems has shown that StarQuest meets this obligation.  

Microsoft BackOffice bundles StarSQL with every package. As a part of this agreement, StarQuest must maintain the highest level of compatibility with Microsoft products. Microsoft provides worldwide support for StarSQL and holds the code in escrow to insure ongoing availability. This relationship has resulted in making StarSQL the database access middleware that works best with all Windows operating systems.  

"StarQuest's support has been a key in moving DRDA forward as an industry standard." Mel Zimowsk, DRDA Specialist, Senior Software Architect, IBM  

StarQuest Software is a licensee of IBM Distributed Relation Database Architecture (DRDA). This is the same architecture that IBM uses to provide interoperability with all of its DB2 relational database products. StarQuest has the most complete offering of the IBM architecture available today. In addition, StarQuest is a Blue Ribbon business partner with IBM and is currently selling and marketing products jointly developed with IBM.  

"StarQuest has a place in Cisco's long term plans." Cliff Meltzer,VP and General Manager of IOS Technology and Engineering Operations, Cisco Systems  

StarQuest is a charter member of Cisco's Enterprise Associates Program and StarSQL EE is the only database access middleware certified to work with Cisco's IOS operating system. StarQuest has jointly developed software, the Cisco Transaction Connection v1, currently available as part of Cisco's operating system. Cisco's confidence in StarQuest is underlined by member representation on StarQuest's board of directors.  

StarSQL Pro has been commercially available since February 1995 and is currently in production at over 500 sites. All of this adds up to the most dependable database access middleware product available today.   

Usability  

It is not enough that a product is fast and dependable. The challenge is effectively deploying the solution to the user community. StarSQL EE excels at providing maximum usability. There are several issues to consider when determining the real usefulness of a database access middleware product as an organization wide standard. They include:  

  • Compatibility with existing hardware and software
  • Desktop management and configuration
  • Fault tolerance and use under load
  • Licensing options

In order to be useful, a product must work with the existing components of the IT infrastructure. This includes:  

  • Network Infrastructure
  • Applications
  • Databases
  • Operating Systems
  • Hardware Platforms

"StarSQL EE allowed us to connect all our TCP/IP desktops, through Cisco routers, to DB2 4.1 on our SNA backbone. We didn't expect to get that kind of flexibility." Henry Slack, CTO, Employer's Reinsurance Corp 

StarQuest's commitment to standards and close ties to the leading network and application vendors work together to make StarSQL EE the most useful database access product available. StarSQL Pro works with TCP/IP, SNA, or both. StarSQL works with all leading IBM network connectivity products including Microsoft SNA Server, Novel NetWare for SAA, and Cisco Transactioin Connection v1.  

"StarSQL Pro connects all of our 16 and 32 bit operating systems to all of our AS400's and our mainframe. This made our choice easy." Dan Garlewicz, Network Manager, Nabisco  

StarSQL Pro implements the highest level of ODBC compatibility available. This means that StarSQL can take advantage of advanced client server tools like Microsoft's Remote Data Objects or ActiveX Data Objects, or PowerBuilder to it's fullest capability. StarSQL connects to all DB2 products on any hardware platform and supports all Microsoft, Windows operating systems.  

"We use Tivoli to manage our desktop environments. StarQuest silent install options makes it a perfect fit for centralized desktop management." William Gee, Technical Specialist, Employer's Reinsurance Corp.   

Managing desktop software has become a major concern for IT managers. Installing software and configuring many desktops becomes a critical item for deployment. StarSQL EE is engineered to make the task of managing desktops easy. Along with support for management tools from Microsoft, Tivoli and Seagate, StarSQL EE has built in support for network installation and configuration. This insures easy deployment for any size installation.  

"We only pay for what we use. It's not a hassle to maintain compliance and we can count on the service being available to all our users." Jeri Mahoney, Systems Specialist, Bridgestone/Firestone  

StarQuest provides flexible licensing strategies to match deployment and usage requirements.  

StarSQL supports high availability implementations from Cisco, IBM and Microsoft to ensure that your applications are available 24 hours a day, 365 days a year.  

Overall Value  

"We use stored procedures extensively. StarQuest helped us find what worked best." David Calenda, Manager of Plant Infrastructure, Nabisco  

StarQuest provides outstanding value along with its solid performance, stability and ease of use. StarQuest's focus on DB2 access and dedication to working as partners with our clients has provided the experience necessary for understanding the challenges of getting the most out of DB2. Bundled CASE tools, sample code and applications, automatic static SQL support and convenient tracing facilities ease the tasks associated with client server development.  

"StarQuest's customer support is always helpful and responsive. We have no complaints. Around here that's high praise." Henry Slack, CTO, Employer's Reinsurance Corp.  

StarQuest works with customers to answer questions, plan installation and deployment, tune performance and develop appropriate client server solutions. StarQuest's customer support department is knowledgeable, helpful and available 24 hours a day, 7 days a week.  

"When I call StarQuest I know I'm going to get results." Julia Chan, Consultant, Kaiser Permanante  

Benefits of Standardization and 
Enterprise Deployment

Organizations benefit when StarSQL EE is part of the enterprise standard. The benefits can be realized financially, operationally and with increased productivity.  

"If you call any ERC office you will get the same results in the same amount of time. This is one of the results of using StarSQL EE throughout our enterprise." Henry Slack, CTO, Employer's Reinsurance Corp.  

The initial purchase price of a software package is only a fraction of the total cost of ownership. While purchasing a site license greatly reduces the per use cost of StarSQL, greater savings come from a reduced cost of ownership. The cost reduction is realized in consolidated training, efficient usage, consistent performance and most importantly only paying for what you actually use. Operationally standardizing on StarSQL EE makes it easy to comply with copyright laws and improve accountability. StarSQL EE works with your network infrastructure so it is easy to manage.  

"Effective treatments keep patients from being readmitted to the hospital. With direct access to the critical data our analysts are able to find new ways to make this happen." Julia Chan, Consultant, Kaiser Permanente  

Making a commitment to sharing data and using StarSQL EE database access middleware allows you to rejuvenate existing applications and enables new applications for increased productivity. Users gain access to data and work with familiar desktop tools, allowing them the opportunity to make innovation and contributions as a part of their daily routine. With StarSQL EE, an organization can put this functionality on every system without a penalty for systems that do not use it.  

Conclusion

  "I recommend StarSQL EE without reservation." David Calenda, Manager of Plant Infrastructure, Nabisco   

"Our evaluation convinced us that StarSQL Pro was the best product of its kind. StarQuest's service makes us glad we found them." Frank Habeebullah, DBA, TWA.  

"I am implementing DB2 database access with StarSQL Pro for the second time." Manny Aguillar, Network Consultant, Kaiser Permanente.  

"StarSQL Pro is the best value." Tony Godino, Montgomery Securities  

"StarSQL works for us." Gary Blouin,Vice President, MIS Automation Group Bank of America  

Sharing DB2 data resources with GUI-based client applications is a proven way for organizations to save money and provide better service. StarSQL EE is the best value available for sharing DB2 data with the Windows environment. StarSQL is endorsed by Microsoft, Cisco and IBM and as such, provides unparalleled performance, stability, usability and value. Dedication to, and focus on, providing data access services for DB2 makes StarQuest uniquely qualified to be a valuable partner for dependable database access middleware. By only charging for actual usage, conforming to standards and addressing the requirements for today's IT solutions, StarQuest has provided the flexibility necessary for making StarSQL EE a part of the enterprise standard desktop.  

"StarSQL was faster, more stable and lower in cost than any other solution we evaluated. StarQuest made it easy to do business with them." Henry Slack, CTO, Employer's Reinsurance Corp.  

 
APENDIX 1: SNA SERVER CONFIGURATION

This section includes a sample configuration between VTAM on MVS and a Microsoft SNA Server. The parameters from this configuration are referenced in the configuration of StarSQL Data sources described in another section.

VTAM MVS
Sample Configuration

1. PU/LU - A PU must be defined in VTAM by the VTAM systems programmer. Figure 1 is an example of a PU with an Independent LU.

*** StarSQL can use Independent and Dependent type of sessions to communicate to the database. For an example of a PU w/Dependent LUs, please refer to the StarSQL Pro online help file.

- Figure 1 -

STAR2 PU ADDR=02, IDBLK=05D, IDNUM=10092, DLOGMOD=LU62STAR, MODETAB=MODELU62, SSCPFM=USSSCS, PUTYPE=2, MAXDATA=521, MAXPATH=1, PASSLIM=4, DISCNT-NO, ANS=CONT, PACING=0

STARLU LU LOCADDR=0, PACING=0, VPACING=0 

2. Mode -The Mode Table entry contains information governing how conversations take place in VTAM; they define pacing, RU sizes and COS (class of service parameters). One of the most important entries in the LOGMODE table is the PSERVIC field which identifies the LU traffic protocols. The mode entry can be placed in any mode table under VTAM, the default or the same one used by DB2 in the APPL statement (see below) for DB2's LU definition.

LU62STAR MODEENT LOGMODE=LU62STAR, FMPROF=X'13', TSPROF=X'07', PRIPROT=X'B0', SECPROT=X'B0', COMPROT=X'50A1', RUSIZES=X'8989', TYPE=0, PSNDPAC=X'03', SRVCPAC=X'03', SSNDPAC=X'02', PSERVIC=X'060200000000000000002F00'3. APPL
DB2APPL VBUILD TYPE=APPL LUDB2T APPL AUTH=(ACQ), APPC=YES, AUTOSES=1, DMINWNL=10,  DMINWNR=10, DSESLIM=20, MODETAB=MODEDB2, SECACPT=ALREADYV, SRBEXIT=YES, VERIFY=NONE, VPACING=2 

onPool is locatedMicrosoft SNA Server Sample Configuration 
 
 
SNA Server Config Matching VTAM and DB2 Parameters 
MODE LU62STAR 
Mode Name LU62STAR 
Comment  
Session Limit 20  DSESLIM (APPL Definition)  
Min Con Winners 10 DMINWNR (APPL Definition) 
Min Con Losers 10 DMINWNL (APPL Definition) 
Autoactivation Lim 1 AUTOSES (APPL Definition) 
Enable Autopartner Yes 
High Priority Yes 
Pacing Send Count 7  SRVCPAC (MODE Definition) 
Pacing Recv Count 7 PSNDPAC (MODE Definition) 
Max Send RU 4096 RUSIZES (MODE Definition) 
Max Receive RU 4096 RUSIZES (MODE Definition 
SERVER STARSERV 
Server Name STARSERV 
Comment  
Control Point Name STAR2 PU/CPNAME or PU Name(PUDefinition) 
Network Name STARW VTAM NetID 
   
Link Services associated with this Server: 
SNADLC1 SnaDlc1 

Connections associated with this Server: 
DB2MVS 802.2 Connection 

APPC Local LUs associated with this Server: 
STARLU  

LINK SNADLC1 

Link Service Name SNADLC1 
Server Name STARSERV 
Comment SnaDlc1 
Link Service Type Token Ring 

Connections associated with this Link Service: 
DB2MVS 802.2 Connection 

CONNECTION DB2MVS 
Connection Name DB2MVS 
Server Name STARSERV 
Comment 802.2 Connection 
Remote End Host 
Activation type Initially Active 
Call Direction Both 
Local Block Number 05D IDBLK (PU Definition) 
Local Node Number 10092 IDNUM (PU Definition) 
Control Point Name PAPACDRM VTAM SSCPName 
Network Name STARW VTAM NetID 
Remote Block Number  
Remote Node Number  

Primary Link Service SNADLC1 

Connection Type 802.2 DLC 
DLC Type Token Ring 
XID Format Format3 
Remote Network Address 420000000400 HOST Network Address 
Remote SAP Address 4 /Use defaults for remaining 
Max BTU Length 1493 /link parameters or refer to  
Receive ACK Threshold 2 /SNA Server Help 
NAK Send Limit 8 
Retry Limit 10 
XID Retry Limit 3 
T1 Timeout Default 
T2 Timeout Default 
Ti Timeout Default 
Reactivation Delay Default 
Reactivation Retry Limit None 

3270 LUs assigned to this Connection: 

No LUA LUs assigned to this Connection. 

 No Downstream LUs assigned to this Connection. 

APPC LUs assigned to this Connection: 
LUDB2T  

APPCRLU LUDB2T  

LU Alias LUDB2T DB2 APPL 
Connection Name DB2MVS 
Network Name STARW 
LU Name LUDB2T 
Uninterpreted LU Name LUDB2T 
Comment  
Parallel sessions Yes 
Automatic partnering Yes 
Session level security None 
Implicit Mode <none> 

Partner LUs and modes: 
STARLU LU62STAR 

APPCLLU STARLU 

LU Alias STARLU Independent LU (VTAM) 
Server Name STARSERV 
Independent LU Yes 
Network Name STARW 
LU Name STARLU 
Comment  
Automatic partnering No 
Member of def. pool No 
Implicit remote LU <none> 
Timeout for TP start 60 

Partner LUs: 
LUDB2T LU62STAR DB2MVS  

APPENDIX 2: STARSQL DATA SOURCE DEFINITION  

This section shows how to configure DB2 on MVS to accept request from StarSQL over SNA Server. Parameters in the section are referenced in the section on defining a StarSQL data source. 

Distributed Data Facility 

The Distributed Data Facility (DDF) is a component of your IBM database. Its primary task is to route data from one database to another or from a client to another client (distributed unit of work). If distributed data has never been implemented it may not be configured. DDF must be active in order to make a successful connection to DB2 using StarSQL Pro. 

During startup processing to obtain system installation parameters, DB2 reads the BSDS (Bootstrap Data Set). One of the records stored in the BSDS is the DDF record. This records contains information used by DDF to connect to VTAM. If your organization has not implemented distributed database capabilities, DDF may not be configured.  

          a) If you are in the process of installing DB2, use the DDF installation panel DSNTIPR to provide:                    - The location name for the DB2 system                    - The LU name for the DB2 system                    - The password used when connecting DB2 to VTAM b) If DB2 is already installed, use the change log inventory utility (DSNJU003) to update the information in BSDS. Below is an example of how a BSDS is updated with a location name of STARDB, LU name of LUDB2T, and a password of STARPASS.

//SYSADMB JOB ,'DB2.3 JOB',CLASS=A 
//* 
//* CHANGE LOG INVENTORY: 
//* UPDATE BSDS WITH 
//* - DB2 LOCATION NAME FOR STARDB 
//* - VTAM LUNAME (LUDB2T) 
//* - DB2/VTAM PASSWORD 
//* 
//DSNBSDS EXEC PGM=DSNJU003 
//STEPLIB DD DISP=SHR,DSN=DSN230.DSNLOAD 
//SYSUT1 DD DISP=OLD,DSN=DSNC230.BSDS01 
//SYSUT2 DD DISP=OLD,DSN=DSNC230.BSDS02 
//SYSPRINT DD SYSOUT=* 
//SYSUDUMP DD SYSOUT=* 
//SYSIN DD * 

DDF LOCATION = STARDB, LUNAME=LUDB2T, PASSWORD = STARPASS 

Note if a password is not required to connect DB2 to VTAM, leave it blank. 

c)Starting DDF - To start the distributed data facility (DDF), if it has not already been started, use the following command: 
-START DDF 

Using the START DDF command requires authority of SYSOPR or higher. The command causes the following messages to appear: 

DSNL003I - DDF IS STARTING 
DSNL004I - DDF START COMPLETE LOCATION locname LU netname.luname 

If the distributed data facility has not been properly installed, the START DDF command fails and message DSN9032I, - REQUESTED FUNCTION IS NOT AVAILABLE, is issued. If the distributed data facility has already been started, the START DDF command fails and message DSNL001I, - DDF IS ALREADY STARTED, is issued. 

SYSLUNAMES 

You must have an entry in SYSIBM.SYSLUNAMES to allow the local LU access to DB2. 

a) You can insert a row which contains default values for any LU to use, which is not specifically described. The default row will contain blanks in the LUNAME column. An example: 

INSERT INTO SYSIBM.SYSLUNAMES (LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES) VALUES (' ',' ', 'C', 'N', 'N', ' '); 

b) You can authorize each requester individually by NOT having a default row. If there is no default row, DB2 requires that the LU be present. If the row isn't found the request is denied. 

INSERT INTO SYSIBM.SYSLUNAMES (LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES) VALUES ('REMOTELU', ' ', 'A', 'N', 'N', ' '); 

Values that correspond to the example configuration in this document are shown in parenthesis. 

ODBC Resources 
--------------------- 

Data Source Name: DB2MVS 
Comment: This is a connection to DB2 on MVS  

Data Source Value Matching SNA, DB2 and VTAM  
-------------------------------  

Database Server Name DDF Location Name (STARDB) 
SQL Catalog Qualifier SYSIBM or SYSIBM.AUTHID 
SQL Package Collection STARCOLL 

 

  
Network: 

Local LU LU Alias for APPCLLU in SNA Server  

(STARLU) 

Remote LU LU Alias for APPCRLU in SNA Server (LUDB2T) 

Mode SNA Server Mode for LU Partners (LU62STAR) 
 

 

 
  
Data Source Configuration 

DB2 Authorization Requirements 

An SQL package is an object that StarSQL uses to store internal control structures as a compiled form of SQL. You must have an SQL package on the host to use dynamic or static SQL on a DRDA connection. Note that beginning with StarSQL Pro v2.1, StarSQL assumes that required SQL packages already exist on the server. If StarSQL does not find the package it needs already residing on the server, it automatically binds the package "on the fly." A user connecting for the first time with StarSQL must have the following authorizations: 

BINDADD 

CREATE IN <COLLECTION> 

For the example in this document a DB2 Administrator would issue the following DB2 commands: 

GRANT BINDADD TO MYAUTHID 
GRANT CREATE IN COLLECTION STARCOLL TO MYAUTHID 

After the StarSQL Pro packages have been created, the DB2 Administrator can revoke the 'BINDADD' and 'CREATE IN' authorizations from the USER. 
  
StarSQL FAQ 

How are the packages created? 

Many off-the-shelf ODBC applications will execute the ODBC APIs necessary (SQLStatistics & SQLExecDirect) for StarSQL Pro to automatically bind the packages. The packages cannot be bound manually i.e. the StarSQL Pro driver binds the packages using DRDA commands. In general, the packages will be created during normal database processing by the application. StarSQL Pro will bind two packages initially - a Catalog package and a Dynamic package. StarSQL will bind a different Dynamic package depending on the Advanced Options used in the data source (see below). 

StarQuest has a bind utility call 'StarBind' which is included on the StarSQL Pro CDRom for versions 2.40 and later. This application will bind all packages on the database without having to change Advanced Options to bind a new package. 

** HELDCURSORS - StarQuest recommends using the HeldCursors Advanced Option for DB2/MVS users who may experience locking problems on the database. 

What are the names of the packages that are created? 

Static packages created correspond to Advanced Option settings for Isolation Level and Held Cursors option.  

Catalog package (SYSIBM) 
SWRC0000 - read committed/held cursors off (default) 
SWRR0000 - repeatable read/held cursors off 
SWRU0000 - read uncommitted/held cursors off 
SWTS0000 - serializable/held cursors off 
SWRC1000 - read committed/held cursors on 
SWRR1000 - repeatable read/held cursors on 
SWRU1000 - read uncommitted/held cursors on 
SWTS1000 - serializable/held cursors on 

What happens after package binding? 

After the packages are created, the DB2 Administrator must 'GRANT EXECUTE' to all users of StarSQL Pro. For this example the following command would be issued: 

GRANT EXECUTE ON STARCOLL.SYSIBM TO AUTHID 
GRANT EXECUTE ON STARCOLL.SWRC0000 TO AUTHID 
etc. 

Each user of StarSQL should specify 'STARCOLL' as the SQL Package Collection in the StarSQL Data source and all users will share the packages that were created in the initial connection. 

APPENDIX 3: IMPORTING DB2 DATA INTO EXCEL 

 

 
 

 
Pull down menu. 

 
Select database. 
 

 
Enter UserID/Password RACF, ACF2, UNIX, OS/400 etc. 
 

 
 
Secect authorized tables and views. 
 

 
Select columns. 
 

 
 
 

 

 

 

  

 
APPENDIX 4: SAMPLE HTML AND ACTIVE SERVER PAGE 
  
  
Sample HTML 

This is for the a sample htm file that has calls the ASP files 

<HTML> 
<HEAD> 
<TITLE>TEST Active Server Pages</TITLE> 
</HEAD> 
<BODY BGCOLOR=#FFFFFF> 
<TABLE> 
</TR> 
</TABLE> 
<HR> 
<P> 
<A HREF="SOURCE2.asp">Show me a list of our products (DB2MVS) </A> 
</BODY> 
</HTML> 

Sample ASP 

<%@ LANGUAGE=VBSCRIPT %> 

<HTML> 
<HEAD> 
<TITLE>ADO Enabled Application that display results from Nell via TCP/IP</TITLE> 
</HEAD> 
<BODY BGCOLOR=#ffffff> 

<% 
Set cnnODBC = Server.CreateObject("ADODB.Connection") 
cnnODBC.Open "DB2MVS", "USERID", "PASSWORD
Set rstODBC = cnnODBC.Execute("SELECT * from STARTRAK.PRODLIST") 
%> 

<P>The query is SELECT * from STARTRAK.PRODLIST</P> 
<P>Here are the results from the query.</P> 

<BR><I><B><%=sql%></I></B><P> 
<TABLE BORDER=1> 
<TR> 
<% For i = 0 to rstODBC.Fields.Count - 1 %> 
<TD><B> 
<%= rstODBC(i).Name %> 
</B></TD> 
<% Next %> 
</TR> 

<% 
v=rstODBC.GetRows 
rstODBC.close 
cnnODBC.close 
%> 
<P> 
<% For row = 0 to UBound(v,2) %> 
<TR> 
<% For col = 0 to UBound(v,1) %> 
<TD><%= v(col,row) %></TD> 
<% Next %> 
</TR> 
<% Next %> 
<BR> 

</BODY> 
</HTML>

 
APPENDIX 5: SAMPLE REPLICATION SUBSCRIPTION 
 
 
Start StarQuest Data Replicator and select source and destination tables. 
 

  
 
Specify source and destination table properties if required. 
  

 
    
  
Subscription Wizard- Choose a table.
 
 
  
Specify optional horizontal selection criteria- for selection of table rows. 
 

 
Select the destination database and request bulk copy or ODBC insertion- bulk copy is faster; ODBC logs database changes. 

 
  
  
Specify vertical selection criteria- for selection of table columns. 

Combine fields and change data types if required. 

  
  
Specify optional "before" and "after" processing-on the source and destination databases.
  

    
  
Schedule the subscription giving time of day and frequency for the transfer. 
  

   
Run the replication and review replication statistics in detail. 

 
APPENDIX 6: SAMPLE MTS CONFIGURATION  

Connection pooling is very useful when an ODBC application like Microsoft Internet Information Server (for example) connects and disconnects frequently. Microsoft Internet Information server (IIS) version 3.0 with Active Server Pages (ASP) takes advantage of connection pooling. You can enable connection pooling for IIS users by changing the value of StartConnectionPool to 1. The StartConnecti under: 

HKEY_LOCAL_MACHINE\System\  
CurrentControlSet\Services\W3SVC\ASP\Parameters. 

 
An ODBC application can use SQLSetEnvAttr to enable connection pooling. The following is an example of how to enable connection pooling in an ODBC application:  
#include <windows.h> 
#include <stdio.h> 
#include <sql.h> 
#include <sqlext.h> 

void main() 
{ 
SQLHENV henv; 
SQLHDBC hdbc; 
int i=0; 

if (!SQL_SUCCEEDED(SQLSetEnvAttr( 
NULL, // make process level cursor pooling 
SQL_ATTR_CONNECTION_POOLING, 
(SQLPOINTER)SQL_CP_ONE_PER_DRIVER, 
SQL_IS_INTEGER))) 
printf("SQLSetEnvAttr/SQL_ATTR_CONNECTION_POOLING error\n"); 

if (!SQL_SUCCEEDED(SQLAllocHandle(SQL_HANDLE_ENV, NULL, &henv))) 
printf("SQLAllocHandle error\n"); 

// set the ODBC behavior version. 
if (!SQL_SUCCEEDED(SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, 
(SQLPOINTER) SQL_OV_ODBC2, SQL_IS_INTEGER))) 
printf("SQLSetEnvAttr/SQL_ATTR_ODBC_VERSION error\n"); 

//set the matching condition for using an existing connection in the 
pool 
if (!SQL_SUCCEEDED(SQLSetEnvAttr(henv, SQL_ATTR_CP_MATCH, 
(SQLPOINTER) SQL_CP_RELAXED_MATCH, SQL_IS_INTEGER))) 
printf("SQLSetEnvAttr/SQL_ATTR_CP_MATCH error\n"); 

 while (i < 10) {  

if (!SQL_SUCCEEDED(SQLAllocHandle(SQL_HANDLE_DBC, 
henv, &hdbc))) 
printf("SQLAllocHandle error\n"); 
if (!SQL_SUCCEEDED(SQLConnect(hdbc, 
(unsigned char*)"testing\0", SQL_NTS, 
(unsigned char*)"sa\0", SQL_NTS, 
(unsigned char*)"\0", SQL_NTS))) 
printf("SQLConnect error\n"); 
else 
printf("Connect successfully %d times\n", i); 
//the first time, the application calls SQLDisconenct, it will return 
//the connection to the //pool 
SQLDisconnect(hdbc); 

Back to the top

Back to the White Papers Summary

To find out more about StarQuest products,
fill out this information request form or e-mail to sales@starquest.com.

Products | White Papers | Customer Support | Partners | About StarQuest | Press & Events

Copyright 2000 StarQuest Software, Inc. Please read our legal notice.
Contact webmaster@starquest.com with site comments.