APYR3FIX 7.01 performance... TIP

[Former Member]

Hi,

I'm patching the new 7.01 Unicode kernel with the APYR3FIX provided in this kernel. Things have changed and the performance of this tool ( in comparison with 6.40 Unicode kernel ) has been lost.

As far I know, APYR3FIX unpacks the SAR file in /usr/sap/tmp/apysap, creates another directory with a copy of the actual kernel in same directory and finally creates a new directory with a merge of the previous ones ( from my observations ). It means that for a simple patch, a new kernel is generated and this is very slow. Let me know if I'm wrong, please.

So it's necessary to apply all patches at same time to just generate the new kernel once. I've used APYR3FIX in this way:

APYR3FIX SID(<SID>) SAVF(QTEMP/PATCH) SAVLIB(GEN701UOPT) KRNLIB(R3701U30) FROMDIR('/tmp') FROMFILE('*.SAR')

It works, but it has a hidden problem: if you put several .SAR files in the /tmp directory, and some of them contains the same object, which one will be the applied ?? Probably the one present in the patch last decompressed, which probably is not the most recent.

Regards,

Joan

[Former Member · Accepted solution]

Hello Joan,

the parameter FROMFILE('.SAR') was never intended to work with masked input () - indeed we expected to see a fully qualified name here. So we tested the command the way you entered it and found that it happens to work - but your suspicion is correct: with the same object being in two patch files the last one unpacked will win, and this need not be the most recent one. So for the time being we strongly recommend to use parameter FROMFILE with a fully qualified name only.

On the other hand your argument concerning the performance is correct. Therefore we started to work on a patch of APYR3FIX, which will allow an input like yours with FROMFILE('*.SAR'), where we guarantee that only the most recent object will be put into the kernel library, if duplicate names exist.

Thanks for bringing this matter to our attention

B. Wolf, SAP AG

Edited by: Bernhard Wolf on Feb 19, 2009 11:48 AM