ARSDOC GET -L produces "error"

[grahaj7]

hi!

I have a need to run ARSDOC GET to get the 'most recent' version of a report.   I don't see an option for this, so I have come up with a couple ways to do it:

1. First run a QUERY (sorted), use the results of the query to get a REPORT_DATE and then run an ARSDOC GET with that date as criteria.
This would totally work but, I would need to do that programmatically and I will be turning this process over to others, so the simpler the better. 

2. Running an ARSDOC GET -L 1  (limit 1) actually does the trick because the reports are sorted in descending order and the '-L 1' limits it to one report only.  I always get the most current report. So that works, BUT when I use that I get

ARS6055E A maximum of '1' hits(s) were requested for this query. The number of matching hits found was '1982'.

and ARSDOC returns 768.

It's odd that this is an "error" because I specifically asked for '1' result, and that's what I got.  The rc768 would get flagged by the scheduling software and force an abend.   I could tell the scheduler to ignore the rc 768 but rc 768 could happen for other reasons which need addressed, and SHOULD abend.

Has anyone come up with a simple way to get "most current report" that  is not either of these two? :)  I thought about putting in an enhancement request to IBM to ask them to not produce an error/rc 768 for the second case.  (I know that would take time even if it were acceptable. )

[Lars Bencze]

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! ;)

[Justin Derrick]

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.