Did it. At last I managed to install Oracle V5.1.17.4 on MSDOS 6.22 under VMware Server 1.04. You probably think I am nuts. As someone said on our way home from Miracle Open World: “I would spend my time learning Oracle 11g”. Maybe. The person who said it, by the way, is an Oracle trainer, so what would I expect…
I / we (Bert Jan Meinders, an old colleague of mine) did our first attempt almost 1, 1 1/2 years ago. Our first attempt was based on VMware GSX software after we succesfully installed Oracle 4.1 on MSDOS. This was the first time (and until now the last time) I saw a total crash of VMware software. Oracle V5 was shipped under DOS with a memory manager called SQLPME (SQL Protected Mode Executive) V1.2.1.
This memory manager made extended memory available for use of Oracle software (database, forms etc), this way it could cross the 640 Kb boundary of conventional memory.
SQLPME was aggressive enough with its peeking and poking in memory that it crashed the VMware GSX environment at the time. Under VMware Server 1.04 it just hung itself up / nothing happened.
Click on the image to enlarge
VMware Server 1.04 been released a little while ago, so I thought, why not, maybe its time for another go…
What made my day, was a small post on the internet called: Toshiba, Technical Support Bulletin: T5100 Rom Rev. 2.0 or Earlier and Oracle
This mentioned a small setting about a special machine sqlpme setting: sqlpme -m2
I still have no idea what the “-m2” really meant, but I guess this is / was a way to distinct between 286 and 386 architectures. There is also still documentation out there (to my surprise) regarding sqlplme settings. Most of it is based on Oracle 6 technology, though the following, in Russian written, documentation / piece of text looks actually like it contains Oracle V5 based information: ch-01-02 (ORACLE RDBMS for MS-DOS Getting Started Version 5.1B).
By setting this parameter hardcoded, that is I protected the “oracle.bat” file with an attrib +r command, this time the installation of the Oracle software almost went fluently (OK, not completely fluent but I have it working now).
Click on the image to enlarge
OK, long story short. It works and all the available software to me, is installed, as the following pictures should prove.
Retro-Spectacle
PROTCHK Extended Memory Environment Check Program
Database warm started via “IOR WARM”
No UFI – SQL*Plus introduces itself
SGI – Reporting the SGA details
SQL*Forms V2.0.18.17 in full ANSI color
Expand – Adding a “TOOLS” datafile to the Database
“Oracle Open World” beat this…
I know, I am nuts… and I hope I find the time to completely document the installation steps for Oracle V5.1.17.4 on MSDOS 6.22 in a VMware machine. For all those who want to ask… No, I can not and will not send you the software because it (still) is licensed. Sorry.
Anyway, I hope you enjoyed the pictures.
😎
Related Posts:
In those days I was starting my IT and Database adventure using Clipper.
Old days …
In those days, I was learning my “Basic” and “Pascal” skills on something called a Prime Computer at school…
😉
Nuts?? Why Nuts?? I’m waiting for Oracle6 on VMWare.. 🙂
Do you help me (again) converting all 40 plus floppies to floppy images 😉
Sure…. always interrested in a ‘pizza-session’… 🙂
We should have applied for a decent job…
😎
I’ve being trying to do something similar without success.
Are you able to share your autoexec.bat, config.sys and config.ora files?
I think config.ora has an error. I didn’t touch that.
Johns (very informative) response via email:
Thanks Marco,
I’ve been trying to install SQL*Forms V3 on both VMWARE/MS-DOS 6.22 and an ‘empty’ MS-DOS 6.22 Pentium II without success. I don’t yet have a database installed.
SQLPME starts up OK, but starting SQL*Forms and SQL*Menu just give “Protection exception error 0D code=0000”.
Do you have any suggestions?
Regards
John Roberts
Also, the “-m2” in “sqlpme –m2” refers to the machine type.
You may have a MACHTYPE.EXE executable.
You can try “sqlpme –“ for a full list of parameters or “sqlpme-m?” for a list of machine types.
The following is the information posted / alas only available via Google cache of a post linked [here]. Because I can’t control Google’s caching mechanism and the original post already disappeared it is posted here for prosperity…
Installing Oracle Products for Windows and DOS
Read this if you are installing your Oracle products for Windows onto a workstation that already has either DOS products or older Windows products.
Oracle Home Directories
The Oracle Installer places most Oracle products for Windows into a separate Oracle home directory from Oracle products for DOS. The default Oracle home directory for Windows is \ORAWIN. The default Oracle home directory for DOS is either \ORADOS for products designed for the V3 Oracle Installer or \ORACLE6 for products that were designed for the V2 Oracle Installer.
Note: The default DOS Oracle home directory for products installed by the older V2 Oracle Installer is \ORACLE6. When a V2 directory structure is migrated to the V3 directory structure, the name of the directory remains the same. So, if the DOS directory name was \ORACLE6, it remains \ORACLE6. However, some older Oracle and 3rd party products for Windows are installed in the Oracle home directory for DOS. These products include, but are not limited to, the following products:
– Oracle Card for Windows 1.x
– Oracle for Windows (DDE Manager/Toolbook Interface) 1.x
– Run Form for Windows 3.x
– Run Menu for Windows 5.x
– SQL*Plus for Windows 3.0.x
– Oracle Business Manager 1.x
If you use these products, you must follow the guidelines described in the following paragraphs to maintain compatibility with other Windows and DOS products.
Configuration Files
Current Windows Oracle products look for configuration parameters in the ORACLE.INI file in your \WINDOWS directory. DOS Oracle products and older Windows products look for configuration parameters in the CONFIG.ORA file. The CONFIG.ORA file is located either in the \XBIN subdirectory of your V3 DOS Oracle home directory, or in your V2 Oracle home directory. Make sure that the following parameters in your ORACLE.INI file are duplicates of the parameters in you CONFIG.ORA file.
– LOCAL
– REMOTE
– SQLNET DBNAME
– INTERRUPT
– TCP_SERVICES_FILE
If a parameter exists in one file and not the other, add the parameter to the file that does not contain it. If a parameter does not exist in either your ORACLE.INI file or CONFIG.ORA file, you do not need to add it to either file. If the parameter exists in both files, make sure they are set to the same value.
Also make sure that the SET CONFIG or SET CONFIG_FILES command in your AUTOEXEC.BAT file points to your CONFIG.ORA file, not your ORACLE.INI file. The Oracle Installer will warn you if your CONFIG environment variable is set incorrectly. For more information about the CONFIG variable, see your DOS products documentation.
The DOS Path and Oracle Home for Windows
Since Oracle DLLs are now stored in the \ORAWIN\BIN directory and not the \ORACLE6\BIN directory, older Windows products and 3rd party products must be configured to use the DLLs in the new \ORAWIN\BIN directory. To do this, the Installer will ask you if you want it to modify your AUTOEXEC.BAT file to put the \ORAWIN\BIN directory on your DOS search path. Answer ‘Yes’ if you are using older Windows products that require new Oracle DLLs, or a combination of old and new Windows products that require the same DLLs. For example, you must put \ORAWIN\BIN on the DOS path if you are using Oracle Card 1.1 with a recent version of SQL*Net for Windows.
ORA6WIN.DLL
Older Windows products and many 3rd party products are shipped with an ORA6WIN.DLL file, which enables these products to operate under Windows. You must make sure that the most recent version of this file is used by all these products. To do this, you should put the most recent ORA6WIN.DLL file in your \ORAWIN\BIN directory and you should delete or rename all other ORA6WIN.DLL files from your workstation and from other locations available to your workstation via your network. You should also make sure that the \ORAWIN\BIN directory is on your DOS path as described in the above paragraph. If the installer detects obsolete ORA6WIN.DLL files, it will ask you if you want it to rename them. However, you also should check for this file yourself; the Installer will not search all possible locations. This is especially important if you are using products on a network.
Running DOS Products within Windows
You may use Oracle DOS products within Windows provided you run SQLPME before starting Windows and run Windows in standard mode, not enhanced mode. However, to let Windows run, you must limit the amount of memory that SQLPME will use. Otherwise, SQLPME may use all available memory and prevent Windows from running.
In order to force a ceiling on how much memory SQLPME will use, add the following line to your CONFIG.ORA file in your DOS Oracle home directory:
DYNAMIC_MEMORY=X
This will force all ORACLE protected mode products for DOS to run in no more than X kilobytes of extended memory. Windows will then use the memory that is not used by SQLPME. Make sure you set X low enough to allow enough free memory for Windows to run and high enough to allow DOS Oracle products to run. Also, do not set X higher than 16000.
When running DOS Oracle products from within Windows you must use DOS SQL*Net, not Windows SQL*Net, to connect to a remote database. Windows SQL*Net products are only supported in Windows enhanced mode not standard mode.
If you are running Windows in enhanced mode, you cannot run DOS Oracle products within Windows. You must not run SQLPME before running Windows in enhanced mode.
Toon has some Historical insight you might enjoy…
😉
See here: http://thehelsinkideclaration.blogspot.com/2009/03/helsinki-declaration-observation-1.html