//*****TCS Internal*******

FOR REBOOTING REMOTE PC :

shutdown -t 0 -r -f
for chkng the completion of job------------
ca7stm------
lprrn,job=job_id
command to chck autosubspe
ps -ef|grep autosubspe
if process is not in running state than
cd /ftp_data
ls
than cd mtsx02v(means put here that name of the domain in which u are currently
present)
ls
than just copy that job or chain name and jst paste it and enter
if it is still not submitted
than write nohup /bin/csh -f /appworx02/autosub/autosubspe(just copy this path f
rom that server where auto subspe is up)and nw put enter
may be this tym it will definitely goes up
Starting agents or automation engine :startso <agent name>
stoping agents or automation engine :stopso <agent name>
to check to memory status on all the servers : df -h
###in upgradation : two files are important in site directorie.
cd /home_dir/site
(1)sosite
(2)awenv.ini
query to findout module name and prompts value with the help of dataset.
select a.so_module, b.so_prompt_dflt from so_job_table a ,so_job_prompts b where
a.so_job_seq=b.so_job_seq and so_prompt_dflt LIKE '%G1Q700AP.Q7CMS200.WEBFILE%'
;
query to findout chain name with the help of dataset.
select distinct c.so_module, a.so_det_arg from so_chain_args a, so_chain_detail
b, so_job_table c where a.so_det_seq = b.so_det_seq and trim(replace(a.so_det_ar
g,'''')) in ('G1QI00AP.QICTBRDG.CHANGES') and c.so_job_seq = b.so_chain_seq;
query to find job name with the help of script name or vise versa :
select so_module,so_program from so_job_table where so_program like '%sftp_mf.sh
%'.
_+++++
'G1QE00AP.NA.FI.DOWNLOAD.INVOICE'
_+++++
below one is for modules that are used in any chains 8:40 AM
select so_module, so_prompt, so_prompt_descr, so_prompt_dflt
from so_job_prompts a, so_job_table b
where a.so_job_seq = b.so_job_seq and lower(so_prompt_dflt) like '%history_15361
4.csv%';

above query is for chain's prompts
select A.SO_MODULE Chain_Name,
(select so_module from so_job_table where so_job_seq = B.SO_JOB_SEQ) Module_
Name,
B.SO_TASK_NAME Chain_Component_Name,
C.SO_DET_ARG_NO Prompt_Number,
D.SO_PROMPT_DESCR Prompt_Description,
D.SO_PROMPT_DFLT Prompt_Default_Value,
C.SO_DET_ARG Prompt_Actual_Value
from so_job_table A, SO_CHAIN_DETAIL B, so_chain_args C, SO_JOB_PROMPTS D
where A.SO_JOB_SEQ = B.SO_CHAIN_SEQ AND
B.SO_DET_SEQ = C.SO_DET_SEQ AND
D.SO_JOB_SEQ = B.SO_JOB_SEQ AND
D.SO_PROMPT = C.SO_DET_ARG_NO
AND (lower(D.SO_PROMPT_DFLT) like '%volvoord.txt%' or lower(C.SO_DET_ARG) like
'%volvoord.txt%') order by (select so_module from so_job_table where so_job_seq
= B.SO_JOB_SEQ);

remote agent on test and QA domain 1 has been created 8:45 PM
test remote agent is on cmfalgadtdb04
QA remote agent is on cmfalgaqqdb04 8:47 PM
password for appworx ID cmfalgadtdb04 - Mum11b@i
cmfalgaqqdb04 - ind@11re 8:47 PM
you can login and check 8:48 PM
it is same as we have in prod
(*) select sid, username, server from v$session where username='SQLOPER';
(*) location of tnsnames.ora and listner.ora files.
cd /oracle/app/oracle/product/10105/network/admin
-------------------------------------------------------------------------------
The function of the program type is to set up the environment necessary for the
program to run properly as well as pass desired data to the program.
To provide a link between the Applications Manager program type and the program
you want to
run, you write a custom program type script
Six Main Tasks
The program type script must perform all the main work of running the task. Spec
ifically, the
interface script must accomplish six main tasks:
1.
Program execution
2.
Parameter passing
3.
Error determination
4.
Output registration
5.
Debug/administration
6.
Termination
Program execution
6
Accomplished with the eval
command. Note that arg includes the $program variable.
Parameter passing
5
Accomplished with ONELINE and
$par.
Error determination
7, 10, 15, 17
The code err=$? traps the exit status
of the last command executed.
Output registration
9, 14
Accomplished by FILESIZE.
Debug/administration
---
Not present in this script.
Termination
17
Accomplished with exit command.
$err traps exit code.
------------------------------------------------------------------
Searching for Text Strings
Some processes such as FTP and Oracle may have errors, but still exit with a zer
o exit value.
With these types of processes, you may have to search for specific text strings
in the log files to determine whether the process completed successfully. One ex
ample of this is illustrated within the FTP program type script by the following
lines:
#grep for "transfer complete" from ftp sysout
#and count the lines returned
check=`cat ftp.$seq_no|grep -i 'transfer complete'|wc -l`

#if no 'transfer complete' lines were found

#the ftp was not successfull
if [ $check -eq 0 ]; then

#set the return status to non zero and display message

echo "Error detected"

err=2
fi
--------------------------------------------------------------------------------
---------------
In Applications Manager, the shell scripts are called run-time extensions.
--------------------------------------------------------------------------------
--------------------
Taking Actions on Tasks
To take actions on one or more tasks, use the
awexe aw_quemgr call.
Format
awexe aw_quemgr tranmode=<letter> jobids=<space separated run_ids
inside single quotes> so_user_name=<Applications Manager user name> password=<use
r password>
The following tranmode letters correspond to an action:
H
Hold task(s) RReset task(s) DDelete task(s) KKill task(s)
Example
In the example below, user
PBROWN deletes run_id 65711.00.
> awexe aw_quemgr tranmode=D jobids=65711.00 so_user_name=PBROWN
password=8uwc76
Success
jobids processed
--------------------------------------------------------------------------------
-----------------------------------------------------------------
Getting Process Flow Names from Component Run IDs
Format
awexe get_chain_name jobid=<run ID number>
Example
An example is shown below.
> awexe get_chain_name jobid=689046
SAMPLE
-------------------------------------------------------------------
Retrieving a Substitution Variable
Format
awexe get_var_value subvar=<subvar name>
Example
In the example below, the value for the
#today substitution is returned.
> awexe get_var_value subvar=#today
27-jan-09
--------------------------------------------------------------------------------
Viewing a Queue Summary
awexe q
The
awexe q call returns the following columns: queue, max threads, tasks in the Bac
klog, active or inactive status, priority, and thread schedule sequence
--------------------------------------------------------------------------------
------------------------------------------------------
Viewing Tasks in the Backlog
awexe jq
-----------------------------------------------------------
Viewing Tasks in History

awexe jh
-------------------------------------------------------
Viewing an RMI and Agent Connection Summary
awexe rmi_status
--------------------------------------------------------
Viewing an Applications Manager User Login Report
awexe show_users
--------------------------------------------------------------
Administration-1.8
automation engine, agents, RMI server, and Web server
UC4 _client _login _report
At client start-up, the client will connect to the RMI server specified in Optio
ns.properties file
location of Options.properties file is /home/web/classes
Automation Engine--
The automation engine is the execution logic or brain of Applications Manager. I
t monitors job
and process flow schedules and, at the appropriate time, sends them to the desig
nated local or remote agent for execution. The automation engine communicates wi
th the Applications Manager database, where all object definitions are stored.
Local Agent--
At a minimum, a basic Applications Manager setup will include a single automatio
n engine and
its local agent. The local agent runs programs or executes scripts on the host m
achine where the Applications Manager automation engine is installed. It receive
s commands from the automation engine.
Applications Manager Database--
Applications Manager uses object definitions stored in an Oracle database to giv
e it an
advantage over all other schedulers. When you create a job, process flow, or oth
er Applications Manager object, the definition is stored in the Applications Man
ager Oracle relational database. You can then use the objects to build more comp
lex objects. For example, you might define a database login, then assign that lo
gin to many different jobs. If the login changes, you change it in one place, an
d Applications Manager uses the new definition everywhere it is referenced. This
object-oriented approach makes it easy to update and maintain the Applications
Manager system.
Client--
You access Applications Manager through a Java client. The client machine is the
PC used to
access the Applications Manager graphical user interface. This means you can acc
ess Applications Manager from any PC, Apple Macintosh, or Sun Workstation that h
as a Web browser. Client software provides access to all Applications Manager fu
nctions and features. The clients communicate directly with the Applications Man
ager automation engine. You can have any number of clients.
Remote Agent--
In larger systems, you may have one or more Applications Manager remote agents o
n other
servers. A remote agent must be installed on each machine where tasks are execut
ed. Any number of remote agents can report to a single automation engine. Remote
agents may run on UNIX, Windows, VMS, and OS/400 platforms.
The automation engine will schedule and control task execution on all the agents
assigned to it.
The agent monitors tasks until they complete.
RMI Server : The RMI Server is the process that servers information to the Java
client and runs the
Applications Manager automation engine. It connects to Oracle instances through
JDBC over SQL*Net.
________________________________________________________________________________
______
Basic Steps for Installing an Applications Manager Remote Agent
The basic steps for installing a remote agent are:
1. Define the remote agent object in Applications Manager.
2. Create a user login.
3. Install the Applications Manager remote agent software.
4. Start the Network Listener Service (for Windows).
5. Verify the installation.
Step 1 is described in
topic 4.2 Defining Remote Agents. Steps 2-5 are described in the Installation Gu
ide.
________________________________________________________________________________
________
**All Applications Manager agents are now multi-threaded Java agents. There are
no longer C
agents. The AgentService process runs on all agents. The awcomm process runs onl
y on the automation engine machine. Normally an additional process called RmiSer
ver is also run on the automation engine machine.
There is only one network connection between an agent and the RMI server and tha
t connection
is always initiated by the AgentService process. This connection supports two wa
y communications. That is to say the RMI server can communicate with the remote
AgentService over the same port. This also functions as automatic agent failover
in the event of the automation engines RMI server failing.
The WatchWorx Process
When started, the WatchWorx process monitors all other Applications Manager proc
esses on an
agent or automation engine and attempts to restart them if they go down. For mor
e information, see topic 8.3 The watchworx Process.
The awcomm Process
The
awcomm process provides a port directory service for the automation engine machi
ne. It stores the name of each automation engine and its listening port, and mak
es it available to AgentService processes. There is no awcomm on remote agent ma
chines and there is usually one awcomm process on an automation engine machine.
For more information on the awcomm process, see topic 8.4 The awcomm Process.
The AgentService Process
The
AgentService process establishes a unique port. The port communicates with the R
miServer processe(s). If the port numbers are not specified in the awenv.ini fil
e, Applications Manager will determine the first available port between 49152 an
d 65535. AgentService performs required agent functions to launch, manage, and m
onitor tasks as instructed by the automation engine. AgentService also services
requests to view local output.
The
AgentService process for the automation engines local agent connects directly to
the database, but the AgentService processes for remote agents connect to the au
tomation engines RmiServer process.
The
AgentService process functions as automatic agent failover in the event of the a
utomation engines RMI server failing provided an additional RmiServer process is
online.
Automation Engine/RmiServer Process
The RMI server for the Applications Manager automation engine is responsible for
initiating
and monitoring task execution. Because the automation engine is incorporated wit
h the RMI server, there is no separate automation engine process.
The automation engine monitors the Applications Manager task queue and job/proce
ss flow
schedules and determines when scheduled tasks are eligible for execution. When a
task is eligible for execution, the automation engine collects the necessary in
formation from the database. Then the automation engine requests that the agents
AgentService process create the pr and pm program execution files and launches t
he pm script. After the task has been launched, the AgentService process monitor
s the task until it goes to completion.
The RMI Server process serves out information to the Applications Manager Java c
lient. It gets
its Oracle SQL*Net connect information from the awenv.ini file in the site direc
tory, and decrypts its login information from the Masters.properties file. For m
ore information on the RmiServer process
The program execution processes include
awexe and awrun. Program execution processes run only when executed, whereas the
other processes are persistent.
The awexe process allows you to issue various Applications Manager functions fro
m the operating system command line or from scripts
The awrun process allows you to submit tasks from the command line or in scripts
.
To check if a specific port is being used, issue the following command:
netstat -an|grep <port number>
The awcomm process is the first process that is brought up when you execute the
startso command
if it is not already running. It reads recovery information from the net_conn.d
at file in the data directory.
DependenciesFor the RmiServer process to work correctly, the following condition
s must be met:
The awcomm and automation engines AgentService process must be up and running to
get the database SID connection information.
Net8 (SQL*Net) must be running for the RMI server target database.
______________________________________________________________________________
master.properties : appworx/data
options.properties:appworx/web/classes
keyfile.in :appworx/data---that is vendor manangement License , with out this Ap
pworx will not work
While purchasing the Product, UC4 will give us keyes/license to use the product
______________________________________________________________________________
3. The automation engine initiates the program execution sequence by requesting
the AgentService process.
The AgentService process creates the pr (task parameters) and pm (task environme
nt variables) files.
The pm file initiates the BODY script
________________________________
The awexe process is used for the product install, import and export, task start
ing and
completion, and startso and stopso commands.
The awexe process is what is known as a thin client. It connects to the AgentServi
ce process.
The awexe process can only run items that are listed in the awserver_sql.dat and
awserver_sqlusr.dat files in the Applications Manager data directory.
The proper variables (AW_HOME, AGENT, PATH=$AW_HOME/bin:$PATH) must be set for t
hem to execute correctly, an Applications Manager user must exist that matches t
he OS user, and the user must have the correct Awexe Range.
Awexe calls are used for the install, import and export, the command line utilit
y, task starting and completion, startso and stopso, etc.
Starting/Running Routine
The awexe process submits requests to AgentService. To see if the OS user can ex
ecute the statement, the AgentService process validates the operating system (OS
) user and the awexe command number against the range of allowable commands assi
gned to the user.
If the permissions are correct, the statement is executed and the results are pa
ssed back to awexe.
eMeasure for Middleware : B-2013-132783
eMeasure for DBA : B-2013-132784