Jump to content


Photo

Memory file conflicts

Started by Mike Nicholson, Sep 06 2006 09:41 AM

21 replies to this topic

#16 Cleve Haynes

Cleve Haynes

    Expert

  • Members
  • PipPipPipPip
  • 172 posts
  • Gender:Male

Posted 07 September 2006 - 10:29 AM

I had a little bet with myself whether it would be you or Rob that replied to this one first.

As it turns out I lost ;-)


In all fairness, Rob actually looked at it first - and was at my desk when I sent the post... So perhaps you didn't lose after all... :D

Play to Grow - Eco Educational Toys for a Magical Childhood

Educational Toys

#17 Guest_Old Fart_*

Guest_Old Fart_*
  • Guests

Posted 07 September 2006 - 11:52 AM

Old fart (what do your friends call you ?? :D )

I'm confused. How would I ALIAS a file that doesn't have a physical counterpart?

"Dear old fart".

Just specify an(other) alternate name for the memory file with ALIAS().
I'm assuming memfile names are handled like any other file (no reason why not that I can think of).
They do have a physical counterpart - in the sense of a 'named' chunk of memory in your session/process.

#18 Rick Young

Rick Young

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 265 posts
  • Gender:Male
  • Location:Guelph, Canada

Posted 07 September 2006 - 12:29 PM

PS.
As far as temporary workarounds go:
Remember background processes do not have a unique @TERM.

They do seem to have a unique @TERM, at least in the context of Bus & Tasks calls. It uses the PID (at least on the version/release/platform - 5.5r517 HPUX) I'm on.

-Rick

#19 Rob Donovan

Rob Donovan

    rob@proivrc.com

  • Admin
  • 1,647 posts
  • Gender:Male
  • Location:Spain

Posted 07 September 2006 - 01:04 PM

We change @TERM to the PID for all background processes...
devtrailer-thumbnail.jpg

 

http://www.somethingatemyalien.com

#20 Mike Nicholson

Mike Nicholson

    Expert

  • Members
  • PipPipPipPip
  • 196 posts
  • Gender:Male
  • Location:Stockholm, Sweden

Posted 08 September 2006 - 09:15 AM

As a follow up to this and after further testing ...

I'd strongly reccommend that nobody use memory files on a VMS system.

It appears that memory file add locks are being created purely based on the key value (not the file name, not the alternate name, not the field name - just the value).

This applies to at least screens and updates.

Cheers

Mike

#21 JamesS

JamesS

    Member

  • Members
  • PipPip
  • 39 posts

Posted 11 September 2006 - 10:53 AM

All,

Looks like we have a fault with the simulated add mode record locking present in PROIV's RMS file system driver. It is not going to be present in other ports.

Let me be VERY clear the data held in a memory file is not shared between processes (or thred on the windows server implementation); however the name space for add mode locking is, hence periodically you will see locks from other users.

As I recall add mode locking was put in when a certain application which relied on this feature was moved from proisam to RMS.

cheers

james

#22 Guest_Old Fart_*

Guest_Old Fart_*
  • Guests

Posted 12 September 2006 - 07:58 AM

Hello James,


Response appreciated B) just wanted to clarify a couple of things..

Memory files have nothing to do with RMS right? So there's no reason for any of that add mode trickery to be invoked presumably? And you will be putting a stop to it for memory files in a future release right? :D

Also, the behaviour (in updates at least) seemed like a read error not a lock, which of course makes it a lot more problematic.

PS. Where are you all nowadays? What happened about the buildings in Boundary Way?
Back to ProIV Bugs Confirmed

Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users


  1. ProIV Resource Centre
  2. → ProIV
  3. → ProIV Bugs
  4. → ProIV Bugs Confirmed
  5. Privacy Policy