Good Lord, let us not get started!! I came from the documentation = capital of this here United States of America, namely the military. = Pile it up high, got to have something to keep the carpet down!! Dick Goulet Senior Oracle DBA Oracle Certified 8i DBA -----Original Message----- From: Ellis R. Miller [mailto:sartre1@xxxxxxxxxxx] Sent: Thursday, August 05, 2004 4:55 AM To: oracle-l@xxxxxxxxxxxxx Subject: RE: standards Very good point. However, and I am not being facetious, I am fairly = certain documenting alleged IT standards is not the means but the end. According to my illustrious mentor, Mr. Bill Mitchell of America West, = one of the forefathers of IT who first hacked www.microsoft.com by = leveraging the now well-documented security flaw in Internet Explorer "View/Source" (subversively and magically invoking Notepad) we were on the James = Martin (pre-Death) methodology, which at the time was slightly less fashionable than proudly exclaiming to be on the "Jenny Craig" plan. When our Oracle = rep later indicated he was not familiar with the standard Bill asked if any = of the old schoolers still awake/alive at that late afternoon (past 10am) JDeveloper presentation could offer an explanation. Many an old schooler stared at their orthopedic shoes that day wondering if the prescription = had expired and hoping the awkward silence would soon pass...or their = Medtronic defibrillator would suddenly kick-in as the seven shocks it administers before assuming one has gone to meet James would have been less painful = than the shame (a first and last for everything). Weeks later, like a Special Olympian on performance-hampering drugs Bill came shambling after me all sideways and twisted with documented proof = of James Martin and the standard for America West in hand, which, like a = driver license, was all that was required to validate the enterprise standards = of the typical IT department under the wise ruling of the typical IT = Manager. Your point is extremely valid yet, statistically, it is safe to assume = the point is to bury the IT standards document in the collective IT time = capsule to be dug up by angry auditors in the year 2075 when humans are, once = again, allowed to return to the APS IT Superfund site. In short, never underestimate the power and practicality of seemingly pointless IT documentation. Consider the excerpt (below) from the = following link [and if any of you live nearby wake up the wife and kids and tell = them the good news about the family moving to Las Vegas on the way there]: http://www.phoenixnewtimes.com/issues/1994-06-01/feature3.html INPO found that recurring problems--such as dirty cooling water or = broken control-panel lights--were not going away, despite the hundreds of = proposals and recommendations that APS management would produce to explain how the plant was going to solve its problems. "That's what they do," says Linda Mitchell, a former plant engineer and whistle-blower who won a judgment against the utility after she was = harassed for reporting safety problems to the NRC. "They can write 5,000 pieces = of paper about anything, but they never fix a fricking thing." INPO was not alone in its harsh assessment of the plant. Ellis PS Would you like to make more money? Sure, we all would. Then why not = train to be a Nuclear Engineer, an IT Manager, or even a CIO? Working with computers and stuff ain't much different than working with radiation. Besides, plant practically runs itself. You gots your standards here and over here you got your documentation. Now, the documentation is mostly = for the Federal boys but every now and then your gonna need to know where = it's at and fetch it right quick. Otherwise, that Federal tit is gonna run = dry and that ain't no good for doughnuts nor nothin' else. -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Markoen Meijerink Sent: Thursday, August 05, 2004 12:39 AM To: oracle-l@xxxxxxxxxxxxx Subject: Re: standards L.S., This sounds like the application of the ideas of Karl Popper: It is = often easier for Homo Sapiens to know and to make a decision based on what you don't want. Karl has written = about more things than the importance of falsification in science. But being witty is not the point here: Whether it is about database and infrastructure-standards (OFA) or about programming-standards (e.g. CDM): a good standard is nothing more than a useless, 'dead' book in the = closet if you do not perform any active checking. If you do nothing about enforcing the standards, = you can almost save you the effort. So if you want your oracle files being placed in /unn/oradata/bla...bla...something then schedule a check that checks if it is so. And if you still want to have all your foreign keys to have an index, = then schedule a check to monitor whether this is so. I can give many examples of useful, sanitary checks that you should = perform at the schema, instance or database level. And also should keep on doing. Maybe you created the initial 10 users correctly with the right settings, but the 11-th user is created with e.g. "that nice feature in = the application to 'create user john identified by john' " at some later time without your knowledge. If this user ever gets resource privs you 'll know where the objects = will go. The work is not the writing of the standard, the work is in the = programming of the active checking! Find a complete standard combined with a complete tool to implement this notion (we use one of course). You will be far better off. Markoen Meijerink ----- Original Message ----- From: "Mogens N=F8rgaard" <mln@xxxxxxxxxxxx> To: <oracle-l@xxxxxxxxxxxxx> Sent: Thursday, August 05, 2004 1:51 AM Subject: Re: standards > Splendid. > > And it brings me back to the very valid point Cary made to me some = years > ago when we were in Honolulu together for the OAUG - remember the one > where Oracle pulled all financial support two weeks before the start = of > the conference? > > That was the beginning of the Mark Jarvis Master Plan (MJMP) to kill = off > user groups and get some real messages out to customers instead :). > > Anyway, Cary's point was (I think) to focus on worst practices instead > of best practices. When you constantly look for best practices you = will > always be falling behind reality, and there will be no impetus for > moving the bar up. If you look for worst practices (things not to do), > then you'll learn and grow and become smarter and you can steadily add > to the list... or just move the bar up, up and away. > > Mogens > > > > david wendelken wrote: > > > How about: > > > > PL/SQL Programmers who use exception blocks like this will be = flogged, then fired from their job. > > > > EXCEPTION > > WHEN OTHERS THEN > > NULL; > > END; > > > > :) > > > > -----Original Message----- > > From: David <thump@xxxxxxxxxxxxxxxx> > > Sent: Aug 4, 2004 3:45 PM > > To: oracle-l@xxxxxxxxxxxxx > > Subject: standards > > > > I ahve been asked to write the standards for the company in terms of > > Oracle databases. > > I have never done anythign like that before... > > Anyone have any pointers or skeletons or examples I could review? > > Cheers > > ---------------------------------------------------------------- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > ---------------------------------------------------------------- > To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx > put 'unsubscribe' in the subject line. > -- > Archives are at //www.freelists.org/archives/oracle-l/ > FAQ is at //www.freelists.org/help/fom-serve/cache/1.html > ----------------------------------------------------------------- > ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------