[Robelle-l] Administrative problem
Neil Armstrong
neil@robelle.com
Tue, 09 Jul 2002 09:41:10 -0400
At 08:56 AM 7/9/2002 -0400, Leonard_Berkowitz@harvardpilgrim.org wrote:
>Here is the code we are using:
>
>BASE HEALTH.DATA,1,?
><writepass>
>INPUT ARCHSR00.PUB
>DEFINE SRV,13,16,DISPLAY
>EXTRACT SRV
>SORT SRV
>OUTPUT ARCHSRSV.PUB
>DUPLICATE NONE KEY
>XEQ
>GET COUNTER
>DEFINE CNTR,COUNTER-KEY[1],10
>TABLE SRVTAB,SERV#,SORTED,ARCHSRSV.PUB
>TABLE CNTTAB,CNTR,FILE,ARCCNTTB.PHCDBASE
>IF $LOOKUP(SRVTAB,SERV#) AND NOT $LOOKUP(CNTTAB,CNTR)
>OUTPUT ARCHCC00.PUB,APPEND
>DELETE
>EXIT XEQ
>
>The problem is that the input for the deletes is in a memory table
>(SRVTAB), so we have no way of tracking the progress of the job as we would
>if the input were a file. Is there a solution?
I want to understand what it is you are trying to track, is it the time
it takes to load the tables in the two table commands? Once the tables
are loaded, progress messages would print out by default if the counter
dataset has more than 50,000 records in it, or you could change the
default with the set progress command as follows:
>set progress percent 5 min 1000
This means print progress messages every 5 percent if the dataset
has over 1000 records.
I was confused by the statement you make that says:
"The problem is that the input for the deletes is in a memory table"
This is not entirely true, the input source is the dataset counter,
the tables are just used to compare certain values. The tables are
loaded at command execution time, for example, when the table command
is typed, and unfortunately we have no progress messages on this.
Now you don't mention what version you have, but in Suprtool version
4.5 and higher we improved the loading of a table by as much as 28%,
and subsequent searches thru a table by as much as 33%. So while you
do not get progress messages on the loading of a table, the table
command has had a significant performance improvement. We later improved
the performance even further by reducing and almost entirely eliminating
CM to NM switches in a lot of cases. This improved performance even
further, but I did not measure this particular case.
I hope you can clarify what it is you want to track so we can
consider it as an enhancement.
Sincerely,
Neil Armstrong
Robelle
>I would be willing to
>sacrifice some speed in processing the input to be able to keep track.
>
>Thanks.
>--
>Leonard S. Berkowitz
>Perot Health Care Systems
>(Harvard Pilgrim Health Care account)
>voice: 617-509-1212
>fax: 617-509-1955
>pager: 781-226-2431
>
>_______________________________________________
>Robelle-l mailing list
>Robelle-l@robelle.com
>http://two.pairlist.net/mailman/listinfo/robelle-l