Loading ...
Sorry, an error occurred while loading the content.

How disable automatic response (*N) in QSYSOPR ?

Expand Messages
  • emmanuel_lara_mtl
    Hi, How disable automatic response (*N) in QSYSOPR ? Context : I want debug my CGI pgm. So, in the init sub-routine I m trying the following methode for CGI
    Message 1 of 4 , Jun 1, 2009
    • 0 Attachment
      Hi,

      How disable automatic response (*N) in QSYSOPR ?

      Context : I want debug my CGI pgm. So, in the init sub-routine I'm trying the following methode for CGI does a PAUSE.

      1) DSPLY commande with wait for response.
      2) SNDUSRPGM (CL command and API) to send an inquery (*INQ) message to QSYSOPR.

      When the message are waiting for response in QSYSOPR, this give me the time to do a STRSRVJOB and STRDBG. After STRDBG, I respond to the message and the CGI program continues the treatment.

      In interactive or batch (SBMJOB...) mode, all run (work) as I want.
      But when I call CGI with the Browser (and by Apache), the message in QSYSOPR doesn't waiting for response because *N is send.

      Do you know why ?

      Thanks a lot,
      Emmanuel.
    • jbperotti
      CHGJOBD JOBD(QHTTPSVR/QZHBHTTP) INQMSGRPY(*RQD) and restart the HTTP instance Giovanni
      Message 2 of 4 , Jun 1, 2009
      • 0 Attachment
        CHGJOBD JOBD(QHTTPSVR/QZHBHTTP) INQMSGRPY(*RQD)
        and restart the HTTP instance

        Giovanni

        --- In Easy400Group@yahoogroups.com, "emmanuel_lara_mtl" <elara@...> wrote:
        >
        > Hi,
        >
        > How disable automatic response (*N) in QSYSOPR ?
        >
        > Context : I want debug my CGI pgm. So, in the init sub-routine I'm trying the following methode for CGI does a PAUSE.
        >
        > 1) DSPLY commande with wait for response.
        > 2) SNDUSRPGM (CL command and API) to send an inquery (*INQ) message to QSYSOPR.
        >
        > When the message are waiting for response in QSYSOPR, this give me the time to do a STRSRVJOB and STRDBG. After STRDBG, I respond to the message and the CGI program continues the treatment.
        >
        > In interactive or batch (SBMJOB...) mode, all run (work) as I want.
        > But when I call CGI with the Browser (and by Apache), the message in QSYSOPR doesn't waiting for response because *N is send.
        >
        > Do you know why ?
        >
        > Thanks a lot,
        > Emmanuel.
        >
      • emmanuel_lara_mtl
        Thank you Giovanni, It Works !!! Does it cause a problem to keep INQMSGRPY to *RQD instead of *DFT ?
        Message 3 of 4 , Jun 1, 2009
        • 0 Attachment
          Thank you Giovanni, It Works !!!

          Does it cause a problem to keep INQMSGRPY to *RQD instead of *DFT ?


          --- In Easy400Group@yahoogroups.com, "jbperotti" <gb_perotti@...> wrote:
          >
          > CHGJOBD JOBD(QHTTPSVR/QZHBHTTP) INQMSGRPY(*RQD)
          > and restart the HTTP instance
          >
          > Giovanni
          >
          > --- In Easy400Group@yahoogroups.com, "emmanuel_lara_mtl" <elara@> wrote:
          > >
          > > Hi,
          > >
          > > How disable automatic response (*N) in QSYSOPR ?
          > >
          > > Context : I want debug my CGI pgm. So, in the init sub-routine I'm trying the following methode for CGI does a PAUSE.
          > >
          > > 1) DSPLY commande with wait for response.
          > > 2) SNDUSRPGM (CL command and API) to send an inquery (*INQ) message to QSYSOPR.
          > >
          > > When the message are waiting for response in QSYSOPR, this give me the time to do a STRSRVJOB and STRDBG. After STRDBG, I respond to the message and the CGI program continues the treatment.
          > >
          > > In interactive or batch (SBMJOB...) mode, all run (work) as I want.
          > > But when I call CGI with the Browser (and by Apache), the message in QSYSOPR doesn't waiting for response because *N is send.
          > >
          > > Do you know why ?
          > >
          > > Thanks a lot,
          > > Emmanuel.
          > >
          >
        • jbperotti
          Emmanuel, job description QHTTPSVR/QZHBHTTP is shipped by IBM with INQMSGRPY(*RQD). If you keep it like that, any CGI program receiving an escape message would
          Message 4 of 4 , Jun 1, 2009
          • 0 Attachment
            Emmanuel,

            job description QHTTPSVR/QZHBHTTP is shipped by IBM with INQMSGRPY(*RQD).
            If you keep it like that, any CGI program receiving an escape message would send a message to QSYSOPR and wait for a reply to be given.
            In my opinion - but that is just another person's opinion - it makes no sense to have an Internet user waiting for QSYSOPR to answer to an error message. In my opinion, it is better provide the remote user with a message about program failure, and have the program failure recorded in the joblog.
            I understand that the developer would like to be in control of the failure. However, his need to be in control should not conflict with user's expectation for a quick answer.
            In order to help the developer to be in control of failures, I have developed a special tool, called EPOLICE, that will even send an e-mail message to the developer, and help him in retrieving the joblog documenting the failure. That is a free of charge software, and you can download it from the Easy400 site.

            A separate speech should be given for the needs of a developer in testing his programs while being built.
            First of all I would recommend to have a separate instance for program testing.
            Next, I do not personally agree that one should plug extra code in a program (see your DSPLY statement) to help debugging.
            After all, one can easily predict what HTTP server job will be in control of a requests (see http://www.easy400.net/cgidev2o/debug.htm ).
            Of course, entering STRSRVJOB and STRDBG commands is a real pain, and one would like something faster.
            This is why I have developed a new command (which comes with CGIDEV2) named EDBG (enhanced debug) that simplifies the whole operation, while providing you with internal SRTVSRVJOB and STRDBG support.

            Testing, however, is a special situation which must be adapted to one's personality. I told what I do, but I I'm not by all means suggesting that you behave the same way.
            Find the way that better fits your character!

            Regards,

            Giovanni

            --- In Easy400Group@yahoogroups.com, "emmanuel_lara_mtl" <elara@...> wrote:
            >
            > Thank you Giovanni, It Works !!!
            >
            > Does it cause a problem to keep INQMSGRPY to *RQD instead of *DFT ?
            >
            >
            > --- In Easy400Group@yahoogroups.com, "jbperotti" <gb_perotti@> wrote:
            > >
            > > CHGJOBD JOBD(QHTTPSVR/QZHBHTTP) INQMSGRPY(*RQD)
            > > and restart the HTTP instance
            > >
            > > Giovanni
            > >
            > > --- In Easy400Group@yahoogroups.com, "emmanuel_lara_mtl" <elara@> wrote:
            > > >
            > > > Hi,
            > > >
            > > > How disable automatic response (*N) in QSYSOPR ?
            > > >
            > > > Context : I want debug my CGI pgm. So, in the init sub-routine I'm trying the following methode for CGI does a PAUSE.
            > > >
            > > > 1) DSPLY commande with wait for response.
            > > > 2) SNDUSRPGM (CL command and API) to send an inquery (*INQ) message to QSYSOPR.
            > > >
            > > > When the message are waiting for response in QSYSOPR, this give me the time to do a STRSRVJOB and STRDBG. After STRDBG, I respond to the message and the CGI program continues the treatment.
            > > >
            > > > In interactive or batch (SBMJOB...) mode, all run (work) as I want.
            > > > But when I call CGI with the Browser (and by Apache), the message in QSYSOPR doesn't waiting for response because *N is send.
            > > >
            > > > Do you know why ?
            > > >
            > > > Thanks a lot,
            > > > Emmanuel.
            > > >
            > >
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.