How to Add a New Device Type 10/3/00 1.) Get the device type to be defined along with a brief description of the device type. If the device is on a node not used before (unknown to dio_ssdn_to_device_type_c routine) get the node number info also (i.e. trunk/node). 2.) Edit file /usr/local/mecca_head/mecca/uls/ul_clib/device_types.h. This file is used by dio_ssdn_to_device_type_c which, in turn, is used by DABBEL. If a new class will be defined, diolib.h must be modified to add the new class. A.) For a new type, choose an appropriate definition based on the functionaliy of the type. This can usually easily be extracted from the type description that was supplied. Looking through the include file you will find the appropriate section, based on device class, where all the types for a give class are defined. Make an entry with the next corresponding ACNET device type number. Remember to modify the "top" of class range definition also (DIO_xxx_DEVICE_TOP). B.) For a totally new class (and type within that class), a totally new range for the device type must be selected. The range of numbers must be unique within the include files for this new class. Put all the device types for this new class together in one block of defines and remember to define the "start" and "top" of the device type range for this new class. Search for "ADD NEXT" for place to add next block of device types. Define types as in A above. C.) When adding a new device class, you should create a new class_updateN.sql file in the directory DWIN_DISK:[DWIN.CENTRAL.SYBASE.CLASS_UPDATE.TABLE_UPDATES] and execute that on the ADBS server only. This will update the table device_class_table which is used by many of the dialog routines. 3.) Using the ACNET device type number, the device description, and an appropriate 12 character short description, enter these new device types into the device_type table on both ADBS and CDBS. If using isql, one can specify a '-i {file}' parameter on the command line in order to facilitate device type entry. All update files are kept in: DWIN_DISK:[DWIN.CENTRAL.SYBASE.CLASS_UPDATE.TABLE_UPDATES] 4.) Now the device type must be recognized by the CLIB routine 'dio_ssdn_to_device_type_c' which is found in the source file /usr/local/mecca_head/mecca/uls/ul_clib/dio_misc.cpp. A.) Find the appropriate local procedure which usually corresponds to the device class. Add the device type supplied earlier by the Front-Ender to the switch statement. Return the appropriate ACNET device type as defined in the device_types.h file. Return the appropriate ACNET device class as defined in diolib.h. B.) For a totally new class you will have to write two new routines. The first routine should be named is_xxx_fe which will contain the list of front ends that belong to the new class. The second routine is named xxx_device_type and maps SSDN information to the specific device type. The switch statement for this new routine will include Front-Ender supplied types. Insert types for the new procedure as in A above. You will need to add calls to these two routines to both dio_ssdn_to_device_type_c and dio_dev_type. Use an existing class as a template. C.) Release your changes to dio_misc.cpp with the 'mecca --commit' command. Once he CLIB build is complete, copy it to all consoles with the command 'update_xcons_all'. Procedures to interogate the database and incrementally update the database exist in DWIN_DISK:[DWIN.CENTRAL.SYBASE.CLASS_UPDATE.RELOAD]. Since DABBEL users can now make device entries without being stopped by DABBEL, the procedure LIST_NOTYET.COM can be used to find out information about these new devices entered into the database. The 'p1' parameter contains the database server (defaults to CDBS). There are two output files produced by this command procedure: NOTYET.LIS and NOTYET.DAT: The LIS file contains the DI, name, property, SSDN, front-end, and description of all device/properties which have not yet been typed. The DAT file contains only the distinct DIs for these devices. Should you need to modify the incremental update application (DEVCLASS.EXE), the build command is DEVCLASS_BUILD.COM (DEVCLASS_BUILD_DEBUG.COM for a debug version). This program does NOT have to be rebuilt to support new device types. This information is picked up from CLIB. DEVCLASS.EXE must be run as a foreign command. The single parameter is the name of the DAT file (normally NOTYET.DAT) which contains a list of device indices: one DI per line for all devices which need to have device class and device type recomputed using a new version of determine_device_type. Both the CDBS and ADBS databases are modified by this application. (Note: You can create a file of device indices from a file of device names using the command file name_to_di.com (@name_to_di {input_file}').) IMPORTANT! Do not run DEVCLASS.EXE with DABBEL enabled. There is a potential for database collision. The easiest way to ensure serial access to the database is to use the 'DABBEL_BATCH' queue. Simply execute the command procedure 'UPDATE.COM' (no parameters) to access the database through the queue. The log file will be written to 'UPDATE.LOG'. These procedures assume that the list of device DIs is contained in 'NOTYET.DAT'.