10-17-2015 01:08 AM - edited 10-17-2015 10:57 AM
Rising End User Computing (EUC) costs are helping organizations build an effective defense by migrating processes to a non-mainframe environment such as Unix or AIX based platforms. For our discussions in this process, let us assume there is no other motivational factor other than cost. One may have several Generational Data Groups (GDGs) on the mainframe that can pose a problem for conversion. However, the GDGs may be converted to SAS Generational Data Sets (GDSs) on the Unix SAS environment given some subtle differences that could be worked around with Shell scripts.
SAS has intelligently thought of such a need and provides us this GDS mechanism to be created using GENNUM and GENMAX options simply while creating a Dataset. The operation is made simpler and similar to refer to the generations and when a code refers to a generation with appropriate notification while a reference is out of range.
GDS documentation has appeared even in earlier 9.* versions so it is not a new concept, however, usage has not been very common among development teams in the author's observations.
10-17-2015 10:22 AM
What is te question? The culture and technical conditions are a little bit different
Delivering data (as GDG's).
- Mainframe SAS datasets (bound gdg) are containers wiht possible many SAS-datasets and catalogs
Unix/Windows are using a segregated datasets as the suffix "sas7*" The directory is more like te mainframe bound library
- Mainframes are using an andvanced locking mechanisme not present at Windows Unix, it is just coming. The GDG usage is avoiding the locking questions by creating a new dataset where the old one can get deleted/uncataloged after some period of time.
The SAS GDS looks like a mainframe gdg but the difference: it is working on sas-datasets.
The GDG creation part is normally done as delivering ODS (extracts of operational data) by the prodcutions support team.
At Windows/Unix SAS users are not commonly used to the regularities wiht scheduled processing deleivering an dwh. Insteda they are used to code the full physical datasetnames in ther programs (terrible bad coding practice).
Do you want to Convert the processing you will need the change some cultural behaviors.
- The Dwh processing should run scheduled on your Unix machines cerating those newly datasets (ODS)
The creation-of that code should be modified to use GDS in a SAS appraoch
- The users should use those GDS with avoiding the lockings.
It is a more straight forward processing of working wiht extracts/ODS not possible with a RDBMS usage approach.
As the common DWH theory is learned by means of Kimball Inmon Lindsted using a RDDMS as pre-req than yes, it is not a well known approach.
10-17-2015 11:10 AM
Thank you for your response.
I did not post a question, rather wanted to present the availability of an alternative and the scarce use of SAS GDS which closely resembles the functionality of a mainframe GDG.
Also, you bring up an excellent perspective as it relates to the culture. I believe culture is one of the dimensions to look into while the other dimension would be the awareness of the alternative which might be related to team-training and also part of the leadership initiative to bring the concept to light and the needed motivation with the interests of curbing EUC costs by moving to less expensive alternate options while everything else such as security, integrity and others are maintained. While all that said, I do recognize that culture would be the most challenging to transform.