INFO-VAX Fri, 30 May 2008 Volume 2008 : Issue 300 Contents: %RMS-F-DME from recall/output Re: %RMS-F-DME from recall/output Re: Connecting OS-X to OpenVMS? Re: Connecting OS-X to OpenVMS? Re: cron facility wanted for VMS Re: cron facility wanted for VMS Re: cron facility wanted for VMS Re: cron facility wanted for VMS Re: cron facility wanted for VMS Re: DEC Document Re: fibre channel tape drives accessed from multiple clusters Re: fibre channel tape drives accessed from multiple clusters Re: How to spot an orphan in VMS Re: How to spot an orphan in VMS LBR function result codes still not available Re: LBR function result codes still not available Re: LBR function result codes still not available Re: MAIL , unread messages and IMAP Re: Monitor Cluster Re: Monitor Cluster Moving disk on EVA from controller A to B? Re: OT: Unix equivalent of SET PROC/SUSPEND? Re: Price quote for Q-bus cards from Microvax 4000/200 Re: Price quote for Q-bus cards from Microvax 4000/200 Re: Price quote for Q-bus cards from Microvax 4000/200 Re: What's up with decuserve.org these past few days ? Re: What's up with decuserve.org these past few days ? ---------------------------------------------------------------------- Date: 29 May 2008 14:22:38 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: %RMS-F-DME from recall/output Message-ID: <2tuAoeXjKsQB@eisner.encompasserve.org> When I try to do recall/output from a detached process, I get %RMS-F-DME. On the same system it works fine from spawned subproceses, with the same number of commands in thier recall buffer, or more, or less. help/mess tells me to mess around with PIOPAGES, so I tried that. VMS 7.2-1 on a DEC 3000 Model 400S (upgrading is not an option). When I get home I'll try it on 8.3. Any ideas, or do I just need to keep boosting PIOPAGES? ------------------------------ Date: 29 May 2008 19:00:04 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: %RMS-F-DME from recall/output Message-ID: <483efd33$0$25017$607ed4bc@cv.net> In article <2tuAoeXjKsQB@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > > When I try to do recall/output from a detached process, I get > %RMS-F-DME. On the same system it works fine from spawned > subproceses, with the same number of commands in thier recall > buffer, or more, or less. help/mess tells me to mess around > with PIOPAGES, so I tried that. > > VMS 7.2-1 on a DEC 3000 Model 400S (upgrading is not an option). > When I get home I'll try it on 8.3. > > Any ideas, or do I just need to keep boosting PIOPAGES? > How are you using/creating this DETACHED process? I've created a command procedure: $ SET VERIFY $ SHOW DEFAULT $ SHOW TIME $ SHOW USER $ RECALL/ALL $ RECALL/OUTPUT=SYS$MANAGER:RECALL.TEST $ SHOW TIME $ EXIT and then I run it DETACHED with: $ RUN/DETACH/INPUT=TESTRECALL.COM SYS$SYSTEM:LOGINOUT.EXE - _$ /OUTPUT=SYS$MANAGER:TESTRECALL.LOG/ERROR=TESTRECALL.ERR ...and I get: $ SHOW DEFAULT SYS$SYSROOT:[SYSMGR] = SYS$SYSROOT:[SYSMGR] = SYS$COMMON:[SYSMGR] $ SHOW TIME 29-MAY-2008 14:55:39 $ SHOW USER OpenVMS User Processes at 29-MAY-2008 14:55:39.67 Total number of users = 1, number of processes = 12 Username Node Interactive Subprocess Batch SYSTEM A533U2 11 1 $ RECALL/ALL $ RECALL/OUTPUT=SYS$MANAGER:RECALL.TEST $ SHOW TIME 29-MAY-2008 14:55:39 $ EXIT SYSTEM job terminated at 29-MAY-2008 14:55:39.68 Accounting information: Buffered I/O count: 26 Peak working set size: 2704 Direct I/O count: 11 Peak virtual size: 171872 Page faults: 174 Mounted volumes: 0 RECALL has no effect in my test. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: Thu, 29 May 2008 17:06:07 -0400 From: JF Mezei Subject: Re: Connecting OS-X to OpenVMS? Message-ID: <483f1bd1$0$7237$c3e8da3@news.astraweb.com> Christoph Gartmann wrote: > Terminal commands are not an option. I am looking for something that can be > handeld by an average Mac user. We have a few hundred of them. So configuring > each single Mac isn't an option as well. If you use automount, you don't need "terminal commands". You need to configure this once and the MAC will automatically mount the NFS drives when it needs them. If the mac boots while the NFS server is down, but it doesn'T yetr need to access to those drives, the user won't know about it, and when the user tries to access the drive, if the NFS server is back up, the user gets in. With 10.4 and before, there is the netinfo database. Enter your mounts there and voila. With 10.5 Apple used a new config database enviropnment so the commands are different. Is the VMS data "public", or is it to be a per-user storage system ? ------------------------------ Date: Thu, 29 May 2008 20:17:32 -0700 (PDT) From: sean@obanion.us Subject: Re: Connecting OS-X to OpenVMS? Message-ID: <4768af6b-8803-4099-9649-ef67a61c42ec@79g2000hsk.googlegroups.com> On May 29, 9:57=A0am, VAXman- @SendSpamHere.ORG wrote: > In article <7dfff845-e0a9-4de8-88b7-5ca61070f...@s50g2000hsb.googlegroups.= com>, s...@obanion.us writes: > > >{...snip...} > >At the Bootcamp I used the CIFS/Samba that OpenVMS Engineering is > >releasing. > >http://h71000.www7.hp.com/network/CIFS_for_Samba.html > > I missed that session as I didn't arrive until late Tuesday eve. > > >I did not have a chance to do any file support testing, but simple > >drag-and-drop copy and file opening from an application from both Win > >XP and OS X 10.4 worked well. =A0We used both Standalone (uses local > >authentication) and Member (uses Windows Domain authentication) > >modes . =A0OS X has the advantage of mounting multiple file services > >using different credentials (domain/username/password): Windows only > >wants to use one set of credentials per system, so once you login to a > >Domain, only those credentials can be used (though there are some > >limited ways around this...). =A0There is also a Advanced Server > >conversion procedure, but it seemed a little limited and we gave them > >some good feedback. > > >Current version of CIFS for OpenVMS is 1.0, which doesn't support > >being a PDC or BDC, but it sounded like additional functionality was > >being worked on. > > On which version(s) of VMS will the CIFS 1.0 install and run? > > -- > VAXman- A Bored Certified VMS Kernel Mode Hacker =A0 VAXman(at)TMESIS(dot)= COM > > =A0 "Well my son, life is like a beanstalk, isn't it?" > > http://tmesis.com/drat.html Following the link I gave: "Use of the Common Internet File System requires OpenVMS Version 8.2 or later for AlphaServer systems, and OpenVMS V8.2-1 or later for Integrity server systems." ------------------------------ Date: Thu, 29 May 2008 18:05:49 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Re: cron facility wanted for VMS Message-ID: <1gC%j.7753$R_4.6437@newsb.telia.net> Keith Cayemberg wrote: > For those readers of this thread who are interested, here is my list > of OpenVMS compatible third-party Job Schedulers... An impressive list of tools !! Is it possible that these "lists" (you have posted other just as impressive lists of specific tools before) are available online somewhere ? Now I have to save a private copy every time... :-) Best Regards, Jan-Erik. > > Absyss - Visual TOM > http://www.absyss.com/produit-1.php > > Advanced Systems Concepts - ActiveBatch Enterprise > http://www.advsyscon.com/ > http://h71000.www7.hp.com/partners/asci/index.html > > Automation Technology Computing, Inc. (ATC) - Command File Scheduler > http://www.atcsoftware.com/ > > Axway - Synchrony Automator - formerly XOS - Axway Open Schedule > http://www.axway.com/products/synchrony_automator.php > > Badger Network Technologies Ltd - ActivityScheduler > http://www.activityscheduler.co.uk/ > > Batch Process Technologies, Inc. - BATCHES > http://www.bptech.com/batches1.htm > > BMC Software - CONTROL-M for Distributed Systems > http://www.bmc.com/products/proddocview/0,2832,19052_19429_23437_1521,00.html > > CA Job Management for OpenVMS > http://www.ca.com/us/products/product.aspx?id=1485 > > CRON PCSI Kit - Rohwedder OpenVMS Downloads > http://www.the-rohwedders.de/downloads/index.html > ftp://mvb.saic.com/freewarev80/cron/ > http://www.djesys.com/vms/mentor/cron.html > > Cybermation - is now a part of the CA Workload Automation > http://www.ca.com/us/content/campaign.aspx?cid=159142 > http://www.ca.com/us/workload-automation.aspx > http://web.archive.org/web/20051130084414/http://www.cybermation.com/products/jobscheduling/ > http://web.archive.org/web/20050412164332/http://www.cybermation.com/products/jobscheduling/agents/ > > JSS - Job Scheduling System > http://h21007.www2.hp.com/portal/site/dspp/menuitem.5179cc2b5bf6406ac6713f8da973a801/?productId=7175 > http://www.icam.com/ > > ISE Inc. - EnterpriseSCHEDULE > http://www.i-s-e.com/Products/EnterpriseSCHEDULE/ > http://h71000.www7.hp.com/partners/ise/index.html > http://www.i-s-e.com/docs/schedule/enterpriseschedule_brochure.pdf > > Itheon Ltd - TWS OpenVMS Extended Agent - Wayback Machine > http://web.archive.org/web/20050309033607/http://www.itheon.com/products/product_index.htm#tws > > JOB_DAEMON - Watch disks for files to trigger batch jobs > http://vms.process.com/scripts/fileserv/fileserv.com?JOB_DAEMON > > Kronos Scheduler - OpenVMS Freeware CD v4 > ftp://mvb.saic.com/freewarev40/kronos/ > > MVP Systems, Inc. - JAMS for OpenVMS > http://www.mvpsi.com/ > http://h71000.www7.hp.com/partners/mvpsi/index.html > > ORSYP S.A. - Dollar Universe - cross platform job scheduler batch > processing management > http://www.orsyp.com/ > http://h71000.www7.hp.com/partners/orsyp/index.html > > Redwood - Cronacle > http://www.redwood.com/products/cronacle/ > > Software and Management Associates (SMA) - OpCon/Xps > http://www.smausa.com/ > > Software Partners/32, Inc. - JOBSYS > http://www.sp32.com/service/jobsys/ > http://h71000.www7.hp.com/partners/software/index.html > > UC4 Applications Manager - formerly AppWorx Enterprise Scheduler > http://www.uc4.com/en/uc4-suite/ > http://www.uc4.com/en/uc4-info/appworx-is-now-uc4/ > > UC4 Operations Manager - formerly UC4:global > (UC4 formerly named SBB Software) > http://www.uc4.com/en/uc4-suite/ > > Voyager Software - NBS - Network Batch System > http://www.vgersoft.com/nbs/index.html > > XuiS Software Ltd. - EnterpriseSCHEDULE > http://www.xuis.com/products/schedule/ > http://h71000.www7.hp.com/partners/xuis/index.html > > Cheers! > > Keith Cayemberg ------------------------------ Date: 29 May 2008 14:08:24 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: cron facility wanted for VMS Message-ID: In article , AEF writes: > > But won't the logical be translated when the job is submitted? > The file name will be parsed, and only the physical device name and FID are stored in the queue. This was a problem for us when we had removable disks and the operators would try to execute jobs after moving the platter. The solution was to submit a .com file on the system disk that would execute a .com file given by name in P1. We asked DEC for the option not to store the physical name, but they told us it was done for security reasons. Details unknown, probably dates back to the days when it wasn't so easy for software to tell RMS to look only at inner mode names. ------------------------------ Date: Thu, 29 May 2008 13:19:50 -0500 From: David J Dachtera Subject: Re: cron facility wanted for VMS Message-ID: <483EF3C6.16725892@spam.comcast.net> Rob Brown wrote: > > On Wed, 28 May 2008, David J Dachtera wrote: > > > A useful trick is to get he job's /AFTER time using F$GETJPI() for > > (probably F$GETQUI?) Indeed. See? AIX has already ruined me! D.J.D. ------------------------------ Date: Thu, 29 May 2008 13:22:44 -0500 From: David J Dachtera Subject: Re: cron facility wanted for VMS Message-ID: <483EF474.DF640B7B@spam.comcast.net> Alfred Falk wrote: > > Keith Cayemberg wrote in > news:d6b625f4-6dfe-4b31-9e6f-85893797c4c1@l64g2000hse.googlegroups.com: > > > On May 27, 6:42 pm, Alfred Falk wrote: > >> marlow.and...@googlemail.com wrote in news:7f1ab094-5e0d-455a-88af- > >> 7b7172b2a...@m36g2000hse.googlegroups.com: > >> > >> > I am talking to some ops people to find out how our internally used > >> > product can be improved. One area they have mentioned is that there > >> > is a job that is currently launched manually. As we know, easily > >> > automated tedious boring repeatative jobs that are done manually > > >> > >> This generally works well. There are situations under which jobs may > >> fail to run - such as disk failures. Then the next submission won't > >> happen and you have to manually re-submit the job. A "cron" facility > >> can be more robust. > > > > > > In reference to the robustness of the OpenVMS Batch Facility: > > There are three aspects of the OpenVMS Batch Facility which I rarely > > see being mentioned when this theme comes up. > > I agree the VMS batch facility is quite robust. The problem I was > referring to involved situations where the drive containing the .COM > file for the batch job was on a disk that was not available at the time > the job was supposed to run. This has occurred for at least two reasons > 1. Disk actually had failed > 2. Cluster node serving the disk was not up (usually in cluster > re-boot.) > > So, if the time has come to execute the job, and the disk isn't there, > the job "runs" and fails. No repeated self-submission. Now you need to > manually re-submit the job. The answer to that is to set the queue /RETAIN=ERROR. The entry will be retained on the queue and can be "SET ENTRY/RELEASE"d when the drive where the .COM resides again becomes available. D.J.D. ------------------------------ Date: Thu, 29 May 2008 13:36:31 -0700 (PDT) From: Keith Cayemberg Subject: Re: cron facility wanted for VMS Message-ID: <5c0b1c06-c8ae-473c-8421-9f32933604e5@27g2000hsf.googlegroups.com> On May 29, 7:25 pm, AEF wrote: > On May 29, 11:18 am, Keith Cayemberg wrote: > > > > > On May 28, 8:26 pm, Alfred Falk wrote: > > > > Keith Cayemberg wrote innews:d6b625f4-6dfe-4b31-9e6f-85893797c4c1@l64g2000hse.googlegroups.com: > > > > > On May 27, 6:42 pm, Alfred Falk wrote: > > > >> marlow.and...@googlemail.com wrote in news:7f1ab094-5e0d-455a-88af- > > > >> 7b7172b2a...@m36g2000hse.googlegroups.com: > > > > >> > I am talking to some ops people to find out how our internally used > > > >> > product can be improved. One area they have mentioned is that there > > > >> > is a job that is currently launched manually. As we know, easily > > > >> > automated tedious boring repeatative jobs that are done manually > > > > > > > >> This generally works well. There are situations under which jobs may > > > >> fail to run - such as disk failures. Then the next submission won't > > > >> happen and you have to manually re-submit the job. A "cron" facility > > > >> can be more robust. > > > > > In reference to the robustness of the OpenVMS Batch Facility: > > > > There are three aspects of the OpenVMS Batch Facility which I rarely > > > > see being mentioned when this theme comes up. > > > > I agree the VMS batch facility is quite robust. The problem I was > > > referring to involved situations where the drive containing the .COM > > > file for the batch job was on a disk that was not available at the time > > > the job was supposed to run. This has occurred for at least two reasons > > > 1. Disk actually had failed > > > 2. Cluster node serving the disk was not up (usually in cluster > > > re-boot.) > > > > So, if the time has come to execute the job, and the disk isn't there, > > > the job "runs" and fails. No repeated self-submission. Now you need to > > > manually re-submit the job. > > > Hmm, actually I see this as a problem not of the Batch Facility but > > rather the system configuration or the way the Batch Facility is being > > used. If Host-Based Volume Shadowing is enabled for your cluster then > > placing your COM file on a shadow set, and using AUTOSTART execution > > queues should generally insure the COM is always available even if you > > are using self-submitting jobs. Another possibility without installing > > HBVS is placing your COM file on a local disk on every node in your > > cluster for which your queue is setup to fail over with AUTOSTART. The > > COM file is then submitted using a directory logical defined as a > > "Search List" which will look for the COM file in that list of > > directories until it finds the file. Such a directory logical would > > then also be used for defining the path for the job's logfile as well. > > The directory logical can be defined on each node independently or > > defined as a "Cluster Logical" Cluster Logicals are also quite useful > > for various fail-over schemes, especially when you are using a third > > party application which is not cluster-aware such as Sybase on > > OpenVMS. > > But won't the logical be translated when the job is submitted? > > I don't have any VMS clusters, and I'm running VMS V6.2, and I get the > following: > > $ DEFINE COM_PATH DSA1:[FELDMAN],DSA0:[FELDMAN] > $ SUBMIT/HOLD/NOPRINT COM_PATH:SQ > Job SQ (queue IDS07$QUE, entry 757) holding > $ SHOW ENTRY/FULL 757 > Entry Jobname Username Blocks Status > ----- ------- -------- ------ ------ > 757 SQ SYSTEM Holding > On available batch queue IDS07$QUE > Submitted 29-MAY-2008 13:15:44.26 /KEEP /LOG=DSA0:[SYS0.] > [SYSMGR]SQ.LOG; /NOPRINT /PRIORITY=100 > File: _DSA1:[FELDMAN]SQ.COM;3 > $ > > The logical name is translated before the job runs. Is there some > reason it would be different in a cluster? I can see this working if > the disk dies before you submit. I can also see this working if you > have a DISPATCHER batch job submitting jobs without the /HOLD or / > AFTER qualifiers, but not if you use the self-submitting method. But > if the disk dies between the time of submission and the time of > execution, I'd think it would fail. > > Of course if a disk dies (assuming no shadowing is in effect), you've > probably got bigger problems. And what if the disk dies when the job > is already running? You can't blame QUEUE_MANAGER for that! > > [...] > > > Cheers! > > > Keith Cayemberg > > AEF Yes, you're quite right about the logical name translation. I wasn't thinking it through when I added that thought to my discussion.If I could think of a place to put the encapsulation file where it's always available (Galaxy-base shared memory RAM Disk?). Then the logical translation would then first occur in the encapsulation file when it is running in the queue, and then find an available copy of the COM file using the search-list logical. I suppose HBVS is really the better solution. :-) Cheers! Keith Cayemberg ------------------------------ Date: Fri, 30 May 2008 00:26:07 +0200 From: Marc Van Dyck Subject: Re: DEC Document Message-ID: Tom Linden expressed precisely : > On Mon, 19 May 2008 07:44:44 -0700, VAXman- <@SendSpamHere.ORG> wrote: > >> I did some work for TTI. I'll fire off an email to Dan Esbensen if you'd >> like or I can forward his email to you. > > Please do. You might also suggest that maybe it would be a good idea if they > don't want to or can't support Document that they release it as open source > like Matt did with MX That would at least give someone a chance to try a port to integrity. Anyone remembers DECinspect ? -- Marc Van Dyck ------------------------------ Date: Fri, 30 May 2008 00:14:02 +0200 From: Marc Van Dyck Subject: Re: fibre channel tape drives accessed from multiple clusters Message-ID: wayne.sewell@gmail.com explained : > On May 26, 3:41 pm, Kari Uusimäki > wrote: >> Colin Butcher wrote: >>> The FC protocol moves data between devices. That's all it's designed to do. >>> The way you set the infrastructure up determines which systems can see >>> which devices. That's what "zoning" in the FC switches does (it's analogous >>> to VLANs in a data network). In a SAN infrastructure where the zoning >>> allows all HBAs to see all tape devices then you will have to implement >>> some form of access control to ensure synchronised and serialised access to >>> the available pool of tape drives. >> >>> Do beware of having Windows boxes capable of seeing the tape and robot >>> devices as well as your VMS systems - the Windows removable storage service >>> and the device drivers have a nasty habit of probing the tape and robot >>> devices every so often, which can play havoc with operations in progress. >>> It's easy enough to fix - just disable the relevant services and device >>> drivers in the Windows boxes, or set up the zoning so that the Windows >>> boxes cannot see the tape devices. >> >>> If you choose to have all your systems see all your storage devices or tape >>> devices then you have to deal with the consequences by ensuring that you >>> don't have multiple systems attempting to access the same device at the >>> same time. It's not a problem that's unique to tapes. Disc storage arrays >>> implement "device presentation" that describe which HBA WWIDs (systems) can >>> access which available storage units (see the EVA Vdisk presentations or >>> look at selective presentation in HSGs). Tapes don't implement device >>> presentation as far as I'm aware - and while it might be a useful concept >>> (presentations being a little easier to work with than SAN zoning) you'd >>> still have to arbitrate access to the tapes if more than one system can see >>> the tapes at any given instant in time. >>> In a VMS environment that's what ABS/MDMS does for you. ABS uses network >>> communications to arbitrate access to the tape devices by having one (or >>> more for redundancy) ABS servers allocate tape devices to client systems, >>> the ABS servers manage the tapes and moving them around using the robot, >>> then the ABS clients perform the backup functions directly to the tapes, >>> then the ABS servers take care of the tape moving again. >>> Alternatively you should be able to write something pretty simple to >>> synchronise access to the tape devices and robots, then used BACKUP as and >>> when you need to. All you need to do is keep track of the tapes, robots and >>> backup jobs across the separate clusters. >>> You could also control tape access by using SAN zoning in the SAN switches, >>> thus restricting access from a single cluster to a single known set of >>> tapes, however you'd have to change the SAN zoning if you needed to make >>> those tapes available to other nodes / clusters. >>> However, why bother doing all that when you can buy the ABS server and >>> client components? It's what I've done for the big systems I've been >>> designing and building recently. ABS has been around for a good few years >>> now. It works pretty well on the whole. >>> It's also worth reading the SAN design reference guide to understand SAN >>> zoning and a few other things. See here: >>> http://h20000.www2.hp.com/bizsupport/TechSupport/DocumentIndex.jsp?co... >>> It's not that difficult once you understand what's going on and why it all >>> works as it does, then figure out what mechanisms you need to use to >>> achieve what's needed. >> >> With modern tape libraries you can do also do selective presentation of >> the tape drives (and the robotic). That will help somewhat. Then there >> is also a possibility to use different zoning for different needs. E.g. >> when you want to backup your VMS cluster you use one zone configuration >> and when you are done with that you change the zoning configuration to >> another one which will give access to the tape library for a winbloze >> cluster and so on. That kind of a zoning reconfiguration can be >> automated. There aren't many other means of synchronizing tape drive >> access in a heterogenous SAN on the SAN or OS level. Backup applications >> like ABS can keep track of tape drive access on the application level. > > Yes, I understand about the zoning and reconfiguration and such. This > particular customer refuses to do that, wants all jukeboxes available > to all vmsclusters simultaneously. He doesn't have any foreign > systems in the SAN. Basically I will need to add the tape drive > locking to tapesys. Advance warning for die-hard technologists : I'm going to simplify a lot ... You must know that Fibre Channel is, to some effect, the implementation of the SCSI protocol on a single wire. In the SCSI protocol, there is a pair of commands "reserve/release" that can be used to restrict the usage of a device by a particular host. When a "reserve" command has been sent to a device by a host, every other host trying to allocate that device will receive a "device is busy" error. Until the host sends a "release" command. We have implemented those two commands into two very simple programs, and have inserted calls to those programs at strategic points of our DCL backup jobs (SLS/DCSC). All our tape drives (Storagetek 9840 & 9940 models) are on a switch, visible from all our OpenVMS hosts, and we never had any allocate collision since then (almost a year ago). With such a delay without encountering problems, I suppose we can assume that it is safe... Unfortunately, that trick is not going to serve us very long, since SLS is not ported to Integrity... Anyone over here having any kind of experience with the openVMS netbackup client ? -- Marc Van Dyck ------------------------------ Date: Thu, 29 May 2008 16:24:38 -0700 (PDT) From: wayne.sewell@gmail.com Subject: Re: fibre channel tape drives accessed from multiple clusters Message-ID: <804ef237-28ab-4a50-b468-085a89e35e41@a9g2000prl.googlegroups.com> On May 29, 5:14 pm, Marc Van Dyck wrote: > wayne.sew...@gmail.com explained : > > > > > On May 26, 3:41 pm, Kari Uusim=E4ki > > wrote: > >> Colin Butcher wrote: > >>> The FC protocol moves data between devices. That's all it's designed t= o do. > >>> The way you set the infrastructure up determines which systems can see= > >>> which devices. That's what "zoning" in the FC switches does (it's anal= ogous > >>> to VLANs in a data network). In a SAN infrastructure where the zoning > >>> allows all HBAs to see all tape devices then you will have to implemen= t > >>> some form of access control to ensure synchronised and serialised acce= ss to > >>> the available pool of tape drives. > > >>> Do beware of having Windows boxes capable of seeing the tape and robot= > >>> devices as well as your VMS systems - the Windows removable storage se= rvice > >>> and the device drivers have a nasty habit of probing the tape and robo= t > >>> devices every so often, which can play havoc with operations in progre= ss. > >>> It's easy enough to fix - just disable the relevant services and devic= e > >>> drivers in the Windows boxes, or set up the zoning so that the Windows= > >>> boxes cannot see the tape devices. > > >>> If you choose to have all your systems see all your storage devices or= tape > >>> devices then you have to deal with the consequences by ensuring that y= ou > >>> don't have multiple systems attempting to access the same device at th= e > >>> same time. It's not a problem that's unique to tapes. Disc storage arr= ays > >>> implement "device presentation" that describe which HBA WWIDs (systems= ) can > >>> access which available storage units (see the EVA Vdisk presentations = or > >>> look at selective presentation in HSGs). Tapes don't implement device > >>> presentation as far as I'm aware - and while it might be a useful conc= ept > >>> (presentations being a little easier to work with than SAN zoning) you= 'd > >>> still have to arbitrate access to the tapes if more than one system ca= n see > >>> the tapes at any given instant in time. > >>> In a VMS environment that's what ABS/MDMS does for you. ABS uses netwo= rk > >>> communications to arbitrate access to the tape devices by having one (= or > >>> more for redundancy) ABS servers allocate tape devices to client syste= ms, > >>> the ABS servers manage the tapes and moving them around using the robo= t, > >>> then the ABS clients perform the backup functions directly to the tape= s, > >>> then the ABS servers take care of the tape moving again. > >>> Alternatively you should be able to write something pretty simple to > >>> synchronise access to the tape devices and robots, then used BACKUP as= and > >>> when you need to. All you need to do is keep track of the tapes, robot= s and > >>> backup jobs across the separate clusters. > >>> You could also control tape access by using SAN zoning in the SAN swit= ches, > >>> thus restricting access from a single cluster to a single known set of= > >>> tapes, however you'd have to change the SAN zoning if you needed to ma= ke > >>> those tapes available to other nodes / clusters. > >>> However, why bother doing all that when you can buy the ABS server and= > >>> client components? It's what I've done for the big systems I've been > >>> designing and building recently. ABS has been around for a good few ye= ars > >>> now. It works pretty well on the whole. > >>> It's also worth reading the SAN design reference guide to understand S= AN > >>> zoning and a few other things. See here: > >>>http://h20000.www2.hp.com/bizsupport/TechSupport/DocumentIndex.jsp?co..= . > >>> It's not that difficult once you understand what's going on and why it= all > >>> works as it does, then figure out what mechanisms you need to use to > >>> achieve what's needed. > > >> With modern tape libraries you can do also do selective presentation of= > >> the tape drives (and the robotic). That will help somewhat. Then there > >> is also a possibility to use different zoning for different needs. E.g.= > >> when you want to backup your VMS cluster you use one zone configuration= > >> and when you are done with that you change the zoning configuration to > >> another one which will give access to the tape library for a winbloze > >> cluster and so on. That kind of a zoning reconfiguration can be > >> automated. There aren't many other means of synchronizing tape drive > >> access in a heterogenous SAN on the SAN or OS level. Backup application= s > >> like ABS can keep track of tape drive access on the application level. > > > Yes, I understand about the zoning and reconfiguration and such. This > > particular customer refuses to do that, wants all jukeboxes available > > to all vmsclusters simultaneously. He doesn't have any foreign > > systems in the SAN. Basically I will need to add the tape drive > > locking to tapesys. > > Advance warning for die-hard technologists : I'm going to simplify > a lot ... > > You must know that Fibre Channel is, to some effect, the implementation > of the SCSI protocol on a single wire. > > In the SCSI protocol, there is a pair of commands "reserve/release" > that can be used to restrict the usage of a device by a particular > host. When a "reserve" command has been sent to a device by a host, > every other host trying to allocate that device will receive a > "device is busy" error. Until the host sends a "release" command. > > We have implemented those two commands into two very simple programs, > and have inserted calls to those programs at strategic points of our > DCL backup jobs (SLS/DCSC). All our tape drives (Storagetek 9840 & 9940 > models) are on a switch, visible from all our OpenVMS hosts, and we > never had any allocate collision since then (almost a year ago). With > such a delay without encountering problems, I suppose we can assume > that it is safe... > > Unfortunately, that trick is not going to serve us very long, since > SLS is not ported to Integrity... No problem. Tapesys has been running on integrity for a couple of years. Several former SLS customers are running on it now. TS includes a database conversion from SLS. I will have the TAPE OPER LOCK command running in a few days, allowing locking of the device across clusters from within tapesys and from the dcl command line. Also, you should be able to use your "reserve/release" programs with tapesys as well. ------------------------------ Date: Thu, 29 May 2008 20:05:19 GMT From: John Santos Subject: Re: How to spot an orphan in VMS Message-ID: <30E%j.30575$9H6.30426@trnddc04> marlow.andrew@googlemail.com wrote: > John Santos wrote: > >>If the process looks to VMS like it is running on a serial terminal >>(virtual, telnet, ssh, LAT, etc.) then possibly the process is getting >>disconnected when the user closes the window. This would show up in >>SHOW USER/FULL as a disconnected session. The user could reconnect to >>the process and resume where he had left off by logging into the system >>again (or starting up another "xterm" session) and then using the >>CONNECT command to reconnect to the virtual terminal (VTAxxx: device >>displayed in the "SHOW USER/FULL" output.) If you login using the >>normal "LOGINOUT" program, it will ask you if you want to connect to >>any existing disconnected processes when you log in, but some process >>connection mechanisms might bypass this, forcing you to manually >>reconnect. You can only connect to a disconnected terminal from the >>same account it was originally logged into. > > > This is just the sort of info I was after. When this problem happens > what I want to do is to identify the process and kill it. I dont want > to reconnect to it. What will happen is some OP user or other will > accidently disconnect their Reflection session then some other OP user > will have to recover from this. > > >>Disconnected processes go away after a timeout, determined by a >>sysgen parameter, TTY_TIMEOUT, default value 900 seconds (15 minutes.) > > > I am not sure that this is happening but even if it is, we need to be > able to find and kill the process well within that 15 min It is possible to configure terminals to *NOT* use the virtual terminal facility. The method depends on whether it is a permanent terminal (i.e. a serial port), or one created dynamically, such as a LAT terminal, or a telnet terminal. For Telnet terminals, the method depends on the IP stack. It would either be some sort of setting in the telnet config or by setting the characteristics appropriately on the template device. (e.g. for the HP TCP/IP stack. TNA0: is the template. I *think* you do a $ set terminal/permanent tna0:/nodisconnect to disable it. For the TCPware stack, you define a logical name in telnet_control.com.) If the terminal is set nodisconnect, and the session goes away, the process gets killed immediately. (The terminal disconnect mechanism was originally designed for dialup, but is useful in other contexts as well. For example, I work from home a lot via VPN; when my ISP decides to lose routing to work, the VPN tunnel dies, but when it comes back, I can telnet back into the systems at work and reconnect to the detached processes and not lose anything.) > > -Andrew Marlow > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Thu, 29 May 2008 17:11:26 -0400 From: JF Mezei Subject: Re: How to spot an orphan in VMS Message-ID: <483f1d0f$0$7237$c3e8da3@news.astraweb.com> John Santos wrote: > If the terminal is set nodisconnect, and the session goes away, the > process gets killed immediately. But if the "lock" is a temporary file, then when the process gets killed, that process won't have the time to delete that file. If it uses a temporary file as a "lock" instead of the real locks VMS provides, then you would need a permanent detached process that checks to see if that file is opened every minute or so, and deletes it if it is not opened by any process (allowing another process to then creating a new "lock" file. That is how unix works in multi-node applications since unix lacks internode lock mechanisms. ------------------------------ Date: Thu, 29 May 2008 15:54:00 -0700 (PDT) From: Rich Jordan Subject: LBR function result codes still not available Message-ID: <8303a368-f427-4ba2-b4fb-ff085225b20a@k37g2000hsf.googlegroups.com> Back in 1991 someone posted a complaint about the LBR$_* function return codes not being present in the language specific include files. In 1999 after another complaint, Hoff indicated he had filed a problem report with OpenVMS engineering to get it fixed. Today I had to write a program to play with libraries. Unfortunately it looks like those return codes are _still_ not available in the language specific include files; I checked Macro, C, and BASIC on my V7.3-2 system, then to be certain did the same on a V8.3 (Alpha) box. Same results; the codes are not there. I guess using the LBR$ functions in a user written program must be a pretty rare event. Whats the best way to try and get this back on someone's burner? I don't have real VMS support any more (just DSPP access) and if time allows I'll try to get something done tomorrow. Any other options? If Hoff's internal report garnered no results I'm not hopeful about anything I do (and it won't help the current situation in any case). Comments about this being proof VMS is dead and has been since 1991 please pipe to NLA0:. There's enough noise in this group already. Thanks Rich ------------------------------ Date: Thu, 29 May 2008 17:34:24 -0700 From: "Tom Linden" Subject: Re: LBR function result codes still not available Message-ID: On Thu, 29 May 2008 15:54:00 -0700, Rich Jordan wrote: > Back in 1991 someone posted a complaint about the LBR$_* function > return codes not being present in the language specific include > files. In 1999 after another complaint, Hoff indicated he had filed a > problem report with OpenVMS engineering to get it fixed. > > Today I had to write a program to play with libraries. Unfortunately > it looks like those return codes are _still_ not available in the > language specific include files; I checked Macro, C, and BASIC on my > V7.3-2 system, then to be certain did the same on a V8.3 (Alpha) box. > Same results; the codes are not there. > > I guess using the LBR$ functions in a user written program must be a > pretty rare event. Whats the best way to try and get this back on > someone's burner? I don't have real VMS support any more (just DSPP > access) and if time allows I'll try to get something done tomorrow. > Any other options? If Hoff's internal report garnered no results I'm > not hopeful about anything I do (and it won't help the current > situation in any case). > > Comments about this being proof VMS is dead and has been since 1991 > please pipe to NLA0:. There's enough noise in this group already. In which module do you expect to find those? FREJA> pipe lib/list sys$library:PLI$STARLET.TLB|grep lbr $LBRCTLTBL $LBRDEF LBR$CLOSE LBR$DELETE_DATA LBR$DELETE_KEY LBR$FIND LBR$FLUSH LBR$GET_HEADER LBR$GET_HELP LBR$GET_HISTORY LBR$GET_INDEX LBR$GET_RECORD LBR$INI_CONTROL LBR$INSERT_KEY LBR$LOOKUP_KEY LBR$LOOKUP_TYPE LBR$MAP_MODULE LBR$OPEN LBR$OUTPUT_HELP LBR$PUT_END LBR$PUT_HISTORY LBR$PUT_RECORD LBR$REPLACE_KEY LBR$RET_RMSSTV LBR$SEARCH LBR$SET_INDEX LBR$SET_LOCATE LBR$SET_MODULE LBR$SET_MOVE LBR$UNMAP_MODULE LBRUSR > > Thanks > > Rich -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Thu, 29 May 2008 21:31:58 -0400 From: =?ISO-8859-15?Q?Arne_Vajh=F8j?= Subject: Re: LBR function result codes still not available Message-ID: <483f5904$0$90264$14726298@news.sunsite.dk> Tom Linden wrote: > On Thu, 29 May 2008 15:54:00 -0700, Rich Jordan wrote: >> Back in 1991 someone posted a complaint about the LBR$_* function >> return codes not being present in the language specific include >> files. In 1999 after another complaint, Hoff indicated he had filed a >> problem report with OpenVMS engineering to get it fixed. >> >> Today I had to write a program to play with libraries. Unfortunately >> it looks like those return codes are _still_ not available in the >> language specific include files; I checked Macro, C, and BASIC on my >> V7.3-2 system, then to be certain did the same on a V8.3 (Alpha) box. >> Same results; the codes are not there. > In which module do you expect to find those? > > FREJA> pipe lib/list sys$library:PLI$STARLET.TLB|grep lbr > $LBRCTLTBL > $LBRDEF > LBR$CLOSE > LBR$DELETE_DATA LBR$* function <> LBR$_* return code I would say that lbrdef would make sense. Arne ------------------------------ Date: Tue, 27 May 2008 08:03:49 -0500 From: Rick Sanders Subject: Re: MAIL , unread messages and IMAP Message-ID: > Check your IMAP client settings to see if it is deleting the > messages after it grabs them. Generally you don't want to > keep copies on both your server and your client. I believe that is a POP client setting ("leave messages on server"). An IMAP server does not delete messages unless you manually mark them for deletion. When you read a message with an IMAP client the server marks it as SEEN but leaves it in the mailbox. -Rick ** Posted from http://www.teranews.com ** ------------------------------ Date: Thu, 29 May 2008 13:24:42 -0500 From: David J Dachtera Subject: Re: Monitor Cluster Message-ID: <483EF4EA.7467EA8E@spam.comcast.net> Jack wrote: > > When I run the utility "Monitor Cluster" in one of my 40 nodes cluster, I > see that nodes apear on more than one line in most of the diaplay, i.e. on > "memory use". > I mean the same node utilizes -80% and in another line it says -75%. > > What is that supose to say? Look for an ECO kit with a MONITOR fix in it. D.J.D. ------------------------------ Date: Thu, 29 May 2008 17:02:12 -0700 (PDT) From: AEF Subject: Re: Monitor Cluster Message-ID: <1e8cb395-8c39-46e0-83e5-1ae520716082@m45g2000hsb.googlegroups.com> On May 29, 7:04 am, "Jack" wrote: > When I run the utility "Monitor Cluster" in one of my 40 nodes cluster, I > see that nodes apear on more than one line in most of the diaplay, i.e. on > "memory use". > I mean the same node utilizes -80% and in another line it says -75%. > > What is that supose to say? > > Regards > Jack Well, you're doing pretty well with negative memory usage! You can offload all your memory to other more needy machines and it will be transparent to your users! Seriously, MONITOR does not take a complete snapshot at any given instance. It scans. So it was probably 80% during one scan and 75% in another scan, and perhaps your system is too busy. Try running MONITOR at priority 15 and see if that helps, or run it on a quiescent cluster member. Does it always do this? Every screen has multiple listings of the same node? Is it the same node that MONITOR is running on that gets doubled? Please provide some more details. AEF ------------------------------ Date: 30 May 2008 06:54:39 GMT From: yehavi@vms.huji.ac.il Subject: Moving disk on EVA from controller A to B? Message-ID: <2008May30.065439@hujicc> Hello, I have an EVA-5,000 with a few systems connected to it. Recently, after I got complains of slow response during peak hours, I've found that one controller is less used than the other (using EVAperf and looking for the host port stats). When looking at the virtual disks definitions I see that most disks are defined as "Path A preferred" while very few are defined as "path B preffered". I've tried two things to move some more disks from A to B, without success: - On the VMS: Set device/path=xxx/switch; after the command I do SHOW DEVICE and see that the new path is unavailable and the disk returns to the old path. - changing the preffered path on the EVA. however, the managing controller is left as A. Any idea how to force the EVA to change the managing controller for a disk? Thanks! __Yehavi: ------------------------------ Date: 29 May 2008 15:25:14 -0400 From: Rich Alderson Subject: Re: OT: Unix equivalent of SET PROC/SUSPEND? Message-ID: "David Weatherall" writes: > Tom Linden wrote: >> On Fri, 23 May 2008 05:09:26 -0700, Simon Clubley >> wrote: >>> For example, I have emacs configured to exit on Ctrl-Z (like >>> EDT/EVE) instead of returning to the shell. >> Most people use ctrl-z and Meta-z to scroll up or down. > OK I'll show my ignorance. Where's the meta key on my LK2/400 or PC > keyboard? :) As others have pointed out, the key has been defined as a prefix character equivalent to holding down a shift key labeled since the early days of TECO EMACS. The Stanford/Knight keyboard, which originated at the Stanford Artificial Intelligence Laboratory and was taken to the MIT AI Lab to Tom Knight, the shift keys labeled and turned on the 200 bit and the 400 bit respectively--these were PDP-10 systems and used a 12-bit character code of which the bottom 7 bits were a graphically-extended ASCII (no ASCII "control characters", extra non-alphanumeric characters). The use of for was a poor substitute. On PC keyboards, the key is defined as in GNU Emacs. IIRC, on LK201 keyboards, the key was often so defined, but that may have been true only under the X Window System; similarly, on Sun keyboards the key was frequently used as under X. I miss the SAIL keyboard. -- Rich Alderson Current maintainer, MIT TECO EMACS (v. 170) "You get what anybody gets. You get a lifetime." news@alderson.users.panix.com --Death, of the Endless ------------------------------ Date: 29 May 2008 14:11:30 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Price quote for Q-bus cards from Microvax 4000/200 Message-ID: In article , "janprunk@gmail.com" writes: > Hello ! > > Someone suggested to me that I should try this discussion group to get > a price quote for my Q-bus cards from the Microvax 4000/200. > The parts will be sent from Europe. Those boards are basically worth the value of shipping, depending on exactly which boards, and probably only to others in Europe. ------------------------------ Date: Thu, 29 May 2008 13:41:50 -0500 (CDT) From: sms@antinode.info (Steven M. Schweda) Subject: Re: Price quote for Q-bus cards from Microvax 4000/200 Message-ID: <08052913415014_2020CE0A@antinode.info> From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) > In article , "janprunk@gmail.com" writes: > > Someone suggested to me that I should try this discussion group to get > > a price quote for my Q-bus cards from the Microvax 4000/200. > > > The parts will be sent from Europe. > > Those boards are basically worth the value of shipping, depending > on exactly which boards, and probably only to others in Europe. Well, "depending" covers a lot, including major exceptions to the main "value of shipping" claim. A SCSI card is the only one which would be likely to have any significant value. People pay hundreds of US dollars (or even Euros) for a card like a CMD CQD223/TM. One recent example of a comparable card: http://cgi.ebay.com/_W0QQitemZ170218796028QQ Many others sell for around $10, if at all. (Anyone want some CXY08 cards? I have a bunch.) ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Thu, 29 May 2008 23:17:39 +0300 From: =?ISO-8859-1?Q?Kari_Uusim=E4ki?= Subject: Re: Price quote for Q-bus cards from Microvax 4000/200 Message-ID: <483f0f6a$0$23828$9b536df3@news.fv.fi> janprunk@gmail.com wrote: > Hello ! > > Someone suggested to me that I should try this discussion group to get > a price quote for my Q-bus cards from the Microvax 4000/200. I have a > fully functional server, and would consider reselling it in whole or > just parts of it for a good price. Tell me what you need and how much > you are willing to spend and I will dissamble the server and look for > part numbers. I got a good profile at Ebay and we could end the sale > there. The parts will be sent from Europe. You can also contact me > directly to my email address. > > Kind regards, > Jan Prunk It would be very good to know which boards you have in your VAX4000-200. It is easy to find the part numbers on the boards and then post a list here. You'll find the part numbers on most boards printed on the outer edge, which has the handles. The part number has a letter and four digits e.g. M7555 or M8189. Regards, Kari ------------------------------ Date: Thu, 29 May 2008 19:34:06 -0400 From: bradhamilton Subject: Re: What's up with decuserve.org these past few days ? Message-ID: <483F3D6E.3020604@comcast.net> R.A.Omond wrote: > Haven't been able to access Eisner for a good > few days now, and I've seen no mention of anything > here ... > Hmmm...I've had no trouble accessing it recently... I just cleared my browser's cache and tried again - I had no problem accessing NOTES: SSH and TELNET to eisner.decuserve.org work fine, as well - all this as of 29-MAY at 1930 EDT (US). ------------------------------ Date: Thu, 29 May 2008 19:40:55 -0400 From: bradhamilton Subject: Re: What's up with decuserve.org these past few days ? Message-ID: <483F3F07.2030201@comcast.net> R.A.Omond wrote: > Haven't been able to access Eisner for a good > few days now, and I've seen no mention of anything > here ... Just an FYI to those who attempted to have Encompass investigate this problem - EISNER:: and Encompass parted ways a number of years ago. As noted in this thread, Steve Arnold is the point of contact for system/network-related issues. For those of you who haven't "visited" in a while, come on by and check out the web-enabled NOTES interface - it's quite impressive. ------------------------------ End of INFO-VAX 2008.300 ************************