sub store 		{
		my $recs=new FileHandle('/home/www/recs','>>') or die "can't open file";
		my $j=0;
		my $k=0;
		my $test;
		my (@ec,@rc,@pc,@erc,@et);
		@ec=param('ec');
		@rc=param('rc');
		@pc=param('pc');
		@erc=param('erc');
		@et=param('et');
		$test=param('test');
		
		while ($j <= $num_forms)	{ 
	
			my $ecj=$ec[$j];
			my $rcj=$rc[$j];
			my $pcj=$pc[$j];
			my $ercj=$pc[$j];
			my $etj=$et[$j];


			if ($ecj)		{
				$k++;
				my $line=$ecj.",".$rcj.",".$pcj.",".$ercj.",".$etj."\n";
				print $recs $line;
			}
		$j++;
		}
		
		$recs->close;
		$forms->delete('submit');		
		print 	$forms->header,
			$forms->start_html(),
			$forms->startform(),
			$forms->p("$k records written"),
			$forms->delete('action'),
			$forms->p('<br><br>Click contnue to enter more records, close browser to exit<br>'),
			$forms->submit(-name=>'Continue',-value=>'enter'),
			$forms->hidden('action','enter'),
			$forms->hidden('num_forms',$num_forms),
			$forms->end_form,
			$forms->end_html();	
 }

The basis of the score subroutine as it currently exists is essentially the same as the logic at the end of the multirec.cgi script I discussed in a previous section ... the parameters corresponding to given fields on the forms are read into arrays, then written to a comma-delimited ascii file in a line that represents the record associated with any given event. It is at this point that the current extensions to the subroutine begin. First, the number of lines that are actually written are counted as the script traverses the loop that writes records. After the filehandle to that file is closed, the script deletes the action parameter and generates a page displaying the number of records written and prompting the user for input to continue. It is good to do this, the reinforcement it gives to users can substantially enhance their comfort level with the system. But let me tell you a little secret - don't let this out. This is not the real reason this page exists. It's all a trick to get the browser to send appropriate material to the server to get the script to generate a new entry page. Think about this a little and you'll see what I mean. We've written the records entered, but we need to start the script over again. We could spawn another process, calling the script with arguments identifying the client, the number of forms we want, and other key variables such as the address of the browser, and start directing output back to the browser. But then we'd have to complicate the logic at the beginning of the script, and we'd be adding an overall level of complexity to the script that would make the execution environment far less stable. In the next version of the script we will be running an external script to actually add the records we've written to the database, but that will be a far more simple script designed for a very specific task. By using this generated page to initiate a session between the browser and the server, we are using those two environments to do precisely what that they were written to do: handle the lower-level details of the conversation. This allows the script's logic to be clean and sparse. There will be times when you will be forced by circumstances to adopt a structure that embodies some degree of clunkiness. There is no point in compounding such problems by adding levels of complexity unnecessarily.