non-printable characters

[howdie007]

I have a sequential file that contains a wide variety of non-printable characters. I need to convert these to spaces. How can i do this in a cobol2 program running on zOS/390 mainframe.
The valid ASCII hex values are x'20' thru x'7E'. Hence, we need to convert x'00' thru x'1F' & x'7F' thru x'FF' to spaces.

Any ideas are appreciated. Thank you.

 

[webrabbit]

INSPECT ... CONVERTING, or if COBOL2 has it, TRANSFORM should do the trick. Otherwise, do the following:

Perform Varying I from 1 by 1 Until I > Length of INPUT-RECORD
    If INPUT-RECORD(I:1) < Space or > '~'
        Move Space to INPUT-RECORD(I:1)
    End-If
End-Perform

 

[k5tm]

Use INSPECT ... CONVERTING along with hexadecimal notation for alphanumeric literals. For example (not a complete solution):

INSPECT record-area 
    CONVERTING X"000102030405060708090a0b0c0d0e0f"
            TO SPACES.

The other code points are left as an exercise.

Tom Morrison

http://www.liant.com

 

[ceh4702]

Well you could build a table of all the values you want to convert and then just search the table and when you find a match you change the value to a space. Or you might try a class test. If xyz not alpha numeric move ' ' to xyx. There are probably lots of ways to work on this.

If you do not like my post feel free to point out your opinion or my errors.

 

[slade]

I think the INSPECT solution will prove to be the best performer in Howdie's environment (zOS/390) because it only uses a single TR Assembler instruction, provided he uses a literal and not a variable to contain the from/to values.

Using the variable will result in about 4 to 5 Assembler insructions ending in a call to a COBOL subroutine.

However, I'm wondering if COBOL can accommodate a literal big enough to accept x'00' thru x'1F' & x'7F' thru x'FF'.

Regards, Jack.

"A problem well stated is a problem half solved" -- Charles F. Kettering

 

[k5tm]

Jack,

Of course it can! You need to read up on continuation of alphanumeric literals (the bane of COBOL compiler developers -- well one of the various banes at least).

According to the IBM Enterprise COBOL LRM (page 46) hexadecimal literals may be continued.

Tom Morrison

http://www.liant.com

 

[ceh4702]

We print on a high speed band type mainframe printer and if you use the fastest band with the fewest letters in all caps, then it just refuses to print the other characters. i.e. they all come out as spaces.

So can you get all those unprintable characters with some kind of class statement?

if not alpanumeric ......

If you do not like my post feel free to point out your opinion or my errors.

 

[slade]

Tom,

I know how to continue a literal. The question is how large a literal can the intruction handle. This is connected to another ques: why does the compiler use a subroutine when a variable is used.

It sounds like the compiler has enough info about the variable to build a TR instruction with the address of the variable. Instead, it calls a sub ????

Regards, Jack.

"A problem well stated is a problem half solved" -- Charles F. Kettering

 

[PHV]

So, again, in the mainframe environment no simple utility like the tr unix command ?

 

[k5tm]

Jack,

Wasn't intending to insult your intelligence.

The TR instruction, IIRC, has a 256 octet translation table.

In general the compiler must generate a subroutine call when a variable is used because the contents of the translation table are not known at compile time. Now an optimizing compiler can determine to some extent if it really does know everything it needs to know at compile time to generate the table as a literal, but then again, this might not rise to the level of importance to get that much attention. Optimizations that start making these types of assumptions have a propensity to make a wrong decision, and maybe that risk just wasn't worth it for this optimization.

Of course this thread may have consumed more computing resources than the optimization would over years.

Tom Morrison

http://www.liant.com

 

[slade]

Tom,

I'm familiar w/the IBM COBOL environment and suspected the length limit for a literal would be 255 or 256, but when I didn't find any mention of a limit in the manual I thought something else might be going on.

I also assumed that the compiler could determine the size of a variable and use the TR instr when the length of the variable was below the limit or else use a sub.

I'm probably missing something here. Where am I going wrong?

Regards, Jack.

"A problem well stated is a problem half solved" -- Charles F. Kettering

 

[3gm]

COBOL literals in the 1985 standard are limited to 160 bytes.

None of the IBM COBOL manuals I've looked at show an extension that allows longer ones.

Regards,

Glenn

 

[slade]

Hi Glenn,

The link below lists the eCOBOL limits. I didn't see anything under the order of 16Meg that applies to this problem.

But then, I may be misreading something. Some of the entries seem contradictory.



Regards, Jack.

"A problem well stated is a problem half solved" -- Charles F. Kettering

 

[3gm]

Jack -

I believe you forgot to include your link. I think the standard limitation on literals applies unless there is SPECIFIC wording in the reference manual to the contrary.

To quote from the Enterprise COBOL for z/OS Language Reference Version 3 Release 4 manual:

The maximum length of an alphanumeric literal is 160 bytes. The minimum length is 1 byte.

Glenn

 

[slade]

Ah, those senior moments!

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR10/APPENDIX1.2?DT=20020920180651

Regards, Jack.

"A problem well stated is a problem half solved" -- Charles F. Kettering