A fix is available
APAR status
Closed as program error.
Error description
bypass location name release information if the location name is the local SSID
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All QMF for TSO/CICS users who install, * * migrate, or run DSQ1BPKG to bind QMF * * runtime packages. * **************************************************************** * PROBLEM DESCRIPTION: Users can experience a SQL code -805 * * SQLCODE805 when starting QMF even * * after having run the * * QMFvrm.SDSQSAPE(DSQ1BPKG) job to bind * * QMF runtime packages. This problem * * typically happens when * * the QMFvrm.SDSQSAPE(DSQ1BPKG) job * * is run soon after having migrated * * DB2 for z/OS modes. * **************************************************************** * RECOMMENDATION: * **************************************************************** After migrating DB2 for z/OS modes, as instructed by both the QMF and DB2 for z/OS documentation, users should run the QMFvrm.SDSQSAPE(DSQ1BPKG) job to bind QMF packages, in order to bind new database application packages that support the new mode of DB2. Sometimes, the QMFvrm.SDSQSAPE(DSQ1BPKG) job does not bind the correct set of packages for the release of database specified. This can cause SQL code -805 on various QMF packages and a failure of QMF to start.
Problem conclusion
The QMF bind runtime packages job, QMFvrm.SDSQSAPE(DSQ1BPKG), determines the correct list of packages to bind at a database based on information received from a CONNECT. CONNECT to a database returns information in the SQLERRP area of the SQLCA that identifies the the database type and release. Sometimes, that database type and release information is not updated immediately following a mode migration for DDF CONNECT (CONNECT TO server). If the information received from the CONNECT TO server is not correct, the list of packages to be bound that QMF builds will be incorrect. The delay of update of database type and release information typically happens in a local scenario, so QMF processing has been modified to handle the common case. The problem has not been seen in remote cases (where the location name specified is not the location name of the local subsystem specified). * For example, a user might specify this information in the DSQ1BPKG job: //BIND.SYSTSIN DD * %DSQ1BPKB DBSV DB_SILICONVALLEY * In the above scenario, DB_SILICONVALLEY is the location name of the local subsystem id, DBSV. This is the common case for which modifications in QMF code have been made. * DSQ1BPKG processing has been modified to detect if the location name specified is the location name of the SSID specified. If it is, QMF will bypass connecting to the location to determine the data base signature information. QMF will determine version and release from the database signature of the local subsystem.
Temporary fix
Comments
APAR Information
APAR number
PI09903
Reported component name
QMF-QUERY MGMT
Reported component ID
566872101
Reported release
B10
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2014-01-17
Closed date
2014-02-18
Last modified date
2014-03-03
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI15227 UI15228
Modules/Macros
DSQ1BPKB
Fix information
Fixed component name
QMF-QUERY MGMT
Fixed component ID
566872101
Applicable component levels
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SSCWRCK","label":"QMF for TSO\/CICS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"11.1","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]
Document Information
Modified date:
03 March 2014