Cobol Data Division Question

[DECxchange]

Hello,
I am new to Cobol on OpenVMS Alpha 7.3. I just had a simple question. Does anybody know how manny bytes the following statement represents? My guess is 8 + 5 = 13. Or is in Words? I tried to look this up in the Cobol language reference manual on OpenVMS.org but couldn't find it.

01 WS-VALUE-SUMMARY-TABLE.
05 WS-PROD-FORCED-DOWN-TIME PIC 9(08)V9(05).

The reason I'm asking this is I had to add some variables to this file definition. It is a layout for an RMS Indexed file. I recompiled and relinked the Cobol program and got the following error in the VMS debugger:

1130: " DATE: ", SUMMARY-DATE
->1131: WRITE OPERATION-REC
1132: INVALID KEY
1133: DISPLAY "WRITE TO SUMMARY FILE FAILED"
1134: DISPLAY "FILE STATUS ",FSTAT-OPERATION
1135: END-IF.
1136:
─ OUT -output───────────────────────────────────────────────────────────────────
stepped to IC4107A\%LINE 1264 in THREAD 1
stepped to IC4107A\%LINE 1267 in THREAD 1
stepped to IC4107A\212-GET-SPECIFIC-MACHINE in THREAD 1
break at IC4107A\%LINE 1131 in THREAD 1
%COB-F-WRITE_ERROR, Error during WRITE on file OSFTDISK3:[RMS]IC4107A.IDX;2
-RMS-F-RSZ, invalid record size
break on unhandled exception preceding SHARE$DEC$COBRTL+107012 in THREAD 1
─ PROMPT -error-program-prompt──────────────────────────────────────────────────
%DEBUG-I-SOURCESCOPE, Source lines not available for .0\%PC
Displaying source in a caller of the current routine
DBG>

So basically, I'm trying to fix the error:
-RMS-F-RSZ, invalid record size

There is a .FDL file for this indexed file. So I just need to count up the bytes in the Cobol file definition, change the FDL record size and convert/fdl the indexed file, right? Thanks.

[Hoff · Accepted solution]

Try http://www.hp.com/go/openvms/doc for the manuals, including the COBOL documentation. (http://www.OpenVMS.org isn't where you look for HP details and documentations. That's a user community site.)

The declaration of the file would be interesting, as it looks that your additions to the record were not reflected in the file creation and record size.

As for the size in bytes for packed decimal (and this is from very dim memory), it's usually calculated by calculating the numbers of digits, divided by two, plus one. Any resulting fraction is rounded up.

S99999999V99999

Which works out to 9 bytes for a packed decimal COMP type, and 13 for non-comp DISPLAY types.

(I'd confirm it, though.)

A straight COMP type is usually easier to calculate.

When presented with this sort of thing, I usually end up using the debugger or other such, and seeing what's actually produced. Create a little stub or such, and pass it around, and take a look. Easier than the manuals.

But as for the manuals...

http://h71000.www7.hp.com/DOC/82final/6296/6296pro_018.html
http://h71000.www7.hp.com/DOC/82final/6296/6296pro_039.html

[DECxchange]

Hoff,
Thanks for the help and the links. BTW, the last two links you gave me are exactly what I ended up going to via OpenVMS.org. There is a link on that latter web site about 1/3 down called "documentation". It must link you to the HP doc site. I only looked at the Lang. Ref. though so perhaps I just didn't look close enough or study it hard enough. But thanks again, appreciate your help.

[Hein van den Heuvel]

You really need to show a bit more from the record definition to correctly describe the problem. The debugger info is rather useless, just the RMS-F-RSZ is all that's needed.

Anyway,

Yes will likely need to convert the file. And yes you will likely want to match the x in "RECORD; SIZE x; " in the FDL to the cobol length. COBOL/LIS will nicely tell you the new size. Or... some folks 'cheat' and create an edit of the program with OPEN FOR OUTPUT and have cobol create the file, then use ANAL/RMS/FDL on the new file. Delete that new file, and mix and match the old and new fdl as needed.
Or... just set the record size in the FDL to 0 and omit 'FORMAT FIXED', then any record size will be allowed.

Note... you might need a program instead of a convert to read from all, write to new.
Convert can 'grow' the record. However, it needs to provide fresh byte values. You can control this with the /PAD switch, but only provide one byte value, typically space, ascii zero, or the default binary-zero.
If you added both text fields and comp fields, then a simple single byte value typically is not good enough for all fields added and a program is needed.

Cheers!
Hein.

[DECxchange]

Thanks, I did create a listing earlier so I'll take another look and go from there. Thanks for all of the suggestions.

[Dennis Handly]

>My guess is 8 + 5 = 13.

I would say yes for usage DISPLAY. It's true for COBOLII/iX.

>Hoff: A straight COMP type is usually easier to calculate.

It's 8 bytes.

[Phil.Howell]

An easy way to check this is to include the qualifiers /LIST /MAP=(DECLARED) when you compile.
The listing will then show you the size of the data structures.
You should also read up on the /ALIGNMENT qualifier if you have any binary fields.
Phil

[John Gillings]

Phil's suggestion to use /LIST/MAP is the easiest way to see the size(s) of a particular declaration. However, if you want to find a declaration to match a particular size, that's not much help (unless you're into trial and error).

See Tables 5-12 "Unscaled Data Items, Allocated Storage, and Corresponding Data Types" and 5-13 "Scaled Data Items, Allocated Storage, and Data Types" in "HP COBOL Reference Manual" for details of the sizes of data types.

Chapter 16 in "HP COBOL User Manual" will teach you how to ensure your data is layed out in memory the way you want (important if your data must match records in existing files). In particular see "Table 16-1 Boundaries for Naturally Aligned Binary Data (Alpha, I64)" and "Table 16-2 Alignment and Padding Order of Precedence (Alpha, I64)"

Use /LIST/MAP to confirm your declarations are correct.

[Homer Shoemaker]

QUOTING HEIN
"Or... just set the record size in the FDL to 0 and omit 'FORMAT FIXED', then any record size will be allowed."

I like the way you think! Had a similar problem, searched the forum, found this, and used your fix. Presto change-o. It works!

Too bad I can't assign points in this thread.

[John Reagan]

Besides John G's suggestions, also look at the COBOL RM manual for the USAGE clause. There are tables there for how the compiler computes storage sizes for various declarations.