Narrative:

I accepted hand off on aircraft #1 enroute; northeast bound on J14; FL330. I accepted hand off on aircraft #2 climbing westbound to FL230. Based on observed traffic; I climbed aircraft #2 to interim altitude of FL320 (he was requesting FL340). I changed my attention to my uret screen to clean up the screen from unneeded entries derived from having just opened the sector. I noticed two entries which were of the same aircraft but were 'greyed out'. Neither had a cid. I assumed the entries were of aircraft which had exited the sector and deleted them. Just to make sure; I performed a qf message on the aircraft. The call sign did not exist. As aircraft #2 was leveling FL320 and clear of traffic; I started to climb aircraft #2 to FL340. It was then I noticed a merging; limited; non-correlated data block at FL330 directly in front of aircraft #2; now at FL320. I did not climb aircraft #2. At this point; I had no idea who this target was. Remembering the call sign of the 'greyed out' entries earlier in uret; I called in the blind for the aircraft to ident. It was indeed that aircraft; aircraft #1. His flight information was gone. No track. No flight plan. Nothing. This could only happen with a 'remove strip' message. It wasn't done at this sector. It could have only have been done from somewhere else with a logic override and verification check. A three step process. I told the pilot we had lost all his flight plan information. I got the information from him. With the assistance of a newly acquired d-side; we were able to input a new flight plan and effect a hand off to washington center less than one minute from the common boundary. I was later told the 'remove strip' message originated from the traffic management unit at the center. For what reason I don't know. The logic override and verification checks are put in place for this type of computer entry to avoid a situation like this. It was apparently ignored. But; once it had been done; the traffic management controller (or any controller for that matter) should find the sector in which his computer input affected and advise them immediately. This was not done. Two situations were averted after noticing the untracked; limited data block. 1.) a possible system error between aircraft #1 and aircraft #2. 2.) a system deviation with the adjacent sector/center. Entering airspace without coordination. This should have never happened.

Related reports:

Google
 

Original NASA ASRS Text

Title: ZTL controller described a loss of data block information that nearly resulted in a loss of separation; reporter claiming Traffic Management failed to provide notification to the sector after dropping the data.

Narrative: I accepted hand off on aircraft #1 enroute; northeast bound on J14; FL330. I accepted hand off on aircraft #2 climbing westbound to FL230. Based on observed traffic; I climbed aircraft #2 to interim altitude of FL320 (he was requesting FL340). I changed my attention to my URET screen to clean up the screen from unneeded entries derived from having just opened the sector. I noticed two entries which were of the same aircraft but were 'greyed out'. Neither had a CID. I assumed the entries were of aircraft which had exited the sector and deleted them. Just to make sure; I performed a QF message on the aircraft. The call sign did not exist. As aircraft #2 was leveling FL320 and clear of traffic; I started to climb aircraft #2 to FL340. It was then I noticed a merging; limited; non-correlated data block at FL330 directly in front of aircraft #2; now at FL320. I did not climb aircraft #2. At this point; I had no idea who this target was. Remembering the call sign of the 'greyed out' entries earlier in URET; I called in the blind for the aircraft to ident. It was indeed that aircraft; aircraft #1. His flight information was gone. No track. No flight plan. Nothing. This could only happen with a 'remove strip' message. It wasn't done at this sector. It could have only have been done from somewhere else with a logic override and verification check. A three step process. I told the pilot we had lost all his flight plan information. I got the information from him. With the assistance of a newly acquired D-side; we were able to input a new flight plan and effect a hand off to Washington Center less than one minute from the common boundary. I was later told the 'remove strip' message originated from the traffic management unit at the center. For what reason I don't know. The logic override and verification checks are put in place for this type of computer entry to avoid a situation like this. It was apparently ignored. But; once it had been done; the traffic management controller (or any controller for that matter) should find the sector in which his computer input affected and advise them immediately. This was not done. Two situations were averted after noticing the untracked; limited data block. 1.) a possible system error between aircraft #1 and aircraft #2. 2.) A system deviation with the adjacent sector/center. Entering airspace without coordination. This should have never happened.

Data retrieved from NASA's ASRS site as of April 2012 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.