SUBROUTINE store $$IMPLICIT $$INCLUDE 'C$INC:BCS.INC' $$INCLUDE 'YBOS$LIBRARY:ERRCOD.INC' $$INCLUDE 'YBOS$LIBRARY:BNKTYP.INC' INTEGER ind, index ! bank and data index of TAUS INTEGER blocat ! YBOS named bank finder INTEGER bmake ! create a named bank INTEGER status ! error return status INTEGER ind, index ! bank and data indices INTEGER ngroup ! number of groups in bank INTEGER bnktyp(3) ! store info about types of peices in bank C................................. C== Load the bank type header with the appropriate bits ngroup = 0 CALL btpack(bnktmx, ngroup, 2, bnktyp(1)) ! mixed-type bank CALL btpack(bnkti4, ngroup, 10, bnktyp(2)) ! 10 integers CALL btpack(bnktr4, ngroup, 20, bnktyp(3)) ! 20 reals status = bmake(iw, 'TAUS', 1, 30, bnktyp, ind, index) IF(status .NE. yesucc) RETURN C== Set usual constants rw(index+15) = 3.1415926 ! boston cream pie <------ iw(index+6) = 30.2 ! version number CALL loadup RETURN END
The routine defines a named bank which consists of a header which we shall ignore, and then a block of 10 integers and 20 reals. So long as all work is done on a single computer, you can get away with a lot, but if the data has to be ported from one architecture to another, you may wind up with garbage if the translation routine tries to translate the integer representation of 3.1415926 on a VAX to an integer on SGI.
Load the named banks properly, or your banks will not port properly. (You may think you're the only one who'll ever use this, and only on one machine. This is certain only if you delete all your code when you are done tomorrow.)
Try to use parameterized names instead of hard-coded numbers, as was done above. The hard-coded numbers are much harder to read and debug later.
It is better to avoid the use of BTPACK, and use BTYMAK. You're likely to make fewer errors.