DS8000 administration: daily, weekly and monthly checks
-
Phase 0: Before you start
-
Phase 1: Plan and install
-
Phase 2: Build the storage
-
Phase 3: Copy Services
-
Phase 4: Run it day to day
-
Phase 5: Troubleshooting and career
DS8000 administration is the quiet work that keeps a running system healthy, with short read-only checks every day, a deeper look every week, and evidence filed every month. When it’s done well nobody notices it, and when it’s skipped everybody does.
What you get here is a real runbook with the exact DS CLI checks and what “good” looks like for each. After that you turn the daily check into a small Python report that runs on a jump server and prints one OK or WARN line per item.
The lab has you run the daily and weekly checks by hand first and then through the script. In Break It you fill up a pool and kill a port, and watch the report catch both before any user does.
| Time | You need | By the end you can |
|---|---|---|
| 60 to 75 minutes | The practice shell, Python 3 on your laptop, and Lesson 25 (or any system you’ve built) | Run daily, weekly and monthly DS8000 checks, read their results, and schedule a Python report that warns you early |
What it is, in one line
DS8000 administration is a repeating set of read-only checks (health, capacity, paths, copies, users, alerts, code) done on a fixed rhythm, so problems turn up in your report before they turn up in a ticket.
In Simple Words
The school bus depot
A school bus depot has twenty buses. Every morning, before the children climb on, the driver walks round his bus checking tyres, lights and fuel, which takes five minutes, and he does it even if the bus looked fine yesterday. Once a week the depot manager goes through the logbooks and checks who has a valid licence, and once a month a mechanic changes the oil and files a report so the inspector can see the work was done.
Nobody waits for a parent to ring up and say the bus ran out of fuel on the way to school, because a call like that means the morning walk-round didn’t happen.
DS8000 administration runs the same way. Your health, capacity and path check is the daily walk-round, users, password rules and alerts are the weekly logbook, and the config export, audit log and code level are the monthly service.
Engineer's View
What you check, and where the numbers come from
Capacity. lsextpool shows status as below, exceeded or full. You set the pool threshold with chextpool -threshold, and it warns when the unused real extents fall below that percentage (the default is 15). Give yourself an earlier warning, at around 80% allocated, so there’s time to order or move capacity.
Users and passwords. showpass gives you the expiry days, failed logins allowed, minimum length (default 8) and history, and showuser shows FailedLogin and DaysToExpire for a single account (SG24-8559-01, pp. 183 and 341-342).
Alerts. SNMP takes no more than two trap addresses (chsp -snmp on -snmpaddr, checked with showsp), and you can define up to eight syslog servers (p. 179). There’s no lsproblem command, so you’ll find events on the GUI Events page and the HMC.
Evidence. offloadfile -config exports two files, the advanced settings and the ICS install history (p. 434). For the audit log you use offloadauditlog or offloadfile -auditlog, and offloadfile -perfdata gives you one week of performance data at 1-minute intervals (pp. 391 and 444).
Code. ver -l shows the bundle, named PR.MM.FFF.EEEE, so 10.10.106.0 is Release 10.1 (pp. 400-401). Check it against the latest bundle IBM lists for your model.
Release 10.1 extra. Dual Control (maker/checker) can make a second person approve changes. lsdcreq lists the requests that are waiting, so if you switch the feature on, add it to the daily check (p. 395).
How it works, step by step
1Decide who owns each check
If a check has no owner, nobody does it. Put a name against every line of the runbook, and a deputy for holidays.
The daily checks belong to the on-call storage admin, and the weekly and monthly ones to the team lead, who signs them off.
2Keep checks read-only and use a monitor user
Every check starts with ls or show. Run them as a user in the monitor group, and then a typo or a script bug can’t ever change the configuration.
Any change you find you need goes through your change process, never through the check script.
This is the runbook. Copy it into your team wiki and set the limits to suit your company.
| When | Check | DS CLI | Good looks like |
|---|---|---|---|
| Daily | Both CPCs up | lsserver | server0 and server1 Online |
| Daily | Arrays and hardware | lsarray, lsioenclosure | Data Normal, enclosures Online |
| Daily | Pool capacity | lsextpool | status below, under 80% allocated |
| Daily | Host paths | lshostport -login | 2+ logins per host, in 2 I/O enclosures |
| Daily | Copy Services | lsflash -l, lspprc | State Valid, mirrors Full Duplex |
| Weekly | Users and expiry | lsuser -l, showuser | No leavers, nobody locked |
| Weekly | Password rules | showpass | Matches the company policy |
| Weekly | Alerts and access | showsp, lsaccess -l | SNMP Enabled, two targets, AOS as agreed |
| Monthly | Config and audit | offloadfile -config, offloadauditlog | Files stored with the date |
| Monthly | Code level | ver -l | Known bundle, upgrade planned if behind |
By hand the daily part takes five minutes, and as a script it takes seconds, which is why it’s the first thing to automate.
3Automate the daily check from a jump server
The script runs on your workstation or a jump server and never on the DS8000 itself. It calls DS CLI with a profile (banner off, header on, delimited format), reads the CSV rows and checks each value against a rule.
The DS CLI password lives in an encrypted password file made with managepwfile, never in the script. Profiles and password files are explained in Lesson 9.
4Send the result where people look
If nobody reads the report, you may as well not have one. Mail it to the team, post it in the team chat, or have it open a ticket automatically whenever there’s a WARN line.
Hang on to the daily files for at least a few months, because they turn into your capacity trend and your audit evidence.
5Look at the trend once a month
Today’s 62% doesn’t tell you much by itself. But 62% after 48% last month means you’ve got about two months before the 85% threshold, so it’s time to order capacity.
Put the monthly numbers for each pool into one table. Lesson 22 adds the performance side.
6Review and re-sign the runbook every quarter
Systems change over time, with new hosts, new pools and new mirrors. Every quarter, check the runbook still covers everything and the people named on it still work here.
Do one real test too: a Call Home test with IBM and a restore from a copy. Until you’ve restored a backup, it’s only a hope.
Hands-on lab: run the checks and a Python daily report
Before you run any command, double-check it
Read every command twice before you press Enter. Check the target: the system or account, the IDs, the names and the sizes. These commands are for learning and were tested in our lab, not on your system. At work, run the read-only list commands first, follow your change process, make sure a backup exists, and ask a second person to check anything that changes or deletes data. You run them at your own risk.
You’re the storage admin for a small ERP system, with a Linux database server erp-db1, a Windows app server win-app1, a pool pair and one FlashCopy that refreshes a copy of the database. You’ll run the checks by hand first so you understand what the script is doing for you.
Practice shell note: the practice shell is our teaching tool, not IBM software, and real DS CLI output is close but not identical. The simctl lines in the setup script are practice-only and log the second host port in through I0052, the way a SAN admin would zone it. The monthly items (offloadfile, offloadauditlog) only run on a real system.
1Load the running system
Reset the shell, do the first login, then save this as setup-26.txt:
# setup-26.txt: a small running system to administer (Lesson 26). Run after simctl reset.
mkarray -raidtype 6 -arsite S1
mkarray -raidtype 6 -arsite S2
mkrank -array A0 -keygrp 1 -stgtype fb
mkrank -array A1 -keygrp 1 -stgtype fb
mkextpool -rankgrp 0 -keygrp 1 -stgtype fb FB_0
mkextpool -rankgrp 1 -keygrp 1 -stgtype fb FB_1
chrank -extpool P0 R0
chrank -extpool P1 R1
mkfbvol -extpool P0 -cap 200 -sam ese -name erp_#h 2000-2001
mkfbvol -extpool P1 -cap 200 -sam ese -name erp_#h 2100
mkfbvol -extpool P0 -cap 200 -sam ese -name erpcopy_#h 2010
mkhost -type "Linux Server" -hostport 10000090FA13B914,10000090FA13B915 erp-db1
mkhost -type "Windows Server" -hostport 21000024FF2D0F86,21000024FF2D0F87 win-app1
chhost -action map -volume 2000,2100 erp-db1
chhost -action map -volume 2001 win-app1
mkflash -record -persist 2000:2010
mkuser -pw Temp1234 -group monitor noc_view
simctl logout 10000090FA13B915
simctl login 10000090FA13B915 I0052
simctl logout 21000024FF2D0F87
simctl login 21000024FF2D0F87 I0052Run this:
python ds8sim.py (then: simctl reset -all, quit)
python ds8sim.py -hmc1 10.0.0.1 -user admin -passwd admin -newpasswd Practice1 ver
python ds8sim.py -hmc1 10.0.0.1 -user admin -passwd Practice1 -script setup-26.txtAt the end of the script you should see CMUC00137I for the FlashCopy, CMUC00133I for the user, and four SIM lines for the logins.
✅ Checkpoint: no E messages in the setup output.
2Create the password file and the profile
Run this:
python ds8sim.py -hmc1 10.0.0.1 -user admin -passwd Practice1 managepwfile -action add -pwfile security.dat -name admin -pw Practice1You should see this:
CMUC00206I managepwfile: Record 10.0.0.1/admin successfully added to password file security.dat.Now save this as auto.profile in the same folder:
hmc1: 10.0.0.1
username: admin
pwfile: security.dat
devid: IBM.2107-78SV001
banner: off
header: on
format: delim
delim: ,The lab profile uses admin to keep things short, but at work you’d point it at a monitor user such as noc_view.
✅ Checkpoint: security.dat and auto.profile sit next to ds8sim.py.
3Run the daily check by hand
Save the eight daily commands as daily-26.txt: lssi, lsserver, lsioenclosure, lsarray, lsextpool, lshost, lshostport -login, lsflash, one per line.
Run this:
python ds8sim.py -hmc1 10.0.0.1 -user admin -pwfile security.dat -script daily-26.txtYou should see this (shortened to the lines you judge):
Date/Time: 24 October 2026 20:00:33 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
ID Image ID Image Name Power Control SFI State
=============================================================
server0 IBM.2107-78SV001 ds8k-g10-lab Online Online
server1 IBM.2107-78SV001 ds8k-g10-lab Online Online
Date/Time: 24 October 2026 20:00:33 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
Array State Data RAIDtype arsite Rank DA Pair DDMcap (10^9B)
====================================================================
A0 Assigned Normal 6 (5+P+Q+S) S1 R0 0 4800.0
A1 Assigned Normal 6 (5+P+Q+S) S2 R1 0 4800.0
Date/Time: 24 October 2026 20:00:33 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
Name ID stgtype rankgrp status availstor (2^30B) %allocated available reserved numvols
======================================================================================
FB_0 P0 fb 0 below 99576 0 6372864 64 3
FB_1 P1 fb 1 below 99576 0 6372864 64 1
Date/Time: 24 October 2026 20:00:33 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
WWNN WWPN Host I/O ports ESSIOport
==============================================================
20000024FF2D0F86 21000024FF2D0F86 win-app1 16 (all) I0032
20000090FA13B915 10000090FA13B915 erp-db1 16 (all) I0052
20000120FA13B914 10000090FA13B914 erp-db1 16 (all) I0032
21000024FF2D0F87 21000024FF2D0F87 win-app1 16 (all) I0052
(lsflash output shortened: 2000:2010 Recording Enabled, Persistent Enabled)Read it the way the bus driver walks round his bus: both servers Online, both arrays Normal, both pools below threshold, and each host logged in on I0032 and I0052. I0032 is in I/O enclosure 1B2 and I0052 in 1B3, so every host keeps running if one enclosure goes down.
✅ Checkpoint: you can say in one sentence why each block is healthy.
4Run the weekly check
Save ver -l, lsuser -l, showpass, showsp and lsaccess -l as weekly-26.txt and run it the same way.
You should see this (shortened):
Storage Image LMC Bundle Version
===========================================
IBM.2107-78SV001 7.10.10.348 10.10.106.0
Name Group State Scope
==================================
admin admin active *
noc_view monitor active PUBLIC
secadmin secadmin active *
service ibm_service active *
Password Expiration 365 days
Failed Logins Allowed 5
SNMP Disabled
SNMPadd -
hmc cmdline wui modem cim aos rsc vpn
===============================================================
hmc1 enabled enabled disabled disabled enabled enabled disabled
hmc2 enabled enabled disabled disabled enabled enabled disabledThe weekly check has turned something up straight away: SNMP is Disabled, so this system sends no traps at all. A real admin would raise a change to fix it with chsp -snmp on -snmpaddr (see Lesson 21). Passwords that go a whole year without expiring may break your company policy too.
✅ Checkpoint: you noted two weekly findings: SNMP off, and a 365-day password expiry to compare with policy.
5Monthly: export evidence (real system)
On a real DS8000 the monthly part looks roughly like this. The commands follow the Redbook examples, and you run them from DS CLI on your workstation rather than the GUI's embedded DS CLI.
dscli> offloadfile -config c:\ds8k-admin\2026-10
dscli> offloadauditlog -logaddr smc1 c:\ds8k-admin\2026-10\audit.txtThe first one writes productSettings and ICSInstall.history, and the second writes the audit log. Keep both in a folder named after the month.
✅ Checkpoint: your runbook has a monthly folder rule and a named owner.
6Save the daily report script
Save this on your laptop in the lab folder, next to ds8sim.py. It runs there and not on the DS8000.
# daily_report.py: the DS8000 daily check as a short OK/WARN report.
# Runs on your workstation or jump server, not on the DS8000.
# It talks to the DS8000 only through the DS CLI (auto.profile: banner off, header on, format delim).
import csv, subprocess
DSCLI = ["python", "ds8sim.py", "-cfg", "auto.profile"] # at work: ["dscli", "-cfg", "auto.profile"]
def dscli(*args):
"""Run one DS CLI command and return its rows as dictionaries."""
out = subprocess.run(DSCLI + list(args), capture_output=True, text=True).stdout
lines = [l for l in out.splitlines() if l and not l.startswith("SaatVedha") and not l.startswith("CMUC")]
return list(csv.DictReader(lines))
POOL_WARN = 80 # warn before the pool threshold (default 85) is reached
warnings = 0
def report(ok, area, text):
global warnings
if not ok:
warnings += 1
print(("OK " if ok else "WARN") + " " + area.ljust(9) + text)
servers = dscli("lsserver")
up = [s for s in servers if s["SFI State"] == "Online"]
report(len(up) == 2, "servers", "%d of 2 CPCs online" % len(up))
for a in dscli("lsarray"):
report(a["Data"] == "Normal", "array", "%s on %s: %s" % (a["Array"], a["arsite"], a["Data"]))
for p in dscli("lsextpool"):
used = int(p["%allocated"])
report(used < POOL_WARN and p["status"] == "below", "pool",
"%s %s: %d%% allocated, status %s" % (p["ID"], p["Name"], used, p["status"]))
encl = {p["ID"]: p["I/O Enclosure"] for p in dscli("lsioport", "-l")}
paths = {}
for h in dscli("lshostport", "-login"):
if h["Host"] != "-":
paths.setdefault(h["Host"], set()).add(h["ESSIOport"])
for host, ports in sorted(paths.items()):
bays = {encl[p] for p in ports}
report(len(ports) >= 2 and len(bays) >= 2, "paths",
"%s: %d logins on %s (%d I/O enclosures)" % (host, len(ports), ",".join(sorted(ports)), len(bays)))
for f in dscli("lsflash", "-l"):
report(f["State"] == "Valid", "flash", "%s: %s" % (f["ID"], f["State"]))
for u in dscli("lsuser"):
if u["State"] != "active":
report(False, "user", "%s is %s" % (u["Name"], u["State"]))
print("Result: %s, %d warning(s)" % ("CHECK NEEDED" if warnings else "ALL OK", warnings))The rules are where the learning is: two CPCs online, arrays Normal, pools under 80% and "below", at least two logins per host across two I/O enclosures, FlashCopy State Valid, and nobody locked out. On macOS or Linux, change "python" to "python3" in the DSCLI line.
✅ Checkpoint: daily_report.py is saved and the DSCLI line matches your system.
7Run the report
Run this:
python daily_report.pyYou should see this:
OK servers 2 of 2 CPCs online
OK array A0 on S1: Normal
OK array A1 on S2: Normal
OK pool P0 FB_0: 0% allocated, status below
OK pool P1 FB_1: 0% allocated, status below
OK paths erp-db1: 2 logins on I0032,I0052 (2 I/O enclosures)
OK paths win-app1: 2 logins on I0032,I0052 (2 I/O enclosures)
OK flash 2000:2010: Valid
Result: ALL OK, 0 warning(s)✅ Checkpoint: nine lines, all OK, result ALL OK.

8Schedule it (at work)
At work a scheduler on the jump server would run it every morning and mail out the result, something like this (you don't need to run it in the lab):
schtasks /create /tn "DS8000 daily report" /sc daily /st 07:00 /tr "cmd /c cd /d C:\ds8k-admin && python daily_report.py > daily.txt"
0 7 * * * cd ~/ds8k-admin && python3 daily_report.py | mail -s "DS8000 daily" storage-team@example.comThe first line is for Windows Task Scheduler and the second is a Linux cron entry. Run the job as a service account that can read the password file, and make sure a WARN line reaches a person and doesn't just land in a folder.
✅ Checkpoint: you know where the job would run, as which user, and who reads the result.
Break It, Then Fix It
A report is only any good if it turns red when it should, so you’ll cause two real problems and check the script catches each of them.
1Break: fill pool P0 to 90%
The practice-only simctl poolfill pretends other data has filled up the pool, much like a month-end batch that wrote far more than normal.
Run this:
python ds8sim.py -cfg auto.profile simctl poolfill P0 90
python daily_report.pyYou should see this:
SIM0109I simctl: extent pool P0 is now 90% allocated (637287 extents available).
OK servers 2 of 2 CPCs online
OK array A0 on S1: Normal
OK array A1 on S2: Normal
WARN pool P0 FB_0: 90% allocated, status exceeded
OK pool P1 FB_1: 0% allocated, status below
OK paths erp-db1: 2 logins on I0032,I0052 (2 I/O enclosures)
OK paths win-app1: 2 logins on I0032,I0052 (2 I/O enclosures)
OK flash 2000:2010: Valid
Result: CHECK NEEDED, 1 warning(s)Why: 90% is past your 80% rule and also past the system’s own 85% threshold, so lsextpool reports exceeded. Every volume here is thin (ESE), which means once the pool is full, the next host write that needs a new extent will fail. Catch it at 80% and you’ve got days to act, but catch it at 100% and you’ve got an outage.
2Fix: add a rank to the pool
The proper fix is more capacity (or moving volumes, see Lesson 27). Save this as addcap-26.txt:
# addcap-26.txt: add one rank to pool P0
mkarray -raidtype 6 -arsite S3
mkrank -array A2 -keygrp 1 -stgtype fb
chrank -extpool P0 R2
lsextpoolRun this:
python ds8sim.py -cfg auto.profile -script addcap-26.txt
python daily_report.pyYou should see this:
CMUC00004I mkarray: Array A2 successfully created.
CMUC00007I mkrank: Rank R2 successfully created.
CMUC00008I chrank: Rank R2 successfully modified.
Name,ID,stgtype,rankgrp,status,availstor (2^30B),%allocated,available,reserved,numvols
FB_0,P0,fb,0,below,129449,41,8284737,128,3
FB_1,P1,fb,1,below,99576,0,6372864,64,1
OK servers 2 of 2 CPCs online
OK array A0 on S1: Normal
OK array A1 on S2: Normal
OK array A2 on S3: Normal
OK pool P0 FB_0: 41% allocated, status below
(output shortened: the other lines are OK)
Result: ALL OK, 0 warning(s)The lsextpool output comes out comma-separated because the profile says format: delim, and that’s what the script reads. At work you’d add a matching rank to P1 too, to keep the two rank groups balanced.
✅ Checkpoint: P0 is back to 41%, status below, and the report says ALL OK.
3Break: port I0052 loses light
Run this:
python ds8sim.py -cfg auto.profile simctl portfail I0052
python daily_report.pyYou should see this:
SIM0105I simctl: I/O port I0052 has no light (cable or SFP problem).
OK servers 2 of 2 CPCs online
OK array A0 on S1: Normal
OK array A1 on S2: Normal
OK array A2 on S3: Normal
OK pool P0 FB_0: 41% allocated, status below
OK pool P1 FB_1: 0% allocated, status below
WARN paths erp-db1: 1 logins on I0032 (1 I/O enclosures)
WARN paths win-app1: 1 logins on I0032 (1 I/O enclosures)
OK flash 2000:2010: Valid
Result: CHECK NEEDED, 2 warning(s)
Why: both hosts still work through I0032 alone and no user notices a thing, and that’s the danger. The next failure on I0032, or any service work on enclosure 1B2, takes both servers down.
Confirm it on the port itself with showioport I0052, which shows State “No light detected” and Logins 0.
4Fix: restore the light, then rerun
At work this means swapping a cable or SFP. You or the SAN team handle the cable, and the IBM SSR comes in if the host adapter part is faulty. In the shell:
python ds8sim.py -cfg auto.profile simctl portfix I0052
python daily_report.pyYou should see this:
SIM0106I simctl: I/O port I0052 has light again.
(output shortened: servers, arrays and pools OK)
OK paths erp-db1: 2 logins on I0032,I0052 (2 I/O enclosures)
OK paths win-app1: 2 logins on I0032,I0052 (2 I/O enclosures)
OK flash 2000:2010: Valid
Result: ALL OK, 0 warning(s)✅ Checkpoint: both hosts are back to two logins in two I/O enclosures.
This happened at work
The pool that users found first
This happened at an insurer that kept its scanned claim documents on thin volumes in one DS8000 pool. Their weekly check was a junior admin copying the pool figure from the GUI dashboard into a spreadsheet every Monday, and that Monday the pool showed 78%, so the line in the sheet was green.
On Tuesday a new month-end job kicked off. It scanned and OCR-processed a backlog of paper claims and wrote three times the usual amount, and by Wednesday the pool status had turned “exceeded”, but nobody opened the GUI between Mondays.
At 8:15 a.m. on Thursday the claims team rang the help desk because document uploads were timing out. When the storage team logged in they found the pool at 97% and climbing by about a point an hour, which gave them roughly three hours before the thin volumes would start failing writes.
They stopped the OCR job, then checked and deleted an old 6 TB test clone with two people watching, which brought the pool down to 89%. IBM installed more capacity the following week, but about 1,900 claim documents had to be scanned again.
Root cause: capacity, which can change within a day, was checked by hand once a week, and no automatic warning ever reached a person.
Fix: a daily report from the jump server that warns at 80% and goes to the on-call channel, along with a monthly growth table. New batch jobs now need a capacity estimate before they go live.
Lesson: check things as often as they can change. Capacity and paths need a daily look, while users and rules can be weekly.
Common mistakes and troubleshooting
| Symptom | Likely cause | What to check / fix |
|---|---|---|
| Report says ALL OK but a host lost disks | Path rule counts logins only, not I/O enclosures | Map each login port to its enclosure with lsioport -l |
| Script fails with KeyError | Profile not in delim format, or a column name changed | Check format: delim and header: on; print the header row |
| Script prints nothing at all | Password expired or wrong in the password file | Log in by hand, then update the record with managepwfile |
| Nobody saw the WARN | Output written to a file nobody opens | Send WARN lines to mail, chat or a ticket |
| Pool full overnight | Threshold met but checked only weekly | Daily check at 80%; monthly trend per pool |
Looking for lsproblem | That command does not exist | Use the GUI Events page or the HMC for events |
Tip: whenever you add a rule to the script, break it on purpose once in the practice shell. If you’ve never seen a rule turn yellow, you can’t be sure it ever will.
Interview questions
Click a question to open it. They’re worded the way an interviewer would ask them, and under each one you’ll find why they ask it and one way you could answer in your own words.
Fresher level
1. What do you check on a DS8000 every morning, and why those things?
Why they ask this: They want to know whether you have a routine or just wait for tickets.
How you might answer: I check both CPCs with lsserver, the arrays with lsarray, pool capacity with lsextpool, host logins with lshostport -login, and copy states with lsflash -l and lspprc.
Those are the things that can go wrong overnight without anyone noticing, like a failed part, a pool filling up, a lost path or a suspended mirror.
2. Why should a monitoring script log in as a monitor user and not as admin?
Why they ask this: They’re testing whether you think about safety as well as convenience.
How you might answer: A monitor user can only run ls and show commands, so even if my script has a bug or someone edits it badly, it can’t delete a volume or change a port. It keeps the audit log honest too, since the report user is obviously not a person making changes.
2–5 years experience
3. Your daily report shows WARN for one host: one login on one port. The application team says everything works. What do you do?
Why they ask this: They’re checking you understand redundancy and won’t brush off a warning just because users are happy.
How you might answer: I’d agree it works today, but there’s no redundancy left. I’d check the port with showioport for light and logins, then look at the switch side with the SAN team. Until it’s fixed, I’d tell the app team they’re one failure away from an outage and put off any service on the I/O enclosure holding the remaining path.
4. How would you decide the warning level for pool capacity?
Why they ask this: They want to see you reason from lead time instead of just picking a number.
How you might answer: I’d start with how long it takes to get capacity, since an order and install can take weeks and moving volumes takes days. Then I’d look at monthly growth and set the warning so I’ve still got at least that lead time before the 85% threshold. In the lab I used 80%, but a pool that grows fast might need 70%.
Senior level
5. Design the administration routine for a team of three that runs four DS8000s across two sites.
Why they ask this: Seniors get judged on whether a routine survives holidays, people leaving and growth.
How you might answer: I’d have one read-only report script a day covering all four systems, run from a jump server at each site, with WARN lines going to the on-call channel. On top of that, a weekly user and alert review by a named owner with a deputy, a monthly config and audit export filed by date, and a Call Home and restore test every quarter.
The runbook lives in the wiki with its owners, and I get it re-signed every quarter.
6. An auditor asks you to prove that your DS8000 checks really happen. What do you show?
Why they ask this: They’re testing whether your routine leaves evidence behind or only memories.
How you might answer: I’d show the dated daily report files from the jump server, the monthly folders with the offloadfile -config output and the audit log export, and the weekly review notes with names on them. For alerts I’d show a test trap that arrived on the monitoring system, plus IBM’s confirmation of the last Call Home test.
Quick quiz
Q1. Which command shows if a pool is below, exceeded or full?
lsranklsextpoolshowpasslsserver
Show answer
B — lsextpool has a status column with below, exceeded or full.
Q2. Why does the report check I/O enclosures, not just the number of logins?
- Enclosures are faster
- Two logins in one enclosure are lost together if that enclosure fails
- DS CLI needs it
- It is a licence rule
Show answer
B — Real redundancy means paths through different I/O enclosures.
Q3. Where should the daily report script run?
- On the DS8000 CPC
- On the HMC
- On a jump server or workstation
- Inside the GUI
Show answer
C — The DS8000 never runs your Python. The script calls DS CLI from outside.
Q4. Which DS CLI setting makes the output easy for a script to parse?
- format: delim with header on
- banner: on
- format: stanza with header off
- -s
Show answer
A — Delimited output with one header row turns straight into CSV rows.
Q5. What is the default pool threshold that marks a pool as exceeded?
- 50%
- 70%
- 85% allocated (15% free)
- 99%
Show answer
C — chextpool -threshold defaults to 15, so the status changes at about 85% allocated.
Quick recap
- Administration runs on a rhythm: health, capacity and paths daily, users and alerts weekly, evidence monthly and tests quarterly.
- Every check is read-only and runs as a monitor user.
- Warn on pools before the 85% threshold, based on your lead time for new capacity.
- Count paths per I/O enclosure, and not only per host.
- Automate the daily check from a jump server with DS CLI, a profile and a password file.
- A WARN line has to reach a person, and every rule should be tested once by breaking it.
Next lesson
Lesson 27: DS8000 operations: capacity, migration, power and service tasks → Next you move from checking to doing: the routine changes you make on a running system.
Further reading: DS8000 administration
Want to go deeper into DS8000 administration? IBM Redbook SG24-8559-01 covers users and password rules in Chapter 10 (pp. 340-342) and monitoring, Call Home and data offload in Chapter 12. IBM Documentation: chextpool explains the pool threshold.
On SaatVedha, Lesson 22: DS8000 performance monitoring adds the performance checks. You can also see the full plan for this course on the IBM DS8000 Implementation course page.
