I am completed baffled

[mseedig]

We recently converted our test environment from Ascential DataStage TX 8.0 to IBM WebSphere Transformation Extender 8.1. No problems. This weekend, we started the conversion of our production environment. The OS levels are identical. The hardware is practically the same. The version and build of the WTX components are identical. The trouble is, when I copied over the maps, trees, etc and rebuilt the system, I get different results in the production environment than I do in the test environment. I have a map that is reading the text of the transmission data to parse out a series of variable elements, such as transaction id, file type, etc. Using identical inputs (and the map source code is identical), I am getting very different results from one environment to the other. Has anyone ever seen anything like this before?

As an example, in one environment I get:

edi0000008200804200001oo.out|997|148
(and this is correct)

In the other environment I get:

edi0000008200804200001oo.out|997|041007717
(this is definitely not correct, unless ansi has come up with an x12 transaction type of 041007717!)

 

[janhes]

Is the data structure the same?

 

[mseedig]

Yes, we are using the exact same input in both instances, the data and data structure identical. Honestly, it makes no sense to me at all.

 

[eyetry]

Hardware variations can make a diff.

Could there be TX patches/updates applied to one machine that are not on the other? There used to be a batch file, Windows, that you could run that would list file version info.

Same could be true for OS. In our shop we've had issues with tech services having OS patch and application variations between machines that have affected output. An application specific issue was based on FTP tools used.

 

[RichLee]

dtxver.exe is the command you need in 8.1

 

[janhes]

What's the rule for the field with the incorrect data?

 

[mseedig]

I haven't been ignoring your question for me, I've just been juggling 1,001 things these past couple of days. I'll hopefully get it posted on Monday. (The actual rule for that output card is one that calls a functional map and uses a series of outputs from a previous output card, so my post may be a little convoluted.)

 

[mseedig]

Ok, here goes. I found BOTH dtxver.exe and dstxver.exe in the installation directory. Ran both executables on both the test and production servers. Did a DIFF on the results, and the only thing different was the time stamp of when the files were created. The ver contents were identical. Also did a ver on the OS, and the results again were identical. Had one of the server folks do a comparison on the servers, and they determined that the installs and all the other things on the servers look the same.

The "offending" rule is:

=IF ( Variable Element [1]:Identification = "txt", "ak1", Variable Element [6]:Identification )

Since Variable Element [1]: Identification is not "txt", then I expect the output to be the value of Variable Element [6]:Identification. (And since I'm using the exact same input file, for some reason I'm expecting the same output.)

The rule from the previous card that builds Variable Element [6]:Identification is:

=IF ( Variable Element [5]:Identification = "997", f_Get997Original( MID( Text Data:Transaction, FIND( "AK2" + Variable Element [4]:Identification, Text Data:Transaction ), 80 ), Variable Element [4]:Identification ),
IF ( Variable Element [5]:Identification = "824", f_Get824Original( MID( Text Data:Transaction, FIND( "OTI" + Variable Element [4]:Identification, Text Data:Transaction ), 80 ), Variable Element [4]:Identification ), "txt" ) )

And for the record, it is a 997, not an 824.

The rule for the f_Get997Original functional map is:

=WORD( AK2Segment, ElementSeparator, 2

I have another map that I can't explain the results either, but that is another thread. (It should be reading in a config file at runtime, but it sure doesn't seem to be doing so.)

I'm all out of hair to pull out. Anyone have any extra?

 

[janhes]

So it looks like the problem is arising in f_Get997Original.
You need to check what this is generating and why. Could the FIND be causing the problem?

 

[mseedig]

Ok, I THINK I found the problem, I just can't imagine what caused it. We process X12 148 transactions (version 3041). The 148 transaction comes in two "varieties", a First Report, and a Subsequent Report. While these two flavors contain varying segments and data, they are both 148 transactions. The problem I found late yesterday was that the 148 Subsequent Report generates a 997 that does not have an AK2 segment, which is where we look to find that it is a 148. (We also process other transaction sets such as 837). However, a 148 First Report generates a 997 that DOES have an AK2 segment. My assumption would be that if one 148 generates a 997 with an AK2 segment, then all other 148 transactions would do the same. I've looked at the Trade Links and the X12StructureValid table, and I can't for the life of me figure out why one 148 generates a 997 with an AK2, and another 148 generates a 997 without an AK2. If I had any hair, I'd be pulling it out, but I'm already bald so that won't work.