I had a similar problem in v6, i think i posted about it. SAS said fixed in v9. SAS say it is to do with the line sizes on local and remote machines. i begged to differ, but that wasn't acceptable. the problem was usually seen around a macro variable where eg &x would sent to remote as & x and some following code may have been lost.

my fix was to never remote submit my code. instead i used proc uploads to send the code stream as a file from mainframe to unix, then remote submiteed a little one line %include of that code. so the code is loaded locally and we never had a problem again.when i get to work today i'll try to find time to post the macro i wrote to do this.

don

Jay Stevens wrote: > > 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. > > *********************************************************************

-- Don Stanley, B.SC, Dip O.R.S, MNZCS EMAIL:: don_stanley@xtra.co.nz, don@sysware.co.nz Author:: Beyond the obvious with SAS Screen Control Language. Author:: Solutions for your GUI Applications Development Using SAS/AF FRAME Technology http://www.sysware.co.nz , http://www.geocities.com/don_stanley_nz/don_home.htm