SDSF Rexx Issue - to copy SYSOUT into PDS

[saurabh khandelwal]

Hello,
I am trying to run SDSF rexx to copy SYSOUT into PDS present in
Implementing REXX Support in SDSF manual. I am able to create members(
members name starting with Job id)

in the PDS. But the data is not getting populated in these members
from Job outputs. The issue which I issue is

328 *-* address LINKMVS "IEBGENER Parm DDlist"
>L> "IEBGENER Parm DDlist"
+++ RC(12) +++

I am not able to resolve this issue. I am using below inputs
in Rexx and JCL to run this program. From the Job I am supplying only these
three parameter.

JOB(*) PDS(TEST12.SDSF.OUT) DDNAME(JESMSGLG)

And in Rexx below are my inputs

JobPattern = "JOB*"
OwnerPattern = "TEST12"
JobClass = ""
Destination = ""
CondCode = ""
DdName = ""
PdsDsn = ""
Error = "NO"
MemberRule = "JOBID"

--
Thanks & Regards
Saurabh

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN

[Leonardo Vaz]

You are executing IEBGENER with parm "Parm DDlist", pretty much like in a JCL with the following card:
// EXEC PGM=IEBGENER,PARM="Parm DDlist"

And IEBGENER is giving you a RC=12, because that's not valid.

Leonardo Vaz

[Rouse, Willie]

In SG247419 page 94 Implementation Rexx support in SDSF it say PARM="" or null.


Respectfully,
Willie C. Rouse
Senior Mainframe Consultant
Prince George's County, Maryland
Office of Information Technology
9201 Basil Court/ Room B8
Largo, MD 20774
Voice: 301-883-7189
Fax: 301-883-3790

This E-mail and any of its attachments may contain Prince George’s

County Government or Prince George's County 7th Judicial Circuit

Court proprietary information or Protected Health Information,

which is privileged and confidential. This E-mail is intended

solely for the use of the individual or entity to which it is

addressed. If you are not the intended recipient of this E-mail,

you are hereby notified that any dissemination, distribution,

copying, or action taken in relation to the contents of and

attachments to this E-mail is strictly prohibited by federal law

and may expose you to civil and/or criminal penalties. If you have

received this E-mail in error, please notify the sender immediately

and permanently delete the original and any copy of this E-mail and

any printout.

[Walt Farrell]

On Wed, 27 Feb 2013 17:49:37 +0000, Leonardo Vaz <Leonar...@CN.CA> wrote:

>You are executing IEBGENER with parm "Parm DDlist", pretty much like in a JCL with the following card:
>// EXEC PGM=IEBGENER,PARM="Parm DDlist"
>
>And IEBGENER is giving you a RC=12, because that's not valid.
>

No, he's not. LINKMVS interprets the quoted string, using the first word as the program name, and the next as the name of a variable that will be parameter 1, the next as the name of a variable that will be parameter 2, etc. It's not like JCL.

See TSO/E REXX Reference, at
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4a3a0/2.5.9.2?SHELF=all13be9&DT=20110621111559&CASE= or http://preview.tinyurl.com/bp43u5d to see a picture of how it works.

It is possible, though, that the 1st parameter (like the PARM= on JCL), or the DDList, contain an error. We would need to know what was in those REXX variables.

--
Walt

[Paul Gilmartin]

On Wed, 27 Feb 2013 17:49:37 +0000, Leonardo Vaz wrote:

>You are executing IEBGENER with parm "Parm DDlist", pretty much like in a JCL with the following card:
>// EXEC PGM=IEBGENER,PARM="Parm DDlist"
>

Actually not entirely like. This calls IEBGENER with R1 pointing to a
list of 2 fullwords. The first points to a halfword length followed by
the content of the Rexx variable PARM; the second has its sign bit
set and points to a halfword length followed by the content of Rexx
variable DDLIST.

>And IEBGENER is giving you a RC=12, because that's not valid.
>

Yes. But it might be valid if PARM contains a valid PARM for IEBGENER
amd DDLIST contains a valid alternate DdName list for IBM utilities,
as in:
Title: z/OS V1R13.0 TSO/E REXX Reference
Document Number: SA22-7790-10
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4a3a0/2.5.9.2

2.5.9.2 The LINKMVS and ATTCHMVS host command environments
...
address 'LINKMVS' prog 'PARM DDLIST'

... from which it appears to have been adapted. I do exactly this
when I need to. It works.

>-----Original Message-----
>From: IBM Mainframe Discussion List On Behalf Of saurabh khandelwal
>
> 328 *-* address LINKMVS "IEBGENER Parm DDlist"
> >L> "IEBGENER Parm DDlist"
> +++ RC(12) +++

[Steve Thompson]

From: Paul Gilmartin <PaulGB...@AIM.COM>
Date: 02/27/2013 06:44 PM

On Wed, 27 Feb 2013 17:49:37 +0000, Leonardo Vaz wrote:

>You are executing IEBGENER with parm "Parm DDlist", pretty much like in a
JCL with the following card:
>// EXEC PGM=IEBGENER,PARM="Parm DDlist"
>

<SNIPPAGE>

Yes. But it might be valid if PARM contains a valid PARM for IEBGENER
amd DDLIST contains a valid alternate DdName list for IBM utilities,
as in:
Title: z/OS V1R13.0 TSO/E REXX Reference
Document Number: SA22-7790-10

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4a3a0/2.5.9.2


2.5.9.2 The LINKMVS and ATTCHMVS host command environments
...
address 'LINKMVS' prog 'PARM DDLIST'

... from which it appears to have been adapted. I do exactly this
when I need to. It works.

<SNIP>

Glad it worked for you. I tried it with IEBCOPY and couldn't make it work
at all (yes, I compared the example in the REXX book to the info in the
"DFSMSdfp Utilities" discussing this for IEBCOPY).

So I fixed my REXX code to only use SYSUT1-4 for IEBCOPY and where I had
been using SYSUT1/2 to something else.

I got tired of chasing S0C4 and other interesting ABENDs and RCs from
IEBCOPY.

Later,
Steve Thompson

[Scott Ford]

You might to review this Share presentation

https://share.confex.com/share/117/webprogram/Handout/Session9656/REXX%20Language%20Coding%20Techniques.pdf

Scott ford
www.identityforge.com

Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb

[saurabh khandelwal]

Thanks All,
I have used the code provided my IBM in SDSF with REXX
manual. Looks like the code is not properly setup and require many
modification to make it work.

If anybody has used that code before, please share your
experience.

Regards
Saurabh

> > This E-mail and any of its attachments may contain Prince George�s

> > County Government or Prince George's County 7th Judicial Circuit
> > Court proprietary information or Protected Health Information,
> > which is privileged and confidential. This E-mail is intended
> > solely for the use of the individual or entity to which it is
> > addressed. If you are not the intended recipient of this E-mail,
> > you are hereby notified that any dissemination, distribution,
> > copying, or action taken in relation to the contents of and
> > attachments to this E-mail is strictly prohibited by federal law
> > and may expose you to civil and/or criminal penalties. If you have
> > received this E-mail in error, please notify the sender immediately
> > and permanently delete the original and any copy of this E-mail and
> > any printout.
> >
> > ----------------------------------------------------------------------
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
Thanks & Regards
Saurabh Khandelwal

[Miklos Szigetvari]

Hi

Without SYSPRINT or alternate you can easily get rc 12

Kind regards, / Mit freundlichen Gr��en
Miklos Szigetvari

Research& Development
ISIS Papyrus Europe AG
Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria
T: +43(2236) 27551 333, F: +43(2236)21081
E-mail: miklos.s...@isis-papyrus.com
Info: in...@isis-papyrus.com Hotline: +43-2236-27551-111
Visit our brand new extended Website at www.isis-papyrus.com
---------------------------------------------------------------
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS Papyrus accepts
no responsibility for malicious or inappropriate content.
---------------------------------------------------------------

[Shane Ginnane]

On Thu, 28 Feb 2013 09:19:33 +0530, saurabh khandelwal wrote:

>Thanks All,
> I have used the code provided my IBM in SDSF with REXX
>manual. Looks like the code is not properly setup and require many
>modification to make it work.
>
> If anybody has used that code before, please share your
>experience.

I had to help an apps team to save JES2 output to a PDS a couple of days back. A quick hack of the REXX with SDSF examples in the SDSF Customisation worked fine. And I mean a *quick* hack - 10 minutes.
Have a look at the "Print to SYSOUT" - it uses "XSC", but just use "XDC" and adjust the variables to suit. Trivial - no need to muck with calling utilities.

Shane ...

[Stocker, Herman]

You may want to take a look at Mark's SDSF@DR program. It sounds like what the OP wanted to do.

Mark's page:
http://www.mzelden.com/mvsutil.html


Regards,
Herman Stocker

It is impossible to make anything foolproof, because fools are so ingenious.
-- Robert Heinlein

The sender believes that this E-mail and any attachments were free of any
virus, worm, Trojan horse, and/or malicious code when sent. This message and
its attachments could have been infected during transmission. By reading the
message and opening any attachments, the recipient accepts full
responsibility for taking protective and remedial action about viruses and
other defects. The sender's employer is not liable for any loss or damage
arising in any way from this message or its attachments.

---

[Walt Farrell]

On Wed, 27 Feb 2013 19:07:47 -0600, Steve Thompson <stho...@US.IBM.COM> wrote:

>
>Glad it worked for you. I tried it with IEBCOPY and couldn't make it work
>at all (yes, I compared the example in the REXX book to the info in the
>"DFSMSdfp Utilities" discussing this for IEBCOPY).
>
>So I fixed my REXX code to only use SYSUT1-4 for IEBCOPY and where I had
>been using SYSUT1/2 to something else.
>
>I got tired of chasing S0C4 and other interesting ABENDs and RCs from
>IEBCOPY.

I hope you were trying that on z/OS V1.13, and not an earlier release where IEBCOPY may requires APF authorization, Steve. Generally when REXX invokes programs they won't run with APF authorization, and that can lead to many strange problems.

--
Walt

[Steve Thompson]

From: Walt Farrell <walt.f...@GMAIL.COM>
Date: 02/28/2013 08:05 AM

On Wed, 27 Feb 2013 19:07:47 -0600, Steve Thompson <stho...@US.IBM.COM>
wrote:

>
>Glad it worked for you. I tried it with IEBCOPY and couldn't make it work
>at all (yes, I compared the example in the REXX book to the info in the
>"DFSMSdfp Utilities" discussing this for IEBCOPY).
>
>So I fixed my REXX code to only use SYSUT1-4 for IEBCOPY and where I had
>been using SYSUT1/2 to something else.
>
>I got tired of chasing S0C4 and other interesting ABENDs and RCs from
>IEBCOPY.

I hope you were trying that on z/OS V1.13, and not an earlier release
where IEBCOPY may requires APF authorization, Steve. Generally when REXX
invokes programs they won't run with APF authorization, and that can lead
to many strange problems.

<SNIPPAGE>

Actually, I was running on z/OS V1R12, and it works just fine when it owns
SYSUT1-4. But it kept having problems with the DDLIST being passed to it.
And it complained about the command being passed. Now it puts out a
message that it see that it has been invoked by a TSO Command (so it has
set up for the CPPL ? -- Sorry I don't have a current SYSOUT where it got
invoked for COMPRESS). And like I said, it works find as long as I don't
try to pass the DDLIST.

And I am aware of the APF issue (and why it must be so), so that was what
I was waiting for -- if I hit the S047 ABEND, I knew I had a show stopper.
The method of invocation that I used works fine:

>> ADDRESS 'TSO' pgm 'COMPRESS' /* Invoke IEBCOPY and tell it to compress
*/ <<

Regards,
Steve Thompson

[Paul Gilmartin]

On Thu, 28 Feb 2013 11:14:29 -0600, Steve Thompson wrote:
>
>And I am aware of the APF issue (and why it must be so), so that was what
>I was waiting for -- if I hit the S047 ABEND, I knew I had a show stopper.
>The method of invocation that I used works fine:
>

It needn't be so. As evidenced by 1.13, where it is no longer so.

>>> ADDRESS 'TSO' pgm 'COMPRESS' /* Invoke IEBCOPY and tell it to compress */
>

But that leaves no way to pass a DDLIST. And the example I posted
shows that alternate DDNAMEs work. For me. On 1.13.

It's possible that while alternate DDNAMEs override SYSUT1 and SYSUT2
in generated commands (in fact they're shown as those commands are
logged in SYSPRINT), DDNAMEs coded in SYSIN are taken as-is; no
substitution. I've neither examined the documentation minutely nor
performed an experiment. Whatever the case, it should be documented;
worth an RCF if not.

-- gil

[saurabh khandelwal]

Hello Walt,
I am running this program under z/OS 1.13 system only.

Regards
Saurabh

--
Thanks & Regards
Saurabh Khandelwal

[saurabh khandelwal]

Hello Herman,
I have check this Mark's utility earlier, but this
doesn't suit to my requirement because my target is to put Job's output in
a single PDS with different members( name can be Job id or Job name). This
will be useful for us, while we are installing any product or performing
set of similar task.

But if I use, PS file, then for every job I will have one dedicated dataset
and it will be painful if I have 100+ jobs.

Regards
Saurabh

--
Thanks & Regards
Saurabh Khandelwal

[Anthony Thompson]

I can only echo Shane's reply. I don't know why you are messing around with external utilities when SDSF Rexx provides you with the function you are after. Why re-invent the wheel?

Below is a snippet of Rexx invoking SDSF functions to write held sysout to a PDS:

/******************************************/
/* Turn on SDSF functions, set desired */
/* job list via PREFIX command, specify */
/* print output dataset (for XDC action */
/* character and invoke H (held output) */
/* panel. */
/******************************************/
blah = ISFCALLS('ON')

ISFPREFIX = "ANT*"
ISFOWNER = "ANT"
ISFPRTDSNAME = "ANT.TEMP.SDSFPDS"
ISFPRTDISP = "NEW"
ISFPRTSPACETYPE = "CYLS"
ISFPRTPRIMARY = 5
ISFPRTSECONDARY = 1
ISFPRTBLKSIZE = 27920
ISFPRTDIRBLKS = 10

ADDRESS SDSF "ISFEXEC H"
last_RC = rc
CALL Check_RC

/******************************************/
/* Loop through displayed jobs, writing */
/* each to a PDS member. */
/******************************************/
total_rows = ISFROWS
first_mbr = "Y"

IF total_rows = 0 THEN
DO
SAY 'No jobs found with prefix 'ISFPREFIX', owner 'ISFOWNER'.'
SAY 'Dataset 'ISFPRTDSNAME' not created, no jobs to output.'
END
ELSE
DO i = 1 TO total_rows
ISFPRTMEMBER = JNAME.i
ADDRESS SDSF "ISFACT H TOKEN('"TOKEN.i"') PARM(NP XDC)"
last_RC =rc
CALL Check_RC
IF first_mbr = "Y" THEN
DO
first_mbr = "N"
ISFPRTDISP = "SHR"
END
END

Of course, non-unique job-names would mean any member would contain the last job with that job-name written to the PDS. I'd suggest writing to a pre-allocated z/UNIX file (ISFPRTDDNAME) where file-names could be a concatenation of job-name and job-number, and use the XFC command instead of XDC. See snippet below:

/******************************************/
/* Turn on SDSF functions, set desired */
/* job list via PREFIX command, specify */
/* print DDNAME (for XFC action char */
/* and invoke H (held output) panel. */
/******************************************/
blah = ISFCALLS('ON')

ISFPREFIX = "ANT*"
ISFOWNER = "ANT"
ISFPRTDDNAME = "ANTSDSF"

ADDRESS SDSF "ISFEXEC H"
last_RC =rc
CALL Check_SDSF_RC

/******************************************/
/* Loop through displayed jobs, writing */
/* each to a z/UNIX file. */
/******************************************/
total_rows = ISFROWS
unix_dir = "/u/ant/"
ADDRESS TSO "FREE F("ISFPRTDDNAME")"

IF total_rows = 0 THEN
DO
SAY 'No jobs found with prefix 'ISFPREFIX', owner 'ISFOWNER'.'
SAY 'No files created in directory 'unix_dir'.'
END
ELSE
DO i = 1 TO total_rows
file_name = unix_dir||JNAME.i||"_"||JNUM.i
ADDRESS TSO "ALLOC F("ISFPRTDDNAME") PATH('"file_name"') ",
"PATHDISP(KEEP,KEEP) PATHOPTS(OWRONLY,OCREAT) ",
"PATHMODE(SIRWXU)"
Last_RC = rc
CALL CHECK_TSO_RC
IF Last_RC <> 0 THEN
LEAVE
ADDRESS SDSF "ISFACT H TOKEN('"TOKEN.i"') PARM(NP XFC)"
last_RC =rc
CALL Check_SDSF_RC
ADDRESS TSO "FREE F("ISFPRTDDNAME")"
END


Ant.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of saurabh khandelwal
Sent: Friday, 1 March 2013 1:05 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: SDSF Rexx Issue - to copy SYSOUT into PDS

[Walt Farrell]

On Fri, 1 Mar 2013 08:59:58 +0530, saurabh khandelwal <sourabhkha...@GMAIL.COM> wrote:

>Hello Walt,
> I am running this program under z/OS 1.13 system only.

My concern doesn't affect you; the reply was specific to Steve, who is testing with IEBCOPY.

Your problem should simply be that you don't have the parm or the alternate-ddname list variable setup correctly, but you've never shown us what they contain, as far as I know.

--
Walt

[Paul Gilmartin]

On Fri, 1 Mar 2013 15:59:40 +0930, Anthony Thompson wrote:

>I can only echo Shane's reply. I don't know why you are messing around with external utilities when SDSF Rexx provides you with the function you are after. Why re-invent the wheel?

> ...

>Of course, non-unique job-names would mean any member would contain the last job with that job-name written to the PDS. I'd suggest writing to a pre-allocated z/UNIX file (ISFPRTDDNAME) where file-names could be a concatenation of job-name and job-number, and use the XFC command instead of XDC. See snippet below:
>

I had been unaware of this. Thanks.

>ISFPRTDDNAME = "ANTSDSF"
>
Can I let SVC 99 choose a DDNAME via BPXWDYN( '...rtddn(ISFPRTDDNAME)...')
I assume so.

>ADDRESS TSO "FREE F("ISFPRTDDNAME")"
>

Unnecessary if generated DDN,

> file_name = unix_dir||JNAME.i||"_"||JNUM.i
>

When I "reinvent[ed] the wheel", I chose to put each job step
in a separate directory. Will SDSF respect something such as:

file_name = unix_dir||JNAME.i'/'JNUM.i

> ADDRESS TSO "ALLOC F("ISFPRTDDNAME") PATH('"file_name"') ",
> "PATHDISP(KEEP,KEEP) PATHOPTS(OWRONLY,OCREAT) ",
> "PATHMODE(SIRWXU)"
>

"filedata(BINARY)" is the default. This can be pretty unreadable.
Will SDSF respect a setting of "filedata(TEXT)" instead? (You might
be inclined to say "Of course!", but Binder, for example, overrides
"filedata(TEXT)" to BINARY on SYSLIN. RCF submitted.)

Thanks,
gil

[Paul Gilmartin]

On Fri, 1 Mar 2013 09:04:46 +0530, saurabh khandelwal wrote:
>
>But if I use, PS file, then for every job I will have one dedicated dataset
>and it will be painful if I have 100+ jobs.
>

Again, I'll recommend UNIX directories. They allow keeping things
much better organized -- even a subdirectory for each step within
each job.

>On Thu, Feb 28, 2013 at 6:18 PM, Stocker, Herman wrote:
>
>> You may want to take a look at Mark's SDSF@DR program. It sounds like
>> what the OP wanted to do.
>>

I had been unaware of this. Thanks, Herman.

>> Mark's page:
>> http://www.mzelden.com/mvsutil.html
>>

Thanks, Mark.

-- gil

[Farley, Peter x23353]

Mark's SDSF@DR program is a start, but it also allocates a separate sequential file for each job, albeit with good information about each job encoded in the DSN.

However, his program could easily be modified to create members in a PDS by using ISFPRTDISP='OLD' and ISFPRTDSN='desired.pds.dsname' (or perhaps better to avoid running out of room in the PDS, ISFPRTDSN='desired.PDSE.dsname') and ISFPRTMEMBER=jname.i instead of the technique it now uses. Then all of the other ISFPRTxxxx variables can be set to null strings as they are ignored when ISFPRTDISP='OLD'.

If you have the free version of PDS86 from CBT or one of the commercial equivalents you could also set the ISPF statistics of the member you add to record when it was added to the PDS(E) and by whom, but that is optional.

I also noticed that Mark's program presumes that you need the ISFPRTVOLSER and ISFPRTUNIT fields for ISFPRTDISP='NEW' output. Even for a sequential file, for purely SMS shops like my own you would instead want to specify all of the "class" variables and leave the volser and unit parameters null, like this:

ISFPRTSTORCLAS=storclas
ISFPRTMGMTCLAS='MCLARGE'
ISFPRTDATACLAS='DCLARGE'
ISFPRTUNIT=''
ISFPRTVOLSER=''

Where MCLARGE and DCLARGE are suitable defaults for your own SMS environment.

YMMV of course. HTH.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Friday, March 01, 2013 10:00 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: SDSF Rexx Issue - to copy SYSOUT into PDS

On Fri, 1 Mar 2013 09:04:46 +0530, saurabh khandelwal wrote:
>
>But if I use, PS file, then for every job I will have one dedicated dataset
>and it will be painful if I have 100+ jobs.
>
Again, I'll recommend UNIX directories. They allow keeping things
much better organized -- even a subdirectory for each step within
each job.


>On Thu, Feb 28, 2013 at 6:18 PM, Stocker, Herman wrote:
>
>> You may want to take a look at Mark's SDSF@DR program. It sounds like
>> what the OP wanted to do.
>>
I had been unaware of this. Thanks, Herman.

>> Mark's page:
>> http://www.mzelden.com/mvsutil.html
>>
Thanks, Mark.
--

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

[Paul Gilmartin]

On Fri, 1 Mar 2013 15:59:40 +0930, Anthony Thompson wrote:

>I can only echo Shane's reply. I don't know why you are messing around with external utilities when SDSF Rexx provides you with the function you are after. Why re-invent the wheel?
>

I reinvented the wheel because I looked at:

13.14.8 Browse a single data set

... the only topic mentioning "a single data set", where I saw:

Say "Now reading" isfdsname.kx
"EXECIO * DISKR" isfddname.kx "(STEM line. FINIS"
Say " Lines read:" line.0
do lx = 1 to line.0
Say " line."lx "is:" line.lx
end

... and believing that was the paradigm, replaced the "EXECIO; say"
code with "address ATTCHMVS IEBGENER blank AltDD"

-- gil

[Ted MacNEIL]

>If you have the free version of PDS86 from CBT or one of the commercial equivalents you could also set the ISPF statistics of the member you add to record when it was added to the PDS(E) and by whom, but that is optional.

You could also use the ISPF LM* routines (Library Management) to change/add stats.
No need to invest in another product.
-
Ted MacNEIL
eama...@yahoo.ca
Twitter: @TedMacNEIL

[saurabh khandelwal]

Thanks all for helping me . Its working now and able to collected Jobs in
PDS members.

Regards
Saurabh

Saurabh Khandelwal