http://www.scribd.

com/doc/22606788/Autosys-Tutorial

http://writetrends.files.wordpress.com/2009/09/autosys-edk2uaj45cie.pdf

http://sc.tamu.edu/shortcourses/SC-unix/introToUnix.pdf

AutoSys is used for defining, scheduling and monitoring jobs. These jobs can be a UNIX
script, java program or any other program which can be invoked from shell. Before
starting we assume that user has already setup an AutoSys environment. This
environment consists of autosys server and autosys client.

AutoSys System components

1. Event server (AutoSys database)
2. Event processor
3. Remote agent

Event Server

The event server is a AutoSys database which stores all system information and events
as well as all job, monitor, and report definitions. Sometimes this database is also called
as a data server, which actually describes a server instance. That is, it is either a UNIX or
Windows process, and it is associated data space (or raw disk storage), that can include
multiple databases or tablespaces.

Event Processor

This is main component of the autosys system. This processes all the events it reads from
dataserver. The event processor is the program, running either as a UNIX process or as a
Windows service that actually runs AutoSys. It schedules and starts jobs. When you start
the event processor it continually scans the database for events to be processed. When it
finds one, it checks whether the event satisfies the starting conditions for any job in the
database.

Remote Agent

On a UNIX machine, the remote agent is a temporary process started by the event
processor to perform a specific task on a remote (client) machine. On a Windows
machine, the remote agent is a Windows service running on a remote (client) machine
that is directed by the event processor to perform specific tasks.
The remote agent starts the command specified for a given job, sends running and
completion information about a task to the event server, then exits. If the remote agent is
unable to transfer the information, it waits and tries again until it can successfully
communicate with the database.

Basic functionality of AutoSys

Below is the diagram which explains the basic functionality, please check the
explanation.

Explanation
1. The event processor scans the event server for the next event to process. If no event is
ready, the event processor scans again in five seconds.
2. The event processor reads from the event server that an event is ready. If the event is a
STARTJOB event, the job definition and attributes are retrieved from the Event Server,
including the command and the pointer (full path name on the client machine) to the
profile file to be used for the job. In addition, for jobs running on Windows machines, the
event processor retrieves from the database the user IDs and passwords required to run
the job on the client machine.
3. The event processor processes the event. If the event is a STARTJOB, the event
processor attempts to establish a connection with the remote agent on the client machine,
and passes the job attributes to the client machine.
The event processor sends a CHANGE_STATUS event marking in the event server that
the job is in STARTING state.
4. On a UNIX machine, the inetd invokes the remote agent. On a Windows machine, the
remote agent logs onto the machine as the user defined as the job’s owner, using the user
IDs and passwords passed to it from the event processor.
5. The remote agent sends an acknowledgment back to the event processor indicating that
it has received the job parameters. The socket connection is terminated. At this point, the
event processor resumes scanning the event server database, looking for events to
process.
6. The remote agent starts a process and executes the command in the job definition.
7. The remote agent issues a CHANGE_STATUS event marking in the event server that
the job is in RUNNING state.
8. The client job process runs to completion, then returns an exit code to the remote agent
and quits.

Defining autosys job

There are various parameters to define autosys job. Starting from profile, timezone, start
time, starting condition and so on. There are the two methods you can use to create job
definitions:
1. Using the AutoSys Graphical User Interface (GUI).
2. Using the AutoSys Job Information Language (JIL) through a command-line interface.

In this tutorial we will use JIL language to create autosys jobs.

JIL stands for Job Information Language. Using this you can instruct autosys to save job
definitions. This information saved in autosys database. You can also create a jil file
which contains job definition. You can then pass this jil file to autosys.

Essential attributes for defining job

1. Job Name
JIL Keyword : insert_job. Name used to identify the job.
2. Job Type
a. JIL Keyword : job_type. The job type is one of job types: command (c), file watcher (f)
or box (b).
3. Owner
a. JIL Keyword : owner

The job owner specifies whose user ID the command will be run under on the client
machine. This attribute is automatically set to the user who invoked jil or the GUI to
define the job, and cannot be changed except by the edit superuser.

Other job attributes:

1. command: The command attribute can be the name of any command, executable,
UNIX shell script or batch file, and its arguments.
2. machine: This attribute specifies the client machine on which the command should be
run.
3. date_condition: The start date/time dependencies attribute is a toggle, which specifies
whether or not there are date, time, or both, conditions required for starting the job.
4. days_of_week: The days of the week attribute specifies the days on which the job
should be run.

Sample jil file for command job echoJob.jil

?
1insert_job:echoJob
2machine:unixMachine
3owner:username
4command:echo “Hello this is command job”

To add this job in atosys db. Run following command from unix:

jil < echoJob.jil

You can create/modify jobs either through the GUI interface (Schedular console) or
you can script it with the JIL command. Here is a sample JIL code.
/* ----------------- sample_ls ----------------- */

insert_job: sample_ls job_type: c

command: ls -l
machine: unixboxa
owner: user123
permission: wx,mx,we,me
description: "runs an ls -l as user123"
job_terminator: 1
alarm_if_fail: 0

Suppose that you save the code into code.txt you would do the following;
jil < code.txt

and if you wanted a log:

jil <code.txt >code.log

This has to be done from an autosys command line.

Once the code is in the autosys database, you can use autorep to check the status of
a job or box. For example, to check the status of sample_ls you would type:

autorep -j sample_ls

And to view the underlying JIL code, you would type:

autorep -j sample_ls -q
There are numerous other options and you really should read an Autosys guide to
get an uderstanding of the relationships between jobs and boxes, runstatus, etc.
As far as troubleshooting batch problems, autosys writes an autoremote log file, and
that file is placed where you specify in your setup of autosys. For example, the file
might be in the /tmp directory and called auto_rem.389743.93299.1
The file should always start with auto_rem and the numbers that follow will
correspond to the job ID in the database.

Introduction to Autosys: AutoSys is an automated job control system for scheduling,

monitoring, and reporting. These jobs can reside on any AutoSys-configured machine that is
attached to a network.
An AutoSys job is any single command, executable, script, or Windows batch file. Each
AutoSys job definition contains a variety of qualifying attributes, including the conditions
specifying when and where a job should be run.

Defining Jobs :
There are the two methods you can use to create job definitions:
¦ Using the AutoSys Graphical User Interface (GUI).
¦ Using the AutoSys Job Information Language (JIL) through a command-line interface.

Autosys Jobs:

Job Types and Structure :

There are three types of jobs: command, file watcher, and box.
As their names imply, command jobs execute commands, box jobs are containers that hold
other jobs (including other boxes), and file watcher jobs watch for the arrival of a specified
file.
In the AutoSys environment, the box job (or box) is a container of other jobs. A box job can
be used to organize and control process flow. The box itself performs no actions, although it
can trigger other jobs to run. An important feature of this type of job is that boxes can be put
inside of other boxes.
Default Box Job Behavior:
Some important rules to remember about boxes are

Jobs run only once per box execution.

Jobs in a box will start only if the box itself is running.
As long as any job in a box is running, the box remains in RUNNING state; the box cannot
complete until all jobs have run.
By default, a box will return a status of SUCCESS only when all the jobs in the box have run
and the status of all the jobs is "success.
By default, a box will return a status of FAILURE only when all jobs in the box have run and
the status of one or more of the jobs is "failure."
Unless otherwise specified, a box will run indefinitely until it reaches a status of SUCCESS or
FAILURE.
Changing the state of a box to INACTIVE (via the sendevent command) changes the state of
all the jobs in the box to INACTIVE.

Job States and Status :

AutoSys keeps track of the current state, or status, of every job. The value of a job’s status is
used to determine when to start other jobs that are dependent on the job. The job status is
displayed in the job report generated by the autorep command, and in the job report you can
view in the Job Activity Console
Following are the status of Autosys jobs:
INACTIVE : The job has not yet been processed. Either the job has never been run, or its
status was intentionally altered to “turn off” its previous completion status
ACTIVATED :The top-level box that this job is in is now in the RUNNING state, but the job
itself has not started yet.
STARTING : The event processor has initiated the start job procedure with the Remote Agent.
RUNNING : The job is running. If the job is a box job, this value simply means that the jobs
within the box may be started (other conditions permitting). If it is a command or file watcher
job, the value means that the process is actually running on the remote machine.
SUCCESS : The job exited with an exit code equal to or less than the “maximum exit code for
success.” By default, only the exit code “0” is interpreted as “success.” If the job is a box job,
this value means that all the jobs within the box have finished with the status SUCCESS (the
default), or the “Exit Condition for Box Success” evaluated to true
FAILURE : The job exited with an exit code greater than the “maximum exit code for success.”
By default, any number greater than zero is interpreted as “failure.” AutoSys issues an alarm
if a job fails
TERMINATED : The job terminated while in the RUNNING state. A job can be terminated if a
user sends a KILLJOB event or if it was defined to terminate if the box it is in failed. If the job
itself fails, it has a FAILURE status, not a TERMINATED status. A job may also be terminated if
it has exceeded the maximum run time (term_run_time attribute, if one was specified for the
job), or if it was killed from the command line through a UNIX kill command. AutoSys issues
an alarm if a job is terminated.
RESTART : The job was unable to start due to hardware or application problems, and has been
scheduled to restart.
QUE_WAIT : The job can logically run (that is, all the starting conditions have been met), but
there are not enough machine resources available.
ON_HOLD : This job is on hold and will not be run until it receives the JOB_OFF_HOLD event.
ON_ICE : This job is removed from all conditions and logic, but is still defined to AutoSys.
Operationally, this condition is like deactivating the job. It will remain on ice until it receives
the JOB_OFF_ICE event.

The difference between "on hold" and "on ice" is that when an "on hold" job is taken off hold,
if its starting conditions are already satisfied, it will be scheduled to run, and it will run. On the
other hand, if an "on ice" job is taken "off ice," it will not start, even if its starting conditions
are already satisfied. This job will not run until its starting conditions reoccur.
The other major distinction is that jobs downstream from the job that is "on ice" will run as
though the job succeeded. Whereas, all dependent jobs do not run when a job is on "on
hold"—nothing downstream from this job will run.

Starting Parameters :
AutoSys determines whether to start or not to start a job based on the evaluation of the
starting conditions (or starting parameters) defined for the job. These conditions can be one
or more of the following:
¦ Date and time scheduling parameters are met (it is or has passed the specified date and
time).
¦ Starting Conditions specified in the job definition evaluate to true.
¦ For jobs in a box, the box must be in the RUNNING state.
¦ The current status of the job is not ON_HOLD or ON_ICE.
Every time an event changes any of the above conditions, AutoSys finds all the jobs that may
be affected by this change, and determines whether or not to start them.
sample jil code / Writing jil code:

jil = Job information language

When using JIL to create a job definition, you enter the jil command to display the JIL prompt.

Runs the Job Information Language (JIL) processor to add, update, and delete AutoSys jobs,
machines, monitors, and reports. Also used to insert one-time job override definitions.

-------------------------------------------------------------------------------------------------
/* ----------------- SAP_UAT_MU03_C ----------------- */
insert_job: SAP_UAT_MU03_C job_type: c

command: /local/SAP/processCheckUAT.sh

machine: MU03-UAT

owner: admin@MU03-UAT

permission: gx,wx,mx,me

days_of_week: all

start_times: "15:00, 14:00"

description: "Job used for Run testing of process"

alarm_if_fail: 1

max_exit_success: 1
-------------------------------------------------------------------------------------------------
The above example is a simple jil code of autosys which we have to write if we want any
particular job to be thru autosys.

To Insert a new JIL code :

issue command "jil"
bash-3.00$ jiljil>>1>
"The following prompt will appear" copy paste the jil code u have made example of jil code
below...........
At the end the "C" or "B" determines if the job is box job or child job.
if the jil is inserted properly successfull message will come if any errors are there the jil code
contains some errors..
if successfull exit;
2. Other way is to create a temp file named temp.jil which contains jil code on autosys server:
give command.

bash-3.00$ jil<>

Functional Listing of AutoSys Commands :

This section lists which AutoSys commands to use for specific tasks. All commands are for
both Windows and UNIX, unless otherwise specified.

Accessing Sybase : xql

Checking System Status : autoflags
autoping
autosyslog
chase chk_auto_up
Converting cron to JIL (UNIX Only) : cron2jil
Defining AutoSys Jobs or Machines : jil
Defining Calendars : autocal, autocal_asc
Reporting Job Status : autorep
autostatus
Starting AutoSys (UNIX Only) : eventor
Stopping AutoSys : sendevent

Using Autorep command:

Function
Reports information about a job, jobs within boxes, machines, and machine status. Also
reports information about job overrides and global variables.
Syntax
autorep {-J job_name -M machine_name -G global_name} [-s -d -q -o over_num] [-r
run_num]

autorep -J (job name here)

This will display a list of jobs with complete details with box/jobname, last/latest run date &
time, status, exit code, etc.
Viewing JIL code for any Autosys job

autorep -J (job name here) -q

To obtain the underlying JIL (Job Interaction Language) source code for any Autosys job, run
command:

To obtain the information of previous runs

autorep -J (job name here) -r (No of runs back) example : autorep -J (job name here) -r 1

would generate a report for the job run one runs back

This command will add “echoJob” job to autosys databse.

Commands to control the job

Start job command

?
1sendevent –E FORCE_STARTJOB -J <job_name>
2
3sendevent -E STARTJOB -J <job_name>

To put jobs on OFF ICE or ON ICE

?
1sendevent -E OFF_ICE -J <job_name>
2
3sendevent -E ON_ICE -J <job_name>
4
5sendevent -E KILLJOB –J "Job Name Here"

Meaning of AutoSys status

 STATUS AUTOSTATUS Meaning
RU RUNNING Running
ST STARTING Starting
SU SUCCESS Success
FA FAILURE Failure
TE TERMINATED Terminated
OI ON_ICE On Ice
IN INACTIVE Inactive
AC ACTIVATED Activated
RE RESTART Restart
OH ON_HOLD On Hold
QW QUE_WAIT Queue Wait
RD Refresh Dependencies
RF Refresh Filewatcher

How do I create a job that runs as the root userid?

You can't.
For security reasons, Autosys jobs are not allowed to run under the root userid. If you are creating
an Autosys job that must perform actions as root, you must create a password-less kuu rule to
allow the job to run under another prod id (other than root). Approvals for password-less kuu
rules must be granted by IT security.
How do I check the status of a job?
autorep -J job_name
autorep -J job_name -d
Job Status lookup
How do I kill or terminate a job?
To kill a Job:

sendevent -E KILLJOB -J
job_name

To terminate a Job:

sendevent -E CHANGE_STATUS -s TERMINATED -J job_name

When should I kill or terminate a job (and what's the difference)?
 You should kill a job when the job status indicates the job is RUNNING and the
command and auto_remote processes are present on the client machine. (You can't kill a process
that no longer exists.) When a job is killed in this manner, its status will be TERMINATED.
 You should change the status of a job to TERMINATED when Autosys thinks the job is
RUNNING (i.e., job status is RUNNING) but the command process and the auto_remote are not
present on the client machine. You can also change the status to FAILURE or even SUCCESS,
depending on how you want the processing to continue.
How do I restart a job?
sendevent -E FORCE_STARTJOB -J job_name
How do I put a job ON HOLD or ON ICE?
To put a job ON_HOLD:

sendevent -E JOB_ON_HOLD -J job_name

To put a job ON_ICE use:

sendevent -E JOB_ON_ICE -J job_name

The following statements apply both to jobs ON HOLD and those ON ICE:
Even though the command may be successful, the job status may not immediately change to
ON_HOLD (or ON_ICE). The timing will depend upon how long it takes the event processor to
process this event.
You cannot put a job ON_HOLD if it is in STARTING or RUNNING state. The sendevent
command will run without error, but the EP will not change the job status and you will not
receive a notification.
To successfully put a job ON_HOLD, you should precede and follow the job with autorep
commands, as in the following example:
autorep -J job_name
sendevent -E JOB_ON_HOLD -J job_name
autorep -J job_name -d

To take the job off hold:

sendevent -E JOB_OFF_HOLD -J job_name

To take the job off ice:

sendevent -E JOB_OFF_ICE -J
job_name
What is the difference between ON_HOLD and ON_ICE?
Both ON_HOLD and ON_ICE will prevent a job from running when it is scheduled. However,
there are differences. Your choice of whether to put the job ON_HOLD or ON_ICE depends on
when you expect the job to run after you take it OFF-HOLD / OFF-ICE and whether the job is in
a stream or not.
When you put a job ON_HOLD
When the job is taken off hold, it will run immediately (once) if any runs were missed during the
ON_HOLD period (assuming all other conditions are met). Otherwise, it will start at its normal
time.
Note, however, that if the job has dependent jobs, these dependent jobs will not start. Also, if the
job is in a box, the box will not finish. Therefore, if a job is in a stream and you put it
ON_HOLD, this will effectively stop the stream.
When you put a job ON_ICE
When the job is taken off ice, it will start at the next scheduled run, not before. Moreover, if the
job has dependent jobs, the dependent jobs will see that job's status as SUCCESS. Thus in a
stream, the downstream jobs will run normally (but see the note below for an Autosys gotcha).
Putting a job ON_ICE effectively removes that job from the stream execution without having to
delete the job definition.
Note that when a job in a stream is put ON_ICE dependent jobs are started immediately after the
job is put ON_ICE (other conditions allowing). Therefore, putting a job ON_ICE can trigger the
portion of the stream that follows this job.
What happens to my job if Autosys is down?
If either the Event Processor is down or the Event Server (database) is down for any reason (such
as maintenance or a crash), then Autosys jobs will not be started. The jobs that were started
before Autosys went down will continue to run (as long as the client machines are up). However
the job status in the database will not be updated until both the Event Processor and the Event
Server are back up . When Autosys is back up, all the jobs that were supposed to start during the
downtime period are started. If a job has missed more than one run, it will only be started once.
What is a Chase alert?
Chase is a system utility that monitors Autosys to verify that jobs don't get stuck in STARTING
or RUNNING state, and generates alerts if it finds stuck jobs. In general, a chase alarm means
that there is something wrong either with the job or with the client machine. Because these are
job-related not infrastructure problems, the user is responsible for responding to the alerts.
For more information about the chase utility, see
[[http://miscwebapp.ms.com/sam/autosysweb/docs/support/troubleshooting.html#chase]
[Troubleshooting]] or Command Lookup.
Job & Machine Definitions
How do I view job definitions?
autorep -J job_name -q
How do I update a job using Jil?
To modify a job: use Jil as in the following example:
update_job: job_name start_times:
"0:00"

Do not use insert_job for existing jobs; it won't work.

Why can't I update my job anymore?
There are a few possibilities:
(a) You are not logged into the machine specified in the @machine component of the owner
attribute (in the job definition). To view the owner attribute for your job, you can use the -q flag
with autorep as follows:
autorep -q -J job_name

If you are not logged into the @machine specified in the job definition, then you can use the
command chgownermach to change the @machine to another valid machine. You must use the
physical host name for the machine (e.g., obtained via uname -n ), not a machine alias.
chgownermach -J job_name -m
machine

(b) You are not the owner of the job.

I accidentally deleted my job. How do I recover a deleted job?
Once a week, AutoSys Operations saves all job definitions into the following directory,
organized by year, month (YYMM) and instance:
/ms/group/it/unixeng/htdocs/Reports/autosys/archive
To find your job there: cut and paste the jil for your job into a temporary file, and resubmit it back
into Autosys.
If the job has been edited in the last 30 days, the following command will show its last
definition:
autotrack -v -J job_name
How do I find all dependencies on a job?
job_depends -d -J
job_name
How can I list all the jobs I own, by Prod ID or by Machine Name?
There is no vendor tool to do this but you can use the local (Morgan Stanley) jilgrep command.
This allows you to conduct searches in the Event Server (database).
jilgrep -q prod_id
jilgrep -q -e -h
host_name

Also, try the njilgrep command.

How do I list real and virtual machines?
To see the real machines contained in a virtual machine, use:
autorep -M virtual_machine -q

To see a list of all of the real and virtual machines that are defined in an Autosys instance,
use:
autorep -M ALL
What if my job edit machine is down?
You log in to another machine and use the chgownermach command to change @machine on the
jobs you need to edit.
How fast can I change @machine in case of an emergency?
We estimate the rate at which jobs can be changed in a steady stream to be better than ten per
minute. This rate should not be substantially affected by multiple users running the
chgownermach command simultaneously.
How do I append the current date to a standard output or error file?
To append the current date to standard output or standard error:
std_out_file: >/tmp/$AUTO_JOB_NAME.$AUTOSERV.`date "+%y%m%d"`.out
std_err_file: >/tmp/$AUTO_JOB_NAME.$AUTOSERV.`date "+%y%m%d"`.err

File watcher jobs do not create output files, so any entry in std_out_file: or std_err_file: will be
ignored
How do I append the current date to a file watcher?
To append the current date to a file you are watching for:
watch_file: /my_full_path/filename.$(date +%y%m
%d).txt

The name of your filewatcher file would then be: /my_full_path/filename.091130

Do not try to use the date command directly in the file name. (In other words do not try
something like
watch_file: filename.`date "`+%m-%d-%y"` as this will not work.)

Job Features
How do I redirect stderr and stdout?
By default, stderr and stdout files go to /dev/null. We recommend that you save these as log files
in order to have them for troubleshooting a job failure. To do this, you need to specify the
redirection using the job attributes for std_err_file, and std_out_file .

std_out_file: /var/tmp/$AUTO_JOB_NAME.out
std_err_file: /var/tmp/$AUTO_JOB_NAME.err

(Incidentally, $AUTO_JOB_NAME is an Autosys environment variable containing the name of

your Autosys job.) The default is to append to the file. If you wish to truncate the file each time
the job runs, specify > in front of the file name, as follows: std_err_file: >/var/tmp/
$AUTO_JOB_NAME.err
How do I add retry logic to my job?
If a job ends with a FAILURE status, then it can be restarted a number of times by using the
n_retrys attribute. (By default, it will not attempt to restart.)

This job will start an additional five times in casee of

failure:
n_retrys: 5
How do I set the time zone for my job?
The time zone for your job is the time zone of the Event Processor for the Autosys instance. So, if
the machine where you want to run your job is in London but the instance you use is NYA (and
thus the EP is in New York), you can change your time zone so that you're running the job on
London time with the following attribute:
timezone: London
You can get a list of all available time zones by running the command:
autotimezone -l
Other Autosys Features
How do I list all Autosys global variables?
autorep -G ALL
What are the Autosys environment variables?
The following environment variables are defined in the environment of a job when the command
is executed:
AUTOPID
The PID of the auto_remote process spawned for that job run.
AUTORUN
The value of the run_num/ntry.
AUTOSERV
The three letter Autosys instance identifier.
AUTOSYS
The Autosys root directory (which in Morgan Stanley can be instance-specific). Useful in
referring to the Autosys
executables patch as $Autosys/bin .
AUTO_JOB_NAME
The name of the Autosys job being executed. This is useful in creating job-specific output
file by using the variable
in the file name.
AUTO_JOB_PID
The PID of the command process, i.e., the direct child of the auto_remote. For other
environment variables, see the
next Q and A.

Interfaces
What GUIs are available for Autosys?
The Autosys GUIs are accessible via the following command, which brings up a small menu by
which to select a GUI: autosc The most useful
choices are:
Ops Console
a console to monitor jobs.
Job Definition
a single-job definition GUI.
Jobscape
a job stream monitor that shows both box hierarchy and job or box status.
The Calendars GUI is intentionally disabled. However, for job definitions, we recommend that
you just the JIL. It allows you to manipulate many jobs at a time and to save the JIL definitions
under a separate source control system.
Is there a PERL API for Autosys?
No. There is no PERL API (or any other APIs) available for Autosys.
MS Environment
How do I use "module load" for my command in an Autosys job?
One tempting place to load a module is in the job profile. However, for reading the profile,
Autosys uses sh (the Bourne shell), which does not understand functions and therefore the
module command. (In fact, module is a function.) by default, and cannot be changed. So, don't
use the module load in the profile.
However, if your command is a ksh script, you can load the module as part of it.
If your command is a perl script, use the perl module: Env::Modulecmd.
If the command is neither a ksh nor perl script, you can create a ksh wrapper for it.

dd870c12n1 /tmp 125$ time db2 -tvf qry

real 0m20.00s
user 0m0.22s
sys 0m0.97s

156453 record(s) selected.

If you want to activate the failed job than do first on-hold the job ,than off-hold the job

The null device is typically used for disposing of unwanted output streams of a process,
or as a convenient empty file for input streams. This is usually done by redirection.

/dev/null is a special file, not a directory, so one cannot move files into it with the Unix
mv command. The rm command is the proper way to delete files in Unix.

> /dev/null 2>&1

You need to understand the theory first and then its upto you how and where you
want to apply that theory. I'll try to explain above to you.
The greater-than (>) in commands like these redirect the program’s output
somewhere. In this case, something is being redirected into /dev/null, and
something is being redirected into &1.

Standard in, out and error:

There are three standard sources of input and output for a program. Standard input
usually comes from the keyboard if it’s an interactive program, or from another
program if it’s processing the other program’s output. The program usually prints to
standard output, and sometimes prints to standard error. These three file descriptors
(you can think of them as “data pipes”) are often called STDIN, STDOUT, and
STDERR.

Sometimes they’re not named, they’re numbered! The built-in numberings for them
are 0, 1, and 2, in that order. By default, if you don’t name or number one explicitly,
you’re talking about STDOUT.

That means file descriptor 0 or fd0 denotes STDIN or standard input and file
descriptor 1 or fd1 denotes STDOUT or standard output and file descriptor 2 or fd2
denotes STDERR or standard error.

You can see the command above is redirecting standard output into /dev/null, which
is a place you can dump anything you don’t want (often called the bit-bucket), then
redirecting standard error into standard output (you have to put an & in front of the
destination when you do this).

The short explanation, therefore, is “all output from this command should be shoved
into a black hole.” That’s one good way to make a program be really quiet!

ps -ef| grep marchprd (to see the process run at database)

njilgrep -i NYF rvcr% -start 08/09/2011 00:00 -end 08/09/2011 01:10

du -hk * 2>>/dev/null | sort –nr (Directories occupying huge space :)

autotrack -v -j mrd-db2-march2-updstat1
autorep –j rvcr-cp-mt-box –r -5

servinfo -v mrda202
pts mem nayakr
wk '{printf ("%s%s", $2,"\t")} END {print "\n"}'

njilgrep -h <hostname>

ex: njilgrep -h npias3015

njilgrep -i NYD,LNA,TKA,HKA,NYF sp-ir-rmi-pre-ln-disc
mpstat -P ALL for check load average (instead of rup)

/u/rave_system 8$ du -k --max-depth=1 .
du -h --max-depth=1 .
free –m (free space in server)

top np756c1n5 (see details about server)