A fix is available
APAR status
Closed as program error.
Error description
Design Change Proposal (CC_SE_TIMESTAMP_FF) . The Server Bridge Team will introduce a new environment variable to control the TIMESTAMP behavior. The environment variable will be called something like CC_SE_TIMESTAMP_FF. The environment variable will accommodate the migration as well as the new users using the Connectors on the Server canvas. This fix will not be selective to the Oracle connector. After the code changes the behavior would be like this. 1. When the environment variable is not added, the jobs would behave the same way as they are behaving today. 2. When the environment variable is added and its value is set to MICROSECONDS, it would be same behavior as (1). 3. When the environment variable is added with a value of SCALE, then it is expected that the scale is mentioned in the timestamp fields in the schema and whatever scale is mentioned the microsecond resolution for each of the fields, that value would be used and the microsecond resolution would be set accordingly. If the Scale column attribute is not set, the value 0 will be assumed. 4. When the environment variable is added and its value is set to NONE, then the behavior would be same as DS_NO_FF (or SCALE with the scale in the timestamp fields being set to 0). If we wanted to 100% mimic the behavior of the OCI plug-in, then specifying NONE should omit everything after the seconds part (e.g. "2012-02-21 08:56:20"), but specifying SCALE with the Scale column attribute unset (i.e. set to 0) would leave the period after seconds (e.g. "2012-02-21 08:56:20."). Case (2), (3) and (4) are to accommodate the various possible migration scenarios to the best of our ability. .
Local fix
n/a
Problem summary
Problem: An issue with SEBridge in handling Microseconds resolution of Timestamp data Details: Here in SEBridge, Microseconds resolution is hardcoded. So we are always seeing 6 fraction digits irrespective of scale and other properties
Problem conclusion
Resolution: To handle microseconds correctly, we added an environment variable which does: 1. When the environment variable is not added, the jobs would behave the same way as they are behaving today. This is to ensure that any of the customers who are using the Connectors on Server canvas and are comfortable with the hard coded microseconds that is coming in their data. 2. When the environment variable is added and its value is set to MICROSECONDS, it would be same behavior as (1). 3. When the environment variable is added with a value of SCALE, then it is expected that the scale is mentioned in the timestamp fields in the schema and whatever scale is mentioned the microsecond resolution would be set to that. 4. When the environment variable is added and its value is set to NONE, then the behavior would be same as DS_NO_FF ( or SCALE with the scale in the timestamp fields being set to 0).
Temporary fix
Comments
APAR Information
APAR number
JR41993
Reported component name
WIS DATASTAGE
Reported component ID
5724Q36DS
Reported release
850
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2012-02-21
Closed date
2012-05-29
Last modified date
2012-09-04
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
WIS DATASTAGE
Fixed component ID
5724Q36DS
Applicable component levels
R850 PSY
UP
R870 PSY
UP
[{"Line of Business":{"code":"LOB10","label":"Data and AI"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSVSEF","label":"InfoSphere DataStage"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.5"}]
Document Information
Modified date:
07 October 2021