7 Replies Latest reply on Apr 20, 2016 6:56 PM by Bill Robinson

    job relationships...

    Daniel Suen

      I originally have an NSH script (and a job associated with it) and a bunch of BLPackages.


      The NSH script will create an appropriate BLPackage deployment job (i.e. select the right BLPakcage based on the target server) on the fly and put it under some job folder. Over time, that folder will grow and grow, and I am wondering if there is a clean way of doing it.


      Ideally, there should not be any new job creation underneath the job folder, just launch a single job against the targets (right-click - then select the targets).


      I am thinking of trying,


      1. Pre-create a set of jobs, with 1-1 mapping between each job and each BLPackage.

      2. Modify the NSH script to get the Job key, and, (a) remove any existing hosts assigned to that job, then (b) assign a host to it and (c) execute the job.


      I don't know if this will run into race conditions as the job is always identified by a single key (JOB_KEY). So, if I execute the NSH job with a set of N targets, any kind of parallel run seems to me that it may introduce conflict in target assignment, and this will not work.


      I don't know if my thinking is correct or not. But if this is not the right way, what is the proper way of doing this?



        • 1. Re: job relationships...
          Bill Robinson

          why not use the 'executeAgainst' blcli command ?

          • 2. Re: job relationships...
            Daniel Suen

            Thanks. I will give it a try.


            blcli_execute Job executeAgainstServers JOB_KEY hostA,hostB,hostC


            or executeAgainst* command under the Job section.



            • 3. Re: job relationships...
              Bill Robinson

              well, any of the executeAgainst* commands - whichever one you need... 











              • 4. Re: job relationships...
                Daniel Suen

                Why is it I don't see documentation on "Job executeAndWaitAgainstServers" in the 8.5 documentation. I am running 8.6.x, and not sure if this is good.


                The thing is, this will return a job run key instead of a schedule ID with "non-wait" command.


                A Job run key allows tracking errors,


                blcli_execute JobRun getJobRunHadErrors "${JOB_RUN_KEY}


                But not with the schedule ID...at least not obvious how to do it.



                • 5. Re: job relationships...
                  Bill Robinson

                  many of these are unreleased commands.  you can generate the docs for those: Unreleased blcli commands and documentation

                  • 6. Re: job relationships...
                    Daniel Suen

                    If I follow this, I want to know if there is a way to see error more directly.


                    BLPackage JobA

                    BLPackage JobB


                    NSH Job - which uses server properties to determine if JobA or JobB should be run, and pass along the servers.


                    So, in the NSH script, I did,


                    # $JOB is either "JobA" or "JobB".

                    blcli_execute DeployJob getDBKeyByGroupAndName "job_fodler" $JOB


                    if [ $rc != 0 ]; then

                    print_debug "something wrong";

                    exit 1;


                    blcli_storenv DEPLOY_JOB_KEY

                    # $host is the target host

                    blcli_exectue Job executeAndWaitAgainstServers $DEPLOY_JOB_KEY $host


                    if [ $rc != 0 ]; then

                    print_debug "something wrong";

                    exit 1;



                    I got all these working; however, I notice that, if there is an error in executing a job for the host, usually it won't be possible to tell from this NSH job result. I can browse JobA's "Show Result", and I see it failed, but in the NSH job "Show Result", it is marked as success for the server "$host".


                    Is it possible to see the error (for some server targets) under the NSH job "Show Result" rather than going to the JobA or JobB?




                    • 7. Re: job relationships...
                      Bill Robinson

                      i believe that the return code of the exeucteAndWait is only showing if the command ran, not if the job failed or not.  so after you run the deploy you need to call one of the 'hadErrors' or 'jobstatus' commands.  from that point if you want to exit the nsh script in an error you can certainly do that.