 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion Groups Database Servers DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybaseDesktop Databases FileMakerFoxProMS AccessParadoxGeneral General DB TopicsDatabase TheoryRelated Topics Java Development.NET DevelopmentVB DevelopmentMore Topics ... |
Database Forum / Ingres Topics / November 2007ABF Debugger / NAIUA
Hi group, I am looking for an ABF debugger, and can see that NAIUA has this listed under their membership area. Does anybody know if the group is still active (unable to open the application form as it is word, and no response from the mail link)? Alternatively, does anyone know of an ABF debuuger? Is the NAIUA group one any good? Thanks Andrew Wilson >Hi group, > [quoted text clipped - 6 lines] >Alternatively, does anyone know of an ABF debuuger? Is the NAIUA group one >any good? The NAIUA is moribund at the moment, and has been for quite some while. While there is plenty of Ingres usage in North America, there doesn't seem to be any great amount of user group interest, at least not at that level. There has been sporadic regional and local user-group activity, although I don't keep track. As for the ABF "debugger" -- I downloaded the linked-to tar file from the naiua site, and it's not a debugger as you might think of one. It appears to be a semi automated way of inserting message statements into the source; I didn't dig into it at all. Unfortunately, in all the years I used ABF/4GL, I never heard of any real debugger for it. At this stage in ABF's life, it would be a serious labor of love to produce such a thing. (Meaning that you are unlikely to make any money or get any great amount of thanks for doing it.) Since ABF can be run interpreted, a debugger would certainly seem to be possible, but nobody I know has ever looked at doing it. Karl On Nov 5, 3:36 pm, Karl & Betty Schendel <schen...@kbcomputer.com> wrote: > >Hi group, > [quoted text clipped - 30 lines] > > Karl i assume the OP is referring to osq-debug. I used it once upon a many moons ago. basically, it will print each block of code as it executes, and print the values of selected variables at that time. It works by generating a temporary file with each block of code duplicated inside a message box. It was also, IIRC, somewhat fragile, in that is was easy to get it generate code that would compile and die.... > Unfortunately, in all the years I used ABF/4GL, I never heard > of any real debugger for it. At this stage in ABF's life, it [quoted text clipped - 4 lines] > seem to be possible, but nobody I know has ever looked at > doing it. Thanks Karl. Hadn't held out much hope, but have a strange situation that I would love to single step through. Andrew On Nov 5, 3:47 pm, "Andrew Wilson" <andrew@_nospam_blueoffice.com> wrote: > > Unfortunately, in all the years I used ABF/4GL, I never heard > > of any real debugger for it. At this stage in ABF's life, it [quoted text clipped - 11 lines] > > Andrew Andrew, that's what osq-debug does.. it's not a gee-wiz debugger that you can set break-points and such, but it will allow you to view the code as it executes and the values in user-specified variables. it might not be the greatest thing, but it beats putting your own message statements in everywhere. one real nice thing about it, is you can "turn off" the debugger when you're done and not worry about extraneous code being scattered everywhere > Andrew, that's what osq-debug does.. it's not a gee-wiz debugger > that you can set break-points and such, but it will allow you to view > the code as it executes and the values in user-specified variables. Does anyone have a NAIUA username and password I can borrow, or alternatively a copy of the tar file? Andrew > > Andrew, that's what osq-debug does.. it's not a gee-wiz debugger >> that you can set break-points and such, but it will allow you to view >> the code as it executes and the values in user-specified variables. > >Does anyone have a NAIUA username and password I can borrow, or >alternatively a copy of the tar file? I don't see anything on that site that is password protected? (Lots of broken links once off the home page, but no passwords...) I can download osq-debug with no problems, try http://www.naiua.org/toolz/scriptdir/osq-debug.tar The resulting tar file seems to be a bit squirrely but it does untar into something that is more or less readable. Karl > I can download osq-debug with no problems, try > > http://www.naiua.org/toolz/scriptdir/osq-debug.tar > > The resulting tar file seems to be a bit squirrely but it does > untar into something that is more or less readable. Thanks, downloaded fine ... Andrew Another question is why would you want to bother? If you are doing enough development to bother with such a thing, why not get rid of ABF? Conversion isn't that expensive if done properly. >Hi group, > [quoted text clipped - 10 lines] > >Andrew Wilson > Another question is why would you want to bother? If you are doing enough > development to bother with such a thing, why not get rid of ABF? > Conversion > isn't that expensive if done properly. "Properly" would have to be near-miraculous IMO. We have a number of customers running core systems based on ABF that work perfectly well. They are large, stable applications that took hundreds of developer-years to create. They are so stable that there are no in-house development or support personnel. But every so often they need a minor enhancement. What would be the business case for spending, say, $3 million to replace something that really only needs a $5,000 tweak? Roy I think there is still room for ABF type server based installations. simonl wrote > ..why not get rid of ABF? We had an overnight ABF job for many years which took input from an automatically prepared keystrokes file. It was converted to OpenROAD for maintainability / marketability reasons - pretty much a cut/paste exercise. We lost the ability for us to easily control and monitor the process from an external point of view. It also lost out on performance and security because of the large volume of data being processed over the network. It also turned out to be much less reliable due to occasional environmental problems at client end. The script was something like this. # Build_keystrokes_based_on_date > keystrokes.txt cat keystrokes.txt | slowdownfilter_writtenin_c | my_ABF_app -dmydb startproc | tee \tmp\savemylogplease.txt Check_for_errors \tmp\savemylogplease.txt ahhh the power of unix!!! Paul oh yes.. It cost a week's development and introduced a couple of new bugs. I don't think the budget need to stretch to $3 million for a 1000 frame app. Perhaps $500,000 so long as the osq generator problem doesn't apply (yes, I think this one would be a killer). But my argument was if the development effort being applied to such an application was enough to justify spending significant amounts of time and/or money on getting a debugger, why not stump up a little bit more up front to go to something which could reduce your long term development costs. The advantages of going down another route are, as Paul correctly points out, not that much for batch processes. Properly or near properly is possible. >> Another question is why would you want to bother? If you are doing enough >> development to bother with such a thing, why not get rid of ABF? [quoted text clipped - 11 lines] > >Roy >I don't think the budget need to stretch to $3 million for a 1000 frame >app. Tell us more. I am standing on the sidelines watching as a ?3 million replacement is being procured for an ABF system. Where did they go wrong? How would you recommend going about it? Be specific. > Perhaps $500,000 so long as the osq generator problem doesn't apply (yes, > I > think this one would be a killer). I'd still want to see a business case. Where am I going to get $500,000 benefit, how long will it take to pay back, and why is that a better thing to spend $500,000 on than anything else I could spend that money on? (BTW the project that I am watching unfold appears to offer zero payback ever, and none of their arguments for doing it are even coherent, never mind plausible. Maybe wanting return on investment is just my personal fetish.) > But my argument was if the development > effort being applied to such an application was enough to justify spending [quoted text clipped - 3 lines] > long > term development costs. I don't think debuggers cost enough that you could ever make that argument stick. Roy If you have an in-house developed application which meets all your business needs with little need for any further development, the business case is tough. But it is a whole lot better than spending $3 million to get no real advantage. And $3 million doesn't buy you that much software development these days. But even for in house development, if you are still doing significant development better technology can result in lower enhancement costs. As you sort of say though, the development has to be pretty significant for this argument to work. Where the main advantage of modernising an ABF application (via Transforge) comes into it is if you are a software house looking at making some additional sales. The first Transforge project I worked on made some sales that it is hard to imagine them ever making if they stayed with ABF. The second one I sold only to they're previous customers last I heard, but that did prevent some of their customers leaving them. I've seen a presentation from the internet about a UK company that did something similar. Re: debuggers don't cost enough: Given that you can't buy a debugger for ABF for love or money, did you mean they don't add enough value for that argument to stick. Maybe, but a few months ago I added a debug to one program which consisted of writing to a log file every parameter passed to that program. It took over an hour just to type in the debug. Try retrofitting that to every program, and you've got a job that I don't want. And where do I get my figures? It's based on what I think is achievable if I did it again, with a profit margin, assuming only a small cost (<$100000) to the Ingres Corp for actually producing the Transforge output. In fact, the second Transforge project I worked on was in excess of 1000 frames, and took about 1.5 person years to do the post-transformation adjustment, including GUI-fying (adding drop downs etc) to all the frames. So excluding what was paid to CA (which I wasn't privy to), I'd say it got well under the $500000 figure, but the complexity was fairly low. >>I don't think the budget need to stretch to $3 million for a 1000 frame >>app. [quoted text clipped - 24 lines] > >Roy [snip] > Where the main advantage of modernising an ABF application (via Transforge) > comes into it is if you are a software house looking at making some > additional sales. [snip] I would agree, and I would add that even the case for using migrating INGRES/ABF to more contemporary platforms, e.g. VAX/VMS to x86_64/GNU/Linux, doesn't really apply, from what I've experienced. ABF seems to migrate with ease, and most of the work is in the ESQL migration. Mark R. Winston www.datavailable.com Simon wrote... > second Transforge project I worked on was in excess of 1000 frames, and took > about 1.5 person years to do the post-transformation adjustment, including > GUI-fying (adding drop downs etc) to all the frames. So excluding what was > paid to CA (which I wasn't privy to), I'd say it got well under the $500000 > figure, but the complexity was fairly low. I've been using a benchmark of around 1 man day per frame for manual conversion of ABF to OpenROAD. With offshore developers it works out to less than $US200 per frame. Straight conversion is a fairly simple recipe, just dull and boring cut, paste and substitute. Then you get down to specifics and allow time for more complex functions and integration specifics - reports, system calls, database triggers, appserver functions, etc. Without looking closely I would have guesstimated around 4 man years for the job. <salespitch> I've found management decisions are often made on the appearance of the software. Converting to OpenROAD give you a more acceptable and attractive product AND more functionality. Using OpenROAD keeps the underlying business intelligence intact and is 100% compatible with existing ABF applications. Manual conversion, together with a staged rollout, offers low risk to the business. The proof of concept can be low cost requiring very little analysis or setup. You can convert and release one module at a time. You can set your own pace depending on development and QA resources. </salespitch> Paul >I don't think the budget need to stretch to $3 million for a 1000 frame app. >Perhaps $500,000 so long as the osq generator problem doesn't apply (yes, I [quoted text clipped - 3 lines] >up a little bit more up front to go to something which could reduce your long >term development costs. Because the numbers you are comparing are typically different by at least two or three orders of magnitude; with the development/debugging number being the smaller. Feasibility of conversion also depends on how the app was written. Larger apps will tend to use more ABF tricks to save code and implement clever forms display idioms, and these tricks don't convert well. I was involved with the TelesisMFG ERP app some years back, and the notion of converting it automatically is laughable -- I defy any program analyzer to understand more than a fraction of what that code is doing. (OTOH for a human reader, it is or at least was relatively decent code.) I'm with Roy; a conversion of any significant app should only be done after a proper business case analysis. Karl > >I don't think the budget need to stretch to $3 million for a 1000 frame app. > >Perhaps $500,000 so long as the osq generator problem doesn't apply (yes, I [quoted text clipped - 22 lines] > > Karl I'm not sure where simon it getting his numbers....but even at $500,000, you'd have a hard time making a business case. The OP seems to imply that he wanted to examine one (or possibly a few) pieces of ABF with a *free* debugger. Besides, the last time I looked, the actual cost of conversion was well in excess of $500 / frame > Another question is why would you want to bother? If you are doing enough > development to bother with such a thing, why not get rid of ABF? > Conversion > isn't that expensive if done properly. Actually our code is Vision code that dumps to ABF with a very clever post processor, written in perl, that takes care of most of the mundane coding through templates and macros. It would of course be possible to migrate the "generated" code automatically but management has decided that that is not an option. At present, although the codebase is vey large it is easily maintained due to the post processor. I agree with management that the cost of conversion along with the loss of ease of coding would render the project a dead duck. We are actually in progress with a manual conversion to a system based on web technology from a danish companies framework (eifos from captator). Andrew |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.