Client-Side Scripting Languages | COBOL and Visual Basic on .NET: A Guide for the Reformed Mainframe Programmer

Many years ago, in my junior-programmer mainframe days (when COBOL, CICS, and VSAM were still relatively new to me), I created a mainframe application that used three technologies: Command List (CLIST), REXX, and ISPF Dialogs/PDF. The application was my version of a homegrown paperless change-control system. I designed, coded, and deployed the application on schedule. The entire company started using it. Generally, it was a big success. That is, until the user load exceeded my wildest expectations. The success of the application ended up being its doom. That was my first lesson about scalability.

Tip

Scalability (in general) is the ability of an application to maintain a given level of performance as physical changes are introduced to the application in an attempt to service an increased user load. The phrases "scale upward" and "scale outward" are commonly used in discussions about scalability. In a given situation, "scale upward" can refer to increasing the size of your computer processor or adding more memory. In that same situation, "scale outward" might refer to adding additional processors.

At any rate, as the system started to show serious signs of stress, a more senior programmer came to consult with me. His advice sounded something like this:

"This Command List (CLIST) language is much too slow because it is being interpreted each time a user makes a request. Did you know that you could have compiled your REXX Command List code? There is a time and place for scripts and command list. When you have the choice, a compiled binary module should be your first choice. Nevertheless, you should recode this application with a real language like COBOL or assembler. I still cannot believe that you coded this application with flat files. How are you handling concurrent updates? Have you not heard of VSAM? Besides that, you could have preprocessed your ISPF panels."

Note	A code review would have been a good idea before I coded and deployed the application.

As that scolding senior programmer had told me, there's a time and place for scripts and command list. Well, the time is today and the place (at least one of the places) is in many of the Web pages that you'll create. That's right. We still have languages that are being interpreted at runtime.

JavaScript, JScript, and VBScript

If you have a Web page that you wish to add dynamic features to, you will need to use an interpretive language ”a script language. Your basic choices ^[12] are JavaScript, JScript, and VBScript. If your users are all using Microsoft's Internet Explorer (IE) browser, then VBScript or JScript will be good a choice. Otherwise, plan on brushing up on your JavaScript. The popularity of JavaScript can be attributed to the fact that virtually all browsers fully support it (including IE). By the way, you should be concerned with not only the type of browser your users have, but also the version of that browser.

Tip

I discussed already how the browser " renders " the HTML and prepares it for display (as a Web page). There is a lot to be said for what the Web browser actually does for us. The browser has a scripting engine that takes care of the script code. Now it may be easier to appreciate the emphasis (in the previous chapter) about "knowing" your browser type and version.

When the browser detects an HTML script tag such as the one in the following example, the browser interprets and executes the code:

 <HTML> <script language="JavaScript"> . . . <!-- client-side script code goes here --> . . . </script> </HTML>

In this script code, you can code logic that manipulates or processes the "other" HTML elements and style sheets.

Client-Side Field-Level Validation

Client-side scripts are useful when you perform field-level validation. ^[13] In other words, why make an expensive trip across the network only to find out that the user has not filled in all of the required fields? For example, when a user enters a date into the Date field in your Web page, your script checks that the information entered is in a valid date format. Then, after the client-side script code has served as your gatekeeper, your application makes the call to the Web server and processes the server-side code. Finally, the server-side code executes the database update logic.

Cross-Reference

Chapter 14 covers client-side validation in more detail and provides sample code.

Note

One of the major advances of ASP.NET is that when you write server-side code you can now use a full- powered language (such as VB .NET) instead of being limited to VBScript. The scripting languages VBScript and JavaScript are subsets of Visual Basic and Java, respectively. Additionally, with ASP.NET, the server-side code is compiled code now. Gone are the days of coding your ASP files with VBScript interpretive code for server-side execution. Scripts have their time and place, and server-side execution is no longer the place.

Client-Side Scripts, HTML, and Cascading Style Sheets

When you use client-side scripts to manipulate HTML and CSS, you are creating dynamic Hypertext Markup Language (DHTML). You can leverage the client-side Document Object Model (DOM) to manipulate HTML tags and CSS. DHTML, as its name implies, is a way to make your HTML and CSS displays more dynamic. The W3C (to the rescue again) has worked toward a DOM Specification. The standard will increase the compatibility of your DHTML on multiple browser types (IE, Netscape, and so forth).

The Windows Script Host

The client-side script that I just discussed dealt with "running" the script code on the client side, in the browser. Well, there is another use for script code: You can use script code with the Windows Script Host (WSH) ^[14] on your regular desktop.

The WSH approach to scripts actually reminds me quite a bit of my mainframe CLIST days and even of my Windows DOS batch (BAT) file days. In each of these cases (CLIST and Windows DOS batch), you create a text file, save it, and execute it. That's it ”no compiling. So, with WSH, right on your desktop you can use the Notepad editor (or any other editor), type in some VBScript code (or even JScript), and save the file. Then double-click and run the file. Optionally, you can execute the file from your Command Prompt window (click the Start button and select Run).

Of what use are these "stand-alone" script files? Well, other than making it easy for people to create script viruses (remember the I Love You.txt.vbs virus?), they can help you create very friendly and safe routines to automate user and administrative tasks ”just like mainframe programmers do with CLIST.

If you want to experiment a little, open Notepad and then type in the following four lines of VBScript code:

 Dim obj Set obj = WScript.CreateObject("InternetExplorer.Application") obj.Navigate "http://www.EclecticSoftwareSolutions.com" obj.Visible = true

Next , save the file with a .vbs extension (e.g., SampleWSH.vbs). Then double-click the saved .vbs file. This little VBScript logic will open an instance of IE (using the Windows Script Host object model) and navigate to my Web site. Of course, this will only work if you have the IE browser installed and you have an Internet connection. Don't worry if you don't understand the actual syntax of the preceding VBScript code. I provided this sample just to demonstrate the power of a very small WSH script file.

Caution

I don't advise sending any file attachments in your e- mails that have the .vbs file extension. Your network e-mail system will likely detect the script file and send you a nasty warning. It's not that script files are bad, it's just that some people use them in bad ways sometimes. So, create them, have fun with them, but just don't try to send them through your e-mail system.

How Many Prerequisite Languages Are There?

You have gone from UML to HTML to XHTML, and you'll move on to XML in the next section. For those of you in shock from the seemingly large number of "extra" languages (and tools) that are included in this prerequisites chapter, allow me to point out that we, too, have many languages on the mainframe. You may be keeping count of the additional languages you need to learn to be a well-rounded .NET Windows/Web developer. Before you get discouraged, remember your own mainframe past: How many extra languages (and tools) are normally required to be a well-rounded mainframe programmer? When you start counting, remember to start your mainframe tally with JCL being number one. Then keep counting: Dyl280, Easytrieve, CLIST, REXX, CICS, BMS macros, TSO commands, ISPF Dialogs, SDSF, advanced control card syntax for various utilities such as DFSORT, IDCAMS, batch File-AID, and so on.

My guess is that you may question the fact that I have referred to some of these mainframe technologies as "languages." Good. That is my point. Just because some of these Web/Windows platform technologies include the word "language" in their acronyms does not mean that they are full-fledged languages per se ”rather, they may simply require a certain syntax.

Now that you've learned about HTML and client-side scripting, I may have left you with the impression that those two technologies combined are the only tools that you need to do all of your Web page development. Well, for basic Web pages, there was a time when this was true. However, the trend has been to incorporate more modern, more flexible technologies into your Web page development arsenal. Among the technologies topping the list is the one I discuss in the following section: Extensible Markup Language (XML). Striving to make the best of your .NET development experience, you will want to learn this additional technology.

^[12] If you are targeting IE version 5.0 or later, you can set the LANGUAGE attribute of the HTML script element to XML (or to one of the other choices previously mentioned).

^[13] Validation code is just scratching the surface of script code usefulness . However, keep in mind that if a security-conscious user disables script support on his or her browser, your Web application may not perform as you expect it to.

^[14] Yes, this topic has little to do (directly) with .NET programming. However, I do believe that removing any potential misunderstanding can be helpful to your .NET retraining effort. With all of the concern that you will have about scripting (in the browser when doing client-side logic), I felt it important that you know the difference between the common uses of the term "scripting." Besides, scripting with the WSH is a powerful and useful technique to add to your arsenal ”for the proper time and place.