John Chase reminded us: > EIBDATE is, and has been long enough to be "forever", a four > byte packed-decimal field. From SDFHMAC: > > EIBDATE DS PL4 DATE IN 0CYYDDD+ FORMAT, > * where C is the century > * indicator (0=1900, 1=2000), > * YY is the year, DDD is the > * day number and '+' is the > * sign byte (positive)
At which point, Andy Wood wondered: > I am not now, and in a former life I never was, a CICS person, > but I wonder if that field really was like that "forever". The short version: Yes, essentially, it has been like that forever, or indeed at least "long enough" that his intended point was valid. The long version: I don't know about "that field" specifically, since I'm not a CICS guy, either. But I just looked at some code I last touched in 1978 and I see it supported the century indicator. Some evidence at hand indicates that I was first exposed to the internals of CICS around 1981-1982, so for me that idea was not likely to have specifically been derived from CICS internals. I don't remember where or when the fact that the 2nd nybble in the classic OS/VS date value is the century indicator (or that the "cc" in "ccyydddS" is the century byte) came from. But after all this is the date representation that has been returned by TIME LINKAGE=SVC for a long time. Perhaps Peter Relson or some other IBMer would be able to enlighten us about when (I predict it arrived on the scene in the MVS/SP 1.2 or 1.3 timeframe, but that's just a guess, here). Regardless, this got me thinking, so I searched my MRM archives for "0cyyddd" and "ccyyddd" (and the like). The SAS date/time INFORMATs SMFSTAMP and RMFSTAMP were originally designed to grok the "century byte." That code might have shipped in SAS 79.1 (for SMFSTAMP at least, RMFSTAMP was added later), but my memory is faulty and my MRM records are incomplete, so it might not have been in (both) until SAS 82 (or even later!). I know it was in SAS 5.xx without question, since I found an old SAS program whose comments document why SMFSTAMP could not be used in it: some IBM product or component was using "yyyydddF' in a date field (for an SMF record it wrote), instead of the SAS-expected "ccyydddF". I don't know when folks in Poughkeepsie got that idea. But by the time IBM had documented that, SMFSTAMP8. already worked that way. If memory serves me correctly, the original suggestion for support of the "century byte" came from Dr. Barry Merrill for use in MXG, a product written essentially entirely in SAS. I think Ed Webb wrote that code for SAS (I know he wrote RMFSTAMP for SAS 82 originally). Regardless, as an idea, it dates back at least as far as 1978, and conceptually as far back as 1976. It was a hot topic at that time for forward-thinking bank IMS data base types because of increased attention to additional auditing requirements expected from The Fed and hints of potential additional expansive requirements for long- term data retention (not just for classic auditing purposes, but for ex post facto FBI money laundering investigations, for example). The days of bank applications keeping only 18 bytes of data for each check were soon going to be over. Remember when your checking account statement listed only the check number, date, and amount? 1976 was when the [NC] inter-bank ACH (EFT) data representation (for "ASCII tapes") was being designed. I raised this issue during some of the meetings, which I had been roped into attending because the tapes to be exchanged (physically) among the banks and the ACH were to be in "industry standard" (meaning ASCII) format -- despite the fact that every last bank that sent any tapes to the Charlotte branch of the Federal Reserve Bank had an [EBCDIC] IBM mainframe. I thought it could potentially be the only significant contribution I would ever make (most of the discussion was heavy with acronyms related to bank operations, such as DDA, TD, DNP, CL & BA, which I did not even try to understand). The COBOL types from every last bank's DP department didn't want to have to support YYYY, since their standard internal date data representation was "0yyddd" -- instead of [as you would expect for COBOL types] "mmddyy" or the like. I suggested "cyyddd". They seemed to give it some serious consideration, but they eventually decided to ignore the issue and used "yymmdd" because the EFT transactions would supposedly always be processed within 3-4 days (meaning that "yy" would never, ever be ambiguous). So much for that, but I knew how the COBOL types thought and built systems: every application job stream at the bank I ever looked at started out with one or more huge SORT steps. I pointed out that a date field of "yymmdd" would not sort correctly starting in 2000. I expected the standard set of excuses in response, but instead I was met with blank, uncomprehending stares. They -- literally -- could not comprehend that transactions in the year 2000 would sort before those in 1999. "Why would the sort package do _that_?" was a question that was (seriously) asked. After the third such event, I went back and told my management chain I couldn't represent the bank any longer, because I was seriously unable to help with any problem they had. It was at that point that I decided it was way above my pay grade to even attempt to educate morons. I didn't have that kind of patience. Thus: 2009-1978 = 31. 31 years is not "forever," but close enough for government work in this business. -- WB ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
