Popping into my layout room the other day with no real purpose in mind, I spied a note on one of my staging yard switch panels. The note was reminding me to relabel the panel to clear up an inconsistency between adjacent yard panels.
I have three staging yards (left) along one wall of my layout room stacked one above the other and the 4-yard panels for the three staging yards are similar for each yard. Each panel has a rotary switch to choose the proper staging track. This makes picking a staging track pretty straight forward for my operating crews at the Pittsburgh & South Pennsylvania (P&SP) RR.
So why the note? It seems that for some reason unbeknown to me, I labeled this panel for the middle yard, Wheeling Staging, showing yard track #1 on the wall side of the shelf, whereas the other two yards had track #1 as the first track on the aisle side of the shelf. This inconsistency had not caused major problems but it had caused confusion from time to time if an operator failed to look at the yard panel track diagram before picking their track with the rotary switch, hence the note to self to fix it someday.
I try to remove inconsistencies from my railroad’s infrastructure when I see they create confusion. Operators are busy enough minding their schedule and deciding whether they have the authority to make their movement.
Making the change was rather easy. I used a piece of an old credit card to remove the dry transfer labeling (left) from the track and rotary switch areas and I repainted the rotary switch area.
I waited a day to let the new paint around the rotary switch area dry. The dry transfers were applied and then over-sprayed with dull cote (below) to protect them.
Total time to make the change; about two hours of puttering around. Another inconsistency was cleared from the P&SP.
For this article, I have used the term “informal operating systems” to differentiate less structured approaches from prototype-based operating systems. Steve King has used the term “fun run,” but I feel that term, while easily understandable, does an injustice to both approaches to operations. Those interested in prototype-based operations would not participate if they were not having “fun,” and those, who prefer a more relaxed experience, still want to learn about how the prototype does things. Consequently, I find the term “informal operating systems” more useful and less pejorative.
In Part 1 of this article, we learned that adopting an informal operating system does not always result in the relaxed experience desired. In Part 2, we want to figure out how to establish some basic organizing principles for informal operating sessions and then find ways to communicate those principles to crews (in order to give them the information they need to do their jobs).
Basic organization: To avoid chaotic situations, any operating system must have some basic level of organization; however, the effort to organize operations can seem quite formidable, full of big issues to be addressed – kind of like the big task of getting a coal drag up a steep hill without helpers. I would like to make some suggestions to make that process a bit less intimidating.
First, remember model railroading is not a matter of life and death; it is our hobby.A layout can still be fun even if the operating system is not organized as completely as we might want it to be.
Second, getting organized is a process. I suggest you take it one step at a time:try decisions out, see what works (or doesn’t), make adjustments, and move forward from there. (Repeat as necessary.) If you do that, you will find yourself less intimidated. (Remember friends can also help you see things from a different perspective.)
How do we figure out what step to tackle first?My suggestion is to start with a series of six fairly straight-forward questions that focus on the trains you want to run. This approach sidesteps big issues such as the railroad’s purpose, goals and objectives for sessions; an appropriate level of traffic management; a sense of time as it relates to the session; and a system of car forwarding. Once you get operating, ways to address those issues are likely to reveal themselves.
The following is a sort of Abbott and Costello list of questions. (Remember “Who’s on first?”)Hopefully, this list is a bit less crazy.
Why does this train run?
Who runs this train?
Where does this train run?
When does this train run?
How do you run this train, and how do you coordinate its work with the work of other trains?
What happens to the cars in this train?
How can you come up with answers? Before you actually ask the six questions, what process will you use to find the answers? First, it is best not to concentrate on possible consequences of your answers. Remember you don’t have to get the “right” answer the first time. Second, you do not even have to come up with your own answers. Through the years, model railroaders have developed numerous ideas for addressing these matters; you do not have to reinvent the wheel. Let us take a quick look at some ways you can find possible answers:
Research: You can learn what the prototype and other modelers have done from reading articles in model magazines. I recommend articles about both model and prototype operations. Learn how modelers and prototype railroads have dealt with these questions. Some of the articles may be useful; others not. Try out what seems best. Note that this research may result in your reading articles advocating more formal prototype-based operating systems than you are looking for if you are considering informal systems. Read some of those articles anyway to get a good idea of the organizational issues prototypes and other modelers have dealt with.
Your operating experiences and preferences: What have you experienced in sessions on other people’s railroads? What did you like (and wish to include in your system)? What did you not like (and wish to avoid)?
Your crews’ experiences and preferences: Talk with the people most likely to be crew members, and find out what they prefer.Take that information into account, but do not let it override your ultimate goals and objectives for operating sessions. (SMD member Don Florwick began operating with a crew who preferred informal sessions, but that wasn’t what he had envisioned for his railroad. He used those informal sessions to work out the bugs and then moved on to a more formal TT/TO system.)
Once you have some tentative, first answers using steps A – C, you can then move on to steps D and E. Remember that finding answers is a process; so don’t be frustrated if your first efforts prove unworkable. Set unworkable answers aside, and try again.
Trial and error/beta testing: Start using the rough answers you have. Be patient. (SMD members Pete and Jane Clarke spent years operating their HOn3 East Broad Top, constantly refining their system, until they arrived at the system they use today.) Do not be afraid to make changes to correct things that are not accomplishing what you want.
Feedback from your crews: Remember they have different expectations and experiences from yours. Take advantage of that fact as you refine your answers (and eventually your operating system).
Elaborating on the six questions: Now, let us look at the questions again in more detail, and figure out how to find answers and communicate them to your crews.
Why does this train run? What is its purpose? What does it do? What customer(s) does it serve? Since your railroad is different from everyone else’s, the trains you run will be unique in some way.Each of those trains has its own special role in developing the overall concept of your railroad’s purpose and the operating session’s goals and objectives. Answering the “why” questions will also give you an idea of how this train fits your railroad’s overall scheme.
Once you have determined each train’s purpose, the best way to share that purpose with the crew is with a brief train description at the beginning of the train instructions. A sentence or two should suffice – something short enough for the crew to read before beginning their run.(Remember the hubbub that accompanies the start of every operation session).
Who runs this train?This is a two-pronged question.
Was the layout designed for one/two operators or for a large group? The answers lie in the design of your layout: for instance, the size and capacity of the aisles, the kind of railroad, the number and spacing of towns served, and the expected number of trains to be run in a session. After you have answered these questions, you can use those answers to determine how many crew members you need for your sessions and how many you can accommodate.
Once the crews arrive, who gets assigned to a specific train (or job)? Will you assign by arrival order (first there gets first choice), by experience (such as assigning veterans to dispatching and yard master positions), by sign-up sheet, etc? You have to decide and let your crew know in your orientation briefing.
Where does this train run? Where does it start from; where does it terminate?Where does the train have to go in order to do its job? Where does it interact with other trains?Your answers to the “why” question will point you in the direction of answers to these “where” questions. After you figure out answers for one train, move onto the second, third, and so on.Since this question relates to the “when” question, you may have to revise the answers later on.
For crews, “where” questions should be addressed briefly in the train description (especially where the train originates, works, has meets, and terminates). Somewhat more detailed answers can then be provided in the body of the train instructions. (Remember, at the beginning of the session, it is best to keep the amount of required reading minimal.) Additionally, crews need help orienting where they are within the layout room. They need schematic layout diagrams/maps (giving place names and yard locations along the main line), location signs at those places, as well as more detailed diagrams/maps indicating where specific tracks and industries are. It is crucial that the names of these places be consistent with names used in paperwork.
When does this train run? For informal operating systems, time is perhaps the most complicated question because getting away from the pressures of time is one of the main reasons for taking the informal approach in the first place. Unfortunately, you have to address the time question. Easy prototype-based answers like clocks and timetables are likely to be too formal for you and your crews; so you must come up with a way to determine when a train should be on a given track.(Otherwise, collisions will happen.)
To do so, you will probably need some sort of rough schedule. That can be developed before regular sessions begin and later reflected in the instructions given to crews. (They may not ever need to consult the schedule.) To develop a rough schedule, you should start by making a list of trains in the chronological order you want them to run. Then, you will need to find out how long it takes to run each train in order to figure out when and, consequently, where that train will meet other trains. These are trial and error investigations that you can make before regular operating sessions begin. (Be aware that there may be more stress than desirable during this testing period, but keep in mind that you are trying to find ways to eliminate that stress when you move on to your regular sessions.)
Over the years, we model railroaders have come up with quite a few ways to address the time issue without going to the lengths to which the prototype goes. Among the options we have tried are verbal authorization (mother, may I? sessions), sequence schedules (trains in chronological order), operating scripts (think of Frank Ellison’s comparison of operating sessions with scripts for plays), and train instructions. Some of these work better than others as discussed in Part 1. (Regardless,, there are numerous options to choose from. I plan to discuss some of them in future articles.) To my way of thinking, how you answer the time question is crucial if you want to develop a relaxing, informal operating system for your railroad.
Your best way to give crews time-related information will be the detailed train instructions (following the initial description of why and where the train is run). Be clear and complete.Remember crews won’t see the schedule.
How do you run this train, and how do you coordinate its work with the work of other trains? Start by focusing on each train separately. Figure out how it should do what it is supposed to do. Then factor in how the operation of other trains will affect the one you are considering and make adjustments. Beta testing and trial & error are good ways to develop detailed, coordinated answers for these questions. Again, detailed train instructions are the informal way to communicate this information to crews.
For crews, “how” becomes a two part question:
How a crew runs this train is best conveyed by the train instructions. The level of detail in the instructions relates to the kind of session you want: one that expects train crews to read lengthy, instructions with lots of rules to follow or one that is more relaxed and open. Bulleted directions, grouped under headings for each of the places where events happen, are one way to simplify train instructions and to make them easier to read one at a time.
How a crew coordinates its train’s work with the work of other trains relates to the places (where) and times (when) trains must interact with each other: passes, meets, and multiple trains working in the same location. You want crews to have a basic familiarity with what is happening during the session (especially as it relates to their train) without having to consult a complicated timetable. Again, good train instructions can provide sufficient information and clear up any required matters of train superiority. Unexpected situations can then be handled by train orders (verbal or written).
What happens to the cars in this train? Clearly, you will need some sort of car forwarding system. We model railroaders have quite a few of these from which to choose: car cards and waybills, switch lists, color-coded tacks, car-for-car exchanges, etc. Based on your experience and preferences, choose the one that seems best suited to what your railroad does, then try it, and see how it works. Try another system if the first does not work out. Revise as necessary.
For some kinds of traffic (passenger trains and unit trains, for instance), train instructions alone may serve; however, for general freight traffic, you will likely need a more detailed system giving crews specific directions about where to spot and pick up cars as they run their trains. In setting up a more detailed system, try to keep the information you give crews as brief as possible: type of car, reporting marks, number, and destination may be all the information they will need.
Conclusion: The questions I have suggested are one way to focus on the trains you wish to run and to use those trains as a start to organizing the larger operating system for your railroad. As I said earlier, this approach sidesteps the big issues, but beginning to operate is likely to reveal ways to address those issues.
One important thing to note about the process of answering these questions is that the answers you come up with do not necessarily have to be shared in their totality with your crews – for instance, the rough schedule you developed to answer the “when” question. Your crews probably will not need to refer to that schedule during the actual session – especially if they have train instructions telling them when and where to meet other trains. In other words, your railroad can have a whole layer of “complicated organization” of which your crews can remain blissfully unaware.
With these questions spelled out, we have come to the end of this article and, hopefully the beginning of your quest for the operating system that is right for your railroad. What we have discovered is that setting up an informal operating system is a bit more complicated than we might have imagined. We have realized that just because we want to run trains in a relaxed fashion, we still have to address some basic organizational questions in order to give crews the information they need to get their “jobs” done. The prototype had to answer these questions; so do we. Your goals may be different from the prototype’s, but by answering these questions, you can develop enjoyable, relaxing sessions for your crews (and in the process, give them opportunities to experience and learn more about what prototype railroads do). You want your crews to operate in a calm, “professional,” capable, and relaxed manner.
If you decide an informal operating system is right for you, you will probably want to know about specific alternatives to prototype procedures. Some of these alternatives may not be widely known. For instance, you may have experienced the often chaotic “Mother, may I?” type of session and want a more “professional” type of session. (In this case, perhaps, a “dispatcher, may I?” approach will work better.) Or you may be familiar with formal train orders (prototype-based), but not aware of fill-in-the-blank train orders (more informal).
For this article, I have used the term “informal operating systems” to differentiate less structured approaches from prototype-based operating systems. Steve King has used the term “fun run,” but I feel that term, while easily understandable, does an injustice to both approaches to operations. Those interested in prototype-based operations would not participate if they were not having “fun,” and those, who prefer a more relaxed experience, still want to learn about how the prototype does things. Consequently, I find the term “informal operating systems” more useful and less pejorative. (At the recent NMRA National Convention in Salt Lake City, there was a clinic titled “Operations without the Aggravation.” I find that also an effective way to label less formal approaches.)
Over the years, we have all been harangued by articles and clinics touting the benefits of prototype-based operating systems (TT/TO, track warrants, etc.). The main reason given is that prototype railroads have developed, tested, and refined these systems for many years in the real world, addressing the many situations that come up when operating a railroad. Why would anyone want to re-invent that wheel? Clearly, developing an operating system is not a simple task. Why not use a system already developed and tested?
While this argument is very convincing, it ignores an important fact – prototype operations are very different from model railroad operations. First, prototype railroads are businesses; model railroads are part of our hobby. Second, prototype railroading can be deadly serious; model railroading is supposed to be fun. Third, prototype railroaders are trained professionals; model railroaders are, for the most part, interested, sometimes informed amateurs. Whatever system of operations we choose, whether prototype-based or other, must address these differences.
The goals for prototype-based versus informal model railroad operating systems:
Prototype-based operating systems:
To experience operating the model railroad as closely as possible to the way we might experience operating the prototype,
To have an enjoyable and challenging experience with people knowledgeable about railroads,
To meet the session’s challenges with the tools developed by prototype railroads, and
To replicate the work prototype railroads do.(Creativity is not OK.)
Informal operating systems:
To experience the model railroad in a railroad-like fashion,
To have an enjoyable and relaxing experience with other people interested in railroads,
To pretend we are professional railroaders (somewhat like re-enactors) and, from that effort, to learn things about prototype railroading, and
To find solutions to the situations that come up without having to make efforts that are too much like work. (Creativity is fine.)
While these two sets of goals are not completely different, the emphasis certainly is different between them. Those differences greatly affect the operating system appropriate for a given model railroad. It may have been designed for prototype-based operations, and then again, it may not have been. Crew members may be interested in the challenges of prototype-based operations, or they may be more interested in a relaxing, enjoyable time spent with friends and acquaintances. The prototype being modeled may be a heavily trafficked mainline, or it could be a backwoods branch with two trains a day. Each of these sets of circumstances warrants a “custom” approach.
Prototype railroads understand that fact and address different situations with rules customized for each region and each operating district. “One size fits all” does not work for the prototype; unsurprisingly, that approach does not work for all model railroads either.
Problems with prototype based operating systems: Crews not interested in prototype-based operating systems have voiced numerous complaints. The following are some of the characteristics of prototype-based operations that superintendents might want to avoid:
Too much paperwork: During the often hectic flow of the session, it is often impossible to find time to read, much less deal with, a sheaf of papers, especially when the piece of information needed is buried where it cannot be found easily.
Hard-to read paperwork: The effort to make keep instructions and information easy to handle, often results in making them unreadable except with a magnifying glass. Also handwritten entries on forms are often illegible.
Rule books – too much to remember.
Clearances: Written clearances are an example of excess paperwork.
In-depth pre-session introductory material and long verbal orientations – again too much to remember.
Timetables, clocks and fast time: Crews want to watch their trains, not the clock (too much like work). Besides, a timetable is not easy to read while trying to run a train.
Reporting requirements: Having to pick up the phone or radio every few minutes can be quite distracting.
Complicated train instructions: Brevity and simplicity should be the main goal. Crews should be able to find what they need to do easily.
Train orders written in “railroad English:” Prototype railroaders would understand; model railroad crews might not.
Car forwarding information: Whether car cards, switch lists, or other systems are used, there is often much more information than needed. Also, carrying a large stack of cards around is always a challenge.
Undoubtedly, there are other problems crews might have with prototype-based operating systems, but the above list will suffice for now. (As will be discussed below, some of these items are essential for running a railroad.)
Problems with informal operating systems: After considering the numerous problems common to prototype operating systems, it is tempting to conclude that, by adopting an informal operating system, we can address all those issues and eliminate the things to which crews might object.
However, informal systems come with their own set of problems – a couple of them major. 1) By adopting informal procedures, we have essentially discarded the administrative organization that works so well for managing prototype traffic.
2) Crews may not have the information and directions they need to do their jobs. Between these two problems, it is almost certain that difficulties will arise. The following are some of the potentially maddening situations that develop when using informal operating systems:
Sessions degenerate into confusion: This is perhaps the most serious criticism of the Mother, may I? operating system. Crews (sometimes behaving like spoiled children) all cry out for the host’s attention at the same time. As the number of problems encountered multiplies, the volume of cries increases. The host has far too much to deal with; the session becomes a confused mess.
Situations get resolved without taking into account the railroad’s overall objectives: This problem arises when crews take it upon themselves to resolve a conflict by gentlemen’s agreement – such as the problem of too many trains in one location. The resolution may be quite creative; it may be quite satisfying. But, if the through freight gets held up by the local, that resolution is not the right one.
Worst of all, the crews involved miss an opportunity to experience how the prototype might resolve a similar problem.
Crews blithely unaware of anything but their own train: That might work on a backwoods branch or a one-train-a-day shortline, but when more than one train is running, crews need to be aware of other trains and to coordinate their efforts with those of other crews. (This issue also comes into play when crews have to share aisle space.)
Operating systems that do not address all aspects of operating the railroad: For instance, some layout owners consider having a car card system to be the same as having an operating system. That approach does not consider traffic management, and the car cards lack much of the information crews need to do their jobs. Crews have no sense of time, no information about other trains, no understanding of the superiority of trains, and no authority to use a specific track (in fact, no instructions about which track their train should be on). Confusion reigns. Of necessity, figuring out how to do a given job becomes the primary effort for the session. Enjoyment comes in a distant second.
The result of these situations can be an atmosphere of “chaos,” an atmosphere not conducive to having a relaxing, enjoyable time. Because crews do not have the information they need to do their jobs, they feel uncomfortable. They cannot enjoy themselves – the main reason for adopting informal operations in the first place.
What have we learned? Prototype-based operating systems come with quite a few rules and procedures: things that crews looking for a relaxed operating experience might object to.Adopting an informal operating system seems like a good way to avoid those objections. But informal systems often cast aside the organization needed to run a model railroad and often fail to give crews information needed to do their jobs. The result can be chaotic, quite the opposite of the relaxing, enjoyable experience desired.
Adopting an informal operating system does not have to degenerate into chaos if some effort is put in place to establish basic organizing principles and to give crews the information they need to do their jobs.
Part two of this article will endeavor to discover ways to correct the deficiencies of informal operating systems and will open discussion of the enjoyment possible when adopting such informal systems.
This January fourteen members of the South Mountain Division responded to an invitation from Mat Thompson, MMR to operate on Mat’s exquisite Oregon Coast Railroad. We had a wonderful time and thank Mat for sharing his wonderful railroad with us. This was my 4th visit to Mat’s railroad. This time Mary Miller, MMR and I were assigned to work at the Swift Packing Plant. We had a blast, hence this article.
Mary and I begin our session at Hoyt Street Yard. The yardmaster showed us our Oregon Coast train. Behind our switcher we find a cut of 8 cars billed to the packing plant consisting of 4 empty reefers, 3 loaded stock cars, a box car of packing material, and a caboose.
The Swift Packing Plant is located along the railroad between the Hoyt Street Yard and Willbridge, 2 railroad miles away. As an extra, all scheduled trains are superior to us and we have to carefully pick our time to leave the yard for our run on the single track main to reach the plant. We receive a clearance from the yardmaster and, after checking our timetable for superior trains, we pick our way out of the West end.
Before reaching the plant siding we notice a double ended siding along the main, used for outbound traffic to be picked up by passing freights or another switcher out of Hoyt Street. This day, a yard switcher will service the siding during our 8 hour shift; taking our outbounds while delivering more empties and loads.
Just short of Willbridge, we pull our string slowly ahead until the caboose clears the siding switch and glide to a stop. With the switch lined for the plant, we back our string of cars slowly down the siding, clearing the main.
A mailbox at the plant holds special instructions for us, from the customer, so that cars are spotted correctly and in a timely manner, ensuring plant operations proceed smoothly despite our inexperience with this job.
Reading the instruction provided by plant management, we discover that it takes 21 minutes to unload a stock car at the stock pens on track-2. It takes about an hour to load a clean chilled reefer at the plant on track-2, and about 2 hours to ice and chill a block of reefers on track-1 at the icing dock. We also note the track diagram provided so we can find our way among the maze of tracks at the plant.
Looking at the diagram, we note that track-3 runs along the back where supplies are offloaded for the packing plant. Track-4 is a service track and track-5 is the cleanout track for reefers. There also is a short runaround track on the ladder between tracks-3 & 5. Note the presence of another stock yard on the property. We were pleased to see there was plenty of head room on the lead to switch the plant without fouling the mainline.
Let’s get started spotting the 8 cars we brought to the plant this morning. You recall we boldly backed into the plant without thought, to clear the main while we looked over our instructions and developed a plan for our first service switch. At the plant we found 1 reefer loaded on track-2, at door-5 and 3 reefers iced, chilled and waiting at the ice dock on track-1. We noted there was one empty box car at door-5 on track-3 and a loaded tank car of tallow spotted near the oil tank, billed outbound.
Once oriented, we devise our plan. Here is what we did. First, we pulled our string forward to clear the track-4 switch, then we backed onto track-4 to drop our caboose. Pulling forward to again clear the switch we lined it for the ladder and backed our 4 reefers onto track-5, the cleanout track, and cut away. We then left the remaining 3 loaded stock cars short of track-2 and moved to track-1 where we pulled the 3 iced reefers over to track-2 and shoved them down to doors-1, 2, & 3 for loading.
There were three timers provided for our convenience so we set one for 20 minutes.That would use exactly 1 hour of the 3:1 fast clock time for loading. We then came back to the lead and grabbed the 3 loaded stock cars and swung them over to track-2 at the pens. We had 40 foot stock cars so each had to be individually positioned at the unloading shoots that were spaced for 50 foot cars. Once in position we set the second timer to 7 minutes, giving us 21 minutes of fast time for unloading.
Moving to track-5 we pulled our cleaned reefer string to move them to the icing dock on track-1. We set our third timer for 40 minutes giving us 2 fast clock hours for icing and chilling. Pulling off the icing track, it’s back up the ladder to track-4 to pick up the loaded box car for door-6. Coupled up we move West down the ladder to track-3.
We pick up the loaded tank car and empty box from door-5, then out to the ladder again, backing East to drop the box and tanker against the caboose on track-4 and cut away. We then spot the loaded box we had keep near the engine at door-6, on track-3.
Stepping back to asses our progress we find we have spotted the entire cut of cars we brought from Hoyt Street Yard. It’s now time to build a cut for the interchange. Checking our timers we see that our stock cars have been unloaded and the other timer for the loading dock has expired so the 4 reefers on track-2 at the plant are also ready to be pulled.The interchange track will hold 8 cars, so we back down to track-4 and pick up the tank car of tallow. Next it’s over totrack-2 for all three empty stock cars. We also grab the 4 loaded reefers.
Once we had everything on track-2, we had our cut of 8 cars. Pulling up the spur to the company phone and after checking our timetable for scheduled traffic we called the dispatcher to ask if we could have time and track to pull out onto the main and drop our string onto the double ended siding for pickup.
The dispatcher gave us track time after passage of a scheduled freight. We waited 15 minutes for the freight to pass, notified the dispatcher, then pulled onto the main and made our backing move to the siding. Surprised, we find a new cut of cars awaiting us. You can imagine our movements, making the car exchanges along with the time it took plus returning to the plant siding with a new string of cars.
We have now completed one servicing of the plant. The new string of cars picked up from the interchange brought 4 empty reefers and 4 loaded stock cars for us to position as our shift continued. And so it goes, we start another cycle of cleaning, chilling, loading, unloading cattle at the pens, as well as spotting supplies for the plant, and removal of byproducts. The process varies each cycle, dependent on the flow of cars to and from the plant. For instance we received 4 loaded stock cars this time and we have only 3 unloading shoots, so we will have to watch our timing since reefer loading and stock unloading happen on the same track. This variety of movement, timing of processes, masterful placement of service tracks at the plant make this a rich, challenging, and most sought out assignment on Mat’s railroad.
A big industry can be the main theme for a railroad when you are cramped for space. Mary and I were busy for over 3 real time hours servicing the plant. The randomness of cars received required a different operating plan to keep the product flowing from the plant on schedule. So a Swift Packing, cement, automobile, glass plant, or other big industry, with a realistic operating strategy and a few staging tracks can keep a small crew busy in an enjoyable and challenging way for hours.Big industries can be fun and that might be all that you need!
I want to put in a good word about operating systems that have brought me many happy and informative moments. Before we condemn these informal operating systems, we should be aware of their advantages and of those situations where their use might be appropriate.
Introductory note – To my good friends Pete, Jane, Don, Bob, Steve, Ron, and Bill:I realize that some of the following ideas disagree with thoughts you have expressed to me about prototype-based operation.I thank you for graciously sharing your knowledge and for inviting me to your operating sessions.However, I feel that the current focus on prototype-based systems may not work for all layouts, their owners, and train crews.Less demanding operating systems may be the right approach for those intimidated by or stressed out by prototype-based systems.Consequently, I feel that informal systems, though not well regarded in our hobby at this time, deserve to be acknowledged, talked about, and evaluated on their own merits.The following is an attempt to do so.
Most model railroaders respect the more formal, prototype-based operating systems:timetable/train order (TT/TO), track warrants, and centralized traffic control (CTC) for instance.After all, those systems are modeled after the prototype procedures we attempt to replicate.But what do you do if those systems result in stressful operating sessions for you and your crews?There are less formal alternatives.Many sessions I have participated in have used the informal systems described here.I have enjoyed those sessions even though, among serious model railroaders, the procedures used do not enjoy the same level of respect as prototype-based systems.
Recently, the SMD had a clinic presentation that categorized operations as either prototype-based or “fun run.”While the latter term was certainly easy to understand, it was not particularly fair to anyone.Prototype-based systems are also “fun.”(If they were not, no one would want to participate in them.)On the other hand, “fun run” sessions are not totally frivolous.Categorizing informal systems negatively ignores their potential as stepping stones into the joys of operating and as opportunities to learn about the prototype.Before we consign informal operating procedures to the trash bin of toy trains, it seems to me more useful to think of operating systems as falling on a continuum between prototype-based and “fun run” instead of fitting into one category or the other.A system that starts out “fun run” can easily slide along the continuum towards more prototype-based when those involved feel better informed and more comfortable.
This essay will examine two of the better known informal systems for managing the flow of traffic across a model railroad: gentlemen’s agreement and mother, may I?
Gentlemen’s agreement occurs when two or more train crews agree about how to resolve a conflict, such as three trains arriving in a town with only the main track and one siding not counting spurs. (The layout owner or dispatcher is not usually involved with the negotiations.)If the crews are novices, they might decide to let the local finish switching before allowing the other two trains to come into town.However, more experienced crews would consider the fact that the other two trains are likely more important (passenger trains or through freights, for instance) and would figure out a way to get the local in the clear so the other two trains could execute a pass (before the local gets back to work).While the prototype would probably endeavor not to let this situation happen, it is a good example of how learning what the prototype does can result in a smoother operating session.(By the way, trying to resolve a three-way meet by gentlemen’s agreement can get stressful when you have only two tracks.Ballast conferences and brake clubs anyone?)
Using gentlemen’s agreement places responsibility for resolving conflicts in many hands and encourages creativity from all participants. Bob Proctor handled mainline operations on his Western Antietam and Layabout using gentlemen’s agreement.(His operators often accused him of sadism, but I think what he truly enjoyed was seeing the creative ways crews cooperated with each other.)Resolving conflicts creatively can be very satisfying.However, as seen by the three train example above, the solution dreamed up by the novices failed to take into account the priority of the trains involved. So, that solution, creative though it might have been, was the wrong solution.Consequently, that situation became a learning opportunity reminding us of the railroad’s primary mission of moving passengers and freight in an efficient and timely basis by prioritizing trains.
Another opportunity to learn about the prototype arises when instructions are given to the train crews.(Of course, you must first get the crews to read the instructions.)I was party to a similar (four train) situation where the gentlemen’s agreement resulted in one local backing up to the previous town, one train holding on the main, one train moving forward, and the other local completing its work.We were so proud of ourselves, but we had completely overlooked the fact that the local, which completed its work (the afternoon local), was supposed to pick up a cut of cars from the other (morning) local.If we had read our train instructions, we could have avoided that unfortunate result.Even informal operating systems require following instructions to run the trains effectively.
Experiencing challenging situations similar to those described above is one of the ways informal operating systems give us opportunities to learn about the prototype.Experience is a powerful teacher.(Why did the prototype have this rule?Well, you have just experienced the chaos that can happen if they did not; that’s why.)
Use of gentlemen’s agreement with a common sense understanding of how a railroad operates and with knowledge of our train’s operating instructions can be an effective way to run a model railroad.(A good set of nine basic, common sense rules for operating can be found in Mat Thompson’s “Mark Me Up” column in the summer 2016 issue of the Potomac Flyer, the Potomac Division’s newsletter.)
Mother, may I? is a system of obtaining permission to move your train from one person, usually the layout owner or a designated “dispatcher.”Mother, may I? is not really a fair name for this system, since mothers (of crew members) are rarely the designated permission givers.The name might derive from a problem frequently encountered.With every crew wanting permission from a single person, mother, may I? can get quite hectic.Sessions can easily get out of hand and resemble a bunch of children squabbling for their mother’s attention – not what we want in a relaxed operating experience.Regardless, where train crews request permission to move from a single person, responsibility for resolving conflicts between trains rests in that person’s hands.
Mother, may I? is frequently spoken of with disdain.Before we condemn it, we should consider its similarities with both track warrant and CTC systems – prototype-based systems which also place sole responsibility for permission to move in the hands of a single person – the dispatcher.Clearly because of their wide use, these systems demonstrate that the prototype has had a great deal of experience making single person responsibility work.(Perhaps, a better, more railroady name for mother, may I? might be dispatcher, may I?)
Model railroaders have also used systems similar to mother, may I?For instance, in the past, DC block control often required calling the dispatcher for block assignments allowing a train to proceed.More recently, roving dispatcher systems using verbal authorization have been used successfully on simpler, more compact layouts.With this system, the roving dispatcher makes decisions based on his observations of the current situation from within the layout room.Dave Moltrup’s Beaver Falls and Shenango (aka Moltrup Steel) operates using a roving dispatcher system.
A mother, may I? system can serve as a stepping stone to more prototype-based systems like track warrants or fill-in the blank train order systems (such as the one Tony Koester used for a while on his Allegheny Midland).In fact, the problems encountered with it may encourage adopting one of the prototype-based systems.
Disadvantages of these informal operating systems:
Not prototypical – a common complaint.
Not suited for complex, high traffic layouts. (Consider TT/TO)
Requires creative thought and consideration from the layout owner to set up the operating system.Crews will need good, clear instructions.The challenge of coordinating crew efforts is still present whether the system is formal or informal.
Can get quite chaotic.
Advantages to these informal operating systems:
Low intimidation factor because there is much less to learn and put into practice.
Simplicity: less paperwork,fewer reporting requirements (minimal O.S.-ing), and less dependence on time.
Stepping stone to more prototypically based systems.
Relaxing.
Less administrative oversight during the session. (Everyone, including the layout owner, gets to run a train.)
Operations come naturally to crews.(I’ve noted that when stressed, crews often fall into using informal procedures regardless of the operating system. Crews working at the same station agree to who gets to work first; calling for help from the owner or dispatcher when the rules in place don’t give enough direction to address a problem.)
Gives crew members (especially beginners) firsthand experience of the challenges encountered in coordinating the work of countless people needed to keep trains moving.
Conditions under which these informal operating systems might be appropriate:
Smaller and simpler layouts where it is easy to get an overall idea of the status of operations at any given time.
Layouts where only one or two trains run at a given time.
Layouts with crews who are well acquainted with the layout.
Layouts with good sets of instructions and crews willing to read those instructions (a script for their train, for instance).
Layouts where the owner wants to run trains also.
Layouts that feature switching (not much mainline traffic and few potential conflicts between trains).
Potentially these informal operating systems offer not only an easy introduction to operating but also for the system to become more prototypical while continuing to offer relaxing, enjoyable operating experiences.Three things are necessary for that to happen. First, a commitment to learn more about how the prototype runs trains. Second, a willingness to set up a trial and error process. And third, a continuing effort to implement what is learned both from the prototype and by trial and error.
In conclusion, I want to put in a good word about operating systems that have brought me many happy and informative moments.Before we condemn these informal operating systems, we should be aware of their advantages and of those situations where their use might be appropriate.We also should be aware that informal systems do have some similarities to prototype practices.
While informal systems are not currently regarded highly in our hobby, I hope to foster tolerance for those modelers who prefer to operate that way.While they might not be doing what we prefer, they may be having just as much fun as we are.Furthermore, exposure to the joys of operations may lead them to learn more about prototype practices and to adopt more of those practices for their own operations (no encouragement from the model railroad police necessary).