The first line looks up the value in field doc.subject(0) in the array printerprofdoc.printer_name and returns the subscript value where it was found, or Null if not. I can then use that returned value to look up the corresponding location and site names in the profile. Simple, and neat.

Date formatting
PL/1, and for that matter IMS, didn't have the concept of a date field; we had to do actions on dates either as strings, or as numbers. And while DB2 has date fields, the external representation of them was in string variables--languages such as PL/1 didn't have date-type variables. We created some neat solutions for dealing with dates as strings and numbers and manipulating them in various ways to reformat them. We also had solutions to do date arithmetic, such as the difference between two dates.

Now that we have the concept of date field types in Notes and in LotusScript, we don't often have to do the sorts of manipulations that we had to do because the language constructions do them for us, and they make sure that the result is still a valid date. But all is not sweetness and light, because instead, we have the issue of dealing with the fact that when a Notes date value is created in LotusScript, the actual date that gets created depends on the date format that the machine's operating system is running with. For those of us in Europe, this matters.

Consider the date 01/02/2003. To Americans, it's January 2. To Europeans, it's February 1.

Now consider the code:

If the machine that runs this is running U.S. date format, then NotesDate will have the value January 1. If the format is European, it will be February 2. But if you offer it 21/01/2003, it will correctly parse it as 21 January, because that is the only value that can be parsed from 21/01/2003. So why does this matter, supposing you know what the machine's date format is?

It matters a bit if you run the code on a server, especially on NT4. This is because NT4 sporadically, all by itself, changes the date format to U.S., if running in European format. It doesn't tell you it's done it, but you can see it in the log, where the date format can change in the middle of a log segment. And I've seen this happen on AIX servers, as well. Go look at Knowledgebase entry 182329 for an example of this on NT.

If the code runs on workstations, this is a big issue, because workstations are controlled by users, who are capable of anything. And, of course, while your server is in Europe, your user may be in the U.S. and legitimately be using a U.S. date format.

So you can't rely on dim NotesDate as new notesdatetime("01/02/2003"), even if you make up the string yourself by breaking a date up and reassembling it, because even when you know which is month and which is day, Notes might not agree with you.

But there is a simple trick that works every time. This is to break the date string you have up into the Day, Month, and Year parts and make a Variant out of it with DateNumber: