[comp.protocols.tcp-ip.ibmpc] INT14/COM1 redirection with FTP/TRW PC/TCP

dsc3rjs@NMDSC20.NMDSC.NNMC.NAVY.MIL (Bob Stratton) (12/15/90)

Hello all,

I have a thorny problem with a pretty high priority, and I'm looking for 
answers.

I have 386 PC's running TRW's (ported from FTP Software) PC/TCP suite,
along with a big PC-to-mainframe front end from Comshare, called "Commander."

The Commander software understands the following API/comm interfaces:
 - COM[1..4] for the PC serial ports.
 - IRMA boards from DCA
 - the Forte PJ comm. adapter
 - the IBM 3278/79 Emulation Adapter, or the 3270 connection card
 - the ITT Application Programming Interface

 Of all the items above, I have a nagging suspicion that the ITT API may be
similar to what I want, if not identical, but I've never seen anything on it.
(I infer this from very scant data - The argument list looks similar to 
certain interrupts that I know are grabbed by things like PC/TCP, i.e. "60")

Unfortunately, Comshare doesn't document things like this very explicitly, and
I haven't been able to find anyone who could tell me what I want to know.

Has anyone written a "COM1 to INT14 Redirector"????? Is it at the BIOS level
or does it try to grab H/W accesses to the serial port? Am I spinning my 
wheels?

Thanks in advance!

Bob Stratton 		| dsc3rjs@nmdsc20.nmdsc.nnmc.navy.mil [DDN/Internet]
NAVMEDATASERVCEN	| dsc3rjs@vmnmdsc		      [BITNET]
(Innova Comms. / AT&T)	| 295-3503 [AV]    +1 301 295 3322    [PSTNet]
Disclaimer: The above opinions are mine alone - Who else would want them?

jbvb@FTP.COM ("James B. Van Bokkelen") (12/15/90)

If they don't support INT 14 themselves, it will be hard to fake without
a *lot* of fancy programming on a machine which can trap and redirect
accesses to the I/O ports used by COMn (i.e. an 80386 in other than real
mode).  In any case, it seems like you want to create a TN3270 conneciton,
which requires that you use the Dev Kit Telnet library (in 2.05, it is
fancy enough to do a multi-session TN3270) or direct TCP access via sockets
or the INT 61 calls.  The problem is that basic INT 14 isn't zippy enough
to handle block mode and terminal type negotiation.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

dsc3rjs@NMDSC20.NMDSC.NNMC.NAVY.MIL (Bob Stratton) (12/15/90)

>If they don't support INT 14 themselves, it will be hard to fake without
>a *lot* of fancy programming on a machine which can trap and redirect
>accesses to the I/O ports used by COMn (i.e. an 80386 in other than real
>mode).  In any case, it seems like you want to create a TN3270 conneciton,
>which requires that you use the Dev Kit Telnet library (in 2.05, it is
>fancy enough to do a multi-session TN3270) or direct TCP access via sockets
>or the INT 61 calls.  The problem is that basic INT 14 isn't zippy enough
>to handle block mode and terminal type negotiation.

Thanks for the quick response...

The TN3270 connection is not necessary as I am going through a Data PBX
and Asynchronous Emulation Adapters (AEA's) on my front end to the mainframes,
which will give me VTxxx emulation by default. 

I thought about what's involved in writing this hack myself, but it also 
seems that the Comshare software is using some beast called "OS286" which 
I hear (rumor) does some switching in and out of protected mode so as to get
large tracts of virtual memory, thus further complicating my problem.

The really annoying thing is that the package has hooks to use some other 
API's, some of which allow the specification of port addresses...I can't 
imagine writing stuff to delete someone else's 3270 screen control codes
from the data stream, however.

I've heard an answer from the most definitive source I know (that's you 
James!), so now I'll fall on the net: If ANYONE out there has any experience
in doing LAN configuration with Comshare's COMMANDER product, PLEASE drop me
a note. I suspect that they may have done this before, and are just not 
documenting it, based on their price/time estimates to provide this
functionality.


P.S. Will the glorious TN released in 2.05 work under the 2.04 kernel???

Thanks to all in advance,

Bob Stratton 		| dsc3rjs@nmdsc20.nmdsc.nnmc.navy.mil [DDN/Internet]
NAVMEDATASERVCEN	| dsc3rjs@vmnmdsc		      [BITNET]
(Innova Comms. / AT&T)	| 295-3503 [AV]    +1 301 295 3371    [PSTNet]
Disclaimer: The above opinions are mine alone - Who else would want them?

jbreeden@netcom.UUCP (John Breeden) (12/15/90)

In article <9012141949.AA23788@nmdsc20.nmdsc.nnmc.navy.mil> dsc3rjs@NMDSC20.NMDSC.NNMC.NAVY.MIL (Bob Stratton) writes:
>
>Has anyone written a "COM1 to INT14 Redirector"????? Is it at the BIOS level
>or does it try to grab H/W accesses to the serial port? Am I spinning my 
>wheels?
>

A few years ago I saw a product from a company (in Southern California as I
recall) that made a hardware product (card) that looked like a COM port to
an application but re-directed it out as an INT14 call (it cost $100 single
quantity two years ago).

They make/made async servers based on INT14 and IBM's ASC. I just can't recall
the company's name. This might joggle someone's mind. Sorry I can't offer
more - I'll check my files at work (brown boxes under desk).

-- 
 John Robert Breeden, 
 netcom!jbreeden@apple.com, apple!netcom!jbreeden, ATTMAIL:!jbreeden
 -------------------------------------------------------------------
 "The nice thing about standards is that you have so many to choose 
  from. If you don't like any of them, you just wait for next year's 
  model."

jbvb@FTP.COM ("James B. Van Bokkelen") (12/19/90)

The 2.05 TN.EXE should work just fine on a 2.04 kernel, but ordinarily
you wouldn't upgrade one without the other...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901