Christmas ticketing restrictions.

[whole diary]

[JayMac]

Scheidt & Bachmann Ticket XPress machines, the most common TVM^▸ (Ticket Vending Machine) across the UK^▸ (United Kingdom), are regularly updated by their maintenance contractors. For many TOCs^▸ (Train Operating Company) this service is contracted to Telent.

From what I can gather, most were updated to Windows 10 during 2016.

[ellendune]

And as I have said before the software used by DB^» (Deutsche Bahn - German State Railway - about) is much better.

[ChrisB]

Don't disagree. Tell the RDG^‡(resolve) that, they're the ones (was ATOC^» (Association of Train Operating Companies See - here)) that would have to agree to update all the TVMs^▸ (Ticket Vending Machine)

[Worcester_Passenger]

The operating system is usually no guide to the age of the program software.

I'm running Avantix^▸ (Ticket Issuing System used on board trains) Traveller 1.7.24.0 under Windows 10 here (it says copyright to 2016). But the README file that comes with it says that it's only supported if you're running it under Windows 7. It comes with a .HLP file that will only run under Windows Vista, 7, 8 or 8.1.

[ChrisB]

And there's the rub.

Developers won't program in anything unsupported. So operating systems would need updating, and the hardware would need to be able to run current operating systems. W10 needs a lot more RAM than WXP or W7.

So you almost may as well buy new

[stuving]

I'm sure what's involved is a pretty minor change inside the TVM^▸ (Ticket Vending Machine)'s application, and nothing to do with the OS^▸ (Ordnance Survey), or whether the app will run under it. But organising that is far less simple, as can be seen below:

If you want to know what fares data looks like, you can sign up to a free licence and get some. RDG^‡(resolve) do give a little information on this, though the document defining the file formats of these "RJIS Datafeeds Interface Specification For Fares and Associated Data" is an ATOC^» (Association of Train Operating Companies See - here) one dated 2004. This says the two main fares data files are 100MB and 50MB, and the restriction file is 475 kB (or they were then).

Of course that's not what gets downloaded onto a TVM; it will be digested into something more specific. But no doubt the applications running in the machines were designed together with the pre-processing with that form of data as part of the specification. That definition knows nothing about ticket types - they are just specific values of data fields. Time restrictions are dealt with via restriction codes (the same codes you see on a ticket, surely). Each restriction code leads to a list of atomic restrictions, and one field in some of those (date band and calendar records) is a length-7 field called DAYS:

A  set  of  7  markers  each  set  to  Y  or  N, 
representing the days of the week.  The first
character represents Monday.  If the marker
= Y, then the restriction applies on this day
of    the    week,    between    the    dates    in   
DATE_FROM/DATE_TO.    If  the  marker 
is N, then the restriction does not apply on
this  day  of  the  week,  between  the  dates  in 
DATE_FROM/DATE_TO.

So if the TVM application applies that based on the true day-of-the-week value, nothing in its downloaded data tables can alter that. It would need changed software in all TVMs so the DAYS data is be redefined as the "applied day value" and some new data field introduced to say how to derive this applied day from the true date (not just day-of-the-week).

That doesn't sound too hard, and if that field itself is unchanged then unmodified machines would simply ignore the change. But the fact that the definition is so old suggests that it's not something RDG would undertake lightly. Are they justified? I really don't know. But the "who's going to have to do what?" question is likely to be important.