Any 3270 emulation for perl yet?

[Fred]

I searched for a perl 3270 emulator several years ago, and
could find none. I wound up using the s3270 emulator wrapped
in a perl script. I've been searching again, and still do
not see a perl based 3270 emulator. Since a perl 3270
emulator apparently still does not exist, I guess the
question is why? It would seem a natural for perl, to
connect to a 3270 and screen scrape, or whatever.


-Thanks

 

[Ted Zlatanov]

F> I searched for a perl 3270 emulator several years ago, and could
F> find none. I wound up using the s3270 emulator wrapped in a perl
F> script. I've been searching again, and still do not see a perl
F> based 3270 emulator. Since a perl 3270 emulator apparently still
F> does not exist, I guess the question is why? It would seem a
F> natural for perl, to connect to a 3270 and screen scrape, or
F> whatever.

I don't think you mean "emulator" here, since Perl is not going to
pretend to be a 3270. You want Perl to connect to a 3270 and get some
data. If you can show sample data the 3270 would send, and what tasks
you are trying to accomplish, you may get more help.

Ted

 

[RedGrittyBrick]

I searched for a perl 3270 emulator several years ago, and
could find none. I wound up using the s3270 emulator wrapped
in a perl script. I've been searching again, and still do
not see a perl based 3270 emulator. Since a perl 3270
emulator apparently still does not exist, I guess the
question is why?

Maybe because the 3270 is so complex, weird and little-used nowadays?

The original 3270 was connected by Coax cable, not serial cable, not by
Ethernet (nor even Token Ring originally).

The original 3270 used a proprietary block-mode communications protocol.
I think it was synchronous rather than asynchronous.

The 3270 uses the EBCDIC character set.

I think most 3270 emulators (including s3270) emulate 3270 over telnet,
which gets rid of the first two problems. Assuming your mainframe
supports TN3270.

Perhaps Uri is busy scrutinizing RFC1576

 

[Uri Guttman]

R> Maybe because the 3270 is so complex, weird and little-used nowadays?

it is still a major i/o style for many legacy mainframes. that is why
there are many software emulators around. not much in the way of
physical terminals may exist anymore but i don't know for sure.

R> The original 3270 was connected by Coax cable, not serial cable, not
R> by Ethernet (nor even Token Ring originally).

well it was used way before those were invented. hell, the simple ascii
terminal wasn't in use then too. and they did use serial lines when used
over a modem (at least the modem part did).

R> The original 3270 used a proprietary block-mode communications
R> protocol. I think it was synchronous rather than asynchronous.

bisync. it used a 2 byte sync char and was half duplex/polled.

R> The 3270 uses the EBCDIC character set.

the least of its craziness.

R> Perhaps Uri is busy scrutinizing RFC1576

nope. i actually used a 3270 emulator package from DEC on RT-11 way
before most of you were born. i even found a bug in it which proved that
we were the first real world users of it (it started an ack0/ack1
pattern on the wrong foot). so i know about the protocol (bisync) and
polling and such. this last fall i even helped someone i know with using
some 3270 emulation package under perl. but i won't be writing a module
for this as no itch could possibly make me care about the 3270.

a cluster of 3270s would share a single controller/modem which would
connect over a phone line to the mainframe. so it used some form of
serial line at that level. there might have been some form of coax
between the terminals and the controller. i didn't ever get into
physical use of 3270's so i may be wrong on the wiring but the protocol
i did know some way back when.

uri

 

[gf]

a cluster of 3270s would share a single controller/modem which would

connect over a phone line to the mainframe. so it used some form of
serial line at that level. there might have been some form of coax
between the terminals and the controller. i didn't ever get into
physical use of 3270's so i may be wrong on the wiring but the protocol
i did know some way back when.

The protocol was SNA over coax. The controllers were prone to locking
up, causing sessions to fail on the attached terminals and forcing
tired system admins to run around looking for the appropriate box that
wasn't clicking (as it read its 8" floppy) and hit the reset switch.

I was really glad to see them go because they were so much of a pain.

These days I'd imagine most sites would have migrated to TCP/IP on VM
and would be using some variation of tn3270 or a different terminal
emulator.

From my experience scraping 3270 screens back in the days of yore, the

big problem would be a buffer would have to be built which would
contain the screen being sent by the mainframe. Then, when the
computer said the screen was finished being written it'd send a signal
and we could scrape.

Telnet could be used, because tn3270 is basically built on telnet with
additional positioning and color codes. If the host was sending a
screen update after a clear then it should send the screen from left
to right and top to bottom... if the screen was designed that way. Of
course it could also go in any other order because of the ability to
position and print at any screen position.

As for seeing one done in Perl? I don't see why anyone would. There
are libraries and APIs available to get there from Java and C/C++ so
I'd head that way first.

 

[John W. Kennedy]

The protocol was SNA over coax.

No it wasn't, at least, not in the early days; early 3270's were
channel-attached or used bisync, and even when SNA was added as an
option, SNA stopped at the controller, with the coax protocol being
proprietary. (In fact, the first SNA 3270's (the 3271-11,-12 and
3275-11,-12) stopped being SNA at the 3705; beyond that point, it used a
half-assed semi-SNA.) I think later sophistications from the mid-80's
may have employed some kind of SNA all the way, but I'm not certain.