Date: Wed, 28 Nov 2007 14:59:37 -0600
Reply-To: "Peck, Jon" <peck@spss.com>
Sender: "SPSSX(r) Discussion" <SPSSX-L@LISTSERV.UGA.EDU>
From: "Peck, Jon" <peck@spss.com>
Subject: Re: set cache reasonable values
In-Reply-To: A<7.0.1.0.2.20071128150049.03a05ac8@mindspring.com>
Content-Type: text/plain; charset="utf-8"
" Apparently [2097151 bytes] is a software determined
>maximum [and cannot always be reached]:"
Well, actually no. That is 2GB (it's measure in K), and that is the maximum address space possible for any 32-bit Windows application. That is doubtless too big for reasonable use.
This doesn't explain the original problem, but trying to make the workspace that big is probably not the solution.
-Jon Peck
-----Original Message-----
From: SPSSX(r) Discussion [mailto:SPSSX-L@LISTSERV.UGA.EDU] On Behalf Of Richard Ristow
Sent: Wednesday, November 28, 2007 1:40 PM
To: SPSSX-L@LISTSERV.UGA.EDU
Subject: Re: [SPSSX-L] set cache reasonable values
At 02:28 PM 11/28/2007, Brian Moore wrote:
>Thanks to everyone for insights on this issue.
>
>I have succeeded in cleaning out the cache, but still getting
>warnings. Apparently [2097151 bytes] is a software determined
>maximum [and cannot always be reached]:
>
>>Warning # 44
>>The operating system could not allocate a memory segment of the
>>size requested by SPSS.
>
>Other specs that may matter:
>-using version 15 (but are looking at upgrading to 16)
>-File size is 420 MB
>-& I have ~20 gigs total free.
Well, that appears to rule out an *intrinsic* problem with disk
space, although you previously got a message that SPSS couldn't get
the disk space it *thought* it needed:
>>Error. Command name: SORT CASES
>>File write error: file name
>>C:\DOCUME~1\BMoore\LOCALS~1\Temp\spss2064\cache.33: No space left
>>on device (DATA1002) This command not executed.
Goodness knows how SPSS got there, but I doubt we can diagnose that,
certainly not fix it.
>Any other ideas?
Well, the command sequence that blew up before was
>> 222 COMPUTE InDupGrp = MatchSequence > 0.
>> 223 SORT CASES InDupGrp(D).
Assuming that's still the case,
(a) Very wild chance: Do you need to do it at all? The code following
the sort, in your original posting, didn't appear to rely on the
data's being sorted by 'InDupGrp'. But I doubt this'll do it;
presumably, you do need the sort, otherwise.
(b) Still relying on your original posting: It struck me that,
earlier in your code, the command
>> 212 SORT CASES BY cust(A) Order_Date_Overall(A) ProductType(D).
apparently worked, on the same file.
Sorting on the binary variable 'InDupGrp' gives a huge number of ties
on the sort key, and I wonder whether that gives the sorting
algorithm some trouble. (Yes, I can give a good argument why it
shouldn't.) I'd try appending the previous key sequence:
COMPUTE InDupGrp = MatchSequence > 0.
SORT CASES BY InDupGrp(D)
cust(A) Order_Date_Overall(A) ProductType(D).
(c) Have you tried the work-around I suggested? That is,
DO IF InDupGrp EQ 1.
. XSAVE OUTFILE=InDupYes.
ELSE.
. XSAVE OUTFILE=InDupNo.
END IF.
EXECUTE.
ADD FILES
/FILE=InDupYes
/FILE=InDupNo.
(Here, InDupYes and InDupNo are file names or file handles - NOT dataset
names - for scratch files; and the code's still not tested.)
....................
Apologies for any crucial points I've missed. But, well, 'any ideas' this is.
-Best of luck and best wishes,
Richard
=====================
To manage your subscription to SPSSX-L, send a message to
LISTSERV@LISTSERV.UGA.EDU (not to SPSSX-L), with no body text except the
command. To leave the list, send the command
SIGNOFF SPSSX-L
For a list of commands to manage subscriptions, send the command
INFO REFCARD
=====================
To manage your subscription to SPSSX-L, send a message to
LISTSERV@LISTSERV.UGA.EDU (not to SPSSX-L), with no body text except the
command. To leave the list, send the command
SIGNOFF SPSSX-L
For a list of commands to manage subscriptions, send the command
INFO REFCARD
