30.06.2013 Views

File Management - IBM

File Management - IBM

File Management - IBM

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

|<br />

118 <strong>File</strong> <strong>Management</strong> V4R5<br />

v INCREL that specifies a UCS-2 graphic field name<br />

For more information on copying DBCS or UCS-2 fields, see “Copying DBCS files”<br />

on page 209.<br />

Converting System/370 floating point and null fields<br />

To copy floating point fields and null fields that are in a System/370 format to an<br />

AS/400 format, use FMTOPT(*CVTFLOAT) and FMTOPT(*NULLFLAGS)<br />

respectively. You can use these two values together in one command:<br />

FMTOPT(*CVTFLOAT *NULLFLAGS).<br />

The FMTOPT(*CVTFLOAT) parameter on the CPYF command converts each<br />

floating point field from System/370 hexadecimal format to the IEEE format that is<br />

used by the AS/400. The CPYF command converts those fields that are identified<br />

by the external description of the physical to-file.<br />

The FMTOPT(*NULLFLAGS) parameter on the CPYF command takes the byte (or<br />

flag) following each null-capable field and uses it to indicate if the corresponding<br />

input field is null. The CPYF command takes the fields that are identified as<br />

null-capable by the external description of the physical to-file. If the byte (or flag)<br />

is blank (X'40') or contains X'00', the data is considered not null. Any other value<br />

for the flag causes the corresponding input field data to be ignored and the output<br />

value set to null.<br />

If you use *CVTFLOAT or *NULLFLAGS and the input file is externally described,<br />

the input file’s external description is not used in mapping the copied data.<br />

When you use *CVTFLOAT and *NULLFLAGS (together or independently), make<br />

certain that the to-file is an existing database, externally-described, physical data<br />

file.<br />

You cannot specify the *CVTFLOAT and *NULLFLAGS values when any of the<br />

following conditions are true:<br />

v You have specified RCDFMT(*ALL) for a multiple-format logical from-file<br />

v You have specified any value other than the default for CRTFILE, and the to-file<br />

does not exist<br />

v You have specified a value other than the default for the FROMKEY, TOKEY,<br />

INCCHAR, INCREL, SRCOPT, or SRCSEQ parameters.<br />

When you specify either *CVTFLOAT or *NULLFLAGS, all other values for the<br />

FMTOPT parameter are ignored. If you use both *CVTFLOAT and *NULLFLAGS<br />

on one CPYF command, both values are recognized.<br />

When you specify the *CVTFLOAT value (and have not specified *NULLFLAGS),<br />

the expected from-file record length is the to-file record length. When you have<br />

specified the *NULLFLAGS value, the expected from-file record length is equal to<br />

the sum of the to-file record length and the number of null-capable fields in the<br />

to-file. The from-file’s record length may not be less than the expected length. If<br />

the from-file’s record length is greater than the expected length, an inquiry<br />

message is sent to the QSYSOPR message queue to determine if the user wants to<br />

continue. If the user continues, the trailing data (fields) in the from-file is truncated<br />

in the to-file.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!