Software cost for SAS z/OS and consider sub-capacity licensing

[Scott Barry]

Although SAS software licensing cost can be considered excessive, it’s a key consideration to maximize just how much your contracting staff (and ideally to include key / knowledgeable mgmt. staff) who have a stake at keeping SAS, of course as well as MICS too!

Here are some considerations for licensing SAS on z/OS:

 

1) SAS will negotiate a sub-capacity licensing arrangement, but it requires isolating SAS z/OS software use on what’s sometimes called a ‘licensed software’ LPAR; other vendors may also be willing, but clients must ask/insist that the opportunity be negotiated.

 

2) Client (your enterprise) must be prepared with ‘historical usage’ measurement (for the initial negotiation) to understand current / planned usage, as well as allowing for some growth (additional MSU capacity for the SAS-designated LPAR) – likely it won’t be just SAS running there so you must be ready to address incidental increased-capacity need.

 

3) Also, enterprise staff will need to identify what SAS z/OS components are required when developing a plan – if SAS/FSP is licensed, then it must be justified; similar condition for say SAS/Graph. Do consider that starting with SAS V9.3, there are SG* PROCs now in SAS BASE that provide graphical reporting – very effective, if SAS/Graph is licensed but where not all features are exploited.  The SAS software can generate a user-type SMF record (MXG supports it for reporting/analysis) if you might want to get additional information about various PROC usage.

 

4) Of course, to get to #2 above, the enterprise must develop, justify and finally execute a consolidation plan in order to get SAS onto a subcapacity LPAR environment.

 

5) Also, SAS will insist that the enterprise maintain a current-version status going forward, however with an understanding that there will be reasonable transition time-periods (between versions) – this would all pertain to SAS z/OS operation.  So, another consideration, is that the enterprise will need/want to limit how many SAS environment library configurations exist – i.e., users can’t simply create their own copy of the SAS software libraries, without consideration for maintaining currency. As well, there are SAS SETINIT (renewal considerations) too helping to manage how many copies of the SAS software are out there and in use.

 

6) Once the SAS subcapacity environment is attained, it must be managed – SAS does not require any SCRT-type reporting, but SAS INSTITUTE does expect that there could be an audit of SAS software usage at any time, to support the contractual arrangement. 

 

To demonstrate that SAS is serious and will consider sub-capacity licensing, here is a SAS.COM document / link on the topic:

 

http://support.sas.com/techsup/technote/ts773.pdf

 

And here is an IBM-MAIN discussion thread – do consider the various opinions as just that, one’s perspective:

 

[e-mail]/msg88680.html" rel="nofollow" target="_blank">https://www.mail-archive.com/[e-mail]/msg88680.html

 

Another link below….

 

http://www.dssresources.com/news/1977.php - another link to a paper on the topic, not from SAS INSTITUTE.

 

 

Hope this information helps….and it is possible to get to a reasonable place with SAS software licensing, but it will take work and attention/effort.  And you are more than welcome to share this information with others, and I can be contacted as needed for any further clarification or guidance as necessary.

 

Scott Barry

SBBWorks, Inc.

 

[Anon Anon]

A very good post and some good points made Barry.

ITMetrics,who have supported CA-MICS for many years, have developed an activity logger for SAS (ALS) on the z/OS platform that will help a Site discover its SAS "estate" and identify all the associated z/OS resources.

This includes CECs, SYSPLEXs, Systems, JOBS, USERS, CPU, SAS Data Libraries and SAS Files, z/OS Datasets, DASD, TAPE,  Source code libraries and script members, SAS Products and Procedures and what SAS is being used for (such as accessing DB2, IMS, ADABAS, sending emails, running SAS/AF Apps, CONNECT Sessions .etc).

 

We use ALS as part of our services to help Sites:

• Understand their total investment in SAS workloads .. it is not just the cost of the software
• Justify the incumbent SAS Software portfolio
• Position themselves for negotiating SAS license costs
• Assist in moving SAS workloads around within a Site or when Sites merge
• Consolidate, rationalize and tune SAS based workloads
• Support SAS version upgrades
• Support migrating old SAS/AF applications to other technologies
• Justify and support migrating SAS workload from z/OS to other platforms
• Support investigations as to whether a Site should consider migrating to WPS (from World Programming) and to help plan and track such migrations
• Associate SAS workloads in "migration sets" when workloads are related in some way and should be handled as a set for the purposes of migration or upgrades
• Save Software and operational costs by profiling current SAS workloads and recommending, justifying and tracking changes to realize significant costs savings

 

ALS was originally written to monitor MICS and to help rationalize the resource that was associated with running MICS in large Sites and to support a re-design of MICS Complexes.

ALS has been continually developed over the years, has supported SAS Sites all over the World and has become a key tool for observing and managing SAS workloads and SAS based Applications on the z/OS platform , both batch and Interactive and supporting all SAS versions.

The ALS monitor and its partner analyzer can also calculate the real 4hour rolling average MSU values, equivalent to the SCRT reports, just for the SAS workloads and this has proven very useful when moving workloads across the operational day and/or within Sysplexes and CEC’s  so that the peak periods in the SCRT reports are not adversely affected .. and therefore neither are the associated IBM z/OS Software costs.

Steve Bagshaw

ITMetrics