MARKNET and RELNET

Prev Next Home Home Table Of Contents Index

MARKNET and RELNET

Use of these utilities is very similar to that described in the preceding section. MARKNET is analogous to FMARK, and RELNET is like RELEASE. MARKNET stores more information about the system's status than does MARK, so it is appropriate for managing TSR's, such as network shells, that hook into the system at a low level.

Because MARKNET stores so much information about the system, it always writes the data to a disk file in order to reduce its own memory usage.

Command line syntax for MARKNET and RELNET is:


  MARKNET [d:][directory]filename [/Q]
  RELNET  [d:][directory]filename [options]

The main command line parameter to each program specifies the name of the file where the mark information will be stored. We refer to this file as the net mark file. A complete pathname should be specified for the net mark file. RELNET's pathname must exactly match that passed to MARKNET, with the exception of case.

Note that MARKNET and RELNET may be used in almost any situation where FMARK and RELEASE are used. MARKNET saves all of the same system information as does FMARK, but it goes further to store information such as the device driver chain, DOS internal variable areas, DOS system file tables, DOS environment, communications port status, XMS memory state, and other information. Nevertheless, MARKNET and RELNET were written primarily because of the large demand to release the NetWare shell. We'll refer to NetWare specifically in the following and provide an example of how to load and release it.

The only new restriction for using MARKNET is that the system must be running DOS version 3.0 or later. MARKNET depends on the format of certain internal DOS data structures that were quite different in DOS version 2.

Like FMARK, MARKNET leaves a small (144-192) byte mark in memory, and writes a disk file to store the system status. MARKNET's file varies in size, but is typically 3-4 kilobytes (K). The size depends on the number of device drivers, the value of the 'FILES=' directive in CONFIG.SYS, the number of EMS and XMS memory blocks allocated, and other DOS implementation details.

Do not attempt to redirect the output of MARKNET. Doing so will waste at least one file handle that cannot be recovered later by RELNET. MARKNET's /Q option is provided to prevent it from writing any screen output.

Marks placed with MARK, FMARK, and MARKNET may be mixed in the same system. RELEASE treats all marks placed with MARKNET as protected; such marks may be released only by calling RELNET explicitly. Consider the following example:


  MARK TSR1
  TSR1
  FMARK C:\MARKS\TSR2.MRK
  TSR2
  MARKNET C:\MARKS\TSR3.MRK
  TSR3

Entering RELEASE by itself would generate a warning and do nothing else. Entering RELEASE C:\MARKS\TSR2.MRK would generate the same warning. The only way to get all three of these TSR's out of memory would be to enter the following commands in sequence:


  RELNET C:\MARKS\TSR3.MRK
  RELEASE C:\MARKS\TSR2.MRK
  RELEASE TSR

RELNET has options to control how much of the system state it restores. Several of the options match those of RELEASE; new ones are also provided to control the additional information that MARKNET stores. RELNET accepts the following options:


  /C        do NOT restore the communications ports.
  /E        do NOT access EMS memory.
  /H        work with upper memory if available.
  /I        do NOT shut down IPX events and sockets.
  /K        release memory, but keep the mark in place.
  /P        do NOT restore DOS environment.
  /Q        write no screen output.
  /R        revector 8259 interrupt controller to powerup state.
  /S chars  stuff string (<16 chars) into keyboard buffer on exit.
  /T        do NOT reset the system timer chip.
  /U        work with upper memory, but halt if none found.
  /V        verbose: show each step of the restore.
  /X        do NOT access XMS memory.
  /?        write help screen.

You can also put the string RELNET=options in the DOS environment. For example, if you type


    SET RELNET=/U/Q

at the DOS command line, RELNET will use the /U and /Q options as the defaults thereafter.

None of these options, except perhaps /U, is required in order to release the NetWare workstation shell.

/C prevents RELNET from restoring the communications state of the system (as encoded in the 8250 async chip and the 8259 programmable interrupt controller). Because both of these chips provide readable registers, MARKNET is able to store an accurate picture of the communications state when the mark is stored; RELNET can restore the state to exactly what it was. Therefore, the /C option should be needed rarely, perhaps only on newer PS/2 models that don't use the 8250 as a communications controller. Note that MARKNET stores information only about COM1 and COM2.

/E is made available for systems running early, buggy EMS drivers that don't correctly implement all of the EMS 3.2 system calls. Don't use it unless you have an EMS-related problem during or after running RELNET.

/H is like /U (see below), but will continue even if no upper memory blocks are found.

/U will cause RELNET to halt if no upper memory blocks are found. With /H you can write a batch file that works on all machines whether or not they have upper memory blocks.

/I prevents RELNET from detecting and deactivating IPX events and sockets owned by the memory blocks being released. (IPX is the low level communications protocol used on Novell networks.) Don't use it unless it solves a problem for you.

/K is useful when you will be releasing and reloading a TSR repeatedly. With it, you avoid the need to replace the mark each time the TSR is released. Using /K prevents RELNET from deleting the net mark file.

/P keeps RELNET from restoring the DOS environment, which it normally does because NetWare modifies the DOS PATH. In some cases, other changes to the environment should not be undone; use the /P switch only when such changes must be preserved.

/Q prevents RELNET from writing any screen output (unless an error occurs). This is useful when you are using RELNET in an integrated system. Redirecting RELNET's output causes technical problems and should never be done.

/R may be useful for unloading task-switching utilities that "re-vector" the hardware interrupt controller. Use it only if it solves a problem.

/S followed by at least one space and then a short string (15 characters or fewer) tells RELNET to stuff this string into the keyboard buffer just before exiting. RELNET automatically adds a carriage return to the end of the string. The string may not contain tabs or spaces. See the discussion of /S in the preceding section for more details.

/T keeps RELNET from resetting the system timer chip to its default rate, which it does by default.

/U causes RELNET to access high memory. See the discussion of high memory in the previous section for more information.

/V activates additional status reporting during the release and may provide useful information in cases when RELNET isn't working.

/X prevents RELNET from restoring the state of XMS (extended) memory. This option is provided in case of an unforeseen conflict with an XMS memory driver. Note that this option also controls whether the HMA (high memory area) is restored.

The following is a simple version of a NetWare LOGIN.BAT file with support for releasing the shell:


  rem place the mark
      marknet C:\NET\NETWARE.MRK

rem load the NetWare shell TSR's ipx net3 rem optional portions of the shell rem netbios rem int2f

rem switch to login drive and log in F: login USERNAME

At a minimum, the items in uppercase will need to be customized for a given user and workstation.

NetWare could then be released with the following batch file:


  rem let the server know we're leaving
      z:\public\logout
  rem restore the workstation
      relnet C:\NET\NETWARE.MRK

As of version 3.0 of TSR Utilities, you may release the NETBIOS emulator independently from NETx and IPX. You should always release NETx and IPX together.

Prev Next Home Home Table Of Contents Index

Sponsors
Shopping
Forum
Forum
email
EMail
Index
Index
Home
Home