Narrative:

I was working radar position 15. My adjacent sector 6, called to inform me of traffic requesting IFR. Sector 6 '/oked' (logic override function). The departure message and initiated a data block only handoff. I accepted the handoff and subsequently issued IFR clearance. The 'dm' message that sector 6 initiated caused an 'unsuccessful message' to display on my vdm (video display monitor) which I did not catch. The aircraft traversed my sector normally, but when a handoff was initiated to ZDV (denver), it failed. I was very busy with other duties in the sector and didn't notice the failed 'flash.' I reinitiated the handoff, only to have it fail again. (The second time always works!) I noticed the data block not flashing anymore, so I thought, and issued a frequency change to the aircraft. A mins or so later, I received a call from ZDV, 'who is this guy?' no flight plan information had passed to ZDV. Fortunately, I was able to initiate a manual handoff and pass flight plan information prior to the aircraft exiting my airspace. No foul! However, I was removed from duty because of a 'performance issue.' failure to recognize an unsuccessful flight plan!? The failure was a result of ZDV computer not recognizing the obscure departure airport in ZLC airspace. This lack of computer input/database could have caused a serious problem. But fortunately, I was able to quickly cover steps and avoid that situation. With dsr on-line and the fact that the denver computers have ample storage capacity, there should be no excuses for any airport not being stored in any database! 3-LETTER identifiers do not consume any, or very little, computer memory. This should have never happened!

Related reports:

Google
 

Original NASA ASRS Text

Title: ZDV CTLR ALERTS ZLC CTLR OF UNCOORD COM HDOF XFER OF ENRTE GV.

Narrative: I WAS WORKING RADAR POS 15. MY ADJACENT SECTOR 6, CALLED TO INFORM ME OF TFC REQUESTING IFR. SECTOR 6 '/OKED' (LOGIC OVERRIDE FUNCTION). THE DEP MESSAGE AND INITIATED A DATA BLOCK ONLY HDOF. I ACCEPTED THE HDOF AND SUBSEQUENTLY ISSUED IFR CLRNC. THE 'DM' MESSAGE THAT SECTOR 6 INITIATED CAUSED AN 'UNSUCCESSFUL MESSAGE' TO DISPLAY ON MY VDM (VIDEO DISPLAY MONITOR) WHICH I DID NOT CATCH. THE ACFT TRAVERSED MY SECTOR NORMALLY, BUT WHEN A HDOF WAS INITIATED TO ZDV (DENVER), IT FAILED. I WAS VERY BUSY WITH OTHER DUTIES IN THE SECTOR AND DIDN'T NOTICE THE FAILED 'FLASH.' I REINITIATED THE HDOF, ONLY TO HAVE IT FAIL AGAIN. (THE SECOND TIME ALWAYS WORKS!) I NOTICED THE DATA BLOCK NOT FLASHING ANYMORE, SO I THOUGHT, AND ISSUED A FREQ CHANGE TO THE ACFT. A MINS OR SO LATER, I RECEIVED A CALL FROM ZDV, 'WHO IS THIS GUY?' NO FLT PLAN INFO HAD PASSED TO ZDV. FORTUNATELY, I WAS ABLE TO INITIATE A MANUAL HDOF AND PASS FLT PLAN INFO PRIOR TO THE ACFT EXITING MY AIRSPACE. NO FOUL! HOWEVER, I WAS REMOVED FROM DUTY BECAUSE OF A 'PERFORMANCE ISSUE.' FAILURE TO RECOGNIZE AN UNSUCCESSFUL FLT PLAN!? THE FAILURE WAS A RESULT OF ZDV COMPUTER NOT RECOGNIZING THE OBSCURE DEP ARPT IN ZLC AIRSPACE. THIS LACK OF COMPUTER INPUT/DATABASE COULD HAVE CAUSED A SERIOUS PROB. BUT FORTUNATELY, I WAS ABLE TO QUICKLY COVER STEPS AND AVOID THAT SIT. WITH DSR ON-LINE AND THE FACT THAT THE DENVER COMPUTERS HAVE AMPLE STORAGE CAPACITY, THERE SHOULD BE NO EXCUSES FOR ANY ARPT NOT BEING STORED IN ANY DATABASE! 3-LETTER IDENTIFIERS DO NOT CONSUME ANY, OR VERY LITTLE, COMPUTER MEMORY. THIS SHOULD HAVE NEVER HAPPENED!

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