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