Hi Mike, I checked the documentation on the SETPTR command and I am not able to find any means for having Universe write a print job to any file other than the &HOLD& file.
I also tried to RESIZE &HOLD& to a type 18 file and it would not let me do that. I will include your comments in my comments to IBM and let you know what they say. Thanks again for your suggestions, 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 ----- Original Message ----- From: "HENDERSON MIKE, MR" <[EMAIL PROTECTED]> To: "Dave Taylor" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Sunday, November 06, 2005 11:29 AM Subject: [U2] RE: Status of an Automatic Write Action to the &HOLD& (a Type1) File - Solution Found {Unclassified} > 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/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
