FEED Validator

for Atom and RSS and KML

Congratulations!

This is a valid RSS feed.

Recommendations

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

line 34, column 6: Avoid xhtml:body (15 occurrences) [help]

      <body xmlns="http://www.w3.org/1999/xhtml"><p>It's been a long while s ...
      ^

line 46, column 4: Ensure lastBuildDate is present when slash:comments is used (15 occurrences) [help]
```
    </item>
    ^
```
line 562, column 2: Missing atom:link with rel="self" [help]
```
  </channel>
  ^
```

Source: http://www.eight-cubed.com/blog/index.xml

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="http://www.eight-cubed.com/blog/rss2html.xsl"?>
<rss version="2.0"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
xmlns:admin="http://webns.net/mvcb/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/"
xmlns:wfw="http://wellformedweb.org/CommentAPI/">
<channel>
<title>e i g h t - c u b e d . c o m</title>
<link>http://www.eight-cubed.com/blog/</link>
<description>A day in the life of an OpenVMS systems specialist. Articles and tutorials on Systems Management and Programming for OpenVMS.</description>
<dc:language>en-us</dc:language>
<dc:creator>James F. Duff</dc:creator>
<dc:rights>Copyright 2018 James F. Duff</dc:rights>
<dc:date>2018-06-29T12:43:58+11:00</dc:date>
<admin:generatorAgent rdf:resource="http://www.movabletype.org/?v=3.34" />
<admin:errorReportsTo rdf:resource="mailto:[email protected]"/>
<sy:updatePeriod>daily</sy:updatePeriod>
<sy:updateFrequency>1</sy:updateFrequency>
<sy:updateBase>2000-01-01T12:00+00:00</sy:updateBase>
<item>
<title>Bit tests in COBOL</title>
<link>http://www.eight-cubed.com/blog/archives/001290.html?from=rss</link>
<guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001290.html</guid>
<description>It's been a long while since I've had anything interesting to post here. Mostly, my day to day occupation for the last couple of years has been maintaining the infrastructure, operating system, and ensuring business as usual continues for the company's primary application.
However, I got an interesting query from an old friend today, asking if there is a way to do bitwise tests in COBOL. This was an interesting challenge that made me think outside the box!</description>
<body xmlns="http://www.w3.org/1999/xhtml">It's been a long while since I've had anything interesting to post here. Mostly, my day to day occupation for the last couple of years has been maintaining the infrastructure, operating system, and ensuring business as usual continues for the company's primary application.
However, I got an interesting query from an old friend today, asking if there is a way to do bitwise tests in COBOL. This was an interesting challenge that made me think outside the box!</body>
<dc:subject>Programming</dc:subject>
<dc:date>2018-06-29T12:43:58+11:00</dc:date>
<comments>http://www.eight-cubed.com/cgi-bin/mt-comments.cgi?entry_id=1290</comments>
<slash:comments>0</slash:comments>
<trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/528</trackback:ping>
<wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001290.rss</wfw:commentRss>
</item>
<item>
<title>Are we getting closer to the bug?</title>
<link>http://www.eight-cubed.com/blog/archives/001289.html?from=rss</link>
<guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001289.html</guid>
<description>In my previous post which was terrifyingly over six months ago, I again touched on the issue that I described way back in June 2014 about directory renames sometimes producing catastrophically incorrect results. I thought I'd bring you up-to-date with what's happening...</description>
<body xmlns="http://www.w3.org/1999/xhtml">In my previous post which was terrifyingly over six months ago, I again touched on the issue that I described way back in June 2014 about <a href="http://www.eight-cubed.com/blog/archives/001285.html">directory renames sometimes producing catastrophically incorrect results</a>. I thought I'd bring you up-to-date with what's happening...
Shortly after I published the update in late June 2015, Engineering got in touch with me to note that RMS has a process wide directory path cache, which gets invalidated on every directory remove operations (delete or rename). Cache invalidation is based on a directory sequence number contained in the <abbr title="Unit Control Block">UCB</abbr> of the disk involved. They suggested running some <abbr title="System Dump Analyser">SDA</abbr> commands to see if, when the problem occurred, the field was not being updated.</body>
<dc:subject>OpenVMS</dc:subject>
<dc:date>2016-01-14T11:24:06+11:00</dc:date>
<slash:comments>1</slash:comments>
<trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/527</trackback:ping>
<wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001289.rss</wfw:commentRss>
</item>
<item>
<title>Still rename weirdness</title>
<link>http://www.eight-cubed.com/blog/archives/001288.html?from=rss</link>
<guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001288.html</guid>
<description>Long time between posts. My job has got very quiet due to my company aiming to replace the in-house written...</description>
<body xmlns="http://www.w3.org/1999/xhtml">Long time between posts. My job has got very quiet due to my company aiming to replace the in-house written system running on VMS with an off-the-shelf <abbr title="Enterprise Resource Planning">ERP</abbr> system. With the inherent stability of the system running on VMS, I haven't had much to write about.
However, I wrote <a href="http://www.eight-cubed.com/blog/archives/001285.html">an article</a> over a year ago concerning a rare issue where a series of directory renames gets "confused". This issue has hit us twice in the last three days.
Perhaps now that the old team reassembled for VSI is back together, someone will be able to solve this.</body>
<dc:subject>OpenVMS</dc:subject>
<dc:date>2015-06-27T05:10:45+11:00</dc:date>
<slash:comments>0</slash:comments>
<trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/526</trackback:ping>
<wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001288.rss</wfw:commentRss>
</item>
<item>
<title>HP World in Sydney</title>
<link>http://www.eight-cubed.com/blog/archives/001287.html?from=rss</link>
<guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001287.html</guid>
<description>HP World Tour is coming to Sydney on the 28th of August. I'm registered and attending if you anyone wants to catch up face to face.</description>
<body xmlns="http://www.w3.org/1999/xhtml">HP World Tour is coming to Sydney on the 28th of August. I'm registered and attending if you anyone wants to catch up face to face.</body>
<dc:subject>Hewlett Packard</dc:subject>
<dc:date>2014-07-23T18:08:02+11:00</dc:date>
<slash:comments>0</slash:comments>
<trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/525</trackback:ping>
<wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001287.rss</wfw:commentRss>
</item>
<item>
<title>System logical name changes</title>
<link>http://www.eight-cubed.com/blog/archives/001286.html?from=rss</link>
<guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001286.html</guid>
<description>Here's a command procedure that run daily, will provide you with a nice email listing additions, deletions, and modifications to the system logical name table.</description>
<body xmlns="http://www.w3.org/1999/xhtml">Here's a command procedure that run daily, will provide you with a nice email listing additions, deletions, and modifications to the system logical name table.</body>
<dc:subject>OpenVMS</dc:subject>
<dc:date>2014-06-16T17:21:00+11:00</dc:date>
<slash:comments>0</slash:comments>
<trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/524</trackback:ping>
<wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001286.rss</wfw:commentRss>
</item>
<item>
<title>Rename weirdness</title>
<link>http://www.eight-cubed.com/blog/archives/001285.html?from=rss</link>
<guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001285.html</guid>
<description>Sometimes a directory rename doesn't?</description>
<body xmlns="http://www.w3.org/1999/xhtml">Consider the following directory structure:
<pre>
$ dir my_disk:[top.branch...]
Directory MY_DISK:[top]
branch.DIR;1
Total of 1 file.
Directory MY_DISK:[top.branch]
archive.DIR;1 report1.rep;1 report2.rep;1
Total of 3 files.
Directory MY_DISK:[top.branch.archive]
20140611.DIR;1 20140612.DIR;1
Total of 2 files.
Grand total of 3 directories, 6 files.
</pre>
During the day, a large number of reports are created in MY_DISK:[TOP.BRANCH].
The goal of the following set of DCL commands is to move these files to a directory called MY_DISK:[TOP.BRANCH.ARCHIVE.20140613]:
<pre>
$ set prot=o:rwed my_disk:[top.branch]archive.dir
$ rename my_disk:[top.branch]archive.dir my_disk:[top]branch_archive.dir
$ set prot=o:rwed my_disk:[top]branch.dir
$ rename my_disk:[top]branch.dir my_disk:[top.branch_archive]20140613.dir
$ create/dir my_disk:[top.branch]
$ rename my_disk:[top]branch_archive.dir my_disk:[top.branch]archive.dir
</pre>
Now imagine there are 80+ BRANCH.DIR directories (with different names of course) and we have that sequence of commands execute in parallel jobs, one for each directory.
The vast majority of the time, this works fine. However, on the odd occasion, the CREATE/DIR command says that the directory already exists, even though the preceding RENAME has returned a success status.
After the CREATE/DIR, the next RENAME also succeeds, however, right afterwards, the BRANCH.DIR directory has mysteriously gone missing! The directory is only then recoverable by performing an ANALYZE/DISK/REPAIR.
This is on I64 8.4 with UPDATE-V0800, FIBRE_SCSI-V0500, RMS-V0400, and SYS_V0300.
The underlying ODS-5 disk is a two member shadow set that a SET VOLUME/CACHE=NODATA has been issued against (the disk is 99.9% write) mounted on all nodes of a five member cluster.
I've logged a call with HP against this.
</body>
<dc:subject>OpenVMS</dc:subject>
<dc:date>2014-06-13T17:15:46+11:00</dc:date>
<slash:comments>0</slash:comments>
<trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/523</trackback:ping>
<wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001285.rss</wfw:commentRss>
</item>
<item>
<title>NRPE on OpenVMS</title>
<link>http://www.eight-cubed.com/blog/archives/001284.html?from=rss</link>
<guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001284.html</guid>
<description>Trials and tribulations of making NRPE work on OpenVMS.</description>
<body xmlns="http://www.w3.org/1999/xhtml">I have a pretty extensive <a href="http://www.nagios.org/">Nagios</a> setup here, that monitors everything from network links, OpenVMS services, Windows server availability, and Linux.
Because I haven't installed <abbr title="Nagios Remote Plugin Executor">NRPE</abbr> on Windows as I don't manage those boxes, some people in the Windows Team have recently been looking at Microsoft's SCOM product. I thought I better demo NRPE, at least on OpenVMS.
I got the <a href="http://nrpevms.dbaalacarte.com/">OpenVMS NRPE kit</a>, but this code seems to be fairly old (no IA64 references). But as all the code was there, it appeared to build just fine on IA64.
Unfortunately, there are a couple of "gotchas" in the kit, both in the documentation, and in the implementation. First, let's fix a bug in the code that of course only rears its head when you set the DEBUG flag in NRPE.CFG to 1 (which you want to do when you are initially configuring the service).
The bug is in the CUSTOM.C module. Replace this source:
<pre>
void syslog(int priority, char *message, ...){
char buffer[MAX_INPUT_BUFFER];
va_list arguments;
va_start(arguments, message);
sprintf(buffer, message, va_arg(arguments, char *));
printf("%d: %s\n", priority, buffer);
va_end(arguments);
}
</pre>
With this:
<pre>
void syslog(int priority, char *message, ...){
char buffer[MAX_INPUT_BUFFER];
va_list arguments;
va_start(arguments, message);
vsprintf(buffer, message, arguments);
printf("%d: %s\n", priority, buffer);
va_end(arguments);
}
</pre>
This prevents an access violation if there are no optional arguments (the result of a va_arg on nonexistent arguments is undefined in the C specification).
The other unfortunate bit is a combination of the documentation, that advises you to create logical names containing a dollar sign (which is <a href="http://h71000.www7.hp.com/doc/73final/4518/4518pro_003.html#4518_naming_con">generally not recommended</a>); and omissions in the configuration file.
Because the documentation tells you to create a logical containing a dollar sign, you have to specify command definitions that will be examined for macro substitution with an escaped dollar sign ($$) as the dollar sign is the macro introducer in Nagios.
If you look in the NRPE.CFG file supplied in the kit, you will see this is commands such as
<pre>
command[check_test][email protected]$$scripts:check_test.com
</pre>
But just below this is
<pre>
command[check_cpu][email protected]$scripts:check_system.com CPU
</pre>
which only supplies a single dollar sign. Because of this, the macro processor assumes you've carelessly left a trailing dollar sign off and supplies you with one. The command finally executed is
<pre>
@nrpe$scripts:check_system.com CPU$
</pre>
which doesn't work.
To fix, simply add the extra dollar sign in the NRPE.CFG file (or better yet, ignore the documentation and don't use a dollar sign in your logical names at all).</body>
<dc:subject>Systems Management</dc:subject>
<dc:date>2014-04-30T17:14:11+11:00</dc:date>
<slash:comments>0</slash:comments>
<trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/522</trackback:ping>
<wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001284.rss</wfw:commentRss>
</item>
<item>
<title>Poor man's PCA</title>
<link>http://www.eight-cubed.com/blog/archives/001283.html?from=rss</link>
<guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001283.html</guid>
<description>Description of a solution I came up with to automatically collect program counter information in an executable image, with links to the source code.</description>
<body xmlns="http://www.w3.org/1999/xhtml">As part of DECset, HP have a really useful bit of software called the Performance and Coverage Analyzer (PCA). The program is capable of recording <abbr title="program counter">PC</abbr> information, and then displaying the corresponding lines of source code that the frequently recorded PCs belong to. Unfortunately, I don't have a license.
So, how do I get a program to record its program counter on a regular basis? Read on.</body>
<dc:subject>Programming</dc:subject>
<dc:date>2014-03-20T14:59:49+11:00</dc:date>
<slash:comments>0</slash:comments>
<trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/521</trackback:ping>
<wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001283.rss</wfw:commentRss>
</item>
<item>
<title>Holidays</title>
<link>http://www.eight-cubed.com/blog/archives/001282.html?from=rss</link>
<guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001282.html</guid>
<description>Having experienced zero issues due to moving production recently, I'm going on holidays. Expect no updates for at least a month :)</description>
<body xmlns="http://www.w3.org/1999/xhtml">Having experienced zero issues due to <a href="http://www.eight-cubed.com/blog/archives/001281.html">moving production</a> recently, I'm going on holidays. Expect no updates for at least a month :)</body>
<dc:subject>Personal</dc:subject>
<dc:date>2014-02-14T13:47:10+11:00</dc:date>
<slash:comments>0</slash:comments>
<trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/520</trackback:ping>
<wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001282.rss</wfw:commentRss>
</item>
<item>
<title>Moving production</title>
<link>http://www.eight-cubed.com/blog/archives/001281.html?from=rss</link>
<guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001281.html</guid>
<description>After months of setup, we finally successfully relocated the main machines that support our ERP application to the new data centre today.</description>
<body xmlns="http://www.w3.org/1999/xhtml">After months of setup, we finally successfully relocated the main machines that support our <abbr title="Enterprise Resource Planning">ERP</abbr> application to the new data centre today.
We actually attempted this back in October, but we had to roll back after a very strange hardware issue that didn't appear to be a hardware issue. A mezzanine fibrechannel card reported all in the green, but irregardless of what we tried, failed to recognise the disks. After fighting this with everything we could think of (array setup, FC switch setup and zoning, Virtual Connect setup, host hardware, first and second level support from HP), and compounded by some poor network support from the CoLo, we rolled back.
When we got back to the original data centre, and after talking to HP third level support, it was realised that the fibrechannel card was showing bizarre numbers for the <abbr title="World Wide Name">WWN</abbr>s. We deleted the Virtual Connect profile associated with the blade, and recreated it, and while the WWNs now looked appropriate, the card would still not see the drives. In desperation, we replaced the card, and everything came good. Everyone breathed a huge sigh of relief.
On reflection, we should have suspected the card was dodgy before we rolled back, as we had HP engineers on site with spares in case anything like this actually happened. 
When we came to do the move again today (this time armed with the offline diagnostics tool, just in case), everything went much more smoothly. Let's hope we have no bedding down issues when the full production load comes on on Tuesday morning.</body>
<dc:subject>Systems Management</dc:subject>
<dc:date>2014-01-26T23:28:15+11:00</dc:date>
<slash:comments>0</slash:comments>
<trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/519</trackback:ping>
<wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001281.rss</wfw:commentRss>
</item>
<item>
<title>VMS$BUFFER_OBJECT_USER</title>
<link>http://www.eight-cubed.com/blog/archives/001280.html?from=rss</link>
<guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001280.html</guid>
<description>Unless the VMS$BUFFER_OBJECT_USER identifier has a specific value, system services that require the identifier return with a misleading error.</description>
<body xmlns="http://www.w3.org/1999/xhtml">A few pieces of code on this site use buffered objects for fast I/O. For example, <a href="examples/framework.php?file=sys_fastio.c">this programming example</a>.
Comments in the code note that you must have the VMS$BUFFER_OBJECT_USER identifier granted to your process or the code will fail to run. This is all nicely documented in various manuals on the documentation set, probably most comprehensively in <a href="http://h71000.www7.hp.com/doc/82final/5841/5841pro_069.html">this section of the "Programming Concepts Manual"</a>.
But:
<pre class="code">
<code class="language-dcl">
$ show proc/rights
10-JAN-2014 13:06:45.09 User: XXX Process ID: 20202096
Node: XXXXXX Process name: "xxx"
Process rights:
XXX resource
INTERACTIVE
REMOTE
DBG$ENABLE_SERVER
VMS$MEM_RESIDENT_USER
VMS$BUFFER_OBJECT_USER
System rights:
SYS$NODE_XXXXXX
Soft CPU Affinity: off
$ run test
sys$create_bufobj claims you don't have the VMS$BUFFER_OBJECT_USER identifier!
$
</code>
</pre></body>
<dc:subject>OpenVMS</dc:subject>
<dc:date>2014-01-10T13:19:11+11:00</dc:date>
<slash:comments>2</slash:comments>
<trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/518</trackback:ping>
<wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001280.rss</wfw:commentRss>
</item>
<item>
<title>CPUSPINWAIT crash</title>
<link>http://www.eight-cubed.com/blog/archives/001272.html?from=rss</link>
<guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001272.html</guid>
<description>A couple of weeks ago, we experienced a CPUSPINWAIT crash. Initial investigation indicates that the crash occurred in a call to SYS$ICC_ACCEPT() while waiting to get spinlock IOLOCK8.</description>
<body xmlns="http://www.w3.org/1999/xhtml">A couple of weeks ago, we experienced a CPUSPINWAIT crash. Initial investigation indicates that the crash occurred in a call to SYS$ICC_ACCEPT() while waiting to get spinlock IOLOCK8.
Because of the call to Intra-Cluster Communication services, HP initially recommended applying patch VMS84I_IPC-V0200. But after I pointed out that the release notes for that patch mention "waiting for the SCHED spinlock" and not the IOLOCK8 spinlock, I insisted that further crash analysis be performed.
At the moment, it appears that the crash is a close relation of the one solved by the above patch, but is certainly not the same crash.
Engineering is presently investigating.
Here's the crash footprint:
<pre>
Crash Time: 15-NOV-2013 16:31:10.90
Bugcheck Type: CPUSPINWAIT, CPU spinwait timer expired
Node: xxxxxx (Cluster)
CPU Type: HP BL860c (1.59GHz/9.0MB)
VMS Version: V8.4
Current Process: BATCH_1008254
Current Image: DSA34:[EXE]xxxxx.EXE;5
Failing PC: FFFFFFFF.80263C20 SMP$TIMEOUT_C+00170
Failing PS: 00000000.00000800
Module: SYSTEM_SYNCHRONIZATION_MIN (Link Date/Time: 3-SEP-2010 12:46:50.40)
Offset: 00010F20
Boot Time: 21-OCT-2013 09:50:42.00
System Uptime: 25 06:40:28.90
Crash/Primary CPU: 3./0.
System/CPU Type: 4020
Saved Processes: 1056
Pagesize: 8 KByte (8192 bytes)
Physical Memory: 20479 MByte (134742016 PFNs, discontiguous memory)
Dumpfile Pagelets: 5243425 blocks
Dump Flags: olddump,writecomp,errlogcomp
Dump Type: compressed,selective,dosd,shared_mem
EXE$GL_FLAGS: poolpging,init,bugdump,tbchk
Paging Files: 1 Pagefile and 0 Swapfiles installed
Stack Pointers:
KSP = 00000000.7FF43E10 ESP = 00000000.7FF68000 SSP = 00000000.7FFAC000
USP = 00000000.7AB0B960
General Registers:
R0 = 00000000.00000000 GP = FFFFFFFF.AD8EE800 R2 = 00000000.7FF43E00
R3 = 00000007.57A0E823 R4 = 00000000.00000043 R5 = FFFFFFFF.8C9CB080
R6 = 00000000.885A49B8 R7 = FFFFFFFF.896B2D00 R8 = 00000000.00000000
R9 = 00000000.00000002 R10 = 00000000.8813C470 R11 = FFFFFFFF.8825CC00
SP = 00000000.00000000 TP = 00000000.7B30E1C8 R14 = 00000000.00000000
R15 = FFFFFFFF.AD6EE968 R16 = FFFFFFFF.8019A6C0 R17 = 00000000.0000078C
R18 = 00000000.00000000 R19 = 00000000.0000078C R20 = FFFFFFFF.AD6EE300
R21 = 00000000.7FF43E38 R22 = FFFFFFFF.8825E1A8 R23 = FFFFFFFF.AD022EA0
R24 = 00000000.00000000 AI = 00000000.00000003 RA = 00000000.8813A480
PV = 00000000.0000FBA6 R28 = FFFFFFFF.8A5D6EC0 FP = 00000000.7FF43EC0
R30 = FFFFFFFF.AD6EE300 R31 = 00000000.00000000
CPUSPINWAIT Bugcheck:
Cause: timeout processing IPINT and/or acquiring spinlock
Spinlock name: IOLOCK8/SCS
Spinlock address: AD6EE300
Spinlock owner CPU Id: 02
Crash CPU Id: 03
CPU Id CPUDB BugCode State WorkReq Interrupted PC
------ -------- --------------- -------- ------------------------ ---------------------------------------
00 880E2000 CPUSPINWAIT Run bugchk
01 88258C80 CPUSPINWAIT Stopped bugchk
02 8825AC00 CPUEXIT Stopped <none>
03 8825CC00 CPUSPINWAIT Stopped <none>
System Registers:
Page Table Base Register (PTBR) 00000000.0010D950
Processor Base Register (PRBR) FFFFFFFF.8825CC00
Privileged Context Block Base (PCBB) FFFFFFFF.B0142080
System Control Block Base (SCBB) 00000000.00000000
Software Interrupt Summary Register (SISR) 00000000.00000180
Address Space Number (ASN) 00000000.002788F6
AST Summary / AST Enable (ASTSR_ASTEN) 00000000.0000000F
Floating-Point Enable (FEN) 00000000.00000001
Interrupt Priority Level (IPL) 00000000.00000008
Machine Check Error Summary (MCES) 00000000.00000000
Virtual Page Table Base Register (VPTB) 00000000.00000000
Failing Instruction:
SMP$TIMEOUT_C+00170: break.m 100002
Instruction Stream (last 20 instructions):
SMP$TIMEOUT_C+00120: mov r8 = r58
SMP$TIMEOUT_C+00121: mov.i ar.pfs = r56
SMP$TIMEOUT_C+00122: nop.b 000000 ;;
SMP$TIMEOUT_C+00130: nop.m 000000
SMP$TIMEOUT_C+00131: nop.f 000000
SMP$TIMEOUT_C+00132: br.ret.sptk.many b0 ;;
SMP$TIMEOUT_C+00140: add r19 = 200140, r1
SMP$TIMEOUT_C+00141: mov r22 = r17
SMP$TIMEOUT_C+00142: nop.i 000000 ;;
SMP$TIMEOUT_C+00150: ld8 r19 = [r19] ;;
SMP$TIMEOUT_C+00151: or r19 = 04, r19
SMP$TIMEOUT_C+00152: nop.i 000000 ;;
SMP$TIMEOUT_C+00160: nop.m 000000
SMP$TIMEOUT_C+00161: sxt4 r17 = r19
SMP$TIMEOUT_C+00162: nop.b 000000 ;;
SMP$TIMEOUT_C+00170: break.m 100002
SMP$TIMEOUT_C+00171: mov r17 = r22
SMP$TIMEOUT_C+00172: nop.i 000000 ;;
SMP$TIMEOUT_C+00180: break.m 100003
SMP$TIMEOUT_C+00181: nop.f 000000
SMP$TIMEOUT_C+00182: nop.i 000000 ;;
SMP$INIT_SANITY_C: alloc r41 = ar.pfs, 11, 00, 00
SMP$INIT_SANITY_C+00001: add r15 = 2000B0, r1
SMP$INIT_SANITY_C+00002: mov r47 = r7
SMP$INIT_SANITY_C+00010: mov r46 = r6 ;;
</pre></body>
<dc:subject>OpenVMS</dc:subject>
<dc:date>2013-12-05T12:21:44+11:00</dc:date>
<slash:comments>0</slash:comments>
<trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/510</trackback:ping>
<wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001272.rss</wfw:commentRss>
</item>
<item>
<title>SYS$ACM changed behaviour?</title>
<link>http://www.eight-cubed.com/blog/archives/001271.html?from=rss</link>
<guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001271.html</guid>
<description>Has SYS$ACM(W) changed behavior in recent versions of OpenVMS?</description>
<body xmlns="http://www.w3.org/1999/xhtml">Hoff posted on C.O.V concerning <a href="https://groups.google.com/forum/#!topic/comp.os.vms/2isZplU2FhM">an issue with SYS$ACM(W)</a>. While I didn't think my example program that demonstrates how to use this system service to change a password would have the issue he was talking about, I thought I better test it anyway.
I didn't experience the issue he raised, but to my utter surprise, the code failed to work at all and returned a CONTACTSYSMGR error message. On looking in the ACME log, I found a message indicating that the item list did not contain the ACME$_LOGON_TYPE item code.
Which is weird because the manual says (and I quote) "If not specified, the value defaults to the logon type of the calling process".
Well yes, it appears to have done so in the past. But not any more. I looked though the release notes and can find no reference to this behaviour change.
I really don't like undocumented changes in behaviour. And to make matters worse, OpenVMS Engineering still haven't fixed the <a href="http://h71000.www7.hp.com/doc/fb_doc.html">documentation feedback form</a> that produces a page not found error when you hit the submit button.</body>
<dc:subject>Programming</dc:subject>
<dc:date>2013-10-25T12:56:41+11:00</dc:date>
<slash:comments>0</slash:comments>
<trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/509</trackback:ping>
<wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001271.rss</wfw:commentRss>
</item>
<item>
<title>ACLSEARCH X01-07</title>
<link>http://www.eight-cubed.com/blog/archives/001270.html?from=rss</link>
<guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001270.html</guid>
<description>A new version of ACLSEARCH has been released. A fix suggested by Tony McGrath has been incorporated to handle long ACLs correctly, and I've done some reworking of the "Does this ACE match?" logic.</description>
<body xmlns="http://www.w3.org/1999/xhtml">I've just released a new version of ACLSEARCH. This utility has recently seen extensive use by Tony McGrath. Tony has not only been finding issues with my DCL, but he uncovered a really interesting bug in ACLSEARCH.
Turns out that because ACE's can't span headers if they overflow into extension headers, the file system will leave unused space at the end of the ACL area, and describe the unused space as valid.
The difference between two file header variables describe the length of the ACL area: <code>FH2$B_RSOFFSET</code> and <code>FH2$B_ACOFFSET</code>.
Both of these are a count of the number of 16 bit words, so we need to multiply by 2 to obtain the number of bytes for the ACL area.
The interesting bit is that if you take the <code>ACE$B_SIZE</code> values for the (valid) ACEs in the area and add them all up, it may or may not equal the difference of the two header variables. This was confusing the code, to put it mildly.
Tony came up with a good suggestion that corrected the issue, and the new version incorporates his mods. I've also reworked some of the more esoteric "does this ACE match?" logic that I'd previously coded, but never personally needed (so I didn't test it very well ;-)</body>
<dc:subject>Programming</dc:subject>
<dc:date>2013-10-01T13:05:58+11:00</dc:date>
<slash:comments>0</slash:comments>
<trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/508</trackback:ping>
<wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001270.rss</wfw:commentRss>
</item>
<item>
<title>3PAR now fully supported</title>
<link>http://www.eight-cubed.com/blog/archives/001269.html?from=rss</link>
<guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001269.html</guid>
<description>HP announce full support for 3PAR on IA64 OpenVMS.</description>
<body xmlns="http://www.w3.org/1999/xhtml">HP have just announced the full support of 3PAR storage arrays. The following is supported:
<div class="text-list">
<ul>
<li>HP 3PAR StoreServ 7200</li>
<li>HP 3PAR StoreServ 7400</li>
<li>HP 3PAR StoreServ 7450</li>
<li>HP 3PAR StoreServ 10400</li>
<li>HP 3PAR StoreServ 10800</li>
</ul>
</div>
running OS 3.1.2 MU2 on IA64 OpenVMS 8.3-1H1 and 8.4.
</body>
<dc:subject>Storage Area Networks</dc:subject>
<dc:date>2013-08-31T10:25:58+11:00</dc:date>
<slash:comments>0</slash:comments>
<trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/507</trackback:ping>
<wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001269.rss</wfw:commentRss>
</item>
</channel>
</rss>

If you would like to create a banner that links to this page (i.e. this validation result), do the following:

Download the "valid RSS" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src attribute if necessary):

<a href="http://www.feedvalidator.org/check.cgi?url=http%3A//www.eight-cubed.com/blog/index.xml"><img src="valid-rss-rogers.png" alt="[Valid RSS]" title="Validate my RSS feed" /></a>

If you would like to create a text link instead, here is the URL you can use:

http://www.feedvalidator.org/check.cgi?url=http%3A//www.eight-cubed.com/blog/index.xml

Home · About · News · Docs · Terms