---
title: "After Image Engine"
canonical: "https://kb.myframeworks.com.au/space/FRAM/28396324/After%20Image%20Engine"
format: markdown
---
# How it works

The main 'AI Engine' script that controls the switching, copying, and applying of the AI logs is called cp_next_ai. It is set to run as a root via **cron** every **[SyncInterval]**, anything from once an hour to every 5 minutes. It has a single argument passed in, which is the database instance name, typically 'live'. It is heavily commented, but its main steps include:

1. Creates a lock file, **[AiLogPath]**/swailive.inprocess, which is deleted on script completion, and is used to stop a second iteration of the script from starting, particularly if the previous run took longer than  **[SyncInterval]** to complete.
2. Creates a log file, **[AiLogPath]**/swailive.mmddHHMM, used to log its steps, which is emailed at script completion, with either a **'success'** or **'failure'** subject status.
3. Pings the DR server to check that it is up and exits with failure if it is not up.
4. Switches AI extents, if there are less than 9 full, otherwise exits.
5. Copies the oldest full extent to **[LiveAiCopy]**, where it is then compressed and copied to the DR server using** [RemoteMethod]** as **[RemoteUser]**, to **[DrAiCopy].**
6. Runs the `roll_forward_ai` script on the DR server using as root, which uncompresses the copied AI log file, and applies it to the warm spare database using the Progress rfutil command, for example:
  
7. If the roll forward fails, the script exits, otherwise it re-compresses the AI log file on the DR server, and moves both the local Production copy and remote DR copy of the compressed AI log to the archive directories **[LiveAiCopyOld]** and **[DrAiCopyOld]** which are both purged of files older than 7 days.
8. It then empties the AI log file it just processed, making it available for re-use.
9. It then loops through steps 5-8 processing any other full extents if they exist. For example, if a previous switch was made via cp_next_ai but then failed at some point afterwards, or the next time cp_next_ai is run after an online Progress backup, which also switches AI extents.
10. Next, it optionally remotely calls the drlive2demo.sh script, to refresh the DR Demo DB. Often though this step is run via a separate 10pm cron job on the DR server.
11. Once the script finishes, either by getting to the end successfully, or by failing at any point and exiting with an error, its last step is to send its log file via unix mail to **[MailAccount].** The read_registry script defines the username to send the email to. It can either be a local unix user account, which requires a POP mail client configured to retrieve them, or if a smart mail host has been defined on the unix server, it can be any external email address.