Using BRMS Exits in Control Groups You should not be using BRMS

Using BRMS Exits in Control Groups
You should not be using BRMS control group exits to replace Control Language
Programs (CLP).
BRMS exits should never contain any SAVxxx commands (SAVLIB, SAVOBJ,
SAVCHGOBJ, SAVSYS, SAV, SAVDLO, SAVCFG, SAVSECDTA) or
SAVxxxBRM commands (SAVSYSBRM, SAVLIBBRM, SAVOBJBRM,
SAVDLOBRM, SAVBRM, SAVLBRM, SAVFLRBRM, SAVMEDIBRM) unless
they are submitted to batch via the SBMJOB command.
Having these commands in a CLP is the same as having them directly in the
exit. BRMS control group exits should not have other BRMS commands like
STRMNTBRM or MOVMEDBRM.
BRMS also checks for an active backup item in the control group before ending
any subsystems. If there are no active items to be saved, any subsystems or
job queues specified under Option 9 or 10 from the WRKCTLGBRM screen will
not be processed.
1
Om man har Retain Object Detail *NO, hur kan man då se vilka objekt som inte blev sparade?
Som standard står det *ERR i fältet för Retain object detail, men vad innebär det?
Eftersom man inte sagt varken *OBJ (object detail) eller *MBR (member detail) har man
ingen information vad som sparades. Men när det står *ERR vill BRMS åtminstone göra
en uppmärksam på att vissa objekt inte sparades. Det gör den genom att under
WRKMEDIBRM finns det finns en kolumn för vad som eventuellt inte sparades. Väljer
man sedan detaljinformation (val 9) så visas ett meddelande-id som indikerar varför.
Har man sagt "object detail" är meddelandefältet blankt för allting som gick bra.
Notera att denna information sparas så att man känner till detta även om inga loggar
från körningen finns kvar.
Hur ser man vilka som inte blev sparade när man har satt Object Detail *YES?
Då väljer man på samma sätt 9 och rullar igenom listan med alla sparade
objekt. De som inte blev sparade är markerade i kolumnen Message ID exakt
som är fallet när man har Object Detail = *ERR
För övrigt ser man vilka objekt det gäller klart och tydligt i BRMS-loggen
(DSPLOGBRM) genom att leta efter meddelande-ID eller med hjälp av
Severity.
I BRMS systempolicy finns ”Start of Day”
Om man vill hålla ihop backuper över dygnsgränser kan man använda ”Start
of Day” som är ett värde i BRMS systempolicy.
Sätter man den till 06:00 kommer backuper som t.ex. startar klockan 01 att
få föregående dags skapandedatum.
Det blir alltså inte nästa dag förrän klockan har passerat 6 på morron.
Gör det eventuellt enklare att leta efter backuper tagna för onsdagens data
genom att leta med onsdagens datum, så slipper man fundera på när
backupen egentligen togs? Om den startar kl. 23 i normalfallet men blev
senarelagd till efter midnatt av någon anledning. Vem kommer ihåg att det
var just så den dan?
Eller också blir det bara förvirrande att se datumstämplingen för ett band eller
en backup i BRMS inte är densamma som om man skulle göra DSPTAP eller
titta i jobbloggen.
....mer om systempolicyn
I BRMS systempolicy finns ett värde som handlar om vilka som får vara aktiva
i systemet även fast man sagt att man kastar ut användarna (förutsatt att det
subsystem som de är påloggade i inte tas ner).
Funktionen kallas ”Work with Sign off Exceptions”.
Kan vi skicka iväg en IPL när som helst?
Helst inte. Därför finns ett annat värde i systempolicyn som förhindrar det ifall
backupen av någon anledning flyttats eller dragit ut på tiden.
6
Varför är inte banden friställda?
Band där spartiden gått ut friställs inte automatiskt om inte dessa villkor är
uppfyllda:
●
●
●
●
●
Bandet måste finnas på en lagringsplats som tillåter friställning (ej
kassaskåp och liknande)
Datats spartid för samtliga backuper som finns på bandet måste ha löpt ut
BRMS måste känna till att bandet finns på plats och är tillgängligt. Inte
bara istoppat i bandroboten.
STREXPBRM eller vanligare STRMNTBRM måste vara körd
Man får inte använda append ihop med rensningsvärdet
RMVMEDI(*REUSE) i STRMNTBRM eftersom det ena förutsätter det andra
och tvärtom.
Intresseklubben noterar
Band som monteras i en bandrobot utan steckkodsläsare får följande namn:
●
NLTxxx Non-Labeled Tape - contains data in non-Standard Tape Label
format.
●
CLNxxx Cleaning - This cartridge has been identified as a cleaning tape.
●
BLKxxx Blank - This cartridge contains no data.
●
UNKxxx Unknown - This cartridge was not identifiable.
●
IMPxxx Import - Refers to the cartridge that is in the Priority slot
●
SLTxxx Slot - Refers to the cartridge by slot number
xxx är ett sekvensnummer
System policy
Finns bara en och innehåller grundinformation som används om det inte är
specificerat på lägre nivå. Här ett par parametrar som man bör känna till:
●
Home location for media kan vara *HOME, men använd helst ett bättre
namn som beskriver att band som hamnat här visar att något inte
fungerat som det ska. *HOME eller motsvarande lagringsplats ska alltså
vara tom.
●
Signoff exceptions talar om vilka användare som inte ska kastas ut
●
End subsystems: Hur gör vi det? Immed eller controlled?
●
●
●
Presentation controls: Ange att måndag är första dag i veckan och
kanske också på vilken kö BRMS-meddelanden ska hamna.
Allow backups in batch tillåter 21-backuper utan konsol. Under tiden
visas status A90037C0. Dock får inget inträffa som inte tas om hand.
Därför bestämmer man en tidsgräns som tar upp systemet om det inte
startar automatiskt.
IPL controls: Ska det göras en IPL efter backupen samt mellan vilka
tidpunkter är det tillåtet?
Backup policy
●
●
Default Weekly acivity: Om det ska vara full eller förändringsbackup?
Save journal files when saving changed objects. Se upp med det
här !
BRMS försöker förkorta backuptiden genom att inte ta med sig
förändrade filer som är journalförda. Den sparar förstås journalmottagarna, men inte själva de förändrade filerna. Observera att detta
ställer krav vid återläsningen, så det enklaste är nog ändå att spara ut
alla förändrade filer oavsett om de är journalförda eller ej.
●
Object precheck: Ska vi låta bli att spara ut ett bibliotek om det inte går
att få tag allt dess innehåll?
●
Append: Ta ett nytt band eller lägga till efter befintliga backuper?
●
End of tape option: *LEAVE, *REWIND eller *UNLOAD?
●
Entries to omit: QPFRDATA och QMPGDATA samt alla QSC*-bibliotek.
Ingen av dessa behöver återläsas, så varför slösa tid och utrymme att
spara dem?
Att utesluta objekt som finns på iASP
OMIT objects from iASP går inte att göra från 5250.
WRKCTLGBRM
WRKASPBRM visar ASP'arna
Ingen indikering i kontrollgruppen över att det skulle finnas uteslutna objekt, men tryck
F14 så ser man att omits existerar vid backup av *ALLUSR för CFIASP men man ser inte
vad som ska uteslutas.
för att se vad som döljer sig där måste man gå till iNav
Logga på iNAV och plussa ut Backup Recovery Management System så man kan gå in
på kontrollgruppen i fråga.
Klicka den och under tab'en som beskriver vad som ska tas backup av står det Yes för
kolumnen ”Omits”. Klicka knappen Edit ute till höger och panelen ”Edit Item to Save”
dyker upp. Där finns en knapp ”Change Omits”. Klicka den. Nu ser man.
Media policy
Här specificeras hur länge datat ska sparas samt
●
Spara till savfiler?
●
ASP storage limit: Hur mycket tillåts vi fylla upp i en ASP?
●
●
●
●
Secure media: Om man vill att enbart de med behörigheterna *SECADM
eller *ALLOBJ ska kunna hantera säkrade backupvolymer.
Hur många lediga band måste det finnas?
Ska banden kopieras? Det går att välja om man vill använda originalet
eller kopian vid en återläsning.
Plockas parametrarna upp av överliggande struktur?
Move policy
Här anger man hur banden flyttas runt
●
●
●
Viktigt är att band inte friställs på lagringsplatser där de inte är åtkomliga.
Kanske ska man överväga att inte göra flyttarna med automatik utan ta
dem för hand med kommandot WRKMEDBRM och med val 8 flytta alla
som ska till samma ställe.
Om man bara trycker ut ett band från bandroboten utan att använda
någon move policy hamnar bandet i location *HOME vilket kanske inte är
så lyckat, men någonstans måste ju bandet finnas. Eftersom BRMS inte
vet var det tog vägen sen får det bli *HOME tills vidare. Alternativt blir det
kvar på senast kända lokation. Alltså BRMS tror att det sitter kvar i
bandroboten.
Recovery policy
Allow object differences och vart man vill återställa m.m.
●
Om det inte anges här måste man komma ihåg F16 vid återläsning vilket
inte alltid är fallet i en stressad situation.
Att försäkra sig om lediga band
STRMNTBRM
Expire media . . . . . . . . . .
Expire media set volumes . . . .
*YES
*YES
(friställa band i kedjor)
STREXPBRM
Active file count . . . . . . .
Active file action . . . . . . .
Expire media set volumes . . .
File retention type . . . . . .
Select creation dates:
Beginning creation date . . .
Ending creation date . . . . .
0
(det ska inte finns några aktiva backuper kvar)
*EXPMED
*YES
*ANY
*BEGIN
*END
STRBALBRM
Action . . . . . . . . . . . . .
Media class . . . . . . . . . .
Volume locations to include . .
Systems . . . . . . . . . . . . .
Number of media required . . . .
*BALANCE
ULTRIUM3
TAPMLB01
+______ (vilka system ska balanseras?)
5
(alla ska ha minst 5 lediga band)
Gick backupen bra?
DSPLOGBRM
DSPLOGBRM
DSPLOGBRM
DSPLOGBRM
DSPLOGBRM
DSPLOGBRM
TYPE(*BKU)
TYPE(*BKU)
TYPE(*BKU)
TYPE(*BKU)
TYPE(*BKU)
TYPE(*BKU)
MSGID(CPF3771)
MSGID(CPF3761)
MSGID(BRM15A7)
MSGID(CPF3774)
MSGID(CPF3778)
MSGID(CPF3741)
vissa objekt sparades inte
låst objekt
backupen avslutades med fel
alla objekt sparades inte bibl...
alla objekt sparades inte
objekt xxxx,yyyy i
biblioteket ..... sparades inte
Någon gång då och då gör även detta:
DSPLOGBRM PERIOD((*AVAIL *BEGIN)) MSGID(BRM1993) för att hitta om ett
band är skrivskyddat
Varför hittar man backupinfo som ser ut så här?
Helt enkelt för att dessa bibliotek inte är sparade över huvud taget.
Om man vill hitta sådana gör man WRKMEDIBRM SAVSTS(*ERROR)
Hur ser om nånting inte täcks av en kontrollgrupp?
WRKMEDIBRM CTLGRP(*NONE) visar vilka objekt som finns sparade, men
som inte ingår i någon kontrollgrupp och därmed riskerar att bli uteslutna från
normal backuptagning.
Nånting gick snett i spärrat läge
Det finns 2 varianter för att ta backup i spärrat läge: Batch restricted eller BRMS konsol.
Händer det något i Batch restricted är det kört, men BRMS konsol går att avbryta
genom att:
tryck F9 för att komma till en kommandorad
ange lösenordet för den profil som loggade på BRMS konsol
WRKMEDBRM *EXP för att hitta ett ledigt band
montera bandet i bandroboten
WRKMLMBRM välj 1 (addera) för bandet du monterade som troligen har status *INSERTED
tryck enter på menyn som kommer upp. Ingen ändring behövs om det är samma mediaklass osv.
tryck F5 för att se att bandet blir *AVAILABLE
DSPMSG QSYSOPR och svara G på "No media available...."
tryck F12 för att lämna kommandoläget
backupen fortsätter med konsolen låst
Om man t.ex. blivit utan lediga band på grund av att bandlåset är på hanteras även
denna situation genom ovanstående procedur. "G" innebär ominventering av bandinventariet i bandroboten, så den gör ett nytt försök med bandet den redan ratat.
Den enda situation som blir besvärlig är om man behöver initiera bandet och enbart har
en bandstation. Då är det kört eftersom backupjobbet håller låsning på bandstationen.
Varför skrivs det på olika band i samma backup?
Normalt sett för att ett band tagit slut och backupen fortsätter på nästa, men
det händer ibland att BRMS väljer att skriva på olika band i samma jobb vilket
beror på att den försöker undvika att belägga band i onödan.
Om man t.ex. har både full och inkrementell backup med olika spartider i
samma kontrollgrupp, kan det bli så att BRMS väljer att skilja på datat.
I exemplet nedan adderar man dessutom till befintliga volymer.
Här hade man 9 dagars spartid för förändrade objekt,
medan man har 16 dagar för fullbackuper.
Saved
*SAVSECDTA
*SAVCFG
#LIBRARY
ADTSLAB
D7SRV
EFAKTURA
FASTANP
FASTDATA
Date
12-04-05
12-04-05
12-04-05
12-04-05
12-04-05
12-04-05
12-04-05
12-04-05
Time
01:11:36
01:14:42
01:16:19
01:16:56
01:16:57
01:16:59
01:17:05
01:17:05
Type
*FULL
*FULL
*CUML
*CUML
*CUML
*CUML
*CUML
*CUML
Volume Sequence Expires
020C72
112 12-04-21
020C72
113 12-04-21
01B28E
419 12-04-14
01B28E
420 12-04-14
01B28E
421 12-04-14
01B28E
422 12-04-14
01B28E
423 12-04-14
01B28E
424+ 12-04-14
Volume XXXXXX not under ... media control
När man monterat ett för BRMS okänt band dyker meddelandet "Volume
XXXXXX not under ... media control" upp vilket man kan ignorera.
Det beror på att 57xxSS1 option 18 ”Media and Storage Extensions” i OS/400
håller reda på vad som händer i samtliga bandrobotar och passar
informationen till BRMS som enbart vill göra en uppmärksam på att nu finns
det ett band som saknas i BRMS bandförteckning.
En annan sak i sammanhanget är att band som ägs av BRMS tillåts numera
att det skrivs på utanför BRMS. Dock håller BRMS ett getöga på vad som
händer med dess band så att inget blir överskrivet.
Gör man t.ex. en backup med något SAV...-kommando mot ett av BRMS ägt
band, uppdaterar BRMS sin backupinformation att det nu finns ytterligare en
backup att välja mellan. Dock finns ingen information över vilka objekt som
sparades.
Backupanalys
go brms
2. Backup
1. Backup planning
6. Backup analysis
3. Display backup analysis
Hur många band kan det gå åt?
Kommandot är ANZLIBBRM
BRM1883 "Devices with density .... not available"
Band saknas eller är på fel ställe i BRMS inventarieregister.
Man gör WRKMLBSTS val 9 och hittar hur många band som helst, ändå BRM1883.
DSPDEVD TAPMLB01
DSPDEVBRM TAPMLB01
WRKLOCBRM
Man måste ta sina backuper mot MLDIBM, inte TAPMLB01 vilket är förvirrande.
Se upp när man byter bandrobot eller att den skapat om sig själv.
I exemplet ovan stoppade man in ett nytt band i TAPMLB01 i hopp om att det skulle
hjälpa vilket det inte gjorde.
SAVSYS 21, de senaste 5 sparas i en dataarea
Sedan release 6.1 sparas en historik över de senaste fem SAVSYS 21körningarna i dataarea QSRSAV21 i QUSRSYS.
Dataarean har inget med BRMS att göra men kan vara bra att känna till.
ASYNCBRING
En ny parameter till SAV-kommandot är ASYNCBRING.
”Enable objects to be asynchronously brought into memory early so they will
not need to be paged in when first accessed by the SAV processing.”
Vilket har gett allt från 0 till 60% förkortning av backuptiden.
Allt beroende på hur IFS-datat är organiserat.
Virtuella bandrobotar
När man använder virtuella bandrobotar är det bra att känna till att värdmaskinen inte förstår att det är en virtuell bandrobot den pratar med.
Eftersom allting är virtuellt har saker som *LEAVE, *UNLOAD, *REWIND etc.
ingen funktion.
Precis som med fysiska band finns allting kvar tills det blir överskrivet. Att ta
bort en backup innebär inte att man friställer diskyta. Det innebär enbart att
det plockas bort information ur BRMS inventarieregister. Först när man skriver
till sekvensnummer 1 åker det som tidigare fanns på bandet.
Append ter sig tämligen onödigt eftersom vi enbart allokerar det utrymme
som behövs. Funktionen finns egentligen enbart för att kunna utnyttja banden
fullt ut.
Att flytta bort aktiva backuper från i övrigt friställda band (reclaim) har
plötsligt blivit mycket enklare. Speciellt om man tidigare enbart hade en
bandstation.
DSPTAP har blivit ett rent nöje. Inget monterade eller spolande. Poff, klart!