The suggestions are grouped by subject. Of course the grouping is imprecise, but it is just a way to break the suggestions into some manageably sized groups.

The suggestions are presented here without comment, so you can review what others have to say about Sablime. If you'd like to see the Sablime® Team's responses, follow this link.

General Commentary

The unix version is good as it is.

I've worked with Sablime® since v1. Everywhere I go, I tell companies looking for a CM solution that Sablime® is still "the most bang for the buck" in CM tools. The only tools I've ever used that were better are ECMS and TrueChange...however both products suffered from a lack of support and vision and thus died (or are dying).

I also administer several Clear Case databases with CCMS which seems to be the way to go. I hated the unbelievable tangle of MR dependencies associated with Sablime® (no way to get thru the maze to approvals). Other than that, it was a good system for sequential development.

I would say that the biggest problem with Sablime® for our project is that it has been clobbered by the SunOS4.x. to Solaris2.5 to Solaris 2.6 to Solaris 2.7 migration. The database locking is not reliable on multiprocessor Sparcs (UltraII and Ultra60). Luckily, corruption of the ASCII tuples is typically easy to remedy. If we has SCCS, or heaven forbid, SBCS corruption, as often as we have had adb problems, we would dump Sablime® immediately.
Lucent ME CIO is not particularly familiar with Sablime. However, I can't understand how anything they've done could cause the problems we've seen since moving to Solaris 2.6. We're running Sablime® v5.0, patchlevel 6.
I think the industry lacks a good platform-independent build environment. The closest thing is Rational's Clear-Case. Nmake just doesn't cut it. Integration of building and source control is necessary. We use John Sobek's "pbt" builder with GNU make. It provides us with build logs that are a lifesaver for ISO 9000 and also for quickly identifying if a particular source file version was present in a particular fielded product. The way getversion mangles SCCS SIDs, they are completely useless for tracking.
We plan to migrate to 5.2 and try Web Sablime. We never even tried the Windows or X GUIs. The Web (or perhaps Java) is definitely the way to go for GUIs. They must be platform independent. As for the added potential for data corruption with a distributed system, DATA INTEGRITY is definitely THE SINGLE MOST IMPORTANT THING we require from a software product management system. The rest is pointless if you can't be sure the data you check in will be there when you need it.

[Web Sablime] does not work well with PC long names and case sensitivity coming from a UNIX box. PC Sablime® is worse...

Sablime® loses out because it really can't compete in the Windows development environment. We have an embedded base of Unix + Windows applications. Sablime® works great for Unix but it is really awkward in Windows. If the Sablime® Windows Client was more robust and integrated with popular development applications like Microsoft Visual Studio then this would be the one source code control for Unix and Windows.

It works fine the way it is, I don't plan to add extra time for bells and whistles.

As an administrator of software procurement not usage, I'd like to see a permanent license key with a yearly renewal notice. This yearly install is not only cumbersome, but time consuming and expensive as IBM must do these yearly installs.
This goes double for C++ and nmake since I have [ big bucks ] of this SW in [ our location ].

I Love Sablime®, the development team is just wonderful. Without it development in Lucent would come to a stop.

I do plan to convert to 5.2 and I am planning on setting up the web.
I find the system easy to use and works well if it is used. Took awhile to get others to use it properly. Everyone is trying to circumvent the controls. Especially when editing the source. They seem to like to keep their own source change it then edit the source, replace it with theirs and put it back. This causes problems, especially if someone else had the code out. I have educated developers about the problems this causes and for the most part they use the system correctly. But when they are in a hurry, they revert back to their old style. But is is 95% better than it was. And like I say, if one uses the system correctly, it works fine.

We're a fairly small organization and Sablime® meets our needs pretty well. Although I'm not aware of every detail, the "big picture" of Sablime® feature releases isn't clear to me. We installed 5.x, but I don't really know what features that provides over the 4.x we were running. Given the question above, I do not know why we would want to run 5.1 or 5.2 vs. 5.0. To be honest, I'm not even sure what 5.x we're running or how to find out.

One of our projects elected to use MKS Source Integrity for their PC-based Java development. I'd like to know about the Web interface, we might have used that. But they like SI pretty well, because it integrates into their Java development environment. Perhaps the same could be done for Sablime®, but no one has done this.

I was vaguely aware of the Sablime® Web interface, but we don't have it running to my knowledge. This seems to be another case of lack of information/education from the Sablime® organization to ours. If you are implementing new features, I recommend you put more effort into educating your customers about them.

[after list of suggestions] That's all I have for now. I'd like to reserve the right to think about it and add some items to the list. Thank you very much for soliciting my input.

P.S. - You have my permission to add the above to a wall chart as well. Thanks.

Sablime® as it is currently meets our needs.

Product Direction

Having both graphic PC interface and X (unix) interface with all the commands available in unix command line interface (except DBA commands).

Allow concurrent development on the same file with merging functionality.

Remove KSH restriction.

A more graphical environment would be useful, color, graphics.

More command as "unedput, killmr, changmr, setgroup" in the graphic interface tools

Add functions to PC interface: nochange and kill MR

I would like to see improvements on the PC Sablime. Currently it doesn't allow administrative actions and there is no 'getversion' equivalent in the PC version.

Allow parallel development - may have architects working on changes and developers working on another enhancement they may want to test separately then merge changes together and test in test teams later.

Can all the command be made GUI in xsab and PC Sablime? Like getversion?

We have a number of projects, and we've been slowly figuring out how to manage them. It would be convenient if we could move MRs between Sablime® products. We've been forced into putting all our projects into separate generics within a single product. Otherwise we have to re-enter the MRs by hand if it applies to multiple generics.

Develop builder more.

I would like to see source code control and its overhead as an option that would be easy to not invoke if it is not being used as in my application. This causes several issues with audits with the current version.

We would like to see Sablime® in the form of X-Windows with a GUI front end.

The customer support for Sablime® could be stronger. Over the years, problems reported have not had a quick turnaround. The customer support operators seem to brush problems off as if they do not exist or are not important.

The version control piece of Sablime® is not competitive to other tools in the way of having the ability to have multiple versions of the same source code out for edit at the same time and merging changes once they are checked back in.

Make better use of information already in the variables/environment. Example: you know what files are out for edit using what MRs, but you always make the user tell you - if the user tells you incorrectly you give an error. So if the user gives you a file name to edput, you should be able to supply the MR number.

Go back and look at consistency issues. Example: some menus are manipulated based on emacs convention (i.e. control-p to back up a field), but some are manipulated based on vi convention (i.e. control-d to see menu items that can't be displayed on one screen).

Add some "interactive" ability. Example: if a user needs to edput files from more than one directory, rather than run an edput for one directory and then have to re-execute the edput command, ask if the user wants to run the same command again (it would be an extension of the current "confirm")

More easy to use.

I would really appreciate a better pricing structure. Sablime® costs more than nearly any other software package (either internally
or externally) than I have ever used or for which I approved funding. It is *way* too expensive. I think the Host cost of $3500 is too high and I think the per-user cost of $100 is extremely high, especially since not all registered users are actually using the product at the same time and many users (non-developers) are just occasional users. For example, our Production Services users only create MRs. Our Testers only create and stpass MRs. The Developers use most of the functionality (create/fcreate, edget, edput, submit, etc). It is painful to pay the same amount for users who use only a fraction of the functionality as for the
users who use Sablime® for true software change control.

Overall, I like the proposed changes in 5.2, although I have not had the chance to install it. I look forward to working in that version.

Customer Support, Documentation and Training

It would be nice to know who the Sablime® Administrators are if they are responsible for specific applications or are they a centralized resource for any application?
Although training is available, it would be good to know if there are specific time estimates to perform various Sablime® Admin activities (i.e., adding a new generic, updating a drop down list boxes, etc.)

..I just wish that when I need help in performing some type of job, there's someplace that I can go and have a step-by-step instructions rather than calling the helpline. Sometimes they do not respond promptly enough.

I would like to see real timely Technical support. I have had so many problems when calling about a problem in the past. Sometimes it was days before I got a call back, sometimes never and I had to call again. Sending email wasn't much better and I would have to resend the email again.

While the Tier 1 support can sometimes be lacking, your Tier 2 technicians are some of the most competent individuals with whom I have ever worked. Their knowledge and skill in both the application and OS is to be commended.

Administrative interaction with Lucent/Sablime® is highly efficient. Notices of updates are effectively and consistently distributed. The license renewal process is fast and almost completely bullet-proof. Lastly, the usage of surveys, such as this one, are a solid means of obtaining feedback. In every case, technologies -- ranging from HTML to email -- are used to the greatest effect.

Alerts and information regarding Y2K preparations were especially effective last year. I knew exactly what needed to be done well ahead of schedule thanks to diligent email and web reports.

Online tutorials to complement the documentation. The documentation has shown a marked improvement under 5.2. (I especially like the Adobe soft-copy availability.) However, there are no tools/CBTs to provide at least a rough overview of the user and admin aspects of the system. While CBTs are no substitute for classroom training, it would be helpful to have at least a pre-cursory overview.

Frontline support via an AUDIX/callback structure sometimes results in long delays. While I have never had an un-returned call, there were times when the interim delay intensified Production issues. Maybe it would be possible to allow a priority/database down line for Severity 1 issues. I do think the "honor system" of permitting the user to choose, as strange as it sounds, works. Several other software vendors use a similar structure.

New Feature suggestions

Is it truly impossible to delete a Generic? It seems like that should be such a simple task, but no one has been able to tell me how to accomplish it yet.

A "snapgen" command, to create a snapshot a generic, so that if it becomes necessary to restart work at that point a new generic can be created from the snapshot.

More support/recovery tools. While general interface input is available, tools for correcting corruption or database anomalies are in short supply. Too many support calls I've placed have ended up in tuple hacking sessions. There are little or no tools to address the issues that the audit's so effectively diagnose.

If there's any chance of an mr_merge, it would be fantastic. Better yet, is a "featuring like" capability like ECMS. It's actually better than merging changes with GUI oriented tools such as those in Clear Case.

...to see a version of a file in a specific editor.

A tool or command that [shows] changes made to a file from one generic to another.

Add possibility to easily have smart reports (without using ssql, without developing a supplementary layer)

Ability to back out MR from a generic (that has source code changes to it) (sometimes a developer starts a change but is then told to stop work on it and work on a higher priority, or a feature is delayed due to changing schedule or priority)

A friendly GUI (Web based) to extract MRs in a given generic, grouped by type, subphase, and severity. This would help us do some metrics.

A viewer into the source code database would be helpful to my developers in order to look at a version of a file. This would save the time of having to check out the file with an sget and then looking at it.

Automatic Tag Generation to Source Files.

Ability to specify our own versions, instead of Sablime® maintained version ids.

Scripts which save unix users to go through the curses interface always. Many projects which use Sablime®, have scripts like ai, eg, ep written in a shell scripting language to give fast access to Sablime. Why not STC itself provide it, so that every time some thing changes, we need not rewrite the scripts.

One thing I would like to see happen is some effort clean up of old SCCS files, Particularly the ones that are removed when using source command that seems to create a backup copy of s.files. After about 2 years these files are obsolete, and practically worthless.

Improvements to Existing Features

Having a mailing mechanism more efficient. The mail sender have to be always the developer who launches the related command; allowing to select the type of mail to send per ptsid according to its roles (because a ptsid who is MRA + GA receives too many mails).

Could the web Sablime® I/F be integrated into another http server like Apache?

Easier conversions. Correct conversion notes - exp "cat sabl52.tar.Z* | uncompress | tar xvof - vs. cat sabl52_tar.Z* | uncompress | tar xvof -"

Easier reports - the relations ships of "and"/"or" are confusing when trying to get reports - have to do report - save - do another report and combine using scripts.

Need better documentation on relationships of files, also I had originally taken the administration course over one year ago and these were not covered in the class. If something went wrong in the system and there was no way to clean it up using the system, one has to go into the files and change data in fields. Very dangerous. I learned by trial and error.

Enhance external communication between different products to make it more automatic without needing to launch several commands, or to write scripts to encapsulate the external communications.

Correct bugs in PC interface.

Improve ssql command to look like standard SQL. The most missing functionality is to retrieve data from several relations with only one ssql statement.

Suppress or enhance standard reports, which are useless with Sybil interface.

Allow to create MR without having a license (but nevertheless a PTSid) because a lot of persons have only to create MRs.

I would like to see improvements in documentation availability; in particular
1)Accessible User Guides on the web.
2)Basic screen help on UNIX Sablime® (e.g. helpful hints on screen navigation printed across the bottom of the screen). I would also like to know what buttons you enter to page up and down on those pop-up windows of valid values which appear when the cursor is on a given field).
3) Sablime® news (for instance, I know nothing about the Sablime® website mentioned earlier).

I would like to be able to undo mistakes without having to log off the systems while working on most of the screens.

Currently, it's very inconvenient to check-in or check-out files. One of the big problems is that the file name length is limited to 8 characters for the PC version. For the UNIX version, the interface is not user-friendly. You have to fill so many fields.

Documentation - Used to be easier to retrieve information before 5.0 manuals. I find it's not as easy and quite annoying.

When mail is sent to a developer (e.g. when you assign an MR), put the MR number in the subject.

A way to automatically get web (html) type code to ftp over to the web machine when the web site is not on a UNIX box.

More user defined fields in the create window.

Can we get source code in different directories at the same time?
Can we have dir shortcuts in GUI instead of changing dir so tediously?

Sablime® reports should be extracted better way - PC Sablime® reports mess up even if you ask for one MR - it gives the whole report for all the MRs.

When creating an MR, I would like the abstract to copy automatically into the detail description. Most of the time I copy the abstract by hand and then add something to it in the detail description.

It should allow for more friendly reports.

It should link to our metrics collection process in some way.

In the PC version, you can't resize or horizontally scroll the window that is big enough to see the file name you want to edput, get, etc.

Backtab through screens such as fcreate.

Error and help messages more legible.

I installed web Sablime® 2.0 some days ago. Since 1.0 was already installed and I didn't want to stop it, before 2.0 works successfully, I wanted to install 2.0 in other directories than 1.0, to keep it apart from 1.0. I think it will be easier to remove 1.0, if it is no more necessary. And it should be possible to use the same web server. But the implementation steps for 2.0 do not support such a action.

I'd like to see an easier way to retrieve previous file versions.

We have people who enter MRs with their PC and forget to put newlines in the descriptions. It would be nice if Sablime® would break the lines in report mode. Currently, we have a giant line that runs off the edge of the page and the MR description is unreadable.

Permit the pre-trigger mechanism to allow modifying command line values.

For pre/post triggers: don't limit the length of the output to 70 characters. My users usually need much more than 70 characters to understand the nature of the error. Also allow the hooks to produce output without interpreting it to be a failure of some sort. I may want to give my user some useful information even though it is not an error. Exit codes should be the only thing to differentiate success from failure. Of course, it would also be nice if the hook's stdout and stderr were mapped to the Sablime® command's stdout and stderr.

Please, please, please, provide more user defined fields. 5 is not enough. 10 or 15 perhaps. Also, it would be very, very useful if plenty of user defined fields were available for the following relations: GS, G, ADM, PR, PTS, FTD, CAS, SNAP.

Pre and post triggers for all of the test state commands.

Command permissions: It is both useful and annoying for the command permissions to have generic granularity. How about providing some way of the CP scheme to have product (and maybe even global) scope? In a similar manner, it would be useful for Sablime® groups to have global scope as well as product scope. My instance has 13 product databases and many groups are duplicated and must be maintained. It's an administrative pain.

Allow more than one file to be added when doing an xaddisrc screen.