Well, your intrepid adventurers have 3 days of Working Outside the Inbox under our belts and I thought this a would be a good time to discuss in a little more depth about how we are doing this.
Lets start with Step 1: Stop replying to email. This step would really be more accurately described as Mindful Processing of Email but that doesn't sound nearly as provocative and attention-grabbing, and wouldn't make nearly so many people's heads explode, which wouldn't be nearly as much fun.
So listen: this is what we are really doing.
Think of this as stopping the reflexive knee-jerk reaction of working in your inbox, simply reading and replying. We've all become very well trained by our inboxes: receive an email, send an email. Read your incoming email and then...
Stop. Think. Ask yourself a few questions along these lines:
Change begins with us (and you!)
Here are some wild and crazy ideas on how you can work effectively and openly and without being chained to your inbox:
Use the content repository or content management system of your choice as long as it's NOT YOUR MACHINE. Don't become the bottleneck, or the single point of failure. Put your stuff where people can find it and get it. When people email and ask you for that information, give them a link to the information where you've posted it.
Use wiki pages for knowledge capture and on-demand access. One example, instead of keeping your project status or metrics in a spreadsheet on your machine, think open and transparent and provide that data on a wiki page. if your manager expects a weekly status report, put it there.
discussion forums for collaboration, idea sharing and brai
Use the community blog for news, announcements, and community-wide communications. Why blog? To take advantage of all the technology that allows us to share knowledge more widely ... tags, RSS feeds, aggregators, search.... the list goes on. Rather than sending an 800mg email that immediately plunges 20% of your unsuspecting audience into "mail jail", try blogging your news. Oh, the 80% who aren't in mail jail? I posit that 40% will not read it anyway, either deliberately or by accident when it scrolls "below the fold" amidst a barrage of other people sending news, asking questions, and, worst of all, sharing files.
Besides, I bet a couple of weeks from now, someone's going to ask you for the information again anyway.
Speaking of sharing files.... There are better ways. Instead of mailing a slide deck to 10 people for review and comments, use Connections and if you MUST send an email, send a link to where you have posted the file (or the wiki page from which you are working) so that it can benefit the greatest number of people, who can then bookmark it / subscribe to it / grab the RSS feed, or otherwise self-serve when they need the information. Which means the doc owner doesn't need to send the updated file out to a cast of thousands either.
Oh, it all just makes so much SENSE.
So no, we're not giving up email entirely, and there will be times that we will (gasp!) send an email. We're just going to be mindful in our work and aim to get the maximum value from each interaction.
So, stop and think.
Just because a conversation starts in email doesn't mean it belongs there.
kellypuffs 06000168YK Visits (4780)
During August and September IBM Rational Client Support will be conducting a Customer Orientation Webcast series, geared specifically for our new Green Hat clients, but open for anyone to attend.
We are inviting you and your clients to attend our August/September Customer Orientation Webcast series, and to help ensure that you get the maximum utlization out of your IBM products.
During this informative 45 minutess presentation and Q&A, we'll explain how to:
If you know any people in your organization that are involved in administration or utilization of any Green Hat products, please let them know about this webcast that can be helpful in introducing them to IBM Support.
We look forward to meeting you at our next webcast!
kellypuffs 06000168YK Visits (4724)
From the IBMJazz channel on YouTube:
Sumant Renukarya 270002B42N Visits (4719)
If there is a need to know the cipher used by CLM applications or RTC and the level of encryption used for web-clients, this blog should be of some help.
Cipher refers to the algorithm used for performing encryption and decryption of the data.
Generally, SSL (Secure Socket Layer) is used for data encryption, decryption and transmission using certificates or smart cards. However, this also depends on the kind of Application server being used. Based on the kind of application server in use, the respective product documentation should have the details on the cipher used.
Websphere Application Server, Apache Tomcat
a. For Internet Explorer, login to RTC and then right click on the web-page --> Properties;
b. For Firefox web-browser, if one hovers and clicks on the padlock symbol prior to URI in the address bar, say before https: //ho
So, if the RTC/CLM installation is based on Websphere Application Server (v7.0), the site supports a minimum cipher strength of 168 bit encryption. This, can be confirmed by looking into the properties for ccm application web-page and the application server documentation.
By default, using the Apache Tomcat application server the site supports a minimum cipher strenght of 128 bit encr
The cipher indicates that the data is encrypted between the Internet browser and the Server. It doesn’t encrypt the data on the database itself.
This is what is behind the HTTPS protocol and is managed by the Application server. RTC is only an application installed on top of Jazz, which is installed on WebSphere.
Here is the link for the WebSphere v 7.0 documentation - About "TLS 1.0, 3DES with 168 bit encryption (High)". This explains SSL Version 3 and TLS Version 1.0 cipher specifications: http
AcdntlPoet 2700019V2G Visits (4702)
Are you ever confused by some acronyms or IBM-isms which you may come across on the web, in support calls, or discussions with colleagues? Here's a tip I stumbled upon which has helped me substantially in my day-to-day business which I am now sharing with you in the hopes you'll find it helpful as well!
This post explains the IBM V.R.M.F - Maintenance Delivery Vehicle (MDV) terminology used by Rational products. V.R.M.F is the product release numbering format that is being implemented throughout the IBM and the Rational product lines.
IBM is using a standard version format for MDV. The product numbering is based on the IBM Version, Release, Modification and Fix Level structure within the V.R.M.F format.
The following table provides some details of the individual version elements. Note: Although not all of the version elements are publicly available, they are all fully supported:
Wondering about all the document definitions as well? Check out the IBM Software Support Document Definitions page for brief, glossary style definitions of all the various document types we as IBM may produce.
And lastly, how about a link to our Site Assistance page... here you can find a number of resources to help with things like navigation, search, filtering, managing support portal modules, managing product lists, and much more!