home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / cpm / walnut-creek-CDROM / ENTERPRS / CPM / UTILS / F / LUALL.ZIP / LU300.DOC < prev   
Text File  |  1989-10-07  |  35KB  |  927 lines

  1.  
  2.  
  3.    Documentation for LU.COM and LRUN.COM
  4.  
  5.    
  6. |  This  document applies to version 3.00 of LU.COM and version
  7.    2.0 of LRUN.COM.
  8.  
  9.    Copyright (c) 1982, 1983 by Gary P. Novosielski
  10.    All rights reserved.
  11.  
  12.    Permission  is  hereby  granted  to copy and distribute this
  13.    document  for  any  non-commercial  purpose. Any use of this
  14.    material  for  commercial  advantage  without  prior written
  15.    consent of the author is prohibited.
  16.  
  17.    
  18.  
  19.                            INTRODUCTION
  20.  
  21.    Library  Utility  (LU)  is  a  program to allow combining of
  22.    multilple  files  into  one  larger  file.  It requires CP/M
  23.    version 2.0 or higher to run.
  24.  
  25. |  Version 3.00 replaces  version 2.11. The major revisions are
  26. |  the  addition  of the -b, and -n operators, and the addition
  27. |  of  CRC  calculation  and  checking  to improve reliability.
  28. |  Error  reporting has also been improved. Major revisions are
  29. |  marked with a vertical bar (|) in the left margin.
  30.  
  31.         The  directory  information  in  an LU style library is
  32.    contained  in  the  same file as the data files, or members.
  33.    The amount of space to be allocated to the directory must be
  34.    specified by the user when a new library is created, but can
  35.    be  changed  when  the file is reorganized. The size of each
  36.    directory entry is 32 bytes, which means each four directory
  37.    entries  take  up  one sector of the library file. Currently
  38. |  only  18  bytes  of each entry are used, with 14 bytes being
  39.    reserved  for  use  with  possible  future enhancements. The
  40.    directory  itself uses one entry for control information, so
  41.    the  number  of  directory sectors needed for a library of m
  42.    members is (m + 1) / 4, rounded up to the next whole number.
  43.         The user need not be concerned with this discussion, as
  44.    directory  size  is calculated by the program. All directory
  45.    sizes  are  input and output in terms of entries, each entry
  46.    being a potential member file. The program adjusts directory
  47.    size to an integral number of sectors.
  48.  
  49.         LRUN.COM is a small program which allows running a .COM
  50.    (object code) file member directly from any library, without
  51.    having to extract it to a separate disk file.
  52.  
  53.    
  54.  
  55.    
  56.  
  57.    
  58.  
  59.    
  60.  
  61.    
  62.  
  63.    
  64.    Page 1 of 14   83-08-16
  65.  
  66.    
  67.  
  68.    
  69.    Documentation for LU.COM and LRUN.COM
  70.  
  71.    
  72.                         WHY USE LIBRARIES?
  73.  
  74.         First,  a library file usually takes up less space than
  75.    the total of the individual member files which went into it.
  76.    The  reason  for  this  is that CP/M allocates disk space in
  77.    fixed  blocks  or groups, typically 2k bytes each. Any space
  78.    after  the  last  sector  of  a file up to the next 2k block
  79.    boundary is wasted. The same files in a library use only the
  80.    number of sectors they actually need, and though the library
  81.    itself  may  have  a  partially wasted block at the end, and
  82.    requires   some  space  for  directory  information  at  the
  83.    beginning,  the  net  effect  is  usually  a saving of total
  84.    space.  The  best results are seen when many small files are
  85.    combined into one library.
  86.         Second,  a library file makes most efficient use of the
  87.    CP/M disk directory, since it is treated as only one file by
  88.    CP/M regardless of how many members it contains.
  89.         Third,  libraries  can  aid in transferring packages of
  90.    software  from  one system to another using XMODEM. Only one
  91.    file  is transferred, eliminating the need to run the XMODEM
  92.    transfer  program several times, the chance of overlooking a
  93.    needed  file, and the problems of naming conflicts, (such as
  94.    READ.ME files) among unrelated packages.
  95.  
  96.    
  97.  
  98.                       WHY NOT USE LIBRARIES?
  99.  
  100.         There   are  some  very  good  reasons  for  not  using
  101.    libraries.
  102.         For one thing, files within a library are not available
  103.    to  most "normal" programs. If a frequently accessed file is
  104.    placed  in  a library, it will have to be extracted from the
  105.    library  to  its  free-standing counterpart before it can be
  106.    used  by  most programs. (.COM files are a notable exception
  107.    to  this,  because  of the availability of the LRUN command,
  108.    covered later.)
  109.         Libraries  can  actually  waste disk space. When a disk
  110.    file  is erased, CP/M returns the space formerly used by the
  111.    file  to  the  free  space pool for use by new files. When a
  112.    member  file  is  deleted  from a library however, the space
  113.    previously  occupied by the file is not useable. The library
  114.    must  be  reorganized  to make this space available to CP/M.
  115.    While  this  is  easy  to  do with the LU program, it is not
  116.    automatic,  and  if the situation is ignored, large areas of
  117.    disk can be tied up as unproductive "dead space".
  118.  
  119.    
  120.  
  121.    
  122.  
  123.    
  124.  
  125.    
  126.  
  127.    
  128.  
  129.    
  130.    Page 2 of 14   83-08-16
  131.  
  132.    
  133.  
  134.    
  135.    Documentation for LU.COM and LRUN.COM
  136.  
  137.    
  138.                   HOW TO USE THE LIBRARY UTILITY
  139.  
  140.         LU  has two main methods of operation: interactive, and
  141.    parameter  driven.  In  parameter  driven  mode, the program
  142.    takes  its  command  inputs from the command line when it is
  143.    first  invoked, and when the entire line has been processed,
  144.    execution ends.
  145.         In  interactive  mode,  the  program  takes its command
  146.    inputs  from one or more input lines from the standard input
  147.    device  (typically the console). When all the command inputs
  148.    have  been  processed,  the program reads another line. This
  149.    process can be repeated as long as necessary.
  150.         Input  from disk files, C program "pipes", and the XSUB
  151.    facility are also supported for more advanced applications.
  152.         Interactive  mode  is  probably  the best way to get to
  153.    know  the  program, because the effect of each action can be
  154.    immediatley seen.
  155.         To  start  an  interactive library maintenance session,
  156.    just  type  LU  on the command line with no parameters after
  157.    it.
  158.         All the methods make use of similar syntax:
  159.         Each  input  line, regardless of its source, is scanned
  160.    left  to  right.  All alphabetic characters are converted to
  161.    upper  case. If the line contains any blanks it is separated
  162.    into multiple individual input strings.
  163.         These  input  strings  are  divided  into  two classes:
  164.    operators (sometimes called tags, or options) and operands.
  165.         An  operator  is  defined  as  any two character string
  166.    where  the  first  character is a minus sign. Operators tell
  167.    the  program what to do. Valid operators are -a, -b, -c, -d,
  168.    -e,  -l  -n,  -o, -r, -u and -x. Anything else with the same
  169.    form is an operator too, but an invalid one.
  170.         Operands are any other input string.
  171. |       The  most  common  operand  strings  are names of files
  172. |  which  are  to  be  acted upon by the previous operator, for
  173. |  instance,  added  to or extracted from a library file. These
  174. |  are called filespec operands, and have the following general
  175. |  form:
  176.  
  177.         [u/][d:][filename][.[ext]]
  178.  
  179.         where  u   is  an  optional  user  area prefix. It is a
  180.    decimal  number  from  0  to  31,  and  if  present, must be
  181.    followed  by  a slash (/) character. User areas greater than
  182.    15  should  be used with care, as they cannot be accessed by
  183.    any of the resident CCP (Console Command Processor) commands
  184.    of CP/M, such as USER, TYPE or ERA.
  185.  
  186.                d   is  an  optional  drive  designator. It is a
  187.    single  character  in  the  range of A to P, and if present,
  188.    must be followed by a colon (:).
  189.  
  190.                filename  is  a  string  of  0  to 8 characters,
  191.    following the standard CP/M conventions for filenames
  192.  
  193.                ext   is   a   string  of  0  to  3  characters,
  194.  
  195.    
  196.    Page 3 of 14   83-08-16
  197.  
  198.    
  199.  
  200.    
  201.    Documentation for LU.COM and LRUN.COM
  202.  
  203.    
  204.    following  the standard CP/M naming conventions for filetype
  205.    extensions.
  206.  
  207.    The  period  (.)  after  filename  is  manditory  if  ext is
  208.    specified,  and  optional  otherwise.  The  names  "xyz" and
  209.    "xyz." are equivalent.
  210.  
  211.    Ambiguous  operands  are  those which contain the characters
  212.    "*"  or "?" in the filename or extension fields. Examples of
  213. |  valid filespec operands are:
  214.  
  215.     foo.bar
  216.     3/b:test.fil
  217.     3/test.fil
  218.     b:test.*
  219.     test.fil
  220.     test.
  221.     test
  222.     z
  223.     -z.
  224.     comm?nd
  225.     0/
  226.     b:
  227.     5/a:
  228.  
  229.    Note in the example "-z." the period, though not required by
  230.    the  syntax  of  a  filename,  is  essential  to prevent the
  231.    operand from being mistaken as the invalid operator "-z".
  232.         What  action  is  taken  upon  the operand depends upon
  233.    which operator most recently preceded it. If no operator was
  234.    entered, or an invalid one, or one that expects no operands,
  235.    the  operand  will draw an error message, but will otherwise
  236.    be ignored.
  237.         When   running   interactively,   LU  prompts  for  the
  238.    operators  and operands. You can type as many inputs as will
  239.    fit  on the line, separating them with spaces. The end of an
  240.    input  line  has  no  special  significance. The most recent
  241.    operator remains in effect, and the next line can begin with
  242.    additional operands for it.
  243.  
  244.         The prompt displayed for each input line has this form:
  245.  
  246.         -m u/d:>
  247.  
  248.         where  m  is the current operator in effect
  249.                u  is the current user number in effect
  250.                d  is the current default drive
  251.  
  252.         For  example  the  prompt  might  be  "-E  0/A:>". This
  253.    indicates  that the -e operator is in still in effect; if an
  254.    operand  is  entered it will be interpreted as the name of a
  255.    member  file to be Extracted from the library. It also shows
  256.    that  the current user number is 0, and the current drive is
  257.    A:.  Any operands which are entered without an explicit user
  258.    or  drive  will  use  these  defaults.  The  defaults can be
  259.    changed at any time with the -u operator, discussed below.
  260.  
  261.    
  262.    Page 4 of 14   83-08-16
  263.  
  264.    
  265.  
  266.    
  267.    Documentation for LU.COM and LRUN.COM
  268.  
  269.    
  270.         When  the  program  first  starts up, the prompt begins
  271.    with  "-?",  which means no operator is currently in effect.
  272.    In  this  case,  the  only  valid  input is an operator. Any
  273.    operand will be rejected.
  274.  
  275.    
  276.  
  277.    
  278.  
  279.    
  280.  
  281.    
  282.  
  283.    
  284.  
  285.    
  286.  
  287.    
  288.  
  289.    
  290.  
  291.    
  292.  
  293.    
  294.  
  295.    
  296.  
  297.    
  298.  
  299.    
  300.  
  301.    
  302.  
  303.    
  304.  
  305.    
  306.  
  307.    
  308.  
  309.    
  310.  
  311.    
  312.  
  313.    
  314.  
  315.    
  316.  
  317.    
  318.  
  319.    
  320.  
  321.    
  322.  
  323.    
  324.  
  325.    
  326.  
  327.    
  328.    Page 5 of 14   83-08-16
  329.  
  330.    
  331.  
  332.    
  333.    Documentation for LU.COM and LRUN.COM
  334.  
  335.    
  336.                        SUMMARY OF OPERATORS
  337.    In this discussion, the "open library" refers to the library
  338.    name  specified  as  the  current  library  by  using the -o
  339.    operator  discussed  below.  The default name LIBRARY.LBR is
  340.    used whenever an operator needs an open library, but none is
  341.    currently open.
  342.  
  343.         -a   add   files   to  library.  -a  causes  subsequent
  344.    operands  to be treated as the names of files to be added to
  345.    the  open  library.  Ambiguous operands match all disk files
  346.    which   qualify   according   to   normal   CP/M   wild-card
  347.    conventions,  except those with a filetype of .LBR. Explicit
  348.    user  or  drive specification on an operand causes that area
  349.    to be searched for the file(s) instead of the defaults.
  350.  
  351. |       -b   Buffer  size set. -b reads the subsequent operator
  352. |  as the size (in sectors) to allocate  for a disk I/O buffer.
  353. |  Normally,  this  operator  need  never  be  used, since a 64
  354. |  sector buffer is assumed if not specified. A full discussion
  355. |  of  buffer  size  considerations, and their relation to disk
  356. |  access   speed   is  beyond  the  scope  of  this  document.
  357. |  Generally,  a  larger  buffer  will  increase  the  speed of
  358. |  adding,   extracting   and  reorganizing,  but  this  widely
  359. |  variable with different hardware.
  360. |       Bear  in mind that a large I/O buffer will decrease the
  361. |  size of the largest library directory which can be processed
  362. |  by  the  program,  since  the  directory buffer competes for
  363. |  system  memory  with the I/O buffer. Conversely, setting the
  364. |  buffer  to  a  value  less than 64 will increase the maximum
  365. |  directory  size.  This  operator can only be used at program
  366. |  startup,  before the first library is open. Its operands are
  367. |  not  filespec  operands,  but  simple integer numbers in the
  368. |  range 1...255.
  369.  
  370.         -c   close  the  open  library.  If  a library has been
  371.    opened  with  the  -o  operator,  or  if the default library
  372.    LIBRARY.LBR  has  been  opened  by  some  other operator, -c
  373.    causes  it  to  be  closed.  Otherwise,  it  has  no effect.
  374.    Normally this operator need never be entered, since any open
  375.    library is automatically closed at the end of the session or
  376.    when  another  one  is opened. It is provided for situations
  377.    where  it  is  desired to change disk volumes without ending
  378.    the  LU  program.  Before  removing  the disk containing the
  379.    library  file,  it  must  be  closed.  After  mounting a new
  380.    volume,  the  -U operator (see below) should be used. The -c
  381.    operator expects no operands.
  382.  
  383.         -d   delete  files  from  library. -d causes subsequent
  384.    operands to be treated as the names of members to be deleted
  385.    from  the  open  library.  Ambiguous names match all members
  386.    which qualify. User and drive specifications on operands are
  387.    ignored,   since   the  library  members  are  obviously  in
  388.    whichever area contains the open library.
  389.  
  390.         -e   extract  files  from library. -e causes subsequent
  391.    operands  to  be treated as the names of members in the open
  392.  
  393.    
  394.    Page 6 of 14   83-08-16
  395.  
  396.    
  397.  
  398.    
  399.    Documentation for LU.COM and LRUN.COM
  400.  
  401.    
  402.    library  to be extracted to normal free-standing CP/M files.
  403.    The  original  copy  is  not  deleted,  and  remains  in the
  404.    library.
  405.  
  406.    Ambiguous  operands  extract all members which qualify. User
  407.    or  drive  specifications  on  member names cause the output
  408.    file(s)  to  be placed in the specified area rather than the
  409.    default.  Any  existing  file  with  the  same  name will be
  410.    overwritten  unless  it is protected by having its Read/Only
  411.    attribute set on.
  412.  
  413.         -l   list  current library map. -l causes the directory
  414.    of  the open library to be listed on the console. The member
  415.    names are displayed, along with their index (starting record
  416.    within   the   library)  their  size  in  sectors,  and  the
  417. |  internally calculated CRC value.
  418.      Also, information is displayed about the number of sectors
  419.    in  the  library,  and  how  much  space is used and  unused
  420.    (wasted).  The  number  of  active  entries (members) in the
  421.    directory  is  also  displayed,  as well the number deleted,
  422.    free  for  future  use,  and  the  total  number. This helps
  423.    determine  whether  the  library needs to be re-organized to
  424.    free  unused  space  and  deleted  entries.  The operator -l
  425.    expects  no  operands,  so  the next input should be another
  426.    operator.
  427.  
  428. |       -n   Name  a  member. -n causes each subsequent operand
  429. |  to be treated as a request to change the name of a member in
  430. |  the  open  library.  Since both the new and old names of the
  431. |  member  must  be  given,  a special double operand format is
  432. |  used.   It  is  essentially  two  filespec  operands  "glued
  433. |  together" with an equals sign. For example:
  434. |                      newname.typ=oldname.typ
  435. |  would  cause the member OLDNAME.TYP to have its name changed
  436. |  to  NEWNAME.TYP.  If  the  old name is not found in the open
  437. |  library,  or  if the new name is that of an existing member,
  438. |  no  rename  takes  place,  and  an  appropriate  message  is
  439. |  displayed.  Operands  which  do  not  conform to the special
  440. |  <new>=<old> syntax will also draw an error message.
  441.  
  442.    
  443.  
  444.         -o   open a library. -o causes the following operand to
  445.    be  treated  as  the name of a library file to be opened for
  446.    use  with  subsequent operators. If there is already an open
  447.    library,  it is first closed, and the new one opened. If the
  448.    new  library  does not exist, it is created with no members.
  449.    Ambiguous   names   are   not   allowed.   User   and  drive
  450.    specification can be used to override the current area.
  451.         The  file  type  may  be specified, but if not entered,
  452.    defaults  to  .LBR  which  is strongly suggested as the file
  453.    type  for  all  library files. You will recall that files of
  454.    type  .LBR  are  ignored  by the wildcard matching of the -a
  455.    (add)   operator.   This   prevents   libraries  from  being
  456.    accidentally  added  to other libraries, or to themselves; a
  457.    situation  not  unlike  trying  to  drive a truck up its own
  458.  
  459.    
  460.    Page 7 of 14   83-08-16
  461.  
  462.    
  463.  
  464.    
  465.    Documentation for LU.COM and LRUN.COM
  466.  
  467.    
  468.    tailpipe.
  469.         If  for  some  reason  you  want  to add one library to
  470.    another,  be my guest, but you will have to specify the name
  471.    without * or ? characters when adding it.
  472.  
  473.         -r   reorganize  library.  -r causes the currently open
  474.    library  to  be  reorganized. First, the directory is sorted
  475.    into  alphabetical  order,  and  then all active members are
  476.    copied  to  a  work  library  which is opened on the default
  477.    user/drive. The size of the directory may be changed at this
  478.    point  by  specifying a greater or smaller number of entries
  479.    than were present the old library. The directory will always
  480.    be  made  large  enough to contain all the active members of
  481.    the  old  library,  so  it is safe to enter a size of "1" to
  482.    make  the  directory  as  small as possible. (See Specifying
  483.    Directory Sizes below.)
  484.         When  reorganization  is  complete,  the old library is
  485.    deleted  from  its  user/drive area, and the work library in
  486.    the  default area is renamed to the name of the old library.
  487.    No  backup  copy  is retained. The newly reorganized library
  488.    remains open for use with subsequent operations.
  489. |       Note that although the newly reorganized library always
  490. |  ends up in the default area, the default area can be changed
  491. |  with  the  -u  operator.  (Do  this first, before using -o.)
  492. |  Also,  the  old  library can be opened in any area, by using
  493. |  explicit  user/drive  specifications. The net result is that
  494. |  it is possible to reorganize a library from any desired area
  495. |  to  any  other  area.  Reorganizing a library to a different
  496. |  drive  is  usually a much faster operation, and is manditory
  497. |  if  the  current disk does not contain enough free space for
  498. |  the old and work libraries at the same time.
  499.  
  500.    
  501.         -u   Use new default area. The -u can be used to change
  502.    the  default  value  for user number or drive. It causes the
  503.    user  prefix  and  drive spec of the following operand to be
  504.    used  as  the new default area. If the following operand has
  505.    no  user prefix, or no drive spec, the corresponding default
  506.    is  not  changed.  (The  filename  and  ext  sections of the
  507.    operand  must  be  absent.)  If  a  change is made, any open
  508.    library  is first closed, and the disk system is reset. Thus
  509.    feature allows newly mounted disk volumes to be accessed for
  510.    writing;  CP/M  causes new volumes to be Read Only until the
  511.    program  performs  a disk system reset. The -u operator also
  512.    affects  which area will be used for the work library during
  513.    reorganization. See the -r operator above.
  514.         Note:  If directed I/O is active (See advanced features
  515.    below)  the  -u  operator is treated as invalid. Due to some
  516.    unfortunate  assumptions  in  the  C  run-time  package, the
  517.    default  drive  cannot  be safely changed while directed I/O
  518.    files are open, and the BDOS gets confused by the disk reset
  519.    under these conditions.
  520.  
  521.         -x   eXit program. -x causes the interactive mode to be
  522.    turned  off,  which  means that the input line containing it
  523.    will  be  the  last line scanned by the program. It does not
  524.  
  525.    
  526.    Page 8 of 14   83-08-16
  527.  
  528.    
  529.  
  530.    
  531.    Documentation for LU.COM and LRUN.COM
  532.  
  533.    
  534.    cause   immediate  program  termination,  and  if  any  more
  535.    operators follow it on the same line, they will be processed
  536.    normally. The program terminates only after the current line
  537.    is fully processed. Any open library is then closed, and the
  538.    user  number  and default drive are reset to the values they
  539.    had  when  the  program  was originally invoked. To preserve
  540.    compatability  with  earlier versions, the program will also
  541.    end if an empty input line (carriage return alone) is typed.
  542.  
  543.                     SPECIFYING DIRECTORY SIZE
  544.  
  545.         Whenever  an  old library is opened, the directory size
  546.    is displayed as follows:
  547.  
  548.     Old library LIBRARY.LBR has 32 entries, 5 free.
  549.  
  550.         This  means that 5 more members may be added before the
  551.    directory  becomes  full.  When  the  directory  is full, -a
  552.    becomes  an  invalid  operator,  and  the  library  must  be
  553.    reorganized to add any more members.
  554.         When  a library is created for the first time, the user
  555.    is prompted like this:
  556.  
  557.     New library COMMAND.LBR. Allow how many entries?_
  558.  
  559.         Any number from 1 to 65535 is valid. The actual maximum
  560.    is  determined by the amount of free memory available on the
  561.    system in use. Directory size will be rounded up to the next
  562.    whole  sector  necessary  to  contain  the number of entries
  563.    requested.  This  number  will  remain  in  effect until the
  564.    library is reorganized. Since the directory itself counts as
  565.    an  entry,  one  entry  is added to your response before the
  566.    size  is calculated. Therefore just enter the maximum number
  567.    of  member  files  you  want  the  library  to be capable of
  568.    holding.
  569.         The  maximum number of member files is also constrained
  570.    by  the  amount  of  available disk space. If the disk space
  571.    runs  out  during  an  add,  the  name  is  not added to the
  572.    directory.  If  a  multiple  add  is  in progress, due to an
  573.    ambiguous  operand, the remaining qualifying files are still
  574.    added  if possible. If any of them is small enough to fit in
  575.    the  remaining  disk space, it will be added. If any sectors
  576.    were  written  by  a  failed  add  attempt,  and  then never
  577.    utilized,  they  remain  as  unused sectors, and the library
  578.    should be reorganized.
  579.  
  580.    
  581.  
  582.                      PARAMETER DRIVEN METHOD
  583.  
  584.         All of the information needed for a maintenance run may
  585.    be specified on the command line. The operators and operands
  586.    are  entered, separated by spaces, after the LU command, and
  587.    the operations will take place without console intervention,
  588.    except  in  the  case  where  the  directory  size for a new
  589.    library is requested. The syntax is:
  590.  
  591.    
  592.    Page 9 of 14   83-08-16
  593.  
  594.    
  595.  
  596.    
  597.    Documentation for LU.COM and LRUN.COM
  598.  
  599.    
  600.  
  601.     LU <opr> [<opd> [<opd> ...]] [<opr> [<opd> ...]...
  602.  
  603.     where square brackets indicate optional parameters, and:
  604.         <opr> is any operator.
  605.         <opd> is any operand.
  606.         ...   indicates  that the preceding parameter may occur
  607.    multiple times.
  608.         Any  names  occurring  prior  to the first operator, or
  609.    following  an  operator  which does not expect operands, are
  610.    ignored.
  611.  
  612. |                          CRC CHECKING
  613. |
  614. |       Whenever  a  new  member is added to a library, a value
  615. |  called  the CRC (Cyclic Redundancy Check) word is calculated
  616. |  and  stored in the member's directory entry. When the member
  617. |  is  extracted  from  the  library,  the  calculation is done
  618. |  again,  and compared with the saved value. If the two values
  619. |  do  not  match,  it  is  an  indication  that the member was
  620. |  damaged in some way while it was in the library. The extract
  621. |  will  still  be  performed,  but  a message warning that the
  622. |  extracted copy is questionable will be displayed.
  623. |       This feature is especially valuable for libraries which
  624. |  have been created on another system and transmitted by phone
  625. |  (possibly  several  times) before you receive them. It helps
  626. |  insure  that  the extracted files are faithful reproductions
  627. |  of   the  files  originally  inserted  before  transmission.
  628. |  Members  added  by LU versions prior to 2.20 do not have CRC
  629. |  words.  The  CRC check will be bypassed when one of these is
  630. |  extracted.
  631. |       The  CRC  word  of the directory itself is checked when
  632. |  the library is opened. A message warning of a CRC error will
  633. |  be displayed at that time. Libraries modified by LU versions
  634. |  prior  to 2.20 have no directory CRC word, and the CRC check
  635. |  will  usually  be bypassed. If a warning does occur, it will
  636. |  not adversely affect operation.
  637. |       When  a library is reorganized, CRC words will be added
  638. |  to  all  members,  if  not  present.  CRC errors which occur
  639. |  during  reorganization  will cause the program to abort. The
  640. |  damaged  member  must  be  deleted before the library can be
  641. |  reorganized.
  642. |       Libraries  created by this version of LU can be read by
  643. |  all  previous  versions. The CRC values inserted will simply
  644. |  be ignored by early versions of the program.
  645.  
  646.    
  647.  
  648.    
  649.  
  650.    
  651.  
  652.    
  653.  
  654.    
  655.  
  656.    
  657.  
  658.    Page 10 of 14   83-08-16
  659.  
  660.    
  661.  
  662.    
  663.    Documentation for LU.COM and LRUN.COM
  664.  
  665.    
  666.                         ADVANCED FEATURES
  667.  
  668.         Input  from  BDS C "pipes" or ordinary sequential files
  669.    is  also  possible. The filename is specified on the command
  670.    line  preceded  by a "<" character and no intervening blank.
  671.    Example:
  672.  
  673.     LU <CONSOL.DUP
  674.         reads the contents of the file CONSOL.DUP and uses each
  675.    line  of  the  file  as  if  it had been typed at the normal
  676.    console   by  the  interactive  method.  In  this  case,  no
  677.    operators  or  operands  may  be present. Console output may
  678.    also  be  redirected  by  specifying  an  output file on the
  679.    command  line  after  the  character  ">".  This  applies to
  680.    parameter  driven as well as interactive (including "piped")
  681.    input. Examples:
  682.  
  683.     LU -O 3/SPECIAL -A B:ZOT.COM >20/C:LOGFILE.OUT
  684.         would  add  the file zot.com from drive b, current user
  685.    area,  to  the  library  special.lbr,  in user area 3 on the
  686.    default  drive.  Console  output  would be written to a file
  687.    called logfile.out in user area 20 on drive c. The placement
  688.    of  the  output  name on the line does not matter and except
  689.    for  turning  on  redirected  output,  it  is ignored by all
  690.    operators.
  691.  
  692.     LU <BATCH.IN >B:RECORD.DOC
  693.         would  take interactive commands from the file batch.in
  694.    and  write  console  output  to  a file called record.doc on
  695.    drive B.
  696.  
  697.         Normally,  console  file  output  is also echoed on the
  698.    real  console,  except  when input is also redirected, as in
  699.    the  last example. To force visible console output when both
  700.    an  input  and  output  file  are  used,  the  ">" character
  701.    preceding  the output file name may be changed to a "+" like
  702.    this:
  703.  
  704.    LU +RECORD.DOC <BATCH.IN
  705.         This  would  have  the  same  effect  as  the  previous
  706.    example, except that message output would also be visible on
  707.    the console.
  708.  
  709.    
  710.  
  711.    
  712.                              CAUTIONS
  713.  
  714.        The  importance  of  keeping  backup  copies of all disk
  715.    files,  and  especially libraries, cannot be overemphasized.
  716.    By  using  library files, the user is exposed to the dreaded
  717.    all-the-eggs-in-one-basket  syndrome.  That is, if something
  718.    happens  to the library file, particularly the directory, it
  719.    may  be  beyond  the  capabilities  of even a CP/M wizard to
  720.    restore the member files. The situation is made particularly
  721.    sticky by the fact that the the directory must be updated in
  722.  
  723.    
  724.    Page 11 of 14   83-08-16
  725.  
  726.    
  727.  
  728.    
  729.    Documentation for LU.COM and LRUN.COM
  730.  
  731.    
  732.    place as members are added or deleted.
  733.         Precautions  have been taken to minimize this risk. For
  734.    one  thing,  the  directory  is  read  into  memory when the
  735.    library  is  first  opened,  and  is only written back if it
  736.    differs  from  the copy on the disk. Operations which change
  737.    the  directory  are:  adds,  deletes, and the sort operation
  738.    which  is  done  before reorganization. If only extracts (or
  739.    LRUN executions) are done, the directory is never rewritten,
  740.    and  the  .LBR  file  may  be write protected if desired, by
  741.    using  the  CP/M  STAT  command. When a read-only library is
  742. |  open, all LU operators except -l, -b, and -e become invalid.
  743.         As  another  precaution, the entire empty directory  is
  744.    allocated  and  written  to disk when a new library is first
  745.    created. This insures that there will always be enough space
  746.    on disk for the number of directory entries requested at the
  747.    time  of  creation.  The disk space may run out while adding
  748.    member  files,  but there will always be enough room on disk
  749.    to update the directory once it is successfully created.
  750.         The  fact that only the memory copy of the directory is
  751.    modified  until the file is closed may come in very handy if
  752.    you  mistakenly  delete a member file and recognize it right
  753.    away.
  754.         For example, suppose you make the mistake of typing "-d
  755.    *.*". Briefly, your heart sinks, as the "Deleting:" messages
  756.    are  displayed  and  all the member names zip into oblivion.
  757.    Don't  panic. Only the memory copy of the directory has been
  758.    modified.  When  the  -D  0/A:>  prompt  returns, do not hit
  759.    RETURN. Instead, abort the program with Control-C. This will
  760.    cancel  the  program without updating the directory, and the
  761.    original members will still be present.
  762.         Here  is  another  caution.  Since the entire directory
  763.    must  fit in memory for a library to be successfully opened,
  764.    it  is  possible  that  a  huge  directory created on a your
  765.    system will be too large to fit in memory if read on another
  766.    system will less memory. This should not be a problem with a
  767.    library of under a hundred entries.
  768.         To  give  you an idea of how much elbowroom you have to
  769.    work with, LU displays the highest memory location used each
  770. |  time  it terminates. This will vary depending on the size of
  771. |  the  disk  I/O buffer, as well as the largest directory used
  772. |  during operation, and will be slightly higher if interactive
  773.    operation   was   used,  since  a  console  buffer  must  be
  774.    allocated.
  775.      It  does not include the stack, which grows down from high
  776.    memory,  and  is allowed about a thousand bytes of space for
  777.    subroutine parameters and temporary work areas.
  778.  
  779.    
  780.  
  781.    
  782.  
  783.    
  784.  
  785.    
  786.  
  787.    
  788.  
  789.    
  790.    Page 12 of 14   83-08-16
  791.  
  792.    
  793.  
  794.    
  795.    Documentation for LU.COM and LRUN.COM
  796.  
  797.    
  798.                          THE LRUN COMMAND
  799.  
  800.         The  LRUN  command was created for those of us who have
  801.    lots  of command files we like to keep on line all the time.
  802.    We  all  have some favorite little .COM files are very small
  803.    programs,  but  having  a  lot  of them on disk eats up file
  804.    space  at an alarming rate due to the fixed CP/M block size.
  805.    Put them all into a library called COMMAND.LBR using LU. You
  806.    can  then  run  any  .COM  file directly from the library by
  807.    saying:
  808.     LRUN <followed by normal command line just like always>
  809.        The full syntax of LRUN is:
  810.  
  811.     LRUN [-<lbrfile>] <commember> [<parameters>]
  812.  
  813.    Where:
  814.  
  815.         <lbrfile>  is  the  library  to be searched. The square
  816.    brackets  around  -<lbrfile>  indicate it is optional. The -
  817.    character tells LRUN that what follows is a library name. It
  818.    is not an actual part of the name. Don't leave a space after
  819.    the  -. If the first parameter doesn't begin with - then the
  820.    default  library  COMMAND.LBR  is  used.  If a drive spec is
  821.    given,  such as B:, then only that drive is searched for the
  822.    library.  If  no  drive  spec  is given, the current area is
  823.    searched first, and if no library of that name is found, the
  824.    default  area is searched before giving up. The default area
  825.    is set to 0/A: in the distribution object code, but this can
  826.    be  changed to something more appropriate for your system by
  827.    changing two equates in the source program and reassembling.
  828.    LRUN  does  not otherwise support user numbers, and will not
  829.    recognize the "u/" syntax on its parameters.
  830.         If a name, but no type is entered, .LBR is assumed.
  831.  
  832.         <commember>  is  the  name of the command to be run. No
  833.    drive  spec is used here. The type defaults to .COM and need
  834.    not be entered.
  835.  
  836.         <parameters>  is  a the normal (possibly empty) list of
  837.    parameters  which  the  .COM  file  expects  to  find on the
  838.    command  line  when  it  is  run. This list is parsed to the
  839.    required  file  control  blocks and command line area before
  840.    execution  begins,  so  the  program  will not be aware that
  841.    anything  cute  is  going  on.  (Thanks  to  Ron  Fowler for
  842.    supplying the code which makes this possible.)
  843.  
  844.    
  845.  
  846.                           LRUN EXAMPLES
  847.  
  848.     LRUN ED FOO.BAR
  849.         the  file  ED.COM is searched for in COMMAND.LBR on the
  850.    current  drive,  or the A: drive. If found, ED.COM is loaded
  851.    from  the  library,  and  FOO.BAR  is  passed  to  it  as  a
  852.    parameter.
  853.  
  854.    
  855.  
  856.    Page 13 of 14   83-08-16
  857.  
  858.    
  859.  
  860.    
  861.    Documentation for LU.COM and LRUN.COM
  862.  
  863.    
  864.     LRUN -C:SPECIAL LU -O COMMAND -A A:*.COM
  865.         the file LU.COM is searched for in SPECIAL.LBR on the C
  866.    drive.  If  found,  LU.COM  is  loaded,  and the strings -O,
  867.    COMMAND, -A, and *.COM are passed to it as parameters.
  868.  
  869.     LRUN - -ZIP
  870.         the file -ZIP.COM is searched for in COMMAND.LBR on the
  871.    current drive, or the A: drive. If found, -ZIP.COM is loaded
  872.    and  executed  with  a  blank parameter list. Since -ZIP.COM
  873.    begins  with a -, the extra - followed by a space was needed
  874.    to act as a place-holder for the library name. Compare with:
  875.  
  876.     LRUN -ZIP
  877.         the  library  -ZIP.LBR  is looked for, but nothing else
  878.    happens, because no command was specified.
  879.  
  880.     LRUN
  881.         with  no  parameters  at  all,  causes a screen of help
  882.    information to be displayed as a memory refresher.
  883.  
  884.    
  885.  
  886.         Please   report   any   problems   or  suggestions  for
  887.    enhancement  to  me  via  CompuServe  CP-MIG  or EMAIL, user
  888.    number  70160,120;  or  by  phone  at (201) 935-4087, voice,
  889.    evenings (eastern time) or weekends.
  890.  
  891.                        Gary P. Novosielski
  892.  
  893.    
  894.  
  895.    
  896.  
  897.    
  898.  
  899.    
  900.  
  901.    
  902.  
  903.    
  904.  
  905.    
  906.  
  907.    
  908.  
  909.    
  910.  
  911.    
  912.  
  913.    
  914.  
  915.    
  916.  
  917.    
  918.  
  919.    
  920.  
  921.    
  922.    Page 14 of 14   83-08-16
  923.  
  924.  
  925. to  find on the
  926.    command  line  when  it  is  run. This list is parsed to the
  927.    required  file  control  blocks and command