Abstract: Since we also use some legacy systems among our machines, this page contains useful configuration and usage hints for Mac OS X as well as Mac OS Classic systems. Hints have been selected for things that are less obvious, yet are needed for smooth operation, and for informations that may no longer be so easily available for someone running only most recent machines.

• Learn to know your Mac!
• Helpers
  • Fix unreadable iCalendar files
• Our Servers
• Using AFP (Apple Filing Protocol) Services
• Accessing LiteratureSE
• Systems Configurations:
  • OS X Hints
  • Time Synchronization (winter vs. light-savings time)
  • Date and Time Formats
• FTP Configuration
• Preparing a bootable CD for your Mac
• Trouble Shooting

• Learn to know your Mac!
   
  I strongly recommend to invest some time in understanding well how to use your Mac. You will later greatly profit. The Mac is easy to use, but the danger is you ignore the many, not so obvious features, that may give you lots of power and help you ease your work.
  • You find on the se-server in folder News many nifty e-books that are easy to read and contain most helpful information.
  • You find in our handbook library several well written books that may also help you to learn making good use of your Mac.
  • The internet also offers a lot of well done tutorial and hints. E.g. start here, consult the on-line help offered within the Help menu of applications, manuals, and technical papers, which are not only authorative, but also are often among the most helpful.
  • There are also sites especially made for scientists, e.g. Mac OS X for Science or Macs in Chemistry.

   

• Helpers
   
  
  • Fix unreadable iCalendar files
    If you receive an iCalendar file, typically having extension .ics and iCalendar refuses to recognize it with this error message:
    
    it may well be the ics-file is merely of a too old version. Then I recommend to use this little helper application I wrote (freeware, courtesy ETH Zurich): Fix ICS File (download). Simply drag and drop your ics-file onto this utility. It converts your ics-file to version 2.0 and then makes an attempt to open the converted file. In many cases this is all you need for a successful importing of the event into your iCalendar.

   

• Our Servers
   
  
  • se-server.ethz.ch
    Hardware: Macintosh Xserve G5, CPU PowerPC G5 2 GHz, 1 GB SDRAM, 400 GB Disk space
    OS: X Server 10.4.x (Tiger).
    The following volumes are offered with restricted access (only via Login/password and the so-called Apple Filing Protocol ( afp)):
     
    
    1. SE_Intern - the central internal file server
    2. Modelle-Daten - models and data
    3. PreReleases - prereleases of own software and editor Alpha related stuff
    4. SED - development server
    5. SE_Software - SE-specific releases of software
    6. SE_SW-Installationen - commercial, licensed software (no longer maintained)
    7. To_Archive - to prepare an archive
    8. ftp - temporary file storage for transfer
       (the volume name is now a misnomer, but kept for compatibility reasons; note, we no longer provide ftp services on this server)

  This server offers basically only afp (Apple Filing Protocol) services with restricted access (via Login/password). This server is protected by several firewalls and resides in the zone ETHZ-VPZ_UWIS. It may also offer some additional services such as ssh and ftp etc. However, such services are not for general use and are reserved for administrators and developers only and are only possible from certain machines.

  For access hints click here

  Note that the entire se-server is protected from data loss by a daily netbackup

   

  • FileMaker Server (IP name = savannah.ethz.ch)
    Hardware: hosted actually by our se-server
    OS: see se-server
    Data base software: FileMaker 6.0v4 offering the central data base file LiteratureSE via TCP/IP (access restricted)
    

    For access hints click here

    Note that this service is protected from data loss by a daily netbackup

   

  • Simulation Servers (Suns and Macs)
    Details: Click here
    RASS software: Latest version as available from here
    The OS X simulation server cluster is described here
    

    Note that all simulation servers are NOT protected from data loss by any backup. It is your responsibility to avoid data loss, since you should use those simulation servers only to run some simulation experiments, analyze and archive the results, and, once finished, delete all files you used. The only exception to this is the huron, which receives a daily netbackup.

• Using AFP Services

  AFP stands for Apple Filesharing Protocol. You can also construct URL's of the form afp://se-server.ethz.ch/SE_Intenr... to specify a particular folder or file on an AFP server.

  To access one of the offered afp services use Finder's menu command "Go -> Connect To Server" (Command-K) or the "Chooser" (MacOS Classic) and enter the "Server IP Address" of the server, e.g. se-server.ethz.ch similar to this:

  Mac OS X

  Mac OS Classic

  Then login with a dialog similar to this:

  Mac OS X

  Mac OS Classic

  and choose one or several volume(s) to mount

  Mac OS X

  Mac OS Classic

  and click OK.

  It is not recommended to check any volumes to the right of the list, i.e. please refrain from auto mounting shared volumes. Thanks!

 

• Accessing LiteratureSE

  FileMaker services are only available using the FileMaker application. It is recommended you do this only from within your personal literature data base LiteratureMY. To succeed you need a working TCP/IP based connection to the Internet.

• Systems Configurations

  • OS X
    

    Finely edited help, hints, tutorials etc. can be found at OSX FAQ.

    Here you may find an answer to some of the more pertinent questions you might have with respect to MacOS X.

  • Time
    

    To maintain a consistent, well synchronized time stamp amongoftware_URLs.html">NetworkTime (or the built in facility on OS 8.5 and newer) to set the time. The settings are these:

    

    

    

  • Date & Time Formats
    

    

    Under MacOS 8.1 don't touch the time zone settings. Leave this entirely to the control panel "Network Time".

    Recommended date format:

    

    Recommended time format:

    

    Above settings ensure proper back up, file transferal when updating between development servers and your local machine, working of M2 mode in Alpha or macros in MEdit, working and sorting of our literature data base. Please stick to them!

  [Contents ] [ Top] ] [ Bottom]

• FTP Configuration (also of interest for non-Mac users)

  You will often need ftp to transfer files among hosts. ftp is particularly useful to transfer large files, which otherwise risk to get intercepted if sent by E-mail attachment. For ftp you should configure your ftp client, e.g. Fetch, in such a way, that you encounter a minimum of problems. This is particularly important for Systems Ecology modelers and developers, since the Development server (SED - Systems Ecology Development server) holds thousands of masters for many kind of files we need in our daily work. The integrity of these files can only be warranted if you follow a few precautions as explained below.

  Rules of thumb if in doubt: If possible avoid text mode, it may corrupt data! To a Mac upload all files in binary mode! To a Sun upload all files in raw data mode! To an IBM PC upload all files in raw data mode!

  • Using Fetch 3.0.3 On a Mac Connecting to a Classic Server (MacOS 9.1)

    If you use Fetch on a Mac to download and upload files, e.g. from/to SED, you should configure Fetch as follows:

    • Default text format: Text
    • Default non-text format: MacBinary II
    • Uncheck "Add .bin suffix to MacBinary II files"
    • Uncheck "Add .txt suffix to text files"
    • Check "Encode and decode file and folder names"

      

    This ensures that in automatic mode you will upload any non-text file, e.g. a SBM-file or an application, as a 1:1 copy from your Mac to the SED. Text files will also be uploaded correctly, given for reasons explained below. Moreover, note the option "add no .bin suffix" will quietly overwrite any already existing file with the same name. This is usually what you want. This also avoids getting a mess on the SED.

    Be careful, however, with this overwrite option. In particular make sure, before you edit a file, which already exists on the SED, that you have currently the master rights and that you edit starting from the most recent version.

    There is a subtle advantage to this method for Alpha users. Alpha's ftp filesets or the ftp menu offer a convenient remote editing of files. If you use Fetch as the helper application to accomplish the involved ftp, these settings allow you to access files on a Mac as well as on a Unix machine. Since you do only upload the data fork in above settings, any remote editing of text files via Alpha is well supported.

    Finally note, above settings work generally well, since the SED is configured in a way, which allows to upload text files conveniently and safely from any platform. In this mode you upload text files as if you would NOT do it from a Mac (see next hints), i.e. only the data fork is transferred. Extensions are then used to actually assign the file to a particular application (see below). Note, this may imply, that the transfer gives the file to another application, e.g. uploading an Alpha file with extension '.PRJ' will result in a file, which is owned by RAMSES (see table below). However, a file with no extension uploaded in text mode, will be owned by SimpleText (see table below). This is usually no big problem, since what matters most for the release machinery based on the SED server, is that text files are stored as files of type 'TEXT'. Otherwise the release machinery fails. E.g. any MPW script not of type 'TEXT' crashes. Any file to be distributed in a release and which is not of type 'TEXT' will end up in the release as a binary file of an unknown application!

    Should you exceptionally wish to upload a text file from a Mac including its resource fork, e.g. because you wish the file to be owned by a particular application, e.g. Alpha or MPW, then you best upload it in MacBinary II mode. E.g. use button "Put File..." or temporarily change your preferences. Then you will get a 1:1 copy of the file even in text mode.

     

  • Using Fetch 4.0.3 On A OS X Mac Connecting to a X Server

    If you use Fetch on a Mac to download and upload files from/to SED, you should configure Fetch similar as described above, but with some differences. These are the recommended settings:

    • Default Upload Format: Raw Data
    • Check "Add .hqx suffix to BinHex uploads"
    • Check "Add .bin suffix to MacBinary III uploads"
    • Uncheck "Add .txt suffix to text files"
    • Check "Encode and decode file and folder names"

      

    OS X does not see the resource fork of files. Since ftp normally works only with the data fork, the resource fork is lost unless you take certain measures (see below). For many files, e.g. source code files, the resource fork is irrelevant. It may contain information on last selection, fonts, or tab width, information which is rarely essential. However, for other files, e.g. applications, the resource fork is essential and must not be lost. If you download such a file from our X Server, then you will obtain a corrupted file.

    Uploading of such files should be done with format "MacBinary III". On a X Server the option "Add .bin suffix to MacBinary III uploads" ensures that the file is characterized as a MacBinary file. A MacBinary file contains the resource fork stored within the data fork. Thus both forks are transferred during a ftp transfer. When you download such a file, Fetch will unpack it and the result is an identical copy of what you have originally uploaded.

    However, if you mount the X server via afp, a MacBinary file does not behave normally, since it has an empty resource fork. If you wish to use it directly, and without downloading it first via ftp, you can unpack it by drag-and-drop onto utility "StuffIt Expander". Then the file is restored to what it was before the upload. Note, however, once unpacked a download via ftp is no longer possible. You need AppleShare access to download it.

    It is recommended to use afp to download such a file.
         If you have no access to afp and would like to use ftp, then you would need first to issue a packing command to the remote X server, asking to convert the wanted file into the MacBinary format. The subsequent download would then result in the wanted file. There is a tool called macbin which can accomplish this task. You need to login by ssh (available to programmers of Systems Ecology), using e.g. application Terminal, go to the directory where the wanted file sits and then encode the wanted file:

                   cd <path to directory where myfile resides>
                   macbin -e <myfile> > <myfile>.bin
    	

    The result is then a file with the same name as your original file, but encoded (-e) and with extension .bin added. The encoded file can be downloaded via ftp. Using Fetch will result in the reconstruction of the file exactly as it was present on the X Server.

    Ex.: Lets assume you have a file called MyFile.app in directory Anschlagbrett on our server volume SE_Intern. The commands are then:

                   cd SE_Intern/Anschlagbrett/
                   macbin -e MyFile.app > MyFile.app.bin
    	

    There is one drawback with usingmacbin: It does only encode for MacBinary II format, not the more uptodate MacBinary III format. Note, all ftp users login to /Shared Items/FTPRoot/. What you see are actually only symbolic links to all available share points.

     

  • Using ftp from Unix or IBM PC machines

    Non-text files should be transferred in binary mode between your machine and the SED. This does not affect the content in any way and 1:1 copies should result. However, permissions, e.g. for executables, get lost and must be set again.

    The situation is more complex for text files, since most ftp clients affect the content of text files. Uploading of files via ftp from Unix and IBM PC machines is no longer a problem, given the ftp client does not affect the content of the transferred files. Thanks to the current configuration on the SED, each file is automatically assigned to a particular application. Of course, only if there exists one on the Mac, i.e. Unix or IBM executables remain what they are (given they were transferred in binary mode!). Using the "Internet Config" extension, this technique interpretes the extension of a file and assigns a creator (signature) and file type according to the extension of the file. All standards are supported plus the following special extensions, which are of relevance to us:

    Extension	Application	Creator (signature)	File type	Comment
    .MOD or .mod	Alpha	ALFA	TEXT	Modula-2 program or implementation module
    .DEF or .def	Alpha	ALFA	TEXT	Modula-2 definition module
    .PRJ	RAMSES Shell	RAMS	TEXT	RAMSES project file
    .DAT	Alpha	ALFA	TEXT	Any data file
    .DTF	Alpha	ALFA	TEXT	Any data frame file
    .txt	SimpleText	ttxt	TEXT	Any editable, simple text file
    none or unknown to "Internet Config"	-	hDmp	BINA	file transfer mode is binary
    none or unknown to "Internet Config"	-	SimpleText	TEXT	file transfer mode is text

    Using Unix hosts, ftp preserves the essential content of text files when transferring in text mode. In particular note, that uploading a Modula-2 file like a .mod-file from a Unix machine to the SED, results exactly in what we need: The file becomes a text file, which is owned by Alpha, and EOLs are translated to the Mac EOLs (CR). Fortunately, the content of the file is otherwise not affected, and special characters (>126) are fully preserved during down- and uploads. Consequently, if your Mac source should make use of special characters, such as 'ö' in a string, this character will be preserved during a down- and upload between a Unix host and the SED. Only if you really wish to translate such special characters, you have to do it explicitely on the Unix or IBM PC. Then you have to make sure to translate correctly in both ways, i.e. before uploads or after downloads. Neither the SED nor ftp will do it for you!

    Should your ftp client affect the content of a text file, it should only translate the EOL (end of line) accordingly to the target machine. However, it is NOT recommended to make use of such a feature. Note, on the SED it is currently Apple's standard ftp server, which performs the ftp service. Using a raw data mode instead of text mode, could be preferable when uploading files, since this does not change the content of a text file in any way. Should your ftp client insist on translating the content of text files, force it to translate for a Mac. A solution might be to avoid any translations at all, i.e. also excluding the translation of EOLs. This means avoiding the text mode at all. For example, from a Unix host upload in binary mode. The resulting file will be a 1:1 copy. In particular, EOL remains that of UNIX (LF) or IBM PC (CR,LF), yet the file type is 'TEXT' and it is owned by Alpha, e.g. when the extension is .mod etc. Most importantly this means also, you have to fear no disturbance of the RAMSES releasing machinery. Moreover, if you use a Mac, Alpha can still correctly open and edit such a file. The only disadvantage is, if you wish to make file content comparisons with Alpha, you will have first to make the EOL conversion on the Mac. Then, the drag-and-drop utility "ctc 1.5" comes very handy. It can translate the EOLs in any way for any number of files. This utility is contained in the RAMSES Extras release.

    Rules of thumb if in doubt: If possible avoid text mode, it may corrupt data! To a Mac upload all files in binary mode! To a Sun upload all files in raw data mode! To an IBM PC upload all files in raw data mode!

  [Contents ] [ Top] ] [ Bottom]

• Preparing a bootable CD for your Mac

  Some useful hints can be found here.

  [Contents ] [ Top] ] [ Bottom]

• Trouble Shooting

  We have an entire web page dedicated to trouble shooting.

  [Contents ] [ Top] ] [ Bottom]

Responsible for content: Andreas Fischlin  ( Last modified 22/05/2010 )