Help using Base SAS procedures

Best Way for Saving SAS Code

Reply
Regular Contributor
Posts: 164

Best Way for Saving SAS Code

Hi all

One of the (many) powerful features in SAS is the ability to save the code to modify/ re-use it later on in the project.

It also makes long and sophisticated analyses much easier, in such a way that the analysis can be planed in several steps.

Some colleagues save the code as a .sas file, with the ease of clicking to open the code directly in SAS and the possibility to save it back again directly from SAS through the save button

Others choose to save it as a word document, arguing it would be easier to track/see changes introduced to the code later on.

A general question to the public here, how do you save your code? what is the best way of doing it, or better said, which way would you recommend and for what reasons?

Apologies if I posted this discussion in the wrong forum.

Best regards

Ammar

Trusted Advisor
Posts: 3,215

Re: Best Way for Saving SAS Code

ammarh, there is no best way in the way of "one size fits all" the best way is one that is the most easy one fitting your needs.

1/ ".sas"files.

Storing hand made code as ".sas" has the advantage that you add version management tools for segregation of developers and releasemanagent tools for deployment knowing the specific version.

The disadvantage is that you are missing macro/formats and more of the dedicated SAS programming options. There is more to solve.

2/ Eguide

You can store code within Eguide as that is an nice IDE (Integrated Development Environment) using MS-word for that is a humbug argument and not a good practice.

The disadvantage is you are missing a good releasemanagement approach. As the sas code can be tailored to be external links you can combine that with 1/ ".sas files"

3/ SAS Source catalog types and other catalog types

These are dedicated to SAS they are very good in making machine differences of OS type irrelevant. When you have something that must run on Windows / Unix / Mainframe this can be a good choice to use. The disadvantage is: it must be managed with SAS tools.

4/ Metadata objects.

Coding manual is going to be an history job with this. The code/source is moved the linking metadata objects setting properties and the resulting SAS code is more a less a compiled version of the real source that is in the metadata. Your management of code is moved to Management of metadata-objects. This concept change is for a lot of newbies and oldies rather difficult to accept.

Your version management should have the objective of managing that metadata not the resulting SAS-code, Your release-management should be able to keep the metadata (source) and compiled versions (sas-code) in sync. At least  ITSM "standard of good practice" are making those directions.  There is a lot lacking with SAS with this, just some tools to build you own solution for the management are there. There is no choice  as SAS-DI SAS-Eminer SAS-VA,  SAS solutions and maybe more are all moving into this approach.             

---->-- ja karman --<-----
Super User
Posts: 7,868

Re: Best Way for Saving SAS Code

Once tracking of changes becomes necessary (and that point usually comes MUCH earlier than most people think!), it is best practice to use a dedicated version control system. EG now offers integration with git, so if you do not already have a VCS set up at your organization, look into that. Change management with Microsoft Office is, ah, ridiculous.

---------------------------------------------------------------------------------------------
Maxims of Maximally Efficient SAS Programmers
Trusted Advisor
Posts: 3,215

Re: Best Way for Saving SAS Code

Hi kurt we agree on being ridiculous using MS-Office as change ahh beter release management tool.  Yes for the developer that EGuide implementation will be a nice feature with embedded code in the Eguide project file. http://blogs.sas.com/content/sasdummy/2014/10/12/eg-71-new-programmer-features/  But this is just for programmers not for compliancy with production environments.

I found a nice link with a good picture showing the life cycle. (focus on the developed sas code not the sas system). IT Release Management | Rocket Software Version control is at the development area of new business applications. The regulations are describing of versions used in production environments. That is a different context of the same word "version" many are using the iso27k series or have similar controls. I know you are in a area that is under control of those.  (ISO/IEC 27002:2013(E) )  See guidance g/  It is about the control of versions in the operational environment.
As this is so clear stated I am wondering why that many persons have problems what that. Any explanation?

12.5 Control of operational software

    Objective: To ensure the integrity of operational systems.

12.5.1 Installation of software on operational systems

Procedures should be implemented to control the installation of software on operational systems.

Implementation guidance

The following guidelines should be considered to control changes of software on operational systems:

a) the updating of the operational software, applications and program libraries should only be performed by trained administrators upon appropriate management authorization (see 9.4.5);

b) operational systems should only hold approved executable code and not development code or compilers;

c) applications and operating system software should only be implemented after extensive and successful testing; the tests should cover usability, security, effects on other systems and userfriendliness and should be carried out on separate systems (see 12.1.4); it should be ensured that all corresponding program source libraries have been updated;

d) a configuration control system should be used to keep control of all implemented software as well as the system documentation;

e) a rollback strategy should be in place before changes are implemented;

f) an audit log should be maintained of all updates to operational program libraries;

g) previous versions of application software should be retained as a contingency measure;

h) old versions of software should be archived, together with all required information and parameters, procedures, configuration details and supporting software for as long as the data are retained in archive.

Vendor supplied software used in operational systems should be maintained at a level supported by the supplier. Over time, software vendors will cease to support older versions of software. The organization should consider the risks of relying on unsupported software.

Any decision to upgrade to a new release should take into account the business requirements for the change and the security of the release, e.g. the introduction of new information security functionality

or the number and severity of information security problems affecting this version. Software patches should be applied when they can help to remove or reduce information security weaknesses (see 12.6).

Physical or logical access should only be given to suppliers for support purposes when necessary and with management approval. The supplier’s activities should be monitored (see 15.2.1).

Computer software may rely on externally supplied software and modules, which should be monitored and controlled to avoid unauthorized changes, which could introduce security weaknesses

---->-- ja karman --<-----
Super User
Posts: 19,878

Re: Best Way for Saving SAS Code

.SAS files are text files, Word Documents are a proprietary format. You're more likely to lose access to a Word file in the future than a .SAS file.

I'd save it as a .SAS file within a Version Control System if tracking changes is a major issue.

Trusted Advisor
Posts: 3,215

Re: Best Way for Saving SAS Code

Reeza please explain why a version control system (developpers segregation) as the needed one is a release management one as assuring the production environment. See those guidelines above.  I am always and still wondering why that change to do something different happening. 

---->-- ja karman --<-----
Super User
Posts: 7,868

Re: Best Way for Saving SAS Code

Jaap:

A VCS provides a central repository. If a user/developer falls ill or is run over by the proverbial bus, his work is preserved for others to continue. If her/his desktop is encrypted and nobody knows the password, you're hosed.

Changes can be reliably rolled back, so a previous program version can be used to rerun a job with older file structures, and it can be reliably proven to auditors how a certain dataset was created.

Finally, multiple users/developers are protected against trashing each others changes.

---------------------------------------------------------------------------------------------
Maxims of Maximally Efficient SAS Programmers
Super User
Super User
Posts: 7,997

Re: Best Way for Saving SAS Code

Just adding my 2p's worth here.

1) Using Word - really, there is no case whatsoever to use such a thing.  Firstly it is a proprietary format, (ok latest editions are Open Office, but they are still Zipped, and macros etc are still binary).  It has none of the functionality of an IDE.  These two points alone should be enough to stop the use.
2) .sas, the extension is only there to allow the OS to know that that file should open with a certain application.  The underlying format is text, which is a staple across all systems, therefore it is portabl, and readable without any additional tools (i.e. you can use OS commands to list it). 
3) SAS catalogs.  Proprietary format.  Binary. Not easily portable.  Requires certain software.
As mentioned by Reeza and KurtBremser above, the "best" way to version, audit, control development environments is via a VCS.  I have seen several other attempts, using folder strcutures, naming conventions etc. but these are all flawed in two ways, firstly they are manual, secondly they are not auditable.  I notice that it is commonplace in SAS programs to include version history for instance.  This really grates on me, again the process is manual (i.e. falible), requires effort, and looks untidy.  Using a vsc correctly eliminates the need for this with embedded histories which can be pulled out at run time, bug trackers etc.  In addition, a vcs allows multiple working branches, complicated merging between version etc.
Trusted Advisor
Posts: 3,215

Re: Best Way for Saving SAS Code

Yes kurt, I understand that goal of VCS for DEVELOPERS very well. 
The versioning requirement by regulators is however on PRODUCTION that is an other environment and other implications (same word version is used).

There are also requirements to make that PRODUCTION environment reliable an verifiable. It are those PRODUCTION requirements coming with questions like the correct versions being there to be solved.

For fun is the same kind of questions that should prove you are not hacked (SIEM) or running the wrong software with PRODUCTION data.  


The confusion of goals can be very frustrating.   Making a backup but not able to restore that one sound funny these days, as the only auditing requirement is "have a backup" it happens.

Seem to be a cultural difference with EU and VS people. EU culture trying to follow the goal of laws and VS trying not to break those, intentions of the laws doesn't matter.

---->-- ja karman --<-----
Super User
Posts: 19,878

Re: Best Way for Saving SAS Code

What does EU and VS stand for?

I like VCS for shared workspaces, where multiple people share a set of code, not necessarily production. It sounds like the OP is working within a team and if you're sharing macro's/code within a team without a structured system, whether its VCS or a rigid folder structure you'll run into issues  quickly. Someone is going to need a variant of XY code for a project and will change the master instead of a copy.

And you won't know until something breaks, if it breaks. And you won't know who to yell at either :smileylaugh:

Trusted Advisor
Posts: 3,215

Re: Best Way for Saving SAS Code

EU Europe (tiny part is NL) and  VS sorry it is a local NLS I18N abbreviation, it I should have it better noted as US United-States. Canada is different I believe more in between although it is located upper (N).

As long as developers are closely located and they are working traceable on their personal account, no problem to find the one that has broken it (OS level).  Still better to have a more rigid approach.

Even with easy OS controls you can do a lot. The developers only allowing to update at develop coding nowhere else. Another guy (skilled admin) doing to promote/deploy.

It are the same actions and the same structure with a VCS system. It closes all access down and only the VCS service account is getting access. No freedom allowed for a developer.

You can do even better using the concat options with libnames filenames.  SAS(R) 9.4 Companion for UNIX Environments, Fourth Edition (it exist in every OS).

Why it is better to do that?   You do not need to copy a master of every possible source /object to every developer so he just can test/run. Copying everything to him is  introducing uncontrolled changes. Having the concatenation active only the source he is assumed to change my be copied backed to him. What he doesn't have to change cannot be changed and cannot cause errors.

    
For the bad behavior of the SAS metadata it is missing that approach of versioning and releases, only with DI you can do some things.
I got no comment for that and we SAS institute moving fast into that.  

---->-- ja karman --<-----
Ask a Question
Discussion stats
  • 10 replies
  • 437 views
  • 6 likes
  • 5 in conversation