I don't know the exact behaviour of runcmd, in that I don't know if the command is executed within NSH as Administrator or by the rscd service as SYSTEM, but this may be an issue with the level of network access permitted to the SYSTEM account - i.e, read only.
Not an answer to the question, but an idea for an avenue of investigation.
Are you trying to put the file on a drive on the local severs (i.e. running CM) or on each remote server listed in servers_job2.txt?
It seems that the /u drive is valid as seen from your "list of hosts" input file. It just seems that the redirection did not work.
Did you try to just do a
and see what happens? Also, after you do the "NSH Here" I'm not sure what you did to before the runcmd was run. I tried it as follows and got it to work
host% touch /u/tmp/out.txt
cmhost% runcmd ....
In a windows environment, shared resources are mapped as drive letters for collaboration, etc. In my case, I'm using a U:\.... so in windows:
net use U:
Once dong that my local computer has a local hard disk of C:\ and a network drive of U:\
NSH allows me to cd //@, then cd /u/tmp.
Finally, getting back to the question, I'd like to run a runcmd script, and instead of writing the output to my local context of /c/tmp I'd like to write to my local context of /u/tmp.
it doesn't seem to work with the /u/tmp but works fine if I use /c/tmp. Note that this writes to my local context of /c/tmp and not on a managed host /c/tmp.
That's almost exactly what my old unicenter script did; map a drive to a network share, cd to that share then attempt to write a file there.
It turned out that the problem was the unicenter service was running as SYSTEM, so the scheduled job was too and SYSTEM didn't have write access to the network.
This was a very long time ago (7-8 years), but it still could be the case in this case.
Wilson, it looks like a problem writing output to the U: drive (/u/tmp)
Try running something simple redirected to /u/tmp:
echo test > /u/tmp/out.txt
Update: Andrew and I worked offline a bit on this. As it turns out, this problem only seems to happen with my terminal server session, and not when when running directly from my local client. More details as they come.
Never was able to figure this out. it only happens when running NSH from within the terminal server enviornment.
if /c is local and /u is a network drive, I can cd to /u, I can make directories under /u but I can not touch file.txt
Bottom line is that I can't create any filse on a windows network share, and it's not a permissions issue (reacall that I can create directories).