 |
|
|
|
Sablime Known Issues
|
Note that these are in no particular order. See the Known Issues Index for an organized list.
|
Email "from" address incorrect (comma in PTS name)
Many Sablime commands send email, and they set the "from" address of the email to the address found in the user's PTS record. Sablime uses the form Name<address>, where Name is the "Full Name" in the PTS record and address is the "Email Address" from the PTS record.
If the Name contains a comma, though (for example: "Riffle, Paul"), this causes the underlying sendmail utility to incorrectly mark the email as being from two users (for example, from "Riffle", and from "Paul<address>").
This problem will be fixed in Sablime version 6.1, Update 4.
Workarounds:
Remove commas from the "Full Name" field in the PTS record.
|
Source commands fail using SBCS and very large files
Sablime source commands (such as edget, sget, addsrc) may fail when using SBCS and when the file is very large. It has been observed that the file size Sablime can handle with SBCS as the version control tool is directly proportional to the amount of physical RAM on the machine, somewhere around 50%. That is, a file larger than 128MB is not safe to store in Sablime with SBCS on a machine with 256MB (or less) of RAM.
Workarounds:
Use SCCS to store the file if possible.
Increase the amount of RAM on the machine.
Run the source operations from an NFS client that has more RAM.
|
approve command fails with call_sccs message: bad p-file format(co17)
When there are an extraordinary number of deltas being approved
for a particular file, the Sablime approve
command may fail with a messages similar to the following:
+ Approving the specified MRs for the generic [1.0].
*SYS_ERR* Message Number [999] From: call_sccs.c [Version 13.1.1.2].
SCCS/SBCS command [get] failed, see DBA Warning file and
[/usr/tmp/call_sccs10762] file on host.
Please Notify Your Sablime System Administrator Immediately.
+ A Master Trace Record has been generated for the Database Administrator.
$ cat /usr/tmp/call_sccs10762
ERROR [/home/sablime/sdb/src/s.main.c]: bad p-file format (co17)
The "s." file mentioned in the error message is the system's master copy of the corresponding source file, including all the changes that have been applied.
The "p-file" is a lock file that the system constructs as it is trying to approve the MRs.
If the number of deltas is very large (it varies, but is somewhere over 100),
the system truncates the line in the p-file, resulting
in an improperly formatted p-file.
The utilities that perform these particluar operations are provided by the UNIX system vendor, so Sablime, unfortunately, can not fix this problem.
Workarounds:
To avoid the problem, you can approve MRs more frequently and limit
the amount of times one MR is used to update (edget/edput) a file.
Depending on the situation there are three workarounds that could be applied after you've encounted the problem. These involve trying to reduce the number of deltas being approved at one time for this file.
1) If you are approving multiple MRS and more than one touches the file in question:
If using Sablime v6.0 or later, run the mk_approve command to produce a script for approving the smallest subsets of depedent MRs.
If you are not yet on v6.0, you can attempt to manually find smaller subsets of MRs to approve without encountering dependency issues.
If that isn't successful, you may have to find the set of MRs that touch this file and use the "depend" command to eliminate their dependencies on other MRs in the set. Approve these MRs, and then restore the dependencies.
2) If it is only one MR that touches the file many times, use "unedput" to remove deltas from the file (save away the copy of the file that unedput initially delivers to you). Once you've removed a sufficient number of deltas (assuming they were sequential and didn't have other MR deltas intermixed), you can "edget" the file and "edput" the copy you saved from the first unedput. This should restore the contents to where it was, but with fewer deltas. Then you'll be able to approve the MR.
3) If neither of the above can resolve the problem you may have to sget and save a copy of the file and then remove it from the generic by using the "source" command. You can then re-addisrc or re-addgsrc it. You will lose the MR history within this generic if you use this method
|
|
