Cant restore API-written object?

[kzw2zx]

I'm having an issue where a software we use writes a file to TSM using the Client API. The problem is that I am trying to restore some of the objects in a troubleshooting measure, and finding that they are impossible to restore.

If you look at attachment 01.jpg you can see my do a "q ar" to get the objects, but then I do a more-specific "q ar" and it pukes... saying I have invalid arguments, even though I used the same spec the first "q ar" provided.

Since the first "q ar {Attachments}\*\*" worked in getting me a file listing, I tried restoring that... and it puked... and even if I specify a file name. Ugh.

I've attached the select-statement info on one file to show as an example (02.jpg).

Can anyone tell me what i am doing wrong (if anything) or is this program at fault and somehow writing incorrectly to TSM?

Thank you so much - this has been hell troubleshooting!

Cheers,
Dustin

PS - Sorry, had to break 01.jpg into two parts...

 

[PJ]

As I understand the API, it gives you some basic functionality for how to register objects with the server and how to pipe your data in and out. But an application using that API will most certainly not deliver that data in a way the normal TSM Client can handle - so my guess would be: If your programmer forgot to deliver a working retrieve functionality, you're out of luck.

PJ

 

[kzw2zx]

As I understand the API, it gives you some basic functionality for how to register objects with the server and how to pipe your data in and out. But an application using that API will most certainly not deliver that data in a way the normal TSM Client can handle - so my guess would be: If your programmer forgot to deliver a working retrieve functionality, you're out of luck.

The retrieve through the software works, but doing via DSMC doesnt... and it's puzzling since it seems like it would accorind to the API guide (subsection attached). We'd like to this this for troubleshooting in the future... or at least find a hardened reason as to why it isnt working as described in IBM's book on the API. :\

-D

 

[PJ]

Interesting...

Whatever. I guess your problem is using restore rather than retrieve. You can see the objects as archive objects, so only a retrieve can get them.

I'd try a retrieve using the exact syntax that yielded proper results (first screenshot) and I'd include the -su=y and -pick options.

PJ

retrieve {Attachments}\*\* -pick

Or some such ....

 

[kzw2zx]

Whatever. I guess your problem is using restore rather than retrieve. You can see the objects as archive objects, so only a retrieve can get them.
I'd try a retrieve using the exact syntax that yielded proper results (first screenshot) and I'd include the -su=y and -pick options.

Yeah, I briefly forgot about retrieve... even still though it doesnt work with these items. :\ I'm certainly not trying to be difficult, just trying to figure out why this isnt working when it seems like it should.

Is this just the behavior of API-written items, or is there any way to 'validate' the way these were written? Or have I simply tried everything at this point and it's no use via DSMC, lol?

(see new attachments)

-D

 

[PJ]

I never encountered a condition where "q ar" would show the files and the exact same search would not work with a retrieve. I guess you already tried all permutations coming to mind? (uppercase, lowercase, without braces etc.)?

PJ

 

[BBB]

I'm probably barking up the wrong tree here, but does your API client connect with a different nodename to that of the normal client on the server you're doing this on?

Ie if you run "q sess" on your dsmc command line, are you getting "DOMOKUN-AM" as the node name?

 

[kzw2zx]

Both PJ and BBB have really good points, and yes... been tried.

* I am using the -node=DOMOKUN-AM switch with DSMC so that's good
* I've tried all caps, all lower-case, and even mixed... all have the same result (with and without brackets too)

Well, I feel better in one sense knowing that something is wrong and that what I've been trying *should* have worked...

Now I just need to figure out exactly why it's not working... and I dont think I personally have the experience for that.

Perhaps the programmer is using the API incorrectly and somehow gets the object there but it's not 'right'? The funny part about that is that the program that writes the file to TSM can also read it back. It's only DSMC that cant get it back. :\

I need some Advil...

 

[PJ]

One thing that bit me today. I tried to retrieve from an archive containing some "umlaut" characters and it just wouldn't work. By accident I stumbled across "ret {filespace_name}* -su=y -pick" with NO directory separator whatsoever involved - and it worked.

PJ

 

[kzw2zx]

ret {filespace_name}* -su=y -pick

That worked! Thanks PJ