7 0 Saa Aix Inst Guide

Alliance Access 7.0

Installation and Administration GuideThis installation guide explains how to install and administer Alliance Access on AIX, and how to prepare the systemprior to installation. This document is for system administrators and anyone that installs Alliance Access. Knowledge ofAIX is a prerequisite for readers of this document.

31 December 2010

AIX

Connectivity

Table of Contents

.Preface .............................................................................................................................................................................7

Part A – Installation .............................................................................................................................................9

1 Installation Features Overview ............................................................................................................... 11

2 Preparation ...................................................................................................................................................... 13

2.1 Getting Started ......................................................................................................................................... 13

2.2 Prepare the System ................................................................................................................................ 15

2.3 Tracking What Happens During Installation ....................................................................................... 18

2.4 Create the Temporary Installation Directory ....................................................................................... 19

2.5 Prepare for Non-root Installation, Upgrade, Backup, or Removal ................................................... 19

2.6 Create the sagsnlg and alliance Group ............................................................................................... 20

2.7 Prepare the Licence File ........................................................................................................................ 20

2.8 Prepare the Response File (for Silent Installation, Upgrade, Relicensing, or Removal) ............. 21

2.9 Protect the Passwords in the Response File ...................................................................................... 22

2.10 Prepare for a Hosted Database Installation ........................................................................................ 22

2.11 Prepare a Backup File for Upgrade ...................................................................................................... 27

3 Installation ........................................................................................................................................................ 31

3.1 Before You Install .................................................................................................................................... 31

3.2 Interactive Installation ............................................................................................................................. 32

3.3 Silent Installation ..................................................................................................................................... 42

3.4 Next Steps ................................................................................................................................................ 46

4 Upgrade ............................................................................................................................................................. 58

4.1 Before You Upgrade ............................................................................................................................... 58

4.2 Interactive Upgrade ................................................................................................................................. 61

4.3 Silent Upgrade ......................................................................................................................................... 69

4.4 Next Steps ................................................................................................................................................ 73

5 Relicensing ...................................................................................................................................................... 75

5.1 Before You Relicense ............................................................................................................................. 75

5.2 Interactive Relicensing ........................................................................................................................... 76

5.3 Silent Relicensing .................................................................................................................................... 79

5.4 Next Steps ................................................................................................................................................ 79

6 Removal ............................................................................................................................................................ 81

6.1 Before You Remove ............................................................................................................................... 81

6.2 Interactive Removal ................................................................................................................................ 81

6.3 Silent Removal ......................................................................................................................................... 82

7 Patches .............................................................................................................................................................. 83

7.1 Installation ................................................................................................................................................ 83

7.2 Removal .................................................................................................................................................... 84

Alliance Access 7.0 - AIX

2 Installation and Administration Guide

8 Additional Information ................................................................................................................................ 85

8.1 Non-root Installation or Upgrade ........................................................................................................... 85

8.2 Silent Mode .............................................................................................................................................. 85

8.3 Licence Files for Alliance Access ......................................................................................................... 91

8.4 Checking Your System Configuration .................................................................................................. 91

8.5 The Software Integrity Report ............................................................................................................... 94

Part B – Configuring for SWIFTNet ......................................................................................................95

9 Introduction ..................................................................................................................................................... 97

10 Check Connectivity ...................................................................................................................................... 98

10.1 Configure SWIFT DNS Servers ............................................................................................................ 98

10.2 Confirm Connectivity ............................................................................................................................... 98

11 Defining Alliance Access in Alliance Gateway ................................................................................ 99

11.1 Concepts ................................................................................................................................................... 99

11.2 FIN Messaging ......................................................................................................................................... 99

11.3 InterAct and FileAct Messaging .......................................................................................................... 101

11.4 Data Encryption/Gateway Authentication between Alliance Access and AllianceGateway .................................................................................................................................................. 103

12 Configuring Alliance Access for FIN Messaging .......................................................................... 104

12.1 Defining a SWIFTNet Connection ...................................................................................................... 104

12.2 Assigning a SWIFTNet Connection to a Logical Terminal ............................................................. 105

12.3 Sending and Receiving a Test MT Message .................................................................................... 105

12.4 Access to the SWIFTNet FIN Test Service (Vendors only) ............................................................ 105

13 Configuring Alliance Access for InterAct and FileAct Messaging ....................................... 107

13.1 Defining a SWIFTNet Connection ...................................................................................................... 107

13.2 Installing Application Service Profiles ................................................................................................ 107

13.3 Configuring SWIFTNet Emission and Reception Profiles ............................................................... 107

13.4 Sending and Receiving an InterAct or a FileAct Message ............................................................. 108

Part C – System Administration ...........................................................................................................111

14 Introduction to System Administration ............................................................................................. 113

14.1 Overview of the System Administration Application ........................................................................ 113

14.2 System Management Procedures ...................................................................................................... 117

14.3 The Alliance Release Tree .................................................................................................................. 118

15 An Introduction to Dual Configuration Support ............................................................................ 121

15.1 Alliance Access Operations ................................................................................................................. 121

15.2 HACMP Overview ................................................................................................................................. 122

15.3 Alliance Access Dual Hardware Configuration ................................................................................. 122

15.4 Important Technical Documentation on Dual Configuration and HACMP ................................... 125

16 General System Maintenance ................................................................................................................ 128

16.1 System Management Commands ...................................................................................................... 128

Table of Contents

31 December 2010 3

16.2 Essential System Maintenance ........................................................................................................... 130

17 Managing UNIX Accounts ....................................................................................................................... 133

17.1 Alliance Administrator Account ........................................................................................................... 133

17.2 Security Considerations ....................................................................................................................... 133

17.3 The alliance_init File ............................................................................................................................. 134

17.4 Workstation IP Address Checking ...................................................................................................... 134

17.5 The Instance Registration File ............................................................................................................ 134

18 Managing the Alliance Access Servers ............................................................................................ 136

18.1 Starting the Alliance Access Servers ................................................................................................. 136

18.2 Stopping the Alliance Access Servers ............................................................................................... 140

18.3 Running Selected Program Scripts following Server Start and Stop ............................................ 144

18.4 Monitoring Processes ........................................................................................................................... 144

19 Backing Up Data .......................................................................................................................................... 147

19.1 Database Backup .................................................................................................................................. 147

19.2 Archive Backup ...................................................................................................................................... 148

19.3 Temporary Storage Directory for Backup .......................................................................................... 148

19.4 Performing a Manual Backup of Archives ......................................................................................... 149

19.5 Performing a Manual Backup of the Database ................................................................................. 151

19.6 Scheduling Automatic Backups .......................................................................................................... 153

19.7 Following a Backup ............................................................................................................................... 153

20 Restoring Data .............................................................................................................................................. 154

20.1 Restoring an Archive Backup .............................................................................................................. 154

20.2 Restoring the Alliance Access Database .......................................................................................... 156

21 Managing Disk Space ................................................................................................................................ 161

21.1 Monitoring Available Disk Space ........................................................................................................ 161

21.2 Modifying Disk Space Parameters ..................................................................................................... 161

21.3 System Resources ................................................................................................................................ 162

21.4 How To Recover Disk Space .............................................................................................................. 162

21.5 Backing Up the Instance Registration File ........................................................................................ 162

22 Managing the Database ............................................................................................................................ 163

22.1 Getting Information about the Alliance Access Database .............................................................. 163

22.2 Checking the Alliance Access Database ........................................................................................... 163

22.3 Configuring the Embedded Database ................................................................................................ 164

22.4 Backing Up the Alliance Access Database ....................................................................................... 165

22.5 The saa_bankquery Tool ..................................................................................................................... 166

23 Database Recovery .................................................................................................................................... 168

23.1 About Database Recovery ................................................................................................................... 168

23.2 Database Configuration for Enhanced Resiliency ........................................................................... 170

23.3 Database Recovery Process ............................................................................................................... 172

23.4 Database Recovery Backups .............................................................................................................. 174

23.5 Repairing Messages ............................................................................................................................. 176



23.6 The saa_dbrecovery Command ......................................................................................................... 178

24 Handling System Failures ....................................................................................................................... 183

24.1 Process Failure ...................................................................................................................................... 183

24.2 Power Failure ......................................................................................................................................... 184

24.3 Disk Failure ............................................................................................................................................ 184

24.4 Recovery on a Different Host Using a Cold Backup ........................................................................ 185

25 Replication of Configuration Data ....................................................................................................... 190

25.1 Configuration Replication ..................................................................................................................... 190

25.2 Handling the Export and Import of Sensitive Data ........................................................................... 192

25.3 Entities Eligible for Export and Import ................................................................................................ 193

25.4 Status Management of Entities for Import ......................................................................................... 197

25.5 Parameter File for Configuration Replication .................................................................................... 199

25.6 Exported Fields ...................................................................................................................................... 203

25.7 Export Configuration Data ................................................................................................................... 210

25.8 Import Configuration Data .................................................................................................................... 210

25.9 Report File for Configuration Replication .......................................................................................... 212

26 Operational Integration ............................................................................................................................ 214

26.1 Overview of Operational Integration ................................................................................................... 214

26.2 Operational Monitoring ......................................................................................................................... 215

26.3 Operational Management .................................................................................................................... 222

27 Using Command Line Tools ................................................................................................................... 226

27.1 saa_manageasp .................................................................................................................................... 226

27.2 saa_configconnection ........................................................................................................................... 226

27.3 saa_system ............................................................................................................................................ 227

27.4 saa_configbootstrap ............................................................................................................................. 233

27.5 saa_bootstrap ........................................................................................................................................ 235

27.6 Alliance CIFA Export ............................................................................................................................. 236

27.7 TCP/IP Service Files ............................................................................................................................. 237

27.8 The Reset Message Partners (reset_mp) Script .............................................................................. 237

28 TCP Configuration for the Alliance Access Server ..................................................................... 239

28.1 Port Configuration ................................................................................................................................. 239

28.2 apply_alliance_ports Tool .................................................................................................................... 240

29 General Troubleshooting ........................................................................................................................ 242

29.1 The Alliance Configuration Report ..................................................................................................... 242

29.2 The JOURNAL_query Facility ............................................................................................................. 244

Part D – Appendices .......................................................................................................................................247

.Appendix A Setup Recommendations ...........................................................................................................249

A.1 Alliance Access for Service Bureaux ................................................................................................. 249

A.2 Alliance Access as Standalone Message Entry and Repair System ............................................ 251

.Appendix B Command Line Tool Syntax Reference ...............................................................................269

Table of Contents

31 December 2010 5

B.1 checkhost ............................................................................................................................................... 269

B.2 reset_mp ................................................................................................................................................. 269

B.3 saa_bankquery ...................................................................................................................................... 270

B.4 saa_bootstrap ........................................................................................................................................ 270

B.5 saa_configbootstrap ............................................................................................................................. 270

B.6 saa_configconnection ........................................................................................................................... 271

B.7 saa_dbconfig .......................................................................................................................................... 271

B.8 saa_dbinfo .............................................................................................................................................. 272

B.9 saa_dbrecovery ..................................................................................................................................... 273

B.10 saa_dbrestore ........................................................................................................................................ 274

B.11 saa_export .............................................................................................................................................. 275

B.12 saa_import .............................................................................................................................................. 277

B.13 saa_manage .......................................................................................................................................... 278

B.14 saa_manageasp .................................................................................................................................... 279

B.15 saa_monitor ........................................................................................................................................... 280

B.16 saa_msgrepair ....................................................................................................................................... 282

B.17 saa_rtfilegetrequest .............................................................................................................................. 283

B.18 saa_system ............................................................................................................................................ 284

B.19 swrpc_keytool ........................................................................................................................................ 286

.Legal Notices .............................................................................................................................................................288



PrefacePurpose

This guide describes how to install, configure, and administer Alliance Access on AIX. Theguide includes an introduction to dual-configuration support and system administration.

Audience

This guide is for anyone who installs Alliance Access. Knowledge of how to use AIX is aprerequisite for the readers of this document.

In general, the information provided in this guide is designed for users connecting to SWIFT andthe FIN application. Where appropriate, information is also provided for users connecting toother networks.

Preface

31 December 2010 7



Part A

Installation

Part A - Installation

31 December 2010 9



1 Installation Features OverviewIntroduction

This section describes the new installation-related features that are available for AllianceAccess.

Hosted database or embedded database

In an embedded database environment, the product software uses the database supplied withthe product. In a hosted database environment, you install Alliance Access within an existingdatabase.

For information about the configuration of hosted database environments, see "Prepare for aHosted Database Installation" on page 22.

Silent mode

You can perform the installation, upgrade, patch, relicensing, and removal operations in silentmode. The main difference between interactive (GUI-based) operations and operationsperformed in silent mode is the way input data is provided. In a GUI-based procedure a userprovides input through GUI-windows. An operation launched in silent mode does not requireinteractive user input, instead a response file and a licence file provide this input.

The use of response files and licence files reduces the time required to perform and repeat theoperation, especially if you have a large number of Alliance Access instances. Furthermore, theuse of a response file allows for segregation of duties: operations managers can prepare theresponse files in advance, and the operation itself can be scripted or carried out by other peopleof the organisation. SWIFT provides templates of response files with default values, oralternatively, you can run an interactive installation to generate a response file and a licence file.For more information about using the silent mode, see "Silent Mode" on page 85.

Options for software licensing

Licence data can be provided either directly on screen, or from a file.

When Where How

during an interactive softwareinstallation, relicensing, orupgrade

in the licensing windows • Enter licence data on screen.

• Provide licence data from alicence file.

during silent installation,relicensing, or upgrade

from a command line Provide licence data in a licencefile.

For more information about the licensing options, see "Relicensing" on page 75.

Secure Channel

Secure Channel improves the way Alliance software licence data is distributed. Previously, theAlliance Left Security Officer (LSO) and Right Security Officer (RSO) received the licence datafor the Alliance products on paper. With Secure Channel, licence data is no longer distributedon paper by post. They can now be securely viewed online.

To access Secure Channel, you must be registered on www.swift.com and have the appropriateaccess rights defined in your user profile.

For more information, see Secure Channel on www.swift.com.

Installation Features Overview

31 December 2010 11

http://www.swift.com

http://www.swift.com/support/secure_channel.page?


Recording the installation

The interactive installation features the option to record the input information provided duringthe installation into a response file. A command-line based silent installation procedure can usethis response file to provide the same installation information in subsequent installations. Thisreduces the risk of human error from manual intervention. For more information about recordingthe installation, see "Response Files" on page 86.

Recording the licence information

The interactive installation features the option to record the licence information (except licencekeys which are recorded in the response file) provided during the installation into a licence file.Use this file to provide the same licence information in subsequent licensing or relicensingtasks.

For more information about recording the licence information, see "Response Files" onpage 86.

Performing actions as a non-root user

It is possible to install, patch, remove, or upgrade the Alliance Access software with a non-rootuser account, such as, all_adm. The non-root user account becomes the Alliance administrator,and the owner of the instance.

Before you can take an action (such as, installation) with a non-root user account, the root usermust prepare the system for the action that the non-root user will perform.

To complete the installation, the root user must perform some post-installation tasks.

For more information, see "Non-root Installation or Upgrade" on page 85.



2 Preparation

2.1 Getting StartedRelease Letter

A Release Letter for Alliance Access 7.0, provides essential information about the AllianceAccess software that you are about to install or upgrade. For example, it provides additionalchecks, instructions, or tips that you need to know before you install, upgrade, or relicense thesoftware.

Installation media

The Release Letter lists the channels through which the Alliance Access software is distributed.In this guide, "release media" refers to any media that provides the software, for example, aDVD, or a file downloaded from www.swift.com.

The release media provides an installation program (called an installer) which allows you toinstall or upgrade Alliance Access easily. You can launch the installation program directly from aDVD or from a hard disk.

You can install or upgrade Alliance Access from the following locations:

• DVD:

– local

– remote DVD drive, that is, a drive on a remote AIX machine

• Directory on hard disk:

– local disk

– remote disk, that is, a disk on a remote AIX machine

To get started

1. Read the Alliance Access Release Letter, if you have not already done so.

2. Determine which task you need to perform, and prepare for that task. See "Preparationchecklist" on page 14.

3. After you perform the generic preparation tasks, review the prerequisites and checklists inthe sections, "Installation" on page 31 and "Upgrade " on page 58, and complete anyadditional preparation tasks described there.

4. Perform the task required:

• "Installation" on page 31

• "Upgrade " on page 58

• "Relicensing" on page 75

• "Removal" on page 81

• "Patches" on page 83

Preparation

31 December 2010 13

5. Review the Post-Installation or Post-Upgrade sections in the Release Letter, asappropriate, and complete any additional tasks that are specified there.

6. Complete the Next Steps in the relevant sections, which describe the configuration tasksthat are required to make your system operational.

Review also the Additional Configuration section in the Release Letter, and complete anyadditional tasks that are specified there.

Preparation checklist

The columns in the table are not mutually exclusive. Therefore, you must perform thepreparation tasks that are indicated in the relevant columns:

Preparation Task Inst

all w

ith

em

bed

ded

dat

abas

e

Inst

all w

ith

ho

sted

dat

abas

e

Up

gra

de

- st

and

ard

Up

gra

de

fro

m p

rep

ared

bac

kup

Rel

icen

se

Rem

ove

Pat

ch

Use

sile

nt

mo

de

Lau

nch

op

erat

ion

as

no

n-r

oo

t

Read the release Letter ✓ ✓ ✓ ✓ ✓ ✓ ✓

"Prepare the System" onpage 15

✓ ✓ ✓ ✓

"Create the TemporaryInstallation Directory" onpage 19

✓ ✓ ✓ ✓

"Prepare for Non-rootInstallation, Upgrade,Backup, or Removal" onpage 19

✓

"Create the sagsnlg andalliance Group" onpage 20

✓

"Prepare the Licence File"on page 20

✓

"Prepare the ResponseFile (for Silent Installation,Upgrade, Relicensing, orRemoval)" on page 21

✓

"Protect the Passwords inthe Response File" onpage 22

✓

"Prepare for a HostedDatabase Installation" onpage 22

✓

"Prepare a Backup File forUpgrade" on page 27

✓



2.2 Prepare the SystemIntroduction

Review each of the topics in this section to identify the actions that you need to take to prepareyour system for an installation or upgrade of Alliance Access.

System requirements

For details of the required operating systems and Service Pack levels, see the Release Letter.

The installation program checks for the minimum requirements. Before installing AllianceAccess, you can also use the checkhost tool to verify that the system meets the minimumrequirements. This tool is provided on the release media. If any problems are detected, thenyou must resolve them before starting the installation. For instructions on how to use this tool,see "Checking Your System Configuration" on page 91.

2.2.1 Define the Alliance File System

Introduction

It is important to consider carefully the size and location of the file system in which AllianceAccess is installed, before you start the installation process. Otherwise, if changes have to bemade later, then lengthy reorganisation of disk resources will be required.

File system location and permissions

The default directory that is proposed for the installation is /Alliance/Access.

Important If you create or select a different directory during the installation, you must ensurethat the user who runs the installation (by default, all_adm) has full read and writeaccess to this directory. For more information about setting permissions on theinstallation directory, see "Prepare for Non-root Installation, Upgrade, Backup, orRemoval" on page 19.

Alliance Access can be installed on a UNIX File System (UFS), if the minimum systemrequirements are met. This file system must have read-write permission. Your AIX systemadministrator must decide exactly where to install Alliance Access.

Disk space

Before purchasing Alliance Access, SWIFT advised your organisation of the minimum amountof disk space required for the expected level of operations. This figure must be taken as aminimum requirement. The exact amount of space needed for operational data depends on thetraffic processed, number of operators, the frequency with which archives are backed up andremoved, and so on. Clearly, there are advantages in allocating as much space as possible tothe file system in which AIX is installed. For more information about disk space requirements,see the Release Letter.

By default, the software and the database are installed on the same file system. To increaseperformance, the database can be split over several disks. In this case, the configuration of thedatabase is done using dedicated tools (saa_dbinfo, saa_dbconfig), after installation.

Mounting local file systems

If the Alliance Access file system is mounted locally, then it is important that no "mount options"are used, particularly nosuid. If nosuid is used, then problems can occur when an AllianceAdministrator logs on.

Preparation

31 December 2010 15

2.2.2 Automatic Time Synchronisation

Overview

When automatic time synchronisation is performed, the time is checked periodically on anumber of machines and compared with a reference time. This is generally done using theNetwork Time Protocol (NTP). When necessary, the system time is changed.

On UNIX, NTP is not enabled by default. Therefore, if you want to use NTP on UNIX, make surethat the slewing mode is implemented.

Automatic time synchronisation must be switched off while the Alliance Access servers arerunning because Alliance Access makes extensive use of date and time in its processing. Amanual synchronisation can be done when the servers are stopped (for instance, using a poststop server script).

Note Problems can occur due to timestamp conflicts in the Alliance Access database,when the system time is changed while the Alliance Access servers are running.

Synchronisation modes

Two synchronisation modes exist:

• stepping mode: for large time differences between the system time and the reference time,the system will step or jump to the correct time. This can be done forward or backward. If theAlliance Access servers are running during this time change, then a system freeze can occur.

• slewing mode: for small time differences between the system time and the reference time,the system will slew the time. The NTP daemon will increase or decrease the speed of theCPU to match the reference time. By doing so, there is no jump in the system's time; italways moves forward.

The implementation of the slewing mode can be considered as acceptable as it does notdeviate from the fact that time only goes forward. However, we have already experiencedproblems on systems where slewing mode was not working as expected due to incorrectfunctioning of the complete time server system. In those cases we did see in the logfiles that thetime moved backwards resulting in Alliance Access restarts.

2.2.3 System Setup

Introduction

Use this checklist to configure the basic hardware and operating system.

System setup checklist

Action Responsible Documentation

Install basic system hardware Hardware Vendor IBM manuals

Install DVD drive Hardware Vendor IBM manuals

Install AIX with supported packages andcomponents (see "Prerequisites for theInstallation" on page 31)

AIX System Administrator AIX manuals

Alliance AccessRelease Letter

Configure disk partitions and paging space(see "Prerequisites for the Installation" onpage 31)





Define file systems and logical volumes AIX System Administrator AIX manuals

Install and configure LANs and LANconnections


For interactive operations:

X-terminals and associated ports areconfigured and available


Assign a <host name> AIX System Administrator AIX manuals

Allocate TCP/IP addresses AIX System Administrator AIX manuals

2.2.4 Required Information

Purpose

Perform the basic setup of the system, as listed in "System Setup" on page 16. Then, use thischecklist to ensure that you have all the required information at your disposal before installing orupgrading Alliance Access.

Checklist

Check the following items:

Required information Responsible Reference

Release Letter AIX System Administrator Release media

Licensing details (as notified bySWIFT to Security Officers)

Security officers SWIFT licensing agreement

Part 1 of the InitialisationPassword

Left security officer SWIFT licensing agreement

Part 2 of the InitialisationPassword

Right security officer SWIFT licensing agreement

Details of the required softwareinstallation directory

AIX System Administrator -

For interactive operations:

Identity of the display terminalused for installation


Identity of your DVD drive AIX System Administrator AIX manuals

2.2.5 Software Installation and Licensing

Checklist

Use this checklist when installing and licensing Alliance Access on your system and for yourdestinations.

Software installation and licensing checklist


Log on to the "root" or AllianceAdministrator account

Alliance Administrator AIX manuals

Preparation

31 December 2010 17


Start installation process fromDVD or directory

Alliance Administrator "Installation" on page 31

Perform licensing procedures Alliance Administrator andSecurity Officers

Follow system configurationdialogues and check for errors

Alliance Administrator

Wait for files to be copied Alliance Administrator

Check for successful completion Alliance Administrator

Log out of the "root" or AllianceAdministrator account

Alliance Administrator

Store release DVD in a safeplace

Alliance Administrator -

2.3 Tracking What Happens During InstallationOverview

The installation process consists of various steps. Some steps are automatic whereas othersrequire that you enter particular values or make choices from a range of options. In general, ifyou complete a particular step successfully, the next window appears automatically.

Having installed Alliance Access software, and performed any additional hardware-relatedconfiguration activities, initial configuration activities must also be performed within AllianceAccess, as described in "Post-Installation Checklist" on page 46.

Following the installation, additional configuration activities may have to be performed,depending on the Alliance options used by your installation.

When Alliance Access software is installed and fully operational, your Alliance Accessadministrator can reconfigure parts of your system and perform various administrative tasks tomaintain your system daily (for example, back up and restore the Alliance Access database).

Installation log

The steps that are completed successfully are recorded in the installation.log. In addition, theevents that occur during the installation are recorded in the installation.log, and in theinstallation_systemcheck_yymmdd_hhmmss.html file.

These files are found in the Alliance Access installation directory, or else, in the temporaryinstallation directory. For more information about the temporary directory, see "Create theTemporary Installation Directory" on page 19.

The log is stored in the temporary directory until you successfully provide the path and name ofthe installation directory during the installation. After you provide the installation directorysuccessfully, then the log is stored there.

If an error occurs during installation

If a problem occurs during the installation process, then an error message appears, describingthe nature of the error, as well as giving the full text of the actual error message reported byyour system.

If the nature of the error is serious (for example, there is a problem with your release media),then you are prompted to abort the installation. Generally, you must not attempt to continue the



installation if a problem occurs. However, if an error is easily resolved (for example, you enteredthe licensing details incorrectly), then you are asked to repeat the last action. Once corrected,the installation proceeds normally.

In all cases, make a note of the error message before you stop and restart the installationprocedure. If in doubt, then contact your System Administrator for advice.

If a problem cannot be resolved, then contact Support for further assistance.

2.4 Create the Temporary Installation DirectoryDescription

You must ensure that a temporary directory is available before launching product installation orupgrade, or patch installation. This is so that information relating to the installation/upgrade canbe logged somewhere before the actual installation directory is known by the system.

This temporary directory is specified in either of the following ways:

• When launching the installation or upgrade command, by appending the -tempdir option tothe command, followed by a directory path (for example, ./saa-install -tempdir<directory path>).

• Define a directory path in the "TMPDIR" environment variable.

• Let UNIX use the /var/tmp or /tmp default temporary directory.

2.5 Prepare for Non-root Installation, Upgrade,Backup, or Removal

Introduction

The user that installs the Alliance Access software becomes the owner of the Alliance Accessinstance. To prepare for a backup, installation, upgrade, or removal operation of AllianceAccess with an account that does not have root privileges, the UNIX root account must performspecific tasks before and after the operation.

The non-root user account must be the same operating system account that owns theSWIFTNet Link instance.

You can ignore this section if you intend to perform these actions with the root user account.

Preparation tasks

To prepare for a non-root user to install, back up, upgrade, or remove Alliance Access, do thefollowing:

1. Log on with the root user account.

2. Create the sagsnlg and alliance groups.

3. Add the non-root user account to the sagsnlg and alliance groups, if not already done.

For more information, see "Create the sagsnlg and alliance Group" on page 20.

This non-root user will become the owner of the installation.

Preparation

31 December 2010 19

4. If you are installing, then create the installation directory with the correct ownership andprotections (750). The default directory path is:

/Alliance/Access

Important The user account that will run the installation must have full access to thisdirectory for example, all_adm.

5. If you are upgrading Alliance Access or Alliance RMA from release 6.3, then change thepermissions of the central registry location. Type:

/usr/bin/chmod 644 /var/opt/swift/*.swiftBefore you upgrade 6.3 to 7.0 on a UNIX cluster with a non-root user, ensure that theversion file (/saa.<date>. swift for Access, /sar.<date>. swift for RMA) in /var/opt/swift/ isreadable for the non-root user.

2.6 Create the sagsnlg and alliance GroupIntroduction

Before installing Alliance Access, create the sagsnlg and alliance groups by completing thesteps in the following procedure.

Procedure

1. Edit the /etc/group file to find out a group ID that is not yet in use. Each line of the /etc/group file looks like:

sagsnlg:!:<group_ID>:alliance:!:<group_ID>:

2. Select two free group IDs depending on your company policy. The group ID is the value inthe third column.

3. Create the groups sagsnlg with the selected group IDs by executing the commands:

mkgroup -A id=<group_ID> sagsnlgmkgroup -A id=<group_ID> alliance

2.7 Prepare the Licence FileApplicability

This procedure explains how to prepare the licence file. Once prepared, the file can be used asan alternative to entering the data interactively.

This procedure is not applicable if the licence file has been downloaded from Secure Channel.For more information about Secure Channel, see "Secure Channel" on page 11.

Procedure

1. Insert the Alliance Access product DVD.

2. On the DVD, in the folder for Alliance Access, navigate to the AIX/installer directory.

3. Copy the silent.properties.lic.saa file from the Alliance Access product DVD to a directoryof your choice.



Note The directory you choose must also contain the appropriate response file(before launching the installation or upgrade).

4. Edit the file to incorporate the information obtained in your licensing agreement.

5. Save the file, using the same file name as the response file followed by extension .lic.

If you intend to perform a non-root installation or upgrade, then save the file so that it canbe read by the user account that performs the non-root installation or upgrade.

2.8 Prepare the Response File (for Silent Installation,Upgrade, Relicensing, or Removal)

Purpose

A response file provides all the user input required to complete a procedure in silent mode.

You can prepare the response file in either of the following ways:

• Record the input provided to a GUI-based procedure, using the -record option. For moreinformation, see "Record input parameters" on page 86.

• Modify the sample response file provided on the Alliance Access product DVD, as describedin this section.

• Modify a previously created response file.

Modify the response file provided on DVD

1. Insert the Alliance Access product DVD.

2. On the DVD, in the folder for Alliance Access, navigate to the AIX/installer directory.

3. Copy the appropriate response file from the Alliance Access product DVD to a directory ofyour choice:

• silent.properties.install.saa.embedded, if you are installing the supplied database

• silent.properties.install.saa.hosted, if you are installing into your own database

• silent.properties.relicensing, if you are relicensing

• silent.properties.uninstall, if you are removing Alliance Access.

Note The directory you choose must also contain the appropriate licence file (beforelaunching the installation or upgrade).

4. Edit the file to incorporate the required information. The file contains information aboutwhich parameters are required.

For more information, see "Response File Parameters" on page 87.

5. Obfuscate or encrypt the system, Left and Right initialisation passwords or any other databy using the obfuscation tool provided on the Alliance Access product DVD.

For more information, see "Protect the Passwords in the Response File" on page 22.

Preparation

31 December 2010 21

6. Save the file.

If you intend to perform a non-root installation or upgrade, then save the file so that it canbe read by the user account that performs the non-root installation or upgrade.

2.9 Protect the Passwords in the Response FilePrinciple

Silent installation or upgrade operations require that the system account password and Left andRight Initialisation passwords are present in the response file.

In the response file, the passwords or any other data can be specified in clear text, obfuscated,or encrypted (which is the recommended option).

A tool is provided on the Alliance Access product DVD to obfuscate or encrypt passwords orany other data.

Run the obfuscation tool

1. On the Alliance Access product DVD, navigate to the AIX/installer directory.

2. Run the obfuscator tool, using the -key option if you want to encrypt a password.

If you use the -key option, you will be prompted to enter the key to be used. The same keymust be provided later to run the installation routine.

The key to be used must meet certain criteria:

• The length of the key must be in the range of 8 - 20 characters.

• The key must contain at least one uppercase character, one lowercase character, andone numeral.

• The number of occurrences of the same character must not exceed half the length of thekey.

3. You are prompted to enter the data (password) to be obfuscated or encrypted.

The result is displayed.

4. Copy the resultant data displayed to the appropriate parameter in your response file.

2.10 Prepare for a Hosted Database InstallationIntroduction

With release 7.0, Alliance Access introduces a new installation model where the AllianceAccess database schema is created in an existing Oracle instance instead of in an Oracleinstance created by the Alliance Access installer.

Note You can only use the hosted database option when installing Alliance Access. Youcannot upgrade an existing version of Alliance Access to use this option.

Before launching this type of Alliance Access installation, the database administrator (DBA) onthe customer Oracle instance must check that the prerequisites have been met. This sectionprovides the detail of these database prerequisites.



In this section, the default tablespace names (SAA_DATA, ...) and user names(SAAOWNER, ...) are used. However, these are configurable during the installation.

2.10.1 Important Information

In the context of an Alliance Access database installed in an Oracle instance provided by thecustomer, it is assumed that the customer is responsible for the management of the database.

The following actions fall under the customer's responsibility:

• During the installation of Alliance Access, two database directory objects(SAA_ARCH_BACKUP_DIR and SAA_DB_BACKUP_DIR) are created. These objects arerequired for the generation and restoration of Alliance Access backups of configuration dataand of archives. If several Alliance Access databases are installed on the same Oracleinstance, then these database directory objects must be different per Alliance Accessdatabase. Changing the names of these objects is possible through the Alliance Accessconfiguration screens.

• Creating other objects (such as tables or indexes) in the Alliance Access databaseschema(s) should not be done. These objects may be deleted by Alliance Access (duringinstallation or at run time), or they may prevent the Alliance Access software from workingproperly.

• Installing multiple Alliance Access instances using the same Oracle instance requires thattablespaces, users and directory objects are different between the different Alliance Accessinstances.

• Monitoring the disk space usage of the tablespaces is performed regularly to avoid a crash ofAlliance Access because of unavailable disk space.

• Oracle and its storage infrastructure are configured for protection against media failures, forexample, by disk mirroring and/or RMAN backups and/or Data Guard.

• Before starting the Alliance Access servers, the Oracle instance and listener must be started.This is also required for certain off-line Alliance Access tools, for example saa_systemdbbackup.

• Before stopping the Oracle instance and the listener, the Alliance Access servers must bestopped.

• Network connectivity between the Alliance Access host and the Oracle host is reliable.

• After removing Alliance Access, the tablespaces, schemas, and directories listed in thisdocument can be removed from the Oracle instance.

• The Alliance Access backup/restore functionality comprises the backup of archives ofmessages and events, and backup of Alliance Access configuration data. This functionalityrequires a shared file system that is readable and writable from the Oracle system and theAlliance Access system with their owner credentials (for example, an NFS mount). Theshared directory can be set using Alliance Access configuration screens.

• For the Oracle system, the following mount options are required:

rw,bg,hard,rsize=32768,wsize=32768,vers=3,cio,intr,timeo=600,proto=tcpThere are no specific mount option requirements for the Alliance Access system.

Preparation

31 December 2010 23

• User accounts, group memberships, and permissions must be configured to enable thefollowing:

– for the backup, Alliance Access creates the backup directory. Oracle writes one or moredatapump files and a log file. Alliance Access reads the datapump file(s) and writes aninformation file.

– for the restore, Alliance Access reads the information file and the datapump files from thebackup directory. Oracle reads one or more datapump files, and writes a log file.

2.10.2 Prerequisites For a Hosted Database

System requirements

You must have licence option 13:HOSTED DATABASE.

The software version of the Oracle instance wherein the Alliance Access database will becreated must meet the following Oracle version requirements:

• Type of Oracle: Standard/Enterprise

• Version of Oracle: see the Release Letter

The following Oracle configuration parameters must be set as follows:

• processes = 250

• sessions = 500

• sga_target = 1200M

• pga_aggregate_target = 300M

• database character set = US7ASCII

Depending on the Oracle version, the sga_target and pga_aggregate_target values can also beset through the memory_target parameter, by setting: memory_target = 1500M.

2.10.3 Database User Accounts

Accounts required

Before launching the Alliance Access software installer to install Alliance Access within anOracle instance provided by the customer, the customer must have performed the followingprerequisites:

• The following three Oracle database users (and their associated passwords) are created andavailable for use. These are logical names that will be mapped to physical names atinstallation time:

– SAAOWNER

A database schema owner user: this Oracle user will be used to create the databaseschema (tables, views, indexes, stored procedures, functions, scheduled jobs, ...) ofAlliance Access.

– SAATEMP

A database temporary schema owner user: this Oracle user will be used to managetemporary data when required by Alliance Access (for example, during restore of messagebackups).



– SAAUSER

A database run time user: this Oracle user will be used by Alliance Access to connect tothe installed Alliance Access database whenever Alliance Access requires access to thedatabase.

Note Each of these users must also be granted the necessary privileges.

User Account Attribute Value and Comment

SAAOWNER Account status Once the installation of Alliance Access issuccessful, the account status can be set toLOCKed (this is optional).

Authentication method The SAAOWNER must be identified by apassword when connecting to the AllianceAccess database. This setting is mandatory.

Default tablespace SAA_DATA is the default tablespace whereSAAOWNER will create database objects. Thissetting is optional.

SAATEMP Must have the same attributes as SAAOWNER.

SAAUSER Account status UNLOCKed.

Authentication method The SAAUSER must be identified by apassword when connecting to the AllianceAccess database. This setting is mandatory.

Default tablespace SAA_DATA is the default tablespace whereSAAUSER will create database objects. Thissetting is optional.

2.10.4 Tablespaces

Tablespaces required

The necessary tablespaces and associated datafiles must be created. These are:

• SAA_DATA: contains the Alliance Access configuration data.

• SAA_FILE: contains the payloads associated to FileAct messages.

• SAA_TEMP: contains temporary data (for example, the restored 6.x archives for which CRCis to be re-calculated before import in the SAA_MESG).

• SAA_MESG: contains the messages managed by Alliance Access.

• SAA_JRNL: contains the Alliance Access events.

2.10.5 System and Object Privileges

The three database user accounts required by Alliance Access must have database system andobject privileges as described in the following tables.

Preparation

31 December 2010 25

SAAOWNER and SAATEMP system privileges

System privilege Comment Usage scope

CREATE ANYDIRECTORY

Used to create directories during backup and restore ofdata.

Run time.

CREATE JOB Used to create jobs during the Alliance Access databaseconfiguration.

Installation orpatch.

CREATEPROCEDURE

Used to create stored procedures, functions and packagesduring the Alliance Access database configuration.


CREATESEQUENCE

Used to create sequences during the Alliance Accessdatabase configuration.


CREATE SESSION Used to connect to Oracle during the Alliance Accessdatabase configuration.


CREATE SYNONYM Used for synonym creation. Installation orpatch.

CREATE TABLE Used to create tables during the Alliance Access databaseconfiguration.

Also used at run time by stored procedures to create dailytables, search tables.


Run time.

CREATE TRIGGER Used to create triggers during the Alliance Accessdatabase configuration.

Also used at run time by stored procedures to createtriggers for daily tables.


Run time.

CREATE VIEW Used to create views during the Alliance Access databaseconfiguration.


UNLIMITEDTABLESPACE

Used for backup and restore operations. Run time.

SAAOWNER and SAATEMP object privileges

Object privilege Comment Usage scope

EXECUTE onDBMS_LOB

Perform certain operations on LOBs. Run time.

EXECUTE onDBMS_LOCK

Used for concurrency control of certain database objects. Run time.

EXECUTE onDBMS_FLASHBACK

Used during backup. Run time.

SELECT onDBA_LOBS

Used for table and tablespace size calculations during thebackup/restore operations.

Run time.

SELECT onDBA_SEGMENTS


Run time.

SELECT onDBA_FREE_SPACE


Run time.

SELECT onDBA_DATA_FILES


Run time.

SELECT onDBA_TABLESPACES


Run time.




SELECT onDBA_INDEXES


Run time.

SELECT on V_$DATABASE

Used to determine OS in stored procedures. Run time.

SELECT onDBA_DATAPUMP_JOBS

Used for backup and restore operations. Run time.

SAAUSER system privileges


ALTER SESSION Used to set session tracing, current_schema. Run time.

CREATE SESSION Used to connect to Oracle. Run time.

CREATE SYNONYM Used for synonym creation. Installation orpatch.

CREATE ANYDIRECTORY

Used to create directories during backup and restore ofdata.

Run time.

2.11 Prepare a Backup File for UpgradeIntroduction

You can use backed up configuration data from a compatible earlier release of Alliance Accessor Alliance RMA for subsequent use on an Alliance Access 7.0 host machine.

This feature can only be used between two systems of the same operating system (only fromAIX to AIX).

Note The backup file does not include:

• the usrdata directory and content therein. The data contained in this directory isstill available on the host where the backup was generated, even if the AllianceAccess software is uninstalled. The data can safely be copied manually to thenew host.

• operational data (messages, events, audit cards).

Compliance Report file

A report file, check_db.info, is generated during the preparation of the backup file and stored inthe $ALLIANCE/mig directory.

This report can be looked at to identify any pre-requisites related to routing rules, routingkeywords or message partners that would not be met.

This means that even if the preparation task is not performed, you can find out what needs to beupdated or removed in advance.

Preparation

31 December 2010 27

Compatibility

Regardless of installed patches, the backup files of the following releases of Alliance Access arecompatible with Alliance Access 7.0:

• Alliance Access 6.0


You can also upgrade to Alliance Access 7.0 from the following releases of Alliance RMA:

• Alliance RMA 6.0


2.11.1 Before You Create a Backup File for Upgrade

Overview

Before you create a backup file to prepare for an installation from backup, ensure that youperform the following actions:

1. From the SWIFT Interface application, Quit and Logout all logical terminals and switch themall to Manual mode. For details, see the Daily Operations Guide.

2. From the SWIFT Support application, ensure that all logical terminals in use are assignedthe latest Message Syntax Table. For details, see the System Management Guide.

3. From the Application Interface application, select all the message partners and disablethem.

4. Export RMA authorisations. For details, see "Exporting Authorisations Manually" in theRelationship Management Application User Guide.

Note During the upgrade, RMA authorisations are automatically migrated to the newrelease. This step is only to provide you with a backup in case of problemswith RMA migration during the upgrade process.

5. Ensure that all message templates have the latest message syntax table assigned andexport them all. For details, see "Exporting Templates" in the Daily Operations Guide.

Note During the upgrade, templates are automatically migrated to the new release.This step is only to provide you with a backup in case of problems withtemplate migration during the upgrade.

If, after the upgrade, message templates cannot be opened or modifiedbecause they are assigned to an earlier message syntax table, then you canexport the message templates and assign the latest message syntax table tothem during the import.

6. Follow the instructions about preparing for upgrade in the Release Letter.



2.11.2 Create a Backup File for Upgrade

Prerequisites

1. Ensure that Alliance Access or Alliance RMA is not running.

2. Verify that the server for which a backup will be taken is not running, and that the SystemAdministration window is not open.

3. If you are running Alliance Access 6.3.x or Alliance RMA 6.3.x, and database recovery isactivated, then deactivate it before starting the upgrade. For more information, see"Deactivate the Database Recovery Mode" on page 180.

Procedure

1. Log on with sufficient privileges.

2. Stop the Alliance Access or Alliance RMA on the host machine.

3. Insert the Alliance Access installation DVD.

4. Prepare your system:

a. Open a Korn shell.

b. Mount the DVD.

c. If you are working remotely, then export the display to your local machine:

export DISPLAY=<IPaddressComputer>:0.0where <IPaddressComputer> must be replaced by the IP address for the computerwhere the installation windows will be displayed.

5. Navigate to the folder that contains the Alliance Access installation program.

AIX/installer

6. Double-click the saa-install.exe file.

7. The installation program inspects your system and the Welcome to the Alliance AccessInstaller window appears. This window might appear in the background, so you may haveto close or minimise other windows to find it.

If the installation program detects a compatible previous release of Alliance Access orAlliance RMA on your host system, then the Prepare Backup File for Upgrade option isthe only one available.

8. Click Next .

The Backup File Location window appears.

9. If you do not agree with the proposed location where the backup file must be created, theneither type the full physical path or click Browse to provide the location. You cannot providea symbolic link as a valid path.

If the directory specified already contains a backup file, then a warning message appearsasking you to provide a suitable directory.

10. Click Next .

A message appears that prompts you to close any open Alliance applications (for example,the Alliance Command Prompt) before you proceed with the backup.

Preparation

31 December 2010 29

Click OK in the Warning box when all Alliance applications are closed.

11. Click Next to start the backup.

A message appears to remind you that messages, events, and audit cards will remainpresent in the database, and that the backup file does not include these. Completedmessages, events, and audit cards must be archived and backed up before they can berestored to the other system.

Click OK to continue.

12. Click Finish to complete the backup operation.

The following files are created as a result:

File created Details

backup file A file named SAA6<x>to7.zip (for Access) or SAR6<x>to7.zip (for RMA)where <x> is replaced with 0 or 3, as corresponds to the release that wasbacked up.

installation.log Contains details about the backup procedure. This file is present in theinstallation directory of Alliance Access or Alliance RMA.



3 InstallationOverview

This section describes how to install Alliance Access 7.0.

3.1 Before You Install

3.1.1 Prerequisites for the Installation

Checklist

Before installing Alliance Access, ensure that:

• the IBM system hardware has been installed and tested.

• you system has been prepared according to the instructions in the section "Preparation" onpage 13.

• for an interactive installation:

– both Alliance Access Security Officers (or their deputies) are present

– X-terminals have been installed and tested

• for a silent installation, you have prepared the following files:

– a licence file. See "Prepare the Licence File" on page 20.

– a response file. See "Prepare the Response File (for Silent Installation, Upgrade,Relicensing, or Removal)" on page 21.

• the Alliance Access Administrator account has been created on the system.

Additional information

Before you begin the installation, you also need the following:

• access to the root or Alliance Access Administrator account of your system (this may requirethe presence of your local AIX system administrator, or the issuing of a temporary passwordfor the root account).

• details of the directories in which you want to store the Alliance Release Tree (that is,Software).

If, during installation, problems occur and you cannot solve them easily, abort the installationand perform the following:

• Remove the release DVD and store it in a safe place.

• Log off.

• Seek advice about the problem.

• Restart the complete installation process.

Installation

31 December 2010 31

3.1.2 Mounting the DVD Drive

Procedure

1. A directory mount point must first be made for the DVD and then the DVD must bemounted. Log on as 'root' and create a directory, for example MNT:

mkdir /MNT

2. Mount the DVD:

mount -v cdrfs -r /dev/cd0 /MNT

3. Insert the Alliance Access release DVD.

3.2 Interactive Installation

3.2.1 Launching the Interactive Installation From DVD

Overview

All commands in this guide assume that you are using the Korn shell (not the Bourne shell).

Before starting an installation, ensure that the machine is reserved for your use for the durationof the installation.

To launch the installation program:

1. Check that you are using the Korn shell by looking at the entry for root (or Alliance Accessowner account) in the /etc/passwd file. To invoke the Korn shell, log on as root (or AllianceAccess owner account) and type:

ksh

2. To start the installation process, log on as root (su root does not work) or the AllianceAccess owner account.

3. If you are working remotely, then export the display to your local machine by typing:


4. If the disk space requirements for the temporary files for the install program cannot besatisfied, then you can use the installer option -tempdir <TMPDIR> to specify analternate temporary directory.


6. Navigate to the following directory in the folder for Alliance Access:

/AIX/installer

7. Start the installation process by typing:

./saa-installTo record the installation details for future use, run the saa-install command with the -record option. See "Record input parameters" on page 86 for more information.



8. To proceed with the installation, follow the steps in "Install Alliance Access Interactively" onpage 34.

During installation, you specify the UNIX account name used by the Alliance administrator forthis installed instance of Alliance Access.

Throughout the installation, the install program periodically accesses the install drive to copy,install, and license the various components of Alliance Access. It is therefore important that youleave the Alliance Access release DVD in its respective drive until the installation is complete.

To launch the program from a remote DVD drive

1. Set the permissions on the remote machine. You have to edit the following files:

~/.rhosts/etc/exports

2. Insert the DVD on the remote machine.

3. Mount the DVD on the remote machine.

4. Share/export the mount point of the DVD on the remote machine as an NFS resource.

5. Create a mount point on the local machine.

6. Mount the remote directory on the local machine.

7. Finally, access the DVD from the local machine using the local name <mount_point> for theremote directory.


/AIX/installer

9. Type the command:


3.2.2 Launching the Interactive Installation From a Directory

Introduction

All commands in this guide assume that you are using the Korn shell (NOT the Bourne shell).To check this, see the entry for root (or Alliance Access owner account) in the /etc/passwd file.

To invoke the Korn shell, log on as root (or Alliance Access owner account) and type:

ksh

To launch the installation program:

1. Log on as root (or Alliance Access owner account).



Installation

31 December 2010 33


4. Copy the DVD contents to an install directory on hard disk by typing:

mkdir <install directory>cd <install directory>cp -r /MNT/* .

5. Unmount the DVD:

cd ~umount /MNT

6. Navigate to the following directory in the created install directory:

/AIX/installer

7. Type the following command:


8. To proceed with an interactive installation, follow the steps in "Install Alliance AccessInteractively" on page 34.

During installation, you specify the UNIX account name used by the Alliance administrator forthis installed instance of Alliance Access.

Throughout the installation, the install program periodically accesses the install directory tocopy, install, and license the various components of Alliance Access.

To launch the installation program a remote directory:

1. Copy the DVD contents to a directory on the remote machine.

2. Share/export this file system on the remote machine as an NFS resource.

3. Mount the directory on the local machine.

4. Access the directory from the local machine using the local name <mount_point> for theremote directory.

For example:

cd /<mountpoint>/AIX/installer

5. Type the following command:


3.2.3 Install Alliance Access Interactively

Installation event log

Events that occur during installation are recorded in the installation.log file, found in theAlliance Access installation path or in the default temp directory if the installation directory has



not yet been entered. In case of installation failure, please check this file for the reasons of thefailure.

To install Alliance Access interactively:

1. When the installation program starts, it unpacks the files required.

Once all the files are unpacked, the Welcome window is displayed:

Note The options available vary according to your current installation (if any).

2. Select Install Alliance Access 7.0, and continue with step 3.

If you are installing from a backup file, then select Install Alliance Access 7.0 fromPrepared Backup File. For more information, see "Prepare a Backup File for Upgrade" onpage 27.

3. Click Next .

The End-user Licence window appears.

4. Accept the terms, and click Next .

If you are installing from a backup file, then the Backup File Location window appears.Browse for the location of your backup file.

If you are installing for the first time, then the Installation Location window appears.

Installation

31 December 2010 35

5. Specify the directory name and path, in which to install Alliance Access.

You can either accept the default path, or click Browse to select another path.

If you select another path, then note the following conventions:

• Do not use spaces in the path name.

• Do not specify a symbolic link. You must type the full physical path.

• Use a directory that is dedicated to this product.

Warning Do not create a new directory using the Browse > new-directory option.

To create new directory at this point, type the path and name of the newdirectory in Directory Name field. For more information about settingpermissions on the installation directory, see "Prepare for Non-root Installation,Upgrade, Backup, or Removal" on page 19.

6. In the Owner field, specify the user that will own the installation files.

The owner cannot be root because the installed files are restricted to owner account.

7. In the Database field, select whether you want to install Alliance Access with the Oracledatabase provided (Embedded) or on your own Oracle database (Hosted).

If you select Hosted, the following fields must be completed:

• Host

Enter the host name or IP address of the machine where the Oracle instance to be usedis installed.

The host name, if entered, is not case-sensitive, and must meet the following criteria:

– maximum of 31 characters

– can only contain the characters 'a-z', 'A-Z', '.', and '-'

• Port

Enter the port number to be used by Alliance Access to connect to the Oracle instance.



• Service

Enter the service ID identifying the Oracle instance.

8. Click Next .

9. The checkhost command is run to validate whether your system meets the minimumoperating system requirements. The test results are saved in the software installationdirectory, in the file:

installation_systemcheck_yymmdd_hhmmss.html

where yymmdd and hhmmss are the date and time of the installation.

If your system meets all the requirements, then the Packages Configuration windowappears.

This window is used to license the packages and features that your institution haspurchased from SWIFT. The pre-selected packages are part of the base licence and cannotbe deselected.

Note If your system does not meet all the requirements, then the SystemConfiguration Test Results window displays information about the problemsthat were detected.

The Result column specifies the severity of a reported problem:

• Problems reported as Warning do not prevent you from continuing theinstallation, but you may encounter unexpected results.

• Problems reported as Blocking prevent you from continuing theinstallation. Fix the problem and start the installation again.

10. Decide how you want to provide licence-related data.

Manually: proceed to step 11.

Installation

31 December 2010 37

From a licence file: click Load from File and browse to the location of the licence file. Thenclick Next and proceed to step 16.

11. Select the licensed components, using the items listed in the Packages section of yourlicensing agreement. Then click Next .

Note You may want to license additional component packages or 'disable' selectedcomponent packages after the installation is finished. To do this, you canrelicense Alliance Access using a new licensing agreement. You do not haveto reinstall. For more information, see "Relicensing" on page 75.

12. The Servers Configuration window appears.

13. Select the licensed components, using the items listed in the Servers section of yourlicensing agreement. Then click Next .

The Licensed Destinations Configuration window appears.

14. In this window, type:

• the 8-character live destination(s) listed in the Licensed Destinations section of yourlicensing agreement.

• the 8-character training destinations. The eighth character is a 0 (zero), to denote testand training. Although the test and training destination does not appear on your licensingagreement, you must enter it if you want to use it.

Each destination must be on a separate line. Once you have typed all your destinations,click Next .

The Message Types Configuration window appears.

15. In this window, type the message types listed in the Message Types section of yourlicensing agreement.

Each message type must be on a separate line. Once you have typed all your messagetypes, click Next .



The Initialisation Password Configuration window appears.

16. Enter the initialisation passwords as follows:

• The Security Officer who received the INITIALISATION PASSWORD provided in Part 1of 2 of the licensing agreement must type this password in the First initialisationpassword field.

• The Security Officer who received the INITIALISATION PASSWORD provided in Part 2of 2 of the licensing agreement must type this password in the Second initialisationpassword field.

Note Do not confuse the Initialisation Passwords with the Master Passwords. TheMaster Passwords are used by the two Security Officers when they first signon to Alliance Access.

17. Click Next .

If the password verification fails, then an error message appears. Click OK and enter thecorrect input.

Installation

31 December 2010 39

18. The Instance Configuration window appears.

Field Description

Host Name The host name of the Alliance Access system.

IP Address The IP address of the Alliance Access system.

Instance Name The name of the Alliance Access instance on the Alliance Access system.

The instance name can be up to 15 alphanumerical characters, and muststart with an alphabetical character. It can contain the "_" character.

If several instances are installed, each one must have a unique instancename.

Instance Comment A description of the instance.

It can contain alphanumeric characters and spaces, and must not exceed30 characters.

19. If necessary, change the default values in the IP Address, Instance Name, and InstanceComment fields.

20. Click Next .

If you have selected the embedded database option, the Installation Summary windowappears. Go to step 24.

If you have selected the hosted database option, the Database User Names andPasswords window appears. Go to step 21.

21. Enter the names and passwords of the Oracle database users required (as set up duringthe preparation phase as described in "Database User Accounts" on page 24).

Schema Owner and password: this is the user that will be used by the Alliance Accesssoftware installer to create and configure the Alliance Access database schema.

User Name and password: this is the user that will be used by Alliance Access to connectto the installed Alliance Access database.



Temp Schema Owner and password: this is the user that will be used by the AllianceAccess software when temporary data are to be managed (for example during restore ofbackups).

Click Next .

Note These user names and passwords cannot exceed 30 characters and mustcomply with the Oracle user name and password specifications.

22. Enter the names of the tablespaces that Alliance Access should use (as set up during thepreparation phase as described in "Tablespaces" on page 25).

In the Data Tablespace field, enter the name of the tablespace containing the AllianceAccess configuration data (SAA_DATA).

In the File Tablespace field, enter the name of the tablespace containing the AllianceAccess FileAct payloads (SAA_FILE).

In the Event Tablespace field, enter the name of the tablespace containing the AllianceAccess events (SAA_JRNL).

In the Message Tablespace field, enter the name of the tablespace containing the AllianceAccess messages (SAA_MESG).

In the Temporary Tablespace field, enter the name of the tablespace used by AllianceAccess when required to manage temporary data (SAA_TEMP).

23. Click Next .

The Installation Summary window appears.

24. Check that the details displayed are correct, and if so, click Install . Once you click Install , itis not possible to abort the software installation. If the details are not correct, click Previous

to return to the previous screen(s) and make your corrections.

The software installation begins. You can monitor the progress of the installation throughvarious windows, for instance while Alliance Access copies files.

At the end of the software installation, the Installation Complete window appears,confirming a successful installation.

The window displays information about the port configuration. For more information aboutport configuration, see "TCP Configuration for the Alliance Access Server" on page 239.

The window also reminds you to perform SWIFTNet configuration activities.

25. Click Finish to complete the installation.

Installation

31 December 2010 41

Note Once the installation has completed successfully, if you have installed fromDVD, remove the DVD as follows:

1. Log on as root (or Alliance Access owner account) and unmount the DVDby typing:

cd ~umount /MNTIf this command returns the error Device is busy, this means thatthere is some process still using the DVD software. This is probably theSystem Administration application itself. Quit the System Administrationwindow and run the following in the controlling x-term:

cd /Try again to unmount the DVD.

2. Log off from the root (or Alliance Access owner account) account.

26. Perform the post-installation steps described in the Release Letter. Then follow theinstructions in "Post-Installation Checklist" on page 46.

27. Following initial software installation, when the servers are first started, one alarmmessage, per live destination, is displayed, similar to:

********************* ALARM ********************SUBSET DEFINITION: 'XXXX': INITIALISED TO SYSTEM DEFAULTSuch alarms, which are also logged in the Event Journal as 'severe' events, result from thefact that the licensed destinations do not yet have delivery subsets defined for them inAlliance Access. These alarms are normal.

3.3 Silent Installation

3.3.1 Install Alliance Access Silently From DVD

Overview

All commands in this guide assume that you are using the Korn shell (not the Bourne shell).

Before starting an installation, ensure that the machine is reserved for your use for the durationof the installation.

To install Alliance Access silently from DVD

1. Check that you are using the Korn shell by looking at the entry for root (or Alliance Accessowner account) in the /etc/passwd file. To invoke the Korn shell, log on as root (or AllianceAccess owner account) and type:

ksh

2. To start the installation process, log on as root (su root does not work).






5. A directory mount point must first be made for the DVD and then the DVD must bemounted. Log on as 'root' (or Alliance Access owner account) and create a directory, forexample MNT:

mkdir /MNT

6. Mount the DVD:




/AIX/installer

9. Start the installation process by typing:

./saa-install -silent <response file> [-key <value>]Where:

• <response file> identifies the path to and name of the properties file to be used.

For example:

/tmp/alliance/silent.properties.install.saa.embedded

Note The licence file must also be present in the same directory.

• -key <value> specifies the key to be used if the password(s) in the response file havebeen encrypted.

Important Throughout the installation, the install program periodically accesses the installdrive to copy, install, and license the various components of Alliance Access. Itis therefore important that you leave the Alliance Access release DVD in itsrespective drive until the installation is complete.

10. Perform the post-installation steps described in the Release Letter. Then follow theinstructions in "Next Steps" on page 46.

Installing from a remote DVD drive





4. Share/export the mount point of the DVD on the remote machine as an NFS resource.

5. Create a mount point on the local machine.


Installation

31 December 2010 43

7. Finally, access the DVD from the local machine using the local name <mount_point> for theremote directory.


/AIX/installer

9. Type:



For example:




Viewing the silent installation progress or result

The installation log file is updated during a silent installation. You can view the log to see theprogress of the silent installation, or the result if the silent installation operation has ended.

3.3.2 Install Alliance Access Silently From a Directory

Introduction

All commands in this guide assume that you are using the Korn shell (NOT the Bourne shell).To check this, see the entry for root (or Alliance Access owner account) in the /etc/passwd file.

To invoke the Korn shell, log on as root (or Alliance Access owner account) and type:

ksh

To start the installation process:

1. Log on as root (or Alliance Access owner account).




4. A directory mount point must first be made for the DVD and then the DVD must bemounted.

Log on as 'root' (or Alliance Access owner account) and create a directory, for exampleMNT:

mkdir /MNT



5. Mount the DVD:


6. Copy the DVD contents to an install directory on hard disk by typing:


7. Unmount the DVD:

cd ~umount /MNT


/AIX/installer

9. Type:



For example:



Important Throughout the installation, the install program periodically accesses the installdirectory to copy, install, and license the various components of AllianceAccess.


To install from a remote directory:

1. Copy the DVD contents to a directory on the remote machine.


3. Mount the directory on the local machine.

4. Access the directory from the local machine using the local name <mount_point> for theremote directory.

For example:


5. Type:



Installation

31 December 2010 45

For example:




Viewing the silent installation progress or result

The installation log file is updated during a silent installation. You can view the log to see theprogress of the silent installation, or the result if the silent installation operation has ended.

3.4 Next StepsHow to use this section

After installing Alliance Access, you must perform a number of software tasks before it is readyfor daily use. To complete these tasks, you must have other SWIFT documentation available.The best way to proceed is to read carefully what you have to do for each task. If you are notsure what is required of you, then go to the other SWIFT documentation that is referred to in thetask. Also, remember that there is an online Help system installed with Alliance Access. If, aftercareful reading of all the documentation, you are still not sure how to proceed, then contactSupport.

You must have the following documentation available:

• System Management Guide

• FIN Initial Services Forms

3.4.1 Post-Installation Checklist

Authentication of users

If operators will use one-time passwords, or if you want to use LDAP repositories to authenticateusers, then make sure that an authentication server has been provided and deployed. For moreinformation about one-time passwords and authentication servers, see the Security Guide andthe System Management Guide.

Post-installation checklist

Use the following checklist to configure the installed software for live users:


If you are going to use Alliance Web Platform, installit and load the packages for Alliance Access

Alliance Administrator Web Platform documentation

Log on to Alliance Access using the administratoraccount. Enter a new password when prompted.

This must be done from the console to avoid any$DISPLAY problems.

Alliance Administrator Security Guide

Installation andAdministration Guide

Start the Alliance Access servers Alliance Administrator Installation andAdministration Guide




Wait for servers to be ready. Do not quit the SystemAdministration application.

Alliance Administrator Installation andAdministration Guide

From Alliance Workstation, sign on as left securityofficer using Part 1 of the Master Password.

Update left security officer password.

Left security officer Security Guide

System Management Guide

From Alliance Workstation, sign on as right securityofficer using Part 2 of the Master Password.

Update right security officer password.

Do not sign off

Right security officer Security Guide


Create customised operator profiles (or use thedefaults provided).

Right security officer Security Guide

Create new operator(s) (with "Supervisor" or"SuperKey" privileges). Assign SWIFTNet Supportapplication permissions to other operators if needed.

Right security officer System Management Guide

Approve new operator(s). Right security officer System Management Guide

Display RIGHT part of system password(s) for newoperator(s).

Right security officer System Management Guide

Sign on to Alliance Access as left security officerusing updated password.

Left security officer System Management Guide

Approve operator(s). Left security officer System Management Guide

Display LEFT part of system password(s) for newoperator(s).

Left security officer System Management Guide

Sign on to Alliance Access as an operator, using thesystem password received from left security officer/right security officer.

New operator

(with "Supervisor" or"SuperKey" privileges)


Update operator password when prompted. New operator System Management Guide

Create units (if required). New operator System Management Guide

Assign units to operators (if required). Left security officer / Rightsecurity officer


Set up your security parameters. Alliance Administrator Security Guide

In the System Management application, define andselect the SWIFT destination for alarm generatedmessages (MT 999).

New operator System Management Guide

Not required for standalone Alliance Access:

In the System Management application, start theSNIS, used for InterAct and FileAct (including RMA(Relationship Management application))


Sign off. New operator Daily Operations Guide

Restart Alliance Access in Housekeeping mode. New operator System Management Guide

When servers are ready, sign on using updatedpassword.

New operator Daily Operations Guide

Install and activate Value Added Service ParameterFiles (if required).


Install the Alliance Bank File from the CorrespondentInformation File application (if required).


Installation

31 December 2010 47


Install any MX Standards which are to be used (ifrequired).

New operator "Installing MX Standards" onpage 50


To prepare your Destinations, install the MessageSyntax Tables (MSTVs) from the SWIFT Supportapplication.


Still in Housekeeping mode, define the LTs (LogicalTerminals) and assign each to an MST.


Restart Alliance Access in Operational mode New operator System Management Guide

Create an internal correspondent for your Test &Training destination. Open the CorrespondentInformation File application and in the SearchCriteria window, click Cancel .


From the Correspondent menu, select New, and inthe Institution field, enter your BIC-11 Test &Training code, for example ALIBBEB0XXX. Add thedetails fields, if required.


Click the Other tab and change the CorrespondentDefinition to Internal. Click the IntegratedApplication tab. In the Preferred Networks list,transfer "SWIFT" from Available to Selected. Fromthe Correspondent menu, select Add.


Set up the RPC and SSL Security between AllianceAccess and Alliance Workstation (if required).

Alliance Administrator See "RPC and SSL Securityfor Alliance Workstation" onpage 52.

Not required for stand-alone Alliance Access:

Define a SWIFTNet connection and assign a logicalterminal to it, and then send and receive a testmessage.

To test the connection, you need the details of theAlliance Gateway instances that you plan to use.

Part B, "Configuring forSWIFTNet" on page 95

Define new message partners (if required) New operator System Management Guide


In the System Management application, start SNIS,used for InterAct and FileAct activities (including RMA(Relationship Management application))



Check SWIFT communications

Any operator System Management Guide

Update delivery subsets if they are different from thedefaults (System, Urgent, Normal):

• generate MT 035 in Message Creation application

• Login/Select (I/O without delivery subsetsselected) the logical terminal used to send the MT035

• wait for MT 055 response (handled automaticallyby Alliance Access). Subsets are updated.

• perform QUIT for this logical terminal

Any operator System Management Guide




Redefine delivery subsets, if the defaults areinsufficient:

Any operator

• redefine the subsets by using the SWIFT Interfaceapplication


• Login with this logical terminal to send themessage

Daily Operations Guide

If you have installed from a backup file and theDatabase Recovery option is licensed, you mustmanually activate database recovery by using thesaa_dbrecovery tool.

Alliance Administrator "Activate the DatabaseRecovery Mode" onpage 179


If you plan to test the connection with SWIFT, thenensure that the SWIFTNet connection with theAlliance Gateway is operational.

Alliance Administrator Part B, "Configuring forSWIFTNet" on page 95

Install and configure printers (if required) AIX System Administrator IBM manuals


3.4.2 Additional Tasks after a Non-root Installation

Procedure

After the installation of Alliance Access by a UNIX account without root privileges, the followingtasks must be performed with the UNIX root account:

1. Log on as root.

2. Navigate to the installation directory and run the script called saa_rootpostinstall.ksh. Forexample:

<Install_directory>/install/saa_rootpostinstall.kshThe script:

• runs the RPCConfiguration.ksh script which delivers the new version of the files inthe /usr/swa directory.

• adds the new Alliance Access instance in /usr/swa/insts.

• runs the apply_alliance_ports script which configures the Alliance ports in /etc/services.

• runs the MPConnConfig.tcl script which configures the MPConn ports in /etc/services(ports required for the CAS message partners).

• copies the installation registry entry (a file generated in the installation directory duringinstallation) of the product to the central registry location on the system (/var/opt/swift).

• starts the Alliance Access Name Service of the Alliance Access instance with the highestrelease number.

Installation

31 December 2010 49

3.4.3 Installing MX Standards

Description

To allow MX keyword extraction on Alliance Access from messages exchanged over SWIFTNetservice or services to which you subscribed, the corresponding MX standard(s) must beinstalled on Alliance Access and on the Messenger package of Alliance Web Platform. You candownload the appropriate message standards deployment package(s) and accompanying coverletter(s) from the Download Centre on www.swift.com > Support > Download Centre.

Note • Using the Messenger 6.3 package to install a message standards deploymentpackage on Alliance Access 7.0 is not supported.

• Support for System Messages related to SWIFTNet 7.0 requires the installationof the SWIFTNet 7.0 System Messages Deployment Package.

3.4.4 Configuring RMA for Test and Training

Purpose

This procedure provides additional instructions for configuring RMA for FIN Test and Training.

For FIN Test and Training destinations, a licensed live BIC8 that is used to sign all authorisationmessages for FIN Test and Training. You must configure a licensed BIC as the destination forall FIN Test and Training authorisation messages. That BIC is referred to as the Signing BIC forTest and Training.

RMA service for FIN Test and Training

The authorisations for the pilot service and FIN Test and Training are exchanged overswift.rma!p.

To configure RMA for test and training:

1. Define the Signing BIC for Test and Training, as the signing destination of all FIN Test andTraining authorisation messages. The Signing BIC for Test and Training must be the BIC8for which you will create the emission and reception profile.

For more information, see "Defining the Signing BIC for Test and Training Authorisations"on page 51.

2. For FIN Test and Training destinations, define a SWIFTNet Emission profile and aReception profile for each Signing BIC for Test and Training.

For more information, see "Configuring SWIFTNet Emission and Reception Profiles" onpage 107.

3. If necessary, change the operator profiles and assign them to the users that will operateand administer the RMA. You can use or adapt the default operator profiles, RMA_Adminand RMA_Oper, or create profiles for your own use.

For more information about the default operator permissions, see the System ManagementGuide.

For details about default operator profiles, and for instructions on modifying or assigning aprofile to a user, see "Managing Alliance Access Security" in the System ManagementGuide.




4. If you do not want to confirm the authorisations that your correspondent revokes or rejects,then set the Needs Status Confirmation security parameter.

For more information, see "Security Parameters" in the System Management Guide.

Note The confirmation is for information purposes only. The revocation and rejectionof the authorisation always takes effect regardless of whether the action isconfirmed or not.

3.4.5 Configuring RMA for the SWIFTNet Integration Testbed

Purpose

This procedure provides additional instructions for configuring RMA for the SWIFTNetIntegration Testbed.

Perform these instructions on the Alliance Access server, and on each Alliance workstation.

Important Only SWIFT, and its partners and vendors that have a BIC starting with PT, mustperform this procedure.

When to use

Perform this procedure after the Alliance Access software has been installed.

RMA services

When RMA is configured for the SWIFTNet Integration Testbed, authorisations are exchangedover the pilot service, swift.rma!x.

To configure RMA for the SWIFTNet Integration Testbed:

1. In the home directory of the Alliance administrator (all_adm), enter the following command:

vi .swa.$ALLIANCE_INSTANCE.rc

2. Add the following line to the swa.$ALLIANCE_INSTANCE.rc file:

export RMA_SERVICE_NAME=swift.rma!x

3. Save the changes to the file, and quit the vi editor.

To apply the changes to the variable, you must close and re-open the System Administrationwindow.

3.4.6 Defining the Signing BIC for Test and TrainingAuthorisations

Purpose

FIN Test and Training authorisations are exchanged as InterAct messages over theswift.rma!p service over SWIFTNet, and are signed by an Authoriser DN. Therefore, youmust define a licensed live BIC, the Signing BIC for Test and Training, as the signing BIC8destination of all FIN Test and Training authorisation messages.

This procedure provides instructions for setting the value of the Signing BIC for Test andTraining, which must be a BIC8 for which an emission profile and a reception profile is definedfor the service swift.rma!p.

Installation

31 December 2010 51

Users and permissions

You can define the Signing BIC for Test and Training when the Def Signing BIC T&Tfunction is assigned to you in the Relationship Mgmt application.

To define the Own Signing BIC:

1. Launch the Relationship Management application.

2. From the File menu, select Signing BIC for T&T.

The Define Signing BIC for T&T RMA window appears.

3. Select a BIC8 to use for signing Test and Training authorisations.

4. Click OK .

3.4.7 RPC and SSL Security for Alliance Workstation

Introduction

Security between the Alliance Access servers and an Alliance Workstation is defined by the RPCAuthentication configuration parameter. After a new installation, the default setting isProcess Authentication. Security officers can change this setting from the SecurityDefinition application.

If you upgrade to release 7.0, then the upgrade process migrates your current setting for theparameter.

Secure Socket Layer (SSL) is also available for the encryption of the data for thecommunication between the Alliance Access server and an Alliance Workstation. This can be asfollows:

• If Off or Process Authentication is selected, then Alliance Access does not use SSLfor communication with the Alliance Workstation.

• If Data Integrity or Data Confidentiality is selected, then Alliance Accessinitialises its process communication with SSL enabled.

If SSL is enabled, then the Alliance Workstation can also use Server authentication.

Communication with Alliance Web Platform is always initialised with SSL enabled and AllianceAccess server authentication is required.

The following security options are available for process communication with the AllianceWorkstation:

• SSL

• SSL and Server Authentication

• No SSL

If SSL is used, then the ssl.p12 file contains the self-signed certificate and private key. ForAlliance Access, this file is stored in the $ALLIANCE_DB directory. A self-signed certificate isgenerated and imported during installation or migration. The default certificate is contained in



the cacert.crt file in the $ALLIANCE_DB directory. This default certificate expires after 730days. The DN of the default certificate has the value cn=saa_<instance name>. It iscontained in the .cert_dn file also located in the $ALLIANCE_DB directory.

Each installed Alliance Access system has its own self-signed certificate after the installation ofthe software. If your disaster backup system requires the same certificate as your live system,then you must regenerate a certificate on the live system and import this certificate on thedisaster backup system.

If Server Authentication is used, then it is the responsibility of the Alliance Administrator tomaintain the CA Certificate and Private Key. The CA Certificate can be generated or a requestcreated using the swrpc_keytool tool.

The CA Certificate must then be imported into Alliance Access using thesaa_configconnection tool. For details, see "saa_configconnection" on page 226.

3.4.7.1 Certificate Generation for Server Authentication (swrpc_keytool)

Overview

If Server Authentication is used, then it is the responsibility of the Alliance Administrator togenerate a CA Certificate and Private Key. A self-signed Certificate or CA Certificate request iscreated using the swrpc_keytool tool. This tool is located in $ALLIANCE/ BSS/bin/$ARCHand is run from the command line.

To generate a self-signed certificate or certificate request:

1. Log on as Alliance Administrator (all_adm).

2. Open an X-term from the OS Configuration menu in the System Administration window.

3. Move to the directory containing swrpc_keytool:

cd $ALLIANCE/BSS/bin/$ARCH

4. Run swrpc_keytool from the command prompt:

./swrpc_keytool

5. Follow the instructions displayed to generate either a "self-signed certificate" or a certificaterequest.

a Do you want: 1: aself-signedcertificate

If you select 1, then a self-signed certificate is generated,which is signed with its corresponding private key. In thiscase the CA certificate and the certificate itself are identical.The subject and issuer of a self-signed certificate are thesame.

2: a certificaterequest [default, 1]:

If you select 2 to generate a certificate request, then a PKCS-10 file (Request for Certificate), is generated. You mustpresent this file to a CA (Certificate Authority) to receive acertificate. In this case, the subject and issuer of thecertificate are different. The subject is the DN you entered inthe certificate request, and the issuer is the DN of the CA. Touse server authentication in this case, you must receive boththe certificate and the CA certificate.

b File name for the newkey:

Enter the path and file name for the private key. If you enteronly the file name by default, then the file is created in thecurrent directory.

c Enter a password ofyour choice:

The key is password-protected. Select a password thatcomplies with your institution's password policy and thefollowing rules.

Installation

31 December 2010 53

The password must have:

• min. 8 and max. 30 alphanumeric characters

• at least 1 uppercase, 1 lowercase, and 1 number

Repeating consecutive characters may not exceed half thepassword: and may not be equal to the protected file name.

d Re-enter the passwordfor verification:

Re-enter the password for verification: The new key is nowgenerated. If you selected option 2 in step a, then skip to stepg.

e File name for thecertificate:

Enter the file name for your certificate. If the file exists, thenyou are prompted to overwrite the file. If the file does notexist, then skip to step i.

f Overwrite existingfile? [default, n]:

Enter yes (y) to overwrite an existing file: skip to step i, orenter no (n) to return to step e.

g File name for thecertificate request:

Enter the file name for your certificate request. If the fileexists then you are prompted to overwrite it. If not, skip tostep i.

h Overwrite existingfile? [default, n]:

Enter yes (y) to overwrite an existing file: skip to step i, orenter no (n) to return to step g.

i Enter thedistinguished name(DN) to be included inthe certificate:This DN is needed ifyou want to configureauthentication.

This DN can contain the following attributes:

• C or country<para>

• ST for state or province</para>

• L or location name</para>

• O for organisation name

• OU for organisational unit

• CN for common name

• EMAIL for the e-mail address

Example: CN=SAA1,OU=department1,O=institution1.

Enter the DN. A check is then performed on the DN.

For a certificate request, this is the last step and now the toolterminates.

j Number of days yourcertificate is valid[default, 30]:

Enter the number of days the certificate can be used. Bydefault it is 30, the maximum value is 3565.

The self-signed Certificate or CA Certificate request is now generated.

3.4.7.2 Importing Certificates

Description

The new Certificate and Private Key must then be imported into Alliance Access using thesaa_configconnection tool. For details, see "saa_configconnection" on page 226.



Warning Applying this procedure requires the new certificate to be distributed to the Allianceworkstations configured to use Server Authentication and to Alliance Web Platform.A restart of the Alliance Access server after running the saa_configconnectiontool activates the changes on the server. Clients using Server Authentication (forexample, Alliance Workstation or Alliance Web Platform) must use the oldcertificate until the server restart and the new certificate after the server restart.

3.4.7.3 Certificate Expiry Management

Description

Before an Alliance Access certificate expires, the user must generate a replacement certificate.The generation of a new certificate on Alliance Access must be done using swrpc_keytool. Ifthere are less than 30 days remaining before the expiry of a certificate, then an event isgenerated in the Alliance Access Event Journal. This event is generated at startup of theAlliance Access servers, and also at midnight every day, until the new certificate is importedusing the saa_configconnection tool. For details, see "saa_configconnection" on page 226.

3.4.8 LDAP Configuration

Description

If you use LDAP and you want to secure the connection between Alliance Access and an LDAPauthentication server, then the following must be taken into account.

The iKeyman key management utility (gsk7ikm) is used to manage the CMS keystore thatcontains SSL certificates. Gsk7ikm is a Java program and requires a JRE to run. Furthermore, itcan handle a CMS keystore format only if the JRE is configured with the IBM CMS securityprovider. The user selects the JRE by setting the environment variables JAVA_HOME and PATH:

export JAVA_HOME=<JRE installation directory> export PATH=$JAVA_HOME/bin:$PATHThe standard JREs provided with AIX v6.1 and installed in /usr/java14 or /usr/java5 areconfigured with the IBM CMS security provider.

3.4.9 The Alliance Developers Toolkit

Introduction

To enable third parties to develop their own proprietary applications, SWIFT provides a suite ofsoftware known collectively as the Alliance Developers Toolkit.

The objective of the Alliance Developers Toolkit is to make the Alliance Access base servicefacilities available to developers of third-party products. Using the Alliance Developers Toolkit,these developers can go on to build their new products at reduced cost and thus increase thenumber of Alliance Access products available to customers.

This is done by:

• taking advantage of the Alliance Developers Toolkit facilities provided by Alliance Access todevelop new components

• re-using and interacting with existing Alliance Access components (for example, ApplicationInterface (AI), SWIFT Interface (SIA)).

Installation

31 December 2010 55

Contents

The Alliance Developers Toolkit contains:

• documented APIs to access the services offered by these facilities. These APIs guaranteeindependence with respect to Alliance Access internal applications.

• a procedure to install components and configure these facilities so that they fit theapplication's needs, without interfering with existing installed applications.

• A de-installation procedure to restore the situation before application installation.

Security

The Alliance Developers Toolkit reinforces the internal security mechanisms of Alliance Accessby:

• minimising the risk of running "break-in" applications that can tamper with the system

• restricting the access of new components (through the use of application profiles likeoperator profiles) to the set of services which they officially claim to require.

3.4.9.1 Delivery Packages

Description

The Alliance Developers Toolkit is delivered as two packages to be installed on top of a versionof Alliance Access supporting the Alliance Developers Toolkit. This is a runtime packageinstalled at customer sites to support components developed with the Alliance DevelopersToolkit, plus a development package used to develop new components with the AllianceDevelopers Toolkit outside of the Alliance development environment.

The runtime package consists of:

• a (set of) shared libraries that implement C bindings for the Alliance Developers Toolkit APIs

• a component installation/uninstallation procedure

The development package consists of:

• header files containing 'C' code prototypes of the functions provided in the AllianceDevelopers Toolkit, with the required type definitions, return statuses, and so on.

• a tracing package for debugging purposes

• a tool to create an installation medium (adk_mk_medium)

• example application(s) and example makefiles.

Both packages are available on AIX.

3.4.9.2 Alliance Developers Toolkit Documentation

Description

In-depth documentation on creating an installation medium and the installation of AllianceDevelopers Toolkit components is supplied with the Alliance Developers Toolkit developmentlicense.



3.4.10 Install Alliance Developers Toolkit Third Party SoftwareApplications

Introduction

The installation of a third-party component is organised into two domains:

• software installation

• service registration

The software installation utilities handle all operations involved with the component (forexample, downloading or upgrading, patching, and so on), while the registration procedureintroduces the component to Alliance. This identification is required to allow the component touse the Alliance services.

The following table shows each installation utility:

Domain Utility Description

Software Install a component Initial installation of the software of a newcomponent

Upgrade a component Upgrading the software of an existing componentto a more recent version

Remove a component Remove all the software of an existing component

Add a patch Add a patch to an existing component

Remove a patch Remove the last installed patch from an existingcomponent

Services Register a component Register to SWA services: either for a newcomponent or for an upgrade

Unregister a component Unregister the component

Note For more information about how to install components, refer to the documentationof your third-party vendor.

Unit assignment to Alliance Developers Toolkit components

When installing Alliance Access with optional package 99:TOOLKIT RUN-TIME licensed, a unitnamed "_ALL_" is defined and is available in the Component view of the Security Definitionapplication (SDA). This unit is assigned by default to the Alliance Developers Toolkitcomponent. When the _ALL_ unit is assigned to a component, no unit restrictions exist for thatAlliance Developers Toolkit component.

Installation

31 December 2010 57

4 UpgradeOverview

You can upgrade to Alliance Access 7.0 from the following releases:



If you have an earlier release installed, then you must upgrade to release 6.0, or 6.3 beforeupgrading to 7.0.

If you have Alliance Access 6.2 installed, then you must upgrade to release 6.3 beforeupgrading to 7.0.

You can also upgrade to Alliance Access 7.0 from the following releases of Alliance RMA:



Do NOT remove Alliance Access before starting the upgrade process. Use the release media.

4.1 Before You UpgradeTwo ways to upgrade

You can upgrade to Alliance Access 7.0 in either of the following ways:

• on the same host where a previous release of Alliance Access is installed

• migrate to a new host, using a backup file prepared on an existing host.

This feature can only be used between two systems of the same operating system (from AIXto AIX).

Tip If you are migrating to a new host, then follow the instructions in "Prepare aBackup File for Upgrade" on page 27 before you check the prerequisites in thissection and launch the upgrade.

Important

Ensure that you complete all the upgrade prerequisites. During the upgrade, any prerequisitesthat have not been fulfilled (and would make the upgrade fail), are reported one by one.

For example, if there are still live messages in the database or events from yesterday whichhave not been archived, then the upgrade will quit. In this case, you must start the servers,archive and back up the messages or events, stop the servers, and then restart the upgrade.

Prerequisites

The prerequisites for an upgrade are the same as for a standard installation (for details, see"Prerequisites for the Installation" on page 31). However, there are a number of additionalrequirements:

1. Alliance Access release 6.0 or 6.3 (with latest mandatory patches) must already beinstalled on your system.

2. You must have the necessary AIX patches available. For details, see the Release Letter.



3. For a silent upgrade, you must prepare the following files:

– a licence file. See "Prepare the Licence File" on page 20.


4. To allow immediate connection of your Alliance Workstations to your Alliance Access 7.0server, we strongly recommend that you ensure that all workstations are installed withAlliance Workstation release 7.0. You cannot connect previous releases of AllianceWorkstation to an Alliance Access 7.0 server.

5. In the home directories of all_adm (/home/all_adm), check for the presence ofthe .swa.<instance-name>.rc file.

If this file is present, comment out the following line if present in the file:

EXPORT NSORDER = local,local,localDo this by inserting a # character at the beginning of the line, for example:

# EXPORT NSORDER = local,local,local

6. During the upgrade, a copy of your database folder is made in a mig directory in therelease tree. Ensure that the drive where the Alliance release tree is currently installedcontains enough free space for this database copy.

Note After a successful upgrade and after making a backup of your upgradedsystem, you can delete the mig folder to save disk space.

7. From the SWIFT Interface application, Quit and Logout all logical terminals and switch themall to Manual Mode. For details, see the Daily Operations Guide.

8. From the SWIFT Support application, ensure that the latest Message Syntax Table isassigned to the logical terminals that are in use. For details, see the System ManagementGuide.

9. From the Application Interface application, select all the message partners and disablethem.

10. Export RMA authorisations. For details, see "Exporting Authorisations Manually" in theRelationship Management Application User Guide.

Note During the upgrade, RMA authorisations are automatically migrated to the newrelease. This step is only to provide you with a backup in case of problemswith key migration during the upgrade process.

11. Ensure that all message templates have the latest message syntax table assigned andexport them all. For details, see "Exporting Templates" in the Daily Operations Guide.

Note During the upgrade, templates are automatically migrated to the new release.This step is only to provide you with a backup in case of problems withtemplate migration during the upgrade.

If, after the upgrade, message templates cannot be opened or modifiedbecause they are assigned to an earlier message syntax table, then you canexport the message templates and assign the latest message syntax table tothem during the import.

Upgrade

31 December 2010 59

12. Check that no alarms are formatted as MT 999 and generated from event distributions forinternal correspondents. If this is the case, such alarms can generate new live messages inAlliance Access causing the upgrade process to fail as no live messages are allowed inAlliance Access when upgrading. These alarms must be removed before upgrading.

13. To be able to perform the upgrade, it is mandatory to archive:

– all messages from the Message File, if you upgrade from release 6.0. You may have tocomplete some messages manually before you can archive them.

– all messages from the Message File up to the previous day, if you upgrade from release6.3. You may have to complete some messages manually before you can archive them.Messages of the current day are migrated.

– all events up to the previous day from the Event Journal application. Events of thecurrent day are migrated.

all Audit Cards.

14. Back up the message archives, journal archives, and any Audit Cards, from the SystemAdministration window. This is mandatory if you want to access your archives on theupgraded system.

Note If you upgrade from release 6.3, then you must back up and remove thearchives of the previous days.

15. Prepare the migration from strict to relaxed certificate mode. See the Release Letter fordetailed instructions.

16. Stop the Alliance Access servers.

17. Before starting the upgrade, it is strongly advised that any existing Alliance Access andassociated database files and archives, are backed up. It is also advisable to back up theoperating system. In addition, it is recommended that you make a backup of the /usr/swainstances registration data.

If the upgrade fails, then you can restore the original software and database, but rememberto restore the original /usr/swa directory (including insts) before you attempt to restart thesystem.

Important If you are upgrading from 6.3, then you should also back up the /var/opt/swiftdirectory before starting the upgrade.

18. Make a note of the $ALLIANCE and $ALLIANCE_DB variables. You may need access tothis information if the upgrade fails. In such a case, you have to re-export these variablesbefore restoring the previous software and database.

Note Ensure that the path to the database is not a symbolic link. You may have toupdate the /usr/swa/insts file temporarily to point to the real directories.

19. During the upgrade, Alliance Access overwrites the existing user environment file .profilefor the Alliance Access administrator account. The existing .profile is saved as .profile.baksuffixed by an incremental number in case it exists.

20. After the upgrade, database recovery is not automatically restarted. If you have activatedthis option, you must deactivate it before the upgrade starts, and reactivate it once theupgrade has been completed. See "Activate the Database Recovery Mode" on page 179for details.



Checklist

Task Reference

The host satisfies the system requirements. "Prepare the System" onpage 15

If upgrading to a new host:

The software owner system account has been created.

The default temp directory has been created. "Create the TemporaryInstallation Directory" onpage 19

If upgrading to a new host:

The backup file from the previous release is available

"Prepare a Backup File forUpgrade" on page 27

Prepare the migration from strict to relaxed certificate mode. Release Letter

4.2 Interactive Upgrade

4.2.1 Starting the Upgrade From DVD

Remote DVD drive

To start the upgrade from a remote DVD drive, see "Upgrading From a Remote DVD Drive" onpage 62.

To start the upgrade from DVD:

1. Log on as root.

Note It is assumed that the root account will use the Korn shell. See the entry forroot in the /etc/passwd file.


export DISPLAY=<IPaddressComputer>:0.0where <IPaddressComputer> must be replaced by the IP address for the computerwhere the upgrade windows will be displayed.


Log on as root and create a mount point directory, for example MNT:

mkdir /MNT

4. Insert the Alliance Access release DVD and then mount the DVD by typing:



/AIX/installer

6. Start the upgrade by typing:

./saa-install

Upgrade

31 December 2010 61

To record the upgrade details for future use, run the saa-install command with the -record option. See "Record input parameters" on page 86 for more information.

7. To proceed with the upgrade, follow the steps in "Upgrade Alliance Access Interactively" onpage 64.

4.2.1.1 Upgrading From a Remote DVD Drive

To upgrade from a remote DVD drive:






5. Create a mountpoint on the local machine.


7. Access the DVD from the local machine using the local name <mountpoint> for the remotedirectory.

For example:


8. Start the upgrade by typing the following command:

./saa-installTo record the upgrade details for future use, run the saa-install command with the -record option. See "Record input parameters" on page 86 for more information.

4.2.2 Starting the Upgrade From Local Directory

Remote directory

To start the upgrade from a remote directory, see "Upgrading From a Remote Directory" onpage 63.

To start the upgrade process:

1. Log on as root. It is assumed that the root account will use the Korn shell. See the entry forroot in the /etc/passwd file.



3. A directory mount point must first be made for the DVD and then the DVD must bemounted. Log on as root and create a mount point directory, for example MNT:

mkdir /MNT



4. Insert the DVD and then mount the DVD by typing:


5. Copy the DVD contents to an install directory on hard disk:


6. Unmount the DVD:

cd ~umount /MNT


/AIX/installer



9. To proceed with the upgrade, follow the steps in "Upgrade Alliance Access Interactively" onpage 64.

4.2.2.1 Upgrading From a Remote Directory

Introduction

To upgrade from a directory on a remote file system, the remote file system must be mountedcorrectly on the local system. Otherwise, the upgrade fails.

To upgrade from a remote directory:

1. Copy the DVD contents to an directory on the remote machine.


3. Mount this file system on the local machine.

4. Access the directory from the local machine using the local name <mountpoint> for theremote directory.

For example:




Upgrade

31 December 2010 63

4.2.3 Upgrade Alliance Access Interactively

Installation event log

Events that occur during upgrade are recorded in the installation.log file, found in the AllianceAccess installation path. In case of upgrade failure, please check this file for the reasons of thefailure.

To upgrade Alliance Access:

1. When the upgrade program starts, it unpacks the files required. Once all the files areunpacked, a window similar to the following appears.

2. If you are upgrading on the same host, select the Upgrade option.

If you are upgrading on a new host, select Install Alliance Access 7.0 from PreparedBackup File.

3. Click Next .

The End-user Licence window appears.

4. Accept the terms, and click Next .

If you selected the Upgrade option, go to step 6.

If you selected Install Alliance Access 7.0 from Prepared Backup File, the Backup FileLocation window appears.



5. Browse to the location of the backup file that you created in "Prepare a Backup File forUpgrade" on page 27. You cannot use a backup file created with Alliance Access Release6.x.

6. Click Next .

The Installation Location window appears.

7. Verify the user account displayed in the Owner field and type the password for thisaccount. This user account is the Alliance Access owner.

8. Click Next .

If you selected the Upgrade option, then a message appears, prompting you to close allthe Alliance applications that are currently open before proceeding with the upgrade.

9. Click Next .

The checkhost command is run to validate whether your system meets the minimumoperating system requirements. The test results are saved in the software installationdirectory, in the file:

Upgrade

31 December 2010 65

installation_systemcheck_yymmdd_hhmmss.html

where yymmdd and hhmmss are the date and time of the upgrade.

If you selected the Upgrade option, then a message appears, reminding you to takeAlliance Access environment (software, database, and archives) and system backups.

If you have taken these backups, then click Next . Otherwise, click Cancel to quit theupgrade process. Take the necessary backups, and then repeat this procedure.

The Packages Configuration window appears.

This window is used to license the packages and features that your institution haspurchased from SWIFT. The pre-selected packages are part of the base licence andinclude the packages already licensed on your previous installation of Alliance Access.They cannot be deselected.

Note If your system does not meet all the requirements, then the SystemConfiguration Test Results window displays information about the problemsthat were detected.

• Problems reported as Warning do not prevent you from continuing theupgrade, but you may encounter unexpected results.

• Problems reported as Blocking prevent you from continuing the upgrade.Fix the problem and start the upgrade again.

10. Decide how you want to provide licence-related data:

• Manually: proceed to step 11.

• From a licence file: click Load from File and browse to the location of the licence file. Thisis the licence file that you prepared in "Prepare the Licence File" on page 20.

Then click Next and proceed to step 16.

11. Verify that all the items listed in the Packages section of your licensing agreement areselected. Then click Next .



Note You may want to license additional component packages or 'disable' selectedcomponent packages after the upgrade is finished. To do this, you canrelicense Alliance Access using a new licensing agreement. You do not haveto reinstall. For more information, see "Relicensing" on page 75.


Verify that all the items listed in the Servers section of your licensing agreement areselected. Then click Next .

13. The Licensed Destinations Configuration window appears, showing the destinationsalready licensed on your Alliance Access system.

14. If necessary, add or remove destinations according to your licensing agreement.

If you have to add new destinations, type:

• the 8-character live destination(s) listed on your licensing agreement

• the 8-character training destinations. The eighth character is a ''0'' to denote test andtraining. Although the test and training destination does not appear on your licensingagreement, you must enter it if you want to use it.


The Message Types Configuration window appears, showing the message types alreadylicensed on your Alliance Access system.

15. If necessary, add or remove message types, as listed on your licensing agreement.



Upgrade

31 December 2010 67




Note Do not confuse the Initialisation Passwords with the Master Passwords. TheMaster Passwords are used by the two Security Officers when they first signon to Alliance Access.

17. Click Next .


18. The Instance Configuration window appears.

Field Description

Host Name The host name of the Alliance Access system.

IP Address The IP address of the Alliance Access system.

Instance Name The name of the Alliance Access instance on the Alliance Accesssystem.

Instance Comment The description of the instance.

19. Click Next .

If you upgrade from Alliance Access or Alliance RMA 6.3, then the Temporary locationwindow appears. This window shows the default temporary directory that will be usedduring the database upgrade, and the estimated disk space required for the upgrade.

20. If there is not enough disk space in the default directory, then select another directory in theDirectory Name field. Type the directory name or click Browse to select a directory.



21. Click Next .


22. Check that the details displayed are correct, and if so, click Install . Once you click Install , itis not possible to abort the software upgrade. If the details are not correct, click Previous toreturn to the previous screen(s) and make your corrections.

The software upgrade begins. You can monitor the progress of the upgrade throughvarious windows, for instance while Alliance Access copies files.

At the end of the software upgrade, the Installation Complete window appears, confirminga successful upgrade.

The window provides information about the port configuration. For more information aboutport configuration, see "TCP Configuration for the Alliance Access Server" on page 239.

23. Click Finish to complete the upgrade.

Note Once the upgrade has completed successfully, if you have upgraded fromDVD, remove the DVD as follows:

1. Log on as root and unmount the DVD by typing:

cd ~umount /MNTIf this command returns the error Device is busy, this means thatthere is some process still using the DVD software. This is probably theSystem Administration application itself. Quit the System Administrationwindow and run the following in the controlling x-term:

cd /Try again to unmount the DVD.

2. Log off from the root account.

24. Perform the post-upgrade steps described in the Release Letter. Then follow theinstructions in "Post-Upgrade Checklist" on page 73.

4.3 Silent Upgrade

4.3.1 Starting the Upgrade From DVD Drive

Introduction

Ensure that you completed all the upgrade prerequisites. During the upgrade, any prerequisitesthat have not been fulfilled (and would make the upgrade fail), are reported one by one.

For example, the upgrade would be interrupted because there are still live messages in thedatabase. You will have to start the servers, archive and back up the messages, stop theservers and restart the upgrade. Then it could be interrupted because there are still events fromyesterday that have not been archived. You would again have to start the servers.

Remote DVD drive

To start the upgrade from a remote DVD drive, see "Upgrading From a Remote DVD Drive" onpage 70.

Upgrade

31 December 2010 69

To start the upgrade process from DVD:

1. Log on as root.

Note It is assumed that the root account will use the Korn shell. See the entry forroot in the /etc/passwd file.




Log on as 'root' and create a mount point directory, for example MNT:

mkdir /MNT

4. Insert the Alliance Access release DVD and then mount the DVD by typing:



/AIX/installer

6. Start the upgrade process by typing the following command:



For example:



7. Perform the post-upgrade steps described in the Release Letter. Then follow theinstructions in "Next Steps" on page 73.

Viewing the silent upgrade progress or result

The installation log file is updated during a silent upgrade. You can view the log to see theprogress of the silent upgrade, or the result if the silent upgrade operation has ended.

4.3.1.1 Upgrading From a Remote DVD Drive

To upgrade from a remote DVD drive:








5. Create a mountpoint on the local machine.


7. Finally, access the DVD from the local machine using the local name <mountpoint> for theremote directory.

For example:





For example:






4.3.2 Starting the Upgrade From Local Directory

Introduction

Ensure that you completed all the upgrade prerequisites. During the upgrade, any prerequisitesthat have not been fulfilled (and would make the upgrade fail) are reported one by one.

For example, the upgrade would be interrupted because there are still live messages in thedatabase. You have to start the servers, archive and back up the messages, stop the serversand restart the upgrade. Then it could be interrupted because the latest Message Syntax Tablehas not been installed. You would again have to start the servers.

Remote directory

To start the upgrade from a remote directory, see "Upgrading From a Remote Directory" onpage 72.

To start the upgrade process:

1. Log on as root. It is assumed that the root account will use the Korn shell. See the entry forroot in the /etc/passwd file.



Upgrade

31 December 2010 71

3. A directory mount point must first be made for the DVD and then the DVD must bemounted. Log on as root and create a mount point directory, for example MNT:

mkdir /MNT

4. Insert the DVD and then mount the DVD by typing:


5. Copy the DVD contents to an install directory on hard disk:


6. Unmount the DVD:

cd ~umount /MNT


/AIX/installer




For example:






4.3.2.1 Upgrading From a Remote Directory

Introduction

To upgrade from a directory on a remote file system, the remote file system must be mountedcorrectly on the local system. Otherwise, the upgrade fails.

To upgrade from a remote directory:

1. Copy the DVD contents to an directory on the remote machine.


3. Mount this file system on the local machine.

4. Access the directory from the local machine using the local name <mountpoint> for theremote directory.



For example:





For example:






4.4 Next Steps

4.4.1 Post-Upgrade Checklist

Procedure

1. Complete the migration from strict to relaxed certificate mode. This task must be performedon Alliance Gateway by the Alliance Gateway instance owner. See the Release Letter fordetailed instructions.

2. Log onto UNIX as Alliance Administrator.

3. Start the Alliance Access servers in Operational mode.

4. Both Security Officers (LSO and RSO) must sign on using the Master Passwords takenfrom the licensing agreement.

5. Check the event journal for:

• alarms which may have occurred during the upgrade.

• any events relating to "OSN gaps". If a logical terminal was in the process ofreconnecting (following an interrupted session) when Alliance Access was stoppedbefore the upgrade, then it is possible that messages will be missed at the next login/select attempt. In such a case, events relating to OSN gaps are present in the eventjournal.

6. The previous Alliance Administrator account environment file .profile is savedas .profile.bak.

If you want to reinstate it, then log on as system administrator, start an X-term window fromAlliance Access and type:

cd~

Upgrade

31 December 2010 73

mv .profile .profile.inst (saves the new profile)mv .profile.bak .profile (re-installs the old profile)exit

7. Open the Application Interface application and check and enable each required messagepartner. For details, see "Managing Message Partner Profiles" in the System ManagementGuide.

8. Alliance Developers Toolkit (ADK) licence only: all ADK applications used with AllianceAccess 6.0, 6.2, or 6.3 have to be recompiled, rebuilt and re-installed before they can beused with Alliance Access 7.0. For information, contact your ADK application vendor.

9. All existing operator profiles are migrated from the upgraded version. In addition, all defaultprofiles are created with an "R7.0" prefix. The user can select to use the new profiles orkeep the migrated ones. The new applications and/or functions are not added to themigrated profiles.

10. If you have to access your old message archives and journal archives, then restore abackup of the previously backed up archives from the System Management application. Asarchives are part of the database, this is the only way to access archives from previousreleases.

11. Not required for stand-alone Alliance Access:

Check Part B, "Configuring for SWIFTNet" on page 95 and follow any procedures that areapplicable to your upgraded system (for example MX Messaging).

12. If you deactivated database recovery before the upgrade, then reactivate it now. See"Activate the Database Recovery Mode" on page 179 for details.

13. For systems with HACMP licensed, see "Upgrade considerations" on page 125.

4.4.2 Additional Tasks after a Non-root Upgrade

Procedure

After the upgrade of Alliance Access by a UNIX account without root privileges, the followingtasks must be performed with the UNIX root account:

1. Log on as root.

2. Navigate to the installation directory and run the script called saa_rootpostupgrade.ksh.For example:

<Install_directory>/install/saa_rootpostupgrade.kshThe script:

• runs the RPCConfiguration.ksh script which creates the /usr/swa directory, and addsfiles to it.

• updates the Alliance Access instances in /usr/swa/insts.

• runs the apply_alliance_ports script which configures the Alliance ports in /etc/services.

• copies the installation registry entry (a file generated in the installation directory duringinstallation) of the product to the central registry location on the system (/var/opt/swift).

• starts the Alliance Access Name Service of the Alliance Access instance with the highestrelease number.



5 RelicensingIntroduction

This section explains how to add or remove packages and features that your institution canpurchase from SWIFT.

5.1 Before You RelicenseCommon prerequisites

Before relicensing, ensure that:

• all passwords and licence-related information is available. You can get this information usingSecure Channel. For more information about Secure Channel, see "Secure Channel" onpage 11.

• both Alliance Access Security Officers (or their deputies) are present, unless you are loadingyour licensing options from a file.

• if you are loading your licensing options from a file, the file is ready.

• the Alliance Access servers have been stopped. If not, in the System Administrationwindow, double-click the Stop Alliance icon.

• you check the integrity of your existing Alliance Access software. See "Checking the AllianceAccess Software Files" on page 231 and "The Software Integrity Report" on page 94 fordetails.

Prerequisites for silent relicensing

• Ensure that you have prepared the following files:

– a licence file. The licence file must have had the Security Officer passwords obfuscated orencrypted. See "Prepare the Licence File" on page 20.


Prerequisites for Destination and Package Removal

Before removing destinations or packages, read the following table and perform the tasks if theyapply to your Alliance Access installation.

Licensed options Required task

Licensed destinations If the new licensing contains fewer destinations, then the unwanteddestinations are removed. Before relicensing, ensure that no unwanteddestination is referenced by:

• configuration parameters

• operator profiles

• message templates

• message file search templates

Relicensing

31 December 2010 75

Licensed options Required task

• routing rules

Application interface A message partner with Session Direction 'To' can only be removed whenthere are no Exit Points assigned to it. If this is the case, first de-assign theExit Points and then remove the message partner.

Packages 14:DATABASE RECOVERY Deactivate the database recovery mode.

16:FILE AUTOMATED No action required. Print message partnersare not affected. Note that automatedmessage partners are changed to manual.

18:CAS TCP-IP Remove all message partners that use TCP/IP. If not removed, then they are disabled.

5.2 Interactive RelicensingOverview

Use this procedure to add new packages and modify existing packages in interactive mode.

Procedure



3. At the command prompt, type:

./saa-relicenseTo record the relicensing details for future use, run the relicense command with the -record option. See "Record input parameters" on page 86 for more information.

4. The installation application unpacks the files in the installer.

The Packages Configuration window appears.



This window is used to license the packages and features that your institution haspurchased from SWIFT. The pre-selected packages are part of the base licence andinclude the packages already licensed on your Alliance Access system.

5. Decide how you want to provide licence-related data:

• Manually: proceed to step 6.

• From a licence file: click Load from File and browse to the location of the licence file. Thisis the licence file that you prepared in "Prepare the Licence File" on page 20.

Then click Next and proceed to step 11.

6. Select the licensed components, using the items listed in the Packages section of yourlicensing agreement. Then click Next .


8. Select the licensed components, using the items listed in the Servers section of yourlicensing agreement. Then click Next .

The Licensed Destinations Configuration window appears, showing the destinationsalready licensed on your Alliance Access system.

9. In this window, type:

• the eight characters of any new live destination(s) listed in the Licensed Destinationssection of your licensing agreement

• the 8-character training destinations. The eighth character is a ''0'' to denote test andtraining. Although the test and training destination does not appear on your licensingagreement, you must enter it if you want to use it.


The Message Types Configuration window appears, showing the message types alreadylicensed on your Alliance Access system.

Relicensing

31 December 2010 77

10. In this window, type any new message types listed in the Message Types section of yourlicensing agreement.






Note Do not confuse the Initialisation Passwords with the Master Passwords. Theseare used by the two Security Officers when they first sign on to AllianceAccess.

12. Click Next .



13. Check that the details displayed are correct, and if so, click Install . Once you click Install , itis not possible to abort the software relicensing. If the details are not correct, click Previous

to return to the previous screen(s) and make your corrections.

The software relicensing begins.

At the end, the Installation Complete window appears, confirming that the relicensing hascompleted successfully.

14. Click Finish .

15. Proceed to "Next Steps" on page 79.



5.3 Silent RelicensingOverview

Use this procedure to add new packages and modify existing packages in silent mode.

Procedure



3. Close the System Administration window.

4. At the command prompt, type:

./saa-relicense -silent <response file> [-key <value>]Where:


For example:

/tmp/alliance/silent.properties.relicensing


Viewing the silent relicensing progress or result

The installation log file is updated during silent relicensing. You can view the log to see theprogress of the relicensing, or the result if the relicensing operation has ended.

5.4 Next StepsTasks to perform after relicensing

Licensed Options Required task

Licensed Destinations After removing destinations:

• start the Alliance Access servers and check the Event Journal.Errors may be reported if configuration parameters in the SystemManagement application still point to the removed destination(s) (forexample, the Sender Logical Terminal for Alarm Messages). Ifnecessary, redefine these configuration parameters to point to validlicensed destinations.

• open the Correspondent Information application and add a newdestination with the "External" definition if required for the removeddestination.

• if you have scheduled the automatic import of authorisations fromthese destinations, then you must modify the action to removethese destinations. For details, see the Relationship ManagementApplication User Guide.

• remove the emission profiles, reception profiles, input channels,and output channels related to these destinations.

Relicensing

31 December 2010 79

Licensed Options Required task

Application interface If necessary, redefine message partners using licensed protocols andcheck that the message partners work properly.

Operator profiles

After relicensing, review the operator profiles and remove any functions or permissions relatedto the down-licensed options, and then approve the operators assigned to these profiles.



6 RemovalIntroduction

Should it ever be necessary to remove Alliance Access instances and software from yoursystem (for example, due to an error during installation), the Alliance administrator can removeAlliance Access files using the following procedure.

Hosted database

If you uninstall an instance of Alliance Access that uses a hosted database, then the AllianceAccess database is not removed. In this case, the customer must remove the Alliance Accessdatabase from the Oracle database instance where it is installed. A hosted database requiresthe license, 13:HOSTED DATABASE.

6.1 Before You RemoveRemoval checklist

1. Make sure that you have archived and backed up the Event Journal and Message File.

2. Store the backup of the Event Journal and Message File archives outside of the AllianceAccess server, as the removal process will remove these directories.

3. Verify that Alliance Access is not running.

4. Verify that the System Administration application is not running.

6.2 Interactive RemovalProcedure

1. Log on as root.

2. Open a Korn shell.


export DISPLAY=<IPaddressComputer>:0.0where <IPaddressComputer> must be replaced by the IP address for the computerwhere the uninstallation windows will be displayed.

4. At the command prompt, use the following change directory command to locate thedirectory that contains the Alliance Access application:

cd <Alliance installation directory>where <Alliance installation directory> is the name of the directory whereAlliance Access is installed.

5. Start the removal process by typing:

_uninst/uninstallThe Uninstaller window appears.

6. Click Next to proceed, or Cancel to terminate the process.

Removal

31 December 2010 81

A warning prompts you to confirm the removal.

7. Click Yes to remove the software, or No to terminate the process.

After you click Yes , the removal of the software starts. When the process is complete, awindow appears to confirm that the software was removed successfully.

8. Click Finish .

9. Reboot your system.

6.3 Silent RemovalPrerequisites

Before removing Alliance Access, ensure that:

• you have prepared the requisite response file.

For complete removal, the response file must contain system.deinstallOption=base.See "Prepare the Response File (for Silent Installation, Upgrade, Relicensing, or Removal)"on page 21.

• the Alliance Access servers are stopped.

Procedure

1. Log on as root.



export DISPLAY=<IPaddressComputer>:0.0where <IPaddressComputer> must be replaced by the IP address for the computerwhere the uninstallation windows will be displayed.

4. At the command prompt, use the following change directory command to locate thedirectory that contains the Alliance Access application:

cd <Alliance installation directory>where <Alliance installation directory> is the name of the directory whereAlliance Access is installed.

5. Start the removal process by typing:

_uninst/uninstall -silent <response file>Where <response file> identifies the path to and name of the properties file to be used.

6. Reboot your system.



7 PatchesOverview

Software fixes are applied in the form of patches. This section explains how to install andremove any software patches that are distributed to you.

There are two types of patch:

• "Cumulative patches", which are sent to all Alliance Access users. Each cumulative patchincludes the previous cumulative patch and any optional patches issued after the previouscumulative patch.

• "Optional (emergency) patches", which are sent to selected Alliance Access users and whichaffect specific deliverables, such as executables and library files. Optional patches do notinclude any previous patches.

Patches can be downloaded from the Download Centre on www.swift.com.

7.1 InstallationPrerequisites

Before installing a patch, you must:

1. read the patch release letter carefully. It describes the scope of the patch and theinstallation instructions.

2. make sure that the Alliance Access servers are not running.

3. back up all data and software.

4. prepare a response file, if you perform a silent installation. For more information, see"Prepare the Response File (for Silent Installation, Upgrade, Relicensing, or Removal)" onpage 21.

5. log on as the user who installed Alliance Access, unless specified otherwise in the releaseletter.

For cumulative patches:

• A cumulative patch can be installed on a base release, on a previous cumulative patch or ona previous optional patch. A cumulative patch contains all cumulative and optional patchessince the base release.

For optional (emergency) patches:

• An optional patch can be installed on a base release, on a previous cumulative patch or on aprevious optional patch. Optional patches must be installed in the order of increasing level

Patches

31 December 2010 83


number. Removing an optional patch restores the previous version of the affecteddeliverables.

For all patches:

• Installing a patch replaces the product deliverables of this patch with new, patched versions.The previous, replaced versions of the deliverables are stored by the patch installationsoftware to be restored when the patch is removed.

7.2 RemovalCan the patch be removed?

Not all patches can be removed. See the patch release letter for specific information aboutpatch removal.

Prerequisites

Before removing a patch, you must:

1. read the patch release letter carefully.

2. prepare a response file, if you perform a silent removal. The response file must containsystem.deinstallOption=delta. For more information, see "Prepare the ResponseFile (for Silent Installation, Upgrade, Relicensing, or Removal)" on page 21.

Note that cumulative patches cannot be removed with this method.

3. log on as the user who installed Alliance Access, unless specified otherwise in the releaseletter.



8 Additional Information

8.1 Non-root Installation or UpgradePurpose

It is possible to install, patch, or upgrade the Alliance Access software with a non-root useraccount, such as, all_adm. The non-root user account will own the installation, and become theAlliance administrator.

A non-root user logs on using the owner account of Alliance Access and launches the installerto begin the installation. Before you can launch the installation with a non-root user account, youmust perform specific pre-installation steps.

Overview of a non-root installation or upgrade

1. The root user logs on and prepares Alliance Access for the non-root installation. For moreinformation, see "Prepare for Non-root Installation, Upgrade, Backup, or Removal" onpage 19.

2. A non-root user logs on using the owner account of Alliance Access and launches theinstaller to begin the installation.

3. Complete any post-installation or post-upgrade tasks. For more information, see "AdditionalTasks after a Non-root Installation" on page 49 or "Additional Tasks after a Non-rootUpgrade" on page 74.

Checkhost

If a non-root user account runs the installation, then some of the checkhost checks may failbecause of the privileges associated to the account. Typically, these will be warnings. Thecheckhost report will include information about any such failures.

8.2 Silent ModeDifference between silent operations and interactive operations

The prime difference between interactive and silent operations is the way input data is provided.In an interactive procedure, this data is provided through a series of windows. In a silentoperation, the data is provided in response files and licence files. For more information, see"Response Files" on page 86.

Benefits

Silent operations have the following benefits:

• Do not require firewall administrators to open many ports to support the X-Display necessaryfor a GUI. This makes it easier and more secure to connect to remote servers or serversbehind a firewall.

• Simplify the repetition of an operation over several instances of the same product, by reusingthe response files after editing them.

• Allow for the segregation of duties: operations managers can prepare the response files inadvance, and the operation can be scripted or carried out by other people of the organisation.

Additional Information

31 December 2010 85

Silent operations are as secure as interactive operations. Any passwords can be madeunreadable in the response file. For more information, see "Protect the Passwords in theResponse File" on page 22.

Scope

The following Alliance Access operations can be performed silently:

• Installation

• Upgrade

• Removal

• Patch installation

• Patch removal

• Relicensing

Viewing the silent operation progress and result

The installation log file is updated during a silent operation. You can view the log to see theprogress of an operation that is in progress, or the results of an operation that has ended.

8.2.1 Response Files

8.2.1.1 Response Files

Purpose

A response file provides the input that is required to complete a silent installation, upgrade,relicensing, patch, or removal procedure.

If you plan to perform an installation, upgrade, relicensing, or removal in silent mode, then youmust first prepare a response file.

Create a response file

You can prepare a response file in the following ways:

• record the input during an interactive procedure, using the -record option. See "Recordinput parameters" on page 86.

• modify the sample response file that is provided on the release media. See "Prepare theResponse File (for Silent Installation, Upgrade, Relicensing, or Removal)" on page 21.

• modify an existing response file, which you created previously during installation, upgrade,relicensing, or removal.

The release media contains sample response files (with extension .properties).

Record input parameters

If the -record option is provided as an option during installation, upgrade, relicensing, orremoval, then the program will:

• create a response file in the location specified.



The response file has a name that ends with .properties and the Licence File has a namethat ends with .properties.lic. The license file is created in the same location as theresponse file. For more information, see "Prepare the Licence File" on page 20.

If a file of the same name already exists, then it is overwritten.

• record the parameters as they are input and store them as values of the correspondingsystem parameters, in the newly created response file. The parameters are storedalphabetically in the response file.

It will also store the associated Licence File for the Package and Server licences,Destinations, and MTs. For more information, see "Licence Files for Alliance Access" onpage 91.

• When any password is entered (left and right initialisation passwords, system password),they are encrypted or obfuscated before being stored in the response file.

The syntax for the -record option is as in the following example:

saa-install -record <response file> [-key <value>]Where:

• <response file> identifies the path to and name of the file to be used to record theparameters.

• -key <value>, if used, indicates that the passwords in the response file will be encryptedwith the provided encryption key. If this parameter is omitted, then the passwords will beobfuscated.

8.2.1.2 Response File Parameters

Purpose

This section describes the possible parameters and indicates their applicability in installation-related operations.

Parameters table - notational convention

The following syntax applies:

• M = mandatory parameter

• C = conditional parameter

• - = not relevant

To make passwords non-readable

When launching a silent installation or upgrade, the passwords can be made non-readable inthe response file. The parameters that end with .encrypted must be used to provideencrypted or obfuscated values only. For more information, see "Protect the Passwords in theResponse File" on page 22.


31 December 2010 87

Response file parameters

The following table lists the parameters that must be defined in the response file for AllianceAccess:

Parameter name Description Inst

alla

tio

n

Up

gra

de

Rel

icen

sin

g

Rem

ova

l

Pat

ch in

stal

lati

on

Pat

ch r

emo

val

system.installOption Install type

Use base (installation), ordelta (upgrade).

M M - - - -

system.deinstallOption Uninstall type

Use base (full systemremoval), or delta (patchremoval).

- - - M - M

application.key A keyword that identifies theproduct.

Use saa (upgrade fromAlliance Access), or sar(upgrade from Alliance RMA).

M M - - M -

Mandatory.Accept.LicensingTerms

Licensing agreement. Musthave the value: Agree

M M - - M -

application.installLocation Installation directory(1) M M(2)

- - M(2)

-

application.owner.name Operating system account thatis the owner of the resultinginstance. For example,all_admThe operating system accountthat is used to install theinstance. The name can bepreceded by the domain name.

C - - - - -

application.ipAddress IP address of the machinewhere the instance exists

C C - - - -

application.instanceName Instance name

For example: AccessC - - - - -

application.instanceComment Instance comment C C - - - -

licence.left.passwordlicence.left.password.encrypted

Left Initial password.

You can only use one of thetwo parameters in a responsefile.

C C M - - -

licence.right.passwordlicence.right.password.encrypted

Right Initial password.


C C M - - -

database.type Type of database M - - - - -




alla

tio

n

Up

gra

de

Rel

icen

sin

g

Rem

ova

l

Pat

ch in

stal

lati

on

Pat

ch r

emo

val

installer.delta.tmpdir Temporary directory for thedatabase upgrade

- M(3)

- - - -

upgrade.deleteAuditCards Delete audit cards

Use the value:

true - delete audit cards

false - cancel the upgrade

- M - - - -

(1) For example, <system_drive>:/Alliance/Access (upgrade from Alliance Access) or <system_drive>:/Alliance/RMA (upgrade from Alliance RMA).

(2) In this case, the directory location also specifies the location of the Installation Log file.

(3) If there is not enough space in the default directory, then the temporary directory for the database upgrade will be

used.

Hosted database - additional installation options

When Alliance Access is installed onto an external Oracle instance, then the following additionalparameters are required in the response file. These parameters relate to the configuration of theAlliance Access database in the external Oracle instance:


alla

tio

n

Rel

icen

sin

g

Rem

ova

l

Pat

ch in

stal

lati

on

Pat

ch r

emo

val

oracle.listener.host Host name or IP address ofserver which hosts the Oracleinstance.

C - - - -

oracle.listener.port Port number used to connect tothe Oracle instance.

If not defined, then the defaultport number is used: 1521

C - - - -

oracle.sid Oracle service ID of the Oracleinstance.

C - - - -

database.tablespace.data.name The tablespace from thedatabase where tables thathold the Alliance Accessconfiguration data will becreated.

For example: SAA_DATA

C - - - -

database.tablespace.event.name The tablespace from thedatabase where tables thathold the Alliance Accessevents will be created.

C - - - -


31 December 2010 89


alla

tio

n

Rel

icen

sin

g

Rem

ova

l

Pat

ch in

stal

lati

on

Pat

ch r

emo

val

For example: SAA_JRNL

database.tablespace.message.name The tablespace from thedatabase where tables thathold theAlliance Accessmessages will be created.

For example: SAA_MESG

C - - - -

database.tablespace.file.name The tablespace from thedatabase where tables thathold the Alliance AccessFileAct payloads will becreated.

For example: SAA_FILE

C - - - -

database.tablespace.temp.name The tablespace from thedatabase where tables will becreated to hold the AllianceAccess restored data.

For example: SAA_TEMP

C - - - -

database.temporary.schema.name Database temporary schemaowner name

C - - - -

database.temporary.schema.passworddatabase.temporary.schema.password.encrypted

Password for the temporarydatabase schema owner.


C - - - -

database.schema.name Database schema owner name C - - - -

database.schema.passworddatabase.schema.password.encrypted

Password for the databaseschema owner.


C - - - -

database.user.name Database user name to beused by the Alliance Accessserver to connect to thedatabase

C - - - -

database.user.passworddatabase.user.password.encrypted

Password for the databaseuser name.


C - - - -



8.3 Licence Files for Alliance AccessInput Licence File

During an interactive installation, upgrade, or relicensing of Alliance Access, you can choose touse separate Input Licence Files that contain the Package and Server licences, Destinations,and MTs. This saves you from entering the data manually through the GUI screens. The InputLicence Files can be built as a result of a Secure Channel download. For more informationabout Secure Channel, see "Secure Channel" on page 11.

By using the -record option during an interactive installation, upgrade, or relicensing, you canalso create a licence properties file for future use.

Sample licence properties files are provided on the Alliance Access product DVD.

Usage of Input Licence File

You can use the Input Licence File with an associated Response File when installing,upgrading, or relicensing Alliance Access software in silent mode. The Input Licence Fileprovides the data about the Package and Server licences, Destinations, and MTs.

For more information about Response Files, see "Response Files" on page 86.

Name of Input Licence File

If the file name of the Response File is filename.prop, then the file name of the associatedInput Licence File must be filename.prop.lic.

Both files must be in the same directory.

For more information about preparing Licence Files, see "Prepare the Licence File" on page 20.

8.4 Checking Your System ConfigurationUses of the checkhost tool

You can use the checkhost tool provided on the release media to analyse the configuration ofa computer and produce a report from the results.

The tool can provide the following output:

• a full system analysis report

• a comparative analysis report: this report compares a host machine against a list of minimumrequirements provided in a requirements file.

The checkhost tool is integrated in the Alliance Access installer as well and provides an on-screen report of possible discrepancies during the installation.

8.4.1 Launching the checkhost Tool

Procedure

1. Log on with the root account.



4. Change to the AIX directory.


31 December 2010 91

5. Locate the checkhost tool by typing:

#cd <Mount point CD>/AIX/checkhost

6. Launch the checkhost tool.

8.4.2 checkhost Syntax and Examples

Syntax

checkhost.ksh [-req <pathname of requirements file>] [-rootdir <pathname of a directory>] [-out <pathname of the report file>]where:

• text wrapped in square brackets [....] represents an optional part of the command

• text wrapped in angle brackets <....> represents values that you must supply.

Options

Use To specify

-req the path to a requirements file

-rootdir the path to a drive or file system against which the checkhosttool must perform a disk space validation.

-out a location for the report file. If not used, then the report isproduced in the following default location:

/tmp/checkhost.log

Syntax examples

• a full system analysis report in the default output location, without disk space validation:

./checkhost.ksh

• a comparative analysis report against the Alliance Access base requirements file, with diskspace validation:

./checkhost.ksh -req ../installer/access.dat -rootdir /Alliance/Access

8.4.3 The Full System Analysis Report

Overview

When running the checkhost tool without specification of a requirements file, the followingreport details are produced:

Information Unit

Checkhost command invoked

CPU type

CPU speed MHz

Number of CPUs

Memory size(1) MB



Information Unit

OS version

Local hostname

Free disk space MB

Installed software

Installed patches

Network adapters

IP addresses

File systems

Paging space MB

OS language

Local time zone

DNS server

Network options(2)

(1) Memory size: the checkhost tool prints the value as reported by the operating system. This value may seem

inaccurate because of discrepancies that arise from the OS defining 1 Megabyte as 1024 Kilobytes and the CPU

vendor defining 1 Megabyte as 1000 Kilobytes.

(2) Network options: details about the configuration of the network driver, such as, tcp close wait interval, arp

cleanup interval, and so on, are reported.

8.4.4 The Comparative Analysis Report

Overview

The comparative report indicates whether a given host machine passes the requirementscriteria in a requirements file.

Performing a comparative analysis before a software installation ensures that the intended hostmachine meets the requirements.

Requirements file

The access.dat file is found on the release DVD, in the AIX/installer folder. It contains thebase requirements for installing or upgrading to Alliance Access 7.0.

8.4.5 Error Messages and Warnings

Error messages

The report produced by the checkhost tool may contain the following error messages:

• Option not available on this platform. Not all properties can be analysed on all platforms.This message indicates that a specific property cannot be analysed.

• Unable to retrieve data, command timed out. A built-in timeout prevents the system fromhanging while the checkhost tool queries the operating system. The checkhost tool displaysthis message against each report detail for which property information is not received withinthe timeout period.


31 December 2010 93

Patch level warnings and errors

When it is run to check minimum requirements, the OS patch level check can generate Warningerrors. This means that the patch is either at a higher or lower level than the requirement, or notpresent. Some errors are reported as Fatal, which means that it is highly recommended toadjust the patch level to the requirements. Failure to do so can cause unexpected Alliancebehaviour.

Example

Installed patches-----------------Warning: patch too HIGH : patch 'IMNSearch.bld.DBCS' must be installed with level '2.3.1.15' instead of '2.4.0.0'.Warning: patch too HIGH : patch 'IMNSearch.bld.SBCS' must be installed with level '2.3.1.15' instead of '2.4.0.0'.

AIX process warnings and errors

There may be cases when the number of processes owned by the Alliance Accessadministrator (for example, all_adm) exceeds the value of the maximum number of processesthat are running per user. This may be due to scripts that are running for monitoring, or openingseveral Application Interface Message Partner sessions simultaneously.

If the checkhost tool reports a warning or failure against the number of available processes onAIX, then increase the number of processes from the default setting of 128 to the requirednumber (for example, 16384) with the command:

chdev -l sys0 -a maxuproc=16384

8.5 The Software Integrity ReportSoftware integrity verification

The integrity of the Alliance Access software is checked by the Integrity Verification Tool (IVT).

The generation of the software integrity report and the result of the software integrity check areincluded in the installation log file produced during the installation, upgrade, or patch operation.

The reports can also be generated at any time by using the saa_system integrity command,as described in "Checking the Alliance Access Software Files" on page 231.

Types of Integrity report

The Integrity Verification Tool can produce the following types of integrity reports:

Report Type Description When to Generate and Check

Full A report is produced for all the softwarefiles of Alliance Access.

• Before software upgrade (fromrelease 7.0 onwards)

• Before patch installation

• Before relicensing

Partial A report is produced for specific softwarefiles (.exe, .dll) of Alliance Access.

Before starting the Alliance Accessservers.



Part B

Configuring for SWIFTNet

Part B - Configuring for SWIFTNet

31 December 2010 95



9 IntroductionPurpose

This section describes the steps to complete before you can send and receive FIN, InterAct,and FileAct messages.

Prerequisites

Before performing the steps in this section, the following must be completed:

• Connectivity setup. For details, see "Check Connectivity" on page 98.

• SWIFTNet Link 7.0 is installed and configured on the system hosting Alliance Gateway.

• You have installed or upgraded to Alliance Gateway 7.0.

• You have set up valid certificates for an Authoriser DN.

Tasks related to the management of certificates are performed on Alliance Gateway. Formore information, see the Alliance Gateway Operations Guide.

• You have installed or upgraded to Alliance Access 7.0. For details, see Part C, "SystemAdministration" on page 111.

Configuration tasks

The main tasks are:

• Checking connectivity

• Defining Alliance Access in Alliance Gateway

• Configuring Alliance Access for FIN messaging

• Configuring Alliance Access for InterAct and FileAct messaging.

Introduction

31 December 2010 97

10 Check Connectivity

10.1 Configure SWIFT DNS ServersDescription

Before you can use your connection correctly, ensure that you have access to the SWIFT DNSservers. For details of configuring the SWIFT DNS servers, see the SWIFTNet Link InstallationGuide.

Note To configure the DNS, you do not need the SNLOwner Account. You can use theroot account.

10.2 Confirm ConnectivityDescription

You must ensure that the host computer can successfully reach the necessary ports on theSWIFT systems. The ports that must be accessible are defined in the SWIFTNet NetworkConfiguration Tables Guide.

Before proceeding with the SWIFTNet Link installation, confirm your Network Connectivity byexecuting the checkip program, as explained in the SWIFTNet Link Installation Guide,"Checking the TCP/IP Network Configuration". This program contacts all necessary ports andchecks whether they are open and can be reached.

If this connectivity test is not successful, then the next step (SWIFTNet Link installation) will fail.



11 Defining Alliance Access in AllianceGateway

Overview

This section explains how to:

• set up Alliance Access as a message partner in Alliance Gateway, with Relaxed SNLFormat selected

• define Alliance Access as an endpoint on Alliance Gateway.

These steps are similar whether you are configuring for FIN, InterAct, or FileAct messaging.Only the message partner and endpoint names differ.

11.1 ConceptsMessage partner names

When Alliance Access connects to an Alliance Gateway system, it must provide a uniquemessage partner name. The Alliance Access message partner name is derived from its instancename.

Alliance Access creates the message partner name with the characters fin_ (for FINmessaging) or sni_ (for InterAct and FileAct messaging) followed by a normalised AllianceAccess instance name.

A normalised Alliance Access instance name is the Alliance Access instance name, reduced tolower case with underscores removed and truncated to 10 characters. The name can have amaximum of 14 characters.

For example, if the Alliance Access instance name is SAA_Rel_70, then the message partnername must be fin_saarel70 (for FIN messaging) or sni_saarel70 (for InterAct and FileActmessaging).

Note If you have multiple Alliance Access systems connecting to SWIFTNet throughAlliance Gateway, then ensure that each system has a unique instance name.

Endpoint names

When Alliance Access connects to SWIFTNet, it must provide an Endpoint name. AllianceAccess always uses an Endpoint name that is identical to its message partner name.

11.2 FIN Messaging

11.2.1 Setting Up a Message Partner in Alliance Gateway

Overview

You must configure your Alliance Access instance as a message partner in Alliance Gateway.This must be completed for each Alliance Access system that connects to this Alliance Gatewaysystem.

Defining Alliance Access in Alliance Gateway

31 December 2010 99

Note • Alliance Gateway provides a default message partner called fin_relaxed. Thismessage partner has the correct settings for connection between AllianceAccess and Alliance Gateway. If you want to use this profile directly, thenchange your Alliance Access instance name to relaxed. Otherwise you canuse the settings in the fin_relaxed profile to create a message partner profile. Inthis case, remember to give it the same name as your Alliance Access instance,that is, fin_<your_instance_name>.

This fin_<your_instance_name> message partner must always be defined.

• You must select Relaxed SNL Format as default message format for emissionand reception.

To set up a message partner for FIN messaging

Add a new message partner as described in the Alliance Gateway Operations Guide, "Creatinga Client/Server Message Partner", with the following details:

1. For the message partner and SWIFTNet Link Endpoint, enter a Name. Enter a uniquemessage partner name based on the Alliance Access instance name. See "Concepts" onpage 99.

2. In the Type field, select ClientServer.

3. In the Host Adapter field, select Remote API Host Adapter.

4. In the Default Message Format for Emission (from Message Partner) field, selectRelaxed SNL Format.

5. In the Supported Message Formats section, select Relaxed SNL Format. Move it fromthe Available to the Selected column by highlighting it and clicking the transfer icon.

6. In the Additional Processing section, select Remote API Host Adapter and LocalAuthentication, then define the local authentication keys.

7. Add the Certificates for Relaxed Mode to the message partner details by clicking Add .

8. Save the message partner details.

9. Finally, enable the message partner. See the Alliance Gateway Operations Guide,"Enabling and Disabling a Message Partner".

11.2.2 Defining Alliance Access as an Endpoint on AllianceGateway

Overview

When data arrives from SWIFTNet into Alliance Gateway, it has the Endpoint name embeddedin the data. Alliance Gateway must know how to route this data to the correct Alliance Accesssystem.

This section explains how to configure Alliance Gateway with this routing information.



Note Before you define the Endpoint, you must have defined the message partner to beused by the Endpoint.

Alliance Gateway provides a default Endpoint called fin_relaxed. You can use thesettings for this endpoint as an example to create yourfin_<your_instance_name> endpoint.

To define an Endpoint

Add a new Endpoint as described in the Alliance Gateway Operations Guide, "Adding anEndpoint", with the following details:

1. In the Routing tab:

• in the Name field, enter the message partner name that you defined in "Setting Up aMessage Partner in Alliance Gateway" on page 99.

• in the SNL Endpoint field, select Equals (=) in the Relation subfield and the messagepartner name that you defined in "Setting Up a Message Partner in Alliance Gateway" onpage 99, in the second subfield.

• in the Traffic Type field, select All.

2. In the Destination tab:

• in the Interface field, select Application Interface.

• in the Application field, select the message partner name that you defined in "SettingUp a Message Partner in Alliance Gateway" on page 101.

• from the Mode option buttons, select Relaxed.

3. Save this configuration.

4. Finally, enable the Endpoint. See the Alliance Gateway Operations Guide, "Enabling andDisabling an Endpoint".

11.3 InterAct and FileAct Messaging

11.3.1 Setting Up a Message Partner in Alliance Gateway

Overview

For InterAct and FileAct messaging, you must also configure Alliance Access as an additionalmessage partner in Alliance Gateway. This must be completed for each Alliance Access systemthat connects to this Alliance Gateway system.

Note • The message partner definition for the SWIFTNet Interface component (forInterAct and FileAct messaging) also follows a defined naming convention. Themessage partner name is also derived from the Alliance Access instance name,but with sni_ as its prefix, that is, sni_<your_instance_name>.

• You must select Relaxed SNL Format as default message format for emissionand reception.


31 December 2010 101

To set up a message partner for InterAct and FileAct messaging

Add a new message partner as described in the Alliance Gateway Operations Guide, "Creatinga Client/Server Message Partner", with the following details:

1. For the message partner and SWIFTNet Link Endpoint, enter a Name. Enter a uniquemessage partner name based on the Alliance Access instance name. See "Concepts" onpage 99.

2. In the Type field, select ClientServer.

3. In the Host Adapter field, select Remote API Host Adapter.

4. For the Default Message Format for Emission (from Message Partner) field, selectRelaxed SNL Format.

5. In the Supported Message Formats section, select Relaxed SNL Format. Move it fromthe Available to the Selected column by highlighting it and clicking the transfer icon.

6. In the Additional Processing section, select Remote API Host Adapter and LocalAuthentication, then define the Local Authentication keys.

7. Add the Certificates for Relaxed Mode to the message partner details by clicking Add .

8. Save the message partner details.

9. Finally, enable the message partner. See the Alliance Gateway Operations Guide,"Enabling and Disabling a Message Partner".

11.3.2 Defining Alliance Access as an Endpoint on AllianceGateway

Overview

When data arrives from SWIFTNet into Alliance Gateway, it has the Endpoint name embeddedin the data. Alliance Gateway must know how to route this data to the correct Alliance Access.

This section explains how to configure Alliance Gateway with this routing information.

Note Before you define the Endpoint, you must have defined the message partner to beused by the Endpoint.

To define an Endpoint

Add a new Endpoint as described in the Alliance Gateway Operations Guide, "Adding anEndpoint", with the following details:

1. In the Routing tab:

• in the Name field, enter the message partner name that you defined in "Setting Up aMessage Partner in Alliance Gateway" on page 101.

• in the SNL Endpoint field, select Equals (=) in the Relation subfield and the messagepartner name that you defined in "Setting Up a Message Partner in Alliance Gateway" onpage 101 in the second subfield.

• in the Traffic Type field, select All.



2. In the Destination tab:

• in the Interface field, select Application Interface.

• in the Application field, select the message partner name that you defined in "DefiningAlliance Access as an Endpoint on Alliance Gateway" on page 100.

• from the Mode option buttons, select Relaxed.

3. Save this configuration.

4. Finally, enable the Endpoint. See the Alliance Gateway Operations Guide, "Enabling andDisabling an Endpoint".

11.4 Data Encryption/Gateway Authentication betweenAlliance Access and Alliance Gateway

Description

If you have decided to use Data Encryption/Gateway Authentication between Alliance Accessand Alliance Gateway, then perform these steps:

• On Alliance Gateway, create a Private Key and Certificate. See the Alliance GatewayOperations Guide, "Creating a Private Key and Certificates".

• On Alliance Access, configure the SSL settings on Remote API. See the Alliance GatewayRemote API Operations Guide, "Configuring SSL Settings on RA".



12 Configuring Alliance Access for FINMessaging

Overview

To configure Alliance Access to send and receive FIN messages, you must:

• define a SWIFTNet connection

• assign a SWIFTNet connection to a Logical Terminal

• send and receive a Test MT message

• set up your access to the SWIFTNet FIN Test service (only if you are a vendor).

Note

When a FIN message is sent from Alliance Access over SWIFTNet, it is enveloped in anInterAct message. In addition, relationship management authorisations for the live RMA serviceare also exchanged as InterAct messages over SWIFTNet. An Authoriser DN signs the InterActmessages that are sent over SWIFTNet.

Therefore, the Logical Terminal that sends the message must be mapped to an Authoriser DN,as follows:

Role to assign to Authoriser DN Associated Alliance Gatewaymessage partner

the fin role for the swift.fin service.

In other words, such an Authoriser DN is a certified FINUser.

fin_<instance>

12.1 Defining a SWIFTNet ConnectionOverview

You define a SWIFTNet connection from the SWIFTNet Support application.

The default SWIFTNet connection is created with the name SAG with pre-defined settings.

For detailed information about maintaining SWIFTNet connections, see "Defining and ModifyingSWIFTNet Connections" in the System Management Guide.

Permissions

By default, only the security officers, and the R7.0_Supervisor and R7.0_Superkey operatorprofiles have the SWIFTNet Support application permissions. Assign these permissions to otheroperators as needed.

When assigning permissions, ensure that Connection Handling in the "SNL Handling" functionis set to Yes.

If you use Local Authentication between Alliance Gateway and Alliance Access, then you canassign the two parts of the Local Authentication Key in the "SNL Handling" function to a singleoperator, or separately to two operators. By default, the Security Officers (LSO and RSO) onlyhave one part of the Local Authentication Key in the "SNL Handling" function assigned.

For more information about assigning permissions, see "Managing Alliance Access Security" inthe System Management Guide.



12.2 Assigning a SWIFTNet Connection to a LogicalTerminal

Overview

For information about assigning a SWIFTNet connection to a Logical Terminal, see "AssigningSWIFTNet Connections to a Logical Terminal" in the System Management Guide.

12.3 Sending and Receiving a Test MT MessageProcedure

1. Ensure that the Alliance Access servers are running in Operational mode.

2. Sign on through Alliance Workstation as an operator with message processingentitlements.

3. Open the Message Creation application.

4. Create an MT 999 (free format message) to be sent from your Test and TrainingDestination (which is assigned to SWIFTNet) addressed back to your Test and TrainingDestination. Sender and Destination fields in the message must be the same. Your Testand Training Destination is the one that ends in 0.

5. Route the message to the _SI_to_SWIFT queue.

6. With the Test and Training logical terminal, log in to SWIFT and select FIN so that thequeued message can be sent and received.

For instructions, see the Daily Operations Guide.

7. Check the status of the Test and Training logical terminal. The logical terminal must beselected and have one N (normal) message queued for transmission.


8. Search for the MT 999 in the Message File.


12.4 Access to the SWIFTNet FIN Test Service(Vendors only)

Important

This section is to be used only by SWIFT, its partners, and vendors (your BIC must start withPT).

To connect to the SWIFTNet FIN test-infrastructure (FIN Vendor Testbed (VTB) through theSWIFTNet Integration Testbed (ITB)), you must access the swift.fin!x service.

A system variable (SERVICE_NAME) must be set with the value swift.fin!x.

Configuring Alliance Access for FIN Messaging


Procedure

1. Log on to UNIX as Alliance administrator.

2. Using vi or another text editor, open the file $HOME/.swa.$ALLIANCE_INSTANCE.rc.

3. Add the following line:

export SERVICE_NAME=swift.fin!x

4. Close and save the file.

The variable is only taken into account after closing and re-opening the SystemAdministration window.

Note If the servers were running while setting the variable, you must do the following:

• Stop theAlliance Access servers and the bootstrap.

• Close the System Administration window, and open it again.

• Start theAlliance Access bootstrap and the servers.



13 Configuring Alliance Access for InterActand FileAct Messaging

Overview

To configure Alliance Access to send and receive InterAct and FileAct messages, you must:

• define a SWIFTNet connection

• install Application Service Profiles

• configure SWIFTNet emission and reception profiles

• send and receive an InterAct or a FileAct message.

Note

When an InterAct of FileAct message is sent from Alliance Access over SWIFTNet, it isenveloped in an InterAct message. In addition, relationship management authorisations for thelive RMA service are also exchanged as InterAct messages over SWIFTNet. An Authoriser DNsigns the InterAct messages that are sent over SWIFTNet.

Therefore, the emission profile that sends the message must be mapped to an Authoriser DN,as follows:

Role to assign to Authoriser DN Associated Alliance Gatewaymessage partner

the appropriate role for the SWIFTNet Business service sni_<instance>

13.1 Defining a SWIFTNet ConnectionOverview

You must define a SWIFTNet connection to assign to the SWIFTNet emission and receptionprofiles. For more information, see "Defining a SWIFTNet Connection" on page 104.

13.2 Installing Application Service ProfilesOverview

You must install the latest Application Service Profiles on Alliance Access to correctly send andreceive traffic for InterAct or FileAct services. For more information, see ''Installing ApplicationService Profiles" in the System Management Guide.

13.3 Configuring SWIFTNet Emission and ReceptionProfiles

Purpose

To exchange messages through SWIFTNet, you must define, enable, and activate SWIFTNetemission and reception profiles for InterAct and FileAct messaging, and also for the RMAservice. You perform these tasks from the SWIFTNet Interface application.

Configuring Alliance Access for InterAct and FileAct Messaging


During the installation or upgrade of Alliance Access, an emission profile and a reception profileis created automatically for each live licensed BIC8 for the live RMA service.

Permissions

By default, only the R7.0_Supervisor and R7.0_Superkey operator profiles have thepermissions to manage emission and reception profiles in the SWIFTNet Interface application.You can assign these permissions to other operators, if necessary.

To configure SWIFTNet profiles

1. Configure an emission profile for each licensed BIC8. See "Defining Emission Profiles" inthe System Management Guide.

2. Configure a reception profile for each licensed BIC8. See "Defining Reception Profiles" inthe System Management Guide.

3. Assign a SWIFTNet connection to each emission profile and reception profile that youcreated. See "Assigning SWIFTNet Connections to SWIFTNet Profiles" in the SystemManagement Guide.

4. If required, assign an input channel to an emission profile. For more information, see "SetUp Input Channels" in the System Management Guide.

5. Enable and activate each emission and reception profile. See "Enabling and ActivatingSWIFTNet Profiles" in the System Management Guide.

Enabling the profile makes it ready for use, and activating it starts message traffic.

13.4 Sending and Receiving an InterAct or a FileActMessage

Note

This procedure applies both for InterAct and FileAct messages, unless specified otherwise.

Procedure

1. Do either of the following:

• Create an MX message from Alliance Messenger on Alliance Web Platform. For moreinformation, see the Alliance Messenger Administration and Operations Guide.

• Create an MX message from your back-office application and send it to your AllianceAccess system.

2. Route the message to the _SI_to_SWIFTNet queue.

3. Ensure that the Alliance Access servers are running in Operational mode.

4. Sign on through Alliance Workstation.

5. Open the SWIFTNet Interface application.

6. Ensure that an emission profile for the SWIFTNet business service to be used has beencreated and set up, as well as a reception profile to receive MX messages from the sameSWIFTNet business service. For details, see "Configuring SWIFTNet Emission andReception Profiles" on page 107.



7. Enable and activate the SWIFTNet emission and reception profiles so that the queued MXmessage can be processed. For details, see "Configuring SWIFTNet Emission andReception Profiles" on page 107.

8. Search for the MX message in the Alliance Access Message File application, or fromAlliance Messenger on Alliance Web Platform. For more information, see the AllianceMessenger Administration and Operations Guide.

Configuring Alliance Access for InterAct and FileAct Messaging




Part C

System Administration

Part C - System Administration




14 Introduction to System AdministrationOverview

To ensure that your Alliance Access installation works efficiently, and in a secure manner,various "system administration" tasks must be carried out. Some of these tasks (such aschecking that the servers are running) must be performed daily, while others (such as renamingan instance) are performed as and when required.

Access to the role of Alliance administrator is gained by logging in with the AllianceAdministrator account. The name of this account is specified during the installation or upgradeof Alliance Access, and is mapped to the system variable $ALLIANCE_ADMIN.

Alliance Access administration tasks may be performed in the following ways:

• by using the facilities of the System Management application of Alliance Access to configurevarious operational parameters of Alliance Access, and to perform backups of the AllianceAccess database and archives.

• by using the Alliance command line tools available in $ALLIANCE/bin (such as saa_systemand saa_dbrestore)

• by using UNIX commands, together with dedicated scripts, to interact directly with the UNIXoperating system.

It is primarily the role of the Alliance administrator to perform these tasks. Normally, the Allianceadministrator does not have access to the operational functions of Alliance Access - that is notdefined as an operator able to sign on to Alliance Access. Tasks that must be performed withinAlliance Access (typically using the System Management application) are, therefore, assumedto be carried out by a supervisor or senior operator of Alliance Access.

This guide defines the tasks that are performed by the Alliance administrator, when logged on toUNIX using the Alliance Administrator account. The use of the System Administrationapplication, therefore, is restricted to those with knowledge of the password for the AllianceAdministrator account. This password must be carefully protected, and regularly updated.

For some organisations, the Alliance administrator may also fulfil the role of 'supervisor' or'operator' - that may also have operational responsibilities. If so, that person must also bedefined as an Alliance Access operator and use their separate Alliance Access operatornickname and password for access to the operational facilities within Alliance Access.

For details about the facilities provided within the System Management application, see theSystem Management Guide.

14.1 Overview of the System AdministrationApplication

Introduction

Alliance Access provides a dedicated application which is used exclusively by the Allianceadministrator.

Introduction to System Administration


14.1.1 Selecting an Instance

Overview

Whenever you log into AIX as Alliance Administrator and enter the relevant password, thesystem checks whether there is more than one instance of Alliance Access installed. If there is,then the Alliance Application Instance Selection window appears.

For a description of this window, see "Alliance Application Instance Selection Window" onpage 115.

To select an instance:

1. Log into AIX as Alliance Administrator and enter the relevant password. The AllianceApplication Instance Selection window appears.

2. Select an instance by selecting it, and then select Open from the Instance menu.

3. The System Administration application is started automatically and the Alliance SystemAdministration window appears.

For a description of this window, see "Alliance System Administration Window" onpage 116.



14.1.2 Alliance Application Instance Selection Window

Description

The Alliance Application Instance Selection window enables you to select an AllianceAccess instance installed on your system.

Example

Field descriptions

Name

The name of the instance given at installation time.

Product

The product type (for example, INTERFACE).

Comment

A user-defined comment field provided when the name of the instance is given.

14.1.3 The System Administration Application

Description

Access to the UNIX shell is also available from the Xterm command of the OS Configurationmenu in the Alliance System Administration window. This facility enables you to enter UNIXcommands and run admin scripts, if required.

Note When you have logged into AIX as Alliance Administrator, the Xterm commandprovides a shell window with administrator permissions. If you have simplyswitched to the administrator account (using su - <admin account name>)from your own, or another account, then you only have the permissions set foryour, or the other, account.

Many of the administrative tasks you are able to perform, may only be carried out when theAlliance Access servers are not running. If you select such a command while the servers arerunning, then a message appears to remind you to stop the Alliance Access servers.

For a list of the commands available using the System Administration application, see "AllianceSystem Administration Window" on page 116. The detailed use of each command is givenlater, within the appropriate section (for example, "General System Maintenance").



14.1.4 Alliance System Administration Window

Description

The various functions available within the System Administration application are logicallygrouped on four pull-down menus (File, Instance, OS Configuration and Alliance), whichappear at the top of the Alliance System Administration window, as described below.

The lower part of the window provides a scrolling text area in which the results of yourcommands, and confirmations of the actions taken, are reported. As a general rule, whenspecific actions are completed, a status like the following is reported in the lower part of thewindow:

Completed, Status = 0 the action has completed successfullyCompleted, Status = 1 the action was NOT completed successfullyIf Completed, Status = 1 appears, scroll back the text in the window for indications as tothe likely cause of the problem. In addition, the Alliance Event Journal may be used toinvestigate possible problems.

The lower part of the window is cleared automatically after every 20 K of characters of statusinformation has accumulated. 20 K is the default value which can be altered by the Allianceadministrator using the UNIX environment variable INA_MAX_STATUS_WIN_SIZE. Forexample,

export INA_MAX_STATUS_WIN_SIZE=20000

Example

Menu descriptions

File

The File menu provides access to commands related to your Alliance software:

• Report. See "General Troubleshooting" on page 242for information.

• Print Screen. See "General System Maintenance" on page 128 for information.

• Clear. See "General System Maintenance" on page 128 for information.

• Exit. See "General System Maintenance" on page 128 for information.



Instance

The Instance menu contains commands which you can use to display and manipulate theattributes of all instances installed on the system.

• Current Instance. See "General System Maintenance" on page 128 for information.

• List Instances. See "General System Maintenance" on page 128 for information.

OS Configuration

The OS Configuration menu provides access to the UNIX shell, which enables you to enterUNIX commands and run admin scripts, if required.

See "General System Maintenance" on page 128 for information.

Alliance

The Alliance menu provides access to commands related to using the Alliance servers,managing Alliance data and for troubleshooting:

• Start Alliance Servers. See "Managing the Alliance Access Servers" on page 136 forinformation.

• Stop Alliance Servers. See "Managing the Alliance Access Servers" on page 136 forinformation.

• JOURNAL_Query. See "General Troubleshooting" on page 242for information.

14.2 System Management Procedures

14.2.1 Regular Procedures

Overview

The following regular system management procedures are used to maintain Alliance Access:

• starting and stopping the servers, as required

• checking that the Alliance Access servers are running normally

• taking regular backups of the Alliance Access database.

The Alliance Access servers can be stopped and started from the following applications:

• System Management application: stop, or stop and restart Alliance Access (servers).

• System Administration application: stop or start the servers.

• UNIX command line (for example, using an Xterm): stop the servers using thesaa_system stop script. Start the servers using the saa_system start script.

14.2.2 Ad-hoc Procedures

Overview

The following procedures must be carried out by the Alliance administrator, as and whenrequired:

• Manage the configuration of AIX software for Alliance Access



• Check the security of Alliance Access software

• Recover Alliance Access database in the event of disk problems

• Reconfigure external connections when necessary

• Install software upgrades, as required

• Load and install software patches

• Kill Alliance Access processes when problems arise

• Provide general troubleshooting assistance

14.3 The Alliance Release TreeAlliance Access software components

The Alliance Access software is made of major functional entities called components. Thesecomponents recognise the client/server architecture of Alliance Access (using remote procedurecalls between server and client processes) and consist therefore of the following two types:

• The Service Component (which refers to the server in the architectural model) is a collectionof servers providing services to applications.

• The Application Component (which refers to the client in the architectural model) is acollection of applications requesting services from servers.

The two different types of components are identified by the last character of the component ID:'S' for Service and 'A' for Application.

The service components are:

BSS Base Service

FSS File Support Services

INS Installation Service

MAS Messenger Adapter Service

MXS Message Exchange Service

RMS Relationship Management Service

SIS SWIFT Interface Service

SNIS SWIFTNet Interface Service

SNSS SWIFTNet Support Service

SSS SWIFT Support Service

TRS Traffic Reconciliation Services

WSS Web Service Services

XSS Standards XML Support Services

The application components are:

BSA Base Application

INA Installation



MPA SWIFT Message Preparation

MXA Message Exchange

RMA Relationship Management

SIA SWIFT Interface

SNIA SWIFTNet Interface

SNSA SWIFTNet Support

SSA SWIFT Support

All components have the same directory tree structure except for a slight difference between thetwo component types. The following describes the Alliance release tree for service andapplication components.

The software release directory structure is as follows:

$ALLIANCE Root directory for Alliance Access Comment

Any ServiceComponent:

BSS, INS, MAS, MXS, RMS, SIS, SNIS,SNSS, SSS, TRS, XSS

bin/AIX Executables Contains Alliance Accessexecutables and commandscripts

lib/AIX Run-time libraries

data/AIX Data, configuration files, parameters files forprinting

nls/AIX Language-dependent catalogues

install Installation scripts

log Error and log files

Any ApplicationComponent:

BSA, INA, MPA, MXA, RMA,SIA, SNIA,SNSA, SSA

bin/AIX Executables Contains Alliance Accessexecutables and commandscripts

lib/AIX Run-time libraries

data/AIX Data and configuration files

nls/AIX Language-dependent catalogues

install Installation scripts

/usr/swa/insts Instances registration file Not in release tree, but animportant directory

/usr/tmp/alliance Error and log files

_uninst Uninstallation scripts

usrdata User data Dedicated folder for userdata

data/BIC Directory for full BIC datafiles



$ALLIANCE Root directory for Alliance Access Comment

data/UpdateBIC Directory for partial BIC datafiles

Core dumps, resulting from process crashes, are located in the bin/AIX directory of the relevantapplication. These files must be copied to the safestore-directory for investigation.

The following command displays existing core files:

find / -name core -exec ls -al {} \;



15 An Introduction to Dual ConfigurationSupport

Introduction

The Dual Configuration Support package (software and manuals) provides Alliance Accessusers with dedicated scripts that are used to configure, start, and stop an Alliance Accesssystem to make use of IBM's High Availability Cluster Multi-Processing facilities (HACMP).

If your site intends running Alliance Access on "high-availability'" systems (that is, machinesrunning IBM's HACMP software layer), then you must license the Dual Configuration optionprovided by SWIFT.

It is assumed that before any Alliance Access instance is configured within HACMP, theHACMP cluster is installed already and in an operational condition. For details about installingand configuring an HACMP cluster, and configuring Alliance Access instances there, see theHACMP Installation and User Guide.

This section describes the facilities offered by the Dual Configuration Support option anddescribes the correct system configuration to be used when running in an HACMP environment.The scripts provided by the Dual Configuration Support option works correctly only if thisconfiguration is strictly matched at the customer site. In the case where a different configurationis required, then the scripts supplied by SWIFT must be customised using the appropriateinstructions in the HACMP Installation and User Guide.

The scripts provided by the Dual Configuration Support option ensure the correct configurationand installation of Alliance Access on HACMP systems. However, it remains the responsibility ofthe local UNIX System Administrator (or Network Administrator) to monitor HACMP systems ona regular basis.

15.1 Alliance Access OperationsOverview

When using Dual Configuration Support, Alliance Access operations are protected as follows:

• In the event of a LAN adapter failure, the system automatically switches to a backup LANadapter, after a short service interruption.

• In the event of a processor failure, the backup processor automatically takes over, recoversthe Alliance Access database and restarts the Alliance Access servers. Following the transferof external connections, a fully operational system may be up and running withinapproximately 15 minutes (depending upon the size of the recovery log files).

An Introduction to Dual Configuration Support


15.2 HACMP OverviewDescription

The HACMP concept is based around the "high availability" or "fault resilient" computing model.It views availability in terms of a set of system-wide shared resources that co-operate toguarantee essential services. It combines software and hardware to minimise downtime byquickly restoring services when a system, or an essential component, fails.

This model does not provide continuous availability, as is the case for "fault tolerant" systems.Fault tolerant systems are designed to offer no service interruption following a componentfailure, but require the use of expensive specialised hardware.

To be highly available, a cluster must have no single point of failure. Cluster components thatare potential single-point of failures include:

• Processors (and associated memory)

• Networks (and adapters)

• Disks (and adapters)

Other components, such as power sources, must not be overlooked. All these components mustbe duplicated in the cluster to avoid a single point of failure. However, since there is a costassociated with each item of redundant hardware, HACMP may be configured to meet thedemand, and thus the budget, of users' processing environments. Therefore, HACMP does notrequire an exact duplication of each component. For example, a cluster may be configured withonly one network, which then becomes the single point of failure. "Alliance Access DualHardware Configuration" on page 122 describes the standard HACMP configuration supportedin the Alliance Access environment. Customer customisation of the standard HACMPconfiguration is described in the HACMP Installation and User Guide.

Disk failure is not supported directly by HACMP systems. There is no dedicated HACMPsubsystem to operate this component.

The availability of any service in the cluster-wide environment is based on "state-of-health" or"heart beat" messages, exchanged between nodes. If a node stops sending these messages,then the peer node automatically takes over and drives the recovery process. It also takes thenecessary action to get critical applications up and running, and to ensure that no data hasbeen corrupted or lost.

When the failed node rejoins the cluster and starts sending heart beat messages once again,HACMP detects this come-back, and may decide (depending on user specifications) that therecovered node has to resume its services. It does this by transferring data and applicationsfrom its peer node back into its own environment. This mechanism is used by default by theAlliance Access dual configuration software.

All of these mechanisms are performed automatically in the HACMP environment, withoutrequiring human intervention. Any event, action, or decision taken by HACMP is logged into filesand it is important that these files are closely monitored by the system or network administrator.Information about handling these files is included in the HACMP Installation and User Guide.

15.3 Alliance Access Dual Hardware ConfigurationIntroduction

The standard Alliance Access dual-hardware configuration is illustrated below. This is a provendefinition of a working dual hardware configuration. If your system is configured according tothese requirements then the scripts supplied by SWIFT work without customisation. If your



requirements are different, then the scripts must be modified using the information provided inthe HACMP Installation and User Guide, and in particular the section "Configuring AllianceAccess in HACMP".

D03

4015

5

Shared Disk

SWIFTNet

Secondary nodePrimary node

SWIFTNet Link-VPN connectivity

Managed CPE

SWIFTNet LinkAlliance Access

HardwareSecurityModule

AIXHACMP

SCSIcontroller

AIXHACMP

SCSIcontroller

heartbeatRS232 serial cable

Network card Network card Network cardNetwork card

The minimal requirements for Alliance Access running the standard AIX Cluster configurationare two systems, each one with:

• one internal disk and one on-board Ethernet adapter (#1)

• Ethernet adapter (#2)

• SCSI-DE Fast/Wide controller

• 8-Port Serial adapter (replaced by graphic adapter if GUI) with:

– serial 1 - local ASCII terminal

– serial 2 - serial connection between the two systems (for "heart beat" signal)

– serial 3 - connection for an HSM

Each system may have its own internal disk and is connected to external shared SCSI-DE fast/wide disks.

Nodes

The cluster is made up of two AIX systems, connected through:

• a single Ethernet LAN (each through two LAN adapters)

• a serial line



Disks

The Alliance Access release tree, database, and archives, can each reside in a different logicalvolume. However, their respective volume group must fully reside on the external disks (HD1-3).They may not be stored in the root volume group or in the internal disk of any of the twosystems. The single exception to this rule concerns the Alliance Access instance informationwhich is stored in the /usr/swa directory.

Note This restriction does not exist in non-dual system configurations, where the internaldisk is usually configured to store the root volume group of the computer, as wellas the full UNIX operating system, its related software, system spaces and noncritical applications.

The external SCSI disks (HDi) must be shared between the two nodes. They are connected tothe same shared SCSI bus (having a different address on each system) through a SCSI-2Differential interface. To avoid down-time in the event of failure of a shared SCSI configuration,it is recommended to attach the three disks to different SCSI buses.

The initial configuration of any volume group of the shared disks must be performed only onceon the source node: then imported through the SMIT interface (using importvg and HACMPcommands cl_scdiskreset) on the second node. This avoids inconsistent definitions of thesame logical volumes on both nodes. This aspect is covered in detail in the HACMP Installationand User Guide.

Network

Each of the two systems is connected to an Ethernet TCP/IP LAN using two network adapters(for example, 'en0' and 'en1'). Each of these four adapters is identified by a different adapterlabel. These labels and their respective IP addresses are specified in the /etc/hosts files (forexample, '149.134.52.122 N_1_service'). In addition to this, there must be one entry for the"service" IP address and label in the /etc/hosts files.

In short, each system has two network adapters, requiring in total five entries in it's /etc/hostsfile. For example:

Node 1 Adapter 'en0' IP label N_1_boot 149.134.52.121

N_1_service 149.134.52.122

Adapter 'en1' IP label N_1_standby 149.134.53.181

Node 2 Adapter 'en0' IP label N_2_boot 149.134.52.123

Adapter 'en1' IP label N_2_standby 149.134.53.182

The two standby adapters must be on a separate logical subnet of their peer service-bootadapters. This is done by using a TCP/IP feature, the network mask, which divides a singlephysical network into separate logical subnets. A valid network mask for the "52" and "53"subnets is 255.255.255.0. This logically defines for the "52" network, all the 149.134.52.xxxaddresses (where xxx means any number less than 256). The "53" subnet contains all the149.134.53.xxx addresses.



Upgrade considerations

When you upgrade Alliance Access, the copy of /usr/swa on the shared disk is updated. A sideeffect is that after hacmp_start_alliance is run the first time, the previous version of swa on theshared disk overwrites the upgraded version of /usr/swa. Using the wrong (older) versionof /usr/swa/alliance_init prevents activation of tracing. Also, the version information in insts isset to the previous version number (for example, 6.0 instead of 7.0).

To resolve this situation, each time a software update (upgrade or patch) affects modulesin /usr/swa (for example, alliance_init), the following post-installation procedure must beperformed by HACMP users to update the shared copy of swa.

1. Log on as root or enter:

su root

2. Enter the appropriate password.

3. In an Xterm session, type:

$ALLIANCE/BSS/bin/AIX/hacmp_report_config

4. From the output file, in the clshowres section of resource_group_name:

– In SWA_RESOURCE, note the first file system on the file systems line.

– Check for the swa directory in that file system.

– Overwrite swa copy with /usr/swa one. For example, if the file system is /alliance, use:

cp -frp /usr/swa /alliance Node 2 Adapter 'en0' IP label N_2_boot 149.134.52.123 N_2_service 149.134.52.124 Adapter 'en1' IP label N_2_standby 149.134.53.182

Takeover assumptions

For Alliance Access, it is assumed that there are identical devices and external connections onboth systems. During a takeover, the host name in all the necessary Alliance Access databaserecords is automatically renamed. Following a takeover, users are required to reconnect therelevant lines and devices onto the working system.

15.4 Important Technical Documentation on DualConfiguration and HACMP

Introduction

The HACMP Installation and User Guide contains all details about the installation, andconfiguration of an HACMP cluster, and the installation and configuration of Alliance Accessinstances. The more relevant parts of this guide are reviewed in the following overview.

The whole HACMP configuration and Alliance Access installation in an HACMP cluster iscovered in 11 steps.



15.4.1 Overview of the Contents of the HACMP Installationand User Guide

Hardware installation

The hardware installation of an HACMP cluster is the first practical step to be done on-site. Itfollows the hardware planning, ordering, and delivery. It is almost always carried out by IBMEngineers, and requires minimal intervention by the users. The hardware configuration must beas per Alliance Access Dual Configuration requirements.

AIX installation

The AIX operating system is the most important component in a cluster. It is therefore essentialthat AIX is correctly installed and that the version is compliant with both Alliance Accesssystems and HACMP. This section describes the steps to validate the AIX operating system. Itconfirms to the user that both (dual) systems are up and running, and that they can be used insubsequent steps. However, it does not guarantee that all Alliance Access and HACMPrequirements are met. This is done later when installing HACMP and Alliance Access.

HACMP system software installation

This section describes the installation of the HACMP system software on the cluster nodes. AnHACMP cluster is a set from 2 to 32 systems, this guide is based on a two-node cluster, but itcan be extended to a larger cluster. This installation of the HACMP system software must befulfilled separately on each node. If HACMP is already installed and verified on one or bothsystems, then a new HACMP installation must not be carried out. If an obsolete or unknownHACMP configuration is currently installed, then a new HACMP installation must be performed.

Cluster configuration

In eight steps, this section describes the software configuration of the HACMP cluster. There isno reference to IBM software application, only to the system configuration tasks required tomake HACMP operational.

Note This section is complex. The example in this section configures a basic cluster. Atthe end, the HACMP cluster can operate successful takeovers and re-integrations.This is validated by a test application.

Alliance Access installation and configuration

The installation of Alliance Access in an operational HACMP cluster is performed in three steps:

1. install Alliance Access on host_1

2. synchronise files and install Kernel Extensions on host_2

3. configure Alliance Access in HACMP.



15.4.2 Checklist

Description

The following list is a chronological summary of the stages required to install, from scratch, anoperational Alliance Access system on an HACMP cluster. The first column is the sequencenumber of the step. The second column is a short description of the step, and the third columnindicates where you can find detailed information.

Step Description See

1 Install the hardware IBM manuals

2 Install all the system software (AIX, HACMP,and so on)

IBM manuals

3 Configure and verify the HACMP cluster HACMP Installation and User Guide

4 Install Alliance Access instances See "Launching the Interactive InstallationFrom DVD" on page 32, and the HACMPInstallation and User Guide

5 Configure Alliance Access instances inHACMP

HACMP Installation and User Guide



16 General System MaintenanceIntroduction

Alliance Access provides a range of facilities to assist the Alliance administrator with systemmaintenance activities and with general troubleshooting.

All the facilities described in this section are available to the Alliance administrator when loggedon as Alliance Administrator and using the System Administration application. Some facilities -particularly those which interact with the operating system, or with the Alliance Access database- can only be used when the Alliance Access servers are not running.

To access any of the commands described in this section:

1. Log on to the Alliance Administrator account, using the current password. The main windowof the System Administration application will appear.

2. If the command you require can only be used when the servers are not running, then firstselect the Stop Alliance Servers command from the Alliance menu and wait for theservers to stop.

3. Select the required command from the relevant menu. Some commands simply displayinformation in the scrolling text area at the bottom of the main window. For othercommands, a window will appear, allowing you to enter relevant data. When you click OK

within that window, the selected command is run, using the data entered.

Some of the commands available within the System Administration application are the subject ofa broader discussion and are described, instead, in the following sections:

• "Managing the Alliance Access Servers" on page 136

– "The "Start Alliance Servers" Command" on page 136

– "The "Stop Alliance Servers" Command" on page 142

• "General Troubleshooting" on page 242

– "The Alliance Configuration Report" on page 242

– "The JOURNAL_query Facility" on page 244

All other administrative commands are described in this section.

Tip You can use the saa_system integrity command to check the integrity of theAlliance Access software. For more information, see "Checking the Alliance AccessSoftware Files" on page 231.

16.1 System Management CommandsOverview

The following commands can be used at any time for system management.



16.1.1 The Clear Command

Description

The Clear command from the File menu allows you to clear the scrolling text area in the lowerpart of the main window of the System Administration application. Use this command to deleteany text currently displayed in the main window. Once cleared, this text cannot be recovered.

16.1.2 The Print Screen Command

Description

The Print Screen command from the File menu allows you to print the current window to a fileor a printer. When Print Screen is selected, the Print Screen window appears.

To send the output to a file, select File in the Output To field and enter the file name in theFilename field. Click OK to send the output to the file specified.

To send the output to a printer, select Printer in the Output To field and then select adestination printer from the Printer field. Click OK to send the output to the printer. If noprinters have been defined, then the Printer option is not available.

16.1.3 The Exit Command

Description

The Exit command from the File menu allows you to quit the System Administration application.This command automatically logs you (Alliance Administrator) off from the AIX operatingsystem.

Upon quitting, you may be prompted for a reboot of the system if certain changes have beenmade to the operating system configuration.

Note Refer to the Xterm command if the reason you want to quit the SystemAdministration application is to access the UNIX shell.

16.1.4 Current Instance

Description

The Current Instance command from the Instance menu allows you to display the name of theAlliance Access instance that you are currently using.

General System Maintenance


16.1.5 List Instances

Description

The List Instances command from the Instance menu allows you to display a list of all theAlliance Access instances currently installed on your system.

16.1.6 The Xterm Command

Description

The Xterm command from the OS Configuration menu allows you to interact directly with theoperating system by entering UNIX commands from within the System Administrationapplication.

When you select this command, a new Xterm shell window opens. When the UNIX prompt ($)appears, you may enter UNIX commands to run the dedicated scripts described in this guide, orperform other administrative tasks that require direct interaction with UNIX (for example, checkthe contents of a directory, determine which processes are currently running, and so on). Theresponse to such commands normally appears in the same window.

To cancel and dismiss the Xterm shell, enter the exit command.

Note When you have logged into AIX as Alliance Administrator, the Xterm command willprovide an Xterm shell window with administrator permissions. When you switch tothe administrator account (using su - <admin account name>) from your ownaccount, or another account, you will only have the permissions set for the originalaccount.

If you want to have administrator permissions, then type the following commands in the Xtermwindow:

$ id # check your user id

$ su - <admin account name> # supply a password

$ ^D # EOF character to stop another

# SAA application appearing

16.2 Essential System MaintenanceIntroduction

For Alliance Access to function in an efficient and trouble-free manner, the AllianceAdministrator is required to perform certain essential tasks.



16.2.1 At the Start of the Business Day

Description

Before Alliance Access and Alliance Workstation operators can sign on for normal operations,the Alliance Administrator should carry out the tasks that follow.

Task Tip

Start the Alliance Access servers From the Alliance menu (in the SystemAdministration application).

16.2.2 During the Business Day

Description

The Alliance Administrator should carry out these tasks during the day:

Task Tip

If you have to investigate a problem, use the EventJournal application to scrutinise system events andalarms, and to view the audit trail of interactiverequests and responses.

Use the Message File application to view thecontents of messages transferred and theirassociated transmission history.

See the System Management Guide

React to any unknown alarms, for example "DiskSpace Too Low".

When you see this alarm, the Alliance Accesssystem is about to shut down.

Use the Monitoring application or the UNIXcommand df to check the disk space parameters.

16.2.3 At the End of the Business Day

Description

The Systems Administrator is responsible for the tasks that follow at the end of the day.

Task Tip

Search the Event Journal for any untreated alarmsand for Security Events. Treat as appropriate.

See the Daily Operations Guide

Archive and back up (with remove option)messages and events to free disk space for thedatabase. These tasks can be automated using theschedule facility.

Free space can be checked using the Monitoringapplication (System Resources - Disk Space).


General System Maintenance


16.2.4 At the End of the Week

Description

The Systems Administrator is responsible for the tasks that follow at regular intervals (forexample, at the end of each week).

Note Only messages and events which are from the previous day can be archived.When you encounter messages which still appear as live (from the previous day)investigate these using the Message File application.

Task Tip

If you are not archiving on a daily basis, use theEvent Journal application to archive the EventJournal. This can be automated (for example,weekly) using the schedule facility.


Use the Message File application to archive theMessage File. This can be automated using theschedule facility.


When appropriate, stop the Alliance Accessservers. This can be automated using the schedulefacility.

From the Alliance menu of the SystemAdministration application, the SystemManagement application, or through the UNIXcommand line with the script saa_system stop.

Use the System Management application to:

• back up and remove the Event Journal archives

• back up and remove the Message archives

• back up the Alliance Access database.




17 Managing UNIX Accounts

17.1 Alliance Administrator AccountOverview

Alliance Access provides and recognises only one UNIX user: a trusted administrator,responsible for system management functions outside of Alliance Access (for example,installation, housekeeping, running servers). This person is referred to as the 'Allianceadministrator' who operates using the dedicated UNIX account name given to the Allianceadministrator. The administrative functions described in this guide, available through the SystemAdministration application, are used exclusively by the Alliance administrator, when logged onas such. In fact, as soon as the Alliance administrator logs on to UNIX, the Alliance SystemAdministration application is started automatically.

The Alliance administrator user is set up during installation.

17.2 Security ConsiderationsOverview

The security of the Alliance Access software and database is ensured by the file permissionsassigned at installation time. This makes sure that:

• All files in the release tree can only be accessed from the Alliance Administrator account

• Most of the other executables can only be run from the Alliance Administrator account, withthe result that only the Alliance administrator can start the Alliance Access servers. Privilegedoperators may also stop or restart the system, using dedicated functions within the SystemManagement application.

Some executables (such as the saa_monitor or saa_manage tools) can be run by other UNIXaccounts, but require specific Alliance Access credentials.

• The files in the database can only be updated by the Alliance administrator or by the AllianceAccess servers at run time.

The following table lists the ownership and file permissions used for Alliance Access:

File Type Owner Group File Permission

data files all_adm alliance, or the defaultprimary group

rw- --- ---

executables all_adm alliance, or the defaultprimary group

rwx r-x r-x

Managing UNIX Accounts


17.3 The alliance_init FileDescription

From the definition of the environment variables $ALLIANCE and $ALLIANCE_DB, theinstallation script creates a file called alliance_init which is stored in the /usr/swa directory.This data file contains parameters which have been properly initialised to run Alliance Access,and is used every time an Alliance Access script is run.

Usage:alliance_init [-a] [-i <instance>] [-x] {-s | -S | -- -e <cmd> | <cmd> [<args>]}where:

-a specifies that the user is Alliance administrator

-i specifies the instance name

-x specifies use X mode for instance selection

-s specifies to only set the environment variables

-S outputs to standard output the exports of environment variables

-e specifies an external command, for example ksh

<cmd> is an Alliance Access command, for example start_server

<args> are optional arguments to the command.

17.4 Workstation IP Address CheckingDescription

The IP addresses of the remote machines that are permitted to connect to your Alliance Accessserver as Alliance workstations are configured using the saa_configconnection tool. For moreinformation, see "saa_configconnection" on page 226.

To enable the change, you have to stop and restart the Alliance Access servers.

17.5 The Instance Registration FileOverview

The details of all installed instances of Alliance Access are stored in a system file locatedat /usr/swa/insts.

For each installed instance of Alliance Access, this file contains the values for the:

• Alliance Access software release tree

• version release number

• type of Alliance product (for example, INTERFACE)

• name of the Alliance Administrator

• instance name

• location of the Alliance Access database



• instance comment.

Managing UNIX Accounts


18 Managing the Alliance Access ServersIntroduction

Alliance Access is designed around a client/server architecture. Typically, "servers" are acollection of processes that access a database and perform the background processing, while"clients" are applications that communicate with the servers.

This section describes the management of the Alliance Access servers, using functions whichthe Alliance administrator must perform using either the commands available from the SystemAdministration application or UNIX command line scripts.

Note These command scripts require the correct environment to be set, which isautomatically done when logging on as all_adm. However, if you want to carry outadministrator functions while logged on as "root", then you must run the scriptusing the following syntax:

. /usr/swa/alliance_init -s [-i <instance_name>]

The following commands are used (by the Alliance administrator) to manage the AllianceAccess servers:

• Start Alliance Servers

• Stop Alliance Servers

These two commands have their equivalent UNIX command line scripts:

• saa_system start

• saa_system stop

Note At the end of a normal operational day, a supervisor (or senior operator) can usethe Stop Alliance command in the System Management application to shut downthe servers.

Another related feature is the saa_system stop force script which may be used in extremecircumstances to force the termination of all Alliance Access server processes. For information,see "Starting and Stopping the Alliance Access Server" on page 232.

18.1 Starting the Alliance Access Servers

18.1.1 The "Start Alliance Servers" Command

18.1.1.1 Running the "Start Alliance Servers" Command

Description

The Start Alliance Servers command, from the System Administration application, is used(only by the Alliance Administrator) to start the Alliance Access servers (for example, at the startof the day or after system maintenance).

Note The Alliance Access servers MUST be running before any client application (suchas the Support application) can be started by an Alliance Access user. Therefore,no operator can sign on to Alliance Access until the servers are running.



To start the Alliance Access servers:

1. Log into UNIX as Alliance Administrator.

2. If more than one instance is installed on your system, then the Alliance ApplicationInstance Selection window appears. Select the required instance from the list pane. Themain window of the System Administration application appears.

3. Select Start Alliance Servers from the Alliance pull-down menu.

If the servers are not already running, then a shortcut menu appears prompting theadministrator to select a start mode for the servers:

• Operational, to perform operational tasks.

• Housekeeping, to perform maintenance and security tasks.

4. Select Extended Reporting, if required. For more information, see "Extended Reporting atServer Startup" on page 138.

5. If there is no active routing schema, then the servers cannot be started in Operationalmode. In such a case, the Housekeeping mode is invoked.

6. When the servers have started, and after several system messages, the followingconfirmation message appears:

Alliance has started

7. If there are no other tasks to perform, then select Exit from the File pull-down menu. Youare logged off from the Alliance Administrator account.

18.1.1.2 Considerations when Using the "Start Alliance Servers" Command

Overview

When the Start Alliance Servers command is run, the server processes are started in an orderthat respects interdependency between them. The script does not return control to the terminaluntil all server processes have successfully started, until a time-out value is reached, or an erroroccurs.

If there is no active routing schema, then the servers are started in Housekeeping mode.

Occasionally, some processes may fail to start and the following error conditions may indicatewhy the servers failed to start:

• Time-out value reached before the servers are ready.

• Some process failed to run.

• Some process terminated in error.

• A whole component failed to start.

Relevant errors can be found in:

• the System Administration window

• the event journal

• status_file (in $ALLIANCE_DB)

• logfile.<instance name> (in $TMPDIR or, if $TMPDIR is not defined on the system,in /var/tmp/alliance)

Managing the Alliance Access Servers


• errorfile.<instance name> (in $TMPDIR or, if $TMPDIR is not defined on the system,in /var/tmp/alliance)

The normal sequence of processes started is as follows:

1. BS_csys

2. BS_topc

3. BS_alarm

4. BS_rmq

5. BS_config

6. BS_search

7. Processes of all the other service components.

18.1.1.3 Extended Reporting at Server Startup

Overview

During startup of the Alliance Access servers, all processing actions are recorded in a log filecalled status_file. This information can also be displayed in the System Administrationapplication window. This optional feature helps you interpret problems which can occur whenthe system is started. The log file can be transmitted to Support. It is located in$ALLIANCE_DB.

Extended Reporting can be turned on or off when starting the servers. The default setting is off.This means that it must be turned on explicitly when starting the servers.

To turn Extended Reporting on and off:

1. Select Start Alliance Servers from the Alliance menu in the System Administrationapplication. The Alliance System Administration: Start Servers window appears.

2. Click Yes from the Extended Reporting menu button. Extended reporting is displayed inthe main window.

18.1.1.4 Extended Reporting Output Format

What is displayed by Extended Reporting

If Extended Reporting is turned on, then the following items are displayed:

• If the database is being started or if the Alliance Access bootstrap is running, then this isdisplayed.

• For each server that is started, the server name, an indication that the server is starting, andthe result ("Ready" or "Failed") is displayed. If a server fails to start, then the event related tothis failure is also displayed.



Example:

Server MXS : Starting... Ready

• If recovery is invoked, then the following is displayed for any change in the recoveryprocess: which entity, message partner, and so on, is recovering and, where relevant, acounter showing how many records have been recovered, whether any messages are stillbeing processed, and the keyfield of the record being processed. All this helps to determinewhich record caused the error.

• If a rollback, or roll forward is carried out, then this is displayed.

• If a server does not start because of database corruption, then the exact entity (and ifpossible the exact record) is displayed.

• Possible solutions to problems that may arise are displayed. Depending on the situation, awarning is issued for the user to make a backup before trying to solve the problem.

18.1.2 The saa_system start Script

Overview

The saa_system start script is used to start the Alliance Access servers. It succeeds only if thesystem is not running already. The Alliance Access servers must be running before any clientapplication can be started by an Alliance Access user.

The Alliance Access servers may also be started from the UNIX command line, by runningeither of the following commands:

saa_system start housekeepingsaa_system start operational

18.1.2.1 Starting the Servers

To start the Alliance Access servers:

1. Log into UNIX as the Alliance Administrator.

2. Run the following command:

saa_system start

3. Log off from the Alliance Administrator account.

When the above command is run, the server processes are started in an order that respectsinterdependencies between them. The script does not return control to the terminal (Thecommand prompt does not appear) until either all server processes have successfully started ora time-out value is reached.

For information about how to display errors, see "Considerations when Using the "Start AllianceServers" Command" on page 137.

Related alarms

Following initial software installation, one alarm message per live destination is displayed, like:

********************* ALARM ********************SUBSET DEFINITION: 'XXXX': INITIALISED TO SYSTEM DEFAULT



Such alarms, which are logged also in the Event Journal as "severe" events, result from the factthat the licensed destinations do not yet have delivery subsets defined for them in AllianceAccess.

18.1.2.2 Starting the Servers in Operational or Housekeeping Mode

Housekeeping mode

To start the servers in Housekeeping mode (to perform maintenance and security tasks), usethe following command:

saa_system start housekeeping

Operational mode

To start the servers in Operational mode (to perform operational tasks), use the followingcommand:

saa_system start operational

18.1.3 Checking that the Servers are Running

To determine which Alliance Access processes are currently running:

1. Log into UNIX as Alliance Administrator. The main window of the System Administrationapplication is displayed (you may have to select an instance first).

2. Select Xterm from the OS Configuration pull-down menu.

3. When the UNIX prompt ($) is displayed in a new window, type:

ps -ef | grep $ALLIANCE | grep -v grep

All Alliance Access processes currently running are listed in the Xterm window.

Note The technique used to start processes is to spawn them as children of BS_csys.The consequence is that the ps command described above may show more thanone BS_csys process running for a period of a few seconds. These duplicateprocesses change into genuine processes in due course. Where BS_csys is notrunning, then the Alliance Access servers are not running.

18.2 Stopping the Alliance Access Servers

18.2.1 Shutdown of Alliance Access

Description

The usual way to shut down the Alliance Access servers is by using the facilities provided withinthe System Management application. For details, see the System Management Guide.

A shutdown of the Alliance Access servers can be initiated automatically by Alliance Access.For example either when a server (that has updated a database) crashes or when the system isrunning out of disk space.

However, in certain circumstances the Alliance administrator may want to shut down theAlliance Access servers (for example, for urgent system maintenance) with the use of the StopAlliance Servers command that is available from the System Administration application.



In urgent situations, the Alliance administrator may also force the immediate termination of allAlliance Access servers and processes using the saa_system stop force command. Fordetails, see "To stop the server" on page 233.

The following table details the various disk space parameters that can be set:

Parameter Description Default

Frequency The interval in seconds (in multiples of 60) atwhich disk space is checked.

300

Shutdown - MB The absolute minimum free disk space (inMB) that must be available on the diskcontaining the database. A system shutdownis initiated if the free disk space available forthe database falls below this value. Thesystem automatically adds (for recoverypurposes) the size of the largest database filestored in the database, plus the size of thedatabase index file, to the value specified.

The frequency with which this parameter ischecked is set by the Disk Space -Frequency parameter.

1000

Shutdown - Release Dir Shut down Alliance Access when availablespace on the disk of the source tree is lessthan this value (in KB).

20000

Warning - MB A warning is issued when the available space(in MB) on the disk of the database is lessthan value.

In addition, extra space (equal to the currentsize of the largest database file) is added tothis value.

5000

Warning - Release Dir A warning is issued when the available space(in KB) on the disk of the source tree is lessthan this value.

50000

Warning - Printer Spool A warning is issued when the available spaceon the /tmp disk is less than this value (inKB).

When the threshold is passed, an alarm issent to all operators who are signed on towarn them that the available disk space islow.

Note that if the disk space available to the "/tmp" directory is less than the value specifiedhere, you will receive warnings about lack ofdisk space.

10000

These parameters are set within the System Management application of Alliance Access. Whena warning of disk space being low has been given, further warnings are generated every 10cycles of disk checking.

If the system shuts down due to insufficient disk space, then you may create additional free diskspace by removing core files and by backing up message and event archives. The archives canthen be removed from the system.

Use the following command to remove core files:

find / -name core -exec rm {} \;In addition to the above parameters, a continuous background process also monitors the use ofpaging space. If the available paging space is found to be dangerously low, then a warning



message will pop up that to inform users to quit Alliance Access. If this message appears, thenall operators must sign off immediately from Alliance Access and you are advised to shut downthe servers.

When the servers have been restarted, the normal functions of Alliance Access are sufficient toenable users to sign on again and continue working.

18.2.2 The "Stop Alliance Servers" Command

Overview

In most circumstances, a shutdown of the Alliance Access servers is initiated from the SystemManagement application of Alliance Access, using the Stop Alliance command.

The Alliance Access servers may also be shut down by the Alliance administrator, as follows:

1. Log into UNIX as Alliance Administrator. After selecting from the instance selection window(if more than one instance is installed on your system), the main window of the SystemAdministration application will appear.

2. Select Stop Alliance Servers from the Alliance pull-down menu.

3. When the servers have stopped, you may perform any system maintenance activities thatrequire the servers to be stopped, or quit the System Administration application.

Description

The behaviour of Alliance Access, following a "stop servers" request, is the same regardless ofwho initiated the shutdown.

• All operators receive an alarm message, stating that the system is shutting down within aspecified period of time. This "grace period" (default is 120 seconds) is that specified by theShutdown "Delayed" parameter which can be configured within the System Managementapplication.

• During the grace period, the servers continue to function normally to allow users to completeany work.

• After the grace period has expired, the servers stop, one after another, in an order thatrespects inter-dependencies between them. HCI windows progressively start to hang up.

• Eventually, the BS_csys process is the only running server left, at which time the HCI itself iskilled.

The normal termination of processes is logged in the Event Journal.

Note When the system does not manage to stop all the servers within the time limitspecified by the Shutdown "Forced" parameter (default value is 240 seconds), a"forced shutdown" is then initiated. During a forced shutdown, processes are killedby BS_csys in an arbitrary order. This parameter is configurable within the SystemManagement application.

Processes terminated in this way are logged in the Event Journal by BS_csys, asif they had crashed.



18.2.3 The saa_system stop Script

Description

The saa_system stop script can be used to stop the Alliance Access servers.

In most circumstances, a shutdown of the Alliance Access servers is initiated within the SystemManagement application of Alliance Access, using the Stop Alliance command.

The Alliance Access servers may also be shut down from the UNIX command line, by runningthe command:

saa_system stopThe behaviour of Alliance Access after the shutdown request is as described in "Description" onpage 142.

18.2.4 The saa_system stop force Script

Overview

The Alliance administrator must resort to the use of the saa_system stop force script, whenand only when either the system must be stopped urgently or the normal shutdown procedurefailed to complete.

To kill the Alliance Access servers:

1. Log into UNIX as Alliance Administrator. After you make your selection from the instanceselection window (if more than one instance is installed on your system), the main windowof the System Administration application appears.

2. Select the Xterm command from the OS Configuration pull-down menu.

3. When the UNIX prompt is displayed in a new window, enter the command:

saa_system stop force

Description

After this command, all Alliance Access server processes are killed in an arbitrary manner.

Note Since this command is issued at the UNIX shell level, the kill action is not recordedin the Event Journal.

When the Alliance Access servers are started next, all database files that were open in "write"mode at the time the saa_system stop force script was run are recovered automatically.

The kill operation takes about one minute to complete. If the kill is successful, then the UNIXcommand:

ps -ef | grep $ALLIANCE | grep -v grepmust not show the BS_csys process.



18.3 Running Selected Program Scripts followingServer Start and Stop

Description

You can specify two executables which may be invoked when the Alliance Access servers areeither started or stopped.

These executables must be present in the script sub-directory of usrdata beneath yourinstallation directory, and must be declared in:

• saa_starthook

• saa_stophook

Scheduling the automatic starting and stopping of the Alliance Access servers is described inthe System Management Guide.

Note The post processor scripts must not contain arguments or quotes. The Allianceadministrator (typically all_adm) must own the scripts. The scripts cannot bewriteable for group or for world (use 0755 for example).

18.4 Monitoring ProcessesIntroduction

The Monitoring application (available from the Access Control application) displays dynamicdata for all servers, and applications that are currently operating in the Alliance Accessenvironment.

Processes are divided into server components, which process and deliver data to applicationsand application components.

18.4.1 Displaying the Processes

To display the processes:

1. Run the Monitoring application.

2. If the Processes window does not appear, then select Processes from the View Modemenu.

You can select to display all processes, or only those in an exceptional state (crashed ortimed-out).



18.4.2 Viewing the Status of a Process

Displaying the processes:

• Timed-out

The application did not receive input within the time-out period and has terminatedaccordingly. This is an exceptional state.

• Running

The application is available. This is the normal process state. Some processes may godirectly into this state without initialising.

• Crashed

The application or server has either crashed or the user has quit or aborted the process. Thisis an exceptional state.

For more information, see "Session Status Pane" in the Daily Operations Guide.

18.4.3 Stopping a Process

Description

Periodically, you may be working with a process which, for some reason, must be terminated.Such a process (for example) can be an application within a component whose response timehas become unsatisfactory due to a possible system overload.

Note Selecting and stopping a component process terminates the entire componentregardless of the number of sub-applications that may be running. For example,stopping the Message Preparation component would stop all Message Preparationapplications currently running.

To stop a selected process:

1. Select the Monitoring application to display a list of all active processes.

2. Select the process (or processes) that you want to stop.

3. From the Action menu, select Processes. The default "action" for processes is to stop theoperation of the selected process.

4. Select Action | Processes | Stop.

18.4.4 Locating and Identifying a Process

Description

The Processes list displays a number of fields to identify a particular process in the system. Usethese attributes to locate and identify the process that you want to stop.

• Description

Short textual description of the application, or server currently running.



• Started By

The name of the operator who is currently using the application. The value of this data field isalways equal to "SYSTEM" for servers.

• PID

Process IDentification number. Each process that is currently active within the UNIXoperating environment is given a unique PID.

• TID

The thread ID of a logical process within a process.

• Display

The variable identifies the host name on which the X server is running and the X terminalwindow that is used to display the application. This host name is not necessarily the machineon which the host system or client process is running.

• Status

The current operational state of the process.



19 Backing Up DataIntroduction

Data generated by Alliance Access is stored in a database and archives. It is important to makebackups of this data. This can be done in either of the following ways:

• by using the Backup/Restore command from the System Management application (throughthe Access Control application, using an Alliance Workstation).

• by typing a command from a Command Prompt window. For detailed instructions, see"saa_system" on page 227.

SWIFT recommends to:

• back up (and remove) the Message File and Event Journal archives every week

• perform a database backup on a daily basis

• take a full system backup at least weekly, or more frequently if required.

Important To take a full system backup, all applications on the system must be stopped.This includes stopping the Alliance Access bootstrap service and the database,using the saa_bootstrap stop command.

Alliance Access maintains all of its software in a directory defined by the environment variable$ALLIANCE.

To ensure operational security and efficient data recovery in the event of a major problem, allAlliance Access data AND associated system configuration data must be backed upperiodically. This section describes the procedures used to back up the Alliance Access data, aswell as the complete system.

The frequency with which backups are taken, and the number of historic copies retained beforethe oldest is overwritten, is for individual organisations to decide according to local requirementsfor operational security. The main reason for making regular backups is to ensure minimaldowntime in the event of disaster. It is therefore highly recommended that you implementregular backup procedures to protect against equipment failure.

19.1 Database BackupDescription

Alliance Access configuration data (for example, operator definitions, profiles, routing rules,RMA authorisations, and so on) is maintained in the $ALLIANCE/database directory. Thecollection of all such data is referred to as the Alliance Access database.

All message and event data is stored in the database and cannot be amended once they arearchived. For information about archiving, see the Daily Operations Guide.

Note An Alliance Access database backup does not include messages or events.

Backing Up Data


19.2 Archive BackupDescription

Archives of the Message File and Event Journal are kept in the database until they are backedup.

Only the archive backups that were created using the Backup/Restore function are compatiblebetween versions of Alliance Access.

Note You cannot create backups of archives that were created using Alliance Access6.0 or earlier.

Management of backup files

A backup is the only way to free the space that the archives use. If you do not have to use thearchives on a daily basis, then you are advised to make regular backups of the archives andremove the original archives. This action makes disk space available and enables data to berecovered efficiently in the event of a major problem, such as, disk failure.

19.3 Temporary Storage Directory for BackupOverview

If one of the environment variables $TMP, $TMPDIR or $TEMP are set, it will be used asstorage for temporary files created during a backup.

You can check the path name of these variables by issuing the following command:

echo "TMP=$TMP" && echo "TMPDIR=$TMPDIR" && echo "TEMP=$TEMP"If none of the variables are set, then backup system will revert to using the /tmp directory.

You can check the available space on this file system by typing:

df /tmp command

To create a temporary directory:

1. Open the System Administration window.

2. Check the name of your Alliance Access instance in the Instance menu.

3. Open an Xterm window from the OS Configuration menu.

4. Change to the home directory of all_adm (normally /home/all_adm) with the cd command.

5. Use the command ls -al to confirm that the file .swa.*instance name.rc exists.Replace *instance name with the instance name obtained in step 2 (bydefault, .swa.init.rc).

If this file does not exist, create it using the instance name from step 2.

6. Open the file and add the following line:

export TMPDIR=/alliance/tmp



Note If you select not to create this entry, temporary files will populate the /var/tmp and /tmp directories during operation and backups. These files must bedeleted manually during maintenance periods. An exception is the /var/tmp/alliance directory, which contains important log files and is maintainedby Alliance Access.

7. Save the file and quit the System Administration window.

19.4 Performing a Manual Backup of ArchivesIntroduction

You can create a backup of archives manually using the System Management application.

Location of Archive backup files

The following are the default locations of an archive backup file:

• Event Journal archive: $ALLIANCE/usrdata/backup/eja

• Message archive: $ALLIANCE/usrdata/backup/mfa

Where $ALLIANCE is the directory in which Alliance Access is installed.

If you select a location different from the default location, then the new location is not recordedpermanently.

Status of the archives

The archives that appear in the Available list in the Alliance Backup window can have thefollowing states:

Status Description

Ready Alliance Access has created an archive successfully, and the archive isready to be backed up.

Done Alliance Access has created a backup of the archive successfully.

An archive has been successfully restored from a backup.

Before you begin

You do not have to stop the Alliance Access servers before you start this procedure.

To perform a manual backup of archives:

1. Run the System Management application.

2. From the File menu, select Backup.

The Backup Alliance window appears.

3. Click one of the following tabs:

• Journal Archive

• Message Archive

4. In the Backup operating mode field, select Manual.

Backing Up Data


5. Click Backup .

The Alliance Backup window appears.

6. The Backup Directory field specifies the location where Alliance Access stores the backupfile. If required, click ... to specify a different location.

If you intend to copy the backup to tape or a hard disk, then make a note of this directorypath for future reference.

7. In the Operation panel, select one of the following:

• Backup, to create a backup of the archive, without deleting the archive.

• Backup and Remove, to create a backup of the archive, and then delete the originalarchive after the backup is complete.

• Remove, to delete an archive that has the status Done, without creating a backup for thearchive.

8. Select the archives to back up, by clicking the transfer arrows to move the archivesbetween the Available pane and the Selected pane.

Note An archive must have the status of Ready or Done, before you can create abackup for it.

9. Click OK .

If the Alliance Access creates the backup file successfully, then it displays a confirmationmessage. Click OK in the confirmation dialog box.

The selected archives are backed up, or removed according to your selection.



Names of archive backup files

Alliance Access creates a directory for every archive backup, and uses the following namingconvention for the directory:

<Entity>_<ArchiveName><Entity>_<ArchiveName1_ArchiveNameN>Where:

• <Entity> represents the type of item being archived:

– JRAR, for backups of Event Journal archives

– MEAR, for backups of Message File archives

• ArchiveName represents the name of the archive that Alliance Access backed up.

Examples of directory names:

MEAR_20070617JRAR_20070610_20070614

19.5 Performing a Manual Backup of the DatabaseIntroduction

You can create a backup of the Alliance Access database manually using the SystemManagement application.

Location of database backup files

The default location of database backup files is $ALLIANCE/usrdata/backup/db.

Where $ALLIANCE is the directory in which Alliance Access is installed.

If you select a location different from the default location, then the new location is not recordedpermanently.

Before you begin

You do not have to stop the Alliance Access servers before you start this procedure.

To perform a manual backup of the database:


2. From the File menu, select Backup.

The Backup Alliance window appears.

3. Click the Database tab.

4. In the Backup operating mode field, select Manual.

5. Click Backup .

The Alliance Backup window appears.

Backing Up Data


6. The Backup Directory field specifies the location where Alliance Access creates thedirectory for the backup. If required, click ... to specify a different location.

If you intend to copy the backup to tape or a hard disk, then make a note of this directorypath for future reference.

7. Click OK .

If the Alliance Access creates the backup file successfully, then it displays a confirmationmessage. Click OK in the confirmation dialog box.

Following the successful backup of a database, Alliance Access writes the version number ofthe Alliance instance and the current date in an information file called backup.info. AllianceAccess stores backup.info in the same directory as the backup. If the backup process fails,then Alliance Access deletes the database backup directory and any files in it.

Alliance Access stores a maximum of two backups. If two backups exist at the time of backup,then Alliance Access shows a warning message and prompts you to confirm to remove theoldest backup. If you click No , then it does not remove the oldest backup. If you click Yes , thenit removes the oldest backup and logs an event.

Naming convention for backup directories

Alliance Access creates a directory for every database backup, and uses the following namingconvention for the directory:

YYYYMMDDTHHMMSS_SAA_DATA_BACKUPWhere YYYYMMDDTHHMMSS represents the local time on the server when the backup wascreated.

Examples of directory names:

20070426T120000_SAA_DATA_BACKUP20070426T220000_SAA_DATA_BACKUP



19.6 Scheduling Automatic BackupsOverview

It is possible to schedule automated backups of the database and of archives. The AllianceBackup/Restore application starts backups according to the schedule defined. For moreinformation, see "Configuring the Calendar and Scheduling Processes" in the SystemManagement Guide.

Backup schedule exceptions

If a backup or restore is running at the time the backup is scheduled, the scheduled backup isnot performed and an event is logged in the Event Journal. Also, scheduled backup does nottake a backup of the archives that are either under construction (that is, the archive process isrunning), or being consulted.

19.7 Following a BackupDescription

The Backup/Restore application creates backup files and places them in a backup directory. Byusing the browse function you can back up to any device with a drive designation on yourmachine. It is up to you to decide what you do with the backup files. They can be copied to tapeor a hard disk. Once created, store your backups in a safe location, according to yourinstitution's security procedures.

Backing Up Data


20 Restoring DataIntroduction

You can restore archived information from a backup in either of the following ways:

• by using the Backup/Restore command from the System Management application (throughthe Access Control application, using an Alliance workstation). This can only be used torestore archive backups.

• by typing a command from an X-term (from the OS Configuration menu in the SystemAdministration window).

For detailed instructions, see:

– "saa_system" on page 227 to restore archive backups

– "saa_dbrestore" on page 274 to restore database backups.

You can restore:

• Event Journal archives

• Message File archives

• Some or all of the configuration data

For more details, see "Backing Up and Restoring" in the Daily Operations Guide.

20.1 Restoring an Archive BackupOverview

The restore procedure imports the contents of an archive backup file into the Alliance Accessdatabase. The backup archive file remains in the backup directory.

If backed up archives of Journal or Message entries are needed (for example, for an audit), thenyou can restore them from the backup files, using the Backup/Restore application or thecommand line tools.

You can also restore archives from backup using the System Management application, which isaccessible through Alliance Workstation.

Note On UNIX, if you are restoring from a backup made with Alliance Access 6.0, thenyou must use the saa_system archive restoretar command.

Restoring Telex and Fax messages

You can restore Telex and Fax messages processed with releases earlier than release 7.0.However, due to database structural changes required to remove Telex and Fax functionalitiesfor release 7.0, the following fields are not restored:

• for Telex messages: Telex Number, Answerback, and Network application

• for Fax messages: Fax Number, CUI, and Network application.



To restore an archive backup:


2. From the File menu, select Restore.

The System Management - Restore window appears.

3. Select one of the following types of archive to restore:

• Journal Archive

• Message Archive

4. Click Restore... .

The Alliance Restore window appears.

The Entity field displays the type of archive backup to be restored. You cannot edit thisfield.

5. The Backup Directory field contains the current path name of the archive to be restored. Ifrequired, select another path by clicking ... .

6. Click the transfer arrows to move the archives between the Available pane and theSelected pane.

7. Click OK to restore the selected archives.

Restoring Data


If the archive is restored successfully, then a confirmation message appears. Click OK .

20.2 Restoring the Alliance Access DatabaseWhen to restore

You can restore the content of the database if it becomes corrupt, possibly because of a partialor complete disk failure.

If such a failure occurs, you may have to reinstall the Alliance Access software before you canrestore the database.

Important If you have to restore from a backup, then you lose all the changes that you havemade to your system since this backup. Therefore, you must create backupsfrequently.

You cannot restore a database from a backup that was created with a previousrelease of Alliance Access.

Location to which the database is restored

When you restore the database, Alliance Access automatically restores it to the correct path,even if the path is different from the one that the database was backed up from originally. Thisenables you to restore the database to a different installation of Alliance Access on a differentcomputer, or disk.

Restore Sets

You can restore either the complete contents of the database or just a set of related data, whichis called a Restore Set. If you restore the complete database to the same system from which thedatabase backup was created, then the Message File and Event Journal entries are overwrittenduring the restore.

You can use the Restore Set option to restore a set of related data, to the exclusion of all otherdata. For example, to copy configuration files and security definitions from a fully configuredprimary site onto a secondary or backup site. To restore the database completely, select all theRestore Sets.

Before restoring data, you can check the consistency of the Restore Set with your currentdatabase.

For more information, see "Restore Sets" on page 158.

Disabling connectivity and ADK components

When restoring the Alliance Access database, it is possible to disable automatically theconnectivity with different networks, back-office applications, and printers, as well as ADKcomponents. If the restored system is used as a cold backup system, then you must disable thisconnectivity.

Licence verification

When backing up the complete Alliance Access database, the Backup application also backs uplicensing. The Backup/Restore application verifies that the licensed options on the targetmachine are the same as those on the backup machine. This ensures that the licensed optionson the test system and live system are the same. If a difference is found, a warning is given andthe restore operation stopped.



20.2.1 Overview of Restoration Process

Database restoration

The restoration of the Alliance Access database involves the following tasks:

1. Run a consistency check on the data that you are restoring.


3. Restore the data from the backup file (that is, importing it into the database).

4. Run the saa_configconnection tool to import the Certificate and Private Key. For moreinformation, see "saa_configconnection" on page 226.

If you do not know the password used to encrypt the file containing the Private Key(created by the swrpc_keytool), then you must run swrpc_keytool tool first.

5. Start the Alliance Access servers.

The Backup/Restore application keeps a catalogue of entities that are validated whenselectively restored (for example, Units, Operators, Keywords, Exit Points and Queues, and soon).

Synchronisation between Live and Test Alliance Access systems

Some users maintain both "live" and "test" systems. The test systems, which are usuallybackups of the live system, are used to prove that a new release functions correctly or tovalidate a new configuration before it is deployed for live operations.

To provide users with a less error-prone method of selectively restoring a part of the databaseonto the live machine, Alliance Access provides verification on each selected Restore Set. Theinformation used to verify that the restored data entities is catalogued during the backupprocess.

You can test the following information before deploying it in a live system:

• routing information

• correspondent information

• operator and profile definitions

Following each validation, and before data in the Restore Set is restored, an overview appearsshowing the results for each data entity. For example:

The following entities were checked for consistency:1.Operators no inconsistencies were found.2.Keywords the following inconsistencies were found: keyword xyz does not exist on the backup-----Detailed information can be found in the following file:/tmp/<logfile>

Restoring Data


Note When restoring data from a database backup, the Restore application verifies thatthe licensed options on the target machine are the same as those on the machinewhere the backup was made. For destinations, the Backup/Restore applicationdoes not check the Test and Training destinations that the users added). If adifference is found, then a warning appears, and the user must stop the restoreoperation.

You cannot restore archives or the database from a network drive.

20.2.2 Running a Consistency Check

Description

The Restore Set option restores a set of related data, to the exclusion of all other data. Forexample, you can use this option to copy configuration files from a fully configured primary siteonto a secondary or backup site.

Before restoring data, you can check the consistency of the Restore Set, with your currentdatabase, using the saa_dbrestore command. For command location and syntax, see"saa_dbrestore" on page 274.

20.2.3 Restoring the Database

Permissions required

You need the Alliance Access Administrator account to restore a database backup.

Before you begin

• Before making a partial restore of a database from another machine, make sure that theAlliance instance on the new machine was built from a full restore of the same database.

• If required, run a consistency check on the Restore Set. For more information, see "Runninga Consistency Check" on page 158.

• If you have database recovery activated, then you must deactivate it, as described in"Deactivate the Database Recovery Mode" on page 180.

• Stop the Alliance Access servers.

Restore the database

You restore the database using the saa_dbrestore command. For command location andsyntax, see "saa_dbrestore" on page 274.

20.2.4 Restore Sets

ADK storage

If option 99:TOOLKIT RUN-TIME is licensed, information specific to the ADK applications isrestored when this Restore Set is selected.

If the ADK Storage Restore Set is selected, the<Alliance installation directory>/data/ADK_DIR directory and all its sub-directories arerestored.



Correspondent

The Correspondents information is restored when this Restore Set is selected.

Operator

When you restore the Operator Restore Set, Alliance Access imports the operator definitions,entitlements, and permissions into the database.

When restoring the Operator Restore Set, the consistency check ensures that no conflicts existin the definitions. For Units, the validation is to ensure that they exist. There is no check toensure that their definition is the same.

If there is an inconsistency between units, then the restore is not allowed.

When the consistency check is complete and before the restore is performed, a report showsthe validated entities and their level of consistency. The location of a detailed log file is providedat the end of the overview.

RMA Authorisations

The RMA authorisations are restored when this Restore Set is selected.

Routing information

When selecting the Routing Information Restore Set, the following definitions are restored and averification is made that the entities exist:

• operator names

• keywords

• exit points

• units

• queues

There is no validation of the contents of these records. When validation is completed and beforethe restore is performed, an overview showing all validated entities and consistency information.The location of a detailed log file is provided at the end of the overview.

If an inconsistency is detected between Queues, Exit Points, Units, and Keywords, the restoreis not allowed. If other inconsistencies are detected (operator names), an option to continue orcancel the restore operation is provided, with a warning about possible inconsistencies.

The following is also restored when this Restore Set is selected:

• keyword information

• routing schemas

• routing rules

• queues.

SWIFT

To restore destination details, logical terminals, and own destinations.

When the SWIFT Restore Set is selected, you can also specify whether information concerningSWIFTNet connections must be restored.

Restoring Data


After a restore, if an LT uses a specific Authoriser DN that no longer exists, then you mustassign another SWIFTNet connection to the LT, or update the SWIFTNet connection assignedto the LT.

SWIFTNet Interface Restore Set

To restore the emission and reception profiles.

When restoring the SWIFTNet Interface Restore Set, you can also select whether theSWIFTNet connection information must be restored.



21 Managing Disk SpaceIntroduction

Alliance Access monitors the different parameters related to available disk space. Theseparameters are listed in the following section and can be updated using the SystemManagement application. The most critical parameter ensures that there is always enough diskspace available for Alliance to take a copy of the largest file of the database (for archiving andrecovery purposes). The Alliance Access servers will go down if these criteria are not met.

Typically the sizes of the message and event journals will rapidly reach high values if backup (ofthe message file and the event journal) is not performed on a regular basis.

If archiving and backup of messages and events is not done regularly, then the available diskspace decreases. You can only free disk space when archives are backed up and removed.

21.1 Monitoring Available Disk SpaceDescription

Applications such as the Event Journal and the Message File applications are continuallyadding new records in the database, which consume the available disk space. It is, therefore,necessary to perform archiving and backup operations to make sure the disk space iscontinually available to other applications.

The system resource display provides a parameter (Disk Space) which enables you to monitorthe available disk space for the database at any given time. Exceptional events are defined formany object classes monitored in the Monitoring application. For example, the Disk Spaceparameter is considered to be in the exceptional state if the free space is less than the minimumvalue specified by the Disk Space configuration parameter Warning - MB. For moreinformation about Disk Space parameters, see the System Management Guide.

21.2 Modifying Disk Space ParametersIntroduction

There are a number of disk space parameters set by default.

To modify disk space parameters:


2. If the Configuration view is not displayed, then select Configuration from the View menu.

3. Look for the parameters with class 'Disk Space' and double-click the parameter that youwant to modify.

Fore information about the parameters available, see the System Management Guide.

Managing Disk Space


21.3 System ResourcesDescription

The Monitoring application provides a Disk Space parameter which enables you to monitor theavailable disk space and system archiving. The parameter indicates the amount of spacecurrently available in the database.

The available disk space can also be obtained using the df UNIX command.

This command reports: total file system sizes, amount used and amount available (in KB) aswell as '% capacity' used. Any file system reported as nearing capacity should be investigatedso as to free up disk space.

21.4 How To Recover Disk SpaceTo recover disk space:

1. Remove unwanted files from the system (for example: Core dump files, old files held inprint queues, and so on).

2. Perform regular archiving of the messages and events.

3. Clean up archives using the Backup and Remove option in the System Managementapplication.

21.5 Backing Up the Instance Registration FileDescription

Use these commands to copy the directory containing the instance registration file to an archivefile in a suitable directory:

su root #provide password

cd /usrtar cvpf <target directory>/<archive file> swa/*The instance registration file can be identified by its title 'insts'.



22 Managing the Database

22.1 Getting Information about the Alliance AccessDatabase

Introduction

The saa_dbinfo tool provides the following information:

• version information about the database

• initialisation parameters

• current database sessions

• tablespace information

• whether the redo log files are correctly sized and reside on disks with adequate performance

• diagnostics reports for specific time periods

• assessment information about database performance with greater/smaller available physicalmemory (RAM).

Prerequisites

The tool must be run from the Alliance Access Administrator account.

The database must be running.

Procedure

1. Log on to the machine where Alliance Access is installed.

2. From the System Administration application, select Xterm from the OS Configurationmenu.

3. Enter the saa_dbinfo command.

For command location and syntax, see "saa_dbinfo" on page 272.

The tool provides, for the period specified, the available hourly diagnostic information generatedby the database engine.

22.2 Checking the Alliance Access DatabasePurpose

Verifies the integrity (absence of unauthorised updates) of the Alliance Access database. Youcan check the whole database, including the daily tables, or just the static (non-daily) tables.

Procedure



Managing the Database


3. Enter the saa_system dbintegrity command.

For command location and syntax, see "saa_system" on page 284.

22.3 Configuring the Embedded DatabasePurpose

The saa_dbconfig command provides the following facilities:

• related to the tablespaces

– display the current location, allocated size and usage, of all the tablespaces or for aspecific tablespace

– change the location of a specific tablespace

– change the size of a tablespace, to either a specific size or to its minimum required size

– reorganise a tablespace to reclaim unused space and resize it to its minimum requiredsize

• related to the redo log files

– display the current location and size of the redo log files

– move all the redo log files to a different location and resize them to the specified size

• related to the memory allocated to the database

– display or change the amount of memory allocated

Note This command starts the database of the Alliance Access instance if it is notalready running.

Explanation of terms

• Tablespace

A tablespace groups database entities in data files.

• Redo log file

A set of files that protect altered database data in memory that has not been written to thedata files.

Prerequisites

The command must be run by the Alliance Access Administrator account.

The Alliance Access Bootstrap service must be stopped.

The servers must be stopped, except in the case of saa_dbconfig -display.

Note You cannot use the saa_dbconfig command with a hosted databaseconfiguration.



Working with tablespaces



3. Enter the saa_dbconfig tablepsace command.

For command location and syntax, see "saa_dbconfig" on page 271.

Working with the redo log files



3. Enter the saa_dbconfig redolog command.


Note The original redo log files remain in the original directory.

Location of database files

The Location Journal Events and Location Messages configuration parameters can be usedto change the default location of the datafiles used to store Journal Events and Messages.

For more information, see "Classes of Configuration Parameters" in the System ManagementGuide.

Displaying and changing memory settings



3. Enter the saa_dbconfig command.


22.4 Backing Up the Alliance Access DatabasePurpose

The saa_system dbbackup command is used to back up the complete database of AllianceAccess.

Procedure



3. Enter the saa_system dbbackup command.




You must specify the directory where the backup is to be stored.

Note Alliance Access removes the oldest backup if more than two backups exist withinthe target backup directory.

22.5 The saa_bankquery ToolPurpose

The saa_bankquery tool provides access to the dedicated Alliance Access database enquiryand repair facility. The tool is used to verify and repair database entities. It can only be run bythe Alliance Administrator.

Prerequisites

Given the powerful nature of this tool, its use is protected by three passwords:

• the first password is the AIX password of the Alliance Administrator (needed initially to log onto the Alliance Administrator account to run saa_bankquery)

• the second password is that of any Alliance Access operator (for example, a supervisor) whohas been granted the specific entitlement, within Alliance Access, to run saa_bankquery

• the third password is a dedicated password that must be obtained from Support, asdescribed further.

When running the saa_bankquery tool for repair, the Alliance Access servers must not berunning.

Note An operator using One-Time Passwords cannot use the saa_bankquery tool.

22.5.1 Running saa_bankquery

Overview

The need to run the saa_bankquery tool implies that you have a serious problem that cannotbe resolved without assistance from SWIFT. If so, first contact Support and be ready to followthe procedure described further.

To run saa_bankquery:

1. Log on as Alliance Administrator to the machine where Alliance Access is installed.


3. Enter the saa_bankquery command.

For command location and syntax, see "saa_bankquery" on page 270.

You are prompted to enter the name and password of a valid Alliance Access operator.This operator must have been granted the entitlement to use saa_bankquery within theAccess Control application of Alliance Access. This entitlement is granted automatically tothe default Supervisor and SuperKey profiles. Assigning this entitlement to other operatorsrequires the approval of both security officers.



4. When prompted, enter a valid Alliance Access operator nickname and the associatedpassword.

The saa_bankquery tool then generates a "session ID" which you must communicate (byphone) to Support. A message is displayed, like:

*** The ID to be used today is "01 SAAGBEBB B04D035F REL6200".ZERO ONESIERRA ALPHA ALPHA GOLF BRAVO ECHO BRAVO BRAVOBRAVO ZERO FOUR DELTA ZERO THREE FIVE FOXTROTROMEO ECHO LIMA SIX TWO ZERO ZEROPlease contact SWIFT customer support for the password

5. Inform Support of the ID shown on the screen. In return, Support informs you of a specialpassword, based on the ID you have provided. You need this password to runsaa_bankquery and it is only valid for one saa_bankquery session.

6. When prompted, enter the one-time password, as provided by Support, intosaa_bankquery.

When using saa_bankquery, Support can guide you as to the commands to enter toinvestigate and resolve your problem. Be ready to read out the relevant responses to eachcommand from the screen.

7. To terminate the execution of saa_bankquery, type:

qThis quits saa_bankquery and returns control back to the Xterm window.



23 Database Recovery

23.1 About Database RecoveryIntroduction

The relational database of Alliance Access can be configured to enhance protection againstmedia failures such as a disk crash or datafile loss.

Database recovery provides functionality that allows an Alliance Access administrator to recoverthe database content, including "live" messages and events. The functionality is subject to thelicence option 14:DATABASE RECOVERY.

Once activated, database recovery maintains ready-to-use backups of database updates onseparate disks (mirror and backup disk). In case of a media failure resulting in the loss of thedatabase content, database recovery provides a single command to restore the database fromthe data available on the mirror and backup disks, including "live" messages and events.

Two types of database recovery are available:

• Full database recovery

The full database content is restored. This requires the availability of the full mirror andbackup disk data. In this scenario, only synchronous replication of the mirror and backupdisks is allowed.

• Partial database recovery

This option must be used when the recovery data set is not guaranteed to be consistent, thatis, typically when it is maintained on a remote site through an asynchronous replication froma primary site. The "partial" recovery restores the database to a consistent state, but possiblywithout the last updates done on the primary site (before switching to the remote site). Anautomatic repair of the recovered database is performed (to prevent duplicate transactions).

For more information, see "Repairing Messages" on page 176.

The main database recovery functions are:

• configure the database for enhanced resiliency, by defining additional mirror and backupdisks.

• schedule database recovery backups. These backups can also be generated on request, tobe included in an external scheduler maintained by the customer.

A recovery backup of the database contains all the data present in the database and noinformation is lost when using these backups for recovery.

• recover the database to its last committed state in case of a major incident affecting thedatabase files, by using the full database recovery process or the partial recovery process.

Database recovery also provides the following options:

• exclude backed up or restored archives from the recovery backups: this reduces the timerequired to restore data



Recovery will ignore:

– restored archives (which have been backed up)

– days of traffic backed up (but not removed from the database)

• compress the generated recovery backups: this reduces the size of the recovery backup.

For more information, see "Scheduling Database Recovery Backups" in the SystemManagement Guide.

Note The disks used for the recovery backup disk and the recovery mirror disk must bemounted exclusively so that only the Alliance Access system where the databaserecovery is activated can access them.

Recovery on a local site

In an active or standby configuration, the Alliance Access system is running on the active site.The database (and optionally its software) is replicated on a backup (standby) site.

In this configuration, the active site data is synchronously replicated to the standby site,ensuring that the data maintained on the active and the standby sites is always identical.

The replication is implemented by the file system used by Alliance Access. This replication isoften provided by a Storage Area Network (SAN) infrastructure.

The SAN replication must not affect the overall file system performance and is therefore onlypossible when the distance between the two sites is limited, usually less than 300 kilometres.When the distance is too large, a synchronous replication is not possible, as it would degradethe disk performance too much, and possibly affect the availability and reliability of the system.

In case of a failure in the primary site, operations can be resumed in the standby site.

The Alliance Access in the backup site can be activated and will be able to resume operationsfrom the replicated database. In this scenario, operations are resumed on the standby sitewithout any data loss. The back-office communication is interrupted until the standby site hasbeen activated and Alliance Access has been restarted.

Recovery on a remote site

To protect against local site failures, customers sometimes maintain a remote site, located faraway from the primary site. In this configuration, an Alliance Access system is set up on theremote site and remains inactive until a failover from the primary site occurs. During normalfunctioning of the primary site, recovery data from the primary site is asynchronously replicatedon the remote site.

With asynchronous replication, the data is not identical between the two sites. There is aninherent time delay before the information generated on the primary site is available on theremote site. The delay is mainly linked to the quality and speed of the connection between thetwo sites. This delay can vary a lot, from a few minutes for the most sophisticated infrastructuresto a few seconds for less advanced configuration. The delay is usually never exceeding half anhour. Due to the asynchronous replication, the data will be inconsistent, as the last updatesdone on the primary site will not be available on the remote site. The amount of information lostwill correspond to the database updates done during the replication delay.

Database recovery allows to restore the database in a consistent state, but missing the lastupdates done on the primary site. This is due to the asynchronous replication of data from theprimary site to the remote site.

This will result in resuming with a database that is not an exact up-to-date image of the livedatabase at the incident.

Database Recovery


This situation may generate duplicate transactions. That is, messages just completed before theincident, may re-appear as "live" in the remote database. If not addressed, the "live" messageswill be sent again to SWIFT or to the back-office applications, leading to duplicate transactions.To avoid, on the remote site, the re-emission of messages already sent on the primary site, amessage repair operation takes place. For more information, see "Repairing Messages" onpage 176.

Managing recovery backups

From the System Management application, you use the Manage Recovery Backups commandto specify:

• when to generate a full or incremental recovery backup of the database (either based on atime schedule or on disk space usage)

• whether to include backups of archives (messages, events) in the recovery backup

• whether to compress the generated recovery backups.

The Manage Recovery Backups command also allows to launch a full or incremental recoverybackup.

For more information about this command, see "Scheduling Database Recovery Backups" inthe System Management Guide.

Disk space monitoring

The Monitoring application provides a System Resources view to check the size of therecovery backup disk containing the recovery backups. For more information, see "The SystemResources Window" in the Daily Operations Guide.

The "Recovery Shutdown - MB" and "Recovery Warning - MB" configuration parameters can beset with relation to disk space monitoring. For more information, see "Classes of ConfigurationParameters - Disk Space" in the System Management Guide.

23.2 Database Configuration for Enhanced ResiliencyDescription

The relational database of Alliance Access is physically made of three main structures:

• datafiles, which contain all the database data. In Alliance Access, these datafiles are mappedto logical database structures called tablespaces. These tablespaces group the databaseentities.

• redo log files, which record all the changes made to the database data.

• control files, which contain information specifying the physical structure of the database (thatis, database name, names, and locations of datafiles and redo log files).

Alliance Access provides a database configuration tool (saa_dbconfig) to move redo log filesand tablespaces (hence datafiles) to another physical location.

The activation of the database recovery on Alliance Access enhances further the databaseresiliency and allows a recovery of the Alliance Access database to its last committed state incase of media failure.



Activate Recovery Mode

The following changes have been performed after the activation of the database recoverymode:

1. After having set up the database for "DB recovery mode", the structure has been changedand is as follows:

D05

4017

6

Live DiskRecovery

Mirror DiskRecovery

Backup Disk

CONTROL02.CTL

REDO01.LOG

REDO02.LOG

REDO03.LOG

DATAFILES

CONTROL03.CTL

REDOM01.LOG

REDOM02.LOG

REDOM03.LOG

ARCHIVEDREDO LOG

FULL BACKUPS

INCREMENTALBACKUPS

CONTROL01.CTL

This database configuration implies that:

– The Recovery Mirror Disk is a fast disk, as it is constantly accessed for writing the redolog files.

– The Recovery Backup Disk is a large-size disk, as it stores the different databasebackups and the archived redo log files.

Note SWIFT recommends using a separate disk controller for the Recovery MirrorDisk and the Recovery Backup Disk.

2. The database is configured to archive the online redo log files.

3. A first full recovery backup of the database has been taken and consists of:

– a database backup which contains all the database data, excluding the backed up orrestored archives of messages, and events

– a backup of the Alliance Access configuration files stored outside the database

Database Recovery


4. The database size is monitored, which triggers the generation of full or incrementaldatabase recovery backups when specified disk size thresholds are reached.

The default configuration for the recovery backups can be changed using the ManageRecovery Backups command in the System Management application.

Note No recovery is possible if the Recovery Mirror Disk or the Recovery Backup Diskare damaged, or have missing or corrupted files. As soon as you discover that therecovery disks are damaged, you must deactivate the recovery mode.

For more information on how to activate the database recovery mode, see "Activate theDatabase Recovery Mode" on page 179.

Alliance Access setup on remote site

To use the database recovery functionality on a remote site in case of failure, the followingsteps must be performed:

1. Install Alliance Access on the primary and remote site, with the same licence, version andpatch level, and instance name.

The IP address, host name, operating system level, software installation location and pathsfor mirror and backup disks may be different.

2. Set up the asynchronous replication between primary site and remote site.

After the asynchronous replication of the disks is set up, Alliance Access will automaticallycreate or update the database control file and trigger the replication of the latest files availableon the mirror and backup disks of the primary site to the mirror and backup disks on the remotesite.

Important A partial database recovery up to the last valid transaction is performed. If youwant to use the data from the partial database recovery, then you must set thevalue of the "Message Repair Action" security parameter on the Alliance Access ofthe primary site.

23.3 Database Recovery ProcessPrerequisites

Before a database recovery is initiated, the following conditions must be met:

• The Alliance Access servers must be stopped.

• The recovery files present on the mirror disk and backup disks must be available. In case of arecovery on a remote site (disaster site recovery), the complete information present on thesemirror and backup disks must be available on the remote site.

• In case of recovery on a remote site, the Alliance Access system where the recovery takesplace must be set up.

For more information, see "Alliance Access setup on remote site" on page 172.

Full recovery process

The full recovery of the Alliance Access database is initiated by launching thesaa_dbrecovery command line tool, using the -r option. For the command to succeed, it ismandatory that the recovery data is complete. This will always be the case when using the local



recovery data. The full recovery command will be rejected if it is executed against recovery datathat has been replicated, but is not complete (as is the case with asynchronous replication).During a full recovery, database recovery will transparently perform the following steps requiredto recover the database up to the last committed transaction:

1. Restore the latest full recovery backup.

2. Restore the incremental recovery backups, if any.

3. Restore and replay the archived redo log files, if any.

4. Replay the redo logs available on the mirror disk.

The database is recovered to its last committed state based on the information available in thedatabase backups, archived redo log files, and on-line redo log files.

For more information on how to start the database recovery, see "Activate the DatabaseRecovery Mode" on page 179.

Note The recovery process assumes that the mirror and backup disks are locallyavailable to be restored on the database. In case of a remote recovery, themirrored control file, on-line redo logs, archived redo logs, and database backupsmust be available on the remote site, with up-to-date information.

The recovery procedure will fail if the various files used for recovery are not up-to-date, containing the last committed data. This constraint is particularly important forthe mirrored control file and the on-line redo log files that are constantly updatedduring database activity.

Partial recovery process

The partial recovery of the database is initiated by launching the command line toolsaa_dbrecovery, using the -v option. This recovery mode must be used when the recoverydata is not complete. It is therefore the only option allowed when executing a recovery from aremote site, using recovery data replicated asynchronously from the primary site. During apartial recovery, database recovery will transparently perform the following steps required torecover the database up to the last valid transaction:

1. Locate the last valid transaction available in the redo logs present on the mirror disk.

2. Restore the database up to that point by:

• restoring the latest full recovery backup

• restoring the incremental recovery backups, if any

• restoring and replaying the archived redo logs, if any

• replaying the redo logs available on the mirror disk.

Database recovery will indicate the timestamp of the last restored transaction.

After successful completion of the partial recovery, the database will be in a consistent state,but will miss some of the last updates done on the primary database. In order to avoid, on theremote site, the re-emission of messages already sent on the primary site, database recoveryperforms the following actions:

• Produce a report with the outstanding live message instances following the databaserecovery.

Database Recovery


• Add a possible duplication indicator (PDE) to each outstanding live message instancepresent in the restored database.

• Perform on these live message instances the action defined by the value of the securityparameter "Message Repair Action" (previously set on the primary site):

– Complete: the message instance is completed

– Investigate: the message instance is routed to the _MP_recovery queue for furtherinvestigation

– None: the message instance is left in its queue for further routing

– Prompted: the action to be taken must be specified when launching the saa_dbrecoverycommand.

A report on repaired messages is stored in the following file:

<Alliance installation directory>/usrdata/report/saa_msgrepair_YYYYMMDDTHHMMSS.xml

For more information about launching the database recovery process, see "Database RecoveryProcess" on page 172.

For more information about possible actions on message instances, see "Processing RepairedMessages" on page 178.

23.4 Database Recovery Backups

23.4.1 Database Recovery Backups

Overview

Database recovery backups can be taken if option 14:DATABASE RECOVERY is licensed andif the operator has the function "Manage Rec Backup" of the System Management applicationincluded in the operator profile.

There are two ways of creating database recovery backups:

• using the Manage Recovery Backups command in the System Management application.For more information, see "Performing Manual Database Recovery Backups" in the DailyOperations Guide.

• using the saa_dbrecovery command line tool. For command location and syntax, see"saa_dbrecovery" on page 273.

23.4.2 Creating Database Backups in Recovery Mode

Introduction

Alliance Access provides functionality to either schedule database recovery backups or tomanually create a full or incremental database recovery backup.



Database recovery backups can be taken manually in either of the following ways:

• using the Manage Recovery Backups command in the System Management application.For more information, see "Performing Manual Database Recovery Backups" in the DailyOperations Guide.

• using the saa_dbrecovery command line tool. This tool is used by customers who prefer torely on the external scheduling of these backups instead of relying on the internal AllianceAccess scheduler. For command location and syntax, see "saa_dbrecovery" on page 273.

To schedule database recovery backups, use the Manage Recovery Backups command in theSystem Management application. For more information, see "Scheduling Database RecoveryBackups" in the System Management Guide.

A database recovery backup includes all the data present in the Alliance Access database.However, backed up or restored archives can be excluded. A database recovery backup alsoincludes database and Alliance Access configuration files (stored outside the database) if thesehave been changed since the last recovery backup was taken.

When you perform a database recovery backup, Alliance Access first verifies that the estimatedsize of the recovery backup is less than the available disk space on the recovery backup disk. Ifinsufficient space is available, then the backup operation will fail. This will however not affectnormal Alliance Access operations.

Description

The following occurs when a database recovery backup is created:

• If the backup type is:

• Full

– A backup of all the datafiles is created on the recovery backup disk. If the IncludeArchive Backups option is not selected, then the datafiles associated to archivebackups of messages and events are not included in the recovery backup.

– The existing incremental backups and the archived redo logs are deleted.

If a previous full recovery backup exists, then this is also deleted at this stage. Youcan remove the existing full recovery backup before taking a new one, by using theoption -e with the saa_dbrecovery command. You can also use this option tocreate disk space if there is insufficient disk space to launch a new full recoverybackup.

• Incremental

– A backup of all the datafiles for which changes have occurred since the last backup(whatever its type) is created on the recovery backup disk. If the Include ArchiveBackups option is not selected, then the datafiles associated to archive backups ofmessages and events are not included in the recovery backup.

– The existing archived redo logs are deleted.

Database Recovery


23.5 Repairing Messages

23.5.1 Repairing Messages after Partial Database Recovery

Purpose

The message repair functionality ensures that no duplicate transactions are generated followinga partial database recovery.

When the Alliance Access database is partially recovered on a remote disaster site, it could bethat some FIN, InterAct, or FileAct messages sent or received by Alliance Access on theprimary site, or some FIN network acknowledgements (ACK or NAK) have not been replicatedon the remote disaster site.

Some of these messages would reappear as live and hence, these messages would be resentto SWIFT, which can result in duplicate messages. The message repair functionality helps youto avoid this because the outstanding live messages are identified with possible duplicateemission (PDE) flags, which ensures that potential duplicate re-emissions are identifiedproperly.

The message repair functionality is available with the following tools:

• automatically, with the saa_dbrecovery tool when a partial recovery is launched (option -v)

• manually, by launching the saa_msgrepair tool

– to resume the repair process if interrupted due to a failure when running as part of therecovery process

– to perform the message repair action following a recovery on an Alliance Access withhosted database

You use the saa_msgrepair tool:

• on an Alliance Access with an embedded database to re-launch a message repair operationpreviously interrupted. The tool is used to take corrective actions following the interruption ofmessage repair operation launched by the saa_dbrecovery tool.

• on an Alliance Access with a hosted database to launch a message repair operation after adatabase restore was performed without the saa_dbrecovery tool. In this case, licenceoption 13:HOSTED DATABASE must be present.

For details about the usage of saa_msgrepair, see "saa_msgrepair tool" on page 177.

When the message repair operation is launched, a possible duplicate emission (PDE) indicatoris added to all the outstanding live messages present in the restored Alliance Access database.

For the live messages that are flagged with PDE, one of the following actions is performed:

• Complete all the outstanding live messages present in the restored Alliance Accessdatabase.

• Route all the outstanding live messages present in the restored Alliance Access databaseinto a dedicated queue, _MP_recovery, for further investigation.

• Leave all the outstanding live messages present in the restored Alliance Access database intheir queue, but flagged with PDE. This will trigger their automatic re-emission to SWIFT or tothe back office.



Note You can resume the normal operations only after the message repair operation hasbeen executed completely and successfully.

saa_msgrepair tool

The tool allows you to:

• display the status of the message repair operation

• select the message repair option

Warning You must exclusively use the saa_msgrepair tool in the context of a databaserecovery following a disaster on an Alliance Access hosted on a primary site. Youmust not use it as a support tool to complete outstanding live messages duringnormal operations. If you launch the tool when there is no database recoveryoperation, then the tool will return an error.

Prerequisites

• The Alliance Access Administrator must run the command.

• The Alliance Access servers must be stopped.

To process the live outstanding messages:



3. Enter the saa_msgrepair command.

For command location and syntax, see "saa_msgrepair" on page 282.

The outstanding live messages are either completed, routed to _MP_recovery for furtherinvestigation, or left in the routing point.

Note A report on the outstanding live messages is stored in the following file:

<Alliance installation directory>/usrdata/report/saa_msgrepair_<YYYYMMDDTHHMMSS>.xmlwhere YYYYMMDDTHHMMSS is the timestamp when the message repair operationwas started.

Error or confirmation messages are produced upon execution of thesaa_msgrepair tool.

Logging information is stored in the following file:

<Alliance installation directory>/log/saa_msgrepair.<YYYYMMDDTHHMMSS>.outputwhere <YYYYMMDDTHHMMSS> is the timestamp when the message repair operationwas started.

Database Recovery


23.5.2 Processing Repaired Messages

Process messages after a partial database recovery

You can find the live outstanding messages that have been repaired following a databaserecovery in the Message Approval application.

If the messages are completed or if there is no action, and if such messages are moved to therepair queue, then the queue will be empty.

In the Message Approval window, you can select the Recovery option from the View menu.

Within this Recovery view, one of the following actions can be performed on these messages:

• Complete: completes the message instance.

• Authorise and Route: routes the message instance as per the routing defined in the_MP_recovery queue.

• Move to Original: moves the message instance to the queue where it was before themessage repair operation.

23.6 The saa_dbrecovery CommandTool availability

The saa_dbrecovery command line tool is available if the database is embedded on AllianceAccess and if licence option 14:DATABASE RECOVERY is present.

23.6.1 Display the Database Recovery Mode

Purpose

This procedure provides instructions for displaying the database recovery mode in whichAlliance Access is operating.

The modes available are:

• Activated

• DeactivatedThe database recovery mode is managed using the saa_dbrecovery tool.


The Alliance Access Administrator account must run the command.

To display the current database recovery mode:



3. How do you want to run the saa_dbrecovery tool?

To launch command Then

with parameters go to step 4




without parameters go to step 5

4. Run the command:

saa_dbrecovery -mThe database recovery mode is displayed.

If the mode is Activated, then the command also displays the total disk size and the freedisk space available in MB for the live disk and each recovery disk.

For more information about the saa_dbrecovery tool, see "saa_dbrecovery" onpage 273.

5. Run the command:

1. saa_dbrecovery

2. Select Display Recovery Mode.

3. Select Quit.

The database recovery mode is displayed.

If the mode is Activated, then the command also displays the total disk size and the freedisk space available in MB for the live disk and each recovery disk.

23.6.2 Activate the Database Recovery Mode

Purpose

This procedure provides instructions for activating the database recovery mode using thesaa_dbrecovery tool.

For more information about active database recovery mode, see "Database Configuration forEnhanced Resiliency" on page 170.



Prerequisite

The Alliance Access database must be running.

To activate the recovery mode:







Database Recovery


4. Run the command:

saa_dbrecovery -a -p <pathname_recovery_mirror_disk> -q <pathname_recovery_backup_disk> [-f]Optionally use -f to specify whether a full recovery backup must be created as part of theactivation.

The command displays the total disk size and the free disk space available in MB for thelive disk and each recovery disk.


5. Run the command:

1. saa_dbrecovery

2. Select Activate Recovery Mode.

3. Specify the full path names of the mirror and backup disks.

4. Select Quit.

The command displays the total disk size and the free disk space available in MB for thelive disk and each recovery disk.

Information about the success or failure of the command is recorded in a log file at the followinglocation:

<Alliance installation directory>/log/saa_dbrecovery.YYYYMMDDTHHMMSS.outputwhere YYYYMMDDTHHMMSS is the time when the command was run.

23.6.3 Deactivate the Database Recovery Mode

Purpose

This procedure provides instructions for deactivating the database recovery mode using thesaa_dbrecovery tool.



Prerequisite


To deactivate the recovery mode:










4. Run the command:

saa_dbrecovery -dFor more information about the saa_dbrecovery tool, see "saa_dbrecovery" onpage 273.

5. Run the command:

1. saa_dbrecovery

2. Select Deactivate Recovery Mode.

3. Select Quit.

Information about the success or failure of the command is recorded in a log file at the followinglocation:

<Alliance installation directory>/log/saa_dbrecovery.YYYYMMDDTHHMMSS.outputwhere YYYYMMDDTHHMMSS is the time when the command was run.

23.6.4 Create a Database Recovery Backup

Purpose

This procedure provides instructions for creating a full backup or an incremental (partial) backupof the database using the saa_dbrecovery tool.

This tool is available if the database is embedded on Alliance Access and if licence option14:DATABASE RECOVERY is present. To create a database backup in recovery mode, thedatabase recovery mode must be activated, as described in "Activate the Database RecoveryMode" on page 179.

Before performing a database recovery backup, Alliance Access estimates the space requiredfor the backup, and then verifies that the recovery backup disk has enough disk space availableto store the database backup.

By default, old database backups are removed after Alliance Access creates a new full-database backup successfully. However, you can specify that Alliance Access removes the oldbackup before creating a new backup.

Disks for backups

The Recovery Backup Disk and the Recovery Mirror Disk must be mounted exclusively to allowonly the Alliance Access system where the database recovery is activated to access thesedisks.



Prerequisite


Database Recovery


To create a database recovery backup:



To launchcommand

Create full backup Create incremental backup

withparameters

go to step 3 go to step 5

withoutparameters

go to step 4 go to step 6

3. Run the command:

saa_dbrecovery -c f [-e]Optionally use -e to specify that Alliance Access removes the old backup before creating anew backup.


4. Run the command:

1. saa_dbrecovery

2. Select Create Full Database Backup.

3. Optionally, you can specify that Alliance Access removes the old backup beforecreating a new backup.

4. Select Quit.

5. Run the following command:

saa_dbrecovery -c iFor more information about the saa_dbrecovery tool, see "saa_dbrecovery" onpage 273.

6. Run the command:

1. saa_dbrecovery

2. Select Create Incremental Database Backup.

3. Select Quit.



24 Handling System FailuresIntroduction

This section describes possible causes of system failure and the procedures to recover theAlliance Access system following such a failure.

The commands described must be run by the Alliance administrator, when logged on to theAlliance Administrator account.

Depending on the nature of the failure, Alliance Access offers different levels of restart andrecovery possibilities:

• If the Alliance Access software has been lost or corrupted, then it must to be re-installed andthe data must be restored from a backup.

• If a disk has failed, then the Alliance Access software must be re-installed and the data mustbe restored from a backup.

• If there is a serious hardware failure, then Alliance Access may be recovered using another(backup) system. For more information, see "Recovery on a Different Host Using a ColdBackup" on page 185.

If ever a disk failure causes the loss or corruption of the operating system, then the operatingsystem must be either completely re-installed, or restored from backup.

It is therefore important that you back up your operating system after it has successfully beeninstalled and configured for Alliance Access (that is, immediately following Alliance Accessinstallation).

The procedures described in this section must be followed if the Alliance Access servers halt, orfail to start, due to a process failure, power failure, or disk failure. These procedures assumethat, following a hardware failure, the system has been repaired, and that the operating systemis available and has been fully configured for Alliance Access.

24.1 Process FailureDescription

Some Alliance Access server processes may terminate unexpectedly for various reasons:software errors, RPC time-outs, kill process commands issued from the shell, systemmanagement actions, and so on. Whatever the reason, all unexpected process terminations arejournalised and an automatic recovery process initiated by Alliance Access.

Following the failure of a particular process, the process is automatically restarted.

The client of the server, whose request was being served at the time of failure, may receive atime-out from the server and possibly enter into recovery mode. Following recovery, futureclients will automatically start speaking to the recovered server again.

Handling System Failures


24.2 Power FailureDescription

After a power failure, the disk(s) are checked automatically by the operating system when thesystem reboots.

If a disk error is found, then the recovery scenario is the same as for a disk failure. See "DiskFailure" on page 184.

If no damage has occurred to the disk(s), then the recovery scenario is the same as for aprocess failure. See "Process Failure" on page 183.

24.3 Disk FailureOverview

Following a disk failure, all data held on the damaged disk is either lost or inaccessible. Youmust repair or replace the damaged disk and then restore both the Alliance Access softwareand data from backups.

If you have the licence option 14:DATABASE RECOVERY, then you can restore your databaseto the last committed state as it was just before the disk failure.

If the damaged disk contained the operating system as well, then the operating system must berecovered from backup before Alliance Access may be restored.

24.3.1 Restoring Alliance Access Database and Archives

Overview

You restore the Alliance Access database by typing a command from an Xterm window(available from the OS Configuration menu of the System Administration window).

For more information about restoring the Alliance Access database, see "Restoring Data" onpage 154.

You can restore Alliance Access archives in either of the following ways:

• by using the Backup/Restore command from the System Management application (throughthe Access Control application, using an Alliance workstation).

• by typing a command from an Xterm window (available from the OS Configuration menu ofthe System Administration window).

For more information about restoring Alliance Access archives, see "Restoring Data" onpage 154.

Note Before attempting a restore of any data files or archives, check that the backupdirectories exist. For example,

$echo $ALLIANCE_DB



24.4 Recovery on a Different Host Using a ColdBackup

Overview

Following a serious hardware failure, you can select to recover the entire Alliance Accesssoftware using a "Cold Backup" system. This involves recovering all the Alliance Accesssoftware and database, and configuring Alliance Access to run on a new host.

Normally, Alliance Access runs on your "active" system from which you can take daily backups.Upon failure of the active system, you can restore your most recent backups onto the secondsystem and continue working from there, again taking daily backups.

When the active system is running again, you can apply the procedure in the reverse order, thatis, take the database backup made from the second (backup) system and restore it onto theactive system.

If you have the licence option 14:DATABASE RECOVERY, then you can recover the AllianceAccess database to its latest committed state (including live messages) on a remote system.For more information, see "Database Recovery" on page 168.

This section describes the steps to be performed, in the context of a recovery using a coldbackup, on the active Alliance Access system and on the backup Alliance Access system, andhow to switch from one to the other.

Where relevant, additional information is provided if you have the licence option 14:DATABASERECOVERY.

24.4.1 Set Up the Active System

Prerequisites

1. Install and configure the correct operating system software. For information about thesystem requirements, see the Release Letter and "Preparation" on page 13.

2. Install Alliance Access, as described in "Installation" on page 31.

3. Install any required Alliance Access patches. Make a note of what has been loaded, as thesame patches must also be installed on the backup system.

Set up Alliance Access cold backup

1. Customise your active system installation as required (for example, define operators,routing, message partners, and import RMA authorisation data).

2. Configure your active system for SWIFTNet. See Part B, "Configuring for SWIFTNet" onpage 95.



3. Back up the Alliance Access database, see "Backing Up Data" on page 147. Perform thisstep regularly, for example on a daily basis.

If you have the licence option 14:DATABASE RECOVERY, then you can configure yoursystem for database recovery instead of performing a database backup:

1. Activate the database recovery mode of the Alliance Access database. For moreinformation, see "Database Recovery" on page 168.

2. Check and possibly change the trigger for the creation of the database recoverybackup. For more information, see "Scheduling Database Recovery Backup" in theSystem Management Guide.

4. Generate a report of your system configuration, using the Report command in the Filemenu of the System Administration application.

Repeat this step whenever you update your system (for example, after installing a newpatch).

5. Continue to work normally with Alliance Access for live operations.

6. Perform regular archives of the Event Journal and Message File. You can scheduleautomatic archiving from the Event Journal and Message File applications respectively, orperform manual archiving from these applications.

7. Perform regular backups of the Event Journal and Message File archives. You canschedule automatic backups from the System Management application, or perform manualbackups from this application.

Notes

• For security reasons, the Message File and Event Journal are not backed up by the databasebackup utility. This is to prevent a message already processed from being processed asecond time in error, in particular after restoring from an old backup.

If you have the licence option 14:DATABASE RECOVERY:

– in case of a full database recovery backup, the content includes all the data present in thedatabase at the time of the backup, except the restored archives or archive backups if theconfiguration explicitly excluded them. The external database and Alliance Accessconfiguration files are also included in these backups.

– in case of incremental database recovery backup, the content includes only the changescompared to the previous full or incremental backups.

For more information, see "Database Recovery" on page 168.

• To back up the archives, you must perform the backup from Alliance Access, which storesthese archives in a release-independent backup format. This allows you to restore thearchives on the current and on any future release of Alliance Access. When you have backedup an archive, the archive may be removed from the database.

• SWIFT recommends to perform archival and backups on a regular basis:

– back up the release tree whenever you upgrade the Alliance Access release or you installan Alliance Access patch

– perform a database backup on a daily basis

– perform archives of the Message File and Event Journal every week



– back up the Message File and Event Journal archives every week.

• Store these backups on separate media, not on the one from which Alliance Access isloaded.

• These backups must be readily available in the event of a crash of the active system.

If you have the licence option 14:DATABASE RECOVERY, then the recovery disks andoptionally the archive backups must be readily available in the event of a crash of the activesystem.

24.4.2 Set Up the Backup System

Overview

You must set up your backup system (install the same operating system software and definepaging space, for example) in the same way as your active system.

Set up Alliance Access on your backup system

1. Install Alliance Access using the same release media as for the active system.

• Assign a different global and local IP address to the backup system. The global IPaddress is the IP address used within your network environment, as it is known toSWIFT.

• Use the same Alliance Access Initialisation and Master passwords as those used on theactive system.

• At this stage, there is no need to configure operators, routing, for example, in AllianceAccess. When needed, Alliance Access configuration data is restored from databasebackups, taken from the active system.

• The $PATH definition for root must be the same for Alliance Access on both systems. Tocheck this, log on as root and type:

echo $PATHThe result of this command must be the same on both systems. If not, then type:

export PATH=$PATH:<missing directory path>

2. If any patches or release upgrades have been applied to the active system, then ensurethat they are also applied to the backup system.

3. Restore the database backup from the active system. Restore all data sets, including theSWIFTNet Interface Restore set.

You restore the database using the saa_dbrestore command.

You may disable connectivity when restoring the database. For more information, see"Restoring the Alliance Access Database" on page 156.

To disable the startup of the SWIFT connectivity and ADK applications on Alliance Accesswhen starting the servers in Operational mode, you can also prevent the SWIFT InterfaceServices, SWIFTNet Support Services, or any ADK components from starting by followingthese steps:

1. Start the Alliance Access servers in Housekeeping mode.




3. Select Stop Component from the File menu. The Stop Component window appears.

4. Select the component that you want to stop in this window and click Stop . Repeat thisstep for other components if needed. Then click Cancel .

5. Restart the Alliance Access servers in Operational mode.

Important First restore a database backup from the active system before taking anydatabase backup on the backup system.

This procedure restores all of your Alliance Access configuration data, exceptfor the Event Journal and Message File. Empty files are created for theseobjects.

For more information about restoring the database, see "Restoring the AllianceAccess Database" on page 156.

4. Start the Alliance Access servers, to validate the installation.


6. If you use server authentication and a CA certificate was obtained on your active system(using swrpc_keytool), then you may want to use the same certificate on your backupsystem. In this case, use the saa_configconnection tool to import the certificate ontothe backup system. For more information about using this tool, see "saa_configconnection"on page 226.


Important If the active system has a logical terminal configured with automatic login, thenat server startup on the backup system, the logical terminal automaticallyattempts to log in. The same is true for automatic activation of emission andreception profiles.

8. Stop the SIS and SNIS components from the System Management application.

9. Possibly modify the configuration of your backup system for SWIFTNet (see Part B,"Configuring for SWIFTNet" on page 95). For example, this can be necessary if the AllianceGateway to connect to is located on another host.

10. Start the SIS and SNIS components from the System Management application.

Note Any changes to ports on the active system must also be made on the backupsystem.

24.4.3 Perform a Takeover on the Backup System

Procedure

1. Log on to the backup system as Alliance Access administrator.

2. Use the Report command from the File menu of the System Administration application tocheck the configuration of the backup system. Compare this report with the latest reporttaken from the active system. Check that the OS release level, paging space allocation,number of user processes, port allocations, Alliance Access release level, and patch levelare correct.



3. Restore your most recent backup of the Alliance Access database (taken from the activesystem) to the same directory on the backup system. Restore all data sets except theSWIFTNet data (the SWIFTNet Interface Restore Set).

To restore the database, use the saa_dbrestore tool (with options -w n).

For more information about restoring the Alliance Access database, see "Restoring theAlliance Access Database" on page 156.

Note This step restores all of your Alliance Access configuration data, except for theEvent Journal and Message File. Empty files are created for these objects.

If you have the licence option 14:DATABASE RECOVERY, then restore on thebackup system the Alliance Access database from the recovery backupsavailable on the recovery backup disk. Use the saa_dbrecovery tool, asdescribed in "saa_dbrecovery" on page 273.

4. If you use server authentication and a CA certificate was obtained on your active system(using swrpc_keytool), then you may want to use the same certificate on your backupsystem. In this case, use the saa_configconnection tool to import the certificate ontothe backup system. For more information about using this tool, see "saa_configconnection"on page 226.


Important If the active system has a logical terminal configured with automatic login, thenat server startup on the backup system, the logical terminal automaticallyattempts to log in. The same is true for automatic activation of emission andreception profiles.

6. Sign on to Alliance Access (as Supervisor - existing passwords apply) and check whetherthe correct configuration of Alliance Access has been recovered.

7. Stop the SIS and SNIS components from the System Management application.

8. Use the System Management application to restore backups of your Message File andEvent Journal archives, as required. Messages and Events which were not included in thearchives cannot be recovered.

9. Verify the SWIFTNet connection details of your logical terminals, and of your SWIFTNetemission and reception profiles. For more details, see Part B, "Configuring for SWIFTNet"on page 95.

10. Start the SIS and SNIS components from the System Management application.

11. Use the SWIFT Interface application to connect to the SWIFT network to check theconnection to FIN.

Note The first Login and Select may generate a negative acknowledgement (NAK)because of incorrect sequence numbers. To correct this, repeat the Login andSelect commands.

12. If you exchange FileAct or InterAct messages, then use the SWIFTNet Interface applicationto check the connection to SWIFTNet.

When all is well, resume normal live operations using your backup system.



25 Replication of Configuration DataOverview

This section describes how to replicate configuration data from one Alliance Access instance toanother instance.

This functionality allows you to:

• validate the configuration changes of a test system before applying these changes on aproduction system.

• easily change the configuration of several production systems that increase the levels ofresilience and load balancing.

• automate repetitive configuration changes.

For example, Service Bureaux can use this functionality to add new customers or BICs.

No additional licence is required to replicate configuration data.

25.1 Configuration ReplicationDescription

Alliance Access provides the following command-line tools to replicate configuration data fromone Alliance Access instance to one or several target Alliance Access instances:

• The export tool (saa_export) uses a parameter file which defines the type of data to exportand exports the configuration data from the source Alliance Access instance to an export file.

• The import tool (saa_import) uses the configuration data in the export file to update theconfiguration of the target Alliance Access instance.

You run the export tool locally on the source instance and the import tool locally on any targetinstance:

Export tool Import tool

Access

D0

54

01

83

Access Export file

(User modifiable

file - text format)

When you run the export tool, the configuration data that matches the criteria defined in theexport parameter file is transferred to the export file. The export file is in XML format.

Before running the import tool on the target Alliance Access instance, you can edit in any texteditor the export file that the export tool produced. This allows you to customise theconfiguration in the target instance. For example, you can replace Test and Training logicalterminals by Production logical terminals before replicating a test instance configuration into aproduction instance.



Parameter file validation

The parameter file used during the export or import operation is validated against schemadefinitions (.xsd files).

These .xsd files are located in the following directory:

<Alliance installation directory>/bin/xsd

Configuration data suitable for replication

An entity is a component of Alliance Access and all occurrences of that component within theAlliance Access instance. For example, the Unit entity indicates all Unit occurrences defined inAlliance Access. Other examples of entities are operator, exit point, emission profile.

All the entities for which you can replicate configuration data are listed in "Entities Eligible forExport and Import" on page 193.

You can use the import and export tools to replicate one or several entities at a time to a targetAlliance Access.

Alliance Access does not support the replication of operational entities, such as, calendarentries, events, or messages, or the entities that it configures automatically either at installationtime or at relicensing time, such as, Destinations.

Sensitive data

Some entities have parameters that may contain sensitive data. You can choose whether toexport sensitive data to the export file. For more information, see "Handling the Export andImport of Sensitive Data" on page 192.

The data in the export file is not protected by a signature. Ensure that the export file is properlysecured, especially if it contains sensitive data, such as the digests for operator passwords.

Permissions

The default operator profile, R7.0_Import_Export, contains the permissions required to exportand import configuration data using the configuration replication tools.

You can assign the R7.0_Import_Export profile to the software owner (all_adm) through the"Software Owner Profile" security parameter. If you do not assign this profile to the softwareowner, then you must run the tools with the -user, or -application, and -passwordoptions, to provide the user credentials.

For more information about the permissions required to export or import specific entities, see"Entities Eligible for Export and Import" on page 193.

In all of the cases below, the user must have the profile R7.0_Import_Export assigned:

User account Software Owner Profile isdefined?

Specify -user, or -application,and -password

all_adm Y Optional

N Mandatory

Any other OS account (operator) N Mandatory

Replication of Configuration Data


25.2 Handling the Export and Import of Sensitive DataOverview

You can export sensitive data, that is, the operator passwords, using the -exportsensitivedata parameter with the saa_export command.

You can export an operator's password if the Authentication Method for the operator is localIf the same entities exist in both the source and the target Alliance Access instance, then youcan update the configuration of the entities in the target instance using the -overwriteparameter with the saa_import command.

Operator passwords

If you export sensitive data using the -exportsensitivedata parameter with thesaa_export command, then the following results are achieved:

Action -exportsensitivedata specified

Result

Export Y The password information (password digest) is added tothe export file.

Import Y The password information (password digest) is added tothe entities in the target instance.

Operators occurrence exists in target Alliance Access

If the operator entity exists in the target instance and if its Authentication Method is Local,then the import process varies depending on whether a password is present in the import file.

If a digest exists for the password, then the Alliance Access instance:

• creates the operator with the existing password from the Import file.

• marks the password of the operator as being expired, which will require the operator to resetthe password the next time the operator logs on.

If no digest exists for the password, then the Alliance Access instance:

• leaves the operator password unchanged.

• logs this action in the report file with the occurrence reference of the operator entity.

Operators occurrence does not exist in target Alliance Access

If the operator entity does not exist in the target instance and if its Authentication Method islocal, then the Import process varies depending on whether a password is present in theImport file.

If a digest exists for the password, then the Alliance Access instance:

• creates the operator with the existing password from the Import file.

• marks the password of the operator as being expired, which will require the operator to resetthe password the next time the operator logs on.



If no digest exists for the password, then the Alliance Access instance:

• sets a system-generated password as the value of password for the operator.

• logs the action in the report file with the occurrence reference of the operator entity.

If -exportsensitivedata not specified

Action -exportsensitivedata specified

Result

Export N The password information (password digest) is notexported to the export file.

Import N If a new operator is added, then Alliance Access generatesa password and assigns it to the operator.

If the operator exists in the target instance, then thepasswords are not changed.

25.3 Entities Eligible for Export and ImportFiltering fields

Entity Permission required forexport

Permission required for import

Configuration System Management System Management: Modify ConfigurationParameter

Correspondent Correspondent Info - Open/Print Correspondent Details

Correspondent Information:

• Open/Print correspondent details and

• Add correspondent, and/or

• Modify correspondent details

Distribution List System Management System Management:

• Add Distribution List, and/or

• Modify Distribution List

Emission Profile SWIFTNet Interface: Open/Print Emission Profile (5)

SWIFTNet Interface:

• Open/Print Emission Profile

• Add Emission Profile, and/or

• Modify Emission Profile

• Schedule Emission Profile, and/or

• Disable Emission Profile auto (6)

• Enable Emission Profile auto

Event Distribution System Management System Management: Modify Event List





Exit Point Application Interface: Open/Print Exit Point (3)

Application Interface:

• Open/Print Exit Point

• Add Exit Point, and/or

• Modify Exit Point

Input Channel SWIFTNet Interface: Open/Print Input Channel (8)

SWIFTNet Interface:

• Adopt Input Channel and

• Open/Print Input Channel

Logical Terminal SWIFT Support SWIFT Support:

• Add LT, and/or

• Modify LT

• Set default Live, and/or

• Set default T&T

Logical TerminalDefinition

SWIFT Interface: OwnDestination List (9)

SWIFT Interface:

• Modify LT and

• Add Action, and/or

• Modify Action, and/or

• Remove Action, and/or

• Enable / Disable Auto Mode

• Enable / Disable Reconnect and OwnDestination List (9)

Message Partner Application Interface: Open/Print Partner (1)

Access Control: Files onServer

Application Interface:

• Open/Print Partner

• Add Partner, and/or (2)

• Modify Partner

Access Control: Files on Server

Operator Security Definition Security Definition:

• Add Operator, and/or

• Modify Operator

Operator Profile Security Definition Security Definition:

• Add profile, and/or

• Modify profile





Output Channel SWIFTNet Interface Open/Print Output Channel (8)

SWIFTNet Interface:

• Adopt Output Channel and

• Open/Print Output Channel

Reception Profile SWIFTNet Interface: Open/Print Reception Profile RTand Open/Print ReceptionProfile SnF (10)

SWIFTNet Interface:

• Open/Print Reception Profile RT, and/or

• Open/Print Reception Profile SnF

• Add Reception Profile, and/or

• Modify Reception Profile and

• Schedule Reception Profile, (6)and/or

• Disable Reception Profile auto or

• Enable Reception Profile auto

Routing Keyword Routing Routing:

• Add Keyword, and/or

• Modify Keyword

Routing KeywordDefinition

SWIFT Support SWIFT Support:

• Add Keyword, and/or

• Modify Keyword

Routing Rule(12) Routing: Open Routing Point(4)

Routing:

• Open Routing Point

• Add Rule, and/or

• Modify Rule

• Default Rule (11)

Routing Schema Routing Routing:

• Add Schema, and/or

• Modify Schema

SWIFTNet Connection SWIFTNet Support: SNLHandling (7)

SWIFTNet Support: SNL Handling (7)

System Queue System Management System Management: Modify Queue

Unit Security Definition Security Definition:

• Add Unit, and/or

• Modify Unit





User Queue System Management System Management:

• Add Queue, and/or

• Modify Queue

(1) Permission details: Only Message Partners explicitly allowed (or not explicitly prohibited) are exported or imported.

Default R7.0_Import_Export profile is set up with 'Prohibited: None'.

(2) Permission details: No constraint, because the LAU keys are not imported.

(3) Permission details: Only exit points explicitly allowed (or not explicitly prohibited) are exported / imported. Default

R7.0_Import_Export profile is set up with 'Prohibited: None'.

(4) Permission details: Only routing rules related to routing points explicitly allowed (or not explicitly prohibited) are

exported / imported Default R7.0_Import_Export profile is set up with 'Prohibited: None'.

(5) Permission details: Only profiles set up for explicitly allowed (or non explicitly prohibited) services and BICs are

exported / imported Default R7.0_Import_Export profile is set up with 'Prohibited: None'.

(6) Permission details: When scheduled actions have to be imported (added or possibly overwriting existing ones), the

operator must be allowed to add actions and/or modify actions and/or remove actions as required by the specific

import needs, for the import to be successful. Default R7.0_Import_Export profile is set up with 'Add / modify /

remove actions allowed'.

(7) Permission details: The Connection Handling permission detail must be set to 'Y' to export / import. Default

R7.0_Import_Export profile is set up with SNL Handling, Connection Handling set to 'Y'.

(8) Permission details: Only Input (Output) Channel occurrences belonging to the destinations (BIC8) explicitly allowed

(or not explicitly prohibited) and for destinations that are not licensed are exported or imported. Default

R7.0_Import_Export profile is set with 'Prohibited: None'.

(9) Permission details: Only Logical Terminal (Logical Terminal Definition) occurrences belonging to the destinations

(BIC8) explicitly allowed (or not explicitly prohibited) are exported or imported. Default R7.0_Import_Export profile

is set with 'Prohibited: None'.

(10) Permission details: Only SnF reception profiles set up for explicitly allowed (or non explicitly prohibited) BICs are

exported or imported Default R7.0_Import_Export SnF reception profile is set up with 'Prohibited: None'.

(11) The change of the default action for a routing rule is only allowed in housekeeping mode.

(12) Only user-defined routing rules can be exported or imported. Internal or default routing rules are not exported or

imported.

Settings for LAU keys

Action Result

Export LAU keys are never exported. Therefore, the LAU keys for Message Partner entities andSWIFTNet Connection entities are not included in the export file.

Import New entity You must define the LAU keys after the import is completedbecause a new entity is added in the target instance withoutLAU keys.

Existing entity LAU keys remain as they are defined already in targetinstance.



25.4 Status Management of Entities for ImportEntity dependencies

Entities have dependencies between themselves or some entities refer to other entities. Forexample, an Operator entity refers to a Profile entity and a Unit entity. A Message Partner entityrefers to a Profile entity. The Message Partner, Operator, and Routing Rule entities refer to Unitentities.

During an import, ensure that the entities that are referred to by imported entities exist in thetarget Alliance Access instance or are imported as part of the same import command and theseentities are in the same export file.

For example, when you import Operator entities, the Units to which the operators belong musteither exist in the target instance or be part of the same export file as the operators beingimported. In addition, the Unit to which an operator belongs must be in an approved state intarget instance. If it is not, then import will fail.

The following diagram shows the dependencies between entities for import and export actions:

For example, the red arrows in the diagram show the following relationships:

• Routing Keyword requires Routing Keyword Definition

• Logical Terminal requires Logical Terminal Definition

Status of entities before and after export

This section lists the entities and the status they must have in the target Alliance Access beforethe import and their status after the import is complete.

Any invalid status stops the export or the import process.



Important If Alliance Access cannot add an entity, then it exports only the fields that arerequired to identify the occurrence of the entity in the target instance, and the fieldsthat can be updated.

Entity name Newoccurrencein targetinstance?

Prerequisites Status in target instance

Before import After import

Configuration - ADK Storage parameter is read-only (left unchanged duringimport)

- -

Correspondent Y Country and Correspondent typefields are read-only (leftunchanged during import

- -

Distribution List Y Distribution, if equal to Fixed,then it is read-only (leftunchanged during import)

- -

Emission Profile Y - Disabled Disabled

Event Distribution - - - -

Exit Point Y Assigned Message Partner fieldis read-only (left unchangedduring import)

- -

Input Channel Y Add or update = input channeladoption

The import tool skips updates.

- -

Logical Terminal Y The server must be inhousekeeping mode.

- -

Logical TerminalDefinition

- Before update: SIS componentmust be stopped

- -

Message Partner Y - Disabled Disabled

Operator Y - Disabled Approvedstatus:Unapproved

and

Enable status:disabled

Operator Profile Y - No operatorusing thatoperator profilecan be loggedon

All operatorsusing theupdatedoperatorprofile getdisabled andunapproved

Output Channel Y Add or update = output channeladoption

The import tool skips updates.

- -

Reception Profile Y - Disabled Disabled

Routing Keyword Y - - -


- The server must be inhousekeeping mode.

- -



Entity name Newoccurrencein targetinstance?

Prerequisites Status in target instance

Before import After import

Routing Rule Y In some cases, user routing rulesexisting in the target instance aredeleted before adding theoccurrences present in the exportfile.(1)

Before add or update, none of theassigned routing schemes maybe active.

The server must be inhousekeeping mode to modifythe default action.

After add or update, the assignedrouting schemes becomeunapproved.

- -

Routing Schema Y - Any Add:unapproved

Update:remainsunchanged

SWIFTNetConnection

Y Before add or update: SIS andSNIS components must bestopped

- -

System Queue - - - -

Unit Y - - Approvalstatus: un-approved(add) or

remainsunchanged(update)

User Queue Y - - -

(1) For example, if the Full indicator is present in the parameter file, and if the routing rule exists in the target

instance, then that routing rule is deleted before the new routing rule is created in the target instance.

25.5 Parameter File for Configuration ReplicationDescription

You use the export parameter file to specify the entity types and entity occurrences that must beexported.

You can specify the following details in the export parameter file:

• The type of entity to export. You must define at least one type of entity.

For more information about the entities that you can export and import, see "Entities Eligiblefor Export and Import" on page 193.

• For each entity type, you can specify additional filtering criteria to export specific entityoccurrences.



– The filtering criteria is optional. If no filtering criteria is specified, then Alliance Accessexports the configuration data of all the entities specified in the parameter file.

– The filtering criteria fields depend on the entity type. The unique identifier of the entity inthe database is always available as a filtering criteria.

Sample parameter files

Two sample export parameter files are provided in the $ALLIANCE/samples directory:

• saaExportParam-Complete.xml, listing all the entities that can be exported and all possiblefiltering criteria

• saaExportParam-Basic.xml, listing all the entities that can be exported, without any filteringcriteria.

You can copy and update a sample export parameter file to match your own export criteria. Thatis, remove some entities that must not be exported or add filtering criteria to some entities torestrict the export. For more information, see "Filtering fields" on page 193.

Syntax of the parameter file

The following is the syntax to use in the parameter file:

<entities>  <entity name='<entity_name>' <filterset> <filter attrib='<Field_name>' value='<field_value>' [op='<operator>'] /> > </entity></entities>You can combine the filtering criteria for several fields by using the AND, or OR, or both logicaloperators for one entity occurrence.

Also, for each filtering field, you can provide a wildcard value or a set of values, each of themallowing to import an occurrence.

Syntax description

To specify a list of entity or entities to export, and any optional filtering criteria, use the followingelements and attributes in the parameter file:

Element Description Mandatory?

<entities> Denotes the start of the parameterfile.

Y

 Comments about a specific entity. N

<entity name='<entity_name>'> The name of an entity.

The 'entity_name' can be used onlyonce in the file, and it must be anentity that is eligible for configurationreplication(1).

Y

<filterset> The criteria by which to select theentities to export.

If you specify multiple <filterset>elements, then a logical OR is appliedwhen forming the selection criteria.

A <filterset> cannot have no twofilters with the same attrib and op

N



Element Description Mandatory?

<filter attrib='<Field_name>'value='<field_value>'[op='<operator>'] /> >

If you specify multiple <filter>elements, then a logical AND isapplied when forming the selectioncriteria.

(2)

attrib - a field by which you can filter

value - value of the field(3).

op - SQL operator:

• GT - greater than (>)

• GE - greater than or equal to (>=)

• EQ- equal to (=)

• NE - not equal to (!=)

• LE - less than or equal to (<=)

• LT - less than (<)

• LIKE - like (like)

The default is 'EQ' (equal).

</filterset> Denotes the end of the filtersetdefinition.

N

</entity> Denotes the end of the entitydefinition.

Y

</entities> Denotes the end of the parameter file. Y

(1) For a list of entities for which you can replicate configuration data, see "Entities Eligible for Export and Import" on

page 193.

(2) If <filterset> is used, then <filterset> must include at least one <filter> element.

(3) Use either single (') or double-quote (") irrespective of the data type. Use a wildcard (such as, % or _) when the

operator is LIKE.

Example of parameter file with filtering criteria

The following shows an example of a parameter file with filtering criteria for two entities, RoutingRule, and Configuration:

<entities>  <entity name='Routing Rule'> <filterset> <filter attrib='Routing Point Name' value='_SI_from_SWIFTNet'/> </filterset> <filterset> <filter attrib='SeqNo' value='200'/> </filterset> <filterset> <filter attrib='Assigned Scheme' value='AB'/> </filterset> <filterset> <filter attrib='Last Update Timestamp' value='30/04/2010 13:30:55' op='GE'/> </filterset> </entity>



 <entity name='Configuration'> <filterset> <filter attrib='Component' value='BSS'/> </filterset> <filterset> <filter attrib='Object' value='Display Format'/> </filterset> <filterset> <filter attrib='Parameter' value='Amount'/> </filterset> </entity></entities>

Filtering criteria for correspondents

Use the following filtering criteria to export BICs:

To export Use

BIC8 the BIC11 filter attribute and positions 9 - 11 set to xxx

BIC11 the BIC11 filter attribute and positions 9 - 11 set to ***

Test and Training BICs the BIC11 filter attribute and position 8 set 0

Internal Correspondents the Correspondent Definition filter attribute set tointernal

Correspondents that cannot be modified bythe BIC upload

the Update on BIC Load filter attribute set to No



25.6 Exported FieldsDetails

The following fields are exported per entity:

Entity name Exportable fields Filter on field?

Correspondent Institution (BIC11) ✓

Correspondent type

Sub-type

Profile

Institution full name

Branch info

City name

Country

Address

Location

POB number

POB location

Update on BIC load ✓

Correspondent definition ✓

Correspondent status

Preferred language

Comment

Selected integrated applications and their details

Configuration Component ✓

Object ✓

Parameter ✓

Value

Distribution List Name ✓

Operators

Selected operators

Selected internal correspondents

SNMP server IP address or port number




Emission Profile Name ✓

Service name

Messaging service

Requestor DN

Delivery mode

Window size

Retry limit

Signing required

Non repudiation required

Use input channel

Input channel

Delivery notification required

Delivery notification queue

Sequence 1: SWIFTNet connection name, Use specificAuthoriser DN, [Authoriser DN]




Calendar

Schedule category

Manual / Automatic mode

ACTIONS = Action id, Day profile, Time, Action

Event Distribution Component

Event number ✓

Configuration management

Distribution

Alarm

Type

Distribute alarm

To distribution list




Exit Point Name ✓

Queue threshold

Assigned to message partner

Processing order

Modify rules allowed

Display rules allowed

Selected Valid Routing Targets

Maximum message age

Input Channel Name ✓

Logical Terminal BIC8 = Destination name ✓

LTCode ✓

MstvId

Window Size

Master BIC for T&T (for T&T LTs only)

Logical TerminalDefinition(3)

BIC8 = Destination name ✓

LTCode ✓

Sequence 1: SWIFTNet Connection name, Use specificAuthoriser DN, [Authorizer DN], Use specific CID SigningDN, [CID Signing DN]




Auto reconnect

Operation mode

Selection mode

Scheduling category, Calendar, Action ID, Day profile,Time, Action

Delivery subsets




Message Partner Name ✓

Description

Allowed direction

Connection method

Increment sequence number across sessions

Always transfer MAC / PAC

Transfer PKI signature

DETAILS = details of any type of Connection Method

Local authentication required

Selected exit points

Message emission format

Send original message

Format of original message

Routing code transmitted

Validation level

Profile name

Message modification allowed

Unit to be assigned

Batch file validation

Build unique file transfer reference

Disposition

Message in

Reply

Transfer UUMID

Original message

Validation error code




Operator Name ✓

Full name

Application

Authentication method

LDAP user identifier

Display password

Selected allowed profiles

Selected assigned units

Selected Delegated Profiles

Selected Delegated Units

Selected Delegated Destinations

Operator Profile Name ✓

Selected applications

Selected functions

All Permission Details (if any)

Output Channel Name ✓

Reception Profile Name ✓

Delivery mode

Queue name

Window size

Selected subset names





Calendar

Schedule category

Manual / Automatic mode

ACTIONS = Action id, Day profile, Time, Action

Routing Keyword Name ✓

Type

Description





Name ✓

MstvId

Field tag

Subfield

Line range from

Column range from

Selected messages

Routing Rule(1) Routing Point Name ✓

SeqNo ✓

Assigned schemes ✓

Description

Condition on

Selected function result

Message

Action on

Source instance type

Source instance notification type

Source instance action

Source instance selected valid target point

Source instance append intervention

Source instance free text intervention

Source instance Unit

Source instance Routing code

Source instance priority

New instance type

New instance notification type

New instance action

New instance addressee

New instance selected valid target point

New instance append intervention

New instance free text intervention

New instance Unit

New instance Routing code

New instance priority

Last update timestamp(2) ✓




Routing Schema Name ✓

Description

SWIFTNet Connection Name ✓

Hostname

Port number

SSL settings

SSL Certificate

SSL CA Certificate

FileAct port number

FileAct SSL

LAU settings

System Queue Name ✓

Queue Threshold




Maximum message age

Unit Name ✓

Full description

User Queue Name ✓




Maximum message age

(1) Alliance Access exports user-defined routing rules only. It does not export or import internal or default routing rules.

(2) You can use this as a filtering criteria to export only the entities that have a Last update timestamp that meets a

specific condition. You can use a date/time interval condition to export entities that have been last updated during

that date/time interval. For example, you can use it to export only entities that have been updated after a specific

start date/time.

(3) The specified delivery subsets must exist on the target system for the import to be successful.



25.7 Export Configuration DataPrerequisites

Before launching the export tool, check the following:

• The Alliance Access server is running in operational mode.

• The export parameter file is created and stored in a directory of your choice. For moreinformation, see "Parameter File for Configuration Replication" on page 199.

To export the configuration data



3. Enter the saa_export command.

For command location and syntax, see "saa_export" on page 275.

The export process starts. The progress of the export process is displayed on the screen asthe different entity occurrences are exported and stored in the export file.

After the export process is completed, the following message appears.

Export completedTotal no. of occurrences exported: 20CONFIGURATION REPLICATION (EXPORT) - ENDStart of export and end of export are logged as events in the Event Journal.

Note If the import fails, check the report file.

Note You can export multiple entities in a single export command.

An overall counter of all exported occurrences (across entity types) is available inthe report file and the Event Journal.

25.8 Import Configuration DataPrerequisites

Before launching the import tool, check the following:

• The Alliance Access server is running in the required mode (operational or housekeeping) forthe import. This will depend on the entity to be imported.

• During the import, if you want to update some entity occurrences, then check whether theentities are in the appropriate status. For more information about the required status, see"Status Management of Entities for Import" on page 197.

• When an Alliance Access operator launches the import tool, that operator must ensure thatthe export file does not contain his/her operator profile. To be able to update an operator, itmust be disabled. To be able to update a profile, no operator using that profile can be loggedon.



• The target Alliance Access is licensed according to the entities that you import.

Important If the import command fails to import any entity occurrence present in the exportfile, then the import process stops. However, the entity occurrences (present in theexport file) that have successfully been imported before the failure are not rolledback.

Therefore, it is recommended to perform the following steps:

• Back up the database

• Import the configuration data

• If the import process fails after having imported at least one occurrencesuccessfully, then

– stop Alliance Access

– restore database from the backup taken in the first step

– restart Alliance Access.

Import options

The configuration specified in the input export file is imported into the target Alliance Accessinstance according to the input parameters.

Some entities must have a specific status before they can be updated by the import command(for example, Message Partner must be disabled). For more information, see "StatusManagement of Entities for Import" on page 197.

For example, if a Routing Rule entity is exported with no filtering or with no Name specified,then the Full indicator is added to the Export file: <ns2:Full>True</ns:Full>. During animport action, if the Full indicator is present in the parameter file, then Alliance Accessreplaces all the routing rules in the target instance with the rules that are defined in the exportfile.

If an entity occurrence is present in the export file and is not present in the target AllianceAccess instance, then the entity occurrence is added into the target instance.

For information about importing sensitive data, see "Handling the Export and Import of SensitiveData" on page 192.

Tip If occurrences cannot be added for a specific entity (for example, a configurationentity), then the import process skips the occurrence and continues with the nextoccurrence.

For more information, see "Entities Eligible for Export and Import" on page 193.

The overwrite parameter

You can force an update to the configuration data in the target Alliance Access instance byusing the overwrite parameter in the import command.



For each entity occurrence present in the export file, and for the corresponding entityoccurrence present in the target Alliance Access instance:

• When the import command is executed with the -overwrite parameter, then the data in theexport file overwrites the data in the target instance even if the values were identical beforethe export process.

• When the import command is executed without the -overwrite parameter, then the data inthe export file for that entity occurrence is ignored or skipped and the occurrence in the targetinstance remains unchanged.

If the Full indicator is present in the Export file (<ns2:Full>True</ns:Full>), then theoverwrite parameter is ignored during an import.

To import the configuration data



3. Enter the saa_import command.

For command location and syntax, see "saa_import" on page 277.

The entity occurrences are added or updated into the database of the target AllianceAccess instance.

The progress of the import process is displayed on the screen as the different entities areadded or updated. Once the import process is completed, the following messages appear:

Import completedTotal no. of occurrences processed: 20 (Added: 0) (Updated: 20) (Skipped: 0)CONFIGURATION REPLICATION (IMPORT) - END

4. After the import is complete, define LAU keys if new Message Partner entities or SWIFTNetConnection entities were created in the target instance.

Note If the import fails, check the report file.

25.9 Report File for Configuration ReplicationDescription

Alliance Access creates a report file when you run the configuration replication tools,saa_export and saa_import.

The report file for saa_export contains an exhaustive list of the occurrences that were skippedor exported. It also contains warning messages related to the export, for example, if errorsoccurred while handling sensitive data.

The report file for saa_import contains an exhaustive list of the occurrences that were skippedor imported, that is, added or updated in the target Alliance Access instance. The file alsocontains warning messages related to the import, for example, if errors occurred while handlingsensitive data or the import was not completed successfully.



Additional notes about the file:

• The file does not contain any password information.

• The content in the file is overwritten with the new logs created during the export process.

• The file is not deleted when the product is removed.

You can specify a name and location for the report file using the -reportfile parameter.

Name and location of report file

If you do not specify this parameter, then the tool creates a report file in the<Alliance installation> directory with the name:

For export: export<timestamp>.log

For import: import<timestamp>.log

where <timestamp> indicates the date and time at which the command wasrun.

The format for the date is yyyymmdd followed by T and the time hhmmss, basedon the 24-hour format.



26 Operational Integration

26.1 Overview of Operational IntegrationDescription

The Operational Integration functionality provides the monitoring and management commandline tools to integrate monitoring and management activities in Alliance Access into third-partyapplications.

• The monitoring tool extracts the monitoring information from Alliance Access and stores it inan XML file. The information can be transferred to other monitoring systems or externalcustomer applications that perform the monitoring operation.

The monitoring tool produces the output in XML format. If you want to transform the outputformat, then you can use the XSLT. A common output format is CSV. Sample files areprovided to show you how to transform the XML format into a CSV format or a fixed widthdelimited format.

• The management tool performs dedicated actions on Alliance Access entity occurrencesbased on the parameters provided in the manage parameter file. A specific exit code returnsthe actual execution status of the command.

The tool manages operations such as enabling or disabling a message partner, logging on toa logical terminal or logging off from the logical terminal. You can launch the tool manually orfrom a scheduler application running outside Alliance Access.

Note The tools must be executed locally on the source or target Alliance Accessinstance for managing and monitoring respectively.

If you want to launch the tools remotely, then you are responsible to ensure thatthe remote implementation is secure.

Parameter file validation

The parameter file used during the manage or monitor operation is validated against schemadefinitions (.xsd files).

These .xsd files are located in the following directory:

<Alliance installation directory>/bin/xsd

Entities

Entities refer to all defined occurrences of a specific entity type. The entities eligible formonitoring and managing are most of the entities that can be monitored or managed throughthe Alliance Workstation or Web Platform screens.

For a list of entities, see "Entities Eligible for Monitoring and Monitored Fields" on page 218 and"Entities Eligible for Managing" on page 223.

Permissions required to launch or execute the tools

The Alliance Access software owner (all_adm) or any OS account (operator) defined in thesystem can launch the tools.

The permissions for the user executing the tools depend on the value of the "Software OwnerProfile" security parameter.



If no value is defined for this parameter, then it indicates that all_adm has no profile assigned,and therefore does not have the required permissions to execute the export or importcommand. In this case, Alliance Access user credentials are required.

Command launcher Securityparameter"SoftwareOwnerProfile" isdefined

Specify user, orapplication,name andpassword incommand

Command execution

all_adm Y Optional • If user, or application, name andpassword are not provided: all_adm

• If user, or application, name andpassword are provided: operator

N Mandatory The user, or application, name andpassword must be provided to executethe command

Any other OS account(operator)

N Mandatory The user, or application, name andpassword must be provided to executethe command

The following conditions are applicable:

• If the "Software Owner Profile" security parameter is defined for all_adm, then it is optional toprovide the user, or application, name and password.

• If the "Software Owner Profile" security parameter is not defined for all_adm, then it ismandatory to provide the user, or application, name and password to run the command.

If any other OS account launches the tool, then it is mandatory to provide the user, orapplication, name and password. Depending on the permissions, the operator (of typeHuman or Application) can run the command.

26.2 Operational Monitoring

26.2.1 Monitoring Data

Prerequisites

Before launching the monitor command, ensure that:

• the Alliance Access server is running in Operational mode

• a monitor parameter file is available, specifying the entities to monitor.

Monitor parameter file

The monitor parameter file is an XML file. It contains the entity types and the selection criteriaused to define the monitoring scope.

For each entity type, one of the following options are applicable for the selection of entityoccurrences to monitor:

• All: all occurrences of the entity type will be monitored

• Summary: provides summary information for an entity type

Operational Integration


• Exception: all occurrences in exception state for that entity type

• Selection: all occurrences matching the user criteria for the entity type

A sample monitor parameter file containing all the entities that can be monitored is providedwhen you install Alliance Access. You can find this file in the $ALLIANCE/bin directory. Youcan copy and update this file to match your own monitoring criteria.

Note Summary information is applicable when monitoring Operator Sessions only.

Structure of the monitor parameter file

<MonitorEntities>       <entity name="Logical Terminal"></entity>  <entity name="Logical Terminal"> <LT>SAAABEBBB</LT> <LT>SAABBEBBB</LT> </entity>  <entity name="Logical Terminal" scope="Selection"> <LT>SAAABEBBB</LT> <LT>SAABBEBBB</LT> </entity>  <entity name="Logical Terminal" scope="Exception"></entity>  <entity name="Message Partner"> <Name>FileInput</Name> </entity>  <entity name="Message Partner"> <Status>ABORTING</Status> <Status>CLOSED</Status> </entity>  <entity name="Message Partner" scope="Exception"></entity>  <entity name="Queue"> <Name>XYZ</Name> </entity>  <entity name="Queue" scope="Exception"></entity>  <entity name="Emission Profile"></entity>  <entity name="Emission Profile" scope="All"></entity>  <entity name="Emission Profile" scope="Selection"> <Name>saaabebb_rma</Name> <Name>saabbebb_rma</Name> </entity>  <entity name="Emission Profile" scope="Selection"> <Enabled>true</Enabled> </entity>  <entity name="Emission Profile" scope="Selection">



<Enabled>false</Enabled> </entity>  <entity name="Emission Profile" scope="Selection"> <SessionStatus>ACTIVE</SessionStatus> <SessionStatus>ACTIVATING</SessionStatus> <SessionStatus>DEACTIVATING</SessionStatus> <SessionStatus>INACTIVE</SessionStatus> <SessionStatus>INTERRUPTED</SessionStatus> </entity>  <entity name="Emission Profile" scope="Exception"></entity>   <entity name="Reception Profile"></entity>  <entity name="Reception Profile"> <Name>saaabebb_rma</Name> <Name>saabbebb_rma</Name> </entity>  <entity name="System Resource"></entity>  <entity name="System Resource" scope="Exception"></entity>  <entity name="Process"></entity>  <entity name="Operator Session"></entity>  <entity name="Operator Session" scope="Summary"></entity>  <entity name="File Transfer"></entity></MonitorEntities>

To monitor the data



3. Enter the saa_monitor command (for details, see "saa_monitor" on page 280).

Note If the -duration parameter is not specified, then you can use the Enter keyto stop the cyclic monitoring.

The monitoring results are sent to the monitor output file specified when launching thecommand. In case any error occurs and this stops the monitoring process, the information issent to STDERR.

Note The monitoring tool uses minimal Alliance Access resources even in case ofintensive usage of the tool. The performance does not slow down the system and itis not required to monitor how much of Alliance Access resources the monitoringtool uses.



26.2.2 Entities Eligible for Monitoring and Monitored Fields

Details

All the monitored fields are described in "Monitoring the Object Windows" in the DailyOperations Guide, including the values of the fields on which you can filter occurrences (forexample, status, or session).

Entity name Monitoredoccurrences

Fields used foroccurrenceselection

Monitored fields

Logical Terminal All or Exception orSelection

LT or Status Logical Terminal (LT)

Status

Mode

Urgent (U)

Normal (N)

System Messages in Queue (S)

Sent

Received

Connection name

User-controlled sent counter(1)

User-controlled received counter(1)

Exception indicator

In exception timestamp

Message Partner All or Exception orSelection

Name or status orSession Status

Name

Status

Session status

Session number

Queued

Sent

Received

User-controlled sent counter(1)

User-controlled received counter(1)

Exception indicator






Monitored fields

Queue All or Exception orSelection

Name Name

Entries

Reserved

Overdue

Message partner

Status

Age of the oldest message instance inqueue

Exception indicator


Throughput information (Overflowcount, entry per second, exit persecond, trend, delay (optional - only incase of flow control)

SWIFTNetProfile

All or Exception orSelection

Name or Enabledor Session status

Name

Input / Output (I / O)

Enabled (True or False)

Status

Session status

Mode

Urgent (U)

Normal (N)

Sent

Received

Connection name

User-controlled sent counter (emissionprofile only)(1)

User-controlled received counter(reception profile only)(1)

Exception indicator


SystemResource

All or Exception NA System resource name and type(2)

Value

Exception indicator






Monitored fields

Process All NA Component

Description

Started by

Process Identification Number (PID)

Thread ID (TID)

Display (that is, hostname)

PName (Process name)

Status

Stoppable

Client address

OperatorSession

All NA Operator

Operator type

Remote IP

Expiration

Session type

Summary NA Count of human operator sessions

Count of application operator sessions





Monitored fields

File Transfer All NA Input / Output (I / O)

Transfer reference

Correspondent

Request type

User reference

Progress

Start date and time

Profile name

Service name

Network priority

Logical file name

File description

File information

File size

Transfer description

Transfer information

Copy required

Copy type

Copy status

Possible duplicate

Stored transfer reference

(1) This counter support customers' statistical needs. For performance reasons, these counters are not updated upon

every time a message is sent or received. Operator permissions control the resetting of these counters, which can

be performed using the Alliance Web Platform.

(2) The type indicates the type of system resource monitored. The possible values are: DISKSPACE,

RECOVERYBACKUP, DATABASEBACKUP, JOURNALARCHIVE, JOURNALARCHIVEBACKUP,

MESSAGEARCHIVE, MESSAGEARCHIVEBACKUP, and OTHER



26.3 Operational Management

26.3.1 Managing Data

Prerequisites

Before you launch the tool, ensure that:

• the server is running and it is in the housekeeping or operational mode as required by theaction to be performed

• a manage parameter file is present, specifying the entities to manage.

Manage parameter file

The manage parameter file is an XML file. It contains the entity types and the selection criteriaused to specify the entity occurrences to manage.

For each entity type, one of the following options are applicable for the selection of entityoccurrences to manage:

• All: all occurrences of the entity type will be managed

• Selection: all occurrences matching the user criteria for the entity type.

A sample manage parameter file containing all the entities that can be managed is providedwhen you install Alliance Access. You can find this file in the $ALLIANCE/bin directory. Youcan copy and update this sample manage parameter file to match your own managing criteria.

Structure of the manage parameter file

<ManageEntities>      <entity type="Component"></entity>  <entity type="Component" occurrence="All"></entity>  <entity type="Component"> <FieldSet> <field name="Name" value="SIS"/> <field name="Name" value="SNIS"/> </FieldSet> </entity>  <entity type="Component" occurrence="Selection"> <FieldSet> <field name="Name" value="SIS"/> <field name="Name" value="SNIS"/> </FieldSet> </entity>  <entity type="Logical Terminal" occurrence="Selection"> <FieldSet> <field name="LT" value="SAAABEBBB"/> </FieldSet> </entity>  <entity type="Emission Profile">



<FieldSet> <field name="Name" value="saaabebb_rma"/> <field name="Name" value="saabbebb_rma"/> <field name="Name" value="saacbebb_rma"/> <field name="Name" value="saadbebb_rma"/> <field name="Name" value="saaebebb_rma"/> </FieldSet> </entity>  <entity type="Reception Profile"> <FieldSet> <field name="Name" value="saaabebb_rma"/> </FieldSet> </entity>  <entity type="Message Partner"> <FieldSet> <field name="Name" value="FileInput"/> </FieldSet> </entity>  <entity type="Queue"></entity>  <entity type="Operator"> <FieldSet> <field name="Name" value="user1"/> </FieldSet> </entity></ManageEntities>

To manage the data



3. Run the saa_manage command (for details, see "saa_manage" on page 278).

Note If you run the command on several occurrences of the specified entity, and thecommand fails for one or more occurrences, then the action is stopped but theaction is not rolled back for the occurrences on which it is successfully completed.

The saa_manage tool only launches or triggers the action specified when thecommand is issued. It does not wait for a successful completion of the action toreturn. For example, for LT login, the tool does not wait until the LT is logged in toreturn.

26.3.2 Entities Eligible for Managing

Details

Entity name Occurrenceidentification

Possible actions Permission required

Component All or Name fieldvalues

Start System Management, Stop, StartComponent

Stop System Management, Stop, StartComponent





LogicalTerminal

All or LT fieldvalues

Login SWIFT Interface, Login, Select

select_FIN SWIFT Interface, Login, Select

Logout SWIFT Interface, Login, Select

Quit SWIFT Interface, Login, Select

Change_mode SWIFT Interface, Enable /Disable Auto mode

Reset_Sent (1) Monitoring: Reset LT Counter

Reset_Received (1) Monitoring: Reset LT Counter

Emission /ReceptionSWIFTNetprofile

All or Name fieldvalues

Activate SWIFTNet Interface, ActivateEProf / Activate RProf

De_activate SWIFTNet Interface, DeactivateEProf / Deactivate RProf

Enable SWIFTNet Interface, EnableEProf / Enable RProf

Disable SWIFTNet Interface, DisableEProf / Disable RProf

Change_mode SWIFTNet Interface, EnableEProf auto / Disable EProf auto /Enable RProf auto / DisableRProf auto

Reset_Sent (for EmissionProfile only) (1)

Monitoring, Reset EProf Counter(Emission profile) or Reset RProfCounter (Reception profile)

Reset_Received (forReception Profile only) (1)

Monitoring, Reset EProf Counter(Emission profile) / Reset RProfCounter (Reception profile)

MessagePartner

All or Name fieldvalues

Enable Application Interface, EnableMessage Partner

Run_session Application Interface, RunSession

Abort_session Application Interface, AbortSession

Start_session Application Interface, StartSession

Stop_session Application Interface, StopSession

Reset_Sent (1) Monitoring, Reset MP Counter

Reset_Received (1) Monitoring, Reset MP Counter

Queue All or Name fieldvalues

Hold System Management, HoldQueue

Release System Management, ReleaseQueue





Operator All or Name fieldvalues

Enable Security Definition, EnableOperator

Disable Security Definition, DisableOperator

(1) When these actions are executed, the value of the counter before the reset is provided in the output.

26.3.3 Action Parameters

Details

Some actions on some entities may require additional parameters.

Entity name Action keywords Action parameters

Logical Terminal select_FIN -subset [subset name 1]

-subset [subset name n]

-ltdirqueue y / n

-send_receive_mode s / r / sr

[-test_mode_selection full_function /local_test] (if test and training LT in sendand receive)

Change_mode -mode manual / automatic

Emission / ReceptionSWIFTNet Profile

Change_mode -mode manual / automatic

Message Partner Start_session (If the message partner uses the File Transferconnection method)

-file_location server / userspace

-connection_point connection_point

-add_PDE y / n

-action route / dispose [queue_name]

Run_session (If the message partner uses the File Transferconnection method)

-file_location server / userspace

-connection_point connection_point

Operator Disable -next_signon_allowed enable, or a date andtime

-next_signon_allowed enable-next_signon_allowed date <DD/MM/YYYYHH:MM:SS>



27 Using Command Line ToolsIntroduction

In addition to the System Administration application, you can use a number of tools availablefrom the command line to administer Alliance Access.

27.1 saa_manageaspPurpose

You can use the saa_manageasp command to install all the Application Service Profiles(ASPs) of a provided ASP package.

Prerequisites

• The Alliance Access server must be running.

• The operator must have the "Manage ASP" permission (in the SWIFT Support application) intheir profile.

Results

Error or confirmation messages are logged in the log directory, underneath your installationdirectory. The filename has the timestamp (YYYYMMDDTHHMMSS) of when the ASPmanagement operation was run.

27.2 saa_configconnectionPurpose

Using the saa_configconnection tool, you can:

• display, add, or delete IP addresses that the SwRPC layer uses to listen for the clientconnections (Alliance Workstation and ADK-based clients)

• display, add, or delete IP addresses of SwRPC layer clients that Alliance Access accepts(Alliance Workstation and ADK-based clients)

• import server SSL certificates and display certificate information

Prerequisites

• The script must be run from the Alliance Access Administrator account

• The script is used to configure the Alliance Access instance that it is packaged with.

saa_configconnection tool location

<Alliance Access installation directory>/bin/saa_configconnection

Syntax

saa_configconnection



Procedure



3. Enter the saa_configconnection command.

For command location and syntax, see "saa_configconnection" on page 271.

The configuration program starts.

4. Make your choice from the menu options and provide responses to the prompts.

The default response is shown in square brackets in the format [default,<default_value>]

Note If the Alliance Access servers are running when the command is run, then theymust be restarted before your changes become effective.

27.3 saa_systemIntroduction

The saa_system tool provides a number of commands for administering Alliance Access.

This tool allows you to:

• archive messages and events

• take archive backups

• take database backups

• list archive backups

• restore archive backups

• run database and software integrity checks

• start and stop the Alliance Access servers

• get information about the status of the Alliance Access servers and database

• start and stop tracing

• list all Alliance Access instances on a host

• rename Alliance Access instances

• copy the Event Journal to a text file.

The saa_system tool is provided in the Alliance Access software and in the Remote APIsoftware.

Using Command Line Tools


Prerequisites

• The Alliance Access bootstrap must be running. See "Starting and Stopping the BootstrapService" on page 236.

• The saa_system commands must be run from the Alliance Access Administrator account.

saa_system tool location

<Alliance Access installation directory>/bin/saa_system

27.3.1 Displaying All saa_system Commands

Introduction

The saa_system command displays all the available commands and the syntax that you mustuse to run the commands.

Procedure



3. Enter the saa_system command.


27.3.2 Messages and Events Archives

Introduction

You can use the saa_system command to manage your archives. You can create, list, back up,restore, and remove archives.

27.3.2.1 Archiving Messages and Events

Introduction

You may archive messages and events using Alliance Workstation. Alternatively, you can usethe saa_system command.

Procedure



3. Enter the saa_system archive command.


If you are archiving messages, only days that have all messages completed can bearchived. The <NumberOfDays> variable is used to specify the number of days to beretained in the database (minimum 1, maximum 999).



27.3.2.2 Listing Archives

Purpose

The saa_system archive list command is used to list archives present in the database.

Procedure



3. Enter the saa_system archive list command.


27.3.2.3 Backing Up Archives

Purpose

The saa_system archive backup command is used to back up archives present in thedatabase. Alternatively, you can use the System Management application.

Procedure



3. Enter the saa_system archive backup command.

You must specify the type of archive, name of the archive, and the directory where thebackup is to be stored.


27.3.2.4 Removing Archives

Purpose

The saa_system archive remove command is used to remove archives from the database.

Procedure



3. Enter the saa_system archive remove command.

You must specify the type of archive and the name of the archive.




27.3.2.5 Restoring Archives

Purpose

The saa_system archive restore command is used to restore backed up archives to thedatabase. Alternatively, you can use the System Management application.

Note To restore archives created in previous releases of Alliance Access, you must usethe saa_system archive restoretar command.

Restoring Telex and Fax messages

You can restore Telex and Fax messages processed with releases earlier than release 7.0.However, due to database structural changes required to remove Telex and Fax functionalitiesfor release 7.0, the following fields are not restored:

• for Telex messages: Telex Number, Answerback, and Network application

• for Fax messages: Fax Number, CUI, and Network application.

Procedure



3. Enter the saa_system archive restore command.

You must specify the type of archive and the full path of the backup.


To restore archives made in previous releases of Alliance Access:

• Enter the saa_system archive restoretar command.

You must specify the type of archive, the name of the archive that you want to restore, andthe full path of the tar file containing the archive.


27.3.2.6 Putting Selected Events into a Text File

Purpose

You can use the saa_system readlog command to place events that belong to a specifiedperiod into a text file.

Procedure



3. Enter the saa_system readlog command.

You must specify the full path for the text file to be created.




27.3.3 Checking the Alliance Access Software Files

Purpose

You can use the saa_system integrity command to verify the integrity of the Alliance Accesssoftware files.

Procedure



3. Enter the saa_system integrity command.


27.3.4 Listing and Renaming Instances

Purpose

You can use the saa_system instance command to list all the instances on the host, and torename the current instance.

To list instances:



3. Enter the saa_system instance list command.


To rename the current instance:

1. Log on as root to the machine where Alliance Access is installed.

2. Ensure that the Alliance Access servers are stopped.


4. Enter the saa_system instance rename command.


5. After the running the command successfully, you must activate the change as follows:

1. Log out as root.

2. Log out as the Alliance Administrator.

3. Log on again as the Alliance Administrator.

The current instance is renamed according to the value specified. For more information, see"Instances" on page 241.



27.3.5 Checking the Alliance Access Database and Server

Purpose

You can use the saa_system status and saa_system dbintegrity commands to check thestatus of the Alliance Access database and servers, and also to detect unauthorised updates tothe Alliance Access database.

Procedure



3. Enter the saa_system status command.


You can specify database or server if you just want to check either of these. Withoutarguments, results for both are displayed.

If the servers are running, then the mode of operation is displayed.

4. To check the integrity of the database, enter the saa_system dbintegrity command.

For command syntax, see "saa_system" on page 284.

27.3.6 Starting and Stopping the Alliance Access Server

Purpose

You can use the saa_system command to start the server (in Housekeeping or Operationalmode), and also to stop the server.

You can restart the server by first issuing the saa_system stop command and then thesaa_system start command.

To start in Housekeeping mode



3. Enter the saa_system start housekeeping command.


To start in Operational mode


2. Open an Xterm window.

3. Enter the saa_system start operational command.




To stop the server



3. Enter the saa_system stop command.


27.3.7 Starting and Stopping Tracing

Purpose

You can use the saa_system command to start or stop tracing activities.

Prerequisite

To run tracing, you need a configuration file provided by SWIFT.

To start tracing



3. Enter the saa_system traceset command.


You must enter the directory and file name of the configuration file provided by SWIFT.

To stop tracing



3. Enter the saa_system tracereset command.


27.4 saa_configbootstrapPurpose

The saa_configbootstrap command is used to configure the Alliance Access Name Serviceand Bootstrap Service to start automatically at system boot time.

Prerequisite

The saa_configbootstrap tool must be run using the root account.



27.4.1 Starting the Alliance Access Name Service at BootTime

Overview

You can set the Name Service to start automatically after a system boot. This is done by usingthe saa_configbootstrap command.

This command can only be issued from the root account.

How to revert back to manual starting of the Name Service is described at the end of thissection.

To start the Name Service at boot time:

1. Log on as root or type:

su root


3. Enter the saa_configbootstrap -nameservice command.

For command location and syntax, see "saa_configbootstrap" on page 270.

Changes are made to the /etc/rc.shutdown file, and the file /etc/rc.d/rc2.d/S999saans iscreated.

To revert back to manual startup:

• Remove the changes made to the /etc/rc.shutdown file

• Remove the file /etc/rc.d/rc2.d/S999saans

27.4.2 Starting the Alliance Access Bootstrap Service at BootTime

Overview

You can set the Bootstrap Service to start automatically after a system boot. This is done byusing the saa_configbootstrap command.

This command can only be issued from the root account.

How to revert back to manual starting of the Bootstrap Service is described at the end of thissection.

To start the Bootstrap Service at boot time:

1. Log on as root or type:

su root


3. Enter the saa_configbootstrap -bootstrap command.

For command location and syntax, see "saa_configbootstrap" on page 270.

Changes are made to the /etc/rc.shutdown file.

The following file is added:



/etc/rc.d/rc2.d/S999saabootstrap_<instance_name>

Where <instance_name> is the name of the Alliance Access instance for which theAlliance Access Bootstrap Service is configured.

To revert back to manual startup:

• Remove the changes made to the /etc/rc.shutdown file

• Remove the file /etc/rc.d/rc2.d/S999saabootstrap_<instance_name>

27.5 saa_bootstrapPurpose

The saa_bootstrap tool can be used to:

• start or stop the Alliance Access Name Service

• start or stop the Alliance Access Bootstrap Service, and the Alliance Access database.

Running the script produces either confirmation or error messages. Logging information is keptin the system log file and in the file saa_bootstrap.out.<x>, where <x> is a value from 0through 5. This allow for six logs to be kept. This file is created in the log sub-directory of theinstallation directory (that is, $ALLIANCE/log/).

Prerequisite

The saa_bootstrap tool must be run using the Alliance Access Administrator account.

Tool location

The command is located in bin sub-directory beneath your installation directory.

You can run the command in the following ways:

• By navigating to the bin sub-directory beneath your installation directory and entering thecommand from there.

• From another directory, by specifying the full path to the command, and the command itself.

About the system log file

The system log is a mechanism provided by UNIX systems to gather activity reports from thesystem and user processes. It can be configured to only record a particular level of errormessages, or only a few selected sources of error messages.

If you wish to record all the messages coming from saa_bootstrap are to be recorded forreview later, you must do the following:

1. The syslogd daemon must be running (this is a UNIX service)

2. It must be properly configured. This is done in the file /etc/syslog.conf. This file mustsimply contain a line like:

user.info <path to a log file (typically /tmp/syslog.out)>This instructs syslogd to record messages coming from all user sources (among whichsaa_bootstrap) in the given file.

3. To activate the new configuration, type:



kill -HUP <pid of syslogd>From this point on, the system log file contains messages from saa_bootstrap about the startand stop of the database or servers, whether the database was shut down and automaticallyrestarted, and so on.

27.5.1 Starting and Stopping the Name Service

To start the Name Service:


2. Enter the saa_bootstrap -nameservice start command.

For more information about the command and its syntax, see "saa_bootstrap" on page 270.

To stop the Name Service:


2. Enter saa_bootstrap -nameservice stop command.

27.5.2 Starting and Stopping the Bootstrap Service

To start the Bootstrap Service:


2. Enter the saa_bootstrap start command.


To stop the Bootstrap Service:


2. Enter the saa_bootstrap stop command.


27.6 Alliance CIFA ExportDescription

Using the script $ALLIANCE/BSS/bin/$ARCH/export_cif, you can export selectedinformation from the Correspondent Information File application (CIFA) to the screen (stdout) orto an ASCII file.

Using the export_cif script, the following information can be exported:

• The Correspondent File (CORR)

From the UNIX command line, the command is issued using the following syntax:

export_cif -c | -h



Where the following is the output of the -h help option:

-c : all correspondent (corr) info-h : helpThe output of the command is sent to stdout by default, any errors are sent to stderr. It is up tothe user to redirect the output to a file. This can be achieved using the redirect operator asfollows:

export_cif -c > correspo.txtThis creates the text file correspo.txt and it contains all information contained in theCorrespondent File. The exported information is formatted with each record separated by ablank line. As an example, here is the export layout for the Correspondent File (CORR):

BIC Code : <corr_X1>

27.7 TCP/IP Service FilesDescription

Alliance Access relies on TCP/IP settings which are contained in operating system files and theAlliance Access database.

The following operating system files are maintained by operating system commands and/orAlliance Access:

• /etc/hosts - maps remote host names to their IP addresses (when DNS is not used).

• /etc/services - maps port numbers and the associated TCP protocol, to service names

The following TCP/IP related settings are managed by the saa_configconnection tool:

• RPC Interfaces - which IP addresses the SwRPC layer uses to listen for the clientconnections (Alliance Workstation, ADK-based clients, and CAS MXA)

• Allowed Workstations - specifies which SwRPC layer clients (Alliance Workstation and ADK-based clients) that Alliance Access accepts.

Tip Normally CAS MXA creates TCP/IP sockets with the IP address associated withthe command "hostname". In a cluster environment, this may causecommunication problems as the TCP service would only listen to the networkadapter with address <hostnameIP>. 5101. If you have such a problem, thenspecify the correct IP address as the very first entry in RPC interfaces using thesaa_configconnection tool.

When using the interactive connection method to connect to a host, service names arereferenced by message partner profiles using the term Connection Identifier. For moreinformation about the /etc/services file and message partner profiles, see "Managing MessagePartner Profiles" in the System Management Guide.

27.8 The Reset Message Partners (reset_mp) ScriptOverview

The reset_mp script is used to reset and disable a message partner. The tool is password-protected and you must contact Support to use it.



The tool must only be used when the Alliance Access servers are not running.

To start the tool and reset a message partner:


2. Enter the reset_mp command.

For command location and syntax, see "reset_mp" on page 269.

3. You are then required to enter a user name and password. You must be an Alliance userthat has the Bank Query permission.

4. An ID to be used is displayed on the screen. This ID must be communicated to Support.You then receive an appropriate password to be typed in.

Usage:

The switch reset_mp -h displays the syntax of the command.



28 TCP Configuration for the Alliance AccessServer

28.1 Port ConfigurationDescription

The TCP configuration defines the ports used by the Alliance Access servers in thealliance_ports file (located in /usr/swa). A base port and range of ports for each AllianceAccess instance are created by Alliance Access during the installation of, or migration to,release 7.0.

The range for the server ports is 6, and these are required for critical processes of AllianceAccess. The Alliance swa_boot process (previously swa_rpcd) has only one port. The defaultnumber of ports for Alliance Web Platform (for example, for Messenger) is three.

Alliance Access allocates default ports that are not currently in use by the system (not usedin /etc/services).

The file has the following format:

alliance swa_boot <swa_boot_port>

server <instance_name1> <base_port1>

messenger <instance_name1> <base_port1>

server <instance_nameN> <base_portN>

messenger <instance_nameN> <base_portN>

The messenger entry is used for specifying the ports used when accessing Alliance Accessthrough web services.

The following is an example of the alliance_ports file:

alliance swa_boot 48009

server SAA_TEST 48100

server SAA_LIVE 48200

messenger SAA_LIVE 48300

messenger SAA_TEST 48400

In this example, the following ports are used by Alliance Access instances:

alliance swa_boot 48009

server SAA_TEST 48100

48101

48102

48103

48104

48105

48106

TCP Configuration for the Alliance Access Server


server SAA_LIVE 48200

48201

48202

48203

48204

48205

48206

messenger SAA_LIVE 48300

48301

48302

messenger SAA_TEST 48400

48401

48402

The Alliance Administrator can modify this file if other default base_ports (<base_portN>) mustbe used for the Alliance Access servers. If the swa_boot port is changed (default 48009), thenthe configuration for each Alliance Workstation connected to the server must be changed toselect this new port.

If the file is changed by the System Administrator, then the apply_alliance_ports tool mustbe run to update the operating system files. The ports for the servers and swa_boot must not bechanged.

Using firewalls

If you use a firewall blocking port between Alliance Access and Alliance Workstation, then checkbefore the installation whether the "default ports" are free.

If they are, then you can already configure these ports on the firewall to allow an AllianceWorkstation to connect to the Alliance Access server.

28.2 apply_alliance_ports ToolIntroduction

After any change to the alliance_ports file, the operating system files (/etc/ services) must beupdated with the new ports allocations using the apply_alliance_ports tool (locatedin /usr/swa). This tool must be run by root with the Alliance Access servers shut down.

To run the tool, type:

cd /usr/swa./apply_alliance_ports -<option>> <instance name>Where:

-<option> = I to update the ports for a specific instance

R to remove the ports for a specific instance

<instance_name>= the instance



Note that in a cluster environment, the apply_alliance_ports tool must be run on eachnode of the cluster to update /etc/services.

Note The comment # SWIFTAlliance_SWRPC is a reserved comment and must onlybe used for apply_alliance_ports.

28.2.1 Handling Multiple Network Cards - IP AddressConfiguration

Description

By default, only one IP address is used by the Alliance Access servers for RPC communicationand is obtained at the startup of the servers. In a system with multiple network cards (which usedifferent IP addresses), or a UNIX cluster environment, the default behaviour can be overruledby running the "saa_configconnection" tool.

For a system with multiple network cards, you must run the "saa_configconnection" tool todeclare all the IP addresses used on the system (use option 1: Configure Interfaces).

If you want to prohibit the use of an IP address for the RPC communication, then it is thesystem administrator's responsibility to ensure that the IP address is removed from theconfiguration.

28.2.2 Instances

Description

When an instance is created or renamed, the alliance_ports file is updated to add or renamethe instance, and the apply_alliance_ports tool is run.

If an Alliance Access instance is removed, then the Uninstaller program automatically removesthis instance from the alliance_ports file.

If an Alliance Access instance is renamed, then the swa_boot and saa_bootstrap processesmust be stopped and restarted.

28.2.3 Installation

Description

The installation process adds an entry in the alliance_ports file for the new Alliance Accessinstance. If the file does not exist, then it is created.

TCP Configuration for the Alliance Access Server


29 General TroubleshootingIntroduction

As with many complex applications, if one file or program is altered in any way, the completesystem may not operate correctly or even at all.

Alliance Access provides the following facilities to assist with troubleshooting, should problemsarise:

• The Alliance Configuration Report

The Report facility produces a formatted report on the current configuration of your AllianceAccess system. This facility is particularly useful for remote diagnostic purposes. Shouldproblems arise, the script may be run and the resulting report faxed to Support to verify thatthe system is correctly configured or to identify configuration problems.

• The JOURNAL_query Facility

This facility allows you to query the Event Journal of Alliance Access, without having to signon to Alliance Access and use the Event Journal application. JOURNAL_query may also beused for diagnostic purposes if the Alliance Access user interface is unavailable or cannot bestarted.

• Pre-installation Check

The checkhost command is used before an installation to check the software andresources that are currently available on the customers machine. All hardware and softwarechecks associated with the installation procedure are carried out by this script and the resultcan be made available as a text file. Customers can fax or e-mail this text file to Support tooutline the resources of their machine in cases of performance or installation problems.

For information about invoking this script, see "Checking Your System Configuration" onpage 91.

• Software Integrity Check

The saa_system integrity command checks whether the Alliance Access software fileshave been altered since installation.

29.1 The Alliance Configuration ReportOverview

The Report command, from the File menu of the System Administration application, allows youto generate a system status report. This report, which may be output to screen, file or printer isuseful for diagnostic purposes and may also be used to record the current status of yoursystem.

To generate a configuration report:

1. Log on to the Alliance Administrator account, using the current password. The main windowof the System Administration application will appear.

2. Select the Report command from the File menu.



3. In the Output To field, select the target destination for the report. Choose from:

• Screen: The text of the report will be displayed in the scrolling text area in the mainwindow of the System Administration application. Use the scroll bars to view thecontents of the report.

• Printer: The text of the report will be sent to your printer. You will be asked to enter thename of the printer. Printed reports are formatted for A4-sized paper, suitable for FAXtransmission. If problems arise, use this option to generate a status report and fax it toSupport for first-level diagnosis.

• File: The text of the report will be written to a file. You will be prompted to enter the pathname of the file in which the report is to be written.

4. In the Filter field, select the type of information you require:

• All Information: All of the following information is included in the report.

• Operating System: Details related to your operating system are included in the report.The report includes a list of the OS patches and packages currently installed on thesystem. A check is also made to diagnose any patch mismatches.

• File Systems: Details related to the file systems currently defined are included in thereport.

• Licensed Options: Details related to the packages, servers and licensed destinationsdefined at licensing are included in the report.

• Hardware Configuration: Details related to hardware such as disk drives, networkadaptors, and so on are included in the report.

• TTY Configuration: Details relating to the status of the serial ports are included in thereport (only if your system has such ports).

• Alliance Release: Details of the installed Alliance Access release are included in thereport.

• Patches: Details of the patches installed on your system are included in the report.

• Paging Space: Details of the paging space on your system are included in the report.

5. Having selected the type of report and destination, click OK .

The type of report selected is generated and output to the screen, file, or printer.

General Troubleshooting


29.2 The JOURNAL_query FacilityOverview

Alliance Access maintains an audit trail of all significant actions performed by Alliance Accessusers and by the Alliance Access system itself. Each significant action is referred to as an'event' and is recorded in an audit file known as the Event Journal.

The Event Journal provides the primary means by which all user and system-related activitymay be monitored. All events are categorised and may be defined as security events or asalarms.

Within Alliance Access, a dedicated application (the Event Journal application) is used to querythe Event Journal and to generate reports. However, the Alliance Access system administratordoes not normally have access to the applications within Alliance Access and, even if he has, ifa problem has occurred which makes the user interface unavailable, the Event Journalapplication cannot be used.

The JOURNAL_query facility enables the Alliance administrator to monitor the Event Journalfrom within the System Administration application, without having to sign on to Alliance Access.

To monitor the Event Journal:

1. Log on with the Alliance Administrator account, using the current password. The mainwindow of the System Administration application will appear.

2. Select the Journal_Query command from the Alliance menu.

The entries you make in the above window are used to instigate a search of the EventJournal. The results of this search may be directed to the scrolling text area of the mainwindow, to a printer or to a file.

3. In the Start Date/Time and End Date/Time fields, enter values to determine the scope ofthe search. For example, if a problem has occurred recently then request all events whichhave occurred in the last 15 minutes. Dates must be entered in the form DD/MM/ YY andtimes as hh:mm:ss, using 24-hour notation. Where no dates or times are entered, thecurrent day from midnight onwards is taken.



4. In the Output To field, select the destination for the search results. Select from:

• Screen (the scrolling area of the main window)

• Printer (you will be prompted to enter the name of a printer)

• File (you will be prompted to enter the name of a file)

5. The Number of Records field is used to limit the total number of records sent to the printeror a file when you have selected Printer or File in the previous step.

Where you have selected Screen in the Output to field, then the Number of Records fieldvalue is used to navigate through the output when using the Next and Previous buttons. Inthe Number of Records field, select the number of records you want to skip when usingthe commands Next and Previous.

Where no value is specified here then the default value of '1' is taken. The informationextracted from the Event Journal is held in a buffer. All operations using the commandsNext and Previous will begin scrolling through the buffer with reference to the number ofrecords specified here.

6. The Search Filter field allows you to input-specific criteria so as to locate particular types ofevent. This field may be used ONLY in consultation with Support and when specificinvestigations are conducted.

7. Events are recorded in the journal in a 'plate-stack' manner, where the latest event isalways situated at the top of the stack. Consequently, the earliest event will always befound at the bottom of the stack. The Event Journal is a large file and even a simple searchcan yield a significant number of events. To display particular events:

• Use the scroll bar at the side of the main window to scroll through the events displayed

• Use the Top and Bottom commands to move to the top (most recent) event in thewindow or to the bottom (oldest) event

• Use the Next and Previous buttons to jump backwards or forwards by the number ofevents specified in the Number of Records field.

8. When operating under the direction of Support, use the Search command to start aninterrogation of the Event Journal after entering criteria in the Search Filter field.

If the search in not successful a warning appears in the main window.

If successful, the result of the search is sent to a destination defined under the Output To

The main window of the System Administration application displays the result of the searchby default. This can be found directly beneath the search window.

Note This command is not available when Output To is set to 'Screen' or 'Print'.

General Troubleshooting




Part D

Appendices

Part D - Appendices




Appendix A

Setup Recommendations

A.1 Alliance Access for Service BureauxOverview

Alliance Access provides functionality to support a multi-banking environment for ServiceBureaux and includes:

• extended data segregation, with the capability to allow institutions served by a ServiceBureau to route only their own messages to their own Exit Points

• the ability to create "local" security officers, so that institutions served by a Service Bureaucan create and maintain their own set of operators

• the ability to restrict message text viewed in the event log, allowing a Service Bureau tocontrol whether the text of messages is stored in the event log or not.

Data segregation

Data segregation is achieved by controlling access through the APPLICATION Interface, andRouting applications using the permissions of each operator setup for an institution, as follows:

• APPLICATION Interface application:

– Open/Print Partner

– Open/Print Exit Point

• Routing application:

– Open/Print Routing Points

For each permission it is possible create a list of either the "allowed" or "prohibited" entities (thatis, Message Partner, Exit Point, or Routing Point) for the operator concerned.

For details about setting up permissions, see "Managing Alliance Access Security" in theSystem Management Guide.

Local security officers

When the "Restrict Delegation" configuration parameter is set, the Service Bureau can create"local" security officers for a served institution by granting them only "restricted delegation"rights. These security officers can be given access to, and delegation rights for, a subset ofOperator Profiles, Units and Licensed Destination, which are specific to the institutionconcerned. The "local" security officers can be used by the institution to create and maintaintheir own set of operators, by delegating rights, and permissions which belong to their restrictedsubset only.

For details about setting up local security officers, see "Setting Up Local Security Officers" in theSystem Management Guide.

Appendix A - Setup Recommendations


Restrict message text viewed in event log

The Service Bureau can also control whether the text of messages is journalised in the eventlog or not. This can be used to ensure that the text of messages of an institution is not viewableby another user.

See the Security Guide for details of how to set up security parameters.

Example setup

A setup like the following can be used to achieve a typical Service Bureau configuration:

• Naming conventions

The Service Bureau must first define the naming conventions, for example, entities can startwith the first four characters of the BIC of the served institution as follows:

Institution: AAAABEBB

Exit Points: AAAA_EP1 and AAAA_EP2,

Message Partners: AAAAFileOutput1, AAAAFileOutput2, and AAAAPrinter1.

Such a naming convention facilitates the use of wild-card characters when setting up thenames of "allowed" or "prohibited" entities.

• Security Definition application

The Service Bureau gives the operators of the served institution, the permissions to managetheir own Message Partners and Exit Points. Alternatively, the Service Bureau can create"local" security officers for the institution so that the institution can create and maintain itsown operators.

For details about setting up operator permissions and creating local operators, see"Managing Alliance Access Security" in the System Management Guide.

• APPLICATION Interface application

– For each institution served by the Service Bureau, the Service Bureau can create a UserDefined Queue (UDQ), for example, AAAAUDQ for institution AAAABEBB and BBBBUDQfor institution BBBBBEBB.

For more information, see "Configuring Queues" in the System Management Guide.

– Operators of the institution that have been given the correct permissions can only assignExit Points to a Message Partner or a Message Partner to an Exit Point according to thelist they manage.

• Routing application

– The Service Bureau defines the routing of the _SI_from_SWIFT queue to each institution.

Messages arriving in the _SI_from_SWIFT queue are routed to the institution-specificUDQ, based on the message receiver (BIC8).

– Operators of the served institution, define the routing of their own UDQ (optionally this canbe done by the Service Bureau as well). Messages arriving in an institution-owned UDQare routed according to the specific requirements of the served institution.

See "Message Routing" in the System Management Guide for more information.



A.2 Alliance Access as Standalone Message Entryand Repair System

A.2.1 Overview

Systems and licences required

You can set up Alliance Access as a standalone message entry/repair system for MT and XML-based messages. This setup requires that the standalone Alliance Access server is licensedwith option 07:STANDALONE REC. This licence option cannot be ordered individually. It is partof a specific licence package, allowing the configuration of a dedicated Alliance Access systemfor standalone message entry/repair next to a master Alliance Access system.

Within such a configuration, the standalone Alliance Access server has no connectivity toSWIFT. This allows for the segregation of the manual message entry/repair activity from thestraight through processing of SWIFT traffic.

Such a configuration requires at least two Alliance Access systems:

• a standalone Alliance Access server, with no connectivity to SWIFT, which allows manualentry and repair of MT and XML-based messages, and which can also receive messagesthrough batch input sessions

• a master Alliance Access system connected to SWIFT.

Both Alliance Access systems must use WebSphere MQ to exchange MT and XML-basedmessages. WebSphere MQ connectivity is provided by the native Alliance Access WebSphereMQ Host Adapter, using the XMLv2 data format to exchange MT and XML-based messages.

Note The activation of the MQ Host Adapter on the master Alliance Access systemrequires licence option 13:MQ HOST ADAPTER.

The following figure summarises the supported architecture of such a configuration.



Figure 1 - Standalone message entry and repair configuration

D0

54

01

67

SWIFT

Back-Office

Central Middleware Infrastructure

TR_REC

MQ Host

Adapter

TR_REC

MQ Host

Adapter

StandaloneAlliance Access 1

StandaloneAlliance Access 2

MQ Host

AdapterMaster Alliance Access

system(s)

XMLv2 XMLv2

XMLv2

A.2.1.1 Message Creation

Overview

The primary function of a standalone Alliance Access system is to support the manual creationof MT and XML-based messages. The messages created on the standalone Alliance Accesssystem are handled by the central middleware infrastructure like any other messages created byback-office applications.

Moreover, messages can be input in the standalone Alliance Access system through the variousadapters available: File Transfer or MQ Host Adapter, for example.

To support the manual creation of MT and XML-based messages, along with reconciliation ofthe network transmission notifications generated on the master Alliance Access system, astandalone Alliance Access system includes the following functionality:

• the creation of an input message on the standalone Alliance Access system

• the transmission of the message through the MQ Host Adapter to the master Alliance Accesssystem



• the reception of network transmission notifications from the master Alliance Access systemover the native MQ Host Adapter, and their reconciliation with the corresponding inputmessage

• the reception of delivery notifications over the native MQ Host Adapter, and theirreconciliation with the corresponding input message. This requires that the Logical Terminals(LTs) used on the standalone and on the master Alliance Access systems have the samelogical terminal code and the same message syntax table assigned.

The reconciliation, on the standalone Alliance Access system, of the received deliverynotification with the input message initially sent requires that the LT code of the inputmessage and the LT code of the delivery notification are identical.

Note The transmission notification generated on the master Alliance Access is a newmessage instance of type transmission notification.

The delivery notification sent from the master Alliance Access to the standaloneAlliance Access is actually a delivery notification system message, as receivedfrom the network.

A.2.1.2 Message Repair

Overview

The standalone Alliance Access system also supports the repair of messages created by back-office applications, when NACKed by SWIFT. In this configuration, the messages created by theback office and that were NACKed, can be forwarded to the standalone Alliance Access systemfor manual repair, and then sent back to the master Alliance Access system.

To support this repair function, the standalone Alliance Access system includes the followingfunctionality:

• the reception of a network transmission notification that includes the details of the originalmessage over the native MQ Host Adapter

• the creation of an input message, on reception of the above transmission notificationcontaining the details of the original input message.

A.2.2 Key Features of a Standalone Alliance Access System

Overview

A standalone Alliance Access system has mainly three features:

• it has no connectivity to SWIFT: as a result, the time required for the reception of anacknowledgement is longer than when Alliance Access is connected to SWIFT

• Real-time InterAct messaging is not supported through a standalone Alliance Access system:the business response of real-time InterAct messages cannot be forwarded from the masterAlliance Access system to the standalone Alliance Access system.

• it introduces a dedicated logic to reconcile the received transmission notifications with themessages created on the standalone Alliance Access system. If the reconciliation fails for anegative transmission notification, then the creation of a repair message is possible.

• it allows, through a security parameter, to check whether an RMA authorisation exists,although the Alliance Access system has no connectivity to SWIFT.



A.2.2.1 Use of the "OTHER" Network

Overview

The default Alliance Access routing rules make use of the "Route To Addressee" action to routethe messages to the preferred correspondent network, which in most cases is the SWIFTnetwork, resulting in messages being sent to the "_SI_to_SWIFT" queue (for FIN).

With a standalone Alliance Access system, the messages must not be routed to the"_SI_to_SWIFT" queue but to the exit point associated to the WebSphere MQ message partnerthat will communicate with the master Alliance Access system. Multiple exit points may exist ifcommunication with multiple master Alliance Access systems is implemented.

To facilitate the routing to specific exit points, the preferred network (when creating a message)is set to "OTHER" by default. To achieve this, when a Full Bank File or a Bank Update File isinstalled, the "OTHER" network is selected as preferred network, instead of the SWIFT andSWIFTNet networks. Similarly, when a new correspondent is defined manually in theCorrespondent File application, its preferred network must be set to "OTHER". In this way, the"Route To Addressee" action used in existing routing rules routes the messages to the uniqueexisting "_OI_to_OTHER" queue. The only main routing change consists in defining theappropriate routing rules on the "_OI_to_OTHER" queue to send the message to theappropriate exit points associated to the WebSphere MQ message partner(s).

A.2.2.2 The _AI_waiting_ack Queue

Overview

Normally, for an Alliance Access system directly connected to SWIFT, the acknowledgementfrom the SWIFT network is received very quickly: the 'Waiting Ack' state is a very short transientstate.

With a standalone Alliance Access system, the "Waiting Ack" state may last much longer. If thenetwork transmission is held in the master Alliance Access system or, following a configurationerror, is not routed back to the standalone Alliance Access system, then this "Waiting Ack" statecould last forever, until a manual action is taken.

To cope with this potentially long "Waiting Ack" state, the standalone Alliance Access systemuses the "_AI_waiting_ack" queue. This queue holds the messages waiting for the networktransmission notification from the master Alliance Access system.

A routing rule must be added to the exit point associated with the WebSphere MQ messagepartner so that the messages get routed to the "_AI_waiting_ack" queue after being sent to thecentral middleware.

A.2.2.3 Check for the Presence of an RMA Authorisation

Overview

The routing logic based on the "OTHER" network provides a straightforward routing change inthe standalone Alliance Access system to route the messages to the master Alliance Accesssystem. However, it does not check for the existence of a valid RMA authorisation at messagecreation. This is linked to the fact that the OTHER network is a user network and not a SWIFTnetwork.

To support RMA lookup, assuming that the relevant RMA authorisations are present in thestandalone Alliance Access system, the security configuration parameter "Check authorisationexist" is used. When the value of this parameter is set to "Yes", the check for the existence ofan RMA authorisation is performed at message creation, even for correspondents having"OTHER" as network.



A.2.3 Message Flows

Overview

This section details the three different flows that a standalone Alliance Access system provides:

• the creation and emission of MT or XML-based messages

• the reconciliation of transmission notifications with the created messages

• the creation of a repair message following the reception of a negative transmissionnotification that cannot be reconciled with an original input message

• the reconciliation of optional delivery notifications with the created messages.

A.2.3.1 Message Entry Flow

Overview

The scenario where messages are created on the standalone Alliance Access system impliesthe following:

• the support of the emission of the input message created on the standalone Alliance Accesssystem

• the reconciliation of the transmission notification received from the master Alliance Accesssystem with the created message.

For information about the optional processing of a network delivery notification received fromthe master Alliance Access system, see "Reception of Delivery Notifications" on page 259.

The following diagram gives an overview of the steps involved in this scenario for the creation ofan MT or an XML-based message.



Figure 1 - Message emission flow

D0540168

_OI_to_OTHER

StandaloneAlliance Access

MQ Host Adapter

XMLv2

Message

Back-Office

Application

Alliance

Workstation

1

1

Alliance

Web Platform

1

_AI_waiting_ackEP1 toMaster

XMLv2

Transmission

Report

MQ queueMQ queue

2

33

34

4

A.2.3.1.1 Emission of an Input Message

Overview

Referring to figure 1 (Message emission flow), the following steps occur:

1. The input message is created in either of the following ways:

– manually:

• from the Message Creation application in Alliance Workstation

• from Messenger on Alliance Web Platform

– the message can be input through a back-office application.

The input messages created in the standalone Alliance Access system are not sent to theusual queues _SI_to_SWIFT or _SI_to_SWIFTNet as this system has no connectivity toSWIFT. These input messages are routed to the _OI_to_OTHER queue.

2. From the _OI_to_OTHER queue, the message is routed to a specific exit point,EP1ToMaster, defined by the user, and assigned to a WebSphere MQ message partner.



3. Upon processing of the message by the WebSphere MQ message partner:

a. the message is queued on the standalone Alliance Access system in the_AI_waiting_ack queue awaiting the transmission notification

b. the message is queued as an XMLv2 message in a WebSphere MQ queue waiting forprocessing by the central middleware which routes this message for processing by themaster Alliance Access system.

To cater for this scenario, the following configuration tasks must be performed:

Task See section

Create exit points "Exit Points" on page 260

Create message partners "Message Partners" on page 260

Define routing rules associated to the exit points "Exit Points" on page 260

Update routing of _AI_from_APPLI "_AI_from_APPLI" on page 262

Update routing of _OI_to_OTHER "_OI_to_OTHER" on page 265

A.2.3.1.2 Reception of Network Transmission Notifications

Overview

When the input messages are queued in the routing point _AI_waiting_ack, they expect apositive transmission notification before being completed. The transmission notifications transitthrough the master Alliance Access system and can be either of the following:

• a network transmission notification received from the SWIFT network

• a transmission notification generated by the master Alliance Access system following a localrejection (for example, if there is no authorisation, or if the reception of the messages inApplication Interface fails).

Referring to step 4 in figure 1 (Message emission flow), the following occurs:

• The positive or negative acknowledgement received from SWIFT by the master AllianceAccess system generates a transmission notification (including original message details)which is queued in a specific WebSphere MQ queue for processing by the standaloneAlliance Access system.

The message partner associated with the WebSphere MQ queue containing the transmissionnotification reconciles it with the input message present in the _AI_waiting_ack queue basedon the original details it contains, and completes the message or puts it in the _MP_mod_textqueue if it has to be corrected.


Task See section


Update routing of _AI_waiting_ack "_AI_waiting_ack" on page 261




A.2.3.2 Message Repair Flow

Overview

The flow where messages originally created in back-office applications are repaired in thestandalone Alliance Access system implies the creation of an input message based on originalmessage details included in the transmission notification received from the master AllianceAccess system.

The following diagram gives an overview of the steps involved in this scenario for the repair of amessage.

Figure 2 - Message repair flow

D0540169

_OI_to_OTHER


MQ Host Adapter

XMLv2

Message

EP1 toMaster

XMLv2

Transmission

Report

MQ queueMQ queue

_AI_from_APPLI

1

1

_AI_waiting_ack

2

_MP_mod_text

The triggering event for this flow is the presence within a WebSphere MQ queue of a negativetransmission notification for a message which the standalone Alliance Access system has neverbeen aware of before.

Referring to figure 2 (Message repair flow), the following steps occur:

1. The message partner associated with the WebSphere MQ queue processes thetransmission notification and after failing to reconciliate against a message, creates aninput message based on the original details it contains.

2. The message is routed to the _MP_mod_text queue to allow its modification before re-emission. The emission steps are as described in "Message Entry Flow" on page 255.

The required configuration tasks are the same as in "Message Entry Flow" on page 255.



A.2.3.3 Reception of Delivery Notifications

Overview

A standalone Alliance Access system can receive delivery notifications from the master AllianceAccess system. It stores them and can route them to the existing _TR_REC queue forreconciliation with a local input message instance.

The following figure gives an overview of the processing related to the reception of deliverynotifications within the standalone Alliance Access system.

Figure 3 - Reception of delivery notifications

D0540170


MQ Host Adapter

_AI_from_APPLI

XMLv2

Transmission

Report

MQ queue

_TR_REC

1

1

2

The triggering event for this flow is the presence within a WebSphere MQ queue of a deliverynotification for a message sent by the standalone Alliance Access system.

Referring to figure 3 (Reception of delivery notifications), the following steps occur:

1. The message partner associated with the WebSphere MQ queue processes the deliverynotification.

2. The message is routed to the _TR_REC queue to allow the reconciliation with the inputmessage.


Task See section





A.2.4 Configuration of the Standalone Alliance AccessSystem

A.2.4.1 Creation of Exit Points and Message Partners

A.2.4.1.1 Exit Points

Overview

The input messages sent from the standalone Alliance Access system are queued in exit pointsfor further processing by the associated message partner.

For details about creating exit points, see "Managing Exit Point Profiles" in the SystemManagement Guide.

A.2.4.1.2 Message Partners

Overview

As the supported configuration for a standalone Alliance Access system is based on the nativeMQ Host Adapter, you must create the message partners with connection method 'WebSphereMQ' and data format 'XMLv2' revision 2, or above.

The emission message partner associated with the exit point sends the messages present inthe exit point to the defined WebSphere MQ queue.

The reception message partners process transmission or delivery notifications queued indifferent WebSphere MQ queues. If you want a repair input message created in case thereconciliation of a negative transmission notification fails, then you must activate the "Createrepair message" option of the message partner.

For details about creating message partners, see "Managing Message Partner Profiles" in theSystem Management Guide.

A.2.4.2 Routing Setup

A.2.4.2.1 Exit Points

Overview

The messages queued at exit points such as EP1ToMaster are routed to the _AI_waiting_ackqueue when successfully processed by the associated message partners.

First, the _AI_waiting_ack queue must be set as valid routing target for the exit points.

Note If an exit point or routing point is not visible in the Routing application, then use theSystem Management application to make it visible and allow modification of rules.For more information, see "Queue Details Window - Routing Info Tab" in theSystem Management Guide.

• From the Queue view in the System Management application, open the details ofEP1ToMaster

• From the Routing Info tab, move _AI_waiting_ack to the Selected list box as valid routingtarget



Define a routing rule like the following one for the EP1ToMaster routing point:

Sequence number 100

Description Source to _AI_waiting_ack

Condition on Function

Function Result Success

Action on Source

Action Route to _AI_waiting_ack

Append Intervention No Intervention

Unit Keep Current

Routing code NA

Priority Keep Current

A.2.4.2.2 _AI_waiting_ack

Overview

The routing rules associated to this queue must be defined based on the type of transmissionnotification:

• when a positive transmission notification is received, the original message instance must becompleted

• when a negative transmission notification is received, the original message instance must berouted to an investigation queue such as _MP_mod_text.

These routing rules are applied following a successful reconciliation of the receivedtransmission notification with an existing LIVE message instance in the _AI_waiting_ack queue.

Define routing rules like the following ones for the _AI_waiting_ack routing point:

• Positive transmission notifications

Sequence number 100

Description positive transm. notification

Condition on Message

Message (Network_delivery_status = Network_Acked)

Action on Source

Action Complete


Unit Keep Current

Routing code NA


• Negative transmission notifications

Sequence number 200

Description negative transm. notification




Message (Network_delivery_status = Network_Aborted)

or (Network_delivery_status = Network_N_A)

or (Network_delivery_status = Network_Nacked)

or (Network_delivery_status = Network_RejectedLocally)

or (Network_delivery_status = Network_TimedOut)

or (Network_delivery_status = Network_WaitingAck)

Action on Source

Action Route To _MP_mod_text


Unit Keep Current

Routing code NA


Note XML-based messages queued in MP_mod_text must be modified usingMessenger on Alliance Web Platform.

A.2.4.2.3 _AI_from_APPLI

Overview

You must update the routing rules associated with the _AI_from_APPLI queue to:

• ensure that input messages received through dedicated messages partners are properlyrouted to the _OI_to_OTHER queue

• route to the _MP_mod_text queue the input messages created in the standalone AllianceAccess system following a repair operation

• route the delivery notifications of MT and XML-based messages to the _TR_REC queue forthe reconciliation with the original input messages.

First, the OI_to_OTHER and_TR_REC queues must be set as valid routing targets for the_AI_from_APPLI queue.

• From the Queue view in the System Management application, open the details of_AI_from_APPLI.

• From the Routing Info tab, move OI_to_OTHER and_TR_REC to the Selected list box asvalid routing targets.

Define routing rules to cater for the following:

• The input messages (created by specific input message partners) are routed to the_OI_to_OTHER queue.

Sequence number 30

Description input to _OI_to_OTHER




Message (Instance_type = Original) and ((Src_entity ='FileInput') or(Src_entity ='MXFileInput')) and (Sub_format = Input)

where:

"FileInput" and "MX FileInput" are the message partners thathave processed the message for input in the standaloneAlliance Access system. If you use other message partners,then this condition must be updated.

Action on Source

Action Route to _OI_to_OTHER


Unit Keep Current

Routing code NA


• The input messages created following a repair operation (upon failed reconciliation in_AI_waiting_ack of a received negative transmission notification) are routed to the_MP_mod_text queue.

Sequence number 40

Description repair to _MP_mod_text


Message (Instance_type = Original) and (Src_entity = 'MPxxx') and(Sub_format = Input)

where:

'MPxxx' is the message partner that has processed thetransmission notification coming from the master AllianceAccess system.

Other criteria, such as Creating_mpfn orCreating_application, can also be used.

Action on Source

Action Route to _MP_mod_text


Unit Keep Current

Routing code NA


A similar routing rule must be set up for input messages created by the back-officeapplications, but which failed the middleware checks.

• The delivery notifications of MT messages are routed to _TR_REC to allow reconciliation withthe original input messages.

Sequence number 50

Description MT traffic reconciliation


Message (Mesg_type='010') or (Mesg_type='011') or(Mesg_type='012') or (Mesg_type='015') or(Mesg_type='019')



Action on Source and New Instance

Action on Source

• Action • Route to System

• Append Intervention • No Intervention

• Unit • Keep Current

• Routing code • NA

• Priority • Keep Current

Action on New Instance

• Type • Copy

• Action • Route To _TR_REC





• The delivery notifications of XML-based messages are routed to _TR_REC to allowreconciliation with the original input messages.

Sequence number 60

Description MX traffic reconciliation


Message (Nature = NETWORK_MSG) and (Format = 'Internal')


Action on Source

• Action • Route to MXSystem






• Type • Copy

• Action • Route To _TR_REC







A.2.4.2.4 _OI_to_OTHER

Overview

The user-defined queue _OI_to_OTHER is used to gather all the messages input eithermanually or by message partner within the standalone Alliance Access system. The routing of_OI_to_OTHER must route the messages to the defined exit points according to the definedrouting criteria. The main reason for using this routing point is to avoid changing the preferrednetwork of the correspondents defined in the Correspondent File (if the Route to Addresseerouting action is used).

You must define routing rules like the following one:

Sequence number 100

Description always to EP1ToMaster

Condition on Always or Message, if you want to customise the routing basedon message content (for example, for a given Sender LT toone master Alliance Access system, for another Sender LT toa different master Alliance Access system)

Action Route to EP1ToMaster


Unit Keep Current

Routing code NA


A.2.4.3 Message Preparation

Overview

To ensure that messages manually input in the standalone Alliance Access system are routedto the _OI_to_OTHER queue by default, the configuration parameter "Preferred Order" definedin the System Management application must be set to "OTHER,APPLI".

To dispose a message directly to _OI_to_OTHER, you must define the_OI_to_OTHER queueas valid routing target for the exit points and for the queues _MP_creation, _MP_mod_text,_MP_verification, and _MP_authorisation. For a specific queue, perform the following steps:

• From the Queue view in the System Management application, open the details of the queue

• From the Routing Info tab, move OI_to_OTHER to the Selected list box as valid routingtarget.

A.2.5 Configuration of the Master Alliance Access System

Introduction

In addition to the emission, and reception of messages to and from SWIFT, the master AllianceAccess system must forward the following to the standalone Alliance Access system:

• negative transmission notifications associated to messages originating from the standaloneAlliance Access system

• transmission notifications associated to messages created on the back-office applications



• delivery notifications associated to messages created on the standalone Alliance Accesssystem.

This requires that you set up exit points, message partners, and specific routing rules.

A.2.5.1 Exit Points and Message Partners

Overview

You must create two exit points:

• DLVtoAloneEP1, to collect all the delivery notifications to be sent to the standalone AllianceAccess system

• TRANStoAloneEP1, to collect all the transmission notifications to be sent to the standaloneAlliance Access system.

The emission message partners that process the transmission notifications must have the"Send Original Message" field set to "Always". This ensures that the original message is alsoincluded in the XMLv2 TransmissionReport.

For details about creating message partners, see "Managing Message Partner Profiles" in theSystem Management Guide.

A.2.5.2 Routing Setup

Overview

The following exit points are used to gather these transmission and delivery notifications:

• LocalSWIFTAcks and LocalMXAcks: positive transmission notifications

• LocalSWIFTNacks and LocalMXRejects: negative transmission notifications

• DeliveryNotifAcks, DeliveryNotifNacks, MXDeliveryNotifAcks, and MXDeliveryNotifNacks:reconciled delivery system messages with original messages sent. As such, the deliverynotifications are not routed to the standalone Alliance Access system, but the delivery systemmessages are.

As these notifications must be delivered in specific exit points, the routing for the followingrouting points must be updated:

• _SI_to_SWIFT for the transmission notifications associated to MT messages

• _SI_to_SWIFTNet for the transmission notifications associated to MX messages

• _SI_from_SWIFT for the delivery notifications associated to MT messages

• _SI_from_SWIFTNet for the delivery notifications associated to MX messages.

Other criteria than the ones present in the routing rules below can be used to refine the routingof these transmission and delivery notifications.

As on any Alliance Access system, the modification queues (such as _MP_mod_transmis) onthe master Alliance Access system must be monitored to ensure that all the traffic is properlysent to and received from SWIFT.

You must define routing rules like the following ones:

• For _SI_to_SWIFT



Route all transmission notifications related to messages originating from the standaloneAlliance Access system

Sequence number 50

Description transmission notifications

Condition on Message: (Src_entity=Message Partner which treated theinput messages coming from the standalone Alliance Accesssystem)


Action on Source

• Action • Complete






• New instance type • Notification Transmission

• Action • Route To TRANStoAloneEP1



• For _SI_to_SWIFTNet

Route all transmission notifications related to messages originated from the Alliance Accesssystem.

Sequence number 50

Description transmission notifications

Condition on Message: (Src_entity=Message Partner which treated theinput messages coming from the standalone Alliance Accesssystem)


Action on Source

• Action • Complete






• New instance type • Notification Transmission

• Action • Route To TRANStoAloneEP1





• For _SI_from_SWIFT

Route all delivery notifications to the standalone Alliance Access system.

Sequence number 50

Description delivery notifications

Condition on Message: (Mesg_type='011') or (Mesg_type= '012') or(Mesg_type='010') or (Mesg_type='015') or(Mesg_type='019')

Function Result = Success

Action Route To DLVtoAloneEP1


Unit Keep Current

Routing code NA


• For _SI_from_SWIFTNet

Route all delivery notifications to the standalone Alliance Access system.

Sequence number 50

Description delivery notifications

Condition on Message: (Nature = NETWORK_MSG) and (Format ='Internal')

Function Result = Success

Action Route To DLVtoAloneEP1


Unit Keep Current

Routing code NA




Appendix B

Command Line Tool Syntax ReferenceRunning commands

Note that the tool can be run in two ways:

• By entering the command from the directory where the tool is located.

• From another location. In this case, you must provide the full path, and the command.

B.1 checkhostTool location

<Alliance installation directory>/AIX/checkhost

Command syntax

checkhost.ksh [-req <pathname of requirements file]>] [-rootdir <pathname of a directory>] [-out <pathname of the report file>]

Parameters

Parameter Description Mandatory?

-req Used to specify the Alliance Access base requirements file, for acomparative analysis report.

-rootdir Used to specify the path to a drive or file system against which thecheckhost tool must perform a disk space validation.

-out Used to specify the location for the report file. If no location is specified, thereport is produced in the following default location:

/tmp/checkhost.log

-outxml Used to specify the location for the report file, and that the file is to be inXML format. If no location is specified, the report is produced in thefollowing location:

/tmp/checkhost.log

B.2 reset_mpTool location

<Alliance installation directory>/MXS/bin/AIX

Command syntax

reset_mp <Message partner name>

Appendix B - Command Line Tool Syntax Reference


Parameters


<Message partnername>

The name of the message partner to reset. Yes

B.3 saa_bankqueryTool location

<Alliance installation directory>/bin

Command syntax

saa_bankquery

Parameters


Support will provide details of any parameters that need to be entered.

B.4 saa_bootstrapTool location


Command syntax

saa_bootstrap [-timeout <value>] [-nameservice]start|stop

Parameters


-saastart Starts the Alliance Access servers.

If this parameter is not given, then the script uses the value of the StartupMode parameter (set in the System Management application) to decidewhether Alliance Access must be started.

stop Stops the Alliance Access servers.

-timeout <value> Defines a value, in seconds, after which the script stops if the AllianceAccess instance does not start or stop (depending on which is selected.The minimum value is 150 (seconds).

-nameservice The Alliance Access name service to be started or stopped.

B.5 saa_configbootstrapTool location




Command syntax

saa_configbootstrap -nameservice -bootstrap

Parameters


-nameservice Starts the Alliance Access Name Service at start time.

-bootstrap Starts the Alliance Access bootstrap service at start time.

B.6 saa_configconnectionTool location


Command syntax

saa_configconnection

Parameters


Make your choice from the menu options and provide responses to theprompts.

The default response is shown in square brackets in the format [default,<default_value>]

B.7 saa_dbconfigTool location


Command syntax

saa_dbconfig <entity> <command>

Parameters

Entity Command Description Mandatory?

memory -display Displays the amount of memory allocated for the databasememory regions.

Default value: 1500 MB.

-resize -all <Size> Changes the amount of memory allocated for the databasememory regions.

tablespace -display [-tablespace<Name>]

Displays the current location, allocated size and usage (inmegabytes) of all tablespaces or for a specified tablespace<Name>.



Entity Command Description Mandatory?

-move -tablespace<Name> -location<DestinationDir> [-size <Size>]

Move the tablespace <Name> to the location<DestinationDir>. System tablespaces (SYSAUX,SYSTEM) cannot be moved.

The -size option is only taken into account when moving thetablespace UNDO or TEMP (the Size is expressed in MB).

-resize -tablespace<Name> [-size <Size>| -optimal]

Re-sizes the tablespace <Name>to the size specified in<Size> (expressed in MB) or to its minimum required size(using -optimal).

Although all tablespaces are configured to automaticallyincrease in size, this allows setting or resetting the size of atablespace.

-reorganise -tablespace <Name> -location <TempDir>

Re-organises the specified tablespace <Name> to reclaimunused space and re-sizes it to its minimum required size.This requires sufficient free disk space to be available in the<TempDir> location to perform an export of the data.

This command only applies to user tablespaces (and notsystem tablespaces).

redolog -display Displays the current location and size of the redo log files.

-move -location<DestinationDir> -size

Moves all redo log files to a <DestinationDir> location andresizes them to the specified <Size> (expressed in MB). Theoriginal redo logs remain in the original directory, and need tobe removed manually if required.

B.8 saa_dbinfoTool location


Command syntax

saa_dbinfo <repdir> [-startdate <date> -starttime <time> -stopdate <date> -stoptime <time>]

Parameters


<repdir> Specifies the directory where the collected information is to be stored (in aZIP file).

Yes

-startdate <date> The start date, in the format YYYYMMDD.

-starttime <time> The start time, in the format HH:MM:SS.

-stopdate <date> The stop date, in the format YYYYMMDD.

-stoptime <time> The stop time, in the format HH:MM:SS.



B.9 saa_dbrecoveryTool location


Command syntax

saa_dbrecovery [-m] [-a -p <pathname_recovery_mirror_disk> -q <pathname_recovery_backup_disk> [-f <y|n>] [-i <y|n>]] [-d [-i <y|n>]] [-c] i [-c] f [-e <y|n>] [-r -p <pathname_recovery_mirror_disk> -q <pathname_recovery_backup_disk> [-z <n|s|a>] [-i <y|n>]] [-v -p <pathname_recovery_mirror_disk> -q <pathname_recovery_backup_disk> [-z <n|s|a>] -s <n|c|i> [-i <y|n>]] [-h]

Parameters


-m Displays the status of Database Recovery Mode, which can be:

• Activated

• Deactivated

If the Database Recovery Mode is Activated, then the command alsodisplays the total disk size and the free disk space available in MB for thelive disk and each recovery disk.

-a Activates the Database Recovery Mode.

You must specify the full path names of the mirror and backup disks.

-p <pathname_recovery_mirror_disk>

Specifies the full path name of the mirror disk.

-q<pathname_recovery_backup_disk>

Specifies the full path name of the backup disk.

-d Deactivates the Database Recovery Mode.

-f <y|n> Specifies whether a full recovery backup must be created as part of theactivation. The default value is y: a full recovery backup is created.

-i <y|n> Launches the tool in interactive mode when activating, deactivating, orrecovering the database:

• y: launch the tool in interactive mode

• n: use command-line parameters

By default, if you omit this parameter, then the tool prompts you for input.

-c f|i Launches a backup of the database :

• f: full database backup

• i: incremental database backup




By default, Alliance Access removes old database backups after creating anew full-database backup successfully. Optionally, you can remove oldbackups before Alliance Access creates new backup, by specifying the -eparameter.

-e <y|n> Alliance Access removes old backup before it creates a new backup.

By default, Alliance Access removes old database backups after creating anew full-database backup successfully.

-r Recovers the database.

You must specify the full path names of the mirror and backup disks.

-z <n|s|a>Enables or disables connectivity and Alliance Developers Toolkitcomponents:

• n: enables connectivity. This is the default value.

• s: disables SWIFT connectivity only

• a: disables all connectivity

-v Recovers the database from an incremental database backup. This ispartial database recovery.

You must specify the full path name of the mirror and backup disks.

-s <n|c|i> If the value of the Message Repair Action security parameter is Prompted,then you can use the -s parameter to specify how to repair messages afterthe database recovery.

The -s parameter can have the following values:

• n: leaves live message instances in their queue for further routing. Apossible duplicate emission is added to outstanding live messageinstances.

• c: completes all live message instances.

• i: routes all live message instances to the _MP_recovery queue, forfurther investigation.

If the value of Message Repair Action is not Prompted, then you cannotspecify how messages are repaired after this partial database recovery.The messages will be repaired according to the value specified for theMessage Repair Action parameter.

-h Displays help about the command and its parameters.

B.10 saa_dbrestoreTool location


Command syntax

saa_dbrestore -r -p <path name of database backup file> -s [a|o|s|r|c|d|w|m] -e [y|n] -n [y|n] -o [y|n] -w [y|n] -z [n|s|a] -i [y|n] -c -p <path name of database backup file> -s [o|s|r|c|d|w|m] -i [y|n]



Parameters

Parameters andOptions

Description Mandatory?

-r Restore database.

-c Consistency check.

In case of detected inconsistencies, a log file is generated. The format ofthe log file is restore_YYYYMMDDTHHMMSS.log, whereYYYYMMDDTHHMMSS is the timestamp when the check was done.

-p <path name ofdatabase backup file>

Specifies the path name where the database backup is located.

In case of hosted database, <path name of database backup file> isthe database directory itself (for example,20101025T104837_SAA_DATA_BACKUP).

-s [a|o|s|r|c|d|w|m] The entities to be checked or restored:

• a = all entities

• o = Operators only

• s = SWIFT interface only

• r = Routing information only

• c = Correspondents only

• d = ADK storage only

• w = SWIFTNet Interface only

• m = RMA authorisations only

-e [y|n] Specifies whether messages and events to be cleaned or not. Defaultvalue: n.

-n [y|n] Restore database even when no licence found on target system. Defaultvalue: y.

-o [y|n] Restore Operators even when the set of operators is not identical. Defaultvalue: y.

-w [y|n] Restore SWIFTNet related information. Default value: y.

-z [n|s|a] Disable Connectivity and Alliance Developers Toolkit components:

• n = no (default value)

• s = SWIFT Connectivity only

• a = all

-i [y|n] Run the script in interactive mode. Default value: y.

B.11 saa_exportTool location




Operator session

Your Alliance Access licensing agreement allows only a certain number of operators to use thesystem concurrently. Running this tool starts an operator session with Alliance Access, and thissession is included in the count of concurrent users of the system.

Command syntax

saa_export -parameterfile <export_parameter_file> -exportfile <export_file> [-user|-application <username>] [-password <password>] | [-passwordfile <password_file>] [-exportsensitivedata] [-overwrite] [-port <port_number>] [-reportfile <file_pathname>] [-summaryonly]

Parameters


-parameterfile<export_parameter_file>

The name of the export parameter file that contains the list of entities (alongwith filtering criteria, if specified) that must be exported.

Yes

-exportfile<export_file>

The name of the export file that will contain the exported data, as a result ofa successful export process.

Yes

-user <username> The name of the Alliance Access operator of type Human executing thecommand.

If omitted and no -application argument is specified, then the operatorexecuting the command must be all_adm.

-application<username>

The name of the Alliance Access operator of type Application executing thecommand.

If omitted and no -user argument is specified, then the operator executingthe command must be all_adm.

-password <password> The password of the Alliance Access operator.

You can use one of the options to specify the password:

• -user|-application <username> -password <password>: Enter theuser name and password in the command line.

• -user|-application <username> -passwordfile <passwordfile>:Specify the password file name, which contains the password. Thepassword included in the password file is not encrypted. Accessing thepassword depends on the access rights associated to the password file.

• -user|-application <username>: You are prompted to enter thepassword when you launch the tool. This is the most secured option.

-passwordfile<password_file>

The name of a file that contains the password of the Alliance Accessoperator.

-exportsensitivedata Indicates that sensitive data will be exported and stored in the export file.

-overwrite Indicates whether the data in the existing export file must be overwritten.

If you enter this parameter and the export file exists before you launch theexport tool, then it indicates that the export file will be overwritten. If you donot enter this parameter but the export file exists, then the export processstops.




-port <port_number> The port number of the localhost in which the Alliance Access is listening.Default port number: 48200.

-reportfile<file_pathname>

The name of the report file in which details of the export are logged. If a filewith that name already exists, then Alliance Access overwrites it.

-summaryonly If specified, the produced export log contains less information about theentity occurrences exported.

B.12 saa_importTool location


Operator session


Command syntax

saa_import -exportfile <export_file> [-user|-application <username>] [-password <password>] | [-passwordfile <password_file>] [-overwrite] [-port <port_number>] [-reportfile <file_pathname>] [-summaryonly]

Parameters


-exportfile<export_file>

The name of the export file containing the configuration data to export. Yes















The name of the password file that contains the password.

-overwrite The import mode. Specify this parameter to update the existing entities. Ifyou do not specify the parameter, then the update is skipped.


-reportfile<file_pathname>

The name of the report file in which details of the export execution arelogged. If a file with that name already exists, then Alliance Accessoverwrites it.

-summaryonly If specified, the produced import log contains less information about theentity occurrences imported.

B.13 saa_manageTool location


Operator session


Exit codes

The saa_manage tool returns the following main exit codes:

• 0: the command has been performed successfully

• 255: the command failed

• 1: the command has been performed successfully for some entity occurrences, but not for all

In some cases, other exit codes may be returned. If the exit code is different from 0, then checkthe output file generated by saa_manage for further details.

Command syntax

saa_manage -manageparameterfile <manage_parameter_file> -manageoutputfile <manage_output_file> -action <action> <action parameter 1, action parameter 2, ...> [-user|-application <username>] [-password <password>] | [-passwordfile <password_file>] [-port <port_number>] [-overwrite]



Parameters


-manageparameterfile<manage_parameter_file>

The name of the file containing the entity type and occurrences to bemanaged. The file can contain all occurrences or a subset of occurrences,identified by their entity identifier fields.

If the file is not located in the current directory, then type the path and nameof the file.

Yes

-manageoutputfile<manage_output_file>

The name and path of the file that will contain the output of themanagement action (for each occurrence, if the action has been successfulor not, as well as any relevant result).

Yes

-action <action><action parameter 1,action parameter2, ...>

The action that must be performed on the specified occurrences and itsrelated parameters, if any. These parameters can be either values orkeywords preceded by a - and followed by a value.

Parameter keywords (such as -ltdirqueue are case sensitive.

For more information, see "Action Parameters" on page 225.

Yes












The name of the file that contains the password of the operator.

If the file is not located in the current directory, then type the path and nameof the file.


-overwrite When this option is specified, if the file specified by the -manageoutputfile parameter exists, then it is overwritten.

B.14 saa_manageaspTool location




Operator session


Syntax

saa_manageasp [-user|-application <username>] [-password <password>] [-passwordfile <passwordfile>] [-l <Full ASP Package Filename>] [-h]

Parameters

Parameter Description

-user|-application <username> Name of the Alliance Access operator of type Human (-user),or Application (-application) executing the command. Theoperator must have the Manage ASP function in their profile.

Optional.

If omitted, then the operator executing the command must beall_adm.

-password <password> Password of the Alliance Access operator.

Optional.

If present, -user must be present too. Must be omitted if -passwordfile is present.

-passwordfile <passwordfile> Name of the file containing the password of the AllianceAccess operator. Allows the password to specified in a fileinstead of in the command line.

Optional.

If present, -user must be present too. Must be omitted if -password is present.

-l <Full ASP Package Filename> Installs all the ASP files included in the ASP package to install(full file name is required).

-h Provides a list of the different options and their meaning.

B.15 saa_monitorTool location


Exit codes

The saa_monitor tool returns the following main exit codes:

• 0: the command has been performed successfully

• 255: the command failed

In some cases, other exit codes may be returned. If the exit code is different from 0, then checkthe output file generated by saa_monitor for further details.



Command syntax

saa_monitor -monitorparameterfile <monitor_parameter_file> -monitoroutputfile <monitor_output_file> [-user|-application <username>] [-password <password>] | [-passwordfile <password_file>] [-cycle <nnnn_sec>] [-duration <nnnn_h>] [-continue_on_error] [-port <port_number> [-overwrite]

Important If you specify the -user parameter without the -password or -passwordfileparameters, then do not redirect the screen output to a file (using the > option).

Parameters


-monitorparameterfile<monitor_parameter_file>

The name of the file that contains the entity types that must bemonitored, and the scope of monitoring for each entity type.

If the file is not located in the current directory, then type the path andname of the file.

Yes

-monitoroutputfile<monitor_output_file>

The name of the file that contains the monitoring information for theentities included in the monitor parameter file.


Yes


If omitted and no -application argument is specified, then theoperator executing the command must be all_adm.

-application <username> The name of the Alliance Access operator of type Application executingthe command.

If omitted and no -user argument is specified, then the operatorexecuting the command must be all_adm.



• -user|-application <username>-password <password>: Enterthe user name and password in the command line.

The user name and password appears when monitoring processes.

• -user|-application <username> -passwordfile<passwordfile>: Specify the password file name, which containsthe password. The password included in the password file is notencrypted. Accessing the password depends on the access rightsassociated to the password file.



The name of the file that contains the password of the operator.





-cycle <nnnn_sec> The value in seconds of the cycle according to which monitoring mustcontinue. The minimum time is 2 seconds. If you do not provide a valuefor the -cycle parameter, then the monitoring runs once only.

-duration <nnnn_h> The value in hours of the duration for which cyclic monitoring must run.This value must be specified only if the -cycle parameter is alsospecified. If this parameter is not specified, then cyclic monitoring runsforever.

-continue_on_error The process continues in case an error occurs on any particular entityor entity occurrence. If this parameter is not specified, then themonitoring stops when the first error occurs on any entity or entityoccurrence.

-port <port_number> The port number of the localhost in which the Alliance Access islistening. Default port number: 48200.

This port number is called messenger1 in the /etc/services file.

-overwrite When this option is specified, and if the file specified by the -monitoroutputfile parameter exists, then the output file isoverwritten.

B.16 saa_msgrepairTool location


Command syntax

saa_msgrepair [option]

Parameters


-m Displays the status of the message repair operation.

• None: no message repair operation is running

• Ongoing: a message repair operation is running and is not complete

-r [n|c|i] After the partial recovery, the actions performed for the message repairdepends on the value of the "Message Repair Action" security parameter. Ifthe value is "Prompted", then the value of the -r parameter is taken intoaccount.

• n: None. Live message instances are left in their queue for furtherrouting.

• c: Complete. Live message instances are completed.

• i: Investigate. Live message instances are routed to the _MP_recoveryqueue.

If the value is different from "Prompted", then the action specified by the"Message Repair Action" security parameter is performed. In all cases, aPDE is added to live outstanding message instances.

-h Provides a list and description of the different options.



B.17 saa_rtfilegetrequestPurpose

Use the saa_rtfilegetrequest command to request the download of a payload file from acorrespondent over the FileAct service in real time.

A real-time SWIFTNet Reception Profile manages the file request, the subsequent reception ofthe file and its storage in the Alliance Access database.

Operator session


Tool location

<Alliance installation directory>/BSS/bin/AIX

Command syntax

saa_rtfilegetrequest -user|-application <username> -service <service_name> -request <request_type> -requestor <distinguished_name> -responder <distinguished_name> -rprof <real-time_reception_profile> -logicalname <logical_file_name> [-password <password>] [-passwordfile <password_file>] [-authoriser <distinguished_name>] [-nonrepudiation] [-signature none|crypto|list] [-priority <priority>] [-port <port_number>]

Parameters

The saa_rtfilegetrequest command has mandatory and optional parameters, as follows:


-user|-application<username>

The name of the Alliance Access operator of type Human (-user) orApplication (-application) executing the command.

Yes

-service<service_name>

The name of the real-time FileAct service over which the payload file mustbe transferred.

Yes

-request<request_type>

The name of the request type to use within the service, to transfer the file. Yes

-requestor<distinguished_name>

The DN of the institution that is requesting the file from the correspondent.

The Requestor DN must have a valid authorisation to receive from theResponder DN.

Yes

-responder<distinguished_name>

The DN of the correspondent institution, that is being requested to transferthe file.

Yes

-rprof <real-time_reception_profile>

The name of the real-time SWIFTNet Reception Profile that will manage thefile request and the reception of the file from the correspondent.

Yes




-logicalname<logical_file_name>

The logical name of the file that is requested from the correspondent. Thisname must be known to the correspondent.

Yes

-password <password> The password of the Alliance Access operator specified in the -user or -application parameter.

(1)

-passwordfile<password_file>]

The name of the file that contains the password of the Alliance Accessoperator specified in the -user or -application parameter.

(1)

-authoriser<distinguished_name>

The Authoriser DN that Alliance Access must use when downloading thefile from the correspondent.

The level-2 BIC8 of the Authoriser DN must be the same as the level-2BIC8 of the Requestor DN.

-nonrepudiation The presence of this parameter indicates that non-repudiation is requiredfor the file transfer from the correspondent.

If the business service requires non-repudiation, then the transfernegotiation for that service must be signed, and you must specify both the -nonrepudiation and -signature parameters.

-signature none|crypto|list

The type of FileAct signature that is required, if any:

• none: No signature is required. Default value.

• crypto: encrypted signature is required

• list: signature list is required

-priority <priority> The SWIFTNet Priority to apply to the File Get Request:

• urgent

• normal

If you do not specify -priority, then normal priority is applied.

-port <port_number> The port number to use to access Alliance Access.

If you do not specify -port, then the default port, 48200, is used.

(1) You can use only one of the optional parameters, -password or -passwordfile, in the command. If you do not

specify -password or -passwordfile , then the system prompts you to type the password for the user.

B.18 saa_systemTool location


Command syntax

saa_system <command> <additional values> <options>where:

• <command> must be replaced with one of the commands listed in the following table.

• <additional values> represents choices for some of the commands.



• <options> represents an optional part of the command.

Parameters


archive [jrnl|mesg] -days <NumberOfDays>

Archives the specified entity: jrnl for events, mesg for complete messages.

Use -days to specify the number of days (1 to 999) for which to retain thearchives.

archive list [jrnl|mesg]

Lists the archives present in the database for the specified entity: jrnl forevents, mesg for complete messages.

archive listtar[jrnl|mesg]<file_pathname>

Only for use with backups created with an earlier version of AllianceAccess.

Lists the archives present in a backup of the specified entity, in the tar filespecified in <file_pathname>.

archive remove [jrnl|mesg] <archive_name>

Removes the specified archive <archive_name> from the database: jrnlfor events, mesg for complete messages.

archive backup [jrnl|mesg] <archive_name><file_pathname>

Performs a backup of the specified archive and stores the created backupunder the directory <file_pathname>.

In case of hosted database, do not specify the <file_pathname>parameter as the backup is created in the eja (for events) or mfa (formessages) subdirectory of the shared directory specified by the LocationBackups parameter.

archive restore[jrnl|mesg]<file_pathname>

Restores the specified archive backup <file_pathname>.

In case of hosted database, <file_pathname> is the archive directory,which is MEAR_YYYYMMDD, or JRAR_YYYYMMDD for a single archivebackup. This directory must be located in the eja or mfa subdirectory of theshared directory specified by the Location Backups parameter.

archive restoretar[jrnl|mesg]<ArchiveName><file_pathname>

Only for use with backups created with an earlier version of AllianceAccess.

Restores the specified archive from the backup tar file specified in<file_pathname>.

dbbackup<file_pathname>

Performs a complete backup of the database, and stores it as a directoryunder the directory <file_pathname>.

In case of hosted database, do not specify the <file_pathname>parameter as the backup is created in the db subdirectory of the shareddirectory specified by the Location Backups parameter.

dbintegrity [all|static]

Verifies the integrity (absence of unauthorised updates) of the AllianceAccess database.

all verifies the complete database, including daily tables.

static only verifies non-daily tables.

integrity Verifies the integrity (absence of unauthorised updates) of the AllianceAccess software files.

This command launches the Integrity Verification Tool. The tool generatesa full integrity report that is compared to the last full integrity report whichwas produced during installation or upgrade.

instance list Lists the instances that are available on the host.

instance rename Renames the current instance.

readlog<file_pathname> [-startdate <StartDate>[-starttime<StartTime>]] [-

Reads the events that belong to the specified period from the Event Journaland places them in a text file named in file_pathname.




stopdate <StopDate>[-stoptime<StopTime>]]

start housekeeping Starts Alliance Access in housekeeping mode.

You cannot start the servers while the database is being restored.

start operational Starts Alliance Access in operational mode.

You cannot start the servers if the database is being restored.

status [database|server]

Gives the status of the Alliance Access instance servers and database:

• Running

For the servers, the command also returns the mode: operational orhousekeeping.

• Not running or stopped

stop [force] Stops the Alliance Access servers.

Use force to stop the Alliance Access servers in a forced way. Theprocesses are killed at the operating system level instead of being stopped.

traceset<file_pathname>

Starts a trace using a configuration file <file_pathname> provided bySWIFT.

tracereset Stops the trace.

B.19 swrpc_keytoolTool location

<Alliance installation directory>/BSS/bin/AIX

Command syntax

swrpc_keytool

Prompts

The following table describes the prompts you will receive. The default response is presented insquare brackets in the form [default]:

Step Prompt Response

a Do you want: 1: a self-signedcertificate 2: a certificate request[default, 1]:

If you select 1, then a self-signed certificate isgenerated, which is signed with itscorresponding private key. In this case, the CAcertificate and the certificate itself are identical.The subject and issuer of a self-signedcertificate are the same.

If you select 2 to generate a certificate request,then a PKCS-10 file (Request for Certificate) isgenerated. You must present this file to a CA(Certificate Authority) to receive a certificate. Inthis case, the subject and issuer of thecertificate are different. The subject is the DNyou entered in the certificate request and theissuer is the DN of the CA. To use serverauthentication in this case, you must receiveboth the certificate and the CA certificate.



Step Prompt Response

b File name for the new key: Enter the path and file name for the private key.If you enter only the file name by default, the fileis created in the current directory.

c Enter a password of your choice: The key is password-protected. Select apassword that complies with your institution'spassword policy.

d Re-enter the password forverification:

Re-enter the password for verification: The newkey is now generated. Skip to prompt g.

e File name for the certificate: Enter the file name for your certificate. If the filealready exists, you are prompted to overwritethe file. If the file does not exist, skip to prompt j.

f Overwrite existing file? [default,n]:

Enter Yes (y) to overwrite an existing file, enterNo (n) to return to prompt h. You are nowprompted to enter the DN. For information aboutDN, see prompt l.

g File name for the certificaterequest:

Enter the file name for your certificate request. Ifthe file already exists you are prompted tooverwrite it. If not, skip to prompt l.

h Overwrite existing file? [default,n]:

Enter Yes (y) to overwrite an existing file, enterNo (n) to return to prompt j.

i Enter the distinguished name (DN) tobe included in the certificate:Example:cn=SAA1,ou=department1,o=institution1.This DN will be needed if you want toconfigure authentication.

This DN can contain the following attributes:

• C for country

• ST for state or province

• L for location name

• O for organisation name

• OU for organisational unit

• CN for common name

• EMAIL for the e-mail address.

Enter the DN. A check is then performed on theDN.

For a certificate request, you are prompted forfurther input and for the key file and certificaterequest file.

j Number of days your certificate willbe valid [default, 30]:

Enter the number of days the certificate can beused. Default value: 30. Maximum: 3565.



Legal Notices

Copyright

SWIFT © 2010. All rights reserved.

You may copy this publication within your organisation. Any such copy must include these legal notices.

Confidentiality

This publication may contain SWIFT or third-party confidential information. Do not disclose this publicationoutside your organisation without the prior written consent of SWIFT.

Disclaimer

SWIFT supplies this publication for information purposes only. The information in this publication maychange from time to time. You must always refer to the latest available version on www.swift.com.

Translations

The English version of SWIFT documentation is the only official version.

Trademarks

SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT: SWIFT,the SWIFT logo, 3SKey, Innotribe, Sibos, SWIFTNet, SWIFTReady, and Accord. Other product, service, orcompany names in this publication are trade names, trademarks, or registered trademarks of their respectiveowners.

Documents

7 0 Saa Aix Inst Guide