Works Just Like OS9..

I finally had the chance to borrow another G4 Desktop machine a day ago (G4450/256RAM/OSX10.1/7b), and decided to check out OSX to OSX Screamernet. If you want the conclusion first, it's this: it works just like it did under OS9 for 6.5/7 - all of the general principles excellently presented by David Todman here are still valid.

These are my notes on Screamernetting between two OSX boxes. It's not a definitive guide to the construction and syntax of the cmdline files that LWSN uses or the overall approach to Screamernet Mode 2 - that all seems covered by Davids' tute. Nor is it a replacement for a much-needed, full-on, step by step explanation of how to Screamernet using different networking protocols and arrangements (e.g. Appletalk, Sharepoints or even, God Forbid, only using your Public Folder in Users).

At the end of the article, I've introduced one final trick (for which Kent Matheson's recent multiple versions of Lightwave tip helped enormously) which makes life even easier than before.

Getting the Networking Right

It took me a while to understand that OS9's Chooser is simply replaced by Connect to Server in OSX's Finder. I know it's a little slow of me, but there you have it. I'd read a lot of stuff that seemed to suggest sharing folders or volumes in OSX was difficult, that you could only share your Public or Shared Directories and that if you wanted OS9-style functionality you needed to use a utility like Sharepoints. I think that that's true if you want to keep reasonable control over who can access various directories on your machine. What I didn't realise was that you can still log on to your host machine from any other OSX machine with your normal administrator-level logon and be able to mount and use any of your normal volumes. Obviously, in so doing, you leave yourself heinously exposed to anyone else in your organisation who wishes to commandeer your node machine and have their wicked way with the host, but...that one's your call.

The time-honoured network layout for Screamernet Mode 2 under OS9 has always been to mount the volume upon which your Program, Content, Command, Node and Output files reside on the node computers. To do this under OS9 you would simply enable File Sharing and Program Linking on your host computer and then enable sharing for the relevant volume(s). You'd then mount these volumes on your node machines and use Program Linking to boot up LWSN nodes on each one. Each LWSN node would sit in it's own folder as David's tutorial describes.

Under OSX, by using Connect to Server and logging on to your host machine from your node machine at your normal administrator level you can effectively duplicate this process.





Of course, there may be a few wrinkles along the way. Here's what I found in my specific setup: for some reason if I enabled Appletalk on both machines and tried to connect that way, the administrator login would fail to authorise. I ended up following the steps outlined in Apple's Knowledgebase documentation to set up two machines with private TCP addressing. All of this will depend on your own network configuration. Using this method I could log in as adminstrator and mount relevant volumes. The only minor problem was that when my volume was loaded on the node a '-1' was appended to the volume name which I assumed would screw up all of the paths to the Content, Command, Output and Plugins (given that my HD name is MacintoshHD).



It didn't. It's obviously some means of denoting that you have the same volume mounted twice but has no impact on the path specifications you're using. If there are any OSX gurus out there who can explain this, I'd love to hear about it.

Program Linking seems to be enabled by default in this scenario. I'm not even sure whether Program Linking is a valid concept under OSX.

Business as Usual With the New (to me Anyway) Wrinkle

Now that I had my working volume mounted on the node, it was easy to start the process of building node folders in the usual way but half way through I remembered Kent's tip on Flay about changing the name of your Lightwave application and the corresponding cmdline file to create different instances of the application. You know - the one where you could create 5 different versions of Lightwave with different memory allocations..(search for it on Flay).

Taking this a step further, I realised that if you created numerous instances of LWSN in the Programs folder i.e LWSN1, LWSN2, LWSN3 and corresponding LWSN cmdline files called LWSN1 cmdline, LWSN2 cmdline, LWSN3 cmdline then you wouldn't need to create separate node folders at all. Here's a screenshot of what I'm babbling about:



For each cmdline, just remember to increment the job1 ack1 numeral appropriately. This tidies up the whole directory structure nicely and works peachily.

In the end, I created three instances of LWSN in my Programs Folder booted two up on my host DP800 (one for each processor) and one on my borrowed G4450 and screamer worked for a couple of hours until I turned it off.

The Mysterious Command Directory

In the process of setting this up, I've become more convinced than ever that the Command Directory is currently redundant/broken. LWSN cannot correctly read the directory for Commands from Lightwave Layout 3 Preferences and will only look for Job1, Job2 etc. files in the root of the Content Directory. This would explain why you should always set your Command Directory to be exactly the same as your Content Directory.