Listen Now

On November 6th and 7th, the German Adabas and Natural User Group met in Darmstadt at Software AG’s headquarter to learn about new features in the October 2018 release. Let’s find out more in episode seven of the Legacy Coder Podcast. German Adabas and Natural User Group Meeting in November 2019 in Darmstadt Overview of the conference Ca. 60 attendees from all over Germany. Again, there were quite a few “young” Natural developers present including my colleague Markus who presented about NatLint, a linting tool for Natural. Currently, 40% of Natural customers work on LUW, 60% still work on the Mainframe. However, according to a different source, only 1/3 of customers are still on the Mainframe. Many different companies attended that run mission critical systems on Adabas/Natural. Hospitals, travel agencies, tax administration, police, banks, insurances, nuclear power plants, microchip factories Hot topics for many attendees Generational Change Rehosting (e.g. Mainframe to LUW) Cost Reduction (e.g. zIIP) Testing Natural Applications Design Thinking workshop with Software AG’s Adam Egger Process for finding and defining the underlying problem we need a solution for. Come up with crazy ideas to get your brain moving. Introduce restrictions later to validate ideas for solutions. Topic: DevOps and Continuous Deployment with Natural What are the main pain points Natural customers have with deploying Natural applications? Manual testing effort Lots of different versions of tools, source, databases etc. Manual deployment effort Adabas gets a new TCP/IP interface Needed to make Adabas ready for containerization. You need a license for Entire Net-Work, if you need more than 4 connections. Non-Natural clients can also use the interface. The TCP/IP interface is as fast as the native IPC interface, if Adabas and Natural run on the same server. Adabas can now be administered via a REST interface. What’s new in Natural and NaturalONE? Due to “NaturalONE and only” Eclipse is now the single editor for programming Natural. Therefore, many missing features had to be added: access to Natural utilities, Error Messages, SYSEXT etc. NaturalONE is now licensed via Natural server. You don’t need any additional license for NaturalONE on the client, no matter how many developers you have. The Ant build files get additional options. Log output while uploading sources to NDV can now be reduced. Modules are cataloged in the correct order (Data Areas first etc.). API management with Adabas/Natural Customers can publish their existing Natural modules as services and re-use them in other applications. No new investments are needed and existing assets can be used. REST Enablement of Natural services is now possible via a restricted version of WebMethods Integration Server that’s shipped free of charge for customers that have an EntireX license. Incoming (e.g. calling a subprogram) and outgoing (e.g. external REST services) calls are possible with this solution. Generating services or service stubs is a matter of seconds and only takes a few clicks. Adabas and Natural on Docker Use Case: Run Natural RPC servers on a scalable infrastructure (Docker and Kubernetes). Adabas is not yet ready to be clustered, but Software AG is working on that. Static code analysis for Natural with NaturalONE and SonarQube My colleague Markus presented the results of his Bachelor’s Thesis about code quality in Natural. He wrote a so called “linter” that checks Natural code for certain code smells, bugs, and security vulnerabilities like unused variables, naming conventions, opening but not closing a work file etc. He uses the Natural parser that’s shipped with NaturalONE. The results of the linting can be viewed in SonarQube but also directly inside NaturalONE. You can also do a few refactorings in NaturalONE with the tool: rename variable, rename subroutine, introduce local variable. What’s next? April 2019: German Adabas and Natural User Group Meeting at ALTE OLDENBURGER AG in Vechta. June 2019: International User Group Conference in Riga. Call to Action Present at a User Group in your country! You don’t have to be “leading edge”! Other customers are also interested in seeing what other companies are doing with Adabas/Natural. Links Permalink for this Podcast episode RSS feed for the Legacy Coder Podcast Software AG’s International User Groups #AdabasNatural2050 at Twitter Official Adabas Community Edition for Docker Official Software AG Natural Community Edition for Docker German Xing-Group: Arbeitskreis Adabas & Natural SonarQube The post German Natural User Group Meeting in November 2018 – Legacy Coder Podcast #7 appeared first on SOA rocks!.

After you have automated the build process for your application based on Software AG’s Adabas and Natural it’s time to take the next step and also deploy the changes to production after each push to Git! I’ll tell you how in the sixth episode of the Legacy Coder Podcast. Recap: Automating your build process with Continuous Integration Listen to Episode 2 of the Legacy Coder Podcast for an introduction on why you should automate everything from compilation to deployment. What is Continuous Integration? CI is a software development practice. Every developer integrates (i.e. merges) at least daily. Each integration is built and tested automatically. This leads to less integration problems and faster deployment cycles. What can go wrong when manually deploying to production (or the next stage)? Finding all the modules that you need to deploy. NAT0082 Invalid command, or Subprogram does not exist NAT0936 Format/length conflict in parameter NAT0933 GDA time-stamp conflict Separating different features in the same modules from each other. Nested functions or other dependent modules can’t be compiled. Compile errors nobody cares about (anymore). Continuous Deployment with Blue/Green Deployments Basic Definitions What is Continuous Delivery? CD builds on top of CI and makes sure that the software can be released at any time. The deployment process has to be fully automated. You just need to push a button to deploy your software to the target environment. What is Continuous Deployment? CD goes even one step further and automatically deploys the software to production if all steps of the deployment pipeline pass. Finally, no more “release days”! What is a Deployment Pipeline? The deployment pipeline defines all the steps (called “stages”) necessary to build and deploy a new version of the software. Usually, there are stages for compiling, testing, packaging and deploying the application. What is Pipeline as Code? Instead of manually creating the deployment pipeline in a CI server like Jenkins you can define all the necessary steps in a domain specific language that the CI server can execute. All the information needed to build and deploy the application are now contained inside the repository. What are Blue/Green Deployments? To be able to deploy to production while users and batch jobs are still using the environment you need another target environment for the deployment process. If everything works as expected you can simply switch to the new environment. Advantages of a fully automated deployment process with blue/green deployments No more missing files, GDA timestamp conflicts, or format/length conflicts. Fast feedback (“Fail Fast”) for the developers, problems are visible immediately. You can reliably and easily roll back to a previous state if something breaks. Interactive tests in the production environment are possible. Running processes and interactive session won’t be disturbed. Deployments don’t need to be done in the evenings or on weekends. No more annoying tasks for the (expensive) software developers. Continuous Deployment for Software AG’s Natural These are the tools we use for our CI/CD process (most are Open Source). Git for version control. Gradle as a wrapper for SAG’s Ant script. Jenkins as a CI server. A custom Java program for compiling Natural on the target environment. NatUnit for unit testing. NaturalONE with additional plugins for NatUnit and staging. Redmine for documentation and communication with subject matter experts. Our former apprentice Jonas built a build lamp with a Raspberry Pi that shows the current state of our Natural build. Implementation at AO AO doesn’t have a single pipeline but 3 different ones for each individual branch: DEV, QA, and PROD. The core stages are identical, but they contain individual steps, e.g. for testing and deployment. DEV: only one target FUser that’s overwritten every time, QA: Blue/Green Deployment with instant switch, PROD: Blue/Green Deployment with nightly switch so the users aren’t disturbed. Before the pipeline can do its job, the developer needs to decide which modules to stage. This is done with Redmine where each changed module is assigned to an issue. An Eclipse plugin developed by ALTE OLDENBURGER searches for all modules assigned to a given issue number and stages them. After a push to Git the pipeline starts. The first stage of the pipeline checks out the latest version of the Natural sources from Git. After that the target Fuser gets erased and recreated from scratch. We use SAG’s Ant script to upload the sources to the target server. We do a full build every time, not an incremental build. Compile errors are formatted as JUnit results so they can be displayed inside Jenkins. We don’t use SAG’s script for that because it doesn’t follow the StepLib chain (for whatever reason). After the compilation additional test data for testing legacy modules that rely on a certain database state are imported into Adabas. Now the unit and integration tests are executed. If the tests pass, the application is deployed into the next “free” FUser. After the deployment the current FUser may be set to the new one. But this depends on the environment. After the release is done there are a few additional steps required, e.g. restarting the Natural RPC servers against the new FUser. After each production release a tag in Git is created. And finally a changelog is generated from these Git tags. How to start with Continuous Deployment for Natural First of all: use Git (or any other version control system, but I would prefer Git). Make your current production sources the new master branch and add development sources on top of that into a new branch. Switch to NaturalONE. Not only do you get a modern IDE with features like Code Completion, but more importantly you get the possibility to use version control from within NaturalONE. Your repository is now the source of truth (and not the server). Make your codebase compile! Don‘t allow any compilation error whatsoever! Add an additional FUser for the automated deployment after each push to Git. Generate the deployment script from within NaturalONE and put it into a Jenkins build. You don‘t need to create a Jenkinsfile yet. Start small! Start writing automated tests, e.g. with NatUnit. By the way: It’s open source! Feel free to use and modify it. https://sourceforge.net/projects/natunit/ Recommended reading Links Continuous Integration Continuous integration vs. continuous delivery vs. continuous deployment | Continuous delivery – Wikipedia Continuous Deployment – Scaled Agile Framework DeploymentPipeline Git – a free and open source distributed version control system Jenkins – The leading open source automation server Gradle Redmine NatUnit Bauen einer Jenkins-Lampe zur Anzeige des Build-Status | Jonas Hellmann The post Continuous Deployment with Natural – Legacy Coder Podcast #6 appeared first on SOA rocks!.

This podcast is called “Legacy Coder” but what exactly is legacy code? I talk about my definition of the term in the fifth episode of the Legacy Coder Podcast. Legacy Code? What is Legacy Code? Definition by Michael Feathers: “Code without tests.” Code of a certain age. Brown field instead of green field. “Old” languages or platforms. Natural, COBOL, ABAP, Mainframes. But also J2EE. Code that’s hard to change or maintain. You can write “new” legacy code. You can also write legacy code in modern languages like Java or C#. Big Balls of Mud, Monoliths. Duplicated code. Hard to separate into individual pieces of functionality for reuse. Different concerns are bundled together (see title image). Code that lacks certain quality characteristics. Not readable, not modularized, not consistent, hard to understand, deeply nested, similar things are done differently, no patterns. How can you get rid of legacy code? Why would you want to get rid of the code in the first place? “Don’t forget – having legacy software is often a sign of success. Your business was successful to last long enough for your software to become legacy.” [Sam Newman] High maintenance costs, aging/retiring workforce, unable to implement new requirements. A big rewrite is almost never the answer. But sometimes. Gradually improve the quality of your codebase. Introduce tests, e.g. compare log files before/after. Integrate the legacy code base into your modern architecture, e.g. with webMethods and EntireX for Adabas/Natural applications. A short piece of Legacy Code in (pseudo) Natural Here’s how many of the old Natural modules I encounter in my day job look like: DEFINE DATA LOCAL USING DDMVIEW END-DEFINE READ IMPORTANT-DDM BY SUPERDESCRIPTOR IF IMPORTANT-DDM.FIELD EQ 1 ADD 100 TO IMPORTANT-DDM.FIELD UPDATE END TRANSACTION ELSE ESCAPE TOP END-IF INPUT USING MAP 'OUTPUT' END-READ END Database access, business logic, and the presentation of the results to the user (UI) are all bundled together into a single module. This becomes a maintenance nightmare quickly and is very hard to test because the individual concerns can’t be separated for testing. This module could be split up into 5 different modules that only do one thing, can therefore be reused in different scenarios, and can easily be (unit) tested: Reading the database (e.g. subroutine READ-DATA) Processing the data, a.k.a. your “business logic” (e.g. subroutine PROCESS-DATA) Saving data to the database (e.g. subroutine SAVE-DATA) Showing the results to the user (e.g. subroutine DISPLAY-DATA) Orchestrating the individual steps to implement the whole use case (the main program) Here’s how the refactored main program would look like: DEFINE DATA LOCAL USING ARRDATA END-DEFINE PERFORM READ-DATA ARRDATA PERFORM PROCESS-DATA ARRDATA PERFORM SAVE-DATA ARRDATA PERFORM DISPLAY-DATA ARRDATA END Recommended reading (and hearing) In his book Working Effectively with Legacy Code* Michael Feathers shows different ways of introducing automated tests into a legacy code base. He uses C++ in his examples but the underlying ideas can be applied to any other programming language, too. * Robert C. Martin wrote my all time favourite book for software developers: Clean Code*. If you haven’t read it already, grab a copy now and read it from front to back! No matter what programming language you’re using, you will definitely find lots of ways to improve your existing code in here. * In the very first episode of this podcast I talked about how to unit test your Natural application. In my opinion, that’s a very important step in modernizing a legacy code base. Links Permalink for this Podcast episode RSS feed for the Legacy Coder Podcast Millennials and Mainframes in 2018 and Beyond The post What is Legacy Code? – Legacy Coder Podcast #5 appeared first on SOA rocks!.

Let’s talk about what was presented and discussed at Software AG’s User Group Presidents Meeting and the German Natural User Group in Darmstadt in November 2017 in episode four of the Legacy Coder Podcast. User Group Presidents Meeting What’s the point of the meeting? Planning the International User Groups Conference (topics, date, venue etc.). What was presented by Software AG? Software AG’s revenue is now > 1 Billion. 4,400 employees all over the world. Ca. 25% Adabas/Natural. 70% of the largest 1,000 companies worldwide use Software AG products. ADAMOS: Joint Venture with big machine builders like Zeiss and Dürr. Don’t rip and replace! Modernize! 3 big moves: Adabas/Natural, integration with webMethods, IoT (1 bn. investment). Modern architecture: System of Records, Integration, IoT/AI. Software AG named by Gartner as leader in Streaming Analytics, InMemory Databases. What was discussed with regards to Adabas/Natural? Don’t separate Adabas and Natural. There will be only one conference for both technologies with a single keynote. Max. 30min presentations, time restrictions for information about business, platform, environment. Natuaral customer base: Mainframe vs. LUW: 50%/50% A workshop for Natural developers would be interesting (best practices, architecture, training). A Hackathon will not be possible at IUGC. How to find/meet other customers with similar problems? Topics for IUGC 2018 in Berlin Already 5-6 presentations submitted. NaturalONE (new features, introducing the IDE etc.) DevOps (CI, Docker, etc.) Rehosting (Mainframe -> LUW) Who uses or plans to use Cloud Computing? 2050 readiness award International User Group Conference 2018 in Berlin Registration is open! German Natural User Group Ca. 60 attendees from all over Germany. Quite a few “young” Natural developers were present. The “Generational Change” starts… I’m the new speaker of the German Natural User Group. Topics of the talks zIIP enablement for Adabas/Natural New features of EntireX How to develop your own Eclipse plugins for NaturalONE Plugin: Rename Subroutine New features in Natural und NaturalONE Natural editor will be shut down with release in fall of 2018. There are still many customers that have concerns. Adabas and Natural in a Docker container, started via Alexa Visualizing Adabas Events with ElasticSearch and Kibana RealHtml4Natural – an alternative webframework for Natural build on top of the Natural Native Interfaces and distributed under the GPL-3.0 license. Call to Action Start Tweeting with #AdabasNatural2050 and #IUGC18! Links Permalink for this Podcast episode RSS feed for the Legacy Coder Podcast Software AG’s International User Groups Registration form for IUGC 2018 in Berlin Attendees of the German Natural User Group in November 2017 Generational Change at the German Natural User Group Young Natural developers at the German Natural User Group #AdabasNatural2050 at Twitter #IUGC18 at Twitter The post Presidents Meeting and German Natural User Group – Legacy Coder Podcast #4 appeared first on SOA rocks!.

Why would anyone dismiss the good old Natural editor and switch over to NaturalONE? Let’s find out what features NaturalONE has to offer in the third episode of the Legacy Coder Podcast. Why should you switch over to NaturalONE? Increased developer productivity Use Copy and Paste (duh!) for high quality Natural programming Syntax Highlighting will help you understand the source code faster. Make use of intelligent search and replace features with regular expressions. Code Completion makes you type way less than before. Code Navigation (jump to a variable definition etc.) lets you explore the code base with a few keystrokes. You can use Code Folding for focussing on the really important stuff. Multiple compile errors are displayed instantly without uploading the source to the server. Repository based development Finally develop software like the cool kids do! Every code change is documented and can be rolled back with just a few commands. It can even be attached to an issue tracker like Jira or Redmine. You can try out new things in an isolated environment. You can automate your coding with code generators like Xtext. Modernize your development environment Share knowledge and open up towards other (maybe younger) developers (Java etc.). Be and stay attractive as a company to new employees. Automate your build process NaturalONE is Software AG’s platform of choice for the future. The old Natural editor will be shut down! Extendable with additional plugins Software AG’s innovations will only take place in NaturalONE (e.g. Code Coverage, Screen Testing). Attach your IDE to an issue tracker like Jira or Redmine with Mylyn. Use Snipmatch for even less typing. Create your own extensions (e.g. NatUnit) for whatever requirement you have. Recommended reading Automating Your Natural Build Process (with the help of NaturalONE) Recipe for Success: Mastering the Generational Change (you should provide state-of-the-art development tools to retain your staff) NaturalONE – The development environment for Natural: Agile development and DevOps attract new talent (a.k.a. Software AG shuts down the Natural editor) Learn how to do basic programming in Software AG’s NaturalOne. NaturalOne Debugging Links Permalink for this Podcast episode RSS feed for the Legacy Coder Podcast Mylyn (Eclipse plugin for hooking your IDE up to an issue tracker) Snipmatch (Eclipse plugin for sharing code snippets among your teammates) Redmine (open source project management tool and issue tracker) Jira (commercial tool by Atlassian) Xtext (open source framework for writing Domain Specific Languages) The post Modern Natural Development with NaturalONE – Legacy Coder Podcast #3 appeared first on SOA rocks!.

Unit testing with Software AG’s Natural – is that even possible? Let’s find out in the very first episode of the Legacy Coder Podcast. Unit testing Natural applications Why would I want to unit test my Natural code? You get instant feedback whether your code works. That’s fun! You get a safety net for refactoring and optimizing your Natural code. You can catch regression as early as possible. That makes evolving your code base easy and painless. Unit tests can be integrated into your build process (Continuous Integration, Continuous Delivery, Continuous Deployment). Unit tests are the first step on your way to a fully automated build process. What tools are available for unit tests with Natural? Subprogram testing within NaturalONE Only subprograms can be tested. Different “language” for defining your tests. Tests have to be defined manually from a GUI. Tests cannot be executed from within Natural itself. Proprietary software maintained by Software AG. Professional support by Software AG is available. NatUnit – an open source framework for unit testing with Natural Everything that can be called from a subprogram can be tested (subprogram, subroutine, function). Tests are written in the same language that is used for production code. Tests can be written as Natural code with full IDE support. Tests can be executed within any Natural runtime. Open source project that can be extended by everybody – including yourself. There’s no professional support for the framework. What do I have to do differently when writing testable Natural modules? You need more fine grained modularization! You have to decouple the User Interface, Database access, and the core Business Logic from each other. You need to extract the functionality to test into its own callable module. NatUnit in action Here are a few screenshot of our NatUnit Eclipse plugin in action. You can run a NatUnit test from within the IDE. If the tests are successful, you instantly see the famous “green bar”. And if the tests are broken, you’ll definitely notice that, too. Recommended reading I mention this book in the podcast episode: Test Driven Development: By Example* by Kent Beck. It was one of the first books on the topic of TDD and is a short read and still relevant after all these years. * The part of my Master’s thesis about the development of NUNIT. I give a step by step introduction of the test driven development of NatUnit itself including code samples. Here’s a blog post I wrote about NatUnit a few years ago: NUNIT: A Unit-Test-Framework for Natural. It also includes a UML diagram of the framework’s initial architecture. Links Permalink for this Podcast episode RSS feed for the Legacy Coder Podcast NatUnit – Unit-Test-Framework for Natural Getting Started with Application Testing in NaturalONE The post Unit Testing Natural Applications – Legacy Coder Podcast #1 appeared first on SOA rocks!.

Who is this guy and what the heck does he know about Software AG’s Adabas and Natural? I’ll show you in the pre-episode zero of the Legacy Coder Podcast. Introduction to the podcast and myself My experience with Adabas and Natural. I’m programming with Natural since 2003. I’m the president of the International Natural User Group since 2016. I co-authored NatUnit (as part of my Master’s thesis) and L4N. My main job is integrating Adabas/Natural into a modern SOA with webMethods Integration Server. In the last few months I automated and modernized the Natural build process with Git, Jenkins, Java, and NaturalONE. My biggest Natural project so far was the migration of an insurance system from Oracle/Java to Adabas/Natural. I frequently speak at local and international user groups and conferences (e.g. Innovation World, Innovation Tour, IUG). Our Natural code base: ~6 million LOC, ~19.000 modules. My professional experience. I studied business computer science (Bachelor’s degree) and software engineering (Master’s degree). I train new hires and apprentices at ALTE OLDENBURGER Krankenversicherung AG in Germany. I also use a few additional languages: Java, C#, PHP, Ruby. I’m a software architect since 2014. I work as an associate professor for programming and software engineering at PHWT since 2009. My personal life. I’m married. I have two dogs. I like taking photos. I run a podcast for aspiring software developers in German. I organize my own user group and conference for software developers. You can find me almost everywhere: LinkedIn, Twitter, Instagram etc. Links Permalink for this Podcast episode RSS feed for the Legacy Coder Podcast My content hub NatUnit ALTE OLDENBURGER Krankenversicherung AG PHWT My two dogs My podcast: Anwendungsentwickler-Podcast My user group and software conference SEROM Some of my social media profiles: LinkedIn, Xing, Twitter, Instagram, YouTube. Here’s a video about my work at ALTE OLDENBURGER Krankenversicherung AG: The post Introduction to the show and the host – Legacy Coder Podcast #0 appeared first on SOA rocks!.

How can you automate the build process for your application based on Software AG’s Adabas and Natural? I talk about our journey towards a completely automated build from scratch after each push to Git in the second episode of the Legacy Coder Podcast. How to automate the build process for an Adabas/Natural application Why would I want to automate the build process? What hurts should be done more often! No more long integration phases before each release! You’ll get a faster time to market for new features. You can get rid of knowledge silos concerning the release of your application. What steps may need to be automated? Upload (transfering the Natural source code to the server) Compile (CATALOG, STOW, CATALL etc.) Unit Tests (e.g. with NatUnit, see Unit Testing Natural Applications) Deployment (the actual release of the new version on the target stage) Restarting RPC servers or whatever individual steps might be necessary in your environment What tools are available for automating the Natural build process? It all starts with Git or any other versioning control system (Subversion, TFS, CVS). You can use Jenkins for Continuous Integration. Software AG’s command line tools (ftouch etc.) can be scripted. Even the CATALL can be scripted by calling into Natural BATCHMODE. NaturalONE’s ant scripts for uploading and compiling Natural sources. Any additional tool that you might need (Bash scripts etc.) How can I get started? Make your project fully compilable. There can be no compile errors whatsoever. Start with a single step, e.g. automate only the compile step first. Script everything (e.g. with Bash) right from the beginning. You can easily call these scripts from Jenkins later on. Hook Jenkins up to your source code repository. It provides plugins for every major system (e.g. Git, Subversion). Try to automate the build with Jenkins. It’s completely free and easy to setup. Perhaps ask a Java colleague if he can help you. How can you go even further than what’s possible today? Try to automate imports of Adabas data that’s important for your application. Try to automate Adabas schema migrations. Implement feature toggles for more fine grained control over your application’s functionality at runtime. Recommended reading Continuous Integration (introduction to CI by Martin Fowler) Active Record Migrations (see how Rails handles database migrations) Links Permalink for this Podcast episode RSS feed for the Legacy Coder Podcast Git – a free and open source distributed version control system Jenkins – The leading open source automation server The post Automating Your Natural Build Process – Legacy Coder Podcast #2 appeared first on SOA rocks!.