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 : Y2K (Year 2000) Stocks: An Investment Discussion -- Ignore unavailable to you. Want to Upgrade?

To: TEDennis who wrote (7039)	10/23/1997 11:41:00 AM
From: Risky Business	Read Replies (1) \| Respond to of 13949

Complete Business Solutions, Inc. Earnings Up 270 Percent In Third Quarter Over Prior Year (Pro Forma)

To: TEDennis who wrote (7039)	10/23/1997 12:14:00 PM
From: C.K. Houston	Respond to of 13949

TED, Hope you don't mind ... Since BEMER is an IS-IT-MIS deal, instead of an embedded system issue, I moved the Bemer discussion here from the TPRO thread. Cheryl _____________________________________________________________________ BEMER DISCUSSION (PROS & CONS): exchange2000.com TEDennis exchange2000.com rob1 exchange2000.com Jim Wilke exchange2000.com Pete exchange2000.com Jim Wilke exchange2000.com TEDennis BEMER SOLUTION Web Site: bmrsoftware.com White Paper: bmrsoftware.com _____________________________________________________________________ ALL: Embedded processing uses "firmware" ... not "software. That's why Bemer doesn't apply here. This means the computerized instructions are permanently embedded into a computer chip and cannot be changed like software can. *To change "firmware", one must dismantle the equipment and replace the computer chip containing the coded instructions.*

To: TEDennis who wrote (7039)	10/23/1997 12:29:00 PM
From: tech	Respond to of 13949

TO ALL I would buy VIAS here. Buy signal this A.M. Last trade > 40 1/8

To: TEDennis who wrote (7039)	10/23/1997 2:03:00 PM
From: TEDennis	Read Replies (3) \| Respond to of 13949

All: Re: Bemer solution Technical discussion: (skip this if bits, bytes, and techno-babble bore you) This post documents my understanding of the technology underlying the solution "invented" by Mr. Bemer. It is not guaranteed to be accurate. My opinions only. My background: Currently retired. 25 years' experience in the software industry, in particular with IBM's mainframe platform. Spent primarily in designing, developing, implementing, and supporting software tools and related technology. IBM's mainframe architecture, beginning with the IBM-360 way back in the 60's, provided a means of intercepting program ABENDs (ABnormal ENDs). This was done to support the "instruction set" of the computer. There are hundreds of "opcodes" (operation codes, or individual instructions) that enable the computer to do what it does. A compiler takes source text that is 'readable' to humans and generates 'object code' that is understandable by the computer. Thus, a COBOL statement that MOVEs fieldA TO fieldB would generate an MVC (move characters) instruction of x'D2NNO111O222', where 'D2' is the opcode (MVC), 'NN' is the number of characters to be moved (minus one for reasons I won't go into here), 'O111' is the computer's address of the first operand (where the characters will be moved to), and 'O222' is the computer's address for the second operand (where the characters will be moved from). Note that for illustration purposes, this example is very simple and ignores the possibility that the data being moved could be display format or any one of several internal computer numeric formats. If the opcode is not understood by the computer, the IBM architecture will generate an abend for reasons of 'invalid opcode' (a S0C1 for you techies). These abends are capable of being intercepted and acted upon by the application program if they have initiated a STAE (Set Task Abnormal End) routine prior to the abend. At that time, the STAE routine can choose to ignore the problem and continue executing, or it could do whatever process it thinks it should do. There is also an ESTAE routine (Extended STAE), but that adds a complexity to the discussion that isn't necessary here. From what I can gather, Bemer's solution is to search the object code for opcodes that are numerical in nature (adds, subtracts, multiplies, divides) and modifies the opcode to be an invalid one. It also creates a table that contains the original opcode and its location within the object code. When the application program executes, the computer encounters the invalid opcode and generates the abend S0C1. Bemer's STAE (or ESTAE) routine gains control and determines if the abend is one that they caused. If not, the abend is passed on to the computer and normal abend processing continues. If it's a Bemer initiated abend, their STAE routine will do whatever numerical processing is needed, then continues executing as normal. Note that this abend intercept technique has been in use for many years. In fact, one of IBM's debugging routines uses it. TSO TEST is built around the same concept, except that it uses an SVC (SuperVisor Call). This allows assembler level programmers to debug code at the object code level. The S0C1 technique is used by some of the proprietary Testers on the market, such as Compuware's Expediter and Viasoft's VIA/SmartTest. This brings up an interesting 'gotcha' for Bemer. The debugging products set their own STAE/ESTAE's, so there will be a conflict if a programmer tries to use one of these debugging tools to fix their programs. This is not an insignificant problem. Many programmers have no idea how to debug their code without an interactive tester/debugger, where they can step through the logic at the source level (MOVE fieldA TO fieldB), and see the values of fieldA and fieldB. They have no idea what object code even looks like, or what the data underlying the interactive display looks like. This intercept method works fine on a stand alone application, but runs into several gotcha's with some of IBM's extensions. Online interactive Teleprocessing monitors such as CICS and IMS have their own requirements that cause the tester/debuggers fits. Add to that DB2 and cross memory functions, multi-tasking (where one 'mother' task controls the activity of several subtasks) ... wow ... lots of stuff to consider. If Mr. Bemer is trying to develop all this from scratch, he's got a long way to go. Another 'gotcha' is that the bits being used to identify the century will tend to get lost through multiple data type conversions. The bits work well in what is known as Zoned Decimal (ZD) format (also called numeric display). In hexadecimal notation (what the computer understands), 16 bits indicate the value of a digit. F0 through F9. '97 would be represented as 'F9F7'. Mr. Bemer's solution (and the '19T0' solution) is to 'fiddle' with the leftmost digit of the year to make it 'E9F7'. That's OK until the computer 'packs' the data into Packed Decimal (PD) format. The data then looks like '097F' (too much explanation required to explain that .. just believe it). Then, it could get converted to a binary format (even worse ... just believe it). Either way, converting it back to the 'Bemer' format would be impossible. The computer would format it as ZD since there'd be no way for it to know what the original format was. There are other gotcha's that I could come up with, but I have other activities to attend to. In summary ... this is not a silver bullet. Nobody has claimed it is, as far as I know. Mr. Bemer's comments definitely oversimplified it, which is why I thought it necessary to post this. His solution will work on some very simple COBOL programs where there were entry level programmers who knew nothing but 'display' format dates. I think it will run into the gotcha's noted above in the more typical programs encountered that have various date formats that must be handled. Regards, TED