Now it's time to write the calcDays procedure. Put it at the end of h-CustSample.p, following all the code you've written so far.

Each internal procedure starts with a header statement, which is just the keyword PROCEDURE followed by the internal procedure name and a colon.

Following this you need to define any parameters the procedure uses. The syntax for this is very similar to the syntax for the DEFINE VARIABLE statement. In place of the keyword VARIABLE, use the keyword PARAMETER, and precede this with the parameter type—INPUT, OUTPUT, or INPUT-OUTPUT. Note that the keyword INPUT is not optional in parameter definitions. Here's the declaration for the calcDays procedure and its parameters. The parameter names start with the letter p to help identify them, followed by a prefix that identifies the data type as DATE or INTEGER:

PROCEDURE calcDays:
  DEFINE INPUT  PARAMETER pdaShip  AS DATE       NO-UNDO.
  DEFINE OUTPUT PARAMETER piDays   AS INTEGER    NO-UNDO.

Now you can write ABL statements exactly as you can for an external procedure. If you want to have variables in the subprocedure that aren't needed elsewhere, then define them following the parameter definitions. Otherwise you can refer freely to variables that are defined in the external procedure itself. You'll take a much closer look at variable scope and other such topics later. Be cautious when you use variables that are defined outside a procedure unless you have a good reason for using them, because they compromise the modularity and reusability of your code. For example, if you pull your procedures apart later and put the calcDays procedure somewhere else, it might break if it has a dependency on something declared outside of it. For this reason, you pass the calculated number of days back as an OUTPUT parameter, even though you could refer to the variable directly.