You cannot expect to be able to create any CGI programs, unless you are able to debug them. Debugging ability is very critical for development. This is why we spend a page on it.

When something goes wrong in your CGI (or in your HTTP directives), the client browser is notified through an error code.
If you are using Internet Explorer, you have to go down to the end of the page to finf what the error code is.
Here comes a list of the most frequent error codes.

• Client errors
  • 400 - Bad request
    
  • 401 - Not authorized
    The page is protected, and the user failed entering the appropriate authorization.
  • 403 - Forbidden
    The page exists, but the HTTP server instance is not authorized to access it.
  • 404 - Not found
    The page does not exist.
• Server errors
  • 500 - Internal Server Error
    The CGI failed sending an appropriate output buffer. Most probable causes are:
    • the program was terminated because of an escape message
    • the program ended without sending a response (output buffer) to the client
    • the program sent an output buffer to the client, but the HTTP headers at the beginning of it make no sense (e.g. the blank line after the last header, usually Content-type: text/html, is missing.

In this page care for Error 500 only.

ERROR 500 may come from two conditions:

• the CGI response is not appropriate
• the CGI did not provide any response

1.  Finding out the CGI response 
   Each production library running CGI programs must include a CGIDEBUG file.
   This file is generated from command cgicbldev2/setcgilib.
   This file contains information and error messages generated from the service program. For instance, when a CGI attempts to write a section that is not found in the external HTML, an error message is written to this file.
   On top of what is automatically provided from the service program, the programmer may ask the service program to document in this file the input and the output buffer for any CGI transaction.
   This is done through command cgidebug:

   Handle CGI debugging (CGIDEBUG) Type choices, press Enter. Action . . . . . . . . . . . . . *ON____ *OFF, *ON, *DSP, *DSPDATA... Data area name . . . . . . . . . CGIDEBUG__ Name Data area library . . . . . . . __________ Name, *CURLIB

   (enter the name of the CGI production library in the "Data area library")
   In the "Action parameter" enter
   • *ON to ask the service program to start recording the input and the output buffer
   • *OFF to ask the service program to stop recording the input and the output buffer
   Use command dsppfm cgidebug to display the contents of this debug file.
   Note 1.
   File cgidebug should be cleared now and then, in order to avoid that it takes away the full disk space.
   Usually a clrpfm cgidebug command does not work, as the file is allocated from the service program.
   The correct command to clear the debug file is:
   • addlible cgicbldev2
   • clrdebug library_name
   
   
   
2.  Debugging a CGI program 
   This is the tough part of the job you must be prepared to.

   In a large number of cases, your CGI is not doing what it was supposed to, or it just bumps out (gets an escape message). How to deal with such cases?

   1. Set jobd qhttpsvr/qzhbhttp
      Set this job description to log(4 0 *seclvl) and restart the HTTP server after doing this.
      In this way you have better chances to understand what went wrong by checking the joblogs of the HTTP serving jobs.
      You should however be aware that:
      • With the Apache HTTP server, a CGI server job will end as soon as a CGI receives an escape message. You will then have to display the appropriate joblog from the qpjoblog output queue.
      • With the Original HTTP server, a CGI server job will not end after serving a failing CGI. In this case, therefore, you must look at the joblogs of the active HTTP server jobs to find out what escape message was received from your CGI.
   2. Make sure that your CGI modules / programs are compiled with parameter DBGVIEW(*SOURCE). We suggest that you change the following command defaults:
      • CHGCMDDFT CMD(CRTCBLMOD) NEWDFT('dbgview(*source)')
      • CHGCMDDFT CMD(CRTBNDCBL) NEWDFT('dbgview(*source)')
      and recreate your programs.
   3. Finding out the HTTP server job that will process the next CGI request
      Whenever the information found in the joblog is not enough to understand why the CGI failed, you will have to run the cgi UNDER DEBUG.
      In this case, the first thing to is to find out which HTTP server job will serve your request. A few hints:
      • You can do this, by
        1. Entering command wrkactjob sbs(qhttpsvr) and pressing F10 several times to reset the measurement interval time.
        2. Running a CGI transaction.
           With Apache, you should not run the failing CGI (it would end the HTTP server job), you must run another CGI transaction that does not fail.
        3. Use F5 to refresh the wrkactjob screen.
           The HTTP server job which displays some CPU usage is the one to be debugged.
      • If you have a very fast system, then you may not be able to detect which of the HTTP server jobs does consume some CPU time. In such a case, you may want to
        1. hold all the HTTP server jobs
        2. run a CGI transaction, release the first job and check if the client browser receives a response
        3. if not, release the second job and check again the client browser
        4. .. etc. ..., until you find out which is the HTTP job that will serve your next CGI request.
   4. Starting the debugging
      1. Looking ad the screen that displays the active jobs in subsystem QHTTPSVR, select with a 5 the one that you found serving your CGI requests, and press Enter.
      2. In the command line at the bottom of the screen, enter command
            STRSRVJOB joblognumber/QTMHHTTP/jobname
         for the job being displayed.
      3. In the command line at the bottom of the screen, enter command
            STRDBG mylibrary/mypgm UPDPROD(*YES)
         for the CGI program you want to debug.
         You will be displayed the source member of the initial module. Should you need to debug another module of the program, press F14 to select it.
      4. Search the statement you want to add a breakpoint to. Position the cursor over the statement and press F6 to add the breakpoint.
      5. From the client browser, start the CGI request.
         The execution will stop at the breakpoint.
      6. Do the following:
         • enter eval variable_name to display the value of a variable
         • or, position the cursor on a variable and press F11 to display its value
         • use F6 to add a new breakpoint
         • use F10 to execute the next statement
         • use F10 to resume execution (until the next breakpoint, if you have one)
         • ... etc. ...