SAS VA Data Load Error

[Matt]

 Hello,

 I am trying to load data into LASR and running into issues. Any help is much appreciated.

 Here is the code I start LASR with

libname VALIBLA sasiola startserver=
(
PATH="/opt/sas/config/Lev1/AppData/SASVisualAnalytics/VisualAnalyticsAdministrator/sigfiles"
)

host="XXXXX-VAApplicationServer" port=10011
signer="http://XXXXXXXXXXXX-MidTier:7980/SASLASRAuthorization"
;
run;

data VALIBLA .mattt;
set sashelp.class;
run; 

 
Error:-

 Hello,

 I am trying to load data into LASR and running into issues. Any help is much appreciated.

 Here is the code I start LASR with

libname VALIBLA sasiola startserver=
(
PATH="/opt/sas/config/Lev1/AppData/SASVisualAnalytics/VisualAnalyticsAdministrator/sigfiles"
)

host="XXXXX-VAApplicationServer" port=10011
signer="http://XXXXXXXXXXXX-MidTier:7980/SASLASRAuthorization"
;
run;

data VALIBLA .mattt;
set sashelp.class;
run; 

 
Error:-

NOTE: There were 19 observations read from the data set SASHELP.CLASS.
NOTE: The data set VALIBLA.MATT has 19 observations and 5 variables.
ERROR: Member or library VALIBLA.MATT.DATA unavailable for use.

[alexal]

@Matt,

Have you reconfigured SAS Visual Analytics? 

[Matt]

Not yet since it's a long process of getting multiple approvals so trying different ways. So far I am able to bring up LASR, I was able to load the data as well on Friday and now it throws me the error I sent earlier. Any idea?

[alexal]

@Matt,

It could be anything. You need to get back to the correct server names as soon as possible. Anyway, have you seen any errors in the LASR Authorization Service Log - SASLASRAuthorization7.<X>.log? That file usually located in SASServer12_1, not sure where is that file in your configuration.

[Matt]

I agree, we are working on getting required approvals.

I saw few errors in SASLASRAuthorization7.4.log. Sent you all via track # 7612329268. Please let me know if you have any solution. 

[FredrikE]

We had something almost like you and solved it with this:

In the sas code we added following option:
options set=GRIDRSHCOMMAND="/usr/bin/ssh -q -o StrictHostKeyChecking=no";
Now we got a successful remote load to LASR Server.

Later also we updated sasenv_local (on the source server) file for SAS Foundation with following environment variable (removing “options  set=GRIDRSHCOMMAND…” from the sas code): 
export GRIDRSHCOMMAND="/usr/bin/ssh -q -o StrictHostKeyCheck-ing=no"
Also a successful remote loading to LASR Server after this.

Any help?

🙂

//Fredrik

[Matt]

No help. Our VA platform is a non distributed. Here are the syntax that assigns library but not able to load data to LASR.

options set=GRIDRSHCOMMAND="/usr/bin/ssh -q -o StrictHostKeyChecking=no";

libname VATEST sasiola startserver=

( PATH="/opt/sas/config/Lev1/AppData/SASVisualAnalytics/VisualAnalyticsAdministrator/sigfiles" )

host="xxxxxVAAppServer" port=10011 signer="xxxxMidTierServer:7980/SASLASRAuthorization" ;

run;

options set=GRIDRSHCOMMAND="/usr/bin/ssh -q -o StrictHostKeyChecking=no"; LIBNAME VAT SASIOLA TAG=HPS PORT=10011 HOST="xxxxVAAppServer" SIGNER="http://xxxMidTierServer:7980/SASLASRAuthorization" ;

data VAT.t_2;

set sashelp.cars;

run;

NOTE: There were 428 observations read from the data set SASHELP.CARS. NOTE: The data set VAT.T_2 has 428 observations and 15 variables. ERROR: Member or library VAT.T_2.DATA unavailable for use. NOTE: DATA statement used (Total process time): real time 2.11 seconds user cpu time 0.02 seconds

[Matt]

@FredrikE,

It appears the options you provided is working now but don't understand the way it works. The way it worked for me is.

(1) It accepts below libname statement and starts the VA LASR. If I try to use libref VATEST while loading the data, it fails with member or library dataset name is unavailable for use. It only works if I create another library with different libname statement and libref. See below steps for more details

options set=GRIDRSHCOMMAND="/usr/bin/ssh -q -o StrictHostKeyChecking=no";
libname VATEST sasiola startserver=
(
PATH="/opt/sas/config/Lev1/AppData/SASVisualAnalytics/VisualAnalyticsAdministrator/sigfiles"
)

host="xxxSASAppVA" port=10011
signer="http://xxxxMidTier:7980/SASLASRAuthorization"
;
run;

(2) Then it requires me to run another libname statement with a different libref

options set=GRIDRSHCOMMAND="/usr/bin/ssh -q -o StrictHostKeyChecking=no";
LIBNAME VAL SASIOLA TAG=HPS PORT=10011 HOST="xxxxSASAppVA"
SIGNER="http://xxxxMidTier:7980/SASLASRAuthorization" ;

(3) Then only it allows me to load the data. 

data VAL.t_1;
set sashelp.cars;
run;

NOTE: There were 428 observations read from the data set SASHELP.CARS.
NOTE: The data set VATEST.T_1 has 428 observations and 15 variables.
NOTE: DATA statement used (Total process time):
real time 9.46 seconds
user cpu time 0.05 seconds
system cpu time 0.06 seconds

[FredrikE]

Have you tried to add it to the starup script (sasenv_local) ?

Maybe there is some problem when starting the server and adding the option, maybe it works if it already are defined in the script?

//Fredrik

[Matt]

Added to sasenv_local and sasv9_local.cfg but still same behavior.

[FredrikE]

Hm, I don't understand the "startserver=" in the first libname, isn't the LASR-server started already?

I mean, is there a need to start it with a Libname?

//Fredrik

[Matt]

That is the only way LASR is starting. Neither it starts with SAS VA Admin console nor it starts by assigning library. The way it starts in our environment is with the program. First program start server and then assign a libname with different libref.

Are you familiar with any other ways to bring up LASR? I mean with a script etc....

[SASKiwi]

There is something wrong if you can't start the LASR servers from the SAS VA Administrator. This is probably the most common way to do this. What happens when you try to start the LASR servers? If it is not working then usually an error message is displayed. 

[alexal]

@SASKiwi,

There is something wrong if you can't start the LASR servers from the SAS VA Administrator. 

Yes, they have changed names for the web servers. For all of them.

[SASKiwi]

Ah, thanks for pointing out the connection to @Matt's other post.