×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
There is a long story behind all of this, some of it told in a couple of
IMHO articles, which, if you are having trouble sleeping some night,
starts here:
http://imho.midrange.com/2007/06/08/system-i-evolution-part-1/
The original system that we were involved with was a product called CIMS
which had a before-its-time menuing system called ACS (Application
Control System). The menuing system was developed on the S/34 and
migrated and enhanced over the years. Each menu was a subfile of menu
items, each of which was individually defined and pointed to a program
technical definition (also individually defined). The sweet part of
this structure was that the program technical definition would set
things like the library list and program options (switches). Then the
menu items would reference these program technical definitions and the
menu items could control things like whether the program could only look
at data vs a full CRUD. In that way you could have multiple menu items
running the same program but operating very differently. The menus
themselves were assigned to groups and as users were added to the groups
those menus and the items on them would become available. Further, a
specific user could be assigned to menu items so the user would have
both the specific items and the groups menu items available. It made
for a very flexible, easy to manage system.
When we discussed how we could move the 5250 based applications to the
"web world" our first challenge was to design the same, flexible,
menuing system for the web. But, since we didn't have source code to
the original RPG programs we knew we would have a lengthy development
cycle and would only be moving a few key applications at a time to the
web while the users would still be running, by and large, 5250
applications. The problem here was coming up with a "unified" approach
so that the users would have one login to the web based menuing system
and yet could still run the 5250 applications "seamlessly": Without
jumping from a 5250 emulation session back to the browser. I already
was involved with tn5250j so I developed this servlet based application
that would serve up 5250 sessions. The user would log in once, then we
would launch the 5250 session "under the covers" so that the user could
just chose the menu item and run it. Some menu items would launch a
Java servlet based application, some would launch an RPG-CGI based web
application (Nathan Andelin wrote that piece) and some would still run a
5250 application. The users were presented with one menuing system and
were insulated from all the "back end" stuff. It was pretty slick.
web5250 was not used in the final cut because of some of the issues I
have already raised about it. We used tn5250j as an applet, which had
it's own downside, but the users were insulated from the details. They
really couldn't tell the difference between web5250 or the applet anyway
and the menuing system launched all of them pretty seamlessly.
So that is the basics of the solution. The web based menuing system was
using a proprietary framework so I couldn't release it open source
(although I'd love to recreate it in Java and make it available some day).
Again, as soon as I can, I'll package up the source and make it
available (we are making Christmas cookies at the moment so it may be a
few hours before I can get back to it).
Pete
Aaron Bartell wrote:
I have a customer that something like this would be perfect for. They
have been struggling through CGIDEV2 for awhile and going "back to the
basics" of green screen type programming while still getting a browser
presence would probably fit the ticket perfectly. I would have to make
some changes first like not having them start on the OS400 login page
and instead allow them to run programs under a generic profile until
they were ready to sign in, but I don't think that would be too hard. I
would also play with the css some to give it a more "web 2.0" look (to
please the insurance agents that would be using it). There are only
about 50 to 60 users that would be using this 5250 web application on a
spankin new 520 with 4GB of memory - would be interesting to see if the
load was too much if ran under Tomcat.
Pete, did the menu system you created have similar needs to the approach
I described?
Aaron Bartell
http://mowyourlawn.com
Pete Helgren wrote:
I haven't tried to "scale" it. It would probably be similar to having
tn5250j on the desktop with many sessions open. Haven't looked into the
internals of 5250j to see if there are limits. Probably should take a
look at the "expense" of each connection. I only have to deal with one
object in tn5250j, the 5250 protocol bean, all of the other stuff I am
insulated from so it might take some digging to unpack all of the issues.
Much of this was written early on in the AEE development cycle Nathan.
We eventually settled on using the tn5250j applet because it was more
stable and complete. I saw Joe's post about PSC and I wonder if
something very similar to web5250 could be written in RPG. It would
probably be something worth investigating. The biggest issues I had
were with function keys that triggered browser functions, rather than
the 5250 functions but I was a complete noob with Java, Javascript and
css (which could be helpful) so there are probably better approaches I
could take now. I need to blow the dust off of this I guess. I haven't
had much interest in the project although I get a connection or two
under the Demo userid every week.
Pete
midrange.com
