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 ]