Conference turris::languages

131.0. "Burroughs LINC !" by TIPPLE::HANSON (We came, We saw, We passed out cold!) Wed Mar 18 1987 12:34

    
    
    
    After seeing my reply to a note on the Burroughs (Unisys) product, LINC,
Allen Peng from Taiwan SWS mailed a note to me asking for more information.
I thought that it might be useful to post this reply, along with other
notes that I have, in this conference.  While this is not a thorough
analysis of the product, it's certainly a start.    

It's a bit long, so if you're interested in reading it, it might be useful
to extract it.  There is a lot of good information here on LINC, but inasmuch
as LINC is comprehensive, there is no good way to tell the complete story.
Therefore, if you have any other questions or comments, perhaps it would
be a good idea to contact me, much as Allen did.

I'll be most happy to entertain any other questions on the LINC product.

Bob Hanson   NY/NJ Vol. SWS
---------------------------

Hi, Bob
       
This is Allen Peng from Taiwan SWS, sorry to interrupt you.   I have read
your notice in the VAX Cobol Generator Notebook,  and I am really glad to
hear we finally have a LINC expert in the E-net.  In here, Taiwan, the major
competitor of our 4GL products is LINC.  Burroughs uses LINC as his main
force, and his main target is DEC.  Although I know our own 4GL products
very well, I don't have enough information to know LINC better.  I have
several questions about LINC, if not spending you too much time, can you
give me some comments?  (In fact, these question s were in my mind for
over one year, and I didn't even know whom should I ask?  Thank god!
Finally....)  Thank you in advance.

        
1. Is LINC just a Cobol generator or a complete 4GL product?              
                     
  "No, LINC is not just a Cobol generator, although that is one part of
   it's functionality.  According to most "formal" definitions, LINC is
   indeed a 4GL, inasmuch as it usually provides at least 10:1 product-
   ivity gains over coding the same application in a standard language.

  "From a single definition language (LDL - see below), a programmer has
   the ability to define the network interface, a message control system,
   screen images, user messages, the Cobol application, and the database.
   All of these generated parts are based on standard Burroughs software
   that has been around for years.  The only real difference now is that
   there is a 4GL interface to tie them all together easily.
                                                              
  "The distinction between LINC and most 4GL products available today is
   that most 4GL's generate "proprietary" code (or non-Cobol, non-Pascal,
   etc.), machine code, or parameters that are analyzed and performed by
   a run-time executable image.  LINC generates Burroughs NDL, GEMCOS,
   DMSII, and Cobol code, and those products are all quite mature and
   well-respected in the Burroughs community. There are many advantages
   and disadvantages to this, depending on your particular viewpoint.

  "Bear in mind that there isn't really a good definition of what a 
   4GL is, except that it should return at least 10:1 productivity gains
   over standard, hand-coding in, say Cobol and database.  By this criterion,
   LINC can indeed be called a 4GL FOR MOST INSTALLATIONS (!) More later."

2. In LINC, there are some terms such as, "components", "events", and 
   "profiles".  What does these mean from a traditional programmer's view?
                                                  
  "Every coding language uses its own jargon or expressions for the same
   old stuff that we've been doing for years, and this is no exception
   with LINC.

  "Although components, events, and profiles DO have physical attributes
   on disk [i.e., the way that each is stored and what it does], these
   terms are most often used when talking about the *design* of a system.

  "A COMPONENT most closely resembles a master file on disk.  Examples
   would be a <Personnel> master file, an <Inventory> master file, a
   <Customer> master file, etc.  In other words, the information stored
   in a component should have a relatively low volume of change or update,
   and reflects an important piece of the business being modeled in the
   application.  A customer, once his record is entered into the component,
   has little modification done to his record except for low volume update.
   (By that, I am referring to updates to change a customer address, the
    safety stock quantity for a product, or an employees department number.)
   By default, you can Add/Change/Delete/Inquire on these records, but they
   are not really *transactions* as Burroughs sees them.

  "An EVENT, on the other hand, is a transaction, and usually ties together
   pieces of information from various Components.  It is a snapshot of a
   piece of activity in the system at any given point in time.  A good
   example of an Event might be an Order-Entry line item.  This line item
   is a transaction for an order, using information or key information from
   the Customer component, the Inventory component, and entry from the screen.
   This example can be diagrammed as follows :


            Custs                    Parts                    Price
         (Component)              (Component)              (Component)
         Key = Custno            Key = Partno             Key = Partno/Qty
                     \                 |                        /      /
                      \                |                       /      /
                       \               |______________________/      /
         Order (Event)  \              |____________________________/
         ________________\_____________|_________________________________
         | Order | Line | Custno | Partno || Qty.| Rqst. | Date | Time |
         | Numb. | Numb |  (FK)  |  (FK)  ||(FK) | Date  |      |      |
         |_______|______|________|________||_____|_______|______|______|
                                                                    
                      
  "In this example, static pieces of information such as customers, parts,
   and prices based on the part-number and a quantity have been set up as
   components, whereas the activity or transaction for order entry captures
   the fields shown.  Also in the components, but not shown here, would
   be information such as the customer name and address, the part descrip-
   tion and other attributes, and any other static information.  Using keys
   such as the partno and custno, we can relate a lot of order information
   in a minimal amount of storage space.  Also notice (hint, hint) that
   this is how one should design a relational database, right ?

  "Another interesting design concept using Events in LINC is that of the
   'Level of Activity'.  By this, we mean that in every business, certain
   activities (Event transactions) balance each other out, and by viewing
   all activity for a certain time period, one can easily extract a lot
   of information with respect to, say, Net Balances, Outstanding Orders,
   etc.   This is to say, for example, that Orders are balanced by Shipments,
   money due is balanced by money received, and inventory stock coming into
   a warehouse is balanced by allocating that stock to the shop floor. 
   In this manner, a well-designed LINC system, using Components as the
   basic 'building blocks' of information for a company, can apply Event
   transactions using some of that basic information, and by viewing the
   Events in various ways, one can determine the level of activity across
   all segments of the business.  (Oh, well, I guess you've got to see it!)

  "Now, finally, you have PROFILES.  These can be considered nothing more
   than indexes on a database.  (The name is derived from the fact that
   you can look at the data one way, and then by changing the "profile",
   look at it another way.)  This is a standard concept.  For example, the
   Customer master file, by default is indexed on Custno.  However, you
   want to declare a Profile based on the Customer-City, which would give
   you a standard database index structure pointing at all customer records
   in alphabetic city order.

  "A couple of interesting points, here.  By default, when constructing
   a Component in LINC, you will get a primary (No duplicates, no Nulls)
   key index on, say, the customer number.  Same for Partno.  When you 
   define the Order-Entry format, and refer to the Component keys by the
   same name (i.e., Custno, Partno), the final application will ALWAYS
   make sure that when you enter the customer or part on the order form,
   there is a corresponding key entry in the components.  This is a good
   example of referential integrity (foreign key integrity) in a good
   relational database.  (Again, hint-hint)

  "Also, by a simple declaration, you can split the order-entry format
   into header and detail (line-item) portions, and have the detail
   line repeat automatically, incrementing the line number on every tran-
   smission.  Many automatic features such as this are supported.
   
  "And finally, these three types of 'logical' structure map into the 
   physical structure of the database differently.  Components are stored
   on disk (under the control of DMSII) as 'disjoint data sets', which
   are simply flat, sequential-like data(base) files.  By declaring
   Profiles on Components, you can build indexes into those disjoint
   datasets (unlimited number).  ALL Events, on the other hand, and no
   matter how many Events you have declared, get mapped into ONE single
   disjoint dataset, and again you can Profile (index) on this file.
   This is done so that an emulation of the relational JOIN operator can
   be acheived.  Hmmmmmm, this must mean that in DMSII, you cannot join
   two datasets (files) together, and you're right !  This is one of the
   serious limitations of DMSII, although they have gotten around it 
   nicely with the use of Events.

  "So, in review :
       Component = Master file; static info; DMSII disjoint datasets.
       Event     = Transaction; variable info; ONE DMSII disjoint dataset.
       Profile   = Index, single/multiple field keys. DMSII sets.

  "These are the three building blocks of LINC application design.

        
3. In LINC, it uses a definition language (LDL) to develop the AP,
   am I correct?  What are the major features of LDL?  Does it has
   a menu-driven interface for end-user?

  "You are correct.  The LINC 'language', or syntax, is called LDL,
   which stands for Linc Definition Language.  Originally, in the
   first version of LINC, this was a source code language.  You would
   sign onto an editor that resembles EDT and code in LDL, which is
   a very English-like syntax.

  "The second major release of LINC, called LINC-II or LINC-11, is
   a menu-driven system.  While you still code some portions of the
   application in the original LDL syntax, many of the coding functions 
   are provided automatically by simply selecting menu options.        

  "Here are some random examples of LDL syntax :

        DISPLAY; (Order Entry Form) LINE;02 POSITION;50 BRIGHT;
        DATA;    CUSTNO             LINE;04 POS;45 REVERSE;
        DATA;    QUANTITY           LINE;05 POS;45 REVERSE;

        MOVE; CUSTS.CUSTNO   CUSTNO
        ADD;  QUANTITY       PRIOR_QUANTITY  GIVING; NEW_QUANTITY
                                                         
 ------>DO.WHEN; QUANTITY > 5000
 | ----> DETERMINE; EVERY (PRICE)
 | |      MESSAGE; ATTENTION (You cannot enter a quantity greater than...)
 | ----> END;
 ------>END.EXIT;

   (Note: the arrows are not part of the LDL syntax, they are provided here
          to show the boundaries of loops, and that loops can be nested.)

  "LDL is free-form (blanks are ignored), the commands can be abbreviated
   to, usually, two or three letters, and all commands have a semi-colon
   after them, so the basic construct is :

            [Command]; [Keyword]/[Parameter]

  "In these examples:
                      DISPLAY  : Display a literal on the screen
                      DATA     : Declares a data item
                      MOVE     : Logic, move data-1 to data-2
                      ADD      : Logic, add  data-1 to data-2
                      DO.WHEN  : Logic, sets up a logic loop
                      DETERMINE: Logic, finds a record in the d/b
                      END      : Logic, ends the determine-loop
                      END.EXIT : Logic, ends a logic loop"

4. Is DMS II a relation or network model database?  How are its perf-
   ormance and features compared with our database systems?

  "DMSII is Burrough's proprietary database system, and can be coded to
   look like a hierarchical, network (Codasyl), or inverted-list system,
   but NOT truly relational.  To code a database, you write a source file
   in a language called DASDL (Data And Structure Definition Language),
   then compile it to get the d/b structures out on disk, initialized.

  "Although the D/B designer, by hand, can write structures in all three
   types, LINC only provides for the inverted-list type database.  If you
   are unfamiliar with this term, simply think about a flat, sequential
   file, with 0,1, or many indexes (profiles) pointing into that file.

  "Again, the interesting part about LINC is that it uses the inverted
   list method, but the application developer "thinks" relational.  The
   design of a good LINC system should be relational design.  You should
   have primary keys on Components, secondary keys in Events, with no
   repeating fields or groups of fields, and normalization is highly
   recommended.  However, even though one designs relationally, the data-
   base is mapped to an inverted list structure schema.

  "Performance-wise, DMSII is highly respected in the industry.  Users,
   according to DataPro, often give it 3� points on a scale of 1-4.
   It performs quite nicely, is rather simple to understand, and allows
   many functions such as restructuring without unloading/loading, a
   passive data dictionary, and analysis utilities.

        
5. Why does LINC need a network specification?  
       
  "A programmer, in LINC, can design a complete Network specification
   through the LDL.  This specification includes terminal types, line
   protocols, adapter numbers, etc.  Like all other Burroughs languages,
   this is usually written in source form and compiled to create an
   executable network handler.  And like all things that LINC does, this
   was formerly done by hand, and now handled by LINC.

  "Generally, in any given installation, the Network specification is
   coded in LINC once, compiled, and then that specification is saved
   in case changes to the Network have to be done.

  "However, in all LINC systems being developed, the LINC programmer
   must include one line that tells of the name of the Network handler
   that was previously compiled.  This line is :

               .
               .
               .
               NETWORK;  LINCNDL
               .
               .

   and is located in the "global" section of every LINC specification.
                       
  "This is required because LINC tracks all terminal activity by station
   (terminal) number and location, recording all information in audit
   logs.  Operator statistics, by station or line number, can also be
   requested from the system.


6. What does the features of LIRC?
       
  "LIRC (Logic Information Report Compiler), is sort of the same thing as
   LINC.  Using the same LDL syntax, you can generate reports, batch up-
   date programs, and inter-system  communication programs.  Primarily
   used for report programs, LIRC will generate Cobol code and allow all
   of the nice functions such as control breaks, totals, and formatting
   of report output.  The syntax statements to perform logic, lookup 
   records, etc., are quite similar to LINC.

  "LINC and LIRC are packaged together, and should be considered as one
   product.  There is no way to use LIRC against a non-LINC system.

7. After developing the AP, is there a easy-to-use editing environment, 
   such as a form editor for end user to alter the form layout?  
        
  "Yes, after designing, coding, and generating a LINC-II system, if you
   want to do any maintenance/enhancement to the system, you simply go
   back into the LINC-II menus and re-specify those things that you want
   changed.  A re-generation is required to make those changes permanent.
   (In other words, the ENTIRE system has to be re-generated.  I don't      
    know if they've gotten around that yet... I've been gone a year !)
   This can be a serious drawback, if Burroughs hasn't fixed this yet,
   because if you want to implement, say, a tiny little screen change,
   you have to regenerate/recompile ALL segments of the application system.
   And, if any of the LIRC report programs touch a DMSII file that has
   been changed during a regeneration, then those LIRC programs, too, have
   to be recompiled.  This is due to the fact that all executable programs
   running against a database are time-stamped, and the programs compilation
   time stamp must be later than the time stamp of the DMSII data structure.

8. For a non-experienced user, how long will it take in order to use LINC,
   how does the productivity gain while developing an AP?

  "It depends on how good you are !  Like all languages, some people pick
   LINC up very quickly, and others never really get accustomed to it. I've
   seen both.

  "For most people, the "new", relational design approach is the hardest
   thing to get accustomed to, and those people will always try to fall
   back on language structures such as Occurs Clauses and embedded records.

  "I would say that the learning curve lasts about 1 month for an average
   programmer, and productivity gains during that period would average
   perhaps 5:1 over conventional coding methods.  As the experience of the
   programmer increases, productivity gains could approach 15:1.  On the
   other hand, the larger the system gets, the more complex it is, and then
   the lower the productivity.  Although Burroughs says that the productivity
   curve stays even despite the size of the application being developed,
   I would tend to disagree.

  "Most notably, the above discussion is valid only if the design of the
   LINC system is good, and what follows is a VERY IMPORTANT POINT...

     * LINC is a 'programmers productivity tool'.  It greatly facilitates *
     * the physical design and coding of an application system.  On the   *
     * other hand, LINC, in and of itself, does nothing to aid in the     *
     * actual design of a system, nor does it evaluate the validity of    *
     * the design.  Because of this, the product generates systems that   *
     * are quite sensitive to the initial design of the application and   *
     * underlying database system.                                        *
                                                                           
     * Another way of looking at this is that LINC will provide excellent  *
     * productivity gains when used in accordance with the style of design * 
     * that the LINC developers intended, to wit, a relational design      *
     * approach.  If a LINC programmer/analyst has a poor initial design   *
     * of his application, or an undefined idea of what business function  *
     * he/she is trying to model, then errors and poor design tend to be   *
     * propogated throughout the system, with a corresponding decrease in  *
     * productivity and efficiency.                                        *

     * While LINC can indeed provide an average of 10-to-1 productivity    *
     * gain, it can also be imagined that it will allow the programmer     *
     * to make the same old design mistakes 10 times quicker, with 10      *
     * times the problems, and 10 times the system overhead.  Watch out !  *


9. Compared with our 4GL products, RALLY or COBOL generator, what do you 
   think will be our strength and weakness?

  "That's a simple one.  We are stronger in that RALLY and COBOL generator
   are part of the V.I.A.  All of our products talk to all of our other
   products (well, at least in theory...), and that all of our products
   can talk across a network.

  "Unisys is just now beginning to realize the need for distributed data
   processing, and is considered a late entry into the networking arena.

  "LINC and LINC-II tend to generate standalone systems.  In other words,
   LINC is fine for developing *new* systems from scratch, but LINC cannot,
   as far as I know, effectively communicate between other LINC systems,
   and LINC cannot be used against older, hand-coded systems.  (This is
   much the same, however, with Cobol Generator.  You cannot take a hand-
   written Cobol program and work on it with the generator.)

  "So, it can be seen that LINC is great for a brand new DP shop, or for
   a system that does not interface to any other existing applications,
   but these situations are generally few and far between.  As a matter
   of fact, this could be LINC's one major pitfall.  Burroughs will always
   recommend that a user buy LINC and totally redesign their applications
   using LINC, but how many users are really willing to do this ?  The
   marketing battle that ensues after this suggestion is really something
   to see !"

   
        
10. Finally, in your own personal opinion, as a previous LINC user and a
    current DEC user, what do you suggest us to do in order to "beat" 
    Burroughs ? 
        
   "TELL THEM THAT WE'RE DIGITAL, NOT UNISYS !
    That alone should tell them enough.

   "No, seriously,  that's a tough question to answer.  It all depends
    on what the customer is looking for, what their future needs are,
    and where they are at at the moment.  Some things that you may want
    to push are the abilities to network systems together, our sopisticated
    product set, our third-party software, and other Digital benefits.

   "On the other hand, although LINC *looks* attractive at first glance,
    it is big, cumbersome, generates a lot of system overhead and contention,
    is VERY inflexible in the approach to designing a system, and is quite
    limited in scope.  With LINC, you can design good, general, standard
    application systems, but as soon as you want to interface to a 'foreign'
    (non-supported) device, or twist the product in any unique way, or
    introduce anything out of the 'ordinary', you will find that the product
    just wasn't built to do it.  Thus, this is a severe limitation.

   "One last bad thing about LINC.  LINC was designed, it seems, to sell
    hardware.  Even with a good crew of people designing a system, even
    with appropriate design, even with good productivity numbers, there
    is a problem.  If you're really good at LINC, you can design and 
    implement systems so quickly that you outgrow your hardware configuration
    in 6 months !  Think about the extra cost to a user now !

   "For more information on how to sell against Burroughs, I would highly
    recommend reading the Competitive Update article written by Bill Moore,
    if you have it available, called "Replacing Burroughs B5000's and
    B6000's.  It has some good general information about Burroughs in it.

   "Some of our general strengths are, and I quote from the article,

       o Lower price and cost of ownership relative to throughput
       o Better investment retention
       o Lower cost for maximum flexibility and reliablility
       o Proven computer-to-computer networking
       o More application software
       o More software development tools

    "And, in my opinion, LINC itself can generate severe technical problems
     on the hardware itself.  Overhead, as I've mentioned, is quite high,
     there are some built-in bottlenecks in the management programs gen-
     erated with the application system, and memory/cpu usage is quite high.

    "Some LINC-specific negatives...

        - It runs on Burroughs machines      
        - It ONLY runs on Burroughs machines 
        - Burroughs merged with Sperry       
        - It is fine for small applications, but on the larger systems,
          the tremendous overhead starts to get in the way.
        - While quite productive for small application development,
          the larger or more complex the system, the less productive
          it becomes.  (Too much interaction between the database
          relations starts to thwart the simplistic approach to 
          design and development.
        - Conventional DPeople have a hard time getting accustomed to
          LINC.  It is a new design philosophy for most, and the urge
          to go in and tinker with the code will cause problems for 
          most programmers.
        - If you indeed have to tinker with the code, that's when you
          start to defeat the purpose of the generator, i.e., every
          time you do a simple re-gen of the system, you have to re-
          apply the patches that you've developed.  There is no way
          that I know of to automatically include your code with LINC.
        - There are no external branch-outs (like calls to system services)
          allowed within the language, i.e. You WILL code only in
          LINC !  So, if the language can't do what you want, you're
          sunk.
        - Existing code cannot be incorporated or catalouged with the
          new LINC systems that you develop.
    
    The last point prevented the sale of LINC to many existing Burroughs
    users.  While LINC was good for small-medium size, BRAND NEW systems,
    as soon as things get too complex, or as soon as you have to incorp-
    orate older systems, you run into a counter-productive situation.
    To sell into existing accounts, you basically had to pitch the fact
    that you were recommending to the customer that he/she throw away
    all the code developed over the last nn years ! 


Well, I hope this has helped you.  I'll also post this in the notes confer-
ences for LANGUAGES, CONVERSION, and COBOL_GENERATOR.

Of course, if you have any questions or comments, or if something (due to
the language difference) is not quite clear, please don't hesitate to let
me know.

Good luck !

Bob Hanson     (OBIWAN::/TIPPLE::/IMBIBE::/DARTH::HANSON)
               (DTN: 323.4053)
               (ROBERT HANSON @KYO)


PS: Below, I've included a section from a previous note that you might
    find useful.
    
    -BTW-  The above mentioned Burroughs (uh, er, Unisys) products most
           closely map to Digital as follows :
    
                GEMCOS     ----- >  ACMS   (sort of...)
                DMS-II     ----- >  DBMS   (sort of...)
                NDL        ----- >  DECnet (sort of...)
                COBOL      ----- >  COBOL  (no sort of on this one)
    
            GEMCOS (Generalized Message Control System) serves as a
              transaction and input-format router, deciding, based on
              a transaction code, exactly which terminal or application
              should receive/send input & output.
            DMS-II (Data Management System-II) is a database system,
              declared as a source language, which can be used to
              specify and maintain hierarchical, network, or inverted-
              list databases, although LINC's design philosophy more
              closely resembles Relational.
            NDL (Network Definition Language) is a source language that
              is used to declare the physical datacomm network in terms
              of d/c lines, terminals, station id's, and protocols.
            COBOL74 (C.O.B.O.L.7.4.) is ANSI-standard with Burroughs
              extensions, and differs, as most, in the datacomm and
              database interfaces.

    To code in LINC, now through the use of menus, you simply declare
    or "paint" a screen format, with input fields included, and that
    will, without further input from the programmer, generate the NDL,
    the database (DMSII schema constructed based on input fields), the
    GEMCOS system, and a Cobol application that will send/receive the
    screen you've painted while allowing Add/Change/Delete/Recall 
    maintenance transactions, storing those transactions in the database.
    
    You can also specify database indexes, files without screens, menus
    or screens without files, inquiries, and other nifty functions.
    Also included as part of the system is a report-writing function
    where reports are coded using virtually the exact syntax used for
    application development.