LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (May 2004, week 2)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Thu, 13 May 2004 10:11:59 +0100
Reply-To:     Nigel.Pain@SCOTLAND.GSI.GOV.UK
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
Comments:     To: novastaylor@HOTMAIL.COM
From:         Nigel Pain <Nigel.Pain@SCOTLAND.GSI.GOV.UK>
Subject:      *****spam***** Re: Moving from SAS/CONNECT to ? : SAS Terminal
              Servers? Hardware specs?         Advice?
Content-Type: text/plain; charset="us-ascii"

******************************************************************************************************************************************************* This email and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. *******************************************************************************************************************************************************

I can't comment on terminal services but one option might be using Enterprise Guide and SAS Integration Technologies. EG is a thin client as far as SAS processing goes (it's another matter if you use it directly to import data). You can write code manually or use the point & click tasks to define what you want to do and then send off the code to be run on the server. The only bandwidth you are using is to send the code (written or task-generated) to the server's spawner process and receive the results back to your EG session. This is the main model for use here - not because of low bandwidth but because of another positive feature of using EG - it costs less to put on desktops than a full copy of SAS! However, we have had one user (so far!) connecting from home through ADSL broadband (512Mbps download, 256Mbps upload) and a VPN, and reporting no noticeable difference in performance.

In terms of administration, we have three servers hosting SAS (soon to be "rationalised" to one) in different locations and support staff also distributed. The servers are actually running Solaris but we do administer Windows servers using Terminal Services (administration of our Solaris servers is done with terminal sessions through X server software). One of the features of Enterprise Guide is that, if you want to centralise the configuration, you can use a repository server. Here you can define servers, users, libraries, cubes if you use MDDB and other resources and the connection process is transparent to the users. The repository server doesn't need to have much of a hardware spec. (ours is a standard 1.7GHz Pentium 4 desktop model with 256Mb RAM, running W2K server). The repository administration software occupies approximately 20Mb disk space, including 1.5Mb for the data for about 160 users. If your SAS server(s) are Windows machines then you can use DCOM to handle connections to them (in a UNIX shop we have to use an IOM bridge). All this means that for most administrative tasks we don't have to be in the same physical location as the servers.

Hope this is helpful.

*************************************************** Nigel Pain Scottish Executive Analytical Services Team Victoria Quay EDINBURGH EH6 6QQ UK Tel +44 131 244 7237 Website: http:\\

> -----Original Message----- > From: Nova's Taylor [mailto:novastaylor@HOTMAIL.COM] > Sent: 13 May 2004 02:41 > Subject: Moving from SAS/CONNECT to ? : SAS Terminal Servers? Hardware specs? > Advice? > > Hi folks, > > The company I work for has recently outgrown the SAS/CONNECT, > remote-submit model and we are now looking at alternative > architectures. We have several offices worldwide and programming > teams may work cooperatively on projects that are remote from their > home office. Wide area network bandwidth makes SAS/CONNECT > impractical. > > We have reached a critical decision point: How do we proceed? Perhaps > we should move to a system where SAS is available on a Terminal Server > Farm of 2-3 servers per site, where users login, start up the SAS/DMS > on the remote machine, and work there? What if we switch to batch mode > - will users rebel at the lack of an enhanced editor, or love the > simplicity of a commmand line? > > Other background info: We are a Microsoft shop, so Windows 2003 Server > would be the OS. I have no choice in that matter. We are not > interested in SAS/IntrNet or a Portal solution. > > I am looking for anyone who would like to share their experiences from > both a user and admin perspective. I will be working with SAS to > determine potential hardware specifications, but would like to hear > from individuals "in the field" in terms of server specs, > configuration, and approaches. Are you running interactive SAS? Batch > SAS? SAS DMS on terminal servers? How have you solved the "resource > pooling" issue where your program team is spread out, but your data is > centralized? Maybe there is an approach that I am overlooking? > > Any help would be greatly appreciated. Please email me offline at > and I will gladly summarize my findings for > SAS-L at a later time. > > > Taylor > SAS Admin >

The original of this email was scanned for viruses by the Government Secure Intranet (GSi) virus scanning service supplied exclusively by Energis in partnership with MessageLabs.

On leaving the GSi this email was certified virus-free

Back to: Top of message | Previous page | Main SAS-L page