Argument type mapping

The data type of a parameter is declared in the routine (see Defining a parameter). However, a variable passed to a routine parameter may have been declared with a different data type in the calling routine. In this case, the data type actually used in the routine may not be what you would expect.

Keep the following rules in mind regarding what happens to argument data types when passing arguments to routines:

For example, if a decimal variable is passed to a routine where the parameter is defined as numeric, the parameter will be treated as a decimal within the routine. If an implied‑decimal (d.) variable is passed, it will be treated as implied‑decimal. We recommend that you define parameters as n rather than d, d., or i to ensure that the passed‑in data retains its data type. You can use the numeric parameter compiler option to convert all decimal‑type arguments to numeric. See Compiler options.

For example, if a decimal variable of four decimal digits is passed to a routine where the parameter is defined as integer, the argument will be treated as an i4 variable by interpreting the passed variable as binary data—with no conversion within the routine.

If a subroutine passes the data to a second subroutine, the rules defined above still apply. For example, say you have two subroutines, sub1 and sub2. In sub1, arg1 is declared as alpha; in sub2, arg1 is declared as numeric. If var is defined as a decimal in the calling program, and then passed to sub1 as arg1, it will be treated as an alpha within sub1. If sub1 then passes var to sub2 as its arg1, it will be treated as an alpha within sub2.

Note

If your routine has multiple optional arguments and you want to make use of strong prototyping, you can specify the VARARGS modifier in your routine definition to enable you to pass more arguments than are declared without causing problems. (Note that if you use VARARGS, you will not be able to run your code on versions of Synergy prior to 9.1.1.)