Most HUNTER applications require storage of users' Basic source programs in an easily accessible bulk-memory system for support, updating, exchange and maintenance.
One very popular method of storing HUNTER programs is in user’s multi-access mainframe database systems, although minis, micros and other HUNTERs are also used extensively. HUNTER'S ability to communicate freely with these other systems is vital to supporting its programming and application.
LLOAD is the command for loading Basic source programs into HUNTER. It may be used to load entire programs or to modify existing ones by appending or overwriting lines.
LLOAD can be used with any of the communications protocols detailed in Communications. During LLOAD no text is echoed to the screen, to speed up the facility. Certain speed/protocol limitations are detailed below.
To enter program lines, simply type
LLOAD followed by carriage return. HUNTER will then load to memory source text presented on the serial port. Note that syntax is checked on a line by line basis and that if an error is detected, the LLOAD will terminate and a 'SYX Error' will be displayed on the screen.
If the program provided overflows the memory space available, a 'MEM Error' will appear.
LLOAD mode can be terminated by pressing 'ESC' on HUNTER'S keyboard or 'power off'. (Data will not be lost).
Alternatively, an 'ESC' character sent over the interface will return control to the keyboard.
Logically, it is difficult for a program to append to or modify itself, since the sequence controlling the modification may be modified as well! However, HUNTER programs can contain sequences that will command a remote processor to send program text and then accept that text as Basic source.
Current versions of HUNTER Basic do not support LLOAD as a program statement, e.g.
100 LLOAD. However, the 'Logical Keyboard' Flag has the same effect as LLOAD and can be commanded in a program as a POKE instruction. By setting the flag to the serial input port and then returning to interpreter mode, HUNTER is configured to accept new program lines. These lines may overwrite the lines originally used to enter the LLOAD mode.
Loading may be terminated by sending an unnumbered 'RUN' statement which will cause execution to re-commence from the start of the new or updated Basic program, making the load sequence virtually transparent to the operator.
A possible program format might be:
100 REM Program reload routine 110 INPUT "Please enter new program name", X3$ 130 LPRINT X3$ 140 POKE LK,1 : REM This sets the logical keyboard as the serial input port 150 END : REM Returns control to the interpreter . . . The new program lines now load . . . The last line transmitted is unnumbered RUN, which executes: 10 POKE LK,128 : REM Restore the logical keyboard 20 PRINT "New program loaded OK : Continue?"
Variable LK is the address of IPFLAG, addresses of memory locations may be found in Memory Locations.
HUNTER'S input buffer ensures that the first line of program is captured, no matter how quickly the distant computer responds.
In present versions of HUNTER operating system, any alteration to program content, including deletion of lines, automatically clears all variables and arrays. This is essential to HUNTER'S operation, but means that data cannot be carried across reload boundaries. Data copied to files is not affected, however.
LLIST is the principal method of copying and recording HUNTER programs.
Invoking LLIST causes program lines to list sequentially from the lowest line number or from a line number specified as an argument in the LLIST. Examples are :
LLIST terminates when all line numbers are listed, when 'ESC' is pressed or when HUNTER is powered down. Data will not be lost if HUNTER powers down during a listing.
LLIST cannot be incorporated in a program, and is only available for manual use.
Protocol and format selections made in HUNTER'S communication package are observed transparently by LLIST. Carriage Return terminator characters are provided at the end of each program line, line feed and null characters are optional.
Remember that HUNTER'S communication system needs to power up to its RS-232 state for transmission to occur. This power-up will cause an off-to-low transition that many systems will read as a single, spurious, character. This event only occurs once and can be avoided by powering up the interface prior to activating a receiving device.
Methods of pre-powering the interface include :
LPRINT " " : REM the interface powers up automatically OUT 132,1 : REM Direct control of the communications inverter
Remember that once powered up, the RS-232 output remains active until HUNTER is powered down or the inverter is commanded 'off' by:
HUNTER power consumption increases substantially during RS-232 transmission with corresponding reduction in battery life. It should be noted, however, that if the RS-232 line is powered off further serial transmission will be lost unless the interface is powered up again, by:
The interface will not power-up automatically with a simple LPRINT statement with no argument.
It is always advisable that some form of protocol handling is established between HUNTER and associated computers.
Some multi-access mainframes and some popular microcomputers are unable to support any form of protocol, however.
In these cases, HUNTER will generally support direct program transfer at speeds of 1200 baud or less. At higher speeds, HUNTER'S input buffer may overflow leading to loss or truncation of lines. At 1200 baud, the buffer smooths the flow of incoming program through HUNTER Basic's syntax checking routines.
Problems with truncation will invariably lead to the load operation being aborted and a 'SYX Error' message being displayed, since the Interpreter will not accept partial lines.
The capability of supporting simple 1200 baud communication is invaluable in many situations.
A very useful HUNTER feature is the ability to communicate directly with mainframe databases using TERM.
This interactive mode can be used manually to establish procedures, logon passwords, etc., before attempting to transfer or copy files or inspect data.
Sequences proven out manually can in most cases be implemented in HUNTER Basic as automatic features of the user's program once protocols, etc, have been finalised. Such sequences can present inputs to the mainframe and inspect the reply for keywords like 'READY' or simple cursor prompts.
Many mainframes are unpredictable in the response they provide to login sequences, with variable 'welcome' or 'news' messages. Make sure your automatic sequence is robust enough to handle these eventualities!
Some general points about database communications should be noted:
Communication occurs generally at 300 baud, although other configurations are possible. Remember that the screen character generator will display all ASCII characters, even if they are not shown on the keyboard.
Other rates encountered on dial-up systems are 110 (very rare) and 1200, but only with sophisticated modems.
Dial-up systems can expect any of even, odd or no parity selections. Transmit and receive parities are generally the same. Always use receive parity if it is available - the occasional appearance of the parity error symbol is a useful indication of bad lines. Remember that telephone lines can be bad in one direction only.
Database systems vary widely in the use of full or half duplex operation.
Full duplex occurs when the host system 'echoes' every received character back to HUNTER. In this mode, HUNTER'S transmission echo should be selected 'off' so that characters typed on the keyboard only appear on the screen if they have completed the whole circuit of HUNTER - Mainframe - HUNTER.
Basic routines can check full duplex replies as an absolutely secure communication protocol, provided the mainframes' own messages don't confuse the issue.
If the echo switch is left 'on', double characters will appear on the screen. This in no way affects communication, but makes outgoing messages hard to read!
Half duplex occurs when the host does not echo characters back to HUNTER. In this situation, the echo switch should be 'on' to allow outgoing messages to be read by the operator. This method does not guarantee that data sent to the host is being correctly interpreted.
A third mode, Simplex, occurs when data is sent in only one direction at one time and is otherwise similar to Half duplex. HUNTER is not concerned which mode is in use.
Unfortunately, very few dial-up databases support any kind of protocol, so that generally HUNTER'S 'none' option should be used. Note that 1200 baud is the fastest recommended speed for no protocol program loading.
However, some systems do support 'XON/XOFF' although implementations vary between computers - seek advice from HUSKY Computers if difficulty is encountered.
The setting of 'NULL' and 'LF' are generally not material in mainframe communication, so that '0' is recommended for NULL count. See below for LF.
HUNTER's 'ENTER' key generates CR (Carriage Return), but some mainframes expect other terminators. Examples are Control C and LF (Line Feed), or 'New Line'. Consult your computer manual for details.
HUNTER'S DEL (Delete) key generates 'rubout'. Few mainframes recognise this, or in many cases allow any deletion at all! 'Cursor left' may work in some cases.
Good quality communication can often be achieved over surprising distances with acoustic couplers at 300 baud, but this method is not recommended for routine daily use.
It is worth knowing that source files kept on computer systems can have further documentation within them by using unnumbered 'REM' lines, e.g.
100 PRINT "HELLO" REM This line of text will be ignored by HUNTER only line 100 will load into HUNTER.
This prevents loading unnecessary text. Naturally, these lines can only be created on the host or database computer.