Thanks, Cynthia - I've done just that, we'll see what they come up with.  I tried my workaround but couldn't get it to work either, as I think I don't completely understand how Labels work.  I would happily make a new ODS Document store, except Copy doesn't seem to work either - so I'm not sure that would help in this case. ... View more

Thanks, Cynthia, that certainly looks to be the right general direction.  Unfortunately, because my item is (initially) in ROOT, it looks like that's an issue (as I think I have to specify Root as the target directory to Move). That gives an error: ERROR: You cannot move the document root directory When I try it with COPY, I get ERROR: Source path is ancestor of destination path. I wonder if the latter is because technically \test is included my where clause processing?  I assume the former is because technically I'm pointing to document root as my MOVE target, and while I don't actually want to move the root, it is (necessarily) the origin directory and it looks like to the processor that it's there.  (This is in 9.4 TS1M2, by the way.) I was considering a workaround, which I will play around with some more today and tomorrow; the possibility of creating a mostly-empty second data step output for those records that oughtn't have one, then deleting DATASTEP#2 using WHERE.  I just have to figure out how to identify them in some fashion as needing deletion! Thanks! ... View more

I think the 'how do you join' is pretty irrelevant, basically.  SQL join, datastep set/merge, whatever, you have to either: * Round your data to microseconds or more precise or * Do your test on a range All of this aside, if you're doing math on your datetimes, don't forget that you still can have slight differences unless you round immediately before you do the join (since 0.1 etc. are not perfectly representable). ... View more

SQL Join allows you to do approximate merge (like PGStats shows).  SAS data step merge would require rounding or something else, if your datetimes are very precise (ie, have microseconds or beyond in them). ... View more

Depends on your data and how it's produced. First off, SAS's precision is 2^53, aside from the floating point.  However, DATETIME is a number in the billions usually (# of seconds since 1/1/1960 is about 1.7 billion), which is about 2^31.  So you really have about 2^22 more precision available in the decimal; that works out to about microseconds in a datetime.  (This is because SAS stores in a 64 bit floating point number 1 sign bit, 11 exponent bits, and 52 bits for the mantissa, which can store up to 2^53 accurately.)  This is all assuming you're on an IEEE system, ie, Intel, Windows/Unix, etc.  If you're on a mainframe it's a bit different. This example shows about how the precision works: data test; format dtval dtval_test DATETIME23.6; dtval=datetime(); do _pow = -1 to -15 by -1;   dtval_test = dtval - 10**_pow;   diff = dtval-dtval_test;     put "Difference:" dtval= dtval_test= diff= 18.16 _pow=; end; run; It stops working (stops having a difference) at 10^-7, which would be tens of millions.  That's where you completely lose precision, ie, SAS won't even consider a difference of 1x10-7 to be a difference. Before that, the difference seems good to about that spot: for 10^-1, diff is 0.0999999046 for example (this is for datetime when I ran this, actual difference may vary some).  Further on that is approximately consistent; around the 7th or 8th digit it diverges from where it should be.  The first six digits after the decimal are 'right', the seventh is often but not always right. This is all contingent on using datetimes approximately like this year's datetimes.  If you are using time or datetime intervals, ie, values that are pretty small on the left side of the decimal, you can be much more precise.  Basically consider 15 significant digits on either side of the decimal and you're okay.  Nanoseconds in times should be fine for example (left has at most 5 digits, right can have 10 safely).   If you're solely looking at intervals, and there isn't any left side of the decimal, you can have up to 39 digits after the decimal in theory according to the datetime format (though I don't highly recommend doing that). Reference: SAS(R) 9.2 Language Reference: Concepts, Second Edition ... View more

Certainly understand not putting the macro in the paper (and wasn't suggesting it should've been).  My issue is precisely the converse of what you said: I don't see why it should be necessary to learn another language (PROC DOCUMENT), when the structure could be trivially represented in a dataset form, and as such made accessible to data step manipulations (which are simple, powerful, and most SAS programmers will find them comfortable to do). In your example in your paper, if there were a dataset, it would've been easy to simply say: data from_ods_document; length path $100; input path $; datalines; \work.mydoc\Means#1\ByGroup1#1\Summary#1 \work.mydoc\Means#1\ByGroup2#1\Summary#1 \work.mydoc\Means#1\ByGroup3#1\Summary#1 \work.mydoc\SGPlot#1\ByGroup4#1\SGPlot#1 \work.mydoc\SGPlot#1\ByGroup5#1\SGPlot#1 \work.mydoc\SGPlot#1\ByGroup6#1\SGPlot#1 ;;;; run; data to_ods_document; set from_ods_document; path = '\'||catx('\',scan(path,1,'\'),scan(path,3,'\'),scan(path,2,'\'),scan(path,4,'\')); run; proc document update=work.mydoc cntlin=to_ods_document; run; quit; Seems easier than having to write a macro to do all of that '^^' stuff.  I imagine the dataset would be richer than just a path variable, but honestly just a path variable would be entirely fine by me. Anyway, I was largely asking to see if this was possible now in case I'd missed something; as it seems it's not, I'll make a sasware ballot suggestion and see how many ODS DOCUMENT users would find it useful (or how many there are?).  For me not having dataset-level access is a big barrier to using it - not sure if that's true elsewhere but worth seeing. ... View more

Would help to have useful code, but that error suggests you are re-using a variable name, once as COMPUTED once as something else (say, ORDER or DISPLAY or GROUP or ANALYSIS or ACROSS, etc.).  ... View more

Thanks, Cynthia.  I ended up doing it the hard way, deciding where to break pages on my own and breaking on those variables, but if I have time in the future I'll talk to tech support.  I was indeed using CSSSTYLE in the ODS PDF, and am a big fan of such. ... View more