check the pnode/snode statistics to see what happened. SecondaryNodeOSĜHARACTER The operating system of the secondary Connect:Direct server (this might not be the same as the IBM Integration Bus operating system)
SecondaryNodeNameĜHARACTER The name of the secondary Connect:Direct server (SNODE) PrimaryNodeOSĜHARACTER The operating system of the primary Connect:Direct server PrimaryNodeNameĜHARACTER The name of the primary Connect:Direct server (PNODE) NameĜHARACTERğile name of the output file.
#CONNECT DIECT NETMAP WINDOWS WINDOWS#
For example, on Windows systems, this directory starts with the drive letter prefix (such as C: ). ProcessNumberĜHARACTER The number of the process that is sending the file.ĭirectoryĜHARACTERĚbsolute directory path of the output directory in the form that is used by the file system of the broker. ProcessNameĜHARACTER The name of the process that is sending the file.
The message is unchanged except for status information in the Local Environment.Īnd, as you can see, the only information that you get after that is: The message received on the In terminal is propagated to this terminal if the record is written successfully. If the process was submitted correctly to the CD Server, it's OK for broker (see the out terminal description of CDOutput node): If you set up a managed transfer you don't, you have to look in the Connect:Direct client to see the status of the transfers. So yes, if you run a script to perform an interactive transfer via Connect:Direct you get a return code. It doesn't monitor the transfer any more than it checks to see if an MQ message made it off a transmission queue. So IIB has successfully sent a command to Connect:Direct to initiate a managed file transfer, and now expects Connect:Direct to manage it. Yes, the Connect Direct server (which the script is manipulating) does report errors. Where in the IIB documentation does it say that the CDOutput node behaves like this? Why "must" it be reporting back? You can use the Connect:Direct statistics to get further information about the process.Ħ445 UserTrace BIP11506I: Committed a local transaction.Ī local transaction has been committed for work done on the message flow thread. The correlating Connect:Direct process is ''PQ11171'', process number ''5''. The CDOutput node ''CD Output'' has successfully sent a command to the primary IBM Sterling Connect:Direct server (PNODE) ''LOCALCDSERVER'' to transfer the file ''MAINFRAMEDATASET'' to the secondary IBM Sterling Connect:Direct server (SNODE) ''MAINFRAMENETMAP''. Sysopts="rm /var/mqsi/common/CD/LOCALIIBSERVER/SAMPLEEG/Transfers/CDOutput/CD Output/MAINFRAMEDATASET"Ħ445 UserTrace BIP12057I: Sent the file ''MAINFRAMEDATASET''. SYSOPTS=":DATATYPE=text:STRIP.BLANKS=no:XLATE=yes:" ) SACCT="WebSphere Message Broker=LOCALIIBSERVER, execution group=SAMPLEEG messageflow=CDOutput messageflow node=CD Output"įILE="/var/mqsi/common/CD/LOCALIIBSERVER/SAMPLEEG/Transfers/CDOutput/CD Output/MAINFRAMEDATASET" PACCT="WebSphere Message Broker=LOCALIIBSERVER execution group=SAMPLEEG messageflow=CDOutput messageflow node=CD Output"
#CONNECT DIECT NETMAP WINDOWS CODE#
In my experience, i have seen the connect direct scripts actually giving the accuarate return code that tells if the file reached the target server or not, which doesnt seem to the case with CD nodes.Ħ445 UserTrace BIP7954I: CDOutput node ''CD Output'' in message flow ''CDOutput'' has successfully sent a command to the IBM Sterling Connect:Direct server ''LOCALCDSERVER'' to start the transfer of the file to the remote system. I am sure i might be missing an entry on netmap on the target server which might be causing this issue but issues like these are common and the cd node must be actually reporting back if the file is in transit or if it reached the target server. No error reported by IIB and the file is stuck on connect direct folder, is now making me think if the CD nodes really have the same capability as the connect direct scripts. I am seeing that IIB is handing off the file to the local connect direct server but the file is stuck in the transfers folder below. I did a trace on the IIB server and below is what it shows. However, i see the file seems to be stuck on the local connect direct server and is not making it to the target OS390 box.
I have a message flow that is trying to send a file through with CDOutput node and the message flow is successfully sending the file the local connect direct server(which is running on the same machine as IIB). I am trying to send a file from IIB server to a OS390 box, with the right entries in place on Netmap and UserConfig files on both servers. I am trying to do a proof of concept on the CDOutput node for file-transfers, both inbound and outbound, as we are trying to move away from the native connect direct scripts, for better integration ith the IIB.
0 kommentar(er)
