ftp.robelle3000.ai 2014/2014.06.ftp.robelle3000.ai.tar/ftp.robelle3000.ai/newsletter/1990/w1990-06.txt

Text File | 1999-04-28 | 24KB | 501 lines

         What's Up DOCumentation



        Robelle Consulting Ltd.
        Unit 201, 15399-102A Ave.
        Surrey, B.C.  Canada  V3R 7K1
        Phone:  [phone]
        Fax:  [phone]

 Date:  November 29, 1990
 From:  Robert M. Green, President
        David J. Greer, Research & Development
        Michael Shumko, Customer Support
 To:    Users of Robelle Software
 Re:    News of the HP 3000, 1990 #6

      What You Will Find in This News Memo:

        News Tidbits
        New Xpress 2.7 Supports MS-DOS File Transfers
        Technical Tips
        About Robelle
        MPE XL Performance Tips from HP
        More on the System Debugger
        Robelle Products:  Problems, Solutions, and Suggestions


                                 News Tidbits

 Starbase.  The database competition on MPE XL is heating up again.  Synergy
 Computing reports that Cognos is shipping a relational database called
 "Starbase" (actually a VAR copy of Interbase) for MPE XL and VAX.  Interbase
 is not available yet on PCs, but is rumored to be released "real soon" on
 386-machines.  Why another database system?  According to Chris Spottiswoode,
 Starbase has several features that users have been waiting years for in other
 databases.  Not being experts on relational databases yet, we aren't
 qualified to verify that!

 Back in Harness.  According to the San Jose Mercury News, "the company that
 David Packard helped build is struggling with both a crisis of its soul and
 financial challenges.  In an attempt at redeeming it, Packard is back,
 managing -- just like in the old days -- by wandering around.  At a time of
 life when most industrial legends are content with a venerated emeritus
 status, the 78-year-old Packard, chairman of Hewlett-Packard Co., is in his
 office most workdays.  He also regularly travels to most HP sites nationwide,
 talking to many of the company's 92,000 employees.  ... in the development
 that associates say is most troubing to Packard, there are complaints the
 company's growth and management style in recent years have caused the
 withering of the "HP Way", a set of benevolent attitudes toward employees and
 customers that somehow set HP apart from other firms, making it Silicon
 Valley's great class act.  A company once celebrated for being trusting and
 collegial has too often, some say, become suspicious and bureaucratic.  A few
 years ago, HP was the basis of an unflattering Stanford University business
 school case study of a company where employee experiences are often sharply
 at odds with lofty management rhetoric."

 Independent Qedit Training.   Over the past two years, we have developed--and
 maintained--user training materials for Qedit and Suprtool.  Some of you may
 have attended such training that Robelle presented in various cities and
 internally at a number of companies.  Recently, a new customer in Texas
 wanted in-house training, but we didn't have anyone free to do it at the
 time.  Mark Ligas, one of our experienced users in Texas and an employee of
 Tymlabs, came to the rescue.  Using our materials and some unused vacation
 time, Mark taught the training class and got good ratings from the students.
 Very enterprising!  If anyone else is interested, Mark charges $850 US plus
 expenses and can be contacted at Tymlabs, [phone].

 Neat HP Desk Tip.  On pages 12-16 of the October issue of Interact, Eric
 Omuro, technical consultant at Complimate in Cupertino, presents an ingenious
 way to do ad hoc reporting of users' disc usage, sorted from worst to best.
 He uses only Qedit, Suprtool, and MPE programming.

 TurboImage Unbundling.  The December issue of Interex/Press is full of
 evidence that the issue of TurboImage unbundling hasn't died down.  Richard
 Kranz, the editor, has an editorial calling on HP to "play the roll of
 gift-giving Santa Claus.  ... HP is in an ideal position to win friends and
 users with one simple act.  Rebundle IMAGE!"  Steve Cooper, chairman of
 SIGIMAGE, is quoted as saying "unbundling was a small flame in April, a big
 blaze in Boston and then HP threw gasoline on the flame and now it's a forest
 fire."  Stan Sieler is quoted at length: "HP is apparently having problems in
 believing what we say."  He heard disquieting rumors that HP thought the
 VARS, the software vendors, were responsible for the Boston complaints on the
 unbundling.  Stan countered with "I can only say, wake up and smell the
 coffee, HP; those weren't vendors at the microphones at the roundtable who
 were complaining."


                 New Xpress 2.7 Supports MS-DOS File Transfers

 Xpress is an electronic mail system that is so easy to use that you can start
 exchanging mail the first day without formal training.  Xpress works on any
 HP 3000 hardware, and on all versions of MPE (including MPE/XL).  Xpress has
 a streamlined design that keeps the load on your machine low, and still
 offers all the functions you need.

 The highlights of the new version of Xpress mail are

  * Attach MS-DOS files to your Xpress electronic messages.  Last year, we
    added the ability to exchange MPE files in Xpress.  Now you can do the
    same with files from your Personal Computer, if you're using Walker
    Richer & Quinn's Reflection program.  You can send a file to another
    user, on another CPU, or even another PC, attached to an HP 3000 in
    your network.  For example, send a sales report, and include the file
    with the graphs or spreadsheets of the actual figures...the user can
    print it with his or her own PC and attached printer.  You're totally
    electronic...no hardcopy or discs to exchange...no courier delays.

  * More speed for users.  The new Screen Display options enable users to
    specify what menus to display, and whether to see the list of users to
    send to in the Out Basket.  Skilled users, or people dealing with slow
    modems, can avoid most displays and save time.

  * Select a range of message numbers.  You can handle your messages in
    quantity.  Tell Xpress to copy messages 1/5 (i.e., messages 1,2,3,4,5),
    move messages 7/ (all messages from 7 to the last), or read 10/1 (read
    your ten messages in reverse order).

  * Context-sensitive help for mail managers.  Xpress now has
    context-sensitive help for mail managers as well as for the users.  Ask
    for help at any prompt while doing your configuration tasks.  Xpress is
    so simple to install that the longest task will be typing in the users'
    names.

  * Pony Xpress for PCs has a message editor.  You can write Xpress
    messages on a PC, and exchange them with the 3000 at your convenience.
    We added an editor to Pony Xpress to make it easier to create messages.

 Our change notice has a full description of all the new features.  Xpress
 owners on service will automatically receive an update tape, containing
 revised user manuals.
 If you haven't yet convinced yourself of the benefits of electronic mail,
 just call for your free demo.  We think you'll like what you see.


                                Technical Tips

 Octcomp Needed After Patch.  When you apply a patch to a CM program to
 correct a problem, you must remember to re-Octcomp the program on MPE XL.  If
 you don't, the patch applies only to the CM code and not to the translated NM
 code that actually executes, so the patch is ignored.  Remember, what Octcomp
 does is translate the old Classic instructions in your CM program into shiny
 new RISC instructions (without your having to make any changes to the
 program, or even having the source code).  The NM code is appended to the
 program file, which still contains the CM code, in case you move the program
 file back to MPE V and want to run it there.  Octcomp is important because
 most CM programs run much faster once they have been "oct'ed".  However,
 Octcomp is not without bugs, so watch bulletins from your third-party vendors
 about programs that should not be "oct'ed" (for example, Prose and Howmessy
 on 2.1 and 2.2).

 Permanent Versus Temporary.  The Finfo function of MPE XL's Command Language
 returns attributes of files.  It looks first for a temporary file and then,
 if it doesn't find one, for a permanent file.  What if you need to know if
 the file is temporary or permanent? FINFO option -13 returns the FOPTIONS
 mask in integer format (on MPE XL 2.1 you can use the string alias "FOPTIONS"
 to specify this option).  You can test the last two bits of the FOPTIONS mask
 to determine the file's domain.

      if (![finfo("!work_file","foptions")] band 1 = 1) then {perm}
                                            band 2 = 2) then {temp}

 The Magic Dies.  Last month we reported that :Help Summary on MPE XL 2.05
 says it can give you a list of commands that have been "enchanted" (instead
 of enhanced).  Dan Carter of Ingres noticed that on MPE XL 2.1, the same help
 screen shows "enchanced" (instead of enchanted).  "Who's typing in this stuff
 at HP?"

 :Store-Transport Warning.  We have job streams to make tapes for customers;
 the jobs use :Store with the ;Transport option (i.e., format the tape so that
 MPE V can read it).  The job logs on in the Robelle account and dumps the
 product files from there, plus a few files from Pub.Sys (for which we have
 Read Access).  When we installed MPE XL 2.1, the Pub.Sys files wouldn't store
 anymore.  :Store-Transport on 2.1 will not allow you to store files outside
 your logon account, even though you have Read Access to them, unless you have
 OP or SM.  This is a known bug in 2.1 and does not apply to NM Stores.
 Workaround:  add OP to the account/user.

 Tip from the Response Center.  If you want to run an OCTCOMPed program file
 in untranslated mode (to check to see if a bug was introduced in the OCTCOMP
 step, for example), run Octutil.Mpexl.Telesup.  Enter the commands

      FILE program-name
      EM ALL

 to return the program to emulation mode, or TRANS ALL to return the program
 to OCTCOMP mode.  The utility simply flips a bit used by the MPE XL loader;
 it does not actually delete or re-translate code.

 EOF on NM KSAM Files.  Craig Engel at Euclid Industries reports that if you
 specify the REUSE option for a KSAM/XL file, the Eof no longer represents the
 actual number of records in the file.  There is no way to determine how many
 records are in the file without actually reading them and counting them,
 using FCOPY or an equivalent.  SR 5000-598276 has been submitted, requesting
 HP to publish the algorithm for interspersing free space in the KSAM/XL file,
 so that a customer can calculate from the Eof how many data records are
 actually present.

 High-speed Modems.  Robelle programmers work from their homes, so data
 communications is a high-priority item.  We have been using modems made by US
 Robotics for some time now, and have found that they work fairly well.  We
 started with the Courier HST model, which permitted 9600 baud, but exhibited
 a `jerky' or `mushy' response for interactive communications.

 The latest modems from US Robotics are much better, and use V.32 and V.42
 technology to give full duplex at high speeds, reportedly up to 38400 baud.
 We only use them at 9600 baud, though, as higher speeds will exhibit the
 `mushy' feeling.  (You press ctrl-s, and two pages later the display stops.
 Or you type a handful of characters and look up to see them echo a moment
 later.)  Using these modems at 9600 baud gives it a direct-connect feel.
 The AT sequences that we use to configure the V.32 modems are:
     At the office:
           AT&FB0X6&B1S21=40S13=1&W
     At home:
           AT&FB0X6&B1T&W
 On our Classic machines, we had to modify our TT files to get the promised
 speed.  You can use the workstation configurator, ttutil.pub.sys, to modify
 the TT files.  Try copying TT10 to TT11, remove enq-ack from TT11, and have
 your modem users sign on with TERM=11.  Since MPE XL machines no longer use
 enq-ack, they are not affected.  Note:  removing enq-ack can let you run at
 speeds close to 960 cps; with enq-ack enabled, you may be looking at 120 to
 240 cps.

 Ffileinfo-56 "Feature".  We recently resolved a problem in Qedit which hinged
 on a very peculiar "feature" of Ffileinfo-56 (number of blocks in a
 variable-length file).

      integer numblocks;  <<16-bit integer in Spl>>
      ffileinfo(filenum,56,numblocks);

 On MPE XL 2.1, this call always returns 0 as the number of blocks for a
 variable record-length file! The reason is simple.  Ffileinfo 56 on XL 2.1
 and MPE V returns a 32-bit integer, so my code only picked up the left 16
 bits, which are 0 for most files.  On the earlier versions of MPE XL which we
 tested, Ffileinfo 56 returned a 16-bit integer.  This happened because the
 MPE V manual was wrong (it said 16 bits, while MPE V actually returns 32),
 and the MPE XL programmer did what it said in the manual! To get the correct
 number of blocks in a variable record-length file, always use a 32-bit
 integer, and if the low-order 16 bits are 0, assume that MPE XL has returned
 a single-word in the high-order word and shift it.







                        MPE XL Performance Tips from HP

 Stephen Kayser at Generra Sportswear sent us the following notes from an MPE
 XL performance class at HP Bellevue.  We did some benchmarks to verify the
 notes on native-mode KSAM/XL files, so we pass them on to you.

 When writing to a new KSAM/XL file, you can improve performance by building
 the file as temporary, writing to it, then saving it.  The file will not be
 attached to the Transaction Manager until it is saved, thus reducing disc
 I/O.  Of course, if the system fails, the file will be lost.  (This technique
 does not apply to compatibility-mode KSAM/V files.)

 Another interesting change in KSAM/XL is that there is no difference in the
 CPU time required to load a file with duplicate keys, whether the duplicate
 key is specified as random (RDUP) or not.  From some tests conducted on our
 922 using FCOPY to load a 10,000-record file with an 8-byte duplicate key:

      KSAM/V             DUP:  73 CPU secs   RDUP:  51 CPU secs
      KSAM/XL permanent  DUP: 154 CPU secs   RDUP: 154 CPU secs
      KSAM/XL temporary  DUP:  93 CPU secs   RDUP:  93 CPU secs

 These tests were performed on MPE XL 2.1, with FCOPY in compatibility mode,
 which helps explain why in all cases it takes longer to load a KSAM/XL file
 than a KSAM/V file.

 Make sure that TurboIMAGE root files and VPLUS forms files have NLS (Native
 Language Support) turned OFF.  If set to English, large NLS tables are
 searched unnecessarily.

 FFLUSH is an HP utility that flushes a file from main memory--handy for
 performance benchmarking.  [We can verify that Fflush exists, but it isn't
 easy to get.]







                          More On the System Debugger

 In a previous news memo, we showed how to set a breakpoint immediately after
 a procedure call (using MPE XL's System Debugger).  David Greer has written a
 paper of tips on the System Debugger which we will be distributing as a
 Christmas present.  As a teaser, here is a new version of the "Return"
 breakpoint (provided by Stan Sieler) that works in all cases.

 The "Return" Breakpoint in Compatibility Mode

 Suppose that your CM program calls the CM procedure extract_ready.  You want
 to know the result of extract_ready, so you would like a breakpoint in the
 calling code immediately after the call to extract_ready.  You do the
 following:

      cmdebug >b ?extract_ready
      cmdebug >c
      .
      .
      .                        {Break at extract_ready}
      cmdebug >lev 1;b p,-1    {-1 means only break once}
      cmdebug >c               {continue execution}

 The "lev 1" goes back to the previous logical level in the calling sequence
 (use "tr,d" to see a complete traceback).  The "b p" sets a breakpoint at the
 compatibility-mode program counter.  Because of the "lev 1", the program
 counter is at the instruction after the one that called the current
 procedure.  The ",-1" tells Debug/XL to execute the breakpoint once, then
 throw it away.  Note that it's safe to use this breakpoint anywhere in the
 extract_ready procedure -- not just at the beginning.

 What if we are in native-mode code (e.g., FWRITE)?  Our return breakpoint
 won't work, since we called FWRITE from compatibility-mode.  To set a return
 breakpoint in this case, first switch into cmdebug:

      cmdebug >b ?FWRITE
      cmdebug >c
      .
      .
      .                        {Break at NM FWRITE}
      nmdebug >cm              {switch into CM}
      cmdebug >lev 1;b p,-1    {set return breakpoint}
      cmdebug >c               {continue execution}

 Setting a "Return" Breakpoint in Native-Mode

 You use a similar method to set a return breakpoint in native-mode code:

      nmdebug >b extract_ready
      nmdebug >c
      .
      .
      .                       {Break at extract_ready}
      nmdebug >lev 1;b pc,-1  {-1 means only break once}
      nmdebug >c              {continue execution}

 The only difference between a CM return breakpoint and an NM one is the name
 of the program counter.  In native-mode, it's called "pc".  This sets a
 return breakpoint immediately after the code that called extract_ready.  Note
 that it's safe to use this breakpoint anywhere in the extract_ready procedure
 -- not just at the beginning.






                                 About Robelle

 New Support Hours.  Robelle's technical support department is open an hour
 earlier, to help customers on the east coast reach us.  Support hours are
 from 7am to 4pm (PST) Monday to Friday.  That's 10am to 7pm on the east
 coast.

 Interview with Our President.  Somehow, a local head-hunter talked Bob Green
 into a phone interview about Robelle for a newsletter.  In an unguarded
 moment, Bob declared "The prospects for software in B.C.  [Western Canada]
 look good.  There are advantages to being here:  we're in the same time zone
 as California; but we don't have to live there."  [Sorry, Californians.]







            Robelle Products:  Problems, Solutions, and Suggestions


 Qedit  Version 3.8.1/3.8.2

 :Stream on MPE XL 2.1.  If you get the error message "WARNING:  NO :JOB OR
 :DATA COMMAND ENCOUNTERED.  (CIWARN 1406)" when streaming a job inside Qedit,
 check for invalid passwords.  When the Stream Command fails for any reason,
 MPE XL returns CIWARN 1406 in addition to the error, but programs like Qedit
 that call the Command Intrinsic see only the last error message.  Try
 streaming the file from the MPE XL command interpreter: it will show both
 error messages.  This bug in MPE XL 2.1 is fixed in MPE XL 2.2 (SR
 5000-559286).

 Change Command on a Fileset.  A customer wanted to know how to use Qedit and
 MPEX to change all occurrences of a string in a fileset, with on-line
 verification (using the CJ command).  This is not supported by the Qedit
 command in MPEX, but with a little help from our friends at VESoft, we came
 up with this:
      %REPEAT
      %RUN QEDIT.PUB.ROBELLE;PARM=163;&
           INFO="T !MPEXCURRENTFILE;CJ :string1:string2:  ;K"
      %FORFILES {fileset}
 This works nicely for Keep files and could be souped up to check for the
 filecode and do an Open/Shut for Qedit files, instead of a Text/Keep.  With
 version 3.9 of Qedit, which will be shipped soon, you can use "Keep,IfDirty"
 to keep the file only if any changes have been made.

 Documentation Error.  There is a mistake in the command file example for the
 WHILE command in the Qedit 3.8 user manual.  It will not find the string to
 be searched for if it is in the first line in the file (since the find
 command starts searching forward from the current line).  Here is an improved
 example:
      PARM string
      /set window (up)
      setjcw cierror = 0
      continue
      /findq "!string" first
      while cierror=0 do
          display FOUND "!string":
          /list */*+3
          display
          continue
          /findq "!string"
      endwhile


 Suprtool  Version 3.2

 "On-line" Versus "Batch".  Some of our customers run Suprtool on-line in a
 "canned" environment, passing commands to Suprtool through Use files to
 execute standard tasks.  They do not want any interaction between Suprtool
 and the terminal user.  But since Suprtool is executing on-line, it will
 sometimes prompt the user for information.  For example, if you specify
 Output,Erase to erase a file, Suprtool will ask
      ERASE all records from this OUTPUT file [no]?
 To suppress this question, you have to fool Suprtool into thinking that it is
 running in batch.  The easiest way to do this is:
      :run suprtool.pub.robelle;stdin=$null;&
          info="Use filename";parm=4

 Prompting for If parameters.  Some customers have asked for the ability in
 Suprtool to prompt for values in the IF command.  The solution has always
 been to write a simple front-end program that prompts the user for
 information, edits it, and creates a USE file for Suprtool containing the IF
 statement, or passes commands to Suprtool through the Suprtool2 interface.

 Customers on MPE XL 2.1 can write simple command files to prompt for values
 and take advantage of IO redirection (a new feature of the command
 interpreter) to create a temporary USE file containing the IF statement.  For
 example, this command file prompts for a starting and ending date for a
 reporting period:

     input start_date;&
           prompt="Enter the first date of the reporting period (yy/mm/dd): "
     input end_date;&
           prompt="Enter the last date of the reporting period (yy/mm/dd): "
     echo ITEM sales-date,date,yymmdd >usefile
     echo IF sales-date >=$date(!start_date) and &  >>usefile
     echo    sales-date <=$date(!end_date) >>usefile
 The USE file looks like this:
     ITEM sales-date,date,yymmdd
     IF sales-date >=$date(88/01/01) and &
        sales-date <=$date(89/01/01)
 To execute the ITEM and IF commands in Suprtool, first enter your Base and
 Get commands, then enter "Use usefile".
 The command file could be enhanced to perform simple editing of the dates for
 reasonability and format, etc.

 Patch for Userlabels.  If you have a file that is built with userlabels, but
 they are not all allocated, Suprtool 3.2 may attempt to read them and print
 an error message such as:
      Error:  Unable to read label from self-describing file
 To fix this, apply the following patches (on MPE XL, don't forget to re-Oct
 Suprtool after patching it):
      :run patch.pub.sys
      File?  Suprtool
      ?M,3,6553
      145206,145606
      ?M,3,4355
      145206,145606
      ?M,2,2577
      145206,145606
      ? <Return>

 Xpress  Version 2.7

 PC File Transfers in 2.7.  When Xpress 2.7 is unable to download a file to
 your PC because it cannot run Pclink, you are left in the Reflection File
 Transfer Menu with "No host response" on the screen.  Xpress writes an error
 message to a temporary file Wrqerror.  The PC of one user this happened to
 had the "host startup" sequence set to:
      RUN PCLINK.PUB.sys;pARM=5
 Xpress 2.7 was not upshifting the :Run Command before executing it.  When the
 customer upshifted the :Run Command, the problem went away.  Xpress 2.7.1
 will upshift the host startup sequence, improve several error messages, and
 write the host "run" command to the Wrqerror file.

 Prose and HowMessy

 Do not Octcomp Prose or Howmessy on MPE XL 2.2.  The problem with the Oct'ed
 versions that started on 2.1 is not fixed on 2.2.  HP is investigating:  SR
 5000-601997.
*c1950a175b10g2P*p-50Y

    Fortune Cookie of the Month
      Are fjords sort of like pjontiacs?    [Ingo Jobling]