For completeness:

The GENTRAN GIFSGATE command was changed to include two new parameter to specify the CCSID of the incoming and outgoing data. The default on the outgoing parm was incorrect--GENTRAN Support says to change it to *STAC, for "Standard Ascii". (Version 6 has been out for ages and I'm surprised we are the first to have this problem, but maybe our combination is unique.)

The VAN connection failure turned out to be limited to a few customers who use SSL. The GENTRAN conversion of their communication profile dropped the SSL information.


On 9/17/2012 6:02 PM, Sam_L wrote:
The EDI guys upgraded GENTRAN from v5 to V6 yesterday. Looked like
everything was working but they didn't test the communication bits.

This afternoon an AS2 partner send back one of our outgoing
transmissions because it contained nonsense data. True. When the EDI
guys look at the IFS file thru a Windows mapped drive the file is
garbage. When I look at it through WRKLNK it is correct. I'm guessing
a CCSID mismatch somewhere in GENTRAN, though IBM support are unable to
pinpoint it, so we've gone back to V5. The other issue is that GENTRAN
batch jobs cannot sign on to the VAN, thought the password is correct
and the EDI guys can connect interactively. And everything works now
that we're back on V5.

The IFS file CCSID is 37. System value QCCSID is 65535 (I inherited
this). Some of the other EDI directories (there is one for each
customer) have CCSID 37, some CCSID 1252, but I haven't looked at them all.

Some user profiles are CCSID 37 but I haven't done a thorough
investigation of them all, or determined what profile EDI jobs get
submitted with.

1) If anyone has any GENTRAN insight I would appreciate it.

2) What are the implications of changing QCCSID(65535) to QCCSID(37)? Is
there anything more suitable for a USA shop, mostly homegrown apps and
.NET code.

Thanks, Sam

This thread ...

Return to Archive home page | Return to MIDRANGE.COM home page