WMCPA Spring Conference 2023

Did you know you can easily modernize your IBM i experience with IDF? In this session,
you will learn how you can easily:

• Modernize your green screen RPG applications
• Allow your end users to personalize the browser UI by adding or removing columns, changing filters and sorts, and much more
• Develop new features
• Fit your application into the larger ecosystem with lightweight API’s that automatically come with the application and any enhancements you add

This Java-based, multi-user interface, metadata-driven framework provides you with a tremendous amount of functionality in a low-code or no-code implementation.

In days gone by the IBM Supplied program QSTRUP combined with a couple options on CHGIPLA was good enough for most IBM i shops. It started what seemed to be needed and anything else we stumbled through after each IPL. When it was time to shut down a PWRDWNSYS or ENDSBS command took down whatever was running. We were happy. Today though we often see dozens of subsystems running many web servers, other needed batch jobs and services. We see monitors and queue processing jobs and many writers. For security purposes we should be starting only the TCP servers that we need, not all of them. Likely we should not start IPV6 and start things in sequence as well. Further considerations may be needed in an HA environment. These include not starting jobs until iASPS are available and starting different IP interfaces and services depending on production or backup mode of the server. We may want to handle special startup modes while doing PTFs, backups or other system maintenance. In this session we will work with customizing that startup. We'll discuss staring PASE jobs with QSH, web server jobs and more. We'll discuss prestart jobs and autostart jobs. And finally we will also work with sequencing the shutdown of the system. As part of this we'll discuss some simple ways to know what needs to be shut down and smoothly handling that.

PART 2

In days gone by the IBM Supplied program QSTRUP combined with a couple options on CHGIPLA was good enough for most IBM i shops. It started what seemed to be needed and anything else we stumbled through after each IPL. When it was time to shut down a PWRDWNSYS or ENDSBS command took down whatever was running. We were happy. Today though we often see dozens of subsytems running many web servers, other needed batch jobs and services. We see monitors and queue processing jobs and many writers. For security purposes we should be starting only the TCP servers that we need, not all of them. Likely we should not start IPV6 and start things in sequence as well. Further considerations may be needed in an HA environment. These include not starting jobs until iASPS are available and starting different IP interfaces and services depending on production or backup mode of the server. We may want to handle special startup modes while doing PTFs, backups or other system maintenance. In this session we will work with customizing that startup. We'll discuss staring PASE jobs with QSH, web server jobs and more. We'll discuss prestart jobs and autostart jobs. And finally we will also work with sequencing the shutdown of the system. As part of this we'll discuss some simple ways to know what needs to be shut down and smoothly handling that.

Learning Objectives:
1) Learn how to control which startup program will run on your IBM i. 2) Examine the various servers to start and how to control them. 2) Learn options for starting different services. 3) Consider ways to control the startup of your server in different operating modes. 4) Understanding an orderly shutdown of your IBM i server.

2017 Common/IBM Innovation Award winner details how the business needs drove grar.com to modernize its web site using Zend Server and WordPress as a Content Management System (CMS) and dynamic content delivery system for the REALTOR Member and MLS Property searches for its public web site and open source tools like bootstrap to provide responsive design.  The grar.com website services the needs of the residents of West Michigan and 3000 REALTOR® members.  The website had been outsourced to a firm using a customized CMS which limited the amount of updating that could be done by staff, with most access restricted to the vendor.  The content became costly to maintain and updates took too long to be completed.  With the highly dynamic content of the membership and real estate databases, the intel servers could not perform to GRAR standards.  It needed to be in-house and running on the IBM i.