How can I set the file nbr to the actual file nbr, all of the DDM’s are showing file nbr 999 in Natural Security, Lib Maintenance, Modify DDM’s:
Predict however is showing the correct actual file nbr.
When I execute a Natural pgm against these files, I get a 3017??
Thanks in advance.
John
I am assuming this is in an open systems environment, right?
Can you change the DDM header directly with SYSDDM?
Sorry, I can’t try this quickly to give a solution… I have NSC set up to use an FDDM and remote FSEC from a mainframe.
Just saw your postings in the Predict thread, it actually sounds like you may not have predict set up completely. NSC just reports the info provided from the DDM header.
If the open systems version of Predict is the same as MF, you may need to check if you have any Database entries. Also check your DDM generation defaults.
Yes, open system as in Linux open system…sorry:lol:
Sysddm? I can login in to Predict(sysdic) and modify the ddm…
Before I moved the ddm’s all to system I could modify the headers in DDM Services, which in Linux can be accessed from any application library. However now that I moved all ddm’s to lib System, I can no longer see any ddm’s from any of the application libraries. I don’t get a 3017 anymore, but now will get a NAT 974: User is not authorized to use this file when I type ‘R’ while editing a program, yet if I enter the program name on the command line, the program will execute… and when I enter L V 'ViewName, I get the same NAT0974 error…
Unless it’s different than the MF Predict, it doesn’t actually modify the DDM. It only modifies the documentation that is used for the generation of the DDM.
Sounds more like you may have NSC issues, can you “L V viewname” from the SYSTEM library? If not, did you define the DDMs for the SYSTEM security (or link)? Sorry, can’t try any of this, like I mentioned before I have a fairly different setup.
The execution is not surprizing, the object would have been created back when everything was working. Yup, one of those quirks (features?) where NSC file security is a compile-time measure only.
I’m thinking I am missing something, just not sure…
I cannot edit any of the locals if they have a View defined due to the Nat0974 error.
So I am going to go back and checksee about my Security setup and/or maybe have a Margarita, :lol:
For each application library including SYSTEM, hit PF5 for Restrictions - on that screen change "Set status of DDMs: " to PUBL. All my DDMs are public so I don’t have to define each DDM as I remember doing when I used SYSSEC on the mainframe (quite a few years ago!).
Thanks for the response Priscilla,
I have set the status of all DDM’s to PUBL in all application libs and system as well…
Now I can check and stow without error, 
So you dont need any DDM’s defined in any application Library?
only in System? (Provided you have the Special Link and Update links in place)
Thanks again…
Linux :roll:
papajohn,
I’ve read some other topics posted by you. It seems, as if you migrate from MF to another platform (linux).
The Natural Security documentation (Version 6.1.1 for UNIX, section “Protecting DDMs On UNIX And Windows”) points out, that the protection of DDMs with Natural Security is different on mainframe computers from that on other platforms.
In my opinion, the main differences are:
-
Natural’s storage location for DDMs is not the same on all platforms: on mainframe computers, DDMs are stored in an FDIC system file, whereas on UNIX and Windows, DDMs are contained in libraries like other Natural objects. Therefore, Natural Security’s handling of the DDM protection is also different.
-
On Unix for every DDM that is to be used, two status classifications have to be made in Natural Security: an internal status and an external status.
The internal status controls the use of the DDM within the library in which it is contained.
The external status controls the use of the DDM by other libraries. The external status of a DDM is only relevant if the library that contains the DDM is used as steplib by other libraries. In your case, that is library SYSTEM.
You have set in all libraries the status of DDMs to “public”. That means, that all your files are not protected, they can be read and updated by any application. Is that what you really want?
If not, I would recommend to read the above mentioned Natural Security notes.
I’m on mainframe, so I have no experience on open systems. I’ve seen these differences between MF and Open System accidently.
Hope this helps.
Helmut Spichtinger
We have only one application and one application library so having all the DDMs as PUBLIC is fine. All my DDMs are in library system - none in the application library. I am stumped as to why you are still getting a NAT0974. Maybe you have actually defined some files specifically in Security? When we first got Nat Sec here I too had only used it on the MF, so tried to define all the files, with not too much success! It was a whole heap simpler to have no files defined specifically.
Just read the last two replies, thanks to Helmut and Priscilla, I will be reading up on the docs and checking the things you both mentioned in the morning, then post back with results, maybe not till monday though.
thanks again.
Yes we’re migrating from IBM to Linux… It might be obvious that I prefer the Mainframe, but economics forces us to change. :roll: