2

I've been doing an OS-COMMAND that execute the -p "procedure.p" with -param that are inside a loop.

My question is how can I handle the number of prowin32.exe that will not spawn too much so it won't consume all my processor and also not less to make it fast?

Note: Version 8.3c

Sample Code

DEFINE VARIABLE Filter AS CHARACTER NO-UNDO.

For Each Item No-lock:
    Assign Filter = "Item.Item = " + Item.Item NO-ERROR.
    OS-COMMAND NO-WAIT
    VALUE("C:\dlcs\83c\bin\prowin32 " +
          "-p C:\nanox\syte_server5\ATMS-CONFIGURED-ICONS\LIVE\Nanox_utility\procedure.p " +
          "-pf C:\nanox\syte_server5\ATMS-CONFIGURED-ICONS\LIVE\Nanox_utility\Conf\pilot.pf " +
          "-param " + Filter).
END.
QUIT.
  • You could put a counter inside the loop and pause if you reach a certain number. Post your code for a better understanding of the problem. – Jensd Mar 10 '14 at 06:59
  • I know this will spawn a ridiculous amount of prowin32.exe. But what i want to know is when to stop opening prowin32 then run another when the other completes. – Mark-L Earth-616 Mar 10 '14 at 07:14
  • Then you will need some kind of way to tell if it's ready or not. Either a table in the DB or a file on the disk (or another solution). – Jensd Mar 10 '14 at 07:19
  • Is it appserver an option for you? This looks like something to be managed using it... – pedromarce Mar 10 '14 at 11:00

2 Answers2

2

I would do it a bit differently. Decide ahead of time how many threads and then divvy up the work like so:

/* worker.p
 *
 * i.e.:
 *   mbpro dbName -p worker.p -param "0,5"
 *   mbpro dbName -p worker.p -param "1,5"
 *   mbpro dbName -p worker.p -param "2,5"
 *   mbpro dbName -p worker.p -param "3,5"
 *   mbpro dbName -p worker.p -param "4,5"
 *
 * in this sample the threadNum starts at 0 -- so end it at numThreads - 1
 *
 */ 

define variable threadNum  as integer no-undo.
define variable numThreads as integer no-undo.

assign
  threadNum  = integer( entry( 1, session:parameter ))
  numThreads = integer( entry( 2, session:parameter ))
.

for each item no-lock where (( item.item modulo numThreads ) = threadnum ):

  /* whatever */

end.

return.

For starters I suggest that numThreads be roughly the number of cores available in the server.

Also, headless batch processes shouldn't be using prowin32.exe. They should use _progres.exe.

8.3 is unspeakably ancient, obsolete and unsupported. Is this system running on a single core Pentium with Windows 3.11? That's relevant because the 8.3 "workgroup edition" will not behave very well if this is a multi-core system. If it is "enterprise" it won't be so bad. But even so you'd be very well advised to upgrade to a current release (11.3 as of this writing) if performance is at all important to you.

Tom Bascom
  • 13,405
  • 2
  • 27
  • 33
0

I do not work with version8.3, but it must pass (possibly replace the temp-table by a work-table).
Here I what I certainly do but it must improve:

DEFINE TEMP-TABLE ttpid NO-UNDO
    FIELD pid AS CHARACTER
    FIELD SIZE  AS CHARACTER
    INDEX i1 IS UNIQUE PRIMARY pid.

DEFINE VARIABLE wline AS CHARACTER   NO-UNDO.
DEFINE VARIABLE wfile AS CHARACTER   NO-UNDO.

wfile = "c:/tmp/list_tasklis.txt".

OS-COMMAND SILENT VALUE("tasklist > " + wfile).


INPUT FROM VALUE(wfile).

REPEAT:
    IMPORT UNFORMATTED wline.
    IF wline BEGINS "prowin32.exe" 
    THEN DO:
        DO WHILE wline MATCHES "*  *":
            wline = REPLACE(wline, "  ", " ").
        END.
        FIND FIRST ttpid 
             WHERE ttpid.pid = ENTRY(2, wline, " ")
             NO-LOCK  NO-ERROR.
        IF NOT AVAILABLE ttpid 
        THEN DO:
            CREATE ttpid.
            ASSIGN ttpid.pid  = ENTRY(2, wline, " ")
                   ttpid.SIZE = ENTRY(5, wline, " ").
        END.
    END.
END.

INPUT CLOSE. 

FOR EACH ttpid
    NO-LOCK:
    MESSAGE "PID  =" ttpid.pid SKIP 
            "SIZE =" ttpid.SIZE
        VIEW-AS ALERT-BOX INFO BUTTONS OK.
END.


OS-DELETE VALUE (wfile) NO-ERROR.
doydoy44
  • 5,720
  • 4
  • 29
  • 45