× 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.



The problem with function keys in Web applications is
that browsers assign default behaviors to them. 
There's no way that I know of to disable default
behaviors, except in Internet Explorer.  For users who
have standardized on Firefox, or Linux, or Mac OS
workstations, the JavaScript you use to trap function
keys won't work the way you want.  On the other hand,
there's no problem having JavaScript monitor for
accelerator keys, like Alt-1, which could be used to
submit forms.

If you decide to front-end existing green-screen
applications with an HTML interface, be prepared for
quite a bit of extra CPU overhead.  A typical 5250
data stream is about 1-2 kb in length.  A comparable
HTML stream may be 10-50 kb in length.  Some Java
interfaces consume 30-50 times more CPU cycles to
produce green-screen screen equivalents in HTML.  Any
savings in high-priced "interactive" CPU cycles may be
gobbled up by additional, although lower-cost batch
CPU cycles.  Given enough concurrent users, the
decrease in performance will be felt.

One problem with CGI interfaces is the load associated
with new program activation.  Most developers use
"named" activation to solve this problem, but may
unwittingly unleash a different problem.  When say 100
users request the same resource at the same time, the
HTTP server will attempt to load 100 instances of the
same application, and since application resources are
scoped to named activation groups, they aren't
released until the HTTP server is shut down.  That's
probably fine if you're deploying only a moderate
number applications, but will become a problem as the
number of users and applications grow.  It's like a
built-in memory leak.  Some developers suggest
restricting the number of available CGI threads as a
stop-gap measure, which is less than ideal, because
it's a global setting that applies to all applications
running under the HTTP server, and doesn't scale well
between low and high-peak usage.

OO languages like Java may consume a lot more CPU and
memory than native languages in the case of small
workloads, but as the number of users and applications
increases, the more efficient J2EE architecture is, in
comparison to standard CGI, because no more than one
instance of a Servlet is running within the
Application Server at a time.

Scripting interface like JSP, ASP, RSP, RPGsp, PHP, or
Net.Data, are seductively simple when getting started
with Web applications, but can get very unwieldy as
the number and complexity of applications grows,
unless you find an effective way to separate UI code
from program logic.  Scripts are great for simple
applications, though.

Using standard program models is critical for
enterprise class development.  It's much easier to
adapt an existing model to a new subject than to
rewrite a new application from scratch.  One problem
with "templates" that come with popular code
generators is that they're quite primitive, providing
little more utility than say DFU, or WRKDBF.  It's
hard to justify GUI point and click interfaces unless
you're providing users with additional functionality,
or streamline access.  Packaged templates normally
aren't very adaptable, and may require mastering an
intermediate scripting language in addition to the
generated language.

Enterprise class development raises a lot of
architecture questions.  Should applications run under
generic or specific user profiles?  Is there a need to
access many applications from a single sign-on?  Do
different users need different menus, and different
access rights?  Should some applications expose
"maintenance" capabilities to some users while
"inquiry" to others?  Do access rights need to be
configurable on a role by role basis?  Is there a need
to support multiple runtime contexts such as different
HTTP or J2EE application servers, or provide access to
production vs. development vs. test data, or provide
access to different versions of the same application? 
Are physical files segmented into members which
provide snapshots of the database, perhaps by fiscal
year?  Do certain users get access to certain records
only, and do record filters need to be configurable
according to user roles?

Just some things to consider.

Nathan Andelin


--- Mary Koetting <Mary_Koetting@xxxxxxxxxxxxxx>
wrote:

> We're a small shop (5 RPG/COBOL programmers) with an
> I5 Iseries (Apache
> server) and we're researching a new tool to write
> web applications and would
> appreciate any input you have on the subject...we
> have some visual RPG
> experience and have a couple of web applications
> using Brad Stone's eRPG. 
> 
>  
> 
> There will be forms entry, maintenance, automatic
> emailing, real time
> updating with about 100 users and it would use at
> least 30 files...would
> also love to have something in place that would
> capture the form as a
> scanned object and pass it to an Oracle
> database....we spend a lot of effort
> feeding forms to a scanner. Don't know if this is
> even possible but would
> save a lot of work.
> 
>  
> 
> We want to be able to use function keys to move from
> one screen to another. 
> 
>  
> 
> We would like to get cut down on our interactive
> workload and also need to
> keep track of who does what...we have a lot of PHI
> information (HIPAA) so we
> have to know when, how and who changed the
> information. I've seen a little
> of the Nexus Portal and I'd like to know if anyone
> has experience with it
> also.
> 
>  
> 
> We greatly appreciate any and all guidance...thanks!
> 
>  
> 
>  
> 
>  
> 
> Mary Koetting
> 
> Senior Programmer Analyst
> 
> Missouri Consolidated Health Care
> 
> 573-526-2856
> 
>  
> 
> -- 
> This is the Web Enabling the AS400 / iSeries
> (WEB400) mailing list
> To post a message email: WEB400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/web400
> or email: WEB400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/web400.
> 
> 



                
__________________________________ 
Discover Yahoo! 
Have fun online with music videos, cool games, IM and more. Check it out! 
http://discover.yahoo.com/online.html

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-2024 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.