DesignBais Tip – Housekeeping

DesignBais requires very little maintenance but here are a couple pointers.

The DBIXMLLOG file tends to get very large if logging is turned on, and periodically needs to be cleared. Logging is enabled on a per-user basis from the Users maintenance form. In each DesignBais-enabled account, Clear-File on this file at some periodic interval, perhaps with a phantom scheduled to wake up once per day when there are no users. Another way to quickly clear the log for the "current" account is to use the Clear XML Log button in the Actve Users form.

The DBISESSIONS file in pre-v4 releases also accumulates data and can be cleared when there is no user activity. Do not clear this file if there is any chance that a user will want to resume a login session afterward. That is, you must really be sure no one is even sitting on a page waiting to continue data entry. One way to clear the file is to go to the Active Users form and click Clear Sessions. This eliminates most but not all items in the file. A clear-file as part of the periodic housekeeping process will keep the file clean.

For D3 sites (and other DBMS platforms that use mv.NET in v4 or above), mv.NET creates temporary files which also need to be cleaned up occasionally. These files are named MVNET.TMP_x where x is a number starting with ‘1’. Periodically execute this command at TCL: MVNET.HOUSEKEEPALL You are prompted to do a complete housekeep or to just delete temp files. Enter ‘FILES’ to just delete the temp files. The verb and response can also be added to the periodic housekeeping phantom or similar application process. mv.NET includes excellent housekeeping routines of its own, but these are only invoked when using a pooled connection that is always logged-in. DesignBais manages its own pooling of Dedicated Connections through non-pooled mv.NET sessions. So, without its own dedicated connection, mv.NET doesn’t know when it can or should handle its own housekeeping, so this needs to be done manually.

DesignBais v4 has enhancements which may eliminate a couple of these housekeeping issues. I’ll update this article in a few weeks and ensure that the v3 and v4 differences are clear.

Menus allow a program to be execute from this field: "Subroutine to invoke before screen". See the DesignBais Manual for details. This is a good place to put common routines that clear up your own work files. Be careful to not "weigh down" the user interface though – you don’t want any one user to wait to get to a form while the server is busy trying to delete some massive file that isn’t properly sized. It may be best for the program specified in this field to check to see if there is a housekeeping phantom running, and if not, spawn the process, but major housekeeping should not be done by user processes. See the other related field for Menus, "Subroutine on Main form Close (‘X’ button)" — you can be fairly certain a number of your users will just kill forms to exit them, rather than using a Close button. Don’t rely on this code getting executed however – users often find creative ways to exit applications without the server knowing they’re gone.

One type of housekeeping function is making sure that your users are still active and not consuming licenses while they’re "out to lunch". One way to monitor user activity is to use the DBTIMER feature:

  • In your AFTER DISPLAY event, save the current date and time (perhaps form name or other data) in a DBSTORE or DBWORK value.
  • When users enter your event handlers, update this timestamp so you know the last time the user had some "real activity".
  • In your AFTER DISPLAY event, check to see if there is a timestamp already in place. If not, use DBTIMER=30000 or some similar value to set the timer. The DBTIMER uses AFTER DISPLAY as its event, so if there is already a timestamp, then the form has fired off this timing event.
  • Check the current time with the last timestamp. If some significant amount of time has gone by without any activity then the user may have gone away for a while. You can popup a form (with its own timer) to give the user the opportunity to confirm they’re actually still at the keyboard. If the user doesn’t respond you can close their appliction form, redirect them to a login page via PROCESS.STACK, perform some wrapup housekeeping, and take other actions.
  • Of course more infrastructures is required around this to ensure that you don’t terminate a user session prematurely. For example, they might simply be working on another screen, and you don’t want to close pages on them or interrupt their other work. In this case, DBSTORE is inadequate and you may need to read/write your own user state data whenever the user fires certain types of events. Put some thought into it and consider exactly how you expect users will be using the software. No doubt you’ll be surprised by how they are actually using it.

If you have your own housekeeping tips to keep the DesignBais runtime or development environment "clean", please post a comment!

The article GUI for MV Developers turned out to be much larger than I expected. It will take another week to cut it back a little. Please come back next week for that article.

I have another DesignBais Tip that’s done and just needs a little fine tuning, called Dynamic Color and Images. I think you’ll like it. I’ve made use of techniques already covered here to demonstrate some interesting new visual effects. Based on recent inqiuries in the DesignBais forum I’m also putting together an article on effective ways to dynamically customize your On Form Report headers, visual aspects of cells, etc. In the coming weeks I’ll also start writing about the new Version 4.0 enhancements and fixes… Stay tuned !

4 thoughts on “DesignBais Tip – Housekeeping

    • Hi Tony – one other file (or set of records actually) to keep an eye on, if you have logging turned on, is _PH_ or &PH& depending on Database. An entry is placed in there that shows all output from the backend Designbais processes, and it can get quitle large. The id is O_username.1

    • Thanks Symeon, missed that. Now that I look I don’t have any items in there, but I usually don’t use COMO either. If I’m not mistaken, the only items we’d be concerned about are the "O_" items. Please let me know if I miss other U2-specific details.

      Since we’re here, in D3 once in a while I see lists in the pointer-file too but they don’t usually accumulate. Sample ID’s:
      The second field is the internal date, so you know when the items are old.

      I will update this article after v4 is out, and also when I get more details about how DesignBais works with jBASE, OpenInsight, OpenQM, Reality, and whatever other platforms they support.

    • Tony,
      Not sure if Symeon’s post just relates to UniData, but in UniVerse the COMOs appear in &COMO& and don’t have the O_ prefix just "username.1".

    • I really need an edumakashen with COMO. And I also need to find out exactly what DesignBais does with &COMO&, _PH_, and &PH& on each platform. I foresee an update to this in about a month.

      Another D3 pointer that I missed… Here is one of my own quotes from CDP:
      I’ve had recent experience with apps that have so many errors during the course of the business day that the RUNTIME-ERRORS file itself gets very fragmented, and every update results in delays as the system chases frames into overflow. Identify your errors, fix them, then delete the file. If you suspect more errors, recreate the file with a mod of something like 101 and wait for more errors to get logged.

      The experience mentioned was with a DesignBais site: v3.3 has some Variable Not Assigned and other errors that are emitted from BAWEBEXEC at runtime. These errors don’t mess up normal data exchanges but DBI is cleaning them up for v4 anyway. If the runtime-errors file exists in dm, normal DB usage will start to have an impact on this file.

      And yet another pointer on performance: mv.NET uses a feature called Character Conversion to ensure that 8-bit data is transmitted reliably between clients and their 7-bit DBMS hosts. For NT systems it’s "probably " OK if no character conversion is done, so all transmissions are in 7-bit. For *nix systems there is usually full conversion. This soft conversion process can have a moderate impact on performance: every character needs to be checked to see if it’s an 8-bit char that needs to be split into two 7-bit chunks. Turning on character conversion is often necessary, but if you don’t need it, absolutely turn it off.

Leave a Reply