About collaborations ZIRUS (Russia-Sibiria-Baikal) and TUNES

[ZIRUS]

This is a multi-part message in MIME format.

--------------3D257C7B6547
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dear friend,
  we have read your home pages about TUNES project. Your idea is
beautiful. 
  For long time we have being developed an Integrated Software
Environment
  (ZIRUS) as a new platform for software development and implementation.
  We consider our ideas are closed to your project. We send you our
  draft about ZIRUS. 
   We'd like to refer to your publications about TUNES in our papers. 
  Could you e-mail us about your basic publications and more closed
another
  projects. 
  Merry Cristmas and Happy New Year to you! 
  
      Sincerely  Nickolay Abasov, Olga Oskina.(Irkutsk)

--------------3D257C7B6547
Content-Type: text/plain; charset=us-ascii; name="Z2.TXT"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="Z2.TXT"



      The conception of ZIRUS is:

      1. Representation of all system elements on logical level
 that is the base for external (for users) and internal (for
 a hardware platform)  projections  of these  elements.

      2. On logical level the system elements are represented as
set of connected SEGMENTs (memory domains)  with different structure,
allowing to describe hypertables, hyperlists, hypercode  etc.

      3. The objects  are represented as a set of SEGMETs describing
both data structures and methods.

      4. Logic of program moduls are described by objects of
specific  structure with translation and implementation methods.

       5. Including in knowledge base logic-functional links
allows to influence upon a process of program creation and implementation.

       6. Evolutionary interrelated development of the conception,
 software environment and applications by a mobile team.

        The exprience of software development of ZIRUS
               (from 1990  to  1994)

    A model  of  a system is described in the basis given by a
set of interrelated segs interconnected to form a joint global
data  medium.  Various  types of relations between segs may be
organized.  Such relations give the possibility  to  construct
complex  data models and organize different types of access to
them.
    The description  of  a  seg's  structure  is  also  a  seg
containing the complete information on  the  configuration  of
elementary fields and their types.  The description of a seg's
field includes:  the field's type  (integer,  real,  symbolic,
etc.),  relations  with  other  segs,  the relative address of
location of the field in the seg.  The list of types of fields
is a seg and can easily be extended and modelled.
    - technique for  processing  segs  based  on  usage  of  a
special  technology  ZIRUS,  a  standard  algorithmic language
(e.g. C) being employed;
    - technique  based on compiling trivial programs (definite
type segs containing sequences of instructions  with  simplest
logic of transformations);
    - technique of usage of OLFIS.
    The 3 basic tool packages (TP) have already been developed
intended for:
    - control of  segs  in  the  on-line  memory  (OM);
    - control  of loading program blocks;
    - organizing the data storage in the base of segs.
    In addition,  the following tool packages have  also  been
developed:
    - aids of dialogue mode control (menu; panels; graphic and
text editors, etc.);
    - multifunctional table editor  (applicable  also  to  any
segs);
    - transformation of segs;
    - interfaces with other data formats;
    - etc.
    A few   large  ZIRUS-based  network  complexes  have  been
proposed for practical exploitation:
    - for  business  accounting  and  industrial  planning  at
cable-line manufactures;
    - for  the  36-hour  planning  of  cargo transportation by
trucks for a large company;
    - for   statistical   processing  the  hospital  patients'
anamnesis data;
    - for military applications.

    Within of  frames  of  ZIRUS  a  conception  and the first
version of a language OLFIS have been elaborated.  This allows
compiling  software  programs determined as states of the data
structures embedded in the ZIRUS environment.
    To the end of making the ZIRUS environment internally full
a language OLFIS has been developed and included as  the  next
tecnologies:
    - functional programming (programming at  the  expence  of
introducing and decoding definitions at different conditions);
    - description of logic in the form of functionally-bounded
modules (structural elements of the language);
    - possibility of 1 :  n structuring transformations:  from
one  external  module's  representation  to  a set of internal
representations, and vice versa, from one internal to a set of
different external representations;
    - simulation  of  both  external   and   internal   module
representations in the form of diverse-type segs;
    - adjustability of language syntax with the aid of special
OLFIS dictionaries;
    - module's  internal  code  includes  different   elements
defining   the   internal   logic  of  the  module  (lists  of
parameters,  sequences,  constants,  functional and seg terms,
etc.) and contains information links with the other modules to
be retrieved and the data structures.
    - possibility  of constructing the event-type control with
the use of processing the modified data;
    OLFIS's 3  components are:  (i) the translator of external
representation modules into internal ones;  (ii) the executing
interpreter of the internal representation modules;  (iii) the
visualizer     for     internal-to-external     representation
transformation. Its 2 basic  structural  components  are:  (a)
external and (b) internal module forms.
    The conception  of  OLFIS  implementation (likewise of any
interpreter) assumes that all above components be included  in
ZIRUS, their potential further development being foreseen.
    The following   functions  of  OLFIS  are  basic  built-in
functions:
    - SEG() - intended to modify data content of segs;
    - ZIR() - execute an OLFIS's module,  whose name is either
defined  algorithmically  or is given from the slot of the seg
containing the module's name.

       PROCESSING LOGIC-FUNCTIONAL LINKS (LFLs)
       AND BASIC SCHEME OF PARALLEL PROCESSING

    Operative tracing  LFLs and modification of such LFLs were
principal objectives,  for which solving the OLFIS  conception
was developed. LFLs are some independent (as far as control is
concerned) modules which may be made active  independently  of
the basic logic of programs.
    - selection of active LFLs for  the  set  of  data  to  be
edited, LFLs being selected from the whole LFL set;
    - processing active LFLs,  fail LFLs being displayed,  and
obtaining  a  list  (special seg) of LFLs (specifying definite
regulations,  e.g.  paragraphs of an  agreement)  resulted  in
failures.
    Existential and universal  quantifiers  are  specified  as
operators in the external structure of modules and may be used
for describing complex LFLs.  The mechanism of firing LFLs may
be  used for maintaining the integrity of the database and the
system as a whole.
    OLFIS allows one to describe the logic of execution, which
may be used for parallelizing large programs and represents  a
set  of independent processes (main modules of OLFIS stored in
the module knowledge base).
    Consider this problem in the aspect of transfering control
by modifying data.  Parallelization in terms of ZIRUS  implies
the following coordinated system of processes.
    1) The head module is  executed,  and  it  bases  (writes)
output  values  into  the corresponding locations of data segs
with the help of the function SEG.
    2) The  controlling  module  defines  a new list of active
modules for one list obtained.  It solves the converse problem
of defining the lost of modules, which have access to modified
data fields.
    3) A  new list of main modules obtained may be comlpletely
parallelized for independent execution of respective modules.
    4) For each new obtained module of the list the processing
procedures are executed starting from Step 1.
    This approach  allows  to  parallelize the problem into an
arbitrary number of simultaneously executed modules.


             


--------------3D257C7B6547--