VAX COBOL and TCP/IP

Hi all,

I work as a consultant developing systems integration software. One of
my customers has all it's administrative software on VAX, written in
COBOL, and we now need to send/receive data via TCP/IP to get data into
their new hip-doody transaction based system. Their resident COBOL
programmer has done the basic send/receive routines, so we can get data in
and out OK.

The packet structure we are sending is <STX><LENGTH><DATA><ETX>. Send
works OK, but the COBOL programmer does know how to do an interative read
and store to process the incoming data.

Has anyone done anything like this? If so, could you share your knowledge
and or code?

TIA

Simon Martin

On Fri, 27 Aug 2004 09:45:43 -0400, simon martin
<smartin@milliways.cl> wrote:

>I work as a consultant developing systems integration software. One of
>my customers has all it's administrative software on VAX, written in
>COBOL, and we now need to send/receive data via TCP/IP to get data into
>their new hip-doody transaction based system. Their resident COBOL
>programmer has done the basic send/receive routines, so we can get data in
>and out OK.
>
>The packet structure we are sending is <STX><LENGTH><DATA><ETX>. Send
>works OK, but the COBOL programmer does know how to do an interative read
>and store to process the incoming data.
>
>Has anyone done anything like this? If so, could you share your knowledge
>and or code?

On Windows, winsock (wsock32.dll) does the heavy lifting; VAX has a
similar device driver. To read a message in Windows, you say:

call 'read' using                   *> call 'recv' on VAX
by value socket-handle,
by reference input-buffer,
by value buffer-length
returning tcp-return-code

simon martin wrote:

> The packet structure we are sending is <STX><LENGTH><DATA><ETX>. Send
> works OK, but the COBOL programmer does know how to do an interative read
> and store to process the incoming data.

Generally you have to do that when sending data over a modem because you
don't necessarily know where a packet starts or ends, or what its size is.

This practice is totally unnecessary under TCP/IP because the standards
automatically indicate what a particular packet is, the order of the
fragments, and how long it is.  If you use TCP as opposed to UDP, you
even get guaranteed delivery of the packet free of charge!  Even on
wends and holidays!

Stick that in your pipe and smoke it, Fedex!

Well, except that under TCP two "packets" may be combined or one "packet"
may be split.  So having a length "field", at least, is quite useful.

Frank

---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO  USA
 
simon martin wrote:

> The packet structure we are sending is <STX><LENGTH><DATA><ETX>. Send
> works OK, but the COBOL programmer does know how to do an interative read
> and store to process the incoming data.

Generally you have to do that when sending data over a modem because you
don't necessarily know where a packet starts or ends, or what its size is.

This practice is totally unnecessary under TCP/IP because the standards
automatically indicate what a particular packet is, the order of the
fragments, and how long it is.  If you use TCP as opposed to UDP, you
even get guaranteed delivery of the packet free of charge!  Even on
wends and holidays!

Stick that in your pipe and smoke it, Fedex!

In article <gFtJd.9952$Hg6.7236@trnddc09>, Paul Robinson <postmaster@paul.washington.dc.us>
 writes:
> simon martin wrote:
> 
>
> Generally you have to do that when sending data over a modem because you
> don't necessarily know where a packet starts or ends, or what its size is.
>
> This practice is totally unnecessary under TCP/IP because the standards
> automatically indicate what a particular packet is, the order of the
> fragments, and how long it is.

No they don't.  TCP is a stream protocol; it provides no delimiting of
user records.  UDP is an unreliable-datagram protocol and may silently
truncate or fail to deliver a record.

There have certainly been a great many record-oriented protocols
designed to run on top of TCP/IP, and some of them are even standard
(in the sense of appearing in standards-track RFCs and the like), but
applications using straight TCP have to do some sort of framing.
Using both frame markers (and hopefully some bit-stuffing or other
escaping technique to prevent them from appearing elsewhere in the
data) and a length field is redundant, but redundancy is often a good
idea.

In many cases, application programmers would do better to avoid
reinventing the wheel and use one of the many freely-available
implementations of record-oriented application protocols.  Lots of
applications that have nothing to do with web browsing use HTTP for
just this reason, for example.

However, if the OP is committed to using "raw" TCP streams, then he's
on the right track.  I didn't see the original post (apparently due
to an infelicitous interaction between a crashing X server, my
newsreader's approach to updating its read-article data, and the
server's article-numbering scheme), but with typical TCP APIs (BSD
sockets, etc) the receiving side would:

1. Make sufficient receive attempts, accumulating data in a buffer,
until the initial fixed-length portion of the message had been read
(in this case, that would be the <STX> and the <LENGTH>, assuming the
latter was fixed-length; if not, this gets a bit trickier, as the
receiver would have to receive data and parse it until it knew it had
the entire length field).  Of course, it needs to handle exceptions
such as premature conversation termination.

2. Verify that the <STX> is correct, parse the <LENGTH>, and verify
that it's within an acceptable range.  (Skipping the last step is not
a good idea.  I've seen plenty of programs that used a 32-bit length
unquestioningly but would never receive a 4 GB packet in proper
operation.  Implement sanity checks.)

3. Make additional receive attempts, accumulating data, until the
entire packet has been received.  It would be a good idea to scan for
<ETX> after each receive, as another sanity check (assuming <ETX>
cannot appear in normal data).

4. Verify the <ETX>.

Many modern protocols (like HTTP) are much more complex, and can
delimit records in various ways, but the above is pretty typical for
simple proprietary application protocols.

The main thing to note is that TCP does not know where your record
ends, so the TCP API cannot receive your record for you.  You have to
determine when you've reached the end.


--
Michael Wojcik                  michael.wojcik@microfocus.com

This is a "rubbering action game," a 2D platformer where you control a
girl equipped with an elastic rope with a fishing hook at the end.
-- review of _Umihara Kawase Shun_ for the Sony Playstation