&EPA
            United States
            Environmental Protection
            Agency
            Office of Planning
            and Management
Management Information
and Data Systems Division
Washington DC 20460
2nd Annual
ADP Conference
November 29, 30 and
December 1, 1977

-------
                        This document is available from:

                            U.S. Department of Commerce
                            National Technical Information Service
                            5285 Port Royal Road
                            Springfield, Virginia 22161
                                     DISCLAIMER
  This report has been reviewed by the Office of Planning and Management U S Environmental
Protection Agency, and approved for publication. Mention of trade names or P™ Envir°lnme"tal
does not constitute endorsement or recommendation for use               commeraal products

-------
2nd Annual ADP Conference
November 29, 30 and
December 1,  1977
Sponsored By
Management Information and Data System Division
Office of Planning and Management
U. S. Environmental Protection Agency
Washington DC 20460

-------
                            TABLE OF CONTENTS
                                                                       Page
                                                                       Number
FOREWORD ............................. iii
AGENDA  .............................. v
GENERAL SESSION I
     Welcome ............................ GS-1
     Lee Johnson  ........................... GS-2
     Willis Greenstreet ......................... GS-6
     David Morin  ........................... GS-6
          Questions and Answers  .................... GS-1 6
PANEL  A:  DISTRIBUTIVE PROCESSING
     Overview of Distributive Processing in EPA
          Theodore Harris  ....................... A-l
     Cincinnati Test Site Experience
          Bruce Almich  ........................ A-4
          Questions and Answers  ....................  A-6
     The EPA Telecommunications Network
          Fred Kastner .........................  A -7
          Questions and Answers  ....................  A -9
     Project  Independence:   Data  Processing Capability
          D.  M. Cline .........................  A-10
     Air Quality Tracking  System/PDP
          Steve Goranson ........................  A-12
     Mini-Computer Success
          Curtis Lackey  ........................  A- 14
          Questions and Answers  ....................  A- 16
     Distributing Processing  Issues at EPA Region V
          Joel Brandon .........................  A- 17
     Region X  Mini- Computer Experience
          Dennis Schur .........................  A- 19
          Questions and Answers  ....................  A-21
     Systems:  Distributed — Centralized- -Independent
          Jim Hammerle ........  ................  A-22
     The Mini-Computer and  National Systems
          Jim Susha .........................  A-25
          Questions and Answers  ....................  A-27

-------
                                                                        Page
                                                                        Number
 PANEL B:   EFFLUENT DATA SYSTEMS
     Introductory Remarks
          Jack Sweeney   ........................  B-l
     EPA's  Needs and Uses of Effluent Data
          Chuck  Evans .........................  B ~2
     Planned Effluent Data Systems
          Bill Milligan .........................  B ~7
     Introduction—The Region II Effluent Data Systems
     Purposes and Goals
          Cliff Lundin .........................  B -9
     Region II:  Summary and Future Systems Usage
          Cliff Lundin .........................  B-ll
          Questions and  Answers ....................  B-13
     Administrative  Efficiency Report
          Pete Gattuso .........................  B-16
          Phil Taylor  .........................  B-19
          Questions and  Answers ....................  B-22
 PANEL C:   EXCHANGE  AND STANDARDIZATION
     Overview
          Ted Standish .........................  C - 1
     Software and Documentation Standards
          Maureen  Johnson .......................  C -4
     Data Integration
          Gail Huguet .........................  C -7
          Questions and  Answers ....................  C-10
     Standard Terminal Contract
          Jim Flatten  .........................  C-ll
     Work Processing Standards
          Cathie Tittle.   . ..                                               -
     Summary Remarks
          Ted Standish ......................... C-18
          Questions and Answers  ....  ................ C-20
                                      *"
PANEL D:  SYSTEM  DEVELOPMENT CYCLE
                                      *•-
     Overview
          Morris  Yaguda ........  .............       D -1

-------
                                                                       Page
                                                                       Number
     Upgrade
          Lance Wallace	D -2
     The Chemical Information System
          Stephen Heller	D -5
     Comments
          Morris  Yaguda	D-12
     Planning for the 1980's
          Morris  Yaguda & Theodore R. Harris	D-13
          Theodore R. Harris	D-16
          Questions and Answers	D-18
     Feasibility Studies
          Don Fitzpatrick	D-21
PANEL E:  ADMINISTRATIVE SYSTEMS
     Introductory Remarks
          Neil Haley	E -1
     The Financial Management System
          Alan M. Kaplan	E -2
          Questions and Answers	E -7
     Resource Management Information System
          C. Tom Wolz	E-10
          Questions and Answers	E-13
     The Personnel Management Information System
          Michael Platt	E-14
          Questions and Answers	E-18
     Contracts Information  System
          Edward McLean	E-22
          Questions and Answers	E-25
     Personal Property Systems
          Cariton Woodeli	E-28
          Questions and Answers	E-31
          Paul Wagner	E-33
          Comments	E-36
PANEL F:  WATER SUPPLY
     Overview
          Fredrick T. Martin	F -1

-------
     Legislative  Direction and
     Decentralization of the Model State
     Information  System
          Dan  Barber
     Meeting the Requirements
     of the Safe Drinking Water Act
     and the Needs of the States and EPA
          Bruce O. Keith
     Test and Acceptance of a System
     for a User Other than  EPA
          Donald Worley ........................ F-19

          Questions and  Answers .................... F-22

PANEL  G:  ADP MANAGEMENT

     Introductory Remarks
          Kenneth  Byram ........................ G--1

          Questions and  Answers .................... G -3

     MIDSD:  Coordination and Integration
          George Lehnert   ....................... G -7

     ADP Management and Organization
          Bruce Rothrock   ....................... G -8

          Questions and  Answers ................ .... G- 11

          Comments .......................... G-12

     ADP Problems From a  Manager's Perspective  ............ G-14

          Questions and  Answers .................... G-19

     Centralization
          Joel Brandon ......................... G-20

          Comments  .......................... G-25

PANEL  H:   TOXIC  SUBSTANCES

     Overview
          Ken Olsen  .......................... H -I

     The Inter- Agency Regulatory Liaison Group
          Warren Muir ......................... H -6

     Feasibility Study on Information Systems
          Morris Yaguda ........................  _ _<
     Inventory Information in the
     Chemical Abstract Service
          Frederick H.  Siff  ....................      H-ll

     The Informatics Contract
          Ernest Stalder                                                  „ ..

-------
                                                                      Page
                                                                      Number
     Confidentiality
          Denise Swink	H-16

          Questions and Answers	H-18

CONCLUDING REMARKS/PANEL SUMMARIES

          Willis Greenstreet	P5-1

GENERAL SESSION II:  PANEL SUMMARIES

     Distributive Processing Summary
          Theodore R. Harris	PS-2

     Effluent Data Systems Summary
          Jack Sweeney	PS-3

     Exchange and Standardization Summary
          Ted Standish	PS-5

     System Development Cycle Summary
          Morris Yaguda	PS-7

     Administrative Systems Summary
          Neil Haley	PS-9

     Water Supply  Summary
          Tom Martin	PS-1 0

     ADP Management Summary
          Kenneth Byram	PS-1 1

     Toxic Substances Summary
          Ken Olsen	PS-1 3

-------
                                PRODUCTION NOTES
The  proceedings of the Second Annual  ADP Conference were captured  on  tape and
transferred, by transcription,  into written form.  Due to occasional difficulty in getting
good sound quality, changing of tape reels, or other intervening factors, certain portions
of the text were deemed unintelligible and have been marked as such.

Contract limitations and poor graphic quality have limited the  number of illustrations in
this  document.  Wherever  possible, however, textual references to specific illustrations
are tied to that graphic with a "figure X' designation.

The document's pagination employs the following system:  Each individual panel session is
individually numbered,  with the panel  session's identifying letter followed by the page
number itself (for example, within Panel Session A the pages are designated A-l, A-2, A-
3, etc.; Panel Summaries are designated PS-1, PS-2, PS-3, etc.).

-------
                                   FOREWORD

The Second Annual ADP Conference was held November 29, 30 and December 1, 1977 at
the Annapolis Hilton, Annapolis,  Maryland.   The objective  of  the Conference was  to
inform conference attendees  about  the  Agency's major ADP activities, as well as other
areas of general concern.  Panels were formed consisting of key  managers who presented
talks on their activities.  Question and answer periods were held  at the end of each Panel
Session.
                                                  Luther Garrett
                                                  Conference Program Coordinator

-------
                                  AGENDA

                       2nd ANNUAL ADP CONFERENCE
                     NOVEMBER 29-30, DECEMBER 1, 1977
                           ANNAPOLIS, MARYLAND
General Session

WELCOME
     Willis E. Greenstreet, Director
          Management Information and Data Systems Division

GUEST SPEAKERS:
     Lee Johnson, President
          Computer Network Corporation (COM NET)

     David Morin
          International Data Corporation

-------
                              Distributive Processing
        Panel Member


Theodore R. Harris, Chirperson


Bruce Almich


Fred Kastner


Mickey Cline

Curtis Lackey

Joel Brandon

Dennis Schur

Steve Gorensen

Jim Hammerle


Jim Susha

Willis E. Greenstreet
              Organization


Management Information and Data Systems
Division - Hq.

Computer Service and Systems Division -
Cinicinnati

Management Information and Data Systems
Division - Research Triangle Park

Environmental Research Laboratory-Athens

Region IV - Atlanta

Region V - Chicago

Region X - Seattle

Region V - Chicago

Office of Air Quality Planning and Standards
Research Triangle Park

Municipal Construction Division - Hq.

Management Information and Data Systems
Division - Hq.

-------
                              Effluent Data Systems
        Panel Members

Jack Sweeney, Chairperson
David Lyons
Clifford Lundin
Howard Hein
Peter Pattuso
Marty Halper
     Organization
Region II - NewYork
Enforcement Division - Hq.
Region II - New York
Region II - New York
Region II - New York
Effluent Guidelines Division - Hq.
                                         vu

-------
                           Exchange and Standardization
        Panei Members


Ted Standish, Chairperson

Maureen Johnson


Gail Huguet


Catherine Tittle


James Flatten
              Organization
Region III - Philadelphia

National Computer Center - Research
Triangle Park

Delaware Valley Regional Planning
Commission

Management and Organization Division -
Hq.

Management Information and Data Systems
Division - Hq.
                                        via

-------
                            System Development Cycle
       Panel Members
             Organization
Morris Yaguda, Chairperson


Lance Wallace

Norman Cottrell


Donald W. Fitzpatrick

Stephen Heller
Management Information and Data Systems
Division - Hq.

Office of Research and Development - Hq.

Management Information and Data Systems
Division - Hq.

Arthur Young and Company

Management Information and Data Systems
Division - Hq.
                                         IX

-------
                              Administrative Systems
        Panel Members


Neil Haley, Chairperson


Systems Managers;

Alan M. Kaplan

Edward S. McLean

Michael H. Platt

Paul F. Wagner

Carlton Woodell

Charles T. Wolz


Systems Users;

Mary Blakeslee

Leo C. Cox


Albert Pines

Dennis Schur
              Organization


Management Information and Data Systems
Division - Hq.
Financial Management Division - Hq.

Contracts Management Division - Hq.

Personnel Management Division - Hq.

Grants Administration Division - Hq.

Facilities and Support Services Division - Hq.

Budget Operations Division - Hq.





Office of Air and Waste Management - Hq.

Office of Water and Hazardous Materials -
Hq.

Office of Research and Development - Hq.

Region X - Seattle

-------
                                   Water Supply
        Panel Members


Frederick T, Martin, Chairperson

Robert D. Barber

Bruce O. Keith

Donald L. Worley
              Organization
Office of Water Supply - Hq.

Region IV - Atlanta

Office of Water Supply - Hq.

Management Information and Data Systems
Division - Research Triangle Park
                                          XI

-------
                                ADP Management
       Panel Members
             Organization
Kenneth Byram, Chairperson


Joel Brandon

George Lehnert


Bruce Rothrock

Douglas W. Shape

Michael Steinacher
Management Information and Data Systems
Division - Hq.

Region V - Chicago

Office of Water and Hazardous Materials -
Hq.

Office of Enforcement - Hq.

Region IV - Atlanta

Management Information and Data Systems
Division - Research Triangle Park
                                       xu

-------
                                GENERAL SESSION I

                                                                  K
                                      Welcome


     I want  to  welcome you to the Second ADP  Conference.   I hope  we are able to
provide a forum  for you to talk to each other; that is the purpose of  the meeting.  We're
here to provide a meeting place, to give you some interesting and educational topics, but
primarily the purpose is for the user community and systems managers  to talk to each
other.  The genesis of this meeting occurred at the zero-based budget ranking for ADP
last summer, when it became perfectly obvious to me, sitting in on that session, that the
users and the managers were not talking to each other about what their plans were for the
future.   We're  available  to  assist you  but basically the success  or  failure of  this
conference, at least to my mind, is how well you talk to each other and find out what each
other's plans are.  A  lot is going on  in EPA.  I can attest to that.  I set a personal goal of
visiting all of the regional offices in a year; it took  me a year and a half and I have been
to all of them now.  It does no good for me to stand here and tell you all the things  I have
found, heard, or seen. I  think you need to discover this for yourselves.  In this vein, I hope,
during the coming year to year and a half, to be involved in a series of meetings in a
specific area such as laboratory instruments, where people can get together to talk.  I'd
like all of you to keep this in mind during the sessions.

     Our  first topic will be the ADP world-at-large, more particularly,  the commercial
sector and the vendors.   Our speaker knows more about this than any other human being
outside the Federal Government.

     Now Lee and I have had a standing joke for the last few days.   I told him that if he
did not give me a biographical sketch, I was going to tell you what I knew about him.  He
got worried and  this morning he gave me a few notes which I will share with you.  First,
though, I  would  like to  say that Lee  is a man of  great energy.  More than that, Lee
Johnson has done  something that I  have always wanted to do.  The thing that I admire
most about Lee Johnson is that one  night he had the audacity to throw a  printer that did
not work out on the street. I have always wanted to  do that, and he did.

     But seriously speaking,  Lee is one of the pioneers in the data processing industry.
He started with General Electric Corporation in a management training program in 1953;
his first task was  to evaluate Univac I. Then he joined Remington Rand, or its  successor
corporation, working there from 1956 to 1967.  He moved into the communications aspect
of computers, specializing in airline reservation systems.  He  was also involved with the
Federal Systems Division of Univac  in 1961, when they had 69 employees and $4.5 million
in business.  When he left,  they had 3100 employees and $241 million in business. He left
in 1967 and  formed two companies, COMNET (Computer Network Corporation) and one
called  COMTEN,  which makes communications front-end computers.  Over the  years,
COMNET has grown from a small company in 1971 to a corporation of 200 employees and
$16 million in revenue.  With that, I  would like to introduce Lee Johnson.
                                          GS-1

-------
                                  GUEST ADDRESS


                                    Lee Johnson

      I'd like to tell you a bit about where  COMNET has been where we are today, and
 where  we are going.   COMNET  was started  with $11,667.20.  In  1967, we had the
 important task of trying  to decide which Thursday we were  going to the courthouse  to
 declare bankruptcy.  Those were days when, in essence, commercial companies would sign
 five or six different types of contracts.  It was not necessarily their intent to use any one
 of those companies. If they used your service, it only determined how your bill would  be
 computed.  We were an industry where a 30-day contract, with good intent behind it, was
 great!

      The  industry almost did not make it through the 1970-71  crunch of the economy,
 recession, tight money market, etc.  If you had the name  "time-sharing", attached to the
 company, it was  worth between 10 and  30 points on the stock; it did not matter whether
 you had any business or were doing anything.  Wall Street would loan you great sums  of
 money. COMNET went public on November 9,  1967  at $2.25 a share for all of 200,000
 shares.  In the subsequent four years, 185 of the companies of our type  went down the
 tubes.  It was a very difficult, competitive environment in  which the industry grew up in.

      COMNET is an independent. Other independent  corporations are Computer Science
 Corporation, Boeing Computer Service, Litton, etc.  As  an independent,  our business is
 basically the  computer service industry.  The  objective  was  to find a way to improve
 software capability, computer capability, and communications capability.  The key, from
 our point of view, is the Federal Government; 76 percent  of our revenues, six months into
 our fiscal year, are U.S. Government.  Approximately seven or eight perecent are from
 quasi-government sources  such as  the U.S.  Postal Service  and  the  U.S.  Railway
 Association.

      I  think we  are  finished with the  era  of contracts  that  assured you nothing.  Our
 guarantee was $100 a  month.  On November 8, 1971, GSA  moved into  the arena  for
 computer services awarding a contract  to the Computer Science Corporation. That first
 contract has remained with that company and accounts for $30 to $35 million in annual
 revenues  from  the  Government.    There were,  however,   exclusions.   There  were
 restrictions on the  type  of services they  could  provide.  These  restrictions  allowed
 companies,  such as ours,  to carve out a remaining niche  in the Federal Government.  In
 1972-73, the initial contract had to be re-competed.  The people at  GSA were  basically
 going out to re-compete that same contract. The longest contracts that COMNET has had
 in the Government are of two types.  The first type, like our EPA contract, is a multi-year
 facilities contract. The other type of contract is with the Department of Transportation
 (DOT).  They  basically re-compete the  contract every two years.  They  do not pick a
 single company, but pick approximately  eight or ten from the  industry which furnish both
 IBM and non-IBM services. Our company has had a contract with DOT for almost seven
 years now.  The theory behind this was  that GSA would go out and re-compete that CSC
 contract on a single-company  basis.  We started  to  work with GSA, along  with  other
 companies.  We concentrated  on GSA to pick a national company, a  regional company, a
 multi-regional company, and a local company;  the differences among these companies
 would represent the communication capability. If you did not have hard-wired lines across
 the country, you were not  a nationwide company. There was a  little company called Tym-
Share, which is, I think, the largest independent in this business that had a communication
network service they put up with mini-computers; they were getting  ready  to tariff that

                                          GS-2

-------
service.  We managed to get a standard contract with two minor changes. One was that
we can not disclose that we are a user; second, we can not indicate by our traffic analysis
where our  customers are.  We signed that document. It never occured to this company
that a competitor would sign the contract for which they put the network up initially for
themselves and subsequently had gone out to sell that service.  They sold it to about 19
Fortune 500-type companies.  I guess there was considerable gnashing of the teeth.  But
they had one basic decision to make: would they get out of business with those 19 other
companies,  or accept  this one with COMNET?   Well, they  made  the right  decision.
COMNET became a national company under the system we are trying to sell to GSA.  We
had  a communication  network, and were  one  node larger  than Tym-Share.   We kept
pushing the concept of the multi-vendor approach to GSA.  In that system, there would be
at least 15  or 20 companies offering IBM service.  At least two or more offering UNIVAC
service, CSC and University Computing; two or more companies offering CDC equipment.
There would be  many companies  offering DEC 10; Compu-Serve,  On-Line Systems and
First Data  in Boston.  In essence, there would be competition within the product lines of
manufacturers.  In addition,  one company could hardly  service the entire needs  of the
Federal Government. Over a period of  about a year and a half, GSA accepted this idea.
GSA's acceptance of the multi-vendor concept came on Friday, April 18, 1975, as I  recall.
We had  an  all-day conference with about 100 people at GSA to discuss a draft of some 400
pages which represented GSA's request for the industry's opinion  about teleprocessing.
COMNET wanted that first contract, and, in fact on November 11, 1976, COMNET was
awarded the first contract for GSA teleprocessing services.  We were unhappy with the
situation, however, because GSA did not make it  mandatory. It was  made mandatory on
August 1, 1977.  At the time of the initial announcement by GSA, the government segment
of the market was reported  by GSA to be between  $60 and $80 million annually. That
amount is projected to grow in the  1980's to between $300 to $400 million.  Now there
were, and still are, exemptions to that basic program. Facilities management, where you
provide an entire system or service are exempt from the GSA-TSP; batch services are also
exempt  from that program.  The multi-vendor  philosophy,  however, will   turn the
Government business into a substantially greater amount of annual revenues than have
been predicted by some of the people at GSA.  But I would  like now to talk about some
changing elements.  To  my knowledge,  the EPA contract  is  the largest Government
contract for services of this type in the country. The GSA-TSP has basic segments, one of
which is called   the BA,  the Basic Agreement,  and the other is the multiple  award
schedule.  We received a $5  1/2 million  contract from GSA, under the BA section, to
provide  the Federal Trade Commission, for the next 60 months, with  their entire data
processing for that agency. In this case, it is dedicated resources, not a dedicated system.
We find that the Government and the industry is  maturing considerably. In the past, there
have been a lot of protests by losing vendors; we have done it a couple of times to check
out the system to see if it worked or to check out the new Freedom  of Information  Act.  I
find that that works two ways, if you win the contract it  works very well; the Government
agency  works with you to protect your private  information.  If  you lose  a contract,
however, the Government works very well with your competitors to provide information.
This has been the subject of several court cases.  The courts  have ruled both for and
against private industry. There is no particular trend  that has been established.


     I think the government is trying to clean up the procurement process, and I think our
industry is trying to clean up its act, too.  We do not really want to  protest just for kicks.
We want to protest when we honestly feel it has not been a fair procurement. I think that
you will  find that most of the protests are by  incumbents who attempt to prolong  the
amount of revenue by tying up the government.  We do talk in the industry about trying to

                                          GS-3

-------
 eliminate this  protest  process because it takes a year to be solve.   GSA,  or  GAO,
 generally comes  back  and says, "You have a valid protest, and we think  that you were
 troubled in certain areas.  However, because of the large amount of costs involved in
 cancelling for the inconvenience of the Government, we are  going to let  the incumbent
 continue."

      In the future, I think the Government will  move into more cost-plus  contracts.  I
 believe the fees will be  close to  10-12 percent.  There will be  more of  this type of
 contract, and there will be more contracts which require dedicated resources. This is the
 reason why the BA portion of the GSA schedule was established, in  order to negotiate the
 requirements  for what is needed  for  the  services,  other than  the standard price list.
 Basically, we have two different types of computers, DEC  computers and IBM computers,
 but we have  eight computer systems.   We have not been dealing with peripheral
 equipment; we are moving more into an era of  non-compatible or compatible  IBM, but
 non-IBM main-frames.

      I am sure that your are familiar with  the AMDAHL system, a very powerful system,
 quite compatible to IBM and the ITEL system.  COMNET has a 158-Mod Three and sitting
 alongside is a 158-Mod Three equivalent.  It is built by  ITEL, and is about  two to three
 percent faster in throughput.  And this is something we will see more and  more.  Several
 of the service companies have already shifted and are using non-IBM main-frames.  But I
 think as we move into the late part of the 1970's and early part of the 1980's,  we  are going
 to find that the industry  will  change the entire spectrum of services.  We will  get away
 from what I call  facilities management or dedicated resources, and go into total systems,
 where we provide a service. That service contract for example, (our Navy contract is 36
 months long)  is  a far cry from  30-day contract for  a $100-a-amonth guarantee with
 contracts  signed  by  six  other  companies.   Our EPA  contract  began as  a 48-month
 agreement, and by the 1980's  should stretch out a bit.   Our HEW contract is 42 months,
 and our Federal  Trade  Commission  contract is 60 months.  We are talking about a
 capability and a service  that is totally different from what we have today,  and one that
 will go out ten years.  We will be spanning the technology in communications, software,
 peripheral equipment,  mainframes, etc. and  they  will have to provide  contractual
 solutions.   We are  headed for long-term contract capability that  provides a  broad
 spectrum of services.

      I do not think the industry will change any more  in the coming five to seven years
 than in the last five to seven years; at the same time, the number of companies will shake
 out considerably.  Previously, I indicated that there are now some 32 companies  that have
 signed contracts  with GSA; that is a fictitious number,  if you look at it more  seriously.
 Not more than  five  to  seven  companies  are seriously  involved in  competing for
 Government contracts.  One of those companies has six employers and a PDT 11/70.  The
 company President developed  the software  and works on the  software part-time.  We go
 all the way from  small companies of that type to very large  companies.  In the case of
 our  organization,  however, we compete with about five to  seven different companies.
 There are exceptions, of course, but these are rare.  All of a sudden some new company
 will show up,  but in the  last  5  years, you  can guess on any procurement  who your
 competitors will be.  Looking at the RFP, you will say that Boeing  will bid, AMS will bid,
 PRC will bid,  and so on down  the line.  This is changing. We are currently  involved in a
 procurement with a Government agency that is scheduled to be awarded by Christmas.  It
is  a three-year contract, but the companies are  not the traditional ones.  We have
companies like Rapid Data in New Jersey, Federal CSS in Stamford, Connecticut, Martin
Marietta in Orlando, Florida, etc.  Basically we have always  been  involved  in competing


                                           GS-4

-------
with companies that are IBM. But we have CDC equipment and have CSC involved with
Univac equipment.  We also have IBM compatible equipment.  I think we will come into a
new era where you will find five to seven companies competing, but these will be different
types of companies. Then we will move into an era where the Government says, "We want
solutions. Do not tell us about hardware.  Do not tell us about software.  This is what we
consider  as our data services requirement.  We want you to respond to an RFP. We want
solutions. Do not tell us about feeds and speeds and hardware capacities."

      Basically, that is where we are going in the service industry. By 1982,  1983, or 1984
we estimate no more than 10  suvivors  as  independents.   Certainly, General Electric,
McDonnell Automation, Boeing (they are not considered independents) will  be survivors.
Of the independents, there will certainly be not more than 10.

      I think that the EPA-type contract has been questioned more than anything else by
the people with whom we now do business.  Let me give you a couple of  examples.  HEW
paraphrased your Privacy Act requirements, word for word, paragraph by paragraph. You
will find that many agencies are simply trying to move toward the cost-plus contract,
toward the language you have in your contract in order to emulate your process. I don't
say this because COMNET is  the winner.  I am one of the guys who has been around town
since 1953 and did not really know the purpose of the blue-ribbon panel until after it was
over. I think the integrity  of the process was given a big lift.  No one likes  to work on a
project where you know who the winners are, or you suspect you know  who the  winners
are.  In  the  case of EPA,  we,  in the industry, felt  that  the  procurement  was  totally
honest.

      A  typical procurement,  if you really  go out  to  win,  takes  about a $100,000
investment.  Our company put in excess of $1 million into EPA procurement.  We put that
money in the procurement  because it was a  very tightly controlled procurement of which
we would like to see  more.  Many agencies  have asked us how  EPA kept the process so
tight.  We have explained  all that we know about it,  and we find them emulating that
process.

      There  is  one  other  element  coming into fruition  in  the  government;  namely,
algorithms.  I was on a panel in New Orleans about a month ago, and a company for which
I used to work  said that  they had an algorithm consisting of 43 pages.  It was so complex
that it was not important to pass out, or explain to the Government or the potential users,
because  no one individual knew it.  It was broken down into six different categories with
an individual heading up each of the categories.  I was sitting next to a young lady who had
Category III. She had 13 pages in which she specialized.  This brings up, I think, serious
problems and we have been  addressing them in  the Government. It's almost like trying to
determine a price by throwing a dart at a dart board.  We sometimes have a diffucult time
coming up with a price and  interpretation of an algorithm.   We have  been advocating
another element of pricing  which has been adopted on two occasions. We think it removes
the subjectivity in pricing.  The new approach has been, go to the vendor, talk to him.  We
say, "This is how we  have  intrepreted your price; we have filled out the schedules, etc.
We want your confirmation that our number is your number." Then we get a  letter saying,
"Yes, you have correctly interpreted my algorithm," or "no you did not,  here  are  the
changes." Then re-run your model and come up with a number.  I think that  this approach
will be used more and more in the Government because it will at least give the industry
and the Government the confidence that they agree on each other's numbers.  Thank  you.
                                          GS-5

-------
                            INTRODUCTORY COMMENTS


                                  Willis Greenstreet

      Our next speaker is David Morin, who is the manager of The Information Systems
 Planning Service,  International  Data  Corporation (IDC).   IDC  primarily  does  market
 research for the  industry itself, and also publishes Computerworld. Mr. Morin has been in
 the business about 18 years and  has a great deal of data processing  experience.  Before
 IDC, he was employed by the world's largest manufacturer of costume jewelry.  The most
 interesting  part of his bio is, however, the fact that he is in daily contact with the user
 community who are IDC clients.  With that I give you David Morin.

                                  GUEST ADDRESS

                      David Morin, International Data Corporation

      Thank you.   I thank you for the opportunity to spread the word about distributed
 processing.   I also hope that you  will not accost me as I leave the room because some of
 the opinions that I will present will probably be a  little bit different than what you have
 envisioned as distributed processing.

      Let me just briefly describe IDC. Basically, it is a 13-year-old firm who primarily
 provides services to the vendor community. The company began by establishing data files
 of just about all  the computer installations in the country, along with what hardware was
 contained in those  installations, what size core was used, who  the key people were, what
 peripherals were used, etc.  From  that data base,  we are able to conduct many surveys,
 often with  the Computerworld name associated with the surveys.  Initially, we gathered
 information for the vendors, then recently we found that the same information is of value
 to the users who  want to know what other users are doing in the same areas. In the past,
 we have given the topic of distributed processing a great deal of attention. In fact, we
 have sponsored two four-day conferences on the  topic.  Obviously,  I am going to have
 some difficulty condensing four  days of  material  into a one-hour presentation.  I might
 also  add,  that Fortune  magazine asked IDC  to  write a special  article  dealing with
 distributed  processing, for their March issue. The article was so popular that reprints are
 no longer available.  If you can get to a library, and look at the  March issue of Fortune
 magazine,   there  is additional material on  distributed  processing that  you might find
 interesting.  I might also add that the November issue of Fortune carries a special report
 on information networks  in  the office of tomorrow.   It  is not  exactly distributed
 processing,  but it is a very fascinating article.

      Well,  let me  get right into distributed processing.  What is  distributive processing?
 Basically, it is buzz words. There are many, many buzz words. The computer industry is
 the  greatest generator of buzz words.   Unfortunately, buzz  words cannot  really  be
 defined. The problem with a buzz word is that, for example, the vendors go to a user and
 say, "What are you doing?  What are your  plans for the next three or four years." The user
 will say, "Well I am going to  install distributed processing."   The vendor then sits down
 with the user and talks a little about what distributed processing is,  and what the user is
 going to do  with it. The user explains the plans clearly and concisely and then  goes away
 to talk  to the next user.  That next user tells him that he is going to install  distribued
processing in the next year or two.  He goes on, to  describe how he is going  to use it, and
the vendor gets an  entirely different story. In fact, he goes away shaking his head, saying
                                          GS-6

-------
one of those users does not know what he is talking about. Computerworld spends a lot of
time writing about what distributed processing is all about. In fact, IDC publishes a entire
newsletter on the subject. All in all, buzz words cause a lot of confusion. As I mentioned,
the users are planning to get involved in  distributed processing, and they may have  an
entirely different idea of what it is, than the vendor envisions.  That is unfortunate for the
vendor because he is  running back to his  shop trying to design a piece of hardware  or
software to serve the needs of distributed processing applications, and he is going around
in circles.  IDC was asked to define distributed processing; and basically broke it down
into four basic definitions.  First is distributed load processing; second, distributed data
entry; third, distributed  data-based processing; and the fourth is  distributed dedicated
processing.

      Distributed processing by itself is very difficult to define, but these terms, we feel,
can be defined. Load balancing is a situation where you have a computer network.  Today
you feed a job into any port in the  network. The software or scheduler decides that the
job should be run on a computer located in Florida. Tomorrow, because of scheduling, or a
different set of criteria,  the same job might be run in your own installation; the following
day it might be run in Chicago.  You never really know exactly where the job is going to
be run.

      The second definition deals with  what we call distributed intelligent data entry.
This  is where  we provide enough  intelligence  at  each remote  location  to 'provide
essentially error-free data entry.  This includes involved table look-ups, a series of codes,
additional information, skeleton  master  file information and allows us to determine that
the data coming in is valid. It is corrected at the point of entry.

      The third type  of distributed processing is what we  call distributed   data-base
processing.  This is where the data base is actually split up.  A good example of this  might
be Sears and Roebuck stores.  They  are  located all over the country  but the average
customer goes into the same store 99 percent of the time.  Once or twice in the course of
a year, he  might be  traveling and might  go into a different store.  In that case, the
network allows the information from the primary store to be transferred  over the wire on
that one-exception type of situation.  Basically, however, all of the processing necessary
for that customer can  be done in one store or at one location.

      The fourth type  of distributed processing is similar to the first,  except  that in this
case we may have different types of computers attached in the same network. Some of
them are  large number crunchers,  scientific  types of  computers; others  have  other
features allowing for business applications.  Here the job is fed at any  one of  the remote
locations and is funneled to whichever computer is capable of handling that particular job.
In this situation, the same job will most  probably be handled on the same computer every
time unless there is a duplication of computer systems throughout the network.

      Out of  the four types of distributed processing  we have identified, there is one area
which we feel  is most  likely to be  expanding, and that is the  distributed data-base
processing.   This is  the  situation  in which you have your  data  base split  into many
different regional locations where the processing is performed the majority of the time.
Thus,  you  have  a network  of processing  nodes  which are  either functionally  or
geographically distributed, but all inter-connected via some communication link or  media
transfer arrangement.  Now the data, as I mentioned, is spread among the nodes, and there
is minimal redundancy.   The user at any node has access to the information stored at
another node.  This is the Sears  Roebuck example where someone travels to  Florida and
                                          GS-7

-------
 wants to  buy something, and  they  need to  do a credit check.  The regional center
 processing the Florida application can access the information in Boston and transfer it
 over the wire in this one-exception situation. One of the key advantages to this approach
 is that you eliminate the majority of the communciation costs  where the expenses  are
 rather high.  If you have all this information at the location where roughly 80 percent of
 the processing is  done,  that  information  never has to  travel over  the wire.   Thus,
 communication costs are  reduced. You still retain the ability to send the information over
 the wire, if necessary.  The next element of this type of processing is a central control of
 the system, and the development or acquisition of components.  The key point to  make
 here is coordination. It is necessary to have this central coordination.  Some of the users
 with whom  we  have talked  have had varying degrees of central control.   Generally,
 however, there has to be some sort of central control, otherwise payroll applications will
 be redeveloped at each of the nodes and will not be compatible with one another.  You will
 have equipment  acquired at each of the nodes that may or may not be compatible with
 other equipment in the total network.  It is more feasible to have central control to assure
 that all  these pieces fit together.

      We have found that there are two  general  types of network configurations within
 distributed installations.  The first is  what we call the ring network.  From  a hardware
 standpoint, you have your computers located around the ring. You may have one computer
 attached to the ring that is a little larger  than some  of  the others for  specialized
 processing.  It may house specialized software  that may be  needed occasionally,  but
 basically you have spearate and distinct  processing nodes located at several  areas with
 access to all.  The second configuration is what we call the star network.  Here, you have
 a large,  central host computer performing the same functions as the large computer  listed
 in  the  ring nework,  but all  communication has to go  out through  the central host
 computer.  The satellite processes are disc mini-computers of one type of another.  They
 can do a great deal of processing on their own without very much interface with the host
 computer.

      There  is another viewpoint to  mention here.  Management concepts  are forever
 going through cycles; one of the cyles is to question whether to centralize or decentralize.
 Those that  have  their  data  processing totally centralized  may find  many of  the
 disadvantages that exist in that kind of arrangement. They may  start drifting away from
 the  centralized approach and gradually convert to the decentralized approach.  The grass
 always seems greener on the other side of the fence.  In any case, we are finding that  not
 only does management go through centralized and decentralized cyles, but the distributed
 data processing environment does as well.

      To go through the evolution of  data processing within the  industry for the last few
 years, I will start with the second generation of equipment in  the early 1960's. The trend
 was toward a decentralized type of environment with stand-alone non-compatible systems,
 located in major operating units of a  company.  During the third generation in the late
 1960's, some locations started upgrading, and there was a move toward centralization. In
 the  early  1970's, we had a major effort to  centralize  the  processing in  these  large
 computer  systems.   The remote  computers  were replaced by  telecommunications or
 remote job entry  terminals which interfaced with the  large  installations  at central
 locations.

      Now, we are getting into the beginnings of  distributed processing. We have gone
 through  the centralized approach; now, we are starting to get  back  into the  cycle of
decentralization.  A good example of the systems being decentralized  are transaction-
driven applications. These are  applications (for example the  airline industry) where data

                                           GS-8

-------
is taken at separate locations, and the whole operation is dependent on these transaction-
driven systems.  If you have ever gone up to an airline reservations counter and been told
that their computer is down, you are very aware of the chaos which occurs.  Many of the
companies having these large central systems are starting to find out how dependent  they
are on the system, and how their company cannot function if anything happens to that one
central  system.   The trend, therefore,  is going  towards the decentralized approach,
although you  still have a problem  because your node can go down.  In this  situation,
however, at least the whole company isn't out of business as a result of it.

      To carry this one step further, into  the 1980's, we see the broader use of distributed
processing elements, a  redistribution  of the  previously  centralized  applications.   To
speculate further, we  see  computer  networks where one  organization  will  probably
interface with another organization, possibly a supplier with a customer, a customer  with
his vendors, etc. Now, the advantages and disadvantages of centralization are just about
the opposite  of the  advantages and  disadvantages  of decentralization.   Briefly,  with
centralization, you have the economy of scale and processing; you have bigger and bigger
CPU's that process more efficiently and for less cost.  You have lower total manpower on
certain tasks, and you  have vastly  better negotiating power as  far as central buying is
concerned.  You also have  concentrations of vendor selection expertise, and  you can
encourage uniformity and standardization within the centralized approach.  Among the
disadvantages are that, sometimes a relatively simple task takes three days of debate and
three months  of paperwork and  red tape.  Because of the large size  of some installations,
they almost become non-responsive to the users' needs. With decentralization, you have a
high  degree of  local flexibility and maximum responsiveness to your users' problems.
Some of  the  disadvantages are  the  reinvention of  basics,  similar  personnel  at each
decentralized site rather than one person specializing in that task or function at a central
site.  However, no matter whether you are in  a centralized or  decentralized approach,
there will be advantages or disadvantages.  What we are working towards is balancing the
advantages and disadvantages of both.  We have been  both decentralized and centralized;
now we are starting to balance our approach.

      When  we get  into  distributed processing, we  are  going to need a  lot of  vendor
support. Mini-computers are a large part  of distributed processing.  We are going to need
new types of  peripherals, primarily  disc systems, to attach to these minis.  There will be
different types of disks,  namely, cartridges, floppies, and  new disks that are not yet on
the market.  Work stations, CRT's, and input units are other types of equipment that will
become a part of this new distributed approach.  There will be a need for other peripherals
instead of the large, high-speed printers.  We are going to need a lot of  smaller printers
attached to the minis in order to be economical for  the volumes produced on the minis,
but these will be different types of printers, then we are currently familiar with.

      Software is another major area that needs to be addressed.  The software for this
new distributed concept is different in  the area of communication.  You need specialized
software  for  the  host  computer as well as  the network  nodes, and new types  01 file
management software, and data-base management systems.  The languages are also going
to play  a key  part.  The mini-computers,  for the most part, do not have extensive COBOL
usage; vendors will have to supply other,  more usable  languages.  Each of the vendors has
the capabilities of providing these services, and they are currently working on them. They
are,  however, running  around in circles to some extent, because  there is no generally
accepted standard throughout the industry as to what exactly distributed processing is. A
lot of people are concerned. They are hearing about  distributed processing, and want to
                                          GS-9

-------
 know what it is all about.  They feel that-if they are not involved with it, they will be left
 behind.  Frankly, distributed processing has to be a perfect fit or its not woth considering.
 You need to know all the features that are key parts of distributed processing.

      IBM is a key  factor  in anything that happens  in the computer industry.  It is
 worthwhile to mention briefly what IBM's strategy is, or what their feelings are about
 distributed processing.   Are they  for or against it?   Well, basically they are for it.
 Distributed processing means more computer power; there will be new application and new
 transaction processing. IBM does not want to pass up any  sizable business areas. IBM does
 see the processing nodes,  the mini-computers as being a threat to them to  some extent.
 There is a lot of  revenue  out there being spent on mini-computers, and they are not IBM
 mini-computers for the most part.  IBM is  somewhat late in the development of mini-
 computers and mini-computer  software.   In fact, the  Series One announcement  was
 somewhat of a defensive move on the part of IBM to save  sales that were going to smaller,
 mini-computer  companies.  Within IBM, there  are struggles to determine  to whom  the
 responsibility for  distributed processing belongs.  Most of you have probably been dealing
 with representatives from the Data Processing  Division in your large central sites.  You
 will find, as you get  more into distributed processing, that you  will have to start dealing
 with the General Systems Division of  IBM if you  are going  to be obtaining the  smaller
 machines.

      It is difficult to  say at this time which division will provide the major thrust into
 distributed processing, but you can believe that IBM is going to get their act together soon
 and start pushing distributed processing.

      Now, I would like to talk about some of the environmental needs of the distributed
 system. The leasing, for example, of mini-computers is a new concept. Most of the mini-
 computers in the past were sold for $25,000  to $50,000, or maybe a little more depending
 on your  definition of  a mini-computer.  Generally, they've been  sold outright. Now if  you
 are putting together a  large distributed processing network, and  you are going to have  a
 dozen mini-computers or  more  distributed around the  country, you are talking  about  a
 large total expenditure, and you need to think about leasing or other methods of obtaining
 this equipment.

      Maintenance at varied remote sites is another problem. One of the companies with
 whom we  have dealt most heavily in  our investigation  of distributed processing was  a
 railroad.  Railroad yards were scattered all  over the country.  The yards were dusty  and
 had extreme temperatures.  Some of the yards were quite remote; as a result, the mini-
 computer  companies had  to  service capabilities at   these  remote  locations.   And
 furthermore, there is the requirement of training personnel.

      Now, another topic that has been mentioned is the  capability of interconnecting all
 of this non-IBM equipment to central CPU.

      These are a few of the things that have to  be considered when you go  to distributed
 processing. I mentioned earlier, a high-level language, like COBOL is not readily available
 on  the mini-computers, if you start implementing a  distributed system  now, you must
 consider what languages people have to  be trained in.

      Now I  will  talk  a  little about  what  we have discovered  about the actual
implementation  of some  of the  systems.   These are just  beginning to emerge as
operational distributed processing systems.  It represents a significant departure from the


                                          GS-10

-------
typical data processing techniques with which we are all familiar.  We have likened the
distributed processing concept to the industrial revolution of the past.  There the focus
was on mass production;  the key was transportation, and the result was greater product
availability.  With distributed processing, the focus is on information handling.  The key is
communcation; the result is  greater information available to various managerial levels,
although it is only in its embryonic stages.

      Distributed processing is an evolutionary outgrowth of telecommunications applica-
tions.  Within the airlines, for example, they went from reservations to seat assignments
and fleet management. Within retail, they went from credit authorization to point of sale
and merchandise  control.  In manufacturing,  they  started  with order entry,  went  to
warehousing control  operations, and then finally  ended up  with  plant  and  material
requirements  planning.  Thus, it is  a phased  approach that grows out  of the  recently
acquired teleprocessing expertise.

      Now I would  like  to  give you a little more  information on  how I obtained my
information.  Basically, there were 30 user  and  12  vendors interviews.   Our research
library contains just  about every article that was ever written on distributed processing,
and we have zeroed in on it, primarily because it is such a hot issue.  I also mentioned
earlier  our publications,  such as the EDP Industry Report, the Distributed  Processing
Newsletter, and   Auto Transaction Report.  In order  to  report effectively the news we
have  had to address this  topic in-depth.  It is well in excess of 30 users that have  been
interviewed  at this point.  Those  30 users  were people who claimed  that they had a
distributed  processing system up and running or very  close to  running.  Our  biggest
discovery is that the users are very, very slow to jump to new concepts. There has to be a
significant, clear reason  to go with distributive processing.   Today's users,  who are
considering distributive  processing,  are  pioneers.    They  have  to  do  a lot  of  work
themselves.  They must have an in-depth  knowledge of what mini-computers can do and
how they do it.   Generally, they are large organizations with lots of money because it
takes a lot of money to get a distributed processing system up and running.  It requires a
very significant commitment in  dollars and time. There  is  a level of risk involved. The
whole system could be conceived and developed, and end up  costing more and performing
worse than your present concept. Thus, there are warnings to be considered. The pay off
must  be clear. It has to be very obvious that there will be a big payoff in this application
because  there are a number of pitfalls along the way. If there is not a clear economical
advantage our warning is:  "Don't proceed with D.D.P. just for the sake of being one of the
leaders in this area."

      Today, there are pockets of experimentation in distributed  processing.   Not  many
organizations have a true distributed processing system that is operational.  There  are a
few pioneers who are making attempts. They are benefitting and spreading the word. It
has taken these  pioneers the better part of  10 years  to  get  their systems  planned,
designed, and implemented.   The pioneers are  generally those  in naturally  distributed
industries; namely retail, transportation,  some  manufacturing, the  computer  servicing
industry, etc. The insurance industry has been through a program of centralization.  Now,
they find themselves at the point of starting to decentralize.

      Quite often, distributive processing requires a major expansion of existing computer
facilities.   That  consideration is part of the  justification of  going to a distributive
processing system.  If you have to expand your  computer facility, you  have to buy new
equipment in order to handle new applications.  This is a good time to consider the cost
advantages of the distributive processing approach.


                                           GS-11

-------
      Lastly,  but  most importantly, is what we call the 80-20 Rule.  This is a situation
 where 80 percent of the processing is done at the distributed site, the remote site.  Only
 20 percent of the processing involves interaction with the central computer.  Some of the
 largest savings involved  with  distributed processing is the elimination or avoidance of
 communcation costs.  Communication costs seem to be  rising steadily, and the distributive
 approach  takes  advantage of  that  by  avoiding  the need to  transmit  data   over
 communcations lines from  one computer to another. Some appropriate applications have
 occured within transportation,  in the retail industry, banking and manufacturing. The key
 is that there must be very little interaction with the central site.  Other ingredients are
 new  operational  application  requirements, generally  not  traditional  applications  (like
 payrolls, general ledgers, or accounts receivable), expansion of your computer facility, and
 the 80-20  rule.  Then  too a pioneering individual is required, someone willing to fight the
 non-IBM arguments, someone who knows enough about mini-computers to go with the non-
 IBM  vendors  who buck the general  trend to  stick strictly with IBM.  Furthermore,  a
 significant commitment is  required.  Development costs are very high. For example, we
 found the railroad had budgeted $45 million to their distributed processing system. A bank
 to whom we  talked had budgeted $30 million to the development and  implementation of
 their  distributed  processing  system.    There  is  a long  time-frame,  usually a phased
 approach,   a  great deal of organizational involvement, and a significant  amount of
 interaction between managerial personnel at the remote and at the central site. There is
 also  a lot  of coordination necessary  to  make all  pieces  fit together.  Many of  these
 commitments will be reduced as more experience is gathered, but, at present it is still a
 formidable task.   In  the future,  we hope that the right hadware  and software will be
 available, and that it will be a  much easier task to complete.

      Elements involved  in the implementation are, first, a  study  phase which for the
 pioneers have covered a  three-to five-year period.  The selection and evaluation phases
 take another year or more.  Here it involves optimizing the price, size,  and breadth of the
 products that will be required.  Pilot implementation takes at least  six months, and total
 system development,  two to three years.  Testing can take up to a year, and training and
 installation can extend up to three years.

      Why does it take so long? First there is the internal political environment, including
 the non-IBM  approach.  Then there  are software shortcomings,  one  of  which is  its
 availability.  In terms of personnel, there are  not many people who are knowledgeable in
 both  mini-computers  and  larger business computers.   There are definite geographic
 shortages  of  mini-computer  experts.   You are also  talking about implementing  these
 systems at remote sites.  In Washington, there may be  an abundant  supply of  mini-
 computer talent, but in that railroad yard in some godforsaken place you may have a little
 more diffuculty finding computer specialists.  Lastly, there is a  definite  need for an
 understanding of the overall operational aspects of distributed processing applications.

      Now,  I'll just touch briefly on  some other areas of concern.  First,  the vendor
 hardware is different than what you have probably been dealing with in the past.   The
 financing of that  equipment, whether you rent it, lease it, or purchase it, also has to be
 addressed.   The D-P personnel costs of operations are different.  In the past, you might
 have had an operator who ran a console or mounted tapes. You are talking about someone
 who is going to run a mini-computer at some remote location; he will be the D-P manager,
 the operator, the  programmer, the punch operator, and everything else, in  one.  He is,
 most likely, a different kind of individual than you have had at your  facilities with the
 larger,  centralized  approach.   Then there is  inter-organizationl management time and
 overhead.   There's a lot  of travel  involved,  a lot of calling back and forth, a lot of
interaction  required in order to make all these pieces fit together.  Probably, you will


                                          GS-12

-------
need some outside consulting assistance,  both  in the software and the communications
area.   You  also  have to consider the impact  of  new  distributed applications on your
current existing applications.   These  distributed systems  are not  going to  run  by
themselves, without interfaces with existing applications.  The more existing applications
that you  have  the  more interfaces  you  will have  to  plan.   Salaries  are another
consideration.  That guy or gal who is the sole data-processing department probably has a
different salary structure than those people you had in the traditional environment. You
may also have to consider some of your  own service people in remote locations.  For
example, you obtain  a piece of equipment at a remote  site but the vendor just does not
supply service.  Some  companies have  actually trained  their  own  service  people  to
maintain equipment instead of having the vendor do it.

     Next,  I will touch  on two or three case studies.  The railroad, as I mentioned, was
the prime example of distributed processing. Their application was for yard operations.
They  had 90 railroad yards;  20 of them were to be automated fully.  Their application
involved assembling and disassembing railroad trains.  A  block of trains would come in
from another yard, and  it  would be necessary to break the train up and send the various
cars in the  right direction  to  build new trains.   They  were also  involved  with rate
calculations.   The  programs that  calculate the rate  structure for railroads are just
phenomenal. The amount of time that the car is on  a particular track, how long it sits at
a siding, how many miles  of  track it traveled, the  nature of the cargo, and hundreds of
other factors all affect  it.  Much of this information can be  calculated at these  remote
yards and does not require more than minimal  information from the central site. Their
alternative  to automating  these jobs  would require the  expansion of  their  computer
facilities.  They had to be on line 24 hours a day, because the railroad operated around the
clock.   They met the 80-20 Rule, because 80 percent of the  processing was done at the
yards.   In this case, they did have what we call a pioneering director of MIS.  He had to
fight the non-IBM equipment battle with management. But he also understood what minis
could do and how to make them function for him.

     The host system that he had was an IBM 370/168 with three mega-bites, with the
second 168 primarily for back-up. He had to get car history information from the central
data base, but that information was passed along from node  to node.  Then he  had to do
the car block assignments.  He  put in distributed processing at 20  of the 90 yards, using
Deck PDP-1145's.   He  used it for these block-to-track assignments.   The  data-base
information included tonnage, flags for dangerous cargoes, etc. The  work was  scheduled
over three shifts, and he had to keep track of industry zones through which the car moved.
Some of the other network elements included inquiry  points which consisted of 3270's to
access the car history.  Some of the freight stations had INCO-TERM terminals.  Data was
entered on these terminals for centralized  rate calculations. These were in the yards that
were  not  fully automated.  Incremental cost trade-offs  for the centralized alternative
were negligible as far as equipment was concerned, but as far as communications were
concerned, this application would have been four times more costly on a central, rather
than a  distributed approach.   His  total  one-time cost  for  distributed  processing ran
$415,000 whereas the tele-processing approach was at $1 million. On a monthly basis, the
distributed  processing  approach ran  $83,000 versus $150,000  for  the tele-processing
approach.  He used the 80-20 rule for his primarily communications cost to justify the
entire   application.    Computer-room  expansion  was  going  to  be  required;  system
survivability was also a  key factor.  If a central site  went down, the entire railroad was
out of operation, whereas if just one node  went down, he was in a much better position to
continue to operate the remainder of the railroad.
                                          GS-13

-------
      The system survivability problems that we mentioned earlier were the maintenance
 availability  at  remote  locations;  unfavorable physical environment  for  computers-
 temperature, dust, and humidity.  The power requirements were not always adequate, and
 administrative control was a problem.  A lot of that control had to be handled centrally.
 At some of the remote sites, he had no console operator; and they had to do a lot of their
 diagnostics via communications lines from these remote mini-computers.  They also had to
 write a lot of the software in the Basic language.

      At this railroad, they committed $45 million, and have spent $35 million to date.  As
 I mentioned earlier,  they were implementing this program in a phased approach, so that
 there are still segments that  will eat up that additional $10 million in the next two years.
 With them, it was a 13-year time frame from study to the end.  Approximately 260 people
 had to  go out and train 6,000 others in a  60-day period.  Now, the future extensions that
 will eat up the additional $10 million by 1979 are the complete automation of empty car
 assignments and total car scheduling from dock to dock.

      Another example is a paper manufacturing company that we observed doing a pretty
 good job as far as distributed processing is concerned. Here,  30 out of 65 of their plants
 were to be  automated,  using Four-phase  computers,   System 3's.   Their centralized
 applications were primarily financial; decentralized applications involved marketing and
 production.   In this company, the key  factor in  the  justification of  the  distributed
 approach was  management's philosophy that if you give a guy his own computer, he  will
 run it and manage it more efficiently and use it more effectively than he will if he has to
 use one at a central  location.  That was their philosophy.  Their distributed data base, in
 this case, involved payroll.   The gross pay  was  calculated locally, but  Federal  reporting
 requirements were handled at the central  facility.  Incidentally, they kept their  summary
 files locally in this application update, or summary, transactions were fed to the central
 site for  statistical purposes  and other reasons.  Their justification  was primarily the
 management philosophy that each location  would  make  more effective use of their  own
 equipment and make better decisions based on use.  The majority of their communications
 were handled overnight, using voice-grade WATS lines. Very little of their communication
 was necessary during the day.  Also, they were required to expand their existing facility if
 they were to consider  the  new applications; that  was  another  factor in  making them
 decide  to go  with the  distributed  approach.  Because  this company's application  was
 relatively simple it was a comparably shorter implementation period.  The study took four
 years,  the vendor selection  three  months,  the implementation three  months, and the
 installation two  years.   In this particular  company they did not keep accurate records of
 the costs strictly related to distributed processing; I cannot tell you  exactly what it cost
 them to put in their system.

      My last  example is an  automotive assembly  division.   Here  they were  primarily
 interested in controlling their material requirements planning.  Their justification  was
 accuracy and the communications costs. They felt that it was a negligible increase in  cost
 by using the distributed processing system. In fact, a cost analysis showed that they saved
 $250,000 a year over  the central approach, particularly on communications costs.

      In summary, the  underlying  threads  to  a distributed  processing  system involve
 transaction-oriented applications, not the conventional batch data-processing applications.
 Generally, the development of a distributed processing system is an expensive, political,
 cumbersome thing to implement. It  is very slow to evolve. It has to be justified in detail,
 with users looking at all of the alternatives, .because of  potential  pitfalls. It requires an
in-depth study of all  the alternatives  to be  sure that you're not walking down the  wrong


                                          GS-1*

-------
road blindly,  and it has to be  implemented with minis for data  entry, inquiry, local
processing,  terminal handling,  file handling,  and  communications with  the  existing
network.  Specific industries which seem to be most appropriate for distributed processing
are railroads; retail applications  primarily involved with point of sale; banking, with some
unique  situations;  and the  insurance  industry, where distributed  processing is in  the
thinking stages.  The computer  services industry offers many advantages to distributed
processing, and many of the computer services industries are taking the lead at developing
applications to make use of distributed processing.  In many cases communication service
bureau  applications are being considered for minis;  in order  to not lose  the kind of
businesses, that are implementing the minis themselve.  Some service bureaus are putting
together the software and the applications necessary to continue servicing the small users
with a mini-computer on-site, with heavier processing power available back at the central
site.  Within manufacturing, the application area is somewhat mixed, although materials
requirement planning seems to be the primary area.

     That concludes  the  material  that  I have  to present to you.   If there  are  any
questions, I will be glad to try and answer them.
                                           GS-15

-------
                             QUESTIONS AND ANSWERS
Question:       How about something like social security?

Answer:         Yes, social  security would seem to be distributive.   In fact, they are
                doing a lot of processing in regional centers; I am not sure just how much
                interaction  they would need  to have with the central site.  I do know,
                however,  that almost everything involved with social security does go
                into the  central site at one time or another.  Government agencies are
                large,  have much computer power,  and are  distributed  all  over the
                country;   it seems  as  though  they fall into a  distributed prospect
                category.

Question:       Wouldn't  there  be  military  applications,  like intelligence-gathering,
                satellite-tracking, etc.?

Answer:         Well, I'm sure that  there  are many applications  that are  appropriate
                within the Government. I am sure that the Government is definitely ripe
                for distributive applications.  I just do not know which of any agencies
                are doing what at this point.

Question:       I  was wondering what the mini-computer companies were doing in regard
                to the software standarization problem?

Answer:         It has been my experience that the vendor himself is not doing all that
                much, as far as the software  is concerned, he's leaving it up  to the user,
                the OEM companies, or the software houses to develop software.  I would
                think that it would be  in the best interests of some of those vendors to
                attack certain kinds  of software, at least the software typically involved
                with distributed processing.

Question:       Could  you raise the  issue of centralized  versus de-centralized manage-
                ment orientation? What are your thoughts on the compatibility of the
                centralized management orientation?

Answer:         /  feel that there has to be central  control, otherwise  all the pieces will
                not fit together. The development of that software or of the system can
                be performed  at distributed locations.  It has to be controlled, however,
                by  some  central  site in order to insure the  compatibility  and the
                uniformity of all the  interfaces.
                                         GS-16

-------
                       PANEL A: DISTRIBUTIVE PROCESSING
                     Chairman:  Theodore R. Harris   MIDSD, Washington, D.C.

                     Panelists:  Bruce Almich   CSSD, Cincinnati, Ohio
                                Fred Kastner    NCC, Research Triangle Park
                                Mickey Cline    ORD, Athens, GA
                                Curtis Lackey   Region IV, Atlanta, GA
                                Joel Brandon    Region V, Chicago, Illinois
                                Dennis Schur    Region X, Seattle, WA
                                Steve Goransen  Region V, Chicago, Illinois
                                Jim Hammerle  OAQPS, Research Triangle Park
                                Jim Susha      WPO, Washington, D.C.
                 OVERVIEW OF DISTRIBUTIVE PROCESSING IN EPA


                      Theodore Harris, MIDSD, Washington, D.C.

     I have assembled eleven  people who will be making presentations on their views,
actions and plans for distributive processing in EPA.  The goal for today is to share what
we are doing, who  is doing it,  where we  need to go, and what major  issues we need to
resolve.  First, I would like to give you my  view of what we're doing.

     I do not  like to use the words distributive processing; it is against my anti-buzz word
philosphy.  The way I visualize it is as a hierarchical set-up with the host computers
playing major  data-base roles.  Using a map of the U.S. which shows EPA's organizational
structure, one can see that we are greatly geographically dispersed.  This is one of two
charts I have on the host computers.  I think it is dated May. It is a complex environment
with hardware, software and many people.

     This  is  a  similar  configuration  chart  with  Univac equipment  for  our  National
Computer Center (NCC)  in North Carolina. This shows the four by two configuration for
the Univac 1110. It will  soon go to a four by three.  It is also very large and complicated
with a lot of equipment and people.  This is a better descriptive chart which shows the
flow of the data automation up through the hierarchy.  You can look at this several ways.
From top to bottom is the way we are currently looking at it, from headquarters with the
national  systems running from large computer centers, gathering data either through this
mechanism or  places  in  between.   If  you look at  it as you  go  down,  the  different
responsibilities and  authorities  in the agency  change as you go down to the field level.  I
would like to show the lab view  because the more that I learn about the agency,  the more
important role I understand that they play in what we are doing and where we are going.
The direction that EPA is leaning—maybe already there—is to automate fully from source
data, through  automation control to the  locals, i.e., local mini-computers, then to the
National  Data  Base  Systems.

     There are two mini-computers identified on the chart.  The PDF  11-70 was selected
via the EPA standard terminal  contract that  was competitively procured two years ago.

                                          A-l

-------
 The Data General Mini-computers was a similar procurement for laboratory automation. I
 will talk about the PDF 11/70's and their  particular  role in distributive decentralized
 computing.  This chart shows the goal and  the purpose of what we are doing.   The
 procurement did was entitled called  mini-computers:  it was called a remote  job entry
 (RJE) Terminals with concurrent local processing.  The goals and the purpose were to
 support distributive processing,  distributed in the terms of local data entry, local data
 management, and a decentralized data base management. The justifications for sites have
 been mainly on data entry and some  small processing at the local level.   Goals of lower
 cost to the agency and the provision of an agency-wide procurement mechanism  were
 identified in this presentation. We have accomplished, these goals by providing an agency-
 wide contract.  We currently have five mini-computers installed and one  on order.  This
 chart shows that all, except one, are connected to both computer centers.  The chart is in
 color showing how they are connected and the speeds.  There may  have been one or two
 changes since the slide was prepared; The changes would have been instead of two 4800
 band lines, one line at 9600 would  be going to  either place.  Starting  at the lefthand
 corner, the Cincinnati system in our  EPA test  support site.  The others  are installed in
 Athens, which is a research lab; Atlanta, Chicago and Seattle, which are regional offices;
 and another in Gulf Breeze.  The little arrows pointing in are dial-up lines into the  mini,
 however, most of the terminals are locally-connected.  They are hard-wired.  You can also
 dial into the mini-computer to give flexibility.

      The concurrent functional activities were defined in functional terms.  They were
 remote job  entry (RJE) to support both IBM and UNIVAC. IBM - HASP is the facility that
 allows  you  to do multiple things simultaneously while connected to the central computer.
 You may check status  to find out where your  jobs are.  The UNIVAC 100^ emulator is
 currently being replaced by the Nine Thousand Remote (NTR), but when this procurement
 was done, these were the requirements.  In addition,  we required some FORTRAN and/or
 BASIC  to do some statistical calculations for small one-time modeling.

      Our third requirement was for data management. Data management and data-based
 management are buzz-words that have different meanings to different people. I will give
 you mine.  A Data Management System (DMS),  it has three aspects: data entry, on a
 screen  or a CRT that provides for formating and validating of data entered;  a storage
 facility to keep  up  with the files; and the  data elements within the files to provide for
 sorting, searching, some manipulating of data, and  a high level language  for a report
 generation.  This facility was a desirable option in our recent procurement;  however, the
 winner  did  not  provide  it.  EPA  then went out  with another  procurement for a  Data
 Management System (DMS) for the  agency.  We awarded this competitive contract to
 United  Computing Systems, Inc.  They have been successful in having a Data Management
 System  running on  Control Data computers.  A year and a half  ago, they  decided to
 implement on the PDP 11/70. It is the same exact language.  The chart shown is to give
 you a better definition of what it is supposed to be, how data-based management is a part
 of it as opposed to the other way around.  The data is  in the middle with the data elements
 identified.  You can either enter data in  or  take it out. You can manage  it  by backing it
 up,  moving it around, or you can  manipulate it, and then produce reports.  One copy of
 the data can be accessed in multiple ways.  It is not something as complicated as DBMS-
 1100, or System 2000,  but  something simple, quick, and easy.  The Digital Equipment
 Corp. contract  allows  us  to buy most  of  what equipment that  they  sell.  We have
 determined  a  standard  configuration, so that  we can share software,   have  the  same
 standard operating systems, and experience most of the startup problems at our test site.
 To put  in a complete package consisting of hardware and software, is our  goal for all
future sites.
                                          A-2

-------
     This chart shows the software pieces involved.  This chart gives an indication of the
software side.  Looking  from the top down, (of the pyramid).  At the top is the operating
system, IAS, underneath are the  two remote job entry (RJE) emulators that talk to the
central sites either one at  a time or at the same time, or to multiple sites at the same
time, depending on communication lines. The next level of interfaces of software are the
user-related pieces.  The point here is that it is a complicated computer, but simplified
down to a smaller scale.

     Everybody in the  field has  their own buzz words and even though the title of this
talk is called decentralized computing, I would like to  call it Balanced Computing.  EPA
needs  to look at each of  its applications on  an individual basis  and  decide which
application pieces or total application go on which computer.  This is the idea of Balanced
Computing:  allowing that flexibility. I think the way we are going, the data entry pieces
are working  out very well on  the  mini-computers.  I would like  to  raise the  issue  of
distributed data bases and how EPA should keep them  in sync with the National Data
Bases.

      We want to be sure that we do not duplicate applications. Since the equipment and
software are the same,  there is no problem in taking modules and running them on other
systems.  We are working in the area of a standard development approach, and a systems
analysis attack. We are also looking at standards for documentation for minis common at
an  EPA  mini-computer managers'  meeting about a month ago, we  came up with the
concept  of  a  Documentation  and Distribution Center.   The  center is  to document
programs, have it at one location for all of the other centers and publish abstracts of the
programs.

      Before I call on the next speaker, I have some information for those people that do
not know what mini-computers  are.  The first part is for those who have never dealt with
laboratory automation.   Then I  will  discuss some  instruments and some  automation
interfaces.
                                          A-3

-------
                        CINCINNATI TEST SITE EXPERIENCE
                         Bruce Almich, CSSD, Cincinnati, Ohio
      I would  like to say  a word  about
 Digital Equipment Company's IAS and how
 EPA selected  it.  How do  you  come up
 with an operating system for the hottest
 mini-computer architecture?  We ended
 up  with  IAS,  because of its  concurrent
 capabilities of real time and  batch pro-
 cessing.  That is very difficult to do in a
 single CPU.  Luckily, the hardware archi-
 tecture lends itself to that.  Further, IAS
 seems  to fall  out mostly because  it was
 the only  system for  which we could buy
 off-the-shelf   communication   software.
 When we got IAS, we realized that it was
 very easy and quite  necessary  to learn
 quite a bit more about the internals of the
 operating system. We realized one of the
 points  addressed in relation to mini-com-
 puters is  that one is not dealing with IBM.
 You have to  hold your  own hand.   We
 found  that  it is as complex  as any
 operating system,  running  on any other
 machine in the agency, with the exception
 that there is not quite as much parallelism
 going on.  As far as the types  of systems
 work that needs to  be  done,  it's  in the
 same ball park with the larger systems.

      Our  machines  showed up  about a
 year ago and we brought up the release of
 IAS, Version 1.1.  Apparently One Point
 Zero was unusable or unworkable.  One
 Point One was a much better system; it
 worked quite well.

      In January  1977 it was  generally
 revealed to my group through Ted Harris
 that DEC would be willing  to let us test
 site release Version  2.0, which  was the
 next revision.  We seized the opportunity
 mostly  because we saw some bugs  in One
 Point One.  The plan was twofold:   First,
 to try to plan for conversion and find out
 what types of  things  we should not write
 to  maintain state-of-the-art  with the
 operating system; and second to help DEC
 find bugs  in their own system by partici-
pating in  their test site activities where
you  send  in quality  assurance  reports on
their software.   It  was  about February
when Two Point Zero came in and we got
it running.  At the present  time  we have
put up the release version which has come
to all sites within the last couple of weeks
and it is a very stable operating system.

      I am certain that all of the regions
have much more accurate data than we do
on the uptime of their system, but I do not
know of any site that has an uptime that
is available  to all users of less than 90 to
95 percent during the  work day  or after
hours.  The  Two Point Zero  test  site
experience was very  positive for us.

      We do agency-wide support, mostly
in helping people get started. When a site
gets started, either they have come from
laboratory types of mini-computers and do
not know  a whole lot about ADP, or they
have come from larger  systems and do not
have that much  expertise in ADP mini-
computers.   They are finding that  the
personnel  skills  required  are  condensed
into a smaller number of people than at a
central site.  Usually at a site,  you have a
systems technical manager, a telecommu-
nications    head/systems   programming
head,  who  puts  in  the  patches to  the
operating  system and  maintains  liaison
with other sites in an effort to find bugs
in the  system,  even  in  the application
software.  Mostly, our efforts  have been
geared  toward pre-delivery  training  and
bringing people up to speed on the operat-
ing system.  There are some variations in
the configuration  that some of the sites
have come up with,  mostly because they
have different volumes of processing  re-
quirements like tape  drives.

     Other  types of agency support that
we've been providing is also along the line
of trying to develop transportable utilities
in the  system-level software.   At  this

-------
point we are developing a telecommunica-
tions software processor which interfaces
with   the  communications   emulators.
Hopefully we will provide a high degree of
automatic  communication  between the
PDP-11  systems  and  the  agency-wide
large systems and between PDP-lls and
laboratory automation  computers.   Our
operator is  going to retire in  a few more
weeks,  and  we  are  trying  to  replace
between 20 and  50 percent of what she
does with the automatic capability within
the  PDP 11. We are dialing the R3E data
phone automatically,  and answer it auto-
matically.  We want  to send  files  to and
from the host  without having to  order
them individually, or  involve the operator
and  user.

     As  far as  our plans go we have
installed, are de-bugging and testing the
Data    Management    System    called
INFORM-11.  Test time is  now available
to anyone who  wants  to get an account
and  try it out.   Some previous knowledge
at  the  user level of  IAS is necessary.
Most folks  who  have  been using  it are
those who have either ordered it  or will
order it  shortly.  They want to get a good
feel for the size  of  the application with
which  they  can get by.  on a PDP  11.  We
also attempted to evaluate  INFORM  in
terms of fitting it into the environment of
concurrent  remote job  entry.  We  need to
know how many users we can support, and
how big the application can get before any
one user begins to take over  most of the
system.   The  final released version  of
INFORM, at  least  the  one  that will  be
delivered to all the sites,  is in Cincinnati
now.  It resolves  most of  the bugs on our
bug list.  Next week,  we are  having  a
training  session in Cincinnati to kick off
the applications development. At present,
most  of the  INFORM applications being
worked on are not things that are being
stored locally, but  rather are data entry
and reduction systems for the large hosts.

      I   am   really  excited  by  future
prospects of this  project.  I look forward
to the time, about a year from now, when
it will  be technically possible  to put  a
dedicated mini anywhere  for a data base
of a certain type. One case that comes to
mind  is the Federal Reserve  Bank in New
York.   They  have  the world gold supply
data base on one mini.  I  understand that
ERDA  is  looking  into  that  type  of
approach for the  plutonium  supply  or
other nuclear products processing.  To me,
it is  very exciting because reliability  of
hardware no longer becomes that much of
an issue.  People  fighting for resources on
a  large  central  machine   no  longer
becomes an issue when you  get down  to
the matter of using the machine to meet
Agency needs as the main idea.  I will now
respond to questions you may have.
                                           A-5

-------
                            QUESTIONS AND ANSWERS
Question:        I don't understand transportability.

Answer:         What we have been doing is, as we are developing something or before we
                we start to write down something about it which describes, we see if
                there  is interest at the other sites.  In one case, there was a magnetic
                tape  utility.  Now everyone  seems to want to take magnetic  tapes of
                various  types and formats and put them in PDP-11 format, play with
                them, and  send them off to  NCC or  WCC or read an NCC tape.  To
                develop a transportability or  a truly versatile mag tape usually takes a
                while.  We  try to  identify these areas.  The way it proceeded up until  the
                first  mini computer conference was that someone would say, "I think I
                am going to do this.  Does anybody object?"  or " This is a functional
                description of what I am going to do.  WouZd you use  it? "  If a couple of
                places say they will use it, then they say, I will do all the documentation,
                all the comments and make this usable by everybody At the applications
                level,   the  mini-computer managers'   meeting  will  put  all  of  the
                applications that are more than two to three person-months of indicated
                effort up on a blackboard, and pick them off and identify a given site, a
                given  person,  usually a  given site  with  various  applications.    My
                application, at  this point, is  to work a laboratory sample management
                program for the regional laboratories.  There are various administrative
                systems that have been dealt with in the same way.

Question:        Do you support any training activities?

Answer:         We consult with you on what  you should take from DEC before you  get
                your system.  We  have a two- to three-day training course in Cincinnati,
                where we teach your system manager how to supervise the installation of
                the system, do his system manager duties, and how to train the end users.
                Basically,  it is an  orientation,  a  three-day course where the system
                manager and operations chief  will overlap during the second day.

                Most of the training is available at DEC, but DEC has extremely limited
                hardware and system availability in their training sessions.  People who
                have had this before take the lead and try all the new things they want to
                try. People who have not seen it before generally get scared and do  not
                try anything.  In  the lab sessions and  the lecture, you do not get that
                much hands-on experience; you do get free training with five person-
                weeks of training credits, with your  systems, plus a week of on-site
                training for a dozen people who are presumably your best  users. We try
                to picfc up all the  loose ends with that training and try to make it a good
                package, tailored toEPA.
                                          A-6

-------
                    THE EPA TELECOMMUNICATIONS NETWORK
                      Fred Kastner, NCC, Research Triangle Park
     The communications  portion of the
COMNET  contract   was  awarded   last
December  and called for a single nation-
wide   telecommunications  network  to
replace and combine the services provided
by Optimum Systems, Inc. (OSI)  and the
National Computer Center.  OSI  services
have been  replaced and COMNET is  still
working  on completing the access to the
Univac system at NCC.  When  we got
ready to install the network, we took the
latest  statistical  data from OSI  and the
National Computer Center, combined it,
looked at it, and then decided where we
wanted to  put  in  dedicated facilities. We
took the COMNET  proposal  and imple-
mented the network based  on three nodes:
COMTEN  communications processors in
Denver,    the   Computer  Center   at
COMNET headquarters, Washington, D.C.,
and the  National Computer Center  down
at RTF.  The network has two phases; one
for high speed batch work, and one for low
speed access.  Presently, the COMTEN in
Denver and in Washington are connected
over a 56  KB  DDS circuit (Digital  Data
Service).  The circuit from  Denver to RTP
is not yet installed, although we expect it
to be  operational at the end of  January
1978.  It will also probably be a 56 KB
DDS.  The  circuit between  the Washington
Computer Center and the  National Com-
puter Center  will also be  DDS; it is not
yet installed.  Currently, in its place, are
six 9600  BPS dedicated circuits. What we
have   now  is   the   three    COMTENS
connected  by just the two circuits  from
Denver to  Washington, from  Washington
to RTP.

     The   remote   sites   have   batch
terminals, Data 100s, but also some of the
sites  have  mini-computers,   the   DEC
machines.  In most of these cases, for the
high  speed network,  there  are 9600  band
lines,  using split stream data  sets to use
half of the lines for Washington access,
and the other half of the lines for access
to  the  Univac  system  using  the  1004
protocol.   That  portion  of  the network
software is not yet available.  COMNET is
testing it and they indicate that it will be
ready by the first of the year.

     The interactive portion of the net-
work is  a little more complex due to the
large  number of  users in  the field.  There
are things that we can do with  low speed
communications that we can not with high
speed.  Basically each  remote site has a
multiplexer that  will  take a number of
low-speed  terminal sites reached by  a
local dial up within that city, and concen-
trate, combine  it onto  a higher  speed
circuit,  and send it along the way.  Some
of the circuits are rather complex in that
they have  more than one drop, and  will
eventually   terminate  at  one of  the
COMTENS.  We can reduce  circuit costs
and also provide local availability in  this
multiplex concept.  COMNET  is having
some  problems with Timeplex equipment.
When you think about  all  the vendors
involved with  this, Timeplex, as well as
General  Data Comm  and   virtually  a
different  telephone company for  every
site, I can sympathize with them, but they
proposed the system. They believe it will
work; they  are  convinced that it works
now.  One  of  the priorities that we have
established with  the contract is that even
though the services may work  as far as
the COMNET's concerned, if the user can
not get  the job done, then it is worthless
to us. We have  started several programs
at COMNET to  make sure the users are
satisfied.    Hopefully  these things  will
clear  up.  With the amount of equipment
involved, I think it will take a little time
to stablize. Basically though, it is a good
network, and  I think  it  will provide the
services we require.

      As I indicated, each remote site has
a  multiplexer  with local dial capability.
We did this for  availability in order  to
                                         A-7

-------
enable the user to dial a local telecommu-
nications  access  number, and get on the
network, not only for the EPA office, but
for  any other state, contractor groups
within  the city,  or any groups that can
access the local number. For those people
who do not have dedicated equipment, and
this is  true for  the  batch services  also,
COMNET provides WATS lines, all homed
in Washington that enable the user to get
on the system.  Once  you get the data
tone, the user merely indicates with which
system he wants to process,  then the
logical connection is made.   As  of last
Monday, 30 CPS  or interactive usage low
speed is available to both centers.  We
brought up Univac last Monday, and found
some minor problems with it.  There are
some isolated cases where Timeplexers do
not work, but, we are working on this. All
in all,  I was pleased with the way it did
come up last  Monday.  COMNET is pre-
sently working on 1200  bps access.  They
will support the  new Bell 212 full duplex
1200 band modem.

      COMNET  is also  working  on the
Univac 1004 software, and expect  it  to be
ready the  first of the year.   As  soon as
they get that done, we  are going to ask
them to support  NTR  which is  Univac's
new RJE protocol.   All  this is working
towards what  we eventually hope  to have
as common protocol.  The remote user at
the RJE terminal will load in one emmula-
tor deck and will  be able to get on at both
centers.  It will  probably be an ASC 11
protocol; we are  not exactly how to get
there, but  NTR is certainly a step in that
direction.

      Another  item,  within  the  next  6
months,  is  the request  from  COMNET
about the recommendations and feasibility
on  intercomputer communications;  i.e.,
being able to move  data and  data  files
directly  from  one  host to  the other.
Bruce's   mini-computer   in   Cincinnati
offers a way of doing this.  You sign on to
the IBM system and unload files, then sign
on to Univac and send them down to us.
We would, however,  like  to  see a way to
do  it directly; it is one of the items on
which we will be working  next year.

     We have also prepared an EPA, NCC
WCC Interim  Telecomunications  Users
Guide.  The  NCC user  should have  this
booklet and the WCC users will receive it
shortly.   It briefly describes the network,
lists the  phone  numbers of  the multi-
plexers in the remote cities and the WATS
lines for the different speeds of access. It
talks about sign-on cards, site I.D.'s, user
I.D.'s, who to  call if you have problems,
and  what certain messages  mean coming
out of the COMTENS. This is  an interim
guide and will be replaced with a formal,
more sophisticated document probably in
February. It  will come out as part of the
WCC users guidebook.   The communica-
tions section  will be independent so that
we can take it out and make it available
to the NCC user  community as well.  The
WCC user  community should be getting
their copies  probably next week.   This
booklet should help considerably in letting
you  know what the  network is all  about
and what we  are  trying to do  with it.  If
you  are  having   problems   with   the
COMNET network, the best  thing to do is
to see me after the session.  One of the
problems we  have had is that  COMNET
assumes  that  things are  working when
they are  not.   The only way that they can
find  out  about about the problem  is for
you to call and let them know.
                                          A-8

-------
                             QUESTIONS AND ANSWERS


Question:       Did you look into using a commercially available network, like Telenet
                and Tymshare instead of inventing your own network, protocol, etc.?

Answer:         This is what COMNET proposed, and we  went with it.  Their back-up
                system  or alternate system, actually  does  use  one of  the  existing
                interactive systems.  We are trying to get the users off of it, because we
                would like to use the primary network, the dedicated facilities, in order
                to pinpoint workloads and find out for sure where  the requirements are
                and where we need to make changes in the network.
                                          A-9"

-------
             PROJECT INDEPENDENCE:  DATA PROCESSING CAPABILITY
                            D. M. Cline, ERL, Athens, GA
      Back in  November 1976,  President
 Nixon  proclaimed his Project  Indepen-
 dence to deal with the energy crisis.  The
 very same day, I stood up and proclaimed
 Project Independence for data processing
 capability in Athens.  The  reason I did
 that was because I was using OSI and the
 General Time Sharing Utility (GTSU) that
 we have had  all along.  I  didn't like  it
 because the response time was very poor.
 Turnaround  times for jobs that required
 large memory requirements  were always
 over my response.  You could not use the
 system after midnight, or on Sundays, and
 some people work at those  hours.  They
 also did not have a plotter;  everybody
 needs a plotter and  they  had  a poorly
 supported,    interactive    development
 system, TSO.

      We did a little feasibility study, and
 the adoption of Standard Terminal  IVB
 was justified on cost because we are cost
 effective. We did not look or explore the
 intangible  effects  of having  our  own
 facility, because evidently you can not do
 that in the feasibility study. You had to
 justify  all  the  dollars, and  we did  just
 that.  We finally got our mini  ordered in
 September of 1976 with MIDSD's consider-
 able help.   It was delivered in  late
 February,  1977.  It took  a few weeks for
 the manufacturer to come out  to install
 the system,  and as soon as  they did, we
 started using the system.

      How do we use that  system?  First
 of all, we started converting every appli-
 cation  that  we had at OSI to a local
 system.  As it turned out, it  is  quite easy
 to do, using  one of the Agency's approved
 languages.

      Some  of  the things  we do on  our
 system, I think, are pretty nice.  We  can
 reconstruct a gas chromatogram from  a
 GC/IR system.  This means  that, in  the
past, the scientist could only acquire data,
or analyze data, but not both at the same
time. Now, I can acquire the data, bring a
tape, and while he is acquiring more data I
could be doing the analysis  on the  mini-
computer. We couldn't do that analysis at
COMNET because it takes approximately
9 million bytes of data to do that.  That
means we would  have to sign on COMNET
and hope that COMNET did  not go down,
the  communication facility  did  not  go
down or our  remote  job entry terminal did
not go down.  We have also done all  our
mathematical  modeling.  We have a large
environmental chamber  in  our  facility,
where  we control  all  the environmental
parameters.  We  have developed models of
that system, all  running on the PD 11/70.
We can acquire  data  from  the environ-
mental chamber  and from a mathematical
model with simulated data and plot  both
on  the  same  graph.    We  have  several
interactive programs that do that.

     We have also re-evented the wheel a
little,  by  implementing  some  of   the
graphic   techniques     available     on
Mathematical  Modeling Labs on our mini-
computer.  We have a comprehensive set
of  graphic  routines  which  support  our
programs in the terminals.  The benefits
of the system are  manifold,  because our
program  analysts have  really increased
the  productivity as   opposed  to  doing
batched  program development.   People
consider it a terminal and operate it down
to a 60 character a second, as opposed to
the  30  character  a second,  system  we
have at OSI, where we could edit a  job,
wait for it to come back and better it.
This way you find out  immediately if you
have  a mistake or not.   On  the  IAS
system, we  do have the batch capability
and    we     develop    our   programs
interactively.  We then select the job for
batch processing. The turnaround is very
good because  there are a few people in
the Athens lab and  there is a lot of time
left over from the  program development
                                          A-10

-------
activities.   Graphics are great.   All our
graphics are  done  at  9600  BAUD  as
opposed to the 300 BAUD at COMNET.  A
month before  our mini was installed,  we
were spending $6,000 or $7,000 a month,
with a high of about $9,000 or $10,000.  If
you  look  at September, we're down to
about $87  at  COMNET.  That is quite a
savings in money.

      In our Zero-Based Budget (ZBB)  for
1978, $276,000 was allocated in our labo-
ratory;  once  these  savings were known,
however, it decreased to $72,000.

      One  disadvantage   of   our  mini-
computer is that we are running  on a  16-
bit mini-computer.  When you have that,
you  are  limited  to  a 32K word  address
base.  This means once you start  working
on large problems, you continually have to
contend  with overlay  systems.    With
modern  technology,  there are at  least
three mini-computers which support a  32-
bit word line.  If we  had that, it would
eliminate many of the problems  that we
are encountering on a daily basis, both in
terms of  the  instruction set  and  the
overlay problem  .  And there's one huge
software gap  in  our system.   We do  not
have a local statistical analysis package,
like SAS and SPSS.   Other than this we
love the new mini.

     We are doing a little something in
the area of distributive processing.  First,
we are  trying to tie all of our dedicated
mini-computer system into our mini-com-
puter for report generation, data analysis
and program storage, in  order  to load
programs  on PDP-8's or our POP ll's.
Second, in  January, we are doubling our
memory requirement. We will be able to
prepare some of our data locally, transmit
it  to WCC for processing and then get the
information back.  The only thing that we
do at WCC, by the way, is FMD.

     In summary, Standard Terminal IVB
has done more for giving our  laboratory a
hardware-software  capability than any-
thing else.  MIDSD should not drag its feet
now.    During  the  1980's,  they  should
include  32-bit   mini-computers  in   their
distributive  processing  network; on  the
more  immediate front, they need to rally
and get a staff package.  I am very  happy
to be a part of the Standard Terminal 4B
adventure;  I  believe that  my  Project
Independence policy has provided a good
hardware-software capability, as well as a
cost effective measure.
                                          A-ll

-------
    12,00.
    10.50_
                       WCC  EXPENDITURES
QC
CC
Q
    9.00 _
    7,50 _
 ..00 _
4.50
    3.00  _
    1 ,50
    o.oc
             11
             I I ':
             I ' '•
             ' 1 I .
          OCT
NG-/ '  -DEC    JflN '  FEB
                                             MINI  INSTRLLED
                                                          $87
                                    i—	—r
                                 MRR    flFR   MflT   JUN
JUL   RUG

-------
                         AIR QUALITY TRACKING SYSTEM

                                        PDF
                                   Steve Goranson
     This  is  a road  show  that  I gave
several  times  in a couple other places.  I
am going to  talk about  the  PDF  world.
This series  of programs  is  very  simple.
The reason  that it is successful is  that it
is simple; it uses simple language and it is
compatible  with other  systems.   It is
somewhat  transaction driven,  because  I
deal with input records that are at a base
level.    The  PDF  also  provides  quick
turnarounds and analysis.  Mostly we will
be dealing with small data sets.

     Air quality data is handled by NADB
in its entirety.  The problem is that  the
regions   took  over  the editing cabilities
and handling  procedures  from  the state
and local agencies.   We are required to
give NADB a clean data set.  The first
purpose  for  this "system  or  series of
programs" was to create a clean data set.
It was  initially designed on  the Univac,
and then on  our PDF.   Basically,  we
jumped  in at the basic edit level and tried
to  provide  trunaround to  the states  and
local agencies as quickly as  they gave us
the tape.   We hope we are at a point
where one man can bring up a magnetic
tape with his  quarterly report.  Attend  a
meeting in the morning, and we can return
a  summary by noon.   To reiterate  the
needs of the system: initially, we wanted
a quick  response on special projects.  The
analysis     includes    some    complex
summaries,  air quality standards requiring
non-overlapping periods of analysis.  Pri-
marily,   it  is designed  as  a  regional
tracking  mechanism,  whereby   I   can
interact with  (unintelligible), and to  a
lesser  extent, management.   I  am  in
surveillance and analysis,  and  we  pri-
marily handle  the data and supply report;
it was really  out of their request that  I
designed   this   particular   series  of
programs.   Trend analysis is something
that was built in somewhat latter.  Jerry
Miller designed a program which operates
on the Univac, and does trend analysis on
the air quality information. At present, it
is  not usable on the PDF, because it is a
COBOL-driven program.   It is, however,
available on the Univac; In fact, all these
programs are available on the Univac.

     By turning around the data the same
day, there is no  question as to what they
had  submitted  to us.    Grant  funding
required us to submit a certain number of
sites  and  a certain quantity of  data.
Validation  of verification  is  very,  very
important.   The  region is responsible to
NADB   for  following   up  bad  data;
hopefully,  we  have  arrived at  a  point
where  we can nip it  in the  bud.   I will
show  you  how  that works.   As  these
summaries  operate on Univac, they also
will provide a reigonal summary of all our
data from  the NADB files, if requested.
There is a mechanism for generating input
from NADB to this program, but primarily
my goal is  to get the data clean before it
gets to NADB.  It is also important to get
it  back to  the states, so they know what
they have  submitted, and we know what
they have  submitted  and  where they are
deficient.   In developing  the  system, I
tried to get  the key  points that enforce-
ment   errand   hazardous   surveillance
wanted to  know.   Mainly,  we want the
linkage between where the monitoring site
was  located, what county  what AQCR,
what  state, what region, and  now what
SMSA.  Within urban areas,  we have the
capabilities of  strippling  off  industrial,
commerical, and residential remote sites,
summarizing by county or by state.  In
this package, we developed a state area
file an AQCR file.  Summary statistics is
the other main program, with the number
cruncher taking  the input  records  and
summarizing them. The area file contains
information   relevant   statistics,   the
                                          A-12

-------
population of the counties, urban areas,
and SMSAs. This provides the linkage as a
direct access file loaded on the PDF. The
AQCR  file  basically  contains  require-
ments.  This will be altered somewhat in
prospective (unintelligible) recommenda-
tions, namely instead of what we call the
(unintelligible),   minimum   required, will
now be called the (unintelligible) sites.  It
is however, different references, different
ball games; the same mechanism, will hold
the same structure.

      The  minimum  sampling  site file is
again (unintelligible) specific.  It contains
merely a specification of whether, know
what it monitors at those specific sites,
and whether  it  is  a required site  or a
federal required or  part  of the  sub-
network that will probably be equipment
specific,   especially  quality  assurance
guidelines and equivalency. The rest of it
is  basically  linkage to this  road code,
basic  information  also containing  UTM
coordinance  of  the site,  sampling site
address, station type, and  the  information
keyed for request purposes.

      Basically what we provide is a site
summary.  This  would be a summary for
the   criteria    standards,   of    what
information is available for that site, and
for what given  time  period.   If they
submit a  quarterly report,  it'll give you
the number of observations for the site.
AQCR summary  is the summary  for  all
the  sites  with  the  AQCR.    Violation
summary  gives all  the  accessions of the
standards, tracks them, and prints them
out. It lists the site, the site address, the
observation,  the  number  of observations
over the standard and highest  value, and
whether  it is a required site or sub-site.
This  is  a  detailed  listing of  all  the
violations that occurred at that site, at a
given time period, on the tape.    The
AQCR summary  lists the  number of sites
required   for  that  AQCR  number  sites
reporting.   It is a tracking mechanism
showing  whether they are in compliance
with what they are supposed to  be submit-
ting.  It also shows the number of mini-
mum  sites and the maximum  values for
those AQCRs.

      There is also an 5O2 standard. They
have  multiple standards,  24-hour  stan-
dards, 3-hour  standards,  and  also  when
they occurred.

      We also have a meteorology program
going, it  is actually a Univac.  It is not
there on the PDF, but I hope that there is
a plotter  that we can share that perspec-
tive.
                                          A-13

-------
                             MINI-COMPUTER SUCCESS
                                Curtis Lackey, Chief
                    ADP Management Branch Region IV, Atlanta, GA
      I am  amazed at how  far  we have
 come in  nine  months.   By  we, I  mean
 everybody involved in the mini-computer
 effort. I underestimated the savings both
 tangible and intangible  when we did the
 feasibility  study  two  years ago.   The
 reasons  for our  success--! think we can
 call what we have done so far a success--
 are due to several  factors.  One is that
 the competitive  procurement resulted  in
 an award for a good hardware and soft-
 ware.  It  was better  than what I had
 expected with more processing power than
 I expected; that is one of  the reasons for
 our  success.   Another  reason  for our
 success is that we  are sharing software.
 Region IV  has shared  software  with  all
 sites  and  has  received  software  from
 other sites.   The  third  reason  for our
 success is the  availability of a test site,
 for technical assistance, for information,
 and just for help.  I do not know who had
 the idea for that, but whoever did should
 be commended.   Then  there  is  another
 reason,  Ted Harris.   Ted  has  lead  us
 through  the contractual  maze  on  this
 project, and he has been a good point man
 for us.  In  truth, we probably would not
 have  had  a  successful  mini-computer
 effort without Ted.

      In  my opinion,  the  mini-computer
 project is the leading edge of ADP devel-
 opment in EPA and those of us  that are
 involved in it  or  are  excited  about  it.
 Those of  you who  will be involved in it,
 will enjoy the increased support capability
 you have  for your  users.   Since March  or
 April of this year, we have learned a lot.
 We  have  learned that good operational
 procedure is extremely important in run-
 ning  a mini-computer or  any  computer.
 We also learned that the system requires
support.    It takes,  one  person-year  in
addition  to the operator.   Therefore,  it
really requires  two  people.  You can get
by  with  less,  but  it will probably depend
on your workload.  System tuning can have
a big payoff.   We nave not changed any
system  software  but  we have tuned  it
some with significant increase in through-
out. We are also using disc-to-disc backup
over  disc-to-tape  backup,   which saves
hours everyday.  I would like  to  empha-
size,  sharing  software just can  not be
beat. The regions are somewhat similar.
There are a lot of cases when we just use
a piece  of software without change.  A
good  operator is  really needed,  and we
have one in Region IV.  Also, someone  in
the  office  should know  a  little about
communications because it really  comes
in handy.  Management is slow to recog-
nize the impact and the potential benefits
of  the  mini-computers, but  maybe  the
reason for this is that they  have been
oversold  in the past,  and now they are
-waiting to see results.  They are reserving
judgment on this one.

      Our approach in Region  IV  was  to
move the systems  we could quickly to the
mini-computer. We did not undertake any
big development efforts, but the systems
that we  tried  to move very  quickly were
relatively simple  systems.   We  have  16
systems  operational now on the mini and
six  utilities that  we developed,  or  con-
verted to the  mini. Region X developed a
gneralized update  capability that  was on
the IBM  system. We have converted  that
to run on the POP  11/70. That  was one of
the reasons we were able to move several
of these other applications quickly to the
mini-computer.  The  biggest  application
area that we  tackled  so far has  been in
data entry of  the  Grants and the Finance
systems.    Those  systems  utilize  one
terminal;  in   the  future,   there  will
probable be another one added. That one
is  in  the program area.   The users are
entering  the  data  at the  source from
                                          A-14

-------
turnaround documents, coding sheets, and
actual source  documents, eliminating the
coding process.   In  many instances, also
eliminating a big backlog in keypunch that
is  a waiting turnaround  for keypunching.
Another   area,  just  implemented   two
weeks ago,  was  finance.  The financial
management branch  was  directly entering
data  in  a screen,  in their  office  from
source documents and avoiding a lot of
their coding.  Another area  is the water
and  air modelers which  come down and
use  our   system  daily.    This has  had
negligible impact on us so far, and it has
been a real responsive tool for them.

      What  are  our  plans?    Our  plans
depend a lot  on what  kind  of  package
INFORM is.  I will identify some areas in
which we are interested.  The  regional
Formal Reporting  System  is something
that we want to put  up that will interface
with the  headquarters system.  A Docu-
ment Control  Register System, a budget
system,  a project  reporting  system,  a
STORET  input data  editing  system, the
Region X water quality index system, and
a  version of  the sample file  controller.
We want to move some local  enforcement
systems that feed PCS.  We would like to
move  our little positon  management sys-
tem, and  there is also another area called
grant  data  management that we would
like to get into sometime in the future.

      I  want  to  emphasize  we  are not
jumping out into any of these on our own.
We will be sharing in the systems develop-
ment process with all sites. The extent of
our success, in the future, depends on how
much we share with each other and  plan
together.  Something I've learned: sharing
is easy to say, but it is work to do it.  You
have  got  to  be  considerate  of other
people, think about their needs, communi-
cate  with  them,  fix  bugs, send them
updates to your system, and you have got
to be committed to it.  So, the idea of the
software clearinghouse is something  that
came out of our meeting  in Cincinnati.
It's a really good idea  and  something we
will support in Region IV.

      There's a phrase that I have thought
up, in the past, amd had jokingly said  that
some   of   our   Headquarter   systems
managers were saying,  "Hey guys wait up,
we want to lead."  That is really unfair to
say because they do have some legitimate
concerns, and as some people in this room
have  some  legitimate concerns.    One
concern is  that the Regions not develope
ten duplicate,  individual systems.  I share
that concern.  We are going to try to do
the best we can in preventing that from
happening.

      In summary,  we have  made a lot of
progress, but  the  big payoff is  yet to
come.  To  achieve maximum benefit, the
mini-computer  application  development
must  work;  it   is   sharing  and   not
duplicating.  The  Regions   must  involve
Headquarters  in  planning,  and  Head-
quarters must take an interest now, rather
than be surprised later.
                                         A-15

-------
                            QUESTIONS AND ANSWERS


Question:       When you actually transform an application program or data from one
               region to another, what actual physical mechanism do you use?

Answer:        Magtape.

Question:       Are you doing any documenting now?

Answer:        Yes, we are making a consciencous effort to document.  We are trying to
               share everything  that we  do.  Region IV sends out a monthly activity
               report to all regions and several headquarter offices.
                                        A-16

-------
                DISTRIBUTING PROCESSING ISSUES AT EPA REGION V
                                 Joel Brandon, Chief
                               Data Processing Branch

                                  Region V, Chicago
     There are two concepts I would like
to address:  distributive  processing and
mini-computers.    They  are somewhat
related  in  this  context.    Distributive
Processing, indicates  that somebody has
distributed   something,  or  has   taken
something   that   was      central   or
nonexistent and deliberately spread it out.
Clearly,  this  is not  going  on  in  EPA.
There  is no managed effort to  distribute
any  application  system  in  this  agency.
This is because, in fact,  there is  not any
particular managed  ADP  effort in the
agency.    In  other words,  there  is   no
central ADP organization responsible  for
all  our ADP  applications.   That means
that there is no planning and no manage-
ment.   There  is no  oversight review  or
overall  coordination.     MIDSD,   inter-
regional cooperation, etc. provide  these,
but  they  really  do  not substitute  for
actual planning.  Without it,  you  can not
have a distributive system.

     Decentralized   responsibility  has
always existed;  this  is  a decentralized
agency.   The  regions have  always had
their own say in what they do. In the case
of the minis,  it is just  a  matter of the
equipment following that  logical function.

     The  second concept is the  mini-
computer,  itself.    Although  they are
called  minis, they have 16-bit word  struc-
ture,  but  they are  not  small.    Their
processing capabilities are rather exten-
sive,  a  couple of examples have been
made here  which  are fair judges of how
these things can support enormous opera-
tions.  Since these things are  not "mini's",
and since we do not have any distributive
effort, the question is what are these real
computers doing  in  the  little  regions?
Why are they  there?   Why did we want
them?     Those  of  us,  who have had
experience  on  large  machines,  were
frightened of the prospect of getting  this
thing under  our  control  and  having to
deliver something  with it.  In fact,  the
only reason is  that  we were  completely
unable to get our work done without them.
The only thing we could see as an alterna-
tive  to having  our  own  computer  was
having  the  stuff  done  right  at  Head-
quarters and that it  was not being done.
We could not produce an interactive  sys-
tem in the regions the using Headquarters
equipment.  It was rather unfortunate. In
many cases, what  we are doing could be
done by Headquarters.

     We have considerable cooperation
between the regions.  At the  Cincinnati
meeting of the mini managers, we more or
less agreed  that we  would develop appli-
cations for ourselves, make  such  compro-
mises  as  we  could and  let them  be
installed in  other  regions.   However, we
would  not  keep  daily  contact  in their
development.     The  reason  for   that
decision is  that it  would be  impossible to
do it.  We can get by with that  decision
since  the   entire  concept  of  systems
development has changed with the imple-
mentation of these  machines.  It is  this
point that  I would  like to  stress.   It  is
having this type  of machine  and more
important,   having   a  data management
system (DMS) on the machine.  We are no
longer locked into the old-fashioned tech-
nique  of  extensive  analysis, extensive
design,  feasability studies,  and  the  pro-
duction of a system expected to  last a
specific life cycle.  That is not the  way
application development is going to work
in the  future.    I  think  we  ought to
recognize this. It is very easy, using the
Data Management  System  to set  up a
system. Bruce Almicn did not go into the
application  side of the Cincinnati effort,
                                          A-17

-------
but when they bought up INFORM 11, they
bought up a personnel system with it, just
as a demonstration. It took them only two
weeks to generate an adequate personnel
system.  This was at  the same  time  as
learning INFORM, so that an experienced
INFORM user might  expect to do  even
better.  That means that if a new report is
needed, it  is a matter of, say, an after-
noon, instead of  a week, two  weeks,  or
even a month. Having that capability, the
requirement  to   analyze  and  document
becomes considerably lessened.  In fact, it
almost disappears when you also consider
the fact that Data Management Systems
(DMS) are largely self-documenting.  They
are also a lot easier to understand, than
COBOL or PL/1.   What  we look for in
Region  V  is bringing up a  series  of
systems.  They are planned; they are in
our feasibility study.  We  will talk to the
other regions in the development of these
applications.  In  fact, we will  throw  an
initial  package at  them.   For  instance,
Region  V  is responsible  for one of  the
finance systems,  but  I  would  be  very
surprised if those systems were  not com-
pletely modified within several  months of
delivery.   Because the regions  do, have
separate and completely  diverse activi-
ties.  I do not know what will  happen to
these systems  if  and when they  strike
Headquarters, but the same thing can take
place there.  The old constraints  are now
largely gone. As long as we do not flood
these machines  with things  that  they
should not be doing, we are assured of our
ability to support our individual locations.

      The  last point I would like  to make
has  to  do  with RJE  management  and
output productivity.  One of the things we
have noticed about the mini is  how much
it has helped us in managing the enormous
volumes of output.   We generate four or
five million print lines a month, and we
can not really  leave the thing up after
hours.  We  have several  different tech-
niques  for   getting   print  output   and
gathering  it,  the technical details  are
unimportant.  The net effect is  that we
can print twice as many lines as we could
on the Data 100 equipment.  Even though
we  had  two RJE's and one of  the minis.
That  is  a  side  benefit  that  was  not
envisioned,  but  it certainly worked  out
very well. All the other experiences that
we have had at Region V have either been
covered or  will  be  covered by  Dennis
Schur when  we get to Region  X. In the
interest of time, I will stop now.
                                         A-18

-------
                      REGION X MINI-COMPUTER EXPERIENCE
                                 Dennis Schur, Chief
                                Data Processing Branch
                                  Region X, Seattle
      I took  the  time to prepare a paper
for this conference that I hope would  be
published in  the  proceedings.  Because of
that, I^do not think that I really  want to
spend too  much time  going over  that
paper.  If  you have an  interest,  you can
secure a copy of  the proceedings and read
it.  What I attempted to do in the paper
was to take a chronological  approach  to
our experiences,  from the initial  decision
to  be a part of  the procurement of  the
mini-computer,   through  the assistance
that  we provided to MIDSD, through the
installation of our machine and our subse-
quent experience.   We  had our machine
installed in January of this year;  and this
have not had it for  a  full year yet.   I
would have to agree with Curt, however,
that  over  the past  12 to 18 months, we
have come a long way.  One thing that I
would like to stress—I am not sure that it
was adequately  addressed by  the earlier
speakers—is the impact  of the decision to
move  towards something  like  a  mini-
computer on a local staff.  I am a Branch
Chief, I have eight positions in my branch
that  support data  processing  for our
region. That does not  mean that there are
only eight people involved in data process-
ing.   In  the program   areas,  I would
imagine there are probably twice as many
people as  there  are in  our  branch  that
actively  use  data processing on a day-to-
day basis.  One of the things I think that
all  of us  envisioned  was that  our  own
staff, program people  would be turned on
to this new thing called  mini-computer.  I
was disappointed it  did not have  more
flashing lights than it has.

      I would like to mention some of the
problems in implementation that relates
to people's  attitudes  about  changes and
management  problems in trying  to get
people to accept  these changes in FY 76.
We had in our region probably  the only
IBM 2780 in the whole agency. From that
piece of  equipment,  we moved to  the
more standardized  Data 100  equipment,
that I think  everyone else has.   We in
Region X think we are one of the pioneers
and, in pushing for mini-computers, we
were, in fact, the first regional office to
accept the mini-computer and have it
installed.  We have had some problems. It
takes more expertise  on the part of your
staff  to manage  and  operate effectively
the POP  11/70 than it does the Data 100
remote terminal.  I think you all have an
appreciation  for  the  fact that,  within
EPA, we  seem to  be  able  to find ways
somehow or another to secure funding, for
a contract, hardware, or whatever, but we
have  a strange  difficulty  in  trying  to
secure positions  to  support equipment
expansion once the decision is made.  I
tried,  in  vain,   to  get two additional
positions within my branch  to support this
new ADP equipment. Earlier, I think Curt
made a point that  it takes at least  two
people full-time  just to keep  this  ADP
equipment operating.   That is certainly
true.  The two people that we generally
had in mind to do this were the two best
people on our staff.    At least  in my
situation  that  was the case.   I  would
caution those regions  or laboratories that
are anticipating the installation of a mini-
computer,  like the PDP 11/70.   In your
feasibility studies, I think you should take
a hard and long look at the implication of
that decision for  your staff resources. In
many cases, I think you will find that you
do not have the right people on your staff
now.  You will need a top notch technical
person to  be your PDP  11/70  systems
manager.  That individual is not the ADP
Branch Chief; this  is  a full-time job.  To
go out and hire someone like that is going
to take some recruiting.  I  do not know
                                         A-19

-------
what  other regional situations would  be,
with respect to position management and
classification, but,  in my opinion, we had
some  real  pains trying to get the ADP-
type position within our branch adequately
classified.   Your  staff  may not quite fit
the kind of people that one  needs for a
ADP   11/70  operation.     Also,  users
perceive the system differently.  Some of
the more ADP-oriented users, the staff of
our S&A  Division,  look upon  the PDF
11/70 as something that really gets their
job done, and is very responsive; they see
it  as  a tool to  them,  just  like  their
telephone.   They use  it, they really  do,
and it is amazing to me to observe from a
distance the  kinds  of applications that
these    individuals    with   very  little
assistance can get going.  I think the POP
11/70 is truly a programmer's—I hate to
use the word programmer's—machine.  For
the experienced ADP user or for a person
with some technical background, it can be
a  real  benefit.   For  those  individuals,
however who are not ADP -orinented, but
do ADP work—people who do data entry,
coding,  and routinely request administra-
tive reports—the POP 11/70 is not really
going to make their job very much easier.
It  has the  potential to do  that,  but  the
hardware and software configurations as
we procured them will  not  directly allow
us  to place a  terminal  at a non-ADP-
oriented user's work station.  My  point is
that there  is a  fair amount of  training
that has to  be factored into the installa-
tion of   the POP  11/70  system.   I  had
several other points that will come out in
the paper that I have prepared, so I think
that in  the  interest of trying to  provide
some time  for the other speakers, I will
just conclude here.
                                         A-20

-------
                            QUESTIONS AND ANSWERS


Question:       What  level person would  you need for a systems manager for a  PDF
                11/70?

Answer:         I think all of the regional ADP Branch Chiefs would agree that a GS-12
                computer specialist level  position is the absolute minimum.  We would
                like very much to see that position be a GS-13, at least I would. There is
                a tremendous amount of technical expertise that has to be absorbed and
                retained in  that  individual; I think we  have  to do everything that we
                possibly  can to retain that person  in that position.   There is a lot  of
                competition out there.  As these mini-computer systems are excepted in
                industry, there will be much more competition for those people that  have
                those skills.
                                         A-21

-------
              SYSTEMS:  DISTRIBUTED - CENTRALIZED - INDEPENDENT
                                 Jim Hammerle, Chief
                               National Air Data Branch
                              Research Triangle Park, NC
      Hammerle:  My first question is why
 are we talking about distributed vs. cen-
 tralized processing?  I think that we have
 heard explanations for what it may or may
 not mean,  what  it  means  to  individual
 people  and ways  of going about it, etc.,
 but  why   are   we  talking  about  it?
 Secondly, what is distributive processing?
 I think  we had a number of definitions this
 morning, and a couple this afternoon, and
 I will contribute to the confusion of that
 second  question, myself.

      I  think I have at least  probably  a
 partial   answer  to  the  first  question.
 Morris  Yaguda, I think it was about a year
 ago that you were using a slide, I did not
 know where you got it, but I had used the
 same slide  myself previously.   It showed
 four  stages  of ADP growth.   The fourth
 stage   was   the  phase  at which  initial
 explosive  growth  is  over;  there  is   a
 moratorium  on  new  applicaitons  and an
 emphasis on control with fewer resources.
 What bothered me the most when  I saw
 those four stages  of ADP growth was the
 last stage.   I saw  it  a couple years ago,
 and at that time,  there were a few people
 moving into that  fourth stage.  I  think
 certainly we fall  into that  stage at this
 time.   I have not seen that bright soul
 whoever he  was  who dreamed up  those
 four stages, but  now that we are in the
 fourth  stage, and some  others  have been
 in it for awhile,  what is the fifth  stage?
 We may be  on  the verge of discovering
 that now, because I will suggest what the
 fifth stage might actually be.

     People usually associate centraliza-
 tion with higher efficiency, and decentra-
lization with more effectiveness and more
responsiveness (that  is-closer  to  the
users).  Efficiency has  to  do with bigger
machines, higher specialized people, etc.
These are the kinds of things about which
people think when they talk about centra-
lized  vs.  decentralized.   The American
Management   Association  talks  about
separate  machines  transmitting   data
among  themselves.   They are  machine
oriented.  We had a speaker this morning
who addressed additonal  things besides
machines; namely, input, data processing,
etc. He expanded that beyond just  taking
a look at  machines talking to each other
and he looked at other aspects.

     Willis Greenstreet mentioned  his G2
activities.  He ran one of those on us a
couple  of  years   ago,  called  the  Index
Systems study of our data systems.  Where
was  the  data base?    They had  three
different bases about which they talked in
their draft report.  The final report talks
about utility, hybrid and the current  sys-
tem.   As it turns out, the utility  was a
totally centralized operation. Hybrid has
a centralized  component  and a decentra-
lized  component  with  the  centralized
component a subset of the decentralized.
In other words, you had a number  of major
data bases scattered around, and you had
little pieces of them all gathered  together
into one centralized data base. Then what
they actually  had was  a  totally centra-
lized and totally  decentralized data base.
That was  where each state had  all their
air  data;  headquarters  also had  all their
air data. If that is the way you look at  it,
what do you  call the situation where you
have a  centralized data base where each
little  piece is decentralized?  There are
actually five  of   these  permutations  of
data base locations and I  am  proposing
that probably what most people have been
talking  about  today as  decentralized sys-
tems, I  would  tend to think of as the  first
sign of a totally decentralized system.
                                          A-22

-------
     Centralized and decentralized are a
matter of degree.  I do not think there is
anyone who would take a look at air data
systems and say it is centralized or it is
decentralized.   It is a matter of degree.
You need to look at all the  components.
Some are centralized, some are decentra-
lized. Therefore, the concept of a centra-
lized system or a decentralized  system is
really  not very  good in itself.  It is a
matter  of degree.  How much is centra-
lized and how  much is  decentralized?
That will  depend on the current situation.

     What  do   we  have  for  computer
resources  in  the  agency  as  far  as
machines?  What do we have In terms of
personnel?   in terms of communications
lines and policies, etc.?  This  will be a
dynamic situation in which something that
was centralized  last year will  be decen-
tralized this year.  Something decentra-
lized this year  will be centralized next
year. It is a dynamic situation.  We do not
have centralized  or decentralized sys-
tems, but we have a new stage, perhaps
the  fifth stage in  ADP,  and that  is
independence:    total independence with
mini-computers  not tried  to any  other
machines, devoted to servicing one sys-
tem.  I  would also like  to  mention that
besides  looking   where  the  system   is
decentralized or centralized or looking
where  the data  base is and saying it  is
decentralized or centralized,  you  could
look elsewhere like where are the people?
Are they  centralized or decentralized? I
am very much concerned about the matter
of the people.   I think each  of  us has to
look at that very carefully.  Where are the
people  located   with  whom  we  have  to
deal?  Where are our users, where  is our
management?

     I have a checklist here.  On the left
side is a  D for decentralized and on the
right side is a C_ for centralized.  If you
consider auditability and visibility, I am
sure you will agree that if you have your
operation  centralized you have  a lot  of
visibility  and a lot of auditability.  This
means  that others can see what you are
doing; you can catch a lot of arrows.   It
depends on whether you are centralized or
decentralized as to whether that is a plus
or a  minus.   I  will give  credit on both
sides.  With  management concentration,
again, you may like to operate indepently.
It may be best for the agency that you  do
not.  This is a matter of consideration and
again I don't think we can say  that the
best way is to be centralized or the best
way is to be  decentralized.  I will  give a
plus  for  each one of them.   The next is
one with which  I  am  particularly con-
cerned.   It is a very touchy subject with
me.  This is data base and integrity.  I will
not  put  any mark  down,  because  my
personal  opinion is that in my context  of
centralized,  decentralized, and  indepen-
dent systems, I believe you do have more
data  base integrity  with a  centralized
system. Regarding personnel competence,
I think, even though it may hurt a little
bit, you have to  admit that  in  a centra-
lized  operation,  you can  afford higher-
graded people.   You will  have  a  higher
competence  level in  the  people.   With
personnel specialization,  I will  say that
decentralized and centralized can share.
You have people who are very specialized
in a centralized operation and you have
people who  are very  specialized  in  a
decentralized operation.    Those  people
who are in the decentralized operation are
very  specialized  towards   the  users.
They're  close to the data users, so they
are very attuned to those people.  In a
centralized   operation, you   can  afford
somebody who  spends  all  their time on a
small subject.  A decentralized  operation
just  could not  afford that  kind  of  an
overhead.  Next is standard of operation.
It is easier to set up standards of  opera-
tions  in a centralized facility as opposed
to a decentralized facility. That is not to
say you can not do it with  a decentralized
facility,  but  it  is easier  to   do  in a
centralized  one.    Functionalization  of
duties and responsibilities is also easier in
a centralized than in a decentralized, but
it's  not impossible in  decentralized.   It
takes a little more time, a little more
effort.  In  a decentralized operation you
have  a greater  probability of success in
the area  of data application and integrity.
                                           A-23

-------
Documentation standards again are easier
to have in a centralized operation.   With
programming techniques, the  centralized
system has a little more edge  over the
decentralized system.  Redundancy, there
is a good possibility for redundance in a
decentralized operation.  Project control
is usually a little bit on the side  of a
centralized  operation.    With  upward
mobility of people,  there are  advantages
in a centralized operation that you do not
have in a decentralized one.  There are
more  opportunities  to move within  your
specialty  field in a centralized operation.

      I would like to give our data systems
a report card.  First of all I  have tried to
list  some, though not  all, of  the compo-
nents  making a data system.  Starting at
the top, data collection is a decentralized
responsibility as far  as air data systems is
concerned.   ADP management I am  con-
sidering as MIDSD, a centralized activity.
Data collection  is toally dencentralized;
pre-input  processing is totally decentra-
lized at this time. In spring of 1972, there
was a  meeting of S&A directors at Crystal
Mall.  At  that time, every item on this list
would  have had a C^ on it for centralized,
as far as air data was concerned—every
item,  except data  collection.  At  that
time,  I specifically  stated that we would
work  toward  decentralization, and  we
have accomplished decentralization.  Pre-
input processing is one of our examples of
decentralization  in  which  the  Regional
Office and state and local agencies do all
the  pre-input processing.     Data  base
integrity at this  time  is a response of the
NADB; it is centralized.   Data base and
system maintenance is our  responsibility;
it is centralized.   Output processing  is
totally  decentralized.    The   Regional
Offices access  the data  bank  and  use
retrieval programs.  They make all their
own retrievals.  Data  use is as decentra-
lized as it can be.  I  have campaigned a
long time saying that.  There  is no  one
person or one group who is responsible for
data use or data analysis. All users should
be considered equal.   Data  system users
assistance  is centralized and,  obviously,
should be  centralized.    Data system
development is  a  centralized  function.
Special applications,  though, are  decen-
tralized.  As you well  know,  if you ask us
for a special program, we do not have the
resources  to do that.  Therefore, that is
decentralized.    The  hardware utilities
communications  are centralized because
it is the computer center's responsibility.

      The   one  thing  that  I  previously
mentioned  that I will bring up now is the
matter of input processing.  Currently, it
is a centralized responsibility as far as air
data   is   concerned.      Through   past
experiences and  a lot of problems,  both
with  ours  and others'  data systems, we
believe that it  should,  at  least for  the
time being,  remain a centralized responsi-
bility. That is not to say that sometime in
the future  it will not become a decentra-
lized responsibility. In fact, it is the next
logical  candidate  for  decentralization.
What I am getting at is that we have, over
a  period   of five  years,   moved  to  a
situation where we do have some  decen-
tralization and  some  centralization,  and
we  will continue to move toward further
decentralization, keeping in  mind the  dif-
ference between centralization, decentra-
lization, and total independence.

-------
                  THE MINI-COMPUTER AND NATIONAL SYSTEMS
                        Jim Susha, ChiefSystems Support Staff
                 Office of Water Program Operations, Washington, D.C.
     What I would like to do is share with
you my perspective  from Washington and
some of the concerns that I have watching
the emergence of the mini-computer on
the scene.  First, I'd like to give you a
little bit of background.   I am in the
construction  grants  program.   A  little
over two years ago,  we conducted a  study
to determine  what  the national require-
ments   for  managing  the  construction
grants  programs  would be;  this means
what the regions  would need to  manage
the program.  At  the time we conducted
the study, there were no mini-computers
in any of the regions.  The only thing we
had  at that time was a  contract  with
Optimum Systems, Inc. (OSI).  The  com-
puter system that supported us then and
now is because GIGS supports all the  grant
programs.  We went  through a study GIGS,
requirements,    and   subjecting    those
requirements to review by all the regions
before establishing a system.  In March of
this  year, we  installed that system, at
least the computer  end of it, in the 10
regional  offices.  We still had to develop,
region-by-region,  data collection  pro-
cedures, reporting packages, training pro-
grams  and all the other requirements of
implementing  a system.  Now  we also
went through  the  COMNET conversion
over the summer.  It was a setback for us
in terms of the system.  Having come out
of that, we now face credibility problems
in the regions in terms of  the  central
system being able  to support the regional
offices.

     Well, at  the  time we did the initial
study,  we recognized that we were really
in a  hierarchical   situation.   We  had
requirements out  there, some which  we
felt  could be met in a short timeframe;
others, we felt  could be met in a long
timeframe.  We divided our system study
into  two phases; short  and a long range.
The  short range, we defined as project
level  management.   In grant  programs,
this is really a project within a grant.  We
have also defined a long-range study that
includes  state  requirements.    It  also
includes the Corps  of  Engineers a level
that we  have not  supported which  is  a
contract  level requirement.  We still  are
not planning  to support that,  but  there
seems to be a contract level requirement
in the regions.  We went  ahead with  the
short-range system  and implemented it to
satisfy what  we felt was the immediate
need.  When that was  done we became
engaged  in  this longer-range   study  to
define what our long-range requirements
are.  This  long-range study  will address
data base management.  Again, when we
started the minis were not there; we did
talk of decentralization, distributed net-
works, and  distributed master files  to
support the heirarchical requirement.  We
are involved in the  long range study now.
Since the minis have gone  in our approach
and  thinking  has had to  adjust.  I have
seen  some  evidence that  the  mini-com-
puter  could   be  the   solution  to  our
problems if utilized properly.

      First,  the front  end  processing is
terrific,  as far  as  editing data and this
data  entry is  responsive  to  the user.  I
think that stuff is great.   The package
that I understand Region X has developed
and  passed  on to  the  regions  has real
merit.   But,  there  is  a  problem  in
supporting the regions requirements from
Washington that would  exist in any cen-
tralized  system,  particularly where  you
have  regional  offices  spread nationally.
We have  a staff and there is no way that
we could ever justify a staff  large enough
to meet the needs of ten regional offices.
It is just too great.  There fore there is a
necessity to decentralize the maintenance
and possibly the development, but it must
                                          A-25

-------
be  accomplished under controlled condi-
tions.  I do see some other problems even
in a controlled environment.

      We  come  to the  question  of the
master files and where do  they  reside -
how will  they be decentralized?  I have
seen evidence of what I will call a major
attitude change  in the regional offices by
the users.  Those regions that have minis,
they seem to be excited by the fact that
those minis are  in their  regions and that
they will  be independent.   They will not
have  to rely on central  processing; they
will be able to have their data processing
group  respond  to  their  needs  almost
immediately.  It remains to be seen just
how  that  works out.    Region   V   is
embarking  on an  effort  to  develop  a
redundant  file  maintenance  system,  if
that is correct.

      As  I  mentioned earlier,  we  have
acurrent redundancy problem; we have to
interface   with   certain  State systems.
Programs   were  delegated   to   certain
states, and many of the states have their
own computer  systems.    We have  to
decide how we  will  interface with  these
State systems.  I have defined two major
alternatives:  what I call  a transaction-
driven interface,  and the  other is file
replacement.  I  am drawing  an analogy
between the mini-computer in the regions
and the problems we have to face in the
states.   First we  were  working at  an
interface  between the central system and
the  states.   Now  I  see  an  interface
developing between  the  central  system
and  the  regional systems.   The  first
alternative to these common problems is a
transaction-driven interface  where  you
have two master-file systems being main-
tained.  One would be in a state system;
the  other  in the  national system.   In
Washington, we would have what we have,
that is,  a  regional  construction grants
management system which is supported by
GIGS.   The  transaction-driven  interface
would  generate  transactions  from  the
state system,  transmit them to ours, and
we  would process them into our files.  In
other words, transactions would be pro-
cessed  twice but in separate  files.   The
problems that I  see with  that one is that
you really  do have to maintain two sys-
tems,  because  you have to  work  your
errors off on both systems. You must also
reconcile those systems on a regular basis.
I  do not believe there  is anyone in the
world  who  could  keep two independent
master file systems in sync. There would
be  timing  problems.   One system  goes
down,  the  other   up.    The  resources
required  to  maintain two systems  are
expensive,  both  in reconciliation and any
error corrections  in  maintenance of the
two systems.    Those are  some  of  the
major  problems.     There  is  another
alternative, however, which  I  call  file
replacement.  This actually has  two sub
options:    file  replacement and  record
replacement.  Under a file replacement
system  the state  only has to transmit
their   file   (full  file  replacement)  or
portions  thereof (record  replacement) to
Washington on a weekly basis.  This means
only a  single  file  system  has to  be
maintained.  In interfacing two systems
like that, it is far less complex than the
software required for a transaction-driven
interface in  which you not only have to
reconcile, but you will also have to main-
tain the  transaction programs that inter-
face.    These  same alternatives apply
where  the  region would be maintaining a
master file system on the  mini.
                                           A-26

-------
                             QUESTIONS AND ANSWERS


Question:       For clarification, you are saying that you take the tape system and send
                send it over to GIGS.  You are replacing the GIGS file with the state file,
                or is it the other way around?

Answer:         The  movement of  the file  is  from  the state  or  the region  into
                Washington.  The advantages to that is  that it maintains a single system.
                There  are no reconciliation problems, and it is a less complex update.
                The software maintenance under this situation is minimal, so I think that
                in the two options,  I favor file  replacement.  That,  however, is an
                immediate problem, because I do not know of any  way that we  can
                prevent Region V from developing data maintenance systems in their
                region to support their construction grants operation.  So  this is an
                immediate problem.  I also see some long-range problems. I suppose that
                it comes in part, from the fact that I have come up very traditional lines,
                where  control,  efficiency, and responsiveness were important. The  real
                questions  that  I have  are:    in  the regions or in a decentralized
                environment, if there is not  any control  over development, there is not
                any control over system growth or direction.  Traditional  things that you
                go  through  when you  bring  up  a system—analysis, definition, pro-
                gramming implementation—if you do not have that control, then from my
                standpoint in Washington, it looks  very chaotic. If the regions develop,
                implement, and change  at will, then I cannot see anything but a chaotic
                situation developing.  I do not know exactly how we can control that type
                of environment because communication, cooperation, and coordination is
                very difficult with the long distances involved.  I guess I am here looking
                for answers to this, because the minis are out there. We are studying and
                looking at our long-range system requirements.  I do not  see any easy or
                planned solution to the problems.

                Another thing that will  complicate it,  I think, is the construction  grants
                program.  That  is only one system,  but  in a  study that we are conducting
                now, we  are also addressing an integrated environment.  In that, we will
                try to  draw three or  four Headquarter systems together, maybe  into a
                data base system. Incidentally, I see come problems in  that because to
                me there is a dichotomy between decentralized processing and data base
                management  systems.  DBMS is a centralized approach.  I have some
                notes taken out of some articles that I have read concerning some other
                problems.  They say  that the file structures between the  host and the
                minis should be the same, because in the truly distributed environment,
                the logical relationships between  those  files should be  compatible.  If
                not, you can create some horrendous problems  in moving data from one
                site  to another.  If we move  Washington  to  a data base  management
                system that integrates three or four major systems, then somehow  that
                needs to be kept in line with the  activity going  on in our regions over
                which we have no control. I am here not to answer questions, but to ask
                questions.  I would really appreciate it if anyone could spell out what is
                being done or what is going to be done to  solve some of these things I see
                as problems.  If there are not any problems, I would  like  to know  that
                also.

                                           A-27

-------
Response:
Question:
Answer:
One thing about control—I do not think things are really out of control.
Anything done in the regions will be done, I am sure, in concert with the
users in the region.   It is  his needs that are  primarily in the mini-
computer effort. I do not think there  is any intent to go a separate way,
without having control or the reconciliation  problem solved.  I do not
share your opinion that it is impossible to have two files reconciled daily
by a proper system design.  I appreciate the problems you have  about the
long-range goals. What I see here is requirements.  Who really needs the
data?  Do the regions need the data or daily management of construction
grant programs?  Does Headquarters need the data for the outside role?
That is a major issue: who really needs the data on a firsthand basis?

I have not been an active component of the issue in the forefront about
the GIGS  data base, with respect to the mini-computer site.   I have to
admit that I like your proposed alternative very much.  I think it is great
and am really glad you proposed it.  I think it is entirely workable to have
a system configuration where the regional offices maintain local  copies
of  the  master  file,  and in  fact, forward  that master file  copy  to
Headquarters on some kind  of a timely basis.  I think one of the biggest
complaints that we hear  in the regional offices is that the GIGS system,
as it  now exists, is simply not responsive.  It is not responsive  in the
sense that things are out of  your control.  If the COMNET facility is not
working properly, and  you miss an update, our users miss their  reporting
requirements. One concern I have to come back to again is that those of
us managing ADP  in the regions have to be aware of some of  the more
subtle implications of  your  proposals.  It  sounds  very  attractive on the
surface, but what it really means is that my system is more reliable than
the central  system.  The software  that would be developed to perform
the update is as reliable as the software that you have in Headquarters.
What I would propose  is that we work together on this.  I would  like
nothing better than to  see  you  find  the  development of  the regional
software to maintain a regional file that we could transmit.   I think  if
you would consider that, in additon to the one you suggested,  it may  in
fact relieve some  of  the  anxiety  you have  over  the possible chaotic
situation that could develop.  Quite frankly, we do not have the  resources
locally to duplicate the  GIGS, the  Arrow System, and who knows what
other systems  people  may  like  to have.   We do,  however, have these
machines  in the regions that can provide  very responsive interactive
capabilities  to users.  If we  adopt the position of working together on it,
we could certainly use  your resources to exploit some of the potential  of
the machines.

The  study  that  we  are conducting  now  will  take  a look  at those
alternatives. The situation that I was describing was one under which we
had no control,  because  as  you  know, it will take some time  for us  to
define the relationships among several file systems, and even  longer  to
develop software, implementation and training.  The situation I was
describing was one that  exists immediately.   I do not know how long it
will take  us to  get  there, I do not know how much  it will  cost us  in
resources, whether the resources will be available at the time.  I do know
the situation I used in the charts exists today; the states do have their
own computer systems.  It  is a problem  that we have to solve  today,
                                          A-28

-------
there has  to  be an effective interface between state systems and a
centralized system. One of the options, and to me the best option, is file
replacement.  It requires changes to GICS, because it is not in their
normal procedure.  Theirs is  a transaction-driven system.  If we have
minis out there  and we have three (I understand that a  fourth is coming
up),  one  region develops a data base  system using INFORM 11 and it is
completely redundant with the data elements that we have to carry in a
centraZized system plus some regional ones.  We would then have  the
same situation in the region that we  have in the state except that there
is no control; there is no way  we have the resources now to get out there
and  help you develop the mini because they just are not in-house. They
would have to be bought.  It is a long-term issue that we  are trying to
address,  and yet the issue is right in front of us  today.  This is the  one
problem  about which I am concerned.
                            A-29

-------
                       PANEL B:  EFFLUENT DATA SYSTEMS
                                Chairman: Jack Sweeney

                                Panelists:  Chuck Evans
                                          William Milligan
                                          Cliff Lundin
                                          Phil Taylor
                                          Howard Hein
                                          Pete Gattuso
                            INTRODUCTORY REMARKS

                                    Jacfc Sweeney

     Effluent data has been around for a long time.  It has been used for many decades in
the field of environmental engineering for design and planning of sewage treatment plants
and other industrial processes.  It has been used for water quality analysis and, more
recently in EPA, it has become a very important aspect of the development of guidelines
and the NPDES enforcement program. There seems to be a lot of usage of effluent data,
once you start looking around, but you do not see too much sharing of this  data.  Everyone
seems to be off doing their own thing and one of the things we would like to do here today
is to get people together and start discussing effluent data as a group, hoping that in time
it will  lead to greater sharing of data. When you start talking about sharing of effluent
data, this is where you start getting into the area of using data processing to support that
effort.  The first speakers are Chuck Evans and Bill Milligan from the Compliance Branch
of the Office of Enforcement, who will  be making a joint  presentation on the use of
effluent data from a national enforcement perspective.  The second presentation will be
given by three gentlemen from Region II.  They will be addressing  the usage of effluent
data at the regional level and the data processing system that has been developed in their
region  to support that effort.  The first speaker will be Cliff Lundin from the Status of
Compliance Branch, which is the prime user of the system.  The second speaker will be
Howard Hein,  from the  Data Systems Branch.  He is the  Systems Manager and the third
speaker  will be  Pete  Gattuso,  who is  also in the Compliance Branch.   The  third
presentation will be from Phil Taylor,  who is from the Water Quality Analysis Branch of
the Office of  Water and Hazardous Materials.  Phil will be giving us some  insight  into
branch activities in terms of using effluent  data for water quality  analysis,  particularly
toxic-related effluent data.
                                           B-l

-------
                     ERA'S NEEDS AND USES OF EFFLUENT DATA
                                     Chuck Evans
      Today in most regional situations, a
 sophisticated means of handling informa-
 tion in  general,  and   specifically  the
 handling of effluent data, is not in opera-
 tion.  Almost an army of clerks manually
 treat  everything  that  comes into  the
 Agency from all sources.

      Before I get  underway,  I would like
 to ask, how many of you have  worked  on
 water   enforcement   or   have   some
 experience with water  compliance,  the
 permit program, compliance monitoring or
 handle  effluent data on  a  routine basis?
 Okay, so  there  are  no  strangers  in  the
 audience.  Before we  get into the system
 that Water Compliance is using to handle
 effluent data and why effluent data is so
 important to us that we need some kind of
 system to handle it, it is  appropriate  to
 take a few minutes to reach back into the
 recent  past to understand why  we  are
 dealing  with the  national situation  we
 have.   The most  appropriate historical
 milestone is the enactment of the Federal
 Water Pollution  Control  Act;  or,  as  we
 would like to abbreviate it—the Act. The
 Act  resulted  in   something   called  the
 National   Pollutant   Discharge  System
 (NPDS).  It is a network  of investigators,
 information handlers, and decision-makers
 that has been set up to translate compli-
 ance information or raw effluent data into
 enforcement   decisions,    resulting   in
 compliance with general rules of water
 waste  treatment.    The  net  result  is
 cleaner water. This system also called for
 development of a  permit program.  The
 permit program led to the development of
 a  Federal  order  requiring everyone  to
 apply  for  a  Federal permit prior   to
 discharging  into  any  receiving  stream
 anywhere in  the country.  All U.S. waters
 are liable for this kind of  regulation.  The
 Agency was flooded with applications  for
 these Federal permits to  discharge.  The
system for  the issuance  of permits was
developed on the same basis that IRS uses
to collect taxes, i.e., a voluntary system
to gain the most cooperation in the public
and private  sectors with the law,  When
you  pay  your  taxes,  if   you  sign  a
statement  in  good  faith verifying that
everything contained therein is true and
accurate to the best of your knowledge.
This is consistent with the current Federal
philosophy  that  we will achieve greater
public compliance and reach the goal of
cleaner  water with  the  least amount of
resistance from the public.  The permit
program is established in the Act  within
the   National    Pollutant    Discharge
Elimination System.

   Voluntary compliance is  our  operating
philosophy.   The  voluntary compliance
with Federal regulations is in effect in 29
state jurisdictions where the state govern-
ments have enacted  environmental laws
with codes for  water treatment  that are
acceptable to the Agency.   The Agency
does not have primary jurisdiction in these
areas.   In  the other  states,  EPA has
primary jurisdiction.  There, all discharges
in both public  and  private  sector must
apply, fill out an application and comply
with  the  permit.    For  those of  you
familiar with it,  a  lot of   this is very
elementary.  But, I am leading up to a
situation with which you are also familiar-
-paper and information on paper.  We are
talking about the 50,000 issues permits
and  almost  as  many  applications   in
existence  today; that is a  lot  of paper
with which to deal.   If  we  handle about
100 information BITS with  each permit
application, that is  a lot of information
for relatively few clerks,  a handful  in
comparison to the amount of information
that they have to handle nationwide.

   Effluent data  is our chief handle on
exactly  what   is  going  into  receiving
streams across the country.  If dischargers
                                         B-2

-------
comply voluntarily,  we will get a pretty
accurate reading of  what is going on; we
will  be  able to access  pollutant  loads.
That way,  we will be able to assess what
is being taken out in time. Perhaps in 15
to 20  years  we  may have some kind of
yardstick for measuring how fast we are
cleaning our  water.  That is why effluent
data is key to us. We do not have enough
people to sit at the end of a pipe in every
out-fall  in the  country;  we  do not even
know where  all the  outfalls are.  That is
why voluntary compliance is key; that is
why attention to this  paper is key;  and
that is why effluent  data is key.

      A  permit  is  composed  of  three
sections.  There is a compliance schedule
which is nothing more than  a reasonable
forecast of  when that facility can plan
and build  the  level of treatment that is
required by regulation. It begins with the
development of engineering  specifica-
tions;  goes all the  way to the award of
contract; goes  to the  start  of construc-
tion, progress  reports,  completion of the
construction;  its  operation;  and   final
limits.    The   reason  that   the  permit
compliance schedule is so complex is that
the applications  from industries require us
to determine  what  the  range of  the
operation is  in terms of  input and output
so that we can determine what the pollu-
tant load is  likely to be under full opera-
tion, below  capacity and between opera-
tions. From all  of the various inputs into
the industrial  process,  we learn exactly
how much is coming out of the end of that
pipe, and  how it affects the stream in
comparison with other pipes contributing
to that stream.

      In  addition to the effluent data we
have a lot of  milestone events to track
(for the construction of  this waste water
treatment).    The  permits  require  the
facility  to meet certain  effluent limita-
tions once the construction is completed.
In most cases, the number of  limitations is
probably under 10 for  different chemical
units.   (If you  multiply that by 50,000
permits, you have a lot of information to
track.) The third element of  the permit is
the requirement to monitor and report the
discharge.  Again, this traces back to the
concept of voluntary compliance with the
law.  Like paying your taxes is  voluntary
as long as you report in  good faith, in
Federally permitted discharges you moni-
tor according to the requirement of the
permit, sample it at the required intervals
and with the  right equipment, and analyze
it according  to the laboratory analytical
techniques  recommended and appropriate
for that type of discharge, everything is
fine.  There are, however, a lot of critical
if's and but's  in there.  If you sample well
and analyze  poorly,  the data  is no good.
We will not know what is  going into the
stream, this  warps the  whole national
picture.   Our  only  method  of  quality
assurance is to verify all data through an
inspection program. The amount of infor-
mation coming to us based on the need for
effluent data is tremendous; we have to
track  everything that  goes on for  our
permit  application,  the construction  of
treatment facilities, the attempt  to find
tune the plumbing, so  that it will have a
final  limit.   There is a lot of overview
required to see that the appropriate tech-
niques  are   used  to  analyze  the  data
gathered  by  the   floor   measurement
devices, that people who use the devices
know  how to  use them. That is a big job
for roughly  60 positions  in  the  United
States for 60,000 permits multiplied by all
their  requirements  within each permit—
the construction schedule, the effluent
limits themselves, and the reporting and
monitoring requirements.   All of this has
to be handled some  way  and has to be
immediately    accessible   to   decision-
makers within Enforcement, not  only in
the Headquarters office, but  also within
the regions.

      Before  we get  into  that  system,  I
would like  to  touch  on  some  of  the1
operating   philosophy  that Enforcement
has had and  with  which  it is currently
operating.    In  the  beginning,  with the
NPDES   program,    we   sat   around
Headquarters trying to figure out how to
cope  with 10 of the regulations, with the
billions of dollars we were appropriated to
                                           B-3

-------
 get the job done, and with the handful of
 people we had to do it.  A  lot of effort
 was devoted  to  trying to coordinate  the
 people disbursing funds to  municipalities
 for treatment of facilities with the people
 that were actually writing  the permits.
 We need  management information  sys-
 tems, forms,  ADP systems, etc., that  can
 be  converted or that integrated  nicely.
 Back in the days  when things were getting
 underway, it  was a  matter of showing
 permits  so that  people could be awarded
 grants to build.  Then they could get  the
 construction  started.    If  construction
 started on those facilities which achieved
 the best  practical  technologies,  whose
 standards would  result in the most pollu-
 tion abatement, then the Agency would be
 leapfrogging  ahead  in time,  given   its
 management  problems.  So we come to a
 point in time where a lot of  money  has
 been spent, people have permits, facilities
 are nearly completed or, in most cases, at
 least able  to operate on routine basis.
 Still the problem in the Agency is whether
 the water is getting any cleaner. We have
 now reached  a phase  in our  Enforcement
 central  philosophy where we  no  longer
 worry so much  about getting  money  out
 and getting   permits  written as  we  are
 about enforcing the  schedules  of  those
 permits.   You can achieve clean water
 faster by building treatment  facilities,
 and treating water than you can by suing
 people over and over again and dragging it
 out through the courts.

      We  have  reached  the  phase   of
 attempting  to  achieve  compliance   by
 technical support, by guidance,  and  by
 follow-up.  We follow-up  based on what
 we read.   We read a lot of numbers that
 are  the  results  of the requirements  to
 report   effluent  data,   to   describe
 discharges in chemical currents.

      At  this point, we can start to look at
 what this means to the human beings in
 the regions whose job it is on a day-to-day
 basis to deal with all of this information.
 What is key effluent  data?  The emphasis
was on getting construction of treatment
completed.  Now, however, we  are going
to take enforcement action not only for
violations of  construction  requirements
but  especially   for  not   meeting  the
effluent   limits  contained  in  Federal
permit.  Individual firms and EPA agreed
upon  their   own  permit  requirements.
About  80 to 85 percent of all industrial
major permits—about 5,500 out of 50,000
permits we have issued for which EPA has
jurisdiction—do  have construction com-
pleted  and are able to achieve operational
limits;   they  are meeting  the  permit
requirements in terms of effluent limits.
Less than half  of  the  roughly  22,000
municipal facilities  meet  their  require-
ments  because  they  cannot get construc-
tion completed either because of  lack of
state approval, delays,  or funding delays
with grants or tie-ins to other systems.
This is  what regional auditors live with on
a  day-to-day  basis.   They get  effluent
data in   the  mail  and  they  have  to
interpret  it;  they  have  to be  able  to
determine whether the numbers make any
sense,  whether all of the needed informa-
tion was  reported for  the  permit under
audit, and whether any  more data can be
used in subsequent technical evaluations.

     If we are not shrewd in our part in
arriving  at  treatment  technologies that
make it  easier for  someone to monitor,
sample, analyze and report data, we really
cannot  do  our  job  at the  Agency  to
expedite  the  water  cleanup.    These
reports come into the Agency  usually on a
quarterly basis.   Given  the  number  of
major  permits that  are  in effect  right
now—for  the facilities  that we  have to
pay  attention to more closely—we have
about 100,000 pieces of paper  just for the
majors alone.  This is exactly the situation
that forced our  division to  rethink the
process of handling  it all in the regions.
Two to three years ago, when  Mr.  Quarles
made his annual visit to all the regions, he
noticed  cardboard   boxes  on  top  of
cardboard boxes, full of progress reports.
This is exactly what caused Mr. Quarles to
pull his lieutenants together and say that
the  regions do not  have a  system  for
handling reports. The dischargers spend  a
lot  of  money  having  it  analyzed and

-------
sampled; we do not  know what is going
into the receiving streams. Somebody has
got to come up with a system for handling
it.   Effluent  data is key;  but a  more
automatic way of handling it is absolutely
imperative, not only because of the sacks
of mail, but because of the situation here.
Human   beings  just  cannot   read  the
reports,  interpret them,  and make good
decisions about them because  we do not
have  enough  of them.    It is not cost
effective to hire any more. It takes about
60  positions nationwide to  handle about
100,000  permits.    Imagine   the  data
problems when you add to  that 300,000  of
those  PMR's  that  come  from  minor
facilities where we  do not have the time
to  look, but  must if we  do our job  as
public servants according  to the Act.  A
half million pieces of paper a year—all  of
which have at least, half a dozen chemical
parameters—have  to  be  reported  on a
quarterly basis. You just keep adding the
time sign and another number and you are
talking  about 60  people having to cope
with an amount of information  that just is
not feasible.  But, they are  hacking away
at it right now.

      I do not think that we need to spend
any more  time verifying  that effluent
data is key.  We cannot do our job without
effluent data and we are getting it now  on
the DMR form. The real kicker is that we
are going to  continue to  depend  on that
handwritten  form, voluntarily  filled-out,
in the future.  The Agency stuff, like IRS,
comes with returns every quarter. We get
these DMR returns, discharge mo>v taring
reports;  and the number of permits to  be
issued will  increase  tenfold.   Thus, the
number that we will be getting in the mail
will increase,  but  the position that  we
appropriated  to  handle   them will not
increase.  This is a good time  to get into
what we call  the  Enforcement Manage-
ment System.  When Mr. Quarles sees the
piled   boxes   of   the    DMR's   and
Congressional reports in  the offices,  he,
from his  experiences  as  an attorney,
knows that  if the Agency is going  to  do
anything, figures that this will probably go
through  the  courts, at least to establish
some kind of  national credibility.   Any
case depends on good evidence.  If all of
our evidance is unread, unopened,  and in
cardboard  boxes  lining   the   halls  of
regional offices, we are just going to fail.
Our track record in court can somewhat
back  up  that statement.   Several  task
forces in the Agency were convened over
the summers of 74 and 75. They met and
tried   to  devise  some  fancy   way  for
handling  all this information.  Since the
people on  these task  forces were high-
level managers, they designed elements of
an Enforcement Management System that
was so huge that ordinary people working
at the regional level could not possible get
a job with them. They took the philosophy
again, hung it at the door,  and got down to
paper work.  Out  came a simple routine
for handling paper that contains effluent
information as well as other information.
It was called "compliance information."
This enables the  60  positions  we  have
nationwide to translate most of  the criti-
cal stuff  to decisions of whether  or not to
act.

      The slide tells the whole story of the
business  about  the law,  voluntary com-
pliance,  commercial or in-house analysis
of sample effluent and recorded informa-
tion, it shows the step of mailing informa-
tion to regional EPA offices, the audits
there. The question mark in the middle is
an  attempt  to lead  you through  the
various  tasks by  sorting,  according  to
priority-determining,  what  you  have in
terms  of major  discharge  information so
that you can focus on that right  away,
moving right through to whether or not it
is  adequate  to  evaluate  on  factor
enforcement procedures, and to determine
which ones are actionable—where we have
good  chances  of  taking  an action  and
accomplishing compliance. This  technical
evaluation  results  in  that enforcement
decision which automatically leads  into an
action.   This is  all written into guidance
that has been sent  out as a directive from
the AA for enforcement.  Following up on
that, we  tracked the results of that action
arid store the result.   When the action is
retrieved, it is not done purely  to fill in
the    squares   for    a    Headquarters
commitment, but  also for national water
                                          B-5

-------
qualities   studies,    and   for   public     same routine again and again.  We find
information.   One of the major  reasons     analytical  techniques so  that when we
that  this  effluent  data needs   to  be     pick up that effluent data, we see a trend.
collected accurately and handled properly     If  we keep collecting it over a period of
is  for use as a factor in decision-making     time, we will have a good idea whether
patterns.  Every quarter we go into the     anything  we  are  doing  is resulting  in
                                             cleaner water.
                                           B-6

-------
                       PLANNED EFFLUENT DATA SYSTEMS
                                    Bill Milligan
     For some time we have been looking
at  effluent   data   from   an  agency
standpoint.     We   realize   there  is  a
tremendous problem out there; it is very
large, and  we  do not quite know how to
handle it.   In  the  spring  of 1977,  we
commissioned  a  feasibility  study   by
Arthur Young and finished it in 3une.  The
results  of  that study  went  out to  the
Regions. The next thing that we  saw  was
a  violent   reaction  from  the  Regions
because the study aroused a  multitude of
problems.  When we talked to the  Regions,
we tried to find out what were  the  real
problems.     We   have  come  to  the
conclusion  that maybe there were not as
many problems as the Regions thought.  I
know that  Sam Conger of MDSD is here
and I would like to bring up one point.  We
have heard that we are trying to resurrect
GPSF and that is not correct. We are not
trying to do anything like that at  all.  The
results of the Arthur Young Study pointed
out five system phases based on  require-
ments  which Arthur Young thought were
necessary.  The first, Option 1, was pretty
much where we are today. The checkered
in-boxes represent  automated functions
within the system.   Now, as you walk
through these, boxes, you will find that we
have DMR  forecasting.  Under Option 2,
Arthur  Young is  saying DMR  issuance.
This  would  involve  preprinting  DMR
forms, forecast and track the DMR:  the
initial   screening  will   be  automated.
Under Option 3, they have added  substan-
tive screening  to  the DMR processing.
Under   Option  4,   they  have  entered
violation history.   Under Option 5,  they
have entered action  tracking. Now in our
discussions  with the Regions and among
our   own    people   in   Permits   and
Compliance, the consensus is that Option
5 is probably the best system. As you can
see, it has  quite a bit more in it than what
we currently  have.   We  do  not  want to
resurrect a new type of system  that will
do all of these things.  We looked around
when we first completed this study.  We
indicated  which systems were available
that could accomplish this and the only
system that had all of these things was in
Mississippi. They have a very good system
and it is written in COBOL.  It is  an easy
system to  operate.   They  did not have
action tracking or the violation  history,
but it was the only system around that
would  satisfy our  needs.   He sent  the
feasibility  study out  to all  Regions.  It
went  to  three people in each  Region;
namely, the  Administrator, the Enforce-
ment  Director, and  the  ADP  Branch
Chief. With  each  study we  sent  a letter
requesting  to have  combined  responses
about the system.   We did not get  many
combined replies.  We have received two
or  three  Regional  responses  with  the
Administrator signing a combined reply.
The  other responses  came  either  from
Enforcement  or ADP.  Region HI sent in
two of them  one from ADP and one from
Enforcement.  They wanted  to be doubly
sure  that  we  received  their  message.
Since that time we  have  been  working
with Region II. They  seem to have  found
the key to putting  the  system together.
They  have  all the  functions that  we
require.  They do not have a  combined
report writer.  This is what we would like
to add to their system.  We would like to
take their  basic LEDS system and  add a
report writer on it.  Essentially this would
provide us Option 5 but we do not want to
store actual effluent  data in our  system.
The  only  things that we would  like  to
store are the actual violations.  We would
like  to store effluent data in STORET.
Recently we  have  been  working with the
STORET  people.   MDSD has agreed  to
have their people  work with us  to help
coordinate any problems.   The  primary
benefit of phase one is preprinting the
DMR form. It is one of the major  benefits
that we have heard from both Region II
and Region VII who have it.  Preprinted
DMR forms  will usually  come  back  on
                                          B-7

-------
 time.  In most cases, they will come back
 completed.   We think that this is one  of
 the  biggest advantages  of the  system.
 The Region II  LEDS  system provides the
 capability   for   DMR   violation/action
 tracking as well.  I will let them discuss
 that later.  Our main concern is preprint-
 ing DMR forms, tracking the receipt  of
 DMRs   when   they  arrive,   initially
 screening the  form  to see whether they
 have violated  their limitations, and  sub-
 stantive screening to identify the level  of
 violation.    Now,  suppose we  have   a
 permittee that is marginally in violation,
 just a  fraction, for  a period of three
 months.  There are some  marginal viola-
 tions that are  going to take a substantive
 type of screening.  We want  to  look  at
 them  on a long  term  basis  to  figure
 whether they are in or out of compliance.
 The feasibility study's Option 4  is  really a
 phase one system. Arthur Young proposed
 a two   phase  system  approach  for  us.
 Phase  one  is  a  basic  system similar  to
 what LEDS  has in it.  A phase two system
 is a day-to-day management system.   We
 have had MRI Corporation come in and  do
 an evaluation  of EDS vs.  PCS.  We felt
 that Data Base was just a little ahead  of
 us at this time. We feel that there is not
 enough data in PCS  to  warrant  a Data
 Base.  My personal opinion is that we are
 talking  about  a billion bytes.   We are
 currently   at   three  hundred   million.
 Projected costs  for  system development
 of phase one are: $58,000  for design and
 programming,  $27,000 for support  pro-
 cedures and training,  and $158,367 for
 enterining permit limitations.   Phase one
 is for majors only, if I failed to mention
 that,  I  am   sorry.    For  phase one, the
 operations cost is $262,542 a  year.  We
 feel that  although  this  is  high,  it  is
 reasonable.   If you are looking at costs
 and trying to equate  what these costs are
 going to give us, I can say that in the past
 month   there have  been  at  least fifty
phone calls  from  industry, congress, and
all over the country from people looking
for effluent data.  There is a definite need
for effluent information throughout  the
country. As Chuck pointed out, to do  our
job in  Enforcement  we  must  have  this
information.   The  Quarterly  Noncom-
pliance Report is being changed right now
to  contain  more  than  just  compliance
schedule violations.  In the future it will
contain effluent violations and without an
ADP system I find it hard to believe that
there can be any other method to  manage
effluent data.

     Phase two  is a day-to-day  system.
It is considerably more expensive.  If  you
are going to have a complex day-to-day
system  then you'd better have some sharp
people to maintain the system.   It is  not
just buying  the software to maintain  the
system, you  need people who understand
the  data,  the  system  itself,  and   the
relationships of the data.  We  do not have
that capability right now and don't plan on
getting it  for  a few years.  We do  not
want  to tie the Regions  into  a  system
when we cannot handle it.

     A development system under phase
one   gives   you   several  benefits   as
previously  mentioned.    I  feel  that  in
twelve months we can develop a phase  one
system  utilizing  the  Region II  system.
Right now we  have talked to Region VI
and VII and they  have agreed  to pilot  the
system.  At the end of the 12-months  the
Regions   would   make   the   go  ahead
decision. We would try to cater  it to their
needs.   We would also try to have Region
II  oversee  the  whole operation, allowing
three Regions to be  involved.  The total
time of bring the  system up would be 27
months.   That inlcudes bringing  all  the
Regions on board  and purifying the data.
This is  not going  to be  an  overnight
operation;  it will  not be cheap.   It   will
take time.
                                          B-8

-------
 INTRODUCTION - THE REGION II EFFLUENT DATA SYSTEM PURPOSES AND GOALS
                                    Cliff Lundin
     What  my  colleagues and I  from
Region II are going to  try to present to
you today, is an example or demonstration
of how one region has taken the problem
of what to do with effluent data and how
we have  handled it.  I just want to  point
out  that  we  are  not  here to  sell our
specific system to  anybody; we are here
to point  out the concepts which we used
and  some of the directions in which we
have gone in developing our system.  I
think  that  you   will  see  from  our
experiences that  we have proved that an
ADP system can be used effectively in the
EPA Water Enforcement program.

      In the next few years, the emphasis
within EPA  in  the  Water Enforcement
program  will be on effluent data. That is,
to  see  whether  or  not the equipment
which has been  installed  can  meet the
effluent  limits  which  were  set  in the
permit   guidelines.    To  do   that, we
designed our LEDS systems.

      We started our design back in March
1976. Our prime purpose in designing the
system was to enhance and streamline the
Region II efforts on Discharge Monitoring
Report (DMR) violations.  In doing that,
we wanted  to  meet the criteria of the
Enforcement  Management System  (the
EMS) of  which  Chuck Evans  and Bill
Milligan,  just spoke.  Another one  of our
goals was  to   utilize   manpower   more
effectively.  Previously under our manual
review system,  only major  DMRs  were
reviewed.  The data was entered manually
on a summary sheet; at times the backlog
ran  from one to two months.   Using our
LEDS system all permitees are reviewed
and  only  those that  are in violation are
looked at by our  technical staff.   The
system also provided us with a  historical
summary of effluent data.
     Our  third purpose was to improve
our response time.  DMR's are constantly
coming in.  In Region II, this approaches a
rate of 900 per  month.  Under our manual
system,  we at times had a backlog of one
to two months in review. EMS calls for a
minimum response time. We have made a
commitment to  thirty days or under. With
our system, we  are  meeting that commit-
ment and in addition, all DMR's (not just
majors) are being reviewed.

     A  fourth  goal was  to provide  for
action violation tracking.  What we have
done in  our various outputs is  provide a
past history, so  that you can tell instantly
by  looking  at  the report,  how long a
permitee has been in violation, or whether
or  not  this  is  a  one-time  occurrence.
Another purpose was to provide a control
file from  which summary date  could be
obtained.   Again, with  the  summary  we
would have  the data, right  there  at  our
finger tips  without having  to  research
back into the  files.  Another  important
goal was to aid  the  permittee in fulfilling
his reporting requirements.  Especially on
the minors, there  was  a  great deal of
confusion  on the part of the  permittee
about  what  exactly  was   his   permit
requirements, what had to  be reported,
and when it had to be reported to us. The
uses of the  preprinted DMR  gives  the
permittee guidance  as to what we  expect
from  him.   It  also gives him  a  better
understanding of what his limitations are.

     Our   seventh   purpose   was  to
eliminate  administrative errors. A large
number  of DMR's  were coming in off-
cycle  or  with  the wrong  parameters.
These were relatively  minor violations,
that were taking up a large part  of  our
enforcement  time.   With  the use  of  the
DMR  preprint,  we practically eliminated
the administrative deficiencies.
                                          B-9

-------
     Finally,  our  last  purpose was to
enhance our decision-making process so as
to see  where we were going and what we
could do with the effluent data.  In going
about this, we  set up a number of design
goals.  Specifically, we wanted to have a
system  which  was  implementable  in  a
relatively short time with  relatively few
changes   to  our   existing   set-up  of
reviewing the DMR's.  We felt that going
to  a  new  form   might   confuse  the
permittee; we wanted to use our existing
system with few administrative changes.
Our  second goal  was to  have  enough
flexibility in the system in order to adjust
it  to our  regional needs.  At that time,
EMS was only a proposed system.  We did
not know what  the final version would be.
So we had to build enought flexibility into
LEDS so that we could adapt it later for
the  various  Headquarters  requirements.
Our third goal in designing the system was
to be  able  to coordinate  it with other
aspects of our regional system  and  the
various national systems.  In Region II we
have a  multi-tiered  level of permit  data
computer files.  We  wanted to be able to
relate  this, by  the permit number to the
other facility level  data available.   We
also  wanted  to be  able to relate it to
national systems, such as STORET, so that
it   would  be   compatible   for  future
comparison.    Hopefully,   utilizing   our
system,  we  will  be  able   to  have an
objective  evaluation  of   the   permit
program and its effectiveness.
                                         B-10

-------
                REGION II: SUMMARY AND FUTURE SYSTEMS USAGE
                                     Cliff Lundin
     So you have just seen how, in a little
over a year  and eight months, we have
been able to design a system which meets
our purposes and goals, which implements
the basic requirements of EMS, and which
provides  a significant data base for our
use in  EPA.  I would now like to go into
some of the future intended uses.

     The first  use is our Suspects Report.
This should be in operation within the next
month to  six weeks.  Its functions will be
to  look  at  the DMR's  and  determine
whether or not the permittee is possibly
lying to us.  In  completing the DMR he is
signing a  statement that  he is telling the
truth.     The   Act   provides   criminal
penalities for  any  purposeful  false mis-
statements.  One of  the  things this pro-
gram will do is to  look at  the DMRs for
whether or not the  permittee is reporting
the same thing, consistently, without vari-
ation.   We recently  turned up one case
where  the  permittee  had reported the
exact  same   values  to  us,  for   four
quarterly  periods in a row.  He will pop up
on   the   Suspects  Report   for   this
consistency.  The second criteria utilized
in this program would be whether or not
the value reported for the parameter is
outside the normal expected  range.  For
instance,  a  primary  sewage  treatment
plant may report a BOD of 2 miligrams
per liter.  This is  beyond  its capability.
Our system  will be programed to isolate
these facilities.

     The  second future prospect, for our
system is its  use in our state overview
program.  We have two states, New York
and  the  Virgin Islands which  have been
delegated responsibility over the NPDES
program.  New York has their  own data
system.    What we  will  be  doing  is
designing  a conversion  program.  Once a
month  we will  get a tape of the reported
data and run it through our system.  We
are going to establish a separate limit file
for the major discharges only so that we
can use our system for overview.

     The third possible  future report is in
"candidates  for inspection".   This  would
somewhat  combine  the criteria of  the
Dirty  Dozen  Report,  plus the  Suspect
Report  to   help   us  and  the  permit
engineers prepare a list  of which facilities
need to be inspected.

     Another application,  which we  are
using already to a limited  degree is with
the "208" planning program. In our Status
of  Permit Development (SPD) file,  we
have a field called "208" Region.  When
the   208   interim  plans    come   in
inventorying the facilities in their area we
enter them into the system. We can then
sort on the SPD system to see the total
number of dischargers in the 208 Region.
Another  possible  future   area  is   an
interaction  with  the  Toxics  program.
There  is  also  the  possibility  of special
sorts, i.e. by parameter.  We  also are in
the process now of entering the latitude
and longitude for each discharges into our
system,  so  that we  can  do  specialized
sorts by lat/iong, by  counties, by major-
minor sub-basin, or even by SIC codes.

     Finally   we   have   talked   about
depositing  this data into  STORET,  or
interacting it with STORET ambient data
base,  to  see  the  effectiveness of  the
NPDES program, to see whether or not as
total  effluent  loading  goes  down, river
quality  improves.    This  is  the  basic
question,  the effectiveness of EPA.  We
may also get into some  plotting and other
sophisticated   techniques,  particularly,
trend  analysis   in  order  to  be  able to
predict if a facility, based  on past six
compliance factors, is getting nearer and
nearer  to his limit, and when he will go
over it. We would also  look at whether or
not there is  too much room between what
he is reporting and what  his limitations
actually are.

-------
     To  sum up, effluent  data is a key
part of  EPA's  enforcement  posture  in
enforcing the  Federal Water  Pollution
Control Act amendments.  Effluent data
can  and  is  being  used  primarily  for
enforcement.  But I think  that we have
shown that it can be used for many other
purposes  particularly  the  208  Planning
Program.  Through a coordinated effort of
the  technical,   enforcement,   and  ADP
people, I  think that we have come up with
an efficient and effective ADP system,
which has enabled us to get better use of
our manpower resources.  It has enabled
us to gauge our effectiveness in enforcing
the NPDES program and allowed us to do
a  timely  review of  effluent  reports.
Finally,  I  think  a  system  like   this,
combined with our other systems, helps us
pull all the aspects  of our enforcement
program  together in order to advance our
goal of  cleaning the  nation's  waters.
Thank you.
                                        B-12

-------
                             QUESTIONS AND ANSWERS
Question:
Howard Hein:
Question:
John Sweeney:
Question:
Cliff Lundin:
How  will  OE  Headquarters'  recent initiatives  along  the  lines  of
implementing CAS effect your program? Do you plan to adopt CAS?

I guess it depends on what the final structure of CAS will look like; I am
inclined to take full advantage of whatever is available on the national
level.  One of the things that CAS will have that the regional  system
does not have  is a report writer that will enable the system to be used by
the engineers out in the technical areas and perhaps also by the states. I
think that  the system will be opening up to more people.    A report
writer is a big advantage.   One major  difference  between what Bill
Milligan was presenting and what we  have in ours is that we do want to
keep  all the data for six reporting  periods because we  think  that is
important for  the engineers and attorneys.  Mainly the engineers use it in
reviewing what has been going on with the  discharge before they make an
enforcement decision.  Maybe if that problem is cleared up then there
would be no inconsistency between CAS and what our system does right
now.

I would like to ask a  question of the enforcement people.  Jack,  I would
like to find out when you folks are going to go to the mini-computer and
whether or not you are looking at this  application as  something with
which you may want to concern yourself on the computer?

Well we are about ready to issue a statement of work. Arthur Young has
been contracted to do a feasibility study for the mini in Region II.  That
is  one of the systems  at  which we  will  ask them to  look.  It really
depends on what they find in the feasibility  study.  The system has
COBOL programs. Apparently COBOL is not available on the mini. That
is an obstacle. I cannot see us converting this system to a mini if  there
is going to be a big conversion effort.

The second question that should  be addressed to the enforcement  folks in
the region is:  Could you give us a description of the analysis done before
you went into the system.  Then, what kind of impact has the system,
now that it is operational, had?  Has the nature of the workload, not just
the quantity, changed?

Before the implementation of the system, we had and  still have about
800-900 DMR's coming in each month. Approximately 400 of those had
to be reviewed manually.  With this system, it has taken the load off New
Jersey and Puerto Rico. Prior to that, we had two people, temporary,
but full-time  para-professionals, evaluating them.   Three other people
from  the staff also pitched in and helped on a time available basis.  We
still had a  backlog.   With the implementation of the system, we again
                                           B-13

-------
                have two positions, again they are para-professional temps who review
                the DMR's part-time.  Their responsibility is split, half time with manual
                review of New York DMR's and half with review of the LEDS reports put
                out by the system.  Three other people pitch in on a part-time basis for
                the LEDS  system  reports.   The nature  of their  work  has changed.
                Previously, all they would do is detect the violation, make  a cover sheet
                or a violation report form, list the violations, and forward them on to the
                engineering staff.  What is being done now is that para-technicals review
                the exception report, then they  consult the DMR for keypunch errors;
                they review the permit itself to  be sure  that there were  no  notices of
                non-compliance  or anything in the permit file to indicate  the nature of
                the violation.   As a third step,  they review our compliance print-out
                which is a mini-history of the permit, to determine whether or not they
                have an adjudicatory hearing or an active request for modification.  They
                then come up with an enforcement recommendation.  Their work is a
                little  bit more technical than  it  was  before  i.e., they detect the
                violations and then they  come up with an enforcement recommendation
                which then goes to one of the specialists, who either okays or modifies
                the recommendation. It has changed the nature of their workload. It is a
                little bit more technical; it involves a little  more research work, it will
                eliminate a lot of the  drudgery of sitting there  and just  manually
                reviewing numbers. The  nature of their work has definitely changed. We
                have the same  number  of  people,  but  we are getting a  lot  more
                effectiveness out of them.

Chuck Evans:    / do not  know if I can really add  a great deal to what Cliff just said but
                there are some interesting sidelights to the question you posed. One that
                I have  observed in  some of my original research in Chicago, relates to
                the old system of leaving the job  of the massive organization, filing, and
                ranking of all of the effluent data.  When you left it up to  the clerks,
                administrative   assistants,   environmental   protection  assistants,  or
                compliance technicians, or whomever handles this data at the first crack,
                it is such a ponderous job that we  were able to measure their workload as
                well as their attitude during the peak, the  shock loading as  it came  to be
                known  in the  region.  When this stuff  fell on  them at  peak Monday
                mornings in the cycle, we noticed that the technicians  were calling in
                sick more often and were taking  more and longer breaks.  As time  went
                on they were getting less and less work done per day in terms of actual
                cases  that  they were able to complete.   This  was not just  something
                about which we had a hunch;  it was dramatic enough so you could see it.
                T*eir whoZe attitude changed.  I do not know if this is something that
                occurs across the country, but it  occurred there.  This stuff  would just
                fall in their laps in such amounts that they had no way to cope with it
                except to stack it up and start at  the  top of the stack, take one DMR at
                a time,  and go through it.   Since they never  saw the  stack getting
                shorter, their whole job orientation, their attitude, everything just  went
                into a  tailspin.  In support  of what Cliff has already said about the
                accuracy with pre-printed DMRs,  the fact is that a lot of the work is now
                secretarial.  The screener's job, or whatever you want to  call it, it is a
                lot more professional; they are encouraged to be more professional and
                do  it a little bit better.  It  lets  them pay more attention to what the
                numbers  really  mean rather  than whether the decimal  point is in the
                right place or not.  I do not know if this adds to your understanding of the
                situation but it is something  I thought was incredibly interesting when I
                was doing research out there.

-------
Question:       When you implement CAS, do you visualize having a total  headquarters
                file of all 10 regions or 10 separate implementations for each region that
                would like to have it?

Bill Milligan:    When / implement  CAS, what / see is having one master file, sequential
                in nature, and probably just  the  way STORET is being updated today.
                What I see coming  is that  we will take that file and we will segregate all
                the  compliance schedules,  the  effluent  data,  the  inspections, and
                violations in separate files.  They will be indexed and these will key our
                facility file. We will get a permit number in which you win find a match
                for the record we want. We will go into the other files, pull the data out,
                and set it up for printing.  For reporting purposes they will be indexed for
                updating purposes,  at least sequentially.
                                           B-15

-------
                       ADMINISTRATIVE EFFICIENCY REPORT
                                     Pete Gattuso
      Clifford  mentioned  some  of  the
 goals  we had  in developing our effluent
 data system; I would like to show that we
 have  achieved those  goals  to a  great
 extent.  In order to see how  our system
 operates,  we  looked  at  some  of  the
 reports or outputs that we get from the
 computer and how we use them. In doing
 so there are two fundamental points which
 really show the value of an effluent data
 system.  First  of all as the  data comes in,
 it is screened against permit limits  and it
 is permanently stored on a computer file.
 The fact that we  store the data  means
 that we  can go in at any time and retrieve
 data from previous months and display it
 in a form which  gives a discharge history
 for  that  permit.   Storing  the data  has
 other benefits which we will talk about a
 little  later.    The  second  point  is  the
 benefit common  to all computer systems,
 the  ability to obtain a multiplicity  of
 copies of the  output.   This is especially
 valuable in an  agency like EPA where you
 have  several   different  groups   with
 different functions  all working towards
 the  same goal.    For  example, in  our
 situation we  have five different  groups
 intimately involved with these discharge
 permits.  We have the compliance branch
 which is responsible for the initial detec-
 tion and  inquiry into the  violations; we
 have the engineers responsible for techni-
 cal input both to  EPA personnel and  to the
 permitee;   we   have   the   attorneys
 responsible for the follow-up enforcement
 actions,  the   Surveillance  and Analysis
 Division  which goes out and samples the
 facilities,  and the  state  agency  which
 contributes  to all these different  areas.
 And the point I want to make is that all of
 these  five  groups  really  benefit  from
 having at  hand  the  kind  of  reports  at
which  we can look.    Consequently,  the
Agency's response as  a whole  is greatly
enhanced.
     The first thing we will look at is the
pre-printed DMR form.  Basically, this is
the  main  source  of  our  data.    It  is
generated  from   two  basic   files,  the
facility level file, for most of the heading
information, and  the permit limit file for
each    parameter   and    corresponding
effluent limit.   We generate  this every
quarter, and send a three-month supply to
the permitee.  When we send it to  them
we include a notice which  explains it to
the permitee.  Of course,  this tells the
permitee exactly  what he has to report,
and it  reminds him of his effluent limits.
It  really imporves  the  quality  of  his
reporting to us.  It is returned to us in the
mail and there  is  no loading involved,
because  our  keypunchers are  trained to
take the form and keypunch directly from
it.

     At this point  I  want  to mention
something  about  accuracy  of  the  data.
When  these forms come in we have to
trust that what the permitee is telling us
is  true.  He does in fact sign a statement
indicating  that  he  is  telling the  truth
under  penalty  of law.   We  do suspect,
however,   that   there  may   be   some
permitees who  are falsifying  this type of
information,  though  probably   not  too
many.   There are a number of  ways that
we can deal with  this.  First of all, we can
go out and sample the facilities ourselves
and compare that data to what is  being
reported.   This  is  something  we do
periodically for each discharger.  We can
also  run a  computer program  with this
data which can determine if a permitee is
possibly  falsifying his report.   Another
thing  that   really  contributes  to   the
accuracy of the data is that we use it on a
day-to-day basis  as a working tool, so we
have the opportunity  to  observe obvious
errors  in the input and to  correct them.
One  tool is the effluent violation report.
                                          B-16

-------
This is generated whenever  a DMR is
reviewed by the computer and a violation
is  detected.   It tells us what  parameters
were in violation and if there were  any
administrative deficiencies on the  report,
such as a failure to report an item.  It also
gives somewhat of a discharge history for
those parameters in the form of the past
six reported  values.    In planning  this
report we  could  have done it two ways:
First of all, we could have had only those
parameters that  were in violation  printed
out  or we could have printed all  the
parameters as long as there was at least
one violation.  We chose the latter method
because  in reviewing effluent violations
we have found that it is many times very
valuable to have other parameters which
may have  a  distinct  relationship  to  the
violated  parameter in a way  that would
effect our judgment.    Looking  at  the
report on the  left-hand margin, we have a
single  asterisk which indicates an effluent
violation,  a double asterisk indicates  an
administrative deficiency  and  a  triple
asterisk would indicate both cases for that
parameter.  Then we  have the effluent
limits  for  each  parameter, the reported
value,  the frequency of analysis required
by the  permit   and  reported by  the
permitee,  likewise for  the sample type
and then we have  the compliance  factor.
Now this compliance factor is a ratio of
the reported value to  the limit,  or in the
case of a  minimum reuqirement such as
dissolved oxygen, it is  the inverse, such
that, in either case, a compliance factor
greater than  one indicates  an effluent
violation.  The only exceptions to this are
p_h,  temperature,  and  percent removal
where   we  felt  a  ratio   would  not
accurately  indicate  the  extent  of  the
violation.   In those  cases we  have  the
acutal reported  value as  the  compliance
factor. Then we  have the most recent six
compliance factors for those parameters.
We could  have  just  as  easily put  the
reported values  there, but we chose the
compliance factors because  it is much
easier  to see at a glance how the permitee
has  been  doing   rather  than having  to
compare all those reported values to the
limit.  This report is sent to a number of
different places.  It is sent to the engineer
for his technical input.  If the  violations
are very serious, it is sent to the attorney,
a copy is sent to the state agency, and a
copy is sent to one more very important
place,  to  the permitee himself, the com-
pany.  Now it is a requirement of these
permits  that  if  a violation  occurs  the
permitee  should tell us why it  happened
and what  he is doing about it.  If he fails
to do  that, we  send  him what my boss ~
calls a nastygram.   Basically  this is  a
violation  letter  telling  him he  had  a
violation  which  was not explained  to us.
He has 14 days  in  which to do so. The
letter refers him to an attachment for the
violations that we are citing.  We simply
take this computer sheet, circle the viola-
tions and  staple it to the letter. We also
include  an  explanation  sheet.    This
package  constitutes our initial enforce-
ment action.  We have had a great deal of
success with this; the permitees really do
respond  to it.   Of course, if we were
reviewing   these   monitoring  reports
manually, it would take us a long time just
to  discover those  reports  that have  a
violation.  With  this system, we only look
at  those  that have violations.   We  can
respond   to  the   violations  sometimes
within  a  week after receipt  of  the DMR
and usually never more than 30 days. This
is for  both majors and minors.  We are
very satisfied  with the way  that it  is
working out for us.

     The  next   report  is   the   total
summary  report  which contains all  the
data we  have,  all the limits  and  the
reported  data for those facilities.  Again,
it is a  very simple report.  There is basic
heading  information  on  top,   and each
parameter is  in  the  left-hand column.
These include the effluent limit, the units,
and the six most recent values.  These are
not compliance factors, but the  actual
reported   values.   As Howard mentioned,
this report would take up about  4,000 plus
pages on printout, so instead we get it on
microfiche.   It  turns out  to  be a very
convenient tool because all  the different
                                          B-17

-------
groups  who  are  involved  with  these
permits have access to microfiche reader
or reader-printers. We get the microfiche
in five copies and distribute  them.  In  a
very  easy  way, we have supplied  all the
people  who  are  involved  with  these
permits with all the data in our system.
Of  course, if  you save the old copies of
the microfiche, you will always  have the
complete   historical   record   of   the
permitees1  discharge.   Now  this  is  of
obvious benefit  for anybody who is at all
involved  in these  permits.    Just  one
example would be the S&A Division who,
when they  go  out to  sample a facility,
would like to see exactly what  is in the
discharge and what are the problem areas.
We had a case in the region just recently
where  a  permitee  was  found  to be
falsifying his DMR.    The permitee did
admit to falsification.   The interesting
thing about it,is  that we  would  have
caught  him over a year ago  because at
that time  the S&A division went  out to
sample  the  facility,  except that  they
failed to  sample for that one parameter
that was being falsified. With this kind of
data, readily available to  them, I think
that  this  type  of  oversight would  not
occur very often. Now just briefly I want
to go into  the remaining two reports, the
statistical  report which  simply  tells  us
how many  DMRs  were  reviewed.  The
total  broken down  into  all  the various
classes is located on the bottom.  On top,
the classes are pretty clear.  In  the left-
hand  column,  we have the State  and an
"F" for final limit; the "I" is  for internal
limit. This report is of value to us  for our
report to Washington.
     Next is the administrative deficien-
cies report.  This is  generated whenever
DMRs  are reviewed and no violations are
found but  there are  some administrative
deficiencies.  We can use it in the same
fashion as the effluent violation  report
although   it  is  not   of  such   great
importance.

     Now, I want to go briefly into cost.
We have broken down the monthly cost of
our system.  Computer and time-sharing
costs of  $200 month includes all the edit
programs,  inputs, reports, retrievals; it
also includes the  microfiches.   We feel
this is a very modest cost to pay.  Key-
punching at 6,000 cards per month costs
about  10  cents  a card.  Then, we print
95,000 lines at $1.20 per line.  Costs, then
amount to a total of $942.00 a month. As
indicated,  the total is  for  1200 permits.
This may  be  a little  deceiving because
many of the permits report monthly, but
many  report  on  a  less frequent  basis.
Thus, we are actually  getting about  500
DMRs  per month.   In judging the cost,
however,  the total has to  be  taken into
consideration  wherever file  size  would
affect  the cost.   One  final thing  that I
would like to mention is that anybody who
is  at all  involved in getting effluent data
will soon discover that there is an awful
lot of  it.  The files grow  quite large, so
the cost goes up.  Some kind of archiving
is  necessary. We plan to archive the data
in  the near future, keeping six records for
each parameter  on the file.  We are not
sure just how we are going to archive it,
but STORET has been mentioned  as  a
possibility.
                                          B-18

-------
                                     Phil Taylor
     I  am  with  the  Office  of  Water
Planning and  Standards, Monitoring and
Data Support Division.   Most of the work
in our  division  is  associated  with  the
consent  decree   from  which  the   129
priority pollutants evolved.  We do inter-
relate (Figure 1) with some key divisions
in Headquarters.  CSD, the Criteria Stan-
dards Division,  works  on water  quality,
criteria, and toxicology.  We  work  with
the Effluent Guideline  Division regarding
treatment  technology and permits.   We
interface with  the  economic areas  of
OA&E.   All these  put together  are  in
concert  with what is coming out of the
S&A Programs in the regions.  We  have
four  major  contracts  associated  with
environmental study areas shown in Figure
2.  These deal with sources of pollutants
and  an  industrial inventory.   We  are
looking at the  fate  of water  pollutants
after they have been discharged.  We are
concerned  with their relationships,  with
their  physical,  chemical, and  biological
behaviors in waters, and how  they pass
through  the  food chains.   We are  con-
cerned with levels of the water pollutants
in the environment.  With our contractors,
we will be  monitoring along with  the
regional S&A programs, ambiant  waters,
fish   tissue,   water  supply,  and  some
effluents.  We  will have  some exposure
studies;  our main interest in exposure is
regarding the human population in those
areas  where  there  are  drinking water
supplies  contaminated  or potential  for
contamination.    All   of  these  keyed
together  provide  for   risk  assessment,
which will be going on  for the next 12-24
months.

     Figure  3  is  one example of a risk
assessment approach that has a  number of
modules.  Modules may be entered  at a
different point depending on the amount
of data available.  As you can see, we are
very interested  in animals, humans, fish
and aquatic life and the  exposure levels
and how we  can assess the  environment
regarding the 129 water pollutants.  The
use of  our  toxic  studies will be quite
varied.  The first level is in response to
the regulatory process and best available
treatment  guidelines.   We will  be con-
cerned with ranking of industries, the sub-
categories,   and   the   environmental
significance of  the  water  pollutants.  We
are going  to assist  in helping the Agency
in its position in legal challenges and with
control   alternatives,   particularly   in
section 208, 307 and 311.   In those areas
we   know  that  there  are  some  toxic
problems.    We are going  to indicate to
such programs as  Air, Solid Waste  and
Toxic Substances, that there are problems
that we cannot manage under PL 92-500.
For example, we have to assess fish tissue-
data, we are expanding that program with
the Fish and Wildlife Service.   Environ-
mental  mapping  (Figure 4)  of  water
quality data shows at a  glance  mercury
levels in the United States. This area will
be expanded each  year for example to
include  information on  fish tissue  levels
averaging the 129 water pollutants.  This
map indicates  four  different levels of
mercury present  in the environment  and
also  shows us those areas where we do not
have any  data.  So, in  working with the
regions and the contractors, we use this as
our first  level to  assess  where we  are
missing data, where we  have  data  and
what the levels are. In this case, we had
10 years worth of data we can tell what is
happening  in the  environment  such  as
mercury concentrations are getting lower
in some  geographic areas and  in some
areas they are getting  higher.   As  in
Figure 5, nationally it is about 50 percent
of the areas samples are getting  better
and 50 percent are getting worse.  It did
not show us anything significant except  in
some area we do see trends of clean up.

     Regarding the  industrial  inventory
project, we are using two types of data
bases.  One is referred to as the EDS Data
Base which is similar to PCS data.  The
other data base  is Dunn  and  Bradstreet
(Figure 6) shows the industrial  concentra-
tion  for  one  of  organic chemical  SIC
category  throughout  the  United States.
                                           B-19

-------
                                             REGULATORY DECISION
                                         REGULATORY DECISION
[REGIONAL N&NITORING
                                                                                           AT ION
EFFLUENT GUIDELINE PROP.
           VOMI t libr t
% 208/NATER QUALITY MANAGEMENT
S 302
S 307(a)d)
S 307(a)(2)
     WATER QUALITY STANDARDS
                                  Figure 1

-------
to
LU
I—t
o
g
LU




(N
Dp

£
                                              EXPOSURE
              MATERIALS

              BALANCES
         DISTRIBUTION
               &

            TRENDS
                AMBIENT
                                              RISK

                                         ASSESSMENTS
 HUMAN

TOXICITY
                             HUMAN

                             TOXICITY

-------
EMISSIONS
        ENVIRONMENTAL]
             FATE
        (  MODULE   1  J
           GEOGRAPHIC
          DISTRIBUTION

           MODULE  2

        FISH & WILDLIFE
            EXPOSURE
       C

MODULE  3

            RISK TO
        FISH & WILDLIFE
                                            EXPOSURE
                                            ROUTES
                                       FISH & WILDLIFE
                                       BIOACCUMULATION
                                 HUMAN
                            BIOACCUMULATION
                                 HUMAN
                                TOXICITY
                            FISH & WILDLIFE
                                TOXICITY

                              LABORATORY
                            ANIMAL TOXICITY
                                                     FOOD
                                                CONTAMINATION
WATER
SUPPLY
                   Figure 3
                    METHODOLOGY FOR RISK ASSESSMENT

-------
                                                     Figure 4    Environmental Protection Agency
                                                                                    System
                     UXZMD
            Cone.           t of
Shading  Range (ug/1)   Covered Area   I of US
         No Data
           0
        .0001-.29
        .30-.60
        .61-19.9
All    1577 Cells
 33
 21
 24
 22
100
 47
 17
 11
 13
12
53

-------
                                                      Figure 5
                                                            Bivixcmental Protection Agency
                                                                      CTOHET System
blank
 t
  4
  O
No Data
Mora than 25% Inproveroent
Between 101 and 25* Inprovarent
l£88 than lot Change
Between lot and 25% Vtorsenlng
More than 25% Worsening
Area Coveredi 17 Percent of US
249 Cells
  7 Cells
 17 CellB
  6 CellB
222 Cells
SOI Cells

-------
 \   W^


flU  T
 C ~~ r* O IT T C V w i -• r'\
 u i U t\ C !  o T O ; L. i !



  CRGRNIC  CHEilICRL MRNUF  _^  ,


       S.I -C.2869  FROM       VA

       D  4  B   JULY/77

A CRG CHEn rrs


-------
 The Dunn and Bradstreet data file has a
 data base of 300,000 records as contrasted
 to  the EDS  data base  of  about 55,000
 records, so geographically, there would be
 a much  different  picture  of industrial
 concenttrations.   We do  environmental
 mapping  and analysis of industrial data
 the  state levels.

      I think  the  most interesting project
 of  the four  contract  areas is  what  we
 refer  to  as  industrial  facilities profile
 project.  It is an inventory of industrial
 facilities in  the  United  States.   We are
 going   to   inventory   industries   at  the
 facility level for only the 21 industrial
 categories  identified  in the  settlement
 agreement.   This covers about 700 sub-
 categories  which  will be quite an effort.
 There are  two  major parts of the indus-
 trial  environment   in  which   we  are
 interested.  One  is direct  dischargs gen-
 erally represented by the PCS data base.
 The area  which  we  will have the most
 work  to  do  is what  we refer  to  as a
 indirect discharge—those industrial facili-
 ties that discharge into muncipal sewer
 systems.    For  example, the  direct dis-
 chargers   recorded   are  about   45,000
 permits out of  some  65,000 applications.
 The indirects are unknown until  we get
 involved with actually inventorying those
 facilities.    When we consider  700 sub-
 categories  for  21 industrial groups, Dun
 and Bradstreet  files showed 300,000 faci-
 lities.  One sub-category alone has 55,000.
 Thus,  we can see that  we have a very
 formidable task ahead.

      One of  the  steps that is involved is:
 agreeing  to  the  definition, the  type of
 data we  want  to collect at  the  facility
 level.  Figure 7 identified the  first cut of
 those  data items that we are going to
 collect at  the  facility  level.  In  many
 instances,  it  is  generally agreed  that the
 SIC  codes are in error and it will be a lot
 of work to get them corrected. The other
 situation  is that  we  do not  have good
 location information on  industries, parti-
 cularly their  latitude  and longitude.   We
are  going to  look at  PCS  data, our EPA
data base, Dunn and Bradstreet, municipal
 needs files, trade  associations,  regional
 files  and state files. Before we go to the
 regions we  are going to take these differ-
 ent data bases and, where we can, match
 them and merge them  together and make
 assessment   of   which  data  we   can
 ascertain as being most accurate.  After
 that step, we will then plan to go to each
 region. Our present plan is to do Region II
 first.  We plan  to get  to Region II about
 the middle  of January. We are going to
 depend on the PCS data first, then (unin-
 telligible) for the direct discharges.  We
 are  talking with  Enforcement  and  are
 concerned with coordination of their work
 and   their   data  files  so  that  we  can
 minimize duplication.  Any data we have,
 anybody is welcome to it.  If anybody has
 some data that will make our job easier,
 we will be happy to work with them.  We
 are glad to  hear that everybody is doing a
 good  job  here  because we  will have to
 depend on  those  regions that have data.
 For the next cycle, we will  probably be
 able to develop a  better strategy.  We are
 going  to be using the industrial facility
 data  for material balances  and distribu-
 tion trends in the  environment to assist in
 the risk analysis.   We will be concerned
 with  the geographic distribution covering
 the 21  categories of industries, and the
 special analysis concerning  some  of  the
 sub-categories.  The profiles and analysis
 of this data  will be supportive  of the EGD
 program.  We have a small contract over
 the next 30 days  for a special  study on
 municipal waste treatment  to study the
 129 priority pollutants.  We will  be work-
 ing with industrial ranking to  make an
 assessment of which industries may be the
 biggest problem and which types of indus-
 tries have the biggest problems;   We  will
 also be looking at  point source versus non-
 point  source  problems.  In  the coming
 year,  we have some other data bases that
 we will be  using  to  assist  in analyzing
 water quality and  industrial facilities. We
have a digital data base of streams in the
 United  States  which we  refer  to  as  a
reach file.  It consists of stream which are
shown as a  1:2,500,000 scale map and was
digitized in 1976.    This  file  contains
22,000  river  segments.   Each  segment
                                           B-20

-------
               Figure 7

       PROPOSED DATA ELEMENTS
                 TOR
      INDUSTRIAL PROFILE STUDY
NPDES Number
EPA Region
State Code
City Code
D&B Number
County Code
Name of Facility, Business, etc.
Address
Area Code & Telephone Number
River Basin Code - Major
River Basin Code - Minor
208 Planning Area
Facility (Utility) Owner: Public,
Private, etc.
1972 SIC Oode(s)
D&B Number
River Mile Index
Industry Group
NPDES Permit Authority Natie
NPDES Permit Issue Date
NPDES Permit Expiration Date
Major Discharge Indicator
Effluent Discharge Receiving Type
   (stream, land, ocean, etc.)
Discharge Flow to Municipality
Discharge Flow to Surface Waters
Discharge Waters Name
Dischage Point Location, Lat. & Long.
Discharge Number
Multiple Point Discharges
Compliance Schedule Date

-------
averages about 16 miles, and covers about
350,000 miles which is about one-tenth of
the estimated total  miles  of  streams in
Figure  8  is  a  digital plot  of stream
segment data for one portion  of the U.S.
We are working with the Water Research
Council and USGS with this data base. We
are  interested  in identifying industrial
facilities along  these streams. This data
base has many other  uses of which differ-
ent people can take advantage.  The data
base can be used  for example to supply
water  resource  statistics, water manage-
ment  statistics,  miles  of  stream  with
improved water quality miles of  stream
not  meeting standards,  and modeling.
Also   data   on  industries   by   stream
segments, which industries would be under
permit, which industries  are  discharging
toxic pollutants,  which  industries  have
water  quality data.   It  would provide a
variety of different things that people ask
regarding river basins and segments.  For
modeling,  there  will   be   macro-type
modeling, such as  mass balances for con-
servative substances.  We will be  able to
know what is going  into  the water envi-
ronment  by  individual  streams.   At the
level of  20,000 stream  segments, there
are  many things that we will be working
on, keeping in mind  we are talking about
one-tenth of  the  streams in the  United
States.
                                          B-21

-------
Plot Of All  Streams '.ngitized
     In Portion Of U..S.

         Figure 8

-------
                             QUESTIONS AND ANSWERS
Question:
Answer:
Question:

Answer:



Question:
Answer:
What are your plans for the (unintelligible) data that would be collected
via your  contractor or  with  the compliance  inspection program that
would be carried out by the  regional S&A people?

First of all, the inventory that we win be making is at the facility level,
it is not at the pipe level.  In cases of direct discharges that  can be
transferred to their use; the question of the  effluent data there is three
sources of data:  regarding the  129  water pollutants one  is guidelines
Division.  Our contract and the one in the Effluent Guidelines Division,
there is our contractors and the S&A programs in the regions.  Regarding
those effluent data we plan to put those in  the water quality file.  We
will have pointers to relate to those effluent listing in the inventory.

How are you going to keep your data up-to-date through the years?

At the moment, we are not planning to update the data other than do the
first cycle with the contract.   At the end of  the contract we  will assess
what our position is and what our next step will be.

Phil,  the basic issue is  how many independent kinds of  efforts  we are
going to have going on within  the Agency?  I am wondering if there is
anyway we can take (unintelligible) particular subject at this point. It
concerns me that we have regional systems that are being developed; two
national  inventories of effluent  or discharging facilities, one in Water
Enforcement and one in Water Programs.  We do not have a lot of overall
coordination in the development of these systems.   It  is a  hierarchial
type of problem.  At the top you have two major offices. The Office of
Enforcement and the Office of Water Hazards. It seems to me those are
the two  offices at Headquarters are the most  involved with  effluent
data. Over on one side, we get into the program enforcement. Then, we
run into another  hierarchy with 10 regional offices being at different
places in  terms  of  implementation.   Each  region has its different
priorities, different personnel,  different capabilities.  It is hard to reach
agreement  even  among them as to  whether there  is  a  need for an
effluent  data system.   Even if  there is, what is the  time frame in
implementing such a system.  I think the CAS  study is going to be a
mechanism that eventually hammers out some kind of resolution.  I think
that the mechanism is there.   I think that study has to  be  implemented
with the Office of Water Hazards Materials.  That was one reason why  I
asked Bill the question of whether  that would be  considered  in the CAS
feasibility study.  To me, that seems to be  the  mechansim to carry it
about.  What  other alternatives  do we have  for getting  people together
and trying to resolve this question of sharing effluent data?

We know our contractors cannot  do everything.  We will be going to each
one of the  10 regions.  We will physically  go out to each  one of the
regions and sit down and figure out the best  way to identify and work on
the industrial facility profile problem. Some regions are in better shape
than others, and some have  less resources than others. All we are trying
to do is to get a list of those  industries at the facility  level. We know

                           B-22

-------
Question:
Answer:
Question:
Answer:
that there are a lot of errors in that. It is a lot of work to do that but we
are anxious to get it done because we need to  make an assessment to
support work related to  the consent decree and make an assessment of
the toxic substances in  the  water.  We will work cooperatively with
anybody who wants to so we can get this thing on its way. I think part of
the file can be very helpful to the  different programs to come to some
agreement that there is  a facility out there, and yes it is still producing
pollutants whatever  its number.  I think there are a lot of things that
could be accomplished cooperatively over the next few months.  This file
can be  used by a  variety of people, and at the same  time, we will be
taking advantage of different software packages  and analysis packages to
better assess what the data means.  I think that  another area that we
have  not talked about here is analysis, and how to make use of it.  We
need to use the data  we have, even if it is limited, or at least try to get a
better handle on  what is out there in the environment.   Is the water
getting better or is it getting worse?  Which industries are cleaner than
others?

Who was going to  coordinate this whole overall effort in EPA in terms of
working together on effluent data?

It seems to me that  Enforcement plays an important role in that respect
because of the bulk  of the effluent data that is being generated  by the
Agency through the  EPA permit program.  Perhaps, we can use the CAS
vehicle to bring about this coordination.  I do not think you can look to
the regions to bring about this kind of  coordination.  I think  it has to
come down from Headquarters. It seems  to  me this kind of effort should
be left to  Headquarters, not just to  coordinate, but  to pull the regions
together so that they can become actively involved. I think that there is
a reluctance on the part of the Office of Water  Enforcement to take the
leadership  role in managing the effluent data.  They  are  looking at it
strictly from  the standpoint of reporting.  The data will  be made
available to other  people in the Agency.

I have a question,  Ted.  We talk about trying to get a uniform agreement
on the  (unintelligible)  that we mentioned to get involved  with effluent
data  within one program area Enforcement.  There is still not really a
general agreement as to where we are going with  effluent  data.  Maybe
you could elaborate, Ted, on how your region would feel, how you react
to that CAS study?   Are the regions so dead set against  effluent data
that it does not want to  get i nvolved with any type of study along these
lines?

As you are aware, the situation that the regions  faced two or three years
ago  was that we  were trying to define what the regions, as a group,
needed in the way of an effluent data system.  We had a meeting of the
10 regional ADPs about two or three years ago.   We attempted to sit
down and hash out our basic needs. At that meeting, the 10 of us could
not come to any agreement whatsoever as to what the basic set of needs
was.    Headquarters then  went on  to  pursue the  development of  a
compliance analysis sytem.  I suggested to  them, when I was down at
Headquarters earlier this year, that in order to insure the development of
the sytem, we needed to  justify the future uses of that system.  They had

                         B-23

-------
to obtain the concurrence of the Regional Administrator on the system.
Now, I think it was pointed out earlier here, that Region III had two
different responses to  CAS.  We are not against automating the effluent
data per  se.  But the  problem we  are  having is that  CAS  as originally
proposed has some  very significant weaknesses  in it.  One that has
already  been mentioned is  involved  with the initial  data  collection
efforts.   I believe Arthur Young estimated that it would take  10  man-
months to collect the permit  data for all 10 regions.  I  believe your
estimate  alone said 9-man months  to do one region.   It looks as though
the data  from the regions is grossly different from that which Arthur
Young has submitted.  The second  is that  Arthur Young had indicated, I
believe, in their feasibility studies that one of the justifications for going
to CAS was the manpower savings.  Again, it has been pointed out that
here you really do not  save manpower.  What you do is shift the kind of
work that is going on.  If the Agency believes that you save 40 positions
by automating DMR's I think they are in a  sad surprise when the system
actually comes off, Especially if the regions are then told  that we now
have to eliminate 40 positions  from the Enforcement  Program.  I  think
there  will  be some  adverse  reactionsfrom most regions.  The  third
problem that we had with the system as it  was proposed was that we are
having  problems getting the state data  into  the system,  and  we are
running into questions about how are we going to require the states  to do
this?

So, we are not opposed to automation.  In fact, we still see  that there is
a need to have this data somewhere available for use for water  planning
for toxicology and for overall  environmental monitoring efforts to help
us develop the environmental quality indices that we are moving toward
as an agency. The problem that we  have right now is the mechansim that
is being proposed to do that.  I would urge  OE that they should come out
with a new feasibility  study that addresses, in detail,  the resources that
are going to be required to implement  CAS.  As discussed  in all of our
previous  zero-base budgeting  meetings, part  of  that feasibility  study
must  include the operational costs  for  the regions for at least the first
two years.  I hope  that OE is  aware that  they must include those  costs
because  that does add a significant change to the impact of their cost
projections for CAS.  We had some  reservations on the (unintelligible) as
to what was required to implement  CAS. We found a manpower savings.
What happened was the time, the position  saved in the actual manpower
screening of DMR's was put to  use  in more enforcement follow-ups.  So,
it allowed them to re-invest those positions in some priority stuff, really
getting into  what they should be doing. The one concern voiced by the
enforcement director in our region  was that if you start to  include all of
the minors in this system, you  are going to have a list of violations that
he is never going to be able  to handle. He is concerned about the data
problem itself and is against putting minors into the system. How can we
deal with minors' reports if we do not have the resources to follow-up on
the violations?  We have been  asking that  question of headquarters and
even of our  Enforcement Division.  Why have the data come in, in the
first place, if we are not going to  do anything with it? I  can  perceive
two main points  coming out of' the discussion that  we have  had today.
The first  is that the CAS feasibility study really needs to  be looked at
again, more legwork has got to be done, with each of the regional offices

                         B-24

-------
                in terms of trying to  explain the purposes of using an automated data
                processing system for  screening DMR's.  We are trying to pin down the
                resource requirements and projected cost savings.  The second item is
                that some effort above the EPA, whether it be a task force or some type
                of steering committee, should address the question of the agency's need
                for effluent data.   How that would actually come about,  I do not  know,
                but that would be  one of the recommendations that would come out of
                this seminar here today.  Is there anybody that would like to elaborate on
                this or are there any major points that should be  brought out?

Answer:         I think one thing that we could do with the CAS response is to distinguish
                between two issues; one is the automation of DMR's and one is the need
                for effluent data.  They are not necessarily coincidental.   One of the
                basic problems that law enforcement people have with the CAS study is
                not an effluent data collection per se, it was an automated DMR system
                which, in a sense, was to make  the data effort  more efficient.  The law
                enforcement people felt that they could deal with violations  without the
                automation of DMR's  even though they would still like to have  effluent
                data available to them for various analysis, etc.  How would they know if
                you did  not automate the DMR function?   How wouZd you  collect the
                effluent data?  Do not confuse me,  I am not  saying  that we take the
                DMR data and put it back into an automated system, what we are really
                talking  about,  is taking  (unintellibible)  and  putting  it  under  the
                microscope, detecting the  violation, and throwing the rest into (unintel-
                ligible).  You have a whole series of clerks, engineers, and programmers
                involved in this whole process.  What our enforcement people are saying
                is that they do not think that whole enforcement procedure is necessary.
                They can see a  procedure  for  somehow  getting hold of selective,
                accurate,  valuable effluent  data,  i.e.,  having  a system that  can
                manipulate the data  for  various analysis,- but not necessarily taking
                automation of DMR's as a mandatory procedure. They are very opposed
                to  that  idea.   I  think the new  CAS study could make that distinction
                because  I think that it is an important one for the Regional Enforcement
                Officers.
                                          B-25

-------
             (MONENTARY TAPE FAILURE: SESSION RESUMES WITH...)
                We are finding  that many of the  questions they  had were  already
                answered. I think Dallas was one region—they started checking back into
                it and tried to come up with a different view that it might not be as bad
                as they had originally thought.  They felt that our cost was not justified.
                We cannot justify our cost resources in the study.  We ahd a subsequent
                meeting with MIDSD and PRO and we specifically said  where  are your
                problems?  Arthur Young was there.  The answer we got at MIDSD was
                that they had no problems with our resources and cost.

                The third group that  we have to go through  is Program Reporting.  They
                want us to do an impact study on how the system will affect the regions.
                I  was talking with Arthur Young yesterday. We have our outline from
                Program Reporting and now we are trying to accomplish that.  We have
                already begun on it, and we will h ave it done in about three weeks.  Does
                that answer your quesiton?

Answer:         Yes, basically.

Question:       Our region has initially taken a look  at the various systems which were
                proposed.  There seems to be no concensus that we really wanted to get
                involved in tracking  and handling  an effluent data  system.  With the
                Region II presentation, however, we see  that there were more  nuts and
                bolts.  I  think my regional  management would have a  lot easier time
                swallowing it and understanding what it is.  I am  hoping that you were
                going to do that in one way or another.  Is that the case? You are going
                to come back and say that here is what we are focusing on?

                What we are focusing on is the complexity of the data.  I felt this all
                along.  It is a monstrous job. Region II has  done  the  groundwork for us.
                Arthur Young laid our the structure for a system  that (unintelligible) for
                detail data only.  Region II has already accomplished that.  We could use
                a systme like EPA to get a report writer, I  think we are going to end up
                in a very good position for all these reasons. But  again, it is only going
                to be what you put into it.

Bill Milligan:    / want to ask a question and hope to get some response from some  of the
                other regions.  If you  had the capability of the Region II system  available
                from a national system would you use it?

Answer:         Ted Standish  from Region III.   As  I  understand it, the current regional
                comments coming in from the Regional Administrators is that we are
                against automation as it is currently proposed.  We are willing to look at
                any pre-proposal by Headquarters.  We are  primarily concerned that OE
                and OWHM talk to each other and  make sure that there is coordination.
                We are also very much concerned  about  the problem of our delegated
                states who have to fall to the permanent use their own DMR's. We have
                problems under OMB where we cannot force  any state to use Agency
                software.   We  are going to have problems in  trying  to get them to
                convert their data into our format.  Now you have addressed it  by  saying
                that you are willing to talk to someone at Headquarters to underwrite all

                                         B-26
Bill Milligan:

-------
                the conversion programs, but that is assumming that the states are going
                to go along with that, and that the regions' (unintelligible) is willing to
                condition the grants. So, as of right now, the general consensus seems to
                be:  we  can handle the situation manually, for the foreseeable  future
                unless we see  a better proposal out of Headquarters, this will be our
                conclusion. I would think what Mike was getting at from Region I is that
                if you did come back to the hard proposal, the description of the Region
                II system, I think it would simplify our review  within the reigon to have
                something specific  at  which to look,  something specific  on  which to
                comment. That would give us the resource impact.

Question:       Ted, could you shed any light on  what kind of discussions you have had
                using STORE!  or fitting STORET into (unintelligible) information data.

Answer:        / presented our implementation plan to Sam and he is on his way out here
                right now.  I have  somebody in my office right now that is going o work
                with us on data retrieval for three ot four months.   We have been very
                scared.  I think it is extremely complex; it will take a  ot of people with
                experence that we just do not have on board.   I am  relying on Sam's
                service to help us  out  in this area. We got some very good input from
                him already.   The  plan we have is to take the data and load it  in the
                retrievals.  Once we get our system up  and running we are operational.
                We plan to have a combined retrieval using a PCS-type of format, select
                retrieval which would go into both STORET and NCAS, retrieve the data,
                and set it up for printing. I have not had a chance to  sit down and talk
                with  Sam much about  that.  Most people know about  it.  The only
                objection I made to Bill was the fact that (unintelligible).  Why don't we
                use some intermediate system?  Why don't  we just go ahead and use
                STORET  directly?   We  got into  the politics and  discussion and all that
                sort of stuff.   I do  not know  who that one is going to  come out.  The fact
                that we are going  to wind up somehwere in concert with each other,  I
                think it is a reZativeZy giant step if you ask me, and maybe we can solve
                the other one,  too.

                Is that going to built into our final CAS feasibility study?

                Yes, I guess it  would be.

                We have  already gone ahead with you guys on a pilot on this deaZ to see
                how it is going to roZZ. I am pretty sure Region VI has gone ahead to give
                it a shot.  If we do not like the way it operates, we will probably wind up
                doing our own, just Zifce we have done with our other systems.  That is
                basically where we are going to be,  as part  of  our implementation
                procedure.  We go ahead with this thing nationally, Region VI and VIII are
                going to have to sign off on it. We are not going to shove this thing down
                anybody's throat.

Question:       I would like to address this question to Region II.  How do you resolve the
                inconsistent manner in which permits are written to obtain the  pearly
                conditions utilizing summer students?  That came up earlier in  our lonely
                efforts.  The permits in (unintelligible) are very wacky to say the least.
Question:

Answer:

Bill Milligan:
                                           B-27

-------
Howard Hein:
Question:
Bill Milligan:




Question:

Bill Milligan:

Question:


Jack Sweeney:
How  we  resolved  it was that we  appointed  one person,  Cliff, as a
technical coordinator  to  interpret the permit conditions.   When any
question came up,  if necessary they went and  tracked down the person
who actually wrote the permit to get the interpretation.  That would be
documented in each file by something in writing such as a written memo.
But we had one person who was responsible overall for seeing how the
conditions were interpreted.  It  worked out pretty well.  We tried to
bring that out in the implementation, i.e.,  that filling out data bases is a
big job; you technical people have got to get involved with spearheading
and  interpreting  the  data.   I think  in the original CAS,  one  of the
proposals was to do it by contract. The problem was that you have to get
regional involvement, you  have got to get  the people that actually wrote
the permit to interpret them.   Another thing that come up with the
permits is that they were  confusing to summer  students;  they were also
confusing to the permit engineer.  A number of permits were revised, or
at least a permit was clarified to what the permit acutally meant.

You  mentioned the requirements of the NPDES  Program  to  obtain
information form the states for Headquarters requirements. Many of the
states have programs, but in all probability they would not have all the
data elements in the system  which you would require. From where would
you get this informaiton?

We have already started using CAS as a contract to fill in any loose data
we do not have.  Region V is doing it now at CAS and we are going to
start doing it with  everybody at CAS.  Computer Science is going to fill
out our missing data.

Are you going to go out to the states and find their  BMS also?

That's right.

Does the same thing hold  true with the development of programs for the
states who do not have their own computerized system?

The  ultimate  responsibility for  the system   lies with  the  regions.
Somehow the  regions are  going to have to get that data.   There is a
conversion problem between the  states and the  regions computerized
data-wise. CSC can handle that  I think.  That information has to flow
into the regions, now it goes directly to  the states and we  do not get
copies of them.  We have to figure out some type of a mechanism to get
it out. It will not be a simple one-two-step combination. We are talking
about a very complex system.  Headquarters must put out some type of
guidelines along these lines then.  Or is it  going to  be a volunteer type of
thing like everything else? It is a tremendous problem, I admit that.  We
cannot just sit down and listen on the phone and request the information
we  need.  It  is amazing  what people want to see and what we  are
supposed to have as an Agency.  I do not think it  will stop just because
there might be problems.  We just have to find a way around it.  There is
a need for the states to have personnel who can obtain this information,
through the burden  lies within the regions to obtain this information. Of
course, we are saddled with the need for additional people,  money, and
                                          B-28

-------
Question:
Bill Milligan:
Question:
Bill Milligan:
what have you.  In the case of New York State, a good case in point, they
have their program, their own system, and their own DMR. Yet, we have
determined  that the  adequacy of this list is not acceptable and we are
going to  be loading the  permits into  our own file and  getting the
reporting data  on  cards or  tape and writing  conversion  programs
ourselves so that the data  can be screened by  our programmer.  That is
what we are deciding. I think we are getting involved.

My impression is  that  for Region VI  and VIII, being in  the pilot  study
seems to be based on the fact  that they  volunteered.  I would  wonder if
Headquarters  had  given any thought to the criteria of Region  VI and VII
based on say, Region III, IV and V?  What the compatibility would be with
their being different programs?   Along these same lines  Dave Write
alluded  that if  he did not like it  he  would  build his  own.   Bill you
mentioned the fact that the two regions would sign off on it  once Region
VI and VII had signed off on it. It is going to be mandatory for the  other
regions  to accept  it?  If it reaches this  point, I  think we come again  to
the question of:  how do we require delegated states within the  regions to
pick up  on the program from an unfortunate standpoint?

Number one,  Region VI and  VIII sign off, Region II will also.  Region II
will be  overseeing  the whole operation with  Headquarters so  three
regions will be doing it.  It will be mandatory if they go with it.  I was
told that the regions are responsible for the state's data.  It  will be your
responsibility  eventually to  (unintelligible).  If there is no conversion
program, things like that are possible.  If they do not have a system, that
is the only way to  do  it.

All right, let us go back to the one aspect of the question I asked. Where
it seems like VI and VIII volunteered the pilots in this instance, did your
office, in fact, take a look as to how they would compare against some of
the other more heavily permeated regions and  that  the impact would  be
credible in this instance?

All right, look at  what Region II has already done.  For I, II, and III,  we
are assuming that these regions are pretty similar.  We want to get  the
West involved.  Region VII already had a  system set up using information
data.  We thought we could probably use  their data to convert  over.
Region  VI will be  the real test, because they have a tremendous number
of permit applications down there.
                           B-29

-------
                   PANEL C: EXCHANGE AND STANDARDIZATION
                           Chairman:       Ted Standish

                           Panelists:       Maureen Johnson
                                           Gail Huguet
                                           Catherine Tittle
                                           3ames Flatten
                                     OVERVIEW


                                     Ted Standish


      What I would like to do to begin is to go through some of the background explaining
why this issue has come up at this time.  Back in 1972 or 1973, data processing credibility
was very low in this Agency.  I think that there were several reasons for that.  First, we
had problems with the General Point Source File.  We had problems with the conversion to
OSI, and we had problems with  the Research Triangle Park 360-50  Computer Center and
the attendant problems with the air systems.  In addition, we had several problems with
Congress and OMB.  I would say overall, in  that period, there was a general inability of
data  processing to meet  the user and management needs of the Agency.   There was a
general lack of faith on  the part of the Agency in data processing ability to serve any
useful purpose.   In addition, there was a great deal  of  duplicate effort because  of  the
fragmentation of data processing, both within the regions, among Headquarters units here
in Washington and in all of the R & D installations.  During that period,  1972-73, I believe
all of the organizations that were involved in data processing started trying to regain the
credibility of data processing by developing basic tracking systems.  Rather than going for
the grand design of GPSF, we all started looking at the individual needs of basic programs
such as the NPDES Permits Program, just to track whether or not we had issued a permit,
not what the effluent limitations were in that permit.   To a large extent, their efforts
were individualized and they were not coordinated, especially among the  regions.  This
resulted,  for example,  in  the permits area, in  10  different management information
systems that handled whether  or not a permit was  issued.  During  the  same period,
Headquarters, in trying to  establish their credibility, started  to develop a very limited
capability system, which  is  the  Permit Compliance System.  It was successful in  that it
met the needs defined by managers, and it  was developed within a reasonable period of
time.  However, there were problems in that there were still Headquarters and regional
efforts going on in diverse  areas.  Few regions adopted PCS as their system within the
region.

      I  think it is  generally agreed that the reigons are viewed as microcosms of  the
Agency. Each region has  all the programs that are going on in Headquarters.  It becomes
apparent to  all  of us in the regions that we need to coordinate our efforts in order to
reduce  our duplicative work, and  enable the transfer of systems, among ourselves.  The
problems that we faced, however, were the following:  first of all,  we had  no mechanism
for coordination;  secondly, we  had no  documentation  standards; thirdly, we: had no
software design standards, in terms of structure and compilers.  The hardest problem with
which we had to deal with the regions was that specific data was included in the software

                                          C-l

-------
 itself rather than being in tables.  If any other region wanted to pick up another region's
 software, you had to go in and physically modify the source code itself.  The last problem
 we faced was that there were no  equipment standards.  The software  developed by one
 region to operate on  their  equipment might not operate on the equipment maintained  by
 another region.  It was also apparent to the regions that we need to modify Headquarters
 software in order to meet regional conditions.

      In the 1973-1975 period, one of the things going on was that centralization of the
 data processing activities in several regions made it much  more apparent that, in addition
 to dealing with individual  programs, there was a need to coordinate and  integrate data
 across programmatic  lines, including the Assistant Administrator lines in Headquarters.  I
 think those of you who attended the Effluent Data Systems session yesterday got a flavor
 of that  when we started talking about the fact that  there  were at  least three offices
 currently involved in  effluent data:  namely, the Office  of  Enforcement; the Office  of
 Water and Hazardous  Materials, and  the Office of Toxic  Substances.  The regions began
 discussions  of standardization about two years ago.   Again, the reason that we started
 bringing it  up was because we were interested  in trying  to transfer software among
 ourselves.  The other problem we had was that we knew that the documentation problems
 were preventing  some of  this transfer.   The third thing we faced  was  that we were
 discovering that  we had the one-man or the "indispensable-man" problem.  We had one
 person who  had written the software or we had one person  who knew that software.  When
 that person left,  that software essentially became useless. Concurrent with the effort the
 regions started in standardization  methodology, there was a presentation at last year's
 conference  on structured  programming.   There was a subsequent  proposal  by the
 Management  Information and  Data Systems Division this last  summer  concerning the
 adoption of  some methodology  for structured  programming.    There  was  also the
 development of the Model State Information  System for the Water Supply Program.  This
 was done using the HIPO method developed by IBM for structured programming.

      I believe that there are several factors forcing us to look at standardization and get
 it under control.  First of ail from the technical side, one of the driving forces,  at least
 from my reigon, is the proposal by MIDSD to come out some time during  this fiscal year to
 review our regional operations, particularly whether or not we have documentation for our
 software. I have problems in  that area and I will have to  do  something  about that before
 that review occurs.   The second thing that  we are all faced with is that we have the
 Development,  Maintenance and Operations contract, where  we  have Computer Sciences
 Corporation developing software for  anyone  who puts in  a task order.   The unfortunate
 problem is  that  we  have no standards under which the  contractor is  to operate.  Any
 software that comes  out  is essentially at the design requirements of  the originating
 organization.   Thirdly, we  are faced  with the situation of regional  mini-computers being
 installed with at least three regions currently having minis, and several more in the
 process  of  looking  at the  feasibility  of installing  minis.  We have  the laboratory
 automation  efforts going on which could standardize the methodology for automating the
 S&A laboratories within the regions, and all of the methodology for automating the labs in
 the R&D sector.  We are also faced with the word processing data processing interface.  It
 is not very  clear where word  processing and data processing begin.  The most important
 aspect that  is pressing us right now is the 1981 procurement  where we are required to  go
 out on  a fully competitive procurement, which  could result in non-IBM- or UNIVAC-
 compatible equipment. To the extent that we are not standardized, I would hate to see
 the problems  that we will have trying to convert to  that system.  It  is all fresh in our
minds right now,  the problems that we had converting from OSI to COMNET, and that was
IBM to  IBM.   One other thing that became  apparent reading  the  1981 study is, as  I
understand  the GSA  rules, that the contractor  who  is  awarded  the new  data-center
                                                                            *
                                         C-2 ,

-------
contract is  not  responsible for converting any  software  that is not documented.  That
means a little bit to me too, in  that if I have a non-IBM or non-UNIVAC system, and I have
some undocumented software, I am faced with having to convert it myself.

      From the management standpoint, we are  seeing that data processing has grown in
credibility.  We are also  seeing that there are  significant  manpower, or person power,
constraints within the Agency so that more programs are relying on data processing to aid
their activities.  I think Water  Supply is a very good example of that.  In addition to  the
new programs that are coming  up, we have existing programs which are rapidly expanding
in their usage. The continuing discussions on Effluent Data Systems is one of those areas.
In view of  this increased reliance  on  data processing, without significant increase in
manpower, there is a much greater need now for  us to coordinate our development efforts
to relieve the manpower shortages.  In addition, because of the installation of the regional
mini-computers, there will be the need  to transfer programs between those  centers.   We
have to get away  from the idea that quick and  dirty programming efforts, which can be
easily done on a mini-computer, are going to be  acceptable without documentation.  That
is what the Agency has faced all along. If you  look back at every system we have ever
developed, the idea in the beginning  was that it was going to be a quick and dirty system.
We did not need to document it; subsequently, we have ended up with a lot of software, no
documentation, and no one who really understands how it works.

      There is also going to be  a greater need to integrate data among the programs.  The
208 area-wide study was one of the first to indicate that there were problems in trying to
tie the data bases together. The 1981  study that was developed by Informatics stresses
the  need  of  the toxic program to tie  different programs together. There is also  the
current emphasis  of  the agencies  to develop environmental quality indices which  will
require us to start tying our data together.  I believe the last area,  forcing us into  greater
coordination, is  that  management is relying to a greater and greater extent on the data
for decision-making and strategic planning purposes.   We are getting  into the position
where we have  to avoid conflicting  actions between programs.   For example, it is
ludicrous, in my opinion, for enforcement to issue a violation against a discharger, if, in
fact, the problem is that  we have  not  awarded that discharger, in the  case of a
municipality, his construction  grant. Right  now that coordination  effort  is being done
somewhat on an ad-hoc basis  manually, but it is something that  could  be  done  through
automation, since  all of that data is currently in existence somewhere in systems.

      I would like to go through the members of the panel now, introduce them, and briefly
say what they will be  discussing.

      Maureen Johnson is  with the Management Information and Data Systems Division at
the  National Computer Center in Research Triangle  Park.  She  will be discussing  the
software and documentation standards that are going to be proposed.  Next is Gail Huguet
from the Delaware Valley Regional Planning Commission, which handled  the Philadelphia
208  Study for Region III; she will be discussing  the integration of data across programs.
Next is Jim Flatten  from the Management Information and Data  Systems Division in
Headquarters, who will discuss the data processing equipment standards.  Finally is Cathy
Tittle from  the Management and Organization Division in Headquarters,  who will discuss
the proposed word processing standards  that are coming out.
                                          C-3

-------
                  SOFTWARE AND DOCUMENTATION STANDARDS
                                  Maureen Johnson
      One advantage of having standards,
 both through the design and the documen-
 tation  of  software, is to  help in the
 evaluation of the final  product.  If you
 know what to look for and if you convey
 to  the  developer what your criteria are,
 chances are that those are going to match
 up  a lot better.   It  should also reduce
 redundance as far as developing programs
 are concerned  and  avoid  two  regional
 offices doing essentially the same thing.
 In  North Carolina, I am sure there have
 been occasions  where offices  right next
 door to another  one, but  in different
 divisions, may well  have been working on
 the same sort  of problem.  Certainly  in
 the design phase, if  standards are applied,
 there are reliability factors.   The confi-
 dence  level that  we  can  have in the
 software being developed will  be greatly
 increased.   It simplifies costing and staff
 projections.  If essentially the same things
 are being done in the same length of time
 and about the same  level of effort, it will
 reduce the dependency on individuals.  It
 is human nature to  assume that  good ole
 Maureen will always  be  around.  If her
 program needed to be modified, she would
 take care of it; if it needed to  be run just
 a  little bit  different  with   different
 parameters, she would take care of it; she
 always  did.   But who is it that  develops
 the software under contract?   Where  is
 the person  in a  month?  A  year? Two
 years?    Certainly  they  have  changed
 companies three times.  Just try finding
 out why a particular  switch was set, or
 why when you think it is there, it sprouts
 up somewhere else.

     Standardization  does   provide  a
 method of getting things done the way you
 want them done  without day-to-day con-
 trol.   It reduces petty decision-making
 time.   In terms  of  coding, for instance,
 the coder may spend some time  deciding
 which way to code a loop, which way to do
a very minor detail.  If there is a  standard
established,  there is no decision;  it is just
done that way.  It might not be the most
artistic way of doing it, but it  works,  it
has been proven  to work.   One other
aspect of standardizing programming  is
that it will eliminate some of the known
pitfalls into   which  many  programmers
fall. It will also reduce the life cycle cost
of a system.   The front end cost  will be
reduced, because programming efficiency
should increase  the  effectiveness  of the
software  that   should  be   enhanced.
Certainly, maintenance will be reduced.
In fact, we may hav6 contract money for
development,     but     what     about
maintenance?  When you need it done will
you have support? It certainly turns your
stomach  when you  have paid a  certain
amount for  software development,  and
you find it must be modified, and the cost
of  modification  is  twice  the  original
development cost because it is not docu-
mented,  nor can it be  converted  if it  is
not documented.

     Bottom line, what does standardiza-
tion do?  It enables  us to  communicate
with one another.    There  is  a writer's
golden rule:  write unto others as you will
be  written unto.  Readability  in  and of
itself is  reason  enough for  standardizing
our documentation and the way our coding
is written on the page.  Naming conven-
tions   is  another  area  that   must  be
addressed.  Data elements.  Data element
dictionaries. What are dictionaries?  They
define terms.  If someone's getting into an
argument,  maybe  they  will  have  the
foresight  to  define terms.  If you are
going to transport a program, or if  you are
going to use data from  one  program from
one system  in another system, and the
same  term  is  used to  mean  something
different, or if the same data element has
a different name in the two systems, you
have a lot more work, a lot more  time,
and a lot more effort than if those had, in
the first place, been consistent.   If one
person is talking about  a system  flow
chart,  another  talking about  structure

-------
flow,  and someone  else  talking  about
schematic logic, are they really  talking
about  the  same  thing,  or  are  they
different?  Just what is  required  in a
documentation package?  We will  also be
addressing style  and coding  conventions.
What  do  I mean by  coding  conventions?
Perhaps   limiting the  number of  "ifs"
nested in a COBOL program.  Did you
know  that if you nested too many  "ifs" in
a COBOL program  that the code might
fall in on itslef and create a black hole?
That was  to see if you are listening!

      In the area of  program and system
design,  we will be  advocating  modular
construction  and requiring,  hoping,  and
praying for top down design.  We will  not
be   stating   a  specific   methodology;
however,  we will be teaching the Jackson
Method after the first of the year. What I
have seen so far is that those people who
have   studied   and   used  that   method
become  converts.    In  other  words,  it
seems to  sell itself.   At this  point, I think
we have  realized,  that  any  method  is
better than none. If  it is a structured top
down approach,  it  will be  better than
bottom up.  How are we going  to do this?
These standards  should be applied to all
new  software  development,  especially,
that  done under contract.   It is  easy.
Once the standards are written and have a
place  in  a manual  with  a  chapter  and
verse page to reference, what does it take
to put them in a  contract? The documen-
tation standards should be applied to any
documentation written even if the  pro-
gram  already  exists.  Ted  mentioned  that
somebody's going to come looking and  see
if you have documentation.  Chances  are
you are  going  to  start rolling up your
sleeves and doing some documentation in
the near future.  Would it  not  be  nice to
have  some standards? First  of all, within
your own  office, you are going  to have to
come up  with  some  sort of  format from
which your   people  can  work.    With
agency-wide  standards, everyone  will be
doing it  in the  same basic format, with
the same requirements.  Low and behold,
we may be able to read what someone else
has written, and know where to look for
something  in  a  documentation  package.
Certainly  the  documentation  standards
should be applied to any documentation
being prepared as part of the conversion
effort.

     Goals that we have set for ourselves
include: easy to use standards. If they are
cumbersome, no one will use them.  You
will get so much  grief from  contractors,
that you will  finally give in.  They have
got to be easy to use and they have to
make sense.  They need  to be clearly
stated.  Maybe we can  adhere  our  own
golden rule of writing.

     What is the  status on all this?  What
is being done?  We  had a survey done by
CSC  of  the techniques currently being
used within the agency, both programming
techniques and documentation standards.
We wanted to know how much had already
been invested in  one set of  standards or
one  technology,  and  our decisions  then
would be tempered  by that knowledge. If
there was a close advantage between  two
different   ways  of   doing   something,
certainly  that heavy investment on  the
part of one might  weight  that  decision.
We certainly  wanted to avoid  throwing
something   away   that   was   already
established and proven; we also wanted to
solicit copies  of  existing standards.   We
received the final report last  week.  I was
a  little  disappointed  in   its  lack  of
thoroughness.  All the regional offices and
laboratories had been contacted, but as so
often happens, the  right people  were not
involved in the  survey.   It did not do
anything  for  my credibility feeling to
know of some fairly elaborate documenta-
tion standards which were not reflected in
the survey.  It also bothered me a little
that they  had talked to some program
managers, and one of the first questions in
the survey  was:   "Do  you  know of  any
development  work  being  done  in  your
area?"  The answer was no.  That is one
way to get through the survey in a hurry,
for sure.    But  I knew that there  was
development work being done.  We  have
received some copies  of  documentation
standards.  If  you have any, or if you feel
                                         C-5

-------
that something is very near and dear to
you, please get in touch with either Gene
Lowrimore or myself.  In the area of Data
Element  Standards, Frank Bullock is  the
Contract Officer on a contract to Arthur
Young;  they  will  be developing data
element standards for the Agency. I am
sure Frank  will be  glad to provide  you
with a copy of  the scope of work on that
contract.    Gene Lowrimore  and I  are
working  on Agency  standards  for  pro-
gramming,  documentation,  and  design.
We have  set  up  targets for  ourselves.
Hopefully, by early  January, we  will have
a draft of the documentation standards;
by February, programming standards,  and
in March,  design standards.

     I want to  hear from you. We will be
distributing  these   drafts  for   review,
comments, and  suggestions.    Somebody
had to do it.  We are all going to have to
live with  them and we  are going to have
to use them.  This is your chance to get
your two cents in. Certainly, they are not
going to  be something that are carved in
granite and can  not be modified.  We will
all learn in the process.  After the review,
there will be final acceptance,  and they
will be incorporated  as part of the EPA
ADP  manual.  ADP is a vital and costly
tool used in working towards the Agency's
mission.  I challenge each of you to  raise
your   own   consciousness   about   the
necessity  and advantages of standardizing
our  ADP  efforts—not  only  your  own
awareness, but  the  awareness  of  those
around you.  Whether you are a  branch
chief,  a  programmer,  or  a  contract
officer, each one of us can do our part.
                                         C-6

-------
                                DATA INTEGRATION
                                     Gail Hu.gu.et
      EPA has computerized a tremendous
amount of  information  in the last few
years, and is about to computerize more.
The problem with much of the work done
is their single purpose data bases.  There
are  air  quality  inventory,  enforcement
files, large supply sampling, etc. They are
all single  purpose.  It is very difficult  to
take  information,  for  example,  for  a
single industry, from  all of these separate
files  and  compare it. This is  one  of the
things that  EPA  will have to face in the
future,  if they are not facing  it already.
We,  at  the  Delaware  Valley Regional
Planning  Commission,  got a  sample  of
that  program when  we got a  208  grant.
We felt that we  had  to have a wide array
of  information.  The sampling informa-
tion, discharging data.,  land  use  data,
centers'  information, population  projec-
tions, we  wanted  to put all of  this
together and use it across the board.  The
problem  was:  how  do  we do it?   Our
consultant,   Chester  Beth   Engineers,
approached  it  from  a rather  interesting
point of view.  They decided rather than
trying to  put everything into one system
they  would  try  to  organize  what  was
existing;  they  would do this  through a
geographic code  and  standardized identi-
fiers.  Let me get some charts and show
you what the system looks like. DVRPC is
a  regional  planning  commission  with  9
counties  and 353 municipalities that  we
represent to states.  We  found we had a
tremendous  task  because every  one  of
these  municipalities  and  states  had  a
different  (unintelligible).    We  began by
trying to  pull things together  geographi-
cally.   We  developed what we call the
demand center.  A demand center is like a
(unintelligible). It is about the same size,
but it is  based  on  a watershed;  it  is a
hydrologic unit.  This graphic explains it.
Imagine this red line as a municipality.
These blue  lines  are streams, the black
lines  represent  the  demand   center  we
developed. What we did was say that the
municipality  in  our region  is  extremely
important; that will always be the border
of our geographic  system.  The  streams
will  be  divided  up  into  sub-watershed
areas.  The red lines are the municipali-
ties, you  put the streams over the  top, and
then  you  put  on  the  demand  centers,
dividing them up into separate areas.

     We  started putting information to
these systems, and  we found that census
information was impossible hydrologically.
We decided to use a census block, a  very
small city unit, actually  a city block.
Then we  could  develop  a correspondence
table between the census block and these
demand  centers, these  hydrologic units
and  this  information  could be fed in; we
are  using  computerized tables,  and we
found  that  this worked  much   better.
DVRPC  also had  land  use  information
stored by these centers, blocks, and em-
ployment data.  All of that information
was fed into the hydrologic unit.

     The next problem  was to  get  dis-
charger data into this hydrologic  unit. It
had to be done by mapping the dischargers
and coding them. This,  however,  was not
really enough for the system.  We wanted
to be able to say—for example, if we were
sampling  data down in the stream some-
where and we found a toxic waste—which
dischargers could  possibly contribute to
this  problem.   We borrowed  a  stream
coding system from the State of Pennsyl-
vania.  (We can go  to the next chart.)
This system was based on using Delaware
River in  the  beginning;  the code  for the
river would  be an 01.   (unintelligible)
which was 109th river from the mouth of
the  Delaware   was  01109;  the  162nd
stream the West Branch, upstream from
this  river, would have the entire  number
01109162.  This was  a  very cumbersome
system; however, we were able to trace
problems  from  a tributary, that  we may
have  found in  the (unintelligible) river.
                                          C-7

-------
 We could trace them using this computer-
 ized  system.   We could say, we have
 sampling problems here,  what are all  the
 dischargers above on a certain  point on
 the system?   We could then trace it all
 the way  back.   (Let  me go  to  the next
 one.)

      The third part of this system had to
 be a river mile index. We wanted to have
 relative distance to find a stream, so we
 borrowed a river mile index system from
 the Delaware  River  Basin  Commission,
 and implemented  throughout  our entire
 system.  We actually measured all of  the
 streams,  put mile ticket points on them,
 and coded all  of  the information  to river
 mile  points, to the stream code,  and to
 the demand  center.   Now  we  had an
 integrated system that had a geographic
 unit identifier.  We were able to compare
 the land  use information which is stored
 by demand center, to population, which
 was also stored in the demand center, and
 to discharge data that had a stream code
 and river mile index.   We  could then
 compare  all of these different  kinds of
 information.   Solid waste data could be
 coded to the demand center,  and we also
 coded our demand centers to stream and
 to river mile indices. We could say on any
 given  river, where are  the  solid waste
 disposal sites that might contribute to the
 problems we are seeing?  Where is  the
 agricultural land that might contribute to
 this problem?   We had a broad range of
 information coded on all three  of these
 systems;  then  it  was comparable.  This
 chart  gives  a  little bit  of  an example.
 These  numbers are discharger numbers.
 This is a stick  diagram of the stream, and
 these are discharger numbers—non-muni-
 cipal,   industrial  municipal,  etc.—they
 were all mapped and coded, and  then put
 into the  system.   Here is  a so-called
 typical  watershed area  and  the  various
 demand  centers.    Here are discharger
 points, diversions, water  quality  stations;
 all of them are coded to the system and
 could be compared.  These are the various
 files put into the data base system, i.e.,
 industrial point  sources and municipal
point sources. In some of  these others, we
never put them into the systems actually.
They were coded,  though, to the system.
Thus,  we  were  able  to  say  when we
wanted to find out about something, like a
water  supply  diversion,  because  it was
coded.  In other words not all of these
pieces have to  be on the same system,
because  the  geographic  codes are  the
same, you are able to compare them even
if they are not on the same system, or not
computerized at all.

     The second part of this system was
to  use  codes   that  already   existed.
Nothing is worse than creating your own
code, and  then not having anyone else
understand it and not being able to trans-
fer data between one agency or the other.
We investigated  all the  codes that we
could find in the region, and there  were
many of them.  For example, the State of
Pennsylvania had a county and minor civil
division code and coding system. We used
that  in the number  that  identified the
demand center.  This was  different  from
the census code, unfortunately, so we also
put  that in  the file in  order  to  do
retrievals by census codes, or by the State
of Pennsylvania codes.  When we finish
with our  study, we can transfer data right
to the Pennsylvania system; the codes are
the same.   We also  used our  sub-basin
code and our stream code. When it came
to the river mile index, we used the river
mile codes of the Delaware River Basin
Commission which is also the same coding
system used by the (unintelligible).  We
used (unintelligible).  We tried everywhere
along  the  line  to  use  something that
already existed.  We  tried not to create
things, and when we did, we also put other
numbers on the system. This was the case
with the MPDS  permit number.  We put
that  on our system, in order to relate the
two.  (unintelligible) number is the State
of Pennsylvania enforcement  code  num-
ber for each discharger.  We also put that
under systems so that we could communi-
cate.  Pennsylvania permit numbers, pro-
cess  numbers  that we use and  units of
production for all of these things, we tried
to use already existing codes.  We used
standard SIC codes.   Again, we were not
                                         C-8

-------
trying  to  create new codes.   This  is     table you develop, the harder you make
something EPA has to start doing; i.e. to     your task. It is much easier if you use the
develop the same coding system, or keep     same code,  or, at least, keep the same
similar codes on  whatever  files they use.     codes  on your files,  even  though  you
For example, if you have an enforcement     lengthen the file,  it is very important to
code,  an  enforcement  file  for  water     be  able to put that code in and get the
quality, some kind of code that will get     information out in the  format in  which
you into the air quality inventory for the     you need it.
same industry  should be on one of  those
files.   There  has to be  some kind of
transferability; the  more correspondence
                                          C-9

-------
                             QUESTION AND ANSWER
Question:        Do you have any of the map digitized? Do you have any graphic display
                of any of these maps?

Answer:         We have graphic displays of several of the maps.  The river mile index
                and stream code work were done on maps; the demand centers were all
                mapped. We do not have it digitized, per se; however, the census data is
                digitized using a  geographic  base  file.   We have some of  the units
                digitized at  various levels.  It  will take a data transfer to  make the
                system work.
                                        C-10

-------
                        STANDARD TERMINAL CONTRACT
                                    Jim Flatten
     Any standards  you develop have to
be written to meet  the job  that  can be
done.

     I  would like to  get  into a  brief
history  of why we came  up  with the
standard  terminal  contract.    We  must
provide a standard interface for our tele-
communications network. As most of you
know, we have the UNIVAC  computer at
RTF.    We   have  the  IBM  37160  at
COMNET. Both could interface different
terminal standards; however, those of you
who have requirements to go to both can
use just one terminal.  It allows us to have
a single telecommunications network, re-
ducing cost and providing better and more
efficient  service to  everyone.   By  stan-
dardization we  are  trying  to make the
equipment reliable  and  cost  effecitve,
while  providing  a vendor  offering  you
rapid service and maintenance repair for
your equipment in order to prevent down-
time  and interference with  your opera-
tions.  By having  standard terminal con-
tract, we were able to have one interface
with each vendor.  For problems,  such as
non-responsiveness   of  maintenance  or
non-responsiveness for delivery, it made it
much easier to work with the supplier.   I
do not know how many of you have been
with this  Agency since its inception.  We
went through many  horror stories of the
DATEL/HARRIS   Communications   ter-
minal days. When Harris Communications
walked in one day, they walked out with
every terminal because there had been a
long period of non-payment; the users had
failed to renew their lease agreements at
the end of the fiscal year.  Some of the
renewals were not done for several years.
Now the Harris Communications terminals
have  been  out  of   the  Agency  for
approximately  three  years.    Just  last
week, we were still trying to resolve one
of the old invoices.   This has  been time
consuming and  has  created  many pro-
blems; it has created an enormous expense
to the Agency.  There was hope  that the
new  standard  terminal  contract  would
avoid this. Anyone using Anderson/Jacob-
son terminals knows that we did not solve
that problem completely.

      In the past, if you required  a termi-
nal for your use, each of you would have
to  go out  and  evaluate  the available
vendors,  research what  was  available in
the   market,   find  out  the   vendor's
responsiveness,  and his  ability to meet
your  need.    There  was  duplication  of
effort, that the standard  terminal con-
tract eliminated.   The  present  standard
terminal contract is not the answer to all
problems.   I  would, however,  like  to
review some of the problems that  we were
having.  We have gone back and talked to
our present standard terminal contractors,
and  they have indicated that the volume
of our procurement has  been so  minimal
that  they would  not  be interested in
having  it continue  after  the  present
contract period.  We are still having the
lease  payment   problem   with  some
vendors.   I  have on my desk right now,
after a year and a  half  of resolving 500
and  some odd  invoices  that were mis-
billed    or    mis-invoiced,   150   still
unresolved.  This has created thousands of
hours of  wasted effort on the part of EPA
employees trying to resolve  whether the
invoices   were  valid,  against  which
purchase order they were  supposed to be
billed, and arranging for payment.   The
vendor has  outstanding  against  EPA, at
the  last  count, over $200,000 worth of
invoices  that  are still unresolved or un-
paid.  They are getting quite perturbed
with  a  situation,  mostly  of  their  own
creation. Some  of the  invoices  that  we
had  from this particular vendor,  were
invoiced against purchase orders  that ex-
pired at  the end of FY  1974.  They have
'never updated their records to reflect new
purchase orders.
                                         C-ll

-------
      Another  problem  is  beginning to
 appear in  price  discrepancies  between
 GSA schedules and our standard terminal
 contracts. Now there are reasons for this.
 We require 30-day delivery for interactive
 terminals  under EPA  contracts.    GSA
 contract  requirements are about double
 what our requirements are.  When we have
 30 days, they have 60.  When we have 60
 days,  they have 120.  We have to weigh
 that  against the  fact  that  the  Texas
 Instruments  terminals,  under  the   GSA
 contract, model 7^5's and 743's are practi-
 cally $400 each less to purchase than they
 are under our  contract.  The same  holds
 true for the  (unintelligible) terminal. The
 standards  and   criteria  we  have  as
 additional items in our specifications, are
 being evaluated in relation to the increase
 in price we  pay for a terminal to deter-
 mine if it is cost effective.  To justify a
 new standard terminal contract, after the
 present one expires,  we would have to
 have a larger volume of new terminals to
 be purchased, or  leased than past  usage
 has indicated. On July 17 of this year, we
 sent a memo out  to all  known EPA  ADP
 users   asking,  what  equipment   they
 presently had?  How long they intended to
 keep  it?    What   their intent  was for
 additional equipment  in  the  next  three
 years? They said that everything they had
 is fine, they work great, they  do not need
 anything additionally.  One person would
 like a standard terminal  contract to buy
 one item,  another  person wanted tractor
 forms, on the Class IA, of which we have
 about six in the whole agency.  It began to
 appear that  we  could not justify the man
 hours,  time, and  effort  to  develop  a
 standard terminal  contract for the period
 1978-1981  to meet a  limited requirement
 for  additional  equipment.  Maintenance
 and service on presently owned equipment
 would be available under the GSA  con-
 tract at an almost identical price.

      Another  problem  is adding   new
equipment.  As most  of  you know, Texas
Instruments  has  come out with a  new
portable terminal, model 765, which is a
bubble memory machine, that  can be used
off-line,   has   limited   text   editing
capabilities. You can search a file, create
a  file in  memory,  edit  it,  change  it,
replace it, segment  it,  and you can turn
the machine off without losing data. You
can turn it on later and start from  where
you stopped.  You can go "on-line" at any
time and transmit the data directly from
memory. This machine costs about  $2900
for a machine with a 20K bubble memory.
In talks with  Texas Instruments,  they
stated they would not place this machine
on our standard terminal contract.  Their
reasoning was  that  the  volume was too
low and they could not meet our delivery
schedule.  I do not know if anybody has a
requirement for that type of terminal, but
that is one of the problems which we have
experienced.  How we can get  the  latest
equipment  meeting  our  basic  standards
specifications under our standard terminal
contract has been a  problem.   We have
reviewed  our  available  options,  and  I
would like to give you our thinking and the
way we plan to go in the furture.

     We want to eliminate the problem of
carry-over  leasing from one  year  to the
next;  we  would  like  to  suggest that all
leased  terminals  be  purchased.    The
break-even point on  all terminals—I am
speaking   now   of   only   low   speed
interactive terminals—is between 18 and
21 months.  If you are going  to keep  a
terminal over  18  months,  it becomes
economically feasible to buy it.   In the
past, people have desired to lease; as they
feel the vendor will provide better service
since  it is his machine.  This has not been
our experience  over  the  past  several
years.     Most  reliable   vendors   with
equipment  meeting our specifications and
standards, provide equal service for leased
and owned equipment.  Purchasing hard-
ware  would eliminate one of  the  major
problems we  have had,  that of users not
renewing leases at the end of each fiscal
year.   Terminal  maintenance  agreement
renewals at the end of  the year is not a
serious problem. Even  if a maintenance
agreement  is  not in being maintenance
can be obtained fairly  quickly under  a
one-time  purchase   order.   This  would
alleviate the problem of trying to resolve
                                          C-12

-------
bills going back three to four  years.  We
suggest that any equipment that can be
justified  for  lease,  be  leased  with a
termination date specified.  The terminal
will  be  taken  out  at  that  time.   If
requirements develop late for longer use,
you   should   exercise   purchase  option
credits and buy it.  We have spoken with
our  procurement people  about obtaining
terminals  under  the  GSA  schedule  con-
tracts.  It is  not a great deviation from
what we  have done now.   Develop  your
specifications, one  or two paragraphs will
usually suffice, a short evaluation of three
or four alternatives (if any)  and reason for
selection along with a  purchase request
will  then  be  forwarded to procurement.
We hope to issue specifications for you to
obtain terminals.  It will in most cases be
a small purchase under a GSA contract. It
is a very simple procurement procedure.
One item we  have  not enjoyed under our
EPA  schedule  is  the  Government-wide
discounts being offered by vendors under
the GSA standard terminal requirements
contracts.

     My remarks, to this point, have only
been  for  the  low   speed   interactive
terminals, not  for our  present Data  100
terminals or  the  mini  computers.   These
are high cost items.  They do not have the
short pay  out  time  for  lease  versus
purchase considerations and  they  require
more detailed specifications and procure-
ment analysis.  We are hoping to upgrade
our  specifications   to  include   more
capabilities if you need them. If anybody
has any additional requirements  they feel
might be beneficial in the Data 100 RJE
area, I  would appreciate receiving them.
We will continue  to look at the standards,
requiring  that any  terminals  procured
meet our specifications and standards.
                                         C-13

-------
                          WORD PROCESSING STANDARDS
                                    Cathie Tittle
      I imagine that some of you may be
 wondering why I  am here  today  talking
 about word procesinig when we have just
 split  the  responsibilities for  word pro-
 cessing and data processing and placed the
 responsibility in the Management and Or-
 ganization Division. We did that, I think,
 for some very good reasons, I  would like
 to explain those to you this morning, give
 you a little bit of an idea what we have
 been  doing in Headquarters as far as word
 processing is concerned, what we plan to
 do to assist regions in the laboratories and
 how we look  at standardization of word
 processing equipment.

      There is a Federal Property Manage-
 ment Regulation,  put out by the National
 Archives Record  Service, which requires
 every agency to establish a focal point for
 word processing.   That  responsibility  is
 not  only a  Headquarter's  responsibility,
 but is also a responsibility for the Regions
 and  laboratories.    As  an  Agency, we
 recently  have been studied by National
 Archives and Records  and we also are
 currently undergoing a GAO audit on word
 processing. The focus of  these surveys  is
 what are you doing with word processing?
 Are   you  controlling  your equipment?
 What kind of equipment do you have? Is it
 cost effective? Do you have any idea why
 you have it and what you are using it for?

      When we established the focal point
 within Management and Organization, we
 determined that it was best to start our
 surveys with Headquarters, get an idea of
 what  kind of equipment we had and what
 it was being used  for,  and make recom-
 mendations for the programs on how they
 could improve their use of the equipment
 to  make  their   operations  more cost
effective on these  lines.

      We  found that we  were spending
about $2 million a year on the rental of
word  processing   equipment  in   Head-
quarters, that we owned an additional half
million dollars  worth of word processing
equipment, and that we were  spending
anywhere  from $600,000 to $800,000  a
year on Bowne. That is an awful lot of
money, especially  when we had no  idea
what it was being used for.

     We initiated  a contractor-assisted
study in Headquarters and  went out, not
to change  our  organizational  structures,
but to look at equipment and make equip-
ment  recommendations.    We  have  just
completed  that study now, and are  just
about to go out  into the Regions. We have
found that by making simple recommenda-
tions—eliminating    some     equipment,
changing  some equipment,  reassigning
equipment—we  have been able  to recom-
mend configurations that will save Head-
quarters about  $250,000 a  year in rental,
and an additional $200,000  to $300,000 in
Bowne charges. We are trying to bring
things under some sort of control. We are
proposing, through  an over-target request,
to take our contractors out  on the road to
8  of  the  10  regions  initially  and  to
Cincinnati  and  to  RTP, to provide the
same sort of  study that we have done at
Headquarters.    The idea  is to  develop
base-line  data  on  what  equipment the
Regions and labs have and its uses.  From
there, program  managers can look at the
equipment  they have,  reassign  it,  and
develop systems while slowing  escalation
of expenditures in word processing.

     If  you are trying to define what we
consider to be  word processing, many of
you will think of Bowne Time-Sharing, the
contract    for   computerized    word
processing  which MIDSD was  responsible
for.  When the agency  was founded  that
was almost the only alternative available
to  people  to  do  large document   text
editing.  In that  case, large documents
were  10-page  reports.   IBM  had  some
equipment, the MAG  CARD  equipment,
with which many  of  you  are  familiar,
which had very limited capability. So our
                                         C-14

-------
use of Bowne Time Sharing as an Agency
snowballed and  grew to the  extent  that
last  year,  we spent  over  $700,000 with
very little  control over what the applica-
tions really were.

     We  are no longer  defining  word
processing    as    computerized    word
processing  through a  time  shared system.
We feel that there are many,  many alter-
natives to  that  approach,  that are more
cost   effective.     Stand-alone   word
processing  devices and mini-computer sys-
tems are coming out on the market almost
on a daily basis.  They have capabilities
parallel  to  what has been  available
through time shared word processing  in
the past, but at a much lower cost.  The
cost is lower not only on  a month-to-
month rental basis,  but  also  from the
standpoint  that  what you are getting is a
fixed price resource, unlike a  time shared
system with no control.   With Bowne  it
was  very  hard  to determine  for  future
months what your costs could be.  With no
supervision of the uses of  that system, a
secretary could  spend $700, $800, $900  or
thousands  of dollars, doing fairly  simple
word processing  applications.   What we
have done in  our  recommendations  in
Headquarters is  to  show  people where
they have  off-line alternatives.  In doing
that we, as I said before, are predicting
about $250,000 savings.

     The  Agency  contract  for  time
shared word processing is currently being
completed.  The  Management Organiza-
tion  Division will be the project officer
for  that   contract   once   it  has  been
awarded.   The funds used to pay for  that
system will no longer come from the ADP
funds as they have in  the past.  They will
now  come  from  program funds.   I would
like  to relate  this  to our  concept  of
standardization and control of word pro-
cessing. The reason we did this is that we
felt that it was time that managers in the
Agency began to be aware of  what word
processing  was and be responsible for the
decisions relative to  the  acquisition  of
word processing  systems and word pro-
cessing equipment.  Bowne was almost a
free resource to a number of people.  If
you had  extra ADP  funds,  why  not  use
them?  On the other  hand, people who had
a requirement to do  large document text
editing, to do photocomposition or to do
some  of  the  applications that  are only
available   on  a   time   shared  word
processing  system,  could  not do  them
because  there were  not  enough ADP
funds.    They  could  not or  would  not
reprogram  funds   from  somewhere else
into ADP to be able to use that system.

     We wanted to make the situation a
little more equitable.  We wanted to say
to people, word processing is  everywhere
from the typewriter  all the way  to com-
puterized word processing.  Consider  all
of your alternatives when you  are looking
for a  word processing  system.   Do  not
segment,  putting  ADP  word processing
over here, in a totally different box.  We
will be requiring some of the larger users
of  computerized  word  processing   to
conduct feasibility studies in FY  '79.  We
believe  that  the  alternative  to time
shared word processing for some of  the
large  users are mini-computers (shared
logic) which can be  more cost effective.
Region IV is a good  example of  this.  We
do  not have  the resources  to support
sophisticated  shared logic system within
some of our Headquarters programs.  We
do  not have the set-up that you have in
the Regions  where you  already  have an
ADP ship operating  a mini-computer for
other reasons. You  can bring in a mini-
computer for word processing and begin to
support that  for  the users  as well.   To
take  an  Effluent Guideline  Division in
Headquarters  and ask them  to staff up to
support a word processing mini will take a
lot more  time and consideration  than
perhaps it would be to bring  one in to a
Region or a laboratory that currently has
a POP 11/70.

     We have developed, and are about to
circulate for comment,  an order  that will
control word processing both  in  Head-
quarters and  in the  Regions  and labora-
tories. It assigns the responsibility to you
for approval of requests for equipment; in
                                         C-15

-------
  Headquarters to the Management Organi-
  zation  Division;  in  the Regions  to the
  Management  Division  Director;  in the
  laboratories,   to   the   Administrative
  Officers; and in the case of Cincinnati and
  RTF,  to the  Office  of Administration.
  The main reason  that we are doing this is
  that  we are required  to  do  it  by the
  FPMR;  secondly, we  feel that Agency
  program managers should not  be required
  to  have  to  take  the  time  to  muddle
  through the 30 to W odd word processing
  vendors out there,  and try  to become
  experts.  They should not have to have
  that  burden  along  with  all  the   other
  burdens they have.    Somewhere  in the
  agency, within the regions  and the labora-
  tories,  there  ought  to   be  a  resident
  expert, who can provide that guidance and
  assistance and who can say—for this appli-
  cation you should be looking at this type
  of equipment.  The order, first of all, will
  assign the responsibility, not  so that we
  can be  ogres and say "No"  to  people, but
  so  that people will  know  that there is a
  central point to which they can come for
  guidance and assistance.  If  people are
  really moving in  the wrong direction, we
  can steer them back on the right course.
  The second  thing that  we will be doing  is
  providing a technical  manual to give
  guidance to the programs for  making the
  initial decisions such as  where they want
  to  go with  word processing  equipment.
  There are  industry standards  that  say  if
  you are doing  certain types of applica-
  tions,  you  should be  looking at certain
  types of equipment.  CRT  equipment can
.  produce a certain number  of  lines a day
 and is geared to  do  large  document text
 editing.   IBM  Mag  Card  equipment,  or
 other  mag  card  type of  equipment,  is
 geared more for correspondence. We will
 be providing that kind of  information to
 the offices,  so  that,  by  the  time the
 request  comes  into  the reviewing  office,
 this information  will  have been applied
 and we will expect the  request to be right
 in line with what they should be.

      We will  be  requiring,   in   Head-
 quarters, feasibility studies on a periodic
 basis,   for   any  office  that   wants  to
significantly change their equipment.  We
are  not  planning to  standardize  word
processing equipment within the Agency.
We are not  moving along the lines of  a
standard procurement for equipment.  We
are finding  that  the  cycle  of changes--
significant  changes  to  word processing
equipment—seems to be a two-year  cycle.
About every two  years for the last  six or
eight years there has been a  fairly signifi-
cant new announcement  or  development
within  word  processing. First, there were
card machines and then  came machines
with memory.  Next came CRT's applied
to word processing, but hard-wired.  Now
it  is software-based  CRTs.   These  things
change rapidly enough that we feel as new
vendors come on  the  market with very
good new improvements  to  their  equip-
ment,  standardization, would prevent  us
from keeping up with it.

     We are also not recommending pur-
chases.  Right now at Headquarters, we
have a moratorium on purchase of word
processing equipment.  The reason we are
doing this—we do not intend for it to  go
on forever—is that while the prices are
starting to drop, they have not dropped as
drastically as they have for  data process-
ing terminals. We are still seeing $15,000
and $20,000 CRT word processors. The
payoff for those is 36  months, at best; in
many cases, it is  more than that.  With a
two-year  cycle  of  major  technological
changes in word processing  equipment,  it
does not make  sense to buy something
that you have to keep for three or more
years before you can pay it  off.  We will
also have a moratorium on the purchase of
equipment   that  has  been  around  the
agency for awhile.  IBM  is  pushing very
hard to get us to buy all the equipment
that we have had  for the last three to five
years.  This gets to the point of the 1981
situation and  equipment  standardization.
The  communications capability protocol
on the IBM  equipment will  not be com-
patible with all  the potential computer
systems with which we may end up with.
Communicating  Mag Cards now  are   15
CPS or 14.8 correspondence.  They can
only be used to go into the Bowne system.
                                         C-16

-------
I guess they can  go  into COMNET,  but,
from  what I understand, that may very
well may be ended soon.   There is  new
technology available  for the same price,
but that can do an awful lot more. Thus,
we are not  recommending purchases of
anything on which you have rental credits
at this point. We are not recommending,
for the time being, that you purchase any
new equipment.  We  have  started to see
the $10,000  CRT, just the last couple of
months.    Perhaps,  within  the  next  9
months to 12  months, those  prices  will
come down a little farther; then  , it  may
become  cost effective to  purchase  this
equipment.

      I think  the thing which we should be
aware of is that by putting  word  process-
ing responsibility in Management Divisions
in the  Regions, and  in Headquarters in
Management  Organization,  we  are  not
saying that we now think that it is totally
separate from ADP.  I think we would be
fooling ourselves  if  we tried  to totally
separate the data being processed on our
computer systems from that prepared on
word  processing  equipment.   I  firmly
believe that  we as an Agency  have many
applications  (ADP and  word  processing)
that use the  same data and that we waste
significant   resources  duplicating   that
data.
     It is important  that  you  become
aware and stay on top of it as much as you
possibly can, to integrate those two sys-
tems and  to eliminate  the duplication of
effort.  The technology in word processing
is  moving rather  rapidly  toward  data
processing.  It  is moving away from the
Mag Card, and getting closer and closer to
the word processing mini-computer. Any-
one who wants  to volunteer  to help us to
look into  where we  should be going with
word processing minis is welcome.  I am
not a data processing person, myself; I am
much more geared toward typewriters and
typists, so I can use your assistance.

     The  last thing I would  like to say is
that I am  a staff of one at Headquarters.
I will be,  as we go out to the regions and
laboratories, asking each of the organiza-
tions to assign someone  to  responsibility
of word processing, much like the current
ADP coordinators, so that we can develop
a  network for  keeping  communications
going between headquarters and the field.
As I have time, and  my  time  will  be
limited, I will  be  more than happy to
provide guidance and assistance to any of
you.   We are  going  to be developing
training programs to give you the back-
ground  you need to  be  able  to deal with
word processing in your organization. Do
not hesitate to call on me.
                                         C-17

-------
                                SUMMARY REMARKS
                                     Ted Standish
      I have a few closing  comments I
 would  like  to  make,  concerning  the
 coordination effort going on with people
 within  the  Agency.  As  far as current
 efforts are  concerned, this Conference is
 obviously  an example of  our  effort  to
 bring data processing under some kind of
 coordinated control within the Agency.
 We  have  also  seen  such  things as  the
 STORE! and AEROS conferences.   The
 meeting  tonight  of  the  Regional  ADP
 Branch Chiefs  is  another example.   One
 example,  or interesting  example of this
 Conference  and  the  issues  in  this  it
 addresses   came   from  the  zero-based
 budgeting process we  went  through last
 year and this year.  We also have commit-
 tees now on regional  mini-computers and
 on the laboratory automation projects.  I
 think however,  that there are also  needs
 for expanded efforts.  I  believe that we
 have to  look  at  the detailed  resource
 impact and trade-offs of those systems. I
 think in a lot of cases, we are overlooking
 what it takes to  bring a system up, and
 what it takes  to maintain  that system
 over time.  We are also asking, at least
 within our  region, that all systems must
 be approved by the Regional Administra-
 tor; division level  approval or below  is not
 acceptable for the acceptance of the new
 system.  We are also going to see, or need
 to see,  greater inter-program  coordina-
 tion. Again, I bring up the Effluent Data
 System discussion of yesterday, where we
 have, the  Office  of Enforcement, Water
 and  Hazardous   Materials,  Toxic  Sub-
 stances, and Research and  Development
 involved.    Then,   you throw in the   10
 regions on top  of that, and  you have a
 fairly complicated  mess with  which  to
 deal.  We  are also  going to  need to see
 greater intersystem coordination,  or  if
 you  wish,  intermedia  coordination.   For
 example, on the media side,  we need  to
 see coordination, say between grants and
 water enforcement.  We are going to need
to see coordination for air and water, for
example. I think some of us probably have
examples  of  water people saying, "It is
okay so long  as  you do not dump it into
the water," and  the air people saying, "It
is okay so long as you do not dump it into
the air." Of course, if you  put the two of
those people  in the  same  room  at  the
same time, they end  up in a fist fight.
Each one is just incredulous that the other
would have the gall to say  something like
that.

     One other  thing  I would suggest we
look at as an  Agency is  to review  the
success of the  Model State Information
System  experience.    Has  the   use  of
structured programming really  made it
easier for us  to  install that system in the
umpteen thousand states that we have to
install it, and is  it, in fact, easier for us to
maintain and modify  that software as we
use it?  As far as the issues arising from
this panel, I guess there are several that  I
see coming. The first is that we are faced
with the  imminent issuance of  software
design,  programming  and  documentation
standards.  In January, we will be faced
with  the  documentation   proposal;  in
February, the  program  proposal; and in
March, the design  proposal. Now we have
to  read those,  review  them, and send
comments back  to MIDSD  on them.  We
are  going to see  the  continuation of the
hardware  specification and the continua-
tion of  the standard  Agency contract for
the remote job entry terminals and for the
mini computers. We should be looking at
the purchase  of  low speed terminals to get
them off  the  leases,  and secondly,  we
should be submitting to MIDSD,  any  R3E
or  mini-computer needs not currently  in
the list of requirements.  Cathy brought
up the issuance, in the near future, of the
word processing order and the guidelines
for the use of word processing equipment.
We are also  faced with the contract for
the  standardization   of  data  elements.
This is  the first that I have learned of  it
and I  would certainly  be interested  in
seeing what  the contract has to say.  The
                                          C-18

-------
last thing that we will be doing in Region
III is that, because of  the experience that
we had with the Philadelphia 208 efforts
in trying to coordinate  the data within
that  area,  we  are going  to  perform a
feasibility   study  in   the   beginning  of
calendar year 1978  to put  that data base
system itself up on  the Washington Com-
puter  Center, which would then  make it
available for use by any 208 region that
wishes to use it.  Our intention is to put
the data up  that  already  exists  for  the
Philadelphia area so that we can examine
within the  reigon how useful it is to EPA
itself, assuming that we find that it is a
viable  means   of   tying   together  our
programs.  We would then start looking at
the expansion  of  the system  to include
other areas within the region on a priority
basis.
                                           C-19

-------
                             QUESTIONS AND ANSWERS
 Question:
 Answer:
 Question:
Answer:
I am  Curt Lackey.  I have already gotten my answers, but I will repeat
the question for everybody else.  My question is directed to Gail. What is
the  status  of the  system?   What computers  does it  own?   Is  it
documented, and can you get me copies of the documentation?

Yes.  The system has been up and running for about two years. It is on a
National CSS  Time Sharing System  which uses  IBM  equipment.   They
have  a special language,  that is a report writer and data base storage
system.  It is  called NOMAD.  But that is not crucial to the system;  in
fact,  we are going to take it off that system and put  it on ours, using it
in a different system. It should not give us any problem.  Yes, we can
send you some generalized documentation.  I also wanted to say that this
is a fairly inexpensive  way of organizing our information.   We  spent
about five months doing the mapping, the coding and entering the data
into the system and the design.  The  consultant spent  about $20,000 and
DVRPC spent about another $20,000. This was for a 208 grant program.
I think it was a fairly inexpensive way of organizing the data.  This does
not include data gathering, just setting up the system.

I have two questions that are related. They are  related because of the
need  to look at data across media lines.  The first question concerns the
need  to establish  data element standards. A reference was made earlier
this morning to the contract of Arthur Young, but, as I understand that
contract and the statement of work,  it is not going to do what is needed
in the Agency. What I think is needed here, is that we need to have an
Agency-wide  definition or standard  definitions  of  data  elements. We
need  to have standard attributes for all these data elements, and we need
to  have standardized values or accepted values for  each of the data
items that have some kind of unique  coding structure  or accepted  coded
values. There are so  many different systems in this Agency.  What each
programmer in each office defines as his own data elements, even if they
were  software compatible, you could not transfer  the  data from one
system to another very  easily because of the attributes and the data
element definition.  The other question, or the other thing, pertains to an
issue  that has already caused some problems within the Agency that are
worse than just the data element standards.  It is going  to be severe in
the years to come unless we do something immediately about it, and that
is the facility I.D. number. We have  a NEDS facility I.D. number and, we
have  an NPDES facility I.D. number. We have a municipal facility I.D.
number, and we are  going to have a water supply I.D. number.  We are
going to have  a toxic I.D. number, and we will not know how to  relate
information from each of these data  systems, because there will not be a
key record that will translate this.

Mr. Burning from the Office  of Enforcement is  quite concerned  about
looking at compliance status and the enforcement history across  media
lines.   He is not interested in going  to a water file and looking at  water
facilities. He  wants to know  in the  steel industry for instance, what is
the compliance status in the air, toxics and the water areas.  Right now,
we can not get to that at all.  The biggest problem is the fact that  we do

                        C-20

-------
Answer:
Question:
not have  a common facility I.D. number within this Agency.  / am
wondering if a recommendation can come out of this particular panel
from this  Conference about establishing a task force to work on that to
begin this calendar year.

Gail and I talked about that problem at lunch on Monday.  One of the
proposals we might use so  that we do not have to develop our own new
numbering system is to take the Dun & Bradstreet numbers which have
I.D. numbers for every industrial facility in the country, or try to find
some other source similar to that and use them as the common identifier.
I will include it in my summary remarks tomorrow as one of the action
items that should come out of this panel. It is definitely something that
is needed, because it will become more and more difficult to tie  the data
together without common identifiers.  As Gail pointed out, the number of
cross-referencing tables is growing astronomically  and is causing  us
considerable problems.

I am Bill Serovy from Region I. We thought about trying to use the Duns
number as a universal facility I.D. a couple of years ago.  Then the Duns
file went away. We were told that we better not use  the Duns number
because that was  part of the Duns file for which we had stopped paying.
We were told that  we would be in big trouble  if we used it and that it
might mean having to buy back the  rights to the Duns file.  I think it
would be a good idea anyway, but I am just pointing that situation out as
a possible problem.

I  have three  questions  or  concerns  about  the standardization  of
programming and documentation. The first thing is that I  do not think
that standards necessarily replace  skills.  Good  programmers  tend to
write good  programs;  bad programmers tend  to  write  bad programs,
regardless of standards or anything else  that you try to impose from the
top.  As Maureen said, a good programmer or any programmer  for that
matter, assumes  that  he or  she will be around for some time and can
always maintain the program. Maureen says that sometimes that means
that they write sloppy programs because they  figure they will be there to
patch it up.  On the other hand, some of us figure that we may be around
to pay for our sins, and if we write bad programs, it will come right back
in another  year.  Somebody will want a thing  modified, and I  probably
will not remember what I did a year ago,  so  I had better do it right the
first time.  A good programmer will look at the long term and will look
at the problem  from the top down.  A bad programmer will not.

The second  issue  here is the threshold at  which these  standards will be
applied. There are a lot of  quick and dirty programs being written in the
Agency, and chances are that there will continue to be. At some point it
becomes counter productive to try to apply documentation standards to a
program that will be used one or two times. It ends up taking you more
time to write up comprehensive documentation than it would to write the
program, to run it, and to  throw it  in the trash barrel. We have to be
careful  in applying  this threshold; otherwise,  everyone will try  to sneak
in under it and say I want to use this  program once, and then continue to
use  it  a  thousand  times  over the next five  years.   It  will be  a
management problem to decide where these  standards apply and where
they do not.

                         C-21

-------
Answer:
Answer:
The third thing is that, to some extent, the quick and dirty programming
problem is a result of quick and dirty management.  That is something
that  we  cannot  directly address  in  the ADP, but some  users,  some
program managers, will refuse to define their requirements for you or to
write them down on paper. How do we assist them in doing that? Or do
we compel them to do it?

/ will say something about alteration.   This may be  a cop out,  but I
believe  that  standards  will  make  the  good  programmer,  a better
programmer.   It  will   also  make  the  poor  programmer,  a better
programmer.  It was interesting to me, in the hallway just outside, that
several people came up  to me who either are in programming, or have
been in programming.  They stated that, at one point, they were in a
situation  where standards  were  being applied.  They are not now in a
situation where standards are applied. There are no standards whatever,
and it is  very uncomfortable for them.   We sometimes generalize that
programmers resist standards and documentation. It is a fair generaliza-
tion, but  it is well to remember that once you have either  enforced or
self-enforced standards and documentation requirements, you can either
do  it within yourself if no one else is beating on you, or if it  comes from
the top down, which it should,  if you  are  ever removed  from that
situation,  it becomes very uncomfortable because you see the chaos.  As
far as top-down management  is  concerned,  perhaps we can  make  some
progress if a threshold is established.  For certain systems, given certain
size requirements, there are  documentation requirements and require-
ments for design.

As  far as that last comment on the problem of management, I think all of
us face that issue, and we have all had to try and deal with the various
problems that  management is having and to find what  it  is  that they
need.   There  are any  number  of reasons  why they  cannot define
requirements.  In one case,  they  may not  know what  Headquarters  is
doing, or where  Headquarters is  going,  and, for  that  matter,  Head-
quarters may not know where  it is going.  Another problem has been that
the managers may not understand data processing at  all, so  that they
really do not know how they should define what it is that they want. The
third case is that  their needs  are changing rapidly over time.   What we
have tried to do in the region  is to take a firmer and firmer  stand where
necessary, and not to start the development of the system until we have
gotten concurrence and written requirements from the division directors.
It is painful to go through that; you will get some arrows and  a few other
things thrown at you, while you are trying to do so, but I think, in the
long run, it tends to pay off.  As the divisions become accustomed to the
idea that they need to specify their needs, then they begin to think more
about what they are doing.  They begin to do a better job of writing down
their requirements.  The other technique that we have started to use in
the region, which is probably going to endear us to Headquarters no end,
is to send down our proposals to Headquarters for their concurrence on
our  writing  the  software.   For  example,  we are  working  on the
automation  of the  violation summary  required  by  the Enforcement
Management  System. We  are not going to proceed with developing  or
finalizing that  until  we have gotten OE  to sign that that is the format
%%yn  Wffl1' f  Now+ L£ IWy* %e tour years  from now that  we have an
acceptable format, but that is the way we are heading now.

                         C-22

-------
Question:
Answer:
Answer:
Question:
Answer:
Question:
Question:
I  am Carl Worster from Region VIII.  I would like to ask Maureen what
languages do you see being standardized in the future?  The bottom line
concern we  have in Region VIII is where does PL1 stand relative  to the
1981 effort?  After you respond to that,  I  would like anyone who is
knowledgeable  to  respond to  this  question:   Would someone  please
elaborate on the Arthur  Young contract  on data elements  and data
standardization? Thank you.

The languages we will initially address  will be COBOL and FORTRAN,
and the PL1 question comes up. I am not sure on the current status on it.
Gene  can correct me if  fm  wrong.  I  think that this will eventually
become one of the three standard languages in  EPA.  When it  does, the
standards will go along with that. Gene and I have kicked around among
ourselves, APL and BASIC.  We have not arrived at an answer to it as
yet; we would be interested in hearing your input, particularly from the
reigonal offices  with the minis.  I think the basic question there is much
more vital.

The Arthur  Young contract is just in the Statement of Work phase, and is
just being drafted, or re-drafted, in its final form. The intent is only to
look at files from the various systems—the  key system and the  larger
systems—to see  if there are any elements within these files that would
be candidates for standardization.  Then, get a list of these candidates
for standardization, and suggest that these could be standardized. At the
same time,  also  suggest some means, whereby a committee could handle
standardization of data elements. All that this  contract would do  at the
present  time is to point out  where  there are  areas that  could be
standardized.

Could you refer to some specifics, what files or systems are you looking
at?
We are looking  mostly at  STORET, GICS, and PCS.
know yet. We also have to define these systems.
We  really do not
Just as a follow-up to my intent in asking for this information, I came to
the U.S. Environmental Protection Agency from the U.S. Bureau of Land
Management.  BLM has a computerized system, used not only in  design
but in programming documentation and in system documentation.  It can
also be used as a means  for standardization for data elements both in
systems and across systems. If this could actually become a nucleus of a
data element dictionary  concept, I would like to describe briefly the
system.  It  utilizes the concept of defining a data element—describing
what it means,  and how  it is used, and how it  ties to virtually every
computer system using that data element.  It creates a cross reference.
It provides automated documentation for each master file in which that
data element is used.  I would offer this for consideration to anyone who
would be in the position of having a need to do this.

I  am Curt Lackey from  Region IV.   Everybody  is talking about data
elements,  systems, and so forth.  There  is another area that I hope
somebody looks at and that  is using instruction techniques, or some kind
                                         C-23

-------
                of  technique  in writing and also documenting models.  Just  last week,
                somebody in my staff spent 10 hours finding the data problem that should
                have been caught by some kind of edit  or something.  When we  start
                looking at documentation  and techniques, let us include the  models all
                over the Agency.

Question:        I am Linda Tucker, Data Branch Chief of the Mobile Source Program in
                Ann Arbor.  I am interested, Maureen, in any  Agency-level  work  that
                may  be underway  regarding data  security standards.   We have had a
                particular problem recently in Ann  Arbor.  Because we are a compliance
                program, we  have  proprietary information from the automobile manu-
                facturers in their  dire  concern  about our information protection.   In
                attending to all those concerned, we recently undertook an evaluation of
                our data security practices.  In order to do that and to come  up  with an
                acceptable  measure  by which  we could be evaluated from an  audit
                standpoint, we had a great deal of difficulty using the ADP Manual or the
                Security Manual to deal with  specific ADP-related questions.  Conse-
                quently, I  had the  contractor actually prepare  data security standards,
                particular to our program and particular to the level of sensitivity of the
                information that we handle. I would be very interested in making  that
                available to anyone who would be interested in  that type of approach or
                in  participating in  Agency-level discussions regarding the  data security
                issue. Is there such an effort underway?

Answer:         I cannot  comment on  the status  of  that, bat I am  sure that  we will
                welcome your input.

Question:        Over the day  and a half of this Conference, there have been a number of
                comments made regarding concerns about redundant efforts in terms of
                software development between the region and  Headquarter's activities.
                We have also recently looked into the software availability and exchange
                question, initiated by the auto manufacturers interest in getting the rules
                of  the game by which we  evaluate their compliance.  In doing that, we
                are coming up with two  already-established, formal  means by which
                software can  be exchanged, and a  couple of  informal possibilities.  We
                are also  finding  that  dealing  with  the  baisc  question  of software
                availability, that the  Freedom of  Information  Act  does  not cover
                software.   Both GSA and DOD have  taken positions that  software is
                considered an exploitable resource  property, having a tangible value and
                therefore not publicly available through the Freedom of Information Act
                channels.  I have raised this with  MIDSD. I think  that MIDSD will  be
                taking an official Agency policy on this, but there is still the question of:
                if we get such a request, if there is an interest region to region, or region
                to  Headquarters for an exchange  or even for basic information  what
                might be available government-wide?  There is a recently established,
                infant program  called the Federal Software Exchange Program, which is
                mandatory in  GSA terminology. Yet, it is undefined or unclear in terms
                of  the interpretation of what it is  to  cover, even if they came out with
                guidelines  requesting  Agencies and  government  entities  to submit
                "common use" programs fully documented.  The Program, itself,  actually
                calls for the submission of abstracts, rather than full complete packages.
                They have a catalogue service  for  which there is a charge of less than
                                         C-24

-------
                $100.  If a request is received, it is referred back to the submitter.  The
                submitter  is  actually asked, at that point,  to produce  the software
                package complete with documentation.  The implication of the FSEP
                program is that documentaiton is available or that  there is  some plan
                conscious  and timely by which that documentation is to be prepared.
                There is also a  slight cost for participating in  the  program.   The
                alternative to the Federal Software Exchange Program is the National
                Technical  Information Service  (NTIS) mechanism.   Some of you  have
                probably  already  used that activity.   NTIS  is  voluntary.  It  is more
                expensive  than FSEP.  You  do  turn over a complete package and they
                attempt to  recover some  of their  reproduction  cost in making that
                package available. It does have a broader distribution potential,  outside
                of the government sector, with industry or private corporation.  At this
                point, the Mobile Source Program has not taken an official stand on this.
                We are still debating the policy issues.  We do have some research and
                some information. If there is interest, I can also make that available.

Question:        I  would like to make a comment on the software information exchange.
                We have seen a  couple of the  catalogues.   There have   been  two
                published. I question how they put a price tag on the software.  Some of
                the things that, at least according  to the abstract,  seem to  be a very
                small  item,  have $1,800 to $2,000  price tags on them.  This does not
                quite seem to be  fulfilling the mission or the  goal intended if it is going
                to be such a cost incumbent system.

Answer:         If I could react   to  that,  I would  raise  the question  with the GSA
                coordinator in charge of  that program.  The answer  that I received was
                that the cost is determined according to an algorithm that considers such
                things  as  processing time, lines  of  code, etc.   It is  not in  direct
                proportion to the development effort.

Question:        I  am John Green, from  Narragansett,  Rhode Island, at the laboratory.
                There are  a  couple  of  things  I  would like to say  with  respect to
                standardization.   One of them  is that one of the panel members talked
                about the different data bases that exist in the EPA. Then there was a
                session yesterday on Distributive Processing.  I think the situaiton  that
                exists is that  we  already have  distributive data bases within EPA.  In
                fact, they are all  over the place. What would  be a good idea is to try and
                integrate the data bases,  and the only way that I can really see making it
                work would be implementing a real computer network. Now one problem
                with computer networks is that computer networks mean  something
                different to  different people.   What I mean by computer network  is
                something like the (unintelligible) that is a real network.  We are not just
                telephone  wires strung across the country from one computer to another
                computer, or teletypes hanging off a remote site.  In regard to the other
                things that the panel  members  were bringing out, If we had a computer
                network, I would  sit down  at my terminal  and I would say what is the
                latest thing  on documentation of software standards. I would be able to
                put that in and get the latest report from Maureen on what the  current
                status of  that thing  is,  because she is entering that in our computer
                terminal.  I would be able to say I could have ready access to that.  The
                same thing goes for word processing.  I  would like to thank Cathy Tittle
                                         C-25

-------
                for her efforts in keeping abreast of what is going on in word processing.
                We just ordered a word processing system for rental, at Narragansett.  I
                started looking at that business and saw about 30 to 50 manufacturers.  I
                knew a few companies.  I knew IBM.  What they had is real expensive; it
                was really lousy.  But a  phone call to Cathy  from our lab, and she looked
                at what we were going to be doing.  She gave about four manufacturers,
                and we went out and scoped them out.  I think we made a good selection
                based on the information we  had, because she has been keeping abreast
                of that.  She is worth your while, if she does  nothing besides that, as a
                clearinghouse.  Another thing regarding program documentation.  There
           ,     is something that  I  try to  enforce,  in the  program development at
                Narragansett.  One thing that I thought about, half tongue in cheek, is
                writing a spec for a compiler that said it would not compile unless there
                is about  10 lines of  documentation in the  front of it, and at  least 20
                percent of our code  is source documentation.  That is the  kind of thing
                that might be a simple  kind of standard  to  implement.  With regard to
                the  language,  my  feelings  on  that  is that I believe  that  the  new
                FORTRAN standards, when they come out, will have character  (unintel-
                ligible) in their places, and  some control structured in it.  I  hope that the
                Agency adopts that standard very quickly.   With regards  to PL1, APL,
                and BASIC, I view those as minor languages.  I think that it would be too
                helter skelter to try to coordinate any  kind of documentation on it. I just
                want to  say  one  more thing.  With  regard  to the  standard  terminal
                contract,  I also had occasion to stumble  across  that document while
                looking  for our  word processing equipment.  It seems to me  that  for
                relatively low cost items, like word processing or data terminals,  that
                the  business changes  too  fast  to  get out any kind  of  up-to-date
                documentation. I would think that a clearinghouse like what Cathy does,
                for standard terminals is in order. I can call her up and say, "Hey, I saw
                this bubble memory, (unintelligible) flashy graphics terminal, can I  talk
                to an Agency computer  with this?"  There would be somebody there that
                would say, "Yes, we know about that. We have tried to document it."  He
                could have something on this network into  which I could key it in, I  can
                ask information on this,  because he is entering that into his own disk  file
                and I have access to it.  That is the kind of  thing to which I would like to
                see the Agency go.  I would like to see it go  to a real network, and try to
                develop software interfaces to the different data bases. In other words,
                the data bases all exist;  they will all have their own entry,  language,  and
                verfication procedures.   They will have their own  inquiry procedures.
                What I would like to see with regard  to the Agency  is come up with  a
                standard  inquiry language for people who want to gain access to this, for
                graphics information for example.

Question:       I  am Sherman  B. Arthur  from Region IX, San Francisco.   I have  a
                comment with regard to programming standardization.   I would think
                that standardization of  programming  should be applicable regardless of
                languages that are  used.    I  would   think that the  application  of
                standardization to  the  few  languages  that Maureen mentioned would
                restrict the value of this standardization too much, because in EPA, we
                use many different languages. For instance, we use PL1 and IRS. Then,
                in Region IX, we do a great deal of computer programming on  the Data
                100 key-batch system.  Also standardization should be applicable to JCL


                                          C-26

-------
Answer:
Question:
Answer:
Question:
and ECL statements.  All of the programming statements should have a
clear  identification of  the  purpose  of  the program  and what  files in
access are applicable, what  variables involved,  and what procedures are
used.   I  would like  to see  the  standardization  of  programming be
developed as language free as possible.

/ could not agree with you more.  Hopefully,  we will  put  together a
standard  with  overall concepts that are  applicable  across  languages,
although we do intend  also to go into some details specific to certain
languages. It has also been our observation that the documentation,  used
when  a program is being modified, very often is just  the source listing.
That is what it often comes down to.  The more information that can be
included in  that source listing, done  in such a  fashion that is readable,
concise, etc., is helpful. The purpose of the program does not have to be
stated six different ways on  10 different pages, but up front, including all
modifications  and a history of what has happened to that program.   I
would  love to  have a  couple of quick and dirty program  listings up  here
that miraculously had a history of  the modifications that had  been made
to them and how often they  had been used.   I think it would  prove a
point, too.

Bill Serovy again from Region I. I would like to make a point about PL1
and other languages.  About 10 years ago, I started college and took my
first freshman FORTRAN course.  At that time, all the upper classmen
thought FORTRAN was a very funny thing; they thought that  it was a
great  joke that anyone would be still using FORTRAN.  At  that time,
PL1 and APL were around and thought to be far  superior languages.  Now
we see that at long last, there is an American  National  Standard either
existing or very close to existing for PL1.  If you talk to people who are
doing  advanced work, PL1 is a funny language.  Government standards
have this way  of becoming stone  age or the lowest common denomina-
tors.   I  am very  concerned that  we have some  provisions,  preferably
formalized for allowing exceptions to these standards.   For  us to stick
with FORTRAN, COBOL, or even PL1 through the 1980's would be a big
disaster for this Agency.  It cuts  down on productivity.  I  think,  it  is
really not in the long-term, best interests of the Agency.

I think we have to build in a certain amount of flexibility, if for no other
reason, than who knows what next language is over the horizon.

About  the  ANSI  standard  on PL1,  it does exist now and is totally
unreadable, not because it is incorrect or sloppily done, but because it is
done so formally that I cannot read it.  The Department of Defense has
accepted  it;   I do not think  that  GSA  and  the National  Bureau of
Standards can  hold out too much longer.  It is true, however, that, to the
extent that something is standardized, it can not long  be state-of-the-
art.   That  is  a very real danger that  you have  to watch.  Telephone
companies are  still  doing  things  in archaic   ways,  so  they  can be
compatible  to  devices that  were  invented  in 1912.  We really have to
watch that.
                                         C-27

-------
Question:       Marge Adler from Cincinnati. I do not necessarily have a question, but
                more of a concern. In regards to the standardization of program design
                and  documentation:  with the  advent of the  minis, and data  base
                management, INFORM, I would like to see the kind of documentation and
                the kind of standards that could be applicable  across even  the mini-
                development, because the quick  and  dirty programs, as we have termed
                it, can all of a sudden become a  de-standard if we are not careful. I feel
                it is very important, particularly with  the  INFORM  and  the experience
                that some of us have already had.

Question:       Bruce Rothrock,  again.   I  would like to get back to this data element
                standard issue again, and the proposed  Arthur  Young study.   I would
                characterize that study  as  being one of whether or not standards can be
                developed in certain areas  in the Agency.  As a result, it begs the real
                question.  I think we already know that standards can  be developed and
                need to be developed. I  am wondering if more meat can be put into that
                particular contract, not  to assess whether we can, but to lay our  specific
                areas where we want standards created.

Question:       I see  no reason why it could not be put  in there, at this point in time. As
                I said it is into the final copy, but there is  nothing wrong with changing
                that  if you have some  suggestions to add.  I would appreciate  your
                delivering it to me, and we will put it  in there.  That document was
                circulated.  I do not know how many of you saw it. It was sent out to all
                ADP  Branch Chiefs and Coordinators back  in July and  August.  The
                comments I received, I incorporated into the current version; if there are
                more, this is a good time to put them in.

Question:       One  question  that  I  have  on   standardization,  special programming
                languages and the approach to system design is, are there any suggestions
                on how these things can  be enforced?

Answer:         / suppose ideally  they -would be  easy  to use.  They would be so much
                better than the alternative chaos that they would sell themselves.  Now
                that is really an  ideal  situation.  One  thing I  mentioned before that
                makes it a little easier to enforce is that it is very easy to reference a
                set of standards in a contract.  It is a lot easier than enforcing it upon
                your own people in your  own office.  You do not have to hear the gripes,
                you just tell them to do it.  That is one of  the acceptance criteria when
                you get that back.  As  far as enforcing it within programming groups,
                such as EPA, and Agency groups it will be done very carefully and with
                great difficulty.

Question:       Curt  Lackey, Atlanta.  I used to be in  DOD, and we had a  team that
                came around.  I mentioned  this  to Willis.  At that  time, he  was more
                concerned with the general systems study and he had some reservations.
                Not too long ago, he said he might get around to the idea that  I talked
                about earlier, but the question of an audit group or  an audit function in
                MIDSD or  in  the audit part of  EPA  is probably the enforcement.  It
                would take some  resources to do that and it may be time consuming but
                that is one approach.
                                         C-28

-------
Answer:
Question:
Answer:
Answer:
Question:
As / mentioned earlier, Willis is proposing, if we can get around to it, to
come  into the reigons and review each of the ADP operations.  One of
the things at which he will be looking is documentation. It would seem to
me that it is a rather easy  extension  to  go from that  review of
documentation to a review of our software, and to enforce it in that way.
I am  sure  that  in MIDSD's wisdom,  they can come up  with suitable
sanctions to those of us who transgress the standard, such as removal of
our ADP suballowance or other nifty things. It would seem to  me that in
addition to the enforcement role MIDSD could play, each data processing
manager would  ensure  that  the standards are followed.   It  is in our
interest to make sure that we adhere to them. The ADP Branch Chiefs
from the regions have been talking about this for several years. I believe
we feel it is in our interest to have  those standards, and as far  as I am
concerned, I will enforce them in my region.  I would assume that the
other regions will do the same.

One problem  that we  do not  seem  to address here, that came out quite
strongly a couple of years ago when we got the 1110 in North Carolina, is
the problem of inter-language compatibility,  file compatibility.  I think
we will probably have  to  accept,  for  some  time,  some  difficulty in
transferring files from one machine architecture to another.  Everyone
would like to see that  fixed up.  There are some efforts underway, but it
is even worse  when you create a file on one mahccne, using FORTRAN,
and you cannot read it using COBOL. Is the  Agency in a position or do
we have leverage in the RFP for the 1981  machine or machines to make
a hard requirement?  If we cannot make it a hard requirement, what can
we do to encourage that sort of compatibility?

Fou would not buy the thing if you could  not  read it  in one language or
another.  There is a lot of work being done with standards interchange.
By referencing  those  standards that have  been  established  since the
UNIVAC contract, Univac,  itself, is having to adhere to those standards.
I assume that  the other vendors are doing  the same towards that goal of
transportability between vendors using a standard interchange code, file
format, tape labels, etc.

It seems to me that that could be part of the 1981 RFP. I do not see why
it should not be~in there. I would imagine we will bring it up, and ask
that it be entered as part of the requirement.  If there are any problems,
we will discuss it at that point.

Marge Adler, from Cincinnati.  I want to direct this to Jim regarding the
standard terminals.  We had run into a situation several times where the
vendors have contacted us directly in regards to nonpayment of invoices.
I am not so very sure where  to direct them to get the answers to their
questions.  I have told them to go to accounting, but they said they have
already talked to them.  I have said go talk  to MIDSD,  and they have
already talked to them.  It almost becomes a witch hunt because of the
money involved.  There have  been cases where a year has gone by since
they have even received payment. The second concern is in regard to the
purchase of the terminals and the maintenance to be performed on these
things.  I had run into the situation just recently where we could call the
vendor and give them  an oral purchase order.  They would then respond,
                                         C-29

-------
 Answer:
Question:
almost  come  out  that  same day  or  at  least the next day, to correct
whatever happened to be wrong with the terminal.  3ust the past month,
however, two of the vendors are  requiring a written purchase order,
which is causing quite a delay in getting  the terminal up and operational
again.  In a situation where we, as a service group,  are trying to provide
equipment for the EPA people in Cincinnati, it means that that terminal
is going to be down for a period of, perhaps, days before we can get the
repair in there.  I am wondering if there is not something that could be
done, in regards to this, without having to go on a maintenance contract.
Most of these terminals are not broken that often enough to make a
maintenance contract cost  effective.

On the  witch hunt for payment of past due invoices, that is about where
it is. The vendor sent the invoice to Financial  Management,  either at the
beginning or the end of each month, depending on the practices of that
vendor.  Financial Management looks at  the purchase request, and sees
whose authorization is  there and to whom the equipment was directed.
They mailed the  invoice to that person  with  a slip on the front  to be
signed and returned to Financial Management for payment. Those have
been disappearing in the mails, they have been directed to people who no
longer exist. I do not know how to get around that.  I really do not. This
is what I said  in my talk about having spent thousands of hours trying to
review  invoices that have  been misbilled and misdirected.  It takes the
phone calls to you, the user, to ask if you received  it and phone calls to
Financial Management to ask if they have received  and paid it. We have
had to ask the vendor to submit a second invoice, and sometimes a  third
and fourth invoice.  Vendors have billed against purchase orders that
have died at the end of the fiscal year, and they continue to bill into the
next fiscal year, trying to find the new order in the new fiscal year that
relates  to the  old order, of the old fiscal year.  Physical, manual labor of
going in and trying to find out who has it and  whether an order has been
issued is huge, and the time delay is horrible.  At  this point, Marge, I
really do not know  any answers. The  answer of having a vendor come in
and provide service prior to cutting the purchase order has two problems.
First, if you have issued a purchase order before the person comes, how
do you know for what amount to make it out.  You do not know how many
hours he is going to be there; you do not  know what parts are going to be
replaced.  The other problem is the Federal policy and law  that you
cannot  have any  work committed to  be  done prior to the  issuance of a
purchase order. It is strictly illegal.  Some  of the  vendors have been
kind-hearted enough to go  in and provide emergency service in the past
to severaZ of our locations. Some places, they still have not been paid. I
think that is probably part of the  problem.   I do not know how to get
around  the  legality of asking the vendor to come  in and perform work
before the purchase order is cut.

In Cincinnati we had a mechanism  where an oral purchase order could be
given to the vendor.  Procurement would call the  vendor,  and assign a
purchase order at  that time.  We did have something to charge against,
and it was not a fact of asking for  the service before a purchase  order.
Basically, however, what has  happened now is that I guess the vendors do
not want to go that way. They actually want to have the written order in
                                         C-30

-------
Answer:
Answer:
their hands before they come out and do the work.  I was not necessarily
referring to the fact of not a purchase order being assigned at all.

If that is the vendor's policy, I do not know any way around it.  They are
perfectly 'within their rights. They have written purchase orders, prior to
performing their required service.  You might have your people issue a
purchase order at the beginning of the fiscal year upon which you can
draw.  That is one possibility.  As far as the invoice problem goes, I am
surprised.  As far as I understand my region, the situation is that the
invoices come directly to us first.  We sign off a receipt of services, and
send them up to Finance. It makes our life a lot easier, and the purchase
order number is on the invoice so that we  know what  we have received
and what we have not. I am surprised that the invoices are being sent to
Finance first.

It  would seem to me  that  it  is an easy change to make to a purchase
order.  If you can get Financial Management to give their work out to the
regions, I would gladly have them go out there.  Any other questions? In
coming up with this idea of the panel, or what to do with this panel, I had
to struggle  with whether to keep it internal to this Agency, or go full-
blown efforts in looking at it across the Government.  I decided to keep
it within the Agency but you should keep in mind that there are a number
of task forces that are currently in operation.  I think the  number  will
probably grow over time.   We have  them, CEQ has them.  They have
started up five  monitoring task forces now to look at  the monitoring
acitvities in five different  areas.  We have a group that is looking at the
relationship between EPA  and the Consumer  Products Safety Commis-
sion, and a few others. They are looking at how we are interacting with
them.   I think  then,  in the future,  what we are going to see  is the
requirement coming to us from Congress and elsewhere to start, not only
coordinating among ourselves within  the Agency, but among the other
agencies in the Government. That will enhance our problems many times
over. Thank you for attending; I appreciate your being here.
                         C-31

-------
                     PANEL D: SYSTEM DEVELOPMENT CYCLE
                               Chairman:  Morris Yaguda

                               Panelists:  Lance Wallace
                                          Donald W. Fitzpatrick
                                          Stephen Heller
                                          Ted Harris
                                    OVERVIEW


                                   Morris Yaguda

     Good morning, ladies and gentlemen. My name is Morris Yaguda, and I am with the
Management Information and Data Systems Division.   I would like to welcome you here
this morning to our panel. The title of the panel is Systems Development Cycle, which is
a real mystery  word.  It reminds me of some of the items that I have seen on menus, a
chef's selection or something like that.   Let me tell  you what we will be doing. We will
have four presentations this morning, and two terminal-oriented demonstrations will be
available  outside  in the  hall afterwards.    Lance  Wallace will  talk  to  us  about the
UPGRADE system developed by CEQ and  which OR&D is interested in bringing into EPA.
Steve Heller will then talk about the Chemical Information System.  The Chemical
Information System is  a joint EPA-NIH development involving an additional half-dozen
other agencies.   For  these two  systems,  after  our presentations, there  will be
demonstrations  in the foyer.  We will then have a bit of theory.  Don Fitzpatrick  from
Arthur Young,  which does  feasibility studies,  will talk about how  he has been  doing
feasibility studies in EPA, what their theory is, their approach, and the philosophy behind
it.  The fourth presentation will be the briefing that we are giving senior management on
the 1980  ADP  systems  procurement.  Some  of  you sit  on the steering group for that
planning  activity,  many of you do not.  I think it is  important that as many people as
possible become aware of the plans  to buy computers for the 1980s.
                                         D-l

-------
                                     UPGRADE
                                    Lance Wallace
      The Office of Research and Devel-
 opment of which I am a part, has recently
 entered  into  an Inter-agency Agreement
 (IAG)  with  the President's  Council  on
 Environmental  Quality,  concerning  the
 evaluation  of  an  automated interactive
 graphic  and  statistical  analysis  system
 called UPGRADE.  UPGRADE is a source
 for user-prompted, graphic and data eval-
 uation.  It has been developed by CEQ to
 analyze  information from  a variety of
 environmental monitoring sources, as well
 as economic,  demographic,  and  health
 data.  The  system includes an integrated
 data base developed to study the relation-
 ships  between  environmental  pollutants
 and health.

      The objectives of  the  IAG are to
 determine how UPGRADE  may best  be
 implemented within EPA. As part of this,
 it is important that all the potential users
 in EPA, whether in the laboratories,  the
 regions,  or in Headquarters, be notified of
 the existence of the IAG and be given  the
 opportunity to evaluate the usefulness of
 the system  for their own program.  The
 intent of this presentation is to give  you a
 chance to increase  your  familiarity with
 UPGRADE  and  introduce   you to  the
 nature  and  the scope of the system, as
 well as its  related data bases.  We have
 here  with us the project leader for  the
 creation of  UPGRADE, Larry Milask.  He
 will be available to answer any technical
 questions you have about UPGRADE.

      UPGRADE has been developed over
 the  past  two-and-a-half years  at  an
 approximate cost of $500,000.  The initial
 CEQ design requirements dictated a sys-
 tem that could provide statistical analysis
 and  graphic  display  of  environmental
 trends and interdisciplinary relationships.
 The system  also had to be accessible to
 the Council's professional staff.  Some of
 them did not possess specialized computer
training.  CEQ's needs led to the creation
of UPGRADE,  which has several notable
features:

     One  feature  is  interdisciplinary
cross-media analysis of data from water,
air,  health,  demographic,   and related
information.    These   data  have   been
selected, and screened  from  the highest
quality  monitoring  data that  could  be
found; they satisfy a set of  strict criteria
put out by CEQ for their various studies.

     The second  feature that UPGRADE
has  is   that  it  is   English  language
prompted.    A  knowledge  of  computer
systems language is not necessary to  use
the system.  It is accessible to managers
and analysts  who  do not have specialized
training.

     A  third feature is that it is  inter-
active and graphics oriented.  It gives the
users immediate  feedback through  online
computing which  allows them to evaluate
and manipulate this statistical data. This
capability  allows almost  instant produc-
tion of bar charts, graphs, polygons, etc.;
in addition, it  can produce  maps of the
country shaded to users' specification on
an off-line basis.

     Finally, its  fourth feature is that it
has access to  advanced statistics.   The
Statistical Analysis System (SAS), is being
interfaced with it now, and it will add a
wide variety of advanced statistical pro-
cedures. UPGRADE has been used for the
last couple  of years  for  a  variety of
environmental and health studies by the
Council on Environmental Quality, and has
produced   some  sections   in  the  1977
Annual Report to Congress.

     EPA's interest in UPGRADE stems
from the Agency's perception of  several
basic needs,  the  first  being the need  for
linking  health  and  environmental  data.
Many recent  reports, including that of the
                                          D-2

-------
 National  Academy of Science have com-
 mented on the inability of the agency to
 relate  environment  quality  to  health
 effects.  UPGRADE can  provide a rapid
 determination of correlations between the
 mortality rate, the main  health variable
 available at  this point, and environmental
 variables.  In a relatively mechanical way,
 one can  run through a large number of
 possible correlations, and  use UPGRADE
 as a hypothesis generator.

      The second basic Agency need is for
 increased analysis of this environmental
 data.  The same reports have pointed out
 the imbalance between the Agency's col-
 lection of data  and its analysis of that
 data.  By  making analysis available to a
 wide  variety  of users,  including  those
 without computer training, UPGRADE has
 a potential  for increasing data analysis.
 The danger that has been pointed out, and
 of  which  we are  well  aware,  is  that
 untrained personnel will use  the data to
 create correlations that are, in fact, more
 far-reaching than the data  can bear.

      Finally, there is a need for the rapid
 investigation of available monitoring data
 and rapid turnaround time  for  informa-
 tion.   You still have the pollutant-of-the-
 month   syndrome   and   congressional
 inquiries, and other request for fast turna-
 round  analyses, maps, charts, graphs,  and
 other information aids; the rapid graphics
 capabilities of this system  can help in this
 regard.

     These  are three needs  that I have
 selected.   I  think there are many,  many
 more specific sorts  of needs, but that is
 the sort of thing we hope  some of  you in
 this room would let us  know and  how
 UPGRADE might be modified to satisfy
 your needs.  I am the Project Officer for
 the evaluation.  My phone  number is 426-
 4657-   That is  at  EPA  headquarters,
 Washington,  D.C.  I  welcome any  com-
 ments  or requests for information  that
 you have.  Dr. James Reisa is the CEQ
 representative on the IAG.

     I will just briefly mention that  the
IAG is  broken into five tasks.  The first is
the System Installation Survey.  Presently,
UPGRADE is  supported on  the NIH sys-
tem.   The question  arises,  can  it  be
supported?  The second task is the User
Needs Survey.  We must find the prospec-
tive   users  and   give  them   time  to
familiarize themselves with  UPGRADE so
that  they can  arrive at recommendations
concerning whether  UPGRADE would  be
useful  in   satisfying  their  needs,  or
whether  it would  be  useful  if  proper
modifications   were   made.    This will
require  an  information  campaign  about
UPGRADE; this is one of the first  shots--
others will include demonstrations  at the
regions and the laboratories.  There is a
questionnaire  that will be developed and
circulated to prospective users concerning
their needs.  The third task is Systems
Design Analysis which will depend on the
findings of the first two tasks.  Depending
on the detailed design specification devel-
oped, it  will  be tailored to  the  results
from those tasks.  The fourth task is the
management  requirement,  i.e., what  is
needed for the optimum maintenance and
operation of the system, including a data
base management system to be developed
for UPGRADE.  Those will be determined
based on  the  findings of the first three
tasks and based on the recommendations
of MIDSD.  Finally, the documentation of
UPGRADE will result in a user's manual.

     Figure D-l illustrates the kind of
statistical  analysis at which the user can
look after he has selected the variables he
wants  to  study  in  the  integrated data
base.  Some of these variables (the first
eight)  are  water  quality  variables, the
next six  are health variables, and the last
is a demographic variable.  You can check
this  table and decide whether any of these
variables have data points  in  which you
are  interested.   The number of data
points,  refers to  counties,  because the
National  Center  for  Health  Statistics
(NCHS)    system    has    county-based
mortality rates.

      Figure D-2 shows a sample correla-
tion. The figure runs heart disease morta-
lity rates on the Y-axis against percent of
the county population living in urban areas
                                         D-3

-------
                                               Figure 1
         £3,157?
HARDNESS, TOTAL
   MAX-  695.P
   HIM-  3.SOO
   HEAM- 131.7
   STDU- 130.9
   NDP-      246.
                                       BASIC STATISTICAL REPORT
                                 *  1970 ENUlROHflENTAL/HEALTH DATA  *
                                     NATIONAL HEALTH TRENDS
                               02
                           CALCJUN.DISS
                              MAX-  760.8
                              urn-  .8000
                              MEAN- 55.a?
                              STDU- 64.10
                              NDP-      183.
                               03
                           flAGNESIUfl.DXSS
                              MAX-  148.7
                              MIN-  .3608E-81
                              I1EAN- 17.09
                              STDU- 16.98
                              HDP-      171.
                               84
                           NITRATE TOTAL
                              MAX-  83.8®
                              C1IN-  .0
                              MEAN- 2.973
                              STDU- 4.283
                              NDP-      141.
    OS
soDiuri.Diss
   nAX-  4-M.9
   MIN-  .e
   MEAH- 47.11
   STDU- 71.30
   NDP-      194.
                               *£
                           ARSENIC,D1SS
                              RAX-  2809.
                              MSN-  .0
                              OEAN- 71.28
                              STDU- 370.5
                              NDP-       98.
                               87
                           CADniun,Diss
                              MAX-  1200.
                              niN-  .e
                              WEAN- 19.33
                              STDU- 129.9
                              NDP-       85.
                               88
                           ZINC.DISS
                              MAX-  .4400E+86
                              P11N-  .8
                              riEAN- 9311.
                              STDU- .S18GE+8S
                              NDP-       84.
CANCER OF STOMACH
   MAX-  241.3
   HIN-  15.40
   flEAN- 97.51
   STDU- 35.83
   NDP-      298.
CANCER OF BLADDER
   MAX*  153.0
   WIN-  .8
   MEAN- 69.59
   STDU- 28.78
   NDP-      298.
    11
ACUTE ISCWEMIC HEART DIS
   MAX-  4S37.
   HIN-  1632.
   MEAN- 2860.
   STDU- 534.2
   NDP*      298.
                                                                                     12
                                                                                 CHRONIC ISCHEH1C HEART
                                                                                    MAX-  3234.
                                                                                    HIN-  465.8
                                                                                    MEAN- 1644.
                                                                                    STDU- 468.9
                                                                                    NDP-      290.
                 13
             CEREBROUASCULAR DISEASE
                flAX-  3131.
                MIN-  718.7
                MEAN- 1156.
                STDU- E33.9
                NDP-      S98.
                 14
             MAJOR CU DISEASES
                HAX-  8488.
                fllN-  4085.
                MEAN- 648S.
                STDU- 762.9
                NDP-      298.
                 15
             X URBAN
                MAX-  188.8
                RIH-  22.68
                MEAN- 67.27
                STDU- 18.26
                NDP-      290.

-------
   4836.SO   r
g  41S3.S3
U
T
E  3872.36
I
C  3550.88
H
E
S  2264.96
   1943.48
1622.60
       22.60
                    Figure 2  1970 EKUiRONnENTAL/HEALTH DATA
                                   NATIONAL HEALTH TRENDS
                                (1ST ORDER LEAST SQUARES FIT)
                          SIGNIFICANT AT THE 9SX CONFIDENCE LEVEL
                                                                                         V INT •   3263.SIS
                                                                                         II •   -5.99931
                                                                                         F •   12.647
                                                                                         R -   -.205
                                                                                         T •   -3.556
                                                                                         NDP  •   299
                        -k
35.50       48.40       61.30
               X URBAN
                                                        74.20
                                                                    87.10
ICO.CO
                                                                       NOVEMBER 28.1977

-------
Figure 3

    -  *   NATIONAL HEALTH TRENDS

Y-AXIS« CANCER OF STOMACH
X-flXISl NITRATE TOTAL


THE SOLUTION POLYNOMIAL OF ORDER 1 FOLLOUSl


Y •   1.0114D+02

    +  C-8.7860D-01)tXm


                  ANALYSIS OF VARIANCE FOR POLYNOMIALS
SOURCE OF
VARIANCE
TOTAL
DUE TO NTH
DEGREE POLY
UNADJUSTED
(N-DTH POLY
ADJUSTED FOR
NTH TERM OF
NTH DEG POLY
ERROR
DEGREES OF
FREEDOM
141
2
1
1
139
sun
SQUARES
0.1577990+07
0.1371400+07
0.13S890D+07
0.2492660+04
0.8065910+06
MEAN
sun SORS.



0.3493660+04
0.1486260+64
F
VALUE



0.167713D+01

THE FIT IS NOT SIGNIFICANT AT THE 95* CONFIDENCE LEVEL
TAKE A HARD COPY FOR THIS CASE. IF YOU UI5H.
THEN PRESS RETURN TO CONTINUE.

-------
on the X-axis.  The numbers on the right-      shows  a  trend,   a  five-day  biological
hand  side  are  the  statistical  analysis      oxygen demand at a certain station.  The
which is automatically run by the system.       X-axis is years. Figure D-5 is an example
                                             of a polygon plotting  feature.  These are
     Figure D-3 is a table of the analysis      the total suspended particulate measures
of  variance  for  polynomial  regression.      from  a  24-hour sample,  taken every six
Figure D-4 is a sample of a bar chart.  It      days.

-------
    Figure
                     12SCTYS.EASTERN

                            RIVER MILE  5-1.94
    L

    fl
    I
    T
    S
0
e
            3.84
       3.3? ,45.00
                        3.0?
    1
    •
    2
A   0
u   e
E      5
R   T
A   0   D
G      A
       n
       G
          a.93
          a.
    B   a.so
    0
    D

       2.71
       a.ea
          a. 53
          a.
       L  2.3S


          a.27
          a.is
                             45.00
                                     e.sa
                                                 a.45
                                                 19.09
a.5i
as.ee
                                                              a.se
                                                              16.09
                                                                       a.44
                                                                       ai.ee
                                                                                  a.ia
                                                                                  18.00
                 63.80           71.00            73.00
                         70.04            7a.ee            74.09

                                           SAMPLE DATE YEAR/MONTH

                                        UPPER LiniT  OF INTERVAL
                                                                  75.00
                                                                                   77.00
                                                                       76.60
                                       TOP BAR STATISTIC •

                                           AUERftCE

                                       BOTTOfl 3AR STATISTIC «

                                        NO. OF DATA POINTS

                                        IN IMTERVAt


                                        1ST Y-AXIS PARTITION

                                        IS PLOTTED
                                                                              NOVEMBER 38,1977

-------
Figure 5
  io.ee
                   CEO.SflROAD.NEP.COAL.CNTYSaa
                       !5ii35oeiHoa EAST CHICAGO
AP    KA    JN    JU    AU    SE    OC    NO    DE    JA
         JA    FE    fIR
       1975
                                          CftTE
                                                                    NOVEMBER 33,1977

-------
                       THE CHEMICAL INFORMATION SYSTEM
                                   Stephen Heller
     I'm going to be  describing a rather
unorthodox computer system being devel-
oped jointly  between our agency  and the
National Institutes of Health.  It  is more
of a bottoms-up system development, than
a top down, simply in that there are a few
people who believe  there was  a need for
the  things  I  will describe.   When  the
system got so big, it became clear that we
had to become a little more orthodox.

     This  first  slide gives an outline of
the way in  which  the system has  been
developed.    The Chemical Information
System  (CIS)  is  a series of numeric data
bases and  a  family of interactive pro-
grams  with  which  to search  these data
bases.   Tw.o  main  areas with which the
user  can  interact  are  literature and
normal bibliographic services.  Within the
Chemical  Information System  directly,
there are only a  very few related specifi-
cally  to  the  data banks of bibliographic
data available. There are, however, addi-
tional links to other  literature references.
On the right-hand side, there is a data and
analysis section.  This comprises the bulk
of the Chemical  Information System data
banks, mostly spectral and more recently,
toxicology data banks.  The analysis por-
tion involves a  program  called  MLAB,
Math  Lab.   In  the center of the  whole
system is something called sub-structure
search.  This  is the  part of the CIS about
which  I  will talk.     It  requires  some
explanation and  perhaps a  little bit of a
background.   Each chemical   substance
that the agency has in its files and  its
data banks,  that we regulate  or  that we
are trying to regulate, that we  know or do
not yet  know in  terms of  being toxic or
pollutants—is being  assigned   a  unique
identification number  similar to a  social
security number  for  a person.  It is called
a  registry   number.     The   Chemical
Abstracts Service (CAS), a division of the
American  Chemical Society,   has   been
doing this registration  work for EPA since
1974.  At  present, there are about four
million  of  these  chemicals  which  have
been assigned numbers. These are pretty
much the known public chemicals. There
is  probably an equal  number of private
chemicals  that have been developed  at
universities or  within industries which
have not been reported, patented, or ever
used.  From this  enormous bank of four
million, we have been going through the
Agency files of chemicals, STORET, the
pesticide data bank, TSCA candidate list,
etc.,  and coming  up with sub-sets  from
the  four  million.   First,  we  have  an
administrative list indicating the different
data banks  which can be  organized and
linked together through  this registration
number,  (e.g. you  could find how  many
data banks have something on benzene in
it, and  so  forth.  )  We also have,  asso-
ciated with  this  registration number,  a
computer readable representation of the
chemical structure.  For any mathemati-
cian who knows  something  about  graph
theory,   it  is  simply a  graph  of  the
chemical.  Most of you, I am  sure, are not
chemists, but probably have  seen one or
two   chemical   diagrams  in  your  life.
Fortunately,  they are nothing more than
just lines drawn together with some funny
little characters.  Primarily, they are just
simple graphs, (simple pictures),  enhanced
very readily and adaptable within a  com-
puter, (which does not understand the first
thing about chemistry), but knows  about
points and  space and connections between
points. The sub-structure search software
system  allows  one to search  for   these
graphs,  for these chemicals, within the
data bank or data banks, as would be the
case when you have more than one file, as
with the multitude of agency files.  You
can search for the complete structure of a
specific chemical  or you can in fact, look
for parts of chemicals.   The  pesticide
people seem to feel that any time you find
a chlorine in a molecule,  it will probably
be a  pesticide  or  a related pesticide.   It
                                         D-5

-------
 will also probably be toxic.  If it happens
 to be attached to a benzene, it will likely
 be even more toxic.  Thus,  you can look
 for all  benzene compounds with chlorine,
 for example.  The result of such a search
 would be a list of the chemicals that meet
 this  criteria.    Obviously,  benzene and
 chlorine  are   found  in  many,   many
 chemicals.  So, you are likely to get a long
 list  of  answers.   Also, besides  getting  a
 list  of  the chemicals that meet the query
 in terms  of retrieval, you will  find out
 which  data banks  in  the Agency have
 information of  these chemicals.   They
 may very well just be reported, or have a
 regulation pending on it.  In the  case  of
 STORET, where  there are a  few hundred,
 mostly  inorganic, but some organic chemi-
 cals, you; will  discover  that there  is  a
 great  deal  cf water quality data  asso-
 ciated  with that chemical.   There is  no
 sense in going to STORET to look for  a
 particular dichlor  benzene if that is not
 one of the elements on which  STORET
 collects data.  This is a link, a way to tell
 you whether or  not  it is worth  going  to
 this other data bank for information.  You
 can tell  very  quickly which data banks
 within  the  agency,  and  to  some  extent
 outside the agency, may have some useful
 information on the chemical in which you
 are  interested.   It  does not, however,
 generally tell you what the information  is,
 and it  does  not tell  you  whether the
 information is good  or bad.   It does tell
 you  what there  is in terms  of  the gross
 answer. This next slide gives some indica-
 tion about the groups that are working  on
 the  joint development.   This is a fairly
 large project  in  scope.  Besides  NIH and
 EPA, we  have the Bureau of Standards,
 the  Food and  Drug  Administration, and
 the Department  of Energy.  The National
 Cancer  Institute  is also providing funding
 and support for the system.   Outside the
 government,  we  have  a   variety   of
 contractors, and collaborators.   In some
 cases, we  are not even paying some poeple
 for the  work they are doing.  There is also
 a  variety of  foreign organizations  and
 governments,   the   British   and   Dutch
 governments,  working in connection and
collaboration with the development of the
system.   One  of  the main reasons for
doing the collaboration is that besides the
expense of the project,  the expertise in
many of these areas lies outside either the
Government or, in fact, the United States.
Since  the   problems   are  essentially
universal in nature, the pollutant found in
Siberia turns out to be about the same as
you  will find  here  in  Annapolis  or  in
Chicago.   It  is  much  easier  to  work
together to put together this information
and have the computer systems retrieve it
than  it  is  to work  separately.   The
collaboration between these organizations
indicates that obviously we are  not the
only ones  who  feel this  way.  (The next
slide please.)

      We have  a number  of users in the
testing and  evaluation stage of the sub-
structure search system. We had about 81
groups here in the  United States from the
Government, universities,   and  industry,
who were using the system and evaluating
it.  After  we felt the system was working
well enough and the people were actually
willing to  pay for its  use, it was then
transferred to a commercial system.  In
May,  1977,  the  demonstration  network
testing and evaluating ended, and went on
to the Tymshare computer network, where
it  is  available  to  anyone  who wants  an
account.   In the demonstration here this
morning, we  can show you exactly how it
works and provide  you with the accounts.
The data files, as  I indicated before, are
primarily these CAS registration numbers.
There are the structural diagrams of the
various names  of  the  chemicals,  the
approved index name, the standard name,
and the technical name that chemists use.
In  addition,  there  are  usually  a lot  of
synonyms  and practical  names.  DDT is
not the proper name  for the pesticide, but
if  you don't call  it DDT,  nobody  knows
about what  in the world you are talking.
You need to have these  various synonyms,
trade names, and commercial names asso-
ciated with it.  At the time this slide was
put together, we had about  50 files in the
process, we  now have about  100 files of
which 40   or  50  have   already  been
completed.   There  are roughly 400,000
                                          D-6

-------
references  and  a  little  over  250,000
different  chemicals.  These  various files
are pesticides, TSCA, STORET, and files
from other Government data banks, from,
for  example,  the  Consumer  Products
Safety Commission,  the Cancer Institute,
and so forth.  The entire data bank that is
being searched is being put together right
now  with EPA funds, mostly  MIDSD, and
the  data-searchable  elements from the
Chemical Abstracts  Service.   There  is
nothing more than these names, the regis-
tration  numbers,  and   the  computer-
readable representation.  That is what we
are doing.  We are now  linking  them  to
other  files  but the  other  files  are not
physically  on   the   same  computers.
STORET is still where it always has been
but  we  can tell  you whether  or  not a
particular chemical is in the STORET data
bank,  and whether or not you should  go
there to look up information about it. The
next slide is analagous to this and refers
to the various data  banks that are  tech-
nical-    and   instrument-oriented,   and
scientific  instrument-oriented.   In  this
case,  our  users  number close to  300
laboratories in the United States, Canada,
Western  Europe,  and even  someone  in
Eastern Europe now.  All of  the regional
labs, ORD,  the pesticide office, Enforce-
ment,  and  the  Water and   Hazardous
Material labs all are using this system in
normal everyday routine identification  of
unknown  pollutants  of toxic substances.
The  input  information  is  normally the
measurement from a lab instrument in the
case of mass spectrometry,  which  is the
primary  toll  of  identification  of  the
agency labs.  In addition, you can  put  in
toxicology data, such as LD50  data,  for
example, (the dose to kill half the popula-
tion), along with other parameters such as
whether it has to be orally injected, and
whether it is a mouse or rat or whatever.
Then get out the chemicals that meet that
criteria.  Of course,  in the identification
of pollutants, the ideal answer  is to get
out the pollutant that is being identified.
We now will link that answer  with the
toxicology data so that we will know if we
have made an identification; you will also
know  if  this  chemical  that you  have
identified is toxic. If so, it will be a likely
way  to tag it as being something  about
which to be concerned.  If you identify a
lot of pollutants that are not toxic, then it
may  be useful to know this.  It  may  be
necessary to check with the permit pro-
gram to ensure that these chemicals could
be, in fact,  discharged.   When you start
finding  large  concentrations  of  toxic
chemicals,  then you  have more than  a
permit problem.  You may have a  very
serious  health problem.   So we  will  be
linking the  toxicology data to the spectral
data.

     The  files  vary  in  size,  from  a
hundred in  the infrared data bank, which
the  data  bank  is  just  being  started,
through as  many as 30,000 X-ray spectra;
The  mass spectrometry data bank is the
responsibility  of   the  Department   of
Industry  in  the Mass Spectrometry Data
Center in England.   The Carbon-13  data
bank  is  the responsibility of the Dutch
Chemical Society through the Netherlands
Information Combine.  The X-ray system
is being  run through  the  Department  of
Energy   at  the  Brookhaven  National
Laboratory. The contributors of the data
come from  the Agency as well as from the
outside, both in the United States and in
many countries overseas.  (The next slide)

     There are a few slides like this, and
the purpose is to try and give you an idea
of how the system is being developed.  It
is  somewhat of  an unorthodox  way  of
doing it, but it  seems to be  working.  We
seem to have a  lot  of  users, a  lot  of
pleased users, even to the point that they
are paying  money on commercial systems
to use  it.    This is  in  addition to  the
Agency group users or to others outside of
the Agency who are users. In the case of
the  mass spectrometry,  where  we  have
about 300  laboratories, less than 10 per-
cent of those are EPA labs.  In this case
of the sub-structure search, the system is
being developed  on a government com-
puter.  It is not an  Agency computer, but
a NIH computer, a POP 10. The POP 10 is
a  large-scale  time  sharing computer;
being  exclusively  time   sharing  it  has
                                          D-7

-------
 really  no batch  capabilities.  Once the
 system is complete,  in the sense that we
 believe that it is  a viable working system,
 having been tested  by the users,  the
 system is then transferred  to commercial
 vendors, where it is made available to the
 Agency and others.  It is maintained  by a
 particular  contractor  or   collaborator,
 responsible for the operational aspects of
 the system.  At present, we do not pay for
 the  storage  of   the data  banks.   The
 storage of all  these data  banks  comes
 from the usage of the system. So, there is
 some economic incentive for us to get this
 thing out and used by the public.  We can
 reduce our expenses in  the sense of  data
 bank storage.  We only pay for the usage.
 The  user  interacts  directly  with  the
 operational version of the  system, in the
 sense of  getting  a commercial computer
 account  and directing his questions  and
 day-to-day problems  to the  organization
 responsible for maintenance.  All  of the
 software  has been  developed  by  the
 Government, starting at  NIH  and  now
 under  contracts  through  EPA   funding.
 The  software  is  in the public domain as
 well as  in  the   data banks themselves,
 having been purchased completely  by the
 Government.

      Once you take  the 80 or some users
 who are not paying anything and  ask them
 to pay money, the  usage  falls  off a bit.
 We are  down now  to  about  23  users,
 although  these groups are growing as time
 goes on.    There is  a minor subscription
 fee, and then the average costs of search-
 ing; the connect  time plus the computer
 time right now is averaging about $75 an
 hour at commercial rates.  We are in the
 process of putting up all these data banks,
 but we  now  have  only  five   of them
 available  which are being used on a daily
 basis by some two dozen groups.  Three of
 these are EPA files;  two of these are the
 spectral data banks.  The TSCA candidate
 list was the largest and the first that  was
 put  up.   This  was related to the Toxic
 Substance Control Act inventory program.
 This is the candidate list for which  the
 reporting, I believe, will begin in January
in support of Section 8 of the legislation.
We  have  the  list  of  active  pesticide
ingredients.  We also have  the spectral
files. The mass spectrometry and Carbon
13 round out the other two. The  next slide
is  probably a little bit more representa-
tive  of what is going on. The reason we
only  had  five  up  is  that  we have been
making some changes to  the software and
enhancing the  capabilities of the system
to have something a lot more useful.  This
is  the  list of 32  files  that  are being
processed and will be up very shortly, by
the end  of the year, I think.  They are now
beginning to link  together  the  various
agency data banks, and  other data banks
outside the agency of interest.  Again, if
you  go  with  this pollutant of the month
philosophy, you want to know,  are there
any definitive studies on these chemicals?
There are about a thousand of them.  You
can look them up and say, "Aha, there is a
definitive monograph.  Let me go over  to
the  Consumer  Products  Safety  Com-
mission  and find out  where  I  can get a
copy  of  it."    That  is to what that file
refers.  The  registry of toxic effects  of
chemical  substances  is  a  long  list  of
toxicology data  associated  with about
20,000 chemicals.   That is actually being
linked directly to the system. The second
one  is  a  national  occupational hazard
survey  which  went  into  a  variety  of
industrial organizations  to find  out the
chemicals  being  used  in  these  various
laboratories  and  factories.     The  NSF
chemical  list  is a  list  of priority  toxic
chemicals. The National Cancer Institute,
Public Health Service 149 list is a list  of
chemicals  which  have  been tested  for
carcinogenicity.   It  does  not  tell  you
whether  the results  are  positive or nega-
tive,  it  just tells  you that the chemical
has been tested.  It  is not as good and as
useful as  it can be, but it helps.  It turns
out that the book itself that the Cancer
Institute  published   does  not  tell  you
whether  or not it  is  positive or negative,
it  just tells you what has been  tested.  It
can  give  you the actual reference to  it.
(You  discover  very  quickly  in  putting
together data  banks, how little informa-
tion  it turns  out to  be in most  cases, but
that  is another story.)
                                          D-8

-------
      The  National  Institute  of  Mental
Health  has a file  on drugs; if you want
some information on LSD you  can go into
that  file.   There  is an  X-ray  file  that
came from the Cambridge Crystal Data
Center   in  England,  the  World  Health
Organization  drug list,  the  International
Trade Commission,  commercial  organic
chemicals, etc.  These are, again, a list of
bibliographic  chemicals that  have been
tested for mutogenicity.  It just tells  you
that  somebody  has tested  for it.   This
would be a useful piece of information,
knowing whether  or  not to even bother
calling  up Oakridge  and asking them  for
their references.   There  is  a  pesticide
index to the number of pesticides  that
have been put together by a private firm.
The index is a  very  popular handbook of
about 10,000  chemicals of  very common
chemicals with  properties associated with
them.  There is a list of chemicals being
studied  by the  common  market and  a
toxicology center  that EPA  is  putting
together  with TSCA. In Italy, there  are
about 3,500 chemicals on which they  are
collecting toxicology data, and we have a
link into their first go-around list they  are
establishing.  We  have a National Fire
Association list  of hazardous  chemicals
and flammability  information associated
with  them.  There are literally hundreds
of other files that we have not yet seen.
We are  trying to process these things as
quickly   as  possible.   It turns out that
because this had never been done before
in  any   sort  of organized  fashion,  the
backlog is enormous.  We know of at least
160,000 or 170,000 that we have not  yet
processed and suspect  there  is probably
two or three times that number which we
have not found.  We are slowly but surely
trying to do this.   We have a contractor
now, someone working full-time, just try-
ing to find  these  files.  In theory, all of
these things should have been processed in
the past. Our office had implemented  a
regulation, an EPA order (2800.2), which
required the tagging  of all chemical data
banks in the  Agency  with these registra-
tion numbers.  People, however, have been
slow to  find the  regulation and implement
it, and we have been  more or less working
with  people  who wanted to  cooperate
rather than running around batting every-
body  over  the  head  in  the  Agency,
demanding that they register  their chemi-
cals.  In turns out it is probably a good
idea,  because we  could  not  handle it if
everybody decided to  cooperate.  (Next
slide).

      This just gives a little bit of the
background for the TSCA file.  There is a
reference for anyone who is interested in
the details of this computer system.  The
structure search requires the user to have
the picture of the chemical.  We are also
adding the capability of search  for names,
but it is primarily viewed  as a structure
system.   It  is  useful only  for  discrete
chemicals. Many of the chemicals on this
TSCA list, and in  the final inventory list,
will not be  discrete, but generic chemi-
cals.  When  you search the TSCA list you
get   the  registry   number,   the  TSCA
clerical code designation number.  You do
get out  the various names,  even though
you cannot search for them  immediately
right  now, and you  get, if you want the
structural diagram.   You  can  actually
figure  out  what  that  name  means  by
looking at the picture.  (Next slide.)

      If anyone is interested in using this
system, they just contact the contractor,
Fein-Marguart Associates; they have been
providing computer accounts to people in
the Agency.  Actually, this slide  was used
for a  public meeting where people outside
the agency  have  to  contact  Tymshare
directly. (Next slide)

      This is just a very brief idea on how
the system  works.  I want  to  give one
example.  This slide shows very  simple
commands being put together.  These can
be  put  together  at an ordinary terminal
with,  say an IBM  Selectric,  or  any other
kind  of terminals you have in  the labs or
offices.   These commands take about a
half hour to figure out exactly how to use.
From there,   you  go  full  speed  doing
whatever kind of searches you want.

      The next slide show an example of
one  of  the  searches.   At the top, by
                                          D-9

-------
 generating  the  command's  ring,  alter-
 nating bonds,  adding branches, and  substi-
 tuting  atoms,  we  come  up with  that
 structure.  We  then go in and using  that
 structure search, identify a compound.  In
 the future, you will be linked directly to
 the spectroscopic  or  toxicology data  or
 the plants and production data, so you can
 actually   print  out   this  information
 directly.  In some cases, like the STORET
 data, we  will  not take it all and put it into
 this computer;  we'll  link it directly.  In
 the case  of small  data  banks we will  be
 able to have  the information printed out
 directly.    That is the  way the  search
 works.  It takes a few  seconds to generate
 the theory; with the  system interactive,
 you get the immediate  response.  (Next
 slide please).

      This is a search using the  TSCA list
 looking for a long chain compound.  This is
 an exact  match for this chemical and the
 bottom shows the chemical structure, the
 registry  number,  and the other  TSCA
 information associated with it.

      The next  slide  is  for those  people
 who have something a little fancier than a
 teletype;   this  is  actually  a   $400,000
 graphics  terminal  that NIH has.  If you
 don't like those teletype outputs, you can
 get a  much nicer  looking  chemical  dia-
 gram  drawn  out  with  the  space-filling
 model.  These are the fancy ones you can
 get and anyone who would like  to  have a
 chemical  structure  drawn with that termi-
 nal, we would be delighted to provide  it.

     Our next two slides give an example
 of getting out some toxicology data where
 you are going into  the NIOSH RTECS file
 asking  for  oral  rat  LD  50  data  and it
 comes up and says there  are  111 com-
 pounds that have oral rat LD 50 data  from
 this set that we are using.  The next  slide
 is an example of what the output would
 look like.  There is oral rat LD 50 260
 milligrams  per kilo   and the  literature
 reference and the name  of the compound
 associated with it.  This is  the sort  of
 toxic data that  you would get from doing
a data search.  The next  slide is again an
overview of how the X-ray system works.
The Government as well as Case Western
are  developing   the   X-ray   and  the
informational  analysis  programs.  Brook-
haven  is acting as the responsible party
for making  it  available and maintaining
the program.   This case is  available on
another commercial network.   With the
CAMSEQ  program     the   substructure
search works on a two-dimensional picture
of the  molecule,  of  a two-dimensional
graph.  The  fancy  picture I have with the
color  of  that  one molecule is actually
generated from three-dimensional coordi-
nates, the X, Y, Z positions in space, not
just X and Y.  The question is how do you
get between two  and  three dimensions.
The  answer  is  you  use this  CAMSEQ
program which takes the two-dimensional
picture, using a variety of mechancial and
similar techniques.  It comes up with an
approximation, which is very,  very close
to the actual real structure; it enables you
to draw out the three-dimensional  struc-
ture of the molecule. This is  going to turn
out, I think, to be very important in the
future  when  you  talk about  structure-
activity correlations for  making predic-
tions, and so forth. Molecules  have three
dimensions.   The  property  of   molecules
are dependent upon their actual three-
dimensional  structure.  This sort of infor-
mation will  be a  necessary  extension of
what has been going on in the past.

     After  the X-ray  system, I have a
slide that tries to describe  the evolution
of the GCMS instrumentation  technique,
and how  it  relates to some of  the laws
that  have been going  on  in  the past and
are being implemented.    The use  of
computers in this instrumentation area
started  about  10   years  ago.   It  first
started being  used in EPA labs about six
years when essentially this project of data
banking and  identification  got started.
One of the first things that came out of it
was the chemicals, found in  New Orleans
and the other water  systems.  Suppose
carcinogens  were  all identified using this
data bank and using this type  of instru-
mentation.  There are people who believe
that the Safe Drinking Water Act of 1974
                                         D-10

-------
was passed because of the scare tactics of
these cancer chemicals in all  the  waters
around the country.  Again, the identifica-
tion  and  proof  came from  this  system.
The  Toxic Substances Control Act  calls
for the identification of  these chemicals
and their  monitoring.   The Agency relies
primarily  on these  spectroscopic  finger-
prints,  these identification tools.  The
need for this data bank is readily available
for ourselves and industry.  We think it is
extremely important.  (The next slide).

      This is now an overview of the mass
spectrometry system  being developed  by
the Government.  The operational  version
is the responsibility of the  Mass Spectro-
metry Data Center in England which is
funded by the British government.  Again,
in this case, it is  made  available by the
ADP  Corporation  on their  international
PDPlO's;  there is a minor subscription fee
and various use charges associated  with it.
(Next slide).
     As of last month, there were about
280 labs using it, what amounts to 4,000
searches a month.  There is a subscription
fee of $300;  prices vary from $1 to $15
for searches.

     There   are   something   like   30
different options to search the  data bank.
Different labs have different approaches
and different needs for looking up infor-
mation,  depending  upon  the  individual
viewpoints of the people in the labs.  We
have  developed  a variety  of software
options to search  the data bank.   The
answers normally come out the same, but
some people  happen to like to do things
one  way, as  opposed  to another, and as
long as we can provide this without any
real  difficulty  we continue to make as
much of the system available in as many
ways as possible.  We feel that trying to
lock people into one particular approach is
self-defeating;  they will just go up and do
it some other way.  It is  much easier to
try and offer the flexibility within the one
system.
                                          D-ll

-------
                                    COMMENTS
                                   Morris Yaguda
     Those of you  that  have heard  me
talk on previous occasions have probably
heard  me refer to the Dick Nolan Stage
Hypothesis.   It  has  been  one  of   my
favorite discussion  topics  in terms of
understanding what data processing can do
for people and also what it  is doing to
them.   I would just  like to  make  a point
here that,  in the hypothesis, you go from
Stage Three, which is a period of gaining
control over your data processing to Stage
Four, which is involved with integration of
systems.   Hopefully,  agencies are  now
moving from Stage Three to Stage Four.
One of the things that you can expect is
to see systems like UPGRADE, where you
are trying  to integrate information from
various data bases and not just processing
a particular application. I think you have
seen  this  in  the  Chemical Information
System.  There is an attempt to integrate
a lot of information and to try  to gain
superior control over agency missions.  I
would  also like  to  point out  that   the
Office  of  Toxic Substances, during   the
last  year,  commissioned MITRE  to do a
very basic informational requirement ana-
lysis  to support  the  Toxic  Substances
Control Act.  That  study tries to under-
stand  what   the  needs  of  regulatory
agencies are to control toxic substances.
It  also asks what  information  is needed,
what  information  sources are available,
and what systems need to be  developed.
It  sets out a ten-year blueprint for infor-
mation systems development  and planning
activity.  The Chemical Information Sys-
tem is one  of  the key elements in that
plan.  I think you have gotten a feel from
the presentation today as to  what sort of
capabilities are offered.   I  think if you
have the time  to  see that MITRE  study,
you  will  understand it  in  the greater
context of regulatory agencies trying to
gain control over toxic  substances.   Since
I have  mentioned theory, our first two
presentations have really been practical
examples.  The first two  talks have been
living examples of systems  that are at-
taining  maturity  and  working  through
their  early  evolutionary  stages.   Within
MIDSD, we have a task order contract to
perform system studies  that  require some
rather unique skills.  At the present  time,
Arthur  Young  is  the incumbent on that
contract.  Don Fitzpatrick is the Arthur
Young Project  Manager for the contract.
He will now give us a presentation on his
approach for doing a feasibility study.
                                        D-12

-------
                             PLANNING FOR THE 1980's
                        Morris Yaguda and Theodore R. Harris
     Ted and  I  have been making  this
presentation  around the  agency.   We are
at the  point in  planning  for the 1980's
where  we  are  talking to  a lot  of EPA
senior managers.  This is the briefing that
we give to them.  We try to bring to their
attention the  fact  that  we  are  talking
about an agency-wide ADP support for a
10-year  timeframe; it has to follow some-
thing called OMB Circular A-109, which is
an OMB management circular for  major-
systems  acquisition.   It   is  rather  an
expensive item for which we are planning.
Estimates vary between $300 and $450
million  at this time.   We  talk  in the
background about our management control
of  data processing.  We  talk  about  a
driving function that is making us do this
planning, namely, that our present service
contracts and  capabilities  are expiring.
We also go into some details on the plans.

     I think  many of you are  aware that
the two major, central, data management
resources are used in just about every part
of the Agency.  They serve many, many
applications throughout the  Agency. That
is the point of this chart.  The manage-
ment of the ADP  operation  in EPA and
ADP applications system is split  between
a central office of  the Management Infor-
mation Data Systems, which is responsible
for  providing   the  central   computing
centers  as well as general  oversight and
coordination.  The Program Management
Office is responsible for determining the
need  for  planning,  implementing,  and
operating their  own individual applications
as well as providing for whatever local
people,   contract   and  equipment  are
needed.   You have seen in your experience
with EPA what kinds of control  mech-
anisms  we   use.    These  are,   in  my
judgment, the  state-of-the-art tools for
controlling ADP.    They are  consistent
with the paper  that we have often talked
about before, the Nolan Stage Hypothesis.
I think many  of you are familiar with our
Zero-based Budgeting Program. We have
full  charge back  of  utilization of  the
central  computer   and  make  them   an
accountable resource.    Additionally we
require  feasibility  studies  for  all  new
applications.  Most  of you are aware that
we  have in EPA two major  sources  of
central  computing  resources.    One  of
them is the COMNET contract awarded in
1976, and expiring in 1980. That contract,
as you know, provides the communications
network which links all of you out in the
field—in  the  regional  offices,  labora-
tories, State and local governments—with
the Headquarters' computing facility.  In
North Carolina, we  have  the  UNIVAC
equipment  which  is  government-owned,
for   the  most  part,  in  a  government-
furnished building, but which is  managed
by  a facility  management  contractor.
That contract  was recently awarded in
September, 1977 and will expire, also, in
1980. Obviously, we are at a point where
in the beginning of the 1980  period, we
will  be out of sources of supply; something
needs to be done. Let us go into what it is
that we are  going  to  plan  for replacing
these basic service contracts.   This  dis-
cussion  I  would like  to present  will  be
organized on these four points.   We  will
talk a bit about what the constraints are
in our planning.  We will go into a little
detail on the A-109  process which is a new
process.  We will talk about  what we have
done in EPA and what our next steps are.

     The  first  constraint  is  that new
kinds of services we buy have to fit into
our management concepts.  We have been
beaten extensively about the head  and
shoulders  and urged to gain greater and
greater  control of  our data processing
costs.   We have gained  that at  a con-
siderable investment in learning. You just
can  not lose control of data processing.
We  also have considerable organizational
and  staff investment in learning.  You just
can  not lose control  of data processing.
We   also  have  organizational  and  staff
considerations that have to  be consistent
                                         D-13

-------
 with approach about which we are talking.
 We  have decentralized systems  responsi-
 bility.   We do have  nation-wide  require-
 ments  and  severe  limitations  on  what
 positions are available  to  support  data
 processing  applications.  This means we
 are  very  heavily  dependent   on  con-
 tractors.  Solutions that  might call  for a
 great  number of in-house  positions are
 really not feasible.

      The   second   constraint   is   a
 scheduling  one.   The new  service capa-
 bility  must be in place in time for  an
 orderly conversion before the current ser-
 vice contracts expire.    We  have  been
 planning on this basic kind of a milestone.
 We  have been saying we need one year for
 planning and  justification of our  require-
 ment, six months  to develop a solicitation
 document, eighteen months to have a fully
 competitive procurement, and at least one
 year for an orderly conversion period.   A
 four-year period may seem  like an awful
 long time.  I should  tell  you that this  is
 believed by  many people  to  be  a  very
 optimistic schedule.  I think if we can do
 this in this timeframe, we should be very
 proud  of ourselves.  I'd like to make one
 point. If you  look at this set of milestones
 and  if  you look  at  the fact  that our
 COMNET contract  expires  in   1980,   it
 means that we must be done with  the first
 year of  planning  by  December,  1977; we
 are  just  about there.

      The third constraint is that  we  must
 use a policy issued by OMB last year,  OMB
 circular   A-109,   which  governs large-
 sytems acquisitions whether they be  ADP
 or   non-ADP.   This  is  really  a  new
 approach  for civilian  agencies.   The
 military   agencies have  had  experience
 with this sort of thing.  When the military
 buys a new weapon,  they will very often
 have a large number  of offerers  that are
 doing  design, and  multiple  companies
building  a prototype before they finally
select  one which  is to go into operation.
This  new process looks  something  like
that.  The  circular said  that  agencies
could accept  their own dollar level which
would  trigger the requirements  for this
process.  Most of the smaller  or medium
civilian agencies  accept the figure of $10
million.  That  is what EPA did.  We are
talking  about  $450  million,  so we  are
clearly above this dollar threshold.  There
are also  very  few applications of system
acquisitions in EPA  that would excuse
that $10 million figure. If we ever build a
large building, it  might exceed that, but
pretty much this  is the only EPA A-109
activity I think you will every see.  There
are two key features of this process.  One
of them  is  that the  agency  head retains
certain  key decisions  in the process; the
second  one  is that  there  is a  single
program  manager who is  set  up with a
project  manager's  responsibility for this
entire  procurement   activity.      This
provides point of contact.

      The fourth  constraint is  flexibility.
There is  just very little you can do to see
and  know  definitely what  the future is
going to hold.  Whatever we buy, whatever
contract we try to set up will  have to be
one  that has  a great deal of flexibility
built into it.

      Let me   just talk now about  what
we've done  to date, to how we have  gone
about this process.  One of the things we
did was  to gather  together all of  the
people who were thought to  have  been
interested.   We  set up an  agency-wide
ADP planning  group.   We have 15 division
directors from the Agency serving as the
management arm of this steering group.
We have 35 or so senior technical  people
supporting the  15  managers.  We also have
extensive liaison  with  oversight agencies
to make sure that they know what we are
doing and  we  know  what  their  concerns
are.  Unfortunately, their concerns  vary
through  time,  so  we  have to  keep in
contact with them.  Most of the agencies
to whom we  have talked  and  made our
pitch have  said, "Fine, we are very happy
to know what  you are doing,  but you  must
realize that we can not give you any kind
of advanced approval.  We  will  always
reserve our right  to  find fault with  what
you are doing,  but nonetheless, we feel it
is essential  to  maintain the liaison."  The

-------
size of the job about which we are talking
is a tremendous amount of data collection
analysis and report writing that justifies a
procurement of  this  type.   We  have
contracted  out  for  this because  our  in-
house positions are very, very limited.  We
have had a contract  with Informatics Inc.,
and our workload studies are planned to be
completed in December.  I  think  we will
make that deadline.  How do we  project
the workload for the future? How can we
see it?  The basic  approach that we use is
a multiple  scenario approach.   We have
tried  to  isolate  an  expected  kind  of
growth  rate, one that might correspond to
increased activity for  the  Agency.   We
also project a very pessimistic  scenario
that might follow if monies or interest for
environmental  activities  were  reduced
drastically. We  have also noted, in terms
of  an  individual  ADP activity  in   the
Agency, that the system managers have a
good feel for how it will grow up  through
1979.  We have identified all ADP activi-
ties by our zero-based budget processing.
Up through 1979,  we  have  our  advance
budget performed  and  it is being reviewed
by  OMB.   Beyond that, it is really very
difficult for an individual system manager
to know what will happen.  Generally,  the
feeling is, "I  really   don't know,  that
depends on too  many  variables.   Go  see
my top manager."  In fact, that is what we
have  done.  We  have gone  to  the  top
managers in EPA, and they do not  know
anything about the system.  We could  not
ask them  questions.   They  really do  not
know.   We can ask them, how do  you  see
the amount of  money  coming in EPA?
How do you see our budget?  How do you
see EPA  being funded?   How do you see
your particular activity getting a  bigger
chunk or a smaller chunk of that money?
How do you see your various sub-elements
being   given   additional funding  incre-
ments? We use this top-down approach  to
get a  feel for how much  activity,  how
much interest  we have flowing down from
the top.   We  have  used those factors  to
project workloads for the future.

     I  would like to mention on this slide,
what it is that A-I09 is talking about.  The
basic point I  would like to show is  that
there are some activities that need to  be
done in  the   mission;  in this particular
case,  it  is data  processing  and  mission
components in the Agency.  We have  to
develop a workload requirement.  We have
to get  those approved.  Now we jump  up
to the Agency head.  We have to have the
Agency head  approve them.  Then we  go
on  and we explore  alternative  ways  of
satisfying the  requirements. Once we get
to the point  where we have picked out
some promising  ones, and we have a few
that we want to demonstrate, we have  to
go  and get the  Agency head's  approval
once again. At  the end of the prototype
stage, after the demonstration and evalu-
ation,  we  want to  pick  one  for  full
production.  At  that point,  we go once
again and get Agency head approval. That
is interaction  at those various points.  At
this time, I would like to ask Ted to talk a
while more about that.
                                         D-15

-------
                                  Theodore JR. Harris
      I am going to talk about ADP system
 acquisition.  I will talk about it in the six
 different  areas  which the  circular ad-
 dresses.   Informatics Inc.,  is  currently
 producing our feasibility study and work-
 load analysis.  The study is divided  into
 three distinct groupings.

      The first is the consolidated-systems
 study.  Many people in EPA  are probably
 familiar with the forms and surveys  that
 we  send out.   The  survey  details  the
 workload for 1977 and projects it through
 the different years.  The telecommunica-
 tions  workload was also surveyed at the
 same time for the ADP activities we  had.
 It  had  been  massaged  and  put  into a
 detailed  workload by  location  and then
 projected  by the location.   We have  also
 addressed the conversion study, which is
 in final draft now.  The final report will
 be summarized in a  final document, which
 will be produced December 15, 1977, and
 distributed to the ADP Planning Panel.

      A-109 describes  in detail a function
 called program management.  It  describes
 it as an individual who is totally respon-
 sible  for  the  acquisition   project.    It
 requires a  charter  which is  in effect a
 contract  between the  individual and the
 Agency stating responsibilities,  authori-
 ties, and resources.  The charter  would
 also delineate  staff that would assist  in
 the particular functions. I will come back
 to the staff in a few minutes.

      There are three specific documents
 that are produced. The program manage-
 ment   plan   describes  how  the  team
 operates, what  methods they use,  how
 they  will  control  the contractors that
 interface the Agency, both the planning
 panel and the rest of the approval oversite
 agencies.  The  system acquisition plan
 describes the procurement  methodology.
 Also, a request  for proposal (RFP) will be
 developed. All of the proposals that come
in will be evaluated.  The team will also
monitor, review,  and  evaluate  the  con-
tractors involved.
     The first phase is called alternative
system  design.   We  currently  envision
multiple award  contracts which  will be
fixed price  contracts.  Any vendor  may
submit  proposals  at  this  time.    They
should address the workload requirements,
the design,  and  approach to EPA's work-
load. It is  projected that we will select
five contractors, at  least  two for each
concept.  If there  are three concepts,  I
guess we will have six contractors.  The
selection criteria at this time is really
important because  of  the narrowing  con-
cept of  this procurement. The first stage
would select from the world. The second
stage would select from those that are in
the alternative system design phase.  The
next would select from those, and further
narrow  it down.  At this point, all of the
EPA  computer  documentation  will be
made available  to the contractors  in  a
controlled manner  so  that  they  all  have
the same information.  All of our  systems
need to be documented by the time these
contracts are awarded. This phase would
produce a concept to demonstrate  the risk
of  conversion, and include  a conversion
methodology.

      The system  demonstration  concept
is  also  envisioned as  multiple   award,
fixed-priced contracts. This phase would
only be open to those  contractors  that
were selected in the system-design phase.
The proposals at this phase would address
the  workload requirements and  conver-
sion.   We  would  select  probably   two
contractors for  this demonstration.   The
purpose is to determine and evaluate the
risk.  We would  probably pick several EPA
computer activities that  would be opera-
tional at the time.  The contractors would
install  and  operate  these  activities.   I
have used the word "prototype",  it is the
closest  word I  can use  to describe for
what we are looking for  in a demonstra-
tion. This phase would produce the  final
contract.

      The  next  slide shows  after the
award,  the  start-up and  conversion.  We
                                          D-16

-------
have  included  this because past experi-
ences  has taught  us that  we  need  to
include this  as part  of  the procurement
cycle, and the need to  monitor it  very
closely.  My  next slide shows the goals of
this procurement.

      The goals are very simple:  We  want
a system life of 10 years.  That means that
we require that expansion of hardware to
be  provided,  depending  on  our  flexible
requirements.   We want growth  of  soft-
ware as technology changes, but we do not
want any major conversions.

      The  next  slide   is  our  current
approach for  the acquisition staffing.   I
will  briefly  describe the  functions; the
four  bodies identified are two computer
services  and   two  telecommunications.
This is to evaluate, monitor, and analyze
proposals and contractors for those parti-
cular  categories.  In EPA,  we  consider
those categories divided into  hardware,
software, with people in both.  Next,  we
have the two  procurement officials; the
contracting officer, who would handle all
of  the appropriate rules and regulations;
and the financial officer, who would be
concerned with the cost  analysis.

      We envision the final contract  to be
one of  our  cost-plus-award-fee (CPAF)
types, and this  involves a  great deal of
cost analysis throughout  the whole acuqi-
sition cycle  and evaluation.   The  last
person  I  term  the  Program  Control
Officer.  You might want to look at him
or her as the person who coordinates the
multiple  contractors with the acquisition
staff  within  the  team  and  the  ADP
planning  panel.   To  the  rest  of  the
Agency,   the   person  would  provide
librarian type duties for computer docu-
mentation.   I feel  that  this would be a
very difficult job to handle.

      The next  slide  shows timing  and
start-up  phase-in of the  individuals.  The
letters and circles refer to the  next slide,
which is a flow chart of the acquisition
process.  The concept here is that we have
broken it down into a  phased in  step-by-
step requirements.

      We are at the point today of getting
the final mission needs and  we will go to
the   assistant  administrators  and  the
regional  administrators for their  approval
before it goes to the EPA Administrator.
Once it goes to the EPA agency  head, he
will   designate  the  program   manager,
authorize the charter, and provide for the
resources.  Our  current schedule for RFP
development  has  the   first   draft  due
December 9th. We will provide a draft of
the RFP in January to be sent out  to the
ADP  Planning Panel.  We then project a
two-month review cycle. Thank you.
                                          D-17

-------
                             QUESTIONS AND ANSWERS
Question:       Larry Weiner from MIDSD.  I am rather concerned about the life cycle
                cost determination over a 10 year period.  If we look back 10-years,  we
                sec that costs have gone down. In a lot of ways we really have not been
                able to predict the technological development that has taken place.  We
                are moving into a very new  environment with the 1980's.  How can you
                possibly predict cost  over a 10-year period, when we do not know what we
                will have 5 years from now?

Answer:         What we are  trying to do is provide a system.  We are looking at system
                life that will  probably be 10 years, regardless of whether we can cost it
                or not.  In terms of the feasibility, we need to provide enough flexibility
                for that kind of a time frame because you probably will  not go through
                another feasibility study for that timeframe.  We are  projecting.  The
                best  that we  have  been  able  to do  on a  constructive  basis, given
                technology and the  A-109 procurement, is projecting more than 3 or 4
                years out. I think it is productive for us to do that, rather than not do it.
                Anything more than 3 years out is, as you say, is a real guess, but I think
                it  is just like  everything else, unless you put your best estimate down,
                you are ignoring the fact that those costs will be there.  You will at least
                want to try and do those trade-offs. I will not say it will be perfect.

Answer:         I would like to also add one point. In the 1980 study, we have had to look
                at those same questions.  We are making an assumption which we think
                we can support to a great degree, i.e., that technological development
                and inflation  will pretty much balance.  For planning purposes,  we can
                make that assumption.  The support  we can find for this is the NIH data
                center billing  rates.  After  some  initial  fluctuations  or  initial cost
                reductions, as they reached an economy of scale, their rates for jobs are
                remaining pretty much constant.

Question:       You mention  that there will be two vendors that will be selected for a
                parallel operation.  I  was  wondering who will  conduct  the  parallel
                operation?  Will EPA people be required to do that or  will that be the
                vendor's responsibility?

Answer:         The vendors will be  providing the demonstrations that we, and  the EPA
                panel, will be observing and in which we will  be cooperating.  We will
                fund that.

Question:       I want to focus on two fairly  major issues, one of which is a group of past
                failures and systems study.  These  are not directed at Arthur Young.
                They  are directed at the Agency and how  it handles its business.  The
                first one is failure to consider the scope of the project.  I think Arthur
                Young has learned its lesson  , but I am  afraid programs may not have.  I
                will go through that in detail  because you have not covered it. Failure to
                consider data  sources  and cost of  gathering  data, both clerical and
                dollars, you did cover that.  Failure to consider the  states and how they
                are organized,  is something that you did not consider.   The first factor
                about the states that is important is that there are 50.   I have seen that
                                         D-18

-------
ignored constantly in our study.  Someone says we will do so-and-so at
the states level without realizing that there are a gross number of them
that makes that particular operation difficult.  Delivery  of the systems
to the states is one example.  It takes a week to deliver the system.  You
have a  whole year  involved  in delivery unless you use multiple teams.
The fact that the states are not Federal Government  is largely ignored.
A State's ADP organization is not central, especially when one deals with
environmental agencies.   Often  the  environmental agency uses  some
other part of  the  State government for  ADP  resources.  Also, the
approval systems for state systems are often more complicated  or more
rigid than the Federal Government systems with the  possible exception
of  A109.   Even the  smaller  systems in  some  states require,  say,
gubernatorial or legislative approval.  Also, the existence of OMB A90 is
sometime ignored.  This is a  circular which restricts what we do to the
states and demands that they perform certain ADP functions.  What I am
concerned with here is our failure in the system study to go beyond the
scope of ADP.  Most of the  system study  is highly technical and ADP-
oriented.  We should be making recommendations and changing the entire
way in which we are doing business in some  areas.  In other words, Arthur
Young may step in, or someone  else, and find  that they have got a
situation that they  can not manage.   You  can not recommend an ADP
system  for us because the way they have  already started to  do their
business is wrong.  That is something that has to be addressed.  Another
point, and I am  afraid I have to address Arthur Young, is the failure to
address all alternatives.   In other words,  it seems to me to  be true of
everyone who does  a feasibility study, but  Arthur Young, from  some of
the recent ones, they  have one thing that they think ought to  be done,
then they turn around and invent several more, or at  least it looks that
way.  Some of them are ludicrous.  There is not any reason, for instance,
to include in a feasibility study the alternative of using mini-computer
systems  in the  regions,  when all the  regious do  not have them.  You
might  as well just  leave  it out.  Last,  failure  to  consider  stop-gap
planning.  We notice, in this process, that we are talking about a year to
do a feasibility study.  Certainly in a major system that would be almost
a minimal period of time, and yet the  requirements of the programs are
such that we have  to deliver something.   I very seldom have seen any
planning.  I don't think this is  Arthur  Young's responsibility.  This ADP
organization does not exist in EPA now, but you have  to  have some way
to satisfy the needs  of the programs.  That means doing something quick
and dirty, using somebody else's software, writing something with a data
management system that will not eventually be in the data management
system,  but  getting  something  moving.    This has  two  clear-cut
advantages.   The first one  is  that we do something  and satisfy the
requirements; the second one  is that it  gives us experience upon which to
draw something  to evaluate when we are doing the real feasibility study.
If  we go ahead and plan  the  system in a vacuum,  write  it  a year  later,
and so forth, we could end up with a (unintelligible) for the most careful
study.  I would like  to recommend that. The last thing is the alteration
in our  traditional  way  of looking at systems development when we
include data  independent  software systems, and I do not  mean  DBMS.
DBMS  is inclined to be,  in  its complexities, somewhat similar to the
systems we are using.  You  can go out, make a lot of mistakes, and
correct them very  quickly so  that the formality of the effort—the

                          D-19

-------
planning, implementing, and then reevaluating—is not necessarily some-
thing that we want to carry through in our next generation of software.
We do not have a whole lot of it now, but we may in the future. This
may destroy both the traditional methods of analysis and design and also
Nolan's Hypothesis of  how  systems are developed.   Largely we  do
planning evaluation because a mistake is quite expensive.  Correcting it,
maintenance on it, is expensive, and this may not carry  over the next
five or six years, when we consider systems development cycle.
                         D-20

-------
                                FEASIBILITY STUDIES
                                   Don Fitzpatrick
      What I'd like  to talk  about is  the
feasibility  study in  the EPA system  life
cycle. It is perceived that EPA is moving
into  what  is known  as Phase  Four  of
Nolan's hypothesis—hopefully, an integra-
tion  and  stabilization  of   some  of   its
systems.   I think MIDSD, and EPA as a
whole,  have  emphasized  the feasibility
study to accomplish this, carefully making
sure that we  study  the system's full  life
cycle.  I do not pretend, at  this  point, to
present EPA  policy and feasibility study
orientation, but rather our  interpretation
of that.  I think you will  find  a  recent
document,     published   by    MIDSD,
establishes  that  policy fairly   clearly.
What  we  are looking  at  is  the  entire
systems  development life  cycle;  every-
body has their own version.  This is  the
Arthur Young and Company version which
has eleven phases.  We have  been involved
in several  projects  in EPA  involving  the
first three phases, i.e., the  requirements
analysis, conceptual design  and detailed
systems  design;  and  also in operational
systems evaluation.

      Actually,  the   first   two  phases,
Phases One and Two, are normally incor-
porated  into  what is called a feasibility
study.  It is  the thing you need  to do to
get  the  system signed off  by MIDSD so
you  can  proceed  with  implementation.
Our  experience, not  necessarily only in
EPA but everywhere throughout our com-
mercial  and  Government experience, is
that if you do not perform  these  phases
properly, you get a very expensive  system
that  doesn't  meet  your  requirements.
Experience and academic studies indicate
that if you do not go through the process
properly,  you can get  huge operational
costs.   A  particular  emphasis  in   the
current EPA feasibility study is the incor-
poration of what is called, "total systems
life  cycle  costing", with  this  you  can
properly weigh your alternatives  in terms
of the cost of development and implemen-
tation vs.   the   operational  cost going
forward.  Many systems  in the  Govern-
ment and elsewhere are being  eaten alive
with operational costs, and for very good
reasons—the importance  of  these studies
has been overlooked in the past.

     What the  feasibility study does is
that it is the beginning point of what is, in
effect, a process of change in the organi-
zation.  Anytime  we get into a system
development cycle, you have already initi-
ated or expressed the desire to change
something. You have either gone through
an  operational  system   evaluation  and
decided that you have a real problem, or
you have a new application that is coming
forward. You need to institute change in
the organization to accept that  new pro-
gram or new systems  requirements, a new
mission or whatever.  In many ways, the
systems that  you  are implementing are
agents  of  change,   i.e., they   are  the
vehicle to change your  organization, to
respond to a mission requirement. Change
is  a difficult process  in the large organi-
zation.  You have to open up and make the
organization itself responsive  and accep-
table  to change.  It is getting everybody
on  board, bringing consensus to all the
players in order to begin  the implementa-
tion process.  Execution of the change can
be very simple if you  have a consensus; it
is very difficult if you have people running
around in different directions.  The litera-
ture and our experience  is littered with
great   systems  that  never  actually got
there.  It is not because they were not the
best technical or the most  sophisticated,
but because the organization, itself, did
not accept the  change  that  was  repre-
sented by  that system, i.e., you never sold
it  in the first place  to everybody.   You
never got  everybody together.  No matter
how pretty  the system  was,  if it  was
imposed from the  outside, it never got
embedded in  the organization.  Maybe it
worked for a  year,  but the data was
terrible, nobody supported it, nobody used
it, so  nobody ever completed that change
                                         D-21

-------
process; nobody ever embedded it into the
organization.   The feasibility  study  is
intended to create the  environment for
change to happen  properly, and to get a
system that meets your requirements.

     If we  can summarize the objectives
of a feasibility study, they are roughly the
following:

     o     What we would like to  do  is
           make  sure  that system  with
           which   we   are  proceeding
           meets  the  requirements   in
           terms  of  EPA's  mission and
           priorities.  It really has to do
           something for you.

     o     We want to select a system, or
           a set  of system  alternatives,
           which are cost effective over
           the entire life cycle.  That is a
           difficult  thing  to get across
           because  there  is   really  a
           trade-off in  designing and se-
           lecting  systems between the
           cost  and  care you  put  into
           implementing and the ongoing
           operational cost.   Of course,
           there  are counter  examples,
           too.

     o     Some   things  are  valid  and
           technically  nice,  but the risk
           involved  to  the  organization
           can be  substantial.  DBMS and
           mini's are a part of that risk.

     o     The other thing you want to do
           is ensure the feasibility study
           is a  system  which  is robust
           over   changes,   needs,   and
           growth, it  must  be flexible.
           Most system life cycles extend
           over ten years.  From the start
           of a  feasibility study,  it  will
           take  you probably  a year to
          accomplish the  study; to pro-
          ceed  with the design and im-
          plementation   will   probably
          take another  year.   You are
          probably  talking  about   two
          years   before   you   have  an
          operational system in a major
          systems  effort.  That system
          will probably be around for six
          to eight  years.  The designer's
          system must  then be respon-
          sive to  what  EPA  looks  like
          ten years from now.  What you
          need to  do is build  into the
          system some things  that allow
          that flexibility over time.

     o    The final  thing  is  to ensure
          effective transition  to the de-
          tailed  design.  This is what we
          are  talking about in terms of
          effecting the  change. Some-
          thing  that we have learned
          fairly  recently in EPA is that
          we have to have  management
          involvement  throughout  the
          feasibility study  process.   We
          attempt   to  actively solicit
          management  involvement  of
          all the people concerned with
          these  systems, because these
          systems  cross just  about  all
          your organizations.   Anytime
          you  touch  one,  it  affects
          everybody.    We  have  con-
          sciously  built  into  the feasi-
          bility study process some guid-
          ance  and  experience  from
          MIDSD  to  ensure that  those
          participants  who  should  be
          concerned are, and that that is
          at minimum  effort  on  their
          part.

Task Plan

     If you have dealt with this before,
you have seen  one  of these.  This is the
definition of our  feasibility study process,
it is really our standard task plan for the
requirements   specification  stage,  i.e.,
Phase One.  You  will note that it is fairly
classic.   It  involves, first of all  the
definition of system  objectives, of func-
tional requirements.   We go out and talk
to everybody and try to  figure  what you
actually need.  I  will not bother you with
all the detail.  The basic  products of that
effort  are:  A summary of the objectives,
                                         D-22

-------
a summary of  the  information require-
ments, the  functional requirements  that
are related to that  information, and the
information issues.

     The second task is typically a review
of  current  operations  and  functions  of
existing   systems,  where  appropriate.
There  are  systems  built that  have  no
existing systems to begin with.  But  even
in those cases, there are parallel systems
in  existence  that might be  of  use in
implementing the new program.  The  final
task in that effort  is a specification of
issues,   requirements,    and  evaluation
criteria.    We have found  that  it is
extremely valuable to identify  to manage-
ment and to each  of the people concerned
the specific issues we intend  to address.
Why did we get to  a feasibility study in
the first place? What is the issue? What
is the problem? Those issues result in the
design criteria and the functional  defini-
tion of requirements. This is incorporated
into  a  "requirements   briefing".    This
occurs  probably  within  the   first   two
months of a typical feasibility  study.  The
requirements  briefing is often  given to
anyone who is willing to listen. Before we
go  on in  trying to define the  system, we
must understand  what  you  are  thinking,
and ensure that we  are going after the
direction you  want.   It  is, in effect, a
working briefing intended to get feedback
from you.

      This process is a  response  to the
characteristics  of what  we  found in the
EPA systems environment. It is not to say
that all  systems have these characteris-
tics.   In  the  established programs,  what
you are  typically  dealing with  is  an
extremely  varied  user-community.    No
matter what system you  touch, it  affects
each of  the  programs   of  each  of the
regions in a very dynamic way. There are
complex    organizational   relationships
which reflect the same thing.  There is a
variety of  data  and data sources  and
numerous systems with  various pieces of
data reflecting the evolution  from Phase
One to  Phase  Two  to   Phase Three to
Phase   Four   of   the   broader  system
evolution process.   Existing  capabilities
are  frequently  incomplete  or  incom-
patible.

     The emerging programs  have very
different problems,  such  as  the  toxic
substances,  hazardous  waste,  or  other
programs that  are evolving now.  It is a
complex regulatory development process.
Programs are being initiated,  there is a
time pressure  to  coordinate  the  regula-
tions  with system  operability, i.e., you
sometimes need  systems defined before
you even have the regulations defined, you
realize  you need something to implement
those regulations since the system's life
cycle is long,  and  is a complex process.
By definition, in that  kind of environment
the user-community is undefined and the
data  sources  are  both  untested  and
undefined. When we  begin a study in this
environment, we are developing something
that has to be  accepted by  everybody.  It
has to  be broadly based or  it will not be
successful.

     To  accomplish  this,   we   have
established   a  very   formalized  data
gathering process.  This  is, in effect, a
reaction to our studies in EPA in the past.
The characteristics include, first of  all, a
thorough plan of study and identification
of the organizational  documents, the mis-
sion statements and plans, and the  current
system's documentation.    What  we are
trying to do here is, before we go  out and
talk to you, we want to get as smart  as we
possibly  can  in relation  to  the  system
scope,  or to whom  and to what might be
impacted. We present you with a prelimi-
nary plan, a work plan and interview plan
to make sure  every base is touched.
Interview guides are fairly  formal and
standardized, but will be particularized to
your organization. These interview guides
go in two directions, one for requirements
and the other for  the kinds of systems
documentation.  The requirements are the
most  complex,  and often  ill-structured.
By definition,  we  want  to get to your
basic underlying mission and function, and
identify  the real objective.  Further,  we
want to make  sure that when  we talk to
                                          D-23

-------
 you, we identify your plans, remembering
 that this will need to respond to you over
 the next  10  years.   Based on  that, we
 traditionally gather interview  notes  alto-
 gether and we do an analysis.  I  wish that
 analysis were a science. I will not pretend
 that it is. It is an art developed over time
 although people are claiming to be making
 it  a science.  After that analysis phase,
 we go  through  a  synthesis  and   brief
 management as we discussed before. The
 synthesis consists of three pieces; namely,
 functional definition of requirements, and
 overview of the current system, and issues
 in  design criteria.

      Once we have communicated  what
 we believe are the requirements, we then
 begin the conceptual design stage.

      At this  point in  time,  we  start
 developing something  that  looks  like  a
 system, and it goes through three careful
 steps.   The  first  is  a  development  of
 alternative system concepts.  The  second
 is  evaluation of cost and effectiveness of
 the  alternatives  we   have  identified.
 Finally, there  is the development  of the
 recommended  systems  concept.  Task one
 is probably the most critical. It is a broad
 scope  look  at   what  alternatives  are
 available to us in bringing  the system  up
 to  meet the requirements.  The alterna-
 tives are not just what hardware we will
 put the thing on, or whether we will use
 DBMS.  It has to start with management
 or  operational reporting that meets the
 requirements,  or identifies the alterna-
 tives for meeting it. How will we get the
 data collection,  data entry, and  data
 validation  put  together  because   in  a
 decentralized  environment  such  as EPA,
 that is typically the Achilles Heel of your
 systems. Alternative system data struc-
 ture:  Potentially DBMS, potentially con-
 ventional,  potentially  file  management
 are alternatives for the systems environ-
 ment. If you are going  mini: WCC, NCC,
 or  some  alternative.    Organizational
 alternatives: Where you place the system
and how you manage  it,  who will  have
charge  of what  pieces?   What  are  the
alternatives for that?  Finally,  we bring
all  these  together  in a  structured form.
The alternatives  we  put  together  are
packages.  You think of the number of
ways  you can  organize,  the number of
ways you can do the hardware, the number
of ways you can do the data entry.  You
get a combination  of things that  is  just
unmanageable.  What we have been doing
is packaging those alternatives based upon
what appears to be reasonable.  The whole
analytical package, before we get  into
costing, is presented again  to  everyone
who will listen  before we go forward with
the  conceptual  design.    There  is  a
briefing, a very key briefing, at that point
in time to make sure that the alternatives
are properly  identified  and the trade-off
criteria  for  the  trade-offs  are  well
thought-out.

     We then get into the formal analysis
of  cost effectiveness.   I  think  the  key
thing here is  the emphasis on full costing,
i.e., the full  cost of  whatever system  is
going  to be implemented or is attempted
to be identified.  The other thing  is not
only the inclusiveness of cost, but the full
system's life cycle cost, i.e., you are  then
looking  over  10 years at both the  imple-
mentation and  the operational costs of
those  systems.   What we  want to do  is
portray the full picture.

     Once we  have developed  a recom-
mended system through that  analysis  pro-
cess, we  will take the one  that appears
most viable to  us.  We will develop  it  in
more  detail so that management is fully
aware of what it is  we are recommending.
That again is a draft and  a management
briefing, and a final feasibility report  only
after  we  have  gone  through  a  fairly
extensive review process. By the end, you
have a  feasibility study report that  goes
forward  to   the  detailed  design.    You
should   have  no  interface  problem;  you
should  have MIDSD, and all the programs
and regions concerned on board.

     That process  responds to what the
major  issues  in the  conceptual  design
process are.    These  are  the  numerous
hardware/software  support  alternatives.

-------
Each  region has its own way of doing it.
It is not only regions, but also states with
what you are trying to work and interface.
You have the hardware alternatives avail-
able to you  both in North  Carolina and
here in Washington. Each  of those has to
be considered, along with  the data alter-
natives you have.  Finally, you have to be
very careful about who will do what in the
system.    There  is  state  and regional
delegation, as well as other delegation of
responsibility.   There  is the centralized
vs.  decentralized considerations which are
paramount in the concept and the alterna-
tives  definition.  It is not only what is
efficient  in  that  sense,  it is what is
effective, because there are very careful
trade-offs  in this environment as to who
has the  incentive to  maintain  the data
properly,  make  sure  that  it  is  edited,
validated,  and  processed  to ensure the
validity of the overall data base. We have
also experienced different styles, both in
hardware  and in  operations.  The  inter-
relationships of  organizationally distinct
programs  relates  more to Headquarters.
Each  program has an interest;  just about
any system you touch has many  interested
parties.  You have to  be  concerned that
everybody  is fully aware of what is hap-
pening, that their  needs are met from that
system.  You do  not want to  institute a
system with  new  data, and go through an
expensive  systems  development  cycle
without making sure that  everybody's in-
terests are involved—programmatic, en-
forcement, etc.

      EPA systems are  also starting to get
into   decision-support   systems,   which
means that systems are not classic ad-
ministrative or stable systems.   They are
systems in which the data changes rapidly.
I think the previous presentation  on up-
date  is  example  of  a decision-support
system.  There is the  first presentation,
which  does not necessarily define the data
that will exist, but rather the process that
goes around.   As  Congress continues to
ask new questions, those systems evolve in
terms of data, rather than function.

     I also think you are ail aware now of
the need to  evaluate  external  reporting
burden.  We are  aware of  the  need to
evaluate fully the impact of these systems
on  the  sources   from which the  data
comes.   Every time you  impose a  new
reporting burden on the public, we have to
incorporate an  estimate  of what   that
impact will be; different systems alterna-
tives  will have different impacts on the
public.   Not only does the  cost include
EPA,  but the whole U.S. public.  How far
and how deep you  go in the external-
reporting burden estimates is still a  pro-
cess  to  be  decided,  to  evolve.    The
question is—how  reliable  are the  esti-
mates that we are  going  to have  to do
there  in  order to get a credible response
to EPA requirements?  One could do a full
study  going into a  whole reporting impact
study   on  the  economy if  you  are not
careful.  I guess the final  major issue is
the growing impact of DBMS. One DBMS
is not necessarily good everwhere. It is a
great  technology,  but  there  are  a lot of
concerns  with  it.   We are continually
asked to evaluate  it to make sure that it
is appropriate, which part of  that techno-
logy is appropriate to a particular system.

      Hopefully, what  finally gets done is
the development of  the systems  concept,
the integration of  three pieces: A projec-
tion of requirements,  and technical and
management alternatives  that are avail-
able to us with some very distinct analysis
methodologies, including the mehtods of
specifying  alternatives so  they are  clear
and concise; life-cycle costing methodo-
logy and also A76-type costing relations
which utilize evaluation approaches which
allow us to look at benefits, qualitative as
well  as quantitatively, and the  input-
output process, the hypo-type documenta-
tion of the concept to ensure the design
transition is appropriate.

      The final thing with which I would
like to leave you is  the feasibility study's
whole purpose:  To open up  the organiza-
tion to  change,  to effect  change  with
minimal hassle,  and  to  make sure  the
system gets to a conclusion, the final end
product.  This  is the beginning of a  final
end product that is  responsive to  your
requirement. Thank you.
                                         D-25

-------
                       PANEL E: ADMINISTRATIVE SYSTEMS
                               Chairman: Neil Haley
                               Panelists:
Alan M. Kaplan
Edward S. McLean
Michael H. Platt
Paul F. Wagner
Carlton Woodell
Charles T. Wolz
Mary Blakeslee
Leo C. Cox
Albert Pines
Dennis Schur
                            INTRODUCTORY REMARKS


                                    Neil Haley

     This panel will be handled a little bit differently than some of the prior ones in that
we have on the panel various systems managers, as well as system users.  The systems
managers will discuss their systems, talking about current operations and plans they might
have for future use, and the direction in which their systems will be going.  After each of
the managers have discussed their systems, the users will have an opportunity to comment
on the system from their point of view, and give observations on any problems they might
have with these systems, or how they use the systems.  Let me just introduce the systems
managers who are here:  Mike Kaplan from Financial Management, Ed  McLean from the
Contracts Management Division, Mike Platt from the Personnel Management, Paul Wagner
from the Grants Administration  Division; Carlton  Woodell from  the the  Facilities and
Support Services Division, and Tom Wolz from Budget Operations. System users are Mary
Blakeslee  from  the Office of Air and  Waste Management,  Leo Cox  from Water and
Hazardous Materials, Al Pines from the Office of Research and Development, and Dennis
Schur who is the ADP Chief from Seattle.
                                        E-l

-------
                       THE FINANCIAL MANAGEMENT SYSTEM
                                   Alan M. Kaplan
      The  Financial Management System
 (FMS) evolved from a small update and
 reporting process which existed in one of
 our predecessor agencies, the  Environ-
 mental Health  Service.  The process,  at
 that time, consisted  of  a few  software
 applications operating at  the  Parklawn
 computer  facility.    During  the  period
 1969-1971, FMS supported a centralized
 accounting operation  whereby obligation
 and payment documents  were mailed  to
 Headquarters  to   be  processed,  key-
 punched, and entered into the computer.

      During  the year  1971,  after the
 Agency received its Determination order,
 we  established  accounting  offices in the
 field, decentralized the payment function,
 and  initiated  a  two-phased  approach
 toward the mechanical decentralization of
 the accounting  system.  The first  phase
 consisted of a  card-to-tape transmission
 to the central  computer facility.   The
 second phase was initiated some months
 later  when  we  were assured of  proper
 controls in the  accounting offices.  This
 phase  consisted of the decentralized "file
 management"  concept.     Under   this
 arrangement, each  office updated and
 maintained its own master file.   Reports,
 however,  were  still being mailed to the
 field, since master files had to be merged,
 messages,  and combined  with other cen-
 tralized  accounting  activity   (payroll,
 budget authorizations, etc.) in order  to
 generate "Fund Status" reports.

     In the succeeding months, we devel-
 oped a process  which would provide for
 decentralized reporting on  a one-for-one
 basis,  i.e.,  each  standard FMD  report
 would   be   accessed  through  a  single
 COBOL or IRS  program on a report-by-
 report  basis. An important aspect of each
 report  generator, tiowever, was the con-
 solidation  of   all   types  of  financial
activity, nationwide, that impacted on an
allowance holders' funds.
     Eventually,   a   front-end   report
generator was developed which permitted
one or more reports to be accessed in a
single  job  submission.     All   reports,
however,  were standard  agency reports
designed  to  answer most of the informa-
tional requirements of Headquarters' man-
agement, but only limited requirements of
our managers in the field.  In responding
to the latter, we  developed various  IRS
computer programs on a first-serve basis
using  contractor  support for  the  more
complex  reports.   In-house  support  was
applied toward file maintenance  applica-
tions, systems development  efforts,  and
smaller report generators.  At the end of
1972,  we were a  relatively small,  but
integrated,  accounting system,  serving
management  and  responding   to   the
internal  and external  reporting  require-
ments  of  Headquarters.    Our   data
consisted primarily of the Agency's annual
work  plan,  plus obligation  and payment
data.   In  an  effort  to  determine  the
direction   we  should  pursue  toward
providing  Agency accounting, a contract
was established with Booz-Allen, Inc., to
take a look at EPA's needs and provide us
with additional insight.

     During  the  period  1973-1974,  the
accounting system was greatly improved
to provide greater management  tools to
the Agency.   During this period  the
accounting  system grew  to become  a
large, complex, and highly integrated Fi-
nancial Management System.  We began to
take a closer look  at  fund  control prac-
tices  within  the  Agency  and also  began
analyzing the reporting requirements of
management in the field. The culmination
of our analyses was to install commitment
accounting agency-wide, and develop and
implement what  we   call our  Software
Package   for  Unique   Reports  (SPUR).
SPUR  was  to supplement  our  standard
library of reports and  would permit a
layman in the field to produce any array

-------
of financial data he desired.   To accom-
plish  this, fewer  than six control  cards
would be  required. They would consist of
specific  statements  and  data elements
described  in  our SPUR  manual.   This
manual is now in the hands of all Financial
Management Officers nationwide.

      Today, FMS  is  an  almost totally
decentralized input/output process.  Four-
teen  accounting offices  nationwide  are
entering data  and spontaneously updating
master  files.   (See Figure 1.)  Hardcopy
reports are accessible over medium-speed
terminals  to  the 1*  accounting  offices,
plus many satellite laboratories.

      All  payroll  data  is entered by Head-
quarters and made accessible  to  each of
the appropriate offices.   This is accom-
plished  through  an  interface with  the
Department of Interior for bi-weekly civi-
lian pay,  an  interface with  DHEW  for
monthly Commissioned Officers'  payroll,
and supplemental pay and  redistributed
labor costs from FMD's payroll section. In
additon, FMD  will commit salaries on a
quarterly basis for each allowance holder.
These are automatically liquidated by the
accounting offices  as  the charges  are
introduced into the system.

      Also entered  into  the  system  by
Headquarters are the Agency's budget and
planning dollars.  Lower-level budget allo-
cations are entered at the local level and
monitored  accordingly.    The  Agency's
budget  and planning  authorizations  are
introduced into the system by interfacing
with  the  RMIS process maintained in the
Budget Operations Division.

      The FMS will  accomodate updating
and reporting on a  demand basis.  Most
updating is done as a weekly cycle plus an
additional cycle at month-end for  correct-
ing remaining  errors.  Standard  monthly
reports may be processed at month-end or
on  an  as-needed  basis.    Most  local
informational    requirements   may   be
satisfied  through  the  SPUR package and
accessed  on demand.  Detailed payroll
data  is  also accessible through SPUR on
an  as-needed  basis.    Although  payroll
disbursements are entered at  month-end,
commitment and obligation (accrual) data
provide up-to-date financial status.

     Each accounting office maintains its
own file  and is totally  responsible for
accounting data entered into that file.  At
month-end,  all  14  files  are  merged to-
gether by FMD.  Agency-level data is then
provided  for internal management and for
external  reporting.  Figure 2 illustrates a
simplified flow of financial data.

     Much of our reporting to local man-
agement  is in the form of "Status" report-
ing.   Status reports  may be  likened to
bank statements that  we receive at the
end of each month.  For example, at the
beginning of the month we have a "pot" of
money in our checking account upon which
we  draw  each time a check  is  written.
At  the end  of the month, we receive a
statement that  reflects each  transaction
(check)  which  has  transpired,  deposits
entered during the month,  and a remaining
balance (known as  "fund availability" in
FMS) to  be  spent  the following  month.
Transactions in the FMS  are known as
commitments, obligations, and payments.
Every commitment  will automatically re-
duce fund availability.  Every obligation
not previously committed  will  also reduce
fund availability.   The  FMS,  therefore,
tracks each  commitment  and/or  obliga-
tion,  such  as  purchase  orders,  travel,
contracts, etc.,  initiated  by  a  program
office.   Eventually, all  payments  which
have been made by the accounting office
in  support  of  an obligation  are   also
entered into the system.  Payments do not
necessarily reduce fund availability since
they   are  always  entered  after  the
obligation.   Fund status  reports, there-
fore, would  reflect, in the aggregate, all
commitments and obligations  which have
had an effect on those funds,  which have
reduced the  pots of money allocated to an
allowance holder or subordinate organiza-
tions.  The reports  would also reflect the
remaining balance of  funds available for
the rest  of that quarter or for the rest of
the year, depending on the report.
                                           E-3

-------
                                                                   EXHIBIT A
                               Figure 1
                                 PROTECTION
                   BKUVTCTNO ACCOUtmNO OFFICE!]
                                                                                        n
                                                                                        E
                                                                            ^v^      I
                                                                                        0

                                                                                        11

                                                                                        G
                                COMHJTUl
                                 CKiTEll

                                IBM 370

                                                                                                w
                                                                                                A
                                                                                                8
                                                                                                H.
                                                                                                DC

                                                                                         L
                                                                                         A
                                                                                         B
                                                                                         n
HOT'S
ATI, iH  ACCCKJHTina  OFF10KO AIlE UNKEH 'W 'J!IB COHK1THI Cni'POKT CENTER THRCDail IllMOTK
TLUMIIJAIfl FOll IIIHJT,  UIDATE, AUU  nrailliVAI, OF FJHAIKJTAI, RKCX)UDS AIID REIOWTD.

-------
 Figure 2  SCOPS 0?  ^FA'S ACCCOSTEIG SYSTEM
                                                     SUJPCST
                                                     LS7EZ2
                                       330C3S3
                                      DCCU3-E2TS
       JU3DS
    MA3AG2SIT
MWBKMMM*
J
4

•
/*»
<-».
MHMV^BM*
X
>-»
^
PROGRAM
HZPCHTS
|  X, *" -^ ^-<-Vl

1 irA ! 1 —"A |
I CCinr.i.CTS ! i GHAZT^S • ;
i sTST7*-! i i s^sr^* i

n *^ * **

^



T* •-
~rc
» ^— ^-

./I


I
?:£:E-3!

-------
      FMS will accommodate many dif-
 ferent "pots" of money.  In the aggregate,
 all  commitments  and  obligations  are
 tracked against  the  allowance  holders'
 funds  to  provide  status reporting at that
 level.  However, an allowance holder, such
 as a Regional Administrator, may elect to
 sub-allocate his funds down  to  Division
 level,  or even lower to, say, project level.
 These  types  of  sub-allocations  are all
 entered through the local finance office.

      The SPUR package could then pro-
 vide reporting of  fund availability at any
 designated level,  whether it be organiza-
 tional or project-based.

      All  spending transactions which oc-
 cur in the agency must utilize "account"
 numbers  assigned to each organization.
 Each individual in the Agency must also
 be assigned  an  account number.   The
 account number is a 10-character  classifi-
 cation code assigned to a document which,
 through a table look-up, will proliferate
 into  various  types of  accounting data.
 Other  accounting  information  is  also
 coded on the documents and entered into
 the system, but it is the account code that
 determines  who and what will be charged.
 Figure 3 shows the  basic structure of the
 account number.

      It is the account number that pro-
 vides the link between the organizational
 structure in the Agency and the program-
 budget structure.   Spending  actions not
 only  impact   against  an  organization's
 funds, (e.g.,  allowance holder,  division,
 branch) but most provide data identifiable
 to the Agency's programs.  In this  way, we
 can ascertain the total monies spent on a
 particular   program   element,   such  as
 wastewater treatment facility construc-
 tion or in the aggregate for a media, such
 as  water.    The  account number will
 uniquely contain the last  three  positions
 of a program element. This provides for a
 direct  link with the Agency's six-charac-
 ter program/budget code; it  is  this six-
character code which is seen  in most
financial reports.  Figure 4 provides a look
at the relationship  between the  account
number and the program/budget and or-
ganizational  structure  of  the  Agency.
Also depicted  is the Document Control
Number (DCN). This may be thought of as
an extension of the Account Number and
provides the link  between  the commit-
ment and obligation of funds.

   In addition  to the program,  organiza-
tion, and  accounting  codes  identified on
reports,   our   SPUR  package   provides
almost  all  the descriptive information
associated with  these  codes.   This  is
accomplished through table look-up which
relates  the proper nomenclature to the
data elements  in the master files.  This
table, known as our Master Code Descrip-
tor File (MCDF), serves as an edit to
ensure  that all  account  numbers  and
object  class  codes  are entered  properly
into the system.  The MCDF is comprised
of many  tables which  serve  many pur-
poses.  Figure 5 illustrates this table.

   Generally, financial  reporting may be
accomplished  in  two ways; the first  is
through our standard reports library.  The
second  is through the mechanism of the
SPUR  package.  The former  is accom-
plished  by merely inserting one  or  more
control cards  in  the  job  control  deck
provided to each office.  Each card would
contain the type of report desired such as
FMO-3, AHM-1, etc.  All of the specified
reports would follow, one after the other,
using only one  job submission.   SPUR, on
the  other hand,  would be  used when a
specific local reporting  need could not be
accommodated  through   the   standard
library.   For  these  reports, one  would
determine information  desired, sequence
of the  report,  totals, title, organization
type, and key in the specifications (state-
ments), as illustrated in the SPUR manual.
These   SPUR   "statements"    are   also
inserted into a job control deck which has
been provided to the accounting office.

   There  are  basically  three types  of
reports   which  are   most    commonly
retrieved from the  system; namely, Ac-
count Office reports, Organizational (Di-
visional  level, Allowance  Holder  level)

-------
                      Figure 3  ENVIRONMENTAL PROTECTION AOEHCY
                                 ACCOUNTING SYSTEMS D123IGN
ACCOUNT NUMBER
      LOCAL
                                    COMMON CODING
                                      2
                                                           "   "
	
-i
0
10
   RECORD W) OH nOCUMQITU AMD CONTAINED III COMIUTER LOOKUP TABLES

PROGRAM ELEMENT CODE -DUJCRKET 3 DIGIT CODE vniicii TIEO ACCOUNT HUHBER TO AdENCY'o PROCJUA?!
                         IUDG&T
DOCUMEIIT CO'ITROL NUMBER -  tti-ii upfco-ic spuioiira ACTIONS TO nit: AII/RC DOCHMKMT coniwoi, RicnTan

OOLIGATIOi! POCUMENT NUMBER - nmmvi w IIIOJECIB IN aim CCUS'IIUJCTEOH aRAuaa

-------
                                                    Figured                                    UXill JUT i>
iLUmTlATIOH OF HOW THE AOClXHl'fTHd  flYOTFl.|  "ntlliai" THE  OIUIAIUSSATIOH IWUCWIIR MI 111 TUB rilUlUAJI uv.
                                         THROUGH THE HUHDEirnitl HYI5'"
(
A
D
M
I
H
I
T
l\
A
T
0
H
f

ORGANIZATION

u
T
A
V
F
0
F
F
1
C
E
3


"F
0
S
T
A
D
M
B
E
P
A
B
0
T
A
D
H
{fj^

A
B
0
HOLDERS




DIVIS10II, JAJJ,
fil'Ef.TAr, OFFICE/


JJUli-OHdAMTZATION
(BRANCH, ETC)



li-
ft
a
i
0
N
B
=»=
=^
/
/
A

/

^
/,
/ ^
^^^
JC^-



/
/
/

-cy-l^

POU.
1
2
3
If

ACCOUNT "\^<^x=
NUMIH'31 $Lc=«^
B. 'f
IDENHFIEa
FISCAL YEAH
PROCJRAM
ELEHMJT V
8l'3i£AL \
miMER \
i) ALI/)WANCE
6 -^ HOLDFJl \
/RE3POHSIBIMTJT \
•^ ' CENTLM
yf LEGISLATIVE
/ AU'illORIZATIOH
10 ,\
IJOCAL OPTION v
^ A-TA 	
/ 1) |K
DOCUMI'JIT CONTROL NO.
y
2^
it
5
6
^ INITEATING
1 ORC5ANTZATION
CPECIAL IDEWTIFIERU
SHU AT,
NUMBER
— ,_ /•i/'\i i f i > n r'ti
COUIi TL.I\
FOR 1-JAC'H
                                                                                          flOfSRAM/iHjnr.ia1\
                                                                                            r.TRUCTUItH      )





1 APPROPRIATION
o
JDC
iET


AOTJ VI' TV
,, f.Un- ACTIVITY
3









^ UNIQUE
5 TO EACH
V6 HIOGIIAH
ELEMENT
E
L



H
E
N
T
\J
7 ALTX3WANCE
0 HOLD1CH





S
U



E
L
E
M
E
N

T
                                                                                             RIOJECT
                                                                                         (ACCOUNT HUMDER)

-------
                                        Figure 5

                              MASTER CODP: DESCRIPTOR FILE
                         EXHIUIT E
1)1 (IK BTORAriE
   DEVICE
ACCT.
01 NO.
do)
APPRO.
SYMBOL
(10)
PROGRAM
ELEMtHT
(6)
01
ORAI
COD!
3~
IIC
(11)
NATIONAL
PROGRAM
MANAGER (2)
PROGRAM
IDENT
(3)
ALLOW-
ANCE
(5)
A'M
TITLE
(23)
                                 02
                                        ALLOWAHCB
  ALLfMANCE HOiDHl
 	TI'IT.E(29)
                                 03
                                         BUDGET
                                       ACTIV['i"/(3)
         ACTIVITY
     T['fLE(3l)
                                     PROGRAM ELl'3-IKtlT
                                     SERIAL NUMBER(3)
1HOG3A-M
PROflRAM
ELfcMEHT
                                  6 j MAJOR AND a
                                     OBJECT
   OBJECT CIAS3
                                        ACCOUNT! H«
                                         roi»T(2)___
 ACCD'-JHTIHG  POIHT
	l'tTr.E(2b)'
                                 00
                                      APIMOPRIATfOH
   APPROPRIATION
                                 09
                                     NATIONAL
 IlfiTlOUAI,
_MA]i AG131  TITI.E(3Q)
10
GEIJERAL LHXIHl
ACCOUWT IJUMHI'IH
('') 	
                                                            GKNtRAL LI-JDGFJl
                                                           ACCOUNT TITLE(30)
PROGRAM" ELiilJEIlT
   TITI,E(32)

-------
reports, and Agency level reports.  There
are,  however,  many  reports  which  are
generated on  a recurring basis which do
not necessarily fall into  the types men-
tioned above.  These could fall into the
category  of   Detail  Payroll  reports,
General  Ledger  reports, Subsidiary  Ac-
counting  reports,  or  selective  reports
which  may  cross  organizational  lines.
This discussion will concentrate only on
the first three types.

      Accounting  Office  Reports  reflect
only  that  data  which is  entered by  a
particular  accounting office.    If  that
accounting office happens to be Region I
and   they   entered  transactions  that
affectedthe funds of another Region, that
data   would  still  be  reflected   as  a
transaction   of  Region  I.    Normally,
accounting office reports are separate job
submissions; however, input and diagnostic
reporting  is  spontaneously   generated
during the update cycle.

      Organizational  Reports  generators
automatically     consolidate      several
separate  files  in order to provide  total
inforamtion relative to a particular orga-
nization.   Let us  assume  the  Allowance
Holder  in  Region I  desired  a  report
reflecting all charges  (nationwide)  affect-
ing his funds.  The report generator would
then   provide  payroll  information  and
selected data from each Region pertaining
to  those accounts  assigned to Region I.
Since  the system must accommodate any
office  charging   against   the  funds  of
another office, this is a crucial feature of
organization reporting.

      Agency-Level reports are generated
by Headquarters  for Agency management
and  for  external reporting requirements.
On a monthly basis, all accounting office
master files, payroll files, plus budget and
planning data are merged and summarized
for this purpose.

      There is a lot of planning that we
have  to  do in finance.   I  would  like to
highlight a few areas that I thought would
be appropriate to this. The first is GAO
Systems  Design  Implimentaiton.     The
Financial   Management   Division   has
received formal approval of its Account-
ing Systems   Design from the  General
Accounting Office.  There are parts of
that design package which must be imple-
mented in the  near future.   Cost  and
Accrual Accounting will have the greatest
impact on FMS.  At present, this Agency
is  not involved in cost accounting as such
either on the input side or on the report-
ing side.  Determining management needs
in  this area, planning the guidelines for
input,   determining  reporting  require-
ments, designing,  programming, and  im-
plementing this  facet  of  our financial
management process may in itself require
two to three man-years of effort.

     A second area deals with improve-
ments  in  the SPUR package.   We  are
presently loking at a two-phased enhance-
ment of SPUR capabilities.  This will be
accomplished  by  two  contracts.    The
present contract  will  provide  for  the
batching of SPUR requests, a finer break-
down  of  data  element  fields,  greater
select  capabilities  of the "LIMIT" state-
ment, and some  cosmetic  changes.   The
second contract will primarily provide for
the ability to calculate percentages.  In
addition to improving SPUR, we intend to
make   it  available  to  the  Agency  and
publicize  its  applicability  government-
wide.   SPUR  can be geared  toward  any
type of file through the proper application
of the SPUR dictionary.

     FMD will be  incorporating  on-line
techniques into the FMS.  One of our on-
line applications will  be to  provide for
automatic    generation    of   payment
schedules  related  to  grants.   Payment
schedules  are now  typed  on OCR sheets
and forwarded  to  Treasury.   With  the
assignment of an IRS identification num-
ber to each grantee, on-line  retrieval of
the grantees' address and other indicative
data is possible.   The  data  would be
generated on  Magtape  and forwarded to
the proper  Treasury Disbursing Center.
We will also  be analyzing on-line tech-
niques  for other uses in the FMS, such as
job submissions, analysis  of documents,
etc.
                                         E-5

-------
     FMD will also be looking at distribu-
tive processing techniques for the  regions
and labs.   Providing  "pre-edits"  in the
field would be a probability. Transmission
of accounting data from the mini's to the
Headquarter's  facility  would  be   a by-
product of this process.

     Presently under  consideration is a
training session to provide an analysis of
the FMS and the accounting office master
files.  There have  been numerous requests
for "obligation" tapes by managers in both
regions and labs. We are presently explor-
ing the  feasibility of providing this data.
However, until there is a complete  under-
standing  as  to the  structure  and data
elements  contained in your master files,
this "obligaiton" data could be meaning-
less. Many managers have raised the issue
of  Agency  systems'  integration.   This
office is well aware of the many benefits
which may be  derived with systems inte-
gration.  There are, however, stipulations
which cannot be ignored:  common input
with common edits would be one; striving
for consistency  of  prior   year data  is
another; and timing requirements of the
various   systems   is  a  third.    We are
presently looking  at  some  type  of  an
interface between CICS  and  FMS for
year-end  reporting of commitment and
obligation data. The issues raised  above,
however,   must   be   resolved  before
managers could begin merging data in the
field even if FMS tapes were provided for
this purpose.

     Regarding    Zero-Base   Budgeting
techniques,  there  will  probably be  new
structures  emerging in  the  very  near
future which would consolidate the  pres-
ent program,  budgeting  and  accounting
structure into "Decision Units".   FMD
must participate in the formulation of this
structure and  equip the FMS to handle it
accordingly.

     Lastly   is   the  development  of
methodology to reduce manpower aspects
of the  financial  management  workload.
The  FMS  must  continually  be   in  a
development mode in order to provide new
and better techniques through automation
which would reduce the operational work-
load in  the accounting offices.  Payment
vouchers of all types have  been on the
rise. The Agency will be looking more and
more  at contracting  out.  Each contract
can  produce  a  multitude  of  payment
vouchers. It is important, therefore, that
automation play a key role in  controlling
the  ever-increasing  workload  of  the
finance office.
                                        E-6

-------
                             QUESTIONS AND ANSWERS
Dennis Schur:
Alan Kaplan:
Al Pines:
I have a few comments.  I would agree with Mike that the capabilities
that are available to us in SPUR has made a world of difference in the
utility of the Financial Management System. Our only gripe, if you can
call  it a gripe,  is that we  would like very much to see the Financial
Management System  moved to  a computer utility  such as WCC  or,
perhaps, NCC.  This would alleviate a lot of frustration that we have  in
the field.  I did not hear that  mentioned in your long-range plan, but I
understand it is being arranged.

Presently we are negotiating such an arrangement, but I cannot and will
not commit to a time frame. Kent is our representative.  He is working
with  COMNET and Willis,  and is looking  at what will be a phased-in
arrangement of certain of our subsystems.

You spoke a lot about the accessibility of this system to the field.  From
ORD's point of view, it is of considerable interest to us that the field,  in
this  case,  does not  include  ORD  laboratories.   This question   of
accessibility is one which has been of considerable interest to us. We
made  a  large commitment about a year ago  to  use  the  ADP finance
system as our own internal management system for our finances, our
program managers, laboratories directors,  etc.  We have done a lot  of
work and it  has been very, very productive.  We designed special reports
and  developed special mechanisms to allow our labs to  receive  those
reports.  We have even experimented with our  laboratory inputing data
for this system.  Most everything has gone along very nicely. We are at a
point right  now where we  are, for all  practical  purposes, completely
dependent  on  the Agency finance system   for  all  of our finance
information. Any decisions made in ORD are based on the  information in
that system. We still  have limited accessibility, particularly since you
people are not on COMNET.  That is a very serious consideraiton as far
as we are concerned.   Also, we have some serious concerns in terms  of
the last item you mentioned, the ability of the finance system to interact
with  other  agency systems.   One thing which  has aZways been very
troublesome to us is the fact that we go  through a great deal of effort  to
rectify information that we have located in various agency systems. The
fact is that we very rarely find that the information from the agency
systems agree. Since the  finance system is the starting point for almost
every action that takes place, we always try to make the  information in
the finance  system as accurate as possible.  Then we just hope that, with
a little bit of good luck, the same transactions eventually show up in the
other  systems,  whether  it be GICS,  or  the  Contracts Management
System.  The ability of these systems to interact, to check against one
another in some automated fashion is something that is of concern to us,
because  we spend a tremendous  number  of man-hours doing that
manually ourselves right now.  Another comment is that you talk about
the ability to  track dollars at  a lower  level than what is issued by the
Agency.  That creates some problems for us. We would like very much to
do that.  We take advantage of the ability to track our program plan in
terms of what we call the Accomplishment Plan, the basic building block
in our planning process.  Because we used that flexibility for tracking
                                         E-7

-------
                program plan, it has  prohibited us from  using that  flexibility to also
                break down our budget according to our organizational structure below
                the  laboratory level.   To have some additonal  flexibility in  that  area
                would be of considerable  benefit to us, because it is important to do
                both.  I must comment that Mike's group has just been fantastic the past
                year.  Kent Smith has put  in a tremendous amount of time and effort for
                us.  We are exceptionally  pleased about how the system is operating.  It
                is amazing what you can  do with  a little  bit  of cooperation and
                coordination  between  offices.   Our  laboratories  have managed to
                eliminate  a lot  of  independent  systems  that they  themselves have
                developed  for internally tracking their money.  We hope within the  next
                year, with a little more progress to be able to eliminate all of them.  The
                few things I have mentioned are areas of some concern.

 Question:       The only thing about which I have a question is what is the  source of  your
                commitment for travel?

 Answer:        Most offices  really do not commit  travel.   They  merely obligate it
                because travel is something that occurs reasonably soon.   Most offices
                will  commit  grants  and  contracts  because of the lag  between  the
                commitment and the obligation.  This produces  a more accurate picture
                of their funds  status.

 Question:       Then, perhaps, what I wanted to ask  is the source of obligation rather
                than commitment?

 Answer:        The R.E. initiates the  obligation and the Accounting Office writes it into
                the system.

 Question:       I guess my question is not clear.  Last year, we  asked for  an increase in
                travel ceiling.  In our justification, it said what  we had spent.  We were
                not supported  by what the report said.  There was some lag there.  At the
                time, travel money was not obligated until  the voucher came through,
                rather than on the travel order itself.  This is at  Headquarters.

 Answer:        I would say that you may be right.  Headquarters has to support many
                program offices.  Like every other  organization in  the  Agency, their
                resources are  limited.  / guess / understand your point, because I hear it
                continuously.  Our actions are not getting committed; our items were not
                obligated.  It  is a problem.  It may be a problem on both  parts. On our
                part, perhaps we can organize a little better in our operations office and
                with our priorities.   Or,  it  may be a problem  in terms  of the agency
                providing  the resources for  us to handle  all  the  paper  work.    The
                documentation handled in the office,  are not in the same proportion as
                the paperwork handled in the regions. The Finance Office really should
                have more resources in our operations shop, in terms of the proportion of
                individuals supporting Headquarters decisions.

Question:       It is a shortcut then not to use travel order?
                                          E-8

-------
Answer:
Question:

Answer:
Many times they win, but that is not necessarily true.  They do obligate
travel.  In many cases the obligating document or the  travel authoriza-
tion is hung up somewhere or never  even reaches the Finance Office. I
will say this: we have found that in many cases the program neglected to
forward the travel authorization, but yet the voucher comes through with
no problem.  There is money involved there.  They will obligate and pay
at the same time. Here again, in defense of our operations shop, there is
a balance that you really have to look at here.

It comes through quickly if the expenses exceed the advance.

Absolutely. It is there right after the trip.
Mary Blakeslee: I have one question.  I am concerned about the lack of integration in all
                of these management systems, because they all come together.  What
                kinds of studies have you  done?   What kinds of coordination among
                yourselves are you planning  to do to make the process more integrative
                than it has been in the past?
Answer:
Well, we have done some analysis, specifically in terms of the GICS and
the  Contracts  Management  systems.   There  is  an awful  lot  of
inconsistency of data; documents  may  be coded differently in the
different systems.  They may be keypunched differently.  The different
systems have different edit criteria.  Consequently, the transaction will
fall  out of one  system but be accepted by another  system.   We have
homed in on  grants in attempt to examine inconsistencies in the manner
in which documents were being coded in the process.  What we have done
is attempted time and time again, particularly in the area of construc-
tion grants,  to  stress the  necessity  for consistency  in coding  these
documents.   There is a standardized way  of coding documents in the
Agency.  There  is a standard  way for  coding construction grants.  I am
talking about the document number itself.  We have written memo after
memo, year after year.  We have made strides recently.  We have just
recently done an analysis and  I believe there was  something like 90
percent consistency between our system and the GICS process, in terms
of construction grants.  We have not looked  at other program grants yet,
but we  will.  There should  be consistency,  but there is a  lot  involved.
There is the  time of  entry into  our system, and the time that the GICS
process has to accept their data.  Also, what kinds of edits does GICS
have; What edits do  we have?  What edits does Contract Management
have?  You  need standardization of  edit  criteria,  standardization of
input. We are working on it,  because this has been a problem since the
beginning, particularly at the  end of the year, when Budget is  trying to
reconcile  commitments from contracts, grants,  and financial manage-
ment in order to determine carry-over allowances.
                                          E-9

-------
                       Resource Management Information System
                                     C. Tom Wolz
      Mike  told you  a little about  the
 Budget Office.  The purpose of the  Re-
 sources Management  Information System
 is  to support  the  budget  planning  and
 execution function  in Headquarters.  It
 contains  all of the data  on the planned
 positions and funding, except the funds for
 waste  treatment   construction  grants.
 During the  fiscal  year,  we cover  many
 phases of  the process.    For  example,
 during Fiscal  Year  1978,  we  will  be
 updating  monthly the 1978 operating plans
 and  issuing  advice  of allowances.   This
 information  is also  fed into the financial
 management system.  It provides a basis
 for authorizations in the  accounting sys-
 tem.     At  the  same  time,  back  in
 September, we submitted the 1979 budget
 to  OMB.   About  two  weeks  ago,  we
 received  the pass back, the mark-up from
 OMB, which is  in  the  process  of  being
 appealed  because  of some  switches in
 funds from one area to another.  Once the
 appeals  are  resolved,   the  President's
 Budget will  be developed.  Then we  will
 have House  and Senate  actions  and final
 action.   Along about February  or March,
 we  will  develop a  target for  the  1979
 operating plan.  The operating plans are
 then prepared on  an allowance  holder
 basis, undergo  reviews, and hopefully,  will
 be approved  in September or earlier.  Also
 along about February or March, we will be
 issuing the  targets  for the  1980 budget.
 One  of the objectives  of  the  planning
 system this  next  year  is  to  have  the
 allowance  holder   develop  their   1979
 operating plan and  the 1980 budget plan
 simultaneously. These have been separate
 in the past.  Of course, as  most everybody
 knows,  the past 1979 Agency budget  was
 developed on  the  zero-based  budgeting
 process, which gives us another crosswalk.
 Over the past several  years,   we  have
 changed program structure to some extent
 almost every year.  This creates the need
 for crosswalking program  elements from
one  year  to  the next,  splitting them,
consolidating, and so on.  Now we have a
decision  unit  structure  under the zero-
based  budget.    The  program  budget
structure provides the framework for dis-
tribution of resources. We have structure
codes for sources of funds which identify
the year in which the funds were appro-
priated,  such   as  the   new  obligation
authority for the current year,  or carry-
over funds.  A single character appropria-
tion code, a single character media code,
and  a single character sub-activity code,
define the  budget structure.  We  have a
three digit program element code, which
is a  unique number.  We started with 001
and  are up to about 770.  At the end of
Fiscal  year 1977, last  September, there
were about 250  of these elements in use;
about 100 of them  were used by regions.
The next break is an organization break by
allowance  holder.   Then  we  have the
appropriation  authorization code  which
identifies the  section  of  law that limits
the  funds  that   can  be  appropriated or
used.  We identify data  by object  class
groups in the resource management infor-
mation system.  The chart on the program
structure covers the basic tables. We also
have some edit  tables, description tables,
report titles and so forth.   These tables
are updated manually.   The master  data
file is updated through a batch transaction
edit and update program.  When the file is
updated, all of the  update transactions go
into a  master  transaction  history  tape
which  allows   us   to   produce  reports
showing the changes by allowance holder,
by   appropriation,  or  by   summary  of
changes between media.  This is somewhat
similar to  that  first bar chart that I had,
except it is laid out a little differently.
We start with the zero base and appropri-
ation budget plan, we develop the phases
as indicated,  and we produce  the target.
The targets are given to  the  allowance
holders and the assistant administrators.
They submit their  proposed  plans  which
are input into the computer.  Comparison
reports are made  of  the proposed  plans
with the targets.  These are reviewed by
                                         E-10

-------
the  program  analysis  division  and  the
Assistant   Administrator    for   their
respected  program  area.   As  we  move
toward   the  operating  plan  again,  the
targets  for the operating plan are sent out
and the proposed plan is sent  in. Reports
comparing  these  with  the  targets  are
made and  go through the review  of  the
operating  plan.    When  the  plan  is
approved,  we go into the monthly  main-
tenance of the operating plan.  We also
produce  various  comparisons,  such  as
comparisions of distribution of resources
between regions and within  regions.  We
also produce the Federal pay raise calcu-
lations  based on the positions that are in
the  plan,  so  it  is important  that  the
allowance holders maintain plans.
     We tie into DIPS to obtain personnel
costs and staffing plans.  Mike mentioned
that personnel  actions are  supposed to
have a fixed account number.  We use the
fixed  account number to identify  where
the person  is  located in  the  program
structure.    Through  this,  we  produce
reports to back up budget submission to
OMB  and  the  Congress.    The Deputy
Assistant Administrator  for  Resources
Management  plans to combine the  devel-
opment of the 1979 operating plan and the
1980 budget  plan and  to resolve a  lot of
the differences  in the structure  between
the zero-based  budget and the  program
element structure.    In  the  past,  the
resource management information system
has  been  exclusively  a  Headquarters
operation.  I  think in this next go-around,
the regions will  be inputting the data into
the computer and we will pick it up that
way.
                                           E-ll

-------
                            QUESTIONS AND ANSWERS
Comment:      / do not have any real questions but I do have one comment.  Having
               worked on the ZBB process at Headquarters and knowing how  it wiZZ be
               implemented in the future, I want to stress that the RMIS is one system
               upon which we really depend to provide us with accurate data on the
               Agency's resources and where they are.  It  is used for projecting the
               budget.
                       f
Question:       I do have one question, something about which I am curious more than
               anything else, and that is, why is  it  necessary  that  we  update the
               information in the  agencies RMIS system by object class every single
               month? If it is supposed to be a plan, why can it not stand as a plan and
               be compared at points and time, during the year maybe twice, three, or
               four times and in each quarter—to actual expenditure? Our maintenance
               with the RMIS system  is nothing more  than an attempt to keep our plan
               chasing after our actual so that the two match one another when we get
               to the end of the fiscal year. We have now  gone through some efforts
               with the financial management division.  We are using separate target
               tracking in their  system so that we   can compare plans against the
               changes that we make in those plans during the course  of the year. We
               find this to be very helpful; we know how  well we are actually planning.
               I myself,  personally,  do  not understand  the necessities of  actually
               updating the RMIS every single month by object class.

Comment:      / think  a  Zot  of  money is  saved by having  an Agency  Financial
               Management System. It has come a long way in the years that I have
               been with the Agency.  We need some type of ZBB system.  It ought to be
               number one priority.    Number two   priority  should  be  distributive
               processing techniques.  Number three, if we have the record lay-outs, we
               can get by without SPUR.
                                       E-12

-------
              THE PERSONNEL MANAGEMENT INFORMATION SYSTEM
                                    Michael Platt
     The time allowance is 20 minutes to
discuss a problem in this Agency that is
very large in magnitude. Rather than talk
about the construction of the past system,
the current  system, and  what  we have
planned for the personnel system, I will
discuss  basic features  within the  past
system prior to March of this year.  I will
also discuss what actions we have taken to
modify this system to its current state as
of this week. It has been in tremendous
flux for the last 11 months.  Additionally,
I will  discuss the  actions  that  we have
taken during this year to try and improve
the  system  by  coming up  with  a  new
design.  The problems concern things like
whether  or not  an organization may be
moved from one  place to another.  As
systems manager of this system, we have
not  been  able  to  have various  parties
address themselves to some  of  the pro-
blems.   We  are  finally getting  some  of
those problems addressed.  I will also talk
about the  components  of  your system in
terms  of the computer system.  Most of
the people in  this  room  are not  direct
users of the personnel system.  Many of
the people in the room, however, support
the direct users  of  the personnel system.
Prior to March of 1977, for approximately
3& years,  the  system  was  basically  a
reporting system,  consisting of  approxi-
mately  35 or  40  programs  which  ran
against sequential files that were supplied
to the system on a bi-weekly basis from
the  DIPS  payroll  personnel  system  at
Department of Interior. Additionally, the
edit  portion  of   the  personnel  and,
partially, payroll  transactions were pro-
cessed not at the Department of Interior,
but off-site at the same installation where
the personnel system was being processed
at Optimum Systems. Every two weeks at
the  end  of  the   pay  period,   tapes
mysteriously did not make it  to Interior.
Eventually  by  Thursday  morning,  they
would  finally get there, either intact, or
not intact.  Transacitons would then  go
into the system.   Studies found that the
object programs to do edits were approxi-
mately  9 to 12 months behind the object
program  which  was   actually  running
against  accepted transactions when they
finally got to Interior.  Software problems
were enormous. The accountability within
the OSI edit  process was  impossible, and
due to that fact, the agency recognized an
effort   to  directly  input,   through  1C
remotes, into Interior, transactions, then
do the  physical edits with the programs
that physically resided in Interior.   Let
the DIPS people maintain their own pro-
grams.   That, in fact,  did  happen  this
year.

     One of the major problems with this
system in the  past has  been the fact that
the individual that administered this sys-
tem, was not a systems person. He was a
personnel individual. When requests came
for data, various reports, various statis-
tics, the answer was generally, "It  is not
available in the  system."  Unfortunately,
it  was  available  in many  cases.    The
Number One  problem faced when I came
into this job was  getting back user confi-
dence in the capabilities of the group that
was  running  that  system.  That  has not
been an easy task. We feel, however, that
it has occurred to a reasonable degree. I
will explain the specifics. Last year, the
general  attitude of most of the users was
that the data was no good.  These  users
included personnel officers  in the  field
who,  in  fact,   were   responsible  for
maintaining the data.  They did not want
to use the personnel system.  It  was too
restrictive.   Consequently, most  of the
regions  wrote their own.  Many  dollars
have been  spent  agency-wide on manual
systems  that are  personnel  in  nature;
many dollars  have been spent and  much
duplication of effort has gone into writing
personnel computer  systems.  The  main
thrust of what we have attempted to do in
the last year  is to clean up our act, to get
                                         E-13

-------
user support, to  have users' confidence
restored,  and  to create  a  better  edit
process so that transactions are updated
on a timely basis.  Those actions include
the following:  On a three- to four-week
basis,  we have met with Interior  since
January 4th  and  discussed every problem
that existed with the direct input process
and any other  report, output, or process-
ing that they  performed as part of the
payroll system. Second, we have reviewed
all  testing  of modifications to  any of
those  processes.   To this  point,  we have
managed to  get  all of the training  runs
modified; the  microfiche  in  order;  we
have cut out approximately 35 percent of
the unused reports and added several that
were required to  get our jobs done, within
PMD.  We have also informed Interior of
the various items that we would like to
see  as additional  improvements to the
system.  As an example of  that  type of
improvement, the common account num-
ber was not  an editable item, per se, at
the  Department  of  Interior until  last
week.  It is now a mandatory edit item on
any new accession into the system or any
change to that account  number.  Conse-
quently,  within three to four pay periods
after financial management  cleans up all
of the bad account numbers, we anticipate
having no bad common  account  numbers
ever entering the system.  Therefore, that
problem  will  go  away.   That type of  a
problem  has  been  extremely time-con-
suming in  terms of trying to  find out
where the basic problem  occurs.  We have
got many problems  of that nature which
we have  solved.    While  they are  very
minor  in nature,  they  are  very time-
consuming.  They did, in fact, as a group,
effect the performance  of the system  in
terms  of report  accuracy,  in  terms of
understanding the data by a  person  or  a
coding clerk in the field, and in  terms of
effectiveness  of  a  personnel  officer
understanding  a  report.   Those  are the
types of things that we  regret.  In April
1977,  we did  an implementation  on  a
three   division   basis,    with    MIDSD,
Financial Management, and the Personnel
Management  Division,  the  T   and  A
process, payroll EOD's and also personnel
edit as direct input into Interior.  These
included training  sessions, not only  for
personnel coding clerks because they had
not had  enough training in the past, but
also for those within data processing  in
each of the locations so that the personnel
people had someone  to whom they could
go  to help run  the edit for  them, know
how to interface with Interior, etc. This
was a main  requirement  as  far  as the
system  was  concerned.   The types  of
benefits  that  we  have derived from the
direct input process  is that  we have  no
duplicate  records  now  going  into the
Interior process.  We  have  managed to get
rid of approximately  95 percent of the
major software and  tape handling pro-
blems.   We  have,   in  fact,  given the
regional personnel offices 10 opportunities
to edit their data against  four in  the old
system.  The interface with the personnel
input and the financial data is much more
significant and much more accurate.

      We have edit criteria being checked.
We have point of entry edits being per-
formed on the transactions.   Because  of
the fact that we now  have  real  editing
being performed on  the data on  a daily
basis  with  direct  feedback back to each
regional  office  that  next morning, the
accuracy  of  the data going  in is  much
better than it has ever  been.  The main
point is we do not have  more than about
five or six percent of the  transaction not
making it within a pay period.  This has
caused a great  deal of grief  to be taken
off of the personnel offices.  By no means
do  I  stand up  here  and tell you that
everything is perfect with the  direct-input
process.    It  is  not.   We feel that the
necessity of  discussing  how   things are
going with Interior will continue on  an
ongoing  basis.   We  are  still  asking  for
modifications  and corrections to be made
to that process.  The  other types of steps
to  be  taken  this   year  include  going
through all 1600 data sets that were the
results  of  seven  years  of programming,
examining  them,  finding  out what they
were  really attempting to count and list,
etc.   We  narrowed it  down  to 250
convertible data  sets,  then corrected,
                                         E-14

-------
modified, and replaced many of the pro-
grams.   As an example of what I mean,
there were 27 turnover reports, none  of
which counted the items  the same way.
All 27 went to  different users.  None  of
them were correct either.  They forgot  to
take into account that separations were
physically taken off the file from Interior
at the beginning  of the  year.   We have
now modified all of the reports in  such a
way that they are now correctly counting
the information as stated on the report.
There  will no  longer be any  turnover
reports going to OMB showing eight per-
cent.  It happens to be about 26 percent
EPA-wide.  In that conversion process  at
COMNET,  we did, in fact,  put  up alpha
procedures.   Every field  office has the
ability  to  access through  very  simple
instructions which have supplied to them.
They may run  any of the nine national
reports,  and many other  reports as well.
We have supplied a two-inch thick docu-
ment of  all the documentation within this
system  that is available  to the reigons
with file lay-outs, with an understanding
of what  the various procedures mean, and
an  easy-to-use  selection  and  reporter
capability  that they may or may not want
to use.  All of these books were supplied
to  personnel offices  and  the  systems'
offices  in  order  to  promote  better
discussion  or rapport  between  the  two.
This has  seemed to have been a problem in
the past.  Additionally, we looked at the
bi-weekly, monthly, quarterly, and year-
end processes.  We discussed the reports
that were going  to various users as  to
context, i.e., whether they  needed them
or  not.    We had revamped the entire
production cycle and gotten rid of most of
the waste. Where we have not gotten ride
of  waste,  it is because  somebody still
wants to hang on to a  report that they  do
not really need.  All minority EEO Affir-
mative Action reports  have been  reviewed
and are in the process of being rewritten.
They are approximately 50 percent com-
plete.  Once they are completely rewrit-
ten they will be made available  to all
regional   offices,   through  the   same
mechanism or a similar mechanism as all
of the national reports. Additionally, we
have satisfied approximately 700 ad  hoc
reporting  requests  within  the last  11
months.   The ad hoc reporting request
requirements are absolutely astronomical
at this time. They have been for the  last
several years.  The key problem with most
of the ad  hoc report requests is that they
were    always    required    yesterday.
Fortunately, we  have a little larger staff
than we did a year ago, and we have most
of the requirements fairly well planned.
Unfortunately, it is a tremendous drain on
personnel  and manpower.   One of  the
things  that  we  are  stressing and have
stressed  is  a need  for  a new system,
because the fact that 700 and some  odd
report  requests  in a  given year indicate
that the  current system  is not  in  fact
doing what the users  want it to do.  It is
not    meeting     the    requirements.
Additionally, the current  system  is  not
designed  to do anything  but  provide
rosters of people on your payroll. It is not
a  management  information tool,  not  a
trend analysis tool,  not  a training  tool.
The training system is inherent within the
DIPS system.  It has nothing  to do with
the personnel system as of this moment.
An Index Systems   Study produced in
February  indicated a definite need  for
management information   reports  and a
training system  included  in an excutive
development system.   We have not taken
everything in the Index System Study as
the verbatim  requirements of the  new
Personnel Management Information Sys-
tem  currently  under  design.   What  we
have done instead is look reasonably at
resources  and the  scope  of the job  we
intend to do. We have interviewed all but
two regions or labs.  We have interviewed
a minimum of 75 other officials and users
within  this  system, within Headquarters,
and in the field.  We have looked at every
regional system  of which we could get our
hands on the specs.  We have looked at the
thrust,  the  requirements,  and what the
agency  really needs  for an agency-wide
Personnel    Management     Informat:on
System.   The basic answer keeps coming
back: we need a position control system.
We need to be able to track vacancies.  If
you are not  a personnel type, you may not
                                          E-15

-------
know  what all that means.  The personnel
people do know what it means,  and they
are vehement about  having a system that
will  give  them  information  that  their
managers can use.  The current  system
does  not  do  that.   There are  time lag
problems.   There  are transaction pro-
blems.   There are  no vacancy records
maintained in the current system.  The
new system which has, at this moment, a
preliminary design draft has been sent out
to many  people in the  agency for review.
It is  approximately  four  and  one half
inches thick,  but does not cover all of the
areas in  the  system that  we anticipate
covering.  The design draft does, in fact,
show  the user what type of output will be
available in the new system.   It asks the
user to comment on what he would like to
have,  what he wants.   A portion  of the
design draft,  for any of you who may have
read it or are in the process of reading it,
is not the design draft on purpose.  It
happens to be about  the software we will
use, the method we will use, the  program-
ming  techniques  we will  use,  and  the
computer we  will use. The reason it is not
in the design draft is that we are  still in
the process of studying those questions. A
very,  very comprehensive  job has  been
done  by  NCC and  Univac  in  order  to
benchmark  DBM   1100,   a   data  base
management  system, to see  the relative
cost of that system using a live personnel
file  from  Interior  and  get  real  cost
figures.  At the moment, a comparison is
being done of DBM  1100 vs. System 2000.
That  does  not  necessarily mean  that  we
will, in fact, put the personnel manage-
ment  system  up  under  a  data  base
management  system.   We are  looking at
it, however, very strongly. The only thing
that I can tell  you about the draft  and
about the new  system is to bear with us
for the several months.  If you have any
input that  we have not yet heard, please
give us a call.  We  are  very interested in
your  needs, if  they have not been met
within the preliminary draft.   Some areas
will not be done in the initial system.  We
are not putting an executive  development
system  on the  air, although  there  are
some people in  Headquarters that feel
that is an extremely important thing.   We
do  not  feel  that agency-wide it  is  an
important thing for 400 or 500 people to
be tracked. We are not putting it on the
air because of  that.   We  are,  in fact,
looking  at a reasonable implementation
time of approximately a year for getting
it on the  air.  Once it is  on the air, we can
build on  it  and  add  to it.    We  are
attempting to  take an open-ended  file
approach,  and   an  open-ended  program
approach.
                                         E-16

-------
                             QUESTIONS AND ANSWERS

Question:       Mike, I think you  and your staff have come a long way in a very short
                time, but I still think you have a long way to go in establishing credibility
                in the national  personnel system.  Most all of us have, over the course of
                time, devleoped some kind of system, be it  automated or manual,  to
                perform the position management function and  some  other  related
                functions.  I think that at each installation there is  terrific inertia  to
                continue to  do  things the way we have been doing it.  You will  have to
                overcome that.  I  think you are taking the right  approach.  They are out
                there talking to us.   They are finding out what kind of feasibilities we
                currently have.  They are proposing a very flexible new system.  I think
                the success  or failure of that system will most likely hinge on how it will
                be done. The part that you really have not yet addressed.  I think that
                everybody would, in fact, support the concept of a centralized personnel
                system  that would provide position management capability, but  again, I
                think the credibility of the system is going to hinge on training the users
                on how the  system is implemented and subsequently operated.   I would
                hope that you would not stop with  the design considerations. This is all
                the flexibility that we could possibly give you.  The same level of the
                effort ought to be extended into how you will do  it.

Answer:        Would you like me to respond to  that?  Based upon what you have heard
                of what we  have managed to accomplish in a year, you may realize that
                we are very pragmatically motivated towards solving various problems.
                The most significant problem is the credibility of the system.  Unfortu-
                nately,  when we embarked on attempting to improve this system it was
                not at ground zero.   It was about  500 percent  below  ground zero.  We
                have seen significant changes of attitudes by your region.  We  are now
                discussing the system instead of being at each other's throat. In terms of
                being rational in what we are attempting  to create, I think we are. The
                reason why that portion is not in the preliminary draft, is not because we
                do  not  want comments  and not  because  we are not interested in your
                input.  It was  because  it was not ready within the timeframe  to  be
                delivered.   A tremendous push was made in order to get those design
                drafts to them  in  the  same conference, so that we  could  present them
                individually with  the  packages and explain what made up that design
                draft. Everyone will have further opportunity to discuss and comment on
                the hows, as we perceive them.  Just because we perceive them  does not
                necessarily  mean  they will be the  way we will go.   There are many
                factors involved in how we implement a  system.  Many of them  have
                nothing to do with the right way.  In terms of the history, we are  going to
                attempt to do it the right way. We will attempt all of the things we said
                we were going to attempt. I do not know if we will be successful, but we
                are going to try.

Question:       First of all, I would like to wish you the  best of luck. You know there
                have been, and I know I  have often heard, many comments made about
                the Office of Research and Development maintaining systems of its own
                which duplicate other systems in the Agency. I thought I might take this
                opportunity  to make the statement that that really is not true.  It is true
                that many of our laboratories maintain systems of various kinds for the
                                          E-17

-------
 Answer:
 Question:


 Answer:
Question:
purposes of extracting projects, people, equipment, and so forth and so
on, down the line.  To meet the kind of individual requirements of the
laboratory  managers, and it may be true that some of those systems are
duplicative, we could,  in some areas, depend  on  other  agency-wide
systems  to do some of  these things for us.  In that regard, we have
created a position which I now hold, Managmeent Information Systems
Coordinator for R and D. I now have an MIS coordinator in every one of
the laboratories.  We are making some efforts in reviewing all of our
needs  to try  to see where  we can use Agency  systems,  how we can
interact, how  we can eliminate the duplication, within our  laboratories,
of devleopmental efforts in these areas. The reason I take this moment
to make that comment is because:  First, Mike, I would like to invite you,
urge you and  myself to one day get together, discuss your efforts, what
you are planning to do, and come up with the admission that at  this point
in time, wide  basis is one of personnel position management system. We
have basically done  it in order to  monitor where our position are and
where the vacancies lie.  We also have it for descriptive information. We
certainly are  very hopeful that if  there is  any chance that your system
has what we need or will be able to make it available to our managers on
a timely  basis, we would be able to retire the last of our own independent
system.

The only comment to that is that we have recieved a great deal of input
from  R&.D, all of the documentation of your current personnel system,
and a  great deal of  data on  types of reports.  Yes, we will get together
further.

Is there now a workable file of minority classification coded requests by
Civil Service Commission?

There  is  a  minority code attached to every individual's record.  There are
access rights to the data base which was not the case as of March of this
year.   All  of the minority reports  that  the civil  rights people have
authorized will, in fact, be available to any user for  their  individual AA
region, lab, or  whatever.   They have  lists of each  individual and that
individual's minority file.  We can, with the cooperation of civil rights,
print  that for  any appropriate individual in any reigon, AA, or  whatever.
One of the difficult things in trying to administer this system has not
been  the software involved, but people making  decisions about things
like, can the regions have the minority code because they  are asked to
produce  all these reports,  and they cannot  see  them?   They are not
allowed access to the code, therefore, how are they going to produce the
report?  They are supposed  to go around and do head counts when they
have a system that  can  do  the job for them.  That particular question
took  approximately  eight   weeks.   Finally,  civil  rights  authorized
personnel officers to see those minority codes.  We are still working on
those  types of problems.  Mary.

I  have two questions for you.  One is, who are the current users of your
system in terms of general  categories,  people or organizations?   Along
that line, what kind  of information do you provide them now?  You have
described the  how's of implementing  the system.  Since I  am  not  a
                                          E-18

-------
Answer:
Question:
Answer:
computer person, I have heard the question asked in computer terms and
answered in computer terms. What do you mean by how that system will
be implemented?

Let me take the first one.  The universe of our users are the 14 personnel
officers in the field, along with Headquarters,  which  we now consider a
personnel office. We do not consider Headquarters vs. the regions.  One
of the primary problems had been that, Headquarters was Headquarters
and the regions were somebody else.  We are still doing the  operations.
The  only difference is the  volume  of  data  they  maintain.   Those
personnel  officers   through   directions  from  management  division
directors—from RA's deputy RA's,  lab directors, etc.—are requesting
information out of their system of rosters of  organization, code  runs,
breakdowns of numbers of people in various class series jobs,  statistical
information, such as the turnover for permanent individuals and others in
permanent full-time.  They want to  see things like,  who  were  their
separations for  the  prior  quarter.   They  want to see  a  computer-
generated form for  performance appraisals.   That data is available to
every  one of the personnel officers in the field and  to  Headquarters
personnel offices.  It is easily accessible to a non-programmer who, in
fact,   has  the  knowledge to  get  on  the  COMNET alpha  system.
Additionally, we have approximately 750 special requests a year. These
requests run the gamut from the National Science Foundation doing the
study  of  the  pesticides area  which entails approximately  45 various
production runs generated for almost aproximately a year and a  half.
Period of time:  Every  quarter, to Personnel Management  Division in
Headquarters.   We  have approximately eight other  systems that  take
data from  our  system on  a continuing  basis,  such as  the programs
reporting system, the resources management  information system,  etc.
The users, by-and-large, can be characterized as anybody who happens to
be a manager in EPA that has a need to know about his personnel, about
the  Agency's personnel, about  Headquarters' personnel, or  a  given
region's personnel,  or a  lab's personnel.  The key under which  we  have
been operating is that we will refuse no one.  We will attempt to satisfy
everybody's needs.  So far we think that on an ad hoc basis, we have done
that for this year. I do not know if we can continue because the number
of requests keep increasing. As far as the "how" in the  design,  what we
mean  by  "how"  instead of the "what" is  that the "what" is the various
reports.  The "how" is techniques, the type of software and programming
that will  be done in  the new personnel management information system.
The methodology by which we plan on implementing the  system, all of
that is not in writing. All of  that has not yet been completed. That is
the part  of the design draft which  is missing.  It is also  the part upon
which  we intend to  get  further concurrence.  In fact,  we have to get
further concurrence on the  entire design draft, once we have included all
of the comments from everybody in that draft.

Why can we not get a copy of the training file from Interior and put it up
so we can access it?

Because they can not find it half the  time to be quite honest with you.
That file  is approximately 75,000 records at this time.  It has not been
                                          E-19

-------
                examined very closeZy as to accuracy.  / would venture to say that it is
                probably 60 percent accurate. It is probably 80 percent accurate for this
                year, but for prior years, it is very inaccurate.  It will not get better
                unless we do something, and we will in the new system.  It is planned as
                one  of the areas  of  the  new  system that will cover each individual's
                record. Now we are going to do whatever conversion we need in order to
                get that file brought up to the new system.

Question:       Let  me make  a point.  Up to this quarter, training data by  individual
                regions, in terms of reports, was not possible.  They were manually put
                together.   What  happened approximately  three  months  ago,  Interior
                agreed  to  revamp all  of the training reports.  You will get  your own
                reports within three weeks.  They are still trying to assimilate 18 boxes
                of paper.  I was wondering if you could tell me what kind of efforts you
                need so far.  Where are you planning to go relative to integrating your
                system requirements with  what is currently available with PMIS and the
                Financial  Management System?  It is of some concern in our region, and I
                think it might  be in  other regions.  Systems of this  type  had  to be
                developed  in a data  vacuum   when in reality  all phases have  been
                interrelated.  To ignore those data bases and the tremendous cost that go
                into developing that data seems to be ridiculous.  I wonder if you could
                just  tell me what is going on?

Answer:        Basically, we are taking the premise that we have not had anything up to
                now. The system which this agency had for six and one half years was in
                shambles for all intents and purposes. The systems which you  have right
                now is only a stopgap method so that we can implement a new system. In
                terms of interfacing with that  RMIS system, which is in a state  of flux
                concerning how the ZBB effort will effect  it, we  are, in fact, interfacing
                with  it at this  moment,  in terms  of  trying to  get  account numbers
                correct in everybody's files.  What we are  doing is trying to take care of
                our area, first, with the knowledge that  we interface with other systems,
                that we do have an effect on other systems. In terms of input from other
                systems, there is none in the personnel system, itself. Where we need to
                get input, we will, in  fact, build whatever criteria  we need to get that
                input. Interrelating these  systems is a major problem  that I would not
                tackle as an individual systems  manager.  I am aware of the problem.  I
                think the other system managers are as well.  I do not  think that one
                systems manager,  or three or four together, could thrust the  Agency to
                an integrated data base concept. That is a major Agency effort.

Question:       Is it  worth it, though?

Answer:         It may be worth it, but I do not know if we have enough computer power
                to handle it all at one  time.
                                          E-20

-------
                        CONTRACTS INFORMATION SYSTEM
                                  Edward McLean
     I inherited  a system  about  a year
and a  half ago.   I  don't know anything
about ADP, but my  system was designed
by ADP people who did not know a damn
thing  about contracts.  When the  system
was designed, we asked that it be designed
in self-defense,  because we have  used
these daily calls  from  the  administrator
who wanted to know how many contracts
were  issued   in  the  3rd  Congressional
District  of Mass.   Then we  put every
secretary and  every  contracting  officer
looking in  the  file drawers.  We decided
that this was not  very good.  We got a lot
of people working that way, but not much
information.  So, we did ask that a system
be designed;  the designer of the  system
felt that they had to  make  the  system
meet  some criteria.   For example, they
decided that  they would not  leave  any
room  in our file for more than 10 contract
modifications.  We got fixed length files
so that any contracts with more  than 10
modifications  will not show  up.    They
decided that we could only have five lines
of financial data.  We have as much as 20
lines  of DCN's and can numbers,  but we
can only  show five.   As  a  result,  the
largest dollar which shows  on our report
may have 15 to 20 lines for  counting data
combined  in  there.    This  system  was
designed basically as  a  defensive move
and as a management tool  for contracts
only.  We do over  3,000 contracts  a year;
these are not  purchase  orders,  they are
contracts.  Any action over  $10,000 has to
be a  contract, it cannot be a purchase
order.   We do 3,000 of  those.   In  each
contract, there are 8 to 10  steps that we
call milestones which must be detailed so
that the manager can look and see how his
contracting officers are doing.  What we
do  is  we  produce  a  report for  each
contracting officer showing each action
that  he  had.   When I say each  action,
every time one of you sends in a  PR for
contract action, it is assigned  a number,
an RFP  number,  no matter  whether it
goes out into  the street.   The number
tracks it.  We have 82 data elements that
go into this.  We have  1728 characters in
each  contract record  available to  us.
Some of them we never use; in some, we
need more, but every milestone is tracked
until an award is made. Once the award is
made, it (the contract) goes into limbo,
because our job is to issue contracts and
not to do anything else.  We do have some
sub-systems such  as the CAS,  a system
where  all the contracts,  after  they  are
awarded go in and sit.  If anything happens
to them, we can put some data entries in.
Like if we ever make final payment, we
can put a  data entry in our system and
show that the contract has been finished
and paid off.  We issue around  100 stan-
dard reports a month;  that is 100 standard
reports  a month, plus an average of 60
individual ad hoc requests.  We do have
enough   data elements to give a lot  of
contract  information to a  lot of people.
We can tell any Congressman how  many
contracts  were issued in his  district  in
each year, quarter, or at any time, or how
many contracts were  awarded  in  any
region.   Anything that  we have in  the
system we can get  out.   Now, we  did
decide  that   the  system  badly needed
overhauling, but the present system could
not be fixed economically, so  we had a
feasibility study done to see whether we
could get a new system  and mount it on
the mini-computer.  The feasibility study
showed that we could mount this complete
system on a  mini-computer and have the
mini-computer dedicated to us where we
could get good turnaround.  This may have
been one of the few times in a feasibility
study where we decided not to go with it.
There  were  two  reasons.   One  was the
OPM-ADP action plan which said that we
should   move  our   system   to  North
Carolina.   The other  is  that  I, myself,
knowing nothing about computers, did not
want to be responsible for a POP 11-70,
which is, I think, what they recommended
for our system.  I wanted to be able to
blame  somebody else  when  this  thing
                                         E-21

-------
 broke down.  What I have  done is get a
 system development done by Sigma Data
 which developed this new system. Unfor-
 tunately, Sigma Data was not awarded the
 f ollowon contract.  When our CIS contract
 came up, they did  not make it.  Now  we
 have  a  new  vendor,  VITROLABS,  a
 division  of  Automation  Industries, who
 will be the implementer.  The new system
 will  be completely implemented in the
 Univac at NCC. I have a target date for
 May.  I am not saying which year, but my
 boss thinks  it is this coming May.  I have
 been learning with this ADP  thing that
 you never make any definite statements
 because they can really get you.  My plan
 is,  before I  have  this  thing  running  in
 North Carolina, I will run it three months
 parallel operation.  The present system
 may be screwed up a bit, but it is running.
 Once  we can see our  way clear that the
 system is going, we will swap  over.  The
 system will be variable in length. We did
 get a lot of  input to it,  and we are going
 to make  a lot of changes.  We update the
 present system every two weeks.  We have
 a pre-edit prior to update, then update,
 using batch entry.  We can  inquire of the
 system now  through alpha and IRS: most
 of our minor  programs are IRS.  We have
 four major  COBOL programs and 50 IRS
 programs,  but  we  can  make  on-line
 inquiries, because we only have two weeks
 behind, or maybe even a month behind  if
 the information does not  get  into the
 system right at update.  If it comes in the
 next day, it could be a month.  One of the
 other  things we  do besides the  standard
 report, is that when we put out a report
 on NSF case studies on R&D contracts, we
 direct it on keypunch cards and transfer it
 to them.  We have an active contracts list
 that we publish every six months. It lists
 every active contract in the Agency. We
 are probably the only outfit in the Agency
 that makes any money, because we charge
 $25 a throw for  the active contract list.
 For you all, we have reduced it to $5.

      When we get individual requests, we
put  them out  at  remotes;  some of our
standard reports are off-line at remotes.
I  made the mistake, when I first got into
this job,  of seeing if we could eliminate
some  of  these  reports.   I  sent out  a
request to all managers that were getting
reports,  asking  which   ones  I  could
eliminate, I got back requests for 15 more,
and finally decided  that there was no use
in doing  that.  What I do periodically is
have  my  people that make  the report
distribution not  send a report for about
five  reporting periods.  If I  do not  hear
anything  from them, I just cut it off, and
they do not get any more.   I found that
some of our bosses have piles of readouts
on the back of  their desks, so that  they
can impress people when they come in.  I
figure, hell, they could  use the same one
for a year; it  will not hurt them.  It has
been an education for me.  I still do not
know much about ADP, but I do know how
the Agency feels about it.  I have heard
people stand up here and say that they are
working  on assigning numbers to every-
body with whom they do a grant. We  have
assigned  3,000 numbers. Every contractor
we have ever contracted has a  number,
but no one ever came to me to ask if they
could use our number.  I would be glad to
do that.  There are six or eight managers
here and there is not one or three of us
who  could get together and  decide  what
information could be in one  system.  We
all know that there is a heck of a lot of
this  information that should be  in  one
system in order to  be able to retrieve  it
from  us.   The  fellows who  know more
about ADP themselves  could put  their
finger on it.   We all know each problem,
yet we keep going our own ways because
it appears that there is no Agency move-
ment  to  centralize  or, at least, to get a
data base to which all  of us can contri-
bute.  We do not do  nearly as much money
in contracts as we do in grants, but we are
just a drop in the  bucket.   We did $220
million in  contracts last  year.   It  is an
awfully  political  thing.  Everybody wants
to know something  about it.  It is the type
of information that  we give out every day.

     I will say that there  was a reason
that I was put in charge of this system.
One was  because I was its biggest critic as
                                          E-22

-------
a contracting  officer.   The  contracting      to do  is  make  it  easier.  I am still a
officers did all of the input in to it.  The      contracting  officer.  My job  description,
people who did the  input  got absolutely      though, is manager of the system.  I have
nothing from it, so they are reluctant  to      to input, so I know myself on a daily basis,
input.  One of  the jobs I have been trying      how it  is to input to the system.
                                           E-23

-------
                            QUESTIONS AND ANSWERS
Question:
Answer:
Question:
Answer:
Question:
Answer:
First of all,  is the  contracts  planning  system part  of  the contract
management system?

You hit me  in a sore place with  that. We have so many planning systems
in this Agency that it is incredible.  The contract planning system gets
its information from the Contracts Information System. In other words,
the input we put in is extracted to ran the contracts planning system.

What you are  basically  saying  is that  there is very little relationship
between what we put into the system every year for planning purposes
and your system. When will that change and why should  we, as managers,
put anything into that system? It does not help us.

Let me say this.  One of  the reasons I am in the  job  of managing the
Contract Information System is because -when I was head of the special
projects section for CMD, I criticized the  contracts  planning system,
because it could not cross feed with your system. Our new system should
be compatible with Financial Managements.

I   think  the  system  is,  from  our point  of view,  something  that
(unintelligible).  It means that something has fallen through the cracks
getting to you.  We know some of it is  not your fault; it is not our  fault
either.  One observation that some of our people have  made  is that, in
the tracking system if they could have a date for when it is expected to
hit the (unintelligible).  That may be helpful to us.  Otherwise, it could
change significantly and it  would not show any differently on the report.

There  is a  couple of things.  One is the broad time  where  nothing  is
happening because generally nothing is happening.   I trust I  am among
friends here. As you know, if you send in a procurement requirement (we
do  3,000 a year and we  have roughly 75 people doing  this through the
Agency), you can see  that  each person has a hell of a lot of action,  when
it comes in. They do have in contracts a milestone system for  all actions
over 100,000.  They are now supposed to prepare a milestone chart  to go
to  each  project officer  which  will  give you the  milestone.   In  other
words, if he gets the procurement on  November 1st and he  expects to
have an RFP out on  November 30, he should not have  that on the
milestone chart.  We talked about having some kind of a milestone  chart
within the CIS, but I put the nix on it because it is so hard to get them to
put the basic information in it  that  I did not think something that  could
be used to shoot them down would ever get in there.  On that basis, we
can not give you that information, but  if you get  a report, and it shows
that nothing has happened, you can be sure that nothing has happened, or
the guy that is doing it has not put it in. Since this system is a defensive
system for the contracting officer, it behooves him to get every bit of
information that he does in the milestone because his boss is going to use
it to shoot him if it is not in there. So  this is how this  system works.  If
you do not put it in, the boss takes pot shots.

-------
Question:
Answer:
I think the development of this contract system, probably more than any
other in recent years,  has  pointed out  some  of  the  problems in the
Agency in terms of the lack of coordination in  the management system.
It may be a long time—in fact, it may never come about—before the
Agency decides to integrate this management  system.  Maybe it is not
the right thing to do, maybe it is just too costly. I do not know.  A lot of
problems could be resolved, I think, if there was simply more attention
paid in the beginning when the systems are developed. On the part of the
managers, they could coordinate  more  with  one  another in terms of
making sure  things,  such  as common terminology is used.   There are
people who have tried to use the same kinds of coding in their system.
There has always been a problem between Finance and Budget.  They use
slightly different categories in their two systems.  We have gone through
a lot of manipulation with financial management to get the reports out
of their systems that are in the  same  categories as the information that
you put into the MRI5 system.  In your system, you had a definition for
commitments which  was distinctly different from the definition used in
the Financial Management System.  It caused a great deal of concern on
our part in terms  of how we interpret that data.  Also, you mentioned
that your system  was  principally one  that was put  up by contracts
management for their own internal management purposes.  That  is all
well and good; in fact, I might say that often, if that is your real desire,
you  might be  better off not giving  other people outside your office
information on your system.  If you are going to do that, you  have to
expect that they will start looking at your system as one to service them.
When  they  get information from  it,  they  become critical  of the
information.   We  have  gone through  a lot of  man-hours doing  manual
comparisons  of information in the  Contracts Management Information
System and  the Financial  System.  We have found that the two  disagree
greatly.  That concerns  us.  If all these systems are not, at one point in
time, combined into one gigantic data base, there could, at least, be
some mechanism to  provide  some  means  for  these systems to check
against one  another automatically.   This would  see to it that the
information in  them, where it is comparable, is consistent.  I think is
really  something to  which you,  as managers, ought to try to give some
more consideration.  I think it could be done on some automated basis. It
would save a lot of the program offices a lot of time and effort.

/ can't say that I agree with you more.  Here again is a point where the
managers can  talk among themselves.   There has  to be,  however, a
central coordinator.  We  use a lot  of  the same data  that the  other
systems use;  we use  a common accounting number.  We use the  DCN's  .
A lot of that type  of information is the same.  Some of the discrepancies
in dollars occur because the Contract  Information System does not track
committed dollars as such.  We  have them in  there,  but  committed
dollars  fluctuate.    What  our  system  tracks—/ win go  98   percent
accuracy on this or better—is obligated dollar. I would say that for the
fiscal year 1977 data, we had 86 percent or higher  accuracy in obligated
dollars. I expect to see  near 100 percent accuracy in obligated dollars for
fiscal  1978.   That is for  the present  system.   We  were having our
problems with matters of input. Of course, it was a crossfeeding of the
systems' everybody speaks in a little  bit different language.  The thing
                                         E-25

-------
                that really counts in the end is how  many dollars have been obligated.
                All of you who send your money forward as commitment to us would like
                to  have it   reconciled  after our obligation has been made.  A good
                percentage of the  time we  obligate less money than we  commit.  I
                wanted Mike Platt  to  tell me how  he reconciles that and puts that
                unobligated part of the commitment back to the users. I think that is a
                problem.  I do think it will be continuing problem until there is some type
                of  integration and understanding in what obligation, commitment, and
                these different terms are among each of us.

Question:        Our particular  Region  never seems to have very many funds for
                contracts,  so I do  not  think  I  can  comment about  the contracts
                management system.  I would like, however, to  tell you, Ed, that you are
                picking up the ADP job very fast.   Good luck to you with your new
                system.
                                        E-26

-------
                          PERSONAL PROPERTY SYSTEMS
                                   Carlton Woodell
      I am not an ADP person, either.  I
 believe I was selected because the system
 is  simple,  I was  probably  the  biggest
 simpleton available at  the time.  That is
 why they gave it to  me.  I  would like to
 begin with a little synopsis  of the  back-
 ground on this system.

      The  Personal  Property  Accounting
 System is mandated by Sec  202(b),  the
 Federal Property and Administrative Ser-
 vices Act of 1949, as  amended (10  USC
 483) and Sec 2, Public Law 84-863 (31 USC
 66a(c)).  The system is decentralized to
 the 10  EPA Regions;   O.A.,  Cincinnati;
 O.A., Research Triangle Park; ERL, Ada;
 MVEL,   Ann  Arbor;   ERL,   Corvallis;
 N.E.I.C.,   Denver;  EMSL,  Las   Vegas,
 Nevada; and Headquarters,  Washington,
 D.C.  EPA-MIDSD is also a  user.  All of
 these users  may  input or retrieve  data
 simultaneously.   Additionally, each  user
 may edit his  input data  at any time.

      The system originally  was installed
 by  Sigma Data on the NIH computer at a
 total cost of slightly over $14,000, which
 is unbelievable at today's prices. A record
 of  that is still on file  in Frank Bullock's
 office in ADP. Originally, the entire  file
 at  NCC  was written in IRS, with source
 language and retrieval language. We were
 selected to be the guinea pigs to transfer
 over  to  the Optimum  Systems  Incor-
 porated  IBM 370E.     We  did  convert
 virtually  all  the  retrieval  to IRS;  the
 source programs were put in COBOL.

     Along about the  early part of this
 year, they were  looking for a simpleton
 again, and guess  who they found.  I was
 approached and asked if I would volunteer
 to put this system on the NCC UNIVAC.  I
 will be serious and make one  statement.  I
 think it was  the smartest  thing we could
 do.   On  July 1, 1977, the EPA Personal
 Property  Accounting  System  was  con-
verted from  an IBM  370 Computer con-
tracted   from  Optimum Systems,  Inc.,
Rockville, Maryland, to the Government-
owned  UNIVAC   1110   located   at   the
National  Computer  Center,  Research
Triangle Park, North Carolina.  The  file
definitions, per COBOL requirements, are:
Recording mode is SDF; block contains 50
records;   each   record   contains   340
characters.  Files,  except  for tape files
and  PPS-backup  files,  reside on a  dis-
mountable disk pack.  Working files, e.g.,
special reports programs, are assigned to
"free" space.  All files are catalogued.

      The system,  at  present,  contains
approximately 70,000  records, including
owned and leased property.  It is  updated
after 4:30 p.m.  on  the   third   working
Wednesday of  each  month.   This  run
collects  the transactions from the user's
input files into a  single   input  file  and
passes that data through an edit program.
The   valid  output  data from the   edit
program is used to update  the master  file
on disk  and  tapes.  Error reports gen-
erated by the program  are identified by
user  and forwarded for correction and re-
submission.   This  program also produces
the required property management reports
plus  a  summary   of  dollar balances of
owned   personal  property "charged  to"
each  user  for monthly posting   in  the
general   ledger maintained by the  EPA
Financial Management Division.   Concur-
rently a "split" program is executed which
divides the 70,000 records  into four files,
consisting  of data  relating to  specific
users.    Thus,  users  only  "read"  about
15,000-20,000 records instead of the entire
70,000 in the master file.   The  Property
and Supply Management Section does  pro-
duce  reports  on  an  Agency-wide basis
using the entire 70,000 records data base.

      We have had bugs.

      Initially,  after  conversion   to  the
UNIVAC 1110, all reports were generated
by the  use of "canned" SCORE  modules.
This  served well enough for basic routine
                                         E-27

-------
reports,  but severely limited our flexi-
bility for retrieving multiple data without
requiring a special programming effort by
the contractor which, in turn,  was time
consuming and not entirely satisfactory.
Several conferences were held with NCC
and contractor personnel which resulted in
our being permitted to use the Inquiry and
Reporting System for data retrieval.   It
was  made   clear,  however,  that  this
language was not completely "debugged"
in the UNIVAC 1110.

      There  are  several  versions of IRS
available viathe UNIVAC.   The  latest
being TSSMS*IRSSYS/V1RO. We are using
version 7 (IRSSYS7) and, except for cer-
tain functions, have  found  it acceptable.
Any  "bugs"  are reported  to  the  User
Support Service, NCC, to be corrected.

      There are 27 data  elements entered
into  the personal  property master file.
Each data element ranges in size from 1
to  44 characters.    A  data element  is
merely one  piece of information needed
by   managers   at   various  levels   for
different  reasons.    Reports  may  be
produced for any  or all  of these data
elements.   For example,  the Report  to
Congress by the Comptroller General  of
the United States,  dated May 3, 1976, on
"the  Need  for  Better  Management and
Control  over Scientific Equipment" was
critical of the need for  better equipment
use through  "pooling  and sharing."  As a
result, a new two -character data element
was  added   to  the   system  entitled
"USAGE".   Data  entered into  this data
element  indicates to managers  the  fre-
quency of use by a numeric entry plus an
alphabetical  character explaining why the
item  is/is not idle. Thus, an entry of 4D
would mean  that  the item  is  used only
once  a month and that it is sophisticated
instrumentation requiring highly skilled
operators, 7K would  mean  that the item
has been used one time  only and is  being
held for  priority use  in  field studies, but
can be used in the interim.

     Another report  useful for personnel
in the budgeting area is a listing of all
items scheduled for replacement during a
specific  fiscal  year.   This data  is, of
course, generated by the computer based
upon   the  acquisition  date   and  life
expectancy tables  derived  from D.O.D.;
V.A.; DHEW; Coast Guard;  GSA; etc. In
the same manner, the system will provide
data concerning dollar amounts expended
by cost accounting  codes during a specific
fiscal  year for  specific types  of  equip-
ment.   Staying  in  the budgeting field, a
listing of  all EPA excess  equipment is
available to  all users at any time at no
cost.  This listing is updated monthly and
should be reviewed by property procure-
ment and other managerial personnel prior
to purchasing new equipment.

     The  reports  mentioned  above are
only a few of these available  from the
Personal Property Accounting System. To
repeat, information may  be retrieved in
any desired format by any of the data
elements, including both owned and  leased
property.  Here  in the Washington  area,
we have, at times,  been  asked  by various
police  jurisdictions to determine whether
or not a stolen item might belong to EPA.
Usually only the manufacturer, model, and
serial number of the item is known.  The
master file is searched by  serial number
and the result is telephoned to the  police
in a matter of minutes.

     In summary, the 27 data elements in
the master file include a variety of data
useful to managers  at all levels  as well as
those in non-managerial positions.   This
data includes the name of the item, cost,
location, identity of the  acquisition docu-
ment, status, and the name of  the person
to whom the equipment is "loaned".

     Our   experience   indicates    that
virtually  all programs  executed on an
overnight (D/R) priority vary from  10 to
60 percent cheaper using the UNIVAC 1110
vis-a-vis the IBM 370.   We have had no
experience on priority-run  cost compari-
sons, as  such  priorities are not available
at NCC  without special concurrence of
management.     In  our  opinion,   using
UNIVAC edit processor for text editing is
                                          E-28

-------
far more expensive than using WYLBUR
on the  IBM to  include connect charges,
etc.  This has resulted in our discontinuing
the use of several highly desirable  123
character "working files".  We are coordi-
nating with EPA-MIDSD personnel to uti-
lize  a  Data 100 keybatch remote  entry
terminal for text editing  and  subsequent
transmittal to the UNIVAC 1110 of the 123
character files.  We are also in  the initial
stages of using the University of Maryland
edit  processing  procedure  which,  we
understand, is somewhat cheaper than the
Exec 8.

      For future planning, it is our belief
that, in compliance with  the Accounting
Principles  and  Standards  for  Federal
Agencies issued by the Comptroller Gen-
eral of the United  States and Part  II,
Section VIII,  Property Accounting,  EPA
Order 2550.1, Accounting and Finance, the
requirement  for   the   EPA  Financial
Management  Division  to reconcile  per-
sonal property  assets with  the  general
ledger sub-accounts plus the requirement
to   maintain   depreciation   values   of
individual items could be accomplished by
an "interface"  with the life  expectancy
table  and the  individual  item  record
stored in the personal property accounting
system.  We do not feel that the Exec 8
software  is as  simple or as powerful as
WYLBUR; however, this is greatly offset
by new capabilities available via Exec 8.,
e.g.,  the "(aSORTF" command and  the
"(gFAC" command.   Turnaround time  is
normally  overnight with virtually no-run
priorities available, although the use of
the   "@ADD"   command   will   permit
immediate job execution, with output data
printing on the  R3E terminal.
                                          E-29

-------
                             QUESTIONS AND ANSWERS

Question:       I would like to thank Woody for volunteering to go to NCC for us, to do
                the ground work, because I had heard some horrendous things.  I figure if
                he could live through it we would be all right.

Answer:        I would like to reassure you.  We have people that take inventories based
                on nomenclature.  Bear in  mind that when  we installed this system  in
                1972,  we  amalgamated  a force in roughly eight  different data based
                systems, i.e.,  the Atomic Energy Commission was  on cards, some came
                to us  on tapes, and some were manuals. Therefore, the starting position
                on the format of the  master files  still does not appear on the starting
                position on which it should appear.   We will say that the Department of
                Interior transferred an item to us in which the model of an item was part
                of the nomenclature.  We allowed 44 characters for the nomenclature on
                any item. We have a block size of 340, and  we are actually using about
                380.  Within the system, there is a slight interface of a sub-system with
                EPA-MIDSD, in which an annual report is generated based partly on data
                that they store and partly on data that we store.  This produces a final
                report that goes into GSA on ADP  equipment, both leased  and owned.
                Relative to  the interface with financial management that we have been
                attempting this for the  last six years.  We  have  the can number.  The
                regulation supplementing the law requires that the assets maintained on
                the record of finance be depreciated.  We have brought into the system a
                life expectancy table for each item which could readily be used as a
                straight line depreciation table.  It  also requires that the dollar amount
                of the fiscal records be reconciled with the personal property account.

Question:       You said  that the development cost of PPS was approximately $14,000.
                Does  anyone know what the conversion cost  was to get the thing up and
                running at NCC?  In comparison to that, second of all, I think we know
                how Mike Kaplan feels about moving FMS to another IBM system,  how
                would he feel  about moving it to NCC? Most people seem to agree  that
                it would be really nice if we could integrate all the OPM systems in some
                way,  whether  they go into  a common data base or whether they are all
                separate,  data bases, but simply linked.  Might it be more productive for
                the Agency  to attempt to do that rather than spend its resources trying
                to transport all these systems and convert them to run on  the 1110?

Answer:        May / offer a reply to that.   This  was my  really  third  experience  with
                these  conversions.  I am  sort of  a guinea pig  to  this.   This  is the
                smoothest one yet.  I asked whom it cost. I am a taxpayer, too; I realize
                that  cost is  very imperative.  I  believe  that  the learning  process,
                developed by  NCC personnel, by contractor personnel, and certainly by
                me was well worth it. I believe if you do convert and you do use—I am
                sure many of you use COBOL and IRS—the  packages will be even easier
                for them.

Question:       Just one quick question. I have tried in a  couple of cases—it could  be
                cause we  do not know how to do it—to get  a word processing listing of
                property for the  region,  and a combination lease  purchase just for the
                region.  Is there something else available that I  probably do not know
                about, especially for the word processing?
                                          E-30

-------
Answer:         I am not exactly sure what you mean.  I think I know what you mean.
                Normally, word processing would be retrieved by a data element called
                category either for owned or leased properties.  This consists of a three
                character code assigned by MIDSD, EPA, or you go to the first two digits
                of the national stock number, which in this particular  case, I believe, is
                70. If you pulled 292 for the length of 2 equal to 70 for 24 for the length
                of two equals 11 (unintelligible), you would come up with all of your ADP
                equipment.  On the leased property, if you would just put down less than
                100, you would come up with all of the leased property.
                                           E-31

-------
                                     Paul Wagner
      Basically, I  would like  to run  over
 what the system is, and let the questions
 lead  us  to wherever they may.  First of
 all, there are two basic delineations of the
 kinds  of  data  in  the  Grants  Information
 and Control  System (See Figure E-l).  On
 the one hand, there are state and local
 assistance grants data  bases, which  are
 divided  into two  parts; namely, regional
 construction grants and  other  regionally
 administered programs.  These are made
 up principally  of  grants data related to
 state and local governmental  support pro-
 grams.  On  the other  hand is the Head-
 quarters grant data base which consists of
 the research,  training,  fellowship,   and
 demonstration  grant applications,  active
 projects, that  type of thing.  These grant
 programs  are  managed through  Head-
 quarters rather than regions.   The state
 and local assistance data base has all the
 data that relates to grants in  the regional
 offices,  including  component systems, the
 regional construction grants MIS; and the
 water quality's 208 Management Informa-
 tion  System.   Headquarters' data  base
 includes  the small Clean Lakes System
 and also are  ORD sub-system which tracks
 grant  applications  during the  review pro-
 cess. The general types of information we
 carry  in  the  system—and  this  varies
 depending upon the grants program—from
 pre-application  data   in   construction
 grants which starts  with state planning
 lists, the so-called  state project priority
 lists.  Some  of the other programs  do not
 come in  until application time.  Basically,
 this  includes  information   to  identify
 grant, the  project,  or the  application;
 information  to  identify the  applicant,
 geographic  location  of the  applicant or
 project,  a description  of the project,  and
 the  money  awarded  to the successful
 applicant.    In some programs,  there is
 general summary data and outlay informa-
 tion and, particularly in construction, pro-
jection information.   The  construction
grants program is  far more  vast, than all
of the other grant programs put together.
     In 1971, there was an RFP out on the
street;  we  received  some 18  proposals
from  industry  to  do a  system analysis,
design, and implementation of a combined
grants and contracts management infor-
mation system. For reasons only known to
people who have long since left EPA for
better things, that  effort was abandoned
in 1972.   We  went our separate ways.
When  that  effort  was  abandoned, we
started building a small system to track
grant applications.  At that time, that was
a major problem in EPA.  Everybody had
heard about EPA and all the  money they
had for research and training.  Applica-
tions were actually  piled in stacks four or
five  feet  high.  In  those days we had to
find  out from  who we  had  applications
from  so when  a Congressman wrote and
asked what we  were  doing with one, we
knew we had it. That was the big thing in
1972.  We expanded the system in 1973
and  started  taking up  pre-  and   post-
application data. We started getting the
regions involved and started working with
the Municipal Construction Division and
the Management Information Data Sys-
tems  Division.   They  had  grown  from
branch  to division  status by  then.  We
implemented a  regional program princi-
pally  in the  Wastewater Treatment Con-
struction Grant Program. In 1974, we got
more concerned with trying to establish a
quality  control program  on these data; in
1975, the Office of  Water Program Opera-
tions  had  a contract  with Arthur Young,
Inc., to do a  major  construction  grants
systems study.  That study resulted in a
significant modification  and expansion of
GIGS.  In 1976, the expanded system, GIGS
II,  was  implemented.    Last  year,  we
picked  up  the  208  area-wide  planning
grant  water quality  information system
and a small clean lake system. Also, GICS
was  extended  to  include  the State of
California's    Wastewater    Treatment
Construction activities  performed  under
EPA delegation of  authority from  Region
IX.
                                           E-32

-------
     GICS's objectives are to make avail-
able grant activity information to project
officers   and   regional   and   program
management on a weekly basis;  provide
rapid response to special information re-
quests from  grant  applicants,  Congress,
and  EPA senior managers; provide rapid
response to  project  officers,  program
staff,  and  grants  specialists in   solving
daily operational problems; permit mana-
gers to  discontinue  unnecessary   manual
recordkeeping  and  reporting procedures,
both in the regions and Headquarters; and
provide a system design module that can
supply standard management information
on  an  Agency-wide  basis and  still  be
modified to meet special  operational re-
quirements of the respective  regional and
grant program managers.

     GIC5 uses the computer and national
communications facilities of EPA's Wash-
ington, D.C. computer center which are
operated and  maintained  under contract
by   Computer  Network   Corporation
(COMNET).     GICS   is  a   transaction-
oriented batch update computer  system
for  collecting,   editing,   and   storing
information  which  is  relevant to  EPA
grant  programs.   The  system  includes
information   on   grant  re-applications,
including    projects    on    Wastewater
Treatment (WWT), State  Project Priority
Lists;  applications   in  process;   funded
(active) projects; and completed projects
through the time of final audit and close-
out.

     GICS operates on a weekly schedule
in which the transactions that take place
Monday through Friday are collected by
regional, State, and Headquarters'  offices
for entry into  the system during a national
update after 19:30 Eastern time on Friday
night.  The offices (meaning region, State,
and  EPA Headquarters offices)  receive
the results of the Friday  night  update on
Monday morning. If an office has entered
all   of  its   Monday   through   Friday
transactions  and  has  made  no   errors,
weekly management reports can be run on
Monday, however, a clean-up update is run
every  Tuesday  night  to  collect   any
transactions an office has missed and to
allow  correction  of  any errors  which
might have been made on the transactions
processed on  the  Friday night  update.
Offices receive the results from the Tues-
day night update each  Wednesday  morn-
ing.    This semi-weekly update should
assure users a complete  data  base each
Wednesday morning.

     Each  office,  including   regional
offices, the State of California, and Head-
quarters Grants Operations Branch (GOB),
regularly collects transactions  data, such
as award transactions, and enters  them
into  a  "holding" file in the  computer.
Twice weekly, Tuesday and Friday nights,
the  Grants   Information  System   and
Reports  Branch  (GISAR) initiates  the
computer update cycle.  This series of
programs compiles the transaction collec-
tions  and  processes  them  against  the
master file.  In this way  new records are
created and changes and corrections to
existing  records  are  processed.    These
combined records, created and maintained
by the 10 regional offices, California, and
GOB, constitute the total EPA-GICS data
base and reside in  the GICS master file.
The master file,  a  system file, is acces-
sible only to GISAR.  The updated master
file is read to  create  the subordinate data
bases (also referred to as sub-data bases).
Each organization then has a current sub-
data base from which to run outputs, such
as reports  and lists, until the next semi-
weekly update cycle.

      The regions are unique.  They range
in the  grants area  from  Region  V,  a
monster in terms of its volume of activity
and its amount  of dollars, to Region  II
which normally has lots of dollar  activity,
but only  two  states and  Puerto  Rico.
Therefore, they  have a limited volume of
activity.   Region  VIII,  which  has  less
populated areas, has, perhaps, a fair num-
ber of smaller projects, but very few large
projects, fewer universities  and  less re-
search.   Region  III  is  a  region with
additional  grant   related  informational
needs,  that   are  accomodated  with  a
national  system   and  a local  system
                                         E-33

-------
 maintained parallel to the national  sys-
 tem.  As we move along and regions get
 more  ADP  staff,  mini-computers,  and
 more   activities,   as   grants   projects
 increase, we get into a process whereby
 the  region is able to update any day they
 want.  Or, they could update two or three
 times  a day on  a  regional option basis.
 The region could still be maintaining its
 own local data  if  they want different data
 elements, peculiar to their regional needs.
 In the future, perhaps, we will move on if
 it is feasible.  There may be regions with
 mini-computers  that will capture  their
 own data, process it in their  mini-com-
 puter and dump it into the national system
 on a  regular  basis.   Then, rather than
 receiving information from  the national
 update,  the process would  be  reversed.
 Early  next year,  we will  actively discuss
 this.

      We have  had some discussions on the
 interface with various  so-called admini-
 strative systems.  More often than not,  at
 least  in the grants area, administrative
 systems seem  to be in an organizational
 box.  We do have an on-going relationship
 between grants and contracts in  that, on a
 regularly scheduled  basis,   we  do  pull
 together  research  grants  and  contracts
 into a common  listing  made  available
 throughout the Agency in the EPA library
 and  other  users.   We  do have some
 prospective  contracts  information   in
 GIGS.   Along with grant applications, all
 unsolicited proposals are received  in the
 grants administration division and entered
 into GIGS.   Once  the determiniation  is
 made that  an unsolicited proposal is going
 to be routed to contracts as a prospective
 contract, it is dropped and  transferred
 from GIGS, from  the grants process to the
 Contracts  Management  Division.   They
 pick it up in their  system, and  we retire
 the record from GIGS.  We do get a tape
from them on  a  quarterly basis and pro-
duce, for those people interested  in re-
search, a  joint  listing  of  all  research
grants and contracts active at  that time.
We have very little redundancy with the
Financial Management System.  I think we
have three data elements in GIGS which
are also  in  the Financial Management
System.  It has been our practice to avoid
duplication  of the data carred  in  the
Financial Management System.  For that
reason,  we do carry only summary outlay
information, and things of that sort.

     Any  EPA  organization  or   state,
following  initial clearance,  which  has
access to a  terminal or other computer
facility  and  has a  registered  current
account  at  COM NET may run computer
programs and retrieve data from the GIGS
data base.   There are  18  organizations
authorized to  enter  and maintain their
respective  grants data in  GIGS.   These
are:  Region  I through  X, Headquarters
Grants  Operations  Branch (GOB),  ORD-
Project Processing System (PPS),  ORD-
Office  of  Health &  Ecological  Effects
(OHEE), ORD-Office  of  Energy, Minerals
&  Industry (OEMI), ORD-Office of Moni-
toring & Technical Support (OMTS), ORD-
Office  of  Air, Land  & Water (OALW),
California State Water Resources Control
Board, and Grants Information System and
Reports Branch (GISAR). GIGS is also the
host system  for  several other EPA sys-
tems.   As mentioned earlier,  GICS sup-
ports:  The Office of Water and Hazardous
Materials,  Regional  Construction  Grants
Management     Information      System
(RCGMIS),  Water  Quality Management
Information System  (WQMIS),  and Clean
Lakes  Management Information  System,
as  well as  The Office  of Research and
Development's Project Processing System.
GICS   can   be  linked  to  other  EPA
computer systems  that operate  on the
COMNET facility or for which a computer
tape of the data base is available.  Sys-
tems are linked together through  a com-
mon field of  information, such  as zip
codes or grant ID code numbers.
                                          E-34

-------
                                    COMMENTS


Comment:       I would like to mention that, being from a region that has many computer
                capabilities, -we certainly would like to see you keep an open mind about
                the potential for maintaining the regional data base.

Comment:       One comment.  They  will be having an Information Data Management
                Training Course next  week  in  Cincinnati;  then there will  be  training
                courses in Atlanta,  Seattle,  and Chicago.  I am  sure that  you will  be
                welcome.

Comment:       Headquarters needs are not always our needs.  In fact, sometimes they do
                not have anything to do with our needs.  Sometimes we help you and you
                can help us.

                It  has been hard dealing with all the regions and I know you have been
                through a lot of headaches, but,  in the end, it comes out to a much better
                product because it is visible, it does meet our needs.  Along the same
                lines, the other thing to keep in mind is that at the bottom of all of this
                are the people  that input the data.  You say you input data you never
                used, I think that is deplorable.  If the people who input data do not get
                benefits  from  it,  I  do not  see  how  they  are  interested in  its
                correctiveness or use.  It is a bad situation, but I think it is one you have
                to realize exists.
                                         E-35

-------
                             PANEL F: WATER SUPPLY
                                Chairman: Fredrick T. Martin

                                Panelists:  Dan Barber
                                          Bruce Keith
                                          Donald Worley


                                    OVERVIEW


                                 Fredrick T. Martin

      I would like to welcome all of you to the Water Supply Panel of EPA's Second Annual
ADP Conference.  We would like to address that aspect of the Water Supply Program that
deals with the supervision of public water supplies. From an ADP perspective, this means
the  Model State  Information  System  (MSIS)  and its  follow-on  system,  the Federal
Reporting Data System.  Our primary thrust today will be to discuss the decentralized
design of the MSIS system, any unique problems associated with system  implementation,
and ways in which MSIS meets the needs of the States, Regions, and EPA Headquarters.

      I have with me today three pioneers in MSIS development and implementation, each
of whom represents a different perspective.  Dan Barber, the MSIS Coordinator for Region
IV from its Water Division, serves as the interface between the Water Supply and the ADP
Branches in that Region. He represents the regional perspective.  Bruce Keith has a most
unique position  in that he  was the Area Systems Manager for the Southwestern Ohio
Regional Computer Center, better known as SWORCC, which developed the system.  Mr.
Keith had held both technical and managerial positions at SWORCC before coming to EPA
Headquarters, Office of Water  Supply.  He represents Headquarters' perspective on this
system.   Don  Worley, from EPA's Plans,  Analysis, and Research Branch,  National
Computer Center, Research Triangle Park, North  Carolina, will bring to the panel the
Agency perspective.

      We  have three presentations, the  first of which, by Dan Barber, will address "The
Legislative Direction and  Decentralization of the Model State Information System."  He
will  give us  the legislative background of this program,  explain decentralization, and
discuss MSIS installation considerations, as well as  the system preparation and follow-up.
Bruce  Keith, whose presentation  is entitled,  "Meeting  the Requirements of  the Safe
Drinking Water Act and the Needs of the States in EPA," will speak on the Safe Drinking
Water Act, the needs of the States and EPA, and how MSIS meets requirements and needs.
Lastly, Don Worley will present, "The Test and Acceptance of the System to be Delivered
to a User Other Than EPA."

     Before the papers, I would like to give an overview of MSIS, for those of you who are
unfamiliar with the Model  State Information System.

     MSIS, a large-scale  decentralized management information system, is designed  to
assist the States and territories in  meeting their data information handling and  reporting
requirements, mandated by the Safe Drinking Water Act. The system was developed under
contract  by SWORCC  and  delivered to  EPA  in  May  of  this year.   It went through

                                         F-l

-------
 comprehensive 30 to 45-day acceptance test which Don will talk about.  Then we launched
 an intensive installation and training program for the States and regions, all of which will
 be covered in detail today.

      Specifically, MSIS consists of eight primary subsystems whose major functions are as
 follows:

      (1)   The Inventory Subsystem  stores records  of  each  public  water supply and
           contains information such as the name, address, population served, number of
           service connections, source of water, treatment techniques, etc.

      (2)   The Water  Quality Compliance Subsystem,  by  far  the  largest and  most
           comprehensive and complex of  the eight primary  subsystems, determines
           compliance  with  the  regulations.   The system  also  maintains records of
           samples in laboratory  reports and gives  us detailed and summary reports of
           regulation violations.

      (3)   The Regulation Subsystem stores the Federal and/or State regulations that the
           Compliance Subsystem accesses in order to determine compliance.

      (4)   The Federal  Reporting  Subsystem  provides  compliance data  to EPA  in  a
           computer comparable form for the follow-on Federal Reporting Data System.
           This is an annual report required under the Safe Drinking Water Act. Using the
           output of the Federal  Reporting Subsystem of MSIS, a State can fulfill all of
           its annual Federal reporting requirements.

      (5)   The Variances and Exemptions Subsystem maintains  records  of compliance
           schedules, variances,  and exemptions, and produces compliance reports  that
           are appropriately scheduled milestones.

      (6)   The Sanitary Survey Subsystem schedules the periodic sanitary survey based on
           State-defined priority factors, such as the population served.

      (7)   The Enforcement Action Subsystem maintains records of specific enforcement
           actions in order to assist in case-tracking and compliance-monitoring require-
           ments of the  Act.

      (8)   The Operator and Mailing Subsystem  manages data on certified operators and
           produces appropriate mailing lists.

      As  you  can  see,  the  Model  State Information  System  is  a very  complex,
 decentralized, batch-oriented system that meets the annual reporting requirements under
 the Act as well as providing the State with a lot of latitude in  meeting its own needs.
 There are over 50 standard reports available from MSIS,  and  literally hundreds of tailor-
 made reports that are available or possible from this system.

      I  just want  to mention briefly the  implementation  plan,  i.e.,  the training and
 installation program, that the Office of Water  Supply  uses.   The first step is a  Pre-
 Installation Management Conference to make certain that all parties share a mutual set of
 expectations about training, installation, and follow-on services. Then we have week-long,
 formal classroom  training in  each State, where  people are trained in all aspects of the
system.  We  then install the system for  those  States using the computer  on their own


                                          F-2

-------
facilities.  Both the training and installation phases together generally take 12 days.  We
then offer on-the-job training, which consists of four days of additional assistance.  This
allows them to take care of requirements that must be done after installation and training
are completed, but before the system can become truly  operational.  In addition, three
items  are included in our post-installation support  package to a State.  The first is an
actual contract with SWORCC, assistance similar to a year's warranty  on  the system,
which  can  range from a simple phone call about a  question on the documentation to an
actual return visit to the State.  The second item is the MSIS User Support Group, which is
now being formed.  This will serve as an information  gathering and reporting forum, and as
the focal point for all MSIS-related matters, such as the coordination and dissemination of
system updates.  A steering committee has already been formed and a  meeting will be
scheduled shortly.  Finally, we offer a modification contract which addresses two phases;
namely input from the User  Support  Group,  and  any mandated changes that may be
necessary.    Thus,  through  the  Modification Contract,  the   Post-Installation Support
contracts and our User Support Group, we have a package of support  to keep the system
afloat after the SWORCC teams leave the States.

      We have been involved in 15 States and, six States  have  actually signed off.  These
are Oklahoma, Kentucky, Illinois,  Minnesota, New Mexico, and  Alabama.  Some  34 States
are expected to take MSIS, and I expect installation and training to be completed by April
or May of next year.

      Let us now turn to the presentations.
                                          F-3

-------
                              PANELIST STATEMENTS

                              Legislative Direction and
                Decentralization of the Model State Information System

                                     Dan Barber
 Introduction

      The Model State Information System
 (MSIS) was developed by the Southwestern
 Ohio    Regional     Computer    Center
 (SWORCC)  under  contract  to the  Office
 of Water Supply (OWS) at  Environmental
 Protection Agency (EPA) Headquarters in
 Washington,  D.C.    It  is  a  tool  to be
 utilized by  the States in  support  of  the
 requirements of the  Safe Drinking Water
 Act (PL 93-523) of 1974. The system was
 designed under a  decentralized concept
 and will be  operated by most  States on
 their own computer systems.  (Two States
 will utilize  WCC.)  The legislative man-
 date for the Drinking Water Program is
 Public   Law  93-523  which  specifically
 emphasizes  the role  of the  States.   In
 addition, the general  thrust of the Agency
 is to encourage more State involvement.
 Therefore,  the  decision  to   provide a
 decentralized  system  was  based  on a
 desire to insure the autonomous operation
 of each State program.  A decentralized
 data management  system would, in effect,
 assure each  State  more complete control
 of all aspects of their own program.

      This paper will  discuss  the legisla-
 tive background of  EPA/State  relation-
 ships regarding EPA program activities in
 general.  It  will   then  discuss   the Safe
 Drinking  Water Program  and show  that
 the  decentralized  concept for MSIS is in
 agreement with the mandates of the Safe
 Drinking Water Act,  as well  as  with  the
 spirit of other EPA Water  Program legi-
 slation.  Once the legislative background
 for  decentralization  is established,  the
 concept is discussed briefly in comparison
 with centralization.  In conclusion, some
 difficulties experienced in the installation
process for   MSIS  are  discussed and  the
 methods used to  deal with  them  are
explained.
EPA/State Agency Relationships

Legislative Background

     It has been the policy of the Federal
Government to involve the States in pol-
lution  abatement  activities  as much as
possible.  A  basic requirement has been
that the State  regulations controlling the
affected activity  must  be  at least as
stringent as the Federal regulations. This
is true of the delegation  of  the National
Permit   Discharge  Elimination   System
(NPDES),  as well  as the  assumption of
primacy  by  the States  under PL  93-523.
However,  the  importance   of    State
involvement  in Federal  water pollution
abatement  activities  is  obvious  from
existing laws and regulations. It is on this
premise that the decision to decentralize
MSIS  was  based.    The  following is  a
discussion of some Federal programs and
the legislative emphasis for State involve-
ment in each program.  It concludes with
a discussion  of the  Safe Drinking Water
Act.

Water Quality Surveillance System

     In order to develop a  data  base of
essential  water   quality  data  and  to
provide  for  continuing  surveillance of
water  quality  in order to  detect  water
pollution as  it develops, the Administrator
of EPA is  required  to  establish national
programs  to  control  water  pollution.
Under  Section  104(a)(5) of PL 92-500 the
Administrator is required to:

-------
     "...establish national programs
     for the prevention, reduction,
     and  elimination  of pollution
     and  as part  of  such programs
     shall—in cooperation with the
     States...equip and maintain a
     water quality surveillance sys-
     tem for the purpose of moni-
     toring the quality of navigable
     waters and ground waters..."

     The establishment and maintenance
of these programs is generally funded in
part through a State Program Grant pro-
vided to the States under Section 106 of
PL 92-500.  In addition, Attachment A to
the Section 106 Regulations  requires that
the water quality data collected under the
requirements of Section 104  of PL 92-500
be  provided to  EPA  in a manner agreed
upon between the  Regional Administrator
and the  State Director.   The  FY  76
Regional  Guidance  required  that  data
handling agreements be  established bet-
ween EPA and  the States to accomplish
the data transfer.  For  most  of the States
in  Region  IV,  Water  Quality  Data  is
entered  directly  into  STORET  by  the
State.   This fulfills  the requirement  to
transfer the data to EPA. STORET is an
example of a centralized Environmental
Protection Agency ADP  System  used  by
the States.

Construction Grants

     The  Municipal  Wastewater  Treat-
ment Works Construction Grants Program
is  by  far  the Agency's largest  grant
program.   It  encompasses all phases  of
wastewater treatment  works design and
construction, from the planning and design
of the facility through  the completion of
construction.  The total  amount  of  pro-
gram funds disbursed to local governments
nationally  in  FY  77 was approximately
$2.7 billion.  In addition, approximately
$6.7 billion  was obligated for future pro-
jects.  Some facets  of the  Construction
Grants Program have been  delegated  to
State agencies  for  several  years.   The
legislative justification for this delegation
is  contained in the Construction  Grant
Regulation,  40 CFR Part 35.912,  which
states in part:

     "...optimum use will be made
     of available State and Federal
     resources to eliminate unnec-
     essary  duplicative  reviews of
     documents required in proces-
     sing  of  construction  grants
     awards. Accordingly, the Re-
     gional   Administrator   may
     enter  into  a  written  agree-
     ment,  where appropriate, with
     a  State agency  to  authorize
     certification  by   the  State
     agency of technical and/or ad-
     ministrative adequacy of spe-
     cifically required documents."

     In the past, this has referred pri-
marily  to  the review  of  the technical
aspects of the so-called Step 2 grants, the
Plans  and   Specifications  Review,  any
changes requiring additional commitment
of Federal funds, and the technical review
of the Operations and Maintenance Man-
ual  required for each  plant  constructed
under the  program.  For the  most part,
the State role in  the Step  1 grant process
(the planning of the project under Section
201  of the Act) and the Step 3 grant (the
physical construction)  has been limited.
However, Region IX  has delegated the
entire program to the State of California
with the Region  involved  only where the
Regulations  required,   or for  program
monitoring.  In addition, proposed legisla-
tion currently before Congress (HR 3199)
would provide for much  more State in-
volvement  in  the  Construction  Grants
Program through the amendment of PL
92-500  to  include a section 214 entitled
"Certification".   The  so-called  "Cleve-
land-Write Amendment" reads in part:
                                          F-5

-------
     "The  Administrator may carry
     out any  of  his responsibilities
     for actions, determinations or
     approvals    under    sections
     201(g)(2) and (3)...with respect
     to   projects...for  treatment
     works by accepting a certifi-
     cation  by  the  State  water
     pollution control agency of its
     performance of such  responsi-
     bilities."

     This  will provide for the  eventual
delegation  of  most  aspects of  the Con-
struction Grants  Program  to  the States.
The result  will likely increase the  neces-
sity  for EPA  to  work  together  with the
State agencies in order to insure that the
goals of the Act are  met.

     The  data management system used
to support the Construction Grants Pro-
gram is  the Grants Information Control
System (GICS). It is a centralized system
used  only  by EPA  and  the  State   of
California.  As the  States  become more
involved  in the program, the  problem  of
an ADP System to be used by the  States
will have  to be addressed.   Current plans
call  for  the  delegation to include the
operation and maintenance of GICS.

The Safe Drinking Water Act—State Role

     The  Safe Drinking Water  Act (PL
93-523) is  not  unlike other  legislation
governing EPA activities and responsibili-
ties  in the area  of EPA/State  relation-
ships.   It  specifically gives  the  States
primary  enforcement  responsibility for
public  water systems  if the State  meets
certain conditions.  Section 1413(a) states
in part:

     "...a  State  has   primary  en-
     forcement  responsibility   for
     public water  systems during
     any period  for which  the  Ad-
     ministrator   determines...that
     such State (meets primacy  re-
     quirements)."
     The National Safe  Drinking  Water
Strategy is more explicit  in its outline of
the State role in carrying  out the require-
ments necessary to meet  the goals  of the
law. The following statements is found in
the Executive Summary-Strategy  Over-
view Section:

     "EPA  desires  to certify  all
     States  for  primary enforce-
     ment responsibilities..."

The Program  Statement  In  Chapter  II
reads:

     "(PL  93-523) requires the Ad-
     ministrator to encourage max-
     imum (emphasis  added)  levels
     of  State involvement  in the
     promulgation, implementation,
     and  enforcement of regula-
     tions and programs  developed
     under this Act."

In addition, the Program Statement of the
Strategy states:

     "The  State  governments,  to
     the maximum  extent feasible
     (emphasis added), are responsi-
     ble for  supervising  the  public
     water systems,  implementing
     the provisions  of the National
     Primary Drinking Water Regu-
     lations..."

In Chapter HI, the Strategy lists as one of
the program objectives:

     "To insure an effective Fed-
     eral-State partnership (empha-
     sis added) in the implementa-
     tion of the Act."

And finally the Strategy indicates that:

     "EPA  is  working   with  the
     States   to  develop workable
     ADP Systems."
                                          F-6

-------
Summary
     It is  clear that the law, as well  as
the program strategy, strongly emphasize
State involvement  in the Drinking Water
Program.  In fact, the basic thrust of the
Act, regulations, and drinking water stra-
tegy are to provide primary authority  to
the States  to oversee the accomplishment
of the legislative goals.   This  is in line
with other  major agency programs such as
water  pollution abatement and  construc-
tion grants. The most current legislative
changes  proposed  for  the Construction
Grants Program will increase the involve-
ment of many  States in that program.

     The MSIS was  developed  primarily
for State use because of the clear legisla-
tive mandate  for  State involvement  as
well as the obvious  need  for data manage-
ment.   The sheer  volume of monitoring
data alone is  staggering.  When this  is
combined  with the  complexity  of the
regulations  regarding compliance  (espe-
cially when violations occur), the need for
a comprehensive data management system
becomes evident.   A system  was  also
necessary  to  meet  the  annual  reporting
requirement (Section  1450(h) of  PL 93-
523) to Congress. Since heavy emphasis is
placed on the State role, it was felt that
an ADP System should be developed that
could be specifically responsive to  State
data management requirements,  as well as
provide for automated input to the annual
report  to Congress.  The determination  to
decentralize the system  was the result  of
a desire to provide for,  as completely  as
possible, the   autonomy  of each  State
program  and   encourage  the   State  to
accept primacy.

Decentralization—What It Means

     Just as systems  designed  under the
centralized concept have certain limita-
tions which inhibit  State  use,  the  MSIS
designed under the  decentralized concept
has, by necessity, aspects which limit its
flexibility.  For instance, MSIS  was  writ-
ten to  be machine  independent  so that it
could be installed on various State com-
puters.  The nine subsystems are indepen-
dent modules with little direct interface
except through  the use of tables contain-
ing common information.   Of  the  nine
subsystems, five are required  for  system
operation.    The  remaining  four   are
optional  although  some  elements   are
required  for the annual  Federal  Report.
Processing    cost   of   MSIS   is   the
responsibility of each  State  and is  an
allowable item  to be charged against the
Federal  grant  to support Water  Supply
Program activity.  If desired, MSIS can be
installed at  WCC for State  use.   Two
States will use  the COMNET facility and
pay for their usage through an Interagency
Agreement with EPA. The funds to cover
this  usage  may also come from  Federal
grant funds.

      MSIS   is  a  batch,  after-the-fact
system  primarily designed  to  aid  the
States in record keeping,  and projecting
and  monitoring the  complex compliance
schedule information based on a  routine
sampling program required by the  regula-
tions.   One  of its major  purposes  is to
automate the Federal reporting process.
Once a year, tape output from MSIS will
be used as  input to the Federal Reporting
System which will then  process the  data
into  the  proper format for the Report to
Congress.

      Another    well-known     system,
STORET,  was  developed   from   the
centralized concept and is  different in
many ways from MSIS. These differences
are the heart of the centralized/decentra-
lized issue.  The STORET Water  Quality
File  contains water quality data collected
from the Water Quality  Surveillance Sys-
tem  of the States. It is  the largest water
quality data base in  the  country and also
contains data collected by EPA and other
Federal  agencies  including U.S.G.S:  In
Region IV,  it is used as the mechanism for
the  required   surveillance  system  data
transfer   from  the  States  to   EPA.
                                          F-7

-------
STORE! is IBM dependent and located at
WCC.  It is accessed through RJE and low
speed  terminals  throughout the country
and  operates similar  to  an interactive
system with  powerful  and comprehensive
retrieval  capabilities.    State  usage  is
funded  through  the   EPA  ADP  Sub-
allowance  in  the  amount  of  $600,000
annually.    This  essentially  provides  a
dependable ADP System,  cost free  to the
States. The benefit is that the States are
encouraged to use STORET to store their
Water Quality data and in so doing, aid in
the  establishing   of   a   comprehensive
national data base of  water quality data.
Since  the amount  of  funds available to
support  State   usage   is  limited,   some
States   have   established   Interagency
Agreements to cover any  additional usage
above   their   ceiling   amount.    This
mechanism will also be used to fund State
use of the WCC facility  for the MSIS  in
the two States  whose  systems will be at
COMNET.

     The advantages   of  a  centralized
system  over  a  decentralized  system
include:

     o   Operational flexibility

     o   Ease of maintenance of sup-
          port (sophisticated ADP exper-
          tise not required in State)

     o   Reduce installation cost

     o   EPA access to data base.

     However,  the   above  advantages
must  be balanced against advantages of
decentralization which include:

     o   Complete   system control  by
          State

     o   Encouragement of States' pro-
          gram independence

     o    Freedom from effects of EPA
          policy changes
     o     Inability  of  some  States to
           utilize computer facilities out-
           side of State government.

     Any decentralized  system,  the  size
of complexity of MSIS, is costly  to make
operational  since  the system  must be
installed  independently  in  each  State.
However, the long-term  advantages can
outweigh the disadvantages.  This will, in
the end, depend on the  applicability of
MSIS to each State program, the ability of
OWS to provide adequate system support
to the States, and the overall effective-
ness of the system to meet the  require-
ments for which it was designed.   We are
now in the installation  phase, and have
encountered various situations which have
required a great deal of creative throught,
diplomacy, and ingenuity.  The following
section outlines some  problems that can
occur.

MSIS Installation

Considerations

     MSIS  is  a complex  system being
installed in 35 States by the Southwestern
Ohio Regional Computer Center.  There is
a  deadline  for  installation  since  the
system should be installed and operational
in time  for the 1978 annual report to
Congress.  Some difficulties have resulted
from  the necessarily  tight schedule and
EPA contractor personnel  working within
the State bureaucratic structure.   In some
instances,  State organizational structure
has  caused  unexpected  delays.    The
following is a summary of some considera-
tion linked  to  the installation  of  any
decentralized system:

     o     Tight installation schedule can
           produce a  domino effect  if
           installation  drags on in one
           State.
                                          F-8

-------
     o    Various  facilities  have  dif-
          ferent  text  editors,   system
          procedures,  levels  of  com-
          pilers, operating systems, etc.

     o    Many  States have  the ADP
          function  consolidated  in  one
          area  while program functions
          are completely removed. Con-
          flicts  and  misunderstandings
          can develop (or exist  already)
          between the two groups.

     o    Many  State programs have
          little exposure to ADP and do
          not understand the impact of a
          large data system.

     o    When a program element, such
          as Drinking Water, attempts to
          hire ADP personnel for MSIS,
          conflicts can develop  between
          the  program and ADP func-
          tions over that position.

     o    Organization  and  personnel
          shifts within a State can cause
          problems.

     o    Internal   State   politics   on
          State/EPA political situations
          can affect system installation.
          Because of this, it is impera-
          tive  that  the Region be very
          much involved in the process.

Installation Preparation and Follow-Up

     In an attempt to minimize  the  po-
tential for  these situations to  develop,
several steps  have been taken  to insure
that proper  coordination has taken place
with representatives from the Water Sup-
ply and Data Processing functions.  This
involves the completion of various forms
and checklists and  face-to-face meetings
between  the State, EPA,  and  SWORCC.
The preparation  can be broken  into three
distinct areas.

Background Information Packages (BIP)

     The  purpose  of.  the  BIP's  was  to
gather basic information about the State
Water  Supply  and  ADP personnel  and
facilities. They identify the State coordi-
nators  and provide information about the
computer  facilities,  including  type  of
computer, configuration, terminal access,
etc.  The information was gathered for all
States  accepting MSIS  in meetings bet-
ween Regional  Water  Supply  and  ADP
personnel and  their  State  counterparts
approximately one year ago.  This  infor-
mation was compiled by SWORCC and the
national    installation   strategy    was
developed from them.

Checklists

     In the BIP Meetings, the basic infor-
mation is gathered through the use of two
checklists, one for the ADP and one for
the Water Supply  Program.   In addition,
the States are asked to complete another
checklist, called "State Checklist of MSIS
Training and Installation Requirements",
shortly before the installation is scheduled
to begin.  This checklist provides updates
to the earlier ADP  Checklist as well as
more specific information about the train-
ing facilities. The final checklist is  called
"Management Checklist for  Implementing
MSIS in States after Installation",  and
contains information and instructions to
facilitate the development of  State MSIS
usage once the system is installed.

Pre-Installation Management Conference

     The  Pre-Installation  Management
Conference  is scheduled  approximately
two weeks before the Water Training is to
begin.  It generally consists of representa-
tives of  the State ADP and Water Supply
functions; EPA Regional ADP and  Water
Supply    personnel;   the    contractor,
SWORCC; and Tom Martin from Office of
Water   Supply,  Headquarters.    In  this
meeting, a quick overview of MSIS and its
current status is provided, the completed
Checklist for MSIS Training and Installa-
tion   Requirements   is   reviewed   by
SWORCC,  and any State questions are
answered.  The training and  installation
schedule is reviewed  and  an attempt  is
made  to coordinate  management  level
people  who   will  be  involved in  the
installation.
                                          F-9

-------
      Once the  system is  installed, addi-
 tional and follow-up actions  are planned
 to  help  the State develop its usage  and
 solve any difficulties they  may encounter.
 These actions include:

 Post-Installation Training

      After the  MSIS has  been  installed,
 the State  may request up  to four days of
 additional on-site, user-oriented training.
 The training is provided by SWORCC  and
 allows State Water Supply personnel to
 resolve any  difficulties experienced with
 MSIS usage.

 User Support Group

      OWS  is  now  establishing a  user
 support group.  It will consist  of represen-
 tatives from EPA Headquarters, Regions,
 and the States.  Its  purpose  is to gather
 and disseminate  information concerning
 the implementation and usage of MSIS. It
 will essentially  be the focal  point for all
 MSIS  related activities.   In addition,  a
 user support group  will  be  provided by
 SWORCC  for  technical  support to  the
 States and Regions as needed.

      It  would   appear that  the  above
 coordination efforts would be  sufficient to
 insure  that  State  personnel  were ade-
 quately  prepared for  the  installation.
 This, however, is not always the case. In
 one State, the ADP coordinator  for envi-
 ronmental programs who had the responsi-
 bility for the MSIS installation left his job
 after  the  BIP   meeting.   When  the Pre-
 Installation Management Conference  was
 held, his replacement attended the meet-
 ing as well as a representative  from  the
 State  Computer Center (SCC).   By  the
 time SWORCC   arrived for  installation,
 the  new  coordinator  had left  and  no
 replacement had  been named.   The SCC
 was  apparently  not  aware  that  the
 installation was  to  take  place since  the
 SCC representative who attended the Pre-
 Installation Management Conference  had
 also changed jobs and apparently told no
one about  the installation.  As a result of
the   musical  chairs  in  positions,   a
requirement had been established that the
Commissioner's  signature  was necessary
to accomplish even routine tasks such as
the  reservation  of  disk  space.    This,
needless to say, added to the confusion.

     The   above  may  be  an  extreme
example, but there will certainly be other
complications, usually unexpected, which
continue to occur in other areas of the
installation  process.    One  of the  best
evaluations of MSIS installation was given
by Region IV's ADP Management Branch
Chief, Curt Lackey, in one of his monthly
reports. In discussing the problems exper-
ienced in one of our States, he offered the
following  comments  concerning  lessons
learned:

     o     Take  minutes of  the  Pre-In-
           stallation  Management  Con-
           ference.

     o     Send copies to all participants.

     o     Ask the State to follow up one
           week  before installation  with
           calls to all participants.

     o     Assume Murphy's Law will pre-
           vail.

     There is little  doubt as to which of
the four is most appropriate.
                                          F-10

-------
               Meeting the Requirements of the Safe Drinking Water Act
                                        and
                           The Needs of the States and EPA
                                   Bruce O. Keith
Introduction
     The Safe  Drinking  Water  Act  of
1974 greatly expanded the U.S.  Environ-
mental  Protection Agency's responsibili-
ties  in  insuring  the quality  of  drinking
water in  the United States.   Under  the
authority invested in EPA by the Act, a
set  of  drinking  water regulations  was
established   to  facilitate  meeting   the
intent of  the new law.  Since the legisla-
tive  desire is to increase the role of  the
States   in the  enforcement  of  Federal
programs, we  can  understand  how  the
duties  and responsibilities  of  the States
have been, likewise,  greatly expanded.

     The  remainder  of  this report  is
intended to accomplish two major goals.
First, the major  provisions of  the Safe
Drinking Water  Act  are briefly discussed.
The  water systems which are covered, as
well as  the monitoring  and  reporting
requirements as  established  under  the
National Interim Primary Drinking Water
Regulations,  will clearly demonstrate  the
scope of  responsibility  placed  upon  the
States which assume primary enforcement
responsibility (primacy), or upon EPA in
situations where a State does not assume
primacy.  Secondly, in consideration  for
the  additional burdens  placed  upon  the
States  and EPA,  the  development  of a
computerized State information  system,
the  Model  State  Information  System
(MSIS), and a Federal information system,
the  Federal Reporting  Data   System
(FRDS),  are  discussed  insofar  as  they
relate   to the   manner   in  which   the
additional  burdens  are  reduced by a
mechanized approach.  Emphasis  is placed
on state-of-the-art techniques utilized in
the design and programing of  the Model
State Information System  as they relate
to the system's  implementation on a  de-
centralized basis.
The Safe Drinking Water Act of 1974

   On December  16, 1974,  the  Public
Health Service Act was  amended  by the
Safe Drinking Water  Act (PL 93-523) to
assure that the public  is  provided  with
safe drinking water.  The  Act gave  EPA
the  responsibility  of  setting  minimal
national  standards  for  all public water
systems  in  the  United  States.    The
regulations  are of  two  distinct  types;
Primary  regulations  which are aimed  at
protecting public health and take cost into
consideration, and secondary regulations,
designed to protect public welfare.

   In the case of the  primary regulations,
maximum allowable  limits  of  permitted
contamination  in  drinking  water   are
established, as well  as  the frequency at
which water samples  are to be taken and
analyzed. The States are to take the lead
role in enforcing these regulations. In the
case   of  the  secondary  regulations,
maximum  allowable  contaminant levels
and monitoring frequencies are also estab-
lished.   However, these regulations are
not enforceable from  a Federal viewpoint
and  will  only be   enforced  when  an
individual State chooses to do so.

Provisions of the Act

   Some of  the major  provisions  of the
Safe Drinking Water  Act of 1974 are as
follows:

   o     Establishment  of  primary  regu-
         lations for the protection of the
         public health;   National Interim
         Primary Drinking Water Regula-
         tions, promulgated on December
         24,  1975, and  on July 9,  1976,
         became  effective on  June 24,
         1977;
                                           F-ll

-------
           Establishment of secondary re-
           gulations which relate  to  the
           taste,  odor,  and general  ap-
           pearance  of drinking  water;
           proposed  secondary   regula-
           tions, published in the Federal
           Register on  March  31, 1977,
           are intended as guidelines only
           for States that choose  to  en-
           force the secondary standards;

           Measures are to be established
           to protect underground drink-
           ing water sources;

           Research  is  to be conducted
           which relates to health,  econo-
           mic,  and  technological  pro-
           blems  of  drinking water  sup-
           plies;
           Technical  aid,  training,  and
           grant support is to be given to
           the  States  to improve •tu~:-
           drinking water program;
their
      o    Citizen  suits  are  permitted
           against any party in violation
           of  the  requirements of  the
           Act; and

      o    Variances and exemptions may
           be  granted from a required
           contaminant level,  or treat-
           ment process established under
           the regulations, but  only when
           it  can  be demonstrated  that
           there  is not an unreasonable
           risk to the public health.

Water Supplies Covered

      A public water system is defined as
a  water  system   which   provides  piped
water for  human  consumption to  the
public, if such a  system  has at least  15
service connections or regularly serves at
least 25 persons on a daily basis at least
60 days out of the year. The definition of
a  public  water   system  includes  the
following:
   o     Collection, treatment,  storage,
         and distribution facilities which
         are under the control  of  an
         operator   and   which  are used
         primarily in connection with  the
         water system; and

   o     Collection   and  pre-treatment
         storage facilities which are  not
         under  operator control, but  are
         used primarily in connection with
         the water system.

   A   public  water system  is  further
classfied  as being  a community  water
system or a non-community water system.
If  the public water system  serves year-
round  residents,  it  is  identified  as a
community  water  system.   Any  public
water  system which is not a community
water  system  is   identified  as a non-
community water system.

   Quantifying this structure of classifi-
cation clearly demonstrates the extent to
which the regulations apply.  In considera-
tion thereof, the following represents  the
best  estimates of  the  public  water sys-
tems  covered  by  the  National Interim
Primary Drinking Water regulations:

   o     Total   public  water  systems
         (PWS's) covered - 250,000

   o     Community PWS's — 50,000

   o     Non-community PWS's ~ 200,000

   Of the 250,000  PWS's estimated to be
covered  by  the  regulations,  35,500 of
them  serve  85 percent of the nation's
population, and 222,500  serve  15 percent
of the nation's population.  Furthermore,
as near as can  be  determined, 50 percent
of the  nation's population is served by
public water systems which obtain their
water  in  whole or in part from  surface
water sources (e.g., lakes, streams, etc.).
The impact of this factor will  be more
clearly  understood  when the  monitoring
                                         F-12

-------
requirements contained within the follow-
ing section of this report are examined.

Monitoring Requirements

      The  monitoring  and  analytical  re-
quirements, as set forth in the National
Interim Primary Drinking Water  Regula-
tions, are applied to public  water  systems
in a manner which is dependent upon  one
of four classifications.  These classifica-
tions are based upon whether the PWS is
community  or    non-community,    and
whether the PWS obtains its water from
surface or ground sources.

      The  regulations require  monitoring
of six groupings  of contaminants; namely
microbiological,    physical,    inorganic
chemicals, organic chemicals,  man-made
radionuclides  (gross   beta and  photon
radioactivity);   and   naturally   ocurring
radionuclides (RA-226, RA-228, and gross
alpha radioactivity).    However,  which
PWS's must be monitored for the contami-
nant groupings depend upon the classifica-
 tion  of public  water systems.  To under-
 stand the overall impact of the monitoring
 requirements,  table  F-l is presented for
 review.  After reviewing the table, we can
 see  that  the  community   PWS's  are
 required  to perform the majority of the
 sampling and analysis,  and even more so
 when the  community  PWS  obtains  its
 water in whole or in part  from a surface
 water source.   The  largest responsibility
 lies  with  the  analyses of  samples for
 microbiological  and   physical  types of
 contamination;  however,   analyses  for
 inorganic  chemicals   (arsenic,  barium,
 cadmium,   chromium,  lead,    mercury,
 selenium,  silver,  and  flouride), organic
 chemicals (endrin, lindane, methoxychlor,
 toxaphene,  2-4-D,  and 2,4,5-TP),  man-
 made radionuclides (primarily gross beta,
 SR-90,  H-3,  and   1-131), and  natural
 occuring  radionuclides (gross alpha, Ra-
 226, and RA-228), although required to be
 performed less frequently,  are  just as
 important as the other analyses.
Federal Reporting Requirements

   The National Interim Primary Drinking
Water  Regulations set forth the following
Federal reporting requirements:

   Each   state   maintaining   primary
enforcement responsibility shall submit to
the administrator...

     1.  Additions or corrections to the
         State's inventory of public water
         systems;

     2.  A  summary of  violations which
         occurred during  the  reporting
         period;

     3.  A  summary  of  variances  and
         exemptions which were in effect
         during the reporting period; and

     4.  A   summary   of  enforcement
         actions  undertaken  during the
         reporting period.

 Items  one through four  must  be reported
 to  EPA on or before January 1 of each
 year,  and  cover  the   previous  Federal
 fiscal  year,  October  1st   to  September
 30th.   Additionally, the State must give
 prompt  notification to  the administrator
 of any variance or exemption granted.

 Needs of the States and EPA

    It  has been the intent  of the previous
 section  of  this report  to  exemplify  the
 extent  to  which the  responsibilities  of
 EPA and the States have been expanded
 by the requirements of  the Safe Drinking
 Water Act.  Since Congress intended the
 State   to  play  the major role  in  the
 regulations   enforcement,   they   are
 impacted the most.  It is important to
 remember, however, that in cases where a
 State  does not assume primary enforce-
 ment  responsibility, EPA acts in the role
 of the State.  EPA is additionally charged
 with   the   ultimate   responsibility   of
                                          F-13

-------
 safeguarding the drinking water quality of
 the nation and annually reporting to Con-
 gress on implementation effectiveness.

      The  States,  under  their expanded
 responsibilities, clearly needed a  method
 by which the mass of information required
 to be collected and  reported could  be
 effectively managed.   Also, for them  to
 monitor  successfully  the   quality   of
 drinking   water   in   their   State,  a
 mechanism had to  exist to  keep track  of
 whether the water systems in  their State
 were performing the required analysis, for
 the required  contaminants,   within the
 regulated period of time.

      EPA needs to manage the tremen-
 dous  flow of  information in cases where
 they  assume  the  primary  enforcement
 role,  as well as accumulate the informa-
 tion reported  under  the  auspices  of the
 Federal  requirements.  As has been the
 case  with  EPA's National Inventory  of
 Public Water Systems, frequent requests
 are received from  independent organiza-
 tions for information.  With this factor in
 mind,  it is apparent  that future requests
 will be greatly expanded by the additional
 data  that EPA will  have available as a
 result of the new  Federal  reporting  re-
 quirements.  These independent requests,
 as well as the internal research needs  of
 EPA, place an overall expanded responsi-
 bility on the Agency alone.  But, it  cannot
 be disputed that EPA's major need still
 lies in  the  ability  to produce  the  annual
 report   to  Congress   more  easily  and
 accurately.

 How  the Requirements and Needs Were
 Met

      EPA's  Office  of Drinking  Water
 (ODW) was made responsible  for  imple-
 menting the provisions  of the Safe Drink-
 ing Water Act.  In this  capacity, ODW
 acquired  contractual  assistance   from
 American Management Systems, Inc.,  to
 study  the  program  requirements,  con-
cepts, and plans for the successful  imple-
mentation  of  the  Safe  Drinking  Water
Act.   The  remainder  of  this  section
discusses  the steps  which  were  taken
subsequent to this initial contractual task.

Model State Information System

Developmental History

     The   initial   task   performed   by
American   Management   Systems,  Inc.,
establishes that a capability by which the
States  and EPA could fulfill  their basic
responsibilities was  openly evident.   In
response to this finding, ODW entered into
a second contract with American Manage-
ment Systems Inc., to study the feasibility
of developing a computer-based system.
This effort resulted  in the concept for a
model  of  a computerized state informa-
tion system, or as we now know  it,  the
Model State Information System.  The key
recommendation made was to develop a
decentralized  computer system. Overall,
the effort resulted in the general systems
design of MSIS.

     ODW continued in their endeavor by
concluding    that    the    decentralized
approach  was, indeed, most in line with
Congressional intent, and computerization
would provide significant  benefits. ODW
then entered  into a series of contracts
with the University of Cincinnati's South-
western Ohio  Regional Computer Center,
which subsequently performed the initial
methodology  planning  utilized   in  the
detailed  systems  design,  programming,
testing,  and  documentation  of  MSIS;
implemented that plan; developed a plan
involving  State  and  EPA  regional needs
for  installation  aid  and  training,  and
actually developed the training programs.

     The   Southwestern  Ohio Regional
Computer Center (SWORCC) continues to
play an important role in the implementa-
tion of  the  Model  State  Information
Systems through contractual  support to
EPA in the following ways:

     o     Training  in the  areas of MSIS
           operation  and  functions  for
           State  and EPA regional  per-
           sonnel  in classroom  and  on-
           the-job environments;
                                           F-lf

-------
     o     Installation of  MSIS on  com-
           puter  facilities of the State's
           choice;

     o     Post-installation  and  system
           maintenance  support  to the
           States and EPA.

     In order to  grasp the size and com-
plexity of MSIS, the following MSIS statis-
tics are presented:
     o«
9 Subsystems

73 ANS COBOL Programs

200,000 Lines of Source Pro-
gram Code (approximate)
           32   Catalogued
           (Run Streams)
                   Procedures
     o     70 Input Forms

     o     78 Output Reports Available

     o     12 Volumes of Documentation
           contained  with   28  physical
           binders  and consisting of ap-
           proximately 8,600 pages

Major Functions Provided

     While the Model  State Information
System  is  designed  primarily  for  those
States   that  do  not  currently have an
automated  system   for  managing  the
increased  volume of water quality and
related data, it is also designed to provide
enhanced capabilities to those States that
do have an  automated system.  States
choosing to install the  MSIS are required
to implement five of the nine subsystems.
The  remaining  four subsystems  provide
features which  are optional for State and
EPA regional  use,  depending  upon the
volume of data  and individual preferences.
Overall,  MSIS   possesses  the  following
major features:

     o     Maintains records of each pub-
           lic   water  system  in   the
           State/region;
Maintains records on certified
laboratories,   samples   taken,
and  sample  analysis  results,
and provides detail and sum-
mary reports on violations;

Facilitates scheduling of water
quality sampling and analysis;

Maintains records of State and
Federal regulations;

Facilitates submission  of Fed-
eral reporting requirements to
EPA in a format suitable for
direct   entry  into    Federal
Reporting Data System;

Maintains     records      of
compliance   schedules   esta-
blished  via  variance and ex-
emption procedures;

Maintains records  of specific
enforcement  actions to assist
in case   tracking and  com-
pliance monitoring;
                                            Facilitates    scheduling
                                            sanitary surveys; and
                          of
                                       o     Maintains records on certified
                                             public water system operators
                                             and other target  populations
                                             for communication.

                                  Impact  of  a Decentralized Approach  on
                                  System Design and Programing

                                       Many  factors  must  be  taken into
                                  consideration  before  a decision can  be
                                  reached regarding the use  of a computer
                                  system on a centralized or decentralized
                                  basis.   The  development  of  the Model
                                  State Information System is an  excellent
                                  example of  how a  system  design and
                                  programming effort  can  be impacted  by
                                  the decision to develop  a decentralized
                                  system.   However,  it  is important  to
                                  realize  that  the extent  to  which  the
                                  development  efforts  are  impacted  is
                                  largely  dependent on who the users are.
                                  For example,  if  a computerized payroll
                                          F-15

-------
 system was being developed for use by an
 individual State on a decentralized basis,
 the design and programming would not be
 necessarily impacted  to a  great  extent
 since  the payroll procedures  would  be
 basically the same regardless of where the
 system was installed.  On the other hand,
 development  of  a computerized  payroll
 system for use by all the States would be
 extremely   difficult,   if   not   totally
 impossible, due to the variations in orga-
 nizations, procedures, etc.

      Since MSIS  was designed  primarily
 for use by a large number of independent
 organizations, i.e., the States, it was
 immediately clear that  the  system could
 not necessarily meet or  satisfy all  the
 specific desires of each and every user.
 However,  the States did share a common
 responsibility for  enforcing the quality of
 drinking  water.   It was this factor that
 served as a determining  characteristic for
 the ultimate  design of MSIS.  To address
 further the unique requirements of indivi-
 dual users, MSIS was developed to present
 some- degree of variability in an extremely
 modular fashion.  By so  doing, the flexibi-
 lity existed  for  enhancing or  adapting
 MSIS  functions for any State's specific
 needs.  Also, since the available computer
 hardware  and  software  differed  from
 State to State, MSIS was developed to be
 machine  independent.   This,  of course,
 implied that a number of design alterna-
 tives,  as well as some programming tech-
 niques,  had  to   be    eliminated  from
 consideration during the initial phases of
 the development effort.  Because  of this
 restriction,   for   example,  MSIS  was
 designed  to  be a sequentially  oriented,
 batch-computer   system  which  makes
 extensive  use  of run-time parameters
 through control cards.   Although sequen-
 tially  oriented  batch  computer systems
 are commonplace, no   other alternative
 could  really  be  considered  because  the
 system was to be installed on a variety of
 computer mainframes. Other alternatives
 which  may have proven to be feasible and
 possibly    more   efficient,    rely    on
 capabilities which are  not consistently
implemented on all computer mainframes.
 Therefore,   these   alternatives   were
 avoided.

      Although certain  design  approaches
 were mandated by the  intended usage of
 MSIS on a decentralized basis, the system
'was designed and implemented using  the
 most current state-of-the-art technology.
 Specifically,  the  following  techniques
 were utilized throughout the development
 effort:

      o    Hierarchy    plus    input/pro-
           cess/output diagrams

      o    Top-down structured program-
           ming in ANS COBOL

      o    Chief programmer teams

      o    Development support library

      o    Structured  walkthroughs   of
           design and programming.

 The specific benefits of  each technique
 are  too  numerous  to  discuss  in   this
 context,  but  the overall  technological
 application accomplished the following:

      o    Permitted design and program-
           ming  of  diverse  portions of
           MSIS to proceed concurrently;

      o    Insure  conformance  to   the
           general systems design;

      o    Insure  conformance to rigid
           design and programming stan-
           dards therefore improving the
           overall system;

      o    Insure  the  modularity   and
           flexibility of the total system,
           the subsystems, the programs,
           and the documentation;

      o    Enable  the  production  of  a
           reliable,  understandable,  and
           easily  maintainable  system;
           and
                                         F-16

-------
     o    Enable the production of high
          quality  documentation in  a
          timely fashion.

     During  the programming  phase of
MSIS, extensive efforts  were applied to
insure that the system would be portable
to  Honeywell,  Univac,   Burroughs,  and
CDC mainframes. (The target mainframe
was  chosen  to  be  an  IBM  computer
because the majority of  States  indicating
a desire to acquire MSIS had that equip-
ment).  This was accomplished primarily
through the  utilization  of  the  COBOL
copy facility.  By placing program source
code  which typically  varies  from main-
frame to mainframe  in  a COBOL copy
library, necessary modifications at instal-
lation time  can be facilitated in a much
more effective and timely manner.

      In summary, the decision to design a
computer system  for  use on  a  decentra-
lized basis  does  have  an  impact on a
system's  development, and  the  extent  to
which it is impacted is largely  dependent
on who the users will  be.  Certain design
alternatives could not be considered in the
case of MSIS development; however, the
latest state-of-the-art  techniques were
utilized to enhance the system's usability.
Finally,  extensive efforts were  applied
during the programing of  MSIS to insure
its portability to mainframes other  than
IBM.

Federal Reporting Data System

Developmental History

      During  1976,  EPA entered into a
contract  with  Index  Systems,  Inc.,  to
conduct a feasibility study of the design
alternatives  for the  development of a
computerized federal information system,
which is  now   known  as  the  Federal
Reporting Data System  (FRDS).   The
analysis recommended implementation  of
a sequential system,  as well as  outlined
the general systems design of uhe Federal
Reporting Data System.  EPA continued in
its  endeavor   to  develop  a  Federal
information  system  by entering into a
contract  with  the  Computer   Sciences
Corporation for the purpose of performing
the detailed systems design, programming,
testing, and documentation.   As  of  the
date of this report,  Computer  Sciences
Corporation   is   in   the   process   of
completing the design phase and preparing
to initiate programming of the system.

Major Functions Provided

     Unlike the Model State Information
System, the Federal Reporting Data Sys-
tem is to be implemented in a centralized
manner at EPA's National Computer Cen-
ter (NCC), Research Triangle Park, North
Carolina.  Also, the system is intended to
be  utilized  solely  by EPA headquarters
and the regional  offices, and not  by  the
States.   Overall,  the Federal reporting
Data System possesses the following capa-
bilities:

     o     Maintains  records (inventory
           data)  on  each  public  water
           system in the nation;

     o     Maintains  records on all viola-
           tions of the National Interim
           Primary Drinking Water Regu-
           lations from the previous Fed-
           eral Fiscal Year;

     o     Maintains  records on all vari-
           ances and  exemptions;

     o     Maintains   records  on    all
           enforcement actions  initiated
           because of failure to  comply
           with the regulations;

     o     Maintains  summary statistics
           for each public water system,
           as well as  for each State;

     o     Facilitates production  of  the
           annual report  to Congress;

     o     Facilitates production of com-
           pliance statistics  to  enable
           EPA  to monitor  the  perfor-
           mance of  a  State's primary
           enforcement    responsibility;
           and
                                          F-17

-------
     o    Facilitates  response  to  re-
          search  inquiries  from  within
          EPA, as well as from indepen-
          dent organizations.

Decision to Utilize a Data Base Manage-
ment System

     Although, Index Systems,  Inc.,  re-
commended the development of a sequen-
tial system, EPA, after conducting an in-
depth investigation, concluded that a Data
Base Management System (System  2000)
approach  would more closely  meet  the
needs of the Agency, and would facilitate
report  production  from ad  hoc require-
ments in  a more timely manner.   Index
Systems,   Inc.,   reviewed   the  DBMS
alternative  utilizing  System  2000,  and
found it very desirable from the viewpoint
of developmental and on-going operations
cost, as well as from its ability to produce
"special" reports in a timely manner.  The
decision  was based on the fact'that the
DBMS  approach  involved  the  maximum
technical risk  in comparison  with  the
other alternatives.    Technical  risk  was
defined as system sensitivity to changes in
the operating environment.
                                        F-18

-------
                           Test and Acceptance of a System
                              for a User Other Than EPA
                                    Donald Worley
The Objectives of a Test and Acceptance

     The first  objective  of a  test and
acceptance   is  normally  to  determine
whether  to  pay a  contractor.   This  is
especially true in an organization, such  as
EPA, where  the majority  of systems are
developed from an outside source.

     Secondly,  a  test and acceptance
determines whether or not the  system  is
adequate  for release.  This is  especially
true if  the  system is released  to  an
organization   other  than  the  system's
developer. As a matter of fact, test and
acceptance   is  very seldom used  in  a
situation  where  a   system  has   been
developed and will  be  used by the same
organization.

     Lastly,  utilizing the system in either
a  real  or demonstration situation  will
allow you to round off the jagged edges,
these edges are not a reflection of major
problems in the system, but rather natural
results of a program development cycle.

The Situation at the Time of  Action

     A test  and acceptance will almost
always  be done after  a  late  software
delivery  has  delayed the schedule.   Very
seldom do we have the privilege of staying
exactly  on   schedule.   Frequently, the
political  commitments for delivery  apply
pressure to the test and acceptance of the
system, causing the Project Manager,  to
shorten the test and acceptance time.  In
other words,  in any schedule if  there is a
push, the people who get pushed first will
be the test and acceptance team.

     Also the developmental  contractor
will be in a very defensive position.  He
must assist you in a test and acceptance
of the system, but each time you find a
problem it is a black mark on him.

Test and Acceptance Considerations

     Inasmuch as  you are delivering  a
total package (programs,  documentation,
methods, forms  etc.) to a State or local
Agency, the total system  must be tested.
Aspects of the total system include:

     o    System design
     o    Program design
     o    Operating Procedures
     o    Training facility
     o    System delivery
     o    Follow-up support

     Furthermore,  a   proper   test  and
acceptance  of a  system requires a two-
part test.    First,  a  "zero installation"
should be accomplished  on a  Federally
controlled computer.  The full team which
will go to the first customer site needs to
be involved, but  at this point no user of
the system should participate.  Part II of
the  test  and  acceptance  is  the  first
delivery   of  a   system  to   a   user
environment.

The Phases of System Checkout

     Let us now discuss the technique or
the phases  of  software  checkout.   The
Phase  I  checkout  or  acceptance deter-
mines whether or not the system is ready
to begin test  and acceptance.   It  also
determines  whether  the  basic  building
blocks of the system  work.  Do all the
programs function?  Can I  get in all the
input forms?  Can I produce all the output
forms?  At the end of  Phase I, I have not
determined  that  the system can do any-
thing for anybody, but I have determined
that the system is ready for checkout.
                                         F-19

-------
      Phase II is an individual checkout of
 each input and each output form  of the
 system.  The basic goal of Phase II is to
 answer two questions:  Can I get into the
 system everything that has been required?
 and can I get out of the system all  things
 required?   At the end of Phase II, I will
 have determined that all the transactions
 can be  entered  and  that all the reports
 can be retrieved, but I will  not  have
 determined whether  or not the internal
 working of the data over a period of time
 is accurate.

      Phase III of the test and acceptance
 is  by  far  the most  difficult,  time-con-
 suming, and costly of  any of the phases.
 Phase III defines the reason why a system
 is never fully debugged.  Nobody has ever
 had the time to  do the thorough test and
 acceptance that Phase III would require;
 that is, to check out and test the internal
 working of every data item.  We must test
 to  determine  whether the  data  value
 which comes in as input is not only printed
 out correctly, but that it also gets stored
 properly.  It is probably better in  a true
 test and acceptance to  divide Phase  III
 into two parts.   In the first stage,  Phase
 HI-A,  we would, at least, test and  check
 each individual  file which is built  and  go
 through at least two or three iterations of
 master file  updates.   This  activity will
 determine in  limited manner whether  or
 not  the data is being maintained properly.
 The second stage of Phase III which very
 few organizations would ever attempt  to
 do,  would be  an extremely  detailed,
 thorough tracing and checking, to  deter-
 mine whether the system is doing what it
 should  do.   By the time Phase III-A  is
 completed, you  are at the magical 99.9
 percent  of being  debugged.   You can
 simply depend upon the use of the system
 over a period of  years to replace a  Phase
 III-B test.

 The Test and Evaluation of MSIS

     Let's now begin to talk specifically
about  the  Model  State  Implementation
System test and acceptance.  The test and
acceptance team was  a highly qualified,
well-organized, properly managed organi-
zation.  It consisted of Bill Long, a Denver
consultant.  Bill was very qualified to be
the user's representative of the test and
acceptance team. Secondly, I represented
the MIDSD organization as the profes-
sional expert  on this  system.  We  had
support  from the ISI organization, which is
owned by Systems Development Corpora-
tion, the user services group of COMNET.
We also had considerable amount of sup-
port from the Office of  Water Supply.

   We  followed  the   two-part  process
already  described.  MSIS had  been deve-
loped   on  the  SWORCC   system  in
Cincinnati; and while  there  were some
problems encountered in the initial trans-
fer,  COMNET  was  an  excellent  "zero"
installation.    The   Part II  test  was  a
delivery to Oklahoma  where  they knew
they were in a test environment. I think a
good deal of the success MSIS has had was
due to  the considerable amount of effort
in Oklahoma.

   In the  test and  acceptance we con-
ducted  at COMNET,  we  followed the
Phase I, Phase II, Phase III process.  The
Phase I process occurred  without  pro-
blems.   At times,  we had to wait  for
certain   subsystems.    The  contractor,
SWORCC, was  very reliable and  let us
know when various subsystems were or
were  not  working.  There was one subsys-
tem for which we had to wait and some of
the  test  and  acceptance just slipped.
There was pressure to get  the system out
into the field, and  we did have to do  a
fairly rapid  test  and  acceptance.   The
Phase  II   did  uncover   some   source
problems,  which required  the  SWORCC
team to do some program  modifications.
The Phase III  testing  has continued  at
COMNET.

Summary and Conclusions

    In conclusion, I think it would  be fair
to say  that I have tried to convince you
that  you  cannot  depend   upon   the
                                          F-20

-------
developer of  a system  to  do test and     the  test  and acceptance  approach,  and
acceptance for you.  You, must be willing     that is to go ahead, install the system, and
to put  the effort forward  to find out     accept the consequences. My recommen-
whether  the system does,  in fact, work.     dation is to use the test and  acceptance
Has he done for you what you wanted him     process.  Thank you very much.
to do? I  suppose there is an alternative to
                                          F-21

-------
                             QUESTIONS AND ANSWERS
 Question:       In Region IV, most states have installed or are in the process of installing
                MSIS.  What State procedures have had to change to permit the States to
                use MSIS most effectively?

 Answer:        First of all, we have not had all the States installed.  We have  three
                States that are now operational with the system; they are just beginning
                to develop  their own usage.   As far as the installation is concerned,
                however,  we did have one  situation where we had to  hand-carry  the
                entire installation  through the overall management in the State.  We had
                to circumvent some procedures there that made it very difficult to work
                with  the  system and get it installed.   Beyond that, the  usage of  the
                system is still  in the "feeling-its-way-through" phase;  and we have  not
                established anything along those lines.

 Question:       Would MSIS have  been designed  differently if  all the subsystems were
                mandatory rather than having five mandatory and four optional subsys-
                tems? (Addressed  to all panelists.)

 Answer:        It is  important to point out that of  the nine MSIS subsystems, five of
                them are  mandatory and four are at the discretion of the State.  In  the
                four optional subsystems, there is only one, the Variances and Exemp-
                tions Subsystem,  that would need  to  communicate with the  others.
                Possibly it  could  have  been  used as  input  into  the  Water  Quality
                Compliance Subsystem.  So, yes,  there would have been  slight changes;
                but no major changes would have been made.

 CHAIR:        I would like to add two things to that.  First when I reviewed the MSIS
                subsystems, I only  mentioned eight primary subsystems; you are referring
                to nine.  The ninth subsystem, which is non-primary from a management
                point of view, but  certainly essential from a technical point of view, is
                the  MSIS subsystem, which performs interactions  and  various house-
                keeping functions.   Secondly,  in practice,  all the States have taken all
                nine subsystems.  We have no State that has wanted  only  the  basic
                mandatory set.

 Question:       I  have a question related to State reporting requirements. Where a State
                has not assumed primacy by the end of  this  December, are we still
                required to submit  Federal reporting data by January  1 of 1978?

 Answer:        Yes.  For FY 77,  if the States do not have primacy by the end of the
                year, then you  must submit  the data  acting as  a surrogate State.   EPA
                has responsibility for implementing the Act, and we want the States to
                accept that responsibility.  When they assume primacy  then they  are
                bound by  the requirements  of the  Act.  If a State does not now have
                primacy and will not have assumed primacy by the end of the year, the
                FY '77 Report would be the responsibility of the Region.

Question:       What mechanism is available or planned, for checking the accuracy and
                completeness of the data that is submitted by the States?
                                          F-22

-------
Answer:
Question:
Answer:
Question:
Answer:

Question:



Answer:
We are now establishing a very  comprehensive procedure.  Essentially,
the data will be submitted to the Region in order to check accuracy and
completeness.   We  have selected the National  Computer Center for
installation of the follow-on system, and the types -will go directly there.
We will be able to use their facilities management contract for accepting
the data, entering it into the system, and then updating the System 2000
Data Base Management System,  once the Region has certified that the
data  is  accurate.   The data  is  really  submitted through  you,  but
physically it will go to NCC.  You will then access it, do your checks, and
certify it  as all right.  Once  we get that certification from you, the
System 2000 Data Base will be updated.

Do you anticipate maintaining a speciai contract for auditing, or going to
the sources to cross-check samples of the survey  data  against what is
reported to the system within the region?

No,  that would  be your responsibility.  We will assume  that the data is
accurate.  We, in fact, will not update the data base until you authorize
it.  Through the Federal Reporting System which you will access, there is
a complete set  of  26 reports  and all  of System  2000's capability for
getting the kinds of reports that you will use to make that determination.
You will have,  through the  Federal System,  the capability to perform
those checks.  We  will do some  checks in preparation of our report to
Congress.  If we notice anything,  we will  work through the Region to
correct that; we will also be depending upon you.  The responsibility lies
with  the Region, but  we  all share  the responsibility and can  work
together.

I  say  a program is never  de-bugged.    "De-bugged"  means that the
frequency  of faults is so  low  that none have  been  observed  in  a
reasonably long  time.  I also want to take issue with saying that STORET
is  a centralized system. I would like to say that it is quasi-centralized.
The fact is that  the access of data  entry,  data editing, and responsibility
for data is highly decentralized.  We just maintain the system centrally
and provide it as a utility.  The system costs  nothing in terms of actual
cash, but it needs a  definite  manpower commitment, which is not free.  I
would like to ask one question. What is the total investment in MSIS in
terms of dollars, both in-house and contracts?

$2 million, not counting salaries and OWS staff.

How  do you, candidly, feel  about  the decentralized versus centralized
decision that was made? And if you had to make it again how would you
make it?  (Addressed to all panelists.)

The legislative  thrust was to involve the States more  and  more in the
program.  If we had centralized, we would not  have received as  much
State cooperation.  If  I had  to make the  decision for MSIS, I would still
decentralize.  Currently, we are doing a feasibility study  for an ADP
system  to  service the  Underground Injection Control Program, and we
will  be faced with that decision.  Should there be  a decentralized or  a
centralized system, to serve  the  needs of  the underground program?
                                          F-23

-------
Answer:
Question:
Answer:
Answer:
With  the emphasis on the States' needs and State involvement, we may
decentralize again.

The situation with MSIS may be unique, in that there was a very strong
need to establish primacy, or to have the States accept primacy, because
the Safe Drinking Water Act  does  rely heavily on the States to do the
job. It is not clear to me, though, that the decentralized system is much
more beneficial over  a centralized  system, as far as the State is
concerned.  We  may have to wait and see what happens with  MSIS.  If
MSIS becomes another CDHS, then there  is no question in my mind that
we should have gone with the centralized  concept.  However if, in fact,
it works  beautifully the  States  use it, assume  authority  and more
responsibility for their own programs,  establish their independence,  and
use grant funds wisely for the Safe Drinking  Water Act—then maybe it
was better  to decentralize.  My own  personal feeling is that it would
have  been cheaper to develop a centralized system.  We would have had
to install it in 35 states, and we would have a more powerful  state-of-
the-art-type system  than what we have now.   But I think the jury is still
out, so to speak; we'll see in the future what will be the best way to go.

Having been involved, throughout the system's development on a detailed
basis, I have mixed feelings. From a technological viewpoint, I can agree
in that more state-of-the-art  techniques could have been utilized had it
been placed on a centralized basis.  No doubt the design,  to some extent,
as well as the programing suffered,  from the decentralized approach. On
the other hand,  having been intimately involved in all the meetings with
State, Regional and  Headquarters  personnel,  practically  since  the
inception of MSIS, I know for a fact  that the States would have outrightly
rejected the use of the system in many cases.  It is very  difficult now to
get a lot of them to cooperate by simply submitting the requirements
that are in the system that they  are receiving, let alone saying that they
have to give the information to the Federal government.  That was their
primary complaint.  Arguments  persisted  literally for hours on whether
or not a  phone number should be  reported.   If  the  system  had  been
established on a Federal level, many of the States would have just packed
their bags and gone home. And that is  why my feelings are mixed.

My feeling  is that unless we are fortunate, the Federal  Data Reporting
System may have severe troubles over the next couple of years, because
of the lack of  reporting requirements.   This is a  situation  where the
concepts were good,  but somewhere the power was not strong enough for
good implementation.

I would like to add one thing.  In Region IV, we have fairly active
STORET participation.  Seven or eight States use the system on a  daily
basis. The reason for that, more than anything, is that we, in the Region,
have  actively pursued their  usage for  some  years now.   I do not
necessarily  agree that  the States would have outright rejected the
system. If they wanted primacy and if there was a system available,  I
feel pretty strongly  that most of them would take it, and most of  them
would use it, rather than develop their own things,  particularly if there
were  no grant funds available.  The key  issue is  the funding  of such  a

-------
                system. There are some States that just cannot go outside the State and
                pay for usage of a computer or a computer facility. Some states have a
                law that prohibits it.   If  the  funding issue could  have been resolved,
                similar to the STORET sub-allowance, I think that would have been a
                strong point, definitely, to have centralized.

CHAIR:         Well,  if there are no other comments or questions, that concludes our
                presentation. Thank you.
                                          F-25

-------
                          PANEL G:  ADP MANAGEMENT
                          Chairman:     Kenneth Byram

                          Panelists:      Joel Brandon
                                        George Lehnert
                                        Bruce Rothrock
                                        Douglas W. Shape
                                        Michael Steinacher
                            INTRODUCTORY REMARKS


                                  Kenneth. Byram

     The idea for this panel came out of, as ideas for most of the panels did, the zero-
based budgeting committee or the zero-based budgeting process that went on this summer.
Without trying to embarrass him, I think the idea for this panel came from George Lehnert
and assisting him was Bruce Rothrock, at that time, they suggested  that  it might be
healthy to debate or to discuss how data processing ought to be managed in EPA, and how
or where functions ought to exist.  What should be done in a central way, or  maybe what
should not be done in a central way. In the charter to the panel members, I asked them to
be aware  of either  specific kinds of suggestions such as whether MIDSD should be
abolished,  or general kinds of suggestions, such as ADP should not be centralized within
EPA.  On the panel are people with varying perspectives about this thing. Two of us on
the panel  are from MIDSD, two from regional offices, and two are Headquarters ADP
coordinators. Let me introduce them for those of you who don't know everyone here.  On
my immediate left is George Lehnert, who is in the Office of Program Management,
Office  of Water  and  Hazardous Materials.   Douglas Shape  is  Management  Division
Director from Region 4 in Atlanta.  Bruce Rothrock is the Agency Coordinator in  the
Office of Enforcement and is also in the Program Management and Operations area. Mike
Steinacher recently changed jobs and is now working for the National Computer Center.
Finally,  there is 3oel  Brandon who is no long with EPA.   As  a short-timer, he can  say
anything he pleases and probably will.
                                          G-l

-------
           "Those of us involved in Automatic Data Processing in the  Environ-
      mental Protection Agency  lost a valued  source of advice and forcefulness
      when  Dr.  George Lehnert  died in May,  1978.  We are sure that  many of
      George's thoughts as reflected in the panel seminar on ADP Management will
      provide guidance in the events and years to come in EPA ADP Management."

                         MIDSD: Coordination and Integration

                                  George Lehnert
      I find it awfully unfair to blame this
 whole ugly mess on me.  As  a frame of
 reference  for my introductory remark, I
 go back to the  functional statement for
 the office, for MIDSD, as a reference.  I
 think we can look at this as two different
 kinds of functions.  The first of these has
 to do with the development of a manage-
 ment information system.  I  do not know
 whether that means a management infor-
 mation system in the strictest sense, or
 whether that encompasses all data  pro-
 cessing  systems within  EPA.   Subsets
 under  that would be  things  like  formu-
 lating policies and objectives and develop-
 ing guidelines and  standards  for  admin-
 istering a comprehensive agency data pro-
 cessing program. I guess the  word "com-
 prehensive" here is  up for grabs because I
 am not sure what that means, in terms of
 what  it is MIDSD would like to be doing.
 The  second  function  is  providing  the
 Agency a  focal point in  the  integration.
 Information systems can cross functional,
 geographic, media and technical lines. On
 that item, I want to  say  a few words.  I
 have  been under  the  impression  that
 MIDSD  has not  done  enough in terms of
 coordinating  the systems across  these
 lines  functional,  media, etc.   One  good
 example of where they did what was, in
 my opinion, a proper  job of coordination
 was in the Water Supply Program, in the
 Model State  Information System  and in
 the Federal  Reporting System.   In all
 fairness  to  MIDSD,   I  think that   the
 operating  programs  need  to  take an
 initiative  very early in the game  and to
 bring MIDSD in to say, "We are starting to
look at the front end of the system  design,
the feasibility  study,  perhaps, and we
want you in it from the very beginning as
we  do the other program offices in  the
Agency, such as Enforcement, etc., etc."
Often, that is not done.  The reason that
it  is  not  done  is  that  the  operating
departments start paying some attention
to the fact that  they will  need an ADP
system  of  some  sort.  Quite  often  for
most of them, they  are not even thinking
about what  it  is they  are going to be
doing,  because  what  it is they  will be
doing is  farther down  the  line.   An
example is Enforcement.  Normally,  En-
forcement  would not be  initially con-
cerned,  because their work does not come
until about two years later.  By the same
token, in ORD,  they have  ongoing R&D.
It  is  not  in  their cards  to  be  doing
something about this particular system at
this point in  time,  because they  are  not
brought in.   Unless  someone  from  the
water program  goes to  MIDSD and says,
"We are starting to  take a  look at  a
system, which  is mandated by the Act.
We want to bring you in early in the game
and keep you in.  In addition to you being
in on it, we also want you to coordinate
across agency lines to bring in Enforce-
ment, ORD, regions, labs, or whatever."

     I have given you what I thought was
a good example  of the operating program
bringing in MIDSD early in the game, and
MIDSD's response being to  play a  coordi-
native role.  In contrast to that, let me
use  the Hazardous Waste Management
System, as a poor example.  This system
ran down the road for several months, at
least, before anyone from  MIDSD or En-
forcement or any of the other offices got
involved.   There are occasions where  it
has been done  well and  very thoroughly.
What I'm  advocating here is a  stronger
                                          G-2

-------
role by MIDSD  in  terms of coordinating
and   integrating   information  systems
across functional, geographic,  media, and
technical lines.

      Another subset of the development
of  an agency  management  information
program  has to do with the development
and maintenance of the Agency's overall
management information system.   Here,
once  again, I have problems not knowing
what  these  words  mean.   What  is  the
Agency's overall management information
system?   Still another subset is planned
coordination.    Maybe  I  do not  have  a
proper perspective  because I  am  in  the
Office  of  the  Assistant  Administrator;
perhaps, program  people in the individual
programs will have a different perspective
on this. I would say that, to the extent to
which I  am  aware, primarily relates  to
training  programs  in  these  areas, and
some documentation along these lines.

      One problem  that I have had in mind
with  respect to these kinds  of things has
to  do with where,  in  the  organizational
structure,  MIDSD is located.   That is  a
question that I  have had and one we will
discuss today with enough points of view
that we will  have a data base,  from which
we could then go forward or backward.

      What  I  mean by being  improperly
located organizationally  is  that,  in  the
Office  of  Administration,  one  normally
thinks of  services  of some  sort  being
provided.  I do not look at the things that I
talked about as services, per se.  I look at
them  more  as  management  kinds  of
things.     In   the   coordination  across
functional  lines  and  similar  kinds  of
things,  MIDSD would  take the lead.   I
guess in the absence of any recommenda-
tion,  I can only  say that it  ought  to  be
looked at from the standpoint of putting
those functions about which I have talked
under the AA for planning management,
or  perhaps  directly  under the  Admini-
strator.  On  the  other side of the  coin,
there are some bona-fide Agency services
provided.  In other words, we have  been
talking  about real  management kinds  of
things so far, but here are some  services
that need to be provided.  There are  some
provided by MIDSD, such as determining
the need; arranging for the establishment
of  EPA computer  centers;  prescribing
guidelines covering the operations and use
of data processing equipment; operating
the   Headquarters;  providing   technical
guidance  to  field  installations  in  ADP
operations and applications. Those things,
I  think,  are  legitimately  services and
perhaps should be provided from an  orga-
nization which sits in the Office of Ad-
ministration.  However, I  contend that at
least it ought to be looked at  from the
standpoint of breaking it into two pieces,
i.e.,  putting  one  services unit  in the
Office  of  Administration  and the  other
one,  which  provides   real   technical
direction   and   coordination   directly
responsible to  the AA for Planning and
Management.
                                           G-3

-------
                            QUESTIONS AND ANSWERS
Comment:       In terms of the Agency's Management Information System, the language
                was put in several years ago, when people were thinking in terms of one
                Management Information System for General Motors and another one for
                EPA, and another for  the State Department.  These would include all
                facets of management information; namely, personnel, payroll, grants,
                etc. In fact, there has been some allusion to the need for coming up with
                that here  at the conference.   Yesterday, there  was quite a bit of
                discussion about combining OPM systems, making finance and grants one
                system.  I think everybody has in the back of their minds somewhere, an
                image of what a total management information system  would be.  It
                consists  of  the systems and an Assistant  Administrator sitting down in
                front.of the CRT console typing some nebulous inquiry that results in
                exactly the information that he needs to make a prompt, quick, accurate,
                and incontrovertible decision.  I think that if that is  the image, then that
                is probably a little out of date  in terms of what people  now realize is
                practical or possible with one central information bank.

Question:        Is the  term "Agency Management Information System" synonomous with
                the  administrative systems?  The  question  is:   Are those two  terms
                synonomous?

Answer:         As / see it, the administrative  system is one which is used for those
                things which are normally associated with OPM, what is identified by the
                government  as administrative  overhead  or administrative  tasks as
                opposed to program management which you would have to include in MIS.
                Grants, for instance, are handled by OPM, but used by the  regional water
                programs to track their progress and award grants.  It is therefore in the
                Management  Information  System,  but  not  in the  context  of   an
                administrative system.

Question:        I was going to comment on how I would interpret an agency management
                information system to be if four or five years ago, you tried to write the
                responsibility paragraph for  the MIDSD organization.  If you think about
                the Agency's responsibility to the environment and to society, you would
                be interested, not in the administrative system so much as what are we
                doing nation-wide that has  resulted in some kind  of an  environmental
                cleanup.  How can we  measure the progress toward this?  Where are the
                significant problems arising and how can the top management, that is at
                the AA level and above, address these issues and be sure that we  are on
                the  right track?  In  that regard, I also looked at the responsibility
                paragraph within the organization manual and was quite confused about  a
                lot of the language in there regarding MIDSD's responsibility, particularly
                with regard  to  the Management Information System.  I  could not  see
                anywhere within the  Agency that  MIDSD was  running,  directing, or
                assuming responsibility for this or is there any  one type  of system like
                that in existence?

-------
                does not have a mission.  They do not have a piece  of legislation that
                they are enforcing. Yet is seems to me to provide a  much clearer goal
                than some of the  other ADP programs, like GICS, which has a mission
                and yet does not have nearly the reputation.

Comment:       The  STORET that you are picking  up  here  is one in  which  I have been
                interested for sometime.   I do not often allow  myself to  complain  in
                public.  Frankly, I have been in EPA since  1971,  over six years now.   I
                have watched some things evolve and some things not. One of the basic
                things that took me a long time to figure out was brought into focus one
                day when Jim Tozzi, who is the OMB Budget Examiner for EPA, was up
                for  a briefing,  the  first  time Jim   Tozzi  had  every  been  out  of
                Washington.  Regional Division Directors were going through  the briefing
                drill which we had down at that point pretty well. I was watching Jim
                very closely, which is one of my hobbies.  I  can see lights coming in his
                eyes every now  and then.  He was asking questions that indicated to me
                that  he  was understanding  sometimes.    The   things  that  he  was
                understanding was sort of how the Agency's programs fit together, which
                is how water and Enforcement and Water Quality Standard, those type  of
                things, all fit together. I was sitting and thinking, my God,  why is this?
                We are certainly not  nearly as smart as all those people  in Washington
                collectively.  I am sure they have been over there telling him all about
                these great things. It finally dawned on me that they had.  They could
                not probably explain to Jim Tozzi, because they did not know themselves
                how these things fit together.   Only at a regional level does the Agency
                come together.  My point is that, very simply, the Agency dogs not have
                a strategy.   There  is  the  water  strategy, and  there  is  an effluent
                guideline, but none of them fit  together. You are talking about tails and
                dogs and that does not make a lot of sense.  Frankly, the problem is that
                you can not design an information system and build an Agency around  it.
                In relation to what Joel was saying, there  was an information system
                called STORET.   The Agency  just happened to fit around  it.  That is
                almost serendipitous.  What has to happen to leadership to the Agency is
                to decide what we are going to do.   Then all of us get together, whether
                we are building  information systems or environmental quality.  There is
                the problem.  That is why there is no  Agency Information System.  The
                system  provides some things that are required by law, and  some things
                that are not  required by law, and some things  that people want to build
                because they happened to be in the right place at the right time.  We
                have a  mish-mash of  the systems  that we  have  inherited or built, and
                they do not fit together.  We constantly wrestle with  this problem,  I  do
                not think you can put the systems  that we have together.  You have  to
                build them. You start with an idea that they do fit together; they do use
                common data words,  and you start from that point.  We  talk about the
                organizational placement of this division or  this function.  I am not sure
                it makes a lot of difference. It would adjust certain  problems, but until
                the basic  problem is solved, we are just working on the symptoms.  That
                is where I have been for two years, trying to figure out what  to do.
                                           G-5

-------
Answer:
 Comment:
 Comment:

 Comment:
Comment:
Comment:
In terms of the environmental system  that  would meet  the Agency's
needs, as opposed to an administrative system, you could make a similar
analogy in the practicality in trying to combine all of the environmental
information into some sort of tracking system  that would tell us whether
we are making progress or where there  are areas where we need to put
more fuel on the fire to solve the nation's environmental needs. I guess I
am  still not  comfortable  with  that  wording.    Perhaps, if  it  were
interpreted and changed to mean the Agency Management Information
Systems  or the Agency's Management  Information Program, it would
make a little  more sense.  I think the wording is in there historically,
because, at one point, the  way  the future  was going was  to be  one
Management  Information System that  would tell people  what  they
wanted to know, whether that be administrative or technical.  Are there
other comments at the moment?

ADP is often  considered the tail of the dog.  I do not particularly  like
that, but I think  it describes a condition  that, unless  the program
manager tasks are  orderly arranged and you  know what they are,  the
kinds of measurements you need, etc., etc., it  is very difficult to use the
ADP system for something which you do not know. Bruce had referred to
an environmental meansurement of conditions. Until we, in the Agency,
can come up with some  environmental index of some sort and  measure
that, then it is pretty difficult to design an ADP  program to handle it.
There must be indices, some basis  of measurement, or something outlined
to determine whether or not the environment  is getting better or worse,
or whatever.  I think it would be unfair to expect MIDSD or any body  else
to come Up with ADP systems until that is defined.

I think that's a very good point.

In addition to  trying to coordinate our ADP, I have also been working in
that area to some  degree.  Frankly, we found ourselves getting almost
nowhere.   Maybe  there are some brains in the Agency  who  have
something cooking that is ready to pop, but I do not know about it.

In looking at systems, groups, or concentrations of ADP expertise within
the  Agency, the ones  that seems the most successful are, in part, so
because of the people running them, but also, in part, because they know
what they are doing. I could think of some negative ones,  but I will not
mention them.  I think the STORET group has a clear idea of what  it is
trying to do.  I think occasionally, it wanders  off into some areas where
it does not have a clear idea and gets into trouble, but, in general, there
is a very clear mandate there with a whole lot of  effort.  As a result, it
comes out to be a better ADP system than it would if it did not have a
careful charter. I think if you start with the tail, you do not end up  with
much of a dog.

This is true.  I think STORET has set some goals.  Apparently, what you
are saying is that you do not need the dog if you have a tail that can set
its own goal.   The  air system has  a similar purpose and yet the air
systems are known to be not as good as STORET is.  As I said, STORET
                                          G-6

-------
Comment:       I would think that the further up you are in the organization, the stronger
                would be the ear of the person to whom would be listening, whatever it is
                you say.

Comment:       I think that  maybe what Willis  is  saying is that if you start out saying,
                "Gee,  we want to  be a staff office  of  the administrator."   What you
                really need is to have is the Administrator say, "Why / reaZZy need a staff
                office  to do this."  Without the Administrator fully understanding why he
                needs a staff office or the AA, it would not work.

Comment:       I could go back to another analogy, for which, I am probably famous now.
                I remember  back  in  the early days of the Agency,  that first  crop of
                regional  management directors  were  constantly asking Howard Messner
                to get the men to see their boss,  the Regional Administrator.  If  I was
                the appointed one to advise the Administrator on information systems, I
                could not advise him unless he  wants to be advised.  I would have to
                prove  myself worthwhile to be in  there in the first place.  That was the
                same  thing  with  the first round of management  directors.   It was
                difficult being useful, being accepted. I think a year ago, when we had
                the steering group, I think  the organizational placement was not as
                important then as it is now.  In the sense that you had an AA involvement
                in some top-level kinds of decisions relative to ADP.

Comment:       The thing I am hearing from George  and Willis sums  up.  There may be
                advantage in having an organizational change to get  ADP  closer to the
                top, but  only because the people in ADP  know,  more than  anybody else,
                what the Agency should be doing and what it lacks.  Certainly nobody
                else in ADP realizes that there is not  an agency strategy, which if that is
                true, I do not know how much difference it will  make. If you get to the
                top, and they do not know, our telling  them will not make a difference.

Comment:       I have not tried  to say that,  but I will say  this,  that  I  think it is
                important. I would not go so far as to say that there  is not a foundation
                laid relative to the kinds of things we are  talking about.  I am saying that
                until the Agency  does  something concrete  in determining  what its
                strategy is, until there is a measurement  of some sort available in these
                areas,  it makes designing the ADP systems awkward and aZZows us to run
                in all kinds of directions, adding to the problems  that already extst.
                                            G-7

-------
                         ADP Management and Organization
                                   Bruce Rothrock
     Too often in the ADP area we limit
the  management concerns  to  feasibility
studies, system  design aspects, hardware
and  software  considerations,  software
maintenance and  operation.   We  worry
about storage space, job processing  time,
software enhancements,  ADP budgets and
the like, and concentrate all of  our efforts
on  the  details  related  to matters  of
secondary importance. The area requiring
the most emphasis, and certainly the one
to which computer-related management is
subordinate, is information management.
The  Agency spends  far  more  time con-
cerned  about the software for data sys-
tems and data bases than  it does  about
information and the ability  of the data in
these systems to  provide information to
managers  about  their  program  areas.
What is  of  even more  concern is the
amount  of  duplication  throughout the
Agency in data collection, systems devel-
opment,  and data  processing,  and the
general disinterest in developing common
data bases and data gathering activities.

      The DA has  indicated that data is a
valuable resource and  that more  effort
will  be needed in  the future to share and
cooperate  in  the gathering and  use of
data.   We  must  recognize the need to
share  data across  media  and  between
program offices.

      A  limited  analysis  follows that
creates an  organizational structure that
coincides   with    the    responsibilities
assigned to four broad areas of Informa-
tion,   Data,  Software   and   Hardware
(Figure 1).

     The four areas have been arranged
in a  hiearchiacal  order:    Information,
Data, Software,  Hardware.  This top-down
approach  placed  more  importance  on
areas that historically have not been given
much attention  and conveys the concept
that software and hardware can be given
secondary interest behind information and
data. This arrangement also suggests that
perhaps  each area  should be  managed
differently.  Certainly hardware manage-
ment and  information  management  are
not similar, and if we compar the func-
tions and  activities  between  the three
pairs of  adjoining areas  it  is  easy  to
recognize  the  potential  for  separate
management of all four areas.

     There are numerous functions within
the  Agency  related to  data  processing.
Several have been identified and assigned
to one of  the four categories.   Initially
only the functions  have  been  defined;
responsibility  for  the functions  will  be
analyzed later.  The first category, infor-
mation,  has activities  associated  with
information  requirements analysis,  and
data base establishment and maintenance.
(Figure 2).   These include definition of
information needed to carry out program
objectives,  determination  of  currentness
and accuracy of data that will be needed,
understanding sources of  data,  auditing
data bases to ascertain if they fulfill the
needs as defined, and periodically review-
ing and reevaluating information require-
ments.

     Broadly the functions related to the
second  category,  data,  deal with  the
definition  of  data items/data elements,
data element standards, how the data will
be  collected  (including  forms .designs),
data   capture,    data   structure   and
dependancy, and data base administration
as  used  in  connection  with  data base
management systems (DBMS) (Figure 3).

     The   functions   detailed   system
design, program development  and  testing,
and  system  operation  and  maintenance
fall in the software category.  (Figure 4).
                                          G-8

-------
ADP  FUNCTIONS
 INFORMATION
        DATA
   SOFTWARE
   HARDWARE
  FIGURE 1

-------
                      FUNCTIONS
INFORMATION
  '  INFORMATION REQUIREMENTS ANALYSIS
  '  INFORMATION USES AND OUTPUTS
  1  COMPLETENESS,  CURRENTNESS,  AND ACCURACY REQUIREMENTS
  1  DATA SOURCES
  1  DATA BASE AUDITS - DATA VERIFICATION
  '  DATA BASE - DM50
  1  RETRIEVALS:  OUTPUT REPORTS,  DATA ANALYSIS,  DATA REDUCTION
    AND SUMMARIES
                      FIGURE 2

-------
                        FUNCTIONS
DATA
  1  DATA ELEMENT DEFINITION
  1  DATA ELEMENT ATTRIBUTES
  1  DATA VALUE STANDARDS
  '  DATA VALUE EDITS
  1  FORMS DESIGN
  1  DATA CAPTURE AND INPUT
                      FIGURE 3

-------
                     FUNCTIONS

SOFTWARE
  1  FEASIBILITY STUDIES
  1  DETAILED SYSTEM DESIGN
  1  SOFTWARE - DFI&O
  '  AUDIT OF SYSTEM SOFTWARE & SYSTEM DESIGN
  1  SPECIAL APPLICATIONS AND ANALYSIS
                    FIGURE  4

-------
     Functions in the hardware area per-
tain to the procurement and use of  hard-
ware and hardware  services that match
the  Agency's  needs.   (Figure  5).    Some
specific functions relate to low speed and
remote job entry terminal purchase, data
center  operation,  data  center  access
authorization,   telecommunication,   ac-
counting  for  resource  utilization  and
billing, and user communications and sup-
port.

      The next step in the process looks at
who within  the Agency does these  func-
tions,  who  assumes  or  was responsible.
Figure 6 identifies which of four organiza-
tions has responsibility for  the indicated
functions.    The  observer   immediately
draws  ihe  conclusion that  considerable
duplication  and overlap  exists.    From
experience we know that contention fre-
quently develops,  redundant  data collec-
tion   occurs,   similar    systems    are
developed, and occasional confusion exists
over who has  responsibility,  especially in
the software  area.    Many people and
organizations throughout the Agency have
interest in  software  related   functions.
Program  offices  generally   write  the
software, MIDSD likes to see  that  feasi-
bility  studies  have been conducted  and
occassionally conducts audits.  They  try to
assure that proper consideration has been
given  to  the design and development  of
software applications.

      Several  problems  arise  from this
organization of responsibilities:

      1.   Considerable  duplicaton  exists
      in data gathering, systems develop-
      ment, and systems operation.

      2.    Duplicate  or   similar   data
      items and values exist in different
      systems.

      3.    No  standards  exists for data
      elements and   values  and  conse-
      quently data cannot easily be shared
      among systems.
     4.    Because of the multiplicity of
     responsibilities   that  a   program
     director has  he frequencly  makes
     decisions for which he doesn't have
     the training and should not have the
     responsibility.

     A  radical  approach  to  overcome
these problems  separates  responsibilities
by  division  and eliminates  or reduces
duplication of responsibilities.   Figure 7
lists the same functions as in Figure 6, but
assigns  primary responsibility  for func-
tions to one  of  four areas.  The program
offices  and  divisions  maintain  responsi-
bility  for   the functions   related   to
information requirements  and data base
maintenance.    Program Divisions  would
have  little  need  for programmers  and
computer systems analysts.  A  new divi-
sion, the Data Coordination  and Manage-
ment Division, has responsibility for data
element  definitions, standards,  and data
collection.    In  today's   terms  these
functions  of  a  data base  administrator
belong in this  division.    It  takes  on a
broader responsibility of translating infor-
mation requirements defined by program
divisions into data items and coordinating
these  among the   various  divisions  to
eliminate redundant data gathering activi-
ties and promote data sharing.

     Another new division, the ADP Soft-
ware Services Division, takes the respon-
sibility  for  the software  development,
operation,  and  maintenance   functions.
Systems  like GIGS,  PCS,  and  STORET
would be operated and  maintained from
this division.

     Finally, the ADP Computer Services
Division   has   the   responsibilities   of
establishing and running the various  data
centers, and other related functions.

     Because of the relationship and de-
pendence of the three new divisions  they
would   have  to  exist   in  the   same
organization  of the Agency, preferably
directly   under   the  Administrator   or
                                            G-9

-------
                        FUNCTIONS

HARDWARE
  1  REQUIREMENTS ANALYSIS
  1  PROCUREMENT
  •  SERVICE/CONTRACT MANAGEMENT
  1  USER AUTHORIZATION AND REGISTRATION
  1  USER COMMUNICATIONS
  1  USER SUPPORT
  •  UTILITIES
  1  OTHER EQUIPMENT PROCUREMENTS
  1  ACCOUNTING  OF RESOURCE UTILIZATION
                    FIGURE 5

-------
CURRENT RESPONSIBILITY  FOR  FUNCTIONS
                  RESPONSIBILITIES
INFORMATION
  1 DEFINE INFORMATION REQUIREMENTS
  1 DETERMINE How INFORMATION  WILL BE USED
  1 ESTABLISH COMPLETENESS,  ACCURACY, AND CURRENTNESS  REQUIREMENTS
  • DETERMINE DATA SOURCES
  1 DEVELOP, MAINTAIN, AND OPERATE DATA BASE
  1 ANALYZE AND REDUCE DATA
DATA
  ' DEFINE DATA ITEMS
  1 DESCRIBE DATA ELEMENT ATTRIBUTES
  1 ESTABLISH DATA VALUE STANDARDS
  1 DEFINE DATA VALUE EDITS
  1 DATA COLLECTION AND INPUT  MECHANISMS/PROCEDURES
  1 COORDINATE ACTIVITIES AMONG OFFICES
SQFWARE
  1 ASSURE THAT ADP USE WILL MATCH REQUIREMENTS
  ' MAKE EFFICIENT AND EFFECTIVE USE OF RESOURCES
  ' DEVELOP, OPERATE AND MAINTAIN SOFTWARE
  ' REVIEW SYSTEM PERFORMANCE  AGAINST CRITERIA
  ' DOCUMENTATION
HARDWARE
  ' PROCURE OVERALL SYSTEM RESOURCES
  1 ASSURE SYSTEM AVAILABILITY AND RESPONSE
  1 CONTROL ACCESS TO RESOURCES
  1 PROVIDE ACCOUNTING OF RESOURCE UTILIZATION
  1 GUARANTEE THAT RESOURCES ARE USED EFFECTIVELY
  ' MAKE HARDWARE PROCUREMENT  BENEFICIAL AND EFFECTIVE
   X  - Primary Responsibility
   /  - Secondary  Responsibility
PROG
DIV  MIDSD
 X
 X
 X
 X
 X


 X
 X


 X
 X
                                                         PRO
    RO
    ADP
                                             X
                                             X
                                             X
                                             X
                                             X


                                             X
                                             X
                                             X
                                             X
                                             X
                                             X
        X
        X
        X
        X
        X


        X
        X
        X
        X
        X
         X
X
X
                                                                 /
      X
      X
      X
      X
      X


      X
      X
      X
       X
       X
       X
           FIGURE  6

-------
                              PROPOSED RESPONSIBILITIES
                   RESPONSIBILITIES
                                                                  PROG
 INFORMATION                                                       DIV  DCMD
   1 DEFINE INFORMATION REQUIREMENTS                                 x
   1 DETERMINE How INFORMATION WILL BE USED                          x
   ' ESTABLISH COMPLETENESS/ ACCURACY/ AND CURRENTNESS  REQUIREMENTS   x
   ' DETERMINE DATA SOURCES                                          x
   1 DEVELOP/ MAINTAIN/  AND OPERATE DATA BASE                        x
   1 ANALYZE AND REDUCE DATA                                         x
 DATA
   ' DEFINE DATA ITEMS                                               /     x
   1 DESCRIBE DATA ELEMENT ATTRIBUTES                                /     x
   ' ESTABLISH DATA VALUE STANDARDS                                  /     x
   ' DEFINE DATA VALUE  EDITS                                         /     x
   ' DATA COLLECTION AND INPUT MECHANISMS/PROCEDURES                  /     x
   1 COORDINATE ACTIVITIES AMONG OFFICES                             /     x
 SOFTWARE
   ' ASSURE THAT ADP USE WILL MATCH REQUIREMENTS
   ' MAKE EFFICIENT AND  EFFECTIVE USE OF RESOURCES
   1 DEVELOP/  OPERATE AND MAINTAIN SOFTWARE
   ' REVIEW SYSTEM PERFORMANCE AGAINST CRITERIA
   ' DOCUMENTATION
HARDWARE
  1 PROCURE OVERALL  SYSTEM RESOURCES
  1 ASSURE SYSTEM AVAILABILITY AND RESPONSE
  ' CONTROL ACCESS TO RESOURCES
  ' PROVIDE ACCOUNTING OF RESOURCE UTILIZATION
  '  GUARANTEE THAT RESOURCES ARE USED EFFECTIVELY
    MAKE HARDWARE  PROCUREMENT BENEFICIAL  AND EFFECTIVE
    X - Primary Responsibility
    / - Secondary Responsibility
ADP
SSD
ADP
CSD
X
X
X
X
X
        X
        X
        X
        X
        X
        X
                                   FIGURE 7

-------
Deputy Administrator.  Such an organiza-      political  appointment or  changes in ad-
tion could be the Institute of Information      ministration.  This office  would have the
Technology  and  Data Processing, headed      goals of "service, coordination, and  stan-
by  a  career individual  not  subject to      dardization."
                                           G-10

-------
                             QUESTIONS AND ANSWERS
Question:       I have  a question.   If  the Systems  Services  Division will finally be
                primarily responsible for software services, why can not MIDSD not be
                responsive in its present  form since it has that as a part of its bag?  What
                will cause you to be  more effective then  than now?  Is it position in the
                organization?

Answer:         I think  the position  in the organization has a lot to do with it. The fact
                that they have two things.  The position under an AA ship does not give
                them the direct responsibility to the line organizations or to the program
                offices  within the Agency. It is always up and over and down. That does
                not work well  within this Agency.  The other thing is that because we
                have little caches and groups of ADP expertise scattered throughout the
                Agency, there is always  a butting of heads about different decisions that
                need to be made on a particular software development systems design.

Question:       You  have three  organizations now  having a responsibility  for the
                software. In the present organizational structure, why can  not MIDSD be
                given the prime responsibility  in its present form?  In other words, I do
                not  understand  how  you  wipe out  the  program  and  a  few  ORD
                responsibilities when you restructure the organization?

Answer:         This gives a broader role  to  MIDSD, re-labeling it is all  that  it was
                attempting to  do.   MIDSD  and  PRO  have  been caught  up  in the
                responsibility of the data coordination, the management division, which I
                suggest as a radical approach.  Along with their present  responsibility,
                the visibility within the organization  is important.   I do  not think that
                where they are located, at this point, provides the  proper leverage and
                authority to carry out that responsibility.

Question:       Where would the regions fit in your plan?

Answer:         / did not go  through this  in all the  details that are really necessary.
                Regional  offices did not get much focus.  They would operate  pretty
                much in  the  same  vein as they  are now.  The  way they have been
                centralized in the last three years  is that regional data branch becomes
                responsible for most of  the regions' data processing  activities.  You will
                still find that  in some regions.  Some  of the program offices have
                programmers who are writing special analysis programs to  look at air and
                water data. That is an area, too, that  I did not look at too  closely.

Question:       I have a question having to do with what does the Deputy Administrator
                mean when he said data is a valuable source?

Answer:         Spending too much money.
                                           G-ll

-------
                                    COMMENTS
Comment:      / would like to talk a little bit about the consolidation-decentralization
                issue from  a regional  standpoint.   If, in  our  particular  region,  we
                consolidate  or centralize  everybody who  is involved  in ADP and the
                region, I suspect we will have a branch consisting of about 50 people. We
                have about 600 in the region.  Everybody is dibbling and dabbing in ADP,
                EDP or whatever you want to call it, but I do not think from a regional
                perspective  that it  makes a lot of sense. If you took all the  people, you
                would have too many, but if you selectively took some  people and freed
                up  those other ones to do some  technical  business towards  the control
                solution, it might make a lot of sense.

Comment:      If we look at  the centralization issue, whether it is Headquarters or the
                region,  I think it's  important to look at the responsibilities that ADP
                people have.  I know that within most of the regions, a  lot of the people
                who might probably associate with ADP have a responsbility related to
                the  data input,  the review of edit messages, the  checking of the data
                base, and the running  of some  retrievals  which I would  classify as
                responsibility  that is associated with the program office, i.e., managing
                the data base  itself is not really an ADP function, per se.  The fact that
                they have to use some ADP equipment to get some of their work done,  I
                think is incidential. The real  responsibility there is to  manage the data
                base and  the  information in  it.   I would not think in the  centralized
                process that you would pick these people  up necessarily,  because they
                would be  assigned to the program divisions  which should be responsible
                for the data in the system.

Comment:      One thing that was  interesting  to me was the  training  survey.  The
                contractor came back with some enormously high percentage, like one
                out of three,  or one out of four, people in the Agency were involved in
                ADP.  The  training plan came  back from  the  contractor saying that,
                basically, it was at least one out of 10.  It seemed very high and still
                does. One out of every 10 people that you would run into in EPA were
                ADP people.  The problem with that was that there were an  awful lot of
                scientists, engineers,  biologists,  administrators,  and secretaries and so
                forth, that end up  doing data processing-related  work. I think we just
                heard an interesting point.  If you centralize  all those people, you end up
                with centralizing a  good chunk of the Agency in one response, so  that the
                challenge is to separate out where there have been mixes of functions,
                where a secretary is also a data enterer, a scientist is  also a FORTRAN
                programmer.  If you separate out those functions  so that you have  the
                scientist doing science, and the FORTRAN programmer supporting him,
                that makes them both effective.

Question:       At  what point in  this program  was  it suggested that ADP be
                centralized? I do not recall having heard that.
                                            G-12

-------
Answer:
Comment:
 Question:
 Answer:
I think, at least from a regional standpoint, we have long been on
the road of centralization.  We have, in fact, about 80 percent of
that goal of centralization reached.  It  has worked effectively.
We are not there yet, but we will get there.

I would like to suggest another concept.  The divisions, branches,
sections within the program  offices certainly cannot have all the
capabilities required for the conduct  of all kinds of feasibility
studies, audits, system design, and these  types of things.  There-
fore, in my opinion, there needs to be  some centralized resource
for these kinds of capabilities.  We can go to the DM&.O contract
for these kinds of things, but here, once again, it seems to me that
when that is  done with regard  to  a system  or a  contemplated
system, then it ought to be done by a centrally-located organiza-
tion who  can then look across functional and media lines and pull
it together. I look at that from  the Headquarters Program Office
point of view.

Do the regions have any  of these  needs  for a centrally located
systems unit within MIDSD or elsewhere?  That is a question that I
want to pose.

In one word, the answer is yes.  There are a lot of things we would
like to do throughout the regions, but we can not do.
                                           G-13

-------
                     ADP Problems From a Manager's Perspective
                                 Michael Steinacher
      As Ken mentioned, I am from Willis"
 North Carolina  family.  I do  not know if
 you saw the Godfather replaying on tele-
 vision, but it certainly is a  good example
 of  management theory and practice that
 sure works. Whether you are  theory X or
 theory  Y,  that  is  one with  which  you
 cannot argue.  Ken did ask me to try to
 stimulate some  discussion and interaction
 between the panel  and  the audience  on
 thought   provoking   ADP   management
 issues.  I will attempt to do that.  It is
 awfully  hard  for me in my position to
 disguise  some  of my own opinions  and
 philosophies.   I think I could  probably
 argue some topics  from  either  point of
 view, but I do believe you will agree with
 me  that  the topics  of the  conversion,
 contracting,  and   centralization,  even
 though they may be of secondary impor-
 tance, represent something to stimulate
 thought and provoke conversation.

      There are a number of problems that
 face  us as  ADP managers  as  we project
 into 1980 and  the 1980  procurement.  I
 have tried to  summarize  some  of  the
 problems  that seem  to be most  mean-
 ingful.  I would like  to share some of  this
 with  you.   It has  been  interesting  this
 week to communicate with  people  that
 are knowledgeable in the areas of agency-
 wide systems. It seems, however, that the
 Agency is spending hundreds of thousands
 of dollars on systems  that,  if you believe
 what people say, are generally non-res-
 ponsive.  Systems that just do  not seem to
 satisfy management's requirements or the
 intended user-application of the system.

      We suffer, in my opinion, from what
 seems to be a  technological  lag  within
 ADP and EPA.  I can  discuss  many of the
data center specifics, but it does seem to
me that watching things running  in  our
UNIVAC we see  an  awful  lot of second-
and  third-generation  technology, if  you
will, being applied to what I would des-
cribe  as  fourth-generation  problems.
There is a data center technological lag.
We are  certainly faced with the problem
of limited resources.   As managers,  we
are  going  to be  faced with  increasing
demands placed  on  resources  that are
available to us.

     Additionally,  we  are all  going to
affected   by  the   1980   procurement,
whether we like it or not.  Odds are pretty
good that whatever is selected, it will not
be exactly what  we want.  So the whole
business  of  getting  prepared  for  that
eventual  conversion  is something  that
confronts us all.  In terms of resources, if
your organization is anything like ours, we
will  see more of a  decline in  in-house
resources,  i.e.,  government  resources.
These are  clearly declining.  Contractor
resources are, of course, available to us.  I
think it  is pretty clear that this is the
direction  in  which  the   government  is
going.  For those of us who either are or
claim to be  able  to clear memory in six
instructions, we find that this is changing.
We  are  playing   a  different  role.   As
technical managers, we are faced with the
whole process of re-tooling personnel.

     I mentioned earlier that I was going
to attempt to cover  three thought-pro-
voking topics.  The  first  of which deals
with conversion,  with  which we all  are
going to be faced.  Conversions are topics
dear to  my heart.  Along with some of my
other NCC colleagues, I share the credit
for having affected today  successful con-
version  from  IBM to  UNIVAC.  I am sure
that there are those of you who are aware
of how successful that conversion was and
how sweet it  was.  My past experience  is
more in private enterprise than in govern-
ment,  but I  really  do  not  see  much
difference in the way conversion effects
organizations either inside or  outside the

-------
government.   It  is a  painful process.   I
think that  the success of a conversion is
really  relative to  degree of  motivation
does not necessarily  apply to all  of the
inter-application  systems about which we
are concerned.

     In my opinion, the biggest problem
that any  organization faces  in  looking
toward conversion is the attitude problem.
It is simply an  acceptance of change and
an acceptance of the responsibility that
you, your staff, and your colleagues share
in that overall process of conversion. You
see some interesting attitudes.  I  think if
all of  you  would think for a moment you
would  probably  recall  some  of  these
things, too.   You hear  comments like,
"Those turkeys bought it, by golly, they
can install and convert it.  I have to sit
back and  do my job."  That  is  a great
ostrich attitude.  You can stick your head
in the sand and say,  "Those fools bought
that UNIVAC machine, they can  make it
work."

      In looking  at  conversions, we cer-
tainly  can  not ignore the very real pro-
blems  of limited  resources. There are the
technological differences.   We all talk
about  transportability and compatibility.
The facts are that if you go from Brand X
to Brand  Y, you have a  problem.  Our
conversion, as we experience it, is one of
the real parts of the iceberg, that  was just
not apparent to  us, as we went from IBM
to UNIVAC.  I think as managers we have
to consider very early in the  game the
whole  process of  test  and  acceptance.
Conversion is part  of it,  whether it  is
converted for us, we still bear the respon-
sibility of  testing  it  and  ultimately ac-
cepting it.   Then  the whole business  of
paralleling those  production systems on
your current computer with the converted
systems on the  new one.   It is a tricky
business.   It has to  be choreographed
pretty well.   Ultimately, it  will mean
success if it is handled properly. Another
thing,  as managers, we can  not ignore in
talking about conversion  is kind of an
interesting phenomenon.   You find that
the  most  non-responsive system  in your
entire application mix, the one to which
you just do not want to own up because it
does  not  work  well.    You  will  find,
however, that this particular system, once
it is converted, becomes the most classic
example of high technology that you have
ever seen in all your life.  Your recollec-
tions are  always  fine.  It really  was an
example of high technology.  The thinking
is that if it was bad then, it will be worse
on  the new  one, no  question  about it.
What should we do now? A lot to be done
to be sure.  It takes a lot longer than the
next 10 minutes to try to discuss.

      Documentation is another topic.  I
do not see any short  cuts there.  I think
that as you plan for the next three or four
years, that this is the time to develop if
you  have not already.   Some have to
complete    programs,   systems,    and
operating    documentation    with   the
emphasis on your ECL or  JCL techniques
that oftentimes materially change.  You
need  to document the  logic of the pro-
gram at execution time.   You  need to
quantify current performance.  As we go
back  to the high  technology phemonenon,
you  want  to be able to  measure,  at
conversion time, just what that product is
when it is converted and finally delivered
to you. Along with  documenting current
performance, I think you need to consider
current operating cost, and examine them
as you plan for the conversion and as you
go  through  your test  and  acceptance
process.   I think  you need to coordinate
very carefully the dynamics  of your cur-
rent  system  and current  programs  in
respect to the conversion freeze which is
going to take place at some future point
in  time.   Granted all of  our operational
programs  can  not  function  in a  static
state for the next three years, change has
to  take  place.   I  think you have  to
carefully  demonstrate  that  change  can
occur despite  the freeze that undoubtedly
has got to be placed on making changes to
these systems as  you approach the 1980's
conversion process.  It is a good time  to
police the accumulation  of unnecessary
programs and  unnecessary data files.  It is
a  good time to  effect  a  good house-
cleaning, so that when the conversion does
                                          G-15

-------
 take place, you  are not  wasting  time,
 funds and resources converting things that
 are  never  really used.    We  need  to
 emphasize  the use of standard high-level
 programming   languages:       COBOL,
 FORTRAN, PL1.  We need  to think about
 it  now;  that  is  the whole business  of
 parallel processing and test and accep-
 tance procedures.

      Undoubtedly this conversion effort
 will  be effected  largely  by  contractor
 resources.  They will show up one day and
 they will  say,  "Here is your  converted
 package, accept it. Ready or not, here it
 comes."  You  need to be  thinking  about
 that now.   How  do you  go about  the
 process of  continuing to run your opera-
 tion  while  your operation  is  being  con-
 verted?  To sum it up, I think  the  time
 between now and the completion of the
 1980's procurement is a good time to clean
 up and  take stock of what you have.

      We mentioned  that   the  thought-
 provoking topics included contracting out.
 Clearly the trend in  government services
 is  to contract out ADP functions.  Our
 North Carolina experience has been that
 over the past  six years, our government
 resources have declined.   Six years ago,
 we had a  very  small  computer and  35
 people.  Today, we have a very, very large
 computer and 18 people.  Thus, the trend,
 at  least as far as we are concerned, is
 pretty  obvious.  We  have recently  taken
 what we think is a bold step forward  by
 issuing  a mission-oriented contract for the
 operation of NCC.  This  contract went
 into effect October 1st.  It,  in 25 words or
 less, provides contractor support for all of
 the day-to-day activities associated  with
 running our data center.  Our government
 people are assuming the role of technical
 area  managers   of   various  functional
 sections  within   this  mission  contract
 operation.   For all practical purposes the
 government people have retreated to the
 position that I  believe is the role that we
 should be playing,  i.e., one of  planning,
 one of  monitoring,  one  of  evaluating
performance, and one  of  attempting  to
find and describe mission  objectives  in
terms  of  ADP functions and ADP  solu-
tions.  Contractors are being used essen-
tially to take the  definition and do the
thing that they  do best.    My  personal
experience in EPA  as an ADP manager is
not contracting out, but it is the way to
go.  I think if  you woke me up in the
middle of the night and said, "Would you
rather do it with  all government people or
with all contractor people, my inclination
would  probably  be, let's do it  with all
government people because I am  one."
Given  the  EPA  situation ,  however, and
given the situation of government service,
I really can not see any other way to go.
What we need to do is just  learn how to
use that resource effectively.

     There are  some significant advan-
tages in the whole business of contracting
things out.   Although not an advantage,
MIDSD has greatly assisted us with  the
whole  business of contracting out because
we  have  standard contracts  that  are
reasonably easy to get.  Specifically, I'm
thinking of the DM&O.  I believe there are
advantages of contracting out; one of the
principle ones is ease of staffing.  With
the contract resources now  available, we
can  get  the quantity  of people and  the
kinds  of people  that  we need when we
need them.  We  have  the  ability to load
level.  According to our requirements, we
can get an analyst at the front end where
we need him and not have to pay overhead
on the programmers until  we have pro-
gram  specifications with which  to  work.
We  have the  facility to  employ  tech-
nology.  We really can go  and hire the
people who are specialist in these  areas,
without having to experience the learning
period of time that it takes to get our own
talented people up to speed in these new
technology areas that are relatively new
to us.  I do believe that in contracting out,
we have better control and  accounting of
project cost.  You just tend to pay more
attention to the cost of  projects  when
 they are being supported by contracting
personnel.   One reason you  do  this  is
because in all probability it is costing you
 more than what  it would have cost you if
you had done it with your own people. As
                                         G-16

-------
a manager, I feel that I can get more out
of my people than I could probably get out
of a contractor.  Whether that is the case
or not, I do not really know.  To be sure,
when you are tallying the cost of contrac-
tor services  for  projects,  you will  get
more management awareness than what
you  experience when your  programmers
were doing these tasks on in-house basis.

     I think  another significant advantage
in contracting things out is that you  have
the  facility  to  procure up-to-date tech-
nology  through  this  contract  resource.
Many of us have dealt with bits and bytes.
I recall  some  of these experiences  in a
pretty foreign  way.  The fact  is that in
our  mode of  operation in   the  Federal
Government, we do not generally have the
opportunity  to  maintain state-of-the-art
technology and state-of-the-art expertise,
ourselves. We are too busy.  We are too
busy  engaging  in the  business  of  the
Agency and what the Agency is about.  It
is my  opinion that the  contract resource
procures up-to-date technology. The con-
tractors  that  are competing  for  these
kinds  of projects are forced to maintain
that kind of  technology.  That is the only
way they can be successful  in the field.
The  ones  that  have  experienced  the
economic disasters of the early 70's had to
be  good or they would  not have made it
this long.   Perhaps  one of  the  biggest
advantages  of  contracting things  out is
that it will free  up a most  vital resource
and  the most  limited  resource that  you
have.   It will  free  up your  technical
people.  It will get them out of that  bit
and  byte  mode  of  operation.   It  will
permit them  to start addressing their time
and  their energies toward your business,
the business of running the Agency. What
are they going to be doing?  It seems to
me that one of the things that they will
not be  doing is  worrying  about clearing
memory with six instructions. I guarantee
you that there are a lot of  us who  have
spent a  lot  of  time learning how to  do
that.  We are going to be able to apply our
technology  to  mission-related problem
definitions.  We will be able to do our own
feasibility study.  There is one  area that,
if  we call ourselves professionals, really
ticks me off a little bit about contracting
out.  When we have to call in a contractor
to perform a feasibility study because we
do  not  have  the  time  to  do  it, that
contractor winds up spending half of that
contract  time,  getting  to the point of
knowing most of the things that you have
forgotten  a  long  time  ago.   If your
technical  staff were  freed up from day-
to-day activity,  it would seem to me that
they  would be  able to  perform these
feasibility and requirement studies.

     I think an  area  that goes undone in
our Agency is performance monitoring and
evaluation.  How good or how bad is your
current system?  It seems to me  that our
technical  people can concentrate some
energies at looking at that.  We  have all
heard of the ADP stage hypothesis theory
which says we are now going from Stage 3
to Stage  4, Stage  4  being  optimization
and enhancement.  Again,  it seems to  me
that  if  we  can free  up our  technical
people  from  the burden  of day-to-day
activity, that they can concentrate their
efforts on getting from  Stage 3 to Stage
^.  I think one  of the  more significant
advantages of  being  able  to  contract
things out is that it is almost an unlimited
resource.   It is  expandible.  We  do have
the facility to inflate  or deflate  as  our
mission requires.

      There are  some problems associated
with  contracting things out  to  be sure.
Effective  contract management  requires
very special skills.  There seems  to have
been  a  lot of examples of poor  contract
performance.    To  some degree,  it  is
attributable I  am almost of the opinion—
as  Don  Fitzpatrick  with Arthur  Young
mentioned in his presentation—that con-
tract management  is  a   form of  art.   We
try to write contracts that are so ironclad
that we have the  contractor where  we
want them, that it is almost an exercise in
futility, because you cannot contract sat-
isfaction.  You  can  write that  ironclad
contract  and  the guy  could  deliver  the
goods right there on the line.  It could be
the  worse  damn  thing  you  have ever
                                          G-17

-------
procured.  It is very difficult to legislate
perfection.   Our  responsibility certainly
begins with clearly defining our require-
ments,  our  milestones, and the deliver-
ables.    More  importantly,  we  have  to
provide these contractors with a demand
that they adhere to standards.

     Of all  the  areas about which  we
think, but probably have  not done  much
with as yet,  is cost parameters.  We do
not want to  limit those cost parameters
simply to develop  mental  cost and imple-
mentation cost.  We want this cost  para-
meter  to consider the operation of this
system  once it is implemented.   More
importantly,  we want this cost parameter
to consider the maintenance of the system
after it is  turned over  to  us.    The
requirements in our contract must provide
for growth because we are  looking really
at decisions  that  will  effect us in the
Agency over  a 10-year period of time. We
have to provide for schedule or design
reviews. We have  to assure  ourselves that
the design of a system or program is  going
to be cost effective over the life cycle of
the system or program. We have to see to
it that the implementation of this effort
is  consistent  with   the   design.    We
certainly  have to  have   the   feedback
facility of evaluating  the performance of
this effort once it is completed.  In terms
of contracting things out, I would suggest
that indepedent test and acceptance pro-
cesses need  to be emphasized  greatly.
This is a role that our in-house personnel
can perform  very well.  The contractor
does his thing, then we have to effectively
test and evaluate the product once  it is
turned over to use.  Lastly, the comment
that I would  make  about dealing  with
contractors is  that  you cannot  legislate
satisfaction  and perfection.   The  thing
that a lot of  us fail to realize in dealing
with contractors is that they are humans
like us and we have to learn to deal with
them  reasonably  to  communicate  with
them effectively.
                                        G-18

-------
                            QUESTIONS AND ANSWERS


Question:        How many stops did UNIVAC have last month?

Answer:         I set you up for that one, Willis.  We had an aZl time low. We had 18
                stops for the month of November. It is the first time we have been under
                20.   We have looked on that as a step in the right  direction.  I can
                remember a couple of years ago, when we were talking about 75 stops a
                month.  Eighteen is well within workable limits.  We can attribute a lot
                of that  to the fine work of Don Fulford and technical  people that have
                made  decisions in the past.   The recent installation of our uninterrup-
                table power sources have also been a tremendous help. The people system
                is moving well.
                                         G-19

-------
                                   Centralization
                                    Joel Brandon
      I am going to discuss centralization,
and start out talking about centralization
in the context  of the deliberate effort to
centralize ADP  activities in Region V
which was amended by the Regional Ad-
ministrator,  executed,  and  then  com-
pleted.  Then,  I will try to relate to  the
Agency as a  whole, which is not real easy
because the scale is entirely different.

      About six months before I got there,
an  order  was  issued  by  the Regional
Administrator  to bring all of ADP  under
one   branch  and  management  division.
Prior to that,  this is  what the organiza-
tional structure looked like.    The solid
circles represent what I would call profes-
sional positions.  Civil Service refers to
the  300  series people as  administrators,
rather than  professionals,  meaning that
there is  no  positive educational require-
ment to become a  334.   That  is  fairly
important in  what  we  did  there,  for
reasons  with  which  you  will   become
familiar.   Rather than  sticking to Civil
Service,  I will call  those  people profes-
sionals.   The  people  who have  no blue
filled in,  are either clerical  or technical
people, i.e.,  computer technicians, secre-
taries, keypunchers,  and so forth.  Prior to
centralization,  Enforcement  had  its own
little package.  There was  a branch called
data   systems,   which   largely    was
responsible for the operation  of the Data
100 System and did some programming  and
analysis.  Surveillance and analysis  had a
very  powerful  group which  was, for  all
practical purposes, dedicated  to STORET.
GICS had a couple of clerks hooked up to
the   Grants  Administration   Branch   in
Management Division.   They were con-
sidered by the region  to be  computer
people.  They  were tagged for  transfer.
There were   some   other   ADP-related
types, mostly in air. Most of  these people
are now considered to be people who  are
mainly concerned with their own program
area using the  computer as a tool.  They
were not the subject of reorganization and
I found that to be appropriate.  Of course,
we  did  not have  a mini-computer then,
and we  were not supporting it, as we are
now.  The most dramatic difference there
is aside from  the  fact  that everybody is
under one roof, the fact that we have had
an  enormous  increase  in  the ratio  of
professionals to  clericals, or professionals
to non-professionals.   That was  accom-
plished  over time, of course.   There is a
half professional  listed  in  the  current
branch.   That is a  person who is currently
classified as a supervisory operator, who I
have  requested  to  be  reclassified as a
computer specialist.   Personnel has not
seen fit to agree  with me yet.  I think
they will come around.  The reason for the
organization is that  the situation existing
in Region V was pretty  much the same  as
we  have  in the overall Agency.  These
efforts were completely unrelated. There
was  considerable  amount of  bitterness,
jealousy; there were a couple of fistfights.
Dave Rockwell  was thrown  across the
room once.  It was more over a loan of a
bridge book than it was over professional
matters.   The  level  of  bitterness and
animosity was considerable between the
groups,  in some  cases.  The entire branch
is headed by a vacancy  that I have labeled
GICS.   I  have tried to indicate in some
way what the  responsibilities  were and
how they could have been transferred. We
start  out  with  a  seven-man  STORET
group.  Right now  we have essentially one
person involved in  STORET in the Branch.
This, in itself, caused most of the actual
reductions in position.  The entire effort
was redundant.  The big problem was how
to go from  one  to the  other.  Obviously,
the order had  people  dragged  into one
place.   That was the easy part. It was  far
easier  than people  thought  it would  be.
As  soon  as the Regional  Administrator
issued the order, people began to scramble
for positions  in the new  branch.   There
was not any question in fighting it. I think
                                         G-20

-------
that would  probably  happen at this level
as well.  You then find yourself  with  a
group  of people  who were your  former
enemies.  Their skills are not  necessarily
what you  want.   If  you  want to head
toward more  leverage, more professional
and  fewer  clerical people, you have  to
find a way to do it.  This is what we did.
The two GIGS people that you see on the
top are no longer associated with ADP at
all.   They  were largely responsible  for
data entry.  I  have always considered data
entry to be a program problem.  We work
that two ways.  We  transfer  two  people
back with their positions, and that  was, of
course, facilitated both by our own  efforts
and  with the  conclusion of  GIGS.  On the
STORET side, most  of  that  effort was
eliminated with the one professional posi-
tion in STORET on the working level, the
supervisor was transferred  up  completely
and has become our STORET professional.
It turns out that he was doing all of  the
work anyway.  In Enforcement, the one
professional  was  transferred  into  the
Branch and remained a  professional until
he  left a  few  weeks ago.  These were
opportunities  for  upward  mobility even
though the  positions were not identified
specifically as upward mobility  positions
because of  internal  problems.  If these
were engineering positions, we could  not
have done it,  but you can do it  at ADP. If
you   have  a  computer  technician or an
environmental specialist that you want to
make into a  computer  specialist,  if  the
person  is qualified and  can  be trained,
they can  be  converted.  Two other En-
forcement positions  were  given back  to
Enforcement;   one has  been  transferred
into a professional position. In  the Data
Systems Branch, we  had four  people on
the operation staff; now, there  are  two.
Two keypunchers  have been given  to  the
Water  Division  without their  positions
being transferred.  All keypunching is now
being done on contract. The positions that
we have in  the Branch that are classified
as 334 series  are limited to one computer
operator.   I would like  to  contract  that
and a secretary, as well.  What we have
ended up with is a soft core of 334 series
people.  That is the sort of thing I would
recommend  at the national level.   It is
always a question of: Who do you transfer
if  you are going  to centralize?  In my
opinion, it should be more or less limited
to 334's or people who would become that;
in  other words,  a  solid core  of  data
processing people.  That does not mean
that they do not  know  anything  about
programs, but their  responsibilities  are
more concerned with the computer than
they are with  the  programs.   That is  a
fairly easy determination to  make, except
that, in any  successful centralization, if
you are going to  be selfish  about  it, you
ought to drag more people in than you will
use to allow  yourself the luxury of trans-
ferring  some back, and getting  rid of
some.  There was one person who actually
has been released from the Agency in that
program.  I do not think they had a whole
lot to do with centralization.

     There  are two parts to  this graph.
The  top one  is proposed organization for
Headquarters; the bottom is a technique
of relating to the program once you have
done it.  On  top,  I have divided the effort
into three parts  which parallel, more or
less, what we are doing in the regions.
The  set of resources management people
would  pretty much be at the  same level.
Then you would have some people working
on  the  management information system.
They would  be called  sytems  developers,
or something like that, if you wanted to
separate them  from  another group;  it
would  probably useful to do so.   One of
the primary reasons that I recommend this
kind of a combination is to avoid the most
ridiculous redundancy  in efforts  that we
have seen between STORET,  the air sys-
tems, and MSIS, when it comes to collect-
ing  and  disseminating  data   about the
environment. I would hesitate to think of
the savings that we could have realized if
STORET has been made responsible for all
of this stuff in the beginning which  they
wanted to   do.    That  is  probably an
unpopular view in some circles, but from
the  regional  standpoint this had an enor-
mous impact.  We have had  to maintain
relations with more people than we should
have.  In addition to that,  we really can
                                          G-21

-------
not get the job done the way things are
set up now.  In  our region, we have an air
person  and  a  STORET  person.   The
STORE! person is also a backup on  air.
His work enables him to understand what
is going on.  This is something that is  a
rather important  concept.   The fact  is
that  the  experience  that  one  has  in
developing a  data base is  transferable.
Even if you do not translate a live  code
from one of the others, you simply would
not make certain mistakes.   You would
include certain features just on the basis
of your experience.  That does not seem
to be the case in the development of the
air system in the Agency.

     That is enough  for the  top.   The
bottom is a graphic demonstration of how
a so-called  nucleus  of data  processors
would work, does work, in the regions.   I
believe in  the  five-year plan.    Index
systems has said a nucleus of data proces-
sors is probably a  good thing to have.
That is one of the things they have  said
with  which I agree.   I  do  not think we
necessarily have that.   MIDSD certainly
does not act that way.  There may be a
fairly  sizable  group  of people who are
experts, but  the question is how do they
deal with the programs?  The  answer is:
They  are not dealing with them in a total
support relationship.   It is kind of  an
overall review  process. They pretty much
supply resources as'needed, but, in the
analysis effort,  in  developing  new  sys-
tems, their facts are too late.  This is how
we would attempt to stop it.  We have an
established program with an ADP coordi-
nator in it.  That person is not necessarily
an  ADP person and  he probably is  not.
There is someone primarily responsible for
that system  in ADP, then somebody  to
back  him up in  case  he is not there,  in
case he quits, or in case they  need  more
than one person on an effort in any given
period of time. That is pretty much how
we do it in the Region now.   We have  a
person in ADP responsible for something.
We have at least one backup.  On T&A,
for instance, on the  payroll, we have  at
least  three backups.   For an  emerging
program,  they  obviously  do  not  have
anybody  in  ADP,  they do  not have  a
coordinator; they  do not have anybody.
The question is how  do they factor into
ADP  when  they are  coming  up?   My
answer  is that  they draw  on  resources
without paying  for  them until they get
started.  In  other  words, as  soon as they
feel that they might have something to do
in ADP, some person or group of persons
in ADP is/are identified to help them out
on a part-time  basis.   This person would
be looking at what they are  doing  and
make  random suggestions.  Of course, as
they go  further and further  along, the
need becomes more and more apparent to
someone in their organization.  Hopefully,
you end up with someone in ADP to handle
it; an  ADP coordinator can be stolen from
the ADP group or hired from the outside
with the assistance or insistence of ADP.
This process worked as I understand  it
with MSIS.  It was long after it probably
should have  been, but it is  my  under-
standing that Willis insisted -they they hire
an  analyst.    If  they  did,  probably  any
success that they have would  be related to
that.   I would like  to discuss the issue of
how this sort of thing might happen, not
just desire it to happen, but  how it might
actually occur.  I doubt very  much that
MIDSD is going to push strongly for this.  I
had a word  up  there called Czar; that  is
the Russian  equivalent of Godfather.  The
fact is that  if the situation were to take
place,  Willis"  position  would be kind of
tenuous.  This agency has a habit of going
out and  hiring new people for stuff like
that because EPA's management and good
management do not even read the  same
newspapers. Anybody who tries something
like  that has   two  choices.   You  can
succeed; they  can take your job  away.
You can fail, and you would make a whole
lot of enemies, or, possibly  you  could
succeed and they  would give you the job,
but that is only a one out of three chance.
I do not look for this kind of effort coming
up from MIDSD. On the other  hand in the
Region V effort, we went down from some
20-odd  positions  to 12.    Somebody  in
Headquarters  might  possibly notice that
between now and the end of this Admini-
stration.   It  is possible  to  reduce  the
                                          G-22

-------
overall number  of  position  if  you  do
centralize.  If it comes, that will probably
be  the way  it  comes,  which is rather
unfortunate.  It will probably happen if it
happens, so that is to  what you can look
forward, a  forced centralization  with a
reduction in time.

      We  have  a list  of  characteristics,
and  we  would  like  to assign pluses  or
minuses for the existing system which  we
call  fragmented.  For  a centralized sys-
tem  call  it  rationalized because  you  do
not want to bias anyone's selection. I will
briefly discuss what I  think  these things
are and then  will ask you either to agree
with me and  say  nothing, or say  "boo" if
you do not  agree with what  I am saying.
The  first question is:  Is  a decentralized
system more responsive, and my answer to
that is no,   not necessarily.  Responsive
depends on the people.  Some place in the
decentralized organization, you will  have
a data processor reporting to a complete
stranger.  This guy  can snow that guy in
any way that he wants.  He  can  tell him
absolutely  anything.   When the manager
goes to the  person in his organization and
says I  want something,  he does not neces-
sarily  get it,  so it is best  not to send for
him.   It is  also bad  from  the standpoint
that these organizations are buried, that,
say, people even in the  water program can
not get anything out of STORET  because
they  do not  happen to  be in the same
division. We have poor  response from that
standpoint.  I would favor the rationalized
system, from the standpoint  of response,
if there are any boos I  want to hear them.
I guess   everybody  agrees   with that.
Either that or those nickels that passed
did  some good.   Flexibility.   That  is a
vague  term,  by  flexibility  I  mean  the
ability of the organization to respond  to
new  requirements; clearly  this is  related
to response.  I think that a  centralized
organization  that  has  a  nucleus  can
quickly form  an opinion about something
and can quickly give directions.  I would
call a  centralized organization more res-
ponsible.  Cost. If you  reduce the number
of  positions,  if   you  reduce  redundant
effort, clearly you have improved cost. I
would  aassign a plus to the rationalized
system for cost. No negatives. Accounta-
bility.    Jim  Hammerle  had  said that
accountability was not necessarily good.  I
feel it is. I think the central system is far
more  accountable  if, for no other reason
than, its way of doing business is standard.
It is easy to see what is going on at any
one time. For instance, if someone wants
to know how many terminals EPA had,  it
would be a whole lot easier to find out if
they were all under one authority.  I would
assign a plus to be rationalized system for
cost as well.  Standards are,  of course, far
easier for a central organization to en-
force. The manager is responsible for the
standards.   The people working for  him
are the ones  who are responsible  for
applying them. Now, we have agencywide
standards which  are,  in  many  cases,
ignored.  Again, I  would assign a plus  to
the rationalized system for that.  New
approaches.    This is  something  where
there is some  confusion.   It  is possible
with the centralized system having those
standards that you may come  up with
some  one novel approaches.   This would
increase  overtime, but would find  you
were  doing  things  the  same way time
after  time.   I  would ssign  a  plus  to the
fragmented  systems for new  approaches.
I just wanted to see if you were out there.
Technical   resources.      Centralization
would have  a nucleus of data processors
providing you with a far better technical
resource than  having just  a few  people
located  in  each  department.   I do  not
believe  in allowing at any time or any
place,  one  person to analyze  a  given
problem.   No  matter  how  good  that
analyst is he will make mistakes.  Techni-
cal resources depend on depth and I would,
therefore, distinctly assign a  plus to  the
rationalized  system  for   technical  re-
sources.     How  about   management
resources?   You  are not  going to have
computer  managers  in   a   fragmented
system unless you have some fairly large
fragments.   The  larger the  organization
you   have  centrally,   the  more  data
processing  managers  you  will have  and
quite   probably   they   will   be   better.
Because  it  will  be  their  sole   job.
                                          G-23

-------
Overhead.   It  is possible  to have more
overhead  centralized,  but  it  is  quite
unlikely.  The only possibility that that
would happen is  that  if the centralized
agency   became   over-concerned   with
things like documentation  standards, ac-
countability, reporting,  and  things  like
that.   It is my opinion  that we already
have as much of that  as we can possibly
get.  Every possible  thing  that can be
documented  is supposed  to  be  docu-
mented,  not that it  is.   Every  possible
form of documentation that exists in EPA,
every kind  of  reporting you can do, we
have been  doing it.   I would  say that
overhead   is   probably   pretty   much
balanced  between  the two.   An  other
interesting characteristic is trouble.   If
you have people in  a central organization
who appear to cross different lines,  you
will  have  to  send  fewer people  to
different, far-flung  places to accomplish a
given  job.  Rather than sending one from
ADP and a  person from the  program and
another person from  a nother program
with another ADP person,  etc.  You can
send one person from  ADP and one from
each program.   This  should reduce the
travel  budget  as  well.    Vulnerability.
There  are two  kinds; this the last  one.
This is the biggest negative that we have
in centralization.  If you combine every-
body, make  them all professionals,  and
stick them in an ADP group, they will be
the  target   of  every  administrative
overhead   headhunting  operation   that
comes  down  the pipe.  We have had  that
problem in Region V. Generally speaking,
we have been fairly  successful in fighting
it off,  but it is a constant battle.   You
always have to justify every damn position
you have in ADP.  I would assign a plus to
the fragmented  system for that.  The last
one is absenteeism. Absenteeism is a very
grave  problem  in  government.   It  is
certainly a grave problem  in the regions.
I do not  know  how  bad it  is  here, but
whenever  I call somebody they are out.  I
would say offhand that the central system
is much better than  that because there is
a  person  who  responds to  your  needs.
There is also a person to back him up, and
possibly a secretary  to back  up the back-
up.  I would  assign a distinct plus to the
rationalized  system   for vulnerability to
absenteeism.
                                         G-2*

-------
                                     COMMENTS
Comment:      / would like  to add  one  cautionary  note  on  what Joel said.   ADP
                centralization seems to work fairly well with inter-regional offices.  The
                same argument  might be used to centralized the ADP function within the
                Agency. In other words, to  make all regional offices, branches of MIDSD
                or some big balloon like that.  I do not know if that is a good idea or not.

Response:       I would say offhand, in my own opinion, that it would not make a whole
                lot of difference.   It would depend on  the  regional management and
                MIDSD's  management.   If the  regional management  were  bad and
                MIDSD's good, there would be an advantage in having it centralized;  if
                not,  there  would not.   There  is always something to be said about
                decentralizing locations that are physically separated.

Comment:      Throughout this discussion,  while the  various panelists have given
                different points of view  with respect to ADP  management, I feel that it
                is a common thing that can be summed up by saying that MIDSD ought  to
                take a look at being more active in certain areas.  I believe that  would be
                good.

Comment:      I had thought I might share  with you some  insights or experiences  or
                whatever on the COMNET conversion as related to the  centralization  of
                ADP.  There is not  really time  to do that. I do think,  however, that an
                awful lot of the centralization argument revolves around the kinds and
                quality of  people   that  you can attract  and  keep in  these various
                organizations.   A lot of Joel's  discussion is  effective.   His  push for
                centralization is effective  if the people  who are doing the centralizing
                and the people who have  run  the central organization are  talented,
                interested,  and dedicated people.   If  they  are  not  interested and
                dedicated, they will not  work very well. I think that a lot of the feeling
                that people develop, the intense feelings toward centralization and away
                from centralization, depends a  lot   on their experience with  those
                services as provided.  If you are a centralist, you tend to have  had good
                experiences with centralization.  If you are fighting centralization by and
                large the reason might  be because there are managers of that central
                organization who really  are not doing their job.  They  need to  be fired,
                yet because they are in such powerful  positions, they can not be let go.
                My comment  is if you can attract quality people,  you  can do  it-either
                way; you can centralize  or you  can decentralize.  It would probably  be
                slightly more  efficient to  centralize than to decentralize with quality
                people.  You have to look at the ability of that central group to maintain
                its excellence  throughout  a long  period of time, because  once you
                centralize,  you  centralize.   As  soon as someone who is in a  position to
                establish a decrentralized kind of an organization figures out that he may
                be able to get some  more talent doing the job from a decentralized level,
                then that tends  to look more attractive.
                                            G-25

-------
                           PANEL H:  TOXIC SUBSTANCES
                                Chairman:  Ken Olsen
                               Panelists: Denise Swink
                                    Ernest Stalder
                                    Morris Yaguda
                                    Frederick Siff
                                     John Seitz
                                    Warren Muir
                                     Henry Lau
                                     OVERVIEW


                                     Ken Olsen

                              Office of Toxic Substances


      I think I will start by introducing the panel.  Immediately to my left is Denise Swink,
Office of Research and Development; then John Seitz, Office of  Enforcement; Morris
Yaguda, MIDSD; Warren Muir, Office of the Assistant Administrator  for Toxic Substances;
Ernest Stalder, Office of Toxic Substances;  and Fred Siff, Office of Toxic Substances.

      The panel was chosen  from  representative offices  that  are  on  a  performance
evaluation board on our TSCA  Information System Contract,  with Informatics.  Before we
get into details, I would like to provide those of you, unfamiliar with the Toxic Substances
Control Act, with background on this Act.

      The Toxics Control Act  was passed by Congress in late 1976, and became effective
January 1,  1977.   This legislation provides EPA  with the  authority  to  regulate those
commercial chemical substances  which may impose an unreasonable risk  to  man and the
environment.  The  dimensions of the  chemical industry suggest the  magnitude of  the
undertaking that  EPA  is now  facing.    The  agency  has estimated that  there  are
approximately  50,000   chemicals in commerce  produced   by  over  10,000 chemical
manufacturing establishments  which would  be subject  to this legislation.  We also have
estimated that  there  are approximately  1,000  chemicals  which  are introduced into
commerce each year.   The regulatory aspects of the  bill are  directed mainly at  the
chemical and allied  products sector of the chemical industry.  Pesticides, food, drugs, food
                                          H-l

-------
 additives,  and cosmetics currently regulated under  other  laws are exempt under the
 provisions of this Act. The information authority, provided by this Act to the agency, can
 be a vital source of new data upon which to access probable  risk of  chemicals in our
 environment.  Relatively speaking, only a small  portion of  the tens  of thousands of
 chemicals in commerce have been tested for long-term effects in laboratory animals.  As
 the number of recently identified hazards suggest,  we know  very little about the effects
 of many of the chemicals  which surround us.    The new  law provides EPA with the
 authority to require reporting of data the chemical industry  may have and to require the
 development of new data necessary to assess the  relative risks and benefits of existing
 commercial chemical substances.

      A significant feature of this legislation requires manufacturers of new chemicals and
 of significant new uses of existing chemicals to notify the administrator and submit data
 for EPA evaluation, 90 days before the manufacture of these chemicals or their new uses.
 EPA can, on the basis of this data, permit the new chemical to be manufactured or require
 that additional information be  supplied.  This  is a critical decision process which requires
 an efficient information system. While its mechanism is not a certification or registration
 procedure  for each new chemical about  to  enter commerce,  this pre-manufacturing
 screening provides  EPA with  the opportunity to review  and  take  action  to prevent
 hazardous chemicals from coming into the markets. The legislation provides a regulatory
 authority to  take  action  against  the  manufacture  and/or  the  use  of the  chemical
 substance, once a risk has been identified and substantiated. The law provides, however,
 that  before such regulatory  action  can be  initiated,  benefits  of  the chemical,  its
 availability,  adequacy of substitutes,  the economic impact  associated with such action,
 and the cost  of proposed  regulatory action must  be weighed against the projected
 chemical risk to human health in the environment.   I  would  like  to  focus on the
 information  authority within  the  Act.  TSCA  provides EPA  with  broad information
 authority to require manufacturers and processers  to report  specific information to EPA.
 These procedures must follow  the standard rule-making process  contained in EPA Order
 1006.  Other provisions of the Act direct EPA to share all information reported on TSCA,
 including confidential business information, with other federal agencies and departments
 and with TSCA contractors, and to create an integrated set of government-wide chemical
 information files.

      I  am  going to show a couple of  slides here to give you the  background  on the
 information reporting authorities of the Act. Section 4 required, through the rule-making
 process, manufacturers and importers of chemical substances to perform tests of those
 substances as EPA requires.  There will be a significant amount of test data reported to
 the agency  over  the next several years.  EPA has established a section for a work group,
 some of you may be on  it.  It  is broken down into various parameters.   Also, the inter-
 agency testing committee, under Section 4, has named 10 chemical substances, including
 some classes, for testing rules by the  agency within the  next year.   Let me explain
 something about  that. There is an inter-agency committee that has met since the first of
 the year. They just recently (late October) published a list of chemicals in  the Federal
 Register.  Under Section 4, the Administrator has to either promulgate a  testing rule
 within one year of that notice,  or show reason why he did not promulgate that testing rule.

     Section  5,  pre-market notification,  which we are now calling pre-manufacturing
 notification, will affect both  new chemical substances and significant new  uses of
 chemicals.  Manufacturers will be giving us information packages for each one of these
 new uses or new chemicals once the inventory is published towards the end of next year.
 The Act does not follow the logical order  of implementation, so we might be  getting  a
little ahead of ourselves here.

                                        H-2

-------
     Section  6  in regulations requires  us  to  keep  hearing  records  of  what  the
administrative law judges and of open public hearings, as we regulate specific chemicals.
The PCB's and f luorocarbons, and PPBB's are now being regulated under Section 6.

     Section  8  breaks down recordkeeping and  reporting into five major components.
There is a general reporting provision under 8(a) which is very broad.  It covers things such
as the chemical's usage, by-products, impurities, disposal methods,  estimates of persons
exposed, and  just about anything else in that particular area of epidemiological use or
economics.  The final rules of the inventory, to be addressed later in more detail by Fred
Siff, will be published in  the  Federal Register.   We are required  to come up  with  an
inventory of  existing  chemical substances in order to  identify exactly what  is a new
substance.  The Act also  requires manufacturers to report  adverse reactions,  employee
health,  or environmental  effects that they may be observing.   Under 8(b), Health and
Safety  Studies, we are preparing  a first  rule  for  the substances mentioned by  the
interagency testing committee in the Federal Register. Under 8(e), Notices of Substantial
Risks that require manufacturers to report to us any substantial risk of a chemical, we
have received about 25 of these since the  1st of  3anuary. These would primarily include
testing  information showing  adverse reactions.

     In addition to the required reporting authority, the Act has some unique  features.
Under Section 10 of the Act, Data Use and Dissemination, we are to establish and share an
interagency committee. That  committee is to deal with toxicological and scientific data
retrieval  throughout the  Federal  Government.   This  has  been  incorporated  into  the
Interagency Regulatory Liaison, which Warren Muir will discuss a little later.

     On data disclosure, the Act has a unique feature. It states that all health and safety
data is subject to release.   If persons  claim their  health and  safety study  is  to  be
confidential,  we go back  to them and tell them that, under Section 14, that  particular
piece of information is  subject to release.  They may  have to sanitize it somewhat in
certain cases, for example, if we are  dealing with a proprietary or trade secret  structure,
which would be disclosed within the test for safety data.

     Confidentiality is a  tremendous problem that we are facing right now, particularly
because of  the sharing  of information with other Federal  agencies and protecting the
confidentiality of that information.  We  have  been visiting other agencies and we have a
task force  on TSCA Confidentiality.  In  our  information  system  design, we  are also
emphasizing the feature of confidentiality.  It is one of the  leading if not  the leading,
design parameter.

     Under Section 21, any citizen can petition EPA to take any action under TSCA that
would fall under Section 4, Testing; Section 6, Regulation; or Section 8, Reporting.  That
area has not yet generated anything, but once it  becomes better known to the public, we
will get a lot more citizen  petitions.  CPSC get a lot more a year under their authority.

     In Section  25, in conjunction  with  HEW, we  are to  develop a Standards  Data
Classification System. This is  also being incorporated with the RLRG activities. Section
26 establishes an industry  assistance office for the purposes of looking at new, unique and
efficient  ways of  getting the  word  out.  We are  affecting  a tremendous number of
industries out there, especially when  we  get into chemical processors.  These sectors do
not look at the Federal Register.  We did a survey and we found that between 10 and 15
percent of  the people  affected read the Federal Register.   We are establishing an
automated mailing list for a direct mailing of proposed  regulations  to these people.  We
are looking at effective ways  of  getting the word out, so people  can comply  with our
regulations in a timely manner.

                                           H-3

-------
      The design and operation of an information system to support this legislation is an
 important and critical task. It would be simple on the surface to approach this problem by
 saying  that  the system  will contain  all available information  on  every commercial
 chemical substance. This approach is not feasible because of the vast amount of resources
 required, and the lack of justification on behalf  of the agency to build such an enormous
 system.  EPA simply does not need all available health, safety, and economic information
 on all chemicals to carry out effectively the mandate of TSCA.  The magnitude of this
 task,  together   with  the  associated  problem   of  data   collection,  processing,  and
 maintenance, may not get practical with respect to system design and operation, nor cost
 effective from a programmatic standpoint.

      In  order to provide  an information system  that effectively supports the TSCA risk-
 benefit, decision-making process, it was decided at an early stage to design the system in
 conjunction with the overall implementation  of the Act. The TSCA Information System is
 being designed as a principal component of  a Federal  data system that can be used to
 conduct risk-benefit analyses of chemical substances. There are several hundred Federal
 Government data sources for information on chemicals.  The majority of these sources
 deal  with  health and safety data.   The TSCA  system will support  the assessment of
 commercial  chemicals for potential regulatory actions,  from early  warning activity
 through enforcement  of  any  subsequent regulations.  It  also shall control and manage
 tracking features.   The planning and operation of the  TSCA information system  is and
 must continue to be an integral component of the overall TSCA decision and rule-making
 process.

      Focusing on the next items during system design:  First, reporting regulations must
 follow an open rule-making process.  The need for data must be developed using a standard
 rule-making  process, and involving the participation of Federal agencies and interested
 groups.  The second point is that agency resources to collect data, required on the part of
 the industry and government,  must  be justified relative  to the  uses  of that data.  A
 balance, between data requested and resources available to analyze and  take action, must
 be established.  Data that sits in a file without action is burdensome and goes out of date
 very  fast.    The information system must support  decisions on both existing and new
 chemicals.  The  information system is designed  to evolve overtime into a comprehensive
 data  base to support this.

      As we  get into analyzing risk-benefit in the development of TSCA strategy, we find
 that the decisions that need to be made and  the data that is required on existing and new
 chemicals are very similar. The TSCA Information System is an integral part of decision-
 making. The legislation provides the authority to write regulations to either require the
 reporting of  data or restrict the use or uses of particular commercial chemicals or classes
 of chemicals. These regulations and corresponding information systems are used to make
 decisions which will have significant impact on  the chemical industry.  These  are highly
 dependent  functions  which  may cross  organizational  bounds.   The  design  of  the
 information  system to be flexible,  modularized, and  be able to react very quickly as
 regulations, decisions, and the winds around  the agency change.  The effect of  control of
 chemical substances requires close integation of these functions, because of the variety of
 the situations that potentially exist for the agency. We must be capable of systematically
 reviewing the  universe of existing  commercial chemicals  to  determine which,  if any,
 require regulatory  actions, reviewing new chemicals or significant new uses  of  existing
 commercial  chemicals  to decide  whether or not  they should be  allowed  on the
 marketplace, and responding in a rapid manner to emergency and unanticipated  situations.
 Following these three major functions, the regulatory process for chemicals follows seven
steps.  If you look at the decision  process from the initial hazard evaluation through

-------
enforcement—whether it is an  EPA, a CPSC, or an FDA action—these  seven  steps are
fairly similar.   The initial hazard identification comes  in  through  citizen petitions, a
review of literature, or a detailed review of hazards. These determine whether additional
research or testing of studies  is needed. This would then be incorporated into a decision
package and  subsequent risk-benefit  analysis, which leads to regulations  and to eventual
enforcement.  Some of us may be involved with just one of these steps, but these are the
overall  steps as we see it. Converting these steps to TSCA activities breaks down into
input analysis and decisions.  Inputs would be triggers for actions,  such as studies by the
Federal Government, Inter-agency Test Committees and citizen petitions, pre-marketing,
pre-manufacturing, or other government regulatory action. These are the things that say,
all right, we should look at this chemical for one reason or another. We get into the data
evaluation or the analysis step,  or you may have to write additional rules  under  Section 8
or Section *f, into formal data disclosure,  into the analysis portion, and then finally, into
decisions.  Then every  time we make a  decision, whether it  is positive or negative
depending which side you are  on, we are required to put this into the Federal Register.  If
we decide not to take an action, we are to show the cause as to why  we did not take the
action.   Under Section 5, we  also are  required,  when  necessary, to publish  a list of
"unreasonable risk chemicals." This is the hot list chemicals, where we might be either in
the middle of an evaluation or it might trigger certain chemical classes, etc.  I think that
is far down the stream.  It is a very hot  issue to publish a list  of possible candidates
without writing any specific regulations.  You have Section 6 regulation and under Section
7, Imminent Hazard.  If there  is such a thing as an emergency situation, the administrator
can come in and wipe out this whole process, make a decision, and let the courts settle it
all later.

      Before  opening up the session to the panelist talks,  I would like  to talk about
background on our requirement analysis,  performed to date.  Back in 1974, when TSCA
was  still  debated in Congress,  OTS contracted with the National Bureau of Standards to
perform an information system  requirement  analysis on the proposed legislation.  This
document was the basis of an RFP,  issued in December, 1976, to design and operate an
information system  to process and disseminate  all the data  reported to  the agency as a
result of TSCA.  Last February, OTS, in conjunction with NLM (Nat'l  Library of  Medicine)
and CEQ (Council on Environmental Quality), conducted a study of a chemical information
system  to support  regulatory  decision-making.  This study  was performed under  the
contract with the MITRE Corporation. (Limited copies of that study are available through
my office.) TSCA was the focal point of much of this effort. EPA headquarter, regional,
and  laboratory personnel were  interviewed.  An extensive survey of available chemical
information  systems  within  the Federal  Government  was  performed.   The  study
conceptualized  the  idea of a global chemical  information  network as  a  10-year goal,
specifically with respect to TSCA.  The study indicated  that the existing major gaps  are
commercial chemical substances, primarily in the areas of economics and  use.

      Confidentiality could be the subject  of a three-hour discussion, but  I will mention
briefly  what  we are doing  in that area.   We have a  task force which has a very  broad
representation throughout the Agency.  We are developing specific EPA procedures for the
handling and  use of information throughout the agency, with agency contractors, and also
through other Federal establishments.  These are going to require people  who have access
to the information to handle it in a manner similar to what FDA does with information on
drugs. You will have a log book and document control officers.  You will  have to establish
your need to know.
                                          H-5

-------
                THE INTER-AGENCY REGULATORY LIAISON GROUP
                                    Warren Muir
      Last July,  the heads EPA, OSHA,
CPSC,  and FDA decided  to  initiate an
effort  to coordinate their    regulatory
activities with regard  to  chemical  sub-
stances.    Each of the  agency  heads
selected two individuals to  represent them
personally, and meet on a  weekly basis in
an effort and to scope out mutual areas of
cooperation  to pull together  a series of
policies and procedures.  This group of
eight  surrogates is  now  known as  the
Inter-agency Regulatory Liaison Group.
Subsequently,  10  regional groups   with
representatives  from  each of  the  four
agencies  and each  of  the regions,  were
established  and  are in the  process of
completing their work  plans  and under-
taking cooperative  efforts  at the regional
level.  There are also eight Headquarters
working groups in concerned with testing,
research, epidemiology, risk  assessment,
regulatory development, communications
and education, and compliance  with en-
forcement,   and, information  exchange.
Each of these eight Headquarters working
groups  has completed the development of
the  proposed work  plan  with a number of
short and long term projects.  A number
of  groups  have  made  significant  steps
toward cooperation. I will be speaking on
the  Information  Exchange Work Group.
This work group has a draft work  plan, and
will have a final  work plan within a week.
These work plans will all be published and
distributed  widely.   The work plan,  as it
now stands,  contains six major  projects.
The first, and perhaps the most important,
is an effort  to develop and agree upon a
common identifier  for  data files.  These
would  include four  different  types of
identifiers.    First, chemical  identifiers
such  as the  Chemical Abstracts  Registry
Number;  second, descriptive  code (unin-
telligible) for chemical  use;   third, is a
product code, such  as the universal pro-
duct  code,  which  is,  perhaps,   more
applicable to FDA and CPSC,  and the
fourth  will  uniquely  identify establish-
ments.   There are many many different
types of enforcement actions and enforce-
ment files reporting.  In order to  be able
to cross  reference the information,  one
needs to  have some kind of establishment
identifier.

      The subproject is broken down into
three phases.  The  first  is  an effort to
assess what  type of  unique  identifier
would be  the  most  appropriate  toward
which to be heading,  such as agreeing
upon  the  use  of  Chemical   Abstracts
number,  or the Dunn and Bradstreet esta-
blishment code, or whatever.  The second
phase is an effort  to assess the implemen-
tation timeframe and implementation cost
of   attempting   to   incorporate   the
multitude of files in  the  four agencies.
The  third  would  be  the  implementation
phase of all  those files, where it seems
feasible.

      The next sub-project  is in the area
of confidentiality, information  security
procedures.  In the  future, there will be
increased   cooperation   between   the
agencies  and toxic substances  area, and
that there will be exchanges of informa-
tion  among the agencies.   Certainly the
statutory authorities are moving  in that
direction.  T5CA  information legally can
be supplied to another agency with regula-
tory  interest  and  in pursuit of  their
official duties.  Similarly, FDA statutory
language  is  being  changed to  provide
information to us.  The concern  is how-
ever, that  if information is going  to start
flowing,  there would  have to be  some
agreed-upon, minimum level of security so
that the  agency providing the information
can be assured that the confidential status
of the data will be maintained.

      One  of  the more  difficult  tasks
attempted by  the IEG is the  sub-project
on  monograph planning  and  production,
which involves  joint-criteria  document
                                         H-6

-------
preparation.    There  is  a  tremendous
amount of overlapping  research  going  on
in the four agencies.  At a minimum, it
should  be  possible  to   identify  when
criteria documents  are contemplated  so
that it would be  possible for individuals
and  groups  starting  to  take  criteria
document development to being able to be
informed  as to who else might be working
on the same compound to coordinate their
efforts and share information.  The more
ambitious goals of this sub-project would
be  to  undertake three  or four master
contracts for criteria-document develop-
ment,  which would be jointly sponsored by
the agencies. Once it is  determined that
the criteria document is  necessary, there
would   be  an  appropriate  task  order
written  up,  and  a  criteria  document
developed in a  format    usable to  all
relevant  agencies.   That would be  an
extremely difficult undertaking, but it is
one explored  being for  each  of  the
agencies. The next two involve feasibility
studies  toward   two  data  information
systems that came out of the  series  of
needs  and recommendations identified by
contract report MITRE.  On the basis of a
survey of user  needs of  toxic substance
and   chemical    information,   MITRE
identified 10 types  or  10 data system
requirements, and made recommendations
for these data systems.  A number of the
systems are already under development,
being  contemplated,  or in various stages.
There   were two  that  were not  being
addressed  but   which  had   particular
regulatory  agency   significance.    The
Office of Toxic  Substances,  with  some
year-end  funds, provided  the IRLG  with
same funds for the first phase—feasibility
studies on  these two  data  information
systems,  presently  underway by SIGMA
Data Corporation.   One  of  the  systems
would  allow agency personnel, industry or
other  affected  parties  the  ability  to
identify which regulations, laws, and court
decisions,   are   applicable   to  their
particular  chemicals.      This  would
presumably  have  references   to   the
appropriating Federal Register, Code of
Federal Regulations, or  U.S.  Code,  and
would   provide   the  system  user   with
abstracted information,  or refer to the
primary source.

     The second is really not a data base,
but a software package,  for toxicological
data analysis, which would be  available
primarily to two types of users.  The first
would  be testing  laboratories,   govern-
mental  or private  industry,  conducting
toxicological testing.  The system  would
support tests for  a maintaining data.  It
would allow the experimenter,  during the
progress of the experiment  to do  some
short-term analysis,  analyzing  the data
and at  the end of  the experiment  to  be
able to  prepare a machine readable output
which   would  be  submittable  to  the
regulatory  agencies.     The   software
package would also be  valuable  to the
agencies that receiving the raw data. The
Office  of Pesticides,   receives a tre-
mendous amount  of toxiological data for
registration process and it is  envisioned
OTS will be  receiving  similiar amounts
which  means the  toxicologists  will  be
presented and analyzed in many forms. It
may be  that  the  submitter has lumped
together  the  white rats, the males and
females,  it   analyzed   the  data   using
certain statistics, and come out with their
results, it is just a mammoth task for the
reviewer to sit down and try to figure out
what  the  results  would be if you had
separated the black mice from the white
rats, analyzed the  data  etc. forth.  This
particular software being developed would
to allow  the toxicologist or reviewer to
aggregate the  data  differently,   apply
different statistical tests, to  verify the
conclusions.  A system which meets many
of these needs is now under development
at the National Center  for Toxicological
Research  and this feasibility  study  is
investigating the extent  to which it meets
the needs of the four agencies.

     The last of the sub-projects is in the
areas  of  reporting  and  recordkeeping.
This is  one of the areas which kicked off
the IRLG.  There  was  concern  that the
regulatory agencies were not getting their
acts together, were requiring duplicative
reporting,   and    (unintelligible)   their
                                          H-7

-------
recordkeeping requirements.  There is one      at Headquarters and  the regional  level.
last project under consideration which I do      This  summarizes  the  information  ex-
not believe is as yet in the work plan, but      change activities.
will be in the area of library cooperation
                                        H-8

-------
                  FEASIBILITY STUDY ON INFORMATION SYSTEMS
                                   Morris Yagada

                          Management Information and Data
                                  Systems Division
     The MITRE  study  has  been briefly
mentioned.  It is a foundation  document
which  presents  a  basic  analysis of the
information requirements and  an inven-
tory of existing sources of a ten-year plan
to develop ways of understanding how to
use existing and new systems to meet the
defined requirements.   One of  the key
features of that ten-year blueprint is the
idea of a network.  The system is called a
Chemical  Substances Information  Net-
work.  It is not a  system where you have
applications tied together by communca-
tion lines or under central  management.
Rather it  is a  planned use  of  many,
individually managed systems, as they try
to meet the complex information needs of
the  program.   There  were 10  systems
identified  as core  components of  this
network.  Sigma Data was hired to take a
look at these and to carry the analysis and
the planning one step further,  and try to
look at  implementation  alternatives for
achieving some of the system capabilities
that were not being developed  elsewhere.
That study, at this point, is in a final draft
form.

     The MITRE study focused on several
items.    It focused  on  the  data  base
directory, the Chemical Structure Nomen-
clature System,  Chemicals in Commerce
public  file, the OTS confidential file, and
the general security  situation.   Security
pervades everything that OTS is doing at
this  stage.   Industry is  very  concerned
about the fact that they are  giving us the
keys to their operations; these must  be
protected.

     Regarding  the Chemical  Data  Base
Directory, this is  the system designed to
answer the  question as to which files in
the network have particular  kinds of data
information.   It  is a directory of  data
elements. For instance, you could ask the
question,  which  files  have  production
volume?  Or, which files have marketing
information?  Or, which files have certain
combinations of data elements? Once you
have found out which files would satisfy
your request, you could then ask to see all
the data  elements in the files in order to
see if  these  are  the  ones  needed.   You
would also get some information about the
scope of  the  data, how current it is, and
how specific it is.   You would  also get
information  on how to access that  file.
Sigma  Data  looked  at the question of
whether  this  could  be  implemented in
manual form or automated, and presented
pros and  cons on both alternatives.  They
did not make any particular recommenda-
tion.  The National Library of Medicine is,
however,  very  interested  in  building  a
central file.   They  would establish and
maintain  it  as  part of  the  Chemline,
Toxline family of systems on the National
Library  of  Medicine  computer.   They
would   also   make   that   information
available to anyone  else who wanted to
use  it as part  of  any other system or
systems,  in computer or  manual form.
Initially,   it  would  focus   on  the  files
identified as part of the Chemical  Sub-
stances Information Network, but it could
be  extended  beyond that if that proved
reasonable.

    The second  core  component in the
MITRE study is the  Chemical Structure
Nomenclature System. The basic purpose
of this system is to help answer questions
where  you do not know all of a chemical's
name or chemical structure, or you do not
know its standard CAS Registry  number,
or its standard CAS Registry name?  You
may also need technical data associated
with the  chemical. You would also like to
know what files have information about it.
                                        H-9

-------
You would like to be able to point to or
identify a standard identification data for
your chemical.  This is also a directory-
type file.  The first direction mentioned
above was ordered by data elements, this
second directory is by specific chemical.
There are two systems in existence that
approach  the idealized  requirement  for
this kind  of a system.  One  is Chemline,
operated by the National Library of Medi-
cine; the  other is the Chemical Informa-
tion System operated by EPA and  NIH.  I
think some of you may  have been  present
yesterday  in  a  panel  - we  ran   in  the
morning.  There was a presentation given
on the EPA Chemical Information System.
Those systems need some changes to meet
the  idealized  requirement.   In terms of
the  Chemical  Information  System,  our
office  is  presently  doing a  management
and technical evaluation  of  that  system.
We are developing  short-range and long-
range plans for improving  it, making  it
more flexible, and easier to  use.   The
National Library of Medicine is also going
through  some planning  steps, trying  to
make their system  more comprehensive
and more powerful.  One  curious  point  in
the  MITRE study is that they suggested
that these two  systems  come   at  this
idealized  requirement from two separate
directions.    One  is   the  scientifically
oriented  user-community.    The other
serves  a library oriented user-community.
If  they  met  the  idealized  requirement,
however,  both systems would eventually
evolve  into  something that  would look
very similar.  MITRE thus  proposed that
we should be looking at the feasibility of
these two systems merging  and becoming
one.  That alternative is also receiving
serious  thought.  One thing that  we are
doing in  that vein  is  that  managers of
Chemline and  CIS  are  talking to  each
other.

     Chemline also has this pointer con-
cept. Once you identify your chemical  in
Chemline through a name entry, it does
point to  several other files.   They would
like to have the wider set of pointers that
CIS has.  We  are  cooperating in giving
them  our pointers, and they  are  cooper-
ating  in  giving  us their  pointers  to
Toxline.  I would like to mention that OTS
is  presently using  both  systems.   For
instance,  the  CIS system  was  used  to
generate the initial  TSCA candidate list.
There  are three core component systems
defined  as   related  to  in-house  OTS-
operated  systems.   One  of  them is the
TSCA  Proprietary  File  organized  by
chemical. It contains all the information
that gets reported to the Office  of Toxic
Substances in regard to chemicals,  some
of which  are claimed to be  proprietary,
some of  which  are not.  There would also
be a file containing information  on  esta-
blishments, and which would keep track of
which  establishments  are   supposed  to
make certain reports, the status of that
reporting activity, and whether they have
complied  or  not.  There  would also be a
third OTS file  which would  essentially be
an  extract   of  these   first  two  files,
extracting all the information that is not
confidential, the information  that would
be made public. It could be referred to as
the TSCA public file.  There is one last
thing that I would like to mention in terms
of the Sigma Data report, and that is that
it  has  attempted to identify  functions at
the proposed division level at the Office
of Toxic Substances.   It  looks at the
functions of these divisions and it looks at
the information flow through each division
in order for it to do its job.  It shows
interactions    between   divisions,   the
Federal  Register,  industry,  and various
members  of  the  10  core components.   I
suggest that this particular  part of the
study would be  interesting. Again, I would
recommend  reading  the MITRE study and
the Sigma Data study for those who are
interested in learning about this program.
                                         H-10

-------
         INVENTORY INFORMATION IN THE CHEMICAL ABSTRACT SERVICE
                                  Frederick H. Siff
     To prove that we're getting into the
operations  aspects, I have  the honor of
showing you the first flow chart of the
morning,  which  I  hope  will  show  the
processing  of the inventory  that will take
place at the Chemical Abstracts Service.
Both  Warren  and  Morris have  given a
global  view of some of  the information
requirements, not just those of the office
of Toxic Substances within  EPA, but the
total Federal  Government's requirements
for chemical information. At the heart of
the Toxic  Substances  Control  Act, how-
ever, is  the  requirement to define the
universe of existing commercial chemical
substances.  This is  the necessary first
step so that pre-manufacture  evaluation
of  new chemicals  can be  performed by
EPA. This is one of the strongest parts of
the Act  itself.   Thus, the Act requires
EPA to compile, keep current, and publish
a list of each chemical  substance  manu-
factured in or imported  into the United
States.  This  list is the  foundation upon
which all toxic substances control will be
based  and  from which   the commercial
chemical information system will be built,
eventually providing one of  the important
building blocks or modules   in the wider
chemical  information  network, to which
Morris has referred  as  suggestions  that
came from both the MITRE  study and the
Sigma  Data study.   The  initial inventory
rule was proposed sometime last summer.
It had, as its basic thrust, the develop-
ment of a list of chemicals  in commerce.
In  the early  stage,  once  the Act  was
passed,  we entered into  a  contract with
the  Chemical   Abstracts   Service,  a
Division   of  the  American   Chemical
Society, to develop the list, making use of
both   their   information   processing
capability  and the  wealth of information
that they  have  on commerical chemical
substances   and   research  substances.
There  are  more than 3.3  million  sub-
stances   in  the  file  of   registered
chemicals.  It was  recognized  early on
that to develop this initial list of chemical
substances we needed to start with what
we  refer  to now  as the candidate list,
which lists all substances that  we think
are in commerce.   Rather than have all
manufacturers report what they make in
their  own style, we thought  it  would be
best to have a  candidate list or a draft list
of the inventory that manufacturers could
report against. Many sources were used
to develop this file.  These are some of
the Government sources used  to compile
the candidate  list.   Some of these were
processed   at  the  Chemical   Abstract
Service  under  an existing  contract  that
MIDSD  had with them.  Some private,
non-government, source files were  also
used to  produce the candidate list.  A  list
of some 33,000 substances were developed
as a computer  data file and then published
in a hard-copy three-volume set of some
2,200  pages.  Chemicals were  listed in
three  ways;  namely,  by the  Chemical
Abstracts  registry  number, by  formula,
and by the preferred Chemical Abstracts
nomenclature.    This   will   reduce  the
reporting volume that we expect and also
increase  the  accuracy  of  the  final
inventory  list  that will  trigger the other
components of  the Act.     This   was
published in June and can be acquired by
calling  Ken.   In  addition,  the  list is
available on several computer timesharing
networks.  It is available on Chemline. It
is  available   through   the   EPA/NIH
Chemical   Information  System.      In
addition, manufacturers have been given
the opportunity to get a computer tape of
the candidate  list against which they may
process  their  own files.  The  use of  a
candidate  list reduces  reporting volume,
because    manufacturers,    if   their
substances are on  this list,  need  only
report the line number given in the list
and check digits within  the candidate list.
They  can  be processed  very  rapidly with
                                        H-ll

-------
 the Chemical Abstract Service, and the
 processing flow  works.   Regarding the
 TSCA reporting forms, there are a variety
 of forms  developed  to report substances
 that are either on the list  or not on the
 list, or substances that cannot be uniquely
 identified. The latter form  one section of
 the candidate list, the UVCB section.  The
 forms  are currently being  printed.   The
 revised   inventory   regulations   are
 currently  awaiting signature by the Ad-
 ministrator.  The processing flow actually
 has been  developed for  several months.
 The report forms  will be  mailed directly
 to Columbus, Ohio,  where  the  Chemical
 Abstracts Service is  located, and then the
 processing will   begin.   The  reporting
 period is a four-month period beginning in
 January (this assumes  that  that the cur-
 rent regulations  are signed  off before
 then).  We have made some estimates of
 the total  volume of reports that will be
 received.  It  is very difficult to determine
 how many commercial chemicals are man-
 ufactured and  how  many manufacturers
 will be reporting  them.   We have  esti-
 mated,  however,  that  there  will be  a
 maximum  of  some 300,000   different
 reports that  will come  in.  These are
 reported substances, and there  may  be
 duplicated substances.  The  Act  originally
 required that the  final  inventory list be
 available  for  use  by  the  middle  of
 November of  this calendar year.  Due to
 the reproposal  of the inventory  regula-
 tions it will  not  be available  until the
 middle of November next year under the
 revised schedule.

      The  input  processing  will  be per-
 formed at the Chemical Abstract Service.
 The  Chemical   Abstracts  Service   will
 develop a  plant-site  file and also a sub-
 stance  file.   The  substance file will tie
 into  the  CAS  Registry   System,   and
 substances which are not currently within
 the   CAS  Registry System   will   be
 registered.  Substances which are reported
 merely  by the  name or   formula  will
 nevertheless  provide  access   to   the
 synonyms and connection tables which are
 available  within  the CAS system.   The
output  will be  the  inventory  packaging
which will then result in the printed TSCA
inventory.  I will not get into the timing
or how long it will take to process some of
these forms, or the variety of problems
that may result if the flow is greater than
we anticipated.

   The  inventory   work   group   that
developed   the  inventory   regulations,
chaired  by  Cindy  Kelly  of OTS,  has
worked closely  with  us  and  with  the
Chemical Abstracts Service in developing
regulations which would both reduce the
processing burden on industry and increase
the integrity and accuracy of the informa-
tion.  We have been involved in developing
the forms which are being used to support
the  inventory, and also  the assistance
services   that  will  be   provided   for
reporters.  I  mentioned that the inventory
list itself is available through three widely
available   timesharing   services.     In
addition  to  hard  copies  and  computer
tapes,  there will  be  training  services.
There is an instruction manual for how to
report under the Act, and there will be
training  programs  developed  in   the
regions.   Regional TSCA  Data officers
will  work  with  reporters  within   their
regions.  Forms have been made as simple
as possible to fill out,  particularly if the
substance is  on the candidate list. This is
an overview  of the inventory.  We  would
expect  that  processing  will  begin  well
within the four-month reporting period.
By the middle of the summer, we  would
expect  that some  90   percent of the
inventory would  be established and made
available within  EPA.  Most of the sub-
stances on  the candidate  list  should be
reported as  manufactured  and processed
by mid-summer, and then made available.
The  inventory leads into the wider  role
placed on  the information  system  com-
ponent  within   OTS.     The  inventory
describes what is  in the  universe,  plus
provides  a little additional data on site
and production quantities. We are viewing
it as a card catalogue  to some extent
within the  Office.   It  will provide  the
definition of substances.  There will also
be additional information collected  under
the Act, primarily  through the mechansim
                                         H-12

-------
                                 r^
of   pre-market   reporting,   and   8(a)      system, the industry, and commerce infor-
reporting regulations.  The inventory then      mation system.
will  feed into  the  larger  information
                                          H-13

-------
                           THE INFORMATICS CONTRACT
                                    Ernest Stalder
      I am going to talk about the Infor-
 matics contract that OTS recently signed.
 I  will cover five different  points about
 that  contract;  namely,  the   purpose,
 contract type, the mechanism under which
 it was signed and  will be executed, and
 the kind of work that Informatics is now
 doing during the initial period. I will talk
 about how we are planning to manage the
 contract activity, and finally, I  will talk
 about the  present status  of  the work and
 immediate plans for the future.  There are
 two  main  thrusts  and general  areas  of
 activity  in the contract.   The primary
 purpose is mandated under Section 10b(l)
 of the Act, which requires an information
 system  to  be  developed to collect and
 disseminate data that is  reported to the
 administrator under the authority of the
 Act.  The first major thrust is the design,
 implementation,  and  operation  of  a
 system to manage TSCA data. The second
 major activity  is  to  provide a level  of
 analytical support for the decision-making
 process that will use data reported under
 the Act.   There is, under  the five-year
 contract, up to 30 man-years of analytical
 effort allowed.  The analytical effort will
 allow the analysis  of TSCA  data in com-
 parison with other data  sources;  trend-
 forecasting;  evaluation of the impact  of
 proposed  data  collection  regulations  on
 the   chemical   industry.   The  contract
 activity  is intended  to  supplement the
 analytical  resources of OTS, since at the
 time  we went out with the RFP,we antici-
 pated that there would not be an adequate
 number of  internal slots to carry out this
 activity.

      I want to say a few words about the
 contract type.   This contract is a  five-
 year,  cost-plus  award-fee   contract,  a
 rather new mechanism to EPA.   It has
 been  used  by  NASA  and perhaps  other
agencies.    What  it  means  is  that the
contractor  is paid for his cost, plus a base
fee,  plus an  incentive fee.  In this case,
the contractor gets costs  plus 2 percent
profit, plus from 0-12 percent of his cost
awarded to  him solely at  the  Govern-
ment's discretion, a unilateral decision on
the basis of  the  Government's evaluation
of his  performance.   The  contract  is
broken  up into  performance  evaluation
periods, in our  case  every four months.
We assign to the contractor at the begin-
ning  of each period, certain work  areas
that  we are going to emphasize within the
scope of work.   The  contractor  will be
evaluated on his performance  on  these
categories, and  awarded a fee based on
that.  The system  users  are required  to
submit  performance  evaluation  observa-
tions throughout  each period. The obser-
vations don't have a fixed  frequency, but
can  be submitted often or  infrequently.
Of course, they have to be submitted  at
least once each  period. The performance
evaluation  observations are  reviewed by
the evaluation coordinator.  In this case
he is the project officer, and will add his
own  comments as to whether the observa-
tion  in  his opinion  was correct or incor-
rect.  A package is put together for the
Performance Evaluation Board, consisting
of people  who  are  supervisory to the
performance monitors, who will determine
whether or not  contract deficiencies are
due to contractor default or  due to  EPA's
faulty direction.  The Performance Evalu-
ation Board makes  a recommendation for
the level  of  fee to be awarded  based  on
the performance observations.   The Fee
Determination Official  then makes the
final decision as to what  the award will
be.

   We  are now in  our first performance
evaluation period.   There are four cate-
gories of work activity in this period. The
first is initial system development,  and is
broken  down into  three  areas,  overall
system design,  inventory  system,  and a
                                        H-14

-------
feasibility  study  of data  needs of  the
Office of Enforcement under TSCA.   In
overall   system  design,  the  contractor
reviews  the  previous  Sigma Data  and
MITRE studies.  He is to develop perfor-
mance  specifications for  the  systems,
various ways  of  implementing these per-
formance specifications in terms of hard-
ware configuration, and  what  software
would be  used.    He  will  present  the
implementation options  to EPA for con-
sideration.   The  second activity  is  the
inventory system.  This is the first system
that will be developed under this contract
and is envisioned as being the central core
of  the overall TSCA information system.
The first task that I talked to you about
was overall system development, and how
the various  pieces are going to be  put
together.   One  of the  pieces  is  the
inventory system.  There are a number of
magnetic tape files that will be generated
by  the Chemical Abstracts Service (CAS)
that  will be provided to Informatics who
will manage and provide access to those
files.  CAS is creating the  inventory data
base but is not providing search services.
Therefore, Informatics will be required to
design   a  system   to  process,  manage,
update,  and   provide  both  public  and
private access to data collected under the
CAS inventory contract. We envision that
the data  collected  under  the inventory
will  constitute a  core  record,  and  will
provide  a  central  reference  to  whatever
other sub-systems  will  be needed under
the TSCA  information system. Other sub-
systems may  be  for regulatory,  testing
regulations,  citizen petitions, and health
and safety studies data.

      Our  third activity is the feasibility
study of  data needs of  the  Office of
Enforcement  (OE) under TSCA.  One of
our next speakers will be  addressing that
in  detail,  but at  least one need  is for
production data  which will be  collected
under the  Act. The feasibility study will
examine methods of providing needed data
to  OE, whether it be as part of the TSCA
information  system or  a  separate  OE
system.
   The  fourth area at which Informatics
will be  looking is data risk analysis, to
examine and identify threats to data loss,
data modification,  or unauthorized  dis-
semination,  identify  the  probability of
occurrence of these events and compute
what  the  cost of each event  would be.
Information will develop several levels of
risk reduction and identify the associated
costs.  We have a subcontract with Com-
puter Resources  Coorporation,  who  has
been doing some  work for  MIDSD under
the COMNET contract, to provide  us with
guidance on cost/benefits of risk reduc-
tion and an  overview of risk analysis. Of
course, there is also an interface with the
TSCA  Security  Task  Force,  which is
focusing on security of manual data.

   Another  activity under this first four-
month  period  is  support  to rule-making
groups.   This is  on-demand work which
will  be  focused  on  data formating  and
representation, and analysis of the impact
of proposed regulations  and  trendfore-
casting.

   Finally,  the  last  activity  under  this
first four-month period is project manage-
ment. That may seem redundant, but  it is
contractor   resources    expended   on
management of the contract,  to assure
adequate  resource  control  in  terms of
hours and dollars; providing online inter-
face  wtih  the  project   officer;   and
identifying problems at an early stage and
taking corrective actions  in a  responsive
way.  After this first period, when ade-
quate  controls  have  been established,
there probably  will  be  little  need to
continue project  management as  a task.
Regarding  in-house project management
staff, we  have a project officer  and  two
other persons assigned  full-time.    As
needs develop in specific subject areas,
other persons will be rotated in and out.
                                         H-15

-------
                                 CONFIDENTIALITY
                                    Demise Swink
      What  I want to  discuss with you is
 activities  of  the  Confidential  Material
 Task Force, established a couple months
 ago.  The Task Force is developing  pro-
 cedures for handling confidential material
 collected  under   the   TSCA  reporting
 requirements.  One of the first things that
 came up  in the Task Force  deliberations
 was that, even though the MITRE Study
 had been done, it had  been six months to
 nine  months  since  people  discussed  the
 kinds of TSCA information of interest to
 them  and  required methods  of  access.
 Consequently, the Task Force executed a
 Agency-wide  information needs  survey.
 First  of    all,  we  had  a  tremendous
 response  and we  really appreciate it.  All
 the research  laboratories responded  and
 ail  of  the  Regions.    There was   one
 response  from each research  lab and two
 responses from each of the  Regions,  one
 from the TSCA coordinator and one from
 the enforcement coordinator.  We began
 by asking in this  way what specific infor-
 mation   each   organization   would   be
 interested in.  Data items included were:
 chemical identification,  company name
 and  address,  production  volume,   by-
 products, import/export, health and safety
 studies,  molecular structure,  plant  site,
 process, categories of use, exposure data,
 common or trade name, types of activity,
 site-limited    chemicals,    method    of
 disposal,  and test  data.   The Regions
 generally  said  that they  have  a  high
 degree of interest in all  the  data, parti-
 cularly  with   100 percent  response  of
 interest   in  chemical    identification,
 company  name and  address,  production
 volume, by-product, processes, common or
 trade name, and  method of disposal.  The
 research   lab   responses   were   quite
 different  because  their  interest in  the
 data is specific to the kinds of  research
 performed  at  their  labs.    All  of  the
 research labs did  report a general interest
in  chemical  identification,  method  of
disposal, and test data.  The next  thing
that we  asked in the  survey  was,  what
would be your selection criteria?  If this
information system  was  available,  how
would you  access  the  information?   The
regions  generally responded  that  they
would  select   most  often  by  specific
company name or by single chemical.  The
research labs  responded that they would
select   information   mostly   by   single
chemical.  Other selection  modes  were
identified,  such  as  by regions,  generic
chemical groups, plant  sites, and river and
air  basing.  Now as far as accessibility to
the information, 8 of the 10  Regions feel
that they need continuous access to TSCA
information with a very strong interest in
a capability  for  immediate response to
requests.   Sometimes 24  to  48 hours
turnaround   response    to   information
requests  will  be  acceptable  for these 8
Regions.   Two of the Regions reported
mostly 24-hour to 48-hour responses, but
they did state  that from time to time they
would  probably  need, for   emergency
situations,  an  immediate  response to
requests.   Twelve  of the  15 research
stated labs that  they would need  only
occasional  access to  the information, and
that a  48-hour  turnaround  mode would
generally  suffice.  Two of  the research
labs will need  continuous access but not in
an  immediate  response mode.  Another
four research  labs stated the  same thing
as two Regional offices, that we will  need
information occasionally, but there will be
certain sutuations such as  emergencies,
that  we  will  need to have  immediate
response to request.

     The  reasons given  by the  Regions
regarding  use  of  the  information  were:
implementation   of   TSCA,   including
investigation  and enforcement;  response
in   emergencies;   planning   strategies,
including   pre-determination  of  problem
areas and  preventive measures; execution
of   surveys,    monitoring,    and    risk
assessment; establishment of priority and
                                         H-16

-------
contingency  plans;  NPDS  requirements;
issuance of permits; characterization of
the region in general; and development of
regulations.   The  research labs reasons
were that they  needed  the information
for:   design  of health  studies; industrial
assessments for R&D of Pollution Control
Technology;    design   of   experiments;
ecological effects testing design of hazard
evaluation programs; assurance of proper
storage   and  adequate  protection  of
personnel  having  access to materials in
the  lab; development of  identification or
measurement  technique;  application  of
measurement techniques; and source and
characterization,  transport and transfor-
mation studies.

      As  you  can see,  there are varying
degrees of requirements for access to and
use  of  the information collected under
TSCA.  The task  force  will analyze the
feasibility   of   continuous   immediate
access,   distributive   processing,   and
terminal access.  One thing the task force
did find out through the services is that
there will probably be  many requests that
will  be  able  to  be  handled  by OTS
headquarters.   Requests could  be sent by
registered mail within  a couple of days to
the  field offices.   There has  been  no
policy   decisions   whatsoever   on  the
mechanism to get the information out to
the field offices.  The determination has
to be made of what consitute the need to
know and what kinds of mechanisms from
a  security aspect  are acceptable.   The
driving  force  of  all the policy decisions
will  be maintaining the integrity  of the
confidential material being reported under
TSCA.
                                          H-17

-------
                            QUESTIONS AND ANSWERS
Ken Olsen:      First of nil, I want to thank the panel.  I really appreciate the fine talks
                that were given.  It is an awful lot of  information to try to cover in a
                short period of time.  They did provide you with an excellent overview of
                all the  activities, not only our  long-range  plans, but  our immediate
                implementations.  This slide ties it together for FY  78.  There are three
                basic components on which we will focus in  or around October, or  the
                start of FY  79.   The first is TSCA inventory, publishing the final rule
                sometime in early December.  Second is the completion of the processing
                system design.  Fred mentioned that it was complete.  But, there have
                been a few minor  changes in the regulations as well as in Form D, which
                has voluntary reports of product trademarks containing those chemicals
                that have been reported for the inventory.   Thus their  processors will
                have some assurance that what they are buying  will  still be on  the
                inventory often a chemical company will sell a chemical under a product
                trademark without the customer knowing what is in it.  The reporting
                period is scheduled from the 1st of January through the  second  of May,
                120 days.  With the unknowns  we are still projecting form processing to
                be complete early in the fourth quarter  of FY  79.  We will be spinning off
                a file sometime this summer.  We will transfer a file of information from
                CAS down to the TSCA information system  into the inventory module
                pilot.  That should contain 75  to 90 percent of the information reported
                under  the inventory.  It will not  be a  complete inventory listing.  The
                Office  of Enforcement has discussed this with us, and we were able to
                make this Modification to our  schedule in response to  their needs.  The
                confidential handling procedures are there as well, and in order to make
                this partial inventory operational throughout the agency,  we will have to
                evolve  an EPA order for the handling of confidential information. That
                information can be properly transferred to the user groups.

Question:        I  have a basic question on your current and future staffing of your ADP
                contracts.  First  of all do  you have any staff on board right now that
                work with you full-time?

Answer:         In the Office of Toxic Substances, the Assistant Administrator,  Steve
                Ellinek, has proposed reorganization to the Administrator.   We will be
                working within a  Chemical Information Division, a parallel division to
                Hazard Evaluation Testing,  and other divisions that are established.  The
                information division has been given equal authority with all of the other
                divisions.  The ceiling for that division  is some place in the  30's.  I don't
                know whether it is 31 or 39, but it is some place yet to be finalized. We
                do have  on board now a  staff  of 17  people, including two full-time
                computer systems analysts, several program  analysts,  some information
                specialists, and four chemists - chemists that are particularly interested
                in chemical nomenclature,  chemical information, and rulemaking.  The
                size of the CAS contracts, I believe, is about $420,000 to compile the
                inventory  over a  two-year period.  The Informatics contract is a $3.1
                million over a five-year time frame.  We have a  few smaller contracts.
                The minor contract was around $80,000. The  computer resources control
                on computer  security is  $10,000 and there  are a few things in the
                planning stage.
                                        H-18

-------
Question:
Answer:
Answer:
Howard Howell,  Program  and Reporting  Division.   Please try to fit
together the ILRG  with the inventory with CIS.   How  do all  these
systems interrelate overall?  It seems like an awful lot going on here, as
TSCA would probably require anyway.  How are these pieces going to fit
together in a meaningful way?

Our  system is strictly in response to rulemaking, and we have now  a
schedule for the publication of the inventory.  The ILRG may want us to
get into some  of their schedule.  I do not believe  they have  finalized
some of their schedules in the information exchange group yet, but we
are still working in the work plan stage. A lot of what we will be doing
under  TSCA, particularly  in  the  inventory and in the  confidential
handling, would be of great value to ILRG. Some of the things that the
ILRG will be doing, we will be able to work along with and  benefit from.
Warren, do you want to get into some detail about ILRG?

There are two  ways to cut  this thing.   A number  of the ILRG activities
are  an effort to  develop common  approaches, common  identifiers,
common  approaches  to  monographs,  maybe even single  monograph
productions,  and so  forth, coordinated reporting,  recordkeeping activi-
ties.  I do not think your question really goes to that so much  as really
the question about the systems development activities.  How are  these
linked together with  the Office of Toxic Substances and other activities
around  the Federal Government?  The MITRE contract, lays out their
vision of a future Chemical Substances Information Network, as Morris
described with the 10 core components.  Two of the  10 core component
systems are TSCA generated, one being the proprietary data base which
includes all of the data under TSCA.  The other is the public portion, the
non-confidential portion of  it.  Two of the 10 are those being developed
by the ILRG which have feasibility studies dealing with the data analysis
and  the  ability  to  identify applicable  regulations with  respect to
individual chemical substances.  Others include the  directory activities
that Morris described, which are basically  various file and data systems
descriptors  in  terms of  data  elements.   Another   is  the  whole  sub-
structural search capabilities, again that Morris described.  Most of the
others related to bibliographic and other types of data systems which are
available or in latter stages of development through the National Library
of Medicine.  These  are some of the  10 core systems.  The hope and
thought would  be that an individual user  in any  particular agency will
have access to these  10 independently  managed data systems so that, to
the maximum extent possible, common identifiers will be incorporated
into their files.

The MITRE contract, sponsored by the Office of Toxic Substances, the
National  Library of Medicine,  and   the  Council  on Environmental
Qualities, serves as an informal vision on this whole activity.  There is no
specific, master, Federal time frame or development plan. I think that
the concept  has  been generally endorsed  by the  various  agencies that
have reviewed it.  The ILRG, the National  Library of Medicine, and OTS
are making  every effort to move the  development of their  components
along as quickly as possible. They are each operating on slighly different
time frames.   Concerning ILRG activities:   we are having feasibility
                                        H-19

-------
Question:
Answer:
Answer:
studies  on  these  two  activities done  in  approximately  six  months,
depending upon the nature of the follow up activity that is required. I do
not know how long the implementation -will take.  There  are, of course,
the contract procedures which need to go through.  We have been very
fortunate  to use the very rapid contracting procedures that the Council
of Environmental Quality has available to the multi-agency effort,  and it
has been a  multi-agency effort  with the National Library of Medicine,
CEQ, and others participating in the support of these activities.  Once
one  gets into the implementation phases  on specific agency files and
when an agency has got a lead on developing and implementing particular
systems, one is almost certain he will be operating through the agencies'
own procedures. In closing, we do have a very close relationship between
OTS and ILRG.  We  are implementing our systems in accordance with
their philosophy, so eventually when this thing does come  off, no matter
what timeframe it takes, it will be compatible.

My  name is Robert  Greenspan  and  I am  with  the Office of  Water
Planning  and  Standards.   I have  a question  about  environmental
monitoring  data.   My  question  is how   does  OTS anticipate  using
environmental monitoring data,  if at all, under TSCA or other legisla-
tion? How much data do you intend to use? How often?  From where do
you  intend to get it?  Do  you  get it yourself?  Do you get  it  from
someone else?   How  do you intend to interchange information to allow
easy access  to environmental monitoring data?

That is a big order.  Let  me say one thing about  the  Act. The Act.
states that if any sort of a regulatory action is needed it can be taken
under an existing piece of  legislation, such as FWPCA or any other act.
The  regulation should be written under that Act.  We're only kind of
filling the big crack or void in-between. Under my group, we have a sub-
group. Our  subgroup is looking at networking within EPA and with other
systems outside of EPA.  We are addressing the monitoring problem. I do
not know how far we are.

You want us to ask what is likely to happen with respect  to  toxic
substances monitoring. One question that comes up in the whole area of
toxic substances monitoring is: what is a toxic substance?  Is So2 in the
air a toxic substance?  The definition of the chemicals  with which  we
become concerned is a very dynamic kind of thing. It changes over time.
The  chemicals  of concern in  1971 have been rapidly expanding.  The
other question that I will have to ask is what type of monitoring is likely
to be done strictly in the toxic substances context.  Are  we going to be
thinking in   terms  of  doing  anticipatory  monitoring,  going  out and
monitoring things in order  to identify a new problem?  I think there is
going to be  very little of that type of monitoring to be done, at least by
our program office. I would anticipate the type of monitoring that would
be sponsored by the Office of Toxic-Substances would be more exposure
monitoring,  the type of monitoring which will allow us to scope out  the
character or size of the  type  of  problem that we are dealing with,
anticipatory to Section  6 and  other types of regulatory  activity,  or
perhaps in packaging it up and passing it off to some other program or
agency to be dealt with under  their Act. I would not anticipate that the
                                          H-20

-------
Question:
Answer:
Answer:
Question:
Answer:
Answer:
Office would be undertaking any large scale-oriented monitoring activi-
ties.  Those presumably continue to be carried out by Water, Air, and so
forth.  On the other hand, we will certainly want to take advantage of
the data  that  is collected there and will be working  closely with the
STORET people and so forth.  I come from CEQ. We are very high on
UPGRADE as a data analysis tool, and we are aware of the activity that
OID is sponsoring to identify  the utility of the UPGRADE analysis system
as a tool for analyzing data files available in the Agency.  We would hope
to see that that kind of tool will be available to us as a program office to
be able to analyze some of the data that is available in the agency.

You are  telling  me then you have  no  plans, as far as you  know, to
generate the new OTS environmental data handling system?

We have not really defined exactly what the monitoring program is likely
to be.  I would anticipate  that the focus of our monitoring would be with
respect to identifying toxic substances issues.  There may be some data
handling which  would be required for that type of data, but it is not
likely to be anything of the type that exists in the program offices where
regular and ongoing media-oriented monitoring occurs and other type of
monitoring and effluent typed monitoring is going on.  Ours is more likely
to be a one-time shot, in an effort to find out what we are dealing with.

I would like to  make  one short additional comment. The MITRE Study
indicates a string of about 20 or so other files within EPA and outside of
EPA, all  of which will be used  to help support the  OTS missions. No
where in  that constellation is  there an OTS monitoring system.  There
are too many things for  them to rebuild. They have to use everything
that exists.

I had a lingering question. I  am with Water Planning in Headquarters.  I
am working in the pre-treatment  area, basically with sewage treatment
plants and toxic substances.   Our main interest right now is the list of
129 substances that they  are studying.  I  assume your hazard evaluation
division is studying this, too.  What is the status of your study?

I do not think we are evaluating the 129 substances at the Water Planning
Offices.   We had a meeting with them about three weeks ago.  We were
looking,  at that time, at integrating our list  of substances and also
integrating our  list throughout  EPA, to  try to  work  together and
coordinate these efforts.  I do not know of any effort, although I could be
wrong, because I am not sure of what is going on in all the groups within
OTS.  I do not know of any specific hazard  evaluation of  those 129
substances that we are doing.

Let  me  address that briefly.   In the proposed organization with the
Office of Toxic Substances,  there is a proposed Steering Committee of
the Assistant Administrator  and three Duputy Assistant Administrators
in the  area.    The  major  function  of  that  Steering Committee  is
anticipated as  reviewing  the information status on  individual  chemicals
and determining what stage  of work they belong in.  Do they belong in
the area of needing to get more reporting on this particular chemical, or
should we be going to a  hazardous assessment  on this chemical?  That
                                         H-21

-------
                mechanism is obviously not yet operational. There are not DAA's at this
                point.   In anticipation of  that  type of  activity,  Steve  Jellinek has
                initiated a Zow key effort to review those existing hazardous assessments
                that have been done  in the Office over the past few years, and to review
                the type of information which has been  developed by the Interagency
                Testing Committee in cases where they identified a number of chemicals
                as  low priority for  testing.   Their chemicals are  relatively  more
                hazardous. In attempting to take an overview of all of these chemicals,
                some of which may overlap the 129 and to  identify those chemicaZs which
                under TSCA, there  may need to  be future Section 6 action, I think the
                feeling is that we ought not to avoid  the 129 completely, because those
                were developed through your litigation process.  The water program may
                be  dealing  with the  water  effluent aspect  of the  particular  toxic
                substances, but there may be other important ramifications in terms of
                appropriate or inappropriate abuses, occupational exposure,  or whatever,
                that are leading to other media and other types  of problems that would
                .either fall under TSCA, or might  be a concern for other agencies.  Some
                of those 129 may require  additional  testing for other agencies, or for
                EPA, to take actions.  There is some low-key review to decide  whether
                or not  to come up with a Zist of chemicals against which we may want to
                undertake Section 6 action.  There will be reviews, overall lapping of the
                129 with respect to  testing rules or other  types of evaluations that will
                be going on in the office.

Question:       There will be a very  grey area. They are  not going to be  able to master
                the significance, they are not going to develop  guidelines.  There will be
                some interest in the  ACP.  Maybe there will be only one manufacturer in
                the country, so there would  not  be national  guidelines developed under
                the Water Bill.  Yet, it still remains  as a concern, and then it  becomes
                TSCA.  I'm wondering if you know?

Answer:        I think that  is right.  Steve Jelliner is very well aware of the fact that
                for the foreseeable future,  we will not have enough resources to deal
                with all toxic substances problems.   What he  is trying to do is develop
                priority systems where we  focus our limited  resources on the highest
                priority problems.   Where  there is one manufacturer, there is a very
                localized problem. There is not a large exposure to either humans or the
                environment  to  this particular  toxic  substance.  It might be a lower
                priority  than one  where   there  is  broader  exposure  and/or  better
                characterization of toxicity.

Question:       My name  is Sherman B. Arthur from Region 9.   Do you anticipate any
                significant impact of  the  TSCA information  requirement on  regional
                offices and especially in terms of data collection and handling?

Answer:         You mean with respect to having people report  to the regions? At the At
                the present  time, we do not  see any reporting  directly to the regions
                under TSCA.  We are working with  the regional people now, and we'll
                have a  training session in  Washington on the 13th, 14th and JSth of
                December to have the regions provide assistance to people who will be
                reporting to us under the inventory.
                                          H-22

-------
                    CONCLUDING REMARKS/PANEL SUMMARIES


                                  Willis Greenstreet


     First, I would like to say that I am gratified and surprised to see so many of you here
at this  late wind-up session.  I also  want to say that I am terribly pleased that the
conference has met my original intent.   As you may  recall, I announced at the opening
that this conference's purpose was for everyone to talk together. I think that has occured,
at least to my satisfaction.  I would hope that you would continue this dialogue at other
opportunities, not the least of which is using the fine  FTS system. You have to work at
talking  to each other.   It simply  will not work any  other  way,  because we are a very
dynamic organization in the truer sense of the word.  We have certainly picked over our
bones in the past few days.  Mine were just picked before lunch and I feel especially raw,
but nontheless we all understand some of our def iciences and  we also have learned that we
do have some strengths in what we are doing. The overriding consideration with which I
am concerned, however, is that  we all understand both our strengths and weaknesses, and
hopefully we  can decide in what direction we are going.  I am going to try to move as
rapidly  through this as possible.  I think that the  panel chairmen can make very brief and
concise reports.
                                          PS-1

-------
                     GENERAL SESSION II: PANEL SUMMARIES

                          Distributive Processing Summary


                                 Theodore R. Harris


     When we started out, we heard a lot of definitions of Distributive Processing.  The
Distributive Processing panel  also tried to define it.  The purpose of the panel was to
present to everyone what EPA is doing; the panel represented the  many different views
within  the Agency.  All of the EPA mini-computer managers who have POP 11/70 mini-
computers have  made presentations. We had presentations of some applications that are
currently  running on the mini-computer, and we had  two presentations on the view from
EPA national data base managers.  Several issues were raised.  I will briefly state what
they were. Regarding distributive data bases, we need to find out the techniques of how
and  when to validate  them to national  data bases.  With system  analysis, design and
implementation  of software on distributed systems,  the most important issue was the
shortage of highly qualified personnel.  The issue of coordination within the regions and
labs  was discussed.  A new issue identified is the coordination with the national system
managers.  The  suggested answer was to invite to the national systems managers to the
mini-computer mangers' meeting, which happens every six  months.  I am inviting all the
conference attendees who would like to attend this meeting. In summary, there is a lot of
enthusiasm.  EPA is doing things.  Our  approach is conservative, well-planned; and  is
taking  advantage of new technology and the state-of-the-art for the betterment of EPA.
                                          PS-2

-------
                            Effluent Data Systems Summary


                                    Jack Sweeney

      We had three presentations, one from the Office of Enforcement on their proposed
compliance analysis of the effluent data system.  We had a second presentation from
Region II, which is one of the three regions that have some form of effluent data system,
and a third presentation from a  monitoring  data support division on an application of
effluent data and  water quality analysis situations.  We had a very lively discussion during
the meeting, particularly in the  area of the  use  of effluent data and  the enforcement
program.  About half a dozen major points came out of the presentations and discussions.
First  of  all, effluent data is being used quite  extensively right now  in a variety of
programs.  It is used in the 208 Water Planning Program, and also in the facility planning
that goes on in the Construciton Grants Program.  The  second area is water enforcement
where it is being  used for  the NPDES program, and also  in the development of effluent
guidelines.  It is now being regarded for use in the toxic program and  appears to have
applications in the water supply program for  point sources upstream  of  water  treatment
plants.

      The  demand seems  to be  increasing  for  effluent data, but  the  availability or
accessibility to that data by the variety of people that are using it in one form or another
is very limited, because it is not available or easily acessible in an ADP system.  There are
a number or organizations  that are looking to some form of an ADP system to  handle
effluent  data.  At the regional  level, there  is not really consensus yet, as to whether
effluent data systems are needed.  There are three regions, Regions  X, VIII, and  II, that
have  some form of an effluent data system right now.   Region  VI is apparently interested
in volunteering as a pilot region for the system that Enforcement wants  to bring out.   At
the state  level, there are seven states to my knowledge that have effluent data systems
right  now.  At the Headquarters  level, there are the Office of Enforcement, Office of
Water and Hazardous Materials,  and Office  of Toxic  Substances  that are displaying an
interest in effluent data.   There is a growing interest, but there is no  bringing it  all
together at the Agency level. There does not  seem to be a single office in EPA that really
has the authority to play a  leadership role in pulling together all these needs for effluent
data, trying to address them, and  most likely  coming up with some kind of EDP system or
systems that will address those needs. The key to  resolving the problem, I think, probably
lies initially in the enforcement area.

      There is not a consensus, of  course, between regions and the Headquarters as to
what  the need is.  I think most of the discussions that occurred at the session really zeroed
in on  the Compliance Analysis System that Enforcement is now proposing. At the regional
level,  there are a lot of serious reservations  as to whether that is the  right way to  go.
Some of the main problems that were thrown out in the question and answer session was
that  of the resource impact of  implementing  a compliance anlaysis  system.   The
feasibility  study  that was  conducted  seemed to project very low estimates as what
resources  will be  required to implement the  system.   Once the system is implemented,
there is the question of what happens to these positions that  are supposed to be saved
through an effluent data system.  There is also the question, is Enforcement going  to take
these  positions back?   Even  if  they  are  not taken  back, how  are  they going to be
reallocated at the  regional level?  For example, you have shifted the workload away from
the Enforcement  Division  to the  data processing branch.   That  issue  has  not been
addressed.  Another point that was raised was that the  regions felt that  enforcement was
doing  an  end  run in  terms of pushing ahead with impleminting a compliance  system


                                         PS-3

-------
without getting a real clear mandate from the Regional Administrators. Another problem
was that the regions felt that it was going to be a mandatory system, and what  might be
good for one region may not be good for another.  That depends, in part, on regional
priorities and also how many states may have the permit programs Another point that was
raised was have they really considered interfacing the system with STORET, which seems
to be a system that could handle effluent data and make it available to planners to  the
states, and  a lot of other people within EPA?  Apparently,  this interface has  not been
hammered out, or even considered in any detail.  The last point is that enforcement has a
need  to  get out into  the field  and develop more grassroots support for the  system.
Probably, the only way that they will do that is to go around to the regions individually
and discuss the Compliance Anlysis System study.

     I think the main point, however, is that there really is not anyone in EPA that is in a
leadership position  to resolve the problems that  we now  have with effluent data.  One
proposal made was that EPA re-activate or set up a special steering committee, at the AA
level, to address the question of effluent data.

-------
                        Exchange and Standardization Summary


                                    Ted Standish

     The thrust of the Exchange and Standardization Panel was not just to address that
issue from the motherhood standpoint, since I believe all of us agree that we need to get
better capabilities for standardizaing and sharing the work that we are doing. For a more
pragmatic reason, the 1981 procurement effort for data processing is going to impact us in
two potential ways.  One is that we may not be faced  with compatible equipment with
either our current  IBM or  UNIVAC equipment,  and secondly, my  understanding of  the
current   GSA regulations  states that  if a  software system  is not  documented,  the
contractor is not responsible for converting  it.   There is a need to  start working on
standardization within the  Agency.  We had presentations of software standardization,
methods to tie the  programmatic data bases together, a presentation on data processing
hardware standardization, and a presentation on word processing standardization.

     The issues that I saw that came out of  the discussions included the following.  We
are faced with the  imminent issuance of software design,  programming, and documenta-
tion standards by MIDSD.  The draft stardards  for documentation will be issued in 3anuary;
for programming, in February; and for  design, in March.  We  have been  requested to
review those in detail and get  our comments back to MIDSD as quickly  as we can.  Linda
Tucker from  Ann Arbor also brought up the issue of data security standards that  has arisen
out there and the work that they have done.  As I understand it she will be submitting the
work that they did  on data secruity to MIDSD.   In addition, she also is willing to  share
work that they have  done on software  exchange,  especially as it relates  to the GSA
Software Exchange Committee.   The  contract  with Arthur  Young  dealing  with  the
potential for standardization of  data elements within the Agency, was also mentioned.
The RFP is in the final phase, and if anyone has any comments, or any concerns  about
that, they should  contact Frank Bullock.

     As far as  Agency  ADP equipment is concerned,  we  will  continue  the Agency
contract for  remote job entry terminals and for mini-computers.  The standards for those
two areas will be  the same as  the ones in the current contract.   If anyone  has  any
additional needs,  or any changes to those, they should send them into Ted Harris as soon as
possible.  The second thing mentioned as far as ADP equipment  was concerned  is that we
will not continue with a standard Agency contract for low speed terminals.  Instead, the
standards that had  been set for those terminals will remain in place, but each region will
be free to use the  GSA contract to obtain their own equipment.   It  was  suggested by
MIDSD that if we are intending to keep a low speed terminal for anything  more than 18
months, we should seriously consider purchase since the lease vs.  purchase payback period
is less than 18 months, in most cases.

     In  the  case  of word processing,  there will be  an  order being issued by  the
Management  and Organization Division within the very near future that will standardize
word processing guidelines across the Agency.  M&O  Division is also willing to come  out to
each of  the  regions or laboratories to  help set up standards within the regions or
laboratories for word processing.

     In terms of trying to tie the  various Agency data bases together, it was  mentioned
that Region  III will be letting feasibility study  sometime in the  beginning of  the new
calendar year, to pick up on work that was done by the Philadelphia 208 Agency that did
attempt  to tie together the various data bases for water supply,  grants, water quality,
effluent data, and so on.

                                          PS-5

-------
     One last thing that was brought up and which continued last night is the coordination
efforts necessary among all of the people here, and among the people within the Agency.
This Conference is certainly one of those efforts.  In addition, last night, we had another
one of our peaceful  regional ADP  branch chief meetings.  We have agreed among the
branch chiefs that becasue the workload that is coming out to us in reviewing proposed
systems and in trying to respond to the Headquarters issues being  raised, the regions will
group themselves into three areas.  Regions I, II, IX, and X form  one group. Regions HI,
IV,  and V form a second group; VI, VII,  and VIII form  another  group.   We  have agreed
among ourselves  that at least one region from each of  those  groups will review every
feasibility study that  was  prepared by  Headquarters.  There was  a general consensus
among the ADP Branch Chiefs that if a system, is not in the zero-based budget, no support
will  be  given to that  system.    There was  also concurrence  that if the  Regional
Administrator has not approved a proposed Headquarters  system then Headquarters does
not have committment to that system from the region.  We are asking  that in cases of
proposed  feasibility  studies  that  would  effect  the  regions,  that  each  organization
preparing to initiate the feasibility study  send a memo to the Regional Administrator with
a carbon copy to the Management Division Director announcing the feasibility study and
which  regions will  be contacted as part of that  study.   We  are concerned  that our
coordination  with Headquarters be  improved.  We feel that by announcing the feasibility
studies ahead of time,  we  will be  in  a better  position from  the  regional standpoint to
provide meaningful comments and meaningful suggestions on the way to go in the future.
                                         PS-6

-------
                         System Development Cycle Summary


                                   Morris Yaguda

     In our panel,  we had four presentations and two terminal demonstrations. Two of
the presentations dealt with what I refer to as Stage 4 Systems, using the familiar  Nolan
Stage Hypothesis concept.  That is, the first two presentations in our panels dealt with
systems based on other systems. These are the CEQ UPGRADE system, and the EPA-NIH
Chemical Information  System.   The  UPGRADE  system  is  a system  that  the  CEQ
developed, when they were trying to write their annual report.  They found they needed an
automated system  that would let them look at water data, air data, demographic data,
health data, and pull all those things together with a very sophisticated analytical package
that would let them make some statistical sense out ot the interactions  of these various
data bases.  It should be pointed out that the Office of Research and Development in EPA
is presently  exploring, through a systems study, whether or not this system can be brought
into use in EPA. ORD is sponsoring a survey of EPA offices to find out which offices have
a need for,  and  would use such a system.  If anybody does have such a need, they should
contact Lance Wallace.  They are also  investigating  the  implementation alternatives
available  at the present  time.  This system now  runs on the  NIH computer.  They are
presently  adding the SAS (Statistical Analysis  System) package to it.  It runs  in a TSO
region in  over 500  K.  The question arises, where  can one run such a large system?  The
package has tremendous flexibility.

     The second stage 4  system  is the EPA  Chemical Information System.  Steve Heller
of MIDSD gave  a presentation on it.   This is  a system that  has two basic operational
components.  One  of them is the sub-structure search system, and the other is a set of
technical  data bases, representing laboratory instrument readings and other technical data
for specific  chemicals.   The sub-structure search component  is the component that he
spoke about the  most.  It is a tool that allows you to address the system with a particular
chemical  structure  or fragment in mind and  allow you to  identify one or more chemicals
that have that  common  structure.   Once you have done that, you can then ask the
question,  what other files in the  Federal  Government, or  elsewhere, have information on
that specific chemical?   Once again, we see a system that has in it information  about
other systems.  Users have a locator system.  If you find a particular chemical and you
notice that  it was  on the NIDSH hazardous  chemical list, the TSCA candidate list, the
Japanese  candidate list, and had  some hazardous AMES test readings, you then know you
have a bad actor.

     In the third presentation, Don Fitzpatrick talked about the Arthur  Young Company
which does  our  feasibility study contracts.  He talked  about  theory and procedures for
doing a major systems study,  and he  tempered his presentation with  some comments
reflecting some  very hard-won experience in EPA. They have  learned that we are a very
complicated agency, that  if you touch one part, you really  have to look around to see what
is going  on or  what  other  interactions  exist  with other  program  components in
Headquarters and out in the field.  Even beyond that, you  have to look very carefully. In
some of the  recent  studies, they have found that there is a tremendous emphasis nowadays
in looking at the impact  on the public reporting  burden  that  is implied in some of the
alternative  ways of implementing systems.  Don stressed  the fact  that it  was very
important in trying to plan effectively  for these systems and that  you get everyone
involved early. I think he used the phrase, "You try to  get everbody that ought to  be or
should be  interested together."  I think his choice of words indicated that it is not always
easy to do.  He also pointed out that it is really essential.  He has found it to be essential


                                          PS-7

-------
to have management checkpoints at certain key places along the way. You should not go
all the way to the end of the feasibility study and then hope to find that it will fit in. If
you recall the basic points in doing a feasibility study, you need to stop and check with all
the  people  who  ought to  be  interested  after you think  you have understood  the
requirement, after you have it on paper, and you think you understand what the evaluation
criteria ought to be. At that point, you should  stop and check back.  Make  sure that you
have understood it correctly.  Once you define a set of feasible alternatives, once again
(because there are so  many feasible  ways  that you could  possibly implement various
systems) you should stop before you do any detailed cost-benefit analysis.  Stop and make
sure that you have the set of alternatives with which people are  willing to live. Once you
have concurrence on that" point, you proceed ahead, do the detailed cost-benefit analysis
on the various alternatives that have been accepted and develop some draft recommenda-
tions.  Once again, stop and check with management before you go through  the trouble of
locking them up in concrete.

     The fourth and last topic of the  presentation was a briefing on the 1980's planning
effort, which essentially is the briefing that we are giving to senior management at this
point to show how we are, in fact, planning to develop the new systems for agency-wide
support.   I would also  mention that for the  two  systems,  the UPGRADE system  and
Chemical information  System, we did provide  terminal demonstrations.  Unfortunately,
there was not too much  time for too many people to get too much out of them, but I think
that those who were able to observe those systems were delighted.  In our 1980's study, we
also had to face the problem of future costs.  What can you say about future cost?  We
found  in  the  1980's study that, as a first rough  approximation, which we hoped  was
adequate  enough  for planning purposes, we are using the  assumption that inflation and
technological improvements will pretty much cancel themselves out over the future. We
pointed to the fact that if you look at the NIH Computing Center over the past few years,
after an initial cost  reduction  period  as  they put in larger and larger equipment and
achieved the economies of  scale, their cost has pretty much stablized.  We feel that is
support for  our  view  point.   If  you  are worried about  inflation and  technological
improvement, I suggest you might want to assume that they will  balance each other out in
your studies.  In our planning  for systems  we still have   a long  way to go in terms of
understanding the effects of states. There are varied  requirements in the states and  their
impacts on the regions.
                                          PS-8

-------
                          Administrative Systems Summary


                                     Neil Haley

     Our panel was organized and conducted a little bit  different from some of  the
others.  First of all, the objectives of the Administrative Systems Panel was to promote a
communication between systems  managers and the systems users.  We asked each of the
administrative  systems  managers  to give  a talk  on  their  systems to  discuss  the
development of the system,  the current  status, and  the future  trends.   The  systems
managers who spoke were the managers of the personnel systems, the personal property,
the contracts management system, resources management system, finance and grant.
Then  came interaction with  a  representative group  of users  through  comments and
questions.  We had representation from Air and Waste Management, Water and Hazardous
Materioals, ORD,  and a regional office.   One other  thing—we had asked the  systems
managers to prepare a paper beforehand for a couple of reasons.  One was for the record,
and secondly, it enabled some of the managers to talk  about  their systems in a more
personal and philosophical way while they were comfortable knowing that the details of
their systems, or the technical aspects of  the system were in the paper that would be in
the record.

     It seems  that there had been very little coordination between systems during  the
development stage.  Many of them were developed rapidly during the early stages of  the
Agency, and had been developed primarily independently.  They evolved from small update
and reporting systems.  Initially,  they were highly centralized and  there was an  initially
low development cost.  Some of that is now seen in fairly high operating cost. They were
oriented in the beginning to meet Headquarters needs.  In some cases, they had expanded
to meet other-than-Headquarters needs.  This was characteristic.   Under the Personnel
Management System, one of the themes brought out was that Mike Platt was very intent
on building the credibility of  the PMS and building the credibility and reputation of his
staff.  He was working very hard  to meet  very immediate needs, while at the same time,
working on  more longer-range goals.  The  PMIS, one of their major efforts these days, is
to meet the new  needs under ZBB, and  to  push towards MBO  and try  to tie  those
techniques together.  Regarding the Financial Management System, there was discussion
on  the  decentralized  input/output process under SPUR software  packages that were
available.   With the Contracts Information System, Ed  McLean said, right up front, it
serves the Contract Management Division and that's about it. He discussed his role in CIS,
how he  had seen it evolve and how he though it might improve. GIGS is looking at new
mechanisms for updating the national master file.  Also, the construction part of GIGS is
under review by an Arthur Young study.  It is possible that the other portion of GICS will
be reviewed in some fashion.  The Personnel Property System has been moved to NCC and
there was very stong endorsement that NCC was providing excellent service, and that the
transaction had gone quite smoothly. Some of the user concerns came out, not only in the
Administrative Systems Panel, but also in the ADP Management Panel and in other areas.
For example, the need for an integrated  approach was  mentioned.  The administrative
systems  managers were looking for some kind of agency-wide effort in this area. They
felt that on their own, as systems managers, they were not able to conduct anything  like
that, and they  were looking towards  a higher level of support  for this type of  activity.
The users felt there was a need for better coordination  between systems.  There was a
need for a common technology for codes and standardization and so forth.  They felt they
also needed to reconsider  how some  of  the systems had been implemented,  what they
were, the services they were performing now, and whether or not there ought to be more
flexibility and perhaps a wider range of users.  Finally, another observation made was that
some user needs are just not being met by  national systems; they are being provided either
by local systems, by makeshift systems, or not at all.

                                          PS-9

-------
                               Water Supply Summary


                                     Tom Martin

     The water supply panel addressed that part of the Water Supply Program that deals
or relates to the supervision of public water supplies.  From an ADP perspective, that
included primarily  the  Model State Information System and its follow-on system, the
Federal Reporting Data System. We accomplished that in three presentations.  The first
presentation was given  by Dan Barber and was entitled,  "The Legislative Direction and
Decentralization of the Model State Information System."  The second presentation  was
given by Bruce  Keith; it  was entitled, "Meeting the  Requirements  of the Safe Drinking
Water Act and the Needs  of the States and EPA."  The third  and final presentation was
given by  Don Worley; it was  entitled,  "The Test and  Acceptance of  a System to be
Delivered to a User Other than EPA."  From  those presentations and the questions at the
end of the presentations,  there were about six or seven major issues. The first was the
legislative direction, as  well  as general EPA-State relationships.  The latter  are tending
more and more  towards a state role.  As a result of  that, MSIS was developed for state
usage on their own computer facilities or on the computer facilities of their choice.

     Secondly,  MSIS  development  was in fact impacted  by the decision to develop a
decentralized system.  Although much of this impact was attributable to whomever the
intended user was  to be, MSIS was developed utilizing state-of-the-art techniques to
ensure  reliability,  maintainability,  and  usability.   Also, MSIS was developed  in  an
extremely modular fashion in order to facilitate both  adaptation or system enhancements
to satisfy specific state  need.  A third issue was the installation of a  decentralized system
which can cause unique situations and problems to arise.   For example, the installation
schedule, itself,  once the system is developed, can produce a domino  effect when anything
goes wrong  in the installation schedule.  Also, the installation of this system on different
computer mainframes results in problems because of the availability  or implementation of
various  facilities or capabilities on that mainframe.  Nevertheless,  we have discussed
some steps that  can be taken to reduce system implementation problems.  In MSIS's case,
we used some background information packages, various checklists.  We have what we call
pre-installation  management  conferences which bring together the contractor, EPA, and
the state people before  we  go  into  the state.   Then  there  is the package of post-
installation  support in training, a  user  support group, and  mechanism to  modify the
system.  Then, under testing and acceptance, the conclusion reached was that  testing and
acceptance  of such a system  must be comprehensive and should include testing  of the
total  system, (i.e., testing of system design and program  design,  in  addition  to the
programs themselves, the  operating procedures,  the training facility, the usability of the
system, and system documentation).  Finally, and this came out primarily in the question
and  answer  period,  we  discussed  whether MSIS  should   have  been  centralized or
decentralized. The answer to this question can only be realized with time.  We presented
issues on both sides; time  will tell whether or not this is the  best way to go.  I think we
have something workable,  though, and usable.
                                         PS-10

-------
                             ADP Management Summary


                                   Kenneth Byram

     On our panel there were six of us from different parts of the Agency.  The charter
was basically discussed and the question, what sort of ADP organization ought to exist or
not to exist in the central way in EPA?  In other words, if you had to design  an ADP
organization for EPA, where would you put it?  Would you have it like it  is now, or would
you have it more or less centralized?  The  people participating were from two regions,
Joel Brandon from Region V and Doug Shape  from  Region IV-  Two were from MIDSD and
NCC, myself and Mike Steinacher; two were from Headquarters offices, Bruce Rothrock
from Enforcement and George Lehnert from Water and Hazardous Materials.

     George started by looking at MIDSD's registered and approved functional statement,
going through it and seeing what it was that  MIDSD was telling  itself it  was supposed to
do. One of the things that was brought out in George's presentation was that MIDSD  has
responsibility for developing the  Agency Management Information System. George said
that he was not quite sure what that was, and some of the rest of us admitted that we did
not know  either,  but that  perhaps it was an  archaic  concept that  needs  a  little
redefinition.  One  of  the key things that  I think George discovered in our functional
statement  is that MIDSD is  charged with  integrating  ADP efforts across functional,
media, and geographic lines within the  Agency.  George cited a couple of examples, one
which was MSIS. He felt MIDSD had done quite well with it. Another one that he thought
they had not done so well was the Hazardous Waste Management System.  I think he was
indicating that  there was great promise for good work here if systems could be integrated
across these lines.

     Bruce Rothrock then attacked the problem from a little different angle, suggesting
that there were really four areas of effort that were of concern in data processing.  One
of them was information management rather than  data processing management.  The next
was data management itself, ie., from where should the data come?  What kind of data
should be collected?  What should be the checks on that data?   Also discussed  were  the
provision of software programming services and finally, the provision of harware services.
After  introducing  us to those  four  areas,   Bruce suggested  that   the  information
management function probably belonged mostly in the program  offices.  The  programs,
themselves, were in the best positon to  know what source of information* they needed and
what  they should  do with  it.   Data standardization,  he  thought, might be  partly a
centralized  function,  and he  said that,  in a sense, it already was centralized with  the
program reporting which exists within the Office  of Planning and Management.  Finally,
he suggested that the software and  hardware services  were properly a central kind of
function.  He went on to suggest, in  what he characterized as kind of a radical departure
from what we have now, that the central data processing organization within EPA might
properly consist of a group to analyze the data requirements, another group to provide the
software services, and finally a  group  to provide the  hardware services.  By software
service, I do not necessarly mean program analysis  and system  design.  In  a discussion that
followed around  those two  presentations,  one  point  was  brought  out and  that  the
processing effort within the agency follows pretty  closely what the agency itself is doing,
i.e., if the agency has a very clear idea of what it is to do and proceeds with it in a very
deliberate way, the data  processing aspect  of  that program  will also follow in a  fairly
deliberate way. In many cases, it  was very difficult to get an organized agency data
processing  approach to a program,  if the  agency's approach  was,  in  fact,  not  very
                                        PS-11

-------
organized.   Then we went  with a chicken and an  egg kind of thing and asked,  do you
centralize the data processing and then get the larger thing together?  I think it was Joel
Brandon  who said that it sounds to me as if you are suggesting that the  data processing
runs the agency.

     There was some thought about where, if there was to be a centralization of any kind
of data processing with in EPA, it out to be. Some suggested it should be in a staff office
of the Administrator, or at least the  Deputy Administrator; others though  it could be
associated  with the Office of Planning and Management which has functions like  that in
other areas. The two regional people brought out clearly that they felt that centralization
of data processing efforts within a region was a pretty good idea, it had worked well in the
two regions they represented.  Joel had an interesting discussion of  some 20 or so positions
that had been  devoted  to  data processing in one form  or  another before ADP  was
centralized in  Chicago.  Since it has been centralized,  the  number of positions  was
reduced to 11  or 12, with a much more organized effort than they had had before.  This
was  done  partly  be the logic of having the function  centralized, partly  by some
efficiencies when it was  centralized, and also, by contracting out the clerical and sub-
professional or technical kinds of activities with a  remaining   higher percentage of
professional staff.  Mike  Steinacher talked about his experience with contracting out in
the operation  of the data center at Research Triangle Park and providing several of the
services that it does down there. I think he endorsed his experience with contracting as a
very positive one.  He thought it gave considerably more flexibility than if you tried to do
the same thing in-house, at  least the way the Agency is currently  organized and the way
that the emphasis is directed.

     In summary,  there seems to have  been  no  very stong resistance to trying to
centralize  more.   The  group, I think, as  a   whole did not raise large objections to
centralizing. I think  it is important to emphasize to those  who were not there that this
was a  panel and not  a Agency  policy  determination board  so  that the sentiment for a
stronger  direction of data processing  within the agency was with  this group perhaps, it
might not be the agency's intent to proceed that way.
                                          PS-12

-------
                              Toxic Substances Summary


                                      Ken Olsen

     Our panel gave an  overview of the  implementation of  TSCA and its reporting
information system in order to provide a status report of what  is going on and how are
interfacing  with the  various  operating  units  within EPA  and other Federal  agencies
progressing.  First, we started out with our design philosophy of the  information system
being designed to support the decision-making processes under  TSCA.  We are taking a
very careful look at what decisions have to be made and what  is really needed in risk-
benefit analysis.  We  then got into the overview, the big picture. We talked about the
requirements analysis  that we conducted  this spring.  We talked  about the activity of the
Interagency Regulatory Liaison Group, and specifically the Information Exchange Group,
in areas such as standardization and various networking possibilities between information
systems throughout the Federal Government. We  then specifically  talked about TSCA and
what is happening this year, in FY 78. We discussed the the  inventory processing at CAS,
and  how, by roughly a year from  now, we expect to publish the inventory of commerical
chemical substances in the United States, a list of some estimated 50,000 chemicals. We
talked about our TSCA Information System contract with Informatics.  We are designing
an information  system to  process  all the data  that will  be reported under  the  Act's
authority.   The Office of Enforcement discussed the compliance  monitoring module and
how  we are doing a feasibility study of the incorporation of  the  enforcement information
system within the OTS information system.  Finally, we discussed our recent survey of
regional needs and laboratory needs with respect to data availability.  We also touched on
data confidentiality and  discussed why confidentiality  is a driving force in our system
design and  in our network.  We  are in the process of writing a new EPA order on the
handling of  confidential information under the Act.
                                          PS-13


                                                          * U.S. GOVEPMENT PRINTIHG OFFICE: 1978 0-620-007/3705

-------