HP3000-L Archives

April 1996, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Mark Landin <[log in to unmask]>
Reply To:
Mark Landin <[log in to unmask]>
Date:
Wed, 17 Apr 1996 14:18:55 GMT
Content-Type:
text/plain
Parts/Attachments:
text/plain (61 lines)
In article <[log in to unmask]>, Ken Hirsch <[log in to unmask]>
says:
>
>Mark Landin ([log in to unmask]) wrote:
>: Is there an example of how to do mapped file access in COBOL
>: floating around on the net somewhere? I'd like to play around with
>: it.
>
> [sneaky COBOL trick deleted]
>
>If the mapped file does actual disk I/O, Scott Gavin is right that
>mapped-access is not much faster.  However, if the file is present in
>memory, mapped-file access is MUCH faster.
>
>You still must handle EOF via intrinsics.  And, if more than one process
>accesses the file at the same time, you still must contol access
>somehow.
 
 
Some people are curious as to why I'm curious about this.
 
My application is that of a globally shared data concept. That is,
one particular process determines a set of control information, which
must be passed along to multiple other processes which are not in
the master process' family.
 
Currently, our 200+ users are all running a process which reads an
IMAGE dataset for some control information (a couple of hundred records
in a serial read), and formats the data into a table for later use.
We re-read this dataset everytime we enter this particular screen,
and sometimes even when we stay on this screen but change certain
important fields. All in all, it's a lot of disk I/O throughout the
day that I would like to reduce. A couple of hundred records doesn't
seem like much, but multiplied by 200 users times 200 times entering
the screen, it adds up.
 
It seems redundant to have so many people doing exactly the same
thing over and over again. My idea was to have a master process read
the dataset at a set interval (maybe once every 2 or 3 minutes),
format the records into the table which the other processes will use,
and then provide that information to the other processes on demand.
 
If I could do this with a static memory object floating around in the
system somewhere, that would be great. The alternative I hit upon was
to write the formatted data into a flat file and let the other processes
read it instead of the IMAGE dataset. I thought mapped files might be
useful since the file will look just like the table I need to populate,
and I heard it could be faster than the OPEN/READ/WRITE cycle.
 
So what I would have is one process writing to the mapped file, and
hundreds of processes reading the mapped file simultaneously.
 
So does this sound like a reasonable solution? If I could treat
everything as just a truly global memory object, that would be best.
Mapped files looked like the next best thing (if not the ONLY thing).
 
--
Mark Landin                                "If you choose not to decide,
Systems Manager                             you still have made a choice"
Superstar Satellite Entertainment            -Neil Peart, RUSH

ATOM RSS1 RSS2