AutoSys Workload Automation

 View Only
  • 1.  Windows command errorlevel return code ambiguity

    Posted Nov 25, 2014 11:38 AM

    We are moving certain AutoSys command jobs from UNIX to Windows.  "Sleep" and "exit" are fairly elementary; adjusting stdout/stderr are the typical hurdles to be crossed.

     

    There are more complex commands that users have created that depend on UNIX shell command syntax.  We could put Cygwin or other work-alikes on Windows, but I'd prefer to "go native" so future maintenance is more controlled.

     

    Here is one example:

     

    autorep -J JOBNAME | grep " FA "

     

    As a start, I thought to replace autorep with autostatus as more appropriate to the task at hand. It would be nice if it returned an exit code that corresponded to the internal intcode, but that's an idea for another day.  Normally, autostatus would do this:

     

    E:\tmp>autostatus -j GOODJOB

    SUCCESS

     

    E:\tmp>autostatus -j BADJOB

    FAILURE

     

    Capturing those string values with switch logic is left as an exercise for the student.  My question, though, is on defensive programming such that deleting the target job will produce a replicable result.

     

    E:\tmp>autostatus -j NOSUCHJOB

    CAUAJM_E_50004 Invalid job/box name: NOSUCHJOB

     

    The first 2 commands return DOS %errorlevel% as 0, while the last command returns a 1.

     

    E:\tmp>echo %errorlevel%

    1

     

    However, a global variable quest returns a 0 status no matter what?

     

    E:\tmp>autostatus -G JIM

    UPGRADED

     

    E:\tmp>echo %errorlevel%

    0

     

    E:\tmp>autostatus -G JIMI

    CAUAJM_E_50005 Invalid Global Variable Name: JIMI

     

    E:\tmp>echo %errorlevel%

    0

     

    Shouldn't both commands fail with the same status (1) on undefined values? (UNIX command line autostatus behaves the same as Windows command).



  • 2.  Re: Windows command errorlevel return code ambiguity

    Posted Dec 08, 2014 10:11 AM

    Anyone able to help out Jim?



  • 3.  Re: Windows command errorlevel return code ambiguity

    Posted Dec 16, 2014 09:57 PM

    Any CAUAJM_E_* code implies an error. I'd expect %errorlevel% to be non-zero too. bug?



  • 4.  Re: Windows command errorlevel return code ambiguity

    Posted Sep 10, 2015 03:14 AM

    I agree with Chandru, please open in case at CA support

     

    Exit codes should be consistent

     

    If the Job, Global variable or Instance name does not exist, the return code should be the same




  • 5.  Re: Windows command errorlevel return code ambiguity

    Posted Sep 10, 2015 07:49 AM

    Easy everyone.

    firstly: when you PIPE commands you will always get the return code of the last piped command.

    secondly, autostatus and autorep SHOULD return a bad exit when the job or global doesnt exit. This I agree.

    I had opened tickets in the past. They may state that they always exited this way.. so be prepared.

    I usually wrote a perl wrapper to scrape the output. as a stopgap I suggest doing that..

     

    oh and all alerts go to stderr. or at least they did. inside the perl i usualky redirect out and err to same so i can scrape properly.

     

    Good luck.



  • 6.  Re: Windows command errorlevel return code ambiguity

    Posted Sep 11, 2015 03:34 AM

    I agree, it always exited that way, but to be consistent in my opinion it should exit with error 1

     

    I am going to open a CA case to track it down



  • 7.  Re: Windows command errorlevel return code ambiguity
    Best Answer

    Posted Oct 03, 2015 05:59 AM

    We have fixed this problem in upcoming 11.3.6 SP3 Release