Old Fossil Bama wrote:
> I have the following command to execute:
>
> C:\Program Files\Microsoft Office\Office10\Excel Y:\Lacey.xls
>
> running this with STRPCCMD works great under Bosanova 5250, but
> crashes under every version of Client Access we have with this error
> message in the DOS window:
>
> 'C:\Program' is not recognized as an internal or external command,
> executable program or batch file.
>
> I have tried using DOS naming convention, like
> C:Progra~1\Micros~1\Office~1\Excel Y:Lacey.xls but that does not work
> under Client Access either.
>
> Any suggestions on how to make this work under Client Access?

Omitted, was what exactly was being specified on the PCCMD parameter
for both invocations.? Also the second invocation with DOS naming used
relative paths which was a change from the first.? And "does not work"
was not clarified about the second invocation, to indicate if the error
was the same or different than the first failure.?

Presumably it was not the following being requests, so I would
suggest to try quoting the request; optionally quote the parameter
separately, e.g. if it had embedded blanks in its name:
STRPCCMD PCCMD('"C:\Program Files\Microsoft Office\Office10\Excel"
Y:\Lacey.xls') PAUSE(*NO)

If the problem persists, note that the executable is probably named
excel.exe versus excel, so that might make a difference as well, since
the request is not a /start/ invocation. The shell for a start would
look for any executable with the name, irrespective of extension. But
processing for the PCCMD may cause the PC to look for the named file.
Thus the request suggested would be:
STRPCCMD PCCMD('"C:\Program Files\Microsoft
Office\Office10\Excel.exe" Y:\Lacey.xls') PAUSE(*NO)

An example and reference link:

STRPCCMD PCCMD('"C:\Program Files\Internet +
Explorer\iexplore.exe" +
http://www.google.com')
PAUSE(*NO)
http://archive.midrange.com/midrange.../msg01088.html

Note that calling out excel and iexplore in the above PCCMD requests
forces the named application to be used, instead of allowing the default
file handler application to be invoked according to the file extension.
http://archive.midrange.com/midrange.../msg01086.html

Per above link, a way to effect the user's choice of URL handler
follows in an example and reference link:

STRPCCMD PCCMD('rundll32 url.dll,FileProtocolHandler +
http://www.mywebpage.com?&userid=My+Name') +
PAUSE(*NO)
http://archive.midrange.com/midrange.../msg01079.html

or this example and reference link:

STRPCCMD PCCMD('rundll32 Shell32,ShellExec_RunDLL +
"mysheet.xls"')
PAUSE(*NO)
http://archive.midrange.com/rpg400-l.../msg00304.html

Regards, Chuck

On Aug 11, 5:14*pm, CRPence wrote:
> Old Fossil Bama wrote:
> > I have the following command to execute:
>
> > C:\Program Files\Microsoft Office\Office10\Excel Y:\Lacey.xls
>
> > running this with STRPCCMD works great under Bosanova 5250, but
> > crashes under every version of Client Access we have with this error
> > message in the DOS window:
>
> > 'C:\Program' is not recognized as an internal or external command,
> > executable program or batch file.
>
> > I have tried using DOS naming convention, like
> > C:Progra~1\Micros~1\Office~1\Excel Y:Lacey.xls but that does not work
> > under Client Access either.
>
> > Any suggestions on how to make this work under Client Access?
>
> * *Omitted, was what exactly was being specified on the PCCMD parameter
> for both invocations.? *Also the second invocation with DOS naming used
> relative paths which was a change from the first.? *And "does not work"
> was not clarified about the second invocation, to indicate if the error
> was the same or different than the first failure.?
>
> * *Presumably it was not the following being requests, so I would
> suggest to try quoting the request; optionally quote the parameter
> separately, e.g. if it had embedded blanks in its name:
> * *STRPCCMD PCCMD('"C:\Program Files\Microsoft Office\Office10\Excel"
> Y:\Lacey.xls') PAUSE(*NO)
>
> * *If the problem persists, note that the executable is probably named
> excel.exe versus excel, so that might make a difference as well, since
> the request is not a /start/ invocation. *The shell for a start would
> look for any executable with the name, irrespective of extension. *But
> processing for the PCCMD may cause the PC to look for the named file.
> Thus the request suggested would be:
> * *STRPCCMD PCCMD('"C:\Program Files\Microsoft
> Office\Office10\Excel.exe" Y:\Lacey.xls') PAUSE(*NO)
>
> * *An example and reference link:
>
> * *STRPCCMD * PCCMD('"C:\Program Files\Internet +
> * * * * * * * * * * * * * Explorer\iexplore.exe" +
> * * * * * * * * * * * * * *http://www.google.com')
> * * * * * * * PAUSE(*NO)http://archive.midrange.com/midrange.../msg01088.html
>
> * *Note that calling out excel and iexplore in the above PCCMD requests
> forces the named application to be used, instead of allowing the default
> file handler application to be invoked according to the file extension.http://archive.midrange.com/midrange.../msg01086.html
>
> * *Per above link, a way to effect the user's choice of URL handler
> follows in an example and reference link:
>
> * *STRPCCMD * PCCMD('rundll32 url.dll,FileProtocolHandler +
> * * * * * * * * * * *http://www.mywebpage.com?&userid=My+Name') +
> * * * * * * * PAUSE(*NO)http://archive.midrange.com/midrange.../msg01079.html
>
> * * or this example and reference link:
>
> * *STRPCCMD * PCCMD('rundll32 Shell32,ShellExec_RunDLL +
> * * * * * * * * * * * "mysheet.xls"')
> * * * * * * * PAUSE(*NO)http://archive.midrange.com/rpg400-l.../msg00304.html
>
> Regards, Chuck- Hide quoted text -
>
> - Show quoted text -

Thanks, Chuck. Your example with the double quotes wrapped around the
path worked perfectly!

You say it doesn't work but you don't say what *does* happen. Since
what failed before was the parser (apparently) located the first blank
and called everything else the argument to the command we'd certainly
not expect that same result with the shortnames you specified. Things
I'd try:

- using the original blank-infested command, wrap the command portion
in quotes and retry
- also tack on .exe since that really is what's being executed
contrary to M'soft's predilection for extension-less GUIs
- y:Lacey.xls assumes some default path inside y: -- don't assume, be
explicit eg y:\fulano\mengano\lacey.xls

I also didn't see any specification of just what you are running when
not using Bosanova -- I'd suppose iAWin ? What VRM ? What Windows
OS ? May be irrelevant but ya never know.

Finally, traces are what will tell the tale, and for this I'd
recommend the fine free ProcMon from http://sysinternals.com -- this
will tell you just who launched what and what file I/O occurred. More
rambunctious would be windbg and stop on the call to CreateProcess()
or ShellExecute() or whatever.

Suerte,
Juancho Panza

On Aug 11, 3:21*pm, Old Fossil Bama wrote:
> I have tried using DOS naming convention, like
> C:Progra~1\Micros~1\Office~1\Excel Y:Lacey.xls but that does not work
> under Client Access either.
>
> Any suggestions on how to make this work under Client Access?

Dang, that's what I get for displaying a msg thread one day and
responding the next w/o refreshing the view in between -- I see now
Chuck responded more than adequately already. Sorry for the noise.

On Aug 12, 9:35*am, Jon wrote:
> You say it doesn't work but you don't say what *does* happen. *Since

Jon wrote:
> Dang, that's what I get for displaying a msg thread one day and
> responding the next w/o refreshing the view in between -- I see now
> Chuck responded more than adequately already. Sorry for the noise.
>
> On Aug 12, 9:35 am, Jon wrote:
>> You say it doesn't work but you don't say what *does* happen. Since

I am glad I am not the only one who does that! :-) I use /hibernate/
on my PC all the time, often in the middle of composing a reply, such
that when I return to finalize and send, my post is by then, a somewhat
redundant reply. No matter, even if I could have easily looked before
sending. Because sometimes even the slightest bit of difference in
wording, or just one tidbit more of information may help to clarify for
someone. And if not presently for the OP, then perhaps for someone
researching a similar issue in the future. So certainly your post was
not just noise, nor is an apology necessary, especially since I learned
something from your post that I might never have learned otherwise. :-)

Please do consider posting anyhow, even if you do see a sufficient or
even good response. FWiW when I do notice another post, I just prefix
my post with "I see that Xxx already responded sufficiently, so this may
be somewhat redundant..." or some such. I always keep in mind, that the
newsgroup articles will serve as an archive that can be searched [and
tokens in my message may differ from another], and that my contribution
may be just enough [more] to assist someone in the future, even if it
seems mostly redundant now.

Regards, Chuck