Debugging (in D3)

I'm just thinking out loud here...

I personally detest INCLUDEs. Why? Well, for 3 very important reasons:

1. If a change is made to the INCLUDEd item, all programs using it must be recompiled. One or more main programs could be missed, thus still using the old code.
2. When an error occurs inside an INCLUDEd item, only the line number of the INCLUDE is shown, not the line number inside the INCLUDE itself, thus making debugging an INCLUDE more difficult, nigh impossible depending on its size and complexity.
3. INCLUDEs do not isolate the code from the calling/using program, thus accidental (or on purpose) reuse of variables can be a danger, causing unexpected behaviour of the main program.

So here's the question: Is there a way for D3 to show the line number in the INCLUDE where the error occurred? Would this be an enhancement request? Would it even be possible?

If not, how do people go about debugging an INCLUDE? Short of physically embedding the INCLUDE code in the program (temporarily), I can't think of any other way to do it.


------------------------------
Walter Kiess
SA Police Super
------------------------------

1. In our programming standards we maintain a list of files which contain programs.  When an "include" is changed, our compilation process scans each of these files with a FIND for the include and then re-compiles each.  Nothing manual – it is all automatic.
2. You make a good argument for when not to use INCLUDE.  Again, our standard is to only use INCLUDEs for variable definitions (like EQUATEs).  Further, our INCLUDEs are one-liners sometimes with lots of semi-colons.  This standard has served us well for 30+ years.
3. Personally, I feel that code/logic should be in external subroutines and not embedded within INCLUDEs.  You can take better advantage of runtime errors this way as well as logging your own calls to these subroutines.

------------------------------
Michael Archuleta
President
ArcSys Inc
------------------------------

1. In our programming standards we maintain a list of files which contain programs.  When an "include" is changed, our compilation process scans each of these files with a FIND for the include and then re-compiles each.  Nothing manual – it is all automatic.
2. You make a good argument for when not to use INCLUDE.  Again, our standard is to only use INCLUDEs for variable definitions (like EQUATEs).  Further, our INCLUDEs are one-liners sometimes with lots of semi-colons.  This standard has served us well for 30+ years.
3. Personally, I feel that code/logic should be in external subroutines and not embedded within INCLUDEs.  You can take better advantage of runtime errors this way as well as logging your own calls to these subroutines.

------------------------------
Michael Archuleta
President
ArcSys Inc
------------------------------

Ah, yes, Standards... I'm afraid the original developers of our system didn't have too many of those. Especially relating to INCLUDEs. I've spent the last 28 years developing and refining standards for our system. They're still not perfect and I break them from time to time, but that's extremely rare and only to solve a problem that could not be solved (easily) by sticking with the standards.
I have developed a migration utility that migrates all the components that make up the changes made to the system for a work request. I must admit, I hadn't thought of scanning the items for INCLUDEs and then finding all the programs using it and recompiling them. Thanks for the idea, I'll get right on it! :)
I'm a great believer in modularity, of divvying up a problem into smaller steps, thus I have created a lot of subroutines that do the hard work. The main program basically coordinates these subs. This makes debugging easier and any changes flow right through the system to all the other programs only requiring the sub to be recompiled. Much neater, quicker and safer.
There's one caveat though with external subroutines: The parameters are passed by reference and not by value, thus any changes made to the parameter variables are passed back to the calling program. I overcame this by naming the parameters in the subroutine header with the prefix IN. and OUT. to ensure unique names and also to indicate the direction of data flow to the sub (I also ensure all inflowing data is shown first and all outflowing data is shown last in the parameter list).

------------------------------
Walter Kiess
SA Police Super
------------------------------

Ah, yes, Standards... I'm afraid the original developers of our system didn't have too many of those. Especially relating to INCLUDEs. I've spent the last 28 years developing and refining standards for our system. They're still not perfect and I break them from time to time, but that's extremely rare and only to solve a problem that could not be solved (easily) by sticking with the standards.
I have developed a migration utility that migrates all the components that make up the changes made to the system for a work request. I must admit, I hadn't thought of scanning the items for INCLUDEs and then finding all the programs using it and recompiling them. Thanks for the idea, I'll get right on it! :)
I'm a great believer in modularity, of divvying up a problem into smaller steps, thus I have created a lot of subroutines that do the hard work. The main program basically coordinates these subs. This makes debugging easier and any changes flow right through the system to all the other programs only requiring the sub to be recompiled. Much neater, quicker and safer.
There's one caveat though with external subroutines: The parameters are passed by reference and not by value, thus any changes made to the parameter variables are passed back to the calling program. I overcame this by naming the parameters in the subroutine header with the prefix IN. and OUT. to ensure unique names and also to indicate the direction of data flow to the sub (I also ensure all inflowing data is shown first and all outflowing data is shown last in the parameter list).

------------------------------
Walter Kiess
SA Police Super
------------------------------

In line 0007 a couple of simple 'tricks' to pass variable by value

PROG
001 PROGRAM PROG
002 *
003 A="a"; B=1
004 *
005 CRT "PROG: A=":A:" B=":B
006 *
007 CALL SUBR( A:"", (B) )
008 *
009 CRT "PROG: A=":A:" B=":B

SUBR
001 SUBROUTINE SUBR(A,B)
002 *
003 CRT "SUBR: A=":A:" B=":B
004 *
005 A="A"; B=2
006 *
007 CRT "SUBR: A=":A:" B=":B
008 *
009 RETURN

------------------------------
Stefano Maran
GTN Spa
------------------------------

In line 0007 a couple of simple 'tricks' to pass variable by value

PROG
001 PROGRAM PROG
002 *
003 A="a"; B=1
004 *
005 CRT "PROG: A=":A:" B=":B
006 *
007 CALL SUBR( A:"", (B) )
008 *
009 CRT "PROG: A=":A:" B=":B

SUBR
001 SUBROUTINE SUBR(A,B)
002 *
003 CRT "SUBR: A=":A:" B=":B
004 *
005 A="A"; B=2
006 *
007 CRT "SUBR: A=":A:" B=":B
008 *
009 RETURN

------------------------------
Stefano Maran
GTN Spa
------------------------------

I LOVE your solution to this issue, Stefano. Simple and easy to implement. It's a pity that passing by value is not the default and forcing a reference optional, like most other high-level languages. I guess it's a legacy thing where encapsulation wasn't a thing back then (though it should have been).

------------------------------
Walter Kiess
SA Police Super
------------------------------

Ah, yes, Standards... I'm afraid the original developers of our system didn't have too many of those. Especially relating to INCLUDEs. I've spent the last 28 years developing and refining standards for our system. They're still not perfect and I break them from time to time, but that's extremely rare and only to solve a problem that could not be solved (easily) by sticking with the standards.
I have developed a migration utility that migrates all the components that make up the changes made to the system for a work request. I must admit, I hadn't thought of scanning the items for INCLUDEs and then finding all the programs using it and recompiling them. Thanks for the idea, I'll get right on it! :)
I'm a great believer in modularity, of divvying up a problem into smaller steps, thus I have created a lot of subroutines that do the hard work. The main program basically coordinates these subs. This makes debugging easier and any changes flow right through the system to all the other programs only requiring the sub to be recompiled. Much neater, quicker and safer.
There's one caveat though with external subroutines: The parameters are passed by reference and not by value, thus any changes made to the parameter variables are passed back to the calling program. I overcame this by naming the parameters in the subroutine header with the prefix IN. and OUT. to ensure unique names and also to indicate the direction of data flow to the sub (I also ensure all inflowing data is shown first and all outflowing data is shown last in the parameter list).

------------------------------
Walter Kiess
SA Police Super
------------------------------

We have a "book" of standards that has been here before I joined the company. It is pretty detailed even though it is just about 5 pages long.  Our code looks pretty much the same, regardless of who was the programmer. Even variable names are alike.  :)

We are not using INCLUDEs and GOTOs at all. I think there is no real reason to use them. Subroutines do not require recompiling all programs that use them, debugging is as easy as the main program and variables are not shared (except parameters).  GOTOs can be replaced with a more structured program.

COMMON is another one, that I think should be avoided or at least each subroutine/program should list them verbatim.

------------------------------
Chris Wolcz
Senior Software Developer
EXEControl Global Solutions
Clifton Park NY United States
------------------------------

We have a "book" of standards that has been here before I joined the company. It is pretty detailed even though it is just about 5 pages long.  Our code looks pretty much the same, regardless of who was the programmer. Even variable names are alike.  :)

We are not using INCLUDEs and GOTOs at all. I think there is no real reason to use them. Subroutines do not require recompiling all programs that use them, debugging is as easy as the main program and variables are not shared (except parameters).  GOTOs can be replaced with a more structured program.

COMMON is another one, that I think should be avoided or at least each subroutine/program should list them verbatim.

------------------------------
Chris Wolcz
Senior Software Developer
EXEControl Global Solutions
Clifton Park NY United States
------------------------------

I'm with you, Chris.
Sadly, the original developers of our system used INCLUDES and COMMON extensively throughout the system. They are so firmly embedded that it is not possible to remove them without a complete rewrite of the system, something no one would ever want to tackle. So I'm stuck with them and have to make do the best I can.
I'm a firm advocate of encapsulation and do my best to write code in such a way. This allows me to reuse code without having to worry about its effects on the main program other than the function the sub was designed for.

------------------------------
Walter Kiess
Manager IT
SA Police Super
Adelaide SA Australia
------------------------------