Re: FMTSRC

"Buck Calabro/commsoft" <mcalabro@commsoft.net> wrote:

Hi Buck,

>May I throw my hat into the ring?

By all means, but be careful nobody steps on it.  :-)

> * Select from 1999/07 through 2000/01 inclusive
> * Drop the record if the year is too late
>O C 117 118EQC20                  CC
>OAC  54  55GTC00                  YY
 >* Drop record if year is too early
>OOC 117 118EQC19                  CC
>OAC  54  55LTC99                  YY
 >* Include dates within the specified month range
>I C  54  55EQC99                  YY
>IAC  56  57GEC07                  MM
>IOC  54  55EQC00                  YY
>IAC  56  57LEC01                  MM

Fine, but what if the range is, say, 2000/05 to 2001/04? Substituting the
from and to centuries and years directly into your code you would firstly
reject all the records > 2001 (let's be generous and assume there are no
22nd century dates as this would be the case with most real world systems).

When you go to drop the records below 2000 you would omit all those with a
century of 20 and a year less than 00. There aren't any, of course, but
this is unimportant (see below). But there may be any number with a century
of 19. These are still in, and the includes would grab any records in the
range 1900/05 to 1901/04. In most cases you'll get away with it, but there
are real world systems with dates this old, and your solution is not
universally correct.

>With all due respect, Dave has the right answer, but the specs for GT 1999
>and LT 2000 still have comparisons that will always fail (LT00 and GT99).

This doesn't matter in the least. The comparisons fail because these are
edge conditions, but the algorithm works perfectly for any date that
Booth's system cares to plug in. Your solution also has comparisons that
always fail if the high date of the range has a year of 99 or the low date
has a year of 00. You've simply masked this by not choosing edge conditions
in your example.

>Again, respectfully, this was NEVER an easy problem to solve--we always
put
>dates like this in contiguous fields so that we could use 2 statements:
>I C  54  61GEC19990701            CCYYMMDD
>IAC  54  61LEC20000101            CCYYMMDD

No arguments. It's a nasty, tricky problem, and arranging all the dates in
a sensible form like CCYYMMDD is definitely the way to go. It's a pity
Booth's forced to work with a split date. Split dates serve only 2 useful
purposes: amusing the readership of midrange-l and torturing trainee
programmers.  :-))

Dave Kahn, ABB Steward Ltd.


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---