1 INFO-VAX	Mon, 29 May 2000	Volume 2000 : Issue 298       Contents:7 Re: "VMS on Wildfire" Slides from NELUG meeting May 4th , Re: Compaq not as bad as Andrew says (wish?), Re: Compaq not as bad as Andrew says (wish?), Re: Compaq not as bad as Andrew says (wish?), Re: Compaq not as bad as Andrew says (wish?), Re: Compaq not as bad as Andrew says (wish?), Re: Compaq not as bad as Andrew says (wish?), Re: Compaq not as bad as Andrew says (wish?), Re: Compaq not as bad as Andrew says (wish?), Re: Compaq not as bad as Andrew says (wish?), Re: Compaq not as bad as Andrew says (wish?), Re: Compaq not as bad as Andrew says (wish?), Re: Compaq not as bad as Andrew says (wish?), Re: Compaq not as bad as Andrew says (wish?), Re: Compaq not as bad as Andrew says (wish?) DecServer 700 "boot up"  Re: DecServer 700 "boot up"  Re: DecServer 700 "boot up"  error tcpip pop server Re: error tcpip pop server# Re: none urgent cobol exit question & RMS handling of extremely long records" Re: RMS tuning versus file caching Setting password Re: Setting password Re: Setting password Re: Setting password Re: Setting password) Software update at nucwww.chem.sunysb.edu  UNSUB INFO-VAX- Re: VAX VMS 7.2 Bug? ; backup/image/(no)alias  Re: Vms calculator Re: VMS on the desktop?  Re: VMS on the desktop? 
 War Stories ?  Re: War Stories ? & Re: [humor] UNIX/OpenVMS email "virus"  F ----------------------------------------------------------------------  % Date: Sun, 28 May 2000 14:23:51 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> @ Subject: Re: "VMS on Wildfire" Slides from NELUG meeting May 4th( Message-ID: <8gro29$ig1$1@pyrite.mv.net>  + Paul Sture <paul@sture.ch> wrote in message % news:VA.00000063.04d78bad@sture.ch... > > In article <C22568E9.005A6362.00@jklh21.valmet.com>,  wrote: >  > >  > > Soon to be fixed!  > > E > > [BSOD's notwithstanding, it is no less unsafe to "turn off" a VMS  machine  > > without first ? > > performing an orderly shutdown than it is a Wintel machine. L > > You never shut down an OpenVMS cluster, but you do sometimes shut down a VMS D > > machine. The "beauty part" is that they are not the same thing.] > > C > Sorry, but I have to correct you there. NT employs a "lazy write" 
 technique.  J That's only less safe if applications use it unsafely (which they can alsoH do on VMS using deferred writes - and while NT's cache gradually flushesG dirty data back to disk automatically, IIRC VMS deferred writes may sit E around for arbitrary lengths of time in cache).  Any application that L depends upon exactly what data made it to disk on a re-start (most don't, inL either environment:  they just clean up and start over) can access its filesF with write-back caching disabled.  And NT's write-back caching doesn'tJ affect the integrity of the NTFS file system, and even the FAT file systemL is brought back to a usable state by running (yuck) CHKDSK on reboot, thoughJ it's possible that a larger amount of recently-written data may be at risk of loss in this case.    - bill   >  > ___  > Paul Sture
 > Switzerland  >    ------------------------------  % Date: Sun, 28 May 2000 14:34:03 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> 5 Subject: Re: Compaq not as bad as Andrew says (wish?) ( Message-ID: <8grolb$jg1$1@pyrite.mv.net>  5 David A Froble <davef@tsoft-inc.com> wrote in message ' news:392EB8D4.FABBBF52@tsoft-inc.com...    ...   F > The problem is not with VMS, but with C programs written to use UnixD > capabilities.  Should the same application be written to use VMS's
 capabilities, D > it should match the performance of T64, and many times exceed T64.  G Despite appearances, I'm enough of a VMS bigot myself to be inclined to J agree that an optimized application on VMS should usually be able to matchJ or exceed the performance of an optimized application on <pick your Unix>.G However, the skill set required to optimize an application on VMS is in C radically shorter supply than the skill set required to optimize an A application on most Unixes, and if you're willing to settle for a J good-but-not-literally-optimal approach (which in the real world is almostH always the case) the gap in availability of skill sets widens even more.J And it is reasonably arguable that the complexity of optimization, or evenI near-optimization, on VMS is greater in an absolute sense, independent of  familiarity to the masses.  K So the real problem is that VMS doesn't provide an environment in which the I skill sets of the people who write and use these applications can be used G effectively:  if it did, then it might well remain an overall-effective  solution for them.     I'd rather6 > use global sections than file caching in some cases.  J Care to list them?  Even for simple cross-application read-caching, globalI sections are a bit of a pain compared to a central system cache:  must be E set up, torn down, and sized explicitly on an individual basis, don't L balance activity across independent application sets to achieve best overallK system throughput.  For write-back caching, add the need to figure out when L and how often to flush them (Unix typically flushes automatically by defaultH at 30-second intervals, and some variants tweak this mechanism to attainG improved on-disk file contiguity and eliminate disk writes entirely for H files deleted before they're flushed).  If you're willing to use 'locateJ mode' access to operate on the buffer contents directly instead of throughJ RMS's normal record interface (not sure you could do this for write accessC in a global buffer, though) you could assert that this saves a copy E operation, and in any event you save a system call per 'record' - but I crossing the system interface is a lot less expensive than it used to be.      Too many capabilities to > start a list here. > L > As for the evolution of VMS, the earliest systems in 1978 were more suited toK > scientific computing.  It was the input of the business users that helped  VMS B > grow into an enterprise class OS.  Things like BACKUP, extensive print/batch F > queue capabilities, the data integrity you don't seem to care about.  K I can't remember a time, even in 1978, when anyone could have said that VMS H wasn't as concerned about data integrity as it presumably remains today.L And while backup utilities had a checkered history dating back to the 11, itA wasn't for lack of trying to make them as solid as possible (some 9 implementors were just less experienced than later ones).   L It's true that VMS became *more* suited to business computing in areas otherI than data integrity as time went on.  But I don't see that it ever became D *less* suited to scientific computing - save in the area of platformL price-competitiveness, subsequent lapse into unfamiliarity, and then, due toF the resulting lack of market interest, a less-than-aggressive attitude1 toward matching new features developed elsewhere.    - bill   >  > Dave >  > --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    ------------------------------  % Date: Sun, 28 May 2000 14:49:45 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 5 Subject: Re: Compaq not as bad as Andrew says (wish?) , Message-ID: <39316A48.141F5C60@videotron.ca>   Bill Todd wrote:I > However, the skill set required to optimize an application on VMS is in E > radically shorter supply than the skill set required to optimize an C > application on most Unixes, and if you're willing to settle for a ) > good-but-not-literally-optimal approach   K I disagree significantly. There is a HUGE basin of available VMS expertise. K The problem is that due to lack of VMS work (because customers have left or I stopped improving their VMS systems over the years), most have found work I elsewhere and don't advertise their VMS capabilities nor seek work in VMS N because of its "Palmer is killing VMS" image.  VMS is still seen as a "legacy"O expertise while "NT" is seen as "hire anyone who has written "NT" in their CV".   N Once you have a VMS system that is tuned and operating nicely with no softwareG upgrades, there isn't much work needed to keep it running, and few very ; experienced folks would be interested in such work anyways.   : But setup a challenging VMS shop with serious applicationsM deployment/development, and you might get many of those ex-VMS experts out of 
 the woodwork.    ------------------------------  % Date: Sun, 28 May 2000 15:49:59 -0500 ) From: "John E. Malmberg" <wb8tyw@qsl.net> 5 Subject: Re: Compaq not as bad as Andrew says (wish?) 7 Message-ID: <066e01bfc8e6$4c0ac230$020a0a0a@xile.realm>    Bill Todd wrote:I > However, the skill set required to optimize an application on VMS is in E > radically shorter supply than the skill set required to optimize an C > application on most Unixes, and if you're willing to settle for a ) > good-but-not-literally-optimal approach   J Actually the skill set required to optimize an application on any platform is in short supply.   G Most places find it faster or cheaper to buy faster servers or add more D servers instead of actually paying for quality improvements to theirA systems.  And proper optimization can take time that you need the  applications running.   F The exception to this is when you hit a wall were you can not purchaseD faster hardware.  Then you must make it work.  That is were the real expertise is needed.     J.F. Mezei wrote:   B > I disagree significantly. There is a HUGE basin of available VMS
 expertise.J > The problem is that due to lack of VMS work (because customers have left orK > stopped improving their VMS systems over the years), most have found work K > elsewhere and don't advertise their VMS capabilities nor seek work in VMS G > because of its "Palmer is killing VMS" image.  VMS is still seen as a  "legacy"L > expertise while "NT" is seen as "hire anyone who has written "NT" in their CV".  H Companies with good pay and work environments tend to retain top people.H They can take the time to hire promising beginners and train them.  Thus3 they do not need to hire "experts", they keep them.   J At the sites I have been at, for VMS work, we never recruited specificallyL VMS people, we hired programmers, and with little work oriented them on VMS.  L The experienced people that we hired or contracted were always from "word of$ mouth", not professional recruiting.  H And there are plenty of advertisements that I have seen for NON-VMS workJ where they state that experience on VMS is one of the prefered credential.# Very easy to find on any job board.    -John  wb8tyw@qsl.network   ------------------------------  % Date: Sun, 28 May 2000 17:39:06 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> 5 Subject: Re: Compaq not as bad as Andrew says (wish?) ( Message-ID: <8gs3ga$jbg$1@pyrite.mv.net>  J Definitely a valid point, unlike JF's, which in asserting that getting VMSL expertise into a *single* shop might not be too difficult avoided addressingK the point he was supposedly disagreeing with, which was that the *absolute* L supply of VMS expertise is considerably smaller than that of Unix expertise, no matter how you slice it.   K Not to mention the related point that you need *more* expertise to get good K performance out of VMS than out of Unix, which gives most applications good ! performance right out of the box.   G And of course that last dovetails neatly with your own observation that J people seldom bother with much performance optimization:  for such typicalK non-performance-optimized applications, Unix therefore makes more efficient G use of the hardware than VMS does, hence is correctly perceived as more  cost-effective.    - bill  2 John E. Malmberg <wb8tyw@qsl.net> wrote in message1 news:066e01bfc8e6$4c0ac230$020a0a0a@xile.realm...  > Bill Todd wrote:K > > However, the skill set required to optimize an application on VMS is in G > > radically shorter supply than the skill set required to optimize an E > > application on most Unixes, and if you're willing to settle for a + > > good-but-not-literally-optimal approach  > L > Actually the skill set required to optimize an application on any platform > is in short supply.  > I > Most places find it faster or cheaper to buy faster servers or add more F > servers instead of actually paying for quality improvements to theirC > systems.  And proper optimization can take time that you need the  > applications running.  > H > The exception to this is when you hit a wall were you can not purchaseF > faster hardware.  Then you must make it work.  That is were the real > expertise is needed. >  >  > J.F. Mezei wrote:  > D > > I disagree significantly. There is a HUGE basin of available VMS > expertise.L > > The problem is that due to lack of VMS work (because customers have left > orH > > stopped improving their VMS systems over the years), most have found workI > > elsewhere and don't advertise their VMS capabilities nor seek work in  VMS I > > because of its "Palmer is killing VMS" image.  VMS is still seen as a 
 > "legacy"H > > expertise while "NT" is seen as "hire anyone who has written "NT" in their  > CV". > J > Companies with good pay and work environments tend to retain top people.J > They can take the time to hire promising beginners and train them.  Thus5 > they do not need to hire "experts", they keep them.  > L > At the sites I have been at, for VMS work, we never recruited specificallyI > VMS people, we hired programmers, and with little work oriented them on  VMS. > K > The experienced people that we hired or contracted were always from "word  of& > mouth", not professional recruiting. > J > And there are plenty of advertisements that I have seen for NON-VMS workL > where they state that experience on VMS is one of the prefered credential.% > Very easy to find on any job board.  >  > -John  > wb8tyw@qsl.network >  >    ------------------------------  % Date: Sun, 28 May 2000 18:01:16 -0400 * From: David A Froble <davef@tsoft-inc.com>5 Subject: Re: Compaq not as bad as Andrew says (wish?) - Message-ID: <3931972C.CC6CCF12@tsoft-inc.com>   # Not going to let that one slide by.    Bill Todd wrote: > L > Definitely a valid point, unlike JF's, which in asserting that getting VMSN > expertise into a *single* shop might not be too difficult avoided addressingM > the point he was supposedly disagreeing with, which was that the *absolute* N > supply of VMS expertise is considerably smaller than that of Unix expertise, > no matter how you slice it.  > M > Not to mention the related point that you need *more* expertise to get good M > performance out of VMS than out of Unix, which gives most applications good # > performance right out of the box.   H On what do you base this claim?  My perspective is that VMS has a betterO development environment, thus allowing better applictions with less expertize.  L Good VMS applications give good performance right out of the box.  Since theM development environment is friendly, good VMS applications are rather easy to  produce.  I > And of course that last dovetails neatly with your own observation that L > people seldom bother with much performance optimization:  for such typicalM > non-performance-optimized applications, Unix therefore makes more efficient I > use of the hardware than VMS does, hence is correctly perceived as more  > cost-effective.   K Again, a rationalization with no supporting facts.  On what do you base the I claim that Unix makes more efficient use of the hardware?  Your posts are L starting to sound like wishful opinion, or outright trolls.  For someone whoH catches others making claims without substantiating them, you seem to be# following right in their footsteps.   K You're probably going to now find a post of mine that did this.  Fine.  I'm L probably guilty.  However, I will issue this challenge.  An application thatL does not favor either environment, if there is such, will be more easily andO quickly developed on VMS than on Unix.  I'm willing to bet a buck on it, and do 
 the VMS side.    Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596; 170 Grimplin Road               E-Mail: davef@tsoft-inc.comu Vanderbilt, PA  15486    ------------------------------  % Date: Sun, 28 May 2000 18:23:57 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>t5 Subject: Re: Compaq not as bad as Andrew says (wish?)s( Message-ID: <8gs64g$ngf$1@pyrite.mv.net>  H Apologies - it's been 13+ years since I use RMS, and considerably longer: since I've thought about some of its more obscure options.  I Turns out locate mode is not applicable to global buffers at all, read or D write - in fact, it only works for read access even when using localJ buffers.  So if you want shared buffers, you can't avoid a copy operation,! whether you're using VMS or Unix.e  I RMS does make use of global buffers fairly easy, though, even if it isn'taG transparent and the space can't be used as flexibly as a central systeme
 cache can.  8 And returning to an earlier point, the documentation forL read-ahead/write-behind states that it applies only to non-shared SequentialJ files (my recollection, which I couldn't verify in a quick search, is thatG you still may be able to provide multiple buffers for indexed files andtF obtain some LRU caching value - e.g., for upper index levels - but not read-ahead operation).   - bill  0 Bill Todd <billtodd@foo.mv.com> wrote in message" news:8grolb$jg1$1@pyrite.mv.net...7 > David A Froble <davef@tsoft-inc.com> wrote in message ) > news:392EB8D4.FABBBF52@tsoft-inc.com...- >- > ...- >-H > > The problem is not with VMS, but with C programs written to use UnixF > > capabilities.  Should the same application be written to use VMS's > capabilities, F > > it should match the performance of T64, and many times exceed T64. >eI > Despite appearances, I'm enough of a VMS bigot myself to be inclined to9L > agree that an optimized application on VMS should usually be able to matchL > or exceed the performance of an optimized application on <pick your Unix>.I > However, the skill set required to optimize an application on VMS is in E > radically shorter supply than the skill set required to optimize anoC > application on most Unixes, and if you're willing to settle for atL > good-but-not-literally-optimal approach (which in the real world is almostJ > always the case) the gap in availability of skill sets widens even more.L > And it is reasonably arguable that the complexity of optimization, or evenK > near-optimization, on VMS is greater in an absolute sense, independent ofI > familiarity to the masses. > I > So the real problem is that VMS doesn't provide an environment in whiche thepK > skill sets of the people who write and use these applications can be usedvI > effectively:  if it did, then it might well remain an overall-effectivei > solution for them. >  >   I'd rather8 > > use global sections than file caching in some cases. >yL > Care to list them?  Even for simple cross-application read-caching, globalK > sections are a bit of a pain compared to a central system cache:  must beeG > set up, torn down, and sized explicitly on an individual basis, don't F > balance activity across independent application sets to achieve best overalleH > system throughput.  For write-back caching, add the need to figure out whenF > and how often to flush them (Unix typically flushes automatically by defaultyJ > at 30-second intervals, and some variants tweak this mechanism to attainI > improved on-disk file contiguity and eliminate disk writes entirely forMJ > files deleted before they're flushed).  If you're willing to use 'locateL > mode' access to operate on the buffer contents directly instead of throughL > RMS's normal record interface (not sure you could do this for write accessE > in a global buffer, though) you could assert that this saves a copylG > operation, and in any event you save a system call per 'record' - but K > crossing the system interface is a lot less expensive than it used to be.i >  >   Too many capabilities to > > start a list here. > > G > > As for the evolution of VMS, the earliest systems in 1978 were moren suited > toF > > scientific computing.  It was the input of the business users that helped > VMSeD > > grow into an enterprise class OS.  Things like BACKUP, extensive
 > print/batchnH > > queue capabilities, the data integrity you don't seem to care about. > I > I can't remember a time, even in 1978, when anyone could have said thatt VMS J > wasn't as concerned about data integrity as it presumably remains today.K > And while backup utilities had a checkered history dating back to the 11,e itC > wasn't for lack of trying to make them as solid as possible (some ; > implementors were just less experienced than later ones).h > H > It's true that VMS became *more* suited to business computing in areas othernK > than data integrity as time went on.  But I don't see that it ever becameaF > *less* suited to scientific computing - save in the area of platformK > price-competitiveness, subsequent lapse into unfamiliarity, and then, duee toH > the resulting lack of market interest, a less-than-aggressive attitude3 > toward matching new features developed elsewhere.  >  > - bill >h > >  > > Dave > >  > > --8 > > David Froble                       Tel: 724-529-04508 > > Dave Froble Enterprises, Inc.      Fax: 724-529-0596? > > 170 Grimplin Road               E-Mail: davef@tsoft-inc.come > > Vanderbilt, PA  15486d >  >y >r   ------------------------------  % Date: Sun, 28 May 2000 18:55:46 -0400r' From: "Bill Todd" <billtodd@foo.mv.com>c5 Subject: Re: Compaq not as bad as Andrew says (wish?)e( Message-ID: <8gs804$q65$1@pyrite.mv.net>  5 David A Froble <davef@tsoft-inc.com> wrote in messagen' news:3931972C.CC6CCF12@tsoft-inc.com...u% > Not going to let that one slide by.l >l > Bill Todd wrote: > >dJ > > Definitely a valid point, unlike JF's, which in asserting that getting VMSoE > > expertise into a *single* shop might not be too difficult avoidede
 addressingD > > the point he was supposedly disagreeing with, which was that the
 *absolute*E > > supply of VMS expertise is considerably smaller than that of Unixu
 expertise, > > no matter how you slice it.s > >oJ > > Not to mention the related point that you need *more* expertise to get goodJ > > performance out of VMS than out of Unix, which gives most applications good% > > performance right out of the box.e >r! > On what do you base this claim?t  I I'm afraid that in your zeal to defend the honor of VMS, you seem to havenL lost sight of the context in which this part of the discussion evolved (evenJ though you participated in it yourself):  the very specific area of Unix's. automated file caching vs. VMS's lack of same.  D That this gives typical applications better performance on Unix is aL no-brainer.  It has other consequences that some people here may believe are7 pernicious, but lack of performance is not one of them.g  )   My perspective is that VMS has a bettersE > development environment, thus allowing better applictions with lesse
 expertize.  L There are areas in which I would not dispute this assertion, but file-systemG performance is not one of them (at least in comparison with Unixes thataK safely defer meta-data updates as well as user data updates, whether by use0% of logs or 'soft update' mechanisms).e  C > Good VMS applications give good performance right out of the box.y  H 'Good' is a subjective term, so let's just say that default, unoptimizedK Unix file system performance is noticeably better than default, unoptimized J VMS file system performance for typical applications, mostly due to Unix'sK default system caching (my vague recollection is that VMS can be configurednF to read-cache at the disk level, though possibly only in non-clusteredL environments, though that may no longer be a restriction, which helps some -E though the path to such a cache is considerably longer than that to atE file-level cache - but in any case doesn't cover write-back caching).s  I And at least some Unix file systems (SGI's and Veritas' - don't happen tolF know details about others in this area) allow the cache to be bypassedG ('direct I/O') when desired - e.g., to avoid copying overheads on largevI transfers.  Veritas, in fact, does this automatically above a specifiablesJ transfer size (256 KB by default), and SGI's XFS may as well, avoiding any. special application coding to cover this case.     Since the L > development environment is friendly, good VMS applications are rather easy to
 > produce. >oK > > And of course that last dovetails neatly with your own observation that-F > > people seldom bother with much performance optimization:  for such typicallE > > non-performance-optimized applications, Unix therefore makes more-	 efficientbK > > use of the hardware than VMS does, hence is correctly perceived as morel > > cost-effective.m > I > Again, a rationalization with no supporting facts.  On what do you base  ther; > claim that Unix makes more efficient use of the hardware?r  K I obviously should have repeated, about every other sentence, the fact thatlG these observations were made in the context of the file-caching commentiK originated in David Mathog's post.  In that context, Unix indubitably makesrL more efficient default use of the hardware in any environment where file I/O is significant to performance.     Your posts areJ > starting to sound like wishful opinion, or outright trolls.  For someone whooJ > catches others making claims without substantiating them, you seem to be% > following right in their footsteps.t  K No, I'm just letting David Mathog's observations about relative performanceaG stand.  One specific example he gave was compilation performance, but IcK suspect he could supply others (and not being a Unix user I can't, though I C know enough about what's happening under the covers not to have any J hesitation about drawing conclusions about performance from it, given even  moderate external confirmation).  I If you want to learn something, pay attention.  If you'd rather just callw names, go ahead.   - bill   >.H > You're probably going to now find a post of mine that did this.  Fine. I'mhI > probably guilty.  However, I will issue this challenge.  An applicationy thatJ > does not favor either environment, if there is such, will be more easily andSJ > quickly developed on VMS than on Unix.  I'm willing to bet a buck on it, and do > the VMS side.e >h > Dave >  > --6 > David Froble                       Tel: 724-529-04506 > Dave Froble Enterprises, Inc.      Fax: 724-529-0596= > 170 Grimplin Road               E-Mail: davef@tsoft-inc.comO > Vanderbilt, PA  15486a   ------------------------------  % Date: Sun, 28 May 2000 18:37:22 -0500f) From: "John E. Malmberg" <wb8tyw@qsl.net>l5 Subject: Re: Compaq not as bad as Andrew says (wish?),. Message-ID: <sj3b2gen5pj40@corp.supernews.com>  % Bill Todd <billtodd@foo.mv.com> wrotea.  in message news:8gs3ga$jbg$1@pyrite.mv.net...L > Definitely a valid point, unlike JF's, which in asserting that getting VMSC > expertise into a *single* shop might not be too difficult avoidedn
 addressingB > the point he was supposedly disagreeing with, which was that the
 *absolute*C > supply of VMS expertise is considerably smaller than that of Unixl
 expertise, > no matter how you slice it.   I Ok, let's address it.  Computer systems being physical machines are stillxF ultimately bound by the laws of physics.  What kind of expert would be better?p  L One that knows those laws and but not VMS, but has the disipline to RTFM and actually understand them.o  K Or one that knows VMS from experience, but does not actually understand the  physics.  H > Not to mention the related point that you need *more* expertise to get goodH > performance out of VMS than out of Unix, which gives most applications good# > performance right out of the box.a  I Yes UNIX can give most (not all) applications good performance.  But when@J you understand why, it gives you a better perspective on when to recommend each platform.  K However *more* expertise is a term I would not use.  Most of the techniquestG I used to use with VMS tuning came from formulas in an IBM VM/SP tuningsK guide.  That was when it was possible to get data to/from your paging diskseK faster than the CPU could use it.  Now CPUs are outrunning the disks by too  much.   F Most of the tuning parameters of OpenVMS are well documented.  SomeoneK familiar with their application and computer systems can RTFM and find thisr out.  J I went to several UNIX experts to find out why all systems of a particularL brand suddenly died one day.  They did not know.  I found out why by using a ethernet monitor.t  J It turned out that it was the equivalent of a non-page pool exhausted.  ItI turned out a default configuration was causing it to download the routing K tables from the corporate router.  I guess for "performance" it stored them  in the non-page pool.   F Yes, I talked to the vendor's support line.  For my efforts I got sentF copies of two articles that had nothing to with the problem statement.  K I contend that true tuning expertise in other platforms is as rare as it isiL in VMS.  A higher market share for UNIX and M$SOFT attracts more pretenders.  I > And of course that last dovetails neatly with your own observation that L > people seldom bother with much performance optimization:  for such typicalC > non-performance-optimized applications, Unix therefore makes mores	 efficient I > use of the hardware than VMS does, hence is correctly perceived as moren > cost-effective.w  8 I do not know if that perception is always correct.  :-)   -Johnn wb8tyw@qsl.network   ------------------------------  % Date: Sun, 28 May 2000 19:49:32 -0500a* From: Keith Brown <kbrown780@usfamily.net>5 Subject: Re: Compaq not as bad as Andrew says (wish?)y, Message-ID: <3931BE9C.B78D355F@usfamily.net>   Bill Todd wrote: > J > Apologies - it's been 13+ years since I use RMS, and considerably longer< > since I've thought about some of its more obscure options. > K > Turns out locate mode is not applicable to global buffers at all, read or F > write - in fact, it only works for read access even when using localL > buffers.  So if you want shared buffers, you can't avoid a copy operation,# > whether you're using VMS or Unix.  > K > RMS does make use of global buffers fairly easy, though, even if it isn'ttI > transparent and the space can't be used as flexibly as a central systemf > cache can. > : > And returning to an earlier point, the documentation forN > read-ahead/write-behind states that it applies only to non-shared SequentialL > files (my recollection, which I couldn't verify in a quick search, is thatI > you still may be able to provide multiple buffers for indexed files andaH > obtain some LRU caching value - e.g., for upper index levels - but not > read-ahead operation). >  > - bill > 2 > Bill Todd <billtodd@foo.mv.com> wrote in message$ > news:8grolb$jg1$1@pyrite.mv.net...9 > > David A Froble <davef@tsoft-inc.com> wrote in messageo+ > > news:392EB8D4.FABBBF52@tsoft-inc.com...h > >  > > ...x > >nJ > > > The problem is not with VMS, but with C programs written to use UnixH > > > capabilities.  Should the same application be written to use VMS's > > capabilities,tH > > > it should match the performance of T64, and many times exceed T64. > >cK > > Despite appearances, I'm enough of a VMS bigot myself to be inclined toiN > > agree that an optimized application on VMS should usually be able to matchN > > or exceed the performance of an optimized application on <pick your Unix>.K > > However, the skill set required to optimize an application on VMS is ineG > > radically shorter supply than the skill set required to optimize anrE > > application on most Unixes, and if you're willing to settle for atN > > good-but-not-literally-optimal approach (which in the real world is almostL > > always the case) the gap in availability of skill sets widens even more.N > > And it is reasonably arguable that the complexity of optimization, or evenM > > near-optimization, on VMS is greater in an absolute sense, independent of  > > familiarity to the masses. > >bK > > So the real problem is that VMS doesn't provide an environment in which  > the M > > skill sets of the people who write and use these applications can be used K > > effectively:  if it did, then it might well remain an overall-effective  > > solution for them. > >- > >   I'd rather: > > > use global sections than file caching in some cases. > >oN > > Care to list them?  Even for simple cross-application read-caching, globalM > > sections are a bit of a pain compared to a central system cache:  must be,I > > set up, torn down, and sized explicitly on an individual basis, don't H > > balance activity across independent application sets to achieve best	 > overall J > > system throughput.  For write-back caching, add the need to figure out > whenH > > and how often to flush them (Unix typically flushes automatically by	 > defaultVL > > at 30-second intervals, and some variants tweak this mechanism to attainK > > improved on-disk file contiguity and eliminate disk writes entirely forlL > > files deleted before they're flushed).  If you're willing to use 'locateN > > mode' access to operate on the buffer contents directly instead of throughN > > RMS's normal record interface (not sure you could do this for write accessG > > in a global buffer, though) you could assert that this saves a copybI > > operation, and in any event you save a system call per 'record' - butaM > > crossing the system interface is a lot less expensive than it used to be.  > >8 > >   Too many capabilities to > > > start a list here. > > >oI > > > As for the evolution of VMS, the earliest systems in 1978 were more- > suited > > toH > > > scientific computing.  It was the input of the business users that > helped > > VMSaF > > > grow into an enterprise class OS.  Things like BACKUP, extensive > > print/batchaJ > > > queue capabilities, the data integrity you don't seem to care about. > >aK > > I can't remember a time, even in 1978, when anyone could have said thatn > VMSoL > > wasn't as concerned about data integrity as it presumably remains today.M > > And while backup utilities had a checkered history dating back to the 11,a > itE > > wasn't for lack of trying to make them as solid as possible (somer= > > implementors were just less experienced than later ones).  > >nJ > > It's true that VMS became *more* suited to business computing in areas > otherdM > > than data integrity as time went on.  But I don't see that it ever becamenH > > *less* suited to scientific computing - save in the area of platformM > > price-competitiveness, subsequent lapse into unfamiliarity, and then, duen > toJ > > the resulting lack of market interest, a less-than-aggressive attitude5 > > toward matching new features developed elsewhere.s > >h
 > > - bill > >e > > >e
 > > > Dave > > >  > > > --: > > > David Froble                       Tel: 724-529-0450: > > > Dave Froble Enterprises, Inc.      Fax: 724-529-0596A > > > 170 Grimplin Road               E-Mail: davef@tsoft-inc.coma > > > Vanderbilt, PA  15486m > >r > >p > >t   Bill,c  > If you use HSxx controllers on your systems whether it be Unix> or VMS (we use them on both at my shop) the file caching issue' is mute because the controller does it.a   -- c Keith Brown  kbrown780@usfamily.net   ------------------------------  % Date: Sun, 28 May 2000 19:53:08 -0500g* From: Keith Brown <kbrown780@usfamily.net>5 Subject: Re: Compaq not as bad as Andrew says (wish?)a, Message-ID: <3931BF74.790D37A2@usfamily.net>   Bill Todd wrote: > L > Definitely a valid point, unlike JF's, which in asserting that getting VMSN > expertise into a *single* shop might not be too difficult avoided addressingM > the point he was supposedly disagreeing with, which was that the *absolute*tN > supply of VMS expertise is considerably smaller than that of Unix expertise, > no matter how you slice it.f > M > Not to mention the related point that you need *more* expertise to get good M > performance out of VMS than out of Unix, which gives most applications gooda# > performance right out of the box.e > I > And of course that last dovetails neatly with your own observation thattL > people seldom bother with much performance optimization:  for such typicalM > non-performance-optimized applications, Unix therefore makes more efficient I > use of the hardware than VMS does, hence is correctly perceived as more  > cost-effective.  >  > - bill > 4 > John E. Malmberg <wb8tyw@qsl.net> wrote in message3 > news:066e01bfc8e6$4c0ac230$020a0a0a@xile.realm...e > > Bill Todd wrote:M > > > However, the skill set required to optimize an application on VMS is inaI > > > radically shorter supply than the skill set required to optimize an G > > > application on most Unixes, and if you're willing to settle for as- > > > good-but-not-literally-optimal approach  > >lN > > Actually the skill set required to optimize an application on any platform > > is in short supply.n > > K > > Most places find it faster or cheaper to buy faster servers or add moreiH > > servers instead of actually paying for quality improvements to theirE > > systems.  And proper optimization can take time that you need theh > > applications running.i > >sJ > > The exception to this is when you hit a wall were you can not purchaseH > > faster hardware.  Then you must make it work.  That is were the real > > expertise is needed. > >  > >2 > > J.F. Mezei wrote:  > >pF > > > I disagree significantly. There is a HUGE basin of available VMS > > expertise.N > > > The problem is that due to lack of VMS work (because customers have left > > orJ > > > stopped improving their VMS systems over the years), most have found > workK > > > elsewhere and don't advertise their VMS capabilities nor seek work in6 > VMSiK > > > because of its "Palmer is killing VMS" image.  VMS is still seen as a3 > > "legacy"J > > > expertise while "NT" is seen as "hire anyone who has written "NT" in > their  > > CV". > >eL > > Companies with good pay and work environments tend to retain top people.L > > They can take the time to hire promising beginners and train them.  Thus7 > > they do not need to hire "experts", they keep them.  > >tN > > At the sites I have been at, for VMS work, we never recruited specificallyK > > VMS people, we hired programmers, and with little work oriented them onn > VMS. > >pM > > The experienced people that we hired or contracted were always from "worda > of( > > mouth", not professional recruiting. > > L > > And there are plenty of advertisements that I have seen for NON-VMS workN > > where they state that experience on VMS is one of the prefered credential.' > > Very easy to find on any job board.t > >h	 > > -Johnn > > wb8tyw@qsl.network > >r > >a  : At my shop we can't seem to find good Unix people, we have> looked for years. I can't say the same for VMS.  I'm sure will@ respond that we must not offer enough $ but we do offer what the
 VMS guys get.q   -- t Keith Brownl kbrown780@usfamily.net   ------------------------------  % Date: Sun, 28 May 2000 23:52:35 -0400e' From: "Bill Todd" <billtodd@foo.mv.com> 5 Subject: Re: Compaq not as bad as Andrew says (wish?)e( Message-ID: <8gspck$pr3$1@pyrite.mv.net>  5 Keith Brown <kbrown780@usfamily.net> wrote in messager& news:3931BE9C.B78D355F@usfamily.net...   ...n   > Bill,s >a@ > If you use HSxx controllers on your systems whether it be Unix@ > or VMS (we use them on both at my shop) the file caching issue) > is mute because the controller does it.   K Hardware to the rescue!  But as always that's a relatively expensive way to,0 obtain performance when software can do the job.  J Not that it always can:  when you want guaranteed persistence coupled withF fast writes at high volume, stable write-back caching is the only realJ solution (as long as there are lulls during which you can dump the data toL disk).  But you need to double up on the controllers, each with stable writeJ cache, and have them communicate to avoid losing dirty data due to a cacheI failure (assuming you're using some kind of redundancy at the actual diskeI level to guard against single points of failure), and that gets expensiveIL compared to software alternatives that require no special hardware (save for? a sliver of NVRAM somewhere to make RAID recovery fast after an E interruption - which you actually only need if you can't tolerate thesD latency of writing a log record for each write request that can't be8 batch-logged with other contemporaneous write requests).  L Until hardware RAID (especially including copious amounts of stable cache inI a no-single-point-of-failure dual configuration) prices come *'way* down, F systems that ensure file system integrity while optionally trading offG up-to-the-second persistence for overall better performance will remain J popular for applications that demand no stronger guarantees.  This may notJ make a great deal of sense, given how completely the cost of operating andH managing systems dwarfs the cost of purchasing them, but up-front systemL price shows little indication of becoming irrelevant in typical environments in spite of this.o   - bill   >r > --
 > Keith Brownd > kbrown780@usfamily.net   ------------------------------  % Date: Mon, 29 May 2000 00:06:23 -0400x' From: "Bill Todd" <billtodd@foo.mv.com>d5 Subject: Re: Compaq not as bad as Andrew says (wish?)a( Message-ID: <8gsq6f$qpc$1@pyrite.mv.net>  5 Keith Brown <kbrown780@usfamily.net> wrote in messagei& news:3931BF74.790D37A2@usfamily.net...   ...r  < > At my shop we can't seem to find good Unix people, we have@ > looked for years. I can't say the same for VMS.  I'm sure willB > respond that we must not offer enough $ but we do offer what the > VMS guys get.D  J Interesting observation.  Without pretending that it constitutes more than; anecdotal evidence, one might guess at a couple of reasons.e  K 1)  Someone professing to be competent in VMS is more likely to be close to J the truth than someone professing to be competent in Unix (hell, virtuallyI *everyone* who's ever used any form of Unix more than truly superficially K likely thinks they can profess to competence, whereas a casual VMS user mayt< have a bit more respect for what 'competence' really means).  J 2)  Supply and demand dictate that the market for competence is hotter forK Unix people than for VMS people (by now, people who *want* to work with VMSsI may be getting happy to find *any* reasonable position - note the comment E elsewhere that turnover in one company's VMS staff is virtually nil).i   - bill   >h > --
 > Keith Browna > kbrown780@usfamily.net   ------------------------------  % Date: Mon, 29 May 2000 00:44:22 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>a5 Subject: Re: Compaq not as bad as Andrew says (wish?)i( Message-ID: <8gssdp$2fk$1@pyrite.mv.net>  2 John E. Malmberg <wb8tyw@qsl.net> wrote in message( news:sj3b2gen5pj40@corp.supernews.com...   ...R  K > Yes UNIX can give most (not all) applications good performance.  But whenuL > you understand why, it gives you a better perspective on when to recommend > each platform.  F Of course.  But for *most* applications, as you note, Unix provides anH environment that does not demand such understanding (or any particularlyK significant expertise) to get relatively good performance.  (See also David I Mathog's recent thread on 'RMS tuning versus file caching' for a specificnF example in addition to the compilation speed issue he raised earlier.)   ...   H > Most of the tuning parameters of OpenVMS are well documented.  SomeoneH > familiar with their application and computer systems can RTFM and find this > out.  - But in most cases on Unix they don't have to.M  G The point (which I overlooked in my initial comments about the relativebG availability of 'expertise', but which you brought up yourself) is thatlI developers with *minimal* expertise can create typical (disk-bound - thisfK discussion started as a file system issue) applications that perform betterhF on Unix than equivalent applications created by similarly-inexpert VMSH developers perform running on VMS, due to the difference in default file+ system approaches taken by the two systems.   I So the competition is this:  people who were exposed to Unix during their J schooling can create Unix applications that perform well without having toJ RTFM, whereas to create an application on VMS a developer *first* must getH at least minimally acquainted with the system (since s/he likely did notL encounter it in school) and *then* must RTFM - after first searching out theK right one(s) in the 5-foot shelf - if s/he wants the application to performd as well as it would on Unix.  7 Which system are developers likely to gravitate toward?r   >nL > I went to several UNIX experts to find out why all systems of a particularL > brand suddenly died one day.  They did not know.  I found out why by using aa > ethernet monitor.t >dL > It turned out that it was the equivalent of a non-page pool exhausted.  ItK > turned out a default configuration was causing it to download the routing H > tables from the corporate router.  I guess for "performance" it stored them > in the non-page pool.t > H > Yes, I talked to the vendor's support line.  For my efforts I got sentH > copies of two articles that had nothing to with the problem statement.  J The above is an interesting commentary, but seems completely irrelevant toL application development (which if you'll look back through the earlier postsI in this thread is the context of the discussion, especially as related toi2 obtaining good performance from the file systems).  F It is related to the question of 'expertise' (though in *system*-levelB issues), but I think you have convinced me that 'expertise' is notK particularly important to the application development discussion, except as-$ something that most developers lack.   >0J > I contend that true tuning expertise in other platforms is as rare as it isB > in VMS.  A higher market share for UNIX and M$SOFT attracts more pretenders.d  G Possibly.  *Application* tuning expertise is arguably less necessary toeD obtain a given level of performance in Unix environments than in VMSJ environments, so the rarer its existence is, the worse VMS looks (since it needs it more than Unix).c  H *System* tuning is a rather different animal, and my guess would be that@ real experts are extremely rare for virtually any system (thoughI self-professed Unix and NT experts may not be).  If (as per your example)rH Unix systems are *frequently* prone to handle unexpected situations lessH than gracefully, then this represents a real VMS strength (since lackingK such expertise VMS continues to run where Unix does not), just not one thata& is relevant to this particular thread.   - bill   > K > > And of course that last dovetails neatly with your own observation that F > > people seldom bother with much performance optimization:  for such typical E > > non-performance-optimized applications, Unix therefore makes moree > efficient K > > use of the hardware than VMS does, hence is correctly perceived as morel > > cost-effective.. > : > I do not know if that perception is always correct.  :-) >  > -JohnB > wb8tyw@qsl.network >m >h >    ------------------------------  # Date: Mon, 29 May 2000 06:39:19 GMTs* From: young_r@eisner.decus.org (Rob Young)5 Subject: Re: Compaq not as bad as Andrew says (wish?) + Message-ID: <9KXPQRWOgGLU@eisner.decus.org>f  Y In article <3931BF74.790D37A2@usfamily.net>, Keith Brown <kbrown780@usfamily.net> writes:S   > < > At my shop we can't seem to find good Unix people, we have@ > looked for years. I can't say the same for VMS.  I'm sure willB > respond that we must not offer enough $ but we do offer what the > VMS guys get.t >   ; 	VMS folks are hard to find but I also know Unix admins areh> 	very difficult to find also.  I know two contractors that areF 	in at a decent sized shop (multiple IBM RS/6000 S80s) and management E 	would prefer full-time sysadmins but can't find them.  A lot of thatt@ 	going around.  Want to flush admins out of the weeds regardless! 	of platform?  Contract for them.b  ? 	Could they get full-time sysadmins?  Sure.  Unfortunately, theo; 	salary that requires puts their sysadmins pay higher than e< 	management/directors.  That can't happen or you get unhappy@ 	directors/management, so the only way out of the catch-22 is to+ 	hire contractors and hide the cost in POs.d   				Roba   ------------------------------  % Date: Sun, 28 May 2000 16:50:47 -0400e. From: Stephen McElduff <smmsmm@mindspring.com>  Subject: DecServer 700 "boot up". Message-ID: <393186A7.F760037E@mindspring.com>  G I have recently upgraded a VAX from OpenVMS 6.1 to 7.2. We recently hadcF a power failure and now seem unable to have a DecServer 700 boot up. IH suspect this has something to do with the fact that I never gave the new< OS any knowledge of the existence of the t/s on the network.  C Does anyone know what needs to be setup on the VAX in order for the.H DecServer to be able to boot from it. Any resources I can access to find6 answers to this sort of thing, thank you very much....   ------------------------------  % Date: Sun, 28 May 2000 17:46:53 -0400m* From: David A Froble <davef@tsoft-inc.com>$ Subject: Re: DecServer 700 "boot up", Message-ID: <393193CD.68F5F12@tsoft-inc.com>   Stephen McElduff wrote:l > I > I have recently upgraded a VAX from OpenVMS 6.1 to 7.2. We recently had H > a power failure and now seem unable to have a DecServer 700 boot up. IJ > suspect this has something to do with the fact that I never gave the new> > OS any knowledge of the existence of the t/s on the network. > E > Does anyone know what needs to be setup on the VAX in order for thelJ > DecServer to be able to boot from it. Any resources I can access to find8 > answers to this sort of thing, thank you very much....  N It's been a while, so some of the things I mention may not be totally correct.  J First, I'm under the vague impression that the DECserver didn't have to beP registered in the DECnet database (and the DECserver database, if you would callN it that) in order for a software download to occur.  It is necessary for it toO be in the DECnet database in order to CONNECT to the virtual management port on  the DECserver.  C You should have the logical MOM$LOAD defined and pointing to eithernO SYS$SYSROOT:[DECSERVER] or SYS$SYSCOMMON:[DECSERVER].  Never did figure out whyhM I have some systems pointing to one, the other, or both. In any case, set yousM default to this location, and invoke the command procedure DSVCONFIG.  If the P DECserver is not in the list of registered servers, then add it, and finally, inK either case, re-load the DECserver data into the DECnet database.  I'm onlynK familiar with DECnet IV, and if you're running V, then all the above may be  wrong.  > After this, cycle the power on the DECserver,  it should work.   Dave   -- h4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596; 170 Grimplin Road               E-Mail: davef@tsoft-inc.com  Vanderbilt, PA  15486    ------------------------------  % Date: Mon, 29 May 2000 07:52:14 +0800e- From: David B Sneddon <dbsneddon@BIGPOND.COM> $ Subject: Re: DecServer 700 "boot up"+ Message-ID: <3931B12E.22A7E2D6@bigpond.com>8   David A Froble wrote:i >  > Stephen McElduff wrote:l > >nK > > I have recently upgraded a VAX from OpenVMS 6.1 to 7.2. We recently had J > > a power failure and now seem unable to have a DecServer 700 boot up. IL > > suspect this has something to do with the fact that I never gave the new@ > > OS any knowledge of the existence of the t/s on the network.   What flavour DECnet?@ If DECnet-Classic, is "service enabled" on the ethernet circuit?  + $ mcr ncp set circuit isa-0 service enablede ! use your circuit ID ^^^^^e  2 For DECnet-Plus, use NET$CONFIGURE and enable MOP.   > >aG > > Does anyone know what needs to be setup on the VAX in order for the L > > DecServer to be able to boot from it. Any resources I can access to find: > > answers to this sort of thing, thank you very much.... > P > It's been a while, so some of the things I mention may not be totally correct. > L > First, I'm under the vague impression that the DECserver didn't have to beR > registered in the DECnet database (and the DECserver database, if you would callP > it that) in order for a software download to occur.  It is necessary for it toQ > be in the DECnet database in order to CONNECT to the virtual management port onc > the DECserver.  > $ mcr ncp connect via isa-0 physical address xx-xx-xx-xx-xx-xx ! use your circuit ID ^^^^^r? (I think, I don't have any DECnet-Classic systems any more :-()   9 $ set host/mop/circuit=csmacd-0/address=xx-xx-xx-xx-xx-xx6   > E > You should have the logical MOM$LOAD defined and pointing to eithereQ > SYS$SYSROOT:[DECSERVER] or SYS$SYSCOMMON:[DECSERVER].  Never did figure out why O > I have some systems pointing to one, the other, or both. In any case, set youmO > default to this location, and invoke the command procedure DSVCONFIG.  If theoR > DECserver is not in the list of registered servers, then add it, and finally, inM > either case, re-load the DECserver data into the DECnet database.  I'm onlytM > familiar with DECnet IV, and if you're running V, then all the above may bel > wrong.  G Make sure the load file is in the MOM$LOAD area with W=RE access so the  MOP process can read it. > @ > After this, cycle the power on the DECserver,  it should work. >  > Dave >  > --6 > David Froble                       Tel: 724-529-04506 > Dave Froble Enterprises, Inc.      Fax: 724-529-0596= > 170 Grimplin Road               E-Mail: davef@tsoft-inc.coma > Vanderbilt, PA  15486      --   Regards, Dave.eI -------------------------------------------------------------------------cI David B Sneddon (dbs)  OpenVMS Systems Programmer   dbsneddon@bigpond.com I DBS software at ...   http://www.users.bigpond.com/dbsneddon/software.htmsI "Life is what happens to you while you're busy making other plans" Lennona   ------------------------------  # Date: Sun, 28 May 2000 19:03:14 GMT  From: M.Morsbach@gmx.dee Subject: error tcpip pop servern) Message-ID: <8grqhc$26l$1@nnrp1.deja.com>p   Hello ,g  0 i got the following error message several times:  4 "From: AXPS01::TCPIP$POP     26-MAY-2000 14:34:24.86
 To: SYSTEM CC:e> Subj: AXPS01 - %SYSTEM-F-PRIVINSTALL, shareable images must be installed to run privileged image  A The TCPIP POP server has experienced a runtime error.  The reason @ for the error should appear on the subject line of this message.  7 Please investigate this problem as quickly as possible.a Thank you."a  " Any idea on how to fix this error?B We use OVMS 7.1 and TCPIP. Nothing changed in the configuration orE installation of this computer. Sorry for the question if it is a verye8 simple thing, but my knowledge about VMS is not so good.   Thanks for your help!b   Matthias      & Sent via Deja.com http://www.deja.com/ Before you buy.w   ------------------------------  % Date: Mon, 29 May 2000 12:57:57 +1000a/ From: "Phil Howell" <howellp@snowyhydro.com.au>w# Subject: Re: error tcpip pop serverf1 Message-ID: <X0lY4.3892$N4.133365@ozemail.com.au>    type INSTALL INSTALL> LIST /FULL-  ' along with other things you should find0   TCPIP$POP_SERVER;1#                                 Prv &       Entry access count         = nnn        Privileges = SYSPRV BYPASS  + have a look in your tcpip startup procedure0+ maybe it was run without the required privs9 Phil      H <M.Morsbach@gmx.de> wrote in message news:8grqhc$26l$1@nnrp1.deja.com...	 > Hello ,  >t2 > i got the following error message several times: >p6 > "From: AXPS01::TCPIP$POP     26-MAY-2000 14:34:24.86 > To: SYSTEM > CC:a@ > Subj: AXPS01 - %SYSTEM-F-PRIVINSTALL, shareable images must be > installed to > run privileged image >dC > The TCPIP POP server has experienced a runtime error.  The reasonsB > for the error should appear on the subject line of this message. >n9 > Please investigate this problem as quickly as possible.r
 > Thank you."a >u$ > Any idea on how to fix this error?D > We use OVMS 7.1 and TCPIP. Nothing changed in the configuration orG > installation of this computer. Sorry for the question if it is a verys: > simple thing, but my knowledge about VMS is not so good. >  > Thanks for your help!n > 
 > Matthias >r >  > ( > Sent via Deja.com http://www.deja.com/ > Before you buy.r   ------------------------------  % Date: Mon, 29 May 2000 11:03:20 +1000A/ From: "Phil Howell" <howellp@snowyhydro.com.au>y, Subject: Re: none urgent cobol exit question1 Message-ID: <vljY4.3838$N4.131424@ozemail.com.au>r   One way to do this isc2        01  ZWRK-STATUS             PIC S9(9) COMP.    IF  ZWRK-STATUS IS FAILUREa>                    CALL "LIB$STOP" USING BY VALUE ZWRK-STATUS.  I This bit below is cut from the vms 7.2 doc but probably hasn't changed ins the last decade. Phil   LIB$STOP  K The Stop Execution and Signal the Condition routine generates a signal that C indicates that an exception condition has occurred in your program.tL Exception conditions signaled by LIB$STOP cannot be continued from the point of the signal.  L ---------------------------------------------------------------------------- ----   FormatB LIB$STOP condition-value [,number-of-arguments] [,FAO-argument...]  L ---------------------------------------------------------------------------- ----   RETURNS-J LIB$STOP generates a signal and stops execution of the calling program. No condition values are returned.    L ---------------------------------------------------------------------------- ----  	 Argumentsr condition-valuee   OpenVMS usage:  cond_value type:  longword (unsigned) access:  read only mechanism: by valuet  K OpenVMS 32-bit condition value. The condition-value argument is an unsignedV, longword that contains this condition value.J The OpenVMS Programming Concepts Manual explains the format of a condition value.    : Terry Marosites <TMarosites@unitedad.com> wrote in messageG news:1137A4A23A51D311B2D600105A1D5213019AEE45@seantexch.unitedad.com...i > Hello All,A > Hope everyone in the states is going to a long (great) weekend.p >eH > I remember back when I (at least I think I do) when I was able to do a "ExitrK > 4"  in a Cobol program and this with translate into the $status (shown aso atL > fatal error) so that after the run I could do a stat=$status and work with0 > the knowledge of how the Cobol program exited. > I > The Cobol that I am using and all documentation that I have on had saysl the  > exit can't have the 4  >kI > Terry stumped on how to pass a status to DCL. I know I can set a symbolh andmC > do it that way but I thought there was a simpler/ standard method  >) > 7 > *****************************************************y >t > 7 > *****************************************************06 > Any views or opinions are solely those of the author+ > and do not necessarily represent those ofy > United News& Media. 7 > *****************************************************q6 > The information transmitted is intended only for the3 > person or entity to which it is addressed and mayl5 > contain confidential and/or privileged material. Ife5 > you are not the intended recipient of this message,o0 > please do not read, copy, use or disclose this5 > communication and notify the sender immediately. Itn2 > should be noted that any review, retransmission,4 > dissemination or other use of, or taking action in/ > reliance upon, this information by persons org/ > entities other than the intended recipient isn
 > prohibited.i7 > *****************************************************  > ** >r   ------------------------------  % Date: Sun, 28 May 2000 17:35:28 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca>o/ Subject: RMS handling of extremely long records , Message-ID: <3931911C.17E43B07@videotron.ca>  M Every now and then, I read complaints about a file that can't be read becausevC of a record that is too long. (usually , some binary data stored ass5 "stream-lf" but doesn't contain new-line indicators).t  R I used to experience this often, but on 7.2, I didn't quite see this when I tried.  @ Has RMS been changed lately to handle such very long "records" ?  M If not, (perhaps the files I have tested this with were all properly formed),i  I have the following suggestion:  L RMS should have an option to treat records longer than it is able to processN in a single operation as multiple records, with an indication that a record is
 not complete.n  L If the C RTL used such option, it would enable it to provide the caller withI chunks of data within the limits of the user's buffer and quotas.  And by N getting a "record end not found" status code (instead of RTB), the C RTL wouldI know not to add the "newline" at the end of the record. As such, the data L received by the application would not be modified and this would enable muchN of the UNIX software that doesn't knwo about RMS to read binary files that are stored as text files on VMS.   ------------------------------  % Date: Mon, 29 May 2000 12:48:08 +1000n/ From: "Phil Howell" <howellp@snowyhydro.com.au> + Subject: Re: RMS tuning versus file caching 1 Message-ID: <MTkY4.3886$N4.133417@ozemail.com.au>   B While gene sequencing is obviously very different to the accounts,H maintenance management, stores, water modelling, and other miscellaneousE databases that we use, configuring your application "just in case vmsi) crashes" may end up being self-defeating. . Are your run times in weeks, months, or years?# How often do your vms systems fail?y Do you wear a belt and braces?& Do you need a new vms systems manager?
 <end of rant>p  9 One place to look is in the RMS doc under Connect servicea. there is a table of record processing options.K Even if you don't want to use rms calls in your programs, these give a goodh/ summary of what performance tuning can be done. H Some parameters can be implemented by either RMS defaults or by defining< them in the relevant FDL, so no coding changes are required.   Look at: SYS$CONNECT , Table RMS-3 Connect Service RAB Input Fields Table 4-1 FAB Fields  1 While we are on the subject, the table RMS-3 saysnL RAB$V_WBH 2  Write behind: allocates at least two buffers for multibuffering3 (applies only to sequential files on disk devices).vI I'm sure that in the past I've used this on indexed files that were beingrK written sequentially (ie. in primary key sequence). Does anyone know if thec doco is wrong or my memory?e   Phil    = David Mathog <mathog@seqaxp.bio.caltech.edu> wrote in messager& news:8gmo3k$nq8@gap.cco.caltech.edu...K > We've gone over the RMS vs. file caching stuff quite a bit, but there arexJ > a couple of things that are still unclear to me.  The default RMS counts on > my system are: >e > $ sho rmsVG >           MULTI-  |                MULTIBUFFER COUNTS               |x NETWORK)G >           BLOCK   | Indexed  Relative            Sequential         |  BLOCK G >           COUNT   |                     Disk   Magtape  Unit Record |  COUNTpL > Process     0     |    0         0        0       0         0       |    0L > System     16     |    0         0        0       0         0       |    8 > 2 >           Prolog    Extend Quantity      VCC_DFW/ > Process     0              0                0 / > System      0              0                0r >tK > And this results in, as far as I can tell, each file write going straight-# > to disk.  If the process issues a0 >9 > $ set rms/buffer=100 >nJ > that will increase write performance (it doesn't seem to do anything forH > read though).  But any use of buffers decreases data integrity, right? > So is this correct?, >i7 > 1. If the system crashes before the buffer is written  >    then the data vaporizes.  >x; > 2. Once buffering is enabled the last buffer of data onlyr> >    goes to disk once the program closes the file (explicitly >    or on exit.)t >eK > That's not quite so insecure as WNT or Unix style file caching (where themK > data may not get written to disk even on process exit), but its certainly I > enough to hose software which depends on state data written to files onpK > disk. It also means that in terms of data integrity there's not much data.J > integrity advantage for RMS using buffers with a program written naivelyL > (ie, not written to force flushes through the cache at key regions) versusK > running the same thing on Unix and following each program with a "synch".i >tH > While VMS doesn't do file caching, there is "SET FILE/GLOBAL" which isH > supposed to let multiple processes share buffers for one file.  (I sayI > "near as I can tell" because I have not yet found a program where I can0 run:K > two copies and see a difference with this on versus off.)  I couldn't seev a7J > way to force it to leave those buffers around between runs, but maybe itL > would if a dummy program was running that did nothing but leave the accessJ > "open"???  I'm thinking about a case where a large file is read over andE > over again by different programs, and I'd like to avoid the disk IOoF > associated with that.  For a moment I thought that the engineers hadH > actually put in a way to do this, but SET FILE/CACHING only applies toK > Spiralog volumes, and Spiralog was (last time I heard) not a product thata > is safe to use.. > L > Anyway, by futzing around with the RMS parameters I have been able to makeK > at least one program (TFASTA3, which scans a protein sequentially against @ > a 9 Mb DNA database file) run as fast on OpenVMS as it does on Linux/Alpha.F > If I don't change the RMS parameters it runs exactly half as fast onF > OpenVMS.  That sort of fine tuning shows that equivalent performanceI > usually be had, but I sure wish there was a global knob I could turn tonG > make that the default, rather than having to muck around on a file by  file,y > process by process basis.u >n
 > Regards, >e > David Mathog > mathog@seqaxp.bio.caltech.edut@ > Manager, sequence analysis facility, biology division, CaltechL > **************************************************************************L > *                                RIP VMS                                 *L > **************************************************************************   ------------------------------  % Date: Mon, 29 May 2000 10:48:04 +1200l6 From: "Antony Wardle" <antony.wardle@nospam.met.co.nz> Subject: Setting passwordN1 Message-ID: <njhY4.3748$N4.128464@ozemail.com.au>e   Hi.o  I Has anyone invented a way to set your password, linux password, and/or ntO< password with a niffy little command procedure (or similer)?   Or any way arounmd?y   Antony   ------------------------------  % Date: Sun, 28 May 2000 19:08:03 -0400a, From: Howard S Shubs <hshubs@mindspring.com> Subject: Re: Setting passwordi> Message-ID: <hshubs-A1D663.19080328052000@news.mindspring.com>  B In article <njhY4.3748$N4.128464@ozemail.com.au>, "Antony Wardle" ' <antony.wardle@nospam.met.co.nz> wrote:o  J >Has anyone invented a way to set your password, linux password, and/or nt= >password with a niffy little command procedure (or similer)?r   What's wrong with SET PASSWORD?-   -- 0 Howard S Shubs, the Denim Adept    ------------------------------  % Date: Mon, 29 May 2000 11:55:25 +1200n6 From: "Antony Wardle" <antony.wardle@nospam.met.co.nz> Subject: Re: Setting password01 Message-ID: <wiiY4.3790$N4.129712@ozemail.com.au>n  B Well, that is hardly going to change my linux password now, is it?  " Maybe I haven't been clear enough.  C Is there a utility/easy way of setting my password for NT,VMS,LinuxnD all in one easy go. I can already change my vms password in multipleH nodes/clusters in one little command procedure, I just wanted to know if' anyone had already invented this wheel.a   Antony      9 "Howard S Shubs" <hshubs@mindspring.com> wrote in messaget8 news:hshubs-A1D663.19080328052000@news.mindspring.com...C > In article <njhY4.3748$N4.128464@ozemail.com.au>, "Antony Wardle"i) > <antony.wardle@nospam.met.co.nz> wrote:r >tL > >Has anyone invented a way to set your password, linux password, and/or nt? > >password with a niffy little command procedure (or similer)?h > ! > What's wrong with SET PASSWORD?o >t > --! > Howard S Shubs, the Denim Adept    ------------------------------  # Date: Mon, 29 May 2000 01:30:04 GMT / From: "John Nixon" <jorlnixon@worldnet.att.net>  Subject: Re: Setting passwordIF Message-ID: <wKjY4.9695$793.612595@bgtnsc05-news.ops.worldnet.att.net>  I To be honest, you did NOT make yourself clear.  You asked how to set yourl passwordL on Linux or NT, but you were on a VMS newsgroup.  What did you expect if not
 a VMS answer.d  I However, now that you cleared it up a little, maybe somebody will have ane answer for you.  
 good luck.  A "Antony Wardle" <antony.wardle@nospam.met.co.nz> wrote in messageI+ news:wiiY4.3790$N4.129712@ozemail.com.au...mD > Well, that is hardly going to change my linux password now, is it? >x$ > Maybe I haven't been clear enough. > E > Is there a utility/easy way of setting my password for NT,VMS,LinuxSF > all in one easy go. I can already change my vms password in multipleJ > nodes/clusters in one little command procedure, I just wanted to know if) > anyone had already invented this wheel.e >e > Antony >I >h > ; > "Howard S Shubs" <hshubs@mindspring.com> wrote in messaged: > news:hshubs-A1D663.19080328052000@news.mindspring.com...E > > In article <njhY4.3748$N4.128464@ozemail.com.au>, "Antony Wardle"d+ > > <antony.wardle@nospam.met.co.nz> wrote:b > > K > > >Has anyone invented a way to set your password, linux password, and/or  ntA > > >password with a niffy little command procedure (or similer)?e > >e# > > What's wrong with SET PASSWORD?  > >- > > --# > > Howard S Shubs, the Denim Adept2 >2 >4   ------------------------------  % Date: Mon, 29 May 2000 01:53:36 -0400R, From: Howard S Shubs <hshubs@mindspring.com> Subject: Re: Setting password > Message-ID: <hshubs-CF8F43.01533629052000@news.mindspring.com>  B In article <wiiY4.3790$N4.129712@ozemail.com.au>, "Antony Wardle" ' <antony.wardle@nospam.met.co.nz> wrote:   # >Maybe I haven't been clear enough.b   Maybe you haven't!  <grin>    D >Is there a utility/easy way of setting my password for NT,VMS,LinuxE >all in one easy go. I can already change my vms password in multiple3I >nodes/clusters in one little command procedure, I just wanted to know ifg( >anyone had already invented this wheel.   Damnifeyeno.   -- l Howard S Shubs, the Denim Adept:   ------------------------------    Date: 28 May 2000 16:14:33 -0500/ From: jlauret@?.chem.sunysb.edu (Jerome LAURET)a2 Subject: Software update at nucwww.chem.sunysb.edu. Message-ID: <39317e29_1@dilbert.ic.sunysb.edu>    Software updated from o@  http://nucwww.chem.sunysb.edu/htbin/software_list.cgi?sort=dateE  (date in parenthesis, if any, shows our site-release after testing).        New or added  A  MOST 4.9.0 : Most is a text file pager written by John E. Davis.o 	(26-May-2000).n  :  SLANG-1_4_1 : This library provides facilities for screen; 	management, keymaps, low-level terminal I/O, etc ... I hadoB 	to twick things a bit to make the library with module inserted in: 	the correct order (link would fail if you use the defaultE 	distribution). The author has been made aware of this small problem.l) 	Written by John E. Davis. (26-May-2000).:  C  TOUCH : A Unix-like touch utility for VMS written in DCL and using.) 	Joe Meadows FILE utility. (26-May-2000).   @  FILE : I have added Joe Meadow's FILE utility because I tend to? 	beleive that this package should be a standard utility. It is  F 	available since 1993 on the WKU server ... but tones of people still C 	ask questions in comp.os.vms which can be asnwered by ... FILE !!!l> 	(like : how to emulate TOUCH, so trivial when you have FILE).  A  NEDIT 5.1-1 : Latest Nedit editor version. Tested on OpenVMS 7.2  	Alpha only (01-May-2000).  I  LYNX 2.8.3 : This distribution includes the Multinet patch described in  C 	version 2.8.2 + I have compiled and linked it with Slang in order  H 	to have color supports (library included in distribution for OpenVMS7.2C 	Alpha). Use either -color to have the color enabled or define the eE 	logical COLORTERM on your system to have Lynx use color at startup. kE 	One more detail : OpenSSL support in makefiles dropped (I worked on o9 	it in 2.8.2 but never got in the current distribution). f/ 	I'll try to support it at the next release ...r* 	02-May-2000 Patch : CTRL/C problem fixed.   Updatedu  A  DCC-V2_5Q : Please, see the DCCBoard for the list of changes andnC 	history. (26-May-2000). URL Link you WANT to visit (yes you do !!)/- 	http://nucwww.chem.sunysb.edu/info/dcc.htmlx- 	and5 	http://nucwww.chem.sunysb.edu/dccboard/wwwboard.html ? 	We welcome your comments, complaints, suggestions, bug reportsb 	etc ...  B  VPIPE : Verbatim Pipe for pre-7.1 VMS version. Adds a second modeE 	for SPLIT i.e. can now split a resulting line by a given character. I8 	This mode is VERY different from the default mode which@ 	splits the records according to f$parse() fields. (23-APR-2000)   Retiredc    DCC-V2_5H	a
  DCC-V2_5I
  DCC-V2_5J
  DCC-V2_5K
  DCC-V2_5M     -- h6                   Jerome LAURET S.U.N.Y. @ Stony Brook$        ,,,,,      Dept. of Chemistry+       ( o o )     Stony Brook NY 11794-3400r;   ---m---U---m---------------------------------------------t&   E-mail: jlauret@mail.chem.sunysb.edu<   URL   : http://nucwww.chem.sunysb.edu/jlauret/jlauret.html   ------------------------------  % Date: Mon, 29 May 2000 09:50:25 +0530n0 From: Siva Kumar B <sivakumar.b@cybertech.co.in> Subject: UNSUB INFO-VAX-@ Message-ID: <A1A92C702186D311A75500600868566E354457@CSBMEX0121B>   UNSUB INFO-VAX   ------------------------------  # Date: Sun, 28 May 2000 21:23:57 GMT ) From: "Neil Rieck" <n.rieck@sympatico.ca>-6 Subject: Re: VAX VMS 7.2 Bug? ; backup/image/(no)alias8 Message-ID: <N7gY4.4541$WV.236958@news20.bellglobal.com>  4 John Nebel <nebel@ATHENA.CSDCO.COM> wrote in message@ news:Pine.OSF.4.21.0005280719020.2752-100000@athena.csdco.com... >n > Tim, >  > The VMS 7.2 manual says: >dG > "Specifying the /IMAGE qualifier without also specifying /NOALIAS can F > result in incomplete disk or file restoration operations. Therefore,G > Compaq strongly recommends that you specify /NOALIAS with /IMAGE whenn+ > performing image mode backup operations."  >t > John Nebel >g  J 1. At this point I'm not saying that the VMS 7.2 manual is wrong, but more@ files do get copied over when I use /ALIAS rather than /NOALIAS.  I 2. Also, using either switch with /IMAGE results in a warning that statesaF that alias VMS$COMMON.DIR was not copied. However, running DFU 2.7 andB executing a "DIR/ALIAS dsa0:[000000...]" command produces a result8 indicating that DSA0:[SYS0]SYSCOMMON.DIR is an alias forH DSA0:[000000]VMS$COMMON.DIR. It's almost as if s/w drops both the "alias$ file name" and the "real file name".  F I guess it's time to take down the system (ugg) and try a BACKUP after booting the VMS CD-ROM.*  
 Neil Rieck* Kitchener(New Berlin?)/Waterloo/Cambridge, Ontario, Canada.! http://www3.sympatico.ca/n.rieck/i   ------------------------------    Date: 28 May 2000 15:25:47 -0500/ From: jlauret@?.chem.sunysb.edu (Jerome LAURET)* Subject: Re: Vms calculator*. Message-ID: <393172bb_3@dilbert.ic.sunysb.edu>  D 	I have a copy of the ICALC program (version on my site is slightly . extended comparing to original one). Check out 	r6 	http://nucwww.chem.sunysb.edu/htbin/software_list.cgi   	and look for ICALC or go to  D 	http://nucwww.chem.sunysb.edu/htbin/software_list.cgi?package=icalc  3 	This version includes more trigonometric functionsiL and 2 random number generators as well as the hability of having the resultsQ of the operation(s) in the symbol ICALC_OUT (idea from D.M.) separated by commas. M This allows you to actually recover the calculation values from a DCL script.    	Enjoy,-       -- -6                   Jerome LAURET S.U.N.Y. @ Stony Brook$        ,,,,,      Dept. of Chemistry+       ( o o )     Stony Brook NY 11794-3400l;   ---m---U---m--------------------------------------------- &   E-mail: jlauret@mail.chem.sunysb.edu<   URL   : http://nucwww.chem.sunysb.edu/jlauret/jlauret.html   ------------------------------  % Date: Sun, 28 May 2000 14:43:56 -0400t- From: JF Mezei <jfmezei.spamnot@videotron.ca>n  Subject: Re: VMS on the desktop?, Message-ID: <393168EC.64CC45D0@videotron.ca>   Howard S Shubs wrote: , > >2 alarms per day (lunch and go home time) > >cut and paste+ > >calculator (IIRC with cut and paste too)  > >multiple sessions  K I I understand the advantage of a VT terminal on the shop floor or for data M entry clerks, for system management and programming, I am sorry to say that aaK VMS workstation with Decwindows can't be beaten, especially with a nice bigiL huge screen where you can fit 2 "VT terminals" with each 50 or so lines, andI scroll back etc etc.  Cut and paste is much better than on a VT terminal.n   ------------------------------  % Date: Sun, 28 May 2000 14:43:57 -0500 ) From: "John E. Malmberg" <wb8tyw@qsl.net>   Subject: Re: VMS on the desktop?7 Message-ID: <065101bfc8dd$118bde90$020a0a0a@xile.realm>   . JF Mezei <jfmezei.spamnot@videotron.ca> wrote: <snip>( > for system management and programming,: > I am sorry to say that a VMS workstation with Decwindows9 > can't be beaten, especially with a nice big huge screenR> > where you can fit 2 "VT terminals" with each 50 or so lines,8 > and scroll back etc etc.  Cut and paste is much better > than on a VT terminal.  G I would agree that a VMS workstation is superior for this, but I am notl sorry to say that :-)w   -Johnn wb8tyw@qsl.network   ------------------------------  % Date: Sun, 28 May 2000 21:35:35 +0100o. From: mpatt644 <mpatt644@netscapeonline.co.uk> Subject: War Stories ?4 Message-ID: <39318317.5538BFC9@netscapeonline.co.uk>   Hi All,t@ 	When I worked for DEC (yes before it was Q'd) there was a NotesE conference (similar system to Usenet) called War Stories, which was a.F repository for old anecdotes and stupid mistakes that have happened inG the computing world over the years. Does anyone know if there's anthing # similar available on the Internet ?u   ------------------------------  # Date: Mon, 29 May 2000 05:10:42 GMTq9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)c Subject: Re: War Stories ?+ Message-ID: <TjRU4B0vKwwE@eisner.decus.org>t  e In article <39318317.5538BFC9@netscapeonline.co.uk>, mpatt644 <mpatt644@netscapeonline.co.uk> writes:i  B > 	When I worked for DEC (yes before it was Q'd) there was a NotesG > conference (similar system to Usenet) called War Stories, which was ayH > repository for old anecdotes and stupid mistakes that have happened inI > the computing world over the years. Does anyone know if there's anthinge% > similar available on the Internet ?a  D DECUServe has some topics based on personal experience in that area,/ but it is not intended as a comprehensive list.    ------------------------------  % Date: Sun, 28 May 2000 20:09:16 -0500 * From: Keith Brown <kbrown780@usfamily.net>/ Subject: Re: [humor] UNIX/OpenVMS email "virus" , Message-ID: <3931C33C.B2792F10@usfamily.net>  
 nic wrote: >  > Lonnie Carreau wrote:  > >OQ > > If only me and my wife could share VMS as a couple :-).  Looks like you found  > > yourself a gem.  > >  > B > Well my missus is not enamered (sp?) with my VMS systems, but myI > one year old daughter Molly, with toys that beep, flash, wiggle, wobblea? > and talk prefers a keyboard attached to a VMS system any day!  > I > (And before you ask, yes there is a PC next to it, but it's the VMS box, > every time. That's ma girl!) >  > --! > Nic Clews CSC Computer Scienceso3 > email : n c l e w s   a t   c s c   d o t   c o mt  < Funny how kids seem to know something good when they see it! --   Keith Brown) kbrown780@usfamily.net   ------------------------------   End of INFO-VAX 2000.298 ************************ before the buffer is written  >    then the data vaporizes.  >x; > 2. Once buffering is enabled the last buffer of data onlyr> >    goes to disk once the program closes the file (explicitly >    or on exit.)t >eK > That's not quite so insecure as WNT or Unix style file caching (where themK > data may not get written to disk even on process exit), but its certainly I > enough to hose software which depends on state data written to files onpK > di?[̗VcXQxzUD=oq`j&baX%yy8kӜɕ+kރ󼰭6,>-P{vu'7Į4DKmq`]{\l>
&[#E36\-[0:ޘv!ϤkU8`5YC )iaby$#?KBxA&Ywew쥘W9"ò~6:@O"!+_.]sHV&a
Q
l?N4)3Hk͐\NqSao1Oمfc$Fw(g)Bb1_[tfAIQQn<jH2
?J:X.R!	&@5 mdAY2kj
6ע!Xh&kLvIĠy	w