Conversion of Assembler to COBOL code

mushreyas · New User Joined: 18 Jul 2008 Posts: 59 Location: Bangalore

Hi,

I have a requirement to analyse a Assembler code and write a COBOL version of it. After going through manuals i was able to understand a bit, but i have some problem in understanding the below piece of asm code. Can anyone help me with this by providing me with the equivalent COBOL code.

enrico-sorichetti · Posted: Fri Dec 16, 2011 9:48 pm

the shifting right and left are division/multiplication by powers of 10 ...
recreate the logic by multiplying and dividing by the proper powers of 10 ( using when needed also the remainder )

Bill O'Boyle · Posted: Fri Dec 16, 2011 10:21 pm

Give this a try. DBLWORD and MULTIPLICATION not needed. Just desk-checked. The TRUNC(BIN) compile option might be necessary unless your compiler supports COMP-5, in which case, change the definition of WS-FWORD from COMP to COMP-5.

Bill Woodger · Posted: Sat Dec 17, 2011 5:03 am

Do you have a program spec for the Assembler program (including all updates)?

The data shown is a little odd, with the low-order zero, and the high-order two bytes being the low-order bytes of the day number, so you risk mingling data 3-4 times a year.

What is the reason for the re-write? If it is a long-term replacement, I'd be inclined to go from the spec (if I could convince myself it included all the updates) so you have a Cobol program that looks like a Cobol program, rather than one which is structured like an Assembler program. If you feel the spec is unreliable, then I guess you don't have too much of a choice, unless someone is willing to write a new spec.

If you continue like you are, at least do a complete retospective spec at the same time, get it signed off by the usual suspects, so you don't get hung out to dry in User Testing when someone says "the program shouldn't be doing that". You can't stick an Assembler source listing under the user's nose and say "yes it should", but you can say "OK, but you signed-off on the spec..."

Pedro · Posted: Sat Dec 17, 2011 6:29 am

Bill O'Boyle · Posted: Sat Dec 17, 2011 6:52 am

Popular user-response, when the results are not quite what they were expecting -

"You did exactly what I asked for, but not what I wanted...."

Oops!

Mr. Bill

mushreyas · New User Joined: 18 Jul 2008 Posts: 59 Location: Bangalore

Bill,

The code was written long time ago... Maybe i wasn't even born at that time... So not sure about the specs. The ASKEYXT is part of the Record key of a VSAM file which ASM code is trying to generate.

Also isn't the EIBDATE and EIBTIME in Packed decimal format and should be moved to variables defined as S9(07) COMP-3 instead of 9(07) and 9(06).

Bill Woodger · Posted: Sat Dec 17, 2011 4:18 pm

At least part of this goes to me. So I suggest you do the "spec" as you go along, and get it signed-off in the usual way. Otherwise problems are going to be "your fault" even though you have done what you have been asked. You need your "Get Out of Jail Free" card. You are being asked a enough as it is.

There is no problem moving a packed field to a USAGE DISPLAY field, the compiler will generte all the code that the Assembler programmer would have had to do.

Bill O'Boyle · Posted: Sat Dec 17, 2011 11:26 pm

Based upon your comments in the Assembler code, regardless whether the data is represented in packed-decimal or display-numeric format, the value that you need converted to binary has a format of 'DDHHMMSS0'.

But, it's still confusing as to whether the value populated in 'DD' is the high-order 2-Digits of the EIBTIME 'DDD' or the lower-order 2-Digits.

Either of these 'DD's (using todays Julian Day of 351 as an example), could resolve as '35' or '51'.

In either example, this runs the risk of a duplicate value.

You could format the decimal value as 'DDDHHMMSS' and eliminate the low-order zero. But even this format could raised a duplicate because your time granularity is only at the SS (seconds) level., which may not be finite enough to ensure uniqueness.

Now, back to the Assembler code.

You issue a CVB, using R0, converting the DBLWORD to BINARY.

But, then you issue a ST DBLWORD into R0, which is incorrect syntax.

You can keep the DBLWORD value and instead, issue ===> STCM R0,B'1111',ASNKEYXT. Many Assembler programmers normally use a 15 instead of B'1111', but it would be to your benefit to review this instruction in the POPS manual, so you can get the full meaning of the B'1111' mask.

Using a STCM (Store Character Under Mask) is a failsafe and it will ensure you won't have any alignment problems and now, ASNKEYXT contains the Binary-Value and DBLWORD is left undisturbed.

Just my two cents....

Mr. Bill

Bill O'Boyle · Posted: Sun Dec 18, 2011 12:10 am

Check that, meant to say "high-order 2-Digits of the EIBDATE 'DDD' or the lower-order 2-Digits".

Mr. Bill

mushreyas · New User Joined: 18 Jul 2008 Posts: 59 Location: Bangalore

Hi Bill,

Its the Low order 2-digits of YYDDD which will be used. Going by your example of 351, it will use 51.

As i said earlier ASKEYXT is not the record key its forms as integral part of a it. The Record key is of 14 bytes long and the last 4 bytes is ASKEYXT. Logic can't be changed as this ASM code is currently sitting in live and has been there for a very long. However in case of duplicate record being detected while writing to VSAM they are handling it by adding a half word to this binary data stored in register R0. (ADD R0, =H'1')

Bill Woodger · Posted: Sun Dec 18, 2011 9:35 am

So it adds one to the lowliest part of the key. If it does that 10 times, it'll start to change the time part :-)

Probably not important, but how do you ever read them again if you're not quite sure what the key might be? Read with the full key and if not the one you want, read next until 10-byte key change or you find the one you want? Or don't use the full key, and do the same. Seems unusual, but if it has been sitting there for a long time it must be what someone wants :-)

Bill O'Boyle · Posted: Sun Dec 18, 2011 11:34 am

So, with that, in my previous example -