| View previous topic :: View next topic | 
	
	
		| Author | Message | 
	
		| WallaceC Beginner
 
 
 Joined: 17 Dec 2002
 Posts: 22
 Topics: 10
 
 
 | 
			
				|  Posted: Wed Nov 22, 2006 10:07 am    Post subject: How to search string from GDGs? |   |  
				| 
 |  
				| Hi, 
 Could anyone tell me how to search a string from GDGs?
 
 Thanks,
 
 Wallace
 |  | 
	
		| Back to top |  | 
	
		|  | 
	
		| sriramla Beginner
 
 
 Joined: 22 Feb 2003
 Posts: 74
 Topics: 1
 
 
 | 
			
				|  Posted: Wed Nov 22, 2006 12:09 pm    Post subject: |   |  
				| 
 |  
				| In batch (ISRSUPC), use the GDG base as NEWDD. Search will happen on all generations automatically. 
 //SEARCH  EXEC PGM=ISRSUPC,
 //            PARM=(SRCHCMP,'ANYC')
 //NEWDD  DD DSN=<GDG base name>,DISP=SHR
 //OUTDD  DD SYSOUT=(A)
 //SYSIN  DD *
 SRCHFOR  'TEST STRING'
 /*
 |  | 
	
		| Back to top |  | 
	
		|  | 
	
		| WallaceC Beginner
 
 
 Joined: 17 Dec 2002
 Posts: 22
 Topics: 10
 
 
 | 
			
				|  Posted: Wed Nov 22, 2006 2:39 pm    Post subject: |   |  
				| 
 |  
				| Hi Sri Ramla, 
 I tried your suggestion, but the output only showed the line numbers of where the string is but not on which GDG. The output is as follows:
 
  	  | Code: |  	  | ISRSUPC   -   MVS/PDF FILE/LINE/WORD/BYTE/SFOR COMPARE UTILITY- ISPF FOR z/OS
 LINE-#  SOURCE SECTION                    SRCH DSN: INPUT.DATA.G0089V00
 
 75  1WHERE   GLOBL_R = 00011524
 116  1WHERE   GLOBL_R = 00011524
 156  1WHERE   GLOBL_R = 00011524
 
 ISRSUPC   -   MVS/PDF FILE/LINE/WORD/BYTE/SFOR COMPARE UTILITY- ISPF FOR z/OS
 SEARCH-FOR SUMMARY SECTION            SRCH DSN: INPUT.DATA.G0089V00
 
 LINES-FOUND  LINES-PROC  DATASET-W/LNS  DATASET-WO/LNS  COMPARE-COLS  LONGEST-LI
 3          494            1              0           1:80           80
 
 PROCESS OPTIONS USED: ANYC
 
 THE FOLLOWING PROCESS STATEMENTS (USING COLUMNS 1:72) WERE PROCESSED:
 SRCHFOR '11524'
 
 THE FOLLOWING "SRH" FILE CONCATENATED DATA SETS WERE SPECIFIED:
 (01) INPUT.DATA.G0098V00
 (02) INPUT.DATA.G0097V00
 (03) INPUT.DATA.G0096V00
 (04) INPUT.DATA.G0095V00
 (05) INPUT.DATA.G0094V00
 (06) INPUT.DATA.G0093V00
 (07) INPUT.DATA.G0092V00
 (08) INPUT.DATA.G0091V00
 (09) INPUT.DATA.G0090V00
 (10) INPUT.DATA.G0089V00
 
 | 
 |  | 
	
		| Back to top |  | 
	
		|  | 
	
		| shekar123 Advanced
 
 
 Joined: 22 Jul 2005
 Posts: 528
 Topics: 90
 Location: Bangalore India
 
 | 
			
				|  Posted: Wed Nov 22, 2006 2:40 pm    Post subject: |   |  
				| 
 |  
				| WallaceC, 
 You can also go to option 3.4 and give the GDG base and hit enter which might lead you to display of all generations related to the dataset and on the command prompt give the comand:
 
  	  | Code: |  	  | SRCHFOR 'string name'
 
 | 
 You will find the display
 
  	  | Code: |  	  | Strings Found against the GDG name wherever the string is found
 
 | 
 _________________
 Shekar
 Grow Technically
 |  | 
	
		| Back to top |  | 
	
		|  | 
	
		| WallaceC Beginner
 
 
 Joined: 17 Dec 2002
 Posts: 22
 Topics: 10
 
 
 | 
			
				|  Posted: Wed Nov 22, 2006 2:59 pm    Post subject: |   |  
				| 
 |  
				| Hi Shekar, 
 I tried that and it worked. Thank you.
 
 Wallace
 |  | 
	
		| Back to top |  | 
	
		|  | 
	
		| Bharath.AK Beginner
 
  
 Joined: 13 Jul 2007
 Posts: 34
 Topics: 10
 Location: Los Angeles
 
 | 
			
				|  Posted: Wed Jul 18, 2007 6:15 am    Post subject: |   |  
				| 
 |  
				| I believe, the '3.4' related option works o GDGs on Disk, but not on Tape. If so, any option for Tape GDGs too? _________________
 Regards,
 BK
 
 ***** " If You Have To Do It, You Might As Well Do It Right.....If It Is Worth Doing At All, It's Worth Doing It Right !!! " *****
 |  | 
	
		| Back to top |  | 
	
		|  | 
	
		| Nic Clouston Advanced
 
 
 Joined: 01 Feb 2007
 Posts: 1075
 Topics: 7
 Location: At Home
 
 | 
			
				|  Posted: Wed Jul 18, 2007 1:05 pm    Post subject: |   |  
				| 
 |  
				| looking at your superc srchfor output it is indicating that it found the strings in generation 89 
  	  | Code: |  	  | SRCH DSN: INPUT.DATA.G0089V00 | 
 _________________
 Utility and Program control cards are NOT, repeat NOT, JCL.
 |  | 
	
		| Back to top |  | 
	
		|  | 
	
		| kolusu Site Admin
 
  
 
 Joined: 26 Nov 2002
 Posts: 12394
 Topics: 75
 Location: San Jose
 
 | 
			
				|  Posted: Wed Jul 18, 2007 1:15 pm    Post subject: |   |  
				| 
 |  
				|  	  | Quote: |  	  | looking at your superc srchfor output it is indicating that it found the strings in generation 89
 
 | 
 Nic Clouston,
 
 Not True. SuperC  just shows the last concatenated DSN name in the listing. This dataset might not even contain the search String.
 
 Kolusu
 _________________
 Kolusu
 www.linkedin.com/in/kolusu
 |  | 
	
		| Back to top |  | 
	
		|  | 
	
		| dbzTHEdinosauer Supermod
 
 
 Joined: 20 Oct 2006
 Posts: 1411
 Topics: 26
 Location: germany
 
 | 
			
				|  Posted: Wed Jul 18, 2007 2:40 pm    Post subject: |   |  
				| 
 |  
				| Using a GDG base is not true concatenation - as far as SuperC is concerned - there is only one (1) DD statement for the DD Reference.  When the concatenation list contains individual DD statements for each file, SuperC will let you know what file it found the hit. _________________
 Dick Brenholtz
 American living in Varel, Germany
 |  | 
	
		| Back to top |  | 
	
		|  | 
	
		| kolusu Site Admin
 
  
 
 Joined: 26 Nov 2002
 Posts: 12394
 Topics: 75
 Location: San Jose
 
 | 
			
				|  Posted: Wed Jul 18, 2007 2:56 pm    Post subject: |   |  
				| 
 |  
				|  	  | Quote: |  	  | When the concatenation list contains individual DD statements for each file, SuperC will let you know what file it found the hit.
 
 | 
 
 No. Try concatening individual GDG names and it will still show the LAST DSN
 
 ex:
 
 
 
  	  | Code: |  	  | //SEARCH  EXEC PGM=ISRSUPC,
 //            PARM=(SRCHCMP,
 //            '')
 //NEWDD  DD DSN=GDG.G0005V00,
 //          DISP=SHR
 //       DD DSN=GDG.G0004V00,
 //          DISP=SHR
 //       DD DSN=GDG.G0003V00,
 //          DISP=SHR
 //       DD DSN=GDG.G0002V00,
 //          DISP=SHR
 //       DD DSN=GDG.G0001V00,
 //          DISP=SHR
 //OUTDD  DD SYSOUT=(*)
 //SYSIN  DD *
 SRCHFOR  'my search string'
 /*
 
 | 
 
 The output will contain the listing for GDG.G0001V00
 
 Kolusu
 _________________
 Kolusu
 www.linkedin.com/in/kolusu
 
 Last edited by kolusu on Thu Jul 19, 2007 6:59 am; edited 1 time in total
 |  | 
	
		| Back to top |  | 
	
		|  | 
	
		| dbzTHEdinosauer Supermod
 
 
 Joined: 20 Oct 2006
 Posts: 1411
 Topics: 26
 Location: germany
 
 | 
			
				|  Posted: Wed Jul 18, 2007 3:02 pm    Post subject: |   |  
				| 
 |  
				| ok, i understand! 
 any idea why gdg's are handled differently?  They do have descrete DSNs.
 _________________
 Dick Brenholtz
 American living in Varel, Germany
 |  | 
	
		| Back to top |  | 
	
		|  | 
	
		| dbzTHEdinosauer Supermod
 
 
 Joined: 20 Oct 2006
 Posts: 1411
 Topics: 26
 Location: germany
 
 | 
			
				|  Posted: Wed Jul 18, 2007 3:47 pm    Post subject: |   |  
				| 
 |  
				| After dutifully reading the documentation, DS selection is  'a' sequental dataset or PDS(s) with or without member selection. 
 I imagine a concatenated list of non-gdg's will provide the same result - nada!  Since it says 'a' sequential dataset, I fear that SuperC/E, SearchFor/E is sorta tailered for PDS's and as a result only recognizes a new member.
 
 If you think about it, the allocation is for all files in the concatenation.  To open a new member, ISPF needs to do something much different than opening a subsequent sequential dataset in the concatenation list.  And only during this process, will it recognize a 'new file name'.  (this is conjecture on my part.)
 
 By the way, will not work on a tape dataset - gdg or not.  (that is not conjecture, that is a direct paraphrase from the documentation)
 _________________
 Dick Brenholtz
 American living in Varel, Germany
 |  | 
	
		| Back to top |  | 
	
		|  | 
	
		|  | 
	
		|  |