Date:         Thu, 31 Jan 2002 09:04:38 -0500
Reply-To:     Jay Stevens <jay@MEDIASHOWER.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Jay Stevens <jay@MEDIASHOWER.COM>
Organization: Posted via Supernews, http://www.supernews.com
Subject:      Re: SAS/Connect dropping chunks of remotely submitted code

Tim,

Any chance that the chunks of code that were dropped had anything to do with
server-side pipes?  Either via the X-statement or via a PIPE filename?

Jay Stevens



"Tim CHURCHES" <TCHUR@DOH.HEALTH.NSW.GOV.AU> wrote in message
news:sc580bbc.068@doh.health.nsw.gov.au...
> Two of our users have independently struck the same problem, viz: when
remote submitting fairly large SAS programs (about 3500 lines) to a remote
server using the "Remote Submit" menu choice (or the iconic equivalent),
sections of the submitted code are randomly dropped and never make it to the
server. This is particularly disconcerting because the resulting errors
generated by the code which does make it to the server are different every
time! At first we suspected network communication problems, but the problem
persists even when the remote server is connected to the same network switch
as the client machine. Shorter chunks of code don't cause problems. Breaking
up the code into smaller chunks surrounded by rsubmit;/endrsubmit; seems to
be a work-around, but this is the second annoying problem we have
encountered with SAS/Connect on V8.2. The first problem is the creation of
"rogue processes" on the server which chew 100% of a CPU whenever a user
aborts a PROC DOWNLOAD in a certain (quite reasonable) way. Despite patches
from Cary, that problem still persists after many months of attempting to
understand and then fix it by SI. For the record we are running Windows NT
4.0 and SAS V8.2 on the clients, and Windows 2000 Server and SAS V8.2 on the
servers, with a standard TCP/IP Ethernet LAN/WAN in between.
>
> Anyone else encountered similar problems? Needless to say, support calls
to SI have been logged for both these problems. V6.12 and V8.1 never gave us
such grief.
>
> Tim C
>
>
> *********************************************************************
> This message is intended for the addressee named and may
> contain confidential information. If you are not the intended
> recipient, please delete it and notify the sender. Views
> expressed in this message are those of the individual sender,
> and are not necessarily the views of NSW Health.
> *********************************************************************