Troubleshooting BASIC Web Utility Problems

Errors can often occur when developing Web-based applications, and the above suggestions combined with the following troubleshooting guide can help get an application working quickly.

Error Messages

Remember, all applications should include error trapping to handle any problems that may arise. Errors that can be trapped include user escapes, missing files, and end of file errors. These errors can occur outside the calls to the BASIC Web Utility set.

The BASIC Web Utility programs include error trapping as an aid during the development cycle. If any errors occur, a log file (BWWERR.log) is created in the current working directory of the program being run. This may not necessarily be the current working directory of PRO/5, but the directory where the script (stdcgi.exe) resides.

Errors returned by the stdcgi.exe (reported to the browser and the BWWERR.log) are:

Error Message

Description

"Can't generate work file 1"

Could not create the first temporary file.

"Can't open work file 1"

Could not open the first temporary file.

"Can't generate work file 2"

Could not create the second temporary file.

"Can't open work file 2"

Could not open the second temporary file.

"Can't open parameter file stdcgi.bat"

Could not open the batch file.

"Couldn't start task!"

Could not start vpro5.(or other exe specified in the batch file).

"Result couldn't be found"

Could not open temp file that contains the output from vpro5.

Errors returned by the wincgi.exe (reported to the browser and the BWWERR.log) are:

Error Message

Description

"Can't open parameter file wincgi.bat"

Could not open the batch file.

"Sorry: can't start CGI task. Try again later"

Could not start vpro5 (or other exe specified in the batch file).

Debugging Programs during Development

The most common method of debugging a program is to single step through it. (Additional information on the single step verb can be found in the Commands Manual under 'Single Step.') Always set Byte 1 Bit $08$ of the options vector before beginning, or errors may occur in public (or called) programs. This also enables console mode and debugging in public programs.

An alternate method of debugging an application is to have the program create dummy files before each step of the program. This method makes it possible to know exactly which utility failed. Using the example from the Configuration section above, a line was added to create a string file before each call to a BASIC Web Utility program to help determine exactly which call failed.

0005 STRING "d:/bwu/progs/bwustarted",ERR=0050
0010 CALL "utcgi.wbb",ENV$,CGI$,ERRMSG$
0015 STRING "d:/bwu/progs/bwu15",ERR=0050
0020 CALL "uttags.wbb","h1"," My First Web Test Program",HTML$
0025 STRING "d:/bwu/progs/bwu25",ERR=0050
0030 CALL "utsend.wbb",HTML$
0035 STRING "d:/bwu/progs/bwu35",ERR=0050
0040 CALL "utexit.wbb",CGI$
0045 STRING "d:/bwu/progs/bwuworked",ERR=0050
0050 RELEASE