Hi All,
Some years back I was using SAS DI studio to create the SAS jobs and hence we are having SAS DI jobs deployed for running the jobs.
However, off late, we are moving away from SAS DI studio and using SAS EG to create the jobs using Base SAS program and does not use any DI components. Now we are looking to move the DI programs also into a Base SAS programs. On the outset we have identified library references what needs to be amended.
Is there any utility which allows me to do it in SAS or what will be the pointers which i need to watchout when i try to remove the metadata components like tranformation ID, DI macros etc.
Please advice
The deployed jobs are just .sas files without any dependency on DI Studio. To my knowledge all the DI Studio specific macros are defined within the deployed jobs and get compiled during run-time. There isn't any DI specific macro library.
From this perspective you wouldn't have to change a thing.
If your company intends to get rid of DI Studio/the license for the SAS module with which DI Studio comes, then I'd discuss with SAS the implications and especially what this means for already deployed jobs (.sas files). I'm not sure if this would still be seen as code requiring the license given that it had been generated using SAS IP using DIS.
Going forward: Yes, SAS DIS generated SAS code is not how you would code "manually" and it's certainly not that simple to maintain especially if you've used things like the Loop transformation.
I don't really know but would bet that there isn't some script that converts your DIS generated SAS code to something else - which means that's going to become a manual task.
The deployed jobs are just .sas files without any dependency on DI Studio. To my knowledge all the DI Studio specific macros are defined within the deployed jobs and get compiled during run-time. There isn't any DI specific macro library.
From this perspective you wouldn't have to change a thing.
If your company intends to get rid of DI Studio/the license for the SAS module with which DI Studio comes, then I'd discuss with SAS the implications and especially what this means for already deployed jobs (.sas files). I'm not sure if this would still be seen as code requiring the license given that it had been generated using SAS IP using DIS.
Going forward: Yes, SAS DIS generated SAS code is not how you would code "manually" and it's certainly not that simple to maintain especially if you've used things like the Loop transformation.
I don't really know but would bet that there isn't some script that converts your DIS generated SAS code to something else - which means that's going to become a manual task.
So are you getting rid of your metadata environment too?
When EG is connected to a metadata server, it uses the same metadata libraries as DI studio. So this shouldn't be an issue. The metadata objects are defined on the metadata server, not by the application.
If you have gone to a non-metadata environment (e.g. PC SAS or simple SAS Server with metadata setup), then any metadata objects (libraries, tables, prompts...) would need to be replaced/updated.
@Jagadeesh2907 To define often used libraries in metadata is a good thing not only when using DIS. You will still have SMC (SAS Management Console) to maintain such metadata.
If current scheduling uses the deployed job metadata objects then make sure you keep these even when "archiving" the DIS job objects. Deployed job metadata objects can also get created directly from .sas files in SMC so things can continue here as before. If you're using lsf then you might have to ensure that it's not tied to the DIS license - and if it is then you might either have to license lsf directly or change the scheduler.
As you mentioned that you are moving from Metadata to Base SAS - we have built a Flow Manager for jobs, which normally runs on Viya, however we'll soon be updating it to run for SASjs Server as well (ie, on Base SAS). The docs are here: https://cli.sasjs.io/flow/
It's MIT open source (free for commercial use), happy to chat more if you see utility in it. The overarching framework (SASjs) can also be used to for migrating Stored Process Web Apps (either to Viya or Base SAS, it works the same on all three platforms).
Are you ready for the spotlight? We're accepting content ideas for SAS Innovate 2025 to be held May 6-9 in Orlando, FL. The call is open until September 25. Read more here about why you should contribute and what is in it for you!
Learn how use the CAT functions in SAS to join values from multiple variables into a single value.
Find more tutorials on the SAS Users YouTube channel.