sponsored links

Collapse

Announcement

Collapse
No announcement yet.

RUNRMTCMD Question?

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

  • RUNRMTCMD Question?

    Hi, I've been using this successfully between two ofo our LPARs but have a few questions;

    1. The job QNMAREXECD /QUSER seems to continually run even though it doesnít show in active jobs.. When the job runs, I see in the job log entries from previous remote requests which is a little misleading. Is there a way of forcing each remote call to have its own job and joblog?

    2. The remote call Iím executing is a RSTLIB command with *print QPRINT but I canít find the print anywhere. Where does the output go?


    Basically there doesn't see to be anything on the destination LPAR about what has run.

    Thanks
    www.midlifegamers.co.uk

  • #2
    Re: RUNRMTCMD Question?

    what user do you see this running under? you will have to look at that users spooled files.
    Hunting down the future ms. Ex DeadManWalks. *certain restrictions apply

    Comment


    • #3
      Re: RUNRMTCMD Question?

      Originally posted by DeadManWalks View Post
      what user do you see this running under? you will have to look at that users spooled files.
      Hi,

      I have looked at QUSER and the profile which is specified in the RUNRMTCMD.. Nothing on either?
      www.midlifegamers.co.uk

      Comment


      • #4
        Re: RUNRMTCMD Question?

        On the target system run the following command: WRKACTJOB JOB(QTRX*)

        Change the job attributes for all the jobs you see there accordingly:

        LOG(4 00 *SECLVL)
        LOGCLPGM(*YES)

        Run the command again and then check those job logs.

        Comment


        • #5
          Re: RUNRMTCMD Question?

          Server jobs that service remote requests on IBM i tend to be configured to stay running, and when a remote request comes in they service the request, without the overhead of starting up a fresh job. This improves performance. As a result, I'd leave them that way.

          I don't know if there's a way to force a new job each time, but I'm inclined to think so.

          Typically, the WRKOBJLCK command specifying your IBM i user profile and object type *USRPRF is an easy way to find a job servicing your remote request.

          I don't know if this will help, but try changing the server job via CHGJOB SPLFACN(*KEEP). It may be using *DETACH.

          Comment


          • #6
            Re: RUNRMTCMD Question?

            Short version:
            I would guess that it's changing the job name in the spooled file to QPRTJOB. This is very common with server-type jobs.

            Long version:
            Server jobs tend to switch user profiles after the job has already started. So the job id might be something like 123456/ORIG-USER/JOBNAME. But, then the userid changes in the middle of the job (to match what was sent with RUNRMTCMD or rexec in this case) but the job id cannot be changed, so even though the userid might now be NEW-USER, the job id is still 123456/ORIG-USER/JOBNAME... the problem this casues is that spooled files are tracked based on the job id they were created for. So this immediately creates a security problem that ORIG-USER now has access to spooled files that were created for NEW-USER. Oops! So what IBM does to solve this security prbolem is, they change the job id in any creaed spooled files. Instead of using 123456/ORIG-USER/JOBNAME (which would cause the security problem) they put the new spooled files under 123456/NEW-USER/QPRTJOB. So they end up under a different job id -- which may seem confusing, but it's necesary for security.

            Comment

            sponsored links

            Collapse

            Working...
            X