Connecting to DB2

The DB2 for VM database program usually operates in its own virtual machine that is associated with a VM logon ID. The directories of each virtual machine can contain IUCV (inter-User Communications Vehicle) entries that allow the machines to communicate with DB2 for VM. You need to ensure the compatibility between the entries for QMF users and DB2 for VM users.

Any combination of the following cases can exist:

Case 1: The DB2 for VM directory contains IUCV ALLOW. Any other virtual machine can communicate with DB2 for VM.

Case 2: The QMF user's entry contains IUCV ANY. The QMF user can communicate with any other virtual machine, including the DB2 for VM computer.

Case 3: The QMF user's entry contains IUCV sqlsid, where sqlsid is the user ID of the DB2 for VM. The QMF user can contain this directory entry in any case, and must have it if neither case 1 nor case 2 entry applies.

Case 4: The DB2 for VM directory contains an IUCV *IDENT control statement to identify which resources it manages, and whether the resources are local or global. A local resource can be accessed only by QMF users on the same processor. A global resource can be accessed by QMF users on local or remote processors.

If your installation requires the use of QMF in different databases, you must install QMF into each unique DB2 database. Each database contains the following items:

• QMF control tables
• QMF DB2 for VM packages
• QMF sample tables and queries
• QMF views (stem tables)

Initializing the QMF session: The DB2 for VM user ID must be the same as the VM logon ID during the QMF session initialization. QMF connects implicitly during the session.

DB2 for VM considerations

QMF supports DATE, TIME, and TIMESTAMP data types so that users can use local date/time exit routines. For QMF to use a local date/time exit, the text files that contain the date/time exits, RIUXDT and ARIUXTM, must be placed on a disk that is accessible to QMF when QMF is started.

The QMF DCSS includes the ARIRVSTC text file. The QMF DCSS must be rebuilt using the DSQ2ESEG EXEC if this file is changed by PTFs applied to DB2 for VM or a new level of DB2 for VM.

GDDM considerations on CMS

When the QMF DCSS is built, it includes the GDDM interface code. If you run GDDM from a DCSS, you do not need to access a GDDM disk or GDDM TXTLIBs, and you can remove the lines in the invocation exec that refer to GDDM.

If you do not have a GDDM in a DCSS, you must access the GDDM TXTLIBs and perform the necessary FILEDEFs. If you want to change the release of GDDM that QMF uses, you must rebuild the QMF share segment using the DSQ2ESEG EXEC.

Setting up and starting QMF on CMS

The following examples show how to start and pass parameters to QMF operating independently of ISPF. The first two statements for CMS turn on L2 tracing (DSQSDBUG=NONE), pass a value of 50,000 for DSQSBSTG (maximum storage for reports), and pass a value of B (batch) for DSQSMODE (mode of operation).:

• Starting from CMS:

  DSQQMFE dcssname(DSQSBSTG=50000,DSQSDBUG=NONE,DSQSMODE=B

• Starting from an exec and specifying an initial procedure:

  DSQQMFE DSQSRUN=Q.IPROC(&&TABLE=Q.STAFF)

  This statement uses the DSQSRUN parameter:

  • To specify an initial procedure, Q.IPROC, to run when QMF starts
  • To pass a value, Q.STAFF, to the procedure for the variable &TABLE

  To run QMF independently of ISPF, use either of the following commands:

  DSQQMFE dcssname(DSQSBSTG=n1,...)
  DSQQMFE DSQSBSTG=n1,...

  The DSQSRUN parameter as specified in this example results in the following QMF command:

  RUN Q.IPROC(&TABLE=Q.STAFF