File Management - IBM
File Management - IBM File Management - IBM
When you specify PRINT(*EXCLD), the records print in the from-file format. All character data is in the CCSID specified in the from-file field. For TOFILE(*PRINT) and PRINT(*COPIED) listings, and when the to-file is a print file, character data is in the CCSID specified in the to-file fields. Example: In this example, all records that are not copied (or excluded records) are printed: CPYF FROMFILE(DKTIN) TOFILE(LIB1/PF) + MBROPT(*ADD) INCCHAR(*RCD 80 *EQ X) + PRINT(*EXCLD) The records print in character format. Creating an unformatted print listing If you want an unformatted print listing or if the from-file records should be formatted using first-character forms control (CTLCHAR(*FCFC), you must specify a program-described printer device file name. This file name can be QSYSPRT or user-defined (instead of *PRINT). To format the from-file records using first-character forms control, specify CTLCHAR(*FCFC) on the Create Printer File (CRTPRTF), Change Printer File (CHGPRTF), or Override Printer File (OVRPRTF) command. For copy commands where TOFILE(*PRINT) is specified with a PRINT parameter value of *COPIED, *EXCLD, or *ERROR (or any combination), the following limits apply: v The QSYSPRT file must be spooled [SPOOL(*YES)] v You must specify the QSYSPRT in the device file or on the OVRPRTF command, because separate print files open for each file requested. All records are copied to a single spooled file, and the data for each member or label identifier copied begins on a new print page. Copying between different database record formats (FMTOPT parameter) 106 File Management V4R5 (CPYF and CPYFRMQRYF commands) When you copy from a database file to a database file, you must use the FMTOPT parameter if the record formats are not identical or if the files are different types (source or data). If either file is a device file or inline data file, the FMTOPT parameter does not apply. The records are truncated or padded with blanks or zeros when record lengths are different. A message is sent if the records are truncated. For database files, when either FMTOPT(*CVTSRC) or FMTOPT(*NOCHK) is specified and the record data copied from any from-file record is not long enough to fill a to-file record, the extra bytes in the to-file record are set to a default value. If a default value other than *NULL is specified in the DDS (DFT keyword) for a field, that field is initialized to the specified default; otherwise, all numeric fields are initialized to zeros, all character fields are initialized to blanks, all date, time,
and timestamp fields are initialized to the current system date and time. If *NULL is specified on the DFT keyword, only the default buffer value is used. A *NULL default is ignored. If the from-file or to-file is a device file or an inline data file, copy automatically adds or deletes the source sequence number and date fields for each record copied. If one file is a data file and the other a source file, you must specify FMTOPT(*CVTSRC) to perform the copy. The sequence number and date fields are added or deleted as appropriate and the data part of each record is copied without regard to the other field definitions in the file record formats. The SRCSEQ parameter can be used to control how the sequence numbers are created, provided SRCOPT(*SEQNBR) is also specified. For database-to-database copies, you can reconcile any differences in record formats by specifying: v *DROP to drop those fields in the from-file record format for which there are no fields of the same name in the to-file record format. v *MAP to convert fields in the from-file to the attributes of like-named fields in the to-file and to fill extra fields in the to-file, that are not in the from-file, with their default values. The default values are: – The parameter value (including *NULL) for the DFT keyword, if specified for the field – Blanks (for character fields without the DFT keyword) – Zeros (for numeric fields without the DFT keyword) – Current date, time, or timestamp for those type fields without the DFT keyword *MAP is required if fields with the same name are in different positions in the file record formats, even though these fields have the same attributes. v *DROP and *MAP to drop fields in the from-file not named in the to-file and to convert remaining fields through mapping rules to fit the to-file fields that have different attributes or positions. v *NOCHK to disregard the differences. Data is copied left to right directly from one file to the other. Null values are ignored. The copied records are either truncated or padded with default buffer values. Because no checking is done, fields in the to-file may contain data that is not valid for the field as defined. Dropping and mapping fields are based on a comparison of field names. Unless all the fields in the from-file have the same name in the to-file, you must specify *DROP. If the names are the same, but the attributes or position in the record is different, you must specify *MAP. Dropped fields are not copied. There must be at least one like-named field in both record formats to do mapping. When *MAP is specified, fields in the to-file record format that do not exist in the from-file record format are filled with their default values, as described earlier in this section. For fields that have the same name and attributes, the field in the from-file record format is mapped to the field with the same name in the to-file record format, even if their positions in the formats are different. For example, the field CUSNO is the first field in the record format ORDHD, but it is the second field in record format ORDHD1. When the CUSNO field is copied with *MAP, it is mapped to the second field of ORDHD1. Chapter 4. Copying files 107
- Page 66 and 67: Program A (in user default activati
- Page 68 and 69: 58 File Management V4R5 Displaying
- Page 70 and 71: 60 File Management V4R5 Command 7 d
- Page 72 and 73: 62 File Management V4R5 Display All
- Page 74 and 75: Redirecting files 64 File Managemen
- Page 76 and 77: 66 File Management V4R5 Default act
- Page 78 and 79: 68 File Management V4R5 From Databa
- Page 80 and 81: Copying files: overview 70 File Man
- Page 82 and 83: 72 File Management V4R5 Table 9. Co
- Page 84 and 85: Table 10. Summary of Copy Functions
- Page 86 and 87: 76 File Management V4R5 Copying fil
- Page 88 and 89: Resending copy file completion mess
- Page 90 and 91: 80 File Management V4R5 from-file m
- Page 92 and 93: CPYSRCF command support for CCSIDs
- Page 94 and 95: | | | | | | | | | | | | | | | | | |
- Page 96 and 97: | | | | | | | | | | | | | | | | 86
- Page 98 and 99: | | | | | | | | | | | | | | | | | |
- Page 100 and 101: 90 File Management V4R5 Copying onl
- Page 102 and 103: Selecting the records to copy 92 Fi
- Page 104 and 105: 94 File Management V4R5 Selecting r
- Page 106 and 107: 96 File Management V4R5 Example: bu
- Page 108 and 109: 98 File Management V4R5 When you sp
- Page 110 and 111: 100 File Management V4R5 A field na
- Page 112 and 113: 102 File Management V4R5 v “Null-
- Page 114 and 115: 104 File Management V4R5 - INCCHAR(
- Page 118 and 119: Note: It is possible for files with
- Page 120 and 121: 110 File Management V4R5 Variable-L
- Page 122 and 123: Table 14 on page 112 outlines the c
- Page 124 and 125: 114 File Management V4R5 in the cur
- Page 126 and 127: 116 File Management V4R5 (including
- Page 128 and 129: | | | | | | | | | | | | | | | | | |
- Page 130 and 131: | | | | | | | | | | | | | | | | | |
- Page 132 and 133: Preventing errors when copying file
- Page 134 and 135: elationship. However, the copy oper
- Page 136 and 137: Preventing allocation errors when c
- Page 138 and 139: 128 File Management V4R5 - A depend
- Page 140 and 141: Year 2000 support: date, time, and
- Page 142 and 143: FLD TYPE DATFMT SPECIFIED FIELD LEN
- Page 144 and 145: Restrictions for Year 2000 support
- Page 146 and 147: | | | | | | | | | | AS/400 supports
- Page 148 and 149: | | | | | | | | | | | | | | | | | |
- Page 150 and 151: Using the Copy From Import File (CP
- Page 152 and 153: externally described database file
- Page 154 and 155: 144 File Management V4R5 v Two adja
- Page 156 and 157: - Description: This Field Definitio
- Page 158 and 159: Date Fields All date formats suppor
- Page 160 and 161: 150 File Management V4R5 Figure 14
- Page 162 and 163: devices that process the same type
- Page 164 and 165: Default system output queues 154 Fi
and timestamp fields are initialized to the current system date and time. If *NULL<br />
is specified on the DFT keyword, only the default buffer value is used. A *NULL<br />
default is ignored.<br />
If the from-file or to-file is a device file or an inline data file, copy automatically<br />
adds or deletes the source sequence number and date fields for each record copied.<br />
If one file is a data file and the other a source file, you must specify<br />
FMTOPT(*CVTSRC) to perform the copy. The sequence number and date fields are<br />
added or deleted as appropriate and the data part of each record is copied without<br />
regard to the other field definitions in the file record formats. The SRCSEQ<br />
parameter can be used to control how the sequence numbers are created, provided<br />
SRCOPT(*SEQNBR) is also specified.<br />
For database-to-database copies, you can reconcile any differences in record<br />
formats by specifying:<br />
v *DROP to drop those fields in the from-file record format for which there are no<br />
fields of the same name in the to-file record format.<br />
v *MAP to convert fields in the from-file to the attributes of like-named fields in<br />
the to-file and to fill extra fields in the to-file, that are not in the from-file, with<br />
their default values. The default values are:<br />
– The parameter value (including *NULL) for the DFT keyword, if specified for<br />
the field<br />
– Blanks (for character fields without the DFT keyword)<br />
– Zeros (for numeric fields without the DFT keyword)<br />
– Current date, time, or timestamp for those type fields without the DFT<br />
keyword<br />
*MAP is required if fields with the same name are in different positions in the file<br />
record formats, even though these fields have the same attributes.<br />
v *DROP and *MAP to drop fields in the from-file not named in the to-file and to<br />
convert remaining fields through mapping rules to fit the to-file fields that have<br />
different attributes or positions.<br />
v *NOCHK to disregard the differences. Data is copied left to right directly from<br />
one file to the other. Null values are ignored. The copied records are either<br />
truncated or padded with default buffer values. Because no checking is done,<br />
fields in the to-file may contain data that is not valid for the field as defined.<br />
Dropping and mapping fields are based on a comparison of field names. Unless all<br />
the fields in the from-file have the same name in the to-file, you must specify<br />
*DROP. If the names are the same, but the attributes or position in the record is<br />
different, you must specify *MAP. Dropped fields are not copied. There must be at<br />
least one like-named field in both record formats to do mapping.<br />
When *MAP is specified, fields in the to-file record format that do not exist in the<br />
from-file record format are filled with their default values, as described earlier in<br />
this section. For fields that have the same name and attributes, the field in the<br />
from-file record format is mapped to the field with the same name in the to-file<br />
record format, even if their positions in the formats are different.<br />
For example, the field CUSNO is the first field in the record format ORDHD, but it<br />
is the second field in record format ORDHD1. When the CUSNO field is copied<br />
with *MAP, it is mapped to the second field of ORDHD1.<br />
Chapter 4. Copying files 107