I'm very busy right now completing the migration to VM/SP 4, which includes
installing toys like GDDM4, finding out why the heck CATIA V2R2 *still* does
not work when trying to visualize project documents and to convert them to 4250
format, etc.
The following problems have been fixed:
- Error 24 from CARD on an INFO command.
- Error 32 from PUNCH on a GET LISTSERV FILELIST F=Punch (due to a missing
FINIS --> the file appeared to be lrecl 73...)
- Marc's mail-jobfile problem, due to my changing an EXECIO 0 CP (STRING to a
Call Diag 8 which altered the 'result' variable.
- The UMASS problem.
- Kent/Scott's distribution problem, due to the dreaded 255 chars limit on
GLOBALV. LISTSERV is growing and this becomes more and more of a problem...
- The multiple replies to the PUT command is hopefully solved.
- Nick's suggestion about including a blurb on the SET NOACK command in the
intro mailform.
Card/Netdata/Disk argument:
- Obviously DISK is a very poor solution. Each 80 chars line contains 50 bytes
of data and 30 bytes of junk. DISK should be banned from the network.
- Netdata is acceptable although it generates a lot of fixed-size garbage.
- Valdis, you can write lrecl = 1M records under VM.
- Card is ok, better than Netdata, *but* it's not an IBM standard format, there
is no documentation on the format (nor is there any about Netdata, I know),
and, last but not least, it tends to dump a file by *blocks* not records.
This is ok except that the garbage at the end of the last block of the file
gets transferred along with the rest. You have typically 3-5 lines garbage
at the end of the card deck...
I've been working on a DMSFREE hack to speed up LISTSERV (and any REXX program
for that purpose). It is able to allocate/free storage in about 30-40 assembler
instructions, counting the LM/STM and everything else, for a few remarkable
sizes which are used *very* often (eg 4,8,10,17,22 doublewords). It doesn't
work as I wanted. Two problems:
1) Storage keys are different for NUCLEUS and USER calls. Can be solved by
defining two different pools obtained in two different ways. Not a big
problem.
2) Some |"%$!$%!$ programs release via SVC a chunk of storage they have obtai-
ned via BALR. This is lethal to my 'intercepter'. You can FRET via BALR
something you've obtained via SVC without problem, though. There just is no
solution but to trap SVC calls to, preferrably without having to store in
CMS... which looks like it's just impossible unless you trap the SVC PSW and
add your 5-6 instructions/SVC overload... *sigh*
I became very tired after that and decided to take some vacations from this
program. I'm now working on a program that places disk directories in a shared
segment for SEVERAL disks, not just the 190 and 19E. We have a lot of public
disks and will have very little temp space on our new system with 2*3375.
Eric
|