DATA Step, Macro, Functions and more

Signin-Signoff blicks inside a macro invoked from local session

Accepted Solution Solved
Reply
Occasional Contributor
Posts: 5
Accepted Solution

Signin-Signoff blicks inside a macro invoked from local session

Doing something strange.  I put 2 successive signon-rsubmit-endrsubmit-signoff blocks INSIDE of a macro.  Macro variables assigned using %let are not resolving inside the second block.  Everything in first block seems to execute OK.  Stuff in second block also runs, but I cannot resolve macro variables.  That code is just skipped. Can't find any documentation on whether or not you can even do this.

(I'm doing this because my remote session keeps timing out if I do everything at once.  I know it is not normal to use signon INSIDE a macro)

%macro my_macro;

     signon; rsubmit;

          /* bunch of code */

     endrsubmit; signoff

     signon; rsubmit;

          /* bunch of code */

          %let i = 2;

          /* Code beyond here will not recognize i as a macro variable. */

          %put &i.;               /* Not resolving */

     endrubmit; signoff;

%mend my_macro;

%my_macro;


Accepted Solutions
Solution
‎11-22-2012 06:23 PM
Super User
Posts: 3,100

Re: Signin-Signoff blicks inside a macro invoked from local session

Just a thought, but wouldn't it be better to solve the remote SAS server timeout problem rather than trying to code around it? The reason I say this is we had a very similar problem recently and discovered that the reason for the timeouts is that our SAS server sits behind a firewall and it was the TCP ports on the firewall that were timing out. A quick chat to one of our IT network staff confirmed what was going on and a change was implemented to extend the timeout period on the firewall ports. Problem solved.

View solution in original post


All Replies
Super User
Posts: 5,254

Re: Signin-Signoff blicks inside a macro invoked from local session

Without the complete code/log it's hard to say anything about resolving.

There seems to be a ; missing after the first signoff...

Data never sleeps
Occasional Contributor
Posts: 5

Re: Signin-Signoff blicks inside a macro invoked from local session

Sorry for the missing ;    My general question was that "can you put signon-rsubmit statements inside a macro invoked from local session.  The simi-pseudo code I provided was not the actual code I ran. 

Do you know if documentation that addresses issue of placing signon and rsubmit commands inside a macro?

Thanks for your help.

Michael

Super User
Super User
Posts: 6,495

Re: Signin-Signoff blicks inside a macro invoked from local session

The issue of when macro statements like %LET evaluate can be tricky when combining macros with rsubmit blocks.

You might need to resort to work arounds.

Usually I use %SYSLPUT to create the macro variables in the remote environment.

signon;

%syslput i=2;

rsubmit;

  ...

endrsubmit;

Also look at this thread where the programmer ended up using a renamed version of the old SYSLPUT macro from versions of SAS from before the introduction of the %SYSLPUT macro statement. 

Another technique is to move the information in datasets instead.  You could then use CALL SYMPUTX in a datastep on the remote side to populate the macro variable in the remote environment.

Occasional Contributor
Posts: 5

Re: Signin-Signoff blicks inside a macro invoked from local session

Tom.

Thanks for the input.  Are signon and rsubmit statements used inside macros really the norm?  It is in the second signon block where the troubles begin.  Everything resolves just fine.  But down in the second block, procedures and data steps are running before %let and %do statements even though %let and %do appear first.  Very strange.  I don't think it is a synchronous nonsynchronous thing.  

Again.  I'm looking for any SAS documentation talking about Signon and Rsumbit inside a macro.  Have only seen one other posting on the issue.  He was having same problem I am.  But in his case, Signon and Signoff were outside macro and only Rsubmit and endrsubmit were inside:

     signon;

          %macro my_macro;

               rsubmit;

               < stuff >

               endrsubmit;

          %mend;

     signoff;

Super User
Super User
Posts: 6,495

Re: Signin-Signoff blicks inside a macro invoked from local session

SIGNON/SIGNOFF are executable and %MACRO/%MEND are just to define the macro.  To run the macro you need to call it.  In general it would be clearer to move the macro definitions to before the executable code (or put them in an autocall library).  Your example should look more like:


%macro my_macro;

rsubmit;

  < stuff >

endrsubmit;

%mend;

signon;

%my_macro;

signoff;

%DO/%END will control the execution of the macro.  So they will NOT be executing in the remote session. Instead the code that they generate might be sent to the remote session if you have an open RSUBMIT/ENDRSUBMIT block.

It is the %LET that I am not sure whether it could execute in either the local session or the remote session. In general I suspect that they will execute in the local session.  If you want them to execute in the remote session then you probable need to use %NRSTR() to protect the %LET keyword.

Occasional Contributor
Posts: 5

Re: Signin-Signoff blicks inside a macro invoked from local session

Tom:

Still looking for documentation regarding SIGNON/SIGNOFF commands inside a macro.  When two such blocks appear one after the other inside a macro, execution of code inside first seems normal.  Inside the second, proc and data steps seem to execute before %let and %do statements even though macro statements appear first.  Very strange. 

Solution
‎11-22-2012 06:23 PM
Super User
Posts: 3,100

Re: Signin-Signoff blicks inside a macro invoked from local session

Just a thought, but wouldn't it be better to solve the remote SAS server timeout problem rather than trying to code around it? The reason I say this is we had a very similar problem recently and discovered that the reason for the timeouts is that our SAS server sits behind a firewall and it was the TCP ports on the firewall that were timing out. A quick chat to one of our IT network staff confirmed what was going on and a change was implemented to extend the timeout period on the firewall ports. Problem solved.

☑ This topic is SOLVED.

Need further help from the community? Please ask a new question.

Discussion stats
  • 7 replies
  • 314 views
  • 3 likes
  • 4 in conversation