|
|
 | | From: | Carroll, Bill | | Subject: | Re: massive boilerplate inclusions (was : functions returning bo olean ... or failing ...) | | Date: | 18 Jan 2005 06:02:25 -0800 |
|
|
 | Jim,
Regarding massive boilerplate inclusions. I totally concur Robert's code is
excellent... would save us a lot of work... although http://www.cbttape.org/
fills that role pretty well. I don't use it enough.
I was messing around the other day and wrote a simple REXX "pre interpreter"
for lack of a better term. To handle all the mundane REXX code that I hate
coding every time. It works on a "code skeleton concept" where you write a
skeleton REXX and have "add code here" spots in the skeleton. It puts the
rexx together on the EXECFILE DD and executes it on the fly. The skel that
this JCL uses is @TRXDSUT which is a basic file fix type skeleton. This way
I can write a few lines of code and have all the error checking / file I/O
stuff already written. Here is what the JCL looks like...to give you an
idea. It has proved to be fairly useful.
It's a different concept than what you were talking about...but related in
that it saves you from recoding a bunch of stuff.
//JS010 EXEC PGM=WAAPLINK,
// PARM=(IKJEFT01,'RC=0',
// 'REXXPRE @TRXDSUT NOPRINT NODEBUG')
//SYSEXEC DD DSN=PACES.HRMLB.CLIST,
// DISP=(SHR,KEEP,KEEP)
// DD DSN=SYS1.TSO.CLIST,
// DISP=(SHR,KEEP,KEEP)
// DD DSN=SYS3.TSO.CLIST,
// DISP=(SHR,KEEP,KEEP)
// DD DSN=SYS2.TSO.CLIST,
// DISP=(SHR,KEEP,KEEP)
//EXECFILE DD DSN=&&NEWCODE,
// DISP=(NEW,PASS,DELETE),
// UNIT=SYSDA,
// SPACE=(TRK,(1,1),RLSE),
// DCB=(SYS3.DSCB,DSORG=PS,RECFM=FB,LRECL=80,BLKSIZE=0)
//SYSUT1 DD DISP=SHR,DSN=FILE.NAME.IN(0)
//CODEHERE DD DATA,DLM=$$
/* ADD YOUR REXX CODE HERE */
/* SYSUT1 IS YOUR INPUT RECORD */
/* SYSUT2 through SYSUT20 are your output records */
/* To write records just set the value of SYSUTX and call the */
/* write routine... like this: */
/* SYSUT2 = SYSUT1 */
/* CALL WRITE('SYSUT2') */
/* MAKE SURE TO ADJUST YOUR LRECL ON YOUR JCL OUTPUT FILES */
/* COUNTERS ARE AS FOLLOWS: */
/* IDX1 - FOR SYSUT1 */
/* IDX2 - FOR SYSUT2 */
/* IDX3 - FOR SYSUT3 */
/* .... */
/* IDX20 - FOR SYSUT20 */
/* */
INIT:
SAY ' Initialization Routine '
RETURN
FINAL:
SAY ' Finalization Routine '
RETURN
/* ADD OTHER ROUTINES HERE MAKE SURE THEY HAVE A "RETURN"*/
/* ADD INTERNALLY CALLED PROCEDURES HERE */
$$
//*
//*
//SYSUT2 DD DSN=&SYSUID..TEST2(+1),
// DISP=(NEW,CATLG,DELETE),
// SPACE=(10796,(2000,1000),RLSE),
// DCB=(SYS3.DSCB,DSORG=PS,BUFNO=8,
// RECFM=FB,LRECL=133,BLKSIZE=0)
//SYSUT3 DD DSN=&SYSUID..TEST3(+1),
// DISP=(NEW,CATLG,DELETE),
// SPACE=(10796,(2000,1000),RLSE),
// DCB=(SYS3.DSCB,DSORG=PS,BUFNO=8,
// RECFM=FB,LRECL=133,BLKSIZE=0)
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSTSIN DD DUMMY
//*
FYI,
Bill Carroll
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-REXX@VM.MARIST.EDU] On Behalf Of
Fenner, Jim
Sent: Tuesday, January 18, 2005 01:29
To: TSO-REXX@VM.MARIST.EDU
Subject: massive boilerplate inclusions (was : functions returning boolean
.... or failing ...)
An idle comment on the "functions returning boolean ... or failing ...)"
example:
One COULD retain some sort of clarity by calling an internal routine
called i_iplsoon, which then calls external iplsoon
if i_iplsoon() then ...
deep in the in the bowels of your program is the real call:
i_iplsoon :
(do stuff)
xv=iplsoon() /* call external Rexx */
/* handle error condition - copied from Mr Bridges post*/
if left(xv,1)='!' then
else /* proceed using xv */".
(do more stuff, ie error checking)
return xv /* if errors happen, we might exit by SIGNAL */
Points to ponder:
-----------------
- If you don't own ipsloon external rexx, this helps you code around any
weaknesses
- If you do own it, you can go the extra mile and paste lots of error
checking into it as well (it seems to be a theme that we're never safe
anywhere without lots of error checking)
- If everyone had a Rexx compiler we could do helpful INCLUDES I
believe. But we don't in our installation.
- Related gripe:
---------------
With Rexx one has to code EVERYTHING oneself - with Java, one gets a
vast class library of tested routines and WORKING examples for free.
Will IBM ever distribute a vast library of Rexx routines at *any* price
that would save us all this work?
It's like the old joke about "You'll have to make your own bed" and then
you get handed a hammer and nails!
- I am starting to wonder if massive boilerplate inclusions in EVERY
rexx are the only way to create reliable REXX code bases.
I say this after seeing many polished examples from (eg) Mr Rob Zenuk,
and also Frank Clarke.
Maybe we all ought to just individually pay Mr Zenuk for a licence to
his entire library, the fruit of decades of experience, and toss out
almost everything else we have written ... :-(
Wed end up with 500,000 lines of Rexx in our toolbox instead of 100,000,
but at least we would all share the same 500,000 lines ...
Regards
Jim
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-REXX@VM.MARIST.EDU] On Behalf
Of Carroll, Bill
Sent: 11 Jan 2005 09:57
To: TSO-REXX@VM.MARIST.EDU
Subject: Re: functions returning boolean ... or failing ...
Bob thanks for your input... I have been returning 0 1 or -1 from the
subroutine and letting the SIGNALs in the Calling program catch the
error.
I may continue to do this... but for clearer error messages... QUEUE one
to
the stack for the calling REXX to use it it's handling of the error. I
was
just hoping to find a really clean way to do it.
Thanks for the options.
Bill
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-REXX@VM.MARIST.EDU] On Behalf
Of
Bob Bridges
Sent: Friday, January 07, 2005 12:44
To: TSO-REXX@VM.MARIST.EDU
Subject: Re: functions returning boolean ... or failing ...
Yeah, but if 0 (false) is a valid return, how is the calling routine to
know the difference between FALSE and a failure?
I can think of two ways to deal with this...no, three:
a) Have the subroutine handle the error all by itself, by abending the
program if there's a problem, or by contacting the user itself, or with
your SIGNALs, or something. This is often unsatisfactory, but after all
it's the method used with the built-in functions -- they return a value
if
at all possible, but otherwise abend the program ("improper call to
routine...").
b) Have the calling program test the rc for non-Boolean values. For
example, in subroutines that are supposed to be silent to the user, I
often signal an error to the calling routine by an error code preceded
by
a bang ("!"). So if the routine passes back an expected value, it's
good,
but if it returns "!43" it means something went wrong. If you use this
technique, you'd have to say "xv=iplsoon(); if left(xv,1)='!' then /*
handle error condition */; else /* proceed using xv */".
c) Write Boolean subroutines only in cases that are so simple there is
no
error condition to be caught.
The problem with option B is that it ignores the whole point, ie the
simplicity and convenience of being able to say merely "if
iplsoon()...".
But then, if you have to consider possible error conditions, the
simplicity was illusory, wasn't it?
---
Bob Bridges, robertbridges@discoverfinancial.com, 224 405-0811
rhbridg@attglobal.net, 847 520-1684 xt 243
/* Influence is not to be confused with corruption. Influence can get
you
to the head of the line to get your driver's license; corruption is when
you fail the test but get the license anyway. -William F Buckley,
2004-09-17 */
"Woodlyn, Sjon O."
2005-01-07 11:06
To: TSO-REXX@VM.MARIST.EDU
cc:
Subject: Re: functions returning boolean ... or failing
....
If it fails, shouldn't the error processing in IPLSOON() set the bool
value
to false? The whole point in boolean is that it return either
true/false
(a
failure being false).
-----Original Message-----
From: Carroll, Bill [mailto:william.carroll@EDS.COM]
Sent: Friday, January 07, 2005 8:58 AM
I have some confusion on the best way to go.... as far as coding
functions
that return boolean true or false. For instance.
If I have a function called : IPLSOON and I call it like this:
IF IPLSOON() THEN
.... do IPL notification stuff
ELSE
.... continue monitoring
My question is... How do I handle a failure in a function that returns
boolean values... where anything other than true(1) or false(0) returned
becomes an error in the calling REXX.
I typically use the following skeleton code for error routines and
adjust
them according to the specific implementation.
/* rexx */
Arg Whatever .
Signal On Failure
Signal On Syntax
Signal On Novalue
/* add code here */
EXIT
/*-------------------------------------------------------------------*/
/*- ERROR ROUTINES -*/
/*-------------------------------------------------------------------*/
Failure:
PARSE SOURCE . EXECTYPE EXECNAME EXECDDN EXECDSN . EXECENV EXECADSP .
Say "Error in" EXECNAME " - Failure occured on source line" Sigl
Say SOURCELINE(Sigl)
Call Cleanup
Exit(???)
Return
Syntax:
TRC = RC
PARSE SOURCE . EXECTYPE EXECNAME EXECDDN EXECDSN . EXECENV EXECADSP .
Say "Syntax Error in " EXECNAME '-' ERRORTEXT(TRC) '- LINE' Sigl
Say SOURCELINE(Sigl)
Call Cleanup
Exit(???) /* USE -1 for sub prog. actual abend code for driver */
Return
Novalue:
PARSE SOURCE . EXECTYPE EXECNAME EXECDDN EXECDSN . EXECENV EXECADSP .
Say "Error in" EXECNAME " - Novalue used on source line" Sigl
Say SOURCELINE(Sigl)
Call Cleanup
Exit(???) /* USE -1 for sub prog. actual abend code for driver */
Return
Cleanup:
/* do program specific cleanup here */
Return
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
****************************************************************
IMPORTANT
The information transmitted is for the use of the intended recipient only
and may contain confidential and/or legally privileged material. Any review,
re-transmission, disclosure dissemination or other use of, or taking of any
action in reliance upon, this information by persons or entities other than
the intended recipient is prohibited and may result in severe penalties. If
you have received this e-mail in error please notify the Privacy Hotline of
the Australian Taxation Office, telephone 13 28 69 and delete all copies of
this transmission together with any attachments.
****************************************************************
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LISTSERV@VM.MARIST.EDU with the message: INFO TSO-REXX
|
|
|
