Revised: November 20, 1992 There are several potential problems that may be encountered during and after the migration to the IBM RISC System 6000s. The purpose of this file is to define these known problem areas and suggest work arounds. Please read each of these items carefully as they may contain information that effects your work. NFS FILE SYSTEM PROBLEMS -- EXPANDED I. .forward's are occasionally unreliable. This seems to attributed to the NFS problems that we are continuing to see. The problem manifests itself between AIX/370 systems when the user's files (the target user) are mounted from a 6000's and the sending user is on another AIX/370 site. The result of this is the mail is placed in the target account instead of being forwarded. No lost mail, but a nuisance to check multiple accounts. More work is being done with NFS to verify this and other problems which may be related. II. Files being corrupted or zeroed. There have been several observed occurrences of files (.newsrc in particular) being corrupted or zeroed. We feel this problem may have been solved with last Sunday's (11/15/92) network change. If anyone is still seeing this occur, please contact bugs via e-mail. The problem seems to manifest itself when the file is being accessed from an AIX/370 site other than the site that files are mounted on. (eg., reading NetNews on zeus while your files are mounted on nike or any other PS/2 site.) Again more work is being done with NFS to verify this and other problems which may be related. USER FILE SIZE MEASUREMENT ERRORS ON OLD AIX/370 SYSTEMS WITH USER FILES NFS MOUNTED FROM RISC/6000 SYSTEMS The old AIX/370 Systems (zeus and the PS/2s) do not report disk utilization correctly on filesystems mounted via NFS from the RISC/6000 Systems. The RISC/6000s use a cluster size of 4098, they also have a block size of 512 (eight blocks per cluster). The old AIX/370 systems have a cluster size of 4098 and a block size of 4098. The old systems seem to be reporting disk space used for file or directory at eight times the actual amount when viewed with "du", "quota", or "ls -s". We feel that this is due to the old systems misunderstanding the RISC/6000 blocking factor. This should NOT effect user quotas. User quotas are managed by the NFS server, which in this case is the RISC/6000 sites. If a user does go over quota, the RISC/6000 system sends a message to the client system (one of the PS/2s) which informs it that the user is over quota. So far this system seems to be functional as far as the actual quotas are concerned. If you do think that you may be considered over quota, check your quota on the RISC/6000 site where the file system is located (see the "Migration_Schedule" article in system news)with the quota command and also check actual usage on the same site with "du". They should agree, if they do not, please call x-2516 and let us know. For those that are out of sync on the RISC/6000 systems, a system command can be executed by a system administrator which will bring the user back into sync. ALSYS ADA BIND ON RISC/6000 SYSTEMS GENERATES ADDITIONAL FILES When a user executes "ada bind program_name" on the RISC/6000s, it now generates several files in addition to the executable. These files end with the extension ".o" for an object file containing relocatible versions of your modules and those modules you are calling, ".lnk" for a linker command file, and ".cui" for AdaProbe and error traceback information. These files take up a fair amount of space and are always placed in the same location as the executable. There is no way in the AdaWorld environment to re-direct them without also redirecting the executable as well. As a result of this, the previous recommendation of maintaining 600 to 800 Kb of your account free to allow for these files. Once the bind process has completed successfully, the ".o", ".lnk", and ".cui" files may be deleted unless AdaProbe is going to be used as a debugging tool. MAIL ON THE RISC/6000 SYSTEMS Mail on the RISC/6000 systems works differently than on the AIX/370 system. On the old AIX/370 system, incoming mail would normally be placed in the user's home directory in a file called ".newmail". On the RISC/6000 systems, incoming mail is placed in a separate filesystem under "/usr/spool/mail/user_id", where user_id is the login ID of the user receiving mail. Because of the potential problems caused by having two mail boxes and the mail on each system only looking at one of them, mail is being configured as follows for the duration of the migration process. The mail system on the RISC/6000 systems is currently setup to have all incoming mail for a RISC/6000 site bounced back to the old AIX/370 system (via nike.calpoly.edu). Outgoing local mail (mail for another user within the AIX system)will be sent to the old AIX/370 system (via nike.calpoly.edu). Mail to system aliases will not work on the RISC/6000 systems at this time and should be performed on your old AIX/370 site (the site where you have always logged in). When the PS/2 systems are ready to be phased out (sometime during Winter or Spring Quarters 1993), system mail facilities will be reconfigured to direct mail to the RISC/6000 systems. All mail incoming for the old PS/2 sites will be redirected to a RISC/6000 site which will act as the cluster mailer. Mail local to the AIX system will then be sent to the RISC/6000 site which will act as the cluster mailer. During this process all site names will be maintained (PS/2, 370, and RISC/6000) so that no mail will be bounced back to the originator with a host not found. HIDDEN DIRECTORIES BEFORE AND AFTER THE MIGRATION Hidden directories are peculiar to AIX/370, no other UNIX system supports them. If you don't know what a hidden directory is, chances are you don't have any within your account. In the process of migrating from AIX/370 to the RISC/6000 systems, all hidden directories will be flattened as follows: I. All hidden directories will be changed to a file. II. The i370 file within the hidden directory will be moved to that file which used to be the hidden directory. III. All other files in the hidden directory will be lost. This is a good time to prepare for the removal of the AIX/370 system which will be replaced by AIX/ESA, IBM's OSF/I offering. User's should disassemble the hidden directories within their account into regular files before the migration if they wish to maintain anything other than i370 file types. NFS FILE MOUNTING AND WHAT IT MEANS FOR THE USER All filesystems which are being relocated on the IBM RISC System 6000 sites will be NFS mounted back to their original site within the cluster vis NFS (Network File System). Because of the way TCF works under AIX/370, as long as the file system is mounted on one site in the cluster it is available to all sites. However, beware that logging into a site other than the one where your files are mounted in the PS/2s can result in your files having to make several network hops to reach the CPU you are working on. There is a remote, but possible chance that with NFS mounting, files may become corrupted when they are written from the remote site back to the NFS server. Please be sure to check your files occasionally for this possibility. A cursory look at the texts files should be sufficient to spot any corruption in the unlikely event that it occurs. Only files which have been written via NFS need to be checked. We will continue to make backups of the files and should be able to recover any files for users which have become corrupted within a working day or two of them notifying us via the file recovery request. This process should only be used for corrupted files which cannot be reentered within a relatively short period of time. Users are encouraged to back their files up to other media via ftp, Kermit, or x/y/zmodem. There are numerous systems within the Academic Computing Services microcomputer labs which may be used for this purpose. We are currently working on having the PCs within these labs being able to perform ftp services for the users which the Macintoshes already provide.