Richard Bassett

HI Rob,

If you don't have the C-ISAM manual, there's an older one online here: http://informixsoftw... Version 50.pdf

Mostly it's aimed at C programmers but bcheck is covered by Appendix A at page 270.

bcheck cannot repair data files, but the structure of C-ISAM data files is trivial provided you are using fixed length records, there is no real sense in which they could be repaired, only restored from your backup!

bcheck also cannot "repair" indexes but what it can do is entirely replace any damaged indexes by rebuilding them from scratch from the data file (if you answer relevant prompts in the affirmative presumably).

I don't think the purpose of bcheck -s is to repair anything, it appears to be to perform some obscure resizing operation within indexes (I have never used it and am merely reading the manual.)

I think the uppercase .IDX thing is purely an "staging" output of bcheck -s where, for some reason, the final step of the resizing requires you to manually replace the 'old' .idx file by renaming the 'new' .IDX as '.idx'

Best I recall, everything is always lowercase .dat and .idx and I don't think you need to worry about uppercase unless you use this obscure -s option and I'm not clear when/why one needs to do that.

What you did ought to have worked though, unless perhaps you didn't regen one of the functions involved?

Don't forget that with C-DEC you do need to pick a storage format for every field - that's a downside compared to C-FLT.  The ideal world is a genuine decimal floating type but IIRC that's only available in Oracle and DB2.

I know (or maybe knew) a fair bit about ProIV and C-ISAM as I implemented the support in ProIV in the late '80s or something.  Happy to try and help if needed although I don't pass this way often any more.

You can have my email if you want, no problem.  Rob D has loads more practical application experience with C-ISAM than me anyway though.

I meant the .com landing page for your company, I just hesitated to namecheck it although you probably mentioned it in the past anyway

I'm not quite clear whether you're asking about upgrading only Oracle or upgrading ProIV itself, but I suppose both if you want a supported combination?

All older versions of ProIV rely on the OCI7 interface to Oracle.  This © API has been obsolescent for nearly 20 years and very stable.

It's usual that ProIV links dynamically to an Oracle shared lbrary at runtime in order to use the OCI7 API.  Unless perhaps that wasn't true of some of the oldest versions?

Because the OCI7 API is so old and stable, I'd guess there is a fair chance even very old versions of ProIV might work with recent versions of Oracle. Of course such a combination won't be officially supported though.  As you mentioned, there could be a need to redo the ProIV kernel "on site link" where that applies.

Upgrading a ProIV application itself from version 4 to something recent is, as Chris said, likely to be a major exercise involving migration/conversion and recompilation of the source code for an entire application.  It might be that more than one migration/conversion step is needed.

Oracle 10 is long out of regular support I think - it could be logical to aim for Oracle 12 at this point?  Recent versions of ProIV would support Oracle 12 I think.

I note Oracle have said the OCI7 API will finally be desupported in their next major release (although that remains to be seen and I believe it doesn't mean Oracle 18, which is just lipstick on Oracle 12).

Hi Rob,

To add 0.02:

C-ISAM certainly is more dependable.  Using Pro-ISAM only for ProIV's own bootstrap files is a rational objective.  And you might be able to exploit the more-well-known nature of C-ISAM to get SQL access direct to your data, if indeed you're not doing that already.   (Although I'm not sure if there are 'free' solutions out there for that)

ProIV actually had support for C-ISAM with variable length records (external file type CISAMV), however, in C-ISAM that worked by putting data into the index (.idx) and so compromised the reliability/recoverability.  In any case I think that support might have been a specially licenced option.

It's been a long time since I looked at this stuff but I am mildly concerned about your choice of C-FLT as a data type, expecially for financial data.

C-FLT directly represents the C programming 'float' type, which is a 'low' precision binary floating point type.

Because it's a binary floating point type it doesn't accurately represent decimal fractions (e.g. cents)

The maximum precision is likely to be 9 decimal digits total (maybe OK, but wouldn't be in banking etc.)

The storage representation will be machine-specific, whereas C-ISAM can store data independently of chip architectures.

For these reasons, I think C-ISAM has always suggested/recommended using the DECIMAL (C-DEC) type and, personally, I would recommend that too.

Cheers,  Richard

PS.  I noticed something seems slightly wrong with some links on your own main www page - stuff is linked to localhost:10080 ?