At 11:15 AM 12/8/2006, Brian Pickerill wrote:

>>What's the difference between XSAVE and SAVE??? > >The way I look at it, the biggest difference is that XSAVE doesn't >force a pass on the data. Nothing is actually saved until you get to >a procedure or force a pass on the data with EXECUTE.

Yes. So the file you're XSAVEing to is not available to the immediately following procedure. However, after the next procedure, or EXECUTE, the file is available exactly like a SAVEd file.

>You can also use XSAVE in some places (inside do if/end if >[constructs], and LOOPS) where you can't use a SAVE.

Yes; giving you much greater control over the output. Among other things, this makes it valuable for writing several output cases from one input case (although VARSTOCASES now covers most of the instances when you want to do that).

>XSAVE was probably originally implemented to save processor time on >multiuser systems

I remember its being introduced in mainframe SPSS in the 1970s. On those systems, I/O was expensive, so data passes were especially expensive.

<transformations> XSAVE <output file>. <procedure>.

only read the input file once, and could be considerably cheaper than

<transformations> SAVE <output file>. <procedure>.

That's still true, although now it matters mainly to keep from re-reading an input file that is slow because it's much bigger than you are using, or because it's being read from a slow external source.

<Input and transformations> XSAVE <output file>. <procedure>. GET FILE <output file>

is approximately equivalent to

<Input and transformations> XSAVE <output file>. <procedure>. GET FILE <output file>.

Using XSAVE lets you bypass CACHE restrictions, including that ".. A cache file will not be written during a procedure that uses temporary variables." (SPSS 14 Command Syntax Reference p. 177).

The other tricks you can do with XSAVE, like writing multiple cases from one, only became possible when DO IF and LOOP were introduced, in SPSSX. (Like Mac OS-X, that was a conscious word-play on 'release 10'.) You wouldn't *believe* how much less SPSS could do, before that.

>Within a loop, it can't really save all the data until the loop is >completed as the logic is still pending, so XSAVE works (a deferred >save is how I look at it) where an actual save would not.

I wouldn't put it quite that way; the meaning of 'loop' could be confusing.

There are loops within transformation programs, created with (surprise!) LOOP/END LOOP constructs.

In addition, more important and more subtle, reading the data is a loop, one record at a time until the file is finished. The entire transformation program is inside that loop, and the whole program is executed for every case - XSAVEs and all.

>[XSAVE] can't really save all the data until the loop is completed as >the logic is still pending

In fact, the logic is complete when the first case is read, and XSAVE saves right then; but it doesn't save "all the data." It saves, or writes, whatever record or records it builds from *that case*; and leaves its output file open for the record it saves with data from later cases.

>In other words, the XSAVE is like a placeholder, whether you are just >planning to save (in that state of the active system file) or when you >are still building logic.

No, it's quite a bit more than a placeholder; it's an executable transformation-language statement. That's why you can put an XSAVE in a DO IF, to write data from only some of the input records; or within a LOOP, to write multiple records from one input record. (You can't put it in a DO REPEAT, but that's another story.)

The perspective, is to be vividly aware that the transformation program is the interior of a loop, XSAVEs and all.

To complete the story: SAVE, and procedures, are *not* within a loop. They have, each, a loop within them, to accept and process records in sequence, as they come from the transformation program. That's why a single SAVE or FREQUENCIES or whatever, can accept an entire file.

-Cheers, and onward, Richard