The catalog's retroconvertion has been easy and speedy enough for the serial publications already informatized (with Isis system) before the introduction of Aleph; more hard for the monographies availble only on a card catalog. The work has been realized through the following steps:
The database is now of about 265.000 records and available also for the remote access throw the following methods:
As we think that the online availability of the catalog must mean also the documents availability, we promoted and already realized with several Italian Aleph users (the university libraries working with Aleph) a first approach to a document delivery service (loan and copies) based on common rules and are open to an extention of the agreement to other italian and foreign users.
A member of the staff of our automation office (Mr. Marco Robertini) in collaboration with a little group of experts are working on two alternative methods for the online access to the database: one is based on Wais, the other on Isis. Both the methods require the export of the data from Aleph (using Iutil 1.1 and 3.3) after a preselection of the fields of interest.
A little description follow (but for more information refer to Marco Robertini, mail adress : Robertini@sns.it)
Besides more access possibilities to the database the two methods briefly described can give further gains:
Starting from our experience, and seeing that Digital is replacing Open Vms VAX with Open Vms AXP (a recent statistic on DEC Inform Magazine has confirmed that about 70% of VAX Vms platforms are migrated to a DEC Alpha system with Open Vms AXP operating system), I considered to make an attempt for porting Aleph on this new operating system.
First of all, I apologize if my language will be very technical, but it's the best way to tell what I made.
In Scuola Normale Superiore, Aleph is running on a Digital VAX 6000-520 with Open Vms VAX operating system for about six years. In these years, I have got a good experience about the Aleph impact with this DEC operating system, improving Aleph performances too.
Now we have the need to change the VAX system, on which Aleph is running, because its mantenaince cost is very high for this kind of hardware.
Our VAX was shared by the Library and the scientific world (professors and students). According to a planned reorganization of our DEC area, in February 1995, we purchased a DEC Alpha Server 2100 (Alpha generation), with DEC Open Vms AXP operating system, for scientific users. This system has very good performances and will completely raise the hardware maintenance costs for the following three years. This migration is completely transparent for users because the operating system command language is completely the same. So they don't have to restart a training for working on the new system.
This new operating system is very close to Open Vms: the difference is that Open Vms AXP is a 64 bits operating system, while the second one is a 32 bits operating system.
In Madrid, Aleph Yissum told to Aleph users having a DEC VAX, that, in the following 3 years, the best choice is to migrate to an Unix hardware.
In Italy and, I think, in other countries, there are many Aleph users having a VAX, with a consolidated situation of their Aleph program, reached after many years of works and efforts. In my opinion, many VAX system managers have acquired an important experience with Aleph on Open Vms VAX.
Moreover many VAX Vms users, using Aleph, learnt to use other Vms facilities too (like Mail, News, Edit and other tools), that are necessary for their work. This training required much of their time.
Why would system managers and users have to restart learning another operating system, spending other resources in terms of costs, without considering the Aleph migration cost to Unix, in terms of hardware and software?
Considering that DEC Open Vms AXP is transparent to a VAX Vms user, I wondered why don't try to make Aleph runnable on DEC Open Vms AXP operating system?
On this hardware there is a good tool, "DEC Migrate". This
software translates a DEC Open Vms VAX executable image into a
DEC Open Vms AXP executable one. It is commonly runnable with
the VEST command. The command syntax is very simple:
$ VEST/OPTIMIZE/INTERPRET=ALL "vax exec"
where "vax exec" is the VAX Vms exec filename (i.e.:
ALEPH_ALL.EXE)
I translated many executable codes for our scientific users, with this program. In this way, they can continue to work with their programs on the new system, increasing performances.
The same way was followed for Aleph executable codes, in about 10 days. All the executable codes, except three of them (Aleph_Tershr, Aleph_Bufshr and Aleph_Comshr), have been translated by VEST, without problems. The error code for the three previous executable codes tells me that the Open Vms VAX image is not linked with BPAGE=16 option.
The Link Bpage option tells to the system which page size has to be used for creating the VAX image (the default is BPAGE=9 that corresponding to a 512 byte page size). Giving BPAGE=16 option, the page size becomes 64 Kbytes, that is the correct value for DEC Open Vms AXP operating system.
So my attempt stopped here because I don't have the opportunity to relink these three VAX images.
If, with DEC Migrate tool, I almost reached the goal to make Aleph runnable on this good operating system,