I have migrated (SYSOBJH) NATURAL 4.2.6 objects from z/OS to NATURAL 6.3.6 on WinXP. All of these programs stow on the mainframe. There are several that will not STOW on WinXP due to a NAT0907 error – “Generation of record buffer failed. Reason code 4. RC - description:
4 - For ADABAS/VSAM access statements record buffer size (view size)
exceeds the maximum of 64K (Mainframe/ OpenVMS/ UNIX/ Windows).”
The DDM being used by these programs (all report mode, no DEFINE DATA) is large, but not larger than 64K so far as I can tell. As I’ve said, these check/cat/stow with no issues on the mainframe. Any ideas?
At compile time, Natural will look at the DBID in the DDM. (If it’s zero, he’ll use the UDB value from the Natparms.) You need to determine what that DBID is. Then update your Natparms:
Natural Configuration Files
→ Global Configuration File
→ Database Management System Assignments
→ DBMS Assignments
Ensure that there is an entry for the DBID and that the Type is set to ADA2.
Ralph…
The DBID in the offending DDM = 0, which means, I guess, that NAT is looking to DB 12. However, all other modules (many using the DDM that seems to be causing the error) have already stowed successfully. None of the ADABAS files that are being used by the applications (pointed to by many DDMs) have been loaded to ADABAS (since I don’t intend to run the programs), just the DDMs (all with a DBIDs of 0). I have already CATALLed several application in this environment (a few thousand programs) with no issues. The 907 error has occurred in just 3 programs.
Note that I have no intention of running any of this application. I am transferring these applications to the WinXP environment for the purpose of loading them to the NATURAL Engineer Repository.
By default Natural generates Adabas calls in the old ACB format, which is fine for most of your modules. Your three problem programs need the newer ACBX format. When the DDM’s DBID is zero, you can tell Natural to use ACBX by defining the default database as type ADA2 in the DBMS Assignments section of Natparms. The default database is defined by the UDB Natparm.
Thanks Greame… I don’t plan to execute the code (normally), however, as part of the analysis effort (determining if/whether/when these applications may/may not be migrated to other platforms and/or technologies) I want to be sure that these objects do, in fact, stow in the Open Systems environment. And, if not, why not. Also, there are many instances where the object code running in PRODUCTION (without source being present) necessitates the source being pulled from the TEST/DEVELOPMENT environment. So in addition to loading this code into NEE, I want to be sure that it will STOW properly (some of these objects are very old).
Fair call. Ralph’s recommendation should have you CATALLing away in style.
It’s interesting to see another site like us who migrate code to an Engineer repository on Windows. Now that NEE integrates well with SPoD and the browser GUI interface is available, I’m wondering if it would be make sense to put the repository back on the mainframe. It would remove the tedious manual process of transferring the source and would allow us to keep the repository more readily up to date.
No need for adding this idea to Brainstorm, because this is already supported in the newest versions of NEE
There might be some additional licenses needed for having the necessary NEE bits on the MF.
But if there is an NDV server on the MF, the repository and the extraction can be placed/done on the MF and the UI in SPOD.
Finn
