How does Amtrak Arrow system work?

Amtrak Unlimited Discussion Forum

Help Support Amtrak Unlimited Discussion Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Is there any crazy way to change Arrow? Maybe start taking reservations after a certain date ? Call it transition date. Could the opening page send any reservation request to either the old system or the new one ? Same when making a telephone reservation. Computer systems completely separate. For riders changing reservations across the transition date manual agent input will be required. Same for bonus points.
 
The thing's a mess. Lacking code-data separation and lacking full structured programming and lacking full modularization make it a very bad system from a maintenance perspective -- you can do code-data separation and structured programming and modularization in machine language, but apparently they didn't.
Unfortunately in the early days when writing code in 360 Assembler was the thing to do for performance, code-data non-separation was viewed as a feature, not a bug. There were kludges even in high level languages like Fortran to enable such like the famous EQUIVALENCE statement. I think the reason was because one had to play incredible games to fit the functionality that you wanted into the meager hardware capabilities that were available. Of course, I am sure no one imagined that Amtrak among others would still be using that stuff.
 
Back in the early days of programming computer memory was limited and a premium. Coders learned to write clean, efficient code so that it could work within the confines of such memory limitations.

Now, memory is plentiful in most systems. Coders can afford to be "sloppy" with their code and, as a result, some programs/apps become so bloated that it is hard to navigate the code - even to the point they just "write around" badly coded routines instead of removing them or cleaning them up.
 
Unfortunately in the early days when writing code in 360 Assembler was the thing to do for performance, code-data non-separation was viewed as a feature, not a bug. There were kludges even in high level languages like Fortran to enable such like the famous EQUIVALENCE statement. I think the reason was because one had to play incredible games to fit the functionality that you wanted into the meager hardware capabilities that were available. Of course, I am sure no one imagined that Amtrak among others would still be using that stuff.

Jis - You clearly remember those 'Thrilling days of yesteryear" when trying to squeeze everything into 64K (not Meg, not Gig) of core (tiny ferrite circles with 3 wires going through each, replaced with solid state RAM these days) wasn't an easy task. I was overjoyed when the R&D shop I was at upgraded their 360/40 to 128K! We didn't have to fight so hard to 'make it fit'.

Making things run in a 4K 1401....now THAT was an ART! Been there, done that, too!
 
Is there any crazy way to change Arrow? Maybe start taking reservations after a certain date ? Call it transition date. Could the opening page send any reservation request to either the old system or the new one ? Same when making a telephone reservation. Computer systems completely separate. For riders changing reservations across the transition date manual agent input will be required. Same for bonus points.

If only it was that simple.

In most 'working system' upgrades/replacements, what is typically done first is a very detailed, thorough examination of every program & system being replaced by someone very knowledgeable in the 'old' system design, hardware limitations that had to be dealt with, and so on. 'Catching' the subtleties such as data passed between concurrently running programs via absolute addresses are just some of the fun and games to deal with. And, of course, if there ever WAS any written documentation about the old programs, it's long gone or so woefully out of date it's useless. Hopefully, the assembler (or any other language) programmer had extensive documentary comments in their programs. Sometimes that's the best documentation. Other times, it's laboriously read through code, line after line, and determine what it's doing and how it relates to everything else. Of course, all that gets written down in case they unexpectedly drop dead. (I had a co-worker die in a car accident that took the group I was working in several months to figure out what he left behind, etc)

THEN that knowledgeable person, if not also knowledgeable in the new hardware/software environment, must essentially perform a Vulcan Mind Meld into the new system design person(s), then look over their shoulder to ensure that the same functionality and 'tricks' will exist in the new system.

THEN it comes time to design various data transfer methods to take the data from the old system to the new. One of the strangest data formats I encountered were files with 16-BIT dates (7 bits for 2 digit year (0-128), 4 bits for month (0-16) and 5 bits for day (0-32))! Data storage had to be absolutely minimized due to slow and low bits-per-inch tape drives as well as disk drives. I've seen 'screaming' fast IBM 7090s' wait in SECONDS while the single head of a multi-platter disk drive comes out of the platter, slowly moves up or down several platters, then extend the head into the platters and wait for the rotational delay to get some data. In later years, 'data cells' (strips of computer tape hanging from a wheel and being individually selected to be read, similar to a jukebox) on an IBM 360/75 system cause it to spend considerable time idling ('wait' light) despite having 8-10 jobs in the mix. The 'tighter' one could compact the data, the better. As a result, various data extract/conversion programs have to be designed and written to transfer the data from the old system to the new.

Perhaps the biggest data conversion I ever wrote was while at a 'Baby Bell'. I had to extract everything for each customer (in their semi-unique CRIS systems) in each billing cycle from the IMS 'hierarchical' database and populate the marketing DB/2 relational database that had several trillion rows of data on it. It also required data extraction programs on all the 'exchange' computers (switches) to identify their capabilities and the 'area code + prefix' (NPA/NNX) for various needs in the DB/2 data base. Oh...and it had to run on/link to/extract from roughly a dozen mainframe 'images' spread across 5 states! Needless to say, I spent countless hours with the chief CRIS programmer to learn the ins and outs of 'telephony', and then pick the brains of the DBA for the DB2 data base. Fortunately, the chief CRIS programmer and myself were part of the database design team, although not a part of the daily design discussions. It took well over a YEAR just to write and fully verify that data conversion! There's far, far more to 'Ma Bell' than POTS...Plain Old Telephone Service.
 
Last edited:
Jis - You clearly remember those 'Thrilling days of yesteryear" when trying to squeeze everything into 64K (not Meg, not Gig) of core (tiny ferrite circles with 3 wires going through each, replaced with solid state RAM these days) wasn't an easy task. I was overjoyed when the R&D shop I was at upgraded their 360/40 to 128K! We didn't have to fight so hard to 'make it fit'.

Making things run in a 4K 1401....now THAT was an ART! Been there, done that, too!
Having built a PASCAL interpreter to fit in 16k of 16bit RAM on an IBM 1130, using eventually an 8 pass system using the LOCAL (Load On CALl) feature profusely, among other thrills (The PASCAL system was my Comp Sci Masters Thesis in India) yes indeed I have experienced all those thrills. In some sense they were really the wild west days of Software Engineering, which should have really been called Software Art or something like that, since there was very little Engineering discipline in place for anything back then.

At Bell Labs I was on the Digital PBX Controller side of things in Area 43 and 44 (Antelope and Gazelle were the pioneering digital PBXs which actually used a real CSP (Communicating Sequential Processes) paradigm operating system, an in house one called Oryx/Pecos developed at the Denver Labs. My main focus was on architecting and proving out various distributed call processing techniques. So I was relatively far removed from the very difficult data analysis side of things. All that we had to do was create CDR (Call Detail Records) in a format specified by the database folks and spit em out on CDR tapes to be delivered via USMail or Company trucks to the CDR processing centers.
 
Having built a PASCAL interpreter to fit in 16k of 16bit RAM on an IBM 1130, using eventually an 8 pass system using the LOCAL (Load On CALl) feature profusely, among other thrills (The PASCAL system was my Comp Sci Masters Thesis in India) yes indeed I have experienced all those thrills. In some sense they were really the wild west days of Software Engineering, which should have really been called Software Art or something like that, since there was very little Engineering discipline in place for anything back then.

At Bell Labs I was on the Digital PBX Controller side of things in Area 43 and 44 (Antelope and Gazelle were the pioneering digital PBXs which actually used a real CSP (Communicating Sequential Processes) paradigm operating system, an in house one called Oryx/Pecos developed at the Denver Labs. My main focus was on architecting and proving out various distributed call processing techniques. So I was relatively far removed from the very difficult data analysis side of things. All that we had to do was create CDR (Call Detail Records) in a format specified by the database folks and spit em out on CDR tapes to be delivered via USMail or Company trucks to the CDR processing centers.
Got it! Not!! LOL
 
It is amazing how much things have changed in computer programming from the early days to current days. I am astounded that it appears to be financially and logistically impossible to replace Arrow.

The seat reservation system in Europe was really an amazing process to observe when I first visited Europe in 1990. I planned a detailed Itinerary using the Thomas Cook timetable. Then I called rail europe in the United states and gave them dates and train times and/or numbers and specifically requested window seats on all segments. A month or so later, an eternity to me back then, the rail pass and seat reservations arrived in the mail. I joyfully examined each one as I read exotic station names such as Frankfurt Haubptbahnoff or Paris Gare de Lyon. Once I got to Europe the system worked flawlessly. Each seat reservation resulted in a window seat. For some reason I was not successful in getting seat reservations for trains in Italy, nor for the Trans-Alpine express from Basel to Salzburg. I still obtained a window seat on the Transalpine express by walking through several first class cars until I found a vacant window seat in a compartment. A trip that I will never forget.
 
My experience was that in non-English speaking countries, train agents at stations were difficult to communicate with when requesting "forward-facing seats". One had to know the local word for that because apparently not many foreigners asked for such seats. Not just Americans but since many Europeans back then (pre-EEC days) spoke English as a second language so an Italian in Germany e.g. would often attempt to communicate in English with someone in another country. Computerizing made that so much easier.
Amtrak apparently doesn't speak English well when requesting specific seat types.
 
Oh, Amtrak will replace Arrow, it's just a long and slow process.

Don't ask about the upgrades of the computer systems and paperwork processes in the US Department of Defense. (The Army, in particular, is utterly horrific, with forms dating from the 1940s where you're supposed to fill out different things than the form says you're supposed to fill out -- parts of the forms have actually been declared unconstitutional, and they're still using them.)
 
Speaking of records and federal government, a friend of mine who worked for many years at NIST finally decided to retire, and he put in for it. He was told that he could not do so quite yet because they couldn't find his hiring record!!!! It took them several months of riffling through paper records in some sub basement in Washington DC to finally find his hiring record from back in the early '70s or late '60s, and he could finally retire.
 
Just cleaned out my “archives”, and found a manual for the pre-Arrow, “ARTS” system...had forgotten about it...🙂
 
Speaking of records and federal government, a friend of mine who worked for many years at NIST finally decided to retire, and he put in for it. He was told that he could not do so quite yet because they couldn't find his hiring record!!!! It took them several months of riffling through paper records in some sub basement in Washington DC to finally find his hiring record from back in the early '70s or late '60s, and he could finally retire.
The Canadian federal government insisted that I and my Social Insurance number did not exist. Eventually I had to hire a Vancouver, BC immigration lawyer who tracked down the fact that Immigration files from the 1970's were not coming through on the Service Canada computers. The paper copies had been disposed of once they were scanned. I resubmitted everything to Winnipeg in August including the law firm's explanation of their interface problem and have not heard from them yet.
 
Back
Top