Making the CRTL version dependency information useful

[Craig A. Berry]

If you've ever been about to use a CRTL function and wondered when it
first became available, you've probably looked at the version dependency
tables at the end of the CRTL manual or in online help. The problem is,
to use these tables, you have to already know what version first had the
function of interest, or you have to look through each table until you
find the one in which the function appears. In other words, the tables
are basically backwards because they require you to start with the
version to find a function rather than the other way around, which is
the more typical use case.

No more. The attached Perl script (crtl_version_xref.pl) parses the
output of the tables from online help and produces one long list of
versions and functions sorted by function name. If you want the whole
list, just run it like so:

$ perl crtl_version_xref.pl
<output omitted but see below>

If you want a particular function or family of functions, just search
like so:

$ pipe perl crtl_version_xref.pl | search sys$pipe pwuid
V7.3-2 getpwuid
V7.3-2 _getpwuid64
V7.3-2 getpwuid_r
V7.3-2 _getpwuid_r64

Or if you do for some reason want the functions that appeared in a
particular version of VMS, search for the version:

$ pipe perl crtl_version_xref.pl | search sys$pipe V8.3
V8.3 crypt
V8.3 encrypt
V8.3 fchmod
V8.3 lchown
V8.3 lstat
V8.3 readlink
V8.3 realpath
V8.3 setkey
V8.3 symlink
V8.3 unlink

Many caveats and porting gotchas remain. For the table labeled "All
OpenVMS Versions" I assumed V4.0 because I think that might be around
the time a semi-viable CRTL came along, and if you really care about
anything pre-7.x then you need a great deal more help than I can give
you (for many reasons). Bu if someone knows a better definition of "all"
than V4.0, please say so.

I ignored the Alpha-only distinction made for some of the functions
because I'm not interested in VAX and it's no longer correct anyway
since as far as I know those functions are also available on Itanium.

Also worth noting is that this information is no better than what's in
the source tables, i.e., it just tells you when a function first
appeared. It does not tell you whether it actually works or does what
you or some standard or the code you're porting thinks it should do.

I end the post with the entire current list in case anyone just wants a
static version or doesn't want to run my script for some reason:

$ perl crtl_version_xref.pl
V7.3-2 a64l
V4.0 abort
V4.0 abs
V7.3-1 access
V4.0 acos
V4.0 addch
V4.0 addstr
V4.0 alarm
V4.0 asctime
V7.2 asctime_r
V4.0 asin
V4.0 assert
V4.0 atan
V4.0 atan2
V4.0 atexit
V4.0 atof
V4.0 atoi
V4.0 atol
V4.0 atoll
V4.0 atoq
V7.0 basename
V7.0 _basename32
V7.0 _basename64
V7.0 bcmp
V7.0 bcopy
V4.0 box
V4.0 brk
V4.0 bsearch
V7.0 _bsearch32
V7.0 _bsearch64
V7.0 btowc
V7.0 bzero
V4.0 cabs
V4.0 calloc
V7.0 _calloc32
V7.0 _calloc64
V6.2 catclose
V6.2 catgets
V7.0 _catgets32
V7.0 _catgets64
V6.2 catopen
V4.0 ceil
V4.0 cfree
V4.0 chdir
V7.3-1 chmod
V7.3-1 chown
V4.0 clear
V4.0 clearerr
V8.2 clearerr_unlocked
V4.0 clock
V7.3-2 clock_getres
V7.3-2 clock_gettime
V7.3-2 clock_settime
V4.0 close
V7.0 closedir
V4.0 clrattr
V4.0 clrtobot
V4.0 clrtoeol
V7.0 confstr
V4.0 cos
V4.0 cosh
V4.0 creat
V8.3 crypt
V4.0 ctermid
V7.0 _ctermid32
V7.0 _ctermid64
V4.0 ctime
V7.2 ctime_r
V4.0 cuserid
V7.0 _cuserid32
V7.0 _cuserid64
V4.0 decc$crtl_init
V7.3-1 decc$feature_get_index
V7.3-1 decc$feature_get_name
V7.3-1 decc$feature_get_value
V7.3-1 decc$feature_set_value
V4.0 decc$fix_time
V4.0 decc$from_vms
V4.0 decc$match_wild
V4.0 decc$record_read
V4.0 decc$record_write
V7.3-2 decc$set_child_default_dir
V7.2 decc$set_child_standard_streams
V4.0 decc$set_reentrancy
V4.0 decc$to_vms
V4.0 decc$translate_vms
V7.2 decc$validated
V7.2 decc$write_eof_to_mbx
V4.0 delch
V4.0 delete
V4.0 deleteln
V4.0 delwin
V4.0 difftime
V7.0 dirname
V7.0 _dirname32
V7.0 _dirname64
V4.0 div
V7.2 dlerror
V7.2 dlopen
V7.2 dlsym
V7.0 drand48
V4.0 dup
V4.0 dup2
V4.0 ecvt
V8.3 encrypt
V7.3-2 endgrent
V4.0 endwin
V7.0 erand48
V4.0 erase
V4.0 execl
V4.0 execle
V4.0 execlp
V4.0 execv
V4.0 execve
V4.0 execvp
V4.0 exit
V4.0 _exit
V4.0 exp
V4.0 fabs
V8.3 fchmod
V7.3 fchown
V4.0 fclose
V7.2 fcntl
V4.0 fcvt
V4.0 fdopen
V4.0 feof
V8.2 feof_unlocked
V4.0 ferror
V8.2 ferror_unlocked
V4.0 fflush
V7.0 ffs
V4.0 fgetc
V8.2 fgetc_unlocked
V4.0 fgetname
V7.0 _fgetname32
V7.0 _fgetname64
V4.0 fgetpos
V4.0 fgets
V7.0 _fgets32
V7.0 _fgets64
V6.2 fgetwc
V6.2 fgetws
V7.0 _fgetws32
V7.0 _fgetws64
V4.0 fileno
V8.2 flockfile
V4.0 floor
V4.0 fmod
V4.0 fopen
V7.0 fpathconf
V4.0 fprintf
V4.0 fputc
V8.2 fputc_unlocked
V4.0 fputs
V6.2 fputwc
V6.2 fputws
V4.0 fread
V4.0 free
V4.0 freopen
V4.0 frexp
V4.0 fscanf
V4.0 fseek
V7.3-1 fseeko
V4.0 fsetpos
V7.3-1 fstat
V8.2 fstatvfs
V4.0 fsync
V4.0 ftell
V7.3-1 ftello
V4.0 ftime
V8.4 ftok
V7.0 ftruncate
V8.2 ftrylockfile
V7.3-1 ftw
V8.2 funlockfile
V4.0 fwait
V7.0 fwide
V7.0 fwprintf
V4.0 fwrite
V7.0 fwscanf
V4.0 gcvt
V7.0 _gcvt32
V7.0 _gcvt64
V4.0 getc
V8.2 getc_unlocked
V4.0 getch
V4.0 getchar
V8.2 getchar_unlocked
V7.0 getclock
V4.0 getcwd
V7.0 _getcwd32
V7.0 _getcwd64
V7.0 getdtablesize
V4.0 getegid
V4.0 getenv
V4.0 geteuid
V4.0 getgid
V7.3-2 getgrent
V7.3-2 getgrgid
V7.3-2 getgrgid_r
V7.3-2 getgrnam
V7.3-2 getgrnam_r
V7.0 getitimer
V7.0 getlogin
V4.0 getname
V7.0 _getname32
V7.0 _getname64
V6.2 getopt
V7.0 getpagesize
V7.3-2 getpgid
V7.3-2 getpgrp
V4.0 getpid
V4.0 getppid
V7.3-2 _getpwent64
V7.0 getpwnam
V7.3-2 _getpwnam64
V7.3-2 getpwnam_r
V7.3-2 _getpwnam_r64
V7.3-2 getpwuid
V7.3-2 _getpwuid64
V7.3-2 getpwuid_r
V7.3-2 _getpwuid_r64
V4.0 gets
V7.0 _gets32
V7.0 _gets64
V7.3-2 getsid
V4.0 getstr
V7.0 gettimeofday
V4.0 getuid
V4.0 getw
V6.2 getwc
V6.2 getwchar
V8.2 _glob32
V8.2 _glob64
V8.2 _globfree32
V8.2 _globfree64
V4.0 gmtime
V7.2 gmtime_r
V4.0 gsignal
V4.0 hypot
V6.2 iconv
V6.2 iconv_close
V6.2 iconv_open
V4.0 inch
V7.0 index
V7.0 _index32
V7.0 _index64
V4.0 initscr
V7.0 initstate
V4.0 insch
V4.0 insertln
V4.0 insstr
V4.0 isalnum
V4.0 isalpha
V4.0 isapipe
V4.0 isascii
V4.0 isatty
V4.0 iscntrl
V4.0 isdigit
V4.0 isgraph
V4.0 islower
V4.0 isprint
V4.0 ispunct
V4.0 isspace
V4.0 isupper
V6.2 iswalnum
V6.2 iswalpha
V6.2 iswcntrl
V6.2 iswctype
V6.2 iswdigit
V6.2 iswgraph
V6.2 iswlower
V6.2 iswprint
V6.2 iswpunct
V6.2 iswspace
V6.2 iswupper
V6.2 iswxdigit
V4.0 isxdigit
V7.0 jrand48
V4.0 kill
V7.3-2 l64a
V4.0 labs
V8.3 lchown
V7.2 lclose
V7.0 lcong48
V4.0 ldexp
V4.0 ldiv
V7.3 link
V4.0 llabs
V4.0 lldiv(Alpha)
V4.0 localeconv
V4.0 localtime
V7.2 localtime_r
V4.0 log
V4.0 log10
V4.0 longjmp
V4.0 longname
V7.0 _longname32
V7.0 _longname64
V7.0 lrand48
V4.0 lseek
V8.3 lstat
V4.0 lwait
V4.0 malloc
V7.0 _malloc32
V7.0 _malloc64
V4.0 mblen
V7.0 mbrlen
V7.0 mbrtowc
V7.0 mbsinit
V7.0 mbsrtowcs
V7.0 _mbsrtowcs32
V7.0 _mbsrtowcs64
V4.0 mbstowcs
V4.0 mbtowc
V7.0 memccpy
V7.0 _memccpy32
V7.0 _memccpy64
V4.0 memchr
V7.0 _memchr32
V7.0 _memchr64
V4.0 memcmp
V4.0 memcpy
V7.0 _memcpy32
V7.0 _memcpy64
V4.0 memmove
V7.0 _memmove32
V7.0 _memmove64
V4.0 memset
V7.0 _memset32
V7.0 _memset64
V4.0 mkdir
V7.0 mkstemp
V4.0 mktemp
V7.0 _mktemp32
V7.0 _mktemp64
V4.0 mktime
V7.0 mmap
V7.0 _mmap32
V7.0 _mmap64
V4.0 modf
V4.0 move
V7.0 mprotect
V7.0 mrand48
V7.0 msync
V7.0 munmap
V4.0 mv[w]addstr
V4.0 mvwin
V7.3-2 nanosleep
V4.0 newwin
V4.0 nice
V6.2 nl_langinfo
V7.0 nrand48
V4.0 open
V7.0 opendir
V4.0 overlay
V4.0 overwrite
V7.0 pathconf
V4.0 pause
V7.0 pclose
V4.0 perror
V4.0 pipe
V7.3-2 poll
V7.0 popen
V4.0 pow
V7.3-2 pread
V4.0 printf
V4.0 printw
V4.0 putc
V8.2 putc_unlocked
V4.0 putchar
V8.2 putchar_unlocked
V7.0 putenv
V4.0 puts
V4.0 putw
V6.2 putwc
V6.2 putwchar
V7.3-2 pwrite
V4.0 qabs
V4.0 qdiv
V4.0 qsort
V7.0 _qsort32
V7.0 _qsort64
V4.0 raise
V4.0 rand
V7.3-2 rand_r
V7.0 random
V4.0 read
V7.0 readdir
V7.3-1 readdir_r
V8.3 readlink
V7.3-2 readv
V7.3-2 _readv64
V4.0 realloc
V7.0 _realloc32
V7.0 _realloc64
V8.3 realpath
V4.0 refresh
V4.0 remove
V4.0 rename
V4.0 rewind
V7.0 rewinddir
V7.0 rindex
V7.0 _rindex32
V7.0 _rindex64
V7.0 rmdir
V4.0 sbrk
V4.0 scanf
V4.0 scanw
V4.0 scroll
V7.0 seed48
V7.0 seekdir
V8.4 sem_close
V8.4 sem_destroy
V8.4 sem_getvalue
V8.4 sem_init
V8.4 sem_open
V8.4 sem_post
V8.4 sem_timedwait
V8.4 sem_trywait
V8.4 sem_unlink
V8.4 sem_wait
V8.4 semctl
V8.4 semget
V8.4 semop
V4.0 setattr
V4.0 setbuf
V7.0 setenv
V7.3-2 seteuid
V4.0 setgid
V7.3-2 setgrent
V7.0 setitimer
V4.0 setjmp
V8.3 setkey
V4.0 setlocale
V7.3-2 setpgid
V7.3-2 setpgrp
V7.3-2 setregid
V7.3-2 setreuid
V7.3-2 setsid
V7.0 setstate
V4.0 setuid
V4.0 setvbuf
V7.0 sigaction
V7.0 sigaddset
V4.0 sigblock
V7.0 sigdelset
V7.0 sigemptyset
V7.0 sigfillset
V7.3-2 sighold
V7.3-2 sigignore
V7.0 sigismember
V7.0 siglongjmp
V4.0 signal
V4.0 sigpause
V7.0 sigpending
V7.0 sigprocmask
V7.3-2 sigrelse
V7.0 sigsetjmp
V4.0 sigstack(VAX)
V7.0 sigsuspend
V7.3-2 sigtimedwait
V4.0 sigvec
V7.3-2 sigwait
V7.3-2 sigwaitinfo
V4.0 sin
V4.0 sinh
V4.0 sleep
V7.3-2 snprintf
V8.2 socketpair
V4.0 sprintf
V4.0 sqrt
V4.0 srand
V7.0 srand48
V7.0 srandom
V4.0 sscanf
V4.0 ssignal
V4.0 standend
V4.0 standout
V7.3-1 stat
V8.2 statvfs
V7.0 strcasecmp
V4.0 strcat
V7.0 _strcat32
V7.0 _strcat64
V4.0 strchr
V7.0 _strchr32
V7.0 _strchr64
V4.0 strcmp
V4.0 strcoll
V4.0 strcpy
V7.0 _strcpy32
V7.0 _strcpy64
V4.0 strcspn
V7.0 strdup
V7.0 _strdup32
V7.0 _strdup64
V4.0 strerror
V7.0 strfmon
V4.0 strftime
V4.0 strlen
V7.0 strncasecmp
V4.0 strncat
V7.0 _strncat32
V7.0 _strncat64
V4.0 strncmp
V4.0 strncpy
V7.0 _strncpy32
V7.0 _strncpy64
V6.2 strnlen
V4.0 strpbrk
V7.0 _strpbrk32
V7.0 _strpbrk64
V6.2 strptime
V7.0 _strptime32
V7.0 _strptime64
V4.0 strrchr
V7.0 _strrchr32
V7.0 _strrchr64
V7.0 strsep
V7.0 _strsep32
V7.0 _strsep64
V4.0 strspn
V4.0 strstr
V7.0 _strstr32
V7.0 _strstr64
V4.0 strtod
V7.0 _strtod32
V7.0 _strtod64
V4.0 strtok
V7.0 _strtok32
V7.0 _strtok64
V4.0 strtol
V7.0 _strtol32
V7.0 _strtol64
V4.0 strtoll
V7.0 _strtoll32
V7.0 _strtoll64
V4.0 strtoq
V7.0 _strtoq32
V7.0 _strtoq64
V4.0 strtoul
V7.0 _strtoul32
V7.0 _strtoul64
V4.0 strtoull
V7.0 _strtoull32
V7.0 _strtoull64
V4.0 strtouq
V7.0 _strtouq32
V7.0 _strtouq64
V4.0 strxfrm
V4.0 subwin
V7.0 swab
V7.0 swprintf
V7.0 swscanf
V8.3 symlink
V7.0 sysconf
V4.0 system
V4.0 tan
V4.0 tanh
V7.0 telldir
V7.0 tempnam
V4.0 time
V4.0 times
V4.0 tmpfile
V4.0 tmpnam
V7.0 _tmpnam32
V7.0 _tmpnam64
V4.0 toascii
V4.0 tolower
V4.0 _tolower
V4.0 touchwin
V4.0 toupper
V4.0 _toupper
V7.0 towctrans
V6.2 towlower
V6.2 towupper
V7.0 truncate
V4.0 ttyname
V7.3-2 ttyname_r
V7.0 tzset
V7.0 ualarm
V4.0 umask
V7.0 uname
V4.0 ungetc
V6.2 ungetwc
V8.3 unlink
V7.0 unsetenv
V7.0 usleep
V7.3 utime
V7.3 utimes
V4.0 va_arg
V4.0 va_count
V4.0 va_end
V4.0 va_start
V4.0 va_start_1
V4.0 vaxc$calloc_opt
V4.0 vaxc$cfree_opt
V4.0 vaxc$crtl_init
V4.0 vaxc$establish
V4.0 vaxc$free_opt
V4.0 vaxc$malloc_opt
V4.0 vaxc$realloc_opt
V4.0 vfork
V4.0 vfprintf
V7.3-1 vfscanf
V7.0 vfwprintf
V7.3-1 vfwscanf
V4.0 vprintf
V7.3-1 vscanf
V7.3-2 vsnprintf
V4.0 vsprintf
V7.3-1 vsscanf
V7.0 vswprintf
V7.3-1 vswscanf
V7.0 vwprintf
V7.3-1 vwscanf
V4.0 waddch
V4.0 waddstr
V4.0 wait
V7.0 wait3
V7.0 wait4
V7.0 waitpid
V7.2 wchar
V4.0 wclear
V4.0 wclrattr
V4.0 wclrtobot
V4.0 wclrtoeol
V7.0 wcrtomb
V6.2 wcscat
V7.0 _wcscat32
V7.0 _wcscat64
V6.2 wcschr
V7.0 _wcschr32
V7.0 _wcschr64
V6.2 wcscmp
V6.2 wcscoll
V6.2 wcscpy
V7.0 _wcscpy32
V7.0 _wcscpy64
V6.2 wcscspn
V6.2 wcsftime
V6.2 wcslen
V6.2 wcsncat
V7.0 _wcsncat32
V7.0 _wcsncat64
V6.2 wcsncmp
V6.2 wcsncpy
V7.0 _wcsncpy32
V7.0 _wcsncpy64
V6.2 wcspbrk
V7.0 _wcspbrk32
V7.0 _wcspbrk64
V6.2 wcsrchr
V7.0 _wcsrchr32
V7.0 _wcsrchr64
V7.0 wcsrtombs
V7.0 _wcsrtombs32
V7.0 _wcsrtombs64
V6.2 wcsspn
V7.0 wcsstr
V7.0 _wcsstr32
V7.0 _wcsstr64
V6.2 wcstod
V6.2 wcstok
V7.0 _wcstok32
V7.0 _wcstok64
V6.2 wcstol
V7.0 _wcstol32
V7.0 _wcstol64
V4.0 wcstombs
V6.2 wcstoul
V7.0 _wcstoul32
V7.0 _wcstoul64
V6.2 wcswcs
V7.0 _wcswcs32
V7.0 _wcswcs64
V6.2 wcswidth
V6.2 wcsxfrm
V7.0 wctob
V4.0 wctomb
V7.0 wctrans
V6.2 wctype
V6.2 wcwidth
V4.0 wdelch
V4.0 wdeleteln
V4.0 werase
V4.0 wgetch
V4.0 wgetstr
V4.0 winch
V4.0 winsch
V4.0 winsertln
V4.0 winsstr
V7.0 wmemchr
V7.0 _wmemchr32
V7.0 _wmemchr64
V7.0 wmemcmp
V7.0 wmemcpy
V7.0 _wmemcpy32
V7.0 _wmemcpy64
V7.0 wmemmove
V7.0 _wmemmove32
V7.0 _wmemmove64
V7.0 wmemset
V7.0 _wmemset32
V7.0 _wmemset64
V4.0 wmove
V7.0 wprintf
V4.0 wprintw
V4.0 wrefresh
V4.0 write
V7.3 writev
V7.3-2 __writev64
V7.0 wscanf
V4.0 wscanw
V4.0 wsetattr
V4.0 wstandend
V4.0 wstandout

[Chris Scheers]

Craig A. Berry wrote:
>
> Many caveats and porting gotchas remain. For the table labeled "All
> OpenVMS Versions" I assumed V4.0 because I think that might be around
> the time a semi-viable CRTL came along, and if you really care about
> anything pre-7.x then you need a great deal more help than I can give
> you (for many reasons). Bu if someone knows a better definition of "all"
> than V4.0, please say so.

IIRC, VAXCRTL (and ADARTL) were added to the base VMS release in VMS V4.2.

To get VAXCRTL on earlier versions, you had to install the compiler.

--
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360 Internet: ch...@applied-synergy.com
Fax: 817-237-3074

[John E. Malmberg]

On 1/13/2018 10:41 AM, Chris Scheers wrote:
> Craig A. Berry wrote:
>>
>> Many caveats and porting gotchas remain. For the table labeled "All
>> OpenVMS Versions" I assumed V4.0 because I think that might be around
>> the time a semi-viable CRTL came along, and if you really care about
>> anything pre-7.x then you need a great deal more help than I can give
>> you (for many reasons). Bu if someone knows a better definition of "all"
>> than V4.0, please say so.
>
> IIRC, VAXCRTL (and ADARTL) were added to the base VMS release in VMS V4.2.
>
> To get VAXCRTL on earlier versions, you had to install the compiler.
>

The CRTL help is for the DECC runtime that was introduced with VAX/VMS
6.0 and Alpha/VMS 1.0.

That CRTL was backported to 5.5-2 (I do not know about earlier) and
packaged with the DEC C compiler to VAX with a attributable CRTL kit
that can be supplied with programs.

So the "All OpenVMS" versions would refer to 5.5-2 and later.

The GCC/VAX compiler can also use the DECC CRTL on those versions to get
better results than using the VAXCRTL.

And since I have an emulated VAX running, I still attempt to build VAX
kits for projects.

Regards,
-John
wb8...@qsl.net_work

[Craig A. Berry]

On 1/13/18 11:40 AM, John E. Malmberg wrote:
> On 1/13/2018 10:41 AM, Chris Scheers wrote:
>> Craig A. Berry wrote:
>>>
>>> Many caveats and porting gotchas remain. For the table labeled "All
>>> OpenVMS Versions" I assumed V4.0 because I think that might be around
>>> the time a semi-viable CRTL came along, and if you really care about
>>> anything pre-7.x then you need a great deal more help than I can give
>>> you (for many reasons). Bu if someone knows a better definition of "all"
>>> than V4.0, please say so.
>>
>> IIRC, VAXCRTL (and ADARTL) were added to the base VMS release in VMS
>> V4.2.
>>
>> To get VAXCRTL on earlier versions, you had to install the compiler.
>>
>
> The CRTL help is for the DECC runtime that was introduced with VAX/VMS
> 6.0 and Alpha/VMS 1.0.
>
> That CRTL was backported to 5.5-2 (I do not know about earlier) and
> packaged with the DEC C compiler to VAX with a attributable CRTL kit
> that can be supplied with programs.
>
> So the "All OpenVMS" versions would refer to 5.5-2 and later.

Thanks, that makes sense.

> The GCC/VAX compiler can also use the DECC CRTL on those versions to get
> better results than using the VAXCRTL.
>
> And since I have an emulated VAX running, I still attempt to build VAX
> kits for projects.

There are a handful of conversion functions that take quadwords that are
Alpha and Itanium only and generally have "ll" or "q" in the name, there
is the sigstack function that is VAX only, and then there are the ones
with "32" or "64" at end that are Alpha and Itanium only -- these are
the only cases where the version number itself is not enough to give you
platform support. One could add more columns to the output of my script
if indicating these cases is considered important.

[John Reagan]

Let me know if you'd like me to tweak that in the future. I'd be willing to provide some other representation as well. A CSV file or some easily processed?

[Craig A. Berry]

Thanks. I think this works well enough for what you guys inherited from
HP. I assume v8.5 will have a sizable list of new functions, and
depending on what those look like in online help, I may need to revisit
it. If the DocBook-based documentation becomes available then, parsing
that might be the most robust solution.

Side note: I hope the socket library docs get integrated with the CRTL
docs as the functions themselves were integrated into the CRTL quite
some time ago. It would also be nice to see a "first available in
<version>" line added to each function's description.

[Simon Clubley]

On 2018-01-13, Chris Scheers <ch...@applied-synergy.com> wrote:
> Craig A. Berry wrote:
>>
>> Many caveats and porting gotchas remain. For the table labeled "All
>> OpenVMS Versions" I assumed V4.0 because I think that might be around
>> the time a semi-viable CRTL came along, and if you really care about
>> anything pre-7.x then you need a great deal more help than I can give
>> you (for many reasons). Bu if someone knows a better definition of "all"
>> than V4.0, please say so.
>
> IIRC, VAXCRTL (and ADARTL) were added to the base VMS release in VMS V4.2.
>
> To get VAXCRTL on earlier versions, you had to install the compiler.
>

I've seen the later messages about DECC not being the same as VAX C,
but just for completion, here are the list of RTLs from VAX/VMS 4.6:

$ dir sys$library:*rtl*

Directory SYS$SYSROOT:[SYSLIB]

ADARTL.EXE;1 BASRTL.EXE;1 BASRTL2.EXE;1 COBRTL.EXE;1
FORRTL.EXE;1 LIBRTL.EXE;1 LIBRTL2.EXE;1 MTHRTL.EXE;1
PASRTL.EXE;1 PLIRTL.EXE;1 RPGRTL.EXE;1 SCNRTL.EXE;1
UVMTHRTL.EXE;1 VAXCRTL.EXE;2 VAXCRTL.JNL;1 VAXCRTL.OLB;1
VAXCRTLG.EXE;2 VAXCRTLG.JNL;1 VAXCRTLG.OLB;1 VMSRTL.EXE;1

Total of 20 files.

And here is the same list from VAX/VMS V4.0:

$ dir sys$library:*rtl*

Directory SYS$SYSROOT:[SYSLIB]

BASRTL.EXE;1 BASRTL2.EXE;1 COBRTL.EXE;1 FORRTL.EXE;1
LIBRTL.EXE;1 LIBRTL2.EXE;1 MTHRTL.EXE;1 PASRTL.EXE;1
PLIRTL.EXE;1 RPGRTL.EXE;1 VMSRTL.EXE;1

Total of 11 files.

And finally, the same list from VAX/VMS V3.7:

$ dir sys$library:*rtl*

Directory SYS$SYSROOT:[SYSLIB]

PASRTL.EXE;1 PLIRTL.EXE;3 RTLVECTOR.OBJ;1 VMSRTL.EXE;3

Total of 4 files.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Bill Gunshannon]

I thought PL1 was a third party product from Kednos?

bill

[Arne Vajhøj]

> I thought PL1 was a third party product from Kednos?

For VMS VAX 3.7/4.0/4.6??

Arne

[Bill Gunshannon]

For any of them. I was not aware that DEC/COMPAQ/HP ever did a VMS
version of PL1.

bill

[Arne Vajhøj]

> For any of them.  I was not aware that DEC/COMPAQ/HP ever did a VMS
> version of PL1.

I have never really used PL/I myself, so I have not paid
that much attention to PL/I.

But as I recall it then back in the those days it was a DEC
compiler - or at least branded as such.

I assumed that PL/I just like so much else got sold off in the
Bob Palmer era.

And either picked up by Kednos at that time or picked
up by somebody later selling it to Kednos.

But maybe someone more familiar with PL/I can
enlighten me.

Arne

[johnwa...@yahoo.co.uk]

Try using your favourite search engine and looking for

vax vms pl/1 software product description


Even before the days of search engines, a look
at the index for the VMS distribution CDs might
have provided the enlightenment you seek.

Have a lot of fun.

[Arne Vajhøj]

I did some search.

22-Dec-1998 Tom Linden posted to comp.os.vms:

<quote>
Just an informative note that Kednos has taken over sales and support of
the PL/I compiler for VAX VMS, OpenVMS Alpha and Digital Unix.
</quote>

Arne

[Bill Gunshannon]

I guess now there is no more PL1 for VMS. Hope Tom
is enjoying his retirement.

bill

[Arne Vajhøj]

The Kednos web site says:

<quote>
Kednos has closed its doors!

After many years supplying PL/I compilers to OpenVMS and Tru64 UNIX
users around the world, from October 2016, Kednos will cease trading.
The PL/I compilers, run-time libraries and integration tools will no
longer be updated or supported by Kednos. Licenses for commercial
purposes can still be obtained on an "as is" basis, here.

This website will remain as a place to download software kits for those
still holding valid licenses. It is also still possible to request a
hobbyist license and use the compilers in a non-commercial capacity.
</quote>

Definitely no PL/I on VMS x86-64.

But I don't even think that Kednos ported to Itanium. If I am correct
in that, then PL/I on VMS has been a dead end for quite some time.

I have no idea how many PL/I users that are left on VMS.

Arne

[Simon Clubley]

On 2018-01-14, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>
> Definitely no PL/I on VMS x86-64.
>

Last time I checked, we still didn't know what the situation is with
Ada on x86-64 either...

[DaveFroble]

I'm thinking that if it has no value, then contributing the latest stuff to VSI
and John Reagan might be a good thing to do. Not saying John wants it. Just
saying that might keep it from being totally lost.


--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Arne Vajhøj]

On 1/14/2018 8:21 PM, Simon Clubley wrote:
> On 2018-01-14, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> Definitely no PL/I on VMS x86-64.
>
> Last time I checked, we still didn't know what the situation is with
> Ada on x86-64 either...

Ada is ACT.

We may not know, but a guess would be that they would not port.
At least not until they see a significant market. I believe they
are cutting down on platforms not expanding.

Arne

[Ian Miller]

There was a OpenVMS ADA from Adacore but they stopped supporting it.
There is this one http://www.vmsadaall.org/index.php/en/

I hope VSI are talking to someone about ADA as there is definitely a need for a support OpenVMS ADA compiler

[Arne Vajhøj]

On 1/15/2018 11:19 AM, Ian Miller wrote:
> On Monday, January 15, 2018 at 2:31:54 AM UTC, Arne Vajhøj wrote:
>> On 1/14/2018 8:21 PM, Simon Clubley wrote:
>>> On 2018-01-14, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>>> Definitely no PL/I on VMS x86-64.
>>>
>>> Last time I checked, we still didn't know what the situation is with
>>> Ada on x86-64 either...
>>
>> Ada is ACT.
>>
>> We may not know, but a guess would be that they would not port.
>> At least not until they see a significant market. I believe they
>> are cutting down on platforms not expanding.
>

> There was a OpenVMS ADA from Adacore but they stopped supporting it.

Ah. I knew they were cutting down, but I did not know/recall that
VMS was already dropped.

> There is this one http://www.vmsadaall.org/index.php/en/

Interesting. And good initiative.

But with all due respect that web site look a little "new".

> I hope VSI are talking to someone about ADA as there is
> definitely a need for a support OpenVMS ADA compiler

It will certainly be easier to keep GNAT working on
VMS after the move to x86-64 (I assume that the backend
support for x86-64 is a lot better than for IA-64).

And while I think PL/I should have switched to
JVM as target platform, then I don't think
that will work for many Ada users (real time,
hardware close etc.).

[ACT actually did support JVM as platform up to 2013
version, but I suspect it got ditched due to low
demand]


Arne

[Stephen Hoffman]

Pragmatically? Searching the C PDF has worked fine for local use.
For the longer-term list? Update or replace SDL and extend, or
translate and replace the existing SDL definition files and SDL
language syntax to allow a single canonical definition of the APIs
including whether or not the API is documented, the version(s) and
patch levels involved, and generate a database for inclusion onto the
system distribution. The traditional information around to the first
available OpenVMS version for a particular language function is
probably headed somewhere different here though, given the approach
that languages such as Fortran are now following; of shipping the RTLs
with the upward and downward checks eliminated and new functions.
(That won't cover everything, as there'll still be dependencies on
underlying OpenVMS APIs.) This database-based SDL-like approach all
avoids having several different data sources that have to be modified
in parallel when some function call is added; some mix of doc files,
SDL, C headers, etc. It can also work across different languages and
RTLs. With the API database, tools such as LSEDIT and other IDEs, and
the documentation, and the compilers, can all access live data, which
can avoid the "fun" of dealing with install-time translations using SDL
/NOPARSE and ilk and needing to reinstall language kits to get current
definition files and download IDE updates for API changes. The PDF
generator can embed the latest bits or can potentially link to the live
definitions hosted locally or at the VSI galactic HQ web server.
LSEDIT and NetBeans didn't and variously don't update the API
definitions, and I'd wager that the third-party IDE folks would like to
avoid reverse-engineering OpenVMS updates to create and distribute
their own updates to reflect the OpenVMS changes. AFAICT, this whole
application-development area — from SDL definitions to TLB files and
OLB files and IDE integration and documentation integration and the
rest — really hasn't been looked at from end-to-end in far too many
years. The whole of the current implementation — I'd hesitate to use
the word "design" here — has accreted its share of warts. Plan on
decreasing numbers of new folks being interested in the
OpenVMS-traditional compile-link-debug command line approach and
the-big-PDF-API-doc-file approach, too.


--
Pure Personal Opinion | HoffmanLabs LLC

[johnwa...@yahoo.co.uk]

Do you have a definitive reference for "they stopped supporing
it"? There are signs from 2017 that although 'it' may have gone
away from the AdaCore website, 'it' can still be done, with or
without involving AdaCore.

In an Ada environment the usual assumption that the development
environment is the same as the deployment environment isn't
always true, so customer definitions of 'it' may need to be
clarified.

Specifically, look for a post from gérard Calliet to comp.lang.ada
on 2 Mar 2017, titled "Gnat Ada on OpenVMS is back", where
he talks about how Gnat Ada was used to move an existing
VMS/Alpha/Ada application to VMS/IA64/Ada.

Marginally related: Readers interested in Ada applications on
bare metal boxes (*truly* bare metal, not what some HYPErvisor
people call bare metal) might be interested in this 2017 talk
(an informative 15 minutes) from Tristan Gingold, who works
for AdaCore, and also wrote GHDL (which probably won't mean
much to most folk here unless they know what VHDL is):
https://archive.fosdem.org/2017/schedule/speaker/tristan_gingold/
https://archive.fosdem.org/2017/schedule/event/programming_rpi3/

The target Tristan chose for this brare-metal talk is RPi3
(without Linux). Some pros and cons of his choice, and the
resulting consequences, are briefly discussed in the
presentation. The demo application isn't the industyy default
"hello world" (which is actually a bit of a pain to build
from the ground up on a previously unsupported-by-Gnat processor,
because of the runtime library support it quietly drags in).

Interestingly given the news of the last few weeks, Tristan
mentions the importance of cacheability (or not) on device
accesses, and the possible implications of side effects,
and how to sort out cacheability in the particular target
environment used for his talk.

[Craig A. Berry]

On 1/14/18 6:01 PM, Arne Vajhøj wrote:

> Definitely no PL/I on VMS x86-64.
>
> But I don't even think that Kednos ported to Itanium. If I am correct
> in that, then PL/I on VMS has been a dead end for quite some time.

I think I heard there was a disagreement between HP and Kednos about who
should invest the resources to make the compiler work on Itanium. There
is not likely anything about x86_64 that would make that disagreement go
away. And of course rewriting it to use LLVM or some other back end
would be even more work than adapting it to a newer version of GEM.

> I have no idea how many PL/I users that are left on VMS.

There was at least one very big customer (maybe Volkswagen?). No idea if
they are still running Alpha or switched to something else.

[Simon Clubley]

On 2018-01-15, johnwa...@yahoo.co.uk <johnwa...@yahoo.co.uk> wrote:
> On Monday, 15 January 2018 16:19:48 UTC, Ian Miller wrote:
>>
>> There was a OpenVMS ADA from Adacore but they stopped supporting it.
>> There is this one http://www.vmsadaall.org/index.php/en/
>>
>> I hope VSI are talking to someone about ADA as there is definitely a need for a support OpenVMS ADA compiler
>
> Do you have a definitive reference for "they stopped supporing
> it"? There are signs from 2017 that although 'it' may have gone
> away from the AdaCore website, 'it' can still be done, with or
> without involving AdaCore.
>

Yes and No.

I was never able to get an Ada compiler built for VMS Alpha using
the pure FSF sources. The compiler you refer to appears to be have
been built using the GNAT Pro compiler as the starting point which
is an option not available to me and would make the process
considerably easier and more viable.

The issue is that GNAT is written in Ada which means you need an
Ada compiler to compile it.

The approach I took was to try to build a cross compiler gcc/binutils
toolchain on Linux for a VMS Alpha target. Using this approach, it
looks like either various bits might be missing or there are some
non-obvious steps needed which I have missed.

I should point out that I have built gcc cross compilers from source
a good many times and for a range of targets so the general process
is well known to me.

While I was not able to get Ada built, I was able to get a C cross
compiler built using the same method and binaries produced using
this Linux based cross compiler ran on VMS Alpha.

[Bill Gunshannon]

On 01/16/2018 08:21 AM, Simon Clubley wrote:
> On 2018-01-15, johnwa...@yahoo.co.uk <johnwa...@yahoo.co.uk> wrote:
>> On Monday, 15 January 2018 16:19:48 UTC, Ian Miller wrote:
>>>
>>> There was a OpenVMS ADA from Adacore but they stopped supporting it.
>>> There is this one http://www.vmsadaall.org/index.php/en/
>>>
>>> I hope VSI are talking to someone about ADA as there is definitely a need for a support OpenVMS ADA compiler
>>
>> Do you have a definitive reference for "they stopped supporing
>> it"? There are signs from 2017 that although 'it' may have gone
>> away from the AdaCore website, 'it' can still be done, with or
>> without involving AdaCore.
>>
>
> Yes and No.
>
> I was never able to get an Ada compiler built for VMS Alpha using
> the pure FSF sources. The compiler you refer to appears to be have
> been built using the GNAT Pro compiler as the starting point which
> is an option not available to me and would make the process
> considerably easier and more viable.

I started with GNAT from the first release from NYU. The chain
of development required that you use the previous release to
build the next in the chain. After ACT took it over the chain
was broken and some of the missing versions were not made available.
Thus, you need an Ada compiler to build the current Ada compiler.
So much for the "protection" of IP provided by the GPL.

>
> The issue is that GNAT is written in Ada which means you need an
> Ada compiler to compile it.

Exactly, see comments above. If you were keeping up with developments
when NYU was doing it that wasn't a problem. But, today, there are
pieces (deliberately?) missing.

>
> The approach I took was to try to build a cross compiler gcc/binutils
> toolchain on Linux for a VMS Alpha target. Using this approach, it
> looks like either various bits might be missing or there are some
> non-obvious steps needed which I have missed.
>
> I should point out that I have built gcc cross compilers from source
> a good many times and for a range of targets so the general process
> is well known to me.
>
> While I was not able to get Ada built, I was able to get a C cross
> compiler built using the same method and binaries produced using
> this Linux based cross compiler ran on VMS Alpha.

I would imagine that if you gathered up all the original NYU work
and started from the very beginning you wold reach a point after
ACT took over where the previous version would not build the next
version thus making it impossible for anyone but ACT to continue
the chain.

bill

[Simon Clubley]

On 2018-01-16, Bill Gunshannon <bill.gu...@gmail.com> wrote:
> On 01/16/2018 08:21 AM, Simon Clubley wrote:
>>
>> I was never able to get an Ada compiler built for VMS Alpha using
>> the pure FSF sources. The compiler you refer to appears to be have
>> been built using the GNAT Pro compiler as the starting point which
>> is an option not available to me and would make the process
>> considerably easier and more viable.
>
> I started with GNAT from the first release from NYU. The chain
> of development required that you use the previous release to
> build the next in the chain. After ACT took it over the chain
> was broken and some of the missing versions were not made available.
> Thus, you need an Ada compiler to build the current Ada compiler.
> So much for the "protection" of IP provided by the GPL.
>

IIRC, a number of years ago the FSF told Adacore to fix the need to
build with the immediately previous version of GNAT.

Certainly, when building a native mode GNAT compiler these days there
can be quite a jump in version numbers between the current GNAT version
and the version you are building without any problems being encountered.

The current rule for building a cross compiled GNAT toolchain is that
you build a native version which is the same version as the cross
compiled version you want to build and then you build the cross compiler
using this newly built native compiler.

For various targets, this works just fine but fails with an internal
compiler error when building it for a VMS Alpha target.

I have no plans to look at this again in the future as I have a full
range of other projects to do instead.

[Hunter Goatley]

On 1/14/2018 11:13 AM, Bill Gunshannon wrote:
> For any of them.  I was not aware that DEC/COMPAQ/HP ever did a VMS
> version of PL1.

As has been pointed out, they did. My first college classes on VMS were
using PL/I. It was my favorite upper-level programming language until I
finally had a chance to learn BLISS.

Several of my very early DECUS SIG tape contributions were written in PL/I.

Hard to believe that was more than thirty years ago....

--
Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
goath...@goatley.com http://hunter.goatley.com/

[gérard Calliet]

Le 15/01/2018 à 18:00, Arne Vajhøj a écrit :
> On 1/15/2018 11:19 AM, Ian Miller wrote:
>> On Monday, January 15, 2018 at 2:31:54 AM UTC, Arne Vajhøj wrote:
>>> On 1/14/2018 8:21 PM, Simon Clubley wrote:
>>>> On 2018-01-14, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>>>> Definitely no PL/I on VMS x86-64.
>>>>
>>>> Last time I checked, we still didn't know what the situation is with
>>>> Ada on x86-64 either...
>>>
>>> Ada is ACT.
>>>
>>> We may not know, but a guess would be that they would not port.
>>> At least not until they see a significant market. I believe they
>>> are cutting down on platforms not expanding.
>>
>> There was a OpenVMS ADA from Adacore but they stopped supporting it.
>
> Ah. I knew they were cutting down, but I did not know/recall that
> VMS was already dropped.
>
>> There is this one http://www.vmsadaall.org/index.php/en/
>
> Interesting. And good initiative.
>
> But with all due respect that web site look a little "new".

Aknowledged :)

The new initiative is to make available for free a built of the GNAT Ada
compiler -as is- .

The built has been made because of a port project to itanium which was
beginning a month after Adacore gave up any support for VMS.

The only validation we could make was using it for the port. The port is
successfull, ans it seems it works. The application is used to control
the automatic line 14 of uderground in Paris.

The business plan is very simple: anyone can use the built for free, and
we can propose support, determining specific perimeters with the
customer. The more we'll get support contracts, the more we can make
evolutions on the built.

We hoped we could get some help from VSI, but they think we are too
little (too "new", perhaps :) )to speak with them.

By the way, for the friends who want to help, we are now thinking about
extending our built with a VMS debug function (yes there is no debug now
in our build :( ), because we are negociating extending our support with
a customer. Any advice welcommed.

>
>> I hope VSI are talking to someone about ADA as there is
>> definitely a need for a support OpenVMS ADA compiler
>

Right. And I confirm it's no way with Adacore. Good people, got help
when we were rebuilding, but they do confirm the VMS story is finally
closed for them.

> It will certainly be easier to keep GNAT working on
> VMS after the move to x86-64 (I assume that the backend
> support for x86-64 is a lot better than for IA-64).
>

I'm not sure. GNAT Ada is gcc and VSI VMS will be llvm.
The port we have done begins cross-compiling a gcc, it'll be a total
different thing using llvm.
Adacore is studying now a transfer to llvm, but it is not for now, and
not for VMS.
[[we are on gcc 4.7, because newer version use c++ and last year no way
using c++ for a VMS port]]

[Simon Clubley]

On 2018-01-17, gérard Calliet <gerard....@pia-sofer.fr> wrote:
>
> The new initiative is to make available for free a built of the GNAT Ada
> compiler -as is- .
>
> The built has been made because of a port project to itanium which was
> beginning a month after Adacore gave up any support for VMS.
>

Well at least we now know that Ada on VMS is dead which was news to me. :-(

> The only validation we could make was using it for the port. The port is
> successfull, ans it seems it works. The application is used to control
> the automatic line 14 of uderground in Paris.
>

Are you planning to import new functionality from the current GNAT code
base or will your compiler be frozen at its current level of functionality ?

> The business plan is very simple: anyone can use the built for free, and
> we can propose support, determining specific perimeters with the
> customer. The more we'll get support contracts, the more we can make
> evolutions on the built.
>
> We hoped we could get some help from VSI, but they think we are too
> little (too "new", perhaps :) )to speak with them.
>

Did VSI tell you that or did they just not bother replying to your
emails ? If it's the latter, don't read too much into it as that has
apparently happened quite a bit in the past (based on comments here).

>>
> Right. And I confirm it's no way with Adacore. Good people, got help
> when we were rebuilding, but they do confirm the VMS story is finally
> closed for them.
>

That in itself is useful information. Thanks.

> I'm not sure. GNAT Ada is gcc and VSI VMS will be llvm.
> The port we have done begins cross-compiling a gcc, it'll be a total
> different thing using llvm.

Yes, it will probably be closer to the situation I found myself in with
my failed efforts trying to build the GNAT cross compiler on Linux (you
had the advantage of being able to start with a GNAT Pro compiler which
was not an option available to me.)

> Adacore is studying now a transfer to llvm, but it is not for now, and
> not for VMS.
> [[we are on gcc 4.7, because newer version use c++ and last year no way
> using c++ for a VMS port]]
>

That C++ requirement is a major problem for VMS. One advantage of
building cross compilers on Linux is that you can just use the
modern C++ compilers on Linux as part of the cross compiler build.

LLVM is even worse because they keep changing the LLVM source code to
use the latest C++ features.

I wish someone would make a nice portable lightweight compiler generator
toolchain with a good range of backend targets and wasn't full of bloat.

[gérard Calliet]

Le 17/01/2018 à 14:35, Simon Clubley a écrit :
> On 2018-01-17, gérard Calliet <gerard....@pia-sofer.fr> wrote:
>>
>> The new initiative is to make available for free a built of the GNAT Ada
>> compiler -as is- .
>>
>> The built has been made because of a port project to itanium which was
>> beginning a month after Adacore gave up any support for VMS.
>>
>
> Well at least we now know that Ada on VMS is dead which was news to me. :-(

No, no, there is our initiative (buy an Itanium, buy a VSI Licence, and
download here: www.vmsadaall.org :) )

>
>> The only validation we could make was using it for the port. The port is
>> successfull, ans it seems it works. The application is used to control
>> the automatic line 14 of uderground in Paris.
>>
>
> Are you planning to import new functionality from the current GNAT code
> base or will your compiler be frozen at its current level of functionality ?

As said a friend of mine: "with software everything depends on money".
We are planning more than helping Ada survive on VMS, we want to alow
for evolutions. But everything depends on number of subscriptions for
support.

>
>> The business plan is very simple: anyone can use the built for free, and
>> we can propose support, determining specific perimeters with the
>> customer. The more we'll get support contracts, the more we can make
>> evolutions on the built.
>>
>> We hoped we could get some help from VSI, but they think we are too
>> little (too "new", perhaps :) )to speak with them.
>>
>
> Did VSI tell you that or did they just not bother replying to your
> emails ? If it's the latter, don't read too much into it as that has
> apparently happened quite a bit in the past (based on comments here).

No, there are been a very long exchange with VSI, 2 presentations at
bootcamps, personal conversations. VSI wants a complete distribution, a
strong company for support, nothing like best efforts in an Open Source
alliance of consultants.
And perhaps they have a dream about Adacore... which could have became
realty if VSI had help initiatives on VMs Ada, helping to find renewal
of business interest for VMS Ada. I should have pretended I was IBM or
Oracle.

>
>>>
>> Right. And I confirm it's no way with Adacore. Good people, got help
>> when we were rebuilding, but they do confirm the VMS story is finally
>> closed for them.
>>
>
> That in itself is useful information. Thanks.
>
>> I'm not sure. GNAT Ada is gcc and VSI VMS will be llvm.
>> The port we have done begins cross-compiling a gcc, it'll be a total
>> different thing using llvm.
>
> Yes, it will probably be closer to the situation I found myself in with
> my failed efforts trying to build the GNAT cross compiler on Linux (you
> had the advantage of being able to start with a GNAT Pro compiler which
> was not an option available to me.)

In another world (with more investment on our Ada initiative) with time
and resources, perhaps something could be made re-playing our work for
Alpha.

>
>> Adacore is studying now a transfer to llvm, but it is not for now, and
>> not for VMS.
>> [[we are on gcc 4.7, because newer version use c++ and last year no way
>> using c++ for a VMS port]]
>>
>
> That C++ requirement is a major problem for VMS. One advantage of
> building cross compilers on Linux is that you can just use the
> modern C++ compilers on Linux as part of the cross compiler build.
>
> LLVM is even worse because they keep changing the LLVM source code to
> use the latest C++ features.
>
> I wish someone would make a nice portable lightweight compiler generator
> toolchain with a good range of backend targets and wasn't full of bloat.

Be patient. We'll get it :) .

>
> Simon.
>

[Simon Clubley]

On 2018-01-17, gérard Calliet <gerard....@pia-sofer.fr> wrote:
> Le 17/01/2018 à 14:35, Simon Clubley a écrit :
>> On 2018-01-17, gérard Calliet <gerard....@pia-sofer.fr> wrote:
>>>
>>> We hoped we could get some help from VSI, but they think we are too
>>> little (too "new", perhaps :) )to speak with them.
>>>
>>
>> Did VSI tell you that or did they just not bother replying to your
>> emails ? If it's the latter, don't read too much into it as that has
>> apparently happened quite a bit in the past (based on comments here).
> No, there are been a very long exchange with VSI, 2 presentations at
> bootcamps, personal conversations. VSI wants a complete distribution, a
> strong company for support, nothing like best efforts in an Open Source
> alliance of consultants.

Well VSI may have their reasons for rejecting you, but this is a company
which isn't exactly holding itself to their own public standards either.

This is a company which makes a really big deal out of CVE counts but
when someone asks for a CVE number from VSI they are forced to ask
VSI multiple times in order to try and get one.

The latest news is that a CVE number has finally been reserved but it
looks like I am not yet allowed to know the number and have to wait for
another email sometime this week.

What a mess. :-( If VSI respond in this way to the third party security
researchers, VSI are going to get absolutely hammered. I hope that the
changes Derrell appears to be trying to make means that CVE assignment
by VSI is much more efficient in the future.

Oh, and I don't want anyone blaming Clair or Derrell for this. They
do _NOT_ appear to be the problem here and it would be very unfair
indeed to suggest otherwise.

In fact, I will say that Derrell is coming across as an excellent
person on these issues and if the VSI management have any sense they
will listen to him big time.

[gérard Calliet]

Thanks for the analysis. I think there is a general problem with VMS
renewal. From Digital empire and VMS pride, talking one to one to the
Big Companies, and MIT contempt to unixes craftmen, to a little startup
having to use a business network, there is a gap. Big cultural issue.

And perhaps it's the same issue for the community herself. Perhaps we
could imagine getting learning lessons from the successfull (because
they have been pro-active) other communities.

But, times are going. I am sure the ecosystem will evolve.

(Don't speak now philosophy. I need help and pieces of advice for the
Ada debug (in VMS style).
1) debug Ada
2) debug VMS ecosystem
My project :) )

Gérard Calliet

[gérard Calliet]

(By the way, don't be too upset. I'm learning english reading "Pride and
Prejudice" :) )
>
> Gérard Calliet

[Norman F Raphael]

-----Original Message-----

From: gérard Calliet via Info-vax <info...@info-vax.com>

Sent: Wed, Jan 17, 2018 3:35 pm
Subject: Re: [New Info-vax] VSI, was: Re: Ada on VMS, was: Re: Making the CRTL version dependency information useful

> (By the way, don't be too upset. I'm learning english reading "Pride and Prejudice" :) ) > > Gérard Calliet

Bully!

Norman F. Raphael
Please reply to: norman....@ieee.org
"Everything worthwhile eventually
degenerates into real work." -Murphy