Re: Windows/Macro Language Info?

, I would periodically winzip my
class/program source code for archiving.

Hi:

This raises the question as to when a file should be backed-up.

A file should be backed-up immediately after it has been
changed in some way.  It should not be backed up further
if is never changed.

Source code should be backed-up immediately after
final compilation. You know, at that time,  that the
program compiled OK.

A Product File should be backed-up immediately after
changes and not thereafter unless multiple copies
were required.

As mentioned earlier, files can be damaged and nobody know.
If people "backup everything every day", then the time
will come when they wind up backing up files which
have been damaged and nobody know.

I have had several occasions where my source code has
been damaged over the years and, had I backed
everything up all at the same time, I would have
been backing up bad stuff and lost the code as of
its final compilation. (Of course, one has multiple
generations of backups, but still.)

Thanks
Tony Dilworth

In article <1112308317.534253.171720@z14g2000cwz.googlegroups.com>,
<foodman123@gmail.com> wrote:
>, I would periodically winzip my
>class/program source code for archiving.
>
>Hi:
>
>This raises the question as to when a file should be backed-up.
>
>A file should be backed-up immediately after it has been
>changed in some way.

Mr Dilworth, consider a situation of, say, an airlines reservation system
and the number of files that are changed every time a reservation is
confirmed or changed... thousands of people accessing thousands of records
closer to simultaneously than one might wish to get.  Might not the kind
of 'instantaneous backup' you advocate put sufficient drag on system
resources so that response-time could degrade to the point of
unacceptable?

Perhaps Mr Trembley might have a thing or two to say about systems which
undergo a few updates per second, as well... and how backups were handled
before RAID was invented.

DD

docdwarf@panix.com wrote:
> In article <1112308317.534253.171720@z14g2000cwz.googlegroups.com>,
>  <foodman123@gmail.com> wrote:
> 
>
>
> Mr Dilworth, consider a situation of, say, an airlines reservation system
> and the number of files that are changed every time a reservation is
> confirmed or changed... thousands of people accessing thousands of records
> closer to simultaneously than one might wish to get.  Might not the kind
> of 'instantaneous backup' you advocate put sufficient drag on system
> resources so that response-time could degrade to the point of
> unacceptable?
>
> Perhaps Mr Trembley might have a thing or two to say about systems which
> undergo a few updates per second, as well... and how backups were handled
> before RAID was invented.
>
> DD

But surely Raid was invented to get rid of bugs ? Bzzzz........

docdwarf@panix.com wrote:
> In article <1112308317.534253.171720@z14g2000cwz.googlegroups.com>,
>  <foodman123@gmail.com> wrote:
> 
>
>
> Perhaps Mr Trembley might have a thing or two to say about systems which
> undergo a few updates per second, as well... and how backups were handled
> before RAID was invented.
>
> DD

We handle backups pretty much the same way we did in 1986.  This is an
IBM mainframe application with CICS (now Transaction Server 2.x) and
batch processing.  The CICS files are primarily VSAM, and to maintain
24x7 availability we have two sets of files, primary and secondary.
In our overnight maintenance window, CICS processing is switched to
secondary files.  Primary files are then backed up, using standard
utilities, IDCAMS and SyncSort, then purged, reloaded, and refreshed.
We switch from secondaries back to primaries, and do the same batch
processing (backup, purge, reload, refresh) to the secondaries.

There is some debate as to whether SyncSort is faster than IDCAMS at
copying a file, but it doesn't make much difference unless the file is
really large (multiple gigabytes).  Naturally we back up to "tape",
but since we now have VTS I cannot be sure when it really goes to
tape, or to virtual tape.

We now have DB2 tables of course, but the DBA's seem to be in control
of backing up DB2 tables.

When it comes to backing up my home PC, I'm a bit careless.  I use ZIP
disks for backup, and rarely use compression.  I have PKZIP 2.50, but
not WinZip.

For incremental backup, I use a .bat file I wrote:

@echo off
cls
echo ÿ
echo  ****************************************
************************
echo * BCOPY.BAT copyright 2004-01-05 by Arnold J. Trembley         *
echo * copy new or changed files/subdirectories from the source     *
echo * directory to the target directory.  The Source parameter     *
echo * may include wildcard characters.                             *
echo  ****************************************
************************
if "%1"=="" goto ERR01
if "%1"=="/?" goto HELP
if "%2"=="" goto ERR02
goto OK
:err01
echo ÿ
echo Source directory not specified...
goto help
:err02
echo ÿ
echo Target directory not specified...
goto help
:help
echo ÿ
echo %0 -- Backup New/Changed folder to target directory
echo ÿ
echo Syntax is:  %0 Drive:\Path Drive:\Path
goto NOCOPY
:OK
echo ÿ
echo XXCOPY %1 %2 /backup /S /H /R /BN
echo ÿ
xxcopy %1 %2 /backup /S /H /R /BN
goto QUIT
:NOCOPY
echo ÿ
echo XXCOPY TERMINATED WITHOUT COPYING ANY FILES...
:QUIT
echo ÿ

This bat file also uses the XXCOPY freeware utility available from:
http://www.xxcopy.com/index.htm

It has a feature where it will bypass copying a file if the source and
target files have the same date/time stamp.  This is a great time-saver.

I just open a command line window, mount a ZIP disk and type something
like:  BCOPY \COBOL G:\COBOL
Only the new or changed files are copied to the target directory.
Backing up in the wrong direction doesn't hurt anything, because of
the date/time check.

Microsoft RoboCopy also has this feature, but you would have to
download an entire SDK to get this one utility.  I have a copy from NT
4.0 that someone gave me, and I believe it does not have any license
restrictions on sharing.  It works under WinXP home or Professional.

If you type XCOPY /? you will find that the standard XCOPY has a
similar feature, using the /D option.

I don't require an icon to simplify my home PC backups, so these
solutions are okay for me.

I don't backup the OS or applications for which I have install CD's.
Perhaps I am a bit of an optimist this way.  I do make fairly frequent
backups of data files that are important to me, and multiple copies of
them.  And periodically I burn them to CD's.

I've been following this discussion with interest, and there are some
other solutions I might like to try.

With kindest regards,

--
http://arnold.trembley.home.att.net/


In article <4a23e.861618$Xk.642366@pd7tw3no>,
James J. Gavan <jgavandeletethis@shaw.ca> wrote:
>docdwarf@panix.com wrote:

[snip]
 
>
>But surely Raid was invented to get rid of bugs ? Bzzzz........

I'm not sure why it was invented, Mr Gavan... but I seem to recall
something about Elliot Ness using it to get rid of bootleggers.

DD

In article <NO33e.29754$cg1.28994@bgtnsc04-news.ops.worldnet.att.net>,
Arnold Trembley  <arnold.trembley@worldnet.att.net> wrote:
>
>
>docdwarf@panix.com wrote: 
>
>We handle backups pretty much the same way we did in 1986.  This is an
>IBM mainframe application with CICS (now Transaction Server 2.x) and
>batch processing.  The CICS files are primarily VSAM, and to maintain
>24x7 availability we have two sets of files, primary and secondary.
>In our overnight maintenance window, CICS processing is switched to
>secondary files.  Primary files are then backed up, using standard
>utilities, IDCAMS and SyncSort, then purged, reloaded, and refreshed.

Thanks much, Mr Trenbley... by the bye, did you know that Mr Dilworth's
opinions on how this should be done differ?

[snip]

>When it comes to backing up my home PC, I'm a bit careless.

Those barefoot children of cobblers again, aye.

>I use ZIP
>disks for backup, and rarely use compression.

How interesting... I used to use a Jaz drive until the Click o' Death
began eating my disks... oddly enough, this happened right about the time
read/write CDs became cheap.  I would boot into DOS and use a utility
named HD95COPY for images to one disk and the WinZip method described
earlier for the incrementals.

[snip]

>For incremental backup, I use a .bat file I wrote:

Ahhhh, going back an even greater distance... when I worked in DOS I used
something similar, invoking Microsoft's BACKUP in my AUTOEXEC.BAT so that
once a day, when I turned the machine on (there was a file containing the
date it wrote to keep it to 'once') it would dump everything that had been
changed to my B: drive, a state-of-the-art 720K 3 1/2" floppy.

[snip]

>If you type XCOPY /? you will find that the standard XCOPY has a
>similar feature, using the /D option.

After backing up with HD95COPY I would use xcopy c:\*.* e: /s /m to turn
off the attribute bytes before rebooting Win95; I found it to be faster
than attrib.

[snip]

>I've been following this discussion with interest, and there are some
>other solutions I might like to try.

Every so often one needs to dust of The Basics and examine them, aye...
and this tenet is so Basic it needs neither dusting nor examining.

Thanks much.

DD

docdwarf@panix.com wrote:
> In article <NO33e.29754$cg1.28994@bgtnsc04-news.ops.worldnet.att.net>,
> Arnold Trembley  <arnold.trembley@worldnet.att.net> wrote:
> 
>
>
> Thanks much, Mr Trenbley... by the bye, did you know that Mr Dilworth's
> opinions on how this should be done differ?

Yes, I noticed that.  I'm sure he is satisfied with his approach, and
my shop is likewise comfortable with our backup procedures.  Isn't it
a wonderful world where there is a multitude of ways to do things?

> [snip] 
>
> How interesting... I used to use a Jaz drive until the Click o' Death
> began eating my disks... oddly enough, this happened right about the time
> read/write CDs became cheap.  I would boot into DOS and use a utility
> named HD95COPY for images to one disk and the WinZip method described
> earlier for the incrementals.

I have read about the click of death and Iomega drives, but I have yet
to encounter it.  I have two ZIP 250meg drives, but I tend to use only
the USB-powered one, switching it between my desktop and laptop as
needed.

I have not yet gotten around to trying out CD-RW's.  The CD-R's I burn
are permanent backups, and I find the ZIP disk backups seem to take
less time than burning a CD.

> [snip]
> After backing up with HD95COPY I would use xcopy c:\*.* e: /s /m to turn
> off the attribute bytes before rebooting Win95; I found it to be faster
> than attrib.

I have never found the "Archive" bit useful.  When I backup my files,
I like to make multiple copies.  If the archive bit is reset, I can't
make a second, third, or fourth copy of the same files.

> [snip]
>
> 
>
>
> Every so often one needs to dust of The Basics and examine them, aye...
> and this tenet is so Basic it needs neither dusting nor examining.
>
> Thanks much.
>
> DD

You're quite welcome.  And it was worth twice what you paid for it!

With kindest regards,

--
http://arnold.trembley.home.att.net/


In article <DLu3e.34057$cg1.6677@bgtnsc04-news.ops.worldnet.att.net>,
Arnold Trembley  <arnold.trembley@worldnet.att.net> wrote:
>
>
>docdwarf@panix.com wrote:

[snip]
 
>
>Yes, I noticed that.  I'm sure he is satisfied with his approach, and
>my shop is likewise comfortable with our backup procedures.  Isn't it
>a wonderful world where there is a multitude of ways to do things?

It has been said, Mr Trembley, that if one wants only agreement one should
speak only with one's mirror.

[snip]
 
>
>I have read about the click of death and Iomega drives, but I have yet
>to encounter it.  I have two ZIP 250meg drives, but I tend to use only
>the USB-powered one, switching it between my desktop and laptop as
>needed.

I had a Zip100 external (parallel) and a Jaz 1G internal... and after
about six or seven years of nigh-constant use they both went COD.  I
figured that was a sign for me to move on.

>
>I have not yet gotten around to trying out CD-RW's.  The CD-R's I burn
>are permanent backups, and I find the ZIP disk backups seem to take
>less time than burning a CD.

Time doesn't seem to be a major constraint under my present setup.  Wly
incrementals take about a half-hour to write and maybe twenty minutes to
verify, daily incrementals are a minute or three... but I don't have any
major development work on my PC or large databases to deal with.

> 
>
>I have never found the "Archive" bit useful.  When I backup my files,
>I like to make multiple copies.  If the archive bit is reset, I can't
>make a second, third, or fourth copy of the same files.

There we differ... once and away and that is it, for me.  When something
goes 'kerflooie' I just restore last w's system and the dailies.

[snip]
 
>
>You're quite welcome.  And it was worth twice what you paid for it!

Even more, two and a quarter... but sometimes one gets a Real Bargain.

DD

In article <d2i9t2$3o4$1@panix5.panix.com>, docdwarf@panix.com writes:
> In article <1112308317.534253.171720@z14g2000cwz.googlegroups.com>,
>  <foodman123@gmail.com> wrote: 
>
> Mr Dilworth, consider a situation of, say, an airlines reservation system
> and the number of files that are changed every time a reservation is
> confirmed or changed... thousands of people accessing thousands of records
> closer to simultaneously than one might wish to get.  Might not the kind
> of 'instantaneous backup' you advocate put sufficient drag on system
> resources so that response-time could degrade to the point of
> unacceptable?

Well, that's what mirroring is for, and I think it's reasonable to
include mirroring in the category of "backups".

However, I agree that Tony's dicta regarding backups fail to take
into account the wide range of data to be backed up, conditions under
which it is created, and conditions under which it is restored.

For example, only ever taking incremental backups (which is implied
by "not be backed up further if [it] is never changed") makes
restoration infeasible under many conditions (too many incrementals
to restore), and leaves you at the mercy of the integrity of the
original full backup.

Waiting until "final compilation" to back up source code is just
silly.  In my book, source should be regularly (eg daily and before
any major changes) checked into a change management system, and the
system's repository should be backed up daily.  With change
management there's no reason to tie backup to the state of the
source.

And so on.  There is no perfect backup regimen which serves all
purposes.

--
Michael Wojcik                  michael.wojcik@microfocus.com

Americans have five divantages which you should take into account
before giving us too hard a time:
- We're landlocked
- We're monolingual
- We have poor math and geography skills        -- Lucas MacBride

In article <d2mktt028g1@news2.newsguy.com>,
Michael Wojcik <mwojcik@newsguy.com> wrote:
>
>In article <d2i9t2$3o4$1@panix5.panix.com>, docdwarf@panix.com writes: 
>
>Well, that's what mirroring is for, and I think it's reasonable to
>include mirroring in the category of "backups".

I do not believe Mr Dilworth, in his emphasis on a COBOL application to do
the simultaneous backup, was considering mirroring, which I understand to
be more a matter of systems than applications... but my beliefs have been
proven wrong in the past, sure.

>
>However, I agree that Tony's dicta regarding backups fail to take
>into account the wide range of data to be backed up, conditions under
>which it is created, and conditions under which it is restored.
>
>For example, only ever taking incremental backups (which is implied
>by "not be backed up further if [it] is never changed") makes
>restoration infeasible under many conditions (too many incrementals
>to restore), and leaves you at the mercy of the integrity of the
>original full backup.

... hence the mantra of 'Incremental Daily, System Wly'.  At the very
least the system backup is verified against the source data.

[snip]

>And so on.  There is no perfect backup regimen which serves all
>purposes.

What... no 'one size fits all'?  I'm not sure Mr Dilworth agrees with
that... but I suppose he can speak for himself.

DD