IBM Support

JR34897: UNICODE CHANGES IN DSCAPIOP LEAD TO PARALLEL STAGES CALLING THIS OPERATOR TO RETURN UNDESIRED RESULTS.

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Unicode changes in DSCAPIOP lead to parallel stages calling this
    operator to return undesired results.
    
    An example of this can be seen when using the Teradata M Load
    stage in a parallel job.  Timestamps of the format
    "YYYY-MM-DD hh:mm:ss" (length 19) are exported incorrectly as
    "YYYY-MM-DD hh:mm:ss." (length 20).
    This causes the load to fail with the following error:
    
    
    TM_BPAcctDtls,0: Fatal Error: Fatal: MultiLoad returned: 12 **
    Please refer to statements in /path/to/filename.rpt
    to resolve the issue **
    
    This file has the following entry
    
    UTY4016 Data item too large for field SOME_DATE_COL in vartext
    record number 1.
    
    
    Example data:
    aaaaa|1960-01-01 00:00:00.|0
    bbbbb|1960-01-01 00:00:01.|1
    ccccc|1960-01-01 00:00:02.|2
    ddddd|1960-01-01 00:00:03.|3
    
    
    However, this does not occur when used in a server job
    aaaaa|1990-12-12 12:12:12|0
    bbbbb|1990-12-12 12:12:12|1
    ccccc|1990-12-12 12:12:12|2
    ddddd|1990-12-12 12:12:12|3
    

Local fix

  • Work-arounds involve changing the job design and ALTERing the
    DDL of the table where the data is being loaded.
    
    1) Change job design to increase the length of the timestamp
    2) Changing the DDL to reflect the metadata change.
    
    In the example given, change the format in M-Load stage from
    VARTEXT to FAST LOAD
    

Problem summary

  • When using MLoad Stage in a parallel job, timestamps (19) have
    an extra character at the end (".") which causes the load to
    fail.
    

Problem conclusion

  • It has been found that the issue is already fixed as part of the
    Ecase 130080 in the DSCAPIOP layer, for IS 8.0.1. We have
    back-propagated the fix to DS 7.5.3, verified the same in
    "sandbox" environment & found that the issue is resolved.
    

Temporary fix

Comments

APAR Information

  • APAR number

    JR34897

  • Reported component name

    WIS DATASTAGE

  • Reported component ID

    5724Q36DS

  • Reported release

    753

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2009-11-25

  • Closed date

    2012-05-24

  • Last modified date

    2012-05-24

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Modules/Macros

  • SERVEr
    

Fix information

  • Fixed component name

    WIS DATASTAGE

  • Fixed component ID

    5724Q36DS

Applicable component levels

  • R753 PSY

       UP

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSVSEF","label":"IBM InfoSphere DataStage"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.5.3","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
24 May 2012