The following special characters,
# @ !
{ } [ ] |
which have special meanings for HTML and JavaScript, will not show correctly in your Web pages, unless you make sure that, before entering SEU, your job CCSID matches the language of your keyboard.
Do the following:
I obtained surprising improvements on the performance of my welcome page (/easy400/welcome.htm), adding the following directives:
CacheLocalMaxBytes 2 M
CacheLocalMaxFiles 200
CacheLocalFile /easy400/welcome.htm
and adding a CacheLocalFile directive for each image used in the welcome page, such as
CacheLocalFile /easy400/ibm_logo.gif
I also added CacheLocalFile directives for other images frequently used in other pages.
Loading images into local AS/400 cache provides a superbous performance, even better than loading into cache text pages.
Usually the response from your CGI looks as follow:
Content-type: text/html
blank line
<html>
... etc. ...
</html>
A very simple way to have your CGI response linking to another site is that of providing just the following response:
Location: http://URL
blank line
If you whish, you may run our example and display its sources.
The tag <A> supports the keyword target which lets you specify the destination of a page.
starts a page in a new window
starts a page in an existing window named xxx; if this doesn't exist yet, it is created.
starts a page in the current window, after clearing it; this is used when you work with frames and you want to get back to the full window. If you do not specify the target keyword, the page is started in the current window or frame.
The keyword target may be also specified in the form tag. As an example:
<form method="post" action="/mypath/mypgm.pgm" target="_blank">
A CGI should always start the HTML response in the following way:
Content-type: text/html
<html>
The " Content-type: text/html" line contains a so called "HTTP header". This header MUST be followed by a blank line. See also our page Externally defined HTML.
This header tells the remote browser that the response contains an HTML script to be interpreted.
While MS Internet Explorer, in absence of such a header, assumes it by default, Netscape Navigator assumes a text default. Apparently the two products didn't agree on a standard approach. But this is just one of the many examples of disagreement.
In a sense you are requesting something like a /copy pre-compiler function. This could be extremely useful when you have many html pages sharing some pieces of html/javascript. A /copy-like function would allow to keep these common pieces external, and to include them wherever needed, thus reducing both html scripts development time and maintenance.
What, at least in my opinion, would be needed is some include function to be interpreted / executed from the client browser at page load time. Unluckily, nothing like this -- as far as I know -- is available. This me that any include function must be carried over from the server site.
There are two ways you can obtain this dynamic merging:
If an internet browser (Netscape, MS Internet Explorer, etc.) does use the cache, it is most likely that the next time this browser is requested to call a CGI, it shows the previous response instead of issuing a new request.
In such a case the user would see the cached response instead of the new one.
You may use some JavaScript to have a Web page automatically refreshed after a given number of seconds (milliseconds, to be correct).
Please read about the setTimeout method of object window:
setTimeout(function, msec[, arg1[, ..., argN]])
For example, to refresh your page every 25 seconds, add the following to your page source:
<head>
<script language=JavaScript>
function reloadPage() {
window.location=window.location
}
function refreshPage() {
setTimeout('reloadPage()',25000)
}
</script>
</head>
<body onLoad=refreshPage()>
Suppose the following:
Proceed as follow:
@Set up your CGI source and object libraries
by entering command
CGIDEV2/SETCGILIB SRCLIB(mysrclib) PRDLIB(myobjlib) .
@Obtain a sample external html source and a sample CGI RPG source by using command
CGIDEV2/CRTCGISRC SRCMBR(mycgi1) SRCLIB(mysrclib) PRDLIB(myobjlib)
You may compile the module, create the CGI program and run it. Afterwards you may change both the external HTML and the CGI program to fit your needs.
After reading the external html (GetHtml, GetHtmlIfs, or GetHtmlIfsMult you can use the RtvHtmlRcd subprocedure (see member XXXWRKHTML in CGIDEV2/QRPGLESRC). Ask it to retrieve the first record from the section of interest. For example, if 'top' exists and 'xxx' doesn't:
eval rcd = RtvHtmlRcd('top':1:rc) gives rc = 0
eval rcd = RtvHtmlRcd('xxx':1:rc) gives rc = -1
If you don't care about the contents or the rcd, you can use callp inst of eval:
callp RtvHtmlRcd('top':1:rc) gives rc = 0
callp RtvHtmlRcd('xxx':1:rc) gives rc = -1
I would recommending using WrtSection for the section only if rc = @Return codes -1 and -2 are obvious. You can get return code -3 only if the first parameter is *NONE and the relative record number is within a duplicate section.
System value QCCSID 65535 inhibits automatic character conversion from a CCSID to another CCSID. That is general a big problem with CGI programs.
For instance, the external HTML of a CGI program is not trlated to the CCSID of the CGI job when loaded in memory from it. If this HTML contains special characters, these characters are pratically corrupted and when output-ted to the browser they may cause problems, such as some piece of Javascript no longer running.
Fortunately, CGIDEV2 service program cares for this problem. The service program checks the job CCSID and, if it is found to be 65535, it is changed to its default value.
However, this may be not enough. The HTTP server assumes that the CGI is running with the CCSID of system value QCCSID, and this can also cause problems in character conversion.
In order to have your HTTP instance jobs running with a CCSID other than the one specified in system value QCCSID, just add the following directive to the configuration file of your HTTP instance:
DefaultFsCCSID nnn
where nnn is the desired CCSID value.
Yes. There are several ways you can do this.
Using multiple gethtml or gethtmlifs
However you should be aware of the following:
If you care, we have an example of this approach:
Using gethtmlifsmult: This subprocedure allows to load in memory several external IFS files containing html code. This subprocedure is highly recommended whenever several CGI's share some HTML code.
Using Server Side Includes: This allows to merge pieces of static HTML code into the HTML output buffer once it has already been sent from the CGI.
SC41-0607-02 AS/400 Performance Capabilities Reference - Version 4, Release 4
You should read Chapter 6, Web serving performance
(click -> to display this manual in PDF format).
(click -> to display this chapter in HTML format).
In this chapter they report a benchmark done on a simple non-persistent CGI, rather different from the ones one could develop with our CGI service program method.
You may add some JavaScript to have this done. Also in this case, however, we recommend your CGI performs the appropriate checks (some Web users disable JavaScript from their browsers).
In your JavaScript evaluation you should also consider advantages ("pros") and disadvantages ("cons").
As to examples of JavaScript for controlling input fields, you may look at our page JavaScript examples: regular expressions. A little further you'll find a link (Validating form numeric fields) to a CGI performing through JavaScript exactly what you're looking for.
Should you be interested, just download and install on your AS/400 our library js2.
With regard to the checks your CGI should in any case, here are our tips:
This request comes from your Internet browser.
When an user visiting a page of yours asks the browser to take a favorite (bookmark), the browser tries to find whether your site provides a favicon.ico to be associated with favorites.
If such icon is found, the browser associates it to the favorite (bookmark).
For instance, if you bookmark this page, you'll find that your favorite (bookmark) is associated with our computer icon.
Use command cgidev2/http8000.
It creates a (traditional) HTTP server instance for port 80@The instance name is CGIDEV2.
Note 1 - To run command CGIDEV2/HTTP8000, you must have full authority on filesQUSRSYS/QATMHINSTC and QUSRSYS/QATMHTTPC.
Note 2 - Command CGIDEV2/HTTP8000 can be run just once.
When you have a CGI (like an Order Entry) receiving input from a form, the danger always exists that the user incorrectly sends duplicate inputs.
There are two main cases where this is possible.
Case 1: The user enters by mistake an order line equal to the last previously submitted.
This can be controlled in this way:
Case 2: The user by mistake presses the Refresh / Reload button of the browser (I.E. supports also F5 for page reload). In this case, the browser would resend the last traction.
One way a CGI could control this would be to:
What you need is some sample gif, that you may stretch according to the value you want to show.
For instance, the following html
<table cellspacing=0 cellpadding=0>
<tr><td><img src="/cgidev/blue.gif" alt="blue line" height=5 width=80></td></tr>
<tr><td><img src="/cgidev/blue.gif" height=5 width=125></td></tr>
<tr><td><img src="/cgidev/blue.gif" height=5 width=300></td></tr>
<tr><td><img src="/cgidev/blue.gif" height=5 width=193></td></tr>
</table>
If you like, you may run a sample CGI that displays this kind of graphs,
or you may run an Easy400 program displaying the number of downloaders of the Easy400.net CGIDEV2 version.
You have two ways to avoid that a browser fetches a previous version of a page from the cache, instead of asking a fresher version of a page to the remote server.
Technique 1- Avoid to cache a page
Technique 2- Make your response a unique page.
There are two ways you may invoke a CGI from your html.
<A> ... </A>
you implicitly use the GET method.
<form method=get/post ... >
you may choose between the GET or the POSTmethod.
Therefore your question makes sense only for the form technique.
Your CGI's, using Mel's service program, are not sensitive to the GET or POST method, but the remote browser is.
The GET method:
The query string (the string starting by ? and containing the request parameters) is visible in the browser command line.
This is useful for testing purposes, because you can easily detect some flaw in the string.
But it is dangerous once you release your CGIs, because the user may try to alter some parameters in your request.
The POST method: There is no way the user may see the query string, therefore the query string is more protected against undue manipulations.
Another interesting control mastered by the browser when you use the POST method, is the protection against a back page which is not in the cache: a dialog box would appear askingwhether you want to re-post your previous request. An educated user, who previously submitted an order, would understand that doing this would re-enter the same order a second time, and would not go back page. If you used instead the GET method, no such dialog box would appear for aback page which is not in the cache.
In conclusion my suggestion is:
Do the following:
There is also a bypass, at least for gif's:
@add the following HTTP directive
AddType .gif image/gif 8bit
@re-start your HTTP server
You may use CGISRVPGM2 subprocedure chkIfsObj2() or subprocedure chkIfsObj3()