Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Trash following variable length records

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> IDMS/ADSO
View previous topic :: :: View next topic  
Author Message
George Sproull

New User


Joined: 09 Nov 2007
Posts: 2
Location: Mechanicsburg, PA

PostPosted: Sat Nov 10, 2007 12:16 am    Post subject: Trash following variable length records
Reply with quote

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
Back to top
View user's profile Send private message

CICS Guy

Senior Member


Joined: 18 Jul 2007
Posts: 2150
Location: At my coffee table

PostPosted: Sat Nov 10, 2007 1:46 pm    Post subject:
Reply with quote

Sounds like an LE option... Is V12 to V16 a large change?
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Sat Nov 10, 2007 3:57 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
George Sproull

New User


Joined: 09 Nov 2007
Posts: 2
Location: Mechanicsburg, PA

PostPosted: Tue Nov 13, 2007 9:44 pm    Post subject:
Reply with quote

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.

Thanks.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> IDMS/ADSO All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Removing Duplicates based on certain ... chandracdac DFSORT/ICETOOL 8 Fri Dec 09, 2016 4:40 am
No new posts Limit duplicate records in the SORT pshongal SYNCSORT 6 Mon Nov 21, 2016 12:54 pm
No new posts SQZ pipe delimited file with 1 column... Rick Silvers DFSORT/ICETOOL 2 Sun Nov 06, 2016 8:11 pm
No new posts Joinkeys operation when key1 and key2... Susanta DFSORT/ICETOOL 5 Wed Nov 02, 2016 5:35 pm
No new posts How to split the records using the am... vnktrrd DFSORT/ICETOOL 24 Fri Oct 28, 2016 7:33 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us