How different is DB2 for AS/400 and for mainframe? For example, the high-level DB2 administrative privileges. Catalog names such as SYSADM, SYSCTRL, SYSOPR, DBADM, PACKADM, DBMAINT, DBCTRL, or catalog views such as SYSCAT.DBAUTH, SYSCAT.COLAUTH, SYSCAT.TABAUTH etc, are they using the same names for both platforms (AS/400 and mainframe)?[Br _extended="true" />

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

Processing your response...

Discuss This Question: 4 &nbspReplies

There was an error processing your information. Please try again later.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

How different is DB2 for AS/400 and for mainframe? For example, the high-level DB2 administrative privileges.
In that area, there is quite a lot of difference. There is no actual separation between i5/OS and DB2 in the AS/400. DB2 is directly integrated into the object-based structure of the system. So, at the level you're asking about, there are many elements that simply don't apply in the same ways.
Catalog names such as SYSADM, SYSCTRL, SYSOPR, DBADM, PACKADM, DBMAINT, DBCTRL, or catalog views such as SYSCAT.DBAUTH, SYSCAT.COLAUTH, SYSCAT.TABAUTH etc, are they using the same names for both platforms
Generally, no. Mostly because most of it isn't exactly needed in the AS/400 line.
Now, that's not to say that directly parallel functions don't exist. Much of it is made visible to database processes through UDFs for example. To pick a single item for illustration, you might want a list of table authorities and would have possibly queried SYSCAT.TABAUTH on a mainframe. On a reasonably current system from the AS/400 line, you might instead query:

SELECT *
FROM SYSIBM.SQLTABLEPRIVILEGES

Other specific items may have parallels, while others simply have no reason to exist. A number of items have been added to the AS/400 line in the last few releases not because they're actually needed, but because DBAs from other platforms expect to find them. UDFs (supplied by IBM with the system) may extract and/or construct data from the "real" system functions in order to present it in more familiar forms.
Don't lose sight of the potentially large difference between "mainframe" and "midrange". A large mainframe might be comfortable with a few hundred thousand users, and there will be tools to mange the activity from them.
But midrange systems tend to have tools geared to an order of magnitude (or two or three) smaller numbers of objects. There aren't many who'd be interested in using WRKACTJOB to scroll through 50000 active jobs. Databases and other objects have similarly limited tools.
OTOH, the AS/400 line is expected to be more self-sufficient, requiring a relatively smaller staff to manage, operate and maintain it. So, the higher-level stuff is simply different.
For DB2, you can still use the same SQL statements to create and manage database objects, and the statements still have the same purposes and effects. But the specific objects that may be exposed at those higher levels are often different not only in name but in physical implementation as well.
Tom

If by MAINFRAME you are referring to a machine running the z/OS operating system, the answer is that the DB2s will differ (from somewhat to considerably).
The admin auths are quite similar. SYSADM, SYSOPR, DBADM, etc are about the same.
The catalog tables are different, names and content. (about 70 tables in approx 20 tablespaces - and another 10-12 or so tables in the DB2 directory (in a separate database). The information included in the catalog is similar, but the machines have different architecture and hence the data in the catalog is different. For example, DBRMs in z/OS probably live in PDS/E datasets.
Tom's query "SELECT * FROM SYSIBM.SQLTABLEPRIVILEGES"
is probably replaced by " SELECT * FROM SYSIBM.SYSTABAUTH" when on z/OS
There are many more initialization parms on z/OS than on LUW. Some of this is due to the machine design, but also because of all the other subsystems, started tasks, jobs, and users that have to share the machine.
But many (most?) DB2 concepts carry from one flavor of DB2 to the next : tables and tablespaces. partitioning. indices. constraints. logging. unit of work. threads. utilities. monitoring.
It is the way these concepts are implemented that change when one moves up to z/OS. The Devil is in the details.

Hi Tom & Meandyou, thanks.
I'm not very familiar with DB2 and AS/400, but here are the specs: OS V5R3M0 and AS/400 model 9406-550.
I just want to query the high-level administrative privileges information from DB2 AS/400, especially the database privileges and the table & view privileges but don't know how.
Are there any free documents that I can download from the internet that will help? Or perhaps there is another way to do it.
Rauf

I suggest you go talk with your DBA. Ask him to help you with this.
Your question seems sort of vague. You may run into authorization problems. They may come to see you to find out why you are checking on the authorizations. (My work place takes a very dim view of people trying to snoop around.)

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy

Processing your reply...

Ask a Question

Free Guide: Managing storage for virtual environments

Complete a brief survey to get a complimentary 70-page whitepaper featuring the best methods and solutions for your virtual environment, as well as hypervisor-specific management advice from TechTarget experts. Don’t miss out on this exclusive content!

Share this item with your network:

To follow this tag...

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy