The FD entry has a PIC 9(4) COMP variable which takes 2 bytes. Therefore, 2 + 1689 + 4 (for VB datasets) = 1695. The LRECL value in my JCL had 1697 because I overlooked COMP. My job is working fine now.
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA
MOST of the time (in MY experience) a 39 is the result of LRECL of the dataset does not match the record length defined in the program. Glad you found the error.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
As a general rule, specifying PIC 9(08) COMP (a fullword) is a wiser choice for an OCCURS DEPENDING ON as it has a much greater maximum than a halfword, PIC 9(04) COMP and it's only two bytes more. Plus, COBOL has some rather strange idiosyncrasies when dealing with halfwords coupled with the TRUNC option.
If your compiler supports COMP-5 (as a substitute for COMP), then this is what you should use as binary-fields are treated correctly, because COMP-5 is Native Binary.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
No, there are no idosyncracies with COMP fields and TRUNC. They work as documented.
COMP/BINARY/COMP-4 (IBM's Tom Ross has stated that the compiler code simpy aliases BINARY/COMP-4 to COMP) use decmal truncation. A PIC 9(4) of these has a maximum value of 9999.
COMP-5 is native binary, and only truncates to field-size. PIC 9(4) can contain 0-(64k-1).
COMP (and therefore its cousins) is affected by TRUNC.
TRUNC(BIN) and it is also native binary. The PICture is only used to define the field size (1-4, half-word, 5-9, fullord, more than 9, double-word).
TRUNC(STD) targets are always truncated to PICture (PIC 9(3) cannot contain more than 999).
TRUNC(OPT) is the one which needs understanding. To use TRUNC(OPT) all COMP field must conform to PICture. If they do not, then there is some foot-shooting in store. With TRUNC(OPT) the compiiler users whichever is more convenient (speedy) at the time, decimal or binary truncation. If the original source conforms to PICture, there is no problem.. Even if you "see" excess bits in intermediate values, they will not cause a problem. This, correct, behaviour is not limited to half-words.
COMP-5 is unaffected by TRUNC.
If the source is native binary (if it does not conform to PICture) use COMP-5, or you will potetially ose data.
There is a performance hit, generally, but not in all cases, from using COMP-5. Half-word COMP-5 is less problematic than full-word COMP-5 here.
Mess with addresses, use COMP-5. Needing to understand binary from an external source (JAVA, unix-type, Windows) use COMP-5.
So, know your data. If it conforms to PICture, use COMP. If it does not, use COMP-5.
Do not mix within or across programs/systems for the same data. Asking for trouble,
Defining everything as COMP-5 (or using TRUNC(BIN) will work, but there is that CPU hit. If someone decides later to change things for this reason, someone (else) will have to ensure that all binary fields conform to PICture or use COMP-5.
So, there are two choices for a value of >9999 and <32k, COMP-5 PIC 9(4) or COMP PIC 9(8) (not COMP PIC 9(9), which again has performance issues). Half-word instructions are cheaper than full-word instructions.
For >= 32k, COMP PIC 9(8) or COMP-5 PIC 9(9) (no similar problem with 9 "digits" for COMP-5, because COMP-5 is only using the "digits" to determine the size of the field).
All this is documented. There is nothing idiosyncratic. COMP-5 is not a Panacea.
Knowing your data is the important thing, then choosing something which can accurately represent all your data, and being aware of possiblle consequences of using binary fields many times.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
OK, so what are the issues?
Immeasurable differences, no. I mentioned it because people notice it, and mentioned the "conversion" because people "convert" from it.
Making everything COMP-5 will work. There is a cost.
Making everything 9(9) for COMP-5 will work. There is a cost.
I just don't want someone making that into local law on the basis of "idiosyncrasies" which do not exist.
The costs are documented in the IBM Enterprise Performance Tuning guides. COBOL
Version 4 Release 2 is the latest, and with the least extreme of differences:
Quote:
TRUNC - BIN, STD, or OPT
When using the TRUNC(BIN) compiler option, all binary (COMP) sending fields are treated as either halfword, fullword, or doubleword values, depending on the PICTURE
clause, and code is generated to truncate all binary receiving fields to the corresponding halfword, fullword, or doubleword boundary (base 2 truncation). The full content of the field is significant.
This can add a significant amount of degradation since typically some data conversions must be done, which may require the use of some library subroutines.
BIN is usually the slowest of the three sub options for TRUNC.
The relative and absolute amounts of any differences depend, of course, on the specific programs/systems. If there is an element of charging based on CPU, ask the bill-payer the percentage (across a system(s)) they would refuse as a saving.
I've only quoted the one piece, because when I've pasted from the .PDF and it arrived a word at a time...
I have no problem with the suggestion to use COMP-5, only with the context of the suggestions.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
Bill,
About 15 years ago, I was doing a lot of bit-twiddling using halfwords and one day, I got bit, when an overseas client had compiled our programs using TRUNC(STD) as opposed to TRUNC(OPT), which is what we had recommended and the result of the halfword bit-twiddling was incorrect and it caused a big mess.
I understand the additional overhead associated with TRUNC(BIN) as well as 9(09) fullwords. I always use 9(08) fullwords with TRUNC(OPT) or COMP-5 (second choice, when mandated). When defined as COMP-5, the TRUNC option has no effect (been conveying this for years), but there's additional overhead as COMP-5 is a trimmed-down version of TRUNC(BIN).
I would contest the difference between halfwords (9(04)) and fulllwords (9(08)) when using TRUNC(OPT) as the efficiencies are immeasurable and are not worth the time and effort. The main thing is that they are a friendly definition in COBOL as opposed to doubleword-binary, which historically is not.
Perhaps my experiences are out dated?
Maybe, but these are my personal choices, which I know will always keep me out of trouble (fool me twice, shame on me) and avoid those O'Dark Thirty phone calls.
