× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



And won't the database do the caching already?

On Wed, Dec 8, 2010 at 11:25 AM, Mark Murphy/STAR BASE Consulting Inc. <
mmurphy@xxxxxxxxxxxxxxx> wrote:

The big issue I have with writing my own database caching code is that I am
not keeping my data fresh. If later I update the file, my internal cache
does not get updated, and I can get the wrong values out. Just saying, you
have to be careful with it.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx

-----rpg400-l-bounces@xxxxxxxxxxxx wrote: -----
To: rpg400-l@xxxxxxxxxxxx
From: Buck
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
Date: 12/08/2010 12:19PM
Subject: Re: trying to be modular

On 12/8/2010 8:51 AM, David FOXWELL wrote:

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.

I think many of us have gone down this path, but your post will be a
great reference for those who haven't yet. Thanks for posting!

In my pgm :

// *IN49 is already on.

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

ENDIF;

As an outsider (or maybe a new programmer in your organisation?) I have
to ask what '4' might mean, and what indicator 49 does. Referring to
them by a named constant would make my comprehension a bit easier, so:
IF GetAutLevel >= CONFIDENTIAL;
HIDE_ID_NUMBER = *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

I can't tell from just this bit of code what is being 'set' in the user
info. So I'll have to go open up that function to see what it does.
Apparently, it does something to (at least) UAUTNV.

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

It doesn't look like a 'set' but a 'get'. And here's where the decision
making gets harder. There is no 'right' answer. Is there more user
info somewhere else, or is this all of it? Is there a structure that
holds the combined user info? Is it global? Should it be?

This returns an indicator and changes parameter 'Error.' The caller
tests the indicator but not Error. Is this duplicate functionality?
Could this return Error instead, and the caller test for NORMAL? Shop
standards could go either way, and I personally wouldn't have a
complaint with either one.

I like the pseudo-caching of the retrieved database record with the
static user ID. Overall I rather like this general design.
--buck
--

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.

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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.