If the assignment doesn't allow you to use a module, you might start with dbmopen, which will let you tie a hash variable to a file, and then automatically update the file as you make changes to the hash:

#!/usr/bin/env perl
use 5.010; use strict; use warnings;

dbmopen(my %h, './database.dbm',0666) or die $!;  # open database file
$h{mykey} = 'my value';                           # save a key/value p
+air
dbmclose(%h);                                     # close database

dbmopen(my %i, './database.dbm',0666) or die $!;  # reopen database fi
+le
say "$_ : $i{$_}" for keys %i;                    # print key/value pa
+irs
dbmclose(%i);
[download]

When you're comfortable with that, look into tie, which is meant to supersede the dbm* routines and gives you a more flexible way to do the same sort of thing (I think there may be portability issues with dbmopen, which tie was created to alleviate). If you want a database file that's human-readable, you can use something like YAML or JSON on the backend, but those would require a lot of coding or a module.

aaron_baugher definitely gives you a good direction for research and experimentation with dbmopenand its family of routines.

If that makes sense to you, feel free to proceed with it and ask questions on anything.

If dbmopen is confusing you, or confusing to you, let us know. We can find a smaller fire hose to drink from.

I would also point out that backslashes are not used in HTML tags. You have a <\p> instead of a </p> in your most recent post.

Summary

Here are some extremely simplified examples of the basic techniques which would reliably convert a hash to and from a file under relatively reasonable constraints.

As you requested in private chat, I've avoided the use of modules and deprecated functionality (such as dbmopen).

Please note that this is not product-grade code -- reading and writing individual records from a data file is a much more efficient use of CPU, memory, and other runtime resources than this slurp/process/spew approach.

The Slurp/Spew approach simply makes it easier to demonstrate the underlying techniques.

Design

In this example, the design is simplistic:

• Every employee is presumed to have a unique employee ID
• The employee ID is the primary key for this data
• The data is presumed to have no tab characters in it
• The data is presumed to be only text -- no binary data
• The processing sequence is presumed to be:
  1. The entire contents of the data file are loaded to the hash
  2. The data is processed/manipulated as needed
  3. The entire contents of the hash are written to the file, overwriting it

Code

So, without further adieu, a working sample, as requested:

hashfile1.pl:

And what code would be complete without a way to see what your data is actually doing (and yet avoiding the use of the otherwise most excellent Data::Dumpand Data::Dumpermodules):

hashlist1.pl: