Alpha to Itanium DCL issue

Mon Aug 24 15:33:52 CDT 2015

Wow, we migrated to Itanium several years ago and noticed no sort issues. We were on RMS files though, and it seems to be a common thread that Rdb users are having more problems.

From: powerh-l-bounces+rwitkopp=phxa.com at lists.sowder.com [mailto:powerh-l-bounces+rwitkopp=phxa.com at lists.sowder.com] On Behalf Of Lorry Litman
Sent: Monday, August 24, 2015 1:20 PM
To: 'Thomson, Martyn'; 'HERALD KAFFKA'; 'powerh-l at lists.sowder.com'
Subject: RE: Alpha to Itanium DCL issue

Martyn, that's great you were able to isolate the RDB error.

I wasn't aware of the sort issue Herald mentioned but certainly something I'll make note of.

The following I add in case someone is running older software/hardware and has experienced some oddities.

We are running VMS 7.3-2 and PH 7.10.E6 & 7.10.G1 and Oracle RDB 7.0-1 on Alpha ES47 machines.

This past year when we upgraded VMS from 7.3-1 to 7.3-2, minimum version for HP support, and for our disk storage upgrade and changed machines from GS160 to ES47 I ran into some odd behaviour.

A command procedure would be executing code, whether QTP or RDB SQL and the command procedure would just terminate. No error message, nothing in the log file.
This same process termination would also happen to user processes that were logged into and accessing application screens.
The other situation encountered is that sometimes QTP code (or RDB SQL) would execute but the process would hang. No CPU cycles or I/O, nothing, just hung.

we couldn't contact Unicom/Cognos or RDB for support because we are running unsupported versions (no support contract).

To try to isolate this I created a command procedure that simply ran one QTP program that read a couple RMS files and updated some information in an RDB table. Following this it would run a QUIZ program. The QTP program would always run and complete but the command procedure/process (interactive or batch) would terminate right after. No other code not even next line being show $status executed.

Using the accounting utility one thing I found is that the processes, interactive or batch, had a final status of  %SYSTEM-F-ASTFLT.

I contacted HP to try to help analyze what might be going on. Using Analyze/sys, a variety of information was gathered for processes that terminated and the processes that were hung.
Other errors were identified such as
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-EXQUOTA, process quota exceeded

Note: If your command procedure is run in batch or /out=logfile and there is nothing at the end of the logfile. Do $set file/end and then type the file to see if there is anything of interest.

For specific accounts we increased quotas for TQELM, ASTLM, and ENQLM. For some situations this seemed to help but sporadically.

One of the things HP noticed but had no explanation is that some code was being executed in executive mode on the stack when it shouldn't be and thus would not be able to return resulting in hung or terminating process.

No definitive answer or solution yet. A bunch of work arounds and monitoring procedures were put in place to deal with the situations. Fortunately, many of the applications have been migrating off of this platform so fewer and fewer are affected/impacted.

We are in the process of isolating one of the old GS160 and loading all the pre-upgrade software. Then step through the upgrade with HP to see where things may have gone amiss.
Part of the reason is because we also found other issues when compiling some of our 30 year old Macro code.
Answer to the MACRO code compile problem we found
The $TRAN macros now need to know whether they are being used on Alpha or Itanium (they are common source).
The developer who made the changes added various ".IF DF EVAX" and ".IF DF IA64" directives to the macro.
The Alpha version wasn't scheduled to be changed until 8.2, but the common source accidently slipped into V7.3-2.
Those symbols are not part of the Macro-32 compiler itself, but come from a file called SYS$LIBRARY:ARCH_DEFS.MAR.
So add /MIGATE to your MACRO command and add SYS$LIBRARY:ARCH_DEFS.MAR with the file your compiling.

Thanx
Lorry Litman
Application Management
llitman at manitoba-ehealth.ca<mailto:llitman at manitoba-ehealth.ca>
204-926-9076

From: powerh-l-bounces+llitman=manitoba-ehealth.ca at lists.sowder.com<mailto:powerh-l-bounces+llitman=manitoba-ehealth.ca at lists.sowder.com> [mailto:powerh-l-bounces+llitman=manitoba-ehealth.ca at lists.sowder.com] On Behalf Of Thomson, Martyn
Sent: Monday, August 24, 2015 2:05 PM
To: 'HERALD KAFFKA'; 'powerh-l at lists.sowder.com'
Subject: RE: Alpha to Itanium DCL issue

Thank-you for your suggestion!

I was looking for a Powerhouse *E* type error message. Turns out it was an %RDB-E- error on a date conversion in a view.

Because the dozen QTP programs were being executed in the same QTP session, it just carries on regardless executing the others, then aborts when it exits back to DCL. Who knew!
I'll split them up into separate "$ QTP auto=" statements so DCL will error out on the right one.

Thanks again Herald.

From: Thomson, Martyn
Sent: August-24-15 11:21 AM
To: 'HERALD KAFFKA'; 'powerh-l at lists.sowder.com'
Subject: RE: Alpha to Itanium DCL issue

"com" is just a logical for the location of DCL command procedures. Used throughout the app.

I'll try your suggestion of running each procedure from command line.

From: HERALD KAFFKA [mailto:Herald.Kaffka at westfraser.com]
Sent: August-24-15 11:07 AM
To: Thomson, Martyn; 'powerh-l at lists.sowder.com'
Subject: RE: Alpha to Itanium DCL issue

RDB?  Oracle? Or straight RMS/ISAM...

About 2 years ago we went through the same process (Large Powerhouse application => Alpha->Itanium).

App was a mix of Oracle and RMS/ISAM (mostly Oracle with a few legacy RMS files hanging around...).  (No RDB).

Near Zero problems with the OS/Shell.  (Alpha by default ran a stable sort, Itanium ran a unstable sort, so if
Your quiz/qtp runs were sorting down x levels, and detail lines were at x+1, the order of the detail lines was
Undetermined.  (Subtotals were ok, ie Sort down to the level of a "parent company", (say Home Depot), then
Display sales to each individual store, subtotals/grand totals would all be good, but the order in which individual
Stores printed out was random, (oracle returns data in a random order if you don't explicitly sort, if you are using pure
RMS/ISAM you would be fine as RMS runs indexes and retrieves in order).  "I think" there was a logical you could set
To force the old behavior, but as this only affected about 4 quiz/qtp runs out of hundreds, we simply added the last sort
level to reports.  (Cleaner and easier to understand in the long run than  using an invisible logical name out at the system level...).

This was pretty much the only problem we ran into on this.  (course we had moved from various VAXes in the past, and from
VAX to Alpha, so there is/was a pretty good abstraction layer setup in logical names to hide the physical hardware...).

"@com:proc2.com";

Is the @com in the above an "inhouse" symbol/procedure to run a command file?  You might want to look at it if so, and see if it's your problem...
If your routine is not too involved, you might want to step through processing one step at a time at the DCL command line to see if something
Is getting trapped out (and/or confused) by something in the com file wrapper/driver...

Just a few random thoughts...

From: powerh-l-bounces+herald.kaffka=westfraser.com at lists.sowder.com<mailto:powerh-l-bounces+herald.kaffka=westfraser.com at lists.sowder.com> [mailto:powerh-l-bounces+herald.kaffka=westfraser.com at lists.sowder.com] On Behalf Of Thomson, Martyn
Sent: Monday, August 24, 2015 12:03 PM
To: 'powerh-l at lists.sowder.com' <powerh-l at lists.sowder.com<mailto:powerh-l at lists.sowder.com>>
Subject: Alpha to Itanium DCL issue

Moving a large PowerHouse app from Alpha to Itanium. Getting strange behaviour with a DCL procedure terminating prematurely.

DCL procedure proc1.com submitted;
Does a few things then executes proc2.com i.e. "@com:proc2.com";
Proc2.com runs a dozen QTP programs then drops out to proc1.com prematurely! The QUIZ programs don't get run; the reports aren't printed;
On returning to proc1.com it immediately exits, not executing the remainder of proc1.

All QTP/QUIZ were recompiled.

I added "on error then goto err_handler" to both procedures to display $status.  Proc2 is terminating with  %X1900802A. That's a QTP error "A file access error has been detected, but the QTP program did write to the database the number of records shown in the log. The protection on all tables it references is correct. There are no subfiles involved.

Has anyone seen this before? Very puzzled. Any insights, suggestions, etc much appreciated.

I should point out I searched the logs on the Alpha for this job. It happened once last month for the first time ever.

OpenVMS 8.4
Oracle Rdb SQL V7.3-100
PowerHouse  8.40G
Regards,
Martyn Thomson
Senior Technical Analyst, Development Services
Information Technology Services
HP Advanced Solutions Inc.
phone: 250.405.4555 | fax: 250.405.4422
email:martyn.thomson at hpadvancedsolutions.com<mailto:martyn.thomson at hpadvancedsolutions.com>
web:  www.hpadvancedsolutions.com<http://www.hpadvancedsolutions.com/>

-------------EOP---------------

This e-mail message and any attachments are confidential. Any dissemination or use of this information by a person other than the intended recipient is unauthorized. If you are not the intended recipient, please notify me by return e-mail, do not open any attachment and delete this communication and any copy.

Thank you

securemail.phxa.com made the following annotations
---------------------------------------------------------------------

NOTICE: The information contained in this e-mail and 
any attachments is confidential and may be privileged 
or otherwise protected from disclosure.This e-mail is 
intended solely for the use of the named addressee. 
Any other use, printing, copying, disclosure or 
dissemination may be subject to legal restriction. If 
you are not the intended recipient, please contact the 
sender and delete all copies including any attachments.

---------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sowder.com/pipermail/powerh-l/attachments/20150824/f4f64a8b/attachment-0001.htm>