Amiga Computing - Commodore Is Awesome

Looking for on easy
way to organise
backup operations?:
Paul Overaa shows
you how
On many platforms, including the PC,
REXX (the language upon which
ARexx is based) is used primarily as a
^^^ macro language for system house
keeping operations. Moving and renaming sets of
files, batch editing of text files, performing stan
dardised backup operations and so on.
This system-oriented use is perfectly under
standable on these other platforms since the
operating system is, to a large extent, the only
other 'process' that can be communicated with.
ARexx of course, has no such restrictions and in
this sense Amiga users are extremely fortunate.
ARexx's ability to communicate easily with
other programs does tend to result however, in
the potentially useful batch processing links with
AmigaDOS, often taking a back seat Now this is
clearly a shame because for these types of appli
cations, ARexx is far more powerful than
AmigaDOS's own scripting language and you
need look no further than the rather neglected
area of data backup to realise the possibilities.
Whilst data safety is obviously the primary con
cern, the objective of any type of backup arrange
ments ought really to be to get some sort of sys
tem going which makes routine data backup as
easy as possible. It is, after all, a well known fact
that procedures which are awkward tend not to
get followed.
Fortunately for most users, backing up a com
plete high-capacity hard disk on a regular basis is
almost never necessary. For example, programs
themselves, once backup copies of the master
disks have been made, do not need further regu
lar backing up. The unwritten rule with data files
of course is that you back up files only as fre
quently as they change.
The key to success is organisation. Make sure
you have appropriate directory structures and/or
hard disk partitioning (ie the creation of a number
of different logical drives). One big help is to make
sure you keep data files separate from the applica
tions programs which create and use them.
Within this highest level division of programs
versus data, the next most useful hierarchy criteria
is the required file backup frequency. If, for exam
ple, an order file is backed up once a day, it is
worth keeping that data in a directory (or hard
disk partition) that contains only those files that
need to be backed up with this frequency.
An ARexx Example
Once you have a workable backup plan available
ARexx can, in most cases, completely eliminate
the need for using dedicated backup utilities. Let's
say, for instance, you're interested in automating
the backup of a directory called 'daily' that exists
on a partition called Work. In short you want to
copy, to floppy disk, any files present in that direc
tory whose contents have changed since the
With a little organisation, plus some help from ARexx,
almost all backup operations can become a piece of cake!
/* backup.ren */
TEHP='fiaa:T/te»pl
BACKUPJ£ST='dfO:daily'
A«CHlVEjn='ar
drawer was last backed up.
The trick here is to adopt the same method as
used by most archiving utilities. Whenever a file is
backed up the archive bit of the source file gets
set If, when the next backup is performed, that
bit is still set the file hasn't changed and does not
need recopying to your backup disk.
As far as doing this type of thing via ARexx is
concerned the important first step is identifying
the names of the files present in the chosen
source directory. ARexx's address command can
be used in conjunction with AmigaDOS's LIST
command to generate just such a list.
One approach is to set up a couple of constant
definitions to point to the source directory and to
a temporary file for storing the list command out
put. The files, nodates and nohead switches inci-
address cowaitd 'list' BACKUPJOURCE 'to' TEMP 'file; nodates nohead'
if Opentfh,TEHP,'r'> then
do
do uhile "EOF(fli)
Une=Readlri(fb)
if Length(Line)>0 then
do
parss var line file date flags
if PosURCHIVE BIT,flags)=O then
end
do
fi Le=BACKUP_SOURCE j|fi Le
say 'Batting up...' file
address coanand 'copy >NIL:' file 'to' BACKJPJEST
address cossand ■protect >HIL:' file '+a add1
end
end
call Closc(fh)
address comnd 'delete >HIL:' TENP
say 'Operations conplete!'
enc
dentally can be used on the LIST command line to
ensure that only the file names, size and protec
tion flags values are sent to the output file. ARexx
code such as...
BAC«:UP_SIJUSCE=1«ort:daiLy/1
TENP='Hai:t/teip'
address conarancE 'list' BACKUPJOURCE 'to' TEUP
'files
Itodatss "ahead1
therefore ends up generating a temporary file con
sisting of text lines whose general format is... ,
By reading these lines and splitting them into
individual name, size and protection flag values
using the ARexx PARSE instruction it's then easy
enough to check each flag set to see whether the
archive bit is clear or not Any file whose archive
bit is not set represents a file that has been altered
since the last backup, so all we need to do is copy
all such files to the destination backup directory -
resetting the archive bits of each source file as we
do so.
Now your individual requirements for backup
are doubtless going to be different from mine but
the example shown in listing 1 should give a rea
sonable starting point for creating your own back
up scripts. In this case it's the general ideas that
are the important thing - so the thing to do is to
set up some dummy source/destination directo
ries on your own system (modifying the script's
directory references to suit) and then experiment.
Once you see how these archive bit arrangements
work you should then be easily able to incorpo
rate similar ideas into your own backup arrange
ments!
Listing 1: A typical archive bit based ARexx backing up script. Notice how the >NIL: statement
is used to discard output from the copy, protect and delete commands'.
Amiga Computing
MARCH 1997