DFHCOMMAREA
Frank Swarbrick
day. First, let me post a code snippet.
LINKAGE SECTION.
01 DFHCOMMAREA PIC X(2125).
PROCEDURE DIVISION.
IF EIBCALEN = ZEROES
GO TO 9300-XCTL-TO-RE10
ELSE
MOVE DFHCOMMAREA TO RE-COMMAREA
IF RECOM-TRAN-ID = 'RE10' OR 'RE12'
PERFORM 1000-SEND-INIT-MAPRE11
ELSE
PERFORM 2000-RECEIVE-MAP.
Basically, this program (CICSRE10) can be entered two ways. If it was
entered via an EXEC CICS RETURN TRANID('RE11') COMMAREA(RE-COMMAREA)
then EIBCALEN would not be zeroes and RECOMM-TRAN-ID would be 'RE11'.
This should trigger the above to do the perform of 2000-RECEIVE-MAP.
The other way it can be entered is a related program (CICSRE10 or
CICSRE12) doing EXEC CICS XCTL PROGRAM('CICSRE11')
COMMAREA(RE-COMMAREA). Again, EIBCALEN would not be zeroes. But in
this case RECOMM-TRAN-ID would be 'RE10' or 'RE12', depending on which
program did the XCTL. We would in this case perform
1000-SEND-INIT-MAPRE11.
But here's the deal. Sometimes the "MOVE DFHCOMMAREA TO RE-COMMAREA"
seems to have no effect. In other words, it's as if that line is not
even there (so RE-COMMAREA remains all low-values, or whatever). We've
used Intertest to trace the program and, even though it seems to 'do'
the move, we can see that nothing is actually moved.
This doesn't happen all of the time, though. In fact, if the user tries
it and it fails, then logs out (to the VTAM menu) and logs back and
tries it again it may work.
The problem does not seem to occur in production. Or at least no user
has ever reported it. One difference between our production CICS and
our test CICS is that production still has the VS COBOL II runtime,
while test has LE/VSE 1.4.1 (VSE/ESA shop...running CICS/VSE 2.3 in both
prod and test).
One thought is this... Even though DFHCOMMAREA is defined as 2125
bytes, EIBCALEN is never near that size. In fact, the RETURN and XCTL
both include the LENGTH parameter and it's much less than 2125. So when
this program does the MOVE it sometimes is accessing storage that is not
available to the program...? The obvious solution it that case is to
change the MOVE to: MOVE DFHCOMMAREA (1:EIBCALEN) TO RE-COMMAREA.
RE-COMMAREA is working storage. It's 2125 bytes, but includes over 1000
bytes of filler. The original programmer did this anticipating future
expansion...
Anyway, we're just wondering if this sounds like it may be the problem.
We have a lot of programs that do this kind of thing, though the others
have nowhere near this much filler. This is the only program we've run
in to this behavior, though, and we've had CICS under LE for three or
four months. Now we're kind of nervous about going in to production
with LE/VSE, though.
Any thoughts?
--
Frank Swarbrick -- now powered by SuSE Linux 7.2
"I'm very seldom naughty" --Willow Rosenberg, 'Buffy the Vampire Slayer'
Richard
> LINKAGE SECTION.
> 01 DFHCOMMAREA PIC X(2125).
>
> PROCEDURE DIVISION.
> IF EIBCALEN = ZEROES
> GO TO 9300-XCTL-TO-RE10
> ELSE
> MOVE DFHCOMMAREA TO RE-COMMAREA
> IF RECOM-TRAN-ID = 'RE10' OR 'RE12'
> PERFORM 1000-SEND-INIT-MAPRE11
> ELSE
> PERFORM 2000-RECEIVE-MAP.
Why is there no 'USING DFHCommArea' on the PROCEDURE DIVISION header ?
docd...@panix.com
The CICS translator supplies it... at least the one on an IBM mainframe
quite often does.
DD
Paul Pigott
"Richard" <rip...@Azonic.co.nz> wrote in message
news:217e491a.02071...@posting.google.com...
Unless things have dramatically changed on me, doesn't the CICS translator
insert that small bit of code? (Along with lots of other bits of code?)
Paul
Paul Raulerson
this. The zero test might be TRUE when the length of the comm area is zero.
-Paul
"Richard" <rip...@Azonic.co.nz> wrote in message news:217e491a.02071...@posting.google.com...
David_G_Clark
You've almost got the reason. This is caused because cobol is generating
an assembler Move Characters Long instruction because of the lenght you've
specified. However with the MVCL, there cannot be overlap of storage or the
move never happens and (as far as I know) no error condition is ever raised.
The reason it does not fail consistantly is because CICS would need to
load the programs working storage area next to the passed DFHCOMMAREA which
would be much shorter than the 2125 you've specified and so result in an
overlap of fields. Cobol is going to move 2125 bytes so if the real size is
125, then 2000 bytes of whatever follows gets pulled in - if that happend to
be part of RE-COMMAREA because it happens at that moment in time to follow
the DFHCOMMARA in memory, then nothing is moved and no error condition (at
least at the point of move).
The only way to avoid is to use matching lengths. Even when it does
not fail, you're getting some sort of data moved to the end of RE-Commarea
though program might not referance it so it doesn't cause trobles. Easiest
way is to use referance modification (which I think can be used with cobol II)
MOVE DFHCOMMAREA (1:EIBCALEN) TO RE-COMMAREA
should fix problem if I've remembered the code correctly.
In article <3D34BDA1...@sprynet.com>, inf...@sprynet.com says...
Frank Swarbrick
check for non-zeroes". No difference (well, except the obvious). In
any case, it will never be RETURNed to or XCTL'd to with a commarea of
zero. The only time EIBCALEN is zero is if the transaction is started
by a user on blank CICS screen. In this case we go to RE10, which is
the menu program.
--
Frank Swarbrick
never thought of this being the answer (not knowing assembler very well,
in any case), but it makes absolute sense.
Let me make sure I understand exactly. There are 1576 bytes of
working-storage ahead of the beginning of RE-COMMAREA. So if the
address of EIBCALEN is, say 200, then DFHCOMMAREA could conceivably
start at 200 bytes ahead of that. That would mean that if RE-COMMAREA
is greather than 1776, which it is, then DFHCOMMAREA, being defined as
2125 bytes would overlap with RE-COMMAREA. Does this sound right?
Interesting. I assume that the reason that it sometimes works is
because the DFHCOMMAREA being referred to may or may not be immediately
ahead of program working-storage, correct?
Woah! So it looks like this has nothing to do with COBOL II runtime vs
LE/VSE runtime. Would perhaps the reason it never seems to happen in
production is because the DFHCOMMAREA is never immediately ahead of the
program's working-storage? Or maybe it has happened and no one has
reported it to us. I don't think the transaction is used by too many
people.
Anyway, I think I figured out why no other programs are having this
problem. Our other major programs that have a commarea this large
handle it a bit differently. Something like:
IF EIBCALEN = DD-CA-SIZE
MOVE DFHCOMMAREA TO DD-COMMAREA
ELSE IF EIBCALEN = CU-CA-SIZE
MOVE DFHCOMMAREA TO CU-COMMAREA
etc. etc.
Because the destination is the proper size only that number of bytes is
moved.
Thanks a bunch for your help. We'll fix the offending programs (only 3,
I believe) and go on with our happy programming lives! :-)
Frank
Paul Raulerson
statement somewhere. Believe it or not, sillier things have happened. Your trouble seems to be pretty much related to that kind of
issue. In other words, what would happen if you *did*
get back a comm area with an unexpected length?
Besides which, you should be using the EIBCALEN to determine how much of that comm area to return anyway.
"Frank Swarbrick" <inf...@sprynet.com> wrote in message news:3D360AE1...@sprynet.com...
Rbo...@aol.com
As Garry Hasler will tell you there is no reason NOT to use the LE runtime. There is also no reason to MOVE a COMMAREA to working storage if the program is compiled under COBOL/VSE (not sure about COBOLII). Here's some code that would negate the MOVE:
LINKAGE SECTION.
01 DFHCOMMAREA.
03 SAVE-SESS PIC XX.
03 YADA-YADA-YADA
PROCEDURE DIVISION.
IF EIBCALEN = 0
EXEC CICS GETMAIN SET(ADDRESS OF DFHCOMMAREA)
INITIMG(HEX-ZERO) LENGTH(LENGTH OF DFHCOMMAREA) END-EXEC
ELSE
IF SAVE-SESS = some-value
EXEC CICS RETURN TRANSID(EIBTRNID) COMMAREA(DFHCOMMAREA) LENGTH(LENGTH OF DFHCOMMAREA) END-EXEC.
Bob Botsis
Kroger Company
513.745.5487
rbo...@aol.com
(I read and I remember,
I do and I understand)
Ken Meyer
overlap. You may want to use LISTX (or whatever the parameter
is now) to get an assembler listing of the COBOL routine.
If the condition code is not being checked after an MVCL then
the COBOL compiler should be fixed.
Ken Meyer
CSI/BIM
>snip..
> However with the MVCL, there cannot be overlap of storage or the
> > move never happens and (as far as I know) no error condition is ever
> raised.
snip..
Frank Swarbrick
that EIBCALEN was zero. It was that EIBCALEN was less than the
declaired size of DFHCOMMAREA.
Anyway, the solution, as already posted, is to use reference
modification "MOVE DFHCOMMAREA (1:EIBCALEN)".
Frank
Frank Swarbrick
is, but here's the relevant listing:
001497 1 000148 MOVE DFHCOMMAREA TO RE-COMMAREA
001498 1 000149 IF RECOM-TRAN-ID = 'RE10' OR 'RE12'
001497 MOVE
000B34 4120 A628 LA 2,1576(0,10)
RE-COMMAREA
000B38 4130 084D LA 3,2125(0,0)
000B3C 5810 D144 L 1,324(0,13) BLL=2
000B40 4140 1000 LA 4,0(0,1)
DFHCOMMAREA
000B44 5850 902C L 5,44(0,9) PGMLIT
AT +0
000B48 0E24 MVCL 2,4
001498 IF
000B4A D503 A628 9373 CLC 1576(4,10),883(9)
RECOM-TRAN-ID PGMLIT AT +839
000B50 4780 B4EE BC 8,1262(0,11)
GN=6(000B5E)
000B54 D503 A628 9413 CLC 1576(4,10),1043(9)
RECOM-TRAN-ID PGMLIT AT +999
000B5A 4770 B50E BC 7,1294(0,11)
GN=5(000B7E)
000B5E GN=6 EQU *
As you can see, there is no code after the MVCL and before the next
COBOL statement. What code do you think should be produced here? It
would have to trigger some type of runtime error, I guess.
Frank
--
Frank Swarbrick
>
> Frank,
>
> As Garry Hasler will tell you there is no reason NOT to use the LE
> runtime. There is also no reason to MOVE a COMMAREA to working storage
> if the program is compiled under COBOL/VSE (not sure about COBOLII).
> Here's some code that would negate the MOVE:
>
> LINKAGE SECTION.
> 01 DFHCOMMAREA.
> 03 SAVE-SESS PIC XX.
> 03 YADA-YADA-YADA
>
> PROCEDURE DIVISION.
>
> IF EIBCALEN = 0
> EXEC CICS GETMAIN SET(ADDRESS OF DFHCOMMAREA)
> INITIMG(HEX-ZERO) LENGTH(LENGTH OF DFHCOMMAREA) END-EXEC
> ELSE
> IF SAVE-SESS = some-value
>
> EXEC CICS RETURN TRANSID(EIBTRNID) COMMAREA(DFHCOMMAREA) LENGTH(LENGTH
> OF DFHCOMMAREA) END-EXEC.
We're just waiting on some testing of a vendor product and then we'll go
to LE. Probably next month.
As for how you handle creating the commarea... I agree in general, but
100% of our shop's programs create it in working storage and do the
move. So I'm not going to rock the boat...
Ken Meyer
else you are assuming the COBOL programmer knows how machine
language works.. :)
Ken Meyer
CSI/BIM
snip..
Frank Swarbrick
assembler code after the MVCL might look like?
Thanks,
Frank Swarbrick
--
Volker Bandke
<inf...@sprynet.com> wrote:
>A programmer at my shop came upon a rather strange situation the other
>day. First, let me post a code snippet.
>
>LINKAGE SECTION.
>01 DFHCOMMAREA PIC X(2125).
>
>PROCEDURE DIVISION.
> IF EIBCALEN = ZEROES
> GO TO 9300-XCTL-TO-RE10
> ELSE
> MOVE DFHCOMMAREA TO RE-COMMAREA
> IF RECOM-TRAN-ID = 'RE10' OR 'RE12'
> PERFORM 1000-SEND-INIT-MAPRE11
> ELSE
> PERFORM 2000-RECEIVE-MAP.
>
First things first. MOVE DFHCOMMAREA(1:EIBCALEN) TO RE-COMMAREA is
definitely safe, as opposed to MOVE DFHCOMMAREA TO RE-COMMAREA
>We've
>used Intertest to trace the program and, even though it seems to 'do'
>the move, we can see that nothing is actually moved.
This is exactly what is the case. The size of the areas to be moved
is large enough to call foe MVCL instruction to be used. MVCL,
though, does not allow a destructive MOVE (like MVS would allow).
Therefore the MVCL would stop with cc 3 set, which the cobol compiler
does not react on. This is no bug (neither in CICS nor in Cobol) It
is just the way the cookie crumbles.
Assume EIBCALEN = 100
Move DFHCOMMAREA to RE-COMMAREA might look like this
+---------------+ +------------------------------+
! passed data ! ! RE-COMMAREA at data + 200 !
+---------------+ +------------------------------+
<-- 100 bytes --> <--------- 2000 bytes -------->
<--- EIBCALEN -->
+-------------------------------------+
! DFHCOMMAREA ! same address as passed data
+-------------------------------------+
<--------------- 2000 bytes ---------->
Move DFHCOMMAREA to RE-COMMAREA lead to destructive overlay, as
DFHCOMMAREA and RE-COMMAREA overlap
MOVE DFHCOMMARE(1:EIBCALEN) TO RE-COMMAREA avoids the overlap
Having said that, my question to you? Why use this unnecessary MOVE
in the first place? It is just plain "BAD" (Broken As Designed)
Assume you do the following
PGM A Links to PGM B passing a commarea
PGM B MOVES COMMAREA to WS
PGM B XCTL to PGMC, passsing WS-Commarea
PGMC RETURNS (to PGMA)
Data in Commarea of PGMC never show up in A
With kind Regards |\ _,,,---,,_
ZZZzz /,`.-'`' -. ;-;;,
Volker Bandke |,4- ) )-,_. ,\ ( `'-'
(BSP GmbH) '---''(_/--' `-'\_)
You will soon meet a stranger who will become your friend.
(Another Wisdom from my fortune cookie jar)
-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----
Frank Swarbrick
Yep, this is exactly what is happening and that is the exact solution.
> Having said that, my question to you? Why use this unnecessary MOVE
> in the first place? It is just plain "BAD" (Broken As Designed)
>
> Assume you do the following
>
> PGM A Links to PGM B passing a commarea
> PGM B MOVES COMMAREA to WS
> PGM B XCTL to PGMC, passsing WS-Commarea
>
> PGMC RETURNS (to PGMA)
>
> Data in Commarea of PGMC never show up in A
I'm not exactly sure what your question is. Number 1, there are no
LINKs involved. The only ways to enter the aforementioned program are
A) from a blank CICS screen, in which case EIBCALEN is zero, B) from
itself view a RETURN TRANSID COMMAREA and C) via XCTL PROGRAM COMMAREA
from another program.
Are you referring to the fact that the COMMAREA is moved to
working-storage at all? If so, all I can say is it's been the shop
standard for 20 years and I can't imagine it being changed now.
Volker Bandke
>> PGM A Links to PGM B passing a commarea
>> PGM B MOVES COMMAREA to WS
>> PGM B XCTL to PGMC, passsing WS-Commarea
>>
>> PGMC RETURNS (to PGMA)
>>
>> Data in Commarea of PGMC never show up in A
>
>I'm not exactly sure what your question is. Number 1, there are no
>LINKs involved.
I know. I was just showing another simple case where copying commarea
to Working storage is harmful
>
>Are you referring to the fact that the COMMAREA is moved to
>working-storage at all? If so, all I can say is it's been the shop
>standard for 20 years and I can't imagine it being changed now.
Yes, that is what I was referring to - Moveing/copying data from
DFHCOMMAREA to WORKING-STORAGE is a "Bad Thing" (TM). But, of
course, changing a 20 year old shop standard, as bad as it may be, is
an "Impossible Thing" (TM) and should not necessarily be tried
With kind Regards |\ _,,,---,,_
ZZZzz /,`.-'`' -. ;-;;,
Volker Bandke |,4- ) )-,_. ,\ ( `'-'
(BSP GmbH) '---''(_/--' `-'\_)
One of the best automobile insurance policies is a sunday afternoon nap.
indust...@dapsco.com
> can you give me a hint as to what the assembler code
> after the MVCL might look like?
Frank,
These are the possible resulting condition codes from an MVCL
instruction:
Resulting Condition Code:
0 Operand lengths equal; no destructive overlap
1 First-operand length low; no destructive overlap
2 First-operand length high; no destructive overlap
3 No movement performed because of destructive overlap
Though there is nothing you can do about the fact that COBOL does not
test the condition code after the MVCL instruction, the following is what
such assembler code could look like (for the last one shown above):
BC 3,label
(where: 'label' represent a branch address) or:
BCR 3,n
(where: 'n' represents a branch register number).
Sincerely,
Dave Clark
dcl...@dapsco.com
DAPSCO Information Systems
3110 Kettering Boulevard
Dayton, Ohio 45439
(937) 294-5331
Chuck Arney
test for a condition code of 3 you need to use a Branch on Condition mask of
1. That is a BC 1,Label or BCR 1,Reg. Or just make it easier and use
Branch on Overlap, which is BO (I just made that up. BO is usually thought
of as Branch on Overflow, but in this case Overlap makes more sense and in
any case it is a BC 1).
Strange, I know. Just another of the little details an assembler programmer
has to be aware of.
Chuck Arney
IntelliWare Systems Inc. http://www.intelliware.com
Access 3270 apps from the web with z/Web-Host
Access 3270 data from anywhere with z/XML-Host
Access CMS minidisks from OS/390 & VSE with CMSACCess
Voice: 972-296-6166 Fax: 972-296-5468
Frank Swarbrick
>
> > can you give me a hint as to what the assembler code
> > after the MVCL might look like?
>
> Frank,
>
> These are the possible resulting condition codes from an MVCL
> instruction:
>
> Resulting Condition Code:
> 0 Operand lengths equal; no destructive overlap
> 1 First-operand length low; no destructive overlap
> 2 First-operand length high; no destructive overlap
> 3 No movement performed because of destructive overlap
>
> Though there is nothing you can do about the fact that COBOL does not
> test the condition code after the MVCL instruction, the following is what
> such assembler code could look like (for the last one shown above):
>
> BC 3,label
>
> (where: 'label' represent a branch address) or:
>
> BCR 3,n
>
> (where: 'n' represents a branch register number).
Thanks. Someone had mentioned that the COBOL compiler should be
"fixed". I doubt it's worth bothering with trying to get that done,
though. The problem is fixed, so...
indust...@dapsco.com
> ...you have the right idea but not quite the right code.
Chuck,
I figured that somebody was going to "catch me out" on this one. Once
upon a time I knew that there was a "trick" to using the BC (and BCR)
instruction; but, I normally stick to the Extended Branch Mnemonics and
have, since, forgotten just what that "trick" was. So, to remind me (and
for the COBOL programmer who asked), please explain how you arrive at
testing for a "1" when the condition code is actually a "3"?
Now, isn't the condition code actually four binary digits (bits) that
can be set on and/or off in any combination such that the "Branch on
Condition" (BC) instruction can use numbers from 0 to 15 -- right? What
else do I need to be reminded about this? Thanks.
indust...@dapsco.com
Chuck,
OK, I got it. I was actually thinking that I was going to need a
reciprocal of 3 (12) in order to test for it. But, now I see that it is
merely because the condition code numbers are the reverse of the associated
binary values -- as in this correspondence:
0123 - cc bit number
8421 - binary value
Thanks for the reminder. ;-)
Chuck Arney
Naturally the designers chose to name them codes 0-3, as with the normal bit
naming scheme (left to right). So, just as in a TM instruction, you use a
mask of 8 to determine if the condition code 0 bit is on, a 4 to test for
condition code 1, 2 to test for condition code 2 and 1 to test for condition
code 3.
Its all very simple use of a mask to test one or more bits. The only thing
that makes it confusing, is that normally the bits in a byte are numbered
0-7 (left to right) and bit zero would be tested with a X'80'. Bit 1 would
be tested with a X'40'. And so forth. But, since the BC(R) instructions
only have 4 bits for the mask instead of 8 bits, the mask bits are
effectively X'08'-X'01' instead of X'80'-X'10'. Did that clear it all up?
:>).
Chuck Arney
IntelliWare Systems Inc. http://www.intelliware.com
Access 3270 apps from the web with z/Web-Host
Access 3270 data from anywhere with z/XML-Host
Access CMS minidisks from OS/390 & VSE with CMSACCess
Voice: 972-296-6166 Fax: 972-296-5468
----- Original Message -----
From: <indust...@dapsco.com>
To: "VSE Discussion List" <vs...@Lehigh.EDU>
Chuck Arney
to the PSW format level.
Chuck Arney
IntelliWare Systems Inc. http://www.intelliware.com
Access 3270 apps from the web with z/Web-Host
Access 3270 data from anywhere with z/XML-Host
Access CMS minidisks from OS/390 & VSE with CMSACCess
Voice: 972-296-6166 Fax: 972-296-5468
----- Original Message -----
From: "Gary Weinhold" <wein...@dkl.com>
To: "VSE Discussion List" <vs...@Lehigh.EDU>
Sent: Monday, July 22, 2002 10:58 AM
Subject: Re: DFHCOMMAREA
> Sorry to complicate this further, but there are only two bits in the
> condition code. These two bits can have the values 00, 01, 10, 11,
> (0,1,2,3).
>
Gary Weinhold
condition code. These two bits can have the values 00, 01, 10, 11,
(0,1,2,3).
The condition code testing is not to determine which condition code bits
are on, but which values (0,1,2,3) are acceptable. So if values of both
0 and 2, for example, are both directed to the same logic, your branch
mask is x'1010' = 8+2 = 10.
The salmon or yellow book has a section called condition codes, which
correlates the conditon code values with the mask bits, then another
section Extended Mnemonic Instructions to indicate the mask bit values
corresponding to BH, BL, BO, BNM, etc., and yet another, Program Status
Word, which shows the 2-bit CC (Condition Code).
Gary Weinhold
Data Kinetics
indust...@dapsco.com
> I stand corrected, or reminded I guess. Its been a while
> since I got down to the PSW format level.
Chuck,
In your defense, for our discussion it doesn't matter if the condition
code (at the PSW level) is four bits or two. Testing for them is still
based on the 8421 mask. ;-)
Gary Weinhold
Gary Weinhold
Data Kinetics, Ltd
Ken Meyer
correspondence is very simple:
In PSW instruction
00 8 -> 1000 - bit 0 is on means test cc=0
01 4 -> 0100 - bit 1 is on means test cc=1
10 2 -> 0010 - bit 2 is on means test cc=2
11 1 -> 0001 - bit 3 is on means test cc=3
so you see there is no magic here.. :)
Ken Meyer
CSI/BIM
At 12:27 PM 7/22/2002 -0400, you wrote:
> > I stand corrected, or reminded I guess. Its been a while
> > since I got down to the PSW format level.
snip..
indust...@dapsco.com
Ken Meyer
<kmeyer@e-vse. To: "VSE Discussion List" <vs...@Lehigh.EDU>
com> cc:
Sent by: Fax to:
owner-vse-l@Le Subject: Re: DFHCOMMAREA
high.EDU
07/22/2002
01:52 PM
Please respond
to vse-l
You are all making this too complicated. The bit to instruction
correspondence is very simple:
In PSW instruction
00 8 -> 1000 - bit 0 is on means test cc=0
01 4 -> 0100 - bit 1 is on means test cc=1
10 2 -> 0010 - bit 2 is on means test cc=2
11 1 -> 0001 - bit 3 is on means test cc=3
so you see there is no magic here.. :)
Ken Meyer
CSI/BIM
Ken, I see plenty of "magic" there. First, there's only two bits, but they
get tested as if they are four bits. Second, those two bits only have four
possible values (0-3) but four bits have 16 possible values (0-15).
Lastly, you don't test for condition code 0 with a 0 -- you have to test
for it with an 8, etc., etc... Yup, that's "magic" alright. ;-)
Ken Meyer
00 01 10 11
One nibble can have only have 4 unique bit settings (not counting
zero):
1000 0100 0010 0001
If you look at it that way then the two agree. The unique bit
settings are required to determine which condition codes you wish
to check for.
checking not equal would be 0100 0010 0001 or'ed together to produce
0111 or 7.
Ken Meyer
CSI/BIM
snip..
>Ken, I see plenty of "magic" there. First, there's only two bits, but they
>get tested as if they are four bits. Second, those two bits only have four
>possible values (0-3) but four bits have 16 possible values (0-15).
>Lastly, you don't test for condition code 0 with a 0 -- you have to test
>for it with an 8, etc., etc... Yup, that's "magic" alright. ;-)
snip..
Bob Juch
Bob Juch
Director of Technical Services
UNICOM Systems, Inc.