What can .NET technology do for the System i developer?
Welcome to the world of Microsoft .NET technology. You're probably not used to seeing the word "Microsoft" in an IBM-related publication. However, as you continue reading, I think you'll find that Microsoft and IBM can play well together in the IBM System i environment. This article introduces .NET technology and provides an overview of how you can utilize it in your current and future System i application development. After reading this, you may find yourself compelled to learn more about the .NET application development environment and ways you can use the Microsoft toolset to quickly develop high-impact desktop and Web-based applications for the System i platform.
Setting the Stage
As I attended various System i events over the last few years, I noticed a disturbing trend. It seemed that .NET technology was being been ignored or poorly covered at most of the seminars and educational sessions. RPG, Java, and PHP are great development languages, but if you don't see the entire picture of what's available for System i development environments, you can't make an informed decision about the best methodology to use for developing new System i applications for the desktop or Web. Because of the lack of .NET education tracks at COMMON, I asked the user group to add a series of introductory sessions and a one-day seminar to give System i developers an introduction to .NET. They obliged me, and we did the first set of sessions at the spring 2007 COMMON Conference in Anaheim. I also asked the folks at MC Press to allow me the opportunity to talk about .NET in articles, and they concurred that .NET is a relevant topic for iSeries and System i developers.
The Catalyst for Change
I want to provide a little background that should illustrate why System i developers might want to update their skill sets and learn a new technology such as .NET. Over the last 15 years, we've seen the Internet revolution come to pass. We've seen personal computers go from being almost non-existent to a daily staple. The newer generation of young CFOs and CIOs are more computer literate and expect a GUI to front-end every application they use. Because of this change, many companies have begun to replace the System i applications that have run their businesses successfully for years with Windows-based ERP and other applications. I've also seen companies struggle with the decision to either continue using their System i platform or completely migrate to a new one. We in the System i world need to provide these companies with reasons to keep their legacy systems and the tools to modernize them for future needs.
With a little education on how to use a technology like .NET to develop applications, a System i programmer can quickly write a graphical application on top of an existing System i solution, thus adding a new user interface to important parts of an existing system or simply adding ease of access to existing ERP data from a Windows or Web-based inquiry. My experience with this dates back to the early 1990s when I was working as a developer for a company whose executive team demanded a daily report that could be quickly accessed from a desktop icon. They wanted to see a chart showing how things were going, not a greenbar report. We used a query tool to build the data into a pie chart and showed how System i information could be quickly published in a graphical format. This is how I formed the phrase "a little GUI can go a long way" when trying to build PR value for the System i platform.
Why .NET?
With the variety of development methodologies available today--such as Java, PHP, RPG CGI, and .NET--why would anyone choose the .NET development route for developing new System i applications? As a long-time System i developer, I've had the opportunity to work with every one of these development environments and more. After recently going through a two-year learning curve to become proficient in Java, I concluded that the average System i developer might not have the time to effectively learn and implement this development technology, especially if they wanted to quickly build Windows and Web applications to enhance the value of their System i architecture.
At the same time I was learning Java, I was evaluating .NET technology as a next-step migration path for several of our existing Windows-based products. What I learned after working with the .NET technology is that I could quickly write a subfile-like Windows inquiry application in fewer than 100 lines of actual code. I also learned that I could access my existing RPG programs on the System i platform, take advantage of the database, and achieve sub-second response time from my Windows and Web applications--just like I was getting from my System i applications. Really, the choice for me boiled down to the fact that I found that the .NET environment--and, in particular, the VB.NET language--was natural and easy to learn, just like RPG. A lot of the concepts such as subprocedures and D-specs have direct correlations between RPG and the VB.NET language.
What Is .NET?
As the year 2000 approached, we developers spent a lot of time worrying about whether our applications would work after the clock struck midnight. The moment passed, and I remember thinking, "OK, now that the new millennium has proven that there really wasn't much to worry about, it's time to start thinking about what exciting things will happen during the 21st century." The year 2000 was also the year that Java really hit the scene and was promoted by IBM. Meanwhile, the Microsoft development team was working on a new technology that would soon become known as the .NET framework.
The way I like to explain it is that Microsoft sat back and observed what Sun was doing with the Java language and environment. Then, they chose the best pieces of the Java environment and improved on those to bring us the .NET framework. At the same time, they wanted to appease the Visual Basic and C/C++ developers on the PC side of the fence with a single, unified programming environment that supported both language sets. The Internet also needed to be an integral part of this new development environment because of its growing importance.
The .NET programming environment was released in 2002 and received with great fanfare and fear from the PC programming world. VB6 had become entrenched as the PC programming language of choice, and VB.Net had some changes to the language that made VB programmers a little intimidated, much like the initial fear a System i developer can feel when choosing to learn a new language. Recent improvements to the VB.Net language, PC-to-System i connectivity speeds, and System i database drivers as well as .NET 2.0 and the Visual Studio 2005 programming toolsets have made writing desktop applications, Web applications, and Web services with .NET a lot easier. Now, a free version of the Visual Studio 2005 and the recently released Visual Studio 2008 programming environment is available to programmers who want to try their hand at developing desktop and Web applications. With all the recent improvements and free tools available, there is virtually no barrier in place, other than a slow Internet connection, that would prevent developers from using .NET technology to start developing applications for the System i platform.
System i Connectivity with .NET
One of the things I like best about programming applications in the .NET environment is the ability to write an interactive subfile-style inquiry with little programming. Direct SQL calls to the database let me easily filter records and display them in a data grid that is essentially the equivalent of a subfile. This type of program can be easily expanded to create table maintenance, order entry, and other programs.
Remote-command calls provide a basic functionality that allows .NET programmers the capability to run any CL command or program that doesn't require the user to receive any parameter feedback. A remote command call is pretty much limited to a success or failure notification that the job was run. A CPF message (System i error message) can be returned to the user application upon program completion or error, allowing for simple error notification. Although limited in functionality, remote-command calls can be a great way to build a graphical front-end to a report call that you then want to submit as a batch job with the Submit Job (SBMJOB) command. You may also have a CL command that sends back a simple message to provide user feedback, or you may simply want to trigger a System i process from your desktop or Web application.
Remote-program calls are even more powerful. A remote-program call is an important extension to the remote-command call that lets you call any existing System i RPG, COBOL, or CL program, pass parameters to the program, and receive back the parameter results after the call. On the System i platform, we've always used the term "call/parm" to describe this functionality; however, the same functionality can be used from within a .NET application to call a System i program and pass parms. This lets developers reuse existing System i program logic in a Windows or Web application without rewriting existing RPG or COBOL code. An example of this in the real world might be passing parameters from a Web page for a customer who wants to purchase an item. A call to an RPG pricing program could be made to return custom pricing based on an existing pricing routine instead of rewriting the code in VB.NET.
Stored procedures are another topic that could warrant several articles. Think of a stored procedure as a nice way to package up an SQL query or an RPG program call so that parameters or arrays of record data can be easily passed to the program and returned to a Windows or Web application. Stored procedures are a useful way to write a chunk of logic on the System i platform and use it from within RPG and COBOL programs or a .NET Windows or Web application.
What's Next?
Hopefully, I've stimulated your curiosity enough that you'll want to try the .NET toolsets and that you'll start thinking of ways you can add value to your System i platform by building Windows and Web applications that take advantage of its best features. Please attend the .NET sessions at COMMON Conferences, and let me and the team at MC Press know if you would like to see more .NET content slanted toward System i developers.
*Author's Note: The original version of this article was printed in IBM Systems Magazine in October 2007.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online