|
www.riscos.com Technical Support: |
Currently, OmniClient must be loaded from some form of secondary storage medium, such as a disc: this poses the question of how to load it into network stations that don't have a local disc.
This is not difficult to do, but does require care. There are two principle cases to consider, depending upon whether the target machine has a DCI 2 or a DCI 4 network protocol stack available from its onboard ROM.
All of the following instructions assume that you have correctly upgraded your network's shared copy of !System, using !SysMerge as supplied with this release.
As mentioned elsewhere, it's a simple matter to determine whether your machines have DCI 2 or DCI 4 software: at the command line, type the command
help intern.
(Note the full stop.)
If your machine has a DCI 4 stack the procedure is comparatively trivial, since there is no requirement to replace the running network stack.
There are a few simple methods which can be used to load OmniClient depending on your system configuration. You can either use Acorn Access+, or using the Applications Accelerator supplied with Acorn Level 4 Release 3, or if you have Acorn Access cards with LanManager protocols installed, you may load OmniClient from an NT server (but check with your supplier if in any doubt as to which protocols are available on your Ethernet card).
It is possible to use other methods, such as loading directly from a Level 4 fileserver, although this is not recommended for performance reasons. Another way is to use one of the available third-party application loading mechanisms. In such cases contact the software publisher if it is not obvious how to proceed (you may well find that the following instructions provide sufficient information to enable you to set this up, however).
If you do have Access+, you will find that the function of the Access `discs' icon is taken over by OmniClient (assuming that you've selected `Access' as one of the OmniClient protocols in OmniSetup): if you are using the Applications Accelerator, you will find that the `discs' icon is removed from your icon bar, but that you do not have available the Acorn Access functions within OmniClient. This is because OmniClient is designed to operate with full versions of Access only, not with the read-only version that forms the basis of the Applications Accelerator. This does not pose any problems, since the actual ShareFS filing system is still available, and any command line access to it will still work (such as takes place when OmniClient loads its component files). Indeed this can be viewed as a positive advantage, in that it further simplifies a user's interaction with the network - it's one less fileserver type to worry about.
If you are using LanManager and have Access+ with OmniClient you will need to ensure that your machine is configured correctly in order to boot OmniClient directly from an NT server, or equivalent. In order to do this, you will need to make the following configuration changes to your machine from the command line:
| Star command | Action |
| *Configure Boot | This command sets the configured boot action so that a power on, reset or Ctrl Break runs a boot file. Depending on the system version being used, this option may or may not need to be changed. |
| *Configure FileSystem LanMan | This sets LanMan as the configured filesystem. |
| *Configure LMTransport IP | NetBEUI | Configures the filesystem to the IP or NetBEUI protocol, depending on your network configuration. |
| *Configure FS name | This sets the domain name (or fileserver) from which LanManager will attempt to boot. |
Each of these changes will take effect on the next power-on or hard reset.
If your machine has a DCI 2 stack you should ideally consider upgrading the software on your network cards, as otherwise new network software will have to be loaded via the network. Potentially the connection will be broken in the middle of this process, while the DCI 4 protocol stack is loaded.
There is, however, a simple way to address this, and that is to use the Applications Accelerator supplied with Acorn Level 4 Release 3. Note that it is important to use this version of the Applications Accelerator, as it will operate correctly with the existing DCI 2 stack, rather than the more up-to-date DCI 4 version (which as its name suggests, requires DCI 4, which we don't yet have!).
We also assume here that you have the correct DCI 4 driver module for the cards that you are using: if you don't have Acorn-supplied cards, you will need to contact the card manufacturer to obtain a suitable driver (some third-party drivers are supplied in our standard distribution, but not all).
There are several possibilities here, covering differing combinations of network software already in use in the Acorn environment: we will consider those relating to Acorn-supplied software in common use. The example files listed below are supplied on the support disc.
This assumes a network using a Level 4 fileserver, but not using the Applications Accelerator for resource and application delivery.
In this case, we advise that you use the Applications Accelerator: if you have more than a couple of machines, then it's quicker to have them load the Applications Accelerator client software from the Level 4 server, and then use this to load the rest of the components required for OmniClient, than it is to try loading these items directly from the Level 4 server. The sequence is also much simpler, due to the `connectionless' nature of the Access protocols used by the Applications Accelerator.
This assumes a network based around a Level 4 fileserver, used in conjunction with either Acorn Access or the Applications Accelerator for applications and resource delivery.
We assume that all your network cards are of the same type - that is, they require the same driver: if this is not the case, you either need an appropriately-configured copy of !Bootnet for each type, or you need to take equivalent action.
We will also assume that your client machine boot sequence already loads the Applications Accelerator client software - if it doesn't, then as suggested in the DCI 4 section above, contact your local network support agent, or Customer Services, for advice on how to improve your boot sequence to make use of this mechanism. In fact, it's quite simple to run this software, and then issue a Filer_Run command to transfer control of the bootstrap sequence to a !ShareBoot application, located on a shared resources disc.
The following sequence of commands should be used as a basis for your !ShareBoot application, to replace the running DCI 2 protocol stack with a new DCI 4 stack, and then to install OmniClient:
!ShareBoot.!Run
Set ShareBoot$Dir <Obey$Dir>
Desktop Obey -c <ShareBoot$Dir>.!Deskstart
!ShareBoot.!DeskStart
ChangeDynamicArea -RamFsSize 700K
Copy <ShareBoot$Dir>.!Bootnet RAM:!Bootnet ~V ~C R
CDir RAM:Modules
CDir RAM:Modules.Network
Copy System:Modules.Network RAM:$.Modules.Network ~V ~C R
Set Sys$Temp <System$Path>
Set System$Path RAM:$. Run RAM:!Bootnet
Set System$Path <Sys$Temp>
UnSet Sys$Temp
Wipe RAM::RamDisc0.$.* ~c~vfr
RMKill RamFS
ChangeDynamicArea -RamFsSize 0
Filer_Run <ShareBoot$Dir>.!Omni
... remainder of boot file
This assumes that a suitably-configured !Bootnet and !Omni are both stored within your !ShareBoot application: you may choose to hold them elsewhere; if you do so, then simply modify the paths given as appropriate to reflect your chosen location for these items.
This assumes a network using Acorn Access in conjunction with a fileserver which requires the use of OmniClient; for example an Xemplar SchoolServer.
As with any Access boot sequence, you need to set up a `shared disc' to act as your boot server. Configure your clients to Boot, from the filesystem ShareFS, and save this disc as the first (leftmost) mount from the icon bar menu.
This is essentially the same sequence as above, with the important exception that !Bootnet does not get run - it is only necessary to load and initialise the required modules, which can be done as follows, assuming the use of an AEH70 network card:
!ShareBoot.!Run
Set ShareBoot$Dir <Obey$Dir>
desktop obey -c <ShareBoot$Dir>.!Deskstart
!ShareBoot.!DeskStart
ChangeDynamicArea -RamFsSize 700K
CDir RAM:Modules
CDir RAM:Modules.Network
Copy System:Modules.Network.Internet RAM:$ ~V ~C
Copy System:Modules.Network.AUNmsgs RAM:$ ~V ~C
Copy System:Modules.Network.Ether3-16 RAM:$ ~V ~C
Copy System:Modules.Network.MManager RAM:$ ~V ~C
RMKill ShareFS
RMKill Freeway
RMKill InternetA
RMKill AccMsgs
RMKill Ether3 (or whatever is appropriate for your
cards)
RMLoad RAM:AUNMsgs
RMLoad RAM:Mmanager
RMLoad RAM:Ether3-16 (or whatever is appropriate for
your cards)
RMLoad RAM:Internet
RMReInit Freeway
RMReInit ShareFS
Wipe RAM::RamDisc0.$.* ~c~vfr
RMKill RamFS
ChangeDynamicArea -RamFsSize 0
Filer_Run <ShareBoot$Dir>.!Omni
... remainder of boot file
This mechanism is somewhat more efficient than the simpler copy operation used in the AUN case, though it gives the appearance of being more complex.