HP3000-L Archives

November 2006, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Johnson, Tracy" <[log in to unmask]>
Reply To:
Johnson, Tracy
Date:
Thu, 2 Nov 2006 08:57:17 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (54 lines)
Sean Bruce writes:
 
> It seems to me that MPEX has to "compile" or "build" its 
> commands if they aren't there. I'd wonder if subsequent use 
> of the same command is any faster.
> 
> Bruce.

For flexible LISTF that you design, yes that's exactly how it 
works.  Although the default LISTF commands were compiled when 
you installed it.

I imagine one of the reasons VESoft Tech support sometimes has you
purge the compiled commands is that it may be possible they become 
corrupted or fragmented.  They get recompilied the first time they 
are used.  Recompiling "may" put them on a contiguous or "happier" 
set of disc sectors.  But that is a real long shot I think.

There are other mitigating circumstances that may slow down MPEX
commands.  Check out your MPEXMGR file in the PUB group of the
VESOFT account.  Perhaps your predecessor customized it too 
heavily?  

Or you can try 

SETJCW MPEXFASTSTART=1

This will tell MPEX *not* to load UDCs and MPEX help files into 
your current SESSION.  See if MPEX is any faster.

This may be an indicator you have extensive UDCs that are slowing 
down your MPEX.

The best method of fixing your MPEX is to have Vladimir pay you
a house call.  He travels around the country as an itinerant MPEX
trainer and may be in your area about twice a year.  Half a day 
is about 500 bucks.

Tracy Johnson
Measurement Specialties, Inc. 

BT







NNNN

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2