Conference turris::languages

        Are you suggesting that there are languages in use in the
        "Mainframe market" that aren't in use in other parts of the
        technology spectrum. Could you elaborate on what these are. The
        only things that come to my mind are things like JCL (ptooie) and
        CICS (double ptooie) which don't really rate as languages per se.
        
        Elaborate please...
        
        q
        

For starters, COBOL and PL/I are potentially much more important if you're
seriously going after IBM customers...

My purpose in the base note was to illicit your thoughts concerning trends in
computer languages which will effect  mainframe users.  Given IBM's CASE 
announcements I expect alot of development and use of integrated CASE systems
in the future.  What about the U* word?  Will Open Systems impact the large 
mainframe shop?  Will Object Oriented languages and databases make headway
in the near future?

Well, what do you think?

Lavon Loftin

Mainframe languages, in my opinion, would be:

	COBOL
	FORTRAN
	PL/I
	C

in that order (C is making such rapid gains it's *everywhere* now).

Digital has excellent implementations of all four.

However, the emphasis that does suggest itself is the cross-development
environment for IBM and other mainframe systems. It's fine to be able to
write 100,000 lines of VMS COBOL while an IBM team is writing 15,000 lines
of IBM COBOL, but if what the customer wants is IBM COBOL, what use is it?

Code conversion using SCAN programs, etc., go so far. There is still the
issue of IBM environments, database products, etc. The Netron/CAP third
party solution goes a long way to solve this problem, allowing development
of IBM CICS COBOL under VMS. The fly in the ointment? It's a third-party
solution which isn't integrated with Digital's CASE strategy.

See the CURIE::CASE conference for more (also HAMPS::CASE_COMPETITIVE).

/Tom

    From my personal experience, the IBM mainframe shop is a lot
    less likely to be mucking around with object-oriented
    techniques, AI or anything else exotic.  The bulk of the
    technical and management personnel in the larger shops cut
    their teeth on COBOL/CICS and that's really all they know or
    care to know.  To call them conservative is almost an
    understatement.
    
    As far as U*IX goes, these are guys who think VMS security is
    lax 'cause the user gets to make up his own password!
    
    -dave

>    As far as U*IX goes, these are guys who think VMS security is
>    lax 'cause the user gets to make up his own password!
    
    This is a misconception.  It is quite easy for a system manager
    to force users to use PASSWORD/GENERATE, and thus not have to
    opportunity to choose their own password.  
    
    My impression is, in fact, that at least one version of VMS (5.3) 
    has achieved a higher security rating than MVS or VM.  And then
    there's the secure systems group....
    
    MATT

Re: .6:

   You missed the point of what the author of .5 was saying.  The MIS-types
wouldn't even think about Unix.  (The author was saying they feel VMS is
unsecure (insecure?? :-) and Unix - forget it!)

   And you're right.  People who are running their business on software
systems are looking for strong stability, not some university-land experimental
type system.

   I.e. Some TLA: DEC, VMS or IBM.  (I suppose this puts DG and such right
out... :-)


					-mjg

    .5 was passing along the MIS conception ("misconception") that VM or
    MVS = safe, VMS = risky, UNIX = suicide, giving the example of  a
    limitation that supposedly (but doesn't actually) exist in VMS. While
    that's worth noting the force of these opinions, it's also important to
    debunk them as they're being made.  
    
    For that matter, the idea of UNIX being insecure will soon be  outdated
    as well.... But back to discussing mainframe languages....   It amazes
    me that we seem to be scaling back VAX PL/I even as we enter the
    mainframe market.  Even winning a bid or two on the basis of a decent
    PL/I compiler could pay for all the development work.
    
    
    MATT

>    My impression is, in fact, that at least one version of VMS (5.3) 
>    has achieved a higher security rating than MVS or VM.

The only version of VMS that has been officially evaluated is VMS 4.3, 
which has a C2 rating.  Options are available (both from IBM and third 
parties) for both MVS and VM which also have a C2 rating.  VMS 5.3 has
no official rating and is not attempting to obtain one.  (Ratings do 
*not* automatically progress from one version to the next.)

There are rumors that "Thunderbolt" will be trying for a new C2
rating, in which case SE/VMS (or whatever it's called now) would want
to try for a B1 on top of Thunderbolt.  *This is all rumor.* 

There's a version of System V from AT&T which has a B1 rating.  IBM's 
Xenix is currently in evaluation for a B2 rating.

FYI, the security rating designations work like this:
	(highest) A1 > B3 > B2 > B1 > C2 > C1 (lowest)

>    It amazes
>    me that we seem to be scaling back VAX PL/I even as we enter the
>    mainframe market.  Even winning a bid or two on the basis of a decent
>    PL/I compiler could pay for all the development work.

VAX PL/I is getting transferred to a different group partly because they
may be able to devote more resources to it.  Technical Languages and
Environments (which includes projects for Ada, Bliss, C, C++, FORTRAN,
Pascal, IPSE, LSE, SCA, PCA, Debug, PDF, SDL, CDD and related projects,
GEM [new retargetable compiler back end], etc.) has a finite amount of
resources.  While PL/I rates as an important language, compared to the
other projects it was consistently rated lower.  (Rightly so, in my opinion,
in spite of the fact that I spent several years working on it, and in spite
of the fact that compare to things outside of TLE I would rate it higher.)
Basically, it's a good language and hopefully it's new home will allow work
on it to proceed at a more rapid pace than was the case for the last few
years in TLE.  All around, this should be the "right thing" for the long
term.

Kent (VAX PL/I V3.0 PL)

    Re .10:
    
    Where is it going, CLT?

Would you believe MLT?  MLT = MSD Langauges and Tools.  Other languages
supported/developed are VAX APL, VAX DIBOL, VAXELN Pascal and soon VAX PL/I. 
We are a small enthusiastic group that also supports most of the PDP-11
languages.

-Alex

    I think MSD stands for Micro Systems Development - they are responsible
    for the PDP hardware and operating systems, along with a smattering of
    Microvax hardware and software systems.  I hear that MSD is responsible
    for about 20% of DEC's gross revenues, so this is no slouch
    organization.
    
    MSD belongs to Low End Systems, Dom LaCava is the VP.
    
    					Bob Craig
    					DSM Product Group