Barry, re-posting this back to the IBM-MAIN list in case anyone else may be interested...
I have hunted around, looked up some notes AND asked some of the IMS Dev people, we "seem" to remember that it came bout with data sharing in IMS 5, since before that it was only the LSN and the STCK was added later, or possibly the other way round... Thanks. Aurora Aurora Emanuela Dell'Anno CA MSC Sr. Engineering Services Architect Tel: +44 (0)1753 577 733 Mobile: +44 (0)7768 235 339 aurora.della...@ca.com http://www.ca.com/ P please don't print this e-mail unless you really need to! -----Original Message----- From: Barry Merrill [mailto:ba...@mxg.com] Sent: 04 April 2010 14:14 To: Dell'Anno, Aurora Subject: RE: IMS log record sequence number first byte 'F1'x - why? Many thanks for taking the time to educate me. It is the final 8-byte LSN that has the 'F1'x in the first byte in this particular IMS log file. Has this always been the design, or is this something new? I've always INPUT the IMSRECNO with SAS as a PIB8. numeric, but I had not previously implemented duplicate data removal from the IMS log record post-processing, so I had never had the occasion to look closely at the actual LSN value. But when I decided this week to add that logic (by reading the same file twice, PROC SORT NODUP'ing, and confirming that exactly one half of each record type was removed) I hit really strange problems that took a LONG time for me to realize they were the result of that first byte being non-zero, plus a SAS design "error" that I had documented ten years ago and had forgotten. When a 8-byte field is input in SAS as a numeric, I had completely forgotten that only 7-bytes of "mantissa" are storable in their internal floating point values, and that caused LOTS of identical LSN values, with 10*19 magnitude, due to the low order digits being truncated, and those duplicate LSN values were the cause of my NODUP failure. Now, realizing the my/SAS glitch, I INPUT it as a $CHAR8 and all 8-bytes are preserved and my NODUP works just fine now, but I still wanted to document what's in that first byte. And to show my complete lack of knowledge of how the IMS log files I get from customers are created, can you elaborate on the "position of the file in the merge sequence"? I just though you "dumped" the IMS log, and was unaware of a merge operation in that process. Very MERRILLY yours, Barry Merrill ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
