View Full Version : Converting an MRT chat application to ILE RPG on AS/400
Guest.Visitor
01-01-1995, 02:00 AM
I have an RPG/II MRT application that runs in the S/36 environment that I would like to rewrite in ILE RPG, but cannot find any documentation on doing so. This is an unusual application. It is essentially a chat program, with some other industry specific features. In the s/36 environment, the first user to call the program starts the MRT job. All subsequent calls to the program attach to the MRT job. All users share the same display file and see the same inforamtion. Anytime a user updates a display file record, the program writes the new record to every workstation that is attached. I am trying to determine the best way to develop this application in the native environment. I have tried using a multiple-device display file, and having the program acquire the devices that need access. The problem with this solution is that the display station device cannot be acquired unless it is signed off. Has anyone ever written an application like this? Any help would be greatly appreciated.
J.Pluta
10-19-2000, 08:23 AM
Just off the top of my head, I would immediately lean toward a data queue approach. Each user that logs in registers a data queue, and whenever a message is sent, it is broadcast to all the registered data queues. You would have a (relatively short) timeout on your display file read, and whenever the read timed out, you would check for more messages. It gets murky here, but I think you can somehow combine a wait on a display file with a wait on a data queue; if that's indeed the case, you could ue the data queue that you registered as your timeout data queue, then your timeout could be indefinite. Joe http://www.java400.net http://www.edeployment.com http://www.plutabrothers.com
Guest.Visitor
10-19-2000, 08:35 AM
Joe, Thank you for your insight into this problem. That's a great idea! I will look into a data queue solution. Thanks for your help.
Guest.Visitor
10-19-2000, 12:45 PM
Jim, MC Mag published back on July, 1997 such utility "Using Data Queues to Spice Up your Applications" HTH
Guest.Visitor
10-20-2000, 02:14 AM
I'm always interested in new TLAs. MRT = ? bobh
J.Pluta
10-20-2000, 05:46 AM
MRT=Multiple Requesting Terminal, the original interactive interface for the IBM midrange platform (the good old System/3 model 15D running CCP). In fact, what you wrote was a NEP-MRT, (Never Ending Program, Multiple Requesting Terminal). The idea was that you allowed multiple terminals to "login" to your application. The application did an "INVITE" on the display file, and then waited for any old terminal to attach to the application and make a request. Once it did, it got its own set of indicators, etc., and you used these each time that terminal made another request (that is, each time the end user hit enter or a command key). These were stateless programs in the sense that the session state was restored for each request - very similar to the concept of HTTP requests today. The more things change, the more they stay the same. Joe http://www.java400.net http://www.edeployment.com http://www.plutabrothers.com
nycsusan@hotmail.com
10-20-2000, 05:48 AM
What does "TLA" stand for? Term? ?? ???
J.Pluta
10-20-2000, 06:19 AM
TLA is a three-letter acronym for... Three-Letter Acronym. <grin>
G.Gaunt
10-20-2000, 06:36 AM
Multiple Requesting Terminal programs were slick, except when one user caused a flashing keyboard error. Until the offending user pressed Error Reset, all other attached workstations would lock. Ouch.
Guest.Visitor
10-20-2000, 09:43 AM
Sounds a whole lot like what we called re-entrant code. ?? bobh
J.Pluta
10-20-2000, 09:58 AM
I actually was going to use the word "re-entrant", Bob, except that there's a fundamental difference: with MRT, all the logic for the session is executed before turning control over to another terminal, whereas with re-entrant code, two tasks could be simultaneously executing the same code. In order to accomplish that latter feat, you had to make sure all of your working storage was in an isolated chunk of memory and was accessed by a register specific to the task. The Series/1 was especially good at this - the HLL for the Series/1 (EDL) actually supported two registers (called #1 and #2) which could be used to reference data in re-entrant code. Since RPG has global variables, an MRT would walk all over itself if two tasks were allowed to run simultaneously through the code. Joe http://www.java400.net http://www.edeployment.com http://www.plutabrothers.com
Guest.Visitor
10-20-2000, 12:43 PM
Three Letter Acronyms as opposed to FLAs. bobh
Powered by vBulletin® Version 4.1.5 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.