I can't say I'm not disappointed I've not had a chance to try D2 due to there being no direct upgrade path from Webtop to D2. A new user interface just isn't something I've been able to convince management to pay for seeing as though they've already bought a user interface and feel like they are getting charged twice for something that should be provided as an upgrade since they have a support contract. So, it's a tough sell, but I know that isn't your area of expertise so I'll not bother you with it anymore than I already have.
However, you make an excellent point, though I don't think it was your intent. There is a general lack of consistency with EMC Documentum products. If you have a new, objectively better form of documentation for D2, why have a different system for everything else? I think EMC should strive for a uniform, standardized way of providing software and services, including documentation. I know a lot of these products were acquired and are slowly being integrated, I'd suggest that a bit more polish be applied before they are released. I want to see a more homogenous product that has already had all of the rough bits from integration filed down before I get my hands on it.
Julien Fontaine, old school is putting it mildly. It's all PDFs. You can't imagine how hard that is to manage until you are the one who has to use it. It might be a convenient method of providing documentation for EMC but it is horribly inconvenient for the customers. Personally, I think if anyone is going to be inconvenienced it should always be EMC in favor or making things easier for the customer. As if having to cross reference multiple PDFs in order to install and manage one product wasn't bad enough, those PDFs are almost always just minor edits from the previous versions, hardly ever platform or architecture specific, and full of errors and omissions that can literally have you struggling for days only to find that you weren't doing anything wrong, it was just the documentation that was wrong. If I were EMC, before I started work on any more features I'd fix the documentation for the existing product, and I don't mean submitting a bunch of DOC FIX SRs to correct the existing PDFs.
It needs to be rebuilt from the ground up, all online, all of it easily accessible in one place, and constantly updated and corrected. Though, I'd still like a wiki, official or not. I disagree with Alvaro de Andres, wikis work great for documentation in the open source world, but usually only with FLOSS, the problem is with open source software that is really just commercial software using the words "open source" for marketing appeal. It can work with commercial software too, but that requires the company to be extraordinary in the relationship they have with their customers, and that usually isn't the case.
This could all be solved if EMC would provide a wiki formatted documentation site. If we had a wiki we could correct the documentation ourselves and not need to wait months and submit multiple needless SRs just to get a correction to the documentation. If we can't depend on your to give us accurate documentation then you should at least let us fix it ourselves.
Mark, I completely disagree with you. Wiki won't change anything because EMC follows the next principle: what is not documented is not supported (if somebody want to disagree with me, read this first as example, though I have hundreds of such cases), and this principle is very convenient: it allows to sell wide range of support services (extended support, professional services, educations, certifications, etc) - you can download IIG's financial results and find out how much IIG earns due to the lack of documentation Wiki is able to relieve your routine work, but nothing more
I'd like to ask about Java support changes for 7.1. Can you list everything that has changed in regards to Java?
For example, I'd really like to see all of the Documentum process that use Java to use the system Java and not an included JDK. One important advantage of this would be to make it much easier for us to support IT security mandated updates to Java without the need and paperwork involved for obtaining waivers. I have learned through various sources that replacing the included JDK and symlinking (Linux) to your system installed Java usually works fine anyway so why isn't this the way it is done out-of-the-box? Just use $JAVA_HOME and require that a JDK be installed. I can understand limiting the version of the JDK to the most recent stable major version but anything more specific than that won't work for us. If incompatibilities are introduced they should be handled with patches to Documentum and not by requiring a specific version of Java.
The biggest change is the adoption of Java 1.7 from the content server up. Updates to the Java Method Server (JMS) implementation made this upgrade possible.
Earlier Documentum relied on a number of shared libraries across the stack or services. This worked well when all services and clients were released and certified together at the same time. But it did lead to additional risk, time and effort if one of these components was updated to fix a bug or behaviour in a Production system. When we moved away from native load-once components like DMCL, we saw a proliferation of client applications that reused the same Java version so they could all run with the same AppServer. It helps to have the comfort of that AppServer container. Most of the Documentum services run in their own process without an AppServer. They're designers wanted to keep as much compartmentalized as possible with a focus on Ease of Deployment.
An option to make later maintenance easier by sharing Java binaries sounds reasonable to me.
I'd like to ask about kerberos (single domain, single forest) multi-docbase support within Webtop. In the past we had trouble configuring webtop for Kerberos authentication for more than one docbase. The user was required to authenticate to subsequent dobases after the initial selection on the docbase selection page. However, we need to have multiple docbases open within the same Webtop instance, to be able to search across these multiple docbases but to never have to type a username and password. The inability to do this is what tanked our previous efforts at upgrading since we had planned on doing a complete architectural overhaul in the process. If 7.1 can support this it would go a long way toward convincing management that the time to go to 7.1 is now.