[ A bit of stuff off INFO-VAX off ARPAnet.] - Glenn Everhart Re: VMS: ...image questions "Possible" is not the same thing as "DEC-supported." It is in fact quite possible to run another image in the same process and then return control to your own code. Here is a little routine that will execute a DCL command and then transfer control to the program of your choice, which may or may not be the same program that invokes this call. I'll assume you are familiar with techniques for maintaining context across image activations. Sorry I took so long to put this together; usual disclaimers. -=EPS=- Internet: EPS%EQL.Caltech.Edu@Hamlet.Caltech.Edu BITNET: EPS@CALTECH HEP: EQL::EPS ------- [DO_RUN.MAR] .title do_run Combination LIB$DO_COMMAND and LIB$RUN_PROGRAM ;;; Eric P. Scott, May 1986 $clidef $climsgdef $cliservdef $libdef $ssdef $stsdef .default displacement,word .psect do_run,nowrt,exe,shr,pic,long ;;; ret-status.wlc.v=DO_RUN(cmd-text.rt.dx, pgm-name.rt.dx) .entry do_run,^m assume cli$k_srvdesc gt 63 movab -cli$k_srvdesc(sp),sp movl 4(ap),r0 jsb g^lib$analyze_sdesc_r2 blbc r0,28$ cmpw r1,#256 bgequ 27$ movq r1,r6 movc5 #0,(sp),#0,#cli$k_srvdesc,(sp) assume cli$b_rqtype eq 0 assume cli$w_servcod eq 1 assume cli$k_command le 255 movw #cli$k_cliserv!,(sp) movw r6,cli$w_rqsize(sp) movl r7,cli$a_rqaddr(sp) pushl sp calls #1,@#sys$cli blbc r0,40$ movl 8(ap),r0 jsb g^lib$analyze_sdesc_r2 blbc r0,28$ cmpw r1,#132 blequ 30$ 27$: movl #lib$_invarg,r0 28$: ret 30$: movq r1,r6 movc5 #0,(sp),#0,#cli$k_srvdesc,(sp) assume cli$b_rqtype eq 0 assume cli$w_servcod eq 1 assume cli$k_chain le 255 movw #cli$k_cliserv!,(sp) movw r6,cli$w_rqsize(sp) movl r7,cli$a_rqaddr(sp) pushl sp calls #1,@#sys$cli blbs r0,50$ 40$: cmpzv #sts$v_fac_no,#sts$s_fac_no,r0,#cli$_facility bneq 44$ cmpw r0,# bneq 45$ movl #lib$_nocli,r0 44$: ret 45$: movl #lib$_uneclierr,r0 ret 50$: movab cli$k_srvdesc(sp),sp pushl s^#ss$_normal calls #1,@#sys$exit clrl r0 ret .end 10 May 86 CUNNINGHAMR%HAW.SDSCNET@LLL-MFE.ARPA, A DECUS trip report [A shortened version of my DECUS trip report for your amusement.] GENERAL COMMENTS The Dallas Convention Center was the largest such facility I've ever seen, and the joke that they should have issued us horses & compasses instead of cowboy hats didn't seem all that funny as the week wore on and I kept walking the .5+ mile or so back and forth to different ends of the complex. At Dallas -- my 2nd DECUS -- I found myself was able to spend more time in the less formal sessions (the Birds-of-a-Feather and "campground" informal meetings), and the various question & answer sessions. Many of these seemed more productive than some of the more formal sessions. I think my organization got its money's worth out of sending me, but after another DECUS or so this sort of thing will start reaching a point of diminishing returns. My personal preference fron now on is to attend just the "western" DECUS meetings once a year, starting with the next DECUS in San Francisco this October. As before, pre-purchasing most of the session notes proved to be a very good investment. I also ended up ordering audio tapes for seven sessions I would have liked to attend, but couldn't make due to scheduling conflicts. While I didn't get an official count, DECUS attendance seemed down (to perhaps < 5,000 from 6,000+ at Anaheim?). DEC's new policy of not making many new product announcements at DECUS symposia probably had an effect, but I suspect the industry-wide depression made more of a difference. [ Note: official count was about 5000 attendees.] UPCOMING DECUS SYMPOSIA 6-10 Oct 1986 Moscone Center, San Francisco CA 27 Apr - 1 May 1987 Opryland Hotel, Nashville, TN 7-11 Dec 1987 Anaheim Convention Center, Anaheim CA 16-20 May 1988 Cincinnati Convention Center, Cincinnati OH Boston is building a new convention center, and after 1988 we may see a DECUS in the northeast. Until then, New York is apparently the only spot with adequate facilities ... and the consensus is that it's just too expensive. PRODUCT ANNOUNCMENTS AT DECUS Digital had a "DECWORLD" presentation of new things back in March, and announced most of their new products then. In fact, they've officially stated that they will no longer follow the longstanding practice of introducing lots of new products at DECUS, but will announce new products separately (or at special staged events like DECWORLD). The only announcements I caught were: LN03 PLUS, an expanded-memory version of the LN03 (also should be available as an upgrade). Enough memory to bitmap an entire page of output, provides Tektronix 4010/4014 plotting emulation. (significiantly, does not yet provide POSTSCRIPT support, although that might just happen later...). We're planning on getting a couple of them. PRINTSERVER 40, a 40 page/minute (DEC calls this mid-range speed!?) laser printer. Ethernet interface only, intended as a print server. Understands POSTSCRIPT. 300x300 dot/inch resolution. 50,000 pages/month rated capacity, 2,000 sheet feed bin (+ 2 auxiliary trays), 2 output trays. uVAX-II controller and VT220 console. Printserver software downline loaded from a host VAX. Host server symbiont does translation for non-postscript files: ANSI, LN03, REGIS, Tektronix 4010/ 4014 plotting. TU81 PLUS. New version of TU81 (6250/1600bpi tape drive) with buffering to allow it to stream nicely. (256K buffers internal.) VAXcluster console. Looked cute, I missed seeing any specs. However, requires you to buy a whole uVAX II for the cluster. Expensive. A SIGNIFICANT NON-ANNOUNCEMENT DEC had a "technology demonstration" that they emphasized "was not a product, we only want your feed back at this time" consisting of a cluster of uVAX-II's and VAXstations (the workstation models of the uVAX-II with the nifty screens and mouse -- rather like Sun workstations). The cluster used Ethernet, not star couplers. Thin-wire Ethernet, at the demonstration. The way it works is to have one "boot member" (a uVAX in their demonstration, but could be a larger VAX) which holds the common system disk, and downline boots the uVAXes via Ethernet. Other "core member" machines can handle printers and other utilities, but all systems software is on the "boot member". This makes the uVAX-IIs in the cluster "diskless" or potentially so. Digital recommends having a small, fast hard disk on each for paging & swapping. I attended the son that described how they did it, and came away with the impression that the developers found it fairly simple. Multi-cast Ethernet packets effectively replace a systems bus/star coupler. It works. Very well, in my opinion. I think this could well be an interesting development for those of us with VAX 750s ... turn them into "core members" of a cluster of uVAX-IIs and do some very nice things. A lot of people at DECUS liked the idea of clustering uVAXes. SIGNIFICANT THINGS NOT SEEN No sign of any new RA8n larger-capacity disk drives. No sign of any new higher-capacity tape drives. INTERESTING RUMORS The performance of uVAX-IIs in real applications varies more than I suspected. Since it doesn't handle the full VAX instruction set in hardware, performance for a given application can vary anywhere from 10% of, to 110%+ of a VAX-11/780. [COBOL programs and the like that use the edit instructions or packed decimal math are the slow ones. Most everything else is OK.] Expect the uVAX-III (full VAX instruction set in hardware, probably even faster than the uVAX-II) within a year. The 8600 was originally supposed to come out much earlier than the other 8nnn processors, and in some ways isn't really part of the family of new 8nnn processors. Also notice that there is a bit of a gap between the 8600/8650 machine and the 8800. Don't be surprised if DEC announces an 8700 in a year or so ... which might effectively obsolete the 8600/8650. A new board with a J-11 will be out for uVAX and the BI machines within a short time. It will allow compat mode code to run on the PDP11 at hardware speeds. The emulator on the 8800 is comparatively slow and DEC VAX developers who use TECO need it to be faster... VAX LANGUAGES & TOOLS RELEASE STATUS Here's a list of the current versions (and shipping dates) of various DEC software products (courtesy of an L&T handout): ADA V1.2 shipment started Feb 86 VAX APL V2.1 Apr 86 VAX BASIC V2.4 Sep 85 VAX BLISS V4.2 Feb 86 VAX C V2.2 May 86 VAX COBOL V3.3 Apr 86 VAX FORTRAN V4.4 Feb 86 VAX Pascal V3.3 Apr 86 VAX PL/I V2.4 Apr 86 VAX RPG II V2.0 Dec 85 VAX PCA V1.1 Dec 85 VAX DEC/CMS V2.2 May 86 VAX DEC/MMS V2.1 Dec 85 VAX DEC/Shell V1.2 May 86 (Unix-like shell) VAX LSE V1.3 May 86 (Language-Sensitive Editor) VAX Scan V1.0 Nov 85 (awk-like pattern matching, etc.) VAX NOTES V1.? May 86 (computer conferencing) My impression of the VAX NOTES demonstrated on the VAXes in the exhibit hall was mixed, seems like it needs a few more features for the price. Very handy teleconferencer, but the LBL Tools mail system does about the same things and is free. VMS NEW VERSION NOTES Current version is VMS V4.3 (V4.3A, maybe V4.3B for the new 8nnn processors). V4.4 used internally within DEC, but won't be shipped to customers until summer ... they're still adding a few things. Back in December, the VMS developers talked about doing functional upgrades every 8 months (even numbered .n releases), and bug-fix updates in between (the odd numbered .n relseases). In Dallas they admitted that's a tough schedule to hold to, and they're slipping their schedules. What to expect in V4.4? Primarily, support for all the new hardware (8200, 8300, 8500, 8800, HSC70, TU81+) including multiprocessing support; secondarily some improvements in cluster support and some updated utilities (EDIT/ACL gets fixed, DEBUG gets improved) ... and some refinements to DECNET; finally a somewhat re-organized manual set. The new processor support major thing in V4.4 -- and what's causing the delays in producing a production version. For clustered systems V4.4 can co-exist with 4.3 in a rolling upgrade, but not with earlier versions (4.2 or below). Other DECNET systems can address all the nodes of a homogeneous VAXcluster as a single DECnet node; access to layered products on a common system directory can be restricted to one or more nodes via ACLs. SHOW CLUSTER tells you more. ANALYZE/ERROR_LOG tells you more about clusters. There is a new version of the CI port driver. Utility changes involve a new SET RIGHTS_LIST command; a /[NO]RESTART qualifier on START/QUEUE/MANAGER; queue-specific default forms for printer, terminal and server queues; print symbiont now permits user-defined i/o routines (offically). ANALYZE/RMS has some new commands. RMS supports shared read/write access to any sequential files. The symbolic debugger DEBUG has even better screen support. RMS performance should be a bit improved due to cach interlock improvements. DECnet has to be re-installed. Some routing features have been improved, 802.2 and 802.3 Ethernet packets now supported. Many minor DECnet fixes. Look for C2 (federal goverment) security classification for VMS with V4.4. Maybe even B1 in a later version of VMS. VMS DOCUMENTATION RE-ORGANIZED WITH V4.4 Much of the VMS documentation has been re-organized. Some manuals that had been guides (books in small binders) are part of the reference shelf (big binders). Reference shelf manuals are now grouped into "functional" volumes. Specifically: utilities are no longer part of one group called "utilities", they're now part of "program development", "system management", "networking" and other reference manuals. DCL Dictionary is now just part II of older manual, former part I is now the "VAX/VMS DCL Concepts Manual". "User's Guide to EVE" and "VAXTPU EDT Keypad Emulator Quick-Reference Guide" have been merged into the "Guide to Text Processing on VAX/VMS". V4.4 release notes manual is the only release notes manual in the document and incorporates notes for V4.0-4.3. For document ordering purposes there are now several possible subsets you can order: 1) VAX/VMS User's Document set (reference shelf vols 1-6) 3) VAX/VMS Programmer's Document set (reference shelf vols 7-10) 4) VAX/VMS Condensed Document set VAX/VMS User's Manual (nice, better than V3 Primer) VAX/VMS Mini-Reference (superseeds quick-reference booklets) 5) VAX/VMS Guides But, of course, you can still order the whole bookcase full as one item. (and you should get a full set with V4.4.) SOME SUGGESTIONS FOR BACKUP Here's some suggestions for doing BACKUPs efficiently while maintaining a reasonable amount of data integrity, gleaned from several sessions: For best tape drive performance use /BUFFER=5 (default is 3), and a large block size. How large? /BLOCKSIZE=64000 or (if you're conservative) /BLOCKSIZE=16384 for 6250bpi tape units, and /BLOCKSIZE=32768 or (if you're conservative) /BLOCKSIZE=16384 for 1600bpi tape units. Use the smaller BLOCKSIZEs for archival backup tapes, the larger for regular backups. In general /NOCRC is safe for 6250bpi tape drives, but use the default /CRC for 1600bpi tapes. For incremental backups using date selection criteria, use /FAST; otherwise omit this (it doesn't buy you anything for wildcard selection nor if you're backing up many, many files). Preferred method for full volume backup is /IMAGE (which turns on /FAST, incidentally), but for volumes which are nearly full of files doing /PHYSICAL instead goes quicker --- but you must use DSA-type disks (e.g. RA81) because you effectively need a bad-block-free output disk when you do a restore. /PHYSICAL is handy for "snapshot" system disk backups prior to doing upgrades, etc. Only a very rash person would want to change the /GROUP_SIZE (default 10) parameter which controls the xor redundancy block calculation, since you really get no performance increase by disabling it (what it means is that an 11th xor check block is generated for each 10 data blocks on your backup tape). BACKUP definitely goes faster if input and output devices are on separate Unibuses, if you can do that. Using the HSC backup (clustered systems) gets the most out of your tape drives (and is equivalent to doing /PHYSICAL on non-clustered systems). SOME SUGGESTIONS FOR SYSUAF PARAMETERS The VMS default parameters for users (what you get when you run AUTHORIZE and take the original default parameters) are too low for many applications. In particular, the default BYTLIM parameter of 4096 is too low even to run some of DEC's programs (try the DCL sub-command of TPU). Everyone internally at DEC has a BYTLIM of at least 20,000. 24,000 isn't unreasonable, it's a very "cheap" thing to increase (very small increase in working set). Here's a summary of recommended default SYSUAF parameters from various sources: BYTLIM 24000 FILLM 64 BIOLM 24 DIOLM 24 ASTLM 64 TQELM 32 ENQLM 48 JTQUOTA 2048 PRCLM 6 All the rest at DEC's defaults. Working set parameters also need careful attention, but vary according to applications and your notion of how to tune your system. KERMIT Current version of Kermit-32 for VMS VAXes is 3.2.074 . Available from Kermserv on BITNET and via FTP from COLUMBIA on ARPAnet. Will be on fall SIG tapes. USENET UNDER VMS An interesting BOF, continuing the discussion at Anaheim. Several people are working on different approaches, and a small real working group was formed. I think we'll be hearing good news from those folks in a few months. Two separate issues were discussed: the news-reading software; and transport mechanisms. Consensus was that these were separate development issues. While a straight port of readnews/vnews/rnews was feasible, a couple of people have already done much of the work involved in re-writing from the ground up sets of programs giving equivalent functionality under VMS, and that seems to be the preferred path. Similarly, a consensus seemed to be reached that several different transport mechanisms were not only feasible, but it was a good idea to have several. Uucp under VMS programs exist, but typically require Unix licenses in order to run anyways. In theory, any sort of mail transport setup (including Kermit and FIDOnet) should be slightly hackable to transport Usenet news. Doing a modified Kermit (or a set of programs that sits on top of Kermit) to transport the Usenet news seemed to appear popular, and several people said they were interested enough in the idea to hack on it. INFO-VAX SUBSCRIBER'S BOF Not sure that anyone else would, I scheduled one. Was pleasantly surprised to see more than a dozen people show up. Had a free-form discussion touching on many of the recently-active issues being discussed in INFO-VAX. We spent a fair amount of time discussing the features & bugs of various TCP/IP packages for VMS VAXes, the GNU effort, and just matching names dis-embodied electronic addresses with real faces. I'd like to see it happen again at a future DECUS. 10 May 86 GKN%SDS.MFENET@LLL-MFE.ARPA, Backup, DECnet, and tape drives Christian: Let me see if I understand the problem: You want to have Backup deliver a save set straight to a tape drive across DECnet. If this is true, you need to write a program which catches Backup save sets from a DECnet logical link and does the right thing with them. At the end of this message is a program which does such a thing, and a command file which is uses. Basically, you have to define an object for DECnet thusly: $ NCP Define Object NetBackup Number 0 File SYS$SYSTEM:NetBackup.COM Stick NetBackup.COM and NetBackup.EXE on SYS$SYSTEM:, and then use it like: $ Backup [...] NODE::"Task=NetBackup" The save set name will be the name of the source node. I use this to back up a uVAX-II which has no tape drive across an ethernet to an 11/785 every day. Hope this helps. Gerard Newman ---------------------------------NetBackup.COM---------------------------------- $ Set Verify $ $ !+ $ ! $ ! ----- NetBackup.COM: DECnet-based backup $ ! $ ! $ ! This command file, along with NetBackup.EXE, provides a Backup server $ ! process to receive save sets via DECnet and place them directly in a $ ! tape file. $ ! $ ! Version: V01.00 $ ! Date: 05-Feb-1986 $ ! $ ! Gerard K. Newman 05-Feb-1986 $ ! $ !- $ $ Set NoOn !Don't crap out $ Set Process/Priority=4 !Don't be (much of) a ho g $ $ We_Were_Here_Before = 0 !Only once thru so far $ $ ! Get the node name from SYS$NET and use it as the tape label $ $ Node = F$Logical("SYS$NET") !Get the node name $ Node = F$Extract(0,F$Locate(":",Node),Node) ! ... $ Set Process/Name="NetBack: ''Node'" !Frills $ $ ! Grab onto a TU78 if we can (note - just specify the device type, and $ ! DCL will find a free device if it can) $ $ Allocate MF TAPE: !Get a TU78 if we can $ Err_Status = $STATUS !Copy the status $ If .not. Err_Status Then Goto No_Tape_Avl !Die if we lost $ $ ! Initialize the tape et. al. $ $ Init_Tape: !Here to initialize the tape $ $ If We_Were_Here_Before Then Goto Backup_Lost !Punt if we loop $ We_Were_Here_Before = 1 !Mark that we've been he re before $ Initialize/Density=6250 TAPE: 'Node' !Initialize the tape $ Err_Status = $STATUS !Save the status $ If Err_Status Then Goto Mount_Tape !Mount it if we won $ $ ! See if we lost because the tape drive isn't spun up $ $ If Err_Status .neq. %X10750254 Then Goto Cant_Ini !%INIT-F-VOLINV $ $ ! Ask the operator to hang the tape. $ $ Request/Reply "Please mount a tape on ''F$Logical("TAPE")' for backup of _''Node'::" !Ask pretty please $ If $STATUS Then Goto Init_Tape !Try try again $ Goto Cant_Ini !Sigh. $ $ Mount_Tape: !Here to mount the tape $ $ Mount TAPE: 'Node' !Mount the tape $ Err_Status = $STATUS !Retain the status $ If .not. Err_Status Then Goto Cant_Mount !Huh? $ $ ! Catch the save set from the network $ $ Run SYS$SYSTEM:NetBackup !Catch the save set $ Err_Status = $STATUS !Save the status $ If .not. Err_Status Then Goto Backup_Lost !Sigh $ $ ! We're done $ $ Request "Backup is done!" !We're done $ $ Clean_Up: !Here to clean up $ $ Dismount TAPE: !Dismount the tapre $ Deallocate TAPE: !Let go of the tape $ Exit !Ciao $ $ ! Here when we can't allocate the specified tape drive $ $ No_Tape_Avl: !Can't allocate the tape $ $ Own_PID = F$GetDVI(P1,"PID") !Get the owner PID $ Own_Process = F$GetJPI(Own_PID,"PRCNAM") !Get the owner process n ame $ Request "Can't allocate ''P1', it's owned by ''Own_Process' (''Own_PID') " $ Exit !Bye $ $ ! Here when we can't initialize the tape $ $ Cant_Ini: !Can't initialize the ta pe $ $ Request "Can't initialize ''P1', to wit: ''F$Message(Err_Status)'" $ Goto Clean_Up !Bye $ $ ! Here when we can't mount the tape $ $ Cant_Mount: !Can't mount the tape $ $ Request "Can't mount ''P1', to wit: ''F$Message(Err_Status)'" $ Goto Clean_Up !Bye $ $ ! Here when backup lost $ $ Backup_Lost: $ $ Request "Backup crapped out, viz: ''F$Message(Err_Status)'" !Sigh. $ Goto Clean_Up !Ciao ---------------------------------NetBackup.MAR---------------------------------- .Title NetBackup - DECnet based backup .Ident /V01.000/ .Enable SUP .Default Displacement,Word .Subtitle Introduction ;+ ; ; ----- NetBackup: DECnet based backup ; ; ; Facility: ; ; VAX/VMS system management, backup procedures. ; ; Abstract: ; ; This routine will operate as a network server to catch save ; sets from systems which do not have tape drives. This routine ; requires some help from NetBackup.COM. ; ; Environment: ; ; VAX/VMS V4.0 or later, NETMBX privilege. ; ; ; Version: V01.000 ; Date: 21-Jan-1986 ; ; Gerard K. Newman 21-Jan-1986 ; Science Applications International ; 800 Oak Ridge Turnpike ; Oak Ridge, TN 37830 ; (615) 482-9031 ; ; ; Modifications: ; ; ;- .Page .Subtitle Local definitions .NoCross ;Save a tree $IODEF ;I/O function codes $RMSDEF ;RMS junk $SSDEF ;System service codes .Cross ;Turn CREF back on ; Local definitions ; Block size from the backup save set header. This information taken from ; BACKDEF.SDL, fiche 9 B15. $DEFINI BBH ;Start of the Backup Block Header $DEF BBH$W_SIZE .Blkw ;Size of this structure $DEF BBH$W_OPSYS .Blkw ;Operating system ID $DEF BBH$W_SUBSYS .Blkw ;Subsystem ID $DEF BBH$W_APPLIC .Blkw ;Application ID $DEF BBH$L_NUMBER .Blkl ;Block sequence number $DEF BBH$B_FILL1 .Blkb 20 ;Spares $DEF BBH$K_COMMON ;Length of the common header $DEF BBH$W_STRUCLEV ;Structure level, which is composed of: $DEF BBH$B_STRUCVER .Blkb ;The structure version $DEF BBH$B_STRUCLEV .Blkb ;The structure level $EQU BBH$K_LEVEL1 257 ;Structure level 1, version 1 $DEF BBH$W_VOLNUM .Blkw ;Volume number $DEF BBH$L_CRC .Blkl ;Block CRC $DEF BBH$L_BLOCKSIZE .Blkl ;Block size $DEF BBH$L_FLAGS .Blkl ;Flags $DEF BBH$T_SSNAME .Blkb 32 ;.Ascic save set name $DEF BBH$W_FID ;Current FID $DEF BBH$W_FID_NUM .Blkw ;File header number $DEF BBH$W_FID_SEQ .Blkw ;File sequence number $DEF BBH$W_FID_RVN ;Relative volume number $DEF BBH$B_FID_RVN .Blkb ;Relative volume number $DEF BBH$B_FID_RVX .Blkb ;Relative volume file header extension ( ?) $DEF BBH$W_DID ;Current DID $DEF BBH$W_DID_NUM .Blkw ;Directory header number $DEF BBH$W_DID_SEQ .Blkw ;Directory sequence number $DEF BBH$W_DID_RVN ;Directory relative volume number $DEF BBH$B_DID_RVN .Blkb ;Ditto $DEF BBH$B_DID_RVX .Blkb ;Relative volume file header extension ( ?) $DEF BBH$T_FILENAME .Blkb 128 ;Current file name $DEF BBH$B_RTYPE .Blkb ;Record type of the current file $DEF BBH$B_RATTRIB .Blkb ;Record attributes $DEF BBH$W_RSIZE .Blkw ;Record size of the current file $DEF BBH$B_BKTSIZE .Blkb ;Bucket size of the current file $DEF BBH$B_VFCSIZE .Blkb ;VFC size of the current file $DEF BBH$W_MAXREC .Blkw ;Maximum record size of the current file $DEF BBH$L_FILESIZE .Blkl ;Size of the current file in blocks $DEF BBH$T_RESERVED2 .Blkb 22 ;Reserved $DEF BBH$W_CHECKSUM .Blkw ;Header checksum $DEF BBH$K_LENGTH ;Length of the Backup Block Header $DEFEND BBH ;End of the Backup Block Header ; Buffer size we allocate to catch blocks from the network. Do not make ; this bigger than 32K, as VMS can't cope with transfers larger than that ; from DECnet. MAX_BUFF = 32768 ;Largest buffer we care to cope with .Page .Subtitle Impure storage .Psect IMPURE_DATA NOEXE,RD,WRT,PIC,NOSHR,PAGE ; RMS control blocks to create the file on our tape drive. This is ; easier to do than trying to figure out how to use the ACP QIO ; interface. TAPE_FAB: $FAB - ;FAB for the tape drive DNM=,- ;Default file name FAC=,- ;Write access FNA=NODE_BUFF,- ;File name address FOP=,- ;Let me do the I/O RFM= ;Fixed length records ; Random data NET_CHAN: .Blkw ;Channel to the network IOSB: .Blkq ;Random I/O status block BUFF_DESC: .Long MAX_BUFF,0 ;Buffer descriptor NODE_DESC: .Long 64 ;Node name .Address NODE_BUFF ; descriptor NODE_BUFF: .Blkb 64 ;Space for our node name .Page .Subtitle Pure storage .Psect PURE_DATA NOEXE,RD,NOWRT,PIC,SHR,PAGE ; Random strings SYS$NET: .Ascid "SYS$NET" ;To confirm our connect .Page .Subtitle Entry point .Psect CODE EXE,RD,NOWRT,PIC,SHR,PAGE .Entry START,^M<> ;Entry here ; First things first. Confirm our DECnet connection. $ASSIGN_S DEVNAM=SYS$NET,- ;Assign a channel CHAN=NET_CHAN ; to confirm the connection BLBC R0,10$ ;Die if we can't ; Allocate a buffer big enough to hold onto backup save sets PUSHAL BUFF_DESC+4 ;Return the address here PUSHAL BUFF_DESC ;We need this much memory CALLS #2,G^LIB$GET_VM ;Go allocate some memory BLBC R0,10$ ;Sigh. MOVQ BUFF_DESC,R10 ;Address our buffer ; Read the Backup Block Header record to find out how big to make the blocks, et c. $QIOW_S CHAN=NET_CHAN,- ;Read from the network FUNC=#IO$_READLBLK,- ; to find out how big IOSB=IOSB,- ; to make our blocks P1=(R11),P2=R10 ;Put the data here MOVZWL IOSB,R0 ;Grab the I/O status BLBS R0,20$ ;Branch if we won 10$: BRW 50$ ;Leave if error ; Fill in the block size and maximum record size. 20$: $FAB_STORE FAB=TAPE_FAB,- ;Store the BLS=BBH$L_BLOCKSIZE(R11),- ;Block size MRS=BBH$L_BLOCKSIZE(R11) ;Maximum record size ; Use the node name as the save set name, as the save set name in the ; BBH looks a lot like "Task=NetBackup", which is no good at all. $TRNLOG_S LOGNAM=SYS$NET,- ;Get the NCB RSLBUF=NODE_DESC,- ;Put it here RSLLEN=NODE_DESC ;Tell me how long it is MOVQ NODE_DESC,R0 ;Grab a copy of the descriptor LOCC #^A/:/,R0,(R1) ;See if we can find a node name SUBL3 R0,NODE_DESC,R1 ;Compute the length of the node name $FAB_STORE FAB=TAPE_FAB,- ;Store the FNS=R1 ;Save set name size ; Create the file, but let me do I/O to it. Use RMS, as it's a lot easier ; than the QIO interface to the ACPs... $CREATE FAB=TAPE_FAB ;Create the file BLBS R0,40$ ;Branch into the rest of this if we won RET ;Lose otherwise ; Ok - now all we have to do is to loop copying records from the network ; into our file. When we deassign the channel at the end of all of this ; we should be just fine. 30$: $QIOW_S CHAN=NET_CHAN,- ;Read another record FUNC=#IO$_READLBLK,- ; from the network IOSB=IOSB,- ;I/O status here P1=(R11),P2=R10 ;Buffer is here MOVZWL IOSB,R0 ;Get the I/O status BLBC R0,50$ ;Maybe the other guy quit 40$: MOVZWL IOSB+2,R1 ;Get the size of the buffer to write $QIOW_S CHAN=TAPE_FAB+FAB$L_STV,- ;Write out FUNC=#IO$_WRITEVBLK,- ; the next block IOSB=IOSB,- ; on the tape P1=(R11),P2=R1 ; ... MOVZWL IOSB,R0 ;Get the I/O status BLBS R0,30$ ;Loop if successful 50$: CMPL #SS$_LINKDISCON,R0 ;Did the other guy go away? BEQL 60$ ;If EQL yes, not an error CMPL #SS$_LINKABORT,R0 ;This happens sometimes, too BNEQ 70$ ;Must be a real error 60$: MOVL #SS$_NORMAL,R0 ;Else not an error 70$: RET ;Back to DCL (all deassigns done for me) .End START