[tickets] [opensaf:tickets] #232 MDS/TCP should be the default once TIPC management is moved out
- **status**: fixed -- unassigned --- ** [tickets:#232] MDS/TCP should be the default once TIPC management is moved out** **Status:** unassigned **Created:** Wed May 15, 2013 11:10 AM UTC by Mathi Naickan **Last Updated:** Fri Oct 18, 2013 03:11 AM UTC **Owner:** A V Mahesh (AVM) Changed 10 months ago by mahesh owner changed from murthy to mahesh Hans , following are my thoughts to make TCP as the default transport please provide your inputs. Option 1 : Binaries built with both TIPC and TCP footprint ./configure builds the opensaf rpms where the binaries have support for both TCP or TIPC binaries.But, the default configuration will be generated for TCP. For TIPC transport the nid_tipc will be provided as a sample file. If wishes to run with TIPC transport need to do the necessary configuration changes. configuration in nid.conf change the nodeinit.conf if he wishes to use the nid_tipc sample script by adding and entry to the nodeinit.conf file and comment out the entry related to TCP. OR change the soft link of nodeinit.conf form nodeinit.conf.controller to nodeinit.conf.controller.tipc if ok to go with new nodeinit.conf.controller.tipc configuration file ? follow-up: ↓ 4 Changed 10 months ago by hafe Here's what I think: In #2512 I say that opensaf should provide under samples (for example) a tipc init script for those who wish to use tipc. The old nid_tipc script should be removed (or renamed since it contains the mds log rotation) nodeinit.conf should contain a single osaf-mds entry that in the MDS/TCP case calls osaf-dtm start and then does mds log monitoring. In the MDS/TIPC case it just skips the osaf-dtm start call. Then there is an end to the sed-ding of nodeinit.conf from the opensafd start script (which is crazy...). I have mentioned this before. The sed has been the source for problems. Then dh_monitoring should be renamed osaf-dh-monitor so that all daemons in the system uses the osaf prefix. in reply to: ↑ 3 Changed 9 months ago by mathi Replying to hafe: Here's what I think: In #2512 I say that opensaf should provide under samples (for example) a tipc init script for those who wish to use tipc. The old nid_tipc script should be removed (or renamed since it contains the mds log rotation) nodeinit.conf should contain a single osaf-mds entry that in the MDS/TCP case calls osaf-dtm start and then does mds log monitoring. In the MDS/TIPC case it just skips the osaf-dtm start call. Then there is an end to the sed-ding of nodeinit.conf from the opensafd start script (which is crazy...). I have mentioned this before. The sed has been the source for problems. Then dh_monitoring should be renamed osaf-dh-monitor so that all daemons in the system uses the osaf prefix. w.r.t moving the nid_tipc into the samples area, actually we dont have to that. i.e. As suggestged here, when a single/common script is used in the nodeinit.conf, lets call it as 'osaf-transport' (not really 'osaf-mds' because its not entirely mds that's getting started here), then this script can inturn invoke the startup of tcp(default) or tipc accordingly based on what the user configured in the nid.conf Changed 6 months ago by mahesh patch_waiting changed from no to yes Changed 3 months ago by hafe milestone changed from 4.3.GA to future_releases TLC decision/preparation for 4.3 release Changed 7 weeks ago by mathi milestone changed from future_releases to 4.4.GA Changed 5 weeks ago by hafe Some quality issues that should be fixed before making MDS/TCP the default http://devel.opensaf.org/ticket/3113 http://devel.opensaf.org/ticket/2707 http://devel.opensaf.org/ticket/3097 3097 could be due to one of the valgrind reported errors in 3113 --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #618 osaf-transport-monitor loops on systems where sh is not bash
- **status**: unassigned -- invalid
---
** [tickets:#618] osaf-transport-monitor loops on systems where sh is not bash**
**Status:** invalid
**Created:** Wed Nov 06, 2013 03:55 PM UTC by Hans Feldt
**Last Updated:** Wed Nov 06, 2013 04:20 PM UTC
**Owner:** nobody
and creates a lot of CPU load
system: ubuntu 13.10 (/bin/sh is dash)
If the script shebang is changed to bash it works
checkbashisms shows this:
$ checkbashisms
opensaf-staging/osaf/services/infrastructure/dtms/scripts/osaf-transport-monitor
possible bashism in
opensaf-repos/opensaf-staging/osaf/services/infrastructure/dtms/scripts/osaf-transport-monitor
line 47 ('((' should be '$(('):
while ((COUNT 15))
possible bashism in
opensaf-repos/opensaf-staging/osaf/services/infrastructure/dtms/scripts/osaf-transport-monitor
line 57 ('((' should be '$(('):
((COUNT=COUNT+1))
---
Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #618 osaf-transport-monitor loops on systems where sh is not bash
This problem should be handled by
https://sourceforge.net/p/opensaf/tickets/232/ where the problems were
introduced since #232 has not yet been released.
---
** [tickets:#618] osaf-transport-monitor loops on systems where sh is not bash**
**Status:** invalid
**Created:** Wed Nov 06, 2013 03:55 PM UTC by Hans Feldt
**Last Updated:** Wed Nov 06, 2013 04:20 PM UTC
**Owner:** nobody
and creates a lot of CPU load
system: ubuntu 13.10 (/bin/sh is dash)
If the script shebang is changed to bash it works
checkbashisms shows this:
$ checkbashisms
opensaf-staging/osaf/services/infrastructure/dtms/scripts/osaf-transport-monitor
possible bashism in
opensaf-repos/opensaf-staging/osaf/services/infrastructure/dtms/scripts/osaf-transport-monitor
line 47 ('((' should be '$(('):
while ((COUNT 15))
possible bashism in
opensaf-repos/opensaf-staging/osaf/services/infrastructure/dtms/scripts/osaf-transport-monitor
line 57 ('((' should be '$(('):
((COUNT=COUNT+1))
---
Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #621 Cluster startup timer does not stop when the cluster is up but the SUs are in locked instantiation state
--- ** [tickets:#621] Cluster startup timer does not stop when the cluster is up but the SUs are in locked instantiation state** **Status:** unassigned **Created:** Tue Nov 12, 2013 09:39 AM UTC by Sirisha Alla **Last Updated:** Tue Nov 12, 2013 09:39 AM UTC **Owner:** nobody The issue is seen on change set 4585 on SLES 4nodes. The cluster is configured to have 2 nodes SC-1 and SC-2: Application is configured in 2N redundancy model with a spare SU. The cluster startup timer is configured to be 60 seconds. SU1 is hosted on SC-1 and SU2 and SU3 on SC-2. SU1 is in unlocked admin state while SU2 and SU3 are in locked-instantiation state. SC-1 and SC-2 are brought up. The cluster has come up. But there are no assignments to SU1 till the cluster startup timer expiry. Following is the syslog on SC-1: Nov 12 14:51:49 SLES-64BIT-SLOT1 osafamfnd[2041]: NO Assigned 'safSi=SC-2N,safApp=OpenSAF' ACTIVE to 'safSu=SC-1,safSg=2N,safApp=OpenSAF' Nov 12 14:51:49 SLES-64BIT-SLOT1 opensafd: OpenSAF(4.4.M0) services successfully started Nov 12 14:51:49 SLES-64BIT-SLOT1 osafamfnd[2041]: NO 'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo' Presence State UNINSTANTIATED = INSTANTIATING some thing is spawnd instantiate for safComp=AmfDemo1,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo some thing is spawnd instantiate for safComp=AmfDemo2,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo Nov 12 14:51:49 SLES-64BIT-SLOT1 osafamfnd[2041]: NO 'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo' Presence State INSTANTIATING = INSTANTIATED Nov 12 14:51:54 SLES-64BIT-SLOT1 kernel: [96492.575243] TIPC: Established link 1.1.1:eth0-1.1.2:eth1 on network plane A Nov 12 14:51:54 SLES-64BIT-SLOT1 osafimmd[1963]: NO New IMMND process is on STANDBY Controller at 2020f Nov 12 14:51:54 SLES-64BIT-SLOT1 osafimmd[1963]: WA IMMND on controller (not currently coord) requests sync Nov 12 14:51:54 SLES-64BIT-SLOT1 osafimmd[1963]: NO Node 2020f request sync sync-pid:17853 epoch:0 Nov 12 14:51:55 SLES-64BIT-SLOT1 osafimmnd[1973]: NO Announce sync, epoch:3 Nov 12 14:51:55 SLES-64BIT-SLOT1 osafimmnd[1973]: NO SERVER STATE: IMM_SERVER_READY -- IMM_SERVER_SYNC_SERVER Nov 12 14:51:55 SLES-64BIT-SLOT1 osafimmnd[1973]: NO NODE STATE- IMM_NODE_R_AVAILABLE Nov 12 14:51:55 SLES-64BIT-SLOT1 osafimmd[1963]: NO Successfully announced sync. New ruling epoch:3 Nov 12 14:51:55 SLES-64BIT-SLOT1 osafimmloadd: NO Sync starting Nov 12 14:51:56 SLES-64BIT-SLOT1 osafimmloadd: IN Synced 341 objects in total Nov 12 14:51:56 SLES-64BIT-SLOT1 osafimmnd[1973]: NO NODE STATE- IMM_NODE_FULLY_AVAILABLE 13809 Nov 12 14:51:56 SLES-64BIT-SLOT1 osafimmloadd: NO Sync ending normally Nov 12 14:51:56 SLES-64BIT-SLOT1 osafimmnd[1973]: NO Epoch set to 3 in ImmModel Nov 12 14:51:56 SLES-64BIT-SLOT1 osafimmd[1963]: NO ACT: New Epoch for IMMND process at node 2010f old epoch: 2 new epoch:3 Nov 12 14:51:56 SLES-64BIT-SLOT1 osafimmd[1963]: NO ACT: New Epoch for IMMND process at node 2020f old epoch: 0 new epoch:3 Nov 12 14:51:56 SLES-64BIT-SLOT1 osafimmnd[1973]: NO Implementer (applier) connected: 11 (@safLogService) 0, 2020f Nov 12 14:51:56 SLES-64BIT-SLOT1 osafimmnd[1973]: NO SERVER STATE: IMM_SERVER_SYNC_SERVER -- IMM SERVER READY Nov 12 14:51:56 SLES-64BIT-SLOT1 osafimmnd[1973]: NO Implementer (applier) connected: 12 (@safAmfService2020f) 0, 2020f Nov 12 14:51:56 SLES-64BIT-SLOT1 osafamfd[2031]: NO Node 'SC-2' joined the cluster Nov 12 14:51:57 SLES-64BIT-SLOT1 osafimmnd[1973]: NO Implementer (applier) connected: 13 (@OpenSafImmReplicatorB) 0, 2020f Nov 12 14:51:57 SLES-64BIT-SLOT1 osafimmnd[1973]: NO Implementer connected: 14 (MsgQueueService131599) 0, 2020f Nov 12 14:52:49 SLES-64BIT-SLOT1 osafamfnd[2041]: NO Assigning 'safSi=AmfDemo,safApp=AmfDemo' ACTIVE to 'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo' Nov 12 14:52:49 SLES-64BIT-SLOT1 osafamfnd[2041]: NO Assigned 'safSi=AmfDemo,safApp=AmfDemo' ACTIVE to 'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo' The same configuration with single node cluster(SU1 in unlocked and SU2 and SU3 in locked-instantiation) works (the timer is stopped and the assignments are given as soon as SC-1 is up). But if all the SUs in the single node cluster are in locked instantiation, the timer is being started (inferred from the behavior of #620). This issues is reproducible. --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and
[tickets] [opensaf:tickets] #21 IMM: Allow imm-pbe to be configured without shared file system
changeset: 4598:86a1412290d6 user:Anders Bjornerstedt anders.bjornerst...@ericsson.com date:Mon Nov 11 09:38:04 2013 +0100 summary: IMM: 2PBE patch-1 (loading) [#21] changeset: 4599:7456dbbe4c08 user:Anders Bjornerstedt anders.bjornerst...@ericsson.com date:Fri Oct 11 01:17:44 2013 +0200 summary: IMM: 2PBE patch-2 (dumping) [#21] changeset: 4600:9ee3f2fdcd8b user:Anders Bjornerstedt anders.bjornerst...@ericsson.com date:Tue Nov 12 09:06:14 2013 +0100 summary: IMM: 2PBE patch-3 (1safe2pbe) [#21] changeset: 4601:83b28c39b919 user:Anders Bjornerstedt anders.bjornerst...@ericsson.com date:Tue Nov 12 09:10:31 2013 +0100 summary: IMM: 2PBE patch-4 (Fix for si-swap problem) [#21] changeset: 4602:7a716f3877a0 user:Anders Bjornerstedt anders.bjornerst...@ericsson.com date:Tue Nov 05 16:52:49 2013 +0100 summary: IMM: 2PBE patch-5 (Fix loading retry problem) [#21] changeset: 4603:6a7be900da64 user:Anders Bjornerstedt anders.bjornerst...@ericsson.com date:Tue Nov 05 17:00:20 2013 +0100 summary: IMM: 2PBE patch-6 (PBE slave can re-attach when empty CCBs exist) [#21] changeset: 4604:f244cfef05b0 user:Anders Bjornerstedt anders.bjornerst...@ericsson.com date:Tue Nov 12 09:17:11 2013 +0100 summary: IMM: 2PBE patch-7 (Fix two problems in immloader) [#21] changeset: 4605:e281ca91c7c9 tag: tip user:Anders Bjornerstedt anders.bjornerst...@ericsson.com date:Tue Nov 12 13:46:02 2013 +0100 summary: IMM: 2PBE patch-8 (Adjust immoitest 5 4) [#21] --- ** [tickets:#21] IMM: Allow imm-pbe to be configured without shared file system** **Status:** fixed **Created:** Tue May 07, 2013 08:50 AM UTC by Anders Bjornerstedt **Last Updated:** Tue Nov 05, 2013 04:30 PM UTC **Owner:** Anders Bjornerstedt The current implementation of immsv with pbe-enabled requires the pbe file (imm.db) to reside on a shared file system. This enhancement proposes to make it possible to configure imm-pbe so that it does not depend on a shared file system. Redundancy is of course still required for the imm-pbe file and the solution is to have the immsv take care of maintaining the replication and syncing of the imm.db file itself, instead of relying on the file system level (e.g. drbd) to take care of this. Note that if OpenSAF is built without pbe enabled, then immsv is already not directly dependent on any shared file-system. In that case, the responsiblity for taking backups and securing redundancy for backups, falls outside of immsv. So it should already possible to deploy OpenSAF without having any filsystem that is shared between SC's, at least from the perspective of the immsv. The reason for this enhancement is to allow more flexibility in deployment and more control (ease of troubleshooting) the lower layers of the immsv. The reason is not primarily enhanced performance. Performance may be better during circumstances where currently the shared file-system is heavily loaded or is syncing. One example is rolling upgrades that need to reboot the SC's. They will typically cause the shared file-system to go out of sync two times, in opposite directions in a relatively short time period. More details about this enhancement will be presented later. Migrated from: http://devel.opensaf.org/ticket/2466 --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #622 IMM: Update the README file to document 2PBE
--- ** [tickets:#622] IMM: Update the README file to document 2PBE** **Status:** accepted **Created:** Tue Nov 12, 2013 01:07 PM UTC by Anders Bjornerstedt **Last Updated:** Tue Nov 12, 2013 01:07 PM UTC **Owner:** Anders Bjornerstedt --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #622 IMM: Update the README file to document 2PBE
Related to (#21) --- ** [tickets:#622] IMM: Update the README file to document 2PBE** **Status:** accepted **Created:** Tue Nov 12, 2013 01:07 PM UTC by Anders Bjornerstedt **Last Updated:** Tue Nov 12, 2013 01:07 PM UTC **Owner:** Anders Bjornerstedt --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #623 IMM: Disable PBE can result in an unclean cutoff for PRTO-create or PRTA-update.
--- ** [tickets:#623] IMM: Disable PBE can result in an unclean cutoff for PRTO-create or PRTA-update.** **Status:** assigned **Created:** Tue Nov 12, 2013 01:24 PM UTC by Anders Bjornerstedt **Last Updated:** Tue Nov 12, 2013 01:24 PM UTC **Owner:** Anders Bjornerstedt Disable PBE can result in an unclean cutoff for either PRTO create or PRTA update. That is, the disable of PBE may result in the two PBEs being terminated such that one has the PRT transaction committed but the other PBE has not. Of course, any reload attempted using such a PBE state will only bounce when reading the PBE files, since both PBE files are marked with PBE being disabled. Thus this issue is more academic than practical. But it does complicate 2PBE testing if that testing relies on regularly stopping PBE (disabling it) and comparing the files for being identical. Doing such comparisons on the fly, for example by copying both files while PBE is enabled does not work well, since it requires stopping all application traffic generating persistent writes. --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #624 IMM: Many immomtest cases fail incorrectly if 2PBE is enabled.
--- ** [tickets:#624] IMM: Many immomtest cases fail incorrectly if 2PBE is enabled.** **Status:** assigned **Created:** Tue Nov 12, 2013 01:48 PM UTC by Anders Bjornerstedt **Last Updated:** Tue Nov 12, 2013 01:48 PM UTC **Owner:** Zoran Milinkovic Most testcases for immomtest fail executed on a system with 2PBE enabled. The reason is that immomtest heavily depends on the OpenSAF IMM service object: opensafImm=opensafImm,safApp=safImmService 2PBE sets admin-owner for this object to 'safImmService', which seems to conflict with some tests that attempt to set the admin-woner to a test value. In addition, 2PBE creates two runtime objects as children to this object. This seems to trip up tests that use a scope of SA_IMM_SUBTREE for some operatin and expects to hit just one object. The second problem could possibly be fixed by changing scope to SA_IMM_ONE, but more fundamentally it is wrong that these tests rely on and operate on official imm service objects. The tests should only operate on test objects set up by these tests. This to insulate them from changes in the implementation of the imm service. --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
