said:
>
>>... just do the same as now but use PARMS for standard settings
i.e.
>>Drives, Souces & Target !
The PARMS, for me, are somewhat like I control file.
I do enter once my system environment and the script
fullfills the task with these preset PARMS with some
possibility of overriding !!
>That's one option. Some sort of control file would be better.
Your
>environment variable method could work, but is somewhat clumsy.
The
>reason for a control file rather than command line arguments is
that a
>long command lines are hard to read and hard to maintain and the
command
>line is easy to overflow. That said, just defining the defaults
at the
>start of the script along with instructions how to edit the site
specific
>values would work too.
My environment variable method is not clumsy ...
... Harry's script, with all my drives added to it, displayed
over 1 1/2
screen pages ;-(
This was my first change and I brought it down to 9 lines ;-)
My suggested solution only needs ONE line ONLY !
I do not need the long description of "C" for "c" for "1": Just
"C" is enough !
The script shall handle small and capital letter the same and
"1", for me,
has no meaning to drive C:
The script perhaps also could re-display my last time entries ...
... to easien my work because if I only do my daily data backup
...
... it's each day the same !!
>I would expect the backup settings to change slowly over time,
so an
>easily edited control file seems to be a good solution.
I agree.
If necessary I just change the PARMS to my newest needs ;-)
>>sensitive part of the script but I must adjust environment
>>settings accordingly to my system and my needs once and only
>>if my system environments changes ;-)
>
>Harry could have made the script somewhat more generic by using:
>
> SysDriveMap('C:", 'L')
>
>to locate the drives and by using a stem to store the backup
settings for
>each drive.
>
>>The rest of your script works like now ;-)
OK, I cannot qualify !
I can bring ideas and input for Working Methods or Organization
but
programming has never been my power ;-(
I can read and understand the program code and do some
adjustments
in how to use it.
>Another thing I would attempt to do is automate the avaiable
size logic
>somewhat. This could be done by reading the log for the
previous backup
>and extracting the uncompressed sizes. This can be used to
calculate an
>average compression ratio. This along with the remaining space
in the
>container and the backup size from SysDriveInfo() should be a
pretty good
>estimator.
Size logic control isn't that important for me now !
I do have one single very important file in the size of 600MB ...
... so I am far from the critical 2.1GB but all my data collected
into a
DAT file may exceed this critical size again !?
However, this discussion of Backup and this REXX solution with
you, SCOUG
members, has brought me a lot of new ideas, impressions:
Thank you, guys ! It's very interesting to discuss with you ;-))
Now, let's be patient and wait for Harry's new script !
Have a nice Sunday evening,
svobi
steve53@earthlink.net on 04.08.2002 18.49.43
Please respond to scoug-help@scoug.com
To: scoug-help@scoug.com
cc:
Subject: SCOUG-Help: Re: Your REXX script ...
In <1028498966-0-Info@SYNass.NET>, on 08/04/02
at 08:09 AM, "Info2SYNass.NET" said:
>... just do the same as now but use PARMS for standard settings
i.e.
>Drives, Souces & Target !
That's one option. Some sort of control file would be better.
Your
environment variable method could work, but is somewhat clumsy.
The
reason for a control file rather than command line arguments is
that a
long command lines are hard to read and hard to maintain and the
command
line is easy to overflow. That said, just defining the defaults
at the
start of the script along with instructions how to edit the site
specific
values would work too.
I would expect the backup settings to change slowly over time, so
an
easily edited control file seems to be a good solution.
>sensitive part of the script but I must adjust environment
>settings accordingly
>to my system and my needs once and only if my system
environments changes
>;-)
Harry could have made the script somewhat more generic by using:
SysDriveMap('C:", 'L')
to locate the drives and by using a stem to store the backup
settings for
each drive.
>The rest of your script works like now ;-)
Another thing I would attempt to do is automate the avaiable size
logic
somewhat. This could be done by reading the log for the previous
backup
and extracting the uncompressed sizes. This can be used to
calculate an
average compression ratio. This along with the remaining space
in the
container and the backup size from SysDriveInfo() should be a
pretty good
estimator.
Steven
************************************************************
*** >>> 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".
=====================================================
<< Previous Message <<
>> Next Message >>
Return to [ 04 |
August |
2002 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
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.
