01-02-2015 03:25 PM
I've got a macro that either produces one DATASTEP output or two DATASTEP outputs to an ODS DOCUMENT store, which then I need to copy up to another node. Something like this (code at end of question), except instead of specifying both lines, I'd like to be able to specify
move \DataStep#* to ^;
or something like that, because sometimes I only have one of the two datasteps.
Is this possible? I found a reference to a paper from SUGI 27 noting that wildcards were under consideration, but nothing after that...
ods _all_ close;
ods document name=test(write);
define table work.nameage;
text "NAME AND AGE";
column name age;
define table work.nameheightweight;
text "NAME HEIGHT WEIGHT";
column name height weight;
file print ods=(template='work.nameage');
file print ods=(template='work.nameheightweight');
ods document close;
proc document name=test;
move \DataStep#1 to ^;
move \DataStep#2 to ^;
ods pdf file="c:\temp\test.pdf";
ods pdf close;
01-02-2015 08:31 PM
Have you tried a version of the WHERE syntax (as shown for REPLAY at the end of this paper https://support.sas.com/resources/papers/sgf09/318-2009.pdf? My initial thought when reading your question was to use WHERE. I believe that the ability to select objects is only supported using the WHERE syntax, but with CONTAINS as an operator, that gives you the equivalent ability to a wildcard. But that should give you enough flexibility to do what you want.
move ^(where=(_path_ contains 'DataStep#')) to ^; (or something close)
Personally, I'd try to get the syntax working with REPLAY first and then try it with MOVE.
As far as I know, the WHERE support was added in SAS 9.2. I do not believe you can use a simple * as the wildcard, but that would be a question for Tech Support.
01-05-2015 04:43 PM
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!
01-06-2015 12:08 AM
I think that before you abandon using the WHERE, it might be a good idea to open a track with Tech Support. Knowing the right directory structure for the MOVE will be critical. For what it's worth, I find it best to leave the original (starting) document store intact. Then I always make a NEW empty document store and then I have to deal only with the COPY command. And, I am always in control of the directory for the copy because I can always use the DIR command to place the copy pointer at the root and then navigate down from the top. It may be superstitious, but I always start at the top and navigate to where I want to go and I always use a COPY from the original into the new document store.
Tech Support can look at your data and your code and figure out where you are going wrong with the WHERE. And if what you want cannot be done then they might have a workaround to suggest.
01-06-2015 01:15 PM
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.