1 INFO-VAX	Tue, 13 Jun 2006	Volume 2006 : Issue 326       Contents:6 Re: (solved) Help for an OpenVMS/RDB/Java/JDBC newbie? Re: Accounting question  Re: Accounting question  Re: Accounting question  Re: Accounting question 4 Alphaserver 2100 needs a good home - South Cambs, UK' Re: Cost of used alphas vs 8086+charron ' Re: Cost of used alphas vs 8086+charron ' Re: Cost of used alphas vs 8086+charron ' Re: Cost of used alphas vs 8086+charron 2 Re: Default location of shareable images/libraries2 Re: Default location of shareable images/libraries2 Re: Default location of shareable images/libraries2 Re: Default location of shareable images/libraries FREE Webinar: OpenVMS Licensing  Re: GnuPG 1.4.3  Re: GnuPG 1.4.3  Re: GnuPG 1.4.3 # Re: New HP web based email package! # Re: New HP web based email package! . Re: Question about number of Vax System owners. Re: Question about number of Vax System owners. Re: Question about number of Vax System owners. Re: Question about number of Vax System owners. Re: Question about number of Vax System owners. Re: Question about number of Vax System owners  F ----------------------------------------------------------------------    Date: 12 Jun 2006 13:30:05 -0700B From: "dave.mcneil@bell.remove-this-part.ca" <dave.mcneil@bell.ca>? Subject: Re: (solved) Help for an OpenVMS/RDB/Java/JDBC newbie? C Message-ID: <1150144205.339597.220300@h76g2000cwa.googlegroups.com>   A Many thanks to all who helped.  I had two problems with my setup. G First off, Chris was right on, the JDBC driver I was using was designed B for Rdb 7.2.  I installed the correct JDBC drivers but still had a problem.  @ The second problem was 'No suitable driver" and was traced to an1 uppercase R in the URL in the Class.forName call: @ Class.forName("oracle.rdb.jdbc.RdbNative.Driver").newInstance();   Many thanks to all who helped!   Dave   Barratt, Chris (FMC) wrote: G > As a guess, I would check that the version of the JDBC driver you are A > using is compatible with the version of Rdb that you are using. G > Otherwise, logging a call with Oracle would seem the best idea. Given F > that the error is in the check up program - which is pretty straightC > forward - I imagine it will be a well known problem to support...  > 	 > Cheers,  > Chris  >  > > -----Original Message-----. > > From: dave.mcneil@bell.remove-this-part.ca  > > [mailto:dave.mcneil@bell.ca]' > > Sent: Thursday, 8 June 2006 6:30 AM  > > To: Info-VAX@Mvb.Saic.Com 6 > > Subject: Help for an OpenVMS/RDB/Java/JDBC newbie? > >  > > Hello all, > > F > > I am trying to develop a servlet class using JDBC to serve up someH > > departmental data on the web.  Can anyone give me pointers on how to? > > get it all together?  Any and all help gratefully received.  > > I > > I am using an Alpha running OpenVMS V7.3-2, Oracle RDB V7.1-430, Java $ > > 1.4.2. and Oracle's JDBC 7.2 (?) > > A > > After installing Oracle JDBC, when I run the test class thus:  > > < > > >def java$classpath JAVA$JRE_HOME_VMS:[]:[]rdbnative.jar > > >  > > >java "RdbJdbcCheckup" > > >user: dave  > > >password:whatever- > > >database:mynode:my_disk-path:my_database  > > + > > It fails in a most spectacular fashion:  > > ' > > **** Unhandled exception caught...0 ( > > **** Unhandled exception caught...1B( > > **** Unhandled exception caught...1B( > > **** Unhandled exception caught...1B( > > **** Unhandled exception caught...1B( > > **** Unhandled exception caught...1B > >  > > Continuing ... > > SIGBUS    10*  bus error > > = > > Full thread dump Classic VM (1.4.2-4.p2, native threads): E > >     "Finalizer" (TID:0x12a24e8, sys_thread_t:0x4a46390, state:CW,  > > native ID:0x4a8b380) prio=8 3 > >         at java.lang.Object.wait(Native Method)  > >         at@ > > java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111) > >         at@ > > java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127) > >         atC > > java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) C > >     "Reference Handler" (TID:0x12a2548, sys_thread_t:0x49f03e0, * > > state:CW, native ID:0x4a41380) prio=103 > >         at java.lang.Object.wait(Native Method) 5 > >         at java.lang.Object.wait(Object.java:429)  > >         atD > > java.lang.ref.Reference$ReferenceHandler.run(Reference.java:115)C > >     "Signal dispatcher" (TID:0x12a2580, sys_thread_t:0x49ed950, ( > > state:CW, native ID:0x3d7380) prio=5E > >     "main" (TID:0x12a2360, sys_thread_t:0x5e22a8, state:R, native  > > ID:0x7bd02d28) prio=5 1 > >         at rdb.JNI.SetDefTrans(Native Method)  > >         atB > > oracle.rdb.jdbc.common.AbstractNativeRdb.Connect(AbstractNativ > > eRdb.java:273) > >         atJ > > oracle.rdb.jdbc.common.CommonRdbSynch.Connect(CommonRdbSynch.java:136) > >         atA > > oracle.rdb.jdbc.common.Connection.<init>(Connection.java:226)  > >         atG > > oracle.rdb.jdbc.common.NativeConnect.connect(NativeConnect.java:96) H > >         at oracle.rdb.jdbc.rdbNative.Driver.connect(Driver.java:117) > >         at@ > > java.sql.DriverManager.getConnection(DriverManager.java:488) > >         at@ > > java.sql.DriverManager.getConnection(DriverManager.java:158): > >         at RdbJdbcCheckup.main(RdbJdbcCheckup.java:20) > > Monitor Cache Dump: ? > >     java.lang.ref.Reference$Lock@12A2558/12D8F50: <unowned> # > >         Waiting to be notified: / > >             "Reference Handler" (0x49f03e0) J > >     java.lang.Integer@12AA1C8/1306338: owner "main" (0x5e22a8) 1 entryJ > >     java.lang.Class@12A7338/1305940: owner "main" (0x5e22a8) 2 entriesD > >     java.lang.ref.ReferenceQueue$Lock@12A2500/12D93D0: <unowned># > >         Waiting to be notified: ' > >             "Finalizer" (0x4a46390)  > > Registered Monitor Dump:" > >     utf8 hash table: <unowned># > >     JNI pinning lock: <unowned> , > >     JNI global reference lock: <unowned>  > >     BinClass lock: <unowned>% > >     Class linking lock: <unowned> + > >     System class loader lock: <unowned> $ > >     Code rewrite lock: <unowned> > >     Heap lock: <unowned>; > >     Monitor cache lock: owner "main" (0x5e22a8) 1 entry : > >     Thread queue lock: owner "main" (0x5e22a8) 1 entry9 > >     Monitor registry: owner "main" (0x5e22a8) 1 entry  > > : > > %SYSTEM-F-OPCCUS, opcode reserved to customer fault at$ > > PC=FFFFFFFF80AB1ED4, PS=0000001B3 > > %TRACE-F-TRACEBACK, symbolic stack dump follows = > >   image    module    routine             line      rel PC 
 > >       abs  > > PCB > >  DECC$SHR                                   0 0000000000109ED4 > > FFFFFFFF80AB1ED4B > >  DECC$SHR                                                    ? > >       ? B > >  JAVA$JVM_SHR  INTERPRETER  Abort       38420 0000000000003F98 > > 00000000000AEFD8+ > >  JAVA$JVM_SHR  SIGNALS_MD  panicHandler B > >                                         35279 00000000000001B8 > > 000000000010ACC8/ > >  JAVA$HPI_SHR  INTERRUPT_MD  intrDispatchMD B > >                                         23817 0000000000000248 > > 00000000001666E8B > >  DECC$SHR                                   0 00000000001D7704 > > FFFFFFFF80B7F704B > >  DECC$SHR                                                    ? > >       ? B > >  DECC$SHR                                   0 00000000001D73CC > > FFFFFFFF80B7F3CCB > >  DECC$SHR                                                    ? > >       ? B > >  DECC$SHR                                   0 000000000003062C > > FFFFFFFF809D862CB > >  DECC$SHR                                                    ? > >       ? A > > ----- above condition handler called with exception 0000000C: ? > > %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual > > > address=00000000000000D8, PC=0000000005102CE0, PS=0000001B" > > ----- end of exception messageB > >                                             0 FFFFFFFF8009E09C > > FFFFFFFF8009E09C4 > >  RDBJDBCSHR72  RDBJDBC  Java_rdb_JNI_SetDefTransB > >                                         59085 000000000001E200 > > 0000000005102CE06 > >  JAVA$JVM_SHR  JAVA$INVOKE_NATIVE  sysInvokeNativeB > >                                          2479 00000000000002A0 > > 000000000010C1606 > >  JAVA$JVM_SHR  CLASSRUNTIME  invokeJNINativeMethodB > >                                         36909 0000000000000AF4 > > 000000000009F5947 > >  JAVA$JVM_SHR  CLASSRUNTIME  invokeLazyNativeMethod B > >                                         37109 00000000000011C4 > > 000000000009FC643 > >  JAVA$JIT_142_SHR  SUNGENERATOR_  InvokeVirtual B > >                                         34363 000000000000D8D8 > > 0000000004B6FBB8B > >                                             0 000000000538E098 > > 000000000538E098A > >  JAVA$JIT_142_SHR  SUNINTERFACE_  AlphaInvokeUncompiledMethod B > >                                         33946 00000000000002BC > > 0000000004B74DCCB > >                                             0 000000000538DD9C > > 000000000538DD9CA > >  JAVA$JIT_142_SHR  SUNINTERFACE_  AlphaInvokeUncompiledMethod B > >                                         33946 00000000000002BC > > 0000000004B74DCC5 > >  JAVA$JIT_142_SHR  SUNGENERATOR_  InvokeInterface B > >                                         34538 000000000000DF68 > > 0000000004B70248B > >                                             0 0000000005052E50 > > 0000000005052E50A > >  JAVA$JIT_142_SHR  SUNINTERFACE_  AlphaInvokeUncompiledMethod B > >                                         33946 00000000000002BC > > 0000000004B74DCC3 > >  JAVA$JIT_142_SHR  SUNGENERATOR_  InvokeSpecial B > >                                         34428 000000000000DB68 > > 0000000004B6FE48B > >                                             0 0000000004F90CCC > > 0000000004F90CCCA > >  JAVA$JIT_142_SHR  SUNINTERFACE_  AlphaInvokeUncompiledMethod B > >                                         33946 00000000000002BC > > 0000000004B74DCC3 > >  JAVA$JIT_142_SHR  SUNGENERATOR_  InvokeVirtual B > >                                         34363 000000000000D8D8 > > 0000000004B6FBB8B > >                                             0 0000000004DA415C > > 0000000004DA415CA > >  JAVA$JIT_142_SHR  SUNINTERFACE_  AlphaInvokeUncompiledMethod B > >                                         33946 00000000000002BC > > 0000000004B74DCC5 > >  JAVA$JIT_142_SHR  SUNGENERATOR_  InvokeInterface B > >                                         34538 000000000000DF68 > > 0000000004B70248B > >                                             0 0000000004D9C5D0 > > 0000000004D9C5D0A > >  JAVA$JIT_142_SHR  SUNINTERFACE_  AlphaInvokeUncompiledMethod B > >                                         33946 00000000000002BC > > 0000000004B74DCCB > >                                             0 0000000004D9B0BC > > 0000000004D9B0BCA > >  JAVA$JIT_142_SHR  SUNINTERFACE_  AlphaInvokeUncompiledMethod B > >                                         33946 00000000000002BC > > 0000000004B74DCC2 > >  JAVA$JIT_142_SHR  SUNGENERATOR_  InvokeStaticB > >                                         34477 000000000000DD18 > > 0000000004B6FFF8B > >                                             0 0000000004D149CC > > 0000000004D149CCA > >  JAVA$JIT_142_SHR  SUNINTERFACE_  AlphaInvokeUncompiledMethod B > >                                         33946 00000000000002BC > > 0000000004B74DCC+ > >  JAVA$JVM_SHR  EXECUTEJAVA  ExecuteJava B > >                                         38859 000000000000C50C > > 00000000000BCFACB > >  JAVA$JVM_SHR  JNI  jni_Invoke          39549 00000000000016C4 > > 00000000000C18F40 > >  JAVA$JVM_SHR  JNI  jni_CallStaticVoidMethodB > >                                         40788 0000000000005310 > > 00000000000C5540B > >  JAVA$JAVA  JAVA  Java$main_Jacket       9429 0000000000000FC4 > > 0000000000030FC4B > >  JAVA$JAVA  MAIN_JACKET  main           33170 0000000000000204 > > 000000000003C694B > >  JAVA$JAVA  MAIN_JACKET  __main             0 0000000000000084 > > 000000000003C514B > >  PTHREAD$RTL                                0 0000000000055FF8 > > 000000007BD31FF8B > >  PTHREAD$RTL                                0 0000000000030404 > > 000000007BD0C404 > >  > >  > > Dave McNeil + > > Bell Canada Advanced Technical Services ' > > dave.mcneil.remove-this-bit@bell.ca  > >    ------------------------------  % Date: Mon, 12 Jun 2006 15:41:43 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>   Subject: Re: Accounting question, Message-ID: <448DC372.712FAB45@teksavvy.com>   Ferry Bolhar wrote: A > Hm, I thought since I want to extract records form SYS$MANAGER: 3 > ACCOUNTNG.DAT (like the ACCOUNTING utility does), 0 > I need the format of the records in this file. > D > And I havn't found a definition for these records in Starlet, only@ > for the format of accounting messages sent by VMS (termination= > messages from macro $ACCDEF). But it seems these aren't the ( > same as the actual accounting records.    H The format of the accounting records is documented in the manuals. ThereD is no "formal" record layout that could be defined in a starlet typeC definition. But there are constant values for certain field values.  You'll find those in $ACRDEF    F Typically, the record itself contains a records type and a time stamp.F The byte after the time stamp contains a field header and field lengthF followed by the data. After "length" data begins the next field headerJ and so on until yov've processed the full length of the record you've read  B A field can contain a structured set of values.  So if you hit theG header "ACR$K_RESOURCE" , you can then expect a strucred list fo values F containing stuff like login date, status , number of images activated,C cpu_time, page faults etc etc etc. (this structure is documented in 	 $ACRDEF )   F If you hot the ACR$K_ID tag, you can expect a series of values such asA the PID, parent_pod, uic group, uic member, privileges, priority, @ followed by a series of offsets for string values. For instance,C off_username gives you offset to the start of the username. At that H offset, you find one byte defining how long the username is, followed by' that many bytes of text (the username).   H Obviously, different accounting record types have different fields. (theE SMTP receiver can gebnerate accounting records for each spam attempt, H and this is a "USER" type of accounting records with more of less just a8 text string containing the reason a message was refused.   ------------------------------  % Date: Mon, 12 Jun 2006 16:36:45 -0400 ' From: Dave Froble <davef@tsoft-inc.com>   Subject: Re: Accounting question9 Message-ID: <hK6dnUMMGvbVUhDZnZ2dnUVZ_t6dnZ2d@libcom.com>    Ferry Bolhar wrote:  > Larry Kilgallen: > C >>> Is the accounting record format documented somewhere (I have no B >>> VMS docs at hand, sorry!)? Is there is a definition in STARLET >>> or LIB? E >> It is in Starlet, but you don't want the accounting record format. A >> You want the auditing record format, which is also in Starlet.  > A > Hm, I thought since I want to extract records form SYS$MANAGER: 3 > ACCOUNTNG.DAT (like the ACCOUNTING utility does), 0 > I need the format of the records in this file. > D > And I havn't found a definition for these records in Starlet, only@ > for the format of accounting messages sent by VMS (termination= > messages from macro $ACCDEF). But it seems these aren't the ( > same as the actual accounting records. > < >>> If so, perhaps I could write a small C program for this.C >> As a last resort you could do that.  Other languages are better.  > 9 > Why? And which ones? (BTW: we have DEC C licenses only. 6 > But you don't mean MACRO-32 or BLISS-32, do you? ;-) >  > Greetings, Ferry >    Larry prefers ADA. I/m partial to Basic.  Tom is a PL/I proponent. Richard likes Cobol. John might suggest Pascal.  3 For most of the above, anything is preferable to C.    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  # Date: Mon, 12 Jun 2006 20:53:50 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>  Subject: Re: Accounting question2 Message-ID: <yvkjg.1791$Te7.1787@news.cpqcorp.net>   Ferry Bolhar wrote:   9 > Why? And which ones? (BTW: we have DEC C licenses only. 6 > But you don't mean MACRO-32 or BLISS-32, do you? ;-)  H    Most any programming language (and even a few text editors) that can = read in and can process binary data records can be used here.   I    Auditing and the auditing records will get you the data you want, and  8 you will need to use the auditing programming interface.  H    As stated elsewhere, accounting data requires you to process records I written to a file -- it's not going to provide you will the immediacy of  F the audits.  You will need to poll the accounting data, if you choose  accounting over auditing.   I    Details on all of this are in the OpenVMS documentation -- and again,  I please do consider access to the OpenVMS documentation, as that can save  G you time and effort, and can help you decide on programming approaches  I that can better assist with upward-compatibility -- and there are source  + code examples in the SA/NLSA/AskQ database.    ------------------------------  % Date: Mon, 12 Jun 2006 17:27:37 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>   Subject: Re: Accounting question, Message-ID: <448DDC3D.2DA94D65@teksavvy.com>   Hoff Hoffman wrote: J > written to a file -- it's not going to provide you will the immediacy ofG > the audits.  You will need to poll the accounting data, if you choose  > accounting over auditing.     A Could you provide just a quick description of the live capture of D auditing messages ? Someone mentioned a mailbox. I assume one uses aE system service to register a mailbox device to receive audit events ?  Which system service is that ?  @ (from there one can more easily find te relevant documentation).  ? Also, has there ever been consideration for a more direct OPCOM C interface for applications ? (getting them via a mailbox in a "raw" F form, as opposed to declaring a virtual terminal and getting formatted  messages destined for terminals)   ------------------------------    Date: 12 Jun 2006 15:23:56 -0700  From: chris@townleyc.demon.co.uk= Subject: Alphaserver 2100 needs a good home - South Cambs, UK C Message-ID: <1150151036.897361.217620@j55g2000cwa.googlegroups.com>   D Hi folks - work is throwing this out - last known to be working, has0 run Tru64 and VMS in various test configurations  F Not too sure about the config. but it is in a large pedestal, with twoC green storage racks. Not sure about memory, but it will probably be G reasonable, as they were in the production VMS cluster. Only one PSU at 	 the back.    Needs collection!     B I also have a microvax 3110, plus expansion box - used to run VMS,E albeit fairly slowly, but been sitting in a corner for quite a while.  Needs some cables.   Drop me a line if interested   Regards    --   Chris    ------------------------------  % Date: Mon, 12 Jun 2006 14:47:32 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 0 Subject: Re: Cost of used alphas vs 8086+charron, Message-ID: <448DB6C3.790C027E@teksavvy.com>   Wilm wrote: I > PersonalAlpha runs on x86-32 and (better still) AMD 32 bit architecture C > CHARON-AXP (the full production product) runs on x86-64 and (even % > better) on AMD 64 bit architecture.   F How is this done ? Wouldn't the base code expect architectural support for 64 bit values  ?  H Seems to me that the support of 32 bit cpus to emulate 64 bit woudl makeC the code highly inefficient (or the source really ugly with tons of  #ifdef )  F Now, what is *really* needed is an alpha emulator that runs on VAX ...  C Didn't DEC engineers have one early on VAX to start developping the G Alpha software before alphas were available ? Perhaps that could be put  into the freeware ?   G Or better yet, and FX32 or vest version to port from Alpha to VAX. This 7 way, we could upgrade VMS on VAXes to new versions. :-)    ------------------------------  % Date: Mon, 12 Jun 2006 16:58:28 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 0 Subject: Re: Cost of used alphas vs 8086+charron9 Message-ID: <1q-dnSd8T4zDSRDZnZ2dnUVZ_qWdnZ2d@libcom.com>    JF Mezei wrote: 
 > Wilm wrote: J >> PersonalAlpha runs on x86-32 and (better still) AMD 32 bit architectureD >> CHARON-AXP (the full production product) runs on x86-64 and (even& >> better) on AMD 64 bit architecture. > H > How is this done ? Wouldn't the base code expect architectural support > for 64 bit values  ?  F Back up a bit and think about what emulation software would be doing. E It is code that does what the hardware would do with an instruction.  F You can bet that there is significant code involved for each hardware G action.  The VAX or Alpha code is not being run on the emulator system.   J > Seems to me that the support of 32 bit cpus to emulate 64 bit woudl makeE > the code highly inefficient (or the source really ugly with tons of 
 > #ifdef )  I Not at all.  32 bit CPUs have been handling data longer than 32 bits for  ? a long time.  Understand, everything is data being manipulated.   H > Now, what is *really* needed is an alpha emulator that runs on VAX ... > E > Didn't DEC engineers have one early on VAX to start developping the I > Alpha software before alphas were available ? Perhaps that could be put  > into the freeware ?   G This was mentioned recently I believe.  It was stated that it was VERY  H slow.  I may be a bit confused about this, since it's been a few months.  I > Or better yet, and FX32 or vest version to port from Alpha to VAX. This 9 > way, we could upgrade VMS on VAXes to new versions. :-)    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Mon, 12 Jun 2006 17:04:55 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 0 Subject: Re: Cost of used alphas vs 8086+charron9 Message-ID: <suadnYIIoLx_SBDZnZ2dnUVZ_v2dnZ2d@libcom.com>   
 DBT wrote:K > Someone told me the other day that a  3Ghz Intel P4 would "probably" give 2 > similar performance running NT as would the DS10 > 1 > I haven't tried it on either so I wouldn't know  > J > As for cost, you can get a kitted out DS10 with OpenVMS base and EIP for
 > about $6000  > / > The Charon would no doubt be considerabl more  > G > I think Charon-Alpha in the next couple of years could be a very much 3 > considered alternative to buying an Itanic though  >  >   G It's really going to depend upon what CAN be used.  The itanics aren't  G real expensive, and the licensing is a better deal than it's ever been  = on VAX or Alpha.  As the VMS people tell us, and others have   experienced, it does work.  G Now, if you have something that will not run on Itanic, or Alpha, then  & the emulators give you another option.  G  From my perspective, having lost all but one VMS customer, nothing is  D going to help until the owners of VMS start to promote the product. F until then, it will be a constant attrition of current users, as each # finds an alternative, and a reason.    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Mon, 12 Jun 2006 17:21:17 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 0 Subject: Re: Cost of used alphas vs 8086+charron, Message-ID: <448DDAC1.E3515CDA@teksavvy.com>   Dave Froble wrote:H > It's really going to depend upon what CAN be used.  The itanics aren'tH > real expensive, and the licensing is a better deal than it's ever been> > on VAX or Alpha.  As the VMS people tell us, and others have > experienced, it does work.    F Post end-of-sales, the success of a platform depends on how many unitsD had been sold during the platform's lifetime.  Even within the VAX'sH lifetime, you find that there are fewer "newer" VAXEs available comparedG to VAXes that date from the heydays of VMS when sales were much higher.   H For the sake of discussion, should IA64 be end of saled on the same dateD as Alpha (in a couple of months), the Alpha market would continue to4 thrive while the IA64 market would wither very fast.  E This is a bit like TV programs. Once you've produced enough episodes, G you can go into syndication after you've stopped producing new ones and @ the program lives on in reruns.  Once enough VAXes or Alphas are/ produced, there is an after market that exists.   G With IA64, I am not sure that there will be much of an aftermarket. The A platform won't have lasted long enough to really make a long term % survival after the product is killed.   H Remember that there is no or little software that runs only on that IA64B thing.  There is software that runs only on VAX, and there is some+ software that runs on Alpha but not on VAX.    ------------------------------  % Date: Mon, 12 Jun 2006 17:21:21 -0400 ' From: Dave Froble <davef@tsoft-inc.com> ; Subject: Re: Default location of shareable images/libraries 9 Message-ID: <g9OdnUD6oeEhRBDZnZ2dnUVZ_tCdnZ2d@libcom.com>    Rich Jordan wrote:  > No end of fun on this project. > @ > MANMAN links against the image DBMSHR.EXE, which is located inD > SYS$COMMON:[SYSLIB] and installed /OPEN/HEADER/SHARE/PROTECTED and > linkable.  > C > My docs indicate that the linker will look for files qualified by B > /LIBRARY or /SHARE in a linker option file in a default locationE > ALPHA$LIBRARY, which on both the problem and a working MANMAN Alpha ( > system points to SYS$SYSROOT:[SYSLIB]. > H > The generated OPT file for MANMAN has 'dbmshr/share' as the first lineF > in the file.  However when the link occurs, LINKER complains that itB > cannot find the file DBMSHR.EXE in whatever my current directoryH > happens to be; SYS$COMMON:[SYSMGR]DBMSHR.EXE or DKB0:[TEST]DBMSHR.EXE. > F > If I set default to SYS$LIBRARY then the complaint about DBMSHR goesF > away (leaving me with the multiversion Rdb caca to deal with).  That > should NOT be necessary. > G > The 'working' MANMAN system does not have this problem, but generates ? > the exact same OPT files.  There is NO DBMSHR logical, and no = > LNK$LIBRARY logicals defined on the system, and no symbolic  > redefinition of LINK.  > . > What else could cause this kind of behavior? >   A Sticking my big nose into another place where it's likely to get   bloodied.  :-)  D  From some of your problems I'm getting the feeling that the MANMAN + build procedures are not very well written.   H When accessing the shared library stuff, the 'proper' logical to use is G SYS$SHARE.  That will find things in both SYS$SPECIFIC and SYS$COMMON.  G I don't see how this has ever worked unless someone moved files around  H to make it work.  From the perspective of the application, it shouldn't = care whether the files are in the SYS$SPECIFIC or SYS$COMMON.    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------    Date: 12 Jun 2006 15:06:12 -0700( From: "Rich Jordan" <jordan@ccs4vms.com>; Subject: Re: Default location of shareable images/libraries C Message-ID: <1150149972.115165.106850@h76g2000cwa.googlegroups.com>    Dave Froble wrote: > Rich Jordan wrote:" > > No end of fun on this project. > > B > > MANMAN links against the image DBMSHR.EXE, which is located inF > > SYS$COMMON:[SYSLIB] and installed /OPEN/HEADER/SHARE/PROTECTED and
 > > linkable.  > > E > > My docs indicate that the linker will look for files qualified by D > > /LIBRARY or /SHARE in a linker option file in a default locationG > > ALPHA$LIBRARY, which on both the problem and a working MANMAN Alpha * > > system points to SYS$SYSROOT:[SYSLIB]. > > J > > The generated OPT file for MANMAN has 'dbmshr/share' as the first lineH > > in the file.  However when the link occurs, LINKER complains that itD > > cannot find the file DBMSHR.EXE in whatever my current directoryJ > > happens to be; SYS$COMMON:[SYSMGR]DBMSHR.EXE or DKB0:[TEST]DBMSHR.EXE. > > H > > If I set default to SYS$LIBRARY then the complaint about DBMSHR goesH > > away (leaving me with the multiversion Rdb caca to deal with).  That > > should NOT be necessary. > > I > > The 'working' MANMAN system does not have this problem, but generates A > > the exact same OPT files.  There is NO DBMSHR logical, and no ? > > LNK$LIBRARY logicals defined on the system, and no symbolic  > > redefinition of LINK.  > > 0 > > What else could cause this kind of behavior? > >  > B > Sticking my big nose into another place where it's likely to get > bloodied.  :-) > E >  From some of your problems I'm getting the feeling that the MANMAN - > build procedures are not very well written.  > I > When accessing the shared library stuff, the 'proper' logical to use is H > SYS$SHARE.  That will find things in both SYS$SPECIFIC and SYS$COMMON.H > I don't see how this has ever worked unless someone moved files aroundI > to make it work.  From the perspective of the application, it shouldn't ? > care whether the files are in the SYS$SPECIFIC or SYS$COMMON.  >  > --6 > David Froble                       Tel: 724-529-0450@ > Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com > DFE Ultralights, Inc.  > 170 Grimplin Road  > Vanderbilt, PA  15486    Dave, ?      the problem in this case is not the specific versus common 8 problem.  The DBMSHR.EXE file is in the correct locationF (sys$common:[syslib]) and is properly installed.  The problem is that,F while the MANMAN linker option file references it on a line of its ownC as DBMSHR/SHARE, the linker keeps trying to locate DBMSHR.EXE in my D current directory, instead of in SYS$SHARE (or ALPHA$LIBRARY, or...)  B On the working system (which is running VMSV7.3 and slightly olderC DBMS/Rdb/CDD/Manman) the generated OPT file shows the same thing... @ DBMSHR/SHARE by itself on a line.  The links work properly thereF regardless of what the default directory of the process performing the link is.  G Something is making the linker look in the current directory instead of G the default location.  Its not a DBMSHR logical, a LNK$LIBRARY logical,  or anything else I can find.   Thanks again for responding.   Rich CCS    ------------------------------  % Date: Mon, 12 Jun 2006 19:38:20 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ; Subject: Re: Default location of shareable images/libraries + Message-ID: <448DFAD8.32CE84F@teksavvy.com>    Rich Jordan wrote:: > problem.  The DBMSHR.EXE file is in the correct locationH > (sys$common:[syslib]) and is properly installed.  The problem is that,H > while the MANMAN linker option file references it on a line of its ownE > as DBMSHR/SHARE, the linker keeps trying to locate DBMSHR.EXE in my F > current directory, instead of in SYS$SHARE (or ALPHA$LIBRARY, or...)   Isn't this expected behaviour ?   E I know that the image activator uses SYS$LIBRARY:.EXE as default file < specification, which can be overriden if tyou "DEFINE DBMSHRH disk:[dir]file.exe". But during the link, is there an implicit SYS$SHAREE ? Everytime I have used shareable images, I have always specified the " directory for the shareable image.  H Have you tried $DEFINE DMBSHR SYS$LIBRARY:DMBSHR.EXE   prior to invoking% the procedure that does the linking ?    ------------------------------    Date: 12 Jun 2006 18:34:59 -0700( From: "Rich Jordan" <jordan@ccs4vms.com>; Subject: Re: Default location of shareable images/libraries C Message-ID: <1150162498.994747.180710@h76g2000cwa.googlegroups.com>    JF Mezei wrote:  > Rich Jordan wrote:< > > problem.  The DBMSHR.EXE file is in the correct locationJ > > (sys$common:[syslib]) and is properly installed.  The problem is that,J > > while the MANMAN linker option file references it on a line of its ownG > > as DBMSHR/SHARE, the linker keeps trying to locate DBMSHR.EXE in my H > > current directory, instead of in SYS$SHARE (or ALPHA$LIBRARY, or...) > ! > Isn't this expected behaviour ?  > G > I know that the image activator uses SYS$LIBRARY:.EXE as default file > > specification, which can be overriden if tyou "DEFINE DBMSHRJ > disk:[dir]file.exe". But during the link, is there an implicit SYS$SHAREG > ? Everytime I have used shareable images, I have always specified the $ > directory for the shareable image. > J > Have you tried $DEFINE DMBSHR SYS$LIBRARY:DMBSHR.EXE   prior to invoking' > the procedure that does the linking ?    JF, F      no, I didn't try that, though it would probably work.  The linkerD manual stated that libraries defaulted to the location pointed to byC SYS$LIBRARY or ALPHA$LIBRARY logicals; its an older manual, perhaps  there was an error.   E      However I found a workaround after perusing the Oracle metalink. D There's an OPT file provided with DBMS called SYS$LIBRARY:DBMDML.OPTA that references DBMSHR/SHARE.  While the MANMAN OPT file does not C reference it, apparently it is still used, and adding SYS$SHARE: in A front of the DBMSHR/SHARE line fixed all the major MANMAN linking B problems.  There are still some warnings (which I will talk to the9 vendor about tomorrrow) but the thing is finally running.   F      I don't know why it is necessary to change that OPT file, nor whyE the MANMAN docs don't reference it if its a problem, but at least its  working.   Thanks for responding!   Rich CCS    ------------------------------    Date: 12 Jun 2006 11:19:07 -0700% From: "Laura" <lmcgaughey@parsec.com> ( Subject: FREE Webinar: OpenVMS LicensingC Message-ID: <1150136347.923540.129260@h76g2000cwa.googlegroups.com>   
 Greetings,  @ I'd like to invite you to sign up for our FREE Webinar, "OpenVMS? Licensing," to be held on Wednesday, July 12 at 12:00 noon MDT.   C This one-hour Webinar will entail Alpha/VAX licensing, licensing on B Integrity servers, and differences between licensing Alpha/VAX andG Integrity. We will look at terminology, licensing practices, compliance F licensing and licensing in an OpenVMS cluster. Some will be review and, some will be new; come join us and find out!  5 You can register for "OpenVMS Licensing" by going to:   4 http://www.parsec.com/general/promotion.php?p=20G55W  = Thank you! Please feel free to contact me should you have any 
 questions.   Laura McGaughey  PARSEC Group Direct: 720-962-9583 Toll Free: 888-472-7732  Fax: 303-763-9909  lmcgaughey@parsec.com  www.parsec.com  ; Check out our partner site for news, jobs, and resources at  www.openvmsplanet.org!   ------------------------------  + Date: Mon, 12 Jun 2006 15:05:05 -0500 (CDT) * From: sms@antinode.org (Steven M. Schweda) Subject: Re: GnuPG 1.4.32 Message-ID: <06061215050593_2022872F@antinode.org>  7 From: John Malmberg <malmberg@dskwld.zko.hp.compaq.dec>   F > There are a few possible ways to emulate AF_UNIX sockets on OpenVMS./ > [... some potentially useful suggestions ...]   F    As I said, "actual work".  My guess is that trying to substitute anG AF_INET socket would be the eaiest path, but working AF_UNIX sockets in F the C RTL would make the whole project much easier.  It's difficult toE say who will put in the required effort first.  I can be pretty lazy, A and C RTL enhancements of this sort can be pretty slow in coming.   H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------  % Date: Mon, 12 Jun 2006 17:12:44 -0400 ' From: Dave Froble <davef@tsoft-inc.com>  Subject: Re: GnuPG 1.4.39 Message-ID: <HaWdnRoa_5EqShDZnZ2dnUVZ_vWdnZ2d@libcom.com>    Steven M. Schweda wrote:9 > From: John Malmberg <malmberg@dskwld.zko.hp.compaq.dec>  > G >> There are a few possible ways to emulate AF_UNIX sockets on OpenVMS. 0 >> [... some potentially useful suggestions ...] > H >    As I said, "actual work".  My guess is that trying to substitute anI > AF_INET socket would be the eaiest path, but working AF_UNIX sockets in H > the C RTL would make the whole project much easier.  It's difficult toG > say who will put in the required effort first.  I can be pretty lazy, C > and C RTL enhancements of this sort can be pretty slow in coming.   F If there are multiple products which use the AF_UNIX sockets (which I I don't know a damn thing about) that it would be desirable to run on VMS,  C I'd think that providing the capability one time would be a better  A approach than re-writing applications.  The applications may get  C continued development, and that would mean re-writing for each new  E release.  Providing the capability means no re-writing, at least for   that capability.  F Such capability should not 'need' to be in the C RTL.  I'd think that G another library, RTL or OLB, hitting the linker before the C RTL might  G work.  The biggest job might be specifying the capability and activity   of an AF_UNIX socket.    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  + Date: Mon, 12 Jun 2006 17:14:03 -0500 (CDT) * From: sms@antinode.org (Steven M. Schweda) Subject: Re: GnuPG 1.4.32 Message-ID: <06061217140317_2022872F@antinode.org>  ' From: Dave Froble <davef@tsoft-inc.com>   $ > [... AF_UNIX sockets v. C RTL ...]  H > Such capability should not 'need' to be in the C RTL.  I'd think that I > another library, RTL or OLB, hitting the linker before the C RTL might   > work.   D    No, it need not be anywhere in particular, but adding it anywhereG would be complicated, because on VMS now, (I suspect that) because only D AF_INET is allowed, any socket()-related action goes straight to theF TCP/IP code, where in a typical UNIX application, socket() and friends> may be AF_UNIX or AF_INET, so this is not true there.  VariousH posibilities come to mind, but something moderately complicated would beH needed to get the new socket() (et al.) to be used with AF_UNIX, and theE old (TCP/IP) socket() (et al.) to be used with AF_INET.  It's safe to > assume that no GNU developer is making such a distinction now.  D >   The biggest job might be specifying the capability and activity  > of an AF_UNIX socket.   &    A job, but perhaps not the biggest.  H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------    Date: 12 Jun 2006 11:28:26 -0700) From: "Sue" <susan_skonetski@hotmail.com> , Subject: Re: New HP web based email package!B Message-ID: <1150136906.322528.150300@f6g2000cwb.googlegroups.com>  C Thank you very much Bob, Leo the Business mgr is sending you email.    Sue    bob@instantwhip.com wrote: > Sue wrote:A > > Bob I would be interested in your feedback on trysecuresverer  > 7 > Yes, we have a winner ... the interface is wonderful!  > $ > Does it run under 7.1-2 alpha vms? >  > Quote please!  > > > Now all you vms resellers out there have an easy, unhackable> > out of the box vms based email solution to offer, so no more > whinning!    ------------------------------    Date: 12 Jun 2006 13:41:00 -0700) From: "Sue" <susan_skonetski@hotmail.com> , Subject: Re: New HP web based email package!C Message-ID: <1150144860.535755.124920@i40g2000cwc.googlegroups.com>   E Whats even better is that this company is very open to suggestions to G enhancments so your suggestions are taken seriously.  You can make this   what you want and need it to be.  D If you go to the web site there is a place for comments which I urge folks to do.   Sue      bob@instantwhip.com wrote: > Sue wrote:A > > Bob I would be interested in your feedback on trysecuresverer  > 7 > Yes, we have a winner ... the interface is wonderful!  > $ > Does it run under 7.1-2 alpha vms? >  > Quote please!  > > > Now all you vms resellers out there have an easy, unhackable> > out of the box vms based email solution to offer, so no more > whinning!    ------------------------------  % Date: Mon, 12 Jun 2006 10:39:18 -0700 % From: Crabs <IHateSpam@SpamSucks.com> 7 Subject: Re: Question about number of Vax System owners : Message-ID: <odednf1Fj_9aOxDZnZ2dneKdnZydnZ2d@comcast.com>  
 DBT wrote:< > I am curious how many Vax users there are still out there. > G > If you could, please email us with your current hardware and expected 	 > future.  > I > We are looking at offering Vax systems and Vax based hardware solutions  > N > We will not contact you unless you specifically ask us; we're just trying to > investigate the market.  >  > David  >  >  >  Yo Dave 'ol Chap! . Cheerio, Pip, Pip. Wink, wink, nudge, nudge...  B Got half a dozen VAXen of various flavours in my storage cabinet, 7 however that does not mean that I use them anymore. 8-(   & Howz life treating you?  Good, I hope.   TomC a.k.a., "Crabs"    ------------------------------  % Date: Mon, 12 Jun 2006 14:09:39 -0400 C From: "David Turner, Island Computers US Corp" <dbturner@icusc.com> 7 Subject: Re: Question about number of Vax System owners : Message-ID: <U5ijg.71215$QU3.23725@bignews8.bellsouth.net>   Tom... Excellent Thanks   , VMS Alpha sales are good - unix not so good.D Those damned cheap Linux PC/Server boxes aren't helping Tru64 sales.  9 That's why we're looking at expanding to "EVERYTHING VMS"        --     David B Turner Island Computers US Corp 2700 Gregory St, Suite 180 Savannah GA 31404  Tel: 912 447 6622 X201 Cell: 912 447 6622 X251  Fax: 912 201 0402  Email: dbturner@icusc.com  Web: http://www.islandco.com% ===================================== < All orders are subject to the following terms and conditions. of sale. These should be read before ordering.% http://www.islandco.com/warranty.html   2 "Crabs" <IHateSpam@SpamSucks.com> wrote in message4 news:odednf1Fj_9aOxDZnZ2dneKdnZydnZ2d@comcast.com... > DBT wrote:> > > I am curious how many Vax users there are still out there. > > I > > If you could, please email us with your current hardware and expected  > > future.  > > K > > We are looking at offering Vax systems and Vax based hardware solutions  > > F > > We will not contact you unless you specifically ask us; we're just	 trying to  > > investigate the market.  > > 	 > > David  > >  > >  > >  > Yo Dave 'ol Chap! 0 > Cheerio, Pip, Pip. Wink, wink, nudge, nudge... > C > Got half a dozen VAXen of various flavours in my storage cabinet, 9 > however that does not mean that I use them anymore. 8-(  > ( > Howz life treating you?  Good, I hope. >  > TomC > a.k.a., "Crabs"    ------------------------------  % Date: Mon, 12 Jun 2006 14:47:15 -0400   From: "DBT" <dbturner@icusc.com>7 Subject: Re: Question about number of Vax System owners 0 Message-ID: <128rdmd2582dvc7@news.supernews.com>  - Thanks - wasn't a reminder of our existence - H I just talked to a couple of end users and figured I need to jump on the	 bandwagon    --     David B Turner Island Computers US Corp 2700 Gregory St, Suite 180 Savannah GA 31404  Tel: 912 447 6622 X201 Cell: 912 447 6622 X251  Fax: 912 201 0402  Email: dbturner@icusc.com  Web: http://www.islandco.com% ===================================== < All orders are subject to the following terms and conditions. of sale. These should be read before ordering.% http://www.islandco.com/warranty.html   H "Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote in message- news:RVKtO8ubI4ik@eisner.encompasserve.org... 8 > In article <128r5on45qbaa51@news.supernews.com>, "DBT" <dbturner@icusc.com> writes:> > > I am curious how many Vax users there are still out there. > 
 >    Lots. > I > > If you could, please email us with your current hardware and expected  > > future.  > < >    We know who you are and how to find you if we need you. > K > > We are looking at offering Vax systems and Vax based hardware solutions  >  >    We already have ours. > F > > We will not contact you unless you specifically ask us; we're just	 trying to  > > investigate the market.  >  >    You just did.  8) > C >    No, really, we haven't forgotten you as someone we can call if  >    we're looking for a VAX.  >    ------------------------------  % Date: Mon, 12 Jun 2006 15:14:18 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 7 Subject: Re: Question about number of Vax System owners , Message-ID: <448DBD06.D38DAD35@teksavvy.com>  
 DBT wrote:< > I am curious how many Vax users there are still out there.  G At the time the total number of VMS was at 400,000, I had heard 100,000 F VAX systems. (so 25% of the VMS installed base still on VAX). With theF total number rumoured to now be at 300,000, I don't know if the rationC has changed. It could have gone higher is proportionally more alpha ( systems were migrated to non-HP systems.   ------------------------------  % Date: Mon, 12 Jun 2006 17:25:44 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 7 Subject: Re: Question about number of Vax System owners 9 Message-ID: <g9OdnUP6oeFfRxDZnZ2dnUVZ_tCdnZ2d@libcom.com>    Bob Koehler wrote:U > In article <128r5on45qbaa51@news.supernews.com>, "DBT" <dbturner@icusc.com> writes: = >> I am curious how many Vax users there are still out there.  > 
 >    Lots. >   H >> If you could, please email us with your current hardware and expected
 >> future. > < >    We know who you are and how to find you if we need you. > J >> We are looking at offering Vax systems and Vax based hardware solutions >  >    We already have ours. > O >> We will not contact you unless you specifically ask us; we're just trying to  >> investigate the market. >  >    You just did.  8) > C >    No, really, we haven't forgotten you as someone we can call if  >    we're looking for a VAX.  >   H What you appear to be missing Bob is that David is trying to maintain a G 'business plan'.  Do that in a vacuum and it's worthless.  He needs to  E know what his potential market is, the size, and such.  I doubt he's  ) going to invest much before knowing that.   G If he doesn't determine that there is a market, then he won't be there    when you call looking for a VAX.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------    Date: 12 Jun 2006 14:57:30 -0700( From: "Rich Jordan" <jordan@ccs4vms.com>7 Subject: Re: Question about number of Vax System owners C Message-ID: <1150149450.679633.200240@i40g2000cwc.googlegroups.com>   > I know you said email but this is what I have time for, sorry.  G Two VAXen in house; MV3100-30 and a VS3100-30.  Former is a development B system for maintaining code for our last two VAX customers.  SpareA 3100-40 on the shelf if the MV dies.  The VS3100-30 is my desktop F system, used mainly for multiple terminal windows and burning VMS CDs.D If it dies it gets replaced by an old Alpha workstation.  None underG maintenance, and software support was dropped when HP started dithering  on VMS updates for VAX,   F Two customer sites remaining (three, but one is transitioning to AlphaG now).  MV3100-85 running some hard-to-port to nonVMS platform apps, but A the customer has no budget for upgrades; they still have hardware G support.  The other is a 3100-88 maintained for access to old data from  a former VAX-11 cluster.  ? We see no real prospects for future VAX sales, barring the very G unlikely desire to replace one of these (if it breaks, or with a faster D VAX).  Our in house VAX will probably be shut down when the last VAX customer retires their box.        Rich   ------------------------------   End of INFO-VAX 2006.326 ************************                                                                                                                                                                                                                                                                                                                                 Z|#E=٧
4|xR<ʠk6=,ZCa5)uG`jFv|UYvԜZ陽WȩU>C*ATKq5Oa,_4$#&\	EP[@!؍"wIҞ8%fIQhN񠒣,l rƱǯ3ƇS2/U۰1供 EeUq(% `LQqZMOv\Fuvb(yNt\Ml-{t{	]?eZ
y{ J[ERfqo<5mߌ}>* OI1=B `/ޥBs%GY.#)WZ.1Oc/( PNR0hRՠSs'['lfw:k+&Q;9bU":jAg*:3YOؔK-W0
ra
!ÕF5~@	=!$