Expiry Dates – DIY Solution

With the article on Expiry Date two weeks ago, there were some internal discussions around wether we should provide some automation within Genero to provide reminders that maintenance dates are about to expire.  This is always an interesting topic because factors are …

• If you automate an email what configuration is required?  What if there is no mail server?
• Do you provide the warning so that an end-user can see it?  If not how is the sysadmin defined?
• if it is to an end-user do you provide them with a checkbox so the user can acknowledge they have seen it and not be bombarded with the same warning repeatedly?  Where do you store the result of this checkbox click?
• What do you do with Web Services where there is no UI?
• How much warning do you give?  If it is one or two days what if that day is a weekend or holiday?
• Is the warning the same for temporary license, stop dates for evaluation licenses, and subscription licenses?
• Do you provide a warning for maintenance expiry? or only if GRW used?

At the moment, if you are using Genero Report Writer under the DVM Maintenance provision, if the expiry date is exceeded by 60 days the following is output on page 1 of your reports (see entry here). …

ERROR(-33015) : Please contact your sales office regarding licensing.

… this is not a popular design decision when external documents go out with this message!   (If you do not want to see this message, purchase a seperate Genero Report Writer license or make sure your licenses are always updated.)

During these discussions, there was an epiphany where it was observed that Genero has the tools where you can execute fglWrt and read the output of fglWrt, parse it for the maintenance expiry date or subscription expiry date or stop date, and then take whatever action YOU want from within your Genero application.

This first example simply reads what fglWrt -a info license outputs to stdout and parses to find the end of maintenance date.

FUNCTION get_maintenance_expiry_date() RETURNS DATE
DEFINE ch base.Channel
DEFINE line STRING

    LET ch = base.Channel.create()
    CALL ch.openPipe("fglWrt -a info license","u")
    WHILE TRUE
        LET line = ch.readLine()
        IF ch.isEof() THEN
            RETURN NULL
        END IF
        -- Change this next line as appropriate if subscription license etc
        IF line MATCHES "End of maintenance date*" THEN
            RETURN MDY(line.subString(31,32), line.subString(34,35),line.subString(26,29))
        END IF
    END WHILE
    RETURN NULL
END FUNCTION

Newer versions of fglWrt have a --batch argument that outputs a JSON string that is then parseable  …

FUNCTION get_maintenance_expiry_date_batch() RETURNS DATE
DEFINE ch base.Channel
DEFINE rec RECORD
    maintenance_date DATE ATTRIBUTES(json_name="maintenance-date")
END RECORD

    LET ch = base.Channel.create()
    CALL ch.openPipe("fglWrt --batch action=license-info","u")
    TRY
        CALL util.Json.parse(ch.readLine(), rec)
        RETURN rec.maintenance_date
    CATCH
        RETURN NULL
    END TRY
END FUNCTION

This second technique I think would be the preferable technique if –batch is available in your version of fglWrt.  (FLM version 6)

Interesting code in this technique involves the use of util.JSON.parse to parse a JSON string and the use of json_name attribute on the record definition that means when the parse occurs, the JSON object with name “maintenance-date” will be parsed into the “maintenance_date” record member.  The use of – not being permitted in 4gl identifiers.

The –batch arguments are a recent addition to fglWrt which perform tasks and retrieve information in formats suitable for use in scripts, cron jobs etc.  If you have not already, compare the output of fglWrt -a info license and fglWrt --batch action=license-info, and explore the other –batch arguments.

The key thing is you have the ability via a running Genero program to find the date at which your Genero applications may stop and to provide a warning before it happens.  Where and how often in your Genero application(s), you make this call, and how you then do the notification is upto you.

If it was me, I’d consider adding the call into my main menu application that most users would start once a day and either send the sysadmin a notification just like I might if an application crashed, or perhaps I would add a warning on my screen somewhere so that the end-user would then notify the sysadmin.  I might also consider a cron job or similar that runs once a day that calls a small Genero application that contains just this call.