Changing sending ports in the middle of a job

A mainframe host is sending from a specific port to a PC (an IP
address / port) using "Raw" TCP/IP. At the end of the first page they
change from the original sending port to a different port, still
sending to the same IP address and destination port. The job fails,
only the first page printing.
I think it its correct behavior on the part of the receiving system to
end the TCP stream when transmission ceases from the original port,
and assume that the transmission from the new port (same IP address)
is a new transmission.

Am I incorrect?

Any ideas or suggestions?

notgiven wrote:
> A mainframe host is sending from a specific port to a PC (an IP
> address / port) using "Raw" TCP/IP. At the end of the first page they
> change from the original sending port to a different port, still
> sending to the same IP address and destination port. The job fails,
> only the first page printing.
> I think it its correct behavior on the part of the receiving system
to
> end the TCP stream when transmission ceases from the original port,
> and assume that the transmission from the new port (same IP address)
> is a new transmission.
>
> Am I incorrect?
>
> Any ideas or suggestions?

The "circuit" is established with the tuple (src addrs, dst addrs, src
port, dst port) and changing any of the elements would require the
establishment of a new circuit/session.

Whether the sender is intending this or not I can't readily see what's
the point. There are protocols that use multiple ports per "connection
session" but whether that should apply here I can't say.

In your present case it seems something is "broken" (ie., obviously
undesired behavior) but what it may be is hard to say. Sounds like the
sender is expecting the receiver to be prepared for port-per-page but
has failed to set it up (or check that receiver has properly set it up)
before transmitting.

This sort of thing is more common with UDP than TCP, ime fwiw

Is this code that previously ran in a different environment and/or with
a different client?

prg

On 12 Mar 2005 08:20:24 -0800, "prg" <(E-Mail Removed)> wrote:

>The "circuit" is established with the tuple (src addrs, dst addrs, src
>port, dst port) and changing any of the elements would require the
>establishment of a new circuit/session.

Thanks for confirming this. I thought so.

>Is this code that previously ran in a different environment and/or with
>a different client?

Yes, the mainframe previously printed via "Bus and Tag" direct
channel. Now it's going over TCP. The printing works fine if they
print LPR but they do not want to do this because (and I am quoting
here) "When we print LPR we have to spool the job twice, and our spool
area overflows. We don't mind LPR for small jobs, but not for large."
My conclusion is that while I don't know the things they are doing
wrong, I am certain that there are quite a few such things.

"notgiven" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> I think it its correct behavior on the part of the receiving system to
> end the TCP stream when transmission ceases from the original port,
> and assume that the transmission from the new port (same IP address)
> is a new transmission.

Yes, it is a new transmission, as far as TCP is concerned.

DS