Has anyone had any experience using NAT42 or NAT82 and EXX71/72/73, even if these versions are not a prerequisite for that Natural versions? If so, which procedure you have executed: which version was compiled for NATRPC - the old one or the new one? besides copy NATCLTGS, Stubs (when autorpc is off), …
The environment that I am facing now, they dont use ACI, only RPC on both side (client and server).
Does anyone have any hints for this Natural migration? (for the project, at this moment, exx is not being considered to be migrated)
Your questions are unclear: are you migrating from Natural 4.2 to Natural 8.2? And you want to know if you can continue to communicate with an elder (unsupported) version of EntireX while you upgrade?
What “procedure you have executed” are you asking about? which old one/new one???
hi, sorry for this misunderstanding, as I have environments with zos1.9 and zos1.11, the idea is to install nat42 on zos19 and nat82 on zos11, since it is not possible to install nat8 on zos19. .
tks.
Is it not possible, or is it just that NAT 8.2 isnt documented as being supported on z/OS 1.9 due to IBM platform support timing? I am just curious if you tried and ran into troubles.
I have a really terrible position I am in because our mainframe platform guys are not good about staying on supported versions of z/OS and CICS. That doesn’t stop us from wanting to be on supported versions of SAG products, but I am always afraid of getting too far ahead of them for fear I run into a problem and SAG says “we can’t help unless you upgrade your z/OS version” (which I have no control over).
We’re still running z/OS 1.7 with Adabas 8.2.3, Natural 4.2.7 and EntireX 8.2.2. I don’t think 1.7 was ever on the list of z/OS versions that are supported under these.
tks for the info, but the problem is not about NAT, I am sure that NAT8 doesnt run on zos1.9, on first compilation, I have tried it, the abend (warn) arise saying that it is not supported.
The question is related to NAT8, even if it is not supported, will it run with exx71,72,73? and what I need to concern at the migrate time. It seems that it will run as well, but I would like any opinion or better, any experience on it.
Tks anyway, and I would appreciate it a lot any considering about it.
I wonder if anyone had any experience using Stub generated on NAT3 or NAT4, and used them on NAT8. has anyone had to generate them again to use on NAT8 or it could be used the same stub generated previously? Does anyone know if these stubs are compatibles? in addition, do I also need to generate the old natctlgs or I can use the same natctlgs from nat3 or nat4, copying it only from fnat - sysrpc?
I can’t try the scenario you describe as I only started using EntireX with version 8. However, the Natural stubs are themselves just subprograms, and since they are created under Natural v4.2, I would defer to the documentation that states that Natural v8.2 supports catalogued object code all the way down to Natural v2.3 without being re-catalogued (though my input to that is for performance reasons you should probably have no object code out there older than Natural v3.1). Version 4.2 RPC clients should be fine as is under a v8.2 runtime.
I would expect your existing Natural RPC clients (stubs) to work as long as your Natural nuke includes the correct parms for RPC processing. EntireX version 7 may limit your maximum ACI version supported to the level you currently have set.
Software AG doesn’t support EntireX v7 anymore but I can’t see any reason an upgrade to Natural should break this if configured properly.
thank you for your explanation, and it is also what I think about. I have a simple example to test - server and client, and it worked. Now, I will face the test using the old enviroment. I just wanted to know in advance if there would be any problem or not about it. So, I will test it, and I will let you know the results.
When you say that I need using the correct parms, what parms would be? I have only RPC calls, and ACIVERS=2, as logon as COMPR=1, so, do I need to have on Natural include the old Broker RPC interface (NATRPC51, NATRPC61), or do I need using the new one (NATRPC82)? Besides it, we are using the same parms that I had before, i.e, MAXBUFFER=64,RPCSIZE=256.
In one of our test, Natural as client, when I have AUTORPC=ON (stubs being generated automatically), it works fine, however, the opposite, we are receiving NAT6971.
Those are the parms I meant. It’s possible you need NATRPC82 though if there was no NATRPC61 included in your library I’d think you would have had an error in the link-edit step as it wouldn’t be able to resolve your reference, so maybe the older RPC module is available and ok to use (which is what was supplied with Natural 4.2).
With any NAT6971 error you need to also use the reason code to help determine your issue (otherwise the error is too generic). Also, you may need to call RPCINFO to get the server and client codes (8 numbers each) for further explanation. A stublog trace may also be helpful.
as I had an opportunity to test only now, fyi, so far so good, i.e., it is working. I used the current NATRPC82 and the previous NATCTLGS and Stubs. note, I also copied NATCTLGS to SYSTEM (Fuser).
Now, I noticed some different behavior when I use NTASK. on previous version (NAT3, NAT4), when I had, for exemplo, NTASK=2, on the control center, I was able to see 2 instances, on current version (NAT82), there is only 1, even if I have defined NTASK=2. So, I hope it is information only and when I really need to use one more instance, the service would start it.
I followed the manual - adalnkr, reentr…etc…
Do you think there is something missing here? or, from now on, NTASK>1 works this way, and there will be only one instance even if n > 1 and when I need, the service would start it automatically…
I don’t know the differences in how NTASKS is seen with RPC servers running Natural 8 as I don’t have that version running yet. When you look at your registered services under System Management Hub, do you see active servers = 2 and attach managers = 1?
If not, it’s possible it’s just managing the number of tasks internally but I would think there should be some way to tell what your min and max settings (if applicable) are as well as your current level of usage or even highwater marks. Otherwise it could be hard to manage.
Hopefully someone can clarify. I may be off the mark thinking it could be seen in SMH but that was my guess.
If NTASKS=2 is working, you will see active servers = 2 in SMH. Natural RPC does not use the attach manager, so it does not start tasks dynamically.
If you are only seeing one, then there is a configuration issue with your Natural RPC server. Check that your batch JCL includes the appropriate DD cards for CMPRINTx’s for the SYSOUT for the additional tasks. The dependent nucleus (and shared) must be re-entrant and linked as re-entrant, so re-check your steps for assembling the nucleus.
If you terminate the service via SMH or SYSRPC but the job continues to run (you have to cancel it to stop the job), then there is very likely a problem with the re-entrancy of the nucleus. If the job terminates normally, then there is something missing in the parameters and/or DD statements (which should be apparent in the trace output CMPRT10) as the second task was not started.
I will double check the installation process, but I think everything is as you (or manual) said, because ADALNKR was used on the previous version, and the nucleo was generated as reentrant.
Just in case, I am not using SHM, I am still using control center on Windows. Broker is still 7.2 and 7.3, and Natural is updated - NAT823.
What I am not understanding it is that the previous Natural version works, and the new version not, or, maybe it is correct, and when I need more than one service, it starts automatically for NTASKS=2. For NAT82, we are still using the definition - NTASKS=2, that means the minimum are 2, but I am not sure if I use NTASKS=(1,2) would make any difference.
So, if there is something wrong to the installation process, I will do it again and I will let you know.
FYI, it seems that NTASKS works correctly, because we started the trace and when NTASKS=5, for example, 4 tasks are attached, it is: NTASKS= NTASKS - 1… I am not sure if it is correct, but as I was using NTASKS=2, just one was initialized, when we were looking for 5.
You know the first trace goes to //CMPRT10, second to CMPRT101, third to CMRPT102, etc, and standard out goes to CMPRINT, CMPRINT1, CMPRINT2, etc? How many servers are you seeing from SMH?
Check your CMPRINT and CMPRT10 trace carefully since they will report issues with starting tasks. For example, if you specify NTASKS=5, but don’t have a CMPRINT4, it won’t start the task. If you have CMPRINT4 but not CMPRT104, the task will start but no trace will be produced.
NTASKS has always started NTASKS for me, not NTASKS -1.