layout object purpose number directly?

if I have an ID for a layout shape, a "rect" for example,  I can get the layer number directly with

printf("Layer number = %u\n" fig->layerNum)

But to get the purpose number it seems I have to use

printf("Purpose number = %u\n" techGetPurposeName(tech, fig->purpose))

Is there a way to directly get the purpose number without invoking the tech file?  Similarly, for an MPP there doesn't seem to be a way to directly get at the purpose *or* layer number without going through the tech file.

But... I was looking at transferring some layouts from one technology to a different one where the layer numbers and purposes numbers are all different and may or may not have the tech lib for both the old and new technologies loaded at the same time.  For schematics, I just copy in unix-land (with tar) and then remaster all of my PDK instances and refer to a table that maps properties over and triggers callbacks, etc.  That seems to be working fine (yay for graphically compatible symbols).  On the layout end I was going to do  a similar thing (copy in unix-land, and then fix with skill code).  But I'm stuck on finding out the purpose number on shapes without invoking tech files which may or may not actually be accessible from the virtuoso session which is trying to fix up the layers.  What I had envisioned originally was something like

foreach(fig cv~>shapes

    old_lpp_nums = list(fig->layerNum,  old_purpose_num)  ;; but how to get old_purpose_num?  

    new_lpp_nums = conversion_table[old_lpp_nums]

    fig->layerNum = car(new_lpp_nums)

    fig->purpose = techGetPurposeName(tech_new, cadr(new_lpp_nums))  ;; would have been nice to have a ->purposeNum

)

to make matters worse, MPPs don't seem to give access to the layer number or purpose number in the subPart definition:

rodGetObj(fig)~>subParts~>layer  ;; is a string unless the layer is not defined in the tech file, then a number

rodGetObj(fig)~>subParts~>purpose ;; is a string unless the purpose is not defined in the tech file, then a number

so that translation looks like checking if I get integers or strings and if strings then use the new tech file to convert to numbers, then convert numbers with the old to new table, then convert back to strings with the new tech file.  Seems messy at best.

Am I asking for problems by allowing two different PDK libraries to exist in my cds.lib at the same time (what it would take I think to be able to gain access to both the old and new technologies simultaneously).

Maybe I should be using stream map files or even PVS so I can do logical operations if needed instead of directly fixing with skill code.

Thanks for any tips or pointers.

-Dan