In lines 176 to 178 you sign on to a r4emote SAS/CONNECT server, which is running on z/OS:
176 %let ts12=host.test.arba.gov.ar 7541; 177 options comamid=tcp remote=ts12; 178 signon user="consusas" password=XXXXXXXXX;
From log line 182 you remote submit code to that server, which returns 45 lines of its log before the rsubmit ends.
In log line 184 you assign a library Z via RLS to that CONNECT server:
184 libname z "/u/SAS/datos" SERVER=ts12; NOTE: Libref Z was successfully assigned as follows: Engine: REMOTE Physical Name: /u/SAS/datos
which obviously succeeds.
In log line 228 you have another libname statement, which tries to assign library Z with a local path (no server specified as in line 184):
228 LIBNAME Z BASE "/u/SAS/datos"; NOTE: La librería Z no existe.
which fails, as can be seen by the NOTE. This leaves you with an unassigned library Z, so all future references to datasets in library Z will fail.
This non-existence of library Z causes the ERRORs happening from log line 958:
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: El archivo Z.XDAUTO.DATA no existe. 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. NOTE: SAS set option OBS=0 and will continue to check statements. This might cause NOTE: No observations in data set.
You now have no dataset xxxx.STG_SPESERV_PADRON_AUTO, and since OBS=0, and SAS has gone into syntax check mode, you have NOEXEC in the SQL following later:
1240 proc sql; NOTE: PROC SQL set option NOEXEC and will continue to check the syntax of statements. 1241 1242 select max(f_log) INTO :HOY from xxxx.STG_SPESERV_PADRON_AUTO; NOTE: Statement not executed due to NOEXEC option. 1243 select max(h_log) into :hora from xxxx.STG_SPESERV_PADRON_AUTO where f_log = (select max(f_log) from 1243 ! xxxx.STG_SPESERV_PADRON_AUTO ); NOTE: Statement not executed due to NOEXEC option. 1244 1245 1246 UPDATE xxxx.parametro_procesamiento AS a 1247 SET fecha_ult_ejec = put(&hoy, 8.) || put(&hora, z6.), _ 22 WARNING: Apparent symbolic reference HOY not resolved.
which also causes that no macro variables are created. From then on, all hell breaks loose, for obvious reasons.
In log line 228 you have another libname statement, which tries to assign library Z with a local path (no server specified as in line 184):
228 LIBNAME Z BASE "/u/SAS/datos"; NOTE: La librería Z no existe.which fails, as can be seen by the NOTE. This leaves you with an unassigned library Z, so all future references to datasets in library Z will fail.
I'm not being able to understand why this piece of log shows up. I believe that's because I'm calling z.xdauto in the following step
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.);
Why the following statement (written previously in the code) isn't useful to this end?
libname z "/u/SAS/datos" SERVER=ts12;
Thanks,
Martin
@mchiappe83 wrote:
In log line 228 you have another libname statement, which tries to assign library Z with a local path (no server specified as in line 184):
228 LIBNAME Z BASE "/u/SAS/datos"; NOTE: La librería Z no existe.which fails, as can be seen by the NOTE. This leaves you with an unassigned library Z, so all future references to datasets in library Z will fail.
I'm not being able to understand why this piece of log shows up. I believe that's because I'm calling z.xdauto in the following step
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.);
Why the following statement (written previously in the code) isn't useful to this end?
libname z "/u/SAS/datos" SERVER=ts12;
Thanks,
Martin
Because (as I already explained) the following wrong libname statement clears the libref.
And code appears in the log because you ran it, period.
Pay attention to details and make sure that code and logs are from the same execution.
Thanks @Kurt_Bremser for your time
Because (as I already explained) the following wrong libname statement clears the libref.
And code appears in the log because you ran it, period.
Pay attention to details and make sure that code and logs are from the same execution.
I'm sorry but, if you look into the code -not the log- (the wrong libname statement that appears in the log) isn't there. Code and logs are from the same execution.
I'd understand if you prefer not to continue with this stuff.
Again, thanks a lot for your time.
Martin
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?
Build your skills. Make connections. Enjoy creative freedom. Maybe change the world. Registration is now open through August 30th. Visit the SAS Hackathon homepage.
Register today!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.