Product Alert - Progen WebSmart
Chuck Ackerman
In the past couple of years the guys at BCD have been asking me to try out
WebSmart, their Progen-like product for generating web pages to access
AS/400 data. I hadn't found a real need until now.
We have been installing kiosks in our stores to present the many products
that we can't display in the stores to our customers. The kiosks are a
great success allowing salesman to sell more products than they can display
on the showroom floor. The one requests that I've been getting from the
store sales people is that they'd like to see stock availability in other
stores and in the corporate warehouse while browsing the web site.
This is a valid request but our availability data is on the AS/400 and I
didn't want to install CA/400 on the kiosks. CA/400 presents a security
risk and it would take away from the browsing experience.
Now, suddenly, I had a need to present AS/400 data in a browser. I looked
at Websphere but it's costly and cumbersome to maintain. I looked at CGIDEV
and actually created some pages using it. But it's still very labor
intensive from a programmer's standpoint.
Then I looked at WebSmart. I actually loaded the product, ran though the
tutorial AND, get this, had my availability web page up in running in a
single morning! This product is nothing short of amazing. I'm hooked and
don't want to look back. By the end of the second day I had created a P.O.
for BCD for WebSmart.
I'd recommend this product to any AS/400 programmer. It's fast to learn,
the response time in screens is sub-second and the results look polished
right out of the box.
You can get for 30 days for free. Give it a try.
I have no affiliation with BCD or Excel Systems whatsoever.
chuck
Opinions expressed are not necessarily those of my employer.
Nathan M. Andelin
Normally there's a learning curve for program generators like
Websmart. But you were able to build a program in one morning. Is
that because of your 10 years of experience with Progen?
Like programmers themselves, Program Generators rely on templates for
productivity. Let's say you already had an RPG template to check
availability of a product and output a Web page. As a programmer,
wouldn't you be able to modify the RPG template and build the program
in one morning?
BCD offers http://www.mytradingcards.com as a demo of the types of
applications that you can generate with Websmart. But the response
time for browsing the card list is 2-3 seconds per page. Using
Relational-Web in conjunction with RPG to generate an HTML list, I'm
more accustomed to 1/10th the response time, even from a small AS/400
model 170-2290, and over the Internet. Do you really think that
Websmart provides an efficient interface to your data?
Nathan M. Andelin
www.relational-data.com
Martin Brieger
Chuck you had a chance to test it.
All one had to do was selecting the database and fields and do a tad bit of
HTML and that's it.
No big deal and, sorry, but BDC only cooks with water too.
Same applies for any kind of code generators or version control tools. Too
many folks think they are a big secret
Chuck Ackerman
While Progen and Progen Websmart share the same name they really aren't
alike. My experience with Progen didn't help me with WebSmart except that I
had an expectation of an excellent product and excellent customer support.
I wasn't let down.
Also, unlike Progen where you always work within the template framework,
WebSmart only builds the initial program from the template. After that you
work entirely within the Websmart IDE and use it's Progen Macro Language
which is very CL-like in it's commands.
Websmart allows you to call any existing program from within Websmart. So
if you have existing routines they will work just fine with Websmart. Also,
everything that Websmart creates is ILE RPG and in modules. You can
register functions that you create within your programs and get at these
functions directly from other programs.
Plus, since Websmart runs a companion program directly on the AS/400 when a
page is requested there is no never-ending server programs, per se. Each
page is populated by an individual program and then the program ends.
My response time on web pages with about 50 detail lines is almost
instantaneous. There's no equivalent of wrkactjob so I can't tell you the
exact response time but it's fast, very fast. In fact, the screen painting
is as fast as a PC5250 screen. So, to answer your question, yes I do
believe that Websmart is an efficient interface to my data.
chuck
Opinions expressed are not necessarily those of my employer.
"Nathan M. Andelin" <nand...@relational-data.com> wrote in message
news:847c9298.02070...@posting.google.com...
Chuck Ackerman
I agree wit you that there's no big secret to program generators like Progen
or Progen Websmart. They just make knowledge workers more productive. My
staff is very sharp and I want them to spend more time developing solutions
and less time, much less time, writing code.
My analogy is this: Writing RPG code is akin to riding a bicycle. Writing
Progen or Progen Websmart is like driving a car. Both do the same thing and
there's no big secret to driving a car, it just gets you to your destination
much faster while the driver doesn't have to worry about all of the hills
and pot holes.
chuck
Opinions expressed are not necessarily those of my employer.
"Martin Brieger" <Martin....@mbsoft.nu> wrote in message
news:3d2a...@p100.mbsoft.nu...
Chuck Ackerman
Agreed. Both McDonalds and Emeril Lagasse use water, but I can tell you
which one I'd enjoy more.
Nathan M. Andelin
I had an opportunity to exchange a few email messages with some of
people at BCD. They seemed like intelligent and thoughtful people.
It doesn't surprise me that they offer a quality product with
excellent support.
On the other hand, I find the frameworks that support program
generators to be constraining in many situations. I prefer the
freedom of structuring applications according to functional
requirements rather than pre-defined models supported by the code
generator.
Another question. Does Websmart generage HTML as well as RPG code?
To address the productivity concern, I base new programs on templates
that are similar to what I need to accomplish, and store commonly used
procedures in service programs. With a good set of program templates,
and service programs, a programmer will eventually become as
productive as a person who uses a code generator. More importantly,
the programmer will think outside the box, and will be useful at
solving unusual problems.
It surprises me to hear that you see performance from a CGI program
that's comparable to 5250. Are you sure you're not just seeing a page
that was in the browser's cache? The reason I ask, is because the
Websmart demo at www.mytradingcards.com doesn't immediately expire the
pages that it downloads. For example, you may click the [Previous]
link, but the resulting page is displayed from the browser's cache,
rather than calling the CGI program to create the page. That wouldn't
work for most business applications because the database may have
changed in the meantime.
CGI is a great interface for programs that are called occasionally.
But it becomes terribly inneficient as the number of programs increase
and the number of users increase. Calling a program is much less
efficient than sending a stream to one that's already active. One of
the reasons that 5250 is so efficient is because the program is active
during the dialog with the user.
To avoid the overhead of program initialization, some CGI programmers
run their programs under named activation groups. That temporarily
improves performance by causing the program to remain active between
calls. Over time, multiple instances of each program become active.
For example, if your HTTP Server is configured to support 40
concurrent connections, and your application consists of 100 CGI
programs, then 4,000 programs will become active, eventually. And
they remain active. The only way to unload them is to shut down the
HTTP Server.
For these reasons, CGI is not a very good architecture for the demands
of robust, highly interactive applications.
Nathan M. Andelin
www.relational-data.com
Chuck Ackerman
some of people at BCD. They seemed like intelligent and thoughtful people.
"
I've been in the I.T. business since 1975. All of it in the decision making
capacity at the companies I worked for. And, I can say this without
hesitation: Excel Systems (the makers of the BCD products) have the best,
by far, customer service of any vendor I've dealt with. They always answer
the phone on the first ring, never put you on hold, and the person at the
other end thurougly knows the product and can help you. If they can't solve
the problem or answer the question immediatly, they work it through until
it's solved.
-----------------------
Nathan also said: "On the other hand, I find the frameworks that support
program generators to be constraining in many situations. I prefer the
freedom of structuring applications according to functional requirements
rather than pre-defined models supported by the code generator."
First of all, both Progen and WebSmart allow a programmer do absolutely
anything they can think of. I know, I've been using Progen since 1990.
Progen is nothing at all like the "heavy" CASE tools of yesteryear.
Anything can be accomplished within the template of Progen including, if
necessary, writing custom RPG ILE code. However, I've found that in 99.% of
the time Progen will do everything necessary. And, the other 0.1% of the
time when I wrote my own code within Progen I actually found out later a way
to do the same thing within Progen.
-----------------------
Nathan also said: "Another question. Does Websmart generage HTML as well as
RPG code?"
Yes and no. When you first create the program using a template it will
generate the HTML at that time. However, once the program is generated you
are free to modify the HTML to your heart's content. In fact, the HTML
could easily be maintained in FrontPage, Dreamweaver, etc.
-----------------------
Nathan also said: "With a good set of program templates, and service
programs, a programmer will eventually become as productive as a person who
uses a code generator. "
I agree that what Progen buys is time. However, I don't necessarily agree
that the programmer's techniques or abilities would match them. The RPG/ILE
code that Progen and Websmart generate are extremely well documented and
very complete. I consider myself a talented programmer (have a degree in
Computer Science from UCLA, know 19 languages, well read on programming,
etc.) but I've learned a lot just by being curious and looking at the
generated code. And you know what else: I hire programmers. The number of
AS/400 programmers that actually know about modules, procedures, etc. is so
small that if you left your templates would be worthless. A new programmer
would pick up Progen or Websmart than they would modules and procedures,
etc.
I also know that any program I create in Progen will work First time and
Every Time without bugs! I can now debug my business rules instead of being
mired in program syntax and logic rules.
Sure, not everything can be done in Progen, we've got lots of legacy stuff
that must be maintained "the old fashioned way." But programming in RPG/ILE
can be very tedious and time consuming. Do you use a manual screwdriver or
a powered one? I hope your answer is "both" depending on the job. Same
analogy here.
-----------------------
Nathan also said: "More importantly, the programmer will think outside the
box, and will be useful at solving unusual problems."
I want my programmer to be an analyst as much as possible and a programmer
as little as possible. If they have to think about RPG syntax then that
inhibits them.
-----------------------
Nathan: "It surprises me to hear that you see performance from a CGI program
that's comparable to 5250. Are you sure you're not just seeing a page that
was in the browser's cache?"
Nathan, give me credit here, OK? I'm not a bafoon. The program asks for an
item number and shows inventory in 50 stores. It's that simple. Each time
I enter a different item number, each time it gets information from 5 files
for each of the 50 lines. And each time the response is instantaneous.
-----------------------
Wait, hang on a second. I want to try something...
Ok, I'm back...
I opened Websmart and created a program to list all of the records in the
customer master file. Total records 7,200. I figure this would be a good
example since the program would be new and data isn't cached.
Time to generate the template, generate the ILE program and compile the
program: 1 minute 40 seconds.
I went to Internet Explorer and entered the URL for my new CGI web program.
Time from pressing enter until all 7,200 lines were shown in my browser: 8
seconds.
That's very acceptable response time. In fact, that's better than a 5250
display since they'd have to press page down 400 times to get all 7200
records (18 records per page).
-----------------------
Nathan said: "CGI is a great interface for programs that are called
occasionally. But it becomes terribly inneficient as the number of programs
increase and the number of users increase. "
I have two responses:
1. That doesn't concern me in this instance. Anything we do with Websmart
will be for internal use only. Our AS/400 is never exposed to the Internet
so the number of users won't be large. Under 1,000.
2. 1. Boy, I'm not sure what number you suggest is large enough for CGI to
be inefficient. Our main ecommerce web site is written entirely in VBScript
which uses server side CGIs (ASPs) running on a single Compaq 1.2ghz CPU
using Win2K and IIS. That thing can support many hits per hour. I think
it's been up to 10,000 unique visitors. It handles all of our e-business
with MS Access database and calls directly to the AS/400. My HTML group
uses ASNA datagate to get at the AS/400 and like Websmart it's fast, very
fast.
So, if a Compaq server can handle thousands of connections per minute,
certainly my AS/400 model 720 can bear the load of internal kiosks.
-----------------------
Nathan also wrote: "Calling a program is much less efficient than sending a
stream to one that's already active. One of the reasons that 5250 is so
efficient is because the program is active during the dialog with the user."
Are you suggesting that it would be efficient to have a "stateful" connect
to the end user? I'm not an expert on the Internet but everything I read
says that for any volume "stateless" is the only way to go. Could you
imagine if Microsoft were to keep open millions of connections at once?
-----------------------
Nathan, I'm not suggesting that Websmart is the panacea for web programming.
But I AM suggesting it is very efficient, very fast and very easy to use. I
don't have the time or inclination to build a reservoir of personal code
that I KNOW wouldn't be as good as what Websmart or Progen builds.
fbloggs
Thanks for the interesting discussion ! Chuck, thanks for the vigorous
defence of WebSmart. A few points concerning developing in WebSmart,
versus Nathan's approach:
WebSmart has:
-PC based design tool -Full featured HTML tool - drag and drop database
fields, right-click to add edit codes/words
- text-based HTML tool with code snippets, color-coding, realtime
HTML syntax -checking, previews in favorite browser -WYSIWIG HTML
tool also.
-Full-featured web programming language with C, Java or VB-like syntax,
with: -color-coding -F1 prompt for context-sensitive help on any
function -realtime syntax checking -auto-indention of code for
readability -extensible language (code your own functions on the server
side, if you wish, to leverage legacy RPG code
- Central repository for defining business rules and user-interface
standards (eg: attach a drop-down box to a field in the repository-
this can then be automatically included on any page referencing that
field.) A word about Nathan's model for web apps versus WebSmart's
-My understanding is that his product uses data queues with an
intermediary program that sends /receives data on those queues to
backend programs .
I presume (correct me if I'm wrong, Nathan): These backend programs must
run in separate jobs These programs are, as Chuck pointed out,
'stateful' - not a good model for browser-based apps. At some point, if
a user surfs to another link not at the server, those jobs must have to
time out. Ultimately, the program that handles sending messages back and
forth to his batch programs must be a CGI program !
This approach simply adds another layer of performance bottleneck to the
process, and tries to emulate the 5250 model of stateful interaction,
which is really quite inappropriate for Web applications, IMHO.
You can also read about this approach in a book published by Midrange
Computing called E-Deployment.
Now, Nathan's tool, based on the User's Guide at his website:
Uses SEU as the Editor (no color coding, incomplete syntax checking (eg:
what if a field name is undefined) , no auto-indention, requires a
green-screen session etc.) Uses RPG and his API's - again, no realtime
syntax checking that you've coded the calls to his API's correctly.
Usually, this approach to development requires compile, correct your
errors (oops! what about that 7030 error !) , compile again, correct
your errors (Oops ! I passed an incorrect data type to a function!) ,
etc. etc. Then debug.
Deployment requires his server programs running in the background- for
example, a quote from his documentation on session support:
"Our session support requires that program "RDCOLSVR" be running.
This server is automatically started by the STRRELWEB command, and
uses the following files: COLTYPE, COLATTR, COLFLDS, and COLDATA"
(from his API manual).
Presumably, this program uses up some system resources ? WebSmart
requires no such program to run- it just uses the HTTP server.
Nathan appears to have no HTML editing capability in his tool. I'm
not sure how you specify place holders for database fields that are
to be embedded in the HTML , but I'm sure it's not as simple as
dragging and dropping a database field name onto an HTML editing area
in a PC-based IDE.
Anyway, this is just a cursory look at his approach. I invite the reader
to try WebSmart for free. ( http://www.progenwebsmart.com ) I'm
confident you'll be convinced that WebSmart is a robust, secure,
scaleable, efficient and fast-performing solution that will make you
highly productive.
--
www.MainFrameForum.com - USENET Gateway
fbloggs
Duncan Kenzie President, ExcelSystems Software Development Inc.
Nathan M. Andelin
If I ask for a point of clarification, I'm not challenging anyone's
intelligence. There's no need to list your qualifications. I have never
worked with Progen products, nor reviewed the documentation. So my opinions
are generalizations, based on other products that I'm more familiar with. I
believe that code generators have a place in many IT departments. Please
don't take my remarks too personally.
To clarify, Relational-Web doesn't use a CGI interface. Actually, neither
does Microsoft's ASP product. Microsoft says that would be too slow, and
unscalable. Microsoft wrote a plug-in, using the ISAPI APIs to provide a
message interface between IIS and ASP.
IBM also uses the plug-in technique to provide a message interface between
the HTTP Server and its Websphere Application Server. Similarly,
Relational-Web implements a plug-in that runs within the OS/400 HTTP Server
itself, and provides a message interface between the HTTP Server and RPG
programs.
In contrast, OS/400 CGI requests are forwarded to BCI jobs that are started
by the HTTP Server. In just testing a "Hello World" response, I found a
plug-in to perform five (5) times faster than an equivalent CGI program that
runs in a named activation group, and twenty five (25) faster than one that
uses a new activation group. Using standard IBM APIs. If that matters.
In a Web environment, I am suggesting that passing a message to a program
that's already running is much more efficient and scalable than calling a
program directly. Please don't confuse that with "stateful" connections.
While 5250 offers a stateful connection, the program is unloaded when the
user returns to the menu, unless designed otherwise.
In contrast, CGI programs running in named activation groups are not
unloaded, until the HTTP Server is shut down. Every instance of any program
that was ever started by the HTTP Server remains active, although the
browser may have dropped the connection. Combine robust applications with a
multi-user environment, and it's like a continuous memory leak. It's a
worst case proposition. The program remains active and doesn't even
maintain state for the user that started it.
Relational-Web, Websphere Application Server, and Microsoft ASP are good
examples of stateless environments that operate on the principle of a
message interface. They offer APIs to store and retrieve session data in
order to to track individual user state.
CGI offers one thing in common with Java Servlets and ASP scripts. The API
leads to components that are scoped to handle only one type of request. A
file maintenance application that offers a browse function, followed by
options to locate, add, modify, delete, and copy records will likely lead to
a dozen or more separate CGI modules. That's neither efficient on computer
resources, nor easy for a programmer. It's no wonder that so many Web
applications lack robustness.
Without going into a lot of detail here, Relational-Web makes it easy for
programmers to properly scope their applications to maximize efficiency, and
maintainability.
Apparently, based on Duncan's remarks, Websmart offers a robust PC based
development environment, and its own programming language. While I
appreciate the amount of work that it takes to put a product like that
together, I chose to focus on a procedure library, because IBM, Microsoft,
and a lot of huge companies were offering source editors, HTML editors,
programming languages, and such.
Although Windows development environments are neat (I spent 5+ years of my
career developing Windows applications), I found RPG + PDM to be the most
productive, overall, for me.
Nathan M. Andelin
www.relational-data.com
Chuck Ackerman
I appreciate your response. I also appreciate that once you learned more on
how Websmart worked you backed off and started talking in "generalities"
instead of taking Websmart to task. Smart move, should have done it
earlier!
A few clarifications.
You said: "In contrast, CGI programs running in named activation groups are
not unloaded, until the HTTP Server is shut down. Every instance of any
program that was ever started by the HTTP Server remains active, although
the
browser may have dropped the connection. "
Again, a generality that doesn't pertain to Websmart. Had you downloaded in
the trial version of Websmart you could have seen in the manual that after
the page is displayed the CGI program ends.
You also said: "CGI offers one thing in common with Java Servlets and ASP
scripts."
If Java servelets are a better solution then I understand that Websmart can,
optionally, generate Java instead of RPG/ILE. I have no desire to do that,
however.
I was wondering why you jumped all over Websmart when this thread started
without having even looked at the manual, but I realize now that you make a
competing product. IMO, it would have been better to take the high road and
tout one's own product than trying to discredit another product.
Nathan M. Andelin
You seem to have confused the architecture of Relational-Web with Joe
Pluta's E-Deployment design. To clarify, ILE programs that use the
Relational-Web API don't implement the stateful model that was
proposed in Joe's E-Deployment book.
In contrast to the E-Deployment interface, a single running instance
of a Relational-Web application would support multiple concurrent
users. A good example of this is the Chat area at my Web site.
Although one hundred people may be connected to the HTTP Server,
chatting with each other concurrently, message or page refresh
requests for all users would be handled by only one instance of the
Chat program.
If the Chat area needed to support two hundred concurrent users, then
maybe I'd start another instance of the Chat server to balance the
workload.
Relational-Web applications are not called from an HTML link. Like
the HTTP Server itself, Relational-Web applications are started by an
operator, or may be started in conjunction with a system IPL. You can
specify the number of instances to start. If an operator wants to
take down a Relational-Web application, to back-up a database (for
example), there's a command for doing that. While the application is
down, the HTTP Server Plug-In will return an appropriate response to
any browser that requests that application.
Relational-Web applications, like CGI, may rely on cookies or query
string parameters to track individual user state. But a better
alternative is to use the Session API to store state variables on the
server, rather than pass them back and forth between client and
server, over the course of a dialog. The stateful model was really
designed to make programming easier, which it does. Each user is
connected to a separate running instance of the program. The
programmer doesn't need to worry about tracking individual user state.
Although Relational-Web doesn't use this model, I think it's quite
good for most interactive applications. It's simplicity leads to
robust applications. It's nice to load a program from a menu, only
when needed, and unload it when the user returns to the menu. However
today's browser's were designed with stateless connections in mind.
Under most operating systems, CGI is horribly inneficient. OS/400
addresses the concern about CGI program initialization by supporting
activation groups, which enable the program to remain active after the
1st call. Unfortunately, there's no effective way to manage the
number of program instances that become active over the course of
time, and there's no effective way to shut them down, other than to
take down the entire HTTP Server. In contrast, stateful nterfaces,
like E-Deployment and 5250, at least unload the program, when the user
returns to the menu.
In my opinion, the appropriate use of CGI is for programs that are
called occasionally, at sites that don't get much traffic. Which
admitedly applies to many sites.
CGI would not be an appropriate interface for a Chat area, for
example. If multiple users were connected to the HTTP Server, the
HTTP Server would start multiple instances of the Chat program.
Depending on the speed of the processor, and the refresh rate of the
messages, it could lead to many active instances of the Chat program.
Even after all the user's left the site, all program instances would
remain active.
Although a product like WAS has tremendous overhead, IBM can probably
accurately claim that it's more scalable than CGI, because the Servlet
Engine never starts more than one instance of a Servlet. The Servlet
Engine just queues new requests until a thread is available. Then the
thread synchronizes calls to the Servlet's appropriate service method
when it's available. If I understand correctly.
Relational-Web is even more efficient and scalable, because the
request is routed directly from a thread in the HTTP Server to the
queue of the application, without the overhead of an application
server. In addition, an operator can choose to start more than one
instance of a Relational-Web application. The Websphere alternative
would be to start another instance of WAS, and front-end the
configuration with a load balancer. If I understand correctly.
Nathan M. Andelin
www.relational-data.com
Chuck Ackerman
Help me understand...
You said: "If multiple users were connected to the HTTP Server, the HTTP
Server would start multiple instances of the Chat program. "
I have been raised in the S/38 and AS/400 world. And in the 22 years that
I've used it IBM has always touted that ALL programs on the AS/400 are
reentrant. That is, a program is NEVER loaded into memory more than once.
When multiple users are using the same program only a second set of
variables is created. Are you saying this all changes in activation groups
and HTTP server?
Nathan M. Andelin
Pointed questions sometimes foment lively discussion. But it's apparent
that you've interpreted some of my questions or comments differently than I
intended. I'm not sure how I offended you. Perhaps you could email me
privately. I may be able to clear the air.
I looked for a copy of the Websmart documentation at their Web site, but
didn't find it. I haven't requested a copy of the software because I've had
other priorities, plus many Wintel development environments won't run on my
underpowered laptop ;-)
It's interesting that you say that Relational-Web competes with Websmart.
It seems to me that Websmart competes with Lansa, Cool, and various Wintel
based products. Relational-Web isn't a code generator. It's not a
language. It's not a tool for authoring HTML. It's not a repository of
business rules and other objects.
Relational-Web is mostly a collection of callable procedures, designed for
ILE programmers. A Tutorial and API Reference are available at my Web site.
People who use Relational-Web pick their own HTML editors, program editors,
and such. It seems to me that Websmart could rather easily generate an RPG
program that implemented calls to Relational-Web procedures, and if it did,
the resulting application would be more scalable than one that implemented a
CGI interface.
Occasionally, I point out deficiencies in CGI architecture, for example,
because I associate with people who have deployed e-commerce sites with CGI,
only to find them to be unscalable. Then they assume that the iSeries is an
overly-expensive, underpowered platform for hosting Web applications and
move to perhaps a Wintel platform, although Relational-Web provides a
scalable alternative to CGI.
But you seem to think that Websmart can control whether a CGI program will
remain active, or not. Actually, that's a function of the HTTP Server, and
the activation group that the program runs under. Unless *NEW is specified
for the activation group on the CRTPGM command, the CGI program will remain
active, because it is called from an HTTP Server BCI Job, which remains
active. Agreed?
Nathan M. Andelin
www.relational-data.com
Marc
If I may enter the fray on a technical level:
<disclaimer>I'm a developer for WebSmart and work for ExcelSystems
Software Dev Inc</disclaimer>
On 11 Jul 2002 09:25:33 -0700, nand...@relational-data.com (Nathan M.
Andelin) wrote:
>In a Web environment, I am suggesting that passing a message to a program
>that's already running is much more efficient and scalable than calling a
>program directly. Please don't confuse that with "stateful" connections.
>While 5250 offers a stateful connection, the program is unloaded when the
>user returns to the menu, unless designed otherwise.
>
>In contrast, CGI programs running in named activation groups are not
>unloaded, until the HTTP Server is shut down. Every instance of any program
>that was ever started by the HTTP Server remains active, although the
>browser may have dropped the connection. Combine robust applications with a
>multi-user environment, and it's like a continuous memory leak. It's a
>worst case proposition. The program remains active and doesn't even
>maintain state for the user that started it.
I would suggest that there is not much difference between the model
you describe and the HTTP server with the use of named activation
groups. In both implementations it seems to me the program remains
loaded. In both implementations you have control over how many
instances of the application are launched. You almost seem to imply
that there is no control over the HTTP server in its launching of
additional jobs (which are left running) but this is not the case. If
you only want one instance of the application to be loaded, then that
can be accomplished with the CHGHTTPA command.
Having said that, the HTTP server does allow you to specify a minimum
and a maximum of jobs to run, such that if you want to have at least
one job running but up to three should user load demand it, you can do
so (it will automaticall launch the additional jobs when needed). You
are correct (AFAIK) in that it does not automatically kill the jobs
once the demand no longer warrants it, but from what I understand,
your model does not provide a mechanism to kill the server jobs
automatically once they are no longer needed either and I believe you
mentioned that operator intervention would be required to start a
second instance if one was needed? (correct me if I'm wrong)
>CGI offers one thing in common with Java Servlets and ASP scripts. The API
>leads to components that are scoped to handle only one type of request. A
>file maintenance application that offers a browse function, followed by
>options to locate, add, modify, delete, and copy records will likely lead to
>a dozen or more separate CGI modules. That's neither efficient on computer
>resources, nor easy for a programmer. It's no wonder that so many Web
>applications lack robustness.
There is no technical reason why different operations must be coded as
different CGI modules any more than there is in traditional
green-screen programming... <plug>Standard WebSmart programs group
all the functionality you describe into a single module (although you
have the freedom to split or conglomerate operations as much as you
want).</plug>
>Without going into a lot of detail here, Relational-Web makes it easy for
>programmers to properly scope their applications to maximize efficiency, and
>maintainability.
Someone commented earlier that we are all cooking with water and I
guess I would have to reinvoke that here. It seems to me there are
generally two options when invoking a program:
1) Load (or preload) and keep in memory. In this case subsequent
calls are much faster, but more system resources are used.
2) Load and discard. In this case performance is slower, but less
system resources are used.
I don't know if you're willing to go into technical detail but it
seems to me your model must either keep its modules loaded, or must
discard them, so ultimately it's a trade-off between memory resources
and processor resources is it not? At what point does your model load
a particular program? At what point does it discard it from memory?
<plug> It's worth noting that WebSmart allows you to control whether
the module is kept loaded or discarded on a per-module basis, allowing
you to keep frequently used modules in memory, while discarding those
less frequently used. So the statement "Every instance of any program
that was ever started by the HTTP Server remains active, although the
browser may have dropped the connection" is not technically true
(though it can be true by programmer choice).</plug>
Rgds,
Marc
<disclaimer>Opinions expressed are not necessarily those of my
employer</disclaimer>
Chuck Ackerman
program will remain active, or not. Actually, that's a function of the HTTP
Server, and the activation group that the program runs under. "
I've got a lot to learn and I'm glad we've had this discussion. Please help
me understand some more.
If what you say is true then when a program sets on *INLR it is not then
unloaded from memory under the HTTP scenario. Am I understanding you
correctly? The Websmart manual says that LR is seton and the program ends
after a page is displayed, but you indicate that Websmart has no control
over the CGI program and it can't do such a thing. Is this a Paradox?
Nathan M. Andelin
> I've used it IBM has always touted that ALL programs on the AS/400 are
> reentrant. That is, a program is NEVER loaded into memory more than once.
That's basically my understanding too. That every instance of the
program points to the same memory location for execution instructions.
But that individual program instances are defined by internal OS/400
control structures.
> When multiple users are using the same program only a second set of
> variables is created.
Static variables, open data paths, commitment control definitions, SQL
cursors, pointers to system objects, control structures, etc.
CGI programs also use quite a bit more memory than traditional
programs, partly because HTML streams are relatively large.
> Are you saying this all changes in activation groups
> and HTTP server?
No. I'm basically saying that the dynamic elements that define a CGI
program are now scoped to the activation group. The activation group
is owned, in this case, by the HTTP Server BCI Jobs, and that those
jobs remain active.
I've had discussions with CGI programmers who complain that by the end
of the day, the AS/400 would slowed to a crawl and the disk would be
thrashing. The temporary cure would be to shut down the HTTP Server,
and restart it.
When the HTTP Server starts, you'll see a small number of BCI jobs
that start with it, four (4) in most cases. Those jobs will support
four (maybe a few more) concurrent CGI connections. More BCI jobs
will be started as more connections become active. Once started, the
BCI jobs don't go away. If your application consisted of 100 CGI
programs, then over time, an instance of each one of your programs may
be active in each one of the BCI jobs.
Unless, of course, you specify *New for the activation group parameter
on the CRTPGM command, in which case your system will suffer from
program initialization overhead.
But that may be trivial on a low traffic Web site, or one that runs
only a handful of CGI programs, or if the CGI programs offer minimal
functionality.
Web Masters complain that when a site visitor repeatedly clicks on a
CGI link, the HTTP Server starts a new set of BCI Jobs, and each one
of those jobs has activated a new instance of the CGI program.
Hope this helps.
Nathan M. Andelin
www.relational-data.com
Nathan M. Andelin
> a page is displayed, but you indicate that Websmart has no control
> over the CGI program and it can't do such a thing. Is this a Paradox?
My understanding is that *INLR = *ON will close files. But that
static variables, and a multitude of control structures, and other
system objects allocated by the program remain allocated, as they're
scoped to the activation group of the BCI Job. They get deallocated
when the activation group is deleted, when the BCI Job ends.
However, proponents of IBM's Easy400 CGI product, for example,
recommend that *INLR remain *OFF, when the program returns, in order
to improve performance.
Nathan M. Andelin
www.relational-data.com
Francis Lapeyre
"Nathan M. Andelin" <nand...@relational-data.com> wrote in message news:847c9298.02071...@posting.google.com...
> I looked for a copy of the Websmart documentation at their Web site, but
> didn't find it. I haven't requested a copy of the software because I've had
> other priorities, plus many Wintel development environments won't run on my
> underpowered laptop ;-)
The complete manual for the latest Websmart version is at;
http://esdi.excelsystems.com/userguides/websmart250b16ug.pdf
--
Regards,
Francis Lapeyre
"Facilius est camelum per foramen acus transire quam divitem intrare in regnum Dei."
(Mk 10:25)
Return address is filtered via SpamCop.
Nathan M. Andelin
appropriate, in my opinion.
While the CHGHTTPA command controls the number of threads started in
the HTTP Server, and consequently the maximum number of BCI jobs that
can be started, it's not an effective way to manage CGI resources.
Using the NETSTAT *CNN command, one can see that Internet Explorer
typically requests two (2) connections, and Netscape Navigator may
request up to twelve (12) connections to the HTTP Server. Each
connection is handled by a separate thread. By reducing the number of
active threads, you severely restrict the number of concurrent users
that can access the site, for static as well as dynamic content.
Although most browsers always request a "keep-alive" connection, some
CGI Web Masters configure the HTTP Server to drop connections
immediately, in an attempt to support more users with a restricted
number of threads. But that just slows response time and consumes
resources required to open and close sockets, at an busy site.
Programs that implement the Relational-Web API are started by an
operator from the command line. They wait for requests to be placed
on their queue. They process the request, produce a response, then
return to the queue for the next request. This model is ideal for
robust, highly-interactive, high-performance, busy, scalable, Web
applications. The CGI model, on the other hand, is probably better
for simple programs that require occasional use, and run under a *new
activation group.
Structuring a program around a Read loop leads to robust, efficient,
properly scoped programs. It's also an effective pattern for
Model-View-Controller implementations. The program that implements
the Read is the "Controller", which can link to other modules that
implement "View" and "Model" logic. In my opinion, one of the reasons
that many 5250 applications are so robust, is because they are
structured around the Read operation.
A call-level interface, on the other hand, is more appropriate for
simple requests.
Nathan M. Andelin
www.relational-data.com
Marc
On 13 Jul 2002 08:48:51 -0700, nand...@relational-data.com (Nathan M.
Andelin) wrote:
>While the CHGHTTPA command controls the number of threads started in
>the HTTP Server, and consequently the maximum number of BCI jobs that
>can be started, it's not an effective way to manage CGI resources.
>
>Using the NETSTAT *CNN command, one can see that Internet Explorer
>typically requests two (2) connections, and Netscape Navigator may
>request up to twelve (12) connections to the HTTP Server. Each
>connection is handled by a separate thread. By reducing the number of
>active threads, you severely restrict the number of concurrent users
>that can access the site, for static as well as dynamic content.
>
>Although most browsers always request a "keep-alive" connection, some
>CGI Web Masters configure the HTTP Server to drop connections
>immediately, in an attempt to support more users with a restricted
>number of threads. But that just slows response time and consumes
>resources required to open and close sockets, at an busy site.
>
>Programs that implement the Relational-Web API are started by an
>operator from the command line. They wait for requests to be placed
>on their queue. They process the request, produce a response, then
>return to the queue for the next request. This model is ideal for
>robust, highly-interactive, high-performance, busy, scalable, Web
>applications. The CGI model, on the other hand, is probably better
>for simple programs that require occasional use, and run under a *new
>activation group.
I might be missing something, but I still don't understand. If your
model has one job handling all the requests for the application, how
is that different from one CGI job handling all the requests for the
application? I'm not sure the number of simultaneous requests from
one browser would have much of an impact, as usually the rest of the
requests are for images on the page, not for the execution of
programs. (and even if they were for the execution of programs,
then it would seem the CGI model would more readily handle these
multiple simultaneous requests than what I understand to be a
single-threaded (so to speak) approach)
Perhaps I should ask, does your implementation only handle one request
at a time? You seem to indicate this is a negative of the CGI
implementation (with only one job). If not, how does it handle
multiple requests? If it does so by having multiple jobs running
(with the programs and the files open) how is this any different than
running multiple CGI jobs? As I said, I might be missing something,
but if overheard someone describe some jobs as follows:
"They wait for requests to be placed on their queue. They process the
request, produce a response, then return to the queue for the next
request. This model is ideal for robust, highly-interactive,
high-performance, busy, scalable, Web applications"
I would instinctively think that they were talking about the HTTP
server jobs...
Rgds,
Marc
Nathan M. Andelin
Have you ever used a stress tool to fire a series of requests at a CGI
program? For example, given that the HTTP Server is configured to
support up to forty (40) concurrent threads, and given a client
workload of forty (40) active users, then the HTTP Server will start a
maximum of forty (40) BCI jobs.
When running under a named activation group, an instance of the CGI
program will remain active in each one of the BCI jobs. As far as
resource consumption (memory, OS/400 workload managment, etc.), that
would be roughly equivalent to activating forty (40) terminal
sessions.
Now, if your application consisted of one hundred separate CGI
programs, and they all ran under named activation, then over time, it
would lead to 4000 active program instances (40 BCI jobs times 100 CGI
programs). That would be roughly equivalent to 4000 active terminal
sessions. A complex multi-user CGI workload will rather easily
overburden system resources.
The problem is that there's no effective way to manage resource
consumption with CGI, given an active, multi-user environment. If all
currently running BCI jobs are busy when a new request arrives, the
HTTP Server will simply start another BCI job, and forward the new
request to that job.
For any given program, a better approach would be for the Web Master
to control the number of instances of a program that get activated.
This can be done with an HTTP Server plug-in, working in conjunction
with a switching component, to route new client requests to an an
appropriate program queue.
A plug-in is essentially an extension of HTTP Server threads. In the
case of Relational-Web, the purpose of the plug-in is to route
requests to the appropriate program queue, wait for a response, then
return the response to the browser. If the HTTP Server is configured
to support forty (40) concurrent threads, then a single instance of an
RPG program can support at least forty (40) concurrent users.
If multiple program requests arrive at the same moment, they are
simply queued. However, when multiple instances of a program are
running on the server, then a switching component provides a
load-balancing service, so that response time for multiple requests,
ariving at the same moment, is averaged.
With Relational-Web, the number of requests handled concurrently
depends on the number of threads active in the HTTP Server, as
specified by the CHGHTTPA command. On an n-way system, the work of
HTTP Server threads and application programs will be balanced across
multiple CPUs.
Since Relational-Web programs run as jobs, separate from the HTTP
Server, they can run under their own library list, job description,
user profile, etc. This solves a number of system management
concerns, but that is another topic.
Nathan M. Andelin
www.relational-data.com
Marc
On 15 Jul 2002 22:36:44 -0700, nand...@relational-data.com (Nathan M.
Andelin) wrote:
>Have you ever used a stress tool to fire a series of requests at a CGI
>program? For example, given that the HTTP Server is configured to
>support up to forty (40) concurrent threads, and given a client
>workload of forty (40) active users, then the HTTP Server will start a
>maximum of forty (40) BCI jobs.
>
>When running under a named activation group, an instance of the CGI
>program will remain active in each one of the BCI jobs. As far as
>resource consumption (memory, OS/400 workload managment, etc.), that
>would be roughly equivalent to activating forty (40) terminal
>sessions.
>
>Now, if your application consisted of one hundred separate CGI
>programs, and they all ran under named activation, then over time, it
>would lead to 4000 active program instances (40 BCI jobs times 100 CGI
>programs). That would be roughly equivalent to 4000 active terminal
>sessions. A complex multi-user CGI workload will rather easily
>overburden system resources.
How is this different from running 40 relation-web jobs?
>The problem is that there's no effective way to manage resource
>consumption with CGI, given an active, multi-user environment. If all
>currently running BCI jobs are busy when a new request arrives, the
>HTTP Server will simply start another BCI job, and forward the new
>request to that job.
This is only true within the limits set in the CHGHTTPA command.
>For any given program, a better approach would be for the Web Master
>to control the number of instances of a program that get activated.
As mentioned, use CHGHTTPA...
>This can be done with an HTTP Server plug-in, working in conjunction
>with a switching component, to route new client requests to an an
>appropriate program queue.
>
>A plug-in is essentially an extension of HTTP Server threads. In the
>case of Relational-Web, the purpose of the plug-in is to route
>requests to the appropriate program queue, wait for a response, then
>return the response to the browser. If the HTTP Server is configured
>to support forty (40) concurrent threads, then a single instance of an
>RPG program can support at least forty (40) concurrent users.
But the requests don't get processed simultaneously do they? I bet
they 'block' which is what a single HTTP BCI job will do...
>If multiple program requests arrive at the same moment, they are
>simply queued. However, when multiple instances of a program are
>running on the server, then a switching component provides a
>load-balancing service, so that response time for multiple requests,
>ariving at the same moment, is averaged.
So they do block... What you describe is exactly what the HTTP server
does if it has more than one job running...
>With Relational-Web, the number of requests handled concurrently
>depends on the number of threads active in the HTTP Server, as
>specified by the CHGHTTPA command. On an n-way system, the work of
>HTTP Server threads and application programs will be balanced across
>multiple CPUs.
I guess I would suggest the term 'concurrent' is a little misleading,
as the requests are queued (as the HTTP server does as well), so
really it is only handling one request at time, which is something you
found unacceptable in a previous post.
>Since Relational-Web programs run as jobs, separate from the HTTP
>Server, they can run under their own library list, job description,
>user profile, etc. This solves a number of system management
>concerns, but that is another topic.
Well, I think we're caught in a loop here so I'll sum up where I'm not
understanding you...
You describe how 40 HTTP jobs would consume so many resources, but
fail to explain how 40 of your jobs would consume any fewer. You
describe one HTTP job as insufficient because it can only handle one
request at a time, but concede that your one relation-web job can only
handle one request at a time as well. You are unhapy with loading the
cgi into memory on each call as it is too slow, and are unhappy with
leaving it in memory as it consumes too many resources. In neither
case have you described how your approach solves this fundamental
programming trade-off. I just don't see where you can have your cake
and eat it too :< It seems to me that if an application had 100 tasks
to perform, and needed to be able to handle 40 simultaneous requests,
under your model you would end up with everything loaded into memory
as well. I have yet to see an apples to apples comparison.... (Note
that with CGI's you can cherry-pick which modules are kept in memory
and which are not)
<plug>As you mentioned earlier, this conversation is not really about
WebSmart, but about the CGI programming method, and I would like to
reiterate what you intuited earlier, and that's that if desired,
WebSmart could produce relation-web as well as RPGLE CGI or java
servlets.</plug>
I'll sign off of this thread here....
Rgds,
Marc
Nathan M. Andelin
> fail to explain how 40 of your jobs would consume any fewer.
Marc,
If you (or others) believe that CGI is a scalable architecture, then
it would be a waste my time to provide a lengthy explanation of how a
Relational-Web works.
We've been talking small numbers like forty (40) HTTP Server threads,
when in reality a busy ecommerce site requires hundreds or even
thousands of HTTP Server threads to support client connections.
If the Web Master reduces the number of HTTP Server threads, what
happens to people trying to connect to the site, even if only to reach
static content? Their mouse pointer turns into an hour glass, and
that's about it. It's like asking multiple people to dial a single
phone line at the same time.
So how can you suggest something like the use of the CHGHTTPA command
to control run-away CGI resource consumption?
Nathan M. Andelin
www.relational-data.com