Date: Thu, 29 Dec 2005 17:53:50 -0500
Reply-To: "Rickards, Clinton (GE Consumer Finance)"
<clinton.rickards@GE.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "Rickards, Clinton (GE Consumer Finance)"
<clinton.rickards@GE.COM>
Subject: Re: PASSING macro variable from sas program to JCL
Content-Type: text/plain; charset="iso-8859-1"
Using a GDG would probably be a good idea. The 0th file (0) is always the current version, if memory serves.
The problem with GDG's is trying to know what date a particular generation references (i.e. the cycle date in Ken's case). Having the cycle date in file name is great but makes refencing that file difficult in JCL.
I have always been partial to placing the cyle-date in the SAS data set label. Alternatively, one could maintain a file linking goovoo (generation numbers) with cycle date.
Clint
-----Original Message-----
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU]On Behalf Of
Droogendyk, Harry
Sent: Thursday, December 29, 2005 5:42 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: PASSING macro variable from sas program to JCL
Sorry, should have expanded on the thought.
Steps after the one that created the specific generation would refer to
the latest generation ( haven't worked on the The Real Computer in too
long, my memory is failing me, but I think that's the 0th generation
within the same job ). In the case of production environment failures,
operations / scheduling packages generally know how to recover / restart
to grab the appropriate generation.
-----Original Message-----
From: Droogendyk, Harry
Sent: 2005, December, 29 5:37 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: RE: Re: PASSING macro variable from sas program to JCL
Should the flat file be defined as a GDG with the appropriate number of
generations? Might be best of both worlds?
-----Original Message-----
From: owner-sas-l@listserv.uga.edu [mailto:owner-sas-l@listserv.uga.edu]
On Behalf Of Rickards, Clinton (GE Consumer Finance)
Sent: 2005, December, 29 5:20 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: RE: Re: PASSING macro variable from sas program to JCL
All,
I think we need to be careful about throwing out the baby with the
bathwater in deciding whether to use DD statements or not.
I tend to agree that in an ad hoc environment coding DD statements can
be a pain and not nearly as powerful as SAS programming. And one does
have to program that support.
But in a production environment, DD statements have the primary
advantage of visibility. Job scheduling and analysis tools won't look
into SAS programs to see if a data set is being used in a job. Also, at
least in my experience, production support staff who monitor and respond
to problems don't know anything about SAS and would have a hard time
responding to problems. They can handle overriding a DD statement to use
a copy of a file but not modifying a SAS program to do the same thing.
And I much preferred having that support staff handling problems at 3 in
the morning to having them call me at 3 in the morning.
If an ad hoc job will find its way into production then it would ease
the transition to write the DD statements to begin with.
My 2 cents...
Clint
-----Original Message-----
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU]On Behalf Of toby
dunn
Sent: Thursday, December 29, 2005 4:57 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: PASSING macro variable from sas program to JCL
Paul,
I use to have a job card and a step card to fire up SAS, plus a work and
sort space card.
Toby Dunn
From: "Choate, Paul@DDS" <pchoate@DDS.CA.GOV>
Reply-To: "Choate, Paul@DDS" <pchoate@DDS.CA.GOV>
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: PASSING macro variable from sas program to JCL
Date: Thu, 29 Dec 2005 13:53:13 -0800
SASGUY -
JCL DD cards? Yuck! 95% of the time my JCL has two cards: a job card and
then a step card to fire up SAS. I let SAS do all my file handling.
IMHO use filename and libname statements instead of DD cards wherever
possible. Nearly all the allocation parameters are available, and you
have the flexibility of macros and such. As an added bonus your code
will be portable to a remote session on PC or whatever.
Look at
http://support.sas.com/onlinedoc/913/getDoc/en/hosto390.hlp/a000216681.h
tm
Once you've mastered the filename and libname statements, in v9 several
related functions were added: FCLOSE, FDELETE, FEXIST, FILEEXIST,
FILENAME, FILEREF, FINFO, FOPEN, FOPTNAME, FOPTNUM, and LIBNAME. With
these you can check for existing files to delete and allocate new files
conditionally and things like that. Much more flexible than JCL,
portable, and the syntax is much more forgiving.
hth!
Paul Choate
DDS Data Extraction
(916) 654-2160
-----Original Message-----
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of
sasguy
Sent: Thursday, December 29, 2005 12:28 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: PASSING macro variable from sas program to JCL
hi all,
I have weird problem when iam working with mainframe JCL and sas I have
a SAS program and JCL that runs sas program My sas program creates one
flat file and the name of flatfile contains cycle for example:
xxx.yyy.bbbb.0412(<- cycle)
this filename i am using dd statement in JCL but I need to get cycle
dynamically from sas program to JCL Please Let me know If u have any
suggestions Thanks in Advance sasguy
_______________________________________________________________________
This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations.
Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized.
If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately.
Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent.
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite.
Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.
