On Tue, 18 Feb 2003, Irving Hutagalung wrote:
>
> Basically, I want to create an application to get information from
> AS/400 through TN5250 protocol. When I browse through the internet, I
> found out about this tn5250. After browsing through the code and the
> docs, my development team is lost =)
>

I think you're going to find that this is more complicated than you think
it is.   lib5250 is a library of functions for writing a 5250 terminal
emulator.

In the package are pre-written emulators for Windows, Curses (One method
of text-only programming in Unix-like environments), SLang (another way to
do Unix-like) and you can get (separately) a GTK+ version (GTK+ = an X11
toolkit)

What you seem to be looking for is a library for interacting with one of
these preexisting terminals, rather than a library for writing your own
terminal.   Something like HLLAPI, perhaps...   Unfortunately, support
like this has not been writing for our TN5250 client.

You could, of course, write your own HLLAPI style support for TN5250...
contribute it back to the project, that would be great.

You could also write your own "terminal" front-end to TN5250.   This would
be easier than adding HLLAPI support, but probably still more work than
what you're expecting.

A better option than either of these, quite frankly, is to not use 5250
support for this.   Simply write a program that runs on the AS/400 side
that listens on a socket, and write a program on the Solaris box that
connects to it.   This would be simpler, more robust, and it would perform
better.   If the application on your AS/400 is "very simple" as you say,
then I really don't see why you aren't doing it this way...

If your AS/400 developer is not familiar with writing sockets
applications, I wrote a tutorial on sockets for RPG programmers here:

       http://www.scottklement.com/rpg/socktut/

> So, need your help to give some hints on how to use tn5250 from another
> application. Basically, the application is a C application in Solaris.
> If possible, I want to use tn5250 as a library to connect that
> application to AS/400. Is this possible? Where should my team start
> looking at the source? Is there any changes required in the tn5250
> source? I prefer not to change anything in the tn5250 code.
>

If you do decide that you must use a "screen scraper" approach for this,
and want to take up my suggestion of writing your own "terminal" front-end
to tn5250...

Start in cursesterm.c, look at the function called
tn5250_curses_terminal_new() You'll see that what this basically does is
create a structure.   In that structure are all of the parts of the
"terminal object" that are called by lib5250.

Take a look at this code:

   r->init = curses_terminal_init;
   r->term = curses_terminal_term;
   r->destroy = curses_terminal_destroy;
   r->width = curses_terminal_width;
   r->height = curses_terminal_height;
   r->flags = curses_terminal_flags;
   r->update = curses_terminal_update;
   r->update_indicators = curses_terminal_update_indicators;
   r->waitevent = curses_terminal_waitevent;
   r->getkey = curses_terminal_getkey;
   r->beep = curses_terminal_beep;

These are all functions in that same source member.  They are assigned to
the structure.   lib5250 will use them as "callbacks" it calls them when
the appropriate event occurs.

So, you'd need to write your own routines to supply here...
Your version of the "terminal_update" function would probably simply query
the data that's in the display buffer to determine which screen you're on,
etc.   Save the appropriate keystrokes into a buffer.

Then, when curses_terminal_getkey is called by lib5250, supply the next
keystroke that you want to send to the terminal.

Aside from cursesterm, the other source file that you'll be interested in
is tn5250.c itself.   All this does is the basic setup... it assigns the
correct "terminal object" to lib5250, as well as other things.   For your
purposes, you'll probably just want to make your own copy of it, and
change it to use your "terminal object" instead of using
cursesterm/slangterm.

Of course, in both of these cases, you'll use your own code -- in seperate
source files -- and not modify the existing cursesterm.c or tn5250.c.
Just by making your own version of these two source files, you should be
able to do what you want to do...  just link them against lib5250

Also, your routines could call the appropriate curses/slang/gtk/windows
routines if you want the resulting screens to be displayed to the user
as they happen.   in this case, your code would be like a "layer inserted
in between the terminal and the 5250 library"

Also, you can skip the sign-on screen altogether by supplying

env.USER=<userid>
env.IBMSUBSPW=<password>
env.IBMCURLIB=<initial library>
env.IBMIMENU=<initial menu>
env.IBMPROGRAM=<program to call>

in your TN5250 configuration.   This will sign you on as the given userid
& password, skipping the sign-on screen completely.    Just keep in mind
that if you save this in a config file, anyone with access to read that
file can see the user/password.   And it's also sent over the network in
plain-text (unless you're using SSL)....   but that's true of the
keystroke method as well.

> To give more background, the application that resides in the AS/400 is a
> very simple application. The AS/400 developer already creates an
> application for my team, which requires very little screen interaction.
> In fact, the "screen" is used only to receive data and to send data. So,
> don't think of this screen as a "normal screen". The data itself will be
> in the form of fixed-length format.
>
> If done using a "true" TN5250 terminal emulation (I've tried this using
> tn5250 running on Windows XP), this is what I do (human interaction):
> 1. connect to AS/400, using the workstation ID, user ID, and password
> 2. a blank screen will be shown
> 3. I type the data (example: "GET12345BAL", which means "Get (GET)
> balance (BAL) for account number 12345") and press enter.
> 4. the screen will be changed to the reply message (example:
> "GET12345BAL  135", which means the account balance is USD 135).
>
> So, my application need to:
> 1. connect to AS/400
> 2. send the keystrokes with the appropriate format.
> 3. get the screen content to get the reply.
>

Yep.  Again, you can do it the way I've outlined above.   But, I'd really
recommend writing a direct communication between a solaris program & an
OS/400 program using sockets.


> I've run through the archive of this mailing list (at least for the
> recent message up until August 2002), and only found the following
> related messages:
> http://archive.midrange.com/linux5250/200210/msg00007.html
> http://archive.midrange.com/linux5250/200209/msg00020.html
>

Yes, there has been some interest in this, but nobody yet has implemented
it to my knowledge.


This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].