Narrative:

Air carrier X was by all rights just a normal looking flight plan going through eugene approach airspace as an over flight. When I tried to perform an automated hand off it was rejected due to no ARTS flight plan. I tried an RF to EEE (eugene approach) but that would not work. I had to call eugene approach with a manual hand off which was time consuming during a busy morning rush period. Eug approach had absolutely no information at all on this aircraft. I had to strip request them a strip so they could have a flight plan to refer to. I performed a manual hand off and then later on when I had more time I rerouted the aircraft direct eug. After that; I then had to RF the fp to EEE twice before I was able to perform an automated hand off. This problem was prevalent in previous eram builds and was fixed at one point. Now after the latest eram build it has returned! Air carrier Y was right behind air carrier X and I experienced no problems at all with the hand off on that aircraft. This is at least the second time with the same problem on air carrier X. Last week we had the same problem on the same aircraft which showed up right after a newer eram update was installed. Separate but related is air carrier Y. Although I did not experience an auto hand off issues with that aircraft; I did experience an auto pop situation where the aircraft continually popped on my scope after I dropped the data block off. The aircraft was at FL090 (top of eug airspace) and when mode C showed FL091 it was unnecessarily forced onto my scope causing unnecessary clutter. This problem was also fixed at one point but has also returned with the latest eram build that was just brought online last week. While I am at it; add numerous pref set issues that have returned as well with the last eram build. These issues are annoying enough but the real issue is that the problems that had previously been fixed have returned now after the new eram build was brought online. They have reared theirs ugly heads again! Why? Because of the way eram is updated by working with an outdated eram build. It appears that they use the previous build (along with all the problems it had which have been fixed in the current build.) why not use the current build or figure out a way to use the current build as opposed to the previous build for the next build. Whatever build is used for the base it must not have previous problems returning especially if the fix for those problems has been developed and is currently in use. Recommendation; stop going retro on the eram updates. Whenever they update eram we end up going back to having problems which were previously fixed but now show up again until the next subsequent eram build is implemented. The current problems are usually fixed when the updated build goes online but then the previous problems which were also fixed show back up again and so on and so on. Eram takes one step forward but two steps back every time they give us a new update. There has got to be a better way to do updates than having previously fixed problems show up again after they have been fixed. We should never see any of those problems again if they have supposedly has been fixed. If microsoft or any other company operated by installing old bugs along with their latest update - well I doubt they would be in business for long and the customers would revolt on a massive scale. Why is the contractor being allowed to operate in this disjointed and un-business like manner of installing old problems for which there is currently a fix available and especially when the fix is already in use at the present time?

Related reports:

Google
 

Original NASA ASRS Text

Title: ZSE Controller expressed concern regarding ERAM problems that resurfaced after recent software re-build.

Narrative: Air Carrier X was by all rights just a normal looking flight plan going through Eugene Approach airspace as an over flight. When I tried to perform an automated hand off it was rejected due to no ARTS Flight Plan. I tried an RF to EEE (Eugene Approach) but that would not work. I had to call Eugene Approach with a manual hand off which was time consuming during a busy morning rush period. EUG Approach had absolutely no information at all on this aircraft. I had to strip request them a strip so they could have a flight plan to refer to. I performed a manual hand off and then later on when I had more time I rerouted the aircraft direct EUG. After that; I then had to RF the FP to EEE twice before I was able to perform an automated hand off. This problem was prevalent in previous ERAM builds and was fixed at one point. Now after the latest ERAM build it has returned! Air Carrier Y was right behind Air Carrier X and I experienced no problems at all with the hand off on that aircraft. This is at least the second time with the same problem on Air Carrier X. Last week we had the same problem on the same aircraft which showed up right after a newer ERAM update was installed. Separate but related is Air Carrier Y. Although I did not experience an auto hand off issues with that aircraft; I did experience an auto pop situation where the aircraft continually popped on my scope after I dropped the data block off. The aircraft was at FL090 (top of EUG Airspace) and when Mode C showed FL091 it was unnecessarily forced onto my scope causing unnecessary clutter. This problem was also fixed at one point but has also returned with the latest ERAM build that was just brought online last week. While I am at it; add numerous pref set issues that have returned as well with the last ERAM build. These issues are annoying enough but the real issue is that the problems that had previously been fixed have returned now after the new ERAM build was brought online. They have reared theirs ugly heads again! Why? Because of the way ERAM is updated by working with an outdated ERAM build. It appears that they use the previous build (along with all the problems it had which have been fixed in the current build.) Why not use the current build or figure out a way to use the current build as opposed to the previous build for the next build. Whatever build is used for the base it must not have previous problems returning especially if the fix for those problems has been developed and is currently in use. Recommendation; stop going RETRO on the ERAM updates. Whenever they update ERAM we end up going back to having problems which were previously fixed but now show up again until the next subsequent ERAM build is implemented. The current problems are usually fixed when the updated build goes online but then the previous problems which were also fixed show back up again and so on and so on. ERAM takes one step forward but two steps back every time they give us a new update. There has got to be a better way to do updates than having previously fixed problems show up again after they have been fixed. We should NEVER see any of those problems again if they have supposedly has been fixed. If Microsoft or any other company operated by installing old bugs along with their latest update - well I doubt they would be in business for long and the customers would revolt on a massive scale. Why is the contractor being allowed to operate in this disjointed and un-business like manner of installing old problems for which there is currently a fix available and especially when the fix is already in use at the present time?

Data retrieved from NASA's ASRS site as of July 2013 and automatically converted to unabbreviated mixed upper/lowercase text. This report is for informational purposes with no guarantee of accuracy. See NASA's ASRS site for official report.