c






  
 
 
 






 

! 

"

#$
  

%
&'()'

*+ '

,-./0)

1()2  

 3

4c.56

78

Ê
 run 

You will get pmcmd prompt
pmcmd>

Ê
 . run connect command to connect to repository/ cd to go to informatica server directory

pmcmd>connect
it will ask repository name/password

Ê

 run whatever command you need (startworkflow,stopworkflow,abortworkflow,starttas t.....)

Some more useful commands would be

 
The pmrep is a command line program that you use to update repository
information and perform repository functions. It´s installed in Repository
Server installation directory, it is usually ( $PM_HOME/repserver ). You can
execute this command like a command line or you can execute from a script
UNIX.
This command has got a lot of options, for example, you can connect to a
repostory if you execute the following command:

pmrep connect
-r
-n
-x
-h
-o

˜


˜
 
˜


infasetup is under .../server

infacmd is under .../server/bin

during one process a file is generated in one path and during the running of the worflow you want it to
place in another path so for this we need to use unix command "cp soure pathname targt pathname".

Generally all informatica jobs are automated and for this automation we need a tool in general unix
based tools are prefered like control-m autosys.. etc. so for the job to run tru tools it must be in the unix
script form so there pmcmd worflow name ... etc will be used/

AutoSys Cheatsheet
AutoSys: UNIX
Cd to the "autouser" ($AUTOUSER) directory and "." (or source) the "ksh" file. Ex: ".
./autosys.ksh.machine" After installing AutoSys, first make sure that the DB is up and running. Check the
installation by running the command chk_auto_up to verify connection to the DB and event processor.
Enter the KEYS through "gatekeeper", add keys
Run the "autosys_secure" command to set the AutoSys Edit and Exec Super users (and also to enter NT
users/passwords)
Start the Event Processor by running the command "eventor"
Shutdown AutoSys: "sendevent -E STOP_DEMON"
To start the AutoSys GUI set your DISPLAY and run the command "autosc &".
NT: Start AutoSys from start->programs->AutoSys-> administrator ->Graphical User Interface -
>Command Prompt
Command Line Commands:
1. gatekeeper: Allows you to enter the License Keys which allow you to run AutoSys.
2. eventor [-M machine_name] : Starts the event processor.
3. autorep -J [ALL | Job_name] [-q] [> file_name], -d (detail), -r (run number), -o (override), jil < file_na -
G (global var report), -M -q for machine definitions.
Ex: autorep -J job_name -d
autorep -J job_name -d
autorep -J job_name -q > file_name queries the DB & save job Dfn. Into a file
vi file_name
When you want a report of a box use the -L0 option
Autorep -J job_name -l1 report on the job for the day -1 (prev day)
4. sendevent -E STARTJOB -J job_name, sendevent -E FORCE_STARTJOB -J job_name, [JOB_ON_ICE,
JOB_OFF_ICE, JOB_ON_HOLD, JOB_OFF_HOLD, SET_GLOBAL, STOP_DEMON. . . .]
sendevent -E STOP_DEMON - to stop AutoSys
(ex: sendevent -E SET_GLOBAL -G "var_name=/home/mydir" to set a var)
(ex: sendevent -E SET_GLOBAL -G "var_name=DELETE" to delete a var)]
5. chk_auto_up: checks to see if event processor and the DB are both up.
6. autoping -m machine: verify that both client & server are correctly configured.
7. cron2jil -f cronfile [-d outdir] [-I incl_file] [-m machine] [-p prefix]
8. jil
To insert a job directly into the DB
insert_job: job.id job_type: c
machine: machine_name
command: echo testing jil
[go | ;] (depending on the DB you are using)
Template example:
/* ----------------- template ----------------- */
insert_job: template job_type: c
box_name: box1
command: ls -l
machine: localhost
owner: lyota01@TANT-A01
permission: gx,ge,wx,we,mx,me
date_conditions: 1
days_of_week: all
start_times: "15:00, 14:00"
run_window: "14:00 - 6:00"
condition: s (job1)
description: "description field"
n_retrys: 12
term_run_time: 60
box_terminator: 1
job_terminator: 1
std_out_file: /tmp/std_out
std_err_file: /tmp/std_err
min_run_alarm: 5
max_run_alarm: 10
alarm_if_fail: 1
max_exit_success: 2
chk_files: /tmp 2000
profile: /tmp/.profile
job_load: 25
priority: 1
auto_delete: 12
9. autosyslog -e: same as tail -f autosys_log_file. This command must be run from the machine where
the server resides if used with the -e option. Else it can be used with the -J option to see that job's run
log.
10. job_depends: -[c|d|t] -J jobname [-F "mm/dd/yy time"] [-T "mm/dd/yy time"] (Note: It will only
print out the first occurrence found)
11. monbro -n monitor_name: Allows you to run from command line monitor/browser programs
previously created using the monitor/browser GUI.exec superuser: AUTOSYS superuser
12. autocal_asc full_cal_name: prints, adds & deletes custom calendar definitions.
13. autostatus: Reports the current status of a specific job, or the value of an AutoSys global variable. Ex:
autostatus -J job_name, -S instance
14. autotimezone -l : Allows additions, deletions, and queries to the timezones table (-l provides list).
15. autotrack: Tracks & report changes to the AutoSys DB. Ex: autotrack -l 2 (level 2) [sets the tracking
level] autotrack -U sys -v (user sys: verbose) To start using the autotrack utility type: autotrack -u to set
tracking level 1 or 2. By default it is set to 0. Autotrack -l will list the current tracking level. Options -[J, U,
m, F, T, and t] are to request reporting on a specific Job, User, machine, time window (-F -T), and event
type (t). Type is used in conjunction w/other parameters. autotrack w/no arguments retrieves
information an all events omitting detail. -v option is for verbose.
16. autosys_secure: to change edit, exec superusers, change DB passwd, change remote authentication
method.
17. chase [-A|E]: Makes sure that jobs claiming to be running in the client machine are running. The "-E"
option restarts the job.
18. archive_events: to archive events in the DB which are older than x days to prev DB from becoming
full.
19. clean_files: Deletes old remote agent log files. It does it by searching the DB for all machines which
have had jobs started on them.
20. autostatad: to get the status of a PeopleSoft job. You can define one of the user definable buttons to
view PeopleSoft job: Autocons*userButton1Label: Adapter Status
User definable buttons: There are user definable buttons in the operator's console.
How to configure:
Autocons*userButton1Command: /autosys/bin/autostatad -J $JOB -g & (which allows you to have a
command button on the operator's console.)
Dependencies:
success (job) and s(job_b)
failure(job_a) or f (job_b)
notrunning (job)
terminated(job)
exitcode(job) > 5 and exitcode(job_b) != 10
value(global_name)=100
done(job)
Hostscape: Schedule a job to run every x minutes & then go into forecasting. Make that job fail.
ͻ Solid black line: Hostscape can communicate with the remote agent in the client machine.
ͻ Solid red line: Hostscape can't communicate with the remote agent but it can communicate with the
internet daemon (inetd) running on that machine..
ͻ Dashed red line: Hostscape can't communicate with the client machine at all. Client is probably down.
ͻ Accessing a variable name: $$GLOBAL_VAR_NAME (unless used in dependency condition with a job
definition. If used in the "command" field, you must use the $$)
Tunable Parameters:
ͻ $AUTOUSER/config.ACE
ͻ $AUTOUSER/autosys.ksh.xxx
ͻ /etc/auto.profile
ͻ /etc/inetd.conf
ͻ /etc/services
Notify.Ace: The alarms to notify on are:
(There is an example in $AUTOSYS/install/data/Notify.Ace).
ͻ DB_ROLLOVER
ͻ DB_PROBLEM
ͻ EP_HIGH_AVAILABILITY
ͻ EP_ROLLOVER
ͻ EP_SHUTDOWN
Where to go to find the Errors:
ͻ $AUTOUSER/out/event_demon.$AUTOSERV
($AUTOUSER/out/event_demon.ACE)
ͻ Output from the job definition output & error files
ͻ /tmp files created for job_run at client machine
ͻ $AUTOSYS/out/DBMaint.out for DB problems
ͻ $SYBASE/install/errorlog_$DSQUERY when event server will not start.
ͻ NT: AutoNuTc\lib/X11\app-defaults\xpert
AutoSys Maintenance: DBMaint @$AUTOSYS/bin
Once a day the Database goes into a maintenance cycle. Every day at 3:00am it runs a program called
DBMaint. This is user configurable. The program runs DBstatistics which is found in $AUTOSYS/bin.
app-defaults file: /usr/openwin/lib/app-defaults directory. Autocons, Xpert, etc.. ( or: /usr/lib/X11/app-
defaults, /autosys/bin/X11/app-defaults)
Environment file: /etc./auto.profile
C programs: $AUTOSYS/code
Where to change AutoSys screen fonts: /usr/openwin/lib/app-defaults
Where to look for troubleshooting: Chapter 15
Summary of commands: Appendix C
$AUTO_JOB_NAME: when naming a file dynamically using as prefix AutoSys's job name.
$AUTORUN: unique identifier for the run of that job
$AUTOPID: unique identifier for that job's run number (PID)
$JOID: DB identifier for a job. To extract from the DB: select joid from job where job_name=" "
Creating a Virtual Machine:
insert_machine: virtual
type: v /* default, not required */
machine: real_1
machine: real_2
max_load: 100
factor: 0.5 /* used to describe the relative processing power of a machine. Usually between 0.0-1.0*/
machine: real_2
max_load: 60 /* this is designed to limit the loading of a machine */
Load Balancing, Queuing, priorities:
insert_job: test_load
machine: localhost
command: echo "Test load balancing"
job_load: 50
priority: 1 /* this only affects queues */
Note: For 5.0 we will be using information from ServerVision's towards our load balancer which is
composed of 26 categories such as i/o usage, disk usage, CPU usage, etc.
Testing:
zql
zql -U autosys -P autosys
NOTES:
When a job is stuck in the starting condition this means that the event processor communicated with
the remote agent and passed all the information the remote agent ran the job but was not able to
communicate to the DB. Once testing is done with AutoSys one should change the default refresh
interval for AutoSys. This is so there is less querying to the DB. When AutoSys goes from dual mode to
single mode, always run the autobcp command before bringing AutoSys back to dual mode/High
Availability. Default behavior for stdout is to always appends. If you want to overwrite the file enter the
following, no spaces: ">file.out"
Box Logic
Use boxes to group jobs with like scheduling parameters, not as means of grouping jobs
organizationally. For example, if you have a number of jobs that run daily at 1:00 a.m., you could put all
these jobs in a box and assigning a daily start condition to the box. However, a variety of account
processing jobs with diverse starting conditions should not be grouped in the same box.
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." Default SUCCESS is described in Default Box Success and Box Failure on
page 5-13.
ͻ 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." Default FAILURE is described in Default Box Success and Box
Failure on page 5-13.
ͻ Unless otherwise specified, a box will run indefinitely until it reaches a status of SUCCESS or FAILURE.
For a description of how to override this behavior, see Box Job Attributes and Terminators on page 5-6.
ͻ Changing the state of a box to INACTIVE (via the sendevent command) changes the state of all the jobs
in the box to INACTIVE.
When you Should Not Use a Box
The fact that all jobs in a box change status when a box starts running has lead some to use boxes to
implement "job cycle" behavior. Be aware that placing jobs in a box to achieve this end may bring with it
undesired behavior due to the nature of boxes.
Avoid the temptation to put jobs in a box as a short cut for performing events (such as ON_ICE or
ON_HOLD) on a large number of jobs at once. You will most likely find that the default behavior of boxes
inhibits the expected execution of the jobs you placed in the box.
Likewise, you should not place jobs in a box solely because you want to run reports on all of them. When
you run autorep on a box, you will get a report on the box and all the jobs in the box (unless you use the
-L0 option). In addition, if you use wildcarding when specifying a job name, you could get duplicate
entries in your report. For example, suppose you have a box named "acnt_box" containing three jobs
named "acnt_job1", "acnt_job2", and "daily_rep". If you specify acnt% as the job name for the autorep
report, the report will have an entry for the box "acnt_box" and an entry for each job in the box. Then
autorep will continue searching for all job names matching the wildcard characters and, thus, will list
"acnt_job1" and "acnt_job2" a second time.
What Happens when a Box Runs
As soon as a box starts running, all the jobs in the box (including sub-boxes) change to status
ACTIVATED, meaning they are eligible to run. (Because of this, jobs in boxes do not retain their statuses
from previous box cycles.) Then each job is analyzed for additional starting conditions. All jobs with no
additional starting conditions are started, without any implied ordering or prioritizing. Jobs with
additional starting conditions remain in the ACTIVATED state until those additional dependencies have
been met. The box remains in the RUNNING state as long as there are activated or running jobs in the
box.
If a box is terminated before a job in it was able to start, the status of that job will change directly from
ACTIVATED to INACTIVE.
Note o Jobs in a box cannot start unless the box is running. However, once the job starts running, it will
continue to run even if the box is later stopped for some reason.
Time Conditions in a Box
Each job in a box will run only once per box execution. Therefore, you should not define more than one
time attribute for any job in a box because the job will only run the first time. If you want to put a job in
a box, but you also want it to run more than once, you must assign multiple start time conditions to the
box itself, and define no time conditions for the job. Remember also that the box must be running
before the job can start. Do not assign a start time for a job in a box if the box will not be running at that
time. If you do, the next time the box starts the job will start immediately.
The following example illustrates a scenario that would not work properly if placed in a box.
"job_a" is defined to run repeatedly until it succeeds. "job_report" has one starting condition-the
success of "job_a".
How Job Status Changes Affect Box Status
If a box that is not running contains a job that changes status, as a result of a FORCE_STARTJOB or
CHANGE_STATUS event, the new job status could change the status of its container box. A change of
status of the box could trigger the start of downstream jobs that are dependent on the box.
If a box contained only one job, and the job changed status, the box status would change.

I know date +'%Y%m%d' will give me the date in YYYYMMDD format and wc -l <filename> would give me
record count but how would I go about piping the output of the above to one control file that is what I
need to find out.

Create a Shell Script and call it from the post session command
- In the Shell script, have the following command:

fl=`wc -l filname`
fl=date +'%Y%m%d' $fl
touch $fl

Try this... It should solve your problem.

You DON'T NEED to create a shell script. You can execute this as a Single Unix Command....

p1=`wc -l file.txt`;p2=`date +'%Y%m%d'` || cat $p1$p2 > ctlfile

printf '%s%10s\n' `date '+%Y%m%d'` `wc -l < filename.dat` > filename.ctl

Ther are as follows.

1.printf '%s%10s\n' `date '+%Y%m%d'` `wc -l < filename.dat` > filename.ctl

2.wc -l filename.dat| awk '{print $1}' >final.txt |date'+%Y%m%d'>>filename.ctl

3.p1=`wc -l filename.dat`;p2=`date +'%Y%m%d'` || cat $p1$p2 > filename.ctl

In the below post the third option didnt work because they have used a single pipe symbol"|" but you
should use "||" double pipe symbol for the third command to work(It wokred ..!!)
I found the 2nd command.

You can achieve this in one command, if you want to keep it simple:

echo `cat filename | wc -l` `date +%Y%m%d` > ctlfile

If you dont want any delimiter to separate the count and date, then simply delete the space between wc
-l` and `date..

PMREP
INFASETUP
INFAREP
INFACMD

c



9   



3  :


 


) c 

 

  


 
 
3;

 5/c')c/c)c)('/05
:9

 <



 
!3/
 

 < 




= < <:




"3






 <
 
#3





 


   <:

.00'c.0

> : 
 
<
 


there are 2 ways to run the shell script in Informatica: either through command task or pre/post- session
command.Pre- and post-session commands are executed using the C library routine 'system()'. The
command line is passed directly to a Unix shell to execute.Run 'man system()' on UNIX for more details.
while Command tasks are executed by running the following command:
sh -c "command_line_entry" The double quotes are explicitly added by the PowerCenter Server.

This is 6.1 syntax:

#!/bin/ksh

# This script will call Informatica if the backward migration is successful

. /lvol002/app/tumss/bin/tumss_config
check_result ()
{
if [[ $1 == 0 ]]
then
mailx -s "$2" $email_address << EOF
EOF
else
mailx -s "$2: Failed" $email_address << EOF
EOF
exit 1
fi
}

par_file=$Tumss30_PARAMETER_DIR/backward_par

pmcmd startworkflow -s hydra:$PM_PORT -u $PM_USER -p $PM_PW -f TUMSS \

-paramfile $par_file -wait b_TUMSS_backward_migration
check_result $? "Started the creation of ASCII Files for Backward"

This is 5.1 syntax:

#!/bin/ksh

# This script will call Informatica if the backward migration is successful

. /lvol002/app/tumss/bin/tumss_config

check_result ()
{
if [[ $1 == 0 ]]
then
mailx -s "$2" $email_address << EOF
EOF
else
mailx -s "$2: Failed" $email_address << EOF
EOF
exit 1
fi
}
sSessionFlag=$1
sWaitFlag=$2
PM_PROCESS=start
folder_name=TUMSS
batch_name=b_TUMSS_backward_migration
par_file=$Tumss30_PARAMETER_DIR/backward_par

pmcmd $PM_PROCESS $PM_USER $PM_PW $PM_PORT

$folder_name:$batch_name:pf=$par_file $sSessionFlag $sWaitFlag

)
)



 < 
   
 
 <

?c



?c
 


?c
 
 < 
 
 ?c




 <  ?c




 
:




?c
<

 
 

3)


 :




 <

  
 
 
 

3c





 

<
 $

 % 

  
 

 
 9

<
 





= = 
=
=