Congratulations!

[Valid RSS] 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.

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

  1. <?xml version="1.0" encoding="utf-8"?>
  2. <?xml-stylesheet type="text/xsl" href="http://www.eight-cubed.com/blog/rss2html.xsl"?>
  3. <rss version="2.0"
  4.    xmlns:dc="http://purl.org/dc/elements/1.1/"
  5.    xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
  6.    xmlns:admin="http://webns.net/mvcb/"
  7.    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  8.    xmlns:content="http://purl.org/rss/1.0/modules/content/"
  9.    xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
  10.    xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/"
  11.    xmlns:wfw="http://wellformedweb.org/CommentAPI/">
  12.  
  13.  <channel>
  14.    <title>e i g h t - c u b e d . c o m</title>
  15.    <link>http://www.eight-cubed.com/blog/</link>
  16.    <description>A day in the life of an OpenVMS systems specialist.  Articles and tutorials on Systems Management and Programming for OpenVMS.</description>
  17.    <dc:language>en-us</dc:language>
  18.    <dc:creator>James F. Duff</dc:creator>
  19.    <dc:rights>Copyright 2018 James F. Duff</dc:rights>
  20.    <dc:date>2016-01-14T11:24:06+11:00</dc:date>
  21.    <admin:generatorAgent rdf:resource="http://www.movabletype.org/?v=3.34" />
  22.    <admin:errorReportsTo rdf:resource="mailto:[email protected]"/>
  23.    <sy:updatePeriod>daily</sy:updatePeriod>
  24.    <sy:updateFrequency>1</sy:updateFrequency>
  25.    <sy:updateBase>2000-01-01T12:00+00:00</sy:updateBase>
  26.  
  27.        <item>
  28.      <title>Are we getting closer to the bug?</title>
  29.      <link>http://www.eight-cubed.com/blog/archives/001289.html?from=rss</link>
  30.      <guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001289.html</guid>
  31.      <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&apos;d bring you up-to-date with what&apos;s happening...</description>
  32.      <body xmlns="http://www.w3.org/1999/xhtml"><p>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...</p>
  33.  
  34. <p>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.</p></body>
  35.      <dc:subject>OpenVMS</dc:subject>
  36.      <dc:date>2016-01-14T11:24:06+11:00</dc:date>
  37.            
  38.      
  39.      <slash:comments>1</slash:comments>
  40.            <trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/527</trackback:ping>
  41.      
  42.      <wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001289.rss</wfw:commentRss>
  43.    </item>
  44.        <item>
  45.      <title>Still rename weirdness</title>
  46.      <link>http://www.eight-cubed.com/blog/archives/001288.html?from=rss</link>
  47.      <guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001288.html</guid>
  48.      <description>Long time between posts. My job has got very quiet due to my company aiming to replace the in-house written...</description>
  49.      <body xmlns="http://www.w3.org/1999/xhtml"><p>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.</p>
  50.  
  51. <p>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.</p>
  52.  
  53. <p>Perhaps now that the old team reassembled for VSI is back together, someone will be able to solve this.</p></body>
  54.      <dc:subject>OpenVMS</dc:subject>
  55.      <dc:date>2015-06-27T05:10:45+11:00</dc:date>
  56.            
  57.      
  58.      <slash:comments>0</slash:comments>
  59.            <trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/526</trackback:ping>
  60.      
  61.      <wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001288.rss</wfw:commentRss>
  62.    </item>
  63.        <item>
  64.      <title>HP World in Sydney</title>
  65.      <link>http://www.eight-cubed.com/blog/archives/001287.html?from=rss</link>
  66.      <guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001287.html</guid>
  67.      <description>HP World Tour is coming to Sydney on the 28th of August.  I&apos;m registered and attending if you anyone wants to catch up face to face.</description>
  68.      <body xmlns="http://www.w3.org/1999/xhtml"><p>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.</p></body>
  69.      <dc:subject>Hewlett Packard</dc:subject>
  70.      <dc:date>2014-07-23T18:08:02+11:00</dc:date>
  71.            
  72.      
  73.      <slash:comments>0</slash:comments>
  74.            <trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/525</trackback:ping>
  75.      
  76.      <wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001287.rss</wfw:commentRss>
  77.    </item>
  78.        <item>
  79.      <title>System logical name changes</title>
  80.      <link>http://www.eight-cubed.com/blog/archives/001286.html?from=rss</link>
  81.      <guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001286.html</guid>
  82.      <description>Here&apos;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>
  83.      <body xmlns="http://www.w3.org/1999/xhtml"><p>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.</p></body>
  84.      <dc:subject>OpenVMS</dc:subject>
  85.      <dc:date>2014-06-16T17:21:00+11:00</dc:date>
  86.            
  87.      
  88.      <slash:comments>0</slash:comments>
  89.            <trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/524</trackback:ping>
  90.      
  91.      <wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001286.rss</wfw:commentRss>
  92.    </item>
  93.        <item>
  94.      <title>Rename weirdness</title>
  95.      <link>http://www.eight-cubed.com/blog/archives/001285.html?from=rss</link>
  96.      <guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001285.html</guid>
  97.      <description>Sometimes a directory rename doesn&apos;t?</description>
  98.      <body xmlns="http://www.w3.org/1999/xhtml"><p>Consider the following directory structure:</p>
  99.  
  100. <pre>
  101.  
  102. $ dir my_disk:[top.branch...]
  103.  
  104. Directory MY_DISK:[top]
  105.  
  106. branch.DIR;1
  107.  
  108. Total of 1 file.
  109.  
  110. Directory MY_DISK:[top.branch]
  111.  
  112. archive.DIR;1       report1.rep;1       report2.rep;1
  113.  
  114. Total of 3 files.
  115.  
  116. Directory MY_DISK:[top.branch.archive]
  117.  
  118. 20140611.DIR;1      20140612.DIR;1
  119.  
  120. Total of 2 files.
  121.  
  122. Grand total of 3 directories, 6 files.
  123.  
  124. </pre>
  125.  
  126. <p>During the day, a large number of reports are created in MY_DISK:[TOP.BRANCH].</p>
  127.  
  128. <p>The goal of the following set of DCL commands is to move these files to a directory called MY_DISK:[TOP.BRANCH.ARCHIVE.20140613]:</p>
  129.  
  130. <pre>
  131. $ set prot=o:rwed my_disk:[top.branch]archive.dir
  132. $ rename my_disk:[top.branch]archive.dir my_disk:[top]branch_archive.dir
  133. $ set prot=o:rwed my_disk:[top]branch.dir
  134. $ rename my_disk:[top]branch.dir my_disk:[top.branch_archive]20140613.dir
  135. $ create/dir my_disk:[top.branch]
  136. $ rename my_disk:[top]branch_archive.dir my_disk:[top.branch]archive.dir
  137. </pre>
  138.  
  139. <p>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.</p>
  140.  
  141. <p>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.</p>
  142.  
  143. <p>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.</p>
  144.  
  145. <p>This is on I64 8.4 with UPDATE-V0800, FIBRE_SCSI-V0500, RMS-V0400, and SYS_V0300.</p>
  146.  
  147. <p>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.</p>
  148.  
  149. <p>I've logged a call with HP against this.</p>
  150. </body>
  151.      <dc:subject>OpenVMS</dc:subject>
  152.      <dc:date>2014-06-13T17:15:46+11:00</dc:date>
  153.            
  154.      
  155.      <slash:comments>0</slash:comments>
  156.            <trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/523</trackback:ping>
  157.      
  158.      <wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001285.rss</wfw:commentRss>
  159.    </item>
  160.        <item>
  161.      <title>NRPE on OpenVMS</title>
  162.      <link>http://www.eight-cubed.com/blog/archives/001284.html?from=rss</link>
  163.      <guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001284.html</guid>
  164.      <description>Trials and tribulations of making NRPE work on OpenVMS.</description>
  165.      <body xmlns="http://www.w3.org/1999/xhtml"><p>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.</p>
  166.  
  167. <p>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.</p>
  168.  
  169. <p>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.</p>
  170.  
  171. <p>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).</p>
  172.  
  173. <p>The bug is in the CUSTOM.C module.  Replace this source:</p>
  174.  
  175. <pre>
  176. void syslog(int priority, char *message, ...){
  177.        char buffer[MAX_INPUT_BUFFER];
  178.        va_list arguments;
  179.  
  180.        va_start(arguments, message);
  181.  
  182.        sprintf(buffer, message, va_arg(arguments, char *));
  183.        printf("%d: %s\n", priority, buffer);
  184.  
  185.        va_end(arguments);
  186. }
  187. </pre>
  188.  
  189. <p>With this:</p>
  190.  
  191. <pre>
  192. void syslog(int priority, char *message, ...){
  193.        char buffer[MAX_INPUT_BUFFER];
  194.        va_list arguments;
  195.  
  196.        va_start(arguments, message);
  197.  
  198.        vsprintf(buffer, message, arguments);
  199.        printf("%d: %s\n", priority, buffer);
  200.  
  201.        va_end(arguments);
  202. }
  203. </pre>
  204.  
  205. <p>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).</p>
  206.  
  207. <p>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.</p>
  208.  
  209. <p>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.</p>
  210.  
  211. <p>If you look in the NRPE.CFG file supplied in the kit, you will see this is commands such as</p>
  212.  
  213. <pre>
  214. command[check_test][email protected]$$scripts:check_test.com
  215. </pre>
  216.  
  217. <p>But just below this is</p>
  218.  
  219. <pre>
  220. command[check_cpu][email protected]$scripts:check_system.com CPU
  221. </pre>
  222.  
  223. <p>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</p>
  224.  
  225. <pre>
  226. @nrpe$scripts:check_system.com CPU$
  227. </pre>
  228.  
  229. <p>which doesn't work.</p>
  230.  
  231. <p>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).</p></body>
  232.      <dc:subject>Systems Management</dc:subject>
  233.      <dc:date>2014-04-30T17:14:11+11:00</dc:date>
  234.            
  235.      
  236.      <slash:comments>0</slash:comments>
  237.            <trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/522</trackback:ping>
  238.      
  239.      <wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001284.rss</wfw:commentRss>
  240.    </item>
  241.        <item>
  242.      <title>Poor man&apos;s PCA</title>
  243.      <link>http://www.eight-cubed.com/blog/archives/001283.html?from=rss</link>
  244.      <guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001283.html</guid>
  245.      <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>
  246.      <body xmlns="http://www.w3.org/1999/xhtml"><p>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.</p>
  247.  
  248. <p>So, how do I get a program to record its program counter on a regular basis?  Read on.</p></body>
  249.      <dc:subject>Programming</dc:subject>
  250.      <dc:date>2014-03-20T14:59:49+11:00</dc:date>
  251.            
  252.      
  253.      <slash:comments>0</slash:comments>
  254.            <trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/521</trackback:ping>
  255.      
  256.      <wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001283.rss</wfw:commentRss>
  257.    </item>
  258.        <item>
  259.      <title>Holidays</title>
  260.      <link>http://www.eight-cubed.com/blog/archives/001282.html?from=rss</link>
  261.      <guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001282.html</guid>
  262.      <description>Having experienced zero issues due to moving production recently, I&apos;m going on holidays.  Expect no updates for at least a month :)</description>
  263.      <body xmlns="http://www.w3.org/1999/xhtml"><p>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 :)</p></body>
  264.      <dc:subject>Personal</dc:subject>
  265.      <dc:date>2014-02-14T13:47:10+11:00</dc:date>
  266.            
  267.      
  268.      <slash:comments>0</slash:comments>
  269.            <trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/520</trackback:ping>
  270.      
  271.      <wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001282.rss</wfw:commentRss>
  272.    </item>
  273.        <item>
  274.      <title>Moving production</title>
  275.      <link>http://www.eight-cubed.com/blog/archives/001281.html?from=rss</link>
  276.      <guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001281.html</guid>
  277.      <description>After months of setup, we finally successfully relocated the main machines that support our ERP application to the new data centre today.</description>
  278.      <body xmlns="http://www.w3.org/1999/xhtml"><p>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.</p>
  279.  
  280. <p>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.</p>
  281.  
  282. <p>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 <em>still</em> not see the drives.  In desperation, we replaced the card, and everything came good.  Everyone breathed a huge sigh of relief.</p>
  283.  
  284. <p>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.  </p>
  285.  
  286. <p>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.</p></body>
  287.      <dc:subject>Systems Management</dc:subject>
  288.      <dc:date>2014-01-26T23:28:15+11:00</dc:date>
  289.            
  290.      
  291.      <slash:comments>0</slash:comments>
  292.            <trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/519</trackback:ping>
  293.      
  294.      <wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001281.rss</wfw:commentRss>
  295.    </item>
  296.        <item>
  297.      <title>VMS$BUFFER_OBJECT_USER</title>
  298.      <link>http://www.eight-cubed.com/blog/archives/001280.html?from=rss</link>
  299.      <guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001280.html</guid>
  300.      <description>Unless the VMS$BUFFER_OBJECT_USER identifier has a specific value, system services that require the identifier return with a misleading error.</description>
  301.      <body xmlns="http://www.w3.org/1999/xhtml"><p>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>.</p>
  302.  
  303. <p>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>.</p>
  304.  
  305. <p>But:</p>
  306.  
  307. <pre class="code">
  308. <code class="language-dcl">
  309. $ show proc/rights
  310.  
  311. 10-JAN-2014 13:06:45.09   User: XXX              Process ID:   20202096
  312.                          Node: XXXXXX            Process name: "xxx"
  313.  
  314. Process rights:
  315. XXX                               resource
  316. INTERACTIVE
  317. REMOTE
  318. DBG$ENABLE_SERVER
  319. VMS$MEM_RESIDENT_USER
  320. VMS$BUFFER_OBJECT_USER
  321.  
  322. System rights:
  323. SYS$NODE_XXXXXX
  324.  
  325. Soft CPU Affinity: off
  326. $ run test
  327. sys$create_bufobj claims you don't have the VMS$BUFFER_OBJECT_USER identifier!
  328. $
  329. </code>
  330. </pre></body>
  331.      <dc:subject>OpenVMS</dc:subject>
  332.      <dc:date>2014-01-10T13:19:11+11:00</dc:date>
  333.            
  334.      
  335.      <slash:comments>2</slash:comments>
  336.            <trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/518</trackback:ping>
  337.      
  338.      <wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001280.rss</wfw:commentRss>
  339.    </item>
  340.        <item>
  341.      <title>CPUSPINWAIT crash</title>
  342.      <link>http://www.eight-cubed.com/blog/archives/001272.html?from=rss</link>
  343.      <guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001272.html</guid>
  344.      <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>
  345.      <body xmlns="http://www.w3.org/1999/xhtml"><p>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.</p>
  346.  
  347. <p>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.</p>
  348.  
  349. <p>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.</p>
  350.  
  351. <p>Engineering is presently investigating.</p>
  352.  
  353. <p>Here's the crash footprint:</p>
  354.  
  355. <pre>
  356. Crash Time:        15-NOV-2013 16:31:10.90
  357. Bugcheck Type:     CPUSPINWAIT, CPU spinwait timer expired
  358. Node:              xxxxxx  (Cluster)
  359. CPU Type:          HP BL860c  (1.59GHz/9.0MB)
  360. VMS Version:       V8.4
  361. Current Process:   BATCH_1008254
  362. Current Image:     DSA34:[EXE]xxxxx.EXE;5
  363. Failing PC:        FFFFFFFF.80263C20    SMP$TIMEOUT_C+00170
  364. Failing PS:        00000000.00000800
  365. Module:            SYSTEM_SYNCHRONIZATION_MIN    (Link Date/Time:  3-SEP-2010 12:46:50.40)
  366. Offset:            00010F20
  367.  
  368. Boot Time:         21-OCT-2013 09:50:42.00
  369. System Uptime:              25 06:40:28.90
  370. Crash/Primary CPU: 3./0.
  371. System/CPU Type:   4020
  372. Saved Processes:   1056
  373. Pagesize:          8 KByte (8192 bytes)
  374. Physical Memory:   20479 MByte (134742016 PFNs, discontiguous memory)
  375. Dumpfile Pagelets: 5243425 blocks
  376. Dump Flags:        olddump,writecomp,errlogcomp
  377. Dump Type:         compressed,selective,dosd,shared_mem
  378. EXE$GL_FLAGS:      poolpging,init,bugdump,tbchk
  379. Paging Files:      1 Pagefile and 0 Swapfiles installed
  380.  
  381. Stack Pointers:
  382. KSP = 00000000.7FF43E10   ESP = 00000000.7FF68000   SSP = 00000000.7FFAC000
  383. USP = 00000000.7AB0B960
  384.  
  385. General Registers:
  386. R0  = 00000000.00000000   GP  = FFFFFFFF.AD8EE800   R2  = 00000000.7FF43E00
  387. R3  = 00000007.57A0E823   R4  = 00000000.00000043   R5  = FFFFFFFF.8C9CB080
  388. R6  = 00000000.885A49B8   R7  = FFFFFFFF.896B2D00   R8  = 00000000.00000000
  389. R9  = 00000000.00000002   R10 = 00000000.8813C470   R11 = FFFFFFFF.8825CC00
  390. SP  = 00000000.00000000   TP  = 00000000.7B30E1C8   R14 = 00000000.00000000
  391. R15 = FFFFFFFF.AD6EE968   R16 = FFFFFFFF.8019A6C0   R17 = 00000000.0000078C
  392. R18 = 00000000.00000000   R19 = 00000000.0000078C   R20 = FFFFFFFF.AD6EE300
  393. R21 = 00000000.7FF43E38   R22 = FFFFFFFF.8825E1A8   R23 = FFFFFFFF.AD022EA0
  394. R24 = 00000000.00000000   AI  = 00000000.00000003   RA  = 00000000.8813A480
  395. PV  = 00000000.0000FBA6   R28 = FFFFFFFF.8A5D6EC0   FP  = 00000000.7FF43EC0
  396. R30 = FFFFFFFF.AD6EE300   R31 = 00000000.00000000
  397.  
  398. CPUSPINWAIT Bugcheck:
  399. Cause:                  timeout processing IPINT and/or acquiring spinlock
  400. Spinlock name:          IOLOCK8/SCS
  401. Spinlock address:       AD6EE300
  402. Spinlock owner CPU Id:  02
  403. Crash CPU Id:           03
  404.  
  405. CPU Id    CPUDB       BugCode            State       WorkReq                     Interrupted PC
  406. ------    --------    ---------------    --------    ------------------------    ---------------------------------------
  407.  00      880E2000    CPUSPINWAIT        Run         bugchk
  408.  01      88258C80    CPUSPINWAIT        Stopped     bugchk
  409.  02      8825AC00    CPUEXIT            Stopped     &lt;none&gt;
  410.  03      8825CC00    CPUSPINWAIT        Stopped     &lt;none&gt;
  411.  
  412. System Registers:
  413. Page Table Base Register (PTBR)                           00000000.0010D950
  414. Processor Base Register (PRBR)                            FFFFFFFF.8825CC00
  415. Privileged Context Block Base (PCBB)                      FFFFFFFF.B0142080
  416. System Control Block Base (SCBB)                          00000000.00000000
  417. Software Interrupt Summary Register (SISR)                00000000.00000180
  418. Address Space Number (ASN)                                00000000.002788F6
  419. AST Summary / AST Enable (ASTSR_ASTEN)                    00000000.0000000F
  420. Floating-Point Enable (FEN)                               00000000.00000001
  421. Interrupt Priority Level (IPL)                            00000000.00000008
  422. Machine Check Error Summary (MCES)                        00000000.00000000
  423. Virtual Page Table Base Register (VPTB)                   00000000.00000000
  424.  
  425. Failing Instruction:
  426. SMP$TIMEOUT_C+00170:              break.m     100002
  427.  
  428. Instruction Stream (last 20 instructions):
  429. SMP$TIMEOUT_C+00120:              mov         r8 = r58
  430. SMP$TIMEOUT_C+00121:              mov.i       ar.pfs = r56
  431. SMP$TIMEOUT_C+00122:              nop.b       000000 ;;
  432. SMP$TIMEOUT_C+00130:              nop.m       000000
  433. SMP$TIMEOUT_C+00131:              nop.f       000000
  434. SMP$TIMEOUT_C+00132:              br.ret.sptk.many b0 ;;
  435. SMP$TIMEOUT_C+00140:              add         r19 = 200140, r1
  436. SMP$TIMEOUT_C+00141:              mov         r22 = r17
  437. SMP$TIMEOUT_C+00142:              nop.i       000000 ;;
  438. SMP$TIMEOUT_C+00150:              ld8         r19 = [r19] ;;
  439. SMP$TIMEOUT_C+00151:              or          r19 = 04, r19
  440. SMP$TIMEOUT_C+00152:              nop.i       000000 ;;
  441. SMP$TIMEOUT_C+00160:              nop.m       000000
  442. SMP$TIMEOUT_C+00161:              sxt4        r17 = r19
  443. SMP$TIMEOUT_C+00162:              nop.b       000000 ;;
  444. SMP$TIMEOUT_C+00170:              break.m     100002
  445. SMP$TIMEOUT_C+00171:              mov         r17 = r22
  446. SMP$TIMEOUT_C+00172:              nop.i       000000 ;;
  447. SMP$TIMEOUT_C+00180:              break.m     100003
  448. SMP$TIMEOUT_C+00181:              nop.f       000000
  449. SMP$TIMEOUT_C+00182:              nop.i       000000 ;;
  450. SMP$INIT_SANITY_C:                alloc       r41 = ar.pfs, 11, 00, 00
  451. SMP$INIT_SANITY_C+00001:          add         r15 = 2000B0, r1
  452. SMP$INIT_SANITY_C+00002:          mov         r47 = r7
  453. SMP$INIT_SANITY_C+00010:          mov         r46 = r6 ;;
  454. </pre></body>
  455.      <dc:subject>OpenVMS</dc:subject>
  456.      <dc:date>2013-12-05T12:21:44+11:00</dc:date>
  457.            
  458.      
  459.      <slash:comments>0</slash:comments>
  460.            <trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/510</trackback:ping>
  461.      
  462.      <wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001272.rss</wfw:commentRss>
  463.    </item>
  464.        <item>
  465.      <title>SYS$ACM changed behaviour?</title>
  466.      <link>http://www.eight-cubed.com/blog/archives/001271.html?from=rss</link>
  467.      <guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001271.html</guid>
  468.      <description>Has SYS$ACM(W) changed behavior in recent versions of OpenVMS?</description>
  469.      <body xmlns="http://www.w3.org/1999/xhtml"><p>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.</p>
  470.  
  471. <p>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.</p>
  472.  
  473. <p>Which is weird because the manual says (and I quote) "If not specified, the value defaults to the logon type of the calling process".</p>
  474.  
  475. <p>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.</p>
  476.  
  477. <p>I really don't like undocumented changes in behaviour.  And to make matters worse, OpenVMS Engineering <em>still</em> 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.</p></body>
  478.      <dc:subject>Programming</dc:subject>
  479.      <dc:date>2013-10-25T12:56:41+11:00</dc:date>
  480.            
  481.      
  482.      <slash:comments>0</slash:comments>
  483.            <trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/509</trackback:ping>
  484.      
  485.      <wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001271.rss</wfw:commentRss>
  486.    </item>
  487.        <item>
  488.      <title>ACLSEARCH X01-07</title>
  489.      <link>http://www.eight-cubed.com/blog/archives/001270.html?from=rss</link>
  490.      <guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001270.html</guid>
  491.      <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&apos;ve done some reworking of the &quot;Does this ACE match?&quot; logic.</description>
  492.      <body xmlns="http://www.w3.org/1999/xhtml"><p>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.</p>
  493.  
  494. <p>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, <em>and describe the unused space as valid</em>.</p>
  495.  
  496. <p>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>.</p>
  497.  
  498. <p>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.</p>
  499.  
  500. <p>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.</p>
  501.  
  502. <p>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 ;-)</p></body>
  503.      <dc:subject>Programming</dc:subject>
  504.      <dc:date>2013-10-01T13:05:58+11:00</dc:date>
  505.            
  506.      
  507.      <slash:comments>0</slash:comments>
  508.            <trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/508</trackback:ping>
  509.      
  510.      <wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001270.rss</wfw:commentRss>
  511.    </item>
  512.        <item>
  513.      <title>3PAR now fully supported</title>
  514.      <link>http://www.eight-cubed.com/blog/archives/001269.html?from=rss</link>
  515.      <guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001269.html</guid>
  516.      <description>HP announce full support for 3PAR on IA64 OpenVMS.</description>
  517.      <body xmlns="http://www.w3.org/1999/xhtml"><p>HP have just announced the full support of 3PAR storage arrays.  The following is supported:</p>
  518.  
  519. <div class="text-list">
  520. <ul>
  521. <li>HP 3PAR StoreServ 7200</li>
  522. <li>HP 3PAR StoreServ 7400</li>
  523. <li>HP 3PAR StoreServ 7450</li>
  524. <li>HP 3PAR StoreServ 10400</li>
  525. <li>HP 3PAR StoreServ 10800</li>
  526. </ul>
  527. </div>
  528. <p>running OS 3.1.2 MU2 on IA64 OpenVMS 8.3-1H1 and 8.4.</p>
  529.  
  530. </body>
  531.      <dc:subject>Storage Area Networks</dc:subject>
  532.      <dc:date>2013-08-31T10:25:58+11:00</dc:date>
  533.            
  534.      
  535.      <slash:comments>0</slash:comments>
  536.            <trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/507</trackback:ping>
  537.      
  538.      <wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001269.rss</wfw:commentRss>
  539.    </item>
  540.        <item>
  541.      <title>Bespoke dashboard</title>
  542.      <link>http://www.eight-cubed.com/blog/archives/001268.html?from=rss</link>
  543.      <guid isPermaLink="true">http://www.eight-cubed.com/blog/archives/001268.html</guid>
  544.      <description>A description of a little application and infrastructure dashboard I whipped up.</description>
  545.      <body xmlns="http://www.w3.org/1999/xhtml"><p>Obviously, the central application that my employer runs is still running on OpenVMS (or I'd probably be out of a job).  When a standardised monitoring solution was chosen for implementation here, not a lot of notice was paid to monitoring OpenVMS and consequently, the monitoring solution that was chosen had no operating system specific agent to support the platform.</p>
  546.  
  547. <p>The monitoring solution does however support SNMP, but when we asked the consultants who were hired to configure the monitoring solution to support a simple dashboard for the central application, it all proved too difficult for them.</p>
  548.  
  549. <p>Recently, I put a proof of concept dashboard together from a number of tools that I was already using, and a custom MIB to describe some parts of the application.</p></body>
  550.      <dc:subject>Systems Management</dc:subject>
  551.      <dc:date>2013-08-28T12:30:44+11:00</dc:date>
  552.            
  553.      
  554.      <slash:comments>0</slash:comments>
  555.            <trackback:ping>http://www.eight-cubed.com/cgi-bin/mt-tb.cgi/506</trackback:ping>
  556.      
  557.      <wfw:commentRss>http://www.eight-cubed.com/blog/archives/commentrss/001268.rss</wfw:commentRss>
  558.    </item>
  559.    
  560.  
  561.  </channel>
  562. </rss>

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

  1. Download the "valid RSS" banner.

  2. Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)

  3. Add this HTML to your page (change the image src attribute if necessary):

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

 
Copyright © 2002-9 Sam Ruby, Mark Pilgrim, Joseph Walton, and Phil Ringnalda