Date: Wed, 19 Jan 2005 22:18:55 -0500
Reply-To: Taylor <firstname.lastname@example.org>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Taylor <kissmysas@GMAIL.COM>
Subject: Re: How to best access remote data?
Content-Type: text/plain; charset=US-ASCII
SAS/CONNECT is already in the picture. Global access rights to use
servers "across SAS Regions" become very expensive. We're talking
international rights here - say, from Europe to North America.
Telnetting an xTerms might just be the way to go. I would think we
would still want SAS on workstations, just in case the WAN went down -
then programmers could still be productive.
On Wed, 19 Jan 2005 14:59:51 -0800, Pardee, Roy <email@example.com> wrote:
> I take it that sas/connect comes under the umbrella of the prohibitively
> expensive sas options?
> How about having people telnet/ssh or xterm in to a central server &
> submit code that way?
> -----Original Message-----
> From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Tim
> Sent: Wednesday, January 19, 2005 2:44 PM
> To: SAS-L@LISTSERV.UGA.EDU
> Subject: How to best access remote data?
> Hi folks,
> I have a "high level" question about how your SAS programmers are
> accessing data that is remote from their physical location. If you have
> data and SAS servers in one location, but your programmers are scattered
> - many over slower wide area network connections, how do you access your
> We have many large projects and programmers on a single project team may
> be in different locations. Ideally, we want to keep the data in one
> location, so everyone is working from the most recent copy. Transferring
> data across the network can be problematic:
> -> We would need to compress it and send it to the programming
> location, then uncompress it. Some tables are too large (>1G) to
> send of the WAN, even when compressed, so alternate media (DVD) would
> have to be shipped.
> -> When delivering data to multiple locations it becomes next to
> impossible to ensure that everyone is working from the most recent data.
> One solution may be SAS on terminal servers, but the costs of "global
> access" from SAS are prohibitive for a server farm that would be
> needed for this approach. Maybe a huge box at the data site where
> folks can log in and do their work?
> I'm interested in any experience you may be willing to share.