RE: Assembly programmers do it a byte at a time

Alan, Bob,

I think you are missing my point.

So below is clipped example.

Admittedly each subroutine could be a procedure, but why? 
I would have to pass all needed values to each procedure, while not a big
deal why?
The API this code is from has only two exported procedures, but there are 12
internal procedures (required because of the need to use an attribute of
procedures) and 14 subroutines. The subroutines are local to each procedure,
thus if I made them procedures I would have several initialize,
validateparms, etc... procedures and would have to uniquely name them. Why
go to the effort?
I could remove the subroutines and do everything inline (like C) but with
the logic compartmentalized in subroutines it is eaiser to read and
understand, especially by others IMO.

I really want to understand your point of view: if you only learn from those
who agree with you you learn nothing.

Duane Christen

/*++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++ 
/*   Procedure Code

/*++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++ 
 

 /Free

 

  ExSr initialize;

  ExSr validateParms;

 

  forceRetreival = *OFF;

 

  Select;

 

     When lrnFormat = 'RTVLRN0100';

        ExSr getCurrentLRN;

        ExSr loadLRNFormat0100;

 

     When lrnFormat = 'RTVLRN0105';

        forceRetreival = *ON;

        ExSr getCurrentLRN;

        ExSr loadLRNFormat0100;

 

     Other;

        sndPM_Msg_Id = 'PVM1000';

        %SubSt(SndPM_Data : 1 : 20) = 'LRN Info. Format';

        %SubSt(SndPM_Data : 21 : 10) = lrnFormat;

        stringLength = 54;

        %SubSt(sndPm_Data : 31 : 2) = binLength;

        %SubSt(sndPm_Data : 33 : stringLength) =

          %Trim(lrnFormats.Format(1)) + '&N' +

          %Trim(lrnFormats.Format(2));

          /Include QRPGCBSRC,CQMHSNDPM

     EndSl;

 

     Return;

 

 
//==========================================================================
=================
  //   Get Current LRN from Stack or RASP

 
//==========================================================================
=================
 

  BegSr getCurrentLRN;

 

     stackIndex = findLineInStack(line0100.Line);

 

     If stackIndex = 0;                                              // LRN
Not Found in stack  
       stackIndex = putLineInStack(line0100.Line :                   //  Get
LRN from NEC and   
                      getCurrentRaspLRN(line0100.Line));             //  put
it in the stack    
 

     ElseIf forceRetreival;

        updateLineInStack(line0100.line : stackIndex :

                          getCurrentRaspLRN(line0100.Line));         //  put
it in the stack    
     EndIf;

 

  EndSr;

 

 
//==========================================================================
================= 

-----Original Message-----
From: Alan Campin [mailto:Alan.Campin@xxxxxxx]
Sent: Friday, June 24, 2005 1:24 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: Assembly programmers do it a byte at a time


I agree this whole thing gets to be a religious issue. Shouldn't be but it
is. 

I think one issue that has only been touched on with using subroutines vs.
procedures and that is static storage. 

In writing an RPG IV program, static storage should be reduced to the
absolute minimum that you need. One of the primary values of using
subprocedure is that you have local variables. Unless you are using
subroutines inside procedures, you end up with everything being global and
everything static. 

The more static variables that use, the more work the operating system has
to do to manage that static storage. You will find article from Susan
Gartner when she was still with IBM talking about just this problem on the
web.

"C" type languages, which RPG IV is, are very efficient at managing
automatic storage (local variables) and very inefficient at managing static
storage. A well written RPG IV ILE program should have almost no static
storage other than maybe what is brought in by files and embedded Sql on
reduce that even more. Using service programs to implement file I/O can
reduce that to almost nothing.  

A procedure can be a black box. A subroutine can never be. When I write a
program, each procedure is a black box, self contained to do it's job
referring to global variables as little as possible. Why would I want to
keep referring up to a long list of global variables when I can just have
the variables I need to solve the problem in the procedure? Why have to
think about the whole program when I can think about nothing except the
problem I am working on? That's why I use procedures!

Oh well. Like I said. Religious issue. I have this on going battle with the
guy next to me who refuses to use subprocedure for all the same reasons. All
you can do is not talk about it or the air heats up.