20 Apr
2006
20 Apr
'06
4:42 p.m.
A module list I scrounged off the net says this:
M3134-PA DS500 Q IBM Terminal server, 4 port (DECServer 500)
Now we were just talking about how in order to hook up an IBM terminal
to something, you'd have to hook up an IBM box. This seems to
indicate that you could do otherwise and it would work? The module
ports are BNC style coax it appears.
Does anyone have any familiarity with this module?
--
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
<http://www.xmission.com/~legalize/book/>
Pilgrimage: Utah's annual demoparty
<http://pilgrimage.scene.org>
20 Apr
20 Apr
5:23 p.m.
Richard wrote....
A module list I scrounged off the net says this:
M3134-PA DS500 Q IBM Terminal server, 4 port (DECServer 500)
Let me say first that I am not at all familiar with the M3134. However, I
think you're missing the basic concept here. The IBM coax terminals do not
speak ascii, nor do they speak RS232. Nor are they character based like ANY
and EVERY terminal you've probably delt with before. The electrical spec
isn't similar to RS232 but current loop... it is a fundamentally different
thing. These terminals are not only block mode, they speak a VERY robust
protocol between the host and the display. It would be quite difficult to
make sense out of the datastream between the terminal and host in a
character based environment.
Again, while I don't know for sure... I would bet some cash that the M3134
probably provided an electronic connection for the terminals, you probably
had to do a world of programming on your own to actually talk to those
units. And you probably had to develop your own protocol for dealing with
fields/pages being sent back and forth. Perhaps DEC supplied a toolkit for
doing so. But in any case, I suspect that even with their tools, you would
NOT get a RSTS logon prompt on one just by using this card and writing a
little code. You probably would get a toolkit that you could use to send and
receive a page at a time to the terminal... basically you'd probably get an
I/O device under program control.
Jay
5:59 p.m.
In article <016901c664c0$ba7adb70$6500a8c0 at BILLING>,
"Jay West" <jwest at classiccmp.org> writes:
Let me say first that I am not at all familiar with
the M3134. [...]
Me neither and I understand the problems you've outlined, which is why
I want to find someone who is familiar with the M3134 so I can find
out how much of the puzzle it solves.
Right now I don't even have electrical connectivity! I'm working on
this problem, which is why I'm curious to know more about this module.
--
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
<http://www.xmission.com/~legalize/book/>
Pilgrimage: Utah's annual demoparty
<http://pilgrimage.scene.org>
10:05 p.m.
Richard, if you really need to get an ibm coax term on a pdp, there IS a way
to do it.
Set the 3270 style terminal to CUT mode instead of DFT. This removes much of
the "smarts" from the terminal. Hook the 3270 term to a 3174 controller via
coax. The 3174 controller must have the AEA option installed (ASCII
emulation). Basically the AEA option gets you a number of serial ports (9 I
seem to recall) on the back of the 3174 to which you can attach rs232 async
dumb terminals, or, in your case, run cables to the rs232 async port(s) on a
"more traditional" host.
Bear in mind you will get a terminal that still won't work right with many
things you might expect any terminal to work with... for example I don't
believe any character (full screen) editor would work (and not just because
of termcap type issues), I don't think TECO would work (esc=$).... etc. But
you could do it. Most of your application programs (including system
programs like login, command shell, etc) won't work either because they
expect character at a time input.
The basic fundamental issue is, in the IBM world what a terminal is/does and
how a terminal should interact with a host system is a diametrically opposed
and fundamentally different concept to how one thinks about what a terminal
is and how it should interact with a host in the async/ascii world. It's
much much more than just electrical and characterset issues.
So... get a 3174 with option AEA and play around with it and see what you
think.
Jay West
21 Apr
21 Apr
12:38 a.m.
In article <005901c664e8$06ff1b10$6900a8c0 at HPLAPTOP>,
"Jay West" <jwest at classiccmp.org> writes:
The basic fundamental issue is, in the IBM world what
a terminal is/does and
how a terminal should interact with a host system is a diametrically opposed
and fundamentally different concept to how one thinks about what a terminal
is and how it should interact with a host in the async/ascii world. It's
much much more than just electrical and characterset issues.
Yeah, its starting to sink into this thick skull :-).
On the other hand, as a collector of terminals this is pretty
interesting exactly because its so weird!
--
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
<http://www.xmission.com/~legalize/book/>
Pilgrimage: Utah's annual demoparty
<http://pilgrimage.scene.org>
20 Apr
20 Apr
6:09 p.m.
Jay West wrote:
However, I think you're missing the basic concept
here. The IBM coax
terminals do not speak ascii, nor do they speak RS232. Nor are they
character based like ANY and EVERY terminal you've probably delt with
before. The electrical spec isn't similar to RS232 but current
loop... it is a fundamentally different thing. These terminals are
not only block mode, they speak a VERY robust protocol between the
host and the display. It would be quite difficult to make sense out
of the datastream between the terminal and host in a character based
environment.
I know next to nothing about the M3134. It implements enough to
allow you to hook a 3270-speaking terminal to a DECserver 550.
Quite whether that terminal was then intended to talk to a
DEC system or an IBM system is not clear to me. There were
DEC applications that (apparently) could use block-mode
terminals (the VT131 and/or VT132 did block mode didn't they)
but whether the DS550 would translate the 3270-terminal-speak
into something suitable or not, I don't know.
But I think at the very least the physical layer issues must
be solved by this card (otherwise what's the point)?
Antonio
--
Antonio carlini
arcarlini at iee.org
22 Apr
22 Apr
4:02 a.m.
On 4/21/06, a.carlini at ntlworld.com <a.carlini at ntlworld.com> wrote:
Jay West wrote:
I, too, know little about the M3134 (but I used to manufacture IBM
protocol emulators for HASP, 3780 and SNA, including 3270
emulators)... about all I _do_ know about the M3134 is that the output
physical layer is some form of coax. If that doesn't directly connect
a 3270-type terminal, I can't imagine what it's for. I've only ever
plugged genuine IBM 3270 terminals into a 3274, and a 3274 into a 4331
(mid 1980s, for those at home keeping score).
Now... from an application standpoint, it would be helpful if the
M3134 did some protocol massaging (ASCII<->EBCDIC, 3270 to
stream-of-bytes,etc), but I don't know what it really does.
-ethan
However, I think you're missing the basic
concept here. The IBM coax
terminals do not speak ascii, nor do they speak RS232. Nor are they
character based like ANY and EVERY terminal you've probably delt with
before. The electrical spec isn't similar to RS232 but current
loop...
I know next to nothing about the M3134. It implements enough to
allow you to hook a 3270-speaking terminal to a DECserver 550.
6667
days inactive
6669
days old
6 comments
4 participants
participants (4)
-
a.carlini＠ntlworld.com -
ethan.dicks＠gmail.com -
jwest＠classiccmp.org -
legalize＠xmission.com