|
> From: Douglas Handy > > The basic problem is that the BIF's are *functions*, not data values. The > debugger can display the value of any variable, *INxx or > otherwise, but cannot > display the value of any function, %BIF or otherwise. Even the simplest Java IDEs support showing the results of a function, but that's really not the discussion here. I understand your contention that a general ability to show the results of functions is difficult, but to show the results of the %EOF, %ERROR and %FOUND BIFs wouldn't be difficult at all. > Personally, I *like* the new BIFs and eliminating the indicators. > For debugging > purposes, it is more often than not (in my case) used on a simple > IF or DOW or > WHEN, etc and single stepping the code makes it obvious whether > the db I/O was > successful just by how the program execution flows. That's fine while you're stepping through code, but sometimes I want to know the current condition of a variable once I've hit a breakpoint. With an indicator, I could, with a BIF I cannot. What you're suggesting hearkens back to a time when I couldn't even see the contents of variables, and had to set a breakpoint at every condition point in order to determine what was happening in the program. > And for cases where you have compound expressions so can't tell > by a simple > program flow single step, you can either examine the INFDS or > create a dummy > variable for testing and set it like: > > Chain > Eval Dummy = %found() > If %found() And FooBar() = 3.14159 > > then remove the Dummy line after debugging. Requiring dummy code to test a program is absolutely wrong, because that means I either leave dummy variables in my program (inefficient) or I have to remove them after testing, which means I never put into production actual tested code. Either of these is a bad choice, and in fact the latter will not pass strict auditing procedures. And using an INFDS is just as bad - why should I be required to add an INFDS to a program that doesn't use it, just because the debugger hasn't been upgraded? What if I had hundreds of programs that don't use the INFDS - is it your opinion that I should add an INFDS to them all? > I *don't* think it is a matter of a couple of hours time to do > something like > this to the debugger. For %EOF, %FOUND and %ERROR it most absolutely is only a couple of hours, although I'd love to hear someone in IBM tell me it's more. Then I'd like to do some consulting work for that particularly department. > The times I have used it and needed to debug, single stepping > works for me. Single stepping is not practical in all cases. In fact, I rarely single-step during debugging, except when learning a new piece of code. For code I am familiar with, setting breakpoints is far more preferable and productive. > How is it that not being able to display the result of a BIF is > "taking away > functionality"? The loss of functionality is not purely the issue of the BIF, Doug. It's the fact that, before the BIFs were available, I would write an I/O opcode, set a breakpoint immediately after the opcode, and be able to immediately determine the results of the operation without having to step through other code. With the new coding style, I am told to stop using indicators, and use BIFs instead, but now I can no longer execute that same procedure. A small thing perhaps, but it's the general idea that changes are being made with little regard for the impact on those of us who use the tools. It really wouldn't have taken that long to figure out a way to show the results of those particular BIFs. This is my opinion, clearly, and you may not share it. But I think it's kind of annoying that I need to change my development style unnecessarily. This isn't like the change in mindset required to move from procedural to OO, this is simply the fact that IBM decided to change the preferred syntax of the language but didn't update the debugger to keep up with it. That's a mismanaged resource allocation, in my mind. Joe Joe
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.