3000 NewsWire Online Extra

Update of Volume 2, Issue 2 (November, 1996)

HP TO OUTLINE 3000'S ROADMAP IN LATE JANUARY
HP will give its installed customer base a set of road signs and direction on where it's headed with the server on January 29, 1997, when it broadcasts the Strategic Directions Roadmap to the Future show to HP sales offices across the US and in some international locations. HP promises to tell what you can look forward to as an HP 3000 customers and how you can get the most from your HP 3000 investment. What everybody will be listening for is the plan to make MPE/iX 64-bit capable and tuned to the new PA-8000 chip set, and what HP will do to make its Merced family of processors which is being co-developed with Intel deliver some value for HP 3000 customers.

To register, you can call 800.224.HP3K, or register over the World Wide Web at www.hp.com/go/registerhp3k. If you're looking for some hope for the broadcast, keep in mind that HP says it will take "worry free, business-critical computing into the next century." That sounds like at least a five-year plan to us. We'll have full details on our Web site the day of the broadcast.

HP NAMES WEB/INTRANET INTEGRATORS FOR HP 3000
HP has identified an extra handful of integrators and consultants that it recommends for your HP 3000 Internet and intranet projects. HP began this model with its Client Server Integrator program in 1994, and many of those integrators appear on the new intranet consulting list. These companies have had their programs and certifications evaluated by HP for applicability to HP 3000 operations. In short, when you come to them for services and solutions concerning MPE/iX, they won't have to ask you why you're not using Unix instead.

The names new to the list (those that aren't on the Client Server list) are GBSI, based in Denver, Colo. (303.363.3600); OESC, based in Englewood, Calif. (310.419.2200); 3k Associates, based in Springfield, Va. (800.638.6245); Melillo Consulting, based in Somerset, N.J. (908.563.8420); or I/O Data Systems, based in Cleveland, Oh. (216.835.2211). HP also lists a security consulting firm, Myxa Corp. at 610.436.5767. Most security solutions for HP 3000s involve non-MPE/iX systems, since the definition of a firewall implies the use of a separate system that can attacked without any mission-critical damage to your systems.

GET HP 3000 TV SHOWS FROM HP WORLD ON TAPE
If you didn't make it to this year's HP World conference in Anaheim, HP is offering tapes of its Reel World one hour broadcasts on tape. While these shows were heavy in marketing message, they did include some details on solutions you may find helpful. The Wednesday, August 6 tape has highlights of Harry Sterling's State of the HP 3000 address, and the Tuesday tape has a brief item on the World's Largest Poster, created near the conference site with HP 3000 output and an all-volunteer crew. The tapes are free, and you can get yours by faxing a request to 612.430.3388.

LIFE ENDS FOR SERIES 939 AND 959 SYSTEMS NEXT CENTURY
HP stopped selling the Series 939 and 959 HP 3000s as of the beginning of December, but that doesn't mean the systems are completely dead yet. The 939 in particular will probably have a healthy afterlife in the remarketed systems marketplace, because as one expert in channel told us, "HP priced it not thinking it would sell so well. But it did, and it broke the price curve." Both popular systems are facing a support end date of Sept. 1, 2003, so there's plenty of life left in the systems. And HP is still selling board upgrades for the 959s through next October, to give you the ability to add processors to any 959s you're lucky enough to find on the market. Since HP's recommending Series 969/100-400 systems as a replacement for the 959s, and HP cut the 969 prices from 10 to 24 percent in it November announcement, getting a 959 might be easy for a while. HP is dropping the 939 to 959 upgrade kits, but it's retaining an option to upgrade a 939 to a 969/100 system. Combine the usual healthy remarketed discount with the price cuts in a 969, and this may be another way to move off of 9x7 models and onto something that can accept the PA-8000 processor family: buy a 939 used, then upgrade it to 969/100.

HP MOVES TO A NEW TRADE UP PROGRAM NEXT MONTH
HP is introducing a new trade-in program on January 1, and one of its changes is the way your discounts are figured when moving from older HP 3000s to newer models. In the past, HP "discounted your discount," when calculating the bottom line on TradeUp deals. Now it figures your trade in discount and your Purchase Agreement Discount (PAD) at the same time. The difference is slight, but it's still there. An upgrade deal that costs $64,600 until the end of this month will cost $66,000 after January 1. And if your PAD discount is higher than 24 percent (lucky you), you won't get any extra advantage from it if you want to work with the Trade Up program. The 24 percent cap remains in effect from the 1996 version of TradeUp. HP is also dropping a "20+ special" discount that gave an extra 5 percent break to large single orders.

HP is giving the Trade Up break without any need for approval to all upgrades or box swaps (from other systems) when a customer is buying Series 9x9s or 9x8s. The 9x9 purchases qualify for a discount of as much as 10 percent, while the 9x8 purchases qualify for as much as 5 percent. There's no discounts for any external peripherals you may be pulling out of service when you upgrade. However, the discounts apply to all items that are associated with your server. That means things like memory, internal peripherals, networking cards and MPE user licenses also qualify.

9X8S LEAD TIMES ARE LIKE ORDERING PCS
HP has reminded its channel that the delivery time of the Series 9x8s is typically just seven days, a lead time more commonly associated with PC-class systems. HP has sold more of the 9x8s than any other RISC-based system currently being offered. It's been a popular upgrade for companies moving from "Classic" MPE/V systems, because the performance gains are so obvious. HP estimates you'll double the performance of Series 70 system by shifting the work to the rock-bottom Series 918. Support costs drop as well. HP estimates moving an MPE V systems to a 9x8 can show a return on investment in 1-2 years.

The 9x8s are now sporting newer DAT tape drives with increased capacity, and come with larger disk drives bundled at no extra cost. Ordering a 9x8 gets you a DDS-2 tape, which can create 8Gb backups on a single cartridge with compression. The systems also include a 2Gb drive and HP PowerTrust UPS. You need to commit to MPE/iX 5.0 or 5.5 to use the 9x8s; version 4.0 isn't supported, although it won't be supported on any HP 3000 in just a few months.

HIDDEN VALUE: ADJUSTING DATES FOR DAYLIGHT SAVINGS
HP 3000 manager John Joerger, who was instrumental in helping get the World's Largest Poster project publicized in Southern California, recently left the world of the HP 3000 at the Long-Beach Press Telegram for new employment in the world of Unisys and NT. As we wish John a bon voyage, we're forwarding his last bit of help to the 3000 community, a script that automatically changes the system time for the Daylight Savings switches in April and October. John reminds us that we'll have to change the TimeZone references to reflect the correct local ones. Thanks John, and good luck outside the world of MPE!

!COMMENT
!JOB JTIMECHG,MANAGER.SYS;HIPRI
!TELLOP
!TELLOP -------------------------------------------
!TELLOP Adjust system clock for Daylight Savings
!TELLOP -------------------------------------------
!TELLOP
!
!IF HPDay=1 AND HPMonth=10 AND HPDate>24 THEN
!  COMMENT  Have to fall back one hour
!  CONTINUE
!  SETCLOCK TimeZone=W8:00
!ELSEIF HPDay=1 AND HPMonth=4 AND HPDate<8 THEN
!  COMMENT  Have to spring forward one hour
!  CONTINUE
!  SETCLOCK TimeZone=W7:00
!ELSE
!  COMMENT  Today is not a time change day
!  TELLOP -------------------------------------------
!  TELLOP No change done because today is not a
!  TELLOP time change day.
!  TELLOP -------------------------------------------
!ENDIF
!EOJ

HP MAKES PROGRESS ON PING PROTECTION
HP's response center was reporting that a patch had been developed to protect HP 3000 systems from being crashed by the Windows 95 PING programs, a situation we reported on in our last Online Extra and one that's profiled in the upcoming December TestDrive. However, the patch only works for MPE/iX 5.0 at this writing, and HP is holding off on a release of it until they can protect systems using 4.0 and 5.5 as well. Contact your Response Center rep for more details, and stay tuned here. We'll send an advisory along as soon as we hear the full patch is ready.

CALLING INTRINSICS FROM GNU C++
Mark Klein, whose able port of the C++ compiler has made possible many of the advances in MPE/iX compatibility with Unix systems, recently released code that makes it possible to call intrinsics directly from the compiler on HP 3000s. The compiler, known as gcc among its users, is the object oriented tool of choice for MPE/iX systems. Mark gives us the details:

"When I ported gcc, it was with the intention that it would use the Posix library (/lib/libc.a) or native C (LIBC.LIB.SYS) library and not directly call intrinsics. However, calling intrinsics is possible. A couple of weeks ago I posted a group of routines that will assist in this endeavor. I've included them below again with another example. First off, many parameters to the intrinsics are long pointers. Since gcc doesn't directly know about long pointers (nor does it know about intrinsics), you'll have to build wrappers that will construct the long pointers and then invoke the real intrinsic. I've thought about building a complete library like this for a long time, but I've been too busy just doing the necessary parts of the port that I haven't had time to go back. In any event, I'll give you an example (marginally tested) using the PRINT intrinsic. I'll also include in the example the method for obtaining the condition code. Can the compiler be invoked directly from the CI prompt? Yes, it can, but it will use POSIX semantics. In other words, all names will be interpreted as if you were running under the shell. Now for the example: Using Stan's CSEQ (available from Lund), you can get the calling sequence for the PRINT intrinsic:

Procedure PRINT (
   message      : anyvar record  ;        {R25, R26}
                                          {Address type = LongAddr}
   length       :        int16   ;        {R24}
   control      :        int16   )        {R23}
      uncheckable_anyvar

You may not need to understand all the goo below, but take note of the LONGPOINTER declaration and longaddr() procedure. With these two pieces, you should be able to call any intrinsic:

--- cut here ---

/*
 * Copyright, 1996 DIS International, Ltd. Permission is hereby given
 * to use this source code according to the GNU General Public License
 * as long as this copyright notice is also maintained intact.
 */

typedef struct {
  int           spaceid;
  unsigned int  offset;
  } LONGPOINTER;


int getspaceid(void *source)
  {
  /*
   * Given the short pointer, determine it's space ID.
   */

  asm("comiclr,= 0,%r26,%r28");
  asm("ldsid (%r0,%r26),%r28");
  };

LONGPOINTER longaddr(void *source)      // %r26 == offset
  {
  /*
   * Return the long pointer for the address in sr5 space.
   */

  asm("or %r26,%r0,%r29");
  asm("comiclr,= 0,%r26,%r28");
  asm("ldsid (%r0,%r26),%r28");
  };

void longmove(int len,                  // %r26 == byte length
              LONGPOINTER source,       // %r23 == source space, %r24 == off
              LONGPOINTER target)       // sp-#56 == target space, sp-#52== off
  {
  /*
   * Move data between two buffers in long pointer space.
   */

  /*
   * This goo is to remove data from arg0-arg3 and place it in the frame
   * since these registers are needed for the millicode call.
   */
  int bytelen = len;
  int srcspace = source.spaceid;
  int srcoff   = source.offset;
  int trgspace = target.spaceid;
  int trgoff   = target.offset;

  asm(".import $$lr_unk_unk_long,MILLICODE");
  /*
   * The colons separate output from input parameters. In this case,
   * there are no output references from the instructions. The "m"
   * constraint indicates that the following token is a memory reference.
   * The general format is:
   *   asm("" : 
 : );
   *     where 
 and  are:
   *       "" ()
   *      is the PA-RISC instruction in template fmt.
   * Refer to the gcc documentation or http://www.dis.com/gnu/gcc_toc.html
   */
  asm("ldw %0,%%r1"     :: "m" (srcspace));     // load source space to %r1
  asm("mtsp %r1,%sr1");                         // copy source space to %sr1
  asm("ldw %0,%%r26"    :: "m" (srcoff));       // load source offset to %r26
  asm("ldw %0,%%r24"    :: "m" (len));          // load length to %r24
  asm("ldw %0,%%r25"    :: "m" (trgoff));       // load target offset to %r25
  asm("ldw %0,%%r1"     :: "m" (trgspace));     // load target space to %r1
  asm("bl $$lr_unk_unk_long,%r31");             // start branch to millicode
  asm("mtsp %r1,%sr2");                         // copy target space to %sr2
  };

int longpeek(LONGPOINTER source)        // %r25 == spaceid, %r26 == offset
  {
  /*
   * Fetch the int in long pointer space.
   */
  asm("mtsp %r25,%sr1");
  asm("ldw 0(%sr1,%r26),%r28");
  };

void longpoke(LONGPOINTER target,       // %r25 == spaceid, %r26 == offset
          unsigned int val)             // %r24 == value
  {
  /*
   * Store the val into long pointer space.
   */
  asm("mtsp %r25,%sr1");
  asm("stw  %r24, 0(%sr1,%r26)");
  };

void move_fast(int len,                 // %r26 == byte length
               void *src,               // %r25 == source addr
               void *trg)               // %r24 == target addr
  {
  /*
   * Move using short pointers.
   */
  asm(".import $$lr_unk_unk,MILLICODE");
  asm("or %r26,%r0,%r1");               // Copy length to %r1 (temp)
  asm("or %r25,%r0,%r26");              // Move source addr into position
  asm("or %r24,%r0,%r25");              // Move target addr into position
  asm("bl $$lr_unk_unk,%r31");          // Start branch to millicode
  asm("or %r1,%r0,%r24");               // Move length into position
  };

main()
  {
  char *buf = "this is a test!";
  char  buf1[80];
  int   ccode;

  extern int    CCODE();

  extern void   PRINT(LONGPOINTER lp,
                      short       length,
                      short       control);

  LONGPOINTER lp_buf = longaddr(buf);
  PRINT(lp_buf,-strlen(buf),0);
  ccode = CCODE();

  sprintf(buf1, "ccode from PRINT call: %d\n",ccode);
  PRINT(longaddr(buf1),-strlen(buf1),0);
  };

HIDDEN VALUE: RENAMING AN ACCOUNT, CLARIFIED
NewsWire subscriber Evan Rudderow was good enough to help clarify an answer in our recent Hidden Value column of November about renaming accounts. Evan's tips and steps expand the process to make it suitable for more than just moving TurboIMAGE databases,and we're including them here.

"On page 14 of the November NewsWire there's a misleading answer in the Hidden Value column; the question was:

'What's an easy way to rename an account -- or can this even be done at all? I'm spending lot's of time storing and purging, only to restore to a different account.'

The response given was:

'You can do this through DSCOPY using the MOVE. It takes two commands but gets the job done:

DSCOPY base.grp.acct;@.grp2.acct2;fcode=-400;move
DSCOPY base##.grp.acct;@grp2.acct2;fcode=-401;move

Don't forget to change internal references in the restored file to refer to the new account.'

Actually, the published answer gives only the solution for moving a TurboIMAGE data base from one account to another. To move the non-privileged files in the account you'd have to do a:

DSCOPY @.@.acct;@.@.acct;move (although this might have to be done on a group by group basis; e.g:

DSCOPY @.grp1.acct;@.grp1.acct2;move
DSCOPY @.grp2.acct;@.grp1.acct2;move etc. )

Furthermore, DSCOPYs will have to be done for each unique negative file code; a quick perusal of one of my systems shows that some other common privileged file codes are:

     -430 IMAGE/SQL Turbo Connect file
     -431 IMAGE/SQL ATCINFO file
     -491 Allbase/SQL DBECon file
     -493 Allbase/SQL DBEFile
     -497 Allbase/SQL Log file

And, of course, since the IMAGE/SQL ATTACH process internally records fully qualified file names, you'd never want to move either or both components (the TurboIMAGE database and Allbase/SQL DBE) of an IMAGE/SQL pair without first performing a DETACH. Also, I'm not sure that an Allbase DBE can be successfully DSCOPY'd; I seem to recall using STORE/RESTORE to move and Allbase DBE from one account to another once and having been tripped up by Allbase's practice of keeping fully qualified file names internally.

Finally, the last sentence in the published response, "Don't forget to change internal references in the restored file to refer to the new account," cannot be stressed enough! In fact at my site we have documented the procedures for setting up and refreshing test accounts (both accounts of the same name on other systems and accounts with different names on the same system as the production account); between the general guidelines and account specific instructions the documentation runs to 16 pages.

Copyright 1996, The 3000 NewsWire. All rights reserved.