DSNTIPF: Application programming defaults panel 1
The entries on the DSNTIPF panel and the DSNTIP4 panel define application programming default values. These values are used as default values by the program preparation panels, the program preparation CLIST (DSNH), and the precompiler. These values can also be used as default values by other programs, such as QMF.
Migrating or updating the parameters: If you alter parameter values for which a
change during migration or update is not recommended,
this change can invalidate the syntax
of existing SQL statements or affect the way that application programs run. Update is allowed, but
must be handled with caution.
Most of the values that are set here and on the DSNTIP4 panel are contained in the application defaults load module, dsnhdecp. The load module is located in library prefix.SDSNEXIT, which can be loaded and accessed by application programs. When modifying the application defaults load module, do so only by changing and running the installation CLIST.
Many of the fields on this panel involve the selection of coded character set identifiers (CCSIDs). Here is some information that can help you choose values for these fields:
- If you choose YES for the MIXED DATA field, you must specify a mixed data CCSID from Table 2 or Table 3. An error occurs if you do not specify a CCSID or if the CCSID you specify is not listed in the table.
- If you specify an incorrect CCSID, data can become corrupted. For example, assume that the coded
character set used at your site is 37, but you specify 500 as the system CCSID. If Db2 receives data with a CCSID of 500, the data can
become corrupted because character conversion does not occur. Conversely, if Db2 receives data with a CCSID other than 500 and a
conversion is made from that CCSID to 500, the data can become corrupted because character
conversion occurs. Recommendation: Never change CCSIDs on an existing Db2 system without specific guidance from IBM Support.
- If you need to convert to a CCSID that supports the euro symbol, you can correct it by altering the CCSID field for your default encoding scheme.
- During code conversion, Db2 first looks in the SYSSTRINGS table to see if a conversion is defined. If Db2 finds a conversion, it is used. If Db2 does not find a conversion, it uses z/OS® Unicode Services. In some cases, z/OS Unicode Services is used instead of the value in SYSSTRINGS. If the conversion is not available, an error occurs.
- Converting statements to Unicode for parsing depends on having the correct input CCSID
specified. The system CCSIDs must be set up correctly at installation time.
During connect processing, a requester and server provide default CCSIDs for character data sent on the connection.
The Db2 requester uses the application encoding scheme for its default CCSIDs. If an application provides character data that is not in the CCSID that the application encoding scheme identifies, Db2 overrides the default CCSID by tagging each field with the actual CCSID prior to sending to the server. For applications that use the Unicode encoding scheme, the Db2 requester overrides the application encoding scheme CCSIDs with the system EBCDIC CCSIDs and converts the Unicode data to EBCDIC if Db2 determines that the server does not support Unicode character data. If the server cannot accept character data in these CCSIDs, connect fails with a -332 SQLCODE.
The Db2 server uses the system default encoding scheme to determine the default CCSID values for character data that is to be returned to the requester. For servers using the encoding scheme of Unicode, the Db2 server overrides the Unicode encoding scheme CCSIDs with the system EBCDIC CCSIDs and converts the Unicode data to EBCDIC if Db2 determines that the requester does not support Unicode character data. If the requester cannot accept character data in these CCSIDs, connect fails with a -332 SQLCODE.