Unix/Linux OS/Regarding Unix batch monitoring
what is the scope in "Unix Batch monitoring or Job scheduler" job ??? Is that field is ok to earn and learn ????? how will be my future
pLEASE NEED YOUR HELP
Your question touches on 3 separate things, I think...
1) Monitoring of batch processes.
2) Job Scheduling.
3) Usefulness in learning these as it applies to gaining employment.
1) This is either done interactively, via analyzing log files or by adding code to report issues via services like email and text messaging.
2) "cron", "anacron" and "at" are used to schedule user jobs. "init" and the kernel are used for scheduling of system resources.
3) Here is an excerpt of a previously answered question about learning linux:
I've never taken any classes, but I've done lots of on-the-job-beat-your-head-against-the-wall learning, read lots of books, built/fixed systems and done thousands of web searches (once the web existed...) to figure things out.
Classes - In general, they follow a book. I've always needed something in-depth in a particular area that would have taken 8 or 10 classes to get all the pieces I needed... I never had the time for the classes. I needed to find a fix for a problem and had to have it quickly. If you can take one in college, however, take Operating Systems so you get all the basics and not just the particulars of one.
Books - O'Reilly has really good books. You can't go wrong with their books.
Tutorials - They are everywhere. I've not been through any of them because I do servers and most of them are about setting up a home system - with sound, scanning, gaming, video/TV, etc. But I've heard from others who have set up Ubuntu on their home systems that there are quite a few good ones on YouTube.
Install, Configure, Troubleshoot - For linux, the best way to jump in is to have an old computer that you don't mind nuking. These days, my test/play computer is an old Pentium 4 w/1GB ram and a couple of 80GB SATA drives. I've got a bunch of old NIC's and SCSI controllers to play with as well so I can switch one out if another causes issues... You can download base installation CD's for distros that don't have annual support fees, etc. Some of them can be run from the boot CD without trying the installation so you can figure out if the hardware mix works. (like Ubuntu...) You'll learn a lot by running the installation process with different disk layouts, software installations, etc. Then try changing things around after the installation - that's another learning curve.
Another set of learning tools - Once you get linux up and running, get used to using the "man" and "info" commands, followed by web searches when they are a bit terse. Many times I'll need a command to do something like edit a data file... I search the web for "linux binary edit" and "bvi" comes up - and its exactly what I was looking for... and if it wasn't already there, it's available. Then I can use "man bvi" to figure about how to use it on the system.
A list for later:
>>Learn "vi" and shell scripting. Get fluent with "vi". Once you are fluent with it and have a library of your own shell scripts, you can use some of your scripts from within "vi". The combination of "vi", "sed", "awk", "tr", "[e]grep", "sort", "cut" and a ton of other accessible *nix commands makes the shell prompt faster than any GUI for working on the system. I install a C:\bin folder on every Windows computer with all my favorite *nix commands. (There is no "bash" for Windows to run shell scripts without an entire CygWin installation yet, but I'm still watching for one...)
>>Learn how to write/compile tiny 'C' utility programs like "addcr.c" that makes a Windows text file out of a linux text file.
>>Learn how to compile source distributions of packages like Apache, PHP, OpenSSL and things like that.
>>Learn how to create boot/rescue CD's specific to a working system.
>>Learn how to automate things with "cron" in such a way as to have logs of the events that you can follow up on things later.
After you are comfortable building and destroying systems and getting them to do what you want you'll be able to start honing your troubleshooting skills.
And then, every 5 years or so, you'll have to re-learn 50% of everything because it changes so fast! When I started in 1980, MS-DOS wasn't even out yet. - But Unix was already 12 years old and X-Windows had just been developed at the Xerox Palo Alto Research Center. Network protocols were just getting started (everything was serial over conditioned lines - nothing digital...)
All that work I did learning how to make serial connections work reliably - was really worthwhile - for a while...
So keep that in mind -- you have to keep digging to keep up -- all the time.