Hi All,
We are taking automated server backups of IIS 8.1 , based on IBM DS8.1 backup documents except shutting down and starting the DS services has been done manually. But , according to our corprate standards the infrastructure team has to fully automate the backup process which also includes automating the shutdown and restart of DS services.
To that extent, we have to script DS8.1 start & stop commands. Is there any scripts readily avaliable for this , so I can use it to tailor to my environment ?
Any ideas and suggestions is appreciated.
Thanks
Radha
Datastage 8.1 services - scripting start & stop command
Moderators: chulett, rschirm, roy
-
- Premium Member
- Posts: 8
- Joined: Fri Sep 02, 2011 9:33 am
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Shutdown
Startup is similar, except that you use appropriate start options.
The MetadataServer.sh command must be run as superuser - either as root or under sudo.
Note that there are other solutions. However the kill command is not amongst them.
Code: Select all
# Engine
DSHOME=`cat /.dshome`
export DSHOME
cd $DSHOME
. $DSHOME/dsenv
$DSHOME/bin/uv -admin -stop
# Agents
$DSHOME/../../../ASBNode/bin/NodeAgents.sh stop
# Services tier
/opt/IBM/WebSphere/AppServer/bin/MetadataServer.sh stop
The MetadataServer.sh command must be run as superuser - either as root or under sudo.
Note that there are other solutions. However the kill command is not amongst them.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Premium Member
- Posts: 8
- Joined: Fri Sep 02, 2011 9:33 am
Hi Ray,
Thanks for the reply. Currently I am running manually the commands exactly the way you explained, one after the other in the same order. if I have to script it, then I have to make sure the first command is successfull to pass to the next step .How do I do capture the return code of the first comamnd ? what is the return code of each step ?
Also, How do I automate disconnecting the client sessions, prior to shutting down the services.
I tried killing the dscs and dsapi_slave PIDS (responsible for designer client sessions) from unix box using kill -9 , client sessions are disconnected, but the job opened in that session are locked.
I really apprecaite if you could give more insight into it.
Thank you, Radha
Thanks for the reply. Currently I am running manually the commands exactly the way you explained, one after the other in the same order. if I have to script it, then I have to make sure the first command is successfull to pass to the next step .How do I do capture the return code of the first comamnd ? what is the return code of each step ?
Also, How do I automate disconnecting the client sessions, prior to shutting down the services.
I tried killing the dscs and dsapi_slave PIDS (responsible for designer client sessions) from unix box using kill -9 , client sessions are disconnected, but the job opened in that session are locked.
I really apprecaite if you could give more insight into it.
Thank you, Radha
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
In shell scripts you can test the exit status of any command via the $? shell variable, or you could pipeline them together using && connectors.
Rather than kill sessions, train your users to be clear of their sessions when scheduled outages occur, and do the right thing by giving plenty of notice of these scheduled outages.
If you must disconnect client sessions, use the Web Console. Yes, I know, that's not automatically scripted but, in your version, you don't have a lot of choice. (When you upgrade to 8.7 or later things become easier - there's a lot more command line adminstration possible.)
Similarly you should not kill running jobs but, instead, wait for them to finish. Again this is a management technique - know the expected run times of jobs and don't start them if they'll still be running when backups are scheduled.
Rather than kill sessions, train your users to be clear of their sessions when scheduled outages occur, and do the right thing by giving plenty of notice of these scheduled outages.
If you must disconnect client sessions, use the Web Console. Yes, I know, that's not automatically scripted but, in your version, you don't have a lot of choice. (When you upgrade to 8.7 or later things become easier - there's a lot more command line adminstration possible.)
Similarly you should not kill running jobs but, instead, wait for them to finish. Again this is a management technique - know the expected run times of jobs and don't start them if they'll still be running when backups are scheduled.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Learn what that means.emblem_user wrote:using kill -9
SIGTERM
The SIGTERM (-15) signal is sent to a process to request its termination. Unlike the SIGKILL signal, it can be caught and interpreted or ignored by the process. This allows the process to perform nice termination releasing resources and saving state if appropriate. It should be noted that SIGINT is nearly identical to SIGTERM.
SIGKILL
The SIGKILL (-9) signal is sent to a process to cause it to terminate immediately. In contrast to SIGTERM and SIGINT, this signal cannot be caught or ignored, and the receiving process cannot perform any clean-up upon receiving this signal.
![Idea :idea:](./images/smilies/icon_idea.gif)
![Wink :wink:](./images/smilies/icon_wink.gif)
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers