Motivation of software professionals
in [JavaScript]
|
Prev: When writing html table to div, the data from table is unformatted
Next: multi file download with one click
From: Patricia Shanahan on 12 Feb 2010 09:45 Martin Gregorie wrote: .... > Until CODASYL changed the language spec, some time in the mid '90s, the > only way you could get the date from the OS was with the "ACCEPT CURRENT- > DATE FROM DATE." where CURRENT-DATE could only be defined as a six digit > field: > > 01 CURRENT-DATE. > 05 CD-YY pic 99. > 05 CD-MM pic 99. > 05 CD-DD pic 99. Punch cards were another major source of date information. They had limited character sets, could not depend on elaborate preprocessing before entry, and had a hard limit of 80 characters. Even if the input record used a lot less than 80 characters, there was a strong motivation to avoid wasting characters because of the complications if future changes took a record over the limit. I first became aware of the issue in 1970, and could not get any of my fellow developers to pay any attention to it. They may have been right, because the application I was working on was written in the NCR Century assembly language, and was defunct long before 2000. Patricia
From: Lew Pitcher on 12 Feb 2010 11:52 On February 12, 2010 07:23, in comp.lang.c, martin(a)address-in-sig.invalid wrote: > On Fri, 12 Feb 2010 07:16:33 +0000, Richard Heathfield wrote: > >> No, it was a bug that wasted a byte and threw away data. And it's still >> a bug - some of the "solutions" adopted by the industry just shifted the >> problem on a little, by using a "century window" technique. That will >> catch up with us eventually. >> > Lets not forget that up to some time in the '90s COBOL could not read the > century, .... using it's built-in date functions ... > which created a blind spot about four digit years in many IT > people, COBOL being the language of choice for many mainframe systems > (and a lot of minicomputers too, thanks to the quality of the Microfocus > implementation). > > Until CODASYL changed the language spec, some time in the mid '90s, the > only way you could get the date from the OS .... through the COBOL language itself ... > was with the "ACCEPT CURRENT- > DATE FROM DATE." [snip] Which is why "ACCEPT CURRENT-DATE" wasn't used very much in my shop. Rather, we read current-date using an external utility module ("TDDATE") which retrieved the full current date /and time/, and even adjusted it (if required by options) for start-of-business-day (i.e. dates changed at 8AM, not at midnight). I don't doubt that many other serious COBOL shops had similar facilities. -- Lew Pitcher Master Codewright & JOAT-in-training | Registered Linux User #112576 Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/ ---------- Slackware - Because I know what I'm doing. ------
From: MarkusSchaber on 12 Feb 2010 12:35 On 11 Feb., 22:49, "Bo Persson" <b...(a)gmb.dk> wrote: > MarkusSchaber wrote: > > Hi, > > > On 10 Feb., 22:53, Andy Champ <no....(a)nospam.invalid> wrote: > >> Can any locksmith or > >> burglar alarm maker guarantee that a building will withstand all > >> attacks for 12 months? _That_ is the equivalent of withstanding > >> all virus attacks for 12 months - and it's on a far simpler system. > > > Maybe not the locksmith itself, but there are insurance companies > > which calculate how high the risk is, and they take that liability. > > > For locks, cars, even airplanes, insurance companies do that all the > > time. But there are only a few cases where this is done for > > software. > > Is it? What about the software that controls the locks, cars, and > airplanes? As I said, only a few places. Try to find an insurance against word corrupting your PhD Thesis, and you'll understand. Markus
From: Brian on 12 Feb 2010 13:52 On Feb 12, 1:11 am, Leif Roar Moldskred <le...(a)huldreheim.homelinux.org> wrote: > In comp.lang.java.programmer Brian <c...(a)mailvault.com> wrote: > > > > > Imagine driving by a house and seeing a car in front with > > this sign -- "Free car." > > Imagine the cook at a soup kitchen storing raw and fried > chicken in the same container. > > Or imagine a company giving out away a free game as a marketing > stunt and the game turns out to have been infected with a virus > that formats the users' hard-drives. > > Or imagine the author of an open-source product not paying > sufficent attention and accepting a patch from a third party > which turns out to have included a backdoor, providing full > access to any system where the program is running. > You clipped what I wrote about revealing known problems. If I give someone a twenty dollar bill and later when they use that bill it is found to be a counterfeit, I don't think they will sue me unless they have some reason to believe I knew it was a counterfeit. Brian Wood http://webEbenezer.net (651) 251-9384 "And David longed, and said, Oh that one would give me drink of the water of the well of Bethlehem, that is at the gate!" 1 Chronicles 11:17
From: Leif Roar Moldskred on 12 Feb 2010 14:37
In comp.lang.java.programmer Brian <coal(a)mailvault.com> wrote: > > You clipped what I wrote about revealing known problems. Yes, because that doesn't really matter when it comes to legal liability. Well, that's not entirely true -- if someone can prove that you _did_ know about a flaw in the product, you're going to be in hot waters. But merely showing that you were ignorant of a flaw isn't sufficent to absolve you of liability: the cook in the soup kitchen isn't going to _know_ that the food he serves is contaminated with salmonella and Toyota didn't _know_ that their accelerator pedals were faulty. It's not whether you're aware of flaws in your work that matters, but whether you did your job properly and with due diligence. A cook who serves salmonella-infested food because the salad he'd bought had been contaminated at its point of origin is not liable, but the cook does so because he's failed to follow basic standards of hygiene and kitchen procedure _is_. -- Leif Roar Moldskred |