From: Tom Abernathy on
Collin -
Check the location of you WORK directory and the current working
directory under both start methods and see if they are different.
%put %sysfunc(pathname(work));
libname current '.';
%put %sysfunc(pathname(current));

If they are different then perhaps one of them is full or readonly.
- Tom

On Feb 22, 11:41 am, collin.ell...(a)ITRON.COM (Collin Elliot) wrote:
> On Sat, 20 Feb 2010 15:02:28 -0500, Michael Raithel

> >> Stderr output:
> >> There is not enough space on the disk.
> >> NOTE: 0 records were read from the infile RAL.
> >> NOTE: The data set WORK.SETUP has 0 observations and 1 variables.
> >> NOTE: DATA statement used (Total process time):
> >>       real time           1.01 seconds
> >>       cpu time            0.03 seconds
>
From: Andrianarivo RAMAMONJY on
On 22 fév, 17:41, collin.ell...(a)ITRON.COM (Collin Elliot) wrote:
> On Sat, 20 Feb 2010 15:02:28 -0500, Michael Raithel
>
>
>
>
>
> <michaelrait...(a)WESTAT.COM> wrote:
> >Dear SAS-L-ers,
>
> >Collin Elliot posted this interesting issue:
>
> >> I'm not sure if this is for someone with expertise in filename pipe or
> >> systems architecture, but I'm hoping that among the geniuses on this
> >> listserv there is someone who can help me.
>
> >> One of my practices is to create a SAS shortcut in the folders for my
> >> more
> >> significant projects. I change the properties to have these shortcut
> >> point
> >> to an autoexec file that establishes the libnames, etc. One part of the
> >> autoexec includes a filename pipe that gets me a listing of all my code
> >> files that then feeds into a macro that creates file shortcuts for me.
>
> >> I have never had issues with this practice until this week when I began
> >> to
> >> work on a new server with Windows Server 2008 R2 Standard.
>
> >> I created the shortcut, which worked fine in terms of starting SAS and
> >> running the autoexec file, but when it got to the filename pipe, I get
> >> the
> >> following in the log:
>
> >> LOG CONTENTS START:
>
> >> NOTE: AUTOEXEC processing completed.
>
> >> 1
> >> 2      filename ral pipe 'dir /S "O:\SCE\CSI_ImpactEval"';
> >> 3
> >> 4      data setup;
> >> 5        infile ral truncover;
> >> 6        input contents $150.;
> >> 7      run;
>
> >> NOTE: The infile RAL is:
> >>       Unnamed Pipe Access Device,
> >>       PROCESS=dir /S "O:\SCE\CSI_ImpactEval",RECFM=V,
> >>       LRECL=256
>
> >> Stderr output:
> >> There is not enough space on the disk.
> >> NOTE: 0 records were read from the infile RAL.
> >> NOTE: The data set WORK.SETUP has 0 observations and 1 variables.
> >> NOTE: DATA statement used (Total process time):
> >>       real time           1.01 seconds
> >>       cpu time            0.03 seconds
>
> >> LOG CONTENTS END.
>
> >> If I try to run this code from the SAS session that the shortcut
> >> launched, I
> >> get the same result, so it does not seem that it's because the code is
> >> in
> >> the autoexec.
>
> >> However, here is the curious (and frustrating) part. When I start SAS
> >> via
> >> the shortcut in the START menu and then run the same code, it does what
> >> is
> >> supposed to do.
>
> >> LOG CONTENTS START:
>
> >> NOTE: This session is executing on the W32_SRV08  platform.
>
> >> NOTE: SAS initialization used:
> >>       real time           2.06 seconds
> >>       cpu time            0.99 seconds
>
> >> 1
> >> 2    filename ral pipe 'dir /S "O:\SCE\CSI_ImpactEval"';
> >> 3
> >> 4    data setup;
> >> 5      infile ral truncover;
> >> 6      input contents $150.;
> >> 7    run;
>
> >> NOTE: The infile RAL is:
> >>       Unnamed Pipe Access Device,
> >>       PROCESS=dir /S "O:\SCE\CSI_ImpactEval",RECFM=V,
> >>       LRECL=256
>
> >> NOTE: 16840 records were read from the infile RAL.
> >>       The minimum record length was 0.
> >>       The maximum record length was 209.
> >> NOTE: The data set WORK.SETUP has 16840 observations and 1 variables.
> >> NOTE: DATA statement used (Total process time):
> >>       real time           6:18.16
> >>       cpu time            0.21 seconds
>
> >> LOG CONTENTS END.
>
> >> I cannot even begin to understand why launching SAS from a different
> >> shortcut would have an effect on how the code would run, but if anyone
> >> here
> >> has any insights or, even better, solutions, I will be very
> >> appreciative.
> >> And yes, I know I could just use the default icon and then run my code
> >> manually, but I find it very convenient and efficient to do so via an
> >> autoexec,particularly when I've never had issues with this before.
>
> >> Thank you very much in advance.
>
> >Collin, wow; now that is a head-scratcher for sure!  Since the advice that
>
> a couple of other "geniuses on this listserv" isn't panning out, here is
> some from another... of the afore-mentioned personages:-)
>
> >Considering that this is a new Windows server, maybe there are permission
>
> issues at play here.  I just did the following on my workstation, and maybe
> you can do it on your server:
>
> >1. Click on your <Start> menu, highlight <SAS 9.2 (English)> with your
>
> cursor, then right click on <Properties> to bring up the "SAS 9.2 (English)
> Properties" box.
>
> >2. Single click on your new SAS icon to highlight it, then right click,
>
> then click on <Properties> to bring up the "SAS 9.2 (English) Properties" box.
>
> >3. Compare the values of the various tabs in the two property boxes;
>
> especially the SECURITY Tab (and then the Target field in the Shortcut window.
>
> >I am thinking that you will find some significant difference in the way
>
> security was set up for all SAS users who invoke it via <Start><SAS> and for
> those who invoke it via setting up an icon on the desktop.  It's worth a
> try... until some other SAS-L "genius" chimes in:-)
>
> >Collin, best of luck in all your SAS endeavors!
>
> >I hope that this suggestion proves helpful now, and in the future!
>
> >Of course, all of these opinions and insights are my own, and do not
>
> reflect those of my organization or my associates. All SAS code and/or
> methodologies specified in this posting are for illustrative purposes only
> and no warranty is stated or implied as to their accuracy or applicability.
> People deciding to use information in this posting do so at their own risk.
>
>
>
>
>
>
>
> >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >Michael A. Raithel
> >"The man who wrote the book on performance"
> >E-mail: MichaelRait...(a)westat.com
>
> >Author: Tuning SAS Applications in the MVS Environment
>
> >Author: Tuning SAS Applications in the OS/390 and z/OS Environments, Second
> Edition
> >http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=58172
>
> >Author: The Complete Guide to SAS Indexes
> >http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=60409
>
> >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >If it's sent by ship then it's a cargo, if it's sent by road
> >then it's a shipment. - Dave Allen
> >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> This is that point in a thread where one (in this case, I) considers not
> continuing because it displays one's ignorance and/or stupidity.
>
> It certainly makes sense that it's related to permissions and there are
> certainly differences in the properties on the security tab, but there's a
> lot going on and I'm clueless about which matter for this particular
> problem. For starters, the groups/user names are not equivalent between the
> two. For example, on the copied icon, I have a user name whereas on the
> original I icon I do not.
>
> In any event, I think that you've got me on the right track and I should
> leave this forum and take it up with my IT department. If I can first
> convince them that I'm even worth the oxygen I breathe - no small feat -
> maybe they can help me figure out what specific permissions need to change
> to resolve this issue.
>
> Thank you very much.
>
> Collin- Masquer le texte des messages précédents -
>
> - Afficher le texte des messages précédents -- Masquer le texte des messages précédents -
>
> - Afficher le texte des messages précédents -

Hi Collin,
I'm experiencing the same issue in Windows 7. Maybe my own observation
will help you find the final solution to this.
So what I've found out is that when you pin the shortcut on the
taskbar or on the start menu, the pipe works fine.
When the shortcut resides anywhere else, the pipe issues the message
"there is not enouth space on the disk".
To pin a shortcut on the taskbar on on the start menu, the right click
on it and click on "Pin to taskbar" or "Pin to start menu".
Maybe a program run from the desktop does not have the same same right
as a program run from the task bar or a thing like that...
Hope this will help us.
Rivo.