db2 for z/os FL100 - wlm - datasharing

Chris Hoelscher

db2 for z/os FL100 - wlm - datasharing
I would appreciate assistance with or a manual explaining how WLM determines what subsystem members are eligible to receive distributed threads:

Obviously? if a member is down WLM would not route distributed work there
If DDF is deactivated on the member, does WLM know enough to NOT send work there? Or is WLM blind to the DDF status??
Here is the situation
We have a server that sends work randomly to all eligible members - and sends persistent threads to ensure the member is up (and resends if it determines the persistent task is stopped or cancelled)
When we attempt to shut down the member (even in force mode) it doesn't come down because of these persistent threads
We don't want to shut down the server - we want to allow threads to continue to the other members not shutdown - but we don't want threads to abend because WLM sends them to a ddf-disabled member

So - if we disable ddf on a member - will that alone stop wlm from sending work to the member? (we can (hopefully) cancel the threads already in the member - and then get a clean shutdown on this member (and do a light startup to be safe)
What we don't want is to disable ddf - but continue to have wlm route work to this member and have all the threads (10000+) abend because the member isn't accepting new work thru DDF

If some other product (tcpip) ? determines which members are eligible to receive work, then I need help


Thank You,
Chris Hoelscher
Lead Database Administrator
IBM Global Technical Services
T 502.476.2538 or 502.407.7266

David Simpson

db2 for z/os FL100 - wlm - datasharing [EXTERNAL]
(in response to Chris Hoelscher)
I’m not an expert on this but it probably depends more on your VIPA configuration if the members are on different LPARs.

From: Chris Hoelscher [mailto:[login to unmask email]
Sent: Thursday, July 2, 2020 5:39 PM
To: [login to unmask email]
Subject: [DB2-L] - db2 for z/os FL100 - wlm - datasharing [EXTERNAL]

I would appreciate assistance with or a manual explaining how WLM determines what subsystem members are eligible to receive distributed threads:

Obviously? if a member is down WLM would not route distributed work there
If DDF is deactivated on the member, does WLM know enough to NOT send work there? Or is WLM blind to the DDF status??
Here is the situation
We have a server that sends work randomly to all eligible members – and sends persistent threads to ensure the member is up (and resends if it determines the persistent task is stopped or cancelled)
When we attempt to shut down the member (even in force mode) it doesn’t come down because of these persistent threads
We don’t want to shut down the server – we want to allow threads to continue to the other members not shutdown – but we don’t want threads to abend because WLM sends them to a ddf-disabled member

So – if we disable ddf on a member – will that alone stop wlm from sending work to the member? (we can (hopefully) cancel the threads already in the member – and then get a clean shutdown on this member (and do a light startup to be safe)
What we don’t want is to disable ddf – but continue to have wlm route work to this member and have all the threads (10000+) abend because the member isn’t accepting new work thru DDF

If some other product (tcpip) ? determines which members are eligible to receive work, then I need help


Thank You,
Chris Hoelscher
Lead Database Administrator
IBM Global Technical Services
T 502.476.2538 or 502.407.7266


The information transmitted is intended only for the person or entity to which it is addressed
and may contain CONFIDENTIAL material. If you receive this material/information in error,
please contact the sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil rights laws and
do not discriminate on the basis of race, color, national origin, ancestry, age, disability, sex,
marital status, gender, sexual orientation, gender identity, or religion. Humana Inc. and its subsidiaries do not
exclude people or treat them differently because of race, color, national origin, ancestry, age,
disability, sex, marital status, gender, sexual orientation, gender identity, or religion.

English: ATTENTION: If you do not speak English, language assistance services, free
of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios
gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711).

繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助
服務。請致電 1‐877‐320‐1235 (TTY: 711)。

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis èd
pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711).

Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej
pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711).

한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로
이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.
-----End Original Message-----
________________________________
Please note: This message originated outside your organization. Please use caution when opening links or attachments.

Jorg Lueke

RE: db2 for z/os FL100 - wlm - datasharing
(in response to Chris Hoelscher)

This is the text for MODFIFY DDF Stop which should do what you want. But these things can get complicated depending on exactly how threads are distributed via the sysplex. I would test this method in dev and cross my fingers

STOPDb2 stops accepting new connection requests to the specified alias. Existing database access threads that process connections to the alias remain unaffected. Inactive connections related to the alias are closed.

A stopped alias is marked ineligible for starting and does not start automatically when DDF starts. If the subsystem is part of a data sharing group, Db2 de-registers the alias with WLM and Db2 stops participating in sysplex workload balancing for connections to the alias.

 

Db2 Dba, Sysprog, Architect

https://www.linkedin.com/in/jorg-lueke-8b391b4/