I'll have to admit that I'm getting pretty frustrated with the Java product. First I have to jump through hoops with V5R2 because PM400 will not work without a user id with QSECOFR authority, but the profile can't run under QSECOFR itself. And this profile can't be *DISABLED. And this profile can't have the initial menu set to *SIGNOFF. And it's necessary to set PWDEXPITV to *NOMAX for that user to avoid having the scheduled jobs fall over when the password should be changed. All this because the code is written to run on the Java engine and the engine requires it. All to be fixed in some future release. Then I go to load the latest cum and find out that the Java PTF group is showing as not installed. That's curious. I order and load SF99169 Lvl 017, re-ipl, and it still isn't right. The reason: the PTFs will not install without QALWOBJRST set to *ALL. *ALWPTF will not work for Java PTFs. All to be fixed in a future release. This makes me regret that I ever wrote our security standards. Standards that require that user profiles with *ALLOBJ authority be documented with their passwords stored in sealed envelopes in the data center. Standards that forced me create seven new sealed envelopes sorting out the PM400 debaucle. Standards that force me to note in the system's "Captain's Log" that SYSVALS had to be changed for a day in order for IBM received PTFs to be loaded. Standards that force me to note in the same log when the values could be changed back because we're done with the Java PTF loads. For a product that prides itself on being security conscious, you'd think that somebody would rein in the Java programmers and get them on the same page. For goodness sake, learn how to sign the objects, run under an IBM supplied profile for IBM supplied programs, and know when we're loading valid PTFs.
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.