Re: Revisiting an Old Prejudice: READ INTO/WRITE FROM

From: Warren Simmons (wsimmons5_at_optonline.net)
Date: 09/07/04 

Date: Tue, 07 Sep 2004 04:47:44 GMT

Hi JOe,

I tried to point out previously why RI WF were in the COBOL system.
It was my take on it based upon the environmnet of the Univac I.
This system used a mercury delay line for memory, and there was a
totol of 1000 12 character words in which to store in and out data.
Typically, since the blocks of data were moved in batches of 60
words, a progam would assign addresses 940 to 999 as the I/O buffer
for input one. Blocks of 60 words were then assigned for any other
input or output. Soooooo
A read from tape (there was no other kind) loaded the first block
from a tape into 940. Also typically, programs were designed with
ten word records, but not always. The programmer would address the
data in 940 to 949 as the first record. If it was a tape copy, the
simplist thing one could do, that record would be memory transfered
to the output buffer's next ten words.
As it can be seen, if any relationship existed between the first
and second input record, etc. this could be done six times, and
then the whole input buffer would have to be transfered to the output
buffer.

Since very few programs were simple copy programs, some reference to
the seond etc. records might be necessary prior to the move to the
outpupt buffer, say such as a summary of like sorted data. As this
simple proceedure expanded it was possible to work programmatically
in both the input and output buffer, and that proved to be a frequent
problem, sooooo

Memory bufferes were set up in what COBOL calles Working Storage, out
side of the I/O buffers. I don't know that this was a problme in other
systems of that time, but as the short range committee all had
experience with the Univac I, I believe they set the rule about
Read Into (Y00940 Z00820) as an example. The computers I/O system
at that time (and probably still is in most systems, not part of
the programmers direct responsiblility. Such that in the illustratiion
I'm trying to make, would have the I/O system step through six records,
and without additional help, refill the input buffer with the next
block of 60 words.

Now, to clarify as much as possible, the I/O was something a programmer
copied from paper into his program, and seldom considered it except
when the size of the record changed, and then only to plug in a
different I/O program. Our early programmers had training but were
formerly tab people. It took a few years for them to grasp the
relationship between the I/O portion of their code and the part they
did.

That's a lot of words, and it isn't KISS, but it's my expaination of
why when how and where this idea came up. New hardwre, and new compilers
made a difference. I think of it as taking a record from thhe file,
working on it at my desk,then placing it in the output box. Best done
Read Into, Write From.

Forgive the verbage.

Warren Simmons

Joe Zitzelberger wrote:
> In article <nvgnj09rnukvvfmmpkhs7m899648okbvqh@4ax.com>,
> Gerry Kroll <NO.keldine@SPAM.keldine.ca.FOR.ME> wrote:
>
> <snip>
>
>>The reason for using READ INTO and WRITE FROM is nothing more than
>>*efficiency* .....
>>
>>In the bad old days, before computers became so fast, programmers
>>worried about how long their programs ran, and they tried to produce
>>programs that did their thing as accurately and as quickly as
>>possible. Believe me: It's a BIG deal when a program takes 20 minutes
>>as opposed to 15 minutes to run through a reel of tape when you're
>>dealing with 200+ reel datasets. Been there, done that.
>>
>>Now for the efficiency part: When you're working directly in a file's
>>record, each reference to a field in that record requires that the CPU
>>locates the record, loads an index register with the record location,
>>and then uses an indexed reference to the field. This takes several
>>instructions (i.e., time). If you're working with fields in Working
>>Storage, the location is static and the field can be referenced by the
>>CPU directly without involving any index registers or indexing.
>
> <snip>
>
> I'm going to have to totally disagree with you here -- at least in the
> case of IBM/z-OS machines. The compiler loading a BLF into an index
> register takes the same number of instructions as it does to load a BLW
> into an index register. Both are remote to the programs executing code
> and must be resolved at runtime.
>
> It is possible that some implementation of a Cobol compiler once messed
> up file section field references without equally messing up working
> storage field references. But that would only have made the case true
> for that specific compiler -- not as a broad, general, cross-platform
> rule.
>
> I assume, when you say 'static', you are talking about the intermixed
> code and data. Something that you could get with a NORENT, NOREUSE load
> module where declared variables are actually embedded as part of the
> executing code.
>
> I'm not sure what the very old compilers did, but all of IBMs offerings,
> at least since VS-Cobol-II (perhaps older, anyone?) have generated
> separate working storage by default with an initial getmain for the
> working storage at runtime. I'm not even sure you could get one to
> embed working storage in the load module if you tried.
>
> You are right that it is an efficiency question, but that question is
> one of Move Mode I/O verses Locate Mode I/O. Locate Mode is always
> faster, although with a record smaller than 256 bytes you would be very
> hard pressed to notice a difference.
>
> Joe Z.
>
>
>
>
> *** FWIW, the above only discusses specifics about IBM hardware/software
> with some generalities about Intel memory protection and division
> styles. I know Unisys machines can locate records anywhere, but will
> also provide the programmer with a cup of coffee and a magizine if any
> waiting is involved. However, since I've never seen one in the wild,
> I'm not really able to discuss how Unisys memory might be structured and
> protected...
>
> ;-)
>

Relevant Pages

  • Re: Questions about buffered streams
    ... Because of hard disk latency, when you do I/O, it will go faster if ... process a file buffered in convenient small logical chunks, ... The buffered classes transparently handle the physical I/O in ... Unless the buffer size for the physical I/O is at least twice as big ...
    (comp.lang.java.programmer)
  • Re: pushing the envelope with sockets
    ... so it would seem 2.0 does indeed buffer UDP. ... Using async I/O ... receiving on the socket they are received, ... Okay, so during *one* run, the cpu spent increases when input-data is ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Patch for Retry based AIO-DIO (Was AIO and DIO testing on 2.6.0-test7-mm1)
    ... try and hit the AIO verses buffered read race conditions. ... non zero buffer at buf-> 0xaaaaaaaa,aaaaaaaa,aaaaaaaa,aaaaaaaa ... > falling back to buffered i/o. ...
    (Linux-Kernel)
  • Re: Buffered socket I/O with sysread-style blocking?
    ... I/O if you don't want it to actually do buffering? ... What I want to do is read and process the data as it comes in, rather than wait for the whole resource to download, or even wait for a whole buffer block. ... HTTP is an odd case in that an HTTP message starts with textual line-oriented data, and then changes to potentially binary data. ...
    (comp.lang.perl.misc)