Programming Essentials with a .NET Language

In this section, I discuss .NET programming languages, the .NET development environment, and the core underlying .NET technologies. Of course, this discussion will begin our efforts to answer the question of "What is .NET?" Some people might expect that coverage of programming essentials alone would be sufficient to help define .NET. As you will see, it is easy to understand why some have that expectation.

Cross-Reference  

The topics in this section are further discussed in Part Two of this book.

This section explains how .NET qualifies as all of the following entities:

• Programming language choice

• Programming language support

• Development environment

• Collection of class libraries

• Virtual machine and runtime

• Object-oriented technology

.NET Is a Programming Language Choice

That's right, you have a chance to choose your .NET programming language. You make this language choice by selecting your specific .NET compiler. You can actually refer to a given language compiler as a .NET type of language compiler. However, to be technically correct, you would use other phrases such as "the language compiler supports the .NET Framework" and "the language is managed. " Later, in this same "Programming Essentials with a .NET Language" section, I discuss the .NET Framework and what it means to be managed.

According to Microsoft, there are about 20 .NET language compilers. This count includes those compilers provided by Microsoft and other compilers developed by other software vendors ( partners ). A few of the .NET programming language compilers provided by Microsoft are as follows :

• Visual Basic .NET

• Visual C# (pronounced "C sharp") .NET

• Visual J# (pronounced "J sharp") .NET

• Visual C++ .NET

Among the list of partners, one in particular stands out (in my eyes ^[1] ). Let the history books record that Fujitsu Software is the first vendor (and the only vendor for now) to come forth with a .NET compiler for COBOL. As mentioned in Chapter 1, this particular compiler version product is called NetCOBOL for .NET. For all reformed COBOL developers, this decision by Fujitsu Software to jump onboard (teaming up with Microsoft) will stand to be a critically valuable one. Therefore, when you do .NET development, you actually have choices related to the language syntax and language compiler with which you develop.

An Opportunity to Choose

Recall that the mainframe offered several popular programming language choices for business programming: COBOL, assembler, Easytrieve, and Dyl280, to name a few. ^[2]

Each of these mainframe languages had specific advantages over the others. Some of those advantages related to design and compile-level characteristics. In the case of Easytrieve and Dyl280, compilation (or rather, the lack thereof) was even an issue.

Fortunately, in the world of .NET, a language that is said to be a .NET language is able to stand shoulder to shoulder with any other .NET language. In other words, as far as functionality and performance is concerned , one .NET language does not have a clear advantage over another.

 

Because the .NET development environment is designed such that languages are "neutralized," performance is not a criterion; in theory, all the languages will perform well. That being said, you may tend to make your .NET language choice based on personal preference. However, you should take many other things into consideration. Suffice it to say that whether your preference is Visual Basic, COBOL, C++, or even Java, there is a comparable .NET language compiler waiting for you.

Cross-Reference  

Chapter 5 covers .NET language choices in further detail.

.NET Is Complete Programming Language Support

The previous section emphasized the availability of .NET as a language choice. Now, once you do select a .NET language (or languages), you will notice that your chosen .NET language has all of the normal language elements (i.e., conditional logic, loops , case statements, comparative operators, and so on) that you would expect of any programming language. ^[3] In that way, programming on the .NET platform becomes comparable with the legacy mainframe COBOL programming that you have (presumably) done for some time.

During your legacy mainframe development experience, you have likely used COBOL (and other languages) to implement your business rules using these normal language elements. Well, in .NET you will look to these familiar elements and concepts (or language features) to implement your business logic and presentation routines. Granted, the syntax will vary from one .NET language to the next . Nevertheless, you will find that these basic programming elements are there still.

Cross-Reference  

Chapter 6 is devoted to the "nuts and bolts" of .NET programming.

.NET Is a Development Environment

In the mainframe world, you were accustomed to having an actual environment in which to develop your software. One mainframe tool comes to mind: Interactive System Programming Facility (ISPF). Some of you may have had the misfortune of working in mainframe environments where other products were in use ”competing products that looked like and worked like ISPF ( sort of). At any rate, you had a development environment. In this mainframe environment, you had an editor. Additionally, you had the ability to construct and compile in ISPF.

Whether you were doing batch programming or online programming, you typically did (almost) everything within this same environment. There were some exceptions ”times when you left ISPF for certain tasks . Nevertheless, for the most part you leveraged the submenus on ISPF for your development needs. In that sense, you can say that ISPF (and products like it) represented an "integrated development environment."

Well, you guessed it, there is an integrated development environment (IDE) in the world of .NET. Microsoft has a product called Visual Studio .NET (VS .NET). In short, it is an awesome tool. In this IDE, you design, edit, compile, and test your programs. As in the case of the mainframe, there are times when you will work outside of VS .NET. Over time, vendors will attempt to create competing development environments. Only time will tell which one will rise to become the preferred IDE. For now, Microsoft's VS .NET is easily your .NET IDE of choice.

Cross-Reference  

You will explore the VS .NET tool in great depth in Chapter 5.

.NET Is a Collection of Class Libraries

Imagine that you're developing a COBOL program on the mainframe. Perhaps you have a group of mainframe partitioned datasets (PDS) that make up an extensive library of copybooks, utilities, subprograms, and software routines. Let's say that this reusable software library has been proven bulletproof, so much so that you've come to rely on this library and you often reuse selected PDS members .

Now, add on top of all of this that you chose to leverage the inherent COBOL Report Writer module and internal COBOL SORT features. Obviously, your intention would be to maximize any plumbing that the COBOL compiler provided (that you may have a need for) and maximize any reuse opportunity that the reusable software library offered.

Well, with this mainframe analogy I have just about described the functionality of Microsoft's .NET Framework. However, to really be fair, I would have to take this imaginary reusable library and multiply it by a factor of 4,000. The .NET Framework contains several thousand reusable software pieces. Regardless of the .NET language that you happen to use, the full .NET Framework is available to you. The more that you leverage (reuse) the .NET Framework, the better off your .NET development experience and resulting .NET application will be.

Cross-Reference  

Although selected portions of the .NET Framework will appear in almost every chapter in this book, you will focus directly on the .NET Framework in Chapter 7.

.NET Is a Virtual Machine and Runtime

Suppose for a moment that I asked you to define the mainframe's Job Entry Subsystem (also known as JES, JES2, or JES3). You might explain JES in this way: You submit your batch programs in the form of Jobs to the operating system. The operating system in turn hands your Jobs to JES for execution. JES then manages the priority execution of your Jobs. Following execution, JES handles the purging of your Jobs from the operating system. So, what does this have to do with defining .NET and answering the question "What is .NET?"

Well, sitting on the bottom of the entire .NET world is a foundation, an engine referred to as the common language runtime (CLR). The CLR manages the fine details of what your program is doing, in much the same way that JES manages your Jobs. As JES purges your Jobs from the operating system, the CLR might purge your software objects from memory. You could say that the CLR is a micromanager of sorts. As JES is a major piece of system-level software, the CLR is an equally major piece of system-level software.

Cross-Reference  

Chapter 8 discusses the CLR in detail.

.NET Is an Object-Oriented Technology

The emphasis on the .NET Framework earlier in this chapter should also be applied to this topic of object orientation. Putting the two together will lead you to the creation of more maintainable and reusable components .

Good Design Practices Are Still Needed

For the reformed mainframe programmer, moving toward the object-oriented software development model means moving away from the following software development models: ^[4]

• Structured

• Procedural

• Top-down

• Spaghetti

Of course, well-seasoned developers (like us) have only developed applications using the structured development models. So, spaghetti code is a thing of the past, right?

Wrong. Although .NET is many things, it is not a panacea. As it turns out, even object orientation will not prevent developers from writing spaghetti code. However, fully leveraging all that .NET has to offer will encourage good program design. So, as you start writing great .NET applications using the new object-oriented development methodology, remember that design/code reviews and quality assurance processes continue to offer value.

 

In the world of .NET, you will be working with objects: Everything is an object. In your object-oriented program, you will create, reference, modify, and pass objects. After you understand the world of object orientation, you will prepare yourself to create maintainable, robust, and scalable applications. You will strive to create efficient code, and you will even learn not to create memory management problems in your application.

That's right, the concerns of memory management still exist. The concerns of managing memory will feel painfully familiar to the advanced mainframe Customer Information Control System (CICS) programmer who has worked with the GETMAIN and FREEMAIN storage commands. In addition, the phenomenon referred to as "memory leak" is familiar to some advanced CICS mainframe programmers (like yourself). The good news is that .NET has implemented a solution to help developers in the area of memory management.

You will be introduced to this .NET-implemented feature, the garbage collector (GC), in Chapter 8. The GC will do some of what the mainframe FREEMAIN command did and more. As I mentioned earlier, in .NET everything is an object. The GC is just one aspect of what .NET offers to assist you in managing objects. Learn object orientation, and then prepare to work with .NET objects extensively.

Cross-Reference  

I discuss the topic of object orientation in Chapter 4 in detail. In Chapter 9, I discuss object orientation in even more detail as it applies directly to the coding samples.

Sure, there are objects and the .NET Framework, but what about data? You were just about to ask that question, right? Eventually, you are going come across the need to read and/or write data. As I discuss in the next section, the .NET platform has great support for accessing data.

^[1] No offense intended to those who share a passion for other languages such as Fortran, Pascal, and so forth. If it is any consolation, even those languages (Fortran, Pascal, and others) have .NET compilers built (or being built) to .NET-enable them.

^[2] Using the words "Easytrieve" and "Dyl280" in the same sentence with the words "programming" and "language" may be a questionable approach. Later, in Chapter 4, you will see that the Web/Windows world has continued the tradition (as the mainframe world did) of loosely using the word "language" to describe various technologies.

^[3] This is at least true for each of the .NET languages that I discuss. Chapter 6 covers this topic in more depth.

^[4] This, of course, may not apply to those (few, relatively speaking) of you who have already begun object-oriented COBOL development on the mainframe.