Re: [AD] [U2] Basic developments reverse engineering tool ?
That's very difficult to trap. Mark It's a valid point and a common scenario. I've taken two approaches in the past: 1. Dynamic analysis This replaces certain constructs in the source code automatically with calls to subroutines or external functions that update the maps in real time. So for example every OPEN can be replaced with subroutine that writes the name of the program and the file opened to the audit files. However this is only under very controlled conditions, and never guaranteed to be complete - a particular file might only be opened as part of a year-end procedure for example and so the 'correctness' of dynamic analysis depends on the code coverage. 2. Manual Labour To accept that static analysis is always incomplete, but provide a way to identify where the incompleteness occurs (e.g. to log wherever there is an OPEN with a file name that cannot be determined) and provide a way for that link to be documented and completed manually so that eventually the map becomes as complete as possible. It's the down side of having such a flexible platform, that it can make any form of automated auditing and analysis far more difficult. Brian How does it work with parameter driven code. One of my clients has procs like this: HRUN BP SOP1500 STON HORDER HCUSTOMER HPRODUCT HVENDOR P whereby the program (BP SOP1500) has the corresponding INPUT statements for the file names and opens them as F1, F2, F3 which is a real bear when reading the code. Plus all of the bottom line field prompts are also tableized. Very klugy and not friendly at all. I tend to copy the program in question to another place and do a global replace of the R/F1/ORDER just to see the flow. Thanks Mark Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [AD] [U2] Basic developments reverse engineering tool ?
One of my clients has procs like this: HRUN BP SOP1500 STON HORDER HCUSTOMER HPRODUCT HVENDOR P whereby the program (BP SOP1500) has the corresponding INPUT statements for the file names and opens them as F1, F2, F3 which is a real bear when reading the code. Wow - that's just plan mean! There may have been a thought that it was a way to avoid hard-coding file names in case they ever changed (though that would be a weak argument), but then they're hard-coded in the PROC, so I can't see any benefit at all, other than obfuscation. The person that created it must have had a future grudge against whoever came along to maintain the code. Take my job from me, did you? I'll teach you a lesson. :-) Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [AD] [U2] Basic developments reverse engineering tool ?
When in doubt, obfuscate. === Norman Morgan [EMAIL PROTECTED] http://www.brake.com === Judge: An unemployed lawyer who wears a black dress. === -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Snyder Sent: Friday, June 29, 2007 8:21 AM To: u2-users@listserver.u2ug.org Subject: Re: [AD] [U2] Basic developments reverse engineering tool ? One of my clients has procs like this: HRUN BP SOP1500 STON HORDER HCUSTOMER HPRODUCT HVENDOR P whereby the program (BP SOP1500) has the corresponding INPUT statements for the file names and opens them as F1, F2, F3 which is a real bear when reading the code. Wow - that's just plan mean! There may have been a thought that it was a way to avoid hard-coding file names in case they ever changed (though that would be a weak argument), but then they're hard-coded in the PROC, so I can't see any benefit at all, other than obfuscation. The person that created it must have had a future grudge against whoever came along to maintain the code. Take my job from me, did you? I'll teach you a lesson. :-) Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [AD] [U2] Basic developments reverse engineering tool ?
Joking aside, that looks almost like something written by someone who was accustomed to writing mainframe COBOL where actual file assignments were made outside the program code in JCL. That doesn't excuse the internal naming style, but the technique harks back to my misspent youth as a COBOL programmer. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Snyder Sent: Friday, June 29, 2007 8:21 AM To: u2-users@listserver.u2ug.org Subject: Re: [AD] [U2] Basic developments reverse engineering tool ? One of my clients has procs like this: HRUN BP SOP1500 STON HORDER HCUSTOMER HPRODUCT HVENDOR P whereby the program (BP SOP1500) has the corresponding INPUT statements for the file names and opens them as F1, F2, F3 which is a real bear when reading the code. Wow - that's just plan mean! There may have been a thought that it was a way to avoid hard-coding file names in case they ever changed (though that would be a weak argument), but then they're hard-coded in the PROC, so I can't see any benefit at all, other than obfuscation. The person that created it must have had a future grudge against whoever came along to maintain the code. Take my job from me, did you? I'll teach you a lesson. :-) Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [AD] [U2] Basic developments reverse engineering tool ?
If I recall correctly, SoftWhere handled that sort of thing. I do remember seeing it pick up subroutine's uses of files where the file variable was passed as an argument from the calling program. -Original Message- How does it work with parameter driven code. One of my clients has procs like this: HRUN BP SOP1500 STON HORDER HCUSTOMER HPRODUCT HVENDOR P whereby the program (BP SOP1500) has the corresponding INPUT statements for the file names and opens them as F1, F2, F3 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [AD] [U2] Basic developments reverse engineering tool ?
Just to play devil's advocate, there ARE good reasons for doing the code that way: 1. The same program can be used for processing live and historical data if they're in different files. Just create two procs and pass live files in one and historical files in the other. 2. The same program can be used for other file sets - assuming it's a generic routine. 3. Filenames can be changed without having to recompile the program. Although it's a little safer in U2, recompiling code out from under a user isn't a good thing in most flavors of Pick - unless you enjoy sending them to a RIF error. Again, I'm not saying there aren't better ways to do it, but there are legit reasons for this type of code - and who knows how long ago the code was written too. My 1.5 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Norman Morgan Sent: Friday, June 29, 2007 9:02 AM To: u2-users@listserver.u2ug.org Subject: RE: [AD] [U2] Basic developments reverse engineering tool ? Joking aside, that looks almost like something written by someone who was accustomed to writing mainframe COBOL where actual file assignments were made outside the program code in JCL. That doesn't excuse the internal naming style, but the technique harks back to my misspent youth as a COBOL programmer. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Snyder Sent: Friday, June 29, 2007 8:21 AM To: u2-users@listserver.u2ug.org Subject: Re: [AD] [U2] Basic developments reverse engineering tool ? One of my clients has procs like this: HRUN BP SOP1500 STON HORDER HCUSTOMER HPRODUCT HVENDOR P whereby the program (BP SOP1500) has the corresponding INPUT statements for the file names and opens them as F1, F2, F3 which is a real bear when reading the code. Wow - that's just plan mean! There may have been a thought that it was a way to avoid hard-coding file names in case they ever changed (though that would be a weak argument), but then they're hard-coded in the PROC, so I can't see any benefit at all, other than obfuscation. The person that created it must have had a future grudge against whoever came along to maintain the code. Take my job from me, did you? I'll teach you a lesson. :-) Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material not intended for Public use. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is strictly prohibited. If you received this communication in error, please notify the sender and delete the material from any and all computers or devices. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [AD] [U2] Basic developments reverse engineering tool ?
I have been trying to track Joe Toledo and/or someone at his company Toledo Inc. (who used to distribute SoftWhere) but all e-mails have come back undeliverable. The company's web site is also down. That's just too bad. Laure Hansen, City of Redwood City Information Technology 1017 Middlefield Road Redwood City, CA 94063 Tel 650-780-7087 Fax 650-556-9204 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stevenson, Charles Sent: Friday, June 29, 2007 7:28 AM To: u2-users@listserver.u2ug.org Subject: RE: [AD] [U2] Basic developments reverse engineering tool ? If I recall correctly, SoftWhere handled that sort of thing. I do remember seeing it pick up subroutine's uses of files where the file variable was passed as an argument from the calling program. -Original Message- How does it work with parameter driven code. One of my clients has procs like this: HRUN BP SOP1500 STON HORDER HCUSTOMER HPRODUCT HVENDOR P whereby the program (BP SOP1500) has the corresponding INPUT statements for the file names and opens them as F1, F2, F3 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [AD] [U2] Basic developments reverse engineering tool ?
The designers of this mess were (are) called Gull from Long Island, NY. It appears to be one of the many early attempts at a 4GL that are now Roadkill. I have another client running similar code for a Credit Collections application called BestCollect. I could write a book on the false starts of programming in MV. My 1 cent Mark Johnson P.S. In response to the 'future grudges' that could occur, and the history of MV programmers, VARs etc, I would definitely insist that If I were to purchase an application from a VAR and the source code were not on my system, that the source code be stored in escrow by a 3rd party. That way, when the software VAR eventually goes out of business, at least the source sode is available. I don't mind following awkward source code. But I do have to have it. - Original Message - From: Timothy Snyder [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, June 29, 2007 9:20 AM Subject: Re: [AD] [U2] Basic developments reverse engineering tool ? One of my clients has procs like this: HRUN BP SOP1500 STON HORDER HCUSTOMER HPRODUCT HVENDOR P whereby the program (BP SOP1500) has the corresponding INPUT statements for the file names and opens them as F1, F2, F3 which is a real bear when reading the code. Wow - that's just plan mean! There may have been a thought that it was a way to avoid hard-coding file names in case they ever changed (though that would be a weak argument), but then they're hard-coded in the PROC, so I can't see any benefit at all, other than obfuscation. The person that created it must have had a future grudge against whoever came along to maintain the code. Take my job from me, did you? I'll teach you a lesson. :-) Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [AD] [U2] Basic developments reverse engineering tool ?
While your examples are not false, they're hardly true either. In my many years of MV programming, I've never seen such alternate files or other methods. The closest I've seen is code within the program to decide which files to use. I think you are implying contemporary intelligence against an old technique. This entire application is written this way so the chances of having EVERYTHING have alternate files is pretty slim. Thanks Mark Johnson - Original Message - From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, June 29, 2007 11:08 AM Subject: RE: [AD] [U2] Basic developments reverse engineering tool ? Just to play devil's advocate, there ARE good reasons for doing the code that way: 1. The same program can be used for processing live and historical data if they're in different files. Just create two procs and pass live files in one and historical files in the other. 2. The same program can be used for other file sets - assuming it's a generic routine. 3. Filenames can be changed without having to recompile the program. Although it's a little safer in U2, recompiling code out from under a user isn't a good thing in most flavors of Pick - unless you enjoy sending them to a RIF error. Again, I'm not saying there aren't better ways to do it, but there are legit reasons for this type of code - and who knows how long ago the code was written too. My 1.5 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Norman Morgan Sent: Friday, June 29, 2007 9:02 AM To: u2-users@listserver.u2ug.org Subject: RE: [AD] [U2] Basic developments reverse engineering tool ? Joking aside, that looks almost like something written by someone who was accustomed to writing mainframe COBOL where actual file assignments were made outside the program code in JCL. That doesn't excuse the internal naming style, but the technique harks back to my misspent youth as a COBOL programmer. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Snyder Sent: Friday, June 29, 2007 8:21 AM To: u2-users@listserver.u2ug.org Subject: Re: [AD] [U2] Basic developments reverse engineering tool ? One of my clients has procs like this: HRUN BP SOP1500 STON HORDER HCUSTOMER HPRODUCT HVENDOR P whereby the program (BP SOP1500) has the corresponding INPUT statements for the file names and opens them as F1, F2, F3 which is a real bear when reading the code. Wow - that's just plan mean! There may have been a thought that it was a way to avoid hard-coding file names in case they ever changed (though that would be a weak argument), but then they're hard-coded in the PROC, so I can't see any benefit at all, other than obfuscation. The person that created it must have had a future grudge against whoever came along to maintain the code. Take my job from me, did you? I'll teach you a lesson. :-) Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material not intended for Public use. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is strictly prohibited. If you received this communication in error, please notify the sender and delete the material from any and all computers or devices. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [AD] [U2] Basic developments reverse engineering tool ?
Will, Having spent a lot of my career consulting, I have seen a system where the history was archived in files named with the year eg INVOICES was the current fiscal year, INVOICES2006 was last year's orders, INVOICES2005 were 2 fiscal years back, etc. The same held true for the sales history files. There were programs which were passed the file names, which were opened to INV.FILE, SALES.HIST, etc and the same logic ran on the history files as on the current fiscal year's files. This was many years back, when disk space was more expensive, and history files were archived to removeable media (bulky tapes, usually) and brought back when needed for history reports. The proc for the current year would pass hard-coded file names, while the proc for prior years would prompt for the year and append it to the file names and pass those. But it was not the entire system - probably the one you inherited was written by someone who learned on such a system and thought it was the only way to write code (or a cool way to write code) and who never gave a moment's thought to maintainability or documentation. Susan Lynch F. W. Davison Company, Inc. - Original Message - From: MAJ Programming [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, June 29, 2007 7:38 PM Subject: Re: [AD] [U2] Basic developments reverse engineering tool ? While your examples are not false, they're hardly true either. In my many years of MV programming, I've never seen such alternate files or other methods. The closest I've seen is code within the program to decide which files to use. I think you are implying contemporary intelligence against an old technique. This entire application is written this way so the chances of having EVERYTHING have alternate files is pretty slim. Thanks Mark Johnson - Original Message - From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, June 29, 2007 11:08 AM Subject: RE: [AD] [U2] Basic developments reverse engineering tool ? Just to play devil's advocate, there ARE good reasons for doing the code that way: 1. The same program can be used for processing live and historical data if they're in different files. Just create two procs and pass live files in one and historical files in the other. 2. The same program can be used for other file sets - assuming it's a generic routine. 3. Filenames can be changed without having to recompile the program. Although it's a little safer in U2, recompiling code out from under a user isn't a good thing in most flavors of Pick - unless you enjoy sending them to a RIF error. Again, I'm not saying there aren't better ways to do it, but there are legit reasons for this type of code - and who knows how long ago the code was written too. My 1.5 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Norman Morgan Sent: Friday, June 29, 2007 9:02 AM To: u2-users@listserver.u2ug.org Subject: RE: [AD] [U2] Basic developments reverse engineering tool ? Joking aside, that looks almost like something written by someone who was accustomed to writing mainframe COBOL where actual file assignments were made outside the program code in JCL. That doesn't excuse the internal naming style, but the technique harks back to my misspent youth as a COBOL programmer. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Snyder Sent: Friday, June 29, 2007 8:21 AM To: u2-users@listserver.u2ug.org Subject: Re: [AD] [U2] Basic developments reverse engineering tool ? One of my clients has procs like this: HRUN BP SOP1500 STON HORDER HCUSTOMER HPRODUCT HVENDOR P whereby the program (BP SOP1500) has the corresponding INPUT statements for the file names and opens them as F1, F2, F3 which is a real bear when reading the code. Wow - that's just plan mean! There may have been a thought that it was a way to avoid hard-coding file names in case they ever changed (though that would be a weak argument), but then they're hard-coded in the PROC, so I can't see any benefit at all, other than obfuscation. The person that created it must have had a future grudge against whoever came along to maintain the code. Take my job from me, did you? I'll teach you a lesson. :-) Tim Snyder Consulting I/T Specialist U2 Lab Services Information Management, IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ The information transmitted is intended only for the person or entity to which
Re: [AD] [U2] Basic developments reverse engineering tool ?
How does it work with parameter driven code. One of my clients has procs like this: HRUN BP SOP1500 STON HORDER HCUSTOMER HPRODUCT HVENDOR P whereby the program (BP SOP1500) has the corresponding INPUT statements for the file names and opens them as F1, F2, F3 which is a real bear when reading the code. Plus all of the bottom line field prompts are also tableized. Very klugy and not friendly at all. I tend to copy the program in question to another place and do a global replace of the R/F1/ORDER just to see the flow. Thanks Mark Johnson - Original Message - From: Laura Hirsh [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, June 28, 2007 2:26 PM Subject: [AD] [U2] Basic developments reverse engineering tool ? The type of Technical Documentation that Susan mentions is a part of DocuSys! Not only does DocuSys comb through basic code, and also the gamut of SB+ bits, but it sends it to MS Word - nicely formatted, with a table of contents, pagination, Styles, etc. Options include both User Documentation (for SB+ Apps) and Technical Documentation (SB+/Non-SB+). This isn't really an ad, but DocuSys a really useful product/tool. If anyone would like more information, let me know! Laura Hirsh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Joslyn Sent: Thursday, June 28, 2007 7:59 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Basic developments reverse engineering tool ? I was thinking of the sort of documentation that you could get from writing a utility to comb through code. I've written some (not for prime time) versions of this sort of thing. In particular whenever converting from one platform to another. The types of technical documentation that one can glean programmatically from an application are: What files are opened by what programs Where are records written What fields/amcs are read and written by what programs What subroutines are called by what programs What includes/inserts are in use, where In the case of SB+ (or any system where fields are referenced by name) - schemas can be built identifying field name across files and when and where these are updated What else? One thing that I have built into my application that I use rarely but when I need it I find it extremely handy - every one of my programs calls a subroutine at the beginning that just time-date stamps that it has been run. I think I keep the last five or ten runs in a Multivalue list. This helps when I want to clean up and find stuff that never gets run - or when I want to see the last time a customer ran something. I tiny little subroutine that you can stuff programmatically into a top line of all programs and let it go for awhile. Then come back and find interesting things. Susan Date: Wed, 27 Jun 2007 11:33:17 -0700 From: Tony Gravagno [EMAIL PROTECTED] I don't believe there is a way to have a program read code and figure out what it does from a logical perspective. When you say technical documentation, I'm not sure what sort of info you wish to extract from your code. If you mean file usage, common usage, etc, the only way to get a program to process such information is to make sure you have your code completely consistent - or you need to use meta data as described below. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [AD] [U2] Basic developments reverse engineering tool ?
We have a series of programs that will dissect a U2 application and create a series of documentation databases. We have some canned reports or you can simply use LIST to generate your own reports. The application is available for installation on one of your systems so you can maintain this level of documentation. We are working on a second module that will allow for the entry of textual descriptions for each component and then generate various types of documentation. IE. html, pdf, csv, rtf, etc Contact me off line if this sounds interesting. Tom Dodds [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Herve Balestrieri Sent: Wednesday, June 27, 2007 10:23 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Basic developments reverse engineering tool ? To clarify the inquiry : I am seeking for a tool reading Basic source code modules and producing a technical documentation of an application automatically. This is not the purpose of an object code decompiler. Thanks Herve' Balestrieri There was UN-Basic that took compiled code and reverted it back to source code. My 1 cent Mark Johnson - Original Message - From: Herve Balestrieri [EMAIL PROTECTED] Does it exists a (marketed?) tool for MV databases (i.e UniVerse) that would allow to make the reverse engineering of an application, based on automated Basic source code analysis ? Thanks for any information. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
