THE LDOS QUARTERLY               April 1,1982               Volume 1, Number 4
------------------------------------------------------------------------------


                              Table of Contents
                              =================

 VIEW FROM THE BOTTOM FLOOR ........................................ Page  2

 LED - The LDOS Text Editor ........................................ Page  5

 UPDATE NEWS - 5.1.2 ............................................... Page  6

 WHAT'S NEW ? - LDOS compatible software ........................... Page  9

 ITEMS OF GENERAL INTEREST ......................................... Page 10

 TCHRON AND TTIMER CLOCK/CALENDAR PATCHES .......................... Page 12

 FILTER PACKAGE UPDATE ............................................. Page 13

 HIGH MEMORY AND LDOS .............................................. Page 13

 CMD"O" - Implementation and possible uses ......................... Page 15

 PARITY = ODD - By Tim Daneliuk .................................... Page 17
                Includes review of Johnson Associates software

 REVIEW - Structured BASIC Translator by Sue Ratkowski ............. Page 21

 THE LIBRARY - By Earle Robinson ................................... Page 28

 INSIDE THE EXPANSION INTERFACE - By Earle Robinson ................ Page 39

 CHANGING OPERATING SYSTEMS - By Charlie Butler of TAS ............. Page 40

 ROY'S TECHNICAL CORNER ............................................ Page 42

 THE JCL CORNER .................................................... Page 46

 USER CONTRIBUTED PROGRAMS
      DIRECTORY MAPPING PROGRAM - By Bill Fields ................... Page 50
      BINHEX/BAS - By Tim Mann ..................................... Page 55
      DELETE/CMD - By Renato Reyes ................................. Page 56
      NODAM/CMD  - By Chuck Jensen ................................. Page 58
      MX80/FLT   - LSI staff ....................................... Page 59

 PROFILE PATCHES, MODELS I AND III - By Dick Yevich ................ Page 59

 SALVAGE/BAS AND RSCOBOL PATCHES ................................... Page 62

 5.1.2 PATCHES ..................................................... Page 64


             Copyright (C) 1982 By Logical Systems, Incorporated
               11520 N. Port Washington Rd.  Mequon  WI  53092
                               (414) 241-3066


                                   Page - 1



            V I E W   F R O M   T H E   B O T T O M   F L O O R

This has been a  very busy quarter for our  staff, as LDOS has  become one  of
the leading operating  systems for the TRS-80 and demand for our  products has
risen dramatically.  To our  many  thousands of users, THANK YOU. We will make
every  effort  to make  the  LDOS  product line the  best  designed,  written,
documented and supported line of software for the TRS-80.

In  the  last newsletter I stated that  the Extended Support  Agreement  (ESA)
would be $50 per year. After that newsletter went to press it  was decided not
to include 800 line  support in the ESA and to  drop the price of this support
to just $25. The ESA allows the subscriber to receive updates within  the same
version for just  $5,  as  often as  he wishes,  receive four  issues of  this
publication and  to be a member of the LDOS bulletin board on MicroNET (if you
are a COMPUSERVE subscriber).

Due  to large increases  in  sales volume and  some  changes  in warranty  and
support services, we have been able  to  reduce the  suggested retail price of
LDOS to $129.

The current version of LDOS is 5.1.2  for both the MODEL I & III. The features
are now the same for both machines,  other than some slight differences due to
hardware.  This  new version is available  now. You must send in  your  MASTER
disks  with a check for  the correct amount  (see the customer service section
of your  manual) to receive this update.  Model  I users  should note  that we
require BOTH of their master disks to perform this update.

In  the past we have  issued patches to LDOS to correct  minor  problems or to
add minor features. In the future we will be offering very  few corrections or
enhancements  in printed form.  We  feel that it  is  better  to maintain  our
system through  the use of our  update policy. We feel our update policy is  a
fair  and equitable way of  dealing with the ongoing cost of support.  In this
way we are  able to deal with support in a straight forward manner, because we
are sure of the state  of  the version in  use by the user. This does NOT mean
that we will not  be publishing  patches from  time to time.  We  will publish
patches  for such things as  optional enhancements or  very  minor corrections
that are not considered critical in nature.

We  now have  two  new LDOS  packages. They  are both  designed  around a  new
product  we  call  "smal-LDOS"  (pronounced  'small-dos').  This  product is a
minimal runtime DOS based on LDOS. It  will be  marketed to OEMs and  software
publishers and  is  available  for  the Model I and III. The OEM version comes
with a manual in a  5-1/2 by  8-1/2  format, while  the software  distribution
version contains only  a  master  smal-LDOS disk and NO documentation. Both of
these new products  will be available only when they  are a part of a software
or  hardware package.  However,  any  registered LDOS owner can  order (direct
from LSI) one copy of the  smal-LDOS (disk only) product  for $25. This may be
of  value for those  who wish to  have more storage on a "system" disk, as the
libraries (SYS 6 &  7) are much smaller  on this product, or to those who just
want a optimised minimal LDOS to use when  running  applications. This product
is available in Model  I 35 track single or double density and in Model III 40
track double density (specify when ordering).





                                  Page - 2



LSI  will  provide  LDOS on several types of media to meet  certain needs. The
charge  is  $10 if  we provide the diskette  and $5 if the  user provides  the
disk. These will of course  be provided  to  REGISTERED LDOS owners only.  The
system files on these  disks  are located  in such a  fashion that the overall
performance  of  the  system  is  optimised.  The  following  disk  types  are
available:

FOR THE MODEL I TRS-80:
       35 Track, Single sided, Single density (two disk set)
       35 Track, Single sided, Double density
       80 Track, Single sided, Single density
       80 Track, Single sided, Double density
       77 Track, Single sided, Double density, 8-inch

FOR THE MODEL III TRS-80:
       40 Track, Single sided, Double density
       80 Track, Single sided, Double density

NOTE: These disks  are available in  addition  to  the standard media supplied
and not in lieu  of the  standard media. You must specify exactly what type of
disk you  want  (from the  above  list) when ordering, and  include  your LDOS
serial number. We do  not offer double sided system disks at this time. We are
evaluating the reliability of double sided drives and when they  prove to work
reliably we will offer system disks in the two sided format.

The  MicroNET   bulletin  board  is  a  very  good  place  to  receive  timely
information  and  assistance when using LDOS. Users of this board  are  hereby
warned that we will  NOT tolerate the misuse of this service.      The  use of
profanity  or the leaving of slanderous,  libelous or unsubstantiated critical
remarks  on the board will be  cause for canceling the membership of the user.
So  please be  honest, fair and serious  when using this  service. Also if you
have  messages to you that are  not of general  interest to LDOS users, please
delete  them  after  you  have read  them.  Also do  NOT  ask questions  about
clerical matters,  such  as "has  my update been shipped ?", "I didn't receive
my last quarterly" or change  of  address notices and  the like. The  bulletin
board is handled by our TECHNICAL staff not our clerical staff.  Any  clerical
services request must be in writing to our customer service department.

Our telephone support group no longer has any portion  of the LDOS source code
available  to  them  in their  area  of  our building.  So  requests  for  any
information that will require checking the source code  MUST be in  writing to
customer service, ATTENTION: SYSTEMS GROUP.

Please be  careful  when  ordering  products that  are  supposed  to  be  LDOS
compatible. If  we don't definitely state that we support a product  (software
or  hardware) then  do not look to us for support.  When a vendor states  that
his product  is LDOS  compatible, we take that at  face value and assume he is
telling the truth, but we will  not be responsible for false information given
to us by vendors. Check  with us before you buy. We  will be happy to tell you
our position on the product  that  you are considering.  Don't  complain to us
after you have purchased a product and find you have problems.

With regard to the Model  III, we are aware of "Model III type" computers from
several sources. LSI officially supports  ONE type of  Model III, and that  of
course is the official  standard machine  produced exclusively by Radio Shack.



                                  Page - 3



LDOS seems  to work with  most of the other machines..... BUT  ..... We do NOT
have these  machines  in  house  and  therefore  do  not  support  them.  Many
thousands of users  (with standard Radio  Shack hardware) use LDOS with little
or no  problems. To call and say LDOS  won't  format disks  in your  Brand "X"
Model  III  will  probably   meet  with   a  ....."I'm  sorry  we  can't  help
you.........", response. We are willing to  support most quality products that
wish  to  be  supported by  LDOS,  but  only with the full  cooperation of the
manufacturer and with hardware provided by that manufacturer.

Now  for some bad  news.... Our "C" compiler,  known as "LC", has been put  on
HOLD for the  moment. It was very  close to release  when unexpected "personal
demands"  on the author  made  it impossible to proceed. We hope to be able to
revive the  "LC" project in the  near future.... but no promises. So, for  the
time being the LDOS "C" compiler  has been withdrawn as  an  offering  of  the
LDOS product line.  Our apologies  to those who have been awaiting the release
of this product.

Any  registered LDOS user may order  an additional copy of the LDOS manual for
$59 or may order a  replacement for a damaged or  older version of  our manual
for $29.  If ordering a  replacement,  the old manual must be sent in with the
order! Any manual order includes a new binder  and tab set. Please add $5  for
shipping and  handling. Phone orders will  not be  accepted for  "replacement"
manuals. All manual orders must be  placed directly with LSI.  Manuals are NOT
available from dealers or distributors.

The LX80 interface for  the Model I is still available direct from LOBO DRIVES
for a $449.00 This price includes 32K of  RAM, and support for both 5"  and 8"
drives  in single  and double density. The  dual channel  RS232  option  is an
additional $50.00.  We  have  found  the LX80 to be a very  reliable  piece of
hardware, and use them daily at LSI.

If you are not  on the  ESA or covered by the  LDOS  warranty, you  may  still
update  your  Master  disk  to  the  latest  release  within  the  version you
purchased for $10. This is a  lifetime  right for all  registered LDOS owners,
subject only to eventual cost increases to cover  our  costs of providing this
service.

This newsletter is  no longer  included as part  of  the  standard support for
LDOS but is available to those on the Extended Service Agreement, or  to those
covered  on our "OLD" one year warranty. For those who will not have access to
the newsletter, we are installing a LDOS  HOTLINE. This will be a three minute
tape recording stating  the latest LDOS news,  patches, new products,  etc. It
will  be available 24 hours a day, so that it may be called at low rate times,
at  a very low cost to the user. This service  will be available in early July
of  this year. The number will be in the next newsletter and will be available
through directory assistance for area code 414.

Radio  Shack has announced a  double density  controller for the  Model I.  As
this product becomes available, we have every  intention of providing official
support for it. Please give us a little  time  after it  comes  out so  we may
check it out completely. We will also  support  the  new Visicalc and  the new
Super Scriptsit, when time permits.






                                  Page - 4



                            LED - THE LDOS EDITOR

LED is a screen oriented  text editor that is designed  to  work with the LDOS
operating system.  Although  very versatile,  the  LED  commands are  easy  to
learn. Those familiar with the LDOS  LSCRIPT version of Scripsit will notice a
similarity in the  command  key layout. This is the LED command menu,  and can
be displayed at the bottom of the video screen while using LED.

      INDNT  FIND CHANGE HEX  UNMRK DNP  UPP  ALL  AGN       NAME EXIT
       =1=   =2=   =3=   =4=   =5=  =6=  =7=  =8=  =9=       =:=  =-=
      INSRT  LIN   DEL   WRD   BLK  END  TOP  SPA  TAB       MENU SAVE
                                    {TEST/TXT:0-R}    ( 0):X'00'|35751

The display  contains the name of the file currently being edited, the current
cursor  column, the hex  value  of the  character  under  the cursor,  and the
available memory in the text buffer.

Since LED  uses the LDOS keyboard driver,  type-ahead and all keyboard filters
are available for  use with LED. Also, all 128 ASCII  characters are available
directly from the keyboard.

Cursor  positioning is  done  in the  normal manner, with  the  4  arrow  keys
controlling the  cursor  motion.  The <CLEAR><ARROW> keys will move to the top
or  bottom  of  the  text,  or  to the  left  or  right end  of  a  line.  The
<SHIFT><LEFT> and <SHIFT><RIGHT> arrows also perform movement to  the ends of
a line unless tabs  are  set.  Then,  they position  either  to the  next  tab
location  or  back   to  the  previous  one.  There  are  4  different  cursor
characters, depending on the mode  you are in (typeover, insert,  insert line,
or  delete).The UPP and DNP commands are used to move the display buffer up or
down  a full page at a time. If the file  to be  edited has  a /KSM extension,
LED  will  automatically  display  the  alphabetic  letter  before  each  line
assigned to that letter.

LED can  be  used  on  many different  types of  files. The  FIND  and  CHANGE
commands make  it handy  for doing  global changes in BASIC programs. The  AGN
and ALL commands let you find or change things one at a time or all at once.

A very useful feature  is the HEX mode. This  mode  is  available either when
overtyping  or  when inserting.  It  allows  you  to input  characters  as two
hexadecimal  digits over the  entire  X'00' to  X'FF'  range, making  possible
direct editing or inputting of graphics characters.

Certain parameters may be  specified when first entering LED. TABS will  cause
any X'09'  tab  character to  be  expanded. Tabs  normally appear  as  a small
graphics  block. SAVE="filespec" will save a file  under a different name than
was used  to load the file. XLATE=X'fftt' will perform a character translation
when  loading and saving a file. Two  other parameters, END=X'00'  and WP deal
with word processor files that use an X'00' to mark the end of a file.

One very nice  feature is an  automatic  SAVE  prompt. If  you request an exit
back to LDOS Ready, and have modified the text buffer, LED will  automatically
ask  you  if you want to save the file. If no modifications have been made, an
immediate exit to LDOS is done without the prompt.

LED is available for $40.00 from any of the LDOS distributors.



                                  Page - 5



M O D E L   I   5 . 1 . 2   U P D A T E
=======================================

The following new files will be on your LDOSXTRA disk:

   MOD1/EQU has been renamed to EQUATE1/EQU.

   MOD1/DCT - A file  used to set default values  for floppy drives,  normally
   used along with hard drives.

UTILITY PROGRAM CHANGES

BACKUP now allows you to cancel  the QUERY parameter during a backup. Pressing
<C> in response to the prompt will cause the backup  to continue non-stop from
the current file.

FORMAT has  a  new parameter, WAIT=. This  parameter was  added to make up for
deficiencies in certain  80  track drives,  and  is  NOT normally needed.  Its
purpose is to provide a delay between each stepin to another track. It  should
only be used when ALL tracks above a  certain point get locked  out. The value
for  WAIT   will probably be a number  between 5000 and  50000,  and may  vary
greatly  from drive to  drive. It is suggested  that a value of 25000 be  used
initially, and then adjusted up or down as needed.

DRIVER/FILTER PROGRAM CHANGES

KI/DVR has  been  significantly changed. Two new parameters, DELAY= and RATE=,
have been added.  DELAY is the initial delay  between  pressing a  key and the
first repeat, and can be any  value  greater than  10. The default is  30, and
provides about 3/4  of a second delay. RATE is the key repeat rate, and can be
any value  larger  than 1.  The default  is 3,  and provides a repeat  rate of
about 10 per second. All of  the  KI parameters (TYPE, JKL,  DELAY, and  RATE)
can  now be abbreviated to their first character. Also, two new bits have been
assigned in the KFLAG$ memory storage location.  Bit  6, if  set to  "1", sets
the Extended Cursor Mode. Bit 5, if set to "1", sets the CAPS LOCK mode.

KSM/FLT  has a new parameter, ENTER=. This will allow you to set any character
to be used as an embedded <ENTER>. The default remains  the  semicolon. ENTER=
may be followed by the ASCII value  of the character, or  may  be entered as a
character between quotes. For example, to set  a  colon  as the new character,
either ENTER=58 or ENTER=":"  will work.  This  parameter  may  be abbreviated
"E".

LBASIC PROGRAM CHANGES

LBASIC has a new parameter, EXT=ON/OFF. The default  is ON. EXT=ON means  that
LBASIC will use a default extension of /BAS  during LOAD, RUN, MERGE, and SAVE
operations.  File  OPEN  and  KILL  operations  will  never  use  the  default
extension.

The  RUN"filespec",V command will now  save any  fielded variables  used  with
random files.





                                  Page - 6



M O D E L   I I I   5 . 1 . 2   U P D A T E   N E W S
=====================================================

LSI is  proud  to  announce the release of  LDOS-512 for the Model  III. There
have  been many  enhancements  made in 5.1.2 over  5.1.0B. This section of the
newsletter will detail some of these enhancements.

NEW FILES

The following new files will be on your LDOS master disk:

   EQUATES3/EQU -  For  assembly language programmers.  This is an equate file
   for  use with an editor/assembler program,  in the format used by  the EDAS
   editor/assembler.  It  contains  the  labels  from the memory  map  in  the
   technical section.

   LSCRIPT/FIX  - An  enhanced Scripsit patch which makes use of LDOS's KI/DVR
   program and other keyboard features.

   VC/FIX - A patch file for Visicalc

   MOD3/DCT - A file used to set  default  values for floppy drives,  normally
   used along with hard drives.

LIBRARY COMMAND CHANGES

The DEVICE command will now show if VERIFY is on.

The DIR command  has  two  new parameters, SORT  and MOD. The normal directory
display will  be sorted in alphabetical  order. SORT=NO will disable the sort.
The MOD parameter will now show just those files with MOD flags.

The SYSTEM library command has 4 new parameters. They are:

   SYSTEM (DATE=ON/OFF) Enables or disables the DATE prompt when booting.
   SYSTEM (TIME=ON/OFF) Enables or disables the TIME prompt when booting.

   SYSTEM (BSTEP=n) Sets  the  default bootstrap step rate used by the  FORMAT
          utility.

   SYSTEM (DRIVE=,CYL=n)  Sets the  default cylinder count used  by the FORMAT
          utility for the specified drive.

UTILITY PROGRAM CHANGES

BACKUP  now allows you to cancel the QUERY parameter during a backup. Pressing
<C> in response to the prompt  will cause the backup to continue non-stop from
the current file.

FORMAT uses different defaults  if the QUERY=N  parameter  is specified, or if
the <ENTER> key is  pressed in  response to a  prompt. All  prompts, including
NAME and  PASSWORD,  may  be  defaulted. There is also a new parameter, WAIT=.
This parameter was  added to make up  for  deficiencies  in  certain 80  track
drives, and is NOT normally needed.




                                  Page - 7



The LCOMM utility has  had several changes and additions. The XLATE  parameter
has been changed to  allow a  send  character to be translated  to some  other
character.  Likewise,  a  receive  character  may be  translated  to any other
character. Also, the <7> key has now been assigned the following function:

DTD ... <CLR><7>

   The (DTD) Dump To Disk is used to  write the memory buffer used with FR  to
   the  disk. DTD  may be turned on  before or after a file has been received.
   If turned  on before,  the  file will  be  written to disk as  it  is being
   received.

   The  menu display  will  be different,  and  will show  which  devices  and
   functions are active,  as well  as  the amount of available memory, and the
   functions currently active.

The DCC  (Display Control Characters) function has been added,  and will force
a  display of any character received that has a value less than an  X'20' as a
two  digit hexadecimal number surrounded by braces. Also, a  CLS  (Clear Local
Screen)  function has been added,  and  will erase the contents of  the screen
without transmitting any character to the communications line.


DRIVER/FILTER PROGRAM CHANGES

KI/DVR has been  significantly  changed.  All 128  ASCII  characters are  now
available  from the keyboard, and  an  "Extended  Cursor Mode" has been added.
Two  new  parameters, DELAY= and  RATE=, have been added. DELAY is used to set
the initial delay between  pressing a key and the first  repeat.  RATE is used
to  set the  key repeat rate. All of the  KI parameters (TYPE, JKL, DELAY, and
RATE) can now be abbreviated to their first character.

KSM/FLT has a new parameter, ENTER=. This will allow you to set any  character
to be used as an embedded <ENTER>.

MiniDOS/FLT has a new key available. The <P> key will  allow you to send a hex
character directly to the lineprinter.

PR/FLT has the new  parameter SLINE. This may be  used to establish either the
Model I or Model III default for the initial line count.


LBASIC PROGRAM CHANGES

LBASIC has a new parameter, EXT=ON/OFF.  If this parameter is specified as on,
LBASIC will use a default extension of /BAS during LOAD, RUN, MERGE,  and SAVE
operations.

The RUN"filespec",V  command will  now save any  fielded  variables used  with
random files.

The CMD"N" will now renumber ERL= lines.






                                   Page - 8



                                  WHAT'S NEW ?

New from MIDWEST  DATA SYSTEMS  is a package called AUTO-WRITER. It is  a data
management  package that  allows you to use your word processor  to create and
maintain your data base. AUTO-WRITER consists  of 5  programs. STATS gives the
status of a data file,  telling things such as the location  and length of the
fields,  the  format  of  the   data  base,  and  will  even  show  errors  or
inconsistencLes. SELECT lets  you  construct  new files from  your  data base,
based  on  "Plain-English"  truth  statements.  SORT  sorts  in  ascending  or
descending order, and by user specified key. LETTERS  and REPORT generate form
letters  and reports based  on  user  design.  AUTO-WRITER  is  available  for
$72.83.

As  this  newsletter goes to press, the  finishing touches  are  being put  on
AUTO-WRITER +. Enhancements  to  the basic package will include  a  two  level
sort,  a math pack, a new input editor, and  more.  AUTO WRITER + is available
for $120.00,  with a  special update price  available  for current AUTO-WRITER
owners. For  more  information, contact MIDWEST DATA SYSTEMS, 5624 Girard Ave.
South, Minneapolis, MN 55419  (612) 866-9022

From  LYNN  COMPUTER  SERVICE  is  a  product called LYNN'S  A/R,  an accounts
receivable  package.  This  package consists  of 12 integrated programs. It is
available  for  $49.95 + $2.00 S&H, from LYNN COMPUTER SERVICE, 6831 W. 157th,
Tinley Park, IL 60477  (312)  429-1915. Documentation and sample printouts are
available separately for $10.00.

SPEAK! is a program which "adds lips" to your TRS-80 Model III. It  requires a
cassette recorder and mic, and a small  amplifier. Words or phrases are spoken
and learned by  the  program  for later  access  by  other  programs. For more
information contact Bill Neville,  PO  Box 2581, Houston,  TX  77001,  or  Lee
Perryman, P0 Box 2972, Tampa, FL  33601.

From MISOSYS is a new product  called SOLE.  This utility  will  allow  double
density  booting on the  Model I,  Radio Shack E.I. It is available for $25.00
from MISOSYS, PO Box 4848, Alexandria, VA  22303-0848  (703) 960-2998.

Also  from MISOSYS is a program called CON80Z. This program converts assembler
source  files  in  Intel 8080  mnemonic code to Zilog Z80  mnemonic code.  The
output is EDAS/EDTASM compatible. The price is $50.00 + $3.00 S&H.

There is a  HELP utility and  a quick  reference  card available from MISOSYS.
The package  sells  for $25.00, and the reference card is available separately
for $3.00.

See Tim Daneliuk's  review of the JOHNSON ASSOCIATES  software package  in his
column.

From SOFT SECTOR MARKETING comes THE  COMPLETE IDIOT'S BOOKKEEPER. This  is  a
bookkeeping package for  personal or  small business use.  The  package  comes
with programs to provide indexes, edit the  data files, build separate monthly
files, remove deleted entries, etc. This program  was tested with both 5.0 and
5.1 LDOS, and is available for Model I and  III. For more information, contact
Soft  Sector  Marketing,  6250  Middlebelt,  Garden  City,  MI   48135   (313)
425-4020.




                                  Page - 9



The  SNAPP  EXTENDED  BASIC packages should be available for the Model  III at
this time. These packages  provide enhanced  cross reference and  renumbering,
keyword  and  string  cross reference,  variable  dump,  program  compress and
uncompress, "college educated"  garbage collector, and more.  For information,
contact SNAPP Inc., 3719 Mantell, Cincinatti, Ohio  45236  (800) 543-4628.

Available from GALACTIC SOFTWARE  is a manual  on  LBASIC. This  is  a 50 page
manual, and explains all of the disk Basic  statements that are available with
LBASIC.  Although  not a  tutorial  on  Basic  programming,  examples  of most
statements  are included. Also, all LBASIC extensions to normal disk Basic are
explained.  The  manual sells for $9.95 plus $2.05 S&H, and is available  from
Galactic Software,  Ltd, 11520 N. Port Washington Rd, Mequon, WI  53092  (414)
241-8030.

Also  available from  GALACTIC SOFTWARE is the  MemDISK program. This  program
creates  a simulated  disk  drive  in memory.  All  disk  I/O functions  work,
including backup and  copy. The memory  disk  can  even be switched to drive 0
with the SYSTEM command. It is available for $39.00.

Available from ALCOR SYSTEMS is a version of the PASCAL  language. The  manual
includes a reference and a tutorial section.  For further information, contact
ALCOR  SYSTEMS,  13534  Preston  Rd.,  Suite  365,  Dallas,  TX  75240   (214)
226-4476.

As  we went to  press, we had many more software  companies  who  had received
copies  of LDOS and  were checking on full compatibility  with LDOS.  The next
Quarterly should list all of these packages.


                          ITEMS OF GENERAL INTEREST

On the Model III, our USTOR$ pointer is at X'4DFE'.  This points to an 8  byte
storage  area available to the  user. TRSDOS has  its user pointer at X'4CFE'.
If  you are using Radio Shack  programs that use  this area, you should change
the address accordingly.

When using  the 5.1.1 or later LCOMM Utility to  download files, the DTD (Dump
To Disk)  function is turned OFF  when the receive file is reset. If you are
downloading more than one file  and want the DTD to remain on all the time, be
sure  to  do  a DTD  ON <CLR><7><CLR><:>  before turning  on  each  successive
receive file.

New Compuserve  users have requested instructions on getting to the LDOS board
on MicroNET. Simply type in:

   R LDOS

from the OK prompt of Compuserve.

There has been a new RAM STORAGE ASSIGNMENT  designated  for both  the Model I
and  III.  It  is  DAY$,  and  is used  in  conjunction  with  DATE$  to store
information about  the  current  system  date.  The  new  assignments  are  as
follows. The Model III descriptions will match those of the Model I.





                                  Page 10



Model I
DATE$=X'4044'-X'4046'
+0...Contains the two digit year
+1...Contains the day of the month
+2...Contains the month

DAY$=X'4047'-X'4048'
+0...Contains bits 0-7 of the day of the year
+1...
     bit 0........Contains bit 8 of the day of the year
     bits 1-3.....Contains the day of the week (Sunday=0)
     bits 4-6.....Reserved
     bit 7........Set to "1" if leap year


Model III
DATE$=X'421A'-X'421C'
DAY$=X'4417'-X'4418'

The  SPOOL command for the 5.1.2 version has had two  visible changes made.
First, if  KI/DVR is not established, the SPOOL command  will abort with an
appropriate  error  message. Secondly, the system  will  no longer allow  a
SYSGEN if the spooler is active.

"How can  you  switch  between  upper  or  lower  case  without  making the
operator press the <SHIFT><0>?" "How can you force keyboard  input to be in
either upper  or lower case?" These  questions from our users resulted in a
change to the  KI/DVR program for the 5.1.2 update.  The  location known as
KFLAG$ (X'4423' or 17443  on the  Mod I, X'429F' or 17055  on  the Mod III)
now has bit 5  designated as the CAPS LOCK bit. If the bit is set, you will
be in the CAPS LOCK mode. Therefore,  a BASIC program  on the  Model I  can
switch  into  upper  case   only   by  POKEing  the  KFLAG$  location  with
PEEK(&H4423) OR 32, and switch to upper/lower by POKEing the  location with
PEEK(&H4423)   AND  223.  Model  III  would  use   the  same  method   with
PEEK(&H429F). Using the  PEEK  command and  the  logical OR or  AND assures
that any other bits in the KFLAG$ location will remain untouched.

When your disk drive takes  a nap . . . . and then resumes 15 to 30 seconds
later,  chances are it was bitten by  the 300  RPM  bug. During normal disk
I/O, the  only  time  the interrupts  are disabled is  when the  system  is
actually going to  transfer  a  256 byte  sector  to or from the disk. This
makes possible interrupt driven features  such as type ahead, the  spooler,
and  LCOMM.  However,  since the  interrupt clock rate is evenly  divisible
into  a  disk rotation  speed  of  300  RPM,  it  also  can  provide  those
mysterious naps from time  to time when  an  interrupt  occurs just as  the
physical I/O  is going to happen. The solution  is  simple; change the disk
speed to  302 RPM. This will  assure that the  interrupt and  disk rotation
will be out of sync without degrading disk I/O performance.

When using the LSCRIPT  patch to Scripsit, you can still  duplicate most of
the  original  Scripsit  key controls  by  using  the  <CTRL><key> sequence
(<CTRL> being <SHIFT><DOWN ARROW>).  For instance,  <CTRL><S>  puts you  in
the insert mode, <CTRL><V> forces a page marker, etc.





                                  Page - 11



The following procedure can be  used  to simulate turning on and off a link
between the video  and the printer  from within an  LBASIC program. At  the
LDOS Ready prompt, type in  the commands  ROUTE *DU (NIL) and then LINK *DO
*DU. In the LBASIC program,  use a CMD"ROUTE *DU *PR" to link the  video to
the printer, and a CMD"RESET *DU" to turn off the link. This procedure  may
be repeated as often as desired.

Once again, it's time to mention the data  address  mark.  For those of you
who need them, use  the  following patches to force LDOS to  write the  old
DAM. These are for the Model I, Radio Shack E.I., VERSION 5.1.2 ONLY!

.SYS0 patch
X'467C'=A9
.EOP

.PDUBL patch
X'5472'=A9
.EOP


                     TCHRON - Time and Date board Patch

. TCHRON/FIX 03/09/82, ROBERT J. NEWTON
. PATCH SYS0/SYS.SYSTEM USING TCHRON
. This patch is for the Model I TCHRON time & date board
. and is for LDOS Version 5.1.x ONLY! It has been supplied
. by an LDOS user and is unsupported by LSI.
. Note: Parts of this patch have been derived from the
. TTIMER fix listed in the last issue of the QUARTERLY
. and copyrighted by Roy Soltoff
.
. It is recommended that you convert this to a DIRECT
. patch using FED before applying it to SYS0. This is
. to ensure that no additional space is taken up by the fix.
X'45C1'=D1 45 ED 78 0D A4 CD A5 47 ED 78 0D 85 12 1B C9
X'45D1'=11 43 40 01 75 03 60 CD C3 45 10 FB
X'4E97'=21 44 40 E5 01 7C 0F CD B9 4E 23 23 CD B9 4E 2B
X'4EA7'=06 03 CD B9 4E 21 B9 50 DB 78 CB 57 28 01 34 D1
X'4EB7'=18 21 ED 78 0D A0 07 57 07 07 82 57 ED 78 0D 82
X'4EC7'=77 C9 00 00 00 00 00 00 00 00 00 00 00 00 00 00
X'4ED7'=00 00 00
. End of patch


                          Updated TTIMER Patches

There were  a couple of  bugs  that inadvertently slipped  into two of  the
TTIMER  patches  in the last issue. The underlined  bytes in  the following
patches  indicate  the  areas  of  change.  The "xx"  in  the  5.1.1  patch
indicates that the original "13" byte should be removed from the patch.

. TTIMER Model I Version 5.0.2 & 5.0.3 patch
. Copyright (C) 1981 by Roy Soltoff, All rights reserved
. PATCH SYS0/SYS.WOLVES




                                  Page - 12



   D04,65=D8 45 ED 78 0D CD A1 47 ED 78 0D E6 0F 85 12 1B
   D04,75=C9 11 43 40 01 C5 03 CD C9 45 10 FB
   D0D,C0=21 46 40 01 CA 01 CD AA 4E 06 03 CD AA 4E 01 CC
   D0D,D0=0F CD AA 4E EB 13 DB CB E6 03 21 92 50 20 01 34
   D0D,E0=18 34 ED 78 0D A0 07 57 07 07 82 57 ED 78 0D E6
   D0D,F0=0F 82 77 2B C9
   . end of patch


   . TTIMER Model I Version 5.1.1 patch
   . Copyright (C) 1981 by Roy Soltoff, All rights reserved
   . PATCH SYS0/SYS.SYSTEM
   D04,05=D2 45 ED 78 0D CD A6 47 ED 78 0D E6 0F 85 12 1B
   D04,15=C9 11 43 40 01 C5 03 CD C3 45 10 FB
   D0D,4E=21 46 40 01 CA 01 CD B8 4E 06 03 CD B8 4E 01 CC
   D0D,5E=0F CD B8 4E EB xx DB CB E6 03 21 B9 50 20 01 34
   D0D,6D=18 21 ED 78 0D A0 07 57 07 07 82 57 ED 78 0D E6
   D0D,7D=0F 82 77 2B C9
   . end of patch

   FILTER PACKAGE NEWS

   The LDOS Filter  Package was released in January.  Since then, some changes
   have been made  to the disk. The source code  for  all of the programs  now
   comes on the  disk, and  is also available  for  those of you who purchased
   the original package.  This will be  a free update.  Also, for those of you
   who  have  the filter package  with dates  earlier than  2/20/82, apply the
   following patch to CALC/FLT.

   .CALCA/FIX
   . fixes problem with bad entry message display
   D00,ED=0B 54 00 00 1F 0A 43 41 4C 43 2D
   .EOP

   This should stop problems when an incorrect entry is made.


                           HIGH MEMORY AND LDOS

     The question  of high memory  usage  comes up  time and  time again  when
talking about LDOS and application program compatibility. There also  seems to
be  some  confusion regarding  when  LDOS  uses high  memory.  To  make things
perfectly  clear,  remember  the  following  two  points, and  then  read  the
explanation.

   1) LDOS high memory usage is done  in a  totally  relocatable manner. There
   should always be a way to avoid conflict with applications programs.

   2) LDOS never uses high memory when booted without special configuration.

Avoiding memory conflicts

     A memory conflict occurs when two programs or modules  want to occupy the
same memory locations. Since LDOS provides many  advanced  features, it  needs
to store the code for these features somewhere in memory.



                                  Page - 13



It does this in the following manner:

   1) Find the first  available high memory address by  looking  at the  value
   stored in the HIGH$ location.

   2) Install the necessary code in memory below the current HIGH$ value.

   3) Lower the HIGH$ value to protect the new code.

     Any  code that LDOS stores in  high memory is written to  be relocatable.
This means that it can  load anywhere  in  memory, and is not  restricted to a
specific area.  Since LDOS always  respects  the HIGH$  value,  it  will never
attempt to overlay any  programs loaded and protected  by changing  the  HIGH$
value in  this manner. Now, if  all other applications  programs  did the same
thing when installing code in high memory, there would  obviously never be any
memory conflict.

      Unfortunately, TRSDOS and some of  the other operating  systems  do  not
respect the  HIGH$ value. As  a result,  programs or  BASIC USR  routines that
load in high memory  are not  generally  written in a relocatable manner. They
have a fixed load address, and MUST be  loaded there to execute properly. This
means  that they  will overlay any  existing LDOS code  that  happens to be in
those  memory  locations.  When  the LDOS  code  is  something like the KI/DVR
program, this usually results in an immediate system crash.

     To  resolve a memory conflict, you need only to know the load address and
length of the unrelocatable code. We will  consider two  cases - when the code
loads at the very top of memory, and when it loads at some other point.

     When the conflicting code  loads at the very top of  memory,  it is  very
easy to resolve the problem.  Since you know the load address of the code, use
the MEMORY library command to change the  HIGH$  value to  one byte below that
address. For example,  if a piece of code loads from address X'F900' and  goes
to  the top of memory, you would issue  a MEMORY (HIGH=X'F8FF') command.  LDOS
will  now put any of its own high  memory  code  below X'F900', protecting the
module that will load there. You may want  to use  the SYSTEM (SYSGEN) command
to keep this area permanently protected.

     When the conflicting code  does not load  at the top of  memory, you  can
use the same method  just  described  to protect  it. However, this will waste
any  memory between the  end  of  the  program and  the top of  memory.  Let's
consider the  case where  a module loads  at  X'F200'  and extends to X'F3FF'.
There is 3K of  space between the end of the module and  the top of memory. To
avoid wasting this space, use the following procedure.

   1) Load  an LDOS  module  into  high  memory (i.e.,  SET  KI/DVR, install a
   filter, etc).

   2) Type in the command MEMORY  with no parameters to see the current  HIGH$
   value.

   3) If the HIGH$ value is above X'F3FF', repeat  steps 1 and 2. If the value
   has  gone  below X'F3FF', you will need to start over,  stopping before you
   load the module that caused the HIGH$ value to go below X'F3FF'.



                                  Page - 14



   4) Now, issue a  MEMORY (HIGH=X'F1FF') command. This will protect the block
   of memory that will be needed by the unrelocatable module.

   5) Continue to load any other LDOS modules as desired.

     You may now  use  the  SYSTEM (SYSGEN) command  to  permanently save this
configuration with its protected block of memory.


                   CMD"O" - Implementation and Possible uses

In many Basic application programs, there exists a  need to sort the data used
by  the program. There have been many different methods used  and explained in
the  past  to reach such a  goal.  This article will  explain another possible
sorting process inherent in LBASIC, namely the CMD"O" command.

The CMD"O" sorting  routine allows you to  sort information which is contained
in a single  dimension  array, and  can only  be used  with strings.  The only
constraint  on the amount of  information  that can be sorted is determined by
the  amount  of memory available.  Realize that sufficient string  space  will
need to  be allocated  for the data via  the CLEAR statement. The  syntax used
for the CMD"O" command is:

     CMD"O",number of elements to sort, first element of array to sort

You will note there are 2 parameters  that need  to  be specified when issuing
the CMD"O" command. The  first parameter  is  the  number  of elements  in the
array  that  you  wish  to be  sorted. This parameter may  be  specified as  a
numeric constant or a numeric expression.

The second parameter is the array  that you  wish the sort to be performed on,
and the  element number  of the  array  where  the  sort is  to  begin. It  is
specified as  the  array name and  a  subscript. The  subscript number may  be
specified as a numeric constant or a numeric expression.

Before  we  say  anything  more  about  the  CMD"O"  command,  an  example  of
implementing it is in order.


   Example

   Suppose  you have the string  array  A$  dimensioned to  have  6  positions
   (0-5), and the following assignments have been made to the array:

   A$(0)="ZEKE"     A$(1)="HANK"     A$(2)="BOB"
   A$(3)="GABE"     A$(4)="CLIFF"    A$(5)="DON"

   The  following sort commands  will have  these  affects  on  the  A$ array,
   assuming that the above assignments have been  made  to  the array prior to
   invoking each sort command.


   CMD"O",6,A$(0)





                                  Page - 15



   A$(0)="BOB"      A$(1)="CLIFF"    A$(2)="DON"
   A$(3)="GABE"     A$(4)="HANK"     A$(5)="ZEKE"
   -----------------------------------------------


   A%=6:B%=0:CMD"O",A%,A$(B%)

   Same results as previous example
   -----------------------------------------------


   CMD"O",3,A$(2)
   A$(0)="ZEKE"     A$(1)="HANK"     A$(2)="BOB"
   A$(3)="CLIFF"    A$(4)="GABE"     A$(5)="DON"
   -----------------------------------------------


Please note  that whenever  using  the CMD"O"  function,  the sort  cannot  be
performed beyond  the last  element of  the array. For  instance,  in the last
example, if the sort  were  still  to  begin  with array position  2, the most
elements that could  be  specified to be included in the  sort  would  be four
(specifying  a  number greater  than  four would  force  the  sort  beyond the
highest subscript of the array).

It  can  be seen  that  the CMD"O"  function  provides  a  convenient  way  of
performing a sort on a  string array in ram.  But what happens if  you wish to
create an alphabetic index file  using the sorted array? In many applications,
if  a  sort is performed in  ram on an  array,  the subscript number  of  each
element  usually represents some  type of  index  information  (e.g. a  record
number in a random file), and is  generally kept with each item throughout the
sorting process. As it stands, the CMD"O" function will not  allow you to keep
track of  an  item's subscript number throughout the  duration  of the sorting
process.

However,  there  are  several  alternatives available  which  can  be  used in
conjunction with  CMD"O"  to  maintain  an  alphabetic  index  file.  One such
alternative  is to add a two  byte string  onto the end of  each string in the
array.  This two byte string  would  be a compressed integer  representing the
index  number  associated with the  data element (perhaps the array postion of
the element prior to the sort).

The following example will illustrate  how to create  an index file using  the
CMD"O" command.


   Example

   Suppose  you have a  random file  (MYFILE/DAT)  which  contains  an unknown
   amount  of   25  byte  records,  and  you  wish   to  sort   these  records
   alphabetically, creating an index  file  of  sorted  position according  to
   record number.  The following routine will illustrate one way of doing this
   using CMD"O".





                                  Page - 16



   OPEN"R",1,"MYFILE/DAT",25:FIELD1,25 AS D$
   A%=LOF(1):DIM S$(A%)
   FOR L=1 TO A%:GET 1,L:S$(L)=D$+MKI$(L):NEXTL
   CMD"O",A%,S$(1)
   OPEN"R",2,"MYINDEX",2: FIELD2,2 AS E$
   FOR L=1 TO A%:LSET E$=RIGHT$(S$(L),2):PUT 2,L:NEXT L:CLOSE

   After  the above  lines have  been executed,  the random file MYINDEX  will
   have  been  created,  and  will  contain  2  byte  records  representing an
   alphabetic index  (by  record  number)  of  the  file MYFILE/DAT  stored as
   compressed integers..


                                PARITY = ODD

     Since this is  the  first  installation  of  what will  hopefully be a
regular  feature,  I thought it  would  be  appropriate to  introduce  both
myself and this column.  I am by profession an electrical  engineer, and by
avocation a writer.   You may have chanced  upon some of my product reviews
and articles in  BYTE  and  INFOWORLD (I  love to drop names!).  My purpose
here is twofold:

      1) To review products of particular merit with an
         emphasis on their compatibility with LDOS.

      2) To serve as a forum for the burning issues of
         the day which relate to LDOS.

I  am interested in any and all reader feedback.  If there is a  particular
piece  of software you would like to see covered or a topic  which needs to
be discussed please drop me a line or leave a message on MNET.

      Tentatively  scheduled  (very tentatively!) is  a review  of  several
spelling  checkers,  and  a review  of some recent statistical software for
the TRS-80.

      By no means is this  column limited to  reviews, however.   From time
to  time  I'll  delve  into  the  mysterious  world  of  Assembly  Language
programming (to  the great  delight  of  all  you experts  out  there)  and
perhaps explore the hidden  secrets of the LDOS JCL.  The day may even come
when a reader contribution  will be seen in these hallowed  lines: provided
you readers start contributing!

      One final  word  is  in  order regarding  the  product  reviews.   My
responsibility is  first  to  you  the  readers.  I  have  been told by the
moguls who  publish  this journal, that  advertising  in no  way influences
what I can or  can't say about a product.  If  its good I'll say so, if its
not, I'll say that too, hopefully with a coherent reason why.

      For  those  of  you  who wish to make yourselves  heard,  I  herewith
provide the necessary information:

             Tim Daneliuk
             4927 N. Rockwell St.
             Chicago, IL  60625
             MNET# 70745,1520



                                  Page - 17



Now, onward and upward to today's exciting feature


PRODUCT OVERVIEW
NAME: DATAENTR 200 and ISAM 200
MANUFACTURER: Johnson Associates Software
              Box 1402
              Redding, CA  96099
              916-221-0740

PRICE:  $80.00 for  DATAENTR 200,  $90.00  for  ISAM 200  (in  BASIC),  and
$140.00 for ISAM 200 (in machine language).

DOCUMENTATION: Approximately 20 pages for DATAENTR 200 and
               15 pages for ISAM 200

HARDWARE: TRS-80 Model I, II, or III, and CP/M systems.

INTRODUCTION

     DATAENTR 200 and ISAM  200 are two packages  which represent a growing
trend  in  software  development.   These  programs  are  not  applications
programs in themselves, but rather are a set of subroutines designed  to be
integrated  into  a  larger  package.   Using this software,  it  might  be
possible to create  a  mailing  list  program, or a generalized  data  base
manager for example.  They are both  available  written  in BASIC, and ISAM
200 is  optionally  available  in  machine  language  where  optimum  speed
performance is essential.

DATAENTR200 - FEATURES

     This   set  of  sub-routines   provides  a  convenient   way  for  the
applications programmer to develop keyboard entry programs.  This  not only
simplifies  the  programming  process, but  also  forces  a bit  of program
structure  by  separating   the  input  routines  from   the  computational
routines.

     The heart of this  input process is a data entry screen.  This  is the
screen  which the  final user of the program sees as he or she enters data.
In creating this  screen the programmer  defines the data field  names  and
lengths.  When the end  user actually enters the data  for these fields, it
is  returned  as  elements  in  a   string  array  via  the  DATAENTR   200
subroutines.  According to the manual, this  program gives the applications
programmer eight principal features to integrate into his or her code:

     1) Load the screen from disk and hold it in memory.
     2) Display the memory stored data entry form.
     3) Provide full cursor and data entry control for
        1 to 30 fields.
     4) Provide verification and correction services for
        the data entry forms.
     5) Provide keyboard controlled Menu selection.
     6) Display data within the data entry form.
     7) Clear screen data fields.
     8) Provide single field correction.




                                  Page - 18



These features are implemented in three distinct sets of programs.

     The  first  of  these  programs  is  a  set  of  run-time  data  entry
subroutines. These  routines  read a screen  from disk, display the screen,
set up  menu selections, input data  (with optional checking  of the fields
as they  are entered), display data,  prompt the user to verify and correct
data, clear data fields, and  correct individual fields.  The documentation
describes each sub-routine individually, giving the variables  that must be
set before the  routine is called,  a description of  what  the  subroutine
does, and a short example.

     The second program  consists  of run-time utility sub-routines.  These
provide  time delay, blinking message, date/time strings,  Y or  N response
checking,  packing  and unpacking of fields, a moving  sign  board  message
display, and a  dated program  listing with both time and date  stamps.  As
with  the previous  routines, each sub-routine  is individually documented.
These  two sets  of  programs  are  actually both contained in the  program
DATAENTR, but may be separated to save space.

     The third program is a screen creation utility  called UTSCREEN.  This
program  allows  screens  to  be  created, examined,  modified, stored, and
printed.  In creating the screen both the normal keyboard  set and graphics
characters (except on some  CP/M systems) are  permitted   The utility also
has features  like  line drawing and  enclosing  screens in  video "boxes".
The major  feature of  this screen utility is the  ability  to define field
checking at  the time  the screen is created.  This provides  for  run-time
checking of data  entered into each field.  For example, it  is possible to
check if all the characters entered are alphabetic.

DATAENTR 200 - EVALUATION

     By  it's  very  nature,  this  program  cannot  be  rated  on  overall
performance.  Those routines which  I  experimented with  performed exactly
as  indicated in the documentation.  The  UTSCREEN  screen utility has  one
major failing in that  it is insufficiently error-trapped.  Several times I
inadvertently keyed in an incorrect key  sequence and was rewarded  with an
LBASIC  error message which bombed the program and destroyed that session's
screen  editing.  UTSCREEN also has a  problem  in naming  the  files which
store the screen configurations.  The programmer  is prompted for  the file
name  (the  extension  /SCR is  automatically  appended),  but  one  cannot
specify  which  drive to save the file  on!  To use the  program  I  had to
write-protect  my  system disk (which is always full), to force the  system
to write  the  screen  file to  drive 1.   Since  I keep a  JCL  procedures
library on the system drive,  it became very cumbersome  to have  to remove
the write protection every time I  wanted  to  compile  and  execute  a JCL
procedure.

     The  documentation  is  generally  adequate  but  a  bit  terse.   One
excellent feature  of  the  documentation  is  a  set  of  six step-by-step
lessons which demonstrate the use and application of DATAENTR 200.

ISAM 200 - FEATURES

     As  with  the program above,  this  program  is a  set of  subroutines
designed  to  be  implemented  in  a  larger  package  by  the applications
programmer.



                                  Page - 19



These  sub-routines  are  available  written  in either  BASIC  or  machine
language.  As  a  whole, this  set  of  routines  implement  ISAM  (Indexed
Sequential  Access   Method)   file  handling   within   a  BASIC  program.
Specifically,   the  following   seven   file   handling   procedures   are
implemented:

     1) Open the ISAM file.
     2) Get a specific record.
     3) Update an existing record.
     4) Put a new record into the file.
     5) Delete an existing record.
     6) Get the next record in sequence.
     7) Get the first record in the file.

The various file attributes like  field  lengths, field names,  and  record
blocking (LRL) are stored  within the file itself.  When an  ISAM  file  is
opened, the ISAM 200 routines  read these attributes and  adjust themselves
accordingly.

     Several other programs are also included which  assist in creation and
maintenance of ISAM files.   The INIT program  is used to create a new file
and write the file  attributes  to be used later.  ISAMPRNT lists a file to
either the printer  or the screen.   REORG is  used to  reorganize  a  file
which has had many insertions and deletions.  The  program removes  deleted
records, and re-sequences the file to optimize run-time file handling.

     As with DATAENTR 200, each  sub-routine  in  ISAM  200 is individually
documented with complete information  regarding  variable  setting, general
description   of  routine,   error  return   codes,  and  short   examples.
Information is also supplied which discusses  how ISAM 200 uses memory, and
how to use multiple sort keys with the routines.

ISAM 200 - EVALUATION

     This  program can only be considered  to be minimally  compatible with
the LDOS  operating system.  To  begin with,  the machine language routines
which I  evaluated were not fully relocatable, though 32K and  48K versions
were provided on the  master diskette.  Worse yet was  the fact that  these
programs did not  set the HIGH$ memory pointer to protect themselves.  This
makes running any LDOS high memory options  impossible  unless one manually
sets the memory pointer each time ISAM 200 is loaded.

     Operationally, the routines seem to work well.  A  sample mailing list
program is provided to demonstrate the power of the  ISAM routines,  and it
does so  convincingly.  In general, the experienced BASIC programmer should
have  minimal  difficulty  implementing  ISAM  200  in  very  sophisticated
applications if the problems mentioned above are circumvented.

SUMMARY

     Neither of  these  programs  are  for  the  novice.   Both  have  good
potential applications, but some expertise on the part  of the applications
programmer is mandatory.






                                  Page 20



     PRODUCT REVIEW :
     S B T (Structured Basic Translator)
          written by Gene Bellinger
          published and produced by Acorn Software Products, Inc.
          $49.00

     Reviewed by  S. L. Ratkowski, Milwaukee, Wisconsin

     Structured  Programming is the  magic  buzzword in  programming  circles.
Everyone  'knows' that BASIC is  a poor language to  program  in because it is
not 'structured'.   In actual practice,  it is possible  to  write  structured
programs in  BASIC,  but  it takes a  little more  thought on the programmer's
part than is required in a truly structured language such as Pascal.

     Acorn Software has  a  new utility  that  is intended to make  structured
programming a little easier for the BASIC programmer -- they call it SBT,  for
Structured  Basic  Translator.   SBT  is  a  line  oriented   translator  that
understands only three type of lines:

   1)  STRUCTURE ELEMENTS.

            All  of  the  SBT   structure   elements  begin  with  the     '%'
character. The allowable elements are:

          %PROC - this is  the  PROCedure label.   Think  of a Procedure  as a
subroutine. All programs are made up of one or more procedures.

          %CALL -- this is used to CALL a PROCedure.

          %WHILE --  One of  the three  allowed loop  structures.  A  DO-WHILE
loop is  used  in a situation  where you may not want  the body of the loop to
execute even once,  since the test for the exit  condition  is done before the
body of the loop is executed.

          %UNTIL --   This loop structure is used  whenever  you want the body
of  the loop to execute at least once,  no matter what.  The exit test is done
after the body of the loop is executed.
     (The third loop structure is simply the BASIC  FOR ... NEXT loop.)

          %IF  --   Combined  with  the  next   two  structures,  allows   the
construction of several forms of the IF-ThEN-ELSE structure.

          %ELSE and

          %ELSEIF -- Used  with  %IF to construct statements  of  the  IF-THEN
ELSE variety.  They allow very versatile uses.

          %ON  --  This  is used to create the  CASE-CALL,  which  performs  a
conditional call of  one of several procedures, depending on the value of it's
argument.  It translates to  the BASIC sequence ON ...  GOSUB ...

          %ON ERROR  -- Used to code error handling routines of  the  ON ERROR
GOTO ..  type.  The programmer must  be  careful using this, as  the  last %ON
ERROR block encountered is the one that controls when the error occurs.



                                  Page - 21



'RESUME linenumber' cannot  be used because SBT  source  code  has no numbered
lines.

          %END -- This statement is simply a marker  to delineate the end of a
%PROC, %UNTIL, %WHILE, %IF, and %ON ERROR.

   2)    COMMENTS  --  A comment  in an SBT source  program  is any line  that
begins with a non-alphabetic character other than  '%'.   This type of line is
ignored during  processing.  If you want to include  REMarks to be included in
the  final BASIC  program, include them in  the source  by beginning  the line
with 'REM'.  You  may  not  use the abbreviation "  ' ", since SBT  takes this
line as a comment line not to be processed into the object program.

   3)   BASIC STATEMENTS -- Any line which is  not a structure element, and is
not  a  comment  is ASSUMED  to  be  a  VALID BASIC statement,  and  is passed
directly to the object program.  SBT does NO checking  on the validity of such
statements,  and this can cause  some  rather  interesting  crashes  when  you
include comment  lines not  preceded  by  non-alpha  characters, or  incorrect
BASIC statements.

     To use  SBT, you use  the  primitive text editor supplied on the disk, or
any  word processor capable  of producing an ASCII file, to write the 'source'
code of the program. This 'source'  file must have the extension 'SBS'. I used
SCRIPSIT to produce the following:

     (Any lines that  have '<--- ' in them are not in the source, but are used
to explain what is happening in that program line.)
     (The first 5 lines are examples of COMMENT lines.)
(*------------------------------------------------------
(*    EXAMPLE OF PROGRAM WRITTEN USING  S B T
(*    --->> Structured Basic Translator <<---
(*        by Acorn Software Products, Inc.
(*------------------------------------------------------
CLEAR 1000  <--- This is a plain BASIC statement
%CALL INIT   <---  I am calling the Procedure named INIT
%UNTIL CHOICE = 0
   %CALL MENU  <--- Calling the Procedure named MENU
   %CALL INPUT <--- Calling the Procedure named INPUT
   %ON  (CHOICE)  CALL ENTER,EDIT,PRINT,FILE  <--- Depending  on your  choice,
this will call one of the 4 Procedures.
%END UNTIL
PRINT SML$   <---  This is a pure BASIC statement.
END   <---  So is this.
(*-----------------------------------------------
(*    PROCEDURE  INIT  -- SHOWS USE OF
(*    CONDITIONALS TO SET UP CONSTANTS FOR
(*    EITHER MODEL I/III OR MODEL II USAGE.
(*-----------------------------------------------
%PROC INIT <--- This is the Procedure Label.

<---  The  next  11  lines are all  BASIC  statements.   I can use  this as  a
general   purpose  menu  routine  just   by  changing  these  lines  for  each
application I have.





                                  Page - 22



   DIM DT$(100)
   N=5
   DIM MN$(N)
   MN$(1)= "1) Enter Data"
   MN$(2)= "2) Edit Data"
   MN$(3)= "3) Print Data"
   MN$(4)= "4) File Data to Disk"
   MN$(5)= "5) End Program"
   M$= "Enter your choice..."
   M2$="MENU OF OPTIONS"
   E$= "Invalid Input.  Please re-enter..."


<---   The following  lines are  examples of  CONDITIONAL  TRANSLATION. When I
execute the Translator, I  can  set  SWITCHES that will tell the translator to
include  some lines but not others.  I work on a Model  III at home, and use a
Model II at the office.  I would love to be able to write programs  that would
run on both.  By using this feature of SBT, I can.

    All of the lines below that  begin with '$M2$' will only be translated if
I set the proper  switch at  translation time.   If  I specify  NO switches at
translation time, none  of these statements  will be translated, as  they will
be taken to be comments by SBT.

<---  Model II constants

   $M2$ SML$= CHR$(30)   (*  CLS AND SET TO 80 CHAR MODE *)
   $M2$ BIG$= CHR$(31)   (*  CLS AND SET TO 40 CHAR MODE *)
   $M2$ ROW = 24          (*  24 LINES ON CRT *)
   $M2$ COL = 80          (*  80 CHAR LINES *)

<---  Model I/III constants

   $M13$SML$= CHR$(28) + CHR$(31)  (*CLS & SET TO 64 CHAR MODE *)
   $M13$BIG$= CHR$(28) + CHR$(31) + CHR$(23) (* CLS & SET TO 32 CHR MODE *)
   $M13$ROW = 16          (*16 LINES ON CRT *)
   $M13$COL = 64          (*64 CHAR LINES *)
%END PROC (INIT)


     Once  you have created your source  file and saved  it  as  an ASCII file
with the  extension '/SBS',  you go  into BASIC and run SBT.  Under LDOS 5.1.2
on the Model III, the procedure goes as follows:
LDOS Ready

LBASIC RUN"SBT/"


LBASlC - Version 5.1.2 - 03/01/82
(C)  1981 by Logical Systems Incorporated


                        SBT - Structured Basic Translator
                              Ver # 3.1 18-Jan-81




                                  Page - 23



F1x> EXAMPL/$M13$ <--  The program prompts you for the file name of the source
code.  The extension '/SBS' is assumed.


$F$EXAMPL/$M13$
   00100  -  INIT   <--- As  SBT  processes  the  source,  it  shows  you  the
subroutines it is setting up from the PROCs in your program.

   00200 - MENU
   00300 - INPUT
   00400 - ENTER
   00500 - EDIT
   00600 - PRINT
   00700 - FILE
READY

     At this  point, you can LOAD  and RUN the object  program, which is saved
on  the  disk  as an  ASCII program with the extension '/BAS'.  Notice  that I
used  the switches to  tell SBT to only translate  the Model  I/III constants,
not the  Model  II constants.  I include both the source code  of  the program
(FIGURE  1) and the resulting  BASIC  program (FIGURE 2) as an example of what
SBT can do.

       The translation of this program  took  2 minutes  and 16  seconds.  The
writing of the source took me  about an hour and a half, starting from scratch
with the manual in hand.   It took three  tries before I cleaned out the goofs
caused by reading the manual too quickly.

     The program is easy to use, but is not for the beginning programmer.   If
you make a mistake  in the syntax the translator is  looking for, you can wind
up with a  BASIC program that does not make sense.  You must have a  feel  for
what should come out  of  the translator to  figure out what you  did wrong in
the source.

      I  like  structured  programing, but  it  sometimes  requires  too  much
planning when  I program in BASIC.  The SBT is  definitely a  tool that  would
help  me write  more structured  programs.  The documentation is good, and the
examples will help you over the rough spots.

     This product comes on  a 35 track single density TRSDOS diskette that can
be booted on  a Model  I, or  CONVERTed by a Model III.  The instructions  for
use  are included in a small format, 25 page booklet  that includes all of the
allowed syntax of the translator and  examples of  their usage.  In  addition,
the disk  includes three source programs, and the  translated object code that
SBT produces. Interestingly enough, one of the examples is SBT itself.

     One other note is that  the source program for SBT includes  the switches
$TRS$,  $CPM$, and $I$.   To  run  on the  TRS-80,  it  must  be translated as
SBT/$TRS$/$I$.   If you wish  to translate it to run with Microsoft BASIC 4.51
under CP/M vers. 2.2, use  the switches SBT/$CPM$/$I$. If you with to  run  it
under Microsoft BASIC vers. 5.2, use SBT/$CPM$.







                                  Page - 24




============================
     FIGURE1
============================

(*------------------------------------------------------
(*    EXAMPLE OF PROGRAM WRITTEN USING  S B T
(*    --->> Structured Basic Translator <<---
(*        by Acorn Software Products, Inc.
(*------------------------------------------------------
CLEAR 1000
%CALL INIT
%UNTIL CHOICE = 0
   %CALL MENU
   %CALL INPUT
   %ON (CHOICE) CALL ENTER,EDIT,PRINT,FILE
%END UNTIL
PRINT SML$
END
(*-----------------------------------------------
(*    PROCEDURE  INIT  -- SHOWS USE OF
(*    CONDITIONALS TO SET UP CONSTANTS FOR
(*    EITHER MODEL I/III OR MODEL II USAGE.
(*-----------------------------------------------
%PROC INIT
   DIM DT$(100)
   N=5
   DIM MN$(N)
   MN$(1) = "1)   Enter Data"
   MN$(2) = "2)   Edit Data"
   MN$(3) = "3)   Print Data"
   MN$(4) = "4)   File Data to Disk"
   MN$(5) = "5)   End Program"
   M$= "Enter your choice..."
   M2$="MENU OF OPTIONS"
   E$= "Invalid Input.  Please re-enter..."
   $M2$ SML$= CHR$(30)   (*  CLS AND SET TO 80 CHAR MODE *)
   $M2$ BIG$= CHR$(31)   (*  CLS AND SET TO 40 CHAR MODE *)
   $M2$ ROW = 24          (*  24 LINES ON CRT *)
   $M2$ COL = 80          (* 80 CHAR LINES *)
   $M13$SML$= CHR$(28) + CHR$(31)  (*CLS & SET TO 64 CHAR MODE *)
   $M13$BIG$= CHR$(28) + CHR$(31) + CHR$(23) (* CLS & SET TO 32 CHAR MODE *)
   $M13$ROW = 16          (* 16 LINES ON CRT *)
   $M13$COL = 64          (*64 CHAR LINES *)
%END PROC (INIT)
(*-----------------------------------------------
(*    PROCEDURE MENU  --  DISPLAY MENU
(*-----------------------------------------------
%PROC MENU
   PRINT BIG$
   L = ((COL/2)- LEN(M2$))/2
   PRINT TAB(L) M2$
   PRINT
   X=1
   %UNTIL X > N
      PRINT MN$(X)



                                  Page - 25



      X=X+1
   %END UNTIL
%END PROC
(*-----------------------------------------------
(*   PROCEDURE INPUT  --  GET CHOICE
(*-----------------------------------------------
%PROC INPUT
   SCR = (ROW - 1) * COL
   PRINT
   %UNTIL VAL(A$)>0 AND VAL(A$)<6
      L = ((COL/2)- LEN(M$))/2
      PRINT TAB(L) M$
      %UNTIL A$<> ""
         A$= INKEY$
      %END UNTIL
      %IF VAL(A$)<1 OR VAL(A$)>5
         PRINT @ SCR, E$
      %END IF
   %END UNTIL
   CHOICE = VAL(A$)
   %IF CHOICE = N
      CHOICE = 0
   %END IF
%END PROC
(*-----------------------------------------------
(*   PROCEDURE ENTER  -- GET DATA FROM KB
(*-----------------------------------------------
%PROC ENTER
   PRINT SML$
   PRINT "DUMMY ENTER ROUTINE"
   INPUT"HIT 'ENTER' TO CONTINUE";A$
%END PROC
(*-----------------------------------------------
(*   PROCEDURE EDIT  --  EDIT DATA
(*-----------------------------------------------
%PROC EDIT
   PRINT SML$
   PRINT "DUMMY EDIT ROUTINE"
   INPUT"HIT 'ENTER' TO CONTINUE";A$
%END PROC
(*-----------------------------------------------
(*    PROCEDURE  PRINT  -- PRINT DATA
(*-----------------------------------------------
%PROC PRINT
   PRINT SML$
   PRINT "DUMMY PRINT ROUTINE"
   INPUT"HIT 'ENTER' TO CONTINUE";A$
%END PROC
(*-----------------------------------------------
(*    PROCEDURE   FILE  --  FILE DATA
(*-----------------------------------------------
%PROC FILE
   PRINT SML$
   PRINT "DUMMY FILE ROUTINE"
   INPUT"HIT 'ENTER' TO CONTINUE";A$



                                  Page - 26



%END PROC


============================
     FIGURE  2
============================

1 CLEAR 1000
2 GOSUB 100
3 GOSUB 200
4 GOSUB 300
5 ON((CHOICE))GOSUB 400,500,600,700
6 IF NOT(CHOICE = 0) THEN 3
7 PRINT SML$
8 END
100 DIM DT$(100)
101 N=5
102 DIM MN$(N)
103 MN$(1) = "1)   Enter Data"
104 MN$(2) = "2)   Edit Data"
105 MN$(3) = "3)   Print Data"
106 MN$(4) = "4)   File Data to Disk"
107 MN$(5) = "5)   End Program"
108 M$= "Enter your choice...
109 M2$="MENU OF OPTIONS"
110 E$= "Invalid Input. Re-enter..."
111 SML$= CHR$(28) + CHR$(31)
112 BIG$= CHR$(28) + CHR$(31) + CHR$(23)
113 ROW = 16
114 COL = 64
115 RETURN
200 PRINT BIG$
201 L = ((COL/2)- LEN(M2$))/2
202 PRINT TAB(L) M2$
203 PRINT
204 X = 1
205 PRINT MN$(x)
206 X = X + 1
207 IF NOT(X > N) THEN 205
208 RETURN
300 SCR = (ROW - 1) * COL
301 PRINT
302 L = ((COL/2)- LEN(M$))/2
303 PRINT TAB(L) M$
304 A$= INKEY$
305 IF NOT(A$<> "") THEN 304
306 IF NOT(VAL(A$)<1 OR VAL(A$)>5) THEN 308
307 PRINT @ SCR, E$
308 IF NOT(VAL(A$)>0 AND VAL(A$)<6) THEN 302
309 CHOICE = VAL(A$)
310 IF NOT(CHOICE = N) THEN RETURN
311 CHOICE = 0
312 RETURN
400 PRINT SML$
40l PRINT "DUMMY ENTER ROUTINE"
402 INPUT"HIT 'ENTER' TO CONTINUE";A$



                                  Page - 27



403 RETURN
500 PRINT SML$
501 PRINT "DUMMY EDIT ROUTINE"
502 INPUT"HIT 'ENTER' TO CONTINUE";A$
503 RETURN
600 PRINT SML$
601 PRINT "DUMMY PRINT ROUTINE"
602 INPUT"HIT 'ENTER' TO CONTINUE";.A$
603 RETURN
700 PRINT SML$
70l PRINT "DUMMY FILE ROUTINE"
702 INPUT"HIT 'ENTER' TO CONTINUE";A$
703 RETURN


                         THE LIBRARY by Earle Robinson

The library found on  your LDOS disk is a  continuation  of the  system  begun
under the first versions of  TRSDOS. You may have frequently wondered what  it
is and what  is its  use. The library was created in order to provide the user
with  a number of utility  programs of relatively short length so as to occupy
a minimum  amount of disk space. Note that  I said these are programs  because
that  is what they are. It would be  possible for  each and every  one  of the
library programs to  be on your disk  as /CMD files. You  could easily extract
these routines  and create /CMD files on your disk. You would, however, have a
much more encumbered disk, using over double the space  and occupying  some 33
file spaces.

The library was created in order to save  space on the disk. Remember that the
Model I  disk drive system relied  on  35  track  diskettes in single density.
Model I TRSDOS  has far fewer programs than  does LDOS, but  the library, even
in that rather bare bones operating system, saved enormous  space on the disk.
Under LDOS, if the 33  different library  programs were individually stored as
programs on the disk, they would occupy  at least 165 sectors or 17 tracks (if
a double  density disk, 198 sectors,  or 11 tracks). You can  appreciate  that
such  a disk would not  leave much spare  space. Also, not to be forgotten  is
the  maximum number of permitted files on  a single density disk,  48 (*1). If
the library were  split into files,  the  available  number of files would  be
reduced to only 15!  The library in  fact concentrates the 33 library programs
into a space of 88 sectors. How is this done?

Each program file on a disk uses a minimum  of one gran of  a disk (5  sectors
in  single  density  or 6 sectors under double density). Many  of  the library
routines are quite  short, occupying  1 or 2 sectors.  If  they were stored as
files,  each would  be allocated at least 1 gran  of space though using only a
sector or two.  The library packs these routines into 2 separate system files,
SYS6 and SYS7. Two files are  used due to the huge  size  of the library which
would  make a single one  impractical. In addition, the use  of a  second file
permits  allocating space  between each  of them  based on their importance in
day  to day use.  (Single drive users of LDOS can  easily run most of the time
with a system disk without SYS7 being present). Not  only does the packing  of
the library  programs  economize  disk  space, but it permits double  or  even
triple use  of the same code  for certain routines  such  as  COPY and APPEND.
This is  accomplished  by  using  different entry points  to  the same routine
where much of the same code is used by different routines. CONT. Page 37



                                  Page - 28


[Next several pages are advertisements... sorry, but they just don't work too
well as ASCII text.]



The method used is described in Roy Soltoff's description  of his new program,
PDS, which stands for  Partitioned Data Sets, published  in  the last issue of
the LDOS Quarterly.

Due to the construction of the library, it is impossible  to SYSRES  it as can
be done with the other  overlays. In any case, the very long length of SYS6 in
particular swallows  far too much of your RAM. It is possible, however, to put
individual  routines  into  a  /CMD file.  The  choice  would  depend on  your
activity.  For example, if you are doing a  great deal  of copying  of  files,
then the creation of a command file of the COPY routine might be envisaged.

For  those who are  interested  I shall briefly  describe how the  library  is
accessed. Let  us assume that you wish to display the directory. You will type
in DIR (plus any parameters  required) and hit  the  <ENTER> key.  That action
will start the long (in number of bytes,  but short in time) interpretation of
this command at the address 4405  hex.  The  accumulator (the A register) will
be loaded with the value of B3 hex and a RST 28 (*2) will follow.







                                  Page - 37



That  will put you down at the address of  28 hex in  the ROM where there is a
jump instruction to another address in RAM  at 400C  hex (*3)   From there the
B3 value  in  the  accumulator  will lead to  SYS1 being loaded (*4),  and DIR
being  parsed,  matching this library command  with the list located in  SYS1.
Once the name DIR is found,  the index values  following it will be extracted.
These are 21 hex and 80 hex.  The latter tells the system that the DIR routine
is in SYS6 (if it had  been SYS7 the value would have been C0 hex). The former
value is the index for DIR, located in SYS6.

Another RST28, this time  with the value  of 88 hex  in  the accumulator, will
load the first sector of SYS6 where  the indices for the  programs therein are
examined  until 21 hex  is located. SYS6 (and  SYS7  too)  contain each of the
indices for the library routines at the beginning  of the  file. Each index is
followed by the relative load address for  the routine, its entry  point,  and
the  relative address for loading of  the  code used  to run the routine. Note
that this method avoids  loading  the  complete library file in order to reach
the routine desired.  This speeds things up a great deal over the method  used
by  TRSDOS  which loads the complete library, and also permits limiting use of
memory  to the area between  5200H and 6FFFH. In fact,  most routines use much
less space.

The LDOS  library  files have also been  optimized in  so far as is practical.
Based  on feedback from  users, and on LSI's own experience, the routines most
frequently  used are placed earlier in  the library in order to  reduce access
time. In the same  way, the split between SYS6 and SYS7 was made in such a way
so that the most frequently accessed  routines  are  in SYS6. It is frequently
asked  why TRACE is a library routine since it is rarely used and  is not very
practical. Since TRACE  is  a  TRSDOS library routine, LSI included it in SYS7
in order  to  maintain  the  upward compatibility which  is  one  of the  most
important features of LDOS.

                                 Footnotes

   (*1)  In fact, a single density disk has space for 64 files, 8 sectors of 8
   files  each. However,  16 of these are reserved for  system  files. Only 14
   are  used at present, including  BOOT  and DIR). On  a double density disk,
   there are 112 files (after deduction of the 16 system slots allocated).

   (*2) RST is  an assembler instruction called  a restart of which  there are
   six for  the TRS80.  The number  is  the hex  value where  the processor is
   sent. One  advantage  of a restart instruction is that it uses only byte of
   instructions  versus  3 bytes for a normal jump command  The  RST28 is used
   to tell the system which overlay is to be loaded into memory.

   (*3) It  is frequently  asked why the instruction at 400C is merely  a jump
   to another vector. Why not jump immediately  to the  second  vector?  There
   are  two reasons  for  this.  First  of  all,  it  is impossible  to modify
   instructions   in   ROM.   Secondly,  LDOS  strives   to  maintain   upward
   compatibility with TRSDOS  and maintains all 'standard' vector values. This
   means that there are frequently jumps to a  second (or even a third) vector
   where execution begins.

   (*4) The system subtracts 2 from  the value to determine the overlay number
   to be  loaded; the upper  4 bits  of the byte tell the system which part of
   the  overlay to  go to.  In  this case, B3  tells  the system  that SYS1 is
   required, and that the  command  is  to be  parsed.  The  value of 93, also
   calling SYS1, would have led to the "LDOS Ready" message.



                                  Page - 38



               INSIDE THE EXPANSION INTERFACE by Earle Robinson

Model  I  LDOS  users  occasionally  encounter  problems  with  the  Expansion
Interface. As a very  non-hardware oriented person myself,  I have encountered
my  full share of these and will discuss them  in the  following remarks. Some
of my  own  experiences  and problems may  help others  in recognizing what is
happening (or often,  what  is not  happening),  and  more easily overcome  or
resolve things like silent death, re-boots, and data write errors.

The  first annoyance encountered by Mod I users  with the  Expansion Interface
is that of  what  is called 'Silent  Death'.  The screen display  freezes, and
nothing can be entered  from  the  keyboard.  Although one may be  tempted  to
throw the whole computer out the window, a more practical solution  is to push
the Reset  button. Silent death happens most frequently  during  disk I/O, and
can  be  very frustrating if  a file or a program  is lost. The  source of the
problem is within the Expansion Interface,  and  is called  time-out. There is
insufficient delay accorded to the Seek command  due to a too small capacitor,
(thanks to Tandy, which in its infinite  wisdom, did not wish to be accused of
over-engineering  their  products.)   This capacitor  will  be  replaced  upon
demand at your local  RS  computer  center. However, if  you prefer,  and  are
hardware oriented, you may do it yourself.

Unwanted  reboots  usually happen while in the  midst  of  completing  a  most
arduous task,  running, writing or debugging  a program.  They  also typically
occur very late in  the evening, when you don't have a backup of the file,  so
that  it is lost. The one positive aspect of  such  a calamity occurring after
Midnight is that your  loved ones will already  be  asleep  and therefore less
likely to be in immediate danger of  the overwhelming wrath which  will  seize
you.  The usual reason for  these  re-boots  is defective  memory above HIGH$.
LDOS  uses that area  for  drivers  and  devices constantly.  Even one bad bit
somewhere in that memory  can be  disasterous. Fortunately, memory chips  have
now  become quite cheap, usually around $16  per set of 8. Replace that memory
immediately!  Nine times out of ten this will solve the problem.

The final disaster that  we'll  cover is  that  of data read or  write errors.
Localizing this problem  successfully is much more difficult. The usual causes
are: 1)  a  defective  disk  controller chip (WD-1771); 2)  oxidization of the
connector busses 3)  bad diskettes  4) disk  drives  out  of alignment. Tandy,
with its scrupulous concern to  avoid  being  accused  of over-engineering its
products  bought the series -01 of the controller chip  from the manufacturer,
Western  Digital.  This series  might  be called  less  charitably, "seconds".
Since  Tandy also avoided installing a so-called data separator in the system,
the problem with  the  controller  chip frequently only becomes evident when a
user  installs  a  separator  or  a double-density  board  (which  also has  a
data-separator). When I installed my double-density  board,  at  first I could
only successfully write in  double-density and not in single density. Clearly,
my  double-density controller was O.K. but not  the old single one. I replaced
it with a series -02, and that was that.

Another cause  of  data  errors can be  the  connections between  the keyboard
unit, the interface and the disk drives.  The  connector bus on  your keyboard
and  those on  the interface were coated with tin, which oxidizes, rather than
gold, which doesn't.




                                  Page - 39



Though cleaning with  a pencil eraser (the  so-called  pink  pearl  treatment)
will  provide  temporary relief, it  will  also  eventually, if  repeated  too
often, remove the tin.  The best solution  is to  get  the connectors replated
with silver or gold or solder another connector,  a gold one  to the original.
Note that Tandy  didn't wish to  encourage gold bugs when designing  the Model
III either, and also repugned gold connectors on that model.

Use of poor quality diskettes is a frequent  cause  of  data errors, clobbered
directories, and  other dire  problems. Use  first rate  diskettes always. LSI
(and  this writer)  prefer  Scotch. Many of my friends condemn Memorex. I know
those who swear by  Verbatims,  and others who  swear  at them.  Dysans have a
Rolls Royce reputation... .and a similar price, not really  all that justified.
For some  time  I also used Verbatims until I found that the coating seemed to
wear off  (especially those used with 80 double density  tracks).  If you only
operate under single  density, then the choice of diskettes is,  I  might add,
somewhat less critical.

The  final  cause of data errors  is frequently misaligned disk  drives.  This
source of problems is usually  left  as the last resort since it usually costs
a minimum of $35 to  get a drive  re-aligned. It is usually recommended that a
drive be serviced at  least once each  six  months. However, it really depends
on how much use  the  drive  gets,  the  manufacturer.....and luck. I have two
drives from the same manufacturer. The first one has been in service for  over
2  1/2  years  and  has never been re-aligned. The second one required service
after only 5 months of service.  I do recommend, however, that a small fan  be
placed so as to aerate the power supplies of  disk  drives  for  two  reasons.
First of  all, heat build up  will cause more wear. More  important still, the
speed of a drive will vary  widely between the time it is turned  on and  when
it gets warm.  Naturally, cleaning the head  of the drive occasionally is also
highly recommended to remove  oxidized matter. This can be done with a special
diskette kit  available  from  most  dealers including  Radio Shack stores. Be
careful,  however. The head is actually NOT  on  the side  from which the door
closes, but the opposite side. This is  not explained in the  documentation of
the drive  cleaning kits  and many people have destroyed  the pressure  pad by
applying  the wet  cleaning  side of the diskette  against  the  pressure  pad
rather than the head itself!

Finally, a  number of  people complain that they have  more  disk I/O problems
with LDOS than with  brand  X  operating systems. They forget that LDOS offers
type-ahead,  the  most  accurate system clock and  a  reasonably good software
based  spooler.  None  of  the other systems  can equal these  features  which
disable interrupts  much  earlier  during  disk I/O,  which eliminates use  of
type-ahead and the spooler at that time.


             AN ARTICLE by Charlie Butler of The Alternate Source

Per Bill's request,  I am going  to editorialize; carte blanche, one  page, he
says. Thanks for nothing pal. Your turn is coming. Let's talk about


Changing Operating Systems Mid(bit?)stream -- Should you do it?






                                  Page - 40



     Remember  the day you first got  disk?  After getting  the cables figured
out and  determining which way the write-protect notch  went  you were  on the
way. Your first goal was to  learn the  operating system. You probably started
with  DIR, LIB and FREE, but it would be months  (and  seem like years) before
you were up to the  heavies like APPEND and ATTRIB. And now, it's beginning to
make sense. Most of it, anyway. Wasn't it all fun?

     Quite  frankly,  it was a pain in the butt. Learning a new DOS slows down
productivity. You don't  have  enough  time to do  everything now,  much  less
fight  with  a  new  set of  commands  and  the  compatibility  problems  that
invariably pop up. Why spend weeks of frustration learning a new DOS?

     Try this:  Get  your most important data  file. It could be a program you
just spent many hours writing or your customer master list. From BASIC, type

OPEN,"O",1,"filename"<ENTER>

Now say to yourself, "Oh, that's my very important file."  Then type

CLOSE<ENTER>

     Depending on which  DOS  you're using, your file will either be OK, or it
will be a null file (a file that contains no information). A close  inspection
of the directory will reveal that  all directory extension pointers have  been
reset and the file contains no sectors. Recovery will take hours.

     Combine  this  problem with a  library of  wierd acronyms, disrespect for
active drivers when chaining and general incompatibilities in BASIC.

     For  example, the BASIC "MERGE" and "LOAD" commands. TRSDOS allows you to
write  BASlC  statements  in ASCII  to a file in any  order and  corrects that
order  when  LOADing  or  MERGEing  the  program. (Many  of  the  new "program
generators"  or  programs that write other programs use this principle.)   For
illustration, study the following program:

10 OPEN"O",1,"TEST:0"
20 PRINT#1,"20 PRINT I"
30 PRINT#1,'10 FOR I = 1 TO 10"
40 PRINT#1,"30 NEXT I"
50 CLOSE

Run this  program, then  RUN"TEST" with  your operating  system. If  only  one
number  prints on the screen, the program  lines from the  file  TEST were not
merged properly.

     True, the best  laid  plans go  astray, but  I  (the  programmer)  have a
choice  of  which  operating  systems I  will  support. In  order  to  stay in
business, I must support TRSDOS, but any other system must prove its worth.

     The above  examples are only a  couple of the reasons  why I have started
using LDOS  for my programming projects. I don't have to worry about the above
problems.  But  that's  not  all.  What  about other  "bugs"  I  discover?   I
frequently hear customer  complaints about  the frequency  of  updates  coming
from  Wisconsin ("Do you have the  2 pm or the  4 pm version?"). You should be
applauding.



                                  Page - 41



Updates mean  someone  is  listening  to  complaints and  at  least trying  to
correct problems. Most of the updates you probably  don't need, anyhow. It  is
nice to know they are there, if you do.

     Lest  you think I  am trying  to hard-sell LDOS, I  am  not.  It is not a
cure-all for DOS problems (and  they ALL have  them). Just  looking  at  their
manual shows you they have made a  remarkable effort) but it still falls short
of "ideal."  It is not indexed to suit me and  it  doesn't include enough user
examples.  Still, for my applications) LDOS is the best product on the market.
It is also the best documented DOS on the market.

     Should you  hassle  with another  operating system?  Maybe.  If  you  are
having  problems like mine (above), definitely. I  don't envy you;  just  make
sure the DOS you're learning is worthwhile.

                            Roy's Technical Corner

     This is the fourth in my regular  series  of articles  on LDOS  technical
subjects. The first explained the  Data Address  Mark convention used in LDOS.
The second detailed the functions of the @PARAM vector and  how  you  can ease
the   development   of   your   assembly   language  programming  efforts   by
incorporating @PARAM to parse command  line  parameters. The third dealt  with
device  independence  and  its  implementation  on  the   Models  I  and  III.
Commencing  with  this issue,  my  series  has  been  named, "Roy's  Technical
Corner" - and you thought RTC meant Real Time Clock, ha!

     One  of the many  interesting things  unique  to LDOS  amongst  the  many
TRS-80 DOSes  is our  extensive use of distinct  record types in load modules.
Load modules, you say? What's  a load module? Let's set the record straight on
this  one  and  clear  up  some  of  the  semantics  concerning  load  modules
(according to Pete Barbutti, semantics is the study of salmon and ticks}.

     A load  module is simply a file that contains information  on where it is
to load into  memory.  It is usually loaded by the SYSTEM loader. If it can be
directly  executed as a program, it then becomes known  as  an executable load
module (ELM). The usual term that has been applied  to such a  file is  "CMD".
That's because a directly executable load module  is thought  of as a command.
We further use  the  default file  extension  of  /CMD for these command files
(ever wonder where Command File Utility got its name?).

     Another  problem of semantics arises when we consider the  output of  the
DUMP library command. The default file extension  used is /CIM, short for core
image. This has been an unfortunate specification because the core  image dump
is constructed  exactly like  a load  module   it,  in fact, IS a load  module
file.  The  term core-image, assumed originally  coined under  TRSDOS by Randy
Cook, does in fact mean executable  load modules  on main  frame computers. It
is  generally  NOT  the case with  the  TRS-80,  although it  can be.  I  have
problems with the use of  the  CIM extension, in light of the extensive use of
CMD as  a directly  executable module. Perhaps we shall change the default  in
DUMP to something more meaningful.

     Let's  get back  to  the issue at hand. A  load  module has been  said to
include certain "loading" information  pertinent to a loader routine. This  is
in contrast to a data  file,  a BASIC program, an ASSEMBLER source  file, etc.
which contain  no such information. Think of the load  module as a sequence of



                                  Page - 42



RECORDS. Note that  I did not  say an ordered  sequence. Thus, the implication
is that the records  do not have to be in an ascending order (contiguous  load
addresses). Each record  stands  by itself and can be dealt with by a  loader.
The records must  have some indicator as to what TYPE of record they are. This
TYPE code is used to denote a record as a HEADER, a TRANSFER ADDRESS,  an ISAM
DIRECTORY, a LOAD RECORD, or  other meaningful  structure. A record must  also
have a  LENGTH  which  is  the  length of the  data area  field.  Under TRS-80
operating systems, the length is constrained  to a  one-byte value and  can be
from 1-256  in value. The remaining part of the record is its DATA AREA and is
used  to  store program code,  directory  information,  messages, etc. I  have
identified  three different  fields of information for  the record; TYPE CODE,
LENGTH  BYTE, DATA AREA.  If  you are familiar with BASIC random access files,
you will see the similarity in the fielding of records - except  in this case,
we have variable length sequentially  accessed records  (with partitioned data
sets, we also have variable length indexed sequential accessed records).

     Let  me now build  a  table of record types used in  LDOS. After  that is
accomplished, I will then fill in the details where necessary.

          TYPE     DATA AREA
          ----     ---------
           01      object code (load block)
           02      transfer address
           04      end of partitioned data set member
           05      load module header
           06      partitioned data set header
           07      patch name header
           08      ISAM directory entry
           0A      end of ISAM directory
           0C      PDS directory entry
           0E      end of PDS directory
           10      yanked load block
           1F      copyright block

     Any code above X'1F' is invalid as a record type.  In addition, any  code
not listed in the above table is reserved for  future  use. For example, codes
11-18 are reserved for  relocatable code  module structures as defined in  the
LC implementation. As an  aside, Tandy uses  a  type code of  X'03' in lieu of
the transfer address type  code of X'02' to indicate a load module that is not
executable.

     Let's look at a sample file. Start by listing  the first sector of LBASIC
via LIST LBASIC/CMD.BASIC (H). Notice it starts out with:

           05 06 4C 42 41 53 49 43 1F 32 43 ...
            .  .  L  B  A  S  I  C  .  .  C ...

What you  have  here  is  a  load module  header (TYPE=05).  The  length  byte
(LENGTH=06) follows  the TYPE code. The 6-byte  DATA AREA field  is the header
name. ALL RECORDS FOLLOW THIS "FIELDING"  ORDER.  A record is organized with a
TYPE, LENGTH, DATA sequence.  The X'1F' begins  the second  record. Quick now,
what kind is  it?  It happens to be a copyright record with a  LENGTH of X'32'
or  50   decimal  bytes.  Incidentally,   the  TYPE=1F   record  is  generated
automatically by the "COM" pseudo-op in  EDAS, the  assembler used to maintain
LDOS.



                                  Page - 43



     Note  that each record  begins with  the  TYPE  code  and the first  byte
following the end  of a record is always the TYPE code of the next record. The
only exception is when a TYPE code  indicates  the end  of a file. If you look
further in the  record  displayed at  relative position X'3C', or if you count
50 bytes down from the "C" of "Copyright", you will see:

           01 A1 00 4E C3 8E 5B ...

     The record TYPE  is a load block (TYPE=01), and  the length  of  the data
area  is X'A1', or 161 data bytes. The two-byte  field following the LENGTH is
the starting load address for the rest of the field. This  is a  special case.
Since the LENGTH  value includes  the 2-byte load  address, a length  of x'03'
would indicate only one  load byte.  A length of x'04' would indicate two load
bytes.  A length of X'FF' would indicate 253 load  bytes. A  length  of  X'00'
would indicate 254 load bytes.  To be able to have a data  area with up to 256
bytes of loadable data, the LENGTH  values of x'01' and X'02'  are  indicative
of 255  and 256 load  bytes respectfully. This  is  accomplished by having the
system loader decrement the length value by  two when reading a  load address.
The resultant value becomes the true length of the loadable data.

     If you let  the BASIC  listing proceed to the end  of the file, the  last
four bytes should appear as:

           02 02 C9 52

This  will represent the TRANSFER  ADDRESS record  (TYPE=02). Again, we have a
LENGTH byte  which  shows a 2-byte  data  field.  The data field  contains the
transfer  address or  entry  point  to  the  program  in  standard  low-order,
high-order  sequence. Of  course, the  transfer address value  you will see is
dependent on which LBASIC you are listing.

     These are the four types you will  find in  other operating  systems. Now
it's time  to get down to the nitty gritty. List the  first record of SYS6/SYS
via  LIST SYS6/SYS.SYSTEM  (H) {note: if you are  not  using  5.1.1, then  the
password  to  use is WOLVES}. Look  at the area  just past the copyright.  You
will see something like this:

           08 06 1E 00 52 00 00 DB 08 06 21 ...

The TYPE code  of  X'08'  indicates an ISAM DIRECTORY  RECORD. The LENGTH byte
denotes a DATA area of  six bytes. After the sixth byte,  you will see another
TYPE=08 starting another ISAM directory record. SYS6 is a  partioned data set.
The TYPE=08 records are its directory.

     In LDOS, the directory  data area is used  by the SYSTEM loader to locate
where  a  particular member  can be  found  in the file. The data area has sub
fields as  follows. The first byte (1E) is the  ISAM entry number. This  value
is  provided  to the  SYSTEM  loader  by the SYS1 command line parsing routine
upon the discovery of a library command request.  The entry number is  the PDS
member that  will execute your request. The SYSTEM loader will  search the PDS
directory for a match. The next two-byte  sub-field is the transfer address of
the member. The transfer  address is  contained in the directory so  that more
than one transfer address can be  applied to a member (i.e. a member  can have
multiple entry points).




                                  Page - 44



The three-byte field remaining is the triad  pointer which points to the first
byte of  the  member. The triad pointer is composed of the Next  Record Number
(NRN) and Relative Byte  Offset  for the member's first byte. Consult the LDOS
Technical Reference Guide File Control Block section for  more information  on
these values.  Thus you have  six bytes  of data  as  specified  by the LENGTH
byte. In the PDS utility  offered by MISOSYS, the ISAM  directory record has a
length of nine because it  includes a three-byte  subfield  which contains the
TRUE length of the member.  That  piece of information  is  needed in many PDS
commands.

     While you are looking at the first sector of 5Y56, proceed  to the  first
byte following the last ISAM directory record. You will observe the sequence:

           0A 01 00 04 01 00 01 02 00 52 ...

The TYPE=0A indicates  that it  is the  end  of a  PDS  directory. The  SYSTEM
loader uses this  to discover that the requested ISAM entry  happens to not be
in the file being examined. If it gets to the TYPE=0A byte without  a match on
the ISAM number, the member is  not in the  directory. The LENGTH=01 is needed
because  ALL  load module records MUST  have  a  length byte.  The  DATA  area
contains only a single byte) X'00'   We cannot indicate  a null record because
a  length byte of X'00' indicates 256 data area  bytes. Thus) the X'0A' record
type must have a minimum of one byte in its data area.

     The  record  following  is a TYPE=04 to indicate the end of a PDS member.
This  record  serves  but  one purpose when  used  immediately  following  the
directory - it will  result in a  load file  format error  if  you  attempt to
execute  SYS6  or  SYS7  as if  they  were CMD files.  When  not  expecting  a
partitioned  data set  file) the SYSTEM  loader will ignore record types other
than X'01' and X'02' except for the X'04'.  The file reading will terminate at
the X'04' with the above-mentioned error message.

     The  record type X'04' is usually  used at the end of  a partitioned data
set member. If you list through SYS6, you will discover that  each member ends
with "04 01  00".  LDOS uses this code  in lieu  of the transfer address  code
because  the  SYSTEM loader  needs  to take  action different from that when a
standard load file has been completely  loaded. Also, the transfer address for
the member is stored in the ISAM directory itself.

     The next record type to discuss is that used in a  PDS  MEMBER DIRECTORY.
If you  have  purchased the PDS utility from MISOSYS, list it  in  hex. Notice
that it starts with X'06' in lieu of an X'05' which  is the normal header type
for a  load module. Well, PDS uses  the X'06' in certain PDS commands  to note
whether the target  file  is  a  partitioned  data  set  compatible  with  PDS
utilities. There  is a bit set in the LDOS system directory to indicate a file
is a PDS; however that is to be used in a future release of PDS.

     If you list past the front end loader, you will see the  start of the PDS
MEMBER DIRECTORY at relative 0001:14. It reads as follows:

           0C 0B 64 69 72 20 20 20 20 20 01 01 7A 0C ...
            .  .  d  i  r                 .  .  z  . ...

The  TYPE=0C  indicates  a  PDS  member  directory  record.  The  LENGTH  byte
specifies that the data area is an 11-byte field.



                                  Page - 45



The  DATA AREA  is  subfielded  as an  8-byte member  name (in lower  case), a
one-byte  ISAM  number that  is used  to  match  up with a  corresponding ISAM
directory record) and a  2-byte field of member data. The first byte uses  bit
position  7 to  indicate a  data  member  in  contrast  to an  executable  CMD
program. Bit  positions 4-6 are reserved for future use. Bits 0-3 and the next
byte contain the date that the  member was added to the PDS and is in a format
identical to  that  explained  as  DIR+1 and DIR+2  in  the  DIRECTORY  RECORD
section of the LDOS  Technical Reference manual.  As you look through  the PDS
member directory, you  will get to the "0E 01 00" record  which  indicates the
end of the MEMBER directory. The front end  loader  uses this to note  whether
the requested member is in the PDS. The ISAM directory follows.

     One last little one  to wrap up is the record types  associated  with the
PATCH  utility. When  you apply an  X-patch to a file, the  name of the  patch
file  is used as a header name with a  record type of X'07'. Thus, if you want
to YANK the patch, the PATCH program can read  through the file and search for
a like-named header. If a  matching header  is  found, PATCH will  proceed  as
follows. Since it  may be impossible to remove the  patch  without bubbling up
any code  blocks following the patch (another patch maybe?), PATCH will change
the  TYPE=01  records  to TYPE=10  records. The  TYPE=l0 records  will not  be
loaded by the SYSTEM  loader but  will be  considered as non  loadable comment
records.  It is  thus  possible  to "un-yank" a  yanked patch;  however,  this
feature is not implemented in the PATCH utility.

     There  we  have it,  the relatively complete  explanation for load module
format records. Send  in your requests for the  next issues's RTC column. Here
is where you  can  obtain detailed information  on  the  technical  aspects of
LDOS. Regards  until next time. By the way, this entire article  was  composed
using LED, the LDOS Text Editor, and the  latest in professional products from
Logical Systems, Inc. After all text  editing  was done  and a  print copy was
needed, LSCRIPT was used to print the document.

THE JCL CORNER by Chuck

This  month's  column  will  deal with a variety  of topics. The first  is the
announcement of two new JCL features available with the 5.1.2  update release.
JCL will now  flush the typeahead buffer before exiting. This means  that  all
<ENTERs> pressed  in response to a //PAUSE or other macro  will not be  passed
back to the system when the JCL terminates.

A  new compilation symbol, the  percent  sign  (%),  has been  designated  and
allows  passing values directly to  the system as  though  they came from  the
keyboard. The  values  should be  represented as hexadecimal digits.  Any  JCL
file using  the % symbol  must  be  compiled, or JCL  will  abort with a  "Bad
Format" error upon  encountering the line. Also, the character values  must be
those normally accepted by the @KEYIN ROM  routine. The following example will
clear the screen and print the comment line:

   %1F. This is a cleared screen comment

As you can see, the characters are inserted directly in  the line - symbol and
value,  symbol  and value, and then the period followed by the comment string.
DO NOT put them on a separate line  ending with a  carriage return.  Doing  so
will  clear the screen and then output the carriage return, generally aborting
the JCL. This same format holds true when % is used with execution macros.



                                  Page - 46



   %1F//pause press <ENTER> to continue
   %1F//flash 10 Starting up job stream

There are some limitations to the use of this  new symbol. It is  not possible
to pass values to the  MiniDOS or KSM filters using this new symbol.  However,
programs that  do utilize the @KEYIN call for keyboard input should be able to
respond to these characters.

There  were  three  compilation  macros that were  not discussed  in the  last
Quarterly; //. COMMENT, //QUIT,  and //INCLUDE. The first two are very easy to
understand. The //. COMMENT will allow  a message to be  displayed during  the
compile phase. Unlike an execution comment, the  compilation comment will  not
be written to the  SYSTEM/JCL file. One use for the  compilation comment is to
check logic statements as a JCL is compiling. For example:

   .TEST/JCL
   //if A
   //. A was true
   LBASIC RUN"TEST/BAS"
   //stop
   //else
   //. A was not true
   //end

Consider this JCL file as a piece of a large procedure. As  the file is  being
compiled, the  //. COMMENT  lines will  be displayed. Thus you  will  know the
status of this section of JCL logic before execution begins.

The  //QUIT macro is used, as its name would imply, to abort the JCL compiling
procedure.  It is primarily used when it is absolutely  necessary that certain
tokens be specified upon entering a JCL procedure. For example:

   .TEST1/JCL
   //if -s+-d
   //.    You MUST enter both S and D
   //quit
   //end
   backup :#s# :#d#
   //exit

The //if statement  (if not S or not d) tests to see  that both tokens s and d
have  a  logical  true  value.  If  not,  the comment  is  displayed  and  the
compilation aborts.  The end  result of aborting the  JCL procedure could also
be accomplished by using the //ABORT  execution  macro instead of the  //QUIT.
In that case,  however, the entire JCL file would be  compiled  first, and the
abort would actually come during the execution phase.

Before we discuss the //INCLUDE  macro in detail, one important point needs to
be stressed. An //INCLUDE  macro CANNOT  END  A  JCL FILE.  A  JCL file ending
with an //INCLUDE will produce a "Record number out of range" error.

The  //INCLUDE macro is used  to  select  other  JCL  files  from  disk  to be
included in the compilation of a JCL procedure. For example:





                                  Page - 47



   .TEST2/JCL
   //if X1
   //INCLUDE test3:0
   //else
   //INCLUDE test4:1
   //end

This example tests  the token X1. If  X1 is  true, the file TEST3/JCL  will be
read in from drive  0, and its contents compiled and written to the SYSTEM/JCL
file.   As  the  example shows,  the default extension for  included  files is
/JCL. If X1  is not true, the file TEST4/JCL:1 will  be  read in and compiled.
It is  not necessary to use the //INCLUDE  inside an //IF. An //INCLUDE can be
used anywhere in a JCL file.

//INCLUDE's can be  nested up to a level of 10 - that is, an  //INCLUDEd  file
can contain //INCLUDE statements. Refer  to the following example,  taken from
the 5.1.1 (or later) manual, page 5 - 8.

File #1 =>   //. NEST0/JCL
             . nested procedure example
             //INCLUDE nest1
             . this is the end of the primary JCL
             //EXIT

File #2 =>   //. NEST1/JCL
             . this is the first nest
             //INCLUDE nest2
             . this is the end of the first nest

File #3=>    //. NEST2/JCL
             . this is the second nest

The  above will  result  in a nest level  of two  (two pending //INCLUDEs). If
these  three JCL files  are saved as NEST0/JCL, NEST1/JCL, and  NEST2/JCL, and
the  NEST0/JCL  is  compiled and  executed, it  will  result  in the following
dialogue:

   //. NEST0/JCL
   //. NEST1/JCL
   //. NEST2/JCL
   . nested procedure example
   . this is the first nest
   . this is the second nest
   . this is the end of the first nest
   . this is the end of the primary JCL

The three compilation comments will be  shown  immediately  as the JCL file is
compiled.  When the compilation phase is  complete,  the  compiled  SYSTEM/JCL
file will  be executed.  In  this example,  the  execution  phase will  merely
display  a series of execution comments. As  you can see from the order of the
displayed comments, the  files are executed similarly to nested FOR-NEXT loops
in  BASIC. After all //INCLUDEs are detected, the innermost (last encountered)
//INCLUDE  file completes  execution first,  with  execution  proceeding  back
towards the original //INCLUDE.




                                  Page - 48



The //INCLUDE macro  can very easily be  used to compile a large JCL procedure
from  a series of  smaller JCL routines.  If the finished SYSTEM/JCL file is a
procedure that will be executed many times, it  may easily be saved by copying
SYSTEM/JCL to a file with another name.

Even after last issue's  column, there  have been  questions  about the proper
structuring of the //IF  and //END statements. The proper use of //IF requires
one  //END  for  each //IF. What  might not be readily  apparent  when nesting
//IF's is that the last //END corresponds to the 1st //IF. For example:

   First IF      //IF conditional #1             Line #1
                 first block of lines            Line #2
   Second IF     //IF conditional #2             Line #3
                 second block of lines           Line #4
                 //ELSE                          Line #5
   Third IF      //IF conditional #3             Line #6
                 third block of lines            Line #7
                 //END (ends third IF)           Line #8
                 //END (ends second IF)          Line #9
                 fourth block of lines           Line#10
                 //END (ends first IF)           Line#11

Evaluating this  example produces  the following results, When  the first //IF
is false, the entire block between the first //IF and its  corresponding //END
are not  compiled.  Thus, none of the lines in this example  would get written
to the SYSTEM/JCL file.

Assuming  from this  point on  that  the  first //IF  is true, evaluating  the
results of the second and third //IF's would produce the following.

When  the  second IF is true, Line  #4 would  be  written to  SYSTEM/JCL file.
Lines 5  through 8,  the //ELSE  conditional, would be ignored. Line #10 would
also be  written,  as it  comes after the //END statement corresponding to the
second //IF.

If  the second //IF was  false,  the third //IF  in  the //ELSE block would be
evaluated. If  it was true, Line  #7 would be written  to the SYSTEM/JCL file.
Whether or not this third //IF is true, Line #10 will be written out.

As  long  as  the first  //IF is true, Line #10 will always  be written to the
SYSTEM/JCL  file regardless of the logical evaluation of the second and  third
//IF  macros.  This  is because it comes  after the //END macros  for  both of
those //IFs. AlS,Q, you can  see that the first //END in Line #8 corresponds to
the third //IF in Line #6,  the second //END to the second //IF, and the third
//END to the first //IF.

Next  issue's  column  will  probably  deal  with  the  keyboard  macros,  and
interfacing  JCL with applications programs. If  you  readers have any subject
you  want  to see discussed  in The JCL Corner,  drop a letter in the  nearest
mail box, addressed to Customer Support, Attn: Chuck.

P.S.  The  CMDFILE  utility  can  be totally  controlled  by a  JCL  file. Try
creating a JCL,  the first line being CMDFILE, and the  next  lines being  the
proper responses for the CMDFILE prompts.




                                  Page - 49



                             PROGRAMS FROM USERS

This is a directory  mapping program  from  Bill  Fields. Besides  printing  a
directory map, it lists the files in alphabetical  order, along with the grans
they occupy.

20 REM GIVE BACK ANY STRING SPACE SO THAT MEM IS ACCURATE
40 CLEAR 0
60 REM I% IS A FACTOR REPRESENTING THE SPACE REQUIRED FOR ALL
80 REM NON-STRING VARIABLES AND STRING ARRAY OVERHEAD
100 REM IF OUT OF MEMORY THEN INCREASE I%. IF TOO MUCH
120 REM GARBAGE COLLECTION, THEN DECREASE I%.  THE SCREEN
140 REM WILL ALWAYS HAVE A CHANGING DISPLAY THAT INDICATES
160 REM (BY STOPPING) THAT GARBAGE COLLECTION IS IN PROGRESS.
180 I%=5300
200 CLEAR MEM-I%
220 REM ******************************************************
240 REM *                                                    *
260 REM * -----> DISK MAPPER FOR LDOS FORMATTED DISKS <----- *
280 REM *                   03/05/82 VERSION                 *
300 REM *            WRITTEN BY BILL FIELDS                  *
320 REM *                       POST OFFICE BOX 1120         *
340 REM *                       GLENDALE HEIGHTS,ILL 61037   *
360 REM *                                                    *
380 REM * NON-COPYWRITED CODE.  PUBLIC DOMAIN AS LONG AS     *
400 REM * AUTHOR'S NAME AND ADDRESS ARE NOT REMOVED OR       *
420 REM * ALTERED. NOT FOR SALE! THE AUTHOR WOULD WELCOME    *
440 REM * ANY IMPROVEMENTS OR ENHANCEMENTS TO EITHER         *
460 REM * PERFORMANCE OR FUNCTION. ALSO REPORT BUGS,PLEASE.  *
480 REM *                                                    *
500 REM * DIRECTORY STRUCTURE ALLOWS FOR EIGHT GRANULES PER  *
520 REM * CYLINDER (1-8) & 96 CYLINDERS PER DISKETTE (0-95). *
540 REM * IF THE DISKETTE IS DOUBLE DENSITY THEN EACH        *
560 REM * GRANULE IS SIX SECTORS AND IF IT IS SINGLE         *
580 REM * DENSITY EACH GRANULE IS FIVE SECTORS.  A SECTOR IS *
600 REM * ALWAYS 256 BYTES.                                  *
620 REM ******************************************************
640 REM FOLLOWING DIMENSION STATEMENT PUTS VARIABLES INTO
660 REM BASIC1S SYMBOL IN THE ORDER FROM MOST USED TO LEAST.
680 REM COMPUTING THE ORDER OF VARIABLES USE IS DONE BY FASTER
700 REM WHICH IS AVAILABLE FROM PROSOFT POST OFFICE BOX 839
720 REM NORTH HOLLYWOOD, CALIF 916$3
740     DIM    I%,T%,D%,J%,P%,SF%,W%,IK$,E%,DS$,PN$,G%,GC%,S%,Y8%,TC%,EE$,F1$,
Y9$,B4%,TX%,B7%,P1$,P2$,B0%,B1%,B2%,B3%,U%,Y1%,SP%,B5%,B6%,DN$,K1!,ZZ%,F2$
760 CLS
780 REM BIT MASKS FOR BIT0 THRU BIT7
800 B0%=&H01
820 B1%=&H02
840 B2%=&H04
860 B3%=&H08
880 B4%=&H10
900 BS%=&H20
920 B6%=&H40
940 B7%=&H80
960 PRINT @ 260,"LDOS FORMATTED DISK MAPPER"



                                  Page - 50



980 PRINT @835,"USE WHICH DRIVE?  ";
1000 FOR T%=1TO5
1020   DN$=INKEY$:IFDN$=""OR(DN$<>""AND(DN$<"0"ORDN$>"7"))THEN T%=1ELSET%=6
l040 NEXTT%
1060 PRINT @835,"                 ";
1080 IF DN$="0"THEN 1140
1100 PRINT @ 320,"PLACE  LDOS  FORMATTED DISK  IN  DRIVE "DN$"  <PRESS  ENTER>
  ";
1120 GOSUB 4620
1140 PRINT  @320,"Written by Bill  Fields P  0 Box  1120 Glendale Heights, Ill
60137"
1160 REM EACH DIRECTORY ENTRY IS 32 BYTES IN LENGTH
1180 REM SO OPEN DIRECTORY WITH LOGICAL RECORD LENGTH OF 32
1200 OPEN "R",1"DIR/SYS:"+DN$,32
1220 FIELD 1,32 AS F1$
1240 PRINT @835,"Reading GAT                                 ";
1260 REM GET 7TH 32 BYTE RECORD
1280 REM THIS IS X'C0'-X'DF' OF THE GAT RECORD
1300 GET 1,7
1320 REM GAT+X'CB' = VERSION OF SYSTEM UNDER WHICH THE DISKETTE
1340 REM WAS FORMATTED. IF OTHER THAN LDOS5.0 OR LDOS5.1 THEN
1360 REM WARN THAT UNPREDICTABLE RESULTS MAY OCCUR
1380 IF (ASC(MID$(F1$,12,1))  <>  (&H50)) AND (ASC(MID$(F1$,12,1))  <> (&H51))
THEN PRINT  @ 643,"** WARNING ** NON-LDOS DISKETTE - UNPREDICTABLE RESULTS MAY
OCCUR"
1400 REM GAT+X'CC' HAS DISKETTE CYLINDER COUNT EXPRESSED AS
1420 REM EXCESS OF 35 CYLINDERS. TC WILL HAVE TOTAL CYLINDERS.
1440 TC% = ASC(MID$(F1$,13,1)) + 35
1460 REM IF CYLINDER COUNT OF DISKETTE IS LESS THAN 35 THEN
1480 REM THE CYLINDER COUNT AT GAT + X'CC' WILL BE NEGATIVE
1500 REM LIKE, FOR INSTANCE, X'E2' FOR A 5 TRACK DISKETTE
1520 REM THEREFORE,IF CYLINDER COUNT IS > 255 AND < 291
1540 REM THEN ADJUST IT DOWNWARD.
1560 IF (TC%>255 AND TC%<291) THEN TC%=TC%-256
1580 REM IF GAT+X'CD' HAS BIT 5 = 1 THEN DOUBLE SIDED MEDIA,
1600 REM ELSE SINGLE SIDED MEDIA
1620 IF ASC(MID$(F1$,14,1)) AND B5% THEN S% = 2 ELSE S% = 1
1640 REM IF GAT+X'CD' HAS BIT 6 = 1 THEN DOUBLE DENSITY,
1660 REM ELSE SINGLE DENSITY.
1680 REM GC=GRANULES PER SIDE OF CYLINDER (TRACK) OF A
1700 REM DISKETTE. IF DOUBLE DENSITY THEN GC=3, IF SINGLE
1720 REM DENSITY THEN GC=2.
1740 IF ASC(MID$(F1$,14,1)) AND B6% THEN GC% = 3 ELSE GC% = 2
1760 REM IN CONSIDERATION OF OUR SMALL STORAGE FRIENDS,
1780 REM DIMENSION ONLY WHATS NEEDED.
1800 DIM X$(TC%-1,GC%*S%)
1820 PRINT @ 835,"Initializing for "TC%" cylinder diskette with "s%"side(s)";
1840 FOR I%--0TOTC%-1
1860   FOR J%=1TOGC%*S%
1880     X$(I%,J%)="***empty****"
1900   NEXT J%
1920 NEXT I%
1940 REM DISKETTE NAME AT GAT+X'D0'
1960 DN$ = MID$(F1$,17,8)
1980 REM GET NUMBER OF ENTRIES IN DIRECTORY




                                  Page - 51



2000 ZZ% = LOF(1)
2020 PRINT @771,"total 32 byte records in directory =";ZZ%
2040 REM SET CYLINDERS PROCESSED (FOR LOCKOUT) TO ZERO
2060 TX% = 0
2080 REM NOW SCAN TRACK LOCKED OUT INFO
2100 FOR I% = 4 TO 6
2120   REM WHEN I=4 GET GAT+X'60'-GAT+X'7F'
2140   REM WHEN I=5 GET GAT+X'80'-GAT+X'9F'
2160   REM WHEN I=6 GET GAT+X'A0'-GAT+X'BF'
2180   PRINT @835,"Reading GAT                                  ";
2200   GOSUB 4560
2220   GET 1,I%
2240   REM EACH BYTE IS A CYLINDER. IF = X'FF' THEN LOCKOUT
2260   PRINT @835,"Processing cylinder lockout bytes in GAT     ";
2280   FOR J% = 1 TO 32
2300     REM INCREMENT CYLINDER COUNT
2320     TX% - TX% + 1
2340     REM IF ALL BITS ARE ONE THEN SETUP AS LOCKED OUT
2360     IF ASC(MID$(F1$,J%,1))  = B0%+B1%+B2%+B3%+B4%+B5%+B6%+B7% THEN FOR D%
= 1 TO 8 :  X$((I%-4)*32+J%-1,D%) = "*LOCKED OUT*" : NEXT D%
2380     IF TX% = TC% THEN J%=33:I%=7
2400   NEXT J%
2420 NEXT I%
2440 REM Y1 = AVAILABLE GRANULES ON DISKETTE
2460 Yl% = 0
2480 REM SET CYLINDERS PROCESSED (FOR ALLOCATION) TO ZERO
2500 TX% = 0
2520 FOR I% = 1 TO 3
2540   REM IF I=1 THEN PROCESSING GAT+X'00'-GAT+X'1F'
2560   REM IF I=2 THEN PROCESSING GAT+X'20"-GAT+X'3F'
2580   REM IF I=3 THEN PROCESSING GAT+X'40'-GAT+X'5F'
2600   PRINT @835,"Reading GAT                                  ";
2620   GOSUB 4560
2640   GET 1,I%
2660   PRINT @835,"Processing granule allocation bytes in GAT    "
2680   FOR J% = 1 TO 32
2700     TX%=TX%+1
2720     FOR D%=1TOGC%*S%
2740       E%=l
2760       IF X$((((I%-1)*32)+J%-1),D%)="*LOCKED OUT*"THEN E%=0
2780 REM   THE BRACKET IN THE NEXT STATEMENT IS REALLY AN ARROW
2800 REM   THANK YOU MX-80!!!!!
2820       IF NOT ASC(MID$(F1$,J%,1)) AND (2[(D%-1)) THEN Y1%=Y1%+1:E%=0
2840       IF E%=1 THEN X$((((I%-1)*32)+J%-1),D%)="==>ERROR<==="
2860     NEXT D%
2880     IF TC%=TX% THEN I%=4:J%=33
2900   NEXT J%
2920 NEXT I%
2940 FIELD1,1 AS Y9$,4 AS F1$,8 AS P1$,3 AS P2$,6 AS F2$,10 AS EE$
2960 REM K1=FREE SPACE ON DISK IN K
2980 IF GC%=3 THEN D%=6 ELSE D%=5
3000 K1! = Y1%*(D%*.25)
3020 REM RECORDS 01-08 ARE GAT RECORD, AND
3040 REM RECORDS 09-16 ARE HIT RECORD, SO
3060 REM THEREFORE START AT THE 17TH 32 BYTE RECORD



                                  Page - 52



3080 FOR Y8% = 17 TO ZZ%
3100   PRINT @835,"reading         directory entry at record          ";Y8%;
3120   GET1,Y8%
3140   IF (ASC(Y9$) AND B4%) = 0 OR (ASC(Y9$) AND B7%) = 128 THEN 3580
3160   PRINT @835,"Processing FPDE directory entry at record          ";Y8%;
3180   IF P2$ <> "   " THEN PN$ = LEFT$(P1$,INSTR(P1$+" "," ")-1) + "/" + P2$
ELSE PN$ = P1$
3200 IF LEN(PN$)<>12 THEN PN$=PN$+STRING$(12-LEN(PN$)," ")
3220   FOR J% = 1 TO 10 STEP 2
3240     T%=ASC(MID$(EE$,J%,1)) : W%=ASC(MID$(EE$,J%+1,1))
3260     IF T% = 255 AND W% = 255 THEN 3580
3280     IF T% <> 254 GOSUB 4360 : GOTO 3560
3300     E% = W% AND (B7% + B6% + B5%)
3320     D% = W% AND (B0% + B1% + B2% + B3% + B4%)
3340     E%=E%/32
3360     D% = (D%+2)*8+E%+1
3380     PRINT @835,"Processing FXDE directory entry at record          ";D%
3400     GET1,D%
3420     FOR D%=1TO10STEP2
3440       E%=0
3460       T%=ASC(MID$(EE$,D%,1)):W%=ASC(MID$(EE$,D%+1,1))
3480       IF T%=255 AND W%=255 THEN E%=1
3500       IF T% <> 254 AND E% = 0 THEN GOSUB 4360 : E%=1
3520       IF E%<>1 THEN GOTO3300
3540     NEXT D%
3560   NEXT J%
3580 NEXT Y8%
3600 CLS
3620 CLOSE
3660 IF (PEEK(&H37E8) AND (B7%+B6%+B5%+B4%))=48 THEN P%=1 ELSE P%=0
3680 IK$=""
3700 SP%=0: TC%=TC%-1
3720 IF GC%*S%>3 THEN SF%=4 ELSE SF%=10
3740 IF P%=1 THEN LPRINT "Map of diskette by track/gran " ELSE PRINT  "Map of
diskette by track/gran"
3760 IF P%=0 AND IK$<>"" THENCLS
3780 IF GC%=2 THEN DS$="Sdns" ELSE DS$="Ddns"
3800 IF  P%=1 THEN  LPRINT "Diskette "DN$" Tracks" TC%+1"  free  "Y1%"g "K1! "k
Sides="S%" Dens=";DS$ ELSE PRINT  "Diskette  "DN$" Tracks "TC%+1" free  "Y1%"g
"K1! "k "S%" sides "DS$
3820 IF P%=1 THEN LPRINT "Trk "; ELSE PRINT "Trk ";
3840 FOR D%=1 TO GC%*S%
3860 IF P%=1 THEN LPRINT "Granule "D%"  ";ELSE PRINT "Granule "D%"  ";
3880 NEXT D%
3900 IF P%=1 THEN LPRINT ELSE PRINT
3920 FOR I%=SP%TOSP%+SF%
3940   IF I%>TC% AND P%=0 THEN 4120 ELSE IF I%>TC% AND P%=1 THEN4720
3960   IF P%=1 THEN LPRINT USING "##";I%;ELSE PRINT USING "##";I%;
3980   FOR J% = 1 TO GC%*S%
4000      IF  P%=1   THEN  LPRINT  USING "  %          %";X$(I%,J%);ELSE PRINT
USING " %          %";X$(I%,J%);
4020   NEXT J%
4040   IF P%=1 THEN LPRINT ELSE PRINT
4060 NEXT I%
4080 IF P%=1 THEN SP%=SP%+SF%+1:GOTO3920



                                  Page - 53



4100 IF SF%=4 THEN SF%=5
4120 U%=0:D%=0
4140 IF SP%<TC%-SF% THEN D%=-1:PRINT @960,"D = Scroll down";
4160 IF SP%>0 THEN U%=-1:PRINT@976,"U = Scroll up";
4180 PRINT @989,"<enter>=end";
4200 PRINT @1000," M = Map by file";
4220 IK$=INKEY$:IF IK$=""THEN 4220
4240 IF (IK$="U" OR IK$="u") AND U% THEN SP%=SP%-SF%:GOTO3760
4260 IF (IK$="D" OR IK$="d") AND D% THEN SP%=SP%+SF%:GOTO3760
4280 IF IK$=CHR$(13) THEN END
4300 IF IK$="M" OR IK$="m" THEN 4720
4320 GOTO4220
4340 REM record location of file's extent
4360 G% = W% AND (B0% + B1% + B2% + B3% + B4%)
4380 G%=G%+1
4400 W%=INT(W%/32)+1
4420 IF  LEFT$(X$(T%,W%),1)<>"="THEN PRINT @899,"Directory error in ";PN$;
"TRACK="T%;"SECTOR="W%" press <enter> to continue"; :GOSUB4620
4430 PRINT @899,STRING$(76," ")
4440 X$(T%,W%)=PN$
4460 G%=G%-1
4480 IF G%=0 RETURN
4500 W%=W%+1
4520 IF W%>GC%*S% THEN W%=1:T%=T%+1
4540 GOTO4420
4560 FOR T%=1TO100
4580 NEXT T%
4600 RETURN
4620 FORA%=1TO5
4640    IK$=INKEY$
4660    IF IK$ = CHR$(13) THEN A%=6 ELSE A%=1
4680 NEXT A%
4700 RETURN
4720 I%=-1
4740 IF P%=1 THEN LPRINT CHR$(12)
4760 CLS
4780 DIM S$(GC%*S%*(TC%+1)-1)
4800 FOR D%=0TOTC%
4820   FOR T%=1TOGC%*S%
4840     I%=I%+1
4860     IF LEN(STR$(D%))=2 THEN DS$=STR$(D%) ELSE DS$=RIGHT$(STR$(D%),2)
4880     IF LEN(STR$(T%))=2 THEN PN$=STR$(T%) ELSE PN$=RIGHT$(STR$(T%),2)
4900     S$(I%)=X$(D%,T%)+DS$+PN$
4920     PRINT @835,"PREPARING TRACK "D%;"  SECTOR"T%;"INTO RECORD "I%" FOR
SORT"
4940     X$(D%,T%)=""
4960   NEXT T%
4980 NEXT D%
5000 PRINT @835,"Sorting ......
5020 CMD "O",GC%*S%*(TC%+1),S$(0)
5040 IF P%=1 THEN PRINT@835,"OUTPUTTING";
5060 DS$=""
5080  IF P%=1 THEN LPRINT:LPRINT:LPRINT "MAP OF DISKETTE "DN$" BY FILENAME"
:ELSE CLS:PRINT "MAP OF DISKETTE "DN$" BY FILENAME"
5100 SF%=12



                                  Page - 54



5120 FOR I%=0TOGC%*S%*(TC%+1)-1
5140    IF  ((I%-(INT(I%/SF%)*SF%)=0)  AND  (P%=1)  AND  (I%=0))  THEN  LPRINT
"FILENAME   TRACK GRANULE"  ELSE IF ((I%-(INT(I%/SF%)*SF%)=0) AND (P%=0)) THEN
PRINT "FILENAME    TRACK GRANULE"
5160   IF MID$(S$(I%),1,12)<>DS$ THEN E%=2 ELSE E%=1
5180   ON E% GOTO 5200,5240
5200   IF P%=1 THEN LPRINT "             ";ELSE PRINT "             ";
5220   GOTO5260
5240   IF  P%=1 THEN LPRINT MID$(S$(I%),1,12)" ";ELSE PRINT MID$(S$(I%),1,12)"
";
5260   DS$=MID$(S$(I%),1,12)
5280    IF  P%=1  THEN LPRINT  MID$(S$(I%),13,2);"    ";MID$(S$(I%),15,2) ELSE
PRINT MID$(S$(I%),13,2);"    ";MID$(S$(I%),15,2)
5300 IF P%=1 THEN 5540
5320 IF INT((I%+1)-(INT((I%+1)/SF%)*SF%))<>0 THEN5520
5340 D%=$:U%=0
5360  IF  I%<INT((GC%*S%*(TC%+1)-1)/SF%)*SF%  THEN   D%=-1 :PRINT@960,"D=SCROLL
DOWN";
5380 IF I%=>SF% THEN U%=-1:PRINT@976,"U=SCROLL UP";
5400 PRINT @989,"<ENTER>=END";
5420 IK$=INKEY$: IFIK$=""THEN 5420
5440 IF  (IK$="U" OR IK$="u")  AND U% THEN I%=I%-SF%*2:DS$="":CLS:IFI%<0  THEN
I%=-1: GOTO5520ELSE GOTO5520
5460 IF (IK$="D" OR IK$="d") AND D% THEN :DS$="":CLS:GOTO5520
5480 IF IK$=CHR$(13) THEN END
5500 GOTO5420
5520 IF I%=GC%*S%*(TC%+1)-1 THEN I%-INT(I%/SF%)*SF%:GOTO5340
5540 NEXT I%


This  section of the newsletter contains some programs that require the use of
the BINHEX/BAS program to convert them to executable binary files.

Note  that the hex program listings  must be put  into the  proper load module
format before they can be used. To use the program, follow these steps:

1) Use Scripsit, LED, or the BUILD  command to create an ASCII file containing
the hex  code. DO  NOT leave spaces  between  the hex  characters - the spaces
were  put in for readability only!. The ASCII files must NOT contain more than
254 characters (127 byte pairs) per line.

2) Enter LBasic, and Run the program BINHEX/BAS, choosing  the "Hex to Binary"
mode.

BINHEX/BAS

Following is the listing for the LBasic program, contributed by Tim Mann.










                                  Page - 55



10 REM -- Hex to binary/Binary to hex file converter
20 REM -- Tim Mann
30 CLS:PRINT:PRINT"Hex to binary/Binary to hex"
35 PRINT"     file converter":PRINT
40 CLEAR 5000
50 GOSUB 58000
100 PRINT "Type 1 to convert a binary file to hex"
110 PRINT "     2 to convert a hex file to binary"
120 PRINT:INPUT D
130 PRINT
140 ON D GOTO 400,200
150 GOTO 100
200 LINE INPUT "Hex file name: ";HF$
210 LINE INPUT "Binary file name: ";BF$
220 OPEN"I",1,HF$
230 OPEN"O",2,BF$
240 IF EOF(1) THEN 320
250 LINE INPUT#1,D$
255 IF D$="" OR D$="OK" THEN 240
260 FOR I=1 TO LEN(D$) STEP 2
270    PRINT#2,CHR$(FND2(MID$(D$,I,2)));
300 NEXT I
310 GOTO 240
320 CLOSE
330 PRINT:PRINT"Done":PRINT
340 GOTO 100
400 LINE INPUT "Binary file name: ";BF$
410 LINE INPUT "Hex file name: ";HF$
420 OPEN"RO",1,BF$,1
430 OPEN"O",2,HF$
440 FIELD 1,1 AS F$
450 FOR I=1 TO 30
455    IF EOF(1) THEN 505
460    GET 1
470    PRINT#2,FNH2$(ASC(F$));
480 NEXT I
490 PRINT#2,
500 GOTO 450
505 PRINT#2,
510 CLOSE
520 PRINT:PRINT"Done":PRINT
530 GOTO 100
58000 DEF FNH1$(X)=MID$("0l23456789ABCDEF",(X AND 15)+1,1)
580l0 DEF FNH2$(X)=FNH1$(X/16)+FNH1$(X)
58040 DEF FND1(X$)=INSTR("123456789ABCDEF",LEFT$(X$,1))
58050 DEF FND2(X$)=FND1(RIGHT$(X$,1))+16*FND1(RIGHT$(X$,2))
58070 RETURN
60000 END


DELETE/CMD: A MultiDle-KILL Utility by Renato B. Reyes  Ph.D.

     LDOS  has two commands   for  deleting files from disk,   ie.,  KILL  and
PURGE.




                                  Page - 56



KILL deletes single files, while  PURGE  deletes  several  files from the same
disk,    either    automatically    (using    partspecs     and/or    wildcard
specifications)  or   under  user   control.   Between   these   two   library
commands,  however,  there exists a wide gap.

     I  have often  found   it  necessary   to  kill  several  files at  once,
without   being   able to use  the   PURGE   (Q=N)   command.  Sometimes   the
filespecs bear  no  resemblance  to  each  other, which  prevents   the use of
wildcards or partspecs,  or,   worse, they bear  too much  of  a   resemblance
to   other  files on  the disk. And going through  a  manual  PURGE  when  you
have  seventy or eighty files on  a disk  can be time consuming.  The only al-
ternative was to KILL the files one by one.

     On timesharing  systems  such as MicroNET,  the  DELETE  command can take
several  filenames at once.  These  filenames  are separated on   the  command
line by  some valid terminator such as a comma,  and the  system goes  through
the  list   and kills  each  file  from   your directory. I   realized  that a
similar facility would be very easy to set up for LDOS.

     The  accompanying  program, called  DELETE,  is   such  a "multiple-KILL"
facility. To use it, you simply type in

          DELETE filespec,filespec,filespec ....

for as  many   filespecs  as you can fit  on  the   command   line.  Filename,
extension and   password  (if any)  are required;  however drivespecs may   be
omitted.  The  files  must  be   separated from  each  other by a comma  or  a
space. DELETE will  go  through the  list  and  search  the currently  mounted
disks for the   specified  files, deleting them  one  by one. Any errors which
occur  cause  the  program  to display the   offending   file  name   and  the
accompanying error  message.  At the end  of the  process, DELETE will display
the number of files successfully killed.

     If in the  process  of  killing the  listed  files  DELETE comes  upon an
invalid   filespec  or   unrecognizable   terminator,  it   will  display  the
message,   "Invalid    filespec/terminator   encountered."  and   attempt   to
continue,  skipping past the  error if possible.

     DELETE has  one advantage over PURGE;  it  can search every mounted  disk
for  a particular  file to kill,  whereas PURGE is restricted  to  searching a
particular drive only.  However,  DELETE is limited by the size of the command
buffer. It  may be a  good  idea to rename this utility  and give it a  single
letter for  a filename,  in   order to  maximize  the  available  space in the
command  buffer.   In  spite  of  this limitation,  however,  DELETE  is  much
easier  to  use than either  KILL  or PURGE where only  two or three  (or even
four) files need to be killed.

Use  the BINHEX/BAS program to convert this  to  a /CMD file. For those of you
who have the compiled BINHEX/CMD program, the checksum is *F0.

05 06 44 45 4C 45 54 45 01 02 00 52 E5 21 9B 52 CD 67 44 E1 7E FE 0D 28 1E DD
21 7F 53 11 80 53 CD 1C 44 32 7E 53 20 18 CD 24 44 20 24 CD 2C 44 20 1F DD 34
00 18 E6 21 F5 52 CD 67 44 C3 30 40 3A 7E 53 FE 0D 28 3A E5 21 3D 53 CD 67 44
E1 18 CC E5 F5 3A 80 53 CB 7F 20 03 CD 28 44 21 80 53 3E 0D 01 20 00 ED B1 3E
03 77 21 80 53 CD 67 44 21 66 53 CD 67 44 F1 CB F7 CB FF CD 09 44 E1 18 9C 21



                                  Page - 57



7F 53 11 6A 53 CD 87 52 21 6A 53 CD 67 44 C3 2D 40 7E 0F 0F 0F 0F CD 90 52 7E
E6 0F C6 90 27 CE 40 27 12 13 C9 44 45 4C 45 54 45 20 2D 20 4D 75 6C 74 69 70
6C 65 20 66 69 6C 65 20 64 65 6C 65 74 65 20 75 74 69 6C 69 74 79 20 66 6F 72
20 4C 44 4F 53 20 2D 20 56 65 72 2E 20 32 28 33 29 0A 28 63 29 20 31 39 38 32
20 62 79 20 52 2E 20 42 2E 20 52 65 79 65 73 2C 20 50 68 2E 44 2E 0D 0A 46 69
6C 65 20 73 70 65 63 28 01 A3 00 53 73 29 20 72 65 71 75 69 72 65 64 0A 53 79
6E 74 61 78 20 69 73 3A 20 44 45 4C 45 54 45 20 66 69 6C 65 73 70 65 63 2C 66
69 6C 65 73 70 65 63 2C 66 69 6C 65 73 70 65 63 2C 2E 2E 2E 0D 49 6E 76 61 6C
69 64 20 66 69 6C 65 73 70 65 63 2F 74 65 72 6D 69 6E 61 74 6F 72 20 65 6E 63
6F 75 6E 74 65 72 65 64 2E 0D 20 2D 20 03 30 30 20 66 69 6C 65 28 73 29 20 64
65 6C 65 74 65 64 2E 0D 00 00 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0D 02 02 00 52

NODAM - Read those OLDAM disks directly - by Chuck

This  program  came about as a result of needing to read someone's TRSDOS data
disk on my LX-80 at home. This disk  also had to be  returned to the  owner in
original  condition.  The following program  will allow  Model III and Model I
LX-80 owners to directly read a diskette  that uses the old Data Address Mark.
It  is very simple to use, but like some simple  programs,  it  creates a very
simple way to destroy  diskettes.  Here is a  description of the  program, and
how to avoid losing data when using it.

The program bypasses the  checking for the  directory  track DAM by indicating
that the  proper  DAM  was found  WHENEVER THE  SYSTEM  ACCESSES THE DIRECTORY
TRACK  AS  INDICATED  IN  THE  DRIVE  CODE  TABLE. This means  that  you  MUST
either do a  DEVICE  or  LOG command  after installing the program  and before
attempting  to read  the  diskette.  To  install  the  program,  type  in  the
following command, with the ":d" being the drive number to be used:

   NODAM :d

Then, either  do  a DEVICE command, or a LOG  :d  command.  This will properly
update the DCT with the correct directory track. The programs may now be  read
off  of the disk onto a normal LDOS disk.  The software write protect bit will
also be  set, and should show  in the DEVICE command if you are using LDOS 5.1
or later. Now for the pitfalls .

Since the  system is relying upon the DCT information, if you switch diskettes
in  a  NODAMed  drive  and  forget  to log  it  in,  and  the  diskettes  have
directories  on  different  tracks,  scratch  one  diskette  after  the  first
attempted write operation  to  that  drive.  Also, using the BACKUP command to
move information  off of the NODAMed drive will write  the  new DAM  onto that
disk  when removing the  MOD flags  unless it  is  write-protected!  Since the
software write protect will not work with LDOS 5.0,  or on LX-80's without the
5.1  ROM,  the best procedure to  follow is to always physically write-protect
any diskette to be read in the NODAMed drive.

Once  the disk is read and  copied, NODAM may be removed as follows. For LX-80
owners  with any  LDOS  version,  use the  SYSTEM  (DRIVE ,DRIVER) command  to
restore  the proper driver information. For  those  with the 5.1.2 update, use
the  SYSTEM  (DRIVE=,DRIVER)  command  and  the MOD1/DCT or  MOD3/DCT program.
Model  1, 5.1.1 owners can use the  SYSTEM  (DRIVE=,DRIVER)  command, pressing
<BREAK> to  restore the dafault driver address. For Model I, 5.0 and Model III
5.1.$, do a global RESET or BOOT to restore the normal drive configuration.



                                  Page - 58



Following is the code for  the  NODAM/CMD program. Use  the BINHEX/BAS program
to convert it, following instructions found with the program. For  those  with
BINHEX/CMD, the checksum is *59.

05 06 4E 4F 44 41 4D 31 01 FE 00 52 E5 21 6B 52 CD 67 44 3A 25 01 FE 49 21 49
40 20 03 21 11 44 22 35 52 22 3E 52 E1 7E 23 FE 20 28 FA FE 3A 20 3D 7E FE 30
38 38 FE 38 30 34 D6 30 4F CD 8F 47 2A 00 00 01 24 00 B7 ED 42 22 00 00 23 E5
21 E3 52 FD 7E 01 77 23 FD 7E 02 77 E1 FD 75 01 FD 74 02 FD CB 03 FE EB 21 D8
52 ED B0 C3 2D 40 21 C6 52 CD 67 44 C3 30 40 1F 4E 4F 44 41 4D 20 2D 20 4F 6C
64 20 44 61 74 61 20 41 64 64 72 65 73 73 20 4D 61 72 6B 20 72 65 61 64 65 72
20 2D 20 56 65 72 20 31 2E 30 0A 43 6F 70 79 72 69 67 68 74 20 31 39 38 32 20
62 79 20 47 61 6C 61 63 74 69 63 20 53 6F 66 74 77 61 72 65 2C 20 4C 74 64 2E
0A 0D 42 61 64 20 64 72 69 76 65 20 6E 75 6D 62 65 72 21 0D 18 08 00 00 05 4E
4F 44 41 4D CD 00 00 F5 7A FD BE 09 20 0E 78 FE 09 28 04 FE 0A 20 05 F1 3E 06
B7 C9 F1 C9 02 02 00 52


                                   MX80/FLT

This filter will allow the  MX-80  to properly print  the TRS-80 graphics set.
It will work with both 5.0 and 5.1 versions,  and on both the Model I and III.
The BINHEX/CMD checksum is *D4.

05 06 4D 58 38 30 20 20 01 02 00 52 D5 1A F5 21 72 52 CD 67 44 3A 25 01 FE 49
28 08 21 49 40 11 7B 44 18 06 21 11 44 11 8A 42 22 41 52 22 4D 52 ED 53 6D 52
F1 CB 5F 20 32 CB 67 20 33 CB 4F 28 34 DD E1 DD 6E 01 DD 66 02 22 20 53 2A 00
00 22 08 53 01 1C 00 AF ED 42 22 00 00 23 DD 75 01 DD 74 02 EB 21 06 53 ED B0
C3 2D 40 21 CE 52 18 08 21 E0 52 18 03 21 F1 52 CD 00 00 C3 30 40 1F 4D 58 38
30 20 2D 20 4C 44 4F 53 20 4C 69 6E 65 20 50 72 69 6E 74 65 72 20 46 69 6C 74
65 72 20 2D 20 56 65 72 73 69 6F 6E 20 31 2E 31 0A 43 6F 70 79 72 69 67 68 74
20 28 63 29 20 31 39 38 31 20 62 79 20 4C 6F 67 69 63 61 6C 20 53 79 73 74 65
6D 73 2C 20 49 6E 63 2E 0A 0D 44 65 76 69 63 65 20 6E 6F 74 20 61 63 74 69 76
65 0D 44 65 76 69 63 65 20 69 73 20 72 6F 75 74 65 64 0D 4E 6F 74 20 61 6E 20
6F 75 74 70 75 74 20 64 01 24 00 53 65 76 69 63 65 0D 18 07 00 00 04 4D 58 38
30 38 0E F5 79 FE 81 38 07 FE C0 30 03 C6 20 4F F1 C3 00 00 02 02 00 52


The  following  patches for Radio Shack's  PROFILE program were  developed  by
Dick Yevich. They are for  both the Model  I and  III. Following  are the text
and patches from Dick.

PROFILE ON LDOS

The following patches will  allow the program PROFILE to  run under LDOS. They
are presented for  both the 3.1 version for the MOD-I  and the 3.2 version for
the MOD-III.  After  these patches is  an  alternate  patch  which offers some
changes  to the product  to allow  it to  be more easily used. Following  this
brief description are the patches which affect this result:

     1. The PROFILE/CMD and the overlays  SORT, INIT, ACCESS, and PRINT can be
     on any drive.

     2. As standard PROFILE, the  PRODAT file  must start on drive  0, and the
     other files of INFOFILE, FORMFILE, and LPFORM will also be built on :0.




                                  Page - 59



     3. PRODAT will use:

           MOD-I:     drive 0    - 144 sectors
                      drives 1-3 - 302 sectors
           MOD-III:   drive 0    - 448 sectors
                      drives 1-3 - 672 sectors

     4. For the MOD-III 3.2  version only, KI/DVR is utilized,  but TYPE AHEAD
     is  turned  off  on  entry  and turned-on on exit  (if  it was on  at the
     start). The <SHIFT><0> is  supported for upper and  lower case  for field
     names, video display, and print headings.

. 3.1.1 patch for PROFILE/CMD, vers 3.1, MOD-I
X'527F'=20 20 4C
X'52AC'=2E 31 20
X'534F'=4C 44 4F 53 20
X'5AFD'=03
X'5B04'=03
X'5B0D'=03
X'5B15'=03
.EOP

. 3.1.1 patch for INIT, vers 3.1, MOD-I
X'7388'=90 00 2E 01 2E 01 2E 01
.EOP

. 3.1.1 patch for SORT, vers 3.1, MOD-I
X'76F1'=20 4C
X'7701'=20
.EOP

. 3.1.1 patch for PRINT, vers 3.1, MOD-I
X'73BD'=20 4C
X'73D1'=20
.EOP

. 3.2.1 patch for PROFILE/CMD, verB 3.2, MOD-III
X'527E'=20 20 4C
X'52AB'=2E 31 20
X'534E'=4C 44 4F 53 20
X'5AFC'=03
X'5B03'=03
X'5B0C'=03
X'5B14'=03
X'5FB3'=00 00 00 00 00 00
X'5FD0'=C3 00 67
X'65C3'=C5 CD 4D 52 FE 61 38 06 FE 7A 30 02 E6 DF C1 C9
X'6700'=3E 00 21 1C 40 CB BE CB 4F 21 15 67 C2 99 42 C3
X'6710'=2D 40 53 59 53 54 45 4D 20 28 54 59 50 45 29 0D
.EOP








                                  Page - 60



. 3.2.1 patch for INIT, vers 3.2, MOD-III
X'7031'=00 00 00 CD 80 76
X'7062'=1A
X'738A'=C0 01 A0 02 A0 02 A0 02
X'7680'=21 1C 40 CB FE 3A 89 42 32 01 67 AF 32 05 44
X'768F'=3E 0A C3 40 40
.EOP

. 3.2.1 patch for PRINT, vers 3.2, MOD-III
X'73BD'=20 4C
X'73D1'=20
.EOP

. 3.2.1 patch for SORT, vers 3.2, MOD-III
X'76F1'=20 4C
x'7701'=20
.EOP

ADDITIONAL PATCH FOR THE MOD-III

This changes 2 and 3 above for the MOD-III as follows:

     1 - The PRODAT file will start being formatted on drive  1, and the other
     files will  also  be built on drive 1,  allowing  a  normal SYSRES to  be
     used.

     2 - PRODAT uses:  drive 1    - 592 sectors
                       drives 2-4 - 672 sectors

On  drives 2-4, that  leaves 1.5K  for BOOT, 4.5K for SYS0 and  6.0K  free for
misc.  On  drive 1,  it leaves enough  room  to hold  the  INFOFILE, FORMFILE,
LPFORM, and the command and overlays.

-------  these are additions to the above patches.

. 3.2.2 patch for PROFILE/CMD, vers 3.2, MOD-III
X'52AB'=2E 32 20
X'5AD9'=31
X'5AE4'=31
X'5AED'=31
X'5AF6'=31
.EOP

. 3.2.2 patch for INIT, vers 3.2, MOD-Ill
X'7101'=00
X'7198'=01
X'7292'=37
X'7355'=00
X'738A'=50 02 A0 02 A0 02 A0 02
.EOP

. 3.2.2 patch for SORT, vers 3.2, MOD-III
X'77B4'=CD 7C 7B
X'7B7C'=3C DD 77 07 C9
.EOP



                                  Page - 61



Any  problems  encountered  can  be  conveyed  to us and  we  will  attempt  a
resolution.  We will  assist anyone in adding the KI/DVR to the MOD-I version.
Call Dick Yevich at Yevich Assoc., Inc. (609) 428-0021.


Old Subject Revisited

By  popular  demand, the following  section  is  a reprint of  the SALVAGE/BAS
program and Radio Shack patches from the October newsletter.

Since Radio Shack made some major changes to TRSDOS for  the Model I  and III,
we have developed a  program to move files  off of the new TRSDOS 2.3B Model I
disks. This is  an  LBASIC program called SALVAGE/BAS. It will copy files from
a 2.3B or later TRSDOS disk to an LDOS disk.

10 REM--SALVAGE/BAS
20 REM--Program to get files from a TRSDOS 2.3B disk
30 REM-- onto LDOS disks, Model I or III.
40 REM--Use only on the Model I, 2.3B or later. Model III owners should
50 REM-- use CONV to get the files from the ThSDOS 1.3 disk.
100 LINE INPUT "Source filespec? ";SF$
110 LINE INPUT "Destination filespec? ";DF$
200 OPEN"RO",1,SF$
210 OPEN"R",2,DF$
220 FIELD 1,1 AS D1$   'Find source FCB
230 FIELD 2,1 AS D2$   'Find destination buffer
240 Z1=VARPTR(D1$):Z1=PEEK(Z1+1)+256*PEEK(Z1+2)
250 Z2=VARPTR(D2$):Z2=PEEK(Z2+1)+256*PEEK(Z2+2)
260 POKE Z1-32+3,Z2AND&HFF:POKE Z1-32+4,Z2/&H100 'Use 1 bfr
270 N=PEEK(Z1-32+12)+256*PEEK(Z1-32+13) 'Get ERN
280 IF PEEK(Z1-32+8)=0 THEN 300 'Adjust if needed
290 N=N+l:POKE Z1-32+12,NAND&HFF:POKE Z1-32+13,N/&H100
300 FOR I=1 TO N 'Copy file
3l0 GET 1:PUT 2
320 NEXT I
330 POKE Z2-32+8,PEEK(Z1-32+8) 'Transfer offset
340 POKE Z1-32-2,0 'Don't close source file!
350 END


     It  was  also necessary to develop  some small patches for  Radio Shack's
Cobol  and  RSBasic  compilers.  The Cobol package will  refuse  to run  under
anything but TRSDOS 2.3B on  the Model I or TRSDOS 1.3 on the Model III unless
patched, and both  packages do  some  peculiar things  in attempting to handle
the  <Break> key,  which may not work under  LDOS. Although  this  may not  be
clear from the  documentation, these  programs were designed  to run on either
the  Model I or Model III, so the patches  can be applied to a copy taken from
either the  Model I  or  Model  III disks  in  the Radio  Shack  package.  The
resulting patched programs will run on either Model  I  or Model III LDOS. Due
to the incompatibility between  TRSDOS 2.3B and earlier versions of TRSDOS, it
was also necessary to  write  a  special  program  to recover files  from 2.3B
disks. The  REPAIR utility is not  capable  of repairing  2.3B  diskettes (see
SALVAGE/BAS, page 15).  If you have LDOS  5.1, it  is recommended that you use
the CONV utility to transfer the Model III package to an LDOS formatted disk.




                                  Page - 62



. RSCOBOL/FIX
. Patch for Radio Shack COBOL compiler version 1.3B
.   to run under LDOS Model I and III
X'A196'=4F
X'A1D8'=50
X'9A4F'=D2
X'9A5A'=3E C9 32 0C A0 00
. End of patch

. RUNCOBOL/FIX
. Patch for Radio Shack COBOL Version l.3B runtime package
.   to run under LDOS Model I and III
X'AE6B'=4F
X'AE7E'=50
X'9B38'=38
X'9B4A'=3E C9 32 B0 A9 00
. End of patch


. CEDIT/FIX
. Patch to RS Cobol editor version 1.3B to run under LDOS
.   model I or III.
X'5832'=3E C0 32 13 5C 00 00 00 00 00 00 00
X'5C05'=C3
. End of patch


. RSBASIC/FIX
. This patch corrects the Radio Shack Basic Compiler 2.4
.   for proper operation under LDOS Model I and III.
.   Either the Model I or Model III version may be patched,
.   and the resulting program will run on either model0
X'9971'=C9
X'997B'=00 00
. End of patch


. BEDIT/FIX
. This patch corrects the Radio Shack Compiler Ba8ic editor
.   program for proper operation on Model I/III LDOS.
.   Either the Model I or Model III version may be patched,
.   and the patched version runs on both models.
X'58DB'=00 3E C9 32 7C
X'58E4'=00 00 00
X'5C6E'=C3
. End of patch












                                  Page - 63



Patches to MOD I - LDOS 5.1.2 - 03/23/82

These patches are to be installed on all MOD  I - 5.1.2 disks with files dated
before 03/20/82.

Fixes a problem with the <ENTER> key        Fixes a problem with RS232R.
when using a single drive or the (X)
parameter in BACKUP.

Patch BACKUP/CMD.RRW3                       Patch RS232R/DVR.GSLTD
X'5408'=E8 55                               D02,49=00 00
X'55E8'=CD 2B 00 B7 C9                      D02,4F=98
.EOP                                        .EOP

The KI driver setup the wrong type byte     FORMAT initialized the wrong
in the DCB.                                 passwords for BOOT and DIR.

Patch KI/DVR.GSLTD                          Patch FORMAT/CMD.RRW3
D02,82=05                                   D04,F2=AE 01 F5 9C
.EOP                                        D05,12=AE 01
                                            .EOP

The PDUBL driver did not setup all 8 DCTs

Patch PDUBL/CMD.RRW3
D00,40=51
D00,86=08
D00,8F=0A
.EOP

Patches to MOD III - LDOS 5.1.2 -03/23/82

These patches are to  be installed  on all  MOD  III - 5.1.2 disks with  files
dated before 03/20/82.

The KI driver setup the wrong               FORMAT initialized the wrong
type byte in the DCB.                       passwords for BOOT and DIR.

Patch KI/DVR.GSLTD                          Patch FORMAT/CMD.RRW3
D02,85=05                                   D04,F2=AE 01 F5 9C
.EOP                                        D05,12=AE 01
                                            .EOP

RS232T could not be "configed".

Patch RS232T/DVR.GSLTD
D02,5D=C7
.EOP

The LDOS QUARTERLY  is copyrighted  in  its  entirety.  No  material contained
herein may be  duplicated for  any purpose without  the  written permission of
Logical Systems, Incorporated.





                                  Page - 64


