Not your mother’s COBOL


Whenever you start building a new system, there’s a good chance you’re working with customers, clients, employee’s or people of some type or other and our school admin system is no different than any other. It has students, parents, teachers and support staff who are all “persons”. Let’s start with knocking up (I’m Australian, and yes I know what this means in the U.S) a basic person class:

class-id School.Data.Person public.

working-storage section.

01 Person-Id        binary-long              as "Id"             
                    public property with no set.
01 Last-Name        string                   as "LastName"       
                    public property with no set.
01 First-Name       string                   as "FirstName"      
                    public property with no set.
01 Middle-Names     string                   as "MiddleNames"    
                    public property with no set.
01 Person-Title     string                   as "Title"          
                    public property with no set.
01 Birth-Date       type DateTime            as "BirthDate"      
                    public property with no set.
01 Person-Address   type School.Data.Address as "Address"        
                    public property with no set.

method-id new public.
local-storage section.
procedure division using by value   personId      as binary-long
                                    lastName      as string
                                    firstName     as string
                                    middleNames   as string
                                    personTitle   as string
                                    birthDate     as type DateTime
                                    personAddress as type 
                                                  School.Data.Address.
                                    
    Set Person-Id       to personId.    
    Set Last-Name       to lastName.    
    Set First-Name      to firstName.   
    Set Middle-Names    to middleNames. 
    Set Person-Title    to personTitle. 
    Set Birth-Date      to birthDate.   
    Set Person-Address  to personAddress. 

    goback.
    
end method.

method-id ToString override.

procedure division returning returnString as string.

Set returnString to String::Concat(Last-Name::ToUpper() ", 
                                  " First-Name " " Middle-Names)

end method.

end class.
 

Looks a bit different to the COBOL you learnt from Mum, doesn’t it?

I’m not going to go into huge detail on object-oriented theory and what it means in the COBOL world … Encapsulation, inheritance, polymorphism, blah, blah, blah! We want to get coding and develop a little understanding on the way. You can then extend your understanding by doing a little homework.

That being said, you need to understand that in the .NET world classes are like factories that create things: objects (sometimes referred to as types). There are special classes called static classes where this is not quite true, but we’ll cover this later. Objects are constructed of other objects which you might think of as like data. The special thing about objects is, however they have built in behaviour that is invoked when the object is sent a message. In the .NET world messages are sent to methods. So in the above example the Person class creates Person objects. Each person object contains some data in the form of properties and fields (both visible and invisible to the outside world – we’ll get on to this later). Each object has methods to act on that data (the new method is a special method that is only executed once on the creation of the object). The currently written methods in the person class are the new method and the ToString method. Classes, data and methods may broadly be private or public (we’ll get to internal and protected later). Public classes, data and methods are visible to all. Private data and methods are only visible to the class in which they are contained. Private classes are only visible to classes in which they are nested.

You’ll notice that I’ve littered the code with this wordy as "Id" statements (in this case Id is a reserved word!). These are the names for the piece of Common Intermediate Language (CIL often shortened to IL) code that will be built into the executable (or assembly). Whilst not strictly necessary if you’re sticking to COBOL code, if you are working in a multi-language project, or if you want to later have other languages access your code, make your public face friendly. By this, I mean:

  • no hyphens – they get translated into underscores and just look ugly. Tools like StyleCop don’t like them. This will be hard for you I know!
  • use Pascal casing: TheFirstLetterOfEachWordIsUpperCased.
  • Try to use full words, unless the abbreviation is common usage: Average instead of Av, Date instead of Dte. You aren’t saving typing – the IDE does most of this for you in this environment.
  • Do not imbed the class name in the field/property/method name. In this case it is Id not PersonId, Title not PersonTitle. It all becomes superfluous and more readable when you start using the item.

You’ll notice that this class contains several public properties. We’ll get on to this in the next post. Just, let me tell you though, properties are a Good Idea. Perhaps one of the best ideas in .NET …

Advertisements

12 responses to this post.

  1. Posted by sedat on January 6, 2011 at 5:03 am

    Is it cobol or bad copy of c# ?
    no body wants to use if cobol like this, C# sharp better than this,
    I like to write cobol learnt from mum… But I know that you need to support this becuase of your needs 🙂

    Reply

  2. I rhink you’re being a little unfair on COBOL … Most of the languages that operate within the .NET Framework end up looking a little similar at some point. I’m trying to concentrate on the features of the environment that traditional COBOL programmers would not be familiar with so they can take this and use the knowledge to take existing applications to a new environment. When they do this they will gain all the productivity savings that developing provides in Visual Studio plus the cost savings of moving off the mainframe. There are millions of lines of COBOL out there that just work. It would cost billions and years of agony to re-write them in a different language … Why embark on such a costly exercise if a little knowledge means that you can provide the benefits without all that pain?

    Reply

  3. Posted by Neil Thomas on January 6, 2011 at 10:19 am

    I don’t think I’m really qualified to comment technically as I have no .NET experience, just mainframe COBOL, but I think the approach of short daily posts is a good one so that your audience isn’t bombarded with new ideas.

    Reply

    • Thanks Neil. You’re exactly the sort of person I want to aim this blog at, so read on!

      Reply

    • Posted by sedat on January 9, 2011 at 11:23 am

      list of need to know knowledge;
      1-You need to know .net concept(what is .NET)
      2-You need to know Why do you need .NET(why .net ? what for .net)
      3-You need to know system libraries of .NET
      4-You need to know what is class concept
      (if you didn’t work IBM OO cobol even IBM OO cobol is describe OO)
      5-You need to know what is method(manipulation of objects).
      6-You need to know Terms of .NET
      7-You need to know spelling of .NET
      ……
      Mr. burgun let’s help to complete right list pls…

      Reply

  4. Posted by sedat on January 9, 2011 at 9:22 am

    I am not being unfair on cobol. I am honest, don’t have salary for this, don’t need for this.. pls try to be cool and try to find a way more easy than this… I am trying to see the light and find a easy way to adaptation for cobol programmers. I see that you just began to walk on this way!! Could you tell me how many times (days,months,years..) necessary to adaptation to this language ?
    do you think cobol programmers have a lot of free time ?
    Let’s show more complex and complete project.
    (could it be; managed sql data with grid cols and raws?)

    Reply

    • I’m taking this slowly for a reason and trying to introduce some basic OO architectural concepts first. I’ve worked in the COBOL world for nearly 30 years and the .NET world (in both COBOL and c#) for around 10 years so I have been walking this path for some time. It’s hard to say how long someone will take to pick up programming in COBOL on the .NET platform … It really does depend on existing experience and aptitude but in any event the first step is that you must have the product itself.

      I certainly don’t have a lot of free time myself, and you have to remember that this is a labour of love for me. I’m not being paid for this, am not independently wealthy and accordingly cannot make content appear magically. I’m building this up over time. The project will become more complex as we progress.

      Reply

  5. Nice site!

    And your approach is spot on. Get across the concept in a digestable form.

    For those who want to see more complex examples, there are a number of other websites out and about that have them. If you click on the other blogs referenced on this site, you’ll find several.

    I really like what you are doing and look forward to reading your posts!

    Thanks

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: