HP3000-L Archives

January 2000, Week 2

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:
Stan Sieler <[log in to unmask]>
Reply To:
Stan Sieler <[log in to unmask]>
Date:
Tue, 11 Jan 2000 17:36:14 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (52 lines)
Re:
> Currently I have a COBOL program that reads through the detail dataset
> serially, once the record successfully added to the Oracle table, then the
> recorded is deleted from the Image dataset (this is a batch process).
> When
> the COBOL program reaches the end of file mark, it then starts over at the
> top of the dataset with a new serial read.  While the program is moving

It sounds like your program is a continually running program...

Why not modify the DBPUT programs to send a copy of the data to a message file,
which the COBOL program is always waiting on?  That way, you don't
have performance problems because the COBOL program is continually
re-reading the entire dataset over and over and over.  Plus, you get the
data in some kind of chronological order ... sort of.  (I.e., you have
to ask yourself: what happens if process A does:  DBPUT record A, then
gets timesliced, process B does DBPUT record B, then FWRITE B to message file,
then process A does FWRITE A to message file)  Note that the PUT A, PUT B,
WRITE B, WRITE A problem can occur no matter what kind of file you're using
(i.e., as a second file...if you're only using DBPUT and no other output
file, you're ok)   (The problem isn't an MPE problem...it could happen on
any platform.)

That PUT/WRITE chronology problem is solvable:

   FLOCK empty lock file
   DBPUT
   FWRITE to message file
   FUNLOCK

Bruce suggested writing to a flat file and doing FWRITE,6.  That addresses the
"I don't want to lose data" question, but not the chronology problem (unless
you either don't also use DBPUT, or unless you use a locking strategy like the
above)

But...the FCONTROL,6 approach has the potential of DRASTICALLY affecting
your performance.

As far as risk of losing data...you already know: you're more likely to lose
it on the other platform than on the 3000. :)

However, ask your self: what happens *today* if the system aborts while the
COBOL program is running, copying data from the IMAGE dataset over to the
other system?  Do you have a restart strategy?  A method of detecting
already processed entries?

SS


Stan Sieler                                           [log in to unmask]
www.allegro.com/sieler/wanted/index.html          www.allegro.com/sieler

ATOM RSS1 RSS2