[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::languages

Title:Languages
Notice:Speaking In Tongues
Moderator:TLE::TOKLAS::FELDMAN
Created:Sat Jan 25 1986
Last Modified:Wed May 21 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:394
Total number of notes:2683

127.0. "burrough's lincII" by USWAV1::PEABODY () Wed Jan 28 1987 21:57

    i am looking for any info available on a product from burrough's
    caled linc.i would like to understand it's strengths and weaknesses
    also any past or current unhappy users. also what would help even
    more is how it compares to cincom's ultra/mantis and software ag's
    natural/adabase.
T.RTitleUserPersonal
Name
DateLines
127.1Could you give us a hint?TOKLAS::FELDMANPDS, our next successThu Jan 29 1987 13:476
    If you could give us some clue as to what you think it is (a
    conventional programming language? a database language? a 4GL? an
    AI language? not a language?), then it might be easier for someone
    to give you a clue on places to look for information.
    
       Gary
127.2more infoUSWAV1::PEABODYFri Jan 30 1987 08:287
    LINC STANDS FOR LOGIC INFORMATION NETWORK COMPILER AND AS THE NAME
    SUGGESTS,IT IS A COMPLETE SYSTEMS/APPLICATION GENERATOR AS OPPOSED
    TO BEING A PRogram generator. it is based on burroughs dbs II database.
    it builds its own database a bit like vcg does with rms files.i
    found a person who has worked on the system (belfst::irwin), i am
    still looking for more input in relation to cincom/software ag alos
    also any customers who converted from linc
127.3LINC WAS MY LIFE...IMBIBE::HANSONWe'll convert anything...!!!Wed Mar 04 1987 15:12146
    
    Looks like I'm the guy to answer this one...
    
    About one year ago, I came to Digital from Burroughs in New Jersey,
    where I was District Support Specialist and Regional Product Spec-
    ialist for LINC and LINC-II.  Regional activities had me travelling
    along the East Coast to various Burroughs/LINC prospect installat-
    ions, including (yippeeeee), lots of work with LINC in Florida.
    
    Re: .2 
    LINC, indeed, stands for Logic Information Network Compiler, and
    is distinguished from many 4GL products in that it is not just a
    report-writer, cobol-generator, or schema-generator, but rather
    that it is a "complete systems generator"... one-stop-shopping.
    
    LINC, originally developed as a source language yet now (LINC-II)
    working as a menu-driven development system, presents a single,
    rather user-friendly interface to the Burroughs environment.
    Programmers, knowing LINC[II], do not have to have any great under-
    standing of how to code an NDL, DMS-II (not 'dbs') database, 
    GEMCOS message control systems, or COBOL74 code.  Through the
    single language interface, all of that stuff, required to build
    an application system, is generated automatically based on the
    programmer's input.
    
    -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.
    
    The design/coding process with LINC is very simplistic and straight-
    forward, once you get accustomed to all that the language is really
    doing for you.  Be aware that it is positioned by James Martin as
    "Fourth Generation Language suitable for use by DP professionals",
    though Burroughs is a bit reluctant to admit to that wholeheartedly.
    
    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.
    
    Well, on a simplistic level, I've gotta say that LINC is really
    quite good.  Although one is not recommended to go in and change
    any software that LINC generates, it is available if desired.
    You usually don't have to change anything because A) the code is
    really quite clean, and B) within the proper limits of the LINC
    design philosophy (relational design and access), anything that
    you would want to include in the system has a syntactical state-
    ment to implement it.
    
    Productivity gains using LINC, on a simplistic level (hmmmmm, there's
    that phrase again...) can be quite dramatic.  For example, in demos,
    specifying a complete, though simple, system to Add/Chg/Del/Inq
    on transactions for, say, a Customer master file, a Product master
    file, a repeating line order entry format, and a menu would take
    only about �-hour to code and generate.  Estimates for how long
    that would take by hand-coding ranged from �-DAY to 1 WEEK, depend-
    ing on the conventional coding experience of the programmer.
    
    So, how do we beat LINC-II in the marketplace ?  Try these...
    
        - It runs on Burroughs machines      (No real connectivity)
        - It ONLY runs on Burroughs machines (No real portability)
        - Burroughs merged with Sperry       (Anybody know *WHY* ?)
        - 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 (f%&#-around) 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 !  Obviously, I've
    been told to "take a hike..." before.  (Why do you think I'm at
    Digital, now ?  I couldn't take the rejection !  8^)
    
    So, though I've gone on quite a bit, that should get you started.
    Of course, if you'd like to know more, simply give me a call or
    VAXmail me at the addresses below and I'll be more than happy to
    help out.  
    
    Also remember that we can work around LINC from two positions :
    
         1) LINC has a specific purpose in life, and
         2) It's Burroughs, and we should stress the Digital Advantages.
                      \
              ["We're UNISYS, where 0 squared is still 0"]

    Wanna know more ?
    
                    DARTH::HANSON
                    OBIWAN::HANSON
                    DTN 323.4053
    
    Enjoy !
    Bob    
                                           
127.4More in 131TIPPLE::HANSONWe came, We saw, We passed out cold!Wed Mar 18 1987 12:375
    
    See note 131 in this conference for more information on LINC
    
    Bob Hanson