LEFT ALIGN 3

[SiouxCityElvis]

Okay. This has bothered me off and on several times.

I'm on RMCOBOL-85 on Linux platform.

WORKING-STORAGE.

01 WS-1 PIC 9(8)V9(2).
01 WS-NBR-RFMT PIC ZZZZZZ99.99.

01 WS-DISPLAY-FIELD PIC X(10) JUST.


PROCEDURE.

MOVE WS-1 TO WS-NBR-RFMT.
MOVE WS-NBR-RFMT TO WS-DISPLAY FIELD.
DISPLAY "number field: " WS-DISPLAY-FIELD.

and my field does not align left.
Basically, I've come up with a display that shows

number field: 99.98

when I want it to come up as

number field: 99.98

so no matter what my field value is for the number 99.98 or 1234567.98 it will left align(trim the leading spaces) and show next to the number field: part.

How do I accomplish this short form. The last time I accomplished my goal on this it took all this INSPECT garbage to get the proper display.
Is there not a simple alignment technique in this legacy language?
I've check the manuals, and they preach all this stuff about JUST, or JUSTIFIED and I tried JUST and JUSTIFIED LEFT and don't get results.
Thanks.
-David

 

[3gm]

JUSTIFIED takes the field and justifies it RIGHT on the basis of its defined length, NOT based on its contents. I've found very few cases where JUSTIFIED is useful.

What you want to do requires more complex code, e.g.:

     move ws-1                    to ws-nbr-rfmt
     move +1                      to ws-length
     inspect ws-nbr-rfmt tallying ws-length
         for leading spaces
     move ws-nbr-rfmt(ws-length:) to ws-display-field

Regards.

Glenn

 

[k5tm]

For RM/COBOL:

DISPLAY "number field: " WS-1 CONVERT.

Tom Morrison

http://www.liant.com

 

[SiouxCityElvis]

Okay, Hopefully Tom's 1 line of code would do it.
Otherwise, I'm in awe that COBOL requires the extra code Glenn mentioned, which was the type of code I had used before.

I'll try this tomorrow.

Thanks for the help.
-David

 

[SiouxCityElvis]

Tom,

It worked just great by using your suggestion.
Now, why the heck is it so difficult for a fella like me to find this solution in the Manual? I searched the ALIGN, JUST, JUSTIFIED, etc. and it seemed I kept hitting a brick wall. Any suggestions for searching the manual? I seem to get poor results with the method I use to search the manual. Maybe I should just stop guessing what the word would be and asking for exact case match.

In this example maybe searching for "aligning left" would have worked.

Star to you.
Thanks for the help.
-David

 

[k5tm]

David,
[ul][li]DISPLAY and ACCEPT are the most abused verbs in COBOL. These two verbs, perhaps along with associated SCREEN SECTION stuff, have the most nonstandard decorations attached, not just in RM/COBOL, but in virtually all COBOL implementations. The reason for this, in my opinion, is that the mechanics of presentation have been so different in the various hardware/software environments.

All this is a prologue to my suggestion that you read everything both the Language Reference Manual and the User's Guide have to say about DISPLAY and ACCEPT.

[/li][li]Now, with regard to finding a solution in the manuals, consider the following analysis.

Your concern was with the presentation of data (on a display screen in this case). Somehow, though, you got focused on the internal representation of the data, rather than the presentation; JUSTIFIED deals with the internal representation of information in an alphanumeric data item, not its presentation. (PICTURE somewhat bridges the gap between internal representation and presentation, especially when you use the (alpha)numeric edit features.)

[/li][li]Conclusion: As you develop new code, consider separating as much as possible your data representation code from your presentation code and your business rules. If you have the discipline to separate these elements of your application at design time, you will find yourself producing code that is easier to understand and maintain now, and will be easier to modify when new presentation tools become available.[/li][/ul]

Tom Morrison

http://www.liant.com

 

[wahlers]

To: Tom Morrison.

Five stars for your conclusion!

Conclusion: As you develop new code, consider separating as much as possible your data representation code from your presentation code and your business rules. If you have the discipline to separate these elements of your application at design time, you will find yourself producing code that is easier to understand and maintain now, and will be easier to modify when new presentation tools become available.

Of course your conclusion should be standard practices for all serious programmers. Having said this I am amazed to see that all too often this is not(!) standard practices.
The only addition I like to make is to avoid user extensions all together (where possible, of course!).


Regards, Wim.