LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (March 2000, week 1)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Tue, 7 Mar 2000 15:08:55 -0000
Reply-To:     "Vyverman, Koen" <koen.vyverman@FID-INTL.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         "Vyverman, Koen" <koen.vyverman@FID-INTL.COM>
Subject:      Re: Problem handling rsubmit/endrsubmit logic with macro variable
              s
Comments: To: "List SAS-L (E-mail)" <sas-l@uga.cc.uga.edu>
Content-Type: text/plain; charset="iso-8859-1"

LS,

A fix exists to the problem I outlined earlier today. An ugly one, but it works... Thanks to David Johnson for pointing out to me that the trouble seems to be caused by the fact that my &remotoff variable resolves to 'endrsubmit' as expected, but in the remote SAS-session rather than the local session. Whereupon the remote session coughs up the error, as it is unaware of any rsubmitting going on.

The following makes the program run as desired, but leaves me dissatisfied as in half the cases it will dump an error-message in the log, also when things actually went exactly the way I wanted it:

Instead of coding &remoton; data ...; ...; run; proc ...; ...; run; ... &remotoff; I decided to use only the &remoton variable, and hardcode an endrsubmit on every occasion: &remoton; ...same heaps of code... endrsubmit;

Whenever &remoton resolves to 'rsubmit', the code runs in the remote SAS session, and nicely relinquishes control again to the local session.

When, on the other hand, &remoton resolves to a blank, the code runs locally, then generates a 'Statement is not valid...' error upon encountering the superfluous endrsubmit. Nevertheless, the code runs, and leaves the local session in control for more.

Unless there's a way to use &remotoff and have it resolve in the local session, I suppose I'll have to live with it. Another option would be to write code to an ascii file or a source catalog entry with all the macro variables resolved, and then %include. Also a bit of a pain in this case...

Regards,

Koen Vyverman Fidelity Investments Luxembourg.

> -----Original Message----- > From: Vyverman, Koen > Sent: Tuesday, March 07, 2000 12:55 PM > To: SAS-L@LISTSERV.UGA.EDU > Subject: Problem handling rsubmit/endrsubmit logic with macro > variables > > > LS, > > I'm probably being fooled here by a combination of SAS/CONNECT > fine-print and macro processor behaviour. I can't seem to find > out what goes awry in the following... > > A simplified description of the situation: I have a number of > fairly large data sets (1M+ obs), identically structured, with > a number of analysis variables on each. Some of these data sets > live on my PC (Win95), others on a UNIX box. I want to perform > the same analyses on all data sets, therefore I wrap my code up > in a macro, say, %testit. > > In view of the size of the data sets, I would rather not up- or > down-load any of them, so the problem I'm confronted with is how > to get my %testit macro to submit some of its code in the local > (pc) SAS-session, and some of its code remotely, while avoiding > wallpaper programming. > > An elegant way of doing this suggested itself in the form of two > macro variables, &remoton and &remotoff. These would be set to > blanks when code needs to be submitted locally, and to 'rsubmit', > resp. 'endrsubmit', when code needs to be processed remotely. > Sandwiching a data step as follows > &remoton; > data _foo; > set _bar; > ... > run; > &remotoff; > would then either run locally (with both &remoton and &remotoff > resolving to ' ') or remotely (with &remoton resolving to 'rsubmit' > and &remotoff resolving to 'endrsubmit'). > > It does not work, there must be a flaw in either the idea or the > design. Or both? Below is some sample code showing what I'm trying > to achieve: > > ================================================================== > LOG resulting from sample code > ================================================================== > > 165 %* Whether a chunk of code needs to run locally or remotely *; > 166 %* is determined by the value of &RUNWHERE, which can be *; > 167 %* either PC (local) or UNIX (remote). *; > 168 %macro testit(runwhere=); > 169 > 170 %local remoton remotoff; > 171 > 172 %* Set both to blank in the local SAS session. *; > 173 %let remoton=; > 174 %let remotoff=; > 175 > 176 %* Set both to blank in the remote SAS session. *; > 177 data _null_; > 178 call symput('remoton',' '); > 179 call symput('remotoff',' '); > 180 run; > 181 > 182 %if (&runwhere=UNIX) %then %do; > 183 > 184 %* Change the values in the local SAS session. *; > 185 %let remoton=rsubmit; > 186 %let remotoff=endrsubmit; > 187 > 188 %* Change the values in the remote SAS session. *; > 189 rsubmit; > 190 data _null_; > 191 call symput('remoton','rsubmit;'); > 192 call symput('remotoff','endrsubmit;'); > 193 run; > 194 endrsubmit; > 195 > 196 %end; > 197 > 198 %* Now try it... A data set WORK._EEK should appear in *; > 199 %* either the remote or the local SAS session. *; > 200 &remoton; > 201 data _eek; > 202 length xxx yyy $30.; > 203 xxx="***&remoton***"; > 204 yyy="***&remotoff***"; > 205 run; > 206 &remotoff; > 207 > 208 %mend testit; > 209 > 210 > 211 %testit(runwhere=UNIX); > > NOTE: The DATA statement used 0.33 seconds. > > NOTE: Remote submit to MYNODE commencing. > 5709 data _null_; > 5710 call symput('remoton','rsubmit;'); > 5711 call symput('remotoff','endrsubmit;'); > 5712 run; > > NOTE: DATA statement used: > real time 0.030 seconds > cpu time 0.009 seconds > > NOTE: Remote submit to MYNODE complete. > NOTE: Remote submit to MYNODE commencing. > 5713 data _eek; > 5714 length xxx yyy $30.; > 5715 xxx="***&remoton***"; > 5716 yyy="***&remotoff***"; > 5717 run; > > NOTE: The data set WORK._EEK has 1 observations and 2 variables. > NOTE: DATA statement used: > real time 0.140 seconds > cpu time 0.013 seconds > > 5718 &remotoff; > NOTE: Line generated by the macro variable "REMOTOFF". > 5718 endrsubmit; > ---------- > 180 > > ERROR 180-322: Statement is not valid or it is used out of > proper order. > > 5719 ; > NOTE: Remote submit to MYNODE complete. > > ================================================================== > END LOG > ================================================================== > > As can be seen in the above log, &remoton _does_ cause the remote > submit to commence, but &remotoff somehow fails to end it properly. > The WORK._EEK data set gets created in the remote SAS session. > > Can anyone spot the blunder or shed any light on the problem? > > Many thanks, > > Koen Vyverman > Fidelity Investments > Luxembourg. >


Back to: Top of message | Previous page | Main SAS-L page