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: [U2] Basic developments reverse engineering tool ?
All This is something we're keen to add to the U2UG website. We're testing out a couple of different Wikis at the moment. We expect to have something in place very soon for the community to add technical tips, FAQs, learning materials, utilities, possibly vendor pages and similar materials. Watch this space for announcements! Regards Brian Other user groups that I belong(ed) to provide(d) a repository for user submitted utilities. Things like neatly formatted file ACL's, tape listings, database copy routines, etc Each submission would include the utility's documentation, source code, any ancillary files (db) and executable if applicable. I am sure that there is a wealth of end user utilities available for U2. This source code listing program would be a great start. Since our software vendor does not provide any technical documentation about their system, the sort of cross-reference source code tool features mentioned by Susan is something I would find very usefull. Currently, I just save any emails from this group that have useful proc's or commands. Searching the archives is usefull but an index of software utilities by category might be a better way to help fledging U2 programmers see how to accomplish certain tasks. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Basic developments reverse engineering tool ?
Tony/Susan Having written two such 'system auditors' I can tell you from experience that it's not that easy to do a good source analysis. The problem is that every system is different, adopts different standards, use different tools, are often very incomplete, and most include lots of bad links, obsolete code, multiple versions of the same program in different source files and the like. [on to the predictable ad..] Which is why mvScan was designed as a navigation and parsing tool. It scans through a system in a defined order running various 'plug-ins' at each stage. The provided plugins do source code (and object code) analysis, build impact maps of all calls, file opens/reads/writes from BASIC, PROC etc, SUBR() calls, dictionary translations, executed commands (from BASIC, Menus, paragraphs, PROCs), where things are cataloged, common block and include file usage - all that standard stuff. But it also allows you to write custom plugins to pick up site-specific functionality. For example, you might have a generic file opener function that it needs to pick up on. Or you may have custom headers to your programs, or use a precompiler that handles includes and definitions. If you use a 4GL like uvCase or SB+, you might need to include the tool definitions. So the parser has to be very flexible to individual needs. You also have to recognize that static analysis only goes so far. It can't parse relations that are derived at run time. The original auditor I wrote supported trigger insertion - automatically changing source code to replace reads/writes/opens/executes with functions that would capture and log information in real time as the system ran. mvScan doesn't - that approach is too dangerous unless done under controlled conditions. Instead, it uses an autodoc approach in which you are encouraged to 'fill in the gaps' yourselves with special documentary comments in the source code. So the whole becomes an iterative process that will lead to a better understood and documented system. Brian Susan Lynch wrote: Tony, there are a number of things that a source code analyzer can do that would be very helpful if you found yourself coming into a company as a consultant or as a new employee and they had no technical documentation: --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Basic developments reverse engineering tool ?
PLEASE put stuff like this on PickWiki. It's a wonderful place to put snippets, small programs, etc etc. The one thing to watch out for about a user group keeping a repository is that there's copyright issues involved. If you wrote the utility, you can put it on PickWiki, or in a repository, or whatever. What the User Group must NOT do (unfortunately) is to copy the code from the email into a repository :-( This would raise a massive can of worms :-( When did the US sign Berne? Things were a lot easier for USians (not us Europeans) before then. An alternative (should someone care to volunteer!) is to maintain an index on the u2ug website pointing at a repository that stores the emails. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 27 June 2007 22:50 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Basic developments reverse engineering tool ? Other user groups that I belong(ed) to provide(d) a repository for user submitted utilities. Things like neatly formatted file ACL's, tape listings, database copy routines, etc Each submission would include the utility's documentation, source code, any ancillary files (db) and executable if applicable. I am sure that there is a wealth of end user utilities available for U2. This source code listing program would be a great start. Since our software vendor does not provide any technical documentation about their system, the sort of cross-reference source code tool features mentioned by Susan is something I would find very usefull. Currently, I just save any emails from this group that have useful proc's or commands. Searching the archives is usefull but an index of software utilities by category might be a better way to help fledging U2 programmers see how to accomplish certain tasks. Garry L. Smith Dir Info Systems Charles McMurray Company V# 559-292-5782 F# 559-346-6169 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
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/
[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/
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/
[U2] Basic developments reverse engineering tool ?
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. Herve' Balestrieri --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Basic developments reverse engineering tool ?
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] To: u2-users@listserver.u2ug.org Sent: Wednesday, June 27, 2007 6:37 AM Subject: [U2] Basic developments reverse engineering tool ? 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. Herve' Balestrieri --- 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: [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/
RE: [U2] Basic developments reverse engineering tool ?
Something like PRC? Contact Susan through http://www.sjplus.com/ -Original Message- From: Herve Balestrieri [mailto:[EMAIL PROTECTED] 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/
RE: [U2] Basic developments reverse engineering tool ?
The best such tool I ever saw was SoftWhere by Joe Toledo. I don't know if he still sells it. It reads source code, dictionaries, procs, and maps dependencies. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Herve Balestrieri Sent: Wednesday, June 27, 2007 8: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/
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/
Re: [U2] Basic developments reverse engineering tool ?
Herve I have something that may do what you need (mvScan). I'll contact you off-list with some details. Brian 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/
[U2] Basic developments reverse engineering tool ?
Thanks, Jerry ... PRC can help with this, but does not do specifically what Herve is really seeking. ROI Syngineering had a great utility for this, I'm not sure if anyone is marketing it now that Bob has passed away. Does anyone know? And I remember Softwhere by Toledo Assoc., too, but I'm not sure they are marketing that anymore. Seems to me this comes up a lot -- maybe one of us should write one, hmm? Regards, Susan Joslyn SJ+ Systems Associates, Inc. PRC(r) Real software configuration management for U2/Multivalue. --- Date: Wed, 27 Jun 2007 10:40:07 -0500 From: Jerry Banker [EMAIL PROTECTED] Subject: RE: [U2] Basic developments reverse engineering tool ? Something like PRC? Contact Susan through http://www.sjplus.com/ - -Original Message- From: Herve Balestrieri [mailto:[EMAIL PROTECTED] 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/ -- End of U2 Users Digest V1 #1717 *** u2-users-digest 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: [U2] Basic developments reverse engineering tool ?
Herve Balestrieri wrote: 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. 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. Java and .NET use structured comments with XML for doing this and I've seen a few MV packages do the same with BASIC. I'll make up some sample XML below but this is how I might do it. * Documentation * AuthorJoe Coder/Author * Desc * ShortThis proggie processes orders/Short * Long * Longer desc here. * /Long * /Desc * Mods DateWritten=9-dec-1998 * Mod Request=123534 Date=14-feb-2001 * Fixed this to do that. * /Mod * /Mods * FileUsage * File Usage=RWORDERS/File * File Usage=RPRICING/File * /FileUsage * /Documentation ... * CodeDoc Label=CALC.PRICE * Get the current price using special tables. * /CodeDoc CALC.PRICE: * ... CodeDoc Call=SOMEPROG / CALL SOMEPROG(blah) Similar metadata can be created for I-Types or wherever BASIC code is used or referenced. Once these tags are embedded in BASIC you can have a program scan your program files and other source records and build XML documents. These can then be imported into templates or maybe reformatted into HTML with XSLT. You can also use the data to create Where Used type reports. Tony Gravagno Nebula RD TG@ always.remove.thisNebula-RnD.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Basic developments reverse engineering tool ?
Tony, there are a number of things that a source code analyzer can do that would be very helpful if you found yourself coming into a company as a consultant or as a new employee and they had no technical documentation: List programs that open each file - useful for verifying that adding an attribute won't blow up dimensioned arrays or confuse the program logic that deals with the last attribute in the current dimension size, depending on your version/flavor of MV - also useful when you are asked to add another code for a field (eg Active/Terminated status field, suddenly users want to add Pending or Sabbatical statuses - where do you need to add logic to handle those new status values?) List programs that write to each file (useful when trying to figure out how did that attribute get that inappropriate data in there?) List of programs that call a given program (including by a variable name) - useful when you change the list of variables passed to the program Of course, now that we also have paragraphs that can write data, and tools like SB and a variety of others that can store procedural information and write commands in places other than Basic and Proc, it gets a bit trickier to write that sort of automated source code analyzer - gone are the days when you could pass the source code analyzer a list of Basic Program files, a list of Proc files, and let it generate this sort of technical documentation. Susan Lynch F.W. Davison Company, Inc. - Original Message - From: Tony Gravagno [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Wednesday, June 27, 2007 2:33 PM Subject: RE: [U2] Basic developments reverse engineering tool ? Herve Balestrieri wrote: 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. 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. Java and .NET use structured comments with XML for doing this and I've seen a few MV packages do the same with BASIC. I'll make up some sample XML below but this is how I might do it. [Snipped to reduce size ] Tony Gravagno --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Basic developments reverse engineering tool ?
Susan Lynch wrote: Tony, there are a number of things that a source code analyzer can do that would be very helpful if you found yourself coming into a company as a consultant or as a new employee and they had no technical documentation: Without knowing more about what Herve wanted, I'm making this up as I go. It seems to me that anyone could do this, even making it open source, so I'll flesh it out just a little more. Regarding paragraphs, etc, one of the things I was alluding to was that separate items should be maintained which contain XML related to code which cannot itself contain the metadata. For example, Susan, it would be nice to have Where Used data in your HR Partner DesignBais front-end, so that you know which menus call to specific forms, which fields are used on which forms, which forms run specific selection processes, which programs use PROCESS.STACK to invoke other forms, etc. In DesignBais or with other utilities that allow GUI queries it would be helpful to know where various dict items are used. It may not be practical to put the XML in the dict item (extended dict items, paragraphs, etc) and these environments don't have a special/common place for metadata, so a custom file would need to be created that defines where dict items are used, how they're used, etc. As always, Garbage In, Garbage Out, and unless metadata is maintained the reports one derives from the data are going to be inaccurate. Manual procedures must be implemented which require update of the data, or version control software can prompt developers to ensure they have updated docs before checking in changes. T --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Basic developments reverse engineering tool ?
Other user groups that I belong(ed) to provide(d) a repository for user submitted utilities. Things like neatly formatted file ACL's, tape listings, database copy routines, etc Each submission would include the utility's documentation, source code, any ancillary files (db) and executable if applicable. I am sure that there is a wealth of end user utilities available for U2. This source code listing program would be a great start. Since our software vendor does not provide any technical documentation about their system, the sort of cross-reference source code tool features mentioned by Susan is something I would find very usefull. Currently, I just save any emails from this group that have useful proc's or commands. Searching the archives is usefull but an index of software utilities by category might be a better way to help fledging U2 programmers see how to accomplish certain tasks. Garry L. Smith Dir Info Systems Charles McMurray Company V# 559-292-5782 F# 559-346-6169 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Joslyn Sent: Wednesday, June 27, 2007 11:31 AM To: u2-users@listserver.u2ug.org Subject: [U2] Basic developments reverse engineering tool ? Thanks, Jerry ... PRC can help with this, but does not do specifically what Herve is really seeking. ROI Syngineering had a great utility for this, I'm not sure if anyone is marketing it now that Bob has passed away. Does anyone know? And I remember Softwhere by Toledo Assoc., too, but I'm not sure they are marketing that anymore. Seems to me this comes up a lot -- maybe one of us should write one, hmm? Regards, Susan Joslyn SJ+ Systems Associates, Inc. PRC(r) Real software configuration management for U2/Multivalue. --- Date: Wed, 27 Jun 2007 10:40:07 -0500 From: Jerry Banker [EMAIL PROTECTED] Subject: RE: [U2] Basic developments reverse engineering tool ? Something like PRC? Contact Susan through http://www.sjplus.com/ - -Original Message- From: Herve Balestrieri [mailto:[EMAIL PROTECTED] 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/ -- End of U2 Users Digest V1 #1717 *** u2-users-digest 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/
