IBM Mainframe Forum

We do not do homework.

Your conversion factor is close, but not 100% accurate, though it's more accurate than what I use for a rough estimate: multiply km/hr by 5/8. Since you say you do not have to be accurate I guess it's close enough. Any time you have fractions and want to do fractional arithmetic with fixed point arithmetic you have problems. How do you handle this issue in C? You follow the same procedure in Assembler.

After you do the multiply you most likely divide the result by 1000, though, of course, you can handle this issue in the output format. There are two ways to do this: the Divide Decimal (DP) instruction, or the Shift and Round (SRP) instruction to shift the number 3 digits to the right since you are dividing by 1000. Both instructions present problems: DP because you have to allow for a remainder, and SRP because the method to specify a right shift isn't very clear in Principles of Operation.

Unfortunately Principles of Operation isn't very helpful in telling you how to specify a right shift in SRP, so I will tell you a simple way: specify 64-n in the shift amount field in the instruction, where n is the number of digits to shift.

For what it's worth, WTO xxx, where xxx is the name of a storage area will not work, for two reasons. First, while you can specify a storage area, you specify it differently. Second, the storage area must be formatted very precisely. Look at how the storage area in something like WTO 'message text' is formatted, and you'll have the idea.

Basic WTO macro with included text. Lines that start with a + are the macro expansion.The BAL instruction stores the address of the message buffer into register 1.

WTO macro specifying remote text.The first DC defines the length of the message buffer, and includes the length of this prefix. The second DC defines 2 bytes of binary 0s. The third DC defines the message text.

Formatting output is one of the more difficult tasks of an Assembler programmer. Sadly, there are no IBM provided general purpose tools for this task. It's probably too complex!

Hello,

Learning to me comes when I can remove the stress of the due date of this assignment than I can fully concentrate, which I can do when I look at a solution.

Unfortunately, that is not learning, but rather coasting. . . Deadlines are a basic part of our profession.

As mentioned, wo don't do homework, but will work with you to make progress.

As this was started more than 10 days, more effort on your part would possibably (probably) have reduced the stress level. Ift is somewhat a guarantee that if you are not persistent in trying things, no one here is going to push you.

New problem should be a new topic.

Learning to me comes when I can remove the stress of the due date of this assignment than I can fully concentrate, which I can do when I look at a solution.

I've been there myself when I started, but, as Mr. scherrer says, you learn more by doing something, and doing it wrong and starting over. I learned some 7040 Assembler by reviewing the "Assembler" code the 7040 Fortran compiler wrote, but I really learned it by writing programs or Assembler subroutines. Sometimes you learn by reading over your programs and deciding how to do it better.

This is what I have so far on the Prime number program. It prints out 444444 and abends.

And the logical error I need help in fixing comes from:



So, BNL branches to PRIME if the condition code is not low. If it is low, we fall through the branch and end up at PRIME. In other words, no matter what happens we're always going to go to PRIME.

I need help in fixing this logical error. I thought of of replacing BNL Prime with BNH Prime, BL Prime, etc.

does it occur to You that after the branch and before the PRIME label there should be the instructions to process the <other> case ?

it looks like You are doing some patchwork and not programming.
for a beginners before starting writing code it would be wiser to write the pseudo code ( express in plain words the program logic flow )

I have a program where we need to convert (have not learned user input) miles/hr to km/hr in assembly.

THe program runs, but it looks wrong. Can someone explain to me how to fix it and what is wrong? Thanks

enrico-sorichetti wrote:

Select all

                      BNL  PRIME
 
PRIME  EQU  *

does it occur to You that after the branch and before the PRIME label there should be the instructions to process the <other> case ?

it looks like You are doing some patchwork and not programming.
for a beginners before starting writing code it would be wiser to write the pseudo code ( express in plain words the program logic flow )

OK, so then, I would add a statement just below BNL PRIME that says: BL PRIMECHECK

That would be it?

/repeat on
before starting writing code write the pseudo code ( express in plain words the program logic flow )

if the BNL will get You out of the <loop>

why not use a BL to branch to the beginning of the loop
and fall thru in the other case ( BNL )