Re: SMFxTME field
Slide cursor over relevant portion and hit Reply In a message dated 1/8/2016 11:21:56 A.M. Central Standard Time, 004dc9e91b6d-dmarc-requ...@listserv.ua.edu writes: Sorry, I don't see how to quote a prior message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
Sorry, I don't see how to quote a prior message. This is what worked for me from Charles. "Divide by 100 -- remainder is hundredths of a second. Divide quotient by 60 -- remainder is seconds. Divide quotient by 60 -- remainder is minutes. Quotient is hours (24 hour clock). SMFxxDTE is in an amusing packed format: 0cyydddF where c is the century offset by 19 -- that is, 01 => 2000; yy is the low order digits of the year; and ddd is the "Julian" day number of the year: 001 = January 1, ... 365 = December 31 (366 for leap years). " Janet -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
Much more beautiful: qu'est ce que c'est que cela? (What is it that that is that there) Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ted MacNEIL Sent: 08 January, 2016 9:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMFxTME field That that is is that that is not is not is that it it is - -teD - Original Message From: Ed Finnell Sent: Friday, January 8, 2016 03:33 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: SMFxTME field That that is is that that is not is not? In a message dated 1/7/2016 7:02:55 P.M. Central Standard Time, charl...@mcn.org writes: "that"? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
That that is is that that is not is not is that it it is - -teD - Original Message From: Ed Finnell Sent: Friday, January 8, 2016 03:33 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: SMFxTME field That that is is that that is not is not? In a message dated 1/7/2016 7:02:55 P.M. Central Standard Time, charl...@mcn.org writes: "that"? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
Janet Graff wrote: >That worked. Now I have the time formatted very nicely. What worked? Please be kind to clarify what worked and what reply/replies really helped you? It would really help if the persons who asked for help, also post the results of success/failures on IBM-MAIN so that future searches can get those solutions. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
That that is is that that is not is not? In a message dated 1/7/2016 7:02:55 P.M. Central Standard Time, charl...@mcn.org writes: "that"? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
Which "that"? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Janet Graff Sent: Thursday, January 07, 2016 5:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMFxTME field That worked. Now I have the time formatted very nicely. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
That worked. Now I have the time formatted very nicely. Thank you! Janet -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
It's actually the SMFSTAMP8. format provided in the SAS language that converts the datetime format into a SAS datetime variable, which contains the number of seconds plus/minus Jan 1, 1960, the IBM epoch. (Unix and other use 1970). There are 670 instances of variables INPUT with the SMFSTAMP8 informat in the MXG source library, and 1538 instances of variables INPUT with TODSTAMP8 informat. SMFSTAMP is limited to 2 decimal resolution (10 milliseconds) while most TODSTAMP8 fields have microsecond resolution. One of the beauties of SAS datetime variables is the ability to under specify the length of the datetime FORMAT (DATETIME21.2 for SMFSTAMP, DATETIME25.6 for TODSTAMP) so that FORMAT VARIABLE DATE9. ; can be used to summarize/report by DATE (06JAN2016) without creating a DATE variable, or FORMAT VARIABLE DATETIME12.; can be used to report/summarize by DATE and HOUR (06JAN2016:12) and FORMAT VARIABLE DATETIME13. can be used report/summarize by DATE/HOUR/and MINUTE (06JAN2016:12:30) without creating new variables. MERRILLY NEW YEAR, Barry Herbert W. “Barry” Merrill, PhD President-Programmer MXG Software Merrill Consultants 10717 Cromwell Drive Dallas, TX 75229-5112 ba...@mxg.com Fax: 214 350 3694 – Still works, received as email Tel: 214 351 1966 – Unreliable, please use email www.mxg.comHomePage: FAQ answers most questions ad...@mxg.com License Forms, Invoice, Payment, ftp information supp...@mxg.comTechnical Issues MXG-L FREE ListServer http://www.mxg.com/mxg-l_listserver/ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Neil Duffee Sent: Wednesday, January 06, 2016 2:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMFxTME field Caveat: with daily digesting, I'm at least a day behind the discussion... Actually, I believe that MXG is SMFxxDTE & SMFxxTME cognizant by virtue of using the underlying SAS 'inFormat's SMFDATETIME, SMFDATE, & SMFTIME. I do my SMF reporting using SAS directly and, using SMFDATETIME, get SAS Date/DateTime variables [1] that can have the (out) 'Format's you desire. [1] If I remember rightly, the SAS internal representations are #seconds or days from an arbitrary point ie. Jan 01, 1970 (or 1900?). That means, internally, the raw value can be negative for dates/times in previous (Gregorian) centuries, etc. > signature = 8 lines follows < Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada telephone:1 613 562 5800 x4585 fax:1 613 562 5161 mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee “How *do* you plan for something like that?” Guardian Bob, Reboot “For every action, there is an equal and opposite criticism.” “Systems Programming: Guilty, until proven innocent” John Norgauer 2004 "Schrodinger's backup: The condition of any backup is unknown until a restore is attempted." John McKown 2015 -Original Message- From: Charles Mills [mailto:cha...@mcn...org] Sent: January 5, 2016 19:46 Subject: Re: SMFxTME field Of course, if you have the good Doctor Merrill's most excellent MXG software then it will do all of this for you and more in but a trice! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, January 05, 2016 4:30 PM Subject: Re: SMFxTME field The SMFxxTME and SMFxxDTE fields are in my experience consistent representations of *local* time and date on the LPAR represented by the SMFID. No worries about leap seconds (unless you need to get back to some more basic time than local). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
Caveat: with daily digesting, I'm at least a day behind the discussion... Actually, I believe that MXG is SMFxxDTE & SMFxxTME cognizant by virtue of using the underlying SAS 'inFormat's SMFDATETIME, SMFDATE, & SMFTIME. I do my SMF reporting using SAS directly and, using SMFDATETIME, get SAS Date/DateTime variables [1] that can have the (out) 'Format's you desire. [1] If I remember rightly, the SAS internal representations are #seconds or days from an arbitrary point ie. Jan 01, 1970 (or 1900?). That means, internally, the raw value can be negative for dates/times in previous (Gregorian) centuries, etc. > signature = 8 lines follows < Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada telephone:1 613 562 5800 x4585 fax:1 613 562 5161 mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee “How *do* you plan for something like that?” Guardian Bob, Reboot “For every action, there is an equal and opposite criticism.” “Systems Programming: Guilty, until proven innocent” John Norgauer 2004 "Schrodinger's backup: The condition of any backup is unknown until a restore is attempted." John McKown 2015 -Original Message- From: Charles Mills [mailto:cha...@mcn...org] Sent: January 5, 2016 19:46 Subject: Re: SMFxTME field Of course, if you have the good Doctor Merrill's most excellent MXG software then it will do all of this for you and more in but a trice! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, January 05, 2016 4:30 PM Subject: Re: SMFxTME field The SMFxxTME and SMFxxDTE fields are in my experience consistent representations of *local* time and date on the LPAR represented by the SMFID. No worries about leap seconds (unless you need to get back to some more basic time than local). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
Ed Finnell wrote:
> TITLE('SMF Type-14 Records') DATE TIME PAGE -
> HEADER('Time') ON(7,4,TM1,E'99:99:99') -
> C'hh:mm:ss' HEADER('Date') ON(11,4,DT3,E'-999') -
DT3? yuck! That's Julian format and so ancient ... ;-)
I prefer this, but then it is just me! From my sample ICETOOL job for SMF type
89 which I posted in Oct 2013 on IBM-MAIN:
...
HEADER('DATE')ON(11,4,DT1,E'/99/99') -
HEADER('TIME')ON(7,4,TM1,E'99:99:99') -
...
I prefer this DT1 format because you can later sort, re-sort and sort again (if
using Date as sort argument) in subsequent reporting, forwarding and subsetting
the results.
Groete / Greetings
Elardus Engelbrecht
PS: Credits to Frank Yaeger (DFSORT guru, now retired) for those amazing SMF
field handling in DFSORT!
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
Janet Graff wrote: >What macro would we use to convert TIME BIN to a readable DATE TIME? It >doesn't look like STCKCONV to CONVTOD take input of a 32-bit unsigned binary. Others gave you good replies including DFSORT/ICETOOL method and how to calculate it. Charles Mills gave a good reply too. I think I have posted a sample for that using ICETOOL for getting SMF record 89 on IBM-MAIN. The same for handling SMFxxTME. I can repost them here again if you wish. Question, is this a follow-up of you thread in February 2015 where Charles also gave you a macro for that? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
Of course, if you have the good Doctor Merrill's most excellent MXG software then it will do all of this for you and more in but a trice! Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, January 05, 2016 4:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMFxTME field The SMFxxTME and SMFxxDTE fields are in my experience consistent representations of *local* time and date on the LPAR represented by the SMFID. No worries about leap seconds (unless you need to get back to some more basic time than local). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
The SMFxxTME and SMFxxDTE fields are in my experience consistent representations of *local* time and date on the LPAR represented by the SMFID. No worries about leap seconds (unless you need to get back to some more basic time than local). SMFxxTME is the time in hundredths of a second since midnight. There may be system services to convert this (LE time services?) but I just do the arithmetic, which should be easy in assembler, COBOL or C: Divide by 100 -- remainder is hundredths of a second. Divide quotient by 60 -- remainder is seconds. Divide quotient by 60 -- remainder is minutes. Quotient is hours (24 hour clock). SMFxxDTE is in an amusing packed format: 0cyydddF where c is the century offset by 19 -- that is, 01 => 2000; yy is the low order digits of the year; and ddd is the "Julian" day number of the year: 001 = January 1, ... 365 = December 31 (366 for leap years). If you can unpack it there may be system services to further manipulate it. I thought there were system services to work with the basic SMF time and date formats but I don't see them. I have my own code that I "always" use, so I have not looked for system services in some years. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Janet Graff Sent: Tuesday, January 05, 2016 3:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMFxTME field What macro would we use to convert TIME BIN to a readable DATE TIME? It doesn't look like STCKCONV to CONVTOD take input of a 32-bit unsigned binary. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
Which records are you trying to process? There might be samples on
_www.cbttape.org_ (http://www.cbttape.org) .
DFSORT and SAS/MXG are SMFTIME knowledgeable. From DFSORT Smart Tricks
manual(pg 80).
Likewise, you can use the TOD date and time formats (DC1-3 and TC1-4) and
the ETOD date and time formats (DE1-3 and TE1-4) in INREC, OUTREC, OUTFIL,
DISPLAY and OCCUR to display the normally unreadable TOD (STCK) and ETOD
(STCKE) date and time values, respectively, in a wide range of recognizable
ways. For example, DC1 automatically converts the TOD date value to a
Z'mmdd' (=C'mmdd') value and TE4 automatically converts the ETOD time
value to a Z'hhmmssxx' (=C'hhmmssxx') value. These ZD values can be used as
is,
or further edited using the editing features of DFSORT or ICETOOL. Here's
an ICETOOL job that produces the report with readable SMF date and time
that Jorg was looking for:
//SMFRPT JOB ...
//STEP0010 EXEC PGM=ICETOOL
//TOOLMSG DD SYSOUT=* ICETOOL messages
//DFSMSG DD SYSOUT=* DFSORT messages //RAWSMF DD DSN=... SMF data
//SMF# DD DSN=&&TEMPV,SPACE=(CYL,(15,15)),UNIT=SYSDA
//SMF#REP DD SYSOUT=* Report
//TOOLIN DD * ICETOOL statements
COPY FROM(RAWSMF) TO(SMF#) USING(SMFI) DISPLAY FROM(SMF#) LIST(SMF#REP) -
TITLE('SMF Type-14 Records') DATE TIME PAGE -
HEADER('Time') ON(7,4,TM1,E'99:99:99') -
C'hh:mm:ss' HEADER('Date') ON(11,4,DT3,E'-999') -
C'-ddd' HEADER('Sys') ON(15,4,CH) -
HEADER('SMF#') ON(6,1,BI) -
HEADER('Jobname') ON(19,8,CH) -
HEADER('Datasetname') ON(69,44,CH) -
BLANK /*
//SMFICNTL DD *
INCLUDE COND=(6,1,BI,EQ,14) - Select SMF Type-14 records only /* Here's a
sample of what the report might look like:
SMF TYPE-14 RECORDS 02/24/05 10:35:11 - 1
- TIME DATE SYS SMF# JOBNAME DATASETNAME
-
21:30:01 2005-052 SMEP 14 TMVSLFS TMON.MVS30.TMVINST
21:30:07 2005-052 SMEP 14 TMONADMP TMON.SS.LMKLOAD
22:07:00 2005-052 SMEP 14 TMVSLFS TMON.MVS30.TMVINST
22:07:00 2005-052 SMEP 14 TMVSLFS TMON.MVS30.TMVINST
22:07:06 2005-053 SMEP 14 TMONADMP TMON.SS.LMKLOAD
00:00:05 2005-053 SMEP 14 TMONMVS TMON.SS.LMKASET
00:00:05 2005-053 SMEP 14 TMONCICS TMON.STRATS.LMKASET
00:00:23 2005-053 SMEP 14 ESS148XC SYS.EOR.CNTL
In a message dated 1/5/2016 5:38:55 P.M. Central Standard Time,
004dc9e91b6d-dmarc-requ...@listserv.ua.edu writes:
What macro would we use to convert TIME BIN to a readable DATE TIME? It
doesn't look like STCKCONV to CONVTOD take input of a 32-bit unsigned
binary.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
On 2016-01-05 16:38, Janet Graff wrote: > What macro would we use to convert TIME BIN to a readable DATE TIME? It > doesn't look like STCKCONV to CONVTOD take input of a 32-bit unsigned binary. > Suss out, by trial and error, an affine transformation to convert 32-bit unsigned binary to the 64 (or 128)-bit format used by STCKCONV. Beware of leap seconds -- STCKCONV is leap second ignorant. (Easy algebra -- just 2 equations in 2 unknowns.) Or use the C function strftime(). You still must do the same algebra. Aren't SMF records wildly inconsistent in their time formats? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
What macro would we use to convert TIME BIN to a readable DATE TIME? It doesn't look like STCKCONV to CONVTOD take input of a 32-bit unsigned binary. Janet -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
Thank you to everyone for your help. It turns out my content was correct but my timing was off. I was filling in the SMFxTME with the correct Time component of TIME BIN but I was doing it when my server started. I need to change my code to fill in the SMFxTME with the correct Time component of TIME BIN at the time the SMF record is written. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
Janet Graff wrote: >We just noticed our product was setting the SMFxTME field inappropriately >using the TIME BIN macro. What should we be using to set the SMFxTME field? Please post the TIME BIN macro and all fields/variables used. Please post the result of that macro and what you're expected to see. >The doc says > 06 06 SMFxTME4binary Time since midnight, in > hundredths of a second, record > was moved into the SMF buffer. > In record types 2 and 3 this > field indicates the time that > the record was moved to the > dump data set. Documentation is correct. That's a 4 byte value. You need some work to extract hours, minutes, seconds from that value. Just remember that you should use SMFxTME together with SMFxDTE unless you need time value only. >TIME MIC appears to be the right information but it produces 8 bytes and not 4 >bytes of information. Correct. That is TOD in 8 bytes. Please review other persons replies to you. I think you should tell us what you're expecting from the software to produce. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
Works for me: * * Get time in hundredths as we want and date as 0ddd TIME BIN,TIMEWORK,DATETYPE=DDD, + LINKAGE=SYSTEM, + MF=(E,TIMEL) * * Move time where we want it MVC SMFTME(4),TIMEWORK Time in hundredths MVO SMFDTE(4),TIMEWORK+9(3) 0ddd to ?yyyddd? OISMFDTE+3,X'0F' Set sign of F = ?yyydddF MVI SMFDTE,X'01'Set century to 01 = 01yydddF * Y21K alert!!! * on above line a better programmer would compute the century! Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Janet Graff Sent: Friday, February 20, 2015 11:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMFxTME field We just noticed our product was setting the SMFxTME field inappropriately using the TIME BIN macro. What should we be using to set the SMFxTME field? The doc says 06 06 SMFxTME4binary Time since midnight, in hundredths of a second, record was moved into the SMF buffer. In record types 2 and 3 this field indicates the time that the record was moved to the dump data set. TIME MIC appears to be the right information but it produces 8 bytes and not 4 bytes of information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
TIME fills in the 4 words you passed to it with the time and date returned in various formats. You want to use BIN and use the first word for the time. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Janet Graff Sent: Friday, February 20, 2015 2:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMFxTME field Importance: Low We just noticed our product was setting the SMFxTME field inappropriately using the TIME BIN macro. What should we be using to set the SMFxTME field? The doc says 06 06 SMFxTME4binary Time since midnight, in hundredths of a second, record was moved into the SMF buffer. In record types 2 and 3 this field indicates the time that the record was moved to the dump data set. TIME MIC appears to be the right information but it produces 8 bytes and not 4 bytes of information. Janet -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
In <3495911068637390.wa.janet.graffyahoo@listserv.ua.edu>, on 02/20/2015 at 01:05 PM, Janet Graff <004dc9e91b6d-dmarc-requ...@listserv.ua.edu> said: >We just noticed our product was setting the SMFxTME field >inappropriately using the TIME BIN macro. Why inappropriately? It matches the documentation that you quoted. Which word of the output area were you using? >TIME MIC appears to be the right information How so? It returns the TOD value, not units of .01 seconds as described in the documentation. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see <http://patriot.net/~shmuel/resume/brief.html> We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFxTME field
On 2/20/2015 2:05 PM, Janet Graff wrote: We just noticed our product was setting the SMFxTME field inappropriately using the TIME BIN macro. What should we be using to set the SMFxTME field? The doc says 06 06 SMFxTME4binary Time since midnight, in hundredths of a second, record was moved into the SMF buffer. In record types 2 and 3 this field indicates the time that the record was moved to the dump data set. TIME MIC appears to be the right information but it produces 8 bytes and not 4 bytes of information. Why do you think TIME BIN is inappropriate? "BIN returns the time of day as an unsigned 32-bit binary number with the low-order bit equivalent to 0.01 second. The second word of the time value returned is zero." Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMFxTME field
We just noticed our product was setting the SMFxTME field inappropriately using the TIME BIN macro. What should we be using to set the SMFxTME field? The doc says 06 06 SMFxTME4binary Time since midnight, in hundredths of a second, record was moved into the SMF buffer. In record types 2 and 3 this field indicates the time that the record was moved to the dump data set. TIME MIC appears to be the right information but it produces 8 bytes and not 4 bytes of information. Janet -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
