- 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)
Matching: apde X
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