CONNECTING TO DB2 MVS
StarWare StarSQL v1.04
September 19, 1995
Copyright 1995, StarWare Connectivity Software, Inc

The intention of this document is help you gather all the necessary 
information to install StarSQL in your corporation. At the very least 
you will need access to VTAM programmers and the data base 
administrators in your organization.

If you are using NetWare for SAA 1.3 for connectivity, see NETWARE.TXT 
for additional hints.

1.0 Host Software
Before the install you must verify that the Host software components are 
at the minimum level for DRDA connectivity. 

1.1 Databases Supported
StarSQL supports IBM's DB2 running on MVS and SQL/DS on VM/CMS and 
DOS/VSE.

1.2 Versions Required for DB2, SQL/DS and VTAM DB2
Version 2.3 and above

SQL/DS
SQL/DS - Version 3 Release 3
VM/SP - Version 3 Release 2
VM/ESA - Release 1
RSCS - Version 1 Release 2

VTAM
VTAM (MVS) - Version 3 Release 3
VTAM (VM) - Version 3 Release 2
VTAM (VM) - Version 3 Release required for conversational level security

2.0 Gateways Supported

2.1 NT SNA Server
Version must be 2.0 or higher, running on a Windows NT Server version 
3.5 or Windows NT Advanced Server version 3.1 

2.2 Novell SAA Comm Server
Novell's Netware for SAA must be version 1.3B or higher. 

3.0 PC Software
Windows 3.1 or later is required, as well as the installed client 
software that will allow you to connect to NT SNA Server or Novell SAA 
Comm Server.

4.0 VTAM
The first decision to be made is whether to use Independent or Dependent 
sessions. StarSQL can use either type of session to communicate to the 
database.

An Independent LU can:
* Send or receive a BIND (Initiate a session) 7 Support single, parallel 
and multiple sessions to different partner LU's.

A Dependent LU can:
* Receive a BIND but requires the Host to send the bind 7 Supports only 
a single session.

What LU type is chosen will be determined by the network design and 
installation

PU
A PU must be defined in VTAM by the VTAM programmers. An example of this 
is included with this document. Figure 1 below contains a PU with 
Dependent LU's. Note that the LU's in a dependent environment start at 
LOCADDR 2 and each Dependent LU has a DLOGMOD pointing to an entry in 
the Mode Table. In an independent PU (Figure 2) the LOCADDR starts at 0 
since it spawns as many sessions as are required by the local 
application. It has only one DLOGMOD entry since all sessions use the 
same LOCADDR.

PU with Dependent LU's (FIGURE 1)

STAR1           PU      ADDR=01,
                        IDBLK=05D,
                        IDNUM=10092
                        SSCPFM=USSSCS,
                        ISTATUS=ACTIVE
                        MAXDATA=521, MAXOUT=7, PASSLIM=15,
                        DLOGMOD=D4C32782, MODETAB=ISTINCLM,
                        IRETRY=NO, RETRIES=(,4,3),
                        PUTYPE=2,
                        VPACING=0
************************************************************************

LOCALLU1        LU      LOCADDR=2, USSTAB=USSTAB01, 
DLOGMOD=MLU62A,
					ID=LU1
                        MODETAB=MTSNA
LOCALLU2        LU      LOCADDR=3, USSTAB=USSTAB01, 
DLOGMOD=MLU62A,
					ID=LU2
                        MODETAB=MTSNA
LOCALLU3        LU      LOCADDR=4, USSTAB=USSTAB01, 
DLOGMOD=MLU62A,
					ID=LU3
                        MODETAB=MTSNA
LOCALLU4        LU      LOCADDR=5, USSTAB=USSTAB01, 
DLOGMOD=MLU62A,
					ID=LU4
                        MODETAB=MTSNA

PU with Independent LU's

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

INDLOCAL        LU      LOCADDR=0, PACING=0, VPACING=0

Mode
The Mode Table entry contains the information that governs 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 modetable under VTAM, the 
default or the same one used by DB2 in the APPL (see below) statement 
for DB2's LU definition. Since DB2 can either be primary or secondary 
when it initiates a session, when DB2 is secondary it needs to have a 
copy of the primary's mode entry in its Modetable. The parameters for 
specification can include a MODETAB= XXXXX to indicate the table that 
contains the modeentry and DLOGMOD. Figure 3 has an example of a mode 
entry with a dependent session. Figure 4 with an Independent session.

Figure 3 with Dependent LU

MLU62A	MODEENT	LOGMODE=MLU62A,
				FMPROF=X'13', TSPROF=X'07', PRIPROT=X'B0',
				SECPROT='B0', COMPROT=X'50A1',
				RUSIZES=X'8989',
				TYPE=0, PSNDPAC=X'03', SRCPAC=X'03',
				SSNDPAC=X'02',
				PSERVIC=X'0602000000000000002C00'


Figure 4 with Independent LU

LU62STAR	MODEENT	LOGMODE=LU62STAR,
				FMPROF=X'13', TSPROF=X'07', PRIPROT=X'B0',
				SECPROT='B0', COMPROT=X'50A1',
				RUSIZES=X'8989',
				TYPE=0, PSNDPAC=X'03', SRCPAC=X'03',
				SSNDPAC=X'02',
				PSERVIC=X'0602000000000000002F00'


For Independent Sessions, the PSERVIC will be '0602000000000000002F00'. 
For Dependent Sessions , the PSERVIC will be '0602000000000000002C00'. 
You must configure the LOGMODE byte 23 to reflect the type of session 
being used. You must also verify that SNASVCMG is in a Mode Table, if 
you want to use independent sessions.

APPL
After you define the VTAM LU name and password to DB2 you need to 
register these values with VTAM. This is done by way of an APPL 
statement. Figure 5 is an example of an APPL statement. 

Figure 5 APPL Definition

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

5.0 DDF
The Distributed Data Facility 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. Please refer to the 
DB2 Administrator for the state of the component. The key information 
that is required for StarSQL is the RDB name and the Luname. These can 
be found by running the VTAM change log inventory utility or through 
panels by using DSNTIPR. The line will look like this:

DDF LOCATION= locname, LUNAME=db2luname(PASSWORD=....) 

The locname is the RDB name and the db2luname is the LUNAME. 

Enter your values here:
RDB Name _________________	LUNAME __________________

6.0 CDB
The Communications Database contains information regarding network 
attribute of the remote systems (SYSIBM.SYSLUNAMES), LU 6.2 session 
limits for each partner (SYSIBM.SYSLUMODES), mode tables for individual 
users (SYSIBM.SYSMODESELECT), and end user management 
(SYSIBM.SYSUSERNAMES).

VTAM libraries must contain definitions for DB2:
	SYS1.VTAMLST defines DB2 as a VTAM application
	SYS1.VTAMLIB contains DDF mode tables.

7.0 Physical Connection Requirements
Token Ring
Remote Host Address - 12 digit network address(MACADDR in NCP) 
Local Node PU ID - ID Block and ID Num
Network Name - Netid parameter in the VTAM Start Command 
Control Point Name - This should match the SSCPNAME parameter in the 
VTAM Start Command
Remote Node ID - This is the PC's node ID (the one VTAM defines as being 
your local PC.
SAP - Usually 4
XID Type - 0 or 3
MaxBTU - For 4 meg Token it is 4195, for 16 it is 16393. 

Enter your values here:

Remote Host Address ________________________________ 
Block ID(IDBLOCK) ___________ 
NodeID(IDNUM)___________ 
SAP ____	
Network Name(NETID)___________________
Control Point Name ______________________ 

Please provide this information as well as a printout of the PU 
definition, Mode entry, and APPL. Also a collection needs to be created 
in DB2 to create our package. Create a collection called STARCOLL and 
give the initial user that is installing StarSQL for the first time 
BINDADD authority on the collection. Once the install has completed you 
can then take bind authority away from the collection. You may also use 
the collection NULLID if this would be easier instead of creating a new 
collection. Just allow the user to have BINDADD authority during 
install. You may also want to create a view of SYSIBM.SYSTABLES for the 
users in the STARCOLL collection or NULLID (if you have chosen to use 
this instead of creating a new collection). 

The last thing that needs to be done is to allow the local LU access to 
DB2. This is done by inserting a blank row into SYSIBM.SYSLUNAMES. As 
shown below:

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

This will allow you to provide default values for any LU not 
specifically described in the CDB(the default row contains blanks in the 
LUNAME column).

For more information please refer to DRDA Connectivity Guide (SC26-4783) 
from IBM.