home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / database / ingres / 1926 < prev    next >
Encoding:
Text File  |  1992-11-17  |  3.0 KB  |  74 lines
  1. Newsgroups: comp.databases.ingres
  2. Path: sparky!uunet!sun-barr!cs.utexas.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!uvaarpa!cv3.cv.nrao.edu!mail-to-news-gateway
  3. From: CS_PAUL@GSBVAX.uchicago.edu (Paul Ford 312/702-0335)
  4. Subject: re: Frequently Used Procedures
  5. Message-ID: <921117165351.23600e27@GSBVAX.uchicago.edu>
  6. Sender: daemon@nrao.edu
  7. Organization: National Radio Astronomy Observatory
  8. Date: Tue, 17 Nov 1992 22:53:51 GMT
  9. Lines: 63
  10.  
  11. Michael McGarrigle writes:
  12.  
  13. >Does anybody out there know of a way that commonly used routines can be stored
  14. >in one place but accessed by several databases.
  15.  
  16. Several options occur to me:
  17.  
  18.   o Write the procedure in an embedded language (e.g., ESQLC/C) and define
  19.     it as a LIBRARY procedure to ABF.  The procedure has to be compiled
  20.     externally to ABF.   The disadvantage is that you must add a link
  21.     options file to your application definition (for VMS, for Unix I'm not
  22.     sure what the moral equivalent is) to tell ABF where to find the
  23.     compiled object file (or object library file) when it links.
  24.  
  25.   o Under VMS: Leave the procedure in 4GL, but put it in a common
  26.     directory.  Use a VMS path logical for your ABF source directory that
  27.     includes the application specific directory and the common directory.
  28.     Each ABF application that uses the procedure will recompile it, but
  29.     there will be only one source.
  30.  
  31.     Example:
  32.  
  33.         Specific source directory for application MYAPP
  34.                 DEV1:[SOURCE.MYAPP]
  35.         Common source directory
  36.                 DEV1:[SOURCE.COMMON]
  37.         Path logical
  38.                 $ define MYAPP_PATH  DEV1:[SOURCE.MYAPP], DEV1:[SOURCE.COMMON]
  39.         ABF directory specification for application MYAPP
  40.                 MYAPP_PATH
  41.  
  42.  
  43.   o With UNIX I have no real experience, but I'd guess that you could do the
  44.     same sort of common directory trick using soft links instead of VMS
  45.     logical names.  Create a common directory to hold the shared procedure,
  46.     and then in each application directory create a soft link pointing to the
  47.     shared procedure source.  Maybe something like this:
  48.  
  49.         Specific source directory for application MYAPP
  50.                 /dev1/source/myapp
  51.         Common source directory
  52.                 /dev1/source/common
  53.         Soft link from application directory to common directory
  54.                 /dev1/source/myapp/sharedproc.osq ->
  55.                     /dev1/source/common/sharedproc.osq
  56.  
  57.     Some real UNIX experts will have to provide the final word on this
  58.     approach.
  59.  
  60. I'm a 3GL bigot, so the first option is my preference.   In fact it's these
  61. kind of obstacles to code sharing in ABF that make me love it so much.
  62.  
  63. [I think I accidentally sent off an unedited copy of the original posting.
  64. My apologies.]
  65.  
  66. Paul Ford
  67. --------------------------------------------------------------------------
  68. GSB Computing Services                  312.702.0335
  69. University of Chicago                   cs_paul@gsbvax.uchicago.edu
  70. 1101 E. 58th Street
  71. Chicago IL 60637
  72. --------------------------------------------------------------------------
  73.  
  74.