CICS VSAM Transparency for z/OS, Version 1.2


Supported numeric formats

There are various combinations of signed and unsigned numeric fields that are valid in z/OS®. VSAM does not impose any rules governing the format of numeric fields, but rules are enforced by DB2®. Additionally, DB2 stores all DECIMAL, SMALLINT, INTEGER, and BIGINT column values as signed. This has potential implications for CICS® VT. This section defines the combination of VSAM field type and DB2 column data type directly supported by CICS VT.

Zoned decimal fields

A zoned decimal field can be signed or unsigned. The valid sign representations for zoned decimal are as follows:

Positive
C, A, E, and F.
Negative
D and B.

Here are examples of signed and unsigned field attributes in COBOL showing the typical representation of the numeric value +123:

  • PIC 9(3) is unsigned zoned decimal and the value is X'F1F2F3'
  • PIC S9(3) is signed zoned decimal and the value is X'F1F2C3'

When you map a zoned decimal field to any numeric column in CICS VT, you specify the field type C. For every mapped combination of field type C and a DB2 numeric column, CICS VT returns the data to your application programs as unsigned. This applies to all DB2 numeric columns supported by CICS VT, which is currently DECIMAL,SMALLINT, INTEGER, and BIGINT.

If your VSAM file has a signed zoned decimal field, your program logic may depend on signed zoned decimal values. For example, a COBOL test for NUMERIC for a signed zoned decimal field is NOT TRUE if the field value is unsigned. CICS VT has no way of knowing if your application code is dependent on signed zoned decimal values. Your options are to code a simple FBE to reset the field value to signed format, or change the DB2 column data type to CHARACTER. No data conversion is performed for a type C VSAM field that is mapped to a CHAR column.

Packed decimal fields

Packed decimal fields can be signed or unsigned. The valid sign representations are the same as for zoned decimal field. When you map a packed decimal field in in CICS VT, you specify a field type of P for signed packed decimal or U for unsigned packed decimal.
An all cases when a signed packed decimal field is mapped to a DB2 numeric column, the sign representation that CICS VT returns to your application is as follows:
  • Signed positive is B'1100' ('C')
  • Signed negative is B'1101' ('D')
An all cases when an unsigned packed decimal field is mapped to a DB2 numeric column, the sign representation that CICS VT returns to your application is as follows:
  • Unsigned using B'1111' ('F')

CICS VT uses the same sign representation rules for packed decimal fields that map to any supported DB2 numeric column type.

Although the same application logic dependency issues for zoned decimal fields apply to packed decimal fields, you are only likely to encounter an issue if the same field has signed values in some records and unsigned values in other records. If you decide to change the column type to CHAR in this situation, you must also update the CICS VT field type to C in manual mapping. Otherwise the DIM driver generation will fail.

Binary fields

Binary fields can be signed or unsigned. In COBOL, binary fields are defined as COMP, COMP-4, or COMP-5. CICS VT supports binary fields mapped to DB2 column types of SMALLINT, INTEGER, and BIGINT. DB2 data in column types of SMALLINT, INTEGER, and BIGINT is always signed.

CICS VT field types H, F, and B correspond to binary field lengths of 2 bytes, 4 bytes, and 8 bytes respectively. The range of data values in signed binary fields is consistent with the values in the DB2 binary data types SMALLINT, INTEGER, and BIGINT. A potential issue exists with unsigned binary fields. For example, the maximum value in a signed halfword binary field is +32767. This is the same for a DB2 SMALLINT column. The maximum value in an unsigned halfword binary field is 65535. In some cases, it may be necessary to map field type H to an INTEGER column, or a field type F to a BIGINT column.

The automated mapping facility highlights instances of unsigned binary copybook fields. You must know the range of values in unsigned binary fields in your VSAM files to ensure that you map them to appropriate column data types.

You can avoid potential issues with binary field data values by mapping them to CHAR columns. If so, you must update the CICS VT field type to C in each case.

Floating point

CICS VT does not support the mapping of floating point data in VSAM to the single or double precision floating point data types in DB2. Floating point fields must be mapped to CHAR columns of the same length, and must have the FOR BIT DATA attribute.

The auto-mapper recognises floating point fields defined in COBOL copybooks and generates appropriate mapping and DDL.

Partial keys for POINT, START, and STARTBR

VSAM field values that are not consistent with the mapped DB2 column type will come to light during the data migration process. However, you may also encounter runtime data issues with programs that use a partial key value or a generic key in a positioning call. For example, assume that you have VSAM file with a group field key as follows:

       01  SAMPLE-REC.                                  
           05  SAMPLE-KEY.                              
               10  SAMPLE-KEY-CHAR      PIC X(12).      
               10  SAMPLE-KEY-NUMB      PIC 9(4).       
           05  SAMPLE-DATA              PIC X(1000).    
                       

The field SAMPLE-KEY-CHAR is defined as type C and is mapped to a CHAR(12) column. The field SAMPLE-KEY-NUMB is defined as type C and is mapped to a DEC(4,0) column. If a COBOL program performs MOVE SPACES TO SAMPLE-KEY and then MOVE value TO SAMPLE-KEY-CHAR, an EXEC CICS STARTBR gets a data exception error because CICS VT cannot convert a value of spaces in SAMPLE-KEY-NUMB to a valid numeric. The solution in this situation is to code a simple FBE that tests for spaces in SAMPLE-KEY-NUMB for a START, STARTBR, or POINT call, and changes the value to 0.

Review the sample assembler exit PACKDEC, which is an example of a potential solution for a packed decimal field that is part of a key. Mapping SAMPLE-KEY-NUMB to a CHAR column is another solution.

The same issue potentially exists if your program specifies a key length that is less than the entire key.





Last updated: November 9, 2012 20:42:49