20 replies to this topic

[Geoff Lim]

Hi,

am in the process of migrating from Native Version 40R518 to Native Version 50R109.

In V50 I have seen a new (to me) import/export menu P4X.

This produces a *.jbx file as opposed to a *.prx.

I haven't had much luck finding any documentation on P4X so was wondering if anyone had any experience using it.

Readability of the export file is of particular interest as the company I work for has recently adopted Rational ClearCase as its version control application of choice. However, all the nice comparison features work well and good on HTML etc, but aren't of much use when looking at *.prx files.

Basically I like to hear from anyone who's had experience (good or bad) using a version control application like ClearCase with ProIV - how you went about it/useability/etc.

Any and all help will be much appreciated.

Thanks and regards,
Geoff

[Rob Donovan]

Hi,

The P4X menu used to be there is 4.6 also.. I think.

It seems to be the same as the SuperLayer import/export with a few extra things.

The .jbx that you talk about is the export file type that is used for exporting 'Task' definitions that are used by the 'Bus & Tasks' part of ProIV. This has been around for some time.

HTHs,

Rob D.

[Nic Brough]

I'm in much the same position as you are - all development here is done under ClearCase, except the Pro-IV stuff on the Alpha. And we're in a right mess because Pro-IV doesn't have any version control.

However, I'm actually 95% of the way through a project that partially integrates ClearCase with ProIV. It can't tell the difference between versions of prx's (we tried all sorts of horrible things), but it does do all the check-in, check-out, version history and so on.

End result - we have a list of every function, file and global logic sat in the clearcase explorer, user does a check-out, it imports that version into the dev system, and when they check-in, it grabs a copy back.

Next job is automatic label deployment...

[Chris Pepper]

Rather than using export format to dump ProIV code into a code management system we've written our own dump format that turns ProIV into a standard ASCII sequential file.

This allows a more efficient storage of the source as most CMS store only differences on ASCII files.

One tip - don't do as I did and use different file formats for Screens, Reports & Updates as someone is sure to rewrite a Function & change the type!

[Fred Marker]

Chris, You said '... we've written our own dump format that turns ProIV into a standard ASCII sequential file.'

Can you share this utility/function on this forum?

[Richard Bassett]

Hello all,

A few years ago, I did a considerable amount of research and development work on representing Pro-IV source as text for configuration management purposes.

I created some components which I call 'text adapters' to extract and replace Pro-IV source code in a human-readable (and hence CMS-friendly) text-file format.

I spoke to several organizations using Pro-IV but in the end it seemed unlikely they would be prepared to pay enough for the product to justify developing it fully. It was therefore put 'on the back burner' as they say.

Basically, because the text adapters are only a part of the overall configuration-management puzzle, it was difficult to find a pricing strategy likely to recoup the development costs. At the time, it seemed a user-base larger than I though was likely would be needed to drive the price point down.

Then again, perhaps I was speaking to the wrong people

As it happens, I have done some more work on the adapters this year as part of another project and I could probably provide a (restricted) demo in one or two months if people were sufficiently interested.

If I was persuaded enough people would purchase this as a commercial product at a viable price then I would certainly consider pursuing it.

Regards, Richard

[Chris Pepper]

Well, any code belongs to my employer so I would have to get permission. Anyway it's pretty specific to the way we work (e.g. I don't store any GUI related fields, it's not v5). I do lots of stuff like extracting & versioning all the dependent Global Logics and File Definitions so we can rebuild all source for a given client run-time version of a Function. We are Global Logic mad so you can have a complex series of Global Logics calling other Global Logics etc!). I strip all the logic line numbers etc so that the storage is more efficient.

If you have the bootstraps then a basic dump to a sequential file based on PROXFR1 should be pretty easy. I'd be happy to provide advice, but talk to Richard - he's working at a more creative level on this.

[Fred Marker]

Richard,

What is your best estimate on the total cost ($) of finishing your 'text adapters' - even if just one customer is interested?

Fred

[Dan Shannon]

I've written one in PRO-IV, which takes a copy of the bootstrap files and inserts a numeric key field as the version. You can then store the source code in PRO-ISAM files and check it in and out as you need to. No need for complex programs in other languages or text files to store in Source Control programs...

Unfortunately I'm not allowed to post the source as it would probably violate PRO-IV's NDA's

Might be able to post a runtime version - at the moment though it's in v4.0.

However I have seen several companies out there which have signed PRO-IV NDA's which contain words to the effect of 'you must NOT NOT redistribute PRO-IV bootstraps'

Dan Shannon

[Michael Lawrence]

A few companies back I spent about 10 days whipping up a version control system using the bootstraps, it entailed inserting a version number into each bootstrap definition and creating a control record. Once this was done we stopped people making backup copies of functions, they simply archived them off as the next version. We also placed these files in a shared location so that DEV, QA and Production environments could see them. So the Import/Export routines were no longer used and it was a lot faster. as mentioned it only took about 10 days to design, develop and test. We had about 25 developers working within ProIV and it sufficed quite well. PARCHIVE and PRESTORE were the only user functions required.

Enhancements to the system were the usage of a P_LINT function to compare functions and show any suspect code and a comment function that removed any unused logics and placed common comments in all used logics.

[Richard Bassett]

Fred,

If there were really only one customer it would probably make sense to cut some corners on platforms and areas of Pro-IV which were not used. However, I think that is very unlikely to be a realistic scenario.

To do the job properly, I would guess at a ballpark cost of $250K. Please note this is strictly a well-informed guess and no detailed estimating has been done.

Please note that this definitely would not allow for mainframe support - for which I would need access to suitable facilities and probably some additional technical assistance.

I am also assuming V5 will not introduce any fundamentally new problems - I haven't got into V5 in sufficient detail yet.


Richard.

[Rob Donovan]

Hi,

The 5.0 bootstraps are not much different than 4.6. So it shouldnt cause you too much of a problem.

5.5 has a few extra files, due to the support of ActiveX, but I dont think it will be that complicated. But I havent looked into it yet.

The problem you will have, is VIP. Basically the VIP files seem to be a copy of the standard files, obiously with extra fields and they are keyed differently. There are also LOTS of extra Xref files.. totaling upto above 100.

That is gonna cause lots of problems for people who have there own utils... If you use VIP that is. If you dont use it then you will be fine, with a few mods.

Rob D.

[Richard Bassett]

Rob,

Is there any procedure for loading a non-VIPped function (eg. one imported from V4.x) into a VIP environment?

In other words, is there something that can be run to create all the necessary cross-references and so on for otherwise correct source code?

Seems to me such a facility would be important anyway.

[Rob Donovan]

Hi,

Ok, after a quick look, this should import a function into VIP... But I haven't checked it out thoroughly.. so be careful

1) Remove the Prod flag from the function @VIPW510 in $SM
2) Go into @FUN with the function @VIPW510 and window on the Parameters field.
3) Hit add mode and enter a new param with the following values I,$FUN,A,8
4) DO NOT try to gen this function, as its run time only!!
5) Then in your function you can GLOBAL_LSCALL(@VIPWFUN,0001) and set the parameter to the function you wish to import into the VIP bootstraps.

I think this should be ok... but have a play around with it, cause I've just worked it out since there are no docs/info about it.

And its probably best if you do it in a test env first, cause you never know what could happen...

Rob D.