253 r11 3 5 Cookbook

TECHNICAL PAPER: CA Workload Automation AE r11.3.
5 Support Cookbook
CA Workload Automation
AE r11.3.5 Support
Cookbook
The information in this document is usable on all WA AE certified Linux,
UNIX, and Windows platforms. It is verified for 11.3.5 and 11.3.5
Incremental 1 versions.
MARCH 2013
David W. Martin
Joseph E. Neumann
Lee Peterson
CA Workload Automation Development and Support Teams

Page 2
Updated March 15, 2013, 12:32 EST.
This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to as the
“Documentation”) is for your informational purposes only and is subject to change or withdrawal by CA at any time.
This Documentation may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior
written consent of CA. This Documentation is confidential and proprietary information of CA and may not be disclosed by you or used for
any purpose other than as may be permitted in (i) a separate agreement between you and CA governing your use of the CA software to
which the Documentation relates; or (ii) a separate confidentiality agreement between you and CA.
Notwithstanding the foregoing, if you are a licensed user of the software product(s) addressed in the Documentation, you may print or
otherwise make available a reasonable number of copies of the Documentation for internal use by you and your employees in connection
with that software, provided that all CA copyright notices and legends are affixed to each reproduced copy.
The right to print or otherwise make available copies of the Documentation is limited to the period during which the applicable license for
such software remains in full force and effect. Should the license terminate for any reason, it is your responsibility to certify in writing to
CA that all copies and partial copies of the Documentation have been returned to CA or destroyed.
TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION “AS IS” WITHOUT WARRANTY OF ANY KIND,
INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE, DIRECT OR INDIRECT,
FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, LOST INVESTMENT, BUSINESS INTERRUPTION,
GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED IN ADVANCE OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE.
The use of any software product referenced in the Documentation is governed by the applicable license agreement and such license
agreement is not modified in any way by the terms of this notice.
The manufacturer of this Documentation is CA.
Provided with “Restricted Rights.” Use, duplication or disclosure by the United States Government is subject to the restrictions set forth
in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section 252.227-7014(b)(3), as applicable, or their successors.
Copyright © 2013 CA. All rights reserved. All trademarks, trade names, service marks, and logos referenced herein belong to their
respective companies.
CA Workload Automation AE r11.3.5 – Support Cookbook

Page 3
Table of Contents
EXECUTIVE SUMMARY 4
Challenge 4
Opportunity 4
Benefits 4
Section 1: CA CDF Topic 5
CA CDF Usage 5
CA CDF Example 6
Section 2: Install Caveats To Be Aware Of 9
EEM Install and A Non-root User 9
EEM Install and IPv6 10
Section 3: AE Topics 11
AE Directory and File Permissions 11
Upgrade AutoSys and WCC 13
General Principles 13
Upgrade Steps 13
Upgrade the CA EEM Server 15
Upgrade from AutoSys 4.5x or r11 to AE r11.3.5 16
Upgrade AutoSys 4.5x or r11 to AE r11.3.5 (Oracle) 16
Upgrade from AE r11.3 to AE r11.3.5 33
Upgrade AE r11.3 to AE r11.3.5 (Oracle) 34
Upgrade AE r11.3 to AE r11.3.5 (Sybase) 42
AE r11.3.5 Port Architecture 51
Repair an AE r11.3.5 Installation 52
Use the DataMover Application for Data Migrations 59
Unattended AE Install Failure Return Code Meanings 61
Create Oracle Tablespaces, Users, and Roles 63
Configure an Agent to be Compatible with AE 65
Clean Up After a Catastrophic Install or Uninstall Failure 68
Perform ‘sendevent’ in Batch 74
Debug Options, Environment Variables, and Tracing 75
AE Installation Environment Variables 75
AE Installation Tracing 76
AE Interview Forward and Backward Navigation Logic Flow 79
AE Interview Database Connection Test 81
Section 4: Benefits 82
Assist the Customer – Enable Technical Support 82
Assist the Customer 82
Enable Technical Support 82
Section 5 82
Conclusions 82
Section 6 82
References 82
Section 7 83
About the Authors 83

Page 4
Executive Summary
Challenge
New releases of the WA AE product have had a number of significant architectural changes to the product to improve its
performance and robustness. These changes have resulted in differences in production installation and migration including
an increase in information that is required to be specified. Though the bulk of the information is listed in the various
platform Installation Guides, User Reference Manuals and specific Release Notes, an overall walkthrough of the install has
not always been readily available in one place. This direct walkthrough document is being made available here.
This document will not only help customers prepare for and perform installs, but it will help provide discussion points for
CA Technologies Technical Support (Level 1 support) staff when customers call in with problems they encountered. By
indicating where specifically in the install a problem arose, and what it was, Level 1 Support will better able to resolve
installation and migration issues in less time.
Opportunity
As opportunities are discovered that can improve product installation and migration, they will be incorporated within
this document. Thus this document is expected to be updated over time to continue to provide the most current steps to
successfully complete an installation and migration.
Benefits
Creating the CA Workload Automation AE r11.3.5 cookbook before the product is released as generally available gives
customers and Technical Support an important advantage, as a new set of questions and concerns will begin to emerge.
Being equipped with knowledge and results from those who have already experienced these situations, or who have
answered the questions, gives Technical Support the tools to resolve concerns and answer questions. The end result is a
satisfied customer and a confident and helpful Technical Support representative.

Page 5
Section 1: CACDF Topic
CA CDF Usage
The CA Common Diagnostic facility (CA CDF) is a tool provided by CA Technologies to automate the collection of problem-
solving diagnostic data for a customer’s installed CA Technologies software products. CA Workload Automation AE (AE)
leverages the capabilities of CA CDF, and therefore, is shipped on the DVD. The intent of CA CDF is to:
 Minimize the amount of time required to collect the appropriate data
 Standardize the type of data collected
 Reduce the amount of customer skills required to process diagnostic data
This section provides the essential information to gather AE diagnostic data and log files. The latest version of CA CDF can
be downloaded at: http://cacdf.ca.com. For additional information about CA CDF, including design documents, please refer
to the official guide, CA CDF Script File Command Syntax Guide, located at the following link:
https://km.ca.com/technicalsupport/advisors/CACDF/Shared%20Documents/CACDF%20Docs/cacdf_internal_support_guid
e_2012Dec16.docx
To use CA CDF to gather diagnostic information about AE
1. CA CDF is not installed on the server when the AE components are installed. Rather, CA CDF is located on the DVD in
the CACDF directory. For example:
# [/bld/dev/prod/WAAE/11.3.5/build/unix/DVD] ls
acknowledgements.txt AIX CACDF Documentation HP-UX HP-UX_IA64 Linux Solaris-Sparc VendorEULA.txt
wa_setup.sh
In the CACDF directory is a “gz” tar file. For example:

# [/bld/dev/prod/WAAE/11.3.5/build/unix/DVD] ls CACDF
cacdf.tar.gz
To use CA CDF, you must copy the cacdf.tar.gz file to a directory on the server and extract it. For example, to copy the
file to /tmp and extract it, run the following commands:
# cp CACDF/cacdf.tar.gz /tmp
# cd /tmp
# gunzip cacdf.tar.gz
# tar xf cacdf.tar
2. The contents of the extracted tar file are listed below.

# ls
cacdf cacdf.tar README.txt
# cd /tmp/cacdf
# ls
ac.txt d2d.txt mswin32 SCC.txt
aix docfile.txt NSM_ADEM.txt scriptpw.exe
apm.txt drivearray.vbs NSM_ATECH.txt ServerAutomation.txt
arcserve.txt dsm.txt NSM_DIA.txt Service_Desk.txt
Audit.txt DVS.txt NSM_DSM.txt SOI.txt
CACDF_Automation_File_Gen.vbs EEM.txt NSM_EM_UNIX.txt solaris
cacdf.cmd GenCACDFTemplate.sh NSM_JMO.txt sso.txt
CACDF_Keys_Extractor_32bit.vbs getdrwatson.vbs NSM_WEBGUI.txt treeview.css
CACDF_Keys_Extractor_64bit.vbs getevents.vbs NSM_WORLDVIEW.txt treeview.dtd
CACDF_Keys_Extractor.vbs gethwinfo.vbs osdoc_AIX.txt treeview-explorer.xml

Page 6
cacdf.sh getprod.vbs osdoc_HPUX.txt treeview.js

CAPC.txt getsoftfeat.vbs osdoc_Linux.txt treeview.xslt
cappm.txt hpux osdoc_Solaris.txt UCMonitor.txt
caprodreg.vbs httpget.cmd osdoc_Windows 2000.txt version.txt
caprodregxml.vbs httpget.sh osdoc_Windows 2003.txt WAAE.txt
Catalyst_CACDF_Template.txt Hyperformix_CCC.sql osdoc_Windows.txt WCC.txt
catalystpost.cmd Hyperformix_CCC.txt osdoc_Windows Vista.txt wily.txt
catalystpost.sh IMDataAggregator.txt osdoc_Windows XP.txt xosoft.txt
catalystpre.cmd imgs PAM.txt
catalystpre.sh ini_it.vbs pw.vbs
cca.txt linux README.txt
The two files of interest are cacdf.sh and WAAE.txt. The cacdf.sh script collects the information based on what is
contained in WAAE.txt. If you edit WAAE.txt, you will see a number of commands and a number of files. One of the
commands, as_info -a is the gathers most of the information.
To run CA CDF, first set the AE environment and then run the cacdf.sh script. For example:
# . /opt/CA/WorkloadAutomationAE/autouser.ACE/*bash*
# ./cacdf.sh
You are prompted to enter the following information so that the proper information can be gathered and compressed
into the zip file:
 CA Support Contact Number
 CA Support Issue Number
 CA Site ID
 CA Product for which problem was opened
To gather diagnostic information for AE, enter WAAE when you are prompted for the name of the CA product that is
affected. Also, you can gather information for Embedded Entitlements Manager or Workload Command Center
diagnosis by entering, respectively, EEM or WCC.
Once this information has been entered and validated, the utility may take several minutes to scan the environment
and collect files. It builds a zip file with the name generated based on the contact number and the issue number, with
an added sequence number in case another zip file has already been created for that issue. The cacdf.sh script then
uses secure FTP to connect to the CA Technologies support FTP site and upload the zip file.
Note: Before running cacdf.sh (to use the FTP option), you must have reported the issue to CA Technologies support
and have a directory created on the CA Technologies support FTP site to receive the data.
CA CDF Example
The following example illustrates running cacdf.sh and supplying the appropriate command line input to gather diagnostic
information for AE. In this example, the zip file is not sent to the CA FTP site.
# cd /tmp/cacdf
# . /opt/CA/WorkloadAutomationAE/autouser.ACE/*bash* # Set the AE environment.
# ./cacdf.sh # Run the collector.
CA Problem Documentation Collection Utility
Enter your CA Contact Number > 2601
Enter CA issue number (01) > 21109890
Enter your CA Site ID number > 012
Do you want to send the zip file to the CA FTP site? (y|N) > N
Enter the name of the CA product that is affected > WAAE
Contact number is 2601
Issue number is 21109890
Site ID number is 012

Page 7
CA Product is WAAE
DO NOT Send file to CA FTP site.
Is this correct?(Y|n) > Y
Answers are correct
Version 1.59
Date/Time is Fri Nov 2 15:51:31 2012
Creating ZIP file with doc for CA Contact 2601 Issue 21109890 SiteID 012
Adding file to list: /etc/services
Adding file to list: /etc/profile
Adding file to list: /etc/auto.*
Adding file to list: /etc/profile.CA
Adding file to list: /tmp/as_info_dir/waae_file_collection.tar
Adding file to list: /opt/CA/WorkloadAutomationAE/autouser.ACE/autosys.*
Adding file to list: /opt/CA/WorkloadAutomationAE/autouser.ACE/config.ACE
Adding file to list: /opt/CA/WorkloadAutomationAE/autouser.ACE/*.config
Adding file to list: /opt/CA/WorkloadAutomationAE/autouser.ACE/out/DBMaint.out
Adding file to list: /opt/CA/WorkloadAutomationAE/autouser.ACE/out/event_demon.ACE
Adding file to list: /opt/CA/WorkloadAutomationAE/autouser.ACE/out/Num*
Adding file to list: /opt/CA/WorkloadAutomationAE/autouser.ACE/out/as_server.ACE
Adding file to list: /opt/CA/WorkloadAutomationAE/autouser.ACE/webserver/conf/server.xml
Adding file to list: /opt/CA/WorkloadAutomationAE/autouser.ACE/webserver/conf/wrapper.conf
Adding file to list: /opt/CA/WorkloadAutomationAE/autouser.ACE/webserver/conf/logon.conf
Adding file to list: /opt/CA/WorkloadAutomationAE/autouser.ACE/out/waae_webservices*
Adding file to list: /opt/CA/WorkloadAutomationAE/autosys/../SystemAgent/*/agentparm.txt
Adding file to list: /opt/CA/WorkloadAutomationAE/autosys/../SystemAgent/*/log/*
Adding file to list: /opt/CA/SharedComponents/iTechnology/iGateway.log
Adding file to list: /opt/CA/SharedComponents/iTechnology/igwInstall.log
Adding file to list: /opt/CA/SharedComponents/iTechnology/logs/install/*.log
Adding file to list: /opt/CA/SharedComponents/Csam/SockAdapter/version.txt
Adding file to list: /opt/CA/SharedComponents/Csam/SockAdapter/log/*
Adding file to list: autosys_dir.txt
Adding file to list: autouser_dir.txt
Adding file to list: webserver_dir.txt
Adding file to list: agent_dir.txt
Adding file to list: csam_dir.txt
Adding file to list: treeview.css
Adding file to list: treeview.dtd
Adding file to list: treeview.js
Adding file to list: treeview.xslt
Adding file to list: imgs/*.gif
Adding file to list: probinfo.txt
Preparing to execute diagnostic command: cat /proc/version
Preparing to execute diagnostic command: cat /proc/cpuinfo
Preparing to execute diagnostic command: cat /proc/meminfo
Preparing to execute diagnostic command: cat /proc/devices
Preparing to execute diagnostic command: cat /proc/interrupts
Preparing to execute diagnostic command: cat /proc/diskstats
Preparing to execute diagnostic command: cat /proc/partitions
Preparing to execute diagnostic command: cat /proc/modules
Preparing to execute diagnostic command: cat /proc/swaps
Preparing to execute diagnostic command: cat /proc/vmstat
Preparing to execute diagnostic command: cat /proc/iomem
Preparing to execute diagnostic command: cat /proc/ioports
Preparing to execute diagnostic command: cat /proc/zoneinfo
Preparing to execute diagnostic command: cat /proc/loadavg
Preparing to execute diagnostic command: cat /proc/config.gz

Page 8
Preparing to execute diagnostic command: /bin/df –k

Preparing to execute diagnostic command: /sbin/ifconfig –a
Preparing to execute diagnostic command: uname –a
Preparing to execute diagnostic command: /bin/netstat –a
Preparing to execute diagnostic command: /bin/ps –ef
Preparing to execute diagnostic command: /sbin/lspci –vvv
Preparing to execute diagnostic command: /sbin/lsusb –vvv
Preparing to execute diagnostic command: /bin/rpm –q –a
Preparing to execute diagnostic command: /bin/dmesg
Preparing to execute diagnostic command: /usr/bin/env
Preparing to execute diagnostic command: /opt/CA/WorkloadAutomationAE/autosys/bin/as_info –a
Preparing to execute diagnostic command: /opt/CA/SharedComponents/bin/unisrvcntr status
Preparing to execute diagnostic command: ps –ef
Preparing to execute diagnostic command: ulimit –a
Preparing to execute diagnostic command: df
Preparing to execute diagnostic command: ls –l /opt/CA/WorkloadAutomationAE/autosys/bin
Preparing to execute diagnostic command: ls –lR /opt/CA/WorkloadAutomationAE/autosys > autosys_dir.txt
Preparing to execute diagnostic command: ls –lR /opt/CA/WorkloadAutomationAE/autouser.ACE > autouser_dir.txt
Preparing to execute diagnostic command: ls –lR /opt/CA/WorkloadAutomationAE/autouser.ACE/webserver >
webserver_dir.txt
Preparing to execute diagnostic command: ls –lR /opt/CA/WorkloadAutomationAE/autosys/../SystemAgent >
agent_dir.txt
Preparing to execute diagnostic command: ls –lR /opt/CA/SharedComponents/Csam/SockAdapter > csam_dir.txt
Preparing to execute diagnostic command: /opt/CA/WorkloadAutomationAE/autosys/bin/autoflags –a
Preparing to execute diagnostic command: /opt/CA/WorkloadAutomationAE/autosys/bin/chk_auto_up –r 111
Preparing to execute diagnostic command: /opt/CA/WorkloadAutomationAE/autosys/bin/autoping –m localhost
Preparing to execute diagnostic command: /opt/CA/WorkloadAutomationAE/autosys/bin/autoping –m localhost –S
Preparing to execute diagnostic command: /opt/CA/WorkloadAutomationAE/autosys/bin/event_demon –x
Preparing to execute diagnostic command: /opt/CA/WorkloadAutomationAE/autosys/bin/as_server –x
Preparing to execute diagnostic command: /opt/CA/WorkloadAutomationAE/autosys/bin/autorep –M ALL
Preparing to execute diagnostic command: /opt/CA/WorkloadAutomationAE/autosys/../SystemAgent/WA_AGENT/cybAgent –v
Preparing to execute diagnostic command: /opt/CA/SharedComponents/Csam/SockAdapter/bin/csampmuxf status
Preparing to execute diagnostic command: /opt/CA/SharedComponents/Csam/SockAdapter/bin/csamconfigedit display
Preparing to execute diagnostic command: /opt/CA/SharedComponents/Csam/SockAdapter/bin/csamconfigedit port=9000
display
Preparing to execute diagnostic command: /opt/CA/SharedComponents/Csam/SockAdapter/bin/csamconfigedit
portrange=49152-50176 display
Adding file to list: diaginfo.txt
The output is stored in a generated zip file in the current directory. (See below for an example of the naming conventions of
the zip file.) This file contains the results of all commands and all specified files by WAAE.txt.
# cd /tmp/cacdf
# ls *zip
2601-21109890-1.zip

Page 9
Section 2: Install Caveats To Be Aware Of
EEM Install and A Non-root User

EEM embeds CA Directory and CA iGateway and calls their respective installers during EEM’s install process. The EEM
installer requires the root login to perform certain OS operations required by CA Directory and iGateway. There is no way
to go around this, except have a 'sudo' to root after being logged in as a non-root user.
Solution
The CA Directory installer requires 'root' privileges to perform a number of installation functions. A lot of these cater for
legacy situations, such as upgrading from CA Ingres to the newer DXgrid back-end, whereas others are required in all cases.
The CA Directory installer can be run under 'sudo' if the user is unable to login interactively as the root user. 'root' privileges
are required for the following:
 Setting file ownership and the setuid bit on 'dxserver' and 'ssld' (ssld is only present prior to r12.0 SP2) to allow
registering ports below 1024.
 Setting file and directory permissions.
 Switching environments and effective userids between 'root', 'dsa' and 'ingres' when upgrading from non-DXgrid
releases.
 Determining the existence of, or creating, the userid 'dsa'.
 Installing CA Shared Components (ETPKI, CA-OpenSSL, etc...).
 Installing system startup scripts (/etc/init.d, /etc/rc?.d).
 Rollback in the event of an installation failure.
iGateway server is a daemon and installs run level scripts so that it can start/stop with the system. It also modifies a file
called /etc/profile.CA which is sourced in /etc/profile file which gets invoked during system startup. Modifying these files
requires root credentials during installation.
On a side note iGateway provides a host based authentication mechanism as well which requires querying shadow
password files which are not allowed for normal users (only allowed for root or equivalent user).
Sudoers has a configurable option to not prompt the user for password. If considering this, be aware that your IT security
organization may have a concern -- of not having a secondary user password challenge. If they do, then they should
configure sudoers to just allow the no password option for the installation command instead of an unqualified switch user.
For example:
less secure -- <sudo su - root>
more secure -- <sudo /path/to/eem-installer.bin>

Page 10
EEM Install and IPv6

As part of the EEM install process, it attempts to get all localhost addresses by using the getaddrinfo command. If a machine
is not configured for IPV6, but it contains ::1 in its /etc/hosts file, the EEM install will fail with the following error:
IPv6: ::1
bind call for host [localhost] resolving to address [::1] failed: Cannot assign requested address
CA has a program that retrieves all localhost addresses. This program is also contained in EEM. You may need to install EEM
in house and send the program to the user to run. For example:
#./testSysIP localhost
IP addresses for localhost:
IPv4: 127.0.0.1
bind suceeded for host: 127.0.0.1
IPv6: ::1
bind call for host [localhost] resolving to address [::1] failed: Cannot assign requested address
Some systems (e.g. Solaris) come with both IPv4 and IPv6 support. However, the user may not want to activate IPv6. If the
EEM install fails with the above error, the user has two options:
1. Completely disable IPv6
2. Activate IPv6
After the user performs one of the above actions, EEM should install.

Page 11
Section 3: AE Topics
AE Directory and File Permissions

In AE r11.3.5, some directories and files are set with excessive permissions or as owner root. The following describes the
current permission setting and what the directories and files can be set to to increase security.
1. The following directories do not require world-writeable permissions.

drwxrwxrwx /opt/CA/SharedComponents/csutils/log
drwxrwxrwx /opt/CA/SharedComponents/tmp
They can be altered to 775.

2. The following files must have root permission to allow non-root users to run unisrvcntr commands. These permissions
must stay as is.
-r-sr-xr-x /opt/CA/SharedComponents/bin/casrvc
-r-sr-xr-x /opt/CA/SharedComponents/bin/uniregister
-r-sr-xr-x /opt/CA/SharedComponents/bin/unisrvcntr
-r-sr-xr-x /opt/CA/SharedComponents/bin/ustat
-r-sr-xr-x /opt/CA/SharedComponents/csutils/bin/casrvc
-r-sr-xr-x /opt/CA/SharedComponents/csutils/bin/unisrvcntr
3. The world-writeable permissions are not required for the PIF-related directories.
drwxrwxrwx /opt/CA/SharedComponents/installer/administration/admi/CA:CCS
drwxrwxrwx /opt/CA/SharedComponents/installer/administration/admi/CA:CCS/1.0.0.0
They can be altered to 775.

4. The files listed below do not require the SETUID flag set.
-r-sr-xr-x /opt/CA/SharedComponents/ca_lic/CAmtype
-r-sr-xr-x /opt/CA/SharedComponents/ca_lic/lic98fds
5. Regarding the CADirectory SETUID settings, to start and stop CA Directory services when it listens to ports less than or
equal to 1024, which ports are restricted by the OS, the SETUID settings are required. By default the CA Directory
default port is 509. However, if CA Directory is installed with a port greater than 1024, the SETUID settings are not
required.
-rwsr-x--- /opt/CA/SharedComponents/CADirectory/dxserver/bin/dxadmind
-rwsr-x--- /opt/CA/SharedComponents/CADirectory/dxserver/bin/dxserver
-rwsr-x--- /opt/CA/SharedComponents/CADirectory/dxserver/bin/dxserver32
-rwsr-x--- /opt/CA/SharedComponents/CADirectory/dxserver/bin/dxserver64
6. The csampmux binary must have the SETUID bit set so that non-root users can run the broker. (Since the non-root user
cannot make any configuration changes in SSA, allowing them to run the broker service alone will not create any
problems.)
-rwsr-xr-x /opt/CA/SharedComponents/Csam/SockAdapter/bin/csampmux

Page 12
Object Name Type Old New Old New

Permission Permission Owner/Group Owner/Group
/opt/CA/WorkloadAutomationAE Dir 777 775 root/root autosys/autosys
/opt/CA/WorkloadAutomationAE/webserver Dir 777 750 - -
$AUTOSYS/install/CAPKI Dir 777 755 - -
$AUTOSYS/install/eiam.server.config File 666 600 - -
$AUTOSYS/install/eiam.client.config File 666 655 - -
$AUTOSYS/install/eiam.ws.config File 666 600 - -
$AUTOSYS/install/logger.server.config File 666 600 - -
$AUTOSYS/install/logger.client.config File 666 655 - -
$AUTOSYS/install/logger.ws.config File 666 600 - -
$AUTOSYS/install/data Dir 777 775 - -
$AUTOSYS/install/webserver Dir 777 750 - -
$AUTOSYS/install/webserver/AEWS Dir 777 750 - -
/opt/CA/WorkloadAutomationAE/CommandSponsor Dir 777 750 - -
/opt/CA/WorkloadAutomationAE/JRE_WA Dir 777 750 root/root autosys/autosys
/opt/CA/WorkloadAutomationAE/JRE_WA/1.6.0_33 Dir 777 750 root/root autosys/autosys
/opt/CA/WorkloadAutomationAE/JRE_WA/1.6.0_33/* Dir & File - - root/root autosys/autosys
/opt/CA/WorkloadAutomationAE/JRE64_WA Dir 777 750 root/root autosys/autosys
/opt/CA/WorkloadAutomationAE/JRE64_WA/1.6.0_33 Dir 777 750 root/root autosys/autosys
/opt/CA/WorkloadAutomationAE/JRE64_WA/1.6.0_33/* Dir & File - - root/root autosys/autosys
$AUTOUSER Dir 777 775 - -
$AUTOUSER /audit Dir 777 +t - -
$AUTOUSER/webserver/webapps/AEWS Dir 777 750 - -
$AUTOUSER/eiam.server.config File 666 600 root/root autosys/autosys
$AUTOUSER/eiam.client.config File 666 655 root/root autosys/autosys
$AUTOUSER/logger.server.config File 666 600 root/root autosys/autosys
$AUTOUSER/logger.client.config File 666 655 root/root autosys/autosys

Page 13
Upgrade AutoSys and WCC
General Principles
When upgrading or migrating from a previous release of AutoSys (including WCC), it is good to follow general principles.
Doing so will reduce the number of problems associated with a typical upgrade or migration. The general principles are
listed below:
1. Read and understand the documentation. In each product’s documentation is a chapter or section dealing specifically
with product upgrades. Make sure that you read and understand all steps associated with upgrading the product,
whether it is AutoSys 4.5x, AutoSys r11, AE r11.3, WCC r11, or WCC r11.3.
2. Take a backup of the product. In case problems are experienced, it is essential that you backup the existing AutoSys or
AE system, including the database, EEM server system, and WCC system before you begin the upgrade process.
3. Be methodical and take your time. Verify that each step was successful. For example, if the AE r11.3 to r11.3.5 calls for
the upgrade of EEM, verify that EEM upgraded successfully before proceeding on with the AE r11.3 to r11.3.5 upgrade.
4. Perform a product verification after the upgrade. Run a test automated workload to validate the upgrade. Report any
discrepancies to determine if they are new behavior or a problem.
Upgrade Steps
The steps and order of upgrade depends on what products you are using. For example, if you are only using AutoSys 4.5x
with no eTrust security or CA Common Components such as CA Event Management, then the upgrade is very simple. The
table below outlines the preferred order of upgrade. NSM refers to CA Common Components in the table. Also, note that
all steps may not be required, depending on which dependent products are installed.
Product to Dependent Products Upgrade Steps to AE r11.3.5, Including WCC r11.3.5

Upgrade
AutoSys 4.5x NSM 3.1, eTrust 1. Upgrade NSM 3.1 to NSM r11.2 SP1 CUM1. (See CA Common Components
Implementation Guide, Release 11.3.5, Chapter 6, for more information.)
2. Upgrade eTrust to EEM r12. (Update to explain the steps in upgrading from
eTrust to EEM r12. There may not be a direct migration path.)
3. Install AE r11.3.5 and select to migrate the AutoSys 4.5x database data
to the AE r11.3.5 database. (See section Upgrade From AutoSys 4.5x or
r11 to AE r11.3.5 in this document for more information.)
4. Install WCC r11.3.5. (See CA Workload Control Center Implementation
Guide, Release 11.3.5, Chapter 4, for more information.)
References:
1. CA Common Components Implementation Guide, Release 11.3.5,
Chapter 6.
2. CA Embedded Entitlements Manager Implementation Guide, Release
12.0, Chapter 5.
3. CA Workload Automation AE UNIX Implementation Guide, Release
11.3.5, Chapter 21.
4. CA Workload Control Center Implementation Guide, Release 11.3.5,
Chapter 4.
Product to Dependent Products Upgrade Steps to AE r11.3.5, Including WCC r11.3.5

Upgrade

Page 14
AutoSys NSM r11, eIAM, 1. Upgrade NSM r11 to NSM r11.2 SP1 CUM1. (See CA Common Components
r11.0 WCC r11 Implementation Guide, Release 11.3.5, Chapter 6 for more information.)
2. Upgrade eIAM to EEM r12. (See section Upgrade the CA EEM Server in
this document for more information. Also, see CA Embedded
Entitlements Manager Implementation Guide, Release 12.0, Chapter 5.)
3. Install AE r11.3.5 and select to migrate the AutoSys r11 database data
to the AE r11.3.5 database. (See section Upgrade From AutoSys 4.5x or
r11 to AE r11.3.5 in this document for more information.)
4. Perform the steps to migrate the WCC r11 objects to WCC r11.3.5. (See
CA Workload Control Center Implementation Guide, Release 11.3.5,
Chapter 4 and 5, for more information.)
References:
Chapter 6.
12.0, Chapter 5.
11.3.5, Chapter 21.
Chapter 4 and 5.
CA AE r11.3 NSM r11.2, EEM 8.4, 1. Upgrade NSM r11.2 to NSM r11.2 SP1 CUM1. (See CA Common Components
WCC r11.3 Implementation Guide, Release 11.3.5, Chapter 6 for more information.)
2. Upgrade EEM 8.4 to EEM r12, depending on the operating system. (See
section Upgrade the CA EEM Server in this document for more
information. Also, see CA Embedded Entitlements Manager
Implementation Guide, Release 12.0, Chapter 5.)
3. Install AE r11.3.5 and select upgrade. (See section Upgrade From AE
r11.3 to AE r11.3.5 in this document for more information.)
5. Perform the steps to migrate the WCC r11.3 objects to WCC r11.3.5.
(See CA Workload Control Center Implementation Guide, Release
11.3.5, Chapter 4 and 5, for more information.)
References:
Chapter 6.
12.0, Chapter 5.
11.3.5, Chapter 21.
Chapter 4 and 5.

Page 15
Upgrade the CA EEM Server

Before upgrading to AE r11.3.5, you must upgrade the CA EEM Server. The normal EEM upgrade path is from EEM 8.4 to
r12. However, several platforms that EEM 8.4 supported are not supported by EEM r12. The following table identifies the
possible upgrade paths (in green). All other operating systems will require that EEM r12 be installed and the EEM 8.4
information be imported into the r12 database.
CA EEM Server Supported Platforms

Operating System EEM r8.4 EEM r12
Red Hat Linux 3 X (32-bit)
Red Hat Linux 5 X (32-bit) X (64-bit)
SUSE Linux 9 X (32-bit)
SUSE Linux 10 X (32-bit) X (64-bit)
SUSE Linux 11 X (64-bit)
SunOS 5.9 X X
SunOS 5.10 X X
SunOS 5.11
AIX 5.3 X X
AIX 6.1 X X
AIX 7
HP-UX 11.11 X
HP-UX 11.23 X
HP-UX 11.31 X X
Windows 2003 SP2 X
Windows 2003 R2 SP2 X
Windows 2008 SP2 X X
Windows 2008 R2 X
- EEM upgrade from r8.4 to r12 is not supported

- EEM upgrade from r8.4 to r12 is supported
- EEM is not supported on this operating system
If, for example, the EEM server is installed on an HP-UX 11.23 system, you must first export the EEM information from the
HP-UX system because EEM r12 cannot be installed on HP-UX 11.23. Next, you must install EEM r12 on an HP-UX 11.31
system. And, finally, you must import the EEM information to the EEM r12 server. Exporting and importing the EEM
information requires that you perform the following steps. The steps are fully described in CA Embedded Entitlements
Manager Implementation Guide, Release 12.0, p. 63-68.
1. Export the CA EEM database to an LDIF file from the existing CA EEM server.
2. Install CA EEM r12.0 on a supported operating system.
3. Import the LDIF file on the CA EEM r12.0 server.
4. Configure the user store. For information about configuring user store, see the CA EEM Server User Stores
Configuration section in CA Embedded Entitlements Manager Implementation Guide, Release 12.0, p. 23.
5. Issue new certificate for each registered application using safex.

Page 16
Upgrade from AutoSys 4.5x or r11 to AE r11.3.5

This section applies only to upgrading from AutoSys 4.5x and r11 to AE r11.3.5. This section supplements the CA Workload
Automation AE UNIX Implementation Guide, Release 11.3.5, pp. 373-383, by showing the panels you will encounter.
Upgrading from AE r11.3 is documented in the next section.
The panels that you navigate when upgrading from AutoSys 4.5x and r11 to AE r11.3.5 are similar to the previous release
(r11.3) with the exception that the Data Migration panels have been simplified. There is only one Data Migration panel with
the AE r11.3.5 upgrade process. The following example shows the panels for an AutoSys r11 upgrade with an Oracle
database. The panels are similar when upgrading with a Sybase database.
Note: Make sure that if you have EEM security activated, you should upgrade the EEM server first. See the section
Upgrade the EEM Server in this document for more information.
Upgrade AutoSys 4.5x or r11 to AE r11.3.5 (Oracle)

# ./wa_setup.sh
Click Next.

Page 17
If there are active AutoSys processes, the Active Components panel displays. Click Next. Otherwise, the License Agreement
panel displays.
Scroll down to the end of the License Agreement, click I Accept the Terms of the License Agreement radio button, and click
Next.

Page 18
Select Upgrade and click Next.
Select the instance to upgrade and click Next.
Note: You can only upgrade one AutoSys 4.5x or r11 instance at a time.

Page 19
A warning is displayed indicating that if you upgrade the selected AutoSys instance, it will no longer be usable as an AutoSys
4.5x or r11 instance. It will be upgraded to an AE r11.3.5 instance. Click Next.
Select the components to install and click Next.

Page 20
Specify the installation directories and click Next. Note that AE r11.3.5 is installed into another directory and not the
directory that AutoSys 4.5x or r11 is in.
Specify the Application Server information. If you selected to install the AE web server, you must also select Activate CA
EEM and Create/Recreate Instance Policy from the CA EEM Security dropdown selection. Click Next.

Page 21
If you selected to use CA EEM security, the CA EEM Properties panel displays. Specify the EEM server name and EEM
EiamAdmin user password. Click Next.
Click Test. If the test is successful, you will see the following panel. Otherwise, an error will display. In this case, click Back
and verify that you specified the correct EEM server name and EiamAdmin user password.

Page 22
Click OK.
Select which application server properties you want and click Next.

Page 23
Select the Migrate the Legacy Unicenter AutoSys Job Management Database check box if you want the AE installer to
migrate the data. In this example, we will select this option to show the Data Migration panel. If you do not select this check
box, you will need to manually migrate the database data using the uajmdatamover.pl utility.
Specify the Oracle database information and click Next.

Page 24
Specify the SYS (or other database administrator) user password and click Next.
Click Test. If the database connection test is successful, the Database Tests panel shows a “success” message. Otherwise,
the SQL error statements are displayed. In this case, click Back and make sure you have specified the correct Oracle
database information.

Page 25
Click OK.
Specify the password to be associated with the Oracle user ‘aedbadmin’ and Oracle user ‘autosys’. Click Next.

Page 26
Specify the Oracle tablespace information. Note that the data and index tablespace paths must exist on the Oracle server.
Currently, there is no validation to see if the directories are present and writable. Click Next.
Specify the scheduler properties and click Next.

Page 27
Specify the agent properties and click Next.
By default, when upgrading from AutoSys 4.5x or r11, the Configure Agent with Legacy Remote Agent Compatibility check
box is selected. (See section Configure an Agent to be Compatible with AE for information on what the AE installer does to
configure the agent in this manner.) Click Next.

Page 28
Specify the source database information.
If you are migrating database data from AutoSys 4.5x, make sure to specify ‘autosys’ in the Database User input area, and
specify the ‘autosys’ password in the Password input area. Otherwise, for AutoSys r11, specify ‘mdbadmin’ as the database
user and specify its password. Click Next. If the specified database information does not allow the AE interviewer to connect
to the source database, the following panel displays.
Scroll down to see the error message. Click Back and correct the information, then click Next again.

Page 29
Specify the owner and group information and click Next.
Review the settings and click Install to install AE r11.3.5 and migrate the legacy database data.

Page 30
After AE r11.3.5 has been installed and the AutoSys database data has been migrated, the following panel displays.
Click Finish. The installation log is found at /opt/CA/installer/log and is called CAWorkloadAutomationAE.install.log. Looking
at the log shows that the Oracle database was created and uajmdatamover.pl was used to successfully migrate the AutoSys
r11 database data.

Page 31
<snip>
perl CreateAEDB.pl SYBASE **sa_user** **sa_pswd** **aedbadmin_pswd** **autosys_pswd**

/opt/CA/WorkloadAutomationAE/JRE_WA/1.6.0_33 /tmp/ora_createaedb_pri Y AEDB_DATA
"/home/oracle/app/oracle/oradata/SYBASE" "800" "AEDB_INDEX" "/home/oracle/app/oracle/oradata/SYBASE" "80"
CreateAEDB: Data tablespace name is AEDB_DATA.
CreateAEDB: Data tablespace path is /home/oracle/app/oracle/oradata/SYBASE.
CreateAEDB: Data tablespace physical name is /home/oracle/app/oracle/oradata/SYBASE/AEDB_DATA.DBF.
CreateAEDB: Data tablespace size is 800.
CreateAEDB: Index tablespace name is AEDB_INDEX.
CreateAEDB: Index tablespace physical name is /home/oracle/app/oracle/oradata/SYBASE/AEDB_INDEX.DBF.
CreateAEDB: Index tablespace size is 80.
CreateAEDB: Creating the AEDB_DATA tablespace.
CreateAEDB: Creating the AEDB_INDEX tablespace.
CreateAEDB: Creating user autosys.
CreateAEDB: Creating the database tables.
CreateAEDB: Creating public synonyms.
CreateAEDB: Creating the database stored procedures.
CreateAEDB: Writing 421 rows of initial database data.
CreateAEDB: Writing 2489 rows of read-only database data.
CreateAEDB: CA Workload Automation AE database created successfully.
<snip>
Invoking Autosys Migration utility. This may take a while based on the size of your installation.
Running CA Workload Automation AE version 11.3.5.408
Testing source connection credentials
Successful.....
The connection string for the source database is: jdbc:oracle:thin:@anyhost-rh55-64:1521:SYBASE with mdbadmin
The source database is version VER_11_0
Retrieved the source security information
Testing target connection credentials
Successful.....
The connection string for the target database is: jdbc:oracle:thin:@anyhost-rh55-64:1521:SYBASE with aedbadmin
The target database is version VER_11_3_5
The target user aedbadmin can truncate
Fri Dec 28 12:28:14 EST 2012 Start Data Copy process using 6 copiers
Fri Dec 28 12:28:14 EST 2012 Creating Connection pool...
Fri Dec 28 12:28:17 EST 2012 Creating Copy threads
Fri Dec 28 12:28:17 EST 2012 Counting rows...
Table ujo_timezones has 366 rows
Table ujo_job_status has 2 rows
Table ujo_keymaster has 3 rows
Table ujo_machine has 1 rows
Table ujo_job_cond has 2 rows
Table ujo_job has 2 rows
Table ujo_last_Eoid_counter has 1 rows
Table ujo_config has 1 rows
Fri Dec 28 12:28:18 EST 2012 There are 378 rows to read
Fri Dec 28 12:28:18 EST 2012 Truncating 88 tables
Fri Dec 28 12:28:20 EST 2012 Tables are truncated
Fri Dec 28 12:28:20 EST 2012 Copying data...
Using copier 0 for transferring job
Using copier 5 for transferring timezones
Using copier 1 for transferring keymaster
Using copier 3 for transferring job_status
Using copier 2 for transferring job_cond
Using copier 4 for transferring machine

Page 32
JobReader Task 0 read 2 from table ujo_job

Reader Task 3 read 2 from table ujo_job_status
Reader Task 4 read 1 from table ujo_machine
UninotifyReader Task 1 read 3 from table ujo_keymaster
AsextReader Task 2 read 2 from table ujo_job_cond
Reader Task 5 read 366 from table ujo_timezones
Writer task 0.1 copied ujo_job read 2 inserted 2 and ignored 0 duplicates.
Writer task 0.3 copied ujo_command_job read 1 inserted 1 and ignored 0 duplicates.
Writer task 0.2 copied ujo_sched_info read 2 inserted 2 and ignored 0 duplicates.
Writer task 0.4 copied ujo_file_watch_job read 0 inserted 0 and ignored 0 duplicates.
Writer task 3.1 copied ujo_job_status read 2 inserted 2 and ignored 0 duplicates.
Using copier 0 for transferring eoid_counter
JobReader Task 0 read 1 from table ujo_last_Eoid_counter
Using copier 3 for transferring config
Read 0 rows out of 0, and wrote 7 rows
Reader Task 3 read 1 from table ujo_config
Writer task 0.1 copied ujo_last_eoid_counter read 1 inserted 1 and ignored 0 duplicates.
Writer task 4.1 copied ujo_machine read 1 inserted 1 and ignored 0 duplicates.
Writer task 1.1 copied ujo_keymaster read 3 inserted 3 and ignored 0 duplicates.
Writer task 3.1 copied ujo_config read 1 inserted 1 and ignored 0 duplicates.
Writer task 2.1 copied ujo_job_cond read 2 inserted 2 and ignored 0 duplicates.
Writer task 5.1 copied ujo_timezones read 366 inserted 15 and ignored 351 duplicates.
Fri Dec 28 12:28:21 EST 2012 Copying data complete
Fri Dec 28 12:28:21 EST 2012 Data is copied...
Total rows to read 378
Total rows read 378
Total rows written 30
Total duplicate rows 351
Fri Dec 28 12:28:21 EST 2012 Running post processing functions...
Fri Dec 28 12:28:21 EST 2012 Updating Virtual machines...
Fri Dec 28 12:28:21 EST 2012 Virtual machines updated
Fri Dec 28 12:28:21 EST 2012 Updating keymaster table...
Fri Dec 28 12:28:21 EST 2012 Updated keymaster table.
Fri Dec 28 12:28:21 EST 2012 Post processing complete
Fri Dec 28 12:28:21 EST 2012 Synchronizing tables...
Fri Dec 28 12:28:21 EST 2012 Updating OverrideJobs...
Fri Dec 28 12:28:21 EST 2012 OverrideJobs updated 0 rows
Fri Dec 28 12:28:21 EST 2012 Updating Box Joids...
Fri Dec 28 12:28:21 EST 2012 Box Joid updated 0 rows
Fri Dec 28 12:28:21 EST 2012 Update Job Flags
Fri Dec 28 12:28:21 EST 2012 Job Flags updated 8 rows
Fri Dec 28 12:28:21 EST 2012 Creating job tree table
Fri Dec 28 12:28:22 EST 2012 Created job tree table
Fri Dec 28 12:28:22 EST 2012 Start Update TriggerType...
Fri Dec 28 12:28:22 EST 2012 TriggerType updated
Fri Dec 28 12:28:22 EST 2012 Updating Virtual Type values...
Fri Dec 28 12:28:22 EST 2012 Updated Virtual Type
Fri Dec 28 12:28:22 EST 2012 Synchronizing complete
Fri Dec 28 12:28:22 EST 2012 Releasing Connection pool...
Fri Dec 28 12:28:22 EST 2012 Released Connection pool
End Data Copy process. Fri Dec 28 12:28:22 EST 2012

Page 33
Upgrade from AE r11.3 to AE r11.3.5

This section applies only to upgrading from AE r11.3 to AE r11.3.5. Upgrading from 4.5x or r11 is documented in the
previous section and also in the CA Workload Automation AE UNIX Implementation Guide, Release 11.3.5, pp. 373-383. This
section is provided to show the panels that you will encounter, and descriptions of the input you will provide. (Also, see CA
Workload Automation AE UNIX Implementation Guide, Release 11.3.5, pp. 384-388.)
It is important to note that if you have AE r11.3 installed, and you start the AE r11.3.5 installer, you are presented with only
two possibilities: upgrade and remove. In other words, you are not permitted to add features or instances to an AE r11.3
system using the AE r11.3.5 installer. Also, all installed r11.3 components are upgraded to r11.3.5, which is normal. But,
only installed r11.3 components are upgraded. In other words, if an AE r11.3 client is installed, you are not permitted to
upgrade the client and install the scheduler in one step. To accomplish that, you must first upgrade the AE r11.3 client to
r11.3.5, and then run the AE r11.3.5 installer again and select Modify, Add Features, and Scheduler.
Note: Make sure that if you have EEM security activated, you should upgrade the EEM server first. See the section
Upgrade the EEM Server in this document for more information.
The following examples show the panels when upgrading an AE r11.3 server using Oracle to AE 11.3.5. Note that the EEM
security was enabled on the AE r11.3 server using autosys_secure prior to upgrading to AE r11.3.5. The procedure to enable
EEM security is shown next, followed by the upgrade panels.
Enable EEM security

1. Log in as the EXEC super user.
2. Source the AE environment by running the following commands.
# [/] cd /opt/CA/WorkloadAutomationAE/autouser.ACE
# [/opt/CA/WorkloadAutomationAE/autouser.ACE] . ./*bash*
3. Run autosys_secure to activate EEM security.

# [/opt/CA/WorkloadAutomationAE/autouser.ACE] autosys_secure
CA WAAE Security Utility
Please select from the following options:

[1] Activate CA EEM instance security.
[2] Manage EDIT/EXEC superusers.
[3] Change database password.
[4] Change remote authentication method.
[5] Manage user@host users.
[6] Get encrypted password.
[0] Exit CA WAAE Security Utility.
> 1
Are you sure you wish to activate EEM security? [1(yes)/0(no)]: 1
Input the EEM server name (or hit enter to cancel): arhel55
CAUAJM_I_60201 EEM instance security successfully set.
Please select from the following options:

[1] Revert to NATIVE instance security.
[2] Manage CA EEM server settings.
[3] Change database password.
[4] Change remote authentication method.
[5] Manage user@host users.
[6] Get encrypted password.
[0] Exit CA WAAE Security Utility.
> 0
[/opt/CA/WorkloadAutomationAE/autouser.ACE]

Page 34
Upgrade AE r11.3 to AE r11.3.5 (Oracle)

# ./wa_setup.sh
Click Next.

Page 35
Next.
If there are active AE processes, the Active Components panel displays. Click Next. Otherwise, the Instance Upgrade
Information panel displays.

Page 36
By default, all information that is necessary for the AE r11.3.5 installer to connect to Oracle for this AE instance is retrieved
from the previous AE r11.3 installation, except for the Oracle database user aedbadmin password. You should not have to
change any of this information. Also, notice the instance name is supplied. If you are upgrading multiple AE instances, you
will be prompted to supply this information for each AE instance.
Specify the aedbadmin database user password and click Next.

Page 37
If the AE r11.3 server does not have EEM security activated, you get this panel informing you of this fact. Click OK.
Otherwise, you get the CA EEM Properties panel.
There is no option to skip upgrading EEM policies if AE r11.3 has EEM security enabled. If you need to skip the EEM security
policy upgrade, you must run autosys_secure and set security to NATIVE. Specify the CA EEM administrator (EiamAdmin)
user password and click Next.
Click Test to verify that the password is correct.

Page 38
If the password is invalid, you get the CAUAJM_E_60246 error message. Click Back to retype the EiamAdmin user password.
If the password is valid, the CA EEM Server Connection Test panel shows with a Success message.
Click OK.
If you are upgrading multiple AE instances, the next instance’s database connection information displays in the Upgrade
Instance Information panel. When you have supplied all AE instances’ information, the Configuration Files panel displays.

Page 39
On an upgrade, the default behavior is for the AE r11.3.5 installer to reuse the existing agent configuration files and
instance profile files. The reason why this option is needed during the upgrade is because the agent does not have the
ability to “upgrade”. In other words, when the AE r11.3.5 installer “upgrades” the agent, it uninstalls the agent, then installs
the new agent. In the process of uninstalling, the configuration files and profile files are removed.
If you choose not to use the default behavior, and deselect the Reuse Existing Configuration File check box, the Configure
Agent with Legacy Remote Agent Compatibility check box is enabled. You may want the agent to behave similarly to the
legacy agent (pre-r11.3 release). If you do, then select the Configure Agent with Legacy Remote Agent Compatibility check
box. See the section, Configure the Agent to be Compatible with AE, in this document, for more information on how the AE
r11.3.5 installer configures the agent for legacy behavior.
After you have made your configuration selections, click Next.

Page 40
Click Upgrade to begin the upgrade process.
The Monitor Process panel displays until the upgrade completes, at which time the Upgrade Complete panel displays.

Page 41
Click Finish to exit the AE r11.3 to AE r11.3.5 upgrade.
The upgrade log is stored in /opt/CA/installer/log/CAWorkloadAutomationAE.update.log. You will see that the Oracle
database is upgraded in place using CreateAEDB.pl. The log shows the following:
<snip>
perl CreateAEDB.pl SYBASE **sa_user** **sa_pswd** **aedbadmin_pswd** **autosys_pswd**

/opt/CA/WorkloadAutomationAE/JRE_WA/1.6.0_33 /tmp/ora_upgradeaedb_pri N AEDB_DATA "" "0" "AEDB_INDEX" "" "0"
CreateAEDB: Base version 11.3.0 found. CreateAEDB will upgrade the CA Workload Automation AE database.
CreateAEDB: Upgrading the database tables where required.
CreateAEDB: CA Workload Automation AE database is updated.
<snip>

Page 42
Upgrade AE r11.3 to AE r11.3.5 (Sybase)

# ./wa_setup.sh
Click Next.

Page 43
Next.
If there are active AE processes, the Active Components panel displays. Click Next. Otherwise, the Instance Upgrade
Information panel displays.

Page 44
By default, all information that is necessary for the AE r11.3.5 installer to connect to Sybase for this AE instance is retrieved
from the previous AE r11.3 installation, except for the Sybase database administrator user and password. You should not
have to change any of this information. Also, notice the instance name is supplied. If you are upgrading multiple AE
instances, you will be prompted to supply this information for each AE instance.
Specify the Sybase database administrator user name and password. Click Next. If you supply the incorrect information, the
following error displays.

Page 45
Click Back and specify the correct Sybase connection information. When the database connection test succeeds, the
following panel displays if you do not have CA EEM security active on the r11.3 system.
If the AE r11.3 server does not have EEM security activated, you get this panel informing you of this fact. Click OK.
Otherwise, you get the CA EEM Properties panel.

Page 46
There is no option to skip upgrading EEM policies if AE r11.3 has EEM security enabled. If you need to skip the EEM security
policy upgrade, you must run autosys_secure and set security to NATIVE. Specify the CA EEM administrator (EiamAdmin)
user password and click Next.
Click Test to verify that the password is correct.
If the password is invalid, you get the CAUAJM_E_60246 error message. Click Back to retype the EiamAdmin user password.
If the password is valid, the CA EEM Server Connection Test panel shows with a Success message.

Page 47
Click OK.
If you are upgrading multiple AE instances, the next instance’s database connection information displays in the Upgrade
Instance Information panel. When you have supplied all AE instances’ information, the Configuration Files panel displays.

Page 48
On an upgrade, the default behavior is for the AE r11.3.5 installer to reuse the existing agent configuration files and
instance profile files. The reason why this option is needed during the upgrade is because the agent does not have the
ability to “upgrade”. In other words, when the AE r11.3.5 installer “upgrades” the agent, it uninstalls the agent, then installs
the new agent. In the process of uninstalling, the configuration files and profile files are removed.
If you choose not to use the default behavior, and deselect the Reuse Existing Configuration File check box, the Configure
Agent with Legacy Remote Agent Compatibility check box is enabled. You may want the agent to behave similarly to the
legacy agent (pre-r11.3 release). If you do, then select the Configure Agent with Legacy Remote Agent Compatibility check
box. See the section, Configure the Agent to be Compatible with AE, in this document, for more information on how the AE
r11.3.5 installer configures the agent for legacy behavior.
After you have made your configuration selections, click Next.
Click Upgrade to begin the upgrade process.

Page 49
The Monitor Process panel displays until the upgrade completes, at which time the Upgrade Complete panel displays.
Click Finish to exit the AE r11.3 to AE r11.3.5 upgrade.

Page 50
The upgrade log is stored in /opt/CA/installer/log/CAWorkloadAutomationAE.update.log. You will see that the Sybase
database is upgraded in place using CreateAEDB.pl. The log shows the following:
<snip>
perl ./CreateAEDB.pl SYBASE AEDB sa **sa_pswd** **autosys_pswd** /opt/CA/WorkloadAutomationAE/JRE_WA/1.6.0_33

/tmp/syb_upgradeaedb_pri N "" "" "0" "" "" "0"
CreateAEDB: Base version 11.3.0 found. CreateAEDB will upgrade the CA Workload Automation AE database.
CreateAEDB: Creating CA Workload Automation AE users.
CreateAEDB: Upgrading the database tables where required.
CreateAEDB: CA Workload Automation AE database is updated.
<snip>

Page 51
AE r11.3.5 Port Architecture

Page 52
Repair an AE r11.3.5 Installation

The AE r11.3.5 repair process is much more sophisticated than previous AutoSys or AE releases. As such, the repair requires
additional information from the user. The reasons are two-fold:
1. Not just anyone can perform a repair. Only a person with sufficient security clearance (because of password
knowledge) can run a repair.
2. The repair now rebuilds multiple AE instances, including databases, and repairs EEM security policies.
Note: The repair process requires that AE r11.3.5 was previously successfully installed. In other words, if AE r11.3.5 was
never fully installed, then the repair process may not work. Suppose the following:
a. AE r11.3 is installed.
b. An attempt is made to upgrade AE r11.3 to r11.3.5, but the upgrade fails.
Since the AE r11.3.5 upgrade failed, there is no guarantee that the AE r11.3.5 repair process will work. It depends on
when the upgrade failed. If the upgrade failed during the binary upgrade portion, then the repair will likely work. If
the upgrade failed during the database upgrade, then the repair may not work because the AE binaries access the
database, and the database may be in an unusable state.
The following example illustrates repairing an AE dual server installation that is using an Oracle database with EEM security
active. If you repair an AE installation that is using a Sybase database, the only difference from this example is the Instance
Repair Information panel. You are asked for Sybase database connection information instead of Oracle database connection
information.
# ./setup.sh
Click Next.

Page 53
Select Repair and click Next.
Click Next.

Page 54
The repair process requires the Oracle ‘aedbadmin’ user password, as well as the Oracle connection information. Specify
the required information and click Next.
To repair the EEM security policies, the repair process requires the EEM server ‘EiamAdmin’ user password. Specify the
password and click Next.

Page 55
Click Test.
Click OK.

Page 56
Specify the Oracle database connection information for the second server. Click Next.
If you want to reuse the existing agent configuration file (agentparms.txt), select the Reuse Existing Agent Configuration File
check box. If you want to reuse the AE instance profile files (WAAE.txt, ACE.txt, found in SystemAgent/WA_AGENT/profiles),
then select the Reuse Existing Instance Profile Files. If these files are not corrupted, you probably want to reuse them.
Otherwise, deselect the check boxes, which activates the Configure Agent with Legacy Remote Agent Compatibility check
box. Select this check box to configure the agent to behave similar to the legacy remote agent. (See the section, Configure
an Agent to be Compatible with AE, in this document for additional information on this check box.)

Page 57
After making your selections, click Next.
Review the settings and then click Next to begin the repair process.
When the repair finishes, the following panel displays.

Page 58
Click Finish. The output from the repair is stored in /opt/CA/installer/log in the file named
CAWorkloadAutomationAE.reinstall.log. Notice in the log that RefreshAEDB.pl is called to repair the Oracle databases. If
there are any database errors, they are logged in the /tmp/ora_repairaedb_pri and /tmp/ora_repairaedb_sec directories
respectively.
<snip>
perl RefreshAEDB.pl SYBASE **aedbadmin_pswd** /opt/CA/WorkloadAutomationAE/JRE_WA/1.6.0_33 /tmp/ora_repairaedb_pri

RefreshAEDB: Base version 11.3.5 found, RefreshAEDB to upgrade the CA Workload Automation AE database
RefreshAEDB: Upgrading the DB tables where required.
RefreshAEDB: Creating the DB stored procedures.
RefreshAEDB: Writing 2489 rows of read-only DB data.
CA Workload Automation AE database is refreshed.
perl RefreshAEDB.pl DWMS10 **aedbadmin_pswd** /opt/CA/WorkloadAutomationAE/JRE_WA/1.6.0_33 /tmp/ora_repairaedb_sec

RefreshAEDB: Base version 11.3.5 found, RefreshAEDB to upgrade the CA Workload Automation AE database
RefreshAEDB: Upgrading the DB tables where required.
RefreshAEDB: Creating the DB stored procedures.
RefreshAEDB: Writing 2489 rows of read-only DB data.
CA Workload Automation AE database is refreshed.
<snip>

Page 59
Use the DataMover Application for Data Migrations

Customers have used the AE DataMover application to migrate database data from AutoSys 4.5 and r11.0.
This command has performed its designed tasks well on databases containing valid AutoSys data. However, it has
encountered various problems when the database contains obsolete and out-of-date entries. Although problems were
identified by the syntax checker, more often the problems and resolutions were not obvious when reviewing the log files.
This section identifies problems encountered by customers and will need to be addressed for the planned AE r11.3.5
DataMover Application. (Also, see current documentation on migrating the database in CA Workload Automation AE UNIX
Implementation Guide , Chapter 22, p. 409-422.)
Note: Before performing any of the steps below, you should make sure you have a current backup of your database.
The problems have been separated into three categories:
Problems that stop the data migration process or generate errors
1. Incorrect version of the DataMover utility – Verify that you have the most current version of the DataMover
executable. (For example, an earlier version of the tool had a memory issue that was corrected.)
2. Active AutoSys or AE processes – Verify that the AutoSys or AE applications are stopped prior to running (scheduler,
application server, and agent) the DataMover utility. To verify that the AE applications are stopped, run the following
command from the command line:
unisrvcntr status
If any AutoSys or AE processes are running, stop them using the unisrvcntr stop command.
3. Entries created when using the "One-Time" override option.
4. Invalid numbers specified in JIL keywords, such as:
 Value set for the JIL keyword: "term_run_time". This value could be higher than the maximum value allowed,
"527040". (ERROR: CAUAJM_E_18995)
 Value set for the JIL Keyword: "box_terminator". Accepted values are "0, 1, f, false, n, no, t, true, y, yes",
encountered a number. (ERROR: CAUAJM_E_18902)
Problems that slow down the data migration process

1. All jobs associated with a BOX get the warning that the Box does not exist yet (CAUAJM_W_10282 ). This warning will
later generate the error "CAUAJM_E_50246 JIL syntax check FAILED". [Could there be a pre-parser that creates list of
BOX jobs and uses this during check?]
2. Identify jobs referencing invalid calendars and use JIL to remove them.
3. Identify orphaned data and provide option to clean-up (ex. overrides and alarms).
4. Run the following SQL commands:
delete from job_cond where joid not in (select joid from job);
delete from job_status where joid not in (select joid from job);
delete from job2 where joid not in (select joid from job);
Things missed during the DataMover execution or that needs to be addressed afterwards
1. The DataMover does not copy user@host or edit/exec users (see STAR issue 21191984-02).
2. All machine definitions are migrated as legacy. This encourages/assumes that every migration will utilize legacy
machine definitions. We DON’T want the customer to do that. We DO want customers to use the 11.3.5 agents - so the
DataMover should include the option to move all machine definitions as legacy, current, or only export the converted
machine jil.

Page 60
3. Technical Support has found that the majority of customer migrations have required the customer to delete many
machines and then insert them with appropriate definitions. Also, there have been issues caused by having to forcibly
delete machines while orphaning the virtual machine names. This scenario has required the reinsertion of all machines
and then the separation of virtual machines, then the removal of virtual machines.
Current limitations to the DataMover
The following are current known limitations to the DataMover which will be addressed in the future:
1. Scan the database for invalid data, such as is identified in #3 and #4 above. This includes adding the newer integrity
checking, which identifies duplicate data rows. The DataMover should have a command line option to remove
duplicate data rows.
2. The DataMover does not have the ability to modify the agent paramfile.txt file so that “VERIFY=no”. Add the ability to
the DataMover to modify the agent paramfile.txt file so that “VERIFY=no”. This would be applicable for r11.0
migrations.
3. When a fatal occurs, the DataMover should write a more descriptive interpretation of the problem to the log, and
perhaps the screen. For example:
Reading table job failed on input column 4 and output column 5
Reading table job failed on row 900 -- java.sql.SQLException: Numeric Overflow
Copy Task 0 copying job has faulted (3)
4. DataMover does not have the ability to scan for corrupt job names. Add the ability to the DataMover to scan for
corrupt JOB names.
5. As part of the recommended automation, the script should perform a sanity test and verify that the required
DataMover parameter file is in place and has the following entries (note the data is for an Oracle database):
SRCDBTYPE=oracle
SRCDBMACHINE=rex
SRCDBNAME=auto451p
SRCDBPORT=1865
SRCDBUSER=autosys
SRCDBPWD=xxxxxxxxxxxx
TGTDBTYPE=oracle
TGTDBMACHINE=tex
TGTDBNAME=autop
TGTDBPORT=1609
TGTDBUSER=aedbadmin
TGTDBPWD=xxxxxxxxxxxx
NATIVEJDBCJARPATH=/usr/orasys/11.2.0.3r2/jdbc/lib/ojdbc6.jar # Oracle 1.6 compatible JDBC.
JREPATH=/usr/java6_64/jre # Mixed or 64-bit may give better performance.
VERIFY=yes # Note: You'll change this at "Go time".
MAXMEMORYLIMIT=4096 # Note: Make sure the system has the RAM.

Page 61
Unattended AE Install Failure Return Code Meanings

Unattended installation failures usually occur because something is wrong with the system environment or there are invalid
values in the user-created response file. The following tables describe the return code errors from unattended installs.
Return codes from wa_setup.sh
Return Code Description
1 The Oracle or Sybase database connection test failed.
2 The Sybase ‘autosys’ user check failed.
3 The Sybase ‘autosys’ user definition failed.
4 The Oracle or Sybase ‘autosys’ user password test failed.
5 There are not enough Sybase user connections.
6 The Sybase page size is too small.

7 The version of Sybase installed is not supported by AE.
8 The Sybase device is already created.
9 There is not enough free space to create the Sybase database.
10 There is not enough free space in the system temporary directory (e.g. /tmp).
11 The Oracle ‘aedbadmin’ user check failed.
12 Duplicate agent name. There is already an agent installed by the name in the response file.
13 Duplicate agent port. There is already an agent installed that is using the port specified in the response file.
15 $CASHCOMP is not specified correctly in the response file.
16 $ASI_AUTOSYS_INSTDIR is not specified correctly in the response file.
17 The AE web server must be installed on a 64-bit operating system.
18 There is already an AE instance on the server. An unattended install does not support “upgrade” or “modify”.
21 Dependent processes could not be shut down.
22 The installation directory specified in $ASI_AUTOSYS_INSTDIR or $CASHCOMP is not writable.
Return codes from agent_setup.sh
7 Duplicate agent name. There is already an agent installed by the name in the response file.
8 Duplicate agent port. There is already an agent installed that is using the port specified in the response file.
9 There is not enough free space in the system temporary directory (e.g. /tmp).
17 The machine is HP-ia64. The $Config_Agt_Port_2_SSA variable must be set to 0 in the response file.
19 The –I option was not used when installing another agent instance.

Page 62
Return codes from client_setup.sh
Return codes from sdk_setup.sh

Page 63
Create Oracle Tablespaces, Users, and Roles

The AE r11.3.5 installer handles the Oracle database tablespace, user, and role creation differently than in AE r11.3. In
r11.3, the installer could not meet several customers’ requirements of being able to install AE and load the tablespaces
without having to specify the database system administrator user and password.
To meet the customer need, the AE r11.3.5 installer was redesigned to allow the ability to skip all database operations
requiring database system administer user privileges. In AE, there are three operations that require system-level user
privileges:
1. Create tablespace
2. Create user
3. Create role
Early on in the r11.3.5 planning process, a decision was made by the R&D team to group these three database operations
together to reduce complexities. In other words, the installer would not give control to the user to execute/not execute
these three database operations individually.
An SQL script (waae_oracle.sql) was created, providing a simple utility (another requirement) so that the database
administrator could perform all three database operations (not the installer); one major result being that the system-level
database users/passwords required to perform the operations would remain secure.
The waae_oracle.sql script is shown below and fully described in the CA Workload Automation AE UNIX Implementation
Guide , p. 59.
Rem Parameters to this SQL are:

Rem
Rem 1 - Data tablespace name. For example: AEDB_DATA
Rem 2 - Data tablespace size in MB. For example: 800
Rem 3 - Data tablespace directory file. For example: /home/oracle/oradata/orcl/AEDB_DATA.DBF
Rem 4 - Index tablespace name. For example: AEDB_INDEX
Rem 5 - Index tablespace size in MB. For example: 80
Rem 6 - Index tablespace directory file. For example: /home/oracle/oradata/orcl/AEDB_INDEX.DBF
Rem 7 - 'aedbadmin' database user password.
Rem 8 - 'autosys' database user password.
Rem
Rem Create the Oracle tablespaces:
Rem Uncomment if using OMF:
Rem CREATE TABLESPACE &1 LOGGING;
Rem Uncomment if using ASM:
Rem CREATE TABLESPACE &1 DATAFILE '&3' SIZE &2.M AUTOEXTEND
Rem If not using Oracle-managed space:
Rem Create the data tablespace:
CREATE TABLESPACE &1 DATAFILE '&3' SIZE &2.M REUSE AUTOEXTEND ON NEXT 300K MAXSIZE UNLIMITED LOGGING EXTENT
MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;
Rem Create the index tablespace:
CREATE TABLESPACE &4 DATAFILE '&6' SIZE &5.M REUSE AUTOEXTEND ON NEXT 300K MAXSIZE UNLIMITED LOGGING EXTENT
MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;
Rem Create 'aedbadmin' user:
CREATE USER aedbadmin PROFILE DEFAULT IDENTIFIED BY "&7" DEFAULT TABLESPACE &1 ACCOUNT UNLOCK;
SET VERIFY ON;
GRANT CREATE VIEW TO aedbadmin;
GRANT 'CONNECT' TO aedbadmin;
Rem GRANT 'EXECUTE_CATALOG_ROLE' TO aedbadmin;
GRANT 'RESOURCE' TO aedbadmin;
GRANT 'SELECT_CATALOG_ROLE' TO aedbadmin;
GRANT CREATE PUBLIC SYNONYM to aedbadmin;

Page 64
Rem Create 'autosys' user:

CREATE USER autosys PROFILE DEFAULT IDENTIFIED BY "&8" DEFAULT TABLESPACE &1 ACCOUNT UNLOCK;
Rem Create 'ujoadmin' role:
CREATE ROLE ujoadmin NOT IDENTIFIED;
GRANT ANALYZE ANY TO ujoadmin;
GRANT SELECT ON DBA_TABLESPACES TO ujoadmin;
GRANT ujoadmin TO aedbadmin;
GRANT 'CONNECT' TO autosys;
GRANT ujoadmin TO autosys;
Rem Alter 'aedbadmin' user:
ALTER USER aedbadmin QUOTA UNLIMITED ON &1;
Rem Comment if using OMF:
ALTER USER aedbadmin QUOTA UNLIMITED ON &4;
Run waae_oracle.sql from the Oracle command prompt. For example:

> sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 - Production on Tue Feb 15 14:39:35 2011
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> connect SYS/******** as SYSDBA
Connected.
SQL> @/tmp/waae/waae_oracle.sql AEDB_DATA 800 /home/oracle/oracle/product/10.2.0/oradata/orcl/AEDB_DATA.DBF
AEDB_INDEX 80 /home/oracle/oracle/product/10.2.0/oradata/orcl/AEDB_INDEX.DBF AedbAdm1 AutoSys1
The Create Tablespaces, Database Users, and Roles check box, located on the Primary Event Server Properties panel,
controls whether the AE r11.3.5 installer prompts for the Oracle system administrator user password. For example:
If the Create Tablespaces, Database Users, and Roles check box is not selected, as is shown above, the Installer does not ask
for the Oracle system administrator user and password. The AE r11.3.5 installer assumes that you have previously created
the tablespaces, users, and roles using waae_oracle.sql.

Page 65
Configure an Agent to be Compatible with AE

There is no need to configure the agent to be compatible with AE if the AE r11.3.5 installer is used to install the agent. In
fact, the AE r11.3.5 installer performs the six actions that are listed below to make the agent fully functional with AE. If the
agent is installed using the ESP r11.3 agent installer, however, then you must manually perform six actions. (See also CA
Workload Automation AE UNIX Implementation Guide , p. 125-128.)
Note: In the specifications below, information in < > indicates variable information. The definitions for variable
information are described in Table 1.
Variable Description Example
<agent> The agent name WA_AGENT
<host> The host name of the machine prod_host_1
<port> The port number 162
<system_agent_install> The agent installation directory /opt/CA/WorkloadAutomationAE/SystemAgent
<AE_install_directory> The directory where WAAE is installed /opt/CA/WorkloadAutomationAE
<Shared_components_dir> The directory identified by $CASHCOMP /opt/CA/SharedComponents

<LIBPATH_VAR_NAME> The shared library variable name For Linux: LD_LIBRARY_PATH
For SunOS: LD_LIBRARY_PATH
For AIX: LIBPATH
For HP-UX: SHLIB_PATH
Table 1: Variable Names and Descriptions
Actions performed by the AE r11.3.5 installer
1. Creates <system_agent_install>/<agent>/profiles/WAAE.txt. The WAAE.txt file consists of the following:

 AUTOSYS=<AE_install_directory>/autosys
 AUTOROOT=<AE_install_directory>
 CA_FIPS1402_ENABLE=1 # Set to 1 only if agent is specified as FIPS-enabled.
2. Creates <system_agent_install>/<agent>/profiles/<ACE>.txt if the agent is installed with a client, application server, or

scheduler. The <ACE>.txt file consists of the following:
 EWAGLOBALPROFILE=/etc/auto.profile
3. Creates the agent data encryption key and stores it in <system_agent_install>/<agent>/cryptkey.txt. This value is
created using as_config.
4. Configures the <system_agent_install>/<agent>/agentparm.txt file with the following default values (See Appendix A
for details on when each parameter is included):
 agent.spool.success.autocleanup=true
 runnerplugin.spool.clean.enable=true
 runnerplugin.spool.expire=7d
 agent.resourcemon.enable=true
 filemon.firstscan.skip=true
 oscomponent.joblog.success.autocleanup=true
 oscomponent.noexitcode=256
 oscomponent.auth.pam.svc=sshd
 oscomponent.cmdprefix.force=true
 oscomponent.cmdprefix.force.quotes.full=true
 oscomponent.noforceprofile=true

Page 66
 oscomponent.cmdprefix.force=true
 oscomponent.initialworkingdirectory=USER
 oscomponent.profiles.src.verify=true
 oscomponent.profiles.src.delay=true
 oscomponent.profiles.src.order.global.first=true
 security.cryptkey=cryptkey.txt
If SNMP is enabled, the following parameters are added to the <system_agent_install>/<agent>/agentparm.txt file:
 management.snmp.host=<host>
 snmp.trap.listener.port=<port>
 management.snmp.agent.trapsink.host=<host>
 management.snmp.agent.port=<port>
If the agent is installed with an AE client, application server, or scheduler, the following parameters are added to the
<system_agent_install>/<agent>/agentparm.txt file:
 oscomponent.environment.variable_manager_<ACE>_SCH=<AE_install_directory>/SystemAgent/<agent>/profiles/<AC
E>
If an AE instance is added later, the WAAE installer creates another parameter in the
<system_agent_install>/<agent>/agentparm.txt file:
 oscomponent.environment.variable_manager_<AC2>_SCH=<AE_install_directory>/SystemAgent/<agent>/profiles/<AC
2>
5. Because of the parameters that the AE r11.3.5 installer passes to the ESP Agent installer silently, the following
information is stored in <system_agent_install>/<agent>/cybspawn:
 EWA_SHARED=<Shared_components_dir>
 export EWA_SHARED
 CSAM_SOCKADAPTER=$EWA_SHARED/Csam/SockAdapter
 export CSAM_SOCKADAPTER
 <LIBPATH_VAR_NAME>="<system_agent_install>/<agent>:$CSAM_SOCKADAPTER/lib:<AE_install_directory>/autosys/lib:
$<LIBPATH_VAR_NAME>"
 export <LIBPATH_VAR_NAME>
6. Because of the parameters that the AE r11.3.5 installer passes to the ESP Agent installer silently, the following
information is stored in <system_agent_install>/<agent>/ESPmgr:
 EWA_SHARED=< Shared_components_dir>
 export EWA_SHARED
 CSAM_SOCKADAPTER=$EWA_SHARED/Csam/SockAdapter
 export CSAM_SOCKADAPTER
 <LIBPATH_VAR_NAME>="<system_agent_install>/<agent>:$CSAM_SOCKADAPTER/lib:<AE_install_directory>/autosys/lib:
$<LIBPATH_VAR_NAME>"
 export <LIBPATH_VAR_NAME>
What values the AE r11.3.5 installer uses to configure the agent

The AE r11.3.5 installer configures the agent to function in a specific manner by setting the following agent attributes in the
agentparm.txt file.
agent.resourcemon.enable=true
Configures the agent to monitor disk space usage and report errors when thresholds are reached.
agent.spool.success.autocleanup=true
Configures the agent to delete a job’s spool file automatically when the job completes successfully.
oscomponent.auth.pam.svc=sshd

Page 67
Configures the agent to use PAM (Pluggable Authentication Modules) for service security checks. (UNIX only.)
oscomponent.joblog.success.autocleanup=true
Configures the agent to delete a job’s job log automatically when the job completes successfully.
runnerplugin.spool.clean.enable=true
Configures the agent to review the spool files for removal.
runnerplugin.spool.expire=7d
Configures the agent to delete spool files that are older than 7 days.
security.cryptkey=cryptkey.txt
Configures the agent to use cryptkey.txt as the encryption file.
In addition to automatically setting the aforementioned agent attributes, the AE r11.3.5 installer also allows you to tell it to
configure the agent to run in compatibility mode. When the agent runs in compatibility mode, its job processing behavior
closely mirrors that of the product’s legacy agent (remote agent).
To cause the AE r11.3.5 installer to configure the agent to run in compatibility mode, select the Configure Agent with
Legacy Remote Agent Compatibility check box on the Agent Attributes panel (for UNIX) or Agent Properties panel (for
Windows). If you select this check box, the AE installer sets the following agent attributes in agentparm.txt.
filemon.firstscan.skip=true
Configures the agent to skip the first scan of a monitored file.
oscomponent.cmdprefix.force=true
On UNIX, this parameter configures the agent to execute a temporary shell script (containing the profiles to be
sourced) without sourcing the user’s profile. On Windows, this parameter prefixes the job’s command string with a
value of “cmd /c ” to allow commands such as “dir” and “echo” to execute properly.
oscomponent.cmdprefix.force.quotes.full=true
This parameter causes file watchers to work “out of the box”. (Windows only.)
oscomponent.initialworkingdirectory=USER
Configures the agent to set the working directory of all scripts to be the script’s owner’s home directory.
oscomponent.noexitcode=256
Configures the agent to not send a completion code to the scheduling manager host if a job’s exit code is 256. This
value is chosen because the agent’s default settings are 255 for UNIX and 127 for Windows. This allows the agent to
properly return status for exit codes 0 through 255 on all platforms.
oscomponent.noforceprofile=true
Specifies whether the agent allows loading a .profile/.login file based on the usual UNIX rules for sourcing
.profile/.login. When set to true the agent does not load the .profile/.login file. (UNIX only.)
oscomponent.profiles.src.delay=true
Configures the agent to execute the sourcing of profiles (global and job) from a temporary shell script. The agent will
not add /etc/profile or the user’s login profile to this temporary shell script. To further control which profile (global or
job) gets sourced as part of execution, refer to the oscomponent.profiles.global.override parameter. (UNIX only).
oscomponent.profiles.src.order.global.first=true
Configures the agent to first source the profile pointed at by EWAGLOBALPROFILE (/etc/auto.profile) prior to execution.
oscomponent.profiles.src.verify=true
Configures the agent to verify existence of the job profile prior to execution. If the profile does not exist, job execution
is terminated and an error is returned. (UNIX only.)

Page 68
Clean Up After a Catastrophic Install or Uninstall Failure

There have been instances where the product install or uninstall has failed, leaving the server in a state where it must be
cleaned up before the user can successfully install it again. For example, this type of failure could occur if the available disk
space is borderline, and other active processes use and release temporary storage. If one of these processes reserve disk
space that was available at the beginning of the install, and the disk space fills, then the install will fail. Cleaning up the
server is necessary after a catastrophic failure of the CA Workload Automation AE install or uninstall.
To clean up after a catastrophic uninstallation failure
Note: Enter all commands at the operating system prompt, except Step 16.
1. Enter the following command:
unisrvcntr stop CA-WAAE
All CA Workload Automation AE processes stop. To verify that all AE processes are stopped, enter the following
command:
unisrvcntr status
If any AE processes are running, kill them using the kill -9 command.
2. Enter the following command for each process_name, and note the processes that are running:
ps -ef | grep process_name
process_name
Specifies the name of the process to check. Process names to use with the command are as follows:
 as_server
 event_demon
 cybAgent
 csampmuxf
 lic98fds
An active process will display its process ID. Use the process ID in Step 3.
3. Enter the following command using each process_ID listed in Step 2:
kill -9 process_ID
The process is stopped.

lsm -e CAWorkloadAutomationAE
Note: The lsm utility can be removed during a failed un-installation. Perform this step and Steps 5-8 as needed if
lsm is available. Perform Steps 9-15 to ensure that the necessary files are removed from the server even if
you can run lsm successfully.
CA Workload Automation AE is removed.
5. (Optional) If the standalone client is installed, enter the following command:
lsm -e CAWorkloadAutomationAE-Client
The standalone client is removed.

6. (Optional) If the standalone agent is installed, enter the following command:
lsm -e CAWorkloadAutomationAE-Agent
The standalone agent is removed.

Page 69
7. (Optional) If multiple instances of the standalone agent are installed, enter the following command as needed for
each agent instance:
lsm -e CAWorkloadAutomationAE-Agent.agent_name
agent_name
Specifies the name of the agent.
The standalone agent is removed.
8. (Optional) If the standalone SDK is installed, enter the following command:
lsm -e CAWorkloadAutomationAE-SDK
The standalone SDK is removed.

9. (Linux only) Enter the following command:
rpm -qa | grep ^ca-
Depending on which AE components are installed, the rpm packages listed in Step 10 are displayed.
10. (Linux only) Enter the following commands for the installed rpm packages only:
rpm -e --noscripts ca-waae-server
rpm -e --noscripts ca-waae-scheduler
rpm -e --noscripts ca-waae-db
rpm -e --noscripts ca-waae-asapi
rpm -e --noscripts ca-waae-client
rpm -e --noscripts ca-waae-common-sac
rpm -e --noscripts ca-waae-agent
rpm -e --noscripts ca-waae-sdk
rpm -e --noscripts ca-waae-common-cs2
rpm -e --noscripts ca-waae-common-cs
rpm -e --noscripts ca-waae-common
rpm -e --noscripts ca-lic
rpm -e --noscripts ca-waae-webserver
rpm -e --noscripts ca-waae-safex
rpm -e --noscripts ca-waae-jre-64
rpm -e --noscripts ca-waae-jre-32
rpm -e --noscripts ca-waae-cmd-sponsor
rpm -e --noscripts ca-waae-sockadapter
rpm -e --noscripts ca-cs-utils
The rpm packages are removed.

rm –rf install_directory
install_directory
Specifies the root directory where CA Workload Automation AE is installed. By default,
/opt/CA/WorkloadAutomationAE is the installation directory.
The installation directory is removed.
12. Enter the following commands:
rm –f /etc/auto.profile
rm –f /etc/auto.instance_name
instance_name
Specifies the CA Workload Automation AE instance name.
The profile files are removed.

Page 70
13. Enter the following commands:

 On AIX:
rm -f /etc/rc.d/waae_*
rm -f /etc/rc.d/CA-WAAE
rm -f /etc/rc.d/init.d/waae_*
rm -f /etc/rc.d/init.d/CA-WAAE
 On HP-UX:
rm -f /sbin/init.d/waae_*
rm -f /sbin/init.d/CA-WAAE
 On Solaris and Linux:

rm -f /etc/init.d/waae_*
rm -f /etc/init.d/CA-WAAE
The waae_* and CA-WAAE system startup files are removed.

Note: The server cleanup is complete if you do not need to perform the optional steps that follow.
14. (Optional) Enter the following commands only if other CA Technologies products are not installed on the server:
rm -f /etc/profile.CA
rm -f /etc/csh_login.CA
The profile files are removed.

15. (Optional) Enter the following commands only if other CA Technologies products are not installed on the server:
 On AIX:
rm -f /etc/rc.d/CA-CCS
rm -f /etc/rc.d/init.d/CA-CCS
 On HP-UX:
rm -f /sbin/init.d/CA-CCS
 On Solaris and Linux:

rm -f /etc/init.d/CA-CCS
The CA-CCS system startup files are removed and the server cleanup is complete.

Page 71
16. (Optional) If your installation created a database, then depending on the database type, do the following:
To remove the AE Oracle database objects
If the uninstaller progressed to the point where it created its database uninstaller, you can simply run the database
uninstaller script. The uninstaller script is located in /tmp (or the system temporary directory) and is called
rm_waae_<p><ACE>.sh, where <p> indicates the uninstaller script is generated for the primary database, and <s>
indicates the uninstaller script is generated for the second database, in the case of a dual server install. The <ACE> is
the AE instance identifier.
To run the database uninstaller script, do the following (this example illustrates a single server install with the name
of the AE instance being PRD).
# cd /tmp
# ./ rm_waae_pPRD.sh
Enter the Oracle home directory [Default: /home/oracle/app/oracle/product/11.2.0/dbhome_1]:
Enter the directory location of the tnsnames.ora file [Default:
/home/oracle/app/oracle/product/11.2.0/dbhome_1/network/admin]:
Enter the Oracle SID [Default: SYBASE]:
Enter the Oracle User ID with sufficient privileges [Default: SYS]:
Enter the Oracle User ID password:
Enter the Oracle data tablespace name [Default: AEDB_DATA]:
Enter the Oracle index tablespace name [Default: AEDB_INDEX]:
The following information will be used when removing the WA Oracle database:
ORACLE_HOME: /home/oracle/app/oracle/product/11.2.0/dbhome_1
tnsnames.ora Path: /home/oracle/app/oracle/product/11.2.0/dbhome_1/network/admin
Oracle SID: SYBASE
Oracle User: SYS
Oracle Data Tablespace Name: AEDB_DATA
Oracle Index Tablespace Name: AEDB_INDEX
Do you wish to change any information before continuing (Y/N) [Default:N]:
Removing the Oracle tablespaces, which can take a few minutes to complete.
Role dropped.
User dropped.
Tablespace dropped.
Tablespace dropped.
If the database uninstaller is not generated, you will need to run the following SQL statements. Enter the following
commands at the SQL prompt:
At the Oracle prompt, after logging in as user SYS or system administrator:
drop role ujoadmin;
drop user aedbadmin cascade;
drop user autosys cascade;
drop tablespace data_tablespace_name including contents and datafiles cascade constraints;
drop tablespace index_tablespace_name including contents and datafiles cascade constraints;
data_tablespace_name
Specifies the CA Workload Automation AE data tablespace name defined in the Oracle database.
index_tablespace_name
Specifies the CA Workload Automation AE index tablespace name defined in the Oracle database.
The CA Workload Automation AE database objects are removed from the Oracle database and the database cleanup
is complete.

Page 72
To remove the AE Sybase database

If the uninstaller progressed to the point where it created its database uninstaller, you can simply run the database
uninstaller script. The uninstaller script is located in /tmp (or the system temporary directory) and is called
rm_waae_<p><ACE>.sh, where <p> indicates the uninstaller script is generated for the primary database, and <s>
indicates the uninstaller script is generated for the second database, in the case of a dual server install. The <ACE> is
the instance identifier.
To run the database uninstaller script, do the following (this example illustrates a single server install with the name
of the AE instance being PRD).
# cd /tmp
# ./rm_waae_pPRD.sh
Enter the Sybase Server name [Default: LCIBM003]:
Enter the Sybase system administrator user ID [Default: sa]:
Enter the Sybase system administrator password:
Enter the Sybase database name [Default: AEDB]:
Enter the Sybase data device Name [Default: AEDB_DATA]:
Enter the directory that contains the Sybase data device [Default: /opt/sybase/data]:
Enter the Sybase log device name [Default: AEDB_LOG]:
Enter the directory that contains the Sybase log device [Default: /opt/sybase/data]:
Enter the $SYBASE directory [Default: /opt/sybase]:
The following information will be used when removing the Sybase database:
$SYBASE Directory: /opt/sybase
Sybase Database Name: AEDB
Sybase Servername: LCIBM003
Sybase Data Device: AEDB_DATA
Sybase Data Directory: /opt/sybase/data
Sybase Log Device: AEDB_LOG
Sybase Log Directory: /opt/sybase/data
Sybase User: sa
Do you wish to change any information before continuing (Y/N) [Default:N]:
Removing the Sybase database...
Account locked.
Login dropped.
(return status = 0)
Device dropped.
(return status = 0)
If there were no errors in dropping the Sybase AEDB database,
autosys user, AEDB_DATA device, and ujoadmin role, remove
/opt/sybase/data/AEDB_DATA.DAT by issuing the following command:
rm -f /opt/sybase/data/AEDB_DATA.DAT
Device dropped.
(return status = 0)
Remove /opt/sybase/data/AEDB_LOG.DAT by issuing the following command:
rm -f /opt/sybase/data/AEDB_LOG.DAT
After the database uninstaller script has completed, make sure that the database, users, and devices have been
dropped by reviewing the output. Then you should remove the Sybase data and log device files, as is described in the
output above. (Also, see the To remove the Sybase data and log device files section.)

Page 73
If the database uninstaller is not generated, you will need to run the following SQL statements. Enter the following
commands at the SQL prompt, after logging in as user sa or system administrator:
use master
go
drop database database_name
go
exec sp_droplogin autosys
go
drop role ujoadmin with override
go
exec sp_dropdevice 'data_device'
go
exec sp_dropdevice 'log_device'
go
database_name
Specifies the CA Workload Automation AE database defined in the Sybase database.
data_device
Specifies the CA Workload Automation AE data device name defined in Sybase database.
log_device
Specifies the CA Workload Automation AE log device name defined in Sybase database.
After you have run the SQL above, you should remove the Sybase data and log device files. To remove the devices
files, follow the directions in the To remove the Sybase data and log device files section.
To remove the Sybase data and log device files
From the system command line, run the following commands:
rm -f Sybase_datadir/data_device.DAT
rm -f Sybase_logdir/log_device.DAT
Sybase_datadir
Specifies the fully-qualified directory path where the CA Workload Automation AE data device resides.
data_device
Specifies the CA Workload Automation AE data device name defined in Sybase database.
Sybase_logdir
Specifies the fully-qualified directory path where the CA Workload Automation AE log device resides.
log_device
Specifies the CA Workload Automation AE log device name defined in Sybase database.
The CA Workload Automation AE database objects are removed from the Sybase database and the database cleanup
is complete.

Page 74
Perform ‘sendevent’ in Batch

Performing sendevents in batch mode can save time and effort, especially if you have many jobs in “hold” as a result
of using “GlobalAutoHold”. To send multiple events in one batch run, use the following steps.
1. Create a file that consists of events you wish to submit. For example, create a file by the name of batch.snd in the
/tmp directory:
# vi /tmp/batch.snd
Type the following:
sendevent -E JOB_OFF_HOLD -J test

sendevent -E JOB_OFF_HOLD -J test1
sendevent -E JOB_OFF_HOLD -J test2
sendevent -E FORCE_STARTJOB -J test3
sendevent -E MACH_ONLINE -n linux6tst.ca.com
Save the file.

2. Create a shell script that uses the file as input to run sendevent with the –F option. For example, edit a file by the name
of multi_sendevents.sh in the /tmp directory:
# vi /tmp/multi_sendevent.sh
Type the following:
#!/bin/sh
if [ -z “$1” ]; then
echo “Specify the name of the file that contains the sendevent commands.”
exit 1
fi
if [ ! –f “$1” ]; then
echo “The file cannot be found. Please double check the name and path of the file.”
exit 1
fi
iFile=$1
cat $iFile | grep “^sendevent” | while read command
do
echo “$command” > /tmp/cmd.file$$
sendevent –F /tmp/cmd.file$$
done
rm –f /tmp/cmd.file$$
3. Save the shell script and change permissions to execute. For example:
# chmod +x /tmp/multi_sendevents.sh
4. Run the shell script (e.g. multi_sendevents.sh), after having sourced the CA Workload Automation AE environment. For
example, suppose AE is installed on machine RH3242PRD in /opt/CA/WorkloadAutomationAE, and the instance name is
PRD. Run the following:
# . /opt/CA/WorkloadAutomationAE/autouser.PRD/autosys.sh.RH3242PRD
# cd /tmp
# ./multi_sendevents.sh /tmp/batch.snd
Note: When using sendevent in batch mode, you are not limited to a particular kind of event. So, there may be other
useful applications beyond what are shown in the example.

Page 75
Debug Options, Environment Variables, and Tracing

This section focuses on tools that may be of use when diagnosing an AE installation problem. For example, environment
variables can alter the AE installation behavior. Command line options can be specified to increase debugging information.
And, understanding the AE navigation methodology will help in resolving possible navigation problems.
AE Installation Environment Variables

There are a significant number of environment variables which can be used to alter the behavior of the AE installation
process. Most of the environment variables are documented in the CA Workload Automation AE UNIX Implementation
Guide, Release 11.3.5, pp. 48-53. The following environment variables are documented:
 WA_DEBUG
 WA_DB_DEBUG
 AS_INSTALL_DEBUG
 AS_SYB_LOCALE
 AS_SKIP_SPACE_CHECK
 AS_MIG_VERIFY
There are a number of other environment variables not documented in the GA guides, however. These variables should be
used with care by CA Technologies Technical Support to assist in answering questions or resolving problems. Each of these
variables are described below:
AS_DENY_SU=[0|1]
By default, the AE installation uses “su” to activate EEM security. Some customers forbid the use of su. Therefore,
setting AS_DENY_SU to 1 will cause the AE installer to not activate EEM security.
AS_EEM_TEST_DEBUG=[0|1]
If the user is having difficulty getting the EEM server connection test to work, you can set AS_EEM_TEST_DEBUG to 1.
This will cause the AE interviewer to create a file in the system temporary directory called eem.debug. This file contains
the information that the AE interviewer uses to connect to the EEM server, which includes:
AUTOSYS=$AUTOSYS
AUTOUSER=$AUTOUSER
LIBRARY=$SAFE_LIB
ASSAFETOOLFIPS=$ASSAFETOOLFIPS
Also, all messages from as_safetool are logged to eem.debug. This variable should be unset as soon as you determine
that the AE interviewer is using the correct information because the file contains the EEM ‘EiamAdmin’ user password.
AS_SKIP_APPLSVR_DB_CHECK=[0|1]
You can have the AE interviewer skip the application server database check (if installing only an application server) by
setting AS_SKIP_APPLSVR_DB_CHECK to 1.
AS_SKIP_DEVTEST=[0|1]
If the user is having difficulty getting the Oracle disk device test to work, you can set AS_SKIP_DEVTEST to 1. When this
variable is set to 1, both the data and index disk device tests will be skipped.

Page 76
AS_SKIP_EEM_TEST=[0|1]
If you need to skip the EEM server connection test, set AS_SKIP_EEM_TEST to 1.
AS_SKIP_OS_CHECK=[0|1]
The AE interviewer checks to see if the OS is 32 or 64-bit. The AE web server requires a 64-bit operating system. If, for
some reason, this check needs to be disabled, set AS_SKIP_OS_CHECK to 1.
AS_GLIBC_SKIP=[0|1]
To tell the AE interviewer to skip the glibc version check, set AS_GLIBC_SKIP to 1.
AS_GLIBC_VERSION=[version]
The AE product requires a version equal to or greater than 2.3.2-95.3 of glibc. If the requirement changes in the future,
you can set the “new” minimum version of glibc by using the AS_GLIBC_VERSION. Set it to the new requirement. For
example, if the glibc version changed to 2.3.3-107.1, then you would run the following commands:
# AS_GLIBC_VERSION=2.3.3-107.1
# export AS_GLIBC_VERSION
AE Installation Tracing
If a product created by the PIF Packager encounters a problem, it attempts to back out all directories and files it created or
installed, including log files. AE is created by the PIF Packager, and therefore, has this challenge. To force the PIF Packager
to not back out installed components and not remove log files, set the following environment variable:
LSM_ABORT_IMMEDIATE=1; export LSM_ABORT_IMMEDIATE
All other environment variables dealing with AE installation tracing are documented on page 49 of the CA Workload Automation
AE UNIX Implementation Guide, Release 11.3.5. To gather information and log files for problem diagnosis, use CACDF. See Using
CACDF in this document for additional information.
Specify the –t option to enable tracing when running wa_setup.sh, client_setup.sh, sdk_setup.sh, or agent_setup.sh. For example:
./wa_setup.sh –t /tmp/install.trc
The wa_setup.sh script options are documented in CA Workload Automation AE UNIX Implementation Guide, Release
11.3.5, p. 49.
The AE install has a complex interview logic flow due to the many available installation options. If a problem occurs during
the interview process, it is important to know the interview logic path the user took to cause the problem. The interview
produces the logic path automatically. A file is created in the system’s temporary directory called as_install<pid>.trc, where
<pid> is the process ID of the installation. Possible locations for the temporary directory are:
 $TMPDIR
 /tmp
 /var/tmp
 /opt/CA/SharedComponents/tmp.

Page 77
The following example shows the contents of as_install<pid>.trc. This trace file lists each dialog that the user passed
through. As is seen below, the user passed through the Welcome, License, Installation Function, Installation Definition,
Installation Type, and New Components panels.
# cd /tmp
# more as_install19542.trc
V_dlgWelcome
D_dlgWelcome
V_dlgLicense
D_dlgLicense
V_dlgInstallFunc
D_dlgInstallFunc
V_dlgInstallDef
D_dlgInstallDef
V_dlgInstallType
D_dlgInstallType
V_dlgNewComponents
D_dlgNewComponents
Each panel has two scripts associated with it: V_<dialog_name> (for verification) and D_<dialog_name> (for navigation).
The V_ and D_ names correspond to the dialog names in the CAWorkloadAutomationAE.@prm file. The dialog names are
located in the #dhead control immediately following the PIF @DIALOG: indicator. For example, the snippet from the
CAWorkloadAutomationAE.@prm file (shown on the next page) shows the Welcome and License dialog definitions.
@DIALOG:
#dhead: 650 , 500 , dlgWelcome , 211 , scripts/as_verification.sh ;
#graphic: grpGraphic , graphics/waae_w_west.gif , graphics/waae_w_header.gif , graphics/waae_w_center.gif ,
graphics/waae_footer.gif , ;
#textarea: 1 , 1 , txtWelcome1 , 702 ;
#textarea: 3 , 1 , areaEmpty1 , 900 ;
#textarea: 8 , 1 , txtReleaseN , 1341 ;
#textarea: 10 , 1 , txtCopyright , 704 ;
#navbutton: 1 , btnNext , 500 , 5 , , scripts/as_navigation.sh ;
#navbutton: 2 , btnCancel , 502 , 0 , ;
@ENDDIALOG:
<snip>
@DIALOG:
#dhead: 650 , 500 , dlgLicense , 202 , scripts/as_verification.sh , btnDecline ;
#graphic: grpGraphic , graphics/waae_w_west.gif , graphics/waae_w_header.gif , graphics/waae_w_center.gif ,
graphics/waae_footer.gif , ;
#textarea: 1 , 1 , txtLicense1 , 782 ;
#filearea: 2 , 1 , faResponseFile , License.txt , rbAccept , , 0 , 0 , 0 , 0 ;
#textarea: 3 , 1 , txtLicense2 , 707 ;
#radiobutton: 10 , 1 , rbAccept , 1343 , grpRB , $PIF_CHANGECONTROL_btnAccept=1 , 0 , , , 0 , 0 ;
#radiobutton: 9 , 1 , rbNotAccept , 1342 , grpRB , $PIF_CHANGECONTROL_btnAccept=0 , 1 , , , 0 , 0 ;
#navbutton: 1 , btnPrev , 501 , 5 , , scripts/d_pifback.sh ;
#navbutton: 2 , btnAccept , 500 , 5 , , scripts/as_navigation.sh ;
#navbutton: 3 , btnDecline , 502 , 2 , , dlgDeclineExit ;
#navbutton: 4 , btnEula , 1351 , 2 , , dlgVendorEULA ;
@ENDDIALOG:

Page 78
The yellow highlighted strings above identify the name of each dialog. The gray highlighted strings above identify the
verification script that will be called prior to the calling of the navigation script (red highlighted, above). Every AE dialog (or
panel) calls the verification script before calling the navigation script. One reason for this is because the AE installation has
incorporated its own navigation mechanism. In other words, AE uses its own forward/backward logic instead of using the
built-in PIF navigation controls. This was done because the built-in PIF controls did not have all of the navigation
requirements that AE needed.
In addition to the as_install*.trc file, there are two other files automatically created in the system temporary directory that
are useful in solving interview problems:
as_install<pid>.vars
as_install<pid>.tvars
The as_install<pid>.vars file contains all environment and installer variables and values at the time the user clicks Install.
The as_install<pid>.tvars file contains a snapshot of all environment variables and installer variables at the time each dialog
is processed. Each snapshot begins with the dialog name, allowing you to easily identify its starting point. For example:
--------------------------------------------------------------------
--------------------------------------------------------------------
V_dlgWelcome
--------------------------------------------------------------------
--------------------------------------------------------------------
<snip>
PREFIX_ca_waae_server=/opt/CA/WorkloadAutomationAE
TGT_DBTYPE=Oracle
Typical_Current=0
WELCOME_VAR=maintenance
SD_EX=ex
ASI_EEM_LOGGING_CYC_BUFFERSIZE=500
ASI_ORA_STGMGT=Not Using Oracle Storage Management,Using Oracle Managed Files (OMF),Using Automatic Storage
Management (ASM)
Agent_Restart=1
Install_AGENT=1
Mod_UpgInst=0
SYB_LOCALE=iso_1
_=/usr/bin/env
--------------------------------------------------------------------
--------------------------------------------------------------------
D_dlgWelcome
--------------------------------------------------------------------
--------------------------------------------------------------------
ASI_AUTOSYS_INSTDIR=/opt/CA/WorkloadAutomationAE
ASI_DATABASE1=AEDB
ASI_DATA_DIR_save=
ASI_INSTALL_TYPE=
ASI_NCARGS_CURRENT=0
PIF_CHANGECONTROL_fldeemadmin=0
SCHED_Instd=0
SRC_JDBC_PATH=
WebSvr_Start=1
ASI_AGT_ENCRYPT_KEY_V=
ASI_SHUTDOWN_R11_AGENT=0
ASI_SHUTDOWN_SCHED_INST=
ASI_SYB_SA_USER=sa
CAPKI_WAAE_Caller=WAAE1135
<snip>

Page 79
AE Interview Forward and Backward Navigation Logic Flow

The complexity of the AE installation flow does not lend itself to the built-in PIF navigation controls. As such, AE uses its
own forward/backward mechanism, which is illustrated below.
CA Workload Automation AE r11.3.5 Dialog Navigation Flowchart

Page 80
The $AS_PIF_FLOW variable serves as the dialog stack, mentioned in the above flowchart. The variable is stored in the
as_install<pid>.*vars files, and contains all dialog names, space delimited, that have been navigated. For example, by
searching for AS_PIF_FLOW using grep, you can easily “watch” the navigation path taken.
# cd /tmp
# grep AS_PIF_FLOW as_install21187.tvars
AS_PIF_FLOW=dlgWelcome
AS_PIF_FLOW=dlgMustShutDown dlgWelcome
AS_PIF_FLOW=dlgLicense dlgMustShutDown dlgWelcome
AS_PIF_FLOW=dlgInstallType dlgLicense dlgMustShutDown dlgWelcome
AS_PIF_FLOW=dlgAGTInfo dlgInstallType dlgLicense dlgMustShutDown dlgWelcome
AS_PIF_FLOW=dlgAGTInfo dlgInstallType dlgLicense dlgMustShutDown dlgWelcome
As shown above, the navigation path for this installation is Welcome, the Must-Shut-Down panel (evidently there are active
AE or CCS processes), License, Installation Type, and Agent Information. Note that pushing and popping occur LIFO (Last In
First Out).
Depending on the dialog button clicked (Next, Back, Test, or OK), a dialog name is pushed onto or popped from the stack
(the AS_PIF_FLOW variable). This process is a bit tricky because of constraints of the PIF architecture. The following steps
are used in each dialog to control the navigation flow.
On any panel you will find one or more of the buttons Next, Back, Test, and OK.
5. If Next, Test, or OK is clicked:
a. The as_verification.sh script is called to push, if applicable, the dialog name onto the stack. The exceptions to
pushing are when testing the database or EEM server connections. In all other cases, the PushDownOnDialogStack
function is used to accomplish this.
b. The as_navigation.sh script is then called to determine the dialog to display next. This script is specified in the
CAWorkloadAutomationAE.@prm prototype’s dialog definition’s #navbutton control. For example, the Welcome
panel definition’s #navbutton control identifies as_navigation.sh as the script to call.
@DIALOG:
#dhead: 650 , 500 , dlgWelcome , 211 , scripts/as_verification.sh ;
#graphic: grpGraphic , waae_w_west.gif , waae_w_header.gif , waae_w_center.gif , waae_footer.gif , ;
#textarea: 8 , 1 , txtReleaseN , 1341 ;
#textarea: 10 , 1 , txtCopyright , 704 ;
#navbutton: 1 , btnNext , 500 , 5 , , scripts/as_navigation.sh ;
#navbutton: 2 , btnCancel , 502 , 0 , ;
@ENDDIALOG:
All AE dialogs call the as_navigation.sh script, for simplicity. In as_navigation.sh is a function for each panel name.
The function has code which determines which panel should be displayed next. The function echoes the name of
the panel to display and PIF intercepts the name and displays that panel.
2. If Back is clicked:
a. The as_pifback.sh script is called to pop the last dialog name from the stack. As with as_navigation.sh, it echoes
the name of the popped dialog to PIF, who then displays that panel.

Page 81
If there is a problem with the flow (such as a circular flow, skipping a panel, or displaying the same dialog), look in the
as_install<pid>.trc file to identify the dialog order. Then, determine the dialog where the logic flow faltered and fix the
navigation flow, most likely in as_navigation.sh.
AE Interview Database Connection Test

The AE interview verifies database connection information. If the database connection test fails, either there is a problem
with the AE interview’s database test code, or more likely, the user specified incorrect connection information. To eliminate
the possibility that the problem is in the AE interview’s database test code, the interview process can generate, on-the-fly, a
database connection test script for the user to run outside of the AE install. To tell the AE interview process to generate the
test script, do the following:
Oracle Database
1. Run ./wa_setup.sh. When the Database Test dialog displays, run the following command from another terminal session:
# touch /tmp/.as_ora_test
2. Toggle back to the install and click the Test button.

3. From the terminal session you ran the touch command on, run the following command:
# /tmp/.as_ora_test.sh
If .as_ora_test.sh fails, the database user ID, password, or Oracle SID specification is incorrect, or the Oracle
environment is not set up properly. This situation could happen under at least the two following conditions:
a. $ORACLE_HOME/bin/sqlplus is not found.
b. The Oracle user does not have sufficient privileges.
Important: Clicking Back removes /tmp/.as_ora_test.sh and /tmp/.as_ora_test. Make sure you save .as_ora_test.sh if you
need it later before clicking Back.
Sybase Database
1. Run ./wa_setup.sh. When the Database Test dialog displays, run the following command from another terminal session:
# touch /tmp/.as_syb_test
6. Toggle back to the install and click the Test button.

7. From the terminal session you ran the touch command on, run the following command:
# /tmp/.as_syb_test.sh
If .as_syb_test.sh fails, the database user ID, password, or Sybase Server specification is incorrect, or the Sybase
environment is not set up properly. This situation could happen under at least the two following conditions:
a. $SYBASE/bin/isql is not found.
b. The Sybase user does not have sufficient privileges.
Important: Clicking Back removes /tmp/.as_syb_test.sh and /tmp/.as_syb_test. Make sure you save .as_syb_test.sh if you
need it later before clicking Back.

Page 82
Section 4: Benefits
Assist the Customer – Enable Technical Support

Assist the Customer
The overriding purpose of the cookbook is to improve your out-of-the box experience with the product. Technical Support
In a perfect world, there would be no problems and the documentation would read as a best seller. Until we get to that
point, Technical Support stands ready to quickly and efficiently serve the customer.
Enable Technical Support

This cookbook provides details and underlying reasons for why various procedures were done in a particular way. This
information was made available from R&D and QA. As such, the cookbook has not gone through multiple levels of
proofreading, and may not be up to current CA Technologies’ formatting standards. However, it does contain answers that
Technical Support needs to know at a moment’s notice. In effect, the cookbook enables Technical Support to be ever more
efficient and confident as they virtually meet with customers.
Section 5
Conclusions
Most of the cookbook focuses on installation, upgrade, and data migration topics. Each exercise invites stress and anxiety.
The more precise the documentation is, the more useful it becomes. As the current CA Technologies standards do not
provide for screen shots in official documentation, we have created this cookbook to show customers various screen shots
and specific methods to assist them through these often unclear screen entry and selection activities.
Section 6
References
------ CACDF Script File Command Syntax Guide, CA Technologies, December 2012:
https://km.ca.com/technicalsupport/advisors/CACDF/Shared%20Documents/Forms/AllItems.aspx
------ CA Workload Automation AE UNIX Implementation Guide, Release 11.3.5, CA Technologies, 2012.
------ CA Embedded Entitlements Manager Implementation Guide, Release 12.0, CA Technologies, 2011.
------ CA Workload Control Center Implementation Guide, Release 11.3.5, CA Technologies, 2012.
------ CA Common Components Implementation Guide, Release 11.3.5, CA Technologies, 2012.

Page 83
Section 7
About the Authors

David W. Martin is a Senior Principal Software Engineer who is responsible for the AE and CCC
installation processes. He has over 29 years of experience in IT, starting out in VSE and MVS Technical
Support and moving to product development at Goal Systems International, Inc., and later at the
Legent Corporation.
After joining CA Technologies in 1995, David transitioned from mainframe to distributed systems product
development, where he worked on Unicenter TNG/TND, and on the SAP/AG and PeopleSoft Adapters. In
2008, David was elected to the CA Council for Technical Excellence, where he served as Membership and
Infrastructure Committee Chair. He also served as an editorial member of the CA Technology Exchange
publication and currently serves as a CA Mentor and a core team member of the TechScan2 project.
Joseph E. Neumann is a Program Manager for the Distributed WA product area at CA Technologies.
He has over 36 years of experience in the IT industry. He started his carrier with AT&T Bell
Laboratories. He worked there for 26 years on a range of assignments which included Product
Design, Feature Coding, QA testing and management of System Administration teams for various
product areas. Joe also worked as an educator and assignment advisor for the company’s Asian
expansion organization.
Joe joined CA Technologies in 2003 in the Distributed Technical Support organization. The first
product area he worked in was Unicenter DB Performance. He later moved to the AutoSys product
area, which has been renamed Workload Automation AE. He was one of the product’s Support
Delivery Managers prior to his new assignment as Program manager.
Lee Peterson is a Principal Support Engineer. . . .

253 r11 3 5 Cookbook

Uploaded by

Copyright:

Available Formats

253 r11 3 5 Cookbook

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

253 r11 3 5 Cookbook

Uploaded by

Copyright:

Available Formats

TECHNICAL PAPER: CA Workload Automation AE r11.3.

CA Workload Automation Development and Support Teams

Updated March 15, 2013, 12:32 EST.

The manufacturer of this Documentation is CA.

CA Workload Automation AE r11.3.5 – Support Cookbook

CA Workload Automation AE r11.3.5 – Support Cookbook

CA Workload Automation AE r11.3.5 – Support Cookbook

Section 1: CACDF Topic

To use CA CDF to gather diagnostic information about AE

In the CACDF directory is a “gz” tar file. For example:

2. The contents of the extracted tar file are listed below.

CA Workload Automation AE r11.3.5 – Support Cookbook

cacdf.sh getprod.vbs osdoc_HPUX.txt treeview.js

CA Workload Automation AE r11.3.5 – Support Cookbook

CA Workload Automation AE r11.3.5 – Support Cookbook

Preparing to execute diagnostic command: /bin/df –k

CA Workload Automation AE r11.3.5 – Support Cookbook

Section 2: Install Caveats To Be Aware Of

EEM Install and A Non-root User

CA Workload Automation AE r11.3.5 – Support Cookbook

EEM Install and IPv6

CA Workload Automation AE r11.3.5 – Support Cookbook

AE Directory and File Permissions

1. The following directories do not require world-writeable permissions.

They can be altered to 775.

They can be altered to 775.

CA Workload Automation AE r11.3.5 – Support Cookbook

Object Name Type Old New Old New

/opt/CA/WorkloadAutomationAE Dir 777 775 root/root autosys/autosys

/opt/CA/WorkloadAutomationAE/webserver Dir 777 750 - -

$AUTOSYS/install/CAPKI Dir 777 755 - -

$AUTOSYS/install/eiam.server.config File 666 600 - -

$AUTOSYS/install/eiam.client.config File 666 655 - -

$AUTOSYS/install/eiam.ws.config File 666 600 - -

$AUTOSYS/install/logger.server.config File 666 600 - -

$AUTOSYS/install/logger.client.config File 666 655 - -

$AUTOSYS/install/logger.ws.config File 666 600 - -

$AUTOSYS/install/data Dir 777 775 - -

$AUTOSYS/install/webserver Dir 777 750 - -

$AUTOSYS/install/webserver/AEWS Dir 777 750 - -

/opt/CA/WorkloadAutomationAE/CommandSponsor Dir 777 750 - -

/opt/CA/WorkloadAutomationAE/JRE_WA Dir 777 750 root/root autosys/autosys

/opt/CA/WorkloadAutomationAE/JRE_WA/1.6.0_33 Dir 777 750 root/root autosys/autosys

/opt/CA/WorkloadAutomationAE/JRE_WA/1.6.0_33/* Dir & File - - root/root autosys/autosys

/opt/CA/WorkloadAutomationAE/JRE64_WA Dir 777 750 root/root autosys/autosys

/opt/CA/WorkloadAutomationAE/JRE64_WA/1.6.0_33 Dir 777 750 root/root autosys/autosys

/opt/CA/WorkloadAutomationAE/JRE64_WA/1.6.0_33/* Dir & File - - root/root autosys/autosys

$AUTOUSER Dir 777 775 - -

$AUTOUSER /audit Dir 777 +t - -

$AUTOUSER/webserver/webapps/AEWS Dir 777 750 - -

$AUTOUSER/eiam.server.config File 666 600 root/root autosys/autosys

$AUTOUSER/eiam.client.config File 666 655 root/root autosys/autosys

$AUTOUSER/logger.server.config File 666 600 root/root autosys/autosys

$AUTOUSER/logger.client.config File 666 655 root/root autosys/autosys

CA Workload Automation AE r11.3.5 – Support Cookbook

Upgrade AutoSys and WCC

Product to Dependent Products Upgrade Steps to AE r11.3.5, Including WCC r11.3.5

Product to Dependent Products Upgrade Steps to AE r11.3.5, Including WCC r11.3.5

CA Workload Automation AE r11.3.5 – Support Cookbook

perl CreateAEDB.pl SYBASE sa_user sa_pswd aedbadmin_pswd autosys_pswd

perl CreateAEDB.pl SYBASE sa_user sa_pswd aedbadmin_pswd autosys_pswd