1 Reply Latest reply on Nov 5, 2015 3:12 PM by Bill Robinson

    Performance command return value

      Using blcli, I currently am able to successfully run this command:


      blcli -Dcom.bladelogic.cli.debug.release-only="false" DepotFile deleteFileByGroupAndName "${PACKAGE_GROUP}" "${FILE_NAME}"


      to delete a depot file once it has been added to the package, to reduce clutter and consumption of space in our depot.


      This command returns a DB key for the package so that I can then use it to perform an addExternalCmdToStart and

      an addExternalCmdToEnd to the package.


      When I try and perform the same depot file delete operation with this command:


      blcli_execute DepotFile deleteFileByGroupAndName "${PACKAGE_GROUP}" "${FILE_NAME}"


      the depot file is deleted but the addExternalCmdToStart and the addExternalCmdToEnd no longer work.  I assume that this is because the two commands have a different return value.  I would prefer to use the "Performance" command, the one that does not seem to behave as expected, as I believe that it is inherently quicker.  Is there some way to get the correct DB key for the package from the Performance command or do I have to perform an additional command to re-acquire the DB key for the given package.  And does the time/resources needed to run the additional command make it a wash when compared to the time expended to run the non-Performance command that is currently working?

        • 1. Re: Performance command return value
          Bill Robinson

          so you added the depot file to the blpackage and not as a soft-link, and then deleted the original depot file.


          deleting a depot file object should have nothing to do w/ the blpackage if there is no association between the two.


          how are you executing the addExternalCmd commands - w/ what args, where are you getting the blpackage key, etc ?  can you show the whole script or sequence of commands ?


          the 'performance commands' run faster because they don't startup a jvm on each call - just a single jvm is opened (embeded in nsh) and the calls feed into that.