gnb@bby.oz (Gregory N. Bond) (12/04/89)
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.
Deleting the *fo.c files and ~ingres/dbname/appname/* files and
remaking doesn't seem to work - the resulting binaries seem to get the
wrong architecture objects from somewhere and coredump.
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.
_Surely_ there must be a better way. What do other heterogenous sites
do about this?
--
Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: gnb@melba.bby.oz.au non-MX: gnb%melba.bby.oz@uunet.uu.net
Uucp: {uunet,pyramid,ubc-cs,ukc,mcvax,prlb2,nttlab...}!munnari!melba.bby.oz!gnbdmc@sei.cmu.edu (Dawn Cappelli) (12/05/89)
In article <GNB.89Dec4115342@baby.bby.oz> 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. We have the same situation running Sun3's and Ultrix. We've solved the problem, however, in the following manner, which works just fine: First of all, always use the same source code directory and the same database. We never use the default ING_ABFDIR (~ingres/abf), which is where INGRES stores object code. We create a directory underneath the home directory of the DBA of the database called ingres/abf-os. For example, we have two ABF object code directories: ~dba/ingres/abf-sun and ~dba/ingres/abf-ultrix. The protections on those directories are: ~dba/ingres : 777 ~dba/ingres/abf* : 775 In the .cshrc file we determine the type of machine being run on currently (we have a utility which returns 'sun3' or 'vax'). We setenv ING_ABFDIR to the apropriate abf directory described above. Now, as far as the details of running under both operating systems, we try to do most development under one to minimize the confusion, then build the other when the system is ready for testing. However, we still have to go through several iterations as testing progresses. You have to get into Vifred for each form, and save the form. When the form is saved from within ABF it is compiled, which is why it must be saved under each operating system. When you select GO to run the application (or Image) it automatically recompiles anything which has been changed. Since you are using only one source code directory, it detects *all* changes made. And that's about it! It all works very well here. We end up building two images: one per operating system. When a person runs the application, we: check their terminal type & set TERM_INGRES for them, map their keys appropriately for that terminal type (since we don't use default key mappings), set their path for them, check the OS and run the appropriate image. If you have problems, send me email. -- Dawn Cappelli dmc@sei.cmu.edu sei!dmc (412) 268-6170 This is my opinion, and doesn't necessarily reflect the opinion of the SEI.
wong@rtech.rtech.com (J. Wong) (12/06/89)
In article <GNB.89Dec4115342@baby.bby.oz> 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 <db> <appl>". 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 <sys1>::<db> <appl>". (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!
jkrueger@dgis.dtic.dla.mil (Jon) (12/07/89)
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. Yes, there is a better way. Note that this is unsupported. ABF has its own "make" that uses its own "makefiles"; their location and structure is documented in the ABF Advanced Course and I think also in the DBA Guide. You can modify them as you would a makefile, in order to generate multiple images here. Your mods are at your own risk, naturally. The risk is that you break ABF for ordinary use. Thus care is suggested; I'd put the files under source control, for instance. -- Jon -- Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger Isn't it interesting that the first thing you do with your color bitmapped window system on a network is emulate an ASR33?