Joined: 09 Nov 2007 Posts: 2 Location: Mechanicsburg, PA
Hi,
We have a variable length record type defined with an occurs clause defining the length from 1 to 1970 characters. When an OBTAIN is done and a shorter record is returned to the array, it is padded to 1970 characters with garbage. We have just converted to IDMS V16 SP4 from IDMS V12. The same code running against the same data in the IDMS V12 database returns the record padded with nulls. Is anyone else experiencing this?
Thanks,
George
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
The difference between having the area padded and not padded is extra instructions during the data move process. most of IBM's i/o services only move the length of the variable data. Memory beyond the end of record/item/column... and the end of your designated 'receive area' is usually not addressed. Either the I/O service prefills your 'receive area' with spaces, low-values etc. and then moves the variable data for the desinated variable length or executes some instructions afterwards to pad the 'receive area'. I don't know which, would bet on the first, but i think v12 is so old that IBM would have discontinued that - like initializing memory to low values before loading a module - because if you watch your lengths and process your variable length professionally, you won't have any problem. In your case, y'all should of coded properly when the programs were originally coded, calculate a max occurs (number of items for this record) and use it in your indexing/subscripting logic, instead of relying on a data value delimiter when the index is within the max potential range (number of items when record is the max length). Even the STRING command documentation tells you to initialize your 'receive area'.
this is something you are going to have to live with. you don't have junk in the area between end-of-current-var-len-rec and the end of your 'receive area', it is what was there before the i/o services moved the data from its buffer and your receive-area.
This data ( between end of current var len rec and receive area end point) should be ignored by your program, and since it is junk and you are complaining about it means that your code for handling the ixr/subsc is poor. Either fixed the index handling code or initialize your receive area each time before calling the i/o service.
I doubt that I IBM is providing any 'extra services' for poor code, but CICS Guy may have a good point.
[quote]
Sounds like an LE option...
[quote]
i would fix the index/subsc code. add logic to calculate the current records number of items - at most it is a couple of computes, whereas initializing your 'receive area' would be very expensive. more expensive if you find a way to get the I/O service call to do it.
Joined: 09 Nov 2007 Posts: 2 Location: Mechanicsburg, PA
I appreciate the responses. Yes, I agree that assuming that the buffer will be cleared externally is bad and recoding might be the only recourse. But, the point is that the only thing that changed in the scenerio is the IDMS upgrade. Unless the IBM I/O service routines are hard linked into the IDMS modules, I would expect the behavior to stay the same. The garbage beyond the end of the record is not data in the application, but it looks like IDMS internal table data. When, for instance, a 1000 character record is obtained followed by a 200 character record, the 200 character record is not followed by remnants of the 1000 character record for 800 characters. Instead there is "fresh" garbage.
It isn't an LE option (good idea though) since it happens with both OS/VS COBOL running with the non-LE libraries as well as Enterprise COBOL under LE.......this is an OLD system. So old, in fact, that some of the programmers tell me they may not be able to find the source!
I am probably going to open an issue with CA, I just wondered if anyone else had experienced this.