1 INFO-VAX	Tue, 16 May 2000	Volume 2000 : Issue 272       Contents: Re: big Fortran data file  Re: big Fortran data file  Re: cdrom writer drive problem Changing the prompt! Re: DCL Percentages ! Deadlock problems have me stumped  Re: DEFINE ?& DS20 and HSJ-50 controllers - WARNING!* Re: DS20 and HSJ-50 controllers - WARNING! Re: EDT macros Initializing all drives  Re: Licenses MONITOR on VMS 7.2, Novedades en Internet - Servidores de Verdad4 Re: Problem with Seagate disk on VAXstation 4000 VLC, Re[2]: HELP on calculating percentage in DCLK RSVPs requested Re: DFWDAYS, A Compaq Update Weekend June 2nd, 3rd, and 4th  Some OPC websites # RE: String descriptors, BASIC and C ( String descriptors, BASIC and C - part 23 Re: Suggest a better file serving solution than NT? " Re: Utility to track device errors Re: Verifying username password  Re: Verifying username password  Re: VMS backup on PC' Where to start with motif programming ? + Re: Where to start with motif programming ?   F ----------------------------------------------------------------------    Date: 15 May 2000 14:25:34 -07000 From: Richard Maine <maine@altair.dfrc.nasa.gov>" Subject: Re: big Fortran data file1 Message-ID: <uezoprjyk1.fsf@altair.dfrc.nasa.gov>   , helbig@astro.rug.nl (Phillip Helbig) writes:(   [random vs sequential access question]I > In theory, it needs to be randomly accessed.  However, I can structure  H > things so that only the last of the five indices needs to be randomly K > accessed, while the others can be stepped through in order (some of them   > being skipped).  > H > So far, the best solution seems to be to write a record each time the G > second-to-last index is increased, containing the values of the last  H > index (the number of which depends on the value of the second-to-last 	 > index).   ; That sounds like a pretty good match to your problem to me.   G > The straightforward way would be a sequential file.  However, if the  H > program which uses the lookup table doesn't start at the beginning, a K > direct-access file might be better (the record number being some hash of  H > the indices).  However, since the length of the record depends on the H > value of the second-to-last index, I guess this will waste disk space K > since all the records have to be the same length in a direct-access file  I > (unless I'm missing something; I've rarely used direct-access files in   > the past).  E There are ways around this, but they involve extra work (or money for D someone else to do the work).  Whether its worth the work depends on3 how much disk space you'd be talking about wasting.   I Sounds like what you need is basically an ISAM (indexed sequential access E method) file.  Anyway, that's what they were called back in the '60s. B (This is not exactly new stuff).  Fortran doesn't provide built-inF support for such a structure.  You can either throw something together> yourself or buy a 3rd party library that supports such things.  G You might not even really need the sequential part (that is the part of H ISAM that allows you to access the next sequential record without havingH to specify its key).  The important part is the indexed bit.  That's howL the system (or you - since the system doesn't provide this service directly)H can keep track of where in the file each record starts.  The reason thatH Fortran direct access files need to be fixed length is that this gives a> trivial way to figure out where each record is - just evaluateK (recnum-1)*recl+1 and that's where the record starts.  If you want a direct E access file with variable length records, you need some other scheme.   
 Given that  G 1. You are going to write the file sequentially, from beginning to end. E    In particular, you never have to worry about inserting or deleting %    records in the middle of the file.   , 2. You can use the record number as the key.  F 3. Your data is structurally simple, so that it is easy to "block" it.4    (A homogeneous array meets the bill excellently).  G then its really pretty easy to "roll your own" indexed file as follows.   F In this, I assume that we'll allow records to span blocks.  That makesI storage more efficient, but implementation a little harder.  Not clear to F me whether or not this is the best choice.  If the logical records areN big enough that you don't waste much space by padding out to block boundaries,& then the other choice might be better.  M 1. Choose a block size.  Something big enough that it is reasonably efficient P    to read a block.  Block sizes of 1 byte or 1 word do not fit that requirementL    particularly well.  But something small enough so that you aren't usuallyN    reading in far more data than you use because the blocks are so much bigger    than the logical records.  I 2. Create a direct access file with recl appropriate for your block size.     This is the main data file.  .    And define a block buffer, initially empty.  H 3. Create a second direct access file with recl suitable for an array of)    two integers.  This is the index file.   I (Note - many variations are possible.  You can also block the index file. J Or you could integrate the index file into the main file, with some blocksH being index blocks and other ones being data blocks.  I'm just outlining a particularly simple scheme.)   3. Loop for each record   L   3a. write the main data file offset and the record size to the next recordJ       in the index file.  (You might not even need the record size, but it)       seems like it might be convenient).   M   3b. Copy data from your array into the block buffer.  If there is more data I       than there is room left in the buffer, then write the buffer to the >       next physical record in the file and start a new buffer.  G 4. After all records done, pad the last block and write it to the file.   3 Reading is left as a (hopefully obvious) excercise.   B Note that you have two different record numbers to deal with.  TheB "logical" record number is used in the index file and is basically@ your "index key".  In the main data file, each block will have a physical record number.    --  
 Richard Maine  maine@altair.dfrc.nasa.gov   ------------------------------  % Date: Mon, 15 May 2000 22:27:54 -0500 - From: "Craig T. Dedo" <Craig_Dedo@execpc.com> " Subject: Re: big Fortran data file8 Message-ID: <3920c084$0$34877$2c3edae7@news.voyager.net>  
 Dear Phil:   Phillip Helbig wrote:   A > In article <uezoprjyk1.fsf@altair.dfrc.nasa.gov>, Richard Maine & > <maine@altair.dfrc.nasa.gov> writes: > * > Thanks very much for the detailed reply. > L > >Sounds like what you need is basically an ISAM (indexed sequential accessH > >method) file.  Anyway, that's what they were called back in the '60s.E > >(This is not exactly new stuff).  Fortran doesn't provide built-in I > >support for such a structure.  You can either throw something together A > >yourself or buy a 3rd party library that supports such things.  > 5 > Again, interesting explanation.  I'll look into it.  > J > As I'm on a VMS machine, I'm sure there is some VMS file type which fitsD > the bill, but I'd like to stick to a standard-conforming solution.  N     Yes, there is.  RMS, the VMS file system, provides direct support for ISAMK files.  Compaq's Fortran compilers for VMS have Fortran language extensions K that allow Fortran programmers to open, close, read, write, and search ISAM N files without having to resort to obscure procedure calls and data structures.  )     The file is opened with the statement L         OPEN (UNIT=n, FILE=filename, ACCESS="KEYED", ORGANIZATION="INDEXED")) You read fromt eh file with the statement =         READ (UNIT=n, KEY=keyvalue, KEYID=keyid)  data_record L where keyvalue is the value of the key and keyid is 0 for the primary key, 1 for the first alternate, etc.   H     Please see your Compaq Fortran Language Reference Manual for further information.   --
 ----------
 Sincerely,@ Craig T. Dedo                                          Internet: Craig_Dedo@execpc.com G Elmbrook Computer Services                 Voice Phone:  (262) 783-5869 L 17130 W. Burleigh Place                        Fax Phone:     (262) 783-5928L Brookfield, WI   53005-2759                   Disclaimer:     These opinions are mine alone. G USA                                                         They do NOT  represent any organization.   E "They that can give up essential liberty to obtain a little temporary L     safety deserve neither liberty nor safety."  -- Benjamin Franklin (1759)   ------------------------------  % Date: Mon, 15 May 2000 22:23:06 -0700 1 From: Vance Haemmerle <vance@toyvax.Tucson.AZ.US> ' Subject: Re: cdrom writer drive problem 3 Message-ID: <392078CA.2323AB4D@toyvax.Tucson.AZ.US>   $ Brian Schenkenberger, VAXman- wrote: > M > I've tried MANY CD-R and CD-RW devices on VMS -- both VAX and Alpha.  While M > you can use them to burn CDs, you'll be hard pressed to get VMS to use them  > for CDrom reading devices. > K > If you can't set the CD drive to 512 byte sectoring, I doubt that the VMS K > DKDRIVER will take too kindly to it even if the device attributes did not 
 > confuse it.   I   I've got a Yamaha CDR400Atx CD-R on a DEC 3000/900.  It works fine as a R CDrom reading device.  However, after I burn a CD, I have to power cycle the driveQ to get VMS to recognize it as a CDrom reader again.  I think the CDWRITE software % changes some mode pages on the drive.    -- Vance Haemmerle  vance@toyvax.Tucson.AZ.US    ------------------------------  # Date: Mon, 15 May 2000 17:55:20 GMT # From: "Oberon" <io@cableinet.co.uk>  Subject: Changing the prompt! 5 Message-ID: <cSWT4.354$Qd6.36741@news3.cableinet.net>    Hi,   K I know this is probably a simple question! Some years (15) ago I first came A across VMS on a course at DEC in Reading. They showed us a way to E change the prompt to among other things a car and a rocket. I've just F started using VMS (7.1) again after a 10 year break and can't remember how the prompt was done.  > I know it used escape sequences but I've been unable to locate3 any info on any of the main VMS sites I've visited.   " Any pointers would be appreciated.   Thanks Mark) -----------Remove Moon_ to Reply---------    ------------------------------  # Date: Mon, 15 May 2000 21:27:49 GMT   From: james_e_becker@my-deja.com Subject: Re: DCL Percentages) Message-ID: <8fpq41$5i0$1@nnrp1.deja.com>   : The "simple" solution may well be adequate for the case in; hand, but there are actually a couple of potential problems  in the general case.  9 First, pct = b_free/(b_max/100) only works if b_max > 100 = (preferably >> 100). A couple of admittedly extreme examples: : $ write sys$output 1/(87/100)   !correct rounded answer: 1
 2147483647> $ write sys$output 198/(199/100)   !correct rounded answer: 99 198 = $ write sys$output 201/(299/100)  !correct rounded answer: 67  100   ; However, for large values, the errors probably matter less.   < Second, there's a tiny rounding problem, if this is the sort of thing that bugs you: G $ write sys$output 24881000/(35545099/100)  !correct rounded answer: 70  69  < A more general, DCL-only procedure for computing percentages; is shown below. You'd pass the two numbers (e.g. b_free and = b_max) as P1 and P2 to get the percentage. Assumption: P1 and  P2 are positive. $ maxint = %x7fffffff  $ p1 = f$integer (p1)  $ p2 = f$integer (p2)  $ if p1 .gt. maxint/100  $ then $    multiplier = 1  $    divisor = p2/100  $ else $    multiplier = 100  $    divisor = p2  $ endif  $ if p2 + divisor/2 .lt. 0 $ then $    rounding = 0  $ else $    rounding = divisor/2  $ endif 6 $ percentage == (p1 * multiplier + rounding) / divisor  8 Example usage (including a "write sys$output percentage" to show the results):  $ @pct 1 87  1  $ @pct 198 199 99 $ @pct 201 299 67 $ @pct 24881000 35545099 70  : Anyway, for disk free space percentages, the simple method9 others gave you is probably close enough for the intended  purpose.  
 Jim Becker  , In article <8fp0si$fkj$1@news.inet.tele.dk>,&   "Lars Jacobsen" <laja@tdk.dk> wrote:( > The solution was embarassingly simple. > = > The cause was integer overflow thus the equation should be:  >  > pct = b_free/(b_max/100) > 	 > and NOT  > pct = (b_free/b_max)*100 > or > pct = (b_free*100)/b_max >   > Thanks to all who contributed. >  > -- > Kind Regards0 > ----------------------------------------------0 > Lars Jacobsen          Phone : +45 89 45 41 800 > Tele Danmark IT        Fax   : +45 89 45 61 02 > Takseringssystemer (BNTT) - > S/8-173                email  : laja@tdk.dk  > Gunnar Clausens Vej 28 > DK-8260 Viby J    & Sent via Deja.com http://www.deja.com/ Before you buy.    ------------------------------  % Date: Mon, 15 May 2000 17:11:46 -0700 @ From: "Russell E. Owen" <owen@astroNOJNK.washington.edu.invalid>* Subject: Deadlock problems have me stumped2 Message-ID: <8fq3o2$182e$1@nntp6.u.washington.edu>  I I have software that makes extensive use of locks to coordinate multiple  I processes. Roughly once a month a lock conversion request fails due to a  G deadlock error. I haven't found the problem in the code, so I modified  C the code to call SYS$GETLKI and return information about all locks  G whenever a deadlock is detected. Even examining that output I am still  D stumped. If anyone has any suggestions what to look for, I would be 	 grateful.   G In English, T_TRACK was updating Obj data in a simple global database.  G It was holding Obj in the PW state while it prepared the changes, thus  A allowing read-only users access to Obj. T_TRACK then requested a  F conversion from PW to EX so it could write the updated data -- it was I this request that failed.T_GUIDE also wanted to update the Obj data, and  ' so was waiting until T_TRACK was done.    I Note that normally a request to convert from NL to PW should not block a  H request to convert from PW to EX. And indeed, my explicit tests of this C sequence do not fail. So something else must be going on, but what?       G Here is a summary of the data, showing locks held by the process whose  E conversion was denied (T_PTERR) and locks held by other process that  G share one or more locks with T_PTERR. I omitted locks that are granted  G null and have no change request queued. However, a complete listing of  > all locks is appended, as well as a listing of process quotas.  H Lock Name   Lock ID     Parent ID  Grnt  Req  Que  ProcName   State NoteB Obj         385877418   1811940707  NL    PW   1   T_PTERR       5  G Obj         16778329    16777659    PW    EX   1   T_TRACK      14    1 B tgm_Parent  16777659    0           CR    NL   1   T_TRACK      14  G Obj         318767854   1275069623  NL    PW   0   T_GUIDE       5    2 B tgm_Parent  1275069623  0           CR    NL   1   T_GUIDE       5  B TCCUSER2    1241515749  0           PW    EX   1   TCCUSER       5  B TCCUSER1    201328362   0           PW    EX   1   _TNA483:      5  B prt_LTA3:   1073743248  0           EX    EX   1   T_STATUS      5B TCC_ROT     16779245    0           PR    NL   1   T_STATUS      5   Where:& Grnt is the granted state for the lockI Req is the requested state for the lock (irrelevant if the lock has been   granted) Que is the lock queue, one of: * 0: lock conversion waiting* * 1: lock granted (ignore requested state)= * 255: new lock request waiting (but there are none of these) # State is the process state, one of: ) * SCH$C_LEF = 5;  ! LOCAL EVENT FLAG WAIT " * SCH$C_HIB = 7;  ! HIBERNATE WAIT) * SCH$C_CUR = 14; ! CURRENT PROCESS STATE    Notes:= 1: this is the lock whose conversion from PW to EX was denied & 2: this ithe only pending lock request  
 -- Russell       Process quotas:   9 Maxjobs:         0  Fillm:       100  Bytlm:        64000 9 Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0 9 Maxdetach:       0  BIOlm:       150  JTquota:       4096 9 Prclm:          20  DIOlm:       150  WSdef:         2000 9 Prio:            4  ASTlm:       250  WSquo:         4000 9 Queprio:         0  TQElm:        50  WSextent:     16384 9 CPU:        (none)  Enqlm:      2000  Pgflquo:      50000       B A complete listing of locks in the order the data was returned by  SYS$GETLKIW:  C Lock Name   Lock ID     Parent ID  Grnt  Req  Que  ProcName   StateOB AppGeo      1090520919  1275069623  NL    NL   1   T_GUIDE       5B AppGeo      1577059685  654312684   NL    NL   1   T_COMPAPPGEO  7B AppGeo      16777767    1811940707  NL    NL   1   T_PTERR       5B AppGeo      16777821    16777659    NL    NL   1   T_TRACK      14B AppGeo      16778980    738199524   NL    NL   1   TCCUSER       5B AxeLim      1073743122  1275069623  NL    NL   1   T_GUIDE       5B AxeLim      16777323    16777659    NL    NL   1   T_TRACK      14B AxeLim      16777793    1811940707  NL    NL   1   T_PTERR       5B AxeLim      419431895   1140850855  NL    NL   1   _TNA483:      5B AxeLim      452985367   738199524   NL    NL   1   TCCUSER       5B Earth       16777331    16777659    NL    NL   1   T_TRACK      14B Earth       16778822    738199524   NL    NL   1   TCCUSER       5B Earth       16778990    1811940707  NL    NL   1   T_PTERR       5B Earth       2046821439  989857107   NL    NL   1   T_SLOW        7B Earth       234881607   1275069623  NL    NL   1   T_GUIDE       5B GHist       1241515146  1275069623  NL    NL   1   T_GUIDE       5B GS          16777314    1811940707  NL    NL   1   T_PTERR       5B GS          16778393    1275069623  NL    NL   1   T_GUIDE       5B GS          16779150    1140850855  NL    NL   1   _TNA483:      5B GS          285214043   738199524   NL    PW   1   TCCUSER       5B Inst        1241515574  587203074   NL    NL   1   T_STATUS      5B Inst        134219300   1140850855  NL    NL   1   _TNA483:      5B Inst        16777592    16777659    NL    NL   1   T_TRACK      14B Inst        16778133    16777800    NL    NL   1   T_COLLIMATE   7B Inst        16778361    1811940707  NL    NL   1   T_PTERR       5B Inst        318768379   1275069623  NL    NL   1   T_GUIDE       5B Inst        570426618   587202836   NL    NL   1   T_GCAMUSER    5B Inst        788530133   738199524   NL    NL   1   TCCUSER       5B LouvPos     1392509428  1140850855  NL    NL   1   _TNA483:      5B LouvPos     16778975    16778893    NL    NL   1   T_AUTOLOUVER  7B Mir         16777655    16777800    NL    NL   1   T_COLLIMATE   7B Mir         385876831   738199524   NL    NL   1   TCCUSER       5B Obj         117441294   1140850855  NL    PW   1   _TNA483:      5B Obj         16778329    16777659    PW    EX   1   T_TRACK      14B Obj         16778675    16777800    NL    NL   1   T_COLLIMATE   7B Obj         16778869    16778893    NL    NL   1   T_AUTOLOUVER  7B Obj         2013267463  587203074   NL    NL   1   T_STATUS      5B Obj         268436861   738199524   NL    PW   1   TCCUSER       5B Obj         318767854   1275069623  NL    PW   0   T_GUIDE       5B Obj         385877418   1811940707  NL    PW   1   T_PTERR       5B prt_LTA11:  16777393    0           NL    NL   1   TCCUSER       5B prt_LTA11:  83887510    0           NL    NL   1   _TNA483:      5B prt_LTA12:  1660946130  0           NL    NL   1   T_MOCKCTRL    5B prt_LTA15:  234881153   0           NL    NL   1   TCCUSER       5B prt_LTA15:  33555484    0           NL    NL   1   T_COLLIMATE   7B prt_LTA2:   1358955846  0           NL    NL   1   T_SLOW        7B prt_LTA3:   1073743248  0           EX    EX   1   T_STATUS      5B prt_LTA3:   1593836673  0           NL    EX   1   _TNA483:      5B prt_LTA3:   16778641    0           NL    EX   1   T_PTERR       5B prt_LTA3:   201327497   0           NL    EX   1   T_GUIDE       5B prt_LTA3:   83887074    0           NL    EX   1   T_TRACK      14B prt_LTA3:   922747755   0           NL    EX   1   TCCUSER       5B prt_LTA4:   1207961040  0           NL    EX   1   TCCUSER       5B prt_LTA4:   1275070423  0           NL    EX   1   _TNA483:      5B prt_LTA4:   1291846701  0           NL    EX   1   T_STATUS      7B prt_LTA4:   16777327    0           NL    EX   1   T_PTERR       5B prt_LTA4:   16777491    0           NL    EX   1   T_TRACK      14B prt_LTA4:   637535938   0           NL    EX   1   T_GUIDE       5B prt_LTA5:   16777944    0           NL    EX   1   T_TRACK      14B prt_LTA5:   16778229    0           NL    EX   1   T_PTERR       5B prt_LTA5:   16779200    0           NL    NL   1   T_STATUS      5B prt_LTA5:   352323383   0           NL    EX   1   T_GUIDE       5B prt_LTA5:   385876739   0           NL    EX   1   TCCUSER       5B prt_LTA5:   50332827    0           NL    EX   1   _TNA483:      5B prt_LTA6:   16778852    0           NL    NL   1   _TNA483:      5B prt_LTA6:   16779225    0           NL    NL   1   T_COLLIMATE   7B prt_LTA6:   318768826   0           NL    NL   1   TCCUSER       5B prt_LTA7:   150996770   0           NL    NL   1   _TNA483:      5B prt_LTA7:   16777858    0           NL    NL   1   T_GCAMUSER    5B prt_LTA7:   16778276    0           NL    NL   1   T_GUIDE       5B prt_LTA7:   33556244    0           NL    NL   1   T_PTERR       5B prt_LTA8:   1593836284  0           NL    NL   1   TCCUSER       5B prt_LTA8:   16778353    0           NL    NL   1   T_COLLIMATE   7B TCCUSER1    201328362   0           PW    EX   1   _TNA483:      5B TCCUSER2    1241515749  0           PW    EX   1   TCCUSER       5B TCC_GCAM    1342179281  0           NL    NL   1   T_SLOW        7B TCC_GCAM    16777695    0           NL    NL   1   T_GUIDE       5B TCC_GCAM    16778488    0           NL    NL   1   T_GCAMUSER    5B TCC_GCAM    218104887   0           NL    NL   1   _TNA483:      5B TCC_GCAM    33555131    0           NL    NL   1   T_PTERR       5B TCC_GMECH   1174406602  0           NL    NL   1   T_SLOW        7B TCC_GMECH   16778570    0           NL    NL   1   T_COLLIMATE   7B TCC_GMECH   318768626   0           NL    NL   1   TCCUSER       5B TCC_GMECH   50333343    0           NL    NL   1   _TNA483:      5B TCC_ROT     1442841884  0           NL    NL   1   T_GUIDE       5B TCC_ROT     1493172643  0           NL    NL   1   T_SLOW        7B TCC_ROT     16777973    0           NL    NL   1   T_PTERR       5B TCC_ROT     16779245    0           PR    NL   1   T_STATUS      5B TCC_ROT     184550157   0           NL    NL   1   T_TRACK      14B TCC_ROT     50333344    0           NL    NL   1   _TNA483:      5B TCC_ROT     838862039   0           NL    NL   1   TCCUSER       5B TelMod      1543504427  1811940707  NL    NL   1   T_PTERR       5B TelMod      16777652    16777659    NL    NL   1   T_TRACK      14B TelMod      2013266441  1275069623  NL    NL   1   T_GUIDE       5B TelMod      251659105   738199524   NL    NL   1   TCCUSER       5B TelMod      50333687    1140850855  NL    NL   1   _TNA483:      5B tgm_Parent  1140850855  0           NL    NL   1   _TNA483:      5B tgm_Parent  1275069623  0           CR    NL   1   T_GUIDE       5B tgm_Parent  16777659    0           CR    NL   1   T_TRACK      14B tgm_Parent  16777800    0           NL    NL   1   T_COLLIMATE   7B tgm_Parent  16778893    0           NL    NL   1   T_AUTOLOUVER  7B tgm_Parent  1811940707  0           NL    NL   1   T_PTERR       5B tgm_Parent  587202836   0           NL    NL   1   T_GCAMUSER    5B tgm_Parent  587203074   0           NL    NL   1   T_STATUS      7B tgm_Parent  654312684   0           NL    NL   1   T_COMPAPPGEO  7B tgm_Parent  738199524   0           NL    NL   1   TCCUSER       5B tgm_Parent  989857107   0           NL    NL   1   T_SLOW        7B Tune        16778022    1811940707  NL    NL   1   T_PTERR       5B Tune        16778544    16777800    NL    NL   1   T_COLLIMATE   7B Tune        16778742    16777659    NL    NL   1   T_TRACK      14B Tune        1862271737  587203074   NL    NL   1   T_STATUS      7B Tune        201326927   738199524   NL    NL   1   TCCUSER       5B Tune        419432291   989857107   NL    NL   1   T_SLOW        7B Tune        50331886    1140850855  NL    NL   1   _TNA483:      5B Tune        603980145   1275069623  NL    NL   1   T_GUIDE       5B Weath       16777970    16778893    NL    NL   1   T_AUTOLOUVER  7B Weath       16778166    16777800    NL    NL   1   T_COLLIMATE   7B Weath       285214074   738199524   NL    NL   1   TCCUSER       5   ------------------------------  % Date: Mon, 15 May 2000 19:43:56 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>. Subject: Re: DEFINE ? , Message-ID: <39208BB1.A8846AB3@videotron.ca>   Terry Marosites wrote: > M >   This all sounds very logical but why specify foo.tmp;0 to use the highest 8 > version when just specifying foo.tmp will do the same.  A nop. If foo.tmp;9 is installed ( $INSTALL ADD foo.tmp;9 ), then abK specification of "foo.tmp" will access foo.tmp;9 even if foo.tmp;10 exists.f  K foo.tmp;0 will avoid the intalled file lookup and force a directory lookup.o   ------------------------------  # Date: Sat, 13 May 2000 13:05:53 GMTn$ From: Ed Wilts <ewilts@mediaone.net>/ Subject: DS20 and HSJ-50 controllers - WARNING!a, Message-ID: <391D5331.14E87EA7@mediaone.net>  F Since Compaq has failed to document this, and is still selling systemsD that flat out will not work, I'll post a public warning.  There is aC known undocumented bug in the DS20 front-end that will crash HSJ-50fE controllers running firmware V5.4J.  There is NO fix.  Customers with G DS20 systems and HSJs have two choices:  1)  downgrade the HSJ firmware 4 to V5.2, or 2) wait for V5.5 (no ETA available yet).  H We've been fighting this problem for over 2 months and finally got luckyE when one of the many support analysts working this call happen to runoF into a friend of his, mentioned the problem we were having, and lo and& behold, it's a known problem.  Sigh...  H We've gone through all sorts of contortions trying to get 2 DS20 systemsB added to our cluster, and have gone through hell.  I've run out ofH fingers and toes counting how many times I've crashed an HSJ, and on oneH occasion crashed 2 AXP 4100 systems as well when their system disks wereD ripped out from under them.  A normal shutdown or boot of a DS20 can5 crash one or more of your DS20s.  You've been warned!p  8 Note that the CIPCA is a qualified option for the DS20.    -- n Ed Wilts Mounds View, MN, USA mailto:ewilts@mediaone.net   ------------------------------  # Date: Tue, 16 May 2000 03:43:14 GMT $ From: Ed Wilts <ewilts@mediaone.net>3 Subject: Re: DS20 and HSJ-50 controllers - WARNING!d, Message-ID: <3920C3D2.959A232B@mediaone.net>   jgessling@yahoo.com wrote: > . > In article <391D5331.14E87EA7@mediaone.net>,) >   Ed Wilts <ewilts@mediaone.net> wrote:rJ > > Since Compaq has failed to document this, and is still selling systemsH > > that flat out will not work, I'll post a public warning.  There is aG > > known undocumented bug in the DS20 front-end that will crash HSJ-50rI > > controllers running firmware V5.4J.  There is NO fix.  Customers witheB > > DS20 systems and HSJs have two choices:  1)  downgrade the HSJ
 > firmware8 > > to V5.2, or 2) wait for V5.5 (no ETA available yet). > >$ > Ed,1 > $ > Is this the error that looks like? > F >   CI host port detected an arbitration timeout on path A. PersistentD >   hardware faults generating an arbitration timeout will cause the$ >   controller to repeatedly reboot. > > > If so, we were visited by the HSJ product manager last week,H > (william.phillps@compaq.com) He mentioned that this was due to a faultE > in the YACI (yet another CI chip).   A fix is due real soon now.  Ia/ > suggest you shoot him an email for more info.1 >  > Jimg   Jim,  E Thanks for the feedback.  Yup, that's the error, and I was told today C that the fix is in HSOF 5.7, due to ship in the first week of June.0   	.../Ed  -- m Ed Wilts Mounds View, MN, USA mailto:ewilts@mediaone.net   ------------------------------  % Date: Mon, 15 May 2000 19:57:31 -0400n- From: Jonathan Boswell <jsb@ost.cdrh.fda.gov>i Subject: Re: EDT macrosc0 Message-ID: <39208EEB.D553A44F@ost.cdrh.fda.gov>   Phillip Helbig wrote:g > H > OK, I STILL haven't gotten around to using TPU.  It's still on my listJ > of things to do, honest.  (My main reason for this is to be able to makeI > use of LSE, but folks keep saying it will have other benefits as well.)o > E > I've only found two real disadvantages with EDT---the 255 character< > limitj  H I don't know about the rest of your questions, but the long line problemG has been such a PITA for so long that I wrote the following TPU programhG to solve it.  Obviously you can set the length limit to something other  than 80 chars.  F !A TPU procedure to linewrap file at previous space before 80 columns.3 !Written by Jonathan Boswell, FDA/CDRH, c. May 1999- !- !Typical usage:- !-A !  $ edit/tpu/nosection/command=linewrap.tpu/nodisplay <filename>k ! 2 input_file := GET_INFO(COMMAND_LINE, "file_name");1 input_buffer := CREATE_BUFFER("main",input_file);k% POSITION(BEGINNING_OF(input_buffer));67 MESSAGE("About to linewrap excessively long lines...");o  0 long_line_pattern := LINE_BEGIN + NOTANY("",80); counter2 := 0; LOOP@ 	long_line_range := SEARCH_QUIETLY (long_line_pattern, FORWARD);#         EXITIF long_line_range = 0;b5 	POSITION(END_OF(long_line_range));		!Move to col 80.uM 	previous_space_range := SEARCH_QUIETLY (" ", REVERSE,EXACT,long_line_range);n; 	if previous_space_range = 0	!No prior spaces on this line.s, 	then				!Give up and split line right here.? 		MESSAGE("Long line found with no breaks.  Split it anyway.");e
 		SPLIT_LINE;T1 		MESSAGE("Here's what's left: " + CURRENT_LINE);v/ 	else				!Found previous space on current line.t! 		POSITION(previous_space_range);e8 		SPLIT_LINE; 		!Wrap this record before previous space.) 		ERASE_CHARACTER(1);	!Delete this space.j 	endif;a1 	MOVE_VERTICAL(-1);	!Prepare for this line again.h 	counter2 := counter2 + 1; ENDLOOP;= MESSAGE(STR(counter2) + " ridiculously long lines wrapped.");n WRITE_FILE(input_buffer);f QUIT;t   ------------------------------  % Date: Mon, 15 May 2000 14:06:59 -0700d+ From: Jay T. McCanta <jmccanta@immunex.com>a  Subject: Initializing all drives8 Message-ID: <j5p0iskb89osonipkuh4v1ls6q3evmjm4e@4ax.com>  B I have several vaxen that need to have their disks wiped before weC donate them.  I was using INIT/ERASE on the non-OS drives.  I got aiA backup of one the empty drives and I thought I would be clever byeD booting SAbackup and doing a BACKUP/IMAGE/INIT/ERASE with my savesetF of a naked drive.  OK, clever isn't my strong point.  Any ideas?  SomeB systems have only a single drive, so installing VMS onto an erasedF disk and erasing a second drive won't work. I have to erase the drivesF for legal reasons - simple init'd won't do.  The systems are 3100's ofD most flavors.  I remember the MicroVax 2000 has drive testing in itsD boot console - you could wipe a drive with that.  I can't find it on these newer boxes.    
 Any Ideas?  E -===================================================================- 9 Jay McCanta              |  My opinions are barely my own ; System Administrator     |  My employer doesn't necessarily ' Immunex Corp.            |  share them. E -===================================================================-C   ------------------------------  % Date: Mon, 15 May 2000 23:14:56 -04003* From: Chuck Chopp <ChuckChopp@rtfmcsi.com> Subject: Re: Licenses + Message-ID: <3920BD30.8FAB4BBA@rtfmcsi.com>S   David A Froble wrote:r   > "Leigh G. Bowden" wrote: > >kP > > When licensing what is the relationship between VAXstation, VAX and microVAXP > > and can they be mixed i.e. a license from a mVAX 3100 can it be applied to a > > VAXstation?s > >t- > > Similarly AlphaServers and AlphaStations?e >e > $ sho lic/cha + > VMS/LMF Charge Information for node DFE60_7 > This is a VAXstation 4000-60, hardware model type 236IQ > Type: A, * Not Permitted *      (VAX/VMS Capacity or OpenVMS Unlimited or Base)l6 > Type: B, * Not Permitted *      (VAX/VMS F&A Server); > Type: C, * Not Permitted *      (VAX/VMS Concurrent User)u7 > Type: D, Units Required: 100    (VAX/VMS Workstation) F > Type: E, Units Required: 50     (VAX/VMS System Integrated Products)8 > Type: F, Units Required: 10     (VAX Layered Products), > Type: G, * Not Permitted *      (Reserved): > Type: H, * Not Permitted *      (Alpha Layered Products)4 > Type: I, Units Required: 10     (Layered Products) >xR > As you can see from the above, the VAX systems had many types of licenses.  TypeR > 'A' was for servers/timesharing systems, type 'D' was for workstations, and typeO > 'B' is an obscure disaster.  Even the layered products had two types, 'E' and N > 'F', though I'm not sure I ever saw a type 'E'.  The Alpha isn't so bad.  InR > general, the 'units required' for the system vs the units of the license are the > main concern.R > R > Layered products generally will work on any type of system, and the BASE VMS andN > certain VMS USER licenses are tied to the hardware they were sold for, so ifL > you're following the rules that isn't a issue.  I'm not sure just what theR > current rules are for transfering layer products from one system to another, but > is is doable.5 >xP > Note that VAX licenses do NOT work on Alpha, and Alpha licenses do not work onO > VAX.  The only exception I have seen is the MT3* VMS USER licenses, which are6M > freely transferable to any VMS system.  Also note that I'm not an expert on  > licenses.S >  > Dave >t > --6 > David Froble                       Tel: 724-529-04506 > Dave Froble Enterprises, Inc.      Fax: 724-529-0596= > 170 Grimplin Road               E-Mail: davef@tsoft-inc.com  > Vanderbilt, PA  15486   Q The Type E licenses were for the old VAX Cluster licenses and DECnet licenses.  I8L had them on my old cluster consisting of VAX8800, VAX6410, VAX8530 and misc.P MicroVAX 3xxx systems.  I think that Volume Shadowing (Phase 2) falls under thisR category.  System integrated products were the ones that were installed as part ofT the operating system but needed a separate license to be installed before they could
 be activated.8     ChuckL -- Chuck Chopp   8 ChuckChopp@rtfmcsi.com            http://www.rtfmcsi.com0                                   ICQ # 22321532@ RTFM Consulting Services Inc.     864 801 2795 voice & voicemail2 103 Autumn Hill Road              864 801 2774 fax4 Greer, SC  29651                  800 400 4935 pagerC                                   8004004935@alphapage.airtouch.com    ------------------------------  # Date: Sat, 13 May 2000 13:05:18 GMT 3 From: "Someone Somewhere" <Someone@somewhere.where>5 Subject: MONITOR on VMS 7.278 Message-ID: <iqcT4.5178$45.52580@news1.rdc1.tn.home.com>  I I am getting the following message when trying to run MONITOR after a new1I install of VMS v7.2. If I manually install the image using INSTALL ADD, I  can run the monitor utility.G Did I miss something during system setup, or can I just add the install - command to systartup_vms and be done with it?T  . Any help you can provide would be appreciated.           Shrini Arole         shrini@home.com3  2 %DCL-W-ACTIMAGE, error activating image XTI$XTILIB -CLI-E-IMGNAME, image file5 TMMVXD$DKA0:[SYS0.SYSCOMMON.][SYSLIB]XTI$XTILIB.EXE;17K -SYSTEM-F-PRIVINSTALL, shareable images must be installed to run privileged1 image  $    ------------------------------  % Date: Mon, 15 May 2000 10:30:59 +02001: From: Info Servidores de Verdad <servidores@altavista.com>5 Subject: Novedades en Internet - Servidores de Verdad - Message-ID: <0FUM0095M4G02L@mx.east.saic.com>1  ! This is a Multipart MIME message.   + ------=_NextPart_000_001__62462596_37859,89 , Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bitL   Este mail esta en formato HTML.TM Si el programa de correo electronico tiene problemas para verlo, aconsejamos 3R una rapida actualizacion del mismo. Aparte de por poder disfrutar de las ventajas 0 de este nuevo sistema, por motivos de seguridad.  + ------=_NextPart_000_001__62462596_37859,89 + Content-Type: text/html; charset=iso-8859-1 ! Content-Transfer-Encoding: base64   H PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5TZXJ2aWRvcmVzIGRlIFZlcmRhZCAtUHVibGljaWRhH ZC08L3RpdGxlPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0H ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSI+DQo8L2hlYWQ+DQoNCjxib2R5IGJnY29sH b3I9IiNGRkZGRkYiPg0KPGZvbnQgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgH c2Fucy1zZXJpZiIgc2l6ZT0iMiIgY29sb3I9IiMwMDk5MDAiPkVzdGUgDQptZW5zYWplIGxvH IGhhIHJlY2liaWRvIHBvciBlbCBpbnRlcmVzIHF1ZSBoYSBkZW1vc3RyYWRvIGVuIHRlbWFzH IGRlIEludGVybmV0LCANCnkgU09MTyBTRSBFTlZJQVJBIEVTVEEgVkVaLiBObyB2b2x2ZXJhH IGEgcmVjaWJpciBtYXMgbWVuc2FqZXMgZGUgZXN0ZSB0aXBvIHBvciANCm51ZXN0cmEgcGFyH dGUuIDwvZm9udD4gDQo8aHI+DQo8dGFibGUgd2lkdGg9IjYwJSIgYm9yZGVyPSI1IiBjZWxsH c3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIGFsaWduPSJjZW50ZXIiPg0KICA8dHIgYmdjH b2xvcj0iIzAwMDAwMCI+IA0KICAgIDx0ZD4NCiAgICAgIDxkaXYgYWxpZ249ImNlbnRlciI+H PGEgaHJlZj0iaHR0cDovL3d3dy5zZXJ2aWRvcmVzZGV2ZXJkYWQuY29tIj48aW1nIHNyYz0iH aHR0cDovL3d3dy5zZXJ2aWRvcmVzZGV2ZXJkYWQuY29tL2ltYWdlcy90c3RleHQuZ2lmIiB2H c3BhY2U9IjYiIGJvcmRlcj0iMCI+PC9hPjwvZGl2Pg0KICAgIDwvdGQ+DQogIDwvdHI+DQo8H L3RhYmxlPg0KPHA+PGZvbnQgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2FuH cy1zZXJpZiIgc2l6ZT0iMiI+PGJyPg0KICBEaXN0aW5ndWlkbyB1c3VhcmlvLDwvZm9udD48H L3A+DQo8cD48Zm9udCBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlH cmlmIiBzaXplPSIyIj5BbCBjb25vY2VyIGRlIHN1IA0KICBpbnRlcmVzIGVuIHRlbWFzIGRlH IEludGVybmV0LCB5YSBzZWEgYSB0cmF2ZXMgZGUgdW4gY29ub2NpZG8gY29tdW4sIHlhIHNlH YSBwb3IgDQogIHN1IHBldGljaW9uIGRlIGluZm9ybWFjaW9uIGVuIGZlY2hhcyBhbnRlcmlvH cmVzLCBub3MgY29tcGxhY2UgaW5mb3JtYXJsZSBkZSANCiAgZXN0YXMgbm92ZWRhZGVzLCBxH dWUgY3JlbyBsZSBzZXJhbiBkZSBzdSBpbnRlcmVzLjwvZm9udD48L3A+DQo8cD48Zm9udCBmH YWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIyIj48H Yj48Zm9udCBzaXplPSI0Ij4xLjwvZm9udD48L2I+IA0KICA8Zm9udCBjb2xvcj0iIzAwOTkwH MCI+PGI+PGZvbnQgc2l6ZT0iMyI+PGk+UmVnaXN0cmUgc3UgcHJvcGlvIGRlIGRvbWluaW8gH ZGUgDQogIEludGVybmV0IHBvciBzb2xvICQxNTwvaT48L2ZvbnQ+PC9iPjwvZm9udD4gKDIuH NzUwIHB0YXMuKSBhbCBhJm50aWxkZTtvLjxicj4NCiAgRXN0ZSBlcyBlbCBtZWpvciBwcmVjH aW8gcXVlIHB1ZWRlIHVzdGVkIGVuY29udHJhciBwYXJhIGVsIHJlZ2lzdHJvIGRlIGRvbWluH aW9zLCANCiAgcGVybyBxdWUgcHVlZGUgbGxlZ2FyIGEgc2VyIGluY2x1c28gbWFzIGJham8gH KGhhc3RhICQxMC41MCkgc2kgdXN0ZWQgcmVnaXN0cmEgDQogIHVuYSBjYW50aWRhZCBkZSBkH b21pbmlvcyBpbXBvcnRhbnRlcyBjYWRhIG1lcy48YnI+DQogIExvcyBub21icmVzIGRlIGRvH bWluaW8gcmVnaXN0cmFkb3MgZGVzZGUgbnVlc3RyYSB3ZWIsIGFkZW1hcyBwb3NlZW4gdmFyH aWFzIHZlbnRhamFzIA0KICByZXNwZWN0byBhIGxvcyByZWdpc3RyYWRvcyBhIHRyYXZlcyBkH ZSBOZXR3b3JrIFNvbHV0aW9uczo8L2ZvbnQ+PC9wPg0KPHVsPg0KICA8bGk+PGZvbnQgZmFjH ZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgc2l6ZT0iMiI+IDx1H Pjxmb250IHNpemU9IjMiIGNvbG9yPSIjOTkwMDAwIj5SZWRpcmVjY2lvbmVzIA0KICAgIGdyH YXR1aXRhczwvZm9udD48L3U+IDxiPioqTk9WRURBRCoqPC9iPiBQdWVkZSByZWRpcmlnaXIgH dW4gZG9taW5pbyBhIGN1YWxxdWllciANCiAgICBkaXJlY2Npb24gZGUgSW50ZXJuZXQsIGluH Y2x1c28gcHJvdmVlZG9yZXMgZ3JhdHVpdG9zIGNvbiBjb21wbGljYWRhcyBkaXJlY2Npb25lH cy48L2ZvbnQ+PC9saT4NCiAgPGxpPjxmb250IGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2H ZXRpY2EsIHNhbnMtc2VyaWYiIHNpemU9IjMiPjx1Pjxmb250IGNvbG9yPSIjOTkwMDAwIj5EH b21pbmlvcyANCiAgICBkZSBoYXN0YSA2MyBjYXJhY3RlcmVzIGRlIGxvbmdpdHVkPC9mb250H PjwvdT48L2ZvbnQ+PGZvbnQgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2FuH cy1zZXJpZiIgc2l6ZT0iMiI+LCANCiAgICBmcmVudGUgYSBsb3MgY29ydG9zIDIzIHF1ZSBvH ZnJlY2UgTmV0d29yayBTb2x1dGlvbnMuPC9mb250PjwvbGk+DQogIDxsaT48Zm9udCBmYWNlH PSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIyIj48dT48H Zm9udCBzaXplPSIzIiBjb2xvcj0iIzk5MDAwMCI+TW9kaWZpY2FjaW9uZXMgDQogICAgZGUgH bG9zIGRhdG9zIGluc3RhbnRhbmVhbWVudGU8L2ZvbnQ+PC91Pi4gTm8gZGViZSBkZSBlbnZpH YXIgbWFzIGVuZ29ycm9zb3MgDQogICAgZW1haWxzIGEgTmV0d29yayBTb2x1dGlvbnMgcXVlH IGxlIHNlcmFuIGRldnVlbHRvcyBjb24gZXJyb3Jlcy48L2ZvbnQ+PC9saT4NCiAgPGxpPjxmH b250IGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIHNpemU9H IjIiPjx1Pjxmb250IHNpemU9IjMiIGNvbG9yPSIjOTkwMDAwIj5QYXJraW5nIA0KICAgIGdyH YXR1aXRvPC9mb250PjwvdT4gZGUgbG9zIGRvbWluaW9zIHNpIGF1biBubyBkaXNwb25lbW9zH IGRlIHNlcnZpZG9yIHBhcmEgDQogICAgZWxsby48L2ZvbnQ+PC9saT4NCiAgPGxpPjxmb250H IGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIHNpemU9IjMiH IGNvbG9yPSIjOTkwMDAwIj48dT5QcmVjaW88L3U+PC9mb250PjwvbGk+DQogIDxsaT48Zm9uH dCBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIzH IiBjb2xvcj0iIzk5MDAwMCI+PHU+UG9saXRpY2EgDQogICAgZGUgZGlzcHV0YXMgc29icmUgH dGl0dWxhcmlkYWQgZGUgZG9taW5pb3MgSlVTVEEgYSB0cmF2ZXMgZGUgbGEgSUNBTk48L3U+H PC9mb250Pjxmb250IGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyH aWYiIHNpemU9IjIiPiANCiAgICB5IGVuIHN1IHByb3BpbyBjb250aW5lbnRlLCBjb24gc3VzH IHByb3BpYXMgbGV5ZXMsIG5vIGxhcyBsZXllcyBpbmRpc2NyaW1pbmFkYXMgDQogICAgeSByH YWNpc3RhcyBkZSBsb3MgVVNBIGVuIGVzdGUgYXNwZWN0by48L2ZvbnQ+PC9saT4NCiAgPGxpH Pjxmb250IGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIHNpH emU9IjIiPjx1Pjxmb250IHNpemU9IjMiIGNvbG9yPSIjOTkwMDAwIj5SYXBpZGV6IA0KICAgH IGVuIGVsIHJlZ2lzdHJvPC9mb250PjwvdT4sIGVuIHBvY29zIGNsaWNrcyBxdWVkYSByZWdpH c3RyYWRvIHVuIGRvbWluaW8uIE5vIA0KICAgIGVzIG5lY2VzYXJpbyBhY3VkaXIgYSBwcm92H ZWVkb3JlcyBkZSBJbnRlcm5ldCBvIEV4cGVydG9zIHBhcmEgZWxsby4gU2kgbGUgDQogICAgH Z3VzdGEgdW4gZG9taW5pbywgcmVnaXN0cmVsbyB1c3RlZCBkaXJlY3RhbWVudGUsIGFob3JyH ZXNlIGNvc3RvcywgeSBzb2JyZXRvZG8sIA0KICAgIGxvIG1hcyBpbXBvcnRhbnRlLCBubyBwH aWVyZGEgdW4gbm9tYnJlIGRlIGRvbWluaW8gcG9yIGxhIG5vIGRpc3BvbmliaWxpZGFkIA0KH ICAgIGRlIHVuIHRlY25pY28gZW4gZXNlIG1vbWVudG8uPC9mb250PjwvbGk+DQogIDxsaT48H Zm9udCBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplH PSIzIiBjb2xvcj0iIzk5MDAwMCI+PHU+QnVzcXVlZGEgDQogICAgaW50ZWxpZ2VudGUgZGUgH ZG9taW5pb3MgbGlicmVzPC91PjwvZm9udD48Zm9udCBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgH SGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIyIj4gDQogICAgZW4gY2FzbyBkZSBxdWUgH bnVlc3RyYSBzZWxlY2Npb24gZXN0ZSBvY3VwYWRhIHBvciB1biB0ZXJjZXJvLjwvZm9udD48H L2xpPg0KPC91bD4NCjxwIGFsaWduPSJjZW50ZXIiPjxmb250IGZhY2U9IkFyaWFsLCBIZWx2H ZXRpY2EsIHNhbnMtc2VyaWYiPjxiPkNvbXBydWViZWxvIGFob3JhIA0KICBtaXNtbyBkZXNkH ZSBlc3RlIGUtbWFpbDwvYj48L2ZvbnQ+PGJyPiANCiAgPHA+DQoJPGRpdiBhbGlnbj0iY2VuH dGVyIj4gDQogIDxmb3JtIG1ldGhvZD0icG9zdCIgYWN0aW9uPSJodHRwOi8vd3d3LmRpcmVjH dG5pYy5jb20vc2VhcmNoL2luZGV4LnBocD9BbmdlbG9zbzY5Ij4NCiAgICA8aW5wdXQgdHlwH ZT1oaWRkZW4gbmFtZT1mdW5jdGlvbiB2YWx1ZT0ic2VhcmNoX2RvbWFpbnMiPg0KICAgIDxpH bnB1dCB0eXBlPWhpZGRlbiBuYW1lPWRuX2FkcyB2YWx1ZT0iQW5nZWxvc282OSI+DQogICAgH PGRpdiBhbGlnbj0iY2VudGVyIj4gDQogICAgICA8dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkH ZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHdpZHRoPSI0NjgiIGhlaWdodD0iNjAiIGFsaWduH PSJjZW50ZXIiPg0KICAgICAgICA8dHI+IA0KICAgICAgICAgIDx0ZCByb3dzcGFuPSIyIiB3H aWR0aD0iMjQ5InZhbGlnbj0idG9wIj48YSBocmVmPSJodHRwOi8vd3d3LmRpcmVjdG5pYy5jH b20vP0FuZ2Vsb3NvNjkiPjxpbWcgbmFtZT0ic3JjaGJucjAxX3IxX2MxIiBzcmM9Imh0dHA6H Ly93d3cuc2Vydmlkb3Jlc2RldmVyZGFkLmNvbS9zcmNoYm5yMDFfcjFfYzEuZ2lmIiB3aWR0H aD0iMjQ5IiBoZWlnaHQ9IjYwIiBib3JkZXI9IjAiPjwvYT48L3RkPg0KICAgICAgICAgIDx0H ZCBjb2xzcGFuPSIyIiBoZWlnaHQ9IjMwIiBhbGlnbj0iY2VudGVyIiB2YWxpZ249InRvcCIgH Ymdjb2xvcj0iIzAwMzM5OSI+IA0KICAgICAgICAgICAgPGRpdiBhbGlnbj0ibGVmdCI+IA0KH ICAgICAgICAgICAgICA8aW5wdXQgdHlwZT0idGV4dCIgbmFtZT0ic2VhcmNoX2RvbWFpbiIgH c2l6ZT0iMjAiIG1heGxlbmd0aD0iNjQiPg0KICAgICAgICAgICAgPC9kaXY+DQogICAgICAgH ICAgPC90ZD4NCiAgICAgICAgICA8dGQgcm93c3Bhbj0iMiIgd2lkdGg9IjcyIiB2YWxpZ249H InRvcCI+PGEgaHJlZj0iaHR0cDovL3d3dy5kaXJlY3RuaWMuY29tLz9BbmdlbG9zbzY5Ij48H aW1nIG5hbWU9InNyY2hibnIwMV9yMV9jNCIgc3JjPSJodHRwOi8vd3d3LnNlcnZpZG9yZXNkH ZXZlcmRhZC5jb20vc3JjaGJucjAxX3IxX2M0LmdpZiIgd2lkdGg9IjM2IiBoZWlnaHQ9IjYwH IiBib3JkZXI9IjAiPjwvYT48L3RkPg0KICAgICAgICA8L3RyPg0KICAgICAgICA8dHIgdmFsH aWduPSJ0b3AiPiANCiAgICAgICAgICA8dGQgaGVpZ2h0PSIyNCIgd2lkdGg9IjU5Ij48YSBoH cmVmPSJodHRwOi8vd3d3LmRpcmVjdG5pYy5jb20vP0FuZ2Vsb3NvNjkiPjxpbWcgbmFtZT0iH c3JjaGJucjAxX3IyX2MyIiBzcmM9Imh0dHA6Ly93d3cuc2Vydmlkb3Jlc2RldmVyZGFkLmNvH bS9zcmNoYm5yMDFfcjJfYzIuZ2lmIiB3aWR0aD0iNTkiIGhlaWdodD0iMzAiIGJvcmRlcj0iH MCI+PC9hPjwvdGQ+DQogICAgICAgICAgPHRkIGhlaWdodD0iMjQiIHdpZHRoPSI4OCIgYWxpH Z249ImxlZnQiIHZhbGlnbj0ibWlkZGxlIiBiZ2NvbG9yPSIjMDAzMzk5Ij4gDQogICAgICAgH ICAgICA8aW5wdXQgdHlwZT0ic3VibWl0IiBuYW1lPSJTdWJtaXQiIHZhbHVlPSJCVVNDQVIiH IHN0eWxlPSJmb250OiA4cHQgQXJpYWwsIEhlbHZldGljYSwgc2FuLXNlcmlmIj4NCiAgICAgH ICAgICA8L3RkPg0KICAgICAgICA8L3RyPg0KICAgICAgPC90YWJsZT4NCiAgICANCiAgPHA+H Jm5ic3A7PC9wPg0KPC9kaXY+DQo8cCBhbGlnbj0ibGVmdCI+PGZvbnQgZmFjZT0iVmVyZGFuH YSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgc2l6ZT0iNCI+PGI+Mi48L2I+PC9mH b250Pjxmb250IGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiH IHNpemU9IjIiPiANCiAgPGI+PGZvbnQgY29sb3I9IiMwMDAwOTkiIHNpemU9IjMiPjxhIGhyH ZWY9Imh0dHA6Ly93d3cuc2Vydmlkb3Jlc2RldmVyZGFkLmNvbSI+SG9zcGVkYWplIA0KICB2H aXJ0dWFsPC9hPjwvZm9udD48L2I+IGRlc2RlIDIuNTAwIHB0YXMuIGFsIG1lcywgc2luIGRvH bWluaW8gcHJvcGlvLCBvIGJpZW4gDQogIHBvciA1LjAwMCBhbCBtZXMgY29uIGRvbWluaW8gH cHJvcGlvLjwvZm9udD48L3A+DQo8dWw+DQogIDxsaT4NCiAgICA8ZGl2IGFsaWduPSJsZWZ0H Ij48Zm9udCBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzH aXplPSIyIj4gDQogICAgICBTaW4gbGltaXRlIGRlIGVzcGFjaW8gcGFyYSBwYWdpbmFzIHdlH Yi48L2ZvbnQ+PC9kaXY+DQogIDwvbGk+DQogIDxsaT4NCiAgICA8ZGl2IGFsaWduPSJsZWZ0H Ij48Zm9udCBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzH aXplPSIyIj5BY2Nlc28gDQogICAgICBwb3IgRlRQPC9mb250PjwvZGl2Pg0KICA8L2xpPg0KH ICA8bGk+DQogICAgPGRpdiBhbGlnbj0ibGVmdCI+PGZvbnQgZmFjZT0iVmVyZGFuYSwgQXJpH YWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgc2l6ZT0iMiI+NSANCiAgICAgIGN1ZW50YXMgH ZGUgY29ycmVvIGVsZWN0cm9uaWNvIFBvcDMgKGFjY2VzaWJsZXMgdGFtYmllbiBhIHRyYXZlH cyBkZSBXZWIpPC9mb250PjwvZGl2Pg0KICA8L2xpPg0KICA8bGk+DQogICAgPGRpdiBhbGlnH bj0ibGVmdCI+PGZvbnQgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zH ZXJpZiIgc2l6ZT0iMiI+RGl2ZXJzb3MgDQogICAgICBDR0lzIHJlYWR5IHRvIHJ1biBlbiBlH bCBzaXN0ZW1hLjwvZm9udD48L2Rpdj4NCiAgPC9saT4NCjwvdWw+DQo8cCBhbGlnbj0ibGVmH dCI+PGZvbnQgZmFjZT0iVmVyZGFuYSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgH c2l6ZT0iMiI+UG9zaWJpbGlkYWQgDQogIGRlIGFtcGxpY2FjaW9uIGRlIGxvcyBzZXJ2aWNpH b3Mgc2luIGxpbWl0ZSwgc29sbyBlcyBjdWVzdGlvbiBkZSBuZWdvY2lhciBwcmVjaW9zLiANH CiAgU29tb3MgRVhQRVJUT1MgZW4gY29tZXJjaW8gZWxlY3Ryb25pY28uPC9mb250PjwvcD4NH CjxwIGFsaWduPSJsZWZ0Ij48L3A+DQo8cCBhbGlnbj0ibGVmdCI+PC9wPg0KPHAgYWxpZ249H ImxlZnQiPjxmb250IGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyH aWYiIHNpemU9IjIiPjxiPjxmb250IHNpemU9IjQiPjMuPC9mb250PjwvYj4gDQogIDxmb250H IGNvbG9yPSIjMDAwMDk5Ij48Yj48Zm9udCBzaXplPSIzIj48YSBocmVmPSJodHRwOi8vd3d3H LnNlcnZpZG9yZXNkZXZlcmRhZC5jb20iPkhvc3BlZGFqZSANCiAgcmVhbDwvYT48L2ZvbnQ+H PC9iPjwvZm9udD4gZW4gc2Vydmlkb3IgcHJvcGlvIGVuIEVzdGFkb3MgVW5pZG9zIDx1PmRlH c2RlICQxMDAgDQogIGRvbGFyZXMgYWwgbWVzPC91PiAoMTkuMDAwIHB0YXMuKSBjb25lY3RhH ZG8gYSBzdSBwcm9waWEgbGluZWEgRFNMIGRlIDY0MCBNYml0cy9zZWcuIA0KICA8dT5vIGJpH ZW4gcG9yICQxNzA8L3U+ICgzMS4wMDAgcHRhcy4pIGNvbmVjdGFkbyBhIHVuIGFuaWxsbyBtH dWx0aXBsZSBPQy0zLiBUYW1iaWVuIA0KICBkaXNwb25lbW9zIGRlIGxpbmVhcyBwcm9waWFzH IFQxIGluZGl2aWR1YWxlcyBhY3RpdmFkYXMgZW4gcG9jYXMgaG9yYXMsIDx1PmRlc2RlIA0KH ICAkMSwwMDA8L3U+ICgxODEuMDAwIHB0YXMuKSBhbCBtZXMuPGJyPg0KICBJbmNsdXNvIHBvH ZGVtb3Mgc3VtaW5pc3RyYXIgbG9zIG9yZGVuYWRvcmVzIG5vc290cm9zIG1pc21vcy4gRXF1H aXBvcyBDb21wYXEsIA0KICBJYm0sIEhwIG8gc2ltaWxhciBhbCBtZWpvciBwcmVjaW8gZGUgH VVNBLjwvZm9udD48L3A+DQo8cCBhbGlnbj0ibGVmdCI+PC9wPg0KPHAgYWxpZ249ImxlZnQiH Pjxmb250IGZhY2U9IlZlcmRhbmEsIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiIHNpH emU9IjIiPkVzcGVybyANCiAgcXVlIGVzdGEgaW5mb3JtYWNpb24gc2VhIGRlIHN1IGFncmFkH bywgeSBzaSBsZSBoZW1vcyBtb2xlc3RhZG8gbG8gc2VudGltb3MgbXVjaG8sIA0KICBubyB2H b2x2ZXJhIGEgb2N1cnJpci4gRGUgdG9kYXMgZm9ybWFzIHNpIGRlc2VhIHNlciBpbmZvcm1hH ZG8gcmVndWxhcm1lbnRlIGRlIA0KICBudWVzdHJvcyBzZXJ2aWNpb3MsIG5hdmVndWUgaGFzH dGEgbnVlc3RyYSBwYWdpbmEgd2ViIGUgaW5zY3JpYmFzZSBhIHRyYXZlcyBkZSANCiAgZWxsH YSBjb24gZWwgZm9ybXVsYXJpbyBxdWUgZW5jb250cmFyYSBhbCBwaWUgZGUgbGEgcGFnaW5hH IHByaW5jaXBhbC4gPGEgaHJlZj0iaHR0cDovL3d3dy5zZXJ2aWRvcmVzZGV2ZXJkYWQuY29tH Ij5odHRwOi8vd3d3LnNlcnZpZG9yZXNkZXZlcmRhZC5jb208L2E+PC9mb250PjwvcD4NCjxwH IGFsaWduPSJsZWZ0Ij48Zm9udCBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzH YW5zLXNlcmlmIiBzaXplPSIyIj48YnI+DQogIDwvZm9udD48L3A+DQo8aHI+DQo8ZGl2IGFsH aWduPSJsZWZ0Ij48Zm9udCBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zH LXNlcmlmIiBzaXplPSIyIj48Zm9udCBzaXplPSIxIiBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhH LCBzYW5zLXNlcmlmIj4gDQogIDxmb250IGNvbG9yPSIjMDBDQ0NDIj5Fc3RlIG1lbnNhamUgH c2UgZW52JmlhY3V0ZTthIGVuIGNvbmNvcmRhbmNpYSBjb24gbGEgbnVldmEgDQogIGxlZ2lzH bGFjaSZvYWN1dGU7biBzb2JyZSBjb3JyZW8gZWxlY3RyJm9hY3V0ZTtuaWNvOiBQb3Igc2VjH Y2kmb2FjdXRlO24gMzAxLCANCiAgcCZhYWN1dGU7cnJhZm8gKGEpKDIpKEMpIGRlIFMuMTYxH OCBCYWpvIGVsIGRlY3JldG8gUy4xNjE4IHQmaWFjdXRlO3R1bG8gM3JvLiANCiAgYXByb2JhH ZG8gcG9yIGVsIDEwNSBjb25ncmVzbyBiYXNlIGRlIGxhcyBub3JtYXRpdmFzIGludGVybmFjH aW9uYWxlcyBzb2JyZSBTUEFNLCANCiAgZXN0ZSBFLW1haWwgbm8gcG9kciZhYWN1dGU7IHNlH ciBjb25zaWRlcmFkbyBTUEFNIG1pZW50cmFzIGluY2x1eWEgdW5hIGZvcm1hIA0KICBkZSBzH ZXIgcmVtb3ZpZG8uIFBhcmEgc2VyIHJlbW92aWRvIGRlIGxhIGxpc3RhIHNpbXBsZW1lbnRlH IHB1bHNlIGVuIGVsIGxpbmsgDQogIGRlIGNvbnRpbnVhY2lvbjxmb250IGNvbG9yPSIjMDA2H NjY2Ij46IDxhIGhyZWY9Im1haWx0bzpzZXJ2aWRvcmVzQHp4bWFpbC5jb20/U3ViamVjdD1VH bnN1YmNyaWJlLVNFUnNwIj5zZXJ2aWRvcmVzQHp4bWFpbC5jb20/U3ViamVjdD1VbnN1YnNjH cmliZS1TRVJzcDwvYT48L2ZvbnQ+PC9mb250PjwvZm9udD48L2ZvbnQ+IA0KPC9kaXY+DQo8H cCBhbGlnbj0ibGVmdCI+PGZvbnQgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpH ZiIgc2l6ZT0iMSIgY29sb3I9IiMwMENDQ0MiPlRoaXMgDQogIG1lc3NhZ2UgaXMgTk9UIEEgH U1BBTSBiZWNhdXNlIGl0IGhhcyBhbiBhdXRvbWF0aWMgcHJvY2VkdXJlIHRvIGRlbGV0ZSB5H b3VyIG5hbWUgDQogIGZyb20gdGhpcyBsaXN0IChTZWN0aW9uIDMwMSwgcGFyYWdyYXBoIChhH KSgyKShDKSBvZiBTLjE2MTgsIHVuZGVyIGRlY3JlZSBTLjE2MTggDQogIDNyZCBUaXRsZSwgH YXBwcm92ZWQgaW4gMTA1dGggY29uZ3Jlc3MgYWJvdXQgU1BBTSkuIElmIHlvdSB3YW50IHRvH IGJlIGRlbGV0ZWQgDQogIGZyb20gdGhpcyBkYXRhYmFzZSwgcGxlYXNlIHByZXNzIG9uIHRoH aXMgbGluayBhbmQgc2VuZCB0aGUgbWVzc2FnZSBieSBlLW1haWwuIA0KICA8Zm9udCBjb2xvH cj0iIzAwNjY2NiI+PGEgaHJlZj0ibWFpbHRvOiUzQ2ZvbnQlMjBmYWNlPSUyMkFyaWFsLCUyH MEhlbHZldGljYSwlMjBzYW5zLXNlcmlmJTIyJTIwc2l6ZT0lMjIxJTIyJTIwY29sb3I9JTIyH IzAwQ0NDQyUyMiUzRSUzQ2ZvbnQlMjBjb2xvcj0lMjIjMDA2NjY2JTIyJTNFc2Vydmlkb3JlH c0B6eG1haWwuY29tP1N1YmplY3Q9VW5zdWJzY3JpYmUtU0VSZW4lM0MvZm9udCUzRSUzQy9mH b250JTNFIj5zZXJ2aWRvcmVzQHp4bWFpbC5jb20/U3ViamVjdD1VbnN1YnNjcmliZS1TRVJlH bjwvYT48L2ZvbnQ+IA0KICBXZSZhY3V0ZTtyZSBzb3JyeSBpZiB3ZSBoYXZlIGluY29udmVuH aWVuY2VkIHlvdS48L2ZvbnQ+PC9wPg0KPGhyPg0KPHAgYWxpZ249ImxlZnQiPiA8YSB0YXJnH ZXQ9Il90b3AiIGhyZWY9Imh0dHA6Ly91LmV4dHJlbWUtZG0uY29tLz9sb2dpbj1zZXJ2bWFpH bCI+IA0KICA8aW1nIG5hbWU9aW0gc3JjPSJodHRwOi8vdTEuZXh0cmVtZS1kbS5jb20vaS5nH aWYiIGhlaWdodD0xDQpib3JkZXI9MCB3aWR0aD0xIGFsdD0iIj48L2E+IA0KICA8c2NyaXB0H IGxhbmd1YWdlPSJqYXZhc2NyaXB0Ij48IS0tDQphbj1uYXZpZ2F0b3IuYXBwTmFtZTtkPWRvH Y3VtZW50O2Z1bmN0aW9uDQpwcigpe2Qud3JpdGUoIjxpbWcgc3JjPVwiaHR0cDovL3UwLmV4H dHJlbWUtZG0uY29tIiwNCiIvMC5naWY/dGFnPXNlcnZtYWlsJmo9eSZzcnc9IitzcncrIiZzH cmI9IitzcmIrIiYiLA0KInJzPSIrcisiJmw9Iitlc2NhcGUoZC5yZWZlcnJlcikrIlwiIGhlH aWdodD0xICIsDQoid2lkdGg9MT4iKTt9c3JiPSJuYSI7c3J3PSJuYSI7Ly8tLT4NCjwvc2NyH aXB0PjxzY3JpcHQgbGFuZ3VhZ2U9ImphdmFzY3JpcHQxLjIiPjwhLS0NCnM9c2NyZWVuO3NyH dz1zLndpZHRoO2FuIT0iTmV0c2NhcGUiPw0Kc3JiPXMuY29sb3JEZXB0aDpzcmI9cy5waXhlH bERlcHRoOy8vLS0+DQo8L3NjcmlwdD48c2NyaXB0IGxhbmd1YWdlPSJqYXZhc2NyaXB0Ij48H IS0tDQpyPTQxO2QuaW1hZ2VzP3I9ZC5pbS53aWR0aDp6PTA7cHIoKTsvLy0tPg0KPC9zY3JpH cHQ+PG5vc2NyaXB0PjxpbWcgaGVpZ2h0PTEgd2lkdGg9MSBhbHQ9IiIgDQpzcmM9Imh0dHA6H Ly91MC5leHRyZW1lLWRtLmNvbS8wLmdpZj90YWc9c2Vydm1haWwmaj1uIj48L25vc2NyaXB0H Pg0KIDwvcD4NCjxwIGFsaWduPSJsZWZ0Ij48Zm9udCBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhH LCBzYW5zLXNlcmlmIiBzaXplPSIxIj4gPC9mb250PiA8L3A+DQo8cCBhbGlnbj0ibGVmdCI+H PGZvbnQgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgc2l6ZT0iMSI+IDwvH Zm9udD48L3A+DQo8cCBhbGlnbj0icmlnaHQiPjxmb250IGZhY2U9IkFyaWFsLCBIZWx2ZXRpH Y2EsIHNhbnMtc2VyaWYiIHNpemU9IjEiIGNvbG9yPSIjMDBDQzAwIj48aT5TZW5kZWQgDQogH IGJ5IG1hc3NtYWlsZXJwcm8gdjMuMiAtdW5yZWdpc3RlcmVkIHZlcnNpb24tPC9pPjwvZm9u$ dD48L3A+DQo8L2JvZHk+DQo8L2h0bWw+DQo=  - ------=_NextPart_000_001__62462596_37859,89--b   ------------------------------  % Date: Sat, 13 May 2000 09:15:51 -0400-* From: David A Froble <davef@tsoft-inc.com>= Subject: Re: Problem with Seagate disk on VAXstation 4000 VLCj- Message-ID: <391D5587.8BE693AA@tsoft-inc.com>a  A > This is a VAXstation 4000 VLC.  I am only putting one device INpB > the box but I have an external disk and CRDOM.  All this playing> > about is ONLY with the internal disk and the bus terminated. >   M Ok, first the disclaimer, I don't claim this is accurate.  I think I rememberiP reading once that some of the earlier VAXstation 4000 VLC models were limited inL the size (both physical and capacity) of the internal disk. Possibly the maxP capacity was an RZ25 or such.  Not saying this is so, and it doesn't sound right2 to me, but I think I read this tidbit at one time.   Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596; 170 Grimplin Road               E-Mail: davef@tsoft-inc.comz Vanderbilt, PA  154868   ------------------------------  % Date: Mon, 15 May 2000 17:04:25 -0500S* From: WILLIAM WEBB <WWEBB1@email.usps.gov>5 Subject: Re[2]: HELP on calculating percentage in DCLv- Message-ID: <0033000022513052000002L022*@MHS>S   =0AHi Lars,G  = the item codes for F$GETDVI are MAXBLOCK and FREEBLOCKS, whenk corrected the routineg performs o.k. for me.q   Lars Jacobsen wrote: >N > Hello all. > H > I have a small routine that examines the blocks free and max availabl= e blocksD > on a number of disk devices using F$GETDVI(device,"MAXBLOCKS") and > F$GETDVI(device,"FREEBLOCK").gH > Now I would like to perform some action (say send a mail) if the perc= entage& free > is lower than a certain number.
 > Sort of: >G* > $ b_max =3D F$GETDVI(device,"MAXBLOCKS")+ > $ b_free =3D F$GETDVI(device,"FREEBLOCK")C > $ pct =3D (b_free*100)/b_max& > $ IF pct .LT. 10 THEN GOTO send_mail >p. > The calculation of PCT however doesn't work.3 > It looks like there's an integer/decimal problem.3  > Using F$INTEGER hasn't helped. >B > Any suggestions ?C >W > -- > Kind Regards0 > ----------------------------------------------0 > Lars Jacobsen          Phone : +45 89 45 41 800 > Tele Danmark IT        Fax   : +45 89 45 61 02 > Takseringssystemer (BNTT)W- > S/8-173                email  : laja@tdk.dkh > Gunnar Clausens Vej 28 > DK-8260 Viby J0 > ----------------------------------------------   --  - mit freundlichen Gruessen | with best regardsm   Karl RohwedderB iT-Ingenieurteam     | Ellernbruch 11       | D-38112 BraunschweigA Telefon: 0531/515521 | Telefax: 0531/515531 | Mobil: 0172/5434843+D  E-Mail: rohwedder@decus.decus.de           | iT-IngTeam@t-online.de+          karl.rohwedder@it-ingenieurteam.deD DATEX-P: 4505018005::ROHWEDDER  = File item 2 original document name: extern.karl.rohwedder.vcfz! File item 2 document type: PCDATAz File item 2 size (bytes): 345G  5      You have to fake it- DCL only does integer math.g          WWWebb=   ------------------------------  # Date: Mon, 15 May 2000 23:50:40 GMTv1 From: Pat Jankowiak <vaxhackery@worldnet.att.net>lT Subject: RSVPs requested Re: DFWDAYS, A Compaq Update Weekend June 2nd, 3rd, and 4th0 Message-ID: <3929C85F.E87A1D9F@worldnet.att.net>   Hello friends, S  K The time is approaching, and we need to plan for exact numbers for food andyL drink, etc.., so Please e-mail us (RSVP) if you have not registered, but are+ going to attend the Compaq Update Weekend. m   Thanks!G    Please RSVP to dfwdays@decus.org    - > Announcing DFWDAYS, A Compaq Update WeekendW >  > June 2nd, 3rd, and 4th# > [Full info at website, see below]1 >    > > > Please check out the frequently updated info at the website: > http://dfwdays.dfwcug.org/   ------------------------------  % Date: Mon, 15 May 2000 13:56:19 -0400i From: jlahman@LTVSteel.com Subject: Some OPC websites8 Message-ID: <852568E0.00629DAC.00@notesnta.LTVSteel.com>   Here are some OPC websites:m   www.intellution.com/opchub& www.controlmagazine.com/opc/index.html www.opcfoundation.org2    P For other sites, use this search string (put in quotes): OLE for Process Control   ------------------------------  % Date: Mon, 15 May 2000 22:03:03 -070085 From: "cstranslations" <cstranslations@email.msn.com>2, Subject: RE: String descriptors, BASIC and C) Message-ID: <#FaHCQvv$GA.231@cpmsnbbsa04>S  > Richard Banks <rbanks@arel.com.au.nospamming> wrote in message+ news:39202037.17892064@news.magna.com.au...2G >"cstranslations" <cstranslations@email.msn.com> produced the followingW >pearl of wisdom:H   Well - half way any way.  H I fooled around a little bit this morning with passing a string argumentK from BASIC to C, modifying it, then trying to return it. Seemed to run intonE a problem in that the length and address in the descriptor seem to be9G "cleared" once I entered the C code (which left me scratching my head).yF Passing the string [argument] and having the C function return the [a]J descriptor address figuring that it's going to get "plugged" into the leftF side of the BASIC statement turns out to be suspect. I'm tied up otherH things and haven't really thought about the mechanics involved however -9 this is essentially "returning a pointer to a temporary."n  L I don't own a copy of the BASIC manuals and I'm not at work [and off the topK of my head I don't think they go into much detail concerning mixed languageWL programming]. I do own the C manual which does discuss the topic a bit more.G Essentially - the C function should return void and accept at least twojK descriptors. The first argument [dynamic string descriptor] is what you areHK returning and on entry the length and address are clear. The string you areGB passing is next [or in position n+1 where the BASIC function has n arguments].m  J You are still [of course] subject to using the string routines to free and) allocate memory if the length is changed.3   Joel   >Thanks heaps!!!!! >GD >That worked great - the program now runs perfectly (if only I could' >return a string descriptor - oh well).k >K >C
 >- Richard >2" >[rbanks@arel.remove_this_bit.com]   ------------------------------  % Date: Mon, 15 May 2000 20:36:37 -0700z5 From: "cstranslations" <cstranslations@email.msn.com>X1 Subject: String descriptors, BASIC and C - part 2i) Message-ID: <#RQCtfuv$GA.242@cpmsnbbsa04>h  > Richard Banks <rbanks@arel.com.au.nospamming> wrote in message+ news:39202037.17892064@news.magna.com.au...gG >"cstranslations" <cstranslations@email.msn.com> produced the followings >pearl of wisdom:m   Well - half way any way.  H I fooled around a little bit this morning with passing a string argumentK from BASIC to C, modifying it, then trying to return it. Seemed to run intoyE a problem in that the length and address in the descriptor seem to beGG "cleared" once I entered the C code (which left me scratching my head).TF Passing the string [argument] and having the C function return the [a]J descriptor address figuring that it's going to get "plugged" into the leftF side of the BASIC statement turns out to be suspect. I'm tied up otherH things and haven't really thought about the mechanics involved however -9 this is essentially "returning a pointer to a temporary."z  L I don't own a copy of the BASIC manuals and I'm not at work [and off the topK of my head I don't think they go into much detail concerning mixed languageHL programming]. I do own the C manual which does discuss the topic a bit more.G Essentially - the C function should return void and accept at least two K descriptors. The first argument [dynamic string descriptor] is what you arejK returning and on entry the length and address are clear. The string you aregB passing is next [or in position n+1 where the BASIC function has n arguments].h  J You are still [of course] subject to using the string routines to free and) allocate memory if the length is changed.2   Joe9   >Thanks heaps!!!!! >0D >That worked great - the program now runs perfectly (if only I could' >return a string descriptor - oh well).n >G >X
 >- Richard >j" >[rbanks@arel.remove_this_bit.com]   ------------------------------  # Date: Mon, 15 May 2000 18:34:50 GMTy3 From: "Gord Coulman" <nospam_gcoulman@ccinet.ab.ca>g< Subject: Re: Suggest a better file serving solution than NT?: Message-ID: <erXT4.11077$%u6.627483@news1.telusplanet.net>  J Update:  I changed the ATI 2MB PCI video card to an 8MB AGP Diamond 460 onL Friday, using the "Microsoft Certified" NT4 drivers that came with the card.J It ran for a few hours then BSOD, referencing the Diamond drivers.  I thenK switched it to the default VGA drivers that came with NT4.  The machine rangH all weekend without a hitch.  I will wait and see what happens this week? before experimenting further (change only one thing at a time).8  K If if turns out to be the video, can anyone recommend a "proven" video cardg and drivers?  % BTW, the motherboard is an ASUS P2B-DG Gord.g  < Gord Coulman <nospam_gcoulman@ccinet.ab.ca> wrote in message3 news:RfDS4.9238$%u6.495514@news1.telusplanet.net...2J > I know this is a bit off topic, but my primary NT file server is driving meI > nuts with unexplained system hangs and I need to repair/replace it withzL > something approaching the reliability of my OpenVMS machine.  I am open toL > all suggestions, not just another NT box, although the clients are all WinL > 98 and other NT servers, which narrows things a bit.  I have run Pathworks. > in the past, but I'm not going back there... >m" > Awaiting your collective wisdom, >g > Gord.C >WK > Present system: custom built, NT4.0 SP6A, ASUS dual PIII/600 1GB ECC RAM,GK > 9GB mirrored system disk, 140 GB RAID using 18GB Seagate 7200 RPM drives,mJ > Ultra wide Mylex 3ch RAID controller with battery backup, dual redundantF > power supply, dual 3COM 780 load balancing NICs, Diskeeper (latest), McAfee6 > (latest), Undelete (latest), ATI PCI 2MB video card. >zD > Services:  PDC, file services only (print, backup, and application services > on different servers)l >hB > Environment:  about 200 users in a semi-isolated location, heavy
 multimediaE > file i/o.  Typical CPU usage below 30% during peak hours.  Switchedu 100Mbitp > Ethernet (3Com). >zD > Symptoms:  becomes unresponsive.  Needs power-off reset to reboot. HappensiJ > every couple of days at random intervals.  No blue screen, no entries inJ > event log.  No entries in Mylex log.  Desktop freezes, usually including > mouse. >uK > Repair efforts so far:  New RAM, new CPUs, new NICs (problem seemed to gohJ > away after this, now it's back), more cooling (very cool now), shut down7 > Diskeeper, Undelete, McAfee.  Problem is still there.j >GH > Repair efforts soon:  New video card, replace NICs with Intel, replace( > motherboard, replace whole damn thing. >j >j >2   ------------------------------  % Date: Mon, 15 May 2000 15:38:16 -07008. From: Jack Trachtman <Jack.Trachtman@vmmc.org>+ Subject: Re: Utility to track device errorsN( Message-ID: <39207C58.EF0B6514@vmmc.org>  N This is definitely overkill for what you're asking, but I am in the process ofE installing the Heroix ROBOMON product.  One of its "rules" is to scanG- for and notify if any hardware errors appear.G   "Kevin P. Inscoe" wrote:   > AndradeJA-A wrote: > >yM > > Considering the fact that our cluster doesn't go down and considering theh
 > > fact thatFP > > device errors can accumulate in such a way as to make their analysis a minorO > > headache at best and overly time consuming at worst.  Does anyone know of a3N > > utility that regularly logs changes in SHOW ERROR and sends resulting data > > to! > > an output file/email account.g > > $ > > Jay Andrade - VMS System Manager > > NUWC, RI >gF > I do this with the diag command on our Alphas. We monitor everything > fromI > unix machines (Solaris) into HP's OpenView ITO product. So I wrote this1 > shell script:z >s > #!/bin/csh -f3 > #gF > # vms_getoplog - written by Kevin P. Inscoe (Monitor Gateway System) > #yD > # rsh into vms system, perform diag /since and parse for number of) > # "device errors" or "unknown entries".n > #y> > # Use this OpenVMS Lexical function to get 15 minutes prior: > #g/ > # f$cvtime("-00:15:00","absolute","datetime")G > #g > # History: > #X& > # When          Who             What& > # ----          ---             ----0 > # 4-6-2000     Kevin Inscoe    Create Original > #wA > ###############################################################W >C > #W > # Announce ourselves > #+ >gC > /bin/echo $0\: " starting at " `/bin/date` " on OpenVMS host " $1W >k > # globalsC4 > set rcpcmd = `/bin/echo "rcp/user=\042$1\042/log"` > #/bin/echo $rcpcmd( > source /osgss1/apps/monitor/globals.sh/ > set TMP_A = /tmp/vms_getnewerrors_a_$DTMP.tmpm/ > set TMP_B = /tmp/vms_getnewerrors_b_$DTMP.tmp2 >GI > (/bin/rsh $1 -l system `/bin/cat $BASEDIR/vms_last15mins.dat`) > $TMP_A0
 > #cat $TMP_AgH > set delta = `/bin/tail -2 $TMP_A | /bin/head -1 | /bin/awk '{ print $1 > ":" $2 }'v+ >  | /bin/head -1 | /bin/tr -d '[:space:]'`3& > /bin/echo "VMS Delta time is" $delta > /bin/rm $TMP_A > /bin/echo " "p4 > /bin/echo "---- Starting OpenVMS diagnosis ------" > /bin/echo " "GE > #(/bin/rsh $1 -l system diagnose/since=`/bin/echo $delta`) > $TMP_Bh+ > (/bin/rsh $1 -l system diagnose) > $TMP_Bg > /bin/echo " "G > /bin/echo " "p2 > /bin/echo "---- Ending OpenVMS diagnosis ------" > /bin/echo " "0 >v
 > #cat $TMP_Bj >j > #h0 > # Now sort and provide a rollup of error types > #j >V4 > /bin/grep "Entry type" $TMP_B | /bin/sort > $TMP_A
 > #cat $TMP_A1 > /bin/uniq < $TMP_A > $TMP_Bn > cp $TMP_B /tmp/x.x
 > #cat $TMP_Bk: > /opt/bin/perl $BASEDIR/count_vms_errors.pl $TMP_B $TMP_A > cp $TMP_B /apps/monitor/x.x6 >i > #2 > # CleanupD > #l >X! > if ( -e $TMP_A ) /bin/rm $TMP_AB! > if ( -e $TMP_B ) /bin/rm $TMP_B0 >gI > I had to enable rsh access from UCX on the Alphas of course to do this.W >D. > The Perl script count_vms_errors.pl is here: >u > #!/opt/bin/perl -w >Q > #y > # Globals  > #m >W > $error = ""; >3 > #g > # Process file > #v >38 > open (IN, "$ARGV[0]") || die "$0: Error opening $1\n"; > while (<IN>)    {H >  >         $xtemp = $_; >         $temp = $xtemp;u >         chomp($temp);i >         $temp =~ tr/ / /s; >         chop($temp);$ >         @fields=split(/ /, $temp); >         $fields=@fields;? > #       print "$0: OpenVMS Diagnosis Error String=@fields\n";j >         $number=$fields[2]; = > #       print "$0: OpenVMS Diagnosis Entry Type=$number\n";z >         $name1=$fields[3]; >         $error = $name1;# >         if ($fields > 4)        {v, >                         $name2=$fields[4];( >                         chomp($name2);( >                         $error .= " ";+ >                         $error .= $name2;l# >                                 }+# >         if ($fields > 5)        {i, >                         $name3=$fields[5];( >                         chomp($name3);( >                         $error .= " ";+ >                         $error .= $name3;W# >                                 }3# >         if ($fields > 6)        {4, >                         $name4=$fields[6];( >                         chomp($name4);( >                         $error .= " ";+ >                         $error .= $name4;T# >                                 }N# >         if ($fields > 7)        {9, >                         $name5=$fields[7];( >                         chomp($name5);( >                         $error .= " ";+ >                         $error .= $name5;q# >                                 }h# >         if ($fields > 8)        {y, >                         $name6=$fields[8];( >                         chomp($name6);( >                         $error .= " ";+ >                         $error .= $name6;N# >                                 }S# >         if ($fields > 9)        {m, >                         $name7=$fields[9];( >                         chomp($name7);( >                         $error .= " ";+ >                         $error .= $name7;2# >                                 }H3 >         $count = `/bin/grep -n $number $ARGV[1]`;T >         chop($number);% >         @junque=split(/:/, $count);l >         $junque=@junque;= >         print "$error [Type $number] ($junque[0] found)\n";6 >                 }-
 > close (IN);- >-G > Of course you could the same under VMS directly but you get the idea!< >e > ~kevin > --< > Kevin P. Inscoe   Senior Unix System Engineer & Specialist< > Deltona, FL       Itinerary at http://www.inscoe.org/where& > e-mail:  kevin [at] inscoe [dot] org< > http://www.inscoe.org                    28.9492N 81.1955W< > http://www.inscoe.org/comp     http://www.inscoe.org/radio< > "No husband has ever been shot while doing the dishes" Unk   ------------------------------  % Date: Mon, 15 May 2000 14:28:32 -0500o, From: Howard S Shubs <hshubs@mindspring.com>( Subject: Re: Verifying username password> Message-ID: <hshubs-6D4C7D.14283215052000@news.mindspring.com>  M In article <hQOlsqpqF34m@eisner.decus.org>, young_r@eisner.decus.org (Robert i
 Young) wrote:t  # >	Other solutions are welcome also.i  > This would be a very simple program using SYS$HASH_PASSWORD(). -- e; Howard S Shubs      hshubs@mindspring.com    hshubs@bix.com ? The Denim Adept     Which is better, Maryann or pickled Ginger?-> SPAM: uce@ftc.gov   postmaster@[127.0.0.1]   abuse@[127.0.0.1]   ------------------------------  % Date: Mon, 15 May 2000 20:32:43 -0400l* From: David A Froble <davef@tsoft-inc.com>( Subject: Re: Verifying username password, Message-ID: <3920972B.78EF921@tsoft-inc.com>   Robert Young wrote:  > i > In article <5YMK6EGOoO0t@eisner.decus.org>, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:r_ > > In article <hQOlsqpqF34m@eisner.decus.org>, young_r@eisner.decus.org (Robert Young) writes:s > >>@ > >>      I have a need to allow users sign into an open accountC > >>      to make a menu choice to kill off other users.  The grouprF > >>      that has access to the "open" account would then be verifiedA > >>      against their true username and password to ensure thisiM > >>      isn't being abused/misused and for auditing.  I've try to dredge upsJ > >>      a freeware product but can't find it or am not thinking about it > >>      correctly. > >> > >>      summarizing: > >>% > >>      1) login to captive accountC) > >>      2) prompt for username/password-I > >>      3) check against UAF that username password are correct without5+ > >>              actually logging them in.8P > >>      4) if pass check in 3) prompt them for user to whack and then whackem. > >>E > >>      Why this way?  Don't want to hand out privs here and there.-+ > >>      Other solutions are welcome also.h > >uD > > I believe you would be much more secure by writing a program andD > > installing the image with WORLD privilege and protecting it with9 > > an identifier granted only to the authorized zappers.r > F >         I think I understand what you are saying but the entry pointG >         is the DCL menu in the captive account.  By writing a programnE >         and using an associated identifier would work , but I don't:E >         have a common entry point in the number of DCL menus/loginsCE >         that are spread hither and yon.  Perhaps a common situation-C >         for a lot of us.  So for me, it is easier to add featuresvB >         and functionalities to specialized accounts and now thatA >         end users get ideas they drive me in certain directions5H >         I sometimes don't want to go.  One of them is here.  End usersH >         like to design things too.  If they had it there way, it would@ >         be a menu choice only.. I'm trying to keep things from? >         getting really ugly by identifying who is doing what.  > % >                                 RobA  K Ok, you need to do it in the manner you described.  Not much of a problem. sP Prompt for a username, look-up (I'd recommend not accessing SYSUAF directly) theP account record.  If found, then get the password, remember to turn off echo, andP check the password as Howard suggested.  To me the larger job is identifying theL process to 'whack'.  There's also the questions of how to do the 'wacking'. % Force an exit, or really stomp on it.o  6 Someone's gotta have something that does most of this.   Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596; 170 Grimplin Road               E-Mail: davef@tsoft-inc.comc Vanderbilt, PA  15486l   ------------------------------  # Date: Tue, 16 May 2000 01:50:50 GMTs& From: "gadtec" <gadtec@bigpond.net.au> Subject: Re: VMS backup on PCm= Message-ID: <_P1U4.3992$Kc3.25473@news-server.bigpond.net.au>a       Thanks.   H     Someone has allready told me about 'IMDrive', software that can readA     most backup tapes (HW & SW) on PC. I am still to test it out.i  .     Dont you mean VMSTAR for the tar program ?      5 Arne Vajhj <arne.vajhoej@gtech.com> wrote in messageS# news:391FBB38.E8B4DCEE@gtech.com... E > >     Does anyone know of s/w that can read files from a VMS Backupe  > >     tape (DAT) into Windoze. >t< > A C-program to read VMS BACKUP save-sets on Unix exist and0 > I would assume, that it could be ported to NT. >n > But why bother ? >t; > Get someone with a VMS system to read the tape and createu > a new tape with a TAR/ZIP !h >  > Arne   ------------------------------  % Date: Mon, 15 May 2000 22:15:05 +0200s. From: "Marc Van Dyck" <marc.vandyck@skynet.be>0 Subject: Where to start with motif programming ?* Message-ID: <8fplp6$315$1@news0.skynet.be>  I I have been asked to write a 'very simple' Motif program - it looked very]D simple indeed, until I saw some - supposedly simple too - Motif codeL examples. As I want to learn, I won't describe what I need to write here, toK be sure that nobody will provide the piece of code that I need, rather thannJ letting me write it myself. However, I don't know where to start. What I'dB like to see is a document describing the basic principles of motifE programming, explaining widgets, uil, and all the stuff. And also, ifsG possible, some simple, but well commented, pieces of code examples. HaskK anyone something to provide or recommend - preferrably in electronic form ?y   TIA,   -- Marc  (Marc.Vandyck@skynet.be)   ------------------------------  # Date: Mon, 15 May 2000 23:53:14 GMT-, From: TMcGrath@cendant.com.au (Tony McGrath)4 Subject: Re: Where to start with motif programming ?3 Message-ID: <39208bcc.4038915@news.mel.aone.net.au>B  3 On Mon, 15 May 2000 22:15:05 +0200, "Marc Van Dyck"n <marc.vandyck@skynet.be> wrote:@  J >I have been asked to write a 'very simple' Motif program - it looked veryE >simple indeed, until I saw some - supposedly simple too - Motif code M >examples. As I want to learn, I won't describe what I need to write here, to L >be sure that nobody will provide the piece of code that I need, rather thanK >letting me write it myself. However, I don't know where to start. What I'd C >like to see is a document describing the basic principles of motiftF >programming, explaining widgets, uil, and all the stuff. And also, ifH >possible, some simple, but well commented, pieces of code examples. HasL >anyone something to provide or recommend - preferrably in electronic form ? >n >TIA,    Hi Marc,  ! Try starting with the MOTIF FAQ :h% http://www.rahul.net/kenton/mfaq.htmlc  + For some code examples and tutorials, try :r  http://www.cen.com/mw3/code.html; http://devcentral.iftech.com/learning/tutorials/misc/motif/   + That ought to be enough to get you started.  Cheers from Oz,i   Tony ---m      C Tony McGrath, Systems Administrator, British Airways Executive ClubtN Cendant Membership Services, 596 North Road, Ormond, Victoria, 3204, Australia- Phone : 61 3 9578 8233   Fax : 61 3 9578 6326n   ------------------------------   End of INFO-VAX 2000.272 ************************