Error in code to be executed repeatedly

[Kurt_Bremser]

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.

[mchiappe83]

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

[Kurt_Bremser]

---

@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.

[mchiappe83]

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

[Kurt_Bremser · Accepted solution]

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?