Nokia Networks Home

Sablime® Help Desk Resolutions & Workarounds

Note that these are in no particular order. See the Help Desk Resolutions & Workarounds Index for an organized list.

  • Documented source restore script doesn't work

    The file restoral shell actions on the Usage Guide page for “Restoring a Deleted File” as distributed with the v8.0 and v8.0u1 releases did not restore the generic-specific records to generic-specific subdirectories of the relations. Use the updated script on Sablime's web site version of the page.

  • (mra_)deferred MRs don't re-activate when they reach their activation date

    The documentation says that nothing happens when a deferred MR reaches its activation date. Still, it seems reasonable to want some automatic activation or notification.

    This script will re-activate mra_deferred MRs that have reached their activation date:
          # Script to activate mra_deferred MRs that have reached
          # their activation date
          TODAY=116 761 214 762 116date '+%m/%d/%y')
          for MR in $( ssql mr from MRX where$TODAY and mr.eq. 
          { ssql mr from MR where stat.eq.mra_deferred } 2>/dev/null )
    	      activate mr=$MR prompt=n
    A variation of this could activate MRs deferred within generics:
          # Script to activate deferred MRs (within specific generics) that have
          # reached their activation date
          TODAY=$(date '+%m/%d/%y')
          for G in myg1 myg2 myg3
             for MR in $( ssql mr from MG where mrgstat.eq.deferred and 
                g.eq.$G and$TODAY 2>/dev/null )
    	        activate mr=$MR g=$G prompt=n
    You could put a these scripts in a cron table so they run automatically, or just run them when you feel it is time it re-evaluate your deferred MR set.

    You could also change the scripts so they notify you of such MRs rather than actually activating them:
    /dev/null > $TMPFILE
          [[ -s $TMPFILE ]] && print "
          These mra_deferred MRs have passed their activation date:
          $(for MR in $(< $TMPFILE)
                ssql mr abst from MR where mr.eq.$MR 2>/dev/null
          " | /bin/mail $ME
          rm $TMPFILE

  • Firefox doesn't display certain messages on status bar.

    Some Sablime commands use the "status bar" to report minor warnings or other incidental information to the user. The Firefox browser - by default - doesn't let "javascript" (the language used by many Sablime commands) display messages to the status bar.

    You have to specifically enable the capability on Firefox:
    Go to "Tools->Options...", then the "Content" panel, and click the "Advanced" button near the "Enable JavaScript" checkbox.
    On the resulting "Advanced Javascript Settings" window, check "Change status bar text". Then "OK", "OK".
    Javascript will now be able to write to the status bar.

  • Commands fail with message: Lockit can't create lockfile after [10] tries

    Sablime commands that update the database use a lockfile mechanism so that two commands can't update the same file at the same time.
    These lockfiles exist for a very short period of time, usually. Sablime creates them, and then removes them when it is done. An extraordinary event such as a system or network failure, or sometimes even a command interruption, can prevent Sablime from removing the lock file, causing other commands that try to update that particular database file to fail, and report an error message:
         *SYS_ERR* Message Number [999] From:  LockIt.c [Version].
         Lockit can't create lockfile after [10] tries.
         Please Notify Your Sablime System Administrator Immediately.
    Look in the DBA Warning file at $sabGDB/tmp/product_dbawarn.
    The "can't create lockfile" error message will also be recorded in this file, and it will mention the specific file that caused the problem, for example:
    04/26/05 17:36:02 [pmr] approve  @(#) LockIt.c [Version] - dba_msg: Loc
    kit can't create lockfile [/home/sabprod/databases/adb/sab/DBLOCK/MD/mg] after [
    10] tries.
    Locate that lockfile (in the above example, it is /home/sabprod/databases/adb/sab/DBLOCK/MD/mg). If the file is more than a few minutes old, it is extremely unlikely to be associated with a currently running command.
    Remove the file ("mg" in the above example).

  • Edget fails with message: You are not a owner of file

    In this case, apparently, the file has an owner, and it is not you.
    Normally, files do not have owners, but if someone needs to have tighter control over changes to a file, they can declare an owner. Only the owner of a file may change it.

    You can see who the owner is by typing:
    $ ssql sfile dir owner from GS where sfile.eq.filename and g.eq.generic
    This will display the name, directory, and owner of each file that has that filename. To remove or change the owner of a file, use the "source" command on the host.

    See the "File Ownership" page of the Usage Guide (Sablime Documentation) for more information.

  • Eclipse displays empty "Directory on Server" Box

    After selecting "File->Import..."; and then "Sablime Project"; then entering the URL, User Name, and Password; entering a proper Product Name, Generic, and MR number; and selecting "Get Files From: Directory in Sablime"; the next page shows a "Directory on Server" box that's empty.
    Checking on the regular Web Sablime interface, using the "Browse Files" function and selecting that same server, product, and generic, it is apparent that there are directories defined for that generic.
    (The same problem is seen when approaching this page starting at "Team->Share Project")

    The problem here is that there is one or more blank lines in the "Directory Structure" file on the Sablime server.
    Edit the file on your server (at $sabGDB/DIR/<generic_name>) and remove the blank line(s).

  • Query returns empty or bad results - even though DB is known to be correct.

    A customer reports that the command "query relation=MG mrgstat=nochange prompt=n" returns no MRs, even though there are MRs known to be in the nochange state.
    The problem was that the customer had a group named "nochange" in his database. The query command expanded the contents of that group as the argument for the "mrgstat=" option. Renaming the group to some non-keyword name resolved the problem.

  • Web getversion creates @LongLink files on the web client.

    Web getversion on the host uses either the "jar" or the "tar" program to package the set of files it sends to the web client. It prefers the more efficient "jar" but will use "tar" if it cannot find "jar".

    Some implementations of "tar" create these "@LongLink" files when the actual file name is too long for it to handle (> 100 chars). The "@LongLink" file contains the real file name. This method requires that the version of "tar" runningon the receiving machine understand how to handle these as well, otherwise the "@LongLink" files remain.
    Ensure that Sablime's getversion finds a "jar" command to use, by creating a symbolic link in host Sablime bin to the location of "jar":
       $ cd $sabLCB
       $ ln -s /usr/bin/jar