Hi all,
Newbie in this forum, had hope to share and learn from all that are present.
Current Problem -
Control M can't work well when the parameter (max-shm-mem) is set.
This parameter is usually not set in other Unix machine. The parameter has performed what it supposed to do but there is this side effect that
causes Control M unable to su at times.
Wonder if there's any one else encounter such error, these errors normally resolved upon re-run. Any one had managed to work round it with patch around ?
@sysout
sinuxd34% more RIM_STOP_BRG_2G.LOG_001x7i_00001
20070918 203016 Failed to submit job.
20070918 203016 Found empty sysout file.
20070918 203016 Possible cause of problem:
1. Job submission aborted due to error is user profile.
2. Job submission aborted due to error is Autoedit variables.
login. STDOUT -->>
login. STDERR -->>
su: No shell
Control-M can't work well with parameter (max-shm-mem) set ?
-
hipikll
.
Ok, no problem
Symptom/Question
Why does a Job fail to submit in UNIX? The Job Status turns Red (and the Job is not Submitted for Execution. Job fails with error "Job submission aborted due to error in user profile. and/or Job submission aborted due to error in Autoedit Variables"
Additional Problem or Contact Information
The following messages appear in the SysOut of the Failed Job:
...
YYYYMMDD HHMMSS Failed to submit job.
YYYYMMDD HHMMSS Found empty sysout file.
YYYYMMDD HHMMSS Possible cause of problem:
1. Job submission aborted due to error is user profile.
2. Job submission aborted due to error is Autoedit variables.
...
Value of TERM has been set to "".
WARNING: YOU ARE SUPERUSER !!
login. STDERR -->>
ttytype: couldn't open /dev/tty for reading
stty: : Not a typewriter
Not a terminal
stty: : Not a typewriter
stty: : Not a typewriter
stty: : Not a typewriter
.profile[57]: TERM: Parameter not set.
Any Job Submitted to a specific Unix User account fails to set or part of the environment of the user before executing a CONTROL-M job. For example a PATH variable that is set in the shell startup scripts is not processed and as a result the job fails to execute.
SolutionThere are at least three reasons why this can happen:
a). the first is that a Batch Job sources different startup scripts than an Interactive Job
b). certain types of terminal commands in the startup script may cause the rest of the startup script from being processed
c). changing permissions on directories owned by the CONTROL-M/Agent user id can cause this error
1. Batch Job vs. Interactive Job
A batch job is a job that runs without a terminal. A terminal is opened only in an interactive mode such as 'xterm' or 'telnet'. When a job runs in batch it sources only .profile or .cshrc startup script. The .login startup script is not sourced.
In an interactive environment both .login and either .profile or .cshrc startup scripts are sourced. The .profile is sourced for users whose startup environment is Born or Korn shell. For users that have their startup environment setup as C shell then .cshrc startup script is sourced.
For Unix accounts that run batch jobs all environmental variables should be defined in the .profile or .cshrc and not in .login startup script.
2. Certain types of terminal commands in the startup script may cause the rest of the startup script from being processed.
Since the batch execution of a job is done without a terminal, any terminal commands in the startup script will cause the processing of the script to be aborted. The following is an example of terminal commands:
` tset -s -Q `
stty erase "^H" kill "^U" intr "^C" eof "^D"
stty hupcl ixon ixoff
tabs
These commands and others that modify the terminal settings create problems when the script is called by CONTROL-M when running a job under that userid. The solution is to place them in an if-statement that is evaluated whether or not the user account is being used in an interactive fashion. Encapsulate these types of calls in the .profile and in /etc/profile scripts as follows:
# Check if this is interactive
tty -s
if [ $? -eq 0 ]; then # Only if it is interactive, then execute the commands
eval ` tset -s -Q `
stty erase "^H" kill "^U" intr "^C" eof "^D"
stty hupcl ixon ixoff
tabs
fi
For users that have C shell startup environment the syntax for the if-statement is different.
tty -s
if ($status == 0) then
eval ` tset -s -Q `
stty erase "^H" kill "^U" intr "^C" eof "^D"
stty hupcl ixon ixoff
tabs
endif
endif
3. The third reason this can happen is if the permissions on the CONTROL-M/Agent's directories are changed. If these permissions are modified from the original, change them back to the default. If the default permissions cannot be determine, uninstall the CONTROL-M/Agent and reinstall.
Please contact your local System or Control-M Administrator for assistance in performing this function if you are unsure how or if you are uncomfortable with the steps required to complete this task.
Regards
Walty
Symptom/Question
Why does a Job fail to submit in UNIX? The Job Status turns Red (and the Job is not Submitted for Execution. Job fails with error "Job submission aborted due to error in user profile. and/or Job submission aborted due to error in Autoedit Variables"
Additional Problem or Contact Information
The following messages appear in the SysOut of the Failed Job:
...
YYYYMMDD HHMMSS Failed to submit job.
YYYYMMDD HHMMSS Found empty sysout file.
YYYYMMDD HHMMSS Possible cause of problem:
1. Job submission aborted due to error is user profile.
2. Job submission aborted due to error is Autoedit variables.
...
Value of TERM has been set to "".
WARNING: YOU ARE SUPERUSER !!
login. STDERR -->>
ttytype: couldn't open /dev/tty for reading
stty: : Not a typewriter
Not a terminal
stty: : Not a typewriter
stty: : Not a typewriter
stty: : Not a typewriter
.profile[57]: TERM: Parameter not set.
Any Job Submitted to a specific Unix User account fails to set or part of the environment of the user before executing a CONTROL-M job. For example a PATH variable that is set in the shell startup scripts is not processed and as a result the job fails to execute.
SolutionThere are at least three reasons why this can happen:
a). the first is that a Batch Job sources different startup scripts than an Interactive Job
b). certain types of terminal commands in the startup script may cause the rest of the startup script from being processed
c). changing permissions on directories owned by the CONTROL-M/Agent user id can cause this error
1. Batch Job vs. Interactive Job
A batch job is a job that runs without a terminal. A terminal is opened only in an interactive mode such as 'xterm' or 'telnet'. When a job runs in batch it sources only .profile or .cshrc startup script. The .login startup script is not sourced.
In an interactive environment both .login and either .profile or .cshrc startup scripts are sourced. The .profile is sourced for users whose startup environment is Born or Korn shell. For users that have their startup environment setup as C shell then .cshrc startup script is sourced.
For Unix accounts that run batch jobs all environmental variables should be defined in the .profile or .cshrc and not in .login startup script.
2. Certain types of terminal commands in the startup script may cause the rest of the startup script from being processed.
Since the batch execution of a job is done without a terminal, any terminal commands in the startup script will cause the processing of the script to be aborted. The following is an example of terminal commands:
` tset -s -Q `
stty erase "^H" kill "^U" intr "^C" eof "^D"
stty hupcl ixon ixoff
tabs
These commands and others that modify the terminal settings create problems when the script is called by CONTROL-M when running a job under that userid. The solution is to place them in an if-statement that is evaluated whether or not the user account is being used in an interactive fashion. Encapsulate these types of calls in the .profile and in /etc/profile scripts as follows:
# Check if this is interactive
tty -s
if [ $? -eq 0 ]; then # Only if it is interactive, then execute the commands
eval ` tset -s -Q `
stty erase "^H" kill "^U" intr "^C" eof "^D"
stty hupcl ixon ixoff
tabs
fi
For users that have C shell startup environment the syntax for the if-statement is different.
tty -s
if ($status == 0) then
eval ` tset -s -Q `
stty erase "^H" kill "^U" intr "^C" eof "^D"
stty hupcl ixon ixoff
tabs
endif
endif
3. The third reason this can happen is if the permissions on the CONTROL-M/Agent's directories are changed. If these permissions are modified from the original, change them back to the default. If the default permissions cannot be determine, uninstall the CONTROL-M/Agent and reinstall.
Please contact your local System or Control-M Administrator for assistance in performing this function if you are unsure how or if you are uncomfortable with the steps required to complete this task.
Regards
Walty