IBM Mainframe Forum

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.

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 ... c500428f9a
will 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

These users thanked the author enrico-sorichetti for the post:

RISCCISCInstSet (Mon Nov 12, 2012 4:55 am)

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.

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?

These users thanked the author Robert Sample for the post:

RISCCISCInstSet (Mon Nov 12, 2012 4:55 am)

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".

These users thanked the author BillyBoyo for the post:

RISCCISCInstSet (Mon Nov 12, 2012 4:55 am)

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.

These users thanked the author BillyBoyo for the post:

RISCCISCInstSet (Mon Nov 12, 2012 4:55 am)

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"?

Another thing: I shouldn't have had those comments in front of the branch lines there.

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:You have to expand the blocks. e.g.

These users thanked the author steve-myers for the post:

RISCCISCInstSet (Mon Nov 12, 2012 4:55 am)

(message blanked)