Reusable Server Kernel

Problem 36 (Sug): SPOOL LD behavior with PUNCH format

=============== 2000-06-20 13:25:59 (-04.00) ===============
 
Name:        ** Suppressed **
Company:     ** Suppressed **
Telephone:   ** Suppressed **
E-mail:      ** Suppressed **
 
Text:
 
Today's /rsk/rskfix.vmarc suppresses the dumping of the
spool file content to the console.
 
It also adds a new CONFIG parameter, SPL_CATCHER.  The
value of this parameter is the user ID to which
undecodable spool files should be transferred.  If you
set SPL_CATCHER to * you get the current behavior, that
is, the file remains in the server machine's reader.
To transfer undecodable files to MAINT, for example,
code CONFIG SPL_CATCHER MAINT in PROFILE RSK.
 
Brian
=============== 2000-06-19 17:37:36 (-04.00) ===============
 
Name:        ** Suppressed **
Company:     ** Suppressed **
Telephone:   ** Suppressed **
E-mail:      ** Suppressed **
 
Text:
 
You up for a fix test, Dave?
=============== 2000-06-09 13:02:00 (-04.00) ===============
 
Name:        ** Suppressed **
Company:     ** Suppressed **
Telephone:   ** Suppressed **
E-mail:      ** Suppressed **
 
Text:
 
Forgot to mention that the patch alone (to remove the spool data
dump) would alos be a help, for the production level servers we're shipping.
=============== 2000-06-09 13:00:43 (-04.00) ===============
 
Name:        ** Suppressed **
Company:     ** Suppressed **
Telephone:   ** Suppressed **
E-mail:      ** Suppressed **
 
Text:
 
Yes, Brian, a simple (?) CONFIG statement that says 'transfer unprocess-able
spool file here' would work very well for us. Thanks.
We had one site that got this spool dump and raised a big fuss
because they thought we where just throwing away thier mail....:-)
=============== 2000-06-09 12:44:12 (-04.00) ===============
 
Name:        ** Suppressed **
Company:     ** Suppressed **
Telephone:   ** Suppressed **
E-mail:      ** Suppressed **
 
Text:
 
Dave,
The dump of the spool file to the console appears to
be an old debugging scaffold.  I think it would not be
too much difficulty to offer you a CONFIG parameter that
you could use to specify the user ID to which the RSK
should transfer the file.  If you didn't specify such
a user ID, the RSK would just leave the file in the
reader in HOLD state (which it does now, actually, after
making quite a bit of console noise).  Would this
proposal suffice?
It would be very easy for me to give you a patch that
would just suppress the dumping to the console.  How
much help would that alone be?
Brian
=============== 2000-06-09 11:51:12 (-04.00) ===============
 
Name:        ** Suppressed **
Company:     ** Suppressed **
Telephone:   ** Suppressed **
E-mail:      ** Suppressed **
 
Text:
 
Dave, the RSK accepts NETDATA (aka SENDFILE NEW) and
DISK DUMP (SENDFILE OLD).  You are right that the RSK
does not accept PUNCH.  I will look into it but it is
definitely not a high priority, unless you can demonstrate
a pressing reason.  BKW
=============== 2000-06-09 11:38:39 (-04.00) ===============
 
Name:        ** Suppressed **
Company:     ** Suppressed **
Telephone:   ** Suppressed **
E-mail:      ** Suppressed **
 
Text:
 
The RSK SPOOL line driver currently has the restriction that
it will only accept spool files that arrive in NETDATA format,
assuming that the spool file has the correct name and type.
If a spool file arrives that is in PUNCH format instead, the
RSK rejects it and dumps it's contents to the server's console.
This dump of the spool file can cause a great deal of confusion and alarm
at sites running a RSK-based server.
I would like to suggest an enhancement to the RSk that would
allow for the tailoring of the RSK behavior in such situations.
perhaps a new configuration statement in PROFILE RSK that would
allow for:
1) the current behavior
2) specify a VM user id where the PUNCH spool file could be
transferred for further analysis, with a warning message on
the server's console
3) invoke the registered SPOOL line driver, but provide it
with a flag of some sort so it could take the appropriate action.
The spool file id would be provided to the SPOOL service, as is now done, but no
actual spool data would be available.


[ Help | Summary | Previous | Next ]