Data Representation in COBOL
in [Cobol]
|
Prev: Tandem
Next: free implementation? factorial?
From: Pete Dashwood on 11 Jan 2006 07:10 Thanks to both Bill and Doc. I think it was the debugger thing I was thinking of... I remember looking at Assembler listings produced by it and, as I recall, they were interspersed with COBOL source. Ah, happy days... :-) Pete. "William M. Klein" <wmklein(a)nospam.netcom.com> wrote in message news:0NWwf.233699$H26.14998(a)fe07.news.easynews.com... > For the OS/VS COBOL product (if this was in the "back of your mind"), this > created a ".SYM" dataset that could be used by the TESTCOB debugger (a > "barely" interactive debugger of the '70s). This was the first part of > the OS/VS COBOL product to "die" (as far as support goes) as it required > an "unmovable" dataset that could not be handled in an SMS environment. > > -- > Bill Klein > wmklein <at> ix.netcom.com > <docdwarf(a)panix.com> wrote in message > news:dq0bjg$50q$1(a)reader2.panix.com... >> In article <42hh6cF1g2vp4U1(a)individual.net>, >> Pete Dashwood <dashwood(a)enternet.co.nz> wrote: >>> >>><docdwarf(a)panix.com> wrote in message >>>news:dptp6e$g6k$1(a)reader2.panix.com... >>>> In article <Rztwf.14858$oW.10269(a)newssvr11.news.prodigy.com>, >>>> Michael Mattias <michael.mattias(a)gte.net> wrote: >>>> >>>> [snip] >>>> >>>>>Earlier this thread I replied to OP re this: I believe the IBM >>>>>mainframe >>>>>compiler offers a compiler option you can specify which will result in >>>>>the >>>>>creation of an assembler list. If you can get that and read assembler, >>>>>you >>>>>will be able to understand the 'how.' >>>> >>>> The option for the OldBOL compiler (IKFCBL00) was PMAP, for various >>>> versions of IGYCRCTL it is LIST. >>>> >>>Your post stirred something in the deep dark recesses of what passes for >>>my >>>brain... >>> >>>What does/did OPTION SYM do? >> >> I believe that's for IGYCRCTL and it creates SYMbolic records for the >> TEST >> option. >> >> DD > >
From: Christopher Pomasl on 12 Jan 2006 01:20 On Sat, 07 Jan 2006 23:29:30 -0500, raveendra_ibm wrote: > > Thank you Charles Hottel.... > > I was wondering if the result would be the same for > > A PIC X(04) VALUE IS 'BCDN'. > B REDEFINES A PIC S9(04). > ADD 1000 TO B. > DISPLAY B. > > Could you please let me know how this conversion from unpacked to > packed decimal is actually performed. And how is 1000 represented while > addition is performed. > > I am working on IBM Mainframes. > > Thanks and Regards, > Raveendra. The pack and unpack convert zoned decimal to and from packed decimal which is what the underlying machine language will do. The ebcdic for BCDN is C2C3C4D5 Pack reverses the zone and numeric nibbles on the last byte and then takes the numeric nibble for all other bytes. So you get: 02345D in packed decimal format. I don't think that PACK will fail for invalid data. PACK does not evaluate the nibbles, only moves them. Use of the supposed packed field can fail if the packed data that was created is not in packed format. Add 1000 gives 01345D. Since D is a negative sign, adding 1000 to -2345 gives 1345. Unpack reverses the process of the PACK essentially. It reverses the last byte's nibbles again and then moves the decimal nibbles into the numeric nibble of the preceding bytes of the target. Then moves X'F' to the zone nibble giving: F1F3F4D5 = 134N The Display VERB simply displays the value with converting the D5 to a numeric. It is the numeric value with the sign from the packed decimal since B is defined as a signed number. Chris
From: Christopher Pomasl on 12 Jan 2006 10:49 On Wed, 11 Jan 2006 23:20:59 -0700, Christopher Pomasl wrote: SNIP > The Display VERB simply displays the value with converting the D5 to a > numeric. It is the numeric value with the sign from the packed decimal > since B is defined as a signed number. > > Chris It should read "without converting the D5 to a numeric." My bad. The Pack and unpack assembler instructions do NOT fail for a data exception. Only a Access Exception is noted in my aging POP hardcopy manual. They are listed as general instructions and NOT decimal instructions. The description specifically states that they do not evaluate the nibbles as they are being moved. Chris Always remember, you are unique...just like everyone else.
From: charles hottel on 12 Jan 2006 21:52 "Christopher Pomasl" <pomasl-NOSpam(a)starband.net> wrote in message news:pan.2006.01.12.06.20.56.355748(a)starband.net... > On Sat, 07 Jan 2006 23:29:30 -0500, raveendra_ibm wrote: > >> >> Thank you Charles Hottel.... >> >> I was wondering if the result would be the same for >> >> A PIC X(04) VALUE IS 'BCDN'. >> B REDEFINES A PIC S9(04). >> ADD 1000 TO B. >> DISPLAY B. >> <snip> > Unpack reverses the process of the PACK essentially. It reverses the last > byte's nibbles again and then moves the decimal nibbles into the numeric > nibble of the preceding bytes of the target. Then moves X'F' to the zone > nibble giving: F1F3F4D5 = 134N <snip> The unpack will not move X'F' to the zone. It simply switches the nibbles of the rightmost byte. If the COBOL field is defined with a sign then the work is done and the sign will reflect whether the result was plus or minus. If the COBOL field is defined without a sign the compiler will generate and OR Immediate instruct to fix the sign to be positive. (e.g. OI B+3,X'F0').
From: Christopher Pomasl on 13 Jan 2006 20:31
On Thu, 12 Jan 2006 21:52:05 -0500, charles hottel wrote: >> Unpack reverses the process of the PACK essentially. It reverses the last >> byte's nibbles again and then moves the decimal nibbles into the numeric >> nibble of the preceding bytes of the target. Then moves X'F' to the zone >> nibble giving: F1F3F4D5 = 134N > > <snip> > > The unpack will not move X'F' to the zone. It simply switches the nibbles of > the rightmost byte. If the COBOL field is defined with a sign then the work > is done and the sign will reflect whether the result was plus or minus. If > the COBOL field is defined without a sign the compiler will generate and OR > Immediate instruct to fix the sign to be positive. (e.g. OI B+3,X'F0'). It most certainly does, although to be most accurate, the documentation states "Zone bits with coding of 1111 are supplied for all byte except the rightmost byte." Which is essentially the same thing I said. I stated that the rightmost byte was reversed and the.....Ahh I see what you problem is. The unpack does not move X'f' to all zone bytes of the target, only all except the rightmost byte. This is what I meant but wasn't clear enough I guess. The remainder of what you say is indeed likely true (I didn't check) but as stated we are working with a defined signed field. With "zoned decimal" in COBOL (usage is display), if the field is signed the last byte will USUALLY be an alphabetic character in the Cx Dx byte code range. (A-I being positive, J-R being negative) Chris |