data-name-1

Specifies a KEY data item on which the merge will be based. Each such data-name must identify a data item in a record associated with file-name-1. The data-names following the word KEY are listed from left to right in the MERGE statement in order of decreasing significance without regard to how they are divided into KEY phrases. The left-most data-name is the major key, the next data-name is the next most significant key, and so forth.

The following rules apply:

• A specific key data item must be physically located in the same position and have the same data format in each input file. However, it need not have the same data-name.

• If file-name-1 has more than one record description, then the KEY data items need be described in only one of the record descriptions.

• If file-name-1 contains variable-length records, all of the KEY data-items must be contained within the first n character positions of the record, where n equals the minimum records size specified for file-name-1.

• KEY data items must not contain an OCCURS clause or be subordinate to an item that contains an OCCURS clause.

• KEY data items can be qualified.

• KEY data items cannot be group items that contain variable occurrence data items.

• X KEY data items can be floating-point items.

• X KEY data items cannot be variably-located.

• X >_Workstation_> Under AIX, OS/2, and Windows, KEY data items
  X cannot be windowed date fields. <_Workstation_<
  
  X >_Host_> Under OS/390 and VM, KEY data items can be windowed date
  X fields, under these conditions:
  • X The input files specified in the USING phrase may be
    X sequential, relative, or indexed, but must not have any RECORD
    X KEY, ALTERNATE RECORD KEY, or RELATIVE KEY in the same
    X position as a windowed date merge key. The file system does
    X not support windowed date fields as keys, so any ordering
    X imposed by the file system could conflict with the windowed
    X date field support for the merge operation. In fact, if the
    X merge is to succeed, then input files must have already been
    X sorted into the same order as that specified by the MERGE
    X statement, including any windowed date ordering.

  • X The GIVING phrase must not specify an indexed file, because
    X the (binary) ordering assumed or imposed by the file system
    X conflicts with the windowed date ordering provided in the
    X output of the merge. Attempting to write the windowed date
    X merge output to such an indexed file will either fail or
    X re-impose binary ordering, depending on how the file is
    X accessed (the ACCESS MODE in the file-control entry).

  • X If an alphanumeric windowed date field is specified as a KEY
    X for a MERGE statement, the collating sequence in effect for
    X the merge operation must be EBCDIC. Thus the COLLATING
    X SEQUENCE phrase of the MERGE statement or, if this phrase is
    X not specified, then any PROGRAM COLLATING SEQUENCE clause in
    X the OBJECT-COMPUTER paragraph, must not specify a collating
    X sequence other than EBCDIC or NATIVE.

  
  X If the MERGE statement meets these conditions, then the merge
  X operation takes advantage of SORT Year 2000 features, assuming
  X that the execution environment includes a sort product that
  X supports century windowing.
  
  | A year-last windowed date field can be specified as a KEY for a
  | MERGE statement, and can thereby exploit the corresponding century
  | windowing capability of the sort product.
  
  X For more information on using windowed date fields as KEY data
  X items, see the IBM COBOL Programming Guide for your platform.
  X <_Host_<

The direction of the merge operation depends on the specification of the ASCENDING or DESCENDING key words as follows:

• When ASCENDING is specified, the sequence is from the lowest key value to the highest key value.

• When DESCENDING is specified, the sequence is from the highest key value to the lowest.

• If the KEY data item is alphabetic, alphanumeric, alphanumeric-edited, or numeric-edited, the sequence of key values depends on the collating sequence used (see "COLLATING SEQUENCE Phrase" in topic 6.2.23.2 below).

• X >_Host_> Under OS/390 and VM, if the KEY is a DBCS item, the
  X sequence of the KEY values are based on the binary collating
  X sequence of the hexadecimal values of the DBCS characters.
  X <_Host_<

• X >_Workstation_> Under AIX, OS/2, and Windows, if the KEY is a
  X DBCS item, then the sequence of the KEY values is based on a
  X collation sequence according to the COLLSEQ compiler option:
  • X If the COLLSEQ(NATIVE) compiler option is in effect, then the
    X collating sequence is determined by the locale. For
    X information on the locale, see Appendix F, "Locale
    X Considerations (Workstation Only)" in topic APPENDIX1.6.

  • X Otherwise, the collating sequence is determined by the binary
    X values of the DBCS characters. <_Workstation_<

• X If the KEY is an external floating-point item, the key is treated
  X as alphanumeric. The sequence in which the records are merged
  X depends on the collating sequence used.

• X If the KEY is an internal floating-point item, the sequence of key
  X values will be in numeric order.

The key comparisons are performed according to the rules for comparison of operands in a relation condition (see "Relation Condition" in topic 6.1.6.4).

IBM Library Server Copyright 1989, 2005 IBM Corporation. All rights reserved.

Adobe, the Adobe logo, Acrobat, the Acrobat logo, and Acrobat Reader are registered trademarks of Adobe Systems incorporated.