Samba is the canonical system used to do this on Unix-like systems and did support VMS at one point. However I'm not sure that it still does in the main trunk - you could try an older version. Directories can be shared from the VMS server via the samba server or mounted off a Windows machine via smbmount.
If you don't want to compile your own version, HP maintains a port of Samba for VMS, which can be downloaded here.
Alternatively, you could see if the Pathworks32 client will run in Win 2k3 server. Lastly, you may be able to just upload/download files via FTP.
Pathworks for OpenVMS (if installed on VMS) provides integration with active directory. Security can be controlled with inter-domain trusts (Windows side) and ACLs with HOSTMAPs that map active directory names to OpenVMS accounts. You could limit the capabilities of the relevant OpenVMS accounts to match any security policy.
OpenVMS files can have varying record formats, and not all of them can be easily translated to Windows files. Pathworks does a reasonable job translating record formats, but for some files the result is not usable.
Care should be taken with file version numbers, as the Windows side can see only the file with the highest version. When a Windows client deletes a file from a shared directory, an older version can appear and confuse the client.
You could try setting up the OpenVMS system as an NFS server and the Windows 2008 server as an NFS client. The biggest problems with this approach are the fact that OpenVMS has versioned files (so that deleting a file only deletes the latest version) and the fact that OpenVMS filesystems are case-insensitive.
From what I've read, OpenVMS NFS is also very picky about what it will accept; anything off kilter will cause it to reject the NFS traffic.
With OpenVMS 8.x, HP TCP/IP is included - as is NFS.
Whether it's Samba or NFS, nothing in the Windows world is likely to compromise the VMS system - the chances of someone leaving malware on the share that could hurt the VMS system are insignificant.
Or did you meant the other way? That something about the mapping could affect the Windows server? In that case, there'd be nothing more risky than any other drive you mapped on the Windows server.
Samba is the canonical system used to do this on Unix-like systems and did support VMS at one point. However I'm not sure that it still does in the main trunk - you could try an older version. Directories can be shared from the VMS server via the samba server or mounted off a Windows machine via smbmount.
If you don't want to compile your own version, HP maintains a port of Samba for VMS, which can be downloaded here.
Alternatively, you could see if the Pathworks32 client will run in Win 2k3 server. Lastly, you may be able to just upload/download files via FTP.
Pathworks for OpenVMS (if installed on VMS) provides integration with active directory. Security can be controlled with inter-domain trusts (
Windowsside) and ACLs with HOSTMAPs that map active directory names toOpenVMSaccounts. You could limit the capabilities of the relevantOpenVMSaccounts to match any security policy.OpenVMSfiles can have varying record formats, and not all of them can be easily translated toWindowsfiles.Pathworksdoes a reasonable job translating record formats, but for some files the result is not usable.Care should be taken with file version numbers, as the
Windowsside can see only the file with the highest version. When aWindowsclient deletes a file from a shared directory, an older version can appear and confuse the client.You could try setting up the OpenVMS system as an NFS server and the Windows 2008 server as an NFS client. The biggest problems with this approach are the fact that OpenVMS has versioned files (so that deleting a file only deletes the latest version) and the fact that OpenVMS filesystems are case-insensitive.
From what I've read, OpenVMS NFS is also very picky about what it will accept; anything off kilter will cause it to reject the NFS traffic.
With OpenVMS 8.x, HP TCP/IP is included - as is NFS.
Whether it's Samba or NFS, nothing in the Windows world is likely to compromise the VMS system - the chances of someone leaving malware on the share that could hurt the VMS system are insignificant.
Or did you meant the other way? That something about the mapping could affect the Windows server? In that case, there'd be nothing more risky than any other drive you mapped on the Windows server.