🚀 go-pugleaf

We upgraded VMSCHEDULE from 4.0 to 4.3 this week.  Everything seemed
ok Tuesday afternoon, but when I came in on Wednesday morning I
discovered that VMSCHED had problems about midnight.  Unfortunately,
there were no entries on the VMSCHED console after 20:31 hours.
When I called Systems Center, they recommended that I make a minor
change to each request in the database so that the records would
all get rewritten.  Apparently some database records carried over
from old releases can be incompatable with 4.3.  I did this,
(using expert screens of course) and the change I made was to
the from date on the first run screen since VMSCHED insists
that this date be sometime in the future.

Everything ran ok on Wednesday night, but when I came in this
morning I again discovered that VMSCHED had problems about
midnight.  This time I had a good console and the problem
was an addressing exception.

The request that runs at midnight was created years ago via
the SCHED command and it scheduled CP SPOOL CONSOLE CLOSE
to be executed on the VMSCHED machine.  Systems Center says
that they are phasing out the ability to schedule CP commands
via the SCHED command and such a request will cause an
addressing exception.  Such CP (or CMS) commands must now
be in an exec which is scheduled using the exec screen.

Unfortunately, there is no way to detect that SCHED command
scheduled request of a CP command to be run on the VMSCHED
machine is being carried over from previous releases when
the upgrade is done.  Those of you upgrading from old releases
should check your databases.