Library does not display in second run when using rsubmit

Posts: 21

Library does not display in second run when using rsubmit


Good day to you. I'm seeking advice pertaining a query on an issue when we using macro code in EG.

I found out when I run the macro code runs once in EG, it able to assign the 3 libraries in the EG.

Macro Code:-


options comamid=tcp;

%let ServerA_IP= 7551;

signon ServerA_IP user="sasdemo" password =  "43AD89DD822CA28F1";

rsubmit ServerA_IP;

%let TD_IP = '';

%let userid = B20017;

%let pwd = '{SAS002}C400';


%macro tdassign(tdlib,db);



rsubmit ServerA_IP;

libname &tdlib TERADATA user=&USERID password=&pwd server=&TD_IP database=&db;


libname &tdlib slibref= &tdlib server=ServerA_IP;






It manage to create the following libraries and able to view it as shown on attachment.

As can be seen on the screen, the libraries name TDAS400, TDGL and TDCARD is listed out. .

However, if the macro is re-run again in the same session, only the last library gets assigned, in this example, TDCARD even though in the log file stated that all 3 libraries have been successfully assigned. Screen shot included in the attachment.

Is there anyway to circurvent this problem? Do they need to change the macro code or do they need to reopen a new session to enable the macro to runs?

Your advise on this issue is appreciated

Posts: 21

Re: Library does not display in second run when using rsubmit

Posted in reply to mikesatriaevo

Hi, Anyone can help me on this issue?

Trusted Advisor
Posts: 3,215

Re: Library does not display in second run when using rsubmit

Posted in reply to mikesatriaevo

Mike, I missed this one the first time. When I would have seen it I would have reacted the first time and fast....

It is a interesting area I have done a lot. It is the grandfathers approach of grid and threading using SAS/connect.

The SAS support staff is avoiding this more technical challenge by my experience. 

So what is happening (comments first) .

- I see SAS/connect usage to 1 server. For shame no DNS-naming approach but hard codes ip-numbers,

  That could be improved.

  Would be better to set up some standards on that. Standard macros to be uses at startup of SAS.

- I don not see whether you are using async or sync processing.  Sync processing was the only option with SAS V6.

  Starting wiht SASV8 you can do async processing. Starting with SAS V9 you can do MP-connect  (no ip adressing but, script in same machine).      

  I would personally prefer Async processing and using rget waitfor risplay for synchroisation points.

  It is the options connectwait / noconnectwati

  SAS/CONNECT(R) 9.4 User's Guide (rsubmit command options)

- The sigon approach also has changed. More can be done in a more easy way. But the SLIBREF and SYSLPUT are still necessary basics

  SAS/CONNECT(R) 9.4 User's Guide (signon statement) See

The Slibref (Connect_ can be found on:

   SAS/CONNECT(R) 9.4 User's Guide (slibref connect)

   Base SAS(R) 9.4 Procedures Guide (slibref in proc migrate)

I had also some problems with the technical aspects in these function that never have been satisfied well although SAS tracks have been made.

This is the area where timing of the different sessions is important.  Timing issues are difficult to recognize an even more difficult to solve.

With SYNC processing there is continously polling between the local session (SAS-pc) and server-side.

When something fails in that unpredictable results can occur.  Missing settings (pagesize) or not executing something. (library allocation).

With ASYNC processing there is no polling.  The local session is free and synchronizing is done by yourself. What can happen is that pop-ups are coming in the wrong order.

That is no big logical failure unless the screen that should filled in first has become unreachable, By that the logical flow has got blocked.    

As said sadly got both of them.

The best way to get a reliable system is to set up everything at the start of the session and do not change it anymore thereafter.

In this case the timing problem could be caused by reassigning the libraries at the server-side and not first freeing up the slibref at the client side.

The slibref is connected and should get disconnected by the second action.   

---->-- ja karman --<-----
Ask a Question
Discussion stats
  • 2 replies
  • 2 in conversation