SET PROCESS/SUSPEND - implications?

[Willem Grooters]

Suppose you have a number of processes running on a cluster, running the same program, using the same (index sequential) files, though accessing different blocks of data, so in that respect, they do not interfere. Some data read is read, altered and written back.
What will happen if all, but one, of these processes are forced into SUSPEND state and resumed when the only running process has finished?
My major concern is data ingetrity:
If a record has been read for update, and the process enters SUSPEND state before the record has been written back, can it be assured that this record cannot be accessed for update, and will rewrite, after RESUME, access the right record?

Are there other implications to reckon with?

Willem

[Uwe Zessin · Accepted solution]

I think you are safe as long as this is all synchronized by the lock manager (which it is by default).

[Robert Gezelter]

Willem,

At the risk of writing from my recollections, instead of directly checking the documentation, I will offer you the following:

- I am presuming that you are using the standard mechanisms for reading/updating records in files (e.g., RMS)
- RMS Locks the record when you do a read with the possibility of update
- SUSPEND/RESUME does not affect the RMS locks, it is at the process level.

Thus, I would suspect minimal effect. However, I would be careful of other affects. For example, if you cannot guarantee that the record streams processed are disjoint, you could lock on a record held by another (suspended) process.

I suspect that a careful reading of the RMS manual and Lock Management manual would confirm the above.

I am also making presumptions about the source codes actions, a careful check would be appropriate.

I hope that the above has been helpful.

- Bob Gezelter, http://www.rlgsc.com

[Bojan Nemec]

Willem,

The updated record must be read and locked before updating. The lock remains active even if the process is suspended. You can try this:

$ WRITE SYS$OUTPUT F$GETJPI("","PID")
yourpid
$ OPEN/READ/WRITE/SHARE F somefile
$ READ F sym

In an another process do:

$ SET PROCESS/SUSPEND/ID=yourpid
$ OPEN/READ/WRITE/SHARE F somefile
$ READ F sym
%RMS-E-RLK, target record currently locked by another stream

So the record is locked and data integrity is safe. The issue can be for the remaining process which must wait for suspended processes to unlock data.

Bojan

[Wim Van den Wyngaert]

Willem,

If you don't know the details of the application, I would not suspend a process of it.

I've seen :
1) lock / process / unlock -> suspend may block other processes processing the same data
2) programs may test time intervals and consider the interval of the suspend as too long and thus abort
3) programs may assume that they get data of other programs within seconds and if you suspend the program it may behave strangely
etc ...

Btw : this is also the case when you use sql databases. Oracle may give you "snapshot too old" because of it. It all depends of what the program is doing.

Wim

[Jan van den Ende]

Willem,

I have one other, more practical, concern.
We ARE talking RMS, yes?

- if you lock a RECORD for update, then that record is not available for updating. Period.
But... physically, this record, as well as its secondary indexes, reside on disk PAGES, that are grouped to diskpageCLUSTERS.
And those clusters are the unit of update.

Would your lock not imply that you have locked ALL records whose data or indexes coincide with the locked record?

Or does RMS have special provisions for that case? I think such a scheme may be constructed, but I do see all kind of complications....

>>>> Nice question for Hein, I guess?

Proost.

Have one on me.

jpe

[Willem Grooters]

Thanks to all.
It is plain RMS and so I can sleep well tonight (well, others will). Hopefully the processes do not interfere with the data involved. I'm not too familiar with the program but given what I heard on that, and teh parameters given to run, it _seems_ pretty unlikely. Well, if it does (and one or more instances seem to hang) it's now clear where to look and act accoringly.

Willem

PS. I keep the thread open for Hein (and others) to share his knowledge but consider the subject closed.

[Ian Miller.]

Apart from the possible blocking of access due to trying to update a record in the same bucket or parhaps due to index structure locks then its sounds ok. Justa radom thought but if you did suspended the processes using SET PROC/SUSPEND=KERNEL then this may cause more problems as this would prevent the handing of kernal mode ASTs.

[John Gillings]

Willem,

A user mode SUSPEND will be transparent with respect to any locking or process synchronization. The only issue is timing. If a process happens to be suspended while holding a lock, from another process it will just appear that the suspended process is taking a long time to execute.

There should be no data integrity issues, but, depending on the action other processes take on encountering a locked record, you might have other effects. For example, if processes wait for locks, you may get a logjam. If they retry, you may trip a sanity counter.

[Antoniov.]

Hi Willem,
I've already used set proc/susp while program locked indexed record by rms. The record is unavaiable for other processes which opened file for read and write.
However you have to remember:
- some other applications may stop waiting for record unlocking.
- programs that open with unlock can read locked record.
You can simply verify using two dcl procedures like follow.
--- 1.st ---
$ OPEN/READ/WRITE/SHARE=WRITE MY MYFILE.ISM
$ READ MY MYFILE
$ INQUIRE DUMMY "Please, suspen me!"
$ CLOSE MY
--- 2.nd ---
$ OPEN/READ/SHARE=READ MY MYFILE.ISM
$ INQUIRE DUMMY "Hit return after suspend!"
$! I can read record
$ READ MY MYFILE
$ CLOSE MY
--- 2.nd ---
$ OPEN/READ/WRITE/SHARE=WRITE MY MYFILE.ISM
$ INQUIRE DUMMY "Hit return after suspend!"
$! Now I can't read record
$ READ MY MYFILE
$ CLOSE MY

HTH
Antonio Vigliotti

[Tim Hughes_3]

You may also get some deadlock searches happening. These may get reported by some monitoring tools as a problem.

Tim