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.
Dostları ilə paylaş: |