Tag: operations

by Harvey Heyser

Gentlemen’s Agreement and Mother, May I?

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:

1. Not prototypical – a common complaint.
2. Not suited for complex, high traffic layouts. (Consider TT/TO)
3. 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.
4. Can get quite chaotic.

Advantages to these informal operating systems:

1. Low intimidation factor because there is much less to learn and put into practice.
2. Simplicity: less paperwork,fewer reporting requirements (minimal O.S.-ing), and less dependence on time.
3. Stepping stone to more prototypically based systems.
4. Relaxing. 
5. Less administrative oversight during the session. (Everyone, including the layout owner, gets to run a train.)
6. 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.)
7. 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:

1. Smaller and simpler layouts where it is easy to get an overall idea of the status of operations at any given time.
2. Layouts where only one or two trains run at a given time.
3. Layouts with crews who are well acquainted with the layout.
4. Layouts with good sets of instructions and crews willing to read those instructions (a script for their train, for instance).
5. Layouts where the owner wants to run trains also.
6. 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).