CHAPTER VAX PAGESWAPPER - February 1988 - Volume 9 Number 7 Editor's Workfile . . . . . . . . . . . . . . . VAX-3 Interlocked QBus Cycles on the MicroVAX-II . . . VAX-5 Cleaning up the TPU EDT Emulator . . . . . . . . VAX-7 VMSnet Status . . . . . . . . . . . . . . . . VAX-15 I/O Performance . . . . . . . . . . . . . . . VAX-22 Current Field Change Orders . . . . . . . . . VAX-39 LUG News . . . . . . . . . . . . . . . . . . . VAX-43 Spring 1988 System Improvement Request Ballot VAX-44 Anaheim VAXnotes Excerpts - VMS . . . . . . . VAX-71 Anaheim VAXnotes Excerpts - VMS Performance . VAX-80 Anaheim VAXnotes Excerpts - VMS V5 . . . . . . VAX-85 INPUT/OUTPUT . . . . . . . . . . . . . . . . . VAX-96 Forms at the End System Improvement Request Submission Form . . VAX-137 VAX Systems SIG Spring 1988 SIR Ballot . . . . VAX-139 PAGESWAPPER - February 1988 - Volume 9 Number 7 To register for on-line submission to the Pageswapper dial: (617) 262-6830 (in the United States) using a 1200 baud modem and log in with the username PAGESWAPPER. Articles for publication in the Pageswapper can be sent (US mail only -- no "express" services please) to: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA Preference is given to material submitted as machine-readable text (best is Runoff source). Line length should not exceed 64 characters and the number of text lines per page should not exceed 48 (these limits are particularly important for sample commands, etc. where simple text justification will not produce a meaningful result). Please do not submit program source, as that is better distributed on the VAX SIG tape. Please do not submit "slides" from DECUS Symposia presentations (or other meetings) as they are generally a very incomplete treatment for those readers of the Pageswapper who are not so fortunate as to be able to travel to Symposia. Please DO write articles based on such slides to get the content across to a wider audience than is able to attend. Change of address, reports of non-receipt, and other circulation correspondence should be sent to: DECUS U.S. Chapter Attention: Publications Department 249 Northboro Road (BPO2) Marlborough, MA 01752 USA Only if discrepancies of the mailing system are reported can they be analyzed and corrected. VAX-2 PAGESWAPPER - February 1988 - Volume 9 Number 7 Editor's Workfile Editor's Workfile SIR Voting Time By the time you read this there will be barely 2 months until the April 8 deadline. Look over the System Improvement Requests in the article in this issue and send in the ballot form from the back. Do it today, before you forget! Newsletter Survey At the Anaheim Symposium Newsletter editors (as well as anyone who volunteered for the tally committee) got a chance to look at the results of the survey which was mailed to all newsletter subscribers. I forget the numbers, but those familiar with surveying said the percentage of surveys returned was phenomenal compared to the small numbers one usually gets in response to such a survey. The overwhelming sentiment on distribution format favored the current combined volume as compared to the former arrangement where each SIG newsletter got mailed separately. For individual features that readers liked best/worst, almost every feature (across all newsletters) that anybody hated, somebody else loved. You can't please everybody all the time, and to me the survey indicated that everybody (subscribers, anyway) had certain newsletter features which they viewed as valuable to them. That is what it is all about. The most interesting part of reading the comments from the survey was that several readers said that the newsletters needed more reader submissions, "including from me", or words to that effect. That proof that even non-submitters realize we need submissions makes a newsletter editor happy. Newsletter Truncation Many pages have been chopped out of the Pageswapper by DECUS staff in the past six months (remember in August when it said "To be continued in next issue..." and it never was?), so those interested in what they missed should get copies from the Fall 1987 (Anaheim) SIG tape when it is distributed. VAX-3 PAGESWAPPER - February 1988 - Volume 9 Number 7 Editor's Workfile There were several "interim" commitments from the Communications Committee at the Anaheim Symposium. There is hope for budget relief in July, with some change in the printing arrangements (I don't remember the details), but in the meantime: 1. "Big" issues for February and May Newsletter editors were told that the budget could stand two issues between now and July which exceeded the normal "small" size (weight of the issue, for postage budget). Those issues were designated as February and May, when submissions typically peak anyway. So there should be no cuts for those months. 2. Pageswapper page count allocation Cuts have been to give the Pageswapper only 16 pieces of paper (64 page numbers) whereas since before the inception of the combined newsletters we have been working with a budget of 32 pieces of paper (128 page numbers). That is the reason we were quick to adopt the "two up" format - to get more information within the page budget. Our incoming and outgoing VAX SIG Communications Committee representatives are supposed to get this straightened out this month. Of course the Communications Committee had voted in September to have the staff stop cutting pages out of Newsletters. The cutting continued, so the Communications Committee does not necessarily control what happens. I/O Submission Form Editors have been asked to reduce the number of forms each SIG newsletter includes at the end of the combined newsletter to save on printing costs. To that end, I am abandoning the I/O Submission Form, and counting on our noble readership to do the right thing and use a piece of paper in the obvious fashion. The SIR forms will persist for the time being at least, since they include are structured queries that we want answered in order to make the process work. Larry Kilgallen Pageswapper Editor VAX-4 PAGESWAPPER - February 1988 - Volume 9 Number 7 Interlocked QBus Cycles on the MicroVAX-II Interlocked QBus Cycles on the MicroVAX-II Frank J. Nagy Research Division EED/Controls Group Fermi National Accelerator Laboratory P. O. Box 500 Mail Stop 220 Batavia, IL 60510 We recently had a rude awakening about the MicroVAX-II. What we discovered was that interlocked MicroVAX-II instructions (such as BBSSI) do not perform interlocked QBus cycles. Our group is working on a new distributed control system for the external beam lines at Fermilab. Control system data is acquired by a system of Front Ends and distributed to clients using DECnet. We are developing a Data Acquisition Engine (DAE) for our Front End MicroVAXes to increase the I/O efficiency by offloading the MicroVAX CPU. The DAE consists of a VME crate with two 80386 processor boards with attached I/O boards; the 80386 boards are commercial products, the I/O boards are developed inhouse. Communications between the 80386s and the MicroVAX is via a 4 MB memory module on the VMEBus (the 80386s each have 2 MB of private memory for buffers and program code). Another inhouse group developed a Qbus-to-VME interface which allows us to map VME address ranges into QBus Memory space. Our software sets up a global section by PFN mapping and then manipulates interprocessor queues within the VME memory. We have also built a set of boards to give us bi-directional interrupts between the VME processors and the MicroVAX. The interprocessor communications protocol is to dequeue a memory block from a free list queue, copy information into the block (which is resident in the 4 MB common memory on the VMEBus), insert the block onto the destination processor's queue and trigger an attention interrupt of the destination processor. The interprocessor queue structures are software locked by a single lock bit manipulated by test-and-set instructions (XCHG on the 80386 and BBSSI on the MicroVAX). The queue is a simple singly linked list and the interlock is needed to prevent multiple accessors from attempting to update the links simultaneously. VAX-5 PAGESWAPPER - February 1988 - Volume 9 Number 7 Interlocked QBus Cycles on the MicroVAX-II Initial testing revealed no problems and development of 80386 code proceeded apace. We started firing asynchronous interrupts at the 80386s which resulted in collisions in the queue manipulation code. These collisions were traced to the fact that the software interlocks were not working correctly. Further investigation with a logic analyzer revealed that the BBSSI instruction on the MicroVAX _d_o_e_s _n_o_t perform an interlocked QBus operation (using either a DATIO or a DATIOB cycle) but uses separate DATI and DATO(B) cycles. Further investigation revealed that the ADAWI similarly does not perform interlocked QBus operations to QBus memory space. We did _n_o_t check the interlocked queue instructions (INSQxI and REMQxI) since we cannot use them in our environment.: NOTE Interlocked VAX instructions appear to _N_O_T generate read-modify-write QBus cycles to QBus Memory space in the MicroVAX-II. We kludged a solution since we really wanted the interlocked operation to occur on the VMEBus. Before the BBSSI instruction is executed, a bit in the QVI (QBus-to-VME Interface) is toggled to set a LOCK signal. This signal stretches the next VME cycle (holding the VMEBus BUSY) done by the QVI until a VME Write operation is done. Since the next MicroVAX operation (at IPL above 24 so no one else gets the machine) is the BBSSI, the separate read (DATI) and write (DATO) QBus cycles are stretched into a single read-modify-write cycle on the VMEBus. Our interprocessor queue software now works and we are once again back in business. VAX-6 PAGESWAPPER - February 1988 - Volume 9 Number 7 Cleaning up the TPU EDT Emulator Cleaning up the TPU EDT Emulator Richard D. Piccard Educational Computing Kalamazoo College Kalamazoo, Michigan 49007 _A_b_s_t_r_a_c_t This paper reports what may well be the final revisions to our customization of DIGITAL's EDT Emulator interface for TPU. Because DIGITAL has announced that they intend no further development of the EDT Emulator, these include the code for fixes to outright bugs as well as some improvements. The full code for our customizations is included in the submission from Kalamazoo College on the DECUS VAX SIG Symposium Tape for Anaheim, 1987. I. Introduction VMS V4.6 comes with the cheering news that DIGITAL will provide no further updates to the EDT Emulator interface for TPU. ("But the EDT keypad is available under EVE," or words to that effect; this is comforting?) Furthermore, that section file will disappear automatically during the VMS V5.0 upgrade, so anyone who wants to continue using an interface based on that code must squirrel away a copy of SSYYSS$$SSHHAARREE::EEDDTTSSEECCIINNII..TTPPUU _b_e_f_o_r_e _t_h_e _u_p_g_r_a_d_e. After that event, it may prove more effective to modify a copy of their file directly. But we are continuing for now to use the fully layered approach, in which a stock section file is used with a command file that implements our customizations and saves them to a new section file. Since DIGITAL has been happy in the past to provide EDTSECINI.TPU to all licensed VMS sites, it will be included in our VAX SIG Symposium Tape submission, which should be distributed down the tree at about the same time that VMS V5.0 hits the streets. II. Bug Fixes VAX-7 PAGESWAPPER - February 1988 - Volume 9 Number 7 Cleaning up the TPU EDT Emulator The method we use to fix bugs in DIGITAL's EDTSECINI.TPU code is to include in the command file that will create the layered section, KAZSECINI.TPU in our case, a copy of their defective procedure, and then modify it. The corrected version will then supercede the original procedure when the new section file is saved. The stock word-wrapping procedure, normally bound to the space bar, wraps one column too early and also wraps the entire last word of a line even when all the printing characters do fit within the wrapping margins, but the _s_e_c_o_n_d (or later) space character following the word moves the cursor beyond the limit. The fix is to modify their procedure EDT$WRAP_WORD, as indicated below. ================================================================ procedure edt$wrap_word ! space key (wrap word) ! !+ ! Modified from EDTSECINI.TPU ! ! COPYRIGHT © DIGITAL EQUIPMENT CORPORATION ! ! Procedure to wrap the word to the next line. Bound to space ! key when a SET WRAP is done. ! ! 28-SEP-1987 RDP: use the full number of columns (the ! current_column is one beyond the last ! character typed); if the previous ! character was a space, and are now ! too far, then just split_line. !- LOCAL word_size , temp_char, trash_space ; if edt$x_wrap_position = 0 then return endif; if current_column > edt$x_wrap_position + 1 then move_horizontal(-1); temp_char := current_character; move_horizontal(+1); if (temp_char = ' ') then VAX-8 PAGESWAPPER - February 1988 - Volume 9 Number 7 Cleaning up the TPU EDT Emulator split_line; return; else word_size := edt$beg_word; split_line; move_horizontal(word_size); endif; endif; copy_text(' '); endprocedure ================================================================ Ever since the original release of the EDT Emulator, FILL has split a word in the middle whenever the select range starts in a word that extends beyond the specified margin. The fix below has been included in previous versions of KAZSECINI, as submitted to the Fall, 1985, and Fall, 1986, VAX SIG Symposium Tapes; it is included here for completeness. As above, a copy of the stock procedure is included in KAZSECINI and modified as shown in the early portion of the procedure, below. ================================================================ procedure edt$preserve_blanks(flag) ! support routine for fill . . on_error all_done:=1; ! cause exit endon_error; original_position:=mark(none); b_mark:=beginning_of(edt$x_select_range); ! position (b_mark); move_horizontal (-current_offset); b_mark := mark(none); ! ! the above three lines are Kalamazoo's fix of a bug. ! . . ================================================================ VAX-9 PAGESWAPPER - February 1988 - Volume 9 Number 7 Cleaning up the TPU EDT Emulator The structured tabs features of EDT have also been poorly emulated ever since the original release. In particular, the emulator procedure bound to CTRL/T sets all indentations in the selected block to exact multiples of the current "tab size", rather than _c_h_a_n_g_i_n_g the indentation of each line in the block _b_y the specified multiple of the tab size. Our earlier versions of KAZSECINI included attempts to cure this behavior. We are confident that the following code is satisfactory under the current version of TPU. As before, a modified copy of the stock procedure is included in KAZSECINI. The code below is an early portion of the modified procedure. ================================================================ procedure edt$tab_adjust !ctrl t (adjust tabs) . . !+ ! Go to beginning of line. ! Calculate tab depth for this line ! Strip off spaces and tabs at beginning of line. ! Set up new tab goal ! Call the tab routine. !- if length (current_line) > 0 then loop exitif (current_character <> ' ') AND (current_character <> ' '); move_horizontal(1); endloop; ! ! tab_level := get_info(current_buffer,'offset_column') ! / edt$x_tab_size; ! edt$x_Tab_goal := (tab_level + adjust_level) ! * edt$x_tab_size; ! ! For KAZSECINI, the above two statements are deactivated ! and replaced by the next statement. ! edt$x_Tab_goal := get_info(current_buffer,'offset_column') - 1 + (adjust_level * edt$x_tab_size) ; if (edt$x_tab_goal < 0) then edt$x_tab_goal := 0 endif; erase_character(-current_offset); edt$tab; endif; VAX-10 PAGESWAPPER - February 1988 - Volume 9 Number 7 Cleaning up the TPU EDT Emulator . . ================================================================ In VMS V4.6, once again, DIGITAL's love-hate relationship with the GIGI rears its ugly head. The scrolling region limitation, which is noted in the unchanged TPU documentation, is defaulted differently, so that code that used to function quite nicely is now unworkable. The fix is simple this time. The work-around was developed with Edward M. King of the Colorado Customer Support Center. Even though scrolling is "OFF", the line limits _a_r_e obeyed by pseudo-scrolling, repainting the screen. Our procedure for setting up the environment now includes the following lines: ================================================================ procedure tpu$local_init local gigi; . . gigi := get_info(SCREEN, "vk100"); if (gigi = 0) then ! this is not a GIGI, so ! set (scrolling,KAZ_x_top_window,on,3,3,0); set (scrolling,KAZ_x_bottom_window,on,3,3,0); set (scrolling,main_window,on,7,7,0); else ! this is a GIGI, so ! set (scrolling,KAZ_x_top_window,off,2,2,3); set (scrolling,KAZ_x_bottom_window,off,2,2,3); set (scrolling,main_window,off,4,4,6); set (scrolling,message_window,off,0,0,0); endif; ! . . ================================================================ VAX-11 PAGESWAPPER - February 1988 - Volume 9 Number 7 Cleaning up the TPU EDT Emulator III. Improvements While browsing through EDTSECINI we noticed the SHOW VERSION line-mode command. It seemed reasonable to include the date of the KAZSECINI revision. We have created one global variable to carry that information, which is initialized in our procedure tpu$local_init, and modified a copy of the stock procedure edt$show to take advantage of it. The KAZSECINI date _d_o_e_s require modification by hand. The modified portions of the two procedures are shown below. ================================================================ procedure tpu$local_init . . ! kaz_x_version := ' - KAZSECINI 9/28/87'; ! . . ================================================================ ================================================================ procedure edt$show ! support routine for line mode(show cmd) . . .test page 6 [4]: ! SHOW VERSION message('TPU Version V'+str(get_info(system,'version'))+'.'+ str(get_info(system,'update')) + ' - ' + edt$x_version + kaz_x_version); . . ================================================================ VAX-12 PAGESWAPPER - February 1988 - Volume 9 Number 7 Cleaning up the TPU EDT Emulator Following the suggestion provided in the July, 1985, issue of "The HEAP," our earlier versions of KAZSECINI had included the following statement in the local initialization: SET(MESSAGE_FLAGS,1); This did permit more of the informative text of most messages to be visibly displayed on screen, but not the initial file read-in message. We have therefore included in the current KAZSECINI a copy of the stock procedure EDT$INIT_VARIABLES, and moved the statement given above from our procedure TPU$LOCAL_INIT to become the _f_i_r_s_t executable line of EDT$INIT_VARIABLES. This means that the message about reading in the file has room for 15 more characters of subdirectory information before going off the screen. ================================================================ procedure edt$init_variables ! initialize global variables . . set (message_flags,1); . . ================================================================ We found that when the procedures we bind to GOLD/B (for reading a file into a buffer) were executed, we were almost always interested in starting at the top of the buffer, but that the code was leaving the cursor at the bottom. We therefore modified the procedure, as shown below, by adding a line to position the cursor automatically at the top of the buffer. ================================================================ procedure kaz_grab_a_buffer(buffer_name,new_window) . . if file_name <> kaz_x_empty then read_file(file_name); position (beginning_of(buffer_ptr)); ! new line endif; VAX-13 PAGESWAPPER - February 1988 - Volume 9 Number 7 Cleaning up the TPU EDT Emulator ! else ! buffer already exists ! kaz_status_line(buffer_ptr,new_window); map(new_window,buffer_ptr); endif; ! kaz_x_this_window := current_window; return 1; endprocedure ================================================================ IV. What Next The time is fast approaching to bid a fond farewell to EDT and the EDT Emulator. We plan to try to sustain the enhanced EDT Emulator at Kalamazoo College under VMS V5.0, but probably not beyond. We will be encouraging adventurous users to experiment with EVE and EVE-Plus during the end of VMS V4, and will then try to merge the best parts of our modified EDT Emulator into some variant of EVE. I suspect that we will abandon most of the line-mode commands except, perhaps, EXIT, but that we may prefer to keep more EDT key definitions than just the keypad. I would be delighted to hear directly, or better yet through these pages, from anyone who has migrated a user community from EDT or the EDT Emulator to any variant of EVE. In particular, our system has many VT-100 and Zenith Z-29 terminals, and no VT-200 series terminal. Hence, the optimization of EVE using the more limited keyboard is critical for us, and it does not strike me as being at all obvious that it has been done right: I suspect strongly that DIGITAL's recent research has mostly been done on their modern terminals. VAX-14 PAGESWAPPER - February 1988 - Volume 9 Number 7 VMSnet Status VMSnet Status VMS User's Network Working Group Jamie Hanrahan Working Group Chair This is a summary of the current state of the "UUCP and Usenet for VMS" (VMSnet) effort. It is based mostly on the session presented at the Fall '87 Symposium by Tom Allebrandi and Kevin Carosso (presented heroically, I might add, as they both expected me to be the primary speaker, and I was delayed getting back from San Diego). Background (Those already familiar with the working group and its goals may skip this section.) Unix(TM) sites have for many years enjoyed the benefits of "Usenet", a worldwide network of (mostly) Unix systems connected (mostly) via autodialed phone lines. The services provided by this network are electronic mail and "Netnews", an elaborate on-line conferencing system. Usenet differs from dial-in, bulletin-board-like systems like DECUServe and Larry Kilgallen's Pageswapper machine in that the mail and news is delivered automatically to the system you log into every day; there's no need to place an outgoing call when you want to read or send mail. The Usenet has been of incalculable value to the Unix community. The network encompasses tens of thousands of systems, crossing both corporate and geopolitical boundaries; the body of knowledge that is available from the participants is not inconsiderable. Questions posted to Netnews on almost any topic are generally answered within a few days. Bug reports and fixes, patches to Unix system code, and public-domain software are all distributed through Usenet; many sites justify the telephone expenses (which, for sites with many connections, are not small) on this basis alone. Further, Usenet is effectively part of the Internet, which includes Arpanet, CSNET, and VAX-15 PAGESWAPPER - February 1988 - Volume 9 Number 7 VMSnet Status BITNET... not to mention Easynet, DEC's internal DECnet network. VMS users who are aware of Usenet have for many years wished for a way to connect to it -- not only so we could talk to all those other folks, but also (or especially) so we could talk to each other. There has never been anything technically impossible about this, but the necessary software and information has not been cheaply available in the correct combinations. A few years ago some of us got together at a DECUS Symposium, started calling ourselves a Working Group of the VAX SIG, and set out to do something about the problem. RECENT HISTORY When we published our last report, we had settled on a package called PMDF (Pascal Memo Distribution Facility) as our dialup transport mechanism. PMDF is available at very low cost and offers RFC822- (i.e. Internet-) compliant addressing, routing between various transport mechanisms (including DECnet), automatic store-and-retry when a target system is unreachable, etc. It is an extremely valuable and useful package, and will play a major role in many sites' activity on VMSnet. Unfortunately, my efforts to build a network with PMDF alone have not been successful. The reason is that there aren't enough VMS sites who are willing to place long-distance phone calls to each other to build a viable backbone. (Among the thirty or so responses I got to my "contact me" request in the August article, only three people said that they would be able to place long-distance calls.) It is true that PMDF can talk to the Unix package, MMDF, which comes with Berkeley Unix 4.3, but it is not actually _i_n _u_s_e at very many Unix sites, so PMDF does not provide the desired level of Unix connectivity either. Very Recent History (and some good gnus!) VAX-16 PAGESWAPPER - February 1988 - Volume 9 Number 7 VMSnet Status UUCP for VMS is "Almost Here" In October I received a package called "gnuucp" from John Gilmore and Lol Grant. It is part of the Free Software Foundation's "Gnu" (short for _Gnu's _Not _U_n_i_x) effort. It is copyrighted by the FSF, but anyone can freely distribute it as long as their recipients can do the same. Perhaps best of all, it has been certified by AT&T as _n_o_t having been derived from Unix sources. John Gilmore and Lol Grant have gnuucp running under VMS, exchanging mail with a Unix system over hardwired lines. And, I have used it to exchange mail with a Unix system -- albeit with a few bugs -- over a dialin line (that is, the Unix system called VMS; gnuucp can't dial out yet). Internet Addressing Support Tom Allebrandi has been working on porting two public-domain Unix programs called smail and pathalias to VMS. These programs eliminate most of the need for route-style addressing in the uucp world and will allow us to use domain-style addressing instead (user@site). Netnews Support Geoff Huston of Australia National University has written "NEWS 4.0", a nearly full implementation of Unix netnews under VMS. It will appear on the Fall 87 DECUS VAX SIG tape. What's Left? Here's our current list of things to do: VAX-17 PAGESWAPPER - February 1988 - Volume 9 Number 7 VMSnet Status o Fix the dialin and dialout problems in gnuucp, add support for more modem types (it presently can only dial Hayes modems), and track down some other miscellaneous bugs. o Eliminate the need for a C compiler at the user's site (presently, things like the uucp node name are compiled in rather than being defined via logical names) o Finish porting pathalias and smail, and integrate smail with gnuucp o Provide an interface to VMSmail (based on Kevin Carosso's VMSmail foreign protocol interface) o Allow NEWS 4.0 to send and receive news via gnuucp This should keep us busy in our spare time (!) through January. Want to Help Beta Test Some Probably Buggy Code? If you want to be one of the first sites on VMSnet, you'll need: o A VAX or MicroVAX or VAXstation running VMS 4.6 (or later) o Disk space: - 4 megabytes temporary (for the uucp map in text form) - 1 megabyte permanent - 2 megabytes per day per news (if you get all the newsgroups. Multiply by as many days as you plan to keep the news around; there's an automatic "expire" feature) o DZ, DHU/DHV, or DMF port (with modem control), or equivalent (I don't have any terminal servers here, so I can't say how well it'll work with them) VAX-18 PAGESWAPPER - February 1988 - Volume 9 Number 7 VMSnet Status o An autodialing modem, preferably 2400 bps, and preferably Hayes compatible o A nearby (probably Unix) site to connect to (you'll be able to find them via the map files) o The beta test software To receive the beta test software, send a blank tape (2400' 9-track, or a TK50 cartridge) -- _w_i_t_h _a _s_t_a_m_p_e_d_, _s_e_l_f_-_a_d_d_r_e_s_s_e_d _r_e_t_u_r_n _e_n_v_e_l_o_p_e _o_r _b_o_x -- to: For 9-track tapes: Jamie Hanrahan, Simpact Associates 9210 Sky Park Court, San Diego, CA 92123 For TK50s: Tom Allebrandi, c/o ACCI 206-F W. Market Street, Charlotsville VA 22901 The tapes will include gnuucp, smail, pathalias, the VMSmail interface, NEWS 4.0, the uucp network map, an encoder/decoder for sending non-text files via mail, various utilities necessary for building it all from the sources (if you are so inclined; executables will also be provided), and some very sketchy documentation. Warnings Two things need to be said about the sort of dialup network we are creating. First, it should be obvious that if your mail passes through any machines you don't directly control, it is subject to being read by persons other than the intended reader. So, don't plan on using the network for, say, intracompany mail between offices in various cities, unless you set up direct dialed connections (no intermediate hops) between them. Of course, this is a good idea anyway, because of the second thing: Second, if you find yourself communicating heavily with particular sites, you should set up your own long-distance links between them, and not ride on the existing backbones (which are already overloaded). VAX-19 PAGESWAPPER - February 1988 - Volume 9 Number 7 VMSnet Status What's Next? In addition to fixing whatever bugs are found in the test software, there are several other things to be done before we can sit back and rest on our laurels: o Add support for terminal servers o Provide gnuucp as a channel under PMDF o Write _g_o_o_d documentation o Establish procedures for Internet name registry for VMSnet sites o Allow gnuucp to use DECnet links (where they exist) The last item is a particularly exciting idea. We're not talking about running the uucp protocol over DECnet, but rather using a DECnet link to perform the file copy operation, at the next level up, as it were. An organization with VMS systems in different cities around the country, connected by leased-line DECnet links, could then provide significant backbone capacity to the net during the off hours when such links are almost always idle. We may have a rudimentary capability along these lines (using DECnet remote file access) in the beta test release; a proper implementation (with our own special-purpose server, as many sites don't like the security problems that FAL opens up) will have to wait until later. (We'd like to have all of this done in time for the Cincinnati SIG tape, but we'll see.) Naturally, if you want to help with any of this, we'd like to hear from you. See you on the net! Jamie Hanrahan Simpact Associates 9210 Sky Park Court San Diego, CA 92123 619-565-1865 uucp: {sdcsvax,nosc}!crash!jeh arpa: crash!jeh@nosc.mil internet: jeh@crash.CTS.COM VAX-20 PAGESWAPPER - February 1988 - Volume 9 Number 7 VMSnet Status or: jeh@crash.CTS.COM Pageswapper: US194066 DECUServe, DCS: HANRAHAN An Internet mailing list has been established for those interested in the VMSnet effort. To post an item to the list send a message to: VMSNET%FALCON@WPAFB-AAMRL.ARPA on the internet. Requests can be sent to: VMSNET-REQUEST%FALCON@WPAFB-AAMRL.ARPA The list manager is Ted Nieland (TNIELAND@WPAFB-AAMRL.ARPA, NIELAND%FALCON@WPAFB-AAMRL.ARPA) and any problems can be reported to him. VAX-21 PAGESWAPPER - February 1988 - Volume 9 Number 7 I/O Performance I/O Performance Daryl O. Jones P.O. Box 773667 Eagle River, Alaska 99577 May 26, 1987 Ross W. Miller Online Data Processing, Inc. N. 637 Hamilton Spokane, Washington 99202 Dear Sir, The following is in regard to your question of the VAX I/O performance failure featured in the _D_E_C_U_S_ _U_._S_._ _N_E_W_S_L_E_T_T_E_R, April 1987 issue. I work for Anchorage School District in Anchorage, Alaska, as a VAX programmer. We have several VAXes on site including a cluster which runs the Student Management System (SMS). The SMS is a collection of VAX basic programs which accesses several files to do report cards, attendance reporting, scheduling, and other reports required by the state and federal agencies. The types of RMS files accessed or created are indexed, sequential, and relative file structures. The majority of the time we are accessing indexed files to create a report using the RMS defaults provided by the system. The VAX I/O performance question raised its head about a year ago, when I wrote a program on VAX 785 that accessed two files, REG.DBS and REGENTRY.DBS. The program accessed sequentially the REG file first and then the REGENTRY file. The run time was about seven hours long. I was later informed that similar programs took about four hours to run. A review of my program showed that the difference was that the other programs accessed the REGENTRY file first then the REG file. My program was changed to have it access the REGENTRY file first and then the REG file. My program executed with a run time of only four hours, similar to other programs. VAX-22 PAGESWAPPER - February 1988 - Volume 9 Number 7 I/O Performance The resultant time difference was puzzling. Why was there a three hour difference in run time? The only difference in the programs was the order in which the files were accessed. I began to analyze the file structures for clues. The REG file is a 1002 byte record, prolog 1, and three blocks per bucket, indexed file. A single record in REG file represents a single student's registration information for a total of about 41,000 student records in the REG file. The REGENTRY file is a 117 byte record, prolog 3, and three blocks per bucket, indexed file. A single record in REGENTRY file represents an entry/withdrawal record for the student. Therefore, a student may have one or more records depending on the number of transfers and withdrawals. The number of records in the REGENTRY file was roughly 50,000. The unit of transfer from disk to memory is a bucket for indexed files. I concluded that for every GET I/O on the REG file, a single record was retrieved from disk to memory. Whereas in the REGENTRY file case, two or more records were transferred from disk to memory with each GET I/O. It seemed reasonable to increase the number of blocks per bucket for the REG file, which would drop the number of direct I/O requests being made and increase the number of records retrieved at one time from the disk. I converted the REG and REGENTRY files using convert/fdl routine. The bucket size for REG file was increased from 3 to 54 blocks/bucket and for the REGENTRY file the bucket size changed from 2 to 18 blocks/bucket. The next file structure to be changed was the type of prolog. I changed the prolog type from 1 to 3 and saw the size of the REG file drop from 135,000 blocks down to 35,000 blocks. Furthermore, the file compression has increased the number of records per bucket. The increased cpu usage due to the expansion of each record seemed to be negligible. I ran the same program used earlier and looked at the effects on the system via the MONITOR utility. The direct I/O count was lower, ten down to six per second, but the drop in cpu time wasn't much, just 15 minutes out of four hours. I increased the number of I/O buffers from the system default of two to three and ran the same program. Again, I noticed a decrease in the direct I/O counts (six down to 4-5 per second), but not much in cpu time. When I increased the I/O buffers to four I/O buffers, the direct I/O requests dropped from 4-5 per second to 0-1 per second which resulted in processing 15,000 more students (REG VAX-23 PAGESWAPPER - February 1988 - Volume 9 Number 7 I/O Performance and REGENTRY file records combined) over the old version of the program in the first two hours. A couple of months later, I attended the RMS Structures and Utilities Seminar. I found out the reasons for the increased I/O performance and applied it to other programs. The following are two brief examples where techniques of I/O buffering and CONVERT utility were used that dropped the run time of each program from hours to minutes. EXAMPLE 1: First Run: Computer: VAX 785 Input files: Four indexed, prolog 3 files Output file: One four key indexed, prolog 3 file I/O Buffers: Two I/O buffers Prog Language: VAX Basic Direct I/O: 6-9 Request/sec Run Time: 4 hours Input files Program Output file ----------- | Indexed |-------->| ================ ----------- | * * | * * | * * ----------- | * * | Indexed |-------->| * * ----------- | * * ----------- | * *------>| Indexed | |----->* * ----------- ----------- | * * | Indexed |-------->| * * ----------- | * * | * * | * * ----------- | ================ | Indexed |-------->| ----------- VAX-24 PAGESWAPPER - February 1988 - Volume 9 Number 7 I/O Performance (EXAMPLE 1 continued) Second Run: Computer: VAX 785 Input files: Four indexed, prolog 3 files Intermediate file: One sequential file Output file: One four key indexed, prolog 3 file I/O Buffers: 70 I/O buffers Prog Language: VAX Basic Direct I/O: 0-1 Request/sec Run Time: 10 minutes Input files Program Output file ----------- | Indexed |-------->| ================ ----------- | * * | * * | * * ----------- | * * | Indexed |-------->| * * ----------- | * * ----------- | * *------>| Indexed | |----->* * ----------- ----------- | * * | Indexed |-------->| * * ----------- | * * | * * | * * ----------- | ================ | Indexed |-------->| | | ----------- | /|\ \|/ | | | ---------------- | Sequential | INTERMEDIATE FILE ---------------- VAX-25 PAGESWAPPER - February 1988 - Volume 9 Number 7 I/O Performance EXAMPLE 2: First Run: Computer: VAX 8500 Input files: Four indexed, prolog 3 files Output file: One sequential file I/O Buffers: Two I/O buffers Prog Language: VAX Basic Direct I/O: 6-9 Request/sec Run Time: 5-8 Hours Input files Program Output file ----------- | Indexed |-------->| ================ ----------- | * * | * * | * * ----------- | * * | Indexed |-------->| * * ----------- | * * ------------ | * *------>|Sequential| |----->* * ------------ ----------- | * * | Indexed |-------->| * * ----------- | * * | * * | * * ----------- | ================ | Indexed |-------->| ----------- VAX-26 PAGESWAPPER - February 1988 - Volume 9 Number 7 I/O Performance (EXAMPLE 2 continued) Second Run: Computer: VAX 8500 Input files: Four indexed, prolog 3 files Output file: One sequential file I/O Buffers: 80 I/O buffers Prog Language: VAX Basic Direct I/O: 0-3 Request/sec Run Time: 30 minutes VAX I/O performance is determined by the I/O buffers when accessing one or more indexed files randomly, two or more indexed files when accessing them sequentially. The reason for this is that the file index and data buckets are kept in memory. However, this is not always a cure! Sometimes just reading the needed information into an array and performing binary searches can be a more effective method. I hope this will help you in your endeavor. If you are in need of any more information, please feel free to contact me. Sincerely, Daryl O. Jones VAX-27 PAGESWAPPER - February 1988 - Volume 9 Number 7 I/O Performance Daryl O. Jones P.O. Box 773667 Eagle River, Alaska 99577 August 27, 1987 Ross W. Miller Online Data Processing, Inc. N. 637 Hamilton Spokane, Washington 99202 Dear Sir, The following are tests conducted to see the effects of I/O buffers on sequential access files and large file sorts. _I_/_O_ _B_U_F_F_E_R_S_ _W_I_T_H_ _S_E_Q_U_E_N_T_I_A_L_ _F_I_L_E_S One of our computer systems (VAX 750) is used for statistical processing. The response and run times were slow which brought about a discussion that I had with our System Manager, John Borge, on how we might increase the throughput. Since the file processing is sequential with file sizes of a few blocks to about 7,000 blocks. I had suggested that the RMS buffer values should be increased due to the amount of direct I/O. Our System Manager selected six types of processes to be run in batch mode with RMS default values and again using the increased buffer size and number. The RMS default values are 16 blocks per buffer and one buffer per process for sequential access files. The new RMS default values were set at 127 blocks per buffer and two buffers per process for sequential access. The tests were conducted and tabulated by our System Manager once during the day on a loaded system and again at night in a stand-alone mode. The test runs were executed about one half hour apart during the day and night times. The daytime results could be explained away via the difference in loads on the system during the test runs. However, the test results at night were made with only a single process executing with no one else on the system. VAX-28 PAGESWAPPER - February 1988 - Volume 9 Number 7 I/O Performance The nighttime results seemed to validate the daytime results which indicates a drop in resource usage except in working set size as expected due to the increased buffer sizes and number. The new RMS buffers decreased the DIRECT I/O rate, which is expected, however a larger drop was seen in the elapsed time especially under a heavily loaded system. This would indicate that the CPU spent less time waiting for I/O completions and more time doing the job at hand. The decrease in direct I/O requests would also unload the controller allowing it to service more requests. The overall effect was a decrease in system resources and better performance. The one exception to the trend was the FORTRAN program, where the CPU time decreased and the elapsed time increased. In the previous cases, little or no decrease in CPU occurred with a significant decrease in elapsed time. The increase in the elapsed time could be due to the 268% increase in page faults. An increase in working set size might decrease the page faults and drop the elapsed time. NOTE This test was conducted once and has not been repeated for lack of computer time. However, these programs were executed again with larger files and the results were not reproduced. The following are the tabulated results. VAX-29 PAGESWAPPER - February 1988 - Volume 9 Number 7 I/O Performance Computer: VAX 750 Disk: RA 81 Controller: UDA50 Working set size: 4096 SPSSX: Input files: One sequential file, 6,722 blocks long Output file: One sequential, results DAYTIME RESOURCES RMS BUFFERS (SIZE/NO.) 127/2 16/1 DIFF. PERCENT ---------------------------------------------------------------- BUFF I/O 157 163 -6 -4 DIRECT I/O 1229 1629 -395 -24 PAGE FAULTS 2256 3693 -1437 -39 PEAK W.S. (pages) 1708 1750 -48 -3 PEAK VIRT. MEM (pages) 12339 12211 +128 +1 CPU (SEC) 1691 1699 -8 -1 ELAPSED (SEC) 3154 5962 -2808 -47 NIGHTTIME RESOURCES RMS BUFFERS (SIZE/NO.) 127/2 16/1 DIFF. PERCENT ---------------------------------------------------------------- BUFF I/O 154 157 -3 -2 DIRECT I/O 1211 1598 -387 -24 PAGE FAULTS 2260 2082 -178 -9 PEAK W.S. (pages) 1750 1750 0 0 PEAK VIRT. MEM (pages) 12339 12211 +128 +1 CPU (SEC) 1651 1672 -21 -1 ELAPSED (SEC) 1897 3628 -1731 +48 VAX-30 PAGESWAPPER - February 1988 - Volume 9 Number 7 I/O Performance Datatrieve: Input files: One sequential file, 762 blocks long Output file: One sequential, results DAYTIME RESOURCES RMS BUFFERS (SIZE/NO.) 127/2 16/1 DIFF. PERCENT ---------------------------------------------------------------- BUFF I/O 122 152 -30 -20 DIRECT I/O 3950 4148 -198 -4 PAGE FAULTS 1641 1651 -10 -1 PEAK W.S. (pages) 1579 702 +877 +125 PEAK VIRT. MEM (pages) 2254 1742 +512 +29 CPU (SEC) 168 170 -2 -1 ELAPSED (SEC) 357 467 -110 -24 NIGHTTIME RESOURCES RMS BUFFERS (SIZE/NO.) 127/2 16/1 DIFF. PERCENT ---------------------------------------------------------------- BUFF I/O 122 152 -20 -13 DIRECT I/O 3931 4148 -217 -5 PAGE FAULTS 1681 973 +708 +73 PEAK W.S. (pages) 1560 1508 +52 +4 PEAK VIRT. MEM (pages) 2254 1742 +512 +29 CPU (SEC) 169 166 +3 +2 ELAPSED (SEC) 319 344 -25 -7 VAX-31 PAGESWAPPER - February 1988 - Volume 9 Number 7 I/O Performance SORT1: Input files: One sequential file, 3,190 blocks long Output file: One sequential file, 3,190 blocks long DAYTIME RESOURCES RMS BUFFERS (SIZE/NO.) 127/2 16/1 DIFF. PERCENT ---------------------------------------------------------------- BUFF I/O 45 44 +1 +2 DIRECT I/O 611 599 +12 +2 PAGE FAULTS 2230 25428 -23198 -91 PEAK W.S. (pages) 1750 638 +1112 +315 PEAK VIRT. MEM (pages) 2598 2598 0 0 CPU (SEC) 22 52 -30 -58 ELAPSED (SEC) 61 552 -491 -89 NIGHTTIME RESOURCES RMS BUFFERS (SIZE/NO.) 127/2 16/1 DIFF. PERCENT ---------------------------------------------------------------- BUFF I/O 43 44 -1 -2 DIRECT I/O 602 638 -36 -6 PAGE FAULTS 2193 2261 -32 -1 PEAK W.S. (pages) 1750 1750 0 0 PEAK VIRT. MEM (pages) 2598 2598 0 0 CPU (SEC) 22 23 -1 -4 ELAPSED (SEC) 53 98 -45 -46 VAX-32 PAGESWAPPER - February 1988 - Volume 9 Number 7 I/O Performance SORT2: Input files: One sequential file, 3,102 blocks long Output file: One sequential file, 3,102 blocks long DAYTIME RESOURCES RMS BUFFERS (SIZE/NO.) 127/2 16/1 DIFF. PERCENT ---------------------------------------------------------------- BUFF I/O 43 43 0 0 DIRECT I/O 589 573 +16 +3 PAGE FAULTS 2211 25144 -22933 -91 PEAK W.S. (pages) 1750 622 +1128 +181 PEAK VIRT. MEM (pages) 2598 2598 0 0 CPU (SEC) 21 52 -31 -60 ELAPSED (SEC) 64 555 -491 -89 NIGHTTIME RESOURCES RMS BUFFERS (SIZE/NO.) 127/2 16/1 DIFF. PERCENT ---------------------------------------------------------------- BUFF I/O 43 43 0 0 DIRECT I/O 586 573 +13 +2 PAGE FAULTS 2216 25144 -22928 -91 PEAK W.S. (pages) 1750 622 +1128 +181 PEAK VIRT. MEM (pages) 2598 2598 0 0 CPU (SEC) 21 52 -31 -60 ELAPSED (SEC) 57 555 -498 -90 VAX-33 PAGESWAPPER - February 1988 - Volume 9 Number 7 I/O Performance MERGE: Input files: Two sequential files, 3,190 and 3,102 blocks long Output file: One sequential file, 6,292 blocks long DAYTIME RESOURCES RMS BUFFERS (SIZE/NO.) 127/2 16/1 DIFF. PERCENT ---------------------------------------------------------------- BUFF I/O 158 159 -1 -1 DIRECT I/O 1370 1330 +40 +3 PAGE FAULTS 3673 306 +3367 +1100 PEAK W.S. (pages) 494 482 +12 +3 PEAK VIRT. MEM (pages) 1039 1039 0 0 CPU (SEC) 51 51 0 0 ELAPSED (SEC) 103 154 -51 -33 NIGHTTIME RESOURCES RMS BUFFERS (SIZE/NO.) 127/2 16/1 DIFF. PERCENT ---------------------------------------------------------------- BUFF I/O 158 158 0 0 DIRECT I/O 1337 1327 +10.0 +1 PAGE FAULTS 326 367 -41.0 -11 PEAK W.S. (pages) 491 482 +9.0 +2 PEAK VIRT. MEM (pages) 1039 1039 0 0 CPU (SEC) 50 50 0 0 ELAPSED (SEC) 87 109 -22.0 -20 VAX-34 PAGESWAPPER - February 1988 - Volume 9 Number 7 I/O Performance FORTRAN: Input files: One sequential file, 9 blocks long Output file: One sequential file, 6,360 blocks long DAYTIME RESOURCES RMS BUFFERS (SIZE/NO.) 127/2 16/1 DIFF. PERCENT ---------------------------------------------------------------- BUFF I/O 172 791 -619 -78 DIRECT I/O 668 3452 -2784 -81 PAGE FAULTS 1424 578 +846 +146 PEAK W.S. (pages) 1380 451 +929 +206 PEAK VIRT. MEM (pages) 1831 940 +891 +95 CPU (SEC) 575 596 -21 +4 ELAPSED (SEC) 1772 2068 -296 -14 NIGHTTIME RESOURCES RMS BUFFERS (SIZE/NO.) 127/2 16/1 DIFF. PERCENT ---------------------------------------------------------------- BUFF I/O 164 777 -613 -79 DIRECT I/O 847 4255 -3408 -80 PAGE FAULTS 1548 578 +970 +168 PEAK W.S. (pages) 1314 515 +799 +155 PEAK VIRT. MEM (pages) 1831 940 +891 +95 CPU (SEC) 588 602 -14 -2 ELAPSED (SEC) 1293 1264 +29 +2 VAX-35 PAGESWAPPER - February 1988 - Volume 9 Number 7 I/O Performance _I_B_M_ _4_3_8_1_ _A_N_D_ _V_A_X_ _S_O_R_T_ _B_E_N_C_H_M_A_R_K A sort benchmark was conducted in February 1986 using a file that contained 125,000 records, with a record size of 255 bytes. The sort routines used were the VAX/VMS SORT and for the IBM a third party software sort called CA-SORT was used. The IBM CPU time was 21 seconds and four minutes elapsed time. The stand-alone VAX 785 CPU time was four minutes and eight minutes elapsed time. Since that time I have conducted several sort tests using the above file on a VAX 750 computer. Each test reflected a different buffer size and number, working set size, or type of sort. The results did not produce any large reduction in CPU times, elapsed times or direct I/O except in the type of sort (address, indexed), where one minute of CPU and five minutes of elapsed time was dropped. The following pages have the tabulated results. VAX-36 PAGESWAPPER - February 1988 - Volume 9 Number 7 I/O Performance Computer: VAX 750 Disk: RA 81 Controller: UDA50 File Type: Sequential Record Size: 255 bytes Number of Records: 123,237 Working set size: 4096 TYPE OF NUMBER OF TIME (MINUTES) DIRECT BUFFER SORT WORK FILES CPU ELAPSE I/O (NUMBER/ SIZE) ________________________________________________________________ RECORD 2 8.47 14.34 10,315 2/1 RECORD 2 8.61 15.23 10,337 4/1 RECORD 2 8.34 14.01 10,328 10/1 RECORD 2 8.59 14.59 10,389 1/16 RECORD 2 8.42 16.22 10,930 6/16 RECORD 2 8.48 15.95 10,505 8/16 RECORD 2 8.36 15.66 10,514 10/16 RECORD 2 8.38 15.70 10,480 6/127 RECORD 2 8.33 15.74 10,450 10/127 ADDRESS 2 6.90 8.00 4,379 1/1 ADDRESS 2 6.89 8.00 4,375 2/1 ADDRESS 2 6.91 8.28 4,481 4/1 ADDRESS 2 6.83 7.97 4,394 10/1 ADDRESS 2 7.00 8.47 4,430 1/16 ADDRESS 2 7.03 10.17 4,652 10/16 INDEX 2 7.37 8.52 4,891 1/16 INDEX 2 7.49 11.31 5,486 10/16 VAX-37 PAGESWAPPER - February 1988 - Volume 9 Number 7 I/O Performance DEFAULT BUFFER SIZE = 16 BLOCKS NUMBER OF BUFFERS = 1 WORKING TIME (MINUTES) DIRECT SET SIZE PAGE FAULTS CPU ELAPSE I/O ________________________________________________________________ 4096 11,512 8.59 14.59 10,389 3584 9,714 8.69 14.44 10,386 3072 7,712 8.50 14.70 10,362 2304 4,702 8.34 14.11 10,402 2152 4,464 8.24 13.96 10,366 2048 4,144 8.30 14.13 10,395 2048* 4,079 8.16 14.09 10,435 1792 3,623 8.51 14.63 10,572 1536 3,172 8.49 15.52 11,027 1280 2,730 8.63 16.27 11,398 1024 8,556 8.89 14.42 11,922 * - BUFFER SIZE = ONE BLOCK NUMBER OF BUFFERS = 10 The next project is the study of the effect on performance and file size when adding a third key to a large Prolog 3 indexed file (1.2 million records, 128 bytes/record). The following report will contain the following information: 1. RMS Utilities - ANAL/RMS, EDIT/FDL, CONVERT/FDL 2. I/O Buffers - Updating with or without buffers 3. File tuning I hope this will help you in your endeavor. If you are in need of any more information, please feel free to contact me. Sincerely, Daryl O. Jones VAX-38 PAGESWAPPER - February 1988 - Volume 9 Number 7 Current Field Change Orders Current Field Change Orders Miscellaneous FCOs presented at the Fall, 1987 Anaheim Symposium Stanley M. Rose Vice-President, Distributed Processing Technical Support Bankers Trust Company New York, New York The purpose of this article is to list various FCOs that were presented in various sessions at the Anaheim Symposium. Each session provided differing amounts of information; the individual presenting the session is listed. H046 The following FCOs were provided by Jack Toto in session H046, "Hardware ECO Update". KDJ11-A M8192-MK009 upgrade to rev etch C1 Part 21-21858-05 KA630 (MicroVAX-II) M7606-AH upgraded to M7606-AS ECO M7606-ML006 Upgrade kit #EQ-01358-02 Fixes memory errors under Ultrix MS630-A (MicroVAX-II memory) M7607-AH upgraded to M7607-AS Fixes machine check "80" (under Ultrix?) VAX-39 PAGESWAPPER - February 1988 - Volume 9 Number 7 Current Field Change Orders RQDX3 M7555 upgraded to etch rev D1 ECO M7555-ML003 6/86 Fixes IRQ Detect Logic error RQDXE (External RD Drive) M7513 upgrade to rev level B1 ECO M7513-ML001 12/12/86 Fixes corrupted data and/or loss of drive format Upgrade to rev level F1 ECO M7513-ML002 Fixes signal lines not properly terminated DEQNA M7504 ECO M7504-MK005 Upgrade to rev level E1 (note: current revision much higher) TQK50 M7546 ECO M7546-SH002 4/4/86 Upgrade to rev level B2 Board has intermittent short circuits ECO M7546-SH003 6/17/86 Upgrade to rev level C1 New E-Proms ECO M7546-SH004 Upgrade to rev level D1 Fixes a problem with PDP-11 Memory ECO M7546-SH005 2/2/87 Upgrade to rev level E1 Replaced E-Proms ECO M7546-SH006 8/5/87 Upgrade to etch rev level F1 Fixes a bus grant problem VAX-40 PAGESWAPPER - February 1988 - Volume 9 Number 7 Current Field Change Orders BA23-A ECO BA23-A-MK003 Upgrade to BA23-A rev C1 Power cable replaced with higher capacity cable ECO BA23-A-MK004 Upgrade to BA23-A rev D1 Connector replaced with higher capacity connector N030 The following FCOs were provided in session N030, "Communications Hardware & ECOs" by Ed Badger, Perry Sutton, and Brian Williams. DEBNT All DEBNTs will be replaced with DEBNAs, rev F Upgrade kit #EQ-01486-01 DEBNA rev. D This will be upgraded to DEBNA, rev E Upgrade kit #EQ-01500-01 Notes: 1) DEBNA rev E and rev F are functionally identical, and differ only in board layout. 2) It was stated in session V070, "VMS Update", by Harriet Cohen that the _D_E_B_N_T _w_i_l_l _n_o_t _b_e _s_u_p_p_o_r_t_e_d effective with VMS V4.6. Both revisions of the DEBNA also need the following: New ETdriver: Part #EQ-01500-02 (Good for VMS V4.5 and V4.6) New Diagnostics: Part #EQ-01500-03 DELUA M7521 to revision F1 This FCO to be available in the Spring Fixes: 1) Self Test Problem on 83xx processors 2) Problems with TSM/LAT/LAVc - slowdowns VAX-41 PAGESWAPPER - February 1988 - Volume 9 Number 7 Current Field Change Orders DEQNA M7504 to rev K4 Problems: 1) Late Collision may cause data to be altered on receive packet. DEBET (LANBridge-100) Upgrade to rev E8 Upgrade kit #EQ-01479-01 Fixes: 1) Overrun of Ethernet Address table in large networks. 2) Forwards Loopback Messages with wrong next address. 3) Supports LAN Monitor DEMPR Upgrade to rev C1 Upgrade part #EQ-01491-01 (120volt) #EQ-01491-02 (240volt) Fixes: 1) Cable short brings down whole network. Revised unit segments the shorted section from the whole. DMB32 Upgrade of module T1012 to rev H2 ECO to be issued in late Spring Fixes: 1) Printer Port Performance 2) Receive Sync Characters DMZ32 Upgrade of module M8398 to rev H1 Upgrade kit #EQ-01457-01 Fixes: 1) DMA Transaction Timing Problem 2) Split Speed Baud Rate Problem 3) Received Incorrect Character Problem VAX-42 PAGESWAPPER - February 1988 - Volume 9 Number 7 Current Field Change Orders PRO-380 Console BOF The following information was supplied by Alant Schmidt in the PRO-380 console Birds-Of-Feather session on Thursday. This information applies to the 85x0, 8700 and 8800 processors. Revision 7 of the PRO console code will go to the SDC in mid-January, and will be available after the normal ramp-up time. Revision 7 fixes most of the outstanding problems, including loss of time on a re-boot. The following chart was presented showing releases and their relationship to diagnostic releases: Diagnostic Diagnostic Console Version Release Version Name 22D 22 D 22E 22 E 28 28 E 29 29 F/6.0 30 30 G/7.0 1/88 31 31 ?? Q4/88 LUG News from respective LUG Newsletters Meeting topics for February: St Louis Local User's Group 5:30 pm at the Salad Bowl Restaurant 3949 Lindell Boulevard System Management and Security (originally scheduled for October) VAX-43 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot Spring 1988 System Improvement Request Ballot Mark Oakley, SIR Coordinator HHOOLLDD IITT!! DDOONN''TT PPUUTT TTHHIISS OOFFFF!! TTHHEE DDEEAADDLLIINNEE IISS AAPPRRIILL 88!! You have an opinion about what is right or wrong with VAX. Here is your chance to influence the directions of future DEC development. The VAX Systems SIG System Improvement Request (SIR) program is an important method for the VAX user community to provide input to Digital. Your opinion is important, and every ballot adds to the influence of the SIR program. We have a tight deadline this time. Please take the time to vote. I really want to hear from you! On the following pages, you will find the current collection of System Improvement Requests. Please take the time to review these SIR's and assess their effect on your use of VAX's. Then indicate your preferences as described below. TTHHEE SSIIRR BBAALLLLOOTT FFOORRMM AAPPPPEEAARRSS IINN TTHHEE ""QQUUEESSTTIIOONNNNAAIIRREE"" SSEECCTTIIOONN OOFF TTHHIISS NNEEWWSSLLEETTTTEERR.. Also, please fill out the questionnaire portion of the ballot. This information is important to DEC, as it points out which requests are important to a particular segment of the VAX community. Occasionally there is some confusion about the ballot. You can only vote for the SIR's that are listed below. Please provide your six-digit DECUS membership number. (If you subscribe to the DECUS U.S. CHAPTER SIGs NEWSLETTER, then your membership number is the first six digits of the twelve-digit number on the mailing address.) If you are a non-US DECUS member, please provide your full membership number. The returns from this ballot will be totalled, and Digital will provide a formal response to the 10 items which receive the most votes. The results and DEC's responses will be given at the VAX SYSTEM SIG SYSTEM IMPROVEMENT REQUESTS session of the Spring 1988 DECUS Symposium in Cincinnati. Instructions For Voting The ballot form contains two sections, a "support" section and an "oppose" section. To indicate your support for an SIR, enter its number in the "support" section of the ballot. You may list from zero to fifteen SIR's in this section. To indicate your VAX-44 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot opposition to an SIR you consider detrimental, enter its number in the "oppose" section. You may list from zero to five SIR's in this section. Please return your ballot IIMMMMEEDDIIAATTEELLYY. To allow time for DEC to respond, BBAALLLLOOTTSS RREECCEEIIVVEEDD AAFFTTEERR AAPPRRIILL 88 CCAANNNNOOTT BBEE CCOOUUNNTTEEDD.. Any ballot not specifying a DECUS membership number will not be counted. Only one ballot per member will be accepted. _C_l_u_s_t_e_r_s SIR: S88-1 Abstract: Provide high-speed communication services on a VAXcluster using SCS, not DECnet. Description: Communication services between VAXcluster nodes is currently limited to DECnet or file sharing schemes. Digital should implement a communications interface (device driver) that uses the System Communication Services (SCS) to provide high speed data transfer between VAXcluster nodes. This would assist individual sites implementing cluster shareable devices. SIR: S88-2 Abstract: Use a better load balancing scheme when dequeueing jobs from generic batch queues to execution queues. Description: When dequeueing a job from a generic batch queue VMS tries to minimize the ratio of executing jobs to job limit for all the execution queues. If two CPUs have an equal number of executing jobs, and equal job limit, the job will be dequeued to the first CPU with the minimum ratio. It would be more useful if the job was dequeued, instead, to the processor with the lightest CPU load. A method similar to the LAT scheme for terminal connections is suggested. _C_o_m_m_e_r_c_i_a_l VAX-45 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot SIR: S88-3 Abstract: Operators need the capability to deallocate tape drives from users. Description: Users sometimes allocate tape drives for long periods of time. During this period, the user may not be using the drive. There needs to be a way for the operators to deallocate these drives from the users so that they can be used again. SIR: S88-4 Abstract: Improve tape label recognition capability. Description: When processing multi-volume tapes, no assumptions should be made about the label names. In all cases the operator should be prompted for the volume id. SIR: S88-5 Abstract: Improve batch job functionality by providing job "filtering" into defined classes. Description: Concepts such as working sets or time limits can be confusing to unsophisticated users. The number of types of batch queues can become unmanageable in a large system. Management needs a capability to filter jobs that are submitted to a small number of generic-type queues into possibly many execution queues. "Characteristics" are not acceptable. Operators need to control execution queues that have "long", "short", or "regular" jobs. Users should not have to specify both a time limit and an appropriate characteristic to have their jobs go into the "short" queue. SIR: S88-6 Abstract: Provide a "virtual disk" capability. Description: As disk volumes get larger the adequacy of the disk quota utility diminishes. There needs to be a way to partition the physical or logical volumes and apply quotas to the partitions. Currently, there is public-domain software to provide "virtual disks" or partitions, but it is desirable that DEC provide this capability. VAX-46 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot SIR: S88-7 Abstract: Provide identity information about LAT sessions. Description: System managers must be able to locate the physical terminal on which a particular session took place. This information is useful for trouble-shooting, tracking usage, and monitoring security. VMS accounting should be able to include information about the port number and terminal server name in the accounting record for LAT sessions. If this information could not be included in the accounting, then it would be acceptable to record it elsewhere, perhaps in a log file. SIR: S88-8 Abstract: Enhance the ALLOCATE services to allow requests to be queued. Description: Enhance the ALLOCATE services to enable a user to optionally queue the allocation request when all qualifying devices are busy. Device allocation should be handled by a queue manager similar to the VMS V4.0 print queue manager, and the allocation request queues should be made cluster wide to support cluster-visible devices. User functions should include the ability to specify characteristics required of a generic device, the automatic notification of allocation, the ability to delete an allocation request, the ability to examine the allocation request queue, and the ability to do other interactive processing while waiting for an allocation request to be granted. Operator functions should include the ability to mark failing devices as unavailable and the ability to force a deallocate. Manager functions should include the ability to define device characteristics and specify physical devices as possessing those characteristics. Device allocation and deallocation should place records in the accounting file so that charge back accounting can be done for allocated devices. A mechanism for avoiding deadlocks when multiple devices are allocated should be provided. VAX-47 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot Examples: $ ALLOCATE/QUEUED/WAIT TAPE$CLASS:- /CHARACTERISTICS=(DENSITY:6250) LOGICAL_TAPE (Queue an allocation request for a tape drive with 6250 bpi capability and wait until the allocation has completed.) $ ALLOCATE/QUEUED/NOWAIT/NOTIFY DISK$CLASS:- /CHARACTERISTICS=(RA60) MY_DISK_PACK (Queue an allocation request for an RA60 disk drive and return control to my terminal. Notify me when the allocation has completed.) $ ALLOCATE/NOQUEUED TERMINAL$CLASS:- /CHAR=(AUTODIAL,BAUD:1200) DIAL_OUT_MODEM (Allocate a terminal device with a 1200 baud autodial modem but don't queue the request. Give an error if all such devices are allocated.) The queueing capability might be implemented via a symbiont. The queueing capability should also be provided for the MOUNT services. SIR: S88-9 Abstract: Provide support for simple project accounting. Description: The Spring 1985 VAX SIR Ballot contained a request for project accounting in VMS. Digital's response was "We also feel that project accounting is very important...We feel that this is a reasonably complex area and, as such, some of the enhancements that we intend to make in this area will appear over time." Project accounting is something that is desperately needed at large sites. In its simplest form, project accounting should provide a SET PROJECT command that would write a process accounting record, and start recording a new record with a new account string specified by the user. The account string should be verified before these actions take place. The system manager should be allowed to set up a file which specifies which UIC's are permitted to use individual account strings. Many sites have immediate government or internal security requirements for "one username per user" level of VAX-48 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot accountability. DEC should provide this form of project accounting until their full-blown system is available. SIR: S88-10 Abstract: Enhance BACKUP to provide first and last file names logged for each volume of storage media and an incremental restore capability for a directory structure. Description: BACKUP should log the first and last file on each volume to assist in choosing tapes for restoration. Directories or entire directory trees sometimes become unusuable. To aid in recovery, BACKUP should support the following procedure: 1. Delete the structure(s) affected 2. Restore that structure from the last image mode backup 3. Restore the selected structure(s) in incremental mode. _D_C_L _a_n_d _U_t_i_l_i_t_i_e_s SIR: S88-11 Abstract: The DCL WRITE command needs a method for terminating a write operation without generating a CR/LF sequence. Description: When using the DCL write statement, there currently is no method to terminate the operation and prevent the CR/LF sequence. This would be useful when positioning the cursor on the display to a particular location, such as a default response indicator or fixed response location. Any subsequent read operation performed from the terminal would need to properly process any type-ahead text as well as normal response characters not typed ahead. VAX-49 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot SIR: S88-12 Abstract: More capabilities for VAX-11 RSX BRU. Description: VAX-11 BRU would be more convenient to use for interchanging files between RSX systems and VMS systems if VAX-11 BRU were enhanced to know enough of ODS-2 structures to allow access to rooted directories. This feature would permit reading or writing of the rooted portion of the directory tree as if it were the [0,0] directory of the device as BRU sees it. SIR: S88-13 Abstract: Enhanced command line RECALL capabilities. Description: The functionality of the command line RECALL facility would be greatly increased if users were able to tailor some features to their specific needs. It would be desirable if these (YES FOLKS we are asking for still more SYSGEN parameters) features could be set for each user. However, a setting for the entire site would be acceptable. The expansion tailoring would allow sites to set: 1. The size in bytes of the command line recall buffer. 2. The maximum number of commands to be recalled. 3. The size of the DCL command line expansion area. 4. The size of the DCL command input area, to allow larger commands to be passed to user written programs by the foreign command interface processor. SIR: S88-14 Abstract: Extend DCL TABLES Description: Many users desire or have the need to modify DCL TABLES to restrict access to certain commands, command options, or add their own or third party software as a DCL command. Some form of support to facilitate this is needed, even an extra-cost-layered product. A minimal form of support VAX-50 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot would be a listing program that would produce readable output to allow the user to: 1. Check conflicts in names. 2. Verify options. 3. Determine if the command exists, when it was added, and if it it was from VMS. SIR: S88-15 Abstract: DCL status return enhancements. Description: Programs that are called by DCL should implement some form of expanded status reporting that is testable at the DCL command level. For example, if DIFFERENCES were invoked, some indication in $STATUS if the files were the same or different would permit users to act accordingly. For example: $DIFFERENCE F1.TXT F2.TXT $IF $STATUS .EQ. DCL$DIF_NONE THEN - $DELETE F2.TXT;1 Some form of documentation would be needed to allow users to write appropriate tests. The return values could be defined either by numeric returns or reserved symbols known to DCL. SIR: S88-16 Abstract: Enhance SET HOST error reporting. Description: The DCL trapping of CONTROL_Y within the SET HOST command and the current exit processing of a yes response to the question: Are you repeating CONTROL_Y to abort the remote session... fails to indicate that the SET HOST connection was aborted. Some indication of failure to successfully log off would aid in processing errors or performing any needed cleanup. VAX-51 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot SIR: S88-17 Abstract: Add the ability to run a detached process for a specified user name. Description: The ability to run a detached process under a specified user name for a suitably privileged user would provide the ability to do this directly. A technique of putting the run command in a command proc and doing a SUBMIT/USER works but may require additional work to get the job to the start of a batch queue or even require the creation of a batch queue. SIR: S88-18 Abstract: DCL /LOG qualifier is not consistent. Description: Some commands (Backup, Copy etc.) accept /LOG, others (Print, Submit) use /IDENTIFY to produce documentary output. These commands should all support the /LOG or some new qualifier, /DOCUMENT for example, that would produce documentary output. This new qualifier would be consistent across all commands and ignored on commands that can produce documentary output such as SHOW TIME. SIR: S88-19 Abstract: VMS needs a "Control Print Screen" screen command to a file. Description: In many cases VMS users need to produce a disk file with the transcript of a terminal session. The need for this is to produce documentation for manuals or turn in homework assignments for class. The SET HOST/LOG does not completely emulate the terminal output, especially when CR/LF output is suppressed to allow the user to respond to a question on the same line. Also if the SET HOST command has been removed for a user this feature becomes non-existent. Some command such as SET LOGGING TO is needed to provide this feature. The UNIX script utility would provide a good model for this. Obviously if the captured file contained graphics escape sequences or other VAX-52 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot non-printable characters it would be the users responsibility to handle them. The ability to record escape sequences into a file might also be a useful debugging tool for some users. SIR: S88-20 Abstract: Enhance sysgen parameter readability. Description: It would be more useful if SYSGEN were modified to provide a more useful organization of parameters, e.g. memory, terminal, timing, security, VMS mystery, etc. Sorting the output into alphabetic order would also make finding the parameter value in the listings easier. SIR: S88-21 Abstract: Mail enhancements. Description: 1. Allow a user to retract a sent mail message. This could be limited to the last message sent. This would be very useful to retract that nasty undelivered mail message sent to the SYSTEM MANAGER before it is read and you end up with mandatory 32 character one time passwords! 2. Provide a facility to append comments to a received mail message and redistribute it. 3. Provide some form of return receipt when the recipient has read your mail message. 4. Provide a facility to allow users to configure the default printer orientation for printed mail messages. Most mail messages are oriented to portrait mode, not the default landscape mode found on most programmers printers. 5. DEFINE/KEY in mail should support /ERASE in the same way that the DCL DEFINE/KEY does. VAX-53 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot SIR: S88-22 Abstract: SET HOST/DTE enhancement for more modems including those made by Digital. Description: The Digital DF224 modem is not compatible with SET HOST/DTE/ DIAL=number. Please provide support for all recent/modern DEC modems. Support for popular third party modems such as HAYES, RACAL-VADIC, etc. would also be desired. SIR: S88-23 Abstract: Enhance SHOW PROCESS command. Extensions to this command in showing files and subprocesses are needed. Description: Some form of identification is needed for the SHOW PROCESS command to make tracing subprocess trees easier, possibly of the form SHOW PROCESS/SUBPROCESS/ID=. If a user has two processes running in a batch queue or from two terminals, and each process has a subprocess, it is very difficult to determine which subprocess is owned by which parent. The ability to show the the files that a specified process has open is needed. SHOW DEVICE/FILES on one drive systems with many installed images provides too much output. If this feature could also show the current location within each file, then estimating what portion of a file had been processed by a program would be significantly easier. SIR: S88-24 Abstract: MOUNT/FOREIGN and uninitialized tapes. Description: The MOUNT/FOREIGN command will time out and not complete properly on a VIRGIN BLANK tape. Some fix to avoid failing on a blank tape is needed. SIR: S88-25 Abstract: Enhanced DEFINE/KEY capabilities. VAX-54 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot Description: DEFINE/KEY should support control characters and escape sequences; allow multiple input lines to be defined with the extra lines being placed into the type-ahead buffer. For example: $! !Customize keyboard $DEFINE/KEY KP2 "^E" !EDT go to end of line $DEFINE/KEY comma "->DEL" !EDT delete char at cursor $! !MULTIPLE INPUTS $DEFINE/KEY PF4 "^B^H^A:" !Recall and edit command $DEFINE/KEY KP3 "MAILDIR NEW MAIL" SIR: S88-26 Abstract: A /BELL qualifier is needed for certain DCL commands. Description: The addition of a /BELL=n qualifier command to DCL to cause the terminal bell to ring N times with a discernable pause would be very useful to draw attention to the terminal when a long running command completes in any fashion. SIR: S88-27 Abstract: Restore CONTROL_U behavior to pre-V4 status. Description: The CONTROL_U sequence in V4 fails to provide feedback when the terminal is set /LOCAL_ECHO. This is inconsistent with the other control sequences (^B,^C,^O,^Q,^R,^S,^T,^Y,^Z) all of which provide user feedback. Prior to V4 the U sequence both cleared the terminal input buffer and generated a new line/prompt sequence to the terminal. In V4 only the input buffer is cleared which is the expected behavior if the terminal is set /NOECHO/NOLOCAL_ECHO. Given that users of V4 and up may now want this behavior, an additional switch such as /OLD_LOCAL_ECHO would be a way to allow a choice in how the terminal should behave. This request is specifically a request to restore the behavior in /LOCAL_ECHO to what it was prior to V4 and make no changes to the /ECHO and /NOECHO/NOLOCAL_ECHO behavior. VAX-55 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot SIR: S88-28 Abstract: Improving VMS define utility. Description: 1. Almost all DCL commands read from left to right, but the ASSIGN command is right to left. This causes confusion and errors when assigning queues to each other. 2. All features of the ASSIGN command should be provided in the DEFINE command. 3. Since ASSIGN and DEASSIGN exist, DEFINE and UNDEFINE should also exist. 4. In the DCL documentation, related topics should be listed for each command. At least DEFINE could be pointed to DEASSIGN which is not intuitive. _I_n_t_e_r_n_a_l_s SIR: S88-29 Abstract: Provide a "wild card" capability in SYS$GETDVI. Description: It would be very convenient if the SYS$GETDVI system service could return the names of all of the devices on the system. SIR: S88-30 Abstract: Provide various enhancements to the SYS$GETUAI and SYS$SETUAI system services. Description: SYS$GETUAI and SYS$SETUAI should be enhanced so that they provide the same functionality as AUTHORIZE. The following capabilities are needed: VAX-56 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot 1. Support creation and deletion of accounts. 2. Accept unencrypted passwords. Currently, only hashed passwords can be passed to SYS$SETUAI. 3. Provide "wild card" capabilities. It should be possible to return information based on a username "wild card" or uic "wild card". 4. Provide a capability to list unused uic group and member numbers. These enhancements are of critical importance to academic institutions which manage thousands of accounts and require robust and secure mechanisms. SIR: S88-31 Abstract: Enhance the display and setting of terminal communication data. Description: There is a need for the system to explicitly display and set terminal communication data, such as frame size and stop bits. Currently, SYS$QIO calls are needed to select and retrieve this information. The interaction between PASSALL, PASTHRU, PARITY and NOEIGHTBIT should be better documented. SIR: S88-32 Abstract: Enhance the protection and ownership attributes of directory files for project management. Description: In a project environment problems occur when users create files in directories that they do not own. It would be useful if all files created assume the same ownership as the directory in which they were created. It would also be useful if the delete specification of the directory protection controlled the deletion of files in the directory. SIR: S88-33 VAX-57 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot Abstract: Provide a real-time debugger. Description: A real-time debugger is needed for those programmers who work in a real-time environment. SIR: S88-34 Abstract: HSC commands should be able to be issued from DCL command procedures. Description: It would be useful to be able to issue HSC commands from a DCL procedures to perform backups, run diagnostics, etc. It would also be useful if "callable" HSC routines were provided so that programs could be written to control the HSC. SIR: S88-35 Abstract: Provide control of the priority of DECnet processes that perform file transfers. Description: It would be useful if processes that perform transfers of large files across DECnet run at a priority below that of interactive users. This might be controlled by a SYSGEN parameter. SIR: S88-36 Abstract: Provide descriptive text for files. Description: A way to associate descriptive text with files is needed. This text would be especially useful when making decisions about which files to delete. SIR: S88-37 Abstract: READALL should only permit a file to be read. Description: Currently, the READALL privilege permits file protections to be changed. Users with the READALL privilege should only be allowed to read a file, not change the protection. VAX-58 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot SIR: S88-38 Abstract: Images linked on a VMS Version "n+1" system should run on a version "n" system. Description: Sites that develop and support software products must delay operating system upgrades until their customers have upgraded. If images linked on a version "n+1" system could run on a version "n" system, the upgrade would not have to be delayed. SIR: S88-39 Abstract: The DYNSWITCH software should preserve terminal settings. Description: Terminal settings for lines that are used for async-DECnet are altered by the DYNSWITCH image. This image should restore the terminal settings after it finishes with the line. SIR: S88-40 Abstract: Provide a simple capability to display information on a SMG screen from routines that do not call SMG. Description: Some sites have large software packages that have been modified to use the new SMG routines. Many of the old error-handling routines still perform "writes" to the screen without using SMG. "Retrofitting" these routines is costly. There needs to be a simple way to cause these routines to write to the screen without disrupting the contents of the screen. SIR: S88-41 Abstract: Improve the performance of DECnet copies when the source and destination nodes are the same. Description: Access control strings are sometimes used in COPY commands to bypass directory protections. This operation is inefficient because a FAL process must be created and other of overhead associated with DECnet. DECnet copy operations should be optimized when the source node and end node are the same. VAX-59 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot SIR: S88-42 Abstract: An image should be installable as a memory resident routine. Description: With the significant reduction in memory costs and the general increase in the size of memory configurations, this feature that is available on various the PC system would be very useful in VMS. Response time on image activation could be significantly improved if a process were installable as MEMORY RESIDENT. This type of installation would be site dependant and should be easily removable as well if memory needs change unexpectedly. _L_a_n_g_u_a_g_e_s_, _T_o_o_l_s_, _a_n_d _E_d_i_t_o_r_s SIR: S88-43 Abstract: Provide /NOWAIT switch for TPU. Description: If TPU had a /NOWAIT switch that could be set when "DCL" commands were issued to be run by TPU, the user could continue with work in TPU while the "DCL" command continued to run in the subprocess. When the subprocess terminated, TPU would inform the user. A restriction of one "DCL" command running this this mode would be acceptable. It would also be acceptable to have a reserved scrolling region for the message from the "DCL" command to appear. SIR: S88-44 Abstract: The VAX Macro Assembler should process statements past the ".END" directive. Description: It would be convenient to store Macro source in a file and delimit subroutines with the ".END" directive. Currently, the assembler terminates the processing of the source file when this directive is discovered. SIR: S88-45 VAX-60 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot Abstract: Provide a VAX ADA package for VMS Run-Time Library Routines. Description: Currently there is no package for the VMS Run-Time Library rountines, Sort/Merge routines, Convert routines, etc. It is very time consuming for a programmer to construct these packages. Digital should provide these packages. SIR: S88-46 Abstract: Provide line-number support in TPU Description: TPU should be enhanced to provide line-number support. The following capabilities are needed: 1. A command to "go to" a desired line. 2. A command to return the current line number. 3. A command to sequence a file, similar to the EXIT/SEQUENCE command in EDT. _S_e_c_u_r_i_t_y SIR: S88-47 Abstract: Eliminate the automatic unsolicited ACE on file creation. Description: When a user holding a rights identifier (with the RESOURCE attribute) creates a file in a directory owned by that rights identifier, an ACE is automatically added to the ACL for the created file. This unsolicited ACE gives the creator UIC full (read, write, execute, delete, and control) access to the file. This design feature was intended to insure that the creator of a file retains access and is used at some sites to set up a scratch area in which users can create temporary files. However, it causes problems for other sites in two ways. First, a number of users and system managers have been confused by the appearance of this unsolicited ACE. Secondly and more importantly, once a user creates a file in a project-owned VAX-61 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot directory and gets automatic CONTROL access to the file, it is very hard to revoke that user's access when the user leaves the project. Not only must the system/project manager remove the ACE that gives the user's UIC access to the file, but he must also carefully review the ACL to make sure that the user has not added other ACEs that give him access via other rights identifiers. When a large number of project-owned files are involved, this can become a very cumbersome operation. It is proposed that the automatic generation of this unsolicited ACE be eliminated and that a new type of default ACE be defined to replace it. This new ACE might take the form (IDENTIFIER=$CREATOR$,OPTIONS=DEFAULT, ACCESS=whatever_is_desired). When placed on a directory that is owned by an identifier with the RESOURCE attribute, this ACE would cause an ACE to be placed on each file created in that directory giving the creator UIC the specified access. This would allow sites that need this feature to request it explicitly without the confusion of an unsolicited ACE, and it would also allow other sites to give users less than complete access to project-owned files. SIR: S88-48 Abstract: Prevent password reuse by users Description: The only way to prevent a user from keeping the same password is to require the use of the password generator via the GENPWD flag in the UAF. If users are allowed to change their own passwords, then when the password expires, they may change to a new password and then immediately change back to the old one. A way is desired to prevent users from retaining the same password for long periods of time without setting the GENPWD flag. One way to accomplish this would be to maintain a history of the last "n" passwords and to enforce a minimum password lifetime, so that the user could not quickly cycle back to his old familiar password. SIR: S88-49 VAX-62 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot Abstract: Suppress login failure due to "Error reading command input" Description: The number of login failures due to "Error reading command input" can be very large on some systems and do not normally indicate a security problem. In many cases they are associated with terminal problems or timeouts. However, the security alarms due to such errors can fill up the security audit log and obscure real security problems in the system. A mechanism is needed to suppress logging of the login failures due to "Error reading command input" while recording other "real" login failures, such as bad username/password or attempt to login from an unauthorized source. SIR: S88-50 Abstract: Do not update file modification date when changing protections. Description: When users change file protections, either via ACL's or UIC protection codes, the file system updates the file modification dates. This is done so that BACKUP will save the new protections. While this is a very useful feature, it has several drawbacks--(1) users like to know when they last modified the content of the files, and (2) some source code control systems use the modification date to determine whether a source file has been updated. We need a way to have file protections backed up without losing the important information contained in the file modification date. Perhaps a /BACKUP qualifier is needed for the SET PROTECTION command to allow the user to request that the file modification date be updated. SIR: S88-51 Abstract: Mechanism needed to file access via a user-defined image. Description: Non-privileged users sometimes need to give other non-privileged users controlled access to data files through a program. Through this facility any user would be able to control who could access his data files and what kind of access they may have. In the current system, in order to allow another user to add a record to a file, that user must be given WRITE access to that file, which means he could alter existing data or delete records from the VAX-63 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot file. Presently this requires the system manager to install the program with privilege, which is both an administrative nuisance and a security problem, as the privileged image would also have access to other system data files as well as the intended files. This mechanism should be under user control, i.e., the user should be able to determine which images could access a file. For example, the UIC of the image and data file could be required to match before access would be permitted. This feature could be implemented by allowing the system manager to install an image with a particular identifier. Then the user could set up the access control list for that file to permit access by that Identifier. This would be less flexible but would permit a user to allow access from images other than his own, e.g., a data base manager. SIR: S88-52 Abstract: Security alarm messages to a file. Description: Add an option to the Access Control Entries (ACE's) that specifies a file into which security alarms for that file/directory are written. This would allow a user to review security alarms for his own files, rather than depending on the system manager to perform the auditing. Of course, security alarms requested by the system manager via the SET AUDIT command should be written to the system-wide security log. SIR: S88-53 Abstract: ACL class names needed for management of complex ACLs. Description: ACLs are very flexible, but unfortunately a full ACL description must be stored on each file that is to be protected. Whenever the ACLs need to be changed on a large set of files in several directories, the process is time-consuming and error prone. Also, files restored from a previous backup after the ACLs have been changed revert to their original ACLs. If ACL class names were available, they could be redefined without necessitating a change in the ACLs on the individual files. References to ACL class names could be made via a special type of ACE. VAX-64 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot SIR: S88-54 Abstract: End-to-end encryption of logical connections within DECnet-VAX. Description: The assumption made by DECnet that all nodes and communications paths are trustworthy is not viable in many environments. End-to-end encryption of the data portion of network packets is required in these environments to assure that evesdropping is fruitless, both in Local Area Networks (broadcast) and Wide Area Networks (multi-hop). This encryption should be implemented so as to be transparent to the application programmer and user, i.e., the mechanism should be located in the NSP (or OSI session) layer. New encryption keys should be generated for each logical connection between cooperating, encryption-capable processors. (Some nodes will not be capable of encryption and should be allowed to participate in the network without performing encryption.) Intermediate nodes should not be required to participate in, or be knowledgeable of, the key distribution/management or the encryption process. The DES algorithm should be utilized in the near term but should be readily replaced as NBS standards change. Provisions should be made for encryption hardware to boost performance where necessary. SIR: S88-55 Abstract: Support DECnet proxy access for SET HOST command. Description: When a user logs into a remote host via the SET HOST command and a DECnet proxy exists in the NETUAF on that host, the user should have the option of being automatically logged into that proxy account. This would be extremely helpful to less advanced users who switch frequently between systems. It would also reduce the chances of disclosing user passwords, since they would not be transmitted across the network if the proxy were used. A /PROXY qualifier could be added to the SET HOST command to allow the user to request proxy access. SIR: S88-56 VAX-65 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot Abstract: Better control over DECnet remote file access. Description: The RMS file protection defines WORLD access to include all those outside the owner's group. It would be useful to define several classes of users as follows: 1. All WORLD users on the local node. 2. All users local to this VAXcluster. 3. All users on nodes within this DECnet area. LOGINOUT currently gives a process the Identifier NETWORK if that process is being created in response to a network request. It would be useful to obtain greater granularity of access control for network processes by having additional identifiers created based up the node, cluster, and area from which the access is being attempted. This capability might possibly be achieved by having the File Access Listener, LOGINOUT, or some other privileged image set up the additional process Identifiers. SIR: S88-57 Abstract: Enhance COPY to copy ACL's. Description: The COPY utility does not currently handle ACL's. It should be enhanced to propagate any ACL's from the source file to the destination file. However, there may be many times when a user is copying another user's file in order to modify it for his/her own purpose. It is likely that in such cases the user would not want to propagate ACL's from the original file. Therefore, this capability should be available via an additional qualifier to COPY, e.g., /PROPAGATE. SIR: S88-58 Abstract: Provide lexical function for getting RIGHTSLIST information Description: An F$RIGHTS lexical function should be provided to return the list of identifiers held by a user (similar to SYS$FINDHELD). Also, an F$ACCESS should be provided to return a boolean logical value indicating whether access to an object is allowed given an input rights list. VAX-66 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot SIR: S88-59 Abstract: Allow a general identifier to be the owner of a process. Description: It should be possible to make a general identifier the owner of a process (in place of a UIC), so that (1) owner access will be granted via the protection mask to objects owned by that identifier and (2) RMS scratch files will be owned by that identifier and charged against its disk quota. SIR: S88-60 Abstract: Allow security alarm ACE to be bypassed by certain users. Description: Presently, security alarm ACEs "float" to the top of an ACL. If many users are accessing a file, it may be desirable to alarm accesses by certain "casual" users, while not generating alarms for the "regular" users of the file. This would prevent the large number of "normal" security alarms generated by the regular users from obscuring the alarms generated by other "casual" users of the file; otherwise, the interesting security alarms by the casual users might be overlooked in the large volume of "normal" security alarms. _S_y_s_t_e_m _M_a_n_a_g_e_m_e_n_t SIR: S88-61 Abstract: Print form setup and reset modules exactly as requested. Description: The form setup module and printer reset module feature of VMS V4.x print queues, provides a powerful and flexible means of controlling modern printers (especially laser printers). However, many third-party printers use setup strings that are not valid ANSI escape sequences. The VMS and LAT symbionts add a formfeed after these strings which results in a blank page between each file in a print job. This formfeed is not necessary and definitely not wanted. Implementing this change would cause the VAX-67 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot modules to react consistently regardless of the sequences embedded in them. SIR: S88-62 Abstract: Provide BACKUP with the ability to dismount tapes and deallocate tape drives as soon as possible. Description: BACKUP should have the ability to dismount and deallocate tape drives as soon as it is finished using them (and before it exits). Currently, after a large image BACKUP using the /RECORD qualifier, the tape remains mounted and the tape drive allocated until the recording pass is complete (this can take twenty minutes on a full RA81). At a facility where tape drive use is high, it is unacceptable (and frustrating) to require a tape drive to be allocated longer than is necessary. As higher density disk drives become available, this problem will become more acute. SIR: S88-63 Abstract: Add a bell character (control-G) to BACKUP messages which require user action. Description: When BACKUP is run interactively a message requiring a user to respond can easily go unnoticed. Adding a bell character (control-G) to those messages would be beneficial. SIR: S88-64 Abstract: Provide the ability to limit the number of simultaneous interactive logins by a single user. Description: Users can tie up more than their fair share of system resources by logging in at multiple terminals. System managers need a way to control this on a per-user basis. With the increasing use of terminal servers this problem will become more serious as users will not necessarily be limited by physical access to only a single terminal. VAX-68 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot SIR: S88-65 Abstract: Provide a mechanism for distributed management of UAF parameters. Description: In a large installation with many users there is a large burden on a single person to manage the UAF. For example, the system manager might require users who have forgotten their password to present themselves physically before he will give them a new one. In a large installation with a geographically dispersed community, this may not be feasible. A method for allowing certain users to have control over the UAF records of other users, but not all users, is required. Something as flexible as assigning ACLs to allow this function would be preferable, but it would be acceptable to implement it via UIC security and GROUP/WORLD privileges. SIR: S88-66 Abstract: Provide the ability to specify the working set quota and extent of specific images via the INSTALL program. Description: Even though working set values are specified on a process specific basis, they are actually more image specific. It would be more efficient to give users smaller working set values and let specific images which need more memory, be allowed it via the INSTALL program. This will allow the system manager to have greater control over system performance. SIR: S88-67 Abstract: Provide the ability to specify the priority of specific images via the INSTALL program. Description: There are programs on any system which would use the CPU more efficiently if they were to automatically be run at a specific priority. For example, response time is improved if word processor software is run at a priority greater of five (rather than the "normal" priority of four). Allowing the system manager to use the INSTALL program to force programs to run at specific priorities would allow each installation to tailor their operating environment for their given job mix. VAX-69 PAGESWAPPER - February 1988 - Volume 9 Number 7 Spring 1988 System Improvement Request Ballot SIR: S88-68 Abstract: Support installation of multiple versions of layered products (such as languages) on the same machine. Description: While Digital tries very hard to avoid problems, updates are not always perfect. It would be beneficial to allow some users to use a new version of a layered product while others might stay on the older version. If a bug is found in the new version, the affected users can fall back to the previous version. Datatrieve offers this capability but many other products do not. Multiple version installations should be addressed, and hopefully supported and documented, for all layered products. SIR: S88-69 Abstract: Standalone BACKUP should be supported on a greater variety of devices. Description: It would be convenient if Standalone BACKUP could be booted from RX02 and tape drive units. RX02 drives are faster than RX01 drives, can hold two floppies, and can operate at double density. Standalone BACKUP would boot much faster from the RX02. Currently, Standalone BACKUP can be booted from the TK50 and TU58. It seems that this capability could be extended to other non-random access devices (TU78, TU81, etc.). Such a capability might be an attractive alternative to the TU58 and other slow devices. SIR: S88-70 Abstract: Enhance BACKUP to provide additional attributes for output files. Description: BACKUP should provide the same qualifiers that are available on the SET FILE command (e.g. /PROTECTION, /ACL, etc.). Such qualifiers would facilitate the restoration of files. VAX-70 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS Anaheim VAXnotes Excerpts - VMS NOTE Any authorship indicated in these entries is considerably less certain than other Pageswapper material. Attribution to any individual should be taken with a grain of salt. ================================================================ Note 6.0 Can the banner page auto-sizing be disabled? 15 replies "" 17 lines 8-DEC-1987 10:51 ---------------------------------------------------------------- Does any know of a patch to the Print Symbiont that will disable the automatic resizing of the banner pages (Flag, Burst, Trailer) when printing? All-in-1 recommends using the ALL-IN-1 form for printing with WPS+ which has a width of 132 and a length of 255. This causes the print info (Username, filename), when automatically centered, to be lost on the right hand side (especially if your Username is extremely short). Also, the Flag page will be printed over multiple pages, wasting a disgusting amount of paper on our LN03s, because of the extra long page size. Don Mozdzen GMF Robotics 2000 S. Adams Rd. Auburn Hills, MI 48057 (313) 377-7416 ================================================================ Note 6.6 Can the banner page auto-sizing be disabled? 6 of 15 "Jack Patteeuw, Ford Motor Co." 9 lines 8-DEC-1987 17:12 -< E Z !! >- ---------------------------------------------------------------- Forget what ALL-IN-1 asks for ! Set the width and length of the form to something that is reasonable and then, tell the form /NOWRAP/NOTRUNCATE, tell the queue /DEFAULT=NOFEED and use a setup module to set the LN03 margins to the max. This works fine on my system !! VAX-71 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS P.S. If the printer is on a terminal port make certain to: SET TERMINAL/PERMANENT/SCOPE/NOWRAP ================================================================ Note 6.8 Can the banner page auto-sizing be disabled? 8 of 15 "Frank J. Nagy, VAX Guru&Wizard" 26 lines 9-DEC-1987 09:46 -< Setup forms and mix in a bit of DECnet >- ---------------------------------------------------------------- Yep, that's what I did. I set the printer width and line length and the forms width and line length to reasonable values (66 lines and 132 columns) and then defined the form as /NOWRAP/NOTRUNCATE and everything worked well. Since this was not the default form, I then changed the printer tables of the word processing product (Mass-11 from MEC) to use DECnet task-to-task communications to a command procedure which: - deciphered SYS$NET to determine the network object name being invoked. This was used to select the output print queue. - create an empty file of the appropriate characteristics using CREATE/FDL (from examining a file made by Mass-11, I determined what was needed here). - APPENDed SYS$NET to this empty file. - PRINTed the file to the selected (by network object name) file with appropriate PRINT qualifiers. This command procedure was placed in SYS$SYSTEM (just for spite) and, using NCP, installed under about a dozen different DECnet object names. Worked like a charm - and is still working merrily away today! VAX-72 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS ================================================================ Note 6.9 Can the banner page auto-sizing be disabled? 9 of 15 "John Osudar" 5 lines 9-DEC-1987 09:49 -< I like it >- ---------------------------------------------------------------- RE: < Note 6.8 by VAXFAM::FNAGY "Frank J. Nagy, VAX Guru&Wizard" > -< Setup forms and mix in a bit of DECnet >- Impressive! (Now I REALLY believe the "title" that follows your name! :-) ================================================================ Note 9.1 Terminal printer ports 1 of 7 "Frank J. Nagy, VAX Guru&Wizard" 4 lines 9-DEC-1987 09:51 -< TRMPRINT - SIG tape program >- ---------------------------------------------------------------- There is a program on the VAX SIG tapes (within the past 2 years or so) called TRMPRINT which allows a user to print a file on the printer attached to his terminal. We have used it to very good effect. ================================================================ Note 10.7 Digital care to respond 7 of 7 "" 11 lines 11-DEC-1987 11:05 -< We are listening. Thanks for the feedback. >- ---------------------------------------------------------------- We (Digital) are aware of the issues which have been raised over SPRs, including those in the Pageswapper system notes file. We have several ongoing projects in place which are designed to address these issues. When our plans are finalized, we intend to communicate them to the user community in an appropriate manner. Thank you for your continuing interest and feedback concerning SPRs. Bob Bowman Technical Development Consultant VAX/VMS Service Delivery Group - CSC/CS (SPR Processing Team) VAX-73 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS ================================================================ Note 16.0 8800 time incorrect after some reboots. 6 replies "Jeff Blaalid, Rockwell Int" 22 lines 9-DEC-1987 14:53 ---------------------------------------------------------------- We have a VAXcluster of an 8800 and a 780 with one HSC50. Sometimes when the 8800 reboots it comes up with the incorrect system time (usually in the future) and this really screws things up!!!!!!!!! The last example of this was we shutdown the 8800 and 780 with the re-boot option. When the 780 came back everything was ok but the 8800 time was set to 5-aug-1988. The actual date was the 7-dec-1987. I talked to my field service people and they stated that with V4.6 VMS and V5.0 of the console this problem should be corrected.. I guess not - we have been at V4.6 for 4 months and V5.0 since the 8800 was installed (April, 1987). Any suggestions????? Jeff Blaalid Rockwell International Newport Beach, CA 92660 ================================================================ Note 16.1 8800 time incorrect after some reboots. 1 of 6 "" 5 lines 9-DEC-1987 17:27 -< Do a set time from the PRO >- ---------------------------------------------------------------- We have had similar problems with our 8700. I think the problem is that the PRO console maintains its own clock which seems to be the one that is used when the system boots. It doesn't seem that this clock is updated by the SET TIME VMS command. I haven't noticed this problem reoccur since i set the time on the console from the PROs DCL. VAX-74 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS ================================================================ Note 16.2 8800 time incorrect after some reboots. 2 of 6 "" 13 lines 9-DEC-1987 17:46 -< Also experienced incorrect system time on reboot >- ---------------------------------------------------------------- I have had same problem on a cluster with 2 8650s and 1 8700. After a power failure, the 1 8650 came back up with a date 4 months in the future and the other 2 machines came back (warm- restarted) with the correct time. Our operators then rebooted all 3 machines and got all the times wrong! I certainly had a mess when I came in that morning. I can't remember if that was before or after I upgraded from V4.5 to V4.6. I have not had the problem on normal reboots since then but one time startup did prompt for system time and I have no idea why. Sorry, I don't have a solution, but I am interested in one as well. Ken Riggleman Eli Lilly Indianapolis, IN 46285 ================================================================ Note 16.3 8800 time incorrect after some reboots. 3 of 6 "Alan B. Hunt, Powertrain, Ford Motor"4 lines 9-DEC-1987 17:47 -< known problem >- ---------------------------------------------------------------- The previous comment is true. We have the problem. VMS engineering is aware of the problem and is still trying to come up with a fix. V6 of the console software does not fix it. Unclear if V7 will fix it. Resetting the pro time is about it for a work around. ================================================================ Note 16.4 8800 time incorrect after some reboots. 4 of 6 "Yin Cheung" 2 lines 10-DEC-1987 10:13 -< Same problem here >- ---------------------------------------------------------------- We ran into the same problem on our 8700. We were told that this is caused by a bug in the PRO console software. VAX-75 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS ================================================================ Note 16.5 8800 time incorrect after some reboots. 5 of 6 "Jeff Blaalid, Rockwell Int" 5 lines 10-DEC-1987 11:40 -< Reply to 16.1 >- ---------------------------------------------------------------- Re: 16.1 The PRO's time is correct -- I looked into that right away. Jeff Blaalid ================================================================ Note 16.6 8800 time incorrect after some reboots. 6 of 6 "Pete Sivia, Dow Chemical" 51 lines 11-DEC-1987 11:42 -< Yes: clock and a problem and there's a fix >- ---------------------------------------------------------------- There was a BOF this morning on the wonders (and severe agony) of using the PRO 380 as a console device. Lots of problems that they admit to (for which I am very grateful) and they are at least working on solutions. Now if only their info could get out into the field a bit faster... Anyway, time problem: Yep, there is a problem by which the simulated 32-bit register that they create on the PRO 380 to handle the time that was issued from the VAX is corrupted. So you wind up with weird times. Suggested fix was to have your field service folks contact Product Support (CSSE) in Lawrence, Mass. and ask for: "V5.0 PRO 380 CONSOLE WITH R/O TODR" This implements a read-only time of day register and what it does is to tell the PRO to ignore whatever the VAX tries to send to the simulated 32-bit register on the PRO. So, it sounds like the VAX will always ask for the time upon boot which is preferable to trying to stop all the batch jobs that kick off because the clock was set to the future.... Note that the PRO 380 software will actually say "V5.0 with R/O TODR" on the banner. Field Service has to ask internally for it. You might also be able to get a command file that executes some magic commands that can tell you if the PRO 380 32-bit simulated register is corrupted. Note that setting time from the VAX has something like a 20% chance of corrupting this VAX-76 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS register and you won't know about it until you try to reboot the 85xx/87xx/88xx machine. The actual fix for this problem is more than likely not until Rev. 7 of the code which we might see in the April '88 timeframe. While on the PRO 380 fun and games, Alant suggested that: - Ignore Rev. 6 of the PRO 380 console software. - Get at least to Rev. 5 (also known as E) which as been available for some time. - When Rev. 7 comes out, put it in ASAP. Pete Sivia Dow Chemical 258 Bldg. Midland, MI 48667 (517/636-6656) ================================================================ Note 24.0 <<< VMS Microfiche Listings >>> 7 replies "" 17 lines 10-DEC-1987 11:49 ---------------------------------------------------------------- If you have not noticed, VMS Microfiche listings are now a separate service. In order to receive Microfiche, you must contact software services and (1) sign a license (costs ...); and (2) sign a support contract to receive updates (costs less than $20 per month). This changed with V4.4, so you may not have noticed this yet. There was mention of this in the cover letter for V4.4, but DEC has not really publicized this. If you want to keep receiving fiche, YOU have to do something. If in addition you would like to have the LISTINGS available on a CDROM, please send a letter to: Mike Jordan c/o VMS Internals Working Group Box 1063 New York City, NY 10008 VAX-77 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS ================================================================ Note 25.0 diskquota bugs fixed? 2 replies "Alan B. Hunt, Powertrain, Ford Motor"14 lines 10-DEC-1987 14:06 ---------------------------------------------------------------- Two questions on the file system if any developers are out there listening. 1. In a cluster when diskquota is changed for a user on machine A it can be reset to its original value if one of the other machines go down first. The cashes on the machines do not appear to be updated on the other machines by DISKQUOTA. We found that going to each machine in the cluster and doing a SHOW QUOTA updates the caches. We have had some upset management over this thinking we were playing games. 2. Ever since V4.0 there has been a diskquota leakage problem which requires a ANALYZE/DISK/REPAIR or REBUILD in DISKQUOTA. Any word on fixes? ================================================================ Note 25.1 diskquota bugs fixed? 1 of 2 "" 5 lines 10-DEC-1987 14:15 ---------------------------------------------------------------- Working on it. Sorry for the inconvenience. Keith Walls - file system project leader. ================================================================ Note 27.0 CONVERT has interesting bug (v4.6) No replies "" 24 lines 10-DEC-1987 15:40 ---------------------------------------------------------------- I came across an interesting CONVERT bug last week. Has anyone heard this one before? If you do a CONVERT/FAST/CREATE to merge two (in my case) sequential files into an ISAM file with multiple keys and variable length records. VAX-78 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS File A has short records (too short to include the secondary key) File B has long records (they all include the secondary key) CONVERT aborts when it tries to build the secondary index, claiming that there are duplicate keys. There aren't, except in the sense that the records from File A aren't long enough. It works if you do it with CONVERT/NOFAST, but that isn't practical in my case (I gave up on the full file after 2 hours). I found one work around, but it took awhile: $ CONVERT/FAST/CREATE B ISAM $ CONVERT/MERGE A ISAM Bob Graham Dow Chemical VAX-79 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS Performance Anaheim VAXnotes Excerpts - VMS Performance NOTE Any authorship indicated in these entries is considerably less certain than other Pageswapper material. Attribution to any individual should be taken with a grain of salt. ================================================================ Note 1.0 Welcome! No replies "Anaheim VAX Notes Moderator(s)" 6 lines 6-DEC-1987 18:28 ---------------------------------------------------------------- Welcome to the VMS Performance conference. Feel free to discuss anything that is related to VMS Performance, including the performance products, relative power, and tuning questions. However, for detailed information on SPM and VPA see the respective conferences. Use DIRECTORY/CONFERENCE command to find conferences on other topics. If you have a question please send mail to the MODERATOR account. ================================================================ Note 5.0 how do you tune LAVC? 4 replies "John Osudar" 13 lines 8-DEC-1987 09:54 ---------------------------------------------------------------- We just installed a three-node LAVC a couple of months ago; we did this by adding two VS2000's to our existing 11/785. Since then, our 785's performance has gone from bad to atrocious. The LAVC "documentation", such as it is, provides no tuning information. I can't afford to experiment with a running, fully loaded production system to determine the effects of slight adjustments to MSCP or other SYSGEN/AUTOGEN parameters (although I've attempted to make educated guesses and adjusted some things, apparently with little or no effect.) My question is: does anybody out there have any better LAVC tuning information, whether gained from DEC or through experience? (Incidentally, we are running VMS V4.6/LAVC V1.2, so the "improvements" contained in that software are already present.) VAX-80 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS Performance ================================================================ Note 5.1 how do you tune LAVC? 1 of 4 "Frank J. Nagy, VAX Guru&Wizard" 20 lines 8-DEC-1987 10:27 -< LAVC performing quite well >- ---------------------------------------------------------------- We are running an LAVC with 2 *core* nodes (MicroVAX-IIs with 16 MB memory, each serves 2 RA81s, one *core* node is the boot member), 2 VAXstation-IIs with local RD53s and 13 MB and 4 color VS2000s with no disks and only 4 MB. The two heaviest used RA81s are the system disk and the primary user disk; these are served by separate core members to split the major disk serving load. Normal prime time load is for all the workstations to be active and an additional 8-12 people on each *core* member. Activities are classical software development system (editing, word processing, compiling, linking, debugging). My best guess from MONITOR data is that about 12% of each core member is being consumed (on interrupt stack and in kernel mode) serving the central file system to the remainder of the LAVC (including to the other core member). The upshot is that we have no visible performance penalty with the LAVC. I'll be discussing this more in a Thursday session, V163 at 1:45 in Marriott Grand Ballroom Salon F. ================================================================ Note 5.3 how do you tune LAVC? 3 of 4 "" 10 lines 8-DEC-1987 14:03 -< LAVC on 785 >- ---------------------------------------------------------------- | | | reply to note 5.0 by J OSUDAR on tuning LAVC <<< There are some interesting tuning points on LAVC. I seem to have heard in ROME (87 EURO DECUS) that a MICROVAX-II makes a better boot node than an 8350; and that for some of the Unibus machines, it was a good idea to dedicate the machine as a server; timesharing use not recommended. Not sure where the 785 falls in that recommendation, but you said it was already heavily loaded to begin with. Remember that the MSCP server requires a lot of CPU resource on the BOOT (server) node; that VAX-81 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS Performance is how the cluster is implemented. You can't tune away those kind of fundamental design factors. ================================================================ Note 5.4 how do you tune LAVC? 4 of 4 "John Osudar" 24 lines 8-DEC-1987 16:24 -< want information, not miracles >- ---------------------------------------------------------------- | You can't tune away those kind of fundamental design factors. Sure, that's an assumption -- but what I'd like to know is that the MSCP server (and other active LAVC software) is impacting my 785 boot node for legitimate reasons, not because things are mis-tuned. Furthermore, I'd like to be able to adjust things so that the relative "priority" of service is weighted toward the 785. (I've heard mention at several sessions already of future enhancements that will tune the boot node parameters -- e.g. new AUTOGEN feedback stuff -- but the tuning is always for the benefit of satellites, with the negative impact on the boot node. In my situation, the satellites are the LEAST important systems; they are workstations for me and another member of our systems staff, and use their spare cycles to run batch jobs -- the useful work happens on the boot node.) I certainly do NOT expect "miracles" -- I'd simply like to be able to make some informed decisions about how my LAVC is set up. The present LAVC documentation doesn't contain anywhere near enough information for me to understand the effects of the few parameters that can be adjusted. Saying "we have found that setting MSCP_FOOBAR to 998001 generally provides reasonable performance" is NOT enough... I want to know what will happen if I should set MSCP_FOOBAR to a higher (or lower) value; or, conversely, which way I should adjust MSCP_FOOBAR if I want a particular effect on the performance of my (boot node or) satellites. VAX-82 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS Performance ================================================================ Note 9.7 Possible MONITOR improvements. 7 of 17 "" 23 lines 9-DEC-1987 17:50 -< document data sampling interface >- ---------------------------------------------------------------- One feature I'd like to see would be a documented, callable interface to MONITOR, or more accurately the data collection routines it uses (SPISHR??). On each VAX in the cluster, I've got a detached monitor process collecting nearly everything every 5 minutes and logging it to a file. The files get closed at midnight and another program reads them and produces a pile of graphs that I give a quick look see in the morning. This works fine for finding some problems, but occasionally the 5 minute interval is way to long to catch some transient problem. What I'd like to be able to do write my one image which would also sample the data periodically, but be able to change the rate and data sampled when something "interesting" happens. Rather than clutter the MONITOR utility with a bunch of extra code, I rather just "roll my own". Note: this would also let me write my morning graphs directly instead of having to read the MONITOR files. Bob Graham Dow Chemical PO Box 400 Bldg 2503 Plaquemine LA 70765 ================================================================ Note 9.8 Possible MONITOR improvements. 8 of 17 "Jamie Hanrahan" 14 lines 10-DEC-1987 09:20 -< `rolling your own' has been discussed >- ---------------------------------------------------------------- | What I'd like to be able to do write my one image which would | also sample the data periodically, but be able to change the | rate and data sampled when something "interesting" happens... I presented a session here (Anaheim) two years ago on writing your own performance data collection tools (it was in the VAX session notes) and Bruce Ellis presented one this time on Wednesday (also in the session notes). Most of the stuff that MONITOR displays is pretty easy to find in the exec. Rather than using SPISHR I prefer to just grab the stuff myself. That way I'm not limited to what DEC chose to put in SPISHR, and I avoid its overhead (it goes without saying that a monitor VAX-83 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS Performance program should have as low an overhead as possible -- Heisenberg's principle, you know). ================================================================ Note 9.9 Possible MONITOR improvements. 9 of 17 "Jamie Hanrahan" 2 lines 10-DEC-1987 09:21 -< One more thing... >- ---------------------------------------------------------------- The code for the stuff Bruce talked about yesterday will be on the Symposium tape. VAX-84 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS V5 Anaheim VAXnotes Excerpts - VMS V5 NOTE Any authorship indicated in these entries is considerably less certain than other Pageswapper material. Attribution to any individual should be taken with a grain of salt. ================================================================ Note 3.0 How to deal with RETIRED qualifiers 9 replies "Jim Fischer / MIVAXLUG Chair" 15 lines 7-DEC-1987 16:26 ---------------------------------------------------------------- In two sessions today I heard references to 'retired' command qualifiers; where 'retired' is defined as 'still works but not documented'. This will cause problems in the future when we (the experienced system support staff) only remember old qualifier names but not their functionality. I agree that the 'retired' qualifiers can't just vaporize, but they should continue to be documented. At least in an appendix some where called 'Retired Qualifiers'. I'd even agree that this appendix not document the functionality, but point the reader towards the 'new' qualifiers. In this way qualifiers (or commands, etc.) can be retired, but not lost. ================================================================ Note 3.1 How to deal with RETIRED qualifiers 1 of 9 "" 3 lines 7-DEC-1987 16:53 -< Agreement >- ---------------------------------------------------------------- I agree, this goes for anything that is 'retired' from VMS including sys. services, RTL, etc. Another volume in the doc set never killed anyone 8-) VAX-85 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS V5 ================================================================ Note 3.2 How to deal with RETIRED qualifiers 2 of 9 "" 4 lines 8-DEC-1987 08:33 -< Try using VERB utility for old qualifiers >- ---------------------------------------------------------------- There is a great utility in the DECUS library called VERB that disassembles the DCL CLI table. With it, you can see the definition of all qualifiers that the DCL command language interpreter will pass to the image.... ================================================================ Note 3.3 How to deal with RETIRED qualifiers 3 of 9 "" 1 line 8-DEC-1987 10:24 -< yes but... >- ---------------------------------------------------------------- Re .2, that will tell you what they are but not what they do. ================================================================ Note 3.4 How to deal with RETIRED qualifiers 4 of 9 "Scott Bailey" 8 lines 9-DEC-1987 09:18 -< more paranoia >- ---------------------------------------------------------------- I'm worried about what happens when retired qualifiers finally die... If a qualifier is no longer documented, does that mean that down the road in V6 or whatever, DEC doesn't need to tell us that they've finally dropped it? How will we lazy bums with old .COM procedures or whatever remember to get rid of the old stuff? (Yeah, I recognize we should change them NOW, but...) VAX-86 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS V5 ================================================================ Note 3.5 How to deal with RETIRED qualifiers 5 of 9 "Jack Patteeuw, Ford Motor Co." 4 lines 9-DEC-1987 14:06 -< Going away ... eventually ! >- ---------------------------------------------------------------- DEC's stated policy when V4.0 came out was that "retired" system service would go away in the next "major release" (ie. the "unmentionable" one !) I would assume the same for retired qualifiers. ================================================================ Note 3.6 How to deal with RETIRED qualifiers 6 of 9 "" 5 lines 10-DEC-1987 11:05 -< An obsolete services manual is planned >- ---------------------------------------------------------------- Digital is planning to distribute an "Obsolete Services" manual with the next major release of VMS that will document these "retired" system services, DCL commands, and command qualifiers. -comment from a VMS developer ... ================================================================ Note 3.7 How to deal with RETIRED qualifiers 7 of 9 "" 5 lines 10-DEC-1987 11:28 -< good idea >- ---------------------------------------------------------------- A nifty idea. Kudos to the person who thought that one up. David L. Bolthouse Texas Instruments (occasional maintainer of somewhat obsolete code) VAX-87 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS V5 ================================================================ Note 5.0 back to the futures 50 replies "John Osudar" 22 lines 8-DEC-1987 16:33 ---------------------------------------------------------------- Just got out of the "DCL futures" session... as usual, it appears that we're getting features that few, if any, of us asked for, but not those that have been requested over and over again. The case in point is MAIL, and in particular, Return Receipts. OK, they added (will add? may add, in a future unmentionable release??? whatever...) /CC to MAIL. Terrific... They "have no plans" to work on Return Receipts. The number of people who want Return Receipt capability seem to outnumber those who actively do NOT want this feature by at least a hundred to one -- and if DEC did it right, they'd make it an optional feature (as they did with /CC) so that those who don't want it can disable it in their own profile, thus removing most of the remaining objections. So why can't we have it? Is it technically impossible (and if so, why -- when many other mail systems provide such a feature)? Is it a marketing decision (if so, it's a bad one -- we WILL NOT spend money on a product to do this, simply because the money we'd have to spend would buy us fifty other features we do NOT need, at a cost that's too high for the feature we want)??? I know all about "callable MAIL", and it's a nice idea -- but you shouldn't rely on callable interfaces and site-specific implementations to supply fundamental features. Any comments, DEC or otherwise? ================================================================ Note 5.1 back to the futures 1 of 50 "" 13 lines 8-DEC-1987 16:53 -< my thoughts >- ---------------------------------------------------------------- As the one of those opposed to return-receipt-requested, and having had several conversations with DEC reps on this over the past years, allow me to comment. If it is optional at the RECEIVERs end I have no objection to Return Receipt Requests. If not (and this is where I recall digital has a philosophical (not marketing) problem), we are getting closer to BIG BROTHER versus winston smith ("1984"). VAX-88 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS V5 For all of you that argue, well All-in-1 has it so why not VMS mail, it's true that A1 does support Return Receipt Requests, but the RECIPIENT can turn it off in his/her profile. If Digital does offer MAIL with Return Receipt Requests and does not implement as above, I will remove mail from my system. ================================================================ Note 5.5 back to the futures 5 of 50 "Keith Chadwick, Fermilab" 10 lines 8-DEC-1987 17:08 -< What about forwarding ? >- ---------------------------------------------------------------- Does anyone know if DEC plans to fix the feature (bug ?) that allows mail forwarding to distribution lists in a future unnamed major release of VMS ? Example: $ MAIL SET FORWARD="@LIST.DIS" -Keith Chadwick. ================================================================ Note 5.18 back to the futures 18 of 50 "" 15 lines 9-DEC-1987 12:57 ---------------------------------------------------------------- MAIL at DEC is heading toward compliance with the international X.400 standards. Return Receipts will be provided when mail is delivered to the user agent. This is just like what happens with postal mail Return Receipts. (If I pick up your mail for you, I sign the Return Receipt; the sender does not know when you read it.) Depending on the user agent chosen, this may happen when the person actually reads the mail or may happen as soon as mail is presented to the receiving mailbox. Thus whether a Return Receipts means "I read the mail" or "Your mail was delivered to my mailbox" will be under the control of the recipient (or the recipient's management). VAX-89 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS V5 /john ================================================================ Note 5.19 back to the futures 19 of 50 "" 18 lines 9-DEC-1987 12:59 ---------------------------------------------------------------- The "bug" which allows SET FORWARD to a distribution list has been fixed in a future release. It will not be possible to set forward to more than a single destination. The reason it was a bug is that it did not work properly with the mail protocol, and could not possibly be made to work. A sending program would think it was sending to a single recipient, and would thus only wait for a single response. The receiving program could not properly handle the dilemma of whether to send a single response indicating success (if at least one of the recipients did successfully receive the mail) or a single response indicating failure (if at least one of the recipients did not successfully receive the mail). The receiving program did the wrong thing -- it tried to return multiple responses where only one was expected, causing future protocol errors. /john ================================================================ Note 5.30 back to the futures 30 of 50 "Ken Brucker" 12 lines 10-DEC-1987 09:38 -< a vote for Return Receipt Requests >- ---------------------------------------------------------------- I'm a DEC system manager in a DEC-IBM shop and we have a lot of mail traffic going between the two systems. Even the simplistic IBM facility called 'NOTE' (which is a less versatile mail implementation) has Return Receipt Requests as a feature. I get frequent requests and comments about the VAX's lack of a Return Receipt Requests feature from the IBM user community when they do not receive notification to their mail messages. I am most definitely for an implementation of Return Receipt Requests, even if the end user had the option to turn it off or the site could turn it off for everyone. VAX-90 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS V5 ================================================================ Note 5.34 back to the futures 34 of 50 "" 10 lines 10-DEC-1987 10:39 -< Don't disable multi-forwarding! >- ---------------------------------------------------------------- We use this "bug"/feature on our SYSTEM account. We have SYSTEM's mail set to forward automatically to our 3 system managers to allow them to respond in a more timely fashion to user requests sent to SYSTEM. It always seems to forward properly to all 3 accounts. I'd like to see that part of the functionality remain intact! Kurt Wampler GE/Intersil ================================================================ Note 5.36 back to the futures 36 of 50 "" 8 lines 10-DEC-1987 11:04 ---------------------------------------------------------------- | We have SYSTEM's mail set to forward automatically to our 3 | system managers to allow them to respond in a more timely | fashion to user requests sent to SYSTEM. It always seems to | forward properly to all 3 accounts. This won't work in a network environment, especially if the name which has been forwarded to multiple destinations is in a distribution list. Although all three of the forwarded users may get the mail, others won't. ================================================================ Note 5.44 back to the futures 44 of 50 "R. Michael Dupont" 9 lines 10-DEC-1987 12:54 -< KEEP THAT MULTI-FORWARDING! >- ---------------------------------------------------------------- We also use the multi-forwarding from multiple systems across the network to enable us to track system/network problems. It would not be of any benefit to remove this. Michael Dupont EDS 2925 West Minnesota Indianapolis, IN 46241 317/230-3771 VAX-91 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS V5 ================================================================ Note 9.0 V??? SYSMAN UTILITY 9 replies "" 6 lines 9-DEC-1987 16:28 ---------------------------------------------------------------- The SYSMAN utility described in the DCL update session looks great. As I understood the slides, the implication was that if you have OPER privilege, you could run the program. Once running the program, you could grant your self other privileges. Does this seem right??????????? ================================================================ Note 9.2 V??? SYSMAN UTILITY 2 of 9 "" 4 lines 9-DEC-1987 17:13 -< RE: SYSMAN >- ---------------------------------------------------------------- The impression I got was you need oper to run the Utility, you need additional privileges to do anything that may require an additional privilege (I.E. CMKRNL to do SYSGEN WRITE ACTIVE). - Awp ================================================================ Note 9.3 V??? SYSMAN UTILITY 3 of 9 "John Osudar" 5 lines 9-DEC-1987 17:23 -< right >- ---------------------------------------------------------------- Right. You need OPER just to get into SYSMAN. Then you can specify a "profile" containing other privileges -- but, those must be authorized on the local node (if the local node is in the "environment", or authorized for the username in use on non-local nodes. So this does NOT turn OPER into SETPRV! VAX-92 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS V5 ================================================================ Note 10.0 SLOW AND NOT-SO-EASY 4 replies "Steve Graham - Associated Press" 32 lines 10-DEC-1987 10:35 ---------------------------------------------------------------- Speed Problems ... now that DEC is in the fast lane with terminal servers going to 19.2 kbs, the lowly 50 bps for Baudot has gotten lost somewhere. Somehow DEC has forgotten that the world at large still deals largely with 50 and 75 bps circuits and the BAUDOT character set. (Just try to get even a 75 bps circuit from the U.K. to Katmandu). When you try to set a DHV device with SET TERMINAL /SPEED, VMS (4.6) goes off and comes back with nothing. That is to say the port speed hasn't changed, but it didn't tell you that it wasn't working. (there is no error associated with trying to set a speed that isn't recognized in VMS) Anyway, we got a patch for 4.6 so we can deal with telegraph-type lines, but hate to think that every time there is an update, we have to supplicate for a patch to fix what is supposed to be working. DEC also is quick to say they don't support the patch on top of all of that. Removing 50 bps as a standard speed isn't the right answer either. Please Mr. Olsen, can you please prove that DEC HAS IT NOW instead of DEC HAD IT THEN and take care of the world at large. merci, danke and gracias VAX-93 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS V5 ================================================================ Note 10.2 SLOW AND NOT-SO-EASY 2 of 4 "Forrest A. Kenney VMS Development" 36 lines 10-DEC-1987 15:34 -< Some explanation from the developer >- ---------------------------------------------------------------- You are seeing two distinct restrictions here. | | When you try to set a DHV device with SET TERMINAL /SPEED, VMS | (4.6) goes off and comes back with nothing. That is to say the | port speed hasn't changed, but it didn't tell you that it wasn't | working. Certain terminal controllers because of hardware restrictions force their port drivers to prohibit certain baud rates. This is true for the following controllers: DHV/U-11 DMB32 This does not mean that the controllers cannot support 50 baud just that using 50 baud potentially has undesirable effects on adjacent lines. For more details on this see the hardware manual for these controllers. | (there is no error associated with trying to set a speed that | isn't recognized in VMS) The second problem is a deficiency in the terminal port class architecture. Specifically no mechanism was provided to allow the port to signal that it cannot perform an operation. Compounding this problem is the inability to back out the already committed modifications to the parameters. The lack of error reporting was an oversight when the interface was designed. At that time nobody expected that controllers would exists that did not do what is asked of them. The part of the problem is potentially correctable. The second part of the problem is more complex and will have to be looked into. VAX-94 PAGESWAPPER - February 1988 - Volume 9 Number 7 Anaheim VAXnotes Excerpts - VMS V5 Forrest Kenney VMS Development TTDRIVER ================================================================ Note 10.4 SLOW AND NOT-SO-EASY 4 of 4 "" 30 lines 11-DEC-1987 11:30 -< my $0.02 >- ---------------------------------------------------------------- Having been involved with the original problem I would like to add a few points. | | DHV/U-11 | | DMB32 | | This does not mean that the controllers cannot support 50 baud | just | | that using 50 baud potentially has undesirable effects on | adjacent | | lines. For more details on this see the hardware manual for | these | | controllers. There are two problems here -- bad documentation and unqualified sales force. In this particular instance the DHV was sold to us by DEC as a solution to our problem. After all the sales literature states that the device will support 50 BPS -- you don't get the tech manual until after you buy the unit, and if it is under contract to DEC field service just takes it away with them and you have to beg to get it back. Even when you do get to look at the manual (after parting with your money) it is not at all clear that a problem with speed setting exists from looking at the funny little table they give you. In any case, as noted above, the problem is a deficiency in the VMS driver architecture but I could not find any note of this in the VMS I/O user's manual. After having DEC sell us a solution to a specific problem and then, after taking your money, telling us that it won't work, we are feeling just a little bit ripped off! That's why we are going with Simpact boards for serial communications from now on. VAX-95 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT INPUT/OUTPUT A SIG Information Interchange Mail written I/O submissions (no special form required) to: Larry Kilgallen, PAGESWAPPER Editor Box 81, MIT Station Cambridge, MA 02139-0901 USA To register for on-line submission to the Pageswapper dial: (617) 262-6830 (in the United States) using a 1200 baud modem and log in with the username PAGESWAPPER. ================================================================ Note 585.27 Anyone use defrag programs? 27 of 27 "John Burnet" 29 lines 21-DEC-1987 16:56 -< *WARNING* -- Rabbit-7 and BACKUP do *NOT* mix! >- ---------------------------------------------------------------- The following item was posted by Frank Nagy in a DECUServe conference. I hope he doesn't mind my replicating it here. WARNING - to all users of defragmenter programs... This week our main VAXcluster went down for nearly 4 days due to the scrozzing (Digital technical term from Fall '87 symposium :-) of the main user file store, a 16 RA81 volume set. What seems to have happened is that Rabbit-7 was run at the same time as an incremental BACKUP. Rabbit-7 had been in use for a while with no ill effects, but the system manager had enough paranoia to not run both Rabbit-7 and BACKUP at the same time. The system manager was away this week and new staff was in place... My best guess as to what happened is that the incremental BACKUP done with /FAST was remembering the file headers until the /RECORD pass. Now, BACKUP seems to have enough smarts to avoid writing a file header backup out during /RECORD if the file is deleted (for instance) - a change which will modify the file VAX-96 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT sequence number or otherwise mark the file header as invalid. BACKUP does *not* assume (it's probably safe to say) that someone might be mucking with the map area behind its back. I'd guess that this is precisely what is going on, that Rabbit-7 is changing just the map area (which is how ODS-2 tells what disk blocks belong to that file) and then BACKUP comes along and writes its saved file header with the old map information all over it! The problem was first noticed when several users complained that MAIL was failing due to garbaged mail files. John Burnet P. O. Box 1838 Evanston, IL 60204 (312) 272-6520 x2118 ================================================================ Note 663.44 Comments on the SPR process 44 of 46 "Bill Mayhew" 31 lines 10-DEC-1987 18:27 -< Yet Another SPR War Story >- ---------------------------------------------------------------- On September 21, 1987 I submitted an SPR on VAX C via DSIN. Since I hadn't heard anything, I called on Friday, December 4 to get a status report on the SPR. Since my system is supported out of Atlanta, the information was not readily available to the people at the SPR Administration office in Maynard. I was told it would take some research. On Monday, December 7, the information was ultimately found through a rather cumbersome process involving the use of, apparently, three separate systems in the SPR Administration office. The first one was necessary to convert the DSIN "sequence number" to a corporate SPR number (my DSIN submission had never resulted in a DSIN mail message with the corporate SPR number, which it's supposed to). The second one involved cross-checking that number to be sure it was the right SPR (i.e. was from my company); and the third, to actually determine its status. VAX-97 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT I didn't get much of an answer, except that the problem had been forwarded to Engineering on October 26th. Naturally, I asked about what had happened between September 21 and October 26. Evidently, a DSIN SPR is forwarded to the SPR people in Maynard, and is then forwarded to the appropriate Customer Support Center, and then (potentially) on to Engineering. In this case, for some reason, the first step took a full four weeks -- the SPR was not received by the folks in Maynard until October 19. The Customer Support Center got it (back?) on the 22nd; it was forwarded to Engineering, as noted, on October 26th. So far, essentially four days since that conversation with SPR Administration, no additional information on the status of the SPR has been forthcoming, so what's happened since October 26th is a mystery. Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 ================================================================ Note 663.45 Comments on the SPR process 45 of 46 "Dale E. Coy (505) 667-3270" 18 lines 12-DEC-1987 22:16 -< More grist - but where's the mill? >- ---------------------------------------------------------------- Had an interesting conversation at DECUS with a DEC manager who "ought to know" what the facts are. In the midst of this conversation, he stated that (1) it is the job of the support person at Atlanta or Co. Springs to submit SPRs if the problem (bug) can't be fixed; (2) SPRs from the support specialists get MORE attention than those direct from customers; (3) Since SPRs can be submitted by "anybody", engineering sometimes views customer-submitted SPRs as coming mostly from customers WITHOUT software support contracts. He seemed most surprised by my comments that the support people are reluctant to submit SPRs and have REPEATEDLY told me that customer-submitted SPRs get more attention. VAX-98 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT It belatedly occurs to me that a DECUS presentation on the SPR process might be nice. Wonder what SIG would sponsor it? DALE E. COY LOS ALAMOS NATIONAL LAB PO BOX 1663, MS J957 LOS ALAMOS, NM 87545 505-667-3270 ================================================================ Note 704.8 Digi-Data Gigastore System 8 of 13 "John Osudar" 17 lines 28-NOV-1987 15:30 -< Just got our Gigastore... >- ---------------------------------------------------------------- We just got our Gigastore this week. It took about six weeks or so from order to delivery -- not bad. So far all we've done with it is to install it (no problems) and run some tests. I backed up a 90% full RP07 on our 11/785 system two different ways -- the way DigiData recommends (/NOCRC/GROUP=0) took about 70 to 80 minutes (I missed the exact time it terminated), and wrote 13572 32K-byte blocks, for an effective rate of between 93K and 106K per second, somewhat below the maximum 120K. Doing it with the default CRC and GROUP qualifiers took 112 minutes and wrote 14941 blocks, for an effective rate of just under 73K bytes per second. Not great, but it means that we can fit three almost-full RA81-size disks, or two RA82-size disks, onto a single tape, which is good enough for us. I am now working on procedures for automating image removal and reinstallation, volume dismount/remount, etc. so that I can set up a procedure to back up our user disks overnight. I'll post further experiences with the Gigastore as they develop. John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 VAX-99 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT ================================================================ Note 704.9 Digi-Data Gigastore System 9 of 13 "David Shepperd" 10 lines 30-NOV-1987 21:56 -< 1+1=1.5 >- ---------------------------------------------------------------- Arithmetic has never been my best subject. After having run several tapes through the system, I note that we get roughly 1.5Gb per tape. The engineers at Digi-data say, "Well gee, that's what we get on our 780, so it must be working right." Its still a whole lot better than 15 separate 2400' 9 tracks. I wrote a program to just issue QIO's to the unit for several hours and it does run at 120kb/sec with roughly 1% CPU load. BACKUP on a microvax will not get it going much faster than about 75kb/sec even if it is backing up a single 250k contiguous file. Anybody have "fast" streamers that work well with VMS BACKUP? David Shepperd Atari Games Inc 675 Sycamore PO BOX 361110 Milpitas, Ca 95035-1110 (408) 434-1711 ================================================================ Note 704.10 Digi-Data Gigastore System 10 of 13 "gerson cohen" 14 lines 2-DEC-1987 08:29 -< better throughput through better qualifiers! >- ---------------------------------------------------------------- I have had some long discussions with the technical people at Digidata regarding the transfer rates and capacity of the Gigastore device. The device is a "true streamer" which is said to keep moving for as much as 10 to 12 sec after last data is received. IT DOES NOT BACKSPACE. Therefore if the computer driving it is slow or busy, the effective transfer rate will drop along with the ultimate amount actually stored. To get around this problem it was emphasized that one must be prepared to use as large a buffer count as possible (5), noCRC (the hardware is claimed to duplicate this function and the MicroVAX calculates this slowly, and no redundancy blocks (GROUP=0). Under these circumstances, the unit is said to run within 10% of its rated capacity and the actual transfer rate will approach the real transfer rate. Now I only wish I had one to try this VAX-100 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT all. Even at only 1.5 Gb it's great! gerson cohen nih bldg 2 rm 312 bethesda md 20205 301-496-4295 ================================================================ Note 704.11 Digi-Data Gigastore System 11 of 13 "Mark Schell" 8 lines 2-DEC-1987 23:09 -< My life depends on... >- ---------------------------------------------------------------- Not to bring up an old subject, but I'd NEVER write any backup tape that my business depended on with qualifiers /NOCRC/GROUP=0! I don't care if the tape is guaranteed to have NO errors! There are still too many links to fail between the data on my disk and that tape. And then, of course, there's always the problem of the quality of the video tape! Mark Mark Schell DIGITAL EQUIPMENT CORPORATION 8025 NORTH POINT BLVD SUITE 100 WEST WINSTON SALEM NC 27106 ================================================================ Note 704.12 Digi-Data Gigastore System 12 of 13 "Alan B. Hunt" 1 line 4-DEC-1987 19:34 -< ME TOO! >- ---------------------------------------------------------------- I agree with the last comment. Been bit before! ALAN B. HUNT 26803 BERG RD. #301 SOUTHFIELD, MI 48034 VAX-101 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT ================================================================ Note 704.13 Digi-Data Gigastore System 13 of 13 "gerson cohen" 7 lines 7-DEC-1987 08:41 -< No offense intended >- ---------------------------------------------------------------- OK! I didn't say one had to use /NOCRC and /NOGROUP. But when we analyse the performance of an I/O device, it is necessary to count ALL data, whether ours or system generated, when determining the actual transfer rates. We also must acknowledge that the Gigastore can write somewhat faster than BACKUP on a MicroVAX can feed it, and that contributes to the apparent lost of throughput and capacity on the tape. gerson cohen nih bldg 2 rm 312 bethesda md 20205 301-496-4295 ================================================================ Note 749.16 VMS 4.6 - where are you? 16 of 18 "john a goulet" 3 lines 26-NOV-1987 19:57 -< no 4.6 yet!! >- ---------------------------------------------------------------- we don't have it yet and its now thanksgiving!!! Have you gotten it yet?? We are near the Augusta, Me plant and they are running 5.0 on some machines in the plant, so where the hell is 4.6??? john a goulet thomas college west river road waterville me 04901 207 873 0771 VAX-102 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT ================================================================ Note 749.17 VMS 4.6 - where are you? 17 of 18 "Larry Kilgallen" 11 lines 27-NOV-1987 09:57 -< Everyone should have V4.6 by now >- ---------------------------------------------------------------- If you do not have VMS V4.6 and all the accoutrements to which your software services contract entitles you (e.g., some sites order microfiche and extra documentation sets), it is time to complain loudly to your local office. The same goes for MicroVMS V4.6. This above statement does not imply any suggestion that you should *install* V4.6 at any particular point in time. That is a judgement only you can make based on reports you hear from various DECUS sources and based on your own personal desire for adventure. Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 749.18 VMS 4.6 - where are you? 18 of 18 "Joe Sewell" 3 lines 9-DEC-1987 10:37 -< Not everybody, unfortunately >- ---------------------------------------------------------------- Only those of us whose DEC salespeople saw fit to include software maintenance in the quote should have V4.6. (Guess who got stuck without one of those blessed little contracts?) Joe Sewell Level Five Research 503 Fifth Avenue Indialantic, FL 32903 (305)729-9046 VAX-103 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT ================================================================ Note 769.8 Directory file internal structure 8 of 10 "Brian Tillman, Smiths Industries." 9 lines 4-DEC-1987 09:40 -< The conclusion to the story >- ---------------------------------------------------------------- Well, we have definitively found that directories whose "Used" sizes exceed 128 blocks are grossly slower that smaller directories. Large directories can take 2.5 times more CPU time and 1000 (yes, one thousand!) times more buffered I/Os to just execute the DIRECTORY command. The reason is probably because RMS's longest I/O is 64K (128 blocks) and it could also be a cache size as mentioned in .6. Thanks for all your help. Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 ================================================================ Note 769.9 Directory file internal structure 9 of 10 "Larry Kilgallen" 0 lines 4-DEC-1987 14:03 -< Was that *buffered* I/O's? >- ---------------------------------------------------------------- Larry Kilgallen Box 81, MIT Station Cambridge, MA 02139-0901 VAX-104 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT ================================================================ Note 769.10 Directory file internal structure 10 of 10 "Brian Tillman, Smiths Industries." 0 lines 7-DEC-1987 12:23 -< Yes, Buffered I/Os >- ---------------------------------------------------------------- Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 ================================================================ Note 803.1 Central Monitoring of Machines 1 of 3 "John D. Ferriby" 14 lines 10-DEC-1987 00:28 -< ETHERnim and NMCC implemented >- ---------------------------------------------------------------- | We have plans to evaluate DEC's Ethernim and its DECnet | monitoring tool. Some observations -- We are currently using both ETHERnim and NMCC (versions 1.0 and 1.1 respectively) -- both can and willingly consume copious amounts of your system resources, especially NMCC. Be prepared for high processor overhead with ETHERnim, as well as an uncomfortable token-style user interface. As for NMCC, what information you desire to collect and how frequently you want to collect it determines the CPU/IO/Disk space overhead. We have been collecting information at 3 hour intervals over 4 weeks and have consumed approximately 600K+ blocks. [70 nodes] John D. Ferribyþò û 2871 Troy Centry û#2010 Troy, MI 48084 (313) 362-2595 VAX-105 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT ================================================================ Note 803.2 Central Monitoring of Machines 2 of 3 "Chris Erskine" 63 lines 10-DEC-1987 08:16 -< Personal views >- ---------------------------------------------------------------- What I have seen of DEC's network monitoring and management systems is that they all have far to go. Each system is a standalone system which does not talk to the others. This includes such thing as locations to put location of device, manager ... in the data base. If you get all of the systems, you end up with at least 3 databases containing the manager's name for something like a terminal server. Now have the manager change and look at all of the places you have to update to the new name. My general feelings for the different items are as follows. ETHERnim - Will find general addresses and names for some items. Ethernet only. For terminal servers, you have to trace the address back to the node name in lots of places. Does not use all of the information available from the datapackets which it looks at which would help the system. Really gets confusing for VAXmates where DECnet addresses are changing for the same hardware addresses. Must leave the system up at a tube to learn the database. The new version has additional graphics and ability to layout the database but again does not work with the moving DECnet addresses of VAXmates. After all of the work putting the network into graphics, there is not an easy way to get a hard copy of it. Will report all non multicast addresses found on the Ethernet cable but does not help trace or identify non DEC devices or what they may be running. TSM - Needed to manage the DECserver family of servers but has the local data problem of manager's name .... Could use some features to tell it that there is a replacement server being added. Would be nice to have a command to create a command file from the server's database to allow tracking of changes when I have to test a configuration to get it working. RBMS - Same comment on local info. Would help allow it to determine it's network and map out the cable plant. VAX-106 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT LTM - Uses a bridge to monitor the traffic. This device has been the best DEC product for tracking and finding devices in the network. Will provide performance of the network and type of traffic on the network. NMCC/DECnet Monitor - Same graphics problem as ETHERnim for output. As John said, uses lots of disk. Expensive when you consider the layered products also required to run it. I have not had a chance to look at the new version as much as John, but it seems to still have some of the confusing conventions for describing the systems etc. After working with NCP, NMCC requires you to change your thinking of the different entities. Overall, these products are new and still have a ways to go. There are still a lot of work needed to bring them all together and make the consistent in operation and information. DEC used the first releases just to get something to the customer and is still working on defining the management systems. Expect to see all of these change over time and either start talking to each other or to be replaced with a single system which will. Chris Erskine 23 S Holcomb Clarkston, MI 48016 (313) 524-8836 ================================================================ Note 803.3 Central Monitoring of Machines 3 of 3 "Larry Kilgallen" 12 lines 12-DEC-1987 23:08 -< Beware of Products You Can't Call >- ---------------------------------------------------------------- A user at the Anaheim Symposium this past week (no names because I did not ask permission to quote) said that the various DEC network monitoring tools have NO PROGRAM INTERFACE. Considering that the VMS department at DEC claims to have a policy of trying to make all new programs callable, it seems this is another case of one branch of DEC has heard the message from the user community and others have not. The user at Anaheim has a network so large that custom programs to monitor the monitors are a requirement, and as of now, the DEC network monitoring tools do not provide any access for site-specific programs. Larry Kilgallen VAX-107 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT Box 81, MIT Station Cambridge, MA 02139-0901 ================================================================ Note 833.4 LAT problems 4 of 8 "Dale E. Coy (505) 667-3270" 7 lines 25-NOV-1987 00:03 -< LTDRIVER problems? >- ---------------------------------------------------------------- Is there some confirmation for Terry's comment about the LTDRIVER with 4.6? There is absolutely no information on this problem on DSIN, and nobody at local Field Service knows anything about it (surprise?). We have a LTDRIVER.PATCH (file date 15 July 86) - but is this the patch to apply? DALE E. COY LOS ALAMOS NATIONAL LAB PO BOX 1663, MS J957 LOS ALAMOS, NM 87545 505-667-3270 ================================================================ Note 833.5 LAT problems 5 of 8 "Terry Kennedy" 20 lines 26-NOV-1987 03:10 -< Info from local office... >- ---------------------------------------------------------------- | Is there some confirmation for Terry's comment about the | LTDRIVER with 4.6? All I can tell you is what I was told by my local Software Services people. I suppose that doing an analyze/image might point out which version is newer (by module ID, *not* link date). Your best bet in the absence of useful confirmation from anyone would be to rename the V4.6 LTDRIVER (as mentioned in .-n) and try the patch tape. If things get better, keep it. Otherwise, revert to the 4.6 driver. The whole lack of information from DEC on this is a big problem. I saw somewhere that V2.0 of the DS200 load image is in development, and that it may require a new LTDRIVER anyway. It seems that nobody 'owns' LTDRIVER in DEC - VMS says it terminal server products, TSP says it's VMS, etc. VAX-108 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT Terry Kennedy 95 Mohawk Trail Ringwood, N.J. 07456 (201) 435-1890 ================================================================ Note 833.6 LAT problems 6 of 8 "JIM PALMER" 22 lines 14-DEC-1987 20:23 -< DEC has a fix >- ---------------------------------------------------------------- There is an official fix in the form of a backup save_Set that contains a newly linked LTDRIVER.EXE and LATSYM.EXE. Also included is a text file describing the fixes. We obtained ours via DEC field service. The name of the save_set is lat046.bck. There is no FCO link that I know of. To identify the new images, the .IDENTS are: LTDRIVER.EXE .IDENT "LAT X7N-14" LATSYM.EXE .IDENT "LATSYM V2.1" We had a definite problem with DEC 100's being randomly X'offed for unknown reasons. So far so good with the new image, but I was able to put it up the day after DECUS (SAT) so we haven't much time to test. JIM PALMER 3 BROOKDALE IRVINE, CA. 92714-3338 (714) 458-3028 VAX-109 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT ================================================================ Note 833.7 LAT problems 7 of 8 "George Merriman CCA/NY" 13 lines 16-DEC-1987 23:26 -< another problem >- ---------------------------------------------------------------- I have been having a problem with LT application ports. It seems that when a port being used to drive a printer from a program that is NOT a symbiont or anything like that has no traffic for the port for a while (hours, maybe) the link to the port drops out, kind of. A SHOW TERM on the LT: port at DCL shows the owner of the device as the process running the program and a SHOW PORT command to LATCP shows an actual port out there. However, the terminal server shows the port as being disconnected. It also seems that QIO's to the port succeed, but nothing comes out the other end (not sure about this). I'm running VMS 4.6, but I'm not using the special LT port QIO functions to make the connections to the port. The program in question seemed to work OK under 4.5. The server is a 200 running BL20C software (or whatever the latest and greatest is). Any ideas? George Merriman Cambridge Computer Associates 56 Beaver Street 3rd Floor New York NY 10004 212-425-5830 ================================================================ Note 833.8 LAT problems 8 of 8 "Seton Droppers, PBS, (703)739-5100" 12 lines 23-DEC-1987 12:53 -< A couple thoughts >- ---------------------------------------------------------------- Two ideas: 1) Might you have the inactivity logout enabled on the port and that causes the DS200 to go away? 2) I had heard, from DEC, that at least one product's use of LAT ports broke going from 4.5 to 4.6, maybe the QIO interface is needed? VAX-110 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT Can anyone else confirm or deny either of these? Seton Seton R. Droppers Public Broadcasting Service 1320 Braddock Place Alexandria, VA 22314 (703)739-5100 ================================================================ Note 836.0 Anybody know of NETPATH? 2 replies "Ken Robinson" 8 lines 25-NOV-1987 10:02 ---------------------------------------------------------------- Does anyone know of a DECnet monitoring tool call NETPATH, which supposedly will tell you all the paths from node A to node B on DECnet. Ken Robinson Bell Communications Research 444 Hoes Lane, Room 4d449 Piscataway,N.J. 08854 (201)699-8796 ================================================================ Note 836.1 Anybody know of NETPATH? 1 of 2 "John K. Doyle, Jr." 11 lines 2-DEC-1987 18:30 -< Perhaps NETMAP instead? >- ---------------------------------------------------------------- I haven't seen NETPATH, but there used to be a nice utility called NETMAP. It was very smart. It went out and looked at all the neighboring nodes and then did the same thing over and over from each node's "perspective". It then draw a map of all the adjacencies (NOT physical links) for you. The only problem with it was that people liked it TOO much and ran it A LOT. Finally we had to restrict its use because several people would run it and create NML processes all over the network. I am not sure if it ever made it on to the SIG tapes. When I was working for DEC, distributions WERE available on the Engineering net. You might consider talking to your local SWS people about it. John K. Doyle, Jr. Steiner, Levi & Co. VAX-111 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT 2550 Mercantile Drive Suite C Rancho Cordova, CA 95670 (916) 638-2600 ================================================================ Note 836.2 Anybody know of NETPATH? 2 of 2 "Mark Schell" 7 lines 2-DEC-1987 22:57 -< You can have it! >- ---------------------------------------------------------------- NETPATH is a tool available from Digital that traces the "path" from one node to another. It used to be an internal use only tool, but is now available from your local Digital Software Services group under the "Network Assets Program". Mark Schell DIGITAL EQUIPMENT CORPORATION 8025 NORTH POINT BLVD SUITE 100 WEST WINSTON SALEM NC 27106 ================================================================ Note 837.0 SQL ??? 1 reply "MARK SHAFFER" 7 lines 25-NOV-1987 11:35 ---------------------------------------------------------------- I have been asked to inquire here about SQL. Anything you can tell me about it is fine. Does it have some connection with Rdb?... ... and so forth. Thanks, Mark MARK SHAFFER INFORMATION CONTROL TECHNOLOGIES,INC. 17 POLLY DRUMMOND PROF. BLDG. SUITE 105 NEWARK, DE 19711 302-366-8211 VAX-112 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT ================================================================ Note 837.1 SQL ??? 1 of 1 "Alan B. Hunt" 39 lines 25-NOV-1987 12:31 -< Where it came from! >- ---------------------------------------------------------------- SQL is an interface for developers/end-users to use to manipulate a relational database and it was created by IBM. Over the years it has become a defacto standard for query languages. There is now or soon will be an ANSI Standard for SQL which is different from the IBM version. Most of the database packages being developed today have a SQL interface and in some cases a proprietary interface as well. Obviously portability is the issue. In the case of Rdb it came out initially with RDO as its proprietary interface but no SQL interface. SQL then became a larger issue and DEC has now developed a SQL interface for Rdb for a "small" fee. It does not fully comply with the ANSI standard the plans are to do so with future releases. The actual interface to Rdb and other future Digital Relational products is DSRI (Digital Standard Relational Interface). RDO and SQL (as well as the programming interfaces) simply convert a user friendly style of request into calls to DSRI. DSRI is supported by DEC, you can by documentation for it, and it suppose to always be upward compatible. It may be expanded as future needs dictate. A diagram might show: +-----+ +-----+ +--------------------------+ | RDO | | SQL | | Custom Program Interface | +--+--+ +--+--+ +--------------------------+ | | | +-+-------+----+-+ | DSRI | +-------+--------+ | +-----+-----+ | Database | +-----------+ VAX-113 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT The Custom Program Interface can be your own or some third party or DEC package which interfaces to Rdb or any future DEC relational product. ALAN B. HUNT 26803 BERG RD. #301 SOUTHFIELD, MI 48034 ================================================================ Note 839.0 Getting to serial lines on the 8200 8 replies "G. Del Merritt" 8 lines 25-NOV-1987 16:03 ---------------------------------------------------------------- I have an 8200 with a DMZ32 (which I have filled). I am not using the three serial ports that are physically above the console (OPA0) port. How do I get to those? Do they provide modem control like the DMZ? I have looked through my owner's manual, and only have found reference to them in section 10, which talks about the KA820... I'd like to put my modems and LN03 on those ports, so that they don't get perturbed when others than myself play with the connections to the multiplexer! G. Del Merritt 55 Walkers Brook Drive Reading, MA 01867 ================================================================ Note 839.1 Getting to serial lines on the 8200 1 of 8 "G. Del Merritt" 4 lines 25-NOV-1987 16:09 ---------------------------------------------------------------- Forgot to mention that I think they're probably OPA1, OPA2, and OPA3. problem is that I want to make sure that there is nothing else "special" about them that would preclude my letting dialup users have access to them... G. Del Merritt 55 Walkers Brook Drive Reading, MA 01867 VAX-114 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT ================================================================ Note 839.2 Getting to serial lines on the 8200 2 of 8 "John Burnet" 22 lines 27-NOV-1987 10:56 -< Here's the scoop (or part of it, anyway) >- ---------------------------------------------------------------- To get to the 8200's three "serial line units" (SLUs), do this (and also put these commands in your SYSTARTUP.COM): $ mcr sysgen connect slu=1 connect slu=2 connect slu=3 exit The three lines are named TCA0:, TCB0:, and TCC0: (not OPA1/2/3). You should be aware of a couple of things. First, the maximum baud rate on these lines is 1200. Second, the lines use the same port driver ("OPERATOR") as OPA0, which means that all I/O is done character by character (no SILO or DMA), with an interrupt taken for each character received or transmitted. What this means to your system is that your interrupt-stack time will rise dramatically if you run any terminal-I/O-intensive applications on those lines: screen painting programs, Notes, spreadsheets, etc. I don't know whether the lines support modem control or not. Anyone else care to comment? John Burnet P. O. Box 1838 Evanston, IL 60204 (312) 272-6520 x2118 VAX-115 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT ================================================================ Note 839.3 Getting to serial lines on the 8200 3 of 8 "G. Del Merritt" 3 lines 30-NOV-1987 14:22 -< oh well... >- ---------------------------------------------------------------- Thanks. For what are these ports intended, since they be so slow? Alternate operator consoles? Output only lines for slow serial printers? Something else to cause questions? G. Del Merritt 55 Walkers Brook Drive Reading, MA 01867 ================================================================ Note 839.4 Getting to serial lines on the 8200 4 of 8 "Jack Patteeuw" 1 line 30-NOV-1987 17:04 ---------------------------------------------------------------- These ports DEFINITELY do NOT support modem controls ! Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 ================================================================ Note 840.0 Creating Subprocesses with Privilege No replies "Offline Submission" 83 lines 27-NOV-1987 21:14 ---------------------------------------------------------------- How does one use LIB$SPAWN to create a subprocess with privilege? I want to install an image that spawns a subprocess and have that subprocess inherit the same privileges that its parent is installed with. If I use a command file and turn on the required privilege within the command file it works just fine - but my command is only one DCL command (SHOW PROCESS/CONTINUOUS/ID=somePID) and I would rather not have to write the command file on the fly, invoke it, and then delete it. My reasons for this are mainly security related (another process could tamper with my temporary command file in the middle somewhere). VAX-116 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT I want to provide non-privileged users the ability to do a $SHOW PROCESS/CONTINUOUS/ID=whatever Here is a code sample ... I have installed this program with WORLD privilege but the child doesn't have it. PROGRAM SHPC_PRIV(INPUT,OUTPUT); TYPE $UWORD = [WORD]0..65535; VAR LIB_STAT: INTEGER; COMMAND: PACKED ARRAY [1..28]OF CHAR; ID, IOSB: UNSIGNED; PID: PACKED ARRAY[1..8] OF CHAR; LENGTHOF: $UWORD; [ASYNCHRONOUS,EXTERNAL]PROCEDURE LIB$STOP( %IMMED cond_value : INTEGER); EXTERN; FUNCTION LIB$GET_FOREIGN( VAR GET_STR: [CLASS_S] PACKED ARRAY [a..b:INTEGER] OF CHAR; USER_PROMPT: [CLASS_S] PACKED ARRAY [c..d:INTEGER] OF CHAR; VAR OUT_LEN: $UWORD := %IMMED 0; FORCE_PROMPT: INTEGER := %IMMED 0): INTEGER; EXTERN; [ASYNCHRONOUS,EXTERNAL]FUNCTION LIB$SPAWN( COMMAND_STRING: [CLASS_S]PACKED ARRAY [$L1..$U1:INTEGER] OF CHAR := %IMMED 0; INPUT_FILE: [CLASS_S]PACKED ARRAY [$L2..$U2:INTEGER] OF CHAR := %IMMED 0; OUTPUT_FILE:[CLASS_S]PACKED ARRAY [$L3..$U3:INTEGER] OF CHAR := %IMMED 0; FLAGS: UNSIGNED := %IMMED 0; PROCESS_NAME: [CLASS_S]PACKED ARRAY [$L5..$U5:INTEGER] OF CHAR := %IMMED 0; VAR PROCESS_ID: UNSIGNED; VAR COMPLETION_STATUS: UNSIGNED := %IMMED 0; COMPLETION_EFN: UNSIGNED := %IMMED 0; COMPLETION_ASTADR: UNSIGNED := %IMMED 0; COMPLETION_ASTARG: UNSIGNED := %IMMED 0; PROMPT: [CLASS_S]PACKED ARRAY[$L11..$U11:INTEGER] VAX-117 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT OF CHAR := %IMMED 0; CLI: [CLASS_S]PACKED ARRAY[$L12..$U12:INTEGER] OF CHAR := %IMMED 0 ): INTEGER; EXTERN; BEGIN (* PROGRAM SYS *) LIB_STAT := LIB$GET_FOREIGN(PID,'_Pid: ',lengthof); IF NOT ODD (LIB_STAT) THEN LIB$STOP(LIB_STAT); COMMAND := 'SHOW PROC/CONTIN/ID=' + PID; LIB_STAT := LIB$SPAWN(COMMAND_STRING := COMMAND, PROCESS_ID := ID, COMPLETION_STATUS := IOSB ); IF NOT ODD (LIB_STAT) THEN LIB$STOP(LIB_STAT); END. (* PROGRAM SYS *) Thomas B. Graves P.O.B. 131 Norton, Ma. 02766-0131 Telephone: (617)-285-4814 August 19, 1987 ================================================================ Note 845.0 Quote without (much) comment 7 replies "Dale E. Coy (505) 667-3270" 57 lines 2-DEC-1987 20:45 ---------------------------------------------------------------- In view of the ongoing discussion of SPRs, I thought the following might be of interest. This just appeared as a FLASH on DSIN (equivalent to the FLASH about installing the important patch). I never heard of an "administrative closure" before. --------------------------------------------------------------- Title: What Happens After You Submit an SPR Via DSIN VAX-118 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT Date: NOV 1987 Source: Digital Customer Support Center/Colorado Springs DSIN SPR PROCEDURAL CHANGE: Customers submitting SPRs through the DIGITAL Software Information Network (DSIN) will receive mail via DSIN informing them of their CORPORATE SPR NUMBER. This number is your official SPR NUMBER and should be used for all activities concerning that particular SPR (i.e., inquiries, additional information, etc.). This mail acknowledges that the information was received and noted by DIGITAL. After the mail has been sent, the SPR will be closed. Please note that this closure is an "administrative closure." A "technical closure" of your SPR will be delivered to you in the form of a "written response" or a "telephone response." COPIES OF DSIN SPR SUBMITTAL: An acknowledgment copy of your DSIN submitted SPR is not provided. If you need a copy, please submit your SPR using a hardcopy terminal. OBTAINING INFORMATION ABOUT THE STATUS OF YOUR SPR: For the most accurate information about the current status of your SPR, please call: SPR Administration (617) 493-4722 SPR Administration can reference your SPR by the sequence number you received when you entered the SPR (e.g., C870103112) or they can reference your SPR using the corporate SPR number (e.g.,MST-xxxx). SUBMITTING ADDITIONAL INFORMATION ABOUT AN SPR: If you wish to submit additional information about your SPR through DSIN, please do so by entering another SPR. Please be sure to reference the first SPR you entered by sequence number and by corporate SPR number. This will help to assure that the original submittal of the SPR and the additional information SPR are processed together. If the additional information is in listing form or on machine-readable media, you will need to send it to the following address: SPR Center Corporate Administrative Services Group P.O. Box F Maynard, MA 01754 VAX-119 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT Again, when sending additional information, please reference the SPR by its sequence number and by the corporate SPR number. DALE E. COY LOS ALAMOS NATIONAL LAB PO BOX 1663, MS J957 LOS ALAMOS, NM 87545 505-667-3270 ================================================================ Note 845.1 Quote without (much) comment 1 of 7 "Bob Hassinger" 17 lines 3-DEC-1987 11:14 -< Why would anyone submit an SPR via DSIN? >- ---------------------------------------------------------------- It is said that an SPR submittal via DSIN is a little faster than the paper submission to Box F. I am told the difference is that the people at Box F in Maynard turn your paper into electronic form and forward it by network to Colorado where it enters more-or-less the same system as SPRs submitted directly on DSIN. The delay for the Box F paper submission is supposed to be no more than a day or two, particularly because of the electronic transmission to CSC. Given this and the various tracking and administration problems that come with a DSIN submission that are evident in the information in the previous note, is there any real win to doing SPR submissions via DSIN instead of by paper to Box F? The day or two you save is a trivial part of the overall turn around time most of us see. Bob Hassinger Liberty Mutual Research Center 71 Frankland Road Hopkinton, MA 01748 617-435-9061 VAX-120 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT ================================================================ Note 845.2 Quote without (much) comment 2 of 7 "Bill Mayhew" 22 lines 3-DEC-1987 11:48 -< Hand-type SPRs? On a typewriter? Heavens forfend! >- ---------------------------------------------------------------- Unfortunately, the human interface for doing SPR submissions is pretty bad. Digital would do well to expend some resources in this area. The paper forms are a hassle to deal with, if only because one has to find a typewriter, and remember how to use it (!), to submit one. Those of us who long since weaned ourselves of such archaic machines, and/or who have yet to figure out how to correct a typo or rephrase a thought on a 7-part carbonized form, are out of luck. One reasonable solution to this would be for somebody to come up with some kind of program (using TPU, perhaps?) to allow you to create in-house SPRs on-line and print them on some nearby LQP or LA. (I'm not volunteering, I've gotten myself into enough holes, already, this month, and it's only the 3rd... {grin}) The electronic submissions are superior except that there's no way to get a local copy of what you submitted, unless you use SET HOST/LOG or, with Kermit, LOG SESSION..., which isn't _too_ bad. You do need to make the extra step, then, of transcribing the SPR number from Email to your local online or hardcopy, once the number is assigned. What I'd like to see DEC do in this area is to send a complete copy of the SPR submission, _with_ the SPR number, to the submitter's DSIN Email box, rather than sending the number itself. Bill Mayhew Village Systems Workshop Inc PO Box 642 Natick MA 01760 617-237-0238 VAX-121 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT ================================================================ Note 845.3 Quote without (much) comment 3 of 7 "Dale E. Coy (505) 667-3270" 19 lines 4-DEC-1987 00:00 -< What a dandy idea! >- ---------------------------------------------------------------- | One reasonable solution to this would be for somebody to come up | with some kind of program (using TPU, perhaps?) to allow you to | create in-house SPRs on-line and print them on some nearby LQP | or ... Say what you will (and you will), but our ALL-IN-1/WPS-PLUS software came with a built-in SPR template. | What I'd like to see DEC do in this area is to send a complete | copy of the SPR submission, _with_ the SPR number, to the | submitter's DSIN Email box, rather than sending the number | itself. AMEN! and then provide some decent capability (like Kermit or darned near anything) to allow copying stuff from DSIN to the local system. Did you ever try to capture anything from DSIN (like .0)? - I did it with VAXNet Log, but at least half the file is terminal escape codes and other stuff associated with their "scream" interface. DALE E. COY LOS ALAMOS NATIONAL LAB PO BOX 1663, MS J957 LOS ALAMOS, NM 87545 505-667-3270 ================================================================ Note 845.4 Quote without (much) comment 4 of 7 "Kevin Angley" 4 lines 4-DEC-1987 17:23 -< Electronic SPR's >- ---------------------------------------------------------------- Check out Jim Downward's KMSKIT on almost any VAX SIG DECUS tape. It has an SPR-generator. You just answer a few questions and print out the SPR. You do need to staple it to an SPR form though so it will have a DEC-supplied form number. Kevin Angley 3301 Terminal Drive VAX-122 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT Raleigh, NC 27604 (919) 890-1416 ================================================================ Note 845.5 Quote without (much) comment 5 of 7 "Bob Hassinger" 11 lines 7-DEC-1987 09:15 -< Right, we have been using the KMSKIT stuff for years... >- ---------------------------------------------------------------- | Check out Jim Downward's KMSKIT on almost any VAX SIG DECUS | tape. Right! I think I started using Jim's program around the time we moved from RSX to VMS over five years ago. I know for sure the RSX group had agreed to accept it back then and I know I have never had a VMS SPR done with it rejected so it would seem it is acceptable to the VMS group as well. Since those are two of the largest groups, I would guess use of it is acceptable to DEC in general. Bob Hassinger Liberty Mutual Research Center 71 Frankland Road Hopkinton, MA 01748 617-435-9061 ================================================================ Note 845.6 Quote without (much) comment 6 of 7 "Gregg A. Deuchar (408)432-1000" 14 lines 7-DEC-1987 20:03 -< Easy fix for DSIN problem >- ---------------------------------------------------------------- | AMEN! and then provide some decent capability (like Kermit or | darned near anything) to allow copying stuff from DSIN to the | local system. Did you ever try to capture anything from DSIN | (like .0)? - I did it with VAXNet Log, but at least half the | file is terminal escape codes and other stuff associated with | their "scream" interface. The easy way around this problem is to tell DSIN that you are a HARDCOPY terminal. Then all you get is the plain text without the "fancy" graphics. I do the same thing here with a $Set term/device=LA120 command to avoid getting a log file full of escape codes. Now if only ARIS let me set the terminal type... VAX-123 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT Gregg Deuchar P.O. Box 10124 San Jose, CA. 95157 (408) 432-1000 ================================================================ Note 845.7 Quote without (much) comment 7 of 7 "Dale E. Coy (505) 667-3270" 8 lines 9-DEC-1987 02:03 -< I can do that - why can't DEC? >- ---------------------------------------------------------------- Setting the terminal to hardcopy is a dandy idea, but has its own drawbacks, of course. The major point revealed by looking in detail at the escape codes is that often 50% of the transmission is "useless" codes (for example, 4 or 5 pure cursor-positioning commands in a row, followed by something useful like erase-to-eol). No wonder it seems slow some times. DALE E. COY LOS ALAMOS NATIONAL LAB PO BOX 1663, MS J957 LOS ALAMOS, NM 87545 505-667-3270 ================================================================ Note 848.0 Disk capacity 3 replies "MICHAEL GRATTAN" 13 lines 9-DEC-1987 06:51 ---------------------------------------------------------------- We have a MicroVAX II with a RD53 and a RA81. I use the RD53 as a system disk and my users are on the RA81. My RA81 is about 75% full. How full can I let this drive get? Is there some point at which I will see performance degrade due to an overfull disk? In the same vein, I'm trying to get my hands on a 2nd RA81. After it's installed, I want to do a backup and restore of the first drive. Is there a suggested method to accomplish this? VAX-124 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT I would appreciate any thoughts. (Anyone who replies gets one less lump of coal from you-know-who! ;-) ) MICHAEL GRATTAN FAIRHAVEN CORP. 358 BELLEVILLE AVE. NEW BEDFORD, MA. 02742 617-993-9981 EXT 106 ================================================================ Note 848.1 Disk capacity 1 of 3 "Chris Erskine" 16 lines 9-DEC-1987 08:50 -< How fragmented are they? >- ---------------------------------------------------------------- A lot of people say 75 to 80 is the limit. A lot of it is dependent on what is being done on the disk. If you are creating and deleting files all of the time, then you may be over the limit now. I the disk is mostly read without much write, then it is dependent on I/O usage. (Sometimes smaller, slower drives are faster than large fast drives.) A good way to tell is how fast does the disk fragment after compressing it. To compress the disk with a spare drive you can either backup to the second drive and switch address plugs on the drive or backup to the second drive and then back to the first drive. Note that if you switch LAP plugs often, then for tracking of disk problems, you might want to label the drives where they are not related to the address of them. Chris Erskine 23 S Holcomb Clarkston, MI 48016 (313) 524-8836 VAX-125 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT ================================================================ Note 848.2 Disk capacity 2 of 3 "Rytis T. Balciunas" 13 lines 10-DEC-1987 07:08 -< My two cents.. >- ---------------------------------------------------------------- I agree with the 75-80% rule. Our DEC field service person recommended no more than 70%! In any event, your system won't crash if the RA81 gets to these limits...One of our business system's RA81 data disks (has about 300 VERY large files) has been sitting at about 76% for a few months (no time to purge out old data) and I've not noticed major problems due to the amount of space used. This disk gets a great deal of write-activity, with read/write ratio being about 40/60. My problems lie in the lousy design of the data files (business software vendor's ideas, not mine)....I have had disks go to 99% for hours with few MAJOR ills (other than programs going away when they hit 100%!)... RYTIS T. BALCIUNAS CALGON CARBON CORPORATION PO BOX 717 PITTSBURGH PA 15230-0717 (412)787-6784 ================================================================ Note 848.3 Disk capacity 3 of 3 "Jonathan M. Prigot" 11 lines 10-DEC-1987 10:20 -< $.02+$.02=$.04 >- ---------------------------------------------------------------- I think the operant phrase is "...point at which I will see performance degrade due to an overfull disk." Performance on the disk started to degrade when you started using the disk! Every time you use a disk block, the system must keep track of where the unused blocks are. As the disk fills up, the system must devote more of its time to storage allocation. (Of course since VMS caches much of that information, the task isn't as noticeable as with some operating systems.) How much of that time is acceptable is a subjective judgement. On our system, I start noticing a slowdown at about 85-90% of capacity. Jonathan M. Prigot W.R. Grace & Company 55 Hayden Avenue VAX-126 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT Lexington, MA 02173 617-861-6600 x2148 ================================================================ Note 850.0 VAX 11/750 As a Satellite LAVC Member 1 reply "Offline Submission" 16 lines 13-DEC-1987 20:48 ---------------------------------------------------------------- Digital's official line is that a VAX 11/7XX cannot boot across the Ethernet and so a VAX 11/7XX must be the boot member in an LAVC. However, I have heard rumors that you can boot a VAX 11/7XX over the Ethernet by hand via the console subsystem. Does anyone know which console commands you would use for a VAX 11/750? Per Hvid Storno Midtager 2O 2605 Broendby Denmark Telephone: 2455544 Date: October 12, 1987 ================================================================ Note 850.1 VAX 11/750 As a Satellite LAVC Member 1 of 1 "JIM PALMER" 13 lines 15-DEC-1987 20:08 -< DEC can do it! >- ---------------------------------------------------------------- We have been wondering about that very same issue. (See notes 741.* and 569.*) Last week I was able to pose the question to one the VMS developers at the Anaheim DECUS. He says that not only is it possible but they do it internally at DEC all the time!. However the bootstrap mechanism was not his area of expertise and could not pass on the actual mechanics of such. JIM PALMER 3 BROOKDALE IRVINE, CA. 92714-3338 (714) 458-3028 VAX-127 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT ================================================================ Note 852.0 How to obtain a LAT port name/number 1 reply "Jack Patteeuw" 16 lines 15-DEC-1987 08:36 ---------------------------------------------------------------- From the SYSTEM account on the DECUS cluster : answer: .BLKB 34 . . . QIOW_S CHAN=mychannel, - FUNC=, - P1=answer,- P2=#34 The first byte of "answer" is the count for the string contained in the following 16 bytes. The 18th byte is a count for the string contained in the last 16 bytes. This **WILL** be supported in V5.0 by GETDVI. Jack Patteeuw Ford Motor Co. Electrical and Electronics Division 31630 Wyoming Livonia, MI 48150 313-323-8643 ================================================================ Note 852.1 How to obtain a LAT port name/number 1 of 1 "John D. Ferriby" 10 lines 17-DEC-1987 00:17 -< Still more info on the LAT subject... >- ---------------------------------------------------------------- Can't say I've needed to find it, though it could definitely be a useful feature. As for the bits and bytes aspect, that info. is kept is the extension to the UCB for the particular LTx device. Of course, SDA only formats as far as UCB$S_LENGTH, but if you were to redefine the symbol to extend further, you will notice the tel-tale information. I have yet to see the definition for the UCB extension for LAT terminal devices, has anyone else? VAX-128 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT John D. Ferribyþò û 2871 Troy Centry û#2010 Troy, MI 48084 (313) 362-2595 ================================================================ Note 855.0 Hook into VMSMAIL send function 1 reply "Mark Nichols" 3 lines 16-DEC-1987 18:17 ---------------------------------------------------------------- Can anyone direct me to a bit of documentation or a code fragment explaining the "undocumented" MAIL> SEND to: XXX% hook in VMSMAIL? Mark Nichols Standard Wire and Cable Co. 2345 Alaska Ave. El Segundo, CA 90245 213 536-0006 ================================================================ Note 855.1 Hook into VMSMAIL send function 1 of 1 "John Osudar" 17 lines 16-DEC-1987 19:14 -< foreign protocol interface >- ---------------------------------------------------------------- Look on recent (Spring 1985 or later) VAX Sigtapes for Kevin Carosso's UUCP mail submission; he figured out the "foreign mail protocol" interface, which is otherwise undocumented (except in the MAIL code). Basically, when you use xxx% in front of an address, MAIL looks for the logical name MAIL$PROTOCOL_xxx and if that exists, it uses LIB$FIND_IMAGE_SYMBOL (RTL routine) to map the image into MAIL's address space. If the logical does NOT exist, MAIL looks for the image SYS$SHARE:xxx_MAILSHR.EXE and maps it. (If that's not there either, MAIL gives you an error message and gives up.) The image that's mapped by MAIL must have a list of entry points defined; Kevin's code documents this list quite well. It's not a trivial task to implement a foreign protocol interface, but it definitely CAN be done -- I've seen several different ones. MAIL also allows delivery in the other direction, using the (undocumented) /PROTOCOL= qualifier on the MAIL command to VAX-129 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT initiate delivery. John Osudar Argonne National Laboratory 9700 S. Cass Ave. Bldg. 205 A-051 Argonne, IL 60439-4837 (312) 972-7505 ================================================================ Note 858.0 Just got SPEARed 10 replies "G. Del Merritt" 16 lines 21-DEC-1987 17:54 ---------------------------------------------------------------- II just had the pleasure (?) of a visit from field service, who happily gave me VAXsim, SPEAR, and a small grey/tan box called a Remote Services Console. Merry Christmas, I suppose. I must admit that I wish they made the RSC rack mountable - maybe I'll move it under the raised floor. Just more clutter on top of the cabinet... I haven't hooked it up to a modem yet - maybe I will when I get a problem that seems to warrant it. I do have a question about the change that SPEAR wants to SYSTARTUP. Does running WHYBOOT just do what I would hope? i.e., just take a look at the errorlog to see why the system booted? or will it actually affect my system's startup in some way? By the way, didn't the way the SPEAR KITINSTAL built itself an account kinda' stilted? (and did you go through SPEAR's Instruction feature? amazing!) G. Del Merritt 55 Walkers Brook Drive Reading, MA 01867 VAX-130 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT ================================================================ Note 858.1 Just got SPEARed 1 of 10 "Brian Tillman, Smiths Industries." 8 lines 22-DEC-1987 10:56 -< Our SPEAR isn't uncomfortably embedded. >- ---------------------------------------------------------------- Our copy of SPEAR was installed by Field Circus, so I don't know what they went through to do so. As far as the SPEAR account, on our cluster it is a very normal non-privileged account. WHYBOOT hasn't changed how our VAXen boot or what happens at startup. Brian Tillman Lear Siegler, Inc. 4141 Eastern Ave. MS121 Grand Rapids, MI 49518-8727 (616)241-8425 ================================================================ Note 858.2 Just got SPEARed 2 of 10 "Jonathan M. Prigot" 9 lines 22-DEC-1987 15:49 -< WHYBOOT-20 >- ---------------------------------------------------------------- We have not "bounced" our system since SPEAR was installed on the VAX, but if it is anything like SPEAR on the DECsystem-20, WHYBOOT will prompt the operator as to the reason for the reboot (hardware problem, software problem, power fail, etc.) The reason given is factored into the system uptime calculation. I hope that WHYBOOT is smart enough to time out and continue the system boot if we have a momentary power fail in the middle of the night! Jonathan M. Prigot W.R. Grace & Company 55 Hayden Avenue Lexington, MA 02173 617-861-6600 x2148 VAX-131 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT ================================================================ Note 858.3 Just got SPEARed 3 of 10 "Bob Hassinger" 8 lines 22-DEC-1987 17:21 -< No problems here... >- ---------------------------------------------------------------- Field Service also recently installed SPEAR on our 750. Just noticed today after a crash I got a series of lines on the console during bootup listing possible reasons for a shutdown and asking for input. When I did not responded it timed out (seemed like 10 or 15 seconds) and everything seemed to carry on as usual. Bob H Bob Hassinger Liberty Mutual Research Center 71 Frankland Road Hopkinton, MA 01748 617-435-9061 ================================================================ Note 858.4 Just got SPEARed 4 of 10 "JIM PALMER" 25 lines 23-DEC-1987 18:01 -< Making auto WHYBOOT entry >- ---------------------------------------------------------------- DEC field service has also installed SPEAR on our systems. After DEC left, I did the following: 1) Removed the spear account. (No reason to have it, the FIELD account is just fine for FS to run from). 2) The WHYBOOT program puts a time stamped entry in the system errorlog file. I have a layered product installation standard that I follow for all our machines. When the SPEAR facility is executed, the following code runs. $ assign/user sys$input sys$command $ run sys$daderoot:[spe]whyboot SCHED $ $ exit VAX-132 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT Thus, we make an entry automatically at reboot time. So far, I have not found making a manual entry a boot time worthwhile. JIM PALMER 3 BROOKDALE IRVINE, CA. 92714-3338 (714) 458-3028 ================================================================ Note 858.5 Just got SPEARed 5 of 10 "Jamie Hanrahan" 20 lines 23-DEC-1987 21:26 -< On the first day of Christmas, Field Service gave to me... >- ---------------------------------------------------------------- | I just had the pleasure (?) of a visit from field service, who | happily gave me VAXsim, SPEAR, and a small grey/tan box called a | Remote Services Console. Haven't seen SPEAR or an RSC here yet. But when they came out a few months ago to give us VAXsim, I said, "Leave me the tape in case we need to rebuild the system disk." (We do this some- times.) They said, "We can't do that; it's DEC's property." I thought, hmm, they can install the software on my system disk but they can't leave me the media they brought it in on. Right. Next they'll tell me that once VAXsim is installed, making a backup copy of my system disk is illegal. I said, "Sorry, but I have to have the original distribution media on the shelf for anything that's on the system disk." They went away. My system is running quite happily without VAXsim, thank you. Perhaps this is why we haven't seen SPEAR or an RSC. Jamie Hanrahan Simpact Associates 9210 Sky Park Court San Diego, CA 92123 619-565-1865 VAX-133 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT ================================================================ Note 858.6 Just got SPEARed 6 of 10 "Jonathan M. Prigot" 12 lines 24-DEC-1987 09:03 -< Uptime calculations >- ---------------------------------------------------------------- | that I follow for all our machines. When the SPEAR facility is | executed, the following code runs. | | $ assign/user sys$input sys$command | $ run sys$daderoot:[spe]whyboot | SCHED <***** | $ | Just remember that if all your reboots are shown as due to SCHEDuled shutdown, then they do not count against system downtime. I am sure, however, that if your system does crash, you can manually run WHYBOOT to make the appropriate entry. Jonathan M. Prigot W.R. Grace & Company 55 Hayden Avenue Lexington, MA 02173 617-861-6600 x2148 ================================================================ Note 858.7 Just got SPEARed 7 of 10 "Kevin Angley" 22 lines 28-DEC-1987 11:29 -< × >- ---------------------------------------------------------------- VAXSIM is pretty neat ... it is errorlog at a glance with some automatic notification features. I couldn't live without it on my cluster. As for not letting you keep the distribution tape, you should at least be able to copy it via OPTIONS G in VMSINSTAL. If they won't sit for that, call third party maintenance in for quote, just to shake 'em up a bit. VAX-134 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT As for SPEAR, I have had it for over a year, and it has never done anything useful to my knowledge. As best as I can figure, you can tell it that the system went down at 10:00 and came back up at 11:00, and (miracles of miracles), it will tell you the system was down for an hour. I think it does something else, but I've never seen it help me out any. Delete the SPEAR account anyway. As previous note said, FIELD works good enough. That is, assuming you have a field account. I don't. These people have real names (even those in Colorado) so they have named accounts (copied from FIELD with individual passwords - ergo, individual responsibility). Kevin Angley 3301 Terminal Drive Raleigh, NC 27604 (919) 890-1416 ================================================================ Note 858.8 Just got SPEARed 8 of 10 "Saul Tannenbaum" 8 lines 28-DEC-1987 18:36 -< Speared, the past tense >- ---------------------------------------------------------------- I have SPEAR on my system. A cute toy, but I feel much more comfortable with ANALYZE/ERROR myself. Interestingly enough, SPEAR, while installed, doesn't run anymore. "Why not?," I asked my trusty field service person. "Well," he said, "when we install it, we have to give it an expiration time, for when your Field Service contract expires." Of course, he didn't have the documentation with him on how to extend your expiration date. Saul Tannenbaum Tufts University HNRC 711 Washington Str. Boston, MA 02111 (617)556-3346 VAX-135 PAGESWAPPER - February 1988 - Volume 9 Number 7 INPUT/OUTPUT ================================================================ Note 858.9 Just got SPEARed 9 of 10 "Bruce Bowler" 13 lines 29-DEC-1987 08:53 -< Try software services >- ---------------------------------------------------------------- | I said, "Leave me the tape in case we need to rebuild the system | disk." (We do this some- times.) They said, "We can't do that; | it's DEC's property." Jamie, you might try back-dooring it as it were, VAXsim is an orderable product (Q*060) and once you have the latest version of a product on your system *legitimately* (through field circus is OK), you can put it on your software contract. You get new versions through SDC (faster than trough FS, but not much). Complete DOC sets, media, etc. Bruce Bowler General Electric Bruce Bowler General Electric 1 River Road Bldg 2 Room 609 Schenectady, NY 12345 VAX-136 PAGESWAPPER - February 1988 - Volume 9 Number 7 System Improvement Request Submission Form System Improvement Request Submission Form Page 1 of _____ ________________________________________________________________ Submittor: Firm: Address: Phone: ________________________________________________________________ How to write an SIR: Describe the capability you would like to see available on VAX systems. Be as specific as possible. Please don't assume we know how it's done on the XYZ system. Justify why the capability would be useful and give an example of its use. If you wish, suggest a possible implementation of your request. ________________________________________________________________ Abstract (Please limit to four lines): ________________________________________________________________ Description and examples (use additional pages if required) PAGESWAPPER - February 1988 - Volume 9 Number 7 System Improvement Request Submission Form Tear out or photocopy reverse to submit an SIR Mark D. Oakley Battelle Columbus Division Room 11-6-008 505 King Avenue Columbus, Ohio 43201-2369 USA PAGESWAPPER - February 1988 - Volume 9 Number 7 VAX Systems SIG Spring 1988 SIR Ballot VAX Systems SIG Spring 1988 SIR Ballot DECUS membership number __________________ (six digits) Our site uses the following VAX cpus (check all that apply) 8700/8800 ___ 86nn ____ 85nn ____ 83nn/82nn ____ 11/780,11/782,11/785 ____ 11/750 ____ 11/730,11/725 ____ MicroVAX I,II ____ MicroVAX 2000 ____ MicroVAX 3n00 ____ We use VAXes in the following applications(Check all that apply) Business EDP ____ Software Development ____ Education ____ Computer Science Research ____ Data Acquisition/Control____ CAD/CAM ____ Service Bureau ____ Hardware Development ____ Scientific/Engineering ____ Office Automation ____ Telecommunications _____ Other __________________________ I support the following as the most important System Improvement Requests. (List from zero to fifteen SIR's): -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- -------- I oppose the following SIR's as detrimental. (List from zero to five SIR's): -------- -------- -------- -------- -------- Mail to: Mark D. Oakley Battelle Columbus Division Room 11-6008 505 King Avenue Columbus, OH 43201-2693 USA To be counted, your ballot must be received by April 8. PAGESWAPPER - February 1988 - Volume 9 Number 7 VAX Systems SIG Spring 1988 SIR Ballot Tear out or photocopy reverse to vote on SIRs Mark D. Oakley Battelle Columbus Division Room 11-6008 505 King Avenue Columbus, Ohio 43201-2693 USA