Re: trying to be modular

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?

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.

Someone is going to complain that this approach is inefficient. It probably won't be noticeable. Depending, of course, on your hardware, and if you call it 100 or 10 million times a day.

(And FWIW, SetUserInfo might be more properly called GetUserInfo, since it appears to be retrieving information rather than setting it. Setting, I think, generally implies changing. But this might be a language issue.)

Sam

On 12/13/2010 3:47 AM, David FOXWELL wrote:

-----Message d'origine-----
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de
Lennon_s_j@xxxxxxxxxxx

From what I see, there is vast sharing of global data going
on. (Paul's comment on coupling is on the mark.) Personally,
I dislike sharing global data. I'd much rather see this in a
service program.

Sam, I could have used a service program but how would that make any difference to the sharing of global data?

This is an attempt at modularising my code. At the risk of

getting slammed, I ask if it is acceptable and to tell me
what the disadvantages may be and how I should have done this.

Had to get an authorization level from a user information

table to condition a screen indicator in an existing program.
The user table contains lots of other information like name,
department and telephone number, etc.

In my pgm :

// *IN49 is already on.

IF GetAutLevel>= '4';
*IN49 = *OFF;

ENDIF;


In a separate module where the user table is already used,

I added :

P GetAutLevel B EXPORT
D PI LIKE ( DFN_AUTLV )
D UserId LIKE ( DFN_USRID ) CONST
D Error LIKE ( DFN_ERRMG )

D wAutLv S LIKE ( DFN_AUTLV )

IF NOT SetUserInfo ( UserId : Error );
RETURN *BLANK;

ENDIF;

RETURN UAUTNV; // From user table

P GetAutLevel E




P SetUserInfo B
D PI N
D UserId LIKE ( DFN_USRID ) CONST
D Error LIKE ( DFN_ERRMG )

D wUserId S LIKE ( DFN_USRID )
D STATIC

IF wUsrId<> UserId;
CHAIN UserId USRCFD;
If not %found;
error = ....
RETURN *OFF;

ENDIF;

RETURN *ON;

P SetUserInfo B

--
This is the RPG programming on the IBM i / System i
(RPG400-L) mailing list To post a message email:
RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change
list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.