How are you doing on Version 6
#3
Posted 05 December 2006 - 08:04 AM
I've only looked at it briefly on Windows, since its not available for our Unix version yet. So we havent been able to do any major testing.
We've looked at getting our native functions into V6 without using VIP and started to think about what we need to do in that respect.
No major hurdles there though at the moment...
Rob.
#8
Posted 02 January 2007 - 10:29 PM
Before that, we were unable to gen our app in V6.
We are hoping to be able to start testing in a few weeks, but it depends on PRO-IV.
Mark
#10
Posted 18 January 2007 - 02:52 PM
Now that our kernel has a v6.0 release, this is my findings so far:
Found a few problems with installation, but nothing that we could not work around. There were also a few bugs with the client, but nothing too major.
We had to convert all our 'C' routines that were linked into the Kernel to use the new shared library method, but this was not much of an effort.
We started out by trying to do V5.5 Native to V5.5 VIP, then V5.5 VIP to V6.0 ProIV Developer. After 3 days of converting and messing around I gave up. VIP is still terrible and just not worth the time & effort to look at. About 150 of our functions did not even gen once in VIP.
So, I spent 2 hours writing a Native 5.5 to Native 6.0 conversion function, and it converted all our code from 5.5 to 6.0 in 30 minutes, with 0 gen errors once in V6.0 … Now why could they have not done this!!!
We now had our Native ProIV 5.5 code in V6.0 and it worked fine.
I also converted my old Native editor (ROBFUN) to use the V6.0 bootstraps, so now we have a V6.0 editor also (Sometime soon, IDE will support V6 also).
Firstly, we tried to run our 'End Of Period' Charging and Invoice run, as this is our biggest, most complex and performance critical process. This ran fine with no errors, and there was no difference in run times either. So that was a good start.
We also look at the new Gateway (Bus & Tasks), and the performance here was much better if you called a single call many times, but it was much slower if you called simultaneous calls constantly. This was not so good.
That's as far as we have got so far, and since its an 'unofficial' project here and I'm busy on another project we probably wont be doing too much more at this point.
The biggest problem I can see is the fact that Native / ProAIDE is not supplied any more and people are being forced (although you don't have to if you know how) to use VIP / Proiv Developer.
I will be posting my utilities that I used to convert Native 5.5 to Native 6.0 soon, so that others can use them if you wish.
Rob D.
#11
Posted 26 January 2007 - 01:34 PM
We had to convert all our 'C' routines that were linked into the Kernel to use the new shared library method, but this was not much of an effort.
How did you do this? We're facing the same task so any A&G would be appreciated.
Cheers
PS: I'm not part of the development team that will need to do this, but need some answers so I can suggest solutions to them.
#12
Posted 26 January 2007 - 02:26 PM
We had to convert all our 'C' routines that were linked into the Kernel to use the new shared library method, but this was not much of an effort.
How did you do this? We're facing the same task so any A&G would be appreciated.
Cheers
PS: I'm not part of the development team that will need to do this, but need some answers so I can suggest solutions to them.
Since I was the one that converted our C routines, I guess I should reply...
The new shared library method is probably one of the better things they have done in ProIV version 6.
It really is quite simple. It was probably more work for us as we had a custom makefile for compiling the C routines and linking them to the ProIV kernel. I had to totally rework this to generate extsub.so & cstubs.so instead of the "pro" kernel. But even this was just a matter of copying stuff from the new makefile provided.
However, if you haven't played with old kernlink script, it is trivial.
When ProIV is installed, this directory is created:
<installdir>/virtual_machine/lib/extsub with these files: -rwxrwxrwx 1 root system 2467 Dec 1 13:36 cstubs.c -rwxrwxrwx 1 root system 11718 Dec 1 13:36 extsub.c -rwxrwxrwx 1 root system 1261 Dec 1 13:36 extsub.mk
(I love the default file permissions ProIV set on install - will have to change these...)
Replace the cstubs.c & extsub.c from your previous ProIV version that contains all your C routines you call in ProIV.
Then, all you need to do (on most Unixes - some may need different compiler flags to create a shared library) is edit extsub.mk and uncomment these lines in the makefile:
#SHLIB_CFLAGS=-fPIC #SHLIB_LD=cc -shared #SHLIB_EXT=soYou can then create the shared library by running:
make -f extsub.mk
This creates libcstubs.so & libextsub.so
You then copy these to <installdir>/virtual_machine/lib and replace the ones that were already there.
And that's it.
Hope this helps,
Cleve
#13
Posted 12 August 2007 - 03:53 AM
I also converted my old Native editor (ROBFUN) to use the V6.0 bootstraps, so now we have a V6.0 editor also (Sometime soon, IDE will support V6 also)..
I remember using ROBFUN back when CSC's ISIS development was headquarted in Bethesda, MD, 10+ years back.
Back then, it was the best thing since cotton candy.
Glad to hear it's still around.
AK
#14
Posted 12 August 2007 - 07:53 AM
Yes its amazing how things spread, quite a few people have said they used ROBFUN, but I never distributed it out to anyone.
I'm just glad people used it
Of course, IDE has now replaced ROBFUN, but I still use it sometimes.
Rob.
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users