Hi
does anyone know if version 5 of PROIV and/or VIP allows you to save objects (eg functions) as text or ASCII, or any way of doing so, so that standard library or version control systems can do diff's etc between versions to identify differences ?
thanks in advance
Doug
Click the link below to see the new game I'm developing!
3 replies to this topic
#2
Tony White
-
- Members
-
- 14 posts
Member
- Gender:Male
- Location:Birmingham, United Kingdom
Posted 03 September 2001 - 02:02 PM
'Function Divergence' between Sertec's various companies is quite an issue with us, so we spent quite some time trying to find a way of quickly comparing two functions.
Like you we could find no obvious answer, and in the end we had to write some functions that compare the bootstraps themselves.
Unfortunately, comparing all of the detail would have been a huge task, so as a rough guide to whether funtions are different, our 'Divergence Checker' simply counts the number of LS, the number of Logics and the number of fields in each function. The logic lines are also compared on a one for one.
Over the years our developers have found this to be a pretty useful 'Rough Guide'.
Like you we could find no obvious answer, and in the end we had to write some functions that compare the bootstraps themselves.
Unfortunately, comparing all of the detail would have been a huge task, so as a rough guide to whether funtions are different, our 'Divergence Checker' simply counts the number of LS, the number of Logics and the number of fields in each function. The logic lines are also compared on a one for one.
Over the years our developers have found this to be a pretty useful 'Rough Guide'.
#3
David Tuke
-
- Members
-
- 20 posts
Member
Posted 04 September 2001 - 12:03 AM
Greetings folks,
Version Control is vital in a production environment - but there is no provision for this in the standard proiv offerings. Ithink the only option is to roll your own. If proiv prohibit access to the bootstraps, this will further limit the acceptance/usability of their already obscure tool.
Given access to a current version of the bootstraps, I developed a relativley simple method to dump a specified function to a text file as follows:
Read a function as a series of proiv bootstrap files, given the key to the function is the leading edge key to all the
other bootstrap files. Dump each populated data field as a flat sequential record to a nominated file for each of these bootstrap records. This flat file contains every parameter in the bootstraps - formatted as a flat ascii file - one line per populated field in each bootstrap record. Then my routine would do a unix diff, and output the compare with each source code listing side by side, with insertions changes and deletions shown highlighted. This worked very well - but as you can imagine generates substantail output. sdiff does allow you to suppress identical lines, which reduces it somewhat. diff/sdiff has no problems with large ( 2-5k) lines of source code, but the human reader may. It does track and highlight all changes to production environments however, to the satisfaction of auditors etc. It worked very well for small changes to existing production functions, picking up even a function gen only.
In such a standard format, the output could be inserted into a source code control utility (I used sccs as it was available on my machine). The format I used was as follows:
Bootstrap File; Full Key; Field Name; Data
One record per populated data element, one text file per function.
If data was a numeric or date, obviously some suitable PIC was applied
Subsequently, I investigated the possibility of converting a proiv function to a flat 3GL style program, reducing a function to a single 3GL style source code file. I was able to do this for updates, and could generate a pseudocode description of the functions operation, correctly nesting updats and calling the various logics at the appropriate time in the cycle. Methods were inserted to serve as reads on files and other supporting methods as required. This could be extended to screens and reports with more effort.
One significant problem with proiv when it comes to porting the code to another environment is the global scope of the file and scratch variables. This seems to be somewhat difficult to solve, as many other languages limit the scope of variables.
It can be done but would require some considerable effort.
I was looking at this as a way of generating specifications for a java programmer to use in replicating the existing functionality in a way that makes sense to a non proiv programmer (eg C++ or JAVA) I am interested in how such a tool could be extended to possibly port an entire function into a java object, replacing any proprietary black boxes with something else which will transparently (to developers) perform the same functionality.
If anyone is interested in further info re above or discussion re porting proiv to java, contact me at djtuke@attglobal.net
ps I think all those charged with caring for production applications in proiv should be looking at their options for a port right now. The vendor seems keen to increase the level of tie in, viz the approaching rewrite/rehash of the bootstraps which will obsolete any exsiting toolsets. The world is going the way of open source, collaborative effort and widely accepted vendor neutral standards..As soon as someone figures out the economics of this such that we have a win/win situation where everyone is paid for their time and effort...
David Tuke
JavaBarista
Version Control is vital in a production environment - but there is no provision for this in the standard proiv offerings. Ithink the only option is to roll your own. If proiv prohibit access to the bootstraps, this will further limit the acceptance/usability of their already obscure tool.
Given access to a current version of the bootstraps, I developed a relativley simple method to dump a specified function to a text file as follows:
Read a function as a series of proiv bootstrap files, given the key to the function is the leading edge key to all the
other bootstrap files. Dump each populated data field as a flat sequential record to a nominated file for each of these bootstrap records. This flat file contains every parameter in the bootstraps - formatted as a flat ascii file - one line per populated field in each bootstrap record. Then my routine would do a unix diff, and output the compare with each source code listing side by side, with insertions changes and deletions shown highlighted. This worked very well - but as you can imagine generates substantail output. sdiff does allow you to suppress identical lines, which reduces it somewhat. diff/sdiff has no problems with large ( 2-5k) lines of source code, but the human reader may. It does track and highlight all changes to production environments however, to the satisfaction of auditors etc. It worked very well for small changes to existing production functions, picking up even a function gen only.
In such a standard format, the output could be inserted into a source code control utility (I used sccs as it was available on my machine). The format I used was as follows:
Bootstrap File; Full Key; Field Name; Data
One record per populated data element, one text file per function.
If data was a numeric or date, obviously some suitable PIC was applied
Subsequently, I investigated the possibility of converting a proiv function to a flat 3GL style program, reducing a function to a single 3GL style source code file. I was able to do this for updates, and could generate a pseudocode description of the functions operation, correctly nesting updats and calling the various logics at the appropriate time in the cycle. Methods were inserted to serve as reads on files and other supporting methods as required. This could be extended to screens and reports with more effort.
One significant problem with proiv when it comes to porting the code to another environment is the global scope of the file and scratch variables. This seems to be somewhat difficult to solve, as many other languages limit the scope of variables.
It can be done but would require some considerable effort.
I was looking at this as a way of generating specifications for a java programmer to use in replicating the existing functionality in a way that makes sense to a non proiv programmer (eg C++ or JAVA) I am interested in how such a tool could be extended to possibly port an entire function into a java object, replacing any proprietary black boxes with something else which will transparently (to developers) perform the same functionality.
If anyone is interested in further info re above or discussion re porting proiv to java, contact me at djtuke@attglobal.net
ps I think all those charged with caring for production applications in proiv should be looking at their options for a port right now. The vendor seems keen to increase the level of tie in, viz the approaching rewrite/rehash of the bootstraps which will obsolete any exsiting toolsets. The world is going the way of open source, collaborative effort and widely accepted vendor neutral standards..As soon as someone figures out the economics of this such that we have a win/win situation where everyone is paid for their time and effort...
David Tuke
JavaBarista
#4
Chris Pepper
-
- Members
-
- 369 posts
ProIV Guru
- Gender:Male
- Location:United Kingdom
Posted 04 September 2001 - 05:54 AM
I've had to create routines to dump PRO-IV to text format to store in a Code Management system. It's slightly easier for me as we use our own GUI so don't need to store the GUI related fields.
In storing the functions I strip the sequence numbers (which are added back when the function is reloaded) - this means that that the function is stored more efficiently if the product uses delta-ing. Running a compare produces less output - i.e. if a line of logic is inserted then only that line is different.
Some work has been done on dumping to pseudo-code as this would be better as it makes more sense outside the PRO-IV editing environment. Unfortunately we didn't have the budget to do all the work at the time.
I'm about to revisit the project as we are about to upgrade our Code Management System and am interested in discussing the subject of PRO-IV Code Management (including ascii formats) with anyone interested.
In storing the functions I strip the sequence numbers (which are added back when the function is reloaded) - this means that that the function is stored more efficiently if the product uses delta-ing. Running a compare produces less output - i.e. if a line of logic is inserted then only that line is different.
Some work has been done on dumping to pseudo-code as this would be better as it makes more sense outside the PRO-IV editing environment. Unfortunately we didn't have the budget to do all the work at the time.
I'm about to revisit the project as we are about to upgrade our Code Management System and am interested in discussing the subject of PRO-IV Code Management (including ascii formats) with anyone interested.
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
Click the link below to see the new game I'm developing!
