There are two problems that I am at a loss for finding a solution with CMOD. One is that a user is complaining that when they want to view a PDF with on demand, it is showing the wrong information for the third field. I see in the forum you referring to setting these type of things up, but do not see where that happens. If you could point me in the right direction or give me some basic help I would be grateful. See attachments.

Second, is there some type of log on the IBM i for on demand to show what is happening when a report fails? I have a report that does not get archived. It is not on ONDERR. I can see in my program that I am pushing the report to ONDEMAND out queue. I see data base files in QUSROND but not sure if any can be useful to me.

Thanks. Any help would be appreciated. We have users waiting for months on tickets, and I just got assigned to them with no training or experience with On Demand.

Our issue has been solved. In addition to posting here we also opened a case with IBM. Their recommendation was to remove the ARS_LDAP_GROUP_USER_FILTER_USE_DN parameter altogether. After we removed it, users were successfully added to the appropriate groups.

I've never seen this behaviour before -- in my experience, arsmaint has always been happy to wipe out thousands of loads at once, clearing out an entire App Group if the data was old enough.

There's also a patch n 10.5.0.1 for an expiration issue:

      PH22616 - When an Application Group has over 5000 loads to expire that
                are under implicit hold, arsmaint -cd -g AGName will go into
                an infinite loop

-JD.

Our installation is on Windows 2019 running version 10.5.0.4 We are in the process of testing arslsync and are finding that users are being successfully created in CMOD but they are not being inserted into the CMOD group that matches the LDAP groups from which we are syncing.

Is that an invalid expectation? Or would we be missing something in our LDAP parameters?

Here is what we have entered for some of the LDAP parameters:

ARS_LDAP_BIND_ATTRIBUTE=uid
ARS_LDAP_GROUP_FILTER=(&(objectclass=groupOfUniqueNames)(|(cn=11400_DS_CMOD_Dev_Testers)(cn=11400_DS_CMOD_Dev_Developers)))
ARS_LDAP_GROUP_MAPPED_ATTRIBUTE=cn
ARS_LDAP_GROUP_USER_FILTER_USE_DN=FALSE
ARS_LDAP_IGN_GROUPS=Claims,Contract-Management,Drug-Rebate,EDI,EPSDT,Financial,Fraud-Abuse(SUR),MAR,Med-Buy-In,Oracle-Accounting,Oracle-Premiums,Provider,Recipient-Eligibility,Recipient-Enrollment,Reference,Remittance-Advice,RRI,System-Wide,Tester,TPL
ARS_LDAP_MAPPED_ATTRIBUTE=uid
ARS_LDAP_SERVER_TYPE=OPEN
ARS_LDAP_SYNC_USERS_ONLY=FALSE
ARS_LDAP_USER_FILTER=(&(objectclass=memberPerson)(|(isMemberOf=cn=11400_DS_CMOD_Dev_Testers,ou=Groups,dc=thirdparty,dc=tn,dc=gov)(isMemberOf=cn=11400_DS_CMOD_Dev_Developers,ou=Groups,dc=thirdparty,dc=tn,dc=gov)))

We are also looking at implementing using arslsync and also would want the user name populated. In our installation the LDAP is external and is supported by another vendor. Since we are not the administrators of the LDAP we won't be directly logging on to the LDAP. In our case, having the user names included in CMOD as well as the LDAP will be helpful for validation and reporting. When we get a help ticket for a user it would be good to be able to see that the user ID supplied belongs to the person specified in the help ticket.

It's been about a month, and I'm just providing a little update on our status...

ODUG's mail server is working well, and our 'deliverability' is very good -- very few messages are bouncing back.  You can help improve our mail server's reputation by rescuing any messages from the forums that arrive in your 'spam' or 'junk' folder by marking them 'not spam'.  Thanks!

The forums have been re-organized, re-named, and their descriptions expanded to be more descriptive.   Some forums have been archived -- they will remain since some contain good information, but they're now closed to new posts and replies.  If there's a post you want to revive, send a message to me and I'll move it to one of the active groups.  As part of this organization, behind-the-scenes, we've simplified access controls.  Don't hesitate to reply here if you experience an issue.

Bugs continue to be squashed, but attachments are still being tricky.  As mentioned earlier, they weren't able to be rescued from the old site, but right now, we're still not able to upload new ones.  This is likely an overzealous security setting on the web server, I'll keep working on it.

Finally, there's going to be a few minor cosmetic changes to various areas of the site over the coming weeks, primarily to improve accessibility.  A quick check with a website auditing tool has shown that our colour scheme lacks sufficient contrast for folks who are visually impaired (some elements are already fixed!), and that the size of certain user-interface elements are too small to navigate comfortably -- you may already notice that the navigation bar is now larger and has more generous spacing!

Thanks again for your participation in ODUG!

-JD.

Quote from: Justin Derrick on October 16, 2024, 03:19:21 PMYou forgot to add GROUP_OFFSET:, GROUP_LENGTH:, and GROUP_FILENAME:. 

Also...

> arsload: Load Version <8.5.0.6>

😢

-JD.

Thank you , this did the trick

regards

Michel

If you have tips and tricks. I have the roughly the same assignment.

regards

Michel.

> Please Justin, please. Do not remind me 😭

I'm currently working on a v7.1 AIX -> v10.5 Linux upgrade.  I feel your pain!

-JD.

@Justin

arsload: Load Version <8.5.0.6>

Please Justin, please. Do not remind me 😭

Took over the support of this customer for ondemand.
It is not touched for seven years.....

I will add you recommendations to the index file.

Thankyou

Kind regards

Michel