SCOUG-HELP Mailing List Archives

>> Next Message >>

Date:	Sun, 20 Oct 2002 01:25:59 PST7
From:	"Info2SYNass.NET" <Info@SYNass.NET >
Reply-To:	scoug-help@scoug.com
To:	scoug-help@scoug.com
Subject:	SCOUG-Help: XCOPY failures (was: Using Infozip to backup)

Content Type: text/plain

=====================================================
If you are responding to someone asking for help who
may not be a member of this list, be sure to use the
REPLY TO ALL feature of your email program.
=====================================================

Hi Peter
you seem to be up very early ...
... or are you still up soo late ;-)

Your answer is very interesting and I may learn something from
you ;-))
I am quoting into your text below:

pskye@peterskye.com on 20.10.2002 08.07.13
Please respond to scoug-help@scoug.com
To: scoug-help@scoug.com
cc:
Subject: SCOUG-Help: XCOPY failures (was: Using Infozip to backup)

>Info2SYNass.NET wrote:
>>
>> Aren't you starting from floppy or Maintenenace Partition for
>> your XCOPY ?
>
>No. I'm running a backup. I don't boot to my maintenance
partition
>when I run backups.

OK, agreed. I also do not do that ;-)
I only wonder about you backup with XCOPY !?
I am using Sytos Premium as my Backup SW and I also having
BA/2000
as a possible successor if Sytos starts to fail.
With BA I am also experimenting with HCM's REXX scripts ;-))

>> Why is this database helpfile not accessable [by XCOPY] ???
>> Is the system and the DB application running ??
>
>Heck if I know. The files which XCOPY won't copy are probably
"locked"
>by the applications which are using them. A program can be
written so
>that it will open and read locked files but I forget how to do
it.
>
>> I do start my system from the Maintenance System (D:) and
>> do an "hotserved" XCOPY from my primary C: partition
>
>My systems are 24x7 and rebooting to the maintenance partition
would
>require that I shut down all the programs that are running.
Thus, I run
>my backups while the system is hot.

OPS, yeah I forgot that your systems are running 24x7 and I
remember that with HCM's REXX script we were discussing that
you could gain from a much shorter backup time also doing so !?

I also know from my old experiences in the past that we needed
to stop the DB system (IBM IMS) for the time of its backup !!
For this time there was no online access to the DB system.
During backup time accesses were queued.
When the backup was done the DB system was released again and
the queued and further transaction were served normally again.

>> If a file is not accessable means the application is running !
>
>Not necessarily.
>
>The programmer decides whether the file should be locked or not.
>Programs A and B can be written to access a file but not lock
it, and
>program C can be written to open a file and lock it, and you can
then
>run programs A and B together but you can't run A, B and then C
(you get
>a "can't lock the file" error) and you can't run C and then A or
B (you
>get a "file not accessible" error).
>
>
>To prove this, open a text file with E.EXE and then open the
*same* file
>with EPM.EXE. Since neither program locks the file, both can
have the
>file open at the same time.
>
>
>You can also lock just a portion of a file, though I can't
remember how
>OS/2 supports this (or maybe it's a function of DB2, I'm getting
so
>confused by the constant time zone change between Los Angeles
and San
>Diego).

I am not an expert in programming but believe and understand your
explantation and of course your sample with the *same* file ;-)

>> I am still unable to agree with you !?
>> Could you explain better how and what you are doing, please ?
>
>Sure. I'm doing a backup by making an exact copy (a "mirror")
of each
>of my partitions. No compression, just a straight copy. And I
*only*
>copy files which have changed, and I delete files from the
backup which
>are no longer on the original partitions.

OK !

>XCOPY doesn't delete files which no longer exist on the original
>partitions. Thus, if I have a file named MessageToSvobi.txt and
I back
>it up with XCOPY, and then some day I rename it to
MessageToSvobi-1.txt
>because I send you a second message (MessageToSvobi-2.txt),
after I run
>XCOPY there will be both MessageToSvobi.txt *and*
MessageToSvobi-1.txt
>-- XCOPY won't delete the file from the "mirror" copy. But
mirroring
>programs such as dSync will do this.

OK, XCOPY is copying only of course ...
... where dSync seem to be like replication !?
Interesting !

>Also, XCOPY copies *everything* even if it hasn't changed,
>a big time-waster.

Yes, this is true.

>As for agreeing or disagreeing with me, try XCOPYing the example
file I
>gave in my earlier message. It doesn't work here and I suspect
it won't
>work on your machine either (unless you boot to your maintenance
>partition, of course).

Remembering that your systems are running 24x7 gives
me a quite different picture of your situation.
Your mirroring or "replication" (!?) seem do be
well done with dSync !
I will have to learn about !!

>> Have a nice Sunday
>
>I'll be dreaming of the balmy sun-soaked beaches of outer
Mongolia,
>where no one has ever heard of San Diego.

WOW, sounds like you found your corner in the paradise ;-)
Is there still a little free corner if I retire and migrate
my old bones to your balmy sun-soaked Pacific Coast ??

Here near Zurich the weather is cool-grey-cloudy ;-((
I would love much more your picture book weather condition ;-))

Regards, svobi

************************************************************
*** >>> Say NO to HTML in Mail and News <<< ***
*** ++++++++++++++++++++++++++++++++++++++++++++++++ ***
*** >>> AGAINST TERROR +++ AGAINST WAR <<< ***
************************************************************

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-help".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 20 | October | 2002 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.