Converting fields from lower case to upper case

asagar · New User Joined: 11 Jul 2012 Posts: 10 Location: Honduras

I am writing a sanity check program, which requires converting some fields from lower case to upper case. I understand that using the 'Inspect' verb is an option, are there any other ways of doing this too ?

Robert Sample · Posted: Tue Sep 18, 2012 7:50 pm

Enterprise COBOL supports the intrinsic function UPPER-CASE.

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

You're right, that is an option.

Another one is to use the Enterprise COBOL intrinsic function called "Upper-Case". It goes something like this:

Compute ws-upper = FUNCTION UPPER-CASE(ws-lower)

dbzTHEdinosauer · Posted: Tue Sep 18, 2012 7:52 pm

Funtion UPPER-CASE

don.leahy · Posted: Tue Sep 18, 2012 7:59 pm

Hint: check out the list of Intrinsic functions in the Cobol Language Reference.

Bill Woodger · Posted: Tue Sep 18, 2012 8:18 pm

Yes, there are other ways. I feel somewhat "beaten" on the obvious suggestion :-)

What do you mean by a "sanity check program", just out of interest, and how does this relate to it?

Bill O'Boyle · Posted: Tue Sep 18, 2012 8:39 pm

I'm partial to the INSPECT CONVERTING with literals. The compiler generates an in-line TR instruction, whereas, with the FUNCTION's, the compiler generates a BALR to a run-time routine. FUNCTION's were not introduced until COBOL/370, about 20 years ago.

One thing I will say when using the INSPECT, I always coded the lower-case letters using hex-representation (IE: X'81' as opposed to 'a'), instead of taking the chance that someone (like me) brings the code up in CAPS ON mode and accidentally hits the line where the lower-case letters are coded and converts them to upper-case.

Bill O'Boyle · Posted: Tue Sep 18, 2012 10:14 pm

It would be great if COBOL had an MVZ-like command, where you can move 4-Bit zone 'C' values to the zone of each byte of an existing alphabetic string, which performs the upper-case change. Maximum length of the target string, from an Assembler point-of-view, is 256.

An "OC" (OR-character) like-command would work just as well using SPACES (B'11000001') as the mask, which would turn-on the second-bit (from the left), converting a lower-case 'a' (B'10000001') to an upper-case 'A' (B'11000001'). Again, maximum target-string length of 256.

When using either of these methods, the content of the string must be guaranteed to have only lower-case letters or "Unpredictable results may occur" and you know what that means.

As an exercise, try moving each byte to the low-order byte of a redefined halfword, PIC 9(04) COMP, (cleared to X'00's), add 64 to the halfword and move the halfword low-order byte back to the string. Same result, horrible overhead....

Bill O'Boyle · Posted: Tue Sep 18, 2012 10:32 pm

A correction to my previous post (must be "out of my mind" Tuesday), regarding the "OC", a SPACE is a B'01000000'.

Bill Woodger · Posted: Tue Sep 18, 2012 10:51 pm

Even redefine the field as several as-large-as-you-can binary and a last-one-to-make-up-the-length binary, then add specific values (I've not calculated them :-) ).

Again, only good-to-go if field exclusively contains lower-case letters. Even space would be garbled.

Similar is possible for ASCII/EBCDIC conversion, although there the space goes nicely.

Bill O'Boyle · Posted: Wed Sep 19, 2012 2:04 am

Bill,

Or, divide the length of the string by 4 and get a remainder. Then you could add a fullword of X'40404040' (1077952576) to 4-Bytes at a time in an in-line PERFORM. If the compiler doesn't support COMP-5, then TRUNC(BIN) must be specified.

After coming out of the PERFORM (if the length of the string was less than 4, then you would have never executed the PERFORM), check for a remainder from the divide and if found, take care of the last 1-3 bytes and you're done.

asagar · New User Joined: 11 Jul 2012 Posts: 10 Location: Honduras

I would use the COBOL intrinsic function UPPER-CASE.

Thank you so much for your replies.

Bill Woodger · Posted: Wed Sep 19, 2012 3:55 pm

Did you read Bill's first reply? If you have lots to do, it would be worth doing a comparison.

If not many, the FUNCTION approach is easier to understand.

Perhaps for a "sanity check" you should have chosen one of the tortuous solutions :-)

Bill O'Boyle · Posted: Wed Sep 19, 2012 6:37 pm

Bill,

Jim Moore (a programmer's programmer) would agree and also go with the INSPECT with LITERALS.

Regards,

Michael Simpson · New User Joined: 27 Sep 2012 Posts: 6 Location: Sweden

what about special characters in all your solutions (I'm thinking of Swedish åäö to ÅÄÖ).

Not being at work, I seem to remember that the upper-case won't work with these characters. (Maybe you can use the special-names clause to get it to work ???)

Bill Woodger · Posted: Sat Sep 29, 2012 3:32 pm

Michael,

Welcome to the forum.

Whether it can be considered a major oversight or not, I suspect that the vast majority of systems outside Scandanavia pay little heed to Scandanavian characters.

Having said that, the INSPECT ... CONVERTING with literals in hex (X'...'), suggested by the other Bill, would be applicable to any single byte value. For a multi-byte value, INSPECT ... REPLACING could be suitable.

Michael Simpson · New User Joined: 27 Sep 2012 Posts: 6 Location: Sweden

I agree with the scandinavian comment.

My point was more that this is probably just as relevant with special french, spanish, german etc characters sets as well