Modernization for a COBOL/400 shop

260 pts.
Tags:
COBOL/400
There is a (another) study going on to try to determine how we should best "modernize" for the future. We have been a COBOL and CL shop for more than 30 years, but the "dinosaurs are dying off", kids in school don't learn COBOL anymore so thus another study...Someone selling XYZ servers would recommend a move to .NET or C# on their box and likewise a AS/400 person may encourage Java on the 400 box. I am in search of an unbiased view. Of course we are all comfortable with the 400 view and are resistant to leaving it behind. I am not looking for a recommendation based on this post, just hoping some could share briefly about their own modernization journeys. Much thanks in advance to anyone that would share their thoughts, --- Not dead yet dinosaur

Software/Hardware used:
AS/400, COBOL, CL

Answer Wiki

Thanks. We'll let you know when a new response is added.

This is the 3rd time I am entering this response. I’m putting it here because when I put it in the Discussion box, it keeps disappearing.

=========

There are many products available to assist you in building dashboards and to easily create web interfaces to your AS400 data.

I would look at doing some of that to help change the perception that the AS400 is not a modern machine.

The last place I was at had many COBOL programs which we slowly phased out by rewriting them with RPG programs.

I would suggest you hire new staff that have the skills to do these tasks for you. They can exchange knowledge with your current staff so that you have a good foundation for moving forward. 

Discuss This Question: 20  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • philpl1jb

    No matter what envrionment you choose,  new people need to learn a bunch of stuff.  Nothing is more straight forward to learn then the AS/400 and Cobol.  No system on the market is as reliable as the 400.

    You have a satisfactory system any move would be risky.  Pick a few good people and train them .. remember a lot of AS/400 programmers were in accounting.

     

     

    49,980 pointsBadges:
    report
  • CharlieBrowne

    I agree with Tom's statement below.

    Are you running all home grown software or a package?

    What is the goal of your "modernization"? NO more green screen, dashboards, BI, some web accesses? And the list goes on.

    You must first define your destination before you start your journey; else you will never get there. Once defined, it is easier to pick the right path and tools for the journey?

     

    41,380 pointsBadges:
    report
  • LetItBe

    Charlie Brown - We are running highly customized and evolved homegrown systems.  There are not any "Off the Shelf" replacement options. Besides, COBOL and CL, we have many queries used for reporting and also creating file output are used as input files for subsequent processing.   

    For many users, a more "web-like" interface is desired, execs want dashboards...The main concern is to be able to "sustain" and grow our system another 30 years into the future, after current IT people have retired and to take advantage of all the new (better) whiz bang ways of doing code.      

    I am not looking for a specific recommendation - perhaps I am looking in the wrong place, wanting to hear brief summary of other people's experiences, particularly AS400 COBOL people, for we are, indeed, the spotted rare dinosaur. 

    260 pointsBadges:
    report
  • CharlieBrowne

    There are many good products on the market to allow you to build dashboards and do a web interface to the AS400. Doing this will help you get over the perception that the AS400 is not a modern machine.

    The last shop I was at had many COBOL programs, we slowly replaced them with new "Modern" modules that where more flexible and where in RPG.

    I would set a priority list of the steps you can do to resolve your issues. Many get a product for dashboards and either train someone from your staff, hire a new person, or contract with someone just to get a few done.

    New hires would have the skill set to write new code in the way to replace the COBOL. This would be an ongoing long term project.

    41,380 pointsBadges:
    report
  • LetItBe
    Has this thread been closed?
    260 pointsBadges:
    report
  • CharlieBrowne
    No, are you requesting additional information?
    41,380 pointsBadges:
    report
  • philpl1jb

    There is only one environment that you can be certain will run 2013 code in 2043 without major conversions.

    49,980 pointsBadges:
    report
  • TomLiotta

    I'm as much a "COBOL dinosaur" as anyone, doing my first COBOL 40+ years ago and being fairly regular at it since. My first AS/400 COBOL shop experience began in September 1988.

    What are you thinking in terms of 'modernization'?

    ...we have many queries used for reporting and also creating file output are used as input files for subsequent processing.

    To me, that's a big trouble indicator. Can you describe your "queries"? Are those Query/400-style *QRYDFN query objects creating printed output or outfiles? If so, they should probably be at the very top of your list of things to eliminate.

    Delete every one of them and replace them with 'modern' functions. They should have been gone before the turn of the century. How many query outfiles can not be replaced by creating a SQL VIEW instead? How many query reports can not be replaced by SQL and a basic Report Writer (which you've had native for almost 20 years for free while possibly paying extra for Query/400 or a similar product)?

    When bringing up elements such as "...selling XYZ servers would recommend a move to .NET or C# on their box...", it directly implies re-architecting the back-end. A secondary implication is that the back-end itself could be moved to a "XYZ server".

    A move means re-architecting plus migration. But it should be far easier for you to do the re-architecting on the AS/400 itself. For any 'modernization', it's work that has to be done anyway. Why not do it as a phase that stands on its own? And if a migration later becomes a reality, a huge part is already done. It's far easier to change platforms when the database is already defined in a cross-platform way.

    And consider what having a 'modern' database definition means to a .NET or C# developer of a user interface. It's almost irrelevant if the database is still on the AS/400. For you AS/400 developers, business rules can be defined in DB2. Business logic can be in stored procs, UDFs, triggers, or whatever, in DB2 on the AS/400. (Much could even be written in COBOL, possibly by cloning sections of existing code.)

    With the database modernized, the user interfaces become far easier. If a telnet window is currently used on a Windows PC, where's the problem with a browser window on a Windows PC to present data? ...or any GUI presentation on a Windows PC? It's going to be the same presentation platform no matter what.

    Well... except once the database is modernized, it opens presentation up to platforms other than Windows PCs. Especially for a browser, Android tablets and iPhones and just about anything become reasonable. Even iSeries Access emulator program displays become easier.

    Once the database defines the logic, the presentation layer always becomes easier.

    So, again, what are you thinking in terms of 'modernization'? Fixing what you have to make it be 'modern'? Or replacing it entirely?

    Tom

    125,585 pointsBadges:
    report
  • LetItBe

    Charlie Browne –

    I have obtained demos of different products that I have used to create dashboards and web interfaces created from my DDS with COBOL running in the background.   The dashboards were presented to management with favorable responses.  Ultimately, the product was not purchased.  Those making decisions (or not making decisions) decided not to pursue that – and that we should hire consultants to do another study to help us decide what to do.  That is where I am currently.  I am not in a position to make a decision, but would like to be able to provide some alternative ideas. 

    Those hired for this latest study speak in generalities and catch phrases saying the AS/400 is ancient architecture and needs to be abandoned.  I do not believe that and nothing they have told me has proved it to me.  They are in the business of selling servers and services to help us with this migration into the future.  Not exactly an unbiased study.  (Of course I am biased a bit to what I am used to.)

    Tom –

    We do use old *QRYDFN query for some reporting and data selection for subsequent processing.  I have read your comments in more than one thread about how this should have been abandoned 20 years ago.  The reality here and some other places is that the use of query is still in active use – we do not know how or what to do with it.  20 years ago technical conferences were eliminated – trying to keep all the balls in the air and lack of training has created the current environment.  I’d rather not be scolded about what I should have done.  I want to learn newer, better ways of working.

    I do not know how to define my database in a “cross-platform way”.  I do not know how to define business rules in DB2 on the 400.  I need to learn how to do that.  My IT shop is very (too) small BUSY but smart group of people needing direction and information.

    One of the primary reasons for the modernization study is the belief that COBOL programmers are aging out of the workforce, colleges no longer teach COBOL, secondary reasons would be that management and users desire less green screen and more web like interface and also the desire to manage a customer website that from its inception has been managed and controlled by an outside company.  That website gets a daily refresh of data from our iSeries.

    Replacing what we currently operate (quite successfully) on is NOT the end goal unless it is determined that it is necessary to do so.

    All –

    I would like to find information from other shops that were similar to mine and how they have modernized their systems.  Living in Bedrock, I am not sure where the Jetsons hang out to discuss such things. 

    I have learned a lot in this forum and greatly appreciate constructive opinions and advice.

    Thank you.  

    260 pointsBadges:
    report
  • philpl1jb

    Compnay I'm associated with is writting web / java based front ends

    All gets are RPGLE (could have been COBOL but this is an RPG shop) - stored procedures

    All puts call a program which manages the put.  It calls an edit program to verify the data and a write program to write the data.

    This gives us an opportunity to grab all our business logic and put it in places where it can be used multiple times.  Meanwhile we continue to use our existing programs and platform until the new app is ready and proven.

    Hope this helps.

    49,980 pointsBadges:
    report
  • LetItBe

    Phil –

    Thanks for posting.   I have a few questions. 

    Are you saying the company you are associated with is moving from RPG to Java?

    When you say “all gets are RPGLE”, do you mean inputs are handled with legacy RPG code and outputs are done with JAVA?

    We have discussed using this kind of approach, where the “outputs” are done first in the “new world”, with the “Input” being converted/rewritten last.

    When the “new app is ready and proven” will it still live on a 400/iSeries/I? 

    All -

    Code converters have been mentioned and I have heard bad things about those. 

    My own impression is that the database will have to be converted to the “new world” (to us) where fields are stored as date formats, etc. instead of the way they are currently 8 character number fields for dates with edit codes etc.  I know that SQL makes use of date formats and such instead of me coding it to be processed as a date.

    I have heard that code converters produce bad code, but my personal view is that I need to write the code in the “new world” – I understand, intimately, all the details of why the current system is coded as it is, I know what it good, what could be better and what is bad – I need to understand just as intimately the “new world” code.  Having a software converter or consultant come in and do it (quickly and/or to save money?) is not going to help me understand it and maintain and improve it after the big project is “over”.

    Do we really have to leave the 400/iSeries/I behind in order to “modernize’?  That is the biggest question.  Someone in the business of selling iSeries/services may say absolutely not.  Someone selling ABC Servers/services is telling me, absolutely yes.  I suspect both ways are absolutely possible.  Who is to say, objectively, what is best?

    260 pointsBadges:
    report
  • philpl1jb

    The new user interface is web programs with java code but they could be any front end development system. 

    When they need data they called stored procedures on the 400 which are written in RPGLE (this is a get -- where the web page gets data). 

    When they need to store data they pass it to a stored procedures that are on the 400 written in RPGLE (this is a put -- where the web page puts data into the database)

    All interaction with the data base continues to be done in RPGLE.

    Since this is the conversion of a greeen screen appllication the intent is that both the web based and green screen applications will be available for a period of time. 

    There also is a concept that the original green screen programs could be rewritten to use the new getters and putters.

    49,980 pointsBadges:
    report
  • CharlieBrowne

    ""Replacing what we currently operate (quite successfully) on
    is NOT the end goal unless it is determined that it is necessary to do so.""

    There is no reason to replace the current platform. If your "Consultants' tell you that you have too, get new consultants.

    Here is what I see is your current predicament. You have hired someone to define the path you should talk. I'm not sure your destination is completely defined. If management liked the dashboards but does not want to go with them, WHY?

    What exactly is the end product they are after? All data entry in GUI? Only management "stuff" in GUI? Outputs as .csv files that are emailed so they can open them in Excel?

    You need to get that spec'd out first. Then work on trying to implement a step at a time after you have prioritized. Do they want this just to be 'Modern' or are they looking for a ROI?

    41,380 pointsBadges:
    report
  • CharlieBrowne

    Typo in my previous post.

    the path you should talk

    should be:   the path you should take

    41,380 pointsBadges:
    report
  • LetItBe

    Charlie Browne -

     “There is no reason to replace the current platform. If your “Consultants’ tell you that you have too, get new consultants”.

    I would love to have different consultants – the IT staff was given the opportunity to review the responses from the potential consulting companies, but ultimately, the selection of the consulting company was not made by us.  So that ship has sailed and it is frustrating indeed.

    “Here is what I see is your current predicament. You have hired someone to define the path you should take. I’m not sure your destination is completely defined. If management liked the dashboards but does not want to go with them, WHY?”

    Again, not a part of the decision-making process, but I was told that since we will be “modernizing” the system, we don’t need to spend money on the product that I created the dashboards on.  It had been in the budget and goals, but was cancelled.

    “What exactly is the end product they are after? All data entry in GUI? Only management “stuff” in GUI? Outputs as .csv files that are emailed so they can open them in Excel?”

    It became a strategic objective because COBOL programmers are aging out of the workforce, colleges no longer teach COBOL, secondary reasons would be that management and users desire less green screen and more web like interface.  The “in house” COBOL system is an administrative and customer account recordkeeping system.   Another secondary reason is a very strong desire to take over a customer website that from its inception has been created and managed by an outside company.  That website gets a daily
    refresh of data from our iSeries and we receive and process daily customer transactions from the website.

    We have extensive use of query, our files are defined as they were in 1988.  A lack of vision and training has landed us where we are today. 

    I would like to find out what our iSeries options are. 

    I looked into an online course for SQL but it was for use with RPGLE.  It is hard to find training for COBOL people.

    How can I learn to define business rules in DB2?   

    Thanks for continuing this conversation.

    260 pointsBadges:
    report
  • CharlieBrowne

    I suggest you contact Susan and Jon. Two ex-IBMers that do the best education for the iSeries. They also have great contacts should you desire other services.

    http://www.partner400.com/Index.html

    I do not want to post their phone numbers or email address. Get on the mailing list and then you can respond and possibly put a link in your email to this page. You will be working with the best.

    41,380 pointsBadges:
    report
  • LetItBe
    Thank you Charlie Browne.  I have joined that mailing list and sent email to Susan.
    260 pointsBadges:
    report
  • philpl1jb
    Also contact Bob Cozzi. 
    49,980 pointsBadges:
    report
  • LetItBe

    Thanks Phil.

    260 pointsBadges:
    report
  • philpl1jb

    And one more Jim Cooper, Lambton College, Sarnia, ON

    I think Jim's Cobol textbook may still be in print, so he could identify colleges that are still with it.

    49,980 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following