Going to show my age here ...

Actually IMAGE is a network database and not a hierarchical one. It is
patterned
after a database called TOTAL that back in the days preceding Oracle,
Sybase,etc.
was installed almost everywhere. While you didnt need a DBA it was good to
have
people that were knowledgable in normalization and many of the same
principles
in use today to create your databases. I cut my 'DBA' teeth on TOTAL and did
some
work with IMAGE many moons ago. A great tool in its time but would be seen
as 
a dinosaur today.

-----Original Message-----
Sent: Thursday, April 11, 2002 7:58 AM
To: Multiple recipients of list ORACLE-L


Jay,

    We still have one of those dinosaurs running here called HP's TurboImage
database.  It also "does not need a DBA", actually it does not understand
what a
DBA is.  The "database" is hierachtical with the constraints set during
creation.  I constantly have fun with the older ManMan developers as we move
them into PeopleSoft.  They have no idea of what's going on under the
covers. 
SQL is a foreign language to them, their all use to TurboImage intrinsics
and a
SQL*Plus look alike tool called Quiz.  It's kind of fun, you have to "use" a
dataset (they call them databases), report out columns, and then set
conditions.
 Kind of like writing SQL with the from clause first.  This type of
structure
has to be carried into the application programs as well, namely you've got
to
call the dbopen intrinsic before you can use a dataset.  BTW, that's in C
syntax
'dbopen("MANDB.MDATABAS.MMV090")' (the HP3000 MPEi/x directory structure is
kind
of strange).  There is no such thing as rollback or read consistent view and
recovery consists of going back to the last backup, all of which are cold,
and
having everyone re-enter their transactions.  OH, yes, there is no such
thing as
a user.  If you have the ability to loggon to the HP3000, you can use the
database and everything is wide open.  No ideas of security.  Problem with
TurboImage is that to "modify a database" you have to rebuild it using an HP
utility and then you have to rebuild all of your application programs, or
else
they crash.  Developers do that task as needed and when they mess up, well
all
hell can and does break loose.  Also you need to run these third party
utilities
each night so that there is room for the dataset to grow and you have to fix
broken chains all the time.  There is no concept of an instance either.
Your
application program directly accesses the data files/datasets, so 'impeded'
sessions are a common occurance and if an application messes up it can
require a
system reboot to clear the problems.  Sure you don't need a DBA, but you
sure as
heck need an operator.  Problem is that most operators don't get paid as
well as
a DBA.  If your new CIO is in that mindset I'd recommend polishing your
resume,
cause your gonna need it.

Dick Goulet

____________________Reply Separator____________________
Author: "Jay Hostetter" <[EMAIL PROTECTED]>
Date:       4/11/2002 5:54 AM

We are going through a merger, and management is looking to eliminate
positions.
 Here is a brief summary of my discussion with the new director of IT:

Director: "Back when I we were using an AS400, we didn't need a DBA."
Me: "Then you probably were just using files."
Director: "No, it was a database."
Me: "Could you issue SQL commands?"
Director: "Yes.  But we didn't need a DBA.  I guess it was just one of those
mysteries of life."


My thoughts are that he is using the term "database" in the generic sense of
the
word (our "files" are our database), or he was using some proprietary
database
that doesn't even begin to compare to Oracle.

For those of you who know AS400s, I would appreciate some insight that would
demonstrate why he needs to keep me as a DBA.

Thanks,
Jay


-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Jay Hostetter
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: 
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Tony Johnson
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to