What a WTOR is

WTOR stands for write to operator with reply. A program or a system component issues a message to the console and stops until an operator replies. The console shows it with a reply number in front, for example *07 IEF238D JOBNAME - REPLY DEVICE NAME, 'WAIT' OR 'CANCEL', and the operator answers with the REPLY command, R 07,WAIT. D R,L lists the replies that are still outstanding.

Some WTORs are routine and always get the same answer. Some need judgement. All of them hold something up while they wait: a job, a system address space, sometimes a whole subsystem coming up.

Where WTORs go wrong

  • They wait unseen. On a busy console a WTOR scrolls away. The job behind it sits in the active queue doing nothing while the batch's deadline gets closer.
  • Reply numbers are reused. Once a WTOR is answered, its number is free for the next one. An operator who types R 07,... from a note written ten minutes ago can answer a different question than the one they meant.
  • Two people answer the same one. On a floor that watches many LPARs, two operators can see the same WTOR. The first reply wins; the second either fails or, worse, lands on a newer WTOR with the same number.
  • Nobody can say later who answered what. The syslog has the reply, but connecting it to the person, the reason and the outcome takes digging, and clients ask for exactly that after an incident.

What safe automation looks like

Automating replies is worth doing, but the bar is higher than for most automation, because a wrong reply can cancel a job or bring up a subsystem with the wrong options.

  1. Show every outstanding WTOR first, with its age. Before anything is automated, the operator should see each waiting WTOR at the top of the console, per LPAR, with how long it has waited.
  2. Put the reply on the line. The reply box sits on the WTOR itself, so the answer is tied to that message, not to a number typed from memory.
  3. Queue replies per LPAR. Replies go out one at a time per LPAR, so two operators cannot answer the same WTOR twice.
  4. Propose before acting. For a WTOR the floor has answered before, propose the reply that was used last time and how often it worked. A person confirms it.
  5. Earn autonomy one situation at a time. When a proposed reply has been right often enough, let it be sent and reported, and later sent quietly, for that kind of WTOR and that client only. Move it back the moment it is wrong.
  6. Record everything. Each reply with the message it answered, who confirmed it, when, and what the system said next.

Rule-based console automation products can reply to WTORs by rules you write and maintain, and they are good at it. The gap is usually the operator's view: the WTOR, the job behind it, the scheduler's state and the ticket on one screen, with the evidence kept.

How Meridian handles WTORs

In Meridian, outstanding WTORs sit at the top of each LPAR's console view with their age, and the dashboard counts them per LPAR. The reply box is on the WTOR line, replies are queued per LPAR, and the outcome shows on the line. Ready-made flows in Builder open a ticket for any WTOR, or send the standard reply. Earned autonomy is set per kind of situation and per client: propose only, do and tell, or do quietly. Every reply is recorded with its evidence.

See the Act section for the screens.