UPD RE: Problem with overwriting subfile on another Vax node

Wed May 23 01:56:18 CDT 2007

This might have to do with differences in the way Quiz and QTP do their
filehandling.
It could have to do with file/record locking, see the excerpt from the
RMS manual below.

Mark

FAB$V_SQO

Local File Accesses 

Sequential only; indicates that the file can be processed only in a
sequential manner, permitting certain processing optimizations. Any
attempt to perform random access results in an error. This option is
restricted to sequential files and is ignored for all other file
organizations. The FAB$V_SQO option is input to the Create and Open
services. 

Remote DECnet Accesses 

For OpenVMS DECnet operations, this option has an added meaning. When
set for a remote file access, it indicates that file transfer mode (FTM)
should be used for Get, Put, Read, and Write services. File transfer
mode is a Data Access Protocol (DAP) feature that allows several records
to be transferred in a single-network I/O operation to maximize
throughput for sequential access file transfers. 

While the file transfer mode (FTM) feature for the SQO option is applied
regardless of file organization to remote accesses, FTM has restrictions
to make it consistent with the sequential only meaning applied to local
accesses. For a remote file access, FTM is restricted to sequential
access; if FTM is requested (FAB$V_SQO option set), a keyed or RFA
record access will fail with an RMS-F-FTM error (network file transfer
mode precludes operation (SQO set)). For record I/O, FTM is also
restricted to Gets or Puts; Updates or Deletes, if attempted, will fail
with the RMS-F-FTM error. 

The transmitting of records as a block of data, of course, results in
performance improvement; what is not as obvious is that some of the
improvement is due to the fact that the Data Access Protocol (DAP)
eliminates much of its messaging for the FTM feature. Messages are not
sent between the local and remote systems on a record-by-record basis
but rather for the whole block of records transferred. This can result
in apparent inconsistencies in what a reader sees when FTM is used. 

While the RMS default locking behavior does not change when FTM is used,
by the time the record is in your buffer on the local system, the record
may have already been updated or deleted by another process that is not
using FTM. If a locking collision happens on the remote system when the
records are being loaded into the message buffer, then the locking error
will not be returned until the end of the transfer. When using the file
transfer mode (SQO) feature with shared write access to a remote file,
you should expect to see the same kind of inconsistencies in reading
data as you see when the read-regardless (RRL) option is set. To avoid
the possibility of a hang that may be induced by retrying remote
accesses after a record lock error, you are advised to set both the
no-lock (NLK) and read-regardless (RRL) options in the RAB$L_ROP in
applications that use the file transfer mode (SQO) feature for remote
file accesses. (The no query locking (NQL) option is not supported by
the DAP protocol for remote files.) 

This option corresponds to the FDL attribute FILE SEQUENTIAL_ONLY.

________________________________

	From: powerh-l-bounces+mark.debruin=tno.nl at lists.sowder.com
[mailto:powerh-l-bounces+mark.debruin=tno.nl at lists.sowder.com] On Behalf
Of Martijn Nabben (Fairfax)
	Sent: Wednesday, May 23, 2007 01:53
	To: powerh-l at lists.sowder.com
	Subject: UPD RE: Problem with overwriting subfile on another Vax
node

	It appears, that this problem only occurs with Quiz, not QTP.
	QTP overwrites the subfile perfectly fine.

	Thanks,
	Martijn

		-----Original Message-----
		From:
powerh-l-bounces+martijn.nabben=fairfaxnz.co.nz at lists.sowder.com
[mailto:powerh-l-bounces+martijn.nabben=fairfaxnz.co.nz at lists.sowder.com
] On Behalf Of Martijn Nabben (Fairfax)
		Sent: Wednesday, 23 May 2007 11:34 a.m.
		To: 'Joe Boyle'; powerh-l at lists.sowder.com
		Subject: RE: Problem with overwriting subfile on another
Vax node

		Thanks Joe,

		That is indeed a work-around we had considered, but it
involves quite a few script changes - not to mention testing and change
control. We are aiming to simply redefine the logical without any
software changes.
		You're correct in saying, that date/time stamping would
not be necessary.

		If the PH List is unable to resolve the issue, we will
have to go down the path of deleting the subfile prior to creating it.

		Thanks,
		Martijn

			-----Original Message-----
			From: Joe Boyle [mailto:atla38 at dsl.pipex.com] 
			Sent: Wednesday, 23 May 2007 11:02 a.m.
			To: 'Martijn Nabben (Fairfax)';
powerh-l at lists.sowder.com
			Subject: RE: Problem with overwriting subfile on
another Vax node

			A work around might be to simply run a dcl
command like ' delete RPY_DATA:INC-RUNS2*.*;*' as part of the script.

			You can always date and time stamp the subfile
creation name if many processes can be running against the same subfile
at the same time - but this doesn't seem likely from your description.

________________________________

			From:
powerh-l-bounces+atla38=dsl.pipex.com at lists.sowder.com
[mailto:powerh-l-bounces+atla38=dsl.pipex.com at lists.sowder.com] On
Behalf Of Martijn Nabben (Fairfax)
			Sent: 22 May 2007 23:21
			To: 'powerh-l at lists.sowder.com'
			Subject: Problem with overwriting subfile on
another Vax node

			We are in the process of migrating a variety of
systems from Vax to Alpha.

			The plan is to do a serial migration of one
system after another.

			There are online interfaces between these
systems, where a program from the first system reads and writes subfiles
in another system's data directory.

			In order to maintain this functionality we are
currently trying to redefine the logicals to point to the data directory
on the other node. In other words defining logicals on the Alpha that
point to a data directory on the Vax:

			define RPY_DATA YAK::DKA100:[RPY.WKP.DATA]

			For reading subfiles and writing brand new
subfiles this seems to be working fine, but when overwriting an existing
subfile (using Quiz for instance), the following error occurs:

			> set subfile name rpy_data:inc-runs2 keep at
emp-id
			> go
			*W* The permanent subfile RPY_DATA:INC-RUNS2
will be cleared.
			*W* Data access error. (RPY_DATA:INC-RUNS2)
			%RMS-F-FTM, network file transfer mode precludes
operation (SQO set)

			Our Vax Systems guy has checked all necessary
access/privilege settings, but they all seem to be alright.

			Does this ring a bell with anybody? Please let
me know if you need more detailed info, that I haven't considered as
important at this stage.

			Alpha: OpenVMS V7.3-2 

			Vax: OpenVMS V7.3

			PowerHouse: 7.10G1

			Thanks,

			Martijn Nabben

			Fairfax Media, Wellington, New Zealand

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sowder.com/pipermail/powerh-l/attachments/20070523/3390be84/attachment.htm