1 INFO-VAX	Tue, 22 Jul 2003	Volume 2003 : Issue 401       Contents:5 Re: BACKUP/IGNORE=INTERLOCK (was: Re: OpenVms Backup) 5 Re: BACKUP/IGNORE=INTERLOCK (was: Re: OpenVms Backup) 6 Re: Compaq Solutions Aliance - Do it still existing  ?  Re: Custom Separator Page [DCPS] Re: DHCP startup problems  Re: DHCP startup problems  Re: DHCP startup problems  digital 533au memory% Re: dismounting disks during shutdown  Re: Does anyone remember IAS? G Re: Does RT-11 run on the PDP-11/70?  (was Re: PDP-11 OS Release Dates) F Re: Does RT-11 run on the PDP-11/70? (was Re: PDP-11 OS Release Dates)F Re: Does RT-11 run on the PDP-11/70? (was Re: PDP-11 OS Release Dates) Re: duplicating system disks Re: Getting rid of DECwindows?+ Re: HP World: Why Alpha's Omega Makes Sense + Re: HP World: Why Alpha's Omega Makes Sense + Re: HP World: Why Alpha's Omega Makes Sense + Re: HP World: Why Alpha's Omega Makes Sense + Re: HP World: Why Alpha's Omega Makes Sense # Re: Mozilla... the new NULL process # Re: Mozilla... the new NULL process # Re: Mozilla... the new NULL process 2 Non-OpenVMS ethernet access to Printserver 17/600?6 Re: Non-OpenVMS ethernet access to Printserver 17/600?/ Re: Obsolete cross compilers: where did you go? / Re: Obsolete cross compilers: where did you go? / Re: Obsolete cross compilers: where did you go?  Re: OpenVms Backup Re: OpenVms Backup Re: OpenVms Backup Re: OpenVms Backup Re: OpenVms Backup Re: OpenVms Backup Re: OpenVms Backup Re: OpenVms Backup/ Re: OpenVMS Technical Seminar Highlights (some)  Re: PDP-11 OS Release Dates  Re: PDP-11 OS Release Dates  Re: PDP-11 OS Release Dates P Re: Redirecting screen output from FMS to files and displaying them using an emu1 TCPIP V5.3 Anonymous FTP - More control possible?   Re: Update VMS731_CDRECORD-V0100, Re: VAT for non-EU suppliers to EU customers( Re: [NETBEANS34_1] installation troubles  F ----------------------------------------------------------------------  # Date: Mon, 21 Jul 2003 21:37:20 GMT # From: hoff@hp.nospam (Hoff Hoffman) > Subject: Re: BACKUP/IGNORE=INTERLOCK (was: Re: OpenVms Backup)0 Message-ID: <k2ZSa.545$Qb1.117@news.cpqcorp.net>  a In article <EeB0mFx4f4af@malvm7.mala.bc.ca.>, nothome@spammers.are.scum (Malcolm Dunnett) writes: 1 :In article <KyWSa.521$5X.420@news.cpqcorp.net>,  : :    hammond@not@peek.ssr.hp.com (Charlie Hammond) writes: :  :>  M :> In a production environment, a backup strategy that uses /INGORE=INTERLOCK  :> is bogus.  Period.  :  :    That seems a bit extreme.    J   All recent OpenVMS System Management Utilities manuals clearly flag the H   possibility of file data inconsistencies with BACKUP/IGNORE=INTERLOCK.J   Check the manual, and specifically the documentation around the keyword.  H   The interlocks that are being ignored were implemented for a reason --J   there are folks that assume they know what BACKUP/IGNORE=INTERLOCK does,J   and don't understand the implementation nor fully realize the risks, andM   particularly don't consider the meaning of the interlocks.  (Some platforms L   avoid this situation by not bothering with file-level interlocks.  OpenVMSI   chooses the cautious course, and blocks these "corruptable" file-access    collisions.)  * :What about the case of an Oracle databaseD :where one wants to do a "hot backup". Of course one needs to followF :all Oracle's instructions about using ARCHIVELOG mode and setting theG :tablespaces in BACKUP mode, but given all that it's still necessary to ; :use /IGN=INTERLOCK to actually copy the "hot" tablespaces.   E   Please check with Oracle -- if Oracle is willing to assure you that G   there is nothing in cache and everything is out on disk on this, then G   the /IGNORE=INTERLOCK might well produce the desired results.  (While F   I'd not generally expect a consistent file to be locked, there couldG   well be application-specific reason(s) to keep a lock on a file that  %   is consistent.  I don't know that.)   C   Oracle Rdb certainly knows how to do this with the RMU tool, and  C   entirely avoids the requirements for /IGNORE=INTERLOCK.  Once Rdb D   tosses the data out, the resulting RMU/BACK archive files can then   be run through BACKUP.  C :    What about the case where it's files such as PAGEFILE.SYS that F :are open, but they're marked "NOBACKUP" anyway - there's no danger inI :saving the information needed to re-create the file, but it will fail if B :/IGN=INTERLOCK isn't used ( or at least that seems to be the case :based on this thread ).  A   For specific files, the contents are not required and thus the  E   interlocks are not relevent -- more often than not, you are correct /   and these files can also be marked /NOBACKUP.   K :    In many other cases there may be a potential for some "lost" data, but H :it may be inconsequential ( YMMV ). For example, I don't really care ifO :I'm missing a few entries from OPERATOR.LOG or ERRLOG.SYS when I do an on-line M :image backup of a system disk. I expect that the queue database may not copy K :correctly ( so one may need to recreate entries manually ). I know there's K :an (extremely remote) chance that SYSUAF.DAT could end up with a corrupted N :bucket ( bucket check failure ). Since I do an image backup of my system diskK :every day and keep several weeks of history I should be able to restore an Q :earlier version of SYSUAF.DAT in that case ( there's virtually no chance they'll  :all be corrupted ).  F   Remove the blade-guards at your risk.  SYSUAF, RIGHTSLIST, the queue>   files, and any open files can potentially have cached data.   C   The requirement for standalone BACKUP or the bootable environment E   when the operating system system disk is involved has been in place B   for as long as I can remember -- and for just the reasons we are   discussing here.  N :    I understand why the safe thing to say is that "/IGN=INTERLOCK is bogus",O :but it would be more useful if HP accepted that most of us who run VMS systems G :run them in a 24x7 environment, and shutting down every day to back up L :disks isn't an option. What we really need is to fully understand the risksI :of IGN=INTERLOCK and design backup procedures to mitigate them ( even if O :they can't be completely eliminated ). A full explanation of how IGN=INTERLOCK M :works and how it interacts with things like file caching would be a lot more - :helpful than a simple warning to not use it.   G   Interlocks are put in place to keep the visible file data consistent, G   and to provide a mechanism to indicate and prevent access collisions. H   When interlocks are ignored, the OpenVMS BACKUP utility may or may notB   flag these collisions, and may or may not copy consistent data.   L   The recommendation is to incorporate the interlocks and the on-line BACKUPL   support processing at least partially into the application -- applicationsJ   that operate continuously have constraints that traditional applicationsM   tend not to have, including file version number maintenance and, obviously, K   BACKUP support.  There are documentation updates queued in this area, and J   yes, having more details on how to interlock access would be useful -- aJ   set of updates with details on /IGNORE=INTERLOCK are queued for existingJ   OpenVMS manuals, and will appear as these manuals are opened and updatedK   for releases.  (That said, there is extensive documentation on file-level L   operations and locking available within the OpenVMS documentation set, andI   there are products and approaches which can provide on-line operations. *   Rdb, RTR, existing RMS operations, etc.)  K   AFAIK, there is no way to use /IGNORE=INTERLOCK with complete safety save G   on data you don't care about -- and then, why bother with the BACKUP? I   The application must be involved within its own BACKUP (or BACKUP-like) F   operations, or the application must be (able to be) quiesced, or theG   application must be shut down, or you must be using something akin to I   Rdb or distributed capabilities.  One of the obvious options (within an I   application) is to use the BACKUP callable API, either directly or with D   metadata or specific extensions.  Or to provide a way to flush theE   cached data out pending a BACKUP operation, possibly via a nudge or ;   an application-specific BACKUP checkpoint operation, etc.   F   Yes, BACKUP/IGNORE=INTERLOCK usually works, and the data on the diskC   is usually consistent.  The cost of ensuring complete consistency D   within the archived application data might well be prohibitive, orB   it might not be economical.  Or the data involved might well be    recoverable.  Etc.  C   AFAIK, any operating system that provides on-line BACKUP involves B   the application either directly or through the use of a database@   or similar API, and OpenVMS certainly follows this model.  TheA   APIs and tools are available, as are database and like options.   N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------E         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com    ------------------------------  # Date: Tue, 22 Jul 2003 02:07:56 GMT  From: Rob.Buxton@wcc.govt.nz> Subject: Re: BACKUP/IGNORE=INTERLOCK (was: Re: OpenVms Backup)$ Message-ID: <3f1c9a2d.81720671@news>  F On Mon, 21 Jul 2003 21:37:20 GMT, hoff@hp.nospam (Hoff Hoffman) wrote:  b >In article <EeB0mFx4f4af@malvm7.mala.bc.ca.>, nothome@spammers.are.scum (Malcolm Dunnett) writes:2 >:In article <KyWSa.521$5X.420@news.cpqcorp.net>, ; >:    hammond@not@peek.ssr.hp.com (Charlie Hammond) writes:  >: >:> N >:> In a production environment, a backup strategy that uses /INGORE=INTERLOCK >:> is bogus.  Period. >:  >:    That seems a bit extreme.  > K >  All recent OpenVMS System Management Utilities manuals clearly flag the  I >  possibility of file data inconsistencies with BACKUP/IGNORE=INTERLOCK. K >  Check the manual, and specifically the documentation around the keyword.  > I >  The interlocks that are being ignored were implemented for a reason -- K >  there are folks that assume they know what BACKUP/IGNORE=INTERLOCK does, K >  and don't understand the implementation nor fully realize the risks, and N >  particularly don't consider the meaning of the interlocks.  (Some platformsM >  avoid this situation by not bothering with file-level interlocks.  OpenVMS J >  chooses the cautious course, and blocks these "corruptable" file-access >  collisions.)  > + >:What about the case of an Oracle database E >:where one wants to do a "hot backup". Of course one needs to follow G >:all Oracle's instructions about using ARCHIVELOG mode and setting the H >:tablespaces in BACKUP mode, but given all that it's still necessary to< >:use /IGN=INTERLOCK to actually copy the "hot" tablespaces. > F >  Please check with Oracle -- if Oracle is willing to assure you thatH >  there is nothing in cache and everything is out on disk on this, thenH >  the /IGNORE=INTERLOCK might well produce the desired results.  (WhileG >  I'd not generally expect a consistent file to be locked, there could H >  well be application-specific reason(s) to keep a lock on a file that & >  is consistent.  I don't know that.) > D >  Oracle Rdb certainly knows how to do this with the RMU tool, and D >  entirely avoids the requirements for /IGNORE=INTERLOCK.  Once RdbE >  tosses the data out, the resulting RMU/BACK archive files can then  >  be run through BACKUP.  > D >:    What about the case where it's files such as PAGEFILE.SYS thatG >:are open, but they're marked "NOBACKUP" anyway - there's no danger in J >:saving the information needed to re-create the file, but it will fail ifC >:/IGN=INTERLOCK isn't used ( or at least that seems to be the case  >:based on this thread ).  > B >  For specific files, the contents are not required and thus the F >  interlocks are not relevent -- more often than not, you are correct0 >  and these files can also be marked /NOBACKUP. > L >:    In many other cases there may be a potential for some "lost" data, butI >:it may be inconsequential ( YMMV ). For example, I don't really care if P >:I'm missing a few entries from OPERATOR.LOG or ERRLOG.SYS when I do an on-lineN >:image backup of a system disk. I expect that the queue database may not copyL >:correctly ( so one may need to recreate entries manually ). I know there'sL >:an (extremely remote) chance that SYSUAF.DAT could end up with a corruptedO >:bucket ( bucket check failure ). Since I do an image backup of my system disk L >:every day and keep several weeks of history I should be able to restore anR >:earlier version of SYSUAF.DAT in that case ( there's virtually no chance they'll >:all be corrupted ).  > G >  Remove the blade-guards at your risk.  SYSUAF, RIGHTSLIST, the queue ? >  files, and any open files can potentially have cached data.   > D >  The requirement for standalone BACKUP or the bootable environmentF >  when the operating system system disk is involved has been in placeC >  for as long as I can remember -- and for just the reasons we are  >  discussing here.  > O >:    I understand why the safe thing to say is that "/IGN=INTERLOCK is bogus", P >:but it would be more useful if HP accepted that most of us who run VMS systemsH >:run them in a 24x7 environment, and shutting down every day to back upM >:disks isn't an option. What we really need is to fully understand the risks J >:of IGN=INTERLOCK and design backup procedures to mitigate them ( even ifP >:they can't be completely eliminated ). A full explanation of how IGN=INTERLOCKN >:works and how it interacts with things like file caching would be a lot more. >:helpful than a simple warning to not use it. > H >  Interlocks are put in place to keep the visible file data consistent,H >  and to provide a mechanism to indicate and prevent access collisions.I >  When interlocks are ignored, the OpenVMS BACKUP utility may or may not C >  flag these collisions, and may or may not copy consistent data.   > M >  The recommendation is to incorporate the interlocks and the on-line BACKUP M >  support processing at least partially into the application -- applications K >  that operate continuously have constraints that traditional applications N >  tend not to have, including file version number maintenance and, obviously,L >  BACKUP support.  There are documentation updates queued in this area, andK >  yes, having more details on how to interlock access would be useful -- a K >  set of updates with details on /IGNORE=INTERLOCK are queued for existing K >  OpenVMS manuals, and will appear as these manuals are opened and updated L >  for releases.  (That said, there is extensive documentation on file-levelM >  operations and locking available within the OpenVMS documentation set, and J >  there are products and approaches which can provide on-line operations.+ >  Rdb, RTR, existing RMS operations, etc.)  > L >  AFAIK, there is no way to use /IGNORE=INTERLOCK with complete safety saveH >  on data you don't care about -- and then, why bother with the BACKUP?J >  The application must be involved within its own BACKUP (or BACKUP-like)G >  operations, or the application must be (able to be) quiesced, or the H >  application must be shut down, or you must be using something akin toJ >  Rdb or distributed capabilities.  One of the obvious options (within anJ >  application) is to use the BACKUP callable API, either directly or withE >  metadata or specific extensions.  Or to provide a way to flush the F >  cached data out pending a BACKUP operation, possibly via a nudge or< >  an application-specific BACKUP checkpoint operation, etc. > G >  Yes, BACKUP/IGNORE=INTERLOCK usually works, and the data on the disk D >  is usually consistent.  The cost of ensuring complete consistencyE >  within the archived application data might well be prohibitive, or C >  it might not be economical.  Or the data involved might well be   >  recoverable.  Etc.  > D >  AFAIK, any operating system that provides on-line BACKUP involvesC >  the application either directly or through the use of a database A >  or similar API, and OpenVMS certainly follows this model.  The B >  APIs and tools are available, as are database and like options. > O > ---------------------------- #include <rtfaq.h> ----------------------------- L >    For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faqO > --------------------------- pure personal opinion --------------------------- F >        Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com > 7 But in all of this there is one inherant contradiction.   F Typically System Admins choose one of a couple of options when backing up their System Disks. Use Ignore=Interlock2 or Drop a Member of a shadow set and back that up.  E Neither option is fully supported, standalone / offline backup is the F generally recognised supported backup methodology for the System Disk.9 Alas, that kind of flies in the face of 24 x 7, hence the C contradiction. VMS is high availability, but if you want to back up > the system disk you have to take it down! Sorry but you can't.  D There are other options but they're not obvious and I was alerted toA many by the paper John Gillings did in the VMS Technical Journal.  So, I use a merry mixture. Drop a member of a shadow set.D Use Convert/share to take copies of my queue and authorisation filesE (they're not on the System Disk anyway) and secure those with Backup. ! And hope it doesn't come to that! F Now compared to some I'm a newcomer, only been involved with VMS since2 4.4, but I've never had to recover a System Disk. C Re-built plenty but never had need of a restore. I guess that comes ; down to the robustness of the OS, HBVS and the File System.    ------------------------------  % Date: Mon, 21 Jul 2003 15:33:30 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>? Subject: Re: Compaq Solutions Aliance - Do it still existing  ? ) Message-ID: <3F1C4005.A5228D90@istop.com>    Paul Sture wrote: G > A case in point: I received an email on this VMS system containing an E > RTF file as an attachment. I successfully used MIME (ugh) to detach ' > it but the result was downright ugly.   @ $convert/document thefile.rtf/format=rtf thefile.txt/format=text  6 Or, if you want to preserve the formating information:  J $convert/document thefile.rtf/format=rtf thefile.ddif/format=ddif and then* type the file, or use decwrite to edit it.   ------------------------------    Date: 21 Jul 2003 20:37:13 -0700$ From: tpercy23@hotmail.com (BigBarr)) Subject: Re: Custom Separator Page [DCPS] = Message-ID: <421ab8b7.0307211937.4d9caaf9@posting.google.com>   g Paul Anderson <paul.anderson@hp.com> wrote in message news:<210720031318425861%paul.anderson@hp.com>... G > In article <421ab8b7.0307191127.46970e1f@posting.google.com>, BigBarr  > <tpercy23@hotmail.com> wrote:  > D > > I have created a custom separator page that I would like printedG > > before each print job. My queues are already set to use a form with  > > the /setup= qualifier.I > > My question is how do I set the flag page to use the custom separator B > > page? I can set the flag in the dcps$startup.com but I get theJ > > standard flag page printed. I'm sure this is a simple task, but I am a; > > beginner and I do not have any documentation available.  > I > The DCPS flag page is module LPS$$SYSTEMPAGES in the DCPS$DEVCTL device I > control library.  You might want to create a new library, put it before G > DCPS$DEVCTL in the DCPS_LIB searchlist and put your own page in there  > as LPS$$SYSTEMPAGES. > C > DCPS passes variable data into LPS$$SYSTEMPAGES so each flag page I > contains information such as user name and queue information.  It might ? > be easy for a static separator page, but getting that type of A > information printed on your page might be a little more tricky, E > involving, as John Malmberg pointed out, some PostScript knowledge.  > H > There is no supported way to change the flag page in this way.  You're1 > on your own, but others have certainly done it.  >  > Paul  B Thanks for helping!  My postscript flag page prints only username,A jobid, date and queue as opposed to the default flag.  I followed B until "put your own page in there as lps$$systempages".  Could youD please be more specific?  These are the steps I have taken to createF and use a form.  Can I use the same for setting up a custom flag page?  C 1.  In DCPS$STARTUP I added PS1/DATA=POST and FORM_MOUNTED=formname   C Define/system/executive/nolog dcps_lib dcps$devctl, "PS1/DATA=POST" < /default=feed/FORM_MOUNTED=DRAFT/DEFAULT=(FORM=DRAFT,NOFEED)  & 2.  Create PS1.tlb and inserted DRAFT.% 3.  Stop/delete and run DCPS$STARTUP.    ------------------------------  % Date: Mon, 21 Jul 2003 17:48:50 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>" Subject: Re: DHCP startup problems) Message-ID: <3F1C5FB4.50AD154B@istop.com>    Michael Austin wrote: E > IMHO, DHCP is for toy computers.  And since I have servers that are F > dependent upon knowing the IP address to be able to connect to theseH > services... I find it much simpler to just set it and be done with it.  J DHCP can provide far more than just an IP address. It provides adresses ofG DNS, gateway (default route), SMTP server, POP server. IMAP server, LPD J servers and a whole gamut of options that can be transmited as part of the DHCP offer.   K If you have a large network, it makes applying changes far easier since you L know that every X hours (half leases), all machines will check with the DHCPN server to renew the leases, at which point changed parameters get implemented.  M Whether the VMS DHCP client actually does anything with more than just the IP 2 address, I don't know. But the potential is there.   ------------------------------  % Date: Mon, 21 Jul 2003 17:35:24 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>" Subject: Re: DHCP startup problems) Message-ID: <3F1C5C8E.61F4A422@istop.com>     Peter 'EPLAN' LANGSTOEGER wrote:J > 1) What you found. You won't get a lease, if you start DHCP client afterN > DECnet (or LAT, which has DECnet comptible addresses as default). I "solved"N > it, by starting TCPIP in SYSMAN (CONFIG phase) _before_ DECnet gets started.  > Remember that DHCP is very dependant on the ethernet address.   N It sends a broadcast on the ether stating "hi, I am aa-bb-cc-dd-ee-ff, with ip4 address 0.0.0.0, can some DHCP make me any offers ?"  J DHCP servers then respond by sending packets to that ethernet address. TheK client then sends a confirmation to one of the servers which will then send N the full package (DHCP response with all the option) to the client, confirming a lease etc etc.  E I recall looking into this last year or 2 years ago, and perhaps Hoff N providing some code to get the real hardware address of an interface with some
 QIO calls.  I Perhaps the DHCP client software obtains the real hardware address of the N ethernet interface instead of acquiring the functional one (eg: the one set byK decnet), and the "respond to" address included inside the DHCP request then I doesn't match the decnet-set address that the interface is listening for.    ------------------------------  # Date: Mon, 21 Jul 2003 22:28:49 GMT < From: "John E. Malmberg" <Malmberg@dskwld.zko.dec.compaq.hp>" Subject: Re: DHCP startup problems0 Message-ID: <BOZSa.549$he1.383@news.cpqcorp.net>   JF Mezei wrote:  > Michael Austin wrote:  > E >>IMHO, DHCP is for toy computers.  And since I have servers that are F >>dependent upon knowing the IP address to be able to connect to theseH >>services... I find it much simpler to just set it and be done with it. >   L > DHCP can provide far more than just an IP address. It provides adresses ofI > DNS, gateway (default route), SMTP server, POP server. IMAP server, LPD L > servers and a whole gamut of options that can be transmited as part of the
 > DHCP offer.  > M > If you have a large network, it makes applying changes far easier since you N > know that every X hours (half leases), all machines will check with the DHCPP > server to renew the leases, at which point changed parameters get implemented. > O > Whether the VMS DHCP client actually does anything with more than just the IP 4 > address, I don't know. But the potential is there.  F I get the DNS servers, default gateway, domain name, and I.P. address = from the DHCP server.  I have not looked at the other things.   I There appears to be a way to tell the DHCP server what hostname you have  I so that it can update a DNS server.  I have not looked at how to do that   either.      -John ! malmberg@dskwld.zko.dec.compaq.hp  Personal Opinion Only    ------------------------------  # Date: Mon, 21 Jul 2003 21:16:58 GMT 4 From: "Phillip R Sobottke" <psobottke@ameritech.net> Subject: digital 533au memory @ Message-ID: <eLYSa.11771$Vx2.5624664@newssvr28.news.prodigy.com>  2 Is digital ultimate workstation memory registered?  + I want to know if I can use it in an XP1000    ------------------------------  % Date: Mon, 21 Jul 2003 22:58:55 +0100 - From: Gerald Marsh <gerald@cyfer.demon.co.uk> . Subject: Re: dismounting disks during shutdown8 Message-ID: <h4oohvs5pj2hfbg6o0ejt92undgls51609@4ax.com>  ? On Mon, 21 Jul 2003 00:12:43 GMT, Rob.Buxton@wcc.govt.nz wrote:   * >On Sun, 20 Jul 2003 15:38:28 +0000 (UTC),D >helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to >reply) wrote: > G >>What is the recommended procedure for dismounting (members of) shadow E >>sets which are mounted by more than one node and which have members F >>connected physically to more than one node?  Goal is to avoid (mini)J >>merges as much as possible.  Obviously, if one node goes down, taking a K >>member with it, but the other member is still mounted, then a merge will  K >>be necessary when the member rejoins.  But this won't be the case if all  C >>members dismount the shadow set first (which might not always be   >>desirable, of course). >>F >>It seems to me that in the site-specific shutdown procedure, a node K >>should DISMOUNT/SYSTEM all shadow sets and DISMOUNT/CLUSTER non-shadowed  K >>disks which might be mounted by other nodes.  That will leave only those  I >>physically connected disks which are parts of shadow sets mounted from  H >>another node.  Obviously, these will be dismounted in some sense when 5 >>the node shuts down, and a merge will be necessary.  >>J >>What will happen---what will get dismounted in what order---if there is , >>no site-specific dismounting taking place? >>I >>A related question: is it possible from one specific node to dismount a H >>disk on other nodes but not on the specific node in question (without  >>going through SYSMAN etc)? >>  G >I just let the OS remove the shadowsets when it's ready. What you need D >to do to avoid merges etc. is to ensure all applications with files >open are shut down.G >As part of my shutdown I do a show dev /files for each of the disks at " >the end of my shutdown procedure.F >If any of these are showing files open then I add additional shutdown >procedures to close them.  < I seem to remember that, in Host Based Volume Shadowing, theD CLUSTER_SHUTDOWN option does not dismount the disks cluster wide andD that was why we were having excessive shadow copies at startup time.  E I also recall that the option was not passed to SYSHUTDWN so we could  not take action there either.   @ As a result we had to resort to a system-wide logical (should beF cluster-wide now, I suppose) which dismounts all the shadowset membersE cluster wide when required. Damn pain to remember to define the thing  though!   F I do not have access the the system at the time of writing but I thinkE I used the system shutdown options for dismount which were /ABORT and  something else.   F We are still having an internal debate as to whether shadowsets shouldE be mounted cluster-wide including on nodes that do not access them as > files-11 volumes; MSCP serving will still work to maintain the shadowsets.   > If you need the code, please send me an email or post a reply.  & Keep up the good work and the debates!     Gerald.  Gerald Marsh  / gerald -at- cyfer -dot- demon -dot- co -dot- uk    ------------------------------    Date: 21 Jul 2003 18:07:42 -0700  From: wmr282@hotmail.com (w m r)& Subject: Re: Does anyone remember IAS?= Message-ID: <398c9ca7.0307211707.2e0fbed3@posting.google.com>   ` Alan Frisbie <Abuse@Flying-Disk.com> wrote in message news:<3F1C2193.4090207@Flying-Disk.com>...  A > I used RSX-11D and IAS in the late 1970's also, first at Conrac B > (telephone test/diagnostic/logging systems), then at InteractiveE > Graphic Systems.   At IGS we wrote drivers and subroutine libraries B > for thost "funky 3D vector-style" graphics scopes, in particular@ > those from Vector General.   They were really nice scopes, butE > rather pricy.   We had a lot of fun doing cool stuff in those days.   F Yes, that was it, Vector General.  IIRC, it had a rather large circuitE board that was a parallel divider or something like that.  Apparently . we were doing the same thing at the same time!  F I think I still have a VG keyring somewhere (I saw it recently).  It's= a little MPG calculator, very trendy in the mid-to-late 70's.   D > IAS/RSX-11D had a lot of things going for it, but it cost in termsF > of memory and CPU usage.   RSX-11M was much more of a "lightweight",F > but would run on configurations that RSX-11D could not.   Cutler andG > friends did a really good job of turning a "minimal" operating system ) > into major competition for RSX-11D/IAS.   F Yes, after that, all PDP-11's I used had 11M.  I remember how weird it? was.  I never really had a plain 11D system, it had always been  butchered for IAS.  F > As RSX-11M gained in popularity, we ported our drivers and librariesH > to it, and later to VMS.   We also did a port to the DEC VS60 graphics5 > scope.   I still have the VS60 sitting in my house.   # I left before the VAX's came along.    Mike   ------------------------------  # Date: Tue, 22 Jul 2003 03:09:39 GMT * From: don@news.daedalus.co.nz (Don Stokes)P Subject: Re: Does RT-11 run on the PDP-11/70?  (was Re: PDP-11 OS Release Dates)3 Message-ID: <TV1Ta.6427$9f7.758087@news02.tsnz.net>   ) In article <4+Y7aD$kEX4p@elias.decus.ch>, * Paul Sture <p_sture@elias.decus.ch> wrote:/ >The 11/780 console floppy was an RT-11 volume.   G Quite a lot of things were.  RT-11 volumes were (a) simple, (b) kind of B a lowest common denominator; ever pdp11/VAX platform support RT-11C volumes to some extent, e.g. through FLX or EXCHANGE.  VAX consoles E (even the micoroprocessor ones) used RT-11 filesystems; the only ones D that didn't format their console media as RT-11 filesystems were the- Nautilus process with their DEC Pro consoles.   H HSCs also used RT-11 filesystems.  I'm sure quite a few other things did too.   -- don   ------------------------------   Date: 21 Jul 2003 21:17:36 GMT2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com>O Subject: Re: Does RT-11 run on the PDP-11/70? (was Re: PDP-11 OS Release Dates) + Message-ID: <bfhl9g09bc@enews2.newsguy.com>   I In alt.sys.pdp10 Bill/Carolyn Pechter <pechter@shell.monmouth.com> wrote: $ > The RT11 console was on the 86x0.   G Wasn't the console for those either a Pro350 or Pro380 running some odd  verison of P/OS.   		Zane   ------------------------------  # Date: Tue, 22 Jul 2003 05:29:43 GMT ; From: "John Gemignani, Jr." <jon-nope@thiswontworkossc.net> O Subject: Re: Does RT-11 run on the PDP-11/70? (was Re: PDP-11 OS Release Dates) : Message-ID: <bZ3Ta.1232$8g6.38052@news1.news.adelphia.net>  F "Christine Ricketts/Andrew Stewart" <u1276a@uxnxixtxe.com.au> wrote in. message news:3f1cc98f_1@news.iprimus.com.au... > - > "Megan" <mbg@TheWorld.com> wrote in message $ > news:bfcqoj$s8j$1@pcls4.std.com...I > > "Christine Ricketts/Andrew Stewart" <u1276a@uxnxixtxe.com.au> writes:  > [cut]  > > D > > >Interesting.  The RT-11 V5.5 SPD does not mention the PDP-11/70C > > >yet p257 of the RT-11 V5.5 Mini Reference Manual has bit 14 of D > > >the Configuration Word 2 is set if it is a PDP-11/70 processor. > > J > > RT-11 does indeed run on 11/70s, though for some reason I forget afterH > > so many years, we couldn't specifically say that it was supported on	 > > same.  > > C > > >Was this used for the RT-11 Emulation under RSTS/E and/or RSX, + > > >or did RT-11 run native on this beast?  > > G > > It runs native... I used to run it all the time back in the V3 days F > > on an 11/70 at DEC in the ed services lab at PK2 (when ed services > > was in maynard). >u > Most interesting.  Thanks. >t2 > > >PS.  I was told RT-11 runs on the VAX-11/780,1 > > >very easily on the LSI-11 console processor,mC > > >at least once in compatability mode for testing purposes.  :-)e > >tG > > I never tried running it on the Console of the VAX, though it wouldoH > > probably work just fine (though one drive is a bit cramped).  As for; > > running on a VAX, only on one which has RTEM installed.o > >-8 > >                                         Megan GentryB > >                                         Former RT-11 Developer >e> > The VAX-11/780 had a bit in the PSW so that it would execute< > a subset of PDP-11 instructions, aka "compatability mode".* > No Memory Management, No Floating Point. >e; > I was told that someone "munged" up some VAX-11 Boot CodeP8 > that set up the VAX-11 machine environment so that the; > PDP-11 Compatability Mode could access devices in Bank 7,a! > then booted RT-11 SJ and/or FB.N >  > Regards, Andy. >. >t >n  L I played quite a bit with some of this, as the 780 was a very simple machine
 to work with.v@ Comrades got 11M running the kernel  by putting the machine into compatibility mode after loading the system image.e   -Johne   ------------------------------  % Date: Tue, 22 Jul 2003 00:36:32 +0800i, From: Paul Repacholi <prep@prep.synonet.com>% Subject: Re: duplicating system disksa- Message-ID: <87y8yrj0q7.fsf@prep.synonet.com>e  R helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:  = > There must be many folks who have multiple system disks for @ > redundancy, which should be identical except for NODE-SPECIFICC > stuff.  Rather than upgrading, installing layered products on etcMB > ALL disks, it would make more sense to do it just on one "master> > disk" then make copies of this for other system disks (quite0 > comfortably if all system disks are shadowed).   > Does anyone actually do this?-  D Yep. I used to do it with a truckload of layered products, then nuke@ off the ones that where not licenced on the system in question.   C There is a nasty if you boot onto an empty [SYSn] where it will useeF the PARAMS.DAT from syscommon, even if it is a satelite boot :( [SYS0]D is a double trap, as that will be booted if you bootflags are empty.   -- d< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.I@                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Mon, 21 Jul 2003 22:24:30 -0400.* From: JF Mezei <jfmezei.spamnot@istop.com>' Subject: Re: Getting rid of DECwindows? ' Message-ID: <3F1CA03E.81D13C@istop.com>U   Charlie Hammond wrote:F > That said, I would not necessarily recommend this.  It is surprisingF > how often something in one "unused" part of OpenVMS is actually usedH > by some other part of the O/S.  It is generally better and less costlyJ > to by more and/or larger disks than to remove "unused" parts of OpenVMS.  I In particular, the CDA converter libraries are linked against some of the  decwindows files.    ------------------------------  % Date: Mon, 21 Jul 2003 20:40:55 -0400s* From: JF Mezei <jfmezei.spamnot@istop.com>4 Subject: Re: HP World: Why Alpha's Omega Makes Sense) Message-ID: <3F1C87FF.5D3D2EF1@istop.com>o   Dirk Munk wrote:J > You see what I am really worried about is that the Itanium will not be a2 > success. That will leave HP without a processor.  N Worse case scenario. IA64 is abandonned by everyone but HP and HP then becomesN de-facto proprietor of IA64 which itself then becomes a proprietary low volume, chip. No worse that PA-Risc, Alpha or Sparc.  J What the VMS engineers forget to mention is that Alpha was murdered on theK premise that IA64 would become industry standard, low cost, high volume and,0 that there was no way Alpha could achieve this.   I As far as I know, the 8086 is still the industry standard. As a matter ofhK fact, the wintel products at HP are still called industry standard, right ?e  I As far as I know, Intel has admitted that IA64 wouldn't be competitive onUK desktop. So low cost doesn't seem to have been achieved. And if one were to D belive all those white papers presented to customers by then DigitalH engineers, the very nature of the IA64 will make its evolution very timeM consuming and require lots of resources. Will Intel ever be able to make IA64nF price competitive ? Or will it need to continue to what is essentiallyM blackmail/bribe  manufacturers to produce  IA64 based systems in order to geto good prices on 8086s ?  L And in terms of volumes, how many IA64s have been shipped so far ?  Only theN industry standard will achieve the high volumes that will permit the low cost.< Until the 8086 fades into history, IA64 won't get that spot.  N And with a 64 bit 8086 from AMD, it will make it much harder for intel to kill	 the 8086.    ------------------------------  % Date: Mon, 21 Jul 2003 21:01:51 -0400b* From: JF Mezei <jfmezei.spamnot@istop.com>4 Subject: Re: HP World: Why Alpha's Omega Makes Sense) Message-ID: <3F1C8CE5.690FDD8B@istop.com>o   Bill Todd wrote:M > Two years ago, a participant here who vigorously supported Compaq's versionaK > of the rationale for the Alphacide (because he was being told that it wasLJ > true by people whom he trusted but who were *not* part of the Alpha chipN > teams) suddenly dropped out of the discussion after he finally got word fromM > what he considered to be an unimpeachable and directly-informed source thatnJ > it was a pack of lies, and privately apologized to me for having doubted > this u    N In light of recent events in the UK, I think that even if HP/Compaq fabricatedK whatever evidence used to justify the murder of Alpha, we should not expecteL anyone to come forth and spill the beens to the BBC anymore since they would% then have to fear for their own life.u   :-) :-) :-) :-) :-)s   ------------------------------  % Date: Mon, 21 Jul 2003 21:34:54 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>4 Subject: Re: HP World: Why Alpha's Omega Makes Sense) Message-ID: <3F1C94A1.73A03407@istop.com>    Rob Young wrote:M >         Itaniums).  That price curve is just getting started.  Itanium willcN >         suck the air right out of Power and UltraSparc margins.  That is/wasA >         what Compaq was facing with Alpha - among other things.e  I Any company who puts the success of its own products ahead of that of itsyE competitors would have taken Intel to the cleaners for stealing AlphaoI technologies for the 8086/Pentium, and would then have taken Intel to theaM Federal Trade Comission for unfairly  dumping of the IA64 product, as well ascJ using monopoliostic tactics to bully manufacturers to start producing some
 IA64 systems.   K Any company that puts its competitor's products ahead of its own, and whosesK shareholders don't revolt deserves to die. Digital died, Compaq died. CarlycK seems to have similar philosophy. How long will it take for HP to sink ? Ora/ will HP realise the trend and stop it in time ?l   ------------------------------  % Date: Mon, 21 Jul 2003 22:42:04 -0400i( From: David Froble <davef@tsoft-inc.com>4 Subject: Re: HP World: Why Alpha's Omega Makes Sense, Message-ID: <3F1CA47C.7070504@tsoft-inc.com>   JF Mezei wrote:c    P > Worse case scenario. IA64 is abandonned by everyone but HP and HP then becomesP > de-facto proprietor of IA64 which itself then becomes a proprietary low volume. > chip. No worse that PA-Risc, Alpha or Sparc.   Wrong.  M 1) None of the 3 you mentioned will heat your house adequately on those cold U winter days.  N 2) Should there also be problems with the compiler people, EPIC is definitely  NOT your friend.  P 3) Intel will give up on a loser rather quickly.  HP, DEC, and Sun seem to be a F bit more dedicated.  Problems are, HP has changed, and DEC is no more.   Dave   -- h4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  % Date: Mon, 21 Jul 2003 23:21:21 -0400s* From: JF Mezei <jfmezei.spamnot@istop.com>4 Subject: Re: HP World: Why Alpha's Omega Makes Sense) Message-ID: <3F1CAD8D.E969D055@istop.com>m   jlsue wrote:F > I, personally, use AMD for my desktop systems.  I like their price &H > performance capabilities.  But I wouldn't recommend them to anyone who$ > wants real business-class servers.  F Intel decides to take its experience with the 8086 and build its firstF "serious" enterprise chip from scratch with a totaly new paradigm.  HPN supporters blindly support Intel's new venture into a new chip in a new marketK segment for Intel, even before that chip has made its proofs in the market./  L It is interesting that these same people dismiss AMD's efforts. AMD is usingN an architecture that has made its proofs in the market and is high volume, and= AMD's chip will be usable in both desktop and server configs.3  N If Intel is using the 8086 to subsidize the IA64, shouldn't Ia64 supporters beI affraid that if AMD erodes just a bit of the 8086 market that Intel might 7 start to hurt and the subsidy of the IA64 jeoperdized ?r  I Does anyone have any hard facts showing that the IA64 product is actuallyc; profitable from the point of view of return on investment ?n   ------------------------------  # Date: Mon, 21 Jul 2003 18:24:44 GMTr' From: Colin Blake <colin@theblakes.com>i, Subject: Re: Mozilla... the new NULL process; Message-ID: <MdWSa.6250$KZ.2983182@news1.news.adelphia.net>e   VAXman- wrote:  I > Well then an AS1200 with 2 CPUs is hereforthwith to be known as a real p+ > slow system and will be retagged RSS1200.B  C Running something such as MON PROC/TOPC you shouldn't even SEE the u: mozilla process on a system like that. Something is amiss.   ------------------------------  # Date: Mon, 21 Jul 2003 19:59:23 GMTa" From:   VAXman-  @SendSpamHere.ORG, Subject: Re: Mozilla... the new NULL process0 Message-ID: <00A23329.8986B0B3@SendSpamHere.ORG>  e In article <MdWSa.6250$KZ.2983182@news1.news.adelphia.net>, Colin Blake <colin@theblakes.com> writes:  >VAXman- wrote:w > J >> Well then an AS1200 with 2 CPUs is hereforthwith to be known as a real , >> slow system and will be retagged RSS1200. > D >Running something such as MON PROC/TOPC you shouldn't even SEE the ; >mozilla process on a system like that. Something is amiss.r >e  C Well I am running it now on an AS200 4/233 ( I'd like the cycles onaE the AS1200 to be used for something useful) and it's eating up a con-I5 sistent 35-38% according to MONITOR PROCESS/TOPCPU.    --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM             c5   "Well my son, life is like a beanstalk, isn't it?" /   ------------------------------  + Date: Mon, 21 Jul 2003 21:30:54 +0000 (UTC)r7 From: moroney@world.std.spaamtrap.com (Michael Moroney) , Subject: Re: Mozilla... the new NULL process( Message-ID: <bfhm2e$gcm$1@pcls4.std.com>  " VAXman-  @SendSpamHere.ORG writes:  K >>> Well then an AS1200 with 2 CPUs is hereforthwith to be known as a real s- >>> slow system and will be retagged RSS1200.R >>E >>Running something such as MON PROC/TOPC you shouldn't even SEE the  < >>mozilla process on a system like that. Something is amiss. >>  D >Well I am running it now on an AS200 4/233 ( I'd like the cycles onF >the AS1200 to be used for something useful) and it's eating up a con-6 >sistent 35-38% according to MONITOR PROCESS/TOPCPU.    H Something is wrong.  I am also running Mozilla on an AS200 4/233 and theK idle Mozilla process is taking 1% of the CPU.  Sometimes it pops up to 2%,   sometimes blank (less than 1%)  K Are you sure it's not repeatedly animating a complicated .GIF or something?  -- C -Mike    ------------------------------  % Date: Mon, 21 Jul 2003 18:29:03 -0400b* From: Bill Valentine-Cooper <wvc@nwcs.com>; Subject: Non-OpenVMS ethernet access to Printserver 17/600?e8 Message-ID: <srpohvspkpd7flt309lekflmg224hf9567@4ax.com>  C Does anyone know how to print to a Printserver 17/600 over ethernet A from an OS other than VMS? I've got it working fine under OpenVMS D (using LPS V5.0 under OpenVMS V6.2), but can't figure out how to getF to it from a linux box or W32. The Printserver appears to be listeningF on port 170, but as far as I can tell, that's a "no longer well-known" port.    Thanks in advancee   VC   ------------------------------  % Date: Mon, 21 Jul 2003 18:57:09 -0500n/ From: Chris Scheers <chris@applied-synergy.com> ? Subject: Re: Non-OpenVMS ethernet access to Printserver 17/600? 3 Message-ID: <3F1C7DD5.C348D0DA@applied-synergy.com>d   Bill Valentine-Cooper wrote: > E > Does anyone know how to print to a Printserver 17/600 over ethernetyC > from an OS other than VMS? I've got it working fine under OpenVMSaF > (using LPS V5.0 under OpenVMS V6.2), but can't figure out how to getH > to it from a linux box or W32. The Printserver appears to be listeningH > on port 170, but as far as I can tell, that's a "no longer well-known" > port.s >  > Thanks in advance4 >  > VC  G I'm not sure what you mean by W32, but WinNT can download and talk to a  Printserver.  D When you define the printer, give it a port type of "Digital NetworkG Port". Then you can define the type of printer and the appropriate codea" will be downloaded to the printer.  
 Good luck!  G -----------------------------------------------------------------------e$ Chris Scheers, Applied Synergy, Inc.  C Voice: 817-237-3360            Internet: chris@applied-synergy.com     Fax: 817-237-3074a   ------------------------------    Date: 21 Jul 2003 12:18:20 -0700/ From: kenneth.randell@verizon.net (Ken Randell)P8 Subject: Re: Obsolete cross compilers: where did you go?= Message-ID: <79de9693.0307211118.77bbe026@posting.google.com>    > 4 > Are you still using them? If not, what did you do? >   2 Not actively used, but still available if required  B > Did you move them to Alpha via CHARON-VAX or any other software  > emulation solution?n >    We kept the VAX...  = > Did you find OpenVMS/Alpha versions of the cross compilers?U >    No  G > Did you address the obsolescence issue of VAX/VMS when going Itanium?m >    N/A   F > Did some of you contact the numerous editors making cross compilers I > (Intel, BSO, Tasking, Altium, etc.) to ask them to port their products n+ > to Itanium? Or to sell you their sources?  >   B To my knowledge, Intel has no intention of ever porting any of the> XXX386 cross-assembler stuff to any platform.  I could find noC references to any real manuals or software for any of this (ASM386,iB PLM386, etc.) at their web site -- even using part numbers for theA manuals.  Only could find vague references in chipset informationK
 about ASM386.s   ------------------------------    Date: 21 Jul 2003 16:29:49 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)l8 Subject: Re: Obsolete cross compilers: where did you go?3 Message-ID: <ml0lZ91iVd3K@eisner.encompasserve.org>   \ In article <3F1BC902.12704.19E44056@localhost>, "Stanley F. Quayle" <stan@stanq.com> writes:0 > On 21 Jul 2003 at 9:26, Larry Kilgallen wrote:< >> I know of a VMS customer in this area still using SD-Ada.I >> I believe it is supported by EDS, who have no intention of porting it.a >> tE >> So that customer is stuck on VAX, and perhaps cannot even consideri@ >> VAX emulators due to certification issues for their industry. > F > If the military has no issues with moving to CHARON-VAX, I'd expect 6 > that industry certification wouldn't be a problem...  O There is no "the military".  Every decision is based on separate circumstances.h> Some are not allowed to move from one model of VAX to another.   ------------------------------  % Date: Mon, 21 Jul 2003 18:36:53 -0400t* From: "Stanley F. Quayle" <stan@stanq.com>8 Subject: Re: Obsolete cross compilers: where did you go?. Message-ID: <3F1C32C5.7087.1B8161B6@localhost>  / On 21 Jul 2003 at 16:29, Larry Kilgallen wrote: Q > There is no "the military".  Every decision is based on separate circumstances.n@ > Some are not allowed to move from one model of VAX to another.  A Absolutely.  But to reject things out-of-hand is not productive, -	 either...-  
 --Stan Quayleo Quayle Consulting Inc.  
 ----------C Stanley F. Quayle, P.E. N8SQ  +1 614-868-1363  Fax: +1 614 868-1671p1 8572 North Spring Ct. NW, Pickerington, OH  43147c= Preferred address:  stan@stanq.com       http://www.stanq.come   ------------------------------   Date: 21 Jul 03 20:10:43 +0200) From: p_sture@elias.decus.ch (Paul Sture)c Subject: Re: OpenVms Backupi) Message-ID: <xfltDbedD9cE@elias.decus.ch>k  T In article <bfgtrd$h1c$1@lore.csc.com>, Nic Clews <sendspamhere@[127.0.0.1]> writes: > Charlie Hammond wrote: >> e3 >> In article <bfg4s4$3q7$3@n.ruf.uni-freiburg.de>,a8 >> gartmann@immunbio.mpg.de (Christoph Gartmann) writes: >> e9 >> >     ... . You should have used "/IGNORE=INTERLOCK" .p >>  K >> As often discussed on this group,  /IGNORE=INTERLOCK should only be used C >> if you do not care whether or not the resulting backup is valid.aN >> Usually, you do are about the validity of an image backup of a system disk. > = > Sorry Charlie, you're coming in for a bit of stick here...!t > E > Straw poll time, how many have used /ign=inter and ended up with ane > UNBOOTABLE disk? > J > Count me as a never, over say 12 years of doing it reasonably regularly. >   F I'd say never too, and my figure must be closer to 20 years (not quite2 remembering whether /ign=inter was there at V3.0).  C Of course I have screwed applications by not closing them properly,3+ but that didn't render the disk unbootable.o  H Having said that, I understand why the official Engineering line exists.C I am sure that many of us have received support calls where someoneaK insists that nothing is running, when in fact something _has_ been running.e  G (There was the problem on the original batch system, that JBCSYSQUE.DATrF would always be recreated on booting the target disk, and you lost anyD queue information. No matter, since in those days, I used INIT/STARTL with all the necessary parameters for all queues in the startup procedures.)  G > Christoph was absolutely right, the lack of /IGN=INTER meant the file-I > was open, so backup did not lay it on the tape, contents or not... FrommJ > the original post, I'm mildly amused that it even booted. I missed it in > my first reply.f > J > I'm a little worried that some think that /IGN=NOBACKUP means it doesn't > back the file up.8 >   3 Agreed. It did rather leap out of the screen at me.1   ------------------------------  # Date: Mon, 21 Jul 2003 18:47:06 GMTe3 From: hammond@not@peek.ssr.hp.com (Charlie Hammond)a Subject: Re: OpenVms Backupe/ Message-ID: <KyWSa.521$5X.420@news.cpqcorp.net>   * In article <xfltDbedD9cE@elias.decus.ch>, + p_sture@elias.decus.ch (Paul Sture) writes:  ..F >> Straw poll time, how many have used /ign=inter and ended up with an >> UNBOOTABLE disk?  .. >> aK >> Count me as a never, over say 12 years of doing it reasonably regularly.r >> I > G >I'd say never too, and my figure must be closer to 20 years (not quitee3 >remembering whether /ign=inter was there at V3.0).o >iD >Of course I have screwed applications by not closing them properly,, >but that didn't render the disk unbootable. >wI >Having said that, I understand why the official Engineering line exists.n  G With respect, if you think that ensuring a bootable system disk is the  I only reason for NOT using /INGORE=INTERLOCK, then you may NOT understand.g  G The potential loss of data from files that are not correctly backed up  < is MUCH MORE of an issue that a system disk that won't boot.F For "all the right reasons" OpenVMS Engineering is extremely sensitive3 to anything that can cause data loss or corruption.b  J In a production environment, a backup strategy that uses /INGORE=INTERLOCKJ is bogus.  Period.  The cost of lost information will usually exceed by a , LARGE amount the cost of doing backup right.  6 I appologize if anyone thinks I've just insulted them.   -- oJ       Charlie Hammond -- Hewlett-Packard Company -- Ft Lauderdale  FL  USAF           (hammond@not@peek.ssr.hp.com -- remove "@not" when replying)J       All opinions expressed are my own and not necessarily my employer's.   ------------------------------    Date: 21 Jul 2003 12:02:08 -0700. From: spamsink2001@yahoo.com (Alan E. Feldman) Subject: Re: OpenVms BackupR= Message-ID: <b096a4ee.0307211102.65dca795@posting.google.com>-  m josef.rudyk@commerzbank.com (joru) wrote in message news:<2b109804.0307210440.514dbddc@posting.google.com>...: > Hi Maurix, > = > the reason for this message is, that you used the qualifiertC > /IGNOR=NOBACKUP. Page- and swapfiles are marked as NOBACKUP as ite2 > makes no sense to back them up and restore them. > " > Just create a new pagefile with: >  > MCR SYSGEN< > SYSGEN>CREATE/CONTIGOUS/SIZE=xxxxxx disk:[dir]pagefile.sys > D > replace XXXXXXX with the size in 512Byte blocks that your pagefile2 > should be and reboot or intsall it by executing: > / > SYSGEN>INSTAL disk:[dir]pagefile.sys/PAGEFILEa > 
 > Regards Joe   D Not so. Without /IGNO=NOBACKUP, BACKUP will back up the file headersB of the page, swap, and dump files, but will skip copying the data,C since the data is useless for such files (unless you have an unreadeD dump in the dump file, in which case you might want to copy the dataB therein -- probably better to read/save the dump information first though anyway).t  > During the restore, BACKUP will re-create these files, but theC original data will not be restored, which is no problem, of course..A The files will be the same as before (size, location, attributes) C except for the data they contain and they should be contiguous upon A restore also. There is no need to manually re-create these files.a   Disclaimer: JMHO Alan E. Feldmann   ------------------------------    Date: 21 Jul 2003 13:08:37 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)r Subject: Re: OpenVms Backup - Message-ID: <EeB0mFx4f4af@malvm7.mala.bc.ca.>s  0 In article <KyWSa.521$5X.420@news.cpqcorp.net>, 9     hammond@not@peek.ssr.hp.com (Charlie Hammond) writes:    > L > In a production environment, a backup strategy that uses /INGORE=INTERLOCK > is bogus.  Period.  G     That seems a bit extreme. What about the case of an Oracle databaselC where one wants to do a "hot backup". Of course one needs to followgE all Oracle's instructions about using ARCHIVELOG mode and setting thegF tablespaces in BACKUP mode, but given all that it's still necessary to: use /IGN=INTERLOCK to actually copy the "hot" tablespaces.  B     What about the case where it's files such as PAGEFILE.SYS thatE are open, but they're marked "NOBACKUP" anyway - there's no danger ineH saving the information needed to re-create the file, but it will fail ifA /IGN=INTERLOCK isn't used ( or at least that seems to be the casei based on this thread ).-  J     In many other cases there may be a potential for some "lost" data, butG it may be inconsequential ( YMMV ). For example, I don't really care ifeN I'm missing a few entries from OPERATOR.LOG or ERRLOG.SYS when I do an on-lineL image backup of a system disk. I expect that the queue database may not copyJ correctly ( so one may need to recreate entries manually ). I know there'sJ an (extremely remote) chance that SYSUAF.DAT could end up with a corruptedM bucket ( bucket check failure ). Since I do an image backup of my system diskdJ every day and keep several weeks of history I should be able to restore anP earlier version of SYSUAF.DAT in that case ( there's virtually no chance they'll all be corrupted ).f  Q     I understand why the safe thing to say is that "/IGN=INTERLOCK is bogus", butoJ it would be more useful if HP accepted that most of us who run VMS systemsF run them in a 24x7 environment, and shutting down every day to back upK disks isn't an option. What we really need is to fully understand the riskstH of IGN=INTERLOCK and design backup procedures to mitigate them ( even ifN they can't be completely eliminated ). A full explanation of how IGN=INTERLOCKL works and how it interacts with things like file caching would be a lot more, helpful than a simple warning to not use it.   ------------------------------   Date: 21 Jul 2003 21:09:56 GMT( From: ka2doug@cs.commoc.sc (DL Phillips) Subject: Re: OpenVms Backup.> Message-ID: <20030721170956.02838.00000347@mb-m19.news.cs.com>   Nic Clews wrote: >uD >Straw poll time, how many have used /ign=inter and ended up with an >UNBOOTABLE disk?t >5  N Since the mid-80's or so when the MicroVaxen became price competitive with theJ PDP's --- meaning that smaller companies could afford them --- most of ourN customers do not run 24*7 shops.  We  let backup run during their off-time andI usually do an image of the system disk along with the data disk(s) and we: always use /igonor=interlock.h  N Over the years I've restored many a system disk from one of those backups (tooK many back in the RD53/RD54 day's) and every one has booted. (Well, I've had:. some bad TK50 tapes, but that's another issue)  O Reading what a backup log says during the /verify pass will show how gracefullyn& the system disk's /image will restore.  L Except for the queue stuff, sysuaf login times and the log files, all of theO important VMS bits on even a quite active system disk will restore and boot, org such has been my fortune.v  F >Christoph was absolutely right, the lack of /IGN=INTER meant the fileH >was open, so backup did not lay it on the tape, contents or not... FromI >the original post, I'm mildly amused that it even booted. I missed it ina >my first reply. >m  I I seldom get interlock errors when my prompt looks like what the originalt poster typed, ie $$$   :-)    -Doug   ------------------------------  % Date: Mon, 21 Jul 2003 22:58:40 -0400h( From: David Froble <davef@tsoft-inc.com> Subject: Re: OpenVms Backupv, Message-ID: <3F1CA860.2030903@tsoft-inc.com>   Charlie Hammond wrote:  V > In article <bfgtrd$h1c$1@lore.csc.com>, Nic Clews <sendspamhere@[127.0.0.1]> writes: >  >>Charlie Hammond wrote: >> > K >>>As often discussed on this group,  /IGNORE=INTERLOCK should only be usedaC >>>if you do not care whether or not the resulting backup is valid. N >>>Usually, you do are about the validity of an image backup of a system disk. >>>k= >>Sorry Charlie, you're coming in for a bit of stick here...!u >> > D > Since the original poster seemed to have some confusion, I thought* > this point should be strongly made here. >  > H >>...how many have used /ign=inter and ended up with an UNBOOTABLE disk? >> > ' > An unbootable disk is probably rare. fL > More common is an inconsistent or completely invalid (unusable) data file. >  >   N Can you specify a scenario where, when there is no activity that would update P any files on the system disk, a BACK/IMAGE/IGNORE=INTER would give you a backup M with any problems?  Let's go one further and specify that the storage on the s1 system dusk is limited to VMS and static storage.    Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  % Date: Mon, 21 Jul 2003 23:02:35 -0400n( From: David Froble <davef@tsoft-inc.com> Subject: Re: OpenVms Backupd, Message-ID: <3F1CA94B.4050604@tsoft-inc.com>   briggs@encompasserve.org wrote:   g > In article <H9SSa.470$My.202@news.cpqcorp.net>, hammond@not@peek.ssr.hp.com (Charlie Hammond) writes:n > 3 >>In article <bfg4s4$3q7$3@n.ruf.uni-freiburg.de>,  7 >>gartmann@immunbio.mpg.de (Christoph Gartmann) writes:  >> >>7 >>>    ... . You should have used "/IGNORE=INTERLOCK" .. >>>eJ >>As often discussed on this group,  /IGNORE=INTERLOCK should only be usedB >>if you do not care whether or not the resulting backup is valid.M >>Usually, you do are about the validity of an image backup of a system disk.u >> > M > The alternative point of view is that you should only use /IGNORE=INTERLOCK.H > if you are able to live with the possibility that files that were openG > for write during the BACKUP process may be corrupt after the restore.  > 9 > If you look at the log file for the backup and see thatc > V > %BACKUP-W-ACCONFLICT, DSA1:[SYS0.SYSEXE]PAGEFILE.SYS;1 is open for write by another  > userO > %BACKUP-W-ACCONFLICT, DSA1:[SYS0.SYSMGR]ACCOUNTNG.DAT;1 is open for write by   > another userN > %BACKUP-W-ACCONFLICT, DSA1:[SYS0.SYSMAINT]ERRLOG.SYS;1 is open for write by  > another user > I > then you have very little reason for concern.  The data in PAGEFILE.SYShA > is irrelevant and if your log files get truncated, that's stillk9 > probably better than having them eliminated altogether.a > 
 > If you see:  > G > %BACKUP-W-ACCONFLICT, DSA1:[SYS0.SYSCOMMON.SYSEXE]QMAN$MASTER.DAT ...c > E > then you need to consider that your queues might be toast and would D > have to be re-created after any /IMAGE restore of the system disk. >  > and if you see:o > D > %BACKUP-W-ACCONFLICT, DSA101:[SYS0.SYSCOMMON.SYSEXE]SYSUAF.DAT ... > A > then you need to be aware that your user authorization databasei& > may be suspect it has been restored. > G > If you see other open files then you probably have other applicationsID > running on your system disk.  Consider shutting those applications7 > down or investigating online backup support for them.i >  > C > It's not that you _don't care_ about the integrity of your system A > disk.  It's that you may consider the chance of needing to redoi; > your queues or to restore an older copy of your SYSUAF anAB > acceptable consequence of a decision to keep the system up 24x7. > A > Trade-offs.  There are always trade-offs.  The older I get, theeD > less I see things in black and white.  And more in shades of grey. > H > I've done a lot of online backups of my system disks.  And I've had toD > restore from those backups.  In my experience, the above files are? > the ones that are "open for write by another user".  My queueuB > database has been toasted consistently every time I've had to do1 > a restore.  My SYSUAF has never been corrupted.t >  > 	John Briggs >   N If your system startup procedure(s) include initializing all the queues, then I there isn't much of a problem with the queue manager database being open.t  P If this is an issue, then stop the queue manager for the duration of the backup.   Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  # Date: Tue, 22 Jul 2003 03:38:47 GMTD- From: "John E. Malmberg" <wb8tyw@qsl.network>s Subject: Re: OpenVms Backupp8 Message-ID: <bl2Ta.93$8g6.12769@news1.news.adelphia.net>   David Froble wrote:t > I > Can you specify a scenario where, when there is no activity that would PG > update any files on the system disk, a BACK/IMAGE/IGNORE=INTER would 3I > give you a backup with any problems?  Let's go one further and specify  K > that the storage on the system dusk is limited to VMS and static storage.t  ? If your SYSUAF is on the disk, and you are running the OpenVMS  : Management Station agent, you risk a corrupted SYSUAF.DAT.  J There are ways around this of course.  But here is one real world example.  G Of course if you have hot backup systems, and reduncancy, you can take  = the time to rebuild a system disk and rebuild the lost files.r  F I recommend that everyone know how to rebuild their system from known 1 good sources, and have archives of critical data.    -Johnr wb8tyw@qsl.network Personal Opinion Onlyu   ------------------------------  % Date: Mon, 21 Jul 2003 19:51:07 -0400i* From: JF Mezei <jfmezei.spamnot@istop.com>8 Subject: Re: OpenVMS Technical Seminar Highlights (some)) Message-ID: <3F1C7C55.52017983@istop.com>    Neil Rieck wrote:sN > Maybe I'm reading too much into this, but I wonder if RDB will be moved fromJ > Oracle back to OpenVMS engineering? (Although this might not be fiscally6 > possible unless Larry Ellison is feeling charitable)   How big is Oracle on VMS ?  ; I am asking this naively (no accusations or rumours here) :.  M Could Oracle/HP decide to drop one of the two databases and focus on just one K ? Or is Oracle more or less on equal footing as RDB making it impossible toi drop either on VMS ?   ------------------------------  % Date: Mon, 21 Jul 2003 22:59:59 +0200o& From: Frank Arnold <fm.arnold@gmx.net>$ Subject: Re: PDP-11 OS Release Dates' Message-ID: <3F1C544F.89A5758B@gmx.net>    Paul Repacholi schrieb: F > I have also run a 11/44 from TU-58 as the system disk. I can promiseG > you, it is something you never want to do. To init it I set it going,dH > then went to the tavern across the road for lunch. I think that is theE > only way you can, other wise you will kill off the `failed' init...n > D > Light and blunt please, we want it to be *SLOOOOWWW* and painfull!@ > Pity no one did a RSP disk or floppy for diags and the like... >   i' May this is what you're looking for.... 9 http://www.SpareTimeGizmos.com/Hardware/TU58_Emulator.htm.   Frank    ------------------------------  % Date: Mon, 21 Jul 2003 22:47:32 -0400i) From: "Douglas A. Gwyn" <DAGwyn@null.net>g$ Subject: Re: PDP-11 OS Release Dates0 Message-ID: <8Z-dnWoqLvBcOIGiXTWJiA@comcast.com>   paramucho wrote:B > RT-11 *could* act like a memory-resident system, but only if youF > obeyed some pretty strict memory usage guide lines. If you requestedH > all background memory then the system would mark KMON non-resident andB > it would be reloaded from the system device the next time it was > required.   < I was talking about during the execution of the (foreground)9 task.  Unless the task made an explicit disk I/O request,C6 the disk was not used until after the task terminated.   ------------------------------  # Date: Tue, 22 Jul 2003 02:55:42 GMTn* From: don@news.daedalus.co.nz (Don Stokes)$ Subject: Re: PDP-11 OS Release Dates3 Message-ID: <OI1Ta.6421$9f7.757998@news02.tsnz.net>s  = In article <bdc65a53.0307180649.4a7d5d60@posting.google.com>,a% Galen <gspamtackett@yahoo.com> wrote:hA >Somebody used to distribute a Basic-Plus uncompiler, which was a G >pretty cool and magical tool to impress other computer lab staff with.S  B We had one of these under RSTS/E.  The company had installed a fewF tur(n)key systems with smallish disks (MicroPDP-11s, mainly) where theE source to the accounting package on them wasn't provided.  DECOMP (Or55 DCOMP, I forget now) worked wonders on these cases.     E "Here's a pdp11, a terminal with no screen editing capability, a line G printer, a stack of change requests and no source.  See you in a couple 
 of hours."   "Gee, thanks."   -- don   ------------------------------  % Date: Mon, 21 Jul 2003 21:12:54 -0400o* From: JF Mezei <jfmezei.spamnot@istop.com>Y Subject: Re: Redirecting screen output from FMS to files and displaying them using an emuA) Message-ID: <3F1C8F7B.AD573932@istop.com>r  
 Deepak wrote:,C > this they want to dump all the screen views possible (millions ofe > them)nG > into files. This dump should be in a format that is understandable tooC > a screen emulator. So that when they need to see the screen for aoE > particular key, they can use the emulator to read the dump file anda > display the screen.b  M If you have access to the application code, you can use FMS  routines to dump-3 the contents of the current screen to a text file.    ! FDV$PRINT_SCREEN( type, filespec).   where type is:   0 - generates ascii text6 1 - generates terminal escape sequences to draw screenO 2 - generates LN03 sequences (includes font selection for large characters etc)m  L So you could write an app that displays each record on the screen, then usesL FDV$PRINT_SCREEN to create a file containing that record's displayable data.   ------------------------------  + Date: Mon, 21 Jul 2003 23:25:27 -0500 (CDT)w From: sms@antinode.org: Subject: TCPIP V5.3 Anonymous FTP - More control possible?) Message-ID: <03072123252712@antinode.org>I  @    Let's pretend that I'm getting tired of seeing stuff like the8 following in my FTP server log (TCPIP V5.3, VMS V7.3-1):  6       18-JUL-2003 02:32:21.71 User:anonymous logged in4       ident:Tgpuser@home.com from Host:80.135.92.228  C       18-JUL-2003 02:32:23.79 User:anonymous ident:Tgpuser@home.comt7       status:00010001 CWD dir:SYS$SYSDEVICE:[ANONYMOUS]t  C       18-JUL-2003 02:32:25.98 User:anonymous ident:Tgpuser@home.como       logged out  F And a lot of other instances of what must be the same script where theB user name is "[A-Z]gpuser@home.com".  Is there any mechanism for aE user-supplied command procedure or program to reject an anonymous FTPrE connection?  Ideally, it would have access to the anonymous user namef/ and password, and the IP address of the client.t  E    If not, please consider this a feature request from a (non-paying) 1 hobbyist, with all the influence implied thereby.d  F    These scripts can't cope with VMS-style DIRECTORY listings, so theyI don't pose any real threat, but I'd like to reduce the log-file clutter. 0H (Adding some pointless delay before the rejection would be an attractive possibility, too.)  H ------------------------------------------------------------------------  4    Steven M. Schweda               (+1) 651-699-98183    382 South Warwick Street        sms@antinode.orgt    Saint Paul  MN  55105-2547    ------------------------------  # Date: Mon, 21 Jul 2003 18:06:59 GMTo6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)) Subject: Re: Update VMS731_CDRECORD-V0100w5 Message-ID: <7ZVSa.288511$1F6.2928512@news.chello.at>p  [ In article <3F1BBC64.7204.19B2F75E@localhost>, "Stanley F. Quayle" <stan@stanq.com> writes:sG >I have posted it in the bug section of www.openvms.org.  I don't have s? >a support contract, so the official channels are closed to me.d  E Not really. I've no support contract also, but I was able to create a G personal account on the field service webserver and did enter 4 serviceh calls so far :-))p< (Don't get me wrong, I do not exaggerate, 4 in a year or so)  H I marked them all as "OpenVMS hobbyist" and "no support contract" (whichK mostly got ignored and I got thelephone calls asking me for a contract# :-) K and I included observations destined for engineering. All calls were closedyH within days (if not hours), but 3 of the 4 bugs are (almost) fixed now !L (Yes, it took time, and maybe it was not my call, but who knows for sure...)  H It may not be best practice, but worst things seems to be that they onlyI will change registration restrictions and delete my account afterwards...    YMMV   --   Peter "EPLAN" LANGSTOEGERs% Network and OpenVMS system specialistt E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  % Date: Mon, 21 Jul 2003 17:14:07 -0400s* From: JF Mezei <jfmezei.spamnot@istop.com>5 Subject: Re: VAT for non-EU suppliers to EU customersn) Message-ID: <3F1C5793.461D5F7B@istop.com>s   Russell Wallace wrote:G > Heh, yes. If I were a non-EU supplier I'd tell the EU to put it wheresH > the sun don't shine. I'm quite surprised anyone would expect any other > reaction.   M Many USA mail order companies have setup canadians GST numbers. Why ? Because K it saves us, the customers much hassles and money. When the package crosses J the border with the "GST prepaid" sticker, it bypasses the highway robbery9 firms (customs brokers) and it gets delivered right away.A  I If you are vying to expand into a new market, you should make it easy for6L customers to order from you. On the other hand, if you have no intentions toM grow the market and expect only to serve existing customers who are desertingaI at an acceptable rate, then you don't need to work very hard to make life  easier for them.   ------------------------------  # Date: Mon, 21 Jul 2003 19:46:47 GMTs6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)1 Subject: Re: [NETBEANS34_1] installation troubles 5 Message-ID: <HqXSa.291038$1F6.2967618@news.chello.at>c  \ In article <7aXRa.416$zU4.23@news.cpqcorp.net>, "Meg Garrison" <meg.garrison@hp.com> writes:H >I work on NetBeans for OpenVMS, so maybe I can help with your problems.   I'm sure you can ;-)  L >1) The VMS731_UPDATE issue puzzles me, so I'll look into that.  It's likelyM >that update came out after the NetBeans kit was released and wasn't includeduM >in the PCSI information when the NetBeans kit was built.  You should be able:8 >to override the warning message...were you not able to?  L Yes, indeed. And also yes, but that leaves the InsDependErr in PROD SH PROD.M Even after fullfilling the Requirements (JAVA131 and VMS731_SYS installation) : the InsDependErr Message stays. Strange PCSI behaviours...  M >2) I haven't seen that problem here, but I will try to reproduce it.  Do you 4 >have only Java 1.4.1 installed (not 1.3.1 as well)?  K Yes. And the problem (as you already noted) is, that in the PDF of the PCSIpH kit the requirements are explicitely for JAVA131 and VMS731_SYS. So only6 a new kit or a selfmodified PDF/kit works for JAVA141.  H >3) This is a known PCSI problem and is documented in the release notes.J >Just ignore the error messages from PCSI (it cannot delete files with EFSK >chars in the name) and delete the remaining files by hand once the PRODUCTz >REMOVE completes.  5 Shame on me, I haven't read the release notes yet ;-)i   -- e Peter "EPLAN" LANGSTOEGERh% Network and OpenVMS system specialiste E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------   End of INFO-VAX 2003.401 ************************