IBM Mainframe Forum

I have to admit I had not realized the TAB DSECT is larger than the storage assigned to it as Mr. Sample noted. Pintu1228 will have to correct that problem, as well as alter BUILD, CMPUTE and the yet to be written PRINT to correctly update the table pointer. Pintu1228 has to update CMPUTE to update the table pointer, which is not being done.

Mistakes like this are all to easy to make. One way to avoid them is to code like this -32CL(TABSIZE) is safer than CL(TABSIZE*32) since the maximum value for a length used in a DC is 255.

Additional comments:
1. You are converting the quantity wrong -- your CARD defines it as 3 bytes yet you convert 4 bytes, so the quantity is 10 times the amount it should be (plus the first digit of the date).
2. Whether or not you calculate shipping charges correctly cannot be determined because you add the shipping charge to the total in line 124, no matter what you calculated the shipping charge to be.
3. Given these mistakes, you are calculating the total correctly for the first table entry (472 * 650 = 306800 + 500 - 000 = 307300, which is the total for the first table entry).
4. If you read the Assist output, you can discover that the reason for the ABEND is that Assist executed 2,000,000 instructions. This should be a clue to you that perhaps you have an infinite loop since there should be no reason for your code to execute 2,000,000 instructions.

Mr. Sample's observation about the length value in the conversion in statement 72, offset +0406 is correct. In general, you are better off allowing the Assembler to fill in a length unless it's wrong. For example -
This, of course, is classic code to store blanks in an area. The default length in MVC AREA+1,AREA is the length of AREA, and would result in the byte after AREA being damaged. Another example -
This is the classic method to convert binary data in SOURCE to printable characters in TARGET. I will leave it to you to deduce how it works

Thanks for the helpful hints.

So the reason I have declared the lengths is the professor wants us to learn this way.

As far as the total for dsect I have made a mistake from the sheet, now it adds to 32

Regarding the updates I have made to this program below, why do I get an error at ZAP $TSHIP(4),NOSHP(1).

I am trying to load the value of NOSHP (defined as 0 in storage) into the dsect TSHIP that way on the next PRINT SUBROUTINE I can print all lines into a table type format.

Thanks

You have to read all the messages.

PSW AT ABEND FFC50000 C0000516 COMPLETION CODE ASSIST = 221 INSTRUCTION LIMIT EXCEEDED

There is nothing "wrong" with the instruction; it just happens to be where instruction limit count came up.

You were told this before, but you have done nothing to correct this. You still have not altered BUILD so it will stop if it is about to overflow the table. In my opinion, you want to fix the issues in BUILD and CMPUTE before you start working on PRINT. In terms of lines of code, PRINT will be bigger than everything you've done so far. In my opinion, preparing properly formatted output as is true of this assignment in some of the more onerous tasks of an Assembler programmer.

Well, have a nice weekend.

pintu1228 wrote:... So the reason I have declared the lengths is the professor wants us to learn this way. ...

At one level, I agree with your professor's goal, but I think it's unnecessary, on the theory anything you type is a potential mistake.

Another issue I noticed is you are using the BC instruction and coding the condition masks, and you're coding the condition masks as bit constants. I approve of using the bit constant. The trouble is many of us dinosaur greybeards have literally forgotten the condition codes set and how they relate to the condition masks. One thing I notIced - more in passing, rather than looking for anything wrong - is you have a CP/BC B'0101' in at least one place. This got me to thinking, "I don't think CP ever sets condition code B'11', so why specify B'---1' in the BC, as it will never come up?" I then dusted off a Principles of Operation, found the description of CP, and yes, CP does not set condition code B'11'.

Thanks for the clarification...As for the PRINT subroutine how do I print the table and title (sales report)?

Do I have to declare anything in storage to make it print Customer ID, Product ID, etc?


I have figured out the Compute subroutine and it works fine

i HAVE DONE THIS (SEE FILE) BUT i GET ADDRESSIBILITY ERROR, CAN SOMEONE HELP ME FIX THIS?


THANKS

pintu1228 wrote:... As for the PRINT subroutine how do I print the table and title (sales report)?

Do I have to declare anything in storage to make it print Customer ID, Product ID, etc?

Usually, yes. Many programmers prepare a skeleton output line, starting like this -
The blank after PRCID and PRPID inserts a blank. You'll find you often need more than one blank.

pintu1228 wrote:...I have figured out the Compute subroutine and it works fine

Actually, not. It's obviously not processing the first table entry.

Other errors -

PRINT DSECT ?!!

Addressability - Look how you set up your addressability and you should see the problem straight off.

Ok I updated that file since, can you show me if there is any problem with print and what code I have to put in to fix it?


Thanks, you been a great help