One of my favourite extensions is the spell checker for the editor, which is great for pointing out spelling mistakes, which for me can only be a good thing

To install the extension, it is as simple as downloading it, clicking on the downloaded file, restarting Visual Studio and using it.

The spell checker I use with Visual COBOL 2010 is:

http://visualstudiogallery.msdn.microsoft.com/en-us/7c8341f1-ebac-40c8-92c2-476db8d523ce

For those interested, here it is in action…

Method chain can help simply the use class and allows more complex object initialisation without having to worry about the order of the parameters and be done inline.

Consider the use of an “Account” class that takes Name, Address, Telephone and Country. All of which are strings, the constructor with four strings would not be a great constructor.

So you could have a simple constructor and four properties/methods.. however so set up the object would mean you have spread the setup over multiple lines.

Using method chain you can overcome this and even space in the “value” area of the object in your storage area.

The trick of the pattern is to provide methods that always return this/self, so we can change the invokes together… For example:

This technique could even be used to build up a series of items required, for example, the preparation and execution of a sql statement comes to mind… in a similar fashion to Linq.

So… lets look at an example:

WIth the class being:

Which when run with Visual COBOL gives:

And the output of the program is:

Microsoft Application Architecture Guide, 2nd Edition

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

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…

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…

That was pretty straight forward… not too much pain…

And finally the code produces…

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!

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:

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

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

To complete the example… lets use it…

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

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

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:

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.

The .Net base class library has a wealth classes and an huge of amount of methods/properties.

The .Net base class library has a key handy namespace that contains are the lovely classes, which is System.Collections.

As you can see from the above link, it does have quite a lot, so for this blob entry I will look at:

Lets start the first example by using an array of numbers… just to demonstrate its not just strings you can assign to the arrays using “values”.

Running the above code gives us:

The next class that is helpful, is the Queue class, this allows us to “Enqueue” and “Dequeue” item using the same methods, the queue is again displayed using the “perform through” syntax.

Running the above queue example gives:

Next, lets look at the ‘Stack’ class, this is very similar, expect it uses the “Push”, “Pop” methods and we iterate through the Stack using the ‘perform through’ syntax.

Running the above stack example gives:

As you can see using the base class library collection classes with COBOL is just as easy as using C#… so if you are already using COBOL… continue and try out the .Net base class library.. it really is very easy to use and it will make you more productive.. so please explore and enjoy .Net and its Base Class library.

The taste of the pudding mix.. is in the eating.. so lets see it working…

When CLR v2.0 was introduced a few new methods in System.IO.File for block reading/writing files were introduced, these works on arrays aka “OCCURS ANY” fields. Using these APIs instead of using traditional line sequentials is a breath of fresh air, especially if you just want to do some code something quickly without the need of records/group items.

So lets.. have a little play around, lets read a “MonthNames” from the CLR, write them to disk, read them back, reverse and sort it, while display them…

Which when executed gives us:

That was pretty easy… and the code looks okay too… can’t be bad…

References : System.Globalization.DatetimeFormat

So.. lets the show on the road…

Setting up arrays/occurs items in COBOL and manipulating them can be painful. Lets look at some traditional code for playing around with a “months” table.

Now, imagine we can use one or two of the .Net’s base class libraries combined with some nifty natural extensions to COBOL to do some of the heavy lifting.

Defining the month item as a native .Net type ie: a string combined with using the base class libraries Split methods allows us to setup a array quickly.

The .Net version, besides being smaller feels much easier to read, especially if you have any exposure to the .Net base class library from other languages such as C# or VB.Net.

Of course in a real world example, we don’t need to use the split method to setup an array, we could just use the “values” clause… for example:

If however you don’t want to hardcode the months, you can always use: CultureInfo.CurrentCulture.DateTimeFormat.GetMonthName() in the System.Globalization namespace.

So… lets just do it…

Now, I hope you feel like I do that COBOL and .Net are indeed perfect partners to each other.

The above COBOL .Net code will execute on Micro Focus Net Express and I suspect it will also work on Fujitsu’s netCobol too.

Enjoy!

Let’s start with a simple example. Suppose we are writing a bank application and we have a basic domain class – Account. Account supports operations to deposit, withdraw, and transfer funds. The Account class may look like this:

Now let’s write a test for this class – AccountTest. The first method we will test is TransferFunds.

The first thing to notice about this class is that it has a TestFixture attribute associated with it – this is the way to indicate that the class contains test code (this attribute can be inherited). The class has to be public and there are no restrictions on its superclass. The class also has to have a default constructor.

The only method in the class – TransferFunds, has a Test attribute associated with it – this is an indication that it is a test method. Test methods have to return void and take no parameters. In our test method we do the usual initialization of the required test objects, execute the tested business method and check the state of the business objects. The Assert class defines a collection of methods used to check the post-conditions and in our example we use the AreEqual method to make sure that after the transfer both accounts have the correct balances (there are several overloadings of this method, the version that was used in this example has the following parameters : the first parameter is an expected value and the second parameter is the actual value).

Compile and run this example. Assume that you have compiled your test code into a Example1.dll. Start the NUnit Gui (the installer will have created a shortcut on your desktop and in the “Program Files” folder), after the GUI starts, select the File->Open menu item, navigate to the location of your bank.dll and select it in the “Open” dialog box. When the bank.dll is loaded you will see a test tree structure in the left panel and a collection of status panels on the right. Click the Run button, the status bar and the TransferFunds node in the test tree turn red – our test has failed. The “Errors and Failures” panel displayed the following message – “TransferFunds : expected <250> but was <150>” and the stack trace panel right below it reported where in the test code the failure has occurred “at AccountTest.TransferFunds() in xxxx\Example1\Example1\AccountTest.cbl:line 42”

That is expected behavior; the test has failed because we have not implemented the TransferFunds method yet. Now let’s get it to work. Don’t close the GUI and go back to your IDE and fix the code, make your TransferFunds method look like this:

Now recompile your code and click the run button in GUI again – the status bar and the test tree turn green. (Note how the GUI has reloaded the assembly automatically for you; we will keep the GUI open all the time and continue working with our code in IDE and write more tests).

Let’s add some error checking to our Account code. We are adding the minimum balance requirement for the account to make sure that banks continue to make their money by charging your minimal overdraft protection fee. Let’s add the minimum balance property to our Account class:

We will use an exception to indicate an overdraft:

Add two new classes reference to the repository:

Add a new test method to our AccountTest class:

This test method in addition to Test attribute has an ExpectedException attribute associated with it – this is the way to indicate that the test code is expecting an exception of a certain type; if such an exception is not thrown during the execution – the test will fail.

Compile your code and go back to the GUI. As you compiled your test code, the GUI has grayed out and collapsed the test tree as if the tests were not run yet (GUI watches for the changes made to the test assemblies and updates itself when the structure of the test tree has changed – e.g. new test is added). Click the “Run” button – we have a red status bar again. We got the following Failure : “TransferWithInsufficentFunds : InsufficientFundsException was expected”. Let’s fix our Account code again, modify the TransferFunds method this way:

Compile and run the tests – green bar. Success! But wait, looking at the code we’ve just written we can see that the bank may be loosing money on every unsuccessful funds Transfer operation. Let’s write a test to confirm our suspicions. Add this test method:

We are testing the transactional property of our business method – all operations are successful or none. Compile and run – red bar. OK, we’ve made $300.00 out of a thin air (1999.com déjà vu?) – the source account has the correct balance of 150.00 but the destination account shows : $450.00. How do we fix this? Can we just move the minimum balance check call in front of the updates:

What if the Withdraw() method throws another exception? Should we execute a compensating transaction in the catch block or rely on our transaction manager to restore the state of the objects? We need to answer those questions at some point, but not now; but what do we do with the failing test in the meantime – remove it? A better way is to temporarily ignore it, add the following attribute to your test method

Compile and run – yellow bar. Click on “Tests Not Run” tab and you will see AccountTest.TransferWithInsufficientFundsAtomicity() in the list along with the Reason this test is ignored.

Looking at our test code we can see that some refactoring is in order. All test methods share a common set of test objects. Let’s extract this initialization code into a setup method and reuse it in all of our tests. The refactored version of our test class looks like this:

Note that Init method has the common initialization code, it has void return type, no parameters, and it is marked with SetUp attribute. Compile and run – same yellow bar!

Just imagine the sort of rubbish code that could be create… remember because it is present you don’t have to use it!