| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3109.1 | freeware | MUCTEC::BECKER | Hartmut B., VMS & Languages, Munich | Thu Jan 30 1997 05:02 | 14 |
| > At first Ken wanted a PAK for "POSIX for OpenVMS". The kit files are in the
> ASAP OpenVMS SDK, but the ASAP PAK that gets mailed to subscribers of the SDK
> under separate cover doesn't include a PAK for POSIX. I told him he would need
> to contact his business relationship manager to purchase/obtain PAK's for toys
> not included in the ASAP OpenVMS SDK collection.
As far as I know Posix doesn't need a PAK.
On the other hand if he just wants to use his makefiles maybe Gnu make 3.75 is
what he wants to use. Today I read in the GNU notes file that this version runs
on VMS.
Hope this helps,
Hartmut
|
| 3109.2 | OpenVMS w/ POSIX is *NOT* UNIX - period... | AMCUCS::SWIERKOWSKI | Quot homines tot sententiae | Thu Jan 30 1997 13:16 | 67 |
| Greetings!
I've always had to load a PAK with the product name: "POSIX-V" in order to
use "POSIX for OpenVMS" in a build environment, only the run-time components
are available gratis with the base operating system license. The way I under-
stand it is that this allows applications linked against the POSIX libraries
to run on *any* OpenVMS system without having to install/configure/license
POSIX, but to actually use the POSIX Shell for the purposes of building an
application or whatever, you need the "POSIX-V" PAK loaded, POSIX installed off
the SPL, properly configured (via POSIX$CONFIG) and started (via POSIX$STARTUP).
Furthermore, UCX is a stated pre-requisite for POSIX and it must be started
*before* POSIX$STARTUP is invoked at boot time. Only then do you have the full-
blown POSIX development environment available to you.
As for using "gnumake" (or any other UNIX-style "make"-like tools for that
matter), Kent wants to use gnumake alright, but what he really wanted was to
have his make scripts access his source pool sitting on his NFS servers while
under the POSIX environment - this you can *NOT* do!
He (and a lot of other folks) assume that if you can access remote NFS served
filesystems via the UCX NFS client (available since UCX V3.2), that he would
implicitly be able to access those same remote NFS served filesystems while
under the POSIX environment. This simply isn't possible, there is no NFS client
under POSIX and the fact that you may have set up the UCX NFS Client doesn't
help you. POSIX only can access local Files-11 files or "container filesystems"
(which are really local Files-11 files underneath it all). POSIX does not allow
you to access either remote container filesystems or remote files sitting on an
NFS server. You have to step outside of POSIX and use UCX (or some such similar
TCP/IP stack like Wollongong, etc.) that supports an NFS Client to access remote
NFS exported filesystems.
I've been down this path (trying to get OpenVMS w/POSIX installed to look,
feel and function like a UNIX system) for over a year now with one partner and
they are still beating their head against the wall. They've been told to build
their product suite using the native OpenVMS programming environment by both
the guy who picked up the "maintenance" of POSIX in OpenVMS engineering as well
as the former product manager for POSIX. POSIX does not and will never have a
native NFS client and since POSIX engineering is gone, adding new features (like
a native POSIX NFS Client) simply isn't going to happen. FWIW, Julie Corenzwit
(engineer for the UCX NFS Client and former DFS engineer) explained in detail
why POSIX does not (and will not) simply use the existing UCX NFS Client in
order to provide POSIX with remote filesystem access.
If gnumake 3.75 is the kit on the current Freeware CD, Kent would need POSIX
just to unpack and build the gnumake kit. I believe Ian Brockbank (creator of
the first gnumake kit (V3.72-1) on the original Freeware CD) helped me get that
older gnumake kit from that CD up and running - but *not* without having access
to a system with POSIX installed. I suppose once gnumake was built, you might
be able to use it w/o POSIX, but I doubt it since "make"-like tools in general
expect UNIX-style filenames and the only way to do this is with POSIX container
files to contain your sources or possibly create container files using UCX to
contain your sources. In any event, "make" tools (run under the POSIX environ-
ment) only have access to local files/filesystems - no remote (via NFS) access
is possible. At the very least, you would have to move files manually down from
your NFS source pool servers, run whatever "make"-like tool you have on the
local copy of those files and then manually push the results back up to your
NFS source pool servers. Kent wanted to be able to just use his existing make
scripts to reference the NFS source pool servers directly in order to build his
application by using make (under the POSIX environment) and this he cannot do,
cheers...
Tony Swierkowski
Digital Equipment Corporation
Software Partner Engineering
Palo Alto, California
(415) 617-3601
"[email protected]"
|
| 3109.3 | ... | MUCTEC::BECKER | Hartmut B., VMS & Languages, Munich | Fri Jan 31 1997 04:49 | 106 |
| > I've always had to load a PAK with the product name: "POSIX-V" in order to
> use "POSIX for OpenVMS" in a build environment, only the run-time components
> are available gratis with the base operating system license. The way I under-
There is an old entry in the posix notes conference:
<<< VMSZOO::DISK$NOTES:[NOTES$LIBRARY]VMS_POSIX.NOTE;2 >>>
-< POSIX for OpenVMS - Public forum >-
================================================================================
Note 790.0 PAK ? No replies
AIRONE::SICHERA "Maurizio, OpenVMS/Italy Engineerin" 65 lines 27-JUL-1993 13:55
--------------------------------------------------------------------------------
Another note that has been recovered.
================================================================================
Note 784.0 PAK ? 3 replies
RCOCER::SALEHI "Mehran Salehi" 7 lines 20-JUL-1993 17:31
--------------------------------------------------------------------------------
Greetings,
I have the posix for alpha on the July Layered products CD but can't
find its PAK. Does this product need a PAK, what is the product name, where can
I get the PAK for a LOP.
Mike
================================================================================
Note 784.1 PAK ? 1 of 3
AIRONE::SICHERA "Maurizio, OpenVMS/Italy Engineering" 6 lines 20-JUL-1993
18:21
-< Not needed >-
--------------------------------------------------------------------------------
POSIX for OpenVMS does not need a PAK, because its license is included
in the OpenVMS license: just go and install it!
- Maurizio
================================================================================
...
I don't have any posix pak on our system. I can run the posix shell, I can use
make, lex, yacc and the c compiler.
> are available gratis with the base operating system license. The way I under-
> stand it is that this allows applications linked against the POSIX libraries
> to run on *any* OpenVMS system without having to install/configure/license
> POSIX, but to actually use the POSIX Shell for the purposes of building an
If you linked your application against the posix libraries you can run this
application only on OpenVMS system *with* Posix installed. Posix has its
own system services. These services implement the posix system calls. They
have to be loaded. They are implemented in a system loadable image. If you
use the posix shell to create a pure VMS application, only CRTL calls, you
can run it on any VMS system.
> Furthermore, UCX is a stated pre-requisite for POSIX and it must be started
> *before* POSIX$STARTUP is invoked at boot time. Only then do you have the full-
> blown POSIX development environment available to you.
New to me. What Posix uses is the container file system. This is necessary to
use Unix style file names which can't directly be mapped to the VMS file
system. Currently on our system UCX, hmm TCP/IP Services for OpenVMS, is
installed. But when I started with Posix it came with its own minimum container
file services (compatible with UCX, or was it borrowed from UCX?) which was
automagically started via posix$startup. Maybe they changed it.
> As for using "gnumake" (or any other UNIX-style "make"-like tools for that
> matter), Kent wants to use gnumake alright, but what he really wanted was to
> have his make scripts access his source pool sitting on his NFS servers while
> under the POSIX environment - this you can *NOT* do!
As you say, NFS under Posix isn't supported. Using NFS and Posix together can
crash the system.
> If gnumake 3.75 is the kit on the current Freeware CD, Kent would need POSIX
> just to unpack and build the gnumake kit. I believe Ian Brockbank (creator of
> the first gnumake kit (V3.72-1) on the original Freeware CD) helped me get that
> older gnumake kit from that CD up and running - but *not* without having access
> to a system with POSIX installed. I suppose once gnumake was built, you might
> be able to use it w/o POSIX, but I doubt it since "make"-like tools in general
> expect UNIX-style filenames and the only way to do this is with POSIX container
> files to contain your sources or possibly create container files using UCX to
> contain your sources. In any event, "make" tools (run under the POSIX environ-
I don't know if the 3.75 version is on the freeware CD for OpenVMS V7.1, I
expect it isn't. What I saw in the GNU notes file was a reference to this
version. It was said you can simply build it on VMS with @makefile. This
doesn't look like posix. As soon as I can get hold of it I will try. On
older CDs there was only a posix gnu make. This is different. I'm pretty
sure that there are some restrictions on what you can do on VMS versus what
you can do on a Unix system. But I expect it will give you gnu features in
the makefile, macros etc. (With builtin functions you can make out of a
white space separated list a comma separated one, which is very handy on
VMS). And maybe it's restricted to VMS version 7.0 and younger, because its
CRTL is closer to Unix than before.
Anyway, if your partner wants NFS & Posix he's out of luck. We can't offer both
features (as we can't offer Posix & pthreads (1003.1c)). I only thought he (and
we) can benefit from the new gnu make.
Greetings from Bavaria,
Hartmut
|
| 3109.4 | Lack of NFS client for POSIX is real problem... | AMCUCS::SWIERKOWSKI | Quot homines tot sententiae | Fri Jan 31 1997 13:50 | 101 |
| Greetings!
>I don't have any posix pak on our system. I can run the posix shell, I can use
>make, lex, yacc and the c compiler.
I stand corrected, if you have full access to the callable functions and can
use the Shell commands without a PAK so much the better (kind of begs the ques-
tions though about that "POSIX-V" PAK I have on our systems - no matter...).
>If you linked your application against the posix libraries you can run this
>application only on OpenVMS system *with* Posix installed. Posix has its
>own system services. These services implement the posix system calls. They
>have to be loaded. They are implemented in a system loadable image. If you
>use the posix shell to create a pure VMS application, only CRTL calls, you
>can run it on any VMS system.
All the more reason to avoid POSIX, since most customers a developer might
support are not going to have POSIX installed on their systems (very few end
users in my experience have ever installed POSIX on their production systems).
Just as a matter of curiousity; what system loadable image contains the POSIX
callable routines? I didn't spot anything obvious on a V6.2 system, is this
loadable image part of the base OS like the assorted language RTL's?
>New to me. What Posix uses is the container file system. This is necessary to
>use Unix style file names which can't directly be mapped to the VMS file
>system. Currently on our system UCX, hmm TCP/IP Services for OpenVMS, is
>installed. But when I started with Posix it came with its own minimum container
>file services (compatible with UCX, or was it borrowed from UCX?) which was
>automagically started via posix$startup. Maybe they changed it.
Read SPD and install guide for POSIX, UCX is a pre-requisite last time I read
them (for POSIX V2.0, this may have been changed for V3.0...). The installation
of POSIX on my system modified UCX$NFS_SET_FS.COM to invoke POSIX$BINDINGS.COM
so UCX had to be present otherwise I wouldn't have had a UCX$NFS_SET_FS.COM for
the POSIX installation/configuration to modify. POSIX$BINDINGS.COM does create
a minimal container file (i.e. "/cont") which is independant of any container
files created by you in UCX$NFS_SET_FS.COM (that procedure by default doesn't
create any container filesystems so the POSIX installation puts a hook in
UCX$NFS_SET_FS.COM to invoke POSIX$BINDINGS.COM so "/cont" can be created for
use by POSIX in setting up the "/cont/bin", "/cont/usr", "/cont/lib", etc.
directory structure. FWIW, the POSIX$BINDINGS.COM procedure uses a standard
UCX BIND dev:[dir] "/cont" command so again, UCX has to be present or this
procedure doesn't work and it *must* execute for the "/cont/.." container file-
system to be set up.
>As you say, NFS under Posix isn't supported. Using NFS and Posix together can
>crash the system.
Two targeted partners I've been working with for almost two years found this
limitation to be the real road block in using an OpenVMS system w/ UCX and
POSIX as you would any other UNIX NFS client for the purposes of maintaining a
common source pool server that exports filesystems to assorted NFS clients so
builds can be done easily. FWIW, this restriction is clearly documented in both
the POSIX and UCX release notes so it shouldn't surprise anyone - but it does...
>I don't know if the 3.75 version is on the freeware CD for OpenVMS V7.1, I
>expect it isn't. What I saw in the GNU notes file was a reference to this
>version. It was said you can simply build it on VMS with @makefile. This
>doesn't look like posix. As soon as I can get hold of it I will try. On
>older CDs there was only a posix gnu make. This is different. I'm pretty
>sure that there are some restrictions on what you can do on VMS versus what
>you can do on a Unix system. But I expect it will give you gnu features in
>the makefile, macros etc. (With builtin functions you can make out of a
>white space separated list a comma separated one, which is very handy on
>VMS). And maybe it's restricted to VMS version 7.0 and younger, because its
>CRTL is closer to Unix than before.
Regardless of whether the gnumake kit builds via a DCL "$ @makefile" or a
"psx> make" command, you're still stuck actually using your original UNIX
make scripts filled full of UNIX-style file specifications. Without POSIX
(or at least a container file created by UCX) filled with your source modules,
your makefiles are pretty useless since they aren't going to digest Files-11
file specifications. The other "feature" both partners got bit by is non-
unique filespecs under Files-11 that were unique of the NFS server since the
UNIX filesystem treats things like mixed-case filenames as different files,
but by the time UCX mangles "MyModule.c" into "$M$y$M$odule.c" or some such,
the filespec presented by UCX doesn't resemble anything in your makefile.
This BTW, prevented one partner from setting up a dummy container file (local
to the OpenVMS system) and creating links back to the real UNIX NFS server
for their source modules sitting on the UNIX NFS server. They wrote a little
script to "convert" the filespecs presented by UCX back to their original form
as they lived on the UNIX server, but a side effect was to indeed crash the
system anytime you tried to manipulate one of the files back on the UNIX server
via the soft link in the container file on the OpenVMS client.
>Anyway, if your partner wants NFS & Posix he's out of luck. We can't offer both
>features (as we can't offer Posix & pthreads (1003.1c)). I only thought he (and
>we) can benefit from the new gnu make.
Yes, the lack of a native NFS client under POSIX (or at least the ability to
use the UCX NFS client from the POSIX environment) is a big piece of missing
functionality that any other UNIX NFS client would take for granted. Unfortu-
nately, OpenVMS (even with UCX & POSIX) isn't UNIX and simply can't do some of
things a real UNIX client can do - oh well, cheers...
Tony Swierkowski
Digital Equipment Corporation
Software Partner Engineering
Palo Alto, California
(415) 617-3601
"[email protected]"
|
| 3109.5 | posix$kernel | MUCTEC::BECKER | Hartmut B., VMS & Languages, Munich | Fri Jan 31 1997 15:39 | 8 |
| > callable routines? I didn't spot anything obvious on a V6.2 system, is this
> loadable image part of the base OS like the assorted language RTL's?
No, it's posix$kernel which comes with the posix kit. It then lives in
sys$loadable_images. You can spot all such system loadable images in the
file SYS$COMMON:[SYSUPD]VMS$SYSTEM_IMAGES.IDX.
Hartmut
|