Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

virtual table file name is not valid in search.

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CA Products
View previous topic :: :: View next topic  
Author Message
Ragav86

New User


Joined: 27 Jan 2010
Posts: 37
Location: chennai

PostPosted: Tue Feb 21, 2012 2:49 pm    Post subject: virtual table file name is not valid in search.
Reply with quote

Hi can any one let me know why i am getting the following error while reading the virtual table.
my requirement is to capture all the records from the file to table(records with '*' in first column need to be skipped) and need to perform a search..

Code:

 1 *****************                                             
 2 FILE CBNOTRES                                                 
 3 ARG 1 3 A                                                     
 4 DESC 5 76 A                                                   
 5 WS-DATA W 2 A                                                 
 6 WS-DATA1 WS-DATA    1 A                                       
 7 WS-DATA2 WS-DATA +1 1 A                                       
 8 WS-IN1  W 3 A                                                 
 9 WS-IN2  W 2 A                                                 
10 WS-DESC W 76 A                                               
11 FILE CBNOT TABLE 2000 VIRTUAL F(80)                           
12 COPY CBNOTRES                                                 
13 SORT CBNOTRES TO CBNOT USING(ARG)  BEFORE SCREENER1           
14 SCREENER1. PROC                                               
16 MOVE ARG TO WS-DATA                                           
17 DISPLAY WS-DATA '**' ARG '**' DESC                           
18 IF WS-DATA1 NE '*'                                           
19    SELECT                                                     
20 END-IF                                                       
21 END-PROC                                                     
22 JOB INPUT(NULL).                                             
23 DISPLAY 'INPUT '                                             
24 MOVE 'A04' TO WS-IN1                                         
25 SEARCH CBNOT WITH WS-IN1 GIVING WS-DESC                       
25 *******B054 NOT A VALID FILE - CBNOT                         
26 DISPLAY WS-DESC                                               
27 STOP                                                         
Back to top
View user's profile Send private message

PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2422
Location: Netherlands, Amstelveen

PostPosted: Tue Feb 21, 2012 3:02 pm    Post subject:
Reply with quote

Try FILE CBNOT TABLE 2000 VIRTUAL F(80) RETAIN
Back to top
View user's profile Send private message
Ragav86

New User


Joined: 27 Jan 2010
Posts: 37
Location: chennai

PostPosted: Tue Feb 21, 2012 3:20 pm    Post subject: Reply to: virtual table file name is not valid in search.
Reply with quote

no still i am getting the same error..
Back to top
View user's profile Send private message
Ragav86

New User


Joined: 27 Jan 2010
Posts: 37
Location: chennai

PostPosted: Tue Feb 21, 2012 3:35 pm    Post subject: Reply to: virtual table file name is not valid in search.
Reply with quote

virtual table is possible in Eazytrieve?
is there any other way?
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Tue Feb 21, 2012 5:12 pm    Post subject: Reply to: virtual table file name is not valid in search.
Reply with quote

Do the VIRTUAL first, TABLE after. Forget RETAIN unless you are using reading the table/file in more than one JOB/SORT.
Back to top
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2422
Location: Netherlands, Amstelveen

PostPosted: Tue Feb 21, 2012 5:17 pm    Post subject:
Reply with quote

Bill, sequence of the parameters is of no importance. Retain is necessary cause the TS is doing a sort first, and using the table in the next EZT job.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Tue Feb 21, 2012 5:30 pm    Post subject: Reply to: virtual table file name is not valid in search.
Reply with quote

Hi Peter,

I always coded in that order, never had a problem :-)


The RETAIN is only relevant for reading a file. If it is the output of a SORT, not a probllem, which is logical, there'd be no sense in creating the file to be not able to read it.

I'm just looking at the code. Isn't that weird? ARG and DESC are on a different file, the input to the SORT, and are used for selection. The TABLE doesn't have ARG or DESC. Methinks that'll be the problem.

EDIT: Just noticed the Copy. No idea if this will do what you think it will do. ARG and DESC on a TABLE are sort of special things. It seems you have definied them elsewhere just to be able to include them with the copy? Try not doing that.
Back to top
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2422
Location: Netherlands, Amstelveen

PostPosted: Tue Feb 21, 2012 5:35 pm    Post subject:
Reply with quote

Hey Bill, the table has a copy statement pointing to the unsorted table.
I never had problems with table parameters in any sequence.
But for tables targetted by sort i always used FB(x y).
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Tue Feb 21, 2012 5:49 pm    Post subject: Reply to: virtual table file name is not valid in search.
Reply with quote

Hi Peter,

I certainly have never tried to COPY a file for a table (or anything, for that matter, always used macros).

I'm accepting that if you say the order is unimportant, it is unimportant. The RETAIN is unimportant. Without specifiying a length for the output, the SORT willl take it from the input.

I can't see anything "genuinely" wrong (although I'm being in and out very quickly today), so for me I'd concentrate on the ARG/DESC thing. Something doesn't work :-)

I'm assuming from TS's comment they tried the RETAIN anyway. Perhaps they didn't, but I do think that that is not the problem. It is an odd one.
Back to top
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2422
Location: Netherlands, Amstelveen

PostPosted: Tue Feb 21, 2012 6:21 pm    Post subject:
Reply with quote

Try this :

Code:

FILE CBNOTRES
INARG  1  3 A
INDESC 5 76 A
*
WS-DATA W 2 A
WS-DATA1 WS-DATA 1 A
WS-DATA2 WS-DATA +1 1 A
*
WS-IN1 W 3 A
WS-IN2 W 2 A
WS-DESC W 76 A
*
FILE CBNOT FB(80 6160) VIRTUAL RETAIN TABLE 2000
ARG  1  3 A
DESC 5 76 A
*
SORT CBNOTRES TO CBNOT USING(INARG) BEFORE SCREENER1
SCREENER1. PROC
   MOVE INARG TO WS-DATA
   DISPLAY WS-DATA '**' INARG '**' DESC
   IF WS-DATA1 NE '*'
      SELECT
   END-IF
END-PROC
*
JOB INPUT(NULL)
DISPLAY 'INPUT '
MOVE 'A04' TO WS-IN1
SEARCH CBNOT WITH WS-IN1 GIVING WS-DESC
DISPLAY WS-DESC
STOP
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Tue Feb 21, 2012 7:20 pm    Post subject: Reply to: virtual table file name is not valid in search.
Reply with quote

I'd be surprised as all heck if that didn't work out of the box, Peter.

Ragav86,

If you want to humour me, once you have Peter's code in place, can you then try

Code:
FILE CBNOT VIRTUAL TABLE


And let us know. Unless you want to limit the table to 2000, Easytrieve will use the exact record count from the SORT for the table size. As far as I know the Virtual File Manager will do its own "blocking" anyway. I could be wrong, as I've not used Easytrieve on z/OS.

You seem to have made a creditable attempt to ensure that ARG and DESC are the same from input to output. But. If it doesn't work, it doesn't work.

You can now use redefinitions on the file for your test in the sort procedure, no need to do a move to the W field.

I always used assignements, not MOVE, for fields (except where "obvious"). Makes it less like Cobol and doesn't bite you when the fields are not the same.

If I were you, I'd bounce it to CA as well, If whatever caused the problem didn't get an error in the "right" place, they might like to think about fixing it.
Back to top
View user's profile Send private message
Ragav86

New User


Joined: 27 Jan 2010
Posts: 37
Location: chennai

PostPosted: Tue Feb 21, 2012 8:07 pm    Post subject: Reply to: virtual table file name is not valid in search.
Reply with quote

Hi peter & Bill
Thanks for your reply. both codes are working fine..
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Tue Feb 21, 2012 8:32 pm    Post subject: Reply to: virtual table file name is not valid in search.
Reply with quote

Thanks for letting us know.

If you want to try a little "problem determination" before contacting CA, you could try your original but without the COPY for the TABLE file, just define the ARG and DESC.

If that fails as well, it is because confusion has been caused (to the compiler) by ARG and DESC on a non-TABLE file.

If it works, then the problem is with the COPY either in itself, or with non-TABLE to TABLE. So try with two TABLEs (create another TABLE file with another SORT of your original input, and try the COPY on that).

Then you will have something concrete for CA. Let us know if you can narrow it down please, it may assist future readers.
Back to top
View user's profile Send private message
Ragav86

New User


Joined: 27 Jan 2010
Posts: 37
Location: chennai

PostPosted: Tue Feb 21, 2012 9:00 pm    Post subject: Reply to: virtual table file name is not valid in search.
Reply with quote

sure bill i will let you know soon...
Back to top
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2422
Location: Netherlands, Amstelveen

PostPosted: Tue Feb 21, 2012 11:04 pm    Post subject: Re: Reply to: virtual table file name is not valid in search
Reply with quote

Ragav86 wrote:
Hi peter & Bill
Thanks for your reply. both codes are working fine..


Which codes? I have a feeling im f..d real bad. Now i would like to see the codes with all the EZT output.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Tue Feb 21, 2012 11:23 pm    Post subject: Reply to: virtual table file name is not valid in search.
Reply with quote

Why, Peter? It is your code, working as we expected it would. Plus your code with my suggestion for the file definition for the TABLE.

I've learned something today, so thankyou for that.

For the next topic with a FILE I'll know not to query the order. I used macros for file definitions, so coded in the macro in the order of the manual. Even though I could have then invoked the macro with the parameters in a different order, I never did. I like them all to look the same. Never realised the order I'd put them in the macro was irrelevant :-) Thanks.
Back to top
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2422
Location: Netherlands, Amstelveen

PostPosted: Tue Feb 21, 2012 11:39 pm    Post subject:
Reply with quote

Bill, I have the feeling that the TS fooled both of us. Probably he didnt show the real stuff. Well, whatever it was nice talking to you. Take care.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Wed Feb 22, 2012 3:35 am    Post subject: Reply to: virtual table file name is not valid in search.
Reply with quote

Peter, igualmente. I'm hoping that what TS showed us was a cut-down version of an actual program. I think there is something of the "language barrier" problem, and that TS is a person of few words. I certainly hope we've not been fooled.

Ragav86, I just noticed you don't test that the search was successful. You'll need to do that, else you'll just get whatever value was last lying around from the previous successful search, if any, as the DESC is only move if the search was successful.

IF CBNOT
it was found in the table
ELSE
it was not
END-IF
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CA Products All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Add PD field from 2nd file to PD in 1st Sushant Garje DFSORT/ICETOOL 6 Thu Dec 01, 2016 4:32 pm
No new posts File Aid to File Manager conversion murali3955 IBM Tools 4 Thu Nov 24, 2016 3:41 pm
No new posts How to convert the VBM file to VB or... Sulabh Agrawal JCL & VSAM 4 Fri Nov 18, 2016 1:04 pm
No new posts CICS Roll back partially - Need to re... dwijadas CICS 4 Wed Nov 16, 2016 4:30 pm
No new posts Problem in writing Output file vickey_dw COBOL Programming 5 Mon Nov 14, 2016 11:14 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us