- Email: [email protected]
Pollution prevention survey using microcomputers
Computers and Industrial Engineering Vol. 23, Nos 1-4, pp. 447--450, 1992 Printed in Great Britain. All rights reserved
0360-8352192 $5.00+0.00 Copyright © 1992 Pergamon Press Ltd
POLLUTION PREVENTION SURVEY USING MICROCOMPUTERS John H. Ristroph, Ranganathan Muralidharan, Naresh Miglani Engineering Management Program University of Southwestern Louisiana Kym Arcuri Environmental Excellence, Inc. Maurice Knight, Cy Buchert Louisiana Department of Environmental Quality
ABSTRACT This paper describes a microcomputer based survey used to determine barriers to pollution prevention. It describes the operation of the system, aspects of software development, and data structures and analysis procedures. It also provides practical considerations in implementing such a system. INTRODUCTION Pollution prevention relies heavily on proven industrial engineering techniques. In its simplest sense, pollution is waste, inefficient and costly. Some of the procedures used to prevent pollution are familiar to industrial engineers, such as waste reduction, yield improvement, and process flow charting. A systems viewpoint is necessary lest a reduction of wastes released to one medium, such as air, increase the waste stream in another medium, such as water. This paper describes a survey which systematically examines economic, technical, regulatory barriers to multi-media pollution prevention. It represents another area of IE involvement in pollution prevention, information systems. Although the survey is comprehensive in nature, requiring fifty pages of responses, it is designed to take only one to three engineering days to complete. It is one of the first of its kind for this type of environmental reporting, joining a major federal system which is also coming on line. The following sections describe the operation of the system from the viewpoint of the user, and then present the development of the software for the survey, its data structures and the analysis system. This is followed by a brief discussion of some practical considerations which might prove useful in developing similar systems. OPERATION The survey is currently being sent to major generators of hazardous wastes and toxic releases in Louisiana by the Louisiana Department of Environmental Quality (DEQ). Each facility receives a package containing a cover letter, instructions for installing and using the software, a paper copy of the survey, and a diskette containing the programs and their files. The cover letter provides general information about the survey and references the installation and use instructions. The software is written for PC compatibles using a DOS environment. The installation instructions are fairly simple. A user can either create a directory on a hard drive and copy all of the files on the diskette to that directory or use a batch program which does the same thing. The user instructions state how to start the program and operate it. It is anticipated that the respondents will use the paper copy of the survey as a scratch pad and fill it out by hand as the information is collected over time. Most questions require only short answers: Y or N, a rating from 0 to 10 of the significance of a barrier, identification codes, chemical names, percentage mixes, and so forth. A few questions provide the opportunity for brief descriptions of problems and similar responses. Once the respondent has completed the paper form, then those responses need to be entered on the computer. It seems likely that this data entry will be assigned to a member of the clerical staff, just as typing the responses would normally be done by a secretary; so the operation of the system has been designed with that in mind. The software is activated by changing to its directory and then typing SURVEY. The initial screen welcomes the respondent and gives a brief description of the system. The bottom left of the display shows the name of the screen (Welcome Screen, in this case) and at the lower right is a message to press PAGEDOWN for the next screen. The second screen is the menu, shown in Table 1. Its options provide for entering and editing data, going directly to any page of the form, help, outputting files to be sent to the DEQ, printing the survey, and quitting. The first screen for data entry is a pre-filled identification screen which is to be edited if there is any incorrect information. The screen identifier consists of the corresponding page number on the paper form followed by a screen number, such as Page 12 / Screen 1; it can take up to three screens to show one page of the printed form. This type of screen identifier allows the user to know where he or she is at all times. It also allows the user to skip directly to any page of the form. This can be done either by press ESC from a form screen and then using the menu, or simply by pressing F10 at any time; in either case a prompt will request the page number.
447
448
Proceedings of the 14th Annual Conference on Computers and Industrial Engineering
Editing features are similar to a word processor's, such as erasing with the Backspace or Delete keys and toggling between insert and type over modes by pressing INSERT. The system help screen explains how to use these features, as well as how to navigate through the form. Help can be obtained through the menu or simply by pressing F1; pressing ESC returns the system to the prior screen. Choosing the Quit option from the menu allows the users to stop for awhile. The system automatically stores the responses, so the user does not have to worry about saving them.
Table 1. Menu Please press first letter of desired action, such as H for Help; or highlight choice using arrow keys a n d then press ENTER.
Edit or enter data Go to a page (FI0) Help (F1) Output files for DEQ Print the survey Quit
After all responses have been entered and checked, then the user can select the option to output files for DEQ. This causes the dBase [1] files containing the responses to be copied to the floppy disk used to install the system. The option to print the form allows Henu Screen the user to create a hard copy of the completed form for his or her records. The system creates a file named DEQSUR92.PRN which can be printed by using the DOS COPY command to send it to the printer. Printer independence is obtained by using backspaces for underlining and formfeeds for advancing the page. Lines are printed as they appear on the CRT, so they are no longer than 80 characters in length. This will fit on one line of printed output for a printer outputting at 10 characters per inch and allow one quarter of an inch margins. This procedure has been found to work on both Epson and Hewlett Packard compatible printers. S O F r W A R E DEVELOPMENT The system was developed so that it could be distributed on a single high density diskette. Other options would have involved potential communications procedures or resources which were not considered appropriate for an initial effort. The number of respondents is currently 117 facilities with major waste streams, so diskettes provide a convenient distribution mechanism. Other options might have to be considered if more facilities are to be polled. A variety of popular data base management packages were examined to see if they could produce a survey system that would fit on a single diskette. Some of the systems provided a run time support module which could be distributed without violating copyrights, but this added anywhere from 1 to 3 megabytes to the size of the system. The Clipper [2] system was well established and produced .EXE files of a more reasonable size, so that system was used. Its source code is fairly compatible with dBase HI Plus, which allowed a convenient development procedure. The form generator facility of dBase IV essentially allows a user to type the forms directly onto the screen, and then it writes the dBase source code which will produce the same screen. This allowed dBase IV to be used as a code generator, and then the source code was slightly modified so that it could be input to Clipper. One of the major modifications was that dBase supported multi-screen forms, but Clipper did not. This problem was circumvented by breaking the dBase code into procedures, one procedure per screen. Then code was written to control the program flow between these procedures. The logic for each procedure uses dBase's SAY, GET, and READ commands. The text of each line is written to the screen using a variant of the SAY command: @ row, column SAY This is the text of the line written to the screen. Then the GET command identifies where data fields are to be highlighted on the screen and the name of the field: @ row, column GET FieldName The width of each field and its attributes, such as numeric or string, must be previously defined before its use in a GET, so Clipper knows how many spaces to highlight and what type of data to expect. The GET command makes no attempt to actually input the data; this is done by the READ command. Understanding the GET and READ commands was necessary to make cursor moves between fields behave in a way that seemed fairly natural to a word processor operator. Each GET command can be thought of as creating a row in a table named GETLIST which is used by the READ command. The columns of this table include the name of the field, where it is located, and other information. Each GET causes a new row to be created. The first GET is stored on the first row; the second GET is stored on the second row, and so forth. The READ command causes the first row of this table to be accessed, and the cursor to be placed in the proper location. Then the READ command tests each keystroke to determine if it is a data entry key, editing key, cursor movement key, and so forth. By default, pressing a TAB or ENTER key advances the row pointer for the GETLIST table to the next row and moves the cursor to the indicated field. However, special programming might be necessary for other exit keys, such as UP or DOWN, as is described below. Clipper uses a pre-processor to break the READ command down into lower level Clipper statements, to which the programmer has full access. READ is translated into a call to the READMODAL function which has GEl'LIST as an argument. READMODAL processes the GET stored as the first row of GETLIST, calling a function named SETTLE to see if the current field should be exited. The user has complete access to the code for these functions, so they can be modified as desired. For example, suppose that consecutive GET's display 5 fields on one line of the screen, then another 5, and so forth. The user would expect DOWN to move the cursor down one line, which
RISTROPH et al.: Pollution Prevention
449
requires incrementing the GETLIST's row pointer by 5. SETTLE can be reprogrammed to conStLlt a look up table when DOWN causes an exit to find the increment for GETLIST's row pointer. Similar programming can be used for UP and other keys to simulate the behavior that a user familiar with a word processor would expect. This requires manually storing increments in a look up table and providing the associated coding. Finally, when the user requests a new screen with PAGEUP, PAGEDOWN, or F10, all of the data entries are stored; the old GETLIST table is cleared; and a new one is created for the next screen and its READ statement. After the user requests a new screen, then the program exits the procedure used for the current screen; and returns to the screen controller. The screen controller has two major components. The first component keeps track of screen numbers. Over 100 screens are used by the system, and they are numbered 1, 2, 3, etc. If the user selects the menu option Enter or edit data, then screen number 1 is displayed. If PAGEDOWN is pressed, then page number 2 is displayed, and so forth. When the procedure for the current screen is exited, then the controller determines which key caused the exit and appropriately updates the screen number and stores it in the variable ScreenNumber. Then the second component of the controller calls the procedure for the new screen by using a set of CASE statements illustrated by the following pseudo code: CASE ScreenNumber = 10 Declare files to be used Call procedure for screen number 10 CASE ScreenNumber = 11 If an exit is caused by the F10 key instead of PAGEDOWN or PAGEUP, then control first branches to a proc~ure named F10Handler to determine the new value of ScreenNumber. Fl0Handler askers the user for the number of the page on the paper form which is to be displayed, and then consults a look up table to find its screen number. Once a value is assigned to ScreenNumber, then the CASE statements are used to call the appropriate procedure. Dynamically replicating fields posed another developmental problem. For example, suppose that a company is asked for all of the constituents of a certain type of waste. If only 3 blank fields were provided on the screen, then the user might want to add more. Neither dBase nor Clipper provide a high level procedure to dynamically replicate fields on a screen. Code was developed to do this, but the product was found to be awkward from a user viewpoint. For example, programming considerations made it was best to put replicatable fields on a screen by themselves, but this could lead to odd displays. It was also necessary to code around the absence lack of multi-screen forms in Clipper. These difficulties required that the user master additional operations to control form display and data entry. Since this is the first experience that most users will have with such a system, it was decided to avoid such complications. Instead, the survey was redesigned to avoid such problems with little loss of information. For example, instead of asking a respondent to list all constituents of a wastes, the form now ~s~ for only 5 major ones. As another example, the size of the input region for short narrative responses was doubled instead of providing a small region with the capability of dynamically expanding it. (Fixed length fields were used for narratives rather than variable length memo fields so that the same field exit keys, such as TAB or ENTER, could be used through the survey; other exit keys are used for memo fields.) DATA STRUCTURES AND ANALYSIS After a screen is exited, Clipper stores its data in a disk file. The size of Clipper records is limited to 256 fields or 4,000 bytes per record, whichever occurs first. The survey requires ten files to hold each user's responses. Eight of the files contain one record each, and the other two contain multiple records. The ninth file uses seven records for fields common to different parts of the survey that are grouped to save space on the diskette. For example, chemical identification codes are requested for releases to water in one part of the survey and for releases to air in another part of the survey; the format of these codes does not change, so they can all be placed in the same field, with one record being used for water and another for air. The tenth file stores all of the narrative responses. Every data file has one common field, the facility identification number. This permits files to be linked or merged as necessary. In addition to data files, the system stores its look up tables in files. The file containing the GETLIST increments used for the UP and DOWN keys is indexed on field names for fast retrieval. Similarly, the file associating paper page numbers with screen numbers is indexed on page numbers. There are a variety of other files, but they are of a fairly routine nature, including program code and help messages which are indexed on field name. Each respondent will return the system diskette which will contain the updated data files. A program which aggregates users' responses requests each of the 31A" diskettes and then the 5~,~" diskettes. This program produces analysis files for which the data has been reorganized in such a matter that it can be easily processed by the statistical and graphics system, Systat [3]. For example, the contents of records in the data file containing seven records are dispersed among the other files so that little data reorganization must be done by Systat. The analysis files are stored in dBase III format which can be imported into Systat. Most of the analyses consist of statistical summaries of responses, such as the average significance (from 0 to 10) assigned by respondents to different barriers. Systat's procedures are used to compute the various statistics
450
Proceedings of the 14th Annual Conference on Computers and Industrial Engineering
which summarize the responses, and also to provide histograms and other relevant information. In some cases, conditional statistics are desired, such as the average significance assigned to a barrier by respondents who fall into a particular category. Systat's SELECT command can be used to set a condition for subsequent procedures, so such statistics readily can be computed when all of the relevant data is on one file. The results of the analyses can be output to an ASCII file, so that they can be edited as necessary before printing the final report. Other output media include exporting spreadsheets which can be imported as the tables in various word processors. After the analysis files have been processed, they will be stored as a permanent record of the survey. It is anticipated that some form of ad hoc queries will eventually be performed on the analysis files. The query by example facility of Paradox [4] is well suited for this, as are its cross tabulation and graphics procedures. The format of the files is such that they can be imported into Paradox. PRACTICAL CONSIDERATIONS This section provides some practical considerations appropriate for a similar effort, such as the level of effort required to learn how to use the software. This project's programmers had several month's experience using dBase before the project began; and Clipper's language was similar to dBase, so the time required to learn the Clipper's basics was fairly short, a week or two. Initial plans were to code in the more familiar dBase environment and then compile that code using Clipper, but experimentation soon revealed that the fastest method for developing code was to use dBase's form generator and modify its code for Clipper. Differences between the systems were recognized, such as the lack of multi-screen forms in Clipper. The design of the Clipper system differs from dBase in that it allows the programmer to access lower level code for commands such as the GET and READ. It was found to be worthwhile to learn how those commands work and the best way to modify them, such as the use of look up tables. Finally, Clipper's debugging and compilation procedures were different from dBase's, although this transition was fairly smooth. Although it seemed reasonable to expect that most facilities would have an PC compatible, it was recognized that the configurations of these machines could vary. A preliminary, one page survey was mailed to respondents asking if their facility could support the default system which used DOS 3.3 or later, a hard drive with 2 MB available, 3t/z" high density floppies, and a VGA color screen. The vast majority of the facilities had such a system available, but some respondents seemed to describe only the machine sitting on their desks; for example, it is hard to imagine a major corporation known to have a strong information systems group with only a CGA available. The software was tested on a variety of other systems, such as those with monochrome monitors or without hard drives, and found to function satisfactorily; so it was felt that almost everyone should be able to run the survey program. Nonetheless, arrangements were made to allow respondents to use a microcomputer at DEQ to enter their data or, on a worse case basis, to have the data entered for a facility. It is not anticipated that either of these measures will be necessary, but problems could possibly occur as the survey is extended to smaller facilities. An industrial review of the survey resulted in many excellent suggestions for improving the survey which were implemented. It was quickly learned that the dBase/Clipper platform is not a convenient tool for editing large surveys if there are a fairly large number of changes, as there were in this case. Part of the problem is that both systems are screen oriented. Thus if, for example, half of one screen were eliminated, then there was no easy method for simply moving up the remaining screen by a half of a screen. This lack of a convenient editing procedure is a significant problem due to the large size of the system, roughly 5,000 lines of code. It is best to wait until the final paper draft is completed. A system is currently being coded in a lower level language to avoid this type of editing problem. The new system will also be able to integrate screen and printer output more effectively; the current system requires separate modules of approximately equal size. Software References 1.
dBase is a product of from Ashton Tare Corporation (213-329-8000).
2.
Clipper is a product of Nantucket Corporation (213-390-7923).
3.
Systat is a product of Systat Corporation (708-864-5670).
4.
Paradox is a product of Borland Corporation (408-438-5300).
0360-8352192 $5.00+0.00 Copyright © 1992 Pergamon Press Ltd
POLLUTION PREVENTION SURVEY USING MICROCOMPUTERS John H. Ristroph, Ranganathan Muralidharan, Naresh Miglani Engineering Management Program University of Southwestern Louisiana Kym Arcuri Environmental Excellence, Inc. Maurice Knight, Cy Buchert Louisiana Department of Environmental Quality
ABSTRACT This paper describes a microcomputer based survey used to determine barriers to pollution prevention. It describes the operation of the system, aspects of software development, and data structures and analysis procedures. It also provides practical considerations in implementing such a system. INTRODUCTION Pollution prevention relies heavily on proven industrial engineering techniques. In its simplest sense, pollution is waste, inefficient and costly. Some of the procedures used to prevent pollution are familiar to industrial engineers, such as waste reduction, yield improvement, and process flow charting. A systems viewpoint is necessary lest a reduction of wastes released to one medium, such as air, increase the waste stream in another medium, such as water. This paper describes a survey which systematically examines economic, technical, regulatory barriers to multi-media pollution prevention. It represents another area of IE involvement in pollution prevention, information systems. Although the survey is comprehensive in nature, requiring fifty pages of responses, it is designed to take only one to three engineering days to complete. It is one of the first of its kind for this type of environmental reporting, joining a major federal system which is also coming on line. The following sections describe the operation of the system from the viewpoint of the user, and then present the development of the software for the survey, its data structures and the analysis system. This is followed by a brief discussion of some practical considerations which might prove useful in developing similar systems. OPERATION The survey is currently being sent to major generators of hazardous wastes and toxic releases in Louisiana by the Louisiana Department of Environmental Quality (DEQ). Each facility receives a package containing a cover letter, instructions for installing and using the software, a paper copy of the survey, and a diskette containing the programs and their files. The cover letter provides general information about the survey and references the installation and use instructions. The software is written for PC compatibles using a DOS environment. The installation instructions are fairly simple. A user can either create a directory on a hard drive and copy all of the files on the diskette to that directory or use a batch program which does the same thing. The user instructions state how to start the program and operate it. It is anticipated that the respondents will use the paper copy of the survey as a scratch pad and fill it out by hand as the information is collected over time. Most questions require only short answers: Y or N, a rating from 0 to 10 of the significance of a barrier, identification codes, chemical names, percentage mixes, and so forth. A few questions provide the opportunity for brief descriptions of problems and similar responses. Once the respondent has completed the paper form, then those responses need to be entered on the computer. It seems likely that this data entry will be assigned to a member of the clerical staff, just as typing the responses would normally be done by a secretary; so the operation of the system has been designed with that in mind. The software is activated by changing to its directory and then typing SURVEY. The initial screen welcomes the respondent and gives a brief description of the system. The bottom left of the display shows the name of the screen (Welcome Screen, in this case) and at the lower right is a message to press PAGEDOWN for the next screen. The second screen is the menu, shown in Table 1. Its options provide for entering and editing data, going directly to any page of the form, help, outputting files to be sent to the DEQ, printing the survey, and quitting. The first screen for data entry is a pre-filled identification screen which is to be edited if there is any incorrect information. The screen identifier consists of the corresponding page number on the paper form followed by a screen number, such as Page 12 / Screen 1; it can take up to three screens to show one page of the printed form. This type of screen identifier allows the user to know where he or she is at all times. It also allows the user to skip directly to any page of the form. This can be done either by press ESC from a form screen and then using the menu, or simply by pressing F10 at any time; in either case a prompt will request the page number.
447
448
Proceedings of the 14th Annual Conference on Computers and Industrial Engineering
Editing features are similar to a word processor's, such as erasing with the Backspace or Delete keys and toggling between insert and type over modes by pressing INSERT. The system help screen explains how to use these features, as well as how to navigate through the form. Help can be obtained through the menu or simply by pressing F1; pressing ESC returns the system to the prior screen. Choosing the Quit option from the menu allows the users to stop for awhile. The system automatically stores the responses, so the user does not have to worry about saving them.
Table 1. Menu Please press first letter of desired action, such as H for Help; or highlight choice using arrow keys a n d then press ENTER.
Edit or enter data Go to a page (FI0) Help (F1) Output files for DEQ Print the survey Quit
After all responses have been entered and checked, then the user can select the option to output files for DEQ. This causes the dBase [1] files containing the responses to be copied to the floppy disk used to install the system. The option to print the form allows Henu Screen the user to create a hard copy of the completed form for his or her records. The system creates a file named DEQSUR92.PRN which can be printed by using the DOS COPY command to send it to the printer. Printer independence is obtained by using backspaces for underlining and formfeeds for advancing the page. Lines are printed as they appear on the CRT, so they are no longer than 80 characters in length. This will fit on one line of printed output for a printer outputting at 10 characters per inch and allow one quarter of an inch margins. This procedure has been found to work on both Epson and Hewlett Packard compatible printers. S O F r W A R E DEVELOPMENT The system was developed so that it could be distributed on a single high density diskette. Other options would have involved potential communications procedures or resources which were not considered appropriate for an initial effort. The number of respondents is currently 117 facilities with major waste streams, so diskettes provide a convenient distribution mechanism. Other options might have to be considered if more facilities are to be polled. A variety of popular data base management packages were examined to see if they could produce a survey system that would fit on a single diskette. Some of the systems provided a run time support module which could be distributed without violating copyrights, but this added anywhere from 1 to 3 megabytes to the size of the system. The Clipper [2] system was well established and produced .EXE files of a more reasonable size, so that system was used. Its source code is fairly compatible with dBase HI Plus, which allowed a convenient development procedure. The form generator facility of dBase IV essentially allows a user to type the forms directly onto the screen, and then it writes the dBase source code which will produce the same screen. This allowed dBase IV to be used as a code generator, and then the source code was slightly modified so that it could be input to Clipper. One of the major modifications was that dBase supported multi-screen forms, but Clipper did not. This problem was circumvented by breaking the dBase code into procedures, one procedure per screen. Then code was written to control the program flow between these procedures. The logic for each procedure uses dBase's SAY, GET, and READ commands. The text of each line is written to the screen using a variant of the SAY command: @ row, column SAY This is the text of the line written to the screen. Then the GET command identifies where data fields are to be highlighted on the screen and the name of the field: @ row, column GET FieldName The width of each field and its attributes, such as numeric or string, must be previously defined before its use in a GET, so Clipper knows how many spaces to highlight and what type of data to expect. The GET command makes no attempt to actually input the data; this is done by the READ command. Understanding the GET and READ commands was necessary to make cursor moves between fields behave in a way that seemed fairly natural to a word processor operator. Each GET command can be thought of as creating a row in a table named GETLIST which is used by the READ command. The columns of this table include the name of the field, where it is located, and other information. Each GET causes a new row to be created. The first GET is stored on the first row; the second GET is stored on the second row, and so forth. The READ command causes the first row of this table to be accessed, and the cursor to be placed in the proper location. Then the READ command tests each keystroke to determine if it is a data entry key, editing key, cursor movement key, and so forth. By default, pressing a TAB or ENTER key advances the row pointer for the GETLIST table to the next row and moves the cursor to the indicated field. However, special programming might be necessary for other exit keys, such as UP or DOWN, as is described below. Clipper uses a pre-processor to break the READ command down into lower level Clipper statements, to which the programmer has full access. READ is translated into a call to the READMODAL function which has GEl'LIST as an argument. READMODAL processes the GET stored as the first row of GETLIST, calling a function named SETTLE to see if the current field should be exited. The user has complete access to the code for these functions, so they can be modified as desired. For example, suppose that consecutive GET's display 5 fields on one line of the screen, then another 5, and so forth. The user would expect DOWN to move the cursor down one line, which
RISTROPH et al.: Pollution Prevention
449
requires incrementing the GETLIST's row pointer by 5. SETTLE can be reprogrammed to conStLlt a look up table when DOWN causes an exit to find the increment for GETLIST's row pointer. Similar programming can be used for UP and other keys to simulate the behavior that a user familiar with a word processor would expect. This requires manually storing increments in a look up table and providing the associated coding. Finally, when the user requests a new screen with PAGEUP, PAGEDOWN, or F10, all of the data entries are stored; the old GETLIST table is cleared; and a new one is created for the next screen and its READ statement. After the user requests a new screen, then the program exits the procedure used for the current screen; and returns to the screen controller. The screen controller has two major components. The first component keeps track of screen numbers. Over 100 screens are used by the system, and they are numbered 1, 2, 3, etc. If the user selects the menu option Enter or edit data, then screen number 1 is displayed. If PAGEDOWN is pressed, then page number 2 is displayed, and so forth. When the procedure for the current screen is exited, then the controller determines which key caused the exit and appropriately updates the screen number and stores it in the variable ScreenNumber. Then the second component of the controller calls the procedure for the new screen by using a set of CASE statements illustrated by the following pseudo code: CASE ScreenNumber = 10 Declare files to be used Call procedure for screen number 10 CASE ScreenNumber = 11 If an exit is caused by the F10 key instead of PAGEDOWN or PAGEUP, then control first branches to a proc~ure named F10Handler to determine the new value of ScreenNumber. Fl0Handler askers the user for the number of the page on the paper form which is to be displayed, and then consults a look up table to find its screen number. Once a value is assigned to ScreenNumber, then the CASE statements are used to call the appropriate procedure. Dynamically replicating fields posed another developmental problem. For example, suppose that a company is asked for all of the constituents of a certain type of waste. If only 3 blank fields were provided on the screen, then the user might want to add more. Neither dBase nor Clipper provide a high level procedure to dynamically replicate fields on a screen. Code was developed to do this, but the product was found to be awkward from a user viewpoint. For example, programming considerations made it was best to put replicatable fields on a screen by themselves, but this could lead to odd displays. It was also necessary to code around the absence lack of multi-screen forms in Clipper. These difficulties required that the user master additional operations to control form display and data entry. Since this is the first experience that most users will have with such a system, it was decided to avoid such complications. Instead, the survey was redesigned to avoid such problems with little loss of information. For example, instead of asking a respondent to list all constituents of a wastes, the form now ~s~ for only 5 major ones. As another example, the size of the input region for short narrative responses was doubled instead of providing a small region with the capability of dynamically expanding it. (Fixed length fields were used for narratives rather than variable length memo fields so that the same field exit keys, such as TAB or ENTER, could be used through the survey; other exit keys are used for memo fields.) DATA STRUCTURES AND ANALYSIS After a screen is exited, Clipper stores its data in a disk file. The size of Clipper records is limited to 256 fields or 4,000 bytes per record, whichever occurs first. The survey requires ten files to hold each user's responses. Eight of the files contain one record each, and the other two contain multiple records. The ninth file uses seven records for fields common to different parts of the survey that are grouped to save space on the diskette. For example, chemical identification codes are requested for releases to water in one part of the survey and for releases to air in another part of the survey; the format of these codes does not change, so they can all be placed in the same field, with one record being used for water and another for air. The tenth file stores all of the narrative responses. Every data file has one common field, the facility identification number. This permits files to be linked or merged as necessary. In addition to data files, the system stores its look up tables in files. The file containing the GETLIST increments used for the UP and DOWN keys is indexed on field names for fast retrieval. Similarly, the file associating paper page numbers with screen numbers is indexed on page numbers. There are a variety of other files, but they are of a fairly routine nature, including program code and help messages which are indexed on field name. Each respondent will return the system diskette which will contain the updated data files. A program which aggregates users' responses requests each of the 31A" diskettes and then the 5~,~" diskettes. This program produces analysis files for which the data has been reorganized in such a matter that it can be easily processed by the statistical and graphics system, Systat [3]. For example, the contents of records in the data file containing seven records are dispersed among the other files so that little data reorganization must be done by Systat. The analysis files are stored in dBase III format which can be imported into Systat. Most of the analyses consist of statistical summaries of responses, such as the average significance (from 0 to 10) assigned by respondents to different barriers. Systat's procedures are used to compute the various statistics
450
Proceedings of the 14th Annual Conference on Computers and Industrial Engineering
which summarize the responses, and also to provide histograms and other relevant information. In some cases, conditional statistics are desired, such as the average significance assigned to a barrier by respondents who fall into a particular category. Systat's SELECT command can be used to set a condition for subsequent procedures, so such statistics readily can be computed when all of the relevant data is on one file. The results of the analyses can be output to an ASCII file, so that they can be edited as necessary before printing the final report. Other output media include exporting spreadsheets which can be imported as the tables in various word processors. After the analysis files have been processed, they will be stored as a permanent record of the survey. It is anticipated that some form of ad hoc queries will eventually be performed on the analysis files. The query by example facility of Paradox [4] is well suited for this, as are its cross tabulation and graphics procedures. The format of the files is such that they can be imported into Paradox. PRACTICAL CONSIDERATIONS This section provides some practical considerations appropriate for a similar effort, such as the level of effort required to learn how to use the software. This project's programmers had several month's experience using dBase before the project began; and Clipper's language was similar to dBase, so the time required to learn the Clipper's basics was fairly short, a week or two. Initial plans were to code in the more familiar dBase environment and then compile that code using Clipper, but experimentation soon revealed that the fastest method for developing code was to use dBase's form generator and modify its code for Clipper. Differences between the systems were recognized, such as the lack of multi-screen forms in Clipper. The design of the Clipper system differs from dBase in that it allows the programmer to access lower level code for commands such as the GET and READ. It was found to be worthwhile to learn how those commands work and the best way to modify them, such as the use of look up tables. Finally, Clipper's debugging and compilation procedures were different from dBase's, although this transition was fairly smooth. Although it seemed reasonable to expect that most facilities would have an PC compatible, it was recognized that the configurations of these machines could vary. A preliminary, one page survey was mailed to respondents asking if their facility could support the default system which used DOS 3.3 or later, a hard drive with 2 MB available, 3t/z" high density floppies, and a VGA color screen. The vast majority of the facilities had such a system available, but some respondents seemed to describe only the machine sitting on their desks; for example, it is hard to imagine a major corporation known to have a strong information systems group with only a CGA available. The software was tested on a variety of other systems, such as those with monochrome monitors or without hard drives, and found to function satisfactorily; so it was felt that almost everyone should be able to run the survey program. Nonetheless, arrangements were made to allow respondents to use a microcomputer at DEQ to enter their data or, on a worse case basis, to have the data entered for a facility. It is not anticipated that either of these measures will be necessary, but problems could possibly occur as the survey is extended to smaller facilities. An industrial review of the survey resulted in many excellent suggestions for improving the survey which were implemented. It was quickly learned that the dBase/Clipper platform is not a convenient tool for editing large surveys if there are a fairly large number of changes, as there were in this case. Part of the problem is that both systems are screen oriented. Thus if, for example, half of one screen were eliminated, then there was no easy method for simply moving up the remaining screen by a half of a screen. This lack of a convenient editing procedure is a significant problem due to the large size of the system, roughly 5,000 lines of code. It is best to wait until the final paper draft is completed. A system is currently being coded in a lower level language to avoid this type of editing problem. The new system will also be able to integrate screen and printer output more effectively; the current system requires separate modules of approximately equal size. Software References 1.
dBase is a product of from Ashton Tare Corporation (213-329-8000).
2.
Clipper is a product of Nantucket Corporation (213-390-7923).
3.
Systat is a product of Systat Corporation (708-864-5670).
4.
Paradox is a product of Borland Corporation (408-438-5300).