Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!amdahl!rtech!wong From: wong@rtech.rtech.com (J. Wong) Newsgroups: comp.databases Subject: Re: INGRES ABF & multi-architectures. Message-ID: <4234@rtech.rtech.com> Date: 5 Dec 89 19:03:55 GMT References: Organization: Relational Technology Inc. Alameda, CA 94501 Lines: 82 In article gnb@bby.oz (Gregory N. Bond) writes: >We run INGRES 5.1 on Sun3 and Sun4 gear, and use ABF to develop >applications. We just got our first Sun4, and are looking for a way >to manage the dual architecture ABF binaries. It seems there is no >way to use abf on the one databse on the one application to build >binaries for multiple architectures. Given that the Sun3 and Sun4 have different architectures, I assume that you have two completely separate INGRES installations, one for each. Furthermore, I assume you are running INGRES/Net from one system to the other to share databases, and hence, the application definition. Similarly, you are running NFS and sharing the source-code directory. >Deleting the *fo.c files and ~ingres/dbname/appname/* files and The *fo.c files should be machine-independent C and need not be deleted. Since they are placed in the source-code directory by ABF, they should be shared. As noted above, you should have two separate INGRES installations, and hence, two separate ~ingres/dbname/appname directories. These directories will contain the machine-specific object-code files for each architecture. Since they are separate directories, you need not delete any of the files in them. The ~ingres/dbname/appname directories are specified using the environment variable ING_ABFDIR giving $ING_ABFDIR/dbname/appname as the object-code directory. (In this case, ING_ABFDIR would specify the same path as ~ingres.) Needless to say, this variable should be different on the two different systems! >remaking doesn't seem to work - the resulting binaries seem to get the >wrong architecture objects from somewhere and coredump. This sounds like you do not have two separate installations! ABF application binaries are built from object-code for the application and general INGRES libraries: $ING_ABFDIR/dbname/appname contains all the object-code for the application, itself, including any compiled forms (*fo.obj). (You should have two of these directories remember!) Then you may have your own library objects specified in the file specified by the ING_ABFOPT1 environment variable. (You're going to have to make sure you have two of these files, plus two of all your own library objects for the two different architectures!) Finally, INGRES objects and libraries found in ~ingres/lib (of which they're should be two for the different machines.) Now, how do you develop ABF applications on these two systems, sharing the application definition and the source-code directory? You will log onto one system, which should have its own INGRES installation with ING_ABFDIR and ING_ABFOPT1 set to non-shared file system values. The application will be defined in a database in this installation and partially developed here, as well, using the command "abf ". The source-code directory you specify should be on a shared (NFS) file system (which must have the same path on both systems.) You log onto the other system, which again has its own separate INGRES installation and separate ING_ABFDIR and ING_ABFOPT1 specifying different file system values than on the first system. To develop or link the application, you type "abf :: ". (Remember, you're using INGRES/Net.) Nothing else need be done. None of what follows should be necessary: >The best answers that the local RTI support could come up with (after >several weeks and a couple of calls) are: > >1) Touch _every_ frame and procedure in the application (using vifred > and the editor) and remake the image each time you want to change > architectures. Gak! > >2) Use copyapp to copyout the application, delete the application, and > copy it back in for the other architecture each time you want to > change architecture. The copyin will give stacks of error messages > as the frames are multiply defined > >3) Have two different applications using the one source directory, one > for each architecture. Changes will have to be made to both > applications (although forms and text editing can be done once). > >4) Use a separate database for the other architecture. This is even > worse than 3) and the forms will have to be modified twice. -- J. Wong wong@rtech.com Ingres Corporation. **************************************************************** S-s-s-ay!