Evan Reiter

Deal. We'll do that right after the upcoming (April 20) Pp at KIAH.

I sent out a long e-mail recently (full text below) describing what's been going on with the forums and the website. As I explain in the e-mail, we were forced to transition our forums from an MS SQL database to MySQL. This process was incredibly challenging, especially without using any commercial/payware software. I am happy to say that *I think* all of the users, forums, and posts from our previous database have been transitioned. However, there may be some posts that are missing; there could also be some posts that do not display as intended. Each user will also have to go back and reset signatures and avatars (sorry!) I am confident this will be the last time we have to transition the forums anywhere. Now that we are securely on MySQL, it should be easy to transfer the forum to any other ISP because pretty much every ISP supports php in non-Windows environments (whereas many do not support php for MS SQL). You may see some topics that have some strange-looking text at the top. As long as the text in those posts appears properly, I am not concerned. However, if you do find posts that are clearly irrelevant and should be deleted, please let me know. ----- Text from e-mail to be sent out Saturday, February 19 ------ Many of you are aware of the issues we have been having with our website. Since January 17, parts of the site—including (at separate times) the forums, main website, and e-mail system—have been unavailable. Phil, Bill, and I have been working to try to fix these issues as quickly as possible, and without the loss of any data or user accounts. I am happy to say that we have mostly accomplished this. A full description of what has happened over the past month for those interested in reading through it is included below. However, for everyone, please note the following important information. 1/ Unless you received an e-mail otherwise, you should be able to login to your account on both the forums and website. If you are not able to login, please check your e-mail for instructions. If there is no information there, please contact us for assistance. 2/ Some pages of the website, including “Downloads”, “Event Scenery”, and “Image Gallery” will remain unavailable for a few weeks. 3/ Migrating a website is (as we recently found out) a rather complex process. There will likely be broken links in a number of places that we have forgotten to change. Please use the “Broken Links” thread on the forums or e-mail us directly to report any links you find that do not work. I would also like to thank everyone for the immense patience you have shown. Administrating a website and forum system as complex as BVA’s should be a full-time job! In order to prevent similar scenarios, we have transitioned the website to a much more reliable ISP with much better support. We have also switched the forum database structure to a more widely-used system. While I know issues will continue in the future, I cannot imagine that we will see anything like the issues we have over this month again. The remainder of this e-mail explains what has occurred over the past month in terms of attempting to restore the forums, website, and e-mail system. This information is provided for your interest only; please ignore this section unless you are curious to know what we have been going through for the past month. The steps we took are presented in a brief timeline format. Provider names have been disguised. The ISP we have used since 2006 is referred to as “Provider A”; our new provider is referred to as “current provider”. I have written the timeline below not to show you what happened but to give you an idea of the immense contribution that Bill and Phil have made to our community through their support. The tireless efforts of the many people that keep BVA in the air are a constant inspiration. January 17: We discovered that e-mails from the website (including password reminders) were not being sent. When I would try to send an e-mail from the website, I would get a confirmation and positive report, but no e-mail would actually appear. No error messages were displayed. January 17: We posted support tickets with Provider A and Google (our e-mail is sent through Google). We were able to confirm the issue was at Provider A very quickly. As of February 19, the support ticket totals 19 pages. No progress has been made. By page 18 (a week ago), they admitted it was their fault. January 21: The forums go offline with an error message that states: “General Error; could not get style data”. phpBB support forums indicate the issue has to do with file permissions. We ask Provider A to reset file permissions but they claim this is impossible. January 22: Recognizing that the solution to issue with the forums rests in the hands of Provider A, we open an account with Provider B and begin to transfer files and database structures to this provider. Simultaneously, we called Provider A several times, establishing a relationship with one of the operational managers there. We made no progress. January 23: The forums and a basic copy of our website are online through Provider B. We re-link the forums to this provider and re-open the forums. E-mails sent through the website on Provider B using the same SMTP settings go through. January 23: BVA’s website (on Provider A) goes down. I call Provider A who claims the issue is a “permissions problem that should be resolved in 30 minutes”. A few hours later, the website returns and BVA’s original forums return as well. We spent the entire weekend fixing a problem that was in fact a permissions issue that could have been fixed by Provider A. January 23-27: We perform more than 4 years of upgrades on the website and forums that we could not do with Provider A. January 27: Provider B is a temporary host that offers very little space and bandwidth. While we were glad to host the forums there for a short period, it was a temporary solution. Since no progress had been made with either e-mail from Provider A, we opened an account with Provider C. January 28: While opening the account with Provider C, they confirm that we can migrate all our files and database structures to their servers. January 28-31: Provider C’s control panel does not allow us to migrate a backup copy of our database to their servers. We attempt a workaround method described on their knowledgebase that fails. After spending several hours uploading more than 10 GB of files, a call to Provider C’s support confirms there is no other way to migrate this database. We close the account with Provider C. February 1-5: We continue to go back and forth with Provider A over the e-mail issue. In the interim, I use Provider B’s website to send Event Reminder e-mails and manually inform new members that they have been approved. Since the website’s Password Reminder feature uses this e-mail system, several users contact me to request password changes. February 3: In an attempt to speed up our website, Provider B performs an upgrade to our account. This disables the forums and website. We go back and forth through support tickets but they refuse to provide any additional support. Later in the week, we closed the account with Provider B. February 4: Since the forums with Provider A had come back online and Provider B’s forums went down, we wanted to use Provider A for the forums again. When we tried to re-activate these forums, all the posts disappeared. The topics are still in place, but none of the actual posts appear. February 6: We open an account with our current provider. This provider is billed as an expert in the types of software used by our website and forums, claims to have excellent support, and was recommend by the developer of our website’s content management system. February 7-9: We upload the files and database to our current provider. February 11: With the help of our current provider’s support, a copy of the website is installed and works. E-mail does not work. The forums display php error messages or simply do not display. February 11-13: Our current provider and I work on getting the forums online. Our brand of forums is not intended to run on the type of database we have been using in the past. Our ISP recommends that we switch to a MySQL database (from MSSQL), but this process is complex and not supported. They do not know of a way that data from MSSQL can be transferred to an installation of the forums on MySQL. February 13-15: We are able to finally get the forums and website online. However, the infrastructure in place at this new provider was not designed to run our forums on MSSQL. The forums are slow to load. It is impossible to make changes to settings. February 18: We decide to try to migrate the database elements from MSSQL to a MySQL version of the forums. We discover we can migrate files by individually accessing database elements (users, posts, subjects, etc. are stored in separate files), downloading them, and re-uploading them to the new database. The forums and topics display okay, but the actual posts do not import. February 19: Bill, through an ingenious parsing of the XML file, is able to create a file that the MySQL reader can accept. Most of the posts, along with the users and groups, appear on the new forums. February 19: Domain name transfer initiated.

I think if we just use the ATC Timetable -- and allow controllers to coordinate as they see fit -- we would be able to accomplish that quite effectively.

Isn't that basically the Pack the Pattern event, though? Obviously pilots are encouraged to fly circuits but there's no requirement to do that. We've done KBOS about 4 times for Pp events.

In 2009, BVA hosted a charity event called the "Flight for the Fight" that generated almost $1,000 in donations to BVA and the Susan G. Komen Breast Cancer Foundation. In 2009, we fully-staffed KBOS and had controllers available at KALB and KBTV. Each flight plan generated donations, as did every flight plan status change (for example, when it passes between controllers). You can find a summary of what happened in 2009 here: http://bostonvirtualatc.com/dnn/Portals ... _Final.xls. This year, we are thinking of hosting another Flight for the Fight. We want your input as to which event concept might be most popular. You'll see this question on our Poll Question of the Week that you can vote on by signing in to the home page. A description of each of the concepts follows. In each of the concepts, money would be generated for each flight plan and all of the strip status changes. We'd like to know which of the concepts you think would be most popular. If you have any other suggestions, please feel free to post those to this thread. 48 Hours of ATC ZBW_C will be staffed on a shift basis consistently for 48 hours. Other controllers will be online during peak hours. This event would be targeted toward everyone but would be beneficial for those in other time zones who do not normally get to fly with BVA. It would likely be held on a weekend so most people can take advantage of ATC as much as possible. Pack the Pattern + Regional Circuit This event would operate like a normal Regional Circuit but would also encourage pilots to "Pack the Pattern" at each of the endpoint airports. That should allow for a nice mix of arriving and departing traffic as well as circuit traffic to keep controllers busy with merging traffic from opposite directions. Stuff the Circuit A regular Regional Circuit between KBOS and KJFK (or some other NY airport). The draw here would be that if we can get a large number of pilots (we had around 50 for the original FFTF), we should have a very intense experience for everyone, especially if pilots are encouraged to fly as many flights as possible. Original Flight for the Fight Like the first FFTF, this concept would feature a fully-staffed KBOS along with two other satellite airports.

Another successful Colorado Getaway is in the books as far as I'm concerned. Thanks for joining us at KASE, KCOS, and KDEN this past week. As enjoyable as the event was, however, it will certainly be a relief to get back to the East Coast where I don't have to worry about vectoring anybody into a mountain (I'm glad to say that didn't happen once this getaway). I'm sure controllers who have been waiting until we get to KBOS for their certifications are happy to hear that we'll be beginning that tomorrow as well. See you in Alaska later this year!

Thanks for the suggestions! Let me start with a brief explanation of our events. Running events at a virtual community like ours is a balancing act: we need to keep both pilots and controllers as happy as possible. Having too many events that favor one group over another isn't healthy in the long-run. Too many pilot-focused events and controllers won't want to sign up to control| pilots find some of the best ATC-focused events too short or unrealistic. We generally try to offer a range of events in different locations to keep things interesting and try to vary events between long and short, easy and challenging, pilot-focused and controller focused, etc. If you haven't had a chance to look through our Events page, I recommend you do so. Many of these events are coming up in the next month, so you should have a good chance to see what events at BVA are all about. When it comes to suggestions about events, I generally try to accept as many as possible if they seem feasible and will have the support of the community. For example, BVA recently voted that a foul-weather event would be interesting, so we will set up something in a future Regional Circuit to give that a try. Other suggestions are not always as practical (for example, suggesting a Regional Circuit that is 400nm long just won't work). The Domestic Journey, which often features longer routes, tends to be the least popular event (the Dj was 14% of members' favorite event| the Rc was 37%). The other complication is the Scenery Design Team: the group needs a few months' lead time in order to prepare the updates we value so highly during events. For that reason, I have a long list of Regional Circuit citypairs I provide Dan and his team with in advance so that they know what's coming. If someone has a suggestion for a citypair, I'll add it to the end of the list. Depending on the time of year, it can take up to a year to actually get to some of the suggestions. All that being said, I'll respond to your specific suggestions... We have featured every one of these airports except HDN, TEX, and CPR previously (sometimes the exact citypairs as well). Class E airports are not possible for Rc events because of the one-in one-out IFR rules (there can only be one IFR aircraft cleared for an instrument approach or with a departure release at a time, meaning everyone else has to wait in holds or elsewhere). Others (like KDEN to KRNO) are too long: Regional Circuit events longer than about 250nm tend not to work very well. I'm not entirely sure why, but events like KLAX/KLAS tend to be exciting only for radar controllers while _Cl and _G controllers are waiting for airplanes en-route. It may seem strange to do shorter Rc events (like last night's), but the more time airplanes spend with TRACON controllers (and the more time they spend moving on and around airports), the more exciting things are for controllers. I'm assuming that most pilots -- like me -- prefer interacting with busy controllers rather than saying "hello" to a Center controller and then waiting 45 minutes before their next instruction. This varies as well...some events are totally one-way (for example, if we do a KBOS-KACK event, most pilots spawn at KBOS and fly to KACK). Others, like last night, tend to be somewhat even. We've tried things like a "tri-city circuit" before where three airports were controlled. What tends to happen is that pilots fly to two of the airports and the third gets no traffic. Or, we see not enough traffic to support all three and, while there's steady traffic throughout the event, nobody is overly busy. We have also tried more major events. You just missed the Washington HTC where we featured KIAD, KCHO, KORF, KPHL, KACY, and KRIC, but we're featuring another HTC in Chicago on February 6 so you can get an idea how those work. Again, we saw that, while we had a fair bit of traffic, it was dispersed enough that, while steady, controllers weren't swamped consistently. That's why we've removed one airport from the list for the next HTC. I would welcome a few pilots flying out of other airports, towered or otherwise, during events. However, you have to remember that when you choose to do that, you lose out on interacting with three controllers waiting at a staffed airport. Again, it comes down to trade-offs. Great suggestions. We've done PHL to ISP, LGA, and HPN before, as well as LGA to ACK/MVY. However, I'll add a few of these to the list. I hope I've given you an idea of how events work and the range of possibilities that have tended to work in the past. That being said, I'm certainly not trying to 'shoot down' any of your ideas. If you have citypairs that are 50-200nm apart that you would like to see, please list them here. Alternatively, if you have other event ideas, please post them. Some may have been tried (successfully or unsuccessfully) but all of our new ideas come from somewhere. Feedback is always appreciated!

My mistake! Thanks for pointing it out -- I've corrected the page.

(Anyone who has already signed up for the HTC, unfortunately there was an issue with the page today| please add your name to the chart again)

It's pretty late to be making changes to the event| there has already been quite a bit of planning that has taken place. Pilot sign-up is open and controller staffing will begin shortly. I would rather not make major changes to the event at this point. Had you posted this before pilot sign-up and advertising had begun, it would have been much easier to make a change. That being said, we have already removed one airport from the list. We did 6 airports (inc. KIAD) for the Washington HTC| we're featuring 5 total airports this time. The concept of 25 pilots inbound and outbound was voted on by the community and approved by our controllers. Again, I'd rather not make that change unless another event proves that we need to make a change. Remember that we've really only held one event and it was not as well-attended as many of us had hoped. Before we start making wholesale changes let's see whether we're seeing a consistent issue or a one-off. I'd be happy to consider your changes if you and others feel that this next HTC is not particularly intense. Hope to see you in Chicago!

Right...well, based on the poll results, we'll have to give a weather-specific event another shot sometime this year.

I've merged the two topics related to a weather-specific event into this one. I was hoping the poll would remain but unfortunately not. However, users can continue to vote in the poll on BVA's homepage (I think the results are already quite similar).

I've never been a fan of creating weather (actually, I don't really know how to do it with FSX...I would use ActiveSky if I wanted to, but that's beside the point). As Brandon has suggested, this type of event creates several logistical issues. For one thing, the server would also have to be reset to real-world weather after the event| you can't change weather conditions without re-starting the server and ejecting all pilots. By the way, ATC does not see weather on radar screens, so there could be no creative vectoring. If the server is set to real-world weather, I'll sometimes use real-world weather imagery and try to vector pilots accordingly, but that's obviously not possible if we've set the weather to something custom. If you can get 10 responses, (not including those here already) that indicate that there's interest in a special-weather event, then we'll do it.

Consider it done.

The majority has spoken...and the SoCal Getaway has been extended through to October 22 (this Friday will be our last day in SoCal this year). I'm locking the topic because it's the only way I can find to actually stop allowing people to respond to the poll without deleting it altogether.

A few people have approached me about extending the SoCal Getaway so they can continue to enjoy the new airspace for a few extra days. Please let us know what you think about extending the getaway...the decision (based on this poll) will be made around 11pm ET. Happy voting!

This sounds exactly like the Domestic Journey but perhaps you were suggesting having the pilots fly two-way routes instead of the one-way trip. The difficulty with longer events is that, without a very large pilot turnout, they are incredibly boring for ATC (and some pilots too). For example, during our LAX/SFO event with about 24 pilots at the peak, all the controllers had very little traffic because most of the airplanes were actually in the air with the two Centers. In general, I have noticed a lower turnout for even the most popular longer-distance Regional Circuit routes. LAX/SFO had two Center controllers.

That's mostly (but not always) possible. For example, at KBOS, depending on the runway configuration, any of the LOGAN4, WYLYY7, or SSOXS1 might be used for someone departing to the south| this isn't something that would be known until the event starts because they vary based on the configuration of the airport. However, in most cases, there's one departure procedure that will be used, and in those cases, I will definitely add the SIDs/STARs to the textual preferred routes.

As a note for those who are unaware, you cannot call the tow plane in FSX's multiplayer mode -- it leads to glitches on the server.

Fixed... sorry, and thanks for letting me know!

I thought we left off that discussion saying you were going to contact Bill to see whether it was feasible. From my perspective, I think it's a good possibility.

Ok, so once again, correct training but incorrect delivery. The correct procedure is to have the aircraft advise clearance delivery when ready to push and subsequently have the aircraft monitor ground. If the "monitor ground" was given right after the correct readback, it was clearly wrong.

True, except many aircraft are not immediately ready to pushback after receiving their verbal clearance (they re-program the FMS, set up the airplane, etc.). When they are actually ready, they contact the clearance delivery controller to pushback (like they would after receipting a PDC) and are instructed to "monitor". Am I missing something?

I'd say don't report, unless you're specifically asked. If a controller says "report over MHT", then do so, but otherwise we're probably watching you on the live map (or maybe you're un-glitched) and it's probably not going to be worthwhile. If some controllers choose to try the 'without radar service procedure' (actually, there are still a few airports around without radar service in some less-developed parts of the world), they'll let you know what to do.

Thank you for listing some of your observations. Last night's event was a bit of an experiment from the controllers' perspective. For the past 2-3 events, we've had a lower turnout than usual (around 20 pilots), and I assumed with the KBOS-KBTV run last night, we'd have the same scenario. As a result, we had a lot of newer controllers online. Boston Clearance and Ground were working together for the first time, BTV_G was a brand new controller, and BTV_A was controlling his first Regional Circuit as Approach (I think). Our very capable ZBW_C had only controlled that position once before (but Center is an event is drastically different than on a regular night, because normally there won't be any aircraft flying to non-staffed fields during events). Even though each of our students was being listened to by a mentor, the pilots came out in full force and may have overwhelmed some of us. My normal rule is that we do not train during events. I thought I could break it, and we weren't going to be too busy. I was wrong. The pilots came out in full force last night, and you guys may have even scared off a few of our controllers (technical issues with a microphone may have contributed to that a little bit as well). That being said, let me answer a few of your specific points, because I believe they are not systemic errors (i.e. problems with the way we train or the procedures we follow) but rather specific examples of deviation from the norm. This is the real-world procedure for KBOS. Because most gates at the airport require aircraft to either pushback onto Taxiway "A" or into a small ramp area, the FAA allows Boston Ground controllers to act as a pseudo-ramp control and actually authorize almost all pushbacks (with the exception of the Delta company ramp, as well as the Signature/North GA/Cargo ramps, which have their own controllers). In order to avoid overwhelming the one Boston Ground controller, the real-world procedure at KBOS is for Clearance Delivery to tell aircraft to "monitor ground .9" when the are ready to pushback. If you listen to LiveATC, you'll hear it| you'll also hear Boston Ground issuing pushback instructions without having been called by the pilot. You can review the KBOS SOP on our Air Traffic Control page if you want to see BVA's official policy. Our controllers are trained to the real-world standard, and that's what SHOULD have happened. You probably fell through the cracks... someone forgot to edit the "Remarks" section of your flight progress strip and ground never got the message to instruct you to push. Actually, when I heard you call ground and ask him why you weren't contacted, I believe I spoke with both Ground and Clearance Delivery to try to figure out what happened. Despite being a "Pilot Tip of the Month" in a recent Logan Informer, several pilots still contact when they should monitor (last night on BTV_T, a few people called me when they should have just been monitoring... that contributed to the chaos that ensured when I had to quickly step up to BTV_A). That's probably why everyone else was calling instead of waiting for Ground to call them for push. As it turns out, they should not have done so. In other words, in this scenario, the correct, real-world procedure was delivered incorrectly by the controllers online last night. By the way, the correct procedure to follow (or at least, what I've heard real pilots do when it's busy) if you are instructed to monitor a frequency but receive no response is to go back to the previous frequency (on COM2 so you can hear if the controller you are monitoring does call you) to check with that previous controller. For example, in your case last night, you would have gone back to BOS_Cl, asked whether Ground knew you were ready to push, and the controllers would have sorted you out. What you did was totally fine as well because, at the time, BOS_G's frequency wasn't too congested. I WISH, I WISH, I WISH we knew what caused the glitching and what we could do to fix it. But I haven't found a solution just yet. It doesn't seem to happen more or less when it's busy, seems to affect some people but not others (and yet not be related to internet), can sometimes be corrected by temporarily pausing a session, but is (almost) always solved when another member leaves the session. In my opinion, what happens in a 'glitch' scenario is that the server stops sending out updates to the glitched aircraft's movement (either because of a bug on the server, or because for some reason the glitched client has stopped sending out this information... my money is on the server, explanation coming below). Thus, the glitched aircraft continues to do exactly what it was doing when these updates stopped. For example, if you are flying on heading 350 and climbing at 2,000' per minute when a glitch starts, you won't turn or change your rate of climb. I've seen people well over 1 million feet. Strangely, it seems some glitches only affect controllers -- other pilots see the aircraft fine while controllers do not -- and sometimes a plane will be glitched for everyone. When the glitch is resolved -- again, normally when a player leaves the session, but sometimes if the glitched player pauses -- the server starts once again sending out updates to the client. They jump back into position on our radar screen and continue as normal after. During a glitch scenario, however, the server never loses the aircraft. Check BVATC Live! -- that map is fed directly from the server, as are FlightDesk's tracking updates if FSX is closed. The tracking updates and live map show the aircraft correctly, but other FSX clients do not. That's why I think it's a server bug that causes the server to stop sending out the glitched pilot's updates, and not an issue on the client side. In other words, the data are getting through to the server, but aren't coming out the other end. Again, if we knew why, we might have a solution. That explains what a glitch IS. Since we can't say what causes it, it's difficult to place the blame on FlightDesk, easy or helpful as that may be. Furthermore, I understand that Bill has carefully designed and re-designed FlightDesk so as to take up very little bandwidth and CPU usage. He describes himself as a performance freak, and every letter of code he writes is influenced by keeping performance impacts minimal. I've seen glitches happen for AGES, starting before BVA even used FlightDesk. If it's any consolation, they seem to happen to a small group of people consistently but then stop and never come back. A few months ago, controllers would tell me that I'm glitched almost every session. I haven't heard it for a little while now. I wish I could tell you what to do when it happens, or how to avoid it. While restarting your router, re-installing FSX (and in fact the entire OS) from time-to-time, and making sure to run FSX in multiplayer mode such that it's not maxing out your CPU are going to help things anyway, there's no evidence to support the theory that you can resolve or stop glitches from happening by doing any of those things. One thing I have noticed is a considerably better connection to the server -- better voice, smaller chance of getting disconnected randomly -- when settings are not maxed out. There are some members that control for long periods of time but are disconnected after only short flights. I wonder if their settings and CPU usage is dramatically different when they are controlling vs. flying. I know I always tune down my visual settings when I'm doing ATC and the scenery/frames don't matter. I also lock my frames at the lowest possible level when controlling. So what is this glitch crap? I wish we knew, and I wish we had a solution. Since we don't, our controllers try to handle it as best we can, but it can be difficult and frustrating to deal with sometimes. Actually, we do have an informal procedure that controllers should use. In my case, I'll look at the BVATC Live! map right away. Since glitches never manifest themselves there, you can get basic information about the pilot's heading and altitude. Of course, it's impossible to vector someone for an approach using the map, but it's very possible to keep that aircraft separated from others using it. Normally, glitches resolve themselves before I need to start vectoring for an approach, but when they don't, I'll use the live map to maintain separation while I vector someone for delay, or even put them into a holding pattern (like I did to UAL340 last night, the only glitch I saw during the entire Rc). In the case of ZBW, perhaps he was looking at you on BVATC Live! or in FlightDesk, and thus didn't need the position reports. Perhaps BOS_A was not looking at those tools, or just preferred to have you report a waypoint because he was less busy. In every case, controllers hate the fact that glitches happen. Imagine looking at a radar target thinking you have plenty of time to turn/descend someone and then the aircraft suddenly jumps 40 miles and 8000'. Or to issue someone a climb but see them descending 5,000' below the ground. It's difficult to handle. It's worse when you have a no-radar scenario with an aircraft you need to vector to final. Recognizing that glitches are as confusing and frustrating for pilots as controllers, we try to avoid mentioning them as much as possible, and do our best to work with the pilots and provide them the ATC services they need without interruption. Nobody wants to be stuck on the ground holding short of a runway in FS because controllers can't see where they are. Sometimes, if you un-glitch right when you change to a new frequency (or if the previous controller is too busy to alert the next of a potential glitch), we won't remember or know to tell you that you are back on the screen. Normally I will "radar contact" someone a second time if they were previously glitched, but it's the last thing on our minds when it's busy. Normally, we're just thrilled we can see where you are again. The controller on BTV_A last night was (I think) controlling Approach for (one of the) first times during an event. I was going to try to listen in and help, but, as I said, I wasn't expecting him to be as busy as he was. Between the terrain restrictions, a small sector, and the traffic, BTV_A was a difficult position for anyone (even me, as I quickly found out when I had to take over roughly halfway through the event). For some reason -- I'm assuming a technical problem -- our BTV_A was unable to respond to pilots, and I had to take over and clean up the resulting mess. I ask you to give Josh (BWIA) the benefit of the doubt that there was something he couldn't deal with, and support his attempts to continue to control in the future. I will be working with him at the next chance I get to figure out what went wrong, and how we can prevent it in the future. I hope that helps, and thank you again for your comments. In most cases, I think we're dealing here with deviations from the standard rather than standardized deviations from what you might expect, perhaps excepting the glitch scenario, which isn't something you can deal with realistically at all. If you (or anyone else) has suggestions or comments as to how we can improve the standard procedures we follow, I would be glad to discuss them with you. Without the experience of actually controlling, and understanding how frustrating it is when glitch scenarios occur, it's difficult to understand the operational restrictions on some ideas... which is why discussing them with a base of controllers that experience that almost daily is an important step to finding a solution. Thanks again for flying -- and discussing -- last night's event. We'll be going down to Florida for KMCO & KMIA on Tuesday. I'll do my best to staff it with a more experienced crew... you (pilots) see if you can overwhelm us again!