012 Steve Will talks IBM i Power10, “New Nav” and a whole bunch more…

012 Last week was a BIG week – IBM released the new Power10!  And we are so excited to have Steve Will, Chief Architect – IBM i Operating System, back on the show this week to share some of the exciting IBM i enhancements.  Tune in to hear more about the new Power10 E1080, the “New Nav” – the re-invented Navigator for i and much more!Steve’s contact information and social: Steve Will/Rochester/IBM@IBMUS, [email protected] @Steve_Will_IBMi on Twitter Blog: http://bit.ly/You_and_i_blogOne incredible Th(i)ng!  Products, gadgets, recipes, music or things we are loving right now.Tony’s picks for this week:ShopVacs – Tony’s been cleaning house selling his Long Island home.  Best vacuum you’ll ever buy!  Check them out online or head to your favorite hardware store!Peg’s pick for the week:   Running the 10-mile race at the Medtronic Twin Cities Marathon on Oct 3, 2021.  It’s Peg’s first organized road race in 2 years.Steve’s pick for the week:Cruising Alaska AND taking a helicopter over to a glacier for a 2-hour hike!  Steve and his wife cruised with Royal Caribbean Cruises.Upcoming Events:POWERUp21 October 4-7 in Virginia Beach, VA.  This event is LIVE onsite and simulcast over the web.  COMMON provides the best in Power Systems and IBM I education – come learn from the most celebrated industry experts in the field.  Head over to COMMON.org for more information.  Bring the family for a little beach time and don’t forget to pack your swimsuit!RPG & DB@ Summit October 20-26, 2021A virtual event focused exclusively on IBM i developers. Join RPG, database and open-source experts for 5+ days of live, interactive, online in-depth sessions for developers. Check out the sessions and the expert speakers and see for yourself.This episode is sponsored by…COMMON https://www.common.org/homeMidrange Dynamics Change Management Software – Built for IBM i modernization! https://www.midrangedynamics.com/Interested in sharing your IBM i story?  Want to sponsor the podcast?  We want to hear from you!  Reach out to Peg at [email protected]

The State of AS400 iSeries Application Modernization

The State of AS400 iSeries Application Modernization Typically our aging AS400 and Iseries applications are stateful. So, if we are looking at iSeries application modernization, is it a mistake to try and simply modernize beautify them retaining their stateful flow, or should we be looking at refactoring them in a stateless direction? Is it really […]

Guru: What Are Workload Groups And Why Should You Use Them?

September 13, 2021

Workload Groups appear to be a hidden gem of IBM i work management. In all my work with clients, I have only encountered one shop actively using workload groups. Introduced in 2010, they provide an additional control on CPU and can also be used to license software products to a fewer number of cores than are active on the partition.

Workload groups are very simple entities; you add a workload group with the Add Workload Group (ADDWLCGRP) command. You just need to give it a name and how many processor cores, called the processor limit, can be used by that workload group. The processor limit is in whole units and can be from 1 to 256. To see a list of all the workload groups on a system, use the Display Workload Group (DSPWLCGRP) command.

Once the workload group is created, it must be associated with a workload. A workload can be:

A subsystem and all jobs that run in that subsystem.
In the 7.2 release, this association is done by creating a data area named QSYS/QWTWLCGRP that contains the subsystem name and the workload group for that subsystem. Once the data area is created, the subsystem must be ended (if active) and started again for the association to take effect.

In 7.3, IBM enhanced the Create (CRTSBSD) and Change (CHGSBSD) Subsystem Description commands to include a WLCGRP parameter. An active subsystem no longer needs to be ended for the change to take effect; active jobs will continue to use the prior workload group, while new jobs that are started will pick up the change.

In all releases, message CPI146C, subsystem is using workload group, is logged in the job log of the subsystem monitor job.

A specific job.
The Change Job (CHGJOB) command has a WLCGRP parameter to associate a workload group with a specific job. The change is immediate for that job.
Jobs that have their attributes defined by a job description (7.4 and later)
The Create (CRTJOBD) and Change (CHGJOBD) Job Description commands were enhanced with the WLCGRP parameter in the 7.4 release.

Let’s look at the how workload groups can control CPU usage. Traditional work management controls for CPU are in the class object. Knobs and dials labeled maximum CPU time, time slice, and run priority controlled how a job could use CPU. These are good controls, but a low priority job can still consume a lot of CPU if there isn’t higher priority work running. A group of low priority jobs in a subsystem could all contribute to high CPU utilization. When you associate a workload with a workload group, all jobs in that workload will be limited to using no more of the processor time than specified in the processor limit.

Another use of workload groups to control CPU usage involves ad-hoc queries. Assume you have a set of users who routinely need to generate various reports against production data. These queries may be created on the fly and may be poorly written and rather expensive to run. If you can isolate these users into a specific subsystem, perhaps by routing work by user profile, that subsystem could have a workload group associated with it to constrain the amount of CPU resources used by these ad-hoc queries. The users can still access the data and generate their reports, but their impact on the system is better controlled; their queries may simply take longer to run.

Workload groups can also save money. For example, perhaps you have a partition with 24 cores and are using IBM’s MQ product. You do not want to license MQ for 24 cores because of the expense and because there is a lot of other work happening on that partition. With workload groups, you can isolate that MQ workload into its own subsystem and associate a workload group with that subsystem. This allows you to license MQ only for the number of processors specified in the workload group. The Add Workload Product Entry (ADDWLCPRDE) identifies the license term and feature of the product that is limited by the number of processors defined for the workload group. A Remove Workload Product Entry (RMVWLCPRDE) command is also available. IBM has an older document on licensing MQ with workload groups that is still applicable. I used MQ as an example, but using workload groups for licensing purposes is not limited to MQ.

Finally, it may be puzzling why the workload group commands and parameters have a C in them (WLCGRP). During development, IBM used the term ‘workload capping groups’. The commands and parameters had been set in stone, but shortly before the function became available, they simplified the name to ‘workload groups’.

Dawn May is a leading authority on work management, systems management, performance, and diagnostics, with intimate knowledge of the IBM i operating system developed through her distinguished career with IBM. She focuses her skills on helping companies troubleshoot issues and plan for the future while teaching them how to get the most out of their IBM i systems. To learn more about PDI and how to use it, or for assistance with performance issues, visit her Websitedawnmayi.com, to review her offerings.

RELATED STORIES

Manage Workloads Better With Workload Groups

Workload Groups And Performance Considerations

Workload Group Configuration With IBM i 7.3

Setting A Usage Limit With Workload Groups

Managing Workload Groups

Tags: Tags: 400guru, FHG, Four Hundred Guru, IBM i

As I See It: The Misinformation Crisis
Thoroughly Modern: Making The Case For Code And Database Transformation

Managing the DevOps process on IBM i with TD/OMS

Tell me about TD/OMS…

We’ve published a number of posts over the last few months about DevOps and TD/OMS.

But, what is TD/OMS?

TD/OMS is a collaborative multi-platform software change management tool from Remain Software. It supports change and application lifecycle management on IBM i.

 

So, what is DevOps then?

DevOps helps you design the software application lifecycle process.

It’s a way of working that takes you from idea, to change, to test and then into production with deployment.

DevOps is a set of practices used by developers and IT teams to speed up the development process. The whole process of a change request is redefined, with the aim of bringing changes into production as soon as possible.

Learn more about DevOps here.

 

How about DevOps and IBM i?

For IBM i teams, introducing a DevOps process can require a cultural shift.

In DevOps, the whole team is responsible for getting changes into deployment, so developers and operations teams are no longer working in silos.

The goal of DevOps is to design a process that will make change management as smooth as possible, by moving the change back into production as quickly as possible, and automating as much of the process as possible.

Many enterprise IT teams value IBM i’s secure, reliable and flexible development platform.

Here’s a step-by-step process of managing DevOps on the IBM i.

DevOps makes the application change management lifecycle much faster and more efficient than older change management processes.

 

What tools do I need for managing the DevOps process on IBM i?

We’re obviously a touch bias, but TD/OMS is a cost-effective and easy to use change management tool, covering the complete application development cycle, from development and testing to acceptance and deployment.

It follows industry DevOps change management standards and adapts them for IBM i, enabling businesses of any size to go to market quickly, with high-quality software applications and minimal bugs.

Not only does TD/OMS support DevOps on the IBM i, but it also helps non-IBM i developers on the likes of Windows, Linux and Unix to be part of the whole change and application life cycle management process.

If there are high-level tools in the company, then TD/OMS can also be included in that part as a plugin, and the entire DevOps process can be managed from a central dashboard in TD/OMS.

 

TD/OMS features & benefits include:

Graphical impact analysis, to better understand the impact software changes may have
Double Byte Character Set (DBCS) for universal language support
Rollback and recovery support that allows you to return to a previous software version or production/test environment state
BIRT technology platform, for data visualisations and reports that can be embedded into rich client and web applications
Multi-platform support with out-of-the-box, automated deployment for any TD/OMS configured environment
Automatic database update mapping
Multiple options for comparing and merging sources
Software change management for  both in-house and third-party applications.

Discover how TD/OMS can support your application change management DevOps process on IBM i.

The post Managing the DevOps process on IBM i with TD/OMS appeared first on Proximity.

Verified by MonsterInsights