August 2014 - Asg - mailman3.cels.anl.gov

branch, master, updated. v0.2-35-g356b684
by noreply＠mcs.anl.gov 14 Aug '14

14 Aug '14

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "". The branch, master has been updated via 356b68445bfb126a5623d8e9a08257c23e468df0 (commit) from 2271bb0e3b6392cbc5eecae6ad6d04e2aeeaedd0 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 356b68445bfb126a5623d8e9a08257c23e468df0 Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Aug 14 14:18:06 2014 -0400 aefile_syncfs and autoconf check ----------------------------------------------------------------------- Summary of changes: configure.ac | 15 +++++++++++++++ src/aefile/aefile.ae | 22 ++++++++++++++++++++++ 2 files changed, 37 insertions(+), 0 deletions(-) Diff of changes: diff --git a/configure.ac b/configure.ac index c4323f0..fda19cc 100644 --- a/configure.ac +++ b/configure.ac @@ -338,6 +338,21 @@ AC_COMPILE_IFELSE( AC_SUBST(BLOCKSOPT) +AC_MSG_CHECKING(for syncfs) +AC_TRY_LINK( + [#define _GNU_SOURCE + #include <unistd.h> + ], + [ + syncfs(0); + ], + AC_MSG_RESULT(yes) + AC_DEFINE(HAVE_SYNCFS, 1, Define if syncfs function is present) + , + AC_MSG_RESULT(no) +) + + AC_MSG_CHECKING(for fallocate) AC_TRY_LINK( [#define _GNU_SOURCE diff --git a/src/aefile/aefile.ae b/src/aefile/aefile.ae index bbfa173..9fae74a 100644 --- a/src/aefile/aefile.ae +++ b/src/aefile/aefile.ae @@ -241,6 +241,28 @@ __blocking int aefile_fallocate(int fd, int mode, off_t offset, off_t len) return(ret); } +__blocking int aefile_syncfs(int fd) +{ + int ret = 0; + + AETHREAD_RUN(); + +#ifdef HAVE_SYNCFS + ret = syncfs(fd); +#else + /* fall back is to sync everything */ + sync(); + ret = 0; +#endif + if(ret < 0) + { + ret = -errno; + } + + return(ret); +} + + /* hooks/post-receive --

1 0

branch, master, updated. v0.2-34-g2271bb0
by noreply＠mcs.anl.gov 13 Aug '14

13 Aug '14

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "". The branch, master has been updated via 2271bb0e3b6392cbc5eecae6ad6d04e2aeeaedd0 (commit) from 4a7b3e12a823ca8494775ba9b2c5ff3c086c2385 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 2271bb0e3b6392cbc5eecae6ad6d04e2aeeaedd0 Author: Phil Carns <carns(a)mcs.anl.gov> Date: Wed Aug 13 16:48:18 2014 -0400 add fallocate wrapper (and conf test) to aefile ----------------------------------------------------------------------- Summary of changes: configure.ac | 14 ++++++++++++++ src/aefile/aefile.ae | 17 +++++++++++++++++ src/aefile/aefile.hae | 1 + 3 files changed, 32 insertions(+), 0 deletions(-) Diff of changes: diff --git a/configure.ac b/configure.ac index 91d08a8..c4323f0 100644 --- a/configure.ac +++ b/configure.ac @@ -338,6 +338,20 @@ AC_COMPILE_IFELSE( AC_SUBST(BLOCKSOPT) +AC_MSG_CHECKING(for fallocate) +AC_TRY_LINK( + [#define _GNU_SOURCE + #include <fcntl.h> + ], + [ + fallocate(0, 0, 0, 0); + ], + AC_MSG_RESULT(yes) + AC_DEFINE(HAVE_FALLOCATE, 1, Define if fallocate function is present) + , + AC_MSG_RESULT(no) +) + # these are cflags that will be automatically applied by aecc AECC_CFLAGS=$LIBCFLAGS AC_SUBST(AECC_CFLAGS) diff --git a/src/aefile/aefile.ae b/src/aefile/aefile.ae index 7ad4465..bbfa173 100644 --- a/src/aefile/aefile.ae +++ b/src/aefile/aefile.ae @@ -223,6 +223,23 @@ __blocking int aefile_unlink(const char *pathname) return(ret); } +__blocking int aefile_fallocate(int fd, int mode, off_t offset, off_t len) +{ + int ret = 0; + + /* noop if fallocate is not available */ +#ifdef HAVE_FALLOCATE + AETHREAD_RUN(); + + ret = fallocate(fd, mode, offset, len); + if(ret < 0) + { + ret = -errno; + } +#endif + + return(ret); +} diff --git a/src/aefile/aefile.hae b/src/aefile/aefile.hae index 900bd1c..e647d86 100644 --- a/src/aefile/aefile.hae +++ b/src/aefile/aefile.hae @@ -25,6 +25,7 @@ __blocking int aefile_fsync(int fd); __blocking int aefile_fdatasync(int fd); __blocking int aefile_ftruncate(int fd, off_t length); __blocking int aefile_unlink(const char *pathname); +__blocking int aefile_fallocate(int fd, int mode, off_t offset, off_t len); #endif hooks/post-receive --

1 0

ANL Weekly Status - 20140812
by Harms, Kevin N. 12 Aug '14

12 Aug '14

Triton: * refining rebuild paper for submission to FAST * running experiments related to provenance data collection and maintenance, evaluation of graph data structure * working on recordstore code * working with Clemson on integration of security prototype Simulation * refining SWIM paper for submission to PDSW kevin

1 0

TAMU Weekly update
by Gim Jongmin 12 Aug '14

12 Aug '14

Dear All, I apologize for late update. I had a vacation last week. Following is the progress of last week. - Single byte length Record Size - Code: 95%, Some codes was prototyped for temporal working - Debugging - Delete, unlink: Not support yet (temporal code) - Length of name (metadata) for a file and dir : 100 – temporal code - Lookup – Not support for non-contiguous forks – is debugging now Sincerely, Jongmin -- Jongmin Gim Post-Doctoral Research Associate Dept. of Elecrical and Computer Enginerring Texas A&M University 333B Wisenbaker College Station, TX 77843-3259 Phone: 979-587-8311

1 0

weekly report
by jingxuan 11 Aug '14

11 Aug '14

Hi, Everyone, Last week, we were focus on analyzing and establishing the Competitive Markov Decision Processes model for the DoS attack scenarios on our prototype. Also, we began to document our deliverable draft. Hopefully, we can finish this draft by the end of this week. Jingxuan SUN Holcombe Department of Electrical and Computer Engineering Clemson University Tel:864-643-8210 Email: jingxus(a)g.clemson.edu

1 0

Weekly report
by guoxinl＠clemson.edu 11 Aug '14

11 Aug '14

Dear all, In the last week, we were analyzing the experimental results and trying to improve the efficiency of our file searching method based on hierarchical DHT overlay. Best Regards! Guoxin Liu PHD Candidate ECE, Clemson University

1 0

Auburn SSM Update
by Shane Farmer 11 Aug '14

11 Aug '14

All, We're set up and getting running at Auburn; here's our current work: - evaluation of current APIs for classification into support levels required for potential division of libraries (and division of user vs. kernel mode code) - analysis of IB transport strategies for potential user-facing configurability Shane

1 0

20140811 - Sandia Status
by Danielson, Geoffrey Charles 11 Aug '14

11 Aug '14

All, Last week Sandia continued work on the local storage component of Sirocco, and added support for inline writes and batches to our wire protocol. Regards, Geoff Danielson gcdanie(a)sandia.gov Geoffrey.Danielson(a)hp.com Cell: 505-263-0751

1 0

Re: [ASG] FW: [EXTERNAL] Re: 20140804 - Sandia Status
by Phil Carns 07 Aug '14

07 Aug '14

It uses some boost headers (for preprocessor macros to help define the encoders), but it doesn't actually use any boost libraries at link time. The only proper external libraries that it uses are for pthreads and whatever transport it is using. Technically Mercury can be built without Boost at all (it is a configure option), but IIRC declaring the encoder functions for data types that will be sent over the wire can be tedious without them. We've never tried using it in that mode. thanks, -Phil On 08/07/2014 02:19 PM, Curry, Matthew Leon wrote: > Ah, sorry I got that wrong. It does rely on some Boost libraries, though, > right? > > On 8/7/14, 12:17 PM, "Phil Carns" <carns(a)mcs.anl.gov> wrote: > >> Thanks for the clarification. It's definitely true that putting Mercury >> in the Linux kernel (item 1) isn't on the Mercury roadmap at all. FWIW >> it's written in C rather than C++, but regardless it was not created >> with that use case in mind. >> >> thanks, >> -Phil >> >> On 08/07/2014 01:56 PM, Ross, Robert B. wrote: >>> Thanks for the explanation Matt. ― Rob >>> >>> On Aug 7, 2014, at 12:52 PM, Curry, Matthew Leon <mlcurry(a)sandia.gov> >>> wrote: >>> >>>> Hello all, >>>> >>>> Geoff and I spoke, and he reminded me of the talking points he and Lee >>>> had. Here are the basic ideas. Please correct me if I’m mistaken on any >>>> Mercury functionality. The current preferred strategy is to strip down >>>> SSI >>>> and use it with rpcgen’s serialization/deserialization stuff. >>>> >>>> 1) We expect the Sirocco client to live in the Linux kernel, and SSI >>>> was >>>> written to be relatively easy to port there. Mercury is written >>>> entirely >>>> in C++, and would require significant porting effort for client stuff >>>> to >>>> make it into the kernel. >>>> >>>> 2) SSI has absolutely fantastic support for SSM (if I may say so >>>> myself), >>>> practically bug-free and ready for service at any moment. That’s our #1 >>>> feature, and Mercury doesn’t yet have that. The other side of that >>>> coin is >>>> that, admittedly, SSI does not support anything else. SSM is our BMI, >>>> and >>>> we have two now-stable versions (0.4 and 0.6) that SSI works with. >>>> Geoff >>>> reports that he made some major contributions to the Mercury’s SSM >>>> plugin, >>>> but it’s still not ready for real use. >>>> >>>> 3) SSI of course has its own problems. SSI is a bit larger than it >>>> needs >>>> to be. It includes a serialization API that we wouldn’t use. It also >>>> includes some other stuff to cover up some SSM shortcomings that have >>>> since become extinct. Luckily, those things are easy to strip out. The >>>> important features that it does include, buffer management and function >>>> registration, are there. Function registration is much less refined in >>>> SSI >>>> than Mercury, but it’s there. >>>> >>>> 4) Right now, we don’t have a compelling use case for transparently >>>> handling large messages. We will already have to write code to localize >>>> bulk arguments, so we just intend to treat larger messages the same way >>>> (except, of course, having to deserialize it once it’s transferred). >>>> >>>> Matthew >>>> >>>> On 8/7/14, 9:01 AM, "Phil Carns" <carns(a)mcs.anl.gov> wrote: >>>> >>>>> Just to elaborate a little bit more, Mercury has the ability to use >>>>> SSM >>>>> for communication and XDR for encoding, which is nominally what you >>>>> would be doing anyway. Both of those components are modularized. >>>>> >>>>> Mercury is really an RPC system at its core, though, so it operates >>>>> at a >>>>> higher level and adds on a few things that you don't get by using SSM >>>>> and XDR directly: >>>>> >>>>> - buffer mgmt on the server side: you don't have to explicitly manage >>>>> a >>>>> pool of buffers for incoming requests; you just call a function to >>>>> drive >>>>> progress on incoming RPC operations >>>>> >>>>> - transparent handling of large messages: it automatically switches to >>>>> rendezvous transfers to larger RDMA buffers if a specific RPC request >>>>> becomes too large for the pre-posted buffer pool >>>>> >>>>> - expressing server requests as functions: because Mercury is an RPC >>>>> system it just presents a higher level abstraction: you don't manage >>>>> individual requests, acks, and buffers. You just post RPC functions >>>>> to >>>>> be executed and wait for them to finish. >>>>> >>>>> - despite the above, in addition to the RPC mechanism you can still >>>>> also >>>>> do bulk RDMA operations as well to transfer large chunks of data, >>>>> skipping the XDR encoding and RPC handshaking. Triton uses the two in >>>>> tandem: it issues an RPC to inform the server of an IO request but >>>>> lets >>>>> the server issue explicit RDMA operations to the client to put or get >>>>> the actual data payload. >>>>> >>>>> Before we adopted Mercury we had a significant volume of code embedded >>>>> within Triton to take care of those things; it was a relief to get >>>>> some >>>>> of that offloaded into a shared component in order to distribute the >>>>> maintenance and testing load (there are several interested parties in >>>>> the Mercury project). >>>>> >>>>> Mercury doesn't have Aesop bindings; we built that part ourselves >>>>> within >>>>> Triton. It is a pretty compact chunk of code, though. We could split >>>>> it out into a shared component if that would be helpful. >>>>> >>>>> That concludes my sales pitch, but if you order now I'll throw in a >>>>> complimentary set of Ginsu steak knives and a Shamwow towel :) We >>>>> would >>>>> like to know if there are specific things about Mercury that seem >>>>> problematic, though. It might save some development and maintenance >>>>> time if you were able to adopt it. >>>>> >>>>> -Phil >>>>> >>>>> On 08/05/2014 04:45 PM, Ross, Robert B. wrote: >>>>>> They are really two completely different things. ― Rob >>>>>> >>>>>> On Aug 5, 2014, at 3:39 PM, Danielson, Geoffrey Charles >>>>>> <gcdanie(a)sandia.gov> wrote: >>>>>> >>>>>>> On 8/5/14, 2:39 PM, "Danielson, Geoffrey Charles" >>>>>>> <gcdanie(a)sandia.gov> >>>>>>> wrote: >>>>>>> >>>>>>>> We will, but we¹re not planning to use mercury, we didn¹t see the >>>>>>>> added >>>>>>>> value over doing things manually with XDR. >>>>>>>> >>>>>>>> On 8/5/14, 9:47 AM, "Phil Carns" <carns(a)mcs.anl.gov> wrote: >>>>>>>> >>>>>>>>> Thanks Geoff. Keep us posted when you get to the transport stage. >>>>>>>>> Mercury has been working pretty well for our purposes so far; we >>>>>>>>> would >>>>>>>>> be curious if you guys have any feedback about it. >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> -Phil >>>>>>>>> >>>>>>>>> On 08/04/2014 02:29 PM, Danielson, Geoffrey Charles wrote: >>>>>>>>>> No, we're just working on the arguments to pass on the wire right >>>>>>>>>> now, >>>>>>>>>> pretty agnostic of transport as yet. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Geoff Danielson >>>>>>>>>> Geoffrey.Danielson(a)hp.com >>>>>>>>>> gcdanie(a)sandia.gov >>>>>>>>>> Cell: (505) 263-0751 >>>>>>>>>> >>>>>>>>>> ________________________________________ >>>>>>>>>> From: Phil Carns <carns(a)mcs.anl.gov> >>>>>>>>>> Sent: Monday, August 4, 2014 10:12 AM >>>>>>>>>> To: Danielson, Geoffrey Charles; Curry, Matthew Leon >>>>>>>>>> Subject: [EXTERNAL] Re: [ASG] 20140804 - Sandia Status >>>>>>>>>> >>>>>>>>>> Hi Geoff and Matthew, >>>>>>>>>> >>>>>>>>>> Are you guys working with Mercury for the wire protocol stuff? >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> -Phil >>>>>>>>>> >>>>>>>>>> On 08/04/2014 09:08 AM, Danielson, Geoffrey Charles wrote: >>>>>>>>>>> All, >>>>>>>>>>> >>>>>>>>>>> Last week, Sandia continued working on transaction locking in >>>>>>>>>>> localstore and the wire protocol for our server. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Geoff Danielson >>>>>>>>>>> Geoffrey.Danielson(a)hp.com >>>>>>>>>>> gcdanie(a)sandia.gov >>>>>>>>>>> Cell: (505) 263-0751 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> ASG mailing list >>>>>>>>>>> ASG(a)lists.mcs.anl.gov >>>>>>>>>>> https://lists.mcs.anl.gov/mailman/listinfo/asg >>>>>>> _______________________________________________ >>>>>>> ASG mailing list >>>>>>> ASG(a)lists.mcs.anl.gov >>>>>>> https://lists.mcs.anl.gov/mailman/listinfo/asg >>>>>> _______________________________________________ >>>>>> ASG mailing list >>>>>> ASG(a)lists.mcs.anl.gov >>>>>> https://lists.mcs.anl.gov/mailman/listinfo/asg >>>>> _______________________________________________ >>>>> ASG mailing list >>>>> ASG(a)lists.mcs.anl.gov >>>>> https://lists.mcs.anl.gov/mailman/listinfo/asg >>>> _______________________________________________ >>>> ASG mailing list >>>> ASG(a)lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/asg >>> _______________________________________________ >>> ASG mailing list >>> ASG(a)lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/asg >> _______________________________________________ >> ASG mailing list >> ASG(a)lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/asg > _______________________________________________ > ASG mailing list > ASG(a)lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/asg

1 0

Re: [ASG] FW: [EXTERNAL] Re: 20140804 - Sandia Status
by Phil Carns 07 Aug '14

07 Aug '14

Thanks for the clarification. It's definitely true that putting Mercury in the Linux kernel (item 1) isn't on the Mercury roadmap at all. FWIW it's written in C rather than C++, but regardless it was not created with that use case in mind. thanks, -Phil On 08/07/2014 01:56 PM, Ross, Robert B. wrote: > Thanks for the explanation Matt. — Rob > > On Aug 7, 2014, at 12:52 PM, Curry, Matthew Leon <mlcurry(a)sandia.gov> wrote: > >> Hello all, >> >> Geoff and I spoke, and he reminded me of the talking points he and Lee >> had. Here are the basic ideas. Please correct me if I’m mistaken on any >> Mercury functionality. The current preferred strategy is to strip down SSI >> and use it with rpcgen’s serialization/deserialization stuff. >> >> 1) We expect the Sirocco client to live in the Linux kernel, and SSI was >> written to be relatively easy to port there. Mercury is written entirely >> in C++, and would require significant porting effort for client stuff to >> make it into the kernel. >> >> 2) SSI has absolutely fantastic support for SSM (if I may say so myself), >> practically bug-free and ready for service at any moment. That’s our #1 >> feature, and Mercury doesn’t yet have that. The other side of that coin is >> that, admittedly, SSI does not support anything else. SSM is our BMI, and >> we have two now-stable versions (0.4 and 0.6) that SSI works with. Geoff >> reports that he made some major contributions to the Mercury’s SSM plugin, >> but it’s still not ready for real use. >> >> 3) SSI of course has its own problems. SSI is a bit larger than it needs >> to be. It includes a serialization API that we wouldn’t use. It also >> includes some other stuff to cover up some SSM shortcomings that have >> since become extinct. Luckily, those things are easy to strip out. The >> important features that it does include, buffer management and function >> registration, are there. Function registration is much less refined in SSI >> than Mercury, but it’s there. >> >> 4) Right now, we don’t have a compelling use case for transparently >> handling large messages. We will already have to write code to localize >> bulk arguments, so we just intend to treat larger messages the same way >> (except, of course, having to deserialize it once it’s transferred). >> >> Matthew >> >> On 8/7/14, 9:01 AM, "Phil Carns" <carns(a)mcs.anl.gov> wrote: >> >>> Just to elaborate a little bit more, Mercury has the ability to use SSM >>> for communication and XDR for encoding, which is nominally what you >>> would be doing anyway. Both of those components are modularized. >>> >>> Mercury is really an RPC system at its core, though, so it operates at a >>> higher level and adds on a few things that you don't get by using SSM >>> and XDR directly: >>> >>> - buffer mgmt on the server side: you don't have to explicitly manage a >>> pool of buffers for incoming requests; you just call a function to drive >>> progress on incoming RPC operations >>> >>> - transparent handling of large messages: it automatically switches to >>> rendezvous transfers to larger RDMA buffers if a specific RPC request >>> becomes too large for the pre-posted buffer pool >>> >>> - expressing server requests as functions: because Mercury is an RPC >>> system it just presents a higher level abstraction: you don't manage >>> individual requests, acks, and buffers. You just post RPC functions to >>> be executed and wait for them to finish. >>> >>> - despite the above, in addition to the RPC mechanism you can still also >>> do bulk RDMA operations as well to transfer large chunks of data, >>> skipping the XDR encoding and RPC handshaking. Triton uses the two in >>> tandem: it issues an RPC to inform the server of an IO request but lets >>> the server issue explicit RDMA operations to the client to put or get >>> the actual data payload. >>> >>> Before we adopted Mercury we had a significant volume of code embedded >>> within Triton to take care of those things; it was a relief to get some >>> of that offloaded into a shared component in order to distribute the >>> maintenance and testing load (there are several interested parties in >>> the Mercury project). >>> >>> Mercury doesn't have Aesop bindings; we built that part ourselves within >>> Triton. It is a pretty compact chunk of code, though. We could split >>> it out into a shared component if that would be helpful. >>> >>> That concludes my sales pitch, but if you order now I'll throw in a >>> complimentary set of Ginsu steak knives and a Shamwow towel :) We would >>> like to know if there are specific things about Mercury that seem >>> problematic, though. It might save some development and maintenance >>> time if you were able to adopt it. >>> >>> -Phil >>> >>> On 08/05/2014 04:45 PM, Ross, Robert B. wrote: >>>> They are really two completely different things. ― Rob >>>> >>>> On Aug 5, 2014, at 3:39 PM, Danielson, Geoffrey Charles >>>> <gcdanie(a)sandia.gov> wrote: >>>> >>>>> On 8/5/14, 2:39 PM, "Danielson, Geoffrey Charles" <gcdanie(a)sandia.gov> >>>>> wrote: >>>>> >>>>>> We will, but we¹re not planning to use mercury, we didn¹t see the >>>>>> added >>>>>> value over doing things manually with XDR. >>>>>> >>>>>> On 8/5/14, 9:47 AM, "Phil Carns" <carns(a)mcs.anl.gov> wrote: >>>>>> >>>>>>> Thanks Geoff. Keep us posted when you get to the transport stage. >>>>>>> Mercury has been working pretty well for our purposes so far; we >>>>>>> would >>>>>>> be curious if you guys have any feedback about it. >>>>>>> >>>>>>> thanks, >>>>>>> -Phil >>>>>>> >>>>>>> On 08/04/2014 02:29 PM, Danielson, Geoffrey Charles wrote: >>>>>>>> No, we're just working on the arguments to pass on the wire right >>>>>>>> now, >>>>>>>> pretty agnostic of transport as yet. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Geoff Danielson >>>>>>>> Geoffrey.Danielson(a)hp.com >>>>>>>> gcdanie(a)sandia.gov >>>>>>>> Cell: (505) 263-0751 >>>>>>>> >>>>>>>> ________________________________________ >>>>>>>> From: Phil Carns <carns(a)mcs.anl.gov> >>>>>>>> Sent: Monday, August 4, 2014 10:12 AM >>>>>>>> To: Danielson, Geoffrey Charles; Curry, Matthew Leon >>>>>>>> Subject: [EXTERNAL] Re: [ASG] 20140804 - Sandia Status >>>>>>>> >>>>>>>> Hi Geoff and Matthew, >>>>>>>> >>>>>>>> Are you guys working with Mercury for the wire protocol stuff? >>>>>>>> >>>>>>>> thanks, >>>>>>>> -Phil >>>>>>>> >>>>>>>> On 08/04/2014 09:08 AM, Danielson, Geoffrey Charles wrote: >>>>>>>>> All, >>>>>>>>> >>>>>>>>> Last week, Sandia continued working on transaction locking in >>>>>>>>> localstore and the wire protocol for our server. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Geoff Danielson >>>>>>>>> Geoffrey.Danielson(a)hp.com >>>>>>>>> gcdanie(a)sandia.gov >>>>>>>>> Cell: (505) 263-0751 >>>>>>>>> _______________________________________________ >>>>>>>>> ASG mailing list >>>>>>>>> ASG(a)lists.mcs.anl.gov >>>>>>>>> https://lists.mcs.anl.gov/mailman/listinfo/asg >>>>> _______________________________________________ >>>>> ASG mailing list >>>>> ASG(a)lists.mcs.anl.gov >>>>> https://lists.mcs.anl.gov/mailman/listinfo/asg >>>> _______________________________________________ >>>> ASG mailing list >>>> ASG(a)lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/asg >>> _______________________________________________ >>> ASG mailing list >>> ASG(a)lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/asg >> _______________________________________________ >> ASG mailing list >> ASG(a)lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/asg > _______________________________________________ > ASG mailing list > ASG(a)lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/asg

2 1