PowerHouse -- FSERR 179

Peter Bateman shediac92@hotmail.com
Sat, 10 May 2003 10:02:08 -0300


Leonard:

Powerhouse should lock a KSAM before reading it.

>From the Using KSAM-XL manual:

"Shared File Access

If only one process is accessing a file, setting a pointer and reading a
record in a two-step process does not present a problem. Shared file
access, however, presents potential retrieval contention. If a pointer
is positioned to retrieve a particular record by one process, another
process could modify or delete the record before the original process
reads it. The FLOCK and FUNLOCK intrinsics should be used to ensure
proper record retrieval in any program that allows shared access to
its file."



  I have seen situations where customers were using their own 3GL subprgram 
accessing a native
  mode KSAM file and getting this kind of problem with QUICK.

  That recompiling cause the problem to go away indicates to me that 
something has changed
  from the last compilation.


  Possible changes:- Version of PowerHouse, Patch level of MPE/iX,Corrupted 
QUICK binary, etc.
A file equation for the keyed subfile could cause this problem.
e.g. File UNCMPK ... NOLOCK


Regards,
Peter Bateman


>From: Leonard_Berkowitz@harvardpilgrim.org
>To: powerh-l@lists.swau.edu
>Subject: (no subject)
>Date: Fri, 9 May 2003 14:40:49 -0400
>
>MPE/iX 6.5 PowerHouse 8.19C
>
>Here is a screen error in trying to access an indexed subfile (file 
>code=644; TYP=FAK):
>
>MODE:F ACTION:F                Mass UnComp Care             AAC136K2
>05/09/03
>OP#: SWM5433                   UNCOMPAM.PHCDBASE            V 1.0      
>14:27
>
>                   R,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,T
>                   . Ambulatory & Surgical Center Providers .
>                   F,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,G
>
>01 Irs#
>02 Provider
>03 Op#
>04 Ymdtrans
>
>Data access error. (UNCOMPAM*01)
>THE FILE MUST BE LOCKED BEFORE ISSUING THIS INTRINSIC  (FSERR 179)
>
>We recompiled the screen and the error disappeared. Why is that the case? 
>How could we have avoided
>the problem in the first place? What intrinsic might require locking in the 
>FIND PROCEDURE? This
>file is the only file used by this screen.
>
>Thanks in advance.
>--
>Leonard S. Berkowitz
>Perot Health Care Systems
>(Harvard Pilgrim Health Care account)
>voice: 617-509-1212
>fax: 617-509-1955
>pager: 781-226-2431
>
>The information contained in this email message and any attachments
>may be privileged and/or confidential.  It is for intended
>addressee(s) only.  If you are not the intended recipient, you are
>hereby notified that any review, disclosure, reproduction, distribution
>or other use of this communication is strictly prohibited.  If you
>received this email in error, please notify the sender by reply and
>delete the message without saving, copying or disclosing it.  Thank you.
>
>= = = = = = = = = = = = = = = = = = = = = = = = = = = =
>Mailing list: powerh-l@lists.swau.edu
>Subscribe: "subscribe" in message body to powerh-l-request@lists.swau.edu
>Unsubscribe: "unsubscribe <password>" in message body to 
>powerh-l-request@lists.swau.edu
>http://lists.swau.edu/mailman/listinfo/powerh-l
>This list is closed, thus to post to the list you must be a subscriber.

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*   
http://join.msn.com/?page=features/junkmail