Cobol's File System Vs. RDBMs...
in [Cobol]
|
Prev: COBOL: Don`t Call It a Comeback
Next: All X'0D' lost during reading line sequential file using microfocus se
From: Howard Brazee on 28 Jul 2008 09:46 On Sat, 26 Jul 2008 12:24:39 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: >> Instead, we need to have established rules that are more complex than >> assigning a particular owner for a specific datum. > >Why? > >In today's world data can be easily shared by people who are authorised to >access it. My post has never suggested that only ONE "owner" should be >authorised. I am trying to make the point here that data is NOT owned >exclusively by IT, that's all. Data have never been exclusively owned by IT, so I was looking for some more meaning in your statement, and the question of ownership beyond the obvious owners (who also have never been IT). I guess I'm still missing your point.
From: Howard Brazee on 28 Jul 2008 10:03 On Sat, 26 Jul 2008 12:41:45 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: >> Obviously, neither should IT. But IT needs to enforce the guidelines >> that the enterprise and society demand. > >OK, so you see IT as being the "Data Police"? I really don't care who's responsible for enforcing necessary guidelines. IT needs to be involved though. >I don't. Who do you see as being responsible for enforcing privacy, security, and other corporate and governmental guidelines? >It would appear that both you and Doc have pushed my argument beyond where I >wanted it to go. It's not at all obvious where you wanted it to go. An earlier post indicated that all you were interested in is saying IT isn't the exclusive owner - but nobody has ever made any argument against that. >What about companies that don't have an IT department? (They outsource their >Network support and run packages and spreadsheets...) What about places >where the "IT department" is about Network support and Helpdesk? (There are >more and more of these arising...) The outsourced IT still has to enforce user, corporate, and legal guidelines. Heck, even the one-man coffee house needs to handle data within legal guidelines. It doesn't matter whether the IT is a department, outsourced, or a set of index cards with customer names and phone numbers on it. >In the last century when all data processing was the province of the IT >department, who administered the central mainframe repository, the idea >arose that IT were the professionals and the ONLY ones who should be allowed >to deal with data. This is the first I have heard of that. What in the world would such a shop do with the data that they didn't allow its customers to deal with? Why would the enterprise pay for IT if they couldn't deal with the data? This is silly, and past experience reading your insights leads me to assume the misunderstanding is on my side, and that you aren't seriously saying that the Big Brother is IT. >The only point I'm trying to make here is that in today's world data can be >easily shared and access to it controlled by configurations. It doesn't need >the data police or IT as "Big Brother" telling people what they can do with >their data. I never suggested (in fact quite the contrary) that there would >be no audit trails or checks and balances, or implementation of corporate >policy regarding information. All I'm saying is you don't need "IT" to do >this, and, in fact, it is far better when the business are responsible for >their own data. If Big Brother is the state, we do need to comply with their rules. If Big Brother is the enterprise, we do need to comply with their rules, when they don't conflict with the state's rules. If Big Brother is the users, we do need to comply with their rules when they don't conflict with the enterprise's rules or the state's rules. For me, "we" is IT, and we cannot abrogate our responsibilities to the enterprise nor the state just because the user "owns" the data. >That's it, no more from me on this :-) But you did ask questions in this post, so I replied.
From: Howard Brazee on 28 Jul 2008 10:12 On Sat, 26 Jul 2008 09:44:01 -0500, "Michael Mattias" <mmattias(a)talsystems.com> wrote: > >Having been a businessman long before I was a 'geek,' I can agree.. but >with one observation/stipulation .. > >Seems to me not a whole lot of users actually get around to making that >replacement... that is, for these users tomorrow never comes. I have observed the same thing. Balancing between what we should do if we had discipline and wisdom, with what we really do is never easy. Look at all the policies that are in place to make sure users keep unique, secure passwords as an example.
From: Howard Brazee on 28 Jul 2008 10:20
On Fri, 25 Jul 2008 21:01:48 -0500, Robert <no(a)e.mail> wrote: >>So I guess I'm missing your point here. Do you mean we should spend >>as much testing a new program design as GM spends testing a new car >>design? > >If GM changed only the ash tray, would it re-test every other system to insure the ash >tray didn't inadvertantly affect something else? Good point. But there have always been levels that don't get full regression testing. Checking to see that the ash tray opens and closes correctly might be similar to making sure that the new forms are aligned correctly in the old printer. We also didn't need regression testing when putting in a new printer band or paper tape indicating TOF. Occasionally some unexpected bug goes through this way - the cigarette lighter in that new ashtray has a short which effects the electrical system of the car - but over-testing of things that don't appear to be part of the critical functions can be too expensive. So back to: "Imagine test driving a new car the way we test new software". They still seem to be comparable. |