[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::rdb_wish

Title:Oracle Rdb Wishes and Suggestions
Notice:Please READ note 1.0 before using WRITE or REPLY
Moderator:NOVA::SMITHI
Created:Fri Apr 07 1989
Last Modified:Mon Jun 02 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:809
Total number of notes:4111

798.0. "opcom message on storage area extents" by 12293::ALLEMEERSCH (In Flanders fields ...) Tue Apr 01 1997 09:59

    The following topics came up with mission critical customers
    ( Volvo, Delight, Alcatel ...) during the Rdb7 update seminar I
    teached last week overhere in Brussels.
    
    Please provide a possibility to have a opcom message
    ( thru rmu/sh stat is ok) on extent of a storage area,
    identifying the area, responsable user, timestamp etc ... .
    Apparently most customers run home grown procedures to compare
    file sizes and identify storage area extents.
    The idea is that rmu/sh stat is anyway always running somewhere.
    
    _Luc
T.RTitleUserPersonal
Name		DateLines
798.1What sort of thing?DUCATI::LASTOVICAIs it possible to be totally partial?Tue Apr 01 1997 17:568
how would you envision this being implimented?  How about something
along the lines of a logical name like:

	rdm$bind_storage_area_extend_notify_classes "operator class(es)"

If this logical is defined, then any time a storage area would be
extended, a message would be sent to the operator indicating the
storage area name, old size, new size, user, pid, etc. being extended.
798.2NOVA::SMITHIDon't understate or underestimate Rdb!Tue Apr 01 1997 23:293
Surely we would add syntax similar to that added for JOURNALS.

Ian
798.3yah - that would be prettierHOTRDB::LASTOVICAIs it possible to be totally partial?Wed Apr 02 1997 01:083
    sigh - but that would be *soooo* much more work.  :-)  Yah - I suppose
    that there could be something like this for each area even.  I was just
    thinking of 'biggest bang for the buck' from the engineering effort...
798.4elegant is not a requirement12293::ALLEMEERSCHIn Flanders fields ...Wed Apr 02 1997 03:334
    The solution should not even be elegant. 'Quick and dirty' will do,
    as soon as the functionality is there. Logical nr. 112 is ok.
    
    _Luc
798.5Draft release note for Rdb V7.0AHOTRDB::LASTOVICAUse a fork Luke!Sat May 17 1997 17:0539
<COMMENT>
    AUTHOR: Norm Lastovica
    RELATED NUMBERS: RDB_WISH 798
    FIXED by CTS #: KODA CTS 14004 (PIOEXTEND.B32, KODLOGMAC.REQ)
    PLATFORMS AFFECTED: OpenVMS
    INTERFACE(s) AFFECTED: all
<ENDCOMMENT>

<HEAD2>(Operator Notification of Storage Area Extension\opcomareaextend)

<IVMS2>

<P>
The system operator classes CLUSTER and CENTRAL may be
optionally notified for storage area extend events.

<P>
By default, notification of area extends is disabled. To
enable this notification, define the logical name
RDM$BIND_NOTIFY_STORAGE_AREA_EXTEND to 1. This will result
in storage area extend events being notified.   There is,
however, no way to alter the  operator classes that are
notified.  

<p>
The logical name RDM$BIND_NOTIFY_STORAGE_AREA_EXTEND should
be defined system-wide so that any process extending an area
will cause the notification to occur.

<p>
Following is an example operator message:

<CODE_EXAMPLE>(KEEP\WIDE)
%%%%%%%%%%%  OPCOM  16-JAN-1997 05:44:11.71  %%%%%%%%%%%
Message from user SYSTEM on SMILES
Oracle Rdb Database DUA0:[DB]DB.RDB;1 Event Notification
Storage area DUA0:[DB]DB1.RDA;1 extending by 4321 disk blocks
<ENDCODE_EXAMPLE>