IBM Mainframe Forum

PRINT DSECT ?!! You still have not fixed this!


The prototype data obviously contains more than 6 characters! The assembler will just process the first 6.

I just picked one example. You'll have to do the remainder.

Lot's of problems.

• The prototype edit mask obviously has more than 6 characters. You need to define a large enough output area.
• You need to specify one digit select character (X'20' or X'21') for each digit in the packed decimal number you're editing. Your complete prototype edit mask just has 6 digit select characters. $TTOTAL, on the other hand, has 9 digits.
• Except for very simple cases, I quit using literals for an edit mask. They are too hard to examine, and it is too easy to make a mistake.
• The X'21' digit select does not immediately insert a 0; it starts with the next character.

This is what I do.
I first define what I want the output to look like as a 0C'...' data area. This is more for documentation and to define a length. Then I construct the edit mask. When I want to specify a real character, I break the digit selects and insert the character using C'character'. Now I do not want to claim I never make a mistake here, but it's usually easier to find and correct the goof than when you use a literal.

This is what the professor said regarding PRINT: move the math code inside of your table loop code.....the table loop code is not doing any processing the way you have it.

I don't quite get what he is saying. I have my math in the PLOOP

The only proper loop in CMPUTE is

I think there is valid code elsewhere in CMPUTE that you want to move to just after the BC.


You're thinking something like C here. That's OK, but an Assembler programmer thinks differently. When faced with
An Assembler programmer will usually write the equivalent of
The statement that's always executed is the quickest of the two options. If the two statements really are mutually exclusive, an Assembler programmer will write what you did, though we try to avoid it

pintu1228 - You might want to share this with your professor. I'd be interested in his reaction.

<rant mode on>
Long Assembler literals as edit masks

For almost 50 years code like this -
has been accepted practice in our industry. Books have taught this. Assembler language instructors have tolerated this. For almost 50 years no one has clearly stated this is a poor practice, for multiple reasons.

• These long literals are difficult to analyze, especially if there is a mistake in the literal.
• The analyst or programmer must either memorize or look up the hexadecimal codes for a blank character, a comma (,) character, and a period (.) character or other characters that are in the mask.
• The relationship between the target area and the edit mask was very poor. If there was a mistake it was difficult to analyze, and some times difficult to even detect.

About the only advantage to this method is the edit mask was defined with its use.

I propose a practice more like this.
There are a number of advantages to this.

• The 0C' N,NNN,NNN.NN' clearly shows the intent of the edit mask.
• The 0C' N,NNN,NNN.NN' clearly defines the actual length of the actual output area.
• The Assembler converts characters to their hexadecimal equivalent, which, by definition, it can do perfectly.

Now I will not claim this method is perfect. There is no convenient method to cross check the proposed edit mask in 0C' N,NNN,NNN.NN' with the actual edit mask that follows, and switching between character data and the hexadecimal digit select codes is somewhat error prone, though at least the Assembler catches the goofs. And, as was implied earlier, the edit mask is separated from its use.
<rant mode off>

So do I need to my my valid if statement inside the bc call to fix the print then?

I think the IF you proposed belongs in CMPUTE. There may be something similar in PRINT. That needs to be determined.

What exactly am I fixing in PRINT DSECT???

There is quite a bit to fix in PRINT.
1. You defined PRINT as a DSECT so you got an unresolved external reference when attempting to define the V-type address.
2. In line 185 you move 5 characters of the edit mask literal to a 3-character field. I don't think the ED instruction will work properly in such a case.
3. You move $TNUM and $TDATE directly to the print line. Since both variables are defined as packed, I suspect you won't be seeing much printable data from such a command.
4. You move 5 bytes for the date -- ok for packed but not so good for printable data.
5. Your moves in lines 191, 194, 197 suffer the same flaw mentioned in #2 above -- the receiving field is shorter than the sending field.
6. You are not inserting the currency signs on the print line fields.
7. Your assignment indicates you should have a report header which is not in your code.
8. Your assignment indicates you should double-space the report which is not in your code.
9. Your assignment indicates you should have summary data at the end of the report which is not in your code.

Thanks but before I move on to Print, can you help me with my compute logic. Does the logic I have do everything I need?

I am confused on this assignment, whereas previous ones I finished and do well.

Thanks

Have you changed the loop in CMPUTE to actually do anything? You haven't posted any Assist output if so, so it isn't possible to say if your CMPUTE is now correct or not.