Question on IBM Enterprise COBOL INSPECT..REPLACING

[Arnold Trembley]

If I need to change all the trailing spaces in a PIC X field to nulls
(LOW-VALUES), I would like to be able to code it this way:

05 destination-field PIC X(100) VALUE SPACES.

MOVE "This is a null-terminated string" TO destination-field

INSPECT destination-field REPLACING TRAILING SPACES BY LOW-VALUES.

But when I look in the IBM Enterprise COBOL manual for z/OS, there is no
TRAILING option for INSPECT..REPLACING. I'm not in the office today to
try compiling this. Does this work in IBM Enterprise COBOL for z/OS?

Does the COBOL standard say INSPECT..REPLACING can be coded this way?


--
http://www.arnoldtrembley.com/

[Kerry Liles]

I don't see "TRAILING" in the specification in VSE COBOL...

You may be able to do something like this:

MOVE "This*is*a*null-terminated*string" TO destination-field
INSPECT destination-field replacing all ' ' by low-values
INSPECT destination-field replacing all '*' by ' '

[Arnold Trembley]

Thanks for the response. I hadn't thought of that way, but it should
work fine. Of course, I could always code a loop to replace trailing
spaces one by one until no more spaces.

It will be a few days before I'm back in the office to try compiling
this with zOS COBOL. This question came up in the discussion groups for
GnuCOBOL.

I just verified with a simple test that GnuCOBOL 1.1 in Windows 7
supports REPLACING TRAILING SPACES BY LOW-VALUES, in default, IBM, and
MVS syntax configurations.


--
http://www.arnoldtrembley.com/

[Kerry Liles]

Right. There are several ways to accomplish what you wanted to do of
course, some uglier than others. I have always wondered why LEADING was
of interest yet TRAILING was not... :)

[Charles Hottel]

"Kerry Liles" <kerry...@outlook.com> wrote in message
news:mtuqca$b90$1...@dont-email.me...

Instead of fooling around with the '*' to keep the embedded spaces you could
do it this way:

MOVE FUNCTION REVERSE ("This is a null-terminated string ") TO
work-field
INSPECT work-field REPLACING LEADING SPACES BY LOW-VALUES
MOVE FUNCTION REVERSE (work-field) TO destination-field

[Arnold Trembley]

On 9/24/2015 2:35 AM, Charles Hottel wrote:
> "Kerry Liles" <kerry...@outlook.com> wrote in message
> news:mtuqca$b90$1...@dont-email.me...

>> (SNIP)

>> I don't see "TRAILING" in the specification in VSE COBOL...
>>
>> You may be able to do something like this:
>>
>> MOVE "This*is*a*null-terminated*string" TO destination-field
>> INSPECT destination-field replacing all ' ' by low-values
>> INSPECT destination-field replacing all '*' by ' '
>
> Instead of fooling around with the '*' to keep the embedded spaces you could
> do it this way:
>
> MOVE FUNCTION REVERSE ("This is a null-terminated string ") TO
> work-field
> INSPECT work-field REPLACING LEADING SPACES BY LOW-VALUES
> MOVE FUNCTION REVERSE (work-field) TO destination-field
>
>

That would work too. Most of the programmers in my shop have no idea
that "FUNCTION REVERSE" even exists.

Based on the the discussion in the GnuCOBOL sourceforge pages, it seems
that the TRAILING option was an AccuCOBOL extension that GnuCOBOL
adopted. So it probably doesn't work in IBM Enterprise COBOL.



--
http://www.arnoldtrembley.com/

[Clark F Morris]

The COBOL 2014 Standard
http://www.open-std.org/jtc1/sc22/open/ISO-IECJTC1-SC22_N4561_ISO_IEC_FCD_1989__Information_technol.pdf
is now out. If you are at an installation using COBOL you might want
to take a look at it (it's an update of the 1989 standard). Review
and submit requirements for those parts of the standard your
organization can use. As someone who used to The new things include
ALLOCATE (IBM z series Getmain) and FREE (IBM z series Freemain).
Still no INSPECT ... REPLACING TRAILING. Would INSPECT FUNCTION
REVERSE work?

Clark Morris
>

[Pete Dashwood]

I have been too busy to come here for a while but when I read through this
thread I was really surprised that no-one suggested using function REVERSE.

Then I got to Charlie's post and he had suggested it. (Kudos Mr. Hottel...)

However, you don't need the two MOVEs that Charlie suggested; you can say
(as you were hoping, Clark):

inspect function REVERSE (myDataString)
replacing LEADING spaces with LOW-VALUES

It really is that easy.

I can't remember exactly who first posted that solution here (I think it was
Rick...) but it was definitely some years back.

I've been using it ever since.

Here's a 1 line solution for people who agree with me that the more code
there is, the more chance of there being errors...

Given that you have already set your NULL-terminated string into the work
field something like this:

MOVE ASCIIZ-STRING TO WORK-FIELD

you can transform the trailing blanks to nulls with a single line of Fujitsu
COBOL code:

MOVE LOW-VALUES TO WORK-FIELD ( FUNCTION STORED-CHAR-LENGTH (ASCIIZ-STRING)
+ 1: )

Sadly, the incredibly useful function STORED-CHAR-LENGTH is not implemented
in any other COBOL I have come across.

IF your COBOL REALLY tells you the true length of a stored string with the
LENGTH function, you could use that, but mostly they don't. LENGTH simply
returns the length defined in the picture of the field.

You COULD do this:

MOVE SPACES TO WORK-FIELD
MOVE ZERO TO MY-LENGTH
STRING ASCIIZ-STRING,
DELIMITED BY X'00',
X'00',
DELIMITED BY SIZE,
WITH POINTER MY-LENGTH,
INTO WORK-STRING
END-STRING

And then you get the one-liner...

MOVE LOW-VALUES TO WORK-FIELD ( MY-LENGTH + 1: )

If the work-string is long and the ASCIIZ strings are generally less than
half the length of it, then the above is more efficient thatn using function
REVERSE

In C# the entire operation is one line:

WorkField = Regex.Replace("(?<=\x00)\s|(?<=\s)\s\s","\x00"); // regular
expression converts whitespace after a hex 00 to hex 00

Pete.
--
"I used to write COBOL...now I can do anything."

[Joe]

This would probably work but comes accross as very costly as it twice
moves the data around (and has to use intermediate fields) and the
inspect statemens is as far as I know a very expensive one.

I would use a backward loop. More code but likely better performance.

MOVE LENGTH OF workfield TO count
PERFORM UNTIL
count < 1
OR workfield (count:1) NOT = SPACE
IF workfield (count:1) = SPACE
MOVE LOW-VALUES to workfield (count:1)
END-IF
SUBTRACT 1 FROM count
END-PERFORM

[Clark F Morris]

Better would be:

COMPUTE offset-field = LENGTH OF workfield - 1
PERFORM UNTIL
offset-field < 1
OR workfield (offset-field:1) NOT = SPACE
WITH TEST BEFORE
MOVE LOW-VALUES to workfield (offset-field:1)
SUBTRACT 1 FROM offset-field
END-PERFORM

Clark Morris

[Vince Coen]

<mtuqca$b90$1...@dont-email.me> <67ednbLaWcJUOp7L...@earthlink.com>
<9qydnUL_QKhgJp7L...@giganews.com>
<3o280b5pvq0avp8fd...@4ax.com> <d6isdi...@mid.indiv
Hello Pete!

Thursday September 24 2015 19:06, Pete Dashwood wrote to All:

> you can transform the trailing blanks to nulls with a single line of
> Fujitsu COBOL code:

> MOVE LOW-VALUES TO WORK-FIELD ( FUNCTION STORED-CHAR-LENGTH
> (ASCIIZ-STRING) + 1: )

> Sadly, the incredibly useful function STORED-CHAR-LENGTH is not
> implemented in any other COBOL I have come across.

Here is from the GNU Cobol manual (V2.0):

-------------------
6.16.76. STORED-CHAR-LENGTH

STORED-CHAR-LENGTH Function Syntax


STORED-CHAR-LENGTH(string)
~~~~~~~~~~~~~~~~~~
Returns the length -- in bytes -- of the specified "string" (a group item,
"USAGE DISPLAY" elementary item or alphanumeric literal), minus the total
number of trailing spaces, if any.
-------------------



Vince

[Pete Dashwood]

PERFORM... UNTIL is a useful construct but it requires great care when using
it.

I once had a bug that took me 3 days to find because of this. There were
some unusual conditions which meant it was never satisfied...sometimes. If
you let the PERFORM run your index that can't happen.

I agree your code will work (provided your platform implements LENGTH as the
actual length of the ASCIIZ string, without using an intrinsic function),
but I'd recode it like this:

MOVE LENGTH OF workfield TO count
PERFORM

VARYING count
FROM count
BY -1

UNTIL
count < 1
OR workfield (count:1) NOT = SPACE
IF workfield (count:1) = SPACE
MOVE LOW-VALUES to workfield (count:1)
END-IF

END-PERFORM

[Pete Dashwood]

Better in what way, Clark?

There are immediately 2 things I loathe about this:

1. PERFORM... UNTIL (Best avoided, in my opinion...)

2. WITH TEST BEFORE (A totally unnecessary construct that should never have
been added to the language and has been confusing programmers all over the
world for decades... :-)) If you want DO.. WHILE, write FORTRAN... )

It's just as well we all have our opinions.... :-)

[Pete Dashwood]

Ah, I should've known Brian and friends would be onto it... :-)

Good on them.

Now, if we could only get COM and OO I'd be switching to GNU...

Thanks for the heads-up, Vince.

[Clark F Morris]

I have a bug because I didn't decrement offset-field. WITH TEST
BEFORE is needed because the last character could be other than space.
An alternative would be to enclose the PERFORM in an IF Statement for
the last character.

Hopefully INSPECT FUNCTION REVERSED would generate about the same code
as the follow which should correct the bugs in my previous example or
even better.
PERFORM
VARYING offset-field from LENGTH OF workfield - 1 BY -1

UNTIL offset-field < 1
OR workfield (offset-field:1) NOT = SPACE
WITH TEST BEFORE
MOVE LOW-VALUES to workfield (offset-field:1)
SUBTRACT 1 FROM offset-field
END-PERFORM

Clark Morris
>
>Pete.

[Rick Smith]

On Thursday, September 24, 2015 at 2:06:44 PM UTC-4, Pete Dashwood wrote:

<snip>

> However, you don't need the two MOVEs that Charlie suggested; you can say
> (as you were hoping, Clark):
>
> inspect function REVERSE (myDataString)
> replacing LEADING spaces with LOW-VALUES
>
> It really is that easy.
>
> I can't remember exactly who first posted that solution here (I think it was
> Rick...) but it was definitely some years back.

Pete, it was not me, because I know that won't work!

"15 Intrinsic functions

"15.3 Returned values

"The evaluation of a function produces a returned value in a
temporary elementary data item. The type of a function
identifies the type of the returned value as specified in 15.1,
Types of functions."

It is this "temporary elementary data item" that is used in
the INSPECT statement and, therefore, the data item that would
be modified. After completion of the statement, that data
item would go away leaving the original unchanged.

Actually, I am not certain it would compile without error.

Using REVERSE one might write something like:

move function reverse (fld) to fld
inspect fld replacing leading space by low-value
move function reverse (fld) to fld

While the above is rather straight-forward, it is also
more 'expensive' than a simple loop over the trailing
spaces, like (COBOL 85):

compute n = function length (fld)
perform varying n from n by -1
until n < 1 or fld (n:1) not = space
move low-value to fld (n:1)
end-perform

IBM Enterprise COBOL, I believe, drops the first line and allows:

perform varying n from length of fld by -1

COBOL 2002 drops the first line and allows:

perform varying n from length (fld) by -1

COBOL 2014, i'm guessing, would allow the single statement:

move low-value to fld ((length (trim (fld trailing))) + 1 :)

Of course there are other COBOL solutions, but rather than
describe them, I will choose to park my arse in front of the TV
and watch NETFLIX. I choose to do so because my 'housekeeping'
is sufficiently up-to-date. <g>

[Pete Dashwood]

Thanks for the correction Rick. Usually I do compile code before posting it
here, but I felt pretty familiar with this solution and have used it
frequently.

Maybe, I never noticed it was using a temporary area. But I know I have
never coded it as you and Charlie have with the move of the area being
transformed.

Maybe Fujitsu doesn't use a temporary area but applies it to the string in
the function, or maybe the function automatically replaces the string in the
function with the output from the internal work area.

Next time I'm using COBOL, I'll do a test and see:

a. If it compiles without error.
b. If it actually works on the field specified in the function.

... and I'll post the results here.

I was fairly sure it was you who posted it, but I may have just remembered
the concept and not the details... :-)

It is quite some time (couple of years) since I actually used it in code.

I like it as an imaginative solution; that's why I remember it.

Your choice of NETFLIX over posting here is a sound one... :-)

[Pete Dashwood]

No, it can't be.

The ASCIIZ string (by definition) is a string of ASCII characters terminated
by hex 00.

If you are using EBCDIC it will be a string of EBCDIC characters terminated
by hex 00.

Either way, if you move this string to a larger COBOL field, it MUST be
padded with blanks. (And ONLY blanks...)

IF the ASCIIZ field is exactly the same length as the work string the code
will still work.

What you have now, is exactly what I suggested, except that you have added
more source with a completely unnecessary
WITH TEST BEFORE.

(It's unnecessary because it is the default; perform always tests BEFORE,
UNLESS you specify AFTER.. It has worked that way for as long as I can
remember and the first COBOL compiler I used was tape based COBOL 61... :-)
That's why I am strongly opposed to people coding WITH TEST phrases...
except for the very rare occasions when you need to change the default
behaviour with WITH TEST AFTER (and in nearly 50 years I have never seen a
need for it in my own or anyone else's code.) It clutters the source code
and confuses young players who haven't seen it before... Best avoided.

> An alternative would be to enclose the PERFORM in an IF Statement for
> the last character.
>
> Hopefully INSPECT FUNCTION REVERSED would generate about the same code
> as the follow which should correct the bugs in my previous example or
> even better.
> PERFORM
> VARYING offset-field from LENGTH OF workfield - 1 BY -1
> UNTIL offset-field < 1
> OR workfield (offset-field:1) NOT = SPACE
> WITH TEST BEFORE
> MOVE LOW-VALUES to workfield (offset-field:1)
> SUBTRACT 1 FROM offset-field
> END-PERFORM

No, it's still wrong... as they say in Japan: "Please, look again..."

(Hint: I don't much like Arithmetic verbs, either... don't get me started
:-))

Cheers,

Pete

[Rick Smith]

<snip>

> Thanks for the correction Rick. Usually I do compile code before posting it
> here, but I felt pretty familiar with this solution and have used it
> frequently.

<snip>

> I was fairly sure it was you who posted it, but I may have just remembered
> the concept and not the details... :-)
>
> It is quite some time (couple of years) since I actually used it in code.
>
> I like it as an imaginative solution; that's why I remember it.

I posted a solution to another problem that used INSPECT
TALLYING rather than INSPECT REPLACING. A solution to this
problem with INSPECT TALLYING is:

initialize cnt-1 cnt-2
inspect function reverse (fld) tallying
cnt-1 for leading space
cnt-2 for characters after space
move low-value to fld (cnt-2 + 1 : cnt-1)

The goal for the other problem, as I recall, was to not
code any 'loops' over the trailing characters.

[Joe]

Like you said: We all have ways to do things. Your way is just as
good, I generally adapt to whatever is "common" at the customer site
as someone else has to be able to maintain the code after I'm gone.

The geste of this way of solving the problem is only to show an
alternative which MIGHT be less costly to execute in an operational
environment. Where I'm currently at every performance choice often
has noticable impact based on volume. Note: my suggestion has not
been performance tested or compared to your or the original sulotion.

[Pete Dashwood]

Ah, that clarifies it, thanks. It was the first time I had seen function
REVERSE used so that was the bit I remembered... :-)

I'll be using COBOL tomorrow so will do what I said I would do...

[Pete Dashwood]

OK, I have sussed it now... :-)

You were absolutely correct.

The code, as I presented it above, throws a compile error saying "Function
REVERSE cannot be a receiving field."

Which is fair enough, given the Standard you quoted.

To make it work, I did indeed have to move the string around.

Pretty much as Charlie posted...

That being the case, I probably would use an alternative.

For me, that would be the Fujitsu (and GNU COBOL) function as I suggested in
previous post:

MOVE LOW-VALUES TO WORK-FIELD ( FUNCTION STORED-CHAR-LENGTH (ASCIIZ-STRING)
+ 1: )

I don't think there would be a lot of difference between this and a
reversing single byte replacement loop in terms of execution time and object
code, but it is minimal source and I'm a big fan of that :-)

[Rick Smith]

<snip>

> You were absolutely correct.
>
> The code, as I presented it above, throws a compile error saying "Function
> REVERSE cannot be a receiving field."
>
> Which is fair enough, given the Standard you quoted.

Stranger things have happened! <g>

[docd...@panix.com]

In article <x7Kdne_W6JRDfp_L...@giganews.com>,

Arnold Trembley <arnold....@att.net> wrote:
>If I need to change all the trailing spaces in a PIC X field to nulls
>(LOW-VALUES), I would like to be able to code it this way:
>
>05 destination-field PIC X(100) VALUE SPACES.
>
>MOVE "This is a null-terminated string" TO destination-field
>
>INSPECT destination-field REPLACING TRAILING SPACES BY LOW-VALUES.
>
>But when I look in the IBM Enterprise COBOL manual for z/OS, there is no
>TRAILING option for INSPECT..REPLACING.

How about:

05 WS-CHAR-TSTFLD PIC X VALUE LOW-VALUES.
88 VALID-CHAR VALUES 'A' THRU 'I', 'J' THRU 'R', 'S' THRU 'Z',
'a' THRU 'i', 'j' THRU 'r', 's' THRU 'z',
'0' THRU '9', (etc. as needed)

MOVE LOW-VALUES TO WS-CHAR-TSTFLD
WS-DESINATION-FIELD
PERFORM VARYING SUB1 FROM (LENGTH OF WS-SOURCE-FIELD)
BY -1
UNTIL VALID-CHAR OR SUB1 = 0
MOVE WS-SOURCE-FIELD(SUB1:1) TO WS-CHAR-TSTFLD
END-PERFORM
IF SUB1 = 0
PERFORM A315712-INVALID-INPUT THRU A315712-EXIT
ELSE
MOVE WS-SOURCE-FIELD(1:SUB1) TO WS-DESTINATION-FIELD
END-IF


DD

[Arnold Trembley]

Thanks, Doc! I was thinking along the lines of a loop as well. And the
discussion here included some other options using intrinsic functions.

But having the INSPECT REPLACING TRAILING option and FUNCTION
STORED-CHAR-LENGTH in GnuCOBOL makes me like it even more.

--
http://www.arnoldtrembley.com/

[docd...@panix.com]

In article <q4WdnX9QzaCldJHL...@giganews.com>,

Arnold Trembley <arnold....@att.net> wrote:
>On 9/30/2015 8:13 AM, docd...@panix.com wrote:

[snip]

>> IF SUB1 = 0
>> PERFORM A315712-INVALID-INPUT THRU A315712-EXIT
>> ELSE
>> MOVE WS-SOURCE-FIELD(1:SUB1) TO WS-DESTINATION-FIELD
>> END-IF
>

>Thanks, Doc! I was thinking along the lines of a loop as well. And the
>discussion here included some other options using intrinsic functions.
>
>But having the INSPECT REPLACING TRAILING option and FUNCTION
>STORED-CHAR-LENGTH in GnuCOBOL makes me like it even more.

My pleasure, Mr Trembley... but one should strive to keep source code
compiler-independent; isn't that what OBJECT-COMPUTER is for?

DD

[Pete Dashwood]

docd...@panix.com wrote:
> In article <x7Kdne_W6JRDfp_L...@giganews.com>,
> Arnold Trembley <arnold....@att.net> wrote:
>> If I need to change all the trailing spaces in a PIC X field to nulls
>> (LOW-VALUES), I would like to be able to code it this way:
>>
>> 05 destination-field PIC X(100) VALUE SPACES.
>>
>> MOVE "This is a null-terminated string" TO destination-field
>>
>> INSPECT destination-field REPLACING TRAILING SPACES BY LOW-VALUES.
>>
>> But when I look in the IBM Enterprise COBOL manual for z/OS, there
>> is no TRAILING option for INSPECT..REPLACING.
>
> How about:

Doc,

This cannot work as posted.

WS-SOURCE-FIELD is imaginary... it is defined nowhere.
WS-DESINATION-FIELD is spelled incorrectly.

These days, with the interaction going on between workstations and
mainframes, the need to deal with null terminated strings is becoming more
prevalent.

The words 'ASCIIZ and 'EBCDICZ' are shorthand ways to write "a
null-terminated string in either of these two encoding systems".

Here's some more background:
https://msdn.microsoft.com/en-us/library/ee267399(v=bts.10).aspx

The specific stated problem:

The original requirement works on a single field; it has had an
EBCDICZ/ASCIIZ string moved to it and the requirement is to force the
padding spaces generated by the COBOL compiler when it made this move, to be
set to hex '00'. (In other words, to propagate the terminating X'00' to the
end of the destination field, which was padded with spaces by COBOL.)

(Did you actually look at any of the other code examples posted in this
thread?)

On the (necessary because you haven't defined or mentioned it) assumption
that WS-SOURCE-FIELD is representing the EBCDICZ/ASCIIZ field (e.g.
'ABCDE#', where # is X'00', note that the 88 level "validation" of these
characters is irrelevant because the string can contain ANY valid EBCDIC
character; although this will work as a 'filter' if there was a pressing
need to filter and the string had not been already validated. Normally, the
string would be "validated" at the point where the terminator was appended
to it; the terminator marks the characters that are required for the
process.)

I would make the following observations:

>
> 05 WS-CHAR-TSTFLD PIC X VALUE LOW-VALUES.
> 88 VALID-CHAR VALUES 'A' THRU 'I', 'J' THRU 'R', 'S' THRU 'Z',
> 'a' THRU 'i', 'j' THRU 'r', 's' THRU 'z',
> '0' THRU '9', (etc. as needed)
>

This is an effective and flexible "filter" but it will cause more problems
than it will solve. It will cause the source string to be truncated to the
length of the last "valid character" as defined here. (It may still contain
other "invalid characters"...) That completely invalidates the whole point
of null termination. (A way to define valid variable length strings without
having to use count fields.)

> MOVE LOW-VALUES TO WS-CHAR-TSTFLD
> WS-DESINATION-FIELD
> PERFORM VARYING SUB1 FROM (LENGTH OF WS-SOURCE-FIELD)
> BY -1
> UNTIL VALID-CHAR OR SUB1 = 0
> MOVE WS-SOURCE-FIELD(SUB1:1) TO WS-CHAR-TSTFLD
> END-PERFORM

This PERFORM is unnecessary because it will ALWAYS stop on the penultimate
character of WS-SOURCE-FIELD... UNLESS it is a character which fails the 88
level filter. If that happens, it declares the character invalid and it will
not be part of the final string transferred to WS-DESTINATION-FIELD. But the
process which "packaged" the string by null-terminating it, has indicated
that everything before the null terminator is required (that's why it is
null terminated...) You end up with two different views of what is valid and
a process which stops.

If you are not satisfied that the null terminated string is valid, then keep
the PERFORM, but in reality that string will contain valid characters for
the process which it is intended.

If you are satisfied that is the case, then you might as well say:

SET SUB1 to LENGTH OF WS-SOURCE-FIELD - 1 ...and avoid all the PERFORM
overheads...

(As already noted, the string would be validated before having the
terminator appended to it. If this is an "invalid character", then it is a
wanted one...If it is a "valid character" - which it should be... - then the
perform will stop. If there are other "invalid characters" in the string
(before the valid character), THEY won't be found, so why would you pick on
the penultimate one only... :-)

> IF SUB1 = 0
> PERFORM A315712-INVALID-INPUT THRU A315712-EXIT

(This only happens if the entire source string fails the 88 filter.
Otherwise, the string has its length changed, but it may still contain
"invalid characters", so what was the point?. It contradicts the null
termination. Adding a null terminator to a specifc position in a string says
that the characters up to that terminator are required. Even if it contains
characters that fail the 88 level, those characters were in it before it was
terminated, so those characters are required. In effect, this will bomb out
a "false positive" if it doesn't like a character in the string...)

> ELSE
> MOVE WS-SOURCE-FIELD(1:SUB1) TO WS-DESTINATION-FIELD
> END-IF

And (I think, memory may be incorrect here...) WS-DESTINATION-FIELD will be
padded with blanks (I believe it needs refmod on the target as well as the
source to prevent padding.) which is not what is wanted. All that has
happened is that the code has successfully removed the terminating Hex '00"
from the EBCDICZ/ASCIIZ string...

As they say in Japan:

"Please, look again..."

[docd...@panix.com]

In article <d7cka3...@mid.individual.net>,

Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
>docd...@panix.com wrote:
>> In article <x7Kdne_W6JRDfp_L...@giganews.com>,
>> Arnold Trembley <arnold....@att.net> wrote:
>>> If I need to change all the trailing spaces in a PIC X field to nulls
>>> (LOW-VALUES), I would like to be able to code it this way:
>>>
>>> 05 destination-field PIC X(100) VALUE SPACES.
>>>
>>> MOVE "This is a null-terminated string" TO destination-field
>>>
>>> INSPECT destination-field REPLACING TRAILING SPACES BY LOW-VALUES.
>>>
>>> But when I look in the IBM Enterprise COBOL manual for z/OS, there
>>> is no TRAILING option for INSPECT..REPLACING.
>>
>> How about:
>
>Doc,
>
>This cannot work as posted.

It wasn't intended to. Compiling UseNet postings is something best left
to internet-librarians.

DD

[Pete Dashwood]

Fair enough... :-)