IBM Support

CPYFRMIMPF and CPYTOIMPF Data Areas

Troubleshooting


Problem

This document describes the different data areas that can be used for CPYFRMIMPF and CPYTOIMPF.
Using ADDENVVAR ENVVAR(QIBM_CP_DEBUG) before running the CPYTOIMPF or CPYFRMIMPF will include messages if any of these *DTAARAs are being used.

Cause

CPYTOIMPF and CPYFRMIMPF have some options that change the functionality.
Use this SQL query to determine which are set on your IBM i.
IBM i 7.4 or later
select DATA_AREA_LIBRARY,
       DATA_AREA_NAME,
       DATA_AREA_VALUE
  from QSYS2.DATA_AREA_INFO
 where DATA_AREA_TYPE = '*CHAR'
   and DATA_AREA_LIBRARY = 'QSYS'
   and DATA_AREA_NAME in ('QCPFRMIMPF', 'QCPTOIMPF', 'QCPENFSCSD', 
                          'QCPNONEEOF', 'QCPEFSINGL', 'QCPZEROLEN', 
                          'QCPCPYTSMP', 'QCPZEROSTG', 'QCPNOBLANK', 
                          'QCPUSEPATH', 'CPTOFLDDLM', 'QCPTOIMPF2')
;
  
Another option: WRKOBJPDM LIB(QSYS) OBJ('*CP*') OBJTYPE(*DTAARA)

Resolving The Problem

This document describes the different data areas that can be used for CPYFRMIMPF and CPYTOIMPF.

1. Data areas to force the V5R2 code paths

These two data areas force the CPYFRMIMPF/CPYTOIMPF to use the V5R2 code paths. For V5R3, the code for the commands had a major design change to increase functionality and performance. However, some customers needed the exact same support for the commands as the V5R2 code paths, so the data areas were added. However, eventually, customers need to completely get away from using the 'CPV5R2' data areas because they are only temporarily allowed and may be removed at a release boundary in the future. Note: No PTFs are needed for this support because this support was added to the base operating system.

CPYFRMIMPF:
CRTDTAARA DTAARA(QSYS/QCPFRMIMPF) TYPE(*CHAR) LEN(6) VALUE('CPV5R2')

CPYTOIMPF:
CRTDTAARA DTAARA(QSYS/QCPTOIMPF) TYPE(*CHAR) LEN(6) VALUE('CPV5R2')

CRTDTAARA DTAARA(QSYS/QCPTOIMPF2) TYPE(*CHAR) LEN(8) VALUE('CPV5R2_P')

Explanation:
This additional data area is applied if the QSYS/QCPTOIMPF is created and causes the V5R2 data area to use views for the copy so all fields can be copied. This omits the SQL length restriction which caused a problem for the QCPTOIMPF data area.


2. Other data areas

 
  • CPYFRMIMPF Data Areas

    1. CRTDTAARA DTAARA(QSYS/QCPENFSCSD) TYPE(*CHAR) LEN(3) VALUE('YES')

    Explanation:
    This data area will not check for characters within string delimiter(dlm) and shifts. For example, string dlm ---shift out----string dlm --shift in string dlm will be allowed with the data area. Without the data area, this would fail because we expect string dlm ---shift out----string dlm --shift in string dlm to see the second string dlm as the ending string dlm.
    2. CRTDTAARA DTAARA(QSYS/QCPNONEEOF) TYPE(*CHAR) LEN(3) VALUE('YES')

    Explanation:
    This data area will not check for the End of File character within an IFS file which is a X'1C' character.
    3. CRTDTAARA DTAARA(QSYS/QCPEFSINGL) TYPE(*CHAR) LEN(3) VALUE('YES')

    Explanation:
    This data area is used only when copying from the TURKISH CCSID 1026.
    The shift characters can cause problems.
 
  • - CPYTOIMPF Data Areas

    1. CRTDTAARA DTAARA(QSYS/CPTOFLDDLM) TYPE(*CHAR) LEN(6) VALUE('FLDDLM')

    Explanation:
    The customer was able to process in V5R4 using FLDDLM('') or FLDDLM(' ') when exporting to *PCASCII; however, due to incorrect blank conversion, an error message was generated in V6R1 and V7R1. For the FLDDLM parameter, we will not assign the converted field delimiter for FLDDLM('') or FLDDLM(' ') for the *PCASCII code page in the to-file. This data area will support the existing V5R4 results, means the behavior changed after V5R4 and this will enable the original behavior.
    2.
    CRTDTAARA DTAARA(QSYS/QCPZEROLEN) TYPE(*CHAR) LEN(3) VALUE('YES')
    Explanation:
    Forces fields that are defined as VARLEN 0 to export ' ' instead ''.
    3. CRTDTAARA DTAARA(QSYS/QCPCPYTSMP) TYPE(*CHAR) LEN(2) VALUE('NO')

    Explanation:
    Ignores SMP support so the exported records are exported in the same order and the records were inserted.
    4. CRTDTAARA DTAARA(QSYS/QCPZEROSTG) TYPE(*CHAR) LEN(3) VALUE('YES')

    Explanation:
    For character fields that contain the '00'X value, it will export '' instead of the '00'X.
    5.
    CRTDTAARA DTAARA(QSYS/QCPNOBLANK) TYPE(*CHAR) LEN(3) VALUE('YES')

    Explanation:
    If the RMVBLANK() parameter was to remove all the blanks, the export would return a single blank so the exported field would not be a NULL field. This option will allow the parameter to remove all blanks for the RMVBLK parameter.

    Note: Copy To Import File (CPYTOIMPF) command change with V7R1M0 PTF SI53148 (Technology Refresh 8)

    Prior to TR8, when using data areas for the CPYTOIMPF command, the data areas must be in the QSYS library.

    A change has been requested to check for the data area QCPNOBLANK in library QTEMP first and if the data area is in library QTEMP, then use the value for the CPYTOIMPF command from the data area in library QTEMP.
    If the data area is not in library QTEMP, then check for the data area in library QSYS and use the library QSYS value from the data area. For example:

    CRTDTAARA DTAARA(QTEMP/QCPNOBLANK) TYPE(*CHAR) LEN(3) VALUE('YES') and
    CRTDTAARA DTAARA(QSYS/QCPNOBLANK) TYPE(*CHAR) LEN(3) VALUE('NO ')
    would honor the QCPNOBLANK data area.

    CRTDTAARA DTAARA(QTEMP/QCPNOBLANK) TYPE(*CHAR) LEN(3) VALUE('NO ') and
    CRTDTAARA DTAARA(QSYS/QCPNOBLANK) TYPE(*CHAR) LEN(3) VALUE('YES')
    would NOT honor the QCPNOBLANK data area.
    6. CRTDTAARA DTAARA(QSYS/QCPUSEPATH) TYPE(*CHAR) LEN(3) VALUE('YES')

    Explanation:
    This will force the CPYTOIMPF to support the function as if the TOSTMF was an stream file and not a database file.

Related Information

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"Component":"Db2 for i","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"All Versions","Edition":"","Line of Business":{"code":"LOB57","label":"Power"}}]

Historical Number

N1011149

Document Information

Modified date:
07 February 2024

UID

nas8N1011149