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 firstname.lastname@example.org 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.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.