1 INFO-VAX	Thu, 11 Aug 2005	Volume 2005 : Issue 446       Contents:* Re: $SHOW DEVICE/FILES enhancement request* Re: $SHOW DEVICE/FILES enhancement request* Re: $SHOW DEVICE/FILES enhancement request* Re: $SHOW DEVICE/FILES enhancement request* Re: $SHOW DEVICE/FILES enhancement request* Re: $SHOW DEVICE/FILES enhancement request* Re: $SHOW DEVICE/FILES enhancement request* Re: $SHOW DEVICE/FILES enhancement request. Re: 7.3-2 Crashes when a Samba Client connects? Re: anyone using the WeatherDuck?  Other environmental monitor?  Re: Decus UUCP Re: Decus UUCP% Re: Help Needed: Tape Backup Save Set % Re: Help Needed: Tape Backup Save Set % Re: Help Needed: Tape Backup Save Set % Re: Help Needed: Tape Backup Save Set % Re: Help Needed: Tape Backup Save Set % Re: Help Needed: Tape Backup Save Set % Re: Help Needed: Tape Backup Save Set % Re: Help Needed: Tape Backup Save Set % Re: Help Needed: Tape Backup Save Set % Re: Help Needed: Tape Backup Save Set % Re: Help Needed: Tape Backup Save Set % Re: Help Needed: Tape Backup Save Set % Re: Help Needed: Tape Backup Save Set < Killing a process that has allocated the tape drive - cont'd: Re: Mark Hurd to be keynote speaker at HP Technology Forum: Re: Mark Hurd to be keynote speaker at HP Technology Forum: Re: Mark Hurd to be keynote speaker at HP Technology Forum Moving System Disk Problem deleting memory  Re: Problem deleting memory $ Problem printing binary image files.( Re: Problem printing binary image files. Re: Storage shelf questions  Re: [OT] Zip 2.3-1)   F ----------------------------------------------------------------------    Date: 11 Aug 2005 03:37:34 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) 3 Subject: Re: $SHOW DEVICE/FILES enhancement request 3 Message-ID: <LSEjQNcEDdJF@eisner.encompasserve.org>   [ In article <BF1FF07F.121CC%roktsci@comcast.net>, Jeff Cameron <roktsci@comcast.net> writes: J > I have an enhancement request for the SHOW DEVICE/FILES command. I wouldM > like to see the addition of the following two exclusive qualifiers, for use  > in a Cluster environment:  > 1 > $SHOW DEVICE/FILES/NODE=(nodelist)  device-name  >  > -and-  > ( > $SHOW DEVICE/FILES/CLUSTER device-name > J > The purpose should be obvious, being the ability to show files open on a' > volume from other nodes in a cluster.   B One can fake that with SYSMAN, but changing SHOW DEVICE to have itA embedded would potentially be shoving a very large amount of data = across the IPC mechanism.  Isn't there an interaction between A kernel mode and communications needs at that point ?  I was under = the impression that a lot of data structures had to be locked  during SHOW DEVICE/FILES.    ------------------------------    Date: 11 Aug 2005 03:39:45 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) 3 Subject: Re: $SHOW DEVICE/FILES enhancement request 3 Message-ID: <nKYCCUaCwoAs@eisner.encompasserve.org>   [ In article <BF20165C.121F7%roktsci@comcast.net>, Jeff Cameron <roktsci@comcast.net> writes:   I > Does anyone have a program that will display the open I/O channels of a E > process given a process id. I know how to do it via SYSMAN via SHOW : > PROC/CHAN, but again, I would like a more simple method.  @ ANALYZE/SYSTEM will do that, and I doubt that anything can do it? in fewer instructions.  If it is just the command structure you @ want to simplify, I would recommend a DCL command procedure that runs ANALYZE/SYSTEM.   ------------------------------  + Date: Thu, 11 Aug 2005 08:57:40 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)3 Subject: Re: $SHOW DEVICE/FILES enhancement request $ Message-ID: <ddf3u3$v2h$1@online.de>  = In article <BF20165C.121F7%roktsci@comcast.net>, Jeff Cameron  <roktsci@comcast.net> writes:   H > Sysman is the way I do it now, just as you have suggested, but I would > prefer just the one command.  H Right.  Of course, many commands have the /CLUSTER or /NODE qualifier.  H One could also say "use SYSMAN" in these cases, but obviously there are % times when the qualifiers are better.    ------------------------------  % Date: Thu, 11 Aug 2005 13:04:37 +0300 4 From: Mike Rechtman <michael.rechtman.nospam@hp.com>3 Subject: Re: $SHOW DEVICE/FILES enhancement request & Message-ID: <42FB4CE5.10363E3F@hp.com>   Jeff Cameron wrote:  > J > On 8/10/05 6:09 PM, in article 69qdnSEftv-gOGffRVn-pQ@comcast.com, "Brad5 > Hamilton" <brMadAhamPiltSon@coMmcaAstP.neSt> wrote:  >  > > Jeff Cameron wrote: M > >> I have an enhancement request for the SHOW DEVICE/FILES command. I would  ... I > Does anyone have a program that will display the open I/O channels of a E > process given a process id. I know how to do it via SYSMAN via SHOW : > PROC/CHAN, but again, I would like a more simple method.  1 There used to be CHNLST.MAR by (IIRC) Arne Vajhj ? Works for me (on a VAX 6.2, maybe you need an updated version.)    Mike   --  E --------------------------------------------------------------------- E Usual disclaimer: All opinions are mine alone, perhaps not even that. ? Mike Rechtman                            *rechtman@tzora.co.il* F Kibbutz Tzor'a.                          Voice (home): 972-2-9908337  B   "20% of a job takes 80% of the time, the rest takes another 80%"E ---------------------------------------------------------------------  -----BEGIN GEEK CODE BLOCK-----  Version: 3.1: GCM/CS d(-)pu s:+>:- a++ C++ U-- L-- W++ N++ K? w--- V+++$6 PS+ PE-- t 5? X- tv-- b+ DI+ D-- G e++ h--- r+++ y+++@ ------END GEEK CODE BLOCK------    ------------------------------  % Date: Thu, 11 Aug 2005 05:25:54 -0700 ( From: Jeff Cameron <roktsci@comcast.net>3 Subject: Re: $SHOW DEVICE/FILES enhancement request 0 Message-ID: <BF2091E2.12239%roktsci@comcast.net>  L On 8/11/05 1:39 AM, in article nKYCCUaCwoAs@eisner.encompasserve.org, "Larry) Kilgallen" <Kilgallen@SpamCop.net> wrote:   ? > In article <BF20165C.121F7%roktsci@comcast.net>, Jeff Cameron  > <roktsci@comcast.net> writes:  > J >> Does anyone have a program that will display the open I/O channels of aF >> process given a process id. I know how to do it via SYSMAN via SHOW; >> PROC/CHAN, but again, I would like a more simple method.  > B > ANALYZE/SYSTEM will do that, and I doubt that anything can do itA > in fewer instructions.  If it is just the command structure you B > want to simplify, I would recommend a DCL command procedure that > runs ANALYZE/SYSTEM.  K I appologize. I meant to say ANAL/SYSTEM and not SYSMAN. It is the way I do  it now.    ------------------------------  % Date: Thu, 11 Aug 2005 09:30:59 -0400  From: norm.raphael@metso.com3 Subject: Re: $SHOW DEVICE/FILES enhancement request Q Message-ID: <OFF6C79F0E.B8014438-ON8525705A.0049D1EB-8525705A.004A3FF2@metso.com>   I David J Dachtera <djesys.nospam@comcast.net> wrote on 08/10/2005 10:20:43  PM:    > Brad Hamilton wrote: > >  > > Jeff Cameron wrote: H > > > I have an enhancement request for the SHOW DEVICE/FILES command. I would = > > > like to see the addition of the following two exclusive  > qualifiers, for use  > > > in a Cluster environment:  > > > 5 > > > $SHOW DEVICE/FILES/NODE=(nodelist)  device-name  > > >  > > > -and-  > > > , > > > $SHOW DEVICE/FILES/CLUSTER device-name > > > I > > > The purpose should be obvious, being the ability to show files open  on a+ > > > volume from other nodes in a cluster.  > > > & > > > I appreciate your consideration. > > >  > > > Jeff Cameron > > >  > > ) > > I have no cluster to test with, but -  > >  > > mcr sysman > > set env/cluster   > > do sho dev/files device-name >  > ...or how 'bout: > 
 > $ PIPE -( >    (WRITE SYS$OUTPUT "SET ENV/CLU" ; -: >     WRITE SYS$OUTPUT "DO SHOW DEV/FI ", DEVICE_NAME) | - >    RUN SYS$SYSTEM:SYSMAN >   8 Thanks for this.  I never quite get the power of PIPE or the syntax gyrations of it.   1 I bet there is a session in PIPE hints and kinks.   6 (...and yes, I did, indeed, mean SYSMAN (I was waiting; for something else to complete and it was a long day :) ).)    > -- > David J Dachtera > dba DJE Systems  > http://www.djesys.com/ > + > Unofficial OpenVMS Hobbyist Support Page: $ > http://www.djesys.com/vms/support/ > * > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/  > $ > Unofficial OpenVMS-IA32 Home Page:! > http://www.djesys.com/vms/ia32/  >  > Coming soon:( > Unofficial OpenVMS Marketing Home Page   ------------------------------  + Date: Thu, 11 Aug 2005 13:35:07 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)3 Subject: Re: $SHOW DEVICE/FILES enhancement request $ Message-ID: <ddfk6b$m0p$1@online.de>  3 In article <J3YVqJPJIbki@eisner.encompasserve.org>, > koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:   r > In article <OF798AA0E3.578D9117-ON8525705A.000AAE12-8525705A.000AF671@metso.com>, norm.raphael@metso.com writes: > > B > > ISTM that SYSGEN with SET ENVIROMENT should do this just fine. > > % > >> I appreciate your consideration.  > >  > J >    Me thinks you mean SYSMAN.  Yep, good stuff.  I just never understood@ >    why SYSMAN required OPER privilege, even for such otherwize >    non-privileged actions.  F Ditto PRODUCT.  Just to do SHOW you need way too many privs.  At most  READALL should suffice.    ------------------------------    Date: 11 Aug 2005 08:22:17 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 3 Subject: Re: $SHOW DEVICE/FILES enhancement request 3 Message-ID: <J3YVqJPJIbki@eisner.encompasserve.org>   p In article <OF798AA0E3.578D9117-ON8525705A.000AAE12-8525705A.000AF671@metso.com>, norm.raphael@metso.com writes: > @ > ISTM that SYSGEN with SET ENVIROMENT should do this just fine. > # >> I appreciate your consideration.  >   H    Me thinks you mean SYSMAN.  Yep, good stuff.  I just never understood>    why SYSMAN required OPER privilege, even for such otherwize    non-privileged actions.   ------------------------------    Date: 11 Aug 2005 11:40:50 -05004 From: kuhrt@nospammy.encompasserve.org (Marty Kuhrt)7 Subject: Re: 7.3-2 Crashes when a Samba Client connects 3 Message-ID: <cP6xMSc8BFZp@eisner.encompasserve.org>   \ In article <96ADA4779wspenceraporg@216.168.3.30>, noone@nowhere.com (Warren Spencer) writes:M > We've got a fix now (tell mulinet to use the ucx driver).  Thanks to those   > who pondered this! >  > ws  A Can you document what you did to make it work?  I was just about  D to try and start a Samba install on a similar setup (V7.3-2, Mu4.4A,+ SMB2.2.8) and am now more nervous about it.    > 6 > wspencer@ap.dontspamme.org (Warren Spencer) wrote in) > <96ACA7719wspenceraporg@216.168.3.30>:   >  >>Hi Folks,  >>J >>I've got an OpenVMS crash I need to sort out and I'm looking for help on >>where to go next.    >>G >>This is an OpenVMS 7.3-2 box, with all (applicable) patches applied.  I >>The tcpip stack is Multinet 4.4A, with all applicable patches applied.   >>The problem is this: >>J >>When any Samba client attempts to connect to this box, Multinet fires upG >>smbd_startup.com (as it should) and the box crashs with "SSRVEXCEPT,  ' >>Unexpected system service exception".  >>G >>The Samba version is 2.2.8, freshly compiled & installed on this box.  >> >>Some other info: >>I >>- Either a local or remote samba client connecting will cause the crash 8 >>- The crash always happens on the first client connect> >>- The crash always happens - Samba has yet to work correctlyH >>- I've configured smbd as a Multinet service, so Multinet is invoking I >>smbd_startup.com.  But I'm not sure if this is the way it's supposed to  >>be set up. >>/ >>Any ideas where to go next?  What to look at?  >> >>Many thanks! >> >>ws >> >    ------------------------------    Date: 11 Aug 2005 12:10:00 -05004 From: kuhrt@nospammy.encompasserve.org (Marty Kuhrt)H Subject: Re: anyone using the WeatherDuck?  Other environmental monitor?3 Message-ID: <pkchog0mZ9rE@eisner.encompasserve.org>   _ In article <05080910231731@dscis6-0.dalsemi.com>, brandon@dalsemi.com (BRANDON, JOHN M) writes: H > Anyone using the WeatherDuck to monitor their data center environment? >  > Other product(s)?  >  > With satisfaction?  @ At my last job (maybe I should say former job, "last" job soundsD like I'll never work again, but I digress) I used three WeatherDucksD to monitor the three data centers we had in Berkeley.  It wasn't tooD difficult to set up some batch processes to gather the data and makeA a webpage that graphed that data.  The ducks would randomly quit  C reporting, so I had to create another job to check the outputs and  B restart the "quiet" collector.  I also had another batch job that @ parsed the logfiles to make sure the three locations were within acceptable ranges.   ------------------------------   Date: 11 Aug 2005 14:06:27 GMT/ From: Thierry Dussuet <thierry@dussuet.lugs.ch>  Subject: Re: Decus UUCP 1 Message-ID: <slrndfmmr4.1r34.thierry@MARS.Family>    Hello!  B On 2005-08-11, Volker Englisch <eh41@freebsd.polarhome.com> wrote:- > On Thu, 11 Aug 2005, Keith Cayemberg wrote:  >> Volker Englisch wrote:  >>> N >>> does anyone know where to still get DECUS UUCP for VMS/Vax from? All those1 >>> links found in the WWW do no more exist. TIA.  >>> J >> http://www.encompassus.org/ftplib/VS0121_VAX90A_UUCP_AAAREADME_TXT.html > I > Thanks a lot. Do you by any chance know about a way to download this in  > _one_ piece?  3 I could offer http://www.lugs.ch/~dussuett/uucp.zip % It's in one piece and version 2.0 :-)   4 Look at [.UUCP.DOC]USRGD20.MEM for how to install it   Thierry   D PS: http://mvb.saic.com/ seems to have a lot of freeware for OpenVMS   ------------------------------   Date: 11 Aug 2005 14:59:27 GMT/ From: Thierry Dussuet <thierry@dussuet.lugs.ch>  Subject: Re: Decus UUCP 1 Message-ID: <slrndfmpug.1r34.thierry@MARS.Family>   B On 2005-08-11, Volker Englisch <eh41@freebsd.polarhome.com> wrote:- > On Thu, 11 Aug 2005, Thierry Dussuet wrote: 	 >> Hello!  >>E >> On 2005-08-11, Volker Englisch <eh41@freebsd.polarhome.com> wrote: / >>> On Thu, 11 Aug 2005, Keith Cayemberg wrote:  >>>> Volker Englisch wrote:  >>>>> P >>>>> does anyone know where to still get DECUS UUCP for VMS/Vax from? All those3 >>>>> links found in the WWW do no more exist. TIA.  >>>>> L >>>> http://www.encompassus.org/ftplib/VS0121_VAX90A_UUCP_AAAREADME_TXT.html >>> K >>> Thanks a lot. Do you by any chance know about a way to download this in  >>> _one_ piece? >>6 >> I could offer http://www.lugs.ch/~dussuett/uucp.zip( >> It's in one piece and version 2.0 :-) > L > Thanks a lot. I just downloaded that file and realized that there are muchB > less subdirs in it than on the encompassus site - but maybe it's# > sufficient for building uucp. ;-)   L Alot of subdirs are created when running [.BIN]DECOMP_DIST_20.COM (about 12)   Thierry    ------------------------------  % Date: Thu, 11 Aug 2005 12:57:00 +0300 4 From: Mike Rechtman <michael.rechtman.nospam@hp.com>. Subject: Re: Help Needed: Tape Backup Save Set& Message-ID: <42FB4B1C.3A890A5E@hp.com>   Brad Hamilton wrote: >  > Steven M. Schweda wrote:: > > From: Brad Hamilton <brMadAhamPiltSon@coMmcaAstP.neSt> > > ' > >>$backup/list (tape device)/save_set ' > >>                          ^^^^^^^^^  > >  > > L > >   If anyone ever finds a case where /SAVE_SET is actually required for a, > > tape device, please provide the details. > >  > J > I remember that back in the VMS 5.* days, this used to be a requirement. > = > I got in the habit back then, and haven't looked back.  :-)  > B > I know some of our Operations folks in the V7.1 era had problemsB > restoring files from tape savesets without /SAVE_SET, and had no0 > problems restoring files _with_ the qualifier. > E > I have no tape drives with which to test your assertion - I have no & > doubt that you are correct, however. > J > You'll notice, however, that almost all the other answers in this threadC > have specified /SAVE_SET as an output qualifier for tape devices.  > - > Can 50 million VMS manglers be wrong?   :-)  >  > <snip> >  > -- > Bradford J. Hamilton > "All opinions are my own" , > "Lose the MAPS, and replace '-at-' with @"   $ help backup /save  BACKUP     /SAVE_SET   '      Input or Output Save-Set Qualifier   @      Defines the input or output specifier as a BACKUP save set.G      Normally, BACKUP treats specifiers that refer to disk files as      <===G      Files-11 files and specifiers that refer to tapes as BACKUP save    <===
      sets.  F      You must specify the /SAVE_SET qualifier when the input or output7      specifier is a BACKUP save set on a Files-11 disk.       Mike                   --  E --------------------------------------------------------------------- E Usual disclaimer: All opinions are mine alone, perhaps not even that. ? Mike Rechtman                            *rechtman@tzora.co.il* F Kibbutz Tzor'a.                          Voice (home): 972-2-9908337  B   "20% of a job takes 80% of the time, the rest takes another 80%"E ---------------------------------------------------------------------  -----BEGIN GEEK CODE BLOCK-----  Version: 3.1: GCM/CS d(-)pu s:+>:- a++ C++ U-- L-- W++ N++ K? w--- V+++$6 PS+ PE-- t 5? X- tv-- b+ DI+ D-- G e++ h--- r+++ y+++@ ------END GEEK CODE BLOCK------    ------------------------------  % Date: Thu, 11 Aug 2005 08:14:02 -0500 ( From: Wayne Sewell <wayne@tachysoft.com>. Subject: Re: Help Needed: Tape Backup Save Set0 Message-ID: <00A481D5.18A32E24.13@tachysoft.com>  & >Date: Wed, 10 Aug 2005 19:04:39 -04007 >From: Brad Hamilton <brMadAhamPiltSon@coMmcaAstP.neSt> / >Subject: Re: Help Needed: Tape Backup Save Set D >In-Reply-To: <1123713155.901351.57190@g14g2000cwa.googlegroups.com>< >Content-Type: text/plain; charset=ISO-8859-1; format=flowed  >Content-Transfer-Encoding: 7bit >  >Chris Allen wrote: J >>     Is it possible to determine what save sets are on a tape, or to getE >> a backup/list of a save set on tape without knowing what that save J >> set(s) file name is?  I'm a newbie to VMS and after setting up a backupI >> system I was very dissapointed to realize I couldn't restore files off F >> of tape unless I had the corresponding log files that would tell meJ >> save set file name on the tape (the name is generated according to node? >> name, date, etc. therefore it's not the same on every tape). D >>    When I do a "backup/list {tape device}:" or "backup/list {tapeI >> device}:[000000]" I always get "No files found".  I must manually do a H >> "backup/list {tape device}:{save set}".  But what if I don't know the6 >> save set?  Anyone know the answer to this?  Thanks. >>   > $ >$backup/list (tape device)/save_set% >                           ^^^^^^^^^  >     N the /save qualifier is not required for a tape device.  This is only needed ifH you want the saveset to go into a file on a file-structured device.  ForL backup, magnetic tapes are not considered to be file structured.  That's why they are mounted foreign. O =============================================================================== N Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne@tachysoft.com; http://www.tachysoft.com/www/tachyon.html and wayne.html    O =============================================================================== P Jake Blues:"You traded the Caddy for a microphone? ...... Okay, I can buy that."   ------------------------------  % Date: Thu, 11 Aug 2005 08:24:17 -0500 ( From: Wayne Sewell <wayne@tachysoft.com>. Subject: Re: Help Needed: Tape Backup Save Set0 Message-ID: <00A481D6.876A47D8.31@tachysoft.com>  + >From: sms@antinode.org (Steven M. Schweda)  >X-Newsgroups: comp.os.vms/ >Subject: Re: Help Needed: Tape Backup Save Set 3 >Message-ID: <05081018532608_20200298@antinode.org> , >Date: Wed, 10 Aug 2005 18:53:26 -0500 (CDT). >Organization: Info-VAX<==>comp.os.vms Gateway$ >X-Gateway-Source-Info: Mailing List
 >Lines: 24 >To: Info-VAX@Mvb.Saic.Com > 7 >From: Brad Hamilton <brMadAhamPiltSon@coMmcaAstP.neSt>  > & >> $backup/list (tape device)/save_set& >>                           ^^^^^^^^^ > I >  If anyone ever finds a case where /SAVE_SET is actually required for a ) >tape device, please provide the details.   K I've never seen one, and I've been working on tapesys since 1992, so I have < probably done backups in as many different modes as anybody.     > E >   It may be a helpful habit to cultivate so you don't need to think G >when working with save sets on disk, but I've never found it necessary B >on a tape device.  "HELP BACKUP_Command /SAVE_SET" (V7.3-1) says: > G >     You must specify the /SAVE_SET qualifier when the input or output 8 >     specifier is a BACKUP save set on a Files-11 disk. > I >Now this doesn't explicitly say that it's the default for a tape device, E >but I'll be waiting for a counter-example, and I won't be holding my  >breath. >   N Yep, it's the default for tape devices, so the /save qualifier is unnecessary.   Certainly easy enough to try:   ! ZEPPO> backup/list ZEPPO$MKB200:*  Listing of save set(s)  2 %MOUNT-I-MOUNTED, DLT026 mounted on _ZEPPO$MKB200: Save set:          TS6_HIST.HOT  Written by:        TAPESYS" UIC:               [000525,000001]* Date:               9-JUN-2005 20:30:18.13 Command:           BACK/LIST3 LAUREL_DISK3:[TAPESY*HIST*...]*.*;*/NOIMAGE/NORECOR M D/NOVERIFY/BLOCKSIZE=65024/EXCLUDE=([TAP*HIS*.HIST_VMSKITS])/NOLOG/CRC/NOFAST A _HARDY$MKB600:TS6_HIST.HOT/REWI/SAVE/EXACT/NOASSI/MEDIA=NOCOMPACT - Operating system:  OpenVMS Alpha version V7.3  BACKUP version:    AXP72R001 CPU ID register:   80000000  Node name:         _HARDY:: ! Written on:        _HARDY$MKB600:  Block size:        65024 Group size:        10  Buffer count:      114  P [TAPESYS_HISTORY]HIST_ALPHA71FT2.DIR;1                      1  18-JUL-2001 09:39P [TAPESYS_HISTORY.HIST_ALPHA71FT2]$ALPHA71FT2.5R0;1         36  10-JAN-1997 11:13P [TAPESYS_HISTORY.HIST_ALPHA71FT2]SBATTR.COM;1               4  18-JUL-2001 09:39   <remainder of listing deleted>O =============================================================================== N Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne@tachysoft.com; http://www.tachysoft.com/www/tachyon.html and wayne.html    O =============================================================================== P Jake Blues:"You traded the Caddy for a microphone? ...... Okay, I can buy that."   ------------------------------  % Date: Thu, 11 Aug 2005 08:29:19 -0500 ( From: Wayne Sewell <wayne@tachysoft.com>. Subject: Re: Help Needed: Tape Backup Save Set/ Message-ID: <00A481D7.3BAB4085.1@tachysoft.com>   ) >From: "Chris Allen" <ca.allen@gmail.com>  >X-Newsgroups: comp.os.vms+ >Subject: Help Needed: Tape Backup Save Set ! >Date: 10 Aug 2005 15:32:35 -0700   H >    Is it possible to determine what save sets are on a tape, or to getC >a backup/list of a save set on tape without knowing what that save H >set(s) file name is?  I'm a newbie to VMS and after setting up a backupG >system I was very dissapointed to realize I couldn't restore files off D >of tape unless I had the corresponding log files that would tell meH >save set file name on the tape (the name is generated according to node= >name, date, etc. therefore it's not the same on every tape). B >   When I do a "backup/list {tape device}:" or "backup/list {tapeG >device}:[000000]" I always get "No files found".  I must manually do a F >"backup/list {tape device}:{save set}".  But what if I don't know the4 >save set?  Anyone know the answer to this?  Thanks.  @ I could point out that if you get tapesys from software partnersM (www.softwarepartners.com), you won't have to worry about keeping up with the N savesets or the files on them, as this tape management software will do it for you.     I could, but I won't.  :-) :-)     Wayne O =============================================================================== N Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne@tachysoft.com; http://www.tachysoft.com/www/tachyon.html and wayne.html    O =============================================================================== P Jake Blues:"You traded the Caddy for a microphone? ...... Okay, I can buy that."   ------------------------------    Date: 11 Aug 2005 08:20:07 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) . Subject: Re: Help Needed: Tape Backup Save Set3 Message-ID: <nSL6hM$mYoBf@eisner.encompasserve.org>   i In article <wqCdnQbg6toTPGffRVn-hA@comcast.com>, Brad Hamilton <brMadAhamPiltSon@coMmcaAstP.neSt> writes:  > J > I remember that back in the VMS 5.* days, this used to be a requirement.  G    I've been using BACKUP since 3.0 and never have had to use /save_set     on a tape save set.   ------------------------------  % Date: Thu, 11 Aug 2005 08:35:21 -0500 ( From: Wayne Sewell <wayne@tachysoft.com>. Subject: Re: Help Needed: Tape Backup Save Set0 Message-ID: <00A481D8.12FEDFBA.61@tachysoft.com>  & >Date: Wed, 10 Aug 2005 20:53:32 -04007 >From: Brad Hamilton <brMadAhamPiltSon@coMmcaAstP.neSt> 9 >User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) / >Subject: Re: Help Needed: Tape Backup Save Set 4 >In-Reply-To: <05081018532608_20200298@antinode.org> >  >Steven M. Schweda wrote: 9 >> From: Brad Hamilton <brMadAhamPiltSon@coMmcaAstP.neSt>  >>  & >>>$backup/list (tape device)/save_set& >>>                          ^^^^^^^^^ >>   >>  K >>   If anyone ever finds a case where /SAVE_SET is actually required for a + >> tape device, please provide the details.  >> > I >I remember that back in the VMS 5.* days, this used to be a requirement.   ; I go back to vms version 1.0 and I have never had to do it.    > ; >I got in the habit back then, and haven't looked back.	:-)  > B >I know some of our Operations folks in the V7.1 era had problems B >restoring files from tape savesets without /SAVE_SET, and had no / >problems restoring files _with_ the qualifier.  > E >I have no tape drives with which to test your assertion - I have no  % >doubt that you are correct, however.   6 I do, and posted a sample run elsewhere in the thread.   > J >You'll notice, however, that almost all the other answers in this thread B >have specified /SAVE_SET as an output qualifier for tape devices. > * >Can 50 million VMS manglers be wrong?	:-) >     E Most everybody in the world thought the earth was flat at the time of 	 columbus.   I It doesn't *hurt* anything to specify the /save qualifier.  But it is not 	 required. O =============================================================================== N Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne@tachysoft.com; http://www.tachysoft.com/www/tachyon.html and wayne.html    O =============================================================================== P Jake Blues:"You traded the Caddy for a microphone? ...... Okay, I can buy that."   ------------------------------  % Date: Thu, 11 Aug 2005 08:41:55 -0500 ( From: Wayne Sewell <wayne@tachysoft.com>. Subject: Re: Help Needed: Tape Backup Save Set/ Message-ID: <00A481D8.FE238103.9@tachysoft.com>   & >Date: Wed, 10 Aug 2005 21:28:34 -05003 >From: David J Dachtera <djesys.nospam@comcast.net> & >Reply-To: djesysno@spam.earthlink.net >Organization: DJE Systems     > 	 >Z wrote:  >>   >> William Webb wrote: >> > If you ) >> > MOUNT/FOREIGN tape_device tape_label  > D >"label" is optional for /FOREIGN, but will be checked if specified. >  >> > You can >> > BACKUP/LIST tape_device:* >>  A >> If you're going to use BACKUP, let VMS mount the tape for you.  > 1 >Ooohhh... Careful there! Not always a good idea.  >   O Why?  I have been doing this since 1980, and have yet to see a problem with it. + Certainly not with a read-only operation.     O =============================================================================== N Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne@tachysoft.com; http://www.tachysoft.com/www/tachyon.html and wayne.html    O =============================================================================== P Jake Blues:"You traded the Caddy for a microphone? ...... Okay, I can buy that."   ------------------------------    Date: 11 Aug 2005 08:56:56 -0500 From: briggs@encompasserve.org. Subject: Re: Help Needed: Tape Backup Save Set3 Message-ID: <FSwQmVB+8Ypu@eisner.encompasserve.org>   q In article <nSL6hM$mYoBf@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: k > In article <wqCdnQbg6toTPGffRVn-hA@comcast.com>, Brad Hamilton <brMadAhamPiltSon@coMmcaAstP.neSt> writes:  >>  K >> I remember that back in the VMS 5.* days, this used to be a requirement.  > I >    I've been using BACKUP since 3.0 and never have had to use /save_set  >    on a tape save set.  J Same.  I _think_ that standalone backup had a requirement to use /save_setG for save sets on magnetic tape.  But it's been a long while since I had  to do   # 	$ BACKUP MTA0:VMS034.A /SAVE DUA0:    and memory fades.   B These days, standalone backup is the same thing as regular backup.   	John Briggs   ------------------------------  % Date: Thu, 11 Aug 2005 09:57:41 -0400 6 From: Brad Hamilton <brMadAhamPiltSon@coMmcaAstP.neSt>. Subject: Re: Help Needed: Tape Backup Save Set0 Message-ID: <aYadneWxC5XLxGbfRVn-jQ@comcast.com>   Wayne Sewell wrote: , >>From: sms@antinode.org (Steven M. Schweda) >>X-Newsgroups: comp.os.vms 0 >>Subject: Re: Help Needed: Tape Backup Save Set4 >>Message-ID: <05081018532608_20200298@antinode.org>- >>Date: Wed, 10 Aug 2005 18:53:26 -0500 (CDT) / >>Organization: Info-VAX<==>comp.os.vms Gateway % >>X-Gateway-Source-Info: Mailing List  >>Lines: 24  >>To: Info-VAX@Mvb.Saic.Com  >>8 >>From: Brad Hamilton <brMadAhamPiltSon@coMmcaAstP.neSt> >>& >>>$backup/list (tape device)/save_set& >>>                          ^^^^^^^^^ >>I >> If anyone ever finds a case where /SAVE_SET is actually required for a * >>tape device, please provide the details. >  > M > I've never seen one, and I've been working on tapesys since 1992, so I have > > probably done backups in as many different modes as anybody. >  >   C Hmm, I guess I was wrong; I'll have to test it out the next time I  D encounter a tape device.  Thanks to you and Steven for correcting a  misconception.  I I _do_ work with savesets on disk, so it's a hard habit to break.  Is it  D OK if I keep using it for tape savesets?  Less thought involved.	:-)   <snip>   --   Bradford J. Hamilton "All opinions are my own" * "Lose the MAPS, and replace '-at-' with @"   ------------------------------    Date: 11 Aug 2005 07:01:43 -0700$ From: "AEF" <spamsink2001@yahoo.com>. Subject: Re: Help Needed: Tape Backup Save SetC Message-ID: <1123768498.681058.126460@g44g2000cwa.googlegroups.com>    Wayne Sewell wrote: ( > >Date: Wed, 10 Aug 2005 21:28:34 -05005 > >From: David J Dachtera <djesys.nospam@comcast.net> ( > >Reply-To: djesysno@spam.earthlink.net > >Organization: DJE Systems >  >  > >  > >Z wrote:  > >> > >> William Webb wrote:
 > >> > If you + > >> > MOUNT/FOREIGN tape_device tape_label  > > F > >"label" is optional for /FOREIGN, but will be checked if specified. > >  > >> > You can  > >> > BACKUP/LIST tape_device:* > >>C > >> If you're going to use BACKUP, let VMS mount the tape for you.  > > 3 > >Ooohhh... Careful there! Not always a good idea.  > >  > Q > Why?  I have been doing this since 1980, and have yet to see a problem with it. + > Certainly not with a read-only operation.  > Q > =============================================================================== P > Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne@tachysoft.com: > http://www.tachysoft.com/www/tachyon.html and wayne.htmlQ > =============================================================================== R > Jake Blues:"You traded the Caddy for a microphone? ...... Okay, I can buy that."   Path: P g2news1.google.com!postnews.google.com!g47g2000cwa.googlegroups.com!not-for-mail$ From: "AEF" <spamsink2...@yahoo.com> Newsgroups: comp.os.vms . Subject: Re: Help Needed: Tape Backup Save Set  Date: 10 Aug 2005 19:52:55 -0700& Organization: http://groups.google.com	 Lines: 27 C Message-ID: <1123728775.249578.288000@g47g2000cwa.googlegroups.com> 7 References: <8660a3a10508101605299d17b8@mail.gmail.com>      <9GyKe.3177$vb3.734@fe07.lga>! NNTP-Posting-Host: 71.247.174.206  Mime-Version: 1.0 . Content-Type: text/plain; charset="iso-8859-1"B X-Trace: posting.google.com 1123728781 4471 127.0.0.1 (11 Aug 2005
 02:53:01 GMT) ( X-Complaints-To: groups-abuse@google.com8 NNTP-Posting-Date: Thu, 11 Aug 2005 02:53:01 +0000 (UTC)* In-Reply-To: <9GyKe.3177$vb3.734@fe07.lga> User-Agent: G2/0.2& Complaints-To: groups-abuse@google.com- Injection-Info: g47g2000cwa.googlegroups.com;  posting-host=71.247.174.206;3    posting-account=S1CHKAwAAABpFhDaq68xHR8Q1WWz3f4G      Z wrote: > William Webb wrote: 
 > > If you( > > MOUNT/FOREIGN tape_device tape_label > > You can  > > BACKUP/LIST tape_device:*  > @ > If you're going to use BACKUP, let VMS mount the tape for you.  G Uh, on a v5.4-1 system I had trouble using BACKUP to mount a tape. If I F put in a tape that was not the first save set volume it would screw up> with funny characters reported as the label. Using an explicitD MOUNT/FOR made everything work fine. Ever since then I tend to do an? explicit MOUNT first, except with standalone backup, of course!   4 I think you meant let BACKUP mount the tape for you.  D I'm surprised someone doesn't chime in insisting you should ALLOCATED the drive before you load the tape! And then someone else would say,G "Be careful not to forget to DEALLOCATE the drive when you're done, and ' then only *after* you unload the tape!"   @ And STILL we don't know what went wrong for the OP as he did notF provide an actual record of his session and actually told us a command that should work didn't.   ------------------------------  + Date: Thu, 11 Aug 2005 09:12:55 -0500 (CDT) * From: sms@antinode.org (Steven M. Schweda). Subject: Re: Help Needed: Tape Backup Save Set2 Message-ID: <05081109125536_20200298@antinode.org>   From: briggs@encompasserve.org  L > [...]  I _think_ that standalone backup had a requirement to use /save_setI > for save sets on magnetic tape.  But it's been a long while since I had  > to do  > % > 	$ BACKUP MTA0:VMS034.A /SAVE DUA0:   H    I doubt it, although the VMS installation instructions have tended toB include it, at least in recent years (say, the past decade or so).      And aren't you thinking of:  1         $ BACKUP /image MTA0:VMS034.b /SAVE DUA0:   A When VMS distributions started arriving on CD-ROM is when I first G discovered /SAVE_SET.  Until then, I'd never dealt with a save set on a H disk, and had never seen /SAVE_SET used in anger.  (I assume that that'sE about when it started to appear in the VMS installation instructions, A but that's just an assumption.  I didn't start caring until V5.0)    > and memory fades.   /    See the Van Helsing quotation cited earlier.     6 From: Brad Hamilton <brMadAhamPiltSon@coMmcaAstP.neSt>  J > I _do_ work with savesets on disk, so it's a hard habit to break.  Is itM > OK if I keep using it for tape savesets?  Less thought involved.        :-)   E    As I said early on, "It may be a helpful habit to cultivate so you G don't need to think when working with save sets on disk".  My complaint H was that its suggestion to the fellow with the problem was not likely to be helpful.       Is this horse dead yet?  H ------------------------------------------------------------------------  4    Steven M. Schweda               (+1) 651-699-98183    382 South Warwick Street        sms@antinode-org     Saint Paul  MN  55105-2547    ------------------------------  % Date: Thu, 11 Aug 2005 09:55:56 -0500 ( From: Wayne Sewell <wayne@tachysoft.com>. Subject: Re: Help Needed: Tape Backup Save Set/ Message-ID: <00A481E3.552C0F83.2@tachysoft.com>   & >Date: Thu, 11 Aug 2005 09:57:41 -04007 >From: Brad Hamilton <brMadAhamPiltSon@coMmcaAstP.neSt> 9 >User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)  >X-Accept-Language: en-us, en  >MIME-Version: 1.0 >X-Newsgroups: comp.os.vms/ >Subject: Re: Help Needed: Tape Backup Save Set 2 >In-Reply-To: <00A481D6.876A47D8.31@tachysoft.com> >  >Wayne Sewell wrote:- >>>From: sms@antinode.org (Steven M. Schweda)  >>>X-Newsgroups: comp.os.vms1 >>>Subject: Re: Help Needed: Tape Backup Save Set 5 >>>Message-ID: <05081018532608_20200298@antinode.org> . >>>Date: Wed, 10 Aug 2005 18:53:26 -0500 (CDT)0 >>>Organization: Info-VAX<==>comp.os.vms Gateway& >>>X-Gateway-Source-Info: Mailing List >>>Lines: 24 >>>To: Info-VAX@Mvb.Saic.Com >>> 9 >>>From: Brad Hamilton <brMadAhamPiltSon@coMmcaAstP.neSt>  >>> ' >>>>$backup/list (tape device)/save_set ' >>>>                          ^^^^^^^^^  >>> J >>> If anyone ever finds a case where /SAVE_SET is actually required for a+ >>>tape device, please provide the details.  >>   >>  N >> I've never seen one, and I've been working on tapesys since 1992, so I have? >> probably done backups in as many different modes as anybody.  >>   >>   > D >Hmm, I guess I was wrong; I'll have to test it out the next time I E >encounter a tape device.  Thanks to you and Steven for correcting a   >misconception.  > D >I _do_ work with savesets on disk, so it's a hard habit to break.    ! Yes, in that case is it required.    >Is it  E >OK if I keep using it for tape savesets?  Less thought involved.	:-)  >   + Doesn't hurt anything, doesn't do anything. O =============================================================================== N Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne@tachysoft.com; http://www.tachysoft.com/www/tachyon.html and wayne.html    O =============================================================================== P Jake Blues:"You traded the Caddy for a microphone? ...... Okay, I can buy that."   ------------------------------  % Date: Thu, 11 Aug 2005 10:19:17 -0500 ( From: Wayne Sewell <wayne@tachysoft.com>. Subject: Re: Help Needed: Tape Backup Save Set/ Message-ID: <00A481E6.985539DA.2@tachysoft.com>   % >From: "AEF" <spamsink2001@yahoo.com>  >X-Newsgroups: comp.os.vms/ >Subject: Re: Help Needed: Tape Backup Save Set ! >Date: 10 Aug 2005 19:52:55 -0700 ' >Organization: http://groups.google.com 
 >Lines: 27   > 	 >Z wrote:  >> William Webb wrote: >> > If you ) >> > MOUNT/FOREIGN tape_device tape_label  >> > You can >> > BACKUP/LIST tape_device:* >>A >> If you're going to use BACKUP, let VMS mount the tape for you.  > H >Uh, on a v5.4-1 system I had trouble using BACKUP to mount a tape. If IG >put in a tape that was not the first save set volume it would screw up ? >with funny characters reported as the label. Using an explicit E >MOUNT/FOR made everything work fine. Ever since then I tend to do an @ >explicit MOUNT first, except with standalone backup, of course! >     M This appears to be historical residue from the previous millenium.  I was not ) able to reproduce this behavior on 7.3-2.   D In the following example, tape DLT038 is a continuation of a saveset       HARDY> sho dev mk   P Device                  Device           Error    Volume         Free  Trans MntP  Name                   Status           Count     Label        Blocks Count Cnt. HARDY$MKB600:           Online               0  HARDY> backup/list HARDY$MKB600: Listing of save set(s)  * %MOUNT-I-WRITELOCK, volume is write locked2 %MOUNT-I-MOUNTED, DLT038 mounted on _HARDY$MKB600:K %BACKUP-W-NOT1STVOL, HARDY$MKB600:[000000].; is not the start of a save set   , Save set:          KEYKOP_DISK.IMG, volume 2 Written by:        TAPESYS" UIC:               [000525,000001]* Date:               8-AUG-2005 07:37:55.73 Command:           BACK/LIST3 KEYKOP_DISK:/IMAGE/RECORD/NOVERIFY/BLOCKSIZE=65024/ # IGNORE=(INTERLOCK)/NOLOG/CRC/NOFAST , _HARDY$MKB600:KEYKOP_DISK.IMG/SAVE/EXACT/NOA SSI/MEDIA=COMPACT - Operating system:  OpenVMS Alpha version V7.3  BACKUP version:    AXP72R001 CPU ID register:   80000000  Node name:         _HARDY:: ! Written on:        _HARDY$MKB600:  Block size:        65024 Group size:        10  Buffer count:      114   Image save of volume set Number of volumes: 1  
  Interrupt   HARDY>      N Sure it got a warning message about not being at the beginning of the saveset,H but it certainly had no problems finding the label or mounting the tape.   Wayne O =============================================================================== N Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne@tachysoft.com; http://www.tachysoft.com/www/tachyon.html and wayne.html    O =============================================================================== P Jake Blues:"You traded the Caddy for a microphone? ...... Okay, I can buy that."   ------------------------------  % Date: Thu, 11 Aug 2005 20:30:52 +0300 0 From: "MUSTAFA ATAKAN" <matakan@inteltek.com.tr>E Subject: Killing a process that has allocated the tape drive - cont'd L Message-ID: <F014DACB8BE63442993543B780A2F0180151484B@asteriks.inteltek.ist>  , This is a multi-part message in MIME format.  ' ------_=_NextPart_001_01C59E9A.9AB538F1  Content-Type: text/plain;  	charset="us-ascii" + Content-Transfer-Encoding: quoted-printable    Hello John,   + This is the original poster of the case....   G I have been reading the follow-ups since I sent the first letter. Until H now, I rebooted one node from the cluster in order to solve the problem.G But the problem got even worse, I did not see the device $2$mga1. I run G "mc sysman io autoconf" and the device came back. But the problem still  remains the same.=20  D In the attached file, I have added all the useful data you mentionedG below. As you can see, when I say "show dev mga1 /full", it says that a C process is using the tape drive. But when I search the process with D "show system /full", there is no such process and it makes me really angry. Ghost process... :)  G Anyway, when I want to learn the version of fibre_scsi patch, I realize D that there is no such a patch (you can see it in the attached file).F Vms_7.3.1_Fibre_scsi v1.0 was removed and there is no the same kind ofE patch any more. (By the way, this upgrade was not performed by me.) I E suspect the fibre_scsi patch to be cause of the problem and waiting a G guy to verify my suspicion (so that i can call my local HP site and ask F him why they did not apply fibre_scsi patch) or show me a point that i. won't face with the same problem after reboot.  " Thank you all for your kind helps. Best Regards...    -----Original Message-----A From: John Malmberg [mailto:malmberg@dskwld.zko.dec.compaq.hp]=20 ( Sent: Wednesday, August 10, 2005 5:08 PM To: Info-VAX@Mvb.Saic.Com @ Subject: Re: Killing a process that has allocated the tape drive  G I will try to clear up some things in this thread.  Keep in mind that I + do not normally work with the tape drivers.   H The tape drive in the original post was named $1$MGA which means it is a Fibre Channel device.   C This means that the maximum time that a process should be in a hung E state because of a Tape problem is the value of TAPE_MVTMEOUT + (Time H expected for tape operation * error retry count).  TAPE_MVTIMEOUT is setH to 10 minutes on my DS10, but I do not think that value is checked until6 the error retries and recovery attempts are exhausted.  E If a process is in this hung state for more than that amount of time, G then that is a Fibre/SCSI-Tape driver bug somewhere, even if there is a H problem with the hardware that was the initial cause.  This is somethingD that logging a call to HP Software Support may be needed to resolve.  G In the original posting case the DMA transfers are under the control of F the Fibre Channel Adapter hardware, and until it confirms that the I/OG has been canceled the memory needs to remain locked by the tape driver.   G As the original poster has not responded to this thread, we do not know F what version of OpenVMS they are running, nor do we know what ECOs areB present, or even if after TAPE_MVTIMEOUT + ??? elapsed the process cleaned it self up.    John! malmberg@dskwld.zko.dec.compaq.hp  Personal Opinion Only   ' ------_=_NextPart_001_01C59E9A.9AB538F1  Content-Type: text/plain;  	name="error_data.txt"! Content-Transfer-Encoding: base64 # Content-Description: error_data.txt   Content-Disposition: attachment; 	filename="error_data.txt"  L WFNFUlZFUj5zaG93IGRldiBtZ2ExDQoNCkRldmljZSAgICAgICAgICAgICAgICAgIERldmljZSAgL ICAgICAgICAgRXJyb3IgICAgVm9sdW1lICAgICAgICAgRnJlZSAgVHJhbnMgTW50DQogTmFtZSAgL ICAgICAgICAgICAgICAgICBTdGF0dXMgICAgICAgICAgIENvdW50ICAgICBMYWJlbCAgICAgICAgL QmxvY2tzIENvdW50IENudA0KJDIkTUdBMTogICAgICAoWFNFUlZFUikgIE1vdW50ZWQgZGlzbW91L bnQgICAgMzUgICAgIEZEMDIgICAgICAgICAgICAgIDAgICAgIDEgICAwDQogICAgICAgICAgICAgL ICAgICAgICAgICBhbGxvYyBmb3JlaWduICANCiANClhTRVJWRVI+ZGlzbSAkMiRtZ2ExOiAvYWJvL cnQNCiVTWVNURU0tRi1ERVZOT1RNT1VOVCwgZGV2aWNlIGlzIG5vdCBtb3VudGVkDQoNClhTRVJWL RVI+bW91bnQgJDIkbWdhMTogL2Zvcg0KJU1PVU5ULUktT1BSUVNULCBkZXZpY2UgYWxyZWFkeSBhL bGxvY2F0ZWQgdG8gYW5vdGhlciB1c2VyDQolTU9VTlQtSS1PUFJRU1QsIGRldmljZSBfJDIkTUdBL MTogKFhTRVJWRVIpIGlzIG5vdCBhdmFpbGFibGUgZm9yIG1vdW50aW5nLg0KIEludGVycnVwdCANL Cg0KWFNFUlZFUj4NClhTRVJWRVI+c2hvdyBkZXYgbWdhMSAvZnVsbA0KJU1PVU5ULUktT1BSUVNUL Q0FOLCBvcGVyYXRvciByZXF1ZXN0IGNhbmNlbGVkDQoNCk1hZ3RhcGUgJDIkTUdBMTogKFhTRVJWL RVIpLCBkZXZpY2UgdHlwZSBDT01QQVEgU3VwZXJETFQxLCBpcyBvbmxpbmUsIGFsbG9jYXRlZCwNL CiAgICBkZWFsbG9jYXRlIG9uIGRpc21vdW50LCBtb3VudGVkIGZvcmVpZ24sIHZvbHVtZSBpcyBtL YXJrZWQgZm9yIGRpc21vdW50LA0KICAgIHJlY29yZC1vcmllbnRlZCBkZXZpY2UsIGZpbGUtb3JpL ZW50ZWQgZGV2aWNlLCBhdmFpbGFibGUgdG8gY2x1c3RlciwgZGV2aWNlDQogICAgaGFzIG11bHRpL cGxlIEkvTyBwYXRocywgZXJyb3IgbG9nZ2luZyBpcyBlbmFibGVkLCBjb250cm9sbGVyIHN1cHBvL cnRzDQogICAgY29tcGFjdGlvbiAoY29tcGFjdGlvbiAgZGlzYWJsZWQpLCBkZXZpY2Ugc3VwcG9yL dHMgZmFzdHNraXAgKHBlcl9pbykuDQoNCiAgICBFcnJvciBjb3VudCAgICAgICAgICAgICAgICAgL ICAzNSAgICBPcGVyYXRpb25zIGNvbXBsZXRlZCAgICAgICAgICAgNTYwNTc0MDcNCiAgICBPd25lL ciBwcm9jZXNzICAgICAgICAgICAgICAgICAiIiAgICBPd25lciBVSUMgICAgICAgICAgICAgICAgL ICAgICAgW01PUk1BTl0NCiAgICBPd25lciBwcm9jZXNzIElEICAgICAgICAyMDIyMURDNiAgICBEL ZXYgUHJvdCAgICAgICAgICAgIFM6UldQTCxPOlJXUEwsRzpSLFcNCiAgICBSZWZlcmVuY2UgY291L bnQgICAgICAgICAgICAgICAgMiAgICBEZWZhdWx0IGJ1ZmZlciBzaXplICAgICAgICAgICAgICAgL ICA1MTINCiAgICBXV0lEICAgMDIwMDAwMDg6NTAwRS0wOUUwLTAwMEUtQTVFMA0KDQogICAgVm9sL dW1lIGxhYmVsICAgICAgICAgICAgIkZEMDIgICIgICAgUmVsYXRpdmUgdm9sdW1lIG5vLiAgICAgL ICAgICAgICAgICAgICAwDQogICAgUmVjb3JkIHNpemUgICAgICAgICAgICAgICAgICAgIDAgICAgL VHJhbnNhY3Rpb24gY291bnQgICAgICAgICAgICAgICAgICAgICAxDQogICAgTW91bnQgc3RhdHVzL ICAgICAgICAgICAgIFByb2Nlc3MgICAgTW91bnQgY291bnQgICAgICAgICAgICAgICAgICAgICAgL ICAgICAwDQogICAgQUNQIHByb2Nlc3MgbmFtZSAgICAgICAgICAgICAgIiINCiAgICBEZW5zaXR5L ICAgICAgICAgICAgICAgICAgICAgU0RMVCAgICBGb3JtYXQgICAgICAgICAgICAgICAgICAgICAgL ICBOb3JtYWwtMTENCiAgICBBbGxvY2F0aW9uIGNsYXNzICAgICAgICAgICAgICAgMg0KDQogIFZvL bHVtZSBzdGF0dXM6ICBuby11bmxvYWQgb24gZGlzbW91bnQsIG9kZCBwYXJpdHkuDQoNCiAgSS9PL IHBhdGhzIHRvIGRldmljZSAgICAgICAgICAgICAgMg0KICBQYXRoIFBHQTAuMTAwMC0wMEUwLTAyL MDItMTcyMiAoWFNFUlZFUiksIHByaW1hcnkgcGF0aCwgY3VycmVudCBwYXRoLg0KICAgIEVycm9yL IGNvdW50ICAgICAgICAgICAgICAgICAgIDM1ICAgIE9wZXJhdGlvbnMgY29tcGxldGVkICAgICAgL ICAgICA1NjA0NjExNQ0KICBQYXRoIFBHQjAuMTAwMC0wMEUwLTAyMDItMTcyMSAoWFNFUlZFUikuL DQogICAgRXJyb3IgY291bnQgICAgICAgICAgICAgICAgICAgIDAgICAgT3BlcmF0aW9ucyBjb21wL bGV0ZWQgICAgICAgICAgICAgIDExMjkyDQoNCg0KWFNFUlZFUj5waXBlIHNob3cgc3lzdGVtIHwgL c2VhcmNoIHN5cyRpbnB1dCAyMDIyMURDNg0KJVNFQVJDSC1JLU5PTUFUQ0hFUywgbm8gc3RyaW5nL cyBtYXRjaGVkDQoNClhTRVJWRVI+bWMgc3lzbWFuIHBhcmFtIHNob3cgVEFQRV9NVlRJTUVPVVQNL CiVTWVNNQU4tSS1VU0VBQ1ROT0QsIGEgVVNFIEFDVElWRSBoYXMgYmVlbiBkZWZhdWx0ZWQgb24gL bm9kZSBYU0VSVkVSDQpOb2RlIFhTRVJWRVI6ICAgUGFyYW1ldGVycyBpbiB1c2U6IEFDVElWRQ0KL UGFyYW1ldGVyIE5hbWUgICAgICAgICAgICBDdXJyZW50ICAgIERlZmF1bHQgICAgTWluaW11bSAgL ICBNYXhpbXVtIFVuaXQgIER5bmFtaWMNCi0tLS0tLS0tLS0tLS0tICAgICAgICAgICAgLS0tLS0tL LSAgICAtLS0tLS0tICAgIC0tLS0tLS0gICAgLS0tLS0tLSAtLS0tICAtLS0tLS0tDQpUQVBFX01WL VElNRU9VVCAgICAgICAgICAgICAgICA2MDAgICAgICAgIDYwMCAgICAgICAgICAxICAgICAgNjQwL MDAgU2Vjb25kcyAgICAgRA0KIA0KWFNFUlZFUj4NCg0KDQpYU0VSVkVSPiAgICAgDQpYU0VSVkVSL PnByb2Qgc2hvdyBoaXN0DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAtLS0tL LS0tLS0tLSAtLS0tLS0tLS0tLSAtLS0tLS0tLS0tLS0tLS0tLS0tLQ0KUFJPRFVDVCAgICAgICAgL ICAgICAgICAgICAgICAgICAgICAgS0lUIFRZUEUgICAgT1BFUkFUSU9OICAgREFURSBBTkQgVElNL RQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gLS0tLS0tLS0tLS0gLS0tLS0tL LS0tLS0gLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkRFQyBBWFBWTVMgVk1TNzMyX0FNQVRIUlRMIFYxL LjAgICAgIFBhdGNoICAgICAgIEluc3RhbGwgICAgIDEzLUpVTC0yMDA1IDAzOjQwOjE4DQpERUMgL QVhQVk1TIFZNUzczMl9EQ0wgVjMuMCAgICAgICAgICBQYXRjaCAgICAgICBJbnN0YWxsICAgICAxL My1KVUwtMjAwNSAwMzo0MDoxOA0KREVDIEFYUFZNUyBWTVM3MzJfSU9HRU4gVjEuMCAgICAgICAgL UGF0Y2ggICAgICAgSW5zdGFsbCAgICAgMTMtSlVMLTIwMDUgMDM6NDA6MTgNCkRFQyBBWFBWTVMgL Vk1TNzMyX0pPQkNUTCBWMS4wICAgICAgIFBhdGNoICAgICAgIEluc3RhbGwgICAgIDEzLUpVTC0yL MDA1IDAzOjQwOjE4DQpERUMgQVhQVk1TIFZNUzczMl9NQU5BR0UgVjMuMCAgICAgICBQYXRjaCAgL ICAgICBJbnN0YWxsICAgICAxMy1KVUwtMjAwNSAwMzo0MDoxOA0KREVDIEFYUFZNUyBWTVM3MzJfL VkVSSUZZIFYxLjAgICAgICAgUGF0Y2ggICAgICAgSW5zdGFsbCAgICAgMTMtSlVMLTIwMDUgMDM6L NDA6MTgNCkRFQyBBWFBWTVMgVk1TNzMyX0dSQVBISUNTIFYzLjAgICAgIFBhdGNoICAgICAgIEluL c3RhbGwgICAgIDEzLUpVTC0yMDA1IDAyOjU0OjExDQpERUMgQVhQVk1TIFZNUzczMl9BQ1JUTCBWL MS4wICAgICAgICBQYXRjaCAgICAgICBJbnN0YWxsICAgICAxMy1KVUwtMjAwNSAwMjo0NzoxNw0KL REVDIEFYUFZNUyBWTVM3MzJfU1lTIFY3LjAgICAgICAgICAgUGF0Y2ggICAgICAgSW5zdGFsbCAgL ICAgMTMtSlVMLTIwMDUgMDI6Mjg6NTkNCkRFQyBBWFBWTVMgVk1TNzMyX0RSSVZFUiBWMi4wICAgL ICAgIFBhdGNoICAgICAgIEluc3RhbGwgICAgIDEzLUpVTC0yMDA1IDAyOjIxOjMzDQpDUFEgQVhQL Vk1TIEFEVkFOQ0VEU0VSVkVSIFY3LjMtQTQgICBGdWxsIExQICAgICBJbnN0YWxsICAgICAyMi1KL VU4tMjAwNSAwNjo0NjowOQ0KQ1BRIEFYUFZNUyBBRFZBTkNFRFNFUlZFUiBWNy4zLUExICAgRnVsL bCBMUCAgICAgUmVtb3ZlICAgICAgMjItSlVOLTIwMDUgMDY6NDY6MDkNCkRFQyBBWFBWTVMgRE5WL T1NJRUNPMDEgVjcuMy0yICAgICAgIFBhdGNoICAgICAgIEluc3RhbGwgICAgIDIyLUpVTi0yMDA1L IDA2OjE0OjMzDQpERUMgQVhQVk1TIEROVk9TSU1VUDAxIFY3LjMtMiAgICAgICBQYXRjaCAgICAgL ICBJbnN0YWxsICAgICAyMi1KVU4tMjAwNSAwNjoxNDozMw0KREVDIEFYUFZNUyBEV01PVElGX0VDL TzAyIFYxLjMtMSAgICAgUGF0Y2ggICAgICAgSW5zdGFsbCAgICAgMjItSlVOLTIwMDUgMDY6MTQ6L MzMNCkRFQyBBWFBWTVMgVENQSVBfRUNPIFY1LjQtMTU1ICAgICAgIFBhdGNoICAgICAgIEluc3RhL bGwgICAgIDIyLUpVTi0yMDA1IDA2OjE0OjMzDQpERUMgQVhQVk1TIFZNUzczMl9VUERBVEUgVjQuL MCAgICAgICBQYXRjaCAgICAgICBJbnN0YWxsICAgICAyMi1KVU4tMjAwNSAwNjoxMzozOA0KREVDL IEFYUFZNUyBWTVM3MzJfUENTSSBWMS4wICAgICAgICAgUGF0Y2ggICAgICAgSW5zdGFsbCAgICAgL MjItSlVOLTIwMDUgMDY6MTI6NDYNCkNQUSBBWFBWTVMgQ0RTQSBWMi4wLTEwOSAgICAgICAgICAgL IEZ1bGwgTFAgICAgIEluc3RhbGwgICAgIDIyLUpVTi0yMDA1IDA1OjUzOjE2DQpERUMgQVhQVk1TL IERFQ05FVF9PU0kgVjcuMy0yICAgICAgICBGdWxsIExQICAgICBJbnN0YWxsICAgICAyMi1KVU4tL MjAwNSAwNTo1MzoxNg0KREVDIEFYUFZNUyBEV01PVElGIFYxLjMtMSAgICAgICAgICAgRnVsbCBML UCAgICAgSW5zdGFsbCAgICAgMjItSlVOLTIwMDUgMDU6NTM6MTYNCkRFQyBBWFBWTVMgT1BFTlZNL UyBWNy4zLTIgICAgICAgICAgIFBsYXRmb3JtICAgIEluc3RhbGwgICAgIDIyLUpVTi0yMDA1IDA1L OjUzOjE2DQpERUMgQVhQVk1TIFRDUElQIFY1LjQtMTUgICAgICAgICAgICBGdWxsIExQICAgICBJL bnN0YWxsICAgICAyMi1KVU4tMjAwNSAwNTo1MzoxNg0KREVDIEFYUFZNUyBWTVMgVjcuMy0yICAgL ICAgICAgICAgICAgT3BlciBTeXN0ZW0gSW5zdGFsbCAgICAgMjItSlVOLTIwMDUgMDU6NTM6MTYNL CkhQIEFYUFZNUyBLRVJCRVJPUyBWMi4wLTYgICAgICAgICAgIEZ1bGwgTFAgICAgIEluc3RhbGwgL ICAgIDIyLUpVTi0yMDA1IDA1OjUzOjE2DQpDUFEgQVhQVk1TIENEU0EgVjEuMC0yICAgICAgICAgL ICAgICBGdWxsIExQICAgICBSZW1vdmUgICAgICAyMi1KVU4tMjAwNSAwNTo1MzoxNg0KREVDIEFYL UFZNUyBERUNORVRfT1NJIFY3LjMtMSAgICAgICAgRnVsbCBMUCAgICAgUmVtb3ZlICAgICAgMjItL SlVOLTIwMDUgMDU6NTM6MTYNCkRFQyBBWFBWTVMgRE5WT1NJRUNPMDEgVjcuMy0xICAgICAgIFBhL dGNoICAgICAgIFJlbW92ZSAgICAgIDIyLUpVTi0yMDA1IDA1OjUzOjE2DQpERUMgQVhQVk1TIERXL TU9USUYgVjEuMi02ICAgICAgICAgICBGdWxsIExQICAgICBSZW1vdmUgICAgICAyMi1KVU4tMjAwL NSAwNTo1MzoxNg0KREVDIEFYUFZNUyBPUEVOVk1TIFY3LjMtMSAgICAgICAgICAgUGxhdGZvcm0gL ICAgUmVtb3ZlICAgICAgMjItSlVOLTIwMDUgMDU6NTM6MTYNCkRFQyBBWFBWTVMgVENQSVAgVjUuL My0xOCAgICAgICAgICAgIEZ1bGwgTFAgICAgIFJlbW92ZSAgICAgIDIyLUpVTi0yMDA1IDA1OjUzL OjE2DQpERUMgQVhQVk1TIFRDUElQX0VDTyBWNS4zLTE4MSAgICAgICBQYXRjaCAgICAgICBSZW1vL dmUgICAgICAyMi1KVU4tMjAwNSAwNTo1MzoxNg0KREVDIEFYUFZNUyBUQ1BJUF9NVVAgVjUuMy0xL ODEgICAgICAgUGF0Y2ggICAgICAgUmVtb3ZlICAgICAgMjItSlVOLTIwMDUgMDU6NTM6MTYNCkRFL QyBBWFBWTVMgVk1TIFY3LjMtMSAgICAgICAgICAgICAgIE9wZXIgU3lzdGVtIFJlbW92ZSAgICAgL IDIyLUpVTi0yMDA1IDA1OjUzOjE2DQpERUMgQVhQVk1TIFZNUzczMV9BQ1JUTCBWMS4wICAgICAgL ICBQYXRjaCAgICAgICBSZW1vdmUgICAgICAyMi1KVU4tMjAwNSAwNTo1MzoxNg0KREVDIEFYUFZNL UyBWTVM3MzFfQ1BVMjIwOCBWMS4wICAgICAgUGF0Y2ggICAgICAgUmVtb3ZlICAgICAgMjItSlVOL LTIwMDUgMDU6NTM6MTYNCkRFQyBBWFBWTVMgVk1TNzMxX0NQVTIzMDggVjEuMCAgICAgIFBhdGNoL ICAgICAgIFJlbW92ZSAgICAgIDIyLUpVTi0yMDA1IDA1OjUzOjE2DQpERUMgQVhQVk1TIFZNUzczL MV9EQ0wgVjIuMCAgICAgICAgICBQYXRjaCAgICAgICBSZW1vdmUgICAgICAyMi1KVU4tMjAwNSAwL NTo1MzoxNg0KREVDIEFYUFZNUyBWTVM3MzFfRVY3IFYxLjAgICAgICAgICAgUGF0Y2ggICAgICAgL UmVtb3ZlICAgICAgMjItSlVOLTIwMDUgMDU6NTM6MTYNCkRFQyBBWFBWTVMgVk1TNzMxX0YxMVggL VjEuMCAgICAgICAgIFBhdGNoICAgICAgIFJlbW92ZSAgICAgIDIyLUpVTi0yMDA1IDA1OjUzOjE2L DQpERUMgQVhQVk1TIFZNUzczMV9GSUJSRV9TQ1NJIFYxLjAgICBQYXRjaCAgICAgICBSZW1vdmUgL ICAgICAyMi1KVU4tMjAwNSAwNTo1MzoxNg0KREVDIEFYUFZNUyBWTVM3MzFfTEFOIFY2LjAgICAgL ICAgICAgUGF0Y2ggICAgICAgUmVtb3ZlICAgICAgMjItSlVOLTIwMDUgMDU6NTM6MTYNCkRFQyBBL WFBWTVMgVk1TNzMxX0xBTiBWMS4wICAgICAgICAgIFBhdGNoICAgICAgIFJlbW92ZSAgICAgIDIyL LUpVTi0yMDA1IDA1OjUzOjE2DQpERUMgQVhQVk1TIFZNUzczMV9MSU5LRVIgVjEuMCAgICAgICBQL YXRjaCAgICAgICBSZW1vdmUgICAgICAyMi1KVU4tMjAwNSAwNTo1MzoxNg0KREVDIEFYUFZNUyBWL TVM3MzFfUENTSSBWMS4wICAgICAgICAgUGF0Y2ggICAgICAgUmVtb3ZlICAgICAgMjItSlVOLTIwL MDUgMDU6NTM6MTYNCkRFQyBBWFBWTVMgVk1TNzMxX1FNQU4gVjEuMCAgICAgICAgIFBhdGNoICAgL ICAgIFJlbW92ZSAgICAgIDIyLUpVTi0yMDA1IDA1OjUzOjE2DQpERUMgQVhQVk1TIFZNUzczMV9SL TVMgVjIuMCAgICAgICAgICBQYXRjaCAgICAgICBSZW1vdmUgICAgICAyMi1KVU4tMjAwNSAwNTo1L MzoxNg0KREVDIEFYUFZNUyBWTVM3MzFfUk1TIFYxLjAgICAgICAgICAgUGF0Y2ggICAgICAgUmVtL b3ZlICAgICAgMjItSlVOLTIwMDUgMDU6NTM6MTYNCkRFQyBBWFBWTVMgVk1TNzMxX1NZUyBWMi4wL ICAgICAgICAgIFBhdGNoICAgICAgIFJlbW92ZSAgICAgIDIyLUpVTi0yMDA1IDA1OjUzOjE2DQpEL RUMgQVhQVk1TIFZNUzczMV9TWVMgVjEuMCAgICAgICAgICBQYXRjaCAgICAgICBSZW1vdmUgICAgL ICAyMi1KVU4tMjAwNSAwNTo1MzoxNg0KSFAgQVhQVk1TIEtFUkJFUk9TIFYxLjAgICAgICAgICAgL ICAgVHJhbnNpdGlvbiAgUmVtb3ZlICAgICAgMjItSlVOLTIwMDUgMDU6NTM6MTYNCkhQIEFYUFZNL UyBLRVJCRVJPUyBWMS4wICAgICAgICAgICAgIFRyYW5zaXRpb24gIFJlZyBQcm9kdWN0IDIyLUpVL Ti0yMDA1IDA1OjQwOjExDQpERUMgQVhQVk1TIERGVSBWMi43LUEgICAgICAgICAgICAgICBGdWxsL IExQICAgICBJbnN0YWxsICAgICAwMi1OT1YtMjAwNCAxNDozMjo0OA0KREVDIEFYUFZNUyBWTVM3L MzFfTEFOIFY2LjAgICAgICAgICAgUGF0Y2ggICAgICAgSW5zdGFsbCAgICAgMTYtSlVMLTIwMDMgL MjI6NTA6MDkNCkRFQyBBWFBWTVMgVk1TNzMxX1BDU0kgVjEuMCAgICAgICAgIFBhdGNoICAgICAgL IEluc3RhbGwgICAgIDE2LUpVTC0yMDAzIDIyOjQxOjQ5DQpERUMgVk1TIEFWQUlMX01BTiBWMi4zL ICAgICAgICAgICAgICBGdWxsIExQICAgICBJbnN0YWxsICAgICAwNy1NQVktMjAwMyAxMToyNTozL NQ0KREVDIFZNUyBBVkFJTF9NQU4gVjIuMyAgICAgICAgICAgICAgRnVsbCBMUCAgICAgUmVtb3ZlL ICAgICAgMDctTUFZLTIwMDMgMTE6MjU6MDINCkRFQyBWTVMgQVZBSUxfTUFOIFYyLjMgICAgICAgL ICAgICAgIEZ1bGwgTFAgICAgIEluc3RhbGwgICAgIDA3LU1BWS0yMDAzIDExOjEyOjQ2DQpDUFEgL QVhQVk1TIEFEVkFOQ0VEU0VSVkVSIFY3LjMtQTEgICBGdWxsIExQICAgICBJbnN0YWxsICAgICAxL NS1GRUItMjAwMyAxNzo0OTowMw0KQ1BRIEFYUFZNUyBBRFZBTkNFRFNFUlZFUiBWNy4zICAgICAgL RnVsbCBMUCAgICAgUmVtb3ZlICAgICAgMTUtRkVCLTIwMDMgMTc6NDk6MDMNCkRFQyBBWFBWTVMgL Vk1TNzMxX0xJTktFUiBWMS4wICAgICAgIFBhdGNoICAgICAgIEluc3RhbGwgICAgIDE1LUZFQi0yL MDAzIDE1OjU5OjQ5DQpERUMgQVhQVk1TIFZNUzczMV9BQ1JUTCBWMS4wICAgICAgICBQYXRjaCAgL ICAgICBJbnN0YWxsICAgICAxNS1GRUItMjAwMyAxNTo1OToxNQ0KREVDIEFYUFZNUyBWTVM3MzFfL RENMIFYyLjAgICAgICAgICAgUGF0Y2ggICAgICAgSW5zdGFsbCAgICAgMTUtRkVCLTIwMDMgMTU6L NTM6MjgNCkRFQyBBWFBWTVMgVk1TNzMxX0YxMVggVjEuMCAgICAgICAgIFBhdGNoICAgICAgIEluL c3RhbGwgICAgIDE1LUZFQi0yMDAzIDE1OjUyOjUxDQpERUMgQVhQVk1TIFZNUzczMV9RTUFOIFYxL LjAgICAgICAgICBQYXRjaCAgICAgICBJbnN0YWxsICAgICAxNS1GRUItMjAwMyAxNTo1MjowMQ0KL REVDIEFYUFZNUyBTV0NDIFYyLjUtMTA2ICAgICAgICAgICAgRnVsbCBMUCAgICAgSW5zdGFsbCAgL ICAgMTUtRkVCLTIwMDMgMTI6MTk6MjINCkRFQyBBWFBWTVMgQ09CUlRMIFYyLjctNjAzQiAgICAgL ICAgIEZ1bGwgTFAgICAgIEluc3RhbGwgICAgIDE0LUZFQi0yMDAzIDExOjE4OjQ1DQpERUMgQVhQL Vk1TIENPQk9MIFYyLjctMTIwOSAgICAgICAgICBGdWxsIExQICAgICBJbnN0YWxsICAgICAxNC1GL RUItMjAwMyAxMToxNzo1MA0KQ1BRIEFYUFZNUyBBRFZBTkNFRFNFUlZFUiBWNy4zICAgICAgRnVsL bCBMUCAgICAgSW5zdGFsbCAgICAgMjQtSkFOLTIwMDMgMjA6Mjk6MjkNCkRFQyBBWFBWTVMgVENQL SVBfRUNPIFY1LjMtMTgxICAgICAgIFBhdGNoICAgICAgIEluc3RhbGwgICAgIDIxLUpBTi0yMDAzL IDEyOjAyOjM2DQpERUMgQVhQVk1TIEROVk9TSUVDTzAxIFY3LjMtMSAgICAgICBQYXRjaCAgICAgL ICBJbnN0YWxsICAgICAyMS1KQU4tMjAwMyAxMjowMTowMQ0KREVDIEFYUFZNUyBWTVM3MzFfRklCL UkVfU0NTSSBWMS4wICAgUGF0Y2ggICAgICAgSW5zdGFsbCAgICAgMjAtSkFOLTIwMDMgMTg6MjU6L MzgNCkRFQyBBWFBWTVMgVk1TNzMxX0xBTiBWMS4wICAgICAgICAgIFBhdGNoICAgICAgIEluc3RhL bGwgICAgIDIwLUpBTi0yMDAzIDE4OjA3OjE2DQpERUMgQVhQVk1TIFZNUzczMV9FVjcgVjEuMCAgL ICAgICAgICBQYXRjaCAgICAgICBJbnN0YWxsICAgICAyMC1KQU4tMjAwMyAxODowNjo0NQ0KREVDL IEFYUFZNUyBWTVM3MzFfUk1TIFYyLjAgICAgICAgICAgUGF0Y2ggICAgICAgSW5zdGFsbCAgICAgL MjAtSkFOLTIwMDMgMTg6MDE6MzINCkRFQyBBWFBWTVMgVk1TNzMxX1NZUyBWMi4wICAgICAgICAgL IFBhdGNoICAgICAgIEluc3RhbGwgICAgIDIwLUpBTi0yMDAzIDE3OjU1OjIyDQpERUMgQVhQVk1TL IFZNUzczMV9DUFUyMjA4IFYxLjAgICAgICBQYXRjaCAgICAgICBJbnN0YWxsICAgICAyMC1KQU4tL MjAwMyAxNzo1MDoyOA0KREVDIEFYUFZNUyBWTVM3MzFfU1lTIFYxLjAgICAgICAgICAgUGF0Y2ggL ICAgICAgSW5zdGFsbCAgICAgMjQtU0VQLTIwMDIgMTQ6MDQ6MTQNCkRFQyBBWFBWTVMgVk1TNzMxL X1JNUyBWMS4wICAgICAgICAgIFBhdGNoICAgICAgIEluc3RhbGwgICAgIDI0LVNFUC0yMDAyIDEzL OjU2OjQ3DQpERUMgQVhQVk1TIFZNUzczMV9DUFUyMzA4IFYxLjAgICAgICBQYXRjaCAgICAgICBJL bnN0YWxsICAgICAyNC1TRVAtMjAwMiAxMzo0NzowMA0KREVDIEFYUFZNUyBUQ1BJUF9NVVAgVjUuL My0xODEgICAgICAgUGF0Y2ggICAgICAgSW5zdGFsbCAgICAgMDUtQVVHLTIwMDIgMjE6MTQ6MjENL CkNQUSBBWFBWTVMgQ1NXQiBWMS4wICAgICAgICAgICAgICAgIEZ1bGwgTFAgICAgIEluc3RhbGwgL ICAgIDA1LUFVRy0yMDAyIDEyOjI1OjUwDQpERUMgQVhQVk1TIERFQ05FVF9PU0kgVjcuMy0xICAgL ICAgICBGdWxsIExQICAgICBJbnN0YWxsICAgICAwNS1BVUctMjAwMiAxMjoyNDowOQ0KQ1BRIEFYL UFZNUyBDRFNBIFYxLjAtMiAgICAgICAgICAgICAgRnVsbCBMUCAgICAgSW5zdGFsbCAgICAgMDItL QVVHLTIwMDIgMTQ6Mjg6MDkNCkRFQyBBWFBWTVMgRFdNT1RJRiBWMS4yLTYgICAgICAgICAgIEZ1L bGwgTFAgICAgIEluc3RhbGwgICAgIDAyLUFVRy0yMDAyIDE0OjI4OjA5DQpERUMgQVhQVk1TIE9QL RU5WTVMgVjcuMy0xICAgICAgICAgICBQbGF0Zm9ybSAgICBJbnN0YWxsICAgICAwMi1BVUctMjAwL MiAxNDoyODowOQ0KREVDIEFYUFZNUyBUQ1BJUCBWNS4zLTE4ICAgICAgICAgICAgRnVsbCBMUCAgL ICAgSW5zdGFsbCAgICAgMDItQVVHLTIwMDIgMTQ6Mjg6MDkNCkRFQyBBWFBWTVMgVk1TIFY3LjMtL MSAgICAgICAgICAgICAgIE9wZXIgU3lzdGVtIEluc3RhbGwgICAgIDAyLUFVRy0yMDAyIDE0OjI4L OjA5DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAtLS0tLS0tLS0tLSAtLS0tL LS0tLS0tLSAtLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIA0KODggaXRlbXMgZm91bmQNClhTRVJWRVI+L cHJvZCBzaG93IHByb2QgL2Z1bGwNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tL IC0tLS0tLS0tLS0tIC0tLS0tLS0tLS0tLSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tL LS0tLSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KUFJPRFVDVCAgICAgICAgL ICAgICAgICAgICAgICAgICAgICAgS0lUIFRZUEUgICAgU1RBVEUgICAgICAgIE1BSU5URU5BTkNFL ICAgICAgICAgICAgICAgICAgICAgICAgIFJFRkVSRU5DRUQgQlkNCi0tLS0tLS0tLS0tLS0tLS0tL LS0tLS0tLS0tLS0tLS0tLS0tIC0tLS0tLS0tLS0tIC0tLS0tLS0tLS0tLSAtLS0tLS0tLS0tLS0tL LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tL LQ0KQ1BRIEFYUFZNUyBBRFZBTkNFRFNFUlZFUiBWNy4zLUE0ICAgRnVsbCBMUCAgICAgSW5zdGFsL bGVkDQpDUFEgQVhQVk1TIENEU0EgVjIuMC0xMDkgICAgICAgICAgICBGdWxsIExQICAgICBJbnN0L YWxsZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgREVDIEFYUFZNUyBPL UEVOVk1TIFY3LjMtMg0KQ1BRIEFYUFZNUyBDU1dCIFYxLjAgICAgICAgICAgICAgICAgRnVsbCBML UCAgICAgSW5zdGFsbGVkDQpERUMgQVhQVk1TIENPQk9MIFYyLjctMTIwOSAgICAgICAgICBGdWxsL IExQICAgICBJbnN0YWxsZWQNCkRFQyBBWFBWTVMgQ09CUlRMIFYyLjctNjAzQiAgICAgICAgIEZ1L bGwgTFAgICAgIEluc3RhbGxlZA0KREVDIEFYUFZNUyBERUNORVRfT1NJIFY3LjMtMiAgICAgICAgL RnVsbCBMUCAgICAgSW5zdGFsbGVkICAgIERFQyBBWFBWTVMgRE5WT1NJRUNPMDEgVjcuMy0yICAgL ICAgIERFQyBBWFBWTVMgT1BFTlZNUyBWNy4zLTINCiAgICAgICAgICAgICAgICAgICAgICAgICAgL ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBERUMgQVhQVk1TIEROVk9TSU1VUDAxL IFY3LjMtMg0KREVDIEFYUFZNUyBERlUgVjIuNy1BICAgICAgICAgICAgICAgRnVsbCBMUCAgICAgL SW5zdGFsbGVkDQpERUMgQVhQVk1TIERXTU9USUYgVjEuMy0xICAgICAgICAgICBGdWxsIExQICAgL ICBJbnN0YWxsZWQgICAgREVDIEFYUFZNUyBEV01PVElGX0VDTzAyIFYxLjMtMSAgICAgREVDIEFYL UFZNUyBPUEVOVk1TIFY3LjMtMg0KREVDIEFYUFZNUyBPUEVOVk1TIFY3LjMtMiAgICAgICAgICAgL UGxhdGZvcm0gICAgSW5zdGFsbGVkDQpERUMgQVhQVk1TIFNXQ0MgVjIuNS0xMDYgICAgICAgICAgL ICBGdWxsIExQICAgICBJbnN0YWxsZWQNCkRFQyBBWFBWTVMgVENQSVAgVjUuNC0xNSAgICAgICAgL ICAgIEZ1bGwgTFAgICAgIEluc3RhbGxlZCAgICBERUMgQVhQVk1TIFRDUElQX0VDTyBWNS40LTE1L NSAgICAgICBERUMgQVhQVk1TIE9QRU5WTVMgVjcuMy0yDQpERUMgQVhQVk1TIFZNUyBWNy4zLTIgL ICAgICAgICAgICAgICBPcGVyIFN5c3RlbSBJbnN0YWxsZWQgICAgREVDIEFYUFZNUyBWTVM3MzJfL QUNSVEwgVjEuMCAgICAgICAgQ1BRIEFYUFZNUyBDRFNBIFYyLjAtMTA5DQogICAgICAgICAgICAgL ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgREVDIEFYUFZNL UyBWTVM3MzJfQU1BVEhSVEwgVjEuMCAgICAgREVDIEFYUFZNUyBDT0JPTCBWMi43LTEyMDkNCiAgL ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL ICBERUMgQVhQVk1TIFZNUzczMl9EQ0wgVjMuMCAgICAgICAgICBERUMgQVhQVk1TIENPQlJUTCBWL Mi43LTYwM0INCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL ICAgICAgICAgICAgICBERUMgQVhQVk1TIFZNUzczMl9EUklWRVIgVjIuMCAgICAgICBERUMgQVhQL Vk1TIERFQ05FVF9PU0kgVjcuMy0yDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL ICAgICAgICAgICAgICAgICAgICAgICAgICAgREVDIEFYUFZNUyBWTVM3MzJfR1JBUEhJQ1MgVjMuL MCAgICAgREVDIEFYUFZNUyBERlUgVjIuNy1BDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgL ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgREVDIEFYUFZNUyBWTVM3MzJfSU9HRU4gL VjEuMCAgICAgICAgREVDIEFYUFZNUyBEV01PVElGIFYxLjMtMQ0KICAgICAgICAgICAgICAgICAgL ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERFQyBBWFBWTVMgVk1TL NzMyX0pPQkNUTCBWMS4wICAgICAgIERFQyBBWFBWTVMgT1BFTlZNUyBWNy4zLTINCiAgICAgICAgL ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBERUMgL QVhQVk1TIFZNUzczMl9NQU5BR0UgVjMuMCAgICAgICBERUMgQVhQVk1TIFRDUElQIFY1LjQtMTUNL CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL ICAgICBERUMgQVhQVk1TIFZNUzczMl9QQ1NJIFYxLjAgICAgICAgICBIUCBBWFBWTVMgS0VSQkVSL T1MgVjIuMC02DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL ICAgICAgICAgICAgICAgREVDIEFYUFZNUyBWTVM3MzJfU1lTIFY3LjANCiAgICAgICAgICAgICAgL ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBERUMgQVhQVk1TL IFZNUzczMl9VUERBVEUgVjQuMA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL ICAgICAgICAgICAgICAgICAgICAgICAgIERFQyBBWFBWTVMgVk1TNzMyX1ZFUklGWSBWMS4wDQpEL RUMgVk1TIEFWQUlMX01BTiBWMi4zICAgICAgICAgICAgICBGdWxsIExQICAgICBJbnN0YWxsZWQNL CkhQIEFYUFZNUyBLRVJCRVJPUyBWMi4wLTYgICAgICAgICAgIEZ1bGwgTFAgICAgIEluc3RhbGxlL ZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBERUMgQVhQVk1TIE9QRU5WL TVMgVjcuMy0yDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAtLS0tLS0tLS0tL LSAtLS0tLS0tLS0tLS0gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gLS0tLS0tL LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiANCjE0IGl0ZW1zIGZvdW5kDQogDQpWTVNJL TlNUQUwgaGlzdG9yeSBmaWxlIERJU0skT1ZNUzczMVIyOltWTVMkQ09NTU9OLl1bU1lTVVBEXVZNL U0lOU1RBTC5ISVNUT1JZOzEgY29udGFpbnMgYWRkaXRpb25hbCBpbmZvcm1hdGlvbg0KWFNFUlZF Uj4=  ) ------_=_NextPart_001_01C59E9A.9AB538F1--    ------------------------------  % Date: Thu, 11 Aug 2005 10:11:19 -0400  From: norm.raphael@metso.comC Subject: Re: Mark Hurd to be keynote speaker at HP Technology Forum Q Message-ID: <OFE3DEB81D.765669B9-ON8525705A.004DC261-8525705A.004DF129@metso.com>   I David J Dachtera <djesys.nospam@comcast.net> wrote on 08/10/2005 10:06:35  PM:   
 > Z wrote: > >  > > leslie wrote: E > > > Maybe in the top 5, but the top CEO honor goes to Malden Mills'  former > > > CEO, Aaron Feuerstein: > > > 1 > > >    http://sitesearch.washingtonpost.com/wp- # > dyn/articles/A3963-2001Dec19.html = > > >    A CEO Who Lives by What's Right (washingtonpost.com)  > > >  > > >   "By Mary McGrory. > > >    Thursday, December 20, 2001; Page A03 > > > J > > >    In this anxious hour of pink-slip dread, it is restoring to think ofF > > >    Aaron Feuerstein, a Massachusetts manufacturer who prizes his5 > > >    employees and risks profits on their behalf.  > > > G > > >    The CEO of Malden Mills, located in Lawrence, the 23rd poorest I > > >    community in the country, stepped clear of the greedy stereotype  ofI > > >    his kind in 1995 when, just before Christmas, his factory burned  down. J > > >    Rather than taking the insurance money and retiring or moving theI > > >    plant to some Third World country, he promptly announced that he  would F > > >    rebuild. He gave bonuses to the help and paid them while they waited& > > >    for the factory reopening..." > > K > > That act of generosity cost Malden Mills $100M and was a big reason why - > > the company filed for bankruptcy in 2001.  > > I > > Mr Feuerstein was generous, but foolish, and certainly not a top CEO. I > > Top CEOs don't ruin their companies by giving employees money for not  > > working. > H > If it comes down to a choice of investors posting a loss against theirJ > taxable income or several hundred (or even thousand) employees and theirC > families being ruined financially due to a situation beyond human & > control, I know what I would choose. > % > Your mileage may vary, of course...   F Maybe not a "top CEO," but certainly a great man.   I vote with David.  6 "Be sure you're right, then go ahead." -Davey Crockett   -Norm    >  > -- > David J Dachtera > dba DJE Systems  > http://www.djesys.com/ > + > Unofficial OpenVMS Hobbyist Support Page: $ > http://www.djesys.com/vms/support/ > * > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/  > $ > Unofficial OpenVMS-IA32 Home Page:! > http://www.djesys.com/vms/ia32/  >  > Coming soon:( > Unofficial OpenVMS Marketing Home Page   ------------------------------  % Date: Thu, 11 Aug 2005 11:47:06 -0400 ' From: Dave Froble <davef@tsoft-inc.com> C Subject: Re: Mark Hurd to be keynote speaker at HP Technology Forum 0 Message-ID: <11fmsg0mmh6p9ce@corp.supernews.com>   David J Dachtera wrote: 
 > Z wrote: >  >>leslie wrote:  >>I >>>Maybe in the top 5, but the top CEO honor goes to Malden Mills' former  >>>CEO, Aaron Feuerstein:  >>> O >>>   http://sitesearch.washingtonpost.com/wp-dyn/articles/A3963-2001Dec19.html : >>>   A CEO Who Lives by What's Right (washingtonpost.com) >>>  >>>  "By Mary McGrory + >>>   Thursday, December 20, 2001; Page A03  >>> J >>>   In this anxious hour of pink-slip dread, it is restoring to think ofC >>>   Aaron Feuerstein, a Massachusetts manufacturer who prizes his 2 >>>   employees and risks profits on their behalf. >>> D >>>   The CEO of Malden Mills, located in Lawrence, the 23rd poorestI >>>   community in the country, stepped clear of the greedy stereotype of L >>>   his kind in 1995 when, just before Christmas, his factory burned down.G >>>   Rather than taking the insurance money and retiring or moving the L >>>   plant to some Third World country, he promptly announced that he wouldJ >>>   rebuild. He gave bonuses to the help and paid them while they waited# >>>   for the factory reopening..."  >>I >>That act of generosity cost Malden Mills $100M and was a big reason why + >>the company filed for bankruptcy in 2001.  >>G >>Mr Feuerstein was generous, but foolish, and certainly not a top CEO. G >>Top CEOs don't ruin their companies by giving employees money for not 
 >>working. >  > H > If it comes down to a choice of investors posting a loss against theirJ > taxable income or several hundred (or even thousand) employees and theirC > families being ruined financially due to a situation beyond human & > control, I know what I would choose. > % > Your mileage may vary, of course...  >   G I don't know what happened to the company, or the employees, after the  H company filed for bankrupcy, but, many times this causes the jobs to go < away.  Would this be any less devastating for the employees?  D Basically, I applaud the man.  He placed the people higher than the H allmighty dollar.  However, there is reality.  Perhaps he was a bit too C generous.  Perhaps a combination of company and outside aid, while  I saving enough to allow the company to proceed into the future would have  I been more prudent.  Perhaps the bankrupcy would have happened eventually  F due to cheaper compitition.  Perhaps.  Regardless, the man considered G the employees his responsibility, as they were, and acted accordingly.  F This can not be taken away from him, even if he was less than prudent.  C A far cry from those who would plunder the company pension fund to   satisfy their personal greed.    --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Thu, 11 Aug 2005 11:59:47 -0400 ( From: Bill Todd <billtodd@metrocast.net>C Subject: Re: Mark Hurd to be keynote speaker at HP Technology Forum = Message-ID: <SIOdneeSXPBp6GbfRVn-2w@metrocastcablevision.com>    Dave Froble wrote:   ...   F > Basically, I applaud the man.  He placed the people higher than the J > allmighty dollar.  However, there is reality.  Perhaps he was a bit too E > generous.  Perhaps a combination of company and outside aid, while  K > saving enough to allow the company to proceed into the future would have  K > been more prudent.  Perhaps the bankrupcy would have happened eventually  H > due to cheaper compitition.  Perhaps.  Regardless, the man considered I > the employees his responsibility, as they were, and acted accordingly.  H > This can not be taken away from him, even if he was less than prudent. > E > A far cry from those who would plunder the company pension fund to   > satisfy their personal greed.   G Couldn't have said it better myself.  Monday-morning quarterbacking is  F easy (and worth every penny people get paid for it - save perhaps for F the 'analysts'...).  The incontrovertible fact is that Feuerstein had F his priorities straight - in the best tradition of the way capitalism G works when it works best for the long term rather than the short buck.  I Whether he applied them optimally to the situation as it stood back then  A and could reasonably have been expected to develop is not likely  / anything anyone here has any real insight into.    - bill   ------------------------------    Date: 11 Aug 2005 09:56:51 -0700  From: njklostermann@cbegroup.com Subject: Moving System Disk C Message-ID: <1123779411.691829.186070@g43g2000cwa.googlegroups.com>   @ We are moving from an ES40 with a local system disk and many SANE attached disks to a GS80 with a local system disk that will attach to G the same SAN disks the ES40 currently attaches to, after the migration. G  Both are running VMS 7.3-2.  What is the preferred method of migrating C the system disk to the new server?  Should I create an image of the E ES40 system disk and simply restore it to the GS80 disk?  What is the E best method of doing this considering I have intermediate VMS skills?    Thanks -   ------------------------------    Date: 11 Aug 2005 01:22:25 -0700' From: "saee" <aditi.hatwalne@gmail.com>   Subject: Problem deleting memoryC Message-ID: <1123748544.993965.221690@z14g2000cwz.googlegroups.com>    Hi,   E My application has 2-3 processes.One of these processes creates block  data files. A (created with sys$create,mapped by crmpsc and then UPDSECW)Memory ! mapped is deallocated every time. ? Now I stop my application..all processes are stopped. I restart B application, now other process opens these files with sys$open andE crmpsc call.(at this time no other process is accessing these files)I @ just check some variable from file and then deallocate memory by= sys$delva and sys$dgblsc calls.Memory is not getting properly G deleted.Instead of reusing memory ,It is allocating new memory for each & file.Do I need to do some more things?   TIA, Adt    ------------------------------    Date: 11 Aug 2005 07:59:57 -0500 From: briggs@encompasserve.org$ Subject: Re: Problem deleting memory3 Message-ID: <ouxT38c2SuLl@eisner.encompasserve.org>   m In article <1123748544.993965.221690@z14g2000cwz.googlegroups.com>, "saee" <aditi.hatwalne@gmail.com> writes:  > Hi,  > G > My application has 2-3 processes.One of these processes creates block 
 > data files. C > (created with sys$create,mapped by crmpsc and then UPDSECW)Memory # > mapped is deallocated every time. A > Now I stop my application..all processes are stopped. I restart D > application, now other process opens these files with sys$open andG > crmpsc call.(at this time no other process is accessing these files)I B > just check some variable from file and then deallocate memory by? > sys$delva and sys$dgblsc calls.Memory is not getting properly I > deleted.Instead of reusing memory ,It is allocating new memory for each ( > file.Do I need to do some more things?   The explanation is unclear.   H At first it seems that you have stopped your application and stopped all its processes.  A Then you talk about using SYS$DELVA and SYS$DGBLSC and not having H memory released -- apparently in the context of a process that continues running your application.   F Which is it?  Does your application executable keep running or are you+ doing image rundown between each iteration?   * Assuming that the program keeps running...  D Obviously the first thing to check is the return status on SYS$DELVAC and SYS$DGBLSC and the order in which they are called.  Also, check ' the retadr range returned by SYS$DELVA.   E The next thing to look at is your SYS$CRMPSC call.  I suspect that if D you are specificying the EXPREG flag that it will ignore the virtualE address range that you have deleted and allocate fresh address space. A On VAX, at least, there is a distinction between deleting address  space and shrinking P0 space.   D When you delete the address space the page table entries still existA but are set to report "no such page".  I don't think there is any ? special code to update P0LR or its equivalent on Alpha when the 5 deleted address space is at the high end of P0 space.   C Prior to the mapping of the section, the page table entries did not C even exist.  They were out past the end of your allocated P0 space.   E If this suspicion is correct, it is up to you as a programmer to keep C track of the virtual address range(s) that you have mapped and then E deleted so that you can map them again later, leaving the EXPREG flag & off of all but the first $CRMPSC call.   	John Briggs   ------------------------------    Date: 11 Aug 2005 05:09:16 -0700% From: "Erik" <erik_g@abri.une.edu.au> - Subject: Problem printing binary image files. C Message-ID: <1123762156.692911.172610@o13g2000cwo.googlegroups.com>   E We have files of images in Epson graphics format, which we are trying  toD print to an Epson DFX-5000 dot matrix (either on the DS10's parallel port -F LRA0:, or via the LPD print symbiont). When the files are smaller than 32K E bytes, they print okay ... but when they are larger than 32K bytes it  appears G that some bytes go astray, and the printing of the image goes awry. The  files F are just a stream of bytes containing Epson print control and graphicsG commands, there are no line feeds or separate records, just a stream of  say 8 40000 bytes. Extract of DIR/FULL showing relevant parts: File organization:  SequentialE File attributes:    Allocation: 81, Extend: 0, Global buffer count: 0 $                     Version limit: 0? Record format:      Undefined, maximum 0 bytes, longest 0 bytes  Record attributes:  None RMS attributes:     None  7 VMS appears not to like data in chunks larger than 32K. G Does anybody have any idea how to deal with these files successfully on  VMS?: (Linux and Windows manage to print them without problems).   Thanks,  Erik Ahlefeldt.    ------------------------------    Date: 11 Aug 2005 08:01:14 -0700 From: dooleys@snowy.net.au1 Subject: Re: Problem printing binary image files. C Message-ID: <1123769098.578607.273670@z14g2000cwz.googlegroups.com>    You could try...9 just copying the file to the device eg. copy <file> LRA0: @ or set up a telnet queue for the device with a "passall" setting7 (you will have to read the ucx/tcpip manual to do this)  Phil   ------------------------------  % Date: Thu, 11 Aug 2005 06:27:30 -0400 * From: "M Baechtel" <mbaechtel@comcast.net>$ Subject: Re: Storage shelf questions0 Message-ID: <hvSdncGN6POItWbfRVn-pw@comcast.com>  5 70-31490-01 is a BA35X-MH 16-BIT ULTRA WIDE PERSL MOD - see the KZPCM-DA works with DS-RZ1DF-VW disks 4 http://goldeneggs.spyderbyte.com/geggs/GTAU121PF.pdf  H The KZPSA will not work with that disk it can only address 9.1GB unless ' there a newer flash I don't know about.   2 "H Vlems" <nospam@what.ever.com> wrote in message 6 news:af074$42e3df69$513b9a2c$15520@news.versatel.nl...8 > The storgae shelf in question is labeled : DS-BA356-JDD > I got it together with two separately shipped personality modules:C > 70-31490-01 (no other part no on the label) with two 68 pin SCSI   > connectors? > 70-33067-02 or DS-BA35X-FA with one very small SCSI connector  >  > Questions:A > 1) does the shelf accept disks like the DS-RZ1DF-VW and/or the   > DS-RZ1CB-VW?B > 2) the 70-31490-01 has one bank of dip switches. I'm looking for > documentation J > 3) the DS-BA35X-FA has two sets of dip switches, need documentation for  > this > unit as wellH > 4) the $64000 question (:-): is this combination going to work with a  > KZPSA  > or KZPCM-Dx adapter? >  > Hans Vlems >  >    ------------------------------  % Date: Thu, 11 Aug 2005 09:49:49 -0400 6 From: Brad Hamilton <brMadAhamPiltSon@coMmcaAstP.neSt> Subject: Re: [OT] Zip 2.3-1)E Message-ID: <JemdnZ2dnZ1DBcyNnZ2dneDKZt-dnZ2dRVn-zZ2dnZ0@comcast.com>    Steven M. Schweda wrote:8 > From: Brad Hamilton <brMadAhamPiltSon@coMmcaAstP.neSt> <snip>F >    In spite of that, and assuming that you aren't trying to do largeJ > files on a VAX, you should be able to find the latest official beta kits > under: > 4 >       ftp://ftp.info-zip.org/pub/infozip/OLD/beta/ >   * Thanks for the pointer; I'm trying it now.   --   Bradford J. Hamilton "All opinions are my own" * "Lose the MAPS, and replace '-at-' with @"   ------------------------------   End of INFO-VAX 2005.446 ************************                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        