Status of MXG Software's
Support for Year 2000
This final summary was posted to MXG-L Dec 13, 1999:
Dec 13, 1999: Summary of Y2K Issues after MXG 16.16:
Notes:
VSAM Catalogs stop functioning on 1/1/2000. All VSAM catalogs
must have been replaced by ICF Catalogs by then. If there are
any SMF records with IDs of 63, 67, or 69 in your SMF file, you
still have a VSAM Catalog somewhere.
YEARCUTOFF affects two-digit date literals in your report programs.
This is not an MXG problem, as there are no two-digit date literals
in MXG, but if you have any, here's what happens with YEARCUTOFF:
AGE=TODAY()-'19APR41'D; AGE= 21353 if YEARCUTOFF=1900 (correct),
AGE=-15172 if YEARCUTOFF=1960 (wrong!).
ANALDATE utility (MXG 17.07, Change 17.262) will examine all SAS
date/datetime variables in all datasets in a SAS data library
and reports what dates are found.
APAR OW41147 - CRITICAL APAR for SMS. Must Read. Any datasets
with EXPDT=0099999 will be deleted by SMS on January 1, 2000.
You can use DCOLLECT variable ORGEXPDT to detect if you have any,
and correct them as described in that APAR text. Further details
are in text of MXG Change 17.307 (documentation only, no change).
MXG Software Changes for Y2K Ready after MXG 16.16:
Change 17.231 (MXG 17.07): Soft Audit XPMLKDT/XPMXPDT dates were not
only not Y2K Ready, but were flat out wrong in MXG decoding.
Change 17.227 (MXG 17.07): SAP IMS log record 'AE' was not Y2K Ready
until SAP Release 5.0i. Date was 0DDMMYYF, incompatibly changed to
YYYYMMDD format by that release, and now supported by this MXG change.
Change 17.216 (MXG 17.06): MXG Tape Mount Monitor ASMTAPES must have
been assembled with "ES6" to run under OS/390 R1.3 or later. If it
was assembled with ES5 or ESA, the INITTIME date will be 1900 in
the SMF record, but as long as you are using MXG 17.xx or later, it
will protect that 1900 date and your MXG dataset will be Y2K Ready
even if you don't re-assemble the MXGTMNT program from ASMTAPES.
Change 17.136 (MXG 17.04): TCP SMF record for TELNET in TYPETCPT
IBM did not use century bit 0cyydddF for this TELLOGFT datetimestamp;
instead used non-valid yyyydddF format, which creates year 3800 data.
MXG replaced SMFSTAMP8 format with circumvention code to support.
Change 17.091 (MXG 17.02): TELEVIEW 4.3
Release was incompatible, dates had never been validated, now ok.
Change 17.021 (MXG 17.01): HSM and TMS
Date values are Y2K compliant, but default print format was 6 instead
of 7, so the Julian Date of 2000001 prints as 2E6. The default MXG
format was changed; you can add FORMAT xxxxxx 7. ; to your reports.
=====================================================================
This cover letter was sent in reply to Year 2000 status requests:
Date January 20, 1999
To:__________________________________ Company: ________________________
Fax:________________________________ Tel:_____________________________
Re: Year 2000 Support in MXG Software
1. The enclosed technical statement confirms MXG Support of Year 2000.
This was first published in MXG Newsletter Number 28, August, 1995, and
is in member YEAR2000 of MXG Software and on our www.MXG.com homepage.
Both are updated when changes to MXG for Y2K support are made; notify of
changes for Y2K support are posted to all MXG-L ListServer subscribers.
2. We cannot complete your survey forms for you, but believe that all
possible questions are answered in the enclosed document and warantee.
3. With our modest annual renewal fee, you don't want to ask me to take
time from software development to propose changes to your MXG License
Agreement, (we accept no changes), but this statement is part of our
product and our homepage, and it is the best technical statement of Y2K
support that the author and owner can provide, no matter what wording
legal might want. You have my word on it!
4. MXG users worldwide have been testing MXG with Year 2000 data, and
MXG Version 16.09 or later is now required to support all fields in all
products. MXG 16.01+ is Y2K compliant for almost all products, but a
few products had a few julian date fields that had 0100001 (0cyyddd)
values that were not protected with MXG's DATEJUL()-protect-algorithm.
The affected products are listed below. No ABEND, just missing values.
This information is updated in member YEAR2000 of the current MXG source
library and more frequently at our homepage, http://216.234.245.194.
Updates to Year 2000 support are broadcast to MXG-L Listserv subscribers
when the home page has been updated with any Y2K required changes.
5. Yes, our invoicing and business systems are Year 2000 compliant.
Merrilly yours,
Barry Merrill
President-Programmer
______ Thank you for including a fax number; it really saved me time!
======================================================================
Status of MXG Software's Support for Year 2000 as of Jan 20, 1999
========================================================================
Contents
A. Status of MXG Software's Support for Year 2000.
1. Merrill Consultants warrants that MXG 16.09 is Year 2000 Ready.
2. Date and date-time variables have always supported the year 2000.
3. MXG protects ALL products whose dates are not year-2000 compliant.
4. MXG Protection Techniques.
5. MXG member YEAR2000 and homepage www.mxg.com have current status.
6. What happens to measurements in a Y2K Test System in an LPAR?
7. Protected Products read by MXG that ARE NOT year-2000 compliant.
"NOT YET" List - Products that do not provide valid Year2000 dates:
"WAS NOT" List - Prior "NOT YET", now fixed, with fix documentation:
8. Protected Products read by MXG that MAY NOT be year-2K compliant.
"MAYBE NOT" List - Products that need format documentation:
"WAS MAYBE" List - Prior "MAYBE NOT", now documented, with fix info:
9. Support plans for the pseudo-Millennium Weekend, December 31, 1999.
B. Supporting Notes, Chronological Changes, (in YEAR2000, on homepage)
1. Revision of original letter to IBM with Appendices corrected Jul97
2. TIME versus STCK in MVS SAS date/time functions. Aug, 96
3. Algorithm to support CC Century bit in DATEJUL function.
4. Inverse Chronological changes to this member. Last: 2Apr98
5. Verbatim original Jun 28, 1995 letter to IBM, uncorrected.
6. Products discovered in August, 1995, not in original letter
========================================================================
A. Status of MXG Software's Support for Year 2000.
As of January 20, 1999, MXG Version 16.09 is now required for full
Year 2000 Support of all fields in all records from all supported
products. This replaces all prior statements of MXG Y2K Support.
The annual MXG Version that will be shipped to all sites will be
MXG Version 16.16 and it will ship by the end of February, 1999.
MXG 16.01 and later do support almost all products, but five common
products now require MXG 16.09 or later:
HSM SMF Records
CA-1 aka TMS Tape Management Records
BETA93 SMF Records
Landmark Monitor for MVS Version 2
VM Accounting records
Additionally, six other products that have variables that were not
Y2K compliant, but those variables were unlikely to have been used
in your reports:
DCOLLECT - one julian date variable, UCCOLDT
OPC/A - three obscure julian date variables
Landmark - CICS: TYPEMON8,TYPETMON,TYPEMOND
MVS: TYPETMV2,TYPETMVS
one internal datetime TMMDCCLK.
ASTEX - one julian date SDATE
RACF SMF - two variables REVOKEDTE, RESUMEDTE
VLF - VLF Catalog records from SYSLOG.
A.1. Merrill Consultants warrants that MXG Software meets IBM's
definition of Year 2000 Ready:
IBM considers a product Year 2000 ready if the product, when used
in accordance with its associated documentation, is capable of
correctly processing, providing and/or receiving date data within
and between the 20th and 21st cehturies, provided that all
products (for example, hardware, software, and firmware) used
with the product properly exchange accurate date data with it.
MXG Software is Year 2000 Ready for all products that themselves
are Year 2000 ready; the products supported by MXG Software whose
records are NOT-YET Year 2000 Ready are listed in member YEAR2000
of MXG Software (that list is updated between releases on the Y2K
frame of www.MXG.com). If those NOT-YET Year 2000 Ready products
make incompatible changes in their date fields, a new MXG Release
of MXG may be required to support those changes, e.g., MXG 16.09!
As of January 20, 1999, MXG Version 16.09 supports all products.
Merrilly yours,
Herbert W. Barry Merrill, PhD
President-Programmer
A.2. Date and date-time variables have always supported the year 2000.
Date variables are stored as 4-byte floating-point number-of-days
since the 1Jan1960, and will not overflow for 45,925 years.
Date variables now have a default print format of DATE9. (14Aug2019)
which fully supports the year 2000.
Datetime variables are stored as 8-byte floating point number-of-
seconds since 1Jan1960, and will not overflow for 2283 million years.
Datetime variables now have a default print format of DATETIME21.2
(14Aug2019:12:52:59.99) which fully supports the year 2000.
A.3. MXG protects products whose dates are not year-2000 compliant.
MXG dates/datetimes will be valid in 2000 only if the data fields in
records read by MXG actually contain valid Year2000 dates, or if MXG
adds protection logic for those products that do not have Y2K dates.
MXG added logic to protect ALL date fields in ALL records read by
MXG Software, as described in sections A.7 and A.8. The products
ARE NOT or MAY NOT be year 2000 compliant are listed below.
A.4. MXG Protection Techniques.
The SAS input formats of SMFSTAMP, TODSTAMP, and RMFSTAMP do support
the century bit, but the DATEJUL() function does not, instead it
returns an error condition when its argument has the century bit
enabled. MXG 13.13 added logic for DATEJUL() usage to support either
century bit or yyyy formats for fields with sufficient width. In MXG
15.04, protection was added for ALL julian dates that were used in
creating SAS DATE/DATETIME values. In MXG 16.01 support for type 6
records and the unique NPM NETVIEW CYYMMDDf format was protected.
In MXG 16.09, julian date fields in cyyddd are converted to yyyyddd,
so that they will work in your reports if you use DATEJUL() function.
If neither the century bit nor the yyyy date is found, MXG will
"Window" the YY value: if YY is less than 59 the date will be set
to 20YY, whereas if the YY is 60->99, the date will be set to 19YY.
There are also some one-byte binary date fields that contain year
values of 0 thru 255, representing years 1900 thru 2155 that needed
special coding (those dates will provide an opportunity for your
great-grandchildren to make big bucks solving the YEAR2155 problem)!
A.5. MXG member YEAR2000 and homepage www.mxg.com have current status.
MXG source library member YEAR2000 and the Year 2000 frame on our
www.MXG.com homepage contain the current status of products that
still do not or may not support the year 2000. Whenever YEAR2000
is changed in source library, the homepage is also updated. There
is additional detail (variable-level) documentation in both places.
A.6. What happens to measurements in a Y2K Test System in an LPAR?
You can use the ASUM70PR dataset and select the observations from
your production LPAR (SYSTEM='PROD') to measure the Y2K Partition's
use of resources, since the STARTIME of the records from the PROD
SYSTEM will be your local time of day.
All of the records written on SYSTEM='Y2K' will have the year 2000
dates (although the READTIME value could be earlier if jobs were
read into the hold queue before IPLing with year 2000). Since the
Y2K system will be re-IPLed repetitively with the same start value
(probably 31DEC99:23:45:00), RMF interval data will appear to have
duplicate data and the jobs/steps from all IPLs will be jumbled
together, because MXG sorts RMF data by STARTIME and job data by
READTIME.
You can extract SYSTEM='Y2K' data for a specific "test run" by
finding the record number (_N_) of each SMF IPL record, using:
%INCLUDE SOURCLIB(VMACSMF);
DATA _NULL_;
_SMF;
IF ID=0 THEN PUT 'IPL RECORD FOUND ' _N_= SMFTIME=;
and then use the record number of the specific IPL to select only
the SMF records desired. If you wanted the third run, and the third
IPL record had _N_=8,000 and the next IPL record had _N_=10,000, you
would use this logic:
%INCLUDE SOURCLIB(VMACSMF);
DATA _NULL_;
_SMF;
FILE SMFOUT DCB=SMF;
IF 8000 LE _N_ LT 10000 THEN PUT _INFILE_;
IF _N_ EQ 10000 THEN STOP;
to write to //SMFOUT DD the SMF records for that third test run.
There is an alternative to identify each "test run"; you can use the
IPL PROMPT feature to require the operator to reply with the (local)
time and the reason (name of the test run) for each IPL. Then there
would be a SUBTYPE=8 observation in dataset TYPE90 with variables
DTIME and IPLREASN with the operator reply, and the TYPE90 dataset
could be PROC PRINT to identify the SMF record numbers for each run.
You have to have specified PROMPT(IPLR) or PROMPT(ALL) in member
SMFPRMxx in SYS1.PARMLIB dataset to prompt the operator for the
reply at each IPL.
A.7. Protected Products read by MXG that ARE NOT year-2000 compliant.
"NOT YET" List - Products that do not provide valid Year2000 dates:
IBM Products:
Product Description
MVS NCCF Log records
MVS OPC Log records
MVS RMDS Log records
OS400 Trace Trace Data
VM VM/ESA Account Accounting Records
VM VM/370 Monitor Performance Record (Archaic)
Other Vendor Products:
New Dimension CONTROL-D
CA NETSPY
CA ROSCOE
CA SAR
CA VM/EXPLORE
CA XCOM
Fujitsu PDL Reports
Fujitsu Type 127 SMF record
Fujitsu Type 234 SMF record
Goal Systems PDSMAN/XP
LANDMARK TMON FOR DB2
Mobius Infopac
NOMAD NOMAD
ODI ODS/ODI Optical Disk SMF record
SAP SAP CICS Journal
SAP SAP IMS log record type AEx
STERLING DMS
Velocity Software ESAMON
Volvo (Europe) SESAME
Xerox Shared File System Print Accounting
"WAS NOT" List - Prior "NOT YET", now fixed, with fix documentation:
IBM Products:
Product Description Year 2000 Status
MVS SMF SMF type 14, 15 APAR OW13754 (thru 2155).
MVS SMF SMF type 4, 5, 30 APAR OW27461/OW15518.
MVS CICS SMF type 110 MXG 14.02 & APAR PN69653.
MVS RMF SMF 73,74,78 MXG 14.06 & APAR OW15406.
MVS SYSLOG Log records APAR OW18292 adds option.
OS400 Accounting Account/Perf OS/400 Release 3.6 CC bit
MVS DFP CATALOG SMF type 36 Workaround described
MVS DFP VTOC Year 2155 solution
MVS HSM SMF user records Workaround described
MVS NETVIEW NPM SMF type 28 See Change 16.003.
Other Vendor Products:
Boole & Babbage CICS/Manager aka CMR aka Mainview for CICS
LANDMARK TMON/CICS V2 or converted V 8.1.
LANDMARK TMON FOR MVS V2
A.8. Protected Products read by MXG that MAY NOT be year-2K compliant.
In addition, many products write Julian dates in a four-byte packed
decimal date field, which is wide enough to contain either the
century bit (0cyydddF), or the four-digit year (yyyydddF), but many
vendors have not documented what is in that first byte.
If the vendor used the TIME macro to populate the Packed Decimal
field, the century bit is automatically inserted, and those dates
will support year 2000. However, if instead, the vendor used the
STCK macro, then that vendor must add new code to populate the
century bit or new code to set the four-digit year.
These products do not officially support the year 2000 as they
have not documented their date formats.
"MAYBE NOT" List - Products that need format documentation:
IBM Products:
MVS Batch Pipes SMF type 91
MVS FTP SMF record
MVS IMS LOG Log records
MVS NETVIEW NPM SMF type 37 (Field BRFTIMST)
VM VM ACCOUNT Accounting
Other Vendor Products:
AION AION
ALTAI ZARA
CA IDMS/R SMF RECORD
CA TMS
CANDLE OMEGAMON AUDIT SMF RECORD
CANDLE OMEGAMON FOR VTAM
CANDLE ITRF
CINCOM SUPRA
Compuware FILEAID
LANDMARK TMON FOR MVS
Network Systems HMF (HyperChannel, or DXE)
RSD WSF
SIMWARE SIM/XFER
SOFTWARE AG'S NET-PASS
STK ICEBERG
SYNCSORT SYNCSORT
SYSTEM CENTER NDM (NETWORK DATA MOVER)
SIMWARE SIM/XFER
"WAS MAYBE" List - Prior "MAYBE NOT", now documented, with fix info:
IBM Products:
MVS RMF SMF type 70-79 0cyydddF APAR OW15406.
MVS SMF SMF type 4,5,7,14,15 0cyydddF APAR OW15518.
30,32,34,35,90
MVS DCOLLECT IDCAMS output 0cyydddF or yyyydddF in
DFSMS V1.4, 1.3, 1.2
MVS DFSORT SMF type 16 0cyydddF documented
MVS HSM SMF USER RECORD 0cyydddF for all PD4s
MVS RMM EDGS Extract output 0cyydddF for all PD4s
MVS CICS SMF type 110 APAR PN69653
MVS JES2 SMF type 6 0cyydddF doc in OS/390
MVS JES2 SMF type 24 0cyydddF doc in OS/390
MVS JES3 SMF type 25 0cyydddF doc in OS/390
MVS JES2 SMF type 26 0cyydddF doc in OS/390
MVS JES3 SMF type 26 0cyydddF doc in OS/390
MVS APPC SMF type 33 0cyydddF doc in OS/390
MVS JES2 NJE SMF type 57 0cyydddF doc in OS/390
MVS BDT SMF type 59 0cyydddF doc in OS/390
MVS JES3 SMF type 84 0cyydddF doc in OS/390
MVS MULC SMF type 89 0cyydddF doc in OS/390
Other Vendor Products:
Boole & Babbage IMF aka MainView for IMS Version 3.2 yyyydddF
BGS BGS I/O MONITOR Version 5.1 0cyydddF
A.9. Support plans for the pseudo-Millennium Weekend, December 31, 1999.
What are our plans for the pseudo-Millennium Weekend?
We plan to party like it's 1999!
But we also will provide technical support coverage by telephone
(214-351-1966), fax (214-350-3694) and email (support@MXG.com), and
especially via our MXG-L Listserver (see http://216.234.245.194).
Since MXG has been executed at hundreds of sites during their Y2K
tests, we do not anticipate any problems with MXG Software itself,
but our MXG users worldwide will use MXG-L to broadcast any errors
they encounter with Y2K crossings in their data centers, and since
MXG executes in every time zone, our Kiwi-land users will have the
first opportunity to alert the rest of the world if their data
centers experience any problems with the Y2K midnight crossing.
And should all other communications fail, Judy and I will be on our
amateur radio stations (call signs KA5PQD and W5GN), monitoring the
frequencies of 14.199MHz on the hour, 21.299MHz at 20 minutes past,
and 28.399MHz at 40 minutes past, for emergency communications.
Merrilly yours,
Barry and Judy Merrill
Merrill Consultants
========================================================================
B. Supporting Notes, Chronological Changes, other details.
========================================================================
B.1. Revision of original letter to IBM with Appendices corrected Jan97
B.2. TIME versus STCK in MVS SAS date/time functions. Aug, 96
B.3. Algorithm to support CC Century bit in DATEJUL function.
B.4. Inverse Chronological changes to this member.
B.5. Verbatim original Jun 28, 1995 letter to IBM, uncorrected.
B.6. Products discovered in August, 1995, not in original letter
======================================================================
B.1. Revision of original letter to IBM with Appendices corrected
======================================================================
(This is the revised text, correctd 15Jan1997).
Jun 28, 1995
To: Jennifer Green
IBM Solution Developer Enablement Fax 914 432 9418
Tel 433 3823
Fr: Barry Merrill
Merrill Consultants
(MXG Software)
Re: Year2000 Project
a. Since MXG Software processes "every record on the face of the earth",
I have a unique capability to identify all date-containing-fields in all
externalized data records used for accounting, performance, etc., to
help IBM verify that its products support the next millenium, as well to
identify all non-IBM products that must be verified by their vendors to
be Year2000 compliant.
I have examined every date-containing field processed by MXG Software
and enclose herewith several Appendices which identify which products
require either "CHANGE" or "VALIDATE" to support the year 2000 and
beyond:
- "CHANGE" is required when the date in the record is not wide enough
to contain dates beyond 1999. Either the field must be relocated, or
the contents may be redefinable, but in either case both the vendor
and the processor of the data must change their programs.
For example, the fields that are YY in two-byte EBCDIC format
could be redefined as binary values, and processing software
can differentiate between binary and EBCDIC values without
relocation or expansion, since the years 00 to 99 in EBCDIC are
'F0F0'x thru 'F9F9'x, which is decimal 61680 thru 63993 as a
two-byte binary.
- "VALIDATE" is required for fields which currently contain a Julian
date in a packed decimal format of width 4. While this field width
is sufficient to contain the CCYYDDDF formatted date with century
bit, most fields are documented as 00YYDDDF; the program logic that
creates the 4-byte packed decimal field must be verified by the
vendor that the century-bit support has been coded:
- If the program uses the IBM TIME macro (which does now return
the century bit), the vendor must verify that the program has
been recently assembled (i.e., after the CC bit was added to the
TIME macro).
- If the program uses the IBM STCK macro, the vendor must verify
that its program creates the century bit, since reformatting STCK
to CCYYDDDF is done by the vendor's coding.
b. Please advise when all of the IBM products are themselves compliant.
I will be happy to process the IBM data records from a system that you
believe compliant that has been started with a date after 1999 to verify
that your products support the Year 2000.
c. I would hope that IBM would use the enclosed list of non-IBM products
to challenge those listed vendors who respond that their products are
compliant to ensure the vendor has corrected the specific date fields I
have identified herein. Especially for "CHANGE" fields, IBM should
require the vendor to provide the "fix number, or maintenance release"
that makes the change, and to document exactly how the vendor changed
the field, so that other vendors (like Merrill!) can ensure that our
customers have the correct level of the non-IBM products.
d. I recommend that IBM also take this opportunity, well in advance, to
address the YEAR2042 issue: at 23:53:48 on September 17, 2042, the IBM
8-byte hardware clock will fill and return to January 1, 1900. (I first
reported this in MXG Technical Newsletter THIRTEEN in January 1989.)
e. I separately include your Attachment B, certifying that MXG Software
itself is Year2000 compliant, and has been since its creation in 1984.
(In 1979, I attended a "Birds of a Feather" session at SHARE to discuss
how we would deal with the year 2000!).
f. Let me know how I can further assist!
Merrilly yours,
Herbert W. Barry Merrill, PhD
President-Programmer
Management Summary of Critical Products
IBM Products Requiring CHANGE (details in Appendix 1)
MVS CICS SMF type 110 APAR PN69653.
MVS DFP SMF type 36
MVS DFP VTOC
MVS NETVIEW NPM SMF type 28
MVS RMF SMF type 73, 74, 78
MVS SMF SMF type 14, 15
MVS HSM SMF user records
MVS OPC Log records
MVS NCCF Log records
MVS SYSLOG Log records OW18292.
VM VM ACCOUNT Accounting Records
IBM Products Requiring CHANGE or VALIDATE (details in Appendix 2)
MVS APPC SMF type 33
MVS Batch Pipes SMF type 91
MVS BDT SMF type 59
MVS CICS SMF type 110
MVS DFP CATALOG SMF type 36
MVS DFSORT SMF type 16
MVS JES2 NJE SMF type 57
MVS JES2 SMF type 6
MVS JES2 SMF type 24
MVS JES2 SMF type 26
MVS JES3 SMF type 25
MVS JES3 SMF type 26
MVS JES3 SMF TYPE 84
MVS MULC SMF type 89
MVS NETVIEW NPM SMF type 28
MVS NETVIEW NPM SMF type 37
MVS RMF SMF type 70-79
MVS SMF SMf type 4,5,7,14,15,30,32,34,35,90
MVS HSM SMF USER RECORD
MVS DCOLLECT IDCAMS output
MVS RMM EDGS Extract output
MVS FTP SMF record
MVS HSM SMF RECORDS
MVS IMS LOG Log records
MVS OPC Log records
MVS HSM MCD/BCD/ Log records
MVS DFP VTOC
MVS NETVIEW NCCF
VM VM ACCOUNT Accounting
Management Summary of Critical Products (continued)
non-IBM Products Requiring CHANGE (details in Appendix 3)
Vendor Product
CA SAR
CA NETSPY
CA XCOM
Goal Systems PDSMAN/XP
LANDMARK TMON/CICS
LANDMARK TMON FOR DB2
LANDMARK TMON FOR MVS
NOMAD NOMAD
STERLING DMS
Volvo (Europe) SESAME
non-IBM Products Requiring CHANGE or VALIDATE (details in Appendix 4)
Vendor Product
ALTAI ZARA
BGS BGS I/O MONITOR
BOOLE IMF
CA IDMS/R SMF RECORD
CA ROSCOE
CA SAR
CA NETSPY
CA TMS
CA XCOM
CANDLE OMEGAMON AUDIT SMF RECORD
CANDLE OMEGAMON FOR VTAM
CANDLE ITRF
LANDMARK TMON/CICS
LANDMARK TMON FOR DB2
LANDMARK TMON FOR MVS
SAP CICS JOURNAL
STERLING DMS SMF USER RECORD
STK ICEBERG
SYSTEM CENTER NDM (NETWORK DATA MOVER)
SOFTWARE AG'S NET-PASS
SYNCSORT SYNCSORT
CINCOM SUPRA LOG RECORD
AION AION
Compuware FILEAID
Network Systems HMF (HyperChannel or DXE)
RSD WSF
Goal Systems PDSMAN/XP
NOMAD NOMAD
Volvo (Europe) SESAME
SIMWARE SIM/XFER
APPENDIX 0 - Description of the contents of the Appendices:
These appendices follow:
APPENDIX 1 - Details of all IBM Fields which require CHANGE
APPENDIX 2 - Details of all IBM Fields which require VALIDATE
APPENDIX 3 - Details of all non-IBM Fields which require CHANGE
APPENDIX 4 - Details of all non-IBM Fields which require VALIDATE
MXG Variable names are used in this listing, because that was the
quickest way to identify the fields which need CHANGE/VALIDATE.
I will be happy to work with product specialists to re-describe
their affected fields in terms of offset and record subtype and
vendor's original field names.
Formats of fields are shown in SAS (MXG's chosen language):
SMFSTAMP8. - 8-byte standard SMF time-and-date format,
4-byte time-since-midnight (binary, 2 decimals),
date in last four bytes, CCYYDDDF julian date
with century bit expected.
PD4. - Packed Decimal length 4, has ability to store
CCYYDDDF julian date.
PD3. - Packed Decimal length 3, room only for YYDDDF
PIB1. - Positive Integer Binary of length 1, can store
decimal values 0 thru 255.
PK1. - Packed Binary length 1 byte. ('99'x = 99 decimal).
can only store numbers 0 thru 99 in one packed byte.
2. - EBCDIC numeric length 2. ('F9F9'x = 99 decimal).
5. - EBCDIC numeric length 5. ('F9F9F3F6F5'x =99365).
YYMMDD6. - EBCDIC numeric length 6 ('F9F9F1F2F3F1'x =991231).
APPENDIX 1 - Details of all IBM Fields which require CHANGE
IBM CICS SMF type 110 APAR PN69653
COLLTIME 2. YY expanded, MXG 14.02+ supports.
IBM DFP CATALOG SMF type 36 MXG 15.01 PROTECTS
EXPOTIME 2. YY IBM will not change
IBM HSM MCD/BCD/ETC RECORDS MXG 15.01 PROTECTS
DSRDATE PD3. /* DATE IBM Won't CHANGE */
VSRDATE PD3. /* DATE IBM Won't CHANGE */
BCRCDATE PD4. /* DATE CYCLE WAS DEFINED */
BCRBL1D PD4. /* DATE L1 FUNCTIONS PERFORMED */
BCRDBLA PD4. /* DATE ARCGEN LAST UN-WAITED */
BCRDSAB PD4. /* DATE " " " " " */
DCRDATE PD4. /* DUMP CYCLE START DATE */
DCRSTRDT PD4. /* DATE AUTO FUNCT LAST START */
DCRCMPDT PD4. /* DATE LAST COMPL AUTO FUNCT END */
DCRCKDAT PD4. /* DATE " " " */
DCRCCDAT PD4. /* DATE CYC DAY AUTO STRT CHKD */
DCRDCDAY PD4. /* DATE LAST AUTO FUNCT FROM BEGNG*/
DGNTSDD PD4. /* DATE " " " */
DGNEXPDT PD4. /* EXPDT THIS DUMP COPY OR 0 */
DGNCYLDT PD4. /* DATE FULL VOL DUMP BEGAN */
DVLTSDD PD4. /* DATE DUMP COPY WRITTEN */
DVLDEXPD PD4. /* EXPDT IF VALID ELSE X00 */
MCBDBU PD4. /* DATE LAST BACKUP */
MCBDLRPB PD4. /* NON-VSAM DATE LAST REFERENCD*/
MCBCDATE PD4. /* DATE THIS BKUP VERSN MADE */
MCCTSBUD PD4. /* DATE VERSION CREATED */
MCCTSLUD PD4. /* DATE LST VSM UPDT OR CRDT */
MCDDMIG PD4. /* X'00YYDDDS' DATE MIGRATED */
MCDDLC PD4. /* X'00YYDDDS' DATE DATA SET CREATD*/
MCDDLR PD4. /* X'00YYDDDS' DATE DATA LAST USED
MCDDLU PD4. /* X'00YYDDDS' DATE VSAM LAST USED
MCDDRES PD4. /* X'00YYDDDS' DATE RECALL OR DELET
MCDEXPDT PD4. /* X'00YYDDDS' EXPIRATION DATE
MCPDTSDD PD4. /* DATE " " " */
MCPTSLBD PD4. /* DATE LAST BACKUP FROM THIS VOL*/
MCPVTCD1 PD4.
MCPVTCD2 PD4.
MCPVTCD3 PD4.
MCPVTCD4 PD4.
MCPLDEXP PD4.
MCRLGMSD PD4.
MCRGMSD PD4. /* DATE " " " " " */
MCRLGMED PD4.
MCRCDATE PD4. /* DATE LAST MIG. CLEANUP */
MCRNSPKD PD4. /* DATE NEXT SP CK FOR INT MIG */
MCTTSLCD PD4. /* DATE VOL LAST CLEANED UP */
MCTTSLSD PD4. /* DATE VOL LAST SPILLED */
MCVTSLMD PD4. /* DATE LAST MIG NOT VALID L1*/
MCVLSPCD PD4. /* DATE LAST LSPACE YYDDD */
MHCRBGND PD4. /* DATE X00YYDDDS SP. CALC. STR
MHCRENDD PD4. /* DATE SPACE CALC. ENDED
MHCRNXTD PD4. /* DATE NEXT CALC S.B. DONE
IBM NCCF MXG 15.01 PROTECTS
NCCFDTTM PD3. YY
IBM NETVIEW NPM SMF TYPE 28 MXG 16.01 REQUIRED, NOW CYYMMDDF.
BANDTDTE PD4. YYMMDD6. /*DATE OF BANDTIME*/
BANDTIME PD4. YYMMDD6. /*DATE RECORD RECEIVED BY NPM*/
BASNCPDT PD4. YYMMDD6. /*DATE OF BASTIME*/
COLLTIME PD4. YYMMDD6. /*END DATE*OF COLLECTION*/
LDRDATE PD4. YYMMDD6. /*DATE OF STARTIME*/
LNACCBSK PD4. YYMMDD6. /*DATE OF START*/
LNACCESK PD4. YYMMDD6. /*DATE OF END*/
LNADCBSK PD4. YYMMDD6. /*DATE OF START*/
LNADCESK PD4. YYMMDD6. /*DATE OF END*/
LNADDCTD PD4. YYMMDD6. /*DATE OF START*/
LNAMBDAT PD4. YYMMDD6. /*DATE OF STARTIME*/
LNAMEDAT PD4. YYMMDD6. /*DATE OF COLLECTION END*/
LNARBDAT PD4. YYMMDD6. /*DATE OF COLLECTION BEGIN*/
LNEOCBSK PD4. YYMMDD6. /*DATE OF start*/
LNEOCESK PD4. YYMMDD6. /*DATE OF END*/
LNETBDAT PD4. YYMMDD6. /*DATE OF COLLECTION BEGIN*/
LSAACBSK PD4. YYMMDD6. /*DATE OF START*/
LSAACESK PD4. YYMMDD6. /*DATE OF END*/
LSAMBDAT PD4. YYMMDD6. /*DATE OF START*/
LSAMEDAT PD4. YYMMDD6. /*DATE OF END*/
LSTTCBSK PD4. YYMMDD6. /*DATE OF START*/
LSTTCESK PD4. YYMMDD6. /*DATE OF END*/
LVAMBDAT PD4. YYMMDD6. /*DATE OF START*/
LVAMEDAT PD4. YYMMDD6. /*DATE OF END*/
LXETTDTE PD4. YYMMDD6. /*DATE SENT BY NCP*/
LXETTMST 2. YY /*LXET*TIMESTAMP*LXETTMST*/
OGFEDATE PD4. YYMMDD6. /*DATE OF END*/
OGFSDATE PD4. YYMMDD6. /*DATE OF START*/
OGNSDATE PD4. YYMMDD6. /*DATE OF START*/
RMATBDAT PD4. YYMMDD6. /*DATE OF START*/
RMDTEDAT PD4. YYMMDD6. /*DATE OF END*/
SSAACBSK PD4. YYMMDD6. /*DATE OF START*/
SSAACESK PD4. YYMMDD6. /*DATE OF END*/
SSTTBDAT PD4. YYMMDD6. /*DATE OF START*/
SSTTEDAT PD4. YYMMDD6. /*DATE OF END*/
VADSDTEX PD4. YYMMDD6. /*JOBNAME/USERID*START DATE*/
VAPAPLDT PD4. YYMMDD6. /*END DATE*OF APPLICATION*ACTIVATION*/
and many more!
IBM OPC MXG 15.04 PROTECTS
TRLEVDAT PD4. /* EVENT DATE 00YYDDDF */
TRLIAD23 2. YY
MT0CPET 2. YY
MT0DATE PD4. /* DATE OF UPDATE */
MT0IMD 2. YY
MT0IAD 2. YY
MT0DLD 2. YY
IVLFRDAT 2. YY
IVLTODAT 2. YY
MTDIAD 2. YY
MTDDLD 2. YY
MTDDIAD 2. YY
TRLIAD25 2. YY
TRLIAD26 2. YY
TRLIAD27 2. YY
TRLIAD28 2. YY
ETCLDATE 2. YY
TRLIAD32 2. YY
TRLIAD33 2. YY
TRLIAD34 2. YY
EXRDATE 2. YY
EXRRDATE 2. YY
EXRSDATE 2. YY
EXREDATE 2. YY
VSRDATE PD3. /* DATE */
IBM RMDS MXG 15.04 PROTECTS
Sixteen occurrences of YY NUM2. CHANGE required.
IBM RMF SMF type 73 MXG 14.06 + APAR OW15406
IODFDATE 2. YY /*SMF73TDT IODF*CREATE*DATE*/
IBM RMF SMF type 74 MXG 14.06 + APAR OW15406
IODFDATE 2. YY /*SMF74TDT IODF*CREATE*DATE*/
IBM RMF SMF TYPE 78 MXG 14.06 + APAR OW15406
IODFDATE 2. YY /*SMF78TDT IODF*CREATE*DATE*/
IBM SMF SMF type 14,15 APAR OW13754 (YEAR2155)
OPENDTE PD4.
CRDATE PIB1. YY
EXDYY PIB1. YY
IBM SYSLOG OW18292. APAR OW18292 adds option.
EVENTIME 2. YY
IBM OS/400, AS/400 "QAPM" account MXG uses CC BIT.
All dates contain only YY NUM2, but the QAPMCONF Start Event
record contains the CC Century bit, which MXG retains and uses
to decode all other date fields (as long as QAPMCONF is the
first file processed, as noted in VMACQAPM notes).
IBM OS/400, AS/400 "QTRT" trace. MXG 15.04 protects.
TRNYEAR PD3.
IBM VTOC APAR OW13754 (YEAR2155)
CRDATE PIB1. YY
EXPDT PIB1. YY
LASTUSED PIB1. YY
IBM VM ACCOUNT MXG 15.04 PROTECTS.
ACCTTIME 2. YY
ONTIME 2. YY IN PD8.
OFFTIME 2. YY IN PD8.
IBM VM/370 Monitor DEAD PRODUCT.
COLLTIME, YY NUM2. CHANGE required.
APPENDIX 2 - Details of all IBM Fields which require VALIDATE
IBM APPC SMF type 33
REQDTIME SMFSTAMP8. /*SMF33FMT,FMD REQ REGOGNIZED BY
REQDTIME SMFSTAMP8. /*SMF33FMT,FMD REQ REGOGNIZED BY FMH5*
SKEDTIME SMFSTAMP8. /*SMF33TQT,TQD REQ ON SKED QUEUE*/
TPNDTIME SMFSTAMP8. /*SMF33TET,TED REQ EXECUTION ENDED*/
TPSTTIME SMFSTAMP8. /*SMF33TST,TSD REQ EXECUTION START*/
IBM Batch Pipes SMF type 91
AFSTTIME SMFSTAMP8. /*SMF91IFT*1ST ACC*TO THE PIPE*THIS CONN*/
ALSTTIME SMFSTAMP8. /*SMF91OLT LAST ACC*TO THE PIPE*THIS CONN*
PALCTIME SMFSTAMP8. /*PIPE ALLOCATION FOR THIS CONNECTION*/
PCLOTIME SMFSTAMP8. /*PIPE CLOSED FOR THIS CONNECTION*/
POPCTIME SMFSTAMP8. /*PIPE OPEN COMPLETED FOR THIS CONNECTION*
POPNTIME SMFSTAMP8. /*PIPE OPEN REQUESTED FOR THIS CONNECTION*
SMF91SCT SMFSTAMP8. /*STATUS*CHANGED*DATETIMESTAMP*/
INTBTIME SMFSTAMP8. /*SMF91IST INTERVAL*BEGIN*TIMESTAMP-LOCAL*
IBM BDT SMF type 59
ENDTIME SMFSTAMP8.
QUEUTIME SMFSTAMP8.
XMENTIME SMFSTAMP8.
XMITTIME SMFSTAMP8.
IBM CICS SMF type 110 APAR PN69653
CICSTRSD PD4. /*CICS*JOB*DATE*/
IBM DCOLLECT DFSMS V1.4, 1.3 or 1.2
DCUTMSTP SMFSTAMP8. 0cyydddF and yyyydddF
UBTIME PD4.
UMTIME PD4.
DCDCREDT PD4
DCDEXPDT PD4.
DCDLSTRF PD4.
UMCREDT PD4.
UMLRFDT PD4.
UCCDATE PD4.
UCCOLDT PD4.
IBM DFSORT SMF type 16
ENDTIME SMFSTAMP8. /*ICETIMEE*/
STRTTIME SMFSTAMP8. /*ICETIMES*/
IBM FTP
DVGASTIM PD4.
DVGARDAT PD4.
DVGANBTD PD4.
DVGANATD PD4.
DVGDSTIM PD4.
DVGQSTIM PD4.
DVGCSTIM PD4.
DVGRSTIM PD4.
DVGNXMST PD4.
DVGNXMET PD4.
IBM HSM SMF USER RECORD
FSRDATR PD4. /* DATE USER MADE REQ
IBM IMS LOG
GUTIME PD4.
ENDTIME PD4.
STRTTIME PD4.
ENQTIME PD4.
DEQTIME PD4.
SYNCDATE PD4. /* DATE OF SYNC POINT 00YYDDDF
IBM JES2 NJE SMF type 57
XMITTIME SMFSTAMP8.
XMENTIME SMFSTAMP8.
IBM JES2 SMF type 6
PRINTIME SMFSTAMP8. /*SMF6WST+SMF6WSD*/
IBM JES2 SMF type 24
OFLDTIME SMFSTAMP8. /*OFFLOAD DATASET ALLOCATION*/
IBM JES2 SMF type 26
JRDRTIME SMFSTAMP8. /*SMF26RPT+SMF26RPD*/
JCNVTIME SMFSTAMP8. /*SMF26CST+SMF26CSD*/
JSTRTIME SMFSTAMP8. /*SMF26XST+SMF26XSD*/
JENDTIME SMFSTAMP8. /*SMF26XPT+SMF26XPD*/
JPRNTIME SMFSTAMP8. /*SMF26OST+SMF26OSD*/
JFINTIME SMFSTAMP8. /*SMF26OPT+SMF26OPD*/
XMITTIME SMFSTAMP8.
XMENTIME SMFSTAMP8.
IBM JES3 SMF type 25
FETCTIME SMFSTAMP8.
MNTTIME SMFSTAMP8.
STRTTIME SMFSTAMP8.
VERFTIME SMFSTAMP8.
IBM JES3 SMF type 26
DLNETIME SMFSTAMP8.
JRDRTIME SMFSTAMP8.
JCNVTIME SMFSTAMP8.
JSTRTIME SMFSTAMP8.
JENDTIME SMFSTAMP8.
JPRNTIME SMFSTAMP8.
JFINTIME SMFSTAMP8.
IBM JES3 SMF TYPE 84
JMFEDTE PD4. /*JMF INTERVAL END DATE*/
JMFSDTE PD4. /*JMF INTERVAL START DATE*/
IBM MULC SMF type 89
SMF89IET SMFSTAMP8. /*REPORTING*INTERVAL*ENDTIME*/
SMF89IST SMFSTAMP8. /*REPORTING*INTERVAL*STARTIME*/
SMF89UET SMFSTAMP8. /*USAGE DATA*INTERVAL*ENDTIME*/
SMF89UST SMFSTAMP8. /*USAGE DATA*INTERVAL*STARTIME*/
IBM NETVIEW NPM SMF type 37
NPDADATE PD4. /*BRFTIMST - NPDA*DATE*/
IBM RMM EDGS
MDLRDATE PD4. /*DATE*LAST*READ*/
MDLWDATE PD4. /*DATE*LAST*WRITTEN*/
MKDELDAT PD4. /*AUTOMATIC*DELETE*DATE*/
MVEXPDT PD4. /*EXPIRATION*DATE*(CHAR)*ORIGINAL*/
MVLRDDAT PD4. /*DATE*VOLUME*LAST READ*/
MVLWDDAT PD4. /*DATE*VOLUME*LAST WRITTEN*/
MVSTDATE PD4. /*DATE*STORED*/
EDGSADTE PD4. /*ACTION*CREATE*TIME*/
EDGSARSD PD4. /*READER*START*DATE*/
MACRDATE PD4. /*ACTION*CREATE*DATE*/
MALCDATE PD4. /*LAST*CHANGE*DATE*/
MAUCDATE PD4. /*LAST USER*CHANGE*DATE*/
MDCRDATE PD4. /*DSN*CREATE*DATE*/
MDLCDATE PD4. /*LAST*CHANGE*DATE*/
MDLRDATE PD4. /*DATE*LAST*READ*/
MDLWDATE PD4. /*DATE*LAST*WRITTEN*/
MDUCDATE PD4. /*LAST USER*CHANGE*DATE*/
MKCRDATE PD4. /*DSN*CREATE*DATE*/
MKDELDAT PD4. /*AUTOMATIC*DELETE*DATE*/
MKLCDATE PD4. /*LAST*CHANGE*DATE*/
MKUCDATE PD4. /*LAST USER*CHANGE*DATE*/
MOCRDATE PD4. /*DSN*CREATE*DATE*/
MOLCDATE PD4. /*LAST*CHANGE*DATE*/
MOUCDATE PD4. /*LAST USER*CHANGE*DATE*/
MPCRDATE PD4. /*DSN*CREATE*DATE*/
MPLCDATE PD4. /*LAST*CHANGE*DATE*/
MPUCDATE PD4. /*LAST USER*CHANGE*DATE*/
MRCRDATE PD4. /*DSN*CREATE*DATE*/
MRLCDATE PD4. /*LAST*CHANGE*DATE*/
MRUCDATE PD4. /*LAST USER*CHANGE*DATE*/
MVASDATE PD4. /*ASSIGNED*DATE*/
MVCRDATE PD4. /*DSN*CREATE*DATE*/
MVEXPDT PD4. /*EXPIRATION*DATE*(CHAR)*ORIGINAL*/
MVLCDATE PD4. /*LAST*CHANGE*DATE*/
MVLRDDAT PD4. /*DATE*VOLUME*LAST READ*/
MVLWDDAT PD4. /*DATE*VOLUME*LAST WRITTEN*/
MVSTDATE PD4. /*DATE*STORED*/
MVUCDATE PD4. /*LAST USER*CHANGE*DATE*/
MSCRDATE PD4.
MSLCDATE PD4.
MSCUDATE PD4.
MVRETDAT PD4.
IBM SMF All SMF records.
SMFSTAMP SMFSTAMP8.
READTIME SMFSTAMP8. (in all job-related records, but copied
from a single control block).
IBM SMF SMF type 4, 34
INITDATE PD4.
IBM SMF SMF type 5, 35
ENQTIME SMFSTAMP8.
JINITIME SMFSTAMP8.
IBM SMF SMF type 7
LOSSTIME SMFSTAMP8.
IBM SMF SMF type 30
REND SMFSTAMP8. /*SMF30RDE,RET,RED*/
INITTIME SMFSTAMP8. /*SMF30SIT,STD*/
SMF30IST SMFSTAMP8. /*SMF30IST,SMF30IDT*/
IBM SMF SMF type 32
INITTIME SMFSTAMP8. /*SMF32SIT,STD*/
IBM SMF SMF type 90
NEWTIME PD4.
OLDTIME PD4.
APPENDIX 3 - Details of all non-IBM Fields which require CHANGE
Boole & Babbage CICS/Manager type 110 MXG 15.04 PROTECTS.
subtype 'BB'x SMF record
YY PK1. for STIDTIME subtypes 200,201,202,203,204,205
New Dimension CONTROL-D MXG 15.04 PROTECTS.
YY NUM2
CA NETSPY MXG 15.04 PROTECTS.
SNITIME PK1. YY
STARTIME PD4.
STOPTIME PD4.
NSPXTIME PD4.
CA ROSCOE MXG 15.04 PROTECTS.
EDATEJ PD4.
SDATEJ PD4.
DATEJ PD4.
ROSDATE PD4.
SDATE NUM2. (three places)
CA SAR MXG 15.04 PROTECTS.
SARATIME 2. YY
SARPTIME 2. YY
SARBDATE PD4. /*LAST*BROWSED*DATE*/
CA VM/EXPLORE MXG 15.04 PROTECTS.
DATE NUM2. YY
RDATE NUM2. YY
ULOGDATE NUM2. YY
TSELABDA NUM2. YY
TSELABA NUM2. YY
CA XCOM MXG 15.03 PROTECTS.
SKEDDTE PD3. /*SCHEDULE*REQUEST*DATE*/
STARTDTE PD3. /*START*DATE*TRANSFER*/
ENDDTE PD3. /*END*DATE*TRANSFER*COMP*/
XCOMDATE PD4. /*DATE*RECORD*WRITTEN*/
SKEDDTE PD3. /*SCHEDULE*REQUEST*DATE*/
STARTDTE PD3. /*START*DATE*TRANSFER*/
ENDDTE PD3. /*END*DATE*TRANSFER*COMP*/
Fujitsu PDL Reports MXG 15.04 PROTECTS.
YY NUM2.
Fujitsu FACOM type 127 SMF. MXG 15.03 PROTECTS.
DATE PD4. ??yymodd
Fujitsu FACOM type 234 SMF. MXG 15.03 PROTECTS.
DATE PD4. ??yymodd
Goal Systems PDSMAN/XP MXG 15.03 PROTECTS.
LGDATX PD3.
LANDMARK TMON/CICS MXG 15.04 PROTECTS.
TMMDCCLK PK2. 0YYD
ENDDATE YYMMDD6. /*DATE WHEN*RECORD*PRODUCED TMMDDATE*
TIESDATE 2. YY
LANDMARK TMON FOR DB2 MXG 15.04 PROTECTS.
LMRKDATE YYMMDD6. /*DATE RECORD WAS PRODUCED */
ELRCDT YYMMDD6.
ELRMDT YYMMDD6.
DEELRCDT YYMMDD6.
DEELRCDT YYMMDD6.
LANDMARK TMON FOR MVS MXG 15.04 PROTECTS.
LMRKDATE 2. YY
JDINTST SMFSTAMP8. /*INTERVAL*START*TIME*/
JDITIME SMFSTAMP8. /*IPL DATETIMESTAMP*/
JDJSDATE PD4. /*JOB START DATE (00YYDDDF)*/
JDJEDATE PD4. /*JOB END DATE (00YYDDDF)*/
JDRDDATE PD4. /*DATE REPLY DETECTED (00YYDDDF)*/
JISDATE PD4. /*JOB START DATE */
JISTSDTE PD4. /*STEP START DATE */
JISTPDTE PD4. /*STEP STOP DATE */
Mobius INFOPAC MXG 15.04 PROTECTS.
Report Versions Database, Tableid=61,
Inverted Year in 2 EBCDIC bytes.
Start/End dates YYMMDD in PD4. VERIFY.
NOMAD NOMAD MXG 15.04 PROTECTS.
NSMFTLGN 5. YYDDD
ODI ODS/ODI Optical Disk MXG 15.04 PROTECTS.
YY NUM2. four times
SAP CICS JOURNAL MXG 15.03 PROTECTS.
STCDATE PD4. DDMMYY6. 0ddmmyyF
SAP SAP IMS log record MXG 15.03 PROTECTS.
type AEx.
STCDATE PD4. DDMMYY6. 0ddmmyyF
STERLING DMS LOG FILE MXG 15.04 PROTECTS.
CYEAR PIB1. YY
EXPYEAR PIB1. YY
LASTYEAR PIB1. YY
Velocity Software ESAMAP MXG 15.04 PROTECTS.
YY NUM2. for all dates in XAMCPU, XAMSYS, XAMUSR, XAMDEV.
Volvo (Europe) SESAME MXG 15.03 PROTECTS.
SESALODA PD3.
SESAISDA PD3.
SESAIEDA PD3.
SESAOCDA PD3.
SESACCDA PD3.
SESAOCOD PD3.
SESACCOD PD3.
APPENDIX 4 - Details of all non-IBM Fields which require VALIDATE
AION AION MXG 15.03 PROTECTS.
AIONDEND PD4.
AIONDSTR PD4.
AIONDSTR PD4.
AIONDEND PD4.
ALTAI ZARA MXG 15.03 PROTECTS.
FILDATEX PD4. /*EXPIRATION*DATE*/
FILDATEC PD4. /*CREATING*DATE*/
FILDATEL PD4. /*DATA*LAST*USED*/
BGS BGS I/O MONITOR MXG 15.03 PROTECTS.
BGSNSTLT PD4.
Boole & Babbage IMF MXG 15.03 PROTECTS.
ARRVDATE PD4.
STRTDATE PD4.
ENDDATE PD4.
MARRDATE PD4.
STRTDATE PD4
CA IDMS/R SMF RECORD MXG 15.03 PROTECTS.
PMHEDATE PD4. /*END*DATE*/
PMHSDATE PD4. /*START*DATE*/
CA TMS MXG 15.03 PROTECTS.
CREATIME PD4.
DSAUTIME PD4.
LASTTIME PD4.
TMAUTIME PD4.
TMAUDATE PD4.
TMVATIME PD4.
TMVADATE PD4.
CANDLE OMEGAMON AUDIT SMF. MXG 15.03 PROTECTS.
OMDATE PD4. /*DATE*STAMP*/
CANDLE OMEGAMON FOR VTAM MXG 15.03 PROTECTS.
EXNTIME PD4.
CANDLE ITRF MXG 15.03 PROTECTS.
EVENTIME PD4.
CINCOM SUPRA LOG RECORD MXG 15.03 PROTECTS.
SUPCDATE PD4.
SUPRDATE PD4.
SUPIDATE PD4.
Compuware FILEAID MXG 15.03 PROTECTS.
FATLDATE PD4.
Network Systems HMF (HyperChannel, MXG 15.03 PROTECTS.
also called DXE)
HMFHDDTE PD4.
RSD WSF MXG 15.03 PROTECTS.
ACCLDATE PD4.
SIMWARE SIM/XFER MXG 15.03 PROTECTS.
VXBSTME PD4.
VUXBETME PD4.
SOFTWARE AG'S NET-PASS MXG 15.03 PROTECTS.
NETPDISC PD4.
NETPLOGF PD4.
NETPLOGN PD4.
NETPRCON PD4.
STK ICEBERG MXG 15.03 PROTECTS.
ENDDATE PD4. /*INTERVAL END DATE-00Y
SYNCSORT SYNCSORT MXG 15.03 PROTECTS.
SORTBEGN PD4.
SORTEND PD4.
SYSTEM CENTER NDM (NETWORK DATA MXG 15.03 PROTECTS.
MOVER)
NDMENDTM PD4.
NDMNSKTM PD4.
NDMOSKTM PD4.
NDMSKDTM PD4.
NDMSETIM PD4.
NDMSSTIM PD4.
NDMSTRTM PD4.
NDMSUBTM PD4.
STEPTIME PD4.
NDMTIME PD4.
======================================================================
B.2. TIME versus STCK in MVS SAS date/time functions. Aug, 96
========================================================================
In MVS SAS, all functions that return dates/times (DATE(), DATETIME(),
TODAY(), etc.) use the MVS macro STCK (for STore ClocK), but STCK does
not return the century bit, while the TIME macro does return the bit.
Originally, an untested circumvention ZAP was listed here, but that was
not wise because it was not a supported ZAP, and because you should get
your SAS fixes from SAS Institute. SAS is actively researching an
implementation and this note will be revised when a SAS Usage Note
exists.
======================================================================
B.3. Algorithm to support CC Century bit in DATEJUL function.
Revised April 15, 1997 to map CC=0 and YY=00-59 to 2000-2059, see
Change 15.050.
Revised Jan 17, 1999 to store the converted yyyyddd julian date
value back into the input date variable, by inserting the line:
IF xxxxDATE GT . THEN xxxxDATE=YYYYDDD;
to replace an input julian field of 0100001 in cyyddd format with
2000001 in yyyyddd format so julian dates that can be converted.
("Invalid" date values, like 99000 are left unchanged).
While 0100001 value for 01Jan2001 is stored by MVS, converting that
to 2001001 julian date is preferred, because the SAS DATEJUL()
function accepts yyyyddd but not 0cyyddd values. This is only
important if the original input date variable xxxxDATE is kept; in
most cases, MXG has created a SAS DATE or DATETIME variable and the
julian date variable is not even kept. Examples were TMS and HSM
where both the SAS DATE/DATETIME variables and the Julian Date
variables are kept.
========================================================================
/* xxxxDATE contains 00yyddd, 0cyyddd or yyyyddd */
CC=FLOOR(xxxxDATE/100000);
YY=FLOOR((xxxxDATE-100000*CC)/1000);
DDD=MOD(xxxxDATE,1000);
IF 0 LT DDD LE 366 THEN DO;
IF CC EQ 0 AND YY LE 59 THEN YYYYDDD=DDD+1000*(YY+2000);
ELSE IF CC EQ 0 AND YY GE 60 THEN YYYYDDD=DDD+1000*(YY+1900);
ELSE IF 1 LE CC LE 2 THEN YYYYDDD=DDD+1000*(CC*100+YY+1900);
ELSE IF CC GE 19 THEN YYYYDDD=DDD+1000*(CC*100+YY);
ELSE YYYYDDD=.;
END;
ELSE YYYYDDD=.;
IF YYYYDDD GT . THEN xxxxdate=YYYYDDD;
IF YYYYDDD GT 0 THEN DATEYYYY=DATEJUL(YYYYDDD);
ELSE DATEYYYY=.;
IF DATEYYYY LE 0 THEN xxxxTIME=.;
ELSE xxxxTIME=DHMS(DATEYYYY,0,0,xxxxTIME);
======================================================================
3a. Algorithm to support CC Century bit in CYYMMDDF NPM data.
Added Mar 4, 1998. See Change 16.003.
========================================================================
/* xxxxDATE contains cyymmdd was input as PD4. */
/* xxxxTIME contains time in seconds, may be reused for datetime*/
CC=FLOOR(xxxxDATE/1000000);
YY=FLOOR((xxxxDATE-1000000*CC)/10000);
MO=FLOOR((xxxxDATE-1000000*CC-10000*YY)/100);
DD=xxxxDATE-1000000*CC-10000*YY-100*MO;
IF MO GT 0 THEN
xxxxTIME=DHMS(MDY(MO,DD,(YY+1900+CC*100)),0,0,xxxxTIME);
ELSE xxxxTIME=.;
======================================================================
B.4. Inverse Chronological changes to this member.
======================================================================
Jan 20 1999 Update.
Change 16.330 Status of MXG Year 2000 Support as of Jan 20, 1999.
ASUMHSM
TYPE80A MXG 16.09 is now required for full Year 2000 Support of
TYPEBETA all fields in all records from all supported products.
TYPEDCOL This replaces all prior statements of MXG Y2K Support.
TYPEHSM
TYPEMON8 MXG 16.01 and later do support almost all products, but
TYPEMOND five common products now require MXG 16.09 or later:
TYPEOPC HSM SMF Records
TYPETMON CA-1 aka TMS Tape Management Records
TYPETMS5 BETA93 SMF Records
TYPETMV2 Landmark Monitor for MVS Version 2
TYPETMVS VM Accounting records
TYPEVLFC Additionally, six other products that have variables
TYPEVM that were not Y2K compliant, but those variables were
YEAR2000 unlikely to have been used in your reports:
Jan 17, 1999 DCOLLECT - one julian date variable, UCCOLDT
Jan 20, 1999 OPC/A - three obscure julian date variables
Landmark - CICS: TYPEMON8,TYPETMON,TYPEMOND
MVS: TYPETMV2,TYPETMVS
one internal datetime TMMDCCLK.
ASTEX - one julian date SDATE
RACF SMF - two variables REVOKEDTE, RESUMEDTE
VLF - VLF Catalog records from SYSLOG.
Products were found with julian dates that were kept as
0cyyddd value (0100001 for 01Jan2000), which is a valid
Y2K format, but which is one not supported by SAS's
DATEJUL() function, so while MXG correctly created valid
Y2K values, your reports or exit logic would fail if they
used DATEJUL() on those 0cyyddd values. No ABEND, but
missing values or invalid argument messages on your log.
For example, TMS records have julian date values like the
EXPDT that are kept as 0cyyddd that could cause problems.
This DATEJUL() problem itself is not new. MXG reported
it and has provided an algorithm (described in member
YEAR2000, implemented by Change 15.050) that protects
julian dates as they are converted into SAS DATETIME
or DATE variables, which are Y2K compliant. But that
algorithm did not change the raw julian date value.
This change revises the protection algorithm so that it
now replaces the original 0cyyddd value with the valid
yyyyddd value in the raw julian date variable, unless the
yyyyddd value is missing (i.e., an invalid "date" like
99000), when the original raw value is not overwritten.
ASUMHSM testing with Y2K HSM records exposed the error,
and I realized that TMS and all products that keep julian
date variables were exposed, so every MXG member that had
a julian date field was examined, and I found four more
with the kept-julian-date-problem. I also found six
products (nine variables) that had been overlooked by MXG
Change 15.050 that were having unprotected sex with the
DATEJUL() function. All are now algorithm-protected.
Members with kept-julian-date-fields and the variables
that are now converted to yyyyddd:
TYPEDCOL UCCOLDT
TYPEHSM DSRDATE,VSRDATE,FSRBDATE,FSRDATR,FSRDLM,
FSRDLU
ASUMHSM DSRDATE
TYPEOPC TRLEVDAT,MT0CPED,MT0DAT
TYPETMS5 BTHDATE,CRTDT,DSADT,EXPDT,TMVADATE,LDATE,
TMAUDATE
TYPETMV2 JDRDATE
TYPETMVS (archaic) JDRDATE
Members overlooked in Change 15.050 and the variables
that are now protected:
TYPEBETA BETASTRT, BETAEND, BETASTSE, BETAENSE
TYPEDMON SDATE
TYPEHSM WFSRDATR, WFSRDATS, WFSRDATE
TYPETMV2 LMRKDATE, ENDTIME, STRTTIME
TYPETMVS (archaic) LMRKCARK
TYPE80A REVOKDTE, RESUMDTE
TYPEMOND TMMDCCLK
TYPEMON8 (archaic) TMMDCCLK
TYPETMON (archaic) TMMDCCLK
TYPEVLFC DATETIME
TYPEVM STARTIME, ENDTIME
In addition, thirty-five other members were changed
to streamline the algorithm where the creation of the
DATEYYYY variable was not required. These members
were and still are Y2K compliant, but are now more
robustly protected and their non-kept julian dates
are now converted to yyyyddd format:
TYPE90,TYPE84,TYPE434,TYPE37,TYPE1415,TYPE110,
TYPECTLT,TYPEFILA,TYPEIDMJ,TYPEIDMS,TYPEIMS,
TYPEIMSA,TYPEIPAC,TYPEITRF,TYPENDM,TYPENETP
TYPENSPY,TYPEOMVT,TYPEPDSM,TYPEROSC,TYPESIM,
TYPETRMS,TYPEWSF,TYPEXCOM,TYPEXSTR,TYPESUPR,
TYPESLRI,TYPERTEJ,TYPEDMS,IDMSLO57,IDMSJRNL,
ANALTMS,ANALSNAP,ANALRACF,ANALCM29
Apr 8 1998 Update.
a. Landmark CICS records from Version 2 that are converted back to
Version 8.1 format are now Year 2000 Ready, but as the change is
INCOMPATIBLE, MXG Version 16.01 is required. Landmark native
records from CICS V2 or MVS V2 were already Year 2000 Ready and
supported in MXG 15.15.
Mar 27 1998 Update.
a. IBM AS/400 records with year 2000 exposed an MXG logic error that
caused dates in that year to be 1960. The correction was provided
by Change 16.035, which is contained in MXG 16.01.
Mar 04 1998 Update.
a. IBM NETVIEW NPM type 28 records with CYYMMDDF format were found
in year 2000 test platform, requiring extensive changes for this
non-standard format, NPM was moved from WAS NOT to NOW IS by the
Change 16.003 which is contained in MXG 16.01.
Aug 06 1997 Update.
a. IBM documented many SMF records in OS/390 R2 as containing dates
in 0cyydddF format (which MXG expected, so no code change was
needed); those products were moved from MAYBE NOT to WAS MAYBE.
Aug 05 1997 Update.
a. Boole and Babbage identified the format for IMF aka MainView for
IMS 3.2 (replacing 00yydddF with yyyydddF, which MXG already
supported, so no MXG change was required), and they described the
change they will make in CICS Manager aka MainView for CICS 5.2
(incompatibly expanding the one-byte yy field into yyyy in their
header, now supported by Change 15.179 in MXG 15.04).
Boole also identified the owner of CONTROL-D as New Dimension.
Aug 01 1997 Update.
a. IBM Storage Management (DFP, Catalog, HSM, Rmm, DFSORT, DCOLLECT)
now documents in SMF 1.4 that all four-digit packed decimal fields
are 0cyydddF or yyyydddF, but in fact IBM code supporting the year
2000 is available all the way back to SMS 1.2, so DFP, HSM, DFSORT
and RMM entries in YEAR2000 are now "WAS NOT", or "WAS MAYBE".
However, some SMS fields are not going to be expanded by IBM:
-SMF type 36 YY character for export date will not be expanded.
IBM suggests the date is unambiguous if the SMFDATE field is
examined.
-HSM SMF three-byte PD3 fields in MCD/BCD/etc and user SMF record
will not be expanded. Again, IBM suggests a workaround using
the other dates in the record.
MXG's Change 15.167 protects these dates for MXG users.
Jul 15 1997 Update.
a. SMF type 14/15 CRDATE and EXPDT values documented.
IBM APAR OW13754 documents SMF type 14/15 CRDATE and EXPDT data values
are one-byte binary, with value to 255 to be added to the year 1900, so
those fields do support the year 2000 (and MXG was expecting this
definition, so no MXG change is required). This only supports dates
thru the year 2155, so our great-grandchildren will have another year
2xxx project in their future!
b. IBMLINK's SIS displays Item DBRPN dated 10Jul1997.
This IBM note correctly notes that type 14/15 records are compliant (see
preceeding) but claims that SMF type 36 records are compliant because
SMF36EDT (which has only YY in EBCDIC) can be resolved by using the SMF
timestamp's date value as a workaround. While not year 2000 compliant
in my opinion, the one field (Date of Export) is non-critical, and
furthermore, MXG has added protection (windowing) for that YY field.
c. DFSMS V1.4 documents DCOLLECT fields.
DFSMS Version 1.4 documents the DCOLLECT fields, some as ccyydddF and
some as yyyydddF, but MXG was prepared to handle either, so no MXG code
change is required.
d. Change 15.167 protects ALL dates:
Change 15.167 MXG now protects all two-digit YY dates for year 2000.
IMACICBB Since IBM and other vendors have not expanded all of the
TYPEDMS two-digit YY dates, and since it is likely that some MXG
TYPEMON8 sites will still be back level on some of those products
TYPEMONI that are not year-2000 compliant, and since I could cover
TYPEPDL for the negligent products, I have extended Change 15.050
TYPETMON and have added logic to "Window" all dates that are not
TYPEVM year-2000 compliant. Years 00-59 will be set to 20xx
VMAC28 while years 60-99 will be set to 19xx.
VMACCTLD In some members, this protection was added using:
VMACIPAC IF YEAR(DATEPART(datetime)) LE 1959 THEN
VMACNSM datetime=datetime+YEARSECS;
VMACNSPY where RETAIN YEARSECS 3155673600; is used to store the
VMACODS number of seconds between 1Jan1900 and 1Jan2000.
VMACOPC In other cases, the protection was added using:
VMACQTRT IF YEAR(date) LE 1959 THEN date=date+YEARDAYS;
VMACRMDS where RETAIN YEARDAYS 36524 is used to store the number
VMACROSC of days between 1Jan1900 and 1Jan2000.
VMACSAR
VMACTMDB Member YEAR2000 has been updated to show which dates
VMACVMXP are truly year 2000 compliant (and the APAR which made
VMACXAM them so) and to show which dates are not compliant but
YEAR2000 are now protected by MXG Logic to support the year 2000.
Jul 20, 1997
Apr 13 1997 Update.
a. DATETIME20.
Variables that were previously formatted with DATETIME18. have been all
changed to DATETIME20. so as to print 15AUG2019:12:00:00 rather than
just 15AUG19:12:00:00. The text of Change 15.045 provides further
discussion of using truncated datetime formats.est second. Most MXG
datetimestamps were changed to DATETIME21.2
b. TESTING CONSIDERATIONS FOR MXG AND FUTURE DATES.
In the MXG-supplied BUILDPDB, there is no date selection logic, so that
running BUILDPDB with a future date poses no problem. Only in MONTHBLD
is there any date selection, and there is selects observations by ZDATE
that belong in the just-ended month.
For the PDB.JOBS, PDB.STEPS, and PDB.PRINT datasets, if member IMACSPIN
specifies a SPINCNT greater than zero, then the SPIN library's datasets
are used to hold records for partially completed jobs, and the input
SPIN records are matched with today's SMF and the new-incomplete jobs
records are output (writing over) to the SPIN library for tomorrow's
processing. Thus if you are using your production //SPIN library, you
must copy it for safe keeping (your "Original" Spin), run your tests,
and then restore the //SPIN library from the original before tomorrow's
production runs.
It is possible that your site has added logic to the supplied BUILDPDB
job, and there may be tests of the Last Run Date (perhaps variable
LASTRUN in the SPIN.LASTRUN data set, to prevent duplicate runs or
skipped executions), and they may need to be bypassed for testing.
Jan 15 1997 Update.
Member YEAR2000 was restructured for claity, and the Appendices of the
original letter were revised to eliminate duplication between DO NOT
and MAY NOT, and the list of product fixes ("WAS NOT", "WAS MAYBE") was
introduced.
Jan 3 1997 Update.
Although not impacting MXG Software, it was pointed out that the value
returned by SAS for JULDATE() function is yyddd for dates prior to 2000
and is yyyyddd for dates on or after 01Jan2000. This is good, since it
keeps the dates in ascending order (99364,99365,2000001,2000002), but
if you have report programs that use the JULDATE() function, you will
need to examine them for potential impact of this difference.
Sep 14, 1996 Update.
IBM APAR OW15518 confirms that SMF records created by the SMF component
of MVS do in fact use the century bit (0cyydddF) in date time stamps in
normal SMF format, and so MXG already supports this IBM change for all
variables that are input using SMFSTAMP or RMFSTAMP informat.
May 27, 1996 Update.
In fifteen members, the datetime literal '01JAN00:00:00:00'DT was used
to initialize a variable to IBM's epoch datetime value, but that 00 year
value can be interpreted as 1900 or 2000, depending on the value of your
SAS option YEARCUTOFF, so MXG was changed to use '01JAN1900:00:00:00'DT
to always set the correct value. MXG uses this value only when decoding
raw records into SAS datasets, so it is highly unlikely that you would
have this literal value in your own SAS programs; nevertheless, it would
certainly be wise to search you SAS source libraries for its existence
and change to the intended value to support the year 2000. Change 14.100
changed members IMACEXCL,TYPEMOND,TYPEMONI,TYPEMONX,TYPEMON8,TYPETMON,
VMACCIMS,VMACHURN,VMACOMCI,VMACVMON,VMAC110,VMAC110M,VMAC110S, VMAC116
and VMACDB2H, which is included in MXG 14.03 and later.
April 25, 1996 Update.
IBM CICS APAR PN69653 plus CICS 4.1, or any later CICS has corrected the
two-digit YY value for field COLLTIME (Incompatibly!). That APAR is now
supported in MXG 14.02 or later.
November 14, 1995 Update.
The MXG Tape Mount and Tape Allocation Monitor (source in ASMTAPES) uses
the TIME macro to create timestamps in its SMF record to automatically
support the year 2000; the TIME macro returns 0cyydddF for the date, and
MXG knows about the century bit when it reads the MXGTMNT SMF records!
September 20, 1995 Update.
The TLMS product from CA does support the year 2000, but its data values
use the century bit, and change 13.186 was necessary to convert those
numbers (eg., 0100001 for 01Jan2000) into more recognizable numbers (eg.
converted to 2000001 in this example).
August 7, 1995 Update.
IBM letter published in MXG Newsletter 28 and put in member YEAR2000.
======================================================================
B.5. Verbatim original Jun 28, 1995 letter to IBM, uncorrected.
========================================================================
Jun 28, 1995
To: Jennifer Green
IBM Solution Developer Enablement Fax 914 432 9418
Tel 433 3823
Fr: Barry Merrill
Merrill Consultants
(MXG Software)
Re: Year2000 Project
a. Since MXG Software processes "every record on the face of the earth",
I have a unique capability to identify all date-containing-fields in all
externalized data records used for accounting, performance, etc., to
help IBM verify that its products support the next millenium, as well to
identify all non-IBM products that must be verified by their vendors to
be Year2000 compliant.
I have examined every date-containing field processed by MXG Software
and enclose herewith several Appendices which identify which products
require either "CHANGE" or "VALIDATE" to support the year 2000 and
beyond:
- "CHANGE" is required when the date in the record is not wide enough
to contain dates beyond 1999. Either the field must be relocated, or
the contents may be redefinable, but in either case both the vendor
and the processor of the data must change their programs.
For example, the fields that are YY in two-byte EBCDIC format
could be redefined as binary values, and processing software
can differentiate between binary and EBCDIC values without
relocation or expansion, since the years 00 to 99 in EBCDIC are
'F0F0'x thru 'F9F9'x, which is decimal 61680 thru 63993 as a
two-byte binary.
- "VALIDATE" is required for fields which currently contain a Julian
date in a packed decimal format of width 4. While this field width
is sufficient to contain the CCYYDDDF formatted date with century
bit, most fields are documented as 00YYDDDF; the program logic that
creates the 4-byte packed decimal field must be verified by the
vendor that the century-bit support has been coded:
- If the program uses the IBM TIME macro (which does now return
the century bit), the vendor must verify that the program has
been recently assembled (i.e., after the CC bit was added to the
TIME macro).
- If the program uses the IBM STCK macro, the vendor must verify
that its program creates the century bit, since reformatting STCK
to CCYYDDDF is done by the vendor's coding.
b. Please advise when all of the IBM products are themselves compliant.
I will be happy to process the IBM data records from a system that you
believe compliant that has been started with a date after 1999 to verify
that your products support the Year 2000.
c. I would hope that IBM would use the enclosed list of non-IBM products
to challenge those listed vendors who respond that their products are
compliant to ensure the vendor has corrected the specific date fields I
have identified herein. Especially for "CHANGE" fields, IBM should
require the vendor to provide the "fix number, or maintenance release"
that makes the change, and to document exactly how the vendor changed
the field, so that other vendors (like Merrill!) can ensure that our
customers have the correct level of the non-IBM products.
d. I recommend that IBM also take this opportunity, well in advance, to
address the YEAR2042 issue: at 23:53:48 on September 17, 2042, the IBM
8-byte hardware clock will fill and return to January 1, 1900. (I first
reported this in MXG Technical Newsletter THIRTEEN in January 1989.)
e. I separately include your Attachment B, certifying that MXG Software
itself is Year2000 compliant, and has been since its creation in 1984.
(In 1979, I attended a "Birds of a Feather" session at SHARE to discuss
how we would deal with the year 2000!).
f. Let me know how I can further assist!
Merrilly yours,
Herbert W. Barry Merrill, PhD
President-Programmer
Management Summary of Critical Products
IBM Products Requiring CHANGE (details in Appendix 1)
MVS CICS SMF type 110 APAR PN69653.
MVS DFP SMF type 36
MVS DFP VTOC
MVS NETVIEW NPM SMF type 28
MVS RMF SMF type 73, 74, 78
MVS SMF SMF type 14, 15
MVS HSM SMF user records
MVS OPC Log records
MVS NCCF Log records
MVS SYSLOG Log records OW18292.
VM VM ACCOUNT Accounting Records
IBM Products Requiring CHANGE or VALIDATE (details in Appendix 2)
MVS APPC SMF type 33
MVS Batch Pipes SMF type 91
MVS BDT SMF type 59
MVS CICS SMF type 110
MVS DFP CATALOG SMF type 36
MVS DFSORT SMF type 16
MVS JES2 NJE SMF type 57
MVS JES2 SMF type 6
MVS JES2 SMF type 24
MVS JES2 SMF type 26
MVS JES3 SMF type 25
MVS JES3 SMF type 26
MVS JES3 SMF TYPE 84
MVS MULC SMF type 89
MVS NETVIEW NPM SMF type 28
MVS NETVIEW NPM SMF type 37
MVS RMF SMF type 70-79
MVS SMF SMf type 4,5,7,14,15,30,32,34,35,90
MVS HSM SMF USER RECORD
MVS DCOLLECT IDCAMS output
MVS RMM EDGS Extract output
MVS FTP SMF record
MVS HSM SMF RECORDS
MVS IMS LOG Log records
MVS OPC Log records
MVS HSM MCD/BCD/ Log records
MVS DFP VTOC
MVS NETVIEW NCCF
VM VM ACCOUNT Accounting
Management Summary of Critical Products (continued)
non-IBM Products Requiring CHANGE (details in Appendix 3)
Vendor Product
CA SAR
CA NETSPY
CA XCOM
Goal Systems PDSMAN/XP
LANDMARK TMON/CICS
LANDMARK TMON FOR DB2
LANDMARK TMON FOR MVS
NOMAD NOMAD
STERLING DMS
Volvo (Europe) SESAME
non-IBM Products Requiring CHANGE or VALIDATE (details in Appendix 4)
Vendor Product
ALTAI ZARA
BGS BGS I/O MONITOR
Boole & Babbage IMF
CA IDMS/R SMF RECORD
CA ROSCOE
CA SAR
CA NETSPY
CA TMS
CA XCOM
CANDLE OMEGAMON AUDIT SMF RECORD
CANDLE OMEGAMON FOR VTAM
CANDLE ITRF
LANDMARK TMON/CICS
LANDMARK TMON FOR DB2
LANDMARK TMON FOR MVS
SAP CICS JOURNAL
STERLING DMS SMF USER RECORD
STK ICEBERG
SYSTEM CENTER NDM (NETWORK DATA MOVER)
SOFTWARE AG'S NET-PASS
SYNCSORT SYNCSORT
CINCOM SUPRA LOG RECORD
AION AION
Compuware FILEAID
Network Systems HMF (HyperChannel or DXE)
RSD WSF
Goal Systems PDSMAN/XP
NOMAD NOMAD
Volvo (Europe) SESAME
SIMWARE SIM/XFER
APPENDIX 0 - Description of the contents of the Appendices:
These appendices follow:
APPENDIX 1 - Details of all IBM Fields which require CHANGE
APPENDIX 2 - Details of all IBM Fields which require VALIDATE
APPENDIX 3 - Details of all non-IBM Fields which require CHANGE
APPENDIX 4 - Details of all non-IBM Fields which require VALIDATE
MXG Variable names are used in this listing, because that was the
quickest way to identify the fields which need CHANGE/VALIDATE.
I will be happy to work with product specialists to re-describe
their affected fields in terms of offset and record subtype and
vendor's original field names.
Formats of fields are shown in SAS (MXG's chosen language):
SMFSTAMP8. - 8-byte standard SMF time-and-date format,
4-byte time-since-midnight (binary, 2 decimals),
date in last four bytes, CCYYDDDF julian date
with century bit expected.
PD4. - Packed Decimal length 4, has ability to store
CCYYDDDF julian date.
PD3. - Packed Decimal length 3, room only for YYDDDF
PIB1. - Positive Integer Binary of length 1, can store
decimal values 0 thru 255.
PK1. - Packed Binary length 1 byte. ('99'x = 99 decimal).
can only store numbers 0 thru 99 in one packed byte.
2. - EBCDIC numeric length 2. ('F9F9'x = 99 decimal).
5. - EBCDIC numeric length 5. ('F9F9F3F6F5'x =99365).
YYMMDD6. - EBCDIC numeric length 6 ('F9F9F1F2F3F1'x =991231).
APPENDIX 1 - Details of all IBM Fields which require CHANGE
IBM CICS SMF type 110 APAR PN69653
COLLTIME 2. YY expanded, MXG 14.02+ supports.
IBM DFP CATALOG SMF type 36
EXPOTIME 2. YY
IBM NETVIEW NPM SMF type 28
BANDTDTE PD4. YYMMDD6. /*DATE OF BANDTIME*/
BANDTIME PD4. YYMMDD6. /*DATE RECORD RECEIVED BY NPM*/
BASNCPDT PD4. YYMMDD6. /*DATE OF BASTIME*/
COLLTIME PD4. YYMMDD6. /*END DATE*OF COLLECTION*/
LDRDATE PD4. YYMMDD6. /*DATE OF STARTIME*/
LNACCBSK PD4. YYMMDD6. /*DATE OF START*/
LNACCESK PD4. YYMMDD6. /*DATE OF END*/
LNADCBSK PD4. YYMMDD6. /*DATE OF START*/
LNADCESK PD4. YYMMDD6. /*DATE OF END*/
LNADDCTD PD4. YYMMDD6. /*DATE OF INTERVAL TIME STAMP*/
LNADDCTD PD4. YYMMDD6. /*DATE OF START*/
LNAEBDAT PD4. YYMMDD6. /*DATE OF COLLECTION BEGIN*/
LNAMBDAT PD4. YYMMDD6. /*DATE OF STARTIME*/
LNAMEDAT PD4. YYMMDD6. /*DATE OF COLLECTION END*/
LNARBDAT PD4. YYMMDD6. /*DATE OF COLLECTION BEGIN*/
LNEOCBSK PD4. YYMMDD6. /*DATE OF start*/
LNEOCESK PD4. YYMMDD6. /*DATE OF END*/
LNETBDAT PD4. YYMMDD6. /*DATE OF COLLECTION BEGIN*/
LSAACBSK PD4. YYMMDD6. /*DATE OF START*/
LSAACESK PD4. YYMMDD6. /*DATE OF END*/
LSAMBDAT PD4. YYMMDD6. /*DATE OF START*/
LSAMEDAT PD4. YYMMDD6. /*DATE OF END*/
LSTTCBSK PD4. YYMMDD6. /*DATE OF START*/
LSTTCESK PD4. YYMMDD6. /*DATE OF END*/
LVAMBDAT PD4. YYMMDD6. /*DATE OF START*/
LVAMEDAT PD4. YYMMDD6. /*DATE OF END*/
LXETTDTE PD4. YYMMDD6. /*DATE SENT BY NCP*/
LXETTMST 2. YY /*LXET*TIMESTAMP*LXETTMST*/
OGFEDATE PD4. YYMMDD6. /*DATE OF END*/
OGFSDATE PD4. YYMMDD6. /*DATE OF START*/
OGNSDATE PD4. YYMMDD6. /*DATE OF START*/
RMATBDAT PD4. YYMMDD6. /*DATE OF START*/
RMDTEDAT PD4. YYMMDD6. /*DATE OF END*/
SSAACBSK PD4. YYMMDD6. /*DATE OF START*/
SSAACESK PD4. YYMMDD6. /*DATE OF END*/
SSTTBDAT PD4. YYMMDD6. /*DATE OF START*/
SSTTEDAT PD4. YYMMDD6. /*DATE OF END*/
VADSDTEX PD4. YYMMDD6. /*JOBNAME/USERID*START DATE*/
VAPAPLDT PD4. YYMMDD6. /*END DATE*OF APPLICATION*ACTIVATION*/
and many more!
IBM RMF SMF type 73
IODFDATE 2. YY /*SMF73TDT IODF*CREATE*DATE*/
IBM RMF SMF type 74
IODFDATE 2. YY /*SMF74TDT IODF*CREATE*DATE*/
IBM RMF SMF TYPE 78
IODFDATE 2. YY /*SMF78TDT IODF*CREATE*DATE*/
IBM SMF SMF type 14,15
OPENDTE PD4.
CRDATE PIB1. YY
EXDYY PIB1. YY
IBM HSM SMF user RECORDS
DSRDATE PD3. YY
IBM OPC
TRLEVDAT PD4. /* EVENT DATE 00YYDDDF */
TRLIAD23 2. YY
MT0CPET 2. YY
MT0DATE PD4. /* DATE OF UPDATE */
MT0IMD 2. YY
MT0IAD 2. YY
MT0DLD 2. YY
IVLFRDAT 2. YY
IVLTODAT 2. YY
MTDIAD 2. YY
MTDDLD 2. YY
MTDDIAD 2. YY
TRLIAD25 2. YY
TRLIAD26 2. YY
TRLIAD27 2. YY
TRLIAD28 2. YY
ETCLDATE 2. YY
TRLIAD32 2. YY
TRLIAD33 2. YY
TRLIAD34 2. YY
EXRDATE 2. YY
EXRRDATE 2. YY
EXRSDATE 2. YY
EXREDATE 2. YY
VSRDATE PD3. /* DATE */
IBM VTOC
CRDATE PIB1. YY
EXPDT PIB1. YY
LASTUSED PIB1. YY
IBM NCCF
NCCFDTTM PD3. YY
IBM SYSLOG OW18292.
EVENTIME 2. YY
IBM VM ACCOUNT
ACCTTIME 2. YY
ONTIME 2. YY IN PD8.
OFFTIME 2. YY IN PD8.
APPENDIX 2 - Details of all IBM Fields which require VALIDATE
IBM APPC SMF type 33
REQDTIME SMFSTAMP8. /*SMF33FMT,FMD REQ REGOGNIZED BY
REQDTIME SMFSTAMP8. /*SMF33FMT,FMD REQ REGOGNIZED BY FMH5*
SKEDTIME SMFSTAMP8. /*SMF33TQT,TQD REQ ON SKED QUEUE*/
TPNDTIME SMFSTAMP8. /*SMF33TET,TED REQ EXECUTION ENDED*/
TPSTTIME SMFSTAMP8. /*SMF33TST,TSD REQ EXECUTION START*/
IBM Batch Pipes SMF type 91
AFSTTIME SMFSTAMP8. /*SMF91IFT*1ST ACC*TO THE PIPE*THIS CONN*/
ALSTTIME SMFSTAMP8. /*SMF91OLT LAST ACC*TO THE PIPE*THIS CONN*
PALCTIME SMFSTAMP8. /*PIPE ALLOCATION FOR THIS CONNECTION*/
PCLOTIME SMFSTAMP8. /*PIPE CLOSED FOR THIS CONNECTION*/
POPCTIME SMFSTAMP8. /*PIPE OPEN COMPLETED FOR THIS CONNECTION*
POPNTIME SMFSTAMP8. /*PIPE OPEN REQUESTED FOR THIS CONNECTION*
SMF91SCT SMFSTAMP8. /*STATUS*CHANGED*DATETIMESTAMP*/
INTBTIME SMFSTAMP8. /*SMF91IST INTERVAL*BEGIN*TIMESTAMP-LOCAL*
IBM BDT SMF type 59
ENDTIME SMFSTAMP8.
QUEUTIME SMFSTAMP8.
XMENTIME SMFSTAMP8.
XMITTIME SMFSTAMP8.
IBM CICS SMF type 110
CICSTRSD PD4. /*CICS*JOB*DATE*/
IBM DFP CATALOG SMF type 36
EXPOTIME 2. YY
IBM DFSORT SMF type 16
ENDTIME SMFSTAMP8. /*ICETIMEE*/
STRTTIME SMFSTAMP8. /*ICETIMES*/
IBM JES2 NJE SMF type 57
XMITTIME SMFSTAMP8.
XMENTIME SMFSTAMP8.
IBM JES2 SMF type 6
PRINTIME SMFSTAMP8. /*SMF6WST+SMF6WSD*/
IBM JES2 SMF type 24
OFLDTIME SMFSTAMP8. /*OFFLOAD DATASET ALLOCATION*/
IBM JES2 SMF type 26
JRDRTIME SMFSTAMP8. /*SMF26RPT+SMF26RPD*/
JCNVTIME SMFSTAMP8. /*SMF26CST+SMF26CSD*/
JSTRTIME SMFSTAMP8. /*SMF26XST+SMF26XSD*/
JENDTIME SMFSTAMP8. /*SMF26XPT+SMF26XPD*/
JPRNTIME SMFSTAMP8. /*SMF26OST+SMF26OSD*/
JFINTIME SMFSTAMP8. /*SMF26OPT+SMF26OPD*/
XMITTIME SMFSTAMP8.
XMENTIME SMFSTAMP8.
IBM JES3 SMF type 25
FETCTIME SMFSTAMP8.
MNTTIME SMFSTAMP8.
STRTTIME SMFSTAMP8.
VERFTIME SMFSTAMP8.
IBM JES3 SMF type 26
DLNETIME SMFSTAMP8.
JRDRTIME SMFSTAMP8.
JCNVTIME SMFSTAMP8.
JSTRTIME SMFSTAMP8.
JENDTIME SMFSTAMP8.
JPRNTIME SMFSTAMP8.
JFINTIME SMFSTAMP8.
IBM JES3 SMF TYPE 84
JMFEDTE PD4. /*JMF INTERVAL END DATE*/
JMFSDTE PD4. /*JMF INTERVAL START DATE*/
IBM MULC SMF type 89
SMF89IET SMFSTAMP8. /*REPORTING*INTERVAL*ENDTIME*/
SMF89IST SMFSTAMP8. /*REPORTING*INTERVAL*STARTIME*/
SMF89UET SMFSTAMP8. /*USAGE DATA*INTERVAL*ENDTIME*/
SMF89UST SMFSTAMP8. /*USAGE DATA*INTERVAL*STARTIME*/
IBM NETVIEW NPM SMF type 28
BANDTIME PD4. YYMMDD6. /*DATE RECORD RECEIVED BY NPM*/
COLLTIME PD4. YYMMDD6. /*END DATE*OF COLLECTION*/
LNAMEDAT PD4. YYMMDD6. /*DATE OF COLLECTION END*/
LXETTDTE PD4. YYMMDD6. /*DATE SENT BY NCP*/
LXETTMST 2. YY /*LXET*TIMESTAMP*LXETTMST*/
LNARBDAT PD4. YYMMDD6. /*DATE OF COLLECTION BEGIN*/
LNETBDAT PD4. YYMMDD6. /*DATE OF COLLECTION BEGIN*/
LNADDCTD PD4. YYMMDD6. /*DATE OF INTERVAL TIME STAMP*/
VADSDTEX PD4. YYMMDD6. /*JOBNAME/USERID*START DATE*/
VAPAPLDT PD4. YYMMDD6. /*END DATE*OF APPLICATION*ACTIVATION*/
IBM NETVIEW NPM SMF type 37
NPDADATE PD4. /*NPDA*DATE*/
IBM RMF SMF type 73
IODFDATE 2. YY /*SMF73TDT IODF*CREATE*DATE*/
IBM RMF SMF type 74
IODFDATE 2. YY /*SMF74TDT IODF*CREATE*DATE*/
IBM RMF SMF TYPE 78
IODFDATE 2. YY /*SMF78TDT IODF*CREATE*DATE*/
IBM SMF All SMF records.
SMFSTAMP SMFSTAMP8.
READTIME SMFSTAMP8. (in all job-related records, but copied
from a single control block).
IBM SMF SMF type 4, 34
INITDATE PD4.
IBM SMF SMF type 5, 35
ENQTIME SMFSTAMP8.
JINITIME SMFSTAMP8.
IBM SMF SMF type 7
LOSSTIME SMFSTAMP8.
IBM SMF SMF type 14,15
OPENDTE PD4.
CRDATE YY PIB1.
EXDYY YY PIB1.
IBM SMF SMF type 30
REND SMFSTAMP8. /*SMF30RDE,RET,RED*/
INITTIME SMFSTAMP8. /*SMF30SIT,STD*/
SMF30IST SMFSTAMP8. /*SMF30IST,SMF30IDT*/
IBM SMF SMF type 32
INITTIME SMFSTAMP8. /*SMF32SIT,STD*/
IBM SMF SMF type 90
NEWTIME PD4.
OLDTIME PD4.
IBM HSM SMF USER RECORD
FSRDATR PD4. /* DATE USER MADE REQ
IBM VM ACCOUNT
ACCTTIME 2. YY
ONTIME 2. YY IN PD8.
OFFTIME 2. YY IN PD8.
IBM DCOLLECT
DCUTMSTP SMFSTAMP8.
UBTIME PD4.
UMTIME PD4.
DCDCREDT PD4
DCDEXPDT PD4.
DCDLSTRF PD4.
UMCREDT PD4.
UMLRFDT PD4.
UCCDATE PD4.
SDATE PD4.
IBM RMM EDGS
MDLRDATE PD4. /*DATE*LAST*READ*/
MDLWDATE PD4. /*DATE*LAST*WRITTEN*/
MKDELDAT PD4. /*AUTOMATIC*DELETE*DATE*/
MVEXPDT PD4. /*EXPIRATION*DATE*(CHAR)*ORIGINAL*/
MVLRDDAT PD4. /*DATE*VOLUME*LAST READ*/
MVLWDDAT PD4. /*DATE*VOLUME*LAST WRITTEN*/
MVSTDATE PD4. /*DATE*STORED*/
EDGSADTE PD4. /*ACTION*CREATE*TIME*/
EDGSARSD PD4. /*READER*START*DATE*/
MACRDATE PD4. /*ACTION*CREATE*DATE*/
MALCDATE PD4. /*LAST*CHANGE*DATE*/
MAUCDATE PD4. /*LAST USER*CHANGE*DATE*/
MDCRDATE PD4. /*DSN*CREATE*DATE*/
MDLCDATE PD4. /*LAST*CHANGE*DATE*/
MDLRDATE PD4. /*DATE*LAST*READ*/
MDLWDATE PD4. /*DATE*LAST*WRITTEN*/
MDUCDATE PD4. /*LAST USER*CHANGE*DATE*/
MKCRDATE PD4. /*DSN*CREATE*DATE*/
MKDELDAT PD4. /*AUTOMATIC*DELETE*DATE*/
MKLCDATE PD4. /*LAST*CHANGE*DATE*/
MKUCDATE PD4. /*LAST USER*CHANGE*DATE*/
MOCRDATE PD4. /*DSN*CREATE*DATE*/
MOLCDATE PD4. /*LAST*CHANGE*DATE*/
MOUCDATE PD4. /*LAST USER*CHANGE*DATE*/
MPCRDATE PD4. /*DSN*CREATE*DATE*/
MPLCDATE PD4. /*LAST*CHANGE*DATE*/
MPUCDATE PD4. /*LAST USER*CHANGE*DATE*/
MRCRDATE PD4. /*DSN*CREATE*DATE*/
MRLCDATE PD4. /*LAST*CHANGE*DATE*/
MRUCDATE PD4. /*LAST USER*CHANGE*DATE*/
MVASDATE PD4. /*ASSIGNED*DATE*/
MVCRDATE PD4. /*DSN*CREATE*DATE*/
MVEXPDT PD4. /*EXPIRATION*DATE*(CHAR)*ORIGINAL*/
MVLCDATE PD4. /*LAST*CHANGE*DATE*/
MVLRDDAT PD4. /*DATE*VOLUME*LAST READ*/
MVLWDDAT PD4. /*DATE*VOLUME*LAST WRITTEN*/
MVSTDATE PD4. /*DATE*STORED*/
MVUCDATE PD4. /*LAST USER*CHANGE*DATE*/
IBM FTP
DVGASTIM PD4.
DVGARDAT PD4.
DVGANBTD PD4.
DVGANATD PD4.
DVGDSTIM PD4.
DVGQSTIM PD4.
DVGCSTIM PD4.
DVGRSTIM PD4.
DVGNXMST PD4.
DVGNXMET PD4.
IBM HSM SMF RECORDS
FSRRSD PD4. /* DUMMY FOR FSRRSD
DSRDATE PD3. YY
IBM IMS LOG
GUTIME PD4.
ENDTIME PD4.
STRTTIME PD4.
GUTIME PD4.
ENQTIME PD4.
DEQTIME PD4.
SYNCDATE PD4. /* DATE OF SYNC POINT 00YYDDDF
IBM OPC
TRLEVDAT PD4. /* EVENT DATE 00YYDDDF */
TRLIAD23 2. YY
MT0CPET 2. YY
MT0DATE PD4. /* DATE OF UPDATE */
MT0IMD 2. YY
MT0IAD 2. YY
MT0DLD 2. YY
IVLFRDAT 2. YY
IVLTODAT 2. YY
MTDIAD 2. YY
MTDDLD 2. YY
MTDDIAD 2. YY
TRLIAD25 2. YY
TRLIAD26 2. YY
TRLIAD27 2. YY
TRLIAD28 2. YY
ETCLDATE 2. YY
TRLIAD32 2. YY
TRLIAD33 2. YY
TRLIAD34 2. YY
EXRDATE 2. YY
EXRRDATE 2. YY
EXRSDATE 2. YY
EXREDATE 2. YY
IBM HSM MCD/BCD/ETC RECORDS
BCRCDATE PD4. /* DATE CYCLE WAS DEFINED */
BCRBL1D PD4. /* DATE L1 FUNCTIONS PERFORMED */
BCRDBLA PD4. /* DATE ARCGEN LAST UN-WAITED */
BCRDSAB PD4. /* DATE " " " " " */
DCRDATE PD4. /* DUMP CYCLE START DATE */
DCRSTRDT PD4. /* DATE AUTO FUNCT LAST START */
DCRCMPDT PD4. /* DATE LAST COMPL AUTO FUNCT END */
DCRCKDAT PD4. /* DATE " " " */
DCRCCDAT PD4. /* DATE CYC DAY AUTO STRT CHKD */
DCRDCDAY PD4. /* DATE LAST AUTO FUNCT FROM BEGNG*/
DGNTSDD PD4. /* DATE " " " */
DGNEXPDT PD4. /* EXPDT THIS DUMP COPY OR 0 */
DGNCYLDT PD4. /* DATE FULL VOL DUMP BEGAN */
DSRDATE PD3. /* DATE *
DVLTSDD PD4. /* DATE DUMP COPY WRITTEN */
DVLDEXPD PD4. /* EXPDT IF VALID ELSE X00 */
MCBDBU PD4. /* DATE LAST BACKUP */
MCBDLRPB PD4. /* NON-VSAM DATE LAST REFERENCD*/
MCBCDATE PD4. /* DATE THIS BKUP VERSN MADE */
MCCTSBUD PD4. /* DATE VERSION CREATED */
MCCTSLUD PD4. /* DATE LST VSM UPDT OR CRDT */
MCDDMIG PD4. /* X'00YYDDDS' DATE MIGRATED */
MCDDLC PD4. /* X'00YYDDDS' DATE DATA SET CREATD*/
MCDDLR PD4. /* X'00YYDDDS' DATE DATA LAST USED
MCDDLU PD4. /* X'00YYDDDS' DATE VSAM LAST USED
MCDDRES PD4. /* X'00YYDDDS' DATE RECALL OR DELET
MCDEXPDT PD4. /* X'00YYDDDS' EXPIRATION DATE
MCPDTSDD PD4. /* DATE " " " */
MCPTSLBD PD4. /* DATE LAST BACKUP FROM THIS VOL*/
MCPVTCD1 PD4.
MCPVTCD2 PD4.
MCPVTCD3 PD4.
MCPVTCD4 PD4.
MCPLDEXP PD4.
MCRLGMSD PD4.
MCRGMSD PD4. /* DATE " " " " " */
MCRLGMED PD4.
MCRCDATE PD4. /* DATE LAST MIG. CLEANUP */
MCRNSPKD PD4. /* DATE NEXT SP CK FOR INT MIG */
MCTTSLCD PD4. /* DATE VOL LAST CLEANED UP */
MCTTSLSD PD4. /* DATE VOL LAST SPILLED */
MCVTSLMD PD4. /* DATE LAST MIG NOT VALID L1*/
MCVLSPCD PD4. /* DATE LAST LSPACE YYDDD */
MHCRBGND PD4. /* DATE X00YYDDDS SP. CALC. STR
MHCRENDD PD4. /* DATE SPACE CALC. ENDED
MHCRNXTD PD4. /* DATE NEXT CALC S.B. DONE
VSRDATE PD3. /* DATE */
IBM VTOC
CREATED=DATEJUL(CRDATE)+CRCENT*
CRDATE PIB1. YY
EXPDT PIB1. YY
LASTUSED PIB1. YY
IBM NCCF
NCCFDTTM PD3. YY
IBM SYSLOG OW18292.
EVENTIME $2. YY
APPENDIX 3 - Details of all non-IBM Fields which require CHANGE
CA SAR
SARATIME 2. YY
SARPTIME 2. YY
CA NETSPY
SNITIME PK1. YY
CA XCOM
SKEDDTE PD3. /*SCHEDULE*REQUEST*DATE*/
STARTDTE PD3. /*START*DATE*TRANSFER*/
ENDDTE PD3. /*END*DATE*TRANSFER*COMP*/
XCOMDATE PD4. /*DATE*RECORD*WRITTEN*/
SKEDDTE PD3. /*SCHEDULE*REQUEST*DATE*/
STARTDTE PD3. /*START*DATE*TRANSFER*/
ENDDTE PD3. /*END*DATE*TRANSFER*COMP*/
Goal Systems PDSMAN/XP
LGDATX PD3.
LANDMARK TMON/CICS
ENDDATE YYMMDD6. /*DATE WHEN*RECORD*PRODUCED TMMDDATE*
TIESDATE 2. YY
LANDMARK TMON FOR DB2
LMRKDATE YYMMDD6. /*DATE RECORD WAS PRODUCED */
LMRKCARK PK2. 0YYD
LANDMARK TMON FOR MVS
LMRKDATE 2. YY
LMRKCARK PK2. 0YYD
NOMAD NOMAD
NSMFTLGN 5. YYDDD
STERLING DMS SMF USER RECORD
CYEAR PIB1. YY
EXPYEAR PIB1. YY
LASTYEAR PIB1. YY
Volvo (Europe) SESAME
SESALODA PD3.
SESAISDA PD3.
SESAIEDA PD3.
SESAOCDA PD3.
SESACCDA PD3.
SESAOCOD PD3.
SESACCOD PD3.
APPENDIX 4 - Details of all non-IBM Fields which require VALIDATE
ALTAI ZARA
FILDATEX PD4. /*EXPIRATION*DATE*/
FILDATEC PD4. /*CREATING*DATE*/
FILDATEL PD4. /*DATA*LAST*USED*/
BGS BGS I/O MONITOR
BGSNSTLT PD4.
Boole & Babbage IMF
ARRVDATE PD4.
STRTDATE PD4.
ENDDATE PD4.
MARRDATE PD4.
STRTDATE PD4
CA IDMS/R SMF RECORD
PMHEDATE PD4. /*END*DATE*/
PMHSDATE PD4. /*START*DATE*/
CA ROSCOE
EDATEJ PD4.
SDATEJ PD4.
DATEJ PD4.
ROSDATE PD4.
SDATE NUM2. (three places)
CA SAR
SARATIME 2. YY
SARPTIME 2. YY
SARBDATE PD4. /*LAST*BROWSED*DATE*/
CA NETSPY
SNITIME PK1. YY
STARTIME PD4.
STOPTIME PD4.
CA TMS
CREATIME PD4.
DSAUTIME PD4.
LASTTIME PD4.
TMAUTIME PD4.
TMAUDATE PD4.
TMVATIME PD4.
TMVADATE PD4.
CA XCOM
SKEDDTE PD3. /*SCHEDULE*REQUEST*DATE*/
STARTDTE PD3. /*START*DATE*TRANSFER*/
ENDDTE PD3. /*END*DATE*TRANSFER*COMP*/
XCOMDATE PD4. /*DATE*RECORD*WRITTEN*/
SKEDDTE PD3. /*SCHEDULE*REQUEST*DATE*/
STARTDTE PD3. /*START*DATE*TRANSFER*/
ENDDTE PD3. /*END*DATE*TRANSFER*COMP*/
CANDLE OMEGAMON AUDIT SMF RECORD
OMDATE PD4. /*DATE*STAMP*/
CANDLE OMEGAMON FOR VTAM
EXNTIME PD4.
CANDLE ITRF
EVENTIME PD4.
LANDMARK TMON/CICS
TMMDCCLK PK2. 0YYD
ENDDATE YYMMDD6. /*DATE WHEN*RECORD*PRODUCED TMMDDATE*
TIESDATE 2. YY
LANDMARK TMON FOR DB2
ENDTIME = DHMS(LMRKDATE,0,0,LMRKTIME*64);
LMRKDATE YYMMDD6. /*DATE RECORD WAS PRODUCED */
LMRKCARK PK2. 0YYD
LANDMARK TMON FOR MVS
LMRKDATE 2. YY
LMRKCARK PK2. 0YYD
JDINTST SMFSTAMP8. /*INTERVAL*START*TIME*/
JDITIME SMFSTAMP8. /*IPL DATETIMESTAMP*/
JDJSDATE PD4. /*JOB START DATE (00YYDDDF)*/
JDJEDATE PD4. /*JOB END DATE (00YYDDDF)*/
JDRDDATE PD4. /*DATE REPLY DETECTED (00YYDDDF)*/
JISDATE PD4. /*JOB START DATE */
JISTSDTE PD4. /*STEP START DATE */
JISTPDTE PD4. /*STEP STOP DATE */
SAP CICS JOURNAL
STCDATE PD4. DDMMYY6.
STERLING DMS SMF USER RECORD
CYEAR PIB1. YY
EXPYEAR PIB1. YY
LASTYEAR PIB1. YY
STK ICEBERG
ENDDATE PD4. /*INTERVAL END DATE-00Y
SYSTEM CENTER NDM (NETWORK DATA MOVER)
NDMENDTM PD4.
NDMNSKTM PD4.
NDMOSKTM PD4.
NDMSKDTM PD4.
NDMSETIM PD4.
NDMSSTIM PD4.
NDMSTRTM PD4.
NDMSUBTM PD4.
STEPTIME PD4.
NDMTIME PD4.
SOFTWARE AG'S NET-PASS
NETPDISC PD4.
NETPLOGF PD4.
NETPLOGN PD4.
NETPRCON PD4.
SYNCSORT SYNCSORT
SORTBEGN PD4.
SORTEND PD4.
CINCOM SUPRA LOG RECORD
SUPCDATE PD4.
SUPRDATE PD4.
SUPIDATE PD4.
AION AION
AIONDEND PD4.
AIONDSTR PD4.
AIONDSTR PD4.
AIONDEND PD4.
Compuware FILEAID
FATLDATE PD4.
Network Systems HMF (HyperChannel or DXE)
HMFHDDTE PD4.
RSD WSF
ACCLDATE PD4.
Goal Systems PDSMAN/XP
LGDATX PD3.
NOMAD NOMAD
NSMFTLGN 5. YYDDD
Volvo (Europe) SESAME
SESALODA PD3.
SESAISDA PD3.
SESAIEDA PD3.
SESAOCDA PD3.
SESACCDA PD3.
SESAOCOD PD3.
SESACCOD PD3.
SIMWARE SIM/XFER
VXBSTME PD4.
VUXBETME PD4.
======================================================================
B.6. Products discovered in August, 1995, not in original table.
(Have been added to the revised letter.)
========================================================================
ANALIPAC - InfoPac Report Versions Database, Tableid=61, Inverted Year
in 2 EBCDIC bytes. CHANGE required.
Infopac SMF record - Start/End dates YYMMDD in PD4. VERIFY.
IMACICBB - Boole and Babbage CICS/Manager type 110 subtype 'BB'x SMF
subtype STID=200 PK1. YY for STIDTIME. CHANGE required.
subtype STID=201 PK1. YY for STIDTIME. CHANGE required.
subtype STID=202 PK1. YY for STIDTIME. CHANGE required.
subtype STID=203 PK1. YY for STIDTIME. CHANGE required.
subtype STID=204 PK1. YY for STIDTIME. CHANGE required.
subtype STID=205 PK1. YY for STIDTIME. CHANGE required.
TYPEPDL - Fujitsu PDL reports, YY NUM2. CHANGE required.
TYPESAM - RMF System Availability Measurement (believed defunct)
YY NUM2. CHANGE required.
TYPECTLD - Control-D YY NUM2. CHANGE required.
TYPEF127 - Fujitsu FACOM type 127 SMF record. Date in PD4. format
xxyymodd as decimal value fits, but xx could be either
01 as a century bit or xxyy could be 2001. CHANGE-HOW
documentation required.
TYPEF234 - Fujitsu FACOM type 234 SMF record. Same as TYPEF127.
VMACIMS - SAP IMS log record type AEx (174). PD4. 0DDMMYYF.
CHANGE required.
VMACODS - ODS/ODI Optical Disk SMF record. YY NUM2. RPTTIME four
times. CHANGE required.
VMACQAPM - AS/400, OS/400. All records contain YY NUM2, except for
the QAPMCONF Start event, which contains the CC Century
bit, which can be retained for processing by MXG to protect
the other date fields (assuming a Start event is always the
first record in the file).
VMACQTRT - AS/400 Trace Data - TRNYEAR PD3. - CHANGE Required.
VMACRMDS - RMDS - RMDSORG 'A','C','M' and RECKDY='4040'x/'8080'x,
RMDSORG 'B','D','V' Also, RMDSORG='B'/'D'/'U'
sixteen occurrences of YY NUM2. CHANGE required.
VMACRSIO - RS6000 IOSTAT,PSSTAT,VMSTAT trapped output; YY NUM2 in the
VMACRSPS date created by the script. Script must be changed.
VMACRSVM
VMACSFS Xerox Shared File System. DATE YY NUM2. CHANGE required.
VMACVMON VM/370 Monitor COLLTIME, YY NUM2. CHANGE required.
VMACVMXP CA/LEGENT VM/EXPLORE DATE,RDATE,ULOGDATE,TSELABDA,TSELABA
all YY NUM2. CHANGE required.
VMACXAM Velocity Software XA (now ESA) Monitor. YY NUM2. for all
dates in XAMCPU, XAMSYS(twice), XAMUSR, XAMDEV.
CHANGE required.
========================================================================