Why is GUI app taking longer to run dos batch file?

C

cthulhugeek

New Member
Hi,

I have a batch file that submits a progress created html file to the fax server. When I run this from the character version it takes 10 - 12 seconds, when I run it from the gui version it takes 4-5 minutes. The wierd thing is that it does eventully work. I am using the command "DOS SILENT" command. I am assuming maybe the dos shell and the gui shell programs use memory/proccessing priority different? Not sure, any ideas? Any help would be greatly appreciated, as I am completly stumped.

The bat file sendfax.bat is as follows:

del c:\temp\submit*.*
"C:\Program Files\Castelle\FaxPress\SimpleFax Utilities\SubmitFax" /s
u SUPERVISOR /p /r %1 /c NO COVER PAGE /a %2 /o C:\temp /x NONE /V


Thanks,
Don Foley
www.donaldcfoley.com
http://us.imdb.com/name/nm1975841/
 
just a stab but why not OS-COMMAND CALL <some bat file> ?

if that doesn't help could you replicate the problem and post a short procedure that we could play around and debug
 
I tried OS-COMMAND also, but it does not make a difference. This can be brought down to one line of progress code.

OS-COMMAND SILENT sendfax.bat VALUE("5551212") VALUE("c:\temp\test.htm").

This one line will take 10-12 seconds running from the character editor, and 4 or 5 minutes running from a gui progress editor. I can't figure out why.


I ran a test with this code:
DISPLAY "START" STRING(TIME, "HH:MM:SS").
OS-COMMAND SILENT f:\guiswb\sendfax.bat VALUE(...myfaxnumber...)
VALUE("c:\temp\ack180181.htm").
DISPLAY "END" STRING(TIME, "HH:MM:SS").

When running in character editor I got:
START 13:03:18 END 13:03:29

When running the same code in gui procedure editor I got:
START 13:05:22 END 13:10:37

So in the chui I got 11 seconds, and in the gui I got 5 minutes. I am stumped how to fix this. It looks like the way the two programs shell is different. Any ideas how to speed this up?

Don
www.donaldcfoley.com
 
Hi Don,

Unfortunately, I won't be able to try the code over here since I don't have sendfax.bat. If you could find a way to either replicate the problem that we could try ourselves I bet someone here could track down and fix the problem.

Nothing sticks out but I also have experienced some quirky behavior with SILENT, NO-WAIT, if quotes were used and even if the first executable was a batch. BTW is the session in batch-mode, AppServer/WebSpeed or anything else that might be worth noting.

I think, Progress uses a simple cmd.exe /c <something> or similar to shell out which explains all these quirky behaviors, especially, whenever quotes are involved.

What about a simple OS-COMMAND without SILENT just to see if that makes any difference. I'd also use call sendfax.bat. Personally, I'd also use one expression and one VALUE but I doubt that has anything to do with it.

If that doesn't work, maybe, try using win api's to launch the executable, maybe, generate a shortcut or, maybe, generate one batch and run that. Good luck and tell us if we can help and once you've solved the problem.
 
[Edit: I think I spoke to soon, that thing in the fax program may have been there already, because it has not worked again.]

Thanks, your comments made me try some things, that ended up fixing the problem. It seems if I run it with no-wait, it comes back immediatly, and a few minutes later the fax shows up on the fax software. Awesome, even faster than before.

Don
 
Well, actually, it's still taking a few minutes, sounds like it.

It's just that it's running in the background and the procedure continues without waiting for the operation to end.

I mean there's still something shtrange happening there. It's not that its fixed, maybe, hidden.

If you're still game I'd like to try either using win api's or generating a shortcut ? Shouldn't take long.


Man, I'd really like to get to the bottom of all these OS-COMMAND quirks one day.
 
Sure, I am not sure how to do it as an API, I think I could figure out shortcut. I am retrying this with a differnt order number to make sure the no-wait thing works or doesn't. If it does, than that would fix it. I am so curious why os-command works differently, I know they both run cmd.exe, and I assuming that one uses switches that the other doesnt or something like that. I have called progress tech for some answers there also.

Don
 
Give this a try.

Try it first from the editor.

Code: 
run win_createProcess(    
    input 'c:\test.bat "hello world"',
    input '',
    input 1 ).



procedure win_createProcess:

    define input param pcCommandLine    as char no-undo.
    define input param pcCurrentDir     as char no-undo.
    define input param piWindowState    as int no-undo. /* 0=hidden, 1=normal, 2=minimized, 3=maximized */

    define var lpStartupInfo        as memptr no-undo.
    define var lpProcessInformation as memptr no-undo.
    define var lpCurrentDirectory   as memptr no-undo.

    define var hProcess             as integer no-undo.
    define var hThread              as integer no-undo.
    define var iReturnValue         as integer no-undo.

    do on error undo, leave:

        set-size( lpStartupInfo )       = 68.
        put-long( lpStartupInfo, 1 )    = 68.
        put-long( lpStartupInfo, 45 )   = 1.
        put-short( lpStartupInfo, 49 )  = piWindowState.

        set-size( lpProcessInformation) = 16.

        if pcCurrentDir <> "" then do:

            set-size( lpCurrentDirectory )      = 256.
            put-string( lpCurrentDirectory, 1 ) = pcCurrentDir.

        end.   

        run CreateProcessA (
            input   0,
            input   pcCommandLine,
            input   0,
            input   0,
            input   0,
            input   0,
            input   0,
            input   ( if pcCurrentDir = "" then 0 else get-pointer-value( lpCurrentDirectory ) ),
            input   get-pointer-value( lpStartupInfo ),
            input   get-pointer-value( lpProcessInformation ),
            output  iReturnValue ).

        assign
            hProcess = get-long( lpProcessInformation, 1 )
            hThread  = get-long( lpProcessInformation, 5 ).

    end. /* do on error */

    if hThread  <> 0 then run CloseHandle ( hThread,    output iReturnValue ).
    if hProcess <> 0 then run CloseHandle ( hProcess,   output iReturnValue ).
  
    set-size( lpStartupInfo )           = 0.
    set-size( lpProcessInformation )    = 0.
    set-size( lpCurrentDirectory )      = 0.

    if hProcess = 0 then
        return error.

end procedure. /* win_createProcess */



procedure CreateProcessA external "kernel32.dll":

    define input    param lpApplicationName     as long.
    define input    param lpCommandline         as char.
    define input    param lpProcessAttributes   as long.
    define input    param lpThreadAttributes    as long.
    define input    param bInheritHandles       as long.
    define input    param dCreationFlags        as long.
    define input    param lpEnvironment         as long.
    define input    param lpCurrentDirectory    as long.
    define input    param lpStartupInfo         as long.
    define input    param lpProcessInformation  as long.
    define return   param bResult               as long.

end procedure.

procedure CloseHandle external "kernel32.dll":

    define input    param hObject       as long.
    define return   param ReturnValue   as long.

end procedure.
 
Thank you! Thank you! Thank you! That works incredibly well. It even shows up on the server in 2 or 3 seconds. Better than the chui version even. Sweet!

Don Foley
 
This is a snippet from my win api library.

But this and many others were first written based on Jurjen Dijkstra win api publications, samples, library etc.

More win api goodies
http://www.oehive.org/win32api



With all the quirky behavior we've seen with the Windows OS-COMMAND when quotes are involved, run from inside a batch etc. etc. and this certainly isn't the first post I've run into trying to figure out whats happening.

It might be kind of useful to write our own Windows OS-COMMAND implementation.
 
You must log in or register to reply here.
Back
Top