Hi All
First of all, this is going to be quite complicated to explain, but here goes.........
I am trying to use Job variables in order to pass a Pathname from VC on one server to a VC Job running on a different server.
Here is the scenario:
SERVER 1 has a job (CALL_SSH) which creates a user variable named '{USERVAR(UID)}_PRDSSH' (UID is a unique string for this particular job). The combined variable contains the name of a path on our SSH server (e.g ../B2B). The Job then calls a GET_FILES job on SERVER 2
SERVER 2 is the only server that has access to our SSH server so we need to run a job on this server to get files to pass back to SERVER 1. The GET_FILES job needs to know the Path on the SSH server.
On SERVER 1, in the Job/Task Control task that calls GET_FILES on SERVER 2, I have defined a JOB VARIABLE. The Key is 'myjobvar' and the Variable Value is {USERVAR({USERVAR(UID)}_PRDSSH)} - (so two nested USERVARS combined to create a single unique variable name). For explanations sake, lets say the variable UID contains the value '1'.
On SERVER 2 however, on the GET_FILES job, the JOB VARIABLES window shows the variable key 'myjobvar' but the Value says 'User Variable not found: 1_PRDSSH'
I think the issue is down to how Variables are interpretted. For example, if I use the 'SET VARIABLE' task to create a variable named 'sshpath' and define the Value as being {USERVAR({USERVAR(UID)}_PRDSSH)} (that is, nested Uservar's to make up a variable name), it is translated correctly, i.e to the Path Value that is stored in the translated variable '1_PRDSSH' which contains '../B2B'.
If I use the nested USERVAR's in the JOB VARIABLES, they are translated to the Variable Name, rather than the value.
However, if I assign the nested USERVARS to a SET Variable, and then use this SET variable in the JOB Variables value, it trranslates correctly on Server 2.
So, am I misunderstanding how JOB Variables are used to pass values between jobs on different VC Servers?
If not, how can I pass a Value from one VC JOB to another?
Apologies for the lengthy explanation.
Cheers
Andy