LISTDSI

[Mosley, George]

Hello List.

I'm encountering what appears to be an anomaly with this LISTDSI command issued within a rexx exec:

DSRC = LISTDSI('SCM.ADS.TEST.ISPCLIB' NODIRECTORY RECALL)

I get the following response (from a trace):

ARC1020I DFSMSHSM IS RECALLING FROM TAPE DSN=SCM.ADS.TEST.ISPCLIB, PLEASE RETRY
THE USER REQUEST AFTER THE RECALL HAS COMPLETED.
>F> "16"
239 *-* IF SYSREASON="9"
>V> "0021"
>L> "9"
ARC0612I VOLUME MOUNT ISSUED FOR RECALL OR RECOVER OF SCM.ADS.TEST.ISPCLIB
ARC1000I SCM.ADS.TEST.ISPCLIB RECALL PROCESSING ENDED
ARC1001I SCM.ADS.TEST.ISPCLIB RECALL FAILED, RC=0002, REAS=0000
ARC1102I DATA SET IS NOT MIGRATED/BACKED UP
>O> "0"

The dataset was migrated/backed up and I used HRECALL in 3.4 on a similar dataset to prove it, getting this, the expected response:

ARC1007I RECALL REQUEST 00001241 SENT TO DFSMSHSM
***
ARC0612I VOLUME MOUNT ISSUED FOR RECALL OR RECOVER OF SCM.ADS.FIX.ISPCLIB
ARC1000I SCM.ADS.FIX.ISPCLIB RECALL PROCESSING ENDED
***

Any ideas or suggestions? Could this be a defect in the LISTDSI command?

George
________________________________
This email and any attachments are intended only for the named recipient and may contain confidential and/or privileged material. Any unauthorized copying, dissemination or other use by a person other than the named recipient of this communication is prohibited. If you received this in error or are not named as a recipient, please notify the sender and destroy all copies of this email immediately.

Insurance Corporation of British Columbia | 151 W. Esplanade | North Vancouver | V7M 3H9
Contact Us<http://www.icbc.com/about-icbc/contact-us/Pages/default.aspx/>

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

[Garrett, Robert]

George, are you able to HRECALL -that- dataset from ISPF 3.4? SYSREASON = 21 is indicative of some sort of catalog error during locate processing.

Robert Garrett

Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live
Its whole life believing that it is stupid. -Albert Einstein

[Lizette Koehler]

Did your storage admins setup HSM Recalls under TSO to WAIT or NOT WAIT?

PATCH .MCVT.+52 bits(..1.....) /* Alter the default for tape */
/* data set recalls from a wait */
/* state to a no-wait state */



PATCH .MCVT.+52 bits(...1....) /* Alter the default for DASD */
/* data set recalls from a wait */
/* state to a no-wait state */


Lizette

[Robert Zenuk]

Any chance you are doing it twice? I have seen that when trying to recall a dataset when another recall for the same DSN is already in progress and the second request overlaps as the first recall completes. To avoid this in code, I check the DSN volume for MIGRAT* then issue my own HRECALL WAIT.

Rob

-----Original Message-----
From: Mosley, George <George...@ICBC.COM>

[Steve Beaver]

ARC1020I DFSMSHSM IS RECALLING FROM TAPE DSN=SCM.ADS.TEST.ISPCLIB, PLEASE
RETRY THE USER REQUEST AFTER THE RECALL HAS COMPLETED.

You need to is what LISTDSI does not support a WAIT

You might try HREACALL ' SCM.ADS.TEST.ISPCLIB' WAIT before the LISTDSI

Steve

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Mosley, George

Sent: Tuesday, June 23, 2015 1:39 PM
To: TSO-...@VM.MARIST.EDU
Subject: [TSO-REXX] LISTDSI

[Hamilton, Robert]

I know when I issue an HRECALL and then have to sit and wait. Sometimes impatience overcomes me, and I'll just try to browse the data set being recalled. I know it seems to add another HRECALL into the queue, but I don't care, as long.as I can see the data right away when it's available. Then, the first recall completes and I get to see the data, and the second recall will finish in a bit and I'll get the messages you got, ARC1001I SCM.ADS.TEST.ISPCLIB RECALL FAILED, RC=0002, REAS=0000, and ARC1102I DATA SET IS NOT MIGRATED/BACKED UP. It can be disconcerting since you KNOW it was migrated, but HSM likes to let me know when I blew it. So, yeah, it was migrated when LISTDSI went looking for it, but any other attempt to look at/for that data set will still cause another recall request.

Ok, I'm guessing on the secondary recall request, but this happens to me often enough that I have difficulty picturing it differently; there is a second request that must be failing because the first one succeeded.

R;


Rob Hamilton
Sr. System Engineer
Chemical Abstracts Service

Confidentiality Notice: This electronic message transmission, including any attachment(s), may contain confidential, proprietary, or privileged information from Chemical Abstracts Service ("CAS"), a division of the American Chemical Society ("ACS"). If you have received this transmission in error, be advised that any disclosure, copying, distribution, or use of the contents of this information is strictly prohibited. Please destroy all copies of the message and contact the sender immediately by either replying to this message or calling 614-447-3600.

[Mosley, George]

Thanks, all, for the (as usual) rapid response - I love this group.

1. Definitely not issuing the command twice - it's coded in a Rexx exec
2. Lizette - not sure about WAIT vs NOWAIT although I suspect NOWAIT
3. HRECALL works just fine from 3.4

The code is checking for SYSREASON = '9' because the LISTDSI was originally coded with NORECALL.

The disturbing thing is the SYSREASON code of '0021' which indicates "Catalog error trying to locate the dataset'. The dataset is definitely cataloged and is eventually restored.

George (#7327)

[Lizette Koehler]

So, if your HSM is setup for NOWAIT then you fly through your rexx code and might see something like you are experiencing. When it is WAIT, the rexx code has to wait until the recall completes and I think you code would work.

I can run a test and let you know.

The patches can be found typically in the PARMLIB member ARCCMDxx and if you look in the HSM STC you should see on the PARM statement which one that is and then the JCL will point to the PARMLIB dataset.

Lizette

-----Original Message-----
>From: "Mosley, George" <George...@ICBC.COM>

[Garrett, Robert]

Smile.... you made me curious so I decided to try some tests of my own. In the process, I think I may have tripped over your problem. If I'm right, it's not a LISTDSI problem, but a REXX coding problem.

You said your code was:

DSRC = LISTDSI('SCM.ADS.TEST.ISPCLIB' NODIRECTORY RECALL)

Try this:

DSRC = LISTDSI("'SCM.ADS.TEST.ISPCLIB'" NODIRECTORY RECALL)

Notice I added double quotes outside your single quotes around the dataset name. I think what may be going on is REXX sees those single quotes, and (rightfully according to language syntax) takes your dataset name as a literal and strips the single quotes off before passing the string SCM.ADS.TEST.ISPCLIB to the LISTDSI function. I don't know how your TSO profile and system are set up there, but here an unquoted DSN will be modified by prepending the user's ID to it. Adding the double quotes around the string ensures that REXX will pass the entire string with quotes to the LISTDSI function where it will be taken as a fully qualified DSN.

Robert Garrett
Director, Operating Systems Programming
IBM Certified System Programmer - CICS Transaction Server V5.2 for z/OS
IBM Certified Application Developer - CICS Transaction Server V5.2 for z/OS

Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live
Its whole life believing that it is stupid. -Albert Einstein

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Mosley, George
Sent: Tuesday, June 23, 2015 3:39 PM
To: TSO-...@VM.MARIST.EDU
Subject: [TSO-REXX] LISTDSI

[Lizette Koehler]

I have NOWAIT specified in HSM here. So when I issue the REXX for the LISTDSI (using the Double/Single Quote mentioned)

The LISTDSI did not wait for the recall and error-ed as expected.

x = LISTDSI("'BATCNTL.XMI'" NODIRECTORY RECALL)
16 *-* x = LISTDSI("'BATCNTL.XMI'" NODIRECTORY RECALL)
>L> "'BATCNTL.XMI'"
>L> "NODIRECTORY"
ARC0612I VOLUME MOUNT ISSUED FOR RECALL OR RECOVER OF LKOEH05.BATCNTL.XMI
ARC1000I LKOEH05.BATCNTL.XMI RECALL PROCESSING ENDED
>O> "'BATCNTL.XMI' NODIRECTORY"
>L> "RECALL"
>O> "'BATCNTL.XMI' NODIRECTORY RECALL"
ARC1020I DFSMSHSM IS RECALLING FROM TAPE DSN=BATCNTL.XMI, PLEASE RETRY THE USER REQUEST AFTER THE RECALL HAS COMPLETED.
>F> "16"
IRX0100I +++ Interactive trace. TRACE OFF to end debug, ENTER to continue. +++

Of course once the file was recalled, everything was good.

Lizette

[Lizette Koehler]

Try this next time, it should work.

Address TSO " HRECALL 'BLDRES.METADATA' WAIT "
x = LISTDSI("'BLDRES.METADATA'" NODIRECTORY)

[Paul Gilmartin]

On 2015-06-23 14:49, Robert Zenuk wrote:
> Any chance you are doing it twice? I have seen that when trying to recall a dataset when another recall for the same DSN is already in progress and the second request overlaps as the first recall completes. To avoid this in code, I check the DSN volume for MIGRAT* then issue my own HRECALL WAIT.
>

Of course, there's a timing window. Or do you serialize on SYSDSN EXC?

-- gil

[Steve Beaver]

Lizette

Your solution is probably the best unless someone does not want to wait

Steve

[Mosley, George]

Thanks, everyone.

(Sorry for the delay - I was off yesterday.)

Looks like the HRECALL solution will work best here. We use virtual tape so the RECALL is, in fact, very fast. In the case where the dataset isn't MIGRATEd, the redundant RECALL seems to add negligible overhead.

I see, now, my original misinterpretation. I was expecting RC=9 when the dataset was MIGRATEd. The Reason Code table in the Rexx manual (p. 137) actually says:
"DFHSM migrated the data set. NORECALL prevents retrieval"
I, of course, had RECALL specified.

Thanks, again, for all the suggestions.

George