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.

Start of changeMost 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.End of change

Important: You should always use the CLIST to modify installation parameters. Start of changeDo not directly modify the data in the application defaults load module.End of change If you modify any installation parameters by changing job DSNTIJUZ directly, these values are not recorded for later updates, new installations, or migrations. In addition, these values are not checked for validity. If you do not use the CLIST to modify these parameters, DB2® may not start.

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® Software 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.

Figure 1. Application programming defaults panel: DSNTIPF
 DSNTIPF         INSTALL DB2 - APPLICATION PROGRAMMING DEFAULTS PANEL 1
 ===> _

 Enter data below:

  1  LANGUAGE DEFAULT     ===> IBMCOB   ASM,C,CPP,IBMCOB,FORTRAN,PLI
  2  DECIMAL POINT IS     ===> .        . or ,
  3  STRING DELIMITER     ===> DEFAULT  DEFAULT, " or ' (COBOL or COB2 only)
  4  SQL STRING DELIMITER ===> DEFAULT  DEFAULT, " or '
  5  DIST SQL STR DELIMTR ===> '        ' or "
  6  MIXED DATA           ===> NO       NO or YES for mixed DBCS data
  7  EBCDIC CCSID         ===>          CCSID of SBCS or mixed data. 1-65533.
  8  ASCII CCSID          ===>          CCSID of SBCS or mixed data. 1-65533.
  9  UNICODE CCSID        ===> 1208     CCSID of UNICODE UTF-8 data.
 10  DEF ENCODING SCHEME  ===> EBCDIC   EBCDIC, ASCII, or UNICODE
 11  APPLICATION ENCODING ===> EBCDIC   EBCDIC, ASCII, UNICODE, ccsid (1-65533)
 12  LOCALE LC_CTYPE      ===> 
 13  DECFLOAT ROUNDING MODE===> ROUND_HALF_EVEN

 PRESS:   ENTER to continue   RETURN to exit   HELP for more information