Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : FBN Associates - Year 2000/Y2K IPO!!! -- Ignore unavailable to you. Want to Upgrade?

To: Blue On Black who wrote (2125)	11/18/1998 5:35:00 PM
From: TEDennis	Read Replies (1) \| Respond to of 2770

lee: Re: Assembler to Fortran ... I agree. Wimpified. My first Assembler programs had to run in 1024 bytes of memory. They were application programs for an IBM mainframe bank teller system called FTS (Financial Transaction System). It was a pseudo multi-tasked system. Lots of functionality, so there were lots of itty bitty routines that were called by a very cute driver program. The entire system, TP monitor and teller application, ran in less than 512K. We converted it to IBM's CICS OS Standard Version 1.3. First successful implementation of a 2980 Teller Terminal system under CICS. It ran like a champ. Sub-second response time. We were tickled pink. Proud of our new baby. Then, the wizard in charge of R&D decided that he was tired of paying high dollar amounts for Assembler programmers, so started hiring entry level COBOL programmers for 1/3 the dollars. Any new functionality was developed in COBOL. That particular version of CICS was very sensitive to program cacheing. The cache mechanism worked beautifully on the 1K Assembler segments because they were all the same size. But, the first time one of the tellers used one of the new COBOL functions, the entire system response time degraded. The COBOL routines were upwards of 12K each, so 12 high accessed Assembler routines got "swapped" out (Note that swapping didn't exist in pre-VS systems) for a rarely used COBOL function. Then, each time one of the high accessed Assembler routines was needed again, it had to wait for the COBOL function to complete before it would get reloaded. Our sub-second response time all of a sudden became several seconds. And, if another teller requested the same COBOL function before the Assembler routines were reloaded, it got priority. Response time got worse and worse. It stayed pretty much unacceptable until we converted to CICS/VS with its vastly superior cacheing methodology ... and a larger, more powerful mainframe with lots more memory. Heck, it only cost a few million bucks. More. I learned a couple of important lessons from that experience. 1) If you have a finely tuned system, don't f... uh, mess with it. 2) Don't let non-technical managers make technical decisions. TED