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



Yüklə 28,67 Mb.
səhifə285/383
tarix17.01.2019
ölçüsü28,67 Mb.
#98988
1   ...   281   282   283   284   285   286   287   288   ...   383

Apr 1, 1997 ZERO error, so protection was added to protect PGINRATE:

IF DURATM GT 0 THEN PGINRATE=MONPGIN/DURATM;

These zero duration records occurred under MVS/ESA 5.2.2

and have strange values for SWAPDLUS and SWAPDLIC but

other variables have reasonable values, and the STARTIME

was 15:20:00.00, SYNCTIME 14:27:54.81, and the SMFTIME

was 15:27:59.91, so why DURATM is zero is unknown.

Thanks to Martin Peck, CA-IT/BM, AUSTRIA.


Change 15.039 IBM's "MVS PSF DOWNLOAD" product created invalid SMF type

VMAC6 6 records (SMF6LN3/SMF6LN6 are located two bytes beyond

Apr 1, 1997 where they should be). APAR OW23937 reports the error,

and PTF UW34926 corrects the error, but bad records can

be read by MXG by conditionally INPUTing the two LENx

fields as PIB4 instead of PIB2 by inserting:

IF LENGTH=274 THEN INPUT @OFTONXT SMF6LN3 &PIB.4. @;

ELSE


before the existing:

INPUT @OFTONXT SMF6LN3 ..... statement

and by inserting

IF LENGTH=274 THEN INPUT @OFTONXT SMF6LN6 &PIB.4. @;

ELSE

before the existing:



INPUT @OFTONXT SMF6LN6 ..... statement

NOTE: This Change was NOT made to MXG Software, but is

only printed here for temporary circumvention to read

records created prior to the installation of the PTF.

Thanks to Hal Merritt, Texas Commerce Bank, USA.
Change 15.038 -Dataset TYPE72GO variable R732CIRC is now R723CIRC to be

VMAC7072 consistent with other subtype 3 type 72 variables.

Apr 1, 1997 -The calculation of NRPTRANS was incorrect, which also

caused the calculation of PERFINDX for Percentile Goals

to be incorrect.

The equation that was: NRPTRANS=TRANS*TRANEXEC/100;

is now: NRPTRANS=TRANS*R723CPCT/100;

-IBM's RMF report calculation of PERFINDX for Percentile

Goal Service Classes can be wrong, producing a value that

is greater than true, especially when the number of TRANS

is small. IBM sums transactions until the sum is GT the

percentage goal, but the definition in the SRM (and now

in MXG) should stop when the sum is GE. For example,

with 10 transactions and a 70% goal value

bucket: 1 2 3 4 5 6 7 8 9 10 11 12 13

RTSMAP: .5 .6 .7 .8 .9 1.0 1.1 1.2 1.3 1.4 1.5 2 4

RTSTRN: 3 0 1 2 1 0 1 0 0 0 0 1 1

RMF counts to the 7th bucket, setting PERFINDX=1.1, but

MXG and the SRM stop at the 5th bucket, PERFINDX=.9,

because 7 out of 10 transactions did meet the goal!

The equation IF SUMPTRAN GT NRPTRANS THEN DO;

was changed to IF SUMPTRAN GE NRPTRANS THEN DO;.


-26Jun97: The following error was originally documented

here in April, 1997, but now has been corrected by APAR

OW26609. See MVS Technical Note 22 in Newsletter 32:

Variable R723CIRC appears very right in lots of cases,

but is very wrong in some Service Class data (notable,

TSO, which has multiple periods) when compared to

TYPE30 interval data. This is still under investigation

but it is most likely an IBM error in RMF

daccumulation in multiple period service classes for

this new variable. The numbers on the RMF report look

fine, because RMF only prints the avg time per I/O

(R723CICT/R723CIRC); it looks like both fields are each

wrong! For 5 periods of TSO in a 30 minute interval:

R723CIRC R723CICT R723CIWT R732CIDT ACTIVETM TRANS

23179776 15:45:17.81 2:18:18.80 6:23:29.81 0:01:28 1309

177746 0:07:53.98 0:01:07.03 0:03:24.63 0:01:22 358

342664 0:13:54.80 0:02:06.71 0:05:55.51 0:04:44 378

10639 0:00:29.34 0:00:04.83 0:00:02.56 0:00:49 10

5180 0:00:13.68 0:00:01.76 0:00:00.94 0:02:19 6

That is 16 hours of connect time in 30 minutes (or 32

I/O concurrently transferring data during the entire

interval) or is 13,000 SSCH per second? I think not!

Clearly, APAR OW26609 must be installed to correct!

Thanks to Don Deese, (CPExpert), Computer Management Sciences, USA.

Thanks to Dale Mattison, Shared Medical Systems Corporation.
Change 15.037 The INPUT of TYPE116 variable QWHCTNO must be changed

VMAC116 from &PIB.4. to &NUM.4. (since the value is an EBCDIC

Mar 29, 1997 number) and the INPUT of variable QWHCTASK must be

changed from &PIB.4. to &PD.4. But see Change 15.043.

Thanks to Helmut Roese, COM GmbH, GERMANY.
Change 15.036 Duplicate.
Change 15.035 The INPUT of TYPE80A variable ACEEUSER was increased from

VMAC80A $VARYING20. to $VARYING30., as data of length 25 was

Mar 29, 1997 found at one site, and an MXG note prints on the SAS log

if a longer length string is found in your data. lmut

Thanks to HeRoese, COM Gmbh, GERMANY.
Change 15.034 CICS Statistics variable A08BKHSW must be INPUT &PIB.2.

VMAC110 and +2 instead of &PIB.4., as it is only a half-word that

Mar 29, 1997 is followed by two reserved bytes.

Thanks to Helmut Roese, COM Gmbh, GERMANY.


Change 15.033 Change 12.264 for IMF variables ABENDSYS and ABENDUSR was

VMACCIMS only correct for old IMF 1.2, and only for ABENDSYS. The

Mar 29, 1997 revised algorithm to decode the two intermingled fields

(stored as xxSSSUUU in four bytes) now reads:

@117+OFFIMS +1 /*SKIP OVER XX OF XXSSSUUU: */

@118+OFFIMS ABENDSYS &PIB.2. /*OVERLAY 117 118 119 120 */

@119+OFFIMS ABENDUSR &PIB.2. /* XX SS SU UU */

/* +1 ABENDSYS */

. /* +1 +1 ABENDUSR*/

The first byte is skipped, the second two bytes are input

into ABENDSYS as PIB2., the third and fourth bytes are

INPUT in ABENDUSR as PIB2. Then, after the INPUT ends,

in both the old 1.2 and later 1.3 groups, this code:

ABENDUSR=MOD(ABENDSYS,16)+ABENDUSR;

ABENDSYS=FLOOR(ABENDSYS/16);

creates ABENDSYS=0013x and ABENDUSR=0000x from 00013000x

(ABENDUSR must be done first, because it uses ABENDSYS

which then stores into itself).

Thanks to M. Nicolas, BNP, FRANCE.
Change 15.032 Variable SERVUNIT was only length 4 in PDB.STEPS and in

BUILD005 PDB.SPUNJOBS, but it should have been length 5 (since

BUIL3005 Change 14.214). The LENGTH statement following PDB.STEPS

BUILDPDB now has SERVUNIT 5 added in the BUILxxxx members,

BUILDPD3 as does the LENGTH statement following PDB.SPUNJOBS in

SPUNJOBS member SPUNJOBS.

Mar 27, 1997

Thanks to Trevor Ede, Bank of New Zealand, NEW ZEALAND.


Change 15.031 Warning message that datasets WORK.INTxxx don't exist is

BUILD004 because the datasets were deleted in both CICINTRV and

BUILDPDB the BUILD004/BUILDPDB/BUILDPD3 members. Since these are

BUILDPD3 CICS only datasets, the DELETE belongs in CICINTRV and

Mar 27, 1997 they are removed from the DELETE in the three BUILDxxx

members.


Thanks to Martin Peck, CA-IT/BM, AUSTRIA.
Change 15.030 When SOFTAUDIT is enabled to collect data only at the JOB

VMACSFTA level, the record is only 115 bytes long, so the test

Mar 27, 1997 IF LENM=131 THEN DO; must be changed to:

IF LENM=115 OR LENM=131 THEN DO;

Thanks to Rick Green, Comerica, Inc, USA.
Change 15.029 -Error in MXGCHAN macro caused RMF Channel Reports to fail

ANALRMFR with a syntax error. The statements &PDB..TYPE73 ; and

Mar 27, 1997 &&PDB&I...TYPE73 ; must have those semicolons removed.

-All of the "PROC PRINT"s and their TITLE statements

should have been deleted (they were debugging prints) to

save paper (or at least SPOOL space!).

Thanks to Michael Creech, Alltel Information Services, USA.
Change 15.028 Variable RVDSNAM1 (FIRST FILE*DATASET*NAME) is now INPUT

VMACEDGR (immediately after RVMEDATR) and kept in RMM dataset

Mar 27, 1997 TYPEEDGR; I'm not sure when this field was added by IBM.

Thanks to Ben Cowan, UCCSN System Computing Services, USA.


Change 15.027 NTSMF discovered new objects created by COMPAQ so four

EXNTCMBU new datasets are now created from these objects:

EXNTCMCN CMPQBUSU Compaq EISA/PCI Bus Utilization

EXNTCMDV CMPQCTLR Compaq 32-Bit SCSI-2 Controllers

EXNTCMNF CMPQDEVS Compaq 32-Bit SCSI-2 Devices

IMACNTSM CMPQCMNF Compaq NetFlex-3 Network Driver

VMACNTSM I note that the Controllers record appears to have a per-

Mar 26, 1997 controller record with CTRLNAME containing the name of

Apr 28, 1997 the controller (eg. \\.\Scsi0) and a second interval

record with CTRLNAME blank (which I assume is an interval

total, but have not had two controllers' data for

verification). Revised Apr 28: NTSMF Version 2.0 adds

two new fields NTVERSN (NT VERSION, 4.0) and NTVERSP (NT

SERVICE PACK, SPK1) to the header of each NTSMF record.

The variables are kept in the PROCESOR dataset and in

dataset NTINTRV (although they will be blank until you

install NTSMF Version 2.

Thanks to Richard Clary, Entergy, USA.


Change 15.026 The new VELOCITY calculation for OS/390 Release 3

VMAC7072 includes I/O delay time if it was enabled (see Change

Mar 25, 1997 14.318), but some sites may need to know the old or new

May 29, 1997 velocities before they are enabled, so two new variables

were introduced:

VELOCCPU 'CPU ONLY*EXECUTION*VELOCITY'

VELOCIOD 'I/O DELAY*EXECUTION*VELOCITY'

and are kept in both TYPE72 and TYPE72GO datasets. The

variable VELOCITY will continue to contain the actual

velocity, and variable R723VELI='Y' will flag whether or

not the value of VELOCITY contains I/O DELAY time.

Text of this change was incorrect until May 29, 1997, but

the above change was made to the code in March.

Thanks to Cheryl Watson Walker, Watson & Walker, USA.


Change 15.025 A typo had real impact - variable BATCHMAX was renamed to

TRNDRMFI MATCHMAX. The correct spelling is BATCHMAX.

Mar 25, 1997

Thanks to Dave Schultz, First Card, USA.


Change 15.024 A typo had minor impact - a FORMAT statement was absorbed

TYPEIMSB as a comment because a comment was not terminated. The

Mar 25, 1997 INFILE IMSSUMS0 END=END; /* comment .... text *

should have ended with */

Thanks to Kristyann Manske, University of Wisconsin-Milwaukee, USA.
Change 15.023 TYPE70 variable PCTMVSBY was wrong (although it did match

VMAC7072 IBM RMF report values) for Amdahl MDF domains with some

Mar 25, 1997 shared and some dedicated CPUs. The MXG equation was

(CPUUPTM-MVSWAITM)/CPUUPTM=58:56-16:00/58:56=43/59=72.8%,

but that assumed the total dispatch time of all CPUs was

CPUUPTM=NRCPUS*DURATM or 59 minutes, when in fact the

true dispatch time was only 46 minutes, and the true CPU

busy time was 30 minutes, and not 43 minutes as shown

below:
The MDF partition had DURATM=14:44.05 with CPUs 0 and 3

given 100% target allocation but CPUs 1 and 2 were shared

with only 55% target allocation for this partition:
LCPUn CPUPDTMn CPUWAITn MVSWAITn MVSBUSYn

0 14:43.99 5:42.42 5:42.37 9:01.62

1 8:35.56 8:22.62 2:14.13 6:21.43

2 8:35.18 8:19.20 2:10.34 6:24.84

3 14:43.92 5:53.71 5:53.59 8:50.33
CPUPDTTM CPUWAITM MVSWAITM CPUACTTM

total 46:38.65 28:17.97 16:00:43 30:38.22


CPUACTTM has 30:38 minutes of actual CPU seconds for the

partition, and CPUPDTTM has 46:30 minutes of dispatch,

so the true PCTMVSBY (percent of dispatch time when this

MVS was busy) is 30/46 or 65.7% (versus IBM's 72.8%) so

the revised MXG equation is now:

PCTMVSBY=100*CPUACTTM/CPUPDTTM;

(IBM footnotes that their value is the arithmetic mean,

which if correct if each LCPU is dispatched equally as

is the case with their PR/SM, so they implied you should

be wary, but apparently IBM won't modify its RMF reports

for MDF idiosyncrasies - but MXG does!).
The variable CPUUPDTM (total partition dispatch time) is

also now calculated and kept in TYPE70 dataset.


This site also enabled the old Amdahl MDF option "Wait

Complete=No Reporting" (see Change 12.289), but that

option appears to be useless when engines are shared

between domains; while the real CPU usage is known, that

option loses the domain dispatch time, so you can never

know what was the capacity available to each

domain/partition.

Thanks to Kirk Poore, Union Electric, USA.


Change 15.022 Old HP-PCS and new HP-MW code still had date litterals of

VMACHPAI JAN70 (the epoch of the Unix Clock) that are now changed

VMACMWAI to JAN1970. (With YEARCUTOFF default, SAS would have set

Mar 19, 1997 the correct date, but it is MXG's intention to support

the year 2000 intrinsicly, rather than thru YEARCUTOFF).

Thanks to Graeme Yeandle, British Telecom, ENGLAND.


Change 15.021 -Variables EDGSADTE and EDGSARSD are added to DATE9 format

FORMATS and the ELSE was removed from ELSE IF after the INPUT of

VMACEDGS EDGSAFLG in the ID=_IDEDGUS logic block (because records

Mar 19, 1997 from SMF were not INPUT due to the extraneous ELSE).

Mar 29, 1997 -Variable EDGSASID must be input as $EBCDIC4. instead of

$EBCDIC8. in the EDGSSECU dataset - not only was EDGSASID

wrong, but all following fields were too, but fortunately

the EDGSSECU data set is just now being investigated!

-Value 18:SAF CALL was added to the MGACFDA format in

member FORMATS for ACF2.

Thanks to Pete Young, University of Toronto, CANADA.
Change 15.020 JES3 BUILDPD3 created additional PDB.JOBS/PDB.STEPS obs

BUILDPD3 that contained only TAPEMNTS TAPFETCH SMFTIME, because

BUIL3005 multiple TYPE25 observations were inadvertently created.

Mar 19, 1997 In the logic following DATA ONE25;, find the statement

TAPEMNTS=MOUNT; and insert the statement OUTPUT;

immediately following (and before the END;).

Thanks to Neil Musitano, Jr., Department of Veterans Affairs, USA.
Change 15.019 Variable ULOGADAE was changed to be INPUT as &PIB.4.3

VMACCOMP in only one statement, but there were two overlooked

Mar 19, 1997 statements for ULOGADAE that are now also changed.

Thanks to Jens Schlatter, Independent Consultant, GERMANY.


Change 15.018 -The Label for dataset TYPE8011 should be ALTDSD and not

VMAC80A ADDUSER.

Mar 19, 1997 -Variable USERID was inadvertently removed from TYPE8014

dataset in MXG 14.14, so USERID was added to KEEP= list

for dataset TYPE8014, and the 1st occurrence of USEROWNR

after ELSE IF RACFEVNT=14 THEN DO; after WHEN (6) was

changed back to USERID, so both USERID and USEROWNR will

be kept in TYPE8014 dataset.

Thanks to Jens Schlatter, Independent Consultant, GERMANY.
Change 15.017 Support for CA-ROSCOE Version 6 SMF Record has been

VMACROSC verified (i.e., the V6 records do not cause MXG to fail

Mar 18, 1997 although I have not yet verified with the DSECT).

Thanks to Bob Bunt, NYSEG, USA.


Change 15.016 Support for CA-DISPATCH Version 6 and five-digit JESNR.

IMACCADI CA relocated the five-digit JESNR to a new area at the

VMAC6 end of the record, and new fields CADIARCH and CADIBUND

Mar 14, 1997 are now created (only if you enable CADI support in the

IMACCADI tailoring member).

Thanks to Kenton O'Brien, Barclays, ENGLAND.


Change 15.015 Support for Anacom's Anastack product (spools data to

VMAC6 microfiche, etc.) which writes a type 6 SMF record. The

Mar 14, 1997 record is an "External Writer" record (DEVICE='EXT WTR')

so many of the JES-only and PSF-only fields will be

missing, but the event, JOB, and number of lines are

captured. No code was changed in MXG, since external

writer records are already supported.

Thanks to Dave Crandall, Farmers Group, USA.


Change 15.014 Change 14.245 (added variables to some BY statements to

WEEKBLD better protect for duplicate SMF records in BUILDPDB) was

WEEKBLDT not fully implemented in WEEKBLD and WEEKBLDT, so the BY

Mar 12, 1997 lists are not exactly the same, but there should be no

execution error. Now, the BY lists are consistent.

Thanks to Tom Parker, Hogan Systems, USA.


Change 15.013 Variable SSTORE72 (Shared Pages Bytes) is now created in

VMAC7072 dataset TYPE72GO, for consistency with variables

Mar 12, 1997 CSTORE72 ESTORE72 TSTORE72 that were added earlier.

Thanks to Bruce Widlund, Merrill Consultants, USA.


Change 15.012 -NTSMF records from NT 3.51 for SQLSERVER, SQLSERVER-LOCKS

IMACNTSM and SQLSERVER-LOG have fewer fields than NT 4.0; now that

VMACNTSM I have raw records, MXG was enhanced to support these NT

Mar 12, 1997 3.51 records.

Thanks to Richard Clary, Entergy, USA.
Change 15.011 Variable SMF744PN was added to dataset TYPE74CF to count

VMAC74 the number of processors in this Coupling Facility. You

Mar 11, 1997 you could have derived the number from CFNUM01-CFNUM16,

by counting, but you should not have to!.

Thanks to Rick Poliak, Amdahl, USA.
Change 15.010 Support for Landmark's "Performance Works/Smart Agents

ADOCPW for UNIX" dumped output (see ADOCPW for syntax of their

EXPWACCT dump command) creates twenty new PWPxyyyy datasets:

EXPWCPUP From Product Detail records:

EXPWDEVD Dataset Name Description

EXPWDEVS PWPDACCT PROCESS ACCOUNTING

EXPWFSL PWPDFSL LOCAL FILE SYSTEM CAPACITY

EXPWFSR PWPDFSR REMOTE FILE SYSTEM RECORD

EXPWMESS PWPDPD PROCESS DETAIL

EXPWNCO PWPDPDI PROCESS DETAIL INTERVAL

EXPWNIND PWPDPDS PROCESS SUMMARY

EXPWNINS PWPDPGM PROGRAM RECORD

EXPWNSO PWPDTERM TERMINAL SUMMARY RECORD

EXPWPD PWPDUFSQ QUOTAS RECORD

EXPWPDI PWPDUFSS USER FILE SYSTEM STORAGE

EXPWPDS PWPDUSER USER SUMMARY RECORD

EXPWPGM From Product Interval records:

EXPWPI Dataset Name Description

EXPWTERM PWPICPUP PROCESSOR RECORD

EXPWUFSQ PWPIDEVD DEVICE USAGE INTERVAL

EXPWUFSS PWPIDEVS DEVICE USAGE SUMMARY

EXPWUSER PWPINCO NFS CLIENT OVERVIEW

IMACPW PWPININD NETWORK INTERFACE INTERVAL

JCLPW PWPININS NETWORK INTERFACE SUMMARY

TYPEPW PWPINSO NFS SERVER OVERVIEW

VMACPW PWPIPI SYSTEM SUMMARY RECORD

Mar 11, 1997 From Product Log records:

Dataset Name Description

PWPLMESS CONSOLE MESSAGES TEXT

Landmark's initial response to documentation was to use

the "ODBC" interface to their database, but this could

only work if you intended to run SAS on the UNIX system

you are measuring, so MXG's more general solution is to

use their ASCII dump of the data store, so you can ship

the raw ASCII data (convert to EBCDIC during transfer) to

OS/390 for processing there like your other "SMF" data.

(The MXG code will also work fine on UNIX or WINDOWS to

directly process the dumped ASCII.)


Unfortunately, their dump has no selectivity of fields,

so you must dump all fields of each record (the CPUP has

32 fields in the Data Model, but 105 fields in their data

store!). And you cannot select the interval; you get all

all six drawers: minute,hour,day,week,month,and year.

And of course, being typically-UNIX, the drawer values

are m,H,d,w,M,Y, with upper and lower case "m" in use for

two different drawers - a nice exposure to coding errors

that mandates VMACPW must be in mixed-case!!!!! In spite

of these deficiencies, the process does work so that you

can monitor your UNIX resources with Landmark's PW

replacement for The Monitor for Unix, formerly TYPETUX.

Thanks to Dan Sedorik, SmithKlein Beecham, USA.
Change 15.009 Support for APAR OW25152 that adds PRINTWAY Print Queue

VMAC6 Name SMF6PRTQ to TYPE6 dataset, compatibly made. I have

Mar 7, 1997 assumed a maximum name length of 16 to save storage. The

Jul 14, 1999 PRINTWAY internal subsystem value of SMF6SBS='0009'x is

used by MXG to set SUBSYS='TCP' for PRINTWAY records.

See Change 17.171 for PRINTWAY impact on TYPETASK.


Change 15.008 -Wrong values for CSCONF,CSAVAIL,CSOFFL,CNCONF,CNPINNED

VMACACHE and CSSTAT with Hitachi 7700, probably due to bad IBM

VMAC74 SMF documentation rather than Hitachi. In the SMF manual

Mar 7, 1997 CSSTAT='....1111'B is the 3990-6 Enhanced Mode flag, and

that is the value in IBM 3990 records, but IBM's Storage

Control manual GA32-0274 documents CSSTAT='.......1'B as

the expected value, and that is the value in Hitachi 7700

records (which are in fact in Enhanced Mode format)! To

support both IBM and Hitachi, MXG's test is changed to:

IF CSSTAT='.......1'B THEN DO;

(The storage sizes are in units of 1024 bytes in the

3990-Enh format records, or are in bytes if not.)

-In VMAC74, the label for CSSTAT is 3990-6 (vice 3880-6!).

-A second HDS 7700 problem: with 3GB of cache, 4080GB of

cache is reported! (Raw data value is 'FF040000'X). PTF

UW36274 may address, but Hitachi is investigating and

this note will be updated when more is known.

Thanks to Miller Dickson, DST Systems Inc, USA.


Change 15.007 Analysis of APAF Shared processors used NUMLP (the number

ANALAPAF of total engines) to calculate PHY_BUSY, but using number

Mar 7, 1997 of engines available to this domain, LINUMLPS, makes more

sense.


Thanks to Gary Strohminger, AT&T Transtech, USA.
Change 15.006 ERROR: WORK.CICINTRV.DATA DOES NOT EXIST if you changed

CICINTRV IMACCICS to write CICS Statistics to the //WORK DD.

Mar 7, 1997 Move the PROC DATASETS; DELETE CICINTRV; to the bottom

of member CICINTRV to correct my error.

Thanks to Fred Kaelber, Pacific Bell, USA.
Change 15.005 Cosmetic. Label for variable SMF42EAC should have been

VMAC42 ACTIVATE*ENF OR*VARY SMS (instead of VARY SMF).

Mar 7, 1997

Thanks to Solomon Baker, Prudential, USA.


Change 15.004 OS/390 V 1 Rel 3 type 72 record INPUT STATEMENT EXCEEDED

VMAC7072 RECORD LENGTH error. The statement SKIP=SKIP-24; that

Mar 1, 1997 is after the statement R723CIDT=128*R723CIDT; must be

changes to SKIP=SKIP-68;

Thanks to Perry Gibson, Candle Corporation, USA.
Change 15.003 All OMVS File Activity datetimestamps were in GMT, but

VMAC92 are now converted from GMT to local (using the same

Feb 27, 1997 algorithm introduced in Change 14.311). In TYPE9210, the

close time, SMF92CTC, is often .01 seconds later than the

SMFTIME value, which in theory should not happen, but is

valid because SMFTIME informat is truncated to .01 sec

resolution while TODSTAMP (SMF92CTC) informat has micro

second resolution that is rounded to .01 seconds by the

DATETIME21.2 format. A true time of .026 seconds will

be .02 input as SMFTIME and .026 if input as TODSTAMP,

but will print as .02 and .03 respectively with the

DATETIME21.2 format (increasing that format to 22.3

would show the .026 value).

Thanks to Perry Gibson, Candle Corporation, USA.


Change 15.002 Variable TERMIND was added to the _PDB30_4 macro so it is

IMACPDB now kept in PDB.STEPS, as enhancement for ABEND decoding,

Feb 27, 1997 in case of multiple bits.

Thanks to Dan Adams, Facilities Systems Office (FACSO), USN, USA.


Yüklə 28,67 Mb.

Dostları ilə paylaş:
1   ...   281   282   283   284   285   286   287   288   ...   383




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©muhaz.org 2024
rəhbərliyinə müraciət

gir | qeydiyyatdan keç
    Ana səhifə


yükləyin