Pete Wirfs said:
I had this same issue setting up PowerShell support in V9. Rather than setting up a new variable like $jobMessenger, I discovered I could modify the contents of &UC_JOBMD
myself, and then I used it like normal. It does not make sense to me that PowerShell interpreter jobs do not populate this variable for us(?)
As I see it, the point of the
&UC_JOBMD
variable is that it can be relied upon to point to the job messenger daemon, regardless of on which agent the job is run. The usefulness of the variable is somewhat negated if one has to set it manually. :smile:
I think the SET instruction is how you modify a windows environment variable?
Yes, and I’m still trying to find the best way to set a variable to the output of another command. The following approach works:
:SET &JMD# = "C:\PROGRA~1\uc4\agent\bin\UCXJWX6M.EXE"
:SET &PW# = GET_LOGIN(TSM.LOGIN,"*",TSM_TEST,PASSWORD)
FOR /F "tokens=* delims=§" %%i IN ('&JMD# ^"CMD^=echo &PW#^" 2^>nul') DO SET pw=%%i
ECHO %pw%
Unfortunately, this approach once again depends on hard-coding the pathname of the job messenger daemon — and in particular, the
8.3 pathame. If I use
&UC_JOBMD
instead, it does not work. If I use the long path name in a UC4 script variable or BAT environment variable, it does not work.
It seems that at least for ordinary Windows jobs,
&UC_JOBMD
contains the long path name enclosed in double quotation marks. E.g.,
"C:\Program Files\uc4\agent\bin\UCXJWX6M.EXE"
I have not found a way to use
&UC_JOBMD
instead of the hard-coded 8.3 pathname. The
FOR
loop does not behave as desired, and I think this is due to the quotation marks, the space between
Program and
Files, or both. Perhaps someone can suggest a way to around this obstacle. Alternatively, perhaps someone can provide a quick and reliable way to convert the long pathname to an 8.3 pathname.