Scheduler Usage

Hi, people !

I have an issue executing a Command Job.

After installing, I tried to run de id command and I got this sysout:

+ id
/home/controlm/ctm/runtime/CMD.00004q0z_00m[2]: id: not found.

but when I ran it with its complete path, I got the follow sysout:

+ /usr/bin/id
uid=1001(cissys) gid=1000(cisusr)

I tried to run the same command on another server where CTM agent is installed and it worked fine. I compared both profiles and there's no difference.

Do you know what is the problem and how can I solve this? If it helps, the OSCOMPSTAT=127

Regards,
Eche

Hi,
It seems that the user on wich controlm submit does not have the path information about unix commands.
You must set the profile of the user adding the /usr/bin in the path of the profile.
(ksh = .profile / csh = .cshrc / ...)

Regards,
Philmalmaison

Even when I have the same user on different servers with the same profile but with different behavior?

If I login to the console and run the command 'id' or 'which id', the result is positive, it works like it should. Not so when I want to run Control-M.

Thanks for replying,
Eche

Compañeros, Control-M realmente no se loguea con el usuario y no ejecuta el profile del usuario. Al ejecutar un comando del sistema operativo con el job tipo 'command', debes incluir el path del comando, si no no funciona.

th_alejandro wrote:Compañeros, Control-M realmente no se loguea con el usuario y no ejecuta el profile del usuario. Al ejecutar un comando del sistema operativo con el job tipo 'command', debes incluir el path del comando, si no no funciona.

th_alejandro said:
Control-M doesn't really login with the user and doesn't run the user profile. When you run an OS command with the job type 'command', you must include the path of the command. If you don't, it doesn't work.

th_alejandro, I don't agree with what you're saying. I executed the same command on another server with the same user, without the complete path and it worked:

+ id
uid=110(cissys) gid=108(cisusr) groups=1(other)

It seems to be something in the user's profile, but I can't find any difference. I'm still looking for a difference.

If someone can tell me a possible solution to this problem, I'll be thankful.

Hi,
You maybe wrong too, trying on another server not ensure that the path is ok.

it just because you probably not have the same path on this new host.
What is to check is the env command on your source server that is not working fine, and just verify that the path for your command is well read by your user at startup for the job.

Regards,
Philmalmaison

philmalmaison wrote:You maybe wrong too, trying on another server not ensure that the path is ok.

it just because you probably not have the same path on this new host.
What is to check is the env command on your source server that is not working fine, and just verify that the path for your command is well read by your user at startup for the job.

Thanks for repliying, philmalmaison. I don't understand pretty much what you said. I think the path is OK, and the same on all servers, because when I ran the command by console, it worked, with and without the path.

The problem appears when I want to run commands like 'id', 'which ###', 'env', commands that should live in /usr/bin (and they actually do, beacuse I ran them by console and they worked) but when I tried to run them as a Command Job on Control-M they just don't.

BMC Support told me to run 'su - <username> -c "<cmd>" ' and it worked, but it doesn't solve the problem for me. In my opinion, seems to be somenthing about OS user's profile but I can't work this way.

I'm still looking for a solution and if you can figure it out, I'll be very thankfull.

Regards,
eche

Finally, I found a solution.

The BMC Support guy found the following in the systout:
+ su - cissys -c id
stty: : Not a typewriter

He told me that something in the user login scripts profile that does the stty and ask me to check the login script and remove any statement that is setting the stty.

Indeed, I found stty erase ^?. First of all, I commented it and the job was OK.

Then I checked the profile and I found this other line:
stty erase "^H" kill "^U" intr "^C" eof "^D"

And changed stty erase ^? to stty erase "^?"

Fortunately, the problem disappeared. I'm still wondering why this didn't happen in the other servers, but at least the issue was solved.

Regards,
eche

your problem is very big for me. i am now new here. thanks