STRPCCMD works on Bosanova not on ClientAccess - IBM AS400

This is a discussion on STRPCCMD works on Bosanova not on ClientAccess - IBM AS400 ; 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 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: STRPCCMD works on Bosanova not on ClientAccess

  1. STRPCCMD works on Bosanova not on ClientAccess

    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?

    many thanks...

  2. Re: STRPCCMD works on Bosanova not on ClientAccess

    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

  3. Re: STRPCCMD works on Bosanova not on ClientAccess

    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!


  4. Re: STRPCCMD works on Bosanova not on ClientAccess

    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?


  5. Re: STRPCCMD works on Bosanova not on ClientAccess

    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


  6. Re: STRPCCMD works on Bosanova not on ClientAccess - OT reply

    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

+ Reply to Thread