BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
mchiappe83
Obsidian | Level 7

Hi Everyone,

 

I have a code that, if ran manually (n times in a row) in SAS Guide performs perfectly well. Now, if I try to execute this code in DIS, it comes up with errors from the second time it is run. Any idea of what may be happening?

 

Many thanks,

Martín

1 ACCEPTED SOLUTION

Accepted Solutions
Kurt_Bremser
Super User

When something unexpected happens, the log is your sole authority in determining what went wrong, as it reflects the code that was actually executed, period. Base(!) SAS does not "invent" phantom statements on its own. So you need to investigate where that erroneus libname statement comes from, and remove it. Until you do that, the code will not work.

 

But I think I see where this is coming from. Log line 228 (the erroneous libname) is in a code part that seems to be automatically created by DI Studio. This part is inserted between your program code (delta-automotor.sas) lines 67 (which corresponds to log line 193) and 70 (which corresponds to log line 958). So you see there's almost 800 lines of code created that are not part of the code you see.

Maybe one of the DI Studio experts can come up with an idea why that libname appears "out of the blue".

If none of the posters here can come up with an idea that helps, I am afraid (as I do not work with DI Studio, it's not even installed here) I can only refer you to SAS technical support. Make sure you point them to the problem point so they do not need to find it on their own.

 

As a workaround, you could insert a correct libname statement immediately before code line 70, so that it overrides the wrong one. And you need to investigate which mechanism makes DI Studio insert that additional code. Is it because the code you showed is actually compiled from several nodes in a DI Studio project/flow?

 

View solution in original post

19 REPLIES 19
LaurieF
Barite | Level 11

(Edited) log please?

mchiappe83
Obsidian | Level 7

Thanks a lot for your response. Please see the both the code and log attached. Let me know your thoughts.

LaurieF
Barite | Level 11

It's too much to go through. Can you edit it down to just the bits around the error? say the data/proc steps either side?

mchiappe83
Obsidian | Level 7

No problem. The first error occurs in the following step:

 

958 proc sql ;
959 insert into xxxx.STG_SPESERV_PADRON_AUTO
960 select * from z.XDAUTO
961 WHERE PUT(F_LOG, 8.)||put(H_LOG,Z6.) > put(&fecha,Z14.);
ERROR: The file Z.XDAUTO.DATA does not exist.
NOTE: PROC SQL set option NOEXEC and will continue to check the syntax of statements.
962 quit;
NOTE: The SAS System stopped processing this step because of errors.

 

The file XDAUTO is being deleted in the very beggining of the code, in order to ensure there's nothing called this way when creating this file inmediately after. Then, the error stated above occurs. At the end of the code, the file is being deleted again in orden to leave the directory clean for the next execution of the code.

 

Let me know If you followed me.

Many thanks

Tom
Super User Tom
Super User

I don't understand.  You deleted the file and then tried to write to it and are surprised it caused an error?

 

I don't see anything in the log where it worked once or where the file is created.

If you deleted it then you need to create it again before you can use INSERT to put records into it.

 

mchiappe83
Obsidian | Level 7

Thanks @Tom for your response. 

 

The file that is being reported in the error is being created in a previous step, inside LIBNAME DATOS '/u/SAS/datos';

 

Then LIBNAME DATOS '/u/SAS/datos' is being renamed with the sentence libname z "/u/SAS/datos" SERVER=ts12 so I expect that the file reported in the error is contained in this new libname. 

 

Are my thoughts correct? Many thanks, 

Martin

Tom
Super User Tom
Super User

@mchiappe83 wrote:

Thanks @Tom for your response. 

 

The file that is being reported in the error is being created in a previous step, inside LIBNAME DATOS '/u/SAS/datos';

 

Then LIBNAME DATOS '/u/SAS/datos' is being renamed with the sentence libname z "/u/SAS/datos" SERVER=ts12 so I expect that the file reported in the error is contained in this new libname. 

 

Are my thoughts correct? Many thanks, 

Martin


Z is a different libref than DATOS, even if they are both ultimately pointing to the same physical location.

Make sure the code is using the libref that is active.

mchiappe83
Obsidian | Level 7

Z is a different libref than DATOS, even if they are both ultimately pointing to the same physical location.

Make sure the code is using the libref that is active

How can I make sure of this?

 

Thanks,

Martin

 

 

 

Kurt_Bremser
Super User

@mchiappe83 wrote:

Thanks @Tom for your response. 

 

The file that is being reported in the error is being created in a previous step, inside LIBNAME DATOS '/u/SAS/datos';

 

Then LIBNAME DATOS '/u/SAS/datos' is being renamed with the sentence libname z "/u/SAS/datos" SERVER=ts12 so I expect that the file reported in the error is contained in this new libname. 

 

Are my thoughts correct? Many thanks, 

Martin


You have here a fundamental misunderstanding of what happens where.

LIBNAME DATOS '/u/SAS/datos'; is being executed during an rsubmit to the remote server, so a local assignment using the BASE engine works.

libname z "/u/SAS/datos" SERVER=ts12; is executed in the local context, but uses the REMOTE engine to the server, so it works also.

But LIBNAME Z BASE "/u/SAS/datos"; is used once again in the local context (not during an rsubmit!) without specifying the server, and so it fails, as that path is not available in your local SAS session. That failed libname effectively clears the libref for Z. Either remove that statement (and keep on using the previously successfully assigned remote library), or specify the server.

mchiappe83
Obsidian | Level 7

Hi @Kurt_Bremser

Thanks a lot for your guidance

But LIBNAME Z BASE "/u/SAS/datos"; is used once again in the local context (not during an rsubmit!) without specifying the server, and so it fails, as that path is not available in your local SAS session. That failed libname effectively clears the libref for Z. Either remove that statement (and keep on using the previously successfully assigned remote library), or specify the server.

 

I'm not being able to understand where does  LIBNAME Z BASE "/u/SAS/datos" happens, as there's no place in the code where I write it down strictly that way.

 

From the log, it seems to have place before the following piece of code:

 

proc sql;
 insert into xxxx.STG_SPESERV_PADRON_AUTO
	select * from  z.XDAUTO 
	 WHERE PUT(F_LOG, 8.)||put(H_LOG,Z6.) > put(&fecha,Z14.);

But there's nothing like LIBNAME Z BASE "/u/SAS/datos" there.

 

Thanks,

Martin

 

 

 

Thanks again for your time.

Martin

 

Kurt_Bremser
Super User

@mchiappe83 wrote:

Hi @Kurt_Bremser

Thanks a lot for your guidance

But LIBNAME Z BASE "/u/SAS/datos"; is used once again in the local context (not during an rsubmit!) without specifying the server, and so it fails, as that path is not available in your local SAS session. That failed libname effectively clears the libref for Z. Either remove that statement (and keep on using the previously successfully assigned remote library), or specify the server.

 

I'm not being able to understand where does  LIBNAME Z BASE "/u/SAS/datos" happens, as there's no place in the code where I write it down strictly that way.

 

Thanks again for your time.

Martin

 


Look at the log. I gave you all log line numbers.

mchiappe83
Obsidian | Level 7

Thanks @Kurt_Bremser

Look at the log. I gave you all log line numbers.

 

I did, but I can't figure out why LIBNAME Z BASE "/u/SAS/datos"; is automatically being generated if libname z "/u/SAS/datos" SERVER=ts12; is created inmediately before. 

 

Is it for the PROC SQL?

 

Best,

Martín

Kurt_Bremser
Super User

The crucial error happens earlier:

228        LIBNAME Z BASE "/u/SAS/datos";
NOTE: La librería Z no existe.

Previously, you used a remote connection for library Z:

184        libname z "/u/SAS/datos" SERVER=ts12;
NOTE: Libref Z was successfully assigned as follows: 
      Engine:        REMOTE 
      Physical Name: /u/SAS/datos
mchiappe83
Obsidian | Level 7

Thanks @Kurt_Bremser

Let me understand your point and then I share my thought.

 

You say the crucial error comes with the following sentence in the code:

 

libname z "/u/SAS/datos" SERVER=ts12; 

 

And that, previously, I'm using a remote connection. 

 

In the code this sentence is being used only once and:

1) the very first thing the log informs is that Libref Z was successfully created

2) then, in line 228, the log informs that library Z does not exist -what I don't understand just because of 1)-

3) when ran manually this code in SAS Guide, over and over again, no error shows up. 

 

Please let us know your thoughts. I appreciate your help very much.

Martin

 

sas-innovate-2024.png

Join us for SAS Innovate April 16-19 at the Aria in Las Vegas. Bring the team and save big with our group pricing for a limited time only.

Pre-conference courses and tutorials are filling up fast and are always a sellout. Register today to reserve your seat.

 

Register now!

How to connect to databases in SAS Viya

Need to connect to databases in SAS Viya? SAS’ David Ghan shows you two methods – via SAS/ACCESS LIBNAME and SAS Data Connector SASLIBS – in this video.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 19 replies
  • 1549 views
  • 4 likes
  • 4 in conversation