Dave,
In my view the behaviour you are trying to program around is absolutely
positively a bug, in fact a rather nasty one.
I am, like you, amazed that UniVerse will let two UV programs
simultaneously access the same incompletely-written record. Actually,
'appalled' would be closer than 'amazed'!
Whilst your problem is with &HOLD&, I don't see that it would
necessarily be any different with any other sort of large write to a
Type 1 or 18 file.
It would be very interesting to know if the same behaviour is exhibited
if:
* &HOLD& is re-created (RESIZEd) as Type 18 instead of Type 1
I expect it would - I think the UV Developers just completely
overlooked this
* the scenario is repeated on a Linux / Unix system
I expect it wouldn't
Thanks for the research.
Regards
Mike
________________________________
From: Dave Taylor [mailto:[EMAIL PROTECTED]
Sent: Saturday, 5 November 2005 14:54
To: Allen Elwood; [EMAIL PROTECTED]; David Jordan;
Jan Oliver; Kevin King; HENDERSON MIKE, MR; Ray Methvin; Tim Stokes
Subject: Status of an Automatic Write Action to the &HOLD& (a
Type1) File - Solution Found
All,
First, thank you for your individual suggestions.
I have found a solution to the problem that I am willing to
implement but am not happy with and I would like to share it with you in
the event that it may be useful to you in the future.
To restate the problem: it revolves around a Pick-like spooler
module, SpoolerPlus, that we have developed on Universe on NT Rel
10.0.10 and are beta testing at a customer site on Universe on NT Rel
10.1.11
SpoolerPlus uses the Universe SETPTR command with Mode 3 and the
BANNER NEXT option to instruct Universe to *automatically* write print
jobs to the &HOLD& file (a Type 1 file) with a pre-defined record ID
plus a sequential no. for record ID differentiation.
The (phantom) SPOOLING program in SpoolerPlus then reads the
&HOLD& file and writes each record in it to a separate HOLD.FILE file (a
Type 18 file) for spooler handling and printing.
When the print job being written to the &HOLD& file by Universe
is large, Universe allows the SPOOLING program to read the record from
the &HOLD& file before Universe has completely written all the data in
the print job into that record in the &HOLD& file. This results in loss
of data in the print job record which the SPOOLING program writes to the
HOLD.FILE file and subsequently processes.
In addition, following the READ from &HOLD&, we WRITE to
HOLD.FILE and then DELETE &HOLD&. If the Universe WRITE function has
not been completed, the DELETE statement fails to delete the record in
&HOLD& and generates an Operating System error that kills the SPOOLING
program.
The SPOOLING program needs to wait until the record is
completely written to the &HOLD& file to avoid writing an incomplete
record to the HOLD.FILE file and enabling a DELETE statement that
results in an fatal error.
Therefore, the SPOOLING program needs to determine when the
writing of the record to the &HOLD& file has been completed so it can
then READ the record written, but not before all the data in the record
has been written.
We tried many alternatives to determine when Universe has
completed the write function to the &HOLD& file.
We tried to read the &HOLD& file with READ, READU and READSEQ to
see of Universe would stop us from reading a partially written record,
and it did not.
We tried writing to the &HOLD& file with WRITE, WRITEU and
WRITEBLK to see if Universe would stop us from destroying the record as
it was being written to the &HOLD& file, and it did not.
In fact we succeeded in writing text not related to the print
job in any way into the middle of the &HOLD& file print job record while
additional data continued to be written into the record by Universe
following the text that we wrote, completely destroying the integrity of
the record.
I am surprised that Universe will even allow us to READ or READU
or READSEQ a record from the &HOLD& file before that record has been
written completely to the file, but it does.
I am amazed that Universe will allow us to WRITE, WRITEU and
WRITEBLK text into the record from the &HOLD& file before it has been
written completely to the file, but it does.
The only action that Universe will not allow me to take to
completely destroy this record as it is being written into the &HOLD&
file by Universe is to DELETE it, for which I deeply grateful.
So, we have temporarily solved this problem by resequencing our
process. We now READ the record from &HOLD&, WRITE the record to a
temporary file (SLUDGE) and then DELETE the record from &HOLD&, and then
decide what to do.
If we can DELETE the record from &HOLD&, we WRITE it to the
HOLD.FILE and DELETE (the temporary copy of it from) SLUDGE. It's
already been DELETEd from &HOLD&.
If we can *not* DELETE the record from &HOLD&, we extend the
record ID to SID by concatenating DATE and TIME, null contents of the
record and WRITE SID to SLUDGE and DELETE ID from SLUDGE, creating a
history of read/delete attempts that failed, for diagnostic purposes.
We then continue to process the next record in the &HOLD& file.
When the SPOOLING program wakes up the next time (whatever SLEEP
is set to) it will again attempt to process the print job that was still
being written during its last pass, along with any other print jobs that
have been or are being written into &HOLD& by Universe.
So far, this has worked correctly in alpha testing and we put it
into beta testing at the customer site yesterday, so we'll see.
What I don't like about this solution is the possibility
suggested by Allen H. that the READ from &HOLD& could occur before the
record has been written completely, but that the record could have been
written completely after the READ and before the DELETE &HOLD& step that
immediately follows, a very short period of time admittedly. This,
however, would allow us to read a partial record and then delete the
entire record from &HOLD& and then process a partial record, which we
would never know about.
The time frame for this anomaly to occur may be very small and
the probability miniscule, but it is a concern in any case.
If you come across any ideas in the future that will allow us to
tighten this up, we will be most grateful.
If you believe that the ability to alter and/or destroy the
contents of a print job while it is being written into the &HOLD& file
by Universe is a serious design deficiency/bug as I do, please share
your thoughts with me that I can pass on to IBM (with or without
attribution) along with my own.
Thank you again for your assistance and for your continuing
support of the U2-list.
I hope I can return the favor some day.
Best regards,
Dave
Dave Taylor
President
Sysmark Information Systems, Inc.
49 Aspen Way
Rolling Hills Estates, CA 90274
800-SYSMARK (800-797-6275)
(O) 310-544-1974
(P) 800-339-1497
(F) 310-377-3550
Your Source for Integrated EDI Translation and DataSync
Integration
www.sysmarkinfo.com
The information contained in this Internet Email message is intended
for the addressee only and may contain privileged information, but not
necessarily the official views or opinions of the New Zealand Defence Force.
If you are not the intended recipient you must not use, disclose, copy or
distribute this message or the information in it.
If you have received this message in error, please Email or telephone
the sender immediately.
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
