ftp.robelle3000.ai 2017

home *** CD-ROM | disk | FTP | other *** search

/ ftp.robelle3000.ai 2017 / ftp.robelle3000.ai.tar / ftp.robelle3000.ai / newsletter / 1997 / w1997-04.txt < prev next >

Wrap

Text File | 1997-08-05 | 23KB | 581 lines

What's Up, DOCumentation? Robelle Consulting Ltd. Unit 201, 15399-102A Ave. Surrey, B.C. Canada V3R 7K1 Toll-free: 1-888-ROBELLE (1-888-762-3553) Phone: (604) 582-1700 Fax: (604) 582-1799 E-mail: support@robelle.com Web: www.robelle.com Date: August 1997 From: Robert M. Green, CEO David J. Greer, President Hans Hendriks, Editor pro tem To: Users of Robelle Software Re: News of the HP 3000 and of HP-UX, 1997 #4 What You Will Find in This News Memo: HP World Debut of Qedit for Windows Year 2000 Video Conference SmartDate from Robelle: Part of the Year 2000 Cure Character Set Confusion New Schedule for Suprtool Training Suprtool DEFINEs Selecting a Range of Non-Collating Dates Compatibility with MPE/iX 5.5 Looper: Qedit's Best Command File HP World ========= It's August, which means that it is HP World month at Robelle. HP World is the premier event organized by Interex, the International Association of Hewlett Packard Computing Professionals. This year's conference runs from August 25 - 29 at the Navy pier in Chicago, Illinois, and as always, it looks like there will be more to see and learn than any mortal can possibly absorb in the few days of the conference. (See http://www.hpworld.com for details.) Attached to this newsletter is an information sheet showing what we at Robelle have planned for this conference. Visit our booth for a personal demonstration of Qedit for Windows, or pick up a schedule of the papers and tutorials we'll be presenting this year. We'll also be celebrating our 20th birthday, so be sure to enter our prize draw and enjoy some birthday cake. Our technical presentations this year include Bob Green's paper on some of the design decisions made for Qedit for Windows, Neil Armstrong's Introduction to HP-UX for MPE Users, Francois Desrochers' tutorial on creating Web pages with Suprtool, the Suprtool Developers' Forum, as well as David Greer's collaboration with Alfredo Rego in How Messy is My Database. David will also be a panelist in the Application Development in a Multi- Platform Environment discussion. Mike Shumko will be presenting an updated version of our Ensuring Data Integrity Using Suprtool tutorial. Trade Shows: A Behind the Scenes Look Anyone who has ever attended an Interex or HP World vendor show area and has never been involved with setting up a booth for an attending company may wonder what is involved. It looks like magic as workers and company staff assemble the booth in a matter of hours. What you are watching is the culmination of approximately one full year of planning. At the Chicago show this year, we will have to choose a booth for the 1998 show in San Diego. This year's conference is where the planning for the next year begins. Once we get back to the office we review what we liked about the equipment, our presentations, booth layout, staffing levels, etc., and also what we didn't like. All this information gets fed into the planning loop for next year as part of the iterative process. One of the next things we do is plan our presentations for next year. All of this information gets passed to Interex, which either accepts or rejects our submissions. The support staff attending the show is chosen based partly on the selections made by Interex. The other parts of planning include shipping support materials, such as manuals, copies of papers and tutorials, supplies, promotions, etc. If we're going to have a contest, the forms and prizes have to be prepared and purchased, plus our pre-show mailings need to mention the contest so that people know about it. When we are in a new city, we can't count on all the things we take for granted at home and in the office. The items we may miss can be as simple as felt pens, wrapping paper, tape, ruler, scissors, etc. That's why planning for every possibility before we leave is so important. Just as when we go on vacation, we may know there is something we missed, but we just don't know what it is until we get there. This year we distributed the conference workload as follows: two staff members working out the technical details for the show, one person in charge of papers and tutorials, two people working on shipping, two people on promotions, and two people working on all the other details. This is a major team effort. Our booth number this year is #1519--hope to see you there! [Marie Reimer] Debut of Qedit for Windows ========================== "When will Qedit for Windows be ready?" We're hearing this question frequently these days at Robelle. Here's a quick update. Qedit for Windows (QWIN) alpha test tapes were sent out at the end of June -- many thanks to our alpha testers! By the time you receive this edition of What's Up DOCumentation?, we should be into our second round of alpha testing. We are still enhancing QWIN's functions and features, but our #1 priority is exterminating any last bugs in the alpha versions. We plan to make QWIN as robust and reliable as our other products! We will be unveiling QWIN at HP World in Chicago, August 25 - 29. And for those attending this year, we look forward to giving you a personal QWIN demo. Also, be sure to catch Bob Green's presentation, Converting Qedit to the Client/Server Model. We're not quite ready to send out evaluation copies of QWIN, but we are certainly getting close. Our sales department is keeping a running list of people who have expressed interest. And as soon as QWIN is officially released, we will be contacting you to arrange a demo. For more information on QWIN, visit our QWIN Web page at http://www.robelle.com/products/qeditwin.html [Nicky Gunther] Year 2000 Video Conference ========================== Marie attended the "Cure2000" video conference hosted by HP at their Richmond, B.C. office in June. For this presentation George Stachnick was an excellent host, and attendees each received a copy of the HP White Paper entitled Cure2000 for the HP3000, which is full of recommendations, products, and services to help in the conversion process. HP expects that there are 150 billion lines of code written and being used by HP computers. If companies start converting today to become compliant, it will cost them $1-2 per line of code, and the cost increases as time runs out. The status of the HP operating systems was laid out as follows: - MPE V 3.0 and 4.0 are ready and the patches are available by calling the Response Center. - MPE/iX 5.5 with Xpress 4 is year-2000 compliant. - MPE/iX 6.0 will be available in the first half of 1998. The follow-up video conference scheduled for September will provide more information about the availability of these developments. Also detailed were the changes HP has made to its own software such as the various new date handling intrinsics. Pre-release versions of these are available from the Jazz Web site at jazz.external.hp.com. HP is urging customers to contact all their solution vendors directly to ascertain the state of year-2000 readiness in their applications. Included in the handout was a list of on-line resources. Some of the most comprehensive sites are the Year 2000 Information Center at www.year2000.com and the HP sites at www.hp.com/go/year2000. Also worth a visit is Robelle's site of frequently asked questions: www.robelle.com/faq/year2000.html [Marie Reimer and Robyn Rennie] SmartDate from Robelle: Part of the Year 2000 Cure =================================================== If you're currently working on your year 2000 conversion or are planning to start soon, consider using SmartDate from Robelle. How does SmartDate help with year-2000 conversions? One of the problems with converting a program to make it year-2000 compliant is dealing with the differences between dates in external, human-readable format, and dates in internal, computer-friendly format. SmartDate helps by providing a number of features that allow users to enter dates in convenient formats. SmartDate easily converts those dates into whatever format the data structures require. For example, users may be accustomed to entering dates in month-day-year format, specifying only two digits for the year, and not typing a leading zero on a day or month that has only one digit. But you may have converted the database to store dates in an I2 field (4-byte integer) as 8-digit values in century-year-month-day format. SmartDate can do all this in one call: - accept free-format input - verify that a valid date was entered - apply a 2-digit to 4-digit cutoff rule on the year - convert to CCYYMMDD format for the program An example of the year cutoff rule would be, "any 2-digit years between 80 and 99 should be interpreted as 19xx, and 2-digit years between 00 and 79 should be interpreted to be 20xx." In SmartDate this would be a "cutoff" value of 80. Sample COBOL source code: accept input-date move RdtXnMMDDCCYY to rdt-from-type move RdtI32CCYYMMDD to rdt-to-type add RdtYearCutoff to rdt-from-type move 80 to rdt-aux-result call "RDTCONVERT" using input-date , output-date, rdt-control if rdt-status <> 0 then call "RDTERROR" using rdt-control, msg-buffer, msg-buf-length display msg-buffer. SmartDate can also format dates for human-readable output, so that they look good on reports. For example, Jul 14, 1997 Mon, Jul 14, 1997 JUL14 97 SmartDate accepts dates in any of 24 formats, including 3 free-form formats, converting them to any of 28 formats. SmartDate handles years from 1583 to 2583 and knows about leap years (yes, 2000 is a leap year). Visit our Web site or call us to receive your free 30-day SmartDate trial package. [Mike Shumko] Character Set Confusion ======================= One perennial issue in the lives of computer folks is that of character sets. This came up again recently in the HP3000-L Internet discussion list, where the following question appeared: Date: Mon, 23 Jun 1997 21:04:20 -0400 Subject: How to use FTP transfer French characters from HP3000 to NT server? We have a MPE file on HP3000 which has some info in French. When I use FTP to transfer it from HP3000 to NT server. Those French characters changed. For example, the 3rd character of "QUEBEC" should be a prime on top of "E". But it changed to two "." on top of "U" after file transfer. I tried to set FTP into ASCII, BINARY and BYTESTREAM mode. It doesn't help. And I tried to send this file to HP9000 UNIX server and then send it from UNIX to NT server. It doesn't help too. But if I use Reflection to transfer this file, all those French characters transferred correctly. But I don't want to use Reflection to do it because Reflection transfer cannot write into a MPE job. That file changes everyday. I don't want to do this transfer manually every day. If anybody has experiences in special characters transfer with FTP, please give me some suggestions. David Greer replied to this as follows: I don't have a specific answer to the question, but I can give some background on the problem. Characters on MPE (and HP-UX) are stored using the HP Roman-8 character set. Characters on Windows NT are generally stored as UNICODE (or the MS Windows character set). Characters in both character sets are represented as a digit number. Every number corresponds to an individual letter and visa-versa (at least as far as Latin-ISO-1 characters are concerned). For the ASCII characters (letters, numbers, and North American special symbols), the numeric representation is the same in both HP's Roman-8 character set, UNICODE, and the MS Windows character set. But for Latin-ISO-1 characters with a numeric value greater than 127, there are differences between these character sets. When you transfer a file with FTP, the numeric values are correctly transferred to Windows NT. But on MPE lower-e-accent is represented by the numeric value 197, and in Windows NT the value 197 is a capital-A with a circle above it. So why does the transfer work with Reflection? The reason is that Reflection is aware of these character differences and does a good job of doing the necessary translations as part of the file transfer. My guess is that you won't be able to use FTP to transfer the file and get character translation. You could use FTP, if you were willing to write either: 1. A program on MPE that pre-translated the file before transferring it with FTP, or 2. A program on Windows NT that post-translated the file after transferring it with FTP. For more information about character sets see our SMUG Book entry: http://www.robelle.com/smugbook/char.html [David Greer] New Schedule for Suprtool Training =================================== Here is Robelle's new schedule of in-house courses for Suprtool in 1997-98: October 16 - 17, 1997 January 23 - 24, 1998 May 28 - 29, 1998 October 15 - 16, 1998 For more information about the schedule or to arrange a private session at your site, call Rosemary Van Poelgeest or Fran Glasgow at 1-888-ROBELLE. Robelle Products: Problems, Solutions and Suggestions ------------------------------------------------------ Suprtool DEFINEs ================= A recent question on the Robelle-L mailing list prompted a discussion of Suprtool's Define command: Question: I have an I1 item in a set and I need to check the value of the first digit of each number in each entry. The maximum number for the item is 9999. I have tried to convert the I1 to a byte field then test the value using the offset. Campus-bldg is the I1 item. def a,campus-bldg,6,byte def b,a[2],1 if b = ("2","3,"4") ext campus-bldg output campbldg I'm getting junk for some reason even if I output as ASCII. Answer: What is not obvious at first is that Define commands are just redefinitions of the input record. Defines do not create new storage, and they do not convert data from one format to another. If you are a COBOL programmer, think of the REDEFINES clause. Therefore your Define commands told Suprtool this: def a,campus-bldg,6,byte Hey, Suprtool, I want to give the six bytes of my input record, starting at the same position as campus-bldg, a name of A. If campus-bldg started at byte 37 of the input record (for a length of 2 bytes because it is an I1), the field A will also start at byte 37, but will go for a length of 6. The thing called A will have all 16 bits of campus-bldg plus the next 4 bytes. This definitely won't work. def b,a[2],1 Now you're telling Suprtool to treat the second byte of A (which is the second byte or rightmost eight bits of campus-bldg) as a field called B. This still doesn't work. The standard answer to the generic question, "How do I test a single digit of a binary number" is, "You need to use two passes." Let's see how to do this the standard way, then let's see some one-pass solutions for this specific case. Two passes: get <dataset> extract <all the desired fields including campus-bldg> output <filename>,ascii xeq input <filename> define a,<position of the thousands digit in the ascii-field campus-bldg>,1,byte if a = "2","3","4" ... The downside of this approach is that all the numeric fields that you extracted are now in ASCII format. The resulting file may not be compatible with whatever program is supposed to read the output. Three(!) passes: get <dataset> define a,1,<length of whole record in bytes>,byte extract a extract campus-bldg output <filename>,ascii xeq input <filename> define b,<position of the thousands digit in the ascii-field campus-bldg>,1,byte if b = "2","3","4" extract a output <filename2> input <filename2>=<dataset> ... With this approach the output record produced by the second pass still has all the input fields in their original format. The input filename=dataset syntax tells Suprtool to trust you that the input file has the same layout as the dataset. That way you can use all the dataset's fieldnames when reading the file. One pass (style A): Assuming that I understand correctly that you have an I1 field whose values never exceed 9999, and you want to select records if the thousands digit is a 2, 3, or 4, you could just do this: input <dataset> if campus-bldg >= 2000 and campus-bldg <=4999 ... This works only because we are testing the high-order or most-significant digit. This wouldn't work if we were trying to test for one of the other digits. One pass (style B): input <dataset> if campus-bldg / 1000 = 2,3,4 ... Again, this works only for testing the most significant digit. [Mike Shumko] Selecting a Range of Non-Collating Dates ========================================= Almost all of Suprtool's date selection functionality relies on converting a date value to a numeric constant, and using that for selection against the (numeric) date field. For example, > item sale-date,date,yymmdd > if sale-date = $today is logically identical to entering > if sale-date = 970805 assuming, of course, that today is 5 August 1997. Notice that Suprtool converts the selection criteria to match the data format, rather than reformatting each data record to do the comparison. This works well for all date formats when testing for equivalence, but fails for range testing in non-collating date formats. For example, if a date is stored in MMDDYY format, any December date will always have a higher numeric value than any January date, irrespective of the year value. If you try to do a range selection on a non-collating date field, Suprtool will return an error: >item purch-date,date,mmddyy >if purch-date < $today Error: Invalid date format for the comparison Question: So how can I select a range of non-collating dates? Answer: By testing for equivalence to each date that falls in the range. Question: How can I test for all those values? Answer: Load a table of qualified date values. Question: How can I get the qualified values? Answer: With Suprtool, of course! First, create a file of all unique date values in the dataset and include a new field with the date value in Display format: >base store.db.sales,1,password >get d-sales >sort purch-date {purch-date is in MMDDYYYY format} >define new-date,1,8,display >extract purch-date, new-date = purch-date >output datefil1,link >duplicate none keys {only 1 record per unique field} >xeq You now have a file with the date field represented twice, once in original format, and once in Display format. Now convert the Display field to a collating date format: >input datefil1 >define year,new-date[5],4,display >define monthday,new-date[1],4,display >extract year, monthday, purch-date >output datefil2,link >xeq Now that we have the date values in a collating format, we can select the range of dates we require: >input datefil2 >define colldate,1,8,display >item colldate,date,YYYYMMDD >if colldate >= $date(*-1/*/01) & and colldate <= $date(*-1/*/last) >extract purch-date >sort purch-date >output datefil3,link We can now use datefil3 to load a table of valid dates: >get d-sales >table datetabl,purch-date,sorted,datefil3 >if $lookup(datetabl,purch-date) ... If you need to do this on a regular basis, it makes sense to create a permanent "translation file", rather than regenerating it each time. [Hans Hendriks] Compatibility with MPE/iX 5.5 ============================== One of the most frequently asked questions is: What version of Qedit and Suprtool do I need for MPE/iX 5.5? We recommend Qedit version 4.4 or later, and Suprtool version 3.8 or later. Remember that when you upgrade your operating system you may need to stream some Robelle jobs to integrate Qedit or Suprtool into the new system. For example, stream Qcompxl.Qeditjob.Robelle to let your native mode compilers read Qedit-format source files, or re-install the Speed Demon or Suprtool2 routines if you need them in SL.Pub.Sys. See the installation section of your user manuals for details. Looper: Qedit's Best Command File ================================== We occasionally get customers asking how to change or delete lines based on the existence of a string in a neighboring line. This usually means setting up a command file that does While loop processing. You can find a great example of a command file called Looper in the Qedit manual under the While command, but here is a variation that came up recently. The customer wanted to print any lines in which the first 3 characters were the same as the previous line's. HPVariables can be used to store the value of each line for comparison to the next, but how can you set a variable to the contents of the line? We created the command file Qsetvar.Cmd to accept a variable name as a parameter, then prompt for the variable's value: Qsetvar.Cmd: parm varname input !varname setvar !varname rtrim(!varname) This way, the contents of a line can be saved in the Hold file, and the contents of the Hold file can be passed to the command file by means of I/O redirection: qsetvar myvar < hold Our second command file saves the contents of each line, compares it to the next, then saves the contents of that line for comparison to the subsequent line, and so on: /set window (up) {ignore case for strings} setjcw cierror = 0 {initialize variables to predictable values} setvar prev,"#" setvar curr," " continue /set right 3 {edit only columns 1 to 3 of each line} /list first {go to top of file} while cierror=0 do /holdq * {copy current line to Hold file} /qsetvar curr < hold (set variable "curr" to whatever is in Hold} if prev = curr then {compare current line to previous} /list * lp {if same, send to printer} endif setvar prev,curr {update value of prev} /lq*+1 {move forward one line} endwhile [Paul Gobes] Qedit, Suprtool, SmartDate, and Xpress are trademarks of Robelle Consulting Ltd. Windows is a trademark of Microsoft Corporation. Other product and company names mentioned herein may be the trademarks of their respective owners.