🚀 go-pugleaf

> > The macros (and CMS function) needed to be a good citizen were
introduced in
> > CMS 5.
>
> Was it, perhaps, also introduced as an add-on to CMS 4?
>
> > Once these changes are made Mailer will no longer work on releases
> > earlier than CMS 5.  I mention this here so that sites still running CMS 4
> > will be forwarned.
>
> If the only purpose for making the change is to allow Mailer to use an
> SFS disk, I'd have to ask, "Why bother?"  Mailer needs to have its "A"
> disk space reserved so that there is always room for the maximum allowed
> size mail file, but that maximum size isn't likely to change, so what's
> the point of using SFS?
>                                                  John

Some possible scenarios (running from something you might want to do today to
future considerations):

1.  It is now possible to specify that the 'userid FORWARD' files are stored
on a disk other than the A-disk. Assume I'm planning for 1000 user forwards
(most of my users are really on work stations but they have bitnet ids on the
IBM).  This requires atleast 2 cylinders of 3380 space (using 1K blocks).  But
I know I won't have 1000 user forwards today and I really don't want to
allocate that space (Yeah, I know 2 cylinders is a bad example).  So I place
the FORWARD files disk in the SFS.  Now I don't care how many forwards I have,
I just make sure that my maximum allocation is big enough to hold them all.
The disk "automagically" expands to meet my needs.

2.  Under ESA 1.1 (on a 390) some of the benchmarks report that it is slower
to write/read to a minidisk than it is to do the same to SFS.  In this
situation I may want my 191 disk to be in SFS.  This does two things for me.
It gets me the improved performance and (again) it gives me a disk that can
grow to fit the size of the mail file.  Now I can set a limit of 15,000 blocks
for my disk (approximately 150 cylinders of 3380 space).  Most of the time I
use a very small allocation from the SFS but when that big mail file comes
through I can handle it.

3.  There is no longer an obvious reason why mail should be dropped into
spool.  Delivery into a directory owned by the recipient may make a lot of
sense.

4.  If I can deliver mail into SFS then I can also access files in SFS that
the user has authorized me to access.  Having the FORWARD files maintained by
the mailer is kludgy.  Why not have them in a MAIL directory in SFS?

5.  Assuming SFS access to other programs, why not use a pipe to perform final
delivery and allow the user to specify filters in their FORWARD file?

6.  Add whatever exotica you can think of that becomes available once you have
access to files that a user creates without having to have passwords for
minidisks.  Especially in an environment where all of a users "minidisks" may
be migrated to slower access storage and restored at logon (system managed
storage is on its way).

Hope this gives an idea of why I think mailer has to atleast tolerate SFS.

   John