Adam Lang wrote:
>
> I got a bit lost at what you were explaining.  Could you try again for me
> please?
>
> Adam Lang


You are using the AS/400 as a communications pathway, not as a
host. All the 400 does is pass your 5250 conversations in both
directions to the PC server. There's no additional logic or
software on the AS/400. Suppose your pc server is
myserver.mydomain.com . The green screen user does a telnet to
myserver.mydomain.com, and receives a menu (created on the
myserver by the applications programmer, using a simple PC
application).

Each menu item either leads to a submenu, or to a program
function. When it leads to another menu, the myserver displays
that menu. When it leads to a program function, the myserver
looks up that program name in the menu file, and passes it a
session number and whatever startup parameters are needed.

Say the program is 'myprogram1'. Now myprogram1 sends screens
thru myserver that are sent back from myserver to the green
screen user. It accepts input screens through the same
mechanism. The VB program sends a screen, then waits for input.
When input comes, it does a select case based on the last screen
that it sent, to know how to handle the input. Screen layouts
would be created with a Screen Designer and stored in a
database, which could preload into local variables in the
initialization section (or asynchronously triggered by
intitialization or first use of that screen.)

You would probably store returned fields as data fields in a
user type.

Each VB program would talk to one screen, the myserver would
replicate the programs as needed. When the user makes a choice
to end that application, the VB program informs the menu system,
optionally chaining to the next program in a sequence. A Vb
program could do anything you can do on a PC - access a
databases, access the web, print a report, etc.

And of course you could have a simple subporogram that you could
call form a regular RPG program, that would do the
communication. That would be a secondary way of using it,
perhaps to read a shipping scale, or scan a document, or send an
email.

The key is to have enough of an infrastructure so that all the
VB programmer needs to do is minimally program their selected
function, whatever that might be.

Write legacy apps with VB6.

The performance would be great. Unlike a CGI program, that VB
app stays in memory through multiple transactions. The only
thing that might slow it down is if the AS/400 begins to bog
down with a lot of Telnet sessions running. I don't know if it
does or not.

Actually, I think Telenet sessions from a green screen do
trigger CFINT, it would only be if they were from emaulator
screens, and perhaps we could support those remote controllers
that go over TCP/IP.

The purpose of this is not to beat CFINT, the purpose is to be
able to write new and addon applications on a PC that support
5250 (or 3270) terminals.

Does that make it more clear?

--
Brad Jensen brad@elstore.com
President
Electronic Storage Corporation Tulsa OK USA
918-664-7276

LaserVault Report Retrieval & Data Mining
www.Laservault.com

www.eufrates.com - Add distance learning to
your site with easy course preparation


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2022 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.