Under DB2/MVS version 3 we placed DSNACAB, DSNACAF, DSNALI & its alias
names in the MVS link list and used ISPF LIBDEF to allow the application
to work.
With DB2 Version 4 we're getting a new abend.
ABEND806-04 requested module DSN3ID00 not found.
Our production TSO environment is on a CPU with 3 & soon 4 DB2
subsystems.
We implement new system mantenance and migrate to new DB2 versions in a
staged manner. The DB2 systems aren't all changed at the same time.
All of the DB2 subsystems on this one cpu could be accessed by TSO
users.
The main CAF routines have some DB2 version to version compatibility.
A release mismatch RC 00C10823 is issued but the DB2 CAF connection is
allowed.
With due care an application can access multiple DB2 versions from the
same ISPF
environment.
With DB2/MVS version 4 we are placing DSN3ID00 in the ISPF ISPLLIB to
avoid
the S806 abend in the ISPF (CAF) application.
Since IBM level 2 says that the results of a release mismatch for
DSN3ID00 is
probably unpredictable. It appears that we will loose the ability to
safely access
mulitple DB2 subsystems from the same ISPF PROC.
Are there workarounds?
What is DSN3ID00? Can I avoid the call to it?
Would appreciate any responses that could help educate me or yield
other solutions.
thanks,
Dave Ward, Seattle, Wa.