Well, short of completing the migration they ought to have done 14-15 years
ago, I'm afraid there's not much to be done. The forced 16-bit alignment
will induce data realignments on half-word boundaries and, if not
necessarily CM switches, other memory management penalties.

Depending on where they come from, they might get away with an N4000. If,
for instance, they migrate from a machine half as powerful and they change
nothing else than the system itself, they may see some improvement. Now, are
they going to complete the native mode migration ? That's dubious at best.

As far as data is concerned, TurboImage on MPE/XL (now /iX) has always been
in native mode, from release 1 and before, but recorded in 16-bit words for
compatibility's sake. One big hit would be if they have exclusive CM data
items, like old CM MPE reals (not IEEE reals, which are handled in NM). Look
for R2, R4 and else data types in the schema. Also have a look in other data
types (flat files ? KSAM ?) they may have alongside their Image databases.

And, last but not least, it's always possible to trap all CM-to-NM and
NM-to-CM switches with debug scripts, but that has a relatively high
performance penalty.

And, oh, where did they purchase their N4000 from ?

Christian Lheureux
Responsable du Département Systèmes et Réseaux / Head of Systems and
Networks Department
APPIC R.H.
business partner hp invent
Tel : +33-1-69-80-97-22   /   Fax : +33-1-69-80-97-14 / e-mail :
[log in to unmask] <mailto:[log in to unmask]>
AIM nickname : MPE Evangelist
"Le Groupe APPIC recrute, contactez nous !"



> -----Message d'origine-----
> De : HP-3000 Systems Discussion [mailto:[log in to unmask]]De la
> part de Xavier Mouton
> Envoyé : mercredi 26 février 2003 12:09
> À : [log in to unmask]
> Objet : [HP3000-L] NM/CM switches and vice versa
>
>
> Hello all,
>
> One company had an old home developped application running on 6.0. For
> migration reasons (what a scoop!), they will replace their
> 9x7 boxes by
> brand new N4000 ones, but running on 7.5...
> Their application was still running on CM mode (Pascal code) and was
> generating numerous CM to NM switches. On high activity period, those
> switches were more than 10,000 per sec (red zone begins by
> 800), inducing
> serious performance damages.
> They migrated their programs to NM mode (but not their data,
> still recorded
> in 16bits format in their DB). They gained better performance
> of course,
> but for a short time : performances were soon as bad as
> before. The reason
> is, if CM to NM switches have been divided by nearly 4, NM to
> CM switches
> have exploded to 3,000 and more (red zone is by 200...),
> inducing memory,
> paging, I/O and sometimes CPU bottlenecks.
> The programs have been re-compiled using the following directives :
> $STANDARD_LEVEL 'HP_PASCAL'$
> $NOTES OFF$
> $HP3000_16$
>
> Prog compilation:
> Pasxl src,objet,$null
>
> Links edit :
> link from=objet1,objet2;to=prg;rl=rlbibxl.pub
>
> Prog exécution :
> run prg;xl="IRISXL.PUB"
>
> Is there any trick to reduce the NM to CM switches ? Do they have to
> necessarily migrate their data to 32bits format ? Is this situation
> compatible to run on N4000/MPE 7.5 ?
>
> Thanks for any enlightenment.
>
> Xavier Mouton
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>

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