From: BUHLE@XRT.UPENN.EDU ("E. Loren Buhle, Jr. [-662-3084]", 215)
Newsgroups: comp.os.vms
Subject: Re: The [continuing] Posix debate
Date: 11 Oct 92 15:03:00 GMT
Organization: The Internet

>I fully agree. However, although the implementation details are fully up to
>the vendor, one point that tends to get missed in the REAL standard is that
>there are MANY different Posix standards : one for the cli, one for the OS RTL,
>one for the database access, etc. This means that something Posix-compliant at
>the C and OS RTL level may not be compatible at the cli level, and so forth.
>Therefore, when you say 'So a POSIX compliant applicaton ... will appear the
>same ...', which of the many Posix standards are you referring to ? Will the
>code compile AND link AND run AND function AND look the same ? 
>
>Since your .sig reads :
>
>	DECUS Standards Representative to POSIX & Vice-Chair of POSIX.9
>
>perhaps you could enlighted me as to which of the many Posix standards
>OpenVMS/Posix 5.5-? adheres to ?
>
Fair enough! I shall send a longer message regarding "general" POSIX info in my 
next message to info-vax (where to get drafts, standards, etc.). To those DECUS 
people using DECUServe, this info is also in the Standards NOTES area under 
POSIX. Anyway, the IEEE puts this all under TCOS - Technical Comm. on Operating 
System . . . POSIX is all the 1003 stuff (commonly shortened to POSIX.1 for 
1003.1, etc.)

   1003.0	POSIX Guide		    1003.11 Transaction	Processing AEP
   1003.1	System Interfaces	    1003.12 Protocol Independent Interf
   1003.2	Shell &	Util.		    1003.13 Real Time AEP
   1003.3	Test Methods		    1003.14 Multiprocessing AEP
   1003.4	Real Time		    1003.15 Batch Services
   1003.5	Ada Bindings		    1003.17 Directory Service API
   1003.6	POSIX Security		    1003.18 POSIX Platform AEP
   1003.7	System Admin.		    1201.1  Windowing Toolkit API
   1003.8	Trans. File Access	    1201.2  User Interface Driveability
   1003.9	Fortran	Bindings	    1224.0  X.400 & 500 Obj Mgt
   1003.10	Supercomputing AEP          1224.1  X.400 Gateway API
   					    1238    Common OSI API & FTAM API

POSIX.1 has a 1988 and a 1990 standard. The 1990 standard is ISO/IEC
(International Standards Org/Int. Elect. Comm). It is done and supported at the
1990 level. VMS support for POSIX.2 (shell and utilities) is to Draft 10.
POSIX.2 became a standard at draft 13 on Sept. 13, 1992. Realtime support for
POSIX, POSIX.4 is to draft 9 (circa 1989) while the current draft is somewhere
around 13(?). I expect 1003.4 (Classic) and 1003.4a to become a standard "real
soon". One of my beefs with DEC is their Realtime support is so out-of-date.
There were some major changes since Draft 9. Oddly enough, the Ultrix POSIX
binding is to draft 10 of 1003.4. I suppose it is when DEC takes there
snapshots.. .. 

Look at the compliance document (required by the IEEE) for VMS-POSIX. You will  
see they are compliant with 1003.1, 1003.2 (draft with value-added 
enhancements), and 1003.4 (draft). That is all. 

Both Fortran-77 (POSIX.9) and Ada (POSIX.5) became standards on June 16, 1992. 
Don't expect VMS to make a binding to either of these languages until VMS V6.2 
AT LEAST! I am working on a POSIX.9 binding, in my spare time. So the only 
language you can use today in VMS POSIX is C. 

Aside from POSIX.1, POSIX.2, POSIX.3 (only vendors care here), POSIX.5, and 
POSIX.9, everything else is in draft stage. Most are completeing ballot, 
though! Some of the GUI stuff is coming out as a GUIDE, not a full standard.

>My concern is that Posix is in some ways like X.25 in the early 80's;
>a somewhat non-standard standard.

The IEEE requires a compliance document. There are many areas of the standard 
where specific information (answers to functions, etc. ) must be implemented a 
certain way. There are other areas where the "answers" are allowed to be vendor 
specific. My favorite example (used in my DECUS talks) is asking the system 
version number. Under AIX, Ultrix, SGI-IRIX, I get the OS version. Under VMS, I 
get the POSIX level (e.g. V1.1 instead of VMS 5.5-1). These "implementation 
defined" responses MUST BE DEFINED in the compliance document. This IEEE 
requirement of a compliance document hopefully will deal with the vagarities 
seen in the X.25 standard....

>
>One important difference that I see is that almost any implementation of X11
>requires a fair amount of CPU cycles, only because it, quite frankly, has to
>do a lot of work (you can't argue that GUI's aren't resource intensive).
>Going back to my original posting, the real problem that I have is, again,
>based on DEC's implementation, and not the standard itself. With DEC's
>implementation, I get a machine that spends a lot MORE time running the
>OS and a lot LESS time running my application.

I could make this argument for every new version of VMS too! I remember the 
small size of VMS 2.4! While it never fit on a RL02 (20Mbytes?), it could fit 
on a 80Mbyte disk. It occupied very little memory and ran quite fast. The jump 
from VMS V3.? to VMS V4.0 certainly slowed down my VAX750! With more 
functionality, things got more massive and made greater use of the hardware. 
Fortunately, hardware get faster and disks/memory more massive. So, there is no 
free lunch . . . but the price isn't all that bad for the functionality.

>
>I guess the question, then, would be whether or not Posix will ever be
>anywhere near as fast as native VAX/VMS/DCL ? Although ALL DEC products,
>when they first come out, are functional and slow, and DEC improves the
>performance over time, I would feel comfortable saying that Posix is at
>least an order of magnitude slower than the equivalent DCL !

Yes, some POSIX functionality could be as fast as native DCL (or faster). POSIX 
shell functionality would be a great enhancement to DCL (e.g. pipes, 
redirection, etc). If the user demand is there, VMS-engineering will put in the 
resources. I'd like to see UCX cleaned up to the level of some of the 3rd party 
stuff (yes, there are problems if one uses 3rd party UCX libraries with POSIX, 
but I'll deal with that next week).

>
>>True, if your code doesn't call system calls not implemented in C. For example,
>>how do you deal with the "fork" call in VMS/Ultrix portable code? How do you
>>write shared memory code for VMS/Ultrix? No, using compiler directives misses
>>the point. The purpose of POSIX.1 is to define an interface to the operating
>>system. 
>
>I see your point ... yes, some stuff does get very machine dependant. About
>a year ago I wrote some 'portable' C code that was using malloc() instead of
>LIB$GETVM, and ran into VERY strange and inconsistent behavior. Turned out that
>the code was executing at elevated IPL via an AST, and DEC's implementation of
>malloc() was NOT re-entrant ! So, I cursed a bit, removed the malloc()'s, and
>put in a bunch of LIB$GETVM's (cursing under my breath). The point being that
>an 'Open' environment does not support the direct concepts of IPL and AST
>(not exactally), so by not developing in a fully 'Open' environment, the
>specific behavior of certain functions may be ill-defined.
>
>(BTW - DEC has since fixed that problem, and malloc() is now re-entrant if you
>put some #define's in your header file, however the mere thought of not being
>able to write asynchronous code streams in C !)
>
>Yes, performance is one of the issues. However, the other issue that I was
>trying to bring up is that under VMS I have a lot of very powerful
>functionality. For example, writing something like :
>
>	if (cli$present(&OUTPUT_FILE)
>		cli$get_value(&OUTPUT_FILE,&FILENAME);
>
>	(code simplified for the purposes of this discussion)
>
I think something like this can be done with the KSH-like POSIX shell. I 
haven't dealt with POSIX in very sophisticated ways, so I must plead ignorance 
at this time...
>
>>>'Open' system. On the other hand, if I am concerned with portability, why not
>>>develop under OSF-1 or one of the many U*IX's where I can get a much better 
>>>price/performance ratio ? 
>>>
>>>In all seriousness, can someone please tell me what I am missing ?
>>
>>Alot. POSIX is for today. POSIX runs on alot of non-UN*X platforms, including 
>>VMS, Burroughs, MVS, etc. Go ask your big blue shop to convert their ES9000 to 
>>OSF. On the other hand, if their OS supports POSIX . . . I can running my 
>>compliant application here.
>
>I understand, and agree. My argument is not with Posix, but with why VMS/Posix
>is a good thing, or at least better than Posix on another box ? Under native
>VAX/VMS I can say that VMS has this architecture, that is easy to do, this
>is very flexible, that is every easy to manage, etc., but under Posix, is
>VMS/Posix any better than (to make up a few) MVS/Posix, Burroughs/Posix, etc ?

That is the point of POSIX. For strictly POSIX compliant software, both the 
user and developer shouldn't need to know or care what platform they are 
using (ignoring the implentation performance). Strict compliance means ONLY 
using IEEE/ISO/ANSI standard complaint. Any extensions are forbidden. Anytime 
the word "may" is present in the standard, it cannot be used in a strictly 
compliant application. However, for conformant applications (where most of the 
rest of us live), there are value-added extensions. This is where DEC can 
differentiate from HP/IBM/etc.

In addition, if you happen to like using a vendor tool/resouce to develop an 
POSIX compliant/conformant application, then this can be seen as a value-added 
functionality. The idea is that applications should have a lifetime beyond the 
original vendor's equipment.

>
>BTW - what are the differences between OSF-1 and Posix ? I realize that OSF-1
>is the Open Systems Foundation (sic?) and Posix is IEEE, but are they not
>both trying to standardize on the same things ? (see my .sig)

IEEE is a "de jure" standards organization. Attendees at this meeting write the 
standards. Anyone belonging to the IEEE Computer Soc. and a few other 
organizations can come a help. Frankly, I'd be happy with any warm body with 
knowledge to contribute. Once the draft is written, it goes out to the public 
for ballot. This is where YOU, the USER/DEVELOPER/INTERESTED_PARTY get to 
argue, bitch, change what is there. This takes time. Between the writing and 
balloting, it can take a few years. If you write a standard in 6months that is 
truely aweful, you can spend years in balloting . . . changing the document to 
get the 75% affirmatives (there are alot of rules here). So it is important to 
write a document that will get the affirmatives on the 2-3 go-around. POSIX.9 
took ~3-4 years to write (there weren't that many of us) and two full cycles of 
balloting (~8months).

OSF, Open Software Foundation, is a player in the POSIX arena. We value their 
attendence (and we'd like to see you too!). They select software in a slightly 
different fashion (do I see a mine-field ahead of me?). 

>
>>{soapbox time}
>>Saying everyone should run OSF is much like Microsoft saying their MS-Windows 
>>environment is "open". If everyone ran MS-Windows, then portability (in theory) 
>>would be assured, they say. Did we hear this from salesmen in pin-stripe suits 
>>in the 60s/70s about their environments?
>
>In summary, I agree with every point you make about Posix and Open systems
>being a generally 'good' thing. I agree that if you want speed, you want
>to write non-portable code to the hardware, and if you want portability
>you write potentionally less-efficient code to standards, and if you want
>both, you write potentionally less-efficient code to standards and wait for
>the next generation of hardware to get faster. :-)
>
>However, except for the people who are currently 'stuck' :-) with VAX/VMS
>and VAX-11 machines, moving forward why should we stick with DEC and VAXen,
>and why shouldn't we move onto the cheapest 'clone' ?

Value added features. Most cars I could buy have a common functionality. Would 
I buy the cheapest clone? I am I really buying my coffin if some care decides 
to give me a little bump? Or do I want the "value added" Sherman tank 
functionality. And I'd like a nice sound system, too . . . though it isn't in 
the common car standard.

A favorite example of standards is the automobile. Assuming I am in the USA, 
when I rent a car I know how to operate it. I know what to do with the steering 
wheel, gear shift (though there may be some optional gears), etc. But the 
"vendor implementation defined features" such as where are the blasted 
lights/windshield switches (which are present according to the standard). Then 
there are the options, like the sound system. etc. 

--
Dr. E. Loren Buhle, Jr.  INTERNET: BUHLE@XRT.UPENN.EDU
DECUS Rep. to POSIX and Vice-Chair of 1003.9
University of Pennsylvania School of Medicine         Phone: 215-662-3084
Rm 440A, 3401 Walnut St., Philadelphia, PA 19104-6228   FAX: 215-349-5978

Newsgroups: comp.os.vms