Re: Date manipulation

From: Judson McClendon (judmc_at_sunvaley0.com)
Date: 12/23/03 

Date: Tue, 23 Dec 2003 16:05:18 GMT

"Howard Brazee" <howard@brazee.net> wrote:
> "Judson McClendon" <judmc@sunvaley0.com> wrote:
> > >
> > > move date1 (1:2) to date2 (5:2)
> > > move date2 (3:4) to date2 (1:4) ...
> >
> > I agree with you about the two moves, but I really don't think using
> > address modification on fixed field moves like this is a good idea,
> > from a maintenance standpoint. Address modification is great for use
> > in scan loops, and with STRING/UNSTRING, or otherwise where
> > you cannot use group levels effectively. And in a few other specific
> > and clear (and not likely to change) situations like extracting the first
> > character of a name. But for fixed field moves, always use:
>
> I agree with you with one possible exception:
>
> DISPLAY 'SIPR702 BEGAN ' FUNCTION CURRENT-DATE (5:2)
> '/' FUNCTION CURRENT-DATE (07:2)
> '/' FUNCTION CURRENT-DATE (01:4)
> ' ' FUNCTION CURRENT-DATE (09:2)
> ':' FUNCTION CURRENT-DATE (11:2)
> ':' FUNCTION CURRENT-DATE (13:2).
>
> If I saw that in a program I was maintaining, I would not be confused, and it
> may be marginally more clear than moving the date to a work field for the
> display.

Yes, because FUNCTION CURRENT-DATE has a clearly defined
standard format. Even then, unless you remember the exact format of
FUNCTION CURRENT-DATE, it is not immediately obvious which
fields are which. And even if you do remember the exact format, you
would probably still have to stop and do a bit of mental arithmetic to
know which fields you are extracting, and in what order. Using a field
broken down into (well) named components is *always* immediately
obvious, which is why we usually do it that way, of course. :-) 

-- 
Judson McClendon      judmc@sunvaley0.com (remove zero)
Sun Valley Systems     http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."