Subject:	A challenge for CET Poole.
Date:	1999/07/14
Author:	cory hamasaki <kiyoinc@ibm.XOUT.net>
	Posting History

A job for CET Poole.  Take this back to your nest of debunkers. This may help them out.   [Excuse me but mainframes don't fail from 0C7 (data exception) abends. Application programs , however, will. This is "not" parallel to MS-Word having a glitch and taking the whole PC down with it. PC's are known for failures such as this. Mainframes, on the other hand, have a far more robust and bulletproof OS, which will not allow (generally speaking) an application program to compromise the entire system. I have not seen a failure like this in almost 20 years]   Yes, they do.  Here's how.  The reason that MVS is robust is three fold. It has protected memory, there is a separate priviledged state called "Supervisor", and the Operating System has been debugged as best as humanly possible.   None of these are true for problems in User SVCs.   ["machine utilization accounting system" There it is - an application program.]   No, you've never worked in priviledged state.  Machine resource accounting means capturing and monitoring the activities of all applications as well as the operating system itself.  This is accomplished by means of instrumentation probes inserted into the heart of the operating system.  These instrumention probes, SMF exits, are extensions to the operating system.  In addition, a portion of the code ran as a resident User SVC.   [Binary arithmetic can be performed on any character whether it is alpha, numeric or special character. If I translated your name into binary, it is a series of 1's and 0Js, which will lend themselves quite readily to any mathematical calculation you please. Then there was: "the next binary number after 1979 is 197A" Wrong, the next "HEXADECIMAL" number after 1979 is 197A - This is one of the things that bothered me - it is an extremely sophomoric mistake made by someone who says he has over 30 years in the business!]   Sorry no.  In S/370-S/390 there is binary, packed decimal, and floating point.  Hexadecimal does *not* exist in S/370-S/390 as a data type. Machine language purists make this very clear.  "The next binary number after 1979 is 197A" is proper terminology in S/370-S/390.  It's a short version of "the next binary number after (binary)'1979'Hexadecimal is (binary)'197A'Hexadecimal".   [This is all plausible but questionable as to why an application was allowed to run in "supervisor state" when it could run in it's own region having access to everything an accounting application should require.]   The reason is that it was accounting for "everything" including the operating system itself.   [One of the things that bother me here is that Cory never mentions what the register would look like in a normal state - Are we to assume that is should have looked like 0001979F? If so, this is not a proper representation of the register. 00001979 would be proper. 0000197A would be proper * BUT * The Hex value of the year 1979 is "7BB" and the Hex Value of the year 1980 is "7BC". The "F" that Cory is showing, I assume, is a "sign byte" which is neutral (unsigned) meaning that the year 1979 was not assigned as either positive "C" or negative "D". This would show in a hex core dump as:   0099 017F   But the integer value of 1979(hex) is "6521". What is it Cory is trying to tell us here?   maybe I am picking nits - but - am I ? ]   No, you're just completely wrong and don't know S/370-S/390 operating systems, assembly language, or S/370-S/390 architecture. But that's OK.   The job accounting system was attemping to toss the machine resource records into monthly buckets.  The buckets existed as slots in auxiliary storage managed by a home grown DBMS using BDAM. There was an error in the index hash algorithm but that's another story.   To frame the transactions, the code had to generate the end bound. On December 1, 1979, the end bound was the first second of January 1, 1980. It did *something* like:         XR  R5,R5       L  R5,curdat    0001 979F       SRL R5,4          0000 1979       LA  R5,1(,R5)    0000 197A       SLL R5,4          0001 97A0       ST  R5,enddat       OI  enddat+3,X'0F'   curdat DC  PL4"1979"    0001 979F enddat DS  PL4   for 1977, it generates 1978 for 1978, it generates 1979   and for 1979, it generates 197A.   That's how the number was generated.  Later, much later, the user SVC took the 0C7.  Note that the example does *not* say where the numbers are binary, decimal, hexadecimal.  Real programmers know.   [I would have loved to see that core dump]   The dump was perhaps 6 inches of greenbar paper.   [I believe that this problem was manufactured by a fertile imagination - but that is my opinion and I welcome other learned opinions on this article]   And your opinion is wrong.   [Yours in COBOL... Dino! AKA Randy Van de Loo]   This whole affair of CET Poole and his "debunkers" forum bothers me.  Is this the level of technical expertise out there?  Some of you may recall CET swaggered into c.s.y2k and TB2K and crowed how his COBOL expert had debunked my 000197AF story.   He was absolutely sure, cock-sure that he and his crew had exposed the old fat geek.  This evening, I was scanning TB2K and saw a reference to the Debunkers so I followed the link and discovered an interesting thread about me and 000197AF started by CPR. A bunch of debunkers were savaging my article.   Strangely enough, there was a non-polly in there with them who did a credible job of educating them about S/370 and machine language programming.   I don't know who that person is.  He glossed over some points and spent a lot of time on others but essentially he showed competancy in assembly language although I don't think he was an operating systems internals person (like SHMUEL).   Based on the absolute certainty of the debunkers and how very wrong they are, I'm afraid that much of the "GREAT NEWS" out there is more wishful thinking by others like CET.  It may be incorrect to extrapolate from this one sample but I don't trust anything that the debunkers are certain about.   As -bks- demands a high standard from the bright side of the force, someone should hold the Pollies to some standards.  Who is up to it?   cory hamasaki http://www.kiyoinc.com/current.html 30 Years on S/360-S/390, mostly as a programmer, sometimes as an executive, consultant, floor sweeper.  M.S. Computer Science from G.W.U. Primarily on MVS-like operating systems, C, Rexx, PL/I, S/370 assembly language.  *no* COBOL. 

-- a (a@a.a), July 14, 1999

Answers

"a", thanks for the post, Cory stood the big Dino on it's head !!

Have you noticed the activity level of these Polly/Trolls picking up lately. It's as though they have been instructed to go full bore in trying to deceive the public. Should get real interesting in the not to distant future.

Ray

-- Ray (ray@totacc.com), July 14, 1999.

Don't these "Queens" have jobs? Or perhaps debunking IS their current state of employment. Perhaps nothin', I think it's pretty obvious.

-- Will continue (farming@home.com), July 14, 1999.

390 Assembler language which the SVCs are written in is UGLY. Not just hard and tedious like PC or mini-computer assembler, but UGLY, owing to its evolution over time.

-- Anonymous99 (Anonymous99@Anonymous99.xxx), July 14, 1999.

Based on the absolute certainty of the debunkers and how very wrong they are, I'm afraid that much of the "GREAT NEWS" out there is more wishful thinking by others like CET.

Too true. The "good news" these days is not facts, nor history, nor even opinion. It is merely optimistic expectations.

-- Lane Core Jr. (elcore@sgi.net), July 14, 1999.

Lane:

Yes, maybe if we hope and wish *REAL* hard it will be "all better".

Kind of like my puppy trying to cover up an accident in the kitchen....

-- Jon Williamson (pssomerville@sprintmail.com), July 14, 1999.

'a':

In defense of Dino, I do believe this is the first time that Cory has presented the actual code. I DO have the knowledge that he felt lacking to analyze this problem, and the first huge mistake in this code was loading a packed date into a register and then continuing to perform arithmetic on it within the register. A simple convert to binary instruction would have corrected the logic.

Dino was correct in his references to binary and hexadecimal. Had a convert to binary been issued, the result would NEVER have looked like 197A. It sure was fun going down memory-lane again looking at a little Assembler code....even if it WAS bad Assembler code.

-- Anita (spoonera@msn.com), July 14, 1999.

Anyone who has not seen a user program take down multiple partitions has NOT worked in older COBOL/IMS apps. We used to REGULARLY pull down the whole kit-n-kaboodle as we were testing a couple of court database apps when I was a SA. OPS and TS HATED us, and very nearly wouldn't mount our tests. Eventually IBM and our hardware vendor found the links and the problems but it took a LONG time.

Chuck who has done more than drive.

-- Chuck, a night driver (rienzoo@en.com), July 15, 1999.

Anita,

It seems to me that Cory is constantly telling people like CET or Cobol Dino that they are wrong, wrong, wrong about the massive problems in fixing the big iron. Now he gives one small example and you seem to say "Oh, that's what he's talking about. No big deal, just make a small fix and it's running ok again." Do you *really* have any idea what Cory is talking about? I don't think so.

-- Gordon (gpconnolly@aol.com), July 15, 1999.

Gordon:

You wrote:

"It seems to me that Cory is constantly telling people like CET or Cobol Dino that they are wrong, wrong, wrong about the massive problems in fixing the big iron. Now he gives one small example and you seem to say "Oh, that's what he's talking about. No big deal, just make a small fix and it's running ok again." Do you *really* have any idea what Cory is talking about? I don't think so."

I really don't keep track of what Cory says or is constantly telling people. Even though I'm only 29, Gordon [grin], I have as much (perhaps more) experience in assembler language and systems programming. Now, I don't think Cory ever said that he WROTE this program, so I'm not saying that HIS logic was faulty. In addition, there's a bit more to the fix than the one instruction that I mentioned, but if I elaborated, would YOU know what I was talking about?

The description of the problem as I'd originally seen it presented on a technical forum raised many questions regarding how the binary representation of 1980 could be 197A. There was no mention of the original field being packed decimal. The inclusion of the code here clarified this issue.

-- Anita (spoonera@msn.com), July 15, 1999.