COBOL NON PRINTABLE CHARACTERS

srinut123 · New User Joined: 11 Oct 2005 Posts: 62 Location: India

Hi
Requirement: I've to replace all non printable characters with spaces.

Can any one help?
Thanks
SRK

Robert Sample · Posted: Thu Nov 26, 2009 3:48 pm

Use reference modification to look at each character; if it is a "non printable character" (whatever that means to you), change it. The process will run slow since you're looking at every byte, but it's very standard code. There are examples of very similar code on the forum already.

Ronald Burr · Posted: Thu Nov 26, 2009 11:42 pm

I have done this on many occasions by coding two 256-byte working storage elements - the first containing All of the 256 possible byte values ( x'00' thru x'FF' ), and the second containing the same, except for replacing each "non-printable" position with x'40' - and then using the INSPECT source-field CONVERTING source-values TO target-values. The execution is very fast if the source-field is less than 257 bytes - slower if greater than 256 since it requires looping under the covers. Here's the code:

dick scherrer · Posted: Fri Nov 27, 2009 3:01 am

Hello,

Another way to do this is to use the input value as the displacement into the "target array" and simply "move" the target value to the output byte. It would require a loop to process the input string.

This may (or may not) use less cpu cycles than the inspect. It has been too long since i did any timing testing on something like this for me to say positively.

Bill O'Boyle · Posted: Fri Nov 27, 2009 8:45 am

A pre-defined translate-table is often defined in a shop, which contains all 256-byte values and can be accessed from both Batch and CICS. This table is Assembled and Linked as if it were a plain-jane Batch Assembler program. It would be incorrect to run this through the CICS translator and then Assembling/Linking it as a CICS/Assembler program -

srinut123 · New User Joined: 11 Oct 2005 Posts: 62 Location: India

Many Thanks for your inputs.

essence21 · New User Joined: 05 Dec 2008 Posts: 20 Location: mumbai

Ronald , i tried ur method but while compilation it gives below error:
Can you please help out?

IGYPA3097-S
IDENTIFIER "WS-SOURCE (GROUP)" WAS NEITHER AN ELEMENTARY ITEM WITH "USAGE DISPLAY", "USAGE DISPLAY-1" OR "USAGE NATIONAL" NOR AN ALPHANUMERIC OR NATIONAL FUNCTION. THE STATEMENT WAS DISCARDED.

IGYPA3097-S
IDENTIFIER "WS-TARGET (GROUP)" WAS NEITHER AN ELEMENTARY ITEM WITH "USAGE DISPLAY", "USAGE DISPLAY-1" OR "USAGE NATIONAL" NOR AN ALPHANUMERIC OR NATIONAL FUNCTION. THE STATEMENT WAS DISCARDED.

enrico-sorichetti · Posted: Wed Oct 06, 2010 6:10 pm

nobody can help You out because...
You did not use the code posted as is,
You did not post the code used !

essence21 · New User Joined: 05 Dec 2008 Posts: 20 Location: mumbai

here's the code used

dick scherrer · Posted: Wed Oct 06, 2010 7:11 pm

Hello,

Which compiler is being used?

This is printed at the top of a compilation.

essence21 · New User Joined: 05 Dec 2008 Posts: 20 Location: mumbai

Not sure if this is it...

1PP 5655-S71 IBM ENTERPRISE COBOL FOR Z/OS 4.1.0 CS12

Bill O'Boyle · Posted: Wed Oct 06, 2010 7:57 pm

essence21 · New User Joined: 05 Dec 2008 Posts: 20 Location: mumbai

Apparently something is going wrong somewhere by me and i am not able to spot it

Bill O'Boyle · Posted: Wed Oct 06, 2010 8:35 pm

Note that (based upon your posted code), the WS-TARGET 01-Level does not have a delineating period, which should raise an "E" level error during compilation.

Otherwise, everything else looks fine....

Bill

essence21 · New User Joined: 05 Dec 2008 Posts: 20 Location: mumbai

Nope .. Just put in a period and tried again.. No luck...

dbzTHEdinosauer · Posted: Wed Oct 06, 2010 9:42 pm

from the compiler output,
what does the OPTIONS page look like.
(cut&paste, please).

essence21 · New User Joined: 05 Dec 2008 Posts: 20 Location: mumbai

I hope you mean this:

OPTIONS IN EFFECT:
NOADATA
ADV
APOST
ARITH(COMPAT)
NOAWO
BUFSIZE(16384)
NOCICS
CODEPAGE(1146)
NOCOMPILE(S)
NOCURRENCY
DATA(31)
NODATEPROC
NODBCS
NODECK
NODIAGTRUNC
NODLL
NODUMP
NODYNAM
NOEXIT
NOEXPORTALL
NOFASTSRT
FLAG(I,E)
NOFLAGSTD
INTDATE(ANSI)
LANGUAGE(UE)
LIB
LINECOUNT(60)
LIST
MAP
NOMDECK
NONAME
NSYMBOL(DBCS)
NONUMBER
NUMPROC(NOPFD)
OBJECT
NOOFFSET
NOOPTIMIZE
OUTDD(SYSOUT)
PGMNAME(COMPAT) TEST(NOHOOK,SEPARATE,NOEJPD)
NOTHREAD
TRUNC(OPT)
NOVBREF
WORD(TBL1)
XMLPARSE(XMLSS)
XREF(FULL)
YEARWINDOW(1900)
ZWB
RENT
RMODE(AUTO)
NOSEQUENCE
SIZE(MAX)
SOURCE
SPACE(1)
NOSQL
SQLCCSID
NOSSRANGE
NOTERM
TEST(NOHOOK,SEPARATE,NOEJPD)

dbzTHEdinosauer · Posted: Wed Oct 06, 2010 10:49 pm

do the errors reference the INSPECT statement?

Ronald Burr · Posted: Thu Oct 07, 2010 12:53 am

Sorry about that. I "wrote" the code by memory rather than by cut/paste.
The SOURCE-VALUES and TARGET-VALUES data items MUST be elementary items - not group items (as was the case in my first code example ). The code should be corrected to mirror this example (note the lines that redefine the source/target values).

dbzTHEdinosauer · Posted: Thu Oct 07, 2010 1:17 am

Ronald Burr,

thanks for the clarification. I spent some time going thru the manual and
missed the part that identifier-6 & 7 had to be elementary items.

Bill O'Boyle · Posted: Thu Oct 07, 2010 1:34 am

Ronald Burr · Posted: Thu Oct 07, 2010 2:45 am

acevedo · Active User Joined: 11 May 2005 Posts: 344 Location: Spain

ooops... I had posted the same as Ronald Burr about the redefines... I hadn't read the 2 page.

essence21 · New User Joined: 05 Dec 2008 Posts: 20 Location: mumbai

Thanks All,

Its working perfectly now.

I feel the issue was cropping up due to 03 level defined under 05.. i now modified to 01 --> 03 --> 05.. And its working ok.

Thank you for your help...

Just one more thing i was wondering what be the CPU usage if this is inserted into a scheduler which runs 1 minute frequency and the field is PIC X(967)

Ronald Burr · Posted: Thu Oct 07, 2010 5:55 pm

An INSPECT...CONVERTING statement in COBOL results in assembler TRANSLATE instructions, which are very, very fast - especially when compared to any other method of performing the same task. The Principles of Operation Manual describes the TRANSLATE instruction thusly:

"The bytes of the first operand are selected one by one for translation, proceeding left to right. Each argument byte is added to the initial second operand address. The addition is performed following the rules for address arithmetic, with the argument byte treated as an eight-bit unsigned binary integer and extended with zeros on the left. The sum is used as the address of the function byte, which then replaces the original argument byte."

Since your source field is more than 256 bytes ( the limit for a single TRANSLATE instruction ), and of a FIXED length, I'm "assuming" that the compiler will simply generate FOUR such TRANSLATE instructions ( three of 256 bytes each, and one for the remainder (199 bytes)) in order to convert the entire field.

If the field were of a VARIABLE length, the underlying code would have to contain a "loop" to perform zero or more 256-byte TRANSLATEs, followed by one for the remainder ( when it becomes less than 256 bytes ). Though somewhat less efficient than when dealing with FIXED length fields, it would still be the fastest method available to accomplish the task.