* copyright (C) 1984-2019 merrill consultants dallas texas usa
Yüklə 28,67 Mb.
|
|
AVGDISMS='AVERAGE*I/O DISCONNECT*MSEC PER SSCH' AVGIOQMS='AVERAGE*IOS QUEUE*MSEC PER SSCH' AVGPNCUB='AVG (MS)*PEND DUE TO*CU BUSY' AVGPNDEV='AVG (MS)*PEND DUE TO*DEVICE BUSY' AVGPNDMS='AVERAGE*I/O PENDING*MSEC PER SSCH' AVGPNSWP='AVG (MS)*PEND DUE TO*SWITCH PORT BUSY' DURATM ='DURATION*OF*INTERVAL' -The ZRBENC dataset supports these new zIIP fields that were added by APAR OA13499: ENCDECP ='DELAY*COUNT*CP' ENCDESUP='DELAY*COUNT*ZIIP' ENCDMSUP='DELAY*COUNT*ZIIP*(MULTI)' ENCSUCT ='ZIIP*ON*CP*TIME' ENCSUPT ='ZIIP*TIME' ENCTSUCT='ZIIP*TIME ON*CP*SINCE*CREATION' ENCTSUPT='ZIIP*TIME*SINCE*ENCLAVE*CREATION' ENCUMSUC='USING*COUNT*ZIIP*ON CP*(MULTI)' ENCUMSUP='USING*COUNT*ZIIP*(MULTI)' ENCUSCP ='USING*COUNT*CP' ENCUSSUC='USING*COUNT*ZIIP*ON CP' ENCUSSUP='USING*COUNT*ZIIP' Thanks to Jerry Urbaniak, Acxiom CDC, USA. Change 24.301 -Yet another "SPLIT70" correction; actual split records VMAC7072 had incorrect NRPHYCPS values in PDB.TYPE70PR because the Feb 2, 2007 PHYSICAL segments came in the second, not first, record. An extra SORT and MEANS were required to correct these values in TYPE70PR dataset. -Variable PARTNCPU was incorrect as it could sometimes still include counts for non-CP engines. -This change also corrected CPU count variables in the ASUM70PR output datasets (ASUM70PR/70LP/CEC/ASUMCELP). -TYPE70PR observations with LPARCPUX=0, an offline LPAR, had values in SMF70WST/LAC/MSU/NSW/PMA that were carried forward because they were not reset. Now, the variables are set to missing values. Thanks to Rudolf Sauer, T-Systems, GERMANY Thanks to Martin Brauer, T-Systems, GERMANY. Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA. ====== Changes thru 24.300 were in MXG 24.11 dated Feb 1, 2007========= Change 24.300 Using the MXG "TAPETEMP" techinque to build PDBs on tape WEEKBLDT without rewind/backspace has worked for years without any WEEKBLDD glitches, but that's because no one had tried to stack WEEKBL3D multiple "WEEK" PDBs in a separate LABEL=(SL,2) tape DSN. WEEKBL3T That caused ABEND A13-10 when the Second Tape Label was MONTHWEK opened. The circumvention required these code changes: MONTHBLS - The MOD in the FILE WEEK MOD .. and FILE MONTH MOD.. MONTHBLD were replaced with new local macro variable &MXGMOD. MONTHBL3 - A %LET MXGMOD=; is inserted BEFORE the first invoke Feb 4, 2007 of either _WEEKBLD or _MNTHBLD, and - After the FIRST invocation of _WEEKBLD or _MNTHBLD, a %LET MXGMOD=MOD; is inserted. The setting of MOD only after the first dataset has been created has circumvented what appears to be a failure by SAS to close the dataset; this logic eliminates the ABEND when you stack multiple PDB libraries in separate tape data sets on a single tape volume. -An alternative circumvention was to create a dataset on the output tape before the first invocation of the build, and then to CLEAR the LIBNAME, as shown below, but the MOD technique is more elegant and more robust. DATA WEEK.MXGDUMMY; RUN; LIBNAME WEEK CLEAR; Thanks to Robbie A. McCoy, Salt River Project, USA. Thanks to Chuck Hopf, Bank of America, USA. Thanks to Rich Anderson, SAS Institute Cary, USA. Change 24.299 Support for z/OS 1.8 changed (COMPATIBLE) to RMM Extract VMACEDGR data: Jan 31, 2007 Dataset EDGGOEXT - New variable ROOWNEML='OWNER*EMAIL*ADDRESS' Dataset EDGGVEXT - New variables RVCAPACI='VOLUME CAPACITY IN MBYTES' RVDCRSID='FIRST FILE CREATION SYSTEM ID' RVDESTBI='DESTINATION BIN NUMBER' RVDESTBN='DESTINATION BIN MEDIA NAME' RVDSNNO ='NUMBER OF DATASETS ON VOLUME' RVEXPTOK='UNIQUE VALUE AT START' RVLABNO1='LABEL NO OF FIRST FILE' RVPERCEN='VOLUME PERCENTAGE FULL' *RVPRERR ='PERMANENT READ ERRORS' *RVPWERR ='PERMANENT WRITE ERRORS' RVRBYSET='VOLUME RETAINED BY SET?' RVSTACKE='COUNT OF VOLUMES STACKED' RVSTACKV='STACKED VOLUME ENABLED?' *RVTRERR ='TEMPORARY READ ERRORS' *RVTWERR ='TEMPORARY WRITE ERRORS' RVVENDOR='VENDOR INFORMATION' RVVOL1 ='VOL1 LABEL VOLSER' RVVWMC ='WRITE MOUNT COUNT' RVWWID ='UNIQUE WORLD WIDE IDENTIFIER' The four *ERRORS fields did previously exist in 4-bytes; they are now 5-bytes, but since they were originally kept as characters, they remain character variables; you can easily convert to a number with NR=INPUT(XXXXERR,5.); -Feb 2: Type H added flag to identify the Date Format (JULIAN, EUROPEAN, AMERICAN), and the GMT Offset. When present, the GMTOFF is used to change the XXXXDATE and XXXXTIME variables to their local values. Thanks to Reinhard Nitsche, GAVI, GERMANY.
BLDSMPDB used to copy/manage the daily/weekly/wtd PDB libraries Jan 31, 2007 for non-SMF data. For example you could build a PDB with TMS and DCOLLECT data and manage it with COPYONLY: %INCLUDE SOURCLIB(TYPSDCOL); %INCLUDE SOURCLIB(TYPSTMS5); %BLDSMPDB(BUILDPDB=COPYONLY); In addition, new option ERASEPDB=NO prevents the deletion of all of the pre-existing datasets in the PDB library, so you could process TMC, DCOLLECT, and SMF data into the day-of-week datasets using %INCLUDE SOURCLIB(TYPSDCOL); %INCLUDE SOURCLIB(TYPSTMS5); %BLDSMPDB(BUILDPDB=buildpdb,erasepdb=no); ====== Changes thru 24.297 were in MXG 24.10 dated Jan 30, 2007========= Change 24.297 Support for optional CMODHEAD='OMEGAMON' CICS segment, IMACICO2 adds duration/counts for ADABAS, IDMS, SUPRA, DATACOM and UTILEXCL a user defined vent. The duration fields are in the new VMAC110 CICS/TS 3.2 format, with 8 bytes for duration. Jan 30, 2007
EXNMONIN monitor from IBM. That product's home page is located at IMACNMON http://www-941.haw.ibm.com/collaboration/wiki/display/ TYPENMON wikiptype/nmon TYPSNMON This is the first iteration, and some of the static info VMACNMON (count of disks, disk names, directory names, etc) was VMXGINIT hand coded for this site's choices, and the startup data Jan 30, 2007 is not decoded yet, so this support will evolve, There is a massive amount of documentation about data values at the NMON web site, so this looks to be a very good data source for AIX and Linux. Dataset NMONINTV contains interval observations with all of the interval metrics that were in the test file. Thanks to Steve Ko, Honda Canada, CANADA. Change 24.295 Support for APAR OA17569, new SMF 14/15 subtype=7 adds VMAC1415 four variables that describe the Key Labels and Encoding Jan 29, 2007 Mechanism for Encrypted Tape Data Sets. SMF14CD1='ENCODING*MECHANISM*KEY 1' SMF14CD2='ENCODING*MECHANISM*KEY 2' SMF14KL1='KEY*LABEL*1' SMF14KL2='KEY*LABEL*2'
VMAC112 in the Omegamon User SMF record supported in TYPEOMCI. Jan 29, 2007 This new record is completely restructured, with changed clocks and counters, but the same twelve datasets are created with most of the same variable names unchanged: DDDDDD MXG MXG DATASET DATASET DATASET SUFFIX NAME LABEL OMCADA OMCIADA OMEGAMON CICS ADABAS DETAIL OMCADT OMCIADAT OMEGAMON CICS ADABAS TOTALS OMCDLI OMCIDLI OMEGAMON CICS DL/I DETAIL OMCDLT OMCIDLIT OMEGAMON CICS DL/I TOTALS OMCDTC OMCIDTCO OMEGAMON CICS DATACOM DETAIL OMCDTT OMCIDTCT OMEGAMON CICS DATACOM TOTALS omcidm OMCIIDMS OMEGAMON CICS IDMS DETAIL omcidt OMCIIDMT OMEGAMON CICS IDMS TOTALS OMCSUP OMCISUPR OMEGAMON CICS SUPRA DETAIL OMCSUT OMCISUPT OMEGAMON CICS SUPRA TOTALS OMCVSA OMCIVSAM OMEGAMON CICS VSAM FILE DETAIL OMCVST OMCIVSAT OMEGAMON CICS VSAM TOTALS ====== Changes thru 24.293 were in MXG 24.10 dated Jan 28, 2007========= Change 24.293 IBM note "Correlating MQSeries Accounting Data to CICS" VMAC116 from 2004 documents that while QWHCTOKN is not populated Jan 28, 2007 in SMF 116 records, MQSeries V5.R2 added QWHCNID which is populated with the NETSNAME/UOWID/UOWTIME data that MXG normally extracts from QWHCTOKN in CICS records. Now, MXG creates NETSNAME, UOWID, and UOWIDCHR from QWHCNID when it is populated. Thanks to Scott Barry, SBBWorks, Inc, USA. Change 24.292 Support for IBM WebSphere MQ V6.0 Open Systems Accounting EXWMQCHS and Statistics is preliminary; this iteration reads the EXWMQMQA output file created by IBM's "amqsmon" program, but the EXWMQMQS support will be changed to read the raw messages from the EXWMQQUA open systems accounting and statistics queues. These EXWMQQUS five data sets are created from either input: IMACWMQA dddddd Dataset Description TYPEWMQA WMQMQA MQIACTNG MQI ACCOUNTING TYPSWMQA WMQQUA QUEACTNG QUEUE ACCOUNTING VMACWMQA WMQMQS MQISTATS MQI STATISTICS VMXGINIT WMQQUS QUESTATS QUEUE STATISTICS Jan 26, 2007 WMQCHS CHNSTATS CHANNEL STATISTICS Thanks to Milt Weinberger, Metropolitan Life, USA
VMAC102 after QW0022VN which was read with $VARYING64. QW0022VL; Jan 25, 2007 IBM writes all 64 bytes, not just the expected QW0022VL length-of-field bytes, so MXG was always misaligned, as QW0022VN is always 26 characters. Now 64-22VN is SKIPed. This was accidentally discovered in SMF data sent for an unrelated question, so I suspect few have used T102S022. Thanks to Rachel Holt, Fidelity, USA. Change 24.290 APAR OA19257 caused invalid and large CPURCTTM values in VMXGRMFI both RMF 72 and SMF 30, APAR OA19282 was a partial fix, VMAC7072 but APAR OA19852 (Feb 7) fixes the error. VMAC7072 The original error causes, among other things, ERROR: VMAC30 NEGATIVE UNCAPTURED-CPU-TIME message when RMFINTRV Jan 26, 2007 processes these data. But the error didn't print the Feb 7, 2007 five components of the CPU72TM, and the message text referenced ancient APARs. The revised message text gives clearer instructions and prints the CPU components. If you find these error conditions, prior to installing the PTFs for the above APARs, you can: a. Correct your PDB library data without rereading SMF with these DATA steps:
CPUTM=CPUTM-CPURCTTM; DATA PDB.STEPS; SET PDB.STEPS; CPUTM=CPUTM-CPURCTTM; CPUTOTTM=CPUTOTTM-CPURCTTM; DATA PDB.JOBS; SET PDB.JOBS; CPUTM=CPUTM-CPURCTTM; CPUTOTTM=CPUTOTTM-CPURCTTM; DATA PDB.SMFINTRV; SET PDB.SMFINTRV; CPUTM=CPUTM-CPURCTTM; CPUTOTTM=CPUTOTTM-CPURCTTM;
b. Correct when your MXG program reads SMF 30 or 70 data records (whether by BUILDPDB, TYPS30, TYPS7072, etc): Insert the below statements before the OUTPUT in the MXG Exit Members (you copy the EXdddddd from the MXG Source into your "USERID.SOURCLIB(EXdddddd)": In member EXTY72GO: CPUTM=CPUTM-CPURCTTM; In members EXTY30U4, EXTY30U5, EXTY30U6, IMACINTV: CPUTM=CPUTM-CPURCTTM; CPUTOTTM=CPUTOTTM-CPURCTTM; Thanks to Pat Curren, Supervalu, USA. Change 24.289 FTP Client Security fields are now added to TYP11903: FORMATS FCCIPHER='CIPHER*SPECIFICATION' VMAC119 FCCPROTE='CONTROL*CONNECTION*PROTECTION*LEVEL' Jan 25, 2007 FCDPROTE='DATA*CONNECTION*PROTECTION*LEVEL' FCLOGINM='LOGIN*METHOD' FCMECHAN=*PROTECTION*MECHANISM' FCPROTBU='NEGOTIATED*PROTECTION*BUFFER*SIZE' FCPROTOL='PROTOCOL*LEVEL' FTP Server Security fields were added by Change 23.146. Thanks to Debbie Shugerts, Verizon, USA. Change 24.288 -Corrections to the sample VTS analyis report. The PUT ANAL94 format for seven variables is $5 in place of 5 as they VMAC94 are character variables. TOTPHYMT includes suffix 2s. Jan 24, 2007 -SMF94VCA is zero after F/C 4001, so it is recalculated Jan 31, 2007 as SMF94VCA=SUM(OF S94VCA41-S94VCA48)/8; when VCA=0. Feb 2, 2007 -Feb 2: $5 changed to $13 to display full DEV name. Thanks to Keith McWhorter, Georgia Technology Authority, USA.
IMACICOM because it was missing the multiply-by-16 to convert the Jan 25, 2007 inputted PIB4.6 value to the correct time units. The missing MQTOTTM=16*MQTOTTM; statement was added; your existing CICSTRAN data is valid if you multiply MQTOTTM by 16.
I could detect an error in your CICS tailoring, at least if you had the optional CANNQ segment, by validating that its expected length of 76 was in fact found as expecte.
fields, and you didn't tailor all of the needed IMACICxx members for all of your optional segments that exist, and if you didn't use UTILEXCL to create an IMACEXCL for your optional CICS segments, then you could have no errors on the log (because MXG can only detect EXCLUDEd fields), but your CANMQ data (in this case) would be trashed as it was read from the wrong part of the SMF 110 record. At least for the CANMQ segment, the length of the segment is contained in the record, so the IMACICOM member that you tailor (by removing the comment block) will detect if it doesn't find the correct length of 76 at the start. Unfortunately, I had to not-ERROR on zero length, as all of the records from an APPLID will have the 76 byte segment, but if the transaction was not involved in MQ, those bytes are all hex zeroes. Although UTILEXCL has always been required for EXCLUDEd fields, it really is required, to be completely safe, even if you ONLY have optional CICS segments, with no excluded fields. If you just manually update all of the IMACICxx members for all of your SEGMENTS, but do not have a UTILEXCL-created IMACEXCL in effect, then the optioal segments are input in the default static order in the IMACICDA member, which applies to ALL of your records, so you could have data out of order, if all regions don't have the same group of optional segments. By using UTILEXCL, its IMACEXCL only calls the right segment for each record, and MXG cannot get out of alignment. In any case, this change will detect an out of order condition, and let you know you need to run UTILEXCL. P.S. Perry's tailoring was correct; in examining the CANMQ data, which appears to be incorrect, I realized the exposure and made this change. Thanks to Perry Lim, Union Bank of California, USA.
VMACTAND to the TANDPROC, provided you still create the "old" data Jan 24, 2007 record format. Thanks to Harriet Sollod, Wells Fargo Bank, USA. Change 24.285 Comments in JCLWEEK were correct that that example is for JCLWEEK building a weekly PDB on DISK, with daily PDBs on DISK, Jan 23, 2007 but the //WEEK DD erroneously had UNIT=TAPE. JCL Example is corrected. Thanks to Lisa L. Lawyer, Lands End, USA.
MXGSASV9 in Change 24.246 was wrong, generating JCL errors that MXGSASV8 EXEC STATEMENT KEYWORDS ARE RESERVED AND CANNOT BE USED. Jan 23, 2007 That REGION=0M belongs on the // EXEC PGM= JCL statement inside the JCL Procedure, and not on the PROC definition. Thanks to MP Welch, SPRINT, USA. Change 24.283 Support for TPF thru PUT19 adds two new datasets VMXGINIT dddddd dataset description EXTPFKC TPFKC EXTPFSB TPFSB VMACTPF and additions to existing datasets: VMXGTPFI - TCPIP Message counters (SXTCPIN) added to SS/SR/ST Jan 23, 2007 - Multiple Systems with Same CPUID supported - Label and KEEP for PUT12 implementation corrected - Update to FF processing for PUT19 (IBM vanilla) - Update SPX PUT15 Dispensed & Returned Counters and new fields added in PUT15. - Added SPXSS for "PS" processing, due to multiple datasets (SPXSS) on FCA. Thanks to Bob Wilcox, EDS, USA. ====== Changes thru 24.282 were in MXG 24.10 dated Jan 22, 2007========= Change 24.282 A new report, "DB2 Storage Analysis" uses IFCID 225 and ANALS225 the DB2STATS dataset to report on storage used by each Jan 22, 2007 DB2 subsystem, above and below the line and above the bar. The report creates an HTML report; the destination must be a PDSE with LRECL=8000, LKSIZE=8004, and required MXG 24.08 or later for the enhanced T102S225 Thanks to Chuck Hopf, Bank of America, USA.
ASMMNVW file; record changes caused MXG to not output any obs EXBBMQAS with the new BMC version. Many new variables are now EXBBMQCF created by this change. EXBBMQDB -BMC's BBMQVSAM record are compressed, and member ASMMNVW EXBBMQQU has the "MNVW" Infile Exit that you install to read BMC IMACBBMQ compressed data, but I did not test for compressed data; VMACBBMQ now, if you try to read compressed records without having VMXGINIT the MNVW exit installed, you'll get an MXG message that Jan 24, 2007 tells you what to do. -Support for 'E6'x QUEUE STATISTICS RECORD creates new BBMQQUES dataset with 187 variables. -Support for 'E7'x DB2 MANAGER RECORD creates new BBMQDB2M dataset with 445 variables. -Support for 'E8'x COUPLING FACILITY RECORD creates new BBMQCFAC dataset with 81 variables. -Support for 'E9'x APPLICATION STATISTICS RECORD creates new BBMQAPPL dataset with 200 variables. -Jan 27: corrected variables with 9-byte names. Thanks to Stuart Wildey, Morgan Stanley, USA. Thanks to Patrick E. Fortune, Morgan Stanley, USA. Thanks to Jeff Sorokin, Morgan Stanley, USA. Change 24.280 An undocumented change in MXG 24.02 corrected variable VMACICE name VDEVNAME to VDEVFDID in dataset ICEBRGUT, and also Jan 22, 2007 revised the text in several variable's labels. This is an INCOMPATIBLE change, if your reports use the old variable name. My apologies: first, for spelling it wrong, and second for not documenting it last year! Thanks to Yves Terweduwe, CIPAL, BELGIUM
EXSAM099 Version 6.x. The new "POOLVOLS" segment appears to have EXSAM100 exactly the same data as the old "LSPACEPO" segment, so EXSAM101 they are OUTPUT in the same SAMSLSPC dataset. EXSAM102 -Support for new SAMS DTOC and eight OBJ02nnn subtypes: EXSAM103 SAMSDT SAMSDTOC SAMS DTOC RECORD DTOC EXSAM119 SAM099 SAMO2099 SAMS 2099 EMC SYSTEMS OBJ2099 EXSAM120 SAM100 SAMO2100 SAMS 2100 EMC CHANNEL DIRECTOR OBJ2100 EXSAM121 SAM101 SAMO2101 SAMS 2101 EMC DISK DIRECTORS OBJ2101 EXSAM122 SAM102 SAMO2102 SAMS 2102 EMC PHYSICAL DEVICES OBJ2102 EXSAM129 SAM103 SAMO2103 SAMS 2103 EMC LOGICAL VOLUMES OBJ2103 EXSAM150 SAM119 SAMO2119 SAMS 2119 IBM ESS SUBSYSTEM OBJ2225 EXSAM225 SAM120 SAMO2120 SAMS 2120 IBM ESS SSIDS OBJ2225 EXSAM227 SAM121 SAMO2121 SAMS 2121 IBM ESS LOGICAL PATHS OBJ2225 EXSAM230 SAM122 SAMO2122 SAMS 2122 IBM ESS VOLUMES OBJ2227 IMACSAMS SAM129 SAMO2129 SAMS 2129 IBM ESS RAID RANKS OBJ2227 VMACSAMS SAM150 SAMO2150 SAMS 2150 IBM ESS PPRC INFO OBJ2227 VMXGINIT SAM225 SAMO2225 SAMS 2225 EMC ALL DEVICES OBJ2227 Jan 19, 2007 SAM227 SAMO2227 SAMS 2227 EMC RDF DEVICES OBJ2227 Jan 28, 2007 SAM230 SAMO2230 SAMS 2230 EMC BCV DEVICES OBJ2230 Jan 31, 2007 Thanks to Mark Daly, CitiGroup, USA. Change 24.278 Further ASUM70PR summarization corrections,redesign: VMAC7072 -In PDB.ASUM70LP dataset, variables LPCTBY/LPCTOV were VMXG70PR slightly wrong (13.087 vs 13.705) with IRD because the Jan 22, 2007 old integer LPARCPUS value was used; now, the actual Jan 26, 2007 average number of CPs online is calculated in the Jan 30, 2007 LPnPREC variables from SMF70ONT/DURATM in PDB.ASUM70LP, and LPARCPUS in PDB.TYPE70PR is unchanged, containing the maximum number of CPs online during the interval. It was only those variables in PDB.ASUM70LP that were slightly wrong; their counterpart variables LPCTnBY and LPCTnOV in the PDB.ASUM70PR dataset were just fine. Note that you cannot use SMF70BDA as it includes the count of CPs plus any IFAs plus ZIPs. -Variable LPnCHG, (Nr CPUs Changed?) is now always blank. The variable was always 'Y' for IRD, and always blank if you didn't summarize in ASUM70PR, and with IRD there's no need, since LPnNRPRC is the average count that interval -CURSHARE and SYSSHARE were corrected for Dedicated CPs. -If all your systems are on the same time zone, GMTOFFTM is valid in the ASUM70PR-created summary datasets, and Change 24.xxx's use of GMTOFFTM to protect setting of the system clock ahead/behind on an active system was fine. Even if you have systems with different GMTOFFTM values (i.e., some systems local, some systems GMT), the system- level PDB.ASUM70PR/PDB.ASUM70LP dataset are fine, but that change was removed for the PDB.ASUMCEC/PDB.ASUMCELP CEC-level summary datasets, where it created invalid and extra observations where there were multiple values of GMTOFFTM in a CEC. With its removal from the BY list, those datasets are now valid; however, the actual value in GMTOFFTM in those two datasets may or may not be the actual GMTOFFTM of the datetimestamps, and there may not be a way for MXG to actually know what that true GMTOFF value is from those two datasets. If this is a problem, please discuss with support@mxg.com, but it should be a minor nit for only a small number of sites. -Jan 30: CURRSHARE corrected for non-IRD managed LPArs. Thanks to Bill McDonald, KCC, USA, for the original error, and, for testing several iterations of this significant exposure: Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA. Thanks to Scott Barry, SBBWorks, USA. Thanks to Al Sherkow, I/S Management Strategies, USA. Change 24.277 The CICS Shutdown Report ANALCISH was revised to support ANALCISH variables dropped by MXG (MNGSYSER and MNGSYSEE), and new Jan 18, 2007 variables MNGRR and MNGRRS were added to the MONITOR Feb 4, 2007 report. A04VADQK moved from SUM= to MAX= and AO4SKINS Yüklə 28,67 Mb. Dostları ilə paylaş:
|