Thanks for your reply Justin. Yes please let me know if you find anything.

Ah, yes -- I see what you're doing now. 

Try adding the query restriction to the User/App Group via the Admin GUI, then do another export -- that will show you how CMOD expects a query restriction to appear in the XML -- then you can try to modify a different account.

But as I said before, it's better to assign these permissions at the group level, so it's easier to understand what permissions a user has by simply reviewing the groups they belong to.  It also allows for simplified administration through your Identity and Access Management team -- adding and removing users from groups in Active Directory / LDAP will change their permissions in CMOD if LDAPsync is configured.

-JD.

Quote from: Justin Derrick on September 03, 2025, 05:19:52 PMYou need to specify the Application Group or User Group that you want to apply that query restriction to.

As a matter of good governance, all permissions should be administered at the Group level, and users added to and removed from Groups in order to grant or restrict or deny access/permissions.

-JD.

Yes, although I specified the group, I still cannot update the query restriction using the arsxml command.

...
  <applicationGroup name="AG1" ... >
     <permission group="GROUP"  ....... queryRes="br_code = '001'" />
...

IBM suggested to create a common group in AD and map all the other groups as a member of this group. And use the common group to get all the users linked to the member groups using nested query.

Common group name : ONDM-ALL

ARS_LDAP_USER_FILTER=(&(objectclass=user)(memberof:1.2.840.113556.1.4.1941:=CN=ONDM-ALL,OU=ONDM-IN,OU=APPS,dc=xxxx,dc=yyyy,dc=zzz,dc=com))

You need to specify the Application Group or User Group that you want to apply that query restriction to.

As a matter of good governance, all permissions should be administered at the Group level, and users added to and removed from Groups in order to grant or restrict or deny access/permissions.

-JD.

I'm during try update query restriction by arsxml.

USER1 has permission to view application group AG1 but no query restriction configured at first time.
So, I export xml by arsxml export will have output xml something like this:

<onDemand xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <applicationGroup name="AG1" ... >
      <field name ... >
      <permission user="USER1" adminAuthority="true" lvAuthority="true" accessAuthority="true" docViewPerm="true" docAddPerm="true" docUpdatePerm="false" docDeletePerm="true" docPrintPerm="true" docCopyPerm="true" docHoldPerm="true" docCFSODPerm="true" docFTIPerm="true" annotViewPerm="true" annotAddPerm="true" annotDeletePerm="false" annotUpdatePerm="false" annotCopyPerm="true" />
       ....
   </applicationGroup>
</onDemand>

-- Then I have edit to --

<onDemand xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <applicationGroup name="AG1" ... >
      <field name ... >
      <permission user="USER1" adminAuthority="true" lvAuthority="true" accessAuthority="true" docViewPerm="true" docAddPerm="true" docUpdatePerm="false" docDeletePerm="true" docPrintPerm="true" docCopyPerm="true" docHoldPerm="true" docCFSODPerm="true" docFTIPerm="true" annotViewPerm="true" annotAddPerm="true" annotDeletePerm="false" annotUpdatePerm="false" annotCopyPerm="true"  queryRes="br_code = '001'" />
       ....
   </applicationGroup>
</onDemand>

When I execute arsxml command, it's not updated anything in permission:
arsxml  -hlocalhost -uadmin -ppassword -i update_perm.xml  -v -x -ecu

...
ARS7709I Adding applicationGroup-permission, AG1-USER1
ARS7743E A permission object named 'USER1' already exists.
ARS7761I Add of applicationGroup-permission, USER1-USER1 failed.

 -- Then I tried 'task="update"' inside xml tag, still no luck --
      <permission user="USER1" task="update" adminAuthority="true" lvAuthority="true" accessAuthority="true" docViewPerm="true" docAddPerm="true" docUpdatePerm="false" docDeletePerm="true" docPrintPerm="true" docCopyPerm="true" docHoldPerm="true" docCFSODPerm="true" docFTIPerm="true" annotViewPerm="true" annotAddPerm="true" annotDeletePerm="false" annotUpdatePerm="false" annotCopyPerm="true"  queryRes="br_code = '001'" />

But something changed in message ...

ARS7755E The permission object named 'USER1' can not be updated unless the parent object is also being updated.

Can anyone suggest solution to me?

Audience:    Anyone who uploads files to Blue Diamond using the SFTP protocol.

Description:    The current RSA SSH key, used to establish a connection to the Blue Diamond FTP server, will be replaced by an ECDSA (Elliptic Curve Digital Signature Algorithm) key. This change will affect anyone who uploads files to Blue Diamond using the SFTP protocol via command line or FTP clients such as FileZilla or WinSCP.

Effective Date:    September 8, 2025.

Action/Impact:    The current RSA SSH key, used to establish a connection to the Blue Diamond FTP server, will be replaced with an ECDSA key on September 8, 2025. Anyone using the SFTP protocol must accept the new key on or after this date in order to continue uploading files to Blue Diamond.

Implementing the new ECDSA key
•   Command line (sftp/scp) - Update your "known_hosts" file (this process varies between different OS. If in doubt, please refer to your System Admin or appropriate documentation)
o   If your known_hosts file has plain text hostnames (not hashed values):
�   Backup your "known_hosts" file
�   Get the new key from the Blue Diamond FTP Server and add it to your known_hosts file

ssh-keyscan -t ecdsa msciftpgw.im-ies.ibm.com >> ~/.ssh/known_hosts
o   For hashed hostnames/ip in known_hosts file:
�   Backup your "known_hosts" file
�   Get the new key from the Blue Diamond FTP Server and add it to your known_hosts file

ssh-keyscan -t ecdsa -H msciftpgw.im-ies.ibm.com >> ~/.ssh/known_hosts
•   FTP clients (ie. FileZilla or WinSCP) - When you attempt to connect to the Blue Diamond FTP server using these Windows tools, you will be prompted to add the new key to the cache.  When prompted, click "Always trust this host, add this key to the cache" and click OK.

•   zOS: Ensure your OS version supports ECDSA IBM zOS Support Doc at https://www.ibm.com/docs/en/zos/3.1.0?topic=ssl-elliptic-curve-cryptography-support

Support/Contact:    For more information or to request support, please email sdsmsci@us.ibm.com

Additional information:    For up-to-date status information on Blue Diamond Services, visit our Status Page at Blue Diamond Status Page at https://status.im-ies.ibm.com/index.html?continue

Hi Lincoln -- as you've already discovered, it's very complicated...

You need to match a user to the groups they belong to, and then the user groups to Folders, and then to specific Application Groups and Applications -- and there might even be query restrictions involved which further reduce the pool of data an individual user might have access to.

In the past, I've had to manually copy access privileges between servers, and it was a real challenge to get everything working properly.

I'll go through some old scripts / notes and post some SQL that might be helpful.

Hi Grahaj & Lars.

There's no real standard for what the various return codes mean, it's up to the developer to define them for each utility.

I'm guessing that in this situation, I'm guessing both 3 and 768 are warnings.  I'll test out this specific situation and see if I can narrow it down.  Both 3 and 768 are peculiar numbers, as they translate to 0000000011 and 1100000000 in binary, so the return codes might be different based on the 'endianness' of the CPU/OS.

-JD.

I reached this post via a link from a CMOD Wiki page relating to arsdoc Return Codes.

When I run a similar command, I receive RC 3, not 768. The main differences:
a. I run on a Windows cmd client, a Windows 2022 server, and I use CMOD version 10.5.0.7 (on both ends)
b. I run arsdoc QUERY, not GET:
   arsdoc query -h ondemand -f "myFolder" -i "WHERE field1='value1' AND field2='value2'" -u LILOLDME -p C:\Temp\my.stash -L 1

Maybe they changed the return code in a later version, or maybe it is different whether you run GET or QUERY?

I know the z/OS versions sometimes are quite different, and that they may not be in sync with the Multiplatform versions, but it would be interesting to know; If you run the same again, do you still get the same RC? Or has it indeed been changed.

@Admins: please don't ban me for typing the "W" word in a z/OS sub-forum! ;)