Hello,

Let me preface this with the fact that I have almost zero COBOL knowledge. I was tasked with converting an old COBOL app into java.

My current issue is I have the whole program working, with the data matching, except for one field.

The cobol app reads in records from a file and manipulates data, then prints it to an output file.

So here is the record in definition:

01  TYPE-K-REC.
       05  TK-FILLER-1          PIC X(40).
       05  TK-DATA.
              10  TK-FILLER-2      PIC X(32).
              10  TK-YTD-HRS       PIC 9(8)V99.
              10  TK-FILLER-4      PIC X(816).

Here is an example record not including quotations:

"123456789101112K                        *** ABCD12EF34567891011121314000000070650+                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               "

So here is my understanding:

TK-FILLER-1 = "123456789101112K                        "

TK-FILLER-2 = "*** ABCD12EF34567891011121314000"

TK-YTD-HRS = "000070650+"

TK-FILLER-4 = All the extra whitespace

Essentially what I want is TK-YTD-HRS. My questions:

TK-YTD-HRS is defined as PIC 9(8)V99. From my limited understanding, and assuming I have mapped out the fields correctly, wouldn't having a "+" at the end of the input cause an error? The thing is apparently it does not because the output file from the cobol app is generated anyway. So does having the + sign in one of the decimal places mean anything?

Basically what is the value of YTD-HRS?

Is it 706.50 and the + sign is just there?

Or is it 7065.0+? If this is the case can someone explain what happens when it goes to add another number that is similar i.e. "7065.0+" + "1234.5+"

Like I said, my knowledge is very limited, so I may have explained this horribly. Let me know if I can provide anymore info.

Thanks

Mike

Well, you have good eyes :-)

That is "00007065" before the implied decimal point, and "0+" after the implied decimal point.

The "+" in EBCDIC is X'4E'.

As far as the validity of a zoned-decimal number (or a byte of the same) that is invalid. The left half-byte should be a "Zone" (an F) or a "Sign" (an F for an unsigned field, like yours) and the right half-byte should be the number (0-9).

If anything were to attempt any arithmetic on that it should cause a system abend S0C7, a Data Exception.

The implication would be that little is done with that value once it appears like that. However, you're going to have to track everything down, or at the very least report the issue and let someone else do the tracking.

So let me expand a little to see if this changes anything. When the file is read, the original record is read in correctly as I believe the + sign is read in and stored as a string field in the REC-IN.

Then it is moved i.e. MOVE REC-IN TO TYPE-K-REC.

So is "moving" a + sign into an int pic result in an error, or does it convert it to the EBCDIC value or so some other integer value?

I'm just wondering if there is any way the + gets converted into an int rather than an error. Because the program runs without error.

Another point:

+ sign is stored in a string pic.

Then is moved to a int pic.

Then the int pic is added to another int pic(this captures a total of all records), but this one clarifies "USAGE IS COMP." Does this change anything in regards to the signed vs unsigned pic declaration?

After all this it then Moves the total pic into a "PIC zzz,zz9.99", which also doesn't seem right as your moving a PIC 9(8)V99 to zzz,zz9.99. Which seems like your leaving out the front 2 integers.

I just think the program doesn't error out but the true value is getting distorted in one if not more of the steps above.

I understand that it's probably hard to follow with my explanations.

So I guess my question for this reply is Moving a PIC x to a PIC 9 valid? Or will this also give an error?

MOVE REC-IN TO TYPE-K-REC is just a byte-for-byte MOVE. It can be nothing else. There are no "strings" in COBOL, only fixed-length fields (except for variable-length ones, but there there is a separate fixed-length field which tells how long the variable one is). So you can't look at the data and do other than guess where one field starts and ends, or even reliably (from one record) guess the data-type.

You'd need to show the code, and the data-definitions, for everything involved. And the value of compiler options NUMPROC and TRUNC. If it doesn't abend for maths, then there is some reason.

It is reasonably common that output fields on a report are "shorter" than you'd think reasonable. This should be because the maximum value that can be held is "smaller" than the field. However, as you say, this could also be a problem. It depends on the definition.

Yes, you could be looking at two (or more) issues.

Can you independently verify the total amount? Is it perhaps that the start-position is "off by a byte"?

Friend, if I understand your need, the variable TK-YTD-HRS is a 9(8), 99  getting "000070650+", so the value in it 000070650,00. For the comma would only be assigned if it were identified by the program in its value.

Although I'm not quite sure what you are saying, I'm quite sure that is not how IBM COBOLs work.

I haven't parsed the data areas, but I did read that second description. From it, I'm guessing that you had "sign separate" specified (or effected). That means that the "+" is not part of the display numeric, but is the sign for that. I used to have to do this kind of programming to get data between dissimilar machines (e.g., Honeywell/IBM, Burroughs/IBM) where the sign would be at a different location (leading vs trailing, or otherwise handled a bit differently). 

So, in this case, one would read the data (numeric display), and then read the sign. The data is "absolute" (as in unsigned, but with z/Architecture is assumed to be positive) and so must be multiplied by "-1" in the case of "-" and "+1" in the case of "+" to ensure the correct sign of the data in/on the new architecture/program.

HTH

Figured I'd give an update due to recent replies.

So I decided to download a compiler (OpenCobolIDE) and run the source code for myself. As @BillWoodger 93bccaec-8df2-4d8e-81b7-2dca26a07c00 pointed out, I did receive a data​ exception that I was expecting.

Given the original programs were written in 2006, whether or not older compiler's handle certain errors is beyond my knowledge.

So at that point I reached out to the provider of the source and expressed that I am confident that what I currently have is not the source code currently being used. Unfortunately, the only source code they have is what I received and through a long story I don't know enough about, it sounds like these apps have been around for a long time and at this point all we have is the executable, and a piece of source code that is most likely not current.

At this point, I have validated that the original data field in question is wrong, and that the new app I wrote correctly calculates the field. Of course, this is not counting on any lost business knowledge from 10 years ago when someone may have purposely altered the specified field in the code, which we no longer have the code to see if they did.

The whole point of this new project was to prepare for some new additions, so we decided to convert the app while we were at it. Unfortunately, it sounds like the new field is directly related to the one I had an issue with, so we may no longer be able to ignore the original problem unless I can figure out what the current cobol app is doing, which is unlikely due to not having any of the source code.

I want to thank everyone for the responses, as they did help. Before this project I did not have much experience with cobol, but now I at least have a basic understanding of the language in general and how my program operates.

I guess I will go ahead and mark @BillWoodger 93bccaec-8df2-4d8e-81b7-2dca26a07c00 as the answer, since he did provide some initial insight that helped me understand my issue as a whole.​

If the source is vital-and-missing, there is the Source Recovery Company. It costs, so needs to be vital. Having discovered that they can lose sources, the company should tighten up their controls so that it can never happen again.

If they happen to be considering a purchase of IBM's Advanced Binary Optimizer (ABO) there is a three-month trial available. As part of the trial the program could be optimised with ABO and a new (pseudo-assembler) listing would be produced of the new, optimised, executable.

Someone who can read "LIST" output could then find out a bit more about the code that is running. If they have someone like that.

I will keep this in mind. At this point I am fairly certain my issue is with the source. After some of your earlier replies, I took a closer look and there are several instances in the input file where there is a number followed by a '+'. However, in all these instances except the one, the PIC is defined to always include the numbers up to the '+'. Why it tries to include it for the one record type is beyond me.

So long story short, the app checks the input file and creates a summary, which is used to validate the data before the file is sent to Vanguard. After I explained what I had found and we decided to move past it, I got the requirements for the changes that need to be made. The requirements are written by Vanguard, and with no surprise, the input file layout matches it almost perfectly. So I scrolled through the requirements and looked at the field I had an issue with and this is what they had:

The current cobol code I have a. doesn't even account for the sign, and b. had the pic as 9(9)V99. However the input file has the data for the extra two numbers and sign. So now I am almost certain that either an attempt was made to get the source code through a decompiler and it didn't come back complete or someone tried to create the cobol source from scratch and just missed some pieces.

Basically it looks like what is currently being used on our end is not following the specs and is just ignoring the signs and various tid bits. 

So at this point I think I am just going to wait for the new input files from Vanguard and test those with the new requirements. Pretty much went from trying to rewrite the old app to just writing a new one with the new requirements.

It is what it is :/

OK, separate signs make a lot of sense for a file sent to an external source.

They didn't have to be defined separately, COBOL has a "SIGN" clause which allows SEPARATE and either LEADING or TRAILING. A signed numeric-edited field is another way to do it.

It is the best way, so that all the data is "character" and no one has to do idiotic decoding of what looks like a letter or a { } (for negative and positive zero).

Good shot @Steve.T 0980a4d6-aa72-4ece-be7a-bf66d3bd2798​ :-)

Sounds like you have a plan now. You should note, through your boss, that thing about how they have lost the Production source, so that they can ensure they never do it again.

The data looks like that, but it doesn't need to be a separate sign. It can be the sign when a numeric-editing PICture was used, or it could simply be the next-byte-along on the record.

Since the PICture shown is unsigned, I'd tend to guess it is an unassociated byte, until more evidence is uncovered.

Please don't multiply by minus-one to reverse the sign of something. Subtract from zero, instead. Always faster. And if changing "unsigned" to signed, ADD ZERO.