This posting is in response to several others over the last two months.
James Mouw of the University of Chicago (to whom I sent a personal
reply) asked several questions on 14 Dec 1990 about the USMARC Format
for Holdings Data (MFHL).  Then there was a question by Thomas Sanders
of Auburn University about MFHL and a reply by Linda Visk of Emory
University.  On 7 Feb 1991, Judith Hopkins at SUNY Buffalo reported on
the LITA MARC Holdings Interest Group meeting at ALA Mid-Winter and
mentioned some interest there in using MFHL for prediction and claiming
purposes.  I have considerable interest in MFHL.

I have only a B.S. in secondary education and I do not belong to any
professional organizations.  I taught science and mathematics in the
public schools for three years but quit that due to developing stomach
ulcers.  I worked at the library of Brigham Young University for many
years in book repair and in the preparation of serials for commerical
binding.

In the 1970'S, Brigham Young University's library produced an automated
serials system based upon a system developed at the U.C.L.A. biomedical
library.  Publication patterns and prediction of the expected issue
were part the the B.Y.U. system.  When B.Y.U. purchased NOTIS on 1985,
it was desired to retain and maintain the publication pattern data and
the predictive capability.  By that time I had taken a COBOL programming
class and was managing the B.Y.U. serials system.  I designed a new
serials system to "plug into" NOTIS.  It utilizes the NOTIS
bibliographic and holdings data, but runs as a program separate from
NOTIS.  Many of the existing features of the B.Y.U. system were kept,
including selective automated claiming and binding notification and
tracking.

The data in the new system is not in the USMARC Format for Holdings.
There was considerable pressure at the time to get a program up very
quickly.  There was some concern about making the new system much
different than the old one.  But I was determined to make the data as
MFHL-like as possible and to predict every predictable issue.  The data
can easily be changed to the USMARC Format.  A program has already been
written which changes it.  The new system went into production in
March of 1989 with many problems.  I have spent the last two years
debugging the system and developing batch programs for it.  The new
system significantly enhanced our predictive capablility and much new
MFHL-like data has been entered.

>From my experience I have come upon what I consider to be some
flaws in MFHL that I would like to air to someone out there who might
be inclined to get some changes made.  Since this posting is already
over long, I will only mention one of them now.

One of my first problems was the fact that some publishers consider
Winter the first season of the year, others consider Winter the last
season of the year and others refuse the make the decision and put
both years with Winter.  When does one change to a new year when there
is only the chronology caption, "(season)" in the "j" subfield.

The first season/last season thing could have been handled with the
"y" subfield (regularity pattern), by putting, for example,
"ps24,21,22,23". But how would one handle, for example,
"1990/91:Winter".  And besides, why should it be necesary to enter
additional data for Winter as the first season.  I believe the format
should be able to handle one as easily as the other.

The description of the "x" subfield (calendar change), would indicate
that it might be helpful, e.g. "21" could be used to show that Spring
is the first season of the year, and "24" could be used to show that
Winter is the first season of the year.  However, I did not understand
exactly how subfield "x" is used and thus did not code it.  This
subfield is described as "codes that indicate the chronological point
at which the next higher level increments or changes".  The "next
higher level" is not precisely defined in my December 1989 format
documentation.  One of the examples in the documentation seems to be
in error as there is no subfield "a" (which is supposedly required).
The other two examples indicate that the "next higher level" is
subfield "a", but then it states that subfield "x" "is not related to
a specific caption".  This still would not have handled the case where
Winter is in both years.

My solution was to use single letter alphabetic codes as chronology
captions.  "(s)" means that Spring is the first season of the year
(and thus Winter is the last season).  "(t)" means that Winter is the
first season of the year.  "(u)" means that Winter is in both years.
This solution saves space, saves data entry time, and may make MFHL
data more transportable in international use.

In addition, I found a need for four codes in place of the chronology
caption, "(day)".  "(d)" means that the number of days between the dates
on consecutive issues is always the same (neglecting omitted dates).
"(w)" means that the number of days between dates on consecutive issues
is always some multiple of 7, i.e., weekly, biweekly or some integral
number of weeks (again neglecting omitted dates).  "(a)" means that the
dates of issue are the same in each month and "(e)" means that the dates
fall on the same day of the week and in the same weeks for each month,
e.g., published on the first and third Thursdays, (once more neglecting
omitted dates in each case).

Dean L. Bennett
Library Automations
Harold B. Lee Library
Brigham Young University
Provo, Utah 84602
(801) 378-7688