Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

TechTip: Debugging CGI Programs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • rpg@post.tele.dk
    replied
    TechTip: Debugging CGI Programs

    ** This thread discusses the article: TechTip: Debugging CGI Programs **
    Hi Art, Just my words - a lot of people thinks that a CGI RPG program is something very difficult - but as you point it - it is just another program with a little different interface - thank again - Jan ps: I have not gotten into some heavy AJAX testing - if you have some code to get me started I would be very pleased....

    Leave a comment:


  • Guest's Avatar
    Guest replied
    TechTip: Debugging CGI Programs

    ** This thread discusses the article: TechTip: Debugging CGI Programs **
    Jan, Yes, we have 1 data area per program, named the same as the program. Having 1 data area for all would be hard to manage. I have a separate testing instance in Apache with a unique internal IP address, which sort of does what you are suggesting, but in a more convoluted way. Currently all our web users are internal, and I can get fairly "exclusive" access after hours. Your technique is critical if you are running a larger implementation. I just wanted to point out that an RPG CGI program is still just an RPG program, and that techniques used for batch debugging can still be used for CGI. Your "threads per child" directive is to help isolate program instance. The way I do it, the active program tells me which one it is by going into MSGW. By the way, don't try my technique with AJAX, as every cursor movement will cause a new program to pop up in MSGW. I plan to play with your technique this weekend, as it opens up some approaches I hadn't considered before. Once again, thanks for a great article. Art Blose

    Leave a comment:


  • rpg@post.tele.dk
    replied
    TechTip: Debugging CGI Programs

    ** This thread discusses the article: TechTip: Debugging CGI Programs **
    Hi Art, Good point. I used to do almost the same thing but used a CL program with a wait instead of the DSPLY and then I had the time to start the debug. The reason I did it as described above was to have a dedicated test environment where you can do heavy testing without "getting" in the way for the production environment, and it is very easy to ask the user to add a :801 to the URL string and then catch him/her on her way in... As I understand you - if you use the same dataarea for all your CGI programs, then you'll set all your programs in "debug" mode at once, but I expect that you'll have different dataareas? Thanks - Jan

    Leave a comment:


  • Guest's Avatar
    Guest replied
    TechTip: Debugging CGI Programs

    ** This thread discusses the article: TechTip: Debugging CGI Programs **
    Good tip! I didn't know how to access the config file from green-screen, and that will be a help. However, I've been getting along with a more "crude" approach. Most of my CGI programs have a debug data area defined. If I set the flag to on, then it stops at *inzsr or setup time on a DSPLY op code. I can then see which CGI job is in MSGW, and do the STRSRVJOB and STRDBG command on it, break after the DSPLY, then answer the DSPLY message to continue. This works under Apache and worked fine under the original flavor of the HTTP server (it also works well for standard batch jobs). Of course, you can't do this when users might be accessing a production program, but it works fine for a development instance or for emergency issues. Art Blose

    Leave a comment:


  • MCWebsite.Staff
    started a topic TechTip: Debugging CGI Programs

    TechTip: Debugging CGI Programs

    ** This thread discusses the article: TechTip: Debugging CGI Programs **
    ** This thread discusses the Content article: TechTip: Debugging CGI Programs0
Working...
X