Today, I walked out of a meeting
We were in a design meeting for a new version of our communications software between our mainframe and the TCP/IP domain.
As our old software was lacking in several aspects, I wrote new software that is beeing used by ever more projects, and is working flawlessly for the last two years, but it is not the expensive enterprise package that is officially supported, so management ordered a merging of my software with the old package.
First the old school tried to make Unisys - the supplier of the old package - to rebuild it to include my functionality. But Unisys refused: they said the architecture is old technology and they don't want to support it anymore.
Then the old school dropped the rebuilding project into the lap of the general infrastructure department, who asked me to cooperate. I agreed in first instance. But when the old school insisted on using this old architecture and refused to change it I said: no thank you, do it yourself, and I left the meeting.
This will now escalate to the general manager who ordered the integration.
Anyway, I don't have a mortgage, which is nice.
Almost H. Anonymous
January 13th, 2006
Wow. You're such an asshole.
Your opinion is shared by some of my colleques.
But not by all.
Old School reminds me of the people who want to repaint the fungus-stained house without repairing the plumbing.
> Wow. You're such an asshole
It's unisys. He's a hero. But like all heros he needs to walk off into the sunset now.
son of parnas
January 13th, 2006
The problem is you are an employee, not a vendor. Now instead of writing a check for support, they have to keep you around (or someone) to maintain the software.
This is an opportunity - look around at small companies who would be willing to buy the code and sell it to the company you work for.
January 13th, 2006
I'm on Eric's side. If he is the key person who has designed the system and without whom the project can not proceed, who are these other people being the boss of him? calling them on their bs is muy apropo.
January 13th, 2006
Also Erik, I would have a list of not-completely-unreasonable demands prepared for the inevitable showdown.
"You must do this."
"No. Here is how it is. I designed the system. I know how it works. I can implement the new system to work flawlessly. But it has to be done the correct way. These others know nothing of the correct way. They did not design it. They do not know. It is pointless to do something like that because you will be unhappy with the result. I will do this for you, but I will be the project manager and I will be paid commesurate with that title and responsibility, a yearly salary of 4X. There will also be a X bonus on completion."
"You are insane! Do as I say or you'll never work in this town again."
"That is an inappropriate remark. You are not a designer. I have enjoyed working with you and wish you the best."
Then when they call begging for you to return, the new value is 6X, profit sharing and 3X bonus on completion, plus a much better private office.
January 13th, 2006
As Joel once said - Coconut herd management is visible here. Eric (who has most knowledge to take the decision) is not the one who has the final say; sad, but that's the sign of a pointy haired boss.
My major objection to the old system is that it is a hodge podge of technologies that we do not support in our regular developer environment. One needs a special installation with licensed components of which there is only one for all of development, and when you start testing, the whole development environment will be disrupted.
Any changes on such a beast takes months of preparation and committees with too many disagreeing members, so we are not agile in adding new features to our protocols. Features that are required by new projects.
The old school calls this 'stability', I call it a standstill.
Anyway, I have been called at home last night, and I do have important support in the escalation process, so my weekend has improved considerably.
Offbeat mainframe TCP/IP stacks suck and blow in their own sweet way and *can* provide all tools necessary to accomplish *any* given task such as CALL OPENPT() or even openport(), send(), listen(), stat() ... close(). This humble opinion is based on my fortunately limited experience which was nowhere near Unisys gear.
But why in God's name do you only have one licence? And by the sound of it one development environment? By now you should be able to pick up a junker secondhand system at a swap meet or some goingOutOfBusiness auto manufacturer's realisation auction and be able to develop and test in parallel once the s/w licences are sorted out.
Or perhaps your management want the moon for sixpence.
++you for building a workaround replacement. But I'm still a little confused as usual - does your opus run on the Unisys gear or emulate/replace its functionality elsewhere?
January 14th, 2006
Origially external communication with the mainframe ran on X.25 but this has been phased out.
Than in the mid nineties the communication between our middleware and mainframe was based on Tuxedo - which is a waste, because we don't use any transactional coupling between layers.
The historical reason is that Unisys used to own (part off?) Tuxedo, and had an interest in placing this technology with their customers. This situation has changed, because Tuxedo is now owned by Bea, and license fees (200,000 per server per year) are a burden.
Unisys built a gateway inside the Tuxedo technologie, a Tuxedo server application on Windows, that processes the messages and routs them to the mainframe that has a Tuxedo interface. The front-end to the Tuxedo server is an asp page that communicates via a special Com component.
The combination Tuxedo server and com-component must run in a special environment, of which we only have three: development, test and production.
Development is used permanently by all developers in their work, Test is used permanently by all our testers and by external clients testing their software, and Production is production. There is no sandbox.
My solution is nothing special, I just pass by all functionality in the Tuxedo Gateway Server Application, moving it up to the level of the Web Application, and I only use the Tuxedo protocol directly to rout to a new mainframe service. Here I disentangled the transmission layer from the processing logic, routing old messages back into the existing software, and forking xml into a custom COBOL written xml parser. This way we could use larger messages and use digitally signed messages.
In the front end I transform new message formats into old when needed for backwards compatibility. And we can add new features by putting transformers on top of the basic transport layer.
And I hope we can replace the Tuxedo protocol with something else in the future, which would be very simple because it is now a transport layer without embedded logic.
Unisys maintained the server application - or rather didn't maintain it at all. The old school wants to put the buziness logic inside the Tuxedo server, which we will have to maintain ourselves then, using a combination of C++, visual basic, asp and com in a special environment. Meanwhile Tuxedo is based on independant processes instead of threads running in a common memory space, so dynamic configuration is impossible.
I want to put all logic on the webserver - my version of which is now implemented in Delphi, but I propose to change that to C#. (and get rid of Tuxedo over time, but that is an independant issue, as it will be a pure transport layer).
Thanks, Erik. Hard to ignore the distortion 200,000 clams/licence/annum introduces if that's in the sandbox.
If you now bypass Tuxedo functionality for new message formats, can show how you could do the same for old formats and then replace its transport layer *and* explain the how and why to the technically challenged in monetary terms I'd say you have a bloody good case.
A weak spot may be the effort required to replace the old message formats but savings achieved by eliminating Tuxedo and consequent futureproofing should cover a lot of it.
You may be asked what's the current worth the annual licence fee? What's the risk in being tied to obscelescent middleware? What can you save in support skillsets?
And whose career is being threatened by your proposal?
Best of luck in the bunfight.
January 14th, 2006
"A weak spot may be the effort required to replace the old message formats"
The effort is already done.
My current solution supports old and new formats. Everything is backwards compatible.
The only modification needed in my solution to completely replace the old gateway is adding a configuration layer to distribute messages for different systems over different backendservers - which is a safety measure that one system failing cannot bring down others.
I only propose a rewrite of the Delphi solution into C#, because it offers a richer library regarding web-services and other developements like cryptography, where Delphi is staying behind.
The actual rewrite will be less then 300 lines of code.
It is not rocket science.
As for the threatened positions: the major threat is to the administrators of the Tuxedo servers - two fulltime positions. And the filosofical principal of 'Buying a Supported Enterprice Solution with Support'. But the latter was already broken by Unisys who cancelled their support.