Change in Case After MOVE statement

apandey · New User Joined: 31 Aug 2009 Posts: 73 Location: Mumbai

Hi ALL,

I have a variable "ASN-PART-OR-CNTNR-TYP PIC X(1) from 1 copybook,
another variable ASC-CODE-PART-CNTNR PIC X. from another copybook.

I have a move statement.
MOVE ASN-PART-OR-CNTNR-TYP TO ASC-CODE-PART-CNTNR
I displayed both fields in SYSOUT, Its value is as below:

ASN-PART-OR-CNTNR-TYP : P (P in CAPS)
ASC-CODE-PART-CNTNR : p (P in small)

I want to know why value is changing from CAPS to small, I havent used
any COBOL Case function on any of the field.
COz exact below this statement
I am checking IF ASC-CODE-PART-CNTNR = 'P' , so its not statisfying IF and going else loop.

Can anyone pls help.

Craq Giegerich · Posted: Fri Jun 03, 2011 8:08 pm

That would not happen, I think there is something missing it your explanation of what was done.

apandey · New User Joined: 31 Aug 2009 Posts: 73 Location: Mumbai

Nothing is missing as per my given information,.
I m also surprised to see this kind of issue. I'hv also never faced such issue.
There is only MOVE statement in whole program on this 2 fields.
Both the copybook are initialised in starting in procedure division.
Then input file is read thru 1 copybook and mentioned field is moved to other field of 2nd files copybook, which i displayed above.

Robert Sample · Posted: Fri Jun 03, 2011 8:28 pm

Bill O'Boyle · Posted: Fri Jun 03, 2011 9:02 pm

This happens often when CAPS ON is set and someone moves the space bar or alters any value on the source-code line and then ALL lower-case on that line are translated to upper-case.

To get around this, use the lower-case value of a letter in hex-notation, as has been suggested.

Bill

dbzTHEdinosauer · Posted: Fri Jun 03, 2011 9:17 pm

Bill,
i am as confused (well not quite) as you are.

he is saying that the first pic x field contains an upper-case P.
his cobol program moves the pic x field to a second pic x field,
and when he displays the data, it is
upper-case P in the source field
lower-case p in the destination field.

well, we all know that a simple cobol move statement will not affect the 'case' of alphabetics.

but,
since so many of the 'new programmers' insist on storing numeric fields in x type
and the field names are suspect numeric fields:
ASN-PART-OR-CNTNR-TYP
ASC-CODE-PART-CNTNR

emphasis is mine
and an uppercase as well as lower case p is a -7.

........

Bill Woodger · Posted: Fri Jun 03, 2011 9:31 pm

Time for a longer piece of the code and the data definitions, in the Code tags please, and copy/pasted so no typos introduced.

As with others, no way a move can do that in Cobol.

Bill Woodger · Posted: Fri Jun 03, 2011 10:09 pm

Discovered by TS 11 minutes after posting original.

Move made by accident to ASC-CODE-PART-CNTR.

Previously ASC-CODE-PART-CNTNR had been changed to lower-case for a different transaction in a different part of the program.

I could be wrong :-)

But where is TS with his interesting problem>

Anyway, my fantasy, I mean my educated guess, gives me another opportunity to emphasise meaningful data-names.

ASC-CODE-PART-CNTNR why? You got a keyboard with no vowels by the time you typed the last part of the name? What did it save anybody? Lined-up against confusion potentially caused? (Not blaming you, TS, until you tell us you defined the copybooks).

GlobalGyan · New User Joined: 31 Jan 2006 Posts: 28

Would you be able to show a screenshot of a debugging tool for the move statement? perhaps the values of variables just afterthe move statement? This might shed some light on this move mystery.
Also show the exact screenprint of the IF loop, it could be that the IF condition may have a 'P ' or ' P' or 'p' ..

nigelosberry · New User Joined: 06 Jan 2009 Posts: 88 Location: Ggn, IN

dbzTHEdinosauer · Posted: Mon Jun 06, 2011 11:47 am

another thread that should be locked and deleted

Bill Woodger · Posted: Mon Jun 06, 2011 12:38 pm

Dick, do you mean to say you see no value in keeping a topic like this?

apandey · New User Joined: 31 Aug 2009 Posts: 73 Location: Mumbai

Hi All,

Thanks all for giving ur valuable time and sorry that I am replying late.
As Robert Suggest in his 1st reply that to work with someone at my site.
I did the same, Even we were not able to crack that problem. But what we
have done is deleted that para and re-written that para. Initialized both the copybook calling before that para.

When we executed, program ran fine. So Thanks everyone for ur valuable reply.

1 more thing,
HI dbzTHEdinosauer,
I saw ur reply about naming and datatype of mentioned 2 fields.
Believe me both were element of copybook which were already implemented way long back and both were alphanumeric fields.
_________________
Regards,
Ashutosh

dick scherrer · Posted: Mon Jun 06, 2011 8:48 pm

Hello,

Bill Woodger · Posted: Mon Jun 06, 2011 9:00 pm

I don't suppose you have the compile listing from the run which went wrong?

Not much point in "intialising" the fields. One is from a file, the other you say is the receiving field of the move, presumably you think with no other route through the program.

If it works now, the code you took out of the paragraph is different from the code you put in. Or the data is different, in which case the problem might come back.

How do you know it ended up with lowercase "p" anyway? Chasing smoke and shadows. End of story unless you have the listing.

nigelosberry · New User Joined: 06 Jan 2009 Posts: 88 Location: Ggn, IN

Its the TS who has to decide. But settling with a solution without knowing what exactly was the problem might turn out be risky.