Is this related to to the "cgi HTML head error" thread?

Dave.

Debugging web applications is something which can be learned. And, not unlike debugging COBOL, it must be learned for a successful debugging experience. I'd say it is easier to learn than debugging COBOL mainframe applications because the documents are readily available.

A status code 500 is sent to a web client to indicate an error which is not the client's fault. You need to check the server's log files for details. I could wade through your article to the text script not found or unable to stat and after this message a well configured Apache should write the file path (not the URL!) where it looked for your CGI program.

So, most likely, either the file doesn't exist, or it isn't readable and executable by the web server's user id, or Perl is not installed as /usr/bin/perl. But we can't tell. If the error message doesn't contain the path, ask to your hoster to improve the error logging (the LogLevel directive in Apache).

A COBOL application probably isn't spewing errors to the general public's web browsers. To do so can expose security vulnerabilities. So the more common approach is to spew a 500 Internal Server Error (to not expose more than is needed), and to log the error to error logs on the web host.

What gets logged is up to the person who developed the web application or CGI application. If the diagnostics aren't sufficient, add better diagnostic information to the error messages. While you're at it, make sure that you're actually handling errors usefully; that you're logging somewhere in the first place. And make sure that there are logfiles configured.

Debugging CGI is something you have to design into your CGI application. If a COBOL application were interacting over the CGI you would be facing the same concerns; this isn't a Perl-specific issue. There's nothing other than sanity preventing you creating a CGI application in COBOL. Once you do that, you'll find it equally challenging (perhaps more-so) to debug in a CGI environment. The point is that CGI layers in a whole other element of complexity, and that complexity has to be managed through more meticulous application design and architecture.

There's nothing other than sanity preventing you creating a CGI application in COBOL.

Somewhere in a strange, off-kilter dimension there's a poor shoggoth commiserating while shuffling his punch cards and saying "You know that's right" . . .

The cake is a lie.
The cake is a lie.
The cake is a lie.

I just googled "COBOL CGI" and there are both open and closed source COBOL implementations providing a CGI interface, and I even find a working COBOL CGI form (with source code). I am appalled and amused at the same time.