It could also be stored in a database (which is in a way just another way of storing it in the file system). I sort of hate to say that, because I am often getting a bit angry when I see other monks suggesting a database approach for cases where I think it would not work properly (for example, database access is often 2 to 3 (or more) orders of magnitude slower than hashes, so that suggestion to use databases instead of hashes are often ill-advised IMHO), but, here, this is something completely different, it is just a matter of making one single piece of data available to a program.

As for environment variables, yes, it would probably not work if the Perl program environment is abandoned, but there might be some ways of doing thing where you could keep the current environment, for example if the next instance of the script is launched by the last one (with a proper delay, sleep time, or some other way to control launch time).

This may seem not very robust, but we are using something like that on a group of 7 VMS platforms. VMS does not have a cron tab, but has a queue system on which you can submit a job on a given future date. We have a crucial daily process to update our replicated databases with the production data every night. The process does the required update work and then submits the next execution for the next day, passing appropriate parameters. This actually works fairly well. We just need not to forget to update the whole shebang when we fiddle with the process or when a reboot occurs.

Our use case is quite different from the OP's, but it might still be the idea of a possible solution.