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.

Re: Code Management in SAS

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".

Re: Code Management in SAS

@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).

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.

Re: Code Management in SAS

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.

Re: Code Management in SAS

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)

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.