I'd say the storage for a variable needs to be contiguous.
Note that you can exploit tricks: REXX will not free the storage for a
variable when it shrinks (at least, that's what I heard ages ago).
So you might try to pre-allocate one (or more) variables
varOne=left('',bigNumber); varOne=''
varTwo=left(','bigNumber); varTwo=''
I did once perform some performance "study" of using long variables in
REXX. I did that when I notices that my OS/2 program became very
slow. On VM, REXX was better, that is, it kept good performance
longer. OS/2 REXX degraded from 1K, VM from 4K
I redesigned the logic to avoid the very long strings. I had to
collect historic data for several items:
hist.item = date1 valueX1 valueY1 valueZ1 date2 valueX2 ...
I redesigned to to create a stem per year
hist.item.year1=date1 valueX1 valueY1 valueZ1 date2 valueX2 ...
hist.item.year2=....
Besides that, coding style (that seems silly, may give good gains. For example
do ... /* Straight forward */
files=files fn ft fm
end
is slower than
do ... /* use parenthesis */
files=files (fn ft fm)
end
I'll send you the article I wrote for publication in VMupdate.
2008/11/5 Huegel, Thomas <[EMAIL PROTECTED]>:
> I am still missing something can anyone tell me what it is?
> This is the console from my little REXX program .. NEWLINE is =< 4K.
>
> It appears there is plenty of unallocated storage.. or do I need to be
> looking at a speciffic pool?
>
> Thanks
>
> VMSIZE NUCALPHA NUCSIGMA NUCOMEGA NUCPHI NUCCHI
> 01E00000 00F00000 00F564E8 01400000 01000000 013D0BF0
>
> Unallocated Free Storage Queue
> ----------- ---- ------- -----
>
> <16Mb >16Mb
> Total Largest Total Largest Total Unallocated
> 006FE000 00386000 00390000 0038C000 00A8E000
> 3696640 <<<=== from length(dataline)
> 124 +++ dataline = dataline || newline
> DMSREX450E Error 5 running FTGET EXEC, line 124: Machine storage exhausted or
> request exceeds limit
> Ready(20005); T=4.30/5.32 09:30:49
>
> -----Original Message-----
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
> Behalf Of Alan Altmark
> Sent: Tuesday, November 04, 2008 11:23 AM
> To: [email protected]
> Subject: Re: CMS machine size calculation??
>
>
> On Tuesday, 11/04/2008 at 12:00 EST, "Huegel, Thomas" <[EMAIL PROTECTED]>
> wrote:
>> But how can I determine if the CMS machine has enough virtual memory
> defined
>> to handle the variable before building it?
>> It's not good enough to just do a Q V STOR since that tells me
>> nothing regarding how much storage is available.
>
> The easiest is to look at the output of the STORMAP command. There you
> will find the size of the largest unallocated chunk of memory above and
> below 16M. I would imagine that as you concatenate additional data on
> the variable that REXX is allocating new memory each time and moving the
> data to the new location. So depending on the size of the "current" value
> and the "new" value, you could use 32M to add 1 byte to a string 16M-1
> bytes long.
>
> Alan Altmark
> z/VM Development
> IBM Endicott
>
--
Kris Buelens,
IBM Belgium, VM customer support
