ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

How to monitor for possible errors

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

  • How to monitor for possible errors

    I have a small piece of code that reads a DB file... based on the values in the file, submits several jobs by building a command string (using the variables in the file) and calling QCMDEXC

    Code:
                 cmdstring = 'sbmjob cmd(call pgm(MYPGM) ' +
                             'parm(' + q + %trim(parm1) + q + ')) ' +
                             'job(' + %trim(jobName) + ') ' +
                             'jobq(' + %trim(jobQue) + ') ' +
                             'user(' + %trim(userName) + ')';
                 monitor;
                   qcmdexc(cmdstring:%len(cmdstring));
                 on-error;
              // DO SOMETHING HERE 
                 endmon;
    Is there a way to get any error messages if the SBMJOB fails?


  • #2
    The ultimate goal of this is to
    1. Run the same job with different PARM1 value from the job scheduler, AND
    2. Have the report output (for each separate run) show up in different users's spool files (userName)

    So this may run 7 times (PARM1 and userName is different each time).

    If there is a better way to do this, I'm all ears.

    Comment


    • #3
      Simon wrote this up some time ago - see https://www.rpgpgm.com/2013/10/captu...ror-codes.html

      You could also consider using QCAPCMD which makes detecting errors a little easier. He wrote that up too. https://www.rpgpgm.com/search?q=QCAPCMD

      Comment


      • #4
        Do you want to know about errors on the SBMJOB command itself? Or about errors in the submitted call operation?

        Comment


        • #5
          Originally posted by Barbara Morris View Post
          Do you want to know about errors on the SBMJOB command itself? Or about errors in the submitted call operation?
          Interesting question. I would like to know both... but figured getting errors on a submitted job would be more difficult.

          I actually hate that I'm submitting the job at all. The ONLY reason I'm submitting the job is so that the report goes to a particular user's spool file.
          I'm reading a DB file that contains client numbers and the associated IBM i user name. Each client has a different user responsible for monitoring the process.

          So if there is a better way to get the reports to the corresponding user, I'm all ears. I have many separate processes that follow this same paradigm.

          Comment


          • #6
            Why not just use OVRPRTF and specify the outq that you want? You can also use it to specify the owner of the spoolfile if you rally want to lock it up.

            Personally in these cases I would lean towards printing it to a pdf and emailing that to the responsible person.

            Comment


            • #7
              Originally posted by JonBoy View Post
              Why not just use OVRPRTF and specify the outq that you want? You can also use it to specify the owner of the spoolfile if you rally want to lock it up.

              Personally in these cases I would lean towards printing it to a pdf and emailing that to the responsible person.
              Simply specifying an outq won't achieve the result I'm looking for. I need the user to be able to WRKSPLF and see the results. I'm not sure how to specify the owner of a spoolfile.

              Jon I have considered (many times) emailing results to each user, but that creates quite a bit of overhead on our mail server given the number of jobs and frequency at which we run them (this is one of many jobs). Additionally, I have made it a point to provide consistent reporting no matter the job. So if I change this job, there are a hundred more I would need to change as well. Maybe that's the right (more difficult) solution?

              In more recent jobs like this I also write out to a "log file" on the IFS - this is mainly for me to see what happened should the user delete the spoolfiles.

              Comment


              • #8
                I haven't time to play with this but WRKSPLF allows you to specify a user and/or a specific printer. It may work to specify a user on the OVR and then see if the spool shows up. Othrowse override to a device named for the us and maybe it will work that way.

                Comment


                • #9
                  I'm missing something... I don't see anywhere on OVRPRTF that allows you to assign the printer output to a specific user name.

                  Our users access their spooled files using a menu option that executes WRKSPLF or ACS (the preferred method). They do not have the authority to look at or manipulate other users' spooled files.

                  Comment


                  • #10
                    Sorry - I was going off the parameter name and didn't notice that you can't actually specify a name for it.

                    There are other options though. For example you don't _have_ to let them use WRKSPLF - why not give them a command that picks up their user Id and selects spool content based on their name. Or give each user their own queue, or named printer file, or ...

                    Comment


                    • #11
                      Originally posted by JonBoy View Post
                      Sorry - I was going off the parameter name and didn't notice that you can't actually specify a name for it.

                      There are other options though. For example you don't _have_ to let them use WRKSPLF - why not give them a command that picks up their user Id and selects spool content based on their name. Or give each user their own queue, or named printer file, or ...
                      I guess I'm not understanding.... they ALREADY have a command/menu option that does WRKSPLF for them (picking up their user ID and selecting their spool files). The only way I know how to get the spooled files into their username is to submit the job in their name.

                      As for the queue - i really don't want to create an outq for every user... especially when they come and go (these are customer service representatives who monitor the jobs).

                      Why doesn't IBM give me the ability to override to a username?

                      I greatly appreciate the suggestions... there just doesn't seem to be a quick-and-easy solution like I was hoping for.

                      Comment


                      • #12
                        I think you may have just answered your own question in a way. If they are using a menu item to request the WRKSPLF then why not have that menu option invoke a selective WRKSPLF with a partial job name specified and then name the submitted jobs by user (for example).

                        Even better have a menu item that uses the new SQL spool queue support - the view OUTPUT_QUEUE_ENTRIES contains among other things the User Data - which you could certainly supply via an OVR. You could then use that data to feed a simple subfile from which you issue the wrksplf or whatever for the file they select.

                        Just saying that there are lots of ways of skinning this cat. Including submitting the job to run under the users Id - have you thought of that approach?

                        Comment


                        • #13
                          And now we have circled back to the beginning... I am currently submitting the job to run under the user's Id.

                          I'm thinking that's probably the better solution for now. We are trying to get away from the Green Screen, so I'd rather avoid more menu options.

                          I was unaware of "SQL Spool Queue support".

                          Comment


                          • #14
                            I'm not sure if this would work for creating spool files under the proper user ID, but you could try using the Set Profile Handle API (QWTSETP) to switch the original job's user ID to the one you want, then run the report, then switch back. If it works, that would eliminate the need to submit jobs to get the spooled files to be owned by the proper user ID.

                            Comment


                            • #15
                              I concur with Brian. You can use the profile swap APIs (QSYGETPH, QWTSETP and QSYRLSPH) to change the user ID that the job runs under. This will cause the spooled files to be created under the new ID and mean you won't need to submit a job. The basic idea is to swap to the new profile, generate the report then swap back to the original jobs profile once complete. I would also take steps to ensure the program couldn't be called by anyone from a command line or some other means as this could be used by anyone to become another identity (such as QSECOFR). e.g. call the program with any ID as a parameter, sysreq-2 to cancel it and hey, I'm now someone else...

                              Comment

                              Working...
                              X