Return-Path: XPUM04@prime-a.central-services.umist.ac.uk Received: from G.SEI.CMU.EDU by ubu.cert.sei.cmu.edu (5.61/2.3) id AA21399; Thu, 7 Jun 90 14:21:46 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA14459; Thu, 7 Jun 90 14:21:45 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA04920; Thu, 7 Jun 90 14:21:37 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa15488; 7 Jun 90 15:44 BST From: Anthony Appleyard To: KRVW <@NSFnet-Relay.AC.UK:KRVW@sei.cmu.edu> Date: Tue, 05 Jun 90 14:07:00 BST Message-Id: <$TGVGDBVHCNZK at UMPA> Subject: Virus-L vol 0 issue #0621 Virus-L Digest Tue, 21 Jun 88, Volume 0 : Issue #0621 Today's Topics VM/SP Release 5 doesn't RECEIVE hidden files; Re: Historical Comments ------------------------------ Date: Tue, 21 Jun 88 08:06:35 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: In-Reply-To: 15 Jun 88 11:57:09 EDT From Jefferson Ogata From: Otto Stolz +49 7531 88 2645 Subject: VM/SP Release 5 doesn't RECEIVE hidden files; Hello, this is good news, and not an unconfirmed rumour. On thursday, I had started writing my note in order to tell you that VM/SP Release 5 contained an antidote to the possible poisining uncovered by Jefferson Ogata's contribution. As I could neither find it in SC24- 5290-0 "Release 5 Guide", nor in SC24-5330-0 "Using Release 5 Enhance- ments", I thought I was wrong, and announced this NETSERV stuff, instead. Now, I looked it up in SC19-6209-4 "CMS Command Reference, Release 5", and -- heureka! -- there it sits and waits for you! I cannot under- stand why they didn't mention it in the other two books (one of them is nearly two inches thick!). Perhaps, they were ashamed admitting impli- citly that they had to remove a serious flaw in their design :-) The RECEIVE and READCARD commands have been enhanced with a new triple of options: FULLPROMPT, MINPROMPT, and NOPROMPT. With RECEIVE, the default is MINPROMPT, and with READCARD (seldom used), it is NOPROMPT -- that's the risky one :-( The explanation for MINPROMPT says: > Minprompt > specifies that a prompt is issued when the name of the first (or > only) file differs from the name of the spool file; the prompt for > the first file is suppressed when it has the same name as the spool > file. A prompt is always issued for the second an subsequent files. Further explanations show that RECEIVE will prompt you for hidden files from partioned data sets in DISK DUMP and NETDATA format, whilst it will read in continuously punched spool files into a single (and harmless) disk file with all those :READ statements embedded. READCARD will accept punched spool files and create multiple disk files from them, evaluating the :RDR statements. In any case, no file will creep onto your disk unnoticed, if you use the MINPROMPT or FULLPROMPT option: instead, you'll be notified and prompted for approval of every file. There remains one dark spot. A usage note for the RECEIVE command says: > The MVS with TSO Extension Program Product ... can send, as a unique > case of multiple files in one transmission, one note and a data file > together. The note will be the first file in the transmission and the > data file will be second. RECEIVE will add the note to the appropriate > notebook, receive the data file, and give informative messages for each > action. This is the only form of multiple NETDATA files supported by > the RECEIVE command. This paragraph has come unaltered from the Release 4 manual. As the last sentence clearly contradicts the new sections on MINPROMPT, I still hope that it is an oversight by the authors, and RECEIVE will not only "give an informative message" for the second file but rather ask the user for approval. We plan to introduce Release 5, tomorrow. And I'd gladly appreciate a MVS/TSO volunteer to sending me a duplicate file as outlined in the quotation above. I hope, it is specific enough to be followed by a MVS/TSO user. I'll shortly report to the list the results of this test, and possibly other experiences with Release 5. Best regards Otto Stolz -------------------- Date: Tue, 21 Jun 88 13:49:30 mdt Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Warning -- original Sender: tag was From: Bill Kinnersley Subject: Re: Historical Comments The "GO TO JAIL" code lives on today, in Honeywell's CP6. The Fortran 77 compiler Version D00 still produces this warning message. Of course this is not a virus. Pretty soon we'll be calling everything that doesn't work right a virus. "Sorry, Prof. My program's not working yet. It must have a virus." -------------------- *** end of Virus-L issue ***