Moving EBCDIC values to alphanumeric field in COBOL

aman333 · New User Joined: 23 Nov 2012 Posts: 4 Location: india

Hi,

I am facing problem while moving EBCDIC values to alphanumeric field in COBOL.

Source Field

Bill Woodger · Posted: Mon Nov 26, 2012 1:01 pm

And the problem is? And the code you have is? Including field definitions. In the Code tags, please.

aman333 · New User Joined: 23 Nov 2012 Posts: 4 Location: india

Problem is that values of source field are getting changed. Hex values should be same for source and destination , but as you can see values are different. We are receiving input file from other system, and we have been told that values in VAR-MISC-DA will be in EBCDIC format.

Please find below code we are using for move:

Pandora-Box · Posted: Mon Nov 26, 2012 2:30 pm

Kindly show us the MOVE statement too

aman333 · New User Joined: 23 Nov 2012 Posts: 4 Location: india

Values are getting moved by

READ INPUT-FILE INTO RSIR-RECORD

INPUT-FILE values ----->>> RSIR-RECORD values

Field definitions have already shared above.

PIC values of both fields are same X(125).

Robert Sample · Posted: Mon Nov 26, 2012 3:25 pm

Aman333, so far you have provided ZERO information that we can use to help you.

How does RSIR-RECORD relate to your source and destination fields in your original post? Source and destination implies a MOVE of some kind -- so why are you refusing to show us the MOVE statement?

You ARE aware, I hope, that reading variable length records the way you are, that you cannot rely upon anything after the number of occurrences your record specifies in VARIABLE-COUNT or VAR-FIELD-CT? And that there may be left over data in the buffer from a previous record -- which is one reason we recommend not using the buffers as you are in COBOL?

Bill Woodger · Posted: Mon Nov 26, 2012 3:39 pm

Aman333,

How did you become aware of what you think is happening? You are showing values, but where did you get those values?

Which Cobol compiler are you using? Robert is correct in how ODO works prior to Enterprise Cobol, and I personally still feel it is good practice to always ensure that the ODO Object contains a logical value.

I can see nothing actually wrong with your READ INTO. This will "MOVE" chunks of data, there is nowhere that it does something to part of the data along the way.

If your values are not what you expect, you are either clobbering them in the program, or using the wrong index/subscript to reference them or otherwise have coded for this particular result to occur, even though you are unaware of it.

Start by saying where/how you got those results. Then go "backwards" through the process of everything in your program which references those things, directly, indirectly, at group or individual level, through CALLs or whatever, until you reach the READ INTO.

If you haven't found it by then, at least you have everything ready to post.

aman333 · New User Joined: 23 Nov 2012 Posts: 4 Location: india

I came to know about what is happening by using display statements. Displayed values of infile-records and RSIR-RECORD and got to know difference.

One thing to note here is that while I am browsing the input file , values are different and in display statement values are different. e.g

In 3.4 option file values are

.. .2...345566777867

While in display statement value is:

2 ..345566777867

dots are getting replaced by spaces as shown above.

I am not sure what more information do you guys need

Bill Woodger · Posted: Mon Nov 26, 2012 4:10 pm

Can you show the DISPLAY statements? Also definition and all references to the subscript/index you use for the DISPLAY (if you do).

Can you show the copybook?

With non-displayable characters, ISPF shows ".", so no mystery there.

As you have non-displayable characters, please show results of DISPLAY in HEX (as you did first). In the Code tags. Note that other formatting does not work inside the Code tags, so don't try it. Use the Preview button to see how your post will look, and correct formatting where necessary.

Simone Salzmann · Posted: Thu Nov 29, 2012 1:56 am

Hi, Aman

your last post looks very like as if the difference in the display in 3.4 and in COBOL is due to the fact that the record length and the block length are omitted in COBOL.
(Each uses two bytes at the beginning of the record)

That would correspond with the fact "Recording Mode V(ariable)" you showed in your second post.

This is not a bug but a feature.
COBOL handles the varying record length (and the block length) itself, you don't have to care for it in your program.
What's shows in position 5 in function 3.4 would be position 1 in COBOL.

Only thing: I haven't had a look into variable files in 3.4 for quite a while and can't be sure on the behavior of this function. Maybe somebody can confirm or deny my assumption.

Bill Woodger · Posted: Thu Nov 29, 2012 5:26 am

From the original post, which is in hex, the display starts with a four-byte unsigned packed field.

The leftmost "13" take the "record-length" (if it were that) well beyond the 4109 shown under the FD and the "IOCS" (the last two bytes of the potential RDW) are neither binary zero nor what would be expected for any record from a VBS/VS.

The silence may indicate a simple record-layout mismatch, or not accounting for the RDW between the two displays.