The Absolute Beginners Guide to OPL

Part 12 - Preserving for posterity

---

Several people have asked whether it's possible to store each set of generated numbers for posterity. Although you might think that this is a bit pointless as they're all just random numbers, it's still a nice idea as it not only gives us a chance to do some more database programming but also paves the way for functions to analyse the randomness of the numbers and, ultimately, to save to disk actual lottery number sets from the real thing on television.

The most sensible place to do the saving-to-disk is within the generate: procedure itself. Find it in your code and insert the following just before the RETURN command:

     REM Save the generated numbers to an archive file for posterity
     IF EXIST("archive.dat")=0
       CREATE "archive.dat",A,num1%,num2%,num3%,num4%,num5%,num6%
     ELSE
       OPEN "archive.dat",A,num1%,num2%,num3%,num4%,num5%,num6%
     ENDIF
     A.num1%=numbers%(1)
     A.num2%=numbers%(2)
     A.num3%=numbers%(3)
     A.num4%=numbers%(4)
     A.num5%=numbers%(5)
     A.num6%=numbers%(6)
     APPEND
     CLOSE

Note the way we check whether the archive file exists before deciding whether to CREATE it or just OPEN it. As we saw when creating the settings file, the database is opened with a list of the variable types that the program expects to find in each entry. I've defined our archive file format to simply have all six integer numbers stored in the same entry. Subsequent entries then get APPENDed to the file, six numbers at a time, gradually building up a complete record of all the numbers ever chosen:

Note how we manually set each part of the database entry equal to its corresponding numbers%() array element. It's tempting to think "I wonder how we could do that using a loop of some kind?" but I know of no quicker way than that shown. If our array had dozens of elements, the code would get very tiresome, and we'd probably end up storing the numbers some other way to get round the problem.

Although we're not going to re-open the archive for analysis right now, it's something that would be easy to do in the future. For now, just translate and run the program and verify that the "archive.dat" file gets properly created and added to. Series 5 owners will find the file in their internal disk's 'root' folder and Series 3 owners will find it in \OPD, also on the internal disk. You can use the system screen functions to ask the Psion the exact file size of the new file. Note the number of bytes and then generate some more sets of numbers. Go back to the system screen and look at the file size again. Hopefully it will have grown, to reflect the extra information added to it!

Those of you with an eye for efficiency may have noted the fact that I keep writing the filenames used by MiLo out in full each time. There is of course a better way to do this, by making a new string variable to hold the desired name. This has the benefit that if we ever need to change the name later on, we can simply alter it in one place and the job's done!

Go back up a few lines and change each reference to "archive.dat" to archive$ instead, as shown:

... and then go right up to the top of the code to make a couple of new global variables, one for each filename that we want to use later on:

    GLOBAL archive$(128),setting$(128) rem filenames used

    archive$="archive.dat"
    setting$="milo.ini"

Note that I've defined each string variable (i.e. sequence of letters) to be up to 128 characters long. While this might seem a little extreme, there are several functions we may use later on which require filenames to be defined to this size. After all, on some systems, a file might be located at "LOC::M:\MYFILE\DOCUMENTS\HEADERS\MILO\MILO.INI" or whatever, and it's best to allow for the worst case scenario! 8-)

Stop press: Series 5 users should perhaps use 255 instead, as dFILE and other commands expect this longer length. Not important for now, but bear it in mind.... 8-)

Finally, go through the program code replacing "milo.ini" with setting$:

Once done, translate and run and check that everything still works! If your code has got out of sync with mine, the full program is available here as milo12.txt.

In general, this is a very useful technique to remember. Wherever you use specific filenames in a program, always define them at the start of a program, where they're easy to locate and change. In fact, the same applies to frequently-used numbers as well, but we'll come to that next week!

See you then!