A DATA ENTRY AND RETRIEVAL SYSTEM FOR A COMPUTER SIMULATION (DERS) Insights into Experiential Pedagogy, Volume 6, 1979 291 A DATA ENTRY AND RETRIEVAL SYSTEM FOR A COMPUTER SIMULATION (DERS) David J. Fritzsche, Illinois State University ABSTRACT This paper reports the development of a data entry and retrieval system (DERS) which has been created for the purpose of significantly reducing the mechanical tasks associated with administering an educational simulation [1, p. 39]. DERS thus frees up time which the administrator can use to focus upon the creative aspects of the simulation experience. The system also enables the administrator to run the simulation when standard computer input-output devices are not operating. DERS alters the traditional administrative activity in several ways. First, students are responsible for entering their decision into the computer. Students are also responsible for obtaining their decisions from the computer. Second, no computer cards are used in the simulation. All information is put on and retrieved from disc storage. Third, the administrator actually runs the simulation. DERS was created for use with Marketing in Action C2]. However, the structure could be adapted to fit other simulations. PROGRAM DEVELOPMENT In its current configuration, DERS consists of three stages. Stage One consists of programs which enable the student team to store company decisions on disc. Stage Two contains the programs which the administrator uses to run the simulation. Stage Three enables the team to retrieve the output of the simulation run upon demand. Stage One The heart of the data entry program is a large single dimensional data array. Each element of the array contains one variable of the teams decision. By placing the variables in an array, any variable in the array may be accessed independently of the remaining variables. Thus any variable in the teams decision may be changed without altering the other variables in the decisions. Each teams decision is divided into company decisions and research requests. When operating in a card environment, the company decisions are punched on one card and the research requests are punched on a second card. This separation is maintained in the data entry programs presentation of decision values to the team members even though both types of data are stored in the same array. When a team accesses the program, it is asked whether it would like a list of the current decisions in its file. The team is then asked whether it would like a list of the current research requests in its file. Samples of the decisions listing and the research requests listing are shown in Tables One and Two. In addition to the decision and research values stored in the file, Tables One and Two show the variable numbers which are assigned to each variable for identification purposes. Whenever a variable is altered, the variable number must be specified. When a team member refers to a variable number, he is referring to the element of the array in which the value of the variable is stored. After the decision and research values presently on file are listed (if so desired), the team is asked how many variables they wish to change. In order to change a variable, the number of the variable must entered followed by the new value desired for the variable. The new value is then placed in the element of the array referred to by the variable number. Only the variables which the team desire to change need be accessed. After the decisions for the period have been entered, several provisions are made to check for errors. First, the team is strongly urged to have the program print out their updated decision and research request values. A visual check can then be made to see whether the numbers are those the team intended to enter. Second, any variable value which exceeds the format length of the simulation will appear as asterisks in the decision and research listings. This condition should be discovered and rectified in the visual check of the decision. Finally, several error checks are built into the program. After the team is satisfied that the decision is accurate, the program checks to see whether the sales force allocation sums to one, whether the team is selling a real product, and whether the team has inadvertently fired their sales force. If any of these conditions are found, the program notifies the team and asks them whether they would like to see a listing of their decisions or research requests. The error can then quickly be discovered and corrected. An abridged flow chart of the data entry program is shown in Figure 1 . It should be noted that the team has the option of listing the decision and research values prior to making any changes, after changes are made, and after an error has been found. If the program finds an error, the error must be corrected before the program will terminate normally. If the error is not corrected, the program will continue to loop. The data entry program reads the contents of a teams file into computer memory. All of the alterations made to the teams decision and research variables are made upon the values in computer memory. After all of the changes are complete, the new decision is read back into the team’s permanent file. After this transfer takes place, the program prints the message “run successfully completed. If this message is not received at the end of a run, the team knows that the program has not terminated normally and thus the decision values in their file have not been updated. Stage Two The second stage of DERS consists of a set of programs needed to run the simulation. The administrative data deck containing the parameter values used to run the simulation has been placed on disc and will be referred to as the control file. Prior to running the simulation, a series of activities needs to be accomplished. First the input and Output files must be linked to the simulation program. The simulation program has been slightly altered so that it can read the team decisions from the individual team files. The simulation in its fourth edition can be directed to store the simulation output in individual team files. Second, the current history file is appended to a history storage file. Third, the decisions made by the team are appended to a decision storage file. Fourth, the period number is changed to reflect the current operating period. Finally, the record containing the period number, the record containing any cash adjustments made by the administrator, and the Insights into Experiential Pedagogy, Volume 6, 1979 292 Insights into Experiential Pedagogy, Volume 6, 1979 293 records containing the company decisions are printed at the terminal. These values can be scanned by the administrator and the run aborted if errors are found. The simulation is then run. After the simulation run is completed, the administrative summary, the last page of the administrators output, is printed on the terminal. The total administrators output is also available on disc. However, reference is generally made to only the last page and thus much paper is saved if only the last page is printed. When running the simulation on the Mid-Illinois Computer Cooperative’s Cyber 72, Stage Two is activated with one command from the administrator: -MIA] (PD 14). The instructions needed for file manipulation and calling the simulation are contained in a procedure file called MIA] with the 1 referring to the region being run. The statement in the parentheses indicates that the current period is Period 14. A fairly extensive set of disc files is required to run the simulation in a non-card environment. First two files must be allocated for each team, one for the team’s decisions and one for the teams output. A file must he created for history storage. A file is needed for the administrative data deck. A file must also be reserved for the administrators output from the simulation. Two files are required for backup data, one for history and one for team decisions. One file is required for the simulation program. Finally, a file is needed for the data entry program, and a file is required to control Stage Two operations. Altogether twenty files are required to operate one region containing six teams. Eighteen files are required for each additional region as the simulation program, and the data entry program are available to use in all regions. In addition to the above files which are contained in the administrator’s account, two procedure files have been created in the student team account. These files contain short programs which simplify accessing the data entry program and the print program. These two files are available for all teams to use. Stage Three The third stage consists of a relatively simple procedure file. The file contains a program which enables the team to direct the data in its output file to the line printer. Multiple copies may be made so that each member of the team can have a copy, if desired. Alternatively the team may get copies of their output file by simply listing the file contents on a terminal. The administrator may also obtain a complete copy of his output by directing the system to route the contents of his output file to the line printer. This output is not normally listed on the terminal due to its length. POTENTIAL PRO8LEMS There are two potential problems which can occur when using DERS. First, there are no card decks which can serve as a backup in case a file is destroyed. It is imperative that backup files are created for critical data. These include the contents of the history file and the team decision files. In its present configuration, DERS contains files which store the history and the team decisions for all past periods. Thus the present period data can always be restored if a file is destroyed. One would also be wise to make tape copies of all the programs in DERS so that a system crash would not bring you to your knees. A second problem is one of security. Unless proper precautions are taken, it is likely that unauthorized proprietary information will leak into competitors hands. The way this problem is handled will depend to some extent upon the computer system available. At Illinois State, all of the teams files as well as the simulation and the DERS programs are stored under one account. The teams access the computer using another account. Each team is given read and write permission for its input file and read permission for its output file and the data entry program. The read and write permission for the input and output files is contingent upon the proper password which is supplied to the individual teams. The teams are informed that the password is the key to their files and thus should be carefully protected. If a team believes their password has been discovered by a competitor, it may request a new password from the administrator. By keeping all of the files in an account not accessible to students except by appropriate password, there is no opportunity for teams to damage the data entry program or their files either by accident or on purpose. Their contact with their files is through procedure files, never direct. The procedure files are in the student account; however, they are very simple and easy to replace if damaged. To date, this has not been necessary. Insights into Experiential Pedagogy, Volume 6, 1979 294 USE EXPERIENCE So far the use experience has been quite positive. Students tend to feel that the terminal is more interesting to use than the key punch. They like to be able to pick up their output at their convenience. The number of errors associated with the simulation decisions has been significantly reduced. This is due to the fact that the team has a chance to examine their decision after it has been entered into memory and that the data entry program checks for specific errors and when found will not let the team terminate the program until the errors are corrected. From the administrators perspective, DERS has reduced the amount of time required to process a decision. Instead of collecting and checking cards for errors, submitting cards for a run, and distributing the output, the task involves typing one instruction on the terminal and then a scanning of the decisions previously checked by the computer. There are several distinct operational advantages to DERS. First, the administrator has complete control over the simulation run. He does not have to depend upon computer center personnel. Second, if the card reader or printer is out of order, the simulation is not affected. The output can be obtained via terminal. Third the simulation play does not have to revolve around class meetings. Times can be set for decisions to be due. The decision can then be run with the output being picked up at the teams convenience. Thus more than one decision can be made through the week even though a class may meet only one night a week. This configuration is also advantageous if the administrator is ill. The simulation can be run from the bedside if a portable terminal and phone are available. Possibly one of the biggest advantages of DERS is that it forces the student to become more comfortable with the computer via familiarity. The computer terminal must be used to participate in the simulation. It becomes a tool which is used to accomplish a task. Thus, if the student finds a terminal on the desk when assuming the first job out of college, no trauma is likely to occur. REFERENCES [1] Fritzsche, David J., “Lets Simplify the Administrative Requirements of Computerized Educational Simulations,” Exploring Experiential Learning: Simulations and Experiential Exercises, The Proceedings of the Fifth National A8SEL Conference, Denver, Colorado, 1978, pp. 39-43. [2] Ness, Thomas E. and Ralph L. Day, Marketing In Action: A Decision Game, 4th ed., (Homewood: Richard D. Irwin, Inc., 1978). Table of Contents Volume 6, 1979 The Use of Cases with Role Plays in a Research Methods Course Debugging and Implementing the Live-Case Approach to Marketing Research in the Australian Environment Using a Case as the Basis for a Modified Debate Using Cases in Business Communication Classes A Structured Approach to Case Analysis and Reporting Intercollegiate Case Analysis Competition as an Experiential Learning Experience Attributes Germane to Student/Live Case Situations Understanding Dispute Resolution Through Experiential learning Personality Development and Conflict Dynamics: An Experimental Design to Study the Effects of Teaching Methodologies on Conflict Resolution Interpersonal Competence and the Digital PDP-11:40 The process of Writing a Collective Bargaining Simulation: A Case Study in Practical Pedagogy Simulating Negotiations in an Educational Context Simulations as a Technique for Teaching Collective Bargaining Experiential Processing of Differing Managerial Perspectives: The Use of a Game Show Format Individual Self Report vs. Group consensus in Small Decision-Making Groups Effects of Sex-Role Stereotypes on Promotion Decisions: An Exercise Computer Aids to Planning: The Budget and Forecasting Module Use of a Microcomputer in a Decision Analysis for Investment Portfolio Selection A Game of Investment Strategy: Description, Use, Criticism and Modification Coping with Future Uncertainties Through Probabilistic Budgeting Administration and Design of Simulation Materials for a Specialized Management Training Program Managing Stress in Organizational Life Banksim: The Bank Management Simulation Issues in the Organizational Application of Simulation and Experiential material Games Within Games: The Role of the Glitch Experiential Learning from Classroom to Business An Evaluation of the Small Business Institute Program as an Experiential learning Exercise Conversations with Top Management (Simulated) Experience in the Use and Assessment of Simulation in Management Education A Statistical Analysis of Simulation Users: Relationships between Stress and Human Subject guidelines Group Decision Making in a Computer Game Analysis of Demographic and Psychosocial Variables Comparing Performance During Three Managerial Accounting Simulation Schedules Business Policy Simulation and the Intense Course Structure The Use of Intensive Simulation in Executive Development and Academic Settings The Use of Experiential Exercises in the Undergraduate Consumer Behavior Course A Personal Marketing Strategy Approach: Framework and Application Teaching PERT Experientially in Marketing Research Discovering the Majority Fallacy An Experiential Approach to Studying International Business A Demonstration of the Business Simulation Game as a Curriculum Assessment Device Relating Teaching Methods with Educational Objectives in the Business Curriculum The Junior Achievement Applied Management Program as a Compromise Situation Between the Simulation and the Internship Who is Using Computerized Business Games?: A View from Publishers' Adoption Lists Trials and Tribulations in Testing Educational Innovations An Examination of the Perceived Effectiveness of Computer Simulation in a Classroom Setting as Affected by Game, Environmental and Respondent Characteristics Game Administration: A Life Cycle Analysis Research on the Effectiveness of Using a Computerized Simulation in the Basic Management Course Gaming and Attitudinal Change The Teacher-Student Relationship in Experiential Classes and the Student's Perception of Course Effectiveness An Exploratory Study of Student Characteristics and Educational Processes in Programmatic Experiential learning General Incongruity Adaption Level (GIAL) as a Predictor of Risk Preferences in a Simulated Management Game The Cap-Stone Opportunity: Combining Business Simulation and Experiential Learning Incorporating MIS/DSS into Policy Courses Via Simulation Who Benefits Most from Participation in Business Policy Simulations: An Empirical Study of Skill Development by Functional Areas The Use of Program NAMEX in Teaching the Accounting for Nonmonetary Assets The Use of Program CVP in Teaching Cost-Volume-Profit Analysis Experiential vs. Traditional Classroom Approach in the Basic Management Course: A Puerto Rican Experience A Guide to the Successful Use of Business Simulation Games The Dynamic Aspects of Interactive Gaming Puts the Realism into Gaming System Representation of SIMORG The Design of a Database System to Support Business Simulation and Experiential Learning A Data Entry and Retrieval System for a Computer Simulation (DERS) Simulation - An Advantage for Accounting Research Computer-Aided Project Performance Control Simulation: An Interactive Experiential Gaming Technique for Managerial Decision Making Utilization of Manual Simulation Games to Develop Scenarios of Future Events - An Exploratory Study Foundry: A Foundry Simulation Customized Debriefing: The Achilles Heel of Experiential learning? Computerized Business Simulations and Experiential Learning Exercises: An Instructional Interface The Baseball Game: A Group Role Observation, Problem Solving Experience A Practical Design for Experiential Learning Exercises: Roles, Technical Equipment and Alternative Debriefing Formats