AMOS 12.00 Administration Guide

Aircraft Maintenance & Engineering System
AMOS Administration Guide
Version: 12.00
Date: 01.11.2017
© Swiss Aviation Software Ltd.

1. AMOS Administration Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Release Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Release Change and Patch Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Release Change Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Release change from pre-10.70 to post-10.70 versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3 Environment Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 AMOS Administrator Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4.1 Advanced Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4.2 Application Server Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5 Database Administrator Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.5.1 Backup, Recovery and Log Shipping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.5.1.1 Backup and Recovery Scripts for Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.5.1.2 Backup and Recovery Scripts for Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.5.2 Database Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1.6 System Administrator Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1.6.1 Client Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1.6.1.1 server.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1.6.1.2 launch.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
1.6.1.3 cleanup.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
1.6.1.4 directDraw.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
1.6.1.5 edoc.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
1.6.1.6 registered.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
1.6.1.7 sim_colors.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
1.6.1.8 simulator.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
1.6.2 AMOS Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
1.6.2.1 Java Memory Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
1.6.3 System Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
1.7 Document Information Administration Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3/52
AMOS Administration Guide

What's new in the AMOS 12.00 Administration Guide
Changes Chapter
Overview of AMOS Administration

The various tasks related to the administration of AMOS can be divided between three roles:
the AMOS administrator, the database administrator and the system administrator.
Dependent on the situation, these roles might have to work together closely. Therefore it is important to know which
tasks are required and how AMOS can support the administrators to perform these tasks. The administration of
AMOS requires a deep understanding of the AMOS architecture, the release strategy and the business processes.
Typical tasks of the administrator are:
monitoring database backup procedures and validating backup integrity
prepare and perform the installation of patches and new releases of both the database server and the
application server
monitoring of resource consumption of the database and application server
configuration and monitoring of interfaces
perform database maintenance like data clean-up, statistics update and space allocation
configure AMOS scheduled tasks
install AMOS maintenance keys
configure client SSL and handle certificates
AMOS client provisioning
The Administration Guide provides an overview of the advanced configuration options available in AMOS that are
recommended to take into account.
Release Files
AMOS Release Terminology

The development of AMOS is strongly driven by our customer's ideas and knowledge. Therefore Swiss AS uses a
release strategy that allows our customers to give feedback on new features and program changes quickly.
Furthermore Swiss AS is constantly focused on the improvement of our product, especially the elimination of errors.
The Swiss AS release strategy implies that we provide two kinds of releases: Stable Releases and Preview
Releases (aka Weekly Builds).
Stable releases
Swiss-AS provides 3 times a year a new version of AMOS so called “Stable Release”. The roadmap and “End of Life
Cycles” of the stable releases is published on the web in the customer area http://www.swiss-as.com/amos/roadmap
/#releasePlan .
Stable releases are recommended to be installed in productive environments since they are tested and reliable.
SWISS-AS.COM
4/52
Potential bugs can easily be fixed by means of patches (single version or cumulative patches) within short time
notice. Functionality and the database schema are not changed by patches; only program errors and security issues
on server or client side are corrected. Patches for one particular stable release version are provided frequently
(weekly) for more than one year. Swiss-AS publishes “Security Alert / Patch Withdraw” and inform the customers to
install the patch. This guarantees a stable AMOS environment with a very high availability for a predictable period of
time.
The release change to a stable release is not reversible!
Recommendations:
Please make sure that you migrated to the next higher supported version until your current version is running
out of support.
The release change to a stable release needs to be tested in detail. All business critical processes and
interfaces needs to be tested via UAT.
Preview Releases
Previews are intended to be used in test environments exclusively as they reflect the latest status of development
and might therefore show incomplete functionality. They can be installed to allow customers to stay up to date with
program changes and to be able to give feedback about new developments.
Every installation of a Preview Release requires a change of the database schema which makes them more or less
time-consuming to install (dependent on the size of your database and the power of the server hardware). Naturally,
Preview Releases always tend to have more errors and cannot be patched like Stable Releases. The release
change to a preview release can only be initiated from a preceding stable release.
For Preview Releases no patches will be published. Bugs might be fixed in the next preview release.
Preview releases must not be used in production!
Patch / Cumulative Patch

A patch of a stable release contains only bug and security fixes. Swiss-AS publishes patches on a weekly basis and
in case of critical findings. For every supported stable release there exist single version patches that can be installed
on an top of the previous patch level and cumulative patches that can be installed on every lower patch level.
Uninstalling a patch/cumulative is possible.
Recommendations:
To put the AMOS installation not into risk, it is recommended by Swiss-AS to install the available patches on
weekly bases.
If the customer's company policy doesn't allow the installation of the patches on a weekly basis, it is required
that the release notes are checked regarding critical applicable fixes as soon as the patch is available. If
required the patches need to be installed via the emergency patch procedure.
“Security Alert / Patch Withdraw” patches needs to be installed directly via the emergency patch procedure.
Release Numbering
Both types of releases differ in numbering as explained in the following examples:
Stable Release version 10.30-08 (aka version 1030007)
SWISS-AS.COM
5/52
major version minor version revision patch level
10. 30 - 07
Preview Release version 10.31(f) (aka version 1031500)
10. 31 (f) n/a, always 00
Upgrade Notes
Please take the following notes into account when upgrading or patching an existing AMOS server:
when upgrading from a Stable Release to a higher Stable Release, up to 2 version can be missed out
when patching a Stable Release only use patch files and not a Stable Release file.
upgrading from a Preview Release is not recommended as data inconsistencies introduced by incomplete
functionality might cause errors during the release change process.
from AMOS v10.30 on patches can be uninstalled
Release File Download

The distribution of all releases and patches is done via swiss-as.com . For access to the download section, you
need to register with AMOS support. You will then be notified by e-mail whenever new releases or patches are
available. Stable Releases, Preview Releases and patch files need to be downloaded to the administrator's PC from
where they can subsequently be installed on the AMOS server. They are available as compressed archives in tgz fo
rmat (release file) or .udb format (patch file) respectively.
Notes for users of Internet Explorer
IE sometimes changes the file's extension of the release file or patch autonomously to .zip during the download. As
AMOS only recognizes .tgz and .udb extensions, you will have to replace the extension with .tgz (release file) or
.udb (patch) manually to correct this behavior.
Release Change and Patch Recommendations
Stable releases
Stable releases are recommended to be installed in productive environments since they have been decently
tested by Swiss-AS.
Please make sure that you migrate to the next higher supported version before your current version is
running out of support. The stable releases' lifecycle is available at the Release Info on swiss-as.com.
The release change to a stable release needs to be tested in thoroughly. All business critical processes and
interfaces need to be tested by the customer during a user acceptance test (UAT).
Preview Releases
Preview releases must not be used in production environments. They allow customers to try out the newest features
future AMOS releases and provide feedback to Swiss-AS.
Patch / Cumulative Patch
There exist several good practice advices of the industry or national recommendations on how to manage patches.
Common to all of these recommendations is:
1. The differentiation between patches that bring new features vs. only fix bugs.
2. The vendors recommendation regarding patch management for his specific software
3. The patch criticality assessment by the user for his specific context, based on the information provided by the
vendor for a specific patch.
SWISS-AS.COM
6/52
Swiss-AS recommends to follow the below guidelines.

An AMOS patch never includes a new feature or function. In rare cases a function might work differently as a
consequence of mitigation strategies to address a critical issue.
To not expose the AMOS environment to risks, Swiss-AS recommends to install the latest available patches
on weekly basis.
As a basic test procedure for patches, patches can be installed on an acceptance environment first and in
production right afterwards.
As patches never alter the behavior of existing features and functions, Swiss-AS is regarding a UAT as not
required prior to installing a patch. Based on the release notes explaining what has been fixed a customer
might decide to do a light testing of the specific processes that might be affected by the fix.
If the customer's company policy doesn't allow the installation of patches on a weekly basis, it is required that
the release notes are reviewed regarding critical applicable fixes as soon as the patch has been published. If
required, the patches need to be installed using the customer's emergency patch procedure.
Every patch fixes at least one problem/bug. Hence not applying a patch can increase the risk of being
operationally affected by the bug(s) fixed in that patch.
In case patches are published by Swiss-AS as a result of a Security Alert or a Patch Withdraw, these patches
needs to be installed immediately using the customer's emergency patch procedure.
For the rare case that a patch doesn’t solve a reported issue in an acceptable way or introduces a new
problem, an un-patch function exists, which bring the system back to the previous configuration within
seconds.
Release Change Process
Overview
Any release change of a production environment needs to be tested thoroughly in a test environment using the
same data and the same AMOS version as in production. Please make sure that key users and administrators are
aware of the following preconditions in order to allow an efficient upgrade test:
in order to get comparable results for the required downtime, the test environment should have a similar
setup as the production servers in terms of hardware resources
both keys users and system/database administrators will be heavily involved in the various tasks required to
perform one test cycle
system/database administrators need to be familiar with the procedures and scripts used to refresh the test
environment with up-to-date production data and the current application server version
experience shows that performing multiple cycles of the upgrade tests (including system preparation and data
correction) until no errors remain takes between several weeks and 6 months
Swiss-AS assists customers regarding the preparation of the test environment, the execution of the release
upgrade and during data correction in case of complex conditions
Every upgrade test cycle consists of the following steps that have to be repeated until both the release change log
and the forecast comparison show no errors. To monitor the progress of the data correction and collect useful
details that might be relevant for the production upgrade, every cycle needs to be documented using the history of
update log files and an Upgrade Instruction Manual.
SWISS-AS.COM
7/52
Process Description
Required steps to perform one release change test cycle to AMOS 10.x are described in the table below (major
steps highlighted in yellow). Note that the post work phase is only applicable after a successful release change in a
production or acceptance environment.
Phase When What Where
Preparation 24h before Update database statistics AMOS APN 2606

Use AMOS Scheduler Tasks
DatabaseMaintenance
Set appropriate number of AMOS APN 1442

threads (AMOS parameter
1520)
Rule of thumb is: no. of
threads in AMOS = 2/3 of the
number of available
database cores
Check database space DB

Free space should be at
least the size of the largest
table multiplied by the
number of threads during the
update
SWISS-AS.COM
8/52
Check file system space of OS

the application server
partition
Free space should be
sufficient to store the release
file and the backup of the
application server directory,
preferably 10 GB
Adjust database DB
parameters according
recommendation.
See latest Hardware
Requirements, Sybase
Standards and AMOS
Installation Guide
Install latest patch AMOS APN 10

available for the current
version
Upgrade Immediately before Disable automatic OS/DB

database backups
Perform manual database DB

backup
Block users AMOS APN 10

Set the limit of user
connections to zero to only
allow administrators to log in
into AMOS
Zero Schedule the AMOS AMOS APN 2313

release change to the
latest patch available for
the new version
Follow progress of OS
upgrade using the release
change URL (described
below) or in the update log
Upgrade Immediately afterwards Analyse release change AMOS APN 2083

Use program Analyse and APN 2168
Verification Release Change in AMOS
10.x to identify classified
(error codes available) and
unclassified errors (no error
codes available, memory
errors or database errors).
SWISS-AS.COM
9/52
Perform Data Correction

Execute actions related to
error codes described in
program Error Codes Viewer.
This is usually done in the
source database (meaning
production) so that the
correction is included in the
next test cycle. Open support
cases for unclassified errors
that are not related to
database or memory issues.
Maintain Update
Instruction Manual
The error and warning codes
require special actions to be
executed before, during or
even after the upgrade.
Therefore it is highly
recommended to maintain an
Update Instruction Manual
that describes how to correct
the data and which activities
have to be executed in which
order. These instructions will
be completed in subsequent
test cycles and will be used
during the production
upgrade.
Forecast With no release change DataSyncDaemon and AMOS APN 2606

errors left forecast tasks
Comparison In AMOS 11.x the
DataSyncDaemon is used for
the forecast calculation.
Please verify if the daemon
has been running without
erros or run the
corresponding AMOS
Scheduler forecast tasks
once in the order specified in
document "Executing
Forecast Comparison Using
APN 2301".
Make sure to run the
Scheduler Task
PartRequestDataCorrectio
nService once before the
PartForecastService.
SWISS-AS.COM
10/52
With no release change Perform Forecast AMOS APN 2301

errors and no error in the Comparison
forecast jobs Follow instructions in
document "Executing
Forecast Comparison Using
APN 2301". Note that the
forecast comparison is only
required upon successful
completion of an upgrade
test cycle. During production
upgrade no comparison
needs to be performed.
Post-Work Upon successful release Perform a manual database DB

change and forecast backup
comparison
Re-enable automatic OS
database backups
Install the latest version of
backup and recovery scripts.
Note that AMOS 9.80 scripts
can no longer be used for
AMOS 10.x.
Renew the AMOS AMOS APN 1500

maintenance key in order
to install licenses of
optional modules. This is
required by the new
license model introduced
with 10.50.
Verify interfaces AMOS APN 902
Setup new required AMOS APN 2606

Scheduler tasks and and APN 2167
Derived Jobs
Make sure that mandatory
system tasks and sequences
like the forecast sequence,
DatabaseDefragmentation
are scheduled in APN2606.
Activate available clean-up
jobs to reduce data growth.
Allow common users to AMOS APN 10

connect to the system
For acceptance testing, key
users might validate the data
and core processes first.
SWISS-AS.COM
11/52
Incremental Release Change

The incremental release change introduced in 10.60 sequentially installs every stable release between two versions.
E.g. when upgrading from 10.70 to 10.90, releases 10.80 and 10.90 are installed automatically during the release
change process. Program Release Change (APN 2313) supports the administrator to download release files,
perform pre-checks, verify admin preparatory tasks and schedule the release change. The progress of the release
change can then be followed in the browser using the AMOS server's URL.
Various log files exist on the server that provide additional information about the release change: full_sync_error log,
full_sync_monitoring log, full sync log (per release), incremental-release-change log.
Release change from pre-10.70 to post-10.70 versions
Purpose
This document descibes how to perform a release change from a pre-10.70 AMOS (minimum AMOS 9.80) to any
post-10.70 version. With this procedure it is possible to upgrade to AMOS 10.80 and higher versions without
stopover at jumping release AMOS 10.70.
Preconditions
Precondition Syntax Example Screenshot
It is required to create a target_version=<your_targ target_version=1080012

config file called release_c et_version>
hange.cfg in the cfg folder
of the pre-10.70 AMOS
server.This config file
needs to contain a line as
specified in the Syntax or
Example column on the
right.
SWISS-AS.COM
12/52
In the parent folder of the n/a n/a

pre-10.70 AMOS server a
folder called release-folder
must exist. This folder has
to contain all release files
of AMOS stable releases
between the source and
the target version. The
AMOS server will be
upgraded
automatically to every
release one after the other.
You can verify the setup of n/a n/a

the release_change.cfg an
d the release-folder
using the Release change
pre-check button in
program Configure Server
(APN:10) in
the Maintenance tab.
Process
The release change process works as follows:
Description
1. The AMOS administrator has to download the latest AMOS 10.70 release file from the swiss-as.com website.
2. The AMOS administrator starts the release change by opening the pre-10.70 AMOS client, open program
Configure Server (APN:10), then switch to the Maintenance tab. Either click new release to install the release
immediately or schedule the release change. Please choose the AMOS 10.70 release file downloaded in step 1 in
the file dialog.
3. The pre-release checks will then be executed automatically on the server. AMOS recognizes that 10.70 will not
be the final version but the version specified in the release_change.cfg file instead. The pre-release check verifies
that all required versions are downloaded in the release-folder.
4. The release change to AMOS 10.70 starts automatically. The output is written to a log file in the parent directory
of the pre-10.70 AMOS server. The log file name is update<newVersion>AMOS_stable_<oldVersion>.log. At the
beginning of the log file there is again some output mentioning the target version and listing the available release
files.
5. After the release change to AMOS 10.70 finished, the release change to the subsequent versions is started
automatically. The log file of this operation can be found in a subdirectory of the release-folder called incrementalR
eleaseChange. The progress can also be followed in the browser using the AMOS server's URL
6. After the release change has been finished successfully, the final version of the AMOS server wil be started
automatically.
SWISS-AS.COM
13/52
Environment Usage
In order to avoid inadvertent use of an AMOS environment, the intended usage of each environment - prior and after
the go-live - needs to be known to every AMOS user and the infrastructure team. During the implementation project
of AMOS, every member of the project team needs know which AMOS instances are available and what they are
used for. The commonly used environments and the data flow between them is documented here.
Environment Overview
AMOS production
Version: only Stable Releases Always on the same version as the migration environment.
Usage: production environment
Access: all users
AMOS migration
Version: only Stable Releases. Always on the same version as the production environment.
Usage: this environment is used to load data from the migration files. It is configured for improved performance.
Access: only users involved in the data migration process.
AMOS acceptance
Version: usually the latest available Stable Release
Usage: this environment is used to regularly validate changes in AMOS coming with a patch or a new release before
this update is applied to production. Prior to the update of production environment, a copy of the production
database is loaded into the acceptance environment so that keys users can verify bug fixes and new features.
Access: key users
AMOS playground
Version: usually the same version as the production environment
Usage: this environment is used to allow users to try out AMOS features using live data. The data is overwritten
regularly with a fresh copy of production data
Access: all users
AMOS test
Version: Preview Releases or Stable Releases
Usage: this environment is used to test the update/patch procedure or a disaster recovery scenario.
Access: administrators only
Data Flow
The following pictures illustrate the data flow during the implementation project (data migration) and in production.
All movement of data, except the manual migration of data from the transfer files, is performed by scripts that can
either be executed by the system administrator or scheduled to run automatically.
SWISS-AS.COM
14/52
Production Data Flow Pre-Go-Live Data Flow
Migration Details
The following topics have to be taken into account when recovering an AMOS database from backup during the
replication of the production environment.
Copy of AMOS Keystore Masterkey File

The AMOS keystore and AMOS maintenance key need special handling when restoring a database from a backup.
The keystore needs to be accessible in order to apply the maintenance key. Therefore the master key file might
have to be copied from the source (production) to the target environment (e.g. test) and renamed to fit the target
database name.
AMOS Maintenance Key Backup

In order to reuse a valid maintenance key of a test environment that will be overwritten with a copy of the production
database, make sure to create a backup of the maintenance key of the test environment whenever it is installed or
renewed. The corresponding backup file is stored in the AMOS server's cfg directory and will loaded into the
database automatically during each restart of the application server. This will then overwrite the production
maintenance key that came with the database backup.
Restore Database User Permissions

Permissions on AMOS tables are still granted to the privileged and unprivileged database users of the production
environment even after loading the backup into a different database. To adjust permissions of database users of an
AMOS environment after loading the backup, the administrator need to run the corresponding command in the
Database synchrinization menu of the amos_config_server command line tool: A - Recreate unprivileged user
permissions
AMOS Administrator Role
Advanced Configuration
Data Cleanup
Program Data Clean-up (APN 2167) gives administrators the possibility to limit the continual growth of your
SWISS-AS.COM
15/52
database. This tool provides jobs to the remove data of particular modules from the database in a consistent way.
Use the following procedure to configure necessary clean-up jobs.
1. Identify fast-growing tables by using the "Table-Size" button in the Database Monitoring tabsheet in program
AMOS Control Center (APN 2167).
2. Find the appropriate clean-up job in the list of tables affected by each job in the selection dialog in program
Data Clean-up.
3. Set up the clean-up job to run regularly (daily) based on a specific criterion (usually "number of days").
Note: when initially cleaning up huge tables you have to make sure that the database transaction log doesn't fill up
because too many rows are affected by the given criterion. In this case, initially use a higher retention time and
move it down slowly to the target time within the next couple of days. Use program Database Explorer (APN 11) to
determine the amount of rows affected by a specific criterion. In general, the amount of data affected by the data
clean-up has an impact on the database's transaction log space and the size of incremental backups.
Log Files
SWISS-AS.COM
16/52
In AMOS APN 10 Configure Server, the AMOS server allows to define backends where the output of the application
server can be stored. In most cases, these backends use log files in the application server's logs directory. To limit
the amount of data that is written to these logs, the administrator can define filters for each backend. Note that if a
particular filter rule is applied, following rules will be ignored.
Scheduled Tasks
The schedule of background tasks in AMOS needs to be defined by the administrator. Due to increased resource
usage, some tasks should not run simultaneously e.g. all tasks related to the forecast calculation. Always follow the
instructions given in the description of each task regarding parameters, the order in which tasks need to be executed
and the recommended period. Please refer to the www.swiss-as.com or the AMOS installation guide regarding the
mandatory scheduler tasks. Mandatory tasks are also called 'system' tasks.
Text Index Location

The location where the AMOS server will store full text search index data can be configured using AMOS parameter
1578 in program Parameter Setup (APN 1442) . The text index data will be used by the internal text search engine
to perform all kind of text searches. The data can be monitored and rebuilt using program Text Index Manager (APN
601). The default location of the text index data is subdirectory text_index of the AMOS webdrive folder. If one of the
following conditions is met, the location of the index directory has to be adjusted using the values of parameter
1578. Note that a reboot of the application server is required after changing the index directory location.
Condition Description
Webdrive location on remote host While the webdrive can be located on a remote file
server using a UNC path,
the index directory should always be stored locally for
performance reasons.
Shared webdrive directory amongst multiple AMOS In test environments, multiple AMOS instances often
instances share a common webdrive
in order to safe disk space. As each AMOS instance
locks access to the index
files upon start, other instances will not be able to use
the index for text
searches if the default location is unchanged. To avoid
this each AMOS
instance needs to have its own index directory.
Separation of index data from visible data Using the default index location, the index directory will
be visible on the
webdrive although this data is of no use for users.
Single Sign-On
With AMOS it is now possible to authenticate against a running Kerberos service to login at the AMOS server
instead of typing in the username and password in the login dialog. This feature has to be enabled on server side
SWISS-AS.COM
17/52
before it is available on the client side at all. To enable SSO via Kerberos, the integer value of parameter 1000 has
to be set to 1 (this parameter is also used for IMAP and LDAP configuration). Doing this allows a client on the next
login to select a checkbox to login e.g. via Windows credentials as shown in the image below:
The AMOS client will look for cached session credentials of the operating system and tries to login with these.
Please ensure that all necessary configuration to use SSO was already done before activating this feature,
otherwise the SSO login will not be available independent on the parameter 1000 setting. To see what else have to
be done, have a look into the online help or ask for further support.
Database Connection Pools

AMOS uses two connection pools for all database connections:
a privileged connection pool for administrative database tasks
an unprivileged connection pool for common user tasks
The following rules apply for the database connection pools:
each pool uses a database login with appropriate permissions on the database level
the amount of possible connections is limited (pool size). The pool size can be increased dynamically, a
decrease requires a restart of the AMOS server.
the connections in a pool will be opened upon request and remain open until a restart of the AMOS server
unused connections will not be closed, they will be displayed as "Open connections"
connections currently used by a process (executing an SQL command) will be displayed as "Reserved
connections"
a process waits for a given time after requesting a connection from the pool (timeout). If the connection is not
provided after the timeout, a notification is displayed in AMOS Control Center (APN 2137).
Program AMOS Control Center (APN 2137) displays the current pool usage in tabsheet "AMOS monitoring",
"Connection pools".
SWISS-AS.COM
18/52
Program Configure Server (APN 10) allows administrators to define the size of each pool and a timeout a process
waits when requesting a connection from the pool before throwing an error. The pool configuration will be stored in a
server configuration file called database_pool_configuration.cfg.
Automatic Maintenance Key Update

The automatic update of the AMOS mainteanance key can be activated by setting integer value of parameter 1472
Maintenance Key Webservice to 1 in program Parameter Setup APN 1442. If activated, the Maintenance Key Check
Job (see APN:1755 Deferred Jobs) will try to request a new maintenance key via a webservice. The automatic
update requires a valid maintenance key and a proper keystore setup for maintenance key requests. It will use the
webserver authentication that is stored for APN:1635 Support Tool.
AMOS Executor Framework Configuration

The executor framework is responsible for parallelizing work in AMOS for example during execution of the forecast
jobs. There is now a centralized dispatching of all tasks which allows better control over system resources such as
CPU or memory making the AMOS server more stable. In program Parameter Setup APN 1442 parameter 1520
controls how many parallel threads are allowed and the value of this parameter now needs to be adjusted according
the system's amount of CPUs (cores) for best performance. Please refer to the parameter description for more
information.
Application Server Monitoring
Similar to the system administrator, the AMOS administrator can monitor user triggered events, automated tasks
and internal server processes using AMOS programs. This helps to better understand the server's load and to be
able to identify potential error sources.
SWISS-AS.COM
19/52
Monitoring Limits
In program Configure Server (APN 10) on tabsheet Statistics, limits can be configured to monitor critical events.
Once a particular limit is reached, the event will be tracked in the application server's monitoring log file and will be
visible in the System Performance tabsheet in the AMOS Control Center (APN 2167).
Warning: in order to limit the amount of monitoring data stored in the database please take the following
recommendations into account:
set up clean-up job MonitoringEventsLogCleanupJob in program Data Clean-up
initially, use high monitoring limits to only catch the most critical events and adjust the limits after having
eliminated them.
Workflow Configuration
In program Workflow Configuration (APN 612) the administrator can set up workflows to monitor events caused by:
User actions
Scheduler tasks
AIM interfaces
System events
Some of these events require the administrator's intervention so the workflow can be configured to send a
notification message.
Maintenance Key and Certifcate Checks
Swiss-AS strongly recommends that, starting from the patches mentioned above, every customer have the
"Maintenance Key Check" Deferred Job enabled and scheduled in their productive environments.
How to check if the Deferred Job is enabled and scheduled?

On APN 1755 – "Deferred Jobs", select the "Maintenance Key Check" job type and click "search".
SWISS-AS.COM
20/52
Make sure that the "Enabled" check box is marked and verify the "Scheduling" tab:
The default schedule is to run this job daily at 1am but it can be changed according to your needs, please make sure
that the job is scheduled to run at a time when the AMOS server is certainly online. Swiss-AS recommends that this
job runs at least once a week.
What happens when the Maintenance key or one of the certificates is about to expire?
For each execution of this Deferred Job, the "Log" tab will contain execution details and a list of soon-to-be-expired
key and certificates:
Maintenance Key
License key certificate
Root certificate
SSL server certificate
SWISS-AS.COM
21/52
In case the Maintenance Key or one of the certificates is about to expire, the same information will be send sent via
email with subject "Maintenance Key Warning!" to all users of the ADMIN group or to the email address given to the
ADMIN group. For AOS customers, the AOS team will receive the same email. Example email text:
The installed maintenance key has expired, please request a new one for not having any restrictions in
your AMOS environment!
Currently installed maintenance key:
Serial Number: 77421392805575325
Valid Until: 19.February.2015
Keystore Area Warning!

amos.client.certificate.licensekey.cert
ERROR Invalid certificate path: Could not validate certificate: certificate expired on
20130728230000GMT+00:00
This area is required to handle the Maintenance Key! You should create a new certificate and then
request a new Maintenance Key.
Server Name: amos-prod
Server IP: 192.168.1.94
Server Port: 5081
Database: cprod
More information about the License Key Certificate

The usage of Root and SSL server certificates is optional but every customer needs to have a valid Maintenance
Key and License Key Certificate in order to avoid an "unmaintained" status of AMOS. AMOS needs the License Key
Certificate in order to encrypt and decrypt the Maintenance Key. This License Key Certificate is automatically
renewed whenever it expires, but when this happens the current Maintenance Key can no longer be decrypted by
the new License Key Certificate and become invisible to AMOS. At this stage a new Maintenance Key needs to be
installed to avoid an "unmaintained" status of AMOS, which blocks access to all APNs other than the AMOS
Administrator tools. The whole renewal process usually takes less than 10 minutes which is not an issue on "Test"
or "Training" environments. For Productive environments we strongly recommend that you plan in advance when to
execute this operation in order to avoid any unscheduled downtime.
How to create a new License Key Certificate?

Please schedule this activity in advance and remember that all APNs other than the AMOS Administrator Tools will
be unavailable to all AMOS users until the processes of creating the new License Key Certificate and installing a
new Maintenance Key are both completed. On APN 1452 – "AMOS Keystore", select the current License Key
Certificate and click on "New Certificate":
SWISS-AS.COM
22/52
Fill out the certificate data. Choose a "Valid until date" (this is the date when the next License Key Certificate will
have to be created). Leave the "Certificate Chain" option unticked.
Press button OK.

AMOS will then create and install a new License Key Certificate which will no longer be able to decrypt your current
Maintenance Key. In order to allow your users to keep using AMOS productively, you now have to request and
install a new Maintenance Key.
How to request a new Maintenance Key?

On APN 1500 – "Maintenance Key Admin", click on "Generate Request":
SWISS-AS.COM
23/52
Fill in all information about your environment (remember to select the "Productive" option if you are doing this for
your Productive environment) and click on "Send Web Request". A new Maintenance Key will be requested and the
"Import Maintenance Key" screen will be shown:
Click on "Import Key" and the process will be completed.
AMOS Control Center
The program AMOS Control Center (APN 2167) provides tools to verify the correct operation of your AMOS server.
It is the central monitoring application within AMOS that gives a quick overview of the AMOS environment and also
detailed information about database and application server processes. Currently, the following components are
monitored by the AMOS Control Center:
database space, table growth, table statistics and database parameters
file system space
AMOS scheduler tasks
AMOS server Java usage
A dashboard displays all critical events based on the given monitoring settings, notifies users based on the
notification settings and provides links to recommended actions. Note that these features require several Deferred
Jobs to be running in order to collect the required data and actively handle critical events.
SWISS-AS.COM
24/52
Database Administrator Role
Backup, Recovery and Log Shipping

Backup and Recovery Scripts for Linux
SWISS-AS.COM
25/52
Introduction
Swiss-AS provides powershell and linux bash scripts for the backup and recovery of Sybase databases used by
AMOS. The script's configuration need to be adapted to the customer's AMOS environment so that they can be
used either manually or scheduled via the task scheduler and cron. All scripts make use of a configuration file that
stores all required parameters and a so called toolboxes which are files that define particular functions. Usually, only
the configuration files need to be changed by the customer in order to get the script running.
This document describes the script's usage and the configuration.
General Notes
Predefined Configuration files : each script requires a specific set of parameters stored in a configuration file.
A template of each of the three configuration files (backup.cfg.ps1/backup.cfg, recovery.cfg.ps1/recovery.cfg
and logship.cfg.ps1/logship.cfg) is provided together with the backup, recovery and logshipping scripts and
the toolbox files.
General Toolbox : the toolbox file toolbox.ps1/toolbox.sh defines generic functions used in the backup and
recovery scripts. By default the toolbox file is located in the same directory as the corresponding script.
Sybase Toolbox : the toolbox file sybase_toolbox.ps1/sybase.toolbox.sh defines Sybase specific functions
used in the backup and recovery scripts. By default the toolbox file is located in the same directory as the
corresponding script.
Powershell execution policy : to be able to run powershell scripts on a host, the execution policy needs to be
adjusted (see Set-ExecutionPolicy command). It is possible the change the policy to the whole server or only
for one script execution (see ByPass execution policy)
Introduction
General Notes
Backup scripts
Function
Usage
Configuration Parameters
System Requirements
Recovery scripts
Function
Usage
System Requirements
Logshipping script
Function
Usage
System Requirements
SWISS-AS.COM
26/52
Backup scripts
The scripts to create database backups are called syb_backup.sh and syb_dump_trans.sh :
syb_backup.sh : creates a set of backup files of one or more user databases and all system databases of a
given Sybase instance.
syb_dump_trans.sh : creates an incremental backup file of one or more user database and truncates the
transaction log of all system databases of a given Sybase instance. The backup file is added to the current
backup set
A configuration file (by default etc/backup.cfg) and the toolbox files toolbox.sh and sybase_toolbox.sh are
required by those scripts.
Function
Full backup script provides the following features:
each database's backup can be compressed and striped to multiple files

outdated backup sets can be automatically removed from the backup directory
each backup set consists of the current full backup files and the incremental backup files that have been
created since the last full backup
creates a backup of all system databases
the script prevents multiple simultaneous executions of a full backup. It queues up a full backup in case an
incremental backup is still running.
performs check of the configuration parameters before creating backup sets
creates and archives a log file for each run
creates entries in AMOS table in order to monitor the backup via AMOS control center (from 10.30 on)
archives backup scripts old log files
Incremental backup script provides the following features:
the backup file is added to the current backup set and is identified by a sequence number and a process ID
by default all databases that are part of the full backup (see syb_backup.ps1) are included, but particular
databases can be omitted
truncates the transaction log of all system databases instead of an incremental backup
the script prevents multiple simultaneous executions
Usage
The scripts syntax is:

syb_backup.sh [-c | -h | -f <config file> | -i ]
syb_dump_trans.sh [-c | -h | -f <config file> ]
Without the option –f the script uses the configuration file etc/backup.cfg.
Options:
-c : let the script check the configuration only. No backup set is created.
-h : shows the usage
-f file : the script uses file as configuration file. Without this option the file etc/backup.cfg is used by default.
-i : overwrites the standby database, logshipping needs to be configured to use this parameter.
SWISS-AS.COM
27/52
The required toolbox files need to be located in the same directory as the script itself.
The script requires the following configuration parameters that need to be defined in the script's configuration file. By
default the configuration file is etc/backup.cfg or it can be provided using option –ConfigFile for Windows powershell
and option -f for Linux bash respectively.
Parameter Description
SYBASE_DIR The path of the Sybase server folder
SYBASE_ENV The script to set the Sybase environment variable
DSPASS The sa login's password file (a restricted access to this

file is strongly recommended)
DSQUERY The Sybase instance's name
BACKUP_SERVER The Sybase backup server instance's name
DATABASES Names of the user databases to be backed up

(Windows powershell: comma separated, Linux bash:
space separated)
NO_TRAN_DATABASES Names ot the user databases you do not want to

backup (Windows powershell: comma separated, Linux
bash: space separated)
SYS_DATABASES Names of the system databases to be backed up

space separated)
BACKUP_BASE The main backup directory
CURRENT_SET Path to the latest backup set
TRAN_BACKUP_PATH Path to the transaction log backup directory
RETENTION_DAYS Amount of days (n * 24h) backup sets shall be stored

prior to deletion.
If set to 0, only the last backup set is kept (see
PREVIOUS_SET)
MAX_BACKUPSETS Max number of backupsets to be kept (including

current)
NUMBER_OF_STRIPES The dump can be split into "stripes" to accelerate the

backup process. DEFAULT: 2
COMPRESSED Dumps can be compressed to save disk space

Windows powershell: [ $true / $false ], DEFAULT: $true
Linux bash: [ Y / N ], DEFAULT: Y
SWISS-AS.COM
28/52
COMPR_LEVEL If compression is active ( Windows powershell: $true,

Linux bash: Y ), a compression level (0 - 9) must be
provided. DEFAULT: 3
LOG_DIRECTORY This is the directory for logging
LOGFILE_NAME_FULL Name of the full backup log file
LOGFILE_NAME_TRAN Name of the incremental backup log file
USE_SESSION_LOG_TRAN Use session log.

Windows powershell:[ $true / $false ], DEFAULT: $false
Linux bash:[ Y / N ], DEFAULT: N
If enabled, generate one log file per execution. If
disabled, use one single file and append results to it.
LOG_RETENTION_DAYS Amount of days (n * 24h) log files shall be stored prior to

deletion.
If set to 0, all log files will be kept
LOCKFILE Name of the lock file (to avoid simultaneous executions)
RECOVER_LOCKFILE Name of the recovery lockfile (to check if a load of the

database is processing).
Must be the same as defined in recover.cfg.ps1 for
WIndows powershell and recover.cfg for Linux bash
SHIP_ACTIVE Log shipping active.

SHIP_FULLSCRIPT Name of full log shipping script.

Windows powershell DEFAULT: logship_full.ps1
Linux bash DEFAULT: logship_full.sh
SHIP_INCSCRIPT Name of incremental log shipping script.

Windows powershell DEFAULT: logship_inc.ps1
Linux bash DEFAULT: logship_inc.sh
INFORMATION_FOLDER Folder where the AMOS information files are located.

See "server1.info.cfg" config file for further information
SWISS-AS.COM
29/52
DUMP_WITH_SA Defines if the target database has to be onlined with

standby access. This parameter needs to
be enabled if you use the report connection in AMOS
DUMP_WITH_SA_REC The transaction log dumped with standby access does

not contain the non-commited transactions, therefore it
is
possible to reduce the number of such dumps.
Default: 4
System Requirements
The Linux user that runs the backup script needs to have the correct permissions on the required files and
directories.
SWISS-AS.COM
30/52
Recovery scripts
The script to recover a database from a full backup is called syb_recover.sh. It loads a set of full database backup
files into a user database of a given Sybase instance. Additionally it remaps AMOS users to Sybase logins and
restarts the corresponding AMOS server to enforce the reactivation of the AMOS maintenance key. This requires a
password-less SSH login to the host of the AMOS server. A configuration file (by default etc/recovery.cfg) and the
toolbox files toolbox.sh and sybase_toolbox.sh are required by this script.
Function
The script provides the following features:

it loads a full backup from one or more backup files and onlines the database. It can also load transaction
dumps located in a specific folder.
AMOS users are remapped to Sybase logins
AMOS parameters for the client title and background image can be customized
AMOS workflows are disabled and AIM config is deleted
the AMOS masterkey file is copied from the source to the target AMOS server
the target AMOS server is previously stopped and restarted at the end to enforce the recovery of the AMOS
maintenance key from local maintenance key backup
allows to trigger pre- and post-scripts for further customization
allows to save the printer settings from the reload of the database
Usage
The script's syntax is:

syb_recover.sh [-c | -h | -f <config file> ]
Without the option –f the script uses the configuration file etc/recovery.cfg.
Options:
-c : let the script check the configuration only. No backup is loaded.
-f file : the script uses file as configuration file. Without this option the file etc/recovery.cfg is used by default.
RECOVER_SYBASE_DIR The path of the sybase server folder
RECOVER_SYBASE_ENV The script to set the Sybase environment variables
RECOVER_DSPASS The sa login's password file

(a restricted access to this file is strongly
recommended)
RECOVER_DSQUERY The Sybase instance's name
SWISS-AS.COM
31/52
RECOVER_BACKUP_SERVER The Sybase backup server instance's name
RECOVER_DATABASE Name of the user database to be recovered
RECOVER_LOGFILE_NAME Name of the session log file
OVERWRITE_LOGFILE Overwrites last session log file or keep it and appends.

Windows powershell DEFAULT: $true
Linux bash DEFAULT: Y
RECOVER_LOCKFILE Name of the lock file
TITLE_TEXT AMOS title text
BACKGROUND_IMG AMOS background image [test,prod,training]
SOURCE_HOST Host of source AMOS server (derived)
SOURCE_AMOS Path of source AMOS server
MASTERKEY The source AMOS server's masterkey file
RECOVER_HOST Host of target AMOS server (derived)
RECOVER_AMOS_LOCAL Local path of target AMOS server
RECOVER_AMOS Path of target AMOS server
RECOVER_MASTERKEY The target AMOS server's masterkey file
RECOVER_SERVICE The target AMOS server's service name
RECOVER_DIR The main backup directory
RECOVER_FILES Backup files of a backup set (Windows powershell:

comma separated, Linux bash: space separated)
DISABLE_WORKFLOWS Defines if AMOS workflows need to be disabled.

Windows powershell [$true / $false]. DEFAULT : $true
Linux bash [ Y / N ]. DEFAULT : Y
DELETE_AIM_CONFIG Defines if AIM configuration needs to be deleted.

Windows powershell [$true / $false], DEFAULT : $true
Linux bash [ Y / N ], DEFAULT : Y
KEEP_PRINTERS_SETTINGS Defines if the environment which is recovered will keep

its printers settings.
Windows powershell [$true / $false]. DEFAULT: $false
Linux bash [ Y / N ]. DEFAULT: N
SWISS-AS.COM
32/52
PRE_SCRIPT A script that will be triggered before the backup is

loaded
POST_SCRIPT A script that will be triggered after the database has

been loaded, before AMOS is restarted
BACKUP_LOCKFILE Name of the backup lockfile (to check if a backup of the

Must be the same as defined in backup.cfg.ps1 in
Windows powershell and backup.cfg in Linux bash
respectively.
System Requirements
The Linux user that runs the recovery script needs to have the correct permissions on the required files and
directories. Additionally, a password-less SSH login is required between the user running the recovery script and the
user running the target AMOS server (see ssh-keygen for details). The AMOS maintenance key on the target
AMOS instance has to be backed up previously in order to allow automatic maintenance key recovery.
SWISS-AS.COM
33/52
Logshipping script
The scripts used for log shipping are called logship_full.sh and logship_inc.sh. They are usually called
automatically by the full and incremental backup scripts but can also be used manually. They copy a set of backup
files to a remote server and load them into the target database. A configuration file (by default etc/logship.cfg) and
the toolbox files toolbox.sh and sybase_toolbox.sh are required by these scripts.
Function
The script logship_full provides the following features:

it copies and loads a set of full backup files from a local directory into a remote database. The remote server
is usually used as a standby system.
removes old backup files on the remote server
performs check of the configuration parameters
synchronizes the AMOS application server and webdrive directories with the remote server (robocopy)
archives logship scripts old log files
The script logship_inc provides the following features:
it copies and loads a set of incremental backup files into the remote database
the backup file of an incremental backup that has been loaded successfully is archived
Usage

logship_full.sh [-c | -h | -f <config file> ] <backup file1> <backup file2> ...
logship_inc.sh [-c | -h | -f <config file> ] <backup file1> <backup file2> ...
Without the option –f the script uses the configuration file etc/logship.cfg.
Options:
-c : let the script check the configuration only. No file is transferred.
-f file : the script uses file as configuration file. Without this option the file etc/logship.cfg is used by default.
SWISS-AS.COM
34/52
SHIP_LOCKFILE Name of the lock file
SHIP_LOGFILE_NAME Name of the session log file
SHIP_LOG_RETENTION_DAYS Amount of days (n * 24h) log files shall be stored prior to

deletion.
SHIPDB The target database
SHIP_DSQUERY The target Sybase instance (defined in local interfaces

file)
SHIP_DSPASS The target Sybase instance's sa password
REMOTE_SHIP_PATH Path of remote backup directory
REMOTE_SHIP_PATH_LOCAL Local path of remote backup directory
REMOTE_SHIP_PATH_LOG Path of remote transaction log backup directory
REMOTE_SHIP_PATH_LOG_LOCAL Local path of remote transaction log backup directory
REMOTE_SHIP_PATH_ARCHIVE Path of remote transaction log archive directory
SHIP_SRV Hostname of target database server
SHIP_FROM_AMOS_HOST Host of source AMOS server
SHIP_FROM_AMOS_DIR The source AMOS directory
SHIP_FROM_AMOS_WEBDRIVE The source AMOS webdrive directory (derived)
SHIP_TO_AMOS_HOST Host of target AMOS server
SHIP_TO_AMOS_DIR The target AMOS directory
SHIP_TO_AMOS_WEBDRIVE The target AMOS webdrive directory
System Requirements
The Linux user that runs the recovery script needs to have the correct permissions on the required files and
directories. Additionally, a password-less SSH login is required between the user running the logship scripts and the
user running the target AMOS and DB servers (see ssh-keygen for details).
Swiss AviationSoftware Ltd.

BSLSAS/CS
P.O.Box, CH-4002 Basel, Switzerland
Tel.: +41 61 582 72 94
Fax: +41 61 582 70 17
SWISS-AS.COM
35/52
Backup and Recovery Scripts for Windows
SWISS-AS.COM
36/52
Introduction
Swiss-AS provides powershell and linux bash scripts for the backup and recovery of Sybase databases used by
AMOS. The script's configuration need to be adapted to the customer's AMOS environment so that they can be
used either manually or scheduled via the task scheduler and cron. All scripts make use of a configuration file that
stores all required parameters and a so called toolboxes which are files that define particular functions. Usually, only
the configuration files need to be changed by the customer in order to get the script running.
This document describes the script's usage and the configuration.
General Notes
Predefined Configuration files : each script requires a specific set of parameters stored in a configuration file.
A template of each of the three configuration files (backup.cfg.ps1/backup.cfg, recovery.cfg.ps1/recovery.cfg
and logship.cfg.ps1/logship.cfg) is provided together with the backup, recovery and logshipping scripts and
the toolbox files.
General Toolbox : the toolbox file toolbox.ps1/toolbox.sh defines generic functions used in the backup and
recovery scripts. By default the toolbox file is located in the same directory as the corresponding script.
Sybase Toolbox : the toolbox file sybase_toolbox.ps1/sybase.toolbox.sh defines Sybase specific functions
used in the backup and recovery scripts. By default the toolbox file is located in the same directory as the
corresponding script.
Powershell execution policy : to be able to run powershell scripts on a host, the execution policy needs to be
adjusted (see Set-ExecutionPolicy command). It is possible the change the policy to the whole server or only
for one script execution (see ByPass execution policy)
Introduction
General Notes
Backup scripts
Function
Usage
System Requirements
Recovery scripts
Function
Usage
System Requirements
Logshipping script
Function
Usage
System Requirements
Backup scripts
The scripts to create database backups are called syb_backup.ps1 and syb_dump_trans.ps1 :
syb_backup.ps1 : creates a set of backup files of one or more user databases and all system databases of a
given Sybase instance.
syb_dump_trans.ps1 : creates an incremental backup file of one or more user database and truncates the
transaction log of all system databases of a given Sybase instance. The backup file is added to the current
backup set
A configuration file (by default etc/backup.cfg.ps1) and the toolbox files toolbox.ps1 and sybase_toolbox.ps1 are
SWISS-AS.COM
37/52
required by those scripts.
Function
Full backup script provides the following features:
each database's backup can be compressed and striped to multiple files

outdated backup sets can be automatically removed from the backup directory
each backup set consists of the current full backup files and the incremental backup files that have been
created since the last full backup
creates a backup of all system databases
the script prevents multiple simultaneous executions of a full backup. It queues up a full backup in case an
incremental backup is still running.
archives backup scripts old log files
Incremental backup script provides the following features:
the backup file is added to the current backup set and is identified by a sequence number and a process ID
by default all databases that are part of the full backup (see syb_backup.ps1) are included, but particular
databases can be omitted
truncates the transaction log of all system databases instead of an incremental backup
Usage
syb_backup.ps1 [-CheckConfig [$true|$false] | -Help [$true|$false] | -ConfigFile <config file>

| $LogshipInit=$false]
syb_dump_trans.ps1 [-CheckConfig [$true|$false] | -Help [$true|$false] | -ConfigFile <config
file> ]
Without the option –ConfigFile the script uses the configuration file etc/backup.cfg.ps1.
Options:
-CheckConfig : let the script check the configuration only. No backup set is created.
-Help : shows the usage
-ConfigFile file : the script uses file as configuration file. Without this option the file etc/backup.cfg.ps1 is used
by default.
-LogshipInit : overwrites the standby database, logshipping needs to be configured to use this parameter.
The script requires the following configuration parameters that need to be defined in the script's configuration file. By
SWISS-AS.COM
38/52
default the configuration file is etc/backup.cfg or it can be provided using option –ConfigFile for Windows powershell
and option -f for Linux bash respectively.
SYBASE_DIR The path of the Sybase server folder
SYBASE_ENV The script to set the Sybase environment variable
DSPASS The sa login's password file (a restricted access to this

file is strongly recommended)
DSQUERY The Sybase instance's name
BACKUP_SERVER The Sybase backup server instance's name
DATABASES Names of the user databases to be backed up

space separated)
NO_TRAN_DATABASES Names ot the user databases you do not want to

backup (Windows powershell: comma separated, Linux
bash: space separated)
SYS_DATABASES Names of the system databases to be backed up

space separated)
RETENTION_DAYS Amount of days (n * 24h) backup sets shall be stored

prior to deletion.
If set to 0, only the last backup set is kept (see
PREVIOUS_SET)
MAX_BACKUPSETS Max number of backupsets to be kept (including

current)
NUMBER_OF_STRIPES The dump can be split into "stripes" to accelerate the

backup process. DEFAULT: 2
COMPRESSED Dumps can be compressed to save disk space

Windows powershell: [ $true / $false ], DEFAULT: $true
Linux bash: [ Y / N ], DEFAULT: Y
COMPR_LEVEL If compression is active ( Windows powershell: $true,

Linux bash: Y ), a compression level (0 - 9) must be
provided. DEFAULT: 3
SWISS-AS.COM
39/52
LOGFILE_NAME_FULL Name of the full backup log file
LOGFILE_NAME_TRAN Name of the incremental backup log file
USE_SESSION_LOG_TRAN Use session log.

If enabled, generate one log file per execution. If
disabled, use one single file and append results to it.
LOG_RETENTION_DAYS Amount of days (n * 24h) log files shall be stored prior to

deletion.
LOCKFILE Name of the lock file (to avoid simultaneous executions)
RECOVER_LOCKFILE Name of the recovery lockfile (to check if a load of the

Must be the same as defined in recover.cfg.ps1 for
WIndows powershell and recover.cfg for Linux bash
SHIP_ACTIVE Log shipping active.

SHIP_FULLSCRIPT Name of full log shipping script.

Windows powershell DEFAULT: logship_full.ps1
Linux bash DEFAULT: logship_full.sh
SHIP_INCSCRIPT Name of incremental log shipping script.

Windows powershell DEFAULT: logship_inc.ps1
Linux bash DEFAULT: logship_inc.sh
INFORMATION_FOLDER Folder where the AMOS information files are located.

See "server1.info.cfg" config file for further information
DUMP_WITH_SA Defines if the target database has to be onlined with

standby access. This parameter needs to
be enabled if you use the report connection in AMOS
SWISS-AS.COM
40/52
DUMP_WITH_SA_REC The transaction log dumped with standby access does

not contain the non-commited transactions, therefore it
is
possible to reduce the number of such dumps.
Default: 4
System Requirements
The Windows user that runs the backup script needs to have the correct permissions on the required files and
directories.
SWISS-AS.COM
41/52
Recovery scripts
The script to recover a database from a full backup is called syb_recover.ps1. It loads a set of full database backup
files into a user database of a given Sybase instance. Additionally it remaps AMOS users to Sybase logins and
restarts the corresponding AMOS server to enforce the reactivation of the AMOS maintenance key. A configuration
file (by default etc/recovery.cfg.ps1) and the toolbox files toolbox.ps1 and sybase_toolbox.ps1 are required by
this script.
Function
The script provides the following features:

it loads a full backup from one or more backup files and onlines the database. It can also load transaction
dumps located in a specific folder.
AMOS users are remapped to Sybase logins
AMOS parameters for the client title and background image can be customized
AMOS workflows are disabled and AIM config is deleted
the AMOS masterkey file is copied from the source to the target AMOS server
the target AMOS server is previously stopped and restarted at the end to enforce the recovery of the AMOS
maintenance key from local maintenance key backup
allows to trigger pre- and post-scripts for further customization
allows to save the printer settings from the reload of the database
Usage

syb_recover.ps1 [-CheckConfig [$true|$false] | -Help [$true|$false] | -ConfigFile <config
file> ]
Without the option –ConfigFile the script uses the configuration file etc/backup.cfg.ps1.
Options:
-CheckConfig : let the script check the configuration only. No backup set is created.
-ConfigFile file : the script uses file as configuration file. Without this option the file etc/backup.cfg.ps1 is used
by default.
RECOVER_SYBASE_DIR The path of the sybase server folder
RECOVER_SYBASE_ENV The script to set the Sybase environment variables
SWISS-AS.COM
42/52
RECOVER_DSPASS The sa login's password file

(a restricted access to this file is strongly
recommended)
RECOVER_DSQUERY The Sybase instance's name
RECOVER_BACKUP_SERVER The Sybase backup server instance's name
RECOVER_DATABASE Name of the user database to be recovered
RECOVER_LOGFILE_NAME Name of the session log file
OVERWRITE_LOGFILE Overwrites last session log file or keep it and appends.

Windows powershell DEFAULT: $true
Linux bash DEFAULT: Y
RECOVER_LOCKFILE Name of the lock file
TITLE_TEXT AMOS title text
BACKGROUND_IMG AMOS background image [test,prod,training]
SOURCE_HOST Host of source AMOS server (derived)
SOURCE_AMOS Path of source AMOS server
MASTERKEY The source AMOS server's masterkey file
RECOVER_HOST Host of target AMOS server (derived)
RECOVER_AMOS_LOCAL Local path of target AMOS server
RECOVER_AMOS Path of target AMOS server
RECOVER_MASTERKEY The target AMOS server's masterkey file
RECOVER_SERVICE The target AMOS server's service name
RECOVER_DIR The main backup directory
RECOVER_FILES Backup files of a backup set (Windows powershell:

comma separated, Linux bash: space separated)
DISABLE_WORKFLOWS Defines if AMOS workflows need to be disabled.

Windows powershell [$true / $false]. DEFAULT : $true
Linux bash [ Y / N ]. DEFAULT : Y
DELETE_AIM_CONFIG Defines if AIM configuration needs to be deleted.

Windows powershell [$true / $false], DEFAULT : $true
Linux bash [ Y / N ], DEFAULT : Y
SWISS-AS.COM
43/52
KEEP_PRINTERS_SETTINGS Defines if the environment which is recovered will keep

its printers settings.
Windows powershell [$true / $false]. DEFAULT: $false
Linux bash [ Y / N ]. DEFAULT: N
PRE_SCRIPT A script that will be triggered before the backup is

loaded
POST_SCRIPT A script that will be triggered after the database has

been loaded, before AMOS is restarted
BACKUP_LOCKFILE Name of the backup lockfile (to check if a backup of the

Must be the same as defined in backup.cfg.ps1 in
Windows powershell and backup.cfg in Linux bash
respectively.
System Requirements
The Windows user that runs the recovery script needs to have the correct permissions on the required files
and directories (including remote ones).
The AMOS maintenance key on the target AMOS instance has to be backed up previously in order to allow
automatic maintenance key recovery.
AMOS Config server tool is remotely executed on the target AMOS host, so make sure WinRM is well
configured regarding Java Memory consumption.
SWISS-AS.COM
44/52
Logshipping script
The scripts used for log shipping are called logship_full.ps1 and logship_inc.ps1. They are usually called
automatically by the full and incremental backup scripts but can also be used manually. They copy a set of backup
files to a remote server and load them into the target database. A configuration file (by default etc/logship.cfg.ps1)
and the toolbox files toolbox.ps1 and sybase_toolbox.ps1 are required by these scripts.
Function
The script logship_full provides the following features:

it copies and loads a set of full backup files from a local directory into a remote database. The remote server
is usually used as a standby system.
removes old backup files on the remote server
synchronizes the AMOS application server and webdrive directories with the remote server (robocopy)
The script logship_inc provides the following features:
it copies and loads a set of incremental backup files into the remote database
the backup file of an incremental backup that has been loaded successfully is archived
Usage

logship_full.ps1 [-CheckConfig [$true|$false] | -Help [$true|$false] | -ConfigFile
<config file> ] -FileNames "<backup file1>","<backup file2>",...
logship_inc.ps1 [-CheckConfig [$true|$false] | -Help [$true|$false] | -ConfigFile
<config file> ] -FileNames "<backup file1>","<backup file2>",...
Without the option –ConfigFile the script uses the configuration file etc/logship.cfg.ps1.
Options:
-CheckConfig : let the script check the configuration only. No file is transferred.
-ConfigFile file : the script uses file as configuration file. Without this option the file etc/logship.cfg is used by
default.
SWISS-AS.COM
45/52
SHIP_LOCKFILE Name of the lock file
SHIP_LOGFILE_NAME Name of the session log file
SHIP_LOG_RETENTION_DAYS Amount of days (n * 24h) log files shall be stored prior to

deletion.
SHIPDB The target database
SHIP_DSQUERY The target Sybase instance (defined in local interfaces

file)
SHIP_DSPASS The target Sybase instance's sa password
REMOTE_SHIP_PATH Path of remote backup directory
REMOTE_SHIP_PATH_LOCAL Local path of remote backup directory
REMOTE_SHIP_PATH_LOG Path of remote transaction log backup directory
REMOTE_SHIP_PATH_LOG_LOCAL Local path of remote transaction log backup directory
REMOTE_SHIP_PATH_ARCHIVE Path of remote transaction log archive directory
SHIP_SRV Hostname of target database server
SHIP_FROM_AMOS_HOST Host of source AMOS server
SHIP_FROM_AMOS_DIR The source AMOS directory
SHIP_FROM_AMOS_WEBDRIVE The source AMOS webdrive directory (derived)
SHIP_TO_AMOS_HOST Host of target AMOS server
SHIP_TO_AMOS_DIR The target AMOS directory
SHIP_TO_AMOS_WEBDRIVE The target AMOS webdrive directory
System Requirements
The Windows user that runs the recovery script needs to have the correct permissions on the required files and
directories (including remote ones).

BSLSAS/CS
Tel.: +41 61 582 72 94
Fax: +41 61 582 70 17
SWISS-AS.COM
46/52
Database Maintenance
Core maintenance by the database administrator includes the following tasks:
full and incremental database backups following the customer's backup policies
update index and table statistics, defragmentation
database server error log monitoring
monitor database and table growth
monitor resource consumption
clean-up unused data/tables
increase database size (see AMOS Installation Guide for details)
Several tools within the AMOS application support DBAs and AMOS administrators to perform these tasks. Please
find an overview below.
Task AMOS Program Remarks
Update index statistics AMOS Scheduler APN 2606 Available tasks:

DatabaseMaintenance
Table/index defragmentation
Monitor database and table growth AMOS Control Center APN 2137 Tabsheet Database
Monitoring/Table Evolution
Monitor resource consumption Statistic Analyzer APN 156 Activation of statistics module
required (APN 10)
Data clean-up (data only) Data Clean-Up APN 2167 Removes dispensable and outdated
data
Data clean-up (unused tables) Protected customer objects APN Remove tables formerly used by
2254 AMOS
System Administrator Role
Client Configuration Files

The AMOS client is configured using configuration files in each client's cfg directory. All these files store Java or
AMOS properties using the format name = value, for example:
Port = 80
There is always one value per line. If the line begins with a #, the line is treated as a comment and not evaluated.
Parameter names and values are case sensitive.
server.cfg
SWISS-AS.COM
47/52
This file contains all the settings that are required to reach the server and some general settings. Most of the
settings are already applied during the client installation, they can be changed with the corresponding AMOS
program. You can create multiple server.cfg files if you need to connect a client to multiple servers. The servers
have to be sequentially numbered, e.g
server.cfg, server2.cfg, etc
This way you can create multiple profiles, for example, one for the test server, one with a proxy and a direct one.
Please note that the first file (server.cfg) is the master file. This file will always be used by the automatic client
update procedure to refresh the client. Only when you reach the login dialog you will be able to select one of the
stored profiles. The AMOS client programs always record their settings in the master file, irrespective of the profile
that you selected at log in.
The following parameter are allowed in the server.cfg:
Runtime
Version of the Java runtime environment. This is entered automatically by the updater, and is used to check whether
the Java runtime environment used by the AMOS client is current up to date , or if there is a newer version available
on the server. The version is stored as a number. e.g.
Runtime = 170040
for the Java version 1.7.0_40

Client
In this parameter the update process stores current version of the AMOS client. This is done in order to verify if
there is a more recent version of the client version available on the server that the update process needs to
install.The version is stored as a string. e.g.
Client=10.30-009
for a client version 10.30-009.
build.revision
Holds the internal build number of AMOS.
SupportEmail
The email address of the automatically generated support emails which are registered here. This value is always set
automatically each time a user logs in using the value of AMOS parameter 1232. Manual changes to this parameter
will be overwritten.
System
This is an internal field which is used by the client updater. Should the the update logic change, the server can
determine by using this number if the client is still using the old update logic or if the client understands the new
logic. This is necessary in order to smoothly and continuously upgrade old clients to the new update logic. This
value should never be changed manually.
Server
Here the name or the IP address of the AMOS server is stored to which the client connects to, e.g.
SWISS-AS.COM
48/52
Server = amosserver.swiss-as.com
Port
The port of the AMOS server is specified with this value. As default the AMOS server runs on port 5080.
ProxyHost
If the internet is only accessible through a proxy server, you can configure the name or IP address of the HTTP
proxy server for here, e.g.
ProxyHost = proxy.swiss-as.com
ProxyPort
This value allows you to specify the proxy port. Often this is port 8080, e.g.
ProxyPort = 8080
ProxyIgnoreList
This value can be used to determine a list of addresses that should be accessed directly and not through the proxy.
You can use the * to specify an address group and you can separate multiple entries with a comma; e.g.
ProxyIgnoreList = *.swiss-as.com, amosng.crossair.ch, test.*.local
ProxyUser
If the HTTP proxy requires authentication you can enter the user here, e.g.
Proxy = proxy user
ProxyPassword
If a password is required for the proxy, you can store the password here. Note that the stored password is encrypted
and cannot be changed manually. You can change it if you access the AMOS Client login dialog or if you run the
ProxySelector tool.
UseProxyForAmos
If the AMOS server cannot be accessed directly, but only through the Internet, you can determine if the AMOS client
should connect to the AMOS server through a proxy with this field. This requires a proxy configuration (see above).
The proxy server must be configured that it allows TUNNEL to the AMOS server (HTTP Connect). Acceptable
values are true and false, e.g.
UseProxyForAmos = true
AllowProxyChange
This parameter can be used to control whether the proxy settings may be changed in the AMOS login dialog. If this
field is set to true, then an additional button will be visible with which you can call up the Proxy Settings dialog, e.g.
SWISS-AS.COM
49/52
AllowProxyChange = true
LastLogin
If the AMOS client is configured to display the last used login, this parameter stores the name of the user that loged
in successfully. The next time a user starts the client the login name will be prefilled with the value of this parameter.
See also AMOS parameter 1219.
Remote
This flag can be set to true to prevent multiple animations and background images to be displayed which would take
a long time to process during a screen refresh. These images would unnecessarily extend this action and would
make a screen refresh very long tedious action. This mode is especially interesting when the AMOS client is used
via Remote Desktop, VNC, Tarantella or Citrix.
AllowClientConfigureSettings
With this flag you can hide some menu configuration options concerning graphic acceleration, re-download client
and DDE handler settings in the AMOS client. If you set this flag to false, these corresponding menu options are not
displayed in the client.
EnvironmentName
This parameter allows you to create an alias for the server name (or IP) and port that will be displayed in the login
dialog.
AllowCancel
If this parameter is set to true then a timer is started to monitor the scroll lock key. If this key is pressed a program
will be launched that allows you to cancel the current running AMOS transaction. This should be only used for
training or presentation purpose to unblock AMOS if one action takes to long. This is not an end user feature.
UseUpdater
If this parameter is set to true then the automatic update process will be used to install new versions of the client. If
you want to roll out all patches on your own you can set this property to false to deactivate the updater completely.
UseSsl
To activate SSL for the client-server communication, the this parameter has to be set to true and the correct port
number has to be specified in the port property. Additionally the client should be rolled out already with the correct
certificates of the AMOS server.
launch.cfg
This file contains some settings that influence the AMOS client launcher. The launcher has some predefined default
settings that can be overritten by creating or editing this file. The following properties can be used:
vm
Defines the path to the Java runtime executable, default is

vm =.\jre\bin\javaw
Set this property to use another Java VM or to use java.exe instead of javaw.exe.
SWISS-AS.COM
50/52
vmargs
Set this parameter to specify additional arguments to the Java VM. This parameter can be used to increase the
client's memory to more than the default of 512 MB, e.g.
vmargs = -Xmx1024m -XX:MaxPermSize=128m
will allow the client to use up to 1024 MB memory. Note that this also requires to increase Java's permanent
generation (PermGen) memory as shown above.
stayAlive
Set this flag to true to make the launcher stay alive. The launcher will then no longer terminate itself but will wait for
the client to terminate before it terminates itself. It will catch all console output from the client and dump it to the
standard console output (system out). Use this if you need to monitor the console of the AMOS client. This
parameter is deactivated per default.
mainClass
This parameter defines the main class that is started by the launcher. The default is amos.client.Client. Note that the
class that you define here needs to have a main method.
updaterClass
Using this parameter an updater class can be specified that is executed before the main class is launched in a
separate VM. The updater is launched in the same VM as the launcher. Per default the launcher tries to start the
class amos.client.Updater. If the class is not found this is ignored. Note that the class that is specified needs to
implement the Runnable interface.
cleanup.cfg
The last time a cleanup of the Client was executed is recorded in this file. From time to time a cleanup job is run to
delete deprecated classes and icons. This file is created automatically after that job has finished.
This file contain the version number of the client and the time when the cleanup job has been executed for the last
time.
directDraw.cfg
In this file, the settings that you will find in the client configuration regarding Graphics Accelleration are saved. These
are internal Java settings and are forwarded directly to the Java runtime system. The values true or false are
allowed for all settings.
FontCache
Enables or disables the font cache.
OnScreen
Enables or disables direct draw onscreen rendering. If disabled, no direct draw will be used. This can help with faulty
graphics card drivers.
OffScreen
Enables or disables direct draw offscreen rendering. If disabled, no direct draw will be used. This can help with faulty
graphics card drivers.
SWISS-AS.COM
51/52
FastDialogs
This disables some native MS Windows options and resolves issues with file dialogs on certain computers.
Version
This field is only for internal use, should all settings from the server for all the clients be overwritten. The server can
check the version number to ensure if this has already been done for a particular client. This is only required if you
want to reset the default behavior for all clients.
edoc.cfg
In this file, all settings that are of interest to the integration for the eDoc are stored here. This file is automatically
generated when an eDoc link is created or opened for the first time. The file automatically searches for the eDoc
client and if found, the path is stored in this file.
ClientPath
The path to the eDoc Java viewer is stored here.
EDocUser
The user name and password that is used for authentication in to the eDoc client is stored in this parameter. If this
value is not set the current AMOS login sign will be used. With these settings you can, for example login as another
user and also use another user's eDoc settings. User name and password can be both specified separated by a
pipe (|), e.g.
EDocUser = username|password
registered.cfg
This file is actually not a configuration file but a MS Windows registry script.This script is used to register the AMOS
client as a DDE server and as a DDE handler for the protocol amos :/ /. This can be done in the client's configuration
menu.
sim_colors.cfg
Color, buttons, images and all other settings which are used in the Simulator Terminal application are defined here.
By changing these value, the GUI of the application can be completely changed. When you use the Simulator
Terminal application for the first time the default value is stored in this file. The settings are to exhaustive to list them
all here.
simulator.cfg
All settings for the Simulator Terminal application are stored here. All options can be set in AMOS client in the
Terminal Configuration application. The individual settings are not described in detail here
AMOS Server Configuration
Java Memory Configuration
Adjusting Java memory of the AMOS Server and the amos_config_server command line tool
Use the Configuration option in the amos_config_server command line tool to increase the memory of the
application server and the amos_config_server command line tool respectively. Note that you need to restart the
application and the command line tool in order to make the new memory values effective.
System Monitoring
SWISS-AS.COM
52/52
The monitoring & troubleshooting of the AMOS environment should include the following tasks:
disk space of the application server and database server partitions, usually /applic, /data, /log, /backup and
/webdrive. In MS Windows, the corresponding partitions might be located on different drives.
memory consumption of java processes and the dataserver processes. In MS Windows, this is the AMOS
service and sqlsrver.exe.
CPU usage of Java processes and the dataserver processes. In MS Windows, this is the AMOS service and
sqlsrver.exe.
creation of incremental and full backup files. Usually, these files are stored in /backup or on a backup drive in
MS Windows.
prepare tools to create Java heap and thread dumps in order to identify performance problems
Document Information Administration Guide
BSLSAS/CS
Tel.: +41 61 582 72 94
Fax: +41 61 582 70 17
SWISS-AS.COM

AMOS 12.00 Administration Guide

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

AMOS 12.00 Administration Guide

Загружено:

Авторское право:

Доступные форматы

Aircraft Maintenance & Engineering System

AMOS Administration Guide

© Swiss Aviation Software Ltd.

AMOS Administration Guide

Overview of AMOS Administration

AMOS Release Terminology

Patch / Cumulative Patch

Stable Release version 10.30-08 (aka version 1030007)

major version minor version revision patch level

Preview Release version 10.31(f) (aka version 1031500)

10. 31 (f) n/a, always 00

Release File Download

Swiss-AS recommends to follow the below guidelines.

Phase When What Where

Preparation 24h before Update database statistics AMOS APN 2606

Set appropriate number of AMOS APN 1442

Check database space DB

Check file system space of OS

Install latest patch AMOS APN 10

Upgrade Immediately before Disable automatic OS/DB

Perform manual database DB

Block users AMOS APN 10

Zero Schedule the AMOS AMOS APN 2313

Upgrade Immediately afterwards Analyse release change AMOS APN 2083

Perform Data Correction

Forecast With no release change DataSyncDaemon and AMOS APN 2606

With no release change Perform Forecast AMOS APN 2301

Post-Work Upon successful release Perform a manual database DB

Renew the AMOS AMOS APN 1500

Verify interfaces AMOS APN 902

Setup new required AMOS APN 2606

Allow common users to AMOS APN 10

Incremental Release Change

Precondition Syntax Example Screenshot

It is required to create a target_version=<your_targ target_version=1080012

In the parent folder of the n/a n/a

You can verify the setup of n/a n/a

Production Data Flow Pre-Go-Live Data Flow

Copy of AMOS Keystore Masterkey File

AMOS Maintenance Key Backup

Restore Database User Permissions

Text Index Location

Database Connection Pools

Automatic Maintenance Key Update

AMOS Executor Framework Configuration

Maintenance Key and Certifcate Checks

How to check if the Deferred Job is enabled and scheduled?

Keystore Area Warning!

More information about the License Key Certificate

How to create a new License Key Certificate?

Press button OK.

How to request a new Maintenance Key?

Click on "Import Key" and the process will be completed.

AMOS Control Center

Database Administrator Role

Backup, Recovery and Log Shipping

Full backup script provides the following features:

each database's backup can be compressed and striped to multiple files

Incremental backup script provides the following features:

The scripts syntax is:

SYBASE_DIR The path of the Sybase server folder

SYBASE_ENV The script to set the Sybase environment variable

DSPASS The sa login's password file (a restricted access to this

DSQUERY The Sybase instance's name