Mainframe to Java

[Sam McMahon]

Hello fellow ranchers,

I am Mainframe/COBOL/DB2 developer with 8 years of experience in coding. As our company is trying to moving away from mainframe, pretty soon I will have an opportunity to convert existing COBOL services to Java. I have started learning Java (for past three weeks) using some web based training available, also I plan to get myself OCAJP 8 certified.

Although I am able to understand the basic concepts (OOPS etc) till now, everything seems new to me 

Given my background, I would appreciate any suggestions on best path forward towards getting certified. Also, do you think its a good idea? Thanks!

[Junilu Lacar]

Welcome to the Ranch!

Retooling can be both challenging and fun. It can also be very frustrating. Eight years is a long time, plenty of time to get set in your ways about how you think about problems and how you write code. Java programming and object-oriented programming in general is an entirely different paradigm from what you're probably used to. It's probably going to be tough.

The good thing is, there's small but vibrant community here and if you like hanging out with a bunch of authors, experienced professionals, and enthusiastic volunteers who are more than willing to give you help and advice, then you have a good chance of getting through this transition with your sanity still intact.

Good luck!

[Sam McMahon]

Thanks Junilu,

Even though it seems new and apparently tough to learn (given where I come from) I am liking it, probably because of the same reasons. It will be fun to explore Java programming.

[Ravi Desigan]

I used to be a Mainframe (COBOL/DB2/CICS) programmer and I put 5 yrs in it.

Now I changed to java and have some solid experience (albeit with a break now).

I think reading books on Java will help with a thorough start.

then probably doing many assignements, and building small to large applications, maybe from a book like Murach's java.

[Sam McMahon]

Thanks for the suggestion Ravi,

I have started with a Java beginners course in Udemy, Will get hold of Murach’s Java Programming too. I am hoping I'd get to build basic java web services in a month or two.

[Jeanne Boyarsky]

Sam,
Welcome to CodeRanch!

One of the nice things about certification is that it gets you to write a lot of code. Another is that it gets you to pay attention to details. Note that the OCAJP is a basic certification. You'll probably need the material on the OCPJP once you get further along. As an author of a certification study guide, I can say that it is important to read a non-cert book first to understand the basics.

General advice on learning to code: write lots of code and play. What happens when you change little things. And ask questions. If you try something and don't know why it works/doesn't, ask here at the Ranch!

[Sam McMahon]

Thank you Jeanne,

Point taken, I am trying to get my head around the Java concepts and coding style. What you said is so true, I am able to understand them by playing with the code myself. I do get stuck every now and then but when I eventually get out of it, the concept stays.

Could you please suggest some non-cert books?
Appreciate the help!

[Jeanne Boyarsky]

I like to recommend Thinking in Java and Murach's Beginning Java because they suggest lots of exercises to try.

[Tim Holloway]

COBOL to Java is one of the more challenging migration paths. COBOL was designed to be English-like, verbose, and deal with mostly discrete values. Java is a descendent of the C programming language, which is terser and more mathematical - C can be considered as a descendent of the FORTRAN and Algol languages that arose in the mid-1950's back when COBOL was first designed and developed.

OOP on the other hand is something that none of the older languages had any notion of. The only OOP languages of that distant era were very specialized and not in general business use. However, it has proven a valuable approach to making the task of building and maintaining ultra-large complex apps possible. A COBOL program traditionally was one long PROCEDURE DIVISION and most of the non-IBM functions were user-written PERFORMs. A Java program is more often a whole raft of class files and almost invariably reaches out to even more externally-supplied classes, both those that are built into the JVM and third-party such as the Apache and Codehaus libraries. While I have seen some attempts at OOP COBOL, and for all I know, it's now part of the standard, COBOL isn't widely used as a new-application platform, so most COBOL code is probably going to be linear code.

In the Java language itself, one of the biggest challenges for business code is that unlike COBOL, Java does not have a primitive numerical type that can accurately represent decimal fractions like IBM COBOL's COMP-3 form does and thus you either have to rely on floating-point or special computational classes. And, lacking the operator overload feature of languages such as C++ and Ada, that means that coding ledger functions that add up pennies and so forth is more tedious and verbose than most math. Then again, you're used to COBOL, so tedious and verbose is probably not an issue.

I will note one "gotcha" when you start dealing with databases in Java. Traditionally, database fields for mainframes were recommended to be fixed-length. That's because back in the old days, your SQL/DDL was coded pretty close to the hardware. Java doesn't support a fixed-length character string as a primitive. The best you can do is a fixed array of characters. More tellingly, the JDBC drivers tend to assume variable-length String objects, so when working with a DB2 or other database in Java where fields are space-padded, you can experience a lot of grief. IBM's drivers, in particular, can be a little too "helpful" in blurring the lines between fixed, space-padded items and true variable-length character fields. I've gotten burned severely on that one.

[Sam McMahon]

Thanks again Jeanne!

[Sam McMahon]

Tim,

First of all, Thanks a ton for the detailed comparison of COBOL and Java. It gives me a better understanding of COBOL's first cousin, twice removed 

I haven't started doing anything complex in java yet, but I have noticed that the individual piece of code (class) is comparatively compact because for most part it calls other abstract classes. I feel COBOL programs like big stones forming a heap, its hard to touch one without moving a few other. They may be sturdy, but the maintenance takes quite a bit of your time and money. We recently did a year long project, and the major change was to increase the maximum number of elements that can be stored in an certain array (Yes it was hard coded in the programs  ), as the programs are tightly coupled we had to change hundreds of them. In modern programming language its not even a problem as there's no limit to the number of elements stored in an array.

[Ravi Desigan]

Hi,

I am not a programming or framework expert, but having enough exposure to either technologies (Mainframe/Java, as well as some 'C'/'C++'), I am taking some liberty to compare the two:

(Experts may feel free to correct me).

1. Write common code into classes: Instead of handling coding individually, identify common logic and write them 'for the programmer' and make it up as part of the language.
2. Any program will require its virtual machine-oriented functionality for fine-tuning, security, runtime access control, etc. So compartmentalize these provisions of the runtime environment and call it as 'Server' -> further divided into Web Container or EJB/J2EE container or a package of both together and provide for these external runtime functions via external files (deployment descriptors, properties files). In the mainframe world, some of this information came via 'JOB CONTROL LANGUAGE'.
3. All instance variables that would be used for program functionality is categorized into 'objects'. All functions that would act on the said 'objects' become the methods on the object.
4. Layer your calls - a typical Mainframe set-up was a stateful (remembers its state) client-server environment. In J2EE world, this is replaced by front-end of interface display and validation of user input data, a middle-tier of programming logic and control of flow and a last tier of database access.
5. The main advantage of modern J2EE framework is that it is 'web-enabled'. It understands various protocols such as HTTP, FTP, SMTP, etc and processes input that comes in any of these formats and returns reply accordingly. This is the functionality that the old-timer Mainframe COBOL lacks, it is akin to a person speaking multiple languages.
6. Most importantly, what is NEW for the Cobol programmer in the JAVA world is how logic need not execute from the apparent single instance of code. In Java world, there can be 'callbacks', 'aspect oriented programming', and other framework-enabled functionalities that do not exist merely in a single, linear piece of code but 'comes in' from various previously set-up building blocks of programming architecture and executes rather 'a-typically'. Even JSF (Java Server Faces) is like this.

I hope I am right in my observation, feel free to correct me, as I already said. Hope this info is useful.

[Tim Holloway]

In OOP, methods tend to be quite small. It's an unusual (and probably poorly-written) method that occupies more than one printed page of code, even heavily commented. And incidentally, Java's JavaDoc comment annotations are strongly encouraged, since they can be used both to create documentation and in the pop-up help capabilities of popular IDEs.

One annoying thing about both FORTRAN and COBOL was their lack (initially) of support for manifest constants. It even became a witticism: "Constants aren't, and variables won't". C repaired that lack via its #define directive and later its "const" attribute. Java uses "final" in place of "const" and the semantics of final aren't quite the same as const, but it's close enough.

Actually, IBM COBOL supported arrays of up to 3 dimensions, but the "array" in Java is actually a 1-dimensional vector, mathematically speaking. The Java array primitive defines a fixed number of slots, which can hold primitive values or object references, depending on the array definition, and once defined, the number of slots is immutable. The Java Vector and ArrayList classes differ in that they encapsulate an array and can be dynamically resized (the encapsulated array is replaced with the new size and values are copied over).

To get the effect of multi-dimensional arrays in Java, you have to explicitly define arrays of arrays. This is more cumbersome than in COBOL or Fortran, but the upside is that you can define heterogeneous or sparse arrays. You have to do all the dirty work yourself, though. If you really want to do serious array processing, you're better off with Fortran or APL.

I don't remember my COBOL well enough and I'm too lazy to grab the manual, but a 2-dimensional chessboard in Fortran would be like so:

INTEGER BOARD(8, 8)

Whereas the equivalent in Java would be more like this:

/**
 * Chessboard as an object.
*/
class Chessboard {
     final int NUM_RANKS = 8;
     final int NUM_FILES = 8;

     // Define board as an object that can only be altered in the constructor.
     final int board[][];

  /* Default constructor. I told you about helping the Javadoc generator!
  */
  public Chessboard() {
     rank = new int[NUM_RANKS][NUM_FILES];

     // Allocate ranks and files 
     for (int i = 0; i < NUM_RANKS; i++) {
          /* Since the cell type is a primitive, it will default to 0.
             Otherwise an inner loop would be required if we wanted to initialize cell objects.
             Like, for example, a cell could be of type ChessPiece.
          */
          board[i] = new int[NUM_FILES];
     }
  }
};

[Campbell Ritchie]

What about this?

int[][] board =
        {
         new int[8], new int[8], new int[8], new int[8],
         new int[8], new int[8], new int[8], new int[8]
        };

A little more cumbersome to write, but there is no need for the loop. Of course none of the subarrays can be marked final. Or even Arrays.fill(...)?

[Tim Holloway]

Campbell Ritchie wrote:What about this?

...

Two things, actually.

First, since the complaint was about the cost of changing array sizes, that's basically the same solution that COBOL was stuck with.

Secondly, compilers these days do loop unrolling as one of their optimization strategies. So the actual generated code is likely to be what you coded anyway, but the total amount of typing is less and it auto-adjusts when you change the constants.

And in my case there's a third thing. When I copy/paste the assignment line and alter the rank indices, I'll almost invariable fat-finger something and end up initializing one row twice and another not at all

I also took advantage of my little exercise to show one of the ways that "final" differs from "const". Making the board a final object means that it's mutable in the constructor but nowhere else. If it had been truly "const", that wouldn't be possible.

I did botch it, though.

This line:

     rank = new int[NUM_RANKS][NUM_FILES];

should be:

     board = new int[NUM_RANKS][NUM_FILES];

[Sam McMahon]

Thank you Ravi, for the tips and the comparison.

Even though COBOL doesn't know classes, we use the similar methodology by putting frequently used functionalities into COBOL utility programs and call them.

[nkosana bohale]

My first post everyone!!! 

Sam,

Your story resonates with me. I'm also a mainframe developer, coding in C, C++ and High Level Assembler.

I've decided to re-orientate away from mainframe technology and towards Java, coupled with other components of Full-Stack Web Dev (JavaScript, HTML5, etc...). I'll be attending a 3 month immersive bootcamp to gain exposure to the relevant technologies. My goal is to build on from there and to attain Java developer certification.

I'll be paying attention to your progress and do hope you keeps us updated.



Thanks to the rest for your inputs.. they've been invaluable.

[Campbell Ritchie]

nkosana bohale, welcome to the Ranch

[William Barnes]

> An IDE is no substitute for an Intelligent Developer.

And nothing is a substitute for a good (graphical) debugger.

[Tim Holloway]

William Barnes wrote:> An IDE is no substitute for an Intelligent Developer.

It's a reference to the conceit that some pointy-haired bosses have that you can buy a fancy IDE full of code-generating "wizards" and use cheap monkeys to do your programming.

I'm all for labor-saving tools and techniques, but it annoys me when they're used as a substitute for doing quality work.

[Chan Ag]

I think studying for Java Certification is a good place to start.

Not that I rate myself greatly in programming skill, but after writing code in PL/1, JCL, DB2 for about 5 years, studying for the certification did give me a decent start. Eventually I didn't write the test cause there were always more things to learn ( and they continue to be and will always be ) and taking up mock tests and the exam started seeming like a waste of time ( it's not a waste of time and actually may help you make a more streamlined progress in your learning but knowing about other topics became far more interesting to me then).

Books, trustworthy tutorials and discussions, the Oracle Java language specifications, and the community of Java programmers are greatly helpful. It's a different kind of a challenge to learn something new in mainframes because of the lack of resources and simulators so learning Java will be a lot easier in that respect I feel. But do not let the vastness of the topics to learn and understand discourage you. That way you will make constant progress.

Write a lot of code. Read a lot of code (yeah I mean it). Critique your code. And write better code next time. When you get a little comfy, critique your approach and design. It's still notebooks and pencil a lot of times. And let the community of experienced and helpful programmers guide you along the way. Someone helped them too.