We have a very important application, but so far no source code. The application was written in COBOL and a compiled version is in our production system and is running.
However, we need to migrate to a new server, and new cobol compiler. We're under the impression that we need to recompile the code to get it to work on the new server. Running the exising compiled program gave runtime memory errors.
We have some source code for the program, but it is old. Not sure what the diff is between it and the compiled program.
Okay, so the question -- what should we do?
Time is not on our side, since we have to send our old server back to get credit for it. Ideas, suggestions, crazy or otherwise? (source control is obvious and its not up to me to do it, so save the lectures)
Create an image of your old server. Then run the old server as a virtual machine on your new server.
However, I agree a better option is probably to keep your production server.
In the short run it would probably be cheaper to arrange to keep the old server. In the semi-long run, you need to make time and budget to reengineer the program, either re-write it or see how much effort it would be to hack the old code into shape doing what the program currently does.
It's sadly. You should consult the Source Recovery Company
If your source code is relatively close to the compiled version, try this:
decompile new version into assembler
compile the old source code into assembler
compare
reconcile as best you can the differences from new version with old version, into the old souce code
repeat
To augment this, and probably as a second step, as it will bring the source code farther from the new compiled version, test with input data and just try reverse-engineering based on the output what would be needed to create that output. The more test input data you have the better this could work.
Good luck!
(I'm not a COBOL programmer but..)
If you know what version the compiler was that compiled the original program, you could at least compile the old cobol source; if the compiled versions is identical you know the source actually is the current version.
If they differ, you could try to (somehow) decompile, or at least disassemble, the working compiled version and the freshly compiled version and use a diff tool to get an idea of how big difference there is.
crazy sugestion: COBOL DECOMPILER --> SOURCE --> NEW COBOL COMPILER...?
(edit: http://juggersoft.com - PAID cobol decompiler)
if you have the .int (intermediate) binary files you can just run on the new server, if not, them you musto to recompile.
The program could have been produced by an external resource and that person or software house or organisation could have the latest source in their repository. It may be held by your parent organisation if you have recently merged, or may be in a different or backup computer installation in your organisation. There may be a copy on the developer's user account and may not have been sent to the production or live site or someone from head office has a copy to assess and try to resolve the situation. You may have success if phone those people or you could always talk to the installation computer operator or support staff and see if they have one on mag tape, CDROM or other backup storage.
Related
After Googling, I found a lot of HipHop documentation, but plenty was posted between 2011 and 2013.
Earlier this year was launched a new version of HipHop that even supports Drupal and includes a lot of improvements...
I've always used the Zend Guard to deploy my commercial applications, but now I started to consider seriously the use of HipHop in production, but here comes the question:
We can run an application using only the bytecode HHBC (Without .php source code)?
Follows the reference of my research
https://github.com/facebook/hhvm/wiki/FAQ
The question may seem very obvious, but it is not so easy to find this answer in the project documentation.
Thanks in advance!
Well, yes and no.
HHVM has a so-called RepoAuthoritative mode in which the HHVM will no longer check the existence of the PHP files or how up-to-date they are; instead, it will retrieve the HHBC directly from its cache.
Theoretically, you can follow these steps:
pre-generate the HHBC for all your PHP files and insert that HHBC in HHVM's cache. This is the so-called pre-analysis phase (if you ever see it in HHVM documentation, this is what they mean by it)
turn on RepoAuthoritative mode (it's just 1 line in HHVM's config)
delete your PHP code
This way your PHP applications will run just fine without the source code being present. Doing a server restart won't change this since HHVM's bytecode cache lives on disk (it's implemented as an SQLite database).
However, it will be kind of a headache if you:
want to change something in your code. You would have to copy your code, make the change and repeat the pre-analysis phase.
want to upgrade HHVM to a newer version. HHVM uses its build ID as part of the cache key so, if you upgrade it, the bytecode cache becomes unreachable and, since you'll be running in RepoAuthoritative mode, your application will be reduced to a bunch of HTTP 404 errors. To fix this, you would have to repeat the pre-analysis phase as well.
Bottom line: no upside, big downside. There's just no point in doing it.
PS: I hope I answered your question. It's also possible that I misunderstood what you asked; if that's the case, please let me know in a comment.
I have two PCs both with XE2. I thought that I had installed identically on both but have problems installing 3rd party packages on one while the other is just fine.
I want the same on both anyway. The easist would probably just to "migrate" the working set-up by moving in into my Dropbox folder. Can I do that? If so, how?
If not, can I (easilly) backup my registry settings on one machine and then import them on the other?
I suppose I could just sort out the problem on the one PC, but am not having much luck so far. I would rather invest the time in only having one Delphi setup. And since I am moving lots of other stuff to DropBox anyway ...
The tool for this is now built into Delphi XE8 and higher.
It's found here:
C:\Program Files (x86)\Embarcadero\Studio\20.0\bin\migrationtool.exe
Online documentation:
http://docwiki.embarcadero.com/RADStudio/Rio/en/Settings_Migration_Tool
Install CnPack wizards from http://www.cnpack.org
From the CnPack toolbar select IDE Config Backup/Restore (image below) and save this file somewhere safe
Copy the components to the second delphi machine . Keep the exact same directory structure.
I store my components as follows this helps backing up, moving etc., but you can use your own structure
D:\components_bds\DCU
D:\components_bds\BPL
D:\components_bds\ComponentsThemselves
Use the restore config file from CnPack to restore your components on the new machine
This is also useful if your testing components that you plan to remove later and keeping a backup of your installation incase something goes wrong you can save time with new delphi installation if hard drive dies. Keep a copy on flashdrive or somewhere safe
You may compare/diff the config file created by cnPack using a tool like Beyond Compare and see what the differences are to find out why third party components give problems on one of the machines. It may be a Delphi registry/installation problem or a problem in the paths of the thirdparty components. Components need to be installed in an order perhaps it did not find the needed dcu or dll it depends on.
I don't know of any way to do so with DropBox. Here's an old post I made (related to Delphi 7, but with correction of registry keys still applicable) in the CodeGear newsgroups; hopefully it will help.
(It probably goes without saying, but back up the existing registry settings on the destination machine before starting by using RegEdit and exporting them, just in case. You'll at least be able to get back to the point you're at now if something goes wrong by deleting the imported entries and then importing the saved ones.)
You can't, without some difficulty anyway. (Especially if you have
third party components installed, as they may have placed files in the
%SYSTEM% folder you may not know about.)
You may be able to (for going from the old computer to the new
computer running the same exact version of Windows!) by exporting the
registry keys under HKCU\Software\Embarcadero and
HKLM\Software\Embarcadero from the old machine, and then after
installing Delphi on the new machine (in the exact same folder
location) importing that registry file.
Many of the compiler, linker, and other settings are configured on a
per-project basis, and should transfer over when you move your source
code to the new machine.
Third-party components are a problem, as I mentioned above. You may be
able to get away with using the registry export/import if you copy
each third-party component set from the old computer into exactly
the same location on the new machine before importing the registry
file. You'll probably have to track down some .BPL files that end up
in the $(BDS)\Bin and possibly other folders under the $(BDS)
tree; the IDE will tell you about missing stuff when you try and start
it. Make sure you answer "Yes " when asked if you want to try and load
it again next time!
Most of my development is hobby stuff or wannabe releases. Instead of dying trying to move my XE2 Pro from my Dell Inspiron N7110 Win 7 machine to my new Win 10 SSD machine, I'm seriously thinking of switching to Lazarus. I've used Lazarus 2.x with Indy 10, ZeosLib, and Firebird and successfully created a working distributed internet system. I also created Lazarus version of my XE2 Blackjack program. When compared to XE2, Lazarus (IMO) has only two weakness and neither are deal breakers for me. BTW, I have successfully duplicated Lazarus (with all installed components) from one machine to another simply by copying and pasting the Lazarus directory and it works. Try that with Delphi.
Sam
So here is the problem: Recently someone bought a new PC for server to replace an older dating from before 1985 (i wonder how it is possible to work daily from then) .
He wants to put there the old COBOL software and he isnt willing in any means to rewrite it to something better..
So is there any compiler for 1985 cobol? For nowadays red hat linux? Googling it found opencobol and other few but all converted the code to c... Seems too compilacted too me..
UPDATE AS REQUESTED
AIX was the old system
What's the problem with converting the COBOL to C and then compiling? As long as it works. Early C++ environments were implemented in the same way: they converted the C++ to C, and then invoked the C compiler.
Converting the COBOL to C allows them to use high-level abstractions that implement the COBOL equivalents in C. They can leverage the standard C libraries, and also convert the COBOL data access code into calls to widely available databases like MySQL. Finally, converting to C and then compiling leverages the vast amount of development effort that went into code generation. Were they to try compiling directly to object code, they'd have to generate the intermediate code expected by the GNU compiler subsystem, or they'd have to go directly to object code. Either one of those would be much more complicated than converting to C, meaning that the likelihood of bugs in the COBOL compiler would be much higher.
From where I sit, I'd say OpenCOBOL is worth looking into. Note that they say they implement "a substantial part of the COBOL 85 and COBOL 2002 standards." You probably want to make sure that they implement the parts that you need.
I would also suggest that you look into TinyCOBOL.
You don't mention when the application, or AIX was last updated. If these were updated in the last few years, you may be able to port the application, without re-compiling. You should check to see what COBOL compiler was used originally, e.g IBM, RM/COBOL, AcuCOBOL, etc. It might be possible to buy a run-time only version (will execute, but not compile), which would be cheaper than buying a compiler.
A company called Micro Focus make a cobol compiler for Windows but I can assure you it is not cheap at all!
Standard method for doing this is called migrating and involves a number of steps including converting source file to a textfile format or a filetype compatible with the target computer, using an approved method of converting to a file and writing to magtape with compatible recording method of Phase encoding or to disk or other data medium possibly in the ASN.xx mode, transferring to the new computer to then read in the file (through ASN.yy) and store it in a native or import file format, then either use a utility to convert it to the sourcefile format or by running the program development environment to access the native text file or import file and saving the content as a native sourcefile. Perform manual checks and amendments to the source or script code and then compile the program and repeat alterations until a working version is achieved. Create test data files on the new computer and create a new jobfile or macro to run the job in the development environment. When fully tested the program can be run live using data files and live macros or jobfiles migrated over from the old system or newly created in more or less the same way as bringing over the source code. An important point is that the live data must be read into a specialized data takeon or loading program to achieve a populated database before any new transactions occur in the case of a structured datafile being necessary. When moving from AIX or other versions of Unix to an entirely different operating system the characters for end of line and linefeed and end of record may need specific conversion if they are not handled by a file format convertor or exporter utility.
My computer crashed recently. We have a Delphi app that takes a lot of work to get running.
One of my co-workers has it all installed still. Is there a way to copy the stuff stored in the palette? And the library paths?
I am using Delphi 5 (I know it is very very very old)
That information is stored in the Registry. I don't know exactly how Delphi 5 does it, but try looking for a key called HKEY_CURRENT_USER\Software\Borland\Delphi\5 or something like that. You'll find all the registration information under that key, including a list of installed packages. You can export the keys to a registry file, copy it to the new computer and install it.
Standard disclaimer: Mucking around in the registry manually can be risky if you don't know what you're doing. Be very careful, and if this solution causes your computer to crash, your house to burn down, or demons to come flying out your nose, it's not my fault.
Try CNWizards which has an export functionality for your IDE settings. You can use the same tool restore them on the new machine. We use it to get the same settings on every development machine. In that way we can ensure that all builds are the same, regardless of who built it.
Based on my experience of having done this a few times(!), the most important registry keys are:
HKEY_CURRENT_USER\Software\Borland\Delphi\5.0\Known Packages
HKEY_CURRENT_USER\Software\Borland\Delphi\5.0\Library
and possibly
HKEY_CURRENT_USER\Software\Borland\Delphi\5.0\Known IDE Packages
and maybe
HKEY_CURRENT_USER\Software\Borland\Delphi\5.0\Palette
HKEY_CURRENT_USER\Software\Borland\Delphi\5.0\Palette Defaults
So long as you have done a standard D5 installation first.
It's easier/more reliable to let the IDE fill in the other bits as you start using it and you change options as appropriate. Some component packages, eg madExcept, DevExpress etc are often best re-installed using their own installers anyway.
Unless you're going to have multiple users on the same machine using Delphi then the HKLM stuff isn't really all that important - I don't think.
As a related aside - I have learned that a good way to handle this is to build a FinalBuilder script (or similar) to set up my Delphi environment each time I decide to use a new machine/installation. I copy/download/checkout (which can be done in FB too) all package source then use FB to compile it, copy it, create dirs, and fill in the appropriate registry keys etc. I always get a consistent environment and makes it much easier to rebuild individual components or packages as and when they get upgraded too. The items can also be put into the script in 'dependency order' so that you know to re-compile a dependent package if something else changes. I now have a single FB sciprt that builds D5, D2007, D2009, D2010 environments and packages of all my main components, all depending on which compiler(s) I'm interested in which I indicate by a simple variable. Well worth it.
Seems to have just worked for me on a Win 7, SP1 and Delphi 5
Logged as user with Delphi & 3rd party components installed.
registry export
hkey current user\software\borland
(no other borland products so selected Borland)
rather than Borland\Delphi\5.0)
Logged into pc as new user.
Did not start Delphi5 (i.e. never started for this user).
Regedit File, Import
Started Delphi all components, including lots of 3rd
party, present.
Project compiled as expected under new user.
Is there currently a feature that allows a exclusive checkout in SVN?
Is there a good plugin for Delphi that allows the access via IDE?
SVN has a concept of "locking" which roughly corresponds to the exclusive checkout. For example, in TortoiseSVN this is exposed via Get lock and Release lock menu entries.
JCL contains a SVN version control expert which works quite fine. Besides other things, tt gives you access to the locking functionality from the IDE.
TortoiseSVN can be added into the Delphi tools menu. I've not tried this myself, since I'm happy using it as an Explorer extension.
Regarding the exclusive checkout, I'm guessing you mean so only one person can edit it at a time? That's not really the idea behind Subversion, the idea is you have working copies and then check in your changes. It'll then try to merge your changes in (this usually works most of the time). If there are conflicts you'll need to resolve them manually.
I believe one of the reasons why people sometimes enquire about locking items in a Subversion repository is because they have their Delphi DFMs saved in a binary format, which makes committing/merging problematic.
An alternative to changing DFMs etc to text is use Scooter Software's Beyond Compare.
Beyond Compare is written in Delphi, and natively knows how to read binary DFMs. This means that it then becomes less of an issue (or even no issue) whether your DFMs are stored in Subversion in binary or text. Beyond Compare V3 also does 3-way merging which makes it really easy to merge multiple commits etc. Even ignoring the ability to diff binary DFMs, it's still a much better diff viewer than TortoiseSVN's built-in tools. I can highly recommend it, and it's very inexpensive.
Currently the only things that I lock in our repository are COM type libraries (*.tlb and their associated *_TLB.pas files).
Regarding exclusive checkouts. It can be done, but it's a pain and generally not worth the time. If you do have dfms saved as binary, convert them to text.
Regarding delphi addins, I have a post at Delphi addins for subversion.
I use the jedi jcl, and TortoiseSvn.
There are also Delphi svn and Delphi addin in for Tortoise svn that I know of.
Maybe I'm naive, but why would anyone want to go to the enormous trouble of merging their changes? Merging might be a simple matter if programmers were editing text files whose contents are easily understood, and which therefore could be merged by virtue of the programmers knowing the meanings of the changes. However if you're using SVN with MS Visual Studio, where changes to one file frequently case changes to other files you didn't know about, and where the encoding of information in such files may be completely unknown to the programmers (who would therefore have no concept of how to interpret much less merge such files) and may even be binary, why would you go to the enormous trouble and risk of having multiple people simultaneously editing things?
The locking paradigm is simple. Only one person edits at a time. Merging is never required. Programmers don't need to know the encodings of (possibly binary) files that they don't even realize that they're modifying. Nobody can stomp on anyone else's changes. Locking (i.e. locking by default) sounds much preferable to me.
What do you mean by "exclusive checkout"? Do you mean that after you check out, nobody else can check out?
That's called a lock and subversion can do this (see Locking), though it's not recommended in general as the purpose of version control is to allow multiple people to simultaneously work on the versioned item.
For first part, I was using Visual Source Safe which is support locking (you have to check out before use), SVN has locking command, but it's against it's concept, you need few time to get used with it, and you will never use the locking command again.
For second part of your question, The TortoiseSVN can be used as external tool, or you can get it working with File Browser bundled with Delphi 2007 and above, and you can use IBrowser which work with older versions.
and Subversion add-ins for Delphi summarize the available SVN plug-ins for Delphi IDE, beside SourceConneXion which is commercial product.