04-26-2015 07:27 AM
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.
04-26-2015 08:51 AM
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.
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.
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.
04-26-2015 09:01 AM
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.
04-26-2015 10:13 AM
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.
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
04-26-2015 01:44 PM
.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.
04-26-2015 01:55 PM
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.
04-27-2015 01:43 AM
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.
04-27-2015 04:32 AM
Just adding my 2p's worth here.
04-27-2015 04:36 AM
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.
04-27-2015 01:46 PM
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:
04-27-2015 02:11 PM
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.