Dude, I've already voted for MVP.  Oh...  :)

On Tue, Jul 30, 2013 at 12:09 PM, Longwing, Lj <llongw...@usgs.gov> wrote:

> **
> And to make it SUPER easy
> https://communities.bmc.com/ideas/1421
> that's the link to the idea...all you need to do is go in and log in (if
> not already) and click the up arrow to cast your vote...I really didn't
> expect this to be an issue...but apparently there isn't enough support to
> do various things in the community.
>
> Come on folks..participate :D
>
>
> On Tue, Jul 30, 2013 at 12:59 PM, Mueller, Doug <doug_muel...@bmc.com>wrote:
>
>> **
>>
>> Tom (and others who responded),****
>>
>> ** **
>>
>> The "feature" of zero-down time and the demonstration at WWRUG 2012 was a
>> lab demo to show a****
>>
>> concept that we had taken from design into prototype to gage interest
>> from the customer base.****
>>
>> ** **
>>
>> To be clear, it is not present in any release of the product at this time.
>> ****
>>
>> ** **
>>
>> We are still gaging customer interest and I will say unfortunately, the
>> interest expressed in this topic has****
>>
>> not been as strong as several of us expected.  There is interest – don't
>> get me wrong – but there are other****
>>
>> things that are generating much more concern from customers.  There is
>> still a contingent struggling to get****
>>
>> this capability added to an upcoming release – but nothing has made it
>> yet.****
>>
>> ** **
>>
>> ** **
>>
>> The functionality we demonstrated was true zero-down time.  It creates
>> parallel metadata tables with new****
>>
>> and old definitions and different servers pointing to different sets –
>> ALL ON THE SAME DATA TABLES.  Lots of****
>>
>> work went in to handle deleted fields (delete is deferred because the old
>> version is still using the fields) and****
>>
>> to even handle cases where archgid changes field IDs (extra view forms
>> are put in place so that both old and****
>>
>> new use the IDs they expect and all is in place).****
>>
>> ** **
>>
>> Both old and new versions of the applications were available and running
>> through different servers in the****
>>
>> server group so you could confirm that all was ready before you flipped
>> the switch.****
>>
>> ** **
>>
>> If any system went down, it came back up looking at its set of
>> definitions so everything is robust and****
>>
>> recoverable while in this mixed mode.****
>>
>> ** **
>>
>> We went so far as to have servers running the old app have a signal to
>> load and prepare the new definitions****
>>
>> in the background while continuing to run the old version so when they
>> were signaled to go live, they finished****
>>
>> any current API call in the old version and any new API call started
>> working with the new version for absolute****
>>
>> zero down time transition at the server.****
>>
>> ** **
>>
>> This means that any program or integration has zero interruption or
>> disruption.****
>>
>> ** **
>>
>> Now, the interactive user through the mid-tier has the issue of caching.
>>  Depending on whether an immediate****
>>
>> update occurs or you are just going to let the next interval check do it,
>> it may be instant to a few minutes****
>>
>> before the updates are reflected to the client and there is going to be a
>> performance slowdown that will be****
>>
>> noticeable as things are reloaded (kind of like a first time reload after
>> mid-tier startup) and then changed****
>>
>> screens will show up.  So, they are never down, but there is a short time
>> of affect on interaction of users.****
>>
>> ** **
>>
>> ** **
>>
>> This is not fantasy as we have prototyped it and it was what was
>> demonstrated at WWRUG and it does work.****
>>
>> ** **
>>
>> If you have not entered your vote for this feature on the BMC Communities
>> AR System thread Ideas entry****
>>
>> for this feature (this is an area where you or BMC posts enhancement
>> requests and the community can vote****
>>
>> on it to show interest – higher vote totals help push features up the
>> list for implementation), please enter****
>>
>> your vote to show support for the idea.****
>>
>> ** **
>>
>> ** **
>>
>> This does not mean no work for the Administrator during an upgrade, but
>> it means no end user outage for****
>>
>> an upgrade.  It should also help reliability and success of an upgrade in
>> a dramatic way as you can test and****
>>
>> verify and make any corrections in the new version before go live.  It
>> also should remove the I have to do****
>>
>> everything under time pressure in the middle of the night on a weekend
>> issue to avoid customer downtime****
>>
>> as much as possible topic.  So, a win for everyone all around.****
>>
>> ** **
>>
>> ** **
>>
>> I hope this confirms and clarifies this capability, what it is and where
>> it is.****
>>
>> ** **
>>
>> Doug Mueller****
>>
>> ** **
>>
>> *From:* Action Request System discussion list(ARSList) [mailto:
>> arslist@ARSLIST.ORG] *On Behalf Of *Tom Shurmur
>> *Sent:* Monday, July 15, 2013 6:57 PM
>> *To:* arslist@ARSLIST.ORG
>> *Subject:* 7.6.04 Upgrade to 8.1****
>>
>> ** **
>>
>> ** ****
>>
>> Howdy Listers,****
>>
>>  ****
>>
>> We are about to embark on upgrading from 7.6.04 to 8.1 on a windows
>> platform using MS-SQL. Has anyone used the No Downtime Upgrade method that
>> was presented at last year’s WWRUG to move from 7.6.04 to 8.1? If so, was
>> it smooth or bumpy ride?****
>>
>>  ****
>>
>> We will be standing up a test system with 2 app VMs and a DB to test this
>> approach.****
>>
>>  ****
>>
>> I look forward to your feedback****
>>
>>  ****
>>
>> Tom Shurmur****
>>
>> Sr Remedy Developer****
>>
>> Froedtert Health System****
>>
>> _ARSlist: "Where the Answers Are" and have been for 20 years_****
>>  _ARSlist: "Where the Answers Are" and have been for 20 years_
>>
>
> _ARSlist: "Where the Answers Are" and have been for 20 years_
>

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Reply via email to