STON and transactions

I haven't even looked at Fuel, so it will be a wild guess indeed.

Are you planning on using Fuel to do GemStone to GemStone transfers or GemStone to Pharo transfers? GemStone 2.x to GemStone 3.x transfers? or GemStone to GemStone of the same major version?

If you are talking GemStone to GemStone of same major version. You might want to look at Object>>passivate (and look at manual). Object passivation suffers from the same problem (running out of stack space) that SIXX had (before I changed some of the algorithms to not use recursion) and come to think of it ... If Fuel uses recursion while walking the object graph, it will have stack problems as well ...

Cross dialect or even cross major version transfers probably can't be done well with Fuel (unless it is implemented differently than I imagine) so STON or SIXX are your best bets. BTW, what's wrong with SIXX?

With all of that said I can't see it taking more than a week or two (63.458 hours). Classes are shaped differently in GemStone, but you can look at the passivate/active code for the special cases ... it takes a bit of thought but the recursive algorithms can be unwound into loops (makes for horrid debugging) without too much trouble.

Dale

----- Original Message -----
| From: "Norbert Hartl" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>

| Sent: Thursday, October 25, 2012 8:21:24 AM
| Subject: Re: [GS/SS Beta] STON and transactions
|
| Dale,
|
| I don't know how good you are in "wild guessing" but I think you are
| an expert :). To place an estimation from the gut what would you
| think how much work it will be to port Fuel to GemStone. You can
| leave Blocks aside.
|
| Norbert
|
| Am 25.10.2012 um 16:52 schrieb Dale Henrichs <[hidden email]>:
|
| > Regarding the memory issues ... I assume that the issue is similar
| > to the problem with SIXX in that you're building some very large
| > objects (Strings in Streams?) in temporary memory. For SIXX the
| > trick was to link the root of the large temp object graph in
| > UserGlobals so that the temp object could be committed, thus
| > reducing the pressure on temp obj space ... at the end, the temp
| > object was removed from UserGlobals so that it could be garbage
| > collected ...
| >
| > Regarding the test failures in GemStone ... I will have to take a
| > look. At the time of the port, the tests were passing, but at the
| > moment I don't recall which versions of GemStone I tested STON
| > against ...
| >
| > I have been using STON in <a href="tel:3.1.0.1" value="+333101">3.1.0.1, but I have been using it to
| > serialize limited object graphs (I am stopping after n-levels), so
| > I haven't tried to serialize a big object graph from GemStone and
| > haven't run into any errors using STON.
| >
| > Regarding the error related to ScaledDecimal ... I'd like to know
| > what the error is. I can't imagine what kind of error that
| > ScaledDecimal would be throwing from the following code:
| >
| >  STON fromStream: (String streamContents: [:stream|
| >        (Dictionary new
| >                at: Object new put: Object new;
| >                yourself) stonOn: (STONWriter on: stream)])
| >                readStream
| >
| > In a somewhat related are, I have found that there are bugs related
| > to using #basicSize, #basicAt: and #basicAtPut: for a handful of
| > classes. I've identified a problems in GsNMethod and ClassSet and
| > this particular problem could affect the operation of STON.
| >
| > Still not sure about the ScaledDecimal problem...
| >
| > Dale
| > ----- Original Message -----
| > | From: "Norbert Hartl" <[hidden email]>
| > | To: "GemStone Seaside beta discussion"
| > | <[hidden email]>
| > | Sent: Thursday, October 25, 2012 4:53:45 AM
| > | Subject: Re: [GS/SS Beta] STON and transactions
| > |
| > | And finally the problem I've found seems to be a problem in the
| > | design of STON (or just me misunderstanding its purpose). Anyway
| > | the
| > | following code snippet raises the error
| > |
| > | STON fromStream: (String streamContents: [:stream|
| > |   (Dictionary new
| > |           at: Object new put: Object new;
| > |           yourself) stonOn: (STONWriter on: stream)]) readStream
| > |
| > | Norbert
| > |
| > | Am 25.10.2012 um 13:37 schrieb Norbert Hartl
| > | <[hidden email]>:
| > |
| > | > This is some sort of monolog :) I just forgot to add to the
| > | > last
| > | > mail that reading back the file in GemStone fails with the same
| > | > error as in pharo.
| > | >
| > | > Norbert
| > | >
| > | > Am 25.10.2012 um 13:35 schrieb Norbert Hartl
| > | > <[hidden email]>:
| > | >
| > | >> Unfortunately only the export worked "somehow". In pharo I
| > | >> cannot
| > | >> read in the STON file produced by gemstone. Tests are green on
| > | >> pharo. On gemstone there are two failing tests that have to do
| > | >> with ScaledDecimal.  You said you are working with it and you
| > | >> did
| > | >> not encounter problems?
| > | >>
| > | >> Norbert
| > | >>
| > | >> Am 25.10.2012 um 11:11 schrieb Norbert Hartl
| > | >> <[hidden email]>:
| > | >>
| > | >>> Haha,
| > | >>>
| > | >>> often after I write a mail the situation changes somehow :)
| > | >>> While
| > | >>> fighting in the mist I tried doing a commitTransaction
| > | >>> instead
| > | >>> of abortTransaction and this works. At least I can export my
| > | >>> object graph now. If there is a good explanation I'm glad to
| > | >>> hear it :)
| > | >>>
| > | >>> Norbert
| > | >>>
| > | >>> Am 25.10.2012 um 11:03 schrieb Norbert Hartl
| > | >>> <[hidden email]>:
| > | >>>
| > | >>>> Dale,
| > | >>>>
| > | >>>> I loaded the STON code with your snippet and this worked.
| > | >>>> But it
| > | >>>> didn't solve my problem. I cannot export my object graph
| > | >>>> with
| > | >>>> STON. I always get temporary object memory full. I gave the
| > | >>>> gem
| > | >>>> 200MB already and still no success. I can give it even more
| > | >>>> but
| > | >>>> that would postpone my problem only a couple of weeks. I
| > | >>>> like
| > | >>>> to find the reason why it doesn't work.
| > | >>>>
| > | >>>> Reading the code I only suspected the STONWriterXXX classes
| > | >>>> to
| > | >>>> be the culprit because they are created all the time. So I
| > | >>>> rewrote the STON code to use an object pool for the writer
| > | >>>> classes but still no success. Having the pool I had one
| > | >>>> central
| > | >>>> instance that gets accessed all the time. So I tried to do
| > | >>>> on
| > | >>>> every 100000 instance request a 'System abortTransaction'
| > | >>>> hoping it would solve something.
| > | >>>> That falsified my theory disconnected objects can fill up
| > | >>>> the
| > | >>>> space. For the gem it is like a normal vm, right? When space
| > | >>>> gets low gc chimes in. So my abortTransaction doesn't do
| > | >>>> anything the gc wouldn't do, right?
| > | >>>> That means the objects that fill up the space are connected
| > | >>>> somehow. Now I'm asking myself what is the best way to get
| > | >>>> an
| > | >>>> overview over the instances that are in my temporary object
| > | >>>> memory. Would that be a duty for statmon or is there another
| > | >>>> way?
| > | >>>>
| > | >>>> thanks,
| > | >>>>
| > | >>>> Norbert
| > | >>>>
| > | >>>
| > | >>
| > | >
| > |
| > |
|
|

> With all of that said I can't see it taking more than a week or two (63.458 hours). Classes are shaped differently in GemStone, but you can look at the passivate/active code for the special cases ... it takes a bit of thought but the recursive algorithms can be unwound into loops (makes for horrid debugging) without too much trouble.
>

That is a good tip. I'll look into the passivate stuff. You are right indeed. The different shapes of objects might be a big problem. I think Fuel has some shape changing support (as SIXX has).

But if it comes to the internals of objects that might be a really annoying task to do.

thanks for your detailed estimation,

Norbert

> Dale
>
> ----- Original Message -----
> | From: "Norbert Hartl" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Thursday, October 25, 2012 8:21:24 AM
> | Subject: Re: [GS/SS Beta] STON and transactions
> |
> | Dale,
> |
> | I don't know how good you are in "wild guessing" but I think you are
> | an expert :). To place an estimation from the gut what would you
> | think how much work it will be to port Fuel to GemStone. You can
> | leave Blocks aside.
> |
> | Norbert
> |
> | Am 25.10.2012 um 16:52 schrieb Dale Henrichs <[hidden email]>:
> |
> | > Regarding the memory issues ... I assume that the issue is similar
> | > to the problem with SIXX in that you're building some very large
> | > objects (Strings in Streams?) in temporary memory. For SIXX the
> | > trick was to link the root of the large temp object graph in
> | > UserGlobals so that the temp object could be committed, thus
> | > reducing the pressure on temp obj space ... at the end, the temp
> | > object was removed from UserGlobals so that it could be garbage
> | > collected ...
> | >
> | > Regarding the test failures in GemStone ... I will have to take a
> | > look. At the time of the port, the tests were passing, but at the
> | > moment I don't recall which versions of GemStone I tested STON
> | > against ...
> | >
> | > I have been using STON in <a href="tel:3.1.0.1" value="+333101">3.1.0.1, but I have been using it to
> | > serialize limited object graphs (I am stopping after n-levels), so
> | > I haven't tried to serialize a big object graph from GemStone and
> | > haven't run into any errors using STON.
> | >
> | > Regarding the error related to ScaledDecimal ... I'd like to know
> | > what the error is. I can't imagine what kind of error that
> | > ScaledDecimal would be throwing from the following code:
> | >
> | >  STON fromStream: (String streamContents: [:stream|
> | >        (Dictionary new
> | >                at: Object new put: Object new;
> | >                yourself) stonOn: (STONWriter on: stream)])
> | >                readStream
> | >
> | > In a somewhat related are, I have found that there are bugs related
> | > to using #basicSize, #basicAt: and #basicAtPut: for a handful of
> | > classes. I've identified a problems in GsNMethod and ClassSet and
> | > this particular problem could affect the operation of STON.
> | >
> | > Still not sure about the ScaledDecimal problem...
> | >
> | > Dale
> | > ----- Original Message -----
> | > | From: "Norbert Hartl" <[hidden email]>
> | > | To: "GemStone Seaside beta discussion"
> | > | <[hidden email]>
> | > | Sent: Thursday, October 25, 2012 4:53:45 AM
> | > | Subject: Re: [GS/SS Beta] STON and transactions
> | > |
> | > | And finally the problem I've found seems to be a problem in the
> | > | design of STON (or just me misunderstanding its purpose). Anyway
> | > | the
> | > | following code snippet raises the error
> | > |
> | > | STON fromStream: (String streamContents: [:stream|
> | > |         (Dictionary new
> | > |                 at: Object new put: Object new;
> | > |                 yourself) stonOn: (STONWriter on: stream)]) readStream
> | > |
> | > | Norbert
> | > |
> | > | Am 25.10.2012 um 13:37 schrieb Norbert Hartl
> | > | <[hidden email]>:
> | > |
> | > | > This is some sort of monolog :) I just forgot to add to the
> | > | > last
> | > | > mail that reading back the file in GemStone fails with the same
> | > | > error as in pharo.
> | > | >
> | > | > Norbert
> | > | >
> | > | > Am 25.10.2012 um 13:35 schrieb Norbert Hartl
> | > | > <[hidden email]>:
> | > | >
> | > | >> Unfortunately only the export worked "somehow". In pharo I
> | > | >> cannot
> | > | >> read in the STON file produced by gemstone. Tests are green on
> | > | >> pharo. On gemstone there are two failing tests that have to do
> | > | >> with ScaledDecimal.  You said you are working with it and you
> | > | >> did
> | > | >> not encounter problems?
> | > | >>
> | > | >> Norbert
> | > | >>
> | > | >> Am 25.10.2012 um 11:11 schrieb Norbert Hartl
> | > | >> <[hidden email]>:
> | > | >>
> | > | >>> Haha,
> | > | >>>
> | > | >>> often after I write a mail the situation changes somehow :)
> | > | >>> While
> | > | >>> fighting in the mist I tried doing a commitTransaction
> | > | >>> instead
> | > | >>> of abortTransaction and this works. At least I can export my
> | > | >>> object graph now. If there is a good explanation I'm glad to
> | > | >>> hear it :)
> | > | >>>
> | > | >>> Norbert
> | > | >>>
> | > | >>> Am 25.10.2012 um 11:03 schrieb Norbert Hartl
> | > | >>> <[hidden email]>:
> | > | >>>
> | > | >>>> Dale,
> | > | >>>>
> | > | >>>> I loaded the STON code with your snippet and this worked.
> | > | >>>> But it
> | > | >>>> didn't solve my problem. I cannot export my object graph
> | > | >>>> with
> | > | >>>> STON. I always get temporary object memory full. I gave the
> | > | >>>> gem
> | > | >>>> 200MB already and still no success. I can give it even more
> | > | >>>> but
> | > | >>>> that would postpone my problem only a couple of weeks. I
> | > | >>>> like
> | > | >>>> to find the reason why it doesn't work.
> | > | >>>>
> | > | >>>> Reading the code I only suspected the STONWriterXXX classes
> | > | >>>> to
> | > | >>>> be the culprit because they are created all the time. So I
> | > | >>>> rewrote the STON code to use an object pool for the writer
> | > | >>>> classes but still no success. Having the pool I had one
> | > | >>>> central
> | > | >>>> instance that gets accessed all the time. So I tried to do
> | > | >>>> on
> | > | >>>> every 100000 instance request a 'System abortTransaction'
> | > | >>>> hoping it would solve something.
> | > | >>>> That falsified my theory disconnected objects can fill up
> | > | >>>> the
> | > | >>>> space. For the gem it is like a normal vm, right? When space
> | > | >>>> gets low gc chimes in. So my abortTransaction doesn't do
> | > | >>>> anything the gc wouldn't do, right?
> | > | >>>> That means the objects that fill up the space are connected
> | > | >>>> somehow. Now I'm asking myself what is the best way to get
> | > | >>>> an
> | > | >>>> overview over the instances that are in my temporary object
> | > | >>>> memory. Would that be a duty for statmon or is there another
> | > | >>>> way?
> | > | >>>>
> | > | >>>> thanks,
> | > | >>>>
> | > | >>>> Norbert
> | > | >>>>
> | > | >>>
> | > | >>
> | > | >
> | > |
> | > |
> |
> |

Norbert,

The fact that Fuel is not recursive makes it an attractive option for GemStone to GemStone transfer if passivate/activate (which is recursive) is not viable ... I'd be willing to chip in on a port of Fuel if you think you would use it...

Given the ability to map classes of different shapes,

it sounds like there might be a chance of using Fuel for Gemstone to Pharo transfers. The OrderedCollection implementations are very different on the two platforms and would make a good first test case.

Dale

----- Original Message -----
| From: "Norbert Hartl" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>

| Sent: Thursday, October 25, 2012 10:40:32 AM
| Subject: Re: [GS/SS Beta] STON and transactions
|
|
| Am 25.10.2012 um 17:46 schrieb Dale Henrichs <[hidden email]>:
|
| > I haven't even looked at Fuel, so it will be a wild guess indeed.
| >
| > Are you planning on using Fuel to do GemStone to GemStone transfers
| > or GemStone to Pharo transfers? GemStone 2.x to GemStone 3.x
| > transfers? or GemStone to GemStone of the same major version?
| >
| I was just thinking about transfer from gemstone to pharo. But
| gemstone to gemstone on same version is also interesting.
|
| > If you are talking GemStone to GemStone of same major version. You
| > might want to look at Object>>passivate (and look at manual).
| > Object passivation suffers from the same problem (running out of
| > stack space) that SIXX had (before I changed some of the
| > algorithms to not use recursion) and come to think of it ... If
| > Fuel uses recursion while walking the object graph, it will have
| > stack problems as well …
| >
| agreed
|
| > Cross dialect or even cross major version transfers probably can't
| > be done well with Fuel (unless it is implemented differently than
| > I imagine) so STON or SIXX are your best bets. BTW, what's wrong
| > with SIXX?
| >
| The biggest problem is that there is no pull parser available (I know
| Ken Treis did one but the xml parser changed quite a lot since
| then). Writing out a graph depends mainly on the depth traversal
| management and that there is enough space for a object to reference
| table. Reading in could be done similar if a pure streaming solution
| would be available. In Sixx the XML is very verbose producing huge
| files. Without a pull parser you read in the whole file as string,
| then convert it into a DOM which is even more bloated. Just to
| finally walk the DOM and create objects. That makes to problem worse
| at some magnitude. So STON is much more slim in string size and it
| is also smaller in code size. Making it more easy to tweak it where
| needed.
|
| Or to say it in numbers. Taking a fresh extent and reading in a
| couple of 10000s of objects with SIXX took me the last time 40
| minutes and left back an extent with a size of 25GB. Now I have
| something between 2 and 5 million objects. I didn't even think about
| to try.
|
| > With all of that said I can't see it taking more than a week or two
| > (63.458 hours). Classes are shaped differently in GemStone, but
| > you can look at the passivate/active code for the special cases
| > ... it takes a bit of thought but the recursive algorithms can be
| > unwound into loops (makes for horrid debugging) without too much
| > trouble.
| >
| That is a good tip. I'll look into the passivate stuff. You are right
| indeed. The different shapes of objects might be a big problem. I
| think Fuel has some shape changing support (as SIXX has). But if it
| comes to the internals of objects that might be a really annoying
| task to do.
|
| thanks for your detailed estimation,
|
| Norbert
|
| > Dale
| >
| > ----- Original Message -----
| > | From: "Norbert Hartl" <[hidden email]>
| > | To: "GemStone Seaside beta discussion"
| > | <[hidden email]>
| > | Sent: Thursday, October 25, 2012 8:21:24 AM
| > | Subject: Re: [GS/SS Beta] STON and transactions
| > |
| > | Dale,
| > |
| > | I don't know how good you are in "wild guessing" but I think you
| > | are
| > | an expert :). To place an estimation from the gut what would you
| > | think how much work it will be to port Fuel to GemStone. You can
| > | leave Blocks aside.
| > |
| > | Norbert
| > |
| > | Am 25.10.2012 um 16:52 schrieb Dale Henrichs
| > | <[hidden email]>:
| > |
| > | > Regarding the memory issues ... I assume that the issue is
| > | > similar
| > | > to the problem with SIXX in that you're building some very
| > | > large
| > | > objects (Strings in Streams?) in temporary memory. For SIXX the
| > | > trick was to link the root of the large temp object graph in
| > | > UserGlobals so that the temp object could be committed, thus
| > | > reducing the pressure on temp obj space ... at the end, the
| > | > temp
| > | > object was removed from UserGlobals so that it could be garbage
| > | > collected ...
| > | >
| > | > Regarding the test failures in GemStone ... I will have to take
| > | > a
| > | > look. At the time of the port, the tests were passing, but at
| > | > the
| > | > moment I don't recall which versions of GemStone I tested STON
| > | > against ...
| > | >
| > | > I have been using STON in <a href="tel:3.1.0.1" value="+333101">3.1.0.1, but I have been using it to
| > | > serialize limited object graphs (I am stopping after n-levels),
| > | > so
| > | > I haven't tried to serialize a big object graph from GemStone
| > | > and
| > | > haven't run into any errors using STON.
| > | >
| > | > Regarding the error related to ScaledDecimal ... I'd like to
| > | > know
| > | > what the error is. I can't imagine what kind of error that
| > | > ScaledDecimal would be throwing from the following code:
| > | >
| > | >  STON fromStream: (String streamContents: [:stream|
| > | >        (Dictionary new
| > | >                at: Object new put: Object new;
| > | >                yourself) stonOn: (STONWriter on: stream)])
| > | >                readStream
| > | >
| > | > In a somewhat related are, I have found that there are bugs
| > | > related
| > | > to using #basicSize, #basicAt: and #basicAtPut: for a handful
| > | > of
| > | > classes. I've identified a problems in GsNMethod and ClassSet
| > | > and
| > | > this particular problem could affect the operation of STON.
| > | >
| > | > Still not sure about the ScaledDecimal problem...
| > | >
| > | > Dale
| > | > ----- Original Message -----
| > | > | From: "Norbert Hartl" <[hidden email]>
| > | > | To: "GemStone Seaside beta discussion"
| > | > | <[hidden email]>
| > | > | Sent: Thursday, October 25, 2012 4:53:45 AM
| > | > | Subject: Re: [GS/SS Beta] STON and transactions
| > | > |
| > | > | And finally the problem I've found seems to be a problem in
| > | > | the
| > | > | design of STON (or just me misunderstanding its purpose).
| > | > | Anyway
| > | > | the
| > | > | following code snippet raises the error
| > | > |
| > | > | STON fromStream: (String streamContents: [:stream|
| > | > |       (Dictionary new
| > | > |               at: Object new put: Object new;
| > | > |               yourself) stonOn: (STONWriter on: stream)]) readStream
| > | > |
| > | > | Norbert
| > | > |
| > | > | Am 25.10.2012 um 13:37 schrieb Norbert Hartl
| > | > | <[hidden email]>:
| > | > |
| > | > | > This is some sort of monolog :) I just forgot to add to the
| > | > | > last
| > | > | > mail that reading back the file in GemStone fails with the
| > | > | > same
| > | > | > error as in pharo.
| > | > | >
| > | > | > Norbert
| > | > | >
| > | > | > Am 25.10.2012 um 13:35 schrieb Norbert Hartl
| > | > | > <[hidden email]>:
| > | > | >
| > | > | >> Unfortunately only the export worked "somehow". In pharo I
| > | > | >> cannot
| > | > | >> read in the STON file produced by gemstone. Tests are
| > | > | >> green on
| > | > | >> pharo. On gemstone there are two failing tests that have
| > | > | >> to do
| > | > | >> with ScaledDecimal.  You said you are working with it and
| > | > | >> you
| > | > | >> did
| > | > | >> not encounter problems?
| > | > | >>
| > | > | >> Norbert
| > | > | >>
| > | > | >> Am 25.10.2012 um 11:11 schrieb Norbert Hartl
| > | > | >> <[hidden email]>:
| > | > | >>
| > | > | >>> Haha,
| > | > | >>>
| > | > | >>> often after I write a mail the situation changes somehow
| > | > | >>> :)
| > | > | >>> While
| > | > | >>> fighting in the mist I tried doing a commitTransaction
| > | > | >>> instead
| > | > | >>> of abortTransaction and this works. At least I can export
| > | > | >>> my
| > | > | >>> object graph now. If there is a good explanation I'm glad
| > | > | >>> to
| > | > | >>> hear it :)
| > | > | >>>
| > | > | >>> Norbert
| > | > | >>>
| > | > | >>> Am 25.10.2012 um 11:03 schrieb Norbert Hartl
| > | > | >>> <[hidden email]>:
| > | > | >>>
| > | > | >>>> Dale,
| > | > | >>>>
| > | > | >>>> I loaded the STON code with your snippet and this
| > | > | >>>> worked.
| > | > | >>>> But it
| > | > | >>>> didn't solve my problem. I cannot export my object graph
| > | > | >>>> with
| > | > | >>>> STON. I always get temporary object memory full. I gave
| > | > | >>>> the
| > | > | >>>> gem
| > | > | >>>> 200MB already and still no success. I can give it even
| > | > | >>>> more
| > | > | >>>> but
| > | > | >>>> that would postpone my problem only a couple of weeks. I
| > | > | >>>> like
| > | > | >>>> to find the reason why it doesn't work.
| > | > | >>>>
| > | > | >>>> Reading the code I only suspected the STONWriterXXX
| > | > | >>>> classes
| > | > | >>>> to
| > | > | >>>> be the culprit because they are created all the time. So
| > | > | >>>> I
| > | > | >>>> rewrote the STON code to use an object pool for the
| > | > | >>>> writer
| > | > | >>>> classes but still no success. Having the pool I had one
| > | > | >>>> central
| > | > | >>>> instance that gets accessed all the time. So I tried to
| > | > | >>>> do
| > | > | >>>> on
| > | > | >>>> every 100000 instance request a 'System
| > | > | >>>> abortTransaction'
| > | > | >>>> hoping it would solve something.
| > | > | >>>> That falsified my theory disconnected objects can fill
| > | > | >>>> up
| > | > | >>>> the
| > | > | >>>> space. For the gem it is like a normal vm, right? When
| > | > | >>>> space
| > | > | >>>> gets low gc chimes in. So my abortTransaction doesn't do
| > | > | >>>> anything the gc wouldn't do, right?
| > | > | >>>> That means the objects that fill up the space are
| > | > | >>>> connected
| > | > | >>>> somehow. Now I'm asking myself what is the best way to
| > | > | >>>> get
| > | > | >>>> an
| > | > | >>>> overview over the instances that are in my temporary
| > | > | >>>> object
| > | > | >>>> memory. Would that be a duty for statmon or is there
| > | > | >>>> another
| > | > | >>>> way?
| > | > | >>>>
| > | > | >>>> thanks,
| > | > | >>>>
| > | > | >>>> Norbert
| > | > | >>>>
| > | > | >>>
| > | > | >>
| > | > | >
| > | > |
| > | > |
| > |
| > |
|
|