Delivery Failing with C:D Transport Error sending a binary zipped file via Sterling Filegateway and Sterling Integrator cdinterop cdjava log post messageId JCPR017I.
Customer trying to transmit a zipped file via C:D using the Connect:Direct Server Adapter built into Sterling Integrator (SFG). This is the first large binary file they have tried (3.6 GB).
They have had no problems transmitting ASCII files up to 7 GB through this same connection.
The CopyTo BP "Status Report" for the failed step states:
Name: FileGatewaySendMessage Instance ID:1347012 Service Name: Connect:Direct Server CopyTo Service
ERROR CDServerCopyToService - Caught exception of type [com.sterlingcommerce.woodstock.cdinterop.server.CDInteropRemoteNodeException], with message [XSMG622I].
In the Sterling Integrator cdjava.cdinter.log (Connect:Direct Server Adapter Protocol Layer log) posted messageId JCPR017I after it appears to have sent multiple 32768 bytes/blocks of data.
[DEBUG 000000000000 GLOBAL_SCOPE CDServer.copyTo() - Finished copying the file to Remote Connect:Direct and details of response from Copy Execution : process 17 processName B1752614 CTRC messageId JCPR017I returnCode 8
Also just after FM72, it specifies text mode is set:
Entered CdCopier.bldNodeDefaults()::03| | | | defaultSysopts: datatype(text) strip.blanks(no) xlate(no)
And looking at FM71 (it follows FM72) it also specifies text mode is set...
00000250 74292073 74726970 2E626C61 6E6B7328 *t) strip.blanks(*
00000260 6E6F2920 786C6174 65286E6F 29000000 *no) xlate(no)...*
*** Next, just after the FM71 is error JCPS014I, due to this zipped file
is sent in text mode, and not sent in binary mode which is required to send a zipped file:
ALL 000000000000 GLOBAL_SCOPE ING_DE_CDSERVER_ADAPTER_node1P003949823976L135 Aug 21, 2012 6:14:19 PM: 04| | | | | EXCEPTION: CdPnIOException: getNextLine(): Source > dest
ALL 000000000000 GLOBAL_SCOPE ING_DE_CDSERVER_ADAPTER_node1P003949823976L135 Aug 21, 2012 6:14:19 PM:04| | | | | EXCEPTION:MSGID=JCPS014I,RC=8,FDBK=1,CLMTHNAME=CdCopier.sendData,
CDTXT="A line of text was read from the source file that is longer than the destination file can accept.
Please change the destination file attributes to accept a longer line of text. If you need help in doing this consult your Connect:Direct administrator.",
For this session sending a zipped file, the datatype should be set to binary, but it was set to text mode, this was verified in both the cdinterop and cdjava.log noted in FM71 and also in the corresponding cdinter.log.
Just after FM71 is error JCPS014I Source > dest record length.
Diagnosing the problem
The Filegateway Consumer profile contained sysopts
But the above sysopts parm does not cause SFG/SI to send this zipped file in Binary mode. This zipped file was sent in text mode because in SI the CD CopyTo service must contain parm BinaryMode=Yes for a file to be sent in binary mode and in this test BinaryMode was not present in the CD CopyTo, so BinaryMode defaults to No which sends file in text mode.
Resolving the problem
There are a few options you can take here for a solution:
1. The customer can use SFG to send his zipped file but he needs to create a new regular CD CopyTo BP. For example it would include a CD Begin Session service, CD CopyTo service, CD End service and in the CD CopyTo service it must contain parm BinaryMode=Yes to ensure the zipped file is sent in Binary mode.
2. If using SFG to send to remote C:D, he could modify the SFG BP AFTRouteViaCD which is executed in SFG to send to all remote C:Ds and code BinaryMode=Yes. But this would mean that each time SFG uses this BP, it will send in binary mode.
3. In SFG, you may create a Custom Protocol for his CD sends, to send with BinaryMode=Yes. The SFG online documentation can provide you with more detailed info on coding a Custom Protocol in SFG.
This particular customer implemented option 3, and created a Custom Protocol to send his zipped file with BinaryMode=Yes.
Translate this page: