"STRANGE" BEHAIVIOR

[Deskin, Bob]

I thought about this behaviour and I believe it is correct. The record
status reflects that difference between the buffers and what's on disk (as
far as QUICK knows). It has nothing to do with whether the file's open or
closed. If you close a file, you don't necessarily re-initialize the buffers
or the record status. I think this highlights the need for a RESET verb that
initializes the buffers and resets the record status. We've all been using
the GETfile OPTIONAL workaround for a long time. While I can't promise
anything, I do know that it's on the list (but it's a long list).

Bob Deskin              
Senior Product Advisor  bob.deskin@cognos.com
Cognos Inc.             (613) 738-1338 ext 4205 FAX: (613) 228-3149
3755 Riverside Drive P.O. Box 9707 Stn. T, Ottawa ON K1G 4K9 CANADA

> -----Original Message-----
> From:	Kogan, Arthur [mailto:akogan@westpac.com.au]
> Sent:	Sunday, February 28, 1999 8:52 PM
> To:	Hamilton, Allison; Deskin, Bob
> Cc:	'powerh-l@lists.swau.edu'
> Subject:	RE: "STRANGE" BEHAIVIOR
> 
> Hi Bob, Allison.
> 
> Thanks a lot for your ideas.
> 
> Bob, I was very careful about closing the file everywhere it was
> appropriate.
> 
> Allison, I am dealing with fixed length records.
> 
> I was thinking about it all weekend and I finally come up with a simple
> solution.
> 
> The problem was as I suspected.
> 
> When my designer procedure hit an error, it was in the middle of a while
> retrieving loop reading records from my temporary file. It has just
> successfully read a record and set the file buffer flags accordingly. Now,
> before flagging the error, I close the file. I thought that this action
> would reset any buffer flags, set by the previous successful read. But it
> appears that it does not. So, when I create my new temporary file, and try
> to write a new record to this empty file, because the buffer flags still
> contain the values from the last successful read of the file, PH thinks
> that I am trying to change/update previously read record and gives me the
> error "record has changed since you last found it".
> 
> The solution I came up with is prior to the first write, I do a get <file>
> optional. Now, since my new file is empty at this time, I get an
> unsuccessful read, which resets the buffer flags appropriately, so that
> when I try to write, PH sees this correctly as writing a new record.
> 
> This was really a curly one.
> 
> Regards and thanks again,
> 
> Arthur Kogan
> Westpac Financial Services
> Sydney, Australia
>   
> 
> 	-----Original Message-----
> 	From:	Hamilton, Allison [SMTP:Allison.Hamilton@Cognos.COM]
> 	Sent:	Saturday, 27 February 1999 1:48 AM
> 	To:	Deskin, Bob; 'Arthur Kogan'
> 	Cc:	'powerh-l@lists.swau.edu'
> 	Subject:	RE: "STRANGE" BEHAIVIOR
> 
> 	Arthur - is your temporary file variable length, perchance???  If
> so, I
> 	suspect that the problem may be due to a couple of variable length
> record
> 	issues we've found lately with both PH 8 and 7 versions in similar
> 	scenarios.  These problems should be corrected to the best of our
> knowledge
> 	in 710G2.  (251425, 248103 are related problems - your scenario is
> similar
> 	to 248103 - except that it was with mailboxes, but a mailbox is just
> a
> 	variable length virtual file - in this case also, the scenario
> worked every
> 	other time, the problem happens when you go from a shorter length
> record to
> 	a longer record)
> 
> 	Hope that helps.
> 	Allison Hamilton
> 
> 	> ----------
> 	> From: 	Arthur Kogan[SMTP:akogan@westpac.com.au]
> 	> Sent: 	Friday, February 26, 1999 1:40 AM
> 	> To: 	Deskin, Bob
> 	> Cc: 	'powerh-l@lists.swau.edu'
> 	> Subject: 	"STRANGE" BEHAIVIOR
> 	> 
> 	> Hi Bob,
> 	> 
> 	> I think this one requires your "deep" knowledge of PH to explain.
> 	> 
> 	> I am working on a quite complex screen and have hit a problem,
> which I can
> 	> not
> 	> readily explain (which is concerning in it self!!!). I am using
> PH710F4 on
> 	> Alpha VMS with RMS files.
> 	> 
> 	> In my screen after "finding" a primary record, I run a designer
> procedure.
> 	> The
> 	> designer procedure:
> 	> 
> 	> 1. sets a system variable with the name of my temporary data file,
> using
> 	> setsystemvalue function.
> 	> 2. runs command to create the empty file, using "create/fdl=..."
> command.
> 	> This
> 	> is an indexed RMS file.
> 	> 3. writes some records to this file, using "put <filename> reset".
> It
> 	> writes
> 	> new records only.
> 	> 4. reads this file during further processing and displays some
> values on
> 	> the
> 	> screen.
> 	> 5. closes the temporary file.
> 	> 
> 	> I have been careful to put close file statement just before
> flagging any
> 	> error
> 	> messages occurring after the first write to the file, within this
> designer
> 	> procedure, as in this case the execution of the procedure stops at
> the
> 	> error
> 	> message and does not continue to step 5.
> 	> 
> 	> The problem occurs when after running the designer procedure once,
> I run
> 	> it
> 	> again without re-finding the primary record or updating (if I do
> either of
> 	> those, there is no problem). The original error message I was
> receiving
> 	> was an
> 	> RMS error about "bucket format check failed". After digging
> dipper, I got
> 	> the
> 	> Powerhouse error "record has changed since you last found it" on
> the first
> 	> write to the new temporary file.
> 	> 
> 	> This has got me thinking, that although I am trying to write "new"
> records
> 	> to
> 	> the "new" empty file, because I have not done a find or update, PH
> thinks
> 	> that
> 	> I am writing an updated version of the last read record. To test
> this, I
> 	> changed my "put <filename> reset" command to "put NEW <filename>
> reset".
> 	> This
> 	> time I got no error, but NO records were written to the file. Note
> also
> 	> that
> 	> the error only occurs every second time, i.e. if after finding the
> primary
> 	> record, I run the designer procedure 6 times, the error will occur
> only
> 	> the
> 	> second, fourth and sixth time.
> 	> 
> 	> Now, I think I can guess that the problem here is that the record
> status
> 	> flag
> 	> does not get reset, so the screen thinks I want to update instead
> of
> 	> adding a
> 	> new record. The question is how can I force this to happen? If I
> can not
> 	> get
> 	> this to work this way, I guess, I can change the screen to run the
> 	> designer
> 	> procedure from POSTFIND, so it can only be run after the user does
> a find,
> 	> but
> 	> I would really like to get this to work according to the original
> design.
> 	> 
> 	> Please help/explain/confirm my guess.
> 	> 
> 	> Regards,
> 	> 
> 	> Arthur Kogan
> 	> Westpac Financial Services
> 	> Sydney, Australia
> 	> 
> 	> = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> = = = =
> 	> =
> 	> Subscribe: "subscribe powerh-l" in message body to
> 	> majordomo@lists.swau.edu
> 	> Unsubscribe: "unsubscribe powerh-l" in message to
> majordomo@lists.swau.edu
> 	> powerh-l@lists.swau.edu is gatewayed one-way to
> bit.listserv.powerh-l
> 	> This list is closed, thus to post to the list, you must be a
> subscriber.
> 	> 
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.