Creating Script Programs

Supported Languages

Script programs can be any program that can be called by another AS/400 program or a file object that contains REXX/400 procedure code. The only limitation is that in order for that language to receive input and return output, the language needs to be able to call, with parameters, one of the following types of Application Program Interfaces:

Original Program Model (OPM) APIs (e.g., RPG, COBOL, CL)
Integrated Language Environment (ILE) APIs (e.g., ILE C, ILE RPG, ILE COBOL)
ILE C
REXX/400 Procedure or Function

Making a Script Available to Web Server/400

There are three factors that make a script program available to a browser:

Enable Scripts Configuration Value
This value must be set to InsideScriptLib or OutsideSriptLib in order for scripts to be run at all.
Script Library Configuration Value
If Enable Scripts is set to InsideScriptLib, the script program must be placed in a library that is included in the Script Library configuration value. Actually, the only objects stored in a Script Library that can be accessed through the Web server are programs.
Note: REXX/400 procedures can only be called from within a library specified by the Script Library configuration value. Files containing REXX/400 code outside of a Script Library will always be served as text files.
Program Object Authority
The Server User Profile must have at least Execute data authority and Operational object authority to the program object to allow the Web server to call the script. The Server User Profile must have at least this much authority to the library that contains the script. Typically, the Server User Profile would have *USE authority to both the library and the script.

How Do Browsers Access Scripts?

There are two common ways for providing users access to a script. One is to create an HTML form that has a submit button that calls a script. The other is to have a hyperlink that directly calls a script.

HTML Form

An HTML form creates a user interface on the browser for collecting data from the user. When this data is submitted by the user, a script is called that can access everything the user typed in. The HTML form is simply some special markup in an otherwise normal HTML document. A form provides entry fields, check boxes, radio buttons, and lists. Below is a simple form that demonstrates the basics of how to use the form to collect data for a script.

<FORM ACTION="/cgi-bin/formscript" METHOD="POST">
Entry Field 1: <INPUT NAME="Var1Name" TYPE="text"> <P>
Entry Field 2: <INPUT NAME="Var2Name" TYPE="text"> <P>
<INPUT TYPE="submit" VALUE="Submit"> <P>
</FORM>

The user would request the above document, fill in a value (for instance, "Text1" and "Text2") in the entry field, and then press the submit button. This would request the formscript script using the POST method. The standard input to the script would be:

Var1Name=Text1&Var2Name=Text2

Hyperlink

If a script doesn't require dynamic user input, a simple hyperlink to the script would work fine. This would be done by including a normal anchor tag (<A HREF=...>...</A>) in an HTML document. Each URL used in the hyperlink to the script can have different extra path information or query strings. For example, the following two hyperlinks would call the script weather using the GET method. The first would request the weather for Kalamazoo, Michigan and the second would request the weather for Rochester, Minnesota.

<A HREF="/cgi-bin/weather?AZO">Kalamazoo, Michigan</A>
<A HREF="/cgi-bin/weather?RCH">Rochester, Minnesota</A>

Accessing AS/400 Objects within Scripts

If a script accesses AS/400 objects (e.g., database files) and the language (e.g., RPG/400) being used does not support qualifying the object with a library, two methods can be used to locate the object:

The object can be found using the library list. The script's library list is the library list of the user that started the server.
A CL program can be used to override to the desired object. The CL program would then call the script code.

Running Scripts from the Command Line

Script programs are just normal programs so they can, of course, be called from the command line. However, script programs generally will not work when called outside of Web Server/400 since the browser input is not available to the script. The Web Server/400 APIs will just return a blank string or indicate that zero bytes are being returned.

Debugging Scripts

Not everyone can write a script program exactly right the first time. Sometimes the script will produce the wrong results or even end abnormally. The first type of problem, faulty results, can be debugged through traditional methods with some minor twists:

Use the browser as your window to the program. Send input values or calculated values back to the browser in the body of the result.
View the exact source of the HTML being interpreted by your browser instead of the formatted version. Most browsers have a menu item that allows you to "View the Source".
Try different browsers to make sure the problem isn't a browser problem. Also, make sure your script works well with all browsers rather than just your favorite.

If a "Bad Request" error is displayed on your browser instead of the output you expected your script to create, then most likely the script caused an exception during execution or the Server User Profile did not have proper authority to the program object or file. The first place to check is your Error Log. This will indicate whether it is an authority problem or whether the program ended abnormally.

If it is an authority problem change the program object's or file object's authority.
If the program ended abnormally, check the job log of the request processor that handled your script request. This can be done using the WRKACTJOB command specifying option 5 on the proper job and then selecting menu item 10. Note: To keep the job log from becoming very large, the job log is cleared after every ten (10) requests. If your job log entry is not there this was probably the tenth request so request the script again.