One problem i can see there is if any update, delete, add is performed to
the file.
Another way is perhaps to use a user index (not in QTEMP) and add a trigger
to the file for updating the
----- Original Message ----- 
From: "Wilt, Charles" <CWilt@xxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Friday, May 06, 2005 2:53 PM
Subject: RE: Normalization was Left AS/400 and Returned


> An option to consider that hasn't been explicitly mentioned...
>
> Encapsulate the I/O to the data in a service program.
>
> Have the service program load a static array the first time any procedure
in the service program is called.
>
> Now it really doesn't matter how the data is stored.  Instead of a program
chaining to a file to find out if a particular day is a workday or loading
it's own array, you'd call IsAWorkday(date).
>
> You could even have procedures that returned an array for an entire week,
month or year if needed.  But more useful perhaps would be a procedure in
the service program like GetWorkdays(fromDate, howMany) that returned an
array of dates.
>
> Just my .02
>
> Charles Wilt
> iSeries Systems Administrator / Developer
> Mitsubishi Electric Automotive America
> ph: 513-573-4343
> fax: 513-398-1121
>
>
> > -----Original Message-----
> > From: midrange-l-bounces@xxxxxxxxxxxx
> > [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Joe Pluta
> > Sent: Thursday, May 05, 2005 8:08 AM
> > To: 'Midrange Systems Technical Discussion'
> > Subject: RE: Normalization was Left AS/400 and Returned
> >
> >
> >
> > And I understand your preference.  Checking every date by
> > doing a CHAIN
> > or SETLL on a file is easy.  I think part of my bias is that
> > I come from
> > a scheduling background, which means I need information for periods,
> > rather than single days.  I might have to schedule an operation to run
> > over 10 days, and thus I'll have to know all the working days.  By
> > reading a one-year array once, I'm covered and I can schedule all the
> > work for that item.
> >
> > With a one-record per date approach, I'll be doing lots of
> > I/O, over and
> > over again (unless I read the data from the file into an
> > array, at which
> > point your argument about how hard it is becomes moot).
> >
> > I guess my point is that I think you need to look not only at the data
> > but also at how it is used when determining the normalization of a
> > database.
> >
> > Joe
> >
> > -- 
> > This is the Midrange Systems Technical Discussion
> > (MIDRANGE-L) mailing list
> > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/midrange-l.
> >
> >
>
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.