Date: Wed, 27 Dec 2006 09:31:49 -0600
Reply-To: SAS_learner <proccontents@GMAIL.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: SAS_learner <proccontents@GMAIL.COM>
Subject: Re: Banks giving up on SAS?
In-Reply-To: <1167208649.459230c989540@ssl0.ovh.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Is SAS transport files can only be generated using SAS only ?? guys we do
not need to have SAS for generate CDISC and .xml file ?? what do you think ?
I heard from somebody that SAS transport is not the only reason for using
SAS at FDA ?? is that so ?
thanks
On 12/27/06, Stéphane COLAS <scolas@datametric.fr> wrote:
>
> Do the CDISC standards can be understand with a XML mapper ? If so, Does
> the
> people can use SAS / XML to communicate in the industry ?
>
> Stéphane.
>
> Selon SAS Bum <SASbum@AOL.COM>:
>
> > SAS is pretty much a de facto standard with the FDA. Hmmm. How will
> they
> > make SAS transport files to send? What about CDISC standards? Seems
> > contrary
> > to industry movement.
> >
> >
> >
> >
> > In a message dated 12/25/2006 9:51:15 P.M. Pacific Standard Time,
> > joewhitehurst@GMAIL.COM writes:
> >
> > Roa,
> >
> > One of the nice things about being a "Company top people" is that I
> > don't have to actually know anything at all about what I am talking
> > about.. I doubt your company has any real "plan to get rid of SAS
> > with in(sic) 2 to 3 years." If I were you, I would wait for the
> > numbers on the replacement costs to start rolling in before I
> > abandoned ship.
> >
> > Joe
> >
> > On 12/23/06, rao bingi <rao.bingi@gmail.com> wrote:
> > > I am working for big pharma company. Their plan is to get rid of SAS
> with
> > in
> > > 2 to 3 years in their reporting purpose. The company top people said
> that
> > > Licensing SAS is too heavy. The company is planning to do same
> reporitng
> > in
> > > low cost softwares.
> > >
> > >
> > >
> > >
> > > On 12/23/06, Peter Crawford <peter.crawford@blueyonder.co.uk> wrote:
> > > >
> > > > On Fri, 22 Dec 2006 16:25:50 +0000, toby dunn <
> tobydunn@HOTMAIL.COM>
> > > > wrote:
> > > >
> > > > >Mikeeee, No clue my man no clue. There was a suggestion
> or rumor if
> > you
> > > > >will that made a comprimise, that being SAS would be left for the
> heavy
> > > > >lifting and use some other program to do the reporting. Dont
> think
> > that
> > > > >caught on too well either, there was simply too many people with
> there
> > > > own
> > > > >way of doing things for that really to happen well. If it was me
> I
> > would
> > > > >have kept SAS and the Unix, MVS, and Windows systems they had.
> > Corraled
> > > > all
> > > > >the scattered data into one proper groups depending on the major
> > > > >departments. Then let the peeps use SAS and say Crystal Reports.
> > That
> > > > way
> > > > >you get the data housed properly and while still allowing for the
> most
> > > > >flexability in cranking cool numbers and being able to report them
> in a
> > > > >presentable fashion.
> > > > >
> > > > >
> > > > >
> > > > >Toby Dunn
> > > > >
> > > > >To sensible men, every day is a day of reckoning. ~John W. Gardner
> > > > >
> > > >
> > > >
> > > > I think the move to save licence fees is sensible, but draconian
> > > > action like "replace SAS" is doomed to expensive failure(imho). It
> > > > seems like the only party benefiting are the consultancies who
> > > > achieve brief popularity until the "whole" cost is discovered.
> > > >
> > > > Perhaps overall costs might fall (substantially?) if there were
> > > > more effort made to support dialog and sharing among the users
> > > > of SAS. I don;t mean party-party-party even in this season.
> > > > Technique sharing could pay big dividends. I see a risk that
> > > > some way down the line we'll have to reverse engineer stored
> > > > processes to document what they do/are supposed to do, and
> > > > discover a lot for duplication.
> > > > Success builds on success.
> > > > Hiding technique from (re-)view (to avoid criticism) risks
> > > > dumbing down much more than it provides security for intellectual
> > > > property or business data. Who needs yet another front end to
> > > > unintelligent processes? The whole SAS community can build on
> > > > their success. (Consider how long SAS has been used for "post-"
> > > > processing banking data..... and I expect there are similar
> > > > examples in other data handling industries like marketing).
> > > > Instead of partitioning into industries, we might join on
> > > > techniques, or on the "levels" like programming/project-management
> > > > /strategic-direction. I learn new techniques/solutions just as
> > > > much outside my normal application field as within ~~ the
> > > > common denominator is generally SAS.
> > > > All these unsuccessful replacements for SAS share a common
> > > > misunderstanding of the domain that is SAS. There may be bits
> > > > on which an alternate supplier can improve, but that is no
> > > > replacement. I struggle to interface teradata with sas stat
> > > > only because the client has so much data invested in teradata
> > > > that it cannot easily migrate permanently without ensuring
> > > > full support for those who use teradata without needing sas.
> > > > It is not simple in either direction.
> > > > It is really nice to have technical support from a single
> > > > vendor that supports such a wide range of problems ~(SAS of
> > > > course)
> > > >
> > > > SAP is no substitute for SAS ( unless you see SAS as an ERP )
> > > >
> > > > ~ maybe I shouldn't be negative ~ I hear SAP abap programmers
> > > > are paid higher rates ~~~ ;-)
> > > >
> > > >
> > > >
> > > > Merry Christmas
> > > >
> > > > Peter Crawford
> > > >
> > >
> >
>
| 
