Category Archives: CLR - Page 3

Microsoft Application Architecture Guide, 2nd Edition

Posted by on January 27, 2010 Comments Off

Microsoft have just updated the “Application Architecture”.  I can’t say I have read it from cover to cover but it is being downloaded to my ebook reader…

The guide helps you to:

  • Understand the underlying architecture and design principles and patterns for developing successful solutions on the Microsoft platform and the .NET Framework.
  • Identify appropriate strategies and design patterns that will help you design your solution’s layers, components, and services.
  • Identify and address the key engineering decision points for your solution.
  • Identify and address the key quality attributes and crosscutting concerns for your solution.
  • Create a candidate baseline architecture for your solution.
  • Choose the right technologies for your solution.
  • Identify patterns & practices solution assets and further guidance that will help you to implement your solution

The guide can be downloaded from: http://www.microsoft.com/downloads/details.aspx?FamilyID=ce40e4e1-9838-4c89-a197-a373b2a60df2&DisplayLang=en

A Comparison Of .Net COBOL, Visual Basic and C#

Posted by on December 15, 2009 Comments Off

Today my collegues Robert and Alex have finally :-) decided to publish a document that compares Visual Basic, C# and COBOL for .Net under The Creative Commons Attribution-ShareAlike 2.5 License.

Rather than doing a cut-paste job, here is a quote from alex, along with a link to the “real” article itself.

Enjoy.

Alex Turner said:

A Comparison Of .Net COBOL, Visual Basic and C#

Introduction

If you are a COBOL programmer wanting to learn C# or a VB programmer wanting to learn COBOL as a .net language (or any other combination of VB.net, C# and COBOL) then this is a good place to start.

Background

If you are a COBOL programmer wanting to learn C# or a VB programmer wanting to learn COBOL as a .net language (or any other combination of VB.net, C# and COBOL) then this is a good place to start.

It has often been noted that the richness of the COBOL language in its Micro Focus .net implementation is not well known. Robert Sales and I have worked on this document to help bring the language to peoples’ attention and to help people who need to work with COBOL on the .net platform.

Click here to continue reading the rest of the article…

Factory Method Pattern in COBOL

Posted by on December 7, 2009 Comments Off

Continuing my series on design patterns for the COBOL, the next one on my list is the “Factory method” pattern.

The pattern is useful, as it helps you hide the real implementation/creation mechanism of your classes. I you are fond of uml… here is the actual uml (from wikipedia).

Factory Method Pattern from Wikipedia!

So… lets see the COBOL code…

       interface-id. "Base".
         method-id. "DoIt".
         end method "DoIt".
       end interface "Base".

       class-id. "Derived1Impl".
       object. implements type "Base".
        method-id. "DoIt" public.
         display "Derived1Impl from DoIt".
        end method "DoIt".
       end object.
       end class "Derived1Impl".

       class-id. "Derived2Impl".
       object. implements type "Base".
        method-id. "DoIt" public.
         display "Derived2Impl from DoIt".
        end method "DoIt".
       end object.
       end class "Derived2Impl".

       class-id. "Factory".
       object.
         method-id. "GetObject".
         linkage section.
         01 obj-base type "Base".
         procedure division using by value oType as binary-long
               returning obj-base.
         
           evaluate oType
              when 1
                 set obj-base to new type "Derived1Impl"()
              when 2
                 set obj-base to new type "Derived2Impl"()
              when other
                 set obj-base to null
         end method "GetObject".
       end object.
       end class "Factory".


       class-id. "FactoryDemo".

       method-id. "Main" static.
       local-storage section.
       01 obj-factory type "Factory".
       01 base-obj type "Base".

       linkage section.
       01 args string occurs any.
       procedure division using by value args.
          set obj-factory to new type "Factory"()

          set base-obj to obj-factory::"GetObject"(1)
          invoke base-obj::"DoIt"()

          set base-obj to obj-factory::"GetObject"(2)
          invoke base-obj::"DoIt"()

       end method "Main".
       end class "FactoryDemo".

That was pretty straight forward… not too much pain…

And finally the code produces…

d:\> FactoryDemo.exe
Derived1Impl from DoIt
Derived2Impl from DoIt
Hello world

Time to sign off for today.. but if you would like me to continue the series on code patterns or have a particular pattern you need… drop us a line!

Design Patterns and COBOL

Posted by on November 29, 2009 Comments Off

As part of my working life I happy to say I use COBOL and for better or worse it is here to stay. With this in mind it annoys me I here/see saying things such as

COBOL is a old language that naturally prohibits you from using modern design patterns.

rubbish I say… COBOL can be used in good ways and bad ways.

I will try and show you that COBOL can be used in a good way… lets take the “Singleton pattern“, as the first example.

First.. lets start off my creating a singleton class in csharp… so here it is:

using System.Collections;

public sealed class MySingleton {
    private static readonly Hashtable sharedHashtable = new Hashtable();

    // Explicit static constructor to tell C# compiler
    // not to mark type as beforefieldinit
    static MySingleton() {
    }

    private MySingleton() {
    }

    public static Hashtable Singleton {
        get {
            return sharedHashtable;
        }
    }
}

Not too shabby.. but lets see what we can do in COBOL…

      $set ilusing"System.Collections"
       class-id.  "MySingleton".

       01 shared-hashtable  type "Hashtable"
            static property as "Singleton" with no set.

       method-id. "New" static.
          set shared-hashtable to new type "Hashtable"
       end method "New".

What… COBOL is smaller… that can’t be true… sorry but it is…

To complete the example… lets use it…

      *> Add two items to the single hashtable
         invoke type "MySingleton"::"Singleton"::
                "Add"("01234567","Ian")

         invoke type "MySingleton"::"Singleton"::
                "Add"("987654321","Stephen")

      *> Now get one of the items of the singleton
         display "Account 01234567 - Contains: "
             type "MySingleton"::"Singleton"::"Item"("01234567")

And I am sure some people… will say sure… this is really true… it is… here is it running..

c:\temp> cobol MySingleton.cbl ilgen(sub);
c:\temp> cobol UseSingleton.cbl ilgen ilref"MySingleton.dll";
c:\temp> UseSingleton.exe
Account 01234567 - Contains: Ian
c:\temp> csc MySingleton.cs /target:library
c:\temp> UseSingleton.exe
Account 01234567 - Contains: Ian

Now it seems to me that COBOL is being under rated… perhaps someone should shout about it! :-)

Type Safety and COBOL

Posted by on November 24, 2009 Comments Off

Having read a recent bog about COBOL and type-safety, I though I would jot down some comments.

ANS85 COBOL is naturally is type-unsafe due as every data item being part of one memory region (or storage area), because of this it can make is difficult to talk to type-safe language such as Java or the CLR.

However, just like any computer language it does not stay still. Object oriented features were added to COBOL, at this point in time you we were given the verbs to create 100% type safe application.

The key to writing type safe code is the use OBJECT-REFERENCE will a TYPE and using them on in your methods and using the INVOKE verb.

For example:

      IDENTIFICATION DIVISION.
       PROGRAM-ID.   "TypeSafeExample".
       ENVIRONMENT DIVISION.
       CONFIGURATION SECTION.
       REPOSITORY.
              CLASS SYS-STRING AS "System.String".
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 hello-world-string    OBJECT REFERENCE SYS-STRING.
       
       PROCEDURE DIVISION.    
          SET hello-world-string TO "Hello World"
          DISPLAY hello-world-string
          STOP RUN.

The use of COBOL pictures can still be used, however for easy interop with other type-safe languages you really have to stick to the right types for your target environment when exposing your COBOL program to the other languages, this means if you are creating classes, the method to be consumed by other languages should use standard types, for .Net/CLR applications the use of CLS-COMPLIANT types is the right approach. For JVM applications, keep to the “core” java.lang types.

Keep to these simple rules and COBOL will happy interop with type-safe languages. :-)