Date: Sat, 19 Dec 2009 08:19:40 -0800
Reply-To: xlr82sas <xlr82sas@AOL.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: xlr82sas <xlr82sas@AOL.COM>
Organization: http://groups.google.com
Subject: Re: SASware ballot
Content-Type: text/plain; charset=ISO-8859-1
On Dec 19, 1:41 am, j...@STANFORDALUMNI.ORG (Jack Hamilton) wrote:
> On Nov 29, 2009, at 8:06 pm, Savian wrote:
>
> > Step back from the price for a sec and pretend that it is zero. The
> > only way to use it is to write the code in ARCHAIC languages. We have
> > only a few to choose from (and I quote Joe): C, FORTRAN, PL/I, and IBM
> > assembler.
>
> > I really wanted to code it in ALGOL so I am SOL ;-]
>
> My recollection is that in practice you weren't so restricted - you could use any language that followed the supported calling conventions. The problem was with languages that required a run-time package to be loaded.
>
> --
> Jack Hamilton
> j...@alumni.stanford.org
> Caelum non animum mutant qui trans mare currunt.
>
> On Nov 29, 2009, at 8:06 pm, Savian wrote:
>
>
>
> > On Nov 29, 12:00 pm, PhilR...@MINEQUEST.COM (Philip Rack) wrote:
> >> Regarding SAS pricing for the toolkit, it's over $12,000 first year for a single PC and $3,000 per year maintenance.
>
> >> If you are interested in SAS pricing for specific modules, you can go to the Executive Information Systems, LLC website and take a look at the GSA pricing. As a rule of thumb, the GSA requires a "best price" from a vendor and that usually is construed as a reduction of 16% off the commercial offering. So, add an additional 16% on to those prices and you're in the ball park.
>
> >> The link to the PDF is:http://www.execinfosys.com/SAS%20GSA%20PriceList.pdf
>
> >> Philip Rack
> >> MineQuest, LLC
> >> SAS & WPS Consulting and WPS Reseller
> >> Tel: (614) 457-3714
> >> Web:www.MineQuest.com
> >> Blog:www.MineQuest.com/WordPress
>
> >> -----Original Message-----
> >> From: SAS(r) Discussion [mailto:SA...@LISTSERV.UGA.EDU] On Behalf Of Ajay Ohri
> >> Sent: Sunday, November 29, 2009 11:35 AM
> >> To: SA...@LISTSERV.UGA.EDU
> >> Subject: Re: SASware ballot
>
> >> Joe
>
> >> I am an engineer and MBA and have seen too many buyouts mergers and. Acquisitions to comment
>
> >> Thanks for the tip
>
> >> Managing the developers community has not been a big success for many software firms but has helped others who managed it well
>
> >> Sas has been in analytical sciences since 70s and a great rep as an employer and with local community but is now losing respect within academia due to lack of speed in new algols
>
> >> Maybe the guys who wrote proc gml should come back to innovative coding rather than innovative marketing
>
> >> It would be interesting if the toolkit and learning edition were set free and incentives created for translating custom r algols into sas algols
>
> >> Open source is a fun passion full environment and intellectually simulating
>
> >> Thanks for the information it's great to see we can create custom procs but what's the current price of sas toolkit
>
> >> Sent from my iPhone
>
> >> On Nov 29, 2009, at 8:26, Joe Whitehurst <joewhitehu...@GMAIL.COM> wrote:
>
> >> Ajay,
>
> >> But SAS anticipated the "open source" quasi-religion by at least a
> >> decade--by including with SAS/Base in the early 1980's a Supplement Library
> >> of Procedures Contributed By SAS Users. You can review a list of the key
> >> terms found in the Supplement Procedures User's Guide here:http://books.google.com/books?id=w-ZQAAAAMAAJ&q=Guttman+scale&source=....
> >> When tech support for these user created procedures became problematic, as
> >> I think it has already for many current worshippers and practitioners of the
> >> quasi-religion, SAS brought most of the user contributed procedures in house
> >> or incorporated the functionality into other parts of the SAS System. Then
> >> SAS created a product designed to facilitate the ability of ordinary users
> >> to extend the SAS System that would bring order to the choas created by
> >> users left to their own devices (and ignorance)--SAS/Toolkit:
>
> >> SAS/TOOLKIT�
>
> >> SAS/TOOLKIT software enables you to write your own customized SAS procedures
> >> (including graphics procedures), informats, formats, functions (including
> >> IML and DATA step functions), CALL routines, and database engines in several
> >> languages including C, FORTRAN, PL/I, and IBM assembler.
>
> >> *SAS Procedures*
>
> >> A SAS procedure is a program that interfaces with the SAS System to perform
> >> a given action. The SAS System provides services to the procedure such as:
>
> >> - statement processing
> >> - data set management
> >> - memory allocation
>
> >> SAS procedures can read SAS data sets and data views, perform data analysis,
> >> print results, and create other SAS data sets. There are many advantages to
> >> writing programs as SAS procedures rather than stand-alone programs:
>
> >> - Familiarity -- using your new procedure is easy for SAS users because
> >> they already understand data input, data manipulation, and general SAS
> >> syntax.
> >> - Extensibility -- you can extend the capabilities of the SAS System to
> >> meet the specialized needs of your users.
> >> - Convenience -- a program incorporated into the SAS System allows you to
> >> put all your programming tools in one place.
> >> - Reduced Coding -- the SAS System provides many services that you, as
> >> the programmer, would otherwise have to code yourself.
> >> - Integration -- the data used by your procedure can easily be sorted,
> >> printed, and analyzed using other SAS procedures during a single job.
> >> - Special Capabilities -- special features, such as BY-group processing,
> >> can be used.
> >> - Reduced Documentation -- the task of documenting your new program is
> >> simplified because only the new language statements, the procedure's output,
> >> and any special calculations need to be explained.
>
> >> *Writing SAS Procedures*
>
> >> If you are considering writing a SAS procedure, you probably have in mind
> >> what you want the procedure to do. Determining function and purpose and
> >> planning your program are important preliminaries to writing SAS procedures.
>
> >> *Writing the Grammar*
>
> >> One of the important parts of planning your procedure is deciding how the
> >> user will invoke it. You must have this information to write the grammar for
> >> the procedure. The grammar defines the format of the PROC statement, the
> >> other statements that can be used when invoking the procedure, and any
> >> options that can be used in the PROC or other statements. The SAS System
> >> uses the syntax rules you define in the grammar to check the syntax of the
> >> statements when the user invokes the procedure.
>
> >> *Writing the Procedure*
>
> >> The biggest task of procedure writing is coding the application program that
> >> actually performs the function of the procedure. To assist you in coding the
> >> procedure, the software provides a library of routines that enable you to
> >> interface with the SAS System and perform frequently needed tasks. The
> >> library routines are grouped into sets that perform related actions. For
> >> example, there are sets of routines for all of the following tasks:
>
> >> - perform I/O on SAS data sets
> >> - dynamically allocate memory for use by your program
> >> - print procedure output or messages to the SAS log
> >> - provide detailed information on observations and variables in SAS data
> >> sets
> >> - handle problems specific to the SAS environment, such as missing values
> >> - replace routines standard to the programming language you are using
> >> when the standard routines do not properly interface with the SAS System.
>
> >> *SAS Informats, Formats, Functions, and CALL Routines (IFFCs)*
>
> >> You can use SAS/TOOLKIT software to write your own SAS informats, formats,
> >> functions, and CALLroutines in the same choice of languages: C, FORTRAN,
> >> PL/I, and IBM assembler.
>
> >> Like procedures, user-written functions and CALL routines add capabilities
> >> to the SAS System that enable you to tailor the system to your site's
> >> specific needs. Many of the same reasons for writing procedures also apply
> >> to writing SAS formats and CALL routines.
>
> >> *SAS/TOOLKIT Software and PROC FORMAT*
>
> >> You may wonder why you should use SAS/TOOLKIT software to create
> >> user-written formats and informats when base SAS software includes PROC
> >> FORMAT. SAS/TOOLKIT software enables you to create formats and informats
> >> that perform more than the simple table lookup functions provided by the
> >> FORMAT procedure. When you write formats and informats with SAS/TOOLKIT
> >> software, you can do the following:
>
> >> - assign values according to an algorithm instead of looking up a value
> >> in a table. You can include calculations and other algorithmic capabilities
> >> in your formats and informats that you write with the software.
> >> - look up values in a Database to assign formatted values. To create a
> >> format with ranges and labels that are derived from a database, you have to
> >> extract the ranges and labels from the database using external means, and
> >> create a flat file containing the values. Then, you read in the flat file
> >> and create a CNTLIN= data set to be read by PROC FORMAT. SAS/TOOLKIT
> >> software allows you to use routines provided by the database software to
> >> extract the data directly, and avoid processing all the data values.
>
> >> *Writing a SAS IFFC*
>
> >> Unlike SAS procedures, IFFCs do not require that you define a grammar
> >> module. In general, IFFCs are simpler and shorter than user-written
> >> procedures. You do not need to interface with the SAS System as much in an
> >> IFFC, but when you do, you can use the same library of routines that are
> >> available for procedures. The routines you are most likely to use when
> >> writing an IFFC perform the following tasks:
>
> >> - provide a mechanism to interface with functions that are already
> >> written at your site
> >> - use algorithms to implement existing programs
> >> - handle problems specific to the SAS environment, such as missing
> >> values.
>
> >> *SAS Engines*
>
> >> SAS engines allow data to be presented to the SAS System so it appears to be
> >> a standard SAS data set. Engines supplied by SAS Institute consist of a
> >> large number of subroutines, all of which are called by the portion of the
> >> SAS System known as the engine supervisor. However, with SAS/TOOLKIT
> >> software, an additional level of software, the engine middle-manager
> >> simplifies how you write your user-written engine.
>
> >> *An Engine versus a Procedure*
>
> >> To process data from an external file, you can write either an engine or a
> >> SAS procedure. In general, it is a good idea to implement data extraction
> >> mechanisms as procedures instead of engines. If your applications need to
> >> read most or all of a data file, you should consider creating a
> >> procedure�-but if they need random access to the file, you should consider
> >> creating an engine.
>
> >> *Writing SAS Engines*
>
> >> When you write an engine, you must include in your program a prescribed set
> >> of routines to perform the various tasks required to access the file and
> >> interact with the SAS System. These routines:
>
> >> - open and close the data set
> >> - obtain information about variables
> >> - provide information about an external file or database
> >> - read and write observations.
>
> >> In addition, your program uses several structures defined by the SAS System
> >> for storing information needed by the engine and the SAS System. The SAS
> >> System interacts with your engine through the SAS engine middle-manager.
>
> >> *Using the USERPROC Procedure*
>
> >> ...
>
> >> read more �- Hide quoted text -
>
> >> - Show quoted text -
>
> > Step back from the price for a sec and pretend that it is zero. The
> > only way to use it is to write the code in ARCHAIC languages. We have
> > only a few to choose from (and I quote Joe): C, FORTRAN, PL/I, and IBM
> > assembler.
>
> > I really wanted to code it in ALGOL so I am SOL ;-]
>
> > Alan
> >http://www.savian.net
Hi SAS-Lers,
Has anyone been able to convert the pricing PDF to a SAS dataset. It
appears to be heavily encrypted. The only way to create a SAS dataset
is to scrape screen shots.
I thought I would add 16% and do some analyses. Pricing behavior can
expose SAS strategic directions.
| 
