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 : TAVA Technologies (TAVA-NASDAQ) -- Ignore unavailable to you. Want to Upgrade?

To: Kevin Podsiadlik who wrote (22575)	8/23/1998 1:16:00 PM
From: Larry Voyles	Read Replies (1) \| Respond to of 31646

Interfaces between disparate systems on varying platforms almost always exchange data in "clear-text", so the date "1/1/1990" will get exchanged as "010190". Data is exchanged and forwarded on to innumerable systems of differing type, so using bytes to "pack" data is not always a good thing. Conversion between EBCDIC and ASCII is implementation-dependent and not always an exact science. Conversion between the ASCII and EBCDIC representations of "0"-"9" are rarely misinterpreted. If we packed two digits into each byte, God knows what would come out on the mainframe side of a file transfer. I've heard many theories as to how this date problem is easily solvable using various mathematical devices, but rarely do people think on how to implement the solution across an entire enterprise. If one has to communicate similar data to two UNIX boxes (of differing flavors), three AIX boxes, two different versions of MVS (one IBM, one HITACHI) and a crufty old version of CMS, implementing byte-packing becomes a headache of grand proportions.