i want to learn & write scripts, please help me.

I believe there is no such book/tutorial that describes "How to write a script for EMC NetWorker". What you can do is learn about command line tools which comes with NetWorker (nsradmin, nsrjb, nsrmm, mminfo, etc.) and then use this tools within your script. The default scripting language is different for UNIX and Windows, but you can always use perl, python, ruby or any other scripting language which is common for UNIX and Windows platform.

As Piotr also says, its very important to familiarise yourself with Networker's command line tools. You should download the Command Reference Guide from Powerlink and read as much of it as you can - as well as explaining how the various commands work, it also has important information hidden in there about how Networker works, especially with regards to the resources (the configurational information).

Changal - I know you sent me an email about this but I have been a little busy this week and not had time to respond. I don't think I have an easy answer to this as like a lot of people I have been entirely self-taught, largely through necessity!

I haven't scripted in Windows for well over 10 years and it does not lend itself well to scripting in my opinion so stick to UNIX if you can. I'd suggest picking a favourite shell to script in as commands will differ slightly, but be aware of the differences as you may well have to fix a script written in another shell. Its also reasonably common to see PERL used for scripting too, especially for reports.

Some useful sites worth looking at:

http://www.sun.com/bigadmin/shellme/
http://tldp.org/LDP/abs/html/index.html
http://www.well.ox.ac.uk/~johnb/comp/unix/ksh.html

If someone has written scripts in your office previously take a look at what they have done using these guides as reference to give you an idea as to how it works. If it doesn't do quite what it should identify the problem and attempt to fix it.

Some advice I'd give on beginning scripting:

* annotate your script, explain what you are doing (a # character indicates all that follows is a comment) - if you don't do this the next person to look at this will have no idea what is going on (which may be you in a month's time).

* include logging what is going on in the script, if it is not working correctly or has errors you will be able to locate the problem far easier. In particular log what parameters you are passing to commands or what you are using in tests.

* hash out anything destructive until you have confirmed it is operating on the data you want in the way you want.

* depersonalize your script as much as possible; assign any variables which may vary in different situations by passing parameters or in a section at the top of the script

* save your scripts - you can always reuse them, or sections of them if you move to a different job. It saves you having to make it all up again and makes you look clever in the eyes of your boss right away. The downside is he is more likely to forgotten it a year later when you have your annual review!