Re: 9/9/99

I actually saw it happen once on one of my jobs.  I was using FORTRAN
though, and not COBOL.  It was the first FORTRAN program I had written
to read data, and didn't know to put in a special card.

I handed the operator my deck with about 8 other people, and mine was
about the 3rd job in line.  I was waiting around for the other jobs to run,
would watch the cards read the program, pause, read the data, pause,
then produce some output.

Then on one job it started reading cards... and didn't stop.  About 1/2
way down the deck of remaining cards the operator realized something
was wrong and aborted the run, went back through the deck to the start
of my job and handed me the cards, telling me that it hadn't stopped reading
the data.

I was really learning this on my own (I was 10 years old at the time) so
found someone to tell me what was wrong, and they explained the 9's rule
to me.

After that I became a little more interested in how the decks were stacked,
and they were putting the special cards between jobs.  3 cards I seem to
remember, one for start of job, one for end of job, and one card that was
a different color (blue I seem to recall) just so the operator could visually
tell the jobs from one another.

Regards,

Jim Langston

Howard Weatherly wrote:

> Perhaps true but..... all data on a mainframe is ended with a card coded
> as /* to the operating system this means end of data. There could be
> other decks behind each ending with a /* and a final card with a /& that
> indicates end of job. So the point being, that what you heard is true
> but only if someone not familiar with job setup is stacking the deck.
>
> Again within any one of the data decks, that is any card data between
> the first data card and a /* card could conceivably contain many logical
> subsets of data each needing to be terminated by something, your example
> is picking the/an date field containing 09/09/99... This would not be my
> first choice even if the current date were 1/1/1959.
>
> Jim Langston wrote:
> >
> > When I learned COBOL it was on a mainframe that used punch cards.
> > If you were reading data and you did not look for a "special" card you
> > coded with a "special" value, it would just read through the rest of the
> > deck, including any other programs after yours, thinking it was data.
> >
> > If you did not enter the data in the format your read was expecting it,
> > you would get a run time error.
> >
> > The solution was to put a "special" value in one of your fields.  If you 
>were
> > reading string text, you could use *** EOF *** or something like that, but
> > if you were reading numeric fields,  you had to put in a numeric value, and
> > all 9's was commonly used, and was in fact called the "9's rule".
> >
> > Jon.Paris@halinfo.it wrote:
> >
> > >  >> From all the discussion I've heard on it, that was a common practice 
>in
> > > COBOL programs as COBOL has no real EOF function (or didn't anyway).
> > >
> > > I don't recall any point in history when COBOL did not have an AT END 
>option
> > > (i.e. EOF).  On some systems I have worked with placing a high value (all 
>9s) in
> > > a dummy record at the end of file was done to allow you to position to
> > > (effective) EOF and read backwards - or is this what you meant by EOF 
>function ?
> > >
> > > Either way, it would never finish up as 09/09/99 it would have been 
>99/99/99.
> > >
> > > +---
> > > | 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
> > > +---
> >
> > +---
> > | 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
> > +---
> +---
> | 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
> +---

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