BookmarkSubscribeRSS Feed
sfffdg
Obsidian | Level 7

Hi ,

 

I am bit new to sas DI Studio.

 

In our company , we develop jobs in sas DI and promote to MainFrame.

 

I have to change a job in sas DI , When I compared the SAS DI code and Mainframes code ,it is not matching at all.

 

Seems like somebody has messed up the job in DI(Mainframe code is not messed up) .

 

As the job is not reliable, I created a new job.

 

When I compared the new job developed in sas DI(leaving the change) and the existing job ( in Mainframes) they both are not matching at all.

 

Need help in understanding the changes between the 2 codes.

 

Psrskwm3.sas is the ---Mainframe code

the later is the new sas DI job(in the new job the only change should be

LIBNAME access V8 "dwgip.dwh.views.full" disp=shr ;

where as in Mainframe it shoul be

LIBNAME access V8 "dwgip.dwh.views" disp=shr ;

 

 

3 REPLIES 3
Patrick
Opal | Level 21

It would scare me if metadata of DIS jobs in Prod is messed-up. That's comparable to having compiled macro code with the source code lost. It certainly looks like someone manually changed comments - so question is: what else?

 

I'd raise a red flag internally. Especially: Are there any other jobs with similar issues and is there any explanation for that. It's not necessarily that a person changed DIS metadata after Prod deployment, it could also be a faulty metadata migration as part of an upgrade (with insufficient regression testing).

 

It's not only the transformations but also the DIS version, job level settings and some environment configuration which influence what SAS code gets generated. 

 

Right click on the job canvas and turn off "Collect Diagnostics", "Collect Runtime Statistics". That should give you already code closer to the old one.

 

But yeah, your original is from 8 years ago built with an older DIS version using a different metadata repository. Don't expect a recent DIS version to generate the exactly same code. 

 

Besides of other differences you also need to look into things like below (from original) so you configure the transformations in your new job the same way.

data _null_;
signon sun19p  %inc 'dwgid.sas.program(signon)';
run;

... or if you've got some sort of version control then eventually get the .spk used for Prod promotion 8+ years ago and import from there the relevant objects into your current environment (though upgrading on-the-fly if still possible/versions not too far apart) 

 

sfffdg
Obsidian | Level 7

Thanks a lot Patrick for the reply.

 

True , I too felt the same ..but the explanation given was , " we are using DI for only development and actual Production is MainFrames."

I really did not agree on the part , that's why I am trying to follow some meaningful process.

But as I am not so proficient in Sas DI , struggling to achieve it.

 

unfortunately , there is no sas pkg available.

 

and

 

I turned off the "Collect Diagnostics", "Collect Runtime Statistics",code is  little bit matching .

 

I have the following concerns on the mismatch , request you to help me on this.

 

1)In the new code why the below code is there extra

 

%let local = aaldwppdc012.corp.aal.au 7551;
data _null_;
   signon local  user="jsid" password="{sas002}F607CF0A5B560EDB45D48F6218674232" noscript;

 

2)

  /*---- Implicit Transfer of Data  ----*/

proc download data = access.RSKWM3
         out = work.RSKWM3;

 

also in the new code data step is used as below to load the data to RSKWM31

 

data staging.RSKWM31;
   set &SYSLAST ;
run;

 

where as in the old code , proc append is used as below.

 

proc append base = data.rskwm3
data = &etls_lastTable (&SYSOPT) force;
run;
      run;
      

 

How Can I develop a correct job?

 

also when I try to run the job , I get the  error (in the attachment) , how can I get rid of that error?

 

also please look at the job (in the attachment).

 

Thanks a ton for your help Patrick .

 

Regards,

Swathi

 

 

Patrick
Opal | Level 21

Looking once more into the two SAS script files you've posted it appears that the local server for the old script is the Mainframe but for the new script it's a Sun Unix environment. Are you connecting to the correct metadata server?

 

Once you've verified that you've picked the correct metadata server and application server context the first thing which you need to manage to become "the same" is node #1 "SAS Extract".  ...but before verifying that you're using the correct environment anything further is not even worth looking into.

 

Just on a side note: The libname to the Mainframe library still uses the V8 engine. Really? Are you on such an outdated SAS version on the mainframe? Haven't you migrated your files as part of an upgrade? 

 

....or is it just so that the code on the Mainframe is legacy which no one wants to touch. But then: Why do you bother to fix the DIS job? This is change in any interpretation so you would need to go through a full SDLC in order to move it to Prod. Fixing broken DIS jobs is something which should have happened as part of migration (and there regression testing should have identified the broken DIS jobs).

sas-innovate-2024.png

Don't miss out on SAS Innovate - Register now for the FREE Livestream!

Can't make it to Vegas? No problem! Watch our general sessions LIVE or on-demand starting April 17th. Hear from SAS execs, best-selling author Adam Grant, Hot Ones host Sean Evans, top tech journalist Kara Swisher, AI expert Cassie Kozyrkov, and the mind-blowing dance crew iLuminate! Plus, get access to over 20 breakout sessions.

 

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
  • 3 replies
  • 955 views
  • 1 like
  • 2 in conversation