As of February 26, 2001, the boot host for VxWorks nodes was changed from b0dau30 to b0dap24. In November 2004, b0dap24 was decommissioned and we now use b0dap83 and b0dap84 as boot hosts. Also as of this time, disk access to b0dau30 using the "network" file driver, which uses rsh, no longer works. This means that if you open files with constructs like b0dau30:myfile, you will have to change the code. Network file access will only work to the boot host. nfs file access, to files in the /cdf/onln/code/cdfprod filesystem, will continue to work as before.

Note that it is strongly prefered that all configuration files necessary to run the experiment that are read by VxWorks nodes be located on the /cdf/onln/code/cdfprod disk. They should NOT be located on either the people disks or the /data1 disk.

It is known that there is a significant body of code that explicitly references node b0dau30 for rsh file I/O. This code must be changed before February 26. There are several options:

• One can simply change the hard-coded b0dau30 name to the new host, b0dap83 or b0dap84. This is strongly discouraged, as it is likely the boot host will change again some day. And by that time people familiar with the code that does this will be long gone.
• The code can be changed to work regardless of the boot host. There is a global variable in the VxWorks system containing the boot host name. This can be used to construct file names as follows.

  From a "C" program:

          extern char[20] sysBootHost;
  	char filename[120];
  	FILE outfile;
  
          ...
  
  	sprintf(filename, "%s:/cdf/people1/cdf_cal/data/ped_0.vec", sysBootHost);
          outfile = fopen(filename, "rw");
  
  	...
  

  From the VxWorks shell:

  
  	myfile = malloc(120)
  	sprintf(&myfile, "%s:/cdf/people1/cdf_cal/data/ped_0.vec", &sysBootHost)
  
  	....
  
  	free(myfile)
  

  Other methods are of course possible.

• It is also known that there are many cases where files are accessed by constructs like:

  ~myuser/myfile

  This WILL NOT WORK with b0dap83 or b0dap84 as the host. The processor will not boot. THIS IS INTENTIONAL. It is true that changing the above to the appropriate variation of

  /cdf/people1/myuser/myfile

  will work. This is fine for remote processors on test stands. However, absolutely no files should be loaded from home directories into the processors used for data taking. Only code in official product directories should be used. If you need a test version, you can create it in the official product area. Too many times people forget they have code in their home directories that is used in the processors and delete it. Then the processors don't boot and it can be difficult to figure out why. Furthermore, this may have deleted the best version of the code! Now is a good opportunity to fix these cases.