I had posted this as a reply but see that the original subject has scrolled - hence I repost it here.

====================================

Arlin Adams said "I think we're all glad you're comfortable with your position, though from the general tone of your comments, and lack of factual support to back up your statements, it's difficult to determine where that comfort originates." While I appreciate your concern for the origin of my "comfort", I am also realizing that the more time I spend in this forum and read plausible answers to sometimes ludicrous questions, that the respondent is shot down many times over with innuendo and crass comments. It is not my position to provide absolutely convincing evidence to you or anyone in this forum. On the contrary - you feel that I am lying, I feel the burden of proof is upon you!

I function as a Systems Analyst in the Consultant industry. I cannot, under contract, reveal the names of my clients in a public forum or any other place. If I do not abide by my contracts I am held liable. It does not take a rocket scientist to understand this.

Arlin Adams said "1. almost no one is saying that all of the computers are going to crash. What is being said is that complex systems will become increasingly corrupted and unreliable to the point of becoming unusable. All of your safeguards are predicated on the concept that the safeguards themselves are not corrupted or corruptible...an unproven concept in a y2k environment in which the very systems the safeguards depend upon for accuracy may themselves be corrupt. "

Arlin, at what point did I say that the safeguards (fallbacks - redundant links) were not already tested or not related to any date driven processes? In regard to network topology the redundancy is built in on a multi-tiered basis consisting of hardware, software and firmware.

Arlin Adams said; "2. Your friends in the utility industry forgot to mention a couple of things to you, most importantly that the reason there is a need to sell power across the grid is because some local utilities *cannot* meet the needs of their own customer base under all circumstances. That means when islanding begins, so do the brownouts/blackouts. Just as importantly, your friends forgot to mention that there are a number of power companies out there which buy ALL of their power across the grid. Now you may be thinking that only occurs in rural areas - places you don't care about, but if you'd be wrong. You need to go ask your friends in the utility industry what's happening with deregulation. In some states, there is even a requirement that local utilities buy power from other sources. Guess what happens when the grid starts breaking up due to islanding? you got it - more blackouts."

See my post above concerning network topology. This is also true of the energy industry. The most common topology is the "Star" topology, which consists of 3 to 6 points all, connected with each other (hardwired). Any one of the points can go down without causing a loss to the remaining points. In this topology scenario, each power station is a point which has it's own substations interconnected to it in it's own star topology. Can "islanding" happen? Sure it is within the realm of possibility. It is not, however, within the realm of probability.

Arlin Adams said "3. if you are certain that the financial institution you claim to work for is y2k compliant, then you should have no problem providing us with it's name, or yours for that matter. To borrow from another thread - your information on your claimed successes in the financial industry is entirely anecdotal. It would also be helpful if you could provide a little more factual evidence to support your claim that you know that the entire financial complex in the US is y2k compliant. I say this, because your use of 'standards' does nothing to disprove that corrupt data will not be passed, as long as that data meets the format required by the standard. We've certainly seen no evidence to support that claim from anywhere else. "

See my post above concerning confidentiality of the client. My name is Randy Van de Loo and you can reach me at COBOL_Dinosaur@yahoo.com. Suppose you tell me what evidence I would be able to supply you with that you would not consider to be "anecdotal" ? I could post COBOL Logic (code) if you like. Would you be able to read and understand it? You seem to think that standards prepared by multinational organizations were done haphazardly or with little forethought. I suppose you are in a position to advise us all when a standard is "bogus" or insufficient for the application? Certainly the data coming in via a standardized interface could be corrupt or non- compliant to the standard. This is why all front-end programs edit the inbound data for compliance and prepare a "rejection" packet for re-transmission to the originating source. In other words if the date field is 8 bytes long and is MMDDCCYY in format and the data comes in 01010000 - it will be rejected. The data should have been 01012000. Now as to whether or not the data is correct even though it is in the correct format, there are other edits that can and are used. Reasonability edits for instance. If the current data being processed is for the last week in December of 1999 and the inbound transaction date shows a deposit being made 01052000, we will reject it. Why? Because it was batched wrong - it is returned to the origin point as a reject. What more do you want Arlin - the blinkity- blanken layout for the interface? Couldn't give it to you anyway as it is protected by - you guessed it - confidentiality agreements and contracts.

============================

walt (Walt@lcs.k12.ne.us), May 14, 1999. said "Did anybody see this quote in the original post? If it is true, does it mean anything?? Can anybody here prove it is wrong??? If this is true, it would practically put Gary North out of business overnight, at least on his banking comments. If this data has beeen compliant for who knows how many years, how are non-complinat banks going to "corrupt" the compliant ones?? "

Good point Walt. Whether you choose to believe it or not, it *is* true. The "Systemic" collapse of the FRS and FRB cannot happen due to data related or topology related failures.. We made darned sure of it.

============================

Sysman (y2kboard@yahoo.com), May 14, 1999. said "Welcome, and it's always nice to have an "insider" join us. "

Thank you Sysman.

Sysman said "Being a fellow old-timer, do you know when the CENTURY field first showed up in IBM Cobol CURRENT-DATE? I'm missing about 5 years of manuals, and can't find an exact date. Also, do you know of any Fortune-500 company that does not have at least one mainframe? Just wondering, since some of our fellow old-times aren't sure. "

COBOL/390, COBOL/370, COBOL-II (Also known as COBOL-85 with a "twist") have the capability of using Intrinsic functions - There is one known as CURRENT-DATE code to follow:

01 YYYYMMDD PIC 9(8). . . .

MOVE FUNCTION CURRENT-DATE(1:8) TO YYYMMDD

In this scenario the current date will be placed in the field known as YYYYMMDD.

=============================

Anita said "I've been involved in mainframe work for perhaps as long as you have, and I don't see any credence in this 9/9/99 scare either. The date would be stored as 090999. This is a FAR cry from ALL nines....not to mention this being a far cry from this particular field being used to delineate end of file. "

Thank you Anita. Good to hear from another fellow Dinosaur.

=============================

Chuck said "Regardless of the existence or absence of this standard in the US, the non-compliant banks,(US and overseas) will still be able to corrupt the compliant banks. NOT because the data coming in has serious date errors, as the input data edits should catch them, but because the DATA that is a RESULT of date calculations may be incorrect. Being within range and incorrect are not mutually exclusive. "

I appreciate your response and concern over this issue. Certainly it is within the realm of possibility for corrupt (incorrect) data to enter the system - BUT - as you have probably read earlier within this post, it is unlikely that this could / would happen. Regardless, your statement that non-compliant banks would "still be able to corrupt the compliant banks" is totally unfounded and without merit. Unless, of course, you would like to supply proof to the contrary.

I do appreciate your other comments on this forum - you seem to have a fair understanding of the industry in general and I hope that I am able to bolster that knowledge, even if slightly, through my posts.

=============================

OutingsR (us@here.yar said "Not that Dino is a troll or anythin', y'unnerstan'. From the index of the Gary North is a Big Fat Idiot forum:

1242. 9/9/99 to bring a preview of armageddon? - Take a look! by COBOL Dinosaur, May 14, 08:19 1. Might I persuade you [to post this at the Yourdon Swamp] by Paul Davis, May 14, 10:09

(_ I just tossed it into the swamp - run for cover! by COBOL Dinosaur, May 14, 11:26

(_ Thanks Dino by Paul Davis, May 14, 11:41

So, Dino pup, what's it feel like to be patted on the head by Sayn't Paul? "

Thank you for your concern as to my whereabouts in other forums. Since I have not seen your postings on the BFI forum, may I take it that it is *YOU* that may very well be a troll?

And as you can see by some of the comments leveled at me in this forum, I was indeed pounced upon as I had predicted.

=============================

To any and all - I appreciate your time that you invest in these forums. Logical minds and cool heads shall prevail over the Y2K and any resultant issues.

Yours in COBOL... Dino!

-- COBOL Dinosaur (COBOL_Dinosaur@yahoo.com), May 18, 1999

Answers

You said:

Thank you Anita. Good to hear from another fellow Dinosaur.

How could this be? I'm only 29 years old! I SWEAR!

Off-topic: We're seeing a lot of work dry up across the nation due to Y2k changes being complete and firms fearing to introduce other maintenance. Are you seeing the same? Perhaps we could discuss this via E-mail (if you're interested.)

Anita

-- Anita Spooner (spoonera@msn.com), May 18, 1999.

Dino (or Randy as the case may be),

there are still a few problems with your answers.

[in response to my point concerning a lack of factual evidence to support your claims you wrote:While I appreciate your concern for the origin of my "comfort", I am also realizing that the more time I spend in this forum and read plausible answers to sometimes ludicrous questions, that the respondent is shot down many times over with innuendo and crass comments. It is not my position to provide absolutely convincing evidence to you or anyone in this forum. On the contrary - you feel that I am lying, I feel the burden of proof is upon you! ]

I'm sorry Dino, but it doesn't work that way. The way it works in the real world is thatif you make a statement that you expect to be taken seriously, while posting from a fictious address, under a false name, you'd best have your factual ducks in order or no one believe a word you write. You have no credibility when writing anonymously, except for the credibility you prove yourself to have through documentary factual material. As of right now Andy's posts about the giant Russian invasion conspiracy have more factual documentation and therefore more credibility than you do. You might want to think about that.

[Dino wrote: I function as a Systems Analyst in the Consultant industry. I cannot, under contract, reveal the names of my clients in a public forum or any other place. If I do not abide by my contracts I am held liable. It does not take a rocket scientist to understand this. ]

It also does not take a rocket scientist to understand that any highschool student with a reasonable command of the English language could make exactly the claims you are making and provide exactly as much evidence as you are providing.

[Dino wrote: Arlin, at what point did I say that the safeguards (fallbacks - redundant links) were not already tested or not related to any date driven processes? In regard to network topology the redundancy is built in on a multi-tiered basis consisting of hardware, software and firmware. ]

you haven't proven anything kid. Most especially you've shown no cause to believe that the level of network remediation you claim is happening even between financial organizations in this country, much less elsewhere. There is also no external hard documentation to support your claims. Again so far all we have from you is hot air, and we need to see something more than that.

Then, Dino/'Randy', you made your truly critical mistake:

[in response to my points concerning the blatant errors in your comments concerning the electrical grid you wrote: See my post above concerning network topology. This is also true of the energy industry. The most common topology is the "Star" topology, which consists of 3 to 6 points all, connected with each other (hardwired). Any one of the points can go down without causing a loss to the remaining points. In this topology scenario, each power station is a point which has it's own substations interconnected to it in it's own star topology. Can "islanding" happen? Sure it is within the realm of possibility. It is not, however, within the realm of probability. ]

LOL! Dino you've gotta stop reading one or two documents and thinking you understand the industry. My utilities contacts are most likely ROFLMAO on this one, quite frankly I'm afraid to ask. All you've described is a model of one type of one part of one utility's distribution grid. The actual grid is not nearly that coherent, with over 4000 seperate utilities,multiple transmission structures of various ages and designs, plus independent power generation companies, plus Electric Cooperatives with no independent generation capacity and even older designs. I suggest you go over to Rick Cowles' forum at

http://www.euy2k.com/

and ask them about the structure and organization of the power grid, with regard to all of the different organizations I mentioned above. The grid is big, it's lopsided, there are parts of it that are brand new, and other parts that are half a century old. Talk to some older project managers - that's where the long term knowledge resides.

or better yet, if my comments make you angry - simply provide documentary proof that all of the 4000 plus utilities and the RECs and the independent generating facillities, etc, are currently structured in the manner you claim - note I did not say "hold as a standard" but "are currently structured'...

[Dino/Randy wrote:: See my post above concerning confidentiality of the client. My name is Randy Van de Loo and you can reach me at COBOL_Dinosaur@yahoo.com. Suppose you tell me what evidence I would be able to supply you with that you would not consider to be "anecdotal" ? ]

News reports (NOT PR press releases) providing documentary support for your claims. That would be an excellent start.

[Dino/Randy again - I could post COBOL Logic (code) if you like. Would you be able to read and understand it? You seem to think that standards prepared by multinational organizations were done haphazardly or with little forethought. I suppose you are in a position to advise us all when a standard is "bogus" or insufficient for the application?]

*sigh* actually I *am* a COBOL dinosaur of sorts, having started out with COBOL/77 back in the days of PDP-9s and such like, though as I've pointed out here repeatedly, I'm long out of practice and very rusty. However, as we both know, without field definitions, plus your input and output form definitions, simply posting uncompiled code segments wont really prove much of anything. Indeed, if anything, one would be led to wonder if you were violating your nondisclosure agreements by doing so - in that if you are who your say you are, your firms competitors could be very interested in that sort of information.

More to the point, you mistake data formatting for data validity - just because something comes in formatted to an international standard, does not mean that the data contained in the formatting is valid. Beyond even that, however, countrys such as Italy (which hasn't even really begun serious y2k remediation efforts) stand a very good chance of having their data streams toasted off from the start. This means that the standards will be functionally meaningless as the financial institutions of countries experiencing those sorts of problems will have to find entirely different means of conducting business, which will then in turn require that whatever those means might be the data thus exchanged must eventually be entered into your institution's systems...something it sounds as though you are entirely unprepared to handle.

as far as documentation goes: how about some documentation that you're institution is capable of handling *via other-than-standard transmission routes* the same volume of data it's currently getting from Italy and, oh, China and, uh, say, Russia, to pick two others which wont have their remediation anywhere near complete by the roll over? Now *That* would be impressive.

[Dino/Randy writes: Certainly the data coming in via a standardized interface could be corrupt or non- compliant to the standard. This is why all front-end programs edit the inbound data for compliance and prepare a "rejection" packet for re-transmission to the originating source. In other words if the date field is 8 bytes long and is MMDDCCYY in format and the data comes in 01010000 - it will be rejected. The data should have been 01012000. Now as to whether or not the data is correct even though it is in the correct format, there are other edits that can and are used. Reasonability edits for instance. If the current data being processed is for the last week in December of 1999 and the inbound transaction date shows a deposit being made 01052000, we will reject it. Why? Because it was batched wrong - it is returned to the origin point as a reject. What more do you want Arlin - the blinkity- blanken layout for the interface? Couldn't give it to you anyway as it is protected by - you guessed it - confidentiality agreements and contracts. ]

Here again you've missed the point in two areas: FIRST: Dates aren't the only concern. None of your filters will be able to identify currency amounts already mangled by calculations based on bad data - other than setting a few 'out of range' checks, for negative numbers, tiny numbers or exponentiated numbers. If the currency figure is within range, even if it is already wrong due to previous errors, you will not be able to spot it. Now as soon as that data is into your system, all calculations based on that corrupted data are, of course, also corrupt...are you beginning to see the problem here?

SECONDLY: The only manner in which to avoid this problem is to go to a human in the loop system where each transaction is double checked manually. You have made no mention of this as a possibility and without it, your data will either be corrupted in short order, or nonexistant as your filters reject all of the incoming message stream for errors...depends on how you write the filters...y'know?

I'm really sorry Randy, but you've got to realize that the situation is a tad more complex than the manuals and standards documents make it sound. Try talking to the folks over on euy2k.com, and then try talking to some of the big iron programmers here on this board (sysman and the others) - they'll be able to help you get a grasp of this much better than I will

Arlin Adams

-- Arlin H. Adams (ahadams@ix.netcom.com), May 18, 1999.

Anita said: "How could this be? I'm only 29 years old! I SWEAR!

Off-topic: We're seeing a lot of work dry up across the nation due to Y2k changes being complete and firms fearing to introduce other maintenance. Are you seeing the same? Perhaps we could discuss this via E-mail (if you're interested.) "

Hmmm... I used to count my years off in HEX too. It only worked until I turned 42 when suddenly I realized my age was then 2A!. :-)

I work in the upper midwest region and so far there has not been a real issue in terms of placement of consultants. Many companies put their "mission critical" projects on the back burner until Y2K projects were either complete or into the testing phases. Now we are seeing more of those older projects being brought back onto the front- burner with even more emphasis than they were originally afforded.

Feel free to contact me via E-mail at the address listed here.

Yours in COBOL... Dino!

-- COBOL Dinosaur (COBOL_Dinosaur@yahoo.com), May 18, 1999.

Arlin said: "Dino (or Randy as the case may be), there are still a few problems with your answers. "

Why am I not surprised? BTW, it is still Dino to you - Thank you.

-----

Arlin said: "[in response to my point concerning a lack of factual evidence to support your claims you wrote:While I appreciate your concern for the origin of my "comfort", I am also realizing that the more time I spend in this forum and read plausible answers to sometimes ludicrous questions, that the respondent is shot down many times over with innuendo and crass comments. It is not my position to provide absolutely convincing evidence to you or anyone in this forum. On the contrary - you feel that I am lying, I feel the burden of proof is upon you! ] I'm sorry Dino, but it doesn't work that way. The way it works in the real world is thatif you make a statement that you expect to be taken seriously, while posting from a fictious address, under a false name, you'd best have your factual ducks in order or no one believe a word you write. You have no credibility when writing anonymously, except for the credibility you prove yourself to have through documentary factual material. As of right now Andy's posts about the giant Russian invasion conspiracy have more factual documentation and therefore more credibility than you do. You might want to think about that. "

Like most who have been around any form of electronic conferencing (FidoNet, Usenet, Et al), I chose to use a nickname which was given to me by some of my former students - long ago. My real name has nothing to do with the content or quality of my posts. Furthermore my credibility can and will be established here, as it has in many other places, with my nick. RE: My "factual ducks" - rest assured that I do, indeed, have my factual ducks in order. Your diatribe to the contrary proves absolutely nothing and does nothing to enhance the dialect within this forum. Furthermore in this, the United States of America, with it's FBI, CIA, NSA Et al, thought for one second that Andy actually knew what he was talking about in regard to a Russian Invasion - just how long would you expect to read his posts?

----

Arlin Said: "[Dino wrote: I function as a Systems Analyst in the Consultant industry. I cannot, under contract, reveal the names of my clients in a public forum or any other place. If I do not abide by my contracts I am held liable. It does not take a rocket scientist to understand this. ]

It also does not take a rocket scientist to understand that any highschool student with a reasonable command of the English language could make exactly the claims you are making and provide exactly as much evidence as you are providing. "

I suppose I could very well digitize my University Diploma, transcript, job history and resume' all for your personal consumption - But, as you have proven so many times before, you would just poo- poo it as contrived evidence to which you would scream fake fake fake! Frankly Arlin, it is diatribes such as yours that give this forum a bad name. Those of us who "REALLY DO WORK IN THE INDUSTRY" and "REALLY HAVE THEIR FINGERS ON THE PULSE OF THE INDUSTRY" get tired of having our words (encouraging or not) discounted as - just so much B.S..

----

Arlin said: "[Dino wrote: Arlin, at what point did I say that the safeguards (fallbacks - redundant links) were not already tested or not related to any date driven processes? In regard to network topology the redundancy is built in on a multi-tiered basis consisting of hardware, software and firmware. ]

you haven't proven anything kid. Most especially you've shown no cause to believe that the level of network remediation you claim is happening even between financial organizations in this country, much less elsewhere. There is also no external hard documentation to support your claims. Again so far all we have from you is hot air, and we need to see something more than that."

Thanks for the "kid" remark - I am of the age where it is rather refreshing. I do not know what line of work you are in, but mine is a highly technical field which is a marriage of the business and technical worlds. We produce computer programs and systems to apply business principles and rules (electronically) to data. Much of the "documentation" you seem to require would either be well beyond your technical capabilities to understand, or confidential in nature. Certainly if you were a firmware programmer for Intel, you would not publish schematics and logic diagrams as "absolute proof" of your claims that the new Pentium-VI is Y2K compliant. Given that position, would I be in the wings yelling FAKE at you for not producing such documentation? Validation of concepts and remarks put on this, or any other, forum is difficult at best. If you chose to not believe it, then go buy more rice and batteries.

----

Arlin said: "Then, Dino/'Randy', you made your truly critical mistake: [in response to my points concerning the blatant errors in your comments concerning the electrical grid you wrote: See my post above concerning network topology. This is also true of the energy industry. The most common topology is the "Star" topology, which consists of 3 to 6 points all, connected with each other (hardwired). Any one of the points can go down without causing a loss to the remaining points. In this topology scenario, each power station is a point which has it's own substations interconnected to it in it's own star topology. Can "islanding" happen? Sure it is within the realm of possibility. It is not, however, within the realm of probability. ] LOL! Dino you've gotta stop reading one or two documents and thinking you understand the industry. My utilities contacts are most likely ROFLMAO on this one, quite frankly I'm afraid to ask. All you've described is a model of one type of one part of one utility's distribution grid. The actual grid is not nearly that coherent, with over 4000 seperate utilities,multiple transmission structures of various ages and designs, plus independent power generation companies, plus Electric Cooperatives with no independent generation capacity and even older designs. I suggest you go over to Rick Cowles' forum at http://www.euy2k.com/ and ask them about the structure and organization of the power grid, with regard to all of the different organizations I mentioned above. The grid is big, it's lopsided, there are parts of it that are brand new, and other parts that are half a century old. Talk to some older project managers - that's where the long term knowledge resides. or better yet, if my comments make you angry - simply provide documentary proof that all of the 4000 plus utilities and the RECs and the independent generating facillities, etc, are currently structured in the manner you claim - note I did not say "hold as a standard" but "are currently structured'... "

Arlin, I think I understand now. You are probably one of those "I HAVE SPENT OVER 1000 HOURS IN RESEARCH ON THE INTERNET" experts. Sorry guy, but I have spent the vast majority of my LIFETIME working in this industry. Unlike you, I truly believe that *I* know what I am talking about. If not, then I have been drawing a salary for almost 30 years on a pretty good ruse. My information in regard to the energy industry is drawn from both my own experience and that of my contemporaries that currently work in that industry. The star topology has been in existence since the days of Thomas Edison. This is when he found out about ghosting in wired transmissions. Are you, Arlin, an expert? On what? What are your qualifications Arlin?

----

Arlin said: "[Dino/Randy wrote:: See my post above concerning confidentiality of the client. My name is Randy Van de Loo and you can reach me at COBOL_Dinosaur@yahoo.com. Suppose you tell me what evidence I would be able to supply you with that you would not consider to be "anecdotal" ? ]

News reports (NOT PR press releases) providing documentary support for your claims. That would be an excellent start. "

And what, Arlin, do you suppose "News reports" are generated from if not press releases or the cumulative effort of investigative reporters who are fed this information (tainted or not) by the subject corporations they are investigating? Try again.

----

Arlin said: "[Dino/Randy again - I could post COBOL Logic (code) if you like. Would you be able to read and understand it? You seem to think that standards prepared by multinational organizations were done haphazardly or with little forethought. I suppose you are in a position to advise us all when a standard is "bogus" or insufficient for the application?]

*sigh* actually I *am* a COBOL dinosaur of sorts, having started out with COBOL/77 back in the days of PDP-9s and such like, though as I've pointed out here repeatedly, I'm long out of practice and very rusty. However, as we both know, without field definitions, plus your input and output form definitions, simply posting uncompiled code segments wont really prove much of anything. Indeed, if anything, one would be led to wonder if you were violating your nondisclosure agreements by doing so - in that if you are who your say you are, your firms competitors could be very interested in that sort of information.

Well "Kid" it looks like the shoe is on the other foot. The first COBOL compiler I used was the first IBM issued "ANSI STANDARD" COBOL- 68 on an IBM 360/50 with 48k of memory. Prior to that it was BAL and 1401 Autocoder. And if you really know your stuff, you would know that I can post field definitions, and declassified segments of code (code sans business logic) which would still prove very little - except to the informed. In terms of violating my agreements, I always know just exactly how far I can go before doing this.

----

Arlin said: "More to the point, you mistake data formatting for data validity - just because something comes in formatted to an international standard, does not mean that the data contained in the formatting is valid. Beyond even that, however, countrys such as Italy (which hasn't even really begun serious y2k remediation efforts) stand a very good chance of having their data streams toasted off from the start. This means that the standards will be functionally meaningless as the financial institutions of countries experiencing those sorts of problems will have to find entirely different means of conducting business, which will then in turn require that whatever those means might be the data thus exchanged must eventually be entered into your institution's systems...something it sounds as though you are entirely unprepared to handle. "

Validation: There is much more to it, in terms of validation, which I could get into here but won't. If what you say were to be true then Y2K (or dates in general) have little to do with what could REALLY be happening with all this data. If an errant date (take today's date if you will) were to be used in a calculation improperly - then conceivably you would have bogus data as a result. This has nothing to do with Y2K. Now, don't you think, if even for a moment, that the Business Analysts and Programmers out here have not thoroughly tested and validated such scenarios? Get real. If you want to shout BUG BUG BUG then you need to yell at General Mills for the "beetle particle counts" being erroneous in the Trix Cereal packaging plant. Not that there is a problem at GM, I just used them for illustration purposes. Rest assured that data is validated 6 ways from Sunday in the banking industry. It has been beatup and spit out by the very best in accountants and auditors. It works. It is so close to flawless there is no measure for anything it lacks. Furthermore, as has been standard operating procedure for *ANY* corporation, with which I have been engaged, all financial data is keyed not once but twice by independent data entry personnel. This means that person "A" enters the original data and person "B" enters it again. If the two files match 100% the data is allowed to go through further validation within the system. If there is *any* mis-match of data, the files are rejected and re-entered again.

----

Arlin said: "as far as documentation goes: how about some documentation that you're institution is capable of handling *via other-than-standard transmission routes* the same volume of data it's currently getting from Italy and, oh, China and, uh, say, Russia, to pick two others which wont have their remediation anywhere near complete by the roll over? Now *That* would be impressive. "

Due to reasons of confidentiality I cannot go into the types of media used in transmission of data, but I can say this much - even EMP from a nuclear explosion will not affect the data or it's transmission in one or more of the links. Their are CRC's produced for the packets and bundles and decoded and tallied. If anything does not match, it is rejected and resent. If you think you can do better, then perhaps you should try driving a computer for a living.

----

Arlin said:"[Dino/Randy writes: Certainly the data coming in via a standardized interface could be corrupt or non- compliant to the standard. This is why all front-end programs edit the inbound data for compliance and prepare a "rejection" packet for re-transmission to the originating source. In other words if the date field is 8 bytes long and is MMDDCCYY in format and the data comes in 01010000 - it will be rejected. The data should have been 01012000. Now as to whether or not the data is correct even though it is in the correct format, there are other edits that can and are used. Reasonability edits for instance. If the current data being processed is for the last week in December of 1999 and the inbound transaction date shows a deposit being made 01052000, we will reject it. Why? Because it was batched wrong - it is returned to the origin point as a reject. What more do you want Arlin - the blinkity- blanken layout for the interface? Couldn't give it to you anyway as it is protected by - you guessed it - confidentiality agreements and contracts. ]

Here again you've missed the point in two areas: FIRST: Dates aren't the only concern. None of your filters will be able to identify currency amounts already mangled by calculations based on bad data - other than setting a few 'out of range' checks, for negative numbers, tiny numbers or exponentiated numbers. If the currency figure is within range, even if it is already wrong due to previous errors, you will not be able to spot it. Now as soon as that data is into your system, all calculations based on that corrupted data are, of course, also corrupt...are you beginning to see the problem here? "

See my response to your diatribe above re: validation.

And again - if your fears had any basis, the banking system in general would have collapsed YEARS ago and it would be me driving the cab.

----

Arlin said: "SECONDLY: The only manner in which to avoid this problem is to go to a human in the loop system where each transaction is double checked manually. You have made no mention of this as a possibility and without it, your data will either be corrupted in short order, or nonexistant as your filters reject all of the incoming message stream for errors...depends on how you write the filters...y'know?

Geeze Arlin - I don't know what to do to make you feel better. You are, apparently, one of those incurable pessimists who just delight in having bad news to ponder. I am tiring of this.

----

Arlin said: "I'm really sorry Randy, but you've got to realize that the situation is a tad more complex than the manuals and standards documents make it sound. Try talking to the folks over on euy2k.com, and then try talking to some of the big iron programmers here on this board (sysman and the others) - they'll be able to help you get a grasp of this much better than I will "

Arlin, I more that realize the complexity of the industry, I am one of the people who helped form parts of it and work daily to keep advancing it. Oh and Arlin - don't look now, but I am one of those "big iron programmers" you speak so fondly of. What are you?

Yours in COBOL... Dino!

-- COBOL Dinosaur (COBOL_Dinosaur@yahoo.com), May 18, 1999.

So evidently we have a financial institution here that is ready for 2000. Has this institution announced it is compliant, ready, non- corruptible, not subject to defaults, cross defaults, or cascading faults of any kind? It would be very worthwhile to be the first to do this. This should be welcome news for its customers plus all the other people who are nervous about where to put their business. Congratulations on this rock solid description of assurance. So when will we hear the announcement?

-- roy scruggs (rscruggs@triada.com), May 18, 1999.

Doggone, I sure enjoyed this thread/debate/discussion. Read every word of it. Just wish I knew what the hell those two fellers were talking about? If those who know, don't know....how do we know??? I guess we will all know next year. In the meantime, our rural electric co op continues to buy and sell large generators to businesses. They told me that was so the power co could direct more power to the people. They generate no power, buy from a non net producer. We figure we are at the end of the line, figuratively and literally!!

Got our generator.....but still no new red truck !!

Taz

-- Taz (Tassie @aol.com), May 18, 1999.

interesting - what we have here, Dino, is a problem with credibility - I refuse to accept yours and you refuse to accept mine. As of right now I've spent in excess of three hours on posts responding to your assertions. Quite frankly I'm beginning to think this game ain't worth the candle. If you want to know more about me, please feel free to search the forum archives - I always post under my own name. always. FWIW: My sources in the utilities industry are at the senior project management level, which is why I'm aware that your assertions concerning the electrical grid are in error.

In the meantime, I'll get back to my information collection, and my y2k preparations, because quite frankly trying to get you to think past your blind faith in the system is apparently beyond my capacity - blind faith being your real final argument. *sigh*

Arlin Adams

-- Arlin H. Adams (ahadams@ix.netcom.com), May 18, 1999.

oh good grief, I just read the quote from OutingsR's post...*sigh* sorry Outings, if I'd read that to begin with I'd never have bothered! I must be tired, allowing myself to be baited by a simply lying troll...

*sigh*

Arlin

-- Arlin H. Adams (ahadams@ix.netcom.com), May 19, 1999.

Hi Dino,

Sorry for the delay here, I'm usually on every few hours, but have been busy at home with my new copy of MS Studio 6.0, and have been swamped at work, jeez, for the last 10 days or so. Damned computers...

"COBOL-II (Also known as COBOL-85 with a "twist")"

My copy of COBOL-II for VSE, dated May 1989, still shows CURRENT-DATE as MM-DD-YY. True that recent versions of COBOL/390 do support the CENTURY field, but it is my understanding that the IBM Operating Systems did not offer CENTURY support until the early or mid 90's, hence ALL mainframe languages did not offer this support before then. I'm an Assembly guy, and don't stay up on COBOL issues much. In fact, I don't stay up on "old" issues much, but there is a bunch of that "old" code out there...

And again, I'm really not that worried about the banks. They are known for being the leaders in the Y2K war, got an early start, and are regulated, and guaranteed, well sorta. I really don't care, because I'm "good to go" for a while. I worry about the rest of the 50,000 or so mainframes out there, and the countless number of custom written applications that they run. And the millions of PC's, and the "billions" of embedded systems, the unknown factor, that's what I'm concerned with. I'm worried because I've seen some strange shit in my 31 years of pushing bits... <:)=

-- Sysman (y2kboard@yahoo.com), May 19, 1999.

Sysman said: "Sorry for the delay here, I'm usually on every few hours, but have been busy at home with my new copy of MS Studio 6.0, and have been swamped at work, jeez, for the last 10 days or so. Damned computers... "

I installed v5.0 of MS Studio - I basically wanted it for the C++ and Java tools, which BTW, took a totally unreasonable amount of disk space - over 500 meg for C++ dev suite alone. I walk both sides of the line from mainframe to PC - Client Server development as well as Proj Mgmt and System Architecture. I love working with all the different tools available to us now. If only we had an IDE back in the 70's... Wow..

Sysman said ""COBOL-II (Also known as COBOL-85 with a "twist")" My copy of COBOL-II for VSE, dated May 1989, still shows CURRENT-DATE as MM-DD-YY. True that recent versions of COBOL/390 do support the CENTURY field, but it is my understanding that the IBM Operating Systems did not offer CENTURY support until the early or mid 90's, hence ALL mainframe languages did not offer this support before then. I'm an Assembly guy, and don't stay up on COBOL issues much. In fact, I don't stay up on "old" issues much, but there is a bunch of that "old" code out there... "

If you look back at my reply in regard to CURRENT-DATE you will see that I referenced an "INTRINSIC FUNCTION" which has been available for about a decade now. As I recall the IF's were covered in addendum manuals to all the languages offered by IBM until COBOL/370 when they were embedded within the "Programmer's Guide" not the Language Reference manuals. I have the old manuals in storage or I would give you the numbers for them. Funny though, I still have my green card and a bunch of yellow cards that I never did put into storage. You would be correct about the century field not getting support within the system's current date until 1991 which, as I recall, is when we got the patch to MVS to cover this. Like you I started out doing Assembly code and then got into doing BAL to COBOL conversions. Yes there is still a lot of old code out there but it is not that hard to repair (or I could use the Y2K era "remediated" term) when using the intrinsic function and/or windowing logic. The Windowing logic is a Band-Aid for some applications, but a permanent fix in others if the windowing logic is "sliding" and data archiving is taking place.

Some of the tools available now use fuzzy logic to ferret out dates and date identifiers in programs so well that it takes very little manual effort to identify and resolve date related issues. The bigger problem is the recompilation and linking of programs and systems so that they will, once again, work in harmony.

Yours in COBOL... Dino

-- COBOL Dinosaur (COBOL_Dinosaur@yahoo.com), May 19, 1999.