Subroutines vs. SubProcedures

[MCWebsite.Staff]

** This thread discusses the article: Subroutines vs. SubProcedures **
** This thread discusses the Content article: Subroutines vs. SubProcedures0

[buck.calabro@commsoft.net]

Subroutines vs. SubProcedures

** This thread discusses the article: Subroutines vs. SubProcedures **
One can end the current program with CEETREC. This will not simply end the current program, however - it kills the activation group. In a pinch, making this program *NEW will allow CEETREC to kill just this program. Compile this as *NEW and you'll see that the program does terminate before the DSPLY happens. d cel_rc_mod s 10i 0 inz(-1) d user_rc s 10i 0 inz(-2) c callb 'CEETREC' c parm cel_rc_mod c parm user_rc c 'still run' dsply c eval *inlr = *on --buck

[peterklevy]

Subroutines vs. SubProcedures

** This thread discusses the article: Subroutines vs. SubProcedures **
Another opinion for continuing to use subroutines within subprocedures: There are professionals out there that write programs whose looping and IF-THEN-ELSE blocks span many pages. These denizens, of what seem to be the programming equivalent of skyscrapers, are able to traverse and decipher such entities without any apparent trouble. They are unconcerned with compactness and brevity. They prefer to walk long straight paths up and down rather than move back and forth over wide areas. I'm not of them. I'm a wide area kind of programmer. My style is to code such blocks so that they span no more than one or two pages. The code within is broken up logically into many small routines, such that each one accomplishes a logical part of the entire task. For me such a design is much easer to traverse and decipher. In this kind of design philosophy subroutines have a part to play. When code is unique to a particular task and the blocks are becoming large and un-wieldy then breaking them up into subroutines is a prudent methodology. Not that you couldn't use sub-procedures in this endeavour, but moving them into subroutines is much easier. In addition when later on I've found that one or more subroutines might better serve the community in a service program I've never had a problem moving them into those confines. Like the aforementioned blocks, the subroutines themselves aren't large either and figuring out what parameters to pass to them isn't that difficult.

[Guest.Visitor]

Subroutines vs. SubProcedures

** This thread discusses the article: Subroutines vs. SubProcedures **
I applaud the idea of reusable procedures, but copying them in isn't the right way to do it. A service program is the correct solution.

[bigdouglas]

Subroutines vs. SubProcedures

** This thread discusses the article: Subroutines vs. SubProcedures **
I always thought you were supposed to program in a way that advances your shops knowledge. What you are describing is programming for the weakest link. Create an environment where advancement of knowledge is rewarded and your company as a whole will benifit. You can not know if it is the most effective and efficient way if you don't know how to do it in the first place.