1 INFO-VAX	Sat, 22 Apr 2000	Volume 2000 : Issue 224       Contents:/ Re: 24x7 Operations (was Re: Verify of Backups) ( Re: Alphastation 4/233 - internal drives) Re: Calculating Discordian dates from DCL  Re: Console Firmware From VMS  Re: Console Firmware From VMS  Re: Console Firmware From VMS  Re: DCL Hackery ! Re: Dropping DECnet..don't do it! ! Re: Dropping DECnet..don't do it!  Re: EMC Disk Storage
 Re: excursion 
 Re: excursion  Increase Card Record Count -- ! Re: Increase Card Record Count -- ! Re: Increase Card Record Count -- ! Re: Increase Card Record Count -- ! Re: Increase Card Record Count -- ! Re: Increase Card Record Count -- ! Re: Increase Card Record Count -- , Re: Infoserver CD-R (was: Verify of Backups), Re: Infoserver CD-R (was: Verify of Backups), Re: Infoserver CD-R (was: Verify of Backups), Re: Infoserver CD-R (was: Verify of Backups)( Interprocess ASt (to purge working sets), Re: Interprocess ASt (to purge working sets)9 Looking for a QVision 1024x768 EISA Card for DEC 2000-300  Re: Mozilla M15's out... Re: Mozilla M15's out...* Re: OpenVMS mail question: Attached files? VAX - Alpha upgrade assistance" Re: VAX - Alpha upgrade assistance" Re: VAX - Alpha upgrade assistance" RE: VAX - Alpha upgrade assistance" Re: VAX - Alpha upgrade assistance" RE: VAX - Alpha upgrade assistance" Re: VAX - Alpha upgrade assistance" Re: VAX - Alpha upgrade assistance" Re: VAX - Alpha upgrade assistance RE: Verify of Backups  RE: Verify of Backups  Re: Verify of Backups % Re: What's this option? - HW Manuals? % Re: What's this option? - HW Manuals?   F ----------------------------------------------------------------------  % Date: Fri, 21 Apr 2000 13:51:49 -0400 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>8 Subject: Re: 24x7 Operations (was Re: Verify of Backups)/ Message-ID: <39009533.5D98B5DD@vl.videotron.ca>   L Couldn't applications be told to hold processing for a few seconds to make a "snapshot" ?  N Implement some sort of staggered temporary suspension of processing to clear a: portion of the pipeline long enough to take its snapshot ?  " Sort of the on-line equivalent of:   STOP/QUEUE/NEXT  dismount drive START/QUEUE   K I.e. hold new transactions for a few seconds at entry point (web server for K instance), once transactions in progress are done, then dismount drive, and - then re-open the gates for normal processing.   N This way, during the few seconds when you dismount the drive, transactions areI not being processed. The files, while still opened, will not contain half  processed transactions.     ---  I For many applications, it is not enough to be able to restore yesterday's M disk, but also know exactly at what point in time the drive is being returned K to, so the owner of the data knows exactly what transactions have been lost @ (thus allowing them to take steps to recover those if possible).  K With this in mind, shouldn't a 7-24 type of application be required to have K some sort of janitor to not only checkpoint the files but also verify their 7 integrity/cleanup transactions in inconsistent states ?   I This way, you could remove a drive from a shadow set at any time. Run the I janitor utility which would remove/document any transactions that were in K progress at the time of the shadow break-up, and checkpoint the transaction S logs to indicate where that backup will end. Backup can then be done on that drive.    ------------------------------  % Date: Fri, 21 Apr 2000 14:08:16 -0500 % From: JM <vmswiz@geonospamcities.com> 1 Subject: Re: Alphastation 4/233 - internal drives O Message-ID: <DD8300A981B74594.5AB8684645C35472.D6F519C29A6DCBA5@lp.airnews.net>   7 > cstranslations <cstranslations@email.msn.com> writes: F > > So . . . I was hoping some suggestions on what I might be able to H > > replace the drive with and/or what other people might be using in a 
 > > 4/233.  H My Alphastation 200 4/233 has a 1.6" 4GB SEAGATE ST15230W SCA drive withD an SCA to 50 pin adapter. It fits in the middle drive slot with justE barely enough room to clear the memory simms. Been running for over a D year and there is no appreciable (as far as I can tell) problem with@ heat any more than a regular RZ drive. (Got the SCA adapter from www.computergeeks.com)  H 5400 RPM drives are your safest bet. They run cooler. The disk tray thatD comes with this system has holes to fit just about any possible 3.5"E drive. Two 1" drives is the best use of available slots. You will not F need any special adapters for standard 3.5" 50-pin narrow scsi drives.  H I've also had a full-height FUJITSU M2934S-512 4GB drive inside, but theF drive seemed to run VERY hot all the time. Too hot to touch. It is nowG in an external SCSI cabinet salvaged from an old DECpc 486 workstation.    YMMV   			*JM*    ------------------------------  % Date: Fri, 21 Apr 2000 20:26:45 +0100 . From: mpatt644 <mpatt644@netscapeonline.co.uk>2 Subject: Re: Calculating Discordian dates from DCL4 Message-ID: <3900AB75.EC9DD97C@netscapeonline.co.uk>  D Glad to be of service, I hope you will find it a usefull addition to
 your systems.    Thomas Dzubin wrote: > D > That is the single most useful piece of DCL code that I've seen inF > this newsgroup for months...I will immediately add this to all of my > programs.   > I verily proclaim it to be so!> > (see also: http://www.cs.cmu.edu/~tilt/principia/body.html ) > G >    "Today is Setting Orange, the 37th day of Discord, Anno Mung 3166; ' >     and the moon is waning gibbous. "  >  > Thomas Dzubin  > 1 > mpatt644 <mpatt644@netscapeonline.co.uk> wrote:  > > Hi, Q > >       Working in the finance sector I keep getting asked for the current date K > > in Discordian format, I couldn't find any routines or lexicals to do it G > > for me so I hacked together the attached bit of DCL. I though't I'd K > > share it here in case anyone else find's it usefull. Obviously the moon ( > > phases part is just a bit of fun ;-) >  > > Martyn.  >  > > --- Cut here --- > > $save_verify = f$verify(0) > <code snipped> > > $return  >  > --N > ---------------------------------------------------------------------------- > Thomas Dzubin ) > Vancouver, Saskatoon, or Calgary CANADA    ------------------------------   Date: 21 Apr 2000 18:09:55 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)& Subject: Re: Console Firmware From VMS6 Message-ID: <8dq5hj$quv$1@mailint03.im.hou.compaq.com>  H In article <39008BB8.614563FD@home.nl>, Dirk Munk <munk@home.nl> writes: :Hoff Hoffman wrote:( :>       $ x=f$getsyi("PALCODE_VERSION")  ' :I assume you mean "CONSOLE_VERSION" ??   F   Nope.  I meant PALCODE_VERSION.  If you want to know the SRM consoleG   version rather than the console firmware version, then then yes, use  E   the CONSOLE_VERSION value -- with the exception of requirements for E   certain commands (eg: those needed for OpenVMS Galaxy), OpenVMS is  H   generally more interested in the PALcode version than the SRM console G   version...  (This whole area can certainly get somewhat confusing...)   C :And now a small question from me, do you also know how to show the I :system serial number from VMS (AY1234567 etc.) assuming it is registered  :in the Bios ?     BIOS?  What's that? :-)   J   Save for a very few Alpha and VAX system platforms, no Alpha and no VAX L   has a machine-readable serial number.  On those few Alpha and VAX systems L   that actually do have a machine-readable serial number, the value returnedM   does not necessarily match the serial number on the sticker.  Further, the  B   value is also often changeable, via jumper or console command.    E   For those folks looking for a serial number for reasons of software H   licensing, the Ethernet PROM is one approach potentially available -- I   please see the OpenVMS Ask The Wizard area for code that accesses this.   K   The OpenVMS LMF environment does not need/use/require the system to have  <   a serial number, and does not depend on any serial number.  F   You could certainly create your own console environment variable forI   this value, but getting at an arbitary value from OpenVMS requires some I   kernel-mode hackery.  (Only specific console environment variables can  1   be accessed via f$getenv and sys$getenv calls.)   N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Fri, 21 Apr 2000 20:07:04 GMT - From: "Richard D. Piccard" <piccard@ohio.edu> & Subject: Re: Console Firmware From VMS( Message-ID: <3900B4DE.515A4287@ohio.edu>   Hoff Hoffman wrote:   J > In article <39008BB8.614563FD@home.nl>, Dirk Munk <munk@home.nl> writes: > :Hoff Hoffman wrote: >    > [snip]   > G >   For those folks looking for a serial number for reasons of software I >   licensing, the Ethernet PROM is one approach potentially available -- K >   please see the OpenVMS Ask The Wizard area for code that accesses this.  >   Q And let me be among the first to jump in and ask any software vendors considering N such a user-hostile approach:  How are your customers going to feel when theirM field servant replaces the broken ethernet card with one that has a different O PROM, or they have to use their disaster-recovery site, and your software stops = working?  This is a technically possible, but very bad, idea.   = Hoff, I hope the Ask the Wizard discussion raises this issue.   #                                 RDP    --B ==================================================================B Dick Piccard                           Academic Technology ManagerB piccard@ohio.edu                                 Computer ServicesB http://oak.cats.ohiou.edu/~piccard/                Ohio University   ------------------------------  # Date: Fri, 21 Apr 2000 22:48:52 GMT  From: Dirk Munk <munk@home.nl>& Subject: Re: Console Firmware From VMS' Message-ID: <3900DAD7.3E9B7D25@home.nl>    Hoff Hoffman wrote:  > J > In article <39008BB8.614563FD@home.nl>, Dirk Munk <munk@home.nl> writes: > :Hoff Hoffman wrote:* > :>       $ x=f$getsyi("PALCODE_VERSION") > ) > :I assume you mean "CONSOLE_VERSION" ??  > H >   Nope.  I meant PALCODE_VERSION.  If you want to know the SRM consoleH >   version rather than the console firmware version, then then yes, useG >   the CONSOLE_VERSION value -- with the exception of requirements for F >   certain commands (eg: those needed for OpenVMS Galaxy), OpenVMS isI >   generally more interested in the PALcode version than the SRM console I >   version...  (This whole area can certainly get somewhat confusing...)   H But if one wants to know if the latest firmware is loaded on a system, IE suppose one has to look at the console version, because those are the A numbers on the firmware CD's. Of course in the description of the F firmware release the PALcode is also mentioned. It is obvious that forC VMS the PALcode version is more important, because that part of the  firmware is used by VMS.         > E > :And now a small question from me, do you also know how to show the K > :system serial number from VMS (AY1234567 etc.) assuming it is registered  > :in the Bios ? >  >   BIOS?  What's that? :-)   B Well there is something that is called "Alpha Bios" :-)), but I am refering to the SRM console.   > K >   Save for a very few Alpha and VAX system platforms, no Alpha and no VAX M >   has a machine-readable serial number.  On those few Alpha and VAX systems N >   that actually do have a machine-readable serial number, the value returnedN >   does not necessarily match the serial number on the sticker.  Further, theB >   value is also often changeable, via jumper or console command.  G Absolutely true. But I make a habit of setting the system serial number F with the appropriate console command. Compaq technical support, CompaqG license and software support registration is all done on serial number, G so it would be nice if there would be a simple way if this number could C be shown in VMS. When you have dozens of systems standing around on E several locations, it is not so easy to have a look at the sticker on  the box.     > G >   For those folks looking for a serial number for reasons of software I >   licensing, the Ethernet PROM is one approach potentially available -- K >   please see the OpenVMS Ask The Wizard area for code that accesses this.  > L >   The OpenVMS LMF environment does not need/use/require the system to have> >   a serial number, and does not depend on any serial number. > H >   You could certainly create your own console environment variable forK >   this value, but getting at an arbitary value from OpenVMS requires some J >   kernel-mode hackery.  (Only specific console environment variables can3 >   be accessed via f$getenv and sys$getenv calls.)  > P >  --------------------------- pure personal opinion ---------------------------N >    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Fri, 21 Apr 2000 22:13:28 +0200 + From: Jimmi Aakjaer <aakjaer@post7.tele.dk>  Subject: Re: DCL Hackery8 Message-ID: <v4d1gssl1ug9d62nv5ohj7ofs9kovddonu@4ax.com>  4 On Thu, 20 Apr 2000 10:30:08 -0700, "Wolf, Gerald J"# <Gerald.Wolf@F22.Boeing.com> wrote:   F >Is there a DCL procedure out there to disuser users who have passwordK >changed is older than a specified amount of time? Is there a way to notify M >these users before they are disusered using the above method.  We would like ( >to do this on a daily or monthly basis. > K >Please include the procedure if you can.  Is there a place on the internet ! >with contributed DCL procedures?  >  >Thank You,  >Gerry Wolf  >Gerald (Gerry) Wolf  	 Hi gerry    B Here you have a little piece of pascal code which i use to warn my  users about password expiration.  F I call it every time when my menu system is started up and it begin to* warn the users 14. days before expiration.  ) It is easy to convert to another language   
 Best regards     Jimmi      TYPE    item_list_3_record = record    buffer_length         : $word;    item_code             : $word;#   buffer_address        : unsigned; #   return_length_address : unsigned;   end;     VAR .  _status                : [volatile] unsigned;,  uai_item_list		: [VOLATILE] array [1..3] of item_list_3_record:=ZERO;  TYPE    item_list_3_record = record    buffer_length         : $word;    item_code             : $word;#   buffer_address        : unsigned; #   return_length_address : unsigned;   end;     VAR .  _status                : [volatile] unsigned;,  uai_item_list		: [VOLATILE] array [1..3] of item_list_3_record:=ZERO; +  pwd_change_date        : [VOLATILE] $quad; +  pwd_lifetime           : [VOLATILE] $quad; 7  username               : PACKED ARRAY [1..12] OF CHAR; /  pwd_change_date_asc    : varying [30] of char; !  pwd_lifetime_double    : double; /  pwd_lifetime_asc       : varying [30] of char; "  pwd_change_date_int    : integer;"  today_int              : integer;
  timestamp_1, $  timestamp_2            : timestamp;"  password_dage          : integer;   procedure check_PASSWORD;  Var   life_time : integer;  begin %  uai_item_list[1].buffer_length := 8; 1  uai_item_list[1].item_code     := uai$_pwd_date; >  uai_item_list[1].buffer_address := iaddress(pwd_change_date);%  uai_item_list[2].buffer_length := 8; 5  uai_item_list[2].item_code     := uai$_pwd_lifetime; ;  uai_item_list[2].buffer_address := iaddress(pwd_lifetime); /  IF ODD($getuai(,,USERNAME,uai_item_list)) then 	     begin       pwd_change_date_asc:= '';  M $asctim(pwd_change_date_asc.length,pwd_change_date_asc.body,pwd_change_date);   D $asctim(pwd_lifetime_asc.length,pwd_lifetime_asc.body,pwd_lifetime);3      gettimestamp(timestamp_1,pwd_change_date_asc);       gettimestamp(timestamp_2);       life_time := 0;<      if (substr(pwd_lifetime_asc,1,11) = '17-NOV-1858') THEN         life_time := maxint 	      else <         readv(substr(pwd_lifetime_asc,1,4),life_time,error:=
 continue);'      (* gdate =  days since 1.1.1900 *) =      pwd_change_date_int := gdate(dec(timestamp_1.year,4,4) + 7 dec(timestamp_1.month,2,2) + dec(timestamp_1.day,2,2)); 3      today_int := gdate(dec(timestamp_2.year,4,4) + 7 dec(timestamp_2.month,2,2) + dec(timestamp_2.day,2,2)); B      if (14 >= life_time - (today_int - pwd_change_date_int)) and C         ( 0 <   life_time - (today_int - pwd_change_date_int)) thenn
         beginaC           (* if less than 14 days before password change time wirtem something on the screen*)          end;	     end; o end;  +  pwd_change_date        : [VOLATILE] $quad;i+  pwd_lifetime           : [VOLATILE] $quad;.7  username               : PACKED ARRAY [1..12] OF CHAR; /  pwd_change_date_asc    : varying [30] of char;n!  pwd_lifetime_double    : double;n/  pwd_lifetime_asc       : varying [30] of char;e"  pwd_change_date_int    : integer;"  today_int              : integer;
  timestamp_1, $  timestamp_2            : timestamp;"  password_dage          : integer;   procedure check_PASSWORD;w Vare  life_time : integer;n beginr%  uai_item_list[1].buffer_length := 8;o1  uai_item_list[1].item_code     := uai$_pwd_date;A>  uai_item_list[1].buffer_address := iaddress(pwd_change_date);%  uai_item_list[2].buffer_length := 8;85  uai_item_list[2].item_code     := uai$_pwd_lifetime; ;  uai_item_list[2].buffer_address := iaddress(pwd_lifetime); /  IF ODD($getuai(,,USERNAME,uai_item_list)) then 	     begind      pwd_change_date_asc:= '';  M $asctim(pwd_change_date_asc.length,pwd_change_date_asc.body,pwd_change_date);i  D $asctim(pwd_lifetime_asc.length,pwd_lifetime_asc.body,pwd_lifetime);3      gettimestamp(timestamp_1,pwd_change_date_asc);       gettimestamp(timestamp_2);i      life_time := 0;<      if (substr(pwd_lifetime_asc,1,11) = '17-NOV-1858') THEN         life_time := maxints	      elsen<         readv(substr(pwd_lifetime_asc,1,4),life_time,error:=
 continue);'      (* gdate =  days since 1.1.1900 *)0;      pwd_change_date_int := gdate(dec(timestamp_1.year,4,4)n8 +dec(timestamp_1.month,2,2) + dec(timestamp_1.day,2,2));3      today_int := gdate(dec(timestamp_2.year,4,4) + 7 dec(timestamp_2.month,2,2) + dec(timestamp_2.day,2,2));aB      if (14 >= life_time - (today_int - pwd_change_date_int)) and C         ( 0 <   life_time - (today_int - pwd_change_date_int)) thenp
         begingC           (* if less than 14 days before password change time writeP something on the screen*)e         end;	     end; l end;    a   ------------------------------  # Date: Fri, 21 Apr 2000 19:45:45 GMT ( From: Terry Kennedy <terry@gate.tmk.com>* Subject: Re: Dropping DECnet..don't do it!' Message-ID: <FtDtK9.L1n@spcuna.spc.edu>g  2 JF Mezei <jfmezei.spamnot@vl.videotron.ca> writes:N >>   Indeed, 7.2 does run fine on VAXen. But my point was that these customersO >> had money to spend, but *Compaq* didn't get any until the customer perceived   >> there was something of value. >iM > No, I would think that no money was being spent because customers perceivedoM > VMS as dead and their existing system were in "maintenance" mode until theyu! > could be replaced with NT/UNIX.c  G   JF, you can put whatever words you want in other people's mouths, butlI please don't put them in mine. These are customers of mine with whom I'vehL had long relationships (all > 5 years, and 2 of them for well over 20 years)7 and your assertion is flat-out wrong about all of them.h  - 	Terry Kennedy             http://www.tmk.comh5         terry@tmk.com             Jersey City, NJ USA    ------------------------------  % Date: Fri, 21 Apr 2000 19:30:27 -0400o0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>* Subject: Re: Dropping DECnet..don't do it!/ Message-ID: <3900E491.232077AF@vl.videotron.ca>    Terry Kennedy wrote:I >   JF, you can put whatever words you want in other people's mouths, bute! > please don't put them in mine. 8  J Sorry , I did not mean to say it was your customer's views. But most of myL (former VMS) customers headed Palmer's call and stopped developping/building0 on VMS platform and are building on other stuff.   ------------------------------  % Date: Fri, 21 Apr 2000 12:51:32 -0700y  From: James.F.Duff@healthnet.com Subject: Re: EMC Disk Storage 8 Message-ID: <882568C8.006D18E5.00@WHDOM99.HEALTHNET.COM>   >tA >Of course, we'd still like to see SET HOST/DUP/... work like SETiF >HOST/SCSI (accept HSx command(s) from command line or image data in a >command proc.).  ! Actually, an API would be nice...o   Jim. -- James.F.Duff@healthnet.com Pure personal opinione   ------------------------------    Date: 21 Apr 2000 15:57:29 -0500- From: Graham Allan <allan@mnhep1.hep.umn.edu>s Subject: Re: excursion0 Message-ID: <w53hfcvqiiu.fsf@lanark.spa.umn.edu>  $ Dan Sugalski <dan@sidhe.org> writes:  1 > At 03:30 PM 4/20/00 -0400, Marc Lippmann wrote: G > >Just FYI, the latest release of Excursion is V7.1.n and is extremelymG > >robust. I use it to a *wide* variety of UNIX platforms and have beenn > >really pleased with it. > M > Have they got the thing doing anything better than 8-plane color? That was -: > the single most annoying thing about the older versions.  & No change there, as far as I can tell.   G. -- aI -------------------------------------------------------------------------n: Graham Allan - I.T. Manager - gta@umn.edu - (612) 624-50409 School of Physics and Astronomy - University of Minnesota:I -------------------------------------------------------------------------    ------------------------------  % Date: Fri, 21 Apr 2000 20:52:33 -0700r- From: "James Wilkinson" <james@elementyl.com>s Subject: Re: excursion2 Message-ID: <Tl9M4.216$7N2.64037@news.pacbell.net>  $ "Dan Sugalski" <dan@sidhe.org> wrote1 > At 03:30 PM 4/20/00 -0400, Marc Lippmann wrote:g= > >Just FYI, the latest release of Excursion is V7.1.n and isc9 > >extremely robust. I use it to a *wide* variety of UNIXe2 > >platforms and have been really pleased with it. >tC > Have they got the thing doing anything better than 8-plane color?sC > That was the single most annoying thing about the older versions.I  M Do any commercial X servers do better than 8 bit?  It is a real limitation, Iy agree.   Jamesh   ------------------------------  % Date: Fri, 21 Apr 2000 14:27:58 -0600-& From: "Richard Wright" <richw@unm.edu>& Subject: Increase Card Record Count --( Message-ID: <8dqe9a$19go$1@lynx.unm.edu>  F I was recently hired at the University of New Mexico ID Card Office toJ manage their Alpha/VMS system -- which is used to track student's ID CardsG in CCURE Ultra.  The system was initially installed with a maximum cardcK record count of 65,000, and we ordered (and installed a patch from Softwarec5 House) that would increase the card count to 250,000.i  K The "patch" was single faxed sheet which told us to install the patch usingLL the "CHOPTION" command, and from here we entered the option value "250,000."I We then entered the four passwords necessary to complete the patch.  ThisaK was the end of the fax, and needless to say, after bringing the system backa+ up, we are still limited to 65,000 records.   I Does anyone know the next step(s)?  Our database can handle the increasede- record count, and we have plenty of HD space.t    Thanks in advance for any ideas.   Richard Wright   ------------------------------  % Date: Fri, 21 Apr 2000 15:48:08 -0500m) From: "John E. Malmberg" <wb8tyw@qsl.net>e* Subject: Re: Increase Card Record Count --. Message-ID: <sg1fb415l6e32@corp.supernews.com>  5 Richard Wright <richw@unm.education> wrote in message " news:8dqe9a$19go$1@lynx.unm.edu... >AG > The "patch" was single faxed sheet which told us to install the patchy using C > the "CHOPTION" command, and from here we entered the option valuee
 "250,000."K > We then entered the four passwords necessary to complete the patch.  This H > was the end of the fax, and needless to say, after bringing the system back- > up, we are still limited to 65,000 records.f >fK > Does anyone know the next step(s)?  Our database can handle the increased-/ > record count, and we have plenty of HD space.f >c! Did you contact the vendor again?p   ------------------------------  % Date: Fri, 21 Apr 2000 14:06:19 -0700e! From: Shane.F.Smith@healthnet.com * Subject: Re: Increase Card Record Count --8 Message-ID: <882568C8.0073F128.00@WHDOM99.HEALTHNET.COM>  . From: Shane F Smith@FHS on 04/21/2000 02:06 PM     To:   Info-Vax@mvb.saic.coma cc:.+ Subject:  Re: Increase Card Record Count --s  4 ichard Wright <richw@unm.education> wrote in message" news:8dqe9a$19go$1@lynx.unm.edu... > G > The "patch" was single faxed sheet which told us to install the patch  using C > the "CHOPTION" command, and from here we entered the option value-
 "250,000."K > We then entered the four passwords necessary to complete the patch.  ThisuH > was the end of the fax, and needless to say, after bringing the system back- > up, we are still limited to 65,000 records.9 >BK > Does anyone know the next step(s)?  Our database can handle the increased:/ > record count, and we have plenty of HD space.n >o  M CHOPTION is not a standard VMS command, so it must be part of the package. ItnM sounds like you need to contact the vendor again, as John Malmberg suggested. N However, if you tell us who the vendor is and what the package is called, it's< possible that someone else may have some experience with it.  J The fact that you had to enter four passwords does make me nervous though,M vendors only usually put that kind of protection on something you have to pay B for. You're not trying to bypass a licencing restriction, are you?   Shane       H  #####   ---------------------------------------------------------------I #-O-O-# | Shane underbar S on pacbell dot net. Spam to abuse@127.0.0.1  |DH #  L  #  ---------------------------------------------------------------D  #===#   Don't blame HealthNet for anything I say. They're innocent.H   ###    OpenVMS: The operating system God runs the Earth simulation on.   ------------------------------  % Date: Fri, 21 Apr 2000 15:39:30 -0600-& From: "Richard Wright" <richw@unm.edu>* Subject: Re: Increase Card Record Count --' Message-ID: <8dqifg$lh4$1@lynx.unm.edu>r  2 John E. Malmberg <wb8tyw@qsl.net> wrote in message( news:sg1fb415l6e32@corp.supernews.com... >87 > Richard Wright <richw@unm.education> wrote in messageH$ > news:8dqe9a$19go$1@lynx.unm.edu... > >(I > > The "patch" was single faxed sheet which told us to install the patch  > usingmE > > the "CHOPTION" command, and from here we entered the option value  > "250,000."G > > We then entered the four passwords necessary to complete the patch.a ThisJ > > was the end of the fax, and needless to say, after bringing the system > back/ > > up, we are still limited to 65,000 records.i > >sC > > Does anyone know the next step(s)?  Our database can handle thei	 increaseda1 > > record count, and we have plenty of HD space.f > >w# > Did you contact the vendor again?s >a > J > Yes - we initally contacted the vendor, who referred us to a few crypticL pages in the CCURE reference manual -- none of which, it turned out, were ofK any help.  Subsequent attempts to reach the vendor have resulted in either:   J a)  allowing their support team to "service" the patch we already paid for at an "      tremendously high hourly rate5 b)  further page references to the ubiquitous manual.   K Their service support team may be able to help us next week, but out recordi" count is maxing out as we speak...  3 Again, thanks in advance for any further insight...l   ------------------------------  % Date: Fri, 21 Apr 2000 16:32:09 -0600a& From: "Richard Wright" <richw@unm.edu>* Subject: Re: Increase Card Record Count --' Message-ID: <8dqli5$f9e$1@lynx.unm.edu>   I No we paid for the patch, which is why we don't want to pay an additional H expense (i.e. a service technician) to install the patch we already paidD for.  The patch came from SCI Video Scan for the Ultra software from SoftwareHouse.  $ Anyone familiar with SCI Video Scan?   Thanks for the responses --i   ------------------------------  % Date: Fri, 21 Apr 2000 16:24:51 -0600 & From: "Richard Wright" <richw@unm.edu>* Subject: Re: Increase Card Record Count --' Message-ID: <8dql4f$tem$1@lynx.unm.edu>p  I No -- we paid for the patch, which is why we don't want to pay a separatesH expense (i.e. a technician) to have it installed.  We were faxed a patchL from SCI Video Scan for our Ultra system -- and after applying the patch, weA were still limited in our card count.  We've been contacting bothi> SoftwareHouse and SCI, but at this time, have had little luck.  # Anyone worked with SCI Video Scan ?a   -- Thanks for the responsesn   ------------------------------  % Date: Fri, 21 Apr 2000 19:42:39 -0400i0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>* Subject: Re: Increase Card Record Count --/ Message-ID: <3900E76C.8B5FA8A3@vl.videotron.ca>l  1 > > > up, we are still limited to 65,000 records.u  M Don't know exactly what the application does, but if the action of increasingsJ the file's capacity created a new version of the file, it is very possibleG that the application still has pointers to the old version of the file.   @ Shutting down and restarting the application might do the trick.  + Do you know the filename of the database ? eK Do a DIR/FULL on it, it will tell you if there are multiple versions and ifk5 the newest version is much bigger than the older one.d   Also,  INSTALL LIST filename L will tell you if the file is perhaps installed. (which means that request toJ access the file would go to the version of the file that is installed (eg:K older version). You can use the INSTALL REPLACE command to make it point to ! the new version of your database.y   ------------------------------    Date: 21 Apr 2000 16:42:22 -0500+ From: rjordan@Mars.mcs.net (Richard Jordan)d5 Subject: Re: Infoserver CD-R (was: Verify of Backups)t( Message-ID: <8dqhvu$113d$1@Mars.mcs.net>     / From: "Richard L. Dyson" <rick-dyson@uiowa.edu> 5 Subject: Re: Infoserver CD-R (was: Verify of Backups)c   <rick-dyson@uiowa.edu> wrote:   I > 	The other method uses an Infoserver 1000 (which I recent picked up forr > a few hundred $).oH > If you upgrade it to the last release of the software (v3.5a, I think) > there is a RECORDeH > command you can use to make an ODS-2 format CD-R disc *IFF* you have a > recorder on theirrC > specific list.  This includes the Sony CDU920 and CDU926, Philipsn > CDD521, as well as the YamahanE > CDR100.  There are about 6 models supported, but these are the moste > common.  The source needsLI > to be a hard drive connected to the Infoserver.  With this disk and the  > LAD/LAST protocols to J > OpenVMS systems you can transparently copy files to the hard drive until > you are full and? > then use the Infoserver to record this disk to the CD-R disc.    Rick, D      last I heard you had to buy an Infoserver that already had the D scribe or CDR option enabled or find some way to get the license andD enabling software.  Unless something has changed, the V3.5a softwareB by itself will not allow CDR operations unless those functions are  specifically enabled by license.  G      Anyone know if the license for CDR (and tape operations) are stillcE available, or cost for same?  My InfoTower (with IS1000) has disk ands VXT functions enabled.  E      Also, does anyone know if its possible to safely run an RZ26L orhD equivalent disk (one only) in an infotower with a couple CDs and oneC CDR drive?  I have no docs for the box so don't know its power and aE cooling capabilities (though I'd bet againt running 7200RPM drives inu it!)._        thanks for any info!    Rich Jordan2 rjordan@mcs.net=   ------------------------------  # Date: Fri, 21 Apr 2000 22:23:56 GMTf/ From: "Richard L. Dyson" <rick-dyson@uiowa.edu>t5 Subject: Re: Infoserver CD-R (was: Verify of Backups) ) Message-ID: <39008EAC.11A6170B@uiowa.edu>g  * Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7biti   Tim Shoppa wrote:i >  > Richard L. Dyson wrote:mQ > >         I make OpenVMS (i.e., ODS-2) CD-R discs all the time.  I too used the  > > above geocitesJ > > references, amoung others.  The first of two methods I found that work > > best (for me) are toK > > master an ISO 'image file' on an OpenVMS box with a free program from a  > > guy from Hungry thatL > > works on VAX and Alpha.  Then transfer the ISO file to my Win95 box with > > EasyCDPro and burn aJ > > CD-R disc.  Note, I also have all the versions of EasyCDPro and EasyCD > > Creator and nowcF > > CD Creator Deluxe and none of them will accept that the ISO file I? >                                                           ^^^1 > > provide. > < > Small nitpick (but it is, IMHO, an important distinction): > I > An ODS-2 disk image is *not* an "ISO file"!  In common usage "ISO file"oG > seems to mean "CD-ROM image", but not all CD-ROM images are ISO-9660,t* > and an ODS-2 disk image certainly isn't. > I > Of course, maybe you're just copying Adaptec's terminology, and they'resD > no hero when it comes to proper usage.  After all, they sell theirB > SCSI host adapters as "SCSI controllers", when a SCSI controller > it is *not*.   Hi Tim,   @ 	Indeed, I was sloppy in my terminology.  I should have used theD term "CD Image" file where I used "ISO Image" file.  I normally make6 true ISO 9660 image files and I used the term loosely.  @ 	I just wish Adaptec's newer versions of the product they boughtG from Incat would allow the input of the DFY$VMSCD image files. :)  Thene, I wouldn't have to keep old versions around.   Regards, rick -- yH Richard L. Dyson                                    rick-dyson@uiowa.eduH  _   _      _____                http://www-pi.physics.uiowa.edu/~dyson/H | | | |    |_   _|   Systems Analyst                     O: 319/335-1879H | | | | of   | |     The University of Iowa            FAX: 319/335-17536 | \_/ |     _| |_    Department of Physics & Astronomy-  \___/     |_____|   Iowa City, IA 52242-1479f   ------------------------------  % Date: Fri, 21 Apr 2000 20:29:59 -0400m+ From: Tim Shoppa <shoppa@trailing-edge.com>-5 Subject: Re: Infoserver CD-R (was: Verify of Backups)31 Message-ID: <3900BA47.2A0F306B@trailing-edge.com>u   Richard L. Dyson wrote:cI >         I just wish Adaptec's newer versions of the product they bought<I > from Incat would allow the input of the DFY$VMSCD image files. :)  Then . > I wouldn't have to keep old versions around.  C You might consider hooking a SCSI CD-writer straight to the VMS boxh= and burning there (with CDWRITE).  I do this and find it very = reliable, and this way you can avoid the intermediate step ofe% having to put the image file on a PC.e   Tim.   ------------------------------  # Date: Sat, 22 Apr 2000 03:26:09 GMT - From: goathunter@PROCESS.COM (Hunter Goatley)g5 Subject: Re: Infoserver CD-R (was: Verify of Backups) - Message-ID: <39011b6a.138847131@news.wku.edu>e  4 On Fri, 21 Apr 2000 22:23:56 GMT, "Richard L. Dyson" <rick-dyson@uiowa.edu> wrote:   A >	I just wish Adaptec's newer versions of the product they bought H >from Incat would allow the input of the DFY$VMSCD image files. :)  Then- >I wouldn't have to keep old versions around.n >fE Yeah, I was pretty irritated by that too.  My solution was to go with A CDRWIN from GoldenHawk (http://www.goldenhawk.com/).  Works well,tE doesn't cost much, and, as a side benefit, gives you complete controll/ of all indexing and gaps when making audio CDs.o     Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/e8 <goathunter@PROCESS.COM>     http://www2.wku.edu/hunter/   ------------------------------  % Date: Fri, 21 Apr 2000 14:03:20 -0700-+ From: Jay T. McCanta <jmccanta@immunex.com>:1 Subject: Interprocess ASt (to purge working sets)>8 Message-ID: <12f1gs0j783srfjmq3cub2s6hgbtfdor35@4ax.com>  D About a million years ago, I had a tool for VAX/VMS that would queueB up an AST to every process on the system to do a PURGEWS.  The was@ pre-MMG_CTLFLAGS.  However, it did a better job of trimming thanB current memory management does.  I have a VAX with a lot of queuesB that with single threaded symbionts.  There are a lot of processesB that hold about 400 pages each.  Id like to get them to trim back.B The tool would cause a paging storm for a bit as working sets were> purged and brought back, but overall, it did a pretty good, if brute-force, job.   F Does anyone know where this is?  I think I could recreate it if I knew4 how to queue inter-process ASTs.  That is the trick.  E -===================================================================-t9 Jay McCanta              |  My opinions are barely my owno; System Administrator     |  My employer doesn't necessarily ' Immunex Corp.            |  share them.IE -===================================================================--   ------------------------------  % Date: Fri, 21 Apr 2000 16:59:58 -0700.5 From: "cstranslations" <cstranslations@email.msn.com>c5 Subject: Re: Interprocess ASt (to purge working sets)o) Message-ID: <e$awz2#q$GA.236@cpmsnbbsa03>   K You can start with the Internals and Data Structures book however I believet1 that alot changed some where between 7.0 and 7.2.e  K VAXMAN wrote an application (Symbol) which (if memory serves) queues an ASTtF to another process on the system to either retrieve or create a symbolI within that process (which would serve as an illustration for queuing andeJ AST to another process). I seem to remember it being on the freeware CD orE maybe it was one of the freeware websites. Maybe he'll drop in with a # definitive answer as to a location.o   Joee    6 Jay T. McCanta <jmccanta@immunex.com> wrote in message2 news:12f1gs0j783srfjmq3cub2s6hgbtfdor35@4ax.com...F > About a million years ago, I had a tool for VAX/VMS that would queueD > up an AST to every process on the system to do a PURGEWS.  The wasB > pre-MMG_CTLFLAGS.  However, it did a better job of trimming thanD > current memory management does.  I have a VAX with a lot of queuesD > that with single threaded symbionts.  There are a lot of processesD > that hold about 400 pages each.  Id like to get them to trim back.D > The tool would cause a paging storm for a bit as working sets were@ > purged and brought back, but overall, it did a pretty good, if > brute-force, job.  > H > Does anyone know where this is?  I think I could recreate it if I knew6 > how to queue inter-process ASTs.  That is the trick. >oG > -===================================================================- ; > Jay McCanta              |  My opinions are barely my ownl= > System Administrator     |  My employer doesn't necessarilyo) > Immunex Corp.            |  share them.sG > -===================================================================-n   ------------------------------   Date: 22 Apr 2000 02:49:41 GMT% From: kellyb5fan@aol.com (KellyB5Fan)fB Subject: Looking for a QVision 1024x768 EISA Card for DEC 2000-300: Message-ID: <20000421224941.13317.00001711@ng-fs1.aol.com>  O I have recently been given 2 DEC 2000-300s.  I have installed VMS 7.2 and motifpK but the machines have the ATI Mach64 EISA card which is not compatable witheO VMS.  If anyone has or knows where I can pick up a couple of QVision EISA cardsiF for a resonable price please send me an email at KellyB5Fan@aol.com.    M Or if anyone knows of another compatable ISA card please pass that info alongo as well.   Thanks,   
 Kelly Meroney1N VMS Applications Developer (One of the few, the proud, fighting tooth and nail to hold on to it).   ------------------------------  % Date: Fri, 21 Apr 2000 15:44:18 -0500C) From: Mike Drabicky <drabicky#dallas.net>t! Subject: Re: Mozilla M15's out...a8 Message-ID: <1bf1gsgmp5gjgt2pcj5a5k73coq6cmhn4h@4ax.com>  C On Wed, 19 Apr 2000 10:47:11 -0600, Dan O'Reilly <dano@process.com>j wrote:  L >Be advised - I haven't gotten it to run worth a damn on Multinet (although,O >i'm not sure that's got anything to do with it).  I can send/receive mail thru(P >it, but it won't load any web pages.  It's also pretty slow, but it is at least >much more stable.  F Ditto that. Multinet V4.2a on OpenVMS V7.2-1. M14 at least worked; M15@ doesn't load any content to any pages. Sure makes browsing fast!   Mike   ------------------------------  # Date: Sat, 22 Apr 2000 03:22:13 GMT - From: goathunter@PROCESS.COM (Hunter Goatley)d! Subject: Re: Mozilla M15's out...o- Message-ID: <39011ad4.138697726@news.wku.edu>b  1 On Fri, 21 Apr 2000 15:44:18 -0500, Mike Drabickyh <drabicky#dallas.net> wrote:  D >On Wed, 19 Apr 2000 10:47:11 -0600, Dan O'Reilly <dano@process.com> >wrote:  >RM >>Be advised - I haven't gotten it to run worth a damn on Multinet (although, P >>i'm not sure that's got anything to do with it).  I can send/receive mail thruQ >>it, but it won't load any web pages.  It's also pretty slow, but it is at leastt >>much more stable.  > G >Ditto that. Multinet V4.2a on OpenVMS V7.2-1. M14 at least worked; M15nA >doesn't load any content to any pages. Sure makes browsing fast!a > # We're looking into this problem....t     Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/18 <goathunter@PROCESS.COM>     http://www2.wku.edu/hunter/   ------------------------------  # Date: Sat, 22 Apr 2000 03:56:27 GMTn- From: goathunter@PROCESS.COM (Hunter Goatley)e3 Subject: Re: OpenVMS mail question: Attached files?1- Message-ID: <390121f9.140526296@news.wku.edu>w  = On 20 Apr 2000 16:16:54 PDT, Fairfield@SLAC.Stanford.EDU (Ken 4 Fairfield; SLAC: 650-926-2924; FAX: 926-3515) wrote:  - >In article <38ff1cd9.8146323@news.wku.edu>,  5 >    	goathunter@PROCESS.COM (Hunter Goatley) writes:  >[...]C >> The funtionality is limited to one file, but with MultiNet's and_< >> TCPware's SMTP implementation, you can send one file as aG >> base64-encoded MIME attachment.  Even with the limitation, it can beu! >> very handy.  It's invoked via:  >> d0 >>     MAIL> send/noedit/foreign/type=1 file.ext >.I >        I (we) have known about the undocumented send/foreign within VMSaI >    Mail for quite a long  time.   However,  what is the "/type=1"?  And_G >    does "file.ext" need to be base64 encoded _first_, or does /type=1e5 >    request base64 encoding?  More details please?  V >5B For years now, MX, PMDF, and MultiNet have allowed you to send VMS> files to other VMS systems running one of those products using; SEND/FOREIGN.  The specified file was base64-encoded by the:E SMTP_MAILSHR (or MX_MAILSHR) and sent with special headers recognizedi by the other products.  > MX, MultiNet, and TCPware now also support sending a "generic"B base64-encoded file as an octet-stream attachment.  The /TYPE=1 isE specified to tell the *_MAILSHR "this should go out as a generic MIME D message with a base64-encoded attachment," as opposed to the special? VMS-only message you get without /TYPE=1.  You don't encode then/ file---MultiNet, TCPware, and MX do it for you.;  .     MAIL> send/noedit/foreign/type=1 alice.jpg     To:	    SMTP%"Joe@There"&     Subject:  Here's the Alice picture	     MAIL>:       Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/F8 <goathunter@PROCESS.COM>     http://www2.wku.edu/hunter/   ------------------------------  # Date: Fri, 21 Apr 2000 18:11:35 GMT>/ From: "John Nixon" <jorlnixon@worldnet.att.net>u' Subject: VAX - Alpha upgrade assistancesG Message-ID: <rR0M4.27578$WF.1136293@bgtnsc04-news.ops.worldnet.att.net>n  K My company is finally about to make the decision to tackle the VAX to Alpha K VMS conversion.   I am looking for recommendations for  software conversionoJ tools or consulting services, either within Compaq or external.  We are in the Atlanta GA. area.e  I The application is a fairly complex one that has evolved over the past 15rJ years and is mostly written in DECC.  There are some remnants of VAX MACRO code.t  G We have a programming staff, although an undermanned one.   We recentlyeC completed a huge project to convert from VAXC to DECC.  It was very-C difficult and took a long time.  Everyone is leery of another majorfJ coversion project at this time, so all we may really need is a little handB holding and assurance that this project won't be as difficult as C conversion.    ------------------------------   Date: 21 Apr 2000 18:21:55 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)+ Subject: Re: VAX - Alpha upgrade assistance 6 Message-ID: <8dq683$r0o$1@mailint03.im.hou.compaq.com>  y In article <rR0M4.27578$WF.1136293@bgtnsc04-news.ops.worldnet.att.net>, "John Nixon" <jorlnixon@worldnet.att.net> writes:a   ..J :The application is a fairly complex one that has evolved over the past 15K :years and is mostly written in DECC.  There are some remnants of VAX MACRO> :code.  !   What is the Macro32 code doing?T  H :We have a programming staff, although an undermanned one.   We recentlyD :completed a huge project to convert from VAXC to DECC.  It was veryD :difficult and took a long time.  Everyone is leery of another majorG :coversion project at this time, so all we may really need is a little 0H :hand holding and assurance that this project won't be as difficult as C :conversion.  D   Once you get to Compaq C, moving from OpenVMS VAX to OpenVMS AlphaF   is typically rather easier -- moving first from VAX C to Compaq C onD   OpenVMS VAX, then moving to Compaq C on OpenVMS Alpha is the exact"   path that I usually recommend...  E   There is a manual on moving Macro32 assembler code from OpenVMS VAXoH   over to OpenVMS Alpha in the OpenVMS documentation set.  Depending on H   exactly what the Macro32 code is doing, this can be an easy and quick I   task, or it can be more involved -- the typical user-mode Macro32 code -E   usually ports across with minimal hassles and minimal changes, but dI   kernel-mode code or code that rummages around within features specific tJ   to the VAX (eg: the VAX call stack) can be rather more involved to port    over.-  H   First evaluate if you really still need the Macro32 code, of course...J   (I've seen more than a few places that implemented something in Macro32,G   and never migrated to newer and equivilent features in OpenVMS, when >J   these features became available.  The Macro32 routines are sometimes no I   longer necessary, in other words...  And sometimes it can be easier andi5   faster to simply translate the Macro32 routines...)e   	--l  G   I can obviously recommend the Compaq Services folks, but it would be nF   interesting to know if there really is a need for that help first...  N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Fri, 21 Apr 2000 18:27:36 GMTu2 From: kilgallen@eisner.decus.org (Larry Kilgallen)+ Subject: Re: VAX - Alpha upgrade assistanceh' Message-ID: <2000Apr21.142736.1@eisner>a  y In article <rR0M4.27578$WF.1136293@bgtnsc04-news.ops.worldnet.att.net>, "John Nixon" <jorlnixon@worldnet.att.net> writes:t  I > We have a programming staff, although an undermanned one.   We recently(E > completed a huge project to convert from VAXC to DECC.  It was veryrE > difficult and took a long time.  Everyone is leery of another majorsL > coversion project at this time, so all we may really need is a little handD > holding and assurance that this project won't be as difficult as C
 > conversion.e  F My recollection of stories at the time was that for those saddled withE legacy C code, converting from VAX C to DEC C was much more than half  the battle of moving to Alpha.   ------------------------------  % Date: Fri, 21 Apr 2000 12:28:44 -0700y/ From: Terry Marosites <TMarosites@unitedad.com>.+ Subject: RE: VAX - Alpha upgrade assistance-M Message-ID: <1137A4A23A51D311B2D600105A1D5213019AEDAE@seantexch.unitedad.com>t  ; http://www.mi.infn.it/~calcolo/OpenVMS/ssb71/6459/6459p.htmg  J Try this link , I have used it several times and have had no problems with- the migrations.  It is a good place to start.n& Terry (Happy In North West Mountains)     -----Original Message-----t6 From: 	John Nixon [mailto:jorlnixon@worldnet.att.net] % Sent:	Friday, April 21, 2000 11:12 AM2 To:	Info-VAX@Mvb.Saic.Com ' Subject:	VAX - Alpha upgrade assistancet  K My company is finally about to make the decision to tackle the VAX to Alpha K VMS conversion.   I am looking for recommendations for  software conversionaJ tools or consulting services, either within Compaq or external.  We are in the Atlanta GA. area.l  I The application is a fairly complex one that has evolved over the past 15-J years and is mostly written in DECC.  There are some remnants of VAX MACRO code.h  G We have a programming staff, although an undermanned one.   We recently.C completed a huge project to convert from VAXC to DECC.  It was very1C difficult and took a long time.  Everyone is leery of another majoreJ coversion project at this time, so all we may really need is a little handB holding and assurance that this project won't be as difficult as C conversion.O   ------------------------------  % Date: Fri, 21 Apr 2000 15:30:38 -0400l0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>+ Subject: Re: VAX - Alpha upgrade assistance / Message-ID: <3900AC55.4B804364@vl.videotron.ca>s   Larry Kilgallen wrote:H > My recollection of stories at the time was that for those saddled withG > legacy C code, converting from VAX C to DEC C was much more than halfe  > the battle of moving to Alpha.  N Are there many instances where once you're converted your VAX-C code to pleaseL the pedandic DEC-C compiler, that there would still be assumptions left that poiters would be 32 bits ?  L I would thend to think that converting VAX-C to DEC-C would be closer to 85%$ of the task. Would that be correct ?  K However, having said this, if the use applications rely on middleware whichlK has not been ported to ALPHA (or whose funcionality was ported as a totallys@ separate product), then the task at hand might be more involved.   ------------------------------  % Date: Fri, 21 Apr 2000 12:44:02 -0700 / From: Terry Marosites <TMarosites@unitedad.com>O+ Subject: RE: VAX - Alpha upgrade assistanceeM Message-ID: <1137A4A23A51D311B2D600105A1D5213019AEDAF@seantexch.unitedad.com>P  9 Ahh the portability of C , not like that old Cobol stuff.1 Just thinking aloud- Terry  -    -----Original Message-----09 From: 	JF Mezei [mailto:jfmezei.spamnot@vl.videotron.ca] m% Sent:	Friday, April 21, 2000 12:31 PMV To:	Info-VAX@Mvb.Saic.Com-+ Subject:	Re: VAX - Alpha upgrade assistance    Larry Kilgallen wrote:H > My recollection of stories at the time was that for those saddled withG > legacy C code, converting from VAX C to DEC C was much more than halfe  > the battle of moving to Alpha.  G Are there many instances where once you're converted your VAX-C code to  pleaseL the pedandic DEC-C compiler, that there would still be assumptions left that poiters would be 32 bits ?  L I would thend to think that converting VAX-C to DEC-C would be closer to 85%$ of the task. Would that be correct ?  K However, having said this, if the use applications rely on middleware which K has not been ported to ALPHA (or whose funcionality was ported as a totally.@ separate product), then the task at hand might be more involved.   ------------------------------  % Date: Fri, 21 Apr 2000 15:46:49 -0400e" From: Dan Sugalski <dan@sidhe.org>+ Subject: Re: VAX - Alpha upgrade assistancee8 Message-ID: <4.3.1.0.20000421153854.01d68740@24.8.96.48>  * At 03:30 PM 4/21/00 -0400, JF Mezei wrote: >Larry Kilgallen wrote:MJ > > My recollection of stories at the time was that for those saddled withI > > legacy C code, converting from VAX C to DEC C was much more than halfm" > > the battle of moving to Alpha. >sO >Are there many instances where once you're converted your VAX-C code to pleasetM >the pedandic DEC-C compiler, that there would still be assumptions left that/ >poiters would be 32 bits ?-  H They generally still are on the Alphas, unless you take steps otherwise.   					Dan  I --------------------------------------"it's like this"-------------------02 Dan Sugalski                          even samurai? dan@sidhe.org                         have teddy bears and evenS;                                       teddy bears get drunkr   ------------------------------   Date: 21 Apr 2000 19:36:59 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)+ Subject: Re: VAX - Alpha upgrade assistancet6 Message-ID: <8dqakr$sri$1@mailint03.im.hou.compaq.com>  b In article <3900AC55.4B804364@vl.videotron.ca>, JF Mezei <jfmezei.spamnot@vl.videotron.ca> writes: :Larry Kilgallen wrote:oI :> My recollection of stories at the time was that for those saddled withsH :> legacy C code, converting from VAX C to DEC C was much more than half! :> the battle of moving to Alpha.   H   Having ported more than a little Compaq C code between OpenVMS VAX andI   OpenVMS Alpha, and having ported more than a little VAX C code forward mC   to Compaq C on OpenVMS VAX, this has (also) been my experience...   O :Are there many instances where once you're converted your VAX-C code to please= :the pedandic DEC-C compiler,-  F   That pesky and pedantic C compiler just found a really nasty bug in E   some local C code, a bug that has clearly been latent up until the  7   installation of the C V6.2 compiler flushed it out...m  H   If you want to render the compiler rather more mellow (or even rather @   more strict), you can use the available /STANDARD qualifier...  M :                             that there would still be assumptions left that  :poiters would be 32 bits ?t  B   By default, pointers are longwords on Compaq C on OpenVMS Alpha.  ;   Pointers are always longwords on Compaq C on OpenVMS VAX.p    M :I would thend to think that converting VAX-C to DEC-C would be closer to 85% % :of the task. Would that be correct ?w  G   Yes.  No.  Maybe.  In most cases, getting a clean compile on Compaq CmF   on one OpenVMS platform makes it rather likely you will get a clean G   compile on the other.  The "no" and "maybe" because it is still quitehE   possible to have features specific to the VAX scattered through theEE   code, or even C compiler features that are not directly portable tom   the other platform.o  L :However, having said this, if the use applications rely on middleware whichL :has not been ported to ALPHA (or whose funcionality was ported as a totallyA :separate product), then the task at hand might be more involved.n  F   Ayup.  The prerequisite products and packages must be considered as    part of any such operation...   N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Fri, 21 Apr 2000 14:54:59 -0700a5 From: "Larry D Bohan, Jr" <LBohan@dbc.spam_less..com>l+ Subject: Re: VAX - Alpha upgrade assistanceo2 Message-ID: <l8sAObFXo5xqtWeQgr96lUWnmtJv@4ax.com>  . On Fri, 21 Apr 2000 18:11:35 GMT, "John Nixon"# <jorlnixon@worldnet.att.net> wrote:   H >We have a programming staff, although an undermanned one.   We recentlyD >completed a huge project to convert from VAXC to DECC.  It was veryD >difficult and took a long time.  Everyone is leery of another majorK >coversion project at this time, so all we may really need is a little handlC >holding and assurance that this project won't be as difficult as Cd >conversion.  7 as others have commented,  the VAXC to DECC conversion p is most of the battle.  6 We had approx 0.5 M lines of C-source, almost none of E it ansi-compliant.   It took us approx 2 years of part-time efforts, e# by 1-4 programmers to make it so.  o  = We expected to find (run-time) bugs, after the move to Alpha,p9 but, after about 2 years we've found almost none that we h+ could attribute to either 'porting' effort.-  5 But also beware of the various ECO's for the C rtls, D and the compiler itself ...t   ------------------------------    Date: 21 Apr 2000 18:57:15 -04004 From: "Robert Deininger" <rdeininger@mindspring.com> Subject: RE: Verify of Backups+ Message-ID: <B526550D-CF694@165.247.45.143>   I On Thu, Apr 20, 2000 5:40 PM, Malcolm Dunnett <dunnett@mala.bc.ca> wrote:t- >In article <B524D10D-2398D@165.247.26.226>, a: >   "Robert Deininger" <rdeininger@mindspring.com> writes: >>  F >> I do my backups with /verify, with multiple save sets per DLT tape.G >> Backup does NOT go back to the beginning of the tape for each verifytI >> on our systems. It just backs up to the beginning of the last save set- >> and compares it to disk.0 >> 2E >    Can it quickly back up over the saveset? Some drives can't ( andMJ >on some drives that can it appears that BACKUP and/or VMS doesn't realize' >this and still does it the slow way ).i  D Quickly?  Hmm. Pretty quickly, yes, because DLTs are fast.  But I'veF never seen evidence that backup uses the "fast skip" feature.  I think? backup reads record-by-record until it find the right number ofo? (virtual) tape marks.  Fast skip would be faster, but slow skipi isn't too bad anyway.n  G Try this test:  On a test tape, write a large saveset (without verify).mE Then immediately add a second small saveset, with just your login.com D for example.  On the second saveset, use /verify.  It will be pretty? obvious whether backup rewinds to BOT.  On my DLTs, it doesn't.u  C The manual from Quantum says the drives should be able to reach any1B point on the tape in 45 seconds or less. But I think that requires@ the "seek by internal block number" command, which I don't thinkA VMS uses.  There is a corresponding "what is the current internalSD block number?" command, which could be used to remember an important% spot on a tape for fast access later.D  D >    I originally started using /COMPARE when we had Exabytes ( as IH >mentioned earlier - it could take hours to start a /VERIFY on a savesetE >on those it it wasn't at the start of the tape - and you sure didn'ti@ >want to place any trust in a backup on an Exabyte if you didn't@ >do a /VERIFY). When we switched to DAT there didn't seem to be I >much difference between /COMPARE and /VERIFY, in fact I switched back to.G >doing /VERIFY. Then I replaced the DATs with some DLT2000XTs and foundeG >that once again /VERIFY was much slower than /COMPARE. It appears thattH >even though the DLT2000s support fast file skips BACKUP doesn't use it.  B I agree.  I played with MKSET, BACKUP, and SET MAGTAPE/SKIP=FILES.E Under the right conditions, I could get SET MAGTAPE/SKIP=FILES to use E fast skip, but not BACKUP.  Even though I read in some document that  A BACKUP has been enhanced to use the feature when it is available.D  B (MKSET is in SYS$COMMON:[SYSHELP.UNSUPPORTED] on VMS 7.1 systems.)     ---------------------------e Robert Deininger rdeininger@mindspring.comt   ------------------------------    Date: 21 Apr 2000 19:13:18 -04004 From: "Robert Deininger" <rdeininger@mindspring.com> Subject: RE: Verify of Backups+ Message-ID: <B52658D0-DD8D7@165.247.45.143>c  < On Fri, Apr 21, 2000 7:45 AM, briggs@eisner.decus.org wrote:A >In article <B524D10D-2398D@165.247.26.226>, "Robert Deininger" <e# >rdeininger@mindspring.com> writes:   F >> I do my backups with /verify, with multiple save sets per DLT tape.G >> Backup does NOT go back to the beginning of the tape for each verify I >> on our systems. It just backs up to the beginning of the last save setp >> and compares it to disk.C >. >How do you know?2  @ When one of my co-workers asked me this question, I sent him the/ following e-mail (I never throw anything away):i  E     Here is a little summary of tonight's incremental backup.  I show-E the elapsed time for the backup command for each disk, along with thecC number of blocks backed up.  I think it is pretty clear that BACKUPhC is being intelligent about positioning the tape for each subsequentc	 save set.      -- Robertt  8 Disk            Time for backup         Blocks backed up8 --------------------------------------------------------- vax             35:07                   82873r- alpha           08:06                   16562e- user01          12:18                   45648g- user02          11:07                   43786e- user03          04:54                   15524 - user04          03:39                   10657 - user05          02:03                    7264 - user06          06:33                   88887w- user07          00:33                    1268 - user08          12:16                   32588l- user09          06:34                   26230-- pc01            03:24                     615    (End of archived e-mail)  C     I extracted the times from the log file, and the elapsed times -C include the /VERIFY pass.  All the save sets are on the same tape, 7E in the order shown.  If BACKUP was going back to BOT for each verify,iG the elapsed time should get longer and longer for subsequent save sets.x  A Also, I note that all the save sets were bigger than 1000 blocks,i except the last.   ---------------------------c Robert Deininger rdeininger@mindspring.com    ------------------------------    Date: 21 Apr 2000 19:27:52 -04004 From: "Robert Deininger" <rdeininger@mindspring.com> Subject: Re: Verify of Backups+ Message-ID: <B5265C3A-EA642@165.247.45.143>o  = On Fri, Apr 21, 2000 12:19 PM, briggs@eisner.decus.org wrote: K >In article <116b01bfab9e$1814c4e0$020a0a0a@xile.realm>, "John E. Malmberg"  <f >wb8tyw@qsl.net> writes:  H >My understanding (in which I am pretty confident) is that the interfaceD >between the device driver and the tape drive is little changed from >the days of 9 track.g > % >The driver can command the drive to:  >a >	Read forward >	Read reverse >	Skip forward n records >	Skip forward n tape marksf >	Skip backward n records  >	Skip backward n tape marks >	Write a record >	Write a tape markc> >	(Ignoring a few more esoteric commands of limited relevance) > D >Not surprisingly, these are the same operations that a user program >can request of the driver.w    E At or around 7.1, MKDRIVER has the fast-skip modifier which works fort (some) newer tape drives.f  I >On drives with accelerated seek capabilities (like the DLT drives have),iK >the drive knows where various landmarks on the tape reside.  For instance,aI >"the start of serpentine track 34 is 17 tape marks plus 435 records in".t* >The driver does not share this knowledge.  @ How sure are you of this?  It doesn't match my recollection from scanning the DLT 4000 manual.r  > Does the drive's extra information last only until the tape is@ dismounted?  I don't recall anything about the drive saving thisB info on the tape (for example in a special area near the beginningC of tape).  How many "shortcuts" can it store?  What happens when it  runs out of room?a  F >When the driver issues a "skip 5 tape marks" command, the drive takesF >its current position in tape marks and records (it keeps track), addsE >the seek offset and tries to find a match in the tape directory.  It-F >it can then quickly skip to a landmark near the final destination andG >do an unaccelerated seek from there.  I've never seen this documented.e >But it seems obvious to me.  E I recall nothing in the SCSI command set that matches this.  Maybe it.G is completely transparent.  But I don't have the manual in front of me. E (I'm speaking specifically about DLTs, I've no experience with DATs.)p  > What I do recall seeing are two SCSI commands that are roughlyF Tell me the "internal block number" at the current tape position, and > Skip to a given "internal block number".  I believe the latterC command takes the shortest path, rather than the logically-linear, iC physically-serpentine simple path.  The trick, I think, is teachingeB your application to know which "internal block number" to ask for.F I haven't found an MKDRIVER function code or modifier that corresponds@ to these functions, which is why I doubt VMS supports them.  ButC there could be an undocumented mechanism for VMS-internal use only.:  C In any case, BACKUP remains a mystery to me.  This is one time when56 the source listings would end the mystery pretty fast.     ---------------------------6 Robert Deininger rdeininger@mindspring.com    ------------------------------  % Date: Fri, 21 Apr 2000 14:38:01 -0500o% From: JM <vmswiz@geonospamcities.com>t. Subject: Re: What's this option? - HW Manuals?O Message-ID: <90A9EE9F8E2613DE.4A01C89721147D58.526F819B3ABF9DD0@lp.airnews.net>1   Hoff::  E   Is there any chance that the hardware manuals are available in somecE electronic form that could be made available on the Internet? GraphicXH cards, SCSI drive jumper settings, Storageworks cabinets, Alphastations, etc, would be the most useful.  G   Even if they are in a non-html format. Some of us still have DECwrite  and DEC document licenses. :)f  H   I hate to see you get asked and have to answer the same questions over, and over again. The FAQ can only get so big.   			*JM*e   ------------------------------   Date: 21 Apr 2000 19:27:00 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman). Subject: Re: What's this option? - HW Manuals?6 Message-ID: <8dqa24$sra$1@mailint03.im.hou.compaq.com>  w In article <90A9EE9F8E2613DE.4A01C89721147D58.526F819B3ABF9DD0@lp.airnews.net>, JM <vmswiz@geonospamcities.com> writes:  :fF :  Is there any chance that the hardware manuals are available in someF :electronic form that could be made available on the Internet? GraphicI :cards, SCSI drive jumper settings, Storageworks cabinets, Alphastations,. :etc, would be the most useful.r  G   Some of this information is already available.  No, I don't have the hH   various URLs handy (or do I have anything even approaching a complete )   list), but start at the following URLs:   0     ftp://ftp.digital.com/pub/DEC/Alpha/systems/;     http://www.compaq.com/alphaserver/technology/index.htmliE     http://www.compaq.com/alphaserver/workstations/retired/index.html3  D   There are various information distributions intended for business D   partners and certified engineers, too.  And the oft-cited hardwareD   self-maintenance services (Compaq Assisted Services) organization.  N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------   End of INFO-VAX 2000.224 ************************