MVSFORUMS.com Forum Index MVSFORUMS.com
A Community of and for MVS Professionals
 
 FAQFAQ   SearchSearch   Quick Manuals   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Use of READ INTO

 
Post new topic   Reply to topic   printer-friendly view    MVSFORUMS.com Forum Index -> Application Programming
View previous topic :: View next topic  
Author Message
Subzero
Beginner


Joined: 02 Dec 2002
Posts: 19
Topics: 7
Location: Chennai, India

PostPosted: Mon May 07, 2007 4:25 pm    Post subject: Use of READ INTO Reply with quote

Hi,
Can anyone tell me the practical use of READ INTO? As far as I know, it is done so that data area is moved to working storage section, which is the only section retained in a dump.

Cheers,
Subzero.
Back to top
View user's profile Send private message Send e-mail Yahoo Messenger
dbzTHEdinosauer
Supermod


Joined: 20 Oct 2006
Posts: 1411
Topics: 26
Location: germany

PostPosted: Mon May 07, 2007 5:02 pm    Post subject: Reply with quote

back in the days .... the 01 record area defined within the FD section, actually was an 'address resolved as offset within the current buffer, the assigned I/O register contained the addtress of the current buffer'. Something like that anyway. Programmers being programmers sometimes just can not stop trying slick things; screwing up a record could mess-up (often did) the block contained within the buffer. keep in mind, we are talking about machines that had 16K to 64K of memory. Last thing you did was declare redundent areas to play with records, when you could save memory and diddle in the buffer -

along came cheaper (and faster) hardware, thus enabling us dumb-dumbs to waste memory and declare a work area for the record; this was supported by extensions to language compilers with macros such as READ with the workarea option. Had to keep the option (in other words, no work area)
for those who would upgrade their operating systems

(sometimes not - around 1986 I just stopped accepting work at shops that were still running DOS)

but would not/could not afford the memory upgrade. Gradually, common sense took over (as well as ideas such as duplex, .....) and the people who paid the bills for the total IT saw that even though they may save a bit on hardware, it required a programming expertise that hard to find. Same applications that I write today (online banking and supporting applications) I used to write in the 70's on 16K machines with only two disc drives. Now with and endless supply of DASD and Virtual memory out the kazoo, things are easier to write so that someone else can follow the logic - since I don't have to worry, too much, about memory.

anyway that's my late night take on the question.

also, if you have a file - and open - during a dump, it is in there also - meaning, you can find the current record within the current buffer, by getting those addresses from the file control block which is also in the dump.

practical use would be to keep programmers out of the Record Area for a file.
_________________
Dick Brenholtz
American living in Varel, Germany
Back to top
View user's profile Send private message
CICS Guy
Intermediate


Joined: 30 Apr 2007
Posts: 292
Topics: 3

PostPosted: Tue May 08, 2007 3:47 am    Post subject: Re: Use of READ INTO Reply with quote

Subzero wrote:
Can anyone tell me the practical use of READ INTO? As far as I know, it is done so that data area is moved to working storage section, which is the only section retained in a dump.
READ INTO is just a shorthand way of doing a READ followed by a MOVE. Sometimes program logic requires records read to be in an area controlled by the program rather than the more transient I/O buffers.
Where does "the only section retained in a dump" come from?
Back to top
View user's profile Send private message
Subzero
Beginner


Joined: 02 Dec 2002
Posts: 19
Topics: 7
Location: Chennai, India

PostPosted: Tue May 08, 2007 8:36 am    Post subject: Reply with quote

It was my misconception that only working-storage area could be retained in a dump. Well that means, if we are hell-bent on saving CPU, then we could do away with all costly READ INTOs.

Thanks for your replies guys !

Cheers,
Subzero
Back to top
View user's profile Send private message Send e-mail Yahoo Messenger
dbzTHEdinosauer
Supermod


Joined: 20 Oct 2006
Posts: 1411
Topics: 26
Location: germany

PostPosted: Tue May 08, 2007 8:44 am    Post subject: Reply with quote

Subzero,

Quote:
Well that means, if we are hell-bent on saving CPU, then we could do away with all costly READ INTOs.


I do hope that was an attempt at humor.
_________________
Dick Brenholtz
American living in Varel, Germany
Back to top
View user's profile Send private message
Subzero
Beginner


Joined: 02 Dec 2002
Posts: 19
Topics: 7
Location: Chennai, India

PostPosted: Tue May 08, 2007 9:43 am    Post subject: Reply with quote

Well DBZ, I was seriously contemplating to replace READ INTOs with READs and move working-storage structure to file section to facilitate that. Since we can locate current record in FCBs, wouldn't this change help in reducing CPU?

Cheers,
Subzero
Back to top
View user's profile Send private message Send e-mail Yahoo Messenger
dbzTHEdinosauer
Supermod


Joined: 20 Oct 2006
Posts: 1411
Topics: 26
Location: germany

PostPosted: Tue May 08, 2007 10:39 am    Post subject: Reply with quote

when trying to optimize your system, unnecessary moves are on the hit list, but I would change 'READ with workarea option' last. Besides, if the READs have workarea option, the writes would be also.

Unless your total processing time is in the 'many many hours' range, the savings achieved would be negative when compared to the cost of the program changes.
also remember, somewhere, someplace, some program is saving the current-record in the work-area and doing some I/O with another structure - sometimes the record has to be moved to a work-area.

If I was tasked with saving CPU, I would start at the design level, then move into programming logic. you should also check the output of a performance analyzer. even IBM provides some performance tools, though they are pretty basic. Plus the hardware also needs to be analyzed.

you are doing READs, which tells me either qsam or vsam. either way, you probably have some legacy software, which means you have processing logic as it was written for computers 10-20 years ago. don't waste your time changing the 'work area option' for I/O.
_________________
Dick Brenholtz
American living in Varel, Germany
Back to top
View user's profile Send private message
dbzTHEdinosauer
Supermod


Joined: 20 Oct 2006
Posts: 1411
Topics: 26
Location: germany

PostPosted: Tue May 08, 2007 11:45 am    Post subject: Reply with quote

another reason, is that you can't use data elements from the File Section (record areas) as host variables in SQL.

http://www.mvsforums.com/helpboards/viewtopic.php?t=8341
_________________
Dick Brenholtz
American living in Varel, Germany
Back to top
View user's profile Send private message
Subzero
Beginner


Joined: 02 Dec 2002
Posts: 19
Topics: 7
Location: Chennai, India

PostPosted: Tue May 08, 2007 5:20 pm    Post subject: Reply with quote

To add to your point, we cannot use "EXTERNAL" data elements in File section

Cheers,
Subzero
Back to top
View user's profile Send private message Send e-mail Yahoo Messenger
Display posts from previous:   
Post new topic   Reply to topic   printer-friendly view    MVSFORUMS.com Forum Index -> Application Programming All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


MVSFORUMS
Powered by phpBB © 2001, 2005 phpBB Group