Possible reporting code inputs on TOPS?

[Jr_Vandalas]

Evening all,

As I am slowly figuring a bit more about TOPS, I came across report types which can be input into a TOPS machine, such as E3 reports and J6 reports. This got me wondering two things - what other reporting inputs are possible to be input on TOPS with a valid outcome? And what are the significance of the numbers that follow these reports when you actually input these codes onto TOPS (Such as J6 followed by 4 1s)?

Many Thanks.

 

[zwk500]

Evening all,

As I am slowly figuring a bit more about TOPS, I came across report types which can be input into a TOPS machine, such as E3 reports and J6 reports. This got me wondering two things - what other reporting inputs are possible to be input on TOPS with a valid outcome?

You'd need the manual to answer that fully. Given that TOPS was intended to centralise maintenance and operations records, there's probably a very long list of what it can do, and it might have changed over the years. For instance you can run a report on where all the locos in a certain 'pool' are at a given time. Some threads show those outputs. You could also presumably do queries on which locos were at a certain location, and so on.

And what are the significance of the numbers that follow these reports when you actually input these codes onto TOPS (Such as J6 followed by 4 1s)?

Many Thanks.

E3 and J6 are query codes, the numbers afterwards would be specifying options for the query.

IIRC E3 was a loco enquiry, You'd put in 'E3 66450' to get the TOPS record for loco 66450 - length, weight, RA, last exam, etc...
The 4x '1' after J6 was about selecting which options you were querying in TOPS. I have a feeling J6 was a carriage or wagon enquiry. So you'd put in 'J6 1 1 1 1' followed by the carriage number.

 

[Jr_Vandalas]

You'd need the manual to answer that fully.

Unfortunately do not have access to one which is why I have brought my enquiry here, in the hopes of at least finding more query codes which are used for locomotives and coaching stock/wagons alike.

IIRC E3 was a loco enquiry

Correct, E3 is an in-depth maintenance enquiry for locomotives. J6 is similar however includes coaches and wagons.

The 4x '1' after J6 was about selecting which options you were querying in TOPS.

I assume that the meaning of the numbers after a query code changes depending on the query code itself?

Thank you a lot for the help so far.

 

[zwk500]

I assume that the meaning of the numbers after a query code changes depending on the query code itself?

Correct, for instance you could add numbers between E3 and the loco number that would include it's last working, even if that had terminated. I think I normally ran E3 queries as 'E3 1 2 1 [Loco]'

 

[FGW_DID]

Evening all,

As I am slowly figuring a bit more about TOPS, I came across report types which can be input into a TOPS machine, such as E3 reports and J6 reports. This got me wondering two things - what other reporting inputs are possible to be input on TOPS with a valid outcome? And what are the significance of the numbers that follow these reports when you actually input these codes onto TOPS (Such as J6 followed by 4 1s)?

Many Thanks.

If you have access to TOPS, on the TOPS input page, try: SD PROC INDEX
That should give you the full list, there’s about 6 pages of them.

Type: SD PURPOSE xx (where xx is the Procedure ID)
That brings up an explanation of the Procedure.

Type: SD INPUT xx (xx = procedure ID)
This brings up an explanation of the keyboard inputs required.

Been a long while since I had access to TOPS, I should imagine the index hasn’t changed much.

TV is quite good, it’s a power report. TV + Location code (TIPLOC is used I think) would give you a report listing all locos at that location.

 

[800002]

The TOPS Enquiry Handbook which Railtrack bequeathed runs to 192 pages...

 

[Jr_Vandalas]

If you have access to TOPS, on the TOPS input page, try: SD PROC INDEX
That should give you the full list, there’s about 6 pages of them.

Type: SD PURPOSE xx (where xx is the Procedure ID)
That brings up an explanation of the Procedure.

Type: SD INPUT xx (xx = procedure ID)
This brings up an explanation of the keyboard inputs required.

As I mentioned in a post above, I do not have access to TOPS unfortunately, however these inputs are good to solve the question I have brought up. Thank you for this!

The TOPS Enquiry Handbook which Railtrack bequeathed runs to 192 pages...

That is quite a bit of pages I must say, based on how it looks like a digital copy I wonder if that handbook is available online?

 

[800002]

As I mentioned in a post above, I do not have access to TOPS unfortunately, however these inputs are good to solve the question I have brought up. Thank you for this!

I thought you had current access to TOPS / TRUST, but were lacking some direction in reports and functions.

That is quite a bit of pages I must say, based on how it looks like a digital copy I wonder if that handbook is available online?

It is, yes. Covering almost everything in the system (very little of which is required by every user of the system).

It might be in existence online somewhere. Google could still come up trumps.

 

[Jr_Vandalas]

I thought you had current access to TOPS / TRUST, but were lacking some direction in reports and functions.

Nope, just someone who has a lot of interest regarding TOPS & TRUST and how it works.

Google could still come up trumps.

Have been searching based on file names etc, can't find anything unfortunately. I am sure there is a few still out there though.

 

[Dren Ahmeti]

Luckily I have a copy!

Back TOPS (F12) also has “FIND LOCO xxxxx” and “FIND WAGON x” that has similar info to other enquiries.

MEND is a good command on the TRUST enquiry screen, as you can use the more complex queries in an easier understood fashion.

The issue with TOPS says that a lot of knowledge is learnt from BR days, and it’s slowly dying out; very few documentations actually exist, and some SD PROCs and SD INPUT xx haven’t been updated since the ‘80s!

Rumour has it within my company that TOPS will be replaced when brake force and brake curves will need to be considered with ETCS, but I don’t think the backend will go anywhere. Some functions of TOPS still think that they’re running punchcards!

Now, if someone could teach me where to find revised consist IDs and detail stops etc on extended reporting - causing all sorts of pain when planners put in pathing stops as power and wagon work

 

[Jr_Vandalas]

Luckily I have a copy!

Legend!

The issue with TOPS says that a lot of knowledge is learnt from BR days, and it’s slowly dying out

It is a shame, which is why I am trying to gather what info of TOPS there is now, and try to fill in missing gaps I have within TOPS despite having no access to it.

and some SD PROCs and SD INPUT xx haven’t been updated since the ‘80s!

I wonder which ones? I would imagine the query codes that were linked to speedlink and TAG traffic since that has died out.

Rumour has it within my company that TOPS will be replaced when brake force and brake curves will need to be considered with ETCS, but I don’t think the backend will go anywhere. Some functions of TOPS still think that they’re running punchcards!

I am pretty sure the backend will remain for freight-related traffic, but TOPS still thinking its running punchcards is quite interesting - I would imagine as a printout?

 

[zwk500]

I am pretty sure the backend will remain for freight-related traffic, but TOPS still thinking its running punchcards is quite interesting - I would imagine as a printout?

Once the full traffic management part of ERTMS is introduced I expect TOPS days will be numbered.
It will be too expensive to keep managing interfaces between it and the modern systems.

 

[Dren Ahmeti]

I wonder which ones? I would imagine the query codes that were linked to speedlink and TAG traffic since that has died out.

Yes!
A lot of references still exist to MGRs, unfitted freight, guards on trains, vacuum-fitted consists, Speedlink, and a helluva lot more.

One example I use daily is on yard-to-yard transfers, where - if I am moving wagons - then I am asked to specify brake type [A for Air, V for Vacuum, R for through-piped dual-air and vacuum (I think?)], and whether I have a guard on board. [via TOPS2000]

Even though unfitted freights have fallen out of use, a Class 9 designation will still throw out an error stating “guard required”.

 

[Jr_Vandalas]

One example I use daily is on yard-to-yard transfers, where - if I am moving wagons - then I am asked to specify brake type

I would imagine that would be a given output after running a C7 query on TOPS (I have been reading the handbook!)

Even though unfitted freights have fallen out of use, a Class 9 designation will still throw out an error stating “guard required”.

Now thats a weird one. Do you simply just input that the train has a guard when it actually doesn't?

== Doublepost prevention - post automatically merged: 4 May 2026 ==

The issue with TOPS says that a lot of knowledge is learnt from BR days, and it’s slowly dying out;

I think a fairly good example of this would be the asterisk on a commodity code for a locomotive working a service, which no one really seems to have a clue on what it means anymore.

 

[Dren Ahmeti]

Now thats a weird one. Do you simply just input that the train has a guard when it actually doesn't?

No, we just don't use them anymore!

 

[Clarence Yard]

From the M&EE perspective, I was a big user of J6 1, A9 5 and E3 1 for quick enquiries. E3 1 2 1 gave me the full details for a loco, including physical and maintenance/overhaul data.

AB enquiries were great fun. They were individually tailored enquiries using keywords. What you had to do was narrow down the enquiry as you went along the string.

It took a few goes at it but my favourite AB enquiry at work was AB TRACTION MNTER LOCDGT EQ 55. That brought up all the ER maintained Deltics, what they were working at the time or their location and their maintenance status, stop code and any restriction.

Pool enquiries were in the X series but you had to be careful you weren’t trying to list a pool consisting of several thousands of vehicles. We used a small Ventech enquiry machine at KX DME (and at depots), and you would soon run out of paper (it came in rolls) if you did that! My most used pool enquiry was for the Flyash wagons which we used to maintain at Peterborough Crescent Shops (45108).

 

[Jr_Vandalas]

No, we just don't use them anymore!

Why didn't I think of that!

I was a big user of J6 1, A9 5 and E3 1 for quick enquiries. E3 1 2 1 gave me the full details for a loco, including physical and maintenance/overhaul data.

That makes sense, since J6 and E3 both give detailed maintenance records for the vehicle you are requesting data from.

Pool enquiries were in the X series but you had to be careful you weren’t trying to list a pool consisting of several thousands of vehicles. We used a small Ventech enquiry machine at KX DME (and at depots), and you would soon run out of paper (it came in rolls) if you did that!

I wonder how many new people had to find out the hard way that larger pools should be listed with caution.

 

[Merle Haggard]

In the early days of EWS Mr Berkhardt decided that TOPS was too expensive and wanted his own in-house replacement. He engaged a one-man computer expert, and I - amongst others - was invited to comment.
I met that man, and he showed me some very impressive screens. I had a strong idea, though, that they were actually just what we called 'flat files' (possibly wrongly), made up to look good but not actually generated from logical flow.
But the best bit was when I asked him what the routine would be to check that the trailing load was within the limit for the route and loco, because his system seemed at the most to just aggregate free form manual input of wagon details to form the consist. He said something on the lines of 'that sort of stuff is unnecessary - on the Continent the driver turns up, looks at the train and says "yeah I can pull that"'. All with the air that British Rail management was just a load of dead beats inventing problems.
Luckily, I retired soon after but I wonder how it went...

 

[55002]

I remember from 40 years ago, TV and then a tops area code got you all the locos on that area.

 

[Jr_Vandalas]

In the early days of EWS Mr Berkhardt decided that TOPS was too expensive and wanted his own in-house replacement. He engaged a one-man computer expert, and I - amongst others - was invited to comment.
I met that man, and he showed me some very impressive screens. I had a strong idea, though, that they were actually just what we called 'flat files' (possibly wrongly), made up to look good but not actually generated from logical flow.
But the best bit was when I asked him what the routine would be to check that the trailing load was within the limit for the route and loco, because his system seemed at the most to just aggregate free form manual input of wagon details to form the consist. He said something on the lines of 'that sort of stuff is unnecessary - on the Continent the driver turns up, looks at the train and says "yeah I can pull that"'. All with the air that British Rail management was just a load of dead beats inventing problems.

This seems like the best example of why we never really tried to replace TOPS (if it ain’t broke, don't fix it). I wonder what actually came out of that system and if it ever had a name? The lack of logical flow especially for important aspects such as such as trailing load (which, I would say is not a good thing to eyeball) does seem a bit ridiculous though.

 

[Adrian Barr]

what other reporting inputs are possible to be input on TOPS with a valid outcome?

I wrote this out before seeing the enquiry handbook posted - it gives a list of what I think are the most useful types of enquiry for freight, and how they can be used in practice. You can compare this to the detail in the enquiry handbook.

It's surprising just how many different enquiry inputs there are within TOPS, many of which have fallen out of use. Some had specific use cases which are no longer required (such as a Q1 "Colliery Wagon Position Report" or reports summarizing wagonload traffic by tag - EY for inbound and EJ for wagons on hand). I've never heard of the SP enquiry intended for Speedlink traffic before - if I want to know which wagons are at a location I would use an X3 to get a full list, although the input is a bit long-winded - for example X3 23460 W ; 2 00 B ; 26238 will give you a list of all wagons at Stanox 26238 (Worksop Down Yard).

Other reports that have fallen out of use were different ways of getting similar information; for example there are several different reports for looking at "crippled" wagons (i.e. defective or due maintenance) within pools.

==========
Loco enquiries:
==========

E3 - Loco information for specific loco(s).
The 1s after the E3 are used to select the following info; an "E3 1" is adequate for most purposes.
LOCATION INFORMATION
MAINTENANCE RECORD ['1' = SHORT REPORT '2' = LONG REPORT]
PHYSICAL CHARACTERISTICS INFORMATION

LP - Loco Pool Enquiry
(like the ones regularly posted in the class 70 thread). FrodshamJnct recently linked this useful page which explains these outputs:
https://www.class37.co.uk/tops_codes.aspx

TV - Power Report
THIS PROCEDURE IS USED TO PROVIDE A LISTING SHOWING THE WHEREABOUTS OF INDIVIDUAL LOCOMOTIVES WITHIN OR EN-ROUTE TO A TRA*, A NUMBER OF TRAS OR A RANGE OF LOCATIONS WITHIN A TRA OR TRA'S OR INDIVIDUAL LOCATIONS WITHIN A TRA.
1. LOCOS OUT OF SERVICE
2. LOCOS ON HAND O.K
3. TRAINS DUE TO ARRIVE WITH LOCOS FOR DETACHMENT
4. LOCOMOTIVES ALLOCATED TO ARRIVE

*A TRA is a TOPS Responsibility Area - originally the geographical area which each TOPS Office was responsible for, but there are now also TRAs for different Freight Operating Companies. Traditionally used by loco controllers to give an overview of locos in an area; for example a power report could be done for Toton yards and depot which would show locos at the yards and depot plus locos on trains heading to these locations, split up into the categories above.

FIND LOCO - loco history
Lists the recent 40 or so TOPS events for that locomotive, including movements and things related to maintenance such as fuelling, exams, change in operating status, restrictions added or removed, faults, and assignments (upcoming planned work) for maintenance or repairs. To get the maximum history you can include a date.
FIND LOCO 66001 0101 would give a history report going back as far as possible (38 lines of info). In theory a skip is required before the date but it works without it...
FIND LOCO 66001 T 0101 would only show loco movements (T for trains) and exclude other events such as maintenance

===============
Wagon Enquiries
===============

A6 or A9 - basic wagon enquiry "TO ASCERTAIN ABBREVIATED INFORMATION ON VEHICLES"
These show similar information to a J6 but in a shorter format, with various options depending on the information required. The response is usually given on a single line (unlike a J6) which makes it useful when basic info is needed on a list of wagons.

J6 - detailed wagon enquiry "TO OBTAIN DETAILED INFORMATION ON FREIGHT/PASSENGER AND NPCCS VEHICLES"
The 1s after the J6 are used to select from the following:
CURRENT LOCATION INFORMATION
PHYSICAL CHARACTERISTICS INFORMATION
CURRENT MAINTENANCE INFORMATION
REPAIR HISTORY INFORMATION
(a basic J6 is without any 1s is usually adequate - by default it selects the current location info + maintenance info)

X3 - wagons at location
This is described as a "delayed wagons" report but the main use of it is to provide a full list of wagons at a particular Stanox. A typical response would sort the wagons by time of arrival into the location, showing wagon number, wagon type, destination, empty or loaded + commodity and day/month of arrival. A complicated input - there are numerous options for changing how the response is sorted and the info shown, or limiting the output to wagons that are empty / loaded / crippled and so on.

X4 - pool enquiry
This gives information on the wagons in a specific pool, such as current location, destination, commodity.
There are numerous options that change how the information is presented and sorted; a typical response would list the wagons in the pool in numerical order along with the wagon type and tell you where they are, where they are going, what they are loaded with. Pool enquiries are also used to provide information on maintenance and defective wagons.

ZQ - pipeline enquiry
Shows wagons destined to a particular location (usually a customer terminal). For example a "pipeline" enquiry for Kronospan at Chirk showed there were 22 loaded IWA timber wagons at Carlisle destined for this location in TOPS.

FIND WAGON - wagon history report
Gives a detailed history for a wagon in TOPS showing the last 40 or so "TOPS events" (which could be train movements, loading, unloading, local transfers between yards and terminals, reporting of defects and so on). Very useful for seeing where a wagon has been, which trains it's been on, where it was loaded from and to. For wagons in constant use the data sometimes only covers a week or two, but for long-term stored wagons it can show info going back many years including the last trains it worked before being stored. One limitation in these cases is that it shows the time / day / month of each activity but not the year. Similar to the "find loco" enquiry, using a date of 0101 in the input gives the maximum length of history (e.g. FIND WAGON 310001 0101)

===========
TRUST Enquiries
===========

TRJC (+ Headcode) - Train running enquiry.
Shows similar information to looking at a train in RTT, with booked timings on the left, actual reported times on the right, minutes late or early plus line taken at each location (e.g. F LINE / S LINE / G LINE / 1 line for fast / slow / goods / platform 1 and so on). A TRJC enquiry also shows delay information which can be viewed in more detail with other inputs.
>Entering a V while viewing a TRJC output shows the vehicles (for freight trains it shows the TOPS "detail consist")
>Entering a G while viewing a TRJC output shows more detailed schedule information including mileage, timing load, booked lines, pathing allowances)

TSIA "Train Schedule Enquiries" -
1. Journey enquiry - similar to using the National Rail Enquiries website to plan a journey from A to B, with a few options to specify route and minimum connection time etc.
2. Location enquiry - similar to using the search function in RTT to see trains at a particular location, with various options to limit the enquiry by things like train class (e.g. class 4 and 6 trains only), business sector (e.g. Heavy Haul services only), trains which are going through another location (e.g. trains which pass this location which also pass through a particular junction).
A useful option when viewing this information is to select "T A" to show actual passing times, or "T L" to show the last TRUST report for each train, which is useful for viewing information from previous days. This makes it easier to see which trains actually ran.
3. Headcode enquiry - Browse schedules by headcode
4. Business enquiry - Browse schedules by sector (specific TOC or FOC) or train service code for a particular day
L. Location directory - Browse database of locations by name / Stanox / Tiploc / 3-letter CRS station codes / depot code.
For a selected location you can see Location Name / Tiploc / CRS code / Stanox / Stanox Name / Customer / TRA / NR Zone and Route

TRJA (+ location) - Trust "lineup" for a particular location.
This shows trains heading towards a particular location (e.g. all trains heading to Peterborough station). A basic TRJA enquiry only shows trains which are planned to call, so for example the results for Peterborough only show freight which stops (e.g. for crew change) and does not include non-stop passenger trains.
TRJA can be modified to show freight, for example "TRJA PBO CF A" will show all freight trains heading towards Peterborough station.
The report shows headcode / booked arrival and departure (or passing time) / last reported location and time / minutes early or late.
The report only shows live schedules which have already been activated and have not been cancelled, so is useful for excluding all the "runs as required" trains that clutter up RTT search results when you are "out and about" and want to know if any freight is heading your way. It would be useful if RTT could replicate this feature!

Input below is TRJA FPK CF A
(shows freight and light engines currently heading towards Finsbury Park). Selecting a train from the output with S will do a TRJC train running enquiry on it.
-------------------------------------------------------
TRUST LineUp for FINSBRYPK (54238) at 14:11 05/05/26

classes 04678 only
Booked
Train arr dep ---------Last reported--------- Overdue reports

. 4E07 13.59 14.04 LEA JN DEP 14.06 24 LATE
. 4L19 14.26 14.41 GORDONHIL PASS 14.04 RT TIME
. 4E39 PASS 14.33 BARKING PASS 14.10 13 LATE
. 6M03 PASS 19.10 FOXTBUGRF ETD 16.53
. 4L08 PASS 21.26 WKFLDEURO ETD 14.31
. 6G30 PASS 23.32 DON UPDCY ETD 18.17

-------------------------------------------------------
TRJD (+ location) - Trainflow enquiry

Another type of "lineup" enquiry, this is useful for giving a list of freight trains heading to a particular yard or terminal (usually specified by Stanox). The info given is similar to a TRJA, but includes a loco number, number of wagons, train origin and some idea of commodity carried - the MRMSRB on 6E22 in the response below is Miscellaneous Railway Materials, Standard Railway Ballast.

TRAINFLOW ENQUIRY - TRAINS TO 23451 DONCDNDCY AT 22:31 05/05/26


GROSS ORIGIN OF RPRSNT
ETA SCHD TRAINID LAST LOCATION TIME LOCO WGS TONNES TRAIN COMMOD

0010 0021 09-0E98-1 DURHAM PASS 22.24 66306 00 0000.00 CARLISLEY
0011 0031 59-6E22-C TOTONCENT ARR 22.24 66305 19 1851.00 MNTSORREL MRMSRB
0149 0159 31-6E40-1 BRNHTHEFT ETD 23.48 66689 22 0523.00 BRNHTHEFT EMPTY
------------------------

TRJD is useful to see trains heading to a yard or terminal, but TRJA is better if you want a list of freight services passing a particular location like a station or junction.

==========
TOPS Consists
=========

Another type of report for wagons is the TOPS "detail consist" which lists the loco(s) and wagons on a particular train along with info such as wagon type, commodity carried, wagon origin and destination, weight, length, max speed, brake force, dangerous goods info and any wagon defects. A detail consist can be generated with an "F4 A" TOPS input, but usually the consist is viewed from a TRJC train enquiry screen (where the V option requests a detail consist from TOPS).

TOPS was designed so that when a freight train departed, the consist would print automatically at whichever TOPS office was responsible for the next calling point or terminating location. These automatically generated consists can be retrieved from within TOPS by the relevant FOC even if they aren't physically printed, which is useful as the consist info disappears from TRUST a couple of hours after the train arrives (the other info on a TRJC like actual running times and delays remains visible for a couple of weeks).

TRUST and TOPS are separate systems which are linked to each other (TOPS was introduced before TRUST existed, and used a more basic system for train schedules). Wagons in TOPS are either at a location (Stanox) or consisted to a schedule from one location to another. Schedule information from TRUST is passed to TOPS so that when a freight schedule is called (activated) in TRUST, it can be consisted in TOPS, with the consist in turn being viewable in TRUST. Departures and Arrivals are passed from TRUST to TOPS and vice versa depending on which system is used to input them.

 

[Merle Haggard]

This seems like the best example of why we never really tried to replace TOPS (if it ain’t broke, don't fix it). I wonder what actually came out of that system and if it ever had a name? The lack of logical flow especially for important aspects such as such as trailing load (which, I would say is not a good thing to eyeball) does seem a bit ridiculous though.

I don't know what happened in the end, although I passed my views on. The guy did seem to be a charlatan to someone with a basic knowledge of computer programming.
As is well known (I think) TOPS was originally intended to make more efficient the distribution of empty wagons to loading points in the most efficient way in the days of, in effect, wagonload services. It achieved a massive reduction in the wagon fleet by removing the contingencies held in large numbers around the system. The original TOPS computer had very limited memory by today's standards, and in effect most of the data storage was by punch card records at TOPS terminals. It seems that, as extra functions were added the programme enhancements were made piecemeal. When any suggestion made by Railfreight for changes to TOPS to improve usefulness the programmers always had the legendary sharp intake of breath. I formed the opinion that it was generally thought within Computer Services that at some point one tiny and innocuous alteration would bring the whole system crashing down irretrievably because it was by then impossible completely to understand all the logic flows. And that was 30 to 40 years ago; would seem to be (over!) due for a complete re-write.

 

[Adrian Barr]

Rumour has it within my company that TOPS will be replaced when brake force and brake curves will need to be considered with ETCS, but I don’t think the backend will go anywhere.

In the early days of EWS Mr Berkhardt decided that TOPS was too expensive and wanted his own in-house replacement. He engaged a one-man computer expert, and I - amongst others - was invited to comment... Luckily, I retired soon after but I wonder how it went...

I think the proposed EWS replacement was known as the TCS project, or some acronym like that. It was looked into fairly seriously, but like you suggest I think they concluded it just wasn't capable of replacing TOPS effectively.

There is a TOPS "replacement" in the pipeline, I think it's at the stage where "expressions of interest" have been invited and the requirements of the project are being determined before tenders are issued.
https://www.railbusinessuk.com/uk-2/2024/08/27/network-rail-looks-at-tops-replacement-options/

If you google "network rail tops replacement project" there's a gov.uk link to a PDF telling companies how to get involved with the tender, but with little detail apart from a couple of paragraphs describing what TOPS is, and this snippet on the aim of the replacement project:

The TOPS and POIS Replacement Project is required to deliver a solution to replace in use functionality of the existing application under the adoption of modern technologies, thus avoiding innovation limitation, technical debt, operational risk and extended support agreements for these two mission critical services.

I'm not quite sure how to decode some of those buzzword phrases, but I think to a large extent the existing functional logic of TOPS will be retained in a streamlined version, but with the "back end" moved onto modern hardware and software to make it a lot easier to support. As mentioned in the post above, some elements of TOPS were restricted by memory limitations, so there will be things that can be improved or added in a new version. I think they are taking the "if it ain't broke don't fix it" approach, but need to modernise the IT that holds it together to avoid problems and high costs supporting it in the future. As mentioned in previous posts, detailed knowledge of the system as it was under BR is gradually dying out, and that also applies to the knowledge needed on the IT side of things.

I wonder how many new people had to find out the hard way that larger pools should be listed with caution.

There are now limits on the number of lines that TOPS will provide in a report before terminating the output with an error saying the number of lines has been exceeded. I think it affects pools with more than 500 or so wagons, which is very few of them these days.

Now, if someone could teach me where to find revised consist IDs and detail stops etc on extended reporting - causing all sorts of pain when planners put in pathing stops as power and wagon work

Not sure what you mean by revised consist IDs, but for handling detail points I find the old-fashioned way of doing things (using AL input in TOPS) is preferable to using extended reporting in TRUST. Normal way of looking at detail points is with F4S on a TRJC enquiry. I've picked this 6B75 example from Trostre to Cardiff Docks because it has 2 detail points on it and visits AD Junction twice - I think the train is usually too long to run round at Pengam, so it does it in the loop at Courtybella instead, just beyond AD Junction yard.

TRAIN ENQUIRY RESPONSE FOR 796B75C307 TFA - GUE
ACTUAL TRAIN ID 796B75C307 BOOKED 6B75C
EDT TROSTE 0305 07
0 LDS 0 MTYS 0 TONNES 0 FT/ 0MTR 0 POTENTIAL BRAKE FORCE
0 UNITS 0 HORSEPOWER 0 TONS 0 FT/ 0MTR 0 BRAKE FORCE
0 FT/ 0MTR-TOTAL TRAIN LENGTH 0 TOTAL TRAIN BRAKE FORCE
STATION CT CONSIST ARR DEP LDS MTYS HRS MIN HRS MIN
79051 TROSTE 01 0305 EST 000 000
79780 MARGAM TC 21 NRP 0347 EST 0445 EST 000 000
76470 ALEXDK JN 55 NRP 0626 EST 0628 EST 000 000
76471 CORTYBELA 57 DETAIL 0633 EST 0653 EST 000 000
76470 ALEXDK JN 59 NRP 0658 EST 0700 EST 000 000
77090 TIDALSDGS 69 DETAIL 0734 EST 0802 EST 000 000
77102 CARDFDK 71 DETAIL 0833 EST 000 000
END

There are detail points at Courtybella 76471 (run round) and Tidal Sidings 77090. NRPs are non-reporting points.

To get rid of the detail point at Tidal you would input this (where GUE is the train file address listed under TFA in the top line):

AL GUE
2L G 77090 ; ; ; 0

These are different options that can be added after the Stanox on the second line:
; ; ; 3 would add a detail point
; ; ; 3 P would add a detail point and power change
; ; ; 3 X would add or keep a detail point but get rid of an unwanted power change
; ; ; 7 P would add a power change only (e.g. for a light engine or loco swap)
; ; ; 0 X would get rid of a detail point and power change
; ; ; 0 is also useful if a location is on the TRUST schedule as a passing point but it won't let you make it a detail point - try making it a non-reporting point first then make it a detail.

This input below is not normally required, but can sometimes be useful for schedules like RHTTs that have unwanted detail points at places which appear more than once on the schedule:
Adding or removing a detail point at ADJ (76470) on that 6B75 would require extra info on the top line because it's on the schedule twice. 0626 is the planned arrival time for the first instance where it calls at AD Junction (need to use the planned arrival or departure time shown on the schedule, not the estimated time calculated by TOPS shown on the F4S after it departs).
This would add a detail point at ADJ. Using 0658 instead of 0626 would add the detail point at ADJ onto the schedule after the run round at Courtybella, instead of before.

AL GUE ; ; ; ; 0626 ; Y
2L G 76470 ; ; ; 3

 

[Jr_Vandalas]

LP - Loco Pool Enquiry
(like the ones regularly posted in the class 70 thread). FrodshamJnct recently linked this useful page which explains these outputs:
https://www.class37.co.uk/tops_codes.aspx

LP has always interested me, but only because of the output. This might be a very large stretch considering it has been mentioned on freightmaster no one has a clue about this.
Next to the commodity code, there is sometimes an asterisk on the right-hand side. I have seen that the asterisk is:
- Never applied onto light engine movements (COM F).
- Applied onto the relevant COM code when a service is allocated onto a train under NX WTT.
- Sometimes not applied to other COM codes under freights (Notably 4, 5 & 9).
I wonder what the actual meaning of the asterisk is? I have been trying to formulate a lot of ideas regarding this but never really reached anywhere, so I would think I can put my thoughts down here. Best I know is that the asterisk is to do with the commodity code because it falls under COM.

 

[CW2]

A couple of comments:
Firstly, the steam loco preservation movement owes a lot to the introduction of TOPS. How so? Simple. TOPS was introduced area by area across the entire network. As noted above, as each area became live on TOPS, the yard masters could no longer conceal their stocks of spare wagons, so they had to get rid of them to adjacent non-TOPS areas. The result was a glut of old wagons that kept the scrapyards busy. Most notably, Dai Woodham at Barry in South Wales decided to concentrate on cutting up wagons for a few years, which meant 100+ steam locos escaped the cutting torch.

Secondly, the freeform AB enquiry was very handy, especially for cranks with TOPS access and interest in specific loco classes. (There were lots of legitimate specialised enquiries that you could do too, checking on specific wagon types or traffic flows).

It's a very long time since I have had to do any TOPS work, but an AB enquiry might go something like this:

AB D1040 D1434 SORT LOCNBR LIST LOCNBR DEPALL LASLOC TRANID ALLOC1 ALLOC2 OPRSTA RESTWK PREDEP LOCDGT EQ 37 OPRSTA NE R,S,U

To explain that, first you need to remember that TOPS is a very old system, and the above gibber is old computer programming language.

AB D1040 D1434 is telling TOPS you are making a freeform enquiry on databases named D1040 and D1434.

SORT LOCNBR means the output will be sorted into numerical loco number.

The LIST command defines the fields which will be listed in the output.

In this case, they are: loco number, depot allocation, last location (as TOPS stanox = 5-digit station number), train identity, next two allocations, operational status, restricted working limitations, maintenance pre assignment, where the loco class is 37 and the loco is not in status R,S,U (stored etc).

You would normally want to limit the output to a specific geographic area, so e.g TRA EQ 54311 would limit the results to the Kings Cross area.

I hope that shines a little light on a forgotten area of the pre-internet gen network.

 

[Jr_Vandalas]

AB D1040 D1434 is telling TOPS you are making a freeform enquiry on databases named D1040 and D1434

Were these databases arranged in regards to TRAs? Or were they organised differently?

 

[CW2]

Were these databases arranged in regards to TRAs? Or were they organised differently?

The databases were national. You could limit the enquiries geographically by restricting the output to either a specific TRA, or by setting lower and upper limits for the STANOX (location numbers).