krus_aragon
Established Member
Especially when you decide that two digits aren't enough to store the year in dates any more.Could you make those 2 characters? You'd be amazed how expensive changing to a longer code would be
Especially when you decide that two digits aren't enough to store the year in dates any more.Could you make those 2 characters? You'd be amazed how expensive changing to a longer code would be
That will never bite us again. I mean they will _have_ to have stopped using the systems by 2060, which is when the problem was deferred to...Especially when you decide that two digits aren't enough to store the year in dates any more.
That will never bite us again. I mean they will _have_ to have stopped using the systems by 2060, which is when the problem was deferred to...
I'm definitely planning on retiring before thatEven sooner there's the 2038 problem waiting to bite (overflowing Unix timestamps...)
I believe Transport for Wales is "AW" as well. Why was it even changed to that, rather than remaining as WW or WB...?West Midlands Railway is still 'LM' and Greater Anglia is 'LE' (what is that even from?) as well.
For example all trains that are operated by the new first /Trenitalia franchise will show as “Virgin Trains” in online journey planners right up to the day before the franchise changes. This is undoubtedly confusing for the general public (“I thought it was changing to First Group -why does it still say the operator is Virgin Trains? Is my ticket still valid?”). The same problem will be on tickets (route codes) issued before the franchise change.
It would be far easier for the system converting the codes to display names to do this, rather than doing it in the source data.Where a change of two letter code would be useful is at the change of a franchise. For example all trains that are operated by the new first /Trenitalia franchise will show as “Virgin Trains” in online journey planners right up to the day before the franchise changes. This is undoubtedly confusing for the general public (“I thought it was changing to First Group -why does it still say the operator is Virgin Trains? Is my ticket still valid?”). The same problem will be on tickets (route codes) issued before the franchise change.
The reason for this is that the data does not support with effect from /with effect until date ranges for TOC two letter codes. If it did this problem would be resolved. This additional data could be introduced in a non-breaking way so that at least some TIS / journey planners could display the correct operator details, and do at least reduce the number of confused passengers.
happens to change its branding part way during the journey
I'm curious to learn what it is you do
For foul like us who understand the system, it's not an issue, however for the average person who takes a train and doesn't understand the detail of how it works, it's an issue that does cause confusion.I don't think it has ever caused a problem in the past when a franchise has changed - people still got on their trains and got to their destinations?
For foul like us who understand the system, it's not an issue, however for the average person who takes a train and doesn't understand the detail of how it works, it's an issue that does cause confusion.
And yet in the airline industry one set of two character alphanumeric codes is sufficient to distinguish every single airline offering scheduled passenger service in the entire world. (Yes, I know that some systems display 3 characters using look-up tables, but the underlying IATA codes are two character - it's just that people like Easyjet prefer their code relates to the brand name so EZY rather than U2) Are we really saying that we need more than that to separate out rail franchises in just one country?With my Software Engineer hat on, being reliant on 2 character TOC codes seems like a bad idea as it drastically limits the possible combinations (especially given that multiple operators come and go over the years; something which BR et al. must have considered at that time) and they are not unique (i.e. NT for the two Northern franchises). In a relational database system, TOC codes would not be enough to uniquely identify each operator. My guess is that some company (possibility one that is associated with the rail industry and that starts with "A" and ends with "S") is making a killing to maintain interoperability.
Only if they are forever unique, which I don't think is something that's required. Having a few years between usage/recycling of the codes should be enough to allow the old names to filter out.Are we really saying that we need more than that to separate out rail franchises in just one country?
and of course WMT is still 'LM'!
GTR has multiple TOC codes, each matching the name of the now defunct former constituent TOCs.
But there can be good reasons for this: the TOC codes are likely to be hard coded into systems such as journey planners, etc.
Correct. It won't come up with the EMT to EMR swap as that's too subtle, but it will certainly come up when Virgin Trains changes to West Coast Rail (if I have that name correct). If the industry were truly customer-focused then it would handle these things better; it's hardly difficult.For foul like us who understand the system, it's not an issue, however for the average person who takes a train and doesn't understand the detail of how it works, it's an issue that does cause confusion.
The codes are used in public, on timetables (proper ones, not journey planners).Bare in mind these two letter codes aren’t used in any general public facing systems
My software engineers hat tells me that 2 character alphanumeric gives you 1296 unique codes, which is plenty as long as you don't keep the online systems full of old data. With my "I read the documentation" hat on I'd say that it comes from a range of BR mainframe systems which means short alpha codes are the normal way of doing it, and they only ever anticipated using the codes for business units. Second guessing the decisions people made 30 years ago using an environment you likely don't understand, and under resource constraints that are difficult to even picture now, is a fools errand at best.
was thinking the same thing... "AW: Transport for Wales, LM: West Midlands Trains (Railway)", VT: (West Coast Rail)" (on the Shrewsbury-Wolverhampton line)The codes are used in public, on timetables (proper ones, not journey planners).
At the end of the day half of the global economy is run on software like this that was written 20-50 years ago and basically just does the job. We could replace it all every 5 years, but it would be a chronic waste of time and resources that could be spent doing something more useful. With systems like this there isn't just the base replacement cost, but also the downstream systems which depend on it. Ultimately replacing it with something shiny and new could easily cost the industry well over £100m all in. You may well then end up with a system that isn't as stable, still lacks important features, and has to be replaced again in 6 or 7 years when the underlying platform goes out of "long term" support. Basically you could be setting yourself up for an ongoing 20m a year in extra costs. Forever. Compared to that IBM is cheap (assuming that there's actually still a mainframe running the system anyway).I'd have to agree with danielnez1 on this, it's poor practice nowadays and this sort of technical debt should've been managed and dealt with a long time ago. It never ceases to amaze me how many 'real world' systems are built on top of this sort of tech (which I consider obsolete) - don't get me started on the financial sector, for instance! I'll be interested to see if/when things improve, but in the meantime I guess IBM will be doing well.
At the end of the day half of the global economy is run on software like this that was written 20-50 years ago and basically just does the job. We could replace it all every 5 years, but it would be a chronic waste of time and resources that could be spent doing something more useful. With systems like this there isn't just the base replacement cost, but also the downstream systems which depend on it. Ultimately replacing it with something shiny and new could easily cost the industry well over £100m all in. You may well then end up with a system that isn't as stable, still lacks important features, and has to be replaced again in 6 or 7 years when the underlying platform goes out of "long term" support. Basically you could be setting yourself up for an ongoing 20m a year in extra costs. Forever. Compared to that IBM is cheap (assuming that there's actually still a mainframe running the system anyway).
If there is a wholesale change to the industry structure, and if the system no longer supports the structure as a result, that's when it's time to fire up a new system, not just because some software engineers want to earn the big bucks but refuse to drop Elixir and learn some COBOL
Exactly right. And there are many more examples of these issues in rail data and systems.I don't disagree with what you've said - I think there's a difference between replacing it because it's not "new and shiny" and replacing it because it no longer does the job it should and/or there's a dwindling skills base. I suspect we just have different opinions as to when the latter is reached.
The experience I had with most of the CMA9 was that that they'd tried to use duct tape around their old systems to pull them into the current century. There'd be a shiny API server written in Java somewhere sat in front of all the old creaking tech for customers to interact with. This system would then talk to a mainframe which was incapable of handling unicode names, or was reliant on a batch job for updating data which meant nothing was realtime and massively slowed changes and innovation. My prediction in this area is that the challenger banks that have built their own tech (Monzo) will do a much better job here and be able to deliver features that consumers expect in 2019.
What does this have to do with rail? Rail is in a similar state from what I've seen of the systems which power it. 2 letter fixed TOC codes which are outdated are a symptom of a wider issue which, in my opinion, is an accumulation of technical debt and underinvestment in systems. Graduates will not want to deal with these systems or go and learn COBOL - and in CS at least, there is more than enough supply of work that not only do they not need to, it would be a losing proposition to go and adopt these sorts of technologies as a new engineer. The end result will be that maintenance gets more and more expensive over time.
As a Monzo customer I'm pretty uncomfortable with their stack tbh. They've made some pretty out-there tech choices. Cassandra is going to be total abandonware in 5 years, and their language choices are fairly niche. It's going to be unmanageable as a platform long before other banks get round to fixing their stacks.I don't disagree with what you've said - I think there's a difference between replacing it because it's not "new and shiny" and replacing it because it no longer does the job it should and/or there's a dwindling skills base. I suspect we just have different opinions as to when the latter is reached.
The experience I had with most of the CMA9 was that that they'd tried to use duct tape around their old systems to pull them into the current century. There'd be a shiny API server written in Java somewhere sat in front of all the old creaking tech for customers to interact with. This system would then talk to a mainframe which was incapable of handling unicode names, or was reliant on a batch job for updating data which meant nothing was realtime and massively slowed changes and innovation. My prediction in this area is that the challenger banks that have built their own tech (Monzo) will do a much better job here and be able to deliver features that consumers expect in 2019.
What does this have to do with rail? Rail is in a similar state from what I've seen of the systems which power it. 2 letter fixed TOC codes which are outdated are a symptom of a wider issue which, in my opinion, is an accumulation of technical debt and underinvestment in systems. Graduates will not want to deal with these systems or go and learn COBOL - and in CS at least, there is more than enough supply of work that not only do they not need to, it would be a losing proposition to go and adopt these sorts of technologies as a new engineer. The end result will be that maintenance gets more and more expensive over time.
I've gone for shortening the name on Traksy to EMR. It's not a classic brand like GWR, but it does appear to be what they're planning to write on the side of the trains. EM is still the logical code for them, which is handyI believe East Midlands Railway is keeping EM, the same as East Midlands Trains. It did however amuse me that on the 222's external displays they continued to display the ML for Midland Mainline as a prefix for the RSID train service number through the entire EMT franchise despite the timetable and reservation system having it as EM!