[Date Prev][Date Next][Thread Prev][Thread Next]
[Author Index]
[Date Index]
[Thread Index]
[SQR-USERS Info]
[SQRUG Home Page]
Re: reading SQR parameters / command line flags - An Aside!!
- Subject: Re: reading SQR parameters / command line flags - An Aside!!
- From: Peter Clark <PGCLARK@VAC-ACC.GC.CA>
- Date: Wed, 5 Jun 2002 07:13:41 -0300
Well, I figured it had to do with some peculiarity of Australian sport that the
rest of the world has absolutely no interest in ... just like if I were to make
a reference to the Stanley Cup finals, I am sure you would be wondering why I
was using up bandwidth on the topic of ice hockey on a technical mail group
when the sport has no interest or connotation in most of the countries of the
people who belong to this group. That said ... Go Red Wings!! :-)
>>> Jamie Allen <jamesa@CYB.COM.AU> 2002/06/04 8:43:20 pm >>>
For those of you that miss the Queenslander dig - Tonight is the second
Rugby League State of Origin match between Queensland and New South Wales
where Queensland are expected to get back the dignity after being thoroughly
trounced in the first game!!!!!
Go Queenslander!!!
-----Original Message-----
From: Banks, Richard [mailto:Richard.Banks@CBA.COM.AU]
Sent: Tuesday, 4 June 2002 16:01
To: SQR-USERS@list.iex.net
Subject: Re: reading SQR parameters / command line flags
Jamie's answer (poor deluded Queenslander that he is!) was applicable for
v7.5, in v8+ the table in question is currently called PSPRCSPARMS however
the problem is that they are stored in some form of meta data, ie
PSPRCSPARMS.PARMLIST for a sample process is;
-CT DB2UNIX -CS -CD F82BBLD2 -CA %ACCESSID% -CAP %ACCESSPSWD% -RP H5GL2563
-I 16819 -R H5GL2563_REPORT -CO HATEMF -OT 2 -OP "c:\temp\" -OF 2
where I think -OP = output path, -OF = output format (2=PDF, 3=CSV) etc
would require a bit of debugging, however if that's what it takes..
I think PS binaries interpret this meta data into process type specific
parameters, pretty clever really, just frustrating when you can't access
that logic! So that would indeed be a backup plan which I may end up using.
I will be using the process scheduler for the reports (I just develop using
command line), however would prefer a solution that doesn't rely on it.
> -----Original Message-----
> From: Michael Lee [SMTP:homestoremike@YAHOO.COM]
> Sent: Tuesday, June 04, 2002 3:44 PM
> To: SQR-USERS@list.iex.net
> Subject: Re: reading SQR parameters / command line flags
>
> This is only true if you are running the SQR using
> Process Scheduler. Richard's example below shows that
> he is running it through command line/Windows client,
> which will not write to PSPRCSRQST.
>
> Mike
>
> --- Jamie Allen <jamesa@CYB.COM.AU> wrote:
> > Have a look at the table PSPRCSRQST and try the
> > following:
> >
> > SELECT PARMLIST
> > FROM PSPRCSRQST
> > WHERE PRCSINSTANCE = '?????'
> >
> > This should get what your after.
> >
> > Go Queenslander!!!!
> >
> > -----Original Message-----
> > From: Banks, Richard
> > [mailto:Richard.Banks@CBA.COM.AU]
> > Sent: Tuesday, 4 June 2002 09:23
> > To: SQR-USERS@list.iex.net
> > Subject: reading SQR parameters / command line flags
> >
> >
> > Inside SQR can I find out what parameters were used
> > to process that SQR?
> >
> > e.g. if I execute my SQR using
> > c:\sqr\sqrw.exe c:\sqr\h5gl2565.sqr F82BINT2/*/*
> > -Ic:\sqr\ -KEEP -Fc:\temp\
> > -Oc:\temp\sqr.log -PRINTER:EP -debugABCD
> >
> > is there some undocumented string (like
> > $SQR-PARAMETERS) that I could then
> > search through to find if a certain flag had been
> > set - specifically I would
> > love to know if the user has requested CSV (-EH_CSV)
> > format and alter my
> > print statements accordingly to not worry about
> > printing headers.
> >
> > I imagine as a fallback I could hunt through the
> > PeopleSoft tables as it
> > must be stored somewhere, but I really don't want to
> > (it involves derived
> > records and got complex quickly!) - anyone know the
> > table in question that
> > stores PARMLIST?
> >
> >
> > ************** IMPORTANT MESSAGE **************
> > This e-mail message is intended only for the
> > addressee(s) and contains
> > information which may be confidential. If you are
> > not the intended recipient
> > please advise the sender by return email, do not use
> > or disclose the
> > contents, and delete the message and any attachments
> > from your system.
> > Unless specifically indicated, this email does not constitute formal
> > advice or commitment by the sender or the Commonwealth Bank
> > of Australia (ABN 48
> > 123 123 124) or its subsidiaries.
> > **************************************************
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com