TPMS
Performance
and
Tuning
Worl(sliop
Dave Leeic Dave Hamilton
VTPTUNEV2.0 TPMS Performance and Tuning Contents 0.1 ICL endeavours toensure that theinformation in this document iscorrect but doesnot accept liability for any errors or omissions. f Thedevelopment of ICL products iscontinuous and published information may notbe c^umentup-to-date.Anyor mayparticularcontain facilitiesissue of anot productmaycontaindescribed here. It Is partimportant onlyoftheto checkf^ilitiesthe describedcurrent position in thiswith
Statementsinthisdocument are notpartofa contract or a program product licence save in so f^ as they are incorporated intoa documentor licence byexpress reference, issue ofthis document does notentitle the recipient to access to or use ofthe products describedand such access or use may be subject to separate contracts or licences.
This document was produced by :-
SystemSupportCentre SystemSupportCentre. Internation^ Computers Limited International Computers Limited. Manchester. Bracknell.
Copyright - International Computers Limited 1990.
Contents 0.2 TPMSPerfbtmance andTuning VTPTUNE V2.0 Contents
1 Workshop introduction 1.1. Agenda. 1.3 1.2. Objectives. 1.5 1.2.1. Pre-requisites. 1.5 1.3. Woricshop manual. 1.7 1.4. Introduction to Tuning and Performance. 1.9 2 Design Practices 2.1. General areasfor consideration. 2.3 2.1.1. Main store. 2.3 2.1.2. OCP or millusage. 2.3 2.1.3. Disc transfers. 2.3 2.1.4. Datatransmission. 2.3 2.1.5. Standards of compatibility. 2.3 2.1.6. Diagnostics. 2.3 2.2. IDMS. 2.5 2.3. Conventionalfiles. 2.7 2.4. CAPS. 2.9 2.5. COBOL Programming. 2.11 2.6. Application Master programming. 2.13 2.7. INGRES and SQL 2.15 2.8. Order of Importance. 2.17 3 AVIM Resources and Response Times 3.1. Objectives. 3.3 3.2. The Information Needed. 3.5 3.2.1. Throughput. 3.5 3.2.2. Store Requirements. 3.5 3.2.2.1. Virtual Store. 3.5 3.2.2.2. Mainstore. 3.5 3.2.2.3. Locked Store. 3.7 3.2.2.4. RIRO. 3.9 3.2.2.5. Job Store Quota. 3.9 3.2.2.6. Working Set 3.9 J^.2.2.7. Polk:y Shared Quota. 3.9 3.2.3. DataAccessing. 3.11 3.3. Estimating Servicetimes and Response times. 3.13 3.3.1. AVM Sen^Time. 3.13 3.3.2. Estimating queuing times. 3.13 3.3.3. TP Response time. 3.17 3.3.4. Temfiinal Response time. 3.17 4 Performance Monitoring Tools 4.1. Introduction 4.3 4.1.1. When to monitor 4.3 C4.1.2. What can be monitored? 4.3 4.2. TPMS Periodic Statistics. 4.5 4.2.1. Generating the statistics 4.5 4.2.2. Outputting the statistics. 4.5 4.2.3. interpreting the statistics 4.7 4.2.3.1. ^hedulerstatistics: 4.7 4.2.3.1.1 Scheduler VM statistics 4.7 4.2.3.1.2 Message type statistKs 4.7 4.2.3.1.3 AVMTYPE statistics 4.9 4.2.3.2. ResponderStatistics 4.9 4.2.3.2.1 ResponderVM statistics 4.9 4.2.3.2.2 MessageType Statistics 4.9 4.2.3.2.3 Temninai Statistics 4.9 4.2.3.2.4 Screen Format Key Statistics 4.9
:VTPTUNEV2.0 TPMS Performance and Tuning Contents 0.3 4.2.3.2.5 Badge Statistics 4.9 4.2.4. Displays from control mode. 4.13 4.3. TPMS Statistics Paclcage 4.15 -4.3.1. Availability 4.15 4.3.2. What it provides 4.15 4.3.3. Collecting the statistics 4.15 4.3.4. Using the statistics 4.15 4.4. IDMS Statistics 4.19 4.4.1. Runtime statistics. 4.19 4.4.2. Trace statistics. 4.19 4.4.3. Utilisation statistics. 4.19 4.5. RIe Meters 4.23 4.6. UST USAGE 4.25 4.6.1. GIVE USAGE (GUS) 4.25 4.7. SYSTEM MONITOR 4.27 4.8. COBOL PATH ANALYSIS (COBRA) 4.29 4.9. PROGRAM_ACTlVmr_SAMPLER (PAS) 4.31 4.10. VME Capacity Management System (VCMS) 4.35 4.11. Suggested set of statistics 4.37 5 Service Management 5.1. Introduction 5.3 ( 5.1.1. The areas to consider are 5.3 5.2. DDS Prepares. 5.5 5.2.1. TPMS PREPARE PACKAGED SERVICE(TPMSPPS). 5.5 5.2.2. PREPARETP^ERVICE. 5.5 5.2.3. PREPARE APPLICATION. 5.7 5.3. Making the TP VMs available on service start 5.9 5.3.1. Checkpointing. 5.9 5.3.2. A BetterAlternative for Series 39 sites. 5.11 5.3.3. COBOL run-time code. 5.13 5.3.4. Load the code more quickly. 5.13 5.3.5. Load less code. 5.13 5.3.6. Parameterfile settings. 5.13 5.3.6.1. SQUOTA 5.13 5.3.6.2. MAXPRI&MINPRI 5.13 5.3.6.3. AViy^lME. 5.15 5.3.6.4. AVMMIN. 5.15 5.3.7. Balance the disc traffk: 5.15 5.3.8. Otherconsiderations. 5.17 5.4. Connectingthe network. 5.19 5.4.1. Connection to TP. 5.19 5.4.2. NTCR and SCT performance. 5.19 5.5. Cataloguecontention. 5.21 5.6. TPMS journal management 5.23 5.6.1. TPMS Cyclk;journal. 5.23 5.6.2. TPMS journal library management 5.23 5.6.3. Create the foltowing hooks for your TPMS servk:e. 5.25 5.6.4. For TPMS servk:es defined by a parameterfile 5.25 5.6.5. Forservk:es defined in a Data Dk:tionary 5.25 6 Tuning 6.1. Introduction to Tuning. 6.3 6.2. Areasfor Consideration. 6.5 6.3. Disctransfer priorities. 6.7 6.4. CVM. 6.9 6.4.1. Servk» time. 6.9 6.4.2. VSI's. 6.9 6.4.3. OCP contention. 6.15 6.4.4. Input-Outputs. 6.15 6.4.5. User hooks. 6.15 6.4.6. Number ofservices. 6.15
Contents 0.4 TPMSPerlbtmance andTuning VTPTUNEV2.0 0^
6.4.7. Queue time. 6.15 6.5. AVM. 6.17 6.5.1. Service time. 6.17 6.5.2. VSIs. 6.17 6.5.3. OOP contention 6.27 6.5.4. Suspensions. 6.27 6.5.5. lOs 6.27 6.5.6. Timeouts. 6.27 6.5.7. Queue time 6.29 6.5.8. AVMTYPEs and AVM copies. 6.29 6.5.8.1. Mapping message tyjses toAVMTYPES. 6.29 6.5.8.2. Single application AVMTYPES. 6.31 6.5.8.3. Offload AVM. 6.33 6.5.8.4. Rolling AVMs. 6.33 6.5.9. Message slots. 6.35 6.6. RLESTORE TRANSFERS. 6.37 6.6.1. Serial files. 6.37 6.6.2. Indexed Sequential files. 6.37 6.6.2.1. Structure of IS files. 6.37 6.6.2.2. Buffers. 6.39 6.6.2.3. Overflow. 6.41 6.6.2.4. Overflow at end of file 6.43 6.6.2.5. Locking. 6.43 6.6.2.6. Multiblock transfers. 6.45 6.6.3. Hashed Random files. 6.45 6.6.4. IDMS. 6.47 6.6.4.1. Buffers. 6.47 6.6.4.2. Overflow. 6.47 6.6.4.3. Journals. 6.49 6.6.4.4. Locking. 6.49 6.6.5. Contention. 6.49 6.7. Communications. 6.51 6.7.1. VME Buffers. 6.51 6.7.2. Line utilisation. 6.51 6.8. Summary. 6.53 6.8.1. Twofurther things about store. 6.53 6.8.2. TP Parameter RIe Values 6.55 6.8.2.1. CTRLDAT 6.55 6.8.2.2. AVMTYPE 6.57 6.8.2.3. MT 6.57 6.8.3. LikelyCauses Of Problems. 6.59! 6.8.3.1. CVM 6.59 6.8.3.2. AVM 6.59 6.8.3.3. RIe 6.59 A Appendices A.1 A.1. Bibiiograpliy A.3 A.2. Queuingtimesfor muftiserver queues. A.5 A.3. Probability of exceeding queue sizes. A.7
VTPTUNE V2.0 TPMS Performanceand Tuning Contents 0.5 1.
Workshop Introduction
VTPTUNE V1.2 TPMS Performance and Tuning Page 1.1 o
V-i
n
Pago1,2 TPMS Perfbmiance andTuning VTPTUNE VI .2 I.IJVgenda.
10.00 Coffee And Introduction.
10.10 Introduction ToTuning.
10.20 Design Practices.
11.05 Coffee
11.20 AVM resources and response times.
12.05 Perfbmnance Monitoring Tools.
13.00 Lunch
13;45 Service Management
14:30 Tuning.
15.30 Coffee.
15.45 Tuning Continued.
17.00 Close.
VTPTUNEV1.2 TPMS Perfonnanoe and Tuning Page 1.3 Workshop Objectives
After attending the workshop the attendee should be able to
»>SIz*aTPIISMrvlc«
^-Monitor tha parfonnanca of a TPMS aarvica
»>liivaatlgata tha cauaaa of parfonnanca problama
»>Tuna a TPMS aarvica
VTPT0030
Page 1.4 TPMSPerfbrmanceand Tuning VTPTUNEV1.2 1.2.0bjectives.
The objectives of this workshop are to enable an attendee to:-
— Size a TPMS servKe.
— Monitorthe performance of a TPMS servk». — Investigate thecauses ofperformance problems.
— Tune a TPMS servk».
1.2.1 .Pre-requisites. Abackground in maintaining and supporting TPMS servk»s. Attendance of the VITPF course with some practical experience is the best background. Some design or programming experience would be useful but is not essential.
VTPTUNE VI .2 TPMS Performance and Turvng Page 1.5 r~)
Page 16 IPMSPertbnnanceandTunino VIPTUNEVI^ 1.3.Workshop manual. This document isthe manual produced as part of the TPMS Performance and Tuning workshop. It isintended todocument the informatfon and the slides contained in the workshop The notes cover all thesubjects that will be discussed during theworkshop. The document is split into chapters. Each chapter covers one topfc on the workshop. Chapter 1. This is the workshop introductfon. It covers the layout of this document and the agenda and objectives for the course. It then introduces the concepts and kleas ofperformance and tuning. Chapter 2. Design practfces. This chapter points out some of the main design points that should betaken into account for TPMS andtheproducts that are related toit. Most of the informatton in this sectfon isbased on practical experience. Chapter 3. AVM resources and response times. This sectkjn covers the methods and technkjues used to cafoulate AVM requirenrients and size the AVMs, as well as estimating response times. Chapter 4. Performance and monitoring tools. Akx)k atthetools available for monitoring the performance ofa TPMS servfce and the VME machine. Chapter 5. Servfce management. This chapter deals with three subjects. Faster restart times, DDS preparesand journal management. Chapter 6. Tuning. This is the main sectton of the workshop. This covers the techniques and areas that are required to tune a TPMSservfce. The rest of the manual contains the necessary extra informatfon, such as graphs and examples.
VTPTUNEV1.2 TPMS Performance and Tuning Page 1.7 Definitions
Performance "Using resources in the most efficient way."
Tuning "Adjusting so as to run efficiently."
Sizing "Predicting resources and comparing witli avaiiabiiity."
VTPT0040
Steps Involved
^Decide on level of performance required
Identifyresources used by service
^Check with available resource
^Identify causes of high resource use
^Tune service
^Measure again!
VTPT0050
Page 1.8 TRMS Performance and Tuning VTPTUNEV1.2 1.4.1ntroduction to Tuning and Performance.
the is What is meant by TPMS tuning and pertbrmance. Consider Perfbmiance "Using resources in the most efficient way" Tuning "Adjusting soas to mn efficiently". This gives a definition of performance and tuning, but this Is not all of the story. To adjust resources effiaently, the service will need to be sized. Adefinition of sizing is Sizing "Predicting resources and comparing with availability.
So:-
Performance =Sizing andTuning
Identified.-4 The first and mostwhatImportantto look at,stepin orderis to todecidetune whata service,level theof performancenecessary stepsis appropriateneed to beto w«y to achieve this is to draw^upreacheda servicewithleveltheagreementusers of thewithservicethe userson theirof therequirements.service TyoicailvThe best thi^ould cover requirements for response times, service availability and other operational ^ performarvie aspects of the service. This has tv¥o main advantages — Everyone involved has a clear idea of what Is expected from the service. — The service canbetuned tomeet therequirements. Khappy withHi?®ft and'®the gain cannot be justifiedexpendingin bettertime andoverallenergyr^hineon tuningpeSxmance.aservice if the user is
nnu,now h»be looi(ed at.Thefollowirtg steps must be followed.pertbrmance. the methods used toachieve it can
— Measure the performance of the service. ^ — Identify the resources used by the service. — Check them with ttie availableresources. — Identify any high orabnormal resource usage. — Tune the system to eliminate the abrKirmality. — Measurethe systems performance. This works for an existing system asthe resources that i uses can easily be measured A i^servi«can^be measured unta it Is running, so the resources that it wiH use must be siz^ by working them out from thedesign. This gives two benefits — ThefunctionalityoftheservfcedesignwaihavBbeencheckedandpotential performance problems spotted in thedesign stage. — "The servwe can be measured diFing testing to ensure that Mmeets the expected performance. If not, problems can be resolved before the servk» goes live. consideration manyprincipleservice.thatIt shouMshouWbebegivenworkedequalon Isweightthatperformancewith any otherisadesignfundamentalfactor. If not, then VTPTUNE V1.2 TPMS Perfbrmance and Tuning Page 1.9 For a New system
At the design stage
Agree service level.
^-Size service
Benefits
Design checked
Possible performance problems found.
^able to check whether service will fit into machine.
^-Test service can be measured against requirements.
VTPT0060
Making Changes
Before
Plan Changes
^Plan measurement stategy
^ Plan regression
•Document
After
•Measure effect
•Measure effect on OTHER services
•Check with usersb
VTPT0070
Page 1.10 TPMS Perfomianoe and Tuning VrPTUNEV1.2 the service will eventually develop performance problems. One further point that needs to be made before moving on is ttiat where changes are to be made toa service they should be made one ata time. Each change needs to be measured to ensure no^nly that it has had the desired effect but also that the rest of the system has not been adversely aff^ed. This al^ includes the rest of the VME system. The users should also be consulted to ensure that the change has had its desired eff^. So, in summary, thebasic principles oftuning a service are — Agree the level ofperformance required. — Size and measure the service to seeif it meets the ayeed level.
— Ifit does not, then
Work oiA the change.
Decide how to measure effects.
Work out a regression path.
Document the change.
Makethe change. — Measurethe servKe's performance to checkthe effect. — users have twt noticed any adverse effeds from changes made to ine service.
Tuning Summary
1- Agree service level 2- Does system meet service level? Measure and Size service 3- If n does not, then •Work out the change Work out a regression path Document the change Make the change 4- Measure results ^Both service and VME machine
5- Check with users
VTPT0080
VrPTUNEV1.2 7PMS Performanoe andTuning Page 1.11 n
t]r
n
Page1.12 TPMS Performance and Tuning VTPTUNEV1.2 2.
Design Practices
VTPTUNE V2.0 TPMS Perfonnance and Tuning Page 2.1 Design Practices
General Areas to consider
^ Main Store
•OCP
^ Disc transfers
•Data transmission
•Standards/ Compatibility
•Diagnostics
VTPT2020
Type latency HeadMVT Data(blocl(size) Total (Msecs) Xfers @40%
FDS5000 8.3 17 2.7(7476) 28 14.3
FDS2500 8.3 15 2.7(7476) 26 15.4
FDS760 8.3 16 3.3(7316) 27.6 14.5
FDS300 8.3 20 3.3(7316) 31.6 12.7
FDS640 8.3 25 5.5(6447) 38.8 10.3
EDS200 8.3 30 8.3(6447) 46.6 8.6
Table showing average number of random transfers possible at 40% disctransfer utilisation.
Page 2.2 TPMS Performance and Tuning VTPTUNEV2.0 2.1.General areas for consideration.
The main areas that should be considered when designing a TPMS system are
2.1.1 .Main store.
VME uses virtual store. This allowsVME to hold onlythe requiredcode and data inactual store, the rest being held on disc. VME will swap pages intostore when required, and discardthem when the store is required for other VMs. Transfers to and from virtual store involve disc accesses which are very slow, compared with accessing main store itself. Thus virtual store transfers or VSIs should be avoided if at all possible.
2.1.2.0CP or mill usage.
TPMS runs at the highest OOP priority nextto the MasterOper and VM1. Lengthy mill bound processes could seriously affectthe performance ofthe rest ofthe machine. Such processes should be performed in a batch environment rather than TPMS.
2.1.3.Disctransfers.
TPMS disc transfers have a higher prioritythan those for other services. Disc transfers are relatively slowand should be keptto a minimum. The table on the page opposite gives the figuresfor Latency, Head Movement and datatransfer time for differenttypes of disc. The nominal access time is given by
Latency + Head mvmt + data transfer time.
The final column gives the average number oftransfers possible assuming 40% disc utilisation (Chapter 6 gives details on resource queuing theory).
2.1.4.Datatransmission.
The speed of transmittingdata over a networkis dependent on the type of network involved and the amount of data to be transmitted. Care shoukJ be taken to minimise the anrxxint of data transmitted by the service. The time delays involved may not be trivial and the process also uses some ofthe available VME resource. Avoid transmitting templates unnecessarily, i.e. ifthe required template is already displayed setthe template ID field to spaces inthe output header.
2.1.5.Standards ofcompatibility.
Is this application compatible with existing systems? i.e.
— Will it run on the machine?
— Do the standards for the system fit in with existing systems shouki the need arise to merge TPMS servrces together?
2.1.6.Diagnostics.
Ifyou can bulk! in some diagnostic hooks or procedures intothe system then itwill save some time when a problem occurs. There are basicallytwo types of diagnostics tiiat can be considered - - I \ — tracingPerformancetobeswitchedDiagnostics.on moreThesequickly.are used to enable performance monitoring
— Functional Diagnostics. This wouki normally be some tracing built into code enabled using a software switch to trace coding errors.
VTPTUNE V2.0 TPMS Performance and Tuning Page 2.3 Points to watch
IDMS IDs ^Minimise number of sets •Use Next,Prior and Owner pointers Sorted sets Duplicate data • RANDOM storage for IDMS 510 • Realm scan using CAPS
• Record indexes
• Buffers
•Virtual store areas
VTPT20S0
Points to watch
IDMS Contention
•Read only service
•Control / Superchief records
•Size area and page to avoid overflow
Size VIA clusters to avoid overflow
• Don't MODIPY CALC record keys
• Duplexing
VTPT20SS
Page 2.4 TPMS Performance and Tuning VTPTUNEV2.0 2.2.IDMS.
This section is not intended to lool(at IDMSperformance in great detail but to indicate the main areas to watch. For detailed advice on IDMSdesign, attend the VIDMD course. The advice given here will help to avoid the most common IDMS performance problems.
IQS. 2.2.1 Keepthe number ofsets to a minimum as extra sets will cause extra lOs. Itis good practice to audit each set and justify its existence during the design.
2.2.2 Alwaysprovide next, prior and owner pointers ifpossible. Itsimplifies navigation and can reduce lOs, particularly using Application Master. It reduces the possibilitiesof having to walk the entire setto find previous or owner records.
2.2.3 Sorted sets. Avoid sorted sets as they can slow down retrievalor updates ifthe sets are large or volatile. Use set indexes ifthey become too large.
2.2.4 Duplicate data ifthis will save furtherretrievals from the database. For example, /^\ duplicating keysofownersinmemberrecordswherethere is morethan one ownermay save extra lOs to retrieve the owner record.
2.2.5 Use RANDOM placement on IDMS 510. This new method of record placement will remove the possibility of overflow, thus reducing the potential number of lOs.
2.2.6 Avokj realm scans unless they are performed by CAFS search or in virtual store areas. See 2.3.8 and 2.3.9 below.
2.2.7 AvokJ record indexes whrchare frequently updated or which have many nullentries as they rapidly become unbalanced.
2.2.8 Too f^ IDMS buffers can signifk:antly increase the number of actual disc reads/writes during a success unit. IDMSstatistk:s can be used to determine whether the number of buffers is correct. The ratioof physk:alreads to requests gives an indrcation of howfrequently a bufferis overwritten. Using the IDMS High Performance Option increases the maximim total buffer size from 256Kb to 16 Mb.
2.2.9 Virtual store areas can significantly reduce lOs on read only areas ofthe database, especially for kx)k-up tables. The IDMS HighPerformance Option increases the usabilityof virtual store areas by allowing a maximum of 450 Mb of store to be used.
Contention. 2.2.10 Use a read onlydatabase servk;e for online retrieval, batch or Querymaster access whilst the service is running.
2.2.11 AvoM superchief or control records that are updated. They must be one of the biggest sources of database contention.
2.2.12 Size the database area and page size to avokJ overflow.
2.2.13 Size VIA clusters so thatthey will not cause overflow, 'h
2.2.14 Don't modify the keys of CALC records. This causes relocated records and extra lOs.
2.2.15 Duplexing database areas can improve the performance of a database area as reads will be done from alternate plexes. Writes will, of course, be more expensive as both plexes will need updating. Plex updates will overiap to some extent, sothe costs are reasonable
VTPTUNE V2.0 TPMS Perfomnanceand Tuning Page 2.5 Points to watch
RECMAN
• Use CAPS
• ISAM or Random?
•Alternate Indexes
•Buffers
•Control records
•Overflow
VTPT2060
Page 2.6 TPMS Performance and Tuning VTPTUNEV2.0 2.3.Conventional files.
Conventional or RECMAN filesprovide few problentsfrom the design pointof view. Discussed in detail in chapter 6.
2.3.1 Considercarefully whether a file shouldbe accessed sequentially onlineand if possible,where the hitrate is less than 30%, use CAPS to perform any searches ofthe file. This providesmany advantages insaving OCP and lOs as the scanning is done at hardware speeds, a maximum of 2.5 MBper second for a FDS 2500.
2.3.2 Considerwhether a file needs to be indexed sequential or whether hashed random would be better. Hashed random files providefaster keyed access to data as there is no indexto read before obtaining the record,so for a file which is never seriallyread, hashed random would be better. , n t
2.3.3 Onlyuse alternate indexes on read onlyfiles. Itis not possible to use them for updates when using RECMAN Recovery. Ifusing an alternate index ensure that itis correctly set up to generate an indexwith blockpointers not an ISAM file pointing at the main index file.
2.3.4 Increasing the number of buffersallocated to a filecan signifk:antly reduce the actual number of disc transfers partk:ularly on ISAM file indexblocks. Chapter 6 deals withthis in more detail.
2.3.5 Locking and deadlocks are unavokiable but will causefew problems ifcontrol records are kept to a minimum. Ifthis type of record is required itwouki be better to introduce a heirarchy ofcontrol recordsto reducecontention to a minimum forthistypeof record.
2.3.6 Overflcn/v can cause a serious problem with IS and Hashed Randomfiles. Frequently reorganising the files will reduce the possibility of overflow. Overflow at the end of a file can be reduced on SV290, see Chapter6 for details.
VTPTUNE V2.0 TPMSPerformanceand Tuning Page 2.7 r^
Points to watch
CAPS
^Low Hit rate
^Minimise data searched
^Disc contention
^Run on Copy of data
VTPT2070
Page 2.8 TPMS Performance and Tuning VTPTUNEV2.0 2.4.CAFS.
CAPS provides fewproblems In a TPMS service provided thatthe basic rulesforusing CAPS are adhered to. These are
2.A3_CAFS should be used where keyed access is not possible and where a lowhitrate of (less than 30 -40 %)s expected. Note that CAPS transfers are larger, because the CAPS buffer is transferred, and willtake tonger than normal disc transfers.
2.4.2 CAPS transfers have a lower OOP priority than nomial disc transfers and will be interrupted bydisc transfersofthe same or higher priority. Thiscouldsignifk:antly increase the amount oftimethat a search takes ifthe disccontaining the file is heavily used.
2.4.3 It may be worth creating secondaryfiles or a separate database area on different disc drivesand controller fromthe mainfilesto CAPSsearch, e.g. searching forcustomer name or address may wellbe quicker on a filecontaining onlythe name and address as CAPS textand a.key tothe record inthe main file ordatabase area, raUier than searching the wholecustomer file. The secondaiy file, ifupdated overnight inbatch couW also have 100% packing density thereby increasing the efficiency ofthe search. ^ ^ cooH 3 5ierrtyr 2.4.4 Por IDMS using a second record type in a separate area on a differentdisc and controller will reducedisccontention during a CAPS search and speed up the search. The packing densityofthis area couldalso be increasedto improve the search speed.
2.4.5 IT IS IMPORTANT TO NOTE THAT WHEN CONSIDERING CAPS DISC LAYOUTS ALL IDMS, TPMS,MAC and BATCH SERVICES MUST BE TAKEN INTO ACCOUNT TO ENSURE THAT OPTIMISING CAPS ACCESS POR ONE SYSTEM DOES NOT SIGNIFICANTLYAPPECTTHE OTHERS.
2.4.6 Programs shouM not start and stop CAPSsearches over several TPMSphases. This causes CAPS to re-search a consklerableamountofdata. Itis more efffcient to perform the (Se^h in the first pnase and store keys^or later retrieval in subsequent phases. This can be achieved by storing the Keys in parfejTesults during the first phase. This also gives abenefit in ^ngadpgLmore powerful processin^.g. paging forwards and backwards through the data and ii^rming the user of how many hits there have been sothat the search may be modified to reduce the items to be displayed.
VTPTUNE V2.0 TPMSPerformanceand Tuning Page 2.9 Points to watch
COBOL
Maintainable Use External data areas • Parameter passing • IDMS records areas • Input and Output message •Common data areas Collecting • Reduces store usage • Reduces loading costs Global code • Reduces store usage
VTPT2080
Top level
2nd level
vtpt2085
TPMS Performance and Tuning VTPTUNEV2.0 2.5.COBOL Programming. COBOL isthemost flexible l^uagefor writing code for aTPMS service. However COBOL programs can makeuse ofallthe facilities available within TPMS and maybecomecomplicated and difficuit to maintain. The following pointsare worthconsidering when designinga COBOL TPMS program.
2.5.1 Program must be easily maintainable and keeping the program small with one defined function will aid this. Always try to keep to a standard of one COBOL module processing one screen within a service.
2.5.2 Modularprogrammingtechniques can effect a large saving both in coding time and in store usage.
2.5.3 External areas can be used to save store in a TPMS AVM by using them for
— Passing parameters between a main module and subroutines.
— IDMS record layouts. Ifthe record layouts are external then IDMS BINDS need onlybe done once within a VM as all record layouts in each program will have the same address. A first time switch in an external area can be used to ensure that they are only done once.
— Input and Output message areas.
— Common data areas inworking storage;paitknjlariy useful inmodular programs or instituationswhere modules each message type is dealt with by calling a subroutine from a cobol module. Inthis case comnrwn working storage areas can be used becuase onlyone of the modules sharing an area are used in a phase.
— When using external areas for either workingstorage or parameter passing it is important that the programmer pays particlar attention to how data items are initialised and the paththrough the varioussubroutines. Using these techniques /r withoutcareful thought coukl lead to spurious programmingproblems and . possible datacorruption.
2.5.4 Collecting code reduces the amount ofstore used within a system and also reduces the costs of toadingthe code. ^
2.5.5 Globalcode is essential for any system that uses multiple copies of AVMs. Each VM uses the same copy of the program thus signifk:antly reducing the store overheads. At SV231 or earlier this requires the code to be amended with ModuleAmender to setthe global property and for the code to be loaded from a servk:e library, at SV290 the loader will load pure code areas globally ifloaded from a service library.This removes the need to mark each program as global,thus reducing the maintenance overhead of using global code.
2.5.6 Using LOAD_COBOL_PROGRAMS can significantly reduce the cost of using CALL 'dataname' as each program called will be indexed by loader reducing the need to search the loading environment as each programis called. LOAD_COBOL_PROGRAMS can be called without specifying any programs inwhk:h case itwill leam as each program is called reducing the overhead on each subsequent call.The callto LOAD_COBOL_PROGRAMS shouMbe placed in the AVM SCL1NA hook.
VTPTUNEV2.0 TPMS Perfomiance and Tuning Page 2.11 Points to watch
Application li/laster
•Use separately compiled Dialogues and Components
•(Minimise variables
I • Use COBOL subroutines
VrPT2090
Page 2.12 TPMS Peffbrmance and Tuning VTPTUNEV2.0 2.6^pplication Master programming. Application Master provides the easiest route into building a TPMS service. Itisa very powerful language which, In inexperienced hands, canproduce very inefficient IDMS navigation. The following points provide some guidance on techniques inAM. Further information can be found inthe QUICKBUILD EXPLOITATION GUIDE.
2.6.1 KeepAM structures small. Donot txjild one monolithic application as this will almost certainly lead to later complications.
2.6.2 AtAM250 use the facilities forwriting separately compiled components to reduce repeatedcode. AM compiles a component inline foreach call within a module so calling a component several times produces several copies ofthat component. Using a separately compiled component will reduce the anuxint ofcode generated. 2.6.3 Keepthe number ofvariablesto a minimum as this will minimise partial resultsusage.
2.6.4 Where sophisticated stringor array handling is requireditmay be more efficient to use a purpose built COBOL module rather than the QB standard modules. This will reduce the numberofvariables used within the programand couldsignificantly reduce the number of calls to other modules.
2.6.5LOAD__COBOL_PROGRAMS can be usedto reduce the costs ofcalling AM dialogues using the technique outiined in section 2^6^. 2 . r. ^ A/0
VTPTUNE V2.0 TPMS Performance and Tuning Page 2.13 Points to watch
INGRES
Maximise SQL
•>Use REPEAT
>-Test Using QEPs
Duplicate data?
VTPT2100
Page 2.14 TPMS Performance and Tuning VTPTUNEV2.0 2.7.INGRES and SQL.
INGRES Isa relationaldatabase system that can mn on VME. Itis possible to embed Structured Query Language (SQL) to access INGRES into either AMor COBOL on VME.This enables access to an INGRESdatabase on VME fromTPMS. The points relatingto AM and COBOL applyequallyto embedded SQLprograms butthere are a few pointsworthmentioning that are speciftc to INGRES. These are coveredinmoredetail inthe INGRES System Design And Tuning Course and the INGRES Embedded SQL Course.
2.7.1 Use as few SQL statements as possible. Each SQL statementshould do as much work as is possible whilstkeeping database retrievals effident. There is no point in requesting 500 records fromthe database Ifonlyone is to be displayed. This will reduce backend/front end communk:atk)n and reduces overall database access. Partk:ularly avokJ IDMStype setwalking processing technkfues.
2.7.2 Where the same enquiry is used many times use the REPEATutility.
2.7.3Test out the SQLbygeneratinga QueryExecution Planto check on what type of access isbeing perform^ for theSQL function.
2.7.4 As withany other database itmay be worth repeating data, i.e. foreign keys, In related tables to avoid having to search moretables than necessary and to simplify SQL retrievals.
VTPTUNE V2.0 TPMSPerformanceand Tuning Page 2.15 n
Page 2.16 TPMS Performance and Tuning VrPTUNE V2.0 2.8.0rderof Importance.
Most development and design work is a compromise between available resources and the idealdesign for performarKe. To ensure that the performanceofthe design is maximised In the short timeavailable, some priorify mustbe assignedto each resource. The best wayisto prioritise the resources in terms of their importance intuning a system, i.e. where the most benefit will be found. The following could be used
— Disc transfers.
— Store usage.
— OOP usage.
Considering each of these areas inthe order specified will produce the most benefit
VTPTUNE V2.0 TPMS Performance and Tuning Page 2.17 3
AVM Resources and Response Times
VTPTUNE V2.0 TPMS Perfomnance and Tuning Page 3.1 Areas to consider
Mainstore Requirement
- Calculate correct quotas
Predict response times
IMeetagreed targets
VrPT3010
Page 3.2 TPMS Performance and Tuning VTPTUNEV2.0 3.1 .Objectives.
The objectives of this activity are as follows:
— To establish the mainstore requirementof newor expanded services inorder to determine correct store quotas for AVWTYPEs.
— To predict response times which are within agreed limits.
VTPTUNE V2.0 TPMS Performance and Tuning Page 3.3 Information needed
Message throughput
Store requirement
i Data Accessing
VrPT3020
store Requirements
^Working Set code
^Working Set data
^Size of global code
^Slze of global data
•RECMAN buffers
»^IDMS buffers
^TP Spooler documents
VTFT3030
Page 3.4 TPMS Performance and Tuning VTPTUNEV2.0 3.2.The Information Needed. Theimplementor needstoobtain information onthefollowing for eachmessagetype: —message throughput. ^ ^ ^ 4^0 rj^
— store requirement.
— data accessing.
3.2.1 .Throughput Obtain an estimate ofthenumber ofmessages expected tobe input, both on average andat peaktimes and build upa picture ofmessagedistribution ona daily, weekly and monthly basis. This can be represented as a bar chart.The systems analyst(s) shouldbe able to provide this infomnation based on the number ofterminals to be used and the expected transaction rate pertenninai at different times.[^emember that if aforced SEND' f^ility is implemented then allowance will have to be made for the extra message pairs involved. Itmay be over-optimistk; to assume that terminal users are always going to HOME the cursor even if they have been asked to! //^ 3.2.2.Store Requirements. ^^ ^ . Information will need to be obtained on the following to allow the store requirements ofeach message type to be calculated: L C-iVH — Working set code.
— Working set data. — Size of global code. / 5 A r /
— Size of global data.
— RECMAN file blocksizes & number of buffers.
— Database page size and no. of buffers.
— TP Spooler documents generated. ^
The complete AVM sizing informationis given in Section 6.5.
3.2^.VME and Store.
Since the utilisation ofstore is one ofthe mainareas ofTP tuning exercises, itis important to understand the bask: corK:epts of Mainstore, Virtual store, Job Quota etc and to have a broad understanding of the way in whk:h VME handles the allocation of Mainstore.
3.2.3.1.Policies and Store Priority.
VME categorises its resources into 10 different resource profiles calledpolk:ies. Within a poik:y manyVMs may run. Forexample, the MAC policy (Polkiy 2) categorises all the MAC servk:es runon the machine. Production TP normally runs in Policy 4. Some polk:ies have a higher priority for store than others. Production TP runs ata higher store priority than ^most everything else on the machine, so that itwill always be given preference over MAC and BATCH in mainstore allocation.
3.2.3.2.Virtual Store.
Virtual store is ail the store available on the machine to be used by VMs. All the code and ^ data used by the VM will bepart ofvirtual store. Some ofit will bein Mainstore and some will beon a
VTPTUNEV2.0 TPMS Perfomnance andTuning Page 3.5 store
^Virtual Store
^Main Store
»• Locked Store
•^RIRO
»• Job Quota
^Working Set
^Policy Shared Quota
VTPT3040
Page 3.6 TPMS Performance and Tuning VTPTUNEV2.0 secondary storage site. Virtual store is discarded to secondary storage and is fetched into Mainstore In zones - usually 6KB In size.
3.2.3.3.Mainstore.
Mainstore is store which is directly addressable by the OOP. It is a subset of Virtual Store. Code or data has to be present in Mainstore before it can be accessed, tf it is not in Mainstore when a request is made to access itthen itwill have to be fetched infrom secondary storage - the zone containing the targetpage will be copiedinto Mainstore. Thisconstitutes a Virtual Store interrupt (VSI). Further, rf thereis insufficient Mainstore available to accommodate the zonethenpages will have to be discarded from Mainstore to make room for it- perhaps having to be written to secondary storage. A VSI caused when a page In secondary store is needed will Involve at least one disc transfer and may involve several. As with user disc transfers, VSIsshould be kept as low as possible.VME tries to ensure that itis the pages least likely to be required whk:h are discarded.
Ifthere is contention for Mainstore,VME will enter a discard cycle inwhk:hitwill discard zones to secondary storage until it has sufficient free pages. Itwill not exitfromthis cycle, even ifit has freed suffk:ient Mainstore, until it reaches the end ofa segment. Ifa large segment size is specified to Collectortherefore, in this situationthere may often be unnecessary discard VSIs.
3.2^.4.Locked Store.
Locked store is a subset of Mainstore which cannot be moved in mainstore or discarded to secondary storage and remains in Mainstore until the VMends or is rolled out. File buffer areas are normally locked store.
/ Itis possible to specifyfor a RECMAN file that the file buffersshould be collapsed when not in use. Thiscan make a signifrcant saving in Mainstore where a file is accessed very rarely, it is specified bysetting IOBUFFERPOLICY=V ina callto DESCRIBE_FILE_USAGE or SET_FILE_OPTIONS. Itwill of course cause some delay and some VSIs when the fileis accessed. There isnocorresponding f^ilityfor IDMS page buffers. /
VTPTUNEV2.0 TPMS Performance and Tuning Page 3.7 STORE FOR A VIRTUAL MACHINE
Virtual Store
Main Store
Job Quota
Working Set
Locked Store
VTPT305(
Page 3.8 TPMSPerformanceand Tuning VrPTUNEV2.0 3^^.5.RiRO. ''^ ifiaucnt^ RIRO (Roll-ln-Roll-Out) mayoccur If the VM 'longsuspends' - the entire VM gets copied to secondary storage and the Mainstore is released. The RIRO Itself is done In 60KB transfers (Increased to 240KBat SV290). ForTP AVMs, RIRO may occur ifAVMMIN is set lowerthan AVMMAX. Particularcare must be taken insizingthe quotas of VMs which are candidates for RIRO, sinceVirtual StoreManager (VSM) will generate discards for the VM until itis below itsjob quota before copying the VM to secondary storage. Further, there is a maximum overall RIROsize of 420 KB on 2900 and 1440KB on Series 39 and forVMs whose quota is largerthan thisyetfurther discards have to be made prior to roll-out to reduce the VMto the maximum RIRO size. Ifthis causes partofthe working set to be discarded then itwill havea very disruptive effect on the VM andperhaps on the system as a whole, as when it is rolled back in, the VM will have to cause VSIs to re-constitute its working set.
3.2.3.6JobStore Quota.
Job store quota is the minimum amount of Mainstore that VME will give to a VM when the VM is present inMainstore. Itisfixed fora TP VM bythe RQUOTA parameterduring normal running and bythe SQUOTA during initialisation. If the locked store requirement ever exceeds the jobquotathe VM will fail with MAINSTORE QUOTA EXCEEDED or MAINSTORE QUOTA TOO LOW(^Where free store is available VMs, partrcularly Production TP VMs, will usually run well above their job quota.^ 3.2.3.7.WorkingSeL I-r Working set means that part ofthe code and data inan AVM which is needed to process the average message. Ifthe job quota can be set above the sum ofthe lockedstore and the working set then the average message will usually incur no VSIs, since allthe code and data itrequires will remainin Mainstore even when the AVM gets discarded downto quota. Initially, itmay be assumed thatthe working set ofan applk:ation is 40% ofthe virtual store occupancy, though thiscan clearly vary greatlydepending on the application. The Collector listing should givea good indk:ation of the true size, partteularly where COBOL Sectionsare being used. Othenvise, PAS(Program Activity Sampler) couldbe used during testingto showwhich segments are beingaccessed.
ijYi 1-^ VTPTUNE V2.0 TPMSPerformanceand Tuning Page 3.9 3.2.3.8.PolicyShared Quota. Policy sharedquotaisa storequota for all global codeanddata loaded byanyVM running in a given policy, it is specified by the SQ parameter to either DEFINE WORKMIX or CHANGE_WORKMIX. If a value issupplied for SQ inPolicy 4 then all the global codeand data loaded by CVMs and AVMs in TP Production will becharged tothe PSQ andnottothe VM which first loaded it. If using a PSQ for thefirst time then this should result in a reduction in quotas in CVMs andAVMs. Although a global segment accessed byseveral AVMs will still only be loaded once ifa PSQ is not used, there are serious drawbacks to not using one. Rrstly (pre-SV290), since itwill not be l Be aware that at SV290 and laterany pure area will, bydefault, be loadedglobally (orin 'shared mode") and theywill therefore be charged to the PSQ ifone is inuse orto the SystemQuota if there is no PSQ. If forsome reason such areas are notto be loaded shareably, either ensure that the module is loaded from a library notcapable ofsupporting global loading - i.e. a library whk:h does not have the SERVICEUBRARY property - or specify ina callto SET_LOADER_OPTIONS inyour SCL1NA hook thatshareable loading isto be switched off. Alternatively, shareableloading can be switched off at system initialisation. VTPTUNEV2.0 TPMS Performance and Tuning Page 3.11 RECMAN Accesses »>Blocksize Record Size •Data / Index blocks k-Key Length •Organisation s •WRITES/REWRITES READS /DELETES •Type of Access VTPT3070 Page 3.12 TPMS Perfonnance and Tuning VTPTUNEV2.0 3.2.4.Data Accessing. For RECMAN files, obtain the following information so that the time spent on accesses to the file can be calculated: — Blocksize. — Record size. — Number of data and index blocks. — Key length. — Organisation. — Number of READs/WRITEs/REWRITEs/DELETEs. — Type of ACCESS needed. This information will be used incalculating the time needed for an AVM to process the message, it will also be used to give an estimate of the additionaldisc traffk: to be expected on implementation. For IDMS, itis more difficult to predictthe numberof disc transfers caused byprocessing a message. However, a reasonable estimate can be made from the Bachman diagram, and this can be checked at a later stage from IDMS statistk:s. IDMS Part V gives some guidance in this area. VTPTUNEV2.0 TPMS Performance and Tuning Page 3.13 Resource Response Times Response time = Queue Time Service Time VrPT6020 Filestore transfers •OCP time for 5000 COBOL instructions on a l-evel60 = 14.4 msecs •Time to service one random disc access = 40 msecs • DISC TRANSFERS ARE SLOW! - Keep number of transfers iow - Service transfers quiclciy VTPT3085 Page 3.14 TPMS Performance and Tuning VTPTUNEV2.0 3.3.Estimating Servicetimes and Response times. Response time is the sum of the time taken to service an item (inthis case a TP message) and the time spent queuing for the entity that services it. There are two response times to be taken intoaccount here; the TP response time, which is the time between the CVM receiving the inputmessage and passing the finaJ reply to VME foroutput to the terminal, and the terminal response. Terminal response is sometimes defined as the interval between pressing the SENDor ACTN keyand the firstcharacter of the replyappearing on the screen. From a terminal user's point ofview itcould be more usefullydefined as the intervalbetween pressing the SEND key and the terminal returning intoTYPE mode having displayed the complete reply. 3.3.1 JWM ServiceTime. The largest component in the TP response timewill normally be the time spent processing the message inthe AVM. This will consist of time using the OCP and time doing disc transfers. The slide illustrates the insignificance of the OCP time relative to the disc transfer time, and because of this, a good approximation of the AVM servrce time can be obtained simply by knowingthe number of disc transfers: add the number of lOs and (VSIs * 2). As a rule of thumb, 20 lOs on a Level 80 equate to 1 second; or 15 lOs to 1 second on a Level 35.: e.g. A message does 25 disc transfers in the AVM on a Level 80 AVM servk:e time = 25/20 = 1.25 seconds This figure, coupled withthe throughput figures, will be used by the implementor to calculate the AVM response time, by adding the queuingtimeso that the TP response time and ultimately the terminal response time can be calculated. VTPTUNEV2.0 TPMS Performance and Tuning Page 3.15 Resource Utilisation Utilisation =Used Capacity Total capacity I VTPT6030 Response times Response time = Service time Queue factor VTPT60S0 Page 3.16 TPMS Performanceand Tuning VTPTUNEV2.0 3.3.2.Estimating queuing times. Having estimated the AVM service timewe should tal Response timescan be calculated foreach resource used bya TPMS service.There may also be queues forany shared resourceand the lilcely queue timecan be calculated depending on the utilisation ofthe resource.These figures will helpto estimatetiie response time that can be expected and also point to problems in using particular resources. The response timecan be calculated accordingto the following formula Response time = Queue time + Service time. This highlights the fact tiiat for each resource which is to be utilised it must be considered whether it is used heavily enough to cause queuing. The utilisation of a resource can be calculated from the formula below Utilisation = Used capacity/ totalcapacity. e.g. An AVM handles 1500 messages at an average of 1.25 seconds service time (mean real time) in a one hour period the utilisation is as follows ^ I hl>U^ Utilisation = (1500 3600 =0.52 ut'hse^ Having obtained a figure forthe utilisation ofthe resource, workout a figure for queue time. Takingthe utilisation figureabove, use the graph 'Queuingtimefor Multi'server Queues', inAppendix A.2,to obtaina queue factor.Thiscan then be used as a multiplier forservk:e timeto give response time. This method provides a figure for response times whk:h is relative to the number of servers for the queue and the utilisation of tiiose servers. The formula now reads Response Time = service time * Queue factor Usingthe previous example itcan be seen, referring to the graph, that the queue factor is 2.1. Hence the response timeisz,^ , Response time = 1.25 = 2.63 seconds. This shows that queue times can have a dramatic effect on the response time of a particular resource as the technique applies equally to disc response times. COMMStraffk: etc. Where we need to consider the effect of many queues on a response time, e.q. where we may have queuing for disc resources as well as for AVMstiien the lower level resource should be considered first as this will affectthe average response time used to calculate the overall response times. it should be noted that there are generally 2 differentsituations that must be considered when workingout the AVM utilisation. Average utilisation and peak utilisation. The average utilisationcan be used to predk:t normal response times. The peak utilsationcan be used to predk:tpeak response times, e.g. ifthe peak message rate VTPTUNE V2.0 TPMS Perfbmriance and Tuning Page 3.17 Response Times Terminal Response Time = TP Response Time + COMMSTime •TP Response Time = CVM ServiceTime •I- AVM ServiceTime (+ Queuing) VTPT3080 Page 3.18 TPMSPerfbnnance and Tuning VTPTUNEV2.0 through the AVM is 2000 message per hour then (usingthe example above) then the utilsation becomes Peak utilisation = (2000*1.25) / 3600 = 0.69 The average and peak utilsation figures will be used, inchapter 6, to determine the correctnumberofAVM copiesfor 2m AVMTYPE and and eilso to calculate the numberof message slots for the AVMTYPE. Calculating the estimated response timeforthe peak utilisation will also denK)nstrate how peaks in message arrival rates can affectresponse times, e.g. peak response time = queue factor for 0.69 utilsation * 1.25 = 3.3*1.25 = 4.12 seconds Hence the response time in this AVMTYPE can vary between 1.25 and 4.12 seconds! The graphs used are for an infinite population. 3.3^.TP Response time. Forthe purposes ofpredating approximate terniinal response times tiie timespent inthe CVM should be so small as to be insignlfk:ant, unless tiiere are disc transfers in user hooks. Ifthere are (and we recommend that there should not be!) then the CVMservice time can be calculated as it was for the AVM. Ifthere are not, then CVM time can be ignored in this calculation. 3.3.4.Terminal Response time. The remainingcomponent in tfie terminal response time is the COMMS time. There is no simple formula for calculating this, nor anyeasywayofmeasuring It, yetitmay havethe most impact on the terminal response time. Tuning tiie COMMS network is outsidetiiescope ofthisworkshop, but itwill be necessaryto produce a figure forCOMMS time inordertoestimate thetotal responsetime. Onewayofdoing itwould be tofind the terminal responsetime ofa message on an existing servrceby literally usinga stop watchand then subtract the TP response timeas itappears on the Periodic Statistics. Alternatively, an SCL procedure such as tiiat below could be used to find the approximate timetaken to send a message from the terminal to VME and the reply backagain. To return to the above example; in this case the COMMS time has been estimated as 2.00 seconds and there are no user hooks being used in the CVM. So, TERMINAL RESPONSE TIME = COMMS + TP RESPONSE TIME = 2.00 + 2.63 = 4.63 seconds One important pointto note here is the effectofthe COMMS tinne on theTerminal Response Time, which mightwellbe very considerable, it is no good trying to fine-tunethe TP service to improvethe servk:e to end users ifthe COMMS networkis chronk:a!ly slow. The other importantpoint is that given that the major part ofthe TP response time is almost VTPTUNE V2.0 TPMS Perfomnance andTuning Page 3.19 certainlyspent doing disc transfers, ifthe design demands that a message does 50 lOs then no amount of tuning will produce a 1 second response time. PROC COMMSUME iS 0 PROCBEGIN STRING INMESS :s HLL(2000) INT COUNTER :> 0 INT START.TIME CLOCK LABELA: , i ASKMESSAGE(RLL(230) * HEX(2200230027F6220327F4)^NMESS,MESSLEN) COUNTER IB COUNTER * 1 IF COUNTER LT 5 THEN GOTO LABELA n ENDjriME CLOCK ELAKEjnME := {ENDJOME - STARTjnilE) / 5 SMSGC *** AVERAGE COMMS TIME » • * NUMERIC (ELAPSE.TIME)) SMSGC BYTES SENT a - +NUMERIC (ME^LEN)) PROCEND This procedure uses a 240 byte message. The lengthofthe inputmessage is determined by the 8th pair of digitsin the HEX string multiplied by 80. The length ofthe output message is the the number in parentheses after FILL in the ASKMESSAGE plus 10. Generally, the longerthe message the higher the COMMS time, since long messages may involve transmittingseveral packets of data. Try the procedure several times and at differenttimes of day. VTPTUNE V2.0 TPMS Performance and Tuning Page 3.21 Page 3.22 TPMS Performance and Tuning VTPTUNE V2.0 4. Performance Monitoring Tools VTPTUNEV1.2 TPMS Perfbrmance and Tuning Page 4.1 Monitoring Tools »-TPMS Periodic Statistics ••TPSTATS pacitage »>iDMS Statistics »>RECiMAN Fiie iMeters >>LUS&GUS ^System IMonitor >>COBPA & PAS »>VCIMS VTPT4010 Page4.2 TPMS Pefformance andTuning VTPTUNEV1.2 4.1.Introduction 4.1.1 .When to monitor Fadlities to monitor the performance ofthe systemwill be used In threemodes: i) During development and implementation, toensure that thesystem as Implemented canmeet thelevel ofperformance agreed and toIdentify potential problems atthe outset ii) During nomnal njnning, to identify and rectify any performance degradation before the end users are aware ofany problem. lii) In responseto a major perfbnnance problem, In an effort tofind the cause ofa serious degradation which is perceived as having beensudden. Rigorous performance checking should be done in the development phase, as any In-buit performance problem, perhaps due topoor design, wil beatthebest very expensive and atthe worst impossible tocorrect when a major problem has become apparent In thelive sen/ice. If the system is sound atimplementation, and sensftile monitoring is done during nonnai running, then theservice manager should rarely bein theposltfcm of needing toinvestigate performance in the third mode. 4.1J2.What can be monitored? When a TP VM isprocessing a message it wS bedoing one of four things: i) Using the CX^P - i.e. executingmstructk)ns. iO Doing lOs - l.e. accessing filestore. Hi) Suffering VSIs-as discussed In chapter3. iv) Waiting todo one of the above-either queuing for the resource orwaiting for a semaphore, event or lock. Itwin also be using mainstore. VME provkles interfeces fbr reporting resource usagein terms ofOCP, lOs, VSIs and mainstore. Thestatistics produced byTPMS makeuse ofthisInformation, as well as intervals between dock tunes atvarkMJs stages of the TPMS processing, togive response times. Some information ontime spent queuing Is avalable from theTPSTATS package but much ofthis type of infomiation wil haveto be de(ftjced. Other facilties may be used toassess theefficiency oftheusercode- COBOL_PATH_ANALYSIS for COBOL code and Program Activity San^Aer fbr OMF. System Monitor wilshow the overall machine performance. VTPTUNE VI .2 TPMS Perfbrmanoe and Tuning Page 4.3 TP Periodic Statistics Sciieduier Statistics *>FUNC=0 •^ISTCALL early •FREQ ^UNITTIME ^Every 30 - 60 minutes VTPT4020 TP Periodic Statistics Responder Statistics »>FUNC=4 1STCALL early >>FREQ »>UNnTIME Once or twice daily VTFT4030 Page 4.4 TPMS Performanoe andTuning VTPTUNEV1.2 4^.TPMS Periodic Statistics. The periodic statistics contain useful information on how the service is performing. They must be u^ as astarting point in any TPMS performance assessment, and they wil indicate^e generai problem areawhen any perfomiance problem isbeing ir:ve8tigated. which canTheyk)e generatedare dividedindependently.Into huo separate groups: Schedulorslatis«cs and Responder statistics' 4.2.1.Generating ttie statistics recoid mByttradefault they VKiaHe ornotpropertiesl)e generated.on theThayTSEareelementinvokedTheby relevantspedMnaparametersvalues in theareCTRLDATFUNC=0 tor Sch^uler statistics and FUNC=4 for Responder statistics. The intervals at which calls ^ made are by the ICT^U. ^ TOO parameters, expressed as multiples of the UNITTIME dS^TnSLfeS^' ^ to alow value as the initial set olfigures is greatly Schedule statistics are generally by f^ the more useful of the two for the purposes of tuning, so collect these atfairiy frequent intervals. There is something of an overhead in /collecting them so on a live sen/ice they should not be collected TOO frequently. When any kind of I penonriance assessment is being carried out every 30 minutes is a useful sampling period For nomial njnnmg on a busy service this could be reduced to once every 60 minutes, and it may be wise tostagger thetimes at which Scheduler and Responder statistics are collected.. R^ponde^tistira are of less interest. although they may provide useful information for smng tiro Comms traffic. Usually they are much fonger than the Scheduler statistics sothere is obviously a greater overhead in outputting ttiem. It should be sufficient to output them acouple of ^1 bej^en^when the ®service is closed, but note^ ttiat this ofwillstatistics,be doneforonlytheif thelastserviceunfinishedis period, tidiy: If It is force dosed then these statistics wiy be lost ^ / 4.2.2.0utpiitting ttie statistics. lagging is being used then the periodic statistics will be written to the logfle,ottien(wse they written to the TPCONTROL journal. If written to a logfile. when ttiey are offloaded ttiere is ttie overfieadoptiOT of wrrtmgto mftottiemttiemtotottiea logfie.Audit ofBoadHowever,journalif loggingor to theis notauditrequiredfite -orforbottianyorottierneittier.reasonIt is ttienless ofttierean Waiwmay be ausing foggingto avoidisttw recommendedoverhead. If ifLOG=USERonly for ttiisispurpose.spedfied.If implementingttie overhead loggiMis not great,for ttieandfirston time ttien remember ttiat ttieservice wil crash if ttiere isa logging failure, unless LOGFAIL=CONTINUE isspedfied. VTPTIINEV1.2 TPMS Perfoimanoe and Tuning Page4.5 Scheduler Statistics ^Scheduler VM - lOs - zero if possible -VSIs-zero - Mean Process Time ^Message Type -iOs-take mosttime -VSIs-lceeplow -RESPT ^Avmtype -Time Queue Empty VTPT4040 Page 4.6 TPMS Perfbnnance and Tuning \nPTUNEV1.2 4^^Jnierpreting the statistles 4^.1.S€fiedulerstatistics: 4^^.1.1 Scheduler VM statistics 'No. of messages processed' thetotal number ofmessages processed by theCVM since thelastcaH (or since start ofservice). 'Currentstore occupancy* the mainstore occupancy ofthe CVM at the time of the statistics caR. last call,,^^0by the numberother figuresof finalin replies.this sectionNotearethatcalculatedthe figuresbyaredividingtnjncatedtotrf ratherresourcethanusagerounded.since the 'Mean No. of lOs' itisdesirable thatthis should always t)e zero. User lOs in message analyser and process reply hooks should be avoided. 'Mean VSI rate' ifgood TP perfomiance is required itisessential that theCVM should not incur VSIs toanymeasurable extent 'Mean process time' theaverage OCP usagepermessage in theCVM. This should t)e very low. Atypical figure for a Level 80 would be about 20 miliseconds. Messages spending too much lime in the CVM wH affect the whole service, sodo aslinte processing as possible. 4^^.1.2 Message type statistics For each message type defined in the Service Description: 'Numt}er ofmessages processed' since lastcaN. This wil not include any messages aborted, e.g. bycalling TPAPPUCATIONERRORHANDLEa 'Mean VSI rate' average per message. This should ifpossible be iceptto zero for commonly used message types - at anyrate, keepitas low as possible. 'Mean store occupancy* averagemainstore occupancy per message. 'Mean Na of lOs' average numberof user disctransfers plususer tape transfers per message. 'Mean process time' averageOCPusage (whiein the AVM) per message. 'Mean real time' average time spent inthe AVM. 'MeanTP response time' Theelapsed time from themessage being r^ in the CVM to the reply leaving the CVM. 'Required TP response time' as specified bythe RESPT parameter inthe f\^t\ parameter file, or Z5 seconds bydef^ When different message types are processed by the sameAVMTYPE • particulariy where there isa large VTPTUNEV1.2 TPMS Perfomianoa andTuning Page 4.7 ,f- (^y<^ /^ik^-p ^'/t 'I iju'-^ ^ I (il< S difference intheiraverage response times- itis important to set this accurately as it is used by I , ^-nP TPMS in ordering messages in the queue Ibr the / iyij AVM. Basically, iftwo message types havethe same average AVM service time and one has a lower RESPT specified then messages ofthattype wil tend to get scheduled first If two messages with the same RESPT anrive 'atthe same time' in the CVM, and one takes on average 20 times as long as the other toget processed, the 'slow* message wil bescheduled first Ignoring the RESPT parameter may ensure that anti-social messages always lump to the front of the 'Slow response flag' Indicated by a 4^^.1.3 AVMTYPE statistics 'Average Queue Length' Self-explanatory. 'Maximum Queue Length' Self-explanatory. Time forwhich Queue is empty* If this isa low proportion ofthetime in thesampling period, consider whether thereare enough copies ofthe AVMTYPE. (See notes onAVM utiisation in Chapter 6.) 'Numt)erofconnected VMs' & Indicate numberof copies ofthe AVMTYPE 'Numberofdisconnected VMs' connected and disconnected atthe time of the call. The remaining fields give the same information asin the Message Type statistics but by AVMTYPE 4.2J.2J)e8pond6rStatistics 4.2^.2.1 ResponderVM statistics Performance dataontheCVM as for theScheduler VM statistics which should be near enough the same. 4.2^.2^ MessageType Statistics 'GOOD'TPmessagesresponsewitimesincludeas inanythewhichSchedulerwere aboitedstatisticsinplusthe throughputAVM. The criterionfigures. forNotebekigthatathe'good'total of message issimply that itshould bea legal message with a valid message type which hasnot been mari(ed as unidentified by Message Ancdyser orotheiwise rejected in theCVM. 4.2^.2^ Tenninai Statistics Throughput and performance figures by terminaL Could be useful for Comms sizing. 4^.2.4Screen Fomurt KeyStatistics commonlyThroughputInvoked userfigurescode,bypartnulartyscreen formatin servk»sCould benotusefulusingIntemplatahelping torouting.establish the most 4.23.2.5 Badge Statistics Throughput figures bybadge. VTPTUNEV1.2 TPMS Performance andTuning Page 4.9 c c c c CNI > lU z SCfHLC? 'CI IP SEWHE SSCH GfMr«ATfD at 11:J8 31 90/0*/26 *STI1» PEfflOl 00:B7:W p 44 ♦♦M cci.E6ul£f ¥.1 SUTISTICS .WMK..? DIVlDIt B1 Kimil! Of COIIEIIT RtPlHS SWT) Z lE^'j Nun^r cumtiT irm pccupauct keiin «i mte kean pmcess nrs m, of ress^ces > 4i tr 1-3'; (r.-Bnts) (sec$3 tfAoassEi) '1 455 0 — oo.« m 11:7.3:15 «5 **** : o f* M »» c r CMw5 r*5 ^^c.V .t5^ 55 •«MMOOOV«f »o « « O 9 O O _,--•HK.S r-rf-cijQj^aQ.Qr:^';-'n'^r,•;!?.': s! p??s M gt M M (• M i? <3 OO O ^ ^ m ^ <«VI •>>rf iC :i ^St J1 « w S J* » « M H -« H "9 1! T « M «t I,* •* •* t Tf 1 «« o v» »» one* m•* ^ z4 c I? II» "• •* o u » Cl _ J «MnPI 9 », J2 >* M > o o2 j• o»• •»-t »2'SSSS«'®^S6'tto'"? «. rrr'rr'r'?:\T':; 5:-: JS*'' ^Sn w-*oo ♦ o -e » K • y m A » > o -< M W» _.^£'"!200ooor»oe f- ^••••••••••« ^ 2:j»-»CTS5« 3 9 , J«52oi»2Sm m > M ooooo eoeem o «> o CM «j*o©nooo2S!pS55'^'"' mm ^ » ACV A 1» *W • ^ « e • 2^ " o • ^ -4 » M m 9 > a. e zv I" X MO S2§-M 2 m»a < ' s z « mo r^c • a g > m in o ««:a < ^ f* M m m t^aw Mod oe» o n •» oonooo i 5r,CTr» ^ « M M ^^22" «n . I* O : I o ^ I « o m I » e VI * K* 5 5 » m ^ » c m 9 's^nm » > :* X "* M 3 m M ac « « « *4 I»* 3 • at ^ M m M a m » » • •CO mSo^ « A -4 22 -wawovo o^oey., -<.o Rr,? -> -*eeoo J'sooooooSS'SS>^ a Dip sssM e A Itt > S r « M ^ _ •4-T "wm ^ 5 nt »•M *t-V M a M ?§5 •!» r«« ^ O' • W» «A » w» s:s »Sut «i« : «§- eo«>M<»o^a«k > «• ««• ^ ^ M n •" Ml* «"£«<•»» aO'^eo-A O — wo B M nVM ^ ' Ui X o w * -4 ^ VrFTUNEV1.2 TPMS Performanoe andTuning Page 4.11 4.2^.Di8plays from control mode. It respondar statistics are being colleciad, message throughput and TP response times bv message type can be viewed dynamicallyvia the controlcommands DISPLAYST=MT and DISPLAY ST=TL VTPTUNEV1.2 TPMS Perfomianoe and Tuning Page 4.13 TPSTATS Package »-Chargeable option on 2900s Need Audit Trail k-STARLOGsY ^Produces -Graphs - MMtags Pair Uatlngs - Messaga Taxt Liatlnga VTFT40S0 TPST ANALYSIS tZST OF MS6i RUN: 1990/02/26 10:28:41 START: 24/02/90 15:09:10 END: 24/02/90 15:09:30 IPTZMC TERHNA MS$NA MA QTZME PRTIHC RTINE VSI ns rUNC (SEC) (NSIC) (SEC) mm 15:09:39 0S01 OTUX 10 0.004 93 0.269 0 556 15:09:40 OSOS DTLX 10 O.OOS 69 0.165 0 556 15:09:40 DS01 »TLX 10 0.004 90 0.203 0 556 15:09:42 PS03 DTLX 10 0.004 68 0.182 0 556 15:09:42 0S01 DTLX 10 0.036 92 0.224 0 556 15:09:44 0SOS DTLX 4 0.008 64 0.095 0 556 15:09:44 6 $03 DTLX 10 0.068 66 0.300 0 556 15:09:44 »S01 DTLX 10 0.359 80 0.177 0 556 15:09:44 2CL PXRSTHSe DTLX 4 0.012 956 1.435 5 550 15:09:46 DSOS DTLX 10 0.004 69 0.114 0 556 15:09:46 0S01 DTLX 10 0.012 80 0.194 0 556 15:09:46 0$03 DTLX 10 0.039 68 0.107 0 556 15:09:47 DSOS DTLX 10 0.007 63 0.113 0 556 15:09:48 0SO1 DTLX 10 0.005 88 0.187 0 556 15:09:49 »$03 DTLX 10 0.003 64 0.106 0 556 15:09:49 OSOS DTLX 10 0.006 68 0.113 0 556 Sampte message pairisting fromTPSTATS Page 4.14 TPMS Performanoe and Tuning VTFrUNEV1.2 4.3.TPMS Statistics Package 4.3.1JVvailability Thepackage comes free with theTPMS Oevetopment SetonSeries 39 machines. On 2900s itis a separatelychargeat)le optnn. 4.3i!.What it provides Graphs can be produced showing message throughput. VSI rate, numbers of lOs, response times, queue times and OCP usage. These can cover any specified time perkxj for whfch the Audit file hokJs thedata These can befor all messages orfor a specified AVM. — As In theperiodk: statistics. lO figures report only onuser transfers -so transfers totheCatafogue. journals and the FLF win not show up. Message pair listings can be produced showing the resources used by indivkjual ^ messages. The period covered can beselected andthemessages tobe included canbeselected, for example, on message type orinput termkial. — Mes^ge text listings can begenerated. Note that if LOG^N orLCX3=:U is specified orif tfie optk}nal pcrtches totruncate record types 2and 6 are applied frP4419 at400, TP5368 at405 orTZrr/0006.1 at510) then this facility will not beavaiable. At cun'ent releases, no statistws are avaflablefor the CVM. 4.3^.Collecting the statistics The audit traifacBities must beswitched on and STARLCX3=Y must bespecified in order to generate the type 19 and 20 records used byTPSTATS. Cleariy there issome overhead in writing tfie statistk» to the fog fife and thesize of the audit fae will be increased. 4.3^.Using the statistics If thereisa sporadk: performance degradation in the servtee, theScheduler statistics should indicate roughly the problem area ortime. Their limjtation. however, isthat they show averages over a relativelyfong period of time. Having used them tofind theapproximate time ofthe probtem. TPSTATS canbeused to locate theparticular message(s) causing (or perhaps sufferingi) theproblefa l=br example: terminal users complain that responses were poor during mki-afternoon on the prevfous day. It can beseen from the Scheduler statistics that response times were maricediy higher between 3:00 pm and 3:30 pm. Producing graphs for thatperiod shows thatthere wasa peak in queue times at around 3:15. Amessage pair listmg can then beproduced starting shortly before that time whkii wi perhaps show that onemessage whkii normally takes a second spent several seconds b^processed in anAWfA. This shoukj help tofind thecauseoftheproblem much more qukMy than couM bedone without ttie TPSTATS package. For detaitod description ofhow togenerate thevarious listings, consult TPIUIS Volume VIII (R00465) li4odule 10. VTPTUNE VI .2 TPMS Performance and Tuning Page 4.15 TPBT ANALV8I8 BIMPH OF 0CP/1PTI»« 8TART1 13/09/M 09i00i00 END* 13/09/99 lOiOOiOO SfMPH.HAMEt OCPOOOOl X_8TftRT 09l00i00 X_8CnLEt 1 HINB/COL V_9CnLEi 20 MSEC/LINE ! • 300^ • • • f • 1 « !♦ • aoo-»«« •• • • • !•••• • • 4H» « • • •••• «• • !•••• •• •••• « • 1IMHHN» *1 •••«•««••• ••• I ! I I ••••••••••••••••« O M1N8 0 10 18 SO M 4S SO 53 GO TP8T f^YSZS 8IWPH OF RTI»«/IPT1I« Bim MfWC. RTIMEOOl START. 13/09/89 09t00i00 EM>i 13/09/89 lOtOOiOO RTIMEOOl X_8TART 09t00i00 X_8CALE» I HXNB/OOL V^ORLCi 0.090 8CC/L1NE ! • i.aao* • ^ ••••• •• • •• •••• • •••••• o.9oo4>«*m •• m>ir ••••••••♦• • !•••• •••«••«••••• • •• ••••••«»»« » ••• •• •y!?-*****'******* • • •••••••••••• • •••«•••««•«•• MXNB Page 4.16 TPMS Perfonnanoe andTuning VTPTUNEV1.2 TP9T ANALYSIS 8RAPH OF 10/IPTI* GWVH inoOTWWll STAATi 13/09/89 09t00i00 ENDs 13/09/89 lOtOOiOO XOOOOOOl X_8TflRT 09i00l00 X.SCALEl 1 MINS/COL V.OCMiti eOO lOS/LXHC 3000« 2000-^« «* » !• • • • *1^ !•«•« « ••• •••• ••««« •• •••«• ••••«» !«••• • • •4HHt • •• ••• »♦ , » iooo«-««««««»« •«« • • ♦ ■»■■■■■«♦♦ ••• ' > ? • • • •• 0+- MINS O 3 10ia 20 2a 30 35 *0«S50S560 TPBT ANALV8X8 6iWPH GF NCT/lPTIMe SmWH IMCi ICTOOOOi STARTi 13/09/89 lOiOOtOO CNDl 13/09/89 lliOOiOO X_8T««T lOsOOiOO X.BCALCt 1 HINS/COL V.SCMft ft M80S/L2IC ; ! 90* • : :. • • •• «««« « !• •• •«, •««««« «« « *• SO* •• « •• •• •••«• • • ••• ,»» , •• •• M • ••• ••••»•• **•••—•»»••»<« mm • • • • » •««••••• aaaa ! *•••• •••••♦•• ••••••••••••••••••*»««. BaagBBBW ••••I !•»•««••••••••••••••••••««««««««««, ? 30**»»*»M»»*mmm4Himmmmm»mmmmmmmmmmmmmmmmmmmmmmmmmA ! »••#••»»••• a BBag, .••••••• ••»>—g • • •• ••••#•! • o*-—•* i « « —-«• > MIM8 0 Sl0lSe029 30 394O4S ao SB 60 VTPTUNEV1.2 TPMS Performanoe and Tuning Page4.17 IDMS Statistics RUNTIME stats ICLSiDMSAVMSTATS SMVlMStltltttet ^TRACE options CMSXRUN DMSXDUQ • UTIUSATION stats DMSXDUMP OMSSTDBCOLLECT €T DMSSTDBOtSPLAY VTPT4060 Page 4.18 TPMS Perfonnanoe and Tuning VTFrUNEV1.2 4.4.IDMS Statistics — Runtime statistics. — Trace statistics. — W'lisationstatistics. 4.4.1 .Runtime statistics. '^e'e are 2ways of collecBng runflnw slaBstics> ss'vice doMdown.'®^ K*«>al. These cover the period from statistics for a program or standardisedstort^.ltcanl,ecalWonW^^A^^S^from the start otSe Vm! '=a"s to be 4.42.Traee statistics. 4.4.3.Utili8ation statistics. VTPTUNEVI.2 TDMe« •^MS Perfomnanoe andTunina ^ Page4.19 08:U3::»o SI I9NS20010 I»MS SERVICE STARTED 08:03:59 76 IDIIS10021 UORK UNIT 2 HAS COHFLETE#.JOS :eLS.TPC0NTRO4. 01:00:17 76 IDIIS10021 WORK UNIT 3 HAS CONPLETED.JOB :CLS.TP401CL06SAV 01:00:17 76 tDIIS10021 yORK UNIT 2 HAS eOltPt£T£D,JOO - :CLt.TPAOOCLOCSAV 01:00s17 76 IDNS10021 WORK UNIT 4 HAS COMPLETED.JOS « :CLS.TPA02CL06SAV 01:00:19 76 IDNS10021 tfORK UNIT 5 HAS COMPLETEV.JOO • XCLS.TPAOSCLOGSAV 01:00:29 76 tDNS10021 WORK UNIT 5 HAS CONPLCTED.JOS :CLS.TPeONTROL 01:02:19 76 IDNS16001 TELL REQUEST FROJt USER JOS •"# LOCATION 01:02:19 76 I0NS16002 FOR ACTION "CLSV*# Of TYPE "CVN-. 01*02:19 81 1DMS20012 IDNS CLOSEDOWN CONPLETED 01:02:20 75 01:02x20 n SESVICC STATISTICS FOR CLOOSLIV. 01:02:20 75 ai:02:Z0 75^ 01:07:20 75 SERVICE STARTED ON 90/02/05 AT 08:03:58 Dn02:20 75 CLOSEDOWN ENDED ON 90/02/0« AT 01x02:19 01:02:20 75 APPLICATIONS RUN IN SERVICE 4 01:02:70 75 HAIINUM APPLICATION CONCORMUrr 4 01:02:20 75 SUCCESS UNITS RUN IN SERVICE 15 01:02t^0 75 NAIINUN UPDATtNO CONCURtCNCY 1 01x02:20 75 NAXINUN PA6C LOCK ENTRY USED 32 01:02:20 75 01:02:20 75 ERROR CONDITIONS: ' 01:02:20 75 DEADLOCKS DCTCCTED/DUAL UPDATES 01:02:20 75 SUCCESS UNITS TIMED OUT 01:02r20 75 CONTINCENCIES 01:02:20 75 SUCCESS UNITS ROLLED BACK BY DML REQUEST €I 01:02:20 75 SUCCESS UNITS ROLLED BACK ST SYSTEM 01:02:20 75 SUCCESS UNITS INCOMPLETE AT CLOSEDOWN 01x02:20 75 01:02:20 75 FILES INTRODUCED DURIN6 SERVICE 01:02:^0 75 FILES REROVCD DURINS SESVICC 01:02:20 75 MEDIA FAILURES ON DATABASE PILES 01x02:20 75 MEDIA FAnotCS ON JOURNAL FUCS 31:02:20 75 vls02x20 75 DATAOASe Access DETAILS: 01x02:20 75 PACES: READ WRITTEN REQUESTED 01:02:20 75 DDLDKL 0 0 0 01:02:20 75 AREA-} 0 0 0 01:02:20 75 AREA-1 17 4 21 01:02:20 75 AREA*2 0 01:02:20 7S 01:02:20 75 TOTAL 17 21 01:02:20 75 01:02x20 75 JOURNAL ACCESS DETAILS: 01:02:20 75 BLOCKS BLOCKS AVERA6E 01:02:20 75 READ WRITTEN SPACE USED 01x02x20 75 CBTTESl 01:02:20 75 JOURNAL 552 01x02x20 75 01:02:20 75 CONTENTION STATISTICS: 01:flF?i«y Tf RESERVES stfspni»s 01:02120 75 01:02x20 75 GENERAL SEMAPHORE 15 0 01:02:20 75 FILE INDCR 70 0 01:02x20 75 ARIA LOCK TAtLC 0 30 0 01:02:20 75 AREA LOCK TABLE 1 30 0 01:02x20 75 ASIA LOCK TABLE 2 30 0 01:02:20 75 AREA LOCK TABLE 3 0 0 01:02:20 75 AREA. LOCK TABLE 4 0 0 01:02:20 75 AREA LOCK TABLE 5 0 0 Page 4.20 TPMS Perfbrmanoe and Tuning VTPTUNEV1.2 01:02:20 75 AREA LOCK TABLE 6 0 01:02:20 7S AREA LOCK TABLE 7 0 01:02:20 7$ TP SERVICE TABLE 1J 01:02:20 75 01:02:20 75 KAfiE LOCK TABLE 0 20 01:02:20 75 PACE LOCK TABLE 1 2 11:02:20 75 PACE LOCK TABLE 2 2 U1:02:20 7S PACE LOCK TABLE 3 3 01:02:20 75 PAC« LOCK TABLE 4 1 01:02:20 75 PACE LOCK TABLE 5 0 01:02:20 75 PACE LOCK T48LE 6 2 01:02:20 75 PACE LOCK TABLE 7 0 01:02:20 75 PACE LOCK FREE 2 01:02:20 75 PACE LOCK DEADLOCK 0 01:02:20 75 01:02:20 75 JOURNAL 11 81:02:20 75 01:02:20 75 OIART 21 01:02fZU 75 01:02:20 75 DDLDML 0 01:02120 75 AREA-3 15 01:02:20 75 AREA-1 15 01 i 02: 20 75 AREA-2 15 01:02:20 75 01:02^20 75 PaCE3 17 01:02:20 75 Oft02:20 75 ACCWULATei STATIfTICS fO« COII^LfTf=» AW-ICATIOItS 01:02:20 75 01:02:20 75 01:02:20 75 PA6ES READ fRON OATABASE 17 01t02t2Q 75 FACES MImil TO MTAOm A 01:02:20 75 PACES RERUESTF* BT IBNS 21 fll<02:20 75 LIMfS REBUfSTEO BT IftHS n 01:02:20 75 RECORDS rouilD 57 ftfst»:20 75 RAME OVEIfLOVS 0 01:02:20 75 FRA6MENTS STORED 0 01:02:20 79 RCCOIOS ICLQCATEI 0 01:02:20 75 DftL STATEMENTS EXECUTED 179 01:02:20 75 01:02:20 75 RECORDS STORED BY PIACENENT: 01t022 20 75 TARCET OWRFLOtf 01:02:20 75 CALC 01:02:20 75 fA«E DIRECT 01:02:20 75 VIA 01:02:20 75 DIRECT 01:02:20 75 OitOZtZO 75 SUCCESS UltlTSi 01:02:20 75 RETRIEVAL 11 01:02:20 75 DO.Am 1IFVATE A 01:02:20 75 UPDATE CNON-DELATED) 0 01:02:20 75 01:02:20 75 BUFFER USA8E: 01:02:20 75 MOCS tiAB INTO EUPTT BUFFER 17 01:02:20 75 PACES READ CAUSINC DISCARD 0 ,\j\/r So 01:02:20 75 PACES REAk CAUSINC DATABASE UPDATE 0 01:02:20 75 Vt/K ( 01:02:20 75 CAfS ACCESS BEIAXLS: 01:02:20 75 PACES SCANNED 01:02:20 75 RECOIDS IETI1EV6D 01:02:20 75 01:02:20 75 END OP ttHS SUVICE STATISTICS VrPTUNEV1.2 TPMS Performanoe and Tuning Page 4.21 RECMAN file meters • DESCRIBE_FILE_USAGE • Buffer allocation • Usage when closed • Multlblock transfers • Overflow • Switch on for ALL TP files VTPT4070 Pago 4.22 TPMS Perfbnnanceand Tuning VTPTUNEV1.2 4.5.Rle Meters Sattng METCRS=YES on a call toDESCRIBE_Fll£_USAGE w9l cause infbmiation on buffer allo to be monitoredRte'neteraandshouldallow verificalionalways besotthatontheforoptimumRECMANnumberfiles usedof buffersin TP.isThisallocated.wBI enableFor indexedoverflow sequential ffles, theusage ofmultiblock transfers isjournalised. .uthe data^ is collected® overtiead by VME anyway.in setting the meters on other than writing the information to the journal: 0043 UrLISSEQRl COBRTL.141.07 UNLOCKine poticv im LOCKim """" " US» ^ , X«« .: DflT« BUFFERS FOR KEYED ACCESS a X SOMB MB OVERFLCW AREA . C end of meters ® ® OA™ eTBTlSTICS TO niM .GacoM.»TL.ixivesi»F, BLOCKS read OURINS SCRIM. ACCesS ?Loir«SolSSii?r^ i HULTIPLE BLOCK READ REQUESTS SHORTENED i BLOCKS READ DURtNS INDEX RANGE INSERTION file usiwe CTflWiii ' *— PRIN6w-m^mw-9^ DATA BLOCKSm g NUMBER OF INDEX.BLOCKS , NUMBER OF INDEX LEVELS 1 DERIVED STOTISTICI ' TOTAL TRANSFERS ON FILE (RUN MODS) a TOTAL BLOCKS IN DATA FILE % BLOCKS IN INDEX FILE 2 OVERFLOW COSTi TOTAL TRANSFERS « OVERFLOW COSTi PERCCNTA6E OF PRIME O ^FFER^TIBLOCKEFFIMENCy'fOHEFFICIENCY KE^INDEX ACttSs'*'^*(RUN MODE) uO END OF METERS " VTPTUNEV1.2 TPMS Performance and Tuning Page 4.23 ISt v- ^ \/{^ Itprovidesthe following statistics: USAGE DURING PREVIOUS nn.nn SEC Elapsed timesince previouscallto LUS TIME (MS) or TIME (SEC) OCP usage in miliseconds or seconds VSIS Self-explanatory MSOCC Mainstore occupancyin KB sees RIRO count Self-explanatory l(K-PU) or l(M-PU) or l(B-PLO Number of Primitive Level Instructions obeyed DRUM PAGES Ignore. CUR PAGES Number ofpages (mainstore) occupied at time of call LSUSPENDS Numberof long suspensions FSXFERS Number of fiestore transit. Includes accessesto the catalogue and the FLF. VS DISC PAGES Page transfers assodated with VSIs AVR PAGES Derived MS OCCdivided byelapsed time. Its usefulness for monitDring such processes as DDS Prepares Is evident It can also be used to monitor resource usage off particular messages -either in testing orIn diagnostic mode after implementation - perhaps by calling it prior to the STOP RUN whenever a diagnostic switch has been set(a message would have to be suppled to switch it on and ofl). 4.6.1.GIVE.USAGE (GU^ This oormnand, avaiable with the System Programming Option, supplies simiar resource information,usage datatooutputLUS,onlybut returnsselectedtheItemsvaluesor pertbrmtoa rowcalculattonsofintegers. onThistheaBowsvaluestheanduseroutputtorefonroiderivedthe figures. It is documented in the System Programming manual (^159). VTPTUNEV1.2 TPMS Perfonmance andTuning Page 4.25 4.7.SYSTEM MONITOR The System Monitor output displays average resource usage in the sample period by VME Policy. It shows a numt)er ofthings notseen from anyTPMS statistics: — The tot^ performance picture across the whole machine. Do not consider the TP service in isolation. If MAC starts doing massive numbers ofVSIs then theTP service will feel the effect The rest of the machine workload will certainly be affacted by theTPservice's resource usage. — VSIs mthe Production TP Policy's SharedQuota — Utiisation of disc drives and oontroHera POLICY DETAILS POLICY -> MOP BATCH NAG TP 8/j MICP UTIL OPA 8/T8K s.ai8 o.o(» a.033 CME TOTAL 0.06B o TOTAL H3 OCC 430 1 4.789 8.948 18.00 78 3 VMS IM MB 3.000 0.011 119 799 8398 3791 0. ISO 0.018 TOTAL V8I/SEC 0.005 0. 1.000 4. 188 l.OOO 9.268 000 0.384 0.084 TOTAL VMS 0 1.674 0 O o O £.089 QUOTA/MB VN O o 0 0 o 0 0 0 acC/N8 VN o 0 0 143 170 653 0 0 - esB 119 184 ROY VMS IN MB 0 0 0 8358 404 OTA/ROY NB VN o 0 0 O o 0 0 0 • ROY Q'O VMB o 0 0 0 0 0 o 0 0 0 OTA/RDY a«0 VN O o 0 0 0 0 o TOTAL SHO OTA 0 0 0 0 0 0 0 TOTAL SHD OCC 0 0 0 O o 0 0 O . LOC VSIS/8EC o 0 O 0 0 0 0 O o 0 SHD VS18/8EC 0 o O 0 O o o o 0 o 0 PUB V8IS/8EC 0 o 0 o 0 R1R0/8EC o 0 0 0 0 0 o 0 0 o 0 *•• END OF PCM.ICY 0CTAIL8 ••• ^ END OF BYBTCN PCAFGRMINCE DETAILS ,9 6a OIBC DAIVE AND CaNTROLLER DETAILS ••• IWUBY XFCR CTRL/DRIVK VOLUME DEV CHAN CAF8 /BEC -*BU8Y- XFER HDIO/ CTRL/0III5C VOLUNE DEV CHAN CAFB /SEC l.fiS O 3.79 HD40/ FOlO ICLEBO «.3B 0.S7 O 0.9B FIM4 FDll ICLCIO 3.4t 0.47 O e.OC F6400t 1.79 0.49 O 0.98 F018 ICLEaO 0.49 0.09 O 0.87 P014 ^08014 0.00 0.00 OO FD19 Foeois 0.84 0.09 O O.St DRIVE AND CONTROLLER DCTAILB ••• END OP 8Y8TEN PERFORNANCE DETAILS ••• VrPTUNEV1.2 TPMS Performance and Tuning Page 4.27 other Performance tools COBOL.PATH.AIIALYSIS -Program analyslt and tuning -Tasting »>PR0GRAM.ACT1VITY.SAMPLER -Tuning collaetlons c - No ovartiaad In oompllad OMF VrPT4090 Page4^ TPMSPerformanceand Tuning VTPTUNEV1,2 4.8.COBOL_PATH_ANALYSIS (COBPA) ®PfOflfani bycalling COBDIAGCPAT^YES) prior to cainng Se^F "***• ®*'™' '"®0™>slic code to be included In Histograms showing the number of times specified modules, paragraphs or lines have been Will bewritten toa pre-created file identified on thecaH toCOBDIAG. », . Envfronment Simulator (TPES) rather than with TPMS. Be aware to COBCMG hM bem made. If(»«*'"<»<'this Is notPOfwhateachis required,executionand to avoidofthethe limitM0DU1£on thewhennumbertheofcall s^^1^ can be written within one SCL block, the developer should not caB COBDIAG at nm time un« the last message isto be sent TPES. Abreal<-ln can then be done and the can made. This will wnte just one set of diagnostic data covering the whole session, rather than aset for each message. / DO NOT RUN CODE WHtcai HAS BEgM ftftUPll cnimtm da-tu «u.. QNIMAUVETPmSEffi^TTiereisaS.^^^^^ module produced (increased by somewhere mthe region of 50%) and in extra OCP usage at nin time. COBOL Path Analysis iscovered in much greater detal on the VME Optimisation for Application Programmers course (VOAP). VTP7UNEV1.2 TPMS Performance andTwilng Page 4.29 ^ 4.9.PROGRAM_ACTIVrTY_SAMPLER (PAS) ^ establish the frequency with which different areas of OMF modules are xD».o ^ ^ ^ COBPA, it can also tje used fairiy easily in a tT,P^^« ^ 's no overhead in either switched1 u on. module produced atcompilation time or in running the program without PAS irrterru^ the TP VMs in which it has lieen^switched on at every ®samplingproductioninteival.TPsenrice.It the samplingbecause itwill inte^ f ®®| ssy-1000 (microseconds) then the increase in CXJP used and TP Response times Will be ofratherimpressive proportions. Example of using PAS inTPES BEGIN LDM(TPMSES) LDM(modulename) PAS_START(10000) TPMSES(„screenm^. PAS STOP PAS_SUMMARY If using it in a TPMS environment, SCL hooks called on receipt of first and last messages can be used to do the calls for AVMs. To trace CVM user hooks, the DBSTART and DBCLOSE hooks can be used tomake the PAS calls. Program Activity Sampler isalso covered in much greater detai on theVOAP course. The Collector workshop also provkies guktance on using COBPA and PAS totune cdlectton. VTPTUNEVI.2 TPMS Perfofmance and TuNng Page4.31 output from PA8_0Z8PLAV OXSTRXBUTZON OF COUNTS fiV ODORESS IN OTLTPFE (CODE COUNTS) ZIN 1 BY PROG NAME ZZN SCALE « « 13 COUNTS DTLTPFE A«CONTRaL B«TIMER«TA6K 88«8PaaLER«0UTPUT 3 8W«WR1TE«RECX]RD TT»ZN1T«NUNERIC8 «H»TLTPFE XINl Bvass BYTE BC«tH .. .3 C««T8 o 3**mhhhhhhhhmi* 2=6 100 sia aoo 76a 300 ]••• 1024 400 laso 500 3 "WWWWWWWWWW OUTPUT FROM N)B_OZSPLAY.AREA DISTRIBUTZON OF COUNTS BV ADDRESS IN DTLTPFE UN 1 BV 38 BYTE Sampto output from Program Activity Sampler VTPTUNEVI^ TPMSPerfomianceand Tuning Page 4.33 4.10.VME Capacity Management System (VCMS) Release 50 ofVCMS Includes a newoption, namedTuning. Itoffers many facilities ofinterest to the TPMS performance specialist. The VCMS 50 Tuning Option gives facilities in two areas — Real Time Monitoring. — Expert System Analysis. The RealTime Monitoring runs on any IBM compatible (such as the ICL DRS M30 - M80 range) under MSDOS, viaan ADI link to VME. Itwill allow the userto monitor general system performance. The Expert System runs inMAC and will examine workmix settings, COMMS buffer settings and usage as well as overall systemperformance. The results ofthe analysis are displayed, followed by advk:e on how to cure any problems found. At the nextrelease ofVCMS, l)oth the RealTime Monitoring and the Expert System Analysis will be extendedto coverTPMS and IDMS. Statistics forAVMs and message types can then be examined. VTPTUNEV2.0 TPMS Performanceand Tuning Page 4.35 Tuning Statistics -TPMS sampling 30 minute - RIe meters for RECMAN (DSRJ) -IDMS AVM stats - IDMS utilisation stats GDMS_ST_DB_COLLECT) -TPMS parameterfile -SMON - LUS for AVM (Rrst/Last mesages) VTPT6000 Page 4.36 TPMS Performance and Tuning VTPTUNEV2.0 4.11.Suggested set of statistics Section 1 outlined the basicmethod ofapproaching tuning a TPMS system. Before wecan tune a system we must first establish a base line. This base line consists of set of statistics which monitor the performance oftheTPMS service andthe restofthe VME system. It isimportant thatthe rest ofthe system is monitored as tuning the TPMSservice may well affectMAC or BATCH services on the machine. A suggested set of statistics would be TPMS statistics sampling every 30 minutes. RIe meters for all RECMAN files (via DSFU). IDMS AVM statistics. IDMS utilisation statisticsvia IDMS_ST_DB_COLLECT. TPMS parameter file listing ~ System monitor output UST_USAGE foreach AVM on first/last messages or accountinginformation from the journals. The statistics could be collected on the live service but there are other methods. The terminal simulator input file could be used to provide a standard test script. Thiscouldbe particularly useful when testing changes to code or specific aspects of the service. NETSIM could also be used to provide standard TPMSruns. Ineither case the inputto the system must adequately reflectthe nor mal range of messages that are processed. Thisset ofstatisticsshouldbe collected overat least a week, probably a month depending on the natureofthe business that the servicesupports. Donotforget the effectsofany month-end processing that goes through the system. VTPTUNEV2.0 TPMS PerfbrmarK»and Timing Page 4.37 5. Service l\/lanagement VTPTUNE V2.0 TPMS Performance and Tuning Page 5.1 Service Management •DDS PREPARES •TP RESTARTS ^TP initialisation ^Terminal connection •JOURNAL HANDLING VTPT5010 Page 5.2 TPMS Performance and Tuning VTPTUNEV2.0 5.1.Introduction An increasing number ofTPMS users require to run their services as near as possible to continuously. When either TPMS orVME breaks orhasto be taken down (perhaps to implement changes) this lossoftheTPfacilities may have a serious impact onthebusiness. Partk:ularly onlarge TP systems, with large networks, the time taken to restore the TP facilities has sometimes been a problem. More generally, nobody wantstheirservk:e to take a long timeto start up if itcan be madeto take a shorter time. Partly because of problems withhavingto close VMsor services because of journal libraries filling, and partly because ofdiffrculty in 'seeingthe wood for thetrees' inTPjournals, there is also a need to controlthe potentially vast printout produced byTP services. Thissectionincludes manyideas forwaysofspeeding upTP restarts. Itis notsuggested that every site should implement allofthese changes; some ofthem are neitherstraightforward norfree of possibleimplications. If restart times are nota problem, there is no pointinexpending timeand effort to effect £in unnoticeable improvement. Where restart times are a problem, consider whichof ofthe changes would be suitableforthe site's circumstancesand, as with any other changes, make the changes one at at timeina controlled manner (ensuring that they can be regressed ifnecessary) and assess the impact of each change before proceeding to the next. 5.1.1 .The areas to consider are — the time taken to generate the components of the service, particularly the pre-processed module (PMOD). — the time taken to start up the service. — joumal space used by TPMS and how to control it The first is an issue only when the DDS model is used; the time to startthe servrce can be sub-divided into the time taken to initialise ail the TP VMs and the time taken to connectthe network; the third area can be dividedintocontrolling output to the joumal and managing the disc space and printing of journals. ION B/133 (see Appendix B)made a number of recommendations for improving restart times. This section contains several additionalsuggestions and assumes a f^iliarity withthe contents of the ION, referringto it onlywhere update or amplification is required. VTPTUNEV2.0 TPMS Performance and Tuning Page 5.3 TPMS PPS >• Allows changes to printers and terminals Amends the PMOD directly Quick TEMPORARY fix! VTPTS020 DDS Prepares Job quota ^DB biocksize »>Number of buffers Patches •^Run In BATCH VTPTS02S Page 5.4 TPMS Performance and Tuning VTPTUNEV2.0 5.2.DDS Prepares. 5.2.1 .TPMS_PREPARE_PACKAGED_SERVICE (TPMSPPS). If theservice description hastobechanged only to make changes toterminal orprinter entries, consider the use ofTPMSPPS. It isvery much quicker thana prepare from DOS. 5.2.2.PREPARETP-SERVICE. It iswell-known thatgenerating a PMOD from the DDS model takesa greatdeal longer than generating one froma parameter file. This is basicallybecause ithas lar more workto do. In attempting to speed up the process the approach is to — reduce the amount of work to be done. — increase the resources available to do it in. Increasing the resources means giving the jobmore main store. Prepares shouldalways be done using a jobquotasubstantially higher thanthe def^lt quotasfor MAC or BATCH. Experiment to find a quota suitable for your circumstances, but at least 400 to 600 KBis recommended and there will probably be a benefit in increasing itstill further. Increasingthe blocksize ofthe dictionary file maywell speed up prepares. A blocksizeof 6KB is probably suitable. Applicationof the optional patch TP4451 (forTPMS 400) will eliminate checks on all screens for a valid system reply area which are otherwise made both in PRE TSE and in PRE APP. TP5324 should be appliedifyou are usingTPMS405, as itdramatically reduces the size ofthe pre-processed module produced from dictionary prepares. Increasing the number of database buffers used on the dictionaryshould reduce the number offilestore transfers giving a saving in prepare times, butthe lawof diminishing returns applies and there comes a pointat whichextra buffersgive no improvement in performance.As with larger blocksizes, remember that having more buffers means using more (locked) mainstore to accommodate them. Ifyou have larger buffers and more ofthem withoutsupplyingthe additional mainstore to accommodate them, you will probablyreduce filestoretransfers at the expense of incurring more VSIs. The following example illustrates what can be done. The results were achieved on SV290 and TPMS 405, all prepares being done in BATCH. RUN NO 1 2 3 4 5 6 7 BLOCK- 2KB 2KB 6KB 6KB 6KB 6KB 6KB SIZE BUFFERS default 15 8 10 15 18 24 USED M-PLI 238.2 232.8 221.4 223.9 224.0 224.0 224.0 FS-XFERS 17310 13301 10468 10454 9804 9653 9344 VTPTUNEV2,0 TPMS Perfomnance and Tuning Page 5.5 PREpare Application Dummy Application I Dummy Tasic I ALL screens VTPT5030 Page 5.6 TPMS Pefformance and Tuning VTPTUNEV2.0 Elapsed times &VSIs will vary quite widely from run to rtin dependent nn what isrunning nn the machine. Thev will also vary deoendina on the machine used, as will QCPtime: therefore nnly the PLI and F/S tranirfers are monitored. Somefurther Improvement is possible through application ofpatches. Application ofTP5324, and ISDA220004 (see below) will reduce iOs and OOP. Afurther word ofwarning onlarger blocksizes: where other usersareaccessing the dictionary concurrently, the fact that more records areon each page could make it more likely that page-locking will give contention problems. 5.2.3.PREPARE APPUCATION. Aswith PREPARE TP-SERVICE, increasing the Dictionary blocksize, the jobquotaandthe number of buffers will be beneficial. Thegeneration ofthe screentemplate modules will be very much quicker if a dunvny dialogue or task is associated withthe applicationand ailscreens are declared on that and on no other dialogue or task. AtTPMS 405,TP5363eliminates the checks (as forTP4451 at TPMS400) in PREAPP- at 405 these checks are not done on PRE TSE. As such, it should be used with caution. The patch ISDA220004 improves access to screens in PRE APP and in PRETSE. The improvement effectedis proportional to the numberofscreens beingprocessed. All prepares from the dictionary shouldbe done inbatch as a RUN_jJOB, as ifthe call to DDS is made directly from MAC oras a RUN__INTERACTIVE_JOB, there are a significant number of additional DML calls and consequently disc transfers. IfBATCH is affected by RIRO, be aware that jobs with largerstore quotas mayfind itharder to get back into mainstorel VTPTUNEV2.0 TPMS Performance and Tuning Page 5.7 starting TP VIMs quicldy •SeelONB/133 •VME Checkpointing Checkpoint skeleton VMS POSSIBLE to checkpoint code - BUT BEWARE! VTPTS040 Page 5.8 TPMS Perfomnanceand Tuning VTPTUNEV2.0 5.3.Making the TP VMs available on service start 5.3.1 .Checkpointing. Ifthe restart has been made necessary because of a break in VME, the first task will be to restart VME itself. Checkpoint loads should be used because they are muchquicker than full reloads. Ifthe Work Scheduling Option Is available, the time taken to create the TP VMs can be saved by checkpointing 'skeleton' TP VMs: CHANGE_WORKMIX(POOL=TPAVM/x&TPCVM/y&TPSPLR/z,ACT=CHECKPOiNT) Furthersavings COULD be made bycreatingVM initialisation hooksto pre-load the TPMS (and IDMS) software. Thiswill require the RSI option to call PRELOAD_MODULE. The following isa suggested list of modules suitable for pre-loading: TP CVM INFT TP AVM INIT TP SPLR mix ICL9TXCM0DSPLR ICL9TXBTPSECM asforTPAVM ICL9TXACR10SPLR ICL9TXAM0D ICL9TXTHCVM ICL9TXBTPINIT exclude IDMS ICL9TXCM0D ICL9TXI0MSH00K add ICL9TXSPLR ICL9TXBTPINIT ICLSTXTPMSTEXr ICLSTXaaaBTPVMS ICLyTXAMOUSPLR ICL9TPMSTEXr iCL=jrxAcnicsrLRi ICL9TXTHTtXT ICLSIDMXl'bb ICL&IDMSnXP ICLDIUfyJXCOMMSUPP ICLSIDMXtibb ICLaiDSUPPfJTTM ICL9TXBDTS ICL9TXPHAN01 where aaa is the version of TPMS software being used (400,405 or 510) and bbb is the version of IDMS in use (400 or 510). [ - Don'tincludeifTP services don't use IDMS '"7 " Don't includeifTP Spooler not being used jjjjjH Don't include if DTS Is not being used VTPTUNEV2.0 TPMS Performance and Tuning Page 5.9 Series 39 sites - an alternative approach - Mark all code as global (pre-SV290) - Collect the code - Load code in batch job - Load PMOD & ICL code - Batch job must long suspend (RSI option) VTPT504S Page 5.10 TPMS Perfomnance and Tuning VTPTUNEV2.0 The Work Scheduling Option is neededto changethe tasks to pick upthe procedures, e.g. CHANGE_SUPPORT_TASK(TPCVM,USERJNlT_PROC=TPCVMINrT) Whilethere seems no reason for not checkpointingskeleton VMs, it must be stressed that there are potential drawbacks incheckpointing the VMs containing TP &IDMS code as above: — If any patches are applied to the TPMS (orIDMS) modules, itwill be necessary eitherto abandon allthe TP VMs or reduce the concurrencies ofthe poolsto zero and back to theircorrect levels using CHANGE_WORKMIX (Work Scheduling Option required) before reloading the TP service(s) inorderto pick up the changes. A newsystem checkpointwould be needed to pk:k up the changes in subsequent checkpoint reloads. — Itwill not be possibleto runtwoversionsofthe softwareinthe TP profile by changing the ICLSNTPJOINIT hook, as the software will already be loaded. Itwill however still be possible to run different versions inTPDEV(assuming the same procedure has not been followed for TPDEVCVM &TPDEVAVM). This approach could be taken stillfurther by pre-loading the applteation code and even the PMOD inthe VM initialisation hooks - withstill more potential problems and disadvantages. While some sites may feel that this is suitable for their environment since the code is very statk:, and that they will handle the complications, itseems too inflexible in general. Inpartrcular, when the apprication 0 code has been pre-loaded, a recycle of an AVM will not pick up a new generation of a module, whk:h might be unacceptable for many sites. \ 5.3.2.A Better Alternative for Series 39sites. The general recommendation for Series 39 users with a requirement to shorten TP initialisation times is to checkpoint the skeleton VMs and load all the code from a SERVICELIBRARY in a batch job prior to starting the TP servrces. This would be done as follows: — Mark all the applk:ation code as global, whether it is shared or not (only necessary pre-SV290). — Re-collect the code (SV221 Collector or later). — Load the code in a batch job charging itto the Poltoy 4 PSQ: STLD0PT(CHARGE=P0UCY/4) LOADMODULE( ) — Load the TPMS and IDMS software and the PMOD(s) in the same batch job. — The batch job must long suspend. Ifthis approach is taken, bear in mind the implications for prcking up amended versions of software. If a change is made to a module and the new module hasthe same generation number as one already globally loaded (which willbe true if patches are applied using SNAP, for example) then it will be necessary to end the batch job and start it again as well as closing all the TP servk:esto ensure that the amended software is pk:ked up. Sites on SV212 will not be able to benefit from this strategy because the 'new* Loader,is not available to them to speed up global loading. These sites may wish to considerthe approach of pre-loading in VM User initialisation procedures as above as an alternative. VTPTUNE V2.0 TPMS Perfomiance andTuning Page 5.11 Parameter file fields affecting startup times •SQUOTA NEVER less than RQUOTAI • MAXPRI & MINPRI ALWAYS setto 1 • AVMTIME SufficientforAVM to start -AVMMIN Affects orderin which AVMs are started VTPT5050 Page 5.12 TPMS Performance and Tuning VTPTUNEV2.0 5.3.3.COBOL run-time code. As the COBOL run-time library softwareis not pubiically loadedforTPMS,the SITEJNITIALISE_SYS7EM canbe extended to give a small improvement byincluding PREPARECOBOLC2(AVM,DOI^AIN=PUBUC) 5.3.4.Load the code more quickly. ION B133suggests usingan OMF blocksize largerthan 2KB. Ifyoutake advantage of blocksizes greater than 6KBat SV231, you need to applythe following repairs: — BU1/111 — BI71/114 — Biyi/120 As ever, make sure you check on the current Repair Status Report first. From SV291, multiblock transfers are used for Loader - the default buffer used is 25KB instead of 2KB. This gives a tremendous improvement in load times for large modules and means that the action recommended in the iON is unnecessary from that release onwards. 5.3.5.Load less code. Neither the TPMS 400 code nor the TPMS 405 code as issued was collected with the appropriate Collector, so the modules from either version can be re-collected to improve load times. (Series 39 sites only). 5.3.6.Parameterfile settings. 5.3.6.1.SQUOTA The default for the SQUOTA parameter on the AVMTYPE record is only 250 KB. It makes no sense whatsoever to give an RQUOTA of, say, 750 KB and then allow the SQUOTA to default - giving the VM the least resources when it hasthe greatest need. SQUOTA should NEVER be less than RQUOTA and in the context of trying to startthe service as quickly as possible, it has sometimes been found beneficial to set SQUOTA to RQUOTA + 25%. In many cases, however the only effect this will have is an adverse one on the rest of the machine workload! The same applies to the CVM,for whk:h the SQUOTA parameter is on the RUN_TPMS command. 5.3.6.2.MAXPRI & MINPRI These parameters provide the means, within TPMS, of downgrading the OOP priority of AVMs. Refer to the IONfor an explanation of the benefit of doing this. Sites on TPMS 400 should apply TP4410 to allow the use of MINPRI and MAXPRI. From the next release of TPMS alter 510, the default for MINPRI and MAXPRI is changed to 1. VTPTUNEV2.0 TPMS Perfbmrance andTuning Page 5.13 Page5.14 TPMS Performance andTuning VTPTUNE V2.0 5.3.6.3JVVMnME. This specifies the time which an AVM will be allowed in which to initialise itself. When the CVM initiates thestartup ofan AVM itwaits uptoAVMTIME for theAVM tosendan event indicating that itis initialised and ready forwork. IfAVMTIME expires before this event is received,the CVM sends an event to the AVM to time out and the AVM failswith a ProgramError 43/07. The AVM thendumps, which clearly harmsthechances ofstarting the servk:e quickly. Ifthe AVM fails during the early stages of initialisation, itwill be frozen until AVMTIME expires. This can happen ifthe VM tries to connect to a mandatoryfile which is not availablefor some reason. /.O \yP Sit, "5 V S The recommendation is to setAVMTIME sufficiently highthat the AVM has ample t'me to initialise, and to avoidthe lattersituation by ensuring that the files are always available at service start 5.3.6.4J\VMMIN. The RUNJTPMS command starts onlythe CVM. The starting ofthe AVMs is initiated by the CVM. in all currentiysupported versions ofTPMS itwill start the AVMs inthe following sequence: — The first copy of all AVMTYPEs with AVMMIN > 0. — Subsequentcopies of all AVMTYPEs with AVMMAX > 1. — Copies of all AVMTVPEs with AVMMIN = 0. This is done serially. Armed withthis knowledge, it makes sense ifthe early availabilityof some AVMsis more important than that of othersto arrange the settings of AVMMIN so that critical AVMsget started first and do not have to compete for resources with non-criticalAVMswhile initialising. This could be implemented by setting AVMMIN = 0 on non-critical AVMs and automatically inputting control commands to startthem via a terminal simulator input file. 5.3.7.Balancethe disctraffic During initialisation of the service, disc transfers willbe done to access the following: Catalogue TPMS software ^ TPMSSlotfile(s) IDMS software IDMS subschema Application code PMOD Screentemplate modules. Secondary storage sites. System monitor output should be checked to ensure that there is no bottleneck either on disc drives or controllers and the appropriate action taken. For example, ifTPMS & IDMS software and the site's applk:ation code are on the same disc drive, and the SYSMON output indk:ates contention on that drive, spread the code over more than one drive. Itwillbe known that the distribution is right when there is no longer contention. VTPTUNE V2.0 TPMS Performance and Tuning Page 5.15 Page 5.16 TPMS Performance and Tuning VTPTUNE V2.0 5.3.8.0therconsiderations. if you dont need it^ don't load it Ensure that no code is loaded unnecessarily. In particular — DONT specify DOCPHASE >0 onan AVM which does notuse spooler. Itwill cause the AVM to load the Spooler code. — DO switch on loadertracing to establish whether youare loading code unnecessarily. Don'tinvoke recovery unnecessarily Ifyou use warm starts (CONTINUE=Y), ensure that the previous TP session has been closed tidily, as this will avoid invoking recovery - i.e., use FNTPMS(....,TYPE=NORMAL) or FNTPMS( TYPE=USER). ^ ^ -TO ^00'P r If the call to RUNJTPMS is preceded by calls creating new system files -eg ' TPMS_NEW__SLOT_FILE before a cold start,don'tmakethe systemfiles larger than they needto be. Each extra block will cause 2 additional disc transfers and use extra mill. VTPTUNE V2.0 TPMS Performance and Tuning Page 5.17 Connecting to TP dOUTCON=Y? Extends TPstartup time o RSCON=Y? Do you really want the defaultaction? Cataloguing Connect TPonly terminals directly to the TPMS service VTPT5055 Connecting the networic >>See ION B/133 •NTCR&SCT - Long suspends - Quota - CATHAN slaves • NTCR - HM hashing algorithm •SCT -ACCEPT CONTROL VTPTS060 Page 5.18 TPMSPerformanceand Tuning VTPTUNEV2.0 5.4.Connecting the network. 5.4.1 .Connection to TP. Avoid OUTCON=YES as itinvolves unnecessarywork and mostTP services are usually started up before the terminals are switched on anyway The RSCON parameter specifies whether terminals connected toTP during the previous sessionshould be automatically reconnected on a restart - the default being YES. Thereare many cases where this is not particularly sensible: for exampleforTPMSXEsessions and in most cases for OSLAN connectedterminals. TPI\/IS will attemptto outwardly connectto the terminals and itwill fail, so once again, this simply extends the startup time. TP only terminals should preferably be cataloguedto connect directly to the TP service. 5.4.2.NTCR and SCT performance. IONB133 advises on improvingthe performance of NTCR and SCT in three areas: — Preventing the tasksfrom long suspending. — Increasing the store quotas used. — Providing more buffers for catalogue accesses to reduce lOs. AtSV290 and later, the quota, number ofCATHAN slave buffers and long/short suspension policy are all controlled by parameter settings to the command CHANGE_NETWORK_CONTROLLER_TASK As stated above, terminalconnection will proceed more quickly ifterminalsconnect directly to the TP service without going via SCT - note thatTPMS- XE does use SCT. IfSCT has to be used, sites on SV212+ PMT1 should applythe following repairs: SN/A/0096(increases no. of CATHAN buffers) SN/A/0166(stops SCT from long suspending) SN/A/0167(stops ACCEPTCONTROL from being sent) FOR THF CORRFrTVERSIONS OF ALL REPAIRS MENTIONED IN THIS SECTION CONSULTTHE CURRENT REPAIR STATUS REPORT. VTPTUNE V2.0 TPMS Performanceand Tuning Page 5.19 Catalogue contention >-Use mainstore to reduce lOs o Public slaves o Local slaves Duplex catalogue? >-l^st resort: split catalogue oSee ION B/133 VTPTS070 Page 5.20 TPMS Performance andTuning VTPTUNEV2.0 /^\ 5.5.Cataloguecontention. Both phases oftheTP start-up process (Initialising theVMs and connecting theterminals) can be hampered by contention forthe catalogue disc. To improveTP initialisation times and terminalconnection rates, use can be made of mainstore to reduce the number ofcatalogue lOs. Provided the main store isavailable, we recommend thatthe number oflocal and public slavesbe increased. This isdone bychanging thetwo steeringfile itemsSI_CH_NUMBER_OF_PUBLIC_SLAVES and SLCH_NUMBER_OF_LOCAL_SLAVES. The defaults are6 for local slaves and zero for public slaves andwesuggest setting 12local slaves and (for a Level 80) 400 plus 100 per node for public slaves. Each extra slave will require 2KB of (unlocked) mainstore which will be incurred for every VM In thecaseoflocal slaves andcharged to theSystem Quota for public slaves. The Workmix task will increase theSystem Quota automatfcally. Increasing the local and public slavesas abovemay well eliminate problems with catalogue accesses. If itdoes not, thenconsider duplexing the catalogue (only available at SV290 and later) and, only if there isstill a problem having doneboth these things, as a lastresort split the catalogue as discussed in ION B133. See VME TIPS 7.4orVME System Performance for further information on improving Catalogue access. VTPTUNEV2.0 TPMSPertbmianceand Tuning Page 5.21 Journal Handling Cyclic journal + XL option -canreduce amount journalisedby CVM Avoid automatic listing of journals - Use SCL procedures V - Separate TPjournal libraries - DELETEUSTFILE VTPTSOaO Page 5.22 TPMS Perfomiance and Tuning VTPTUNEV2.0 5.6.TPMS journal management 5.6.1 .TPMS Cyclic journal. Since release 405 it hasbeen possible tousea cyclic journal file towhich diagnostic tracing doneviathe testswitch isautomatically diverted from the TPCONTROL journal. It is possible using theTPMS/XL option tochange the mapping ofmessagesoutput fom TPMS to route them tothe cyclic journal instead ofthejob journal. This isa lengthy process covered in chapter 4 oftheTPMS XL Option manual (R30168). The^cility allows you toredirect messages by changing the standardTPMS textmodule andspecifying the destination as the cyclic file. Messages can also be routedto the OPER. Using thisfacility requirescareful thoughtabout which messages to redirect, butcan produce considerable savingsinjournal space used. Note - thisfacility only relatesto the CVM journal. Problems with AVM journals can be overcome byrecycling the AVM. The next section alsocoverswaysofchanging the journal library used and stopping the automatic listings of joumals. 5.6.2.TPMS journal library management Many people findthat TPMS journals do not always need to be listed. On a stable service the joumalscan be leftina library to be browsedifnecessciry. The following providesa means of changing the library inwhich TPMS creates its journals and stopping TPMS listing the joumals. The joumals are leftin the library where they can be subsequently deleted or listed,and are still available forproviding diagnostic evidence ofanyfaults inthe service. The SOL procedures havebeen fully tested at versions 400 and 405 but not at TPMS 510. Carefulthought needs to be givento sizingthe partition or controllling file inwhich these libraries are placed to ensure that they do not become full. The patches instep 1 must be appliedbefore steps 2 to 4 are attempted. Steps 2 and 3 belowredirect the TPMS journals to a newlibrary - TPJOURNALUB. Step 4 cancels the list requests generated for TPMS for its journals. 5.6.1 APPLY patches:- FORTPMS405 - TP5215 &TP5265 FOR TPMS 400 - TP4454/3 FOR TPMS 510 - TP/r/0005.1 5.6.2 Create a library asfollows lNTRLB(tpjoumallib,DESC=*STDJOURNAL) CLBP(tpjoumallib,F,:MASTER) CLBP(tpjoumallib,F,:SYST01) } iSYSTEM on 2900 CLBP(tpjournallib,F,:SYST02) } rSYSTEZ on 2900 Create an ICL9NTPJ0INrT hook in the TPMS service user INPUTFILE(*SRC.ICL9NTPJ0IN1T) PROC ICL9NTPJ0INrT IS 0 PROCBEGIN USEUBRARY(tpjournallib,SEARCHKEYS=ICUOURNAL) PROCEND C0MPILESCL(*SRC.ICL9NTPJ0IN1T,SERVICEUBRARY) Ifyou already have an ICL9NTPJ0INrr procedure then ttie USEUBRARYshould be incorporated into it VTPTUNEV2.0 TPMS Performance andTuning Page 5.23 Page 5.24 TPMS Performance and Tuning VrPTUNEV2.0 5.6.3.Create the following hooks for your TPMS service. IN PUTFILE(*SRC.tpservk:enameCPARAMS) PROC tpservicenameCPARAMS IS 0 PROCBEGIN DELETELISTFILE(*ICL9TPJ0URNAL) PROCEND CSCL(*SRC.tpservk:enameCPARAMS,SERVICEUBRARY) INPLrTFILE(*SRC.tpservk:enanieSCL1 NA) PROC tpservicenameSCLINA IS Q PROCBEGIN DELETELISTFILE(*ICL9TPJ0URNAL) PROCEND CSCL(*SRC.tpservicenameSCL1NA,SERVICELIBRARY) IN PUTFILE(*SRC.tpservfcenameSCL2NA) PROC tpservlcenanrieSCL2NA IS 0 PROCBEGIN DELETELISTFILE(*ICL9TPJ0URNAL) PROCEND CSCL(*SRC.tpservicenameSCL2NA,SERVICELIBRARY) ifthese procedures are already inuse,then the DELETEUSTFILE maybe included inyour existing procedures. You then need to change yourTPMS servk:eparametersto include these hooks. 5.6.4.For TPMS services defined by a parameterfile Change the CTRLDAT record to include CPARAMS=tpservk:enameCPARAMS, Change each AVMTYPE record to include SCL1 NA=tpservk:enameSCL1 NA, SCL2NA=tpsen/k:enameSCL2NA, 5.6.5.For services defined in a Data Dictionary Change theTSE element to include *CVM-HOOKS CVM START tpservicenameCPARAMS Change each AVMelement to include *HOOKS FIRST STAGE tpservfcenameSCLI NA SECON D STAGE tpservicename SCL2NA The TPMS service will now need to be reprepared. The library containing the journalscan then be tidied after the services usingttie Ibrary have VTPTUNE V2.0 TPMS Performance andTuning Page 5.26 Page 5.26 TPMS Peiformance and Tuning VTPTUNE V2.0 \ .. been closed. ItIs possible to create separate libraries foreach TPMS serviceifrequired as thiswould simplify nnalntenance on the library. VTPTUNE V2.0 TPMS Peiformance and Tuning Page 5.27 Page 5.28 TPMS Performance and Tuning VTPTUNE V2.0 6. Tuning VTPTUNE V2.0 TPMSPerformanceand Tuning Page 6.1 Page 6.2 TPMS Performance andTuning VTPTUNEV2.0 6.1 .Introduction to Tuning. l-iaving collected the set of statistics suggested inchapter 4, there will be a base lineagainst which changes to the system can be measured. The golden rule of tuning any service is to change one thing at once and measure the results to ensure that the change has achieved what is required. Itis highly likely that tuning one service will reduce the performance ofsome other partofthe system and so a planforregressingthe changes should be put into place sothat any ill effects can be quk:kly rectified. There are two basic methods oftuning a service: whk:h one to use depends on the situation that we find ourselves in. Ifwe are pro-active then we can take each resource, i.e. CVM,AVM, files etc in turn and analyse, size and tune them. The nK>st likely situation is that we are reacting to an existingproblemand then we take the offending message type or resource and tune around that Ineither case itis essential that any changes made are documented and a regression action is planned. Afurther set of statistrcs should be taken and compared withthe base line set. Itis important to includethe VME system statistk:s inthis to measure what effectthe change has had on the rest of the system. You should also consult the end users ofthe system smdthe operations department to determine whetherthey have noticed any improvement or problems resulting from the changes. VTPTUNE V2.0 TPMS Performance and Tuning Page 6.3 Tuning Areas to consider -VME -CVM -AVM -Hies -IDMS -COMMS VTPT6010 Page 6.4 TPMS Performanceand Tuning VTPTUNEV2.0 6.2^reasfor Consideration. The areas that we need to consider are — Disc transfer priorities — CVI^ — AVI^ — Files — IDMS — COMMS We will lookat how each ofthe above can affect the performance ofa TPMS service. VTPTUNEV2.0 TPMS Peffomriance and Tuning Page 6.5 lOs • Transfers queued on (Absolute OCP priority )*2 • CAPS transfers queued on (Absolute OCP priority)^-i-1 • Virtual Store Transfers queued on Chronological order VTPTeOSO Page 6.6 TPMS Performance and Tuning VTPTUNEV2.0 6.3.Disc transfer priorities. On S series machines lOs are queued on base OOP priority. On Lseries machines lOs are queued on base + relative OCR priority (absolute priority) thus can be affected by the values of MAXPRI/MINPRI specified for an AVM. This could be usefulfordowngradingthe impact of large processes or to ensure thatf^ processes such as the CVMeu^e given priority. CAPSand multi-block transfers are furtherdowngradedat (absolute priority) *2 +1. Thus CAPStransfers can be interuptedbyan AVM running at the same or higher priority. AlsoCAPS transfers from a VMwith MINPRI/MAXPRI set to 0 will queue behind transfers from a VMwith MINPRI/MAXPRI setto 1. Note This only applies to Lseries machines. Virtual Store transfers have a higher priority than other disc transfers and are queued in chronological order. Thus ifsecondary storage sites are on user discs then TPMS transfers could be queued behind virtualstore transfers from any VM. Thus a MAC or BATCH VM could dramatically affect the performance of TPMS in this case. VTPTUNEV2.0 TPMS Performanceand Tuning Page 6.7 CVM Areas to consider •-VSIS •OCR contention •lOs •-User hooks •Number of services VTPT6100 Page 6.8 TPMS Peiformance and Tuning VTPTUNEV2.0 6.4.CVM. Having established that the two factors to be examined are the queuing factor and service time, TPMS resource entities are now considered. 6.4.1.Service time. The following areas should be considered when looking at service time. VSIs. OCP contention. I-Os. User hooks. Number of services. 6.4.2.VSI's. Itis essential thatthe CVM gets allthe store that it requires in order to maximise throughput. The CVM normally holds the preprocessed module for the servk:e. Whether or not a PSQ is in use will significantiy affectthe TPMSstore requirementsas the PMOD is mostly globaldata. Sizingthe CVM should therefore be done intwo halves. Rrst size the preprocessed module and then the CVM code and data and any user hooks. VTPTUNEV2.0 TPMS Performance and Tuning Page 6.9 Store requirements for preprocessed module Initial Fixed size 1600 bytes No of message types* 208 bytes No of mess^ slots * (INBUF+OUTOUF+408) bytes NoofAVMTYFES*340 bytes No ofterminals*275 bytes Sum ofAVMUMSM96 bytes No of message types and keys * 40 bytes TOTAL BYTES bytes QUOTA=TOTAU/1024 KB Page 6.10 TPMS PeHbrmanceand Tuning VTPTUNEV2.0 store requirements for preprocessed module. initial fixed size 16000 bytes Noof message types*384 bytes No of message slots * (INBUF + OUTBUF +410) bytes NoofAVMTYPEs *548 bytes (Nooftemfiinals + CONVLIM + FIRSTMSGS)*484 bytes Sum ofAVMUMs *276 bytes No of message types and keys *44 bytes Number offiles *220 bytes Noof screen template modules*32 bytes Noofscreen formats *60 bytes Noof printers *92 bytes DOCNUM*26 bytes PRINTNUM*34 bytes Noof print queues *56 bytes TTNUM*64 bytes total bytes bytes Quotas total/1024 KB VrPTUNEV2.0 TPMS Performance and Tuning Page 6.11 n n n Page6.12 TPMS Perfbrmance andTuning VTPTUNE V2.0 store requirement for the CVM. VM overhead 50 Kb Logging files: (Blocksize in Kb) * 2 Kb TPMS slotfiles: (Blocksize in Kb) * 2 * no of slot files Kb Temiinal simulator (TSIN blocksize in Kb) * no of buffers Kb (TSOIJT blocksize in 1^) *no of buffers Kb TPMS local code and data 15 Kb User code and Data Kb If Policy Shared Quota in use SQUOTA = RQUOTA Kb TPMS global code and data 35 Kb Preprocessed module Kb TP screen formats Kb Ifno Policy Shared Quota and pre-SygOQ SQUOTA = RQUOTA = Kb VTPTUNEV2.0 TPMS Performance and Tuning Page 6.13 CVM Areas to consider »^VSl8 ^OCP contontfon ^-lOs ^-User hooks Number of services VJPT6125 Page 6.14 TPMS Perfbrniance andTuning VTPTUNEV2.0 6.0.0CP contention. TPMS runs as Ihe highest priority forOCP so contention is unlikely except with other TPMS VMS. It is sensible to use MAXPRI/MINPRI to set AVMs lower than theTP CVM for live TPMS services. 6.4.4.lnput-0utput8. The CVM does few or no lOs during message processing and none that are not essential or requested. LOG=SECURE causes one extra 10 per message and should be avoided ifnot necessary. 6.4.5.User hooks. ^ ^ rV t/t User hooks, i.e. message analyser or process reply are the onlysource of high OCP usage or lOs. Both ofthese hooks should perform as little processing as possible and preferablyno lOs. Any data required bythe CVM should be loaded intoCOBOL EXTERNAL or globalareas by a program in the CPARAMS hook, altough this will not be possible ifusing the data is to be ktaded from an IDMS database. It is also worth initialisingglobal areas in a batch job loaded before the CVM is loaded. Itis worthwhile to use tfieTPMS message routerlacilities for normal message types and to only allow unrecognised messages to goto the message analyser.AnAVM based defaultmessage type may be more effk:ient 6.4.6.Number of services. There are signifk^nt user and technrcal gains to be had from merging existing servk:es into one servk:e. This provides the user with a single service to access and reduces the number of CVMs running within the machine.The mainproblemswith this approach are normally packages or operationalreasons for keepingservk:es separate. Packages can be extremelydiffk:ult to merge and would probably be best leftseparate unless they are compatible with existing servrces and make use . ofTPMS routing facilities rather than a message analyser. 6.4.7.Queue time. In rTK)st TP servk:es, CVM utilisation is not a problem. It is possible for queues to form if machine loading is heavy or over 10 messages a second are to be processed. Obviouslyusing a message analyser or process reply could affect the point atwhrch CVM queues will occur. Message sk}ts may become a bottle neck as the limit is 256k total (1 Mbwiththe XLoption) so minimising the sizes of INBUF and OUTBUF may be worthwhile on a highthroughput system. VTPTUNEV2.0 TPMS Perfonnance and Tuning Page 6.15 AVM VSIs OCP contention Suspensions lOs Timeouts VTPTB130 Page 6.16 TPMS Performance and Tuning VTPTUNEV2.0 6.5J\VM. 6.5.1.Service time. The following resources need to be considered when considering AVM service time VSIs OCP contention Suspensions lOs Timeouts 6.5.2.VSi8. As with any VM, VSIsshould be keptto a minimum and avoided on highly frequent messages. The best way to avoidVSIs is to size the AVM store quotas correctly. The requirements are differentfor user, spooler and offloadavms. VTFTUNE V2.0 TPMS Perfomnance and Tuning Page 6.17 Page6.18 TPMS Performance andTuning VTPTUNE V2.0 store requirementfor AVM. VM overtiead 50 Kb RECMAN recoveiyfile (blocksize In kb) * 2 Kb RECMAN recovery delayed update buffer Kb TPMS slot files (blocksize in Kb) * 2 Kb User codeand data working set Kb User file buffers (blocksize In KB* no of buffers) Kb IDMS buffers (largest page size * no of buffers) Kb IDMS journal buffers (blocksize * 2) Kb TPMS local code and data 25 Kb Document handling (10+((DOCPHASE * 2) + 1) *folderfile size in Kb Kb If Policy Shared Quotas are used SQUOTA = RQUOTA Kb TPMS code and data 35 Kb TPMS spooling code and data 55 Kb User global code and data Kb Ifno PolfcyShared Quota is used and pre-SV29Q SQUOTA RQUOTA Kb VTPTUNEV2.0 TPMS Performance and Tuning Page6.19 n Page 6.20 TPMS Performance andTuning VTPTUNEV2.0 store requirementfor ICL spooler AVM. VM overtiead 50 Kb TPMS local code and data Kb Folder files buffers Sum of each (FLDRSIZE* 2) Kb No ofterminals*148-i- No of folder files* 80 4- No of printers *16= bytes = Kb Ifa Policy Shared Quota is used SQUOTA = RQUOTA Kb TPMS global code and data 35 Kb Ifno PolicyShared Quota is used and pre-SV290 SQUOTA RQUOTA Kb VrPTUNEV2.0 TPMS Performance and Tuning Page 6.21 n Page 6.22 TPMSPerformanceand Tuning VTPTUNE V2.0 Store requirement for a dedicated offload AVM VM overhead 50 Kb TPMS slot files (blocksize in Kb) * 2 * no of slot files Kb TPMS local code and data 25 Kb Log file (2 * log file blocksize ) Kb Record area 8 Kb Audit trail (blocksize * no of buffers) Kb SQUOTA RQUOTA KB VTPTUNEV2.0 TPMS Performance and Tuning Page 6.23 Page 6.24 TPMS Performance and Tuning VTPTUNE V2.0 Store requirements for a Policy Shared Quota CVM global code and data 45 Kb AVM glot)al code and data 35 Kb Document handling code and data 55 Kb Spooler global code and data 45 Kb Preprocessed module Kb User global code and data Kb Screen fomfiat modules Kb PSQ = KB VrPTUNEV2.0 TPMS Performance and Tuning Page6.25 AVM VSIs OCP contention Suspensions lOs Timeouts VTPTB139 Page 6.26 TPMS Performance and Tuning VTPTUNEV2.0 6.5^.0CP contention Similarto the remarks on OCP contentionfor the CVM, an AVM Is unlikely to experience contention for OCP except with another AVMor CVM. It is betterto run the AVMs at a lower OCP priority than the CVM to reduce the possibilty ofcontention slowing the CVM as itis singlethreading. This is particularly true ifthe AVM contains mill bound processes. 6.5.4.Suspensions. AVMs can be suspended whilstsome TPMS functions take place. Tlie functions that will suspend an AVM are — ICL9TXL0G. Logfilewrites are done by the CVM when the block is full, the AVM is suspended whilstthe CVM pk:ksup the data. Note:-calling ICL9TXIog from an SCL procedure can result in a system crash. — ICL9TXTAKE/ICL9TXGIVE. Both ofthese routineslooptrying to get the semaphore. They should only be used when absolutely necessary. Where a global table is used that is keyed on terminal id, or has one entry per terminal, then as the entry is only going to updated by one AVM at once then the semaphore routines are not needed. It Is only in the situation where common data can be upcteted by more then one AVMatthe sametime thatthe semaphore routines are required. ^ —(jmmedia^unsolfcited output Causes the AVM to suspend waiting for the CVM \\ tooutput the data. — Filling the output buffer OUTBUF will also cause the AVM to suspend whilst the CVM outputs the unsolicited reply or timer task. Thesefunctions should be avoided. 6.5.5.10s User lOs are discussed inthe next section. The following can reduce lOs to the slot file:- — UsingRSECURE=UPDATE whkih will reduce the number of lO's per message in certain circumstances. — Avokling MRECOV=VMA. Itcauses an extra writeto the slotfilefor each Input message. Qyi, If" ^ \/oc >• — Not using extended partial results. Each extra block causes an extra disc transfer. All the above will produce minorimprovements in overall response times. meouls. rJiijLy '^7 A timeout is caused by a messagethat has exceeded MAXTIME Inthe AVM. Thetimeout is effected bythe CVM sending a contingency 52 subclass 9 to tiie AVM. The contingency can onlybe handled at an ACR level equalto or above that atwhrch it was caused. Thus ifthe AVM is stuck on a VME semaphore or kx:k, i.e. it is in code at a k>werACR level than the CVM ttien the timeoutwill be ignored untilthe AVM gets to the higher ACR level. The timeout will also be ignored ifthe AVM is in IDMS code. Ifthe AVM does not acknowledge the timeout withinAVMTIME then the AVM will be k>st to the servk:e untilit is rehsaded and the terminal processing the message will be locked out. A pointto watch here is that the CVM checks messagetimeout periodrcally as specified inthe periodicfunctions, Thus iftimeout is checked every 5 minutes and MAXTIME is setto 1 minute then ^ the time taken to generate the timeout contingency will be between 1and 6minutes. Thus MAXTIME VTPTUNEV2.0 TPMS Performance and Tuning Page 6.27 Page 6.28 TPMS Performance andTuning VTFTUNEV2.0 must be viewed in conjunction withthe periodic functions and UNITTIME. Messagetimeout is a useful diagnostic tool. Itcan traplooping and long messages and highlight problems. In order todothis itmust becorrectly set up. It isrecommended thatmessage timeoutis onlyused inthe earlystages ofa live service and intesting as itcan cause serious problemsbecause ofthe lengthoftime ittakes to producethe VM dump.The situation is less ofa problem with TPMS 510 as the length oftimeto producetiie AVM dumphas been reduced. If full OPEH and VM dumpsare being produced at 510thenthere isverylittle reduction inthe timetaken and problems could occur. Setting a diagnostic level of4 will considerably increasethe timetakento producethe OPEH report, particularly ifthe programs are large. Onefurttier point isthat MAXTIME should always be greaterthanthe IDMS service timeout as using an IDMS timeout of5 minutes with MAXTIME set to 1 minute wil almost certainly leadtoa vast numberoftimeoutsifthere is any contention for IDMS pages. 6.5.7.Queue time Thequeuing theory diagrams which welooked at in Section 3 indicate thata utilisation figure of30% isa reasonable figure toaim at for avoiding excessive queuing times. Thetheory isbasedon a normal distributionof AVM processing times. The most comrrwn way tosplit messages ina service between AVMs isto arrange themon an apprication basis, sothateach applrcation has its own AVM. This is not necessarily thebestway to arrange the servfee for the bestperformance. Certain applications may havelengthy processing times because of heavy disc or mill usage and would be better in their own AVMTYPE. 6.5.8J^VMTYPEs and AVM copies. 6.5.8.1 .Mapping message typesto AVIMTYPES. During the process of setting upthe TPMSsen/k:ethe designer needs to size the numberof AVM copies andthemapping ofmessage types to AVMTYPES. Theinformation thatwassuggested in chapter3 forms the b^is ofthese decisions. The aim of this process is to provide the most efficientuse of resources and the rrost consistent responses tothe user. In order toachieve this the messagetypesshould be grouped into bands of response tinfies, e.g. 0.5 -1 second, 1 to 2 seconds etc. The reason for this is that the designer/implementor can alkx:ate suffk:ient copies ofan AVMTYPE most effk:iently when the AVMTYPE processes a nanow range of servfce times. ifthis is the situation the graphthat was used to cateulateresponse timescan also be used to work outthe minimum and maximum number ofAVM copies thatwill be required to copewith expected throughput Using the same example as Inchapter 3 , where the AVM servk:etime was 1.25 seconds, the peakutilisation (2000 msgs/hour) was0.69 andtheaverage utilisation (1500 msgs/hour) was 0.52.This gaveexpectedresponsetime varying from 2.63to 4.2seconds.Agoodfkjure to aim at is to ensure thatthe AVM utilisation is around 30%. Looking atthe graph showing queuefactors theeffect onthis AVMTYPE ofincreasing the number ofcopies to twocan be seen. Rrstly this will reducethe utilsation fiqures so peak utilsation = (2000*1.25)72*3600 ^ = 0.35 average utilsation =(15000*1.25)72*3600 = 1.37 Thisgives queue factorsof1.4and 1.1 respectively and extirmtedresponse timesof 1.65 and 1.4 seconds. The second copy will thus reduce the queueingeffectsto a minimum. Ifthis AVMTYPE need to be rolled inand outto because ofstore shortages then AVMMIN should be setto VTPTUNEV2.0 TPMS Perfbmiance and Tuning Page 6.29 AVMTYPES AVMTYPE % Utilisation QUEUE factor 1 40 1.7 2 15 1.2 3 15 1.2 4 20 1.2 5 30 1.4 VTPT6140 Page 6.30 TPMS Pertbrmance andTuning VTPTUNEV2.0 ^^MAX set to 2. Thisprocess should be continued until the utilsation per AVM copyis around ^30%. rsJ^Single application AVIATYPES. Puttingan applicationintoa single AVMTYPE gives the following disadvantages — An AVM which is idlefor most ofthe time but using valuable mainstore. — An AVM whichcannot cope withsudden peaks. — AnAVM which handles bothfast and slowmessages can build upqueues behind slowmessages. This downgradesthe performance from the user's pointofview even though the AVM has a low utilisation. One possible improvement is to have one AVMTYPE with manycopies. Suppose, for example, that we have 5 different AVMTYPEs. AVMTYPE % UTIUSATION QUEUE FACTOR 1 40 1.7 2 15 1.2 3 15 1.2 4 20 1.2 5 30 1.4 The AVMs have thefollowing typical overheads for store s VMo/h 50 KB Slot file buffers 36 KB TP code 25 KB Spooler code 15KB IDMS buffers 20 buffers @ 6144 = 120 KB Partial results 2KB IDMSjournal buffers 24 KB buffers. total = 272 KB - total store overhead 1360 KB. Changingto 1 AVMTYPE with 3 copies would reduce the queuingfactorto 1.1 and save 544 Kb of store. This is a contrived example.A more realistic examplewould be 5 AVMs witti a verylow utilisation which could be amalgamated into1 AVM, saving 0.5 Mb of store but slightly increasing queuing probability. There are 5 main reasons for not amalgamating AVMs> — Appfication needs - requirements to release files for updating. VTPTUNEV2.0 TPMS Perfbrnnanceand Tuning Page 6.31 AVMTYPES •Single appiication AVIM •Could be idle sometimes >*Can it cope with peak traffic *Range of message response times • ll/lerge AVIMs with •Similar response times •using same code VTPTB1S0 AVMTYPES • DONT lUIERGE AVMS if •Application requirements •Resilience •Package application •High numbers of RECMAN files •More than one Database VTPTBieO Page 6.32 TPMS Perfomfiance and Tuning VTPTUNEV2.0 — Resilience - new applications have a tendencyto fail. — Packaged application - DO NOT disturb. — AVM witha high number of RECMAN files - duplication ofthis AVM will duplicate file buffers. — Unable to access more than one IDMS database from the same AVMTYPE. A possible compromise would be as follows AVMTVPE1 - for new applications. AVMTYPE 2 - for rogue messages, high OCP or lO's, large number of files. AVMTYPE3 - for average messages. withanother AVM ifnecessary fortime critical fast messages. 6.5.8.3.0ffload AVM. There is no particular reason why an offload AVM should be a dedicated AVM, itwould be betterto use an existing multi-copyAVM. 6.5.8.4.RollingAVMs. Rolling AVMs provide facilities for dealing with rarepeaks inmessage typesorfor rarely used applirations intheirownAVMTYPEs. Theycan provide the advantages of multi server AVMs without the disadvantage ofmultiple AVM copies until the resourceis required. There is however a price to be paid for this flexibility. The message ^at causes the AVM to be rolled back in will be slow, delayed by the need to RIRO the AVM. The algorithm used byTPMSto decide whetherto roll inanother copyofan AVM takes account of the current queue size for that AVMTYPE.The CVMwillroll in another AVM when the queue exceeds: (CONONDEM +1) * no ofcun'ent AVM copies Thus, with CONONDEM defaulted to 3, the queue needs to reach 4,8,12 to roll incopies ^ 2,3,4. The AVM copy will be rolled out if, on 3 successive checks ofthe periodk: function, the queue forthe AVMTYPE is less than the valueofthe OlSONIDL parameter; thus ifitis checked every5 minutesthen itwill take 15 minutesto roll outthe AVM. Setting DISONIDL to 0 will roll the AVM immediately the message has finished. Whilst this could be usefulforvery lightly loaded VMs such as an offload VM itshouldbe avoidedforallotherAVMs as the cost per message couldbe veryhigh. VTPTUNE V2.0 TPMS Performance and Tuning Page 6.33 Message Slots •Number allocated »>(CONONDEM * 1 ) AVMMAX »>MSIjOTMIN / MSLOTMAX •Calculated using »>MSLOTMIN = AVMMIN t^MSLOTMAX = AVMMS + 1 •AVMMS calculated using queuing theory graphs in appendix 1 vryiBiao Page 6.34 TPMS Perfbmiance and Tuning VTPTUNEV2.0 6.5.9.Message slots. The aimwhensettting Ihe number ofmessage slotsforan AVMTYPE is to tryand ensure that there is usually a message slot available foran incoming message. We have seen howthe number of AVM copies can be calculated using the peak AVM utilisation,this section will deal with using the utilisation figures to set the values for MSLOTMIN AND MSLOTMAX. The number ofmessage slotsalkx:ated to each AVMTYPE is controlled by,eitherthe default (CONONDEM +1) *AVMMAX or by setting MSLOTMIN/MSLOTMAX for each AVM. MSLOTMIN specifies the minimum number of message slots for an AVMTYPE. MSLOTMAX is the maximumnumber of message slots that an AVMTYPE can use. Oncethe number ofavm copies has beenworked outthereseems little point inspecifying MSLOTMIN as lessthanthe number ofAVM copies specified byAVMMIN, otherwise a message could be rejected whenthere isan AVM to process itavailable butno message slot, therefore MSLOTMIN = AVMMIN f MSLOTMAX can be set byusing the peak utilisation fiqure forthe AVM and tiiegraphsin appendix3. Thisset ofgraphs relatethe probability ofexceedinga queue to the AVM utilisation fora given number ofavmcopies.The graphs coverfrom one to five AVM copies. Having worked outthe peakutilsation the designer must thendecide onthe percentage of messages that can be rejected at peak avm k)ading.The should cover most circumstances and should be in the range0 -10 %. Much more thanthisandthe number ofrejected messagescould cause user dissatisfaction. The final step is to kxik at the graph and to pk:k the linerepresentingthe kiwestnumberof message slots forthe peak utilisation figure inthe range 0 -10% on the y axis e.g. fora singleserver (AVM copy) AVMTYPE with a peak utilisation of0.52 then the linerepresenting n=3,5or 7 could be used. Takingthe k3west figure, 3, as a value forAVMMS inthe following formula allowsMSLOTMAX to be cak:ulated asfollows^ MSLOTMAX = AVMMS + 1 = 4 Ifthe designer had decidedthat no messages should be rejectedat peak utilisation times the 7 would be the correctvalueforAVMMS asthe linenearest to zero probability ofrejecting a message, giving a figure for MSLOTMAX of MSLOTMAX = 8 The total number of message slots in the servk:e should be tfie sum ofthe MSLOTMAX values for each AVMTYPE. MSGSLOT = sum of MSLOTMAXs -f2 forcontingencies VTPTUNE V2.0 TPMS Perfomfiance and Tuning Page6.35 Filestore transfers • OCP time for 5000 COBOL instructions on a i^vei 60 = 14.4msecs •Timeto service one random disc access s 40 msecs • DISC TRANSFERS ARE SLOW! - Keep number of transfers low - Service transfers quicidy VTPT6510 SERIAL FILES »COBMODE=E Block written at end of phase Large blocksize will waste space ^Writes to FLF to update EOF »-Flle extension = 2/3 iOs INITIAL size should be realistic Use large allocation unit Iffile may need to be extended VTPT6520 Page 6.36 TPMS Perfbmiance and Tuning VTPTUNEV2.0 6.6.HLESTORE TRANSFERS. Ithas alreadybeen observed that itis likely to be disctransfersmorethan anything else whk:h will determine how tong TPVMs taketo process messages. In order to minimise thetime spent on them, we willwant to do two things: keep the number of disc transfers as lowas possible servrce the transfers done as quicklyas possible. We will nowconsider how we may achieve these two objectivesfor the filestructures most commonly used. 6.6.1.Serial files. Ifa serial file is used as an output file by a TP AVM, unless the whole file is to be written in one phase, itwill have to be opened inappend mode (COBMODEsE). Because a COBOL CLOSE has to be done on the file beforethe STOP RUN, the bkx:k will be physrcally written to the file. Itwill be necessary to updatethe EOFmarker inthe FLF periodically. Thiswill be done every Nblocks, where Nisthe valuesupplied as the SAVEEOF parameterinSET FILE_OPTIONS or DESCRIBE_FILE_USAGE. IfN is setto 1. this means that at least 1 extra disctransfer per updatingphase is done to update the FLF entry. Ensure that the file is created whh an initial size which is realistk:, and that it is in an allocation with a large unit size. Ifitwere to be placed in the default Lallocation and too small an initial size had been specifiedthen once the space initially allocatedhad been filled, each phase writing to the file would cause an extend to the file. whk:h would mean 2 or 3 additional disc transfers. 6.6.2.lndexed Sequential files. 6.6.2.1.Structure of IS files. AnISfile consists oftwo primitive files, one consisting of blocks holding data records in key order and one of blocks holding index entries, ^ch data bkxk will have a corresponding index entry holdingthe value ofthe highest key contained Inthat data block. [This description does nottake account of overflow, whkii is considered later].The length of each index entry is the key length plus 4. Since there are 12 bytes reserved on an indexblock, itfollows that, forexample, usinga 2KB blocksize, ifthe total length of the index entries exceeds 2036 then not all entries can be held in one block. Whathappens then is that a high levelindexbkx:k is used which holdsthe highest keyheld on each oftwo lowerlevel index bkx:ks.Inthis way, an indexed sequential filemay contain several levels of index.The signifk^nce ofthis is that inorderto obtaina data record by key itis necessary to read index blocks fi'omthe highestto the towest level in orderto locate the correct data block. Ifthere are 3 levels of index bkx:k, this means 4 bkx:ks must be read to obtain a data record. VTPTUNEV2.0 TPMS Performance and Tuning Page 6.37 structure of an I.S. File • 1 r 2 3 Index file • C f 1 2 3 4 / Data a b c d e f File VrPT6530 IS FILES IS FILES Calculate indexblocks at Calculate Index blocks at each level each level Example: Example: Blocksize b2048 Blockaize •4096 Key length >24 Key length * 24 No. ofdata Mocks *10000 fto. ofdata blocks sSOOO Index entries per k>lock • 2038129 m72 Indue entries per block a 4084/28 »145 11 « 10000/72 « 139 12 - 139/72 • 2 H 5000/145 35 13-2/72 ml 12 35/145 1 vrpr654o VTPT6545 Page 6.38 TPMS Performance and Tuning VTPTUNEV2.0 The number of levels of index and the number ofindex blocks can be found foran existing file on the File Meters output. Itcan be calculated in advance as follows; NO. OF INDEX ENTRIES = (INDEX BLOCK SIZE-12)/ (KEY LENGTH + 4) PER BLOCK (IPB) [roundeddown] LOWEST LEVEL INDEX (II) = DATA BLOCKS IN FILE / IPB [rounded up] IfII is greater than 1 then there will be a higher level of index calculated as follows: 12 = II / IPB [roundedup] If12is greaterthan 1 then 13 = 12 / IPB [roundedup] and so on until the answer is 1. Clearly, the larger the blocksize on the indexfile, the more index entries can be accomodated ineach index block. Itmay be feltadvantageous to specifya larger blocksize forthe indexfile than forthe data file ifthis will reducethe number oflevels ofindex. Thismay not be desirable though, as itprevents the file buffers being shared for data and index blocks. In the example on slide VTPT6540 the number of index levels would be reduced to 2 ifa 4KB bk}cksizewereto be used, reducing the number of lOs needed to access a record. 6.6^^Bufrer8. Ifa program requests a blockof a filewhrchis already held in a file bufferno disc transfer will be incurred. It makes senseIherefore to allocate suffuient buffers to ensure that index bkx:ks do not have to be re-readany morethan is necessary. To illustrate this,considerthe following example: Afilewithtwo levels of index and two buffers allocated (the default) has a record read. The usage of the buffers will be 1) READ HIGH LEVEL INDEX INTO BUFFER 1 2) READ FIRST LEVEL INDEX INTO BUFFER 2 3) READ DATA BLOCK INTO BUFFER2 - overwriting the first level index block read. Onthe nextread ofthe file itis likely that stage 2 will have to be repeated, whereas if3 buffers had been alkx:ated, the re-read ofthat indexblock maywell have been avoided,savinga disc transf^. Itis generallyrecommendedthat the numberof buffers allocatedshould be 1 per level of index plus 1 (plus 1 if updating). This is not the optimum number for all circumstances however, as the following example illustrates: FILE BLOCKSIZE ^ 2KB KEY LENGTH = 12 BYTES NO. OF DATA BLOCKS = 500 IPB =2036^16 =127 11 =500/127 =4 12 =4/127 =1 VTPTUNEV2.0 TPMSPerformanceand Tuning Page 6.39 IS FILES Calculate Index blocks at each level Example: Blocksize = 2048 Key length = 12 No. of data blocks =500 Index entries per block = 2030/16 = 127 11 = 500/127 = 4 12 = 4/127 = 1 VTPT6550 IS FILES Avoid overflow Reorganise file when necessary >-lf Inserts evenly distributed set packing density as low as needed ^Overflow at EOF ' From SV290, use AMEND.RLE.CONTROL.VALUES 'Pre-SV290, need to pre-format the index blocks VTPTeseo Page 6.40 TPMS Perfbmiance and Tuning VTPTUNEV2.0 So if5 index buffers are allocated, ail the index blocks can be held in mainstore and none will have to be re-read, perhaps saving many disc transfers. The following table shows what bufferswill be used by RECMAN for differentsettings ofthe BUFFERSF>arameter to DSFU or STFOPT depending on the ACCESS being used. The results were obtained using SV290: BUFFERS ACCESS DATA BUFFERS INDEX BUFFERS DEFAULT SEQ OR DYNAMIC 2 1 DEFAULT RANDOM 1 1 5 SEC OR DYNAMIC 2 3 5 RANDOM 1 4 6 SEQ OR DYNAMIC 2 4 6 RANDOM 1 5 8 SEQ OR DYNAMIC 2 4 l^/ 8 RANDOM 1 5 S Ifadditk)nal index buff^ are required then it will be necessary to specify BUFFERS=i X10000-i-d wherein number of Index buffers and d = number of data buffers. Eg. DESCRIBE_FILE_USAGE(FRED,BUFFERS=60003) will allocate 6 index buffers and 3 SV212 users shoukJ refer to ION B98 for further informatkxi on buffer allocation. 6.&2^0veiflow. Ifwe request that a record be inserted on an ISfilethen, by reading the Index blocks, the prime data block where the record 'betongs' is k)cated. Ifthere is no room Inthe prime data blockfor the new record then, if a block is available, an overfkiw block is allocated. The new data record is written to the overflowbkx:kand a pointer to the overftowchain is written to the prime data block. If further records are written withinthe same range of keys Inthe file such that the overflow block itself becomes full then a further overftow block is allocated, the data record written to that block and a pointer to the new overftow bkx:k is written to the first overftow block. Ifthis happens much on a frequently accessed file then the performance degradation can be horrendous, as overftow chains have to be followed incurring large numbers of l-Os. So what can be done to avoid It? Rrstly, volatile IS files should be re-organised regularly to eliminate overflow. 'Regularly*in VTPTUNEV2.0 TPMS Performance and Tuning Page 6.41 BLOCK LOCKING UNLOCKING POLICY - DESCRiBE_RLE_USAGE - SET_HLE_0P710NS Concurrent TP & BATCH -SetEXPUCITfbrTP 'Set IMPUCrrfor BATCH VTPT6S70 IS FILES Large blocksize? >FOR Could reduce levels of index - Probably better disc utilisation >AGAINST 'If access is mainly random, may just waste mainstore ' If many sequential accesses, can use Multiblocktransfers anyway 'More contention through block locking VTFT6575 Page 6.42 TPMS Perfbmianceand Tuning VTPTUNEV2.0 this context means as often as is necessaiy - read the filemeters information to monitor overflow. Secondly, setting a lower packing density may reduce overflow, but itwill make little difference ifmany records are being inserted at the same pointin the file. Thirdly, where a file is to be 'loaded* onlineand the range of keys to be mserted is known, the Hidex blocks can be 'seeded* in the same manner as thatdescribed below for handling insertion at end of file prior to SV290. Rnally, if long overflow chains will be created by inserting many records in groups in \ ascending key sequence, it will be beneficial to set the SPUT parameter for DSFU to a high value \ (say 90). 6.6u2.4.0verflow at end of file The insertionof large numbers of records at the end ofthe file represents a somewhat specialised situation, the handling of whtehis greatly improvedat release SV290 and later. Letus take bywayof examplea case where a TP servk:ewrites logging type records keyed on date and time. Pre-SV290,a record with a key higher than any whrch is to be inserted in run mode has to be writtento the file. As all data records in this example would be inserted between the last genuinerecordand the last (dummy) record, once the last prime data block has been filled they will all go intothe same chain of overflow blocks. Bythe time say 20 overflow blocks in this chain have k)een written to,the WRITE ofthe nextrecordwill have becomeveryexpensiveindeed.The prime data block and all ofthe blocks in the overflow chain will have to be read before the record can be written. The morerecords are written the worse thissituation will become, and l-Os per transactionand response times will increase steadilythroughoutthe life ofthe service. The waythis problem has to be circumvented pre-SV290 is toformat the index blocks before starting the TP servrce byrunning a program to write records inthe range of keys whk:h are to be insertedand then running a program to delete all the records. This will leave the index blocks formatted soas to insert new records in the primedata blocks, but leave the data blocksthemselves empty so that the new records will fit inthem. AtSV290,this procedurewas made unnecessary. Itis no longernecessary to add a dummy record with the highest key. Instead, the highest allowablekey is specified by calling AMEND_FILEjCONTROL_yALUES. Ifthen records are written to the file hirun mode with keys higherthan the prevk>us highest key, primedata blocksare allocated dynamrcally and additioned index entries written as necessary. There is no change at SV290 in the handling of overflow which occurs other than at end of file. 6.6^i».Locking. Locking can, incertain circumstances, drasticallyaff^t the time taken to performa file access. The defaultfor ISfilesinTPMSis LOCK=X - i.e. blocklocking: any other VM may assign the file with LOCK=X and may access the file concurrently, but when a primedata block is accessed itwill be lockedfor a perkxJ of time. Itis importantto appreciate that blocksaccessed by a VM will be locked even ifthe file is assigned only with READaccess. The perk)doftime for whk:h a blockis locked is affected bythe UNLOCKING^POLICY parameter to DESCRIBE_FILE_USAGE or SET_FILE_OPTIONS. Ifitis set to EXPUCIT, then any blocksaccessed since the COBOL OPEN will remain lockeduntil a DESELECT^RECORD is done. This will occur on a COBOLCLOSE or, for a recoverable filein a TP phase, at the end of the phase. Ifit is setto IMPUCnr, the locks are released when RECMAN considers itno longer needs the block. Ifa batch enquiry program accesses the fileconcurrently withTP then itseems sensible to avoki havingthe batch program holdinglocks on all the blocks ithas accessed, thus locking out TP. ^ Call DESCRIBE_FILE_USAGE setting the UNLOCKING_POUCY to EXPUCIT todetermine theTP VTPTUNEV2.0 TPMS Performance and Tuning Page 6.43 n n Page 6.44 TPMS Performance and Tuning VTPTUNE V2.0 usage and callSET_FILE_OPnONS inthe batchSCLsettingitto IMPLiCIT. 6.6J2.6.Multiblocktransfers. When an Indexed Sequential file isaccessed sequentially (READ NEXT) VME will read more than 1 data blockwhen it obtains the record ifit is able to do so - i.e. ifit has suffident filebuff^. Thismeans that in suitable circumstances the appfication can benefit from reading morerecords ina single disc transfer. Thefile meters information will show whether multiblock transf^ are being used. Ifthey are not. and iftheir use seems appropriate, have enough buffersbeen allocated? Ifmultiblock transfers are beingused itis particularly important to specifythe numberofindex and data buffers explicitly, otherwise the multiblocktransfer could overwrite the index buffers. 6.6.3.Hashed Random files. Hashed Random files have the obvk>us advantage that a random access to a record in a prime data block will alwaysincur just1 disctransfer- there are no index blocks to read. Ifonly random accesses are made to a file therefore, it is better to process a Hashed Random file than an IndexedSequential one. The prrcepaid forthis effk:iency is that itis not possible to read the records in key sequence: random means random. As with ISfiles, overflow can become a problem. When the file is created you should ensure that sufficientblocks are allocated and that a good hashing algorithm is chosen. The number of blocks allocatedshould be about doublethat which would be requiredfora serial file. Itis suggested that you calculatethe numberof blockswhich would be required to holdallrecords ifthe blockswerefully packed then increase this by40% and set the initial numberof blocksequal to the nearest prime number (prime numbers give a better algorithm)and that you set the maximum number of blocks to double the number which you calculated were needed to hold all the records. VTPTUNEV2.0 TPMS Performance and Tuning Page 6.45 IDMS • Disc transfers ^'Type of record •Navigation path Number of buffers k-type and number of sets k'type of journalising • Buffers ••Defined by IDMS_RUN or service tables Delayed updates k-Check using DMLtrace or ICL9IDMSAmSTATS VTPTSeiO IDMS • Overflow •Target page full •VIA clusters •Indexes •Journals •Central journals •QBLs and Area journals •Duplexed DB and QBLs • Locking •Page lock table •Delayed Locking VTPTB620 Page 6.46 TPMSPerfbnnanceand Tuning VTPTUNEV2.0 6.6.4.IDMS. The number of disc transfers generated by a request to retrieve, update or store a record on an IDMSdatabase is dependant on the following. Type of IDMS record i.e. CALC, VIAetc. Navigational path used to retrieve record e.g. VIA set or record mdex orCALC key. The number of buffers available. When storinga record,the numberofsets the record partcipates in. Each record that points to the new record will need to be updated. Whether the record is member of a sorted setor a set or record index. The type of journalising used. Each ofthe above affectsthe numberofdisctransfersused. Discussion ofthis ineuiy detail would require some time so only the main points ofbuffers, overflow and journalising are discussed. The other pointsare covered morefully inthe IDMS manuals and on the IDMS design course (VIDMD). M^-r 6.6.4.1.Buffers. EACH AVM is allocateda set of buffers when IDMS_RUN is called inthe SCL1 NA hook.The numberof buffers isspecifiedon the callto IDMS_RUN or defaults to the valuegiven inthe servrce tables. The IDMS default is 8 ifno other value is specified. When a record is requested the page containing itis read into a buffer unlessitisalready there. When allthe buffers containcurrent pages then IDMS must discarda page to fi'ee a buffer. If the page has been updated thenthe before image must be written tothe QBL orcentral joumal, the after imageto the joumal and the page to the datat>ase. Thus several discwrites maybe incurred if the number of buffersis too small. Sizingthe correct number of buffersis very diffk:ult unless the actk)ns ofall the programs inthe AVM can be takenkito account, so collecting AVM statistrcs using ICL9IDMSAVMSTATS or using a DML trace is probablythe best method. Fromthe AVM statistics the following items are usefiil:- Pages requested/ pages read - the ratioof requests to reads gives some indication of how frequently a page is found in a buffer. Should behigh iif a large number of VIA records are being found; lower if all records are CALC. Delayed update- givesinformation on the nunberofsuccess units that managed to successfully delay updates to end of phase. Bufferusage statistns - information on bufferusage. 6.6.4.2.0verfflow. IDMS overflow is caused normally because a target page is full and a record has had to be relocated to another page. Changingthe keys of CALC records can also also produce a similar effect as the target page produced bythe CALC algorithm will not pointto the page used to store the record but to a relocatkNi tag. Each of the above cases will cause one extra disc transfer to retrieve the record. Use ofthe RANDOM record type instead ofCALC goes a longwayto solving this problem. VIA records can suff^ problems ifthere are too many record stored via a single owner either indifferent sets or one large set. Where several different sets are involved then the storage ofsome of the sets can be altered to duster the records on a different page. This accepts that there wSI be overfk)w but limits its effects to some sets. Where onlyone set is involvedthere is not much that can VTPTUNE V2.0 TPMSPerformanceand Tuning Page 6.47 n Page 6.48 TPMS Performance andTuning VTPTUNE V2.0 ' ^ be done. Indexescan also be the cause ofoverflow, especiallywhenstored viathe owning record. Unbalanced indexes wHh toomany levels can also increasethe number ofdisc lOsdramatically. Overflow can be monitored using IDMSDUMP and IDMS_ST_DB_COLLECT and DISPLAY and monitoring the number of pages 100% full. 6.6^.3Joumals. Different types of journals can affrot the numbers of lOs a success unit Central journals are prob£ibly the least efficient because beforeand after images must be written to the joumal prior to updating the database. Quick BeforeLook filesand area journalsinvolve less discaccessing whilst giving the best compromise on disc space and performance. Duplexedareas and QBL's provide the best performanceas onlybefore images need to be keptbutthis reduces the number ofavailable recovery techniques. Disc space is effectively doubled and the number of ifrivesand controllers is increased so itmay not be a viable option insome cases. 6.6.4.4.Locking. Record lockson IDMS are kept inthe page locktable. The semaphore forthe page locktable has been a source ofcontentioninthe past but the position has been eased at IDMS 510 as the page lock table has been split As each record is normally flagged with an update lock when it is retrieved ifthe success unit is in update mode,frequently retrieved records can be a source ofcontention. Using delayedupdating where records are locked when updated can reduce the contention and delays waitingfor access to records in a servne. 6.6.5.Contention. All file accesses may be delayed by having to queue either for the disc drive or for tiie disc controller. Check the System Monitoroutput to detect anysuch contention. VTPTUNEV2.0 TPMS Performance and Tuning Page 6.49 Communication •VME buffers RC 37560 • Line utilisation •Poor responses ? VTFTSnO Page 6.60 TPMS Performance and Tuning VTPTUNEV2.0 6.7.Communications. 6.7.1.VME Buffers. VME will tryto keep the number ofCOMMS buffers in use to a minimum to save store usage. Thiscan cause problems when sudden peaks occurinmessage throughput. Thisisshown bya result code of37560 inthe TPMSCVM journal when outputting a message to a terminal. VME will increase the numt)er ofbuffers n use and requestthatTPMS re-output the message. Should thisoccur frequently, say oncea minute, theninvestigate the buffers allocated to thesystem. Thismayinvolve sizing the COMMS network and helpshould be obtained from a network performance specialist 6.7.2.Line utilisation. Une utilisatkm is diffk:ult to monitor but poor COMMS performanceis a good pointerto overloaded lines. Ifthe TPMS service statistics show that the response times fromthe servk:e are reasonable but terminal response times are poorthen the network is probablyto blame. Again this requires a skilled networks specialist to investigate the problem. VTPTUNEV2.0 TPMS Performance and Tuning Page 6.51 store •Allocation •Is it needed elsewhere? Quotas •Do we really need the store ? •Workmix •Sum of all TPMS services VTPTe720 Page 6.52 TPMS Performanceand Tuning V7PTUNEV2.0 6.8.Summary. 6.8.1 .Twofurther things alxjut store. We have generally given TPMS as much store as itneeds, proljably to the detriment ofother work units. On heavily loadedsystemsshouldthisbe so?. Thisisa matter for personal choice; the consequences ofnotgiving TPMS the store have t)een laid down i.e VSIs and slowresponse times. Generally, TPMS systems arethekey computer servfces totheend users, andas such depriving TPMS ofstore andIhe resulting consequences are protjably not acceptable. Store iscomparatively cheap and can give dramatk: improvements to the end user service. Following on from this, why set high quotas to TPMS VMs, when at some times the store is not used, and could be better used by MAC and BATCH? Notsetting correct quotas will make the system generally volatile. Little used AVMs will be discardeddown nearer to the RQUOTA specified. When a message an'ives itwill VSI heavily to re-establish itsworking set, causingdiscardson whoever has the store.Thestore can easily"bounce" from VM to VM, even though there issuffk:ient store. Systemsizing is notcoveredinthishandout However, an easy wayto find whetherthe system has enoughstore is to input the correctquotas into the call to DEFINEJ/VORKMIX and see what mode it returns. The store defined for the TPPROD and TPDEVis actually used as a totalfor the servue, and the individual numbers and concurrencies are purelydocumentary: e.g. DFWMCrPPROD=TPXS&200&1/1/500&2/2/300) gives a total of 1300KB for TPPROD and could be written DFWM(rPPROD=TPXS&500&2/2/400) This is usefulto remember as there are limits on the CVM and AVM quota specificatkxis. VTPTUNEV2.0 TPMS Performance and Tuning Page 6.53 Page 6.54 TPMSPerfDrmance and Tuning VTPTUNEV2.0 6.8^.TP Parameter RIe Values 6.8^.1.CTRLDAT UNITTIME Set itno lower than is necessary to check the mostfrequently performed periodk: function. At each tick an event will be caused to the CVM whrch will cause some extra processing. While the CVM is doingthis itcannot be processing messages. FUNC=0&FREQ Sample Scheduler stats every 30 - 60 minutes. FUNC=3&FREQ MAXTIME on messages will be actioned onlywhen this is checked. FUNC=4&FREQ CollectResponder stats onlyonce or twk:e a day. MSGSLOTS Occupy ma^tore. Set no higherthannecessary (see 6.5.11). Extramessage slots won'thelp ifthere are insufficient AVM copies to process the messages! INBUF Don't set higher than is needed forthe longestinput message. Only unprotected fields and start unprotected format effectors are sent OUTBUF Nohigherthan the maximum requirement fora reply, comprising the merged final reply plus any unsolicited output. Be aware that user logging will use OUTBUF. PRESBUF Try to avoid using overflowblocks ifpossible. TLMSG Set to YESand deal with ICL03 messages to clear any terminal & transaction tables maintained. MSGTIME Always set to 0. OVERLOAD Set to REJECTto ensure that control mode messages can be sent to take corrective actions in overload situations. SCRMODS Specifythe mostfrequently used modulesfirstso that they will be found sooner by the template mergingcode. LOG The higher the level specified, the greater the overhead. LOG=SECURE will cause 1 10from the CVM for each message pair. RQUOTA Size correctly. MSGAN Don't use one unless itis unavoidable. Ifyou do need one, use it as a defaultdestinationand use ROUTER or pre-definedmessage tags for most messages. PROCRPLY Try to avoid using one ifat all possible. Every output message will have to be processed by it CPARAMS Ifthere is no requirement for one when the service is implemented create a dummy hook. This will mean that ifyou subsequently require one then you just need to change and compile the SCL procedure rather than repreparing theservk:e. DBSTART As for CPARAMS. DBCLOSE As for CPARAMS. VTPTUNEV2.0 TPMS Performance and Tuning Page 6.55 D Page6.56 TPMS Performance andTuning VTPTUNE V2.0 6.8^^AVMTYPE AVMUM Set to AVMMAX -i-1 (at least). This will incur a small overhead in space required for the PMOD, but will mean that under certain circumstances when an AVM copy has become frozen itwill be possible to create an extra one via control commands. RQUOTA Size correctly. SQUOTA Set equal to RQUOTA or to RQUOTA + 25%. NEVER less than RQUOTA. MSLOTMIN Set equal to AVMMIN. MSLOTMAX See section 6.5.11. MAXPRI Set to 1 for service running in Policy4. (TPMS400 requires patch TP4410). MINPRI Equal to MAXPRI. APARAMS AsforCPARAMS. SCL1NA AsfbrCPARAMS. SCL2NA AsfbrCPARAMS. CX)CPHASE As low as possible. The overiiead in store is significant. Never set above zero ifthe AVMTYPE does not in fact use spooler. 6.8^.3.MT QUEUE For remote MTs which are single phase or first phase of multiphase transactions, set to NO to avoid waiting for resources which are not available. RESPT Affects queuing order. MRECOV Set to ABT if possible. Setting to VMAwill cause an extra write to the slotfile for each input message. RSECURE Set to UPDATE on local enquiries. VTPTUNEV2.0 TPMS Performance andTuning Page 6.57 Likely Causes • CVM •VSIs •User Hooks •AVM •Too few copies ? •VSIs •File / Database problems • File/Database •Buffers •Overflow •Locks •Disc utilisation VTFTB730 Page 6.58 TPMSPerformance and Tuning VTPTUNEV2.0 6.8.3. Likely Causes Of Problems. From experience the most likelycauses of problems for each area are as follows 6.8.3.1.CVM — VSIs Due to incorrect store quotas. — User hooks can cause excessive OCP/VSIs or store occupancy, or disc transfers. 6.8.3.2JWM — Too fewcopies OverloadedAVMTYPE not enough capacity to cope with throughput. — VSIs Due to incorrect store quotas. — RIe problems see below. 6.8.3.3.Hle — Buffers Excessive transfers due to insufficient buffers. — Overflow Excessive transfers due to overflow. — Locks Delays in processing due to file locks. — Disc utilisation Transfer takes too longdue to disc or controllerqueuing. VTPTUNEV2.0 TFMS Performance and Tuning Page 6.59 Page 6.60 TPMS Performance andTuning VTPTUNE V2.0 A. Appendices VTPTUNEV1.2 TPMS Performance and Tuning Appendix A.1 A.1.Bibliography R00460 Volume III Designing a TPMS Service R00461 Volume IV WritingCOBOL Applications For ATPMS Service R00462 Volume V Designing a TPMS Service R00463 Volume V! Specifying a TPMSService as a DDS Model R00464 Volume VII Specifying a TPMS ServiceUsing The ParameterFile R00465 Volume VIII TPMS Service Control And Maintenance R00466 System Management R00475 Programmer's Guide R30314 System Performance VTPTUNEV1.2 TPMS Perfomiance and Tuning AppendixA.3 ) ) ) ) < 1 Queuingtimesfor multiserverqueues 0 m Meantimespentt)yaniteminthequeue S < iAr token to service the c 3 to ^ Item), divkled by the mean service time (O s 1 0 ? 3 c 1 I s 1» i I I 0.9 1.0 A- Facility utilization 1 R" > ui ) ) ) ) < T ?> u T—V Of exceeding certain Hj m 0 < queue sizes in a single^erver queue s cr K> ProbabiUtythat numberof Horns inquMieexoeedBNOndiidinaMamsbetas«hvmI) 1 a o X a (Q Si s s CD g* i I 02 03 04 as ae a? LLLIU Facility utilization • Fbrrandomarrivalliinet • EKponenllal«eivlcaMina. a Single server R- > ) ) ) ) < 2 c ProbalM'lityof exceedingcertain z m < queue sizes ina Iwo^rverqueue K) Probabilityttiat numbarofKami in<|UMiottxoe«(lsNflnctadbigtonttbeing«««d) I H unii iiiiiiiig Fad% utilization Fbnandomarrivaltimm DExponantialMivicatimas• ThrealdanUcalsawefBequallyloaded R* > < 2 c Probability Ofexceeding certain z m S queuesizes ina ttiree-serverqueue K» Probability that number of Items inqueue exceeds N (incfudingItemsbeing served) I H 0.4 0.5 0.6 0.7 as 0.9 1.0 Facility utilization • Forrandomarrivaltimes Q Exponentialservicetimes D Threeidenticalsenwreequallyloaded ) ) ) ) < 2 c Probabilityofexceedingcertain m S queuesizesina four-serverqueue K> PiobabllifyItiat number of inqueueexceedsN (Includingitemsbelnaseived) =a § g I LUIIX 0.9 1.0 • For random arrival times Facility utilization > a Exponentialsendeetimes • F6uridentical equallyloaded mJk CO ) ) ) 2 c z -—-jility of Gxc0GclinQC0rt3in m S queuGsizesin a five-serverqueue io nobabi% that numbarof Hams mquMMMMMtoNPndudlngitafnsbeingaaived) I -I llllliM 0.9 1.0 d FbrnndooianlvaltlmM• Exponential««vle.Iline.Q FhwidenllcalFacility utilization > MivefB equally loaded CD Information and operations notice iCL ICL(UK)Limiled Cuslomcf Services System Sup^xn Ce: Replaces lOS B/133.1 „ oaie Jul 89 ^ B/133.2 Page 1 of 7 Improving TP Restart Tim»o The restarting of a TP service afi-oy reload has two distinct components? - Terminal connection - Loading the TP service I^'thftrarels!®' improvements which can be made I I I I I I howlverf "ill remain reUvanrforsvilo?" 1 • terminal CONNECTIQW Exploitation of Mainstore SE9iS:s=H~SK.. bort"e?worrCol!t^rier''(NTCRrand'l(SCT) from roU?„rouro£ ^oL fhfor'°® Task amount of OCP time everv timo saves an appreciable connection sequence ^his ?= L finished its identified in kel BB811-05442-8 and Llfl-oi532-?? ^%cfand'N;cR"ci{a?oiue^bu£fer''store to Slave catafS^data " ^ the morenumber ION NO. b/133.2 Dated; 11/07/89 bipaam s;?.e'"ss^'sssr~"" •» I i-.: r ! " " ~ ^ *?*S" S» Cy>x: Page 2 of 7 It is necessary to increaco 4-v.^ SCT VMS in order to Improve terminal recommended values areT terminal connection rates. The NTCR terminals QUOTA CATALOGUE SLAVES 0 - 200 I 201 - 400 25 (default) I 401 - 600 100 I 601+ 100 100 CHANGE^TASK? using the QUOTA parameter to Each catalogue slave occupies 2Kb of store. SCT numb^^o? SCT'?ocfrca?f^o|urbufferffljfreas^ The number of buffers is changed by calling! CHANGE_TASK(SCT . GEN = Hex( 110P0F0U9)) ^•2• Hardware Manager achieved by setting th^^tHring'furtte^* "" SI_MAX_HARDWARE_UNITS Which may be specified within the file :*SYSTEMOWNER. ICL9NSUPERVIS0R. AMENDMENTSP ION NO. B/133.2 Datedi 11/07/89 BIPAAM Page 3 of 7 to the next higher prime number. Some suggested prime numbers are; ' ' 2053 . 3001 , 3511 , 4099 1*3. Cataloguing SAPs A typical catalogue structure is; Local hierarchy Remote Hierar.w TP service tper terminal) I Local DISAP I Remote DISAP Local TSAP ' I Remote TSAP Local Coupler « ' I Remote OSLAN Station [ OSLAN J TJie same local liiera*"^"Kvf whenever a terminal conLcts The " selected hierarchy can be improved bv'cat^?« local TSAP with a name that places U at f organised alphabetically eg ® AAADISAP AAATSAP The improvements gained bv thla ~.b.. ot this technique redund^t! improved to make ION NO. B/133 5 ^ ' Dated: 11/07/89 BIPAAM Page 4 of 7 2. loading the TP SERVICE Service Definition For a parameter file-defined service, set MAXPRI = 1 MINPRI = 1 For each AVM type definition. For a dictionary-based service, set *RELATIVE__OCP__PRIORITY 1 ^ Silru; (Sy ^VMs at alower OCP this settijgf the foUowLroccurs:^°"®''^®"^ OCP Priority 1 TP CVM : NTCR : SCT 2 TP AVMs running^t^^TO setting for both loading and S?^^^«tion and roadina c»,., optiaisedIf they wereto^nproie^thriladinror-'gi^al^^*'®'.''''®produced by the svlai Collector!'®" '''%0^"^uiriiSicaUng''ihat'^onlv'®?'hin the file from that ^int oLarlJ " present ''® P®^''t in processing the remain^^Af « thus that there la relevant global areas are alreadC ^LnL ®^^ " 'he only produced by the SV221 Coi?f^» narker is module as follois: Collector, which orders the OMP I.p»r. Therefore there is a sLing in i^dfn^ subsequent AVM copies. loading time for second and to achieve the correct format.s*" "f,"" •«it«••using«•Collector ^ ION NO. B/133.2 Dateds 11/07/89 BIPAAM Page 5 of 7 'i'fiusloading/ ci fromthreesubsequenrAVMstaoe copiest^^®"^ obtain improved a) Normal collection b) AMEND MODULE ( rrnoAr C) Recollection ' Stage a is optional but is considered normal. Catalogue placement- drives.p22?''wiirbnchiLed"'!£" the catalogcatalogue is split over"tes2 discon The catalogue has three files, used as follows: PILE 1 Objects PILEFILE I3 ^®lationshipsHardware The transfers on individual S.rU, 3, „„„ ^ »» • CHUl & CHU2 &CHU3) specifiesWhere CHRl thespecifiesupdate transfersthe ..^riue'l'etc"* parameter^to*COp"cATALOGUE^on*'se^series the VOLUMES parameter to "®^?^ PARTITIONSOn 2900 achieve the same effect. NEW_CATAL0GUE may be used to ION NO. B/133 2 BIPAAM Page 6 of 7 ?P Message Text ModulP VM by tups.400"fnd^?405^hL'"been^relel*^^fl^^ loaded by every TMPS.400 the GLOBAL property was f incorrectly, in extra loading costs and extL incurring both 2900 and Series 39, store occupancy in every VM on In TPMS.405 the global property was 4-1, that only one copy is reauired in ® ensuring process is capable of further by recollection. "^ther improvement from SV221 onwards The GLOBAL property can be set thus (TPMS.400 only): ^ AMENDMODULE(:TPMS0400. ICLSTDSW. ICL9TXTPMSTEXT) ° ' -^^O^AL = VKS) + + + + holding TPMS^software)'" library collector?" later, recollected using the SV221 COLLECT 1^UT(:TPMS0400.ICLSTDSW. 1CL9TXTPMSTEXT\ ICI'9TXTPMSTEXT( +1) ) collection is COLLECT ' TPMS0405. ICLSTDSW.ICL9TXTPmS(+1))ICL9TXTPMSTEXT) ++++ i..n~ no B/133.2 Dated: 11/07/89 BIPAAM Page 7 of 7 2* 5. OMF Block Sizes The loading of a TP service resuife ,•« i being loaded. This is typicallv o transfers. ^ serially in 2Kb block The maximum block size of an OMF library# ^ ^ library controller index limit; that Is^ governed by the RELEASE I MAX OMF BLOCK SIZE T up to SV221 I 6144 from SV231 I 24576 * r N fSs2500the purposesd"evices?%':?6":o:id'bf-ol'space'uauLtton!' «"i"ent for LEVEL a M , ACTION = JLPCOPY) where PROC JLPCOPY IS (INT OMFPILE . PROCBEGIH RESPONSE := FLAG) INT LEN STRING NA^ ,= FILL(100) . NEWNAME GIVE_NAME(OMFPILE . BUFFER = NAME LEMrTH - rp»t amP?odo\e;*o1S:f?le r PROCEND SEQUENCE = NO , LISTLEVEL = NONE) The call to AMEND MODULE may produce warn-{n/« »_ -350io„, andtn.'^LVis%trLTsloa a re«ll^^ / P'oauce warning message number .M. option«. „u. .ho„;rs: sss;rr« iis 2":"??^! ION NO. B/133.2 Dated: 11/07/89 BIPAAM