OpenVMS Alpha Guide to Upgrading Privileged-Code Applications

Document revision date: 30 March 2001

OpenVMS Alpha Guide to Upgrading Privileged-Code Applications

Contents

Index

A.9 I/O Request Packet Extension (IRPE)

This section describes the additions and changes to cells in the I/O Request Packet Extension (IRPE) structure. An IRPE structure can contain additional driver-specific information that needs to be associated with an IRP. It can also be used to manage additional buffers that are locked down for direct I/O.

If the IRP$M_EXTEND bit is set in irp$l_sts then the irp$l_extend cell contains a pointer to an associated IRPE structure. Similarly, if the IRPE$M_EXTEND bit is set in the irpe$l_sts cell, then the irpe$l_extend cell contains a pointer to another IRPE. In general, if there is an IRPE cell with the name irpe$X and an IRP cell with the name irp$X , then the cells must be at the same offsets such that the IRP and the IRPE can be used interchangeably in contexts that depend only on these common cells.

Currently, a single IRPE structure can be used to keep track of two separate regions of locked down pages. The new IRPE structure can only manage a single region of locked down pages and contains a single fixed-size primary DIOBM structure for that purpose (see Table A-10).

Table A-10 IRPE Changes
Field Type Comments

irpe$b_rmod unsigned char Requestor's access mode. This corresponds to the irp$b_rmod cell. The space for this IRPE cell was reserved but the cell was not previously formally defined. The addition of this cell facilitates the usage of an IRPE with the EXE_STD$READLOCK routines because the irpe$b_rmod cell is one of the required implicit inputs.

irpe$l_oboff unsigned int Original byte offset into first page for buffer locked into memory. This corresponds to the irp$l_oboff cell that was added to the IRP on OpenVMS Alpha but was not formally defined in the IRPE. This corrects that omission.

irpe$q_driver_p0 int64 Available for use by driver. This cell is overlaid on what was previously filler space.

irpe$l_driver_p0 int Available for use by driver. This cell is overlaid on the low-order 32-bits of irpe$q_driver_p0 .

irpe$l_driver_p1 int Available for use by driver. This cell is overlaid on the high-order 32-bits of irpe$q_driver_p0 .

irpe$q_driver_p2 int64 Available for use by driver. This cell is overlaid on what was previously filler space.

irpe$l_driver_p2 int Available for use by driver. This cell is overlaid on the low-order 32-bits of irpe$q_driver_p2 .

irpe$l_driver_p3 int Available for use by driver. This cell is overlaid on the high-order 32-bits of irpe$q_driver_p2 .

irpe$pq_va_pte PTE_PQ A 64-bit pointer to the actual PTEs that map the user buffer. If the user buffer is not in shared system space, then this PTE virtual address is only valid in the caller's process context.

irpe$l_svapte PTE * A 32-bit pointer to a copy of the PTEs that map the user buffer. If zero, then no PTEs have been locked for this request. This cell replaces the irpe$l_svapte1 cell.

irpe$l_svapte1 - This cell has been removed. It is replaced by the irpe$l_svapte cell.

irpe$l_bcnt unsigned int Byte count for buffer locked into memory. This cell replaces the irpe$l_bcnt1 cell.

irpe$l_bcnt1 - This cell has been removed. It is replaced by the irpe$l_bcnt cell.

irpe$l_boff unsigned int Byte offset into first page for buffer locked into memory. This cell replaces the irpe$l_boff1 cell.

irpe$l_boff1 - This cell has been removed. It is replaced by the irpe$l_boff cell.

irpe$r_diobm DIOBM Embedded fixed-size primary "direct I/O buffer map" structure. This embedded DIOBM structure is valid if and only if the irpe$l_svapte cell contains a non-zero value. See Section A.6 for a complete description of the DIOBM structure.

irpe$l_svapte2 - This cell has been removed. It was used to contain a pointer to the first PTE for a second buffer that was locked into memory. If zero, then there was no second buffer.

irpe$l_bcnt2 - This cell has been removed. It was used for the byte count for the second buffer locked into memory.

irpe$l_boff2 - This cell has been removed. It was used for the byte offset for the second buffer locked into memory.

**Table A-10 IRPE Changes**
Field	Type	Comments
irpe$b_rmod	unsigned char	Requestor's access mode. This corresponds to the `irp$b_rmod` cell. The space for this IRPE cell was reserved but the cell was not previously formally defined. The addition of this cell facilitates the usage of an IRPE with the EXE_STD$READLOCK routines because the `irpe$b_rmod` cell is one of the required implicit inputs.
irpe$l_oboff	unsigned int	Original byte offset into first page for buffer locked into memory. This corresponds to the `irp$l_oboff` cell that was added to the IRP on OpenVMS Alpha but was not formally defined in the IRPE. This corrects that omission.
irpe$q_driver_p0	int64	Available for use by driver. This cell is overlaid on what was previously filler space.
irpe$l_driver_p0	int	Available for use by driver. This cell is overlaid on the low-order 32-bits of `irpe$q_driver_p0` .
irpe$l_driver_p1	int	Available for use by driver. This cell is overlaid on the high-order 32-bits of `irpe$q_driver_p0` .
irpe$q_driver_p2	int64	Available for use by driver. This cell is overlaid on what was previously filler space.
irpe$l_driver_p2	int	Available for use by driver. This cell is overlaid on the low-order 32-bits of `irpe$q_driver_p2` .
irpe$l_driver_p3	int	Available for use by driver. This cell is overlaid on the high-order 32-bits of `irpe$q_driver_p2` .
irpe$pq_va_pte	PTE_PQ	A 64-bit pointer to the actual PTEs that map the user buffer. If the user buffer is not in shared system space, then this PTE virtual address is only valid in the caller's process context.
irpe$l_svapte	PTE *	A 32-bit pointer to a copy of the PTEs that map the user buffer. If zero, then no PTEs have been locked for this request. This cell replaces the `irpe$l_svapte1` cell.
irpe$l_svapte1	-	This cell has been removed. It is replaced by the `irpe$l_svapte` cell.
irpe$l_bcnt	unsigned int	Byte count for buffer locked into memory. This cell replaces the `irpe$l_bcnt1` cell.
irpe$l_bcnt1	-	This cell has been removed. It is replaced by the `irpe$l_bcnt` cell.
irpe$l_boff	unsigned int	Byte offset into first page for buffer locked into memory. This cell replaces the `irpe$l_boff1` cell.
irpe$l_boff1	-	This cell has been removed. It is replaced by the `irpe$l_boff` cell.
irpe$r_diobm	DIOBM	Embedded fixed-size primary "direct I/O buffer map" structure. This embedded DIOBM structure is valid if and only if the `irpe$l_svapte` cell contains a non-zero value. See Section A.6 for a complete description of the DIOBM structure.
irpe$l_svapte2	-	This cell has been removed. It was used to contain a pointer to the first PTE for a second buffer that was locked into memory. If zero, then there was no second buffer.
irpe$l_bcnt2	-	This cell has been removed. It was used for the byte count for the second buffer locked into memory.
irpe$l_boff2	-	This cell has been removed. It was used for the byte offset for the second buffer locked into memory.

A.10 Process Header (PHD)

This section describes the I/O-specific additions to cells in Process Header (PHD) structure (see Table A-11).

Table A-11 PHD Structure Changes
Field Type Comments

phd$l_iorefc uint32 Number of reasons to keep the PHD resident due to groups of pages locked for direct I/O. This count is incremented by MMG_STD$IOLOCK_BUF and decremented by MMG_STD$IOUNLOCK_BUF. On the zero-to-one transition of this cell, the slot reference count for the process in the PHV$GL_REFCBAS_LW vector is incremented. On the one-to-zero transition of this cell, the slot reference count for the process in the PHV$GL_REFCBAS_LW vector is decremented.

**Table A-11 PHD Structure Changes**
Field	Type	Comments
phd$l_iorefc	uint32	Number of reasons to keep the PHD resident due to groups of pages locked for direct I/O. This count is incremented by MMG_STD$IOLOCK_BUF and decremented by MMG_STD$IOUNLOCK_BUF. On the zero-to-one transition of this cell, the slot reference count for the process in the PHV$GL_REFCBAS_LW vector is incremented. On the one-to-zero transition of this cell, the slot reference count for the process in the PHV$GL_REFCBAS_LW vector is decremented.

A.11 SCSI-2 Diagnose Buffer (S2DGB)

For information about S2DGB 64-bit addressing support, see the OpenVMS Alpha Guide to 64-Bit Addressing and VLM Features².

Note

² This manual has been archived but is available on the OpenVMS Documentation CD-ROM. This information has also been included in the OpenVMS Programming Concepts Manual, Volume I.

A.12 VMS Communications Request Packet (VCRP)

The VCRP structure is the VMS Communications Request Packet that is used by the OpenVMS LAN driver VMS Communications Interface (VCI). A VCRP is used to transfer data between an upper- and lower-level VCM.

The VCRP is designed so that it can be used as an ACB by an upper-level VCM. Therefore, the VCRP has been enhanced such that it can be used either as an ACB or ACB64 structure by an upper-level VCM. This allows upper-level VCMs the flexibility of providing 64-bit AST support at some time in the future without requiring another VCRP change and the forced recompilation of all VCMs (see Table A-12).

Table A-12 VCRP Structure Changes
Field Type Comments

vcrp$v_acb_flags_valid bit This is a new bit in the vcrp$b_rmod cell that corresponds to the acb$v_flags_valid bit. This bit is available for the exclusive use of upper-level VCMs.

vcrp$l_acb64x_offset int Offset to the ACB64X structure embedded in this VCRP. This cell corresponds to the acb$l_acb64x cell and is overlaid on vcrp$l_ast . This cell is available for the exclusive use of upper-level VCMs.

vcrp$l_acb_flags unsigned int This cell corresponds to the acb$l_flags cell and is overlaid on the first longword of the existing fork block filler space in the VCRP. This cell is available for the exclusive use of upper-level VCMs.

vcrp$l_thread_id int This cell corresponds to the acb$l_thread_pid cell and is on the second longword of the existing fork block filler space in the VCRP. Reserved for use by the Kernel Threads project.

vcrp$pq_acb64_ast VOID_FUNC_PQ This cell corresponds to the acb64$pq_ast cell. This cell is available for the exclusive use of upper-level VCMs.

vcrp$q_acb64_astprm int64 This cell corresponds to the acb64$q_astprm cell. This cell is available for the exclusive use of upper-level VCMs.

vcrp$q_user_thread_id uint64 Unique user thread identifier. Corresponds to the acb64$q_user_thread_id cell. This cell is available for the exclusive use of upper-level VCMs.

vcrp$pq_buffer_addr64 VOID_PQ 64-bit buffer address. This cell is available for use by upper-level VCMs only. Note that this cell does not replace the vcrp$l_buffer_address cell which continues to be used by lower-level VCMs.

vcrp$r_diobm DIOBM Embedded fixed-size primary "direct I/O buffer map" structure. This DIOBM structure is available for use by upper-level VCMs that need to lock down a buffer and provide a value for the vcrp$l_svapte cell.

vcrp$t_internal_stack char[220] This existing internal stack area of 92 bytes has been increased to 220 bytes to reflect the increased size of a DCBE. SYS$PEDRIVER requires that it can place a DCBE within this stack area. This space is available for the exclusive use of upper-level VCMs.

**Table A-12 VCRP Structure Changes**
Field	Type	Comments
vcrp$v_acb_flags_valid	bit	This is a new bit in the `vcrp$b_rmod` cell that corresponds to the `acb$v_flags_valid` bit. This bit is available for the exclusive use of upper-level VCMs.
vcrp$l_acb64x_offset	int	Offset to the ACB64X structure embedded in this VCRP. This cell corresponds to the `acb$l_acb64x` cell and is overlaid on `vcrp$l_ast` . This cell is available for the exclusive use of upper-level VCMs.
vcrp$l_acb_flags	unsigned int	This cell corresponds to the `acb$l_flags` cell and is overlaid on the first longword of the existing fork block filler space in the VCRP. This cell is available for the exclusive use of upper-level VCMs.
vcrp$l_thread_id	int	This cell corresponds to the `acb$l_thread_pid` cell and is on the second longword of the existing fork block filler space in the VCRP. Reserved for use by the Kernel Threads project.
vcrp$pq_acb64_ast	VOID_FUNC_PQ	This cell corresponds to the `acb64$pq_ast` cell. This cell is available for the exclusive use of upper-level VCMs.
vcrp$q_acb64_astprm	int64	This cell corresponds to the `acb64$q_astprm` cell. This cell is available for the exclusive use of upper-level VCMs.
vcrp$q_user_thread_id	uint64	Unique user thread identifier. Corresponds to the `acb64$q_user_thread_id` cell. This cell is available for the exclusive use of upper-level VCMs.
vcrp$pq_buffer_addr64	VOID_PQ	64-bit buffer address. This cell is available for use by upper-level VCMs only. Note that this cell does not replace the `vcrp$l_buffer_address` cell which continues to be used by lower-level VCMs.
vcrp$r_diobm	DIOBM	Embedded fixed-size primary "direct I/O buffer map" structure. This DIOBM structure is available for use by upper-level VCMs that need to lock down a buffer and provide a value for the `vcrp$l_svapte` cell.
vcrp$t_internal_stack	char[220]	This existing internal stack area of 92 bytes has been increased to 220 bytes to reflect the increased size of a DCBE. SYS$PEDRIVER requires that it can place a DCBE within this stack area. This space is available for the exclusive use of upper-level VCMs.

Appendix B
I/O Support Routine Changes

This appendix contains detailed descriptions of the changes to I/O support routines and the new I/O support routines that are available to enhance device drivers to support 64-bit addresses.

The routines are listed in alphabetical order.

B.1 ACP_STD$READBLK and ACP_STD$WRITEBLK

The routines ACP_STD$READBLK and ACP_STD$WRITEBLK are upper-level FDT routines, so their interfaces remain unchanged:

int acp_std$readblk (IRP *irp, PCB *pcb, UCB *ucb, CCB *ccb) int acp_std$writeblk (IRP *irp, PCB *pcb, UCB *ucb, CCB *ccb)

These routines obtain the address of the caller's buffer from irp->irp$l_qio_p1 . These routines have been modified to obtain the full 64-bit buffer address from irp->irp$q_qio_p1 and pass it to EXE_STD$READLOCK or EXE_STD$WRITELOCK. Note, however, that the buffer size remains a longword and is obtained from irp->irp$l_qio_p2 without checking the upper 32-bits.

B.2 EXE_STD$ALLOC_BUFIO_32, EXE_STD$ALLOC_BUFIO_64

Routines EXE_STD$ALLOC_BUFIO_32 and EXE_STD$ALLOC_BUFIO_64 are new routines that device drivers can use to allocate and initialize simple buffered I/O (BUFIO) packets. The appropriate IRP and BUFIO header cells are initialized but it is up to the caller to copy any data into the packet.

The interfaces for these routines are:

int exe_std$alloc_bufio_32 (IRP *irp, PCB *pcb, void *uva, int pktsiz) int exe_std$alloc_bufio_64 (IRP *irp, PCB *pcb, VOID_PQ uva, int pktsiz)

Table B-1 summarizes the use of the arguments.

Table B-1 EXE_STD$ALLOC_BUFIO_32, EXE_STD$ALLOC_BUFIO_64 Arguments
Argument Type Access Description

irp IRP * Input Pointer to the current IRP.

pcb PCB * Input Pointer to the process PCB.

uva VOID_PQ Input User virtual address, EXE_STD$ALLOC_BUFIO_64

void * Input User virtual address, EXE_STD$ALLOC_BUFIO_32

pktsiz int Input Required size of the packet including the packet header.

**Table B-1 EXE_STD$ALLOC_BUFIO_32, EXE_STD$ALLOC_BUFIO_64 Arguments**
Argument	Type	Access	Description
irp	IRP *	Input	Pointer to the current IRP.
pcb	PCB *	Input	Pointer to the process PCB.
uva	VOID_PQ	Input	User virtual address, EXE_STD$ALLOC_BUFIO_64
	void *	Input	User virtual address, EXE_STD$ALLOC_BUFIO_32
pktsiz	int	Input	Required size of the packet including the packet header.

These routines use the EXE_STD$DEBIT_BYTCNT_ALO routine to allocate the packet and charge the process for the required BYTCNT quota. Any failure status from this routine is returned to the caller.

Table B-2 lists all the implicit outputs that are valid on successful return from these routines.

Table B-2 EXE_STD$ALLOC_BUFIO_32, EXE_STD$ALLOC_BUFIO_64 Implicit Outputs
Field Value on Successful Completion

irp$ps_bufio_pkt Pointer to the allocated BUFIO packet.

irp$l_boff Number of charged bytes and size of allocated packet.

bufio$ps_pktdata Pointer to the packet data region in the allocated BUFIO packet.

bufio$ps_uva32 For EXE_STD$ALLOC_BUFIO_32, value of uva.
For EXE_STD$ALLOC_BUFIO_64, BUFIO$K_64.

bufio$w_size Size of allocated packet.

bufio$b_type DYN$C_BUFIO.

bufio$pq_uva64 For EXE_STD$ALLOC_BUFIO_64, value of uva.

**Table B-2 EXE_STD$ALLOC_BUFIO_32, EXE_STD$ALLOC_BUFIO_64 Implicit Outputs**
Field	Value on Successful Completion
irp$ps_bufio_pkt	Pointer to the allocated BUFIO packet.
irp$l_boff	Number of charged bytes and size of allocated packet.
bufio$ps_pktdata	Pointer to the packet data region in the allocated BUFIO packet.
bufio$ps_uva32	For EXE_STD$ALLOC_BUFIO_32, value of uva. For EXE_STD$ALLOC_BUFIO_64, BUFIO$K_64.
bufio$w_size	Size of allocated packet.
bufio$b_type	DYN$C_BUFIO.
bufio$pq_uva64	For EXE_STD$ALLOC_BUFIO_64, value of uva.

B.3 EXE_STD$ALLOC_DIAGBUF

Routine EXE_STD$ALLOC_DIAGBUF is a new routine that allocates either a 32-bit or 64-bit diagnostic buffer packet and initializes the diagnostic buffer packet header. Diagnostic buffer packets use the same layout as BUFIO packets. This routine initializes the appropriate IRP and BUFIO header cells in the diagnostic buffer packet header but it is up to the caller to copy any data into the packet.

The allocation of a 32-bit or 64-bit format diagnostic buffer packet is controlled by a flag bit in the packet size value that is passed to this routine. This allows callers to simply pass in the value of the ddt$w_diagbuf cell directly to this routine.

The interface for this routine is:

int exe_std$alloc_diagbuf (IRP *irp, VOID_PQ *uva, int pktsiz)

Table B-3 summarizes the use of the arguments.

Table B-3 EXE_STD$ALLOC_DIAGBUF Arguments
Argument Type Access Description

irp IRP * Input Pointer to the current IRP.

uva VOID_PQ Input User virtual address.

pktsiz int Input The low-order 15-bits of this parameter specify the required size of the packet including the diagnostic packet header. If bit-16 (DDT$M_DIAGBUF64) is set a 64-bit diagnostic buffer packet is allocated. Otherwise a 32-bit diagnostic buffer packet is allocated.

**Table B-3 EXE_STD$ALLOC_DIAGBUF Arguments**
Argument	Type	Access	Description
irp	IRP *	Input	Pointer to the current IRP.
uva	VOID_PQ	Input	User virtual address.
pktsiz	int	Input	The low-order 15-bits of this parameter specify the required size of the packet including the diagnostic packet header. If bit-16 (DDT$M_DIAGBUF64) is set a 64-bit diagnostic buffer packet is allocated. Otherwise a 32-bit diagnostic buffer packet is allocated.

This routine uses the EXE_STD$ALLOCBUF routine to allocate the packet. Any failure status from this routine is returned to the caller of EXE_STD$ALLOC_DIAGBUF. Note that the EXE_STD$ALLOCBUF routine may put the process in a resource wait state and there is no additional process quota charge for a diagnostic buffer packet.

Table B-4 lists all the implicit outputs that are valid on successful return from this routine.

Table B-4 EXE_STD$ALLOC_DIAGBUF Implicit Outputs
Field Value on Successful Completion

irp$l_diagbuf Pointer to the allocated diagnostic buffer packet.

irp$l_sts Status flag IRP$M_DIAGBUF is set to indicate that the IRP has an associated diagnostic buffer packet.

bufio$ps_pktdata Pointer to the packet data region in the allocated diagnostic BUFIO packet.

bufio$ps_uva32 If DDT$M_DIAGBUF64 clear, value of uva.
If DDT$M_DIAGBUF64 set, BUFIO$K_64.

bufio$w_size Size of allocated diagnostic buffer packet.

bufio$b_type DYN$C_BUFIO

bufio$pq_uva64 If DDT$M_DIAGBUF64 set, value of uva.

**Table B-4 EXE_STD$ALLOC_DIAGBUF Implicit Outputs**
Field	Value on Successful Completion
irp$l_diagbuf	Pointer to the allocated diagnostic buffer packet.
irp$l_sts	Status flag IRP$M_DIAGBUF is set to indicate that the IRP has an associated diagnostic buffer packet.
bufio$ps_pktdata	Pointer to the packet data region in the allocated diagnostic BUFIO packet.
bufio$ps_uva32	If DDT$M_DIAGBUF64 clear, value of uva. If DDT$M_DIAGBUF64 set, BUFIO$K_64.
bufio$w_size	Size of allocated diagnostic buffer packet.
bufio$b_type	DYN$C_BUFIO
bufio$pq_uva64	If DDT$M_DIAGBUF64 set, value of uva.

B.4 EXE_STD$LOCK_ERR_CLEANUP

Routine EXE_STD$LOCK_ERR_CLEANUP is a new routine. This routine unlocks any previously locked down buffers that are associated with the specified IRP or any IRPEs that are attached to it. Additionally, all the attached IRPEs are deallocated.

This routine is designed to be called in a driver-supplied error callback routine that is called if any error is encountered in the EXE_STD$READLOCK, EXE_STD$WRITELOCK, or EXE_STD$MODIFY_LOCK routines.

The interface for this routine is:

void exe_std$lock_err_cleanup (IRP *irp)

Table B-5 summarizes the use of the arguments.

Table B-5 EXE_STD$LOCK_ERR_CLEANUP Arguments
Argument Type Access Description

irp IRP * Input Pointer to the current IRP.

**Table B-5 EXE_STD$LOCK_ERR_CLEANUP Arguments**
Argument	Type	Access	Description
irp	IRP *	Input	Pointer to the current IRP.

Table B-6 lists all the implicit inputs and outputs that are used by this routine.

Table B-6 EXE_STD$LOCK_ERR_CLEANUP Implicit Inputs and Outputs
Implicit Inputs from the IRP

Field Use

irp$l_svapte If non-zero, points to the first PTE for a set of pages that will be unlocked.

irp$l_bcnt Used only if irp$l_svapte is non-zero to calculate number of pages that will be unlocked.

irp$l_boff Used only if irp$l_svapte is non-zero to calculate number of pages that will be unlocked.

irp$v_extend If set, the IRPE pointed to by irp$l_extend will be processed.

irp$l_extend Used only if irp$v_extend is set to find the first IRPE.

Implicit Inputs from Each IRPE

Field Use

irpe$l_svapte If non-zero, points to the first PTE for a set of pages that will be unlocked.

irpe$l_bcnt Used only if irpe$l_svapte is non-zero to calculate number of pages that will be unlocked.

irpe$l_boff Used only if irpe$l_svapte is non-zero to calculate number of pages that will be unlocked.

irpe$v_extend If set, the IRPE pointed to by irpe$l_extend will be processed.

irpe$l_extend Used only if irpe$v_extend is set to find the next IRPE.

Implicit Outputs in the IRP

Field Value Written

irp$l_svapte Cleared to indicate no locked pages.

irp$v_extend Cleared to indicate no attached IRPEs.

**Table B-6 EXE_STD$LOCK_ERR_CLEANUP Implicit Inputs and Outputs**
Implicit Inputs from the IRP
Field	Use
irp$l_svapte	If non-zero, points to the first PTE for a set of pages that will be unlocked.
irp$l_bcnt	Used only if irp$l_svapte is non-zero to calculate number of pages that will be unlocked.
irp$l_boff	Used only if irp$l_svapte is non-zero to calculate number of pages that will be unlocked.
irp$v_extend	If set, the IRPE pointed to by irp$l_extend will be processed.
irp$l_extend	Used only if irp$v_extend is set to find the first IRPE.
Implicit Inputs from Each IRPE
Field	Use
irpe$l_svapte	If non-zero, points to the first PTE for a set of pages that will be unlocked.
irpe$l_bcnt	Used only if irpe$l_svapte is non-zero to calculate number of pages that will be unlocked.
irpe$l_boff	Used only if irpe$l_svapte is non-zero to calculate number of pages that will be unlocked.
irpe$v_extend	If set, the IRPE pointed to by irpe$l_extend will be processed.
irpe$l_extend	Used only if irpe$v_extend is set to find the next IRPE.
Implicit Outputs in the IRP
Field	Value Written
irp$l_svapte	Cleared to indicate no locked pages.
irp$v_extend	Cleared to indicate no attached IRPEs.

Contents

Index

privacy and legal statement

6466PRO_008.HTML

OpenVMS Alpha Guide to Upgrading Privileged-Code Applications

A.9 I/O Request Packet Extension (IRPE)

A.10 Process Header (PHD)

A.11 SCSI-2 Diagnose Buffer (S2DGB)

2 This manual has been archived but is available on the OpenVMS Documentation CD-ROM. This information has also been included in the OpenVMS Programming Concepts Manual, Volume I.

A.12 VMS Communications Request Packet (VCRP)

Appendix BI/O Support Routine Changes

B.1 ACP_STD$READBLK and ACP_STD$WRITEBLK

B.2 EXE_STD$ALLOC_BUFIO_32, EXE_STD$ALLOC_BUFIO_64

B.3 EXE_STD$ALLOC_DIAGBUF

B.4 EXE_STD$LOCK_ERR_CLEANUP

² This manual has been archived but is available on the OpenVMS Documentation CD-ROM. This information has also been included in the OpenVMS Programming Concepts Manual, Volume I.

Appendix B
I/O Support Routine Changes