Re: Number Only Fields

I'm CCing the list on this message, as it contains information relevant to the
current status of the Number Only field bug, and I'm way too lazy to write
more than one message ;)

On Tue, Jan 04, 2000 at 10:08:06AM -0800, Arno Schortinghuis wrote:
> As to the Numeric Only field, that is exactly how I handled it. Shift field,
> fill if necessary and overpunch the last byte on Field- (with xD0).

This is starting to worry me.  I just tried another emulator (WinAPPC), and it
suffers the exact same "problems" as the Java emulator.  It doesn't shift the
data to the right on Field Exit or Field-, the shifted digit always ends
up being '}' no matter what the digit was before.  And I get the same error as
the Java emulator from the host, although I think I can write that off as
a problem with my silly CL script (I don't know much about CL).

I'm about to try Client Access, but I'm going crazy here.  I've devised a way
that I can use a traffic sniffer to snoop the session, thus not requiring me
to play man-in-the-middle to get a hex-dump of the session.

> 
> I know its a bit of a pain, but it is possible to get a comm trace on the
> AS400.  This can be narrowed down to at least the source TCP/IP address.  I
> had to do this a few times when I got conflicting results from different
> emulators.  I used a real 5250 terminal as the gold standard.

Hmm, I have no "real" 5250 terminal, unfortunately.

> 
> I have been following this discussion group for a while and am curious why
> the project was shifted from C++ to C.  Did you consider wxWindows as a
> basis for the Windows port?

The big reasons were portability, flexibility, and light-weight - in that
order.  Only recently (with the release of gcc 2.95.1, which used to be egcs)
has Linux gotten a modern *and standard* C++ compiler which supports templates,
namespaces, and all the rest well enough to make it worthwhile.  At the time
(and still now, to a degree), C++ is a shifting language, and porting between
different C++ implementations can be a nightmare.  We had issues at one point
when someone tried porting one of the C++ versions to NeXT, which had an
older C++ compiler.

As for the flexibility and light-weight issues, this is observed from the
GTK+ code itself.  You can produce C++ or Ada95 or Scheme or TCL/TK or Perl
or whatever language bindings you want for lib5250 if it is written in C.  If
it is written in C++, sometimes you have issues for conflicting headers and
what not.

As for light-weight, there has been interest in making a Linux-based boot-disk
which turns a 486 into a dumb terminal, which is somewhat similar to what the
Linux Terminal Server Project (http://www.ltsp.org/) has done with the
emulator (well, sort of - they use the remoting ability of X-windows and the
ability to boot Linux from a DHCP/boot/NFS server).

Really, when Mike started this project, he intended for his 'final version' to
be in C and not C++ all along, he just used C++ initially to prototype it.
All that being said, it really is object-oriented still.  There is a sort of
formal structure requiring structures with `constructors', `destructors', and
`methods'.

-Jay 'Eraserhead' Felice

+---
| This is the LINUX5250 Mailing List!
| To submit a new message, send your mail to LINUX5250@midrange.com.
| To subscribe to this list send email to LINUX5250-SUB@midrange.com.
| To unsubscribe from this list send email to LINUX5250-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---