RE: trying to be modular

-----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?