07-15-2014 04:19 AM
I plan to use Rational Team Concert tool for code management in SAS.
Rational Team Concert is a software development team collaboration tool developed by IBM.
It is used to manage tasks such as revision control, build management,etc.
RTC is built on a client-server architecture.
RTC presents an Eclipse-based client interface, a Microsoft Visual Studio client interface, and a Web interface.
Can anyone tell me is there an RTC client for code management in SAS Base?
07-15-2014 07:07 AM
Code management is done at different levels.
a/ - Segregations developers -> version management. (this only applies to Development stage)
b/ - Life Cycle of your business application -> release management. RTC (rational IBM) Endevor, Nolio (CA) and many more
c/ - Life Cycle of middleware (SAS) -> release management. smp-e rpm yum softgrid/ccm and many more.
What your goal with code management?
You have also to definine your code artifacts with SAS first as it can be:
- SAS metadata defined objects (Stored Process parts, Records lay outs, DI code-source referentions, information maps, miner models, job scheduling/planning)
- Eguide projects with flows, Eguide is an Integrated Development Environment storing code internal. It can also use code as references outside Eguide (full path url)
Eclipse is also an IDE it is based on classic coding as once was Cobol now often java.
- Base SAS types in catalogs (formats sources views fcmp-procs) and in old classic plain OS-files style coding.
Version management (Develop only)
With DI and using SAS metadata there is version control with checkin/checkout and when you need all versions of the developers you can connect that to SVN.
Release management ( Develop Ttest Acceptance Production)
Using SAS metadata you are bound to using the SAS tools for importing/exporting the SAS-metadata. Some batch processing is possible to do that but needing well defined structure in SAS metadata.
Implementing a tool for storing the intermediate data and use RTC for that is possible. You are using RTC just as a backup/restore tool in that case as nothing of that binary intermediate file is readable.
Using a good backup restore strategy would make more sense.
The last part is Base SAS types. Only the classic OS-files are applicable for Rational as the only ones being in a structure like Cobol. All other types are needing SAS tools to maintain. SAS is an interpreter but sometimes is compiling some things storing them in a SAS specific way (catalaogs).
Release management (middleware)
The life Cycle of the SAS middleware is out of scope, but many are confusing that with business applications calling SAS the application.
Look at SAS installation the java parts and you will find a lot of eclipse. Eclipse is probably used to build SAS parts by SAS institute.
07-30-2014 08:22 AM
I will require code management for level as stated in option b/ - Life Cycle of your business application.
I am basically creating a customised dashboard by coding on SAS Base. My files are all '.sas' files. Thus I need to do version controlling of only these files which contain macros, basic proceedures to create chart and generates an html file of the same.
Also I would like to know what are OS files in sas, as You have mentioned that "only the classic OS-files are applicable for Rational as the only ones being in a structure like Cobol".
07-30-2014 08:32 AM
What Jaap most probably meant with "OS files" are simple text files. SAS programs stored as .sas are exactly that, you can edit them with any simple text editor like edit or vi. Just like C sources.
SAS can also store codes in SAS catalog files that are not readable outside SAS.
07-30-2014 09:42 AM
@kurt, Yes that is correct the *.sas files are for me OS-type files as you can edit them with whatever other kind of text-editor.
That is a really a very good differentiator: using some kind of other editor, when you see readable sas-code it is OS-type files.
There are a lot of other types like catalogs but also the Eguide projects SAS-metatadata objects etc. That makes a classification mostly a complicated discussion.
DI is build in java using eclipse, all namings of that can be found in the "SASHOME" installation of DI. The source objects are metadatabase object and the executable code is sas-code OS-type of files.
Mentioning COBOL is giving the flashbacks to Endevor the CA-tool that does similar things like Rational.
For Cobol/Assembler the steps are building from source-code object-code into a monolytic executable. Introducing JIT approaches was a later improvement.
Other types of code objects are needing additional tools in the release-management tools. Seen that with Endevor needing Endevor-DB for supporting IDMS. Even with that all needed to be configured by processors. Sounds nice but is saying: handling every type of code object must be doing some dedicated programmed parts.
Back to Jeema
The only type of objects that could become confusing are the SAS-Views and formats. These are resulting in catalog-types.
Sounds confusing, let me try:
*.sas files that will run unmodified after promotion in a new environment can be brought into the release-management tool (no compile/link steps)
*.sas files that needed to be run to get the executable object (catalog), than you need dedicated processors (compile link) supporting both of them
The compilation/compiler in this case is running the sas program. The executable, the really needing one, is the sas catalog member (needing SAS functions).
You could need some other types with different technical behavior. As the processor of the release-management tool is leading there must be a segregation.
Setting up an environment like this is also thinking on reusing promoted components. In a mainframe it is easy to do with al kind of searchpaths with Steplib Joblib and concatenations orders. SAS is also supporting that way of concatenation for libnames and filenames (no difference).
What you are doing is following a generic concept like I tried to explain at: DTAP lcm scm - soll ist, templates (metier.jakarman.nl/dtap04.html)
All these different boxes are needing a dedicated segregate physical location with some security set on it. Only the releasemangement tool will be allowed for updates.
Version control is something different it is about segregation of the work by developers. IT can get complicated when allowing parallel development,
Having a small development team that are cooperating (same room) overwriting each others work will not happen often.
The most simple way of version control is allowing just one person at the same time updating some code by OS-locking.
The best way of preventing code being changed that is already promoted/deployed is having it not physical present in development. That is possible by using the concatenation (search path) approach when running all code with all dependicies. The code should be developed in structured programming way.
07-31-2014 02:33 AM
Now that you mentioned it: we actually use ENDEVOR for SAS code management. We did that because it is the main code management tool for all our backend software (DB2 queries and PL/1 programs), so we did not want to set up a separate environment for the DWH. We did have to write a special frontend that gets/puts .sas files from/to the DWH server into the z/OS based endevor system, using ftp.
08-20-2014 01:59 AM
Now as I know that my classic OS-files are applicable for Rational, could you please let me know the clients I need to install and steps to configure the Classic OS-files for rational (RTC Code Management)
08-20-2014 02:37 AM
It is a IBM tool see: Rational Team Concert - Information Center . I was expecting the one that is setting you up into this direction would already have an implementation and you could just tap into that.
Designing verifying and building a infrastructure for releasemanagement is not to be underestimated. It it is often a big difficult project on its own and afterwards a moloch hardly to change. Are you sure that is your project? It is not SAS related.