net.digest March 1998

Click here for RAC sponsor message

Net.digest summarizes helpful technical discussions on the HP 3000 Internet newsgroup. Advice here is offered on a best-effort, Good Samaritan basis. Test these concepts for yourself before applying them to your production or development HP 3000s.

Analysis by John Burke

Does Patch/iX need patching?

Net.digest summarizes helpful technical discussions on the HP 3000 Internet newsgroup. Advice here is offered on a best-effort, Good Samaritan basis. Test these concepts for yourself before applying them to your production or development HP 3000s.

Analysis by John Burke

Ah ha! A gotcha in detail deleting

There was a thread a while ago discussing what happens when all the entries in a detail dataset are deleted programmatically. The consensus was that the delete chain head is reset and subsequent DBPUTs start with the first record, then the second and so on (IMAGE tries to use entries from the delete chain first when doing DBPUTs).

It turns out there is a circumstance under which this is not true. Stan Sieler noted it very succinctly after I questioned the list about reasons for some strange behavior I had noticed:

“For the last DBDELETE from a detail dataset:

“If the DBDELETE is done within a DBXBEGIN/DBXEND then don’t reset the highwater mark and don’t clear the free chain.

“If the DBDELETE is not done within a DBXBEGIN/DBXEND then reset the highwater mark to 0, and zero the head of the free chain in the user label. (Note: the actual contents of the free chain aren’t touched, as explained by Alfredo Rego and Rene Woc of Adager a few weeks ago.)

“I’m not sure why the difference is based on DBXBEGIN, but it’s there.”

The difference, according to HP, is to ensure that the transaction can be rolled back if necessary. Which of course is the point in using DBXBEGIN/DBXEND. Unfortunately, this behavior does not appear to be documented anywhere and was known until recently only to a few, if any, people outside of the IMAGE lab.

So who cares, you ask? Isn’t one of the reasons for the existence of database management systems the shielding from the user of the messy details of pointers and position? True enough. However, the difference becomes important if you are using dynamic rollback recovery (DBXBEGIN/DBXEND encapsulated transactions) and Netbase/Shareplex under TPS (Third Party Shadowing).

When DBXBEGIN/DBXEND IMAGE transactions are made on the master machine of a master/shadow system – and they result in the deletion of all records from a detail dataset – the delete chain is not reset. That means subsequent DBPUTs are therefore located according to this delete chain. On the shadow side, the posting process makes only non-DBXBEGIN/DBXEND IMAGE calls. What it all boils down to is that in this case, these calls result in the delete chain being reset and subsequent DBPUTs starting with the first record and so on. Netbase/Shareplex detects this inconsistency as an error and the database is flagged as out of sync. [Editor’s note: We are considering a future TestDrive of Netbase/Shareplex if interest warrants. For now this very condensed explanation of how shadowing is done will have to suffice.]

If you use Netbase/Shareplex, be advised that Quest and HP are working on a solution to the problem that should be available by the time you read this. A work-around is to put a bogus record that will never be deleted in each detail dataset that could ever be programmatically emptied by DBX transactions. You can also go back to the old (pre- TPS) version of shadowing databases with DBX transactions.

An IMAGE version that’s a gotcha

Staying with IMAGE gotchas for a minute, I wonder how many of you are on the 07.04 version of IMAGE that came with 5.5 Express 3? [If you are not sure what version you are on, run QUERY and issue the VERSION command.] This version is buggy at best. In fact, I had a Response Center engineer tell me that HP recommends that anyone on 07.04 move off it to something else. [The something else depends upon whether or not you are using dynamic detail expansion (DDX).] I guess I should add that another engineer later contradicted what the first engineer said. However, since we experienced two separate show-stopper problems with 07.04, I tend to side with the opinion of the first RC engineer.

So, you say, what is your point, John? Actually, I have two. My first point is more a concern about the stability of IMAGE. I cannot remember a time when there were so many problems with IMAGE. I have to wonder whether sufficient funds are being funneled to IMAGE development and resources such as people. Just who is working on IMAGE these days? (I’d consider this a fitting topic for the upcoming MPE Programmer’s Forum.)

My second point is: How is a system manager supposed to know what version of any software is the “best” for his system? Information about problems and solutions is not made available to customers in a form that is usable. I subscribe to the HP Support Center’s Patch Digest e-mail messages, but have found them hopelessly impossible to digest (pun intended). It is apparently a further example of the problem that is as old as the computer industry itself: having programmers and developers write documentation almost guarantees unreadable documentation.

The Patch Digest is as close to unreadable as it gets. The description of the patch that takes IMAGE to 07.06 makes only passing note of the system hang on a locked global IMAGE SIR that twice halted our primary production system. And it certainly gave no indication of exposure: i.e., under what circumstances it is likely to occur. The patch description says nothing at all about the other problem we had that – it turned out – was corrected by this patch.

All of this provides the perfect segue to:

The sorry state of the ESC, and some hope

This thread keeps reappearing every few months. And for good reason. I quote Stan Sieler (unedited) who started it up this time:

“Ok...I had to use HP ESC [Electronic Support Center]again today .......what a piece of junk. Does anyone have any idea how we can get HP to provide a GOOD system? One that actually separates MPE from HP-UX from NT from Sparc? One where boolean searches actually work correctly? One where we have a non-censored, full database?

“I’ve complained, badgered, whined for years ... with no results. I’ve asked the so called “HP Management Roundtable” ... with no results. I’ve had one-on-one discussions with HP Support engineers/managers ...with no results. We pay money for HP ESC .... maybe we should be billing HP for time wasted using it.”

Sieler has perhaps been the most vocal, but I am sure that anyone who has tried to research a problem using the ESC will agree with the above sentiment. I know I do. I carried the banner at the Support Roundtable during HP World ’97, cornering several HP Managers afterward. Perhaps the most amazing thing about our conversations was their apparent ignorance of the complaints. We did the typical HP exchange of business cards and I went home sure it would be improved.

Of course as the “sorry state of the ESC” thread shows, at least the Technical Knowledge Database part of ESC has not improved. To be fair, some parts of the ESC are very good. I have had excellent experience using the Software Call Manager instead of calling the Response Center. One obvious advantage is that you can describe the problem in your own words without having it filtered through someone else. Response (frequently by telephone) has always been within the time frame requested.

But then there is the sorry state of the Technical Knowledge Database. I dredged out the card from one of the HP managers I spoke with last August (pretty high up on the Support Division food chain) and sent off an e-mail copying Stan’s post. I noted again my contention that the inadequacies of the Technical Knowledge Database cost HP money since many calls are made to the RC because the information could not be obtained in the TKDB. Several weeks later I received a reply that included several internal memos. I do not have permission to release any details, but it appears that there will be a significant improvement in the Technical Knowledge portion of the ESC that we should see as early as March but more likely by May. Until then, you might try this suggestion from one of the memos to improve your results:

“There is a short-term workaround that customers could use. Customers could use the boolean search option (instead of the descriptive search) and add ‘not hp-ux not s700 not s800’ to their search string. It is certainly inconvenient, but it offers a short-term solution which specifically addresses the issue identified.”

Unfortunately, I doubt there will be anyone at the upcoming MPE Programmer’s Forum this month from the support organization. However, The 3000 NewsWire will be following this and will report as soon as information can be made public on the ESC improvements.

Copyright 1998, The 3000 NewsWire. All rights reserved.




		Click here for RAC sponsor message
		Net.digest summarizes helpful technical discussions on the HP 3000 Internet newsgroup. Advice here is offered on a best-effort, Good Samaritan basis. Test these concepts for yourself before applying them to your production or development HP 3000s. Analysis by John Burke Does Patch/iX need patching? Net.digest summarizes helpful technical discussions on the HP 3000 Internet newsgroup. Advice here is offered on a best-effort, Good Samaritan basis. Test these concepts for yourself before applying them to your production or development HP 3000s. Analysis by John Burke Ah ha! A gotcha in detail deleting There was a thread a while ago discussing what happens when all the entries in a detail dataset are deleted programmatically. The consensus was that the delete chain head is reset and subsequent DBPUTs start with the first record, then the second and so on (IMAGE tries to use entries from the delete chain first when doing DBPUTs). It turns out there is a circumstance under which this is not true. Stan Sieler noted it very succinctly after I questioned the list about reasons for some strange behavior I had noticed: “For the last DBDELETE from a detail dataset: “If the DBDELETE is done within a DBXBEGIN/DBXEND then don’t reset the highwater mark and don’t clear the free chain. “If the DBDELETE is not done within a DBXBEGIN/DBXEND then reset the highwater mark to 0, and zero the head of the free chain in the user label. (Note: the actual contents of the free chain aren’t touched, as explained by Alfredo Rego and Rene Woc of Adager a few weeks ago.) “I’m not sure why the difference is based on DBXBEGIN, but it’s there.” The difference, according to HP, is to ensure that the transaction can be rolled back if necessary. Which of course is the point in using DBXBEGIN/DBXEND. Unfortunately, this behavior does not appear to be documented anywhere and was known until recently only to a few, if any, people outside of the IMAGE lab. So who cares, you ask? Isn’t one of the reasons for the existence of database management systems the shielding from the user of the messy details of pointers and position? True enough. However, the difference becomes important if you are using dynamic rollback recovery (DBXBEGIN/DBXEND encapsulated transactions) and Netbase/Shareplex under TPS (Third Party Shadowing). When DBXBEGIN/DBXEND IMAGE transactions are made on the master machine of a master/shadow system – and they result in the deletion of all records from a detail dataset – the delete chain is not reset. That means subsequent DBPUTs are therefore located according to this delete chain. On the shadow side, the posting process makes only non-DBXBEGIN/DBXEND IMAGE calls. What it all boils down to is that in this case, these calls result in the delete chain being reset and subsequent DBPUTs starting with the first record and so on. Netbase/Shareplex detects this inconsistency as an error and the database is flagged as out of sync. [Editor’s note: We are considering a future TestDrive of Netbase/Shareplex if interest warrants. For now this very condensed explanation of how shadowing is done will have to suffice.] If you use Netbase/Shareplex, be advised that Quest and HP are working on a solution to the problem that should be available by the time you read this. A work-around is to put a bogus record that will never be deleted in each detail dataset that could ever be programmatically emptied by DBX transactions. You can also go back to the old (pre- TPS) version of shadowing databases with DBX transactions. An IMAGE version that’s a gotcha Staying with IMAGE gotchas for a minute, I wonder how many of you are on the 07.04 version of IMAGE that came with 5.5 Express 3? [If you are not sure what version you are on, run QUERY and issue the VERSION command.] This version is buggy at best. In fact, I had a Response Center engineer tell me that HP recommends that anyone on 07.04 move off it to something else. [The something else depends upon whether or not you are using dynamic detail expansion (DDX).] I guess I should add that another engineer later contradicted what the first engineer said. However, since we experienced two separate show-stopper problems with 07.04, I tend to side with the opinion of the first RC engineer. So, you say, what is your point, John? Actually, I have two. My first point is more a concern about the stability of IMAGE. I cannot remember a time when there were so many problems with IMAGE. I have to wonder whether sufficient funds are being funneled to IMAGE development and resources such as people. Just who is working on IMAGE these days? (I’d consider this a fitting topic for the upcoming MPE Programmer’s Forum.) My second point is: How is a system manager supposed to know what version of any software is the “best” for his system? Information about problems and solutions is not made available to customers in a form that is usable. I subscribe to the HP Support Center’s Patch Digest e-mail messages, but have found them hopelessly impossible to digest (pun intended). It is apparently a further example of the problem that is as old as the computer industry itself: having programmers and developers write documentation almost guarantees unreadable documentation. The Patch Digest is as close to unreadable as it gets. The description of the patch that takes IMAGE to 07.06 makes only passing note of the system hang on a locked global IMAGE SIR that twice halted our primary production system. And it certainly gave no indication of exposure: i.e., under what circumstances it is likely to occur. The patch description says nothing at all about the other problem we had that – it turned out – was corrected by this patch. All of this provides the perfect segue to: The sorry state of the ESC, and some hope This thread keeps reappearing every few months. And for good reason. I quote Stan Sieler (unedited) who started it up this time: “Ok...I had to use HP ESC [Electronic Support Center]again today .......what a piece of junk. Does anyone have any idea how we can get HP to provide a GOOD system? One that actually separates MPE from HP-UX from NT from Sparc? One where boolean searches actually work correctly? One where we have a non-censored, full database? “I’ve complained, badgered, whined for years ... with no results. I’ve asked the so called “HP Management Roundtable” ... with no results. I’ve had one-on-one discussions with HP Support engineers/managers ...with no results. We pay money for HP ESC .... maybe we should be billing HP for time wasted using it.” Sieler has perhaps been the most vocal, but I am sure that anyone who has tried to research a problem using the ESC will agree with the above sentiment. I know I do. I carried the banner at the Support Roundtable during HP World ’97, cornering several HP Managers afterward. Perhaps the most amazing thing about our conversations was their apparent ignorance of the complaints. We did the typical HP exchange of business cards and I went home sure it would be improved. Of course as the “sorry state of the ESC” thread shows, at least the Technical Knowledge Database part of ESC has not improved. To be fair, some parts of the ESC are very good. I have had excellent experience using the Software Call Manager instead of calling the Response Center. One obvious advantage is that you can describe the problem in your own words without having it filtered through someone else. Response (frequently by telephone) has always been within the time frame requested. But then there is the sorry state of the Technical Knowledge Database. I dredged out the card from one of the HP managers I spoke with last August (pretty high up on the Support Division food chain) and sent off an e-mail copying Stan’s post. I noted again my contention that the inadequacies of the Technical Knowledge Database cost HP money since many calls are made to the RC because the information could not be obtained in the TKDB. Several weeks later I received a reply that included several internal memos. I do not have permission to release any details, but it appears that there will be a significant improvement in the Technical Knowledge portion of the ESC that we should see as early as March but more likely by May. Until then, you might try this suggestion from one of the memos to improve your results: “There is a short-term workaround that customers could use. Customers could use the boolean search option (instead of the descriptive search) and add ‘not hp-ux not s700 not s800’ to their search string. It is certainly inconvenient, but it offers a short-term solution which specifically addresses the issue identified.” Unfortunately, I doubt there will be anyone at the upcoming MPE Programmer’s Forum this month from the support organization. However, The 3000 NewsWire will be following this and will report as soon as information can be made public on the ESC improvements.
		Copyright 1998, The 3000 NewsWire. All rights reserved.