* copyright (C) 1984-2019 merrill consultants dallas texas usa

Change 21.287 Calculation NRCPUS=SMF70ONT/DURATM had value 2.00000040

VMAC7072 when IRD was not in use, and that fractional value had

Jan 25, 2004 impact on PCTRDYWT and CPUUPTM calculations. Calculation

now uses NRCPUS=ROUND(SMF70ONT/DURATM,.001);

to keep three decimal accuracy after that calculation.

Thanks to Al Sherkow, I/S Management Strategies, Ltd., USA.

Change 21.286 Enhancement to support many NDM/Connect Direct subtypes

EXNDMCS that were previously skipped, with/without log messages.

EXNDMEI All known NDMRTYPEs are now recognized and will be output

EXNDMEV in their corresponding NDMxx dataset; those for which I

EXNDMFA could find DSECTS have additional variables INPUT, and

EXNDMIP those for which I had test records have been validated.

EXNDMJX The ACCOUNT/DATASET name offsets are decoded, but the

EXNDMLS offset not yet exploited, since no one has actually asked

EXNDMMF for any of this new data; users just observed the log

EXNDMPE messages that these new types existed in their SMF data.

EXNDMPX Fully Decoded:

EXNDMQE Dataset NDMRTYPEs Output

EXNDMQT NDMPS - PS or SW

EXNDMRE NDMPX - PX

EXNDMRO NDMQE - QE QH QT QW

EXNDMS2 NDMSY - SY: NO DSECT, ADDL DATA EXISTS.

EXNDMSC NDMAE - AE DU,IU,SU,UM

EXNDMSD NDMSD - SD

EXNDMSH NDMCI - CI CE TI JI

EXNDMSP NDMDT - DT SP FT IB SS SN IS IA ID IP IF IX VP

EXNDMSY Header Only Decoded:

EXNDMTR CS FA GO IF JX LS MF NL PE PI RE RO S2 SB

EXNDMUM SC SH SY TP TR WS XO

EXNDMWS The Header Only subtypes are output, but only with header

EXNDMXO variables; MXG prints a message and hex dump of the first

IMACNDM of each new subtype, up to 10 new subtypes. If you have

VMACNDM the DSECT documentation of those Header Only subtypes,

Jan 25, 2004 please send them so I can fully decode those subtypes.

If you want to suppress those MXG messages from NDM, use:

//SYSIN DD *

%LET MACFILE= %QUOTE( RETAIN NDMNEWST 99; );

%INCLUDE SOURCLIB(TYPSNDM.... );

(or you can put that RETAIN NDMNEWST 99; in IMACFILE).
Change 21.285 New NTSMF Objects supported:

EXNTWBSC dddddd Dataset Object

EXNTWSRR NTWBSC WEBSRVCA NT WEB SERVICE CACHE

EXNTWSRC NTWSRR WSRMPRMC NT WSRM PROCESS MATCHING CRITERIA

EXNTWSRY NTWSRC WSRMPROC NT WSRM PROCESS

VMACNTSM NTWSRY WSRMPLCY NT WSRM POLICY

Jan 22, 2004 -New NRDATA=40 in Active Server Pages supported

Feb 18, 2004 -Variables CIINNAME in dataset CITRIXIN and SQBPNAME in

dataset SQLBUFPT were changed from numeric to character,

as they are Instance Name, and their original numeric

definition was wrong. If you build Week-to-Date, or

combine NTSM datasets built before and after this change,

you will get VARIABLE SQBPNAME HAS BEEN DEFINED BOTH AS

CHARACTER AND NUMERIC (or VARIABLE CIINNAME ....).

You must drop the old variable before combining the old

and new datasets.

Thanks to Terry Heim, ECOLAB, USA.
Change 21.284 TYPE99 variables S99TLPI and S99TSPI were 100 times too

VMAC99 large; they should have been input &PIB.4.2 instead of

Jan 22, 2004 &PIB.4.

Thanks to Adam Warkow, Cicigroup, USA.

Change 21.283 TYPE119 Variables UCRPORT/UCLPORT and CTLPORT/CTRPORT are

VMAC119 now kept as Port Number in numeric variables, instead of

Jan 22, 2004 the variables with suffix C (from which they are created,

but which should not have been kept).

Variables UCLLIP and NILLIP's translate statement typos

that had RIP instead of LIP were corrected.

Some labels were also revised.

Thanks to Thomas Heitlinger, FIDUCIA IT AG, GERMANY.

Change 21.282 Change 21.277 created VMXGSUME to tolerate non-present

ASUMDBSB variables, but it ABENDed with several sample ASUM/TRND

ASUMHSM members that ran just fine with its predecessor design.

MNTHDB2S

MNTHDBDS In each case, the VMXGSUM arguments coded in the example

TRNDDB2S were actually in error, and the output dataset created by

VMXGSUME the old version were never correct nor as expected. but

Jan 22, 2004 the old VMXGSUM did not fail.

-ASUMDSDB had DATETIME=QWACBSC, but variable QBACBSC was

not in the SUMBY= argument list. This caused 22-322 and

180-322 errors underscoring DATETIME=&DATETIME with the

new code as only clue as to the real error.

ASUMDSDB was corrected with QWACBSC in place of QWHSSTCK

in the SUMBY.

-ASUMHSM did not create SHIFT in the INCODE for HSMINTRV,

but SHIFT was in the SUMBY, and BY SHIFT was used in the

step after than %VMXGSUM execution. The old design would

create the non-present SHIFT variable, but the design of

the revised VMXGSUM built its SUMBY without SHIFT, so the

VMXGSUM executed correctly, but then the following step

failed when it found no SHIFT variable.

ASUMHSM was corrected to create SHIFT in the INCODE, as

it did in the other steps of that example, with IMACSHFT.
-MNTHDB2S had the token "DATETIME" in the SUMBY list, and

not the correct variable name. Replaced DATETIME in the

SUMBY list with the STRTTIME variable (i.e, the variable

that was in the DATETIME= argument). However, MNTHDB2s

also had two datasteps in the INCODE=, which required a

change to VMXGSUM to support. Finally, however, because

"DATETIME" as a token in the SUMBY= list was the original

recommended syntax for %VMXGSUM, and probably is around

in lots of existing jobs, the enhanced VMXGSUM was again

enhanced, and with this revision:

If "DATETIME" string is in the SUMBY= list, and

it is NOT ALSO the DATETIME= variable name, and

the length of the DATETIME= variable name is not 0,

then the SUMBY uses the DATETIME= variable name

instead of the name DATETIME.

But because the use of "DATETIME" token in the SUMBY

is archaic, and so you know what we've done, there is

a log message that we found this archaic usage.

-MNTHDB2S - Variable QWHSSTCK not found.

-TRNDDB2S - Restructured.

Change 21.281 Support for DB2 Version 8.1, COMPATIBLE. MXG 20.20 or

VMACDB2 later will read V8 SMF 100 and 101 records without errors

Jan 21, 2004 ("MXG 20.20+ TOLERATES DB2 V8"); this change adds support

for the new fields added at the end of existing segments.

New variables in DB2ACCT:

QXCRESEQ='CREATE*SEQUENCES'

QXALTSEQ='ALTER*SEQUENCES'

QXDROSEQ='DROP*SEQUENCES'

QXPRRESI='PREPARES*RESTRICTED*PENDING*INDEX'

QXALTVW ='ALTER*VIEWS'

QLACOFF1='OFFSET TO*REST OF*TRUNCATED*QLACLOCN'

QBGAP1 ='P-LOCK*LOCK REQS FOR*SPACE MAP*PAGES'

QBGAP2 ='P-LOCK*LOCK REQS FOR*DATA*PAGES'

QBGAP3 ='P-LOCK*LOCK REQS FOR*INDEX LEAF*PAGES'

QBGAU1 ='P-LOCK*LOCK REQUESTS'

QBGAS1 ='P-LOCK*LOCK SUSPND FOR*SPACE MAP*PAGES'

QBGAS2 ='P-LOCK*LOCK SUSPND FOR*DATA*PAGES'

QBGAS3 ='P-LOCK*LOCK SUSPND FOR*INDEX LEAF*PAGES'

QBGAWS ='WRITE AND*REGISTER*WAR*REQUESTS'

New variables in DB2STATS:

QBSTLPL ='TIMES WHEN*PAGES ADDED*TO LPL'

QTGSFLMG='FALSE*CONTENTIONS*ENCOUNTERED'

Q3STHWIB='IDBACK*THREAD*HIGHWATER*MARK'

Q3STHWIF='IDFORE*THREAD*HIGHWATER*MARK'

Q3STHWCT='CTHREAD*THREAD*HIGHWATER*MARK'

-Apr 18, 2005: Version 8.1 is "almost" COMPATIBLE; some of

the data fields can be in "UNICODE UTF-8" format; an MXG

ERROR message will be printed if one is encountered, and

MXG 23.03, Change 23.082, supports QWHSLOCN in UNICODE.

-This change also inserted QBGAGG=TBGAGG to correct the

value in QBGAGG.

Thanks to Steve Cunningham, DST Systems, Inc, USA.

Change 21.280 -Variable LGMGEN was input as $EBCDIC8., but that field is

VMACPDSM actually a one byte number with range 1-99. New variable

Jan 20, 2004 LGMGENNR as numeric is now created, and LGMGEN is not.

Jan 23, 2004 -The logic for 'FF'x values and reset to blank values were

removed; that reset is needed for EBCDIC text fields, but

these fields are all $HEX formatted, so changing 'FF'x to

'40'x or '20'x is undesired.

-The FORMAT LGPSRRC LGJRC $HEX1. was changed to $HEX2., as

should be all MXG one-byte character variables containing

hex data; it makes no sense to display just the first hex

nybble. I assumed it was a typo, but a search of all of

MXG found $HEX1 in VMACXXXX, of all places, in VMACIMS,

and in XLOGREC members, which were changed to $HEX2.

However, HEX1. without the dollar-sign is validly used as

an INFORMAT for numeric variables, and was not changed.

Thanks to Peter Lines, RBS, UK.

Change 21.279 Using PROC COPY + SELECT dataset(s) to copy from a tape

DOC data library should specify MEMTYPE=DATA to minimize the

Jan 19, 2004 run time and the I/O resources. PROC COPY with a SELECT

statement without MT=DATA reads the entire tape dataset

(which could be multi-volume!!), and does not stop when

the last dataset in the SELECT list has been found.

Because PROC COPY can copy more than just datasets, it

continues to read for other entries (Graphs, Catalogs)

with the same name. By adding MT=DATA (or MEMTYPE=DATA),

SAS will stop reading the input when the last dataset has

been read, reducing CPU and elapsed time and I/O.

All PROC COPY statements in MXG that copy datasets now

have MEMTYPE=DATA or MT=DATA specified.
Change 21.278 -NTSMF Active Server Pages object has NRDATA=36, was 34,

ADOCNTSM but both new metrics are named "ASP.NET.V1.1.4322", and

EXNTIP4D added at the end of the record. Temp protection reads 34.

EXNTIP4I -Web Service object has NRDATA=86, was 81, with five new

IMACNTSM fields with "COUNTER NAME MISSING" inserted in 4 places.

VMACNTSM Temporary protection added second INPUT for know 81 vars.

VMXGINIT -Four new Objects are supported:

Jan 18, 2004 DDDDDD DATASET Object

NTASPN ASPNET ASP.NET Apps v1.1.4322

NTASPA ASPNETAP ASP.NET v1.1.4322

NTIP4D IPV4SDRV IPSEC v4 Driver

NTIP4I IPV4SIKE IPSEC v4 IKE

-Some recently added new variables, most from new objects,

were not listed in the (required) INFORMAT 16.2 list,

which would cause values to be 100 times too high.

PROC CONTENTS was used to identify those variables with

no informat and the list was updated (although there are

some counters, notably in the headers, that are integers

and correctly do not belong in the INFORMAT 16.2 list.

-Internal notes and instructions describing how to update

the MXG VMACNTSM code to add support for new object and

new variables were revised, and skeleton code examples

added to make my next revision more procedural.
Change 21.277 -VMXGSUME is an enhanced VMXGSUM, designed to tolerate

VMXGSUME dropped variables from a dataset that are expected by an

Jan 17, 2004 invocation of VMXGSUM, if a variable was in the SUMBY=

list, the VMXGSUM execution failed, or if the variable

was in one of the other lists, that variable with missing

value was created in the output dataset. This change

reads one observation of the input dataset and invokes

in INCODE argument to get the full list of all variables

that exist, and compares that with the variables in all

of the VMXGSUM arguments, and rebuilds the SUMBY=, etc.,

to use only the existing variables.

Specific example: Many sites drop OPERATOR from their

CICSTRAN dataset, but ASUMCICS has that variable in its

SUMBY= list, so previously you had to EDIT an ASUMCICS

to remove the references to OPERATOR. Now, that is

done automatically.

-Performance issues if the input dataset is on tape.

There will be multiple tape mounts on the job log; two if

KEEPALL=YES, and three if KEEPALL=NO, as we must open the

input dataset to determine variables that exist.

If this is a single-SAS-data-set tape library, the extra

mounts should not cause any delay, as only repositioning

is needed on real tape, especially if the tape is a VTS.

However, if the input tape data library contains multiple

SAS datasets, on multiple tape volumes, we must at least

open and read the data library sequentially twice to read

one observation, and then a final time to actually read

the full input dataset, and that could cause an increase

in the elapsed time.

You might consider PROC COPY; SELECT xxxxxxx; from tape

to disk before executing VMXGSUM, but initial test show

that is may not be any better, the copy must write the

full dataset with all variables, but VMXGSUM brings in

only the variables it will need, and write is much more

expensive than read.

Adding a PROC COPY step may increase, or may decrease

the execution time.

Note: This is a big performance hit, just discovered:

Always use MEMTYPE=DATA on PROC COPY with SELECT

statement from tape data libraries.

With MEMTYPE=DATA, SAS stops reading the input tape

library when it finds the last SELECTed dataset.

Without MEMTYPE=DATA, the PROC COPY doesn't know

you only want data entries, so it continues to read

the entire tape data library, because there could

be a different entry (Graphs,Catalogs,etc) with the

same name!

Because the enhanced VMXGSUM can cause errors in working

code, it is not used by default anywhere in MXG. But you

can use the enhanced macro defined in the VMXGSUME member

simply by using %INCLUDE SOURCLIB(VMXGSUME); as the first

statement in your //SYSIN stream, as that will compile

the Enhanced-but-named-the-same %VMXGSUM macro that will

be used by SAS for that job.

Change 21.276 Typos caused UNINITIALIZED VARIABLE message for WATSBACT

ANAL116 (s/b WTASBATC) and WTASPSEO (s/by WTASPSE-zero).

Jan 17, 2004
Change 21.275 Reading Active (undumped) VSAM SMF files caused TYPE70PR

VMAC7072 dataset variable SMF70CIN to be blank, which then caused

Jan 16, 2004 variables LPARCPUS, PARTNCPU, and NRIFCPU to be wrong.

The +OFFSMF (needed to read VSAM SMF transparently) was

not added to the OFFCPUID calculation.

Thanks to Melanie Hitchings, BT, ENGLAND.

Change 21.274 Protection for truncated SMF 110 record (LENGTH=76) was

VMAC110 added, testing the APS/ASS triplets before INPUTing the

Jan 15, 2004 rest of the record. Record was truncated because ACS

Jan 21, 2004 rules for Eagle tape drives forced LRECL=80, and the

ACS rule overrode the Model DSCB in the DD statement.

Thanks to Chuck Hopf, MBNA, USA.

Change 21.273 Variable NTLIP, Local IP Address, was incorrect, typo.

VMAC119 The NTLIP=COMPRESS(NTRIP); should have been (NTLIP).

Jan 14, 2004

Thanks to Raff Rushton, Kaiser Permanente, USA.

Change 21.272 Typos corrected; MVSWAIT3=CPUWAITE is MVSWAITE=CPUWAITE

VMAC7072 and MVSWAITW=MVSWAITX is MVSWAITX=MVSWAITX twice.

Jan 12, 2004

Thanks to Hugh Lapham, RCMP, CANADA.

Change 21.271 -Enhancement decodes INSYSAF bit map to create variables

IMACTPMX JBAFF1-JBAFF32 for the System Affinities of each JOB, but

VMACTPMX you must EDIT the IMACTPMX member, which now defines two

Jan 11, 2004 formats ($MXTPMPX and $MXTPMBT) that map your SYSTEM IDs

Jan 12, 2004 to your SYSPLEXes, and that maps the bits in INSYSAF for

Jan 13, 2004 each SYSPLEX to the AFFINITY SYSTEM's name. If you do

Jan 20, 2004 not update your IMACTPMX, the values in JBAFFn variables

Jan 22, 2004 will be wrong, or more likely, always blank.

-The INPUT(INSYSAFF,$EBCDIC)/TRANSLATE statements for the

INSYSAFF were deleted: i.e., it was "un-EBCDIC'd". That

pair of functions are used only for variables containing

EBCDIC text characters. INSYSAFF contains hex bit string

data as characters, and is formatted $HEX8.

-Variables NRACCTFL and ACCOUNT1-ACCOUNT9 are now created

from the ACCT field, decoding with your IMACACCT member

that determines how many fields are actually kept. As

old variable ACCT contains both binary numbers and EBCDIC

text, it is "un-EBCDIC'd", and is formatted $HEX32.

-CURREC5, current time of day, was incorrect; it is now

input as hhmmssth in four PK1. fields, and converted to

a SAS time value and formatted TIME12.2. I created new

variable CURRENT from CURRECn, but then found it was

exactly equal to SMFTIME, so I chose to not keep CURRENT.

-Variable JALSYJ is not labeled; it appears to be the

same as SYSTEM.

-Variable RD is not labeled; it has value 'NC' in five obs

and is blank in the other five thousand observations.

-Variable RDRDATE is formatted DATE9.

-In testing, you cannot set OBS= to less than 634, because

there are 634 input records for the CNTLLIN for the token

table look up. You get TOKEN NOT FOUND with OBS=100.

-Variables JTSDATE and JTSTIME were missing because their

informats were incorrect; now they are populated.

-Variable CA7DD was incorrectly input.

-Variable CA7DT was created as a character variable, but

that field is a time duration, so variable CA7DTM is now

created as numeric and formatted. I cannot change CA7DT

from char to numeric without causing someone's perfectly

running weekly or monthly job that combines TPMX data to

ABEND due to a variable conflict, and since CA7DT was not

ever correct, it can safely be replaced by CA7DTM.

-Variables CA7JCL, CA7SCHID formatted Z3. to print 001.

-Variable CPU FORMATed TIME12.2.

-Variable CURPRIO now INPUTs only first for bits.

-Variables DISPLD1 formatted DATE9, DISPLD2 corrected.

-Variable INPRIO input BITS4.0.

-Variable INRMT is input $EBCDIC8, but the field changed

to numeric in 5.2.1; new numeric INRMTNR variable is now

created and input PIB.2., but INRMT is still created.

-Variable INSEI input $EBCDIC8 instead of 4.

-Variable JXCPUCA should have been name of JCXPUCA; both

variables now exist, but use only JXCPUCA.

-New variables JES3M26,JESM27,JES3M28 and JES3M29 were

replaced with JLSENQ, JLSENQN, JLSLIMTT and JLSLIMTN,

as they had nothing to do with JES3.

-User character variables TPMUC1-TPMUC99 and user numeric

variables TPMUN1-TPMUN99 are now supported, but none are

kept by default; you remove comments in the EXTYTPMX to

choose which user variables you want kept, and you code

LENGTH and FORMAT statements for character variables to

control their stored lengths and protect any $HEX data.

You also blank out the variable's name from the DROP code

in that member. The example also shows how you can

create variables from any binary fields in your character

fields, and how to use MACRO _KTYTPMX to also keep them.

Thanks to Lawrence Jermyn, Fidelity Systems, USA.

Thanks to Kelly Vogt, Humana, USA.
Change 21.270 Short CMRDETL record caused INPUT STATEMENT EXCEEDED

VMACMVCI and STOPOVER condition; test now validates the record

Jan 8, 2004 is at least 277 bytes, prints error messages and dump of

first two short records, but no longer ABENDs.

Thanks to Mike Kevlin, CSC, AUSTRALIA.
Change 21.269 -Support for many new TNG objects from AIX, NT,and SOLARIS

EXTAI013 dddddd dataset description

thru TAI013 AI013 CA CPU GROUP

EXTAI024 TAI014 AI014 CA DISK GROUP

EXTSO016 TAI015 AI015 CA FILE SYSTEM

thru TAI016 AI016 CA INTERFACE GROUP

EXTSO026 TAI017 AI017 CA KERNEL CONFIG GROUP

FORMATS TAI018 AI018 CA KERNEL GROUP

IMACTNG TAI019 AI019 CA MEMORY GROUP

VMACTNG TAI020 AI020 CA NETWORK GROUP

VMXGINIT TAI021 AI021 CA PER CPU GROUP

Jan 6, 2004 TAI022 AI022 CA SWAP GROUP

Jan 7, 2004 TAI023 AI023 PRINTER QUEUE

Jan 14, 2004 TAI024 AI024 USERS

TSO016 SO016 CA CPU GROUP

TSO017 SO017 CA DISK GROUP

TSO018 SO018 CA FILE SYSTEM

TSO019 SO019 CA INTERFACE GROUP

TSO020 SO020 CA KERNEL CONFIG GROUP

TSO021 SO021 CA KERNEL GROUP

TSO022 SO022 CA MEMORY GROUP

TSO023 SO023 CA NETWORK GROUP

TSO024 SO024 CA PER CPU GROUP

TSO025 SO025 CA SWAP GROUP

TSO026 SO026 USERS

TNT051 NT051 NTMSSQL$IN01:ACCESS ME

TNT052 NT052 NTMSSQL$IN01:BUFFER MA

TNT053 NT053 NTMSSQL$IN01:BUFFER PA

TNT054 NT054 NTMSSQL$IN01:CACHE MAN

TNT055 NT055 NTMSSQL$IN01:DATABASES

TNT056 NT056 NTMSSQL$IN01:GENERAL S

TNT057 NT057 NTMSSQL$IN01:LATCHES

TNT058 NT058 NTMSSQL$IN01:LOCKS

TNT059 NT059 NTMSSQL$IN01:MEMORY MA

TNT060 NT060 NTMSSQL$IN01:SQL STATI

TNT061 NT061 NTMSSQL$IN01:USER SETT

TNT062 NT062 NTMSSQL$IN01:BACKUP DE

NOTE: DATASETS NT051-NT062 CONTAIN DATA

FOR ALL SERVER='IN01' thru 'IN07'

Twelve MSSQL Server Objects are created for each unique

Server Name ("IN01"-"IN07"), so with 7 servers there are

84 unique objects, but only twelve datasets are needed.

Datasets NT051-NT062 contain data for all servers, with

variable SERVER="IN0n" identifying the server.

Capturing the server name from object name, and mapping

84 objects to 12 datasets required new algorithms, and

this implementation is specific to those server names.

Arrays nt063-nt134 are used for "IN02"-"IN06".

-The array sizes directly impact the REGION size needed.

Now, you can change array sizes directly with %LETs in

SYSIN, before the %INCLUDE SOURCLIB(TYPSTNG); statement.

One very large NT site, had to set:

//SYSIN DD *

%LET NT005I=21;

%LET NT007I=999;

%LET NT013I=75;

%LET NT014I=625;

%LET NT017I=625;

%LET NT035I=2000;

%INCLUDE SOURCLIB(TYPSTNG);

This works now, because all of the TNG macro variables

(MAXROWS,AInnnI,AInnnV,NTnnnI,NTnnnV,SOnnnI,SOnnnV,etc)

definition %LETs were moved to VMXGINIT and GLOBALed.

You cannot use %LET MACTNG= to redefine the array

size macro variables; you can't %LET a %LET. You can

define a MACRO _MYSIZE %%LET NT035I=2000; % and use

%LET MACTNG= _MYSIZE ; %INCLUDE SOURLIB(TYPSTNG); ,

but you cannot define MACRO _MYSIZE in your SYSIN

stream - that causes a recursion error.

-By default TYPETNG reads all cube types, and MXG default

array sizes (set so that I can read all test data sent

thus far) requires a REGION=225M. Region is NOT a real

resource, but some sites artificially constrain REGION

size. You can save some virtual storage by reading only

one cube type at a time, and also using MACTNG to specify

the _AIONLY, _SOONLY, or _NTONLY macro, to set unwanted

array sizes to a value of one.

//SYSIN DD *

%LET MACTNG= _NTONLY ;

%INCLUDE SOURCLIB(TYPSTNG);

With _NTONLY REGION=120M

With _SOONLY REGION= 66M

With _AIONLY REGION= 30M

-SAS V8.2 and MXG 21.07 defaults required REGION=100M on

z/OS 1.4; the same program used 86M Total Memory when run

with SAS V9.0 under Windows 2000.

-If there are any observations in the UNKNOWN dataset, it