What's Up DOCumentation Robelle Consulting Ltd. 8648 Armstrong Rd., R.R.#6 Langley, B.C. Canada V3A 4P9 Telephone: (604) 888-3666 Telex: 04-352848 Fax: (604) 888-7731 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. (800) 648-6004. 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 08/35 46 66. 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: (805) 652-4179. 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}