TFCS Replacement?

curiousbrain

Well-Known Member
I hate to necropost and drag this thread up, but ... I'm going to, anyway. I was marveling about it at work, but no one there really understood what I was saying.

I have recently been exposed to TFCS, and my god - talk about archaic. As someone who is familiar with telnet and terminal driven consoles, I actually couldn't believe what I was looking at. I half expected to look under the desk and see a drum and a stack of punch cards. I love a good terminal, but if I feel nostalgic I'll telnet to a BBS.

I was really surprised, I guess is what I'm trying to say.
 

TechGrrl

Space Cadet
I hate to necropost and drag this thread up, but ... I'm going to, anyway. I was marveling about it at work, but no one there really understood what I was saying.

I have recently been exposed to TFCS, and my god - talk about archaic. As someone who is familiar with telnet and terminal driven consoles, I actually couldn't believe what I was looking at. I half expected to look under the desk and see a drum and a stack of punch cards. I love a good terminal, but if I feel nostalgic I'll telnet to a BBS.

I was really surprised, I guess is what I'm trying to say.

Speaking as someone retired from the group responsible for maintaining TFCS, and who was part of at least 3 failed attempts to replace it, it's worse than you think. TFCS duplicates most of the functionality of Load Handling. They are both archaic, mainframe based systems. Unfortunately, when a company considers IT to be a cost center to be penny-pinched, rather than a strategic strength, cost-justifying replacement is almost impossible. Ongoing maintenance of both of those systems is only maybe a million dollars a year, being generous. A replacement project would be in the tens of millions, assuming the Air guys and the ground guys could agree on a common functionality. Which they never have, and never will.

To paraphrase Hillary Clinton's supporters in 2008: "Company Unity My A&&!" or CUMA!
 

Necropostophiliac

Well-Known Member
I hate to necropost and drag this thread up, but ... I'm going to, anyway. I was marveling about it at work, but no one there really understood what I was saying.

I have recently been exposed to TFCS, and my god - talk about archaic. As someone who is familiar with telnet and terminal driven consoles, I actually couldn't believe what I was looking at. I half expected to look under the desk and see a drum and a stack of punch cards. I love a good terminal, but if I feel nostalgic I'll telnet to a BBS.

I was really surprised, I guess is what I'm trying to say.

Re "I hate to necropost and drag this thread up, but ... I'm going to, anyway"

I could not have done better myself.
 

curiousbrain

Well-Known Member
Speaking as someone retired from the group responsible for maintaining TFCS, and who was part of at least 3 failed attempts to replace it, it's worse than you think. TFCS duplicates most of the functionality of Load Handling. They are both archaic, mainframe based systems. Unfortunately, when a company considers IT to be a cost center to be penny-pinched, rather than a strategic strength, cost-justifying replacement is almost impossible. Ongoing maintenance of both of those systems is only maybe a million dollars a year, being generous. A replacement project would be in the tens of millions, assuming the Air guys and the ground guys could agree on a common functionality. Which they never have, and never will.

To paraphrase Hillary Clinton's supporters in 2008: "Company Unity My A&&!" or CUMA!

That's a damn shame; as a person who generally sees technological progress as a good thing, it baffles me why this company does certain things the way they do. As it does others, I'm sure.

I may have a more substantive response later this week, as I plan to play around with TFCS after the shift.

At the very least, though, why hasn't someone written a better interface for TFCS? At the center where I am employed, it is a character-driven, telnet application; if I can't find a better one, I'm thinking I might do some research into trying to use Access/VBA+OLE (seems to be the UPS standard to some extent) to provide something nicer. Assuming there is a library to get data from the telnet application in an ordered way, and not resorting to screen scraping, of course.
 

TechGrrl

Space Cadet
That's a damn shame; as a person who generally sees technological progress as a good thing, it baffles me why this company does certain things the way they do. As it does others, I'm sure.

I may have a more substantive response later this week, as I plan to play around with TFCS after the shift.

At the very least, though, why hasn't someone written a better interface for TFCS? At the center where I am employed, it is a character-driven, telnet application; if I can't find a better one, I'm thinking I might do some research into trying to use Access/VBA+OLE (seems to be the UPS standard to some extent) to provide something nicer. Assuming there is a library to get data from the telnet application in an ordered way, and not resorting to screen scraping, of course.


Several attempts to do what you describe have failed. Unfortunately, due to the current technology, screen scraping is the only way to make it work.
If you are that techno-literate, you should be applying for jobs in IT applications. The development group for these systems is in Louisville. Go for it!
 

curiousbrain

Well-Known Member
Several attempts to do what you describe have failed. Unfortunately, due to the current technology, screen scraping is the only way to make it work.
If you are that techno-literate, you should be applying for jobs in IT applications. The development group for these systems is in Louisville. Go for it!

I don't have a degree; it disqualifies me from ... pretty much most jobs.
 

curiousbrain

Well-Known Member
Several attempts to do what you describe have failed. Unfortunately, due to the current technology, screen scraping is the only way to make it work.
If you are that techno-literate, you should be applying for jobs in IT applications. The development group for these systems is in Louisville. Go for it!

I was looking for something to do, and this just happened to be what I worked on today; I was looking for an excuse to do something quasi-technical lately, so that didn't hurt, either. Forgive me for being longwinded, but when I am interested in something I tend to attack it with a certain vigor that others occasionally find ... annoying; you might say I inform them against their will. I apologize in advance for that, as well.

It is screen-scraping, but someone else has already done the dirty work; and in a good (portable) way. The link is here.

I first went at the problem with the 3270 terminal emulator we use at the building where I am employed, and I was going to try to do the Access/Automation thing I mentioned the other day, but it soon became apparent the functionality exported by the emulator lacked the precision required to extract the relevant data without a massive amount of string-fu, which seemed unacceptable.

Then, I thought I could maybe write my own 3270 terminal routines, that could provide the degree of control necessary; then, I really thought about what that would entail, and that UPS would probably never let me do that anyway, so I quickly moved on from that idea.

Then, I found the `s3270` script that h3270 uses under-the-hood, which led me to the program in question. Which, I have setup myself, and really is pretty nice.

The basic gist is that it passes the terminal screen through a filter of regular expressions, and the resulting text is considered as HTML, and rendered as such in the browser. For each screen of the terminal, it searches for a matching regex, and uses that to render the screen in question; go to another screen, it runs a different set of expressions. This way, you can tailor each menu screen as you want - which is nice, I would think, because you could have a regex that matches every menu, or just one. These regex expressions also have the ability to make calls to Java, if any truly special purpose mangling is needed.

I mean, the upshot here is that, from a complexity standpoint, once the basic foundation is setup, you only have to hire people to do basic HTML (a fairly cheap skill, I would imagine), and not write epic string-fu code that has to be completely reworked every time a character is moved or the terminal hiccups. And, the programs in question are entirely free, so that's nice.

The downside, obviously, is that nothing will ever become of this and this is nothing more than a mental exercise for me; but, I'm content because I feel like it could work.
 

TechGrrl

Space Cadet
I was looking for something to do, and this just happened to be what I worked on today; I was looking for an excuse to do something quasi-technical lately, so that didn't hurt, either. Forgive me for being longwinded, but when I am interested in something I tend to attack it with a certain vigor that others occasionally find ... annoying; you might say I inform them against their will. I apologize in advance for that, as well.

It is screen-scraping, but someone else has already done the dirty work; and in a good (portable) way. The link is here.

I first went at the problem with the 3270 terminal emulator we use at the building where I am employed, and I was going to try to do the Access/Automation thing I mentioned the other day, but it soon became apparent the functionality exported by the emulator lacked the precision required to extract the relevant data without a massive amount of string-fu, which seemed unacceptable.

Then, I thought I could maybe write my own 3270 terminal routines, that could provide the degree of control necessary; then, I really thought about what that would entail, and that UPS would probably never let me do that anyway, so I quickly moved on from that idea.

Then, I found the `s3270` script that h3270 uses under-the-hood, which led me to the program in question. Which, I have setup myself, and really is pretty nice.

The basic gist is that it passes the terminal screen through a filter of regular expressions, and the resulting text is considered as HTML, and rendered as such in the browser. For each screen of the terminal, it searches for a matching regex, and uses that to render the screen in question; go to another screen, it runs a different set of expressions. This way, you can tailor each menu screen as you want - which is nice, I would think, because you could have a regex that matches every menu, or just one. These regex expressions also have the ability to make calls to Java, if any truly special purpose mangling is needed.

I mean, the upshot here is that, from a complexity standpoint, once the basic foundation is setup, you only have to hire people to do basic HTML (a fairly cheap skill, I would imagine), and not write epic string-fu code that has to be completely reworked every time a character is moved or the terminal hiccups. And, the programs in question are entirely free, so that's nice.

The downside, obviously, is that nothing will ever become of this and this is nothing more than a mental exercise for me; but, I'm content because I feel like it could work.

Once upon a time, larger districts and the regions had an IE group that did local applications. If there is such a group in your district, you should contact them and apply for a job in that group.
 

SDFOX 7

New Member
Speaking as someone retired from the group responsible for maintaining TFCS, and who was part of at least 3 failed attempts to replace it, it's worse than you think. TFCS duplicates most of the functionality of Load Handling. They are both archaic, mainframe based systems. Unfortunately, when a company considers IT to be a cost center to be penny-pinched, rather than a strategic strength, cost-justifying replacement is almost impossible. Ongoing maintenance of both of those systems is only maybe a million dollars a year, being generous. A replacement project would be in the tens of millions, assuming the Air guys and the ground guys could agree on a common functionality. Which they never have, and never will.

To paraphrase Hillary Clinton's supporters in 2008: "Company Unity My A&&!" or CUMA!

I know this is an old thread but I just happened to come across this post in a web search and wanted to contribute my two cents.

I personally like using TFCS. I have been using it for nearly 13 years and know it very well. I can log into it with my eyes closed since it is completely keyboard based and you don't need a mouse.

To second TechGrrl, TFCS likely will never be replaced. I was recently speaking to a tech who stated that there are a few reasons TFCS will not get replaced.

In order of significance:

1) There is zero ROI. It is not cost-effective, and there is no benefit to UPS at all, to replace this working system which has functioned successfully for decades. Two of my favorite business terms that apply to this are ROI and cost-benefit analysis.

2) See #1.

3) 100% required uptime. It would be difficult if not impossible to replace TFCS because you would lose visibility and tracking on millions of packages possibly opening UPS up to claims. I believe this is the same situation with COMPASS which is used worldwide for UPS Airline operations.

4) Assuming that a replacement could be designed, you would have to know exactly how TFCS works to duplicate it. Many of these people are probably no longer with UPS. Again, even if you could, this brings us back to #1.

5) Many drivers in many buildings are beginning to use their tractor computers to auto depart and auto arrive. This makes it even less appealing to UPS to spend millions to upgrade a system that is being supplanted by another system.

6) The interface is about 30 years past due, but since TFCS is only used internally and is not customer facing, who cares? Go to the airport, they are also running command line systems like SABRE for arrivals and departures.
 
Top