Peter writes:
> Now, correct me if I am wrong but NetIPC is a HP 3000
> proprietary interface
> and Berkeley Sockets is the open interface that is available
> on every OS you can imagine.

Yes, NetIPC is a proprietary interface BUT it can communicate with other
systems that run TCP/IP or UDP/IP protocols.

> Now, if this is the case, does anyone have sample Cobol code
> using Berkeley
> Sockets? I'm researching writing a new front end for our
> product, using Cobol
> & Sockets but for obvious reasons, it must be portable to Linux.
>
> Any help, thoughts, ideas, or suggestions would be very much
> appreciated.

My only suggestion is that you should concentrate on your INTERFACE, i.e.
your Cobol subroutines that do the work.  You can then implement this
interface in a way that is best for the host OS.  NetIPC does things "the
MPE way", well, at least NetIPC works in a non-Unix way.  For example, most
Unix programmers use the method taught in the famous Stevens' Unix
Networking book for writing socket servers:  Receive a request, fork a
subprocess and exec the handling program.  MPE does not handle processes in
the same way.  Sometimes, MPE responds to the fork in a very negative way,
AKA the 'fork of death'.  OTOH, NetIPC can pass a socket to another existing
program already running in an entirely different account.  Very cool, very
efficient, and not possible in Berkley Sockets (AFAIK).

If you pop on over to http://www.beechglen.com/downloads.htm and look in for
the Cobol Socket example or even go to
http://www.qss.com/Sales/Qsdk/pqsdk.htm and look at how QSS developed a
Cobol Interface to sockets by downloading the QSDK manuals (PDF I believe)
you will see how they created an socket interface to Cobol.

If it were me, I would develop (or buy) an interface to Cobol that will run
on many platforms but implements this interface differently to take
advantage of the capabilities of the host OS.  The library could be a link
time library (RL or .a) or run time (XL or .so).  In this way I avoid
locking my application into any particular vendor or library.  BTW, this
also makes it easier to add new capabilities as there is only one library to
change.

FWIW,

Mark

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *