Day 23 - Indian Railways DOS based systems (?); A great trip to Calcutta

Today was a trip to Kolkata for Biswa Mast Aadmi. It was a a GREAT SHOW! And it
was a wildly succesfuly trip also. Generally, my plans are foiled because of one
thing or the other, today everything worked well. There’s a first!

On my way to Howrah, I had the chance to look at the screen on which the people
behind the ticketing counters in the KGP Station find ticket availability
between different stations, at different dates and different ticket classes
(Sleeper, 3AC, 2AC, etc)

There are a few things to note here. The IRCTC apparently has a huge Database
which is geographically separated, etc etc. That’s the backend part, that
doesn’t matter for the present discussion.

The VT220 terminal itself was introduced in 1983. Yeah, 1983. That is about 8
years before Linus Torvalds started working on
Linux.
It’s also 34 years old now. Using a 34 year old frontend for ticketing? I can’t
see any real reason for that to be an intelligent choice. Isn’t it just better
to update atleast to a latest Linux version?

That aside, let’s look at how the DB is queried.

Entering the date, origin
station and destination station, and the ticket class: leads to a table that has trains running on that
between the two stations and the availability for each of the trains.

Almost immediately, if there are no tickets, or even if there are tickets,
people want to try higher classes. This requires a change in one of the
parameters.

If higher classes are not available for that date, people who are willing to
be flexible (which is almost everyone) want to know the availability of the
earlier day, the next couple days, etc.

Achieving all of this in a crowded station, where noise levels are pretty high
already leads to people having to shout to make themselves heard. It leads to
chaos. There are 2 ways out of this:

A kiosk at the station: People should ideally use the IRCTC website for
checking availability. Or use the IRCTC mobile application. If they can’t,
there should be GOOD kiosks (for some reason, all kiosks have very very bad
touch screens and response times that range between 10s of seconds to 100s of
seconds. Why not just use a keyboard and a mouse? Why this obsession with
touch screens?)

Sidenote:
The IRCTC mobile
app is the WORST MOBILE APP that has ever been written. When you have clicked
on “Book Ticket” and gone through the payment and are waiting for your PNR,
the application starts showing you a non-cancelable Android notification. The
infinitely spinning ring. There’s no progress notification, you can know
nothing. When you are on something like LTE (which I was once on, That’s
where all this ranting is coming from), this takes forever. You can keep
waiting, and it will eventually show you a message that’s a rough equivalent
to “We couldn’t book the ticket. Money will be refunded in a few days. Try to
book your ticket again”. Now, there are plenty of mobile applications out
there with payment SDKs which are way way faster than whatever these people
are using. I am sure that any company would be happy to provide their
services to IRCTC atleast at a lower cost, not that cost would ever be a
prohibiting factor for the leading long-distance transport provider in a
country of 1.2 billion people. But seriously, GET YOUR ACT TOGETHER!

Text interfaces are incredibly powerful. The terminal is one of the biggest
examples of this. Skilled users can use text interfaces much faster than
anything that requires touching or clicking on buttons with a mouse. That
said, the data that comes back from the commands should also make sense. Take
ls for example. ls is great, ls -ls is better when you want to find out
the permissions of all the files, ls -lsh when you want to include hidden
files, ls -lg when you want to see the group that owns the files and
directories and so on. Basically, command line arguments. Would it be so hard
to design a system that parsed something like:

$ GET KGP CST 26 +-1 032
# GET trains from KGP to CST for the 26th of the present month.# show availability for the next day and the previous day.# show availability for ticket classes 2nd Sleeper (0), 3AC (3) and 2AC (2)$ GET KGP CST 4n +3 32
# KGP to CST on the 4th of the next month. Show avail for the next three days# as well. Show only for 3AC and 2AC

Given enough time, writing a fast parser (preferably in C, coming from the
benchmarks discussion in yesterday’s post) for these kinds of commands will
not be hard.

There are some major caveats to this post. Not in the proposals that I have
made, I beleive they are fine, definitely not rock solid because I know very
little about ticketing except from whenever I have booked tickets.

I don’t know if the TUI that they use is the VT220. That was from a Quora
answer dated December 2014. Things shouldn’t have changed in this short a
time.

The backend that Indian Railways uses. It’s so hard to figure out what
exactly they are using. There’s the website of the Centre for Railway
Information Systems, there is a dedicated
page to the Passenger Reservation
System with a “Technology” page. It
doesn’t mention if this is a project that’s being developed for later
installment, or it’s already being used everywhere. It’s all a bit shady.

Finally, I have seen Indigo (the airlines) use a similar TUI interface. They use
it for the generation of boarding passes and baggage tags at the check-in
counter. The people working on them are highly skilled at using these terminals.
So, clearly TUI has some advantage, whether IRCTC is tapping into all of it or
not is questionable to me. I will continue to try to dig up data about this, but
I get the feeling that that is going to be tough.