Need to use CLIST to access GDG file and PDS member



IBM's Command List programming language & Restructured Extended Executor

Need to use CLIST to access GDG file and PDS member

Postby zeroboy » Sun Aug 15, 2010 10:08 am

Not good at Clist, but have a small task need to use Clist, need some help or hits:

I need to check names in a GDG file, for example, to check if name 'John' in the file abc.efg.names(0), if yes, then add 'john' to the member aaa.bbb.ccc(namelog).

when i use a flat file like 'AAA.BBB.CCC.NAMELOG' and 'ABC.DEF.GHI.NAMES' , it works ok, but when i chenge to GDG file and PDS member,errors happen. it can not find file abc.efg.names(0), and can not add to the member. If i change to SHR, it will clear the old records and write the new name to the member.

here is the code:
(this code extracted from a long program manually, may contain some other errors, but the most important thing i need help is how to read a GDG file and how to append records to a member file)


PROC 0 DSN1('AAA.BBB.CCC.NAMELOG')
ALLOCATE FILE(OFILE) DA('&DSN1') MOD
OPENFILE OFILE OUTPUT

SET EOF = OFF
SET RCODE = 0
SET CNAME = 'JOHN'
SET DNS2 = 'ABC.DEF.GHI.NAMES'

ALLOCATE FILE(NEXTNAME) DA(&DNS2) SHR
OPENFILE NEXTCARD INPUT

DO WHILE &EOF = OFF OR &RCODE ¬= 0
GETFILE NEXTNAME

IF &EOF=ON THEN DO
SET RCODE = 1
END

IF &STR(&SUBSTR(1:4,&NEXTNAME) = &CNAME THEN DO
CLOSFILE NEXTNAME
FREE F(NEXTNAME)
SET RCODE = 0
GOTO WRITELOG
END

END


WRITELOG: SET OFILE = &CNAME
PUTFILE OFILE
EXIT
zeroboy
 
Posts: 7
Joined: Sun Aug 15, 2010 9:27 am
Has thanked: 0 time
Been thanked: 0 time

Re: Need to use CLIST to access GDG file and PDS member

 

Re: Need to use CLIST to access GDG file and PDS member

Postby NicC » Sun Aug 15, 2010 10:41 am

You read a GDG in the same way as you read any other sequential file - there is nothing strange about it except the shortcut way to sepcify the DSN. You cannot use (0) (+1) etc do allocate files in CLIST - you have to sepcify the full name. You can do a LISTC LVL to get a list of the GDGs at that level and parse the output listing to get the filename you want which will automate your process somewhat.

To update a member in a PDS you may have to read/write the member and write your new line(s) at the end. I am not sure if DISP=MOD will work - you can try it on a play PDS.
The problem I have is that people can explain things quickly but I can only comprehend slowly.
Regards
Nic
NicC
Global moderator
 
Posts: 2690
Joined: Sun Jul 04, 2010 12:13 am
Location: Pushing up the daisys (almost)
Has thanked: 4 times
Been thanked: 105 times

Re: Need to use CLIST to access GDG file and PDS member

Postby steve-myers » Sun Aug 15, 2010 11:37 am

NicC is correct; you cannot extend a PDS member. DISP=MOD for a PDS data set is sort of a misnomer; when you write to a PDS data set you are generally extending the data set, but you can't extend an existing member.

An Assembler programmer can update a PDS member in place. I've never done it, but it can be done. This capability is not available in CLIST/Rexx, or for a higher level language.

In CLIST/Rexx, you can specify a member name in a data set name for dynamic allocation, but there is no direct way to access a PDS directory to get the members. You can SYSOUTTRAP a LISTDS data-set-name MEMBER command and get the member names from that. I've seen funky Rexx code that reads a PDS directory directly and parses the member names from that, but you're probably better off doing a SUSOUTTRAP for a LISTDS command. In addition, you can use the &SYSDSN(data-set(member)) function in CLIST/Rexx to test if a member is present in a data set.

NicC is also correct when he says relative GDG generations are not available in regular TSO dynamic allocation; his proposal to SYSOUTTRAP the output from a LISTCAT command and analyze that output is what you have to do. Oddly enough, very early in SPF you could specify a relative generation in an SPF data set name and it would take, but I'd bet this is no longer true.

There is a conceptual problem here, too. In JCL, a relative generation maps to the same true generation for the life of a job. This would present a problem in TSO since the "job" amounts to the entire TSO session, but from a user point of view the TSO session is divided into multiple groups that amount to a batch job, but there is no well defined job delimiter short of doing a LOGOFF command.
steve-myers
Global moderator
 
Posts: 1886
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 197 times


Return to CLIST & REXX

 


  • Related topics
    Replies
    Views
    Last post