Who or What are the Autons?

Well... The Autons are dummies! They were a monster that the "Doctor" faced in the legendary TV series "Doctor Who", (see picture on the right). Or the Autons could be Automatic Nightly System. The goal of the Autons project was to replace an existing application used by my place of employment (Ace). The goal was to replace an old REXX application that ran the nightly processes, this program was called "BatchBotlR6". (REXX is an old scripting language that is basically a text file that gets read and executed from top down at run time.)

What did BatchBotlR6 do exactly?

Firstly I would like to confirm that I have removed any information that could be considered private information to ACE and will only talk about the way in which this program was build and designed to run rather than any specifics about ACE or the processes it was designed to run. Please do not ask for any information regarding this as I will not give any.

BatchBotlR6 started as a very simple program that would run through a list of commands and process the files it finds accordingly. Basically it would have a similar setup to what follows:

//Run process1
location=d:\folder1
app=process1
filetype = *.*
CALL RUNAPP

//Run process2
location=d:\folder2
app=process2
filetype = *.txt
CALL RUNAPP

//Run process3
location=d:\folder3
app=process3
filetype = *.xls
CALL RUNAPP

//RUNAPP
//find the files.
//call the correct app passing in the files and correct INI files
(N.B. some processes create their own INI files dynamically at run time)
//archive files

The above shows a very rudimentary exert from the original script. It would run down the list setting up the folders and file types to look for. It would then call the RUNAPP process to execute that section. After processing a folder it will archive the files off to another folder. This carries on until all the folders are done.

What was the purpose of the Autons project?

The goal was to remove this REXX program and replace it with a .NET application, (part of the companies redevelopment of older technologies). The reason this program was chosen as a early one to be redeveloped was it started out as a clean small piece of code and ended up in some what of a bad state. It was not clear what exactly it did and did not do anymore. The main issue was the way in which it was developed was a bit clunky, a lot of, "if this country do X" "if that country do Y". We support 19 countries with MANY different processes to automate. As you may imagine this soon became horrible and un-maintainable code. My objective was to fully understand how it worked and implement a program that will remove the ability for this to happen again. We wanted a way of "soft coding" the jobs while having the backbone unchangeable, also to ensure that the way the jobs were setup would not conflict with the way they should run.

The project went through two cycles, version 1 and version 2. In the first version there was a lot of setting the ground work and getting things to work, the second cycle refinded things a lot and added some extra funcationality.

Please follow the links below to each version:

• version 1
• version 2