1

I would like to build a communication protocol between COBOL and C# applications. I didn't find the right way to connect these two applications. The only possible way is to write data by COBOL to a file and read it by C# application and vice versa.

Can I use socket techniques to create such communication, because the file method has bad performance? Or are there any other methods of communicating data between these two languages?

john miran
  • 393
  • 2
  • 13

1 Answers1

1

Can I use socket techniques to create such communication [...]?

Of course! You just need to make one a socket server and the other the client + creating + implementing a protocol (if it is just one client + server and you don't need secure communication this is quite easy). You may already have a socket option in your COBOL environment or use external libraries like the free CBL_GC_SOCKET (works for many COBOL implementations, as long as they can call C/C++ binaries).

Or are there any other methods of communicating data between these two languages?

A multitude (especially if they run on the same machine).

  • Depending on the COBOL environment used you may have a direct .NET-assembly option and CALL/invoke, or can write a layer to do so with running COBOL code translated to native code within C#.
  • Direct input/output is often a solution (depends on the needs and the environments, not all have a bi-directional pipe option).
  • talk to a message queue server (likely not superior in performance)
  • if the COBOL environment supports it: create a REST endpoint and use this for communication; or do it the other way around talking from COBOL to a REST service implemented in C# (REST from COBOL is likely the "most portable" way of those mentioned, but also the one with the worst performance)
  • ...

Conclusion: there is nothing that hinders COBOL to "communicate" with any reasonable "other programming language", you mainly have to see what you're COBOL and "other programming language" provides and what your goals are.

Simon Sobisch
  • 6,263
  • 1
  • 18
  • 38
  • Could you explain why a message queue server wouldn't work? For example, if telegraf daemon were running locally, and forwarding to, say, ZeroMQ or an MQTT broker, why would that be worse than just a raw socket? (forgetting the overhead of extra dependencies) – OneCricketeer Apr 22 '20 at 06:48
  • 1
    A message server would totally work (after you have both sides working to communicate with it). An additional "man in the middle", which in this case likely also not broadcasts the message but transport it only to a specific client, is always overhead, so depending on how often you send messages you'll see the overhead. – Simon Sobisch Apr 22 '20 at 07:24
  • ZeroMQ / RabbitMQ / ActiveMQ, MQTT, Kafka, and the list goes on, all have different levels of broadcast capabilities. Adding message queue/distributed log channels and asychronous service workers are how the modern web works, so in that realm, companies that dont already invest in techonlogies like that are just going to fail to innovate, IMO. This is how Netflix, Uber, Tesla, Spotify, etc, are all able to scale their workloads – OneCricketeer Apr 22 '20 at 15:51