In this interview, we discuss the remarkable tool modernization journey of NAV (Norwegian Labour and Welfare Administration), where Beta Systems seamlessly transitioned from CA Spool using modernised tools, resulting in major cost saving alongside an enhanced mainframe. Join us in this story as we explore how this successful transition has transformed NAV’s operations and elevated efficiency to new heights.
Meet Jens-Jorgen Benedikt Rask, an IT veteran with over 30 years of experience. He has worked in various areas such as Storage Management, Job Scheduling, Output Management, and more.
For the past 27 years, Jens has specialized as a Presales Consultant at the software solution company Beta Systems. Due to his extensive experience, Jens-Jorgen has played a pivotal role in guiding the organization through successful transformations, bridging the gap between legacy and modernized mainframe tools. This conversation uncovers the triumphs of a project which delivered extensive benefits and showed the importance of tool modernization.
Can you tell us about the background of the project in NAV ? (TCP/IP print solution using _beta doc|z on IBM z/OS) ? Why is this project interesting and relevant?
The project at NAV was initiated because of costs. The former vendor had asked for a major price raise and the contract with that vendor had to be renewed at the end of the year. At that time we had a maximum of 6 months to do the migration using _beta doc|z on IBM z/OS.
NAV has around 20.000 users that print reports on a daily basis. The reports are printed to a windows server and the users can only pick up the reports when identifying with a smartcard. The challenge in the project was that no user should notice any change in the software behind the curtains, ie. the user should not do anything different from the former vendor to our solution.
Our products were already able to cope with the challenge of migration, but a special development (that is now available for all other customers) was developed to make the migration and the use smoother.
Today – as opposite of before – the solution is automatically updating when a new printer is installed, and user management is also done automatically.
How does _beta doc|z differentiate from other output and log management systems for IBM z/OS?
Beta DOC|Z is constantly refined and is one of the best performing output management systems on Z/OS today. The output management system is able to split, bundle and distribute reports to a very high number of users and printers.
Beta DOC|Z is also able to connect to our Beta UX products (DOC|X and LOG|X) – so distribution on open systems is also a part of our solution. It is still developed and enhanced to match all customers’ needs and challenges.
What were the architectural or organizational obstacles that you needed to consider when implementing _beta doc|z, and how did Beta Systems address them?
At NAV there was a solution that was used for security when printing reports – called Papercut. This product was integrated into the former solution and one of the challenges was that the customer did not want to make any changes to this product to integrate the Beta solution.
Another architectural challenge was the former products integration into the security system (RACF) when new printers and new users were created.
We solved the first challenge by making the output have the exact same metadata as in the former solution. For Beta DOC|X this was not a huge challenge since we have access to all Z/OS metadata for print.
The second challenge was in the former solution done by several batch jobs that were reading the RACF user database and the Printers from a file on the mainframe. In our solution this is all dynamically done so no extra batch jobs need to be run. The user is a dynamic field in our solution as well as the printer. The only time we need to do a manual insert of an object is when/if a new printer server is installed – this is a very small change that takes less than a minute to define.
How did you perform discovery and transformation of such a large number of definitions? What led to the idea and how did it lead to implementation?
Beta Systems received the definition files from the customer in the beginning of the project when we were able to analyze all the definitions of users and printers.
The architecture of Beta DOC|X showed out to be a better way of implementing both users and printers as we have the possibility of splitting the naming from the physical IP Addresses and therefore the number of printer definition went down from 34000 printer definitions to 7!
The number of printer server definitions went down from 2400 to around 200.
All the above was achieved due to dynamic fields in Beta Doc|X.
What benefits have you seen since implementing a modernized tool, such as improved performance or cost savings?
There has been a major cost saving in license of the software compared to the former vendor.
In performance we have seen a saving of around 10% CPU usage. This is mainly because the TCP/IP modules have been greatly improved over time in Beta Doc|X and inside its architecture.
There are also savings on the maintenance of the former programs used to integrate to RACF etc., as these batch jobs are no longer needed.
The daily maintenance is down to a minimum as new users and new printers are dynamically added. Before the migration, all changes had to be made manually and a restart of the print system had to be done to add the new printers and users.
What tips and tricks would you give to other organizations that are considering modernizing their mainframe output and print management systems?
It is always a good idea to investigate if there are better solutions on the market – when some kind of internal or external change is imposed to the organization. If a change is needed it is worth considering if this change is of a magnitude and where it would make sense to look at other solutions.
Beta systems is one of the only vendors that are still developing and enhancing their mainframe solutions – meaning that there is always a possibility to upgrade to a more modern solution than the one already installed.
Which part of this project were yourself and your team most passionate about?
I think we were most passionate about the accomplished automation – maintaining the system is so much easier than before.
And of course, the fact that the main critical factors of the project were met. These were the short implementation time that had to be met and the fact that no users actually felt any changes when the system migrated. This was a critical success factor for the customer, as educating 20.000 users in a short time was almost impossible and expensive.
I am really proud we made it happen.
