Jeff Kell posted a great run-down of topics covered at SIGMPE.

In glancing quickly at the list (I'm on lunch break from another class),
I notice only one thing missing:  the ability to specify a "default shell"
for a user.

If memory serves (and it may not), this will be done in two phases.

In the first phase, the goal is to help those few installations that
are just plain max'd-out of available processes.  CSY observed that
for those users who are locked into a menu (via a logon nobreak UDC
that runs the menu program, then automatically signs off), the CI
process is essentially wasted:

        jsmain -> CI -> menu

If the menu could be specified as a "default shell," then this CI
process could be omitted:

        jsmain -> menu

thus saving a valuable process number for something more useful.

Logon UDCs would still be executed, and CI commands would still be
available (e.g., from the COMMAND and HPCICOMMAND intrinsics), but
there would be no "active CI" for these users.  (Since the BREAK key
is handled by the CI, and the CI wouldn't be there, these forced-menu
users would implicitly be run as "option nobreak.")

Since logon UDCs would still be executed, and since the *existing*
logon UDC runs the menu program, these UDCs would have to be changed.
CSY acknowledges that this may be painful, but the customers who need
this feature REALLY need this.

I didn't follow what would be involved in the second phase of this,
but I *think* that's accurate for the first phase.


Also, Gopi asked for a show of hands for users currently taking
advantage of the new date intrinsics (from memory, this includes
HPDATEFORMAT and a few others).  Only a few people raised their
hands.

HOWEVER, I strongly suspect that if/when the ENCHILADA project
comes to fruition, these functions are going to be *essential*.

--Glenn "dashing back to class"

.......................................................................

Item Subject: cc:Mail Text