install nsh on the target.
external command execute in the context of the remote system, so whatever is being run in the command needs to exist on the target system.
Will do. In that case I will just need to execute using nsh - c cp //server/files/* //serverb/files/*
Is that correct?
Principal Technology Consultant
OST (Open Systems Technologies)
605 Seward NW, Grand Rapids, MI 49504
for the record,
Bill is right, it is better to install NSH on every server, I tried something like this from a central server:
Within the command you can utilize a local or custom property classes that you have created, for example:
/bin/subladmin -c "nsh -c \"cp –r//SERVERA/SOURCE-DIR/DIRANDFILES //??PROPERTY-XYZ??/DISTINATION-DIR\""
but the developer needs to deploy the BLPackage on the target host and perform other steps, like config files etc...
If the developer was able to use the BL Depot to store his files, then we will not have a problem. The problem is when we need to pickup files from a server at run time, something File Deploy does, but need this feature in a BLPackage to utlize properties and/or custom property classes. I worked on a similar request at a diffrent customer site and was able to do all of that using an NSH/BLCLI script which even used Component Templates and was very powerful, but it is not simple and the developer will need to spend a lot of time to acomplish that unless I missed something?
I think I should submit an enhancment request to enable a BLPackage to pickup files from a remote server during run time excatly like file deploy, would you guys agree with that or I am on my own here?
installing nsh on every server and then managing acls so this works is not the right way to do this.
if you want to copy files from one server to another, use a file deploy job, or a nsh job w/ cp or dsync.
if you want to copy files and then deploy some other stuff, use a batch job that contains the FDJ and the deploy job.
you might also try using a depot software and the 'agent mount at staging' option.