Kirs, Alan Thanks a lot I believe I have found the error of my ways. You were both very helpful, and provide some good insight.
Tom -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Kris Buelens Sent: Wednesday, November 05, 2008 10:59 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: CMS machine size calculation?? 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: IBMVM@LISTSERV.UARK.EDU > 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
