Let me answer some of the questions you mailed to this list.
1) Code distribution: I assume that by now all of you have received the code.
If this is not the case just contact me or Harold (the nearest one please)
and we'll resend a copy.
2) UN*X userids: I agree with Phil. Unix people that want to communicate with
the network should not leave their UseRiDs in mIxed caSe, even though they
like it better that way. Unix behaves like the average frenchman who sends
mail in french to, for example, german people. My accounting teacher even
told me the story of a french society who was competing with a german one
for selling transformers to Corean people. The french ones were much better
but the german people got the contract. Reason: the french society provided
doc in french, while the german one had english doc. Those Unix systems who
don't accept all-caps userids deserve to be treated like that french society
3) MOVE jobs rejection: I have fixed this one, just c/2 2/2 3/ in LSVCMD in the
"if command = 'X-ADD' |...." line.
4) You *can* change your name on a closed list by just re-SUBSCRIBEing to it.
This works, however, ONLY if the "Validate=" option is "Store only". When
you set "Validate= all commands", you tell LISTSERV to reject any command
that would modify a list and does not have a password. The only exception is
that you can still send *one* SUBSCRIBE command to the list (if it is open).
In other words, you can get on it but you can't change your name then. What
if a UN*X hacker sent a command "from" YOUR userid saying "SUBS listname
(censored) (censored)hole"? (two arguments are required ;-) )
5) Storage capacity problems: this was a real puzzle. The files I sent were
about 5,000 lines (rounded upwards), ie about 512k when kept in storage
(counting the pointers overhead, etc). The first thing LISTSERV will do is
an EXECIO * CARD. My server was 800k when I first sent it the thing, and it
did not run out of storage at that point. Then the lines are pulled one
after the other and stored into GLOBALV vars as the DD card is processed.
This costs a little more storage because GLOBALV is less efficient than the
CMS stack, and my 800k server screamed at this. Since it swallowed the file
at 2M and Marc's needed more, I'll assume that what was needed is 2M + 8k or
so, the difference being due to the EXECLOADs in CMS4, or suchlike. Now
assume the GLOBALV stuff has been done. Instead of 512k, the thing now
eats up 520k (800k seems to have been *just* enough to load the cards, and
it is consistent with my experimentation that a 256k CMS VM can be IPLed
but nearly no storage is left once the PROFILE has been run). So, the DISTRI
BUTE command is executed and all the stuff is fetched back from GLOBALV and
written to a disk file (CARD PUNCH showed to be much faster than a QUEUE
loop + EXECIO...) The present version purged the GLOBALV storage only after
the file was read, so you actually ended up with 2 copies of your file in
storage just before the GLOBALV PURGE. This still doesn't explain 2M... I
had a look into the REXX interpreter, and, lo and behold, here was the
culprit: when you do a CALL statement, *all* variables are pushed into the
REXX stack. Which means one more 512k block. Why so? Because *sigh* the poor
little IBMies had a fast CALL processor but it duplicated a lot of code from
the function parser, and what with maintening it, and aspirins fringe&over-
head, etc. So they just emulated CALL as a function which returns no argu-
ment. They say it's 25% slower, but much more convenient for them. Why do
you have to save vars when calling a function? *sigh*
b = a + f(a)
f: drop a
return 0
--> ADDRESSING EXCEPTION OCCURED AT... IN SYSTEM ROUTINE DMSRFN, RE-IPL CMS
I prefer not to comment on this one. I'll try to "improve" LSVDIST by decrea
sing its performances in order to save 2*filesize bytes.
6) Which disk/storage size should we use?
a) Temp disk space: I suggest 2 to 3 megs of T-DISK. It must be able to hold
a file of FILEMAXL records of lrecl 255. That's about 2500k with filemaxl
= 10,000 (default) and that's why I suggested 5 3350 cyls. It's comforta-
ble enough I think. The MINIMUM size is filemaxl * 80 + overhead, though
(records > 255 are supported but truncated when processing DISTRIBUTE
command, mail files, etc).
b) A-disk space: should be able to hold the code and datafiles. I have a 5
cyls disk myself because I need to hold the shipment files too. People
who don't and have small lists need only 1-1.5 megs.
c) NOTEBOOKs-disk space: optional, and up to you.
d) Storage: should be CMS+CMS overhead + EXECLOAD space + FILEMAXL*120, at
least. This is about 300k + 0k (CMS3) or hmm... 200k? + 1200k, ie 1700k.
2M sounds like a good compromise, and I'm going to propose this as a
standard default value *with the fixed DISTRIBUTE command processor*.
If you increase FILEMAXL you must increase all the above accordingly.
7) SUBSCRIPTION = LOCAL | NODES(....): you can use the SERVICE= LOCAL | nodes
keyword. I don't think we need to change the SUBSCRIPTION keyword.
8) CONFIDENTIAL= LOCAL | NODES... Hmm... What about making a list confidential,
ie not showing it on a LIST command, when the sender is outside the service`
area?
Will probably send more mail later.
Eric
|
