You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
206 <strong>File</strong> <strong>Management</strong> V4R5<br />
– Create Display <strong>File</strong> (CRTDSPF)<br />
– Create Printer <strong>File</strong> (CRTPRTF)<br />
– Create Tape <strong>File</strong> (CRTTAPF)<br />
v By specifying IGCDTA(*YES) on the following database file creation commands:<br />
– Create Physical <strong>File</strong> (CRTPF)<br />
– Create Source Physical <strong>File</strong> (CRTSRCPF)<br />
Improperly indicated DBCS files<br />
If you do not properly indicate that a file is a DBCS file, one of the following<br />
happens:<br />
v For printer files, printer data management assumes the output data to the<br />
printer does not contain double-byte data. The end result depends on the type of<br />
printer the data is printed on and the status of the replace unprintable character<br />
parameter for the printer file you are using.<br />
If the replace-unprintable-character option is selected, printer data management<br />
interprets shift-control characters as unprintable characters and replaces them<br />
with blanks. The double-byte data itself is interpreted as alphanumeric data, and<br />
the printer attempts to print it as such. The printed double-byte data does not<br />
make sense.<br />
If the replace-unprintable-character option is not selected and the printer is an<br />
alphanumeric printer, the double-byte data, including the control characters, is<br />
sent as is to the printer. On most alphanumeric printers, the shift-control<br />
characters are not supported, and an error will occur at the printer.<br />
If the replace-unprintable-character option is not selected and the printer is a<br />
DBCS printer, the double-byte data is printed with the exception of extended<br />
characters. Because the file was not indicated as a DBCS file, the system will not<br />
perform extended character processing. The extended characters are printed with<br />
the symbol for undefined double-byte characters.<br />
v For display files, display data management assumes that the output data to the<br />
display does not contain double-byte data. The end result depends on whether<br />
the display is an alphanumeric or DBCS display.<br />
If the display is an alphanumeric display, the double-byte data is interpreted as<br />
alphanumeric data. The shift-control characters appear as anks. The displayed<br />
double-byte data does not make sense.<br />
If the display is a DBCS display, the double-byte data is displayed with the<br />
exception of extended characters. The system does not perform extended<br />
character processing on the data. Therefore, extended characters are displayed<br />
with the symbol for undefined double-byte characters.<br />
v The system does not recognize literals with DBCS text as double-byte literals if<br />
the source file is not specified as a DBCS file.<br />
Making printer files capable of DBCS<br />
In many cases, printer files are used by the system to produce data that will<br />
eventually be printed or displayed. In these cases, the data is first placed into a<br />
spooled file using one of the <strong>IBM</strong>-supplied printer files. The data is then taken<br />
from the spooled file and is displayed or printed based on the request of the user.<br />
When the data involved contains double-byte characters, the printer file that is<br />
used to place the data into the spooled file must be capable of processing<br />
double-byte data. A printer file is capable of processing double-byte data when<br />
*YES is specified on the IGCDTA parameter for the file. In most cases, the system
Change language