Oracle Observations

November 26, 2017

Birmingham zero food hygiene ratings.

Filed under: Uncategorized — bigdaveroberts @ 5:25 pm

The Birmingham Mail helpfully publishes reviews of Birmingham food hygiene ratings on a quarterly basis.

As the UKOUG conference approaches, I do like to check up on the latest developments.

So firstly the good news, it appears to be much easier to access up to date information on local food hygiene ratings on the website and for your convenience, the data is made available through an API that third party apps mage available on your smart phone.

Secondly, more good news, The only restaurant on Broad St that received a zero food hygiene rating recently has actually shut down, so if you were looking forward to dicing with death at the Bombay Mix, I’m afraid you’ll be disappointed.

Thirdly, even more good news, The perennial zero offender, Pit stop, has somehow gained a satisfactory rating:

However on a more negative standpoint are the disappointing surprises.

The Handmade burger company, one of who’s restaurants can be seen over the canal from the ICC managed a 1:

The company has recently been rescued, so hopefully improvements are coming, however they declined to respond to esquires from the Mail:

Another noted failure in that article is the Smallbrook Queensway holiday inn, where I believe Christian Antognini stayed during one of his Oracle Midlands trips. However the latest rating appears to indicate that this has been resolved:

So, UKOUG conference visitors to Birmingham, EAT WELL!


[Error] Execution (5: 1): ORA-00600: internal error code, arguments: [kzaxins:lxgcnv], [68], [], [], [], [], [], [], [], [], [], []

Filed under: 11g — bigdaveroberts @ 4:51 pm

I failed to find anything on the internet about this one, which is quite pleasing as a significant amount of human error was involved.

We manage our development databases with netapp snapshots to allow retesting against known database configurations with updated applications.

We do try to make sure that we segregate pre-upgrade snapshots, however on this occasion we restored a snapshot that predated the latest patchset upgrade. and encountered the above error.

We did try to re-apply the database component of the upgrade, but that failed to resolve the issue.

We also rolled back to the snapshot and reapplied the patch, and that also failed.

We finally resolved the issue by restoring the snapshot, performing the startup upgrade and then performing the upgrade again.

The thing that slightly surprised me was that opening the database with the new version of the software without performing the startup upgrade made the dattabse unupgradable.

Shutting the database down and then performing a startup upgrade was insufficient.

Oracle may have a more eligant solution to the issue ( we didn’t raise a MOS ticket ) but the result may be that the database ends up in a non supported configuration.

So, always keep a copy of the pre-upgrade database and be careful to follow the instructions, simple steps like starting the database in normal mode before starting it in upgrade mode can sometime cause real problems.

November 3, 2017

PCC-S-02201, Encountered the symbol “void” when expecting one of the following:

Filed under: Uncategorized — bigdaveroberts @ 11:15 pm

This post, unlike my others, doesn’t revolve around a problem I resolved, but I don’t think Kev has a blog, so I’ll take the credit.

I’m also going to include a link sugested by Allyn for those interested in understanding C a little better.

The problem began after the operating system was upgraded on the development box (AIX) and various programs we have developed fail to compile:

++++++ progName.pc ++++++

/oracle/app/oracle/product/10.2.0/bin/proc sqlcheck=full userid=***** include=../Einclude include=/opt/IBMvast/primitiv dbms=v8 MODE=ORACLE CODE=ANSI_C CHAR_MAP=string LTYPE=NONE LINES=YES DEFINE=_LONG_LONG iname=progName.pc

Pro*C/C++: Release – Production on Thu Feb 2 11:58:12 2017

Copyright (c) 1982, 2005, Oracle. All rights reserved.

System default option values taken from: /oracle/app/oracle/product/10.2.0/precomp/admin/pcscfg.cfg

Syntax error at line 647, column 34, file /usr/include/openssl/crypto.h: Error at line 647, column 34 in file /usr/include/openssl/crypto.h int CRYPTO_memcmp(const volatile void a, const volatile void b, size_t len); ……………………………1

PCC-S-02201, Encountered the symbol “void” when expecting one of the following:

, ( ) [

The symbol “,” was substituted for “void” to continue.

Syntax error at line 647, column 58, file /usr/include/openssl/crypto.h: Error at line 647, column 58 in file /usr/include/openssl/crypto.h int CRYPTO_memcmp(const volatile void a, const volatile void b, size_t len); …………………………………………………1

PCC-S-02201, Encountered the symbol “void” when expecting one of the following:

, ( ) [

The symbol “,” was substituted for “void” to continue.

Syntax error at line 256, column 24, file /usr/include/openssl/bio.h: Error at line 256, column 24 in file /usr/include/openssl/bio.h void BIO_set_flags(BIO b, int flags);


PCC-S-02201, Encountered the symbol “” when expecting one of the following:

, )

So an operating system upgrade causes compilation errors?

Actually, the errors are only seen in the pre-compiler, not in the compiler. I don’t know if the AIX C compiler would have issues with this but I would hope not.

Several people worked on the investigation.

I tried using the 11g verion of Pro*C, but the error persisted.

I didn’t have access to a 12c Pre-compiler at work, so I am unable to confirm if the same issue would be present.

The issue was traced by a coligue to changes in the openssl header files, where various prototypes had been changed.

Reverting to the old versions allowed the programs to compile sucessfully.

The issue appears to be a failure of the Pro*C compiler to sucessfully process some of the newer C syntax.

My colligue, not only solved the problem, but found the git hub repository where the change was discussed and debated.

The issue was that the prototype was changed in opensl/crypto.h so that:

int CRYPTO_memcmp(const void in_a, const void in_b, size_t len)


int CRYPTO_memcmp(const volatile void in_a, const volatile void in_b, size_t len)

The link explains that the motive for the change was to stop the GNU C compiler from optimising code that could theoretically allow unencripted values beins stored in memory.

As we weren’t using this function, and we weren’t using the GNU compiler, we felt it safe to revert this change back.

Ultimately, it is perhaps useful to understand the concept of the const volatile, which is explained in this interesting article suggested by my coligue:


Create a free website or blog at