RE: Modules Question

Hi Robert,

OK, the code would appear to be the start of something that didn't get
finished. The repeated lines are probably a block pasted in to be overtyped
when the programmer got round to it. The other code may be used to allow
debug data to be generated for DB fields for testing. But why do that when
an externally described DS would do that for you?

Back to your main question - code within one module can't see code within
another module. It can call procedures that are exported or if you have a
procedure pointer to the address of the procedure. You can see variables if
they are exported from the module and the second module has them set as
import fields. But code in one module can not directly run subroutines
inside subprocedures in another module. Further, one subprocedure can not
directly run subroutines within another subprocedure within the SAME module.
It just can't see them.

Regarding the 'calling' program. Exactly how is this set up? A module can
not be run on its own so it can't be called. You can call the main procedure
within a module but the module must be bound into a runnable object - *PGM
or *SRVPGM. The object is copied directly into the object (bind by copy) and
exists as an integral part of the object. Subprocedures within these objects
can only be called by subprocedures within the same module unless:

1) EXPORT is used on the definition - then subprocedures within other
modules bound into the same object can call the subprocedure.
2) EXPORT is used on the definition AND the module forms part of a service
program AND the subprocedure was exported from the service program using
binder language or export(*all) on the create command. Then the subprocedure
can be called from another object.

I'm not sure what the 'calling' program is but I'm pretty sure it could not
directly run a subroutine which resides within a subprocedure in another
module/object.

Cheers

Larry Ducie