Payroll Positive Negative Zero Branch and Inputs
Posted:
Sun Nov 27, 2011 2:45 am
by RISCCISCInstSet
In this problem I'm trying to properly branch based on positive, negative, or zero results.
I'm also trying to properly understand how to take three inputs from a file.
One last note: if you're thinking about inflammatory comments, or comments between yourselves about the way I suck I would prefer it if you kept them in PM's/other topics where it's the actual subject/wherever.
PAYROLL SUBENTRY
OPEN (INPUT,(INPUT),PRINTER,(OUTPUT))
READLOOP DS 0H
GET INPUT,INREC
MVC PRNTLINE,=CL133' '
MVC OUTNUM,INNUM
MVC PAY,=X'5C202020206B2021204B2020'
PACK THIRD,INNUM
PACK GROSS,INCOME
PACK DEDUCT,DED
* SP GROSS,DEDUCT
* ZAP MUL,DEDUCT
MP DEDUCT,DEDUCT
* ZAP MUL,GROSS
MP GROSS,THIRD
* ZAP MUL,GROSS
MP GROSS,THIRD
* ZAP SUB,DEDUCT
SP DEDUCT,=P'100'
* BC 2,POSITIVE
BC 4,NEGATIVE
* BC 8,ZERO
ED PAY,GROSS
B PRINT
POSITIVE DS 0H
MVC PAY,=CL12'POSITIVE'
NEGATIVE DS 0H
MVC PAY,=CL12'NEGATIVE'
ZERO DS 0H
MVC PAY,=CL12'ZERO'
PRINT DS 0H
PUT PRINTER,PRNTLINE
B READLOOP
ENDDATA DS 0H
CLOSE (INPUT,,PRINTER)
SUBEXIT
*
GROSS DS PL5
DEDUCT DS PL5
THIRD DS PL5
INREC DS CL26
INNUM EQU INREC,8
INCOME EQU INREC+9,8
DED EQU INREC+18,8
*INNUM EQU INREC+27,8
PRNTLINE DS CL133
OUTNUM EQU PRNTLINE+1,8
PAY EQU PRNTLINE+10,12
INPUT DCB DDNAME=PAYIN, X
DSORG=PS, X
EODAD=ENDDATA, X
LRECL=26, X
MACRF=(GM), X
RECFM=FT
PRINTER DCB BLKSIZE=1330, X
DDNAME=REPORT, X
DSORG=PS, X
LRECL=133, X
MACRF=(PM), X
RECFM=FBA
END PAYROLL
Re: Payroll Positive Negative Zero Branch and Inputs
Posted:
Sun Nov 27, 2011 2:55 am
by enrico-sorichetti
in this problem I'm trying to properly branch based on positive, negative, or zero results.
the
z/Architecture Principles of Operation available starting from here
https://www-304.ibm.com/support/docview ... c500428f9awill tell all You might want to know about branching after an <arithmetic>(*) operation
all You have to do is start using it
(*) the condition code used by a subsequent branch instruction is set also by <non strict arithmetic> operations
Re: Payroll Positive Negative Zero Branch and Inputs
Posted:
Sun Nov 27, 2011 3:49 am
by RISCCISCInstSet
It looks like I know about the BC operation, but the program's logic seems to be messed up. And I seem to be lost.
Re: Payroll Positive Negative Zero Branch and Inputs
Posted:
Sun Nov 27, 2011 4:22 am
by Robert Sample
but the program's logic seems to be messed up. And I seem to be lost.
Sorry, but I'm not inclined to help based on previous attempts -- messed up program logic and you being lost seem to be pretty common. Are you sure you want a career in IT?
Re: Payroll Positive Negative Zero Branch and Inputs
Posted:
Sun Nov 27, 2011 5:07 am
by BillyBoyo
Not so much a logic problem but you are "falling through". You haven't mentioned what your results are (which always helps when something "isn't working") but I should think they all say "ZERO". You branch to positive, you move POSITIVE, then fall into negative and move NEGATIVE then fall into zero and move "ZERO".
Re: Payroll Positive Negative Zero Branch and Inputs
Posted:
Sun Nov 27, 2011 5:46 am
by BillyBoyo
I now see you have commented-out two of the branches. So you get ZERO for negative, blanks for the other two.
You are also branching before you do the ED of the PAY, so you'll not get that at all for negative, but you will for positive and zero.
These are not Assembler errors, or logic errors, they are programming errors pure and simple. You have to honestly understand how they came about.
There is the logic, and there is the language. There is also the code to implement the logic.
You can't (yet) just sit down and start writing a program. You have to think about it. You have to "jot it down" in whatever way is comfortable for you (diagrams of some sort, pseudo-code of some sort, doesn't matter what) and then you have to set down some input data which will test your "program" (as you get more experienced this will become "parts of program" and then with more experience, you'll be writing the code without the actual diagramming/pseudo-code, it'll be "in your head"). You need good test data, some normal stuff, some abnormal stuff, and some stuff to test the upper and lower limits. That'll get you a general covering. Then from the data, work out your expected results. Then, work through your diagram/pseudo-code with the input data, recording the changes, and seeing if the expected results appear. If they don't, re-work it. Don't just "add in lines"/"comment out lines" and see what happens with real code. Once you are getting the expected results "by hand", then do the code, test with the same data. You'll know that either it is the implementation when an error occurs, or you can't hack the initial design.
This isn't Assembler advice, it is programming advice, learning to use a language advice. For me there are no short-cuts to this. Look at your program, the evidence is there: you've been through it multiple times, twitching it here, bodging it there. You've taken a "short cut" and wasted so much time in doing so and it still doesn't work.
If you don't sort your method out, then you'll be no good at writing code (any sort) for anyone else, only for yourself, because you'll put up with your limitations.
This may not count as what you want to hear, but you have to sort it out, otherwise you'll keep making basic errors and blaming it on the new instructions you are trying to master (first it was the BC, then the "logic", but all the time just dumb, no other way to say it, errors). It is enormously important in programming to recognise that when something doesn't work, it is because you have dome something (or some things) wrong. You, twice, looked at the wrong thing because you dind't realise how bad a mistake(s) you could make with plain programming.
My patience has its limit. I think you need a big improvement, even if you have to take a backward-step-or-two and invest your time differently, or I am out as well. We are not teachers per se. You can learn much, but you have to get your own basics working for yourself.
Please read this through several times. I'm trying to help by writing this, as it is the last-chance-saloon. If you do the same again, I'm keeping shtum.
Re: Payroll Positive Negative Zero Branch and Inputs
Posted:
Sun Nov 27, 2011 7:05 am
by RISCCISCInstSet
Okay so apparently I was falling through. This seems to solve my problem.
I think I forgot a rule: do not post beginner questions where advanced questions are expected.
@BillyBoyo Would this question and its like be more appropriate in "Stupid Questions"?
Re: Payroll Positive Negative Zero Branch and Inputs
Posted:
Sun Nov 27, 2011 7:18 am
by RISCCISCInstSet
Another thing: I shouldn't have had those comments in front of the branch lines there.
Re: Payroll Positive Negative Zero Branch and Inputs
Posted:
Sun Nov 27, 2011 8:20 am
by steve-myers
We're not really here to debug your programs.
One thing you have to remember is Assembler is not a block structured language like, for example, C. In other words, something like this:
if (test) then
something
else
something
You have to expand the blocks. e.g.
CLC ...,... Perform test
BC 7,ELSE Br if test failed
* CODE FOR EQUAL TEST
BC 15,EXITIF
* CODE FOR NOT EQUAL TEST
ELSE ...
EXITIF ...