Op een computer zoals de System i wordt door meerdere gebruikers gewerkt, en er worden veel verschillende taken uitgevoerd. Dat betekent dat de beschikbare systeemresources en de beschikbare systeemcapaciteit zo optimaal mogelijk verdeeld moeten worden om een optimale doorstroming van het uit te voeren werk te kunnen garanderen. Hiertoe staan u op de System i veel mogelijkheden ter beschikking, ook zonder daarvoor extra tooling aan te hoeven schaffen. Performance en Work Management is afhankelijk van veel factoren en daardoor vrij complex, maar ik ga u toch proberen aan de hand van dit artikel de beginselen uit te leggen.

door Wim van den Heuvel

Werkverdeling
Er wordt onderscheid gemaakt tussen interactieve taken (gebruikers), batchtaken (bijvoorbeeld back-ups), communicatietaken (communicatie tussen de verschillende aangesloten apparaten) en systeemtaken. Het is zinvol om ook binnen de verschillende taaksoorten te inventariseren waaruit het aangeboden werk bestaat. Afhankelijk van deze inventarisatie kan onderscheid gemaakt worden in prioriteit, toegewezen ruimte en processorcapaciteit. Om dit te realiseren kunnen subsystemen worden gebruikt. Zo kunnen bestaande subsystemen als QINTER of QBATCH worden gewijzigd, maar kunnen ook nieuwe subsystemen worden aangemaakt.

Het werk wordt uitgevoerd in de vorm van een taak, een job. Deze jobs hebben, ongeacht het type, een aantal gemeenschappelijke kenmerken. Zo wordt een job gestart door deze via een takenwachtrij of job queue (*JOBQ) aan een subsysteem (*SBSD) aan te bieden. Een subsysteem bewaakt één of meer job queues en selecteert een job zodra deze aan de beurt is. In principe werkt dit volgens het FIFO-principe (first in, first out), maar binnen de job queue kan er met prioriteiten worden gewerkt (zie afbeelding 1).

Afbeelding 1

Per job queue kan worden gedefinieerd hoeveel jobs er vanuit deze job queue gelijktijdig binnen het subsysteem uitgevoerd mogen worden. Ook op het subsysteem kan een maximum worden ingesteld, voor het geval dat het betreffende subsysteem meerdere job queues bewaakt. Het subsysteem plaatst op zijn beurt de job in een geheugendeel, een pool. Een pool is een onderdeel van het interne geheugen; hier wordt de job daadwerkelijk uitgevoerd. Er kunnen meerdere pools aan een subsysteem worden toegewezen. Het is ook mogelijk dat meerdere subsystemen gebruikmaken van dezelfde pool (shared pool vs. private pool).

Voor onder andere de doorlooptijd van een job is het van belang in welke job queue de job geplaatst wordt en welke prioriteit de job daarbij toegewezen krijgt. Dit heeft te maken met routing data (job) en routing entries (subsysteem). De routingdata van een job wordt bepaald op het moment dat de job wordt gestart. In principe is de routing data voor een interactieve job afkomstig uit de job description (*JOBD) die middels het gebruikersprofiel (*USRPRF) aan de gebruiker is toegewezen. De routingdata van een batch job is afkomstig uit het commando waarmee de job in de job queue is geplaatst (SBMJOB). Zodra een subsysteem een job selecteert, wordt de routing data van de job vergeleken met de in het subsysteem aanwezige routing entries. Als er een match wordt gevonden, wordt de pool bepaald en wordt een categorie of class (*CLASS) toegewezen. In deze class wordt de uitvoeringsprioriteit of run priority en de toegewezen tijd of timeslice bepaald.

Een interactieve job wordt default via subsysteem QINTER gestart, waarbij via routing entry QCMDI de shared pool *INTERACT wordt gebruikt, en class QINTER wordt toegewezen. In deze class is run priority ‘20’ opgegeven.

Een batch job wordt default via job queue QBATCH aangeboden. Subsysteem QBATCH bewaakt deze job queue en selecteert de aangeboden job. De job is default voorzien van routing data QCMDB, en via de routing table in subsysteem QBATCH wordt de shared pool *BASE gebruikt, en wordt class QBATCH toegewezen. In deze class is run priority ‘50’ opgegeven.

Door het wijzigen van bijvoorbeeld de job description of de subsysteemdefinitie kan de verwerking van de job worden beïnvloed. Voor een batch job kan een extra job queue worden gedefinieerd en kan een job queue entry aan een subsysteem worden toegevoegd om aan het subsysteem kenbaar te maken dat deze job queue moet worden bewaakt. Het is ook mogelijk afwijkende routingdata op te nemen en deze routing data op te nemen in de routing table van het betreffende subsysteem. Op deze manier ‘herkent’ het subsysteem de job, zodat de job binnen het subsysteem afwijkend kan worden behandeld. In de routing table kunnen eventueel een afwijkende pool en een afwijkende class worden opgegeven. Ook is het mogelijk een heel nieuw subsysteem in te richten en te voorzien van de benodigde job queue entries, workstation entries en routing table.

Voorbeeld
Om bovenstaand theoretisch verhaal concreet te maken, volgen we een batch job die gestart wordt middels het commando SBMJOB (Taak aanbieden, zie afbeelding 2). De job wordt geplaatst in job queue QBATCH, die genoemd wordt in de job description QDFTJOBD. De taakprioriteit in de job queue, die wordt gebruikt om de prioriteit ten opzichte van de overige jobs in de betreffende job queue te bepalen, wordt eveneens geselecteerd vanuit de job description. Dit geldt ook voor de prioriteit van de output in de output queue.

Afbeelding 2: Taak aanbieden (SBMJOB)

Met het commando WRKJOBQ (Werken met alle takenwachtrijen, zie afbeelding 3) kunnen we zien of de job queue wordt bewaakt, en zo ja door welk subsysteem. Job queue QBATCH wordt bewaakt door subsysteem QBATCH.

Afbeelding 3: Werken met alle takenwachtrijen (WRKJOBQ)

In afbeelding 2 is de routing data waarmee de job is aangeboden afgebeeld (QCMDB). Als we kijken naar de definitie van subsysteem QBATCH (WRKSBSD SBSD(QBATCH)), kunnen we de routing table opvragen (zie afbeelding 4). We kiezen optie 7 om de routing table te bekijken (zie afbeelding 5). De kolom ‘Vergelijkingswaarde’ bevat de routing entries. Helaas, deze bevat geen QCMDB! Wat nu… Aan de meeste subsystemen is routing entry *ANY toegevoegd. Dat betekent dat als er geen match gemaakt kan worden tussen de routingdata van aangeboden job en de routing entries in het subsysteem, de job toch zal worden gestart op basis van deze ‘match’.

Afbeelding 4: Subsysteembeschrijving bekijken (DSPSBSD)

Afbeelding 5: Routespecificaties bekijken

Als we met optie ‘5=Details bekijken’ de overige gegevens in de routing table afbeelden, worden de class en de pool die zullen worden toegewezen afgebeeld (zie afbeelding 6). De job zal worden gestart door deze in de eerste pool van het subsysteem te plaatsen.

Afbeelding 6: Details routespecificatie bekijken

Het commando Werken met Subsystemen (WRKSBS) leert ons dat dat de *BASE-pool betreft (zie afbeelding 7). Er zal gebruik worden gemaakt van class QBATCH. Binnen deze class is de uitvoeringsprioriteit (run priority) opgegeven (zie afbeelding 8).

Afbeelding 7: Werken met subsystemen (WRKSBS)

Afbeelding 8: Categorie informatie bekijken (DSPCLS)

Rest ons de job vrij te geven en te kijken of de job daadwerkelijk in QBATCH wordt uitgevoerd, met prioriteit ‘50’. Hiervoor kan het commando WRKACTJOB (Werken met actieve taken) worden gebruikt (zie afbeelding 9).

Afbeelding 9: Werken met actieve taken (WRKACTJOB)

Conclusie
Zoals in de inleiding al is gezegd, zijn Performance en Work Management afhankelijk van veel factoren. Als u de configuratie van uw System i aanpast om een betere performance te krijgen, is het vaak een kwestie van lange adem. Het is belangrijk niet te veel zaken tegelijk aan te passen. Eén of twee dingen aanpassen, dan monitoren wat de uitwerking daarvan is alvorens het volgende aan te passen.

Lang niet alle aspecten en mogelijkheden zijn in dit relatief korte artikel aan de orde geweest. Meer informatie is te vinden in een aantal goede redbooks die u kunt downloaden vanaf www.redbooks.ibm.com. Uiteraard bent u ook altijd van harte welkom op één van de door IBM of JBS aangeboden cursussen!

Wim van den Heuvel is docent van Getronics PinkRoccade, Java Business Solutions. U kunt hem bereiken via wim.vandenheuvel@getronics.com.