From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 6-MAR-1992 14:49:31.20 To: ARISIA::EVERHART CC: Subj: WordPerfect symbiont enhancement letter to DEC From: RELAY-INFO-VAX@CRVAX.SRI.COM@SMTP@CRDGW2 To: Everhart@Arisia@MRGATE Received: by crdgw1.ge.com (5.57/GE 1.123) id AA03642; Fri, 6 Mar 92 13:24:15 EST Received: From WUGATE.WUSTL.EDU by CRVAX.SRI.COM with TCP; Fri, 6 MAR 92 09:52:15 PST Received: by wugate.wustl.edu (5.65c+/WUSTL-0.3) with SMTP id AA23368; Fri, 6 Mar 1992 11:45:10 -0600 Date: Fri, 6 Mar 1992 11:45:09 -0600 Message-Id: <199203061745.AA23368@wugate.wustl.edu> From: robinson@wudos2.wustl.edu (Charles Robinson, Surgery [WUDS::ROBINSON]) To: "info-vax@kl.sri.com"@WUGATE.wustl.edu Subject: WordPerfect symbiont enhancement letter to DEC Since we had such an interesting string of messages going a few weeks ago about WordPerfect's use (or abuse, depending on your point-of-view) of symbionts, I thought this might be of interest. The letter was downloaded from WordPerfect's BBS, and is from Ray Whitmer, Senior Consulting Software Engineer for the VAX group. Charles Robinson ------------------------------------------------------------------------------- VMS SYMBIONTS CUSTOMIZATION ENHANCEMENT REQUEST As a result of design deficiencies in the LAT symbiont (and other PSM- interface-based symbionts), the CPS (DECPrint) symbiont, and the OA$FORMATTER background formatting symbiont of ALL-IN-1, WordPerfect Corporation (WPCorp) has been forced to use unsupported techniques of customizing symbionts. WPCorp has repeatedly submitted detailed descriptions of the customization techniques currently being used to DEC Engineers (as well as any interested users) and continues to plead with DEC in behalf of VMS users for enhancements that would allow WPCorp products to utilize a supported and more functional approach to essential print functionality under VMS. This document describes one of the most aggravating problems of printing under VMS, the inability to handle popular non-ANSI printers. Currently, this problem can only be solved via symbiont customization. In addition, related problems and features which also call for symbiont customization are discussed. The various DEC symbionts (including LAT and other PSM-interface-based symbionts, CPS, and OA$FORMATTER symbionts) and the design flaws that prevent most third- party symbiont customization are discussed. As the PSM deficiencies are discussed, proposals that would allow third-party customization of standard PSM-interface-based symbionts (such as LAT) to solve such problems are presented. General enhancements are proposed to the CPS/DECPrint architecture that would allow third-parties to provide solutions for that symbiont. These DECPrint architecture enhancements, if properly implemented, would eliminate the need for the proposed PSM interface modifications as well as unspecified OA$FORMATTER enhancement proposals. Also, WPCorp software work-arounds that could be eliminated with an adequate VMS symbiont architecture are described. THE MOST AGGRAVATING PROBLEM PRINTING UNDER VMS The most aggravating problem with VMS symbionts is the inability to handle popular non-ANSI printers. VMS symbionts destroy code sequences sent to non-DEC printers, and sometimes destroy code sequences sent to DEC printers. This problem causes the most frustration for users. According to DEC support, there is no perfect solution. The customer must only buy DEC printers and run them in ANSI mode (however, even output to DEC printers in ANSI mode has been corrupted). DEC recommends users print using the /PASSALL qualifier, to prevent the corruption of non-DEC printer output; however, using the /PASSALL qualifier produces an extra blank page with every print job. IS ANSI REALLY SUCH A STANDARD THAT VMS SHOULD EXCLUDE ALL OTHERS? DEC designed their symbiont for printers which use ANSI escape sequences. DEC argues that ANSI escape sequences are the industry standard for printers. WPS-Plus, for example, only uses ANSI printers and the symbiont performs better. Realistically, ANSI is too DEC-specific to be an industry standard. WPCorp, instead of supporting 20 or fewer printers, supports 800 different printers. Most of those printers are not ANSI. This number includes the HP Laserjet series as well as a number of less well-known laser printers that are more popular (and cost-effective) than DEC printers. These printers have many popular accessories and attachments, including collections of cartridges and downloadable bitmapped and scalable fonts. Who else uses ANSI? Not Tektronix, a leading producer of graphics terminals and standards. Not Hewlett Packard. Hewlett Packard's printer language is probably emulated by more third-party companies than ever thought of relying on ANSI escape sequences to drive their printers. Not IBM, usually. It is difficult to find printers besides DEC printers that comply with ANSI. PostScript is also non-ANSI, which is the reason DEC built a totally new symbiont around it. Even many DEC printers support alternative de-facto non-ANSI standards (with escape sequences that are corrupted by DEC). DEC terminals are also forced to support more-popular non-ANSI modes. DEC appears to assume that your printer should have severe problems when connected to VMS if the printer does not support ANSI. This position ignores every popular printer and word processor on the market, as well as a number of DEC printers. If VMS were an open operating system, it would allow reasonable use of non-ANSI printers like open operating systems, including DOS and Unix, do. Even the (non-ANSI) CPS symbiont has been built to only communicate with DEC Postscript printers, thus preventing the easy and open PostScript standard and restricting use to DEC hardware. DEC FORM CONTROL: BACKWARDS FROM THE START DEC's /PASSALL work-around generates an extra page at the end of each print job. If you examine a DEC-software-produced file that has internal form feeds (try a compiler, linker, or librarian listing among others), you will notice that DEC places form feeds at the TOP of each page rather than at the BOTTOM. The only printers that require form control at the beginning of a page are printers with sheet feeders, and because these printers generally use multiple bins, it is usually not a form feed that brings in a new page, and even then form control is required at the end of the page (this time a single code, frequently a form feed.) On most operating systems, proper placement of the form control is left to the software which knows how to drive the printer and places form control at the bottom of the page where it belongs. Even DEC printers work incorrectly when a backwards DEC file is directly copied to them. An extra blank page is generated at the beginning of the file, and the last page is not ejected from the printer. It is natural that when you use files produced by software that handles form control properly, that DEC symbionts will not know what to do with it. This is probably why the DEC symbionts force and extra form feed at the end of the /PASSALL job. Even backwards DEC files print an extra page with /PASSALL, but the extra page appears at the beginning of the job instead of the end because the extra form feed protection is lost with /PASSALL. VMS users find the extra page intolerable. This same problem persists when running non-WPCorp applications, especially when non-VMS applications that produce proper form control are forced into the VMS nightmare, via PCSA for example. THE REMAINING SOLUTION TO THE CORRUPTION OR EXTRA PAGE DILEMMA The only remaining solution to this problem seems to be to customize the symbiont using the DEC modifiable symbiont protocol to disable and bypass the improper behavior of the VMS symbiont. OTHER PROBLEMS REQUIRING SYMBIONT CUSTOMIZATION While the CPS symbiont doesn't currently exhibit the biggest problem exhibited by LAT and other PSM-interface-based symbionts (the corruption of codes or the extra page), these symbionts have other bugs in common with the PSM-based symbionts. They also lack essential features that can only be supplied by third-party symbiont customization. CHECKPOINTING PROBLEM -- SOLVED BY PRINT-TIME TRANSLATION Checkpointing means that if you queue a 200-page document and your print job is interrupted at page 100, when printing resumes the job will begin printing where it left off and only a few pages at most will be duplicated. Checkpointing relies on ANSI form feeds so that you always restart at the top of a page. But non-ANSI printers may use the ANSI form feed code everywhere except where there really is a page break. The CPS symbiont gives up altogether on checkpointing. Although the CPS team apparently believes checkpointing on a PostScript printer is impossible, it is actually a trivial operation when it is done by a translator invoked as the document is printed. The WPCorp translator always knows when it begins a new page. This allows checkpointing to work for non-DEC printers that don't share DEC's form control protocol. The WPCorp translator can also properly checkpoint when sending pages to a PostScript printer and then restart at the checkpoint by sending the required PostScript header again. Also, if a job is interrupted in an incomplete state, the symbiont can clean up the state of the printer. The VMS symbiont that is not customized, on the other hand, has no way of knowing the current printer state, what state might be acceptable, or how to get the printer to that state. ACCOUNTING PROBLEM -- SOLVED BY PRINT-TIME TRANSLATION The knowledge of how many pages were printed makes accurate printer accounting trivial. Many companies place great emphasis on using printer accounting records so that the appropriate department or user can be billed. Because the symbiont expects ANSI, it counts form feeds again, which doesn't work any better for accounting than it did for checkpointing. The WordPerfect translator, on the other hand, knows when a new page is being started regardless of the printer type, if the translator exists inside of the symbiont. It also knows EXACTLY how many pages were translated and printed successfully and the user is charged for that amount, not for a 1000-page job if only one page printed before interruption. And not for 1 page if 1000 were printed, which is the current behavior with the /PASSALL qualifier. PRINTER MANAGEMENT -- IMPROVED BY PRINT-TIME TRANSLATION There are a number of printer resources and states that must be managed on printers. For example, a downloadable font, if used by many print jobs in a row, should only have to be downloaded once. WordPerfect printing allows different print jobs to rely on different initial states. Before the first job prints, the printer is automatically initialized to the proper initial state. If the next job requires the same initial state, it is not necessary to download the fonts again or reset the printer. But if another job requires a different state of the printer, the printer is initialized to that state and then returned to the original state when another job requires it. Also, when the print queue stops and starts, it is assumed that the printer has been off-line and will need its state restored. This functionality compliments the checkpointing and state cleanup previously described. The WPCorp symbiont already has much of this intelligence built-in, and such support will be expanded by WPCorp as time goes on. On the other hand, if software simply sends pre-formatted files that rely on the printer state, there is know way to no that the previous job didn't destroy the printer state. Even if the document is sent immediately following the job which initializes the printer, it is impossible to know what other jobs might have come between print jobs destroying the printer state. MANUAL PRINTER FUNCTIONS -- SOLVED BY PRINT-TIME TRANSLATION A number of printers or organizational procedures require the print job be paused in the middle for manual intervention. Sometimes a print wheel or cartridge must be changed to use a different font, a government procedure might require a carbon be destroyed at a certain point in printing, or it may be desirable to change paper or manually insert a page or envelope into a manual form slot. These and other requirements can only be fulfilled if the translator has control during the physical spooling of the document. DOCUMENT SECURITY -- ENHANCED BY PRINT-TIME TRANSLATION WPCorp also provides a document encryption feature. If print interpretation is done into a file which is then forwarded to the print queue, the entire contents of the encrypted file exist on disk in an un-encrypted form where it is much more vulnerable. If the translation and decryption are done at print time, an un-encrypted representation is never written to a disk. BACKGROUND PRINT FORMATTING IN ALL-IN-1 Background print formatting is an extremely important printing feature. Under ALL-IN-1, the only way to accomplish background print formatting of messages that contain mail headers, WordPerfect, and WPS-Plus attachments without losing features is to integrate WPCorp processing into OA$FORMATTER. For ALL-IN-1 users, integrating WPCorp processing into OA$FORMATTER is better than no background formatting at all, which is what is available without integration into this symbiont. So WPCorp must be able to customize OA$FORMATTER or its equivalent. BACKGROUND FORMATTING WITHOUT A BACKGROUND FORMATTING QUEUE Many non-ALL-IN-1 users (and maybe ALL-IN-1 users as well) dislike the concept of background formatting via a background queue because it is cumbersome and can bottleneck (but WPCorp background formatting is provided for those who can tolerate it). Many prefer to have formatting or translation accomplished in the destination queue symbiont as the actual printing is taking place (like the CPS symbiont does it for ANSI, ReGIS, or TekTronix files). This requires symbiont customization as well. PRINT-TIME TRANSLATION AND BACKGROUND FORMATTING REQUIRE THIRD-PARTY SYMBIONT CUSTOMIZATION These solutions and many more are easily provided via print-time translation of WPCorp documents. But only WPCorp can provide a translator for WPCorp documents. Essential WPCorp printing information is lost, for example, by a CDA translator. It follows that print-time translation requires third-party symbiont customization so that third-party translators may be provided. If VMS were an open operating system, it would support this customization which is essential both to third-party printers and third-party printing software. VMS was more open in the past, allowing symbiont modification to a greater degree than it does now. Now, the LAT and other PSM-interface-based symbionts, CPS, and OA$FORMATTER symbionts which can't be customized have become the standard symbionts. It is difficult, for example, to print properly to a LAT port without the LAT symbiont. DEC has made it impossible to print to LPS printers without the CPS software or to accomplish background printing of ALL-IN-1 mail messages (with varied headers and attachments) without OA$FORMATTER. Third-party symbiont customization capabilities must include all of these symbionts and more. How can WPCorp duplicate the output routines required for the LPS40 and require sites to stop using the CPS symbiont (whose exact behavior is not only a guarded secret, but in some cases patented by DEC)? THIRD-PARTY CUSTOMIZATION OF LAT AND OTHER PSM-INTERFACE-BASED SYMBIONTS When designing the PSM symbiont customization architecture the VMS engineers missed the simplicity and flexibility of other operating system customization architectures. Although the VMS symbiont was supposedly designed to be customized (to solve problems like these), important coexistence features which are essential to a customization scheme were left out of this architecture. PSM CUSTOMIZATION PROBLEM #1: CALLING THE REPLACED ROUTINE DOS interrupts, for example, are the way Microsoft provides to customize various aspects of DOS. Programming the PSM interface is much like programming DOS interrupts but without several important architectural features. Unlike the PSM interface, when a DOS program replaces a standard DOS interrupt, the program keeps track of the chain of all other software which also wants to receive the same interrupt to perform the same function. As with a DOS interrupt, when the WPCorp symbiont is not printing a WPCorp job, it must be able to call the original replaced routines. Further, like DOS interrupts, the same replaced PSM routine is called for numerous sub-functions. The replacing routine may need the original routine to handle part or all of the sub-functions which it cannot or should not replace under certain circumstances. PSM CUSTOMIZATION SOLUTION #1 Although the PSM RTL has easy access to the address of the routine being replaced via the PSM$REPLACE routine, it gives the program absolutely NO way to know what routine is being replaced so that that routine can be called when required. It would be simple to have the PSM$REPLACE routine return this information to the program. PSM CUSTOMIZATION PROBLEM #2: DIFFERENT FUNCTIONS PROVIDED BY DIFFERENT PROGRAMS When a DOS program controls one interrupt, it has no effect on other interrupts. Different programs may control different interrupts, different sub-functions of the same interrupt, or even different stages of the same sub-function. The PSM interface, on the other hand, not only prevents the replaced routine from calling the previous routine, but also prevents replacement of multiple unrelated routines by different programs. PSM routine replacement may only be done by a SINGLE program. So, if a symbiont is created to output via some communications method other than the one supported by standard PRTSMB (like TCPIP), the symbiont prevents another program from making necessary modifications to input or format routines. This completely prevents third-party symbiont customization. DEC further aggravated the situation by moving to LAT rather than physical serial ports as the de-facto standard without providing those output routines where they would available in SMBSRVSHR. This effectively eliminated ALL possibility for third-party printing symbionts. While DEC argues that each third party may write its own LAT output routines, this is not realistic. Originally the required LAT protocol was not documented. WPCorp actually wrote a LAT symbiont which, at the time, was superior to the DEC symbiont; however, details of the protocol changed so often, that it was and is nearly impossible to create a single version that worked well with all versions of VMS. Both the LAT driver and DEC's LAT symbiont changed again under VMS 5.5 in a synchronized release with major changes. WPCorp software is not shipped with VMS so such synchronizations are impossible. Providing private third-party LAT routines is not practical. Even if it were, it would be necessary to also duplicate every other possible output routine devised by DEC or others. How can WPCorp duplicate the output routines required for the LPS40 and require sites to stop their use of the CPS symbiont (whose exact behavior is not only a guarded secret, but in some cases patented by DEC)? PSM CUSTOMIZATION SOLUTION #2 It would be simple for DEC to allow the setup for multiple independent symbionts to be co-initialized via shareable RTL routines within the same symbiont process. Combined with the returned address of information on the routine being replaced, this would allow third- party symbiont customizations to the DEC-supplied LAT symbiont as well as other PSM symbionts. Simply allow a list on the qualifier: /PROCESSOR=(LATSYM,SMB2,WPSYMB, ... etc.) and cause PSM$PRINT to look in each symbiont after the first one for a designated symbol name and call that initialization routine of each image, one after another. This would mean WPCorp software would no longer have to redefine SMBSRVSHR to accomplish the same multiple-initialization feat. PSM CUSTOMIZATION PROBLEM AND SOLUTION #3: REPLACING MAIN_FORMAT The PSM customization architecture does not allow the PSM MAIN_FORMAT routine to be replaced. This routine causes most of the problems within the DEC symbiont, and must be replaced in order to make printing occur correctly (other problems include improper checkpointing, accounting, and the list goes on). DEC must allow replacement of this routine and its functionality. PSM CUSTOMIZATION PROBLEM #4: COEXISTING WITH CO-ACTIVE SYMBIONTS The standard DEC PSM-interface-based symbiont has too many interdependencies between different sub-functions. For example, start_task opens the input file closed by close_file. Most programs would expect open_file to open the file. If someone decides to only replace open_file, read_file, close_file and associated cancel routines, the file is left open because the stop_task didn't clean up everything initiated by start_task. Each start_task request should examine the task and identify which sub-functions will be intercepted/blocked by that replacement routine and which will be passed to previous routines. PSM CUSTOMIZATION SOLUTION #4 This situation can easily be addressed by adding a parameter to the start_task sub-function of each replacement routine which points to a longword mask with one bit representing each sub-function. Each stage checks the bits to make sure that the pre-empting/blocking routine will be calling back for at least the minimal set of sub-functions required for that replaced routine. Additional flags representing the sub-functions preempted/blocked by the current replacement routine for the current task would be set before calling back to a previously- replaced routine. The routine provided by the last processor in the list is first to receive control and pre-empt other routines of the same function declared by other processors. PSM CUSTOMIZATION ADDITIONAL PROBLEMS AND SOLUTIONS The PSM routines additionally manage other features such as checkpointing, accounting, and job status reports. These features are not properly handled by the PSM MAIN_FORMATTER and are not accessible to the replacement routines which are capable of properly manipulating these fields. Easy access could be provided via additional arguments to the (replaced) MAIN_FORMATTER routine, or new utility routines. PSM CUSTOMIZATION ENHANCEMENTS PROVIDED WITHOUT DIFFICULTY These proposed PSM interface changes represent functionality which has already been accomplished by WPCorp when using the PSM-based symbionts. The enhancements are simple to implement and would make VMS printer support more open. Supporting the features is a little more work than implementation. But the fundamentals of PSM symbiont architecture remain unchanged. WPCorp would be happy to discuss perceived obstacles with any VMS software engineer. However, it isn't necessary to implement these proposed PSM enhancements if DEC implements essential CPS/DECprint architecture enhancements in a timely fashion, such that DECPrint can become the symbiont architecture of the future. CPS (DECPRINT) AND OA$FORMATTER CUSTOMIZATION PROBLEMS Like the LAT symbiont, DEC has made it impossible to integrate WPCorp translation/processing abilities into the CPS or OA$FORMATTER symbionts. Both of these symbionts use the SMB symbiont interface rather than the PSM interface, and both symbionts perform translation functions which are extremely important and MUST be customizable by WPCorp. Currently, the CPS/DECPrint symbiont does not support translation into anything besides DEC-printer-only PostScript. Replacement of the output module is completely impossible. Good access to the $SNDJBC parameters of the job is prevented. CPS (DECPRINT) AND OA$FORMATTER CUSTOMIZATION SOLUTIONS The following enhancement list might provide a basis for a usable DECPrint architecture for the CPS symbiont. Once the CPS architecture is enhanced, it could also easily form the basis for OA$FORMATTER queues. If designed properly, OA$FORMATTER queues could be abandoned in favor of translation modules capable of translating WPS-Plus, mail headers, CDA, and other attachments. A general background formatter could still be provided for all products. This background queue would not need to be specific to ALL-IN-1. It would be usable when reduced print-time functionality, potential formatting bottlenecks and complex configuration was not too high a price to pay for all-out printer throughput (not slowed by VAX translation processing). This list is neither complete nor properly prioritized. I. Translation Module Interface A. Not restricted to translating to PostScript. B. Easy to designate translator capable of translating to multiple formats (like current WPCorp translator module which translates to 800 formats). C. Unrestricted access to all $SNDJBC information. D. Unrestricted and reliable access to main input file being translated (current DECPrint provides very limited routines instead of just providing name or file ID and allowing module to do its own input). E. Ability to queue multiple main input files requiring different input translators as well as different print parameters as parts of the same job. F. Ability to recognize and utilize translator-specific print parameters information while ignoring parameter information for other translators or print stages. G. Unrestricted, reliable, and secure access to external files referenced by main input file being translated (this list has to be checked and managed by $SNDJBC and then provided to input module just like the main input file). For example, the WordPerfect document header references a printer type profile and external graphics files which must be located, access verified, and sent with the job to the symbiont, which is unable to either locate the external files or verify that the user had access to them. If the other aspects of the interface are adequate, this functionality may be obtained without explicit support if the other aspects of the interface are adequate by submitting all externally-referenced files as specially-tagged input files immediately preceding the real main input file. H. Ability to flush output pipeline so that reliable checkpointing and accounting may be performed. I. Ability to record pages printed for accounting purposes and record private checkpoint information. J. Ability to manage fonts and other printer resources, preferably between competing input translator modules, so that the printer state is always known and redundant downloading and initialization is avoided. K. Ability to request resources or actions which may require pausing of the queue and manual operator or job owner intervention. L. Ability to provide requested translation interruption cleanup to restore the printer and managed resources to a known and acceptable state. M. The current ANSI-based PSM interface should be abandoned, in favor of the CPS symbiont with an ANSI to ANSI module, which should be just as capable as the ANSI to PostScript or PostScript to PostScript modules. N. Any translation or input module must be free to translate input- related Job Control print qualifiers and functions in the appropriate way given the input and output formats. II. Printer Communications Module A. Ability to allow each output connection provider to provide own module (DEC provides LAT, PostScript LAT, and PostScript LPS40, while others provide TCPIP, FAX machine, and other output routines). B. Ability to declare a single output module for a queue which is fed by multiple translator modules. C. Bi-directional communications possibility with ability to declare reported printer states back to DECPrint so appropriate actions can be taken (this is especially important for PostScript printers, but is also useful for other printer types) III. Filter modules A. Filter modules might be important to allow a minor function to augment/co-exist with a primary input routine (like to provide the CPS Number-Up function regardless of which input translator is active) and to modify the way the translator and communications modules communicate with each other. IV. Multi-threading and other features might be nice. These features are all quite important for the future of print spooling. Many features could be added to the list. If this translation interface was not adaptable to OA$FORMATTER (it really eliminates the need for it if done properly) then a solution for ALL- IN-1 background formatting is still badly needed. Actually, if the CPS symbiont were implemented correctly, there would not be a need for OA$FORMATTER, the LAT symbiont, the standard PSM symbiont, or the requested PSM modifications. ONE ALTERNATE PROPOSAL (PROBABLY NOT EFFECTIVE) I present one alternative proposal which appeared totally inadequate to the problems at hand: the creation of a print symbiont metafile with a control language allowing all functions required by advanced symbionts including manual intervention, checkpointing (difficult for PostScript with a metafile), resource management (similarly difficult), accounting, encryption (difficult with a proprietary encryption scheme, but if DEC provided standard encryption with VMS it might be feasible), cleanup (difficult but not impossible with a metafile), and so on. DEC would have to implement all important print-time features that any third-party needed, designing the language and its interpretation support into every symbiont (not an easy task). A metafile would also fail to address ALL-IN-1 background formatting or background formatting within the destination queue. WPCORP SOFTWARE CURRENTLY ADDRESSES THE VMS SYMBIONT DEFICIENCIES The following is a description of how WPCorp met the printing requirements of the symbiont without the modifications/enhancements from DEC. CURRENT WPCORP PSM CUSTOMIZATION SOLUTION #1 PSM$REPLACE does not provide a way to find out the address of the routine replaced so that it may be called if the replacement routine doesn't apply. The routine has the address of the table in R2, but there is no way for the caller to get this value back. WPCorp created a routine which establishes LIB$SIG_TO_RET as a condition handler, which conspicuously does NOT save R2 in its register mask, and then calls the routine with a bad replaced-routine code (0). This causes the routine to exit with R2 intact. The PSM$REPLACE routine is so simple, that this solution is very reliable, and has worked for 4-5 years of VMS releases (including VMS 5.5) without any problem. With the address of the table, any routine address may be accessed. The index into the table is simply the PSM$K_xxx routine code, where each entry takes up 8 bytes (the high 4 bytes contain flags). CURRENT WPCORP PSM CUSTOMIZATION SOLUTION #2 WPCorp created a shareable image with many transfer vectors -- at least as many as the original SMBSRVSHR. Instead of transferring control to WPCorp routines, most of these transfer vectors transfer control to the corresponding offset in the real SMBSRVSHR (or the next RTL masquerading as SMBSRVSHR). WPCorp printing defines the SMBSRVSHR logical to point to the WPCorp RTL. This, by itself, should affect nothing. All calls into the WPCorp RTL still be made in the DEC RTL. The PSM$PRINT routine in the WPCorp RTL is then modified to perform WPCorp symbiont initialization (via PSM$REPLACE) before calling the real PSM$PRINT. CURRENT WPCORP PSM CUSTOMIZATION SOLUTION #3 WPCorp replaces the main format routine via the same direct access to the table engineered to solve the first PSM problem (which in the case of MAIN_FORMAT allows WPCorp to get the address of the original routine to call when not printing WPCorp documents). There is also one variable which WPCorp accesses in DEC's PSM workspace which tells WPCorp that the input to be filtered in main format came from main input. On all versions of VMS from 4.4 to 5.4, this variable stayed put. But in VMS 5.5 it shifted 20 bytes so that the MAIN_INPUT code was no longer seen and the original mucking-up routine was always called, even if it was WPCorp input. Code corrections were required for VMS 5.5 so that the symbiont could continue to skip main format for WPCorp file input. (The code now works on both systems, and a patch is available). CURRENT WPCORP PRINT PARAMETER CONFLICT AVOIDANCE DEC already sits on P1-P8 and blows up if anyone else tries to pass anything inside of their CPS symbiont. WPCorp also found that different files require different tags and parameters within the same job. WPCorp decided to use the /SETUP qualifier (also of greater maximum length) to pass parameters and replace the FILE_SETUP routine to interpret the parameter and, if it is a WPCorp tag, prevent the standard PSM routines from using the value. Unlike DEC, WPCorp ignores values that are not explicitly tagged for the WPCorp symbiont. CURRENT WPCORP PSM CUSTOMIZATION - ADDITIONAL SOLUTIONS The PSM interface interferes with a number of SMB features that it mishandles and prevents a user-modified symbiont from correcting. One of these features is page accounting. WPCorp code always knows exactly how many pages it has sent to the printer. The symbiont, on the other hand has no way of accurately assessing this for most laser printers, postscript included. At another workspace offset (which didn't change with VMS 5.5) there is a descriptor of the area where PSM tracks this, so the WPCorp symbiont can correct it before it is reported to the accounting system. WPCorp Customer Support received many support calls on this before it was corrected by directly accessing the undocumented PSM workspace. Checkpointing is another feature which caused problems. The PSM routines were inadequate, because they were called at the wrong times and had other limitations. Under the 5.0 version of the symbiont, the WPCorp symbiont accessed the stream id from the PSM workspace and directly called the lower-level SMB$SEND_TO_JOBCTL to report WPCorp private checkpointing. That caused certain problems for the older version of the LPS symbiont which disabled all AST's while it was executing, causing every SEND_TO_JOBCTL to pile up another undeliverable AST against the quota. Since JOB CONTROL was also a bottleneck on the system, in the 5.1 version, WPCorp abandoned that approach and does private checkpointing in a private file. More details on this can be provided. HOW WPCORP SOLUTIONS SURVIVED VMS 5.5 This change to checkpointing was just-in-time because the address of the stream id shifted by 20 bytes in VMS 5.5. (A patch is available for pre-5.1 versions running on VMS 5.5.) Private checkpointing was a very good decision. Another thing that changed in VMS 5.5 was the number of registers in certain entry masks that were intercepting calls for the real SMBSRVSHR. All registers should have been saved in all masks, but instead the current SMBSRVSHR masks were duplicated. Certain SMB$ routines added registers to the mask in VMS 5.5. (The patch corrects this, too.) Now all registers are always saved. HOW WPCORP SOLUTIONS SURVIVED FROM VMS 4.4 TO VMS 5.4 WPCorp has always offered alternatives to integration but they have not been well received by most users because important functionality was lost. Most system managers are dissatisfied with the printing problems (which DEC created). The latest release of WordPerfect 5.1 offers additional alternatives, but still lacks the full functionality which is only obtainable in the destination symbiont. While DEC frequently suggests that system managers should permanently deassign the SMBSRVSHR logical, WPCorp support operators often find that a site's new printing problems originated when they deintegrated their printing. While there have been a few complaints about SMBSRVSHR redirection, a larger number of complaints have been received when WPCorp FAILED to integrate with a new symbiont that DEC or a third-party provided, and users were forced to use the alternative solutions. WPCorp product sites that had trouble with VMS 5.5 (before the patch and fix-up for DEC's own SMBSRVSHR logical redirection) commented that non-integrated (no SMBSRVSHR redirection) printing had too many problems to be a useful alternative. This is why integrated printing is the default. While there are some system managers who can and do live without integrated printing (especially those using only certain DEC or PostScript printers), there are more who can't live without it. CURRENT WPCORP CPS CUSTOMIZATION SOLUTIONS The solutions to the SMB symbiont problem is easier than the solution for the PSM symbiont. The WPCorp intercepts SMB$READ_MESSAGE just like PSM$PRINT is intercepted. The intercepting routine first calls the real SMB$READ_MESSAGE routine, then, before returning, examines the read message. If it isn't about a WordPerfect file, the routine returns without further special processing. If it is about a WordPerfect file, the routine performs additional processing required to translate the WordPerfect file. The message being returned to the caller of SMB$READ_MESSAGE is then modified. This solution is targeted towards the CPS symbiont. It defers the real processing of the file to TRN$WPCORP_PS, but saves away many important qualifiers found in the message for later use. CURRENT WPCORP OA$FORMATTER CUSTOMIZATION SOLUTIONS A variation of the same approach is used to intercept OA$FORMATTER WordPerfect files. In this case, all processing is done in SMB$READ_MESSAGE. THE APPROACH USED IN OA$FORMATTER HAS NOT BEEN RELEASED YET. THE SYSTEM MANAGER'S OPTIONS As always, a system manager has the option of not integrating, but a majority of systems managers are unaware of the integration (although it is documented). They never have problems. All they know is that they print and IT WORKS. For system managers who fear the integration or can't use it for some reason, a background queue may also be used with non-integrated printing. This produces a final-form file, subject to all of the VMS bugs and deficiencies. WPCorp supports background formatting with integrated printer control via an intermediate file with explicit symbiont commands which preserves some functionality while removing major processing from the destination queue. This requires the integration. The background queue is most effective for sites with a high-volume printer to prevent the printer from becoming bottlenecked by translation processing. This background queue is also incapable of formatting All-IN-1 mail messages with multiple attachment types, because it has no ability to format non-WordPerfect documents or headers. This is really a superficial technical document. I would love to discuss any piece of it in detail. I probably left out major considerations of the SMBSRVSHR redirection. Please do not hesitate to call. Thanks, Ray Whitmer Senior Consulting Software Engineer VMS Platform Products WordPerfect Corporation Mail Stop B320 1555 N. Technology Way Orem, Utah 84057 (801)222-5525 or (801)222-5502