Protokoll der 90. z/OS GUIDE-Tagung in Lahnstein

Protokoll der 90. z/OS GUIDE-Tagung in Lahnstein
vom 04. bis 06. Oktober 2006
Allgemeines/Administratives
Zu unserer diesjährigen Herbsttagung konnte Chairman Dietmar Frerix insgesamt 70
Teilnehmer und 9 Gäste in Lahnstein begrüßen. Wegen der geringen Teilnehmerzahl (und
einer anderen Veranstaltung im Hause) tagten wir nicht im großen Sitzungssaal.
Mitgliederbestand (alt)
anwesende Teilnehmer
entschuldigte Teilnehmer
gelöschte Mitglieder
(4x unentschuldigtes Fehlen)
Abmeldungen/Ruhestand
Neuanmeldungen
Mitgliederbestand aktuell
153
70
39
4
4
3
148
Die Termine der nächsten zwei Tagungen:
Frühjahrstagung
Herbsttagung
07. – 09.03.2007
19. – 21.09.2007
Vorträge
Die Vorträge der Tagung liegen auf dem neuen GSE Server http://gseimis2.gse.org
unter Communities, SOSXD zOS (MVS) German Region, G#90 Oct2006
Die Vorträge von Herrn Schiefelbein und Herrn Benke
Linux auf IBM System z – Update
What’s new in RMF
konnten wegen technischer Probleme (Firewall) nicht auf den GSE Server hochgeladen
werden.
Zusätzlich liegen alle Vorträge auf einem FTP Server beim KRZN http://guide.krzn.de
Wir bedanken uns bei den Rednern – insbesondere den GSE Mitgliedern für die
Erfahrungberichte - sowie bei Herrn Penzlin für die Verpflichtung der Referenten.
Zum Vortrag CIM: mehr als nur Catalog-Recovery von Hostsystems als Nachtrag noch die
email: info@hostsystems.de
Requirements
zwei Requirements wurden vorgestellt und verabschiedet mit Priority High
File Latch Contention
Up to now we have to provide a dump from USS address space
including SYSZBPX2 data space to get information about the
file latch contention.
If a latch contention occurs we have to enter:
**************************************************************
D GRS,LATCH,C
ISG343I 15.28.43 GRS STATUS 066
LATCH SET NAME: SYS.BPX.A000.FSLIT.FILESYS.LSN.01
CREATOR JOBNAME: OMVS CREATOR ASID: 000E
LATCH NUMBER: 10113
REQUESTOR ASID EXC/SHR OWN/WAI
**************************************************************
In case of file system latch contention we have the
possibility to use D OMVS commands to get useful information
about file system name,owner, waiter and so on.
For file latch contention, like shown in previous GRS command
ouput, no commands are available to get additional hints.
We do not know the file system nor the file name.
This request is related to PMR 77041,070,724
von Frau Pfeiffer von der Filiadata GmbH in Karlsruhe
WLM managed Batch im Sysplex
beim Öffnen zusätzlicher Initators durch WLM soll – neben den goals die Auslastung der einzelnen Systeme berücksichtigt werden
von Herrn Weilandt von der AOK Baden-Würtemberg in Stuttgart
Berichte der Arbeitsgruppen
zOS/390 (MVS) – Nord
die Arbeitsgruppe trifft sich zweimal jährlich in Lüneburg (im Jahre 2006 im Juni und im
Dezember), beim letzten Treffen standen folgende Punkte auf der Tagesordnung
Erfahrungsbericht zum Health Checker
neuer GSE Server gseimis2
IBM News
Erfahrungsaustausch
zOS/390 (MVS) – West
die Arbeitsgruppe trifft sich jedes Jahr im Mai und im November bei unterschiedlichen
Mitgliedern der Arbeitsgruppe, Tagesordnungspunkte beim letzten Treffen waren
Java Batch
neuer GSE Server gseimis2
IBM News
Erfahrungsaustausch
How to handle CBU and DR in a subcapacity environment
Zu diesem Thema hat Herr Penzlin, IBM noch folgende Information
Here are the guidelines we send out for CBU, Disaster Recovery and other
"unusual" situations.
Summary:
Intervals with increased rolling 4-hour average utilization due to CBU Test
or Disaster Recovery Test should not be considered when calculating
SubCapacity software charging.
IBM's Contractual Terms:
CBU Upgrade & Disaster Recovery will not result in any increase or decrease
in IBM Program charges to your Enterprise during a Test or Emergency.
Customers
their CBU
Customers
per year,
using Capacity Back Up (CBU) must remain within the bounds of
contract regarding the number of and duration of CBU tests.
not using CBU should limit disaster recovery testing to 3 tests
each test lasting no longer than 3 days.
Capacity Back Up (CBU) and Disaster Recovery testing are considered
“Unusual Situations” under IBMs SubCapacity policies and procedures. Any
increases in MSU reporting attributable to CBU/DR test are not billable and
can be overridden in SCRT reporting as long as the testing is within
standard guidelines and conducted outside of peak periods.
Unusual Situations
Customers have the primary responsibility for preventing uncontrolled
loops, operator errors, or unwanted utilization spikes. However, IBM
understands that occasionally situations that could not be prevented
(especially situations related to disaster recovery) may cause exceptional
utilization values. In these situations, IBM does not expect our customers
to pay for the increased utilization associated with the unusual situation.
Please use your best judgement to determine if an unusual situation has
occurred. IBM does not publish a list of unusual situations because they
will by their nature be unpredictable. IBM trusts your judgement when you
indicate an unusual situation has occurred. However, if you repeatedly
override the Tool MSUs (for example, you always have unusual situations
occur at quarter close) or if large discrepancies are found during IBM
audits (IBM Call Home TSAD data is compared with data from subcapacity
reports), IBM will contact you at the time the pattern is noticed.
Modifying the SCRT Report to correct for "Unusual Situations" :
If an unusual situation occurs, customers should NOT use IFASMFDP to delete
SMF records from the SCRT report to be submitted to IBM for billing.
Instead, the “Customer MSUs” fields, along with an explanation in “Customer
Comments” should be used to submit the “correct” number of MSUs the
customer has determined are associated with “normal” workload. Care should
be taken to NOT change any values in the "Tool MSUs" column of the report.
SCRT Override Measurement Process:
Here are some step-by-step instructions on how to use SCRT to determine the
override values:
STEP 1) Run the SubCapacity Report against the entire month of data,
including the days when the 'unusual event' occurred. THIS IS THE
'OFFICIAL' REPORT YOU WILL SUBMIT TO IBM.
STEP 2) Check the Product Max Contributors Section of this SubCapacity
Report to see if any of the product peaks occurred during the 'unusual
event'.
- If not, then your 'unusual circumstance' did not contribute to
the billing-related peak utilization and no further action is needed.
Submit the original report without overrides.
- If so, proceed to step #3.
STEP 3) Use the SMF Dump Program (IFASMFDP) to remove the SMF records
for the time period during which the 'unusual event' occurred and create
a new SMF data file.
STEP 4)
Run SCRT again, using the SMF subset dataset created in STEP 3.
STEP 5) Compare the MSU values from the report generated in this step
(Step #4) to those in the original report (STEP 1).
Enter any changed values into the "Customer MSUs" column of
the report you generated in STEP #1.
Beside each MSU value, enter the comment "[Unusual Event
Description] occurred from <date> to <date>".
Submit both reports by the 9th day of the calendar month following data
collection.
Submit SCRT report generated in STEP 1 (and updated with
overrides in STEP 5) using your normal submission process.
Submit SCRT report generated in STEP 4 to " scrt@us.ibm.com "
with a note saying "Backup report for [Unusual Event Description]"
Keep ALL SMF70 and SMF89 records for 6months as prescribed by the
SubCapacity Ts & C
IBM Billing for each product:
If the Data Collection % on the subset Report generated in STEP 4 is 90% or
more: IBM will use the Override value from STEP 4.
If the Data Collection % on the subset Report generated in STEP 4 is less
than 90%: IBM will use the greater of: (1) the Override value from STEP 4
OR (2) the MSU values from the prior month.
Please note:
This procedure is subject to change at any time.
Wolfgang Kleinen
23.10.2006