Info-Vax-REQUEST@KL.SRI.COM.UUCP (05/06/87)
Info-Vax Digest Wednesday, 6 May 1987 Volume 0 : Issue 11 Today's Topics: SETUP COMMAND PROCEDURE Bells (But no whistles) A partial solution to Digest Format UIS Software on MicroVAX Personal name in mail re: shared files in Fortran Re: Preparation for VMS 5.0 Re: faster VMS spawn Editors... Re: How do I identify my cpu? ---------------------------------------------------------------------- Date: Tue, 5 May 87 19:35 O From: <BEN%TECHMAX.BITNET@wiscvm.wisc.edu> (Benjamin Pashkoff) Subject: SETUP COMMAND PROCEDURE If I could receive a copy a the SETUP procedure talked about, it would greatly expedite another application I am writing. ------------------------------------------------------------------- |Ben Pashkoff xx xxxxxxxx | |System Engineer xx xxxxxx | |Biomedical Engineering xx xx | |Technion, IIT xx xx | |Haifa, Israel 32000 xxxx | |BEN@TECHMAX.BITNET xx | ------------------------------ Date: Tue, 5 May 87 13:52 EST From: Thomas_R._Blake <TBLAKE%BINGVAXA.BITNET@wiscvm.wisc.edu> Subject: Bells (But no whistles) > From: James R Vallino <SIEMENS!JRV@PRINCETON.EDU> > Subject: How do you ring bell in DCL file? > I would like to have the terminal bell rung from within a DCL command > file. Is there a way to specify control characters within a string > used with a 'write sys$output' statement? Can the control character be > entered "raw" into the string or is there a character escape mechanism? > I tried everything I could think of and didn't see anything in the orange > wall of manuals. Right now I 'type' a file which has a single bell character > in it. An example can be found on DCL-6 under = (Assignment Statement) $ BELL[0,32] = %X07 Then you can do a ... $ WRITE SYS$OUTPUT BELL TBLAKE@BINGVAXB.BITNET Thomas R. Blake TBLAKE@suny-bing.CSNET SUNY Binghamton ------------------------------ Date: Tue, 5 May 87 10:46:26 PDT From: xrjjm%dirbe.span@Jpl-VLSI.ARPA Subject: A partial solution to Digest Format Comment: Begin User Supplied Mail Headers. *Site: NASA Goddard Space Flight Center - Greenbelt, Maryland, USA. *Position: 76 Deg. 52' 28.5" West, 38 Deg. 59' 59.8" North. *From: John J. McMahon, Systems Programmer, STX - ST Systems Corporation. *Project: COBE Science Data Room (CSDR), Code 401.1 *Reply-To: (Arpa-Internet) XRJJM%CSDR.SPAN@JPL-VLSI.ARPA *Reply-To: (Bitnet) ZMJJM@SCFVM *Reply-To: (Span/Physnet/Hepnet) 6173::XRJJM = CSDR::XRJJM (Node 6.29) *Reply-To: (TEXnet) UTADNX::UTSPAN::CSDR::XRJJM For those of you using the Vanilla VMS Mailer, someone pointed out a while back that one of the best ways to handle a digest is to do the following: FOWARD/EDIT (Your ID) Edit the digest EXIT (Thus sending the edited digest back to you) DELETE (The original digest) This allows you to keep the pieces you want in MAIL, and at the same time gives you some measure of control over what you delete/keep. I don't know who originally suggested it on INFO-VAX... but it works great! Regards, ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v John J. McMahon (Fast-Eddie) Disclaimer: Views expressed in this letter are my own, and are not meant to represent the views of my employers. ------------------------------ Date: Tue, 5 May 87 12:34:50 EDT From: "Patrick J. O'Neill" <poneill@AMSAA.ARPA> Subject: UIS Software on MicroVAX We have a Microvax (actually a VAXstation II) running Microvms version 4.5. We have a layered product that requires UIS (User Interface Services) version 3.0 or 3.1. Alas, when we dump some headers of UISSHR.EXE, it appears we have version 1.5 or so of UIS. My question is, "is UIS an integral part of VMS , or is it separately ordered ? If Part of VMS, do you pick it off the release tapes a la the options like USER,PROG,SYSP, UTIL, etc. ? ALso, why is the documentation so poor in this area (my last question is probably rhetorical!) " Thank you in advance for any help ! Patrick O'Neill ------------------------------ Date: Tue, 5 May 87 12:13:57 PDT From: awr@Juliet.Caltech.Edu (Bruce W. Rossiter) Reply-to: Bruce%Caltech.Bitnet@Juliet.Caltech.Edu (Bruce Rossiter) Subject: Personal name in mail Subject: Re: bbs,mail questions... > i know that if i define a logical name for a user (ie define kevin kashford) > and then send mail to kevin, only the name "kevin" will appear in the > receivers to: section. is there any way to do the same with the from: > section??? i have tried several diff ways and have been unable to do this. It all depends. If you are using vanilla VMS Mail, you should be able to SET PERSONAL NAME to whatever you want. Mail will be sent with your user id still, but will also give your personal name. See the header of this message, for example. Some other mail services allow similar things. Software Tools Mail (what I'm using -- Thanks Ken!) checks to see if you have set a personal name in VMS Mail and uses that; BUT it only does a check once a day (I think...), so after setting personal name, you may want to wait a day and see what has happened. Other mail systems may be similar; may have their own method; or may not have a means of doing it. I suggest asking your system manager; it is usually the easiest way to find out. There is (or should not be) any way to send out a From: header without your valid userid on it. This prevents you from sending some unsuspecting soul mail from "SYSTEM" asking them to delete files because they are taking up too much room! *smile* Anyway, I hope this help.... -Bruce P.S. I *hate* digest format. If anyone else on a VMS machine is interested in a utility to chop it up into little pieces, send me a line....if there is interest, I'll whip one up and send it out. Any comments or suggestions are welcome. -B. ------------------------------ Date: Tue, 5 May 87 12:35:43 PDT From: rankin%EQL.Caltech.Edu@Iago.Caltech.Edu (Pat Rankin) Subject: re: shared files in Fortran > Can anyone tell me how to flush output from fortran? I open the file as > such: > open(unit=3, type='NEW', file=filen, shared) > to avoid the "File locked by another user" nonsense, and sure enough, I am > able to read the file, but nothing is there. I can only see whats there > when the program exits, which of course defeats the whole purpose. > > robert%jimi.cs.unlv.edu@relay.cs.net I answered this a couple of weeks ago, but I'll repeat the code fragment that can be used by the program that's writing the file: < Date: Mon, 20 Apr 87 16:26:39 PDT < Subject: re: Files in FORTRAN; flushing output buffers < < INTEGER *4 rabadr, FOR$RAB, sts, SYS$FLUSH < ... < c open the file for shared access < OPEN ( lunit, SHARED, ... < c get the address of the RMS Record Access Block < rabadr = FOR$RAB( lunit) < ... < c add a record to the file--it will not show up yet if the I/O is buffered < WRITE ( lunit, ... < c flush the output buffer so that others can read our last record < sts = SYS$FLUSH( %VAL(rabadr), , ) !2nd & 3rd args not used here < ... Pat Rankin ------------------------------ Date: 5 May 87 13:56:51 GMT From: gatech!gitpyr!allen@RUTGERS.EDU (P. Allen Jensen) Subject: Re: Preparation for VMS 5.0 In article <34874385.8be4@apollo.uucp>, jps@apollo.uucp (Jeffrey P. Snover) writes: > I have heard rumors that VMS 5.0 is so > dramatically different from VMS 4.X that > DEC has set a group of people to help prepare > 3rd party software houses. ------------------------------ Date: Fri, 1 May 87 12:19 CDT From: Les LaCroix <LLACROIX%carleton.edu@RELAY.CS.NET> Subject: Re: faster VMS spawn [long message] In a recent note, Robert Perlberg ({philabs|delftcc}!rdin!perl) writes: >If anyone can tell me how to use the abovementioned >technique or any way to start subprograms faster than with lib$spawn() >we would greatly appreciate it. If we can't find any better way we are >going to be forced to link all of our object code (currently about 13 >Megabytes of object code constituting 66 separate executables) into one >gigantic executable (gag!). Kevin Carosso (kvc@engvax.scg.hac.com) responded, encouraging Mr. Perlberg to consider doing just that (make big images). He cites experience with some package which makes liberal use of subprocesses and has real performance problems because of it. I am involved with the development of a fairly large program--I believe that our last release was about 3Mb of executable code. Creating the executable (via the VMS linker) can take a long time--lots of CPU time and paging. This might be excessive if the development machine is small or already heavily loaded. There may also be problems with additional pagefile usage when 13Mb of object code is crammed into a single image because of the presence of local data. This may or may not be a problem, depending on your development strategies. I am not free to tell you how these problems are being addressed here at SPSS. I can, however, talk about subprocess caching. One trick I found useful (at another employer) is outlined below: a) Create a mailbox, and open it for writing. b) Spawn off a subprocess which executes a DCL command procedure, passing in the name of the mailbox crated in step a). c) The DCL command procedure opens the mailbox for reading. It then enters a loop, reading lines and running programs. d) The parent process writes to the mailbox to specify the commands to be executed. Of course, you have to be careful and prepare yourself for the possibility of the subprocess going away unexpectedly. Plus you may need to extend the idea so that the parent can tell when the subprocess has finished its task. There are a couple nice extensions to using subprocess servers like this. First, if your "command specification" fits in one mailbox record, then you can have multiple subprocesses sitting around, all reading from the same command mailbox. It's not necessarily a good idea to spawn off lots of CPU-consumptive commands like this; nonetheless there are instances where multiple server jobs could be useful (say, on a multiprocessor). Another extension to this is to have just one reader (in this case a detached process instead of a subprocess) and multiple writers. A fun and useful thing to do, although it probably doesn't apply to the original problem. Finally, the "reader" can be a remote task rather than a subprocess. This isn't appropriate if the reader really needs to be in your job tree (for example, needs to use resources that your job has allocated). If you don't need that much cooperation, however, using remote tasks can be a quick and easy way to distribute your processing across a cluster or other network. Les LaCroix (CSnet: llacroix@carleton.edu) SPSS, Inc., 402 Washington, Northfield MN 55057-2027 [any similarity between the opinions expressed herein and those of my employer is strictly coincidental] ------------------------------ Date: Tue, 5 May 87 12:15 ADT From: <FXHELP%ALASKA.BITNET@wiscvm.wisc.edu> (UAF Computer Support Group) Subject: Editors... Chris, Couldn't send mail to CHRIS@ENGVAX.SCG.HAC.COM; the Wisconsin Arpanet gateway responds 'ENGVAX.SCG.HAC.COM' -- unknown host. Anyway, I agree -- my favorite mainframe editor is still Honeywell's QED or FRED, which is a great editor, despite the fact that it has NO screen capabilities, and it's really a dinosaur from the dark ages! However, seeing some of the great additions you've made in TPU, I would love to get a copy! (I could wait for the DECUS tapes, but they go to Anchorage, and we don't get much out of Anchorage!) Any chance you might send the files through the net late some night? Thanks for whatever reply you'll give! Jo Knox / University of Alaska Fairbanks Computer Support Group ------------------------------ Date: Tue, 05 May 87 23:42:15 GVA From: JCV%CERNVM.BITNET@wiscvm.wisc.edu Subject: Re: How do I identify my cpu? Here's some more information on the system id register. All definitions are contained in SYS$LIBRARY:STARLET in the macros $SYIDEF and $PRDEF. First, as already noted, there are two undocumented item codes for SYS$GETSYI which are contained in $SYIDEF and are also supported by the DCL lexcial function F$GETSYI. They are SYI$_XSID and SYI$_XCPU (for DCL, without the SYI$_ prefix), and return the extended system id and the cpu subtype. Second, the structure of the normal and extended system id and the values returned for cpu type are in $PRDEF. The structure of the system ids are as follows: 31.........24:23.........15:14.............12:11..............0 Bit position +---------------------------------------------------------------+ : cpu type : eco level : manuf. plant. : serial number : SID +---------------------------------------------------------------+ : cpu subtype : bits : XSID +---------------------------------------------------------------+ This structure is defined via parameters of the form PR$t_SID_xxx and PR$t_XSID_xxx, respectively. 't' has the values 'S' for 'size of field' and 'V' for 'starting bit of field'. For SID, 'xxx' takes the values 'SN', 'PL', 'ECO', and 'TYPE. For XSID, 'xxx' takes the values 'BITS' and 'TYPE'. The contents of the highest byte, i.e., the cpu (sub)type, are the values returned by the (X)CPU item codes. The values returned by these item codes are specified in the parameters PR$_SID_TYPxxx and PR$_XSID_xxxxx. Here, '790' means an 8600/8650 cpu, '8SS' one of the 8200/8300 series and '8NN' one of the 8500..8800 series. The other parts of the system id may or may not have meaningful values: On an 11-780, all contain meaningful data; on a uVAX II, they are all zero. BTW: Could anyone (from DEC ?) enlighten us as to the meaning of the XSID BITS? On our 8800, they have the curious value 9F7... --- Jan Vorbrueggen ------------------------------ End of Info-Vax Digest **********************