Javascript Disabled Detected

You currently have javascript disabled. Several functions may not work. Please re-enable javascript to access full functionality.

Click the link below to see the new game I'm developing!

Memory file conflicts

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

Prev

Reply to this topic

21 replies to this topic

#16 Cleve Haynes

Expert

Members
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...

Play to Grow - Eco Educational Toys for a Magical Childhood

Educational Toys

#17 Guest_Old Fart_*

Guests

Posted 07 September 2006 - 11:52 AM

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

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

ProIV Guru

Members
266 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@proivrc.com

Admin
1,649 posts

Gender:Male
Location:Spain

Posted 07 September 2006 - 01:04 PM

We change @TERM to the PID for all background processes...

Check out our game "Something Ate My Alien"

https://store.steamp...com/app/1047870

#20 Mike Nicholson

Expert

Members
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

Member

Members
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_*

Guests

Posted 12 September 2006 - 07:58 AM

Hello James,

Response appreciated

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?

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?

Prev

Back to ProIV Bugs Confirmed

Reply to this topic

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users