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