iSeries Information Center, Versión 5 Release 4

BARCODE (Bar Code) keyword in printer filesYou can use this field-level keyword to print a field as a user-specified bar code. The BARCODE keyword is valid only for Intelligent Printer Data Stream™ (IPDS™) printers and only for printer files with device type *IPDS or *AFPDS specified.

The format of the keyword is:

BARCODE(bar-code-ID [height] [[*HRZ | *VRT]

[*HRI | *HRITOP | *NOHRI] [*AST | *NOAST]

[modifier] [unit-width]

[wide/narrow-ratio]

[PDF417 data]

[Data Matrix data]

[Maxicode data]])

The bar-code-ID parameter is required. You can specify the bar-code-ID parameter as a special alphanumeric value up to 10 characters long, or as a numeric ID. Valid special values for the bar-code ID are listed in Table 1. If you specify a numeric value for the bar-code ID, then you also must specify the bar-code modifier parameter. See the documentation for your printer for the bar-code IDs and modifiers that it supports.

The height parameter is optional, but if you specify it, it must be the second parameter following the keyword. You can specify the height in one of two ways:

Specify the height in number of print lines. Valid values for the bar-code height are 1 through 9 lines.

Specify the height in inches or centimeters. When you specify the height in this way, the valid format is (height *UOM). Valid values are 0.25 to 25.40 cm (0.10 to 10.00 inches). For PDF417 bar-code type, valid values are 0.02 to 25.40 cm (0.01 to 10.00 inches). The UOM parameter on the Create Printer File (CRTPRTF) command determines the unit of measure for the height.

The value you specify for the bar-code height does not include the human readable interpretation below the bar code. If you do not specify the height parameter, the printer uses a default height.

You can specify the last 9 parameters (all optional) in any order. Using these parameters, you can specify that BARCODE:

Print the bar code horizontally or vertically. The default is horizontal printing (*HRZ).

Include or exclude the human readable interpretation of the bar code. The default is to include the human readable interpretation printed at the bottom of the bar code (*HRI).

Indicate that the human readable interpretation should be printed at the top (*HRITOP) of the bar code. (Check individual printer manuals for different bar code support of *HRITOP.)

Include or exclude asterisks around the human readable interpretation for CODE3OF9 barcodes. The default is to exclude the asterisks (*NOAST).

Select the bar-code modifier. This is a 1-character hexadecimal value that cannot be hexadecimal FF.

Specify the width (in inches) of the narrow bar/space. It is specified as an expression of the form (*WIDTH value). For more information about how to specify expressions, in the DDS Concepts information. The valid values for the parameter are 0.007 through 0.208.

Specify the ratio of the wide bar/space to the narrow bar/space. It is specified as an expression of the form: (*RATIO value). The valid values for the parameter are 2.00 through 3.00.

Specify additional barcode information for the two-dimensional barcodes PDF417, Maxicode, and Data Matrix. You can specify only one of these barcodes. See Specifying two-dimensional barcodes for more information.

Note: The overall barcode width is dependent on:

Ratio or width parameter in user DDS.

Actual customer data in the barcode.

Limitations of printer hardware, such as PEL density, pins and so on.

The width and ratio parameters are ignored for the 4234 and 4224 printer models.

For more information about the 4224 printer models, see the 4224 Printer Models 1xx and 2xx Product and Programming Descriptions, GC31-2551.

If you specify an optional parameter that does not apply to the bar-code ID you have specified, the printer ignores the optional parameter.

If you attempt to print a bar code on a printer that does not support bar codes, the digits in the code are treated as text, and a diagnostic message results in stating that the bar code might not print.

The line and position you specify for the field is used as the upper left corner of the bar code. Because the line specified in the DDS is the base line (the imaginary line on which characters are printed) and this is used as the upper edge of the bar code, the bar code appears to extend down from the bottom of the line you specify.

The following table describes valid data types, field lengths, and the numeric IDs for the BARCODE field.

Table 1. Valid bar-code definitions

Bar Code ID Data type Field length Numeric ID

MSI S 1 through 31 2

UPCA S 11 3

Table 1. Valid bar-code definitions

Bar Code ID Data type Field length Numeric ID

UPCE S 10 5

UPC2 S 2 6

UPC5 S 5 7

EAN8 S 7 8

EAN13 S 12 9

EAN2 S 2 22

EAN5 S 5 23

CODEABAR A 1 through 50 13

CODE128 A 1 through 50 17

CODE3OF9 A 1 through 50 1

INTERL2OF5 S 1 through 31 12

INDUST2OF5 S 1 through 31 10

MATRIX2OF5 S 1 through 31 11

POSTNET S 1 through 31 24

POSTNET (PLANET) 5 S 1 through 31 24

RM4SCC A 1 through 50 26

AP4SCC A 8 through 39 31

DUTCHKIX A 1 through 50 26

JPBC A 7 through 50 27

PDF417 A 1 through 1850 30

MAXICODE A 1 through 138 29

DATAMATRIX A 1 through 3116 28

The following table describes the supported bar codes.

Table 2. Bar codes supported by DDS

BARCODE Digits per code

Range of characters allowed

Default bar code modifier generated

Default bar code modifier printed

Valid bar code modifier

MSI (changed Plessey)

311 0 through 9 2 Modulus 10

No 01 through 09

UPC-A 11 0 through 9 1 No 00

UPC-E 10 0 through 9 1 No 00

UPC-2 digit add on (must follow a UPC A or E bar code)

2 0 through 9 No No 00

UPC-5 digit add on (must follow a UPC A or E bar

5 0 through 9 No No 00

Table 2. Bar codes supported by DDS

BARCODE Digits per code

Range of characters allowed

Default bar code modifier generated

Default bar code modifier printed

Valid bar code modifier

code)

EAN-8 7 0 through 9 1 Yes 00

EAN-13 12 0 through 9 1 Yes 00

EAN-2 digit add on (must follow an EAN 8 or 13 bar code)

2 0 through 9 No No 00

EAN-5 digit add on (must follow an EAN 8 or 13 bar code)

5 0 through 9 No No 00

INDUST2OF5 or industrial 2 of 5

31 0 through 9 1 Yes 01 02

MATRIX2OF5 or matrix 2 of 5

31 0 through 9 1 Yes 01 02

INTERL2OF5 or interleaved 2 of 5

31 0 through 9 1 Yes 01 02

CODEABAR Up to 50 characters 0 through 9,

A through D(begin/end only),-, ., $, /, +, and :

1 Yes 01 02

CODE128 Up to 50 characters

Refer toCODE128 character set in DDS

1 No 012 02

CODE3OF9 or code 3 of 9

Up to 50 characters 0 through 9,

A through Z(upper case only),-, ., $, /, +, %,and a blank

No No 01 02

POSTNET Up to 31 characters

0 through 9 1 Yes Ignored

POSTNET (PLANET)5

Up to 31 characters

0 through 9 1 Yes 04

RM4SCC Up to 50 characters 0 through 9

A through Z

1 Yes 00

Table 2. Bar codes supported by DDS

BARCODE Digits per code

Range of characters allowed

Default bar code modifier generated

Default bar code modifier printed

Valid bar code modifier

AP4SCC 13 through 39 0 through 9

A through Za through zspace, #

1 Yes 01 through 08

DUTCHKIX Up to 50 characters 0 through 9

A through Za through z

1 Yes 01

JPBC Up to 50 characters

0 through 9, A through Z, and -

1 Yes 00 013

PDF417 Up to 1850 characters 4

Any one-byte character

No No 00 01

MAXICODE Up to 138 characters 4

Any one-byte character

No No 00

DATAMATRIX Up to 3116 characters 4

Any one-byte character

No No 00

Notes:

1. The 4234 Printer only supports 14 digits.

2. The value 01 for the bar code modifier is not valid for some printers.

3. The value 01 provides migration support for application programs that use an AFP™ font to print Japan Postal Bar Codes. Data written into the field must be valid characters in the AFP font. The application program must also write the start, stop, and bar code modifier characters.

4. For PDF417, up to 1850 text characters, or 1108 bytes of binary data, per symbol, depending on the security level; refer to the symbology specification. For Maxicode, up to 93 alphanumeric characters per symbol, depending on the encoding overhead, or up to 138 numeric characters per symbol; refer to the symbology specification. For Data Matrix, up to 3116, depending on whether the data is character or numeric; refer to the symbology specification.

5. The PLANET bar code is selected by specifying the POSTNET bar-code-id and a bar code modifier of 04.

CODEABAR field data must begin with an A, B, C, or D and must end with an A, B, C, or D. For example, A11224455C or D33447799D.

Do not specify BARCODE in the same field with the CHRSIZ, CHRID, CVTDTA, DATE, EDTCDE, EDTWRD, FONT, HIGHLIGHT, PAGNBR, TIME, or UNDERLINE keywords.

See the CVTDTA keyword for information about coding IPDS bar code commands.

If you specify CHRSIZ at the record level, it applies to all fields in that record. If you specify BARCODE in one of those fields, the BARCODE keyword is not allowed.

You cannot specify BARCODE on the same record format with BLKFOLD, CPI, or DFNCHR.

When you specify BARCODE on a numeric field, the number of decimal positions must be zero.

When you specify BARCODE on a constant field, the only valid bar code IDs are CODEABAR, CODE128, and CODE3OF9, and you must also specify the DFT keyword either implicitly or explicitly.

You should specify DEVTYPE (*IPDS) or DEVTYPE(*AFPDS) on the CRTPRTF command when BARCODE is specified in the file.

BARCODE is allowed only on data types S and A (see Table 2 for restrictions).

Option indicators are not valid for this keyword.

Japan Postal Bar Codes (bar-code-ID = JPBC) uses only the bar-code-ID parameter, the bar code print orientation parameter ([*HRZ | *VRT]), and the bar code modifier parameter. All other parameters have predetermined values, so any input for them is ignored.

User-specified bar code modifiers are not checked for their validity, and might cause bar code errors if they are not valid. The Intelligent Printer Data Stream Reference manual contains more information about bar codes and valid bar code modifiers.

Specifying two-dimensional barcodes

You can specify additional parameters for the two-dimensional barcodes PDF417, Maxicode, and Data Matrix.

PDF417: The additional data is specified as an expression of the form:

(*PDF417 row-size number-rows security

[escape-indicator] [*MACRO(&data-field-name)])

row-size

This required parameter for PDF417 barcode specifies the number of data symbol characters per row. Valid values are in the range of 1 through 30.

number-rows

This required parameter for PDF417 barcode specifies the number of rows. Valid values are in the range of 3 through 90. You can specify a special value of *MIN (minimum) to instruct the printer to generate the minimum number of rows that are necessary.

security

This required parameter for PDF417 barcode specifies the security level. Valid values are in the range of 0 through 8. Each higher security level causes more error correction code words to be added to the symbol. At a particular security

level, a number of code words can be missing or erased, and the symbol can still be recovered.

escape-indicator

This optional parameter for PDF417 barcode specifies whether the backslash character within the barcode data is treated as an escape character according to the PDF417 symbology specification. Escape characters (started with backslash) allow reader programming to be specified within the barcode data. Valid values for the escape-indicator are:

*NOESCAPE indicates that each backslash character found in the barcode data is treated as a normal data character and therefore all escape sequences are ignored. Specify *NOESCAPE if the barcode data is an image or binary data. *NOESCAPE is the default value if no escape indicator is specified.

*ESCAPE indicates that each backslash character found in the barcode data is treated as an escape character according to the PDF417 symbology specification.

*MACRO(&data-field-name)

This optional parameter allows PDF417 Control Block coding to be specified (as defined in section G.2 of the Uniform Symbology Specification PDF417). The macro-data must be specified as a program-to-system field. The field must exist in the same record format as the BARCODE keyword. The length of the macro data is limited by the rules for a record format; that is, the maximum combined length of all named fields and indicators in a record format is 32 767 bytes. The data type must be A (character), and usage P (program-to-system).

Maxicode: The additional data is specified as an expression of the form:

(*MAXICODE symbol-mode [zipper-indicator] [sequence-data])

symbol-mode

This required parameter for Maxicode barcode specifies the symbol-mode for the MaxiCode barcode. Valid values are in the range of 2 through 6:

2 – Structured Carrier Message, numeric postal code

3 – Structured Carrier Message, alphanumeric postal code

4 – Standard code

5 – Full ECC symbol

6 – Reader program, SEC. No data is transmitted.

zipper-indicator

This optional parameter for Maxicode barcode specifies whether to print a zipper pattern and contrast block. The valid values for the zipper-indicator are:

*NOZIPPER indicates that a zipper pattern is not to be printed with the barcode. *NOZIPPER is the default value if no zipper-indicator is specified.

*ZIPPER indicates that a zipper pattern is to be printed with the barcode.

sequence-indicator

This optional parameter for Maxicode barcode specifies whether this barcode is part of a structured append. The Maxicode barcode can be logically linked together to encode large amounts of data. The logically linked symbols can be presented on the same or different media and are logically recombined after they are scanned. The sequence data for the Maxicode consists of two parts of the following form:

*SEQUENCE(sequence-indicator total-symbols)

sequence-indicator specifies the structured append sequence indicator. Valid values are 0 - 8.

total-symbols specifies the total number of structured append symbols. Valid values are 2 - 8.

Data Matrix: The additional data is specified as an expression of the form:

(*DATAMATRIX row-size number-rows [alternate-data-type] [reader]

[header-trailer] [sequence-indicator])

You can specify the following parameters for the Data Matrix barcode, in the following order:row-size

This required parameter for Data Matrix barcode specifies the row size. Data Matrix barcodes are square symbols or rectangle symbols. The square symbols are 10 by 10 to 144 by 144 and the rectangle symbols are 8 by 18 to 16 by 48. A special value of *DFT can be specified to have the printer select the row size based on the amount of symbol data.

number-rows

This required parameter for Data Matrix barcode specifies the number of rows. Data Matrix barcodes are square symbols or rectangle symbols. The square symbols are 10 by 10 to 144 by 144 and the rectangle symbols are 8 by 18 to 16 by 48. A special value of *DFT can be specified to have the printer select the number of rows based on the amount of symbol data.

alternate-data-type

This optional parameter for the Data Matrix barcode specifies the data type for the defined symbol. Valid values are:

*USRDEF indicates that this is a user defined symbol. *USRDEF is the default value if no alternate-data-type is specified.

*AIMSTD indicates that the symbol conforms to the specific industry standards as authorized by AIM international.

*UCCEAN indicates that the symbol conforms to the UCC/EAN application identifier standard format.

reader

This optional parameter for Data Matrix barcode specifies whether this barcode encodes a message used to program the reader system. Valid values are:

*DATA indicates that barcode data is supplied. *DATA is the default value if no reader indicator is specified.

*RDRPRG indicates that the symbol contains a message used to program the barcode reader.

header-trailer

This optional parameter for Data Matrix barcode specifies whether header and trailers instructions to the barcode reader are to be included. Valid values are:

*NO indicates that no header or trailers are to be inserted. *NO is the default value if no header-trailer value is specified.

*HEADER5 indicates that the barcode reader will insert a 05 Macro codeword.

*HEADER6 indicates that the barcode reader will insert a 06 Macro codeword.

sequence-indicator

This optional parameter for Data Matrix barcode specifies whether this barcode is part of a structured append. The Data Matrix barcode can be logically linked together to encode large amounts of data. The logically linked symbols can be presented on the same or different media and are logically recombined after they are scanned. The sequence data for the Data Matrix consists of three parts of the following form:

*SEQUENCE(sequence-indicator total-symbols file-id)

sequence-indicator specifies the structured append sequence indicator. Valid values are in the range of 1 through 16.

total-symbols specifies the total number of symbols that is logically linked in a sequence of symbols. Valid values are in the range of 2 through 16.

file-id specifies a 2-byte unique file identification for a set of structured-append symbols. When specifying the file-id, the format is X'nnnn', where nnnn is the two byte file ID in hexadecimal.

Note: When a structured append is specified, you must specify *NO for the header and trailer, and you must specify *DATA for the reader. For valid combinations of row-size and number-rows, see the symbology specification.EBCDIC-to-ASCII translation of two-dimensional barcodes

The two-dimensional barcodes PDF417, Maxicode, and Data Matrix are ASCII barcodes. The system extracts the CCSID of the job that generates the spooled file and translates EBCDIC data to code page 500. The printer then translates the data from code page 500 to the appropriate ASCII code page.

Maxicode and Data Matrix barcodes are assumed to start in ISO 8859-1 code page. The IBM®equivalent is ASCII code page 819. ASCII code page 437 is used for PDF417.Example

The following example shows how to specify the BARCODE keyword.

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

A FIELD1 11S O 2 4BARCODE(UPCA 6)

A FIELD2 3A 10 6BARCODE(CODE30F9 4 *NOHRI-

A *AST X'02')

A FIELD3 10S O 4 5BARCODE(UPCE 6 (*RATIO 2.75) *HRZ +

A X'00' (*WIDTH .02))

A FIELD4 10A O 5 5BARCODE(CODEABAR 1 (*RATIO 2.1) +

A *HRITOP)

A 6 5'01234567'

A BARCODE(CODE128 2 *HRITOP *HRZ +

A (*WIDTH 0.1) (*RATIO 2) X'01')

A FIELD5 10A 0 12 5BARCODE(CODEABAR (2.0 *UOM))

A FIELD6 10S 0 15 5BARCODE(10 X'01')Parent topic: Keyword entries for printer files (positions 45 through 80)Related tasksRules for DDS keywords and parameter values

Keyword entries for printer files (positions 45 through 80)These are valid keyword entries for defining printer files.

The keywords are entered in positions 45 through 80 (functions).

Keywords that require AFP(*YES) in printer device descriptions Beginning with OS/400® V3R1, the Advanced Function Printing™ (AFP™) subsystem was a separately orderable feature of the i5/OS® operating system, called Print Services Facility™ (PSF).

AFPRSC (AFP Resource) keyword in printer files You can use this record-level keyword to specify an Advanced Function Printing (AFP) resource or a non-AFP resource stored in the integrated file system.

ALIAS (Alternative Name) keyword in printer files You can use this field-level keyword to specify an alternative name for a field.

BARCODE (Bar Code) keyword in printer files You can use this field-level keyword to print a field as a user-specified bar code. The BARCODE keyword is valid only for Intelligent Printer Data Stream™ (IPDS™) printers and only for printer files with device type *IPDS or *AFPDS specified.

BLKFOLD (Blank Fold) keyword in printer files You can use this field-level keyword for named fields that overflow onto subsequent print lines. This keyword causes folding to occur at a blank rather than at the end of a line. If the BLKFOLD keyword is not specified, the line folds at the end of the physical print line.

BOX (Box) keyword in printer files You can use this record-level keyword to print a rectangle.

CDEFNT (Coded Font Name) keyword in printer files You use this field- or record-level keyword to specify the coded font for printing named or constant fields within a record.

CHRID (Character Identifier) keyword in printer files You can use this field-level keyword to specify that a graphic character set and code page other than the device default can be used for this field.

CHRSIZ (Character Size) keyword in printer files You can use this record- or field-level keyword to expand the width and height of a record or field. The CHRSIZ keyword is valid only for Intelligent Printer Data Stream (IPDS) printers and only for printer files with device type *IPDS or *AFPDS specified.

COLOR (Color) keyword in printer files You can use this field-level keyword to specify the color for a field.

CPI (Characters Per Inch) keyword in printer files This record- or field-level keyword specifies the horizontal printing density for the record format or field that you are defining.

CVTDTA (Convert Data) keyword in printer files This field-level keyword converts character data to hexadecimal data when the field is passed to the printer.

DATE (Date) keyword in printer files You can use this field-level keyword to display the current date or the current system date as a constant field that is 6 or 8 bytes long.

DATFMT (Date Format) keyword in printer files You use this field-level keyword to specify the format of a date field. This keyword is valid only for date fields (data type L).

DATSEP (Date Separator) keyword in printer files You use this field-level keyword to specify the separator character for a date field. This keyword is valid only for date fields (data type L).

DFNCHR (Define Character) keyword in printer files You use this file-level or record-level keyword to define characters of your own design for the 5224 Printer and 5225 Printer.

DFT (Default) keyword in printer files You use the DFT keyword to specify constant values for constant fields.

DLTEDT (Delete Edit) keyword in printer files This field-level keyword lets the i5/OS operating system ignore any EDTCDE or EDTWRD keyword that is specified for the referenced field. If a field description is referred to from a database file, DLTEDT prevents certain information from being referenced.

DOCIDXTAG (Document Index Tag ) keyword in printer files You can use this record-level keyword to create an indexing tag in the document for use by presentation systems such as Advanced Function Printing (AFP), or for use by postprocessor applications such as Content Manager OnDemand.

DRAWER (Drawer) keyword in printer files You use this record-level keyword to specify the drawer from which noncontinuous forms are selected.

DTASTMCMD (Data Stream Command) keyword in printer files You can use this record- or field-level keyword to store a data stream command or some other piece of information in a spooled file.

DUPLEX (Duplex) keyword in printer files You use this record-level keyword to specify whether output is printed on one side or two sides of the paper.

EDTCDE (Edit Code) keyword in printer files You use this keyword to edit output-capable numeric fields.

EDTWRD (Edit Word) keyword in printer files If you cannot accomplish the required editing by using the EDTCDE keyword, specify an edit word instead.

ENDPAGE (End Page) keyword in printer files You use this record-level keyword to eject the current page after the record is printed.

ENDPAGGRP (End Page Group) keyword in printer files You can use this record-level keyword to end a logical grouping of pages that were previously started with the STRPAGGRP keyword. If no group is active, this keyword is ignored.

FLTFIXDEC (Floating-Point to Fixed Decimal) keyword in printer files You use this field-level keyword to print a number in a floating-point field in fixed decimal notation.

FLTPCN (Floating-Point Precision) keyword in printer files You can use this keyword to specify the precision of a floating-point field.

FNTCHRSET (Font Character Set) keyword in printer files You use this file-level, record-level, or field-level keyword to specify the font for printing a named or constant field within a record.

FONT (Font) keyword in printer files You can use this record- or field-level keyword to specify the font ID for printing named or constant fields within a record.

FONTNAME (Font name) keyword in printer files You use this file-level, record-level, or field-level keyword to specify the TrueType font name for printing named or constant fields within a record.

FORCE (Force) keyword in printer files You can use this record-level keyword for duplex printing to force a new sheet of paper to be fed before the record is printed.

GDF (Graphic Data File) keyword in printer files You can use this record-level keyword to print a graphic data file.

HIGHLIGHT (Highlight) keyword in printer files You use this record- or field-level keyword to indicate that a field should be printed in bold letters.

INDARA (Indicator Area) keyword in printer files You can use this file-level keyword to remove option indicators from the buffer (also called the record area) and to place them in a 99-byte separate indicator area.

INDTXT (Indicator Text) keyword in printer files You use this file-, record-, or field-level keyword to associate a descriptive text (indicating intent or use) with a specific indicator. You can specify the INDTXT keyword once for each indicator.

INVDTAMAP (Invoke Data Map) keyword in printer files You use this record-level keyword to specify a data map that defines the layout of a formatted page.

INVMMAP (Invoke Medium Map) keyword in printer files You can use this record-level keyword to call a new medium map.

LINE (Line) keyword in printer files You can use this record-level keyword to print a horizontal or vertical line.

LPI (Lines Per Inch) keyword in printer files You can use this record-level keyword to change lines per inch within a file.

MSGCON (Message Constant) keyword in printer files You use this field-level keyword to indicate that the text for a constant field is contained in a message description.

OUTBIN (Output Bin) keyword in printer files You can use this record-level keyword to specify the destination of the output on printers capable of multiple output bins.

OVERLAY (Overlay) keyword in printer files You use this record-level keyword to print an overlay.

PAGNBR (Page Number) keyword in printer files You use this field-level keyword to specify the location of an unnamed, 4-digit, zoned decimal field to contain the page number.

PAGRTT (Page Rotation) keyword in printer files You use this record-level keyword to specify the degree of rotation of the text with respect to the way the page is loaded into the printer.

PAGSEG (Page Segment) keyword in printer files You use this record-level keyword to print a page segment.

POSITION (Position) keyword in printer files You use this field-level keyword to define the location of a named field on the page.

PRTQLTY (Print Quality) keyword in printer files You use this record- or field-level keyword to vary the print quality within the file.

REF (Reference) keyword in printer files You use this file-level keyword to specify the name of a file from which field descriptions are to be retrieved.

REFFLD (Referenced Field) keyword in printer files You use this field-level keyword when referring to a field under one of these conditions.

RELPOS (Relative Position) keyword in printer files You use this file-level keyword to indicate that when the +n form of positioning a field is used, the fields subsequent to the first field in the line are positioned relative to the end of the previous field.

SKIPA (Skip After) keyword in printer files You use this file-, record-, or field-level keyword to specify that the printer device is to skip to a specific line number after it prints one or more lines.

SKIPB (Skip Before) keyword in printer files You use this file-, record-, or field-level keyword to specify that the printer device is to skip to a specific line number before it prints the next lines.

SPACEA (Space After) keyword in printer files You use this record- or field-level keyword to specify that the printer device is to space some number of lines after it prints one or more lines.

SPACEB (Space Before) keyword in printer files You use this record- or field-level keyword to specify that the printer device is to space some number of lines before it prints the next line or lines.

STAPLE (Staple) keyword in printer files You use this record-level keyword to specify that a stapling operation should be performed within the spooled file.

STRPAGGRP (Start Page Group) keyword in printer files You use this record-level keyword to begin a logical grouping of pages.

TEXT (Text) keyword in printer files You use this record- or field-level keyword to supply a text description (or comment) for the record format or field that is used for program documentation.

TIME (Time) keyword in printer files This field-level keyword prints the current system time as a constant field 6 bytes long.

TIMFMT (Time Format) keyword in printer files You use this field-level keyword to specify the format of a time field. This keyword is valid for time fields (data type T).

TIMSEP (Time Separator) keyword in printer files You use this field-level keyword to specify separator characters for time fields. This keyword is valid only for time fields (data type T).

TRNSPY (Transparency) keyword in printer files This field-level keyword prevents code points that you have redefined (using the DFNCHR keyword) from being interpreted as SCS printer control commands when your program sends an output operation that prints the field that you are defining.

TXTRTT (Text Rotation) keyword in printer files You use this field-level keyword to rotate any text contained in the field.

UNDERLINE (Underline) keyword in printer files You use this field-level keyword to specify that the i5/OS operating system underline the field when it is printed.

UNISCRIPT (Unicode Text Layout) keyword in printer files You use this field-level keyword to control the selection of text marked for complex script processing.

ZFOLD (Z-fold) keyword in printer files You use this record-level keyword to specify that a z-fold operation is to be performed on the current sheet.

Parent topic: DDS for printer filesRelated conceptsRules for DDS keywords and parameter valuesRelated tasksDefining a printer file

Rules for DDS keywords and parameter valuesWhen you code data description specifications (DDS) entries, you must follow these conventions for entering keywords and their parameters.

The DDS coding syntax for keywords and their parameter values is similar to the CL syntax. The DDS syntax rules are:

Code all DDS entries in uppercase except for character values enclosed in single quotation marks and extended names enclosed in quotation marks.

Code keywords on the same (or subsequent) line as the entry with which they are associated.

Separate multiple keywords with at least one blank. Parameter values for keywords must be enclosed in parentheses. The initial parenthesis must immediately follow the keyword. For example:

KEYWORD(VALUE)

This rule is slightly different from that in control language. When coding control language, the parameter values can be positional. Syntax for DDS requires that the keyword be specified, except when specifying either a constant or the parameter value for the DFT (Default) keyword.

Separate multiple parameter values for the same keyword with at least one blank. For example:

KEYWORD(VALUEA VALUEB)

A parameter expression consists of a set of values surrounded by left and right parentheses. Generally, the first value within the expression is a special value. The special value begins with an asterisk and must immediately follow the left parenthesis. One or more parameter values follow the special value. Separate the special value and the parameter value(s) by at least one blank. The last parameter value must immediately precede the right parenthesis. A parameter expression represents one parameter value and must be separated from other parameter values by at least one blank. For example:

KEYWORD(VALUEA (*special-value VALUEB) VALUEC)

Use single quotation marks to enclose character values. Numeric values appear without single quotation marks. See the coding examples for COMP, RANGE, and VALUES keywords. Character values can appear in two places in the syntax:

As a parameter value for some keywords. For example, TEXT (all types of files) and COLHDG (database files) require character strings as text description. Other keywords, such as CAnn and CFnn, use character strings as text descriptions for response indicators.

As the default value of a constant field (either with or without the DFT keyword) for display and printer files only. In display files, a character constant can also be specified for named fields. Even if you do not specify the DFT keyword, specifying a character constant implies the DFT keyword.

To specify a single quotation mark within a character string, specify two single quotation marks so that one single quotation mark appears in the output. For example:

KEYWORD('Customer''s name')

appears as

Customer's name

Use a plus (+) or a minus (–) sign as a continuation character when a keyword and its parameter values do not fit on a single line. The sign must be the last nonblank character in the functions field. A single statement can be continued for a maximum of 5000 character positions.

A minus (–) sign means that the continuation begins in position 45 of the next line (the first position in the functions field).

A plus (+) sign means that the continuation begins with the first nonblank (first significant) character in the functions field on the next line.

If you specify a continuation character within a parameter value, any blanks preceding the continuation character are included in the parameter value.

Specify a plus (+) sign as the last nonblank character on a line to continue conditioning for keywords specified on the next line. This is helpful when a condition includes several option indicators and applies to several keywords.

The operating system continues a DDS statement until you specify one of the following fields:

A record format name (R in position 17).

A field specification (field name or location).

For physical or logical files, a key field specification (K in position 17).

For logical files, a select or omit specification (S or O in position 17).

For join logical files, a join specification (J in position 17).

For display files, a help specification (H in position 17).

For device files, an option indicator or condition name that conditions a keyword, field, or field location.

The maximum length of a DDS statement (5000 characters). The fixed length entries (positions 1 through 44) of the first line are included in the statement, so the maximum space available for keywords is 4956.

Parent topic: DDS coding rules, conventions, and terms

DDS coding rules, conventions, and termsWhen you describe data attributes with data description specifications (DDS), you need to be aware of specific coding rules, naming conventions, and terminology.

Conventions and terminology used in the DDS information The DDS information uses specific phrases and terms to describe key concepts.

Rules for DDS keywords and parameter values When you code data description specifications (DDS) entries, you must follow these conventions for entering keywords and their parameters.

DDS naming conventions Data description specifications (DDS) require that files, records, fields, and other labels and identifiers that are described in DDS keywords follow specific rules.

DDS keywords and parameters Data description specifications (DDS) keywords and parameters typically consist of combinations of standard abbreviations.

Parent topic: DDS concepts

DDS conceptsA traditional means of describing data attributes (such as the names and lengths of records and fields) is to specify the data attributes in the application programs themselves. However, data description specifications (DDS) describe data attributes in file descriptions that are external to the application program that processes the data.

DDS is a convenient alternative to describe data attributes on the IBM® System i™ platform.

The file types that use DDS are physical and logical files, display files, printer files, and intersystem communications function (ICF) files.

Note: By using the code examples, you agree to the terms of the Code license and disclaimer information.

Printable PDF Use this to view and print a PDF of this information.

Creating a file using DDS You can use data description specifications (DDS) to create a file.

DDS coding rules, conventions, and terms When you describe data attributes with data description specifications (DDS), you need to be aware of specific coding rules, naming conventions, and terminology.

General considerations for using DBCS text with DDS files Be aware of these general considerations for positional entries, keyword entries, double-byte character set (DBCS) text literals, and data description specifications (DDS) computer printouts that contain DBCS characters.

Examples: DDS coding These examples show how to use data description specifications (DDS).

When to specify REF and REFFLD keywords for DDS files When you decide whether to specify the REF (reference) keyword, the REFFLD (referenced field) keyword, or both, you need to consider some questions. You also need to know how to specify the parameter values for each REF or REFFLD keyword that you specify.

Related information for DDS concepts Listed here are the product manuals (in PDF format) and information center topics that relate to the DDS concept topic. You can view or print any of the PDFs.

Related informationDDS for physical and logical filesDDS for display filesDDS for printer filesDDS for ICF files

Examples: DDS codingThese examples show how to use data description specifications (DDS).

Examples: DDS syntax Here are some data description specifications (DDS) syntax examples. Except for HLPARA, JFILE, JFLD, and PFILE, the keywords shown in these examples are not actual keywords. They indicate where you can specify the keywords.

Examples: DDS for each file type You can use these examples with appropriate high-level language programs.

Example: Program that uses a physical file, display file, and printer file This example program shows the use of externally described data in a program.

Example: DDS compiler listing This is an example of a data description specifications (DDS) compiler computer printout.

DDS debugging template A special template is available to help you in interpreting the fields on the data description specifications (DDS) compiler computer printout.

Parent topic: DDS concepts

Examples: DDS syntaxHere are some data description specifications (DDS) syntax examples. Except for HLPARA, JFILE, JFLD, and PFILE, the keywords shown in these examples are not actual keywords. They indicate where you can specify the keywords.

DDS syntax for a physical file This is the syntax for a physical file.

DDS syntax for a simple logical file This is the syntax for a simple logical file.

DDS syntax for a join logical file This is the syntax for a join logical file.

DDS syntax for a display file This is the syntax for a display file.

DDS syntax for a printer file This is the syntax for a printer file.

DDS syntax for an intersystem communications function file This is the syntax for an intersystem communications function (ICF) file.

Parent topic: Examples: DDS coding

DDS syntax for a physical fileThis is the syntax for a physical file.

1

Comments (optional): Comments can appear on any line in DDS. They are identified by an asterisk in position 7.

2

File level (optional): File-level keywords appear before the record format name (RECORD on line 00040).

3

Record level (only one record is allowed in physical files): R in position 17 identifies RECORD as a record format name. The record level continues until the first field is named.

4

Field level (at least one field name is required, unless the FORMAT keyword is specified on the record): For fields in physical files, specify at least a name and length. Other attributes can be specified explicitly or by default.

5

Key field level (optional): K in position 17 identifies the field as a key field. A K must be specified for each key field. Specify the key field level by repeating a field name (here, FIELDA) after the field-level specifications.

Note: See Positional entries for physical and logical files for a description of each of the columns shown in the figure.Parent topic: Examples: DDS syntax

DDS syntax for a simple logical fileThis is the syntax for a simple logical file.

1

Comments (optional): Comments can appear on any line in DDS. They are identified by an asterisk in position 7.

2

File level (optional): File-level keywords appear before the record format name (RECORD1 on line 00040).

3

Record level (at least one is required): R in position 17 identifies RECORD1 as a record format name. In simple or multiple format logical files, the PFILE keyword is required for every record format. The record level continues until the first field is named.

4

Field level: Field names and field attributes are not required for logical files.

5

Key field level (optional): K in position 17 identifies the field as a key field. A K must be specified for each key field. Specify the key field level by repeating one or more field names (such as FIELDA) after the field-level specifications.

6

Select and omit levels (optional): S in position 17 identifies FIELDB as a select field. (O in position 17 identifies a field as an omit field.) The select and omit levels follow the key field level.

Notes:

1. To form a multiple-format logical file, specify more record formats within the file by repeating items 3 through 6, or specify more than one file on the PFILE keyword.

2. See Positional entries for physical and logical files for a description of each of the columns shown in the figure.

Parent topic: Examples: DDS syntax

Positional entries for physical and logical files (positions 1 through 44)The first 44 positions of the DDS form are called positional entries.

The following example shows some positional entries for physical files.

Figure 1. Physical file example

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00010A* PHYSICAL FILE CODING EXAMPLE

00020A REF(INVENCTL/INVENTORY)

00030A UNIQUE

00040A R ORDFMT TEXT('Format for Purchase Orders')

00050A ORDNBR 7 0 COLHDG('Order' 'Number')

00060A ITMNBR R 10

00070A SUPNBR R +2 REFFLD(SUPID SUPLIB/SUPMST)

00080A QTYORD 5B

00090A K ORDNBR

00100A K ITMNBR ABSVAL

A

Sequence number for physical and logical files (positions 1 through 5) You can use the first five positions to indicate the sequence number for each line on the form. The sequence number is optional and is used for documentation purposes only.

Form type for physical and logical files (position 6) You type an A in this position to designate this as a DDS form. The form type is optional and is for documentation purposes only.

Comment for physical and logical files (position 7) You type an asterisk (*) in this position to identify this line as a comment, and then use positions 8 through 80 for comment text.

Conditioning for physical and logical files (positions 8 through 16) These positions do not apply to physical or logical files. Leave these positions blank unless you use them for comment text.

Type of name or specification for physical and logical files (position 17) For physical files, type a value in this position to identify the type of name. For logical files, type a value to identify the type of specification. If you specify a name type, the name is specified in positions 19 through 28.

Reserved for physical and logical files (position 18) This position does not apply to any file type. Leave this position blank unless you use it for comment text.

Name for physical and logical files (positions 19 through 28) You use these positions to specify record or field names.

Reference for physical and logical files (position 29) You use this position to specify reference for physical files only.

Length for physical and logical files (positions 30 through 34) You use these positions to specify the length of a physical or logical file field.

Data type for physical and logical files (position 35) For a physical file, you use this position to specify the data type of the field within the database. You specify data type in a logical file only to override or change the data type of the corresponding field in the physical file on which this logical file is based.

Decimal positions for physical and logical files (positions 36 and 37) You use these positions to specify the decimal placement within a packed decimal, zoned decimal, binary, or floating-point field.

Usage for physical and logical files (position 38) You use this field to specify that a named field is to be an input-only, both (both input and output are allowed), or neither (neither input nor output is allowed) field.

Location for physical and logical files (positions 39 through 44) These positions do not apply to physical or logical files. Leave these positions blank unless you use them for comment text.

Parent topic: Defining physical and logical files using DDSRelated tasksSimple- and multiple-format logical files in DDSJoin logical files in DDS

DDS syntax for a join logical fileThis is the syntax for a join logical file.

1

Comments (optional): Comments can appear on any line in DDS. They are identified by an asterisk in position 7.

2

File level (optional): File-level keywords appear before the record format name (RECORD1 on line 00040).

3

Record level (exactly one required): R in position 17 identifies RECORD1 as a record format name. In join logical files, the JFILE keyword is required for the record format. The record level continues until the first join specification.

4

Join level: J in position 17 identifies the beginning of a join specification. At the join level, specify at least one join specification. Each join specification must include at least one JFLD keyword. There must be one JOIN keyword for each join specification in a join logical file if there is more than one join specification in the file. A join specification continues until the next join specification or field name.

5

Field level: At least one field name with usage other than N is required for join logical files.

6

Key field level (optional): K in position 17 identifies the field as a key field. A K must be specified for each key field. Specify the key field level by repeating one or more field names (such as FIELDA) after the field-level specifications.

7

Select and omit levels (optional): S in position 17 identifies FIELDB as a select field. (O in position 17 identifies a field as an omit field.) The select and omit levels follow the key field level.

Note: See Positional entries for physical and logical files for a description of each of the columns shown in the figure.Parent topic: Examples: DDS syntax

DDS syntax for a display fileThis is the syntax for a display file.

1

Comments (optional): Comments can appear on any line in DDS. They are identified by an asterisk in position 7.

2

File level (optional): File-level keywords appear before the first record format name (RECORDA on line 00040).

3

Record level (at least one required): R in position 17 identifies RECORDA as a record format name. The record level continues until either the first field is specified or the first help specification.

4

Help level (optional): H in position 17 identifies the beginning of a help specification. A help specification continues until the next H in position 17 or until the first field. Each help specification must include at least one HLPARA keyword, and a HLPRCD or HLPDOC keyword.

5

Field level (optional): Display file fields that are passed between the display device and the program must be named fields and must have a length specified. Other attributes can be specified explicitly or by default. Constant (unnamed) fields require only a location and a keyword, as described in DATE,

DFT, TIME, and MSGCON keyword descriptions in DDS keyword entries for display files (position 45 through 80). Positions 17 through 38 do not apply to constant fields.

Notes:

1. Items 3 through 5 can be repeated to specify new record formats within the display file.

2. See Positional entries for display files for a description of each of the columns shown in the figure.

Parent topic: Examples: DDS syntax

DDS keyword entries for display files (positions 45 through 80)You type the keyword entries that define display files in positions 45 through 80 (functions).

ALARM (Audible Alarm) keyword for display files You use this record-level keyword to specify that the i5/OS® operating system is to activate the audible alarm when this record is displayed. The alarm is of short duration.

ALIAS (Alternative Name) keyword for display files You use this field-level keyword to specify an alternative name for a field.

ALTHELP (Alternative Help Key) keyword for display files You use this file-level keyword to assign a command attention (CA) key as an alternative Help key.

ALTNAME (Alternative Record Name) keyword for display files You use this record-level keyword to specify an alternative name for a record.

ALTPAGEDWN/ALTPAGEUP (Alternative Page Down/Alternative Page Up) keyword for display filesYou use these file-level keywords to assign command function (CF) keys as alternative Page Down/Page Up keys.

ALWGPH (Allow Graphics) keyword for display files This file- or record-level keyword allows graphics and alphanumeric contents to be displayed by the record format on a 5292 Model 2 Color Display Station at the same time.

ALWROL (Allow Roll) keyword for display files This record-level keyword enables your program to page through data in a window on the display when the system is displaying the record format you are defining.

ASSUME (Assume) keyword for display files This record-level keyword specifies that the i5/OS operating system is to assume that the record is already shown on the display when the display file is opened.

AUTO (Auto) keyword for display files Under some circumstances, the AUTO keyword is equivalent to the CHECK keyword.

BLANKS (Blanks) keyword for display files This field-level keyword, when specified for a numeric, input-capable field, enables your program to distinguish when the field is blank and when the field is zero on the display. In either case, your program recognizes zeros.

BLINK (Blink) keyword for display files You use this record-level keyword to specify that as long as the record being defined is displayed, the cursor flashes.

BLKFOLD (Blank Fold) keyword for display files You use this field-level keyword for named, output-only fields (but not message or program-to-system fields) so that they overflow onto subsequent display lines.

CAnn (Command Attention) keyword for display files You use this file-level or record-level keyword to specify that the function key specified in the keyword (CA01 through CA24) is available for use.

CFnn (Command Function) keyword for display files You use this file-level or record-level keyword to specify that the function key specified in the keyword (CF01 through CF24) is available for use.

CHANGE (Change) keyword for display files You use this record-level or field-level keyword to set on the specified response indicator for an input operation.

CHCACCEL (Choice Accelerator Text) keyword for display files You use this field-level keyword on a single-choice selection field in a pull-down record to specify text for the accelerator key.

CHCAVAIL (Choice Color/Display Attribute when Available) keyword for display filesYou use this field-level keyword to specify the color or display attributes to be used when the system is displaying the available choices in a menu bar, push button, selection field, or subfile single-choice or multiple-choice selection list.

CHCCTL (Choice Control) keyword for display files You use this field-level keyword on a selection field to control the availability of the choices for the field.

CHCSLT (Choice Color/Display Attribute when Selected) keyword for display filesYou use this field-level keyword to specify the color or display attributes to be used when the system is displaying a selected choice in a menu bar or selection field.

CHCUNAVAIL (Choice Color/Display Attribute when Unavailable) keyword for display filesYou use this field-level keyword to specify the color or display attributes to be used when the system displays the unavailable choices in a selection field or a push button field.

CHECK (Check) keyword for display files You use this keyword to perform a number of functions, depending on the parameter values specified.

CHGINPDFT (Change Input Default) keyword for display files You use this file-level, record-level, or field-level keyword to change one or more input defaults for input-capable fields.

CHKMSGID (Check Message Identifier) keyword for display files You use this field-level keyword to identify an error message that is issued when a validity check error is detected.

CHOICE (Selection Field Choice) keyword for display files You use this field-level keyword to define a choice for a selection field.

CHRID (Character Identifier) keyword for display files You can use this field-level keyword to specify that a named field be translated if the CHRID parameter value for the display file differs from the CHRID parameter value for the workstation.

CLEAR (Clear) keyword for display files You use this file-level or record-level keyword to specify that your program is to receive control if the workstation user presses the Clear key, and optionally, that the i5/OSoperating system is to set on the specified response indicator.

CLRL (Clear Line) keyword for display files You use this record-level keyword to specify that the i5/OS operating system is to clear (delete) a specific number of lines before the record is displayed. Only those lines are cleared.

CMP (Comparison) keyword for display files This keyword is equivalent to the COMP keyword.

CNTFLD (Continued-Entry Field) keyword for display files You use this field-level keyword to define a field as a continued-entry field.

COLOR (Color) keyword for display files You use this keyword to specify the color of a field on a color display.

COMP (Comparison) keyword for display files You use this field-level keyword to specify that the i5/OS operating system is to compare the data that the workstation user types into an input or input/output field with the specified value.

CSRINPONLY (Cursor Movement to Input-Capable Positions Only) keyword for display filesYou use this file-level or record-level keyword to restrict cursor movement to input-capable positions only. This keyword only affects cursor movement caused by using the arrow keys.

CSRLOC (Cursor Location) keyword for display files You use this record-level keyword to specify the cursor location on an output operation to the record format that you are defining. Your program sends the output operation after setting the cursor location.

DATE (Date) keyword for display files You use this field-level keyword to display the current date as a constant (output-only) field.

DATFMT (Date Format) keyword for display files You use this field-level keyword to specify the format of a date field. This keyword is valid only for date fields (data type L).

DATSEP (Date Separator) keyword for display files You use this field-level keyword to specify the separator character for a date field. This keyword is valid only for date fields (data type L).

DFT (Default) keyword for display files You use this field-level keyword to specify the constant value for constant fields (unnamed fields) and to specify a default value for named fields.

DFTVAL (Default Value) keyword for display files You use this field-level keyword to specify a default value for an output-capable field.

DLTCHK (Delete Check) keyword for display files You use this field-level keyword to specify that the i5/OS operating system is to ignore all validity checking and CHKMSGID keywords that are specified for a referenced field.

DLTEDT (Delete Edit) keyword for display files You use this field-level keyword to specify that the i5/OS operating system is to ignore the EDTCDE or EDTWRD keyword if either of them is specified for a referenced field. This keyword is valid only when you specify R in position 29.

DSPATR (Display Attribute) keyword for display files You use this field-level keyword to specify one or more display attributes for the field that you are defining.

DSPMOD (Display Mode) keyword for display files You use this record-level keyword to specify which mode (display size) you want to use for the 3180, the 3477, or the 3197 Model D1, D2, W1, or W2 display station.

DSPRL (Display Right to Left) keyword for display files You use this file-level keyword to specify that the records in the display file are written right to left on the display.

DSPSIZ (Display Size) keyword for display files You use this file-level keyword to specify the display size to which your program can open the display file.

DUP (Duplication) keyword for display files You use this field-level keyword to activate the Dup key on the display station keyboard.

EDTCDE (Edit Code) keyword for display files You use this field-level keyword to edit output-capable numeric fields.

EDTMSK (Edit Mask) keyword for display files You use this field-level keyword to define an edit mask for fields with EDTCDE or EDTWRD keywords.

EDTWRD (Edit Word) keyword for display files You use this field-level keyword to specify an edit word if you cannot obtain the editing that you want through the EDTCDE keyword.

ENTFLDATR (Entry Field Attribute) keyword for display files You use this field-level, record-level, or file-level keyword to define that the leading attribute of the field changes to a specified attribute whenever the cursor is located in the field.

ERASE (Erase) keyword for display files You use this record-level keyword with the OVERLAY keyword to specify that the records whose names you supplied as parameter values are to be erased from the display when this record is written.

ERASEINP (Erase Input) keyword for display files You use this record-level keyword with the OVERLAY keyword to erase unprotected input-capable fields already on the display. Unprotected input-capable fields are fields for which the DSPATR(PR) keyword is not in effect.

ERRMSG (Error Message) and ERRMSGID (Error Message Identifier) keywords for display filesYou can use one of these field-level keywords to identify a message that is displayed on the message line and that is associated with that field.

ERRSFL (Error Subfile) keyword for display files You use this file-level keyword to specify that messages should be displayed using a system-supplied error subfile.

FLDCSRPRG (Cursor Progression Field) keyword for display files You use this field-level keyword to define the field to which the cursor moves when it exits a field.

FLTFIXDEC (Floating-Point to Fixed Decimal) keyword for display files You use this field-level keyword to display a number in an output-capable (usage B or O) floating-point field in fixed-decimal notation.

FLTPCN (Floating-Point Precision) Keyword for Display Files You use this field-level keyword to specify the precision of a floating-point field.

FRCDTA (Force Data) keyword for display files You use this record-level keyword to display a record format immediately, without waiting for the next input or input/output operation. When the buffer is partially full, the FRCDTA keyword can be used to clear the buffer.

GETRETAIN (Get Retain) keyword for display files You use this record-level keyword with the UNLOCK keyword to specify that the i5/OSoperating system is not to erase input-capable fields on input operations as described under the UNLOCK keyword.

HELP (Help) keyword for display files You use this file-level or record-level keyword to enable the Help key.

HLPARA (Help Area) keyword for display files You use this help-specification-level keyword to define a rectangular area on the display.

HLPBDY (Help Boundary) keyword for display files You use this help-specification-level keyword to limit the online help information that is available when online help information is displayed.

HLPCLR (Help Cleared) keyword for display files You use this record-level keyword to clear the list of active help specifications. When this record is displayed, only the online help information that is defined on the current record format or on the file level is accessible.

HLPCMDKEY (Help Command Key) keyword for display files You use this record-level keyword to return control to your application program after a command attention (CA) or command function (CF) key is pressed on an application help record format.

HLPDOC (Help Document) keyword for display files You use this file- or help-specification-level keyword to define the document as help information text for a specific location on the display.

HLPEXCLD (Help Excluded) keyword for display files You use this help-specification-level keyword to indicate that the online help information associated with this help specification is not displayed as extended help, but is available as item-specific help.

HLPFULL (Help Full) keyword for display files You use this file-level keyword to indicate that the help text for the help panel group of the application is displayed using the full screen rather than using windows.

HLPID (Help Identifier) keyword for display files You use this constant field-level keyword to specify an identifier for the constant in the field-level help. The identifier you specify can be used on the HLPARA keyword to link help text to this constant field.

HLPPNLGRP (Help Panel Group) keyword for display files You use this file-level or help-specification-level keyword to specify the source of the online help information, defined by the user interface manager (UIM), that is to be displayed when the Help key is pressed.

HLPRCD (Help Record) keyword for display files You use this file-level or help-specification-level keyword to specify the record format containing the online help information to be displayed when the Help key is pressed.

HLPRTN (Help Return) keyword for display files You use this file-level or record-level keyword to return control to your program when you press the Help key.

HLPSCHIDX (Help Search Index) keyword for display files You use this file-level keyword to enable the index search function (F11 on the Help display) and specify the search index object used for the index search.

HLPSEQ (Help Sequencing) keyword for display files You use this record-level keyword to define the sequencing of text records for Page key processing.

HLPTITLE (Help Title) keyword for display files You use this file-level or record-level keyword to define the default title of online help information in panel group. The help information is displayed using the full screen.

HOME (Home) keyword for display files You use this file-level or record-level keyword to specify that you want to recognize and handle the Home key through your program.

HTML (Hypertext Markup Language) keyword for display files You use this field-level keyword on an unnamed constant field to have Hypertext Markup Language (HTML) tags sent along with the 5250 data stream.

INDARA (Indicator Area) keyword for display files You use this file-level keyword to remove option and response indicators from the buffer (also called the record area) and to place them in a 99-byte separate indicator area.

INDTXT (Indicator Text) keyword for display files You use this file-level, record-level, or field-level keyword to associate a descriptive text (indicating intent or use) with a specific response or option indicator. You can specify the keyword once for each response and option indicator.

INVITE (Invite) keyword for display files You use this file-level or record-level keyword to invite the device for a later read operation.

INZINP (Initialize Input) keyword for display files You use this record-level keyword to initialize input/output fields without necessarily sending the initialized data to the display when the PUTOVR and ERASEINP(*ALL) keywords are both in effect.

INZRCD (Initialize Record) keyword for display files You use this record-level keyword to specify that if this record is not already on the display, it is to be written to the display before an input operation is sent from the program that specifies this record name.

KEEP (Keep) keyword for display files You use this record-level keyword to keep the display from being deleted when the display file is closed.

LOCK (Lock) keyword for display files You use this record-level keyword to specify that the keyboard is to remain locked after an output operation.

LOGINP (Log Input) keyword for display files You use this record-level keyword to specify that the input buffer for this record format is to be written to the job log each time the i5/OS operating system performs an input operation for the record.

LOGOUT (Log Output) keyword for display files You use this record-level keyword to specify that the output buffer for this record format is to be written to the job log each time the i5/OS operating system performs an output operation for the record.

LOWER (Lower) keyword for display files The LOWER keyword is equivalent to the CHECK(LC) keyword.

MAPVAL (Map Values) keyword for display files You use this field-level keyword to map field data to a different value during input and output operations.

MDTOFF (Modified Data Tag Off) keyword for display files You use this record-level keyword with the OVERLAY keyword to set off modified data tags (MDTs) for input-capable fields in record formats already on the display.

MLTCHCFLD (Multiple-Choice Selection Field) keyword for display files You use this field-level keyword to define a field as a multiple-choice selection field.

MNUBAR (Menu Bar) keyword for display files You use this record-level keyword to define a menu bar.

MNUBARCHC (Menu-Bar Choice) keyword for display files You use this field-level keyword to define a choice for a menu-bar field.

MNUBARDSP (Menu-Bar Display) keyword for display files You use this record-level keyword to display a menu bar.

MNUBARSEP (Menu-Bar Separator) keyword for display files You use this field-level keyword on a menu-bar field to specify the color, display attributes, or the character that is used to form the menu-bar separator line.

MNUBARSW (Menu-Bar Switch Key) keyword for display files You use this file- or record-level keyword to assign a command attention (CA) key to be the Switch-to-menu-bar key.

MNUCNL (Menu-Cancel Key) keyword for display files You use this file- or record-level keyword to assign a command attention (CA) key to be the cancel key for menu bars or pull-down menus.

MOUBTN (Mouse Buttons) keyword for display files You use this file-level or record-level keyword to associate a Command key or EVENT-ID parameter with one or two pointer-device events.

MSGALARM (Message Alarm) keyword for display files You use this file-level or record-level keyword to specify that the system is to sound the audible alarm when this record is displayed with an active ERRMSG,

ERRMSGID, SFLMSG, or SFLMSGID keyword, or when a validity checking error is detected. The alarm is of short duration.

MSGCON (Message Constant) keyword for display files You use this field-level keyword to indicate that the text for constant fields is contained in a message description.

MSGID (Message Identifier) keyword for display files You use this field-level keyword to allow an application program to identify, at program run time, the message description that contains text for a named field.

MSGLOC (Message Location) keyword for display files You use this file-level keyword to move the message line to the specified line number.

NOCCSID (No Coded Character Set Identifier) keyword for display files You use this field-level keyword to specify that CCSID conversion of the field is not done.

OPENPRT (Open Printer File) keyword for display files You use this file-level keyword to specify that after the printer file is opened (the first time the user presses the Print key), it is to remain open until the associated display file is closed.

OVERLAY (Overlay) keyword for display files You use this record-level keyword to specify that the record format that you are defining should appear on the display without the entire display being deleted first.

OVRATR (Override Attribute) keyword for display files You use this field-level or record-level keyword with the PUTOVR keyword to override the existing display attributes of a field or record that is already on the display.

OVRDTA (Override Data) keyword for display files You use this field-level or record-level keyword with the PUTOVR keyword to override the existing data contents of a field or record that is already on the display.

PAGEDOWN/PAGEUP (Page Down/Page Up) keywords for display files You use these file-level or record-level keywords to specify that your program handles any situation where the workstation user has pressed the Page Down or Page Up keys and thei5/OS operating system cannot page through the display.

PASSRCD (Passed Record) keyword for display files You use this file-level keyword to specify the record format to be used by the i5/OSoperating system when another program passes unformatted data to your program.

PRINT (Print) keyword for display files You use this file-level or record-level keyword to specify that the workstation user can press the Print key to print the current display.

PROTECT (Protect) keyword for display files You use this record-level keyword with the OVERLAY keyword to specify that when the record you are defining is displayed, all input-capable fields already on the display are to be changed to output-only fields.

PSHBTNCHC (Push Button Field Choice) keyword for display files You use this field-level keyword to define a choice for a push button field.

PSHBTNFLD (Push Button Field) keyword for display files You use this field-level keyword to define a field as a push button field.

PULLDOWN (Pull-Down Menu) keyword for display files You use this record-level keyword to define a record as a pull-down menu for a menu bar.

PUTOVR (Put with Explicit Override) keyword for display files You use this record-level keyword to enable the override of either display attributes or data contents (or both) of specific fields within a record that is displayed on a workstation device. By using the PUTOVR keyword, you can reduce the amount of data sent to the display device.

PUTRETAIN (Put-Retain) keyword for display files You use this record-level or field-level keyword with the OVERLAY keyword to prevent thei5/OS operating system from deleting data that is already on the display when the system displays the record again. The PUTOVR keyword has a function similar to, but more effective than, the PUTRETAIN keyword.

RANGE (Range) keyword for display files You use this field-level keyword for input-capable fields. The RANGE keyword directs thei5/OS operating system to perform validity checking on the data that the workstation user types into the field.

REF (Reference) keyword for display files You use this file-level keyword to specify the name of a file from which field descriptions are to be retrieved. You can also use this keyword when you want to duplicate descriptive information from several fields in a previously described record format.

REFFLD (Referenced Field) keyword for display files You use this field-level keyword to refer to a field when the name, record format, file, or library of the referenced field differs from its equivalent in positions 19 through 28.

RETKEY (Retain Function Keys) and RETCMDKEY (Retain Command Keys) keywords for display filesYou use these record-level keywords to indicate that function keys, command function (CFnn) keys, or command attention (CAnn) keys, which are enabled on a display, should be retained when the record you are defining is displayed.

RETLCKSTS (Retain Lock Status) keyword for display files You use this record-level keyword to specify that the system should not unlock the keyboard on the next input operation. This keyword prevents the loss of data when an input operation is started and data is already being transmitted from the keyboard.

RMVWDW (Remove Window) keyword for display files You use this record-level keyword to remove all existing windows on the display before this record is displayed.

ROLLUP/ROLLDOWN (Roll Up/Roll Down) keywords for display files You can use these file-level or record-level keywords to specify that your program handles any situation where the workstation user has pressed the Roll Up or Roll Down keys and the i5/OS operating system cannot move the text lines on the display.

RTNCSRLOC (Return Cursor Location) keyword for display files You use this record-level keyword to return the location of the cursor to an application program.

RTNDTA (Return Data) keyword for display files You use this record-level keyword to specify that when your program sends an input operation to this record format, the i5/OS operating system is to return the same data that was returned on the previous input operation sent to this record format.

SETOF (Set Off) keyword for display files You use this record-level keyword to specify that when an input operation sent to this record format is completed, the specified response indicator is to be set off.

SETOFF (Set Off) keyword for display files The SETOFF keyword is equivalent to the SETOF keyword.

SFL (Subfile) keyword for display files You use this record-level keyword to specify that this record format is to be a subfile record format.

SFLCHCCTL (Subfile Choice Control) keyword for display files You use this field-level keyword on a selection list to control the availability of choices for the list.

SFLCLR (Subfile Clear) keyword for display files You use this record-level keyword on the subfile-control record format so that your program can clear the subfile of all records. This keyword differs from the SFLDLT keyword in that the subfile is not deleted.

SFLCSRPRG (Subfile Cursor Progression) keyword for display files You use this field-level keyword to define that when the cursor leaves the field, it goes to the same field in the next subfile record instead of the next field in the same record.

SFLCSRRRN (Subfile Cursor Relative Record Number) keyword for display filesYou use this record-level keyword on the subfile-control record format to return the relative record number of the record on which the cursor is located within a subfile.

SFLCTL (Subfile Control) keyword for display files You use this record-level keyword to specify that this record format is to be a

subfile-control record format. This record format must immediately follow the subfile record format.

SFLDLT (Subfile Delete) keyword for display files You use this record-level keyword with an option indicator on the subfile-control record format to enable your program to delete the subfile.

SFLDROP (Subfile Drop) keyword for display files You use this record-level keyword on the subfile-control record format to assign a command attention (CA) key or a command function (CF) key that the workstation user can press to fold or truncate subfile records that require more than one display line.

SFLDSP (Subfile Display) keyword for display files You use this record-level keyword on the subfile-control record format so that the i5/OSoperating system displays the subfile when your program sends an output operation to the subfile-control record format.

SFLDSPCTL (Subfile Display Control) keyword for display files You use this record-level keyword on the subfile-control record format so that the i5/OSoperating system displays fields in the subfile-control record format when your program sends an output operation to the record format.

SFLEND (Subfile End) keyword for display files You use this record-level keyword on the subfile-control record format to enable the display of a plus sign (+) or text (More or Bottom) in the lower-right display location occupied by the subfile or a scroll bar.

SFLENTER (Subfile Enter) keyword for display files You use this record-level keyword on the subfile-control record format to specify that the Enter key is to be used as a Page Up key. This allows the i5/OS operating system to page through a subfile of more than one page when the Enter key is pressed.

SFLFOLD (Subfile Fold) keyword for display files You use this record-level keyword on the subfile-control record format to assign a command attention (CA) key or a command function (CF) key that the workstation user can press to truncate or fold subfile records that require more than one display line.

SFLINZ (Subfile Initialize) keyword for display files You use this record-level keyword on the subfile-control record format to specify that thei5/OS operating system is to initialize all records in the subfile on an output operation to the subfile-control record format identified by the SFLCTL (Subfile Control) keyword.

SFLLIN (Subfile Line) keyword for display files You use this record-level keyword on the subfile-control record format to specify that the subfile is to be displayed as a horizontal subfile. The subfile has more than one column of records displayed.

SFLMLTCHC (Subfile Multiple Choice Selection List) keyword for display filesYou use this record-level keyword to define a subfile as a multiple-choice selection

list. Amultiple-choice selection list is a scrollable group of items from which the user can select multiple items.

SFLMODE (Subfile Mode) keyword for display files You use this record-level keyword on the subfile-control record format to return an indication of whether the subfile was in folded or truncated mode on input. You use this keyword with the SFLCSRRRN (Subfile Cursor Relative Record Number) keyword to determine the location of the cursor within a subfile.

SFLMSG (Subfile Message) and SFLMSGID (Subfile Message Identifier) keywords for display filesYou use these record-level keywords on the subfile-control record format to identify a message to be displayed on the message line when your program performs an output operation to the subfile-control record format.

SFLMSGKEY (Subfile Message Key) keyword for display files You use this field-level keyword on the first field in the subfile record format for a message subfile (with Subfile (SFL) and Subfile Message Record (SFLMSGRCD) keywords specified).

SFLMSGRCD (Subfile Message Record) keyword for display files You use this record-level keyword on the subfile record format to specify that this subfile is to be a message subfile and that the records displayed when the subfile is displayed are messages from a program message queue.

SFLNXTCHG (Subfile Next Changed) keyword for display files You use this record-level keyword on the subfile record format to force the workstation user to correct program-detected typing errors in subfile records that have been read by the program.

SFLPAG (Subfile Page) keyword for display files You use this record-level keyword on the subfile-control record format to specify the number of records in the subfile to be displayed at the same time.

SFLPGMQ (Subfile Program Message Queue) keyword for display files You use this field-level keyword on the second (and last) field in the subfile record format for a message subfile.

SFLRCDNBR (Subfile Record Number) keyword for display files You use this field-level keyword on the subfile-control record format to specify that the page of the subfile to be displayed is the page that contains the record whose relative record number is in this field.

SFLRNA (Subfile Records Not Active) keyword for display files You use this record-level keyword with the Subfile Initialize (SFLINZ) keyword on the subfile-control record format so that your program can initialize a subfile with no active records. To do this, your program sends an output operation to the subfile-control record format with the SFLINZ keyword selected.

SFLROLVAL (Subfile Roll Value) keyword for display files You use this field-level keyword in the subfile-control record format to specify that the workstation user can type a value in this field. The value tells the i5/OS operating system how many records to page up or down when the appropriate paging key is pressed.

SFLRTNSEL (Subfile Return Selected Choices) keyword for display files You use this record-level keyword on a selection-list subfile control record to control how choices are returned to the application with the GET-NEXT-CHANGED operation.

SFLSCROLL (Subfile Scroll) keyword for display files You use this field-level keyword in the subfile-control record format to return the relative record number of the subfile record that is at the top of the subfile when control is given back to your program.

SFLSIZ (Subfile Size) keyword for display files You use this record-level keyword on the subfile-control record format to specify the number of records in the subfile.

SFLSNGCHC (Subfile Single Choice Selection List) keyword for display filesYou use this record-level keyword to define a subfile as a single-choice selection list. Asingle-choice selection list is a scrollable group of items from which the user can select only one item.

SLNO (Starting Line Number) keyword for display files You use this record-level keyword to specify a starting line number for the record format you are defining.

SNGCHCFLD (Single-Choice Selection Field) keyword for display files You use this field-level keyword to define a field as a single-choice selection field.

SYSNAME (System Name) keyword for display files You use this field-level keyword to display the current system name as a constant (output-only) field that is 8 characters long.

TEXT (Text) keyword for display files You use this record- or field-level keyword to supply a text description (or comment) for the record format or field that is used for program documentation.

TIME (Time) keyword for display files You use this field-level keyword to display the current system time as a constant (output-only) field.

TIMFMT (Time Format) keyword for display files You use this field-level keyword to specify the format of a time field. This keyword is valid for time fields (data type T).

TIMSEP (Time Separator) keyword for display files You use this field-level keyword to specify the separator character used for a time field. This keyword is valid only for time fields (data type T).

UNLOCK (Unlock) keyword for display files You use this record-level keyword to specify that the i5/OS operating system is to unlock the keyboard immediately after issuing an input operation to the record format you are defining.

USER (User) keyword for display files You use this field-level keyword to display the user profile name for the current job as a constant (output-only) field that is 10 characters long.

USRDFN (User-Defined) keyword for display files You use this record-level keyword to specify that the data for this record is in the form of a user-defined data stream.

USRDSPMGT (User Display Management) keyword for display files You use this file-level keyword to specify that all data written to the display is held until the data is overwritten or cleared by using the CLRL keyword.

USRRSTDSP (User Restore Display) keyword for display files You use this record-level keyword on a window record to specify that the application will manage the display.

VALNUM (Validate Numeric) keyword for display files You use this file-level, record-level, or field-level keyword to enhance the error checking that is performed against fields with the data type numeric-only.

VALUES (Values) keyword for display files You use this field-level keyword to specify a list of values that are valid for the user to type into the field.

VLDCMDKEY (Valid Command Key) keyword for display files You use this file-level or record-level keyword to specify that the i5/OS licensed program is to set on the specified response indicator when any valid command key other than the Enter key is pressed by the workstation user.

WDWBORDER (Window Border) keyword for display files You use this file-level or record-level keyword to specify the color, display attributes, and characters used to form the border of a window.

WDWTITLE (Window Title) keyword for display files You use this record-level keyword to specify the text, color, and display attributes for a title that is embedded within the top or bottom border of a window.

WINDOW (Window) keyword for display files You use this record-level keyword to specify that the record format you are defining will be displayed using a window.

WRDWRAP (Word Wrap) keyword for display files You use this file-level, record-level, or field-level keyword for continued-entry fields, or for named fields so that they overflow onto subsequent display lines.

Parent topic: DDS for display filesRelated conceptsPositional entries for display files (positions 1 through 44)Related tasksDefining a display file for DDSRelated referenceKeyword considerations for display files that use DBCSRelated informationRules for DDS keywords and parameter values

Positional entries for display files (positions 1 through 44)You specify positional entries in the first 44 positions of the data description specifications (DDS) form for display files.

Positional entries for display files (positions 1 through 7) You can specify the sequence number, the form type, and comments in positions 1 through 7.

Condition for display files (positions 7 through 16) Positions 7 through 16 are a multiple-field area in which you can specify option indicators.

Type of name or specification for display files (position 17) You can specify a value in this position to identify the type of name in positions 19 through 28.

Reserved for display files (position 18) This position does not apply to any file type. Leave this position blank unless you use it for comment text.

Name for display files (positions 19 through 28) You use these positions to specify record format names and field names.

Reference for display files (position 29) You can specify R in this position to use the reference function of the i5/OS® operating system. This function copies the attributes of a previously defined, named field (called thereferenced field) to the field you are defining.

Length for display files (positions 30 through 34) You must specify a length for each named field unless you are copying the length from a referenced field.

Data type and keyboard shift for display files (position 35) The entry you make in position 35 is the data type and keyboard shift attribute for display files.

Decimal positions for display files (positions 36 and 37) You use these positions to specify the decimal placement within a zoned decimal field and also to specify the data type of the field as it appears in your program.

Usage for display files (position 38) You use this position to specify that a named field is an output-only, input-only, input/output (both), hidden, program-to-system, or message field.

Location for display files (positions 39 through 44) You use these positions to specify the exact location on the display where each field begins.

Parent topic: Defining a display file for DDS

Related referenceDDS keyword entries for display files (positions 45 through 80)

DDS syntax for a printer fileThis is the syntax for a printer file.

1

Comments (optional): Comments can appear on any line in DDS. They are identified by an asterisk in position 7.

2

File level (optional): File-level keywords appear before the first record format name (RECORDA on line 00040).

3

Record level (at least one required): R in position 17 identifies RECORDA as a record format name. The record level continues until the first field is specified.

4

Field level (at least one field, whether named or unnamed, is required in each record format in the file): Printer file fields that are passed from the program to the printer must be named fields and must have a length specified. Other

attributes can be specified explicitly or by default. Constant (unnamed) fields require only a location and a keyword, as described in the DATE, DFT, PAGNBR, TIME, and MSGCON keyword descriptions in Keyword entries for printer files (positions 45 through 80).

Notes:

1. Items 3 and 4 can be repeated to specify new record formats within the printer file.

2. See Positional entries for printer files for a description of each of the columns shown in the figure.

Parent topic: Examples: DDS syntax

Positional entries for printer files (positions 1 through 44)You specify positional entries for printer files in the first 44 positions of the data description specifications (DDS) form.

To code the remaining part of the form, see Keyword entries for printer files (positions 45 through 80).

The printer file example in Defining a printer file shows some positional entries for printer files.

Sequence number for printer files (positions 1 through 5) You can specify a sequence number in these positions for each line on the DDS form.

Form type for printer files (position 6) You can enter an A in this position to designate this form as a DDS form.

Comment for printer files (position 7) You can enter an asterisk (*) in this position to identify this line as a comment, and then use positions 8 through 80 for comment text.

Condition for printer files (positions 7 through 16) You use these positions to specify option indicators (2-digit numbers from 01 to 99). Then you can have your program set option indicators on (hexadecimal F1) or off (hexadecimal F0) to select a field or keyword.

Type of name or specification for printer files (position 17) The value in this position identifies the type of name in positions 19 through 28.

Reserved for printer files (position 18) This position does not apply to any file type.

Name for printer files (positions 19 through 28) You specify record format names and field names in these positions.

Reference for printer files (position 29) You specify R in position 29 to copy the attributes of a previously defined, named

field (the referenced field) to the field that you are defining. If you do not specify R, you must specify the field attributes.

Length for printer files (positions 30 through 34) You must specify the field length in these positions for each named field (unless you copy the field length from a referenced field).

Data type for printer files (position 35) You can use this position to specify the data type associated with a field.

Decimal positions for printer files (positions 36 and 37) You use these positions to specify the decimal placement within a zoned decimal field and the data type of the field as it appears in your program.

Usage for printer files (position 38) You use this position to specify that a named field is an output-only or a program-to-system field. Do not make an entry in this position for a constant (unnamed) field.

Location for printer files (positions 39 through 44) These positions specify where the beginning of the field that you are defining appears on the page. You specify the line in positions 39 through 41, and the position in positions 42 through 44.

Parent topic: Defining a printer file

DDS syntax for an intersystem communications function fileThis is the syntax for an intersystem communications function (ICF) file.

1

Comments (optional): Comments can appear on any line in DDS. They are identified by an asterisk in position 7.

2

File level (optional): File-level keywords appear before the first record format name (RECORDA on line 00040).

3

Record level (at least one required): R in position 17 identifies RECORDA as a record format name. The record level continues until the first field is specified.

4

Field level (optional): ICF file fields must have at least a name (as in FIELDA) and a length. Other attributes can be specified explicitly or by default.

Notes:

1. Items 3 and 4 can be repeated to specify new record formats within the ICF file.

2. See Positional entries for ICF files for a description of each of the columns shown in the figure.

Parent topic: Examples: DDS syntax

Defining an ICF file using DDS

When you specify positional entries for ICF files, you should follow some specific rules for filling in positions 1 through 44 of the data description specifications (DDS) form.

DDS keyword entries for ICF files (positions 45 through 80) gives rules and examples for specifying DDS keywords.

For more information about keywords for ICF files, see the ICF Programming  book.

Specify the entries in the following order to define an ICF file:

1. File-level entries

2. Record-level entries

3. Field-level entries

Repeat the record-level entries and field-level entries for each record format in the file.

Specify at least one record format in the file.

The maximum number of record formats in an ICF file is 1024. The maximum number of fields in any one record format is 32 767.

Note: Specify the file name with the Create Intersystem Communications Function File (CRTICFF) command, not DDS.

The following figure shows an ICF file example.

Figure 1. ICF file example

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00010A* ICF FILE CODING EXAMPLE

00020A*

00030A R RCD1 RCVENDGRP(14)

00040A FLDA 5

00050A FLDB 5 0

00060A FLDC 10 2

00070A

00080A R RCD2

00090A 72 73

00110AON74 FAIL

00120A FLDD 12

A FLDC R REFFLD(A LIB1/FILEA)

A

Positional entries for ICF files (positions 1 through 44)

Here are some rules and examples for filling in positions 1 through 44 of the data description specifications (DDS) form.

To code the remaining part of the form, see DDS keyword entries for ICF files (positions 45 through 80).

Figure 1 shows some positional entries for ICF files.

Sequence number for ICF files (positions 1 through 5) You can use these positions to specify a sequence number for each line on the form.

Form type for ICF files (position 6) You specify an A in this position to identify this as a DDS form.

Comment for ICF files (position 7) You specify an asterisk (*) in this position to identify this line as a comment.

Condition for ICF files (positions 7 through 16) Positions 7 through 16 are a multiple-field area in which you can specify option indicators.

Type of name or specification for ICF files (position 17) You can enter a value in this position to identify the type of name specified in positions 19 through 28.

Reserved for ICF files (position 18) This position does not apply to any file type. Leave this position blank unless you use it for comment text.

Name for ICF files (positions 19 through 28) You can use these positions to specify record format names and field names.

Reference for ICF files (position 29) You specify an R in this position to use the reference function of the program. This function copies the attributes of a previously defined, named field (called the referenced field) to the field you are defining.

Length for ICF files (positions 30 through 34) You must specify the field length for each field (unless you copy the field's attributes from a referenced field).

Data type for ICF files (position 35) You can use this position to specify the data type of the field within the file.

Decimal positions for ICF files (positions 36 and 37) You can use these positions to specify the decimal placement within a packed decimal, a zoned decimal, a floating point, or a binary field.

Usage for ICF files (position 38) The valid entries for this position are listed here.

Location for ICF files (positions 39 through 44) These positions do not apply to ICF files. Leave these positions blank unless you use them for comment text.

Parent topic: DDS for ICF filesRelated conceptsRules for DDS keywords and parameter valuesExample: An ICF file using DDSDDS concepts

DDS keyword entries for ICF files (positions 45 through 80)The keyword entries are specified in positions 45 through 80. Be sure to follow the rules for DDS keywords and parameter values.

ALIAS (Alternative Name) keyword for ICF files You can use this field-level keyword to specify an alternative name for a field.

ALWWRT (Allow Write) keyword for ICF files You can use this file- or record-level keyword to allow your program to indicate when it has finished sending data.

CANCEL (Cancel) keyword for ICF files You can use this file- or record-level keyword to cancel the current chain of data (group of records) that is being sent to the remote program.

CNLINVITE (Cancel Invite) keyword for ICF files You can use this file- or record-level keyword to cancel any valid invite operation for which no input has yet been received.

CONFIRM (Confirm) keyword for ICF files You can use this file- or record-level keyword to request the remote program to confirm that it received the data.

CTLDTA (Control Data) keyword for ICF files You can use this file- or record-level keyword to inform the remote program that control data is being sent.

DETACH (Detach) keyword for ICF files You can use this file- or record-level keyword to explicitly inform the remote program that your program has completed sending data and wants to end the transaction.

DFREVOKE (Defer Evoke) keyword for ICF files You can use this file- or record-level keyword with the EVOKE keyword to delay an evoke request until either the send buffer is full of data or a FRCDTA keyword is received.

ENDGRP (End of Group) keyword for ICF files You can use this file- or record-level keyword to allow your program to indicate the end of a user-defined group of records.

EOS (End of Session) keyword for ICF files You can use this file- or record-level keyword to specify an end of session function. To end a session, your program issues a write operation with the EOS keyword in effect.

EVOKE (Evoke) keyword for ICF files You can use this file- or record-level keyword to start a program on the remote system.

FAIL (Fail) keyword for ICF files You can use this file- or record-level keyword to inform the remote program that the data sent or received is not valid.

FLTPCN (Floating-Point Precision) keyword for ICF files You can use this field-level keyword to specify the precision of a floating-point field.

FMH (Function Management Header) keyword for ICF files You can use this file- or record-level keyword to inform the remote program that a function management header (FMH) is being sent.

FMTNAME (Format Name) keyword for ICF files You can use this file- or record-level keyword to specify that the record format name is to be sent to the remote program when your program issues an output operation.

FRCDTA (Force Data) keyword for ICF files You can use this record-level keyword to clear the buffer when there is no more data to send, without waiting for the buffer to become full.

INDARA (Indicator Area) keyword for ICF files You can use this file-level keyword to remove option and response indicators from the buffer or record area, and to place them in a 99-byte separate indicator area.

INDTXT (Indicator Text) keyword for ICF files You can use this file- or record-level keyword to associate descriptive text (indicating intent or use) with a specific response or option indicator.

INVITE (Invite) keyword for ICF files You can use this file- or record-level keyword to invite the program device for a later read operation.

NEGRSP (Negative Response) keyword for ICF files You can use this file- or record-level keyword to send a negative response to the remote program. The response indicates that your program detected an error in the data received.

PRPCMT (Prepare for Commit) keyword for ICF files You can use this record-level keyword to request the remote program to prepare for a synchronization point.

RCVCANCEL (Receive Cancel) keyword for ICF files You can use this file- or record-level keyword to set on a response indicator to inform your program that the remote program has sent a cancel request.

RCVCONFIRM (Receive Confirm) keyword for ICF files You can use this file- or record-level keyword to set on a response indicator if the data received by your program contains a confirmation request from the remote program.

RCVCTLDTA (Receive Control Data) keyword for ICF files You can use this file- or record-level keyword to set on a response indicator to inform your program that control data has been received.

RCVDETACH (Receive Detach) keyword for ICF files You can use this file- or record-level keyword to set on a response indicator if the remote program is ending the transaction.

RCVENDGRP (Receive End of Group) keyword for ICF files You can use this file- or record-level keyword to set on a response indicator to inform your program of the end of a user-defined group of records.

RCVFAIL (Receive Fail) keyword for ICF files You can use this file- or record-level keyword to set on a response indicator when the local program determines that the remote program has sent a failure indication.

RCVFMH (Receive Function Management Header) keyword for ICF files You can use this file- or record-level keyword to set on a response indicator to inform your program that a function management header has been received.

RCVNEGRSP (Receive Negative Response) keyword for ICF files You can use this file- or record-level keyword to set on a response indicator to inform your program that the remote program has sent a negative response.

RCVROLLB (Receive Rollback Response Indicator) keyword for ICF files You can use this file- or record-level keyword to indicate whether a rollback operation has been received.

RCVTKCMT (Receive Take Commit Response Indicator) keyword for ICF filesYou can use this file- or record-level keyword to indicate whether a take_commit request has been received.

RCVTRNRND (Receive Turnaround) keyword for ICF files You can use this file- or record-level keyword to set on a response indicator. This response indicator informs your program that the sending program has stopped sending and has given the local program the right to send.

RECID (Record Identification) keyword for ICF files You can use this record-level keyword to allow your program to identify a record-by-record format when it issues a read-from-invited-devices operation using the name of the file.

REF (Reference) keyword for ICF files You can use this file-level keyword to specify the name of a file from which field descriptions are to be retrieved.

REFFLD (Referenced Field) keyword for ICF files You can use this field-level keyword when referring to a field under one of these conditions.

RQSWRT (Request Write) keyword for ICF files You can use this file- or record-level keyword to request permission for your program to send data.

RSPCONFIRM (Respond Confirm) keyword for ICF files You can use this file- or record-level keyword to send a positive response to a received confirmation request.

SECURITY (Security) keyword for ICF files You can use this file- and record-level keyword to include security information when your program starts a program on a remote system.

SUBDEV (Subdevice) keyword for ICF files You can use this file- or record-level keyword to allow your program to request a specific subdevice (for example, a printer) to which transmitted data should be directed.

SYNLVL (Synchronization Level) keyword for ICF files You can use this file- and record-level keyword to specify the level of synchronization your program requires.

TEXT (Text) keyword for ICF files You can use this record- or field-level keyword to supply a text description (or comment) for the record format or field used for program documentation.

TIMER (Timer) keyword for ICF files You can use this record-level keyword to specify an interval of time for your program to wait before your program performs some specified function.

TNSSYNLVL (Transaction Synchronization Level) keyword for ICF files You can use this file- or record-level keyword to specify the transaction synchronization level that is performed while the system is issuing a write operation when a DETACH or ALWWRT keyword is specified. The transaction synchronization level is specified on the SYNLVL keyword.

VARBUFMGT (Variable Buffer Management) keyword for ICF files You can use this record-level keyword to send or receive multiple or partial records using one record format per output operation.

VARLEN (Variable-Length User Data) keyword for ICF files You can use this record-level keyword to indicate that the length of the record sent across the line is variable. The length is specified at run time in the field parameter.

Parent topic: DDS for ICF filesRelated informationRules for DDS keywords and parameter values

Example: An intersystem communications function file using DDSThis example contains data description specifications (DDS) for transmitting data between theSystem i™ platform and a remote system or device.

The following keywords are important in the example:

CONFIRMDETACHEVOKERCVDETACHRCVFAILRCVCONFIRMRCVTRNRND

RECIDSYNLVLEOSRSPCONFIRMALWWRTFAILRQSWRT

Figure 1. ICF file

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00010A*

00020A* SAMPLE ICF FILE

00030A*

00040A 01 (3) EOS

00050A (2) RCVTRNRND(01 'TRNRND INDICATION')

00060A (2) RCVDETACH(02 'DETACH RECEIVED')

00070A (2) RCVCONFIRM(03 'CONFIRM REQUEST')

00080A (2) RCVFAIL(04 'FAIL RECEIVED')

00090A

00100A R CATCHALL

00110A FLD1 132A

00120A*

00130A R SNDEVOKE EVOKE(&LIBNME/&PGMNME);

00140A (1) SYNLVL(*CONFIRM) SECURITY(2 PASSWRD)

00150A (1) CONFIRM

00160A PGMNME 10A P

00170A LIBNME 10A P

00180A PASSWRD 8A P

00190A*

00200A R HEADER RECID(1 'H')

A

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00210A 09 CONFIRM

00220A ID 1A

00230A (4) PART# 12A

00240A UNTCST 6S 2

00250A QTYONORDR 9B 0

00260A TOTAL 9B 0

00270A*

00280A R DETAIL RECID(1 'D') RECID(1 'E')

00290A 09 CONFIRM

00300A ID 1A

00310A (4) LOC 6A

00320A QTY 9B 0

00330A*

00340A R COMMANDS

00350A 05 (5) FALL

00360A 06 (5) ALWWRT

00370A 07 (5) DETACH

00380A 08 (5) RQSWRT

00390A 09 (5) CONFIRM

00400A 10 (5) RSPCONFIRM

A

Legend:

(1)

The record format SNDEVOKE causes the program specified in the field PGMNME and the library specified in the field LIBNME to be started on the remote system. It also establishes a synchronization level of *CONFIRM for the transaction and

passes the data in the field PASSWRD as security information. The CONFIRM keyword requests that the remote system confirm the start of the program.

(2)

If the remote program performs any of the following actions:

Requests to end sending data

Requests to end the transaction

Requests to confirm receiving the data

Sends a FAIL

This sets on one of the following response indicators:

01 (the RCVTRNRND keyword)

02 (the RCVDETACH keyword)

03 (the RCVCONFIRM keyword)

04 (the RCVFAIL keyword)

(3)

The EOS keyword causes the session to end if indicator 01 is on and the program issues an output operation.

(4)

The system sends and receives data in the form of header records (record format HEADER) and detail records (record format DETAIL). If your program is sending, option indicator 09 can be set on, which enables the CONFIRM keyword to request the remote system to confirm receiving the data.

When receiving data, the record selection processing (RECID keyword) determines which record is received. If an H is in position 1, record format HEADER is selected. If a D or an E is in position 1, record format DETAIL is selected. If anything else is in position 1 (unexpected record format, application error, or indicators with no data, RCVDETACH, RCVFAIL, and so on), record format CATCHALL is selected.

(5)

Record format, COMMANDS, is used to request the following communications functions:

If indicator 05 is on, the FAIL function is performed.

If indicator 06 is on, the ALWWRT function is performed.

If indicator 07 is on, the DETACH function is performed.

If indicator 08 is on, the RQSWRT function is performed.

If indicator 09 is on, the CONFIRM function is performed.

If indicator 10 is on, the RSPCONFIRM function is performed.

Parent topic: Examples: DDS for each file type

Examples: DDS for each file typeYou can use these examples with appropriate high-level language programs.

Examples of database files include the following types:

Field reference file (a physical file used for reference, not data storage)

Physical file

Logical file

Examples of device files include the following types:

Display file with help specifications

Subfile examples

Printer file

ICF file

Example: A field reference file This example defines all of the fields used in an application and refers to fields only within the field reference file itself.

Example: A physical file with a new record format This example uses fields in a reference file (REF keyword) and uses a keyed-sequence access path.

Example: A logical file specifying multiple formats and new keys This example uses new field specifications and provides two record formats. Each record format provides a different view of the associated physical file and uses a key different from the associated physical file.

Example: A logical file specifying a new record format This example specifies a record format different from the associated physical file. The UNIQUE keyword is important in this example.

Example: A join logical file This example specifies that the join logical file join three physical files (PF1, PF2, and PF3). This way, an application program can get name, address, and salary information in one input operation, even though the information is stored in three different physical files.

Example: An inquiry display with two record formats in DDS This example defines a display in data description specifications (DDS). The display is displayed by output operations to the record formats PROMPT and RESPONSE.

Example: A subfile with SFLPAG value equal to SFLSIZ value This example defines a display in data description specifications (DDS). When an

output operation to the subfile-control record format SFLCTL1 is performed, the display appears.

Example: A subfile with paging by i5/OS and high-level language programThis example describes a combined method of paging a subfile that uses system resources efficiently.

Example: A horizontal subfile displayable on two display sizes This example shows how a subfile defined in data description specifications (DDS) appears on the 24 x 80 and 27 x 132 display sizes.

Example: A message subfile using DDS This example shows how to define a message subfile. The display shows the message subfile.

Example: A printer file using DDS This example contains data description specifications (DDS) for printing a customer master list.

Example: An intersystem communications function file using DDS This example contains data description specifications (DDS) for transmitting data between the System i™ platform and a remote system or device.

Parent topic: Examples: DDS coding

Example: A field reference fileThis example defines all of the fields used in an application and refers to fields only within the field reference file itself.

The following keywords are important in the example:

COLHDGEDTCDE(Z)REFFLDREFSHIFTTEXT

The following field reference file (MLGREFP) describes all fields used by any program in the application. The other files use the fields in this file.

Figure 1. DDS for a field reference file

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00010A** FLDREF MLGREFP MAILING LIST FIELD REFERENCE FILE

00020A (1)R MLGREFR TEXT('Mailing List Field Reference')

00030A ACTNUM 5 0 COLHDG('Account' 'Number')

00040A EDTCDE(Z)

00050A ACTTYP 1 0 COLHDG('Acct' 'Type')

00060A TEXT('Acct Type 1=Bus 2=Gvt +

00070A 3=Org 4=Sch 5=Pvt 9=Oth')

00080A NAME 18 COLHDG('Name')

00090A REFSHIFT(X)(4)

00100A ADDR R (2) (2)REFFLD(NAME)

00110A COLHDG('Address')(3)

00120A CITY R (2) (2)REFFLD(NAME)

00130A COLHDG('City') (3)

00140A STATE 2 COLHDG('State')

00150A ZIP 5 0 COLHDG('ZIP' 'Code')

00160A EDTCDE(X)

00170A BATNUM 6 0 COLHDG('Batch' 'Number')

00180A EDTCDE(Z)

00190A TRNTYP 1 COLHDG('Trans' 'Type')

A

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00200A TEXT('Trans Type A=Add +

00210A C=Change D=Delete')

00220A XACTNM R REFFLD(ACTNUM)

00230A XACTTTP R REFFLD(ACTTYP)

00240A XNAME R REFFLD(NAME)

00250A XADDR R REFFLD(ADDR)

00260A XCITY R REFFLD(CITY)

00270A XSTATE R REFFLD(STATE)

00280A XZIP R REFFLD(ZIP)

00290A TRNNUM 5 0 COLHDG('Transaction' 'Number')

00300A EDTCDE(Z)

00310A MLGLK1 3 0 COLHDG('Lock' 'Control')

00320A TEXT('Control Number Used for +

00330A record locking')

A

Legend:

(1)

Like all physical files, a field reference file has only one record format. The R in position 17 specifies that MLGREFR is the record format name.

(2)

The Rs in position 29 and REFFLD in positions 45 through 80 specify that the fields ADDR and CITY are to have the same attributes as NAME.

(3)

Specifying COLHDG for ADDR and CITY overrides the COLHDG attribute for NAME, which otherwise will be in effect.

(4)

Specifying REFSHIFT for NAME will cause the keyboard shift specified (X) to be used when this field (NAME) is referred to in a display file.

Parent topic: Examples: DDS for each file type

xample: A physical file with a new record formatThis example uses fields in a reference file (REF keyword) and uses a keyed-sequence access path.

The REF keyword is important in this example. This file has one record format. The names of all fields in the record format are specified.

The following physical file (called CUSMSTP for customer master physical file) describes the fields physically present in the database.

Figure 1. DDS for a physical file

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00010A*

00020A* SAMPLE PHYSICAL FILE(CUSMSTP)

00030A*

00040A (1) REF(MLGREFP)

00050A (2) R CUSMST TEXT('Customer Master Record')

00060A ACTNUM R (3)

00070A NAME R (3)

00080A ADDR R (3)

00090A CITY R (3)

00100A STATE R (3)

00110A ZIP R (3)

00120A (4) SEARCH 10 0

00130A (4) CRDLMT 8 2

00140A (5) K ACTNUM

A

Legend:

(1)

At the file level, the REF keyword refers the i5/OS® operating system to the physical file MLGREFP, which is a field reference file for this database.

(2)

At the record level, R in position 17 specifies that CUSMST is the record format name of the record in this file. (There can only be one record format in a physical file.)

(3)

At the field level, Rs in position 29 specify that the attributes of fields of the same name in the REF file are to be used as attributes of these fields.

(4)

The fields SEARCH and CRDLMT are not defined in MLGREFP; therefore, their field attributes are specified here.

(5)

At the key field level, K in position 17 specifies that ACTNUM is the key field for the file.

Parent topic: Examples: DDS for each file type

Example: A logical file specifying multiple formats and new keysThis example uses new field specifications and provides two record formats. Each record format provides a different view of the associated physical file and uses a key different from the associated physical file.

The PFILE keyword is important in this example.

Figure 1. DDS for a logical file specifying new keys

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00010A*

00020A* SAMPLE LOGICAL FILE

00030A

00040A R CUSMST1 (1)PFILE(CUSMSTP)

00050A ACTNUM

00060A NAME

00070A STATE

00080A LASTNAME I (3)SST(NAME 8 10)

00090A (2) K ACTNUM

00100A*

00110A R CUSMST2 (1)PFILE(CUSMSTP)

00120A ACTNUM

00130A NAME

00140A ZIP

00150A K *NONE

00160A (2) K NAME

A

Legend:

(1)

The two record formats (CUSMST1 and CUSMST2) in this logical file are based on the same physical file (CUSMSTP).

(2)

Record format CUSMST1 has a key different from record format CUSMST2, providing the application program with a different sequence of the same records.

(3)

The LASTNAME field is a substring of the field NAME. The usage I in position 38 must be specified because this is not a join logical file.

Parent topic: Examples: DDS for each file type

Example: A logical file specifying a new record formatThis example specifies a record format different from the associated physical file. The UNIQUE keyword is important in this example.

The following logical file (called CUSMSTL2 for customer master logical file two) uses some of the fields in the physical file CUSMSTP. Another logical file can name all fields, name fields in other physical files, concatenate fields, change the order of fields, rename fields, or choose different key fields. In this logical file, the programmer merely omits some fields from the physical file.

Figure 1. DDS for a logical file

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00010A*

00020A* SAMPLE LOGICAL FILE (CUSMSTL2)

00030A*

00040A (1)UNIQUE

00050A R CUSREC (2)PFILE(CUSMSTP)

00060A TEXT('Logical File Master Record')

00070A ACTNUM (3)

00080A NAME (3)

00090A ADDR (3)

00100A (4)K ACTNUM

A

Legend:

(1)

The UNIQUE keyword specifies that records with duplicate keys are not allowed within a member of this logical file.

(2)

The keyword PFILE (required for logical files) specifies CUSMSTP.

(3)

The field names do not have R specified in position 29 as they do in physical files or in any device file.

(4)

As in CUSMSTP, the field ACTNUM is treated as a key field.

Parent topic: Examples: DDS for each file type

Example: A join logical fileThis example specifies that the join logical file join three physical files (PF1, PF2, and PF3). This way, an application program can get name, address, and salary information in one input operation, even though the information is stored in three different physical files.

The following keywords are important in the example:

JFILE

JFLD

JOIN

JREF

Figure 1. DDS for a join logical file

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00010A (1)R JOINREC (2) JFILE(PF1 PF2 PF3)

00020A J JOIN(PF1 PF2)

00030A (3) JFLD(NAME NAME)

00040A J JOIN(PF2 PF3)

00050A JFLD(NAME NAME)

00060A (4) NAME (5) JREF(1)

00070A (4) ADDR

00080A (4) PHONE

00090A (4) SALARY

A

Legend:

(1)

R identifies the record format. There can be only one record format in a join logical file.

(2)

The JFILE keyword specifies that PF1, PF2, and PF3 are the physical files on which this join logical file is based. Because it is specified first, PF1 is the primary file. There are two secondary files: PF2 and PF3.

(3)

J identifies the join specifications. With two secondary files in this join logical file, there must be two join specifications. Each join specification defines how a pair of files is to be joined, as follows:

JOIN is required when more than two physical files are being joined, and it identifies which two files are being joined in this join specification. In the first join specification, PF1 and PF2 are joined. In the second join specification, PF2 and PF3 are joined.

Note: Secondary files can be joined either to the primary file or to another secondary file. In this example, PF2 in the second JOIN keyword can be PF1. There is no difference in the order of records supplied to the program or in performance.

JFLD identifies which fields are used to link together records from the physical files being joined. In the first join specification, NAME from PF1 links with NAME from PF2. In the second join specification, NAME from PF2 links with NAME from PF3.

(4)

The field names show which fields are presented to the program. At least one field name is required.

(5)

The JREF keyword identifies which physical file to search for the field name; in this example, NAME from PF1 is used. Note the use of the direct file number: JREF(1) indicates to use the first file on the JFILE keyword, which is PF1.

Parent topic: Examples: DDS for each file type

Example: An inquiry display with two record formats in DDSThis example defines a display in data description specifications (DDS). The display is displayed by output operations to the record formats PROMPT and RESPONSE.

CUSTOMER FILE ADD/UPDATE

Enter new or existing customer numberEnter A to ADD new Customer

Name XXXXXXXXXXXXXXXXXXXXXXXAddress XXXXXXXXXXXXXXXXXXXXXXXCity XXXXXXXXXXXXXXXXXXXXXXXState XX Zip code NNNNN

Credit limit $NNN,NNN.NN

F3 - End Program & Print Report F6 - Return to prompt

Name XXXXXXXXXXXXXXXXXXXXXXX

If the cursor is positioned in the area with Xs on the NAME field and the Help key is pressed, online help information will appear.

The following keywords are important in the example:

CAnnCHECKDSPATR(HI BL)DSPATR(UL)EDTCDE(Y)EDTCDE(2 $)ERRMSG

HELPHLPARAHLPRCDHLPBDYHLPDOCOVERLAYPRINT

The example uses +n to specify position.

Figure 1. Display with two record formats

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00010A (1) PRINT

00020A CAO3(21 'End & Print')

00030A CAO6(22 'Display PROMPT')

00040A (7) HELP

00050A (8) HLPDOC(START GENERAL HELP)

00060A (2) R PROMPT

00070A H (9) HLPDOC(LBL1 HELP#1 HELP)

00080A (9) HLPARA(2 2 2 50)

00090A 1 30'CUSTOMER FILE ADD/UPDATE'

00100A 3 2'Enter new or existing customer +

00110A number'

00120A (3) ACTNUM 5 0B +1CHECK(MF)

00130A 40 (4) ERRMSG('Customer number not +

00140A (4) found' 40)

00150A 4 2'Enter A to ADD new Customer'

00160A ADD 1 I +1

00170A (5) R RESPONSE (6) OVERLAY

00180A H (10) HLPRCD(NAMEHELP)

00190A HLPARA(6 10 6 28)

00200A H (11) HLPRCD(ADDRHELP)

00210A HLPARA(7 10 9 33)

00220A (12) HLPBDY

00230A H HLPRCD(HELPRCD1 HELPFILE)

00240A (13) HLPARA(12 18 12 40)

A

A

A

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00250A*

00260A 6 2'Name' (14)

00270A NAME 18 B 6 10 (14)

00280A 7 2'Address' (14)

00290A ADDR 18 B 7 10 (14)

00300A 8 2'City' (14)

00310A CITY 18 B 8 10 (14)

00320A 9 2'State' (14)

00330A STATE 2 B 9 10 (14)

00340A 9 19'Zip code' (14)

00350A ZIP 5Y 0B +1 (14)

00360A 12 2'Credit Limit'

00370A (15) CRDLMT 8Y 2B 12 21EDTCDE(2 $) DSPATR(HI)(16)

00380A (17) 23 2'F3 - End Program & Print Report +

00390A F6 - Return to prompt'

00400A*

00410A* HELP RECORDS

00420A*

00430A R NAMEHELP

00440A 2 2'HELP TEXT FOR NAME FIELD'

00450A 4 2'ENTER THE CUSTOMER NAME'

00460A R ADDRHELP

00470A 4 2'HELP FOR ADDRESS,CITY,STATE,ZIP'

00480A 6 2'ENTER ADDRESS,CITY,STATE & ZIP'

A

A

A

Legend:

(1)

The PRINT keyword allows the display station user to print the display at any time by pressing the Print key.

(2)

An application program displays a prompt by issuing an output operation to the record PROMPT, displaying the constant fields 'CUSTOMER FILE ADD/UPDATE', 'ENTER EXISTING CUSTOMER NUMBER', 'ENTER A TO ADD NEW CUSTOMER', and the named fields ACTNUM and ADD.

(3)

The CHECK(MF) keyword specifies that when the user types into one position of the field ACTNUM, he must type into all five positions before pressing the Enter key, or an error message is displayed and the keyboard is locked. The user must press the Reset key and reenter through the input field.

(4)

If record format PROMPT is displayed and your program sets on indicator 40 when an output operation is sent to record format PROMPT, the error message 'Customer number not found' is displayed on the message line (line 24 of the 24-line display unless the MSGLOC keyword is specified). The message is highlighted, field ACTNUM is displayed with its image reversed, and the keyboard is locked until the user presses the Reset key.

(5)

After the user presses the Enter key, the application program retrieves the required information from the database and sends an output operation to record format RESPONSE, displaying the fields described in the next paragraphs.

(6)

The OVERLAY keyword specifies that an output operation to this record format (RESPONSE) does not cause the entire display to be cleared, as it is by default.

(7)

The HELP keyword enables the Help key for this display.

(8)

The HLPDOC keyword specified at the file level identifies the document to be displayed when no help area for the active records contains the current cursor location.

(9)

The HLPDOC and HLPARA keywords on this H specification specify that the HELP#1 document in the HELP folder will be displayed starting at the LBL1 help label if the Help key is pressed while the cursor is in positions 2 through 50 of line 2.

(10)

The HLPRCD and HLPARA keywords on this H specification cause the record NAMEHELP to be displayed if the Help key is pressed while the cursor is in positions 10 through 28 of line 6. The record NAMEHELP is defined in this display file; therefore, a file name does not have to be specified on the HLPRCD keyword.

Note: When using application help keywords, the screen is automatically cleared.

(11)

The HLPRCD and HLPARA keywords on this H specification cause the ADDRHELP record to be displayed if the Help key is pressed while the cursor is in positions 10 through 28 of line 7, 8, or 9.

(12)

The HLPBDY keyword limits the help records displayed when the Page key is pressed. If either NAMEHELP or ADDRHELP is displayed when the Help key is pressed, the NAMEHELP and ADDRHELP records are accessible using the Page key. If HELPRCD1 is displayed when the Help key is pressed, the help records from other H specifications are not accessible using the Page key.

(13)

The HLPRCD and HLPARA keywords on this H specification cause the record HELPRCD1 in the file HELPFILE to be displayed if the Help key is pressed while the cursor is in positions 18 through 40 of lines 12 through 40. This record is in a separate display file called HELPFILE.

(14)

Five constant fields ('Name', 'Address', 'City', 'State', and 'Zip Code') and five named fields (NAME, ADDRES, CITY, STATE, ZIP) are grouped together on the display by the line and position specifications. The default of the NAME, ADDRES, CITY, and STATE fields is set to character-type fields (A in position 35) because no decimal positions are specified. ZIP is a numeric-only, integer field (Y in position 35; 0 in position 37), so its display length equals its specified length.

(15)

The field CRDLMT is specified with EDTCDE (2 $). EDTCDE(2) is used for monetary amounts, and the $ specifies the floating currency symbol.

(16)

The DSPATR(H1) keyword highlights the field CRDLMT.

(17)

Instructions to the workstation user are generally located at the bottom of the display, just above the message line.

Parent topic: Examples: DDS for each file type

Example: A subfile with SFLPAG value equal to SFLSIZ valueThis example defines a display in data description specifications (DDS). When an output operation to the subfile-control record format SFLCTL1 is performed, the display appears.

First Field Second Field

XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX

The following keywords are important in the example:

ROLLDOWNROLLUPSFLCLRSFLDSP

SFLDSPCTLSFLPAGSFLSIZ

The file in Figure 1 has one column of subfile records. Constant fields in the subfile control-record format are used as headings for columns of fields in the subfile records.

Figure 1. Subfile with subfile size equal to subfile page

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00010A* USE OF SUBFILE KEYWORDS

00020A (1) R SFL1 SFL

00030A (2) FLD1 10 0I 3 11

00040A (2) FLD2 16 O 3 26

00050A

00060A (1) R SFLCTL1 SFLCTL(SFL1)

00070A SFLSIZ(18) (3)

00080A SFLPAG(18) (3)

00090A 05 SFLDSP (4)

00100A 05 SFLDSPCTL (4)

00110A N05 SFLCLR (5)

00120A ROLLUP(01) ROLLDOWN(02)(6)

00130A 1 11'First Field' (7)

00140A 1 26'Second Field' (7)

A

Legend:

(1)

The subfile record format SFL1 and the subfile control-record format SFLCTL1 together define one subfile. The parameter value for the SFLCTL keyword is the name of the subfile record format.

(2)

Each subfile record is made up of two fields: FLD1 and FLD2. FLD1 is 10 bytes long (11 bytes display length because it defaults to signed numeric); FLD2 is 16 bytes long. FLD1 is an input-only field; FLD2 is an output-only field. Eighteen subfile records appear on the display, with the first one on line 3 and the last one on line 20. For each subfile record on the display, two fields (FLD1 and FLD2) appear, with four spaces between FLD1 and FLD2.

(3)

SFLSIZ and SFLPAG (required keywords) have equal values (18). Therefore one page equals the whole subfile. For all subfiles, the value of the SFLPAG keyword is the number of subfile records displayed at any one time (unless the SFLDROP keyword or variable-length records are used).

(4)

SFLDSP (a required keyword) and SFLDSPCTL (an optional keyword) are specified with indicator 05. Therefore, when indicator 05 is set on, the subfile and subfile control records can be displayed by an output operation to the subfile control-record format SFLCTL1.

(5)

SFLCLR (an optional keyword) is specified with option indicator 05 preceded by an N. When indicator 05 is set off, the subfile can be cleared by an output operation to SFLCTL1.

(6)

ROLLUP (an optional keyword) is specified with response indicator 01, and ROLLDOWN (an optional keyword) is specified with response indicator 02. Note also that the entire subfile equals one page, which means that the whole subfile is displayed at one time. Therefore, when the display station user presses the Page Up key, control passes to the program with indicator 01 on, and when the workstation user presses the Page Down key, control passes to the program with indicator 02 on. The program must handle paging, by reading, clearing, rewriting, and redisplaying the subfile. Without ROLLUP and ROLLDOWN specified, the workstation user will receive an error message when pressing the Page Up or Page Down key.

(7)

Two constants ('First Field' and 'Second Field') are displayed when the subfile control-record is displayed (SFLDSPCTL in effect). As specified in this subfile, they act as column headings to the subfile records.

Parent topic: Examples: DDS for each file type

Example: A subfile with paging by i5/OS and high-level language programThis example describes a combined method of paging a subfile that uses system resources efficiently.

In some applications, the number of records in the subfile might be quite large. However, the application user might want to view only the first page or two of these records. In this case, it might be faster and more efficient for the application program to build the subfile a page at a time as requested by the user. The i5/OS® operating system handles the paging of records in the subfile. It also returns a Page Up key indicator to the high-level language program when another page should be added to the end of the subfile. The application user can detect no difference between a page-up request handled by the i5/OS operating system and one handled by the high-level language program.

NAME DEPARTMENT PHONE

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX NNNNXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX NNNNXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX NNNNXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX NNNNXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX NNNNXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX NNNNXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX NNNNXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX NNNNXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX NNNNXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX NNNNXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX NNNNXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX NNNNXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX NNNNXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX NNNNXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX NNNNXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX NNNNXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX NNNN

The following keywords are important in the example:

SFLPAGSFLSIZ

The SFLSIZ value is larger than the SFLPAG value. The subfile is paged by the SFLPAG value.

Figure 1. Subfile with paging by i5/OS operating system and high-level language program in DDS

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00010A R SETSFL SFL

00020A 50 SFLNXTCHG

00030A NAME 30 0 5 2

00040A DEPT 10 5 40

00050A PHONE 4 0 5 58

00060A R SETCTL SFLCTL(SETSFL)

00070A SFLSIZ(0034) (1)

00080A SFLPAG(0017)

00090A 40 SFLDSP

00100A 41 SFLDSPCTL

00110A 42 SFLDLT

00120A 43 SFLCLR

00130A 49 SFLEND (2)

00140A N49 ROLLUP(26)

00150A LOCK

00160A OVERLAY

00170A SETRRN 4S 0H SFLRCDNBR(CURSOR)(3)

00180A 3 2'NAME'

00190A 3 40'DEPARTMENT'

00200A 3 58'PHONE'

A

Legend:

(1)

The SFLSIZ value must be greater than the SFLPAG value so that the i5/OS operating system will handle paging within the subfile. A maximum of 9999 records can be stored in the subfile.

(2)

The SFLEND keyword can be specified with the ROLLUP keyword. One indicator can be used to option both keywords. The application program turns on the indicator to disable the Page Up key and omit the plus sign (+) on the last subfile page when the last page of the subfile is displayed.

(3)

The SFLRCDNBR keyword should be specified so the last subfile page can be displayed after it is built by the high-level language program.

Records in the subfile with changed input fields (modified data tags) will be changed after a new page is added to the subfile by the high-level language program.

Parent topic: Examples: DDS for each file type

Example: A horizontal subfile displayable on two display sizesThis example shows how a subfile defined in data description specifications (DDS) appears on the 24 x 80 and 27 x 132 display sizes.

COLUMN 1 COLUMN 2_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX COLUMN 1 COLUMN 2_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX_____ XXXXXXXXXXXXXXXX _____ XXXXXXXXXXXXXXXX

The following keywords are important in the example:

DSPSIZSFLLIN

Subfile records appear in two columns (SFLLIN keyword). The subfile can be displayed on two display sizes (DSPSIZ keyword).

Figure 1. Horizontal subfile on two display sizes

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00010A* HORIZONTAL SUBFILE ON TWO DISPLAY SIZES

00020A*

00030A (1) DSPSIZ(*DS3 *DS4)

00040A R SFL1 SFL

00050A FLDA 10Y 0I 3 11

00060A FLDB 16 O 3 23

A

00070A R SFLCTL1 SFLCTL(SFL1)

00080A SFLSIZ(50)

00090A (2) SFLPAG(16)

00100A *DS4 (2) SFLPAG(40)

00110A (3) SFLLIN(5)

00120A *DS4 (3) SFLLIN(5)

A

00130A 01 SFLEND

00140A 02 SFLDSP

00150A 03 SFLDSPCTL

00160A 04 SFLCLR

A

00170A 1 21'COLUMN 1'

A

00180A 1 55'COLUMN 2'

A

Legend:

(1)

There is one keyword at the file level, the keyword DSPSIZ (optional). This keyword has two values, *DS3 and *DS4, which indicate that the primary display size is 24 x 80, and the secondary display size is 27 x 132.

(2)

The SFLPAG keyword (required), is specified once with a value of 16 and again with a value of 40. The first time it applies to a device with the primary display size (default of *DS3, or 24 x 80); the second time, coded with a condition name of *DS4, it applies to a device with the secondary display size (27 x 132).

(3)

The SFLLIN keyword causes a subfile to be displayed horizontally. The parameter value specifies the number of spaces between columns of records. In this example, five spaces separate columns of records on both the 24 x 80 display size (*DS3) and the 27 x 132 display size (*DS4). Because *DS3 is the primary display size, it does not need to be specified in positions 9 through 12.

Parent topic: Examples: DDS for each file type

Example: A message subfile using DDSThis example shows how to define a message subfile. The display shows the message subfile.

MESSAGE SUBFILE

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

The following keywords are important in the example:

SFLMSGKEYSFLPGMQSFLMSGRCD

Records in the subfile are messages from a message file.

Figure 1. Message subfile

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00010A*

00020A* MESSAGE SUBFILE

00030A*

00040A R SFLR SFL

00050A SFLMSGRCD(3) (1)

00060A MSGKEY (2) SFLMSGKEY (2)

00070A PGMQ (2) SFLPGMQ (2)

A

00080A R STLCTLR SFLCTL(SFLR)

00090A SFLSIZ(12) (3)

00100A SFLPAG(6) (3)

00110A 01 SFLDSP

00120A 02 SFLDSPCTL

00130A 03 SFLCLR

00140A 04 SFLEND (3)

A

A

00150A 1 32'MESSAGE SUBFILE'

A

Legend:

(1)

Specifying the SFLMSGRCD keyword on the subfile record format identifies this subfile as a message subfile. The parameter value specified causes the subfile to appear on line 3 of the display.

(2)

The fields MSGKEY and PGMQ are user-defined names given to the two fields required for the subfile record format for a message subfile. The only

specifications allowed for them are their names and the SFLMSGKEY and SFLPGMQ keywords, in the order shown.

This subfile is built by a series of output operations to SFLR that place messages in the subfile as subfile records. Messages are truncated to fit single lines (76 characters or 128 characters, depending on display size), and second-level help is available. This subfile is displayed by an output operation to SFLCTLR with option indicator 01 set on.

(3)

This subfile is paged by the i5/OS® operating system when the display station user presses a Page Up or a Page Down key. The SFLEND keyword allows the i5/OS operating system to display a plus sign whenever the subfile can be paged up.

Parent topic: Examples: DDS for each file type

Example: A printer file using DDSThis example contains data description specifications (DDS) for printing a customer master list.

The following keywords are important in the example:

EDTCDE(Y)EDTCDE(Z)PAGNBRSKIPBSPACEA

UNDERLINEBARCODECHRSIZCOLOR

This printer file uses space and skip keywords instead of line numbers.

Figure 1. Printer file

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00010A*

00020A* SAMPLE PRINTER FILE

00030A*

00040A (1) REF(MLGREFP)

00050A R HEADER TEXT('TWO-LINE HEADING, UNDERLINED')

00060A (2) SKIPB(2)

00070A (2) 29'CUSTOMER MASTER FILE'

00080A (2) 75DATE EDTCDE(Y)

00090A (2) +1TIME

00100A (2) 122'Page'

00110A (2) +1PAGNBR EDTCDE(Z) SPACEA(2)

00120A (2) 2'ACCOUNT CUSTOMER'

00130A (2) SPACEA(1)

00140A (2) 2'NUMBER NAME +

00150A ADDRESS +

00160A CITY +

00170A STATE ZIP '

00180A (3) UNDERLINE

00190A SPACEA(2)

A

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00200A R DETAIL TEXT('ONE-LINE RECORD')

00210A (4) SPACEA(5)

00220A ACTNUM R (4) 2CHRSIZ(2 2)

00230A NAME R (5)+4COLOR(BLU)

00240A ADDR R +3

00250A CITY R +3

00260A STATE R (6)+3BARCODE(CODE30F9 4 *NOHRI *AST)

00270A ZIP R +5

A

Legend:

(1)

This printer file refers to the field reference file MLGREFP.

(2)

When SKIPB(2) is specified at the record level, the printer skips to line 2 before printing the record format (HEADER). Also, line numbers in positions 39 through 41 are not allowed.

(3)

UNDERLINE is a field-level keyword that causes the constant field preceding it to be underlined on the printout.

(4)

The CHRSIZ keyword specified here causes the ACTNBR field to print with its height and width expanded by 2.

(5)

The COLOR keyword causes the NAME field to print in blue if you use a printer that supports color (the 4224 Printer).

(6)

The BARCODE keyword specified for the STATE field causes the CODE30F9 bar code to print for the STATE field if you use an IPDS™ printer.

Parent topic: Examples: DDS for each file type

Example: An intersystem communications function file using DDSThis example contains data description specifications (DDS) for transmitting data between theSystem i™ platform and a remote system or device.

The following keywords are important in the example:

CONFIRMDETACHEVOKERCVDETACHRCVFAILRCVCONFIRMRCVTRNRND

RECIDSYNLVLEOSRSPCONFIRMALWWRTFAILRQSWRT

Figure 1. ICF file

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00010A*

00020A* SAMPLE ICF FILE

00030A*

00040A 01 (3) EOS

00050A (2) RCVTRNRND(01 'TRNRND INDICATION')

00060A (2) RCVDETACH(02 'DETACH RECEIVED')

00070A (2) RCVCONFIRM(03 'CONFIRM REQUEST')

00080A (2) RCVFAIL(04 'FAIL RECEIVED')

00090A

00100A R CATCHALL

00110A FLD1 132A

00120A*

00130A R SNDEVOKE EVOKE(&LIBNME/&PGMNME);

00140A (1) SYNLVL(*CONFIRM) SECURITY(2 PASSWRD)

00150A (1) CONFIRM

00160A PGMNME 10A P

00170A LIBNME 10A P

00180A PASSWRD 8A P

00190A*

00200A R HEADER RECID(1 'H')

A

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00210A 09 CONFIRM

00220A ID 1A

00230A (4) PART# 12A

00240A UNTCST 6S 2

00250A QTYONORDR 9B 0

00260A TOTAL 9B 0

00270A*

00280A R DETAIL RECID(1 'D') RECID(1 'E')

00290A 09 CONFIRM

00300A ID 1A

00310A (4) LOC 6A

00320A QTY 9B 0

00330A*

00340A R COMMANDS

00350A 05 (5) FALL

00360A 06 (5) ALWWRT

00370A 07 (5) DETACH

00380A 08 (5) RQSWRT

00390A 09 (5) CONFIRM

00400A 10 (5) RSPCONFIRM

A

Legend:

(1)

The record format SNDEVOKE causes the program specified in the field PGMNME and the library specified in the field LIBNME to be started on the remote system. It also establishes a synchronization level of *CONFIRM for the transaction and passes the data in the field PASSWRD as security information. The CONFIRM keyword requests that the remote system confirm the start of the program.

(2)

If the remote program performs any of the following actions:

Requests to end sending data

Requests to end the transaction

Requests to confirm receiving the data

Sends a FAIL

This sets on one of the following response indicators:

01 (the RCVTRNRND keyword)

02 (the RCVDETACH keyword)

03 (the RCVCONFIRM keyword)

04 (the RCVFAIL keyword)

(3)

The EOS keyword causes the session to end if indicator 01 is on and the program issues an output operation.

(4)

The system sends and receives data in the form of header records (record format HEADER) and detail records (record format DETAIL). If your program is sending, option indicator 09 can be set on, which enables the CONFIRM keyword to request the remote system to confirm receiving the data.

When receiving data, the record selection processing (RECID keyword) determines which record is received. If an H is in position 1, record format HEADER is selected. If a D or an E is in position 1, record format DETAIL is selected. If anything else is in position 1 (unexpected record format, application error, or indicators with no data, RCVDETACH, RCVFAIL, and so on), record format CATCHALL is selected.

(5)

Record format, COMMANDS, is used to request the following communications functions:

If indicator 05 is on, the FAIL function is performed.

If indicator 06 is on, the ALWWRT function is performed.

If indicator 07 is on, the DETACH function is performed.

If indicator 08 is on, the RQSWRT function is performed.

If indicator 09 is on, the CONFIRM function is performed.

If indicator 10 is on, the RSPCONFIRM function is performed.

Parent topic: Examples: DDS for each file type

Sequence number for ICF files (positions 1 through 5)You can use these positions to specify a sequence number for each line on the form.

The sequence number is optional and is for documentation purposes only.Parent topic: Defining an ICF file using DDS

Form type for ICF files (position 6)You specify an A in this position to identify this as a DDS form.

The form type is optional and is for documentation purposes only.Parent topic: Defining an ICF file using DDS

Comment for ICF files (position 7)You specify an asterisk (*) in this position to identify this line as a comment.

Comment lines can appear anywhere in DDS and are kept only in the source file. They appear on the source computer printout but do not appear on the expanded source computer printout.

Use positions 8 through 80 for comment text. A blank line (no characters specified in positions 7 through 80) is handled as a comment.Parent topic: Defining an ICF file using DDS

Condition for ICF files (positions 7 through 16)Positions 7 through 16 are a multiple-field area in which you can specify option indicators.

Option indicators are 2-digit numbers from 01 to 99. Your program can set option indicators on (hexadecimal F1) or off (hexadecimal F0) to select a keyword for output operations. In ICF files, option indicators are valid only for record- and file-level keywords.

A condition is an AND grouping of two through nine indicators that must all be in effect before the keyword is selected. For the indicators to be in effect, they are set off if the letter N is specified, or set on if N is not specified. You can specify a maximum of nine indicators for each condition and nine conditions for each keyword. Therefore, a maximum of 81 indicators can be specified for each keyword, when nine indicators are used with nine conditions. An AND condition occurs when you specify a condition requiring that more than one indicator must be on or off before the condition is satisfied and the keyword is selected. You can join the first indicator with the second, and the third, and so on, by AND to form a condition. You must specify the keyword on the same line as the last (or only) set of indicators specified.

You can also specify several conditions for a keyword such that if any one of them is satisfied, the keyword is selected. This is called an OR relationship. You can join the first condition with the second condition, and the third condition, and so on, by OR. Note that conditions within the OR relationship can consist of just one indicator or several indicators joined by AND. Indicators can be joined by AND to form a condition. Conditions can be joined by OR to give your program several ways to select the keyword.

Specify the conditions by entering the following values:

Position 7 (AND)

If you need more than three indicators to form an AND condition, specify the indicators on the next line or lines. You can specify an A in position 7 on the second or following lines to continue the AND condition, or you can leave it blank because A is the default.

Position 7 (OR)

If you specify several conditions that are to be joined together by OR, each condition must start on a new line and each condition, except the first, must have an O in position 7. An O specified for the first condition produces a warning message, and that position is assumed to be blank.

Positions 8, 11, 14 (NOT)

If you want an indicator to be off instead of on to satisfy a condition, specify an N in the position just preceding the indicator (position 8, 11, or 14).

Specifying a condition for more than one keyword for ICF files

If you want to specify a condition for one or more keywords, the last (or only) indicator must appear on the same line as the keywords. If the condition applies to keywords on more than one line, you must use keyword continuation for the indicators to apply to all keywords.Parent topic: Defining an ICF file using DDS

Related informationRules for DDS keywords and parameter values

Type of name or specification for ICF files (position 17)You can enter a value in this position to identify the type of name specified in positions 19 through 28.

The valid entries for ICF files are:Entry Meaning

R Record format name

Blank Field name

The ICF file example in Defining an ICF file using DDS shows how to code the name type.Parent topic: Defining an ICF file using DDSRelated referenceName for ICF files (positions 19 through 28)

Name for ICF files (positions 19 through 28)You can use these positions to specify record format names and field names.

Names must begin in position 19.Record format name for ICF files

When you specify an R in position 17, the name specified in positions 19 through 28 is a record format name. You can specify more than one record format for an ICF file, but each record format name must be unique within that file.Field name for ICF files

When you specify a blank in position 17, the name specified in positions 19 through 28 is a field name. Field names must be unique within the record format. For ICF files, the order in which field names are specified in the DDS is the order the fields take in the input and output buffers.

The keywords CANCEL, EOS, FAIL, and RQSWRT must have option indicators when they apply to a record with fields. Fields are ignored at run time (not sent across the line) when any of these keywords are in effect. At creation time, if any of these keywords have no option indicator and apply to a record with fields, a severe error is issued and the file will not be created.Parent topic: Defining an ICF file using DDSRelated referenceType of name or specification for ICF files (position 17)Related informationRules for DDS keywords and parameter values

Reserved for ICF files (position 18)

This position does not apply to any file type. Leave this position blank unless you use it for comment text.

Parent topic: Defining an ICF file using DDS

Reference for ICF files (position 29)You specify an R in this position to use the reference function of the program. This function copies the attributes of a previously defined, named field (called the referenced field) to the field you are defining.

The referenced field can be previously defined in the ICF file you are defining. The referenced field can also be defined in a previously created database file (the database file to be referenced is specified with the REF or REFFLD keyword). The field attributes referenced are the length, data type, and decimal positions of the field, as well as the ALIAS, FLTPCN, and TEXT keywords.

If you do not specify R, you cannot use the reference function for this field and you must specify field attributes for this field.

Position 29 must be blank at the file and record levels.

The name of the referenced field can be either the same as the field you are defining or different from the field you are defining. If the name of the referenced field is the same as the field you are defining, you need only specify the letter R in position 29 (in addition to specifying the name of the field you are defining in positions 19 through 28). If the name of the field you are defining is different, you must specify the name of the referenced field with the REFFLD (Referenced Field) keyword.

You can specify the name of the file defining the referenced field as a parameter value with the REF or REFFLD keyword.

You do not need to copy all attributes from the previously described field to the field you are defining. To override specific attributes of the referenced field, specify those attributes for the field you are defining. For example, if you specify a length for the field you are defining, the length is not copied from the referenced field.

When you override the data type to character (by specifying A in position 35), the decimal positions value is not copied from the referenced field.

Note: After the ICF file is created, you can delete or change the referenced file without affecting the field descriptions in the ICF file. Delete and re-create the ICF file to incorporate changes made in the referenced file.Parent topic: Defining an ICF file using DDSRelated referenceREF (Reference) keyword for ICF filesREFFLD (Referenced Field) keyword for ICF filesRelated informationWhen to specify REF and REFFLD keywords for DDS files

REF (Reference) keyword for ICF filesYou can use this file-level keyword to specify the name of a file from which field descriptions are to be retrieved.

Use the REF keyword when you want to duplicate descriptive information from several fields in a previously, defined record format. This keyword allows you to code the file name once rather than on each field that refers to the file as is required by the REFFLD keyword. To refer to more than one file, use the REFFLD keyword. The REF keyword can be specified only once.

The format of the keyword is:

REF([library-name/]database-file-name [record-format-name])

If there is more than one record format in the reference file, specify a record format name as a parameter value for this keyword to tell the i5/OS® operating system which one to use unless the record formats should be searched sequentially.

The database-file-name is a required parameter value for this keyword. The library-name and the record-format-name are optional.

If you do not specify the library-name, the current library list (*LIBL) at file creation time is used. If the record-format-name is not specified, each format is searched in order (as they are specified). The first occurrence of the field is used. For more information, see When to specify REF and REFFLD keywords for DDS files.

You can specify a distributed data management (DDM) file on this keyword. When using a DDM file, the database-file-name and the library-name are the DDM file name and library name on the source system. The record-format-name is the record format name in the remote file on the target system.

Note: IDDU files cannot be used as reference files.

Option indicators are not valid for this keyword.Examples

In the first example, FLD1 has the same attributes as the first (or only) FLD1 in the file, FILE1:

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

A REF(FILE1)

A R RECORD

A FLD1 R

A

In the second example, FLD1 has the same attributes as FLD1 in RECORD2 in FILE1 in LIB1:

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

A REF(LIB1/FILE1 RECORD2)

A R RECORD

A FLD1 R

AParent topic: DDS keyword entries for ICF files (positions 45 through 80)Related referenceReference for ICF files (position 29)

When to specify REF and REFFLD keywords for DDS filesWhen you decide whether to specify the REF (reference) keyword, the REFFLD (referenced field) keyword, or both, you need to consider some questions. You also need to know how to specify the parameter values for each REF or REFFLD keyword that you specify.

You must specify R in position 29 for each field that refers to another field that was previously defined.

Answer the following questions to determine which keyword to use:

REF or REFFLD or both?

If all or most of the fields you refer to are defined REF at the file level.

Specify REFFLD for every field you reference:

That is not in the file you specify on the REF keyword.

or

Whose name differs from the name of the field it references. This includes fields that reference fields in the file you are defining.

Do you need a database file name for each REFFLD keyword you specify?

The database file name specified on a REFFLD keyword overrides the database file name specified on the REF keyword.

On the REFFLD keyword, you can specify:

*SRC so that the i5/OS® operating system searches the file you are defining for the referenced field. The referenced field must be defined before you define the field that references it.

The name of the database file that the i5/OS operating system is to search through to find the referenced field.

If you do not specify *SRC or a database file name on the REFFLD keyword, the default is *SRC if the REF keyword is not specified. If the REF keyword is specified, the default is the database file name specified on the REF keyword.

Is a library name necessary for each database file you specify?

If the job that will create the file you are defining (perhaps your interactive job) has a library list, and the database file you specified is on the library list, enter only the file name (FILE1). Otherwise, specify the file name qualified by the library name (LIB1/FILE1).

Do you need a record format name for each REF or REFFLD keyword you specify?

If the file you reference has only one record format, do not specify a record format name.

If it has more than one record format, specify a record format name.

The following example illustrates reference function specifications. It is not a valid example of any file except an ICF file. Display and printer files must have a location specified for each field. Physical files can have only one record format. The REF and REFFLD keywords are not allowed in logical files.

Figure 1. Sample Reference Function Specifications

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00010A REF(FILE1) (1)

00020A R RECORD1

00030A FIELD1 R (1)

00040A FIELD2 R (1)

00050A FIELD3 R REFFLD(FLD3) (2)

00060A FIELD4 R REFFLD(FLD4 FILE2) (3)

00070A FIELD5 R REFFLD(FLD5 LIB1/FILE3) (4)

00080A FIELD6 R REFFLD(RECORDB/FLD6 LIB1/FILE4) (5)

00090A FIELD7 R REFFLD(FIELD6 *SRC) (6)

00100A FIELD8 R REFFLD(FLD6) (7)

00110A R RECORD2

00120A FIELD1 20 (8)

00130A

00140A R RECORD3

00150A FIELD1 R REFFLD(RECORD2/FIELD1 *SRC) (9)

00160A

00170A R RECORD4

00180A FIELD1 R REFFLD(FIELD1 *SRC) (10)

A

Note: For line 00010, you can also specify library name and record format name. See the REF keyword example.Legend:

1

FIELD1 and FIELD2 have the same attributes as FIELD1 and FIELD2 in FILE1.

2

FIELD3 has the same attributes as FLD3 in FILE1.

3

FIELD4 has the same attributes as FLD4 in FILE2.

4

FIELD5 has the same attributes as FLD5 in FILE3 in LIB1.

5

FIELD6 has the same attributes as FLD6 in record format RECORDB in FILE4 in LIB1.

6

FIELD7 has the same attributes as FIELD6 (on the preceding line in this file).

7

FIELD8 has the same attributes as FLD6 in FILE1.

8

FIELD1 in RECORD2 has unique field attributes. (It does not use the reference function; notice that R is not specified in position 29.)

9

FIELD1 in RECORD3 has the same attributes as FIELD1 in RECORD2.

10

FIELD1 in RECORD4 has the same attributes as FIELD1 in RECORD1.

Parent topic: DDS concepts

DDS keyword entries for ICF files (positions 45 through 80)The keyword entries are specified in positions 45 through 80. Be sure to follow the rules for DDS keywords and parameter values.

ALIAS (Alternative Name) keyword for ICF files You can use this field-level keyword to specify an alternative name for a field.

ALWWRT (Allow Write) keyword for ICF files You can use this file- or record-level keyword to allow your program to indicate when it has finished sending data.

CANCEL (Cancel) keyword for ICF files You can use this file- or record-level keyword to cancel the current chain of data (group of records) that is being sent to the remote program.

CNLINVITE (Cancel Invite) keyword for ICF files You can use this file- or record-level keyword to cancel any valid invite operation for which no input has yet been received.

CONFIRM (Confirm) keyword for ICF files You can use this file- or record-level keyword to request the remote program to confirm that it received the data.

CTLDTA (Control Data) keyword for ICF files You can use this file- or record-level keyword to inform the remote program that control data is being sent.

DETACH (Detach) keyword for ICF files You can use this file- or record-level keyword to explicitly inform the remote program that your program has completed sending data and wants to end the transaction.

DFREVOKE (Defer Evoke) keyword for ICF files You can use this file- or record-level keyword with the EVOKE keyword to delay an evoke request until either the send buffer is full of data or a FRCDTA keyword is received.

ENDGRP (End of Group) keyword for ICF files You can use this file- or record-level keyword to allow your program to indicate the end of a user-defined group of records.

EOS (End of Session) keyword for ICF files You can use this file- or record-level keyword to specify an end of session function. To end a session, your program issues a write operation with the EOS keyword in effect.

EVOKE (Evoke) keyword for ICF files You can use this file- or record-level keyword to start a program on the remote system.

FAIL (Fail) keyword for ICF files You can use this file- or record-level keyword to inform the remote program that the data sent or received is not valid.

FLTPCN (Floating-Point Precision) keyword for ICF files You can use this field-level keyword to specify the precision of a floating-point field.

FMH (Function Management Header) keyword for ICF files You can use this file- or record-level keyword to inform the remote program that a function management header (FMH) is being sent.

FMTNAME (Format Name) keyword for ICF files You can use this file- or record-level keyword to specify that the record format name is to be sent to the remote program when your program issues an output operation.

FRCDTA (Force Data) keyword for ICF files You can use this record-level keyword to clear the buffer when there is no more data to send, without waiting for the buffer to become full.

INDARA (Indicator Area) keyword for ICF files You can use this file-level keyword to remove option and response indicators from the buffer or record area, and to place them in a 99-byte separate indicator area.

INDTXT (Indicator Text) keyword for ICF files You can use this file- or record-level keyword to associate descriptive text (indicating intent or use) with a specific response or option indicator.

INVITE (Invite) keyword for ICF files You can use this file- or record-level keyword to invite the program device for a later read operation.

NEGRSP (Negative Response) keyword for ICF files You can use this file- or record-level keyword to send a negative response to the remote program. The response indicates that your program detected an error in the data received.

PRPCMT (Prepare for Commit) keyword for ICF files You can use this record-level keyword to request the remote program to prepare for a synchronization point.

RCVCANCEL (Receive Cancel) keyword for ICF files You can use this file- or record-level keyword to set on a response indicator to inform your program that the remote program has sent a cancel request.

RCVCONFIRM (Receive Confirm) keyword for ICF files You can use this file- or record-level keyword to set on a response indicator if the data received by your program contains a confirmation request from the remote program.

RCVCTLDTA (Receive Control Data) keyword for ICF files You can use this file- or record-level keyword to set on a response indicator to inform your program that control data has been received.

RCVDETACH (Receive Detach) keyword for ICF files You can use this file- or record-level keyword to set on a response indicator if the remote program is ending the transaction.

RCVENDGRP (Receive End of Group) keyword for ICF files You can use this file- or record-level keyword to set on a response indicator to inform your program of the end of a user-defined group of records.

RCVFAIL (Receive Fail) keyword for ICF files You can use this file- or record-level keyword to set on a response indicator when

the local program determines that the remote program has sent a failure indication.

RCVFMH (Receive Function Management Header) keyword for ICF files You can use this file- or record-level keyword to set on a response indicator to inform your program that a function management header has been received.

RCVNEGRSP (Receive Negative Response) keyword for ICF files You can use this file- or record-level keyword to set on a response indicator to inform your program that the remote program has sent a negative response.

RCVROLLB (Receive Rollback Response Indicator) keyword for ICF files You can use this file- or record-level keyword to indicate whether a rollback operation has been received.

RCVTKCMT (Receive Take Commit Response Indicator) keyword for ICF filesYou can use this file- or record-level keyword to indicate whether a take_commit request has been received.

RCVTRNRND (Receive Turnaround) keyword for ICF files You can use this file- or record-level keyword to set on a response indicator. This response indicator informs your program that the sending program has stopped sending and has given the local program the right to send.

RECID (Record Identification) keyword for ICF files You can use this record-level keyword to allow your program to identify a record-by-record format when it issues a read-from-invited-devices operation using the name of the file.

REF (Reference) keyword for ICF files You can use this file-level keyword to specify the name of a file from which field descriptions are to be retrieved.

REFFLD (Referenced Field) keyword for ICF files You can use this field-level keyword when referring to a field under one of these conditions.

RQSWRT (Request Write) keyword for ICF files You can use this file- or record-level keyword to request permission for your program to send data.

RSPCONFIRM (Respond Confirm) keyword for ICF files You can use this file- or record-level keyword to send a positive response to a received confirmation request.

SECURITY (Security) keyword for ICF files You can use this file- and record-level keyword to include security information when your program starts a program on a remote system.

SUBDEV (Subdevice) keyword for ICF files You can use this file- or record-level keyword to allow your program to request a specific subdevice (for example, a printer) to which transmitted data should be directed.

SYNLVL (Synchronization Level) keyword for ICF files You can use this file- and record-level keyword to specify the level of synchronization your program requires.

TEXT (Text) keyword for ICF files You can use this record- or field-level keyword to supply a text description (or comment) for the record format or field used for program documentation.

TIMER (Timer) keyword for ICF files You can use this record-level keyword to specify an interval of time for your program to wait before your program performs some specified function.

TNSSYNLVL (Transaction Synchronization Level) keyword for ICF files You can use this file- or record-level keyword to specify the transaction synchronization level that is performed while the system is issuing a write operation when a DETACH or ALWWRT keyword is specified. The transaction synchronization level is specified on the SYNLVL keyword.

VARBUFMGT (Variable Buffer Management) keyword for ICF files You can use this record-level keyword to send or receive multiple or partial records using one record format per output operation.

VARLEN (Variable-Length User Data) keyword for ICF files You can use this record-level keyword to indicate that the length of the record sent across the line is variable. The length is specified at run time in the field parameter.

Parent topic: DDS for ICF filesRelated informationRules for DDS keywords and parameter values

DDS for ICF filesYou can use data description specifications (DDS) to define intersystem communications function (ICF) files. This topic collection provides the information you need to code the positional and keyword entries that define these files.

Printable PDF Use this to view and print a PDF of this information.

Defining an ICF file using DDS When you specify positional entries for ICF files, you should follow some specific rules for filling in positions 1 through 44 of the data description specifications (DDS) form.

DDS keyword entries for ICF files (positions 45 through 80) The keyword entries are specified in positions 45 through 80. Be sure to follow the rules for DDS keywords and parameter values.

DBCS considerations for ICF files Be aware of these bracketed-DBCS considerations for ICF files.

DBCS considerations for ICF filesBe aware of these bracketed-DBCS considerations for ICF files.

The functions described in these topics are supported on both DBCS and non-DBCS systems.

Positional entry considerations for ICF files that use DBCS These are double-byte character set (DBCS) considerations for describing the length and data type positions for ICF files.

Additional considerations for describing ICF files that contain DBCS dataConsider these factors when describing an ICF file that contains double-byte character set (DBCS) data.

Parent topic: DDS for ICF filesRelated informationGeneral considerations for using DBCS text with DDS files

Positional entry considerations for ICF files that use DBCSThese are double-byte character set (DBCS) considerations for describing the length and data type positions for ICF files.

Those positions not mentioned have no special considerations for DBCS.

Length (positions 30 through 34)

The length of a field containing bracketed-DBCS data can range from 4 through 32 767 bytes.

Keep the following considerations in mind when determining the length of a DBCS field:

Each DBCS character is 2 bytes long.

Include both shift-control characters in the length of the field. Together, these characters are 2 bytes long.

For example, a field that contains up to 3 DBCS characters, 1 shift-in character, and 1 shift-out character, has 8 bytes of data:

(3 characters x 2 bytes) + (shift-out + shift-in) = 8Data type (position 35)

The data type O (DBCS capable) makes a field DBCS.

Both bracketed-DBCS and alphanumeric data can be used in a DBCS-capable field. Use shift-control characters to distinguish DBCS data from alphanumeric data.Parent topic: DBCS considerations for ICF files

Additional considerations for describing ICF files that contain DBCS dataConsider these factors when describing an ICF file that contains double-byte character set (DBCS) data.

Use ICF files only to send data from the i5/OS® operating system to another system or to a remote workstation.

Send shift-control characters with DBCS data. The system is not aware of DBCS data in an ICF file, and treats DBCS data the same as alphanumeric data.

When using the reference function in an ICF file, if you refer to a field in a database file that has data type J, O, or E, DDS will assign data type O for the field in the ICF file.

DBCS-graphic fields cannot be referenced from a database file because fields with data type G are not allowed in an ICF file. If a field with a data type of G is referenced from a database file, an error message is issued.

Parent topic: DBCS considerations for ICF files

General considerations for using DBCS text with DDS filesBe aware of these general considerations for positional entries, keyword entries, double-byte character set (DBCS) text literals, and data description specifications (DDS) computer printouts that contain DBCS characters.

DBCS text can be encoded as either Unicode or Extended Binary Coded Decimal Interchange Code (EBCDIC). If you are working on a new application, enabling an existing application for DBCS text, or working on an application involving Java™, Open Database Connectivity (ODBC), Java Database Connectivity (JDBC), or other Web methods, then i5/OS® Unicode support provides the easiest way to support not only DBCS text but also other text types. If you are working on an existing application already supporting DBCS text stored as EBCDIC, then i5/OSEBCDIC support for DBCS text is useful.

DDS uses the following terms to describe the different types of DBCS data:

DBCS data

A general term to describe any form of EBCDIC-encoded DBCS data.

DBCS field

A general term to describe any field that can contain EBCDIC-encoded DBCS data.

Bracketed DBCS data

EBCDIC-encoded DBCS data that begins with a shift-out character and ends with a shift-in character.

DBCS graphic data

EBCDIC-encoded DBCS data that contains only DBCS data and does not contain shift-out and shift-in characters.

Unicode data

A general term to describe any form of Unicode-encoded DBCS data.

Unicode field

When the graphic data type is used with CCSID 1200 specified, then Unicode (UTF-16) is stored in the field instead of EBCDIC. When character data type is used with CCSID 1208 specified, then Unicode (UTF-8) is stored in the field instead of EBCDIC.

Positional entries for files that use DBCS data Positional entries are adapted so that you can define data fields that contain double-byte character set (DBCS) data. The entries are adapted for the length and data type positional entries.

Keyword entries for files that use DBCS (positions 45 through 80) When you work with double-byte character set (DBCS) data, you can specify DBCS-specific attributes with certain DDS keywords.

DBCS character strings You can use bracketed-DBCS character strings in DDS files for text-related keywords, such as TEXT and COLHDG, and both bracketed and DBCS-graphic character strings as parameters on the COMP, DFT, RANGE, and VALUES keywords.

DDS computer printouts with DBCS output DDS computer printouts are printed as DBCS output in these instances.

Parent topic: DDS conceptsRelated informationDBCS considerations for database filesDBCS considerations for display filesDBCS considerations for printer filesDBCS considerations for ICF files

REFFLD (Referenced Field) keyword for ICF filesYou can use this field-level keyword when referring to a field under one of these conditions.

The name of the referenced field is different from the name in positions 19 through 28.

The name of the referenced field is the same as the name in positions 19 through 28, but the record format, file, or library of the referenced field is different from that specified with the REF keyword.

The referenced field occurs in the same DDS source file as the referencing field.

The format of the keyword is:

REFFLD([record-format-name/]referenced-field-name [ {*SRC |

[library-name/]database-file-name}])

The referenced-field-name is required even if it is the same as the referencing field. Use the record-format-name when the referenced file contains more than one record format. Use *SRC (rather than the database-file-name) when the referenced-field-name is in the same DDS source file as the referencing field. *SRC is the default value when the database-file-name, the library-name, and the REF keyword are not specified.Note: When you refer to a field in the same DDS source file, the field you are referring to must precede the field you are defining.

Specify the database-file-name (qualified by its library-name if necessary) when you want to search a particular database file.

If, in the same DDS source file, you specify REF at the file level and REFFLD at the field level, the particular search sequence depends on both the REF and REFFLD keywords.

The letter R must be specified in position 29. In some cases, if you specify a value for length, some keywords specified with the field in the database file are not included in the ICF file.

You can specify a distributed data management (DDM) file on this keyword.

When using a DDM file, the database-file-name and the library-name are the DDM file and library name on the source system. The referenced-field-name and the record-format-name are the field name and the record format name in the remote file on the target system.

Note: Interactive data definition utility (IDDU) files cannot be used as reference files.

Option indicators are not valid for this keyword.Example

The following example shows how to specify the REFFLD keyword.

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8

00010A R FMAT1

00020A ITEM 5

00030A ITEM1 R REFFLD(ITEM)

00040A ITEM2 R REFFLD(FMAT1/ITEM)

00050A ITEM3 R REFFLD(ITEM FILEX)

00060A ITEM4 R REFFLD(ITEM LIBY/FILEX)

00070A ITEM5 R REFFLD(FMAT1/ITEM LIBY/FILEX)

00080A ITEM6 R REFFLD(ITEM *SCR)

A

Because the REF keyword is not specified, the default for lines 00030 and 00040 is to search the DDS source file in which they are specified. In line 00080, the parameter value *SRC explicitly specifies the source file.Parent topic: DDS keyword entries for ICF files (positions 45 through 80)Related referenceReference for ICF files (position 29)Related informationWhen to specify REF and REFFLD keywords for DDS files

Length for ICF files (positions 30 through 34)You must specify the field length for each field (unless you copy the field's attributes from a referenced field).

Specify the number of digits for a numeric field, or the number of characters for a character field. The length specification must be right-aligned; leading zeros are optional. Valid length specifications for ICF files are as follows:Data type Valid lengthCharacter 1 through 32 767Binary 1 through 9Zoned decimal 1 through 63Packed decimal 1 through 63Floating-point single precision 1 through 9Floating-point double precision 1 through 17

You can specify a maximum of 9 digits for single precision and 17 digits for double precision. However, the i5/OS® operating system supports a floating-point accuracy of 7 digits for single precision and 15 digits for double precision.

The sum of the number of bytes occupied by all fields in a record must not exceed 32 767 for ICF files. The system determines the number of bytes actually occupied as follows:

Data type Bytes occupied in storageCharacter Number of charactersBinary  1-4 digits 2 bytes5-9 digits 4 bytesZoned decimal Number of digitsPacked decimal (Number of digits/2) + 1 (truncated if

fractional)Floating-point (single precision) 4 bytesFloating-point (double precision) 8 bytes

If you are using a referenced field, you can override the length of the field by specifying a new value or by specifying the increase or decrease in length. To increase the length, specify +n where n is the increase. To decrease the length, specify -n, where n is the decrease. For example, an entry of +4 for a numeric field indicates that it is to be 4 digits longer than the referenced field.

Note: High-level languages can impose specific length and value restrictions on the field length. Observe these restrictions for files used by those languages.Parent topic: Defining an ICF file using DDS

Data type for ICF files (position 35)You can use this position to specify the data type of the field within the file.

The valid data type entries for ICF files are as follows:Entry Meaning

P Packed decimal

S Zoned decimal

B Binary

F Floating-point

A Character

Note: The data type O (DBCS-capable) supports DDS ICF files that use double-byte character set (DBCS).

If a data type is not specified for the field and is not duplicated from a referenced field, DDS assigns a default depending on the value in the decimal positions (positions 36 and 37). If the decimal positions are blank, a default of character (A) is assigned. If the decimal positions contain a number in the range 0 through 31, a default of zoned decimal (S) is assigned.

Note: Specifying F in position 35 results in a single precision floating-point field. Use the FLTPCN keyword to specify double precision or to change the precision of an already specified floating-point field.Parent topic: Defining an ICF file using DDS

Decimal positions for ICF files (positions 36 and 37)You can use these positions to specify the decimal placement within a packed decimal, a zoned decimal, a floating point, or a binary field.

Specify a decimal number from 0 through 31 to indicate the number of decimal positions to the right of the decimal point. (This number must not be greater than the number of digits specified in the field length.)

You can override or change these positions if you are using a referenced field. To override the positions, specify the new value. To change the positions, specify the amount by which you want the field increased or decreased and precede it with either a + or -. For example, an entry of +4 indicates there are to be four more digits to the right of the decimal point than were in the referenced field. If the resulting number of decimal positions is greater than the maximum allowed, you will receive an error message.

Note: High-level languages can impose specific length and value restrictions on the decimal positions. Observe these restrictions for files used by those languages.Parent topic: Defining an ICF file using DDS

Usage for ICF files (position 38)

The valid entries for this position are listed here.

Entry Meaning

B or blank Both input/output field

P Program-to-system field

A program-to-system field is used to communicate between an application program and the sending system (which is local to the application program). It is not sent as part of the data record across the line to the receiving system.

The following rules apply to program-to-system fields:

The field must be a named, numeric, or alphanumeric output-only field.

In the record format, the program-to-system fields must be defined after all the data fields (those with a use of B or blank).

A field cannot be defined as both a data field and a program-to-system field; the field names must be unique.

A program-to-system field can be named on an EVOKE, SECURITY, TIMER, or VARLEN keyword.

The only valid keywords for a program-to-system field are ALIAS, FLTPCN, REFFLD and TEXT.

Parent topic: Defining an ICF file using DDS

Location for ICF files (positions 39 through 44)These positions do not apply to ICF files. Leave these positions blank unless you use them for comment text.

Parent topic: Defining an ICF file using DDS

Example: Program that uses a physical file, display file, and printer fileThis example program shows the use of externally described data in a program.

If you enter the DDS for these files on your system and create them using the Create Physical File (CRTPF) command, the Create Display File (CRTDSPF) command, and the Create Printer File (CRTPRTF) command, this program allows you to add records to the physical file, display and update the records, and print a report.

The program is written in Report Program Generator (RPG). You can enter the RPG specifications shown in the example into a source file on your system and create the program using the Create RPG Program (CRTRPGPGM) command. For more information about RPG, see the RPG/400® Reference manual on the V5R1 Supplemental Manuals  Web site.

Figure 1. Example RPG program using a physical, display, and printer file

Legend:

1

These are the file description specifications (F-specs) for the example program. Positions 7 through 14 specify the file names. These file names should be the same file names used when you created the files from the DDS specifications earlier in this appendix.

2

The Es in position 19 indicate that these files are externally described (described in DDS specifications outside the program rather than inside the program).

3

These are the calculation specifications (C-specs).

4

The first section of the C-specs displays a prompt and retrieves a record from the database.

The TAG operation code indicates a label in the program. The EXFMT operation code writes the record PROMPT to the display, and then reads the record when the user presses the Enter key. The CHAIN operation code retrieves a record from CUSMST based on the key field ACTNUM. If no record with that key value is found, indicator 30 is turned on. The program continues to prompt until the key value of an existing record is entered in field ACTNUM (indicator 30 off) or until an A is entered in field ADD.

5

This section adds a new record or updates an existing record in the database file.

If a new customer is being added (indicator 30 is on), the WRITE operation code adds a new record to the physical file. Otherwise, the UPDAT operation code updates an existing record. The program continues to prompt for, retrieve, add, and update records in the physical file until F3 is pressed, setting on indicator 21.

6

This section prints the report.

A record is read from the physical file and the DETAIL record is written to the printer file until the end of the physical file is reached (indicator 45 is set on). The HEADER record is written on the first page and then written again on each new page (indicator 10 is on). When all the records have been written, the CLOSE operation code closes all the files and SETON LR ends the program.

Parent topic: Examples: DDS coding

Example: DDS compiler listingThis is an example of a data description specifications (DDS) compiler computer printout.

After data description specifications are written, they must be put into a source file. Then, database or device files are created by entering the CL command that starts the data description processor. You can enter the CL command interactively or in a batch job. The data description processor retrieves the data description specifications from the source file designated on the CL command that creates the file, validates the specifications, and creates a computer printout with any errors and any referenced specifications, as this example illustrates.

Compiler listing title (appears at top of each output page):

1

The program number, release modification level, and date of the i5/OS® operating system.

2

The qualified name.

3

The date and time of this run.

4

The page number in the computer printout.

Compiler listing prolog:

5

The type of file and the parameter values specified (or defaults if not specified) on the CL command that creates the file.

6

The name of the DDS processor.

Compiler listing source:

7

The sequence numbers of lines (records) in the source. Comments are treated like any other specification line and are given sequence numbers.

8

The source specifications.

9

If an error is found during processing of the DDS and can be traced specifically to a source specification, the error message identifier and an asterisk indicating where the error is are printed immediately following the source specification line. An asterisk is also printed under the sequence number to indicate that the line contains an error message.

Compiler listing expanded source:

10

Only the valid DDS. This list is what is actually in the file description. No comments or messages are printed. Default values and referenced values are printed for the valid DDS.

11

The length and the buffer (input or output) position of each field.

Compiler listing messages:

12

This section contains a list of all messages (general messages and those already indicated in the source section) encountered during processing of the DDS. For each message, the message identifier, the severity, the number of times the message occurred, and the message text are listed.

Compiler listing message summary:

13

The number of messages at each severity level.

14

The final completion message.

Parent topic: Examples: DDS coding

Related tasksCreating the DDS file

Creating the DDS fileYou can create a data description specifications (DDS) file by running a CL command that corresponds to the type of DDS file.

The file types and their corresponding commands are listed in the following table.File type Command

Physical file Create Physical File (CRTPF)

Logical file Create Logical File (CRTLF)

Display file Create Display File (CRTDSPF)

Printer file Create Printer File (CRTPRTF)

Intersystem communications function (ICF) file Create ICF File (CRTICFF)

When you issue a CL command to create a file, the DDS is retrieved from the source file and validated, and a file is created as shown in the following figure. The file is created only if there are no errors in the DDS of equal or greater severity than the severity specified on the GENLVL parameter of the CL command that creates the file. Thus, you can use the GENLVL parameter to control the allowable error severity when creating the file. Depending on the options you specify on the OPTION and FLAG parameters, a DDS source (or compiler) listing can also be created. The DDS listing contains the data description and error information.

You can use the FLAG parameter to specify the minimum severity of DDS messages which will be printed. For example, you can suppress the warning messages for field overlapping.

The following figure shows a source file that can be processed in batch or interactively to create a file on diskette.

Parent topic: Creating a file using DDSRelated conceptsExample: DDS compiler listingDDS debugging templateRelated tasksCompleting the DDS formEntering the DDS source statements

Creating the DDS fileYou can create a data description specifications (DDS) file by running a CL command that corresponds to the type of DDS file.

The file types and their corresponding commands are listed in the following table.File type Command

Physical file Create Physical File (CRTPF)

Logical file Create Logical File (CRTLF)

Display file Create Display File (CRTDSPF)

Printer file Create Printer File (CRTPRTF)

Intersystem communications function (ICF) file Create ICF File (CRTICFF)

When you issue a CL command to create a file, the DDS is retrieved from the source file and validated, and a file is created as shown in the following figure. The file is created only if there are no errors in the DDS of equal or greater severity than the severity specified on the GENLVL parameter of the CL command that creates the file. Thus, you can use the GENLVL parameter to control the allowable error severity when creating the file. Depending on the options you specify on the OPTION and FLAG parameters, a DDS source (or compiler) listing can also be created. The DDS listing contains the data description and error information.

You can use the FLAG parameter to specify the minimum severity of DDS messages which will be printed. For example, you can suppress the warning messages for field overlapping.

The following figure shows a source file that can be processed in batch or interactively to create a file on diskette.

Parent topic: Creating a file using DDSRelated conceptsExample: DDS compiler listingDDS debugging templateRelated tasksCompleting the DDS formEntering the DDS source statements

DDS debugging template

A special template is available to help you in interpreting the fields on the data description specifications (DDS) compiler computer printout.

The following figure shows a reduced debugging template.

Figure 1. IBM® data description specifications debugging template (Reduced)

Parent topic: Examples: DDS codingRelated tasksCreating the DDS file

Creating a file using DDSYou can use data description specifications (DDS) to create a file.

To create a file using DDS, follow these steps:

1. Complete the DDS form.

2. Type the source statements into a source file. The source file can be part of the i5/OS®database (in a source physical file such as the IBM-supplied QDDSSRC in library QGPL) or it can be on diskettes.

3. Create the file using the appropriate control language (CL) command.

Note: Using the screen design aid (SDA) utility, you can create and test display files without coding DDS directly, using only the functions that apply to display files. See the ADTS for AS/400®: Screen Design Aid manual on the V5R1 Supplemental Manuals

 Web site.

Completing the DDS form You can use the data description specifications (DDS) form to enter positional and keyword information in the designated columns.

Entering the DDS source statements After filling out the forms, enter the source statements into source files.

Creating the DDS file You can create a data description specifications (DDS) file by running a CL command that corresponds to the type of DDS file.

Parent topic: DDS concepts

Completing the DDS formYou can use the data description specifications (DDS) form to enter positional and keyword information in the designated columns.

A sample DDS form is printed in reduced size in Figure 1.

The left side of the DDS form (positions 1 through 44) is for fixed-format entries calledpositional entries. Positional entries define the most common attributes of record formats and fields, such as names and lengths of fields. For a brief description of the most important positional entries, see items 1 through 7 following the figure. For more detailed information about positional entries for each of the file types, see the following topics:

Positional entries for physical and logical files

Positional entries for display files

Positional entries for printer files

Positional entries for ICF files

The right side of the DDS form (positions 45 through 80) is for DDS keywords. DDS keywords define less-common and more-varied attributes of files, record formats, and fields; they follow a subset of the syntax rules for control language. For a brief description of keyword entries, see item 8 following the figure. For more detailed information about keyword entries for each of the file types, see the following topics:

Keywords for physical and logical files

Keywords for display files

Keywords for printer files

Keywords for ICF files

Figure 1. Overview of the positional entries and keywords

1

Sequence Number and Form Type are optional in DDS. The form type identifies the source as DDS source. The entries are valid for all types of files.

2

An asterisk in position 7 makes the entire line a comment. This is valid for all types of files. When A (And), or O (Or), or a blank is in position 7, positions 8 through 16 can provide conditioning for the DDS on or immediately following the current line. Conditioning is not valid in physical or logical files.

3

Type of Name or Specification (position 17) identifies the Name entry (positions 19 through 28) or the specification:Name entry Description Type of fileR Specifies a record format name Allblank Specifies a field name AllK Specifies a key field name Physical and logical onlyS Specifies a select field name Logical onlyO Specifies an omit field name Logical only

Name entry Description Type of fileJ Specifies this as a join specification Join logical onlyH Specifies this as a help specification Display only

4

R specified in position 29 indicates that the attributes of the field in Name (positions 19 through 28) refer to a field specified elsewhere. This is ignored for logical files.

5

Length, Data Type, and Decimal Positions specify attributes of named fields within record formats. These are valid for all types of files.

6

Usage specifies fields as input, output, output/input, neither input nor output, hidden, message, or program-to-system fields. Each type of file has its own restrictions regarding field use.

7

Location specifies the location of the field on the display or printed page. This applies for display and printer files only.

8

Functions specified through the use of keywords apply at different levels for different file types, as follows:

Keywords apply at this level

For these files

File All types of filesRecord All types of filesField All types of filesJoin Join logical files onlyKey field Physical and logical filesSelect or omit field Logical files onlyHelp Display files only

For display and printer files, constants specified within single quotation marks become the default values for displayed or printed fields.Parent topic: Creating a file using DDSRelated tasksEntering the DDS source statementsCreating the DDS file

Entering the DDS source statementsAfter filling out the forms, enter the source statements into source files.

You can enter the source either interactively or in batch.

Entering source statements interactively with SEU

Use the source entry utility (SEU) of the WebSphere® Development Studio. See the ADTS for AS/400®: Source Entry Utility manual on the V5R1 Supplemental Manuals

 Web site. Type in the Start SEU (STRSEU) command to call SEU.

Entering source statements in batch using diskettes

Use one of the following methods:

Enter an input stream containing DDS source and control language (CL) commands on diskette and start a spooling reader using the Start Diskette Reader (STRDKTRDR) command.

Enter only source statements on diskette and copy the resulting data file into a source physical file with the Copy File (CPYF) command.

Enter only source statements on diskette and type a CL command to create the file. Specify the name of the data file on the SRCFILE parameter and *FILE on the SRCMBR parameter of the command.

Note: This method does not create a source physical file.Parent topic: Creating a file using DDSRelated tasksCompleting the DDS formCreating the DDS file

Related information for DDS conceptsListed here are the product manuals (in PDF format) and information center topics that relate to the DDS concept topic. You can view or print any of the PDFs.

Manuals

Backup and Recovery  describes how to make copies of the system and database files for safe keeping.

Advanced Function Printing: Data Stream Reference, S544-3202, provides information about the Advanced Function Printing™ data stream.

See the ADTS for AS/400®: Screen Design Aid manual on the V5R1 Supplemental Manuals  Web site. It provides the application programmer, system programmer, or data processing manager with information about using the WebSphere® Development Studioscreen design aid (SDA) to design, create, and maintain display formats and menus.

See the ADTS for AS/400: Source Entry Utility manual on the V5R1 Supplemental Manuals  Web site. It provides the application programmer or system programmer with information about using the WebSphere Development Studio source entry utility (SEU) to create and edit source members.

Application Display Programming  describes the use of display devices by application programs.

IBM® Personal Computer Enhanced 5250 Emulation Program Version 2.12 Technical Reference, GS57-0222-02, provides the information about the 5250 Emulation Program.

Intelligent Printer Data Stream Reference, S544-3417, provides information about bar codes and valid check digits.

See the RPG/400® Reference manual on the V5R1 Supplemental Manuals  Web site. It describes how to design, code, enter, compile, test, and run RPG III programs.

Other information

Control language  describes control language syntax, commands, and command parameters.

CL programming  provides a wide-range discussion of programming topics.

Work management  provides information about how to create and change a work management environment.

Basic system operations  describes how to operate workstations and how to use the function keys to enter commands.

Experience RPG IV Tutorial is an interactive self-study program that explains the differences between RPG III and RPG IV and how to work within the new ILE environment. An accompanying workbook provides additional exercises and can be used as a reference on completion of the tutorial. RPG code examples are provided with the tutorial and can run directly on the i5/OS® operating system. Dial 1-800-IBM-CALL to order the tutorial.

Saving PDF filesTo save a PDF on your workstation for viewing or printing:

1. Right-click the PDF in your browser (right-click the link above).

2. Click the option that saves the PDF locally.

3. Navigate to the directory in which you want to save the PDF.

4. Click Save.Downloading Adobe Reader

You need Adobe Reader installed on your system to view or print these PDFs. You can download a free copy from the Adobe Web site(www.adobe.com/products/acrobat/readstep.html) .Parent topic: DDS concepts