RE: The Social Phenomena that Leads to a Diversity of Data For
I had a similar experience about half a decade later (or maybe not but half-decade *technology* later) I was in charge of the Campus Student computers. A recent "Modern" replacement to the VAX/780s ... (which were in turn a replacement to the IBM/360 which went its merry way to JPL where it might still be in use today ... who knows). The "modern" replacements were 4 x DataGeneral MV4000 "Mini computers". Only 2 fridges tall instead of 5 ... One day one broke and we had to call the tech (suit, tie, briefcase etc). He came in and went with his list of diags to perform which he admitted were not in order of likely failure, but in order of cost to replace... ( hardware was still more expensive the human time). He tried booting the computer (no boot). The first question he asked me was "Did you turn the power off ?" ... Very sheepishly I said "What do you mean" ... The power was obviously ON ... he asked again ... "Did at any time you turn the power off ..." ... <duck> "Yes" ... "Oh well where do you store the microcode tapes .... " huh ??? Turns out you couldn't boot the device from power-down state to even the normal OS boot ... you had to boot Microcode FIRST which loaded in the microcode and only then could you boot from the OS tapes ... It had never crossed my mind that microcode would be in volatile memory ... ---------------------------------------- David A. Lee firstname.lastname@example.org http://www.xmlsh.org -----Original Message----- From: Cox, Bruce [mailto:Bruce.Cox@USPTO.GOV] Sent: Monday, August 22, 2011 3:43 PM To: David Lee; 'Costello, Roger L.'; email@example.com Subject: RE: The Social Phenomena that Leads to a Diversity of Data Formats and the Ensuing Data Interchange Challenges When I learned Fortran in college, a computer lab technician managed an inventory of all the locks on campus using punched cards and the glorious IBM 1130 complete with Selectric keyboard input device. His code was on the cards as well, "dumped" to punched cards each time he revised it. Loaded very fast, but if the IBM guys came in and rewired the back plane (1. Remove jacket; 2. Remove vest; 3. Remove back cover of 1130; 4. Spread out the paper wiring diagram; 5. Remove wires from back-plane pins as specified; 6. Add wires to pins, taking care to route as specified; 7. Fold up paper wiring diagram; 8. Restore back cover of 1130; 9. Put on and button vest; 10. Put on and button jacket), the code stopped working. At that point he'd retrieve his source deck, compile, and dump again. "... exactly the same machine ..." is no exaggeration. Oh, rats, I forgot to include "roll up sleeves" and "roll down sleeves." It was a ritual with them. Bruce B Cox Director, Policy and Standards Division, OCIO, USPTO 571-272-9004 -----Original Message----- From: David Lee [mailto:firstname.lastname@example.org] Sent: 2011 August 17, Wednesday 15:08 To: 'Costello, Roger L.'; email@example.com Subject: RE: The Social Phenomena that Leads to a Diversity of Data Formats and the Ensuing Data Interchange Challenges Not sure what this has to do with "Social Phenomena" but your description sounds accurate to my memory of 40 years of software development. And it mirrors not just data formats but also code portability. I was lucky at a young age to have exposure to a wide variety of OS platforms and the concept of writing software (then it was "C") so that it was "portable" was ingrained. Yet almost everyone I met had no such concept ingrained. The near-sighted wisdome was 'This will only every run on this one OS/Machine I'm writing it for so why should I put the extra effort into making it "portable" ? Its a waste of time ' Now that Data is the New Software I think the same rationale applies. Still not sure how this ties in with "Social" ... to me its more a matter of expectations, experience, and thinking ahead beyond the 1 inch in front of your face. And be willing to take the extra effort and *suffer* the performance costs of portability. I remember when it was considered "Efficient and Really Cool" to simply take a literal memory dump of a program and save it as an "a.out" format to save state. It was quick, efficient, and actually worked. It only took a few lines of code to save the entire program AND its entire set of data. You could launch the saved program and it picked up where it left off. Fast ! No reading in data files, no serialization. No abstractions. It just re-launched your program back in the same state as when it was left off. The Height of Genius. Except of course it was an awful hack that only worked on exactly the same machine as it was run on and only worked on a very few OS's and then was extremely prone to bugs and hacking. But hey. It was Very Cool Solution to a Real Problem. ---------------------------------------- David A. Lee firstname.lastname@example.org http://www.xmlsh.org -----Original Message----- From: Costello, Roger L. [mailto:email@example.com] Sent: Wednesday, August 17, 2011 1:53 PM To: firstname.lastname@example.org Subject: The Social Phenomena that Leads to a Diversity of Data Formats and the Ensuing Data Interchange Challenges Hi Folks, This is fascinating : The way software is developed has led to the situation today where there are various data formats. Programs are very often written speculatively, that is, without any advance understanding of how important they will become. Given this situation, little effort is expended on data formats since it remains easier to program the I/O in the most straightforward way possible with the programming tools in use. Even something as simple as using an XML-based data format is harder than just using the native I/O libraries of a programming language. In time, however, it is realized that a software program is important because either many people are using it, or it has become important for business or organizational needs to start using it in larger scale deployments. At that point it is often too late to go back and change the data formats. For example, there may be real or perceived business costs to delaying the deployment of a program for a rewrite just to change the data formats, particularly if such rewriting will reduce the performance of the program and increase the costs of deployment. The result? Many applications, each with their own data format, e.g. binary, text-not-XML, and text-XML. Comments? /Roger  Section 1.1 of http://www.ogf.org/documents/GFD.174.pdf _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: email@example.com subscribe: firstname.lastname@example.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format