RE: Monitoring for MSGW

Folks,

Get over this fascination with outputting to spool files and converting
the spool files to a disk file and then processing that.
Crack open a book, STFW, something. Learning something new won't kill
you.
Think "API".

Problems with the spool file to disk file concept:
- processor and disk I/O inefficient.
- details are much more limited on spool files vs what is available via
the APIs
- jobs blow up when you reach max spool file entries per job.
- And the biggest reason? Read the Memo to User for ANY release and you
will see:
Output(*PRINT) changes
Release to release Output(*PRINT) considerations
Applications specifying OUTPUT(*PRINT) to generate spooled output from
commands must be able to
tolerate changes to the record layout in the spooled file. From release to
release, commands that support
that option can add, change, or remove records from the output. Any
application that has a dependency
on the record layout for a specific command might have to change.

I've had print format changes bite me in the butt when supporting multiple
releases and long ago stopped doing this.

Ok, with me coming unglued let me say this. In 15 minutes I am taking off
early for the day. This half day of "vacation" will find me:
- helping set up a going away party at my MIL for her son who is taking a
distant position for ministering
- helping with a concession stand for Unified Track. A team composed of
boys and girls with mental challenges and partners from general education.
Last time I helped them involved me going to the regional burn center.
- helping with a concession stand for football boosters
- football game
- getting there late to the camporee for boy scouts.

I'll feel better next week. Out.


Rob Berendt