Actually MODE 2 opens can be useful indeed - and I applaud the incredible
forsight of the IMAGE lab for these esoteric but very handy open modes -
also including 4, and 6.
But be very careful in the design of your DBSCHEMA's security lists if you
decide to use DBOPEN mode 2.
As already indicated, DBOPEN MODE 2 precludes the use of DBPUT and
DBDELETE. As a result, your program is not required to deal with the logic
complexity and overhead associated with the necessary dataset level locks
for subsequent dbputs and/or dbdeletes (and, as mentioned previously, any
CIUPDATES).
By now you are probably asking - what good is a program that cannot add or
delete data entries?
Well, consider an application - such as order entry, which requires
real-time updating of inventory at the time an order is placed. Assume
that the number of different parts a customer could order was large - but
that new parts would be known about at least 24 hours in advance (quite a
reasonable assumption for many such inventories).
Why not design the online order entry program to utilize mode 2 dbopen and
thus improve its performance while reducing its complexity. At the same
time, the program that adds new part numbers to the product dataset can be
designed to run at night, in batch, utilizing mode 4 - which also
simplifies programming, because mode 4 does not permit other updates to
occur concurrently. Meanwhile, report programs can run concurrently with
the batch update program utilizing mode 6 dbopen. All very elegent, very
simple, and very efficient - in both programming and execution.
Throw into the mix intelligent use of message files, and you have a very
robust and efficient application design that utilizes the best that IMAGE
has to offer.
I wrote a paper on this very subject quite a few years ago, entitled "A
Message about TurboIMAGE" which was about the use of message files in
conjuction with the use of "non-standard" open modes. It was published in
one of Interact, Chronicle, or HP Professional - sorry, I can't remember
which. If anybody's interested, I'll try to dig it up if I can.
Regarding DBSCHEMA design and open mode 2, one side-effect if care is not
taken at the design stage is as follows:
You must specify a read-class list and write-class list at the item level.
Most DBSCHEMA designers are not accustomed to doing this. However, if you
are going to use mode 2 - YOU MUST SPECIFY SECURITY AT THE ITEM LEVEL.
Otherwise, unless you are the data base creator - AND specify ";" as the
data base password at open time you will not be able to modify any data
items. The reason is that as soon as open mode 2 is specified, all classes
arfe removed from the write class list at the dataset level. Consequently,
the user must be in the write-class list at the data item level in order to
gain update capability for that item.
I
At 09:35 AM 97/08/05 -0500, you wrote:
>Ok, remind me.
>
>I've got a new analyst migrating from IBM MVS environment. He's reading
>the manual and discovers MODE 2 open and asks what's the difference
>between MODE 2 & Mode 1?
>
>Since we only use modes 1 & 5 on our production machine, and Quest opens
>the shadowed DB in mode 4, we've never had the need to use/explore other
>modes.
>
>Go figure, a new guy, and immediate he asks questions you can't
>remember/never learned.
>
>Gary Groves
>
>Kwestions, Kwalms, Kweries, Komments....Kall!
>
>
>http://www.superstar.com
>http://www.netlinksat.com
>http://www.uvsg.com
>
>
---------------------------------------------------------------------------
Gilles Schipper
GSA Inc.
HP3000 & HP9000 System Administration Specialists
300 John Street, Box 87651 Thornhill, ON Canada L3T 7R4
Voice: 905.889.3000 Fax: 905.889.3001
Internet: [log in to unmask] Compuserve: 71203,474
---------------------------------------------------------------------------
|
