I am trying to submit the following from a script on an AIX box with NSM
Workload 3.0. (this is a 3rd party scheduling tool from Computer Associates)

This is my simple little script that I try to run from that program. It just executes the script on my AIX box.

#!/usr/bin/ksh

mail blah@ (blah@blah.blah)blah.blah < /etc/motd
return 3

A truly odd thing happens, workload does not get the proper return code of 3 it returns a 0 instead of the 3 like it is told to do. If, I submit this script directly from the command line the proper status is reported. Here is my script in debug from the AIX command prompt.

max:/usr/Backup/jobscripts/TPCP/TEST> ./mail
+ mail blahb@ (blahb@blah.blah)blah.blah
+ 0< /etc/motd (that 0 there makes me think the RC of 0 is coming from there?)
+ return 3
max:/usr/Backup/jobscripts/TPCP/TEST> echo $?
3
max:/usr/Backup/jobscripts/TPCP/TEST>

We have found that this problem ONLY happens with the mail command. Can
someone explain why? Why is mail so special?

/sigh guess not.

:(

Depending on how that ungodly monstrosity invokes the shell, return could be acting as a function return instead of falling back to behave like exit, meaning it sets return value 3 within the child shell, which then exits normally with a 0.

Well finally figured it out. It had to do with some environment variables set by the 3rd party scheduler.

Here was the answer that CA devs came back with.....

So I essentially just added the EXITMAIN to my script and it worked just like it is supposed to lol.


Here is a sample scenario to explain the two TRIGGER options EXITLAST and EXITMAIN

Below is the default processing that occurs when CA7 submits a shell script for execution and that shell script in turn executes other programs and shell scripts:

Job JOB001 (previously defined to CA7) is ready for execution, and the shell script /jobs/job001/script01 is submitted.

/jobs/job001/script01 is:

date

# Issue UNIX date command

progxyz

# Execute program progxyz inline,

# which consumes 3 seconds of cpu time,

# and 10 seconds of wall clock time

# before completing.

/jobs/job001/script02 &

# Execute shell script

# /jobs/job001/script02

# in the background

# (as an asynchronous # process)

exit 25

# terminate script

# /jobs/job001/script01

# with an exit code of 25. Elapsed

# wall clock time 11 seconds, elapsed

# cpu time less than 4 seconds.



/jobs/job001/script02 (which was executed by /jobs/job001/script01) is:

progabc

# Execute program progabc inline,

# which consumes 40 minutes of cpu time # and 90 minutes of wall

clock time

# before completing.

exit 35

# terminate script

# /jobs/job001/script02

# with an exit code of 35. Elapsed

# wall clock time 91 minutes, elapsed

# cpu time just over 40 minutes.

In this example, CAIENF notifies CA7 that job JOB001 has completed only after the shell script /jobs/job001/script02 has exited, which is approximately 80 minutes after the originally submitted job shell script, /jobs/job001/script01, exited.

Additionally, the CPU time recorded for JOB001 is the combination of CPU time used by both shell scripts (in this case, 131 minutes) and the last exit code reported back to CA7 (in this case, 35).

CAIENF collects all the appropriate data automatically and presents this data to CA7 only after all processes associated with the job submitted are completed. You can see this information on the UNIX machine by dumping the contents of the UNIX checkpoint file and checking the JOBTERMU record written for the job. To dump the checkpoint file use the command $CAIGLBL0000/sche/bin/cau9ckl.exe -j "*"

This information is kept by the day of the year and time. The most recent activity will be at the end of this output.



Now, consider a job that completes as soon as the primary shell script completes.

For the previous example, this means considering the job JOB001 complete when the shell script /jobs/job001/script01 has exited.



enfcontrol JOB TRIGGER EXITMAIN

instructs CAIENF to consider a job as completed when the main process (in the sample scenario, shell script /jobs/job001/script01) of the job has completed.

If this option were in effect in our sample scenario, CAIENF would alert

CA7 the completion of job JOB001 when /jobs/job001/script01 exited.

Two other enfcontrol options are provided, which have special meaning only if enfcontrol JOB TRIGGER EXITLAST is in effect:



When enfcontrol JOB TRIGGER EXITMAIN is in effect, both the RC and the

accumulated CPUTIME of a job are taken from the exit of the main

process comprising the job.









enfcontrol JOB RC

This option indicates whether the exit return code presented by CAIENF to CA7 is the exit code of the main process (shell script) or of the last process associated with this job. This can only be used if enfcontrol JOB TRIGGER EXITLAST is in effect EXITLAST is in effect:

Syntax

enfcontrol JOB RC [EXITMAIN|EXITLAST]

For example, if the following option was in effect in our sample scenario, the exit return codes that CAIENF presented to CA7 component would have been 25: ( only if enfcontrol JOB TRIGGER EXITLAST is in effect )

enfcontrol JOB RC EXITMAIN

If enfcontrol JOB RC EXITLAST were in effect, the exit return code presented would have been 35.