Stan,
I use a script to do the checkpoint/upload periodically, but I usually run
it myself rather than as an unattended scheduled task because of the time it
takes (4-5 hours) and the resource usage during the upload and checkpoint.
I like to ensure nothing unusual is going on with either our stations or the
AW so the higher CPU usage and lower station idle time will not be an issue.
I use Angel Corbera's "updatecp" script at:
http://www.geocities.com/SiliconValley/Peaks/5825/scripts5.htm
I have a couple PID and Ratio blocks where I set the SPT parameter to a
specific value for block initialization to that setpoint.  During the
upload, these values get written over with the actual setpoint.  I have
added a few OMSETs to the script to reset these few values after the uploads
are complete.
Regards,
Kevin FitzGerrell
Fairbanks Gold Mining, Inc.

----- Original Message -----
From: Stan Brown <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, April 04, 2000 8:03 PM
Subject: Re: New script file: save_all.sh


> On Tue Apr  4 20:10:24 2000 Kevin Fitzgerrell wrote...
> >
> >Stan,
> >I'm running 4.3 on an AW51B.  I changed the SA_EXEC="save_all.sh" reference
> >to "save_all" and didn't have any problem running the script.  All stations
> >saved correctly.  All of my stations are hosted on the box I ran the shell
> >with, so I didn't test the part of the script that does the save-alls over
> >a remote connection.
> >
> Works great given:
>
> 1. A complete download :-(
> 2. removing the .sh from the inferior script name.
>
> BTW it works fine on an ap, where the CP's are hosted off of another AP.
>
> Duc has one that does an upload/shrink.checkpoint before doing the saveall.
> I am thinking of merging these functions into this one, because I like
> retaining multiple copies.
>
> Any comments as to the pros & cons of adding this functionaility?
>
> And thnaks for the reply.
>
>
> --
> Stan Brown     [EMAIL PROTECTED]
843-745-3154
> Westvaco
> Charleston SC.
> --
> Windows 98: n.
> useless extension to a minor patch release for 32-bit extensions and
> a graphical shell for a 16-bit patch to an 8-bit operating system
> originally coded for a 4-bit microprocessor, written by a 2-bit
> company that can't stand for 1 bit of competition.
> -
> (c) 2000 Stan Brown.  Redistribution via the Microsoft Network is
prohibited.


-----------------------------------------------------------------------
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

Reply via email to