,:W*M
«fes
•=-;-:-i*3
fe^ll
£
EPA
220
1989.11
C.2
^m:mm
f^.,»<^>
iM^
sp-%
":^ -^iv:-?*
mmiisi¥r!*
tflll^^i
^f^:^;,':
£&£?&£
•j. •__'., _•,.,«•• „•,.••••-'..,••,..'• • ., -^- " •
X*3
,
&:£•:-':V:*|
^.'..;,::£-.;;l
m
.
•-•. /
V
j>
-------
.' ftW:..»yS«»S
IV- «;,-
wm~
m
mmii
£A<:,:
&S:I*?' '
mm
j-^-*
&*':•-,
r«s?p
T*. a.?.<5 i
P^J
•sas^j
If
' ^,.';". '-:
;.i*.:
;*.-•
-------
L/rvX
EPA MAJOR SYSTEMS PROFILES
TABLE OF CONTENTS
SECTION I
1.0 BACKGROUND
1.2 PURPOSE
1.3 METHODOLOGY
SECTION II
2.0 PCS SYSTEM PROFILE *
2.1 NEEDS SYSTEM PROFILE 26
2.2 CERCLIS SYSTEM PROFILE 63 ,
2.3 FRDS-II SYSTEM PROFILE .'. 39
2.4 STORET SYSTEM PROFILE 131
2.5 CLP/SMO SYSTEM PROFILE 150
HEADQUARTERS U8RARY
ENVIRONMENTAL PROTECTION AGENCY
WASHINGTON, D.C. 20460
-------
J/WlMPOflf''
.j-1 .JK/ittV-.
-------
1<
EPA SYSTEM PROFIXJ
Sine* 1974 the Environmental Protection Agency (EPA) has
expanded to support additional legislative Acts such as the clean
Water Act, the Toxic Substances Control Act, and the Super fund Act.
For each Act the Agency establishes a supporting program office
which is responsible for carrying out the functions intended by
legislation. In order to carry out these functions the program
offices often develop information systems (IS) which are necessary
to exercise their responsibilities. Program offices often develop
an IS with their own standards considering their specific problem.
This can result in the existence of several computing systems that
overlap one another in the scope of system functions and the data
universe which they operate in. In order to provide better service
and coordination to the Agency's program offices, the Program
Systems Division is gathering available information on existing and
planned AOP systems. This information will be used to plan and
support guidance activities with PSD. This EPA system Profile
document provides a summary of several existing EPA systems. The
intent of this document that is to provide a mechanism for
coordinating future development activities and aid in locating
information. This document contains profiles for the following
systems:
o Permit compliance System (PCS)
o NEEDS Survey (NEEDS)
o Comprehensive Environmental Response, Compensation &
Liability Information System (CERCLIS)
o Storage of Retrieval of water Quality Data (STORET)
o
Contract Lab Progam/Sample Managment Office Systems
(includes: SAM, STAT, CCS, MIS-RAS & TIP).
-------
Th« purpose of the Profile t»»Jc is to provide EPA with
a high-level profile of major EPA information systems.
.
profiles are desired to b« effectively ussd for different u»er
groups including EPA management and technical staff. Th« Profiui
should be broad enough to includs all ksy systam points and narrow
enough for the parson reading the document to determine the
following:
o significant differences between systems profiled
o purpose the system wee developed to support
o functions the system performs
o how the system performs it functions
o kind of support the system and its maintenance
staff provide to its users
o type of system documentation available
o data domain of the system on a broad scale
o who the users are
o what is the status of the system
o background of the system
o technical configuration of the system.
This document can be used by system developers to
identify the systems they need to interface, provide information
about a specific system; and to anyone at EPA who needs to kr>ow
where specific data is being retained and how to access it.
The document can provide guidance for the development of
future information systems in terms of developing standards,
identifying weaknesses, improving system performance and user
support, as well as how to streamline information system
development.
Although this document profiles ten major EPA systems a
full examination of the EPA system environment cannot be obtained
without further examining other EPA systems. Some recommended
systems are:
o Aerometric Information Retrieval Systems (AIRS)
o Compliance Data System (CDS)
-------
o EPAY Payroll System (EPAM)
o Facilities Ind«x System (PIMM)
o Financial Management systa» (PUS)
o Grant* Information and control Syateat (Gics)
o Hazardous Wasta Data Management Syataa (KWOKS)
o Raaourcaa Managaaant Information syatan (RMIS)
METHODOLOGY
Ona key element of the profile task wa» to develop an
outline for tha profile document which would ba conaiatant for each
system; would identify the functionality of each system; and would
focus on other key attributaa such aa hardware, software, key
files, data base, data domain, communications, interfaces, user
training, user correspondence, and documentation. Also included
in each profile is a background section which explains how and why
the system was developed, and what changes had thus far occurred
from the time of system implementation up until the time the system
was profiled.
Developing each profile began with an information
gathering stage which included interviewing system owners and
developers, and reviewing all available documentation including
memos, newsletters, user guides, specification documents, and
program documentation. Some profiles contain more details than
others. Tha depth and scope of tha information raaources available
varied among the systems profiled. Some systems had extensive
resources available while others did not. The inconsistency of the
resources is reflected in the profiles.
-------
2.0 PCS SYSTEM PROFILE
-------
i I
M.
5 B I
III
i i
I !
i i
1 i
5 I
s 5
5 z
i: i
»|i
111
i
5
-------
PCS PROFILE
QUTLIHE
1.0
1.1
1.2
2.0
2.1
2.2
3.0
3.1
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.3
3.3.1
3.3.2
3.4
3.4.1
3.4.2
3.5
3.5.1
3.5.2
3.5.3
4.0
4.1
4.1.1
4.1.2
Svatea
Systea Purpose
System Background
User Environment
User Support
User Training
Technical Overview
Hardware/Software Environment
Subsystem Environments
Data Entry
Data Edits
Updates
Data Retrieval
Data
Systea Data Base
Files
Hardware
Type
Peripherals
Software
online
Batch
CooBunications
Svatea Functions
System Input
Data Input
Update
-------
4.2
4.2.1
4.2.2
5.0
5.1
5.1.1
5.1-2
5.2
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
6.0
6.1
6.2
6.3
system output
Ad-Hoc Data R«tri«v»l
. Reports
System
User Chang* Control Proce»»
System Enhancements
System Problems
Technical Change Control Process
Change Control System Design
Change control Documents
Change Control Activity
Change Control Testing
Implementation of Changes
Documentation
User Documentation
Technical Documentation
Data Dictionary
Appendix I sample System Function screens
Appendix II Documentation Matrix
-------
PCS PROFILE
1.0
1.1
SvstemOverviev
System Purpose
The purpose of th« Permit Compliance System (PCS) is to
track and monitor over 130,000 industrial and public works
facilities in support of the National Pollutant Discharge
Elimination System (NPDES). PCS trades permit information
issuance through expiration as well as additional data including
: general permit information, government grants issued; appeals
and hearing requested by the permittees and facility inspection
data.
1.2
System Background
PCS was developed under the Office of Hater Enforcement
and Permits (OWEP) to support NPDES. The NPDES issues permits to
facilities discharging pollutants into our nation's waterways.
Each permit limits the amount of pollutants a facility may
legally discharge. Actual measurement limits, for pollutants and
beneficial elements are specified on a permit. Maximal limits are
indicated for acceptable levels of a pollutant. Minimum limits
are indicated for the minimal amount of beneficial elements that
are required, such as oxygen.
One of the major functions of the NPDES program is to
determine which facilities violate permit regulations.
Depending upon the severity of the violations, action may be
taken by the EPA to insure future compliance. These "enforcement
actions" that the EPA issues may appear in many forms. The
actions taken become more severe as the violations continue.
Another important aspect of the NPDES program concerns the
maintenance of discharge limits on existing permits as a result
of new laws requiring stricter regulation. These new laws may
require revisions to existing permits, resulting in pollution
discharge limits being lowered or raised significantly. The
revised permit may contain instructions to build nev filtering
plants to comply with new regulations. If this is necessary the
EPA will set a time schedule with completion date milestones for
building new plants. These "compliance schedules* must be met
within the time frame specified or enforcement actions will be
applied.
Hany reports are required by Congress to identify NPOES
violators and the accompanying enforcement actions taken by the
EPA. Both state and regional EPA employees use PCS as a tool to
determine who is violating the Clean Water Act, to what extent.
-------
and what prior action ha* b««n taK*"-
2.0
User
of th« state and regional
,,-
Th« viser community con?i5or»»tion. Each
employaa* needing MPOES program *";igl,at«l states. However,
offica is responsible for their JJJJy'vno have develop** their
regions may contain interface J**^' mtarfaca states must
own tracking and compliance »*»**•!; tn« PCS data basa (typically
supply require MPOES information to w
via a batch upload process ).
contcal
purposes .
requests.
contractors are e.
ploy^. .« create and run retrieval
2.1 User Support
A representative users group meets twice a year with
Headquarters staff and technical staff to discuss PCS issues. The
forua for these user conferences includes discussion o£ new
policy decisions, and present and future enhancements. These
conferences are attended on a volunteer basis.
Headquarters maintains a "status" dataset in TSO/SPF.
This dataset contains the status of the update runs. Users may
determine whether the update is still running or if any problems
have occurred by browsing the status dataset. This dataset also
contains scheduling information such as dates for future training
and implementation dates for major enhancements.
2.2 User Training
Training is conducted by the Headquarters staff on a
monthly basis. Generally, between ten and fifteen users need to
request training before a training class is scheduled.
Headquarter* offers a two and a half day beginners seminar and a
two day advanced course. Only one of the two courses is offered
each month. Training is offered regionally and usually occurs
onsite or in the vicinity of the requesting majority.
The PCS training program encompasses all aspects of
using PCS however, the following items are not included ;
references to PCS Oser Guides used in the field, a detailed
overview of the HPDES application and TSO/SPF training ( TSO/SPF
is offered by the MCC ).
-------
Technical
Hardware/Software Environ*** — 1BM
Th. PCS costing «.» iiK u«ing
sections.
2 Subsystem Environments
, , , Data Entry
PCEHTK, - D.« "try pro,r».
III
3.2.2 Data
, 2 2 Data Edits
Mt. -i«.« ^-«- ssa1-Sv^vgiTr-
»«" ^i!.!>ss's~" ^nr.iln«r.~ -i«u* «• »1"-"
Batc e
are written CICS COBOL.
ADABAS/NATUFAL.
3.2.3 Updates
All regular updates are performed biweekly in a batch
COBOL mode. A "Direct Call" COBOL program is used to apply
transactions to the database. DIRECT ***TfT- programs access the
database at a lower level than Fourth Generation NATURAL. Lower
level meaning "closer* to machine cod*. This software is more
difficult to develop and maintain, but provides more efficient
transaction processing.
valid edits for records which are dependent upon the
existence of other related records are performed during online
editing and batch update processing. If the necessary records
exist the record is added to the data base.
3.2.4 Retrieval
GENERALIZED RETRIEVAL - A series of batch COBOL
programs which generate NATURAL code to access database
records.
INQUIRY - CICS COBOL and Dynamic Source NATURAL code
10
-------
used in con
tha database.
,-unction to generate NATURAL queries to
3.3
PCS Data
•-jin PCS i» related to th* events
Information r«tain**acjivitie». Data related to permit
surrounding permit compliance »°";ctionm, government grants
issuance and acceptance, site inspec £ ^ enforcement
issuance, scheduling, wast* di*P°.sT> oermittee protests and
actions, identification-otvioUtions Permittee pr^
regulations appeals are all part or ww
3.3.1
Data Base
„ .
in a hierarchical format.
PCS data base acces. i»
primary key. The
sasa
through the
. is called L
tni.gue.Ly identifies each
EM**.*.*., . part of the key in every PCS
data base record.
The PCS data base contains approximately 8 million
records.
»
3.3.2 Files
PCS uses approximately 8 different files called the
Permit Facility, Effluent, Compliance, Inspection, Enforcement,
Evidentiary Hearings, Grant and Permit Events.
Permit Facility data contains general facility
information such as name, address and classification.
Effluent data includes three levels of data; pipe
schedule ( identifies currently monitored pipe ), parameter
limits ( identifies pipe parameters being- measured ), and
measurements' ( records the parameter measurements ).
Compliance data tracks schedules for milestone events
and scheduling violations.
Inspection data records the inspection date, type and
inspector.
Enforcement data identifies actions taken and which
violations occurred to provoke enforcement.
Evidentiary Hearings stores data related to permittee
protests and regulations appeals.
II
-------
The Grants CU« contain. record* of which
watertreaEint Junts «r. I..*** <,ov.r»ent
Mnlt *.»« -» "«" °" U5amn°' •"" •Ce"t"C'
of the permits.
3 4 Hardwar*
3.4.1
IBM 3090 - 300 (SIERRA SERIES)
CPU * *
4.2 p«riph«rals
*
- u .».«
3. S Software
PROGRAMMING
COBOL (Batch 6 CICS)
AOABAS/MA1
DBASE III
coBWinications
-53
„,.„ in
central controller
4 0
IZ
-------
4.1
4.1.1
System Input
Data Input
The PCS design
l. card image processing
character card i»ag. data sets and
once the card is submitted and the
thr«« methods to «nt«r data
and 3. PCEHTRYV
section,.
bat"'™?
the card
The
ie: D-NHD0002323001A9 861231
The first character '0' identifies the transaction as a
Delete transaction.
The next two characters '-N1 identifies the record type
as a measurement.
The remaining characters represent measurement data.
Card Image processing requires extensive TSO^SPF
knowledge.
2. PCSADE is an on-line, menu driven, full screen
system that allows users to add new records and display existing
records for deletion or change. PCSADE provides online editing
so data is edited as it is entered.
PCSADE offers Add, Change and Delete transactions,
however a Browse or View option is not available. The Change
function does not immediately update the data base, it submits an
update transaction which takes effect when the Batch Update
process is run. PCSADE provides a Help function. The Help
function contains information about how to use PCSADE, it does
not include a list of any acceptable entry codes.
3. PCEHTRt allows users to enter data on a PC and
upload the data to the mainframe. This system is menu driven with
full screen access similar to PCSADE.
13
-------
4.1.2
Although three ways to enter data exist, there is only
one vay to apply the transactions to the PCS database, ie...
update tha database. Due to the high volume of data entered, no
data is updated online. All-update transactions are processed by
a standard Update Job run twice a week.
4.2 System Output
4.2.1 Ad-Hoc Data Retrieval
Once the data has been applied to the database it can
be retrieved. Currently there are two ways to retrieve data.
They are : Generalized Retrieval and INQUIRY.
Generalized Retrieval is-the most widely used PCS tool. This
facility allows users to set up batch retrieval statements in a
manner similar to the card image data entry. The user submits
these statements and receives either a "canned4* report: or a
customized report. The following example conveys how Generalized
Retrieval works.
ie: 10 STTE - HO
10 SIC2 * 49S2
20 FAC-NAME
The numbers 10,20 identify tha commands.
A 10 command indicates selection criteria
A 20 command indicates what is requested to be displayed
The first 10 command requests the state (STTE) of
Maryland(MD)
The second 10 command indicates the user requests all sewage
treatment plants(internally identified by code 4952)
The 20 command indicates the user requests the Facility name
(FAC-NAME) be displayed on the report.
The subsequent report produced would display the names
of all the sewage treatment, plants in Maryland. Although, widely
used because of its tremendous flexibility. Generalized Retrieval
has batch limitations similar to the batch data entry method.
The online "IKQOIRY" system provides an interactive single
query function. Bach request must be followed by pressing the
•ENTER' key, after which another request may be made. INQUIRY
has two separate modes, Prompt and Command. The Prompt mode is
menu driven and the user selects from a series of "canned
reports". Examples of "line by line" processing and Prompt and
Command modes can be found in Appendix A. The reports produced by
the INQUIRY system appear online.
14
-------
i 4 *
s.o
5 i
U,.r Chang* Control Ptoc««»
—fierio d«pict» th* process wliicn
Th« following scenario
»Y«t«» ca.
_,.- to PCS H«adquart«r* hotlin*.
- u»«r report* probl«« « «t
>.IM is logg«d on th« PCS o»«r R«qu«»t
probl«« i» 10^^
- Headquarters staff analy«s th. proble.
- Headquarters staff d.t.r»in.s extent of
-.issa arssss staf
- Head^arters
software -oaif icat.cn
s.l.l
syst«M Enhanc«««nt
sy.t«i
accomaodate the change.
5 1.2 System "Problems"
svst« "problems" are ^'"owirsrch. (
-------
5.a Technical change Control Process
ar*
tti« »«ctianic* of tha technical change control process
Cor «yata» enhancement* as thay
to b«
5.2.1
tha sa»a for system enhancement* a* they ara for softwara
bl***?l* ^^ tYP** of approacha* require existing software
a modified.
Changa Control systaa Oasign
PCS incorporataa two softvara anvironnants, davalopmant and
production thus adharing to standards sat by MOPO. Tha production
environmant contains tha actual softwara and data tha usar
accessas. Controls hava baan iaplaaantad which rastrict
production updatas outsida of tha ragular updata procass. Tha
development environmant allows software modification and testing
to ba dona on subsets, of actual data. This dual system allows
softwara aaintenanca and modification without interrupting the
production system.
5.2.2
tha
Changa Control Documents
Documents involved in tha change, control process are
PCS User Request
PCS Cobol/Fortran Tracking Form \
PCS Natural Program Tracking Form
Change/Enhancement Test and Acceptance Form for
Natural Progra
5.2.3
PCS Program Updata Log
Changa control Activity
After tha softwara ha* baan changed tha programmer is
responsible for testing tha change.
once tasting is complete tha original request form is
updated to indicate a resolution for tha problem is in effect.
Additionally, tha softwara tracking forms and change acceptance
forms both online and bound copies ara completed. All forms are
reviewed by a senior project manager.
5.2.4
Changa Control Tasting
Testing is performed both by tha programmer making the
change and Headquarters personnel. Tha modification* must ba
tested and cleared by both parties before being passed to tha
National Computer Center (NCC).
16
-------
5.2.5 Implementation of Change*
Th« HCC is responsible Cor moving « software change
fro* development into production.
6.0
PCS User's
6.1
GENERALIZED RETRIEVAL
DATA ENTRY, EDIT and UPDATE (PCSADE, PCENTRY, Batch)
INQUIRY
DATA DICTIONARY
Technical Documentation
PCS Maintenance Manual
Production Control Guide
User Documentation
Users Guides exist Cor each PCS subsystem. Each guide
contains an overview of the PCS data organization, as well, as
detailed procedures pertaining to accessing the subsystem, such
as ; interactive sessions, screen displays, prompts and reports.
Users Guides are currently under revision.
Headquarters plans to have these revised documents online
sometime in fiscal year 89. Online manuals will benefit the
users in that updates to the users guides will be more
manageable, and the time consuming and costly process of mailing
manuals will be eliminated.
6.2
Program Documentation
Maintenance Manuals - There is an extensive collection of program
maintenance documentation on each of the PCS subsystems. These
documents contain detailed program descriptions of the subsystem
programs. For instance, the PCSADE document describes each data
entry screen program (NATURAL) and all of the CICS COBOL editing
programs. The description includes a general overview of each
program and the input and output formats where appropriate. In
addition, program flow diagrams are also contained in these
documents.
The PCS project team also keeps a "hard copy" library of every
program in the system filed by program name.
Production Control - The Production Control manual is an
extensive document detailing the staffs responsibilities. This
document contains listings of all update JCL jobs, the most
common errors that may be encountered, and the appropriate
responses to resolve them.
17
-------
6 3 0*** Dictionary
Th« PCS data dictionary information includes data •Iwwt
descriptions and formats.
-------
Appendix I
• .
System Function
scr««ns
19
-------
17"*1*
SCRESK 10 SCREEN HAKE
PCS-ADC
nAIX flENU SCREEN
SC1ECN 10 SC&EEK KAHE
FAC1
FACZ
f AC*
fACO
IKSP
CSCH
PTRK
CVHft
GKNT
tins
iron
EKAC
EAKS
FACILttt DATA 3CUEEX 1
FACItlTTC DATA 3C1EEK t
FACILITY AOOIE33
OUXEft/OPEftATOA ABD1ESS •
IKSPECTIONS
COMP1IAXCE SCHEDULES
PEinIT T1ACKIX6.
EViaCKTXAKY KEAtlKGS
QtAKTS
LiniTS
LiniT noorricAtiOMS
EMFOKCtntKT ACTION
CMFQtCEntXT ACTION KEYS
PCIi
TAIS
COMLiAXCE SCHEDULE VIOLATIOKS
SIX«IE EVEXT V«"«';Ssca£EK
nETMATnext con? IKS» "*««
M«rii»tnncT COR? IKS* SC»EEK
PMTMATHEXt AUDIT *C*EEK »
PtETltXT«Xt AODIt SCJEEX 2
P»ETltAT«KT AUDT 3CIEEX 1
PCS CODE tiBLE
•» TEErtlXATES SESSION
EXTE* SCREEN 10'
DO YOU BANT THE CHANCE OPTION (Y/K)?
20
-------
PCS-AOC
Facility Owner/Operator Address Screen
TRAHS coot _ OUXER/OPEI ADDRESS SCREEX ID. r.co
- - FACILITY OHXEt ADDRESS .
FACILITY XAM <«XAN> __
ADDRESS LIXE1 (OST1) . _^
ADDRESS LIXE2 COSTZ) -
CITY COCTY) STATE COSTT) ZIP COZIPJ
TELEPHOXZ (OTEL) _
1
- FACILITY OPE»ATOt ADOtESS -
FACILITY MAHE (EXAF1) - - -
ADDRESS LIME1 CEST1) ]r - _
ADDRESS LIKE2 (EST2) , , - , -
CITY (ECTY) STATE
-------
03x09/87
PCS PC-ENTRY
VERSION 2.0t
DATA. ENTRY F(INCT:ON
PANEL E.KSNU
SCREEN 10 SCREEN NAME SCREEN ID
FAC\
FAC2
FACA
FACO
INS?
CSCK
PTRK
EVHR
CUNT
LIMS
LI MM
ENAC
EAKS
ENTER
FACILITY DATA SCREEN 1
FACILITY DATA SCREEN 2
FACILITY ADDRESS
OWNER/OPERATOR ADDRESS
INSPECTIONS
COHfLlAHCS SCHEDULES
PERMIT TRACKING
EVIDENTIARY S£AAtNGS
GRANTS
LIMITS
LIMIT MODIFICATIONS
ENFORCEMENT ACTIONS
ENFORCEMENT ACTIONS K£YS
SCREEN ID'.
OFLG
OFLT
EDMR
EVIO
CV1O
SVIO
FCU
PCI 2
PAU\
PAU2
PAU*
PPSl
SCRE~N NAME
OUTFALL GENERAL DATA
OUTFALL TREATMENT TYPESCOMMEHTS
EFFLUENT DMR PAGE
EFFLUENT MEASUREMENTS/VIOLATIONS
COMPLIANCE SCHEDULE VIOLATIONS
SINGLE SYSHT VIOLATIONS
PRSTRtATMeHT COMP INSP SCREEN 1
PRXTRSATMSNT COMP. INSP SCREEN 2
PRSTUATMENT AUDIT SCREEN t
PRETRXATMENT AUDIT SCREEN 2
PRSTREATMSNT AUDIT SCREEN 3
PRlTRSATMSilT SUMA*Y
IESC: End Data Entry Function:
-------
INQUIRY REPORT:
FACILITY OVERVIEW REPORT
PERMIT NUMBER: CTOOOOQ86
GENERAL INFORMATION
FACILITY NAME: AMERICAN CYANAHID6 COMPANY
ACTIVITY DATE:
ACTIVITY STATUS : ACTIVE
MAJOR/MINOR DISCHARGER : MAJOR
TYP£ OF OWNERSHIP : PRIVATE
STD INDUSTRIAL CLASS(SIC): PLASTICS MATERIALS AND RESINS
;i!uJ?!m"til?J*Nc" '. PRIORY PRIMARY CATEGORY: PLAST
CTTY • WALLINGFORD /T/ STAT6 : CONNECTICUT-
STY; NEW HA"" «M""« o* SUB-REGION: z
RIVER BASIN : NE/PAHCATUCK "VER REACH:
RECEIVING WATERS: QUINNIPIAC RIV
ENTER A CARRIAGE RETURN TO CONTINUE, OR
ENTER 'SKIP' TO SKIP THE NEXT SECTION — PERMIT INFORMATION
-------
Appendix II
Documentation Matrix
24
-------
25
-------
2.1 HHfflS StSTW PHOFIL8
26
-------
-------
2.0
, i
3 ; 2
21
EPA KAJOR SYSTEMS PROFILE
QUTLIHE
i i System purpose
1.2 system Background
2 i User support
2.2 User Training
3.0 T'inTiri1rril '•~«™i««
Hardware/software Environment
subsystem Environments
3
? 2 2 Data Edits
3*2 3 Updates
3 ".2. 4 Dat* Retrieval
3.3 Data
3 3 i system Data Base
3 '.3 ".2 *il«*
3 . 4 Hardware
3.5 Software
-.51 on-line
352 Batch
3.5. 3 communications
4 0
4>1 system Input
4.1.1 Data input
4.1.2 update
4 2 system output
28
-------
4.2.1
4.2.2
5.0
5.1
5.1-1
5.1-2
5.2
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
6.0
6.1
6.2
€.3
A* Hoc Data. Retrieval
Reports
Svati
User Chang* control Process
System Enhancements
System Problems
Technical Chang* Control Process
Changa Control system Design
Change Control Documents
Change Control Activity
Change Control Testing
Change Control implementation
TVacmty^t* t ion
User Documentation
Technical Documentation
Data Dictionary
29
-------
1 0 Svste»
, i System Purpose . ,, .
— survev which is technically
The purpose of the «••*• *"? Q^~ Sy»te« <*«<»*> • ^
supported by the Retrieval .*£££ ". EPlT'7 biennial a"""^
|o summarizs and report to cwj^ publicly-owned waste water
" the cost of constructinq a^. |oal, o/the Clean Water Act,
Baclcground
s»r».y
itut technical support, «**"* ^ contractor.
the Needs data bas«. arant-«ligible
ssar — - — '"
-
problem
30
-------
will provid€ . construction *rant baaa-lin. against which
future SKT data can be compared.
2.0
Oaer Environment
Needs is used by the
private firms, public interest .
states are the source of the data
through RUQuS.
and *tat« governments,
^de associations. The
in I* tne Needs data basa
2.1
User Support
User support services were developed based on the fact
that a substantial number of RUQuS users will not have TSO
experience. User support includes a Hot-Line, On-Line Bulletin
Board, user communications, and Meeds Survey Workgroup.
The user Hot-Lin* is available to any user with questions
concerning hardware, communication linkage problems and RUQuS
software use. The National Computer Center (NCC) may also be
contacted regarding questions concerning hardware configurations.
The On-Line Bulletin Board will make available at regular
intervals information about Needs Survey activities, meetings, data
analysis, and RUQus system-related information.
*
The Needs Survey Workgroup serves to disseminate Needs
Survey and RUQuS information and as a forum to discuss Needs
progress, problems, and enhancements. The Needs Workgroup
comprises regional, local, and Headquarters staff, and meets
annually.
2.2 User Training
During the spring of 1987, RUQuS training sessions were
held at various locations around the country. These training
sessions served to introduce state Needs Survey personnel to both
the NCC and to the use of RUQuS software. Feedback from these
training sessions resulted in further enhancements and refinements
to the RUQuS software, which were included in the Version I release
of RUQus in November 1987.
3.0
3.1
Technical, Overview
Hardware/Software Environment
3.2
Subsystem Environment
31
-------
3,2.1
Data
Entry
The data entry portion of RUQuS resides in the TSO
environment. Menu, and screens support the «ntry of Needs Survey
data.
3.2.2 Data Edits
Data which arc entered via th« RUQuS screens are edited
by tha "Master Edit" process. This process checks for data format
and performs a cross-edit of the data relationships.
3.2.3 Updates
Updates are applied to the data base as soon as a record
either passes the "Master Edit" process or an operator stores the
record in "Interim*1 status, which allows for later updates to be
applied.
3.2.4
Retrieval
Information is retrieved from RUQuS by retrieval screens,
reports, or ad hoc query. All retrieval requests are made in the
TSO environment. Tha General Query function is the only query
method which operates in line-by-line mode. ,
3.3
Data
The data which comprises the Needs Survey data base are
facility needs, population, flow, effluent, unit process,
documentation, and state-related. For data integration purposes,
facility compliance records are stored separate from Needs in a
shared file.
Tha Needs Survey reports present and future resident and
non-resident year populations for each facility in four specific
categories. Tha categories ara:
- Receiving Treatment
- Not Receiving Treatment
- Receiving Collection (sewage)
- Not Receiving Collection.
The populations are reported from a number of sources including
Section 208 planning documents, facilities planning documents,
and state planning offices that deal with population issues.
Population data ara essential for calculating EPA cost curve-based
estimates for those facilities with a documented problem but
insufficient information from which to obtain a cost estimate.
32
-------
Flow U th* total
treatment piwit. total «<
iMtitutlonal, industrial, and
in millions of gallons P«f
reportad In tha K««d« survay
all
through the
commercial,
U «««*ur«d
««
retained in th« <**ta
onth **
Effluent infection i*
design permit limits and onca a»
of treatment category for the
concentration data are reported
(BOD), suspended solid. (SS)
lants. Effluent
parPa1Mt.rs biological
and phosphorous
' Effluent
- Existing
- recent 12 month averages for
Discharge Monitoring Report
* Present Design - current national Pollutant Discharge
Elimination System (NPDES) permit limits
- Future Design - future NPDES permit limits if a
plant upgrade is planned or more
stringent state limits are imposed.
Unit processes refer to tha treatment and sludge handling
for each treatment facility. Unit process coda information is
retained in a RUQuS table for the following categories:
- physical/chemical treatment
- biological treatment
- land treatment
- sludge treatment and disposal
- disinfection
- noncentralized collection/treatment
- facility control
- type of facility construction.
Documentation of the findings of Needs survey is
necessary to support the conclusions of the Survey. RUQuS provides
a variety of documentation data types including:
- Capital improvement Plan (CIP)
33
-------
~ ^nitration/inflow (I/I) Analyst,
- Sewer system Evaluation Survey
- Final Engineer's Estimate
- Cost of Previous comparable Construction
- Facility Plan
- Plan of study (POS)
- state Project Priority List
- state-Approved Area wide or Regional Basin Plan
- Grant Application
- Municipal Compliance Plan (MCP)
- Diagnostic Evaluation
- Administrative Orders
- Court Orders or Consent Decrees
- Sanitary Survey
- State-Approved Local Comprehensive Water and Sewer Plan
- State Certification of Excessive Plow
- State-Approved Municipal Wasteland Allocation.
In order to support the separate needs of the states,
RUQuS retains and services all undocumented facilities. State
Meeds data are stored in the same fashion as are Needs facilities
records with the exception of an additional flag indicating the
record as state only.
3.3.1
System Data Base
The Needs Survey data base contains cost and technical
information on approximately 24,133 wastewater treatment and
collection facilities nationwide, including facilities with unmet
needs and those for which needs have already been met.
The Keeds/RUQus data base is a single inverted file
structure which utilizes In-house Software (IKS).
-------
3.3.2
PilM
RUQUS data i, .tor* in
contain* all the application record
IHS
**** flU WhiCh
3.4
3.4.1
Hardware
Type
RUQuS and the Needs data base are active on the IBM 3090
Located at the NCC.
Peripherals
3,4.2
Peripherals selected for RUQuS/Needs are at the
discretion of the user, however, peripherals selected must be able
to emulate an IBM 3270 or VT-100 and have telecommunications
software. An asynchronous modem with 1200 to 2400 baud is also
required.
3 . 5 Software
PL1 is used extensively for RUQuS software.
>
3.5.1 On-Line »
PL1, Assembler, and COBOL are used for RUQuS screens and
online programs. The programs are run in the ISPF environment.
3.5.2
Batch
PLl, Assembler, and COBOL are used for RUQuS batch
programming needs.
3.5.3
Communications
Any terminal or PC used to access RUQuS must use
Crosstalk or an equivalent.
4.0 System Functions
RUQuS is an on-line, full screen software system which
provides data input and querying capabilities for the EPA's Needs
Survey data base. RUQuS's primary purpose is for use by EPA and
the states as a management tool for analyzing and inputing Heeds
Survey data and generating custom-made reports. Eventually, RUQuS
will help link the major Office of Water data bases and will
support the management of the State Revolving Loan Program. In
order to effectively depict the costs and needs of sites. Needs
must have the technical support to allow for the entry, updating
and retrieval of all necessary survey data including flow,
effluent, liquid, liquid effluent disposal, treatment and sludge
-------
, and
Vs in lin-by-Un.
syst«m Input
.
Data ar« input
screens .
4'111 r^- «
4 2 system output
'
O.n.r.l
4.2.2 Reports
RtJQuS provides a variety of reports, including standard
and custom report generation, via the General Query function.
Facility fact sheets (FPS) comprise standard reports and are
available as either a two or three page report. The two page
report contains all survey data. The three page report contains
-11 survey data plus review record data such as historical screen,
**~—' •*• code status.
S£s«»=5-
-------
5.1 U««r Clung* control Proc«»«
S.I.I System Enhancements
»««••• *nh«nc«»«nt rsqu«»t« to their
Users report any «y«ta* "w
Keeds Survey Regional Representative.
_ „ . „ uarkoroup r«vi«ws all «nhanc«n«nts
Th« N««da Survey WorKgrw«r h
submitted, and prioritizas th« acc.pt«d changes.
reflect the changes.
5.1.2 System Problems
Users report system problem, or bugs to the User Hot-
Line.
*
The status of syst« probl«» i. reflected on the
Bulletin Board.
5.2
5.2.1
Technical change Control Process
Change Control System Design
A development/test version of software is kept separate
from production.
5.2.2 Change control Documents
A change control log is maintained for system problems
and enhancements. The log resides in a TSO data set.
5.2.3
Change Control Activity
Changes to Meeds are examined, and approved or rejected
by the Needs Workgroup. Needs technical staff modifies the
software necessary to facilitate the change(s).
5.2.4
Change Control Testing
37
-------
5.2.5 Change Control
After a th<
software to the production
5.0
User Documentation
U.S. 1988 H««ds Survey User Manual
RUQuS User's Guide
functions .
6.2 Technical Documentation
No technical documentation exists for RUQuS outside of
the commented statements inside the software programs.
6.3 Data Dictionary
A data dictionary is maintained and accessible on-line
through the TSO environment. The Needs data base data dictionary
was written in IKS.
-------
Appendix I
Sample System Function Screens
39
-------
oriaoes
npc HOUSE/"
OPTIOH -»->
tfta «*at*at iad of«s»tioa of
* «*• 'r **»*
.
K KEIBS lOttOS - Of *•*•
OAT&
i llf «U«ti«»> 4,»»*»»*—V —
ft
R 1EACH
«ad
s
KETS PfKITS
prSHOU PfKETS
'
conntxTS =
40
-------
' 1
MESDS
connAKO »»•>
TftltC 0*
. »*TS
»1«*T"
a »
VIISXOM I IS Wf AND
KEU section cH«r HEADS ar
or TODAY - nuei
S01»*t (•••
•ay b« int«r««t«d ia;
"ild."tn."i;;rior;;;.'infor..tion.
,-, rxit • »«tr tins
flEHBEl T/l 0 A«. TIM I«T
GOOD»« 0 *° MOJ1..13** J«
IASVEGAS 0 14 tf«11». OM J« —-- -0~ -„ KIMS
MTU*LTT» 0 ««6 »*0116.i»*» r** — •-«
"illOMt 0 24 »OH5.t7Z7 P«
..jrjr.1."..."^.:'.0.^""""""""
COHRAKOS:
UEI.COHZ STI.»II
.il.ston.s
column.
41
-------
1 r
HCtDS
coniUHB •«•>
NXSBS SVtVBT
SXCUtlTT COB»»««> XXXXXX
JS?*1..•>««««» <— DATA rot TKESC
txxstxm »/r Nvitict ••"' ;" <—
SHOtT tQClfCKIIBU*9> "** * < '?"!„« TM1OUGK
GENCtAl ftgitt -••> * „ .„> x < ..XX lj"
SUWlAtlZC/AKAlttt OSXXa OWItAt ««« nmm> , < i«031* AT
sutvct STATUS txrotT ...> xxxxxxxxx
1D0 Ht« A/F KOHBCt
rtJfl AtL EttOtS (T Ot Ml •••>_!!
SCtMK SEttUXKCX (6 Ot 1> —> »
ptXVXOUS KIXBS SUt»EtS
BtOUSC
connxKtS'
- Th«
o go back to tho «•,*«» »*-_».,
to aeeoss a holy soxooa
^
Kaods Suxvoy Solootion Honu is uso
aad 6oa*xal 9u«xy
- All options undor th* 1984 Hoods Suxvoy data has* roqui.ro
th* us*x to ontor an assigned auttUS toeurity eod*
- All facility data oa th* Fact Shoot Scxoons aco euxzont up
to th* soeond; houovor. uhon ^uorying (ia Short 9uoey oc
Conoral ftuocy). data o.u*xi*« upon is cuxront up to tho oost
roeont updat* as shown on th* uppox right portion, of this
sexoon
-«• «-»«««» Baa »»««»» •••••••••**«»»***>«
-------
conrtAKO •»•>
a/r
«,t.otxtt.
cmturz status i
Stltttl .
OAtX
S7110».tS37
87M09.1S37
(71109.1S37
871109.1537
471109.1537
»71109.1537
871109.1537
•71109.1537
871109.1S37
871109.1S37
871109.1537
871109.1537
871109. 1537
871109.1S37
r*c.
.••••*
• ' "7
CQ«KTt mi*
CaftaCK
USt QtBatt OH* «««'6 AT
ticnzxT
KCBX
MICZ
MCB«
MCCT
PP11T
rrttt
PPtXT
PMKT
prate
PPtKC
prixc
FEXtOT
rrotot
OtO
1S1003
1SZ003
9811
98«10
341000
86732
7992S
240X
28. SO
57.56
IS9092
9800
9800
100193
879H*
81267
Z8.8S
58.29
fct or
10«.7
10H.7
99.8
99.8
101.«i
101 .7
101 .1
t01 .7
101 .U
101.7
10 1 .<*
101.7
181.2
101.3
connAMDS: to 9« to th* MiatoKieml l«»i«u s«c*«n
to 90 to th« txistiaf Com»«ivt* Sec««n
<£NB> to go to th« Fact Sh««t Data 3cc««n*
to »cc««a a h«lp *ero,*n
to return to tlx* K««d* Suzvoy S«l*etion K«AU ot to 90
on to th« n«nt s*l««t*d facility. Aborting th« updat.
to go to th« Pziax Xnfozaation Scz**n
to us* prowiouxlr stot«d yxiat iaiozmation
COHRCKTS: - Th« SuMaxy Kftvicu Sera«a is us«ful whan uantin? to quickly
dataraino tha 4»tas and raviau status of tha «ost raeant
chaix9«s aada to m facility
- In tha zaviau scraan. "old" and "naw"^ data alaaants aza
disvlayad along uith tha X ehang*
43
-------
SCmQLL
x» **•
• •> at
t/r K«I»«'
_
COOH1T «•»
_.„«.,« COUKtT
rac. K»nE» c*noeH ^
CQOICTT» CAM**11
SIP »
—, *«0316 »T 2032
tPl lilt HfBAtC OK* »*"
cattCKt status i
PtEVXOaS StAtaa*
0&t I
871109.1537
871109.1537
871109.1537
871109.1537
871109.1537
871109.1537
871109.1537
871109-1537
,71109.1537
871109.1537
,71109.1537
871109.1537
871109.1537
,71109-1537
.....« — •"•••••'
MI *7110«. '»"
HOME
eiEHEICT
KECX
KEOV
MECV
PPftftT
PF11T
ppurc
prtxt
PP11C
PF11C
PPtMC
prute
FEXTOT
rroiot
HftCODE1 Ri
..—»-—
J._ *h. suaa*]
o» vaiac
15200)
9*21
9*21
9**10
3*2000
1H«1
2*02
8f732
79925
m««
2*02
20.50
57. S«
IXITI*tS« «**
,•••••»•»"•••••"••
cy t««iou Scso«»
..«.< «>t.llE
MEM »**«w*
1S9092
9*00
9*00
100193
4 . AM If
3**™ ' '
I***
21*2
879**
81267
« te • 1&
1 H*1
2**2
2*.*S
5*.t9
,.«.««-««*»"
pet or
10*. 7
99.*
99.*
101- <*
101.7
toi .*
101.7
101 ."»
101.7
101. *
lOt .7
101 . Z
101- 3
i. •«»•"•*
to 90 to th«
to a
to
- tho Hixtotieal lo«i*u Sezoon
109 o£ all th» data ehan««*
- In tho taviou scc«*n. "old" and "now"
dispLayad along with th* X ehaag*
a ...»!•«• hi««««iemi
facility
data •!•»•«*»
»r«
44
-------
< I
eonrtAMD
AXF NvnBcm
suit coiuimw
_^^ ix i» tA'%"
xxxxxxxxx
COM' XX
rfccI»-«T K»nt: xxxxxxxxxxxxxxxxxxxxxxxx.
««*ALS> XXX B»T«-*ln*' XXXXXX.XXXX
t cQiuiixTS coii> «« !SSxxx«xxxxxxiixxx***«™"**x«™***x*:
ysssssssssssss^g^sssssss^^^^
^SSSS^ISS^^SSS^S^^^
;xxxx»xxxxxxxxxxxxxxxxxxxxxxxx>* IIts, „, B*ie;«5;ixxxxx«xixxxx
—coraix" «";,rx«xxxSS*«»«««!«"211SS^^^^
RESIOMAI. COIUIXXTS
xxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxx****--;--
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
XXXXXXXX**********«***»»-""-_..
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx»* XXXXXXXXXXXXXxxxx
;XXxxxxxxxxxxxxxxxxxxxxxxxxxxxxx^ijiisj xxx OA
H2 COrtOEKtS
.......
to
t.
to
- th. Existin,
-t. S.«.. "JJ'SI*!"
ea
45
-------
coma** —*
«•«* **!!!*
i/' x*"**™
n^^w
Ham
•> X
: xxxxxxxxx
NfBCS
st»t««
city «*«••
county Kama •'
county Hu«b«t -> XXXXX
r*"_JI.-.« TO «> XXXXXXXXX
Deductions «•> XXXXXXXX
«> xxxxxxxxx
»> x
'*
rutuza
v vvXXXXXX ««> XXXXXXXX
..> xxxxxxxx ••> xxxxx***
Gt
»nt Mu«b«*«
xxxxxxxx
xxxxxxxx
xxxxxxxx
xxxxxxxx
xxxxxxxx
xxxxxxxx
xxxxxxxx
xxxxxxxx
: XXXXXXXX
comuixD «••>
K«itt Scraon »> X
Efft MX*»» *»**••»•— -
r.t««ory 0«»i«n T«a*
cat«***r >B> XXJtxxMX
z -•> xxxxxxxx
,. -•> xxxxxxxx
,_ ..> xxxxxxxx
;.. .-> xxxxxxxx
u. --> XXXXXXXX
5 ..> XXXXXXXX
— roPOLATlOM BA« (S«E=*
>«vv«YXX
• *>
»">
• •>
• «>
• •>
• •>
«->
1 ?)-
currant
xxxxxxxx
xxxxxxxx
xxxxxxxx
xxxxxxxx
xxxxxxxx
xxxxxxxx
xxxxxxxx
Ooc
*•>
»«>
«•>
>•>
-»>
m«>
• •>
typ«
XXX
XXX
XXX
XXX
XXX
XXX
XXX
Futur.
MO COll
> XXXXXXXX
> xxxxxxxx
rutur.
KO C011
.> xxxxxxxx
;.; c.11
., „»«« -«» ««»»" -» """"
., IXIxx«x ."> «»««» —' """"
Kon-tos
Coll
KO
.> xxxxxxxx «
.> xxxxxxxx -
«-> XXXXXXXX -»«> XXXXXXXX
«»> xxxxxxxx *•*> xxxxxxxx
46
-------
-riou
cscactH
conntM»
N«Bt ««••» •> *
> xxxxxxxxx
rto«
OF
total — > XXXXXXX
Industrial -»»> XXXXX**
Ra.idantial = XXXXXXX
Ctotal flou -
.»•> xxxxxxx «»•> ixxxxxx
ia*> ZXXXXZZ
,..> xxxxxxx
. XXXXXXX
•. zxxxxzx
conruKD «••>
Maxt Option *> X
OAT* CSCMCK o
xxxxxxxxx
prasant
.«»> X
rutura
»»«> X
u c
X X
DISPOSAL or
DOC
«»»> XXX
o u c
»»«>
too >
SUS Sol >
Phos >
Aamonia >
PH
Ta»p *
o.o. >
K Oaox >
EXXSTIXG
Iniluant Ciiluant
XXXXXXX
xxxxxxx
xxxxxxx
xxxxxxx
xxxxxxx
xxxxxxx
xxxxxxx
xxxxxxx
> xxxxxxx
> xxxxxxx
> xxxxxxx
> xxxxxxx
> xxxxxxx
> xxxxxxx
> xxxxxxx
> xxxxxxx
COKCCKT1ATXQKS. rtOKTHlt XTtHOtS
PEESEKT OESX8K— —•-rUTEIX
Effluant
> xxxxxxs
> xxxxxxx
> xxxxxxz
> xxxxxxz
> xxxxxxz
> xxxxxxz
> xxxxxxz
> xxxxxxz
lafluant
> xxxxxxx
> xxxxxxx
> xxxxxxx
> XXXXXXX
> XXXXXXX
> xxxxxxx
> XXXXXXX
> xxxxxxx
liiluai*
> ZXXXXIX
> ixxxxzx
> IXXXXIX
> IXXXXZX
> IXXXXIX
> IXXXXI1
> SXXXXIX
> IXXXXIX
xxxxxxxxx
placaCoda>
,m»>
xxxx
TOXIC
xxxx «•«>
xxxx
*«•>
cotis-
xxxz
xxxz
*>*>
II*>
XXXI
xxxz
xxx
OtSIOH
Lsilues.*
> IXXXXIX
> IXXXXIX
> ixxxzix
> IXXXXIX
> IXXXXIX
> xxxxsix
> IXXXT.IX
> IXXXSIS.
s»i> XXT.X
«,t> xxri
47
-------
connAMo ••»>
K*xt optioa •>
— unit rioctis DATA octtcK
A/r Mu*b*C : XXXXXXXXX
•— iou x or
SCtOlJ. »««> X
Facility Status
Matuc* Pt*s*nt
- 7A -«>
- 7» ..>
Katuz* *roj«ct*d - 7C -«>
facility Chmn«« - 7n «•> x
> x
stt
XX
XX
XX
XX
XX
XX
XX
XX
XX
XX
XX
X
X
X
X
X
X
X
X
X
X
X
Chma«*
X
X
X
X
X
X
X
X
X
X
X
connAMD •-•>
-niSCClLAXCOUS DAtA (SCtXCK H)-
X*xt Scz**iv *> X A/f Ku«h«t = XXXXXXXXX
Phas«d/S*t««at*4 C Hon"Ph«*«4/Korv-S*9««nt«d Info
Award
Status
: X >
= X '•
• X
axes
Kua
XXXXXXXXX
XXXXXXXXX
XXXXXXXXX
Ptoj
Cost
= XXXXXXXXX
: XXXXXXXXX
: XXXXXXXXX
Fun*
Out*
xxxxxx
xxxxxx
xxxxxx
P/S
• X
: X
> X
X
X
X
X
X
X
3X
•• x
' X
X
R«»eh Nuaa«S «««> XXXXXXXXXXX
1971 P«f t«^ Coil «•«> XXXXXXXXX
CoM«nt Cod«s «»> XXXX
9t-SOO/Sub funding «»»> X
Can9x«ssi«n«l District ««•> XXXX
Location Codos «»«> XXXX
facility tatitudo. *>» XXXXXX
facility Lon^titud* -««> XXXXXXX
taach nil«s <<*> ixxxxr.
Subbasin Kuab«c ***> xx
stcoaa Us* -»*> xxxxxx
Coaplianca Status >«» x
najoz/ninoc Status »»*> X
Co*fllianeo Souxc* ***> xxxxx
Compliant* Oat** *-«> XXX
Coasliane*
co***nt -«> XXXXXXXXXXXixxxxxra:
4S
-------
conn»»» ""*
X*«t Of ti«« •> *
* "
. MMXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Tltl. -"_• """"
••
__________ conncKts
s
".'.'^
«»«•«»»««••"*****
_______________ 5TAtE ESTIHATE OAT* CSC1EEK S)
COHtlAKD -•»>
H.Kt Scr««n «> X
>
XXXXXXXX
XXXXXXXX
xxxxxxxx
xxxxxxxx
xxxxxxxx
XXX
xx*
,wl> "xxxxxxxxxxxxxxxxxx x JX
st»Li> xxxxxxxxxxxxxxxxxxxxxxxxx xxxxxx
STAL3> XXXXXXXXXXXXXXXXXXXXXXXXX | xxxxxx
xxxxxx
49
-------
1 1
conn*** '""*
«•«* **•**
"'»'*> "SSSSSSSZ S ;>
sis?.
,«««*»'
yj
POPUtXTIOM XK9 FIOH OWJL CSCICEX
connxKO »«•>
H«xt Scr»«n «> H
X/f Kuabtt • XXXXXXXXX
«««»0?Ut*tIOM
ft«*id«nt t**id*nt
Ho Coll «••« Coll Ho Tr»t «««
»«•> XXXXXXXX ••»> XXXXXXXX «««> XXXXXXXX ««> XXXXXXXX
««»> XXXXXXXX «"«> XXXXXXXX -•«> XXXXXXXX «•«> XXXXXXXX
wan-ft** H«n-R.««
- - »-«v
txxxxxxx
«.,,T.»tIOM OXt*«" ^
K*c tr»t
'—•"""""" .„.,., «.;». srrit
Koa-»«»
-------
COmtANO "••>
K««t S«M«» -> X
TOXIC
IJJ*JM, „
Projected
> XXX > XXX
Oocuiont Titl* •«•>
Authex •••>
oat* ciTtinoo) ••»>
.>
«««HlSCtLLANCO«S OATA«««
197Z Pop *«1 Coll
Co«»«nt co«U»
92-SOO/Sub Funding
congr.ssionml Oisttiet
Location CodM
Dun £ Bt»dstr««t Mo.
•> xxxxxxxxxxx
«> XXXXXXXX
.> xxxx
«> X
«> xxxx
• > XX
-> XXXXXXXXX
Reach nil**
On l«aeh
Strata Us*
Facility L»ti*u4«
Facility Lon«itud«
Plac* Cod*
=> xxxxxx
= > x
»> XX
«> XX XX
*> xxxxxx
»> xxxxxx
.»> XXXX
connAMD •*•>
AMD UXIT P10CCSS DATA (SC1EEK X)
ROU 1 OF
SCROLL -==> C
OISPOSAI or tiauio EFFLUENTS
C 0«C OU
Kext
Screen *> S
u « <-
— m. U u |«
---•» * * Y *
»»> XXX =*=
A/F Xumber : XXXXXXXXX =•-•' * * * ~ „ „
«"COXCEMTaATIOMS DATA CHG/L)*"
EXISTING PRESENT OCSIGX FUTURE
Influent Effluent Influent Effluent Influent
BOO > XXXXXXX > XXXXXXX > XXXXXXX > XXXXXXX > XXXXXXX
Sus Sol > XXXXXXX > XXXXXXX > XXXXXXX > XXXXXXX > XXXXXXX
Phos > XXXXXXX > XXXXXXX > XXXXXXX > XXXXXXX > XXXXXXX
Acaaonia > XXXXXXX > XXXXXXX > XXXXXXX > XXXXXXX > XXXXXXX
pH > XXXXXXX > XXXXXXX > XXXXXXX > XXXXXXX > XXXXXXX
T*«p > XXXXXXX > XXXXXXX > XXXXXXX > XXXXXXX > XXXXXXX
D.O. > XXXXXXX > XXXXXXX > XXXXXXX > XXXXXXX > XXXXXXX
K Deox > XXXXXXX > XXXXXXX > XXXXXXX > XXXXXXX > XXXXXXX
•"UNIT PROCESS OATA»" Pres Effluent
SEX. Tteataent Type Use Chan?* Fut Effluent
v Y v y
A A n «
XX
XX
XX
xx
XX
X
X
X
X
X
A
X
X
X
X
> X X X
DESIGX
Effluent
> XXXXXXX
> xxxxxxx
> xxxxxxx
> xxxxxxx
> xxxxxxx
> xxxxxxx
> xxxxxxx
> xxxxxxx.
= = *> X
= »»> X
51
-------
.....— -o
mmmm ft »KO * SC»«X V«»SXOI*» "
,.••••••"••"•••••"••"•••""
<** ** !• *•
t«
<•!!»> t* !«••*• * * * to ««•«** uitli««t ufdmtiftf
t« «•*«*• t «« r*:i*. infozmmtion S«z*«a
-------
COftflAKD • ••>
«»
Facility Maa*
NFOCS Kuabar
City Kama
County Xa>«
i Cod* or
Stat« »bhr«vi»tioa
...> XXXXXXXX TO
,..> XX
„>
xiixxxrx
** Tna r»**^*4t., _
(KKDtCAD). is
a Salactad Facility Tail
ation of tha £ollouia$ c
City Kaa*. Cotaty Haa*
• th* facility S*l«ctio£ Sczaaa is csaful uh«a uantia? to
updata or r««iau faeilitias 5? cocaty, iot isstaaea. or
for finding iacilitias foe «iich you do aot iaou -^ie A/r I.
**««>**»*>ia«*B*aB***a«««a*a****a**a»BB»«**a'>axsx»**x*x*aassxsx23::
S3
-------
connAMO
• •«>
•**>
eati 1 of <
scaott. •••> a«
ex n*sse • »•:
"'
s
-
-
l6llltt
H20020001
AOtHOtITT
tHOCNXXVXLlC
SOOTH COATCS
UCSt CKCSTCK
ittoonooot
.,20052001
S»tXX03 CXtt
«»20061001
(420070001
H20071001
.,20071002
1,20076001
K20079001
oxroto ««f
CPMMtlttf
t»ST VIKCIKT
TAItOt MK «
QOOSX CIECK *t»
""
**"
QXfOftB
UtSt
tLVtlSOK SS
t«»
*"
H20086001
H20095001
1*20097001
KOITH COVtKTlt
\iw»»«———
sftxxa CITY
UEST CHtSTtl
UEST CHESTER
EXTOK
etVEXSOX
KEMXETT Stt«*«
UEST a*OVE
LOKOOK saovE
HOKETtMOK
K COVEHTXY
«a
COnnXKTS
« -
to sczoll up on* »«««<_..
to sczoll down on* scr««n
to go back to th* Facility Selection Screen (if in
Shozt au*zy) ox to th* K**ds Survey Selection Sczeon
(if in General 3u*zy>
to access a h*lp scz**n
Th* S*l*ct*d Facility Y&bl* displays all th* facilities
selected »ith*r through Shozt ftuery or General Query
- Although th«r* is no limit to th* number of facilities that
can b* selected, only 20 will be displayed at a tiae on the
screen. Us* th* sezoll commands to go up or doun the table
- To select facilities foe update oz zeviou. tab doun the
left-hand column and typo in an beside each A/F nu«
you wish to see,
- Uh*n finished with th* facilities selected, you will be
returned to th* Selected Facility Tabl*. Th* "S" markers
will b* conveztod to "m* to indicate that tho facilities
haw* b**n reviewed.
• Us* SELECT Alt to select all of the facilities on a screen
foz review oz update by placing an at th* prompt.
- Us* VALIDATE EX flASSE to do a mass update of facilities foe
either all th* A/F Mumb«zs selected through placing an *S*
in th* loft column oz by selecting all A/F numbers through
SELECT Alt. An Update Validation Screen will appear to
update all the A/F numbers chosen. Only on* screen can be
mass updated at a tim*.
«»aaa»a»»«»B»»»«»«»«»»«•««»»•»•»»»•»«»»»•»»»«»•»•«»****»*»»****--
-------
conn*MO
r*!**
XXXX
-TM .
BOX/*11*
COHMIIH-
""""
<«»>
•«•«
Lik.ly t«
b« printed
Fmet Sh««t Scr««n*
. „.
2.
3.
=.«" -> r.r.J%£ .»:«•'" -"•
Ft » Us«c ID («.9..
a*«a*»a***
-------
IBS 6«aecai auery Facility
sanoio
teieese oate< 01/1«/»«
« « *— NXCDS*« —« « »
Prompting Levels*
«•• 7.UICK — For the expert user.
K: XOMUL — For th« «icp«ri«ne«d u*«r,
V: VC180SC — Foe th« b«ffinftin? us«c.
KCtBSA*.
n»in B*nu: You h&«« th« following froa uhieh to choose
X: Exit. Don* with S«r for now.
H: H«l>. Disflay s«l«ction, descriptions.
0> Diet. Disffl«y the «»tm «l*««nt 4i«tion«zy.
C: Celt. Catec or modify data set«*nii\s critorim.
o: Out. Cater or modify output report specifications.
S: Sott. tatec or modify sorting specifications.
a: »eks. tater or modify actions at coatrol breaks.
K: Keep. Keep tuery specifications in a library.
L: Load. Load fuery specifications from a library.
E: Exec. Execute the «,uery.
For help, enter "H" followed by the Latter for which you want help.
Example: For help uith selecting the C<cazi option, enter "HC".
Uhich would you like?
56
-------
Selection Crit. You have the
X: Exit, aeturn to the
K: Hew. Enter all i
«ftl"M
»
data
t-
E: Edit. Oodify
Add additional
i. Display soee
thi* * v'
this
Foe help.
Example1 Toe
Uhich uould you like?
Output:
the following
Done specifying the output format.
Eater all new output specifications.
Display the output specifications alzeady entered.
(lake modifications to the existing output specs.
Add neu specifications to those already stored.
Select one of the standard, fixed-format eepocts.
Turn off standard ceport and let you specify the format.
Enter ceport title(s).
Direct report output to a data file.
Get further information about this menu.
for help, enter "H" followed by the letter for which you want help.
Example: for help with selecting HEW specifications, enter "HH".
Uhich would you like?
X: Exit.
H' *•»••
I.: List.
E: Edit.
Hi Add.
S'- Std.
U: user.
TS Titl.
r- rile.
K: Help.
57
-------
_ t $T»T«S rt e * « "
s u « rt *
conn»MB --->
f0 .-> x*xx« SHOH
tS> 10
CT> K*> t> «> no> C0>
MT> nc>
nt> OK> KS> KB> CU>
KR> S0> > , UJl
Vt> P1>
ns> o«> tx> «T> KV>
tt>
KC>
SO SELECT ILL REGXOKS =
TH>
to 90
CQnn&KOS*.
t« tceos* a h*lr «cx*«a
COPirtEKTS-- - Th« Sua»acy St*tus tt«au »llous you to ehoost'th* st»t* *nd/
or t?l t«9ion foe which you want to obtain a Suxvty status
laport.
• Jlceo.»* to K««da information i* autoaatically castrictad by
tha aa*«uoKd saeucity systaa, . Than typa in an basida "SHOU
OOlLAtS?" if you want a raaoct showing Kaads dollar aaounts
This raport will ba currant to tha last systaa u?data.
displayad on tha Maads Susvay Salaction Ranu and on tha
scraan.
«»»«a«»»««aaaa*a»=»»»=i3
dispay
top of this scraan.
»»«m»
58
-------
conn**0"*
ST
19
Ot
no
PA
VA
uv
DC
a u it n » x t
»ll-t» OVBATID OFBITKB
Ntces * • r&es nuns *
M
Sift
1,713
213
0
2.981
it 864
1
490
490
0
no
is*
o
t«*»
2SS
T
»*
•I
^
nr
» T U
03Z2
KCQXC
IVXIIt/J
O/
O/
O/
0^
f
O/
O/
o/
ox
nivi
* K C f
(OOttAES
)N HI
LCCFTO ti
0
0
0
o
' 0
0
0
. 0 * T
IK P"11-!-
eA8««*«
i»xw*c
o/
«*«/•
3/
O/
13/
I/
65/
65/
aou
IOKS)
SCROLL
:tts H
XPTO M
0
44
3
0
13
1
61
61
\ or
• »> cs
ft ACC
:etos *
0
7
2
0
8
25S
27t
272
b*E of
»
,,••••>•<
59
-------
tl0H AMD acn*axs
~«*XXXXX FUCStlTt
PLCASC VCEIFT \*1 MO. « XX«**M
UVOATC V4LIO*
connAxo ••*•>
m •> lt«w*e-»—— •"'—•—•—•— -••—••• «•-•——
..> xxxxxxxxxxxxxxxxxxxx«xx*j—----xxxixxxxxxxxxxxxxxxxxxx»«*»*---—-—
..> xxxxxxxxxxxxxxxxxxxxxxxxxxx« KKMjiKMJiMlttJ{XXXXxxxxxxxxKixx
..> XXXXXXXXXXXXXXXXXXXXXXXXXXXK**
««a«»»*«-««1
—
last sta»e «ia*B.u*Z* conn»Ml> ••• > »*••»*• lls
cen be entexe* »*.^t.C;racc.ss a help «***»
the
u««4 ii *
^
- TH« Updmt« V»Xtd»tion and l«a*xks Scc««n =*".
Z. Type in the tevieu Cede «SH> ii the S-»t« is hapsy
with the data inputted, o: ii the State uan^s to
subeit an intezie update).
1. Type in yeuz initials.
4. Type in specific comments eelatad te ti« update oi th*
facility. These uill hei; the £?l ta»-.»u*t ?e usi*:-
stand changes te the facility.
- By pressing tKTtt after typii? in *.i« abov* Ln.ictai-.cn.
the user uill be eetuxned ts the Ktads Survey s*l*eiion
nenu or to the next selected facility.
a»»»«»»»«»«»»a««»a»»««a»»>i»»*i»»«i = :
60
-------
Appendix II
Documentation Matrix
61
-------
62
-------
2.2 C1RCLIS SYSTEM PROFILE
-------
64
-------
EPA MAJOR SYSTEMS PROFILE
1.0
1.1
1.2
2.0
2.1
2.2
3.0
3.1
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.3
3.3.1
3.3.2
3.4
3.4.1
3.4.2
3.5
3.5.1
3.5.2
3.5.3
4.0
4.1
4.1.1
4.1.2
System
System Purpose
System Background
User Envirpninent
User Support
User Training
Technical Overview
Hardware/Software Environment
Subsystem Environments
Data Entry
Data Edits
Updates
Data Retrieval
Data
System Data Base
Files
Hardware
Type
Peripherals
Software
On-Line
Batch
Communications
System Functions
System Input
Data Input
Update
65
-------
4.2 System Output
4.2.1 Ad Hoc Data Retrieval
4.2.2 Reports
5.0
5.i User Change Control Process
5.1.1 System Enhancements
5! 1.2 system Problems
5.2 Technical change Control Process
s 2 ! Change Control System Design
| 22 Change Control Documents
|'5 3 Change Control Activity
I 2 4 Change Control Testing
I'l'l Change Control Implementation
6.0 Qntat ion
6.1 User Documentation
6.2 Technical Documentation
6.3 Data Dictionary
-------
1.0
1.1
System Purpose
The purpose of the comprehensive Environmental Response,
compensation and Liability information System (CERCLIS) is to
provide tracking, scheduling, and financial management services to
regional sites in support of the Comprehensive Environmental
Response Compensation and Liability Act (CERCLA). CERCLIS is a
tool which helps a region or site to meet Superfund program
management and reporting needs. The data maintained in CERCLIS
include regional site information which is available through a
regional area network called WasteLAN and through direct linkup to
the mainframe. Other site-related information includes financial
information such as budget allowances, administrative data such as
targets and accomplishments, event tracking, site information, and
enforcement activities.
1.2
System Background
CERCLIS was developed by the Office of Solid Waste
Emergency Response (OSWER) to support the Superfund program.
Superfund provides a mechanism to track and clean up hazardous
waste sites located throughout the ten national regions. Each
region's activities are tracked through CERCLIS and are monitored
both regionally and by headquarters.
Originally, CERCLIS was planned as a site inventory
application. However, CERCLIS was expanded to accommodate other
non-site specific and site-related functions, previously available
through systems external to CERCLIS. CERCLIS expanded to maintain
all necessary functions for operation under one integrated system,
the "new" CERCLIS. The systems made obsolete by this expansion are
the Removal Tracking System (RTS), Removal-Remedial Financial
System (RRFS), and the Case Management System (CMS). CERCLIS
integrated the Superfund Comprehensive Accomplishments Plan (SCAP)
into the "new" system as well. Therefore, CERCLIS is currently a
full functioning system supporting all activities necessary for the
collection and reporting of an integrated Superfund program with
project management information.
To date, CERCLIS has been implemented in all ten regions.
Two regions are currently utilizing the WasteLAN, while the
remaining regions plan to link up to the regional area network
shortly. Those regions and users not accessing CERCLIS via
WasteLAN are currently accessing CERCHS directly on the mainframe.
CERCLIS is currently in the production stage of its life
cycle. During the development stage, CERCLIS was piloted at
designated regions to provide a real world environment for system
testing. During the pilot, CERCLIS was modified to correct
problems and enhance performance. Currently, additional computing
resources and mirror image copies of the data base are used to
67
-------
alow response tim« *nd accommodate user community needs.
Headquarters has access to tha CERHELP saction of
CERCLIS and is rasponsibla for maintaining non-sita specific data
and CERCLXS rafaranca tables, regional uaara hava accaaa to tha
entire CERCLIS systaa, including CERHELP.
2.0 User Environment:
Tha user community consists of Headquarters staff, tha
Army Corps of Engineers and tha regional sita staff which includes
an Information Management Coordinator (IMC), Data Administrator
(DA), Data Base Administrator (DBA), and Data Handler (DH).
Headquarters accesses the data contained in the CERHELP data base
and updates tha coda files and tables contained in CERHELP. The
Army Corps of Engineers is integrated with CERCLIS at some sites
and take on tha functions of site personnel since they are
contracted through the EPA to perform cleanup activities.
Each region should have an IMC, DA, DBA, and DH. The IMC
is responsible for the Superfund program and systems management
activities and will coordinate with tha Environmental Services and
Management divisions where necessary. The DA is responsible for
directly maintaining and managing CEP.CLIS. Tha DA also conducts
QA/QC activities, generates and designs reports, performs CERCLIS
queries, maintains tha regional CERCLIS data element dictionary,
maintains tha documentation library, and coordinates and conducts
regional training. DBA functions aro more technical than the DA
and include the development and maintenance of regional CERCLIS
software, user support, and data quality control support:. Data
Handlers (DHs) enter data through CERCLIS data entry screens (CICS
or WastcLAN).
Contract personnel are sometimes employed to perform some
technical and data entry tasks.
2.1 User Support
The CERCLIS user group 01: CERCLIS Management Council
(CMC) as it is now called includes ten regional representatives and
ten representatives from Headquarters. The CMC meets twice a year
to discuss CERCLIS concerns and issues. The CMC is organized into
four work groups which meet at least four times a year and include
regional and Headquarters staff (IMC,DA,DBA). The four areas
supported by the work groups are: Technical Enhancement; Report
Development; Support, Training, and User Documentation; and Data
Usage and Quality Improvement. The work groups support the CMC and
the CMC reports to, coordinates with, and supports the Management
Advisory Council (MAC). Th« CMC submits proposed work plans,
analyses of issues, and problem notifications to the MAC.
The Technical Enhancement Work Group identifies,
analyzes, and plans the activities needed to improve the system's
68
-------
hardware, software, and telecommunications capabilities.
The Report Development Work Group identifies needs for
nev or upgraded standard reports, designs report layouts, and
proposes report development priorities.
The Support, Training, and User Documentation Work Group
identifies, analyzes and plans the activities needed to improve
user support services, training materials and strategies, and user
documentation .
The Data Usage and Quality Improvement Work Group
identifies the needs and planning activities necessary for the
promotion of CERCLis usage. This group ensures that the quality
of all CERCLIS data is maintained at an acceptable level, is
standard across user groups, and includes region specific data
elements .
CERCLIS news is included in two dedicated publications:
the CERCLIS Progress Report, published biweekly and the CERCLIS
Connection, published monthly. The CERCLIS Progress Report
contains information regarding development activities, training,
documentation, regional implementation status, highlights of
selected CERCLIS areas, CERCLIS idiosyncrasies, key milestones, and
meetings. The CERCLIS Connection contains update information,
discussions of target CERCLIS areas, regional report information,
practical applications for data handling, new CERCLIS information,
summaries of proposed and actual changes, Hot Line information and
upcoming system enhancements. These publications are distributed
to the regional Information Management Coordinator (IMC) .
2.2
User Training
Initial regional training is conducted by Headquarters
either at Headquarters or at the requesting region. Any subsequent
training is the responsibility of the regions and is conducted at
a regionally specified location. Initial regional training
includes classroom presentations on the CERCLIS data base schema,
system documentation and user manuals, demonstration of event and
enforcement activity screens and a session where live data are
entered. Personnel targeted for training range from senior
management to data entry support staff.
The following courses are available upon demand:
Introduction to the Enforcement Program
CERCLIS Report Writer
Genius and Interactive S2K.
Courses available through the CERCLIS training program
are Headquarters courses such as:
69
-------
Superfund ovarview
CERCLIs/WasteLAN ori«nt«tion
C1RCLIS Data Quality I»»ue»
Using a SAS interface to S2K for CERCLZS Reporting
and Customized CERCLIS Raporting.
And regional coursas such ait:
Casa Budgat CERCLIS
Raaoval osc and FHS Raconciliation Procadures
RPM/OSC CERCLIS
FMS Raconciliation
CERHELP.
In fiscal yaar '89, training materials will be
standardizad and upgradad. A Central Training Library will be
established and the CERCLIS Hot Line will be expanded to serve as
a mechanism for users to request training.
3.0
3.1
Technical Overview
Hardware/software Environment
The CERCLIS computing environment uses two IBM 3090
computers, versions 200 and 300. Th« version 200 is available for
data entry via CICS screens and the version 300 is a single user
machine dedicated to data base retrievals only.
WasteLAN is a regional area network providing
applications written in dBASE III and access to system software
such as Timeline and Teleplan.
3.2 subsystem Environment
3.2.1 Data Entry
CERCLIS supports two forms of data entry. Programs
written in CICS COBOL provida screens on the central computer.
Programs written in dBASE III provide screens for the WasteLAN
users.
3.2.2
Data Edits
Screen data are edited as they are submitted, therefore
the edit programs ara written in tlae same languages as the entry
70
-------
TIT
x"
/*T^C ^.~. „ . .
scraens; CICS COBOL and B '««i»r»lly writtan in COBOL PLEX
data diractly to tha »ainfra»« «* •_ g«« transactio
o MMrtw
B&tch upload* and downloads of
n COBOL PLEX.
f il« which i»
M
_
Batch uploads raquira tha craation o^j
aditad prior to tha application or upa ^^^ and corr«ct
submitting region is "{*£**£ tha data basa aftar passing the
transactions which ara appli*** co
edit process.
3.2.3
Updates
uniueviA»«»'»'" j ————— .— ———— —
Other batch updates occur as neeaea.
3.2.4 Retrieval
Ill for
and are
SO« r.port
the two
ous»»ix«l
to
national perspective.
3.3
Data
Wdb.«
Information retrieval in CERCLIS is related to the events
surrounding Superfund site cleanup removal activities, enforcement
activity, financial activity, budget and control activity and non-
site specific activities. Regional data ara also included. Data
related to non-site specific incident (NSI) activities reside in
the CERHELP data base. Incident and enforcement activities are
part of the data domain.
Data ara maintained regionally through wasteLAK and
centrally at tha CERCLIS mainframe. Regional data are uploaded to
the mainframe on a weekly basis to permit regional integration into
the national basa.
NSI data ara not related to a sita specific incident.
They include: Targets and Accomplishments such as, SCAP/SPHS;
Target/Measure setting and tracking, and non-site specific (NSS)
accomplishments reporting. IMC staff enters, updates, and
maintains all WasteLAN NSI data.
Budget and Control and Advice of Allowance are functions
of Superfund program management and include items like SCAP budget
development and control, and tracking of tha Advice of Allowance
process. These data are maintained by Headquarters and provided
to regions for viewing purposes only.
71
-------
Financial data may or nay not be site specific and ar«
part of the CERCLIS data base. Site-specific financial data
include obligation data, amount, operable unit and events. Non-
site specific financial data encompass all of the site-specific
data except operable unit and events.
Enforcement data include enforcement activity, planned
and actual milestone dates, scheduled and achieved milestone dates,
compliances statutes, actions required, remedies achieved,
negotiations, judicial actions, and litigation results.
site-specific data are all data involved in the
investigation, assessment, inspection, removal, etc of Superfund
sites. site-specific data include pre-remedial, remedial and
removal. Pre-remedial data are related to the initial
investigative phase of site cleanup. These activities include
site-initialization, preliminary assessment, site inspections,
expanded site inspections, list site inspections, and site hazard
ranking processing (NPL listing). Remedial data contain
information related to tracking fund financial remedial projects.
This includes activities surrounding site project completion,
forward planning, Community Relations, Corps of Engineers design,
technical assistance, and topographical mapping. Removal data
contains information related to tracking removals such as removal
action milestones and financial data.
3.3.1
Data Base
System 2000 is used as the CERCLIS mainframe data base.
The CERCLIS data base has related data bases called CERHELP and
CERTRAN. CERHELP contains non-site specific (NSS) data which are
maintained by Headquarters, and CERTRAN which is an audit trail
type of data base which contains records of all data base
transactions and who made them. System 2000 is a hierarchical data
base design.
dBASE III is used as the WastelAK regional data base
system. All the data available in the WastelAN base are regional
specific only. dBASE III is a relational data base architecture.
The CERCLIS mainframe base contains regional data that
is uploaded from the regions approximately every week. The central
base contains Enforcement information and the other side contains
data related to the events, sub-events, financial matters, and
chemicals used during site cleanup.
3.3.2
Files
Files documented for use in CERCLIS are transaction files
which are used in the upload and download process. These files are
temporary and are used as an intermediate cache to hold the data
72
-------
until it can be stripped or integrated into the data base.
3.4
3.4.1
Hardware
Typ«
CERCLIS mainframe uses an IBM 3090/200 andI an IBM
3090/300. WasteLAM uses IBM or IBM compatible personal computers.
3.4.2 Peripherals
The peripherals used in addition to the
board, full screen color ^tors,
Associated printers include the high
the local site dependent printers.
3.5
Software
CERCLIS mainframe programming languages include:
CICS COBOL
PLEX COBOL
Genius
S2K Hatural Language
SAS
1
CERCLIS/WASTELAM programming languages include:
dBASE III or equivalent
CLOOT
3.5.1
On-Lin<
CICS COBOL is used for on-line CERCLIS mainframe screens
and screen edits. dBASE III is used for on-line WasteLAM screens
and screen edits.
3.5.2
Batch
COBOL PLEX is used for batch processes on the CERCLIS
mainframe and dBASE III is used on WasteLAM.
3.5.3
Communications
Personal computers on the WasteLAM utilize Crosstalk and
Carbon Copy to support their communication needs to the CERCLIS
mainframe.
4.0
4.1
System Functions
System Input
73
-------
4.1-1
Data Input
Data are input into CERCUS and WasteLAN through several
diff««n* mechanisms: 1) FMS data download, 2) WasteLAN upload
to CERCUS, 3) CERCLIS data screens, 4) WasteLAN data entry
screens, and 5) CERHELP screens and CERHELP batch upload and
download.
1) FMS data are copied from FMS into CERCLIS. These data
are usually copied every Thursday, however the two weeks prior to
the close of a quarter and after the close of a quarter, daily
updates can be run at the Regions' request. The copy procedure
takes place in batch mode.
Once the data are in CERCLIS the regional WasteLAN
downloads the FMS central data to the respective regional LAN. The
data are then integrated into the WasteLAN data base. Reports are
generated which document all FMS activities. The WasteLAN Menu
permits access to the Download FMS Data option.
2) WasteLAN Upload to CERCLXS occurs approximately every
week. Regional WasteLAN data are uploaded to the mainframe upon
request from the IMC. The CERHELP and CERCLIS data may be loaded
separately or together. The upload process generates reports which
verify data integrity. These reports are: WasteLAN Upload Report,
which prints the keys of all records contained in the < upload and
Generate Audit Report, which lists the records that were not
accepted into CERCLIS.
3) CERCLIS data entry screens on the mainframe are a
completely separate set of screens from those on WasteLAN. once
WasteLAN is implemented in every region these screens will become
obsolete. The screens have the option to Change, Delete, and view
and are accessed through a menu. The CERCLIS data entry supports
the same functional areas that WasteLAN supports: Pre-Remedial,
Remedial, Removal, Enforcement, and Financial. Data entry screens
are designed to be user-friendly.
4) WasteLAN data entry screens are designed to be user
friendly. The screen design is color-coded, and display windows
are used for messages and help information such as a list of valid
entry codes. One of the beneficial features of WasteLAN screens
is the operator's ability to display a window which contains a list
of acceptable codes, tab to the appropriate code, and have the
system enter the selected code automatically. National Core data
elements are highlighted with an asterisk (*) to differentiate
between National and regional data. The RETURN key must be pressed
to enter data at the end of each field. At the end of the screen
the operator can store the data oir re-edit the screen. Status
lines are displayed at the bottom of every screen. The types of
screens available are menu screens, summary screens, and data
screens. Once the screens have been accessed the user can choose
Next screen; Prior screen; to Edit, Update, Add, Delete, or Exit
74
-------
the screen without applying an updat*.
5) CERHBLP data are updated by Headouart*** and the
Regions. Access to rational CERHELP data. i» made DOS*ibl« through
th« wastetAN CERHELP Maintenance Menu. This screen enable* the
operator to Insert, Edit, and Delate Headquarters defined codes in
WasteLAN. The screen allows NSI, Target/Accomplishments, Budget
Type, and Advice of Allowance codes to be updated.
The updated CERHELP data are uploaded to mainframe
CERCLIS usually every week. Once the upload process is run the
current version of mainframe CERHELP is available to be downloaded
for integration into the WasteLAN CERHELP base. These processes
are available through the Upload WasteLAN Menu. CERHELP data are
accessible to both Headquarters and regional personnel.
4.1.2
Updates
Batch loads require additional edit checks and steps in
order to integrate the file data into the receiving data base.
Updates made through mainframe CERCLIS data entry screens are
applied immediately to the CERCLIS data base after passing the edit
checks. WasteLAN data entry screens work in the same manner except
they update the regional base.
^
4.2 System output ,
4.2.1 Ad Hoc Data Retrieval
Ad hoc retrievals are used to select information from the
mainframe CERCLIS data base and regional CERCLIS data base.
Information retrieved from the mainframe CERCLIS is from the mirror
image data base which resides on the IBM 3090/300. The information
on this machine is typically one day behind actual data.
Retrievals are requested via the S2K natural language interface,
which is accessed through the corresponding option on the CERCLIS
Retrieval Screen.
WasteLAN ad hoc retrieval is available for all systems
as is CERCLIS mainframe ad hoc retrieval. The systems represented
are Pre-Remedial, Removal, Enforcement, Remedial, and Financial (a
financial system exists as part of each other system category in
addition to a separate system). Retrieval is available through the
WasteLAN Reports option, using dBASE III.
4.2.2
Reports
Ad hoc and standard
mainframe and on WasteLAN.
CERCLIS reports exist on the
Ad hoc reports are also a CERCLIS/WasteLAN feature.
Ad hoc reports can be created in a variety of formats. These
include Gantt Charts, data dumps, matrix, and Critical path.
75
-------
There are currently approximately standard ISO reports
on the «ainfra««, some of which are duplicate* of regional reports.
Reports on the mainframe integrate data fro* all the regions and
are often added as a request from the regional users. Regional
reports on the mainframe are usually reports which require a great
deal of number crunching and can be run faster on the mainframe
than on a PC. When a region requests a mainframe report the report
is printed at the computer site in Reuearch Triangle Park (RTF) or
routed to the local printer. If it is necessary the site staff can
federal express a report to the requesting Region. When a local
report is requested it is printed at the local printer, which is
connected to the requesting site.
In order to efficiently utilize CERCLIS reporting
capabilities, report usage and issuance are monitored by the Report
Development Work Group. If a report has not been requested for a
while it will be targeted for investigation. If no future need for
the report is discovered it will be removed from the Report Menu
and the system. Regions are responsible for keeping track of their
own reports.
Reports are supported by Report Library which contains
a sample page from each report accompanied by documentation
explaining the purpose of the report and describing its format.
are:
5.0
Some of the report applications which. CERCLIS supports
- SCAP, SPMS 6 SPR Planning and Evaluation Reports.
Site Summary which provides a site history and
current status.
- Planned vs. Actual which compares actual progress to
planned progress.
- Project Schedule which provides a list of action
items for next quarter.
- Delayed-Event which provides a, listing of which
activities the site has fallen behind on.
- Tickler which provides a listing of items requiring
immediate action.
Svstem Maintenance
A change control process is in effect for three types of
situations which are classified as follows:
- Tier 1 requests which the project manager makes an
immediate decision. Tier 1 requests are considered
emergency situations.
-------
- Tier
which go through th* proj«ct manager,
i* not expedited until it : has gone
Procedure outlined in 5.1.
through the formal change
, ._ _ j , _ , i.._^4AM r
5.1
User Change Control Process
1)
2)
System "problems" represent the Tier 1 and Tier 2
situations and are usually identified when a user
calls the CERCLIS Hot Line or submits a CERCLIS
Change Request Form. The process to accommodate
Tier 1 requests follows:
The Hot Line operator or technical staff member
re-creates the problem, performs an analysis to
determine the cause/source of the problem, and
documents the problem in the CERCLIS Change control
Log.
The problem is presented to the project manager, who
decides whether or not to implement the change
request.
If the problem is to be corrected the technical
staff are notified and the problem corrected.
The outcome of the Change Request is documented and
distributed to relative parties.
The Change Request Log is updated.
All changes submitted via the Hot Line are published
in the CERCLIS connection.
Tier 2 change requests are processed in the
following manner:
- The problem is identified and a Change Request
Form is submitted to Headquarters.
- The request is presented to the progress
forum where an analysis and recommendation is
prepared.
- A decision about the request is made,
documented, and distributed to appropriate
parties.
77
-------
5.1.1
- A summary off the decision is sent to the MAC.
- The chang« is implemented as indicated by th«
outcome of the decision.
3) System enhancements require user* to submit change
Request Forms to their CI1C representatives.
An open window for CERCLIS enhancements is activated
every quarter with plans to activate biyearly in the
future.
The submitted enhancements are reviewed by the
Technical Enhancement work Group who perform a
cost/benefits analysis for each request.
The results of the analysis are submitted to the MAC
who maXes the final decision as to which
enhancements will be implemented.
Once a decision is reached the MAC sends out
notifications, which indicate the status of the
enhancement, to all users who submitted requests.
System Enhancement
System enhancements or Tier 3 change requests are defined
as unsolicited changes to the system which affect original design
or processes. The mechanics of the enhancement process are
documented in section 5.1. Approved enhancements are planned and
initiated by the Technical Enhancement Work Group. System
enhancements are BETA tested.
5.1.2
System "Problems"
System "problems'* comprise Tier l and Tier 2 requests and
are defined as system inadequacies which impede the intended
function of the system. A problem is logged by the Hot Line
operator or project manager and then assigned to the technical
staff for resolution. Once the problem is corrected the log is
updated.
5.2
Technical Change Control Process
The mechanics of the technical change control process are
the same for system enhancements and system "problems." Both
require existing software to be modified and tested.
5.2.1 Change Control System Design
CERCLIS currently resides in the development
environment, however, plans to accommodate test/development and
production environments separately are in effect. The existence
-------
of a dual system environment allows software maintenance and
modification without intarrupting tha production systaa. NO
information has baan provided regarding tha typa of data available
for tha development anvironnant.
5.2.2 Changa Control Documents
Documents involved in tha changa control process are:
- CERCLIS Change Request Log
- CERCLIS Connection Publication
- CERCLIS User Change Request
- Programmer's Maintenance Manual.
5.2.3 Change control Activity
After the software has been changed the programmer(s) is
responsible for testing the change.
5.2.4
Change Control Testing
CERCLIS is not implemented in the production
environment therefore current software released is part of the
system test. ,
Formal methods for interfacing to tha NCC regarding
changes to the production environment have yet to be defined.
5.2.5
Implementation of Changes
The NCC is responsible for moving a software change from
development into production.
6.0
Documentation
Tha following list comprises tha documentation discovered
for CERCLIS:
User Documentation
CERCLIS : Regional System Administration Handbook
CERCLIS Data Element Dictionary
CERCLIS Data Entry and Retrieval Guide
CERCLIS National Reports Library
WastelAN : User's Guide to tha WasteLAN Pre-Remedial System
User's Guide to tha WastelAN Remedial System
User's Guide to tha WastelAN Removal System
User's Guide to the WastelAN Enforcement System
User's Guide to the WasteLAN CERHELP System
79
-------
Technical
6.1
CERCLXS System Documentation
CERCLIS Programmer's Manual
User Documentation
User's guides exist for each WasteLAN system and a
General Data Entry and Retrieval Guide for CERCLIS. Each guide
contains an overview of the CERCLIS or WasteLAN system as well as
detailed procedures explaining access to each subsystem including:
interactive sessions (query, ad hoc retrievals), screen displays,
prompts, and reports.
User's guides for mainframe CERCLIS are maintained by the
Support, Training, and User Documentation Work Group which reports
to the CMC.
WasteLAN documentation i» maintained by the Data
Administrator (DA), who is also responsible for the regional
documentation library. The DA issues regional documentation
updates.
6.2
Program Documentation
Technical documentation for CERCLIS is maintained by
contractor personnel. Program documentation is included in the
CERCLIS Programmer's Maintenance Manual. The manual contains
information regarding program structure, subroutines, common
elements, security, help processing, error messages, update
logging, rollback, and abend processing. The manual also lists
CICS, COBOL, and S2K programming standards. Each program is
documented by transaction id, program id, mapset, map, functions,
language, source, program type, sample screen or output, and
psuedocode.
The CERCLIS System Documentation manual contains general
documentation or CERCLIS functions/features such as: VSAM files,
implementation plan, CICS registration, system overview, program
change control, change control procedure, logs, operations and test
plan.
6.3
Data Dictionary
The CERCLIS Data Element Dictionary (DED) was originally
implemented in BASIS on the IBM 3090 mainframe. Although BASIS
provided users with an on-line search and reporting capability it
was difficult to maintain and use. Therefore, a switch to dBASE
III DED occurred. Currently, the DED is maintained in dBASE ill
and copied to floppy diskette for site distribution.
SO
-------
Appendix I
Sample System Function Screens
SI
-------
LAK MENU
Relational Report Writer
Tla«lin«
IZZ
th« UUf
MultiMat*
Lotu«
-------
K»m«:
Password:
83
-------
MAIN MENU
1) PRE-REMEOXAX,
2) REMEDIAL
3) REMOVAL
4 ) ENFORCEMENT
5) GENERIC EVENTS
6) REPORTS
7) CERHELP SYSTEM
f
0
ENTER SELECTION (1-7) or X to Exit;
84
-------
r SITX IMITIXLItXtlOK
3ITX
Scr*«a 1 of 4 —i
FMS 10 Muab*c: •
Ham*:•
Couaty : •
Own«r Indicator:*
L*tit«d«:*
DI3COVIRT
R*p«rt«d By K
Pboa* Ktwb«r
TO: m
(H]*xt, [F)r*Tiou«,
•er*«a, (C)dit or
D«t*:|
, or (C]oatiau*:( ]
85
-------
EVENT MEKO
1) SITE SELECTIOV
2) FORWARD PLANKING
3) RI/FS TRACKING
4) RECORD OF DECISION
5) WORK PLAN
6) REMEDIAL DESIGN
7) DXSZGN ASSISTANCE
8) RJQODIAX, ACTION
9) COMMUNITY RELATIOSS
10) OPERATIONS 6 MAIFTENASCE
1
11) NSl DELETION,
12) G1N2RIC EVENTS
13) KISAGEMSNT RX90RTS
ENTER SELECTION (1-13) or (M)«nu:|
j
-------
Appendix II
Documentation Matrix
87
-------
EEl-2
Preyminary Design
and Option* Analyst*
EEt-3
Project Management
Plan
EEI-4
System implementation
Ran
EEI-S
Detailed Requirements
Document
Manag«m«nt
EEI-7
Software last &
Accsptanc* Plan
EEI-8
Softwar* Preliminary
Document
EEI-9
Softt»ai» Detailed
Design Document
EEMO
Software Maintenance
Document
EEM1
Software Operations
Document
EEI-12
Software User's
Reference Guide
EEI-13
System Integration
Test Report
S8
-------
2.3 FRDS-II SYSTEM PROFILE
-------
-------
EPA MAJOR SYSTEMS PROFILE
1.0
1.1
1.2
2.0
2.1
2.2
3.0
3.1
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.3
3.3.1
3.3.2
3.4
3.4.1
3.4.2
3.5
3.5.1
3.5.2
3.5.3
4.0
4.1
4.1.1
4.1.2
system Purpose
System Background
User Environment
User Support
User Training
Technical Overview
Hardware/Software Environment
Subsystem Environments
Data Entry
Data Edits
Updates
Data Retrieval
Data
System Data Base
Files
Hardware
Type
Peripherals
«
Software
On-Line
Batch
System Input
Data Input
Update
4.2
System Output
91
-------
4 2.1 Ad Hoc Data Retri«*al
4.2.2
« A
5>1 User Chang* control
5 j^i systea Enhanc«»«nt3
5^1*2 System Problems
5.2 Technical Change Control Process
_ _
6.0
User Documentation
Data Dictionary
92
-------
1.0
l.l. System Purpose
The purpose of version II of the Federal Reporting Data
system (FRDS) is to provide oversight information services in
support of the Drinking Hater Program which monitors compliance
with the Safe Drinking Hater Act of 1974. FRDS-II provides
compliance information for 220,000 water supply sites. These data
include violations, regulations, and status of bearings and
exemptions.
FRDS-II provides interactive services to EPA
headquarters, regional, and state personnel which allows searching
through files of FRDS-II and retrieving the information available
for each Public Hater System (PHS).
1.2
System Background
Three versions of FRDS have been produced over the last
10 years, FRDS, FRDS vs 1.5, and FRDS-II. The development of each
version has been the result of changes in the reporting
requirements of primacy agents (Agencies of State government who
have jurisdiction over public water sources) to the EPA Office of
Drinking Hater (ODH).
The original FRDS became operational in fiscal year 1977
and was designed to accommodate the needs- of the Federal oversight
activities of the Public Hater Supply Supervision (PWSS) program.
The summary data stored in FRDS were collected on an annual basis
and submitted 'to the EPA National Computer Center (NCC), where they
were loaded into the System 2000 (S2K) data base residing on EPA's
UNXVAC 1108 computer system.
The annual collection and entry of FRDS summary data
continued unchanged during fiscal years 1978 through 1984. The
original design produced a new data base for each fiscal year.
During the fiscal period between 1978 and 1984 the FRDS system
environment migrated from the UNXVAC 1108 to the IBH 370, also
located in the NCC.
During the fiscal year 1985 the ODW issued guidance
requiring primacy agencies to modify the frequency of their data
submissions from an annual to a quarterly basis. In order to
accommodate the new guidance as quickly as possible FRDS vs 1.5
was developed as an interim solution. FRDS vs 1.5 combined the
most recently submitted quarterly summary data with the summary
data submitted over the prior three quarters and generated a data
base from these combined summary data. The FRDS vs l.S data base
contained four quarters of summary data. Although FRDS 1.5 enabled
the submission of quarterly summary data, it was deficient in
conducting effective oversight for periods of over 12 months.
93
-------
Also daring 1985, the EPA revi*«4 tAm Federal reporting
requirement* for the Public Water Supervision (PWS) program and
created the Water Supply Guidance V-2, Public water supervision
Revised Reporting Requirements (RRR) document. This document
identified the present and future information needs envisioned by
the Public Water Supply Supervision (1PWSS) program. As a result,
FRDS-II has been designed to meet th«> needs of RRR, and increase
the flexibility of PROS to meet new requirements. FRDS-II will
accommodate four main modifications which include Data Base
Integration, Non-compliance Tracking, Historical Data Retention,
and the Storage of State Discretionary Data.
FRDS-II integrates all the historical data into one data
base, which is accessed and organized by the water supply site
indicator. The redesign effort includes a data base redesign and
development of software to support the FRDS-II design. Some of the
code from the original FRDS was reused in FRDS-II.
Prior to development, an outline for the FRDS-II
capabilities baseline was submitted to the user community for
comments and suggestions. FRDS-II is currently in the development
phase of its life cycle, although the FRDS-II baseline is now
readily available.
2.0 Usar Enyironaent
The FRDS user population includes EPA headquarters ODW,
FRDS-II Data Base Administrator (DBA), FRDS-II Production Control
and User Assistance, state, and regional program users, including
regional branch chiefs.
The FRDS-II DBA and Production Control personnel perform
data base maintenance functions such as updating, backup, recovery,
archiving, and reloading.
2.1 User support
FRDS-II like the original system relies upon user
correspondence through surveys and the FRDS Hot-line to accommodate
the user's needs. User messages and notices are provided on-line
immediately after signing on to FRDS-II.
2.2 user Training
FRDS-II user training is organized similarly to FRDS.
Training classes are held regionally and encompass an overview of
the entire Drinking Water Program as part of the training agenda.
94
-------
3.0
3.1
Technics^ oyarviev
Hardware/software Environment
utilizing
language
«
IBM TSO.
FRDS-II is developed on
the System 2000 data base
extension (PLEX) and operates
3.2 Subsystem Environment
3.2.1 Data Entry
Afttr tb. St..:.. co-pl.t. *£j?£?™££tt> ^
^ pro=^ur» «^.l«t tt^lr ojm^oo^^^ supporting
2££'i«S£./Tr5i£w -**" to "* "•"-
Bv.ntu.Uy, . «=--..«> <"« -*" "IU M tBPlelM"""
using PC-based software.
3.2.2
Data Edits
Extensive data edits are performed on FRDS-lf data prior
to entry to the data base. Specific edits are documented in the
Federal Reporting Data System
-------
3.3
Data
inform., r.tri.v-
surrounding th. »nitorin, "d S".^ .^u-r.. •«*•
Thr.. kind, of ».t.r
ar.: ""r,^ •"Stiti-
factories, »?»»» a. oonMcutiv. w.t«r
public
sector.
' ss:
6) Nonco»pliance profiles.
7) state discretionary data.
8) cm-site visit data.
for entry into IBM-XI.
x d.t.
96
-------
3.3.1 System Data Base
•m. MM TT data basa structure is th« result of
Tha current FRDS-H. «* auooort chanoas in reporting
design modifications over tiW to support ££*£.. resulted in
requirements. The first »«*"*?£;* of lOdata bases with a total
the FRDS 1.5 version which <^^SJ«£T versioiTof the database for
of 2.5 billion characters. The <**™f ^"databases with the most
FRDS-II combines the last eight fiscal ye. integration took
current PWS information. When «^aj i correct match
place a Batching J^gori^.- tf^tching WSs were flagged as
base is
System
3.3.2
2000.
Files
FRDS-II documentation indicated three primary files used
by the system, these are the Data Transfer Pile, Command Files, and
the Locate Data Files. Other files were not described.
Data Transfer File is 80 charactars long, supports
multiple record types, and provides a standard' format for the
submission of quarterly FRDS updates. The format for the Data
Transfer File is tha EPA preferred format for use by States when
they submit updates.
r9IPinflnfl Files are used intermittently throughout FRDS to
expedite user requests.
Locate Data Files serve aa a temporary storage cache for
data selected from a user search request. Up to 11 Locate Data
Files may be created during on user session without being
overwritten. The contents of these files are retained until the
user signs off of FRDS-II. They are typically used as input data
to further output processing, such as reports.
- i. tapl— »f« on
at th.
IBH 30SO/300
Peripherals
3.4 Hardware
3.4.1
in
3.4.2 rw*. *inw» —._
Use of FRDS-II requires an approved interactive terminal
or PC with a telephone connection to MCC. This linkup requires
either an external or internal modem.
3.5 Software
TSO, S2K natural language, and COBOL PLEX. Crosstalk or
other approved communication software is necessary for users
accessing FRDS-II from a PC.
97
-------
3.5.1 On-lin«
S2K natural language.
3.5.2 Batch
FRDS-II batch applications are supported by COBOL PLEX.
3.5.3
Communications
In order to access FRDS-II the user must have an approved
interactive terminal or a PC with a telephone connection to HCC.
Access to FRDS-II varies with geographical location. Access is
available through Tymnet and multiplexers for those users located
in Washington, D.C. and Research Triangle Park.
Users may access FRDS-II from personal computers with
crosstalk.
Users with a minimum of 4800 baud, can access FRDS-II
full screen mode, anything less incurs intolerably slow response
time.
4.0
System Functions
Access to FRDS-II capabilities is provided by the
Function Menu which is the first menu displayed after user sign-on
and includes the FRDS-II/Interactive option* which permits entry
to the FRDS-II Main Menu* The FRDS-II Main Menu has eight options
: Terminate, Assisted Preparation of a System 2000 Locate
Statement, Re-display Broadcast Messages, Retrieve PWSs whose IDs
are stored in an external file. Obtain Geographic Information for
a specified city or county. Reprocess Retrieval data via Post-
retrieval Output Options, System 2000 Self Contained Facility,
Formulate one or more S21C locate clauses and generate a batch
report. These options are discussed in more detail in the
succeeding sections.
4.1 System Input
4.1.1 Data Input
The procedures involved in entering FRDS-II data are two-
fold. Initially, data are entered on FRDS-II Data capture Forms.
These forms are intended for data collection only, not for data
entry into the FRDS-II data base. The forms provide a mechanism
for organizing FRDS data so that the next step, data transfer to
the FRDS-II data base, is simplified.
91
-------
There are eight diff«r«nt FROS-li oata Capture Forms
(Forma A-G and a Record Deletion Font). A brief description of
each For* (A-G) follows:
o Fora A is us«d to document the facility name and
address for a PWS, the characteristics of th* PWS,
and any additional address information such as owner
address or related facility addresses.
o Form B serves to record the data that characterizes
a water source utilized by a PWS, that identify
treatment objectives, and processes that are applied
to a unique source of water used by a PWS.
o Fora C records data which identify geographic areas
or jurisdictions served by a PWS, characteristics of
the geographic area, and data related to on-site
visits, by the EPA, made to a PWS.
o Form D records data which characterize a violation
of a primary drinking water regulation issued to a
PWS by either a State or Federal agency.
o ifera E records data which characterize an
enforcement action taken against a PWS by, a State or
a Federal agency.
o F_ora_F records data which characterize a variance
or exemption that is pending for, or has been
granted to, a PWS and characterizes a schedule of
events and/or actions that are related to a variance
or exemption that is either pending or has been
granted to a PWS.
o Form G is used to enter data that characterizes a
specific set of values defined at the discretion of
the State.
The FRDS-II Data Transfer File format includes a record
definition for each type of Oata Capture Fora. The Transfer File
format is the only format which allows Revised Reporting
Requirement (RRR) data to be entered in the FRDS-II data base.
The EPA prefers that the States use this format to input their
data. States that do not yet have the capability to use the FRDS-
II format have the option of using FRDS version 1.5 format to enter
data. However, if this alternative is selected no RRR data can be
entered via the FRDS version 1.5 format. Eventually, FRDS-II Data
Transfer File format will be the only acceptable format in which
to enter FRDS-II data to the data base.
99
-------
The States submit FRDS-II data to their respective
regional offices each quarter. The mechanism which the States use
to transport the data is arranged by the region. Regardless of the
mechanism selected the data must arrive in an approved FRDS format.
After the States submit their FRDS data, the regions are
responsible for entering the quarterly data into FRDS. The method
selected for this activity is up to the regions.
4.1.2 Updates
The Data Transfer File is the mechanism for permitting
updates to the FRDS-II data base. The file is created at the State
level and submitted to the regions on any medium they select (tape,
diskette. ..etc.) Batch data updates are submitted to the FRDS-II
system every quarter. Each Data Transfer record should contain the
appropriate data value along with the Section Id, Data Address
Qualifiers (to identify activity for an individual data item),
Action Code (indicates activity such as update, deletion),
Component Number, and Batch Date.
4.2 System Output
4.2.1 Ad Hoc Data Retrieval
FRDS-II data are retrieved using a variety of features
available on the FRDS-II Main Menu. The following FRDS-II Main
Menu options provide retrieval capability: '
o Function "A" - Assisted (Prompted) Query.
o Function "E" - Retrieve FWSs Whose Ids are in an
External File.
o Function "G" - Obtain Geographic Information for a
specified City or County.
o Function "S" - Enter the System 2000 Self-contained
Facility (Natural Language).
o Function "X* - Formulate Non-prompted Retrieval
Selection Clauses.
o Function "2" - Formulate non-prompted Retrieval
selection Clauses.
Function "A" - Assisted Query refers to the "Assisted"
or prompted preparation of an S2K Locate statement which is used
to search the data base and to retrieve selected data. Function
"A" provides general retrieval capabilities and is intended to
_ —-i««+. to the more powerful "X" and "Z" functions.
serve
100
-------
Function "A" provides assistance for novic« and
intermediate users. The prompts for novice users are more
informative where the intermediate user receives more streamlined
prompts. The user selects the search domain frost the following
five general data categories, PWS Inventory Characteristics,
violation Characteristics, Enforcement characteristics,
Variance/Exemption Characteristics, and Data Base Administrator
Characteristics.
Function "E" - Retrieve PHSs Whose Ids are in an External
File enables the user to examine a previously created file
containing selected PWS IDs.
Function "G" - Obtain Geographic Information for a
Specified City or County enables the user to retrieve geographic
information about a city or county such as latitude, longitude,
and Hydro-Id.
Function "S" - Enters the user into the S2K Natural
Language environment.
Functions "X" and "Z" are both user-defined queries which
allow users to enter their own formulated data selection criteria
statement in S2K. Function "X* provides the user with the ability
to select and temporarily store as many as 11 different locate data
files which can be used for later output processing. Function "2"
offers a non-prompted user-defined facility to generate standard
batch jobs routed to a remote high-speed printer. * It produces one
or more standard reports from the data selection criteria.
Function "2" differs from Function "X" in that retrievals for "Zn
occur at the time of batch job execution as opposed to online.
Similar to Function "X," Function "2" is a non-prompted S2K locate
statement facility allowing up to 11 different search criteria to
be performed during one session.
4.2.2
Reports
Both ad hoc and standard reports are available on the
FRDS-II Post-Retrieval Processing Options. Menu, which is displayed
whenever Function 'P1 is selected from the FRDS-II Main Menu.
Typically reports will be generated for a select group of data
extracted from a user defined S2K Locate clause, this clause is
typically printed on the bottom to the first report page. Some of
the report options are not currently available, however, these
options are expected to be operational at a later time. The
following reports are listed on the menu:
o FRDSOl - Public Water System Comprehensive
is a summary report of the comprehensive PWS
inventory.
o FRDSQ3 - Public Water System Area and Source Area is
a detailed report of facilities and populations
served by PWS sources.
101
-------
(not available)
PKLia.1.9 — c...^j»m.»—
(not available)•
loffion^^uSJIo^ateorv for
FRDS19B respectively.
source is a summary
PWS source.
•—<•»"• ""t
^ J ^ ^M,^
:« Data (not available)
FSPS24 ~ Public Water Suoialv Sva^^j ayjnmgu.T «»..^
violation Data in a d«taU«d report of PUS plant
location and violation sunoary data including
violation duration in month*.
FRDS31 - Pits Montha in violation is a summary report
calculating the month* in violation for select PWSs.
This auvaarization is pec formed for various
categories of FtfSs and their violations. Two
elementary statistics - number of PWSs and their
population served - are provided.
i yRDS35 — Xnimal. Pa**% Evaluation vill generate a list
of PWS Ids to b« used as input other FRDS-II
reports. The entire population of PWS Ids may be
extracted or a selected subgroup may be specified.
PWS subgroups are specified by sample size. Sample
sizes may be organized by state or applied to the
entire population.
(not
available).
102
-------
ir.lBlt Ytaf
(not available)
Other Post-Retrieval Menu options include:
* File for gAS. (not available) ,
Option 'F* - Frequency distribution. -
Distribution of Data Report, generates a
distribution report which Bay displayed at a
terminal or printed on an off-line, high speed
printer. The report provides a frequency
distribution table of unique code value occurrences
for a specified data element based upon the
currently selected PWS(s). The report always lists
the unique code values and the total number of
occurrences. The frequency distribution may
optionally be sorted by occurrence - from most to
fewest.
Option 'G' - Graphs and Maps (not available) .
- Graph 1 , Number of PWSs by Administrative
Region.
- Graph 2, Percentage of PWSs by Administrative
Region.
• Graph 3, Number of PWSs by Population.
• Graph 4, Percentage of PWSs by Population.
- Graph 5, Number of Violations by County.
- Graph 6, Location of PWSs.
Option "I* * Invo)ce IDRS/CERCHS - IDRS Region Map,
IDRS United States Map, Report For Crosswalk One,
Reports for Crosswalks Two through Five (not
available) .
option «K« - Kounts or Sums of PWS Elements -
Count/Summation of Data Report (not available) .
option «L« - Hat in standard Screen Format Re
for subootion Screens allows the user to list
information for previously selected PWSs. The user
say optionally sort the selected PWSs or browse
through the output in an on-line mode. The reports
may be displayed one at a time or a terminal or the
entire set of selected PWSs may be printed off-line
on a high speed printer.
103
-------
Tfj^mt ^_a«.^MB ^^^ *H|^b^_£ 4fe«m
State« - PWS State M«P» *»» Region
(not available)*
permits the
and print a custom report
(not available)
5.0 System Maintenance
Although FRDS-II is currently under development the
change control process from PROS is still in effect. The process
accommodates three types of change situations.
1) Software bugs, where the project manager makes an
immediate decision about the change.
2) Minor Enhancements.
3) Major Enhancements or addition of nev system
functions.
*
2) and 3) are handled in the same way by the. change control
process .
S.i User Change Control Process
l) System bugs are reported to the PROS Hot-line.
The Hot-line operator documents the problem.
The reported bug is prioritized.
The problem/bug is submitted to technical staff for
resolution.
2) System enhancements are treated in the same way for
minor requests as well as the addition of new
functions.
The enhancement request is prioritized, and the lead
contact group and steering committee review the available resources
and perform a cost/benefit analysis.
The steering committee evaluates the analysis and
makes a decision to either enact or disallow the change.
104
-------
5.1.1
System Enhancement
System enhancements are minor or major unsolicited system
changes which affect intended design or process**. The mechanics
of the enhancement process are illustrated in section S.I.
5.1.2
System "Problems'
System "problems," also called bugs, are defined as
system inadequacies which impede the intended function of the
system. A problem is logged, by the Hot-line operator and assigned
to the technical staff for resolution.
5.2
Technical Change Control Process
The mechanics of the technical change control process
are the same for system enhancements and system "problems," both
require existing software to be modified.
6.0
Documentation
6.1
>
User Documentation t
o Federal Reporting Data system Interactive
Retrieval System User's Guide
o Federal Reporting Data System Data Entry
Instructions
6.2
Data Dictionary
o Federal Reporting Data System Data Element
Dictionary
- Section VT, List of Acceptable Code Values and
Associated Descriptions
- Section VIII, Glossary of Technical and
Drinking Water Programmatic Terms
lOS
-------
Appendix I
Data capture Forms
106
-------
-«. SPA
<-'
c.m
PUBLIC
DATA CAPTURE FORM A
107 -•
-------
DATE
SOUBC61 fNTITY DATA
yu y
SOURCE f ENTITY OATA
M«
y-i-1
TREATMENT 0
« ,
LuJ
U-d
U-d
U-d
i . . i
IMA
U.MOM
u
u
u
*XSS£
U_lJ
u-U
u_u
LJ-ul
LLJJ
(i-
fi«us<
108
-------
PWSIO
.!•»€
t t t I I L
ACTION COOS
U ...H«-
GEOGRAPHIC AREAS SERVED
SAfCM
Qj LLjJL-LjJ
SERVICE AREAS
in a LJ
LJ LJ LJ
LJ LJ LI
LJ LJ LJ
LJ U.I i I J
LJ LJ -U
109
-------
PUBLIC WATER SYSTEM
DATA CAPTURE FORM Q
» » i
ACTION CODE
LJ ••••"'-<
BATCH
•* OM
1 t 1 t
VIOLATION DATA
• ' -0
1. J_l__l_
i t I I . . i I I . I I , Ill i I
• ~'*» -in** l»
i ii i ri ' ' '
MA j««««»^ f •
<^ .9 8
.Jl
-------
.-;£••, EPA
ENFORCEMENT DATA
Ul I I -Li
tTiTi_i n 1111 i
i i i ti « i i
^w^Mff^^MMfM 4^V * I
^TP^ Gi^*"1" * I - I I I
iTn 111 iTi i i 11
«•••
D.t.«
Ill
-------
EPA
PUBLIC WATER *v*
DATA CAPTURE FORM F
BATCH DATE
niTlLl yJ-^
I_ i iiJ
. .
1 1 1 1 1 u
UiJ-LlJ
LLUU-1
| _ i I ' i ' L
| i | i « < »->
LJ 1 i M i
U ' ^ t-1
^ | i i i i J
1 ' |jj
•» c yni ,
| j | II 1 tJ
U1 ' * 'J
Ll I' j ' J
-------
PUBLIC WATER
DATA CAPTURE FORM G
ACTION COOE
BATCH QATE
i . . I L
STATE OtSCRETIONARY DATA
I I I It I 1*1 II
'• t' t ill j I
it t t t t i
, wo 9M ««
I.I.I. I
r
STATE DISCRETIONARY DATA
i i t « «t
<• i -
I I I I I t t I •! I I 1 I 1 I t 1
t till
STATE DISCRETIONARY DATA
I 7 I T I 7 I
C
STATE DISCRETIONARY DATA
• • ' * • • '
. . t •
« « i i t J
i i i i i t . i . t t . i t i i i i i t 1
"•"" i
I 1 L _1 l_ 1*1 1 L I I < I I 1
I " i I
I i 1 i I
21
113
-------
Appendix II
Sample Reports
114
-------
3- I
8 1C
! frliilil »
II ! s-111
a
u
(T
u
I
i!
il
EFFECTIVE
DATE 2/27/89 RELEASE HUMBER 0.95
Page 5-14
119
-------
ii
s s
ss a
E
25
.u
ss; m.
i 5 « —
•
a
«
88
ii
M
a
i
i
|
8
S
S
si
S
I
IM
S
.5
s
I
I 2 I
8 C » S3 *
=1 2 i; s
Si 5 Ii 2
|
'*
ii
-\ i
ii 2
u
<
u
er
£
)
ii
sS
EFFECTIVE DATE 2/27/89 RELEASE NUMBER 0.95
page 5-16
116
-------
u
1
_1
Zs
ii
,1
Ms
,11
•4 •
is
S| St 5* *• -t «2
^ • -— — — »* —
* 3 *
4~i!
is s: st S-: s-: 3^ *2
•" Ml ••• »»* •»• •'*'
£. 1 M M M
M 1
.1 1
M •
21
5 i •* * ' - • '
; -S S
i :|j
S' "*!
,. S! *•! ••« -!-?••
sf s«
! 3!
is 3i
n; 2:
5s 5 !
1 —>• «
. i m< •
1 1 O J 1
;i2£!
!5i £1 „
is S! 2" 5!: st: "- - '
i m « •
i • ^ >
t i n •
: : M:
: : s !
• I fc i
^ 0K M ^B |
! 5! 51 52 5" S2 S
3» -- 5jr 3*
••
_ __ ^» ^^ ^_ ^^ ^
S3 53 =* s*
-* -rt ••» •• • •
~ * 4A # « •
Ml * ^
I
* MM
.....
| «** ^«» 2* *
! Sw 3- ?*
»•* -.5 25
4f MM
-« <* 3*
*" - • *s
4NI **
^_ •* •*
• • " . •» •
•• •• a*
*
> «o -• «*
*» w -^ ^^ •
'• ^ M
«4
fii
5
•
1
II
^ ^
235
MC«
SfS
^i
«•••
••
•
••
L» —
OC
5
1
w •*)
^•^M>
Jt
22 s:
S- ! S"!
?S S *-S
Hg fiS
Oik ••«•
s
s
i
I
2
•
a
i!
Co
EFFECTIVE DATE 2/27/89 RELEASE NUMBER 0.95
Page
s-ia
117
-------
***«•
•'
'
IS!
*«!
Isss
.-2—•*-.
a -
r
-
• » «•
a =
5 * s
•«•*••<
; S"
S S25
S S--
^
S S3
u
<
u
5
I
2
*
S
II
II
I!
/
EFFECTIVE DATE 2/27/89 lU^EASE WWBER 0.95
5-22
US
-------
I
c
EFFECTIVE DATE 2/27/.S RELEASE SOMBER 0.93
Page
5-23
119
-------
»-»•*-
si!
s*i
12!
»11
SS!
JsS
«• •«
sss:
s. .
3S?!
! I*
2 m ^ « «• ••
S23
-
EFFECTIVE DATE 2/27/89 RELEASE NUMBER 0.95
5-24
120
-------
a "5
si
sss;
• a i
: os:
125
II
u
i
S
^ — «•••
u
I
!,
i i 2 tf
c |S,c55s 5r§.r-|| ij
s liiiliiagiiiilir.i
" 3i32lS-2S58Ss32S-«a
EFFECTIVE DATE 2/27/89 RELEASE NUMBER 0.95
Page 5-25
121
-------
>• 3-3*
iis
•v.
-r
2£
71
«• 3»«« ..
:Ss ! *s
5 —-•
2 hsi
5 @
X -V X X N,
« rr
I sllil
25
3
» rs
M
,!f
18 "
1
i1 I
liii
o
*
\
i*
II
Jj i ! f« i'««
sits 5 S
.— n«w
EFFECTIVE DATE
3 I 3
RELEASE W»B1SR 0.95
«&*—«»
Page 5-27
122 '
-------
--•-22522235
SSSS3«»«« — • — •»
222222«.-««-«-
585*8?
2 .2 S *
! ilsi
!. XB -
S -5-2
i S S* •*
«. 2 I«s -.
S
•*
•* _
iS
S
S.
5 s 2
2-25
i ili^
sr; |
P? 5
U
el
-
EFFECTIVE DATE 2/27/89 RELEASE NUMBER 0.9S
Page
5-32
123
-------
-2 -= =5 =5 ~\ sl sf *1 "|
*«jS«""pp»S
si =5 -:
= 1 I s
DATE 2/27/89 RELEASE
0.95
5-39
124
-------
SS2**'**>*w
-------
2 sr
i* «i
cc >-3 •-«
5 IS?!
o «• «.o
p*j
i
Mi
= sil
dii
N ^
•••
5
!i
a*
= * *
! 8 ,
: • • M
^» ^
5w o C ~
|_ M M
^Hs I I I
Is « I
»3 S
»| S -
^ I § ,
s i i
£ -a
! - sl
i I lii
* s ::'
S « 55
i 5 as
a c >• *•
"*•
iS 5 «
*S 2 z
32 t 4
- =«
1 ^i
5 81
s Is
s
ua
•*«*J?S
is?!
I!§i
§
o>
1 11
8 5
S«HI
1
!
s
n
it
ii
°-95
126
-------
li
3!
W I
• I
Sz « S e
sS.s 2 s
•» x -»x 5 *
S»- <
«
«32 a
2* I
I i
li
x i
p^
i
ii
C
EFFECTIVE DATE 2/27/89 RELEASE HUHBE* 0.95
Page 5-43.2
127
-------
2- S
il'.l
f- I IK O
•»3 C_ M
ii
-»• «•
•• *
§( M HI
tt t-
isssssss
issss
> • o S 5
555533:
SSSS32:
833822:
o
o
•
i
;sssss;
3333333323832333
«««a«a««*»ao««a«
S 3
I? **
u »•
= 3
= Hi
£ 2
>s
o •»
V O
IS
•4
{ x
EFFECTIVE DATE 2/27/89 RELEASE SOMBER 0.95 Page 5-43.3
128
_J
-------
Appendix III
Documentation Matrix
129
-------
EEI-2
Pnrfminaiy Design
and Options Analysis
EEI-3
Project Management
Plan
EEM
System implementation
Plan
EEI-S
Detailed Requirements
Document
EE1-7
Softwmr* T«st &
Acceptance Plan
EEI-6
Softwar* Praliminary
OocuRwnt
EEt-9
Softwmra 0«tait«d
Design Document
EEI-10
Softwars Malnt«ianc»
Documsnt
EEI-11
Softwara
Ooeunwnt
EEM 2
Softwar*
EEI-13
Systwn Integration
Test Report
130
-------
2.4 STORIT SYSTEM PROFILE
131
-------
sill!
132
-------
EPA MAJOR SYSTEMS PROFILE
OUTLIHE
1.0 System Overview
1.1 System Purpose
1.2 system Background
2.0 u§e,r Environment
2.1 User Support
2.2 User Training
3.0 Technical Overview
3.1 Hardware/Software Environment
3.2 subsystem Environments
3.2.1 Data Entry
3.2.2 Data Edits
3.2.3 Updates
3.2.4 Data Retrieval
3.3 Data
3.3.1 System Data Base
3.3.2 Files
3.4 Hardware
3.4.1 Type
3.4.2 Peripherals
3.5 Software
3.5.1 On-line
3.5.2 Batch
3.5.3 Communications
4.0 System Functions
4.1 System Input
4.1.1 Data Input
4.1.2 Update
133
-------
4.2 System. Output
4.2.1 Ad Hoe Data Retrieval
4.2.2 Reports
5.0 System Maintenance
5.1 User Chang* Control Process
5.1.1 System Enhancements
5.1.2 System Problems
5.2 Technical Change Control Process
5.2.1 Change Control System Design
5.2.2 Change Control Documents
5.2.3 Change Control Activity
5.2.4 Change Control Testing
5.2.5 Change Control Implementation
6.0 Documentstion
6.1 User Documentation
6.2 Technical Documentation
134
-------
1.0
1.1
Svsten Overview
Purpos*
The purpose of the Storage and Retrieval system (STORET)
is to serve as a repository and analysis tool for Federally,
locally, and state supplied data relating to the quality of
national water ways, in support of the Federal Water Pollution
Control Act Amendment of 1972 (PL 92-500). Titles I-IV of PL 92-
500 require STORET to perform and support the following provisions:
- Title I, Research and Related Programs
Title I requires the establishment of an operative
national water quality surveillance system, the
renderence of technical services and the collection
and dissemination of water quality data. Title I is
the justification for the establishment of STORET.
- Title II, Grants for construction of Treatment Plans
STORET provides quantitative data used for stream
waste load capacities and incipient overloading
projections to support the development and
implementation of waste treatment management plans and
practices. ,
- Title III, Standards and Enforcements
A substantial portion of STORET's report programs help
states to trace their progress of water quality
improvement and enforcement efforts.
- Title IV, Permits and Licenses
STORET data identify sources of effluent violations
and can be analyzed to assure compliance with the
legal limit of allowable discharges.
1.2 Background
Public Law 92-500 is the current program for the
prevention, reduction, and elimination of water pollution. PL 92-
500 built upon and improved the water pollution control program
initiated by Congress in 1948 and amended periodically in the
1950's and 1960's. PL 92-500 requires the collection and
dissemination of basic water quality data by EPA in cooperation
with other Federal departments and agencies and with public or
private institutions and organizations. STORET is the computer-
based mechanism which enables agencies, to comply with 92-500.
135
-------
*&* activities which influenced the development of STORET
as a fully functioning computer systw b«g*n a* early as I960.
Prior to the development of STORET, water quality data were
collected by local state, and Federal, agencies without computer
support. Information was not shared throughout the user community
and retrievals were costly to produce. Data retrieved from the
agencies w«re not in a standard format that could be easily
accessed by any agency. Therefore, a basic concept for the storage
and retrieval of water quality data was introduced in August of
1961 by the Basic Data Branch, Division of Water supply and
Pollution control of the U.S. Public Health Service.
Initially, STORET data, representing 140 sample
locations, were formatted and stored on the Public Health Service
Honeywell computer in 1964. STORET processing on the Honeywell was
limited to computer operator initiated batch jobs run from the main
computer site. All data entered in STORET have to be mailed to the
computer site. However, as the number of sampling locations
expanded and as the jurisdiction for pollution control moved from
the Public Health Service to the Department of Interior's Federal
Water Pollution Control Administration, the need and opportunity
arose to switch STORET from the Honeywell to' the IBM system
maintained by the Department of the Interior.
The 1968 switch to the IBM computer enabled users to
communicate with STORET from the regional offices via% a medium-
speed card reading terminal. Further enhancements occurred to
accommodate growth. These included improved retrieval
capabilities, and the addition of municipal waste, fish kill, and
contract awards files.
2.0 User Environment
Any Federal, interstate, state, or local agency, and
contractors employed thereof, can subscribe to STORET for a fee.
A payment plan between the subscribing agency and the EPA must be
established prior to the connection of STORET service. EPA
typically reimburses the state subscriber a prearranged allotment
allowance. Any amount of computer resources used beyond the
allotment amount is the responsibility of the subscriber.
Subscribers pay for STORET access by either paying the EPA directly
o rovides the computer time-sharing
scribers pay *.«*. d*vc>«. .
or paying the company who provides
services
The U.S. Geological Survey, the U.S. Forest Service, the
U.S. Army Corps of Engineers, the Bureau of Reclamation, the
National Academy of Sciences, the National oceanic Atmospheric
Administration, and the Tennessee Valley Authority all utilize
STORET«s data.
The primary STORET user at an agency is an experienced
Water Quality Analyst. In order to accurately formulate retrieval
requests and analyze STORET output a high degree of technical and
water quality knowledge is necessary*
136
-------
2.1
Us«r support
Th* Data Processing and User Assistance Branch,
Monitoring and Data support Division (MDSD) of EPA's Office of
wat«r and Hazardous Materials is responsible for providing
operational and assistance support to STORET users. User support
for STORET subscribers is provided in the folloving ways:
A STORET Interagency Panel was established in 1974 to
recommend policies, priorities, and approaches to be followed in
managing STORET. In addition to representatives front EPA's Offices
of Water and Hazardous Materials, Planning and Management and
Research and Development the panel is comprised of selected regions
and states, the Council on Environmental Quality, the Office of
Management and Budget, and other Federal agencies including; the
U.S. Geological Survey, the National Academy of Sciences, and the
National Oceanic Atmospheric Administration. The panel meets twice
yearly to provide members the opportunity to review current
activities and future plans.
Annual STORET user meetings provide users with an
opportunity to discuss and exchange ideas on their uses of STORET.
The meeting covers presentations on current status, planned future
capabilities and methods for improved system efficiency, and cost
effectiveness.
v
STORET has a representative in each of,the ten regions.
Each regional STORET representative is responsible for establishing
and implementing STORET policies for all users within the region.
The regional STORET representative is also responsible for
providing assistance to new users. User Representatives meet
annually with Headquarters to discuss STORET problems,
enhancements, and progress. User's report problems and programming
changes to their regional representative.
General user support is provided by Headquarters staff.
This support includes a STORET Hot Line, which is available from
eight a.m. to five p.m. weekdays EST, and questions to Headquarters
staff via time-sharing STORET terminals.
A quarterly periodical called STOR ET cetera keeps users
abreast of current enhancements.
STORET provides a mechanism for users to contact one
another by maintaining an accessible data set list of all users,
their addresses, and phone numbers as well as the data each user
site enters into STORET. The list can be requested by a JCL
runstream.
2.2
User Training
Headquarters offers Beginning and Advanced courses.
Beginning training, which assumes the user is inexperienced with
137
-------
TSO, covers storage and retrieval techniques and access to on-line
data sets. Advanced training, which requires six months of STORET
experience and coapletion of the Beginning course, covers advanced
retrieval techniques, machine readable output options, related
internal logic of STORET, and sophisticated TSO usage.
Training is provided by Headquarters on an annual or as
needed basis. An attendance requirement of 12 to 24 attendees is
necessary for a class to be scheduled, with the exception of
situations where training is crucial to the agency's program.
Scheduling and class training information is available on one of
STORET's HELP data sets.
3.0
3.1
Technical Overview
Hardware/Software Environment
STORET resides on an IBM 3090 mainframe utilizing a
custom file system designed by EPA staff.
3.2 Subsystem Environment
3.2.1 Data Entry
The STORET data entry system is based upon card image
entry through the TSO environment. Card image data sets are
bundled with canned JCL streams to perform the* entry function.
Each user is responsible for entering their own data. Once the
data entry job stream is run the input data is written to a
transaction file, which is later read and edited as part of the
weekly update process.
An enhancement effort to add an interactive menu-based
user interface is currently in progress. The STORET menu-based
system exists in TSO utilizing ISPF dialogue and PL1.
3.2.2
Data Edits
The STORET data editing process is driven by parameter
codes. STORET card image records used for data entry contain
parameter codes which indicate what kinds of edits the data record
should activate.
For the most commonly used parameter codes each value on
the card is checked against a pre-established high/low range.
Values which exist outside the range are rejected unless otherwise
specified by an override code.
Individual agencies can customize edits by supplying
their own high/low ranges and edit checks on the parameter card.
Data edits for the on-line portion of STORET are two
phased. A format edit is performed with the data on the screen (s)
and a cross-edit is performed offline and applied to the
Ul:
-------
transaction fix« created by screen entry.
3.2.3 Updates
Updates ara applied to tha STORET files on a weekly
basis. All updatas wist pass through tha corresponding edit
process before being added to tha system.
3.2.4
Retrieval
Data retrieved from STORET take place via ad hoc requests
through TSO. The requests are activated through JCL runstreams
that can be bundled with pre-established STORET functions and SAS
commands. This feature allows the user the capability to alter and
customize output.
3.3
Retrieval is available through the STORET screen system.
Data
STORET data are primarily used as a decision making tool
for the water quality manager. Other ways STORET data are used
include:
- To fulfill PL 92-500 305 (b) reporting requirements.
\
- Update state and areawide water quality plans.
- Provide background information for research studies.
- Summarize compliance with standards and criteria.
- Access the availability of data on priority
pollutants.
- Evaluate the effectiveness of the water pollution
control program.
- Check MPDES permit compliance.
Users enter their own data in STORET and are responsible
for the quality of the data which they enter. Data contained in
STORET are available to all of the users, are often historical, and
are related to quality of water, identification of waste treatment
plants, pollution-related fish kills, and progress of government
grants awarded to sewage treatment plants.
Water quality data, which coaprisas the bulk of data in
STORET, include station and parametric data. Station data identify
where a sample is takan from; and the date, time, and depth of the
sample. The number of stations have increased from 150 in 1964 to
approximately 200,000 in 1976. Station data include such elements
139
-------
&• unique station identifiar, station location longitude/latitude,
station stat* and county codas, station1* political location,
station's hydrological location, and major/minor riv*r basins which
th« station is close to. Parametric data identify th* parameter
a«asur«d and th* result of th« measurement. Each time «
measurement is taken it is classified as an observation. STORET
presently serves as a repository for over 100 million observations
with approximately 1800 unique water quality parameters. Eighty
percent of all sample observations pertain to 200 of these
parameters.
Municipal waste treatment plant data are another
component of STORET data. An inventory of municipal waste plants
is crucial to the execution of pollution abatement and control
programs at all levels of government. These data are used for
the preparation of basin plans, annual budgets, annual reports;
to perform periodic assessments of the effectiveness of
control/abatement measures and to monitor the degrees of compliance
with standards. Privately and publicly owned municipal waste
facilities are accounted for in STORET.
Fish kill data are entered into STORET whenever water
pollution is determined to be the cause of a fish kill incident.
Fish till data include tissue sample analysis, water sample
analysis, and site location. Data in STORET for pollution-related
fish kills date back to the 1960's.
Contract awards data help interested parties to track
the progress of thousands of contracts awarded to municipalities
for sewage facilities construction, gather statistics on the nature
of award and quantify trends in contract award activity. Contract
awards data date back to 1952.
Discrepancies in the STORE!? data have been known to occur
when two or more differing interpretations have been submitted for
the same body of water.
3.3.1 System Data Base
There is no commercial DBMS used for STORET. Instead,
a file system was developed to accommodate the information. These
files are discussed below.
3.3.2 Files
STORET data are stored in a number of main data files
designed in-house by EPA staff.
These include:
- Water Quality file which contains station and
parametric data.
140
-------
- Wast* Facility file which contains an inventory of
municipal and industrial vasts treatment plants.
- Pish Kill fils which contains information rslatsd to
pollution-related fish kills.
- Contract Awards file which tracks the progress of
government grants awarded to sewage treatment plants.
A series of HELP data sets or files are a component of
STORET which exist for user support functions.
3.4 Hardware
3.4.1 Type
IBM 3090
3.4.2 Peripherals
All STORET users are responsible for providing their own
computer peripherals and supplies. Sixty-one percent of all STORET
users access the system from a PC, while the remaining user
population accesses the system via line-by-line terminals.
3.5
3.5.1
system.
3.5.2
Software ,
PL1, SAS, WYLBUR, COBOL
On-line
PL1 and TSPF dialogue support the STORET menu-based
Batch
Batch software used for STORET include SAS, COBOL, PLl,
FORTRAN, and WYLBUR.
3.5.3
Communications
Communications take place via remote dialup to STORET
using 1200 baud modems. A switch to 2400 buad is planned to
accommodate more users using the screen-based STORET system vs. the
TSO line-by-line STORET system.
4.0
System Functions
STORET functions are available via line-by-line and
through an on-line menu system. The ability to enter, retrieve,
and analyze STORET data in line-by-line mode is supported by a
collection of related software and software elements, which are
141
-------
activated by control cards. The menu-based system is support by
a second set of software and will eventually replace line-by-line
•ode once all of the users are technically compatible.
4.1 System Input
4.1.1 Data Input
State, local, and Federal agencies enter data into STORET
via the TSO environment command language. In order to submit the
data to the system they must be entered into a data set in card
image format with additional parameters to indicate type of edits
to be performed on the data. The data set contains the data
referenced by the JCL runstream which creates the data transaction
file used in the edit process.
4.1.2
Updates
User's edits are not immediately applied to the system.
They must wait for the weekly update process to run prior to
retrieving their updates.
4.2
System Output
Output from STORET exists in a variety of forms to serve
a variety of purposes. These include: ,
- Listings of sampling station information.
- Statistical summaries of parametric data.
Graphical plots of variations in parametric values
over time or along a waterway.
- Location maps which show sample station locations.
- Summaries of parametric values which violate
standards.
- Various maps, such as contour, area-shaded, or trend,
which show variations in parametric values over a
geographical area.
- Linear regression plots and statistical calculations
depicting relationships amongst variables.
- Cards containing station codes and parametric data.
- Disk, magnetic tape, cards, or microfilm containing
STORET data.
Users can route their job output to their own printers
142
-------
requesting user.
4.2.1 Ad Hoc Data Retrieval
Ad Hoc data retrieved are available via TSO environment
command language.
4.2.2
Reports
III ?ornlaTeponr1: «5£?t£?S* report is requested, allowing the
analyst to exclude unessential sample data.
5.0
Maintenance
s.i
User Change Control
5.1.1 System Enhancements
Users submit programming changes to their regional STORET
representative, who presents the request to STORET Headquarters
staff.
The STORET technical staff reviews the request for
further action. If approved the request is issued to the
appropriate programming staff.
5.1.2 System Problems
System problems are reported to the STORET Hot Line,
where the Hot Line operator reports the problem to STORET technical
staff for rectification.
5.2 Technical change control Process
5.2.1 Chang* Control system Design
STORET uses the same data base for modifications and
production. Software which is currently being modified is retained
separately from software in production.
5.2.2 Change Control Documents
No formal change control documents exist to support the
change control process. However, with the addition of the on-line
system the process may be formalized if demand permits.
143
-------
5.2.3 Chang* Control Activity
Software files are modified for enhancements and
probl
5.2.4 Chang* control Testing
The programmer (s) implementing the software changes is
responsible for testing the modifications.
5.2.5 Change Control Implementation
Once the software modifications are tested, the new
software is moved to production.
6.0 Documentation
STORET User's Guides
STORET/BIOS Field Survey Data Base User's Guide
STORET Flow File User's Guide
STORET User's Handbook
STORET Seminar Guide
Technical Documentation
A library of program documentation is available.
STORET HELP Data Sets
A series of HELP data sets are available to all users.
6.1 User Documentation
STORET provides users with documentation concerning each
main data file, overall STORET functions, and execution of specific
programs. The documentation is offered in manuals as well as
through the TSO environment (HELP data sets) .
6.2 Program Documentation
The STORET technical documentation is contained in the
STORET library. The library documents the software and includes
a program overview, purpose, preliminary notes, files accessed, and
structure for each software program.
144
-------
Thi« documentation was last r«vis«d so.*ti*« in th«
1970'S.
g.3 Data Dictionary
Ko data dictionary exists Cor STORET.
145
-------
Appendix I
Sample System Function Screens
146
-------
STORET screen samples are available.
147
-------
Appendix II
Documentation Matrix
148
-------
EEI-1
UssJonHMds
Analysis
sEI-2
pt»fitTW-JtY Design
and Owens Anaiyw
=£1-8
SoJt
0«sicn Cocumam
=£1-9
Softwii 0«tail«c
f Cocunwnt
=£1-13
3yst«.-
Test Rwort
149
-------
2.5 CLP/SMO SYSTEM PROFILE
150
-------
i S
Hill
131
-------
132
-------
I S3
-------
154
-------
ii it
15S
-------
EVA MAJOR SYSTEMS PROFILE
QOTLIKg
1.0
1.1
1.2
2.0
2.1
2.2
3.0
3.1
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.3
3.3.1
3.3.2
3.4
3.4.1
3.4.2
3.5
3.5.1
3.5.2
3.5.3
4.0
4.1
4.1.1
4.1.2
system overview
system Purpose
system Background
environment
User Support
User Training
TechnJ^c^jL overview
Hardware/Software Environment
Subsystem Environments
Data Entry
Data Edits
Updates
Data Retrieval
Data
system Data Base
Files
Hardware
Type
Peripherals
Software
on-line
Baton
Communications
Svfltem Functions
system input
Data Input
Update
156
-------
4.2 SY«ta» Output
4.2.1
4.2.2
5.0
5.1
5.1.1
5.1.2
5.2
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
6.0
6.1
6.2
6.3
A4 Hoe Data
Raporta
s vat <
Kaintananea
nsar Cbanga Control Procaas
Syataa Bahaneaaanta
syataa Problt
Tachnical Chaaga control Procass
cnanga Control systaa Dasign
cnanga Control Documanta
Changa control Activity
cnanga Control Taating
Changa control implamantation
^f.iimta.t ion
Oaar oocumantation
Technical oocumantation
Data Dictionary
157
-------
1.0
1.1
System Purpose
*ne purpose of the contract Lab Program (CLP) is to
provide state-of-the-art chemical analytical services of known
quality on a high volume, cost-effective basis in support of the
Environmental Protection Agency's (EPA) superfund effort,
originally under the comprehensive Environmental Response,
compensation, and Liability Act (CERCLA) and presently under the
198« superfund Amendments and Reauthorisation Act (SARA). The
contractor-operated Sample Management Office (SMO) provides
management, operations, and administrative support to the CLP.
The primary objective of SMO is to facilitate optimal use of
program analytical resources. SMO activities fall into the
following areas:
l) sample scheduling and tracking
2) Contract Compliance screening
3) maintenance of CLP records and subcontracting
4) laboratory invoice processing
5) procurement/m development and statement of work
production
6) management reporting
7) coordinating CLP meetings and conferences
8) National Program Office (MPO) management, technical
and administrative support.
SMO routinely receives Regional analytical requests;
coordinates and schedules sample analyses; tracks sample shipments
and analyses, receives and checks data for completeness and
compliance; processes laboratory invoices; and maintains a
repository of sampling records and program data. In response to
client requests for nonroutine types of analyses, SMO subcontracts
for Special Analytical services, scheduling and tracking for these
efforts as outlined above. SMO maintains a comprehensive data base
of CLP services, performance, and utilisation in order to generate
a variety of management and user reports. In order to support
these functions five automated systems were developed, the systems
that were developed are; the Scheduling, Allocation and Monitoring
(SAM) system, the Statistical data base (STAY) system, the Contract
compliance System (CCS), the Management Information System Routine
for Analytical services (MIS/RAS), and the Tracking and Invoice
Payment (TIP) system. Bach of these five systems will be discussed
in the following sections.
1SS
-------
amM system is to provide BPA with
the purpose of the 8MI Jtoow successfully BPA regions
management reports used to asses» Bd ^4 BOaSuperfund). on
predicted their CLP needs <8apV orojected UM, SAK can be used
occasions when capacity is short osr to r€qu€Sting its assigned
to determine how close region's o»» ^^ r.gion snipped what was
sample allocations, and whether or ov information:
scheduled. SAK captures the foll««1B*
* ..a inorganic sample projections,
- Each region's organic "V required by month.
and assigned allocations i* *•«*»"• *
* ^ *fi* regional weekly requests for
. Site and project specific re?*"-
CLP support.
for
allocations
are not
processing
t-_ £s to provide a
Th« purpose of the 8TM sy. £ results from
statistically ^* •"'iSSJj.d0 tSo«gh SJ Lutin. Analytical
superfund investigations conducted tnroug j^t,, occurrence
on a customise basis. ^ ^^^
The main goals of CCS "• ^^.a^rovWed by the
E»X'» right to
159
-------
The purpose of the Sample Tracking and invoice processing
(TIP) system is to correctly compute the amounts payable to
laboratories based upon the terms of each contract. According to
the terms of the contract, laboratories nay incur cost adjustments.
The factors examined in determining cost adjustments include data
turnaround (amount of time taken by the laboratory to analyse a
sample and send a data package to Viar/8MO), quality control sample
data results/ and holding time criteria, TIP supports the payment
recommendation function of CCS by calculating the sample due dates.
1.2 System Background
The backgrounds of the five systems which support CLP
through the SMO are discussed in the following paragraphs.
SAM was developed in 1985 by viar for the U.S.
Environmental Protection Agency's CLP at a time when EPA needed to
allocate limited laboratory capacity to EPA regions with extensive
hazardous waste sampling demands.
STAT was created by Viar in, 1983/84 in response to an
EPA request for data on compound occurrence at Superfund sites for
taxation studies required by CSRCLA. The 1983 version of STAT was
statistically modeled on the computer records of Routine Analytical
Services (RAB) which had been provided by the CLP up to January
1984. Thirty percent of the sites serviced were selected as were
nine percent of the samples analyzed. Sites were 'stratified
according to National Priority List (N7L) status. "Nineteen percent
of the 354 randomly selected sites were on the NPL at the time.
Up to « organic and 4 inorganic samples* or 12 organic and 8
inorganic samples were selected from each site using a systematic
selection method, depending on the number of sampling episodes
(eases) which had been done for the site, subsequently/ the system
has been revised to include randomly selected samples derived from
HAS information up through 198«.
CCS was developed in 198S by Viar for the BPA's CLP in
response to EPA regional concerns about the quality of data being
provided by contract laboratories, ccs was designed to rapidly
determine the contractual compliance and completeness of data
submitted to EPA under the RAS programs of CERCLA.
KXS/RAS is a computerised case and contract summary
system designed to meet the management information needs of the
EPA's CLP program. MXS/RA8 was developed in July 1982 to capture/
maintain/ process/ and report CLP information relating to
laboratory performance/ adherence to contract requirements/ and
financial and utilisation data.
TIP was developed in 1982 for the BPA*s CLP. TIP forms
the basis of Viar1 a recommendation to EPA for laboratory payment/
to labs which analyse samples from sites deemed potentially
dangerous by the EPA. TIP tracks the collection/ contract
schedules/ cost/ and payment of individual samples. TIP has been
160
-------
procedure »*• modifi.d TI»
additional proc«dur«.
•nhaac«d to
2
us«r support
8KO syt^s- us.r .support [
2.2
on an
are
users ««« ajf»*.«- —
liy B«»*»« »«•• — — --
within the same office area.
User Training
44 * r all SHO systems is performed informally
User training for all snw »*
as-needed basis.
161
-------
3.0
3.1
Hardware/Software Environment
3MO computer systems are supported by th« HOC IBM 3090,
Cincinnati IBM 4381 model R23, and the WXC IBM 4381. VIM HOC 3090
is the central nod* in « series of logical mainframes (UUT). All
SMO production computing is on the Cincinnati IBM 4381. Tit* wic
IBM 4381 is used as a communications vehicle to the HCC's 3090.
3.2 subsystem Environments
3.2.1 Data Entry
The SAM data entry function resides in the TSO
environment utilising FOCUS to generate the screens. Menus and
screens support the entry of SAM data.
STAT acquires new data from PC-based file uploads to the
mainframe via a batch SAS program which runs in the TSO
environment.
ccs data entry processing is carried out by screen data
entry or uploading of data diskettes from PCs. Both forms of entry
are supported by SAS programs which reside ia the TSO environment.
screen programs are further supported by CLIST.
MIS/HAS data are entered through on-line data entry
screens.. These screens reside in the TSO environment and are
further supported by CLIST,
TIP data are entered through on-line data entry screens,
which reside in the TSO environment and are supported by CLIST, and
through the uploading of data diskettes.
3.2.2
Data Edits
Mo specific information concerning SAM or STAT data edits
has been provided.
CCS data are edited after they have been submitted to
the system. Due to the limitations of 8AS/FSP software, no on-
screen error checking is performed. Two types of edit processes
occur, one for each data entry method: upload from diskette and
on-line entry. The kinds of edits for uploaded data include:
- Record format (key fields, record type).
- Valid number of data records per header record.
- Checks for illegal characters in data variables.
- correct information (such as case, lab and
162
-------
contract).
- V»U4 data grouping*, for «xaapi, fractional sets,
The types Of adits performed on the data files ara quit*
extensive. IB summary/ the data adita encompass ehacks on illagal
field values, range cheeks, time sequences, visaing information
from fields and screens, and illagal field combinations.
MIS/RAS checks for tha validity of known fields such as
case number and tha sample dollar count as vail as others. Samples
with erroneous fielda ara rejected and must be resubaitted.
TIP data edits check for value, format, and existence of
required fields. Cross-edits ara performed across tha TIP,
MIS/RAS, and CCS systems.
3.2.3
updates
Updates to the SAM data base occur at tha time tha screen
update takes place via FOCUS programs. Users may also select to
update tha Sample Tracking data base which interfaces to SAM and
contains some of tha same data elements. Users may elect to update
the data baaa after tha data entry or update process when tha
system prompts for update of tha Sample Tracking data base.
STAT data uploaded from tha PC-based data entry system
are stored in a temporary file. Periodically as tha process of
accumulating data for tha complete population of samples
progresses, tha contents of this fila ara addad to tha main STAT
data base.
In order for STAT to maintain tha statistical validity
of its data base, tha data base must be updated at the end of each
year with a sample of that year's RAS work. By updating tha data
base, tha fixed percentage of sitaa and samples included in the
data base is maintained as tha universe of sites and samples
expands. During tais process comparisons to the MIS/RAS data base
are necessary for items such aa new sites, ratio of NPL to non-HPL
sites, and new casea.
CCS data is updated nightly.
consists of tha following four steps:
The update procedure
l) Post daily transactions to a master data set and
backup of all daily data entry filaa.
2) Compare the CCS data basa against tha TIP data base
so that tha unscreened samples may ba identified,
scheduled for screening, and addad to tha CCS
sample fila.
163
-------
3)
in
Evaluate CCS results and produce p«yaaat
recommendation. The tccoaaendations are stored i
tha sample fll*. The TIP system win ratriave
payment recommendations from ccs during its daily
update process.
4) Refresh the individual data entry files from the
aastar fila.
5) Produce an extract of ccs information for tha CARD
system managed by tha USBPA RMSL/Las Vegas. This
fila contain* all ccs data processed in tha last
week. Tha fila is produced each Wadnasday.
MIS/RAS updatas ara performed on a monthly basis and
contain all raconcilad data antry activity for ona month.
TIP updatas occur nightly., Uploadad diskattas ara
appliad iaaadiataly to CCS and ara appliad to TIP during tha
nightly updata procass.
3.2.4
Data Ratriaval
Tha Ad Hoc option allows tha usar to inquira on tha SAM
data alamants by building FOCUS rapoxt ganarator raquasts on tha
scraan. To parform data inquiry functions on tha data "basa using
tha Ad Hoc manu, tha usar must ba familiar with tha FOCUS report
ganarator command syntax and data alamant namas. Tha usar is
racommandad to raad tha "Raport Gan«iratorn saction of tha FOCUS
usar's Manual. Tha manual will instruct tha usar on formatting
custom raports, craating summary raports, and parforming simple
inquiries to tha SAM data basa.
STAT providas no spacial data inquiry facilities. For
interactive query standard 8A8/FSP procedures can ba used, or
custom batch programs written to extract and print tha desired
data.
CCS providas menu-driven data antry screens for each
phase of the CCS procass where information must ba input into tha
system or modified to allow data entry without extensive training
requirements. The data entry environment exists in TSO and
utilises ISPF, SAS/FSP, and SAS Basics.
MIS/RAS data entry is facilitated by the use of data
entry screens which enable entry operators to spacify whether data
should ba added, changed, or deleted from tha master file. Tha
MIS/RAS data antry environment exists in TSO and is supported by
ISPF, SAS and CLIST.
164
-------
no special data inquiry
— »——»» **«• r-- -.--•dures arc used with menus
faciliti"* Standard SM/FSP JgJStio. sWystem of TIP, which
constructed*£»••'. ». co.t Xllo«•« ^^f .,
is written in FOCUS, provides a set w»
In general, TIP r-
i. standard SAS/FSP
m ,
query screens.
3.3
Data
SAM data support the scheduling allocation and monitoring
system. SAM data comprise all elements related to sample
projections, allocations* regional requests for CLP support, which
includes identification of the requesting organization, preferred
laboratory and month of allocation* sample shipment information
such as: estimated ship date and total sample quantity per
shipment, nonallocation projections and performance, and QC
frequency for invoice processing.
Additional related data are case-number (which is the
same under all SMO systems), geographical regions, sampling
activity purpose, site*related information such as spill*id, site-
name and site status, lab-related information such as QC frequency
and lab name.
STAT contains a data universe which is representative of
approximately 30 percent of CLP sites. A statistical sample of
17,197 environmental samples representing 10.4 percent of the
samples analyzed under routine analytical procedures was selected
from each chosen site using a modified, stratified systematic
random sampling procedure.
A total of 18 organic and 18 inorganic samples was
selected from each site where available. Sample data are available
for over 160 organic and inorganic target compounds and elements
and nontarget organic compounds for each site. Sample selected
Chemical Abstracts Service (CAS) Registry number, actual detection
limits, and sample matrix (e.g., surface water, soil, etc.) are
available for each analysis. Blank data assist in assessing
possible laboratory or contamination of samples is also available.
CCS data concern the results of the CCS inspection of
each sample. This includes a summary of completeness and
compliance status of the data divided into 27 specific evaluation
criteria for organic analyses, and 19 for inorganic analyses. The
status for each of these criteria is entered into the CCS data base
for each sample.
MIS/HAS data are related to the activities surrounding
payment of laboratory sample analysis activities and the graphical
reporting thereof. Some general categories of KXS/RAS data are :
* Accounting and payment information such as: program
responsible for payment (Superfund and non-superfund), processing
of 2550 invoice, costlot per sample price for a specified number
of samples under a lab contract, total value of government
C
165
-------
obligated funds to purchase sample aaalyn*, penalties and
incentives for late and early performance and analysis and
appropriation*.
- Laboratory and sample data such as: lab capacity,
late samples, required fraction analysis per sample, dat« of sample
analysis, and sample weight.
Contract data such a» contract and contract
modification numbers.
3.3.1
System Data Base
The SMC data base utilizes the FOCUS DBMS and contains
a single FOCOS file, which is further organized into separate
segments. Several 8X8 files comprise the STXT data, base. These
files are discussed in the following Section 3.3.2.
8X8 files comprise the CCS data base. These files are
discussed in following Section 3.3.2. The CCS data base usually
contains two months1 data in an active file at all times. Data
older than two months are stored in a separate file, which is
called an archive file. The entire CCS system occupies
approximately 50,000 tracks and is expected to grow at a rate of
looo tracks per month.
MX8/RXS data are organised, maintained * and accessed by
SX8 files, which are discussed in Section 3.3.2.
TIP is organised and maintained in 8X8 and FOCUS files.
The TIP data base contains approximately 300,000 sample records
and processes approximately 8000 samples and 70O invoices each
month.
3.3.2
system.
Files
SXM uses intermediary files in the update portion of the
STXT uses six primary files,
following datas
These files contain the
The XLLDXTX file is the result of the selection of a
random sample of K*X samples for 1980-1983. This
file contains information of vox/BNX/PEST compounds
distribution during that period.
The MZTXLBLK file include* blank data for inorganic
soil samples for 1980-1983. These blank data are
associated with the inorganic soil samples in
XLLDXTX. This file helps in monitoring QX/QC of
inorganic soil samples.
166
-------
fil.
ganarmtad for
Th. fil.
tna compound la*« ganarm
i.tr tt
rio Th. fil. gi~. th^ Ji.tr
compound during Ift4 and sp«cifi«s
ia of B«WOVW« fraction.
fti« i» «• ?f J*;0;12.
uniqu* sit. n««s •«• «tT*f» 'f- loc«t«d and wh«th«r
also d««crib*« irh«r« th« sit« i» i«««*
th« sita is on tha MPL or not.
Th.
for a coliaotion o* '"P^*,*^ th. data basa for
"
analysis.
486
of a collaotion, « --*«- -~ tna data
an
alysis
"'" ""- raw was-
quarterly
• S
?iirand is updatad quartarly
•
quartarly
updatad quartarly
•
updatad quartarly.
•ontnly.
167
-------
7) CASESAVE - is the backup til* for the CASBMF file
and is updated monthly.
8) COMTMF - contains contract status and funding
information for each contract awarded to the
laboratory and is updated, monthly.
9) CONTRACT - contains information regarding contract
rules and delivery perfomance analysis for each
contract awarded to the laboratory.
10) CONTSA7B - is the backup file for the COMTMF file
and is updated monthly.
LABPLOT - contains information regarding laboratory
performance analysis. Tliis file is a derivative of
the BACXMF file and is updated quarterly.
PLODAT - contains monthly analysis of sample and
financial utilisation at the case level. This file
is derived by combining the COMTMF and CASEMF
Master Files, and is updated monthly.
PROQPLOT - contains information regarding RAS
program performance analysis organised by calendar
year. This file is derived form the BACKMF file
and is updated quarterly.
>
SAMPLE - contains the most current sample data as
well as historical samples, and is updated daily.
SITES6 - provides invoice information which tracks
the costs incurred at each site with an EPA
site/spill identifier.
TIP contains several files including contract Bid File,
Case Cost Adjustments File, Contract Master File, CostLot Master
File, Diorin Active Sample File, several invoice files reflecting
the different invoice types, inorganic and organic active, semi-
active and nonaotive sample files. The Cost Allocation subsystem
contains the Financial Balance file and the Invoice Transaction
file.
12)
13)
14)
15)
3.4
3.4.1
Hardware
Type
All SMO systems utilise two IBM 4381s and an IBM 3090
I6S
-------
3.4.2
P«ripherals
SMO users access CLP systems vta 3270 tar«inals with
dedicated Haas or ASCII m terminals with dial-up capability.
PCS ara availabla to users and help them to customize soma of tha
applications.
3.s Software
SAM Utilizes TSO, CLIST, SAS, and FOCUS.
STAT utilizes TSO and SAS.
CCS utilizes TSO, ISPF, and SAS (Basics and FSP).
KIS/RAS utilizes TSO, ISPF, CLIST, and SAS.
TIP utilizes TSO, CLIST, SAS, ISPF and FOCUS.
3.S.I on-line
SAM on-line programs utiliza FOCUS FIDEL.
STAT has no on-line programs.
ccs, MIS/RAS, and TIP on-line programs are 'written in
SAS and CLIST. The Cost Allocation subsystem to TIP is written in
FOCUS.
3.5.2
Batch
SAX batch programs utiliza FOCUS Financial Reporting
Language usad for reports, TSO, CLIST, SAS, and FOCUS.
in SAS.
3.5.3
STAT, CCS, MIS/RAS, and TIP batch programs are written
Communications
SAM user
tunications are mada possible through the
USBPA telecommunications Network Menu.
4.0 System ^M^ctions
SAM is a menu-driven system which provides data base
maintenance and reporting functions* SAM functions include CLP
Tracking System, RAS data reports, LAB data reports, allocation
reports, projection/scheduling reports, and maintenance features.
Although the RAS and LAB data reports are on the main
menu, these options are currently unavailable.
169
-------
STKT exists as a collection of si* files from which
reports ar« generated using customised SAS programs. There are no
menus oc specially designed inquiry screens for the data base.
The primar? functions of STAT are to select data base population,
cheek data collection status, add data to the data base* and run
ad hoc reports.
CCS is a menu-based system which allows for a variety of
functions including calculations of initial payment racommendaton,
tracking of laboratory responses to CCS, production reconciled
sample status reports, modifying payment recommendation based on
the timeliness of the laboratories* responses, and tracking of
laboratory and program performance trends over viable time frames.
MIS/HAS is a menu-driven on-line access system with batch
reporting available at scheduled intervals and on request. All
available information maintained in the system can be viewed or
updated by authorised users.
TIP is a menu-driven on-line access system which allows
for the entry of data from screens and uploading of diskettes, and
the generation of hundreds of different reports.
4.1 System Input
4.1.1 Data Input
The initiation of the data entry process for SAM is
dependent upon the weekly receipt of the CLP-SHO Weekly scheduling
worksheets from the SMO Environment Program Coordinators. Each
coordinator is responsible for tracking every sample scheduled and
shipped by a particular EPA region. This detailed scheduling and
shipment information is placed on the Scheduling Worksheet and, at
the end of each week, is given to the system user for data entry.
The SAX entry menu allows access to the add, update,
delete/ and inquiry screens for the initial information, which
comprises nonsuperfund document control number, client projections
for allocating sample analyses by region and new case number; and
for laboratory assignment and shipment records, sample request
records, and separate maintenance of case number and document
control records.
STAT has no user interface for entering data besides the
PC-based upload procedure.
CCS data entry procedures include diskette upload and
on-line screen entry.
The entry of MIS/MS data occurs through the HAS -
contract and RAS-Case Data Entry screens. Access to these screens
allows for the entry of new contract and case records. The screens
which pass validation and are accepted to the system are stored in
170
-------
a transaction ell,
whenever the «T.t€>
ia incorporated into the data base
pr*ce«» *» initiate.
data are entered via SAB/FSF and FOCUS screens.
4.1.2 Update
SMC data ar« updated automatically after a screen entry
of new data or a chang* is successfully submitted to the system.
Each time a successful updat* occurs an archive is mad*. Archive
files of SAM data base updates are held for 30 days.
Updates to SAM occur through the CLP Tracking System,
CLP Sched/M location Maintenance screen, and Contract Lab Table
Maintenance screen.
STAT does not allow updates to data once it has been
uploaded. It does however allow for the analysis results for
selected samples that must be retrieved from archived storage and
input to the system through a PC-based generalized data entry
system. Progress made by this process is checked using three
status reports. These reports compare the file of selected target
samples with the samples in a file containing data uploaded from
the PC-based data entry system.
Updates to CCS are applied to the data base Curing the
nightly update process. Any data entered during the interim before
this process are written to one of many data entry data set files.
These are referred to as "slave files." The slave files mirror the
current state of the data base, which serves to allow for updating
of existing records as well as addition of new records. The first
step in the nightly update process is to extract all new entry
transactions from each slave file. The update process is discussed
in detail in section 3.2.3.
MXS/RAS data are applied to the MIS/RAS data base when
the update process, which typically occurs on a monthly basis, is
activated from the Data entry/Update Menu. The update process is
not requested until the data entry transaction files have been
reviewed by the MX8/RAS MIS coordinator. The contract Master File
and case Master File are updated as separate processes, which
produce update confirmation listings. Any changes made to existing
contract or case records are initiated through the case and
contract Maintenance options on the Date Entry/Update Menu.
changes to existing records are not applied to the data base until
after the update process has been initiated.
TIP data enters the system immediately upon entry.
Multiuser database access is provided through S AS/ SHARE. A nightly
adjustment program is run to perform computations based on contract
provisions.
171
-------
4.2
system output
location*
8AM output My be directed to me or tiro contractor
via a printer destination menu.
4.2.1
Ad Hoc Data Retrieval
8AM ad hoc retrievals are available through FOCUS, which
requires users to be fasdliar with the FOCUS query language and
allows Cor custom report formats, graphics, and special calculation
for financial data.
Requests for STAT data retrievals must be directed to
SMO's project officer at the 1PA Analytical operations Branch.
STAT data retrievals require reference to the list of data elements
to determine which elements are needed for the report, rather than
making a choice from a menu. Data retrievals are negotiated and
refined orally with the system manager to define necessary data
elements and statistical treatment of numerical data. Some typical
requests from STAT ares
- occurrence and concentration data for surface water,
groundwatar, and soils for use in listing 200 (most
commonly detected) toxic chemicals at superfund
sites. Toxicological profiles are produced for the
200 chemicals by the Agency of Toxic substances and
Disease Registry.
- occurrence/concentration reports for EPA'S Office of
Toxic Substances. Test Rules Development Branch,
for use in determining if 90-subchronic toxicity
tests are required under TSCA Section 4.
- Occurrence/concentration reports for BPA's office of
solid Waste to determine the presence of Appendix
VIZI and Appendix IX compounds in groundwater.
- Occurrence/concentration reports for OTS for
compounds on the 1977 TSCA Inventory.
CCS is net designed to accommodate ad hoc query requests.
MZ8/RA8 supports ad hoc queries through requests made
for ad hoe reports on the ADROC Reports menu. The ADBOC Reports
menu allows the user to run management reports that are the basis
for evaluating, planning, and improving analytical services; as
well as effectively managing and enforcing all CL* laboratory
contracts, responding to ad hoc reporting requirements, and
producing reports used to perform quality control checks on KIS/RAS
data.
TIP, like ccs, has no built-in provision for ad hoc
queries. Advanced users familiar with basic SAS and tocos commands
can however perform such queries.
-------
4.2.2
«*M reports are generated on a routine weekly basis.
Monthly and quarterly summaries are also produced. The reports
are generated for each analytical program (organic and inorganic).
The monthly reports (which include weekly summary reports) are
first produced as a preliminary report. After the data entered
into the systems have been thoroughly quality controlled, a final
report is produced for distribution. Three report options are
available to the user. They are allocation reports,
projection/scheduling reports, and ad hoc reports discussed in
Section 4.2.1.
The following reports are available through SAM:
- Monthly Allocation Summary Report
- Monthly Allocation Cumulative Report
- weekly Allocation summary Report
• Quarterly Allocation Management Report
- Monthly Allocation Management Report
- Projection/Scheduling Monthly summary Report
- Weekly Projection/Scheduling Summary Report
* Quarterly Projection/Scheduling Management Report
- Monthly Scheduling/Projection Management Report.
STAT reports are generated on an ad hoc basis only.
hoc retrieval for STAT is discussed in Section 4.2.1.
Ad
CCS reports serve three primary directives. They are:
1) Provide a method of feedback for the labs
regarding their perfomance following their
original data submissions and subsequent
reconciliation efforts.
2) Produce a nightly system error report which
reports on any illogical occurrences of
combinations of data. This report is used for
quality control.
3) Produce a reprocessed samples report to
monitor sample status changes in the system.
173
-------
reports are available 1:o the UMr graphically as
¥•11 as textual ly. fi% tvo Beau* which support these capabilities
axe the R*S Performance Reports Menu »nd the HAS Graphic Menu. The
HAS Performance Exports Menu allow* users to run aui»9«a«nt reports
th«t «r« th« b»»i, (or Managing ud «nforcing all CLP laboratory
contracts. Th« Rxa Graphie Honn allows tho us«r to ma graphs
depicting CLP laboratory co«t», us«ig«, backlog* and data
turnaround. Typ« of reports and graphic* available are:
I)
2)
3)
«)
5)
«)
7)
8)
9)
10)
Backlog data update
Trends in sample timeliness
T/A time distribution by quarters
T/A tiae distribution by months
Data backlog report
Samples in backlog
caseeost report
nr/CY financial and utilization by month
Data backlog by progri
Data backlog aging-rotating months by
lab/program
11) T/A time-trends in samples' timeliness
12) samples analysed by rotating months
13) samples analysed by fiscal year
14) RAS guarterly financiel/util. by programs
TIP produces hundreds of different reports which pertain
to sample lists, invoice reports, and reconciliation.
s.o
Since the SMO systems environment is a highly dynamic
one, the ability for fast implementation of system changes has been
built-in to all SMO systems, controls over change implementation
have been established to maximise the stability of system behavior
and to allow for the most effieieat and effective use of system
maintenance and enhancement resources.
174
-------
0i*r Chang* Control Froc*»»
th*
syst«m »aaag*r is
Chang* worsts for
manager i» usually
. , Of th. syst*«, who h*lp
changa* to th* attention
r**pon*ibl* for
S.I
*• with all ...
responsible- for specifying and
th* corresponding data bas*.
assisted by on* or two ex
in problem resolution and
of th* system manager and th*
implementing the requested changes.
SMO system users report problems to th* system manager
or other users assigned by the system manager to coordinate
requests for programmer support.
5.1.1 System Enhancements
SMO enhancements are report/requested much the same way
that problems are reported, system enhancements must be submitted
in writing and are reviewed for action by the system manager and
appropriate staff.
5.1.2 system Problems
SMO problems are initially submitted to the system
manager and/or a representative for rectification. The SMO user
should fully document the problem to the greatest ^extent possible.
Whenever a problem encountered with a SMO system will
take less than a day to correct, the request may be made verbally
to the programmer. SMO problems/changes requiring more than a day
must be submitted in writing.
In instances where the SMO system manager cannot resolve
the problem, the problem is assigned directly to the programmer,
who is responsible for diagnosing and resolving the problem.
Technical Change Control Process
Chang* Control system Design
5.2
5.2.1 ,.
The SMO test environment is the set of data files and
programs the maintenance programmer uses to test procedures prior
to updating production programs, when maintaining the system, the
programmer should follow a standard procedure for moving production
programs from the production environment to the test environment
-and vice versa. Even though the procedures of moving programs from
the production environment to the test environment seem simple, the
lack of a standard procedure can cause considerable problems.
Therefore, standard maintenance procedures have been established
for use by the data processing staff with the maintenance
responsibility.
175
-------
change control
MO
i
cl»ng«i
in vriti.,
5.2.3
Chang« Control Activity
s:
program*!
problem/enhance
5.2.4 Change Control Testing
the system manager and corresponding r«j
s.2.5 Change control implementation
onoe a 8MO change passes thiro
-—-.#•«> to the production
tasted by the progn
'— representatives.
•ammer and by
— "
...
c
176
-------
€.0
ft major documentation effort Cor all SHO systems occurred
in 1988. Viar was responsible for the development of the
documentation, which is OB an on-going basis, reviewed by an
independent party (PRO). The currency of the documentation Batches
the current life cycle stage of the system documented.
viar'3 SMO documentation is rigorously kept up-to-date.
Viar's change control procedures for system documentation rely on
the use of a written Documentation Change Request (OCR) form to
record any changes to documentation necessitated by system changes.
Another key element of the change control process for documents is
that every page of each document has the date printed in the lower
left corner of the page and the document title appears in the upper
right corner. These headers will support accurate document
identification when requesting changes and will facilitate the
issuance of single updated pages for timely incorporation into the
documentation.
6.1
User Documentation
SAM User Manual
STAT User Manual
FOCUS User Manual
ccs user Manual
MIS/RAS User Manual
TIP user Manual *
6.2
Technical Documentation
SAM Maintenance Manual
SAM Operation Manual
STAT operation/Maintenance Manual
ccs Test Plan **
CCS Design Document
ccs Maintenance Manual *
ccs Operations Manual *
177
-------
t"
------- |