ftp.robelle3000.ai 2014/2014.06.ftp.robelle3000.ai.tar/ftp.robelle3000.ai/newsletter/1989/w1989-02.txt

Text File | 1999-04-28 | 28KB | 505 lines

         What's Up DOCumentation



        Robelle Consulting Ltd.
        8648 Armstrong Rd., R.R.#6
        Langley, B.C.  Canada V3A 4P9
        Telephone: [phone]  Telex: 04-352848
        Fax:  [phone]

 Date:  March 8, 1989
 From:  Robert M. Green, President
        David J. Greer, Research & Development
        Michael C. Shumko, Customer Support
 To:    Users of Robelle Software
 Re:    News of the HP 3000, 1989 #2

      What You Will Find in This News Memo:

        News Tidbits
        Technical Tips
        Mental Migration, Part 2, by Jeff Kell
        Introducing Barbara Janicki
        Robelle Products:  Problems, Solutions, and Suggestions


                                 News Tidbits

 Contest Reminder.  The cutoff for sending programs to the INTEREX Contributed
 Library is about April 15th, if you want your program to be eligible for the
 amazing Robelle Prize:  $2500 to the best program submitted this year (and
 Bob Green picks the winner).

 San Francisco.  Robelle is pleased to announce that we are hosting another
 customer party.  Monday, September 11th at 7 PM, we will take you on board a
 beautiful Hornblower yacht, "City of San Francisco", for a cocktail cruise of
 the bay.  Buses will transport guests from the San Francisco Hilton Square
 and the Ramada Renaissance Hotel to the dock from 6:30 pm.
 The yacht will only hold 750 guests, so make sure you pick up a ticket from
 the Robelle booth (#340/342) between noon and five Monday.  Limit of two
 tickets per customer.  You must have a ticket to board both the bus and the
 yacht.  After the tour, buses will be waiting to return you to the Hilton and
 Ramada Hotels.

 Reach Out and Bite Someone.  Having recently suffered a disastrous severance
 of its East Coast fiber-optic cable system, AT&T is making sure the same
 thing doesn't happen to TAT8, the transatlantic fiber-optic cable that went
 live last week.  The big threat at sea is sharks, which for some unknown
 reason find fiber-optic cable extraordinarily toothsome.  So AT&T had its
 research and development subsidiary, Bell Laboratories, develop
 Fishbite-Protection cable, which now protects TAT8 in shark-infested waters.
 [ComputerWorld, Dec. 19, 1988]

 Data Loss and Worse.  Some wallets and purses are being manufactured with
 magnetic closures.  The intent is good:  wallets can be closed without any
 fumbling with the clasps.  Should you own an item with these closures,
 obviously you have to avoid carrying diskettes in your purse where entire
 files could be turned into pudding.  But think about your credit cards: on
 their reverse side is a little black stripe.  That's a magnetic stripe.  Let
 it jostle against your wallet clasp, and no bank machine in the world is
 going to give you money.

 Workstation Configurator.  Charles Newman reports that HP's Workstation
 Configurator product is now free with MPE.  Just call HP and ask for it.  You
 will have to pay for a manual if you want one.

 Discount for Robelle Users.  Cumulus, the 3rd-party CRT that emulates a
 700/92 and a 700/94 at a lower price with a bigger display and a five year
 warranty, are now shipping 1200 units a month.  Robert David at Cumulus has
 offered a 5% rebate to any Robelle customer in the US who orders before May
 30th.  [phone].  Be prepared to come up with a Robelle invoice.

 100 QEDIT Customers in Scandinavia!  Ole Nord AB announces that they now have
 more than 100 customers for QEDIT in Scandinavia.  Customer number 100 was
 Carelcomp in Finland, a software house.  As a thank you, Robelle and Ole Nord
 AB gave Carelcomp a copy of SUPRTOOL.  Together these 100 customers represent
 nearly 200 QEDIT installations.  Ole Nord AB is located at Strandvagen 39,
 191 45 Sollentuna Sweden, Tel [phone].

                                Technical Tips

 How To Keep A Base Open? Vladimir Volokh passed on this tip to us.  You may
 want to keep any base open all day artificially, if that base is frequently
 opened, then closed, by users.  The first accessor always pays a heavy
 performance penalty in DBOPEN.  Use this job to keep CUST.BASE open until you
 do an ABORTJOB:
     !job keepopen,mgr.useracct/pass,pub;outclass=,2;hipri
     !build suspend;msg;temp;rec=-80,,,ascii
     !run query.pub.sys
     base=CUST.BASE
     ;
     1
     xeq suspend
     !eoj

 Spectrum Surprise!  You are running QEDIT on your new 925 and you want to go
 into VISUAL mode.  Instead of typing VI, you type CI by mistake.  All of a
 sudden, you have launched a new Command Interpreter from in QEDIT, with a
 regular MPE XL prompt and everything!  You think you have been kicked out of
 QEDIT, so you enter QEDIT again (nested this time).  You can't edit your file
 because it is 'busy'.  Workaround:  EXIT from the second QEDIT, EXIT from the
 CI and you are back in the original QEDIT.  [Margarite Way]

 PCLINK Version.  To find out the version number of PCLINK, the file transfer
 program for Reflection, try RUN PCLINK.PUB.SYS,VERSION.  If that doesn't
 work, try RUN PCLINK.PUB.SYS;PARM=1.  You should see something like #A&
 @M#@#a1.20# 5.168C#@ where 5.168 is the version.

 QEDIT Versus HPToolset.  Gunnar Fredlund sent in this comparison of QEDIT and
 Toolset (HP's veteran "extra-cost" screen editor, not to be confused with the
 new HP Edit):  "This example shows a comparison for a project involving three
 programmers and a total of 42 Cobol and Pascal programs."
                                Toolset             QEDIT
 Disc space for source code    65,000 sectors      5,400 sectors
 Compilation of typical COBOL program  120 seconds  48 seconds
    For large Cobol programs, it was faster to exit Toolset, compile and
    start Toolset again than compile from Toolset.
 Environment                   One workspace for   QEDIT used for all
                               COBOL, one for Pascal,  COBOL, Pascal,
                               Editor for Job streams,  Job streams and
                               and Macintosh for doc.   documentation.
 Several programmers           A workspace needed  All code shared,
                               per programmer,     no duplication.
                               duplication of code.
 Renumber and Screen editing   The new screen shows  The new screen
                               new line but same   shows same line,
                               line number!        new line number.
 Add code in full screen       Run out of line     Handles a lot of lines.
                               numbers after a few lines.
 We always use separate development and production accounts.  This is trivial
 using QEDIT, but caused us some problems using Toolset; it is impossible to
 copy a whole Toolset environment from one account to another because some
 file names cannot be changed." [Gunnar]
 Gunnar Fredlund is the president of Nord Software in Santa Barbara
 California, a software consulting firm with extensive experience in HP 3000s.
 Telephone:  [phone].

 What If...  "I get my best ideas in the shower, but I forget them by the time
 I get out."  A common complaint.  But here's an idea: keep a microcassette
 recorder in the shower, in a Ziploc-type bag.  An alternative: mount a
 write-on/wipe-off board in the shower.

 Predictive Support.  You don't necessarily need a HP Support Link modem to
 make HP Predictive Support work.  A Hayes-compatible modem will do the job
 nicely.  One gotcha, though, is that Predictive will send the string "ATZ" to
 the modem, looking for a response of "OK".  If your modem has response codes
 disabled, Predictive will not be able to dial out, because it won't be able
 to figure out what kind of modem it's talking to.


                Mental Migration from MPE-V to Spectrum Part 2
                     By Jeff Kell, UTC Computing Services
                        Reprinted from SIGED Newsletter

 Following the manager's course, I was scheduled for the programmer's
 migration course.  This was a rather intensive 6-day class which has since
 been divided into two parts for future generations (and a good idea since you
 are well saturated with new information by this time).  We learned about the
 various Native-Mode compilers, the Compatibility-Mode emulator, TurboIMAGEXL,
 and touched on Native-Mode stacks and debugging.  We also learned about mode
 switching, which concerned me, due to our robust library of SPL utilities.

 The first lab involved Compatibility Mode, object code translation, and
 Native Mode comparisons.  Understanding just what these things are is one of
 the primary keys to successful "mental migration" and subsequent sanity, and
 I would like to elaborate further.

 MPE XL contains a Compatibility Mode (CM) Emulator which is logically
 equivalent to the microcode on a Classic 3000.  It reads Classic code as data
 and executes it like an interpreter, simulating all of the hardware features
 of the Classic 3000 in the process.  The emulator is so good that initial MPE
 XL releases contained only a small kernel written in Native Mode and the rest
 was MPE-V being fed into the CM emulator.  This is also one of the primary
 reasons that early MPE XL systems had such poor performance:  a Series 930 in
 Compatibility Mode is essentially a Classic Series 70.  Later versions of MPE
 XL contain more Native-Mode code as the CM code is phased out, but some
 subsystems remain in CM such as KSAM, FCOPY, EDITOR, etc.

 Now the important part that many people missed:  you don't really lose much
 of anything by moving to a Spectrum.  You heard, no doubt, that it doesn't do
 SPL.  Horsefeathers.  It compiles SPL (running the compiler in CM), PREPs the
 USL (using Segmenter in CM), and RUNs the program using the CM emulator.  We
 are currently doing program development and maintenance for our 58 on our
 950; it is quite capable of generating CM programs which will run on a
 Classic system.  The only thing you cannot do is get native mode code from an
 unsupported CM language like SPL, FORTRAN 66, old vanilla BASIC, COBOL 68,
 RPG, and so forth.

 Next comes "translated code" which is CM code that has been fed into the
 Object Code Translator (OCT).  If you can picture the emulator operating by
 fetching an instruction, decoding it, and branching off into an appropriate
 emulation routine, then translated code removes the first two steps.  OCTCOMP
 replaces the CM instructions with a series of procedure calls into the
 emulation routines, and then optimizes the resulting code.  The final product
 is appended to the CM program file transparently (if you accidentally move an
 OCT-program to a Classic system, it will run, but you waste the file space
 containing the translated code).

 Finally, we have "Native Mode" (NM) code.  This is a program which was
 compiled using a NM compiler and "linked" with the NM link editor.  It
 executes entirely in Native Mode, and may execute much faster than the
 previous two forms.  The NM compilers provide optional optimization to
 increase the code efficiency even further.  As an assignment, we ran a
 FORTRAN benchmark to generate prime numbers.  The results:
        * Compatibility Mode   - 3.34 seconds CPU
        * Translated code      - 1.56
        * Native Mode          - 0.89
        * Native optimized     - 0.83
 I later ran a Whetstone benchmark on our 58 and 950:
        * Series 58            - 222 seconds CPU
        * Compatibility Mode   - 214
        * Translated code      - 110
        * Native optimized     -  22
 The Whetstone code was an unusual case for us to compare against, as it is
 almost exclusively floating-point number crunching with calls to mathematical
 library functions.  For our typical COBOL/IMAGE applications we found that,
 in general, Compatibility Mode was four times faster (ie, 75% reduction) that
 the Classic 58, and Native Mode was twice as fast (ie, 50% reduction) as CM.
 This yields an average rule of thumb that the 950 in Native Mode is eight
 times faster than our 58.  later.

 Finally we began working with the compilers themselves.  The most immediately
 obvious difference is speed of compilation; they were ridiculously fast even
 on the 930 (granted, they were small class assignments, but it still "felt"
 faster).  A compile, link, and go will flash by the screen faster than you
 can read it.  This is even more dramatic now that we are compiling our own
 real programs.  On previous systems, we have a de-facto standard that we
 always run noncritical compiles in batch due to (a) impact on other
 interactive work and (b) length of time it takes to compile.  On the 950, it
 takes longer to build a compile job stream than to simply compile it
 interactively.  One of our largest programs (8500 lines plus many included
 COPYLIB modules) takes 241 CPU seconds to compile on the 58; this amounts to
 about 8-10 minutes wall time if nobody else is doing anything significant.
 The same program compiles on the 950 in 24 seconds, typically less than a
 minute of wall time.

 The next difference is both a "mental migration" issue and a "warm fuzzy"
 feature.  If you turn on MAP or VERBS in COBOL (or equivalent in another
 language) you are in for somewhat of a surprise.  First, values are in
 hexadecimal.  Yes, hex.  You can say so long and good luck to accumulated
 octal trivia; a string of four blanks is no longer %020040 %020040 but
 instead $20202020 (32-bit machine now, so we group bytes in fours!).  You can
 also say goodbye to uppercase symbols, as all procedure labels and so forth
 are now lowercase by default.  Now the "warm fuzzy" feature:  resolving
 addresses of data and/or code.  All data references are byte addresses
 relative to the Native-Mode data pointer (DP), and they are enclosed in one
 linear space.  No more bother about DB+/Q+/S+/byte/word confusion, all the
 map addresses are straightforward offsets from DP.  Procedures and code are
 relative to the current "chunk" (segment) of code, but you only have one
 "chunk" to deal with unless you have an extremely big COBOL program (only
 COBOL chunks its code) or call a subroutine that is outside the current
 compilation.  Typically there is only one, and in any case the offset is
 direct and straightforward; no more worry with P+/PB+/PL-/STT/segment
 translation.  And in the event that your program aborts, the "tombstone"
 gives the "chunk" or procedure name and the offset (it stores this symbolic
 information in the program file).  Very straightforward.
 Now, unless you are very brave, do not dive right in with DEBUG.  If you ever
 need to be reminded just how much you really don't know about Spectrum, use
 DEBUG.  One of the largest and most confusing manuals you will get with MPE
 XL is the System Debug manual.  If you just want to do something
 straightforward (like you might do on the Classic) it is very nice and almost
 friendly.  But it has a host of features that I cannot begin to explain.  For
 example, it can process a system dump, process macro files, format system
 tables or user-defined structures in memory, and other esoteric things.  It
 has its own command language, variables, functions, and macros.  DEBUG even
 does windows.  In CM DEBUG, you can turn on windows and get the important
 registers at the top of the screen, the current block of instructions next, a
 specified DB, Q, or S relative data area at the bottom (in decimal, octal,
 hex, or ASCII); you can then single step one instruction at a time, and any
 screen value that changes during that cycle will be highlighted for you.  You
 can even open a text window and display your source file inside it.  I'm
 certain that it is an amazing little creature, but with everything else I
 need to be learning now, the sheer magnitude of it scares the heck out of me.
 Classes are finally over, and its back to Chattanooga for a two week break
 before our scheduled week at the Atlanta Migration Center.  We select a very
 large COBOL application with subroutines to convert, and begin to collect
 source for the SPL procedures that will require mode switching procedures (to
 allow NM code to call CM subroutines).  We had learned about them in class,
 they seemed to be fairly simple.  You run a menu driven program called SWAT
 (SWitch Assist Tool) and it generates a Pascal program for you.  You compile
 the Pascal code and link it into an XL file (an NM SL) and it performs the
 magic that will keep you afloat until you convert the SPL to "something"
 native.  That was still somewhat of a scary issue, especially since we had
 identified nearly 100 SPL utility routines.
 A colleage and I, armed with recent backup tapes, arrived in Atlanta somewhat
 cautiously optimistic.  After obtaining necessary badges and clearance
 (unlike the flashy showrooms downstairs, the migration center was located on
 an HP staff floor) we met our second Spectrum.  It was a 930 without much
 memory, but it did have a recent MPE XL release.  In fact, it was one of the
 original systems that I feel sure would have stories to tell if it could
 talk.  Unlike the 930 in Rockville, there was no identification on the box at
 all other than a nameplate in the upper left corner with the familiar HP logo
 and one word:  INDIGO.  Yes, this was one of the prototypes, and it had never
 officially been dubbed a 3000 or 9000.
 A 3000 or 9000?  They sure look alike, don't they?  Many people have wondered
 just what the difference is, and nobody will say officially.  If you strip
 off the peripherals, there is no obvious difference other than the nameplate.
 But what else?  The unofficial word says only a few bits in a ROM in the
 "Processor Dependent Hardware" board.  Can a 3000 run Unix?  If you get a
 chance, watch your CE when he does diagnostics on your 3000.  You get a tape
 called the "HP-UX System Diagnostics" that the CE will load and promptly
 logon as 'root' on the console (yes, folks, that really was a Unix kernel).
 To make matters more mysterious, recall the ISL program I mentioned from the
 startup procedure?  Your CE gave it a Unix load command to get the kernel in
 the first place, and it understood it!  If you figure out how to get DEBUG to
 scan through low memory addresses while MPE XL is running, you will find
 things like "HP-UX SLLIC Assembler 1.4 (c) 1984, Hewlett-Packard Co." and the
 like.  So, can a 3000 run Unix?  Probably, unofficial word will not say no.
 Can a 9000 system run MPE?  No idea, unofficial word says no.  But back to
 migration.
 We created the necessary accounts and restored the production IMAGE databases
 and related files.  First test was to verify Compatibility Mode; should be a
 piece of cake, :RUN REGISTER.PUB;LIB=P.  The system gave the familiar
 linefeed after loading the program and...  nothing.  No abort, no message,
 nothing; the system appears to be in a loop.  Well, perhaps it was just a
 fluke, and another program might be more appropriate.  Break, :ABORT, :RUN
 GETSCHED.PUB;LIB=P.  Linefeed and nothing, looping again.  I feel sick, and
 my SE stopped smiling.  The migration specialist comes over for a look,
 verifies the loop, looks over the code, then looks puzzled.  I feel faint, my
 SE looks at the migration SE, he looks out the window.  We try again, with
 ;DEBUG, and turn on windows, and after several instructions the loop appears.
 Our programs use an SPL procedure for initialization of the terminal I/O
 routines that we use.  This routine does the old familiar method of tracing
 back down through the stack markers to find the PARM and INFO values.  I was
 burned by this one when we installed MPE-V/E with new firmware, but that
 error caused bounds violations.  Could this be related?  Yes, indeed it was;
 CM uses pre-V/E stack markers, and the code was looping on a Delta-Q value of
 zero.  One quick SLPATCH session later, everything was working in CM, my SE
 was smiling again, and I was regaining my appetite.  We tried other programs
 and found one additional bug, also due to the SPL procedures.  A common
 database open routine, leftover from the days of the Series III, was reading
 the system switch register to check for the 0-bit being set (an old mechanism
 we used to disable database access).  Compatibility Mode appears to assume
 the "Read Switch Register" instruction is privileged.  One more SLPATCH and
 all is well.
 Despite initial fears, everything was indeed now working in CM, and the
 response time was much better than ever experienced.  We streamed several
 batch reports (in CM) and were amazed at the results; after using OCT on some
 selected programs the results were even better.  At least now I felt
 confident that I was "at least" getting a faster Classic 3000, whether the
 migration to Native Mode was done or not.  In other words, compatibility was
 now confirmed and I felt much more secure; with two minor exceptions, CM was
 indeed working.
 The remainder of the day was spent creating "stub" procedures with SWAT so
 that we could interface the existing SPL library routines with an NM COBOL
 program.  As soon as enough stubs were complete to test a small application,
 we gave it a try but it was quite a disappointment:  we got the Native Mode
 equivalent of a bounds violation.  Stubs were checked, code was checked,
 traces were added, phone calls were made, and my SE stopped smiling again.
 By the close of the day we had discovered the problem:  another SPL quirk.
 Our terminal I/O routines are called with four parameters, but we soon grew
 tired of coding "CALL" statements with the full complement of parameters.
 The initialization routine was altered to store the parameter addresses in
 the DB-negative area, and a secondary entry point to the I/O routines was
 created that could be called without any parameters (it retrieved the
 addresses stored earlier).  Because of the way the stub procedures operate,
 this scheme fails for reasons too intricate to explain in detail here.
 To make a long story short, a workaround was devised using global pointers
 within the stub by manually modifying the stub source.  The first variation
 on this idea involved modifying the calling program source code to declare
 externals (not terribly desirable) but a later idea spawned an experiment
 Friday morning to link the global pointers between the initialization stub
 and the I/O stub through an RL.  This worked, and negated the need for source
 code modification.  It also negated our source conversion for the week (done
 with source changes) but we did produce a fully compatible stub library we
 eventually used in the live migration.  In spite of several close calls and
 the near panic caused as a result, the overall week was very productive.
 The next few weeks were spent playing the "waiting game" as various
 components of the system were delivered.  One morning a driver came in with a
 delivery of 400 pounds in one carton.  I expected a printer but the carton
 contained manuals, 39 of them, in navy blue "MPE XL" binders.  These were the
 MPE XL FOS manuals; no purchased software, only the basic manuals.  I
 replaced my nine V/E FOS manuals (and quite a bit of other shelf space) with
 the XL manuals.  Welcome to MPE XL.
 Finally, everything else is in place, and the CPU arrives by padded truck.
 ...
     { to be completed next month}







                          Introducing Barbara Janicki

 About a year ago, Robelle went looking for an official technical writer to
 replace our amateur-programmer efforts.  After wading through 350 resumes and
 interviewing 11 people, we settled on Barbara Janicki.  Despite her continual
 commuting between East and West Canada, we all agree we made a good choice.
 Barbara has been busy updating manuals, generating Quick Reference Guides and
 data sheets, creating Novice Guides and Tutorial packages, and generally
 upgrading the quality of all of our words.   ...  Here is how Barbara
 describes it:

           Insight to Robellian
           By Barbara Janicki
           Rebellion brewed.  The crew were few.
           Far between were their coffee breaks.
           The programmers too were sullen.
           We would write code, they cried,
           Not documentation, a dull endeavor,
           That gives us belly aches.

           Passage of Xpress messages lit them.
           Clamshells gleamed in pallid acclaim.   {Literary Hint, clamshell =
           Laptop!}
           They were revolting.
           Step-by-step, item-by-item,
           Bit-by-bit, name-by-name:
           Someone to compile help files
           And do proof-reading.
           Someone with the wiles
           To drain the blustery bloated boils of redundancy,
           And to uncoil the word-snakes' nests
           That clustered like the cables
           Beneath their desks.

           Plain-spoken, word-warden, I
           Met the three jewelled disputers;
           I knew something of computers--
           PCs only--but curiously
           Intrigued by IMAGE, a reader
           Eager To re-do or
           To champion their bulletins.
           They tried my skill in tons of tests,
           And asked for my degree defense.
           I passed my word to furnish reference
           Manuals; to burnish brighter
           The enhancement requests;
           To be their Technical Writer.

           Their hearts leapt up, as they beheld
           Time to compile! time enough to run!
           So it was when I began.  Meanwhile,
           We shared some cookies; and so
           Passed the year since they rebelled.
           When nothing else exists you'd rather do,
           You cannot really call it work, can you?
           Let them write code.






            Robelle Products:  Problems, Solutions, and Suggestions

 SUPRTOOL  Version 3.0

 Non-Collating Dates.  Because dates in DDMMYY form do not collate correctly,
 SUPRTOOL does not support greater-than type comparisions on them (only strict
 equality or non-equality).  For example:
     >input myfile
     >define mydate,1,6         {first six bytes are date}
     >item mydate,date,DDMMYY   {sample date =  251188}
     >if mydate >= $date(88/11/01)    {compare would fail!}
     ERROR: Invalid date format for comparison
 Workarounds:  Because this particular date field is X-type (character), the
 DEFINE command can isolate the day, month, and year portions of the date.
 With these new fields, it is usually possible to select for specific date
 ranges.  However, the $DATE and $TODAY features are not available and this
 technique does not work for J2 dates.
     >define myday  ,1,2
     >define mymonth,3,2
     >define myyear ,5,2
     >if myyear >= "88" and mymonth >= "11"
 Alternative For Any Date Type:  Since date selection is often for a single
 month, create twelve files, one per month, each containing the valid dates
 for the month.  Then load the file into a TABLE and use $LOOKUP.  (In
 SUPRTOOL 3.0, you must re-DEFINE J2-type dates as X-type, but it still
 works).  You could use this same scheme to select any small subset of dates:
     >table daytable,mydate,file,march
     >if $lookup (daytable,mydate)

 Checking A Byte For A Numeric Value? SUPRTOOL does not have one-byte
 integers, making it it difficult to check a single byte for a specific
 numeric value.  Use a two-byte integer DEFINE field and the bit-extract
 operator to solve this problem:
     >define word,transcode,2,integer
     >if word.(0:8)=13

 Instant Mailing Labels You want to extract NAME, ADDR (3X40) and PHONE and
 print each on a separate line.  How to do it?  DEFINE a two-byte integer
 field named CRLF and use it between each EXTRACT field, set to the value 3338
 (%6412, which equals CR and LF).
     >define crlf,1,2,integer
     >extract name,crlf=3338,addr(1),crlf=3338,addr(2),&
     >crlf=3338,addr(3),crlf=3338,phone
     >output *

 QEDIT  Version 3.7 and 3.7.1

 FTN 77 A.01.00 Patch.  V-Delta-4 contains a version of Fortran 77 that goes
 into an infinite loop when you attempt to feed it a QEDIT source file.  This
 patch fixes the problem, and the second part allows the compiler to read
 temporary source files:
     :run patch.pub.sys
     File=ftn.pub.sys
     ?m,32,10125
     051404,140050     {endless loop}
     ?m,32,10054
     041403,021003     {temp files}