Re: [foxboro] Automation of upload/checkpoint/save_all at sites with IACC, ICC, or IEE!!

  • From: "Fitzgerrell, Kevin" <Kevin_Fitzgerrell@xxxxxxx>
  • To: <foxboro@xxxxxxxxxxxxx>
  • Date: Fri, 31 Oct 2008 13:28:48 +0900

Tom,

We've got 3 P91s and 2 P82s now.  I'm far happier with the P82s than
with the P91s.  I'm tentatively planning on ordering 5 more of the P82s
while Foxboro can still sell them to me.  I see from the Sun site
they've EOL'd the workstation line and only sell servers now, so I'm
struggling a bit with the idea of buying new EOL'd workstations, but I
do like these.  It's a little sad that Foxboro's actually implemented
almost all of what I wanted in an AW just before they've told me I won't
be able to get them anymore.  

The Solaris guys look at the file structure and implementation and just
shake their heads at what's been done by Foxboro, but for me it works
well.  The P82s are a lot more secure out of the box than the older 51
series, but I've made ours work just like the older boxes for now.  

I'd like to know when Foxboro will be releasing the 8.4.x improvements
for Solaris 10 hosts.  That will have a big effect on whether I order
more boxes or not.  I like the Solaris boxes as boot hosts, but I also
like the CP improvements introduced in 8.4.  We've already shifted ATS
hosting to the P91s for the improvements under 8.4.

Solaris 10 pros:
All of the Solaris stuff still works
rmount still works
There is an agent for our standard MIS network backup solution
ICC works between Solaris hosts (including across the ATS & CBLAN)
Fast and responsive
Surprisingly little new to learn, as Foxboro has made very little (no?)
use of new features

Solaris 10 cons (mostly no surprises here):
Legacy historian went away
Legacy DM went away
Windows configurators can't be used
Sun has EOL'd the entire workstation line

I'm considering adding SunPCi cards to my P82s to let me put the windows
configurators on the Sun hosts.  I'd stopped doing that with my 51
series boxes a while ago after it got complicated to support EOL'd
hardware and software.  I could probably just install rdesktop and rdp
to my P91s though.

Regards,

Kevin




-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of tjvandew@xxxxxxxxx
Sent: Friday, October 31, 2008 12:24 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Automation of upload/checkpoint/save_all at sites
with IACC, ICC, or IEE!!

Kevin,
    Thanks for the info.  They have two P91 2003 Servers at the refinery

and I have used the remote desktop functionality.  It works okay.  Duc 
and I were discussing the possibilities of using SOTM CP boot hosts 
before I left Dow Corning.  How many P82's do you have?  Are you happy 
with them?
Kevin Fitzgerrell wrote:
> Tom,
>
> There are still a couple of options for keeping a central
> configuration machine in the MESH age, but it depends on your CP
> hosts.  We use (for now at least) P82 Solaris 10 workstations for our
> hosts and ICC seems to work just like it always did between them.  In
> our testbeds we use P91 Windows 2003 servers, and while you can't
> remote ICC between them, you can pull a remote RDP session for ICC.
>
> Regards,
>
> Kevin
>
> On 10/31/08, tjvandew@xxxxxxxxx <tjvandew@xxxxxxxxx> wrote:
>   
>> Terry,
>>     Using the checkpoint file as the master for all CP information IS
>>  the best idea.  There are utilities such as dbvu that already
extract
>>  data from the checkpoint file and they are lightening fast.  Alex
talked
>>  about Foxboro moving in that direction back before the Infusion
>>  development and it sounded like a good idea then.  When using IEE as
the
>>  configuration tool is there still a checkpoint file as we know it
>>  today?  I would think it would still have to exist.  If so, the
>>  checkpoint file should be a great and absolute source of all
information
>>  in the CP regardless of whether you are using IEE, IACC, or ICC.
>>  De-compiling the checkpoint file might be a bit complicated but it
seems
>>  like it would be money well spent by Foxboro and would provide users
>>  with more credible information in a much faster and more reliable
way.
>>  The relationship between the checkpoint and workfile has been a
source
>>  of confusion from day one and the workfile has become corrupted on
too
>>  many occasions.  Since the checkpoint creates a raw image dump of
what
>>  is running in the CP at the time the checkpoint is initiated it
contains
>>  all of the data needed and it is now quick enough to be invoked at
the
>>  beginning of a configuration session to insure the user is seeing
what
>>  is really running in the CP.
>>     Alex or Russ, what were the factors that facilitated the quantum
>>  reduction in the time it takes to checkpoint a 270 series CP?  Was
it
>>  just the 100mb/s bandwidth and switched Ethernet that the MESH
provides
>>  between the 270 CP's and the boot host where the checkpoint file is
>>  stored?  The increased processor power of the CP and/or boot host?
Or a
>>  change in the checkpoint communication data stream?  At any rate,
the
>>  270's checkpoint in seconds rather than minutes that the  nodebus
based
>>  CP's take.
>>     The silence on my last email asking questions about automating
>>  uploads in IACC was deafening.  I think that silence was a positive
>>  confirmation that there is no mechanism in place to allow it and it
>>  points out a glaring deficiency in IACC.
>>     This email proposes a possible solution to a problem that has
>>  plagued IA users from the beginning of IA time but it would be no
>>  surprise to me if it falls on deaf ears also.
>>     Before retiring from Dow Corning and working on the Tesoro Hawaii
>>  project I had no experience with IACC.  Although I am still not an
>>  expert on IACC I see little advantage to using IACC as a day-to-day
>>  configuration tool.  All of the people I have seen use it are still
>>  using ICC driver tasks functions, (iccprt), to provide the bulk of
data
>>  they need to do their jobs.  There are a lot better tools that users
>>  have developed with individually developed applications than what
IACC
>>  provides.  I can understand that it provides people developing the
>>  software applications from a remote location a better tool to create
>>  loop templates and standards but IACC actually gets in the way down
at
>>  the day-to-day use level IMHO.  But IACC is the only mechanism on a
>>  multi-boot-host MESH network that allows for a centrally located
>>  configuration workstation.  If you use ICC on the MESH you have to
be in
>>  a direct session with the CP boot host.  That was a large step
backward
>>  from the UNIX based use of ICC that allowed configuration of any CP
from
>>  any workstation on the nodebus/carrierband network.
>>
>>  Cheers,
>>  Tom VandeWater
>>  Control Conversions Inc.
>>  Kapolei, HI
>>
>>
>>
_______________________________________________________________________
>>  This mailing list is neither sponsored nor endorsed by Invensys
Process
>>  Systems (formerly The Foxboro Company). Use the info you obtain here
at
>>  your own risks. Read
http://www.thecassandraproject.org/disclaimer.html
>>
>>  foxboro mailing list:
//www.freelists.org/list/foxboro
>>  to subscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
>>  to unsubscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>>
>>
>>     
>  
>  
>
_______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys
Process
> Systems (formerly The Foxboro Company). Use the info you obtain here
at
> your own risks. Read
http://www.thecassandraproject.org/disclaimer.html
>  
> foxboro mailing list:
//www.freelists.org/list/foxboro
> to subscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>  
>
>   


 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             //www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
 
 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             //www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
 

Other related posts: