Re: trying to be modular

If you can make the file local to SetUserInfo then you have (probably) solved the "outside interference" problem. And this might be your quickest fix, though once you get the hang of service programs you might find that approach quicker. (Note that I am somewhat spoiled because we use a change management system that make recreating objects really simple. And we are a five-developer shop.)

I assume this: There is a main module, in which SetUserInfo is coded, since you say it is not exported. GetAutLevel is coded in a separate module and is bound to the main module, so it can access SetUserInfo.

GetAutLvl does this:
RETURN UAUTNV; // From user table
and I don't see UAUTNV coded in GetAutLvl, so I assume it must be the global value from the file and is resolved when the modules are bound.

Personally, I prefer the service program approach to the bind approach, because you can be absolutely sure that there is no accidental local access. I also think that it often makes for clearer code.

Sam


On 12/14/2010 8:26 AM, David FOXWELL wrote:

-----Message d'origine-----
Lennon_s_j@xxxxxxxxxxx

As coded, it looks like SetUserInfo ensures that a record for
the specified user is in memory. Buck's comments are right
on--what if somewhere else the record format is re-populated
by another read?

Good point, how about making the file local to the subprocedure? It could even be declared statically. Other subprocedures that used the same file could do the same.

There is a school of thought that says a routine should do
only one thing, but do it very well. SetUserInfo does only
one thing, but it has the potential for not doing it very well.

In a service program scenario, you would have SetUserInfo as
a *private* procedure in a service program.

The same service program would have a public GetAutLevel that
invoked SetUserInfo and returned a value to the caller.

So you would code in your calling program
if GetAutLevel(userid)>= '4';

The service program would have no exported variables and
since SetUserInfo if also not exported, no one call
re-populate the record format from anywhere else.

And the GetAutLevel is also usable by other calling programs,
and you can put other "Get" procedures in the service program.

I'm still not following : in my example, GetAutLevel is exported and coded in a separate module, SetUserInfo is not exported. I would put that into a service program, but what difference does it make as long as those procedures are in a separate module?