- It does not catch errors in Jython expressions
var aVar = 5
var isTrue = Jython[aVar && int(avar) > 5]
This will compile fine in APDE and even the TPM web UI for creating/modifying workflows, but will not work, as:
aVar && int(avar) > 5
is not a valid Jython/Python expression (Python does not have && operator). The correct expression is:
aVar and int(avar) > 5
- It does not catch errors in DCM Query expressions:
var slotToDelegate = 2
var sysIdToDelegate = DCMQuery(/server[@id=$HostPlatformID]/property[@key="ZVM_SSI_SLOT_" + $slotToDelegate]/@value)
var hostToDelegate = DCMQuery(/server/property[@key="ZVM_SYSTEM_IDENTIFIER" and value=sysIdToDelegate]/@id)
These queries will compile fine in APDE, but will not work.
Correct queries are:
var slotToDelegate = 2
var slot_no = "ZVM_SSI_SLOT_" + slotToDelegate
var sysIdToDelegate = DCMQuery(/server[@id=$HostPlatformID]/property[@key=$slot_no]/@value)
var hostToDelegate = DCMQuery(/server/property[@key="ZVM_SYSTEM_IDENTIFIER" and @value=$sysIdToDelegate]/@id)
The TPM web UI for creating/modifying workflows however, is able to catch these errors.
Automation Packages in Tivoli Provisioning Manager (TPM)
APDE Troubleshooting: Build fails with "cannot find symbol: " even when the workflow in question does exist!
Sometimes you land up in this very awkward situation with APDE:
A workflow (called_workflow) which is called by another workflow (calling_workflow) in your project is very much existing in your APDE project, but you still can't package the tcdriver. Every time you try to do so, the workflow2Java step fails with an error like:
message = cannot find symbol: method callThe reason for this as I guess is, the server side does not have a (updated) copy of the workflow in question (called_workflow), though its very much there in your local APDE environment! Hence when APDE tries to generate the Java code for calling_workflow (APDE uses the TPM server's copies of the workflows to generate the Java code for a workflow), it is not able to find the definition of called_workflow on TPM server and puts a statement like this into the generated Java code of call
calAnd when this generated Java file is compiled, naturally the compilation fails, as there is no Java method called called_workflow()! This can be pretty frustrating (like me and my team-mates often were) to come around the situation. This is what I discovered as a work-around, after a lot of hit and trial:
Without doing step 2 this error will mostly NOT go away, no matter how many times you 'clean' and 'package' the project.
The "Build Automatically" option of APDE could come to your rescue, if you face the above problem frequently. This option automatically builds all projects which are not in sync with the TPM server, to sync them up. So if there are many projects in your workspace which are out of sync with TPM server, then turning on this option could make APDE unresponsive for long times. That's the reason why we tend to put this option OFF most of the times. But when APDE is idle, this option should be left turned ON, so that your APDE environment is always in sync with APDE. Once the APDE projects are in sync with TPM server, this option does not hog the processor for long.
Note: All information in this entry may
I thank my colleague, Piyush Chordia for figuring this out for me, when I needed this urgently.
Very rarely, but at times one might need to change the version of a tcdriver installed in TPM, using a brute force technique, for following reason.
A tcdriver with version number lower than what is already installed in a TPM installation, will NOT install on it, and throw an error like "the installed version of this tcdriver is higher then the version being attempted to install".
For example if the installed version of VMware_Virtual_Infrastructure.tcdriver is 22.214.171.1245 then you can reinstall this tcdriver only if the tcdriver file has version 126.96.36.19955 or higher. A tcdriver file having version 188.8.131.5203 can not be installed on it
But for some reason if the version being attempted to install is lower than the version already there, then the following brute force technique can be used to bring down the installed version so that the installation can succeed.
First log into TPM as tioadmin and connect to db2 with:
>db2 connect to maxdb71 user maximo using <your_password>
Change the version of VMware_Virtual_Infrastructure tcdriver, issueing the following command (change the version and tcdriver name as needed in this command)
>db2 update maximo.tcdriver set version='184.108.40.20603' where tcdriver_id = (SELECT TPTCDRIVER.ID FROM MAXIMO."TPTCDRIVER" AS TPTCDRIVER WHERE TPTCDRIVER.NAME = 'VMware_Virtual_Infrastructure')
This is a hack to forcefully change the version of the tcdriver in the TPM database.
After doing the above example a VMware_Virtual_Infrastructure.tcdriver file with version 220.127.116.1103 can be installed.
How will you combine the results of these 2 queries in a workflow?
array list1 = DCMQ
We want to combine 2 pairs of key / value pairs into the same query, so that the results of first query is the input to the second query! The trivial way is to run the first query and then iterate through the result with second pair of conditions to get a final list. That is not efficient, nor elegant!
The following do not work in workflow lang
So the answer?
array list = DCMQ
Note: All information in this entry may not be 100% accurate, though I try to keep this most accurate as per my knowledge. Standard disclaimer applies...