 |
|
|
|
Sablime FAQ
|
Note that these are in no particular order. See the FAQ index for an organized list of the FAQs.
|
How can I limit access to fcreate ?
If you don't want anyone to use fcreate, you can simply make the command non-executable. Go to the command bin on the host and, while logged in as the administ
rator, type
chmod -x fcreate
This will prevent anyone from executing fcreate. On the host, users who type fcreate will get a message saying "not found" or similar, users selecting
fcreate from Web Sablime will get an error message saying "Cannot execute" (or
similar).
If you want to limit the generics in which fcreate can be used, do the following
while logged into the host as the database administrator: -
Use the setgroup command to create a group named, for example, "_FCGENS" contain
ing the generic names where you want fcreate to be usable.
-
Use the ftd command to modify the fcreate command screen: type "ftd"; select the
"modify" Function; the "fcreate" Command; Internal Key "g". Change the "Field
Type" to 2 (if it isn't already); Change the "Popup Selections" to "1" (or more)
; and finally, Change the "Group/File" to _FCGENS.
This will cause only the generics listed in "_FCGENS" to be selectable by the users.
|
Can I convert SBCS files to SCCS ?
Yes, these files can be converted.
(If you're not concerned with preserving the file change history, you can just use the source command to remove the file, and then use addsrc to add it back as SCCS).
If you do want to preserve the file change history, and if you are sure the file(s) are not binary according the Sablime's criteria (more than 1021 characters on any line; octal 1 - Control-A - as the first character of any line) and ends in a newline, then the conversion is straightforward.
You'll be converting many records related to each file, you should consider making a complete backup of the databases in case something goes wrong. The backup below is not strictly necessary, of course, but is recommended.
- Login as the database admin
- Run the dbstop command to stop the Sablime database.
- Backup the complete directory structure under adb/product, sdb/product and idb/product directories if you can.
- For each file you wish to convert:
a) Go to the source file sdb sub-directory that contains this file's "s." file. For example /home/sablime/databases/sdb/product/dir where dir is the file's relative directory as listed in its GS record (ssql dir from GS where sfile.eq.file_name).
b) In this directory, run the command nadmin -dx s.file_name This will remove the "binary" flag (if it is set).
c) After this run sab2sccs command: sab2sccs dir=dir srf=file_name
- Start the database with dbstart command.
If things work as expected you can delete the backups.
|
How can I find out what files are common between two generics ?
The ssql command on the host will do this for you.
ssql sfile dir common from GS where common.lk.generic1 and common.lk.generic2
The above query will report all files that are common to "generic1" and "generic2"
|
How can I restore a file that was removed from Sablime ?
Assuming the file was removed from Sablime using Sablime's "source" command either directly or through the Eclipse IDE, then Sablime will have created a recovery file in case the removal was a mistake.
The process to restore a file is detailed in the Sablime Usage Guide. See the entry for "Restoring a Deleted File"
|
How can I approve a large number of MRs ?
An MR can only be approved if the MRs it depends on are also approved. Discovering these dependencies by trial and error can be frustrating and time-consuming.
Sablime supplies the mk_approve utility which can generate the commands for approving the smallest subsets of MRs that can be approved at once.
Not only does this make the search for dependencies less of a problem, approving MRs in their smallest subsets results in fewer database records (and thus a smaller, more efficient database).
Usage of the mk_approve utility is described in the Sablime Usage Guide. See the entry for "Approving an MR" (mk_approve usage is described on that same page).
Note: approving many MRs is a database intensive task that should be done on the host itself, and with as little other database activity as is practical. Approvals (especially large sets) should not be done concurrently.
|
Can I kill an MR after it's been assigned ?
Yes. With the introduction of the unaccept command a few releases ago, you can now back an MR from any state short of approved all the way back to the created state. From there you can use killmr to kill it.
The only exception is an MR that has been used to spawn other MRs.
To kill an advanced state MR, first reject it back to assigned if necessary. Then, if it hasn't touched any files, use unassign to return it to accepted. If it has touched files, use unedput to undo the edits first. You'll need to do this for any generic(s) that the MR has been accepted into. Then unaccept the MR from each of these generics, and the MR state should change to "created".
Then you can kill it.
|
How can I move a Sablime database to a different machine ?
- You will need a new license file for the new machine. Contact the Customer support team at software@lucent.com for the license transfer form and instructions.
- Turn off the databases, using "dbstop", so that you are working with an unchanging database. If you have more than one product in the Sablime instance you're moving, run the Sablime setup script for a generic in each product, and run "dbstop" for each of the products.
- We recommend you run the audit programs, especially if you are moving to a different architecture or upgrading your release of Sablime.
- If you are staying on the same host architecture and same release of Sablime, you can simply move the Sablime binaries to the new machine. Otherwise download the appropriate binary set from the Sablime web site and install it onto the new machine.
An example of moving the "binaries" follows. It assumes you've made the appropriate modifications to the ".rhosts" file on the new host to allow access from the old host.
cd $sabLCB # location of the bin directory on the old machine
find . -print | cpio -ocB | rsh new_machine \
"(cd new_machine_$sabLCB; cpio -icBdum)"
(Note that some machines use "remsh" rather than "rsh". Some machines prefer different combinations of the "B" and "c" options to cpio.)
- Install your new license file (as ".usrid") into the new machine's bin directory.
- Move your databases to the new machine. An example of doing this follows. It assumes that the databases are located in the same parent directory, and that you've made the appropriate modifications to the ".rhosts" file on the new host to allow access from the old host.
cd $sabBASE # location of directory containing the databases
find adb idb sdb gdb -print | cpio -ocB | rsh new_machine \
"(cd new_machine_$sabBASE; cpio -icBdum)"
There are, of course, other ways to move the files. If the databases are on a fileserver, you may not have to move them at all. Simply change the mount point to the new_$sabBASE if it is different.
-
Log into the new machine as the Database Owner, and in the "Global Database" (gdb) PR subdirectory, modify each file to reflect the new host name, bin, and database directories. These are the 4th through 8th fields of each record. (Use ssql -help from PR to see the field layout of the PR files).
-
Update your "sablime.sh", and "xsablime.sh" files in your bin directory, as necessary to reflect the changed host, bin and database locations. Also update the "sabVAR" file that the (x)sablime.sh file references, so that it contains updated paths.
Run sh2x to regenerate your "sablime" and "xsablime" scripts
sh2x sablime.sh sablime
sh2x xsablime.sh xsablime
-
If you are using the External MR communications package, you will need to update the locations of the executables and the GDB in your ".EMR" and ".BIN" files.
-
Run the "setperm" script to verify/update the permissions of the Sablime files.
-
Execute ". sablime <generic>" and verify that commands work.
-
Restart the databases on the new host, using "dbstart".
|
How can I move a Sablime database to a different location (same machine) ?
- Turn off the databases, using "dbstop", so that you are working with an unchanging database. If you have more than one product in the Sablime instance you're moving, run the Sablime setup script for a generic in each product, and run "dbstop" for each of the products.
- We recommend you run the audit programs so you can be sure whether problems were introduced by the move or were already in place.
- Move your databases to the new locations. An example of doing this follows. It assumes that both the old and new locations have the four databases located in one parent directory.
mkdir new_sablime_db_dir # if necessary
cd old_sablime_db_dir # location of existing database directory
find adb idb sdb gdb -print | cpio -pdumv new_sablime_db_dir
-
Go to the new Global Database (gdb) PR subdirectory, and modify each file to reflect the new database directories. These are the 6th, 7th, and 8th fields of each "product" record. (Use ssql -help from PR to see the field layout of the PR files).
-
Update your "sablime.sh" and "xsablime.sh" files as necessary to reflect the new database locations (in particular the new GDB location).
Also update the "sabVAR" file(s) that the (x)sablime.sh file references, so that they contain updated paths.
Run sh2x, if necessary, to regenerate your "sablime" and "xsablime" scripts
sh2x sablime.sh sablime
sh2x xsablime.sh xsablime
-
If you have "triggers" (in the $sabLCB "hooks" subdirectory), you'll want to check them also to see if they need updating.
-
Setup and restart at least one product, by running ". sablime some_generic, and then running dbstart. Verify that commands launch properly. Restart the remaining products.
-
If you are using the External MR communications package, you will need to update the ".EMR" file in your Sablime bin with the correct location of the GDB.
|
|
